#ubuntu-devel 2005-03-14
<seb128> sorry :(
<mdz> no worries; we are just a bigger team than we used to be :-)
<mdz> not everyone knows what everyone else is doing\
<mdz> I thought about having a release weather applet
<mdz> telling what was safe to upload at the current moment
<jbailey> mdz: Is there an equivalent of snapshot.debian.net?  Maybe also just get a version number list, and pick them specifically.
<mdz> jbailey: morgue.ubuntu.com is the closest thing we have
<lamont_r> seb128: x-c /ia64 just tossed back into the fray, Ithink that's the end of howl.
<seb128> mdz: should mail or put a topic about upload freezes :)
<lamont_r> Kamion: yeah - requested of said user, who is going to try to reproduce it now.
<lamont_r> and given that the CPU in question is a copermine, I don't see why it would fail...
<jbailey> mdz: Yeah, that would do, they just would need to be aptable.  Then make a version list as of a given moment and add today's date to the source.list, and you've got your snapshot without freezing anything.
<sabdfl> guys, hoary looks superb. really looking forward to preview
<sabdfl> night all
<Kamion> night Mark
<mdz> night
<thom> night mark
<mdz> jbailey: it gets to be complex because we're building different things in different places and need for them to be in sync.  it's much simpler to stop processing uploads for the hour or so that we need to roll one of these
<lamont_r> jbailey: actually, having a script rip across morgue.u.c and compose source packages across all of them could be a nice thing tohave.
<lamont_r> mdz++
<sabdfl> brainy, ballsy, bawdy, bendy, breezy, beefy... hmm...
<sabdfl> kthxbye
<lamont_r> sabdfl: ballsy?
<thom> blousy
<Kamion> mdz: it was always going to be awkward today, with elmo travelling
<jbailey> lamont_r: Wasn't it some name like that which got jdub larted for the release names in Gnome? =)
<mdz> yeah, I didn't realize the array-6/cabal-meeting collision until just now
<seb128> jbailey: yeah, now GNOME releases are not named :p
<thom> jbailey: the release codename was "and testicles too" or something, and lots of french people whined :P
* seb128 slaps thom 
<seb128> (that's kind of true :p)
* thom defaults to english blamelaying
<thom> seb128: yes, that's the best part :-)
<seb128> http://mail.gnome.org/archives/desktop-devel-list/2004-February/msg00051.html
<seb128> that's it
<mdz> thom: the English blame the French, and the French blame GTK?
<jbailey> Does that make Miguel French?
<seb128> ah ah :)
<jbailey> ;P
<seb128> rofl
<zul> everybody blames the french..
* jdub growls at seb128 :-)
<zul> or people from toronto
<thom> mdz: nah, the french just lose paris 
<seb128> rrrroh
<jon1012> (someone knows a good lib to instanciate an app ? like gedit who open a new tab when you open a new file with nautilus)
<jon1012> hmmm
<jon1012> i'm french :(
<jon1012> lol
<seb128> jon1012: gedit use bonobo for that
* jbailey is registered on the census as a francophone. =)
<seb128> :)
<zul> my dad is a francophone
<jon1012> seb123 > thx :)
<mdz> lamont_r: weddell finished awfully fast; did it succeed?
<jon1012> seb128 > do you know tutorials for this type of thing ?
<jon1012> seb128 > or doc maybe ? :/
<seb128> gedit's code ? :)
<jon1012> loool
<jon1012> :p
<lamont_r>  ubuntu-desktop: Depends: powermanagement-interface but it is not going to be i
<lamont_r> nstalled
<lamont_r> mdz: that'd be a 'no' ^^^
* lamont_r wonders if maybe we introduced yet another arch-all package that depends: on some partially populated arch-specific package
<thom> pm-i is arch: any
<lamont_r> seb128: syck is the only ia64 failure currently sitting on the pile
<lamont_r> and it segv's - bumer
<thom> ah. acpi-support is the issue
<thom> bugger
<seb128> lamont_r: k
<eazel7> flash plugin crashes my browsers :(
<thom> lamont_r/mdz: I can upload a new acpi-support if it helps, just adding ia64 to the arch list
<eazel7> anybody noticed this?
<thom> eazel7: please take support queries to the #ubuntu channel
<Kamion> thom: please
<lamont_r> thom: won't it fail?
<thom> lamont_r: why? acpid is available on ia64
<thom> as is acpi
<eazel7> ok
<lamont_r> ah, nm.  please upload away
<eazel7> but I'm using hoary, #ubuntu anyway?
<lamont_r> yes
<Kamion> thom: for the record your byhands look ok, we'll find out in a bit though
<lamont_r> eazel7: this would be the channel to discuss your proposed code change to fix the issue.
<eazel7> k
<Kamion> acpi-support will bite the install CD too
<thom> Unpacking acpi-support (from ../acpi-support_0.19_ia64.deb) ...
<thom> Setting up acpi-support (0.19) ...
<thom>  * Checking battery state...                                             [ ok ] 
* thom uploads
<lamont_r> thom: you running hoary on that ia64 box?
<thom> lamont_r: yes
* lamont_r makes a note to actually install his zx2000 sometime soon
<lamont_r> Kamion: how close are daily/current to array 6's release state?
<Kamion> lamont_r: daily/current won't install second stage
<lamont_r> oh well.  with luck it's a small rsync from array 6, yes?
<Kamion> should be, yeah
<lamont_r> because eventually, my buddy is going to kick me out.. :-)
<Mithrandir> mvo: around?
<mvo> Mithrandir: yes, but pretty sleepy
<Mithrandir> mvo: could you send me your .dmrc?
<Mithrandir> just paste it in a query.
<mdz> Kamion: cloops are ready
<mdz> lamont_r: weddell == powerpc?
<Kamion> weddell == ia64
<Kamion> starting live CD builds now
<mvo> Mithrandir: sure
<lamont_r> weddell==ia64
<mdz> would anyone cry if we didn't have an array 6 for ia64?
<lamont_r> adare == ppc
<lamont_r> a daily later wouldn't hurt either
<Kamion> mdz: kinda sucks in the release announcement
<Kamion> we can leave out just the live CD
<mdz> we could use the old cloop for ia64
<Kamion> I'm going to wait for acpi-support for the install CD anyway
<mdz> lamont_r: how old is it?
<lamont_r> Kamion: then again, not having it would tend to maybe motivate the technical folks to step up to the plate....
<mdz> Kamion: you do want to sleep at some point, don't you?
<Kamion> lamont_r: true ...
<jon1012> (I know it's not the place, but is there somebody knowing something about bonobo activation here ?)
<Kamion> mdz: yeah, but I also want to not release a mess
<lamont_r> 20050211.3
<lamont_r> libbonobo was backed up for a while
<Kamion> lamont_r: if you build the cloop when fixed acpi-support's in, I can rebuild just the ia64 live CD and release that
<lamont_r> Kamion: works for me
<Kamion> thom: would you mind hurrying cron.daily when acpi-support builds are ready?
<Kamion> doing whatever the katie crontab does, I guess
<lamont_r> thom: holler when you kick it, eh?
<Kamion> #7108> what sets the default keyboard rate? it sure as hell isn't base-installer
<Kamion> I guess that's in the kernel or something
* mvo goes to bed now
<mdz> even if ia64 were horribly broken, I wouldn't consider it a mess overall
<lamont_r> mdz: ia64 or the array? :-)
* lamont_r ducks
<Kamion> mdz: some urgent-must-be-fixed-right-away bustage has come up in Debian, so I'm going to be up for a while anyway :(
<thom> Kamion: waiting on buildds
<Kamion> thom: ta
<lamont_r> thom: I think they've all uploaded
<thom> lamont_r: jackass disagrees
<lamont_r> well, I told em all to
<thom> oh, just waiting for queue run
<thom> i'll let you off :-)
<lamont_r> yeah - cron.hourly; cron.daily :0)
<lamont_r> although hourly is probably safer to just wait 5 minutes
<thom> lamont_r: yes
* lamont_r twiddles thumbs, waits for the baton pass
<amu> hmm what happend with gnupg-agent, gnupg2 gpgsm ?  
* thom gets bored and kicks cron.daily
<thom> aww:
<thom> Installing new version of config file /etc/init.d/powernowd ...
<thom> This processor "" is known _not_ to support power-saving.
<thom> you mean mckinley doesn't support speedstep?
<lamont_r> hehe
<Kamion> live CDs available
<thom> Updating wanna-build databases...
* lamont_r looks at byDate/today.html, screams.  MUST KILL WANNABUILD
<thom> Kamion: mirrors should be updating now
<lamont_r> meaning jackass is current?
<thom> jackass is current now, yes
<thom> cron.daily just finished
<Kamion> lamont_r: what's wrong with it?
<lamont_r> package in main b-d package in universe --> loop every cron.daily, polluting the reports
<Kamion> ouch
<lamont_r> ia64 livecd/d-i builds kicked
<lamont_r> and there are at least 2 such packages today
<lamont_r> so w-b needs to respect the ogre model
<lamont_r> OTOH, it's pretty easy to tell, even with my hail-mary gnome smashing today
<thom> oh, fucksticks
<thom> i need to fix ffox on ia64 at some point
<lamont_r> thom: lol
<lamont_r> hey - fix hppa whileyou're at it,eh?
<lamont_r> same bug, wasn't it???
* lamont_r was afraid he was going to have to scream there for a second
<thom> hrm
<thom> that means finding power and network for the hppa
<lamont_r> thom: I'll buy you _3_ beers if I can quit stripping firefox from the ubuntu-desktop/hppa :-)
<thom> i'm hoping it'll just go away when i upload ff 1.0.1 actually
<lamont_r> that'd be way cool
* lamont_r really doesn't care _how_ it gets fixed
<Kamion> and cdimage cron.daily's away
<thom> Kamion: d-i look ok then? *phew*
<Kamion> thom: I think so, yeah
<Kamion> we'll find out :)
<thom> heh
<thom> Kamion: i may just be about to suffer sketchy routing while blackcat do a router swap out
<Kamion> k
<thom> although, i think the worst of it just happened :-)
<amu> Kamion: any idea where's gnupg2 left? thought, i would already once have seen this in archive
<lamont_r> ubuntu-desktop is installable
<lamont_r> and currently installing
<Kamion> amu: dunno, sorry, have had a lot of stuff to pay attention to today ...
<Kamion> cjwatson@rookery:~$ madison-lite gnupg2
<Kamion> cjwatson@rookery:~$
<thom> thom@jackass:~ $ grep gnupg2 /srv/ftp.no-name-yet.com/queue/accepted/REPORT
<thom> thom@jackass:~ $
<thom> i'd say that was fairly conclusive
<dholbach> good night everyone
<lamont_r> thom: yeah.  that'd better be conclusive
<thully> does anyone know if the fact that no icons for USB sticks, CD-ROMs, etc are appearing on the desktop is considered a feature or a bug for Hoary?
* lamont_r wonders if that's inotify's fault
<HrdwrBoB> yeah inofity
<lamont_r> thully: at this point, I think that would make it a feature
<thully> funny... too bad, as this worked OK on Warty
<lamont_r> well, I'm hardly authoritative on that subject.
<lamont_r> but current plan for inotify is to have it disabled, but as close to working as possible if you enable it, for release
<zul> lamont_r: inotify should be disabled
<lamont_r> so if it truly depends inotify, then it'll be off
<lamont_r> zul: right
<lamont_r> too close to release to be debugging it now
<zul> nah..:)
<lamont_r> OTOH, once we do release, then we turn it back on once it's stable enough to avoid the wrath of jdub, et. al.
<seb128> 'night
<lamont_r> thom: so is shtoom gonna make hoary? huh? huh? huh????
<zul> heh...well you dont need inotify for things like beagle anymore
<thom> lamont_r: talk to daf
<lamont_r> thom: yeah - saw his packages, was wondering if we were going to at least get it into universe before releas
<lamont_r> s
<lamont_r> e
<thom> lamont_r: too many things on my plate to think about shtoom atm; i'll try and work with him post preview 
<lamont_r> kewl
<Kamion> y'know, technically, adding acpi-support to ia64 requires a change to ubuntu-meta too ... but right now that can go jump
<lamont_r> Kamion: technically?  it got in there... explicitly seeded or not... :-)
<Kamion> yeah, powermanagement-interface depends on it, I guess maybe we should unseed it
<Kamion> and thus change ubuntu-meta for the two other architectures. :)
<lamont_r> yeah
<lamont_r> :-)
<lamont_r> and label the checkin 'remove acpi-support from i386, amd64' :-)
<Kamion> heh
<Kamion> shame we don't actually mail seed changes anywhere - that'd be good for a coronary or two
<thom> heh
* lamont_r heads back home
* thom -> bed
<thom> Kamion: no problems i take it?
<Kamion> thom: hard to tell, CDs haven't finished building
<lamont_r> Kamion: I'll be back on in about 5-10 min
<Kamion> ok
<thom> Kamion: how long will they likely take? I can wait :-)
<Kamion> thom: about 15-20 minutes I think
<thom> kewlies
* thom hugs apt for doing the right thing with install mozilla-firefox-locale-*-
<mjg59> Argh why does swsusp have to be so crap
<zul> mjg59: have you tried swsusp2 or is that even more crappier
<mjg59> zul: That's crappy in entirely different (and far more crackful) ways
<mjg59> zul: It puts a user interface in the kernel
<zul> ah
<zul> ewww
<zul> thats kind of bad
<mjg59> Seriously, the kernel says Press escape to continue
<zul> thats crap
<mjg59> That's why we're not shipping it
<zul> good
<zul> good to know as well
<TerminX> http://pastebin.arslinux.com/1370 <- does anyone know what would cause that to happen?  upgraded Hoary this afternoon and was greeted with that mess afterward
<zenwhen> trying to overwrite `/usr/share/icons/hicolor/48x48/apps/gnome-run.png', which is also in package gnome-panel-data
<zenwhen> does anyone know the solution to this upgrade issue
<zenwhen> i asked once and was given the solution but a friend of mine is now having the issue and i have forgoten the solution
<TerminX> what package is giving you that?
<thom> ubuntu-artwork
<TerminX> you could dpkg -i --force-overwrite I guess
<Kamion> thom: won't that hit install CDs?
<schweeb> TerminX: hah, you said the force word... evil
<TerminX> schweeb: what, you think I'd sit there wasting time trying to find a "pretty" solution to something like an overwritten png of all things? :p
<thom> Kamion: hrm; didn't for me
<thom> or rather, i just installed ubuntu-artwork without problem
<TerminX> that png isn't even supposed to be in gnome-panel-data.. it's in gnome-icon-theme here
<TerminX> what version of gnome-panel-data do you have installed zenwhen 
<lamont> moof
<TerminX> and does anyone have any ideas about the apt-get upgrade eating 150 of my device nodes?
<lamont> mjg59: gack!  no UI in the kernel, dammit
<lamont> (that is, good choice!)
<thom> TerminX: i hate to ask, does rebooting help?
* Mithrandir notes that "C" is not in libc's list of supported locales
<Kamion> doesn't need to be :)
<thom> TerminX: (ie, is it a temporary issue or is udev utterly hosed)
<TerminX> I haven't tried.  I'm sure it would fix it, though.
<TerminX> udev has been hosed since it upgraded and stalled doing something last week; I haven't rebooted to fix that yet, simply unmounted it and went back to actual device nodes.. of course, that does mean something in the upgrade just fucked my actual nodes on disk
<Kamion> or it might have remounted /dev?
<TerminX> I've checked that
<Kamion> ok
<TerminX> it's not mounted, the actual nodes in my /dev had all of their permissions screwed
<TerminX> good thing I don't need most of the affected ones, but it's kind of annoying having to chown and chmod a bunch of ones I do need
<TerminX> this has happened before as well
<Kamion> bugger, ubuntu-desktop is *still* uninstallable in new install CDs
<Kamion> iz gnome bug
<mdz> gah
<mdz> which bit?
<thom> Kamion: bugger
* mdz rsyncs the new images anyway
<Kamion> gnome-applets, gnome-applets-data, gnome-panel, gnome-panel-data, gnome-system-monitor all uninstallable
<Kamion> the first four tend to be interdependent, dunno about g-s-m
<Kamion> that's on all architectures
<mdz> and seb128 left
* Kamion starts singing "up all night"
* Mithrandir ponders just making "current locale == C" => "new locale == en_DK.UTF-8" in utf8migrationtool
<Mithrandir> it'll make the code a lot simpler
<Kamion> heh, yeah, en_DK.UTF-8 is an interesting one
<Mithrandir> Kamion: actually, what locales do you enable if the system default locale is just C?
<mdz> how did the cloop images succeed if that stuff is uninstallable?
<mdz> unless the problem was caused by that gnome-vfs2 upload, which was just after I started those builds
<Kamion> Mithrandir: dunno, the installer never leaves it that way
<Mithrandir> Kamion: mvo claims he has C as his locale, with en empty /etc/environment and no Language setting in dmrc.
<Kamion> Mithrandir: it might've done once ...
<Kamion> it's not supposed to anyway
<lamont> Kamion: so are we nearly there yet? :-)
* Kamion kicks lamont
<lamont> LOL
<lamont> sorry - couldn't resist
<Kamion> :)
<thom> elmo left me that as a voicemail earlier
<Kamion> bastard
<thom> when i was kicking gentoo in the RAID array
<zenwhen> TerminX, 
<zenwhen> thanks for trying to help. Sorry i ran off.
<zenwhen> The person I was helping solved it.
<zenwhen> and ran off on me
<zenwhen> lol
<lamont> Kamion: um, the chroots on the buildd's can install ubuntu-desktop....
<TerminX> aha
<Mithrandir> Kamion: so the user should always have a supported locale set?
<zenwhen> Is array 5 pretty stable?
<zenwhen> I am planning to do a clean install with it Friday
* TerminX hasn't done a clean install on this machine since early 2003
<Kamion> zenwhen: yeah
<zenwhen> cool stuff
<TerminX> knoppix -> sid -> warty -> hoary :)
<zenwhen> I have to do a clean install
<Kamion> zenwhen: but by Friday Array 6 will be out
<zenwhen> the whole backports thing bit me in the ass
<zenwhen> Oh
<Kamion> Mithrandir: nowadays, yeah, but can't absolutely guarantee it
<Kamion> lamont: maybe britney's wrong, but that doesn't often happen
<zenwhen> if it is out early enough in the day I will go with it.
<schweeb> TerminX: hah, I reinstall like every month
<lamont> Kamion: there was much gnome-thrashing today
<TerminX> I don't fuck anything up to the point of reinstallation
<schweeb> oh I don't mess things up
<Kamion> zenwhen: er, if it's out early Friday that means that I will be up for the next 30-something hours, which I have no plans to do
<TerminX> this install is probably torn to shit though.. it's been through a lot
<TerminX> it had Xorg built from CVS HEAD on it for a while when it was running sid, et cetera
<zenwhen> Kamion, oh dont be a wuss. :P
<schweeb> TerminX: I just thrash my system beyone belief by installing packages without care
<TerminX> dude, that counts as messing it up
<schweeb> my last install, I swear I had every -dev package installed
<TerminX> rol
<zenwhen> I installed all kinds of things from backports
<zenwhen> and my system is a mess
<zenwhen> lol
<zenwhen> its my own fault
<schweeb> TerminX: that's what I mean by thrash...not actual destruction... when shit doesn't compile/work, I just randomly install stuff
<TerminX> heh
<schweeb> when it works, I stop
<Kamion> backports are very difficult to get right; don't use backports not made by people you absolutely trust to be competent
<TerminX> when shit doesn't work for me, I figure out the cause of the problem and rectify it
<TerminX> if I'm missing a header, I use apt-file
<TerminX> and so on
<Kamion> if it's "hey, I built this on warty and it seems to work", run away
<dredg> TerminX: what? apply logic to the problem? are you *insane*?
<TerminX> yes, actually, I am
<Mithrandir> Kamion: bah, that sucks, since I then have no really sane way to check whether there is any valid UTF8 locale on the system at all.
<TerminX> I make sure to take my pills, though..
<schweeb> TerminX: well, there's a method to the magic... but the gnu buildtools are rather vague with dependencies
<zenwhen> Fixinfg my current set of problems would require more effort than I am willing to put forth.
<schweeb> s/magic/mayhem/
<Kamion> Mithrandir: in general you can't guarantee that the user's locale is valid; people set their locale to random rubbish all the time
<Mithrandir> Kamion: it's damn hard to transfer it to something sensible, then. :)
<Kamion> I think unsupported locales should immediately produce an error
<Kamion> the sooner the better
<Mithrandir> ok, and C is unsupported or not?
<TerminX> schweeb: you know, you don't have to completely thrash the install to make things work :p
<Kamion> C is absolutely supported, as is POSIX
<Kamion> it's like hardcoded in glibc
* lamont ponders what mother board to buy
<Mithrandir> but it doesn't support utf8, so utf8migrationtool needs to change it to something sane, preferably with the exact same set of semantics, modulo utf8 support.
<Mithrandir> lamont: what CPU family?
<schweeb> TerminX: heh, when it tells you you need gnome-dev or something, and there are like 40 pkgs matching that description, you resort to drastic measures
<Kamion> nothing UTF-8 has the same set of semantics as C in certain ways that matter
<lamont> x86, preferably with a socket7 :-)
<Kamion> for instance, collation order is quite different, which tends to irritate the sort of people who use C
<lamont> Kamion: very
<lamont> LANG=en_US.UTF-8
<lamont> LC_COLLATE=C
<lamont> ...
<Mithrandir> Kamion: so utf8migrationtool really can't convert people who use C, since there is no UTF8 equivalent.
<Kamion> lamont: sing it, brother :)
<Mithrandir> lamont: heh, probably hard to find, I guess?
<Kamion> Mithrandir: it can, but I think it needs to ask them what they want; IMHO you really can't tell automatically
<dredg> Mithrandir: unless one were to introduce a C.UTF-8.... *duck*
<TerminX> schweeb: ha
<Mithrandir> dredg: I think Kamion and multiple other people would kill me for that.
<Mithrandir> it's bad enough to have it in the installer
<lamont> Mithrandir: ebay, dude.
<Mithrandir> people still get money for that kind of old junk?
<lamont> Mithrandir: yeah, you can get like 10-20 USD for them.
<Mithrandir> heh, ok
<lamont> this is the 9 year-old's computer, you see
* thom goes to bed
* dredg follows thom's lead
<dredg> nightol
<thom> 'nacht
<thom> Kamion: if you need desperately urgent root/ftp love, sms
<Kamion> thom: ok, thanks
<Kamion> "I've just installed Ubuntu 3.6 and I have no mouse."
<Kamion> what on earth could 3.6 be?
<lamont> array 3.6?  maybe 3.5?
<Kamion> seems a stretch, since 3.5 was live-only and he seems to be talking explicitly about an install CD
* lamont grumbles.  neither area RT deployment scheduled for May is mine.
<Kamion> RT?
<lamont> remote terminal == why I can't have DSL
<Kamion> ah
<lamont> deployment schedule is a required disclosure, you see....
<Kamion> I assumed it was firefighting somehow :)
<lamont>  Current Remote DSL DMT Interface Deployment Locations - Excel Document, 76k, posted 3/1/05
<thom> mdz/floud: oh, other thing I noticed with ubuntu-doc is that it talks about 5.4, which is wrong wrong wrong
<lamont> yes.
<lamont> 5.04, not 5.4
<lamont> thom: although 5.1 would be even more wrong
<lamont> (for hoary+1)
<thom> lamont: indeed
<lamont> hrm... either scrounge the shed for a MB for her, or buy a reasonably current system, I think
<zul> lamont: i can setup telegram station for you :)
<lamont> Kamion: you need anything from me before I run the kids to town?
<Kamion> lamont: at the moment I'm just trying to upgrade this laptop despite it being caned by a kernel compile so that I can tell if ubuntu-desktop installs here
<lamont> linux-source-2.6.10_2.6.10-25_20050302-1804 05:04:16 (12 entries, sigma 02:12:03)
<lamont> sigh
<Kamion> rsyncing down install/i386 too
<lamont> Kamion: are these currently at daily/current?
<Kamion> lamont: yes
<lamont> ok.
<lamont> I'll take the laptop with me and go scrounge bw in town then
* lamont points Kamion at the other window in case of issues that require him
<mdz> I'm not particularly fussed about 5.4 vs. 5.04, but we should certainly be consistent
<mjg59> lamont: Is there a repository for the kernel development?
<zul> mjg59: yes
<mjg59> zul: Is there any sort of public (read) access?
<zul> mjg59: http://people.ubuntu.com/~lamont/Archives/
<zul> mjg59: you are going for dpl?
<mjg59> zul: Yeah
<zul> mjg59: cool good luck
<HrdwrBoB> angrydpl.com
<mjg59> zul: Heh, thanks :)
<Kamion> sigh, I bet the Task: ubuntu-desktop lines just need to be regenerated
* Kamion contemplates an Evil Hack
<jon1012> mmh.. Kamion, you are lucky if you contemplate evil hacks only rarely ;) I contemplate each day, on my app... :/
<Kamion> who said it was rare? :)
<jon1012> loool
<Kamion> I try to keep them to a minimum, though
<jon1012> same thing for me ;)
<jon1012> (there is nothing more horrible and borring than tracking memory leaks :()
<Kamion> valgrind is your friend
<jon1012> valgrind ?
<Kamion> you don't know of valgrind? oh my god
<jon1012> I do everything by hand, analysing each line of code... :/
<jon1012> lol
<Kamion> i386-only, but it is God's gift for debugging memory problems
<jon1012> I'll try it ;)
<jon1012> thx :)
<Kamion> np, I bet you'll wonder how you got by without it
<jon1012> lol
<mdz> Kamion: hmm, why would task: ubuntu-desktop need to be regenerated?
<mdz> Kamion: you could of course switch to installing the metapackage ;-)
<Kamion> mdz: it's not regenerated frequently enough
<Kamion> yeah, and I could cope with many uses of kickstart not working sanely as a result
<mdz> it would shave several seconds off of the install, too. aptitude seems to be much faster at tracing that dependency list than processing the task
<Kamion> or if it is regenerated frequently enough, something isn't working
<Kamion> you cannot install a metapackage minus one component package
<Kamion> you can do this with tasks, and it's a common preseeding case
<Kamion> so we need to support the task anyway
<Kamion> hm, this would fix ia64 too, bonus
<Kamion> without my mad preseeding hack
<jon1012> good night everybody
<mdz> interesting, python2.3-opengl doesn't depend on python2.3
<mdz> or anything else, for that matter
* Kamion hits cron.daily again, hoping his code works
<mdz> Kamion: I've added an alias to #3057 "disk-utility" to make it easy to resolve the "ISO crashes disk utility" bugs as duplicates; that we we don't need to repeat ourselves as often
<Kamion> mdz: it seems to be unduly difficult to search for resolved bugs by alias
<Kamion> I've had that problem before, looking for the universe-security bug
<mdz> just type "disk-utility" into the duplicate of: field and it DTRT
<Kamion> (thanks, though)
<mdz> you can use aliases in place of bug numbers
<Kamion> oh, I must have missed that
<Kamion> cool :)
<mdz> (if it doesn't start with a digit, it's looked up as an alias)
<stub> Is it worth me submitting more network applet bugs for hoary, or is it due to be replaced?
<mdz> stub: netapplet is in universe
<mdz> and staying there for hoary
<stub> I'm talking about the network configuration thingy under System->Administration->Network
<mdz> ah
<mdz> that's gnome-system-tools stuff
<mdz> and yes, if it has bugs, please report them
<stub> ok. And I'll remember to not call it the Network applet from now on :-)
<mdz> Kamion: is there anything I can assist with / test?
<zul> mdz: im going to re-assign #5431 to me
<mdz> zul: ok
<mdz> stub: applets are the beasties which live directly in the panel
<mdz> except for the ones which are only notification icons...
<zul> mdz: and ill keep my notes there for the usb+inotify there
<Kamion> mdz: when cron.daily finishes, certainly ...
<mdz> waiting, then
<mdz> keeping the writer warm
<mdz> I suppose I should test a round of DVDs at some point
<Kamion> mdz: I just discovered I hadn't baz-updated little to create install/live DVDs; that'll come with the next round
<mdz> I'll wait, then
<Kamion> I wonder if you could cat a live CD onto the end of the previous install-only DVD and rsync off that :)
<mdz> hehe
<mdz> probably the other way around
<lupusBE> daniels, /opt/fdo//lib/libglitz-glx.so: undefined reference to `XF86VidModeQueryVersion' any idea where I should look for the cause of this problem?
<mdz> Kamion: do you have a cron.daily-live queued as well?
<mdz> jigdo seems to account for a huge fraction of cron.daily runtime
<Kamion> mdz: not yet
<Kamion> mdz: yes, need to switch to JTE
<Kamion> it's lots of md5summing
<Kamion> <p>First, uninstallable packages:</p>
<Kamion> [...] 
<Kamion> <p align=right>(there were 0 all up)</p>
<Kamion> hooray, much better
* Kamion suggests everyone who's up rsyncs and tests daily/current/
<Kamion> I'll rebuild live for completeness
<Kamion> mdz: oh, do we want to rebuild the cloops again? I guess not
<Kamion> ia64's cloop build died; I'll omit its live CD from the release
<Kamion> (the mozilla-firefox crash)
<mdz> I'm happy to leave the cloops alone
<mdz> it's late
<Kamion> you're telling me
<mdz> rsyncing
<Kamion> on the upside I think I can rescue the Debian powerpc 2.4 kernels, having been hacking while waiting for builds
<farruinn> 2.4 kernel?
<Kamion> farruinn: Debian, not Ubuntu
<Kamion> mdz: new live CDs up too
<mdz> getting those too
<farruinn> I think that's really great that so many Ubuntu devs work on Debian as well
<mdz> I think it would be great if I had an extra 4 hours every day :-)
<Kamion> if you find out how, let me know
<Kamion> I'm on serious borrowed time today :-) - I may not be particularly active tomorrow
<mdz> next priority is kubuntu, hopefully that won't take much more prodding
<Kamion> right, hope not
<geppy> linux-headers-2.6.10-4-386 is broken
<geppy> It tries to make the symlink /usr/src/linux in whatever folder you happen to be in when you run apt-get
<geppy> so it fails, unless you happen to be in /usr/src
<geppy> which is pretty unlikely
<thully> cool, kubuntu has been one thing I've been really looking forward to (as I normally use KDE instead of GNOME on other distros)
<geppy> That's the only problem, though.  Moving the incorrectly placed symlink to the right directory fixes everything.
<thully> I had an interesting issue when dumping ISO images of Array 5 from burned CDs - if I executed the "eject" command immediately after "cp /dev/hdc hoary-install-i386.iso" finished, my machine locked solid
<mdz> thully: you filed a bug about that less than an hour ago
* Kamion boots amd64 and i386, waits for powerpc to finish rsyncing
<thully> Well - I just thought I would mention it here - didn't know if you saw the bug report yet
<mdz> in general, a bug report is sufficient
<mdz> whether or not we see it within an hour
<Kamion> mdz trawls ubuntu-bugs with considerable diligence
<farruinn> and the mailing list...
<thully> OK - I just thought I'd mention it because it was a crash issue
<Kamion> others of us keep an eye on it as well
<thully> Sorry about this, I just thought it may be worth mentioning because it was so strange and it caused the system to crash 
<geppy> Anyone want to fix that linux-headers package?  It's a one-line fix =P
<Kamion> geppy|waiting_fo: linux-headers-2.6.10-4-386 does not even have a postinst script, so I don't see how it could be creating such a symlink
<Kamion> and the very existence of a /usr/src/linux symlink at all is broken
<geppy|away> Kamion: well, perhaps it's a module-assistant thing
<geppy|away> Kamion: But module-assistant was installing linux-headers-2.6.10-4-386, and the install failed, because the linux-headers-2.6.10-4-386 couldn't create the symlink
<Kamion> module-assistant might well be broken, but we don't support it
<Kamion> module-assistant | 0.6.8ubuntu1 | hoary/universe | source, all
<geppy|away> right
<geppy|away> But it was the linux-headers-2.6.10-4-386 package that was trying to create the symlink
<Kamion> please quote the exact error message, not a paraphrase, thanks
<geppy|away> Kamion:  I've since rebooted, but it was pretty much 'unable to create symlink'
<geppy|away> sorry
<geppy|away> try installing it yourself, see if it complains?
<Kamion> it is 4am here and I'm rather busy doing a Hoary milestone release
<geppy|away> ah, apologies
<geppy|away> By all means, resume your work.
<Kamion> so not really right now, especially if it involves installing stuff from universe :)
<geppy|away> =)
* Kamion boots into amd64 second stage
<zul> module-assitant? never heard of it
<geppy|away> zul:  It's handy for compiling modules;  I use it for realtime-lsm
<zul> hmmm...oh well not in main
<geppy> heh
<Kamion> haggai did fix module-assistant up for Ubuntu kernel packages a while ago
<geppy> Kamion:  I don't think that it's module-assistant, though
<geppy> Karmion: it was the headers package that failed:  I was just randomly mentioning that module-assistant called apt-get
<geppy> well, I fixed it for myself, anyway, I'm done here
<Kamion> I've read the code of the headers package and cannot see how that could happen
<Kamion> linux-headers-2.6.10-4 actually has a postinst, unlike linux-headers-2.6.10-4-386, but it chdirs to /usr/src before doing anything much
<Kamion> I'm trying with linux-headers-2.6.10-4-powerpc; it should make no difference
<zul> night...thanks Kamion for the cd stuff :)
<zul> night mdz 
<geppy> Kamion:  Hrm, it could've been linux-headers-2.6.10-4;  I'll try uninstalling and reinstalling, I guess, seeing if it doesn't work again
<Kamion> like I say, exact error message would mean I could just grep for it rather than guessing
<geppy> Right.
<geppy> Understood.
<geppy> well, it doesn't seem to be giving me the error anymore, despite me having removed the symlink, et cetera
<mdz> zul: night
<geppy> sorry for wasting your time
<Kamion> amd64 installed successfully, i386 about to enter second stage, powerpc box still busy burning CDs
<mdz> Kamion: CD didn't eject on my amd64 install
<mdz> it was still mounted
<elmo> moo
<Kamion> mdz: hm, that worked fine here
<Kamion> server install or normal?
<Kamion> it also worked on i386 (normal)
<mdz> standard install
<mdz> new keyboard logic didn't take on the live CD, but I have a feeling it'll work on the install
<ajmitch> elmo: able to sync pnet, pnet-assemblies, pnetc in universe?
<mdz> Kamion: I have a bad feeling that everyone is going to get a us layout on the live CD
<mdz> Kamion: and that we'd need to rebuild xorg to fix it
<Kamion> mdz: yeah, you seem to be right
* mdz cries
<Kamion> why the rebuild?
<mdz> I suppose I could hack around it in casper
<mdz> but the bug is in xserver-xorg.config
<Kamion> do you not copy over debian-installer/keymap?
<Kamion> doing a GET on that returns blank here
* lamont r3turns
<mdz> I don't copy anything, but passthrough should handle that, no?
<lamont> Kamion: so when I push the kubuntu livecd script, it's going to change the cloop names... do we want to coordinate that?
<Kamion> not on a GET
<mdz> oh
<Kamion> as far as I can tell
<mdz> I guessed it was the 'seen' flag stuff which was busticated
<mdz> db_fget xserver-xorg/config/inputdevice/keyboard/layout seen
<mdz> if [ "$RET" = "false" ] ; then
<Kamion> passthrough is a means for using another debconf instance as a frontend; but GET communicates with the backend, not the frontend
<mdz> I have no idea why it does that
<mdz> daniels: ?
<Kamion> daniels said he'd be away house-hunting for most of today, although SMSable at need
<Kamion> mdz: I imagine that allows for preseeding
<Kamion> mdz: any logs that would indicate what happened to the eject?
<ajmitch> bbl
<Kamion> lamont: please, sometime tomorrow :)
<mdz> Kamion: oh, it ejects _after_ you continue?  isn't that backwards?
<Kamion> er, that was "please coordinate, yes", not so much "please tomorrow" :)
<Kamion> mdz: I get bug reports either way, I can't win
<mdz> Kamion: what's the complaint about the other way?
<Kamion> mdz: the other way, I got bug reports about people who'd left their machine on its side and the CD ejected and fell out on the floor
<mdz> that's their own bloody fault
<lamont> Kamion: OK.  I should be online around 1300 UTC, we should coordinate a swap then, and I can kick the kubuntu livecd build into existance then.  Assuming mdz is OK with the extra few hours...
<Kamion> I tend to agree, but they ranted *shrug*
<lamont> Kamion: speaking of which, why are you still awake?
<mdz> drives designed to be used that way have little clips for that purpose
<mdz> lamont: array 6
<Kamion> lamont: because array CD 6 is not yet done
<mdz> honestly, the other way is correct
<Kamion> I can certainly change it back if you'll back that up during preview freeze
<mdz> currently, it's a race to pull the CD out after it ejects and before the tray gets sucked back in
<mdz> certainly
<Kamion> yeah, that is certainly a problem ...
<lupusBE> daniels, I found the cause : http://bugzilla.ubuntu.com/show_bug.cgi?id=7123 hf I'm going to bed :)
<Kamion> actually it's even more amusing on automatic installs :)
<lamont> Kamion: when the cd falls on the floor, it stays ejected, after all.. :-)
<mdz> Kamion: so is there a simple way for me to copy over the keymap value in casper?
<lamont> anything I can do to help things along, other than shutting up and such?
<mdz> assuming we can confirm that is the problem
<Kamion> mdz: look at one of apt-setup-udeb or initial-setup-udeb, I think
<Kamion> it's not necessarily "simple" but it works; sadly debconf-copydb does not yet work in d-i
<Kamion> (debconf-copydb would be the right answer, long-term)
<Kamion> I get the correct keymap on install
<mdz> ah, chroot debconf(1)
<Kamion> lamont: if you feel like testing, that'd be good, but I don't think I'm going to be rebuilding anything bar dire emergency
<mdz> yeah, I do too
<mdz> for the first time ever
<Kamion> hooray
<Kamion> i386 install good, powerpc in archive-copier
<mdz> Kamion: do I need to specify a real package as the owner when doing this?
<Kamion> 'd-i' is traditional
<mdz> even in the target system?
<Kamion> yes, that's what base-config does
<Kamion> the owner is basically a garbage-collection token
<Kamion> hm, it would be nice to have a more fine-grained progress bar in apt-setup-udeb, so that it looks like it's actually doing something
<Kamion> and there's a bit where it's running apt-cdrom that needs another progress bar (bit awkward for it to be the same one)
<mdz> casper 0.47 uploaded
<mdz> Kamion: base-config seems to set -o base-config, which is why I asked
<Kamion> mdz: where does it do that?
<mdz> jeffm [to mdz] : not sure if you ever incorporated my macio hotplug patches, but they're in -mm now
<mdz> jeffm [to mdz] : well, apart from one fix, they've got benh's blessing
<Kamion> cool
<mdz> too late for hoary, I think, unfortunately
<Kamion> sorry I dropped the ball on that one
<mdz> it was a low priority
<mdz> you had better things to do :-)
<mdz> I'm glad it has its hooks in upstraem
<mdz> upstream
<Kamion> hm, I should time this kickstart install
<mdz> elmo: if you could bless kubuntu-live, since you happen to be around...
<lamont>    599750656 100%   15.83MB/s    0:00:36  (2, 58.3% of 12)
<lamont> that's a bit better.
<lamont> just wish I had that size pipe to the internet. :-(
<Kamion> c. 100 seconds from boot to installing base system
<mdz> Kamion: we should do something about that RECOMMENDED BUT WILL NOT BE INSTALLED
<lamont> Kamion: which images are worth me downloading now, and which ones are you regenerating?
<Kamion> mdz: I'm already using --without-recommends ...
<mdz> Kamion: on the language packs?
<Kamion> lamont: anything in daily/current/ or daily-live/current/
<mdz> I have no idea if that suppresses it or not
<lamont> Kamion: are you just regnerating live or install or both?
<Kamion>                 DEBIAN_PRIORITY=high aptitude --without-recommends -y \
<Kamion>                         install "language-pack-$lp" || true
<Kamion> lamont: no intention of regenerating anything else
<lamont> woot
<mdz> Kamion: no?
<farruinn> Kamion: do you know offhand if the initrd on B&W G3's is working with recent hoary install cds?
<mdz> you don't think we should fix this keymap thing on the live CD?
<farruinn> if not I could test
<Kamion> hm, I suppose
<Kamion> farruinn: not offhand, no
<mdz> fix is uploaded, not built yet
<Kamion> but that means staying up 'til 6am or something
<mdz> I could do a followup release of the live CD
<mdz> though I don't know how to work the publishing bits
<Kamion> it should probably be dropped into the same directory
<mdz> a by-hand sort of thing anyway, then?
<Kamion> that's how it works anyway
<Kamion> you publish daily, then you publish daily-live over the top of it :)
<Kamion> anyway, I'll just stay up, I think the night's pretty much dead anyway
<Kamion> have you tested the casper change?
<mdz> I faked it
<Kamion> ok
<mdz> I'm going to do a proper test now, but I didn't wait before uploading it
<mdz> it's 95% cut-and-paste from apt-setup-udeb
<mdz> oh, hell
* mdz uploads 0.48
<Kamion> ?
<mdz> there was a bug
<Kamion> from the timestamp here it probably missed cron.hourly
<Kamion> this sort of thing is why separate daily and daily-live is useful, btw :-)
<mdz> -rw-rw----  1 mdz mdz 302 2005-03-03 05:03 casper_0.48_source.upload
<Kamion> s/useful/still useful/
<Kamion> powerpc install good
<mdz> Kamion: honestly, all I care about is that they get published together
<Kamion> you mean in /daily/?
<Kamion> or releases?
<mdz> daily
<Kamion> hm
<mdz> that's what my babbling about joining them was about
<Kamion> I suppose I could hardlink images around or something, if you were only building one
<Kamion> yes, I know
<mdz> amd64 and powerpc installs successful here
<Kamion> it's still tricky to support a partial build
<jdub> hey hey hey
<mdz> amd64, powerpc and i386 installs successful, modulo keymap bug
<Kamion> 12:20 from boot to first reboot, kickstart
<mdz> jdub: you're just in time to help test
<jdub> rock
<Kamion> need a faster machine for that test :)
<jdub> how's 6?
<jdub> should i sync against current daily?
<Kamion> getting close to living up to its name in terms of am GMT
<Kamion> jdub: yes please
* jdub updates i386 and powerpc
<jdub> talk went well
<jdub> got a great response
<lamont> keymap affects live or install or both?
<Kamion> lamont: live only
<lamont> ok
<Kamion> keymap worked sensibly on powerpc install too
<lamont> ia64 live went poof?
<Kamion> uh, except it gave me pc105/gb on powerpc
<Kamion> no macintosh model or anything
<mdz> did that actually work?
<Kamion> appears to have done
<Kamion> I bet some stuff is weird that I'm too tired to notice right now
<Kamion> probably affects non-gb people more
<lamont> mdz: I withdraw my comment about ia64 live.
<Kamion> but they were getting an incorrect keymap beforehand :P
<lamont> it's ETHOMBOT
<Kamion> yes, mozilla-firefox crash
<lamont> yep
<Kamion> mdz: will you be able to test the new lives? I'll probably only be able to manage i386, I'd prefer to spend the time writing the release announcement
<mdz> Kamion: yes, I will
<Kamion> ok, thanks
<mdz> testing the latest casper fix now
<mdz> didn't seem te work
<mdz> to
<jdub> mdz: 'te' is a bit irish, easier for Kamion to understand
<jdub> hrm, harsh rsyncage
<mdz> that would be really funny if we weren't trying to make a release happen
<mdz> Kamion: you really don't want to stay up for this
<mdz> it's going to be a long night even for me, I think
<Kamion> I expect to be back around 9am, since Kinnison's working from my place tomorrow, although I may nap during the morning
<Kamion> shall I just do the announcement as soon as I get back?
<Kamion> kickstart install: 24:45 start to finish, one piece of interaction for X video modes
<Kamion> would be nice to speed that up
<mdz> I faked the test a bit too hard
<mdz> ok, 0.49 has a rather better chance of working
<mdz> Kamion: if you really want to wait and do a joint live/install announcement, I guess
<Kamion> mdz: yeah, it would be nicer
<Kamion> I'll disable the normal daily cron jobs
<mdz> I'll hopefully have tested live images within an hour
<mdz> I'll email
<lamont> mdz: 7109 - doesn't affect hoary (file order is good) - do we want to downgrade that and just leave it for the next emacs21 upload?
* mdz wonders how evil it would be to copy in a hand-built casper udeb to the archive on little and build from that
<mdz> it'd save me an hour of waiting for the archive to receive it
<lamont> how clean is the build environment?
<mdz> it's an arch: all package which does little more than dh_install; the build environment is all but irrelevant
<lamont> I would leave that decision up to the CTO then. :-)
<mdz> I'm not sure that I could live with myself
<lamont> I know what you'd do to me if _I_ did it... :-)
<mdz> accepted at 0525
<mdz> when will it be where little can sync it?
<lamont> 0533 source hits the buildds, shortly thereafter it'll get uploaded.  If you just want the .deb early, I can publish it on the buildd for you to grab from little
<lamont> otherwise, 0603 it'll hit jackass in .deb form
<mdz> workrave is pissed anyway
<mdz> back at ~0603
<crimsun> if anyone's around, I have two lintian questions: 1) how critical is the "binary-without-manpage" warning, and 2) how critical is the error "menu-icon-too-big"?
<Kamion> binary-without-manpage is something you should fix at some point, but it isn't immediately urgent.
<Kamion> menu-icon-too-big, dunno.
<crimsun> ok. The latter error is: ... 48x48 > 32x32
<Kamion> I suspect some menu implementations would have trouble with the icon in that case. Try running lintian-info over the output./
<Kamion> see /usr/share/doc/menu/html/ch3.html#s3.7
<crimsun> thanks.
<crimsun> hmm, interesting. mozilla-firefox also has that error.
<froud> thom: don't worry about the OMF categories patch. It has already been done. Thanks.
* froud sends African Greetings
* lamont glares at his 2% complete rsync
<lamont> printer PSC-2400 now printing PSC-2400-27.  enabled since Jan 01 00:00
<lamont>         USB port busy; will retry in 30 seconds...
<lamont> damn USB priters
<mdz> hmm, no casper 0.49 yet
<mdz> built at 0537
<lamont> Mar  3 05:40:02 buildd-mail: casper has been installed; removing from upload dir
<Kamion> mdz: it's there on jackass, probably just mirroring
<lamont> and installed at 0540
<lamont> wb hasn't finished yet, so it may or may not be in the packages files on jackass either
<lamont> wb updated done
<lamont> depending on where you sync from, it's good
<mdz> syncing again
<Kamion> not yet
<Kamion> we sync from auckland
* mdz taps his foot impatiently
<pvh> Is there any way to get more changelog info from an update than "sync with upstream"?
<Kamion> mdz: synced, go for it
<mdz> pvh: yes, by reading the previous entries in the changelog
<pvh> mdz: Ahh!
<pvh> mdz: Synaptic filters out the rest by default.
<pvh> mdz: Or so I conclude from my scant evidence.
<mdz> ok, cron.daily-live running
<Kamion> i386 server install's good
<pvh> mdz: Thank yo.
<Kamion> I'm going to catch some sleep; back ~0900 probably
<Kamion> I have the release announcement written
<lamont> interesting... after I run xsane, I have to stop/start (or maybe just restart?) hpoj
<lamont> before cupsys can see the printer again
<Kamion> http://riva.ucam.org/~cjwatson/tmp/array-cd-6 if anyone wants to proofread / suggest other stuff / whatever
* Kamion &
<mdz> night, Kamion
<mdz> lamont: daniels has the same problem with his psc
<lamont> ah, good. known then
<lamont> bouncey stub
<mdz> live CDs check out
<stub> resetting my sessions so update notifier starts as expected  - could be a problem for hoary upgraders
<pitti> Morning
<froud> mdz: ok I have the omf/scrollkeeper stuff working. I'm now just waiting for enrico do fix his packaging stuff to include proper registration. On my system I can see the About Ubuntu and Release Notes
* lamont looks at the clock, and at the not-so-great progress of his rsync.
<lamont> definitely should go into town tomorrow to fetch images
<lamont> mdz: you need anything else from me before I fall into bed?
* lamont sleeps
<daniels> mdz: pong
<mdz> lamont: nope
<mdz> froud: sounds good
<mdz> daniels: why does xserver-xorg.config check the seen flag on the keyboard question?
<daniels> mdz: to decide if we should use what's already there (what the user selected), or detect it again
<daniels> mdz: to be honest, xserver-xorg is pretty fucked in a couple of places in terms of that sort of thing because probing screwed things up a bit
<daniels> mdz: luckily the damage is largely confined, but I need to go through that at some stage
<dholbach> goood morning
<pitti> Hi dholbach 
<pitti> mdz: do you want to review security changes to hoary from now on? because of preview freeze?
<dholbach> hai pitti
<pitti> daniels: here?
<Alessio> sorry, what's Matthias Urlichs's nickname?
<pitti> Alessio: smurfix
<sabdfl> smurfix
<dholbach> Alessio: smurfix
<Alessio> tx :)
<sabdfl> morning all
<Alessio> morning all
<dholbach> good morning sabdfl 
<pitti> hi sabdfl 
<sabdfl> pitti!
<amu> elmo: please sync libassuan
<amu> hi sabdfl 
<sabdfl> hey amu
<doko> amu: elmo currently is in UTC+6(?) timezone ...
<pitti> Kamion: do you have time for an USN review?
<pitti> jdub: ping
<Kamion> pitti: I'm not sane enough for a USN review right now :)
<pitti> Kamion: trouble with array6? :-)
<pitti> Kamion: no worries, as soon as I catch daniels or jdub, I ask them
<Kamion> pitti: array-6 going out in just a moment
<pitti> cool
<pitti> Kamion: btw, you _did_ sleep a bit tonight, did you?
<Kamion> pitti: about two hours
<pitti> D'oh
<jordi> Kamion: duude :(
<Kamion> Debian powerpc 2.4 kernels going to hell in a handbasket didn't help; still trying to sort that out
<pitti> Moin doko
<doko> just a reboot, testing different ISDN setups ;)
<thom> froud: it's on the list, i sent it last night *shrug*
<seb128> are uploads still frozen for array 6 ?
<Kamion> seb128: no; we're in preview freeze now though
* Kamion releases Array CD 6
* Treenaks cheers
<daniels> Kamion: congratulations :)
<Keybuk> seb128: how come the jimmac cursor theme was dropped?
<seb128> Kamion: new vte with a bunch of interesting patches in it, we want it :)
<seb128> Keybuk: ask jdub: http://bugzilla.ubuntu.com/show_bug.cgi?id=6172
<mvo> seb128: is a changelog of the vte changes available?
<Keybuk> jdub: same question to you, Number Two. :p
<seb128> mvo: http://ftp.gnome.org/pub/GNOME/sources/vte/0.11/vte-0.11.12.news
<mvo> seb128: thanks!
<seb128> np
<Kamion> thom: around to sort out array 6 torrents?
<Kamion> I'm just generating the metafiles now
<mvo> hi rburton 
<rburton> hi mvo 
<froud> mvo: any news from michael
<mvo> rburton: I checked g-a-i and synaptic on debian yesterday and can reproduce the hang. but only on debian with python2.3. have you tried to run it with python2.4?
<rburton> nope
<rburton> typical :/
<mvo> rburton: could you please :) ?
<mvo> froud: no news yet
<mvo> rburton: not sure it fixes it, but it may be worth a try :)
<froud> mvo: :-( me neither
<mvo> froud: I'll let you know as soon as I hear something from him
<froud> mvo: cool
<froud> mvo: do you think we can get the docs for update-manager into release on time
<froud> mvo: or is this going to be for grumpy
<Kamion> thom: torrents generated, syncing to mirrors
<thom> Kamion: cool
<mvo> froud: I think we can, we have some time until hoary-final and doc updates should be ok
<froud> ok
<mvo> froud: we don't need too much stuff, just some basic documentation is enought for the start I think
<froud> mvo: that's fine
<Mithrandir> Keybuk: I loved the discussion on debian-devel between you, doogie and me. :)
<Keybuk> yeah, taht was fun
<ogra> bradb: ping
<sivang> good brunch all :)
<mvo> Keybuk: is the "error-reporting" diff I send you in one of your arch branches? I would like to answer "Henning Glawe" on d-d but I don't want to make false statements
<Keybuk> error reporting diff?
<Keybuk> got a msg-id/bug#/patch name?
<Keybuk> I thought you'd only sent me status-fd so far
<thom> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=169051 was what i was seeing with nautilus last night
<mvo> Keybuk: yes, that was what I wanted to say :)
<mvo> Keybuk: and it also reports errors 
<Keybuk> no, it isn't in any of my branches yet
<Keybuk> could you file a wishlist bug in Debian's bts to remind me?
<mvo> Keybuk: sure, will do
<Keybuk> [DPKG] [CONFFILE]  include support for conffile reporting on status-fd and useful error reporting
<Keybuk> should do
<seb128> thom: k
<Keybuk> which does remind me, that I should get 1.13.1 out today
<Keybuk> it's been sitting in my todo box for a few weeks now
<Keybuk> if you're quick, I'll merge it in :p
<mvo> Keybuk: I'll have to dig out the patch first, but I'll try to be quick :)
<Keybuk> isn't it in your arch repo?
<Keybuk> (michael.vogt@canonical.com--2004--laptop/dpkg--stable-mvo--1.10)
<mvo> Keybuk: it is, thanks for telling me which one (I have three)
<sivang> has anyone seen pitti?
<enrico> hello.  does someone know how to write a OMF file so that a link to the document shows up in the default yelp page?
<Mithrandir> daniels: btw, I can still reproduce the "Xorg asks three times on upgrade" problem.  Might be a debconf problem, as the questions are marked as seen in the debconf db.
<thom> enrico: there should be a mail on ubuntu-doc from me about that
<enrico> thom: /me looks for it
<enrico> thom: there is not.  It's possibly awaiting moderation
<thom> possible it needs moderating
<thom> Kamion: torrents should be rocking
<enrico> groan.  I want admin right for that list!
<froud> thom: when did you send it
<froud> thom: can you join #ubuntu-doc and explain it
<thom> froud: last night
<thom> i could just subscribe and resend, i guess
<mvo> anyone knows about this baz error:
<mvo> baz diff scott@netsplit.com--2005/dpkg--stable--1.10
<mvo>     arch_valid_package_name (name, arch_maybe_archive, arch_req_package, 1)
<mvo> PANIC: exiting on botched invariant
<sivang> thom: are you subscribed to the list? because if not, we didn't get it 
<froud> thom: up to you
<Keybuk> mvo: baz diff $(baz revisions -r scott@netsplit.com--2005/dpkg--stable--1.10 | head -1)
<Treenaks> thom: 1 IPv6-enabled peer for the torrent running :)
<thom> sivang: no; is no-one moderating -doc?
<Kamion> thom: bonus, thanks
<sivang> thom: there is, but I don't think he is on right now, and have no idea when he I will see him to tell him about it
<enrico> thom: it's moderated by jdub and john hornbeck.  The latter isn't very active anymore. 
<thom> right, i just subscribed *mutter*
<mvo> Keybuk: here is a new one: $baz merge scott@netsplit.com--2005/dpkg--stable--1.10--patch-11
<mvo> * merge by delta(scott@netsplit.com--2004/dpkg--stable--1.10--patch-7,scott@netsplit.com--2005/dpkg--stable--1.10--patch-11)[/home/egon/devel/dpkg/dpkg--stable-mvo] 
<mvo> * performing merge
<mvo>     arch_valid_package_name (name, arch_maybe_archive, arch_req_package, 1)
<mvo> PANIC: exiting on botched invariant
<thom> sivang, enrico, etc: it's on the list
<Keybuk>  Go Bazaar, It's Your Birthday
<froud> thom: pls read my response
<enrico> thom: thanks!
* sivang puts on his glasses and looks again
<froud> thom: we have the docs being displyed in yelp but they show in the category "Other Documentation" we want them to be on the default page
<sivang> thom: found it, sorry
<thom> you'll need to work with seb to change how yelp categorises stuff then
<froud> i see
<froud> seb128: can you help
* froud sends thhhanks to thom 
<mvo> Keybuk: problem solved, remvoing the pristines worked. I had to fire up tla to tell me so :)
* Keybuk is frowning heavily at baz at the moment
<Keybuk> all I did was commit, and it's been spewing "Good signature from" at me for an hour
<Keybuk> I guess it's forgotten/lost/didn't have its ancestry
<seb128> thom: thanks :p
<thom> seb128: any time mate ;-)
<sivang> froud: we need another catagory, "Ubuntu Documentation" or something
<seb128> froud: what's the issue ?
<froud> we have docs registered in yelp
<mvo> Keybuk: haha
<sivang> seb128: we need another toplevel catagory in scrollkeepr_cl.xml probably, so the docs would be accessible from there.
<sivang> seb128: (from my poor understanding)
<seb128> any patch is welcome
<mvo> Keybuk: it's good to know that I'm not the only one having trouble with it sometimes
<froud> seb howto do it
<seb128> no idea
* Keybuk just uses tla
<froud> seb128: we want the Ubuntu Docs to be displayed in the default yelp apge
* mvo considers a switch
<sivang> froud: I think an Ubuntu Docs catagory from the main page would be best no?
<froud> seb128: b what I see in scrollkeepr_cl.xml is not the default page listing
<seb128> as said patches are welcome, but I'm really bug flooded and busy atm so don't count on me to do the hack today
<froud> seb128:  so where is the default page generated from once I know this I will patch it
<seb128> src/yelp-toc-pager.c I guess
<sivang> froud: how do you know this is not the default page?
<seb128>         if (!xmlStrcmp (id, "index")) {
<seb128>             xmlNodePtr new = xmlNewChild (node, NULL, "toc", NULL);
<seb128>             xmlNewNsProp (new, NULL, "id", "Man");
<seb128>             xmlNewChild (new, NULL, "title", _("Man Pages"));
<seb128>         }
<seb128> 
<seb128> that's for the Man Pages category
<froud> seb128: that's the yelp src not the content data. ok leave it will potter aaround til we find it
<seb128> and data/man.xml in yelp too
<Keybuk> mvo: http://arch.netsplit.com/scott@netsplit.com--2005/dpkg--devel--1.13--patch-79
<enrico> mdz: froud told me you asked me about the next docteam meeting
<enrico> mdz: froud told me you asked for me about the next docteam meeting
<mvo> Keybuk: cool, thanks!
<enrico> mdz: We should also discuss documentation freeze dates
<Keybuk> mvo: I used your mvo@ubuntu.com address in the ChangeLog and added a copyright line for Canonical -- I figured that's about the right way to credit that?
<mvo> Keybuk: yes, thanks
* Kamion builds a Kubuntu powerpc CD
<Astharot> ciao
<Kamion> amu: have you talked with anyone about promoting libjpeg-progs and libtiff-tools to main? konq-plugins and kfax respectively seem to need those
<Kamion> now to figure out how/where to publish Kubuntu CDs ...
<opi> Kamion: it is ready?
<Kamion> well, they're sort of building. they won't install yet.
<opi> Kamion: when I asked last time it was still ,,not to use on people'' state
<Kamion> I wouldn't say "ready" as such yet, but getting there
<Kamion> I'm only doing the cdimage side of things, I have no clue what Kubuntu itself actually looks like
* Kamion decides on http://cdimage.ubuntu.com/kubuntu/ for now
<Kamion> might move
<amu> Kamion: those are still in universe? 
<Kamion> amu: yeah
<Kamion> they're the two uninstallables on a powerpc CD (well, also kdeaddons and kdegraphics, but those are just metapackages so I imagine they're the knock-on effect)
<Keybuk> mvo: on its way into experimental now
<Kamion> man, bootloader configuration handling in debian-cd is such a mess when you're trying to do all architectures at once
<amu> Kamion: added those 2 packages on my todo 
<sivang> has anyone seen seb128 ?
<sivang> and pitti ?
<Kamion> amu: thanks. should have initial test CDs for you in a couple of hours
<amu> Kamion: cool, rocks
<Kamion> although ia64 won't have the necessary preseed for a while, some other stuff to clear up there first
<Kamion> don't imagine you care too deeply just now
<Kamion> cjwatson@little:~$ PROJECT=kubuntu CAPPROJECT=Kubuntu cron.daily
* Kamion holds breath
* amu cross the fingers 
<Kamion> hm, crap, the logs will go to the wrong place, better fix that first
<doko> hmm, why is ubuntuforums.org allowed to post on the ubuntu-devel list?
<ogra> doko: ...it is since ages...
<ogra> doko: ah, no -users that is, sorry
<amu> kvim is also in universe 
<doko> noisy ...
* Kamion tries that again
<opi> amu: http://yzis.org -- have you seen it?
<Riddell> opi: it's not ready yet plus it needs patches to other kde  programmes
<Riddell> opi: plus i'm not a vi user, but otherwise a good idea
<opi> Riddell: I'm a VIm user :)
<opi> Riddell: I'm trying to build it on Hoary now
<ogra> where is the gtk port ?
<opi> of yzis?
<ogra> ;)
<amu> opi: heh looks strange
<opi> amu: I need to give it a spin to say how it feels :)
<opi> with xorg, is there a -dev package with headers?
<opi> I can't find it
<amu> hmm it's like overkill, but there are guys around, they write their mails with mutt and use openoffice' swriter as EDITOR :)
<opi> haha
<opi> ;D
<opi> But I'd love to use VIm with KMail
<opi> VIm as KPart
<dredg> i'd love to use evolution with vim. i tried it a couple of years ago with some hack i found.
<dredg> the results were.. horrific
<Kamion> opi: there're loads of -dev packages, one per library
<opi> Kamion: I've found a meta package ;)
<opi> Kamion: this system is a gcc virgin ;)
<tseng> is there an "official" plan to get mono into main? GrumpyGroundhog goals talks about beagle "integrated"
<tseng> I cant tell who added it.
<thom> tseng: well, we need to get mono 1.{1,2} so it's available for all arches
<thom> and if that works out i think we'll go for it
<tseng> right
<tseng> ok, the debian team is working on packaging and a new spec.. ill be helping get some packages updated and then merged to grumpy
<thom> rocking
<jdub> tseng: (bendy.)
<tseng> bendy = hoary+1
<tseng> ?
<jdub> *almost* officially now
<opi> jdub: what do you need to watch JDubTV? (except for brain damage;-)
<jdub> totem
<tseng> totem-gstreamer actually
<dredg> no... totem-xine works here
<tseng> it told me to use cvs for theora on the console.. maybe after a bit more thinking it actually does
<opi> ok, got totem ;)
<Treenaks> mplayer works fine, too..
<opi> jdub: URI? :p
<jdub> tseng: totem-xine works ok
<jdub> opi: it's not on
<opi> buuuu!
<opi> ;-)
<tseng> hey do one of you gnome dudes know if gnome-terminal has some prefix for Xdefaults
<tseng> or do I really have to use this color wheel
<tseng> bah not a devel question
<sivang> tseng: mono is always using c# right ?
<thom> sivang: no
<opi> yup
<tseng> how do you mean, always?
<opi> thom: no?
<opi> thom: ain't it .NET?
<thom> there are stacks of languages that can target the cli
<sivang> tseng, thom : what languages am I using to write mono programs?
<tseng> ironpython, boo, nermele, c#, vb.net, asp.net ...
<sivang> thom: and the resulting executable is also runnable over win32 api's ?
<tseng> this is the point of .NET, multiple languages one runtime
<ogra> tseng: classpath ?
<thom> sivang: in general yes, assuming you're not using platform specific apis
<tseng> ogra: java?
<thom> ogra: yes, with ikvm
<ogra> tseng: yup....as thom said
<tseng> yeah.
<sivang> thom: so the move in the gnome world is towards mono?
<thom> sivang: for some people
<tseng> the move in the miguel world is towards mono
<ogra> sivang: the move in the ubuntu world is towards python ;)
<rburton> sivang: gnome is sticking with C for the forseeable future
<tseng> its just a bunch of pot stirring fud on news sites quoting miguel
<tseng> "omg i will leave linux forever if you use .NET!!!ELEVEN"
<thom> yeah. that kinda stuff is pretty tragic
<tseng> its a pretty sane idea to ignore anything in a comment or written by Eugenia
<ogra> hehe
<tseng> stick to planet gnome :)
* Mithrandir notes it might be better for his buildd if he actually did update the archive a bit more often than monthly.
<sivang> ok, noted :) just the thought of using .NET over linux is somewhat doubtful, I mean, is .NET is now an ANSI/OMG/ISO standard? 
<sivang> (bah, /me realized this was somewhat out of line questoin and could be considered as trolling)
<tseng> ecma
<sivang> tseng: ah ok, good to know :)
<thom> *aargh* kicks rpm in the head repeatedly
<opi> thom: you need a gun for that
* opi gives a gun to thom 
<thom> pitti: did you want a backtrace of g-v-m killing itself on dbus restart?
<pitti> thom: by all means, yes
<thom> pitti: is there a bug for it? (i looked quickly and couldn't see one, but searching bugzilla is such a waste of time)
<pitti> thom: none that I know of
<thom> k
<pitti> thom: just open a new one or mail me it
<pitti> thanks
<sivang> pitti: oh, glad to see you're back
<pitti> Hi sivang; yes, was away for a bit
<pitti> sivang: any news?
<sivang> pitti: I had no luck using the built in function of g-c-m, I will try using plain g_spawn_sync
<sivang> pitti: but I have more issues, will msg you
<jdub> so the combination of adding powerpc to my mirror, and all the kde stuff in main has made mirroring slightly less fun
* haggai hands jdub a bigger pipe
<ogra> bradb: another ping
<bradb> ogra: hi
<jdub> haggai: more green to go with it, thanks
<ogra> bradb: i'd like to invite you: https://www.ubuntulinux.org/wiki/MOTUMeeting
<ogra> bradb, since we will talk about universe wrt malone
<bradb> ogra: thanks, we discussed this on launchpad@ yesterday. i'm definitely looking forward to attending. :)
<ogra> great, thanks :)
<dholbach> bradb: cool
<Treenaks> anyone know of a way to get software on a palm without the hotsync cradle?
<Mithrandir> Treenaks: infrared
<Mithrandir> or possibly BT on newer models
<Treenaks> Mithrandir: I don't have any other ir devices around
<ogra> Treenaks: with a morse taper.....hacking in 0100100011101001 etc.....?
<dredg> Treenaks: not much use to you now, but i have a usb cable for my treo that charges and can do hotsyncs when i'm not near a cradle
<Treenaks> ogra: yeah, good luck, morse 75k without error
<ogra> hehe
<Treenaks> ogra: I found a ssh client for my palm :)
<Treenaks> ogra: but I can't get it on my palm in time
<lamont> morning
<ogra> Treenaks: i'll schedule the next meeting an hour later if austraila and NZ are fine with it
<Treenaks> ogra: as someone once said, we need a rotating schedule
<opi> when there will be a UbuntuConf in Germany? :)
<opi> Australia's a bit far ;)
<ogra> Treenaks: i asked extensively during the week, and everybody seemed fine
<sivang> ogra: it's today right?
<Treenaks> ogra: ok, I'll try to find a way.. once I have ssh on my palm it won't be a problem :)
<ogra> opi: i thought about making up a hacking camp in summer.....
<ogra> sivang: yup
<Treenaks> ogra: there's debconf in july in finland
<opi> ogra: supreb :-)
<Treenaks> ogra: and guadec in may
<ogra> Treenaks: finland isnt germany
<Treenaks> ogra: guadec is in Germany
<ogra> Treenaks: i know....
<ogra> Treenaks: i thought more about a ubuntu specifi thing :)
<ogra> specific even
<ogra> camping in the eifel ....and wireless hacking....
<ogra> we have nice camping grounds around here: http://www.grawert.net/gallery/pano/
<Treenaks> ogra: where is "here" (city)?
<ogra> Treenaks: between aachen and the nuerburgring....middle of nowhere.....
<Treenaks> ogra: ah close to .nl :)
<ogra> my village is called rohr (which actually means pipe in english *g*)
<ogra> 500 inhabitants
<jdub> rohr power!
<ogra> yay
<opi> ogra: supreb x2, we have bus to aachen! :)
<opi> ogra: from our city 
<ogra> its still about 70 km from there
<sivang> Treenaks: what time is the motu meeting?
<Treenaks> sivang: 1630utc
<sivang> Treenaks: ok
<ogra> sivang, https://www.ubuntulinux.org/wiki/MOTUMeeting
<jdub> boh
<jdub> locales-gen running for every language-pack
<jdub> hey seb128 
* jdub is doing meaty upgrade atm
<jdub> oh no
<AndyFitz> g'day jdub
<jdub> now it's doing it for language-pack-*-base
<jdub> hey AndyFitz 
<sivang> hey again seb128 
<seb128> hello jdub 
<seb128> re sivang 
<Keybuk> hmm, that sounds like it installed those in the wrong order <g>
<Keybuk> in fact, that definitely sounds like you got them in the wrong order
<Keybuk> la la la la
<jdub> so on that upgrade, it did locale gen 4 times
<jdub> although it hasn't finished
<jdub> and it might do it again
<jdub> ;)
<Mithrandir> Keybuk: is it a feature that libtool .la files include the full path of the .la files they depend on?
<Keybuk> Mithrandir: yes.
<Mithrandir> Keybuk: that means multiarching stuff is a lot harder than it should be, and will cause the RMs pain, I can imagine.
<Mithrandir> but if it's intentional, it's intentional..
<Keybuk> if you were maintainer, you could fix it :p
<bob2> hahaha
<Mithrandir> I would rather stab myself with a blunt spoon
<bob2> you're so subtle at trying to offload packages, scott
<Keybuk> bob2: shut up and fix your bugs
<bob2> or what? you'll upload libtool in my name?
<Keybuk> yes :p
<bob2> and I followed up to them all already!
<Keybuk> fancy following up one some of mine?  I have _plenty_ to go round
* lamont hands Mithrandir a blunt spoon, points at Keybuk meaningfully. :)
<Mithrandir> *chuckle*
<Keybuk> lamont: would you like to maintain libtool?
<Mithrandir> lamont: but then I would have to take over his packages.
<lamont> Keybuk: only posthumously
<ogra> jdub: why didnt you take rburtons clearlooks package....it has far more colors....
<jdub> ogra: 0.2.2 vs. 0.3
<tseng> jdub: im looking in his 0.3
<tseng> it has colors
* jdub is not exactly a fan of theme overload
<jdub> but i'll chat to him about it
<tseng> well
<tseng> its worth at least pulling the Human varient
<jdub> we won't be using that
<ogra> jdub: we could say its his first motu package ;)
<ogra> rburton: if you are interested in MOTU :)
<rburton> what who what why?
<rburton> jdub: yeah, i pushed 0.3 into NEW
<rburton> lunch, bbiab
<ogra> heh
<svenl> mmm, is hoary's choose-mirror currently broken ? 
<svenl> it tries to get http://${countryprefix}archive.ubuntu.com(null)/dists/hoary/Release, and fails.
<ogra> null ??
<svenl> well, also don't know where that comes from.
<ogra> should be /ubuntu instead
<svenl> mmm.
<Kamion> svenl: d'oh
<Kamion> that would be my fault; but countryprefix really should be getting substituted ...
<Kamion> I'll have a look, thanks
<zul> hey
<svenl> Kamion: i run it by hand, do i need to call some special args to the kernel, that yaboot.conf adds ? 
<Kamion> svenl: no, our yaboot.conf's append line is basically empty
<svenl> Kamion: append="--" mmm, doesn't seem so. BTW, what is the -- for ? 
<svenl> Kamion: will using yesterdays initrd work or something ? 
<Kamion> debian-installer-utils/user-params and some magic in yaboot-installer
<Kamion> I made that choose-mirror change on 1 March; the 1 March initrd should be fine
<Kamion> (at least, free of that problem)
<lamont> Kamion: when do you want to do the livecdrootfs change?
<lamont> that is, am I free to break it now?
<svenl> Kamion: can i fix it by hand on a running u-i system ? 
<Kamion> lamont: go for it
<Kamion> svenl: I honestly don't know, haven't tried it out yet, sorry
<svenl> Kamion: no problem.
* Kamion grabs a netboot mini.iso
<svenl> Kamion: netboot images are for netbooting, not for using with mini-isos :)
<svenl> Kamion: how comes http://archive.ubuntu.com/ubuntu/dists/hoary/main/daily-installer-powerpc/ shows only 20050302 and 20040224 ? 
<Kamion> svenl: there was a period when the dailies weren't being built on powerpc due (IIRC) to the buildd in question being down
<Kamion> it's been corrected
<svenl> Mmm.
<svenl> so, i have to go to the february 24 install, right ? 
<lamont> Kamion: new cloop name will be:  ~buildd/livecd/current/livecd.{kubuntu,ubuntu}.cloop
<lamont> 'k?
<Kamion> svenl: guess so, or wait for me to fix it :)
<lamont> likewise for manifest
<Kamion> lamont: updated
<Kamion> so not livecd-current any more?
<lamont> well, that link has been alive but depricated for a while now.. :-)
<lamont> there was directory bloat, but I'd already given you the name
<AndyFitz> night all
<lamont> seemed a shame to make you change, so I made the link stay valid
<lamont> since you have to change anyway, figured I'd retire it.
<Kamion> well the livecd.ubuntu.cloop name is new, by the looks of it
<Kamion> but yeah
<Kamion> lamont: I've made it grab livecd.$PROJECT.cloop, so with a bit of luck Kubuntu live CDs will just work
<lamont> awesome
<lamont> and manifest? :-)
<Kamion> same
<Kamion> svenl: yow, segfault here, I guess I was tired when I wrote that code ...
<svenl> Kamion: :)
<opi> svenl: :)
<daniels> Mithrandir: just for modes, right?
<Mithrandir> daniels: no, mouse probing and everything
* lamont grumbles at ia64
<pitti> Morning lamont
<Kamion> weirdness, it's doing a GET mirror/ftp/countries
<Kamion> despite the protocol being http
<daniels> Mithrandir: *grunt*
<Mithrandir> daniels: note that this installation has never actually been installed as an ubuntu system, it's actually an old RH6.2 system which has been hacked and hacked and hacked, so something _might_ be a bit funky somewhere.
<Mithrandir> daniels: also, xorg.conf has been changed, so it shouldn't ask those questions anyhow
<daniels> Mithrandir: right
<mvo> Kamion: just finished a testinstall of array-6 works like a charm here on my test-machine :)
<Kamion> cool
<mvo> Kamion: oh, I just noticed that my keyboard under X is us, under the console de. I installed with language english, but keyboard german. should I report this against as bug against X?
<Kamion> mvo: yes please, that's supposed to be fixed now
<Kamion> hmm, choose-mirror.templates is a bit hosed in places, I wonder if that has something to do with it
<Riddell> how do I start gnome?  (equivalent of startkde)
<Treenaks> Riddell: gnome-session ?
<jbailey> Kamion: The hack I did for getting initrd-tools to set RESUME automatically relies on the swap partition being mounted at the time. (I'm parsing /proc/swaps) - svenl did an install and it wasn't set.  Is swap not mounted during the install?
<Riddell> hmm "gnome-session: you're already running a session manager"  running in a chroot in Xnest
<Treenaks> Riddell: clean your environment?
<svenl> I have a swap entry in /target/etc/fstab
<Riddell> Treenaks: how do I do that?
<Treenaks> Riddell: I don't know, it's your environment
<jdub> Riddell: look at the output of export :)
<svenl> jbailey: i am not sure swap is enabled during base-install.
<Kamion> jbailey: it should be, the installer tries to autouse swap
<Kamion> that's important for lowmem installs
<jbailey> Hmm, that's what I had assumed.
<lupusBE> daniels, can you plz look at this https://bugzilla.ubuntu.com/show_bug.cgi?id=7123
<jbailey> Kamion: Have you done a test install with array6 yet?  If yes, can you check your /etc/mkinitrd/mkinitrd.conf file to see if RESUME= is set at the bottom of it?
<Riddell> jdub: what do you mean?
<seb128> hum, xorg crash
<jdub> Riddell: run export. look at the output.
<pitti> lamont: ping
<pitti> Kamion: are today's daily and array 6 the same images?
<Kamion> pitti: yes
<pitti> ah, cool
<pitti> I accidentially downloaded the daily
<Kamion> jbailey: I've done lots, not sure if any are still intact :)
<Kamion> jbailey: probably easier for me to just fire off another quick amd64 install ...
<jbailey> Unless, has anyone else here done an install off of array6, or in the last day?
<Kamion> jbailey: I can do one easily, it's no hardship
<Kamion> will take half an hour or so counting the CD burn
<jbailey> Kamion: Sure.  Just that otherwise an answer might be here in 30 seconds. =)
<Kamion> true :)
<Kamion> actually I only need to do the first stage to answer your question
<jbailey> Kamion: Cool, thanks.
<jbailey> Kamion: Aside from, is it safe to do the hotplug upload without fubaring you now?
<svenl> Kamion: on the pegasos/ubuntu install, the nobootloader message doesn't seem to find the right kernel to use.
<Kamion> jbailey: yep, but we're in preview freeze now, you'll need to clear it with mdz/jdub
<Kamion> svenl: hm, ok, I'll have a look and see if nobootloader needs technical branding
<svenl> Kamion: not that it is any important, since there is no vmlinuz, but maybe you rather disable that message for hoary.
<jbailey> Kamion: mdz asked for the patch, but I'll double check.  Thanks for the reminder.
<Kamion> svenl: I'd like to get at least the mkvmlinuz support in for hoary, but ...
<Kamion> jbailey: ah, ok
<Kamion> it'd save me hassle and get me another test machine :-)
<svenl> Kamion: ah, that would be neat.
<svenl> Kamion: mkvmlinuz is really clean and transparent to the rest of the kernel stuff. Jens did a great job on it.
<svenl> Am going to see if out yaboot supports 4.5MB compressed initrds now.
<Kamion> I'm not sure I'll be able to get the mkvmlinuz package into supported now, though, let alone onto the CD; will have to talk with folks
<svenl> Kamion: as long as the kernel-image include the support files, it should be ok.
<Kamion> won't work during the install though without mkvmlinuz in supported
<Kamion> although I guess you could wget it by hand
<svenl> Kamion: yep.
<svenl> Kamion: or preseed it or whatever.
<Kamion> svenl: oh, in fact no vmlinuz would be why nobootloader can't find the right kernel
<Kamion>                 kernel=`ls /target/boot/vmlinuz-2.* | sed -e 's%/target/boot/%%'`
<svenl> Kamion: i think so too.
<mdz> jbailey: the sg thing?
<mdz> jbailey: if so, yes, that's fiine
<svenl> BTW, are usernames with '-' in the name illegal ? 
<jbailey> mdz: Thx.
<zul> *sigh* sometimes i want to blow my brains out
<Kamion> jbailey: swap is enabled during base installation, just checked
<svenl> Kamion: how do you check that ? And it is enabled post-partman ? 
<Kamion> svenl: chroot /target swapon -s
<Kamion> yeah, partman turns it on
<svenl> Kamion: oh ...
<jbailey> Hmm.
<svenl> wel, i am no more in the initrd, so ...
<svenl> jbailey: well, yaboot can handle big initrd's so it is a grub2 issue.
<jbailey> svenl: Is there a chance that /dev/${SWAP} doesn't exist?  I do a sanity check that it should be a block device before I put it in.
<svenl> Mmm, would be really neater if the gige driver would not be broken.
<svenl> jbailey: i don't know, let me check.
<Kamion> jbailey: might be devfs versus non-devfs device names
<jbailey> Kamion: Oh ugh.
<jbailey> Kamion: Yeah, certainly is.
<Kamion> jbailey: can you do a mapdevfs in the d-i initrd, or are you running entirely in /target?
<Kamion> confirmed RESUME not set
<jbailey> Kamion: I've just assumed that I'm running in a chroot on the target system.
<Kamion> I'm pretty sure you will be
<jbailey> Kamion: (my tests were basically dpkg --purge --force-depends and then reinstall)
<Kamion> we could have base-installer fill it in for you somehow, but that's a bit ugly
<svenl> Kamion: well, with the 2004.10.29-beta OF, yaboot from disk was perfectly able to boot the vmlinux/initrd kernel post reboot, so maybe we should just aim for that.
<svenl> only problem is the initial boot, but i will fix that.
<Kamion> svenl: kewl, that's excellent
<jbailey> Kamion: I could parse /etc/fstab, too.  The logic I had was parse /proc/swaps and double check that it's really a block device.
<svenl> Kamion: only problem may be in the ofpath stuff maybe, not sure, i don't use the generated yaboot.conf, and place it in /etc/yaboot.conf on another partition.
<svenl> yaboot is copied from a debian partition too.
<Kamion> jbailey: well, /etc/fstab should have been un-devfs-ed, anyway
<jbailey> Kamion: Not for Hoayr obviously, but are you planning on udev love for after?  I have it running nicely in an initramfs.
<Kamion> guess I could check ofpath, the monitor I'd attach to my pegasos is in use though
<svenl> Kamion: i confirm, /target/etc/fstab was ok pre-reboot.
<Kamion> jbailey: we are running udev, just with devfs names
<svenl> Kamion: who needs a monitor when you have serial console :)
* jbailey writhes a bit.
<Kamion> svenl: sadly I don't, I really should ...
<svenl> Kamion: :)
<Kamion> jbailey: it was an easy change to go from devfs to udev but keep roughly the same pathnames; going from devfs names to traditional names was a *whole* lot more work
<svenl> Kamion: is there a plan to remove the devfs name for post-hoary installer ? Or post-sarge for that matter ?
<svenl> Kamion: i suppose you could use /sys or somethign for it.
<jbailey> svenl: I don't know if Debian could do it until pre-2.6 support is removed.
<Kamion> svenl: I'd certainly like to, but I don't really have a plan; it'll probably be a matter of gradually coming up with compatibility layers that understand both, until we can make it use either without anyone noticing
<svenl> jbailey: etch will assuredly drop 2.6 support.
<Kamion> jbailey: it would certainly be possible to abstract away the things that care about the differences, so that they could cope with either.
<svenl> err pre-2.6 that is.
<svenl> Kamion: hehe.
<Kamion> and I think doing it that way is the easiest and best way, you get to make everything keep working rather than trying to have one giant flag day :)
<jbailey> svenl: I'm not certain of that.  2.6 is still a sufficiently crazy target that I don't see pre-2.6 dropped in Debian for ages.  We've had the chat a few times amongst the debian-glibc folks to try and figure out what we should do with threads.
<mdz> lamont: morning
<pitti> Morning mdz
<mdz> hi
<svenl> jbailey: yes.
<Kamion> svenl: on the Debian side, I think moving to udev to get away from the kernel code that's actually liable to be removed really soon is more important/urgent than changing the device names
<lamont> morning mdz
<Kamion> so I'm quite glad we've been able to do that in Ubuntu first; it should be a straightforward merge to make it happen in Debian
<Kamion> I've been fairly careful to make my changes conditional such that d-i can still be built with or without udev
<mdz> lamont: status of kubuntu cloop images?
<Kamion> ha, I was about to ask that
<lamont> mdz: top of the pile, verifying the script now.  Kamion has made his changes
<mdz> yes, I'm pulling down his install images now
<lamont> typing break
<svenl> Kamion: post-sarge though, so we still have a bit of time.
<svenl> Kamion: but yes, testing them in ubuntu first is rather nice, especially as you don't have the pre-2.6 constraints.
<Kamion> svenl: considering that I was still finding bugs caused by the switch to udev up until a week or two ago, I'm pretty glad of that
<svenl> Kamion: :)
<pitti> mvo: I have the same keyboard problem, do you happen to know the bug #?
<svenl> BTW, any chance to get a french mirror on the wanadoo/france-telecom network ?
<svenl> where is fr.archive.ubuntu.com located anyway ? 
<Kamion> ovh.net, whoever they are
<Kamion> seem to be a Parisian ISP
<svenl> i only get around 100kBps to them.
<mdz> enrico: yes
<mdz> enrico: we need to sync up regarding delivery of documentation for the release
<Kamion> mdz: ok to revert that CD-ROM eject timing change we talked about yesterday? it's a change to cdrom-detect and another to prebaseconfig
<marcin_ant> hi any "linux printing" guru here?
<mdz> Kamion: yep
<marcin_ant> I got a problem with hp printer
<mdz> marcin_ant: this channel is for development discussion; #ubuntu is for support and general discussion
<marcin_ant> mdz: so about development - it this possible that hpijs package is broken?
<mvo> pitti: no, haven't reported it yet (and not looked into bugzilla). I'll do that now
<marcin_ant> mdz: I installed hpijs but drivers doesn't appear in gnome-cups-manager
<pitti> mvo: all the actually relevant bugs have been closed as duplicates of #2822
<mdz> marcin_ant: #ubuntu, please
<marcin_ant> mdz: ok
<pitti> mvo: however, #2106 fits much better for this, and is something entirely different
<seb128> pitti: g-c-m requires to be root to change settings or just to be in lpadmin ?
<pitti> seb128: just lpadmin
<seb128> k
<pitti> seb128: gksudo is just for enabling/disabling cups browsing
<seb128> I've a bug here so :p
<seb128> my user is in lpadmin
<mvo> pitti:  #2822 does not fit for my prolbem
<seb128> but I've the "become administrator" menu option
<pitti> mvo: #2106?
<seb128> which asks for a root password
<pitti> mvo: I will reopen this because the latest x.org 6.8.2-2 claims to fix it
<pitti> seb128: urgh, that should use gksudo
* lamont watches his test build run
<seb128> pitti: that doesn't here
<seb128> pitti: does it work on your system with the current version ?
<seb128> Edit -> become admin
<seb128> "Administrator (root) privilege is required.3
<pitti> seb128: I mean, we should change it to use gksudo (not "I thought it already does")
<seb128> "Please enter the root password to continue"
<seb128> is asks for that
<seb128> pitti: no, does it ask for that on your system ?
<pitti> seb128: erm, I don't have this menu entry
<seb128> sivang neither
<seb128> seems that you should not get it if you are in lpadmin
<seb128> my user is
<seb128> but I get the option
<seb128> I'll debug that here, thanks
<pitti> seb128: exactly, if authentication is already sufficient (lpadmin), you won't see it
<pitti> mvo: maybe we should just open a new bug
<seb128> pitti: hum in fact the archive version works fine, that's sivang's patch breaking it
<pitti> mvo: I selected German keyboard layout, but have PC104/US, you too?
<mvo> pitti: exactly
<mvo> pitti: console keyboard is correct
<pitti> mvo: apart from missing unicode on consoles 2-n
<pitti> but that's already filed
<pitti> mvo: are you already typing a report or shall I do?
<mvo> pitti: I don't mind, I'm not typing it right now
<pitti> mvo: I file one
<mvo> pitti: thanks
<enrico> mdz: I'm here
<sivang> pitti: I now even made my stuff work, and it cann even restart cups and I don't get any window for password whatsoever
<enrico> mdz: we definitely need to
<sivang> pitti: pretty odd
<pitti> sivang: maybe you are already authenticated at this session. Great that it works now!
<sivang> pitti: I did some changes to the arguments that gnome_cups_spawn recives
<sivang> pitti: I hate when I have to guess to make things work :-/
<sivang> pitti: eh probably authenticated alredy this sessoin, how do I clear my token? (I want to teste the authentication window)
<enrico> mdz: I have noted various items I should discuss with you
<enrico> let me know when you have some time
<sivang> pitti: so I can smile now :)
<mdz> enrico: would it be better to discuss at a documentation team meeting, or only the two of us?
<pitti> mvo: #7138, in case you want to add something
<enrico> mdz: I'll tell you the topics, you tell me where you'd like to discuss them
<enrico> mdz: 1) Yelp or not Yelp?
<pitti> sivang: sudo -K, then run it from the same terminal
<enrico> mdz: 2) Freeze date for the documentation
<svenl> Kamion: mmm, yaboot-installer doesn't do anything on pegasos, could you enable it ? 
<enrico> mdz: 3) Post-hoary wishes from the developers
<mdz> enrico: yelp vs. not yelp is a broader desktop issue, and should be discussed on ubuntu-devel
<enrico> mdz: 4) How to notify us when some feature changes and we need to adjust the documentation
<jdub> enrico: "not yelp" is crazy :)
<mdz> enrico: 2) depends on whether we have translators for these documents, and how much time they need
<mdz> enrico: 3) I haven't even begun to think about documentation for hoary+1 yet :-)
<svenl> Kamion: i suppose that not running ybin when a pegasos is detected should be enough, since pegasos OF can boo yaboot directly. Maybe putting a symlink from /usr/lib/yaboot/yaboot to /boot/yaboot would be neat though. Is there a big difference between debian yaboot-installer and ubuntu's one ? 
<enrico> jdub: froud told me that you agreed that help applications are dead and firefox would be better
<mdz> enrico: 4) the best thing would be for documentation authors to track Hoary; we don't closely monitor feature changes which are passed on from upstream, and so notifications from us would be unreliable
<jdub> enrico: i most certainly did not. :-)
<sivang> pitti: thanks, joy ==> it seems that I have now left only to add the warning window about opening the port on the system, and deal with approval/cancellation and hide the menu item with the configuration is custom :-))
<enrico> mdz: uhm... so.  It seems that 1) goes with "Yelp stays for Hoary at least"
<enrico> mdz: that is, if it needs a long discussion here, I guess it's too late for it in the release cycle anyway
<enrico> mdz: am I correct?
<enrico> mdz: 2) freeze dates: when will you know something about translators?  People are asking in the list
<Kamion> svenl: a few differences, but nothing major; mostly branding, a few small technical changes
<jdub> enrico: the issues with yelp seemed to be either minor, easily fixable (with interest from upstream), or fairly ridiculous.
<Kamion> svenl: where does the yaboot.conf go?
<svenl> Kamion: can you mail me a generated yaboot.conf ? 
<enrico> jdub: we've been working around most of them, yes.  Now we just need to figure out how to make our documentation show up in a nice place in the ToC
<herzi> mako: how do you want to receive digital sigantures of the code of conduct? c'n'p into the email and then sign it with gpg?
<mdz> enrico: we are definitely not getting rid of yelp; the only question is whether to use yelp for the doc team documentation.  I think that it makes sense to do so, but the issue is open for discussion as I have not even heard the full argument against it
<jdub> enrico: shaunm is very happy to help out
<Kamion> svenl: from a powermac, yes; from anything else, that's harder :)
<svenl> Kamion: well, the yaboot seems to not support getting the yaboot.conf from the same dir as the yaboot binary, but this is an OF issue i am working on.
<mdz> enrico: I will probably never know; I am not organizing translators
<svenl> Kamion: sure, from a powermac.
<enrico> mdz: who should I ask?
<mdz> enrico: the only translator I can point to for certain is Adi
<svenl> Kamion: the idea is to see if it would work here.
<mdz> enrico: the ubuntu-translators mailing list seems like a likely place
<enrico> mdz: noone's organizing the translators?
<svenl> Kamion: so it currently reads from "boot-disk"/etc/yaboot.conf
<jdub> enrico: speak to daf.
<mdz> enrico: ideally, the documentation could be imported into rosetta, but I don't think it's ready
<enrico> Ok, I can take care of 2, then.
<Kamion> svenl: will do after my next Ubuntu powerpc install; I overwrote the last one I did with a Debian test
<enrico> About 3[post-hoary] : we set up a DocteamPostHoary wiki page to do some brainstorming: it'd be nice to find some items from you people there
<svenl> Kamion: :)
<svenl> Kamion: actually, you could maybe plain add chrp_pegasos support to the ubuntu yaboot-installer for now ? 
<kagou> hi
<Kamion> mdz: ^-- ok to do so? doesn't affect macs at all
<mdz> Kamion: sure
<Kamion> svenl: so still running mkofboot/ybin, etc.?
<Kamion> (for now)
<svenl> for now.
<mdz> amu: have you tested the kubuntu installation CD?
<svenl> Kamion: mmm, maybe not.
<enrico> mdz: and about the meeting, froud told me you wanted to talk with me about it?
<svenl> Maybe i will hack on it on the debian side, and make a custom yaboot-installer and move it in the initrd.
* svenl wonders if that would work.
<mdz> enrico: as I said, I thought it would make sense to discuss these things at a doc team meeting, but if you would prefer that I talk only with you, we can do that
<Kamion> svenl: ok, up to you, they should be compatible
<svenl> maybe i should then check the OF version, and do the nobootloader if the version is too old or something such, not sure if this is possible.
<svenl> Kamion: still interested in your yaboot.conf though.
<Kamion> the Ubuntu changes to the postinst are (a) branding (b) timeout tweak if other operating systems are installed (c) add 'quiet splash' to default post-boot kernel args
<Kamion> yup, will get that to you
<enrico> mdz: we are definitely going to have a docteam meeting to see what to do post-quickguide
<enrico> I think the freeze could be decided well before the meeting, though
<mdz> enrico: the most important thing right now is to get the documentation packages into shape such that they can be installed by default
<enrico> However, we're finishing the QuickGuide and people are getting lost not knowing what to do
<mdz> enrico: after that, to work on the organization of documentation in yelp
<sivang> enrico: did you managee with the installing docs into yelp?
<svenl> Kamion: quiet splash is something that works for all kernels ? 
<Kamion> svenl: can't remember if either/both are Ubuntu kernel tweaks, but they're certainly harmless on kernels that don't support them; they were partly advance preparation for usplash that hasn't come to completion yet
<enrico> mdz: documentation packages are fine already.  They just lack better OMF files and registration into docbase
<Kamion> and I think partly to shut up noisy messages from the kernel and init
<enrico> I'll upload today's improved version
<svenl> Kamion: ah.
<svenl> Kamion: BTW, i could prepare a yaboot-installer from the ubuntu code, and wget it and then install it, right, since current code will not select yaboot-installer on pegasos ? 
* lamont wanders off for a bit while the livecd test build progresses
<enrico> sivang: docs are installed into yelp and scrollkeeper, only they show up in the "Others" category
<Kamion> svenl: right, although I think you need to be careful not to change any debconf templates if you take the wget-and-install route
<enrico> mdz: ok, I think I'm fine.  I'll upload these packages and start organizing the Docteam IRC meeting
<Kamion> (because they get thrown away the next time the debconf database is saved by a new menu item, or something awkward like that)
<sivang> enrico: ah ok
<lamont> heh.
<lamont> mdz: wanna do that rsync-ability bump today?>
<svenl> Kamion: ah.
<svenl> Kamion: anna install yaboot-installer.....udeb, right.
<lamont> mdz: 'no' is OK too.
<svenl> Kamion: well, i will just disable the ybin call and make it installable, should work fine for now.
* lamont notes that 'old-livecd.fsimg-1024' != 'old-livecd.ubuntu.fsimg-1024'
<Kamion> svenl: mmm, haven't got a new enough anna for that yet; you might just need to hack it into the initrd I'm afraid
<enrico> mdz: about the packages: maybe ubuntu-docs should contain the .desktop file that's now in ubuntu-artwork, providing the About Ubuntu menu item?
<mdz> lamont: let's do it as close to preview as we can
<mdz> lamont: once we're fairly certain there aren't any more large packages to be changed
<svenl> Kamion: ok.
<lamont> mdz: OK
<lamont> just have to remember to move a few more files...
* lamont bbiafew, then off to town to find bandwidth, and deliver the wife's phone :(
<Riddell> jdub: can we look at the applications.menu issue sometime?   it needs to get sorted
<jdub> Riddell: yeah
<Riddell> jdub: I don't see a way to have a single applications.menu file that everyone is happy with, I think it needs to have an xdg-applications-menu meta package and a gnome-applications-menu package with the gnome one and a kde-applications-menu package with the kde one
<Kamion> mdz: can it be not too much later than two days before preview, so that we have time to sync up?
<Kamion> mdz: oh, I just saw a bug with the CD-ROM not being detected, even with that udevstart change
<Kamion> I checked and /dev/cdroms/cdrom0 is there, so it's a timing issue I think
<jdub> Riddell: yeah, i've been thinking along similar lines
<jdub> Riddell: distribution-menus, gnome-menus, kde-menus...
<mdz> Kamion: yeah, I saw the same
<mdz> the first set of CDs were working 100% in my test environment, but since then I have seen it fail to detect the CD a few times
<Kamion> yes, likewise
<Riddell> jdub: ok, how do we make this happen?
<mdz> Kamion: have you re-enabled the daily cron jobs?
<Kamion> mdz: oh, no
<Kamion> mdz: thanks for reminding me, done now
<Kamion> mdz: shall I cron kubuntu daily?
<jdub> Riddell: first, let's just sort out what we want from /etc/xdg/menu/*
<jdub> Riddell: we can worry about package changes after that
<Riddell> jdub: I think we want it as it is but with the option to change from a gnome applications.menu to a kde applications.menu
* ogra rings the bell (5 mins to go): https://www.ubuntulinux.org/wiki/MOTUMeeting
<jdub> Riddell: do you want to have a common layout?
<jdub> Riddell: or do you want to use kde upstream layout?
<Riddell> jdub: personally I'd be happy with just using the KDE layout
* sivang --> be back in an hour
<Riddell> jdub: I don't even know how to have a common layout since things like the icons don't match
<svenl> Mmm, well, still X.org configuration problems on pegasos.
<jdub> Riddell: ship different .directory files
<mdz> Kamion: sure
<jdub> Riddell: if we go for different layouts, we just have a namespacing issue
<haggai> I think it would be best to try and combine the best of Ubuntu's changes with the default KDE layout
<mdz> Kamion: I think we need to adjust the naming structure somehow, though
<mdz> it's confusing enough that different versions of the same branch have the same names, but a different distribution with the name filenames and header content is more so :-)
<svenl> Ok, worked.
<ogra> meeting starts
<lamont> mdz: E: Couldn't find package kubuntu-desktop
<svenl> Kamion: mmm, my tft screen doesn't like the the default ubuntu X.org monitor specs, is this because the pegasos doesn't provide ddc/edid info in the OF ? 
<Kamion> svenl: might be, I'm not at all familiar with how X's configuration scheme works though
<Kamion> mdz: that's what we get for calling Kubuntu hoary as well :)
<svenl> daniels: you there ? 
<Riddell> jdub: so kde needs a package with must the same .directory files as gnome-menus has but using KDE icons, and applications.menu sits in it's own package
<svenl> Kamion: removing the horizsync and vertrefresh lines, and it worked.
<svenl> when does daniels usually show up ? He is in australian timezone.
<jdub> Riddell: only if we went for the same layout, which i don't think we should
<jdub> Riddell: also, i'd centralise the directory files and just change the icons
<jdub> Riddell: but let's not do it that way :)
<jdub> i think there's more value in using the kde upstream layout
<Kamion> mdz: I do see the confusion though
<haggai> hmm, and reduce the clutter of the kde upstream layout for kubuntu?
<Riddell> so we do just want two packages with application.menus files
<Riddell> and maybe move around some of the kde .directory files to keep haggai happy :)
<haggai> what happens if you have both KDE & gnome installed?
* haggai grins at Riddell
<jdub> haggai: gnome would use one, kde would use the other
<jdub> haggai: but the .desktop files would all be the same :)
<lamont> svenl: that's usually how daniels tells people to fix their X configs.  "if you can reprodouce the problem with horizsync and vertrefresh commented out, please tell me"
<lamont> or words to that effect
<haggai> jdub: so we'd have to patch them to stop them using the same file by default?
<jdub> seems so
<svenl> lamont: the problem is subtly different though.
<lamont> svenl: his contention is that those lines should almost never be there
<svenl> lamont: if they are not commented out, and since usefbdev is used, X requests a mode from radeonfb, which knows that it is not settable since it has is own DDC stuff.
<Riddell> if we do that the whole conflicting files issue goes away but it does mean a) digging the code to find out what to change  and b) one or both of them isn't using the applications.menu file which is specified in the specification as being the file to use
<svenl> lamont: i kinda agree with him, but it is not as easy, i had lot of experience with pegasos installs with those lines removed by default, and got lot of failures.
<svenl> lamont: from broken KVM switches to old none-DDC compatible monitors, passing through switched of monirots.
<Kamion> daniels' timezone has been a bit ... variable recently, he's been very busy; now would be typical sleep time for him though, of course
* lamont plugs his ears and says he's clueless about X configs
<svenl> lamont: hehe.
<svenl> Kamion: but on pmac, the HorizSync and VertRefresh are coming from the OF ddc stuff through your hacked read-edid, right ?
* svenl adds dcc support to the pegasos-OF todo list.
<Kamion> svenl: nah, we used that temporarily pre-warty I think, but it got dropped in favour of xresprobe
<svenl> Kamion: xresprobe ? 
<Kamion>  Description: X Resolution Probe
<Kamion>   xresprobe is a package that probes both laptop and DDC-compliant screens for
* svenl apt-get sources xresprobe.
<Kamion>   their standard resolutions, and returns a specifically-formatted, easy-to-parse
<Kamion>   output.
<mdz> lamont: it's in universe :-(
<svenl> Kamion: do you know how it works on ppc ? 
<mdz> elmo: ?
<mdz> Kamion: I guess that means that the kubuntu CD is unlikely to be correct, since it won't contain kubuntu-desktop
<Kamion> svenl: not really
<Kamion> mdz: I use the task ;-)
<lamont> mdz: it won't even get cloop images...
<svenl> Kamion: its an upstream thingy ? 
<elmo> mdz: ?
<mdz> lamont: I meant the install CD
<lamont> doh
<haggai> Riddell: how about we patch to look for <gnome/kde>.menu and fall back to applications.menu?
<mdz> elmo: do you have a moment for seed/archive resync?
<Kamion> svenl: daniels and fabbione wrote it I believe
<svenl> Ah ... will have to ask daniels, as fabbione is unreachable.
<Kamion> there's an of.c for powerpc
<mdz> elmo: we have a very few remaining kubuntu bits which need to be moved (kubuntu-desktop from universe, kubuntu-live from new)
<haggai> Riddell: hmm, that would still be confusing for people who did something with applications.menu and wondered why nothing happened
<Kamion> which is spiritually the same as my read-edid
<Riddell> haggai: that sounds fair
<Kamion> mdz: what about libjpeg-progs, libtiff-tools?
<mdz> Kamion: I meant to ask...is there a way to configure a G4 to boot from CD by default?
<Riddell> haggai: people shouldn't be changing applications.menu much
<Kamion> mdz: or are those to be changed in kubuntu?
<Kamion> mdz: I thought I suggested "nvsetenv boot-device cd:" already
<lunitik> Ugh... no one knows? I even removed firestarter... but its UI settings are kept... the toolbar won't allow me to move it...
<Kamion> I haven't tried that but it feels reasonable
<mdz> Kamion: I am not aware of the issues involving those two packages
<lunitik> (--purge and reinstall, and regular remove)
<Kamion> mdz: look at report.html in kubuntu/daily/current/ and follow the uninstallables
<mdz> Kamion: I remember asking, but i didn't remember your response, I'll try that
<lunitik> ahh... wrong channel
<svenl> Kamion: yeah, i guess the easiest way is to provide said ddc support in pegasos-OF, and document this in some errata file for now ? 
<haggai> Riddell: hmm but if we have a kde.menu it would override applications.menu.  Should we ship without applications.menu and give that highest priority if it exists, perhaps?
<Kamion> svenl: if there's some non-OF approach we can also take, I'm sure that would be fine too
<haggai> Riddell: that way a user who created applications.menu would find it had an effect
<svenl> Oh, it uses the fbdev interface ...
<mdz> amu: ping
<Riddell> haggai: yeah ok
<svenl> Kamion: not sure, i think it is easier to do x86 VESA call emulation at the OF level, and provide that data, we already have an emulated vesa fb8 OF package on our TODO list.
<amu> mdz: pong 
<mdz> amu: we need help from you and Riddell to get the CDs in order
<mdz> that's the priority for kubuntu right now
<Kamion> svenl: *nod*
<elmo> what the heck's been done  to the seeds and language packs?
<Riddell> mdz: what needs sorted?
<svenl> Kamion: arg, that of.c code seems to be doing some offb specific stuff.
<Kamion> elmo: l-p-en -> l-p-en-base, l-p-en-update -> l-p-en
<amu> mdz: so what's to do?  
<elmo> someone who's more awake might want to work out what needs to  be done from http://people.ubuntu.com/~james/paste/kubuntu-sync.txt for kubuntu
<Kamion> (etc.)
<Kamion> elmo: l-p-*-update should be removed AFAIK
<elmo> Kamion: so l-p-* can be removed ?
<elmo> err -*-update right ;)
* svenl wonders if that code would survive dual-screen on dual-card case :/
<Kamion> er, yes, you can stop giving me heartattacks now :)
<mdz> amu, Riddell: <elmo> someone who's more awake might want to work out what needs to  be done from http://people.ubuntu.com/~james/paste/kubuntu-sync.txt for kubuntu
<mdz> amu, Riddell: also http://cdimage.ubuntu.com/kubuntu/daily/current/report.html
<Kamion> I believe that promoting libjpeg-progs and libtiff-tools to main will fix everything on report.html, although I haven't done an exhaustive check
<Kamion> (just eyeballed it to make sure it wasn't my CD infrastructure at fault)
<elmo> mdz: ok  to promote them, they seem harmless
<elmo> +?
<Mithrandir> libjpeg-progs in main would be nice anyhow, since you then get lossless rotation of jpegs.
<mdz> elmo: libjpeg-progs and libtiff-tools, yes
<mdz> Mithrandir: I use the -mmx variety myself
<Mithrandir> mdz: it seems not to exist for amd64.
<Kamion> "Rebooting into your new Ubuntu system" -> hmm, are we going to brand stuff like that (not to mention the grub boot menu) for Kubuntu? if so, how?
<mdz> Mithrandir: sounds like a bug
<mdz> Mithrandir: well, perhaps not
<seb128> is the array 6 livecd supposed to work on amd64 ?
<mdz> seb128: it worked for me
<mdz> everything is supposed to work
<elmo> ok, done libjpeg-blah and libtiff-blah
<amu> I'm 15min.off, take the kid from kindergarden  
<Mithrandir> mdz: what package is -mmx in?
<Kamion> still a fair few bits of gnome stuff being unpacked here (python-gnome or whatever), is that known?
<Riddell> why is kdebindings being demoted to universe?  (because it's unused?)
<elmo> Riddell: if it's in the demote column it's not seeded and not pulled in by other stuff
* lamont heads into town.  mdz - about 45 min til back online, or you can kick a build yourself (but be aware that it might not produce exactly what you want... - wasn't able to fully test it, since it bombs on kubuntu...)
<Kamion> Riddell: I kind of hope it stays in main, it's a build-dep of libqt-perl
<seb128> Kamion: unpackaged ?
<svenl> Kamion: should i do a formal bug report in the bugzilla about this X.org problem ? 
<Kamion> seb128: hm what? (this is a Kubuntu installation)
<Kamion> svenl: sure
<mdz> lamont: what's the procedure?
<mdz> Mithrandir: libjpeg-mmx
<seb128> Kamion: ups, "unpacked" I mean
<seb128> Kamion: <Kamion> still a fair few bits of gnome stuff being unpacked here (python-gnome or whatever), is that known? 
<Kamion> seb128: as in unpacked then configured
<lamont> mdz: just kick a livecd rootfs build
<mdz> Kamion: is libqt-perl seeded/germinated?
<Kamion> seb128: I was wondering if the kubuntu guys intended all the remaining gnome packages in kubuntu to be there
<seb128> oh, k
<mdz> lamont: that will build both, or only kubuntu?
<Riddell> Kamion: is libqt-perl used?
<mdz> only kubuntu should be much faster
<lamont> both
<Kamion> mdz: not yet, but it's a build-dependency of debconf which I ripped out in a really hacky way but I'd like to restore
<Riddell> Kamion: there shouldn't be any gnome packages in there
<lamont> didn't give you a hook to build only one yet
<Kamion> i.e. allow the debconf kde frontend to build again
<lamont> which brings up the other question...
<mdz> amu,Riddell: we'll also need to do a security policy check
<mdz> amu,Riddell: currently, kubuntu-desktop pulls in openssh-server(!)
<Kamion> Riddell: there definitely still are
<lamont> ~buildd/livecd/current has both images in it.  if you only build one, does that mean that I need current-$PROJECT, or do we care?
<Riddell> Kamion: ok, cool, so we need to put kdebindings on the seeds somehow
<mdz> gnome-mime-data, libgnomevfs2-common, etc. are there at present
* lamont looks at kamion, points ^^
<Kamion> Riddell: look for gnome in http://people.ubuntu.com/~cjwatson/germinate-output/kubuntu-hoary/desktop
<mdz> python-gnome2 is in desktop
<Kamion> Riddell: promoting kde to main might be sufficient
* lamont must run before his wife kills him.  back online ASAP (~45-60 min)
<Kamion> lamont: I don't mind, but I think it might be nice to have that flexibility given that cloops take a while to build
<Riddell> Kamion: promoting kde to main might pull in stuff we don't want
<mdz> amu had seeded kde, but decided to do it differently
<Kamion> Riddell: kdebindings seems like the sort of thing that should be pulled in via build-deps
<mdz> Get:234 http://us.archive.ubuntu.com hoary/universe libkipi0 0.1-2 [97.4kB] 
<mdz> Get:235 http://us.archive.ubuntu.com hoary/universe gwenview 1.1.8-1ubuntu3 [630kB] 
<mdz> ^^ pulled in by kubuntu-desktop
<svenl> yep, suspend-to-disk worked, provided mkinitrd stuff is fixed for the RESUME thingy.
<seb128> mdz: http://pkg-gnome.alioth.debian.org/amd64.jpg
<mdz> amu: you mentioned gwenview; what happened there?
<seb128> mdz: I get that with the liveCD on amd64, any idea on what could be wrong ?
<Riddell> gwenview is a KDE app incase anyone is confused by that
<mdz> seb128: looks like a bad burn
<Kamion> ok, this kubuntu install CD seems to have worked fine after I worked around the couple of missing dependencies
<mdz> Riddell: yes, but it is one that was not discussed during the promotion review
<mvo> is "Menu item 'load-cdrom' failed." a known error on the live cd? 
<seb128> mdz: k, I'll burn it again on an another media
<mdz> Get:335 http://us.archive.ubuntu.com hoary/universe kvim 1:6.3-046+1ubuntu4 [2586B] 
<Kamion> mvo: not afaik, that also rather suggests a bad burn
<mdz> Kamion: did you encounter libkipi0, gwenview or kvim?
<mvo> Kamion: ok, I'll retry with a new cd
<mdz> Get:352 http://us.archive.ubuntu.com hoary/universe xscreensaver-nognome 4.16-1ubuntu7 [2204B] 
* mvo kicks his stupid cd-rws
<Kamion> mdz: what, on the CD?
<mdz> I'm just installing kubuntu-desktop on a fresh base
<mdz> and these are the things being pulled in from universe
<Kamion> mdz: oh, I'm installing from kubuntu/daily/current/hoary-install-i386.iso
<Riddell> kdelibs-data depends on gnome-menus which is why there's a lot of gnome stuff in there, that will go away if I manage to sort the menus
<seb128> ?
<mdz> Kamion: that CD doesn't have kubuntu-desktop on it, does it
<Kamion> mdz: no
<mdz> so far I have 4 additional binaries
<seb128> Riddell: oh, perhaps we should split it to a data package ?
<Riddell> update-notifier is the other problem, can that be removed from the seed?
<jdub> seb128: we're going to have to use independent applications.menu files
<Kamion> where's kynaptic in the menus?
<jdub> seb128: ie. gnome-applications.menu
<seb128> jdub: why ? i thought we want a common menu to both desktop ?
<jdub> seb128: nup
* Kamion looks at the System Tools menu
<Kamion> "Root Terminal"
<Kamion> "Terminal Program - Super User Mode"
<Kamion> hmm
<jdub> Kamion: we're going to kill those
<Kamion> oh, root terminal == sudo x-terminal-emulator
<jdub> Kamion: it runs gnome-terminal as root, which is insane
<Kamion> although "Terminal Program - Super User Mode" wants the nonexistent root password
<Riddell> mdz: gwenview was added not too long ago, presumably after the promotion review, does it need reviewed somehow?
<mdz> Riddell: where was it added? what depends on it?
<Riddell> Kamion: the whole kde and sudo issue also has to be sorted, I'll be looking at that soon
<Riddell> mdz: kdegraphics I think
<mdz> pitti: here?
<pitti> mdz: yes
<Kamion> ah, kynaptic much more comprehensible than kpackage
<Riddell> Kamion: almost anything would be :)  kynaptic is nice but lacks a lot the synaptic has
<sivang> back
<mdz> pitti: I think we will need a few more last-minute security reviews for kubuntu
<Kamion> Riddell: yeah, no repositories editor it seems
<pitti> mdz: no problem, which packages?
<Riddell> Kamion: exactly
<mvo> Riddell, Kamion: i hacked a bit on kynaptic today. the biggest problem I see is that it does not have a proper install progress thing
<pitti> mdz: gwenview?
<Kamion> hmm. if aptitude fails, you don't get the final sources.list
<Kamion> that seems like a base-config bug
<amu> back
<Kamion> cdrom://Kubuntu 5.04 _Hoary Hedgehog_ - Alpha ...
<Kamion> hah
<mdz> amu: kscreensaver-xsavers should be changed to depend on "xscreensaver" instead of "xscreensaver-nognome | xscreensaver"
<mdz> amu: xscreensaver-nognome is a dummy package depending on xscreensaver
<mdz> pitti: libkipi0 and gwenview
<Kamion> mvo: the Packages download progress thing is ok, if a bit "erk, look at all those colourful progress bars"
<pitti> mdz: alright
<Kamion> which I guess is just a theming thing
<amu> mdz: ok, i'll do it 
<mvo> Kamion: yes, the actuall package installing is happening on the xterm/console that kynaptic was started on *ick*
* lunitik wonders if 'gtk2-engines-gtk-qt' has come up yet in this discussion for Kubuntu   :D
<Kamion> mvo: oh wow, so it is
<mdz> mvo: is kynaptic actually derived from synaptic, or is it something entirely different?
<mvo> mdz: it's a port of synaptic to kde, it uses synaptics libsynaptic 
<mdz> oh, I didn't know about libsynaptic
<mvo> mdz: it's a static lib :) it's only used inside synapatic and kynaptic
<mvo> and kynaptic is only used by kubuntu so far so ...
<Riddell> mvo: it's used by connectiva as well no?
<mdz> mvo: so it is extremely well tested? :-)
<mvo> mdz: I compile it once in a while to see if I broke it. I guess that's considered to be good testing ;)
<lunitik> Riddell: they even stopped using apt4rpm/synaptic ...
<Riddell> and now they're just mandrake anyway
<mvo> Riddell: I don't think so, they wrote it (gustavo niemeyer). but gustavo also wrote smart, a new package manager. and the last kynaptic checkin by gustavo is 7/2004
<lunitik> Riddell: started developing smartpm
<mdz> smart --gui is not quite as nice as synaptic yet :-)
<srbaker> smart?
<mdz> srbaker: apt-cache show smartpm
<Riddell> mvo: I'd be happy to add improvements to kynaptic but then there's the kalyxo one that might appear one day
<pitti> mdz: I don't find any kipi plugin in the archive, so why do we need libkipi0?
<pitti> amu: ^
<srbaker> huh
<srbaker> cool
<Riddell> pitti: we don't, it was for gwenview-kipi package but that had some problems that I havn't sorted yet
<mvo> Riddell: yes, kapture. very promissing. haven't used it yet
<mdz> pitti: gwenview links with it
<mdz> but only recommends kipi-plugins
<haggai> pitti: it's needed for the digikam plugins too; even if there's a problem now I think it should be included when fixed
<mvo> mdz: yes, smart needs a bit of gui love (and glade!)
<mdz> Kamion: did you get my forward regarding LCA registration?  just be sure to send me your registration code when you receive it
<Kamion> mdz: yes, thanks; I've just been too brain-fried today to do any organisation
<lunitik> mdz: will be interesting to see if it continues development with Mandrake(or whatever they decide to be called...) though  :/
<Kamion> today I seem to be able to handle shell scripts and testing and not a lot else
<mvo> Riddell: doesn't konsole has a API? or a terminal class something? it would be nice if we could at least add support to install pacckages inside a terminal window in kynaptic
<Riddell> mvo: of course, it's a kpart so you can embed it anywhere
<Riddell> mvo: can synaptic embed a terminal?
<mdz> Kamion: fortunately, I think that is the right level of operation today :-)
<mvo> Riddell: oh yes, it's doing it for ages :)
<Kamion> mdz: yes, convenient :)
<mvo> Riddell: I'm not into kde development, where do I find a API of the konsole kpart?
<amu> mdz: xscreensaver-nognome removed and uploaded 
<pitti> amu, Riddell: any reason why gwenview ships a shared library in the "gwenview" package?
<pitti> amu, Riddell: that's pretty ugly
* T-Bone supposes no one has any clue what's going wrong with firefox locales on ia64?
<Riddell> amu: because it's a kpart, you get a gwenview application and a gwenview plugin for konqueror etc
<amu> pitti: gwenview was suuggested, as a replacement, never touch it before  
<Riddell> s/amu/pitti/
<pitti> Riddell: I mean, libraries shold be packaged separately
<mdz> Riddell: what functionality does gwenview provide?
<seb128> if the installer says that there is no default route, that's a DHCP server issue ?
<Riddell> mvo: kdebase/konsole/konsole/konsole_part.* and for an example of use kdebase/kate/app/kateconsole.cpp
<pitti> Riddell: http://www.de.debian.org/doc/debian-policy/ch-sharedlibs.html
<Kamion> amu, Riddell: what time would be most convenient for you guys to have daily CD image builds?
<Kamion> as in time of day for a cron job
<pitti> Riddell: if gwenview is the only package using this library, then it should live under /usr/lib/gwenview, or so
<Riddell> mdz: it's an image viewer
<amu> mdz: Gwenview is a simple image viewer for KDE.
<Riddell> pitti: the library is used by gwenview and by anything else that needs an image viewing kpart (i.e. konqueror)
<amu> Kamion: 6.00 a.m. is ok    
<Kamion> amu: UTC?
<amu> yep
<pitti> Riddell: then it should definitively be packaged separately
<Kamion> ok, I'll arrange for it to generally be finished around that time
<pitti> Riddell: so that pacakges using it can depend on the library package (with correct SONAME)
<mdz> lamont: kubuntu cloops are blocked only on having an installable metapackage in main?
<Riddell> pitti: no, it's all loaded at run time, the only thing that depends on it is the gwenview app
<mdz> it sounds like the packaging for gwenview needs some work
<mdz> can we omit it for the purposes of getting working CDs built?
<Riddell> so konqueror goes "I need an image plugin, oh look there's gwenview I'll use that" but otherwise it just uses it's default image plugin
<pitti> Riddell: but in theory other packages could use it, too?
<mvo> Riddell: thanks
<Kamion> 14 5 * * *      /srv/cdimage.no-name-yet.com/bin/cron.kubuntu-daily
<mdz> Riddell: if it's a plugin, loaded with dlopen, it shouldn't go in /usr/lib
<Kamion> done
<Riddell> pitti: only as a kpart, they don't depend on it they just use it if it happens to be there
<pitti> hmm, ok
<seb128> Kamion: have you read my question ? :)
<amu> Kamion: thx
<mdz> sounds like a dlopened plugin to me
<Riddell> mdz: why not?  all other kparts do
<Kamion> seb128: sec
<seb128> k
<Kamion> netcfg-dhcp.templates:_Description: Continue without a default route?
<Kamion> that one?
<elmo> so - anything for me to sync?  I need to go get some breakfast soon
* Riddell reminds elmo about adding his key for main uploads
<seb128> Kamion: yep
<mdz> elmo: defiintely kvim, possibly kipi/gwenview
<Kamion> seb128: yes, that's checked right after DHCP runs, generally a DHCP server issue
<elmo>   * [Fri, 14 Jan 2005 16:32:09 GMT]  {Added [Upload] } 1024D/DD4D5088 Jonathan Riddell (University Address) <jri@jriddell.org>
<seb128> Kamion: what option is expected ?
<Kamion> i.e. as soon as you've got a lease
<elmo> Riddell: ?
<Kamion> seb128: option?
<Kamion> oh
<elmo> kvim done
<seb128> Kamion: the dhcp servers send a Option 3: Router = ... , that's not the right one ?
<Kamion>             for router in $new_routers; do
<Kamion>                 ip route add default via $router
<Kamion>             done
<Riddell> elmo: from yesterday  "Rejected: dbus_0.23-1ubuntu6.dsc: upload is signed by 0x13C16D03EDE728514473AA73A506E6D4DD4D5088 but is not in the Maintainer keyring."
<mdz> Riddell: Debian policy
<Kamion> that's all I can see in the dhclient-script
<mdz> possibly even FHS
<Riddell> mdz: but all other kpart shared libraries are under /usr/lib
<seb128> Kamion: k, I'll try to figure what's wrong here, thanks
<mdz> Riddell: then they all have the same bug :-)
<elmo> Riddell: dbus is a main package?
<Riddell> elmo: I would have thought so
<Kamion> seb128: I'm not really a DHCP expert, sorry :( I can't see where $new_routers comes from, I'm assuming it's set by DHCP
<T-Bone> elmo: glad your here
<T-Bone> elmo: my upload for linux-source got rejected last tuesday
<elmo> Riddell: sorry did I miss something, thought you were a MOTU only ATM?
<seb128> Kamion: np, thanks, I'll try to figure that and let you know
<T-Bone> elmo: and since i'm not whitelisted, I didn't receive anything. Lamont tried to reupload using his key to sign the changes. same effect
<T-Bone> elmo: if you could look at that it'd be very nice
<Riddell> elmo: I got approved by the technical committee for restricted main uploads i.e. anything related to KDE
<mdz> T-Bone: elmo will need the email address that you want whitelisted
<T-Bone> mdz. elmo: varenet@debian.org
<mdz> pitti: are you satisfied with kipi and gwenview from a security support perspective?
<lamont_r> uh, T-Bone you used t-bone@parisc-linux.org in the upload....
<mdz> pitti: let's set aside the library placement for now
<pitti> mdz: other than the broken library, gwenview is straightforward and fine
<pitti> mdz: I didn't look at kipi yet, I'm still in the MOTU meeting
* pitti tries to fork()
<T-Bone> lamont_r: certainly not
<lamont_r> T-Bone: ok
<T-Bone> lamont_r: my changelog was @debian.org
<mdz> pitti: ok, kipi seems to be thankfully very small
<T-Bone> or else something went very wrong. the only address coded in my debian tools is the debian one
<lamont_r> T-Bone: so it was
<T-Bone> http://parisc-linux.org/~varenet/linux-source-changes/linux-source-2.6.10_2.6.10-25_source.changes
<pitti> mdz: kipi is GO
<pitti> mdz: trivial packaging
<pitti> mdz: however, I only looked at diff.gz and the deb structure, no source code review
<pitti> mdz: but it's all user level, so I don't expect many problems there
* sivang wonders what is kipi :-)
<pitti> sivang: me too :-)
<sivang> hehe
<mdz> elmo: ok, please promote libkipi0, gwenview and kvim, and we should be done
<Riddell> sivang: it's an image manipulation plugin thing so it has tools like "rotate" and "add a pretty border" that can be used by various KDE programmes
<sivang> pitti: if you could point me again to your p.u.c where you have the cdbs dpatch immitating script, that would be cool :)
<sivang> Riddell: ah ok, cool !
<pitti> sivang: people.debian.org/~mpitt/cdbs-new-patch
<sivang> pitti: thanks
<elmo> mdz: done
<elmo> T-Bone: did you get confirmed as a full maintainer?
<lamont_r> Kamion: how about if we make ~buildd/livecd/current-$PROJECT/... and teach BuildLiveCD to take an argument of whcih is wanted?
<Kamion> lamont_r: works for me if you can do that with your restricted ssh key
<lamont_r> actually, I'd be more tempted with ~buildd/livecd/$PROJECT/current
* lamont_r likes that much more
<Kamion> ack
<mdz> elmo: when will the changes be reflected at archive.u.c?
<lamont_r> did the kubuntu-desktop migration get finished?
<T-Bone> elmo: http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/001101.html
<mdz> lamont_r: elmo just did the last bits
<mdz> kubuntu-desktop should be installable in main as soon as those changes propagate
<T-Bone> elmo: i understood that (and so has mako) as a "yes" to your question
<elmo> mdz: next cron.daily in 10 mins, + 10 mins  for it to finish + sync
<elmo> or I can force one through now if you want
<mdz> lamont_r: ^^
<mdz> elmo: I think we can wait 20 minutes
<lamont_r> mdz: and the buildd only really needs the 10 mins
<mdz> workrave wants 10 from me anyway
<Kamion> I dunno about workrave, but my wrists want 10 minutes from me
<lamont_r> Kamion: the run I do in a bit will be this morning's version of the script...
<Kamion> lamont_r: let me know final URLs when you have them
<dand> i'm working on translations. anyone knows where can I find menu strings like "Places" and "System"? i tried gnome-menus, but no luck...
<T-Bone> elmo: if in doubt i suppose you want to check that with sabdfl
<Riddell> elmo: are you adding me to be able to upload to main?
<dand> i found out... it was in gnome-panel.
<T-Bone> Mithrandir: ping?
<Mithrandir> pong
<T-Bone> Mithrandir: no time to toy with ia64? :)
<Mithrandir> tomorrow.  I have some stuff I need to do today and I'm in a meeting. :)
<T-Bone> hehe ok np
<T-Bone> Mithrandir: what's your TZ?
<T-Bone> Norway. Stupid question :)
<Mithrandir> CET
<Mithrandir> in 22-23-ish hours is fine, just ping me
<T-Bone> roger that
<T-Bone> thx
<elmo> T-Bone/Riddell: done
<T-Bone> elmo: k thx. So next kernel uploads should go through fine?
<Riddell> elmo: groovy
* lamont_r ponders katie and the NEWness of kubuntu-desktop
<lamont_r> elmo?
<mdz> Kamion: did you sort out the Task: issue with elmo, or is that obsolete now?
<mdz> lamont_r: how are the cloop builds going?
<Kamion> mdz: obsolete
<lamont_r> launched, and chunking along
<Kamion> mdz: at least as far as CD images are concerned
<lamont_r> fwiw, BuildLiveCD now takes an argument: 'ubuntu' or 'kubuntu'.  No argument (or 'all') will build both
<elmo> uh
<elmo> how are you doing that with command limited keys?
<Kamion> lamont_r: can you pass arguments through restricted ... what elmo said
<lamont_r> elmo: if there's no arguments on the command, then it lets you pass it whatever.
<Kamion> it does?
* lamont_r goes to look at w-b's restricted key again
<lamont_r> ah, feh.
<Kamion> I've never encountered that feature before; normally you have to use stdin to pass arguments
<Kamion> so echo ubuntu | ssh buildd@terranova.buildd BuildLiveCD
<lamont_r> you have to teach the script a little bit of smarts
<Kamion> is that a euphemism for "rewrite"? :-0
<Kamion> )
<lamont_r> nah
<lamont_r> not completely
* lamont_r points Kamion at occurances of 'SSH_ORIGINAL_COMMAND' in the ssh source
<Kamion> ooh!
<Kamion> I did not know about that one
<Kamion> neat
<lamont_r> me neither until recently
<mdz> Riddell: does kdm have an autologin feature like gdm?
<lamont_r> so I just have to teach the script to handle that variable :-)
<Riddell> mdz: yes
<mdz> Riddell: I'll need to teach casper how to configure it
<pitti> hmm, array 6 still has no sound for me... I thought the polypaudio "cannot open resource for writing" bug was solved?
<Riddell> mdz: what is casper?
<lamont_r> Riddell: friendly.
<lamont_r> Riddell: it's the thing that confgures and launches the livecd
<mdz> oh, it's very similar to gdm.conf
<amu> mdz: /etc/kde3/kdm/kdmrc AutoLoginEnables=True 
<Riddell> mdz: /etc/kde3/kdm/kdmrc  AutoLoginUser=foo  is the one
<amu> yes it it similar 
<Riddell> and the one amu says
<mdz> there is no timedlogin equilavent, though?
<mdz> what happens when you logout a user who was logged in with autologin?
<mdz> ah, autorelogin
<Riddell> mdz: there is an option to autorelogin or not
<mdz> pitti: still here?
<mdz> /usr/sbin/install-language-locales: line 14: /usr/share/i18n/SUPPORTED: Permission denied
<pitti> mdz: yes
<pitti> ugh
<pitti> mdz: the file is world-readable at my system???
<pitti> mdz: what are the permissions for you?
<seb128> k, now the amd64 livecd works fine :)
<mdz> pitti: there is an extra '|' in the command line
<mdz> pitti: it is trying to execute the file
<pitti> AARGH
<seb128> now I need to figure which dhclient refuses to set the default route
<mdz> seb128: great
<seb128> s/which/why/
<pitti> mdz: sorry for that; I'm afraid that requires a new glibc upload
<mdz> pitti: that's ok, let's get it fixed for preview
<pitti> mdz: ack, I do it now
<pitti> mdz: ah, I never encountered it since /etc/locale.gen is usually there by default
<seb128> dhclient displays a "SIOCADDRT: Network is unreachable" and doesn't set the default route. The server sends an "Option 3: Route =" according to ethereal ... anybody has an idea of what could be wrong ?
<lamont_r> Setting up mozilla-firefox-locale-en-gb (1.0lang20041216-2ubuntu1) ...
<lamont_r> /var/lib/dpkg/info/mozilla-firefox-locale-en-gb.postinst: line 11: update-mozilla-firefox-chrome: command not found
<lamont_r> bummer
<lamont_r> mdz: kubuntu livecd ^^^
<mdz> pitti: I just encountered it installing in a chroot
<mdz> pitti: lamont's bug is yours too I think
<pitti> Yes
<T-Bone> that would certainly fix the ia64 segfault :^)
<mdz> seb128: that sounds like the netmask does not match the default route
<mxpxpod> is anyone else having problems with evolution-alarm-notify crashing?
<tseng> mxpxpod: rarely
<tseng> but yes
<mxpxpod> tseng: it crashes for me all the time
<tritium> mxpxpod, yes, often, and evolution-exchange-storage
<Stuttergart> Anybody having problems with the Array 6 ISO bombing out while trying to "retrieve" the at package?
<mxpxpod> tseng: when gnome starts, when evolution starts
<Kamion> Stuttergart: that suggests a bad burn, normally
<Stuttergart> My Array 6 ISO checks out as far as the MD5 and the at package is on the ISO(find ./ -name 'at*.deb')
<Stuttergart> Kam: Y, but the MD5 checks out.
<Kamion> Stuttergart: what about if you go back to the main menu from the CD and run "verify the CD-ROM's integrity" or whatever it's called?
<Stuttergart> I didn't see that as an option. I will try it out.
<mdz> pitti: please make the mozilla-firefox-locale-* problem a priority, since it is blocking kubuntu live CDs
<pitti> mdz: ETA 20 minutes, is that okay?
<pitti> or faster?
<mdz> pitti: yes, I just meant relative to the install-language-locales problem
<mxpxpod> tseng: how comes the tomboy stuff?
<tseng> i really dont look at that much, more important things going on sorry
<mxpxpod> tseng: heh, that's cool
<tseng> iirc it just wouldnt run, which is odd enough
<tseng> on that note, is tomboy still working on your ppc since dbus upgrade?
<tseng> a user is telling me otherwise
<mxpxpod> tseng: crashes here
<tseng> cute
<thully> hi - I noticed that kubuntu is being worked on now - cool!
<tseng> thully: has been for some time
<thully> No, I mean as far as CD images go...
<thully> and putting it into main
<seb128> mdz: Option 1: Subnet Mask = 255.255.255.0, Option 3: Router = 192.168.1.1 ... should be fine
<thully> I tried out the kubuntu daily - alas, broken packages :(
<mdz> seb128: what is your IP address?
<Kamion> thully: yes, it was the very first image that we produced. the broken packages have been fixed since then; we had a fairly extensive discussion on this channel
<mdz> kubuntu has been worked on for a couple of months now, in fact
<seb128> mdz: 192.168.1.15
<mdz> seb128: strange
<mdz> seb128: and "ip route add default via 192.168.1.1" gives you an error, or no?
<seb128> nop, works fine
<pitti> mdz: uploaded.
<mdz> pitti: do the other locales have the same bug?
<mdz> pitti: thanks
<pitti> mdz: yes, I fixed them all
<pitti> mdz: luckily they are built from a common source package now
<mdz> oh, good
<pitti> mdz: in warty times each language had its own source
<mdz> yes, I did not realize that had changed
<pitti> m-f-locale-all :-)
<pitti> a really wise decision from Debian
<pitti> mdz: the bug is not in warty, btw
<mdz> pitti: where did we end up with the question of which languages to put onto the CD and the live images?
<mdz> that needs to be addressed for preview
<pitti> mdz: there has been no answer so far and the discussion died soon
<Kamion> mdz: I suppose I should kick off a new kubuntu daily so people can try it with non-broken packages
<mdz> Kamion: sounds good
<mdz> once pitti's uploads are built, hopefully we can do a live build as well
<pitti> Kamion: can you please wait until mozilla-firefox-locale-all is built?
<mdz> pitti: does that affect the install CD?
<pitti> mdz: does kubuntu install ffox?
<pitti> mdz: if so, then yes
<pitti> mdz: I suppose it installs Konqueror?
<mdz> pitti: no, kubuntu does not install firefox; that's why we encountered the bug
<mdz> right
<pitti> mdz: then it will affect install as well, if you install language packs
<pitti> -support packages, that is
<mdz> hmm
<mdz> Kamion: you didn't run into this issue?
<Kamion> pitti: ok
<mdz> (the mozilla-firefox-locale-* one)
<Kamion> mdz: no ...
<pitti> mdz: it doesn't affect Ubuntu since we install ffox before the langpacks
<pitti> Kamion: ^
<Kamion> mdz: oh, but I didn't install language packs since I had to install packages by hand
<Kamion> since the automatic aptitude failed
<pitti> Kamion: the package builds very quick and it was accepted now, should be a question of minutes
<mdz> ah
<mdz> jdub: so about polypaudio...
* pitti vomits over polypaudio
<mdz> it's working OK for me
<mdz> but apparently there are issues
<pitti> on ppc it does nothing but crash
<pitti> #6582
* pitti -> food
<mdz> yes, I asked for an update on that bug yesterday. jdub?
<svenl> Mmm, why is bugzilla telling me i need to fill in a component field, while i filed the package entry ? 
<mdz> lamont_r: will the ssh trigger work for kubuntu, or not yet?
<lamont_r> ssh trigger will get you both
<lamont_r> and the kubuntu-livecd build failed
<mdz> I mean the passing of args
<mdz> to build only kubuntu
<lamont_r> not yet
<mdz> fixed mozilla-firefox-locale-* should be available shortly
* lamont_r was helping a user with something for a minute - got distracted.
* mdz notices that polypaudio has been eating 20% of his CPU for some time now
<svenl> daniels: Bug#7144 reported.
* lamont_r works on passing arg
<mdz> lamont_r: firefox fix was built at :09; when can we try another cloop build?
<Nafallo> mailman@l.u.c gets checked, right? :-)
<lamont_r> mdz: go ahead and see if BuildLiveCD kubuntu works with your key
<mdz> bad project: /home/buildd/bin/BuildLiveCD
<mdz> /home/buildd/bin/BuildLiveCD: line 11: ((: 0 = 0 : attempted assignment to non-variable (error token is "= 0 ")
<mdz> the former from terranova, the others gave the latter error
<lamont_r> terranova is the only modified one
<lamont_r> hehe
<lamont_r> try terranova one more time - if that works, I'll clone things
<lamont_r> did it get as far as launching livecd.sh?
<lamont_r> mdz: I'm going to assume that works.  cloned to all 4.
<lamont_r> and firefox should be in the archive in about another 2 minutes
<lamont_r> Kamion: is there going to be an array-6 dvd?
<Kamion> lamont_r: I hadn't planned on one; I suppose there should be a preview DVD though
<lamont_r> sounds about right
<Kamion> ugh, that means I have to download one of the suckers and figure out where to burn it
<lamont_r> Kamion: nah - make mdz do it. :-)
<Kamion> or that :)
<lamont_r> or do you mean to make sure that you can debug it and such/
<lamont_r> >
<lamont_r> ?
<lamont_r> gah
<Kamion> *shrug*
<lamont_r> Kamion: seed question.  the kubuntu stuff is (effectively) siblings of the same-name ubuntu- seed?  kubuntu-desktop is similar to ubuntu-live in it's lack of supersethood?
<Kamion> ubuntu-base < ubuntu-desktop < ubuntu-live
* lamont_r tries parsing that question...
<Kamion> ubuntu-base < kubuntu-desktop (< kubuntu-live)?
<lamont_r> ah, live vs ship I mean
<Kamion> oh, yes
<Kamion> same seed structural semantics
<mdz> lamont_r: did you start a build, or do I need to?
<lamont_r> right.
<lamont_r> mdz: please do
<Kamion> I'm going to put a definition of the structure into the seed archive itself at some point
<lamont_r> on at least one (to test)
<Kamion> when I have time
<lamont_r> I can kick the other 3
<Kamion> and make germinate decide what to do based on that
<lamont_r> Kamion: cool.
<lamont_r> was just pondering my mirror and how much kde hurts me
<mdz> seems to be chugging along
<lamont_r> and thinking about whether or not it makes sense to just seed the seeds, as it were
<mdz> lamont_r: I started them all
<Kamion> hah, yeah, my mirror run's just finishing for the day, having started at 03:35 UTC
<mdz> does Kamion have the new URLs?
<lamont_r> mdz: middle of debootstrap
<Kamion> not sure I have the final ones
<mdz> there should definitely be a preview DVD
<mdz> Kamion: combo-DVD or install-DVD?
<Kamion> combo
<lamont_r> Kamion: URL's are:  <machine>/~buildd/livecd/$PROJECT/current/livecd.$PROJECT.cloop
<lamont_r> I think.
<mdz> lamont_r: hmm, weddell fiinshed early
<lamont_r> mdz: it always does that.
<lamont_r> make thom fix firefox registry crap, and ia64 will be happier again
<Kamion> lamont_r: double $PROJECT?
<lamont_r> Kamion: uh, yeah.
<lamont_r> pb is that livecd.sh can build both, so it needs the second one
* Kamion kicks a new kubuntu install daily
<lamont_r> separating the /current/ directories accounts for the second one
<Kamion> lamont_r: ok
<lamont_r> note that there are no ubuntu livecd roots at this time(in the new structure)
<Kamion> (don't kick a live build while the install build is still running, as usual)
<mdz> lamont_r: which machines are which architectures?  I promise to write it down this time
<lamont_r> hehe
<mdz> I should rewrite the silly script in python so that it could just tell me
<Kamion> Setting up cvs (1.12.9-9) ...
<Kamion> Couldn't reopen stdin at /usr/sbin/update-inetd line 29.
<Kamion> dpkg: error processing cvs (--configure):
<Kamion>  subprocess post-installation script returned error exit status 6
<lamont_r> terranova,weddell,adare,king == i386,ia64,ppc,amd64
<Kamion> (terranova)
<Kamion> maybe it'll work ok anyway
<mdz> there is way too much stuff in kubuntu-desktop right now
<jbailey> pitti: Is that cdbs patch something you want in cdbs itself?
<lamont_r> more is not better? :-)
<mdz> kdewedev probably doesn't need to be in the desktop
<mdz> Riddell,amu: ?
<pitti> jdub: back
<pitti> jbailey: back
<Kamion> terranova failed
<pitti> jdub: sorry, that was not for you
<jbailey> Kamion: Next time you're doing an install, can I get you to check whether /proc/swaps is in devfs style names or lsb style?
<Riddell> mdz: why not?
<pitti> jbailey: what do you mean?
<Kamion> jbailey: pretty sure it was devfs, but yeah, I'll check
<pitti> jbailey: cdbs-new-patch? would you adopt it?
<mdz> Riddell: web development apps?
<Riddell> mdz: quanta is very popular (for some reason) and kommander is increasinly useful
<lamont_r> Kamion: from which I expect the rest to do the same
<mdz> Riddell: we have web development apps in ubuntu as well, but we don't install them by default on every desktop
<jbailey> pitti: I haven't read it - I was more wondering if it was something you wanted in cdbs or just something you were playing with.
<lamont_r> mdz (machine order matches the vertical column on my screen, in case you were curious about the order...)
<pitti> jbailey: do you know dbs-edit-patch and dpatch-edit-patch?
<mdz> lamont_r; I used the same order in my script
<pitti> jbailey: such a thing is really needed for cdbs simple patchsys
<mdz> lamont_r: so the CVS thing is killing us now?
<jbailey> pitti: YEah.  Is this the same for simple patchsys?
<lamont_r> cvs, quanta, and a couple others
<Riddell> mdz: I think people will expect quanta to be in, it's very popular
<mdz> quanta is surely failing due to cvs
<pitti> jbailey: so I wrote cdbs-new-patch, which already fulfills most of my use cases
<lamont_r> Errors were encountered while processing:
<lamont_r>  cvs
<lamont_r>  libcvsservice0
<lamont_r>  quanta
<lamont_r>  kdewebdev
<lamont_r>  kubuntu-desktop
* jbailey does a snoopy dance!
<pitti> jbailey: for tarball.mk I just use dbs-new-patch, that works fine
<jbailey> pitti: I was trying to convince some of the MOTUs earlier today that they should write those tools for me. ;)
<mdz> lamont_r: any reason update-inetd might not be able to open /dev/null?
<pitti> jbailey: but for "normal" (non-tarball) patch creation, the manual method became too tedious for me
<mdz> lamont_r: yeah, that's the dependency trail for cvs
<lamont_r> figures.
<pitti> jbailey: it lacks patch editing, and it cannot handle tarballs for now
<pitti> jbailey: that should be added too, since dbs-edit-patch is still pretty clumsy
<amu> kdewebdev, quanta, cvs could be removed from desktop, if someone wants it, he can easy install it
<lamont_r> mdz: ISTR that being that it got pissed when it couldn't ask a question
<jbailey> pitti: Cool.  I'll pull it into Debian soonish, and see if it looks safe for after preview-freeze.
<mdz> lamont_r:     open(STDIN,  "<$file") or die "Couldn't reopen stdin";
<mdz>     my $file = ($ENV{DEBIAN_FRONTEND} eq 'noninteractive') ?
<mdz>         '/dev/null' : '/dev/tty'; # see 4.13 changelog entry
<pitti> jbailey: hmm, I didn't submit it until now since it really needs patch editing, too
<mdz> lamont_r: surely you're using DEBIAN_FRONTEND=noninteractive?
<pitti> jbailey: however, I can try to implement that this evening if you want
* lamont_r puts $5 on &*%)_(^)()&%^*(+)&*(^ udevd
<lamont_r> s/d$//
<lamont_r> we prevent udevd from starting, but don't prevent the postinst from trashing /dev for us
<Riddell> lamont_r, mdz, amu: if it's causing problems then remove it
<mdz> Riddell: it's not causing the problem, but it's triggering one
<jbailey> pitti: If you're willing, that would be fabulous.
<jbailey> pitti: And the nice part is that these pieces will move directly to cdbs2.
<pitti> jbailey: I think it is really necessary now that I promoted cdbs so much for MOTU :-)
<Riddell> yep
<jbailey> pitti: *lol*  That's also incentive for me to hack on cdbs2.  Maybe this weekend.  Get seb128 off my back ;)
<seb128> no no no
<pitti> jbailey: what's cool in cdbs2?
<seb128> multi-build
<seb128> we need it :)
<pitti> seb128: btw, do you already have some tools for simple-patchsys.mk patch management?
<pitti> seb128: like people.debian.org/~mpitt/cdbs-new-patch ?
<lamont_r> mdz: let me ponder this while I drive back home, and I'll get livecd.sh happy again.
<mdz> ok
<jbailey> seb128: Multibuild, documentation, clearer source code, and no ordering dependancies.
<Kamion> mdz: I'm heading off now; I've added cron.kubuntu-daily-live to cdimage/bin/ on little, so if you need to run that (and no other builds are happening), feel free
* lamont_r fears he may have to insert a 'install and shoot udev' stage between debootstrap and apt-get install $LIST
<mdz> Kamion: ok
<Kamion> should work :-)
<mdz> Kamion: any special procedures if I need to edit it?
<mdz> in terms of syncing up with your archive, etc.
<pitti> jbailey: documentation? YEAH
* lamont_r heads home, having only been parked in the 2hr parking for 2.5 hours
<Kamion> mdz: I can't imagine you'd need to edit that script, but probably best just let me know for tomorrow and I'll commit changes
<jbailey> pitti: The trick with cdbs2 is that there's a 'debian/rules help'
<jbailey> pitti: (that already works)
<jbailey> pitti: So everytime you define a function, you can easily add documentation.
<Kamion> mdz: more likely you might need to edit URLs in cdimage/debian-cd/tools/add_live_filesystem, which isn't in revision control yet
<jbailey> pitti: Later plans include some hackery to be able to automatically turn those into manpages.
<pitti> jbailey: I spent half an hour and a FTBFS upload to find out that configure/packagename:: is broken :-/
<pitti> jbailey: rocks
<jbailey> pitti: Oh, yeah.  That's all redesigned.  It confuses *me* on a regular basis.
<jbailey> pitti: Build passes are labeled per multibuild pass.  packaging passes are done by package name.  They are not otherwise linked.
<jbailey> pitti: That was the mistake we made, trying tom combine the two.
<abelli> smurfix: ping
<pitti> jbailey: what's multibuild?
<pitti> jbailey: like libc does?
<pitti> jbailey: -static, -dynamic, or -fast, -debug?
<mdz> Kamion: ok
<jbailey> pitti: Multibuild is like nano, and nano-udeb.  Configured twice with different options.
<smurfix> abelli: 
<jbailey> pitti: But a better example is abiword.  You have abiword-gnome, abiword-gtk, and abiword-plugins.
* pitti is amazed about smurfix' new ping symbol
<seb128> pitti: totem-xine toem-gstreamer :)
<pitti> jbailey: I want it. Now. :-)
<smurfix> pitti: That was a "pong". Ping is .
<pitti> smurfix: oh, sorry :-)
<jbailey> pitti: So that requires two build passes, and three packaging passes.
<pitti> smurfix: they look all the same in my small font :-)
<smurfix> pitti: They're intended to. Look at the bottom part more closely.
<pitti> smurfix: ah, indeed :-)
<seb128> pitti: nop, no such tool ... I grab it, thanks :)
<abelli> smurfix: have you got time or not?
<seb128> pitti: I like cdbs because usually I make diff on the CVS and cvs diff -u > patch :)
<abelli> smurfix: i really feel bad about this :(
<sivang> seb128: if someone clicks "cancel" in the gksudo window, what's the return code?
<Kamion> oh, damn, cron.kubuntu-* were building Ubuntu by mistake. Fixing ...
<sivang> seb128: (I want to take care for the case in which a user cancelles)
<seb128> $ gksudo ls; echo $?
<seb128> 2
<sivang> seb128: right, thanks :)
<srbaker> is there a source where i can get tomboy for warty?
<abelli> mako: ping
<jinty> cheers sivang
<lamont> right then
<mdz> lamont: any relevations on the way home?
<lamont> yeah.  I'm going to beat udev to death in it's own little world
<mdz> if udev gives you grief, why not use a static /dev?
<lamont> I just can't wait for the first moron that build-depends: udeved
<lamont> udevd
<lamont> that's the issue - I need to finish crippling it
<lamont> udevd doesn't run, but the postinst does lots of painful stuff taht I need to undo
<mdz> udev-without-udevd should work OK too
<HrdwrBoB> \\\\\\\\\\\\\\\\\
<HrdwrBoB> sorry kitten attack
<lamont> kittens are never sorry
<HrdwrBoB> haha true
<lamont> mdz: so don't do a livecd rootfs build for a minute, eh?
<mdz> lamont: ok
<pitti> seb128, jbailey: http://people.debian.org/~mpitt/cdbs-edit-patch
<pitti> seb128, jbailey: this now can both edit and create patches
<lamont> mdz: the issue is that the udev package hijacks /dev..  if you don't run udevd, then you need to unhijack it.  yet one more apt-get added.
<pitti> seb128, jbailey: argh, I just noticed a bug, hold on
<lamont> do we have a kubuntu-live yet? or still  using ubuntu-live?
<mdz> kubuntu-live |       0.28 | http://us.archive.ubuntu.com hoary/main Packages
<mdz> kubuntu-live all the way out to the mirrors
* lamont changes that too
<lamont>         kubuntu)
<lamont>             LIST="ubuntu-base kubuntu-desktop kubuntu-live"
<mdz> ubuntu-base gets installed by debootstrap; shouldn't need to think about it at all
<seb128> cool
<lamont> mdz: no it doesn't:       debootstrap --exclude=udev,ubuntu-base $STE $ROOT $MIRROR
<lamont> udev _can't_ be, which means ubuntu-base mustn't be.
<mdz> eeewwww
<lamont> mdz: trust me, you don't want to read this code...
<lamont> and somewhere cupsd got into the picture, and screwed things up for me as well.
<mdz> it really ought to be possible to get udev working properly in the chroot
<mdz> this is getting pretty gross
<pitti> jbailey: updated, fixed bug
<mdz> mvo: here?
<mvo> mdz: yes
<lamont> mdz: the issue is killing it later
<lamont> I suppose eventually I'll have to just kill everything that has open fd's under chroot-livecd... hrm,
<mdz> mvo: hi, sabdfl and I were discussing language pack installation, and were wondering what the best way would be to queue a package for later installation
<mdz> mvo: in order to handle the case where the user's language is not on the CD, and the network is not available (but the network will become available later)
<mdz> mvo: I considered that we could use the new hook facility, but I wonder if there isn't a better way
<jbailey> pitti: Does this script really have bashisms in it? 
<mvo> mdz: do you want to do the install with synaptic or apt or shouldn't it matter?
<mvo> mdz: we could add persistenty to apt (like aptitude has it now)
<mdz> mvo: yes, something like dselect-upgrade but for synaptic
<abelli> is it possible to use an hoary kernel with warty without breaking anything?
<mdz> mvo: this doesn't currently exist, though, right?
<mvo> mdz: no, there is only "synaptic --set-selections" (which can be used to install stuff non-interactily)
<mdz> abelli: hoary kernels require hoary versions of some supporting tools; they're not directly installable on Warty
<abelli> mdz: thank you very much
<pitti> jbailey: hmm, dash -n is successful
<zul> Mithrandir: ping are you going to be around in about 2 hours?
<pitti> jbailey: OTOH, who cares?
<mvo> mdz: it's trivial to add a "synaptic --selections-file", but I think this quite what we need
<mvo> ?
<jbailey> pitti: Well as a hint, cdbs2 is based in shell and works on posh. =)
<pitti> jbailey: do other shells unterstand ${x%foo} ?
<jbailey> pitti: Yes, that's generally posix-safe.
<pitti> jbailey: works in dash, too
<mdz> mvo: I don't think we should implement something new at this point in the release cycle; just considering the options which are already available
<jbailey> cool.  Although dash isn't a posix shell.  It doesn't support array's.
<pitti> jbailey: uploaded with #!/bin/sh
<jbailey> pitti: Thanks! =)
<mvo> mdz: you basicly want to queue a package for install with synaptic on the next start of synpatic?
<jbailey> pitti: As for why I care, there are debian derived distros that ship without bash for embedded targets.
<pitti> ah
<mdz> mvo: we would want to queue a package for installation when network repositories become available
<jbailey> pitti: So I try to keep cdbs as pure as I can.  (as well as other tools that I write).  
<pitti> jbailey: so you will adopt this into the Debian version?
<jbailey> pitti: Yes, sometime this weekend.  I'll clear it with mdz for post preview-freeze for Ubuntu after I can answer his grilling questions about it ;)
<mdz> jbailey: who what?
<pitti> jbailey: cool, my first contribution to my favourite build system :-)
<jbailey> pitti: See?  he asks hard questions. ;)
* pitti chuckles
<jbailey> mdz: Patch manipulation script for cdbs.  Should be low impact and make many MOTUs very happy.
<pitti> mdz: do you think the addition of a "cdbs-edit-patch" into cdbs would affect the freeze in any way?
<mdz> jbailey: user-level stuff, not build-time changes?
<pitti> mdz: entirely a developer tool
<pitti> mdz: just adds /usr/bin/cdbs-edit-patch, and that's it
<mdz> I don't see a problem with it
<pitti> mdz: I used cdbs-new-patch for a long time now, now I upgraded it to patch editing
<pitti> ogra: so it seems your MOTU crew eventually gets a good cdbs patch tool :-)
<mvo> mdz: the current code can't do that. persistency is not implemented (only at the --set-selections level) and it does not distinguish between local vs networked packages. persistency is easy to add (~20 lines of code), local vs networked might be a bigger problem
<ogra> pitti: yeah
<mvo> mdz: I can make a persistency patch for review if you want (tomorrow morning)?
<mdz> mvo: well, it's a bit simpler than networked, "when the package becomes available" is really the right semantics
<mdz> mvo: no, I really don't think it would be wise to extend synaptic for this during the freeze
<mdz> we need to focus on fixing the bugs we have
<ogra> pitti: trulux just showed me his selinux package, you would have to review it too (NEW and security related)
<sivang> pitti: you're adding the patch script to cdbs? 
<pitti> sivang: maybe, but if jbailey adds it to debian as the only change, we can just sync it
<mvo> mdz: ok
<trulux> ogra: oh, thanks for noticing it
<trulux> mdz, jdub: the mailing list should be created ASAP if possible
<jbailey> pitti: Debian's version has already moved on from where Ubuntu's is.  It'll have to go in as a patch against cdbs.
<mdz> trulux: keep nagging jdub until he creates it
<pitti> jbailey: okay, then I'll do that
<jbailey> pitti: Cool, thanks. =)
<trulux> mdz: ok :)
<lamont> mdz: thanks for the critical comments about udev... :-)  I think it looks more elegant now, and should be more resilient, too.
<lamont> "because once you have tac-nukes, everything starts to look like a small city"
<mdz> lamont: glad to hear it. are we ready for another test detonation?
<lamont> my test is still running, and I haven't cloned the script around yet
<lamont> PIDLIST="$(ls -l /proc/*/root 2>/dev/null | grep -- " -> ${ROOT%/}" | sed -n 's/^.*proc.\([0-9] *\).*$/\1/p')"
<lamont> is just not a nice thing to do, you see.../
<tritium> lamont, what is that quote from?
<lamont> tritium: I really can't remember
* lamont screams, pounds livecds on the table
<ajmitch> jbailey: who's hacking on cdbs2?
<lamont> tritium: was a phrase I picked up somewhere between 6th and 8th grade, lo these many years ago.
<jbailey> ajmitch: I am, occasionally.
<tritium> lamont, ok, thanks :)
<mdz> lamont: EW
<mdz> lamont: would it be worth it to make the chroot a mount point just to be able to fuser -m -k ?
<lamont> mdz: remember when I did that and elmo had a fit?  'k.
<mdz> heh
<mdz> no, but I can imagine
<lamont> -rw-r--r--    1 root     root            2 Mar  3 21:28 null
<lamont> hrm...
<lamont> mdz: very bad to kill init
<lamont> on a box with no remote console.
<lamont> elmo was in london that day, by chance. :-)
<lamont> ISTR you said to use fuser -m -k then too... :0)
<mdz> I didn't say to use it on the root filesystem...
<jbailey> Kamion: HerE?
<lamont> mdz: that was _chrooted_
<mdz> lamont: the "try it without the -k first" was implied :-P
<lamont> apparently if it can't read something or other, it  faults to including it.
<lamont> yeah, well.
<lamont> you seemed so confident... :)
<jon1012> hi everybody :)
<mdz> lamont: I think I would like to see the script
* mdz braces himself
<sabdfl> seb128: around?
<lamont> mdz: give me a couple minutes
<seb128> sabdfl: yes
<sabdfl> seb128: have a small change with big impact i'd like to make w.r.t. nautilus
<seb128> oh ? which one ? :)
<sabdfl> it's the folder browsing, i'd like the default left-double-click action to be open new folder, closing old one
<seb128> switch left click/middle click actions ?
<T-Bone> sabdfl: trying to work around "open everything in the same window", heh? :)
<sabdfl> T-Bone: trying to find sanity
<T-Bone> hehe
<sabdfl> spatial is nice, clutter is not
<T-Bone> definitely
<seb128> sabdfl: that will start some long discussion again probably, and that's against spatial according to upstream IIRC but easy to do :)
<sabdfl> thought so
<jbailey> sabdfl++
<jbailey> stop the insanity =)
<sabdfl> i'll have the discussion tomorrow, but could you work up the patch please?
<seb128> sabdfl: I'll change that tomorrow, prepare to some fun on the lists :p
<seb128> sabdfl: k, should I upload ? or just get the patch and wait for the upload ?
<sabdfl> thanks. will wear teflon
<T-Bone> jbailey: indeed :)
<sabdfl> upload
<seb128> np, better to do yeah :)
<sabdfl> we'll ask for forgiveness tomorrow
<seb128> k
* T-Bone calls it a night, bye all
<sabdfl> night T-None
<ogra> sabdfl: my shift key already loves you ;)
<ogra> for that...
<sabdfl> send me the love guys, i can use it for the hoary+1 name debate too :-)
<T-None> yeah same here
<T-None> though it'll looks a bit surprising for the average user
<T-None> -s
<abelli> sorry what font has been used for ubuntu logo?
<sabdfl> abelli: custom one
<sivang> pitti: I need to loose gnome_cups_spawn, it spawns asynchronously. I need synchronous spawning :-/
<abelli> sabdfl: we are working on the new italian website
<sivang> pitti: creates locking and status problems for me
<pitti> sivang: hmm, async is not that bad ?
<pitti> sivang: okay, if sync is easier, do it
<sivang> pitti: yes, but for this purpose, i need _sync_ not sync
<abelli> ...the last remaing thing is how to write "ubuntu-it.org"
<sabdfl> abelli: only have the letters ubnt
<sabdfl> clone it :-)
<abelli> sabdfl: thank you very much indeed...
<abelli> ciao
<sabdfl> sorry!
<abelli> sabdfl: is smurfix the only one i should speak with for domain problems?
<lamont> sabdfl: wish we'd gotten a complete character set...
<sabdfl> lamont: can do, if we need it
<lamont> although ubuntu-nt is pretty doable, eh?
<lamont> "need" is a pretty strong term
<pitti> ogra: btw, nice meeting today, and nice report
<mdz> seb128: is there a bug open about the fact that the mixer applet opens a dialog if there is no sound device?
<mdz> seb128: I can't find one
<mdz> but with bugzilla, that doesn't mean it isn't there
<seb128> no
<abelli> pitti: im going to branch, your baz archive, ill use it with a friend that is helping, am i allowed?
<mdz> I really think it shouldn't display a dialog
<seb128> I don't think there is one
<ogra> pitti: thanks.... was quite exciting...(first meeting i held on irc ever)
<pitti> abelli: sure, you don't need permission to branch an arch tree :-)
<seb128> mdz: right, the dialog is not really useful for anybody
<pitti> abelli: can you please set up commit notifications and CC me?
<abelli> pitti: obviously..
<pitti> abelli: I can send you my arch hook script if you want
<mdz> seb128: should I file a bug for you, or no?
<abelli> pitti: T H A N K S
<seb128> mdz: please, just as a reminder
<pitti> abelli: http://people.ubuntu.com/~pitti/arch-commit-mail-hook
* pitti -> testing new live cd, brb
<trulux> oops
<trulux> too bad
<trulux> # CONFIG_SECURITY_NETWORK is not set
<lamont> Preconfiguring packages ... 
<lamont> postdrop: warning: unable to look up public/pickup: No such file or directory
<trulux> # CONFIG_SECURITY_SELINUX_MLS is not set
<lamont> I hates packages what send mail
<trulux> thse *needs* to be fixed ASAP
<trulux> pitti: this is a big issue
<trulux> BIG issue :(
<ajmitch> trulux: you shouldn't need MLS
<ajmitch> but you will want networking hooks
<trulux> ajmitch: of course
<mdz> it was not big enough to notice weeks ago when it would have been a small matter to change it
<mdz> we are in a very strict freeze for the preview release right now
* lamont feels near-victory
<mdz> lamont: yes, but at what cost? ;-)
<lamont> 4 umounts and 2 mounts
<lamont> oh, and a 'kill_users()' function
<lamont> udevd doesn't start when you're chrooted with start-stop-daemon diverted, you see...
<lamont> mdz: did we decide that all the locale.gen stuff can go away?
<mdz> lamont: yes
<mdz> language-pack-en takes care of it for us
<lamont> ok
<lamont> gonna have to talk about that in the bastard-stepchildren bof, you know...
<mdz> udevd shouldn't need to start
<lamont> right.
<mdz> what caused your /dev/null to go missing?
<lamont> but if it's not started, then the postinst really shouldn't depopulate /dev
<lamont> udev
<lamont> or rather, udev.postinst
<trulux> mdz: I noticed it when trying to compile latest vsecurity, a new re-structured version
<trulux> and doing debian packaging
<trulux> will re-compile thge kernel
<lamont> which happily built a new /dev, and counted on the (unstarted) udevd to populate trivial things like /dev/null.
<lamont> or somesuch
<lamont>     # I really, really, really hate udev some days.
<lamont>     chroot $ROOT apt-get -y install udev < /dev/null
<lamont>     kill_users
<lamont>     umount ${ROOT}/dev/shm || true
<lamont>     umount ${ROOT}/dev/pts || true
<lamont>     umount ${ROOT}/.dev || true
<lamont>     umount ${ROOT}/dev || exit 5        # this one is fatal
<lamont>     mount -tdevpts none ${ROOT}/dev/pts
<lamont>     mount -ttmpfs none ${ROOT}/dev/shm
<lamont> I suppose that technically, I don't _HAVE_ to umount /.dev
<mdz> lamont: it looks like what you need to do is create /dev/run-udevstart
<lamont> to cause udevd to run?
<mdz> no, to cause your device nodes to be created when udev is installed
<mdz> I'm not sure, though
<mdz> I'd really like to see the script
* lamont finally mirrors his archive, so mdz can see it
<mdz> lamont: I don't have any problem installing cvs in a chroot here
<mdz> I don't understand the original cause of the problem
<lamont> mdz: is that with no tty, or with one?
<lamont> and the issue is that udevd got stubbed out, and winds up with a rather unpopulated /dev - hence unmounting that /dev is the trivial route to go
<mdz> root@mizar:/# DEBIAN_FRONTEND=noninteractive apt-get install cvs </dev/null >/dev/null 2>&1
<mdz> root@mizar:/# dpkg -l cvs
<mdz> ii  cvs            1.12.9-9       Concurrent Versions System
<lamont> what I really would like to do with udevd is install it last, but leave it unconfigured.
<lamont> but that'd pollute the ramfs with all of /dev,  which is bad
<mdz> I really don't think it should be a problem to let debootstrap install udev as normal
<lamont> might not be now that I have kill_users
* lamont will try that next
<mdz> I don't even end up with udevd running in the chroot when I try it here
<mdz> oh, is the host system not using udev in your case?
<lamont> ps aux| grep udev
<lamont> buildd   15246  0.0  0.0  1536  452 pts/0    S+   22:34   0:00 grep udev
<lamont> nope
<mdz> hmm, I can't test that easily
<lamont> test is running.  poor terranova
<mdz> lamont: at what point does /dev get mounted?
<lamont> somewhere in debootstrap
<mdz> Setting up udev (0.050-3ubuntu5) ...
<mdz> I: Configuring udev...
<mdz> Populating the new /dev filesystem temporarily mounted on /tmp/dir.Oxx7q2/...
<mdz> that's what happens here
<mdz> and at the end of debootstrap, /dev is a plain static dev
<mdz> ah, never mind
<mdz> it does in fact
<pitti> night everybody
<mdz> night
<lamont> night pitti
<abelli> pitti: ciao
<abelli> sweet dreams
<pitti> thx
<abelli> pleasure... may pax be with you
<abelli> :))
* sivang goes to sleep after endless fights with gnome_cups_spwan wrt #2251, hope to finish it tommorow.
<sivang> good night all !
<lamont> son of beech
<mxpxpod> how long will it be before the new 2.6.11 is in hoary's repos... I see that 2.6.11-0.2 is in there, but I'm guessing those are pre-releases
<lamont> as usual, mdz is correct (well, ignoring the whole fuser thing...)
<lamont> mxpxpod: once fabbione gets back from his honeymoon, I expect he'll package it
<tseng> mxpxpod: there is a freeze on main for the upcoming preview
<lamont> tseng: 2.6.11 is universe
<sivang> mdz: what I learend, he always is :-) (so when he says something I just take it for granted)
<tseng> hm
<sivang> oops
<sivang> lamont: ^^^
<mxpxpod> lamont: ah, cool... when did he get married?
<tseng> oh thats right it has a versioned package name
<lamont> mxpxpod: couple weeks ago, iirc
<mxpxpod> how long has his honeymoon been?
<lamont> couple weeks.
<mxpxpod> dang
<mxpxpod> my honey moon was a couple of days
* lamont forgets exactly when he's due back
<lamont> mxpxpod: my honeymoon consisted of taking the week off work and playing tourist 40 miles from the house
<mxpxpod> lamont: heh, I went to a tourist trap for mine
<mxpxpod> and it was only like 2 hours away from where we live
<HrdwrBoB> lamont: haha Kim would have my head if I did that :/
<HrdwrBoB> we are going on a cruise
<jbailey> Mine consisted of the train ride from Vancouver back to Toronto. =)
<HrdwrBoB> away from everything
<mxpxpod> jbailey: heh
<jbailey> It was lovely.
<lamont> jbailey: San Jose -> San Fran
<lamont> about 3 times
<jbailey> lamont: There's something cool about being in first class on a train for 3 days, though. =)
<lamont> yeah
<lamont> rode coach from Laramie, WY to Oakland, CA once.  ~24 hours of almost entirely train (with a bus from Ogden to SLC to switch train lines)
<zul> Mithrandir: ping
<Mithrandir> zul: pong
<luis_> blah
<zul> Mithrandir: come to #ubuntu-kernel for a sec
<luis_> mdz: you around? (or anyone who is an expert on the liveCDs?)
<luis_> for some reason the 'pool' directory on my CD is filling up ridiculously, going from 7M to 499M for some reason.
<luis_> needless to say it cramps my CDs a bit ;)
<luis_> oh.
* luis_ bets this is somehow related to not updating the manifest
<lamont> I don't remember seeing this before.... warning: updatedb: could not open database: /var/lib/slocate/slocate.db: No such file or directory
#ubuntu-devel 2005-03-15
<bob2> gah
<bob2> firefox popup!
<tseng> mjg59: seen http://lkml.org/lkml/2005/3/3/130?
<mdz> luis_: yes
<mdz> lamont: that's normal when slocate is freshly installed, before cron.daily runs
<lamont> mdz: ah, then I _did_ see it before
<lamont> btw, 1.3 GB fsimage
<mdz> lamont: excellent!
<lamont> archive mirrored
<mdz> luis_: that's very strange, I don't know of any reason why pool/ would get larger
<mdz> luis_: where this is using the process in the wiki?
<luis_> mdz: basically the process in the wiki, yes
<mdz> lamont: so that's 1.3G compressed, meaning we need to do some subtraction?
<darklight> im abelli... good night everyone
<mdz> lamont: or 1.3G uncompressed, meaning we're in business?
<mdz> luis_: that process doesn't change pool at all...it just copies it out and back in
<lamont> uncompressed - it's compressing now
<darklight> and "have a nice day" for everyone on the other side :)
<luis_> and at some point between uncompressing the daily livecd (with a pool of ~8M), installing a slew of packages, and recompressing the CD, pool grows to ~499M 
<mdz> luis_: the manifest is purely informational
<mdz> luis_: what does du say is taking up all that space?
<luis_> mdz: tons of new packages showing up in pool
<sabdfl> night guys
<zul> nigh sabdfl 
<luis_> I'm currently recompressing something, in a few minutes I can give an exact count, i guess
<mdz> sabdfl: looks like we'll have kubuntu live CDs to play with tomorrow
<Nafallo> night sabdfl 
<darklight> sabdfl, ciao
<darklight> smurfix, u there?
<sabdfl> mdz: krock!
<sivang> night sabdfl 
<sabdfl> kthxbye
<mdz> luis_: packages??
<luis_> mdz: yeah
<mdz> luis_: as in, .debs?
<lamont> mdz: hrm.. one more little tweak in BuildLiveCD and we're done..  (dropped a link)
<luis_> mdz: or at least .debs, 1164 of them
* mdz checks to make sure that the wiki instructions haven't changed since the last time he looked
<mdz> there is just no way
<mdz> lamont: let me know when to fire cron.daily-kubuntu-live
<mdz> luis_: in what directory are they placed?
<zul> mdz: care to comment on #7155 about the linux security modules networking hooks?
<luis_> mdz: extracted_cd/pool/main/ mostly
<luis_> (all but 11)
<luis_> well, the subdirs thereof
<mdz> luis_: you must be rsyncing an install CD onto a live CD
* luis_ ponders
<mdz> or something like that
<luis_> ah-ha
<luis_> mdz: vice-versa, but yeah
<luis_> that would explain
<luis_> mdz: $ rsync --exclude=/casper/filesystem.cloop -a mnt/ extracted_cd
<luis_> that already had an install CD, by accident, underneath it
<luis_> well, possibly
<luis_> at least, I accidentally downloaded an install CD this morning
<dholbach> i'm off to bed... sleep tight everyone
<mdz> the instructions are written such that there would be a live CD mounted there
<luis_> right
<luis_> well, i think I downloaded and mounted the install CD before realizing it
<luis_> and did not clear out extracted_cd before downloading the liveCD and restarting
<luis_> it has been... a very long day
<mdz> :-) here too
<mdz> but we're very close
<luis_> yeah
<luis_> indeed
<luis_> press release wrapped up this afternoon
<luis_> have to cross the is and dot the ts on the livecd
<luis_> or, uh, something like that
<ogra> guys we have a discussion about vim-gnome .desktop file in -motu ... it is listed here: http://www.ubuntulinux.org/wiki/UniversePackageWithoutDesktopFile do we want one ?
<zul> yes
<mdz> ogra: sounds like a question for the desktop team
* ogra remebers a eary warty bug 
<ogra> early even
<mdz> ogra: https://bugzilla.ubuntu.com/show_bug.cgi?id=7059
<mdz> soemone filed a bug just recently, perhaps one of the people involved in the discussion?
<mdz> ogra: I passed it off to jdub for a desktop team answer
<ogra> ah, ok... i'll bug him about it
<jdub> mdz: < mdz> trulux: keep nagging jdub until he creates it
<jdub> mdz: what was that about?
<mdz> jdub: mailing list
<ogra> jdub: selinux
<jdub> mdz: don't have any pending atm
<mdz> jdub: ok, I just assumed that since he was asking "where is it?" that he had actually asked you for it :-P
<luis_> mdz: I HUG YOU
<luis_> :)
<jdub> trulux mentioned some security lists he wanted you to confirm, but without details
<jdub> those?
<jdub> luis_: how's livecd going?
<seb128> jdub: and the desktop files for g-a-i ? :)
<luis_> jdub: better than it was about 10 minutes ago
<seb128> jdub: I want to update the panel tomorrow with the pending changes :)
<mdz> luis_: hehe, no problem
<luis_> jdub: nothing like creating two 1.1G isos to just continue a string of bad news for the day
<seb128> (ie: menu switch and that)
<tseng> I think we agreed to make a "hardened" or "security" mailing list over selinux, no?
<jdub> seb128: how long will you be sleeping? ;-)
<jdub> seb128: have you done Preferences <-> Administration?
<ogra> jdub: i was there when he mentioned them... i think he meant these
<jdub> luis_: d'oh!
<luis_> jdub: yeah
<seb128> jdub: nop, but that will be uploaded tomorrow, I'm looking on it right now
<trulux> mdz: best name?
<jdub> seb128: cool
<jdub> hardened-ubuntu@ ?
<seb128> jdub: sleeping about 8h :)
<jdub> unbreakable@ ?
<trulux> jdub: ubuntu-hardened
<trulux> haha
<luis_> jdub: it's not good when your first step of the day is spending 1/2 hour downloading an install CD instead of a liveCD, and that is the /best/ thing in your day for 5-6 hours
<jdub> seb128: there'll be a present under your pillow then ;)
<jdub> luis_: ah, crap
<seb128> jdub: BTW have you read about the nautilus change ?
<jdub> seb128: not yet
<seb128> cool
<zenwhen> so is array six still tenatively set for tomorrow?
<luis_> but, I have an iso now
<tseng> zenwhen: or yesterday
<mdz> jdub,trulux: ideally something general enough for all proactive security stuff (stack smash protection, MAC, etc.)
<jdub> luis_: so LA had a forum about linux on the desktop yesterday
<luis_> and I finally bought CD-RWs
<seb128> jdub: Mark asked to switch left/middle click behaviour in spatial
<luis_> jdub: linux.au?
<zenwhen> oh
<jdub> luis_: novell dude (greg keiser if you've met him, south african APAC dude) was great
<jdub> luis_: sun and red hat were appalling
<trulux> mdz: then ubuntu-hardened sounds appropiate
<Nafallo> ubuntu-hardened, that wont break my .procmailrc ;-)
<trulux> mdz: are you proud of it?
<luis_> jdub: cool
<jdub> luis_: linux.org.au, yeah (pia is vp)
<trulux> Nafallo: :D
<mdz> trulux: works for me
<mdz> or maybe ubuntu-hardening?
<trulux> mdz: fine
<mdz> what fits best with the other lists
<trulux> 3 2 1 sold
<trulux> ubuntu.hardened
<luis_> jdub: yeah, just took me a bit, I was wondering why you'd be in los angeles for a bit
<trulux> err -
<jdub> seb128: left/middle click? as in the popup menu on drop?
<trulux> mdz: better to do as the other lists, append the topic 
<seb128> jdub: no, like open with or without closing
<trulux> ubuntu-hardened
<jdub> trulux: with our desktop backgrounds, that's a dangerous name :)
<zenwhen> o:
<jdub> seb128: oh, for double-click
<seb128> jdub: double left click or double middle click
<jdub> seb128: yeah, okay
<seb128> yeah
<mxpxpod> since we're closing in on freeze of main, is there any chance we can update the gtkmm packages?
<Nafallo> at what point is new LoCo-teams mailinglists created btw? :-)
<trulux> jdub: haha
<Nafallo> mailed mailman a week ago or something...
<jdub> Nafallo: erk, don't mail mailman
<jdub> Nafallo: mail the list admin, ie. me :)
<Nafallo> jdub: wiki/LoCoHowto or something :-P
<trulux> jdub: then ubuntu-hardened, finally if mdz does not say the opposite
<jdub> seb128: would be a great bonus to have a gconf key for it, but your call :)
<tseng> mxpxpod: er, those are in main?
<seb128> jdub: yeah, I think so
<mxpxpod> tseng: I think the gtkmm stuff is
<ogra> jdub: btw, no calendar this month ?
<jdub> seb128: then at least upstream may take it :)
<seb128> jdub: that will make some long discussion again ;)
<jdub> ogra: calendar's uploaded
<seb128> jdub: I don't think so
<jdub> ubuntu-calendar_5.03_source.upload ubuntu-calendar-march_5.03_source.upload
<jdub> seb128: don't think upstream will take it?>
<ogra> ah, didnt check my mailbox
<seb128> jdub: nautilus' list has already some discussion with such patch IIRC, that's against spatial mode ...
<mxpxpod> tseng: because there are some undefined symbols in the release we have in main
<Nafallo> jdub: done :-)
<trulux> jdub: when do you think you could create it?
<jdub> trulux: straight away with mdz's confirm
<trulux> btw
<seb128> jdub: remember this big patch during 2.7 to change spatial mode on some point ?
<trulux> gnome-backgrounds conflicts with ubuntu-artwork
<jdub> trulux: usually better to make these requests by email
<jdub> yeah, known bug
<trulux> mdz: can you confirm?
<seb128> jdub: IIRC this was one of the change, and the upstream advice reply is "that's not spatial mode"
<jdub> seb128: nah, they were all conflated
<tseng> mxpxpod: ugh. i think youll have to wait until after preview, then clear it with jdub and mdz. is it breaking something in desktop?
<mxpxpod> tseng: no, it's just annoying when I'm trying to develop coaster :)
<seb128> jdub: maybe they will take it, let's write the patch we will see :)
<trulux> jdub: email?
<jdub> mxpxpod: gtkmm is in the gnome release set, it will be updated until gnome release
<mxpxpod> tseng: I'm trying to use TargetLists and there's an undefined symbol to the create method of them
<jdub> trulux: when you're asking for lists and things like that, it's usually better to make the request by email, because then you guarantee the details are tehre and the person has it
<jdub> trulux: find for now
<jdub> fine
<jdub> unless mdz is already asleep
<jdub> in which case i'm happy to take any hits if it's a bad name
<zul> jdub: i have a gamin question for you
<trulux> jdub: just that I'm also near to go to bed
<trulux> and I will be away for 2 days :(
<mxpxpod> jdub: in that case, can we get gtkmm updated to 2.5.7 and glibmm to 2.5.6?
<trulux> nite
<zul> jdub: is it possible to blacklist directories such as /media and such
<jdub> trulux: so you're not going to be able to use the list anyway? :)
<jdub> zul: 0.0.25 should deal with that
<trulux> not in 2 days
<tseng> jdub: it doesnt
<mdz> lamont: ISO build succeeded, downloading now
<zul> jdub; is 0.0.25 available?
<jdub> tseng: bummer
<jdub> zul: it's in hoary
<tseng> at least not here
<zul> ok cool
<seb128> 0.0.25 pool on /media, no ?
<seb128> poll even
<jdub> that's what i've found
<mdz> Riddell: still here?
<tseng> it says its fixed, but I see the same bug
<jdub> mdz: ok with 'ubuntu-hardened'?
<mdz> yes
<tseng> ie, usb devices not picked up in drivemount-applet and desktop
* jdub sees luis-having-a-bad-day footers on lots of mail
<tseng> actually, my ipod is working
<tseng> ignore me, i tested it with a usb2 drive enclosure yesterday with no luck
<jdub> tseng: try that one again?
<tseng> will do.
<jdub> ta
<jdub> going back to dnotify, we need to make sure it's not used on those dirs :)
<tseng> actually, when I tested i think i was using inotify
<tseng> using dnotify atm
<tseng> might make a difference
<seb128> probably does
<jdub> shouldn't make *that* particular difference - that's bad! :)
<tseng> the other usb drive is happy now
<Loevborg> copying to a usb stick is 10x slower using nautilus than using "cp" - is that a known issue?
<jon1012> Loevborg> maybe the sync after that will be faster with nautilus than cp ?
<jon1012> did you try the "sync" command after ?
<Loevborg> jon1012, no, it's really slower.
<Loevborg> jon1012, I umounted after.
<jon1012> ok... :-/
<jdub> ogra: motu meeting summary is great!
<ogra> jdub: thanks :)
<tseng> it was a productive meeting
* jdub is very happy with the outcomes
<GheRivero> res people
<jdub> hey GheRivero 
<sivang> summery sent to -devel ?
<sivang> (motu meeting)
<ogra> yup
<sivang> ogra: cool, sorry I couldn't be there, I am trying to finish something for preview
<ogra> sivang: same here ;)
<sivang> ogra: so you didn't attend?
<sivang> ogra: :)
* sivang is confused
<ogra> sivang, sometimes i cant avoid doing both ;)
<jdub> luis_: there?
<luis_> yeah
<sivang> ogra: ah :)
<mxpxpod> jdub: I just filed some bugs on glibmm and gtkmm
<Nafallo> dooh. you guys should have alias like irc-nick@ubuntu.com ;-). jdub I hope my mail arrived this time :-P.
<jdub> luis_: http://people.ubuntu.com/~jdub/2005/ubuntu-on-the-desktop/
<jdub> if you're interested
<jdub> Nafallo: yeah, only have name-based email addresses :)
<sivang> jdub: cool presentatoin, I'll translate and do it over here :)
<luis_> you know, I think if you airbrushed out her nipples people would comment a lot less on all the skin ;)
<jdub> we did on the cd cover :)
<zenwhen> "totally rad laptop support"
<zenwhen> Well I have to agree
<zenwhen> hoary is a dream on my laptop
<mdz> jdub: that's what I heard we were doing, but my CD covers say otherwise
<zenwhen> and its a 266Mhz P2 junker
<jdub> sivang: also ~jdub/2004/ubuntu-1-2-3/
<zenwhen> I use xfce
* jdub goes to look for nipple.
<jdub> nipplehunt
<zenwhen> hot
<jdub> oh, it's more subtle on the cd cover
<tseng> on gdm she has on the high beams
<zenwhen> no no the nips really "sood out" to me
<zenwhen> stood out
<zenwhen> they really "poke out" at you and make you notice them
<jdub> tseng: yeah, didn't bother with that one. alternate theme and all. ;)
<sivang> jdub: cool
<lamont> another voice ^T&_(*& telephone automated system defeated
<zenwhen> I "stood at attention" and was quite "interested"
<jdub> Nafallo: swedish team isn't listed as official yet
<zenwhen> no inuendo there at all
<tseng> ill test /media and inotify for you in a few jdub 
<jdub> thanks tseng 
<whiprush> jdub: mind if I rip some of those for a LUG presentation?
<jdub> whiprush: up
<jdub> whiprush: nup
<jdub> i should make my upload script add creative commons logos and shit :)
<mako> herzi: herzi yes.. that's correct
* whiprush is combining some existing presentations into one uber one.
<luis_> what are you guys going to ship the april release with? ooo 1.1 or 1.9?
<jdub> luis_: looking like 1.1 atm
<GheRivero> anybody knows was going on with the server [team|edition] ?
<jdub> but 2.0 is in
<luis_> in universe, though, right?
* luis_ is pondering switching to 1.9 for the liveCD
<luis_> <cough>
<luis_> blah
<jdub> luis_: it's in main
<luis_> I left xpdf on the liveCD
* luis_ goes to fix that
<jdub> GheRivero: we don't have a separate server edition
<ogra> urgh
<jdub> GheRivero: but jbailey is the man to speak to about the server team
<jdub> GheRivero: and java stuff
<jdub> luis_: evince for great justice!
<mdz> kubuntu-live IS GO
<jdub> yay!
* ..[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 | If your system hangs at login on Hoary, upgrade to kernel 2.6.10-24 | http://cdimage.ubuntu.com/kubuntu/daily-live/current/
<luis_> that is bizarre
<luis_> xpdf claims not to be installed
<luis_> but it is right there in /usr/bin/xpdf
<ogra> only i386 :(
<Nafallo> jdub: ehm. pt, es, fr seems to exist? where to go official? Not LoCoTeamList?
<mdz> ogra: my friend, this is the _very first working kubuntu live cd_
<jdub> Nafallo: see http://www.ubuntu.com/wiki/LoCoTeams
<mdz> other architectures are being built as we speak
<jdub> mdz: lorenzo is adminning -hardened, yeah?
<ogra> mdz: i know, but i had to give away half of my HW last week when i resigned...no i386 around :(
<mdz> jdub: up to you, listmaster
<mdz> ogra: are you starting a new job?
* jdub grumbles about hackers avoiding policy... ;)
<ogra> mdz: curretly i'm jobess
<ogra> mdz: i applied at credativ....but will have to wait
<tseng> ogra: good luck!
<jdub> ogra: you want to be a kubuntu hackeur? :)
<tseng> im waiting to hear back on a job as well
<ogra> at least i feel really better now
<mdz> how do I take a screenshot in KDE?
<jdub> ogra: you didn't seem happy where you were - yucky place?
<ogra> jdub: nah, just wanted to see the amu work :)
* wasabi kicks tomboy in the shins
<jdub> ogra: (i mean wrt credativ)
<tseng> wasabi: chill out, im on it
<ogra> jdub: ah....
<tseng> im blaming dbus atm
<wasabi> oh i suspose you know what im talking about then? :)
<ogra> jdub: there is always somwthing behind the desktop ;)
<tseng> wasabi: crasher?
<wasabi> not exactly...
<tseng> lets hear it
<wasabi> it starts, waits for about 15 seconds, then exits.
<wasabi> All done. Ciao!
<tseng> oh thats a case of you arent following upstream crack smoking
<tseng> its an applet now
<wasabi> oh super
<wasabi> whaaaa
<tseng> or you can force it with --tray-icon
<ogra> jdub: and i have no idea for what i applied actually....i would take anything related to OSS i think
<wasabi> oh looky there, sure nuff
<wasabi> never even noticed
<mdz> http://people.ubuntu.com/~mdz/kubuntu/kubuntu.png
<wasabi> eww no transparent background either
<ogra> hmm, looks like ked
<ogra> kde even
<sivang> ogra: working on oss is a dream, I wish you luck also :)
<tseng> ogra: because it is :P
<tseng> nasty as ever
<ogra> heh
<ajmitch> ogra: where are you working now?
<ajmitch> between jobs? :)
<ogra> sivang: i wont take anything else :) my initial spark for writing the actual resignation was my boss denying linux at my workplace after three years
<tseng> he's a full time hack-a-thon
<ogra> ajmitch: currently i live from my savings and probably some bounty work..... afetr three months i'll get my dole....
<ogra> which is 63% from my last loan which was high enough to be happy with 63%
<ajmitch> I hope you get a job before then
<sivang> ogra: well, what can I say? I have been in numerous work places that denied linux altogether, I'm glad I am not working for them anymore.
<lamont> mdz: so how does update-inetd decide whether it's interactive or not??
<sivang> ogra: all the best then :)
<mdz> lamont: $DEBIAN_FRONTEND
<ogra> ajmitch: depends on what comes around....else i'll start freelancing (i got many friens in it companys)
<ogra> sivang: thanks :)
<luis_> jdub: have two seconds I can pick your brain during?
<lamont> Template: debconf/frontend
<lamont> Value: Noninteractive
<lamont> does that get downshifted, I wonder?
<jdub> luis_: sure
<Nafallo> well, night all
<jdub> luis_: two seconds is not a lot of cpu power ;)
<bob2> what's the magic boot option to not copy .debs onto the disk?
<luis_> jdub: are you guys planning a graphical boot/installer at some point in the near future?
* lamont tries downshifting
<mdz> luis_: yes
<luis_> next release, or further out?
<jdub> luis_: it's on the list for discussion/specification at UDU; might be next release.
<mdz> bob2: archive_copier/copy=false
<mdz> bob2: but 1.5G still isn't enough, I don't think
<bob2> mdz: hah
<bob2> mdz: I thought 1.2 for base, 600MB for .debs
<tseng> jdub: /media, gamin, inotify .. fail on both devices
<jdub> tseng: does it fail to monitor, or does it somehow lock them?
<tseng> it mounts them, which comes up in nautilus
<tseng> but it fails to show up on the desktop on drivemount-applet
<tseng> do you have a more scientific test?
<jdub> mdz: so, if you choose a locale in the installer that is not shipped on the cd, do we have an option to download it during install?
<mdz> jdub: yep
<jdub> rad!
<mdz> if you answer "yes" to the question
<mdz> then it just does it
<zul> ogra: you get no EI for 3 months?
<jdub> awesome
<ogra> zul: yup, german law....if you resign yourself
<zul> ah i c
<mdz> luis_: graphical installer is very likely for the next release, graphical boot quite likely but lower priority
<ogra> zul: but the 63% for a year
<ogra> then even
<Riddell> mdz: looks nice, is that ISO available somewhere?
<tseng> http://cdimage.ubuntu.com/kubuntu/
<mdz> Riddell: /topic
<zenwhen> kubuntu was a good idea
<tseng> jdub: do you have a specific test I should try re gamin?
<zenwhen> keeps the install to one cd and 
<jdub> tseng: pull the source package, there are tests in there
<zenwhen> keeps me from downloading kde libs and things i dont need to install ubuntu when i get images
<tseng> sure
<Riddell> mdz: and the .1 version of the install CD, that's been rebuilt to work now too?
<jdub> tseng: i imagine it's the inotify backend lagging a bit in the latest releases
<jdub> need some refactoring for common functionality
<mdz> Riddell: it should be.  I haven't tested it, but would appreciate it if you could do so
<Riddell> mdz: great, will download it overnight
<mdz> lamont: do we have amd64+powerpc kubuntu cloops?
<lamont> not yet.
<lamont> Setting up cvs (1.12.9-9) ...
<lamont> Couldn't reopen stdin at /usr/sbin/update-inetd line 29.
<mdz> Riddell: Kubuntu or KUbuntu?
<mdz> lamont: I recommend editing =update-inetd and changing that line to:
<mdz> open(STDIN,  "<$file") or die "Couldn't reopen stdin: $!"
<Riddell> mdz: good question
<lamont> Name: debconf/frontend
<lamont> Template: debconf/frontend
<lamont> Value: Dialog
<lamont> Owners: debconf
<lamont> Flags: seen
<lamont> how the hell did that happen
<Riddell> mdz: the former I think.  /me never liked the name anyway
<mdz> Riddell: what's the usual scheme in the K community?
* lamont preseeded it...
<lamont>     my $file = ($ENV{DEBIAN_FRONTEND} eq 'noninteractive') ?
<lamont>         '/dev/null' : '/dev/tty'; # see 4.13 changelog entry
<sivang> anybody have any idea what should I give gksudo when spawning it using g_spawn_sync so it would *kindly* ask for the current user password rather then root's one?
<lamont> so when the field in the file is 'Noninteractive', does that check still do the right thing?
<Riddell> mdz: when K is used as a prefix the second upper case does usually seem to be kept
<jdub> generally not when you can say it though
<jdub> KParts vs. Kate
<tseng> jdub: happen to know what tests do polling?
<lamont> mdz: because /dev/null is there, etc, etc.  With no controlling tty, though , the build fails
<jdub> tseng: not offhand
<Riddell> jdub: but KThesaurus and KPackage, but if kubuntu is just one word then it should be Kubuntu
<tseng> jdub: this test suite looks like voodoo magic mostly.
<Riddell> cos k-ubuntu sounds daft
<jdub> tseng: welcome to DV :)
<mdz> lamont: I suggest adding some debugging, both $! and the value of DEBIAN_FRONTEND
<mdz> lamont: it seems likely that DEBIAN_FRONTEND is coming through as dialog
<jdub> Riddell: i think Kubuntu is a good brand name; Ubuntu KGX is another good option, that might encourage further buy-in from upstream.
<jdub> Riddell: but i think they'll buy in anyway :)
<mdz> lamont: and so it's actually trying to open /dev/tty
<jdub> Riddell: eh, did you listen to the latest lugradio?
<tseng> you build a small program and run it against a series of script files
<tseng> which is fine.. but the output isnt very comprehensible
<mdz> thom: I don't suppose you're awake
<Riddell> jdub: yes I did, very good stuff (although their Scottish accents could do with some work)
<jdub> tseng: just check the output against the example output :)
<tseng> expect line 5: got 2 of 3 expected events
<thom> mdz: i never like the sound of that :-)
<jdub> Riddell: ha ha
<tseng> cuz 2 out of three aint bad
<jdub> Riddell: kubuntu pimp action :)
<mdz> thom: good morning :-)
<lamont> mdz: it became Dialog after I tried setting it to 'noninteractive' (instead of 'Noninteractive'), the former being an invalid value
<thom> mdz: good evening; how are you this freezing day?
<mdz> thom: I was thinking it might be nice to have a torrent for the kubuntu test image
<tseng> jdub: in that case, i think test 4 fails
<mdz> lamont: that's odd; "noninteractive" should be correct
<Riddell> who is the ubuntu artist?  I was thinking about this for a logo http://muse.19inch.net/~jr/tmp/kubuntu1.png
<mdz> lamont: even debconf itself uses that test
<mdz> if (lc Debconf::Config->frontend eq 'noninteractive' &&
<Riddell> the top one obviously
<lamont> Choices: Dialog, Readline, Gnome, Kde, Editor, Noninteractive
<mdz> lamont: though I suppose debconf/frontend is the value of the select item, and not the true name of the frotnend
<jdub> Riddell: btw, the new kde logo is cool
<lamont> I see no 'noninteractive' there
<thom> mdz: sounds doable
<thully> before I rsync, is the kubuntu daily install ISO currently working?
<Riddell> jdub: are you just saying that because of the similarity to the gnome one? :)
<lamont> the other challenge is that update-inetd is getting installed from the true archive...
<jdub> Riddell: it may have had some sentimental familiarity ;)
<Riddell> thully: unknown, nobody has tried it as far as I know
<lamont> otoh, netbase is installed by debootstrap... gah. what evil.
<lamont> (me, not it)
<Riddell> jdub: are we sorted on the applications.menu scheme, are you going to patch ubuntu's gnome packages to use gnome-applications.menu?
<thom> mdz: is this an omg-right-this-second request, or can i do it in the morning? (sleep is a very tempting option)
<jdub> Riddell: yep
* lamont waits for his test to finish
<mdz> lamont: Uploading via ftp netbase_4.19ubuntu4_source.changes: done.
<mdz> thom: well, in your morning, I'll be asleep, and won't be able to make the announcement
<mdz> thom: so about automating the seeding...;-)
<thom> oh, fair point
<thom> yes; its on the todo list
<mdz> it's not critical that we have a torrent
<lamont> mdz: I just stomp on the file between the debootstrap and apt-get stages. :-)
<mdz> I just figured it'd be nice, since it's likely to get a lot of attention
<thom> mdz: it's totally doable now
<thom> mdz: just tell me which iso you want torrentable, and it shall be done
<mdz> thom: the one in the topic
<thom> okiedokey
<mdz> I generated the .torrent already
<thom> yup
<thom> rsyncing now
<lamont> mdz: no such device or address. :-)
<mdz> lamont: /dev/tty, then?
<lamont> almost certainly.
<lamont> but I can't spell, so I'm running it again to get the frontend var in the die call
<thom> mdz: being seeded now
<mdz> lamont: or you can just use the new netbase :-)
<mdz> thom: thanks
<thom> give it about 5 minutes for processing and it should be good to go
<lamont> given that the buildd hasn't built netbase yet...
<mdz> thom: I just fired up a seed locally, and there is already traffic on it
<mdz> it just maxed out my upstream
<zenwhen> have array six clean install reports been mostly positive?
<mdz> zenwhen: seems that way
<thom> mdz: i think we're hitting each other; i have a download running on a host remotely; they're both waiting on torrent.u.c to finish processing and give peering love
<thom> which has now happened
<thom> mdz: i was pulling 50K/sec off you, now closer to 2MB/sec with orcadas in the picture
<mdz> yep
* thom toddles off to bed
<mdz> thanks
<thom> np
<lamont> Couldn't reopen stdin No such device or address  at /usr/sbin/update-inetd line 29.
<lamont> is printed by: open(STDIN,  "<$file") or die "Couldn't reopen stdin $! $ENV{DEBIAN_FRONTEND}";
<lamont> so me thinks it's empty...
<mdz> interesting
<mdz> hmm, we should have torrented the install CD too
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<schweeb> jdub: frightening
<mdz> I don't see freedom.  I only see grapefruit juice
<schweeb> jdub: how bandwidth intensive is that?  you goin through a ton of bw on your linode (I'm assuming that's where this is streamed through)
<jdub> schweeb: yeah, upstreamed to the linode; pushing 90kbit/s per stream atm.
<lamont> mdz: thoughts?
<lamont> WTH does update-inetd need to open a file anyway?  Why not try opening /dev/tty, and if that fails, open /dev/null?
<mdz> lamont: did you find out why debconf/frontend was wrong?
<lamont> uh, it's set to Noninteractive in config.dat (became Dialog only when I changed  that to noninteractive in the seed), and it's empty in update-inetd
<lamont> ] <lamont> Couldn't reopen stdin No such device or address  at /usr/sbin/update-inetd line 29.
<lamont> <lamont> is printed by: open(STDIN,  "<$file") or die "Couldn't reopen stdin $! $ENV{DEBIAN_FRONTEND}";
<lamont> you;ll note a double space after the 'address'
<lamont> ==> empty
<lamont> and empty != 'Noninteractive' :-(
<tseng> does anyone know of a package using dpatch and not cdbs for me to look at?
<mdz> lamont: export DEBIAN_FRONTEND=noninteractive?
<mdz> tseng: emacs21
<tseng> mdz: thanks.
<tseng> this is silly, why would a package (ldaptor) have a ton of files -w
<tseng> its a native package
<jdub> mdz: heh, s/KUbuntu/Kubuntu/ ;)
<lamont> tseng: postfix
<mdz> jdub: bleah, I regret asking :-)
<tseng> got one, just thought include dpatch.make was a cdbs thing
<tseng> this python package does an explicit (<< 2.4), might be bad news =/
<lamont> mdz: yep.  weddell finished first. :-)
<tseng> hm newer one in debian, might want to sync it
<tseng>     - Clean up and python2.4-proof LDAPAttributeTypeAndValue parsing.
<jdub> Riddell: if you've switched to kde-*.menu, there's not much poitn changing the gnome stuff
<Riddell> jdub: but but it would be unfair if you didn't
<jdub> ?
<bob2> wow, first spam to keybuk-sponsoring-me@debian.org
<bob2> took only 2 days
<Riddell> jdub: just seems unfair if we have to change and gnome doesn't 
<jdub> so the spec optimises for a common menu
<jdub> thus the central applications.menu file
<jdub> we have distro policy reasons for using a different kde menu structure to gnome's
<jdub> which may or may not be the right way to go about it
<jdub> but that's what we've decided for now
<jdub> so given that, we've resolved the namespace issue
<Riddell> jdub: yes
<Riddell> I still think it's unfair that KDE has to change and not gnome, but I won't cry too much over it
<zul> jdub: still no 0.20
<jdub> Riddell: it's a kde change; there's no point churning for the sake of it
<calc> just make kde's menu structure look the same as gnomes? ;)
<jdub> well, we could use a common structure
<jdub> but that's getting close to LCD suckage
<jdub> which i really want to avoid
<jdub> cf. red hat
<Riddell> that's the other option but it does require renaming icons and various other playing about
<Riddell> jdub: LCD?
<calc> what would be wrong with just using the gnome menu layout on kde?
<jdub> lowest common denominator
<jdub> Riddell: nah it doesn't
<Riddell> who is the ubuntu artist?
<jdub> there is no single artist
<jdub> andy fitzsimon is doing a contract to create our icons
<jdub> we have other designers contracted for cd covers, etc.
<tseng> ogra: if a package is building 2.3 and 2.2
<tseng> ogra: do we make it just 2.4, 2.4 and 2.3, or what?
<jdub> i've done some of the artwork
<Riddell> jdub: any thoughts on a kubuntu logo?
<jdub> should probably hug the kde style more than the ubuntu style
<jdub> how about asking kde-artists?
<jdub> that'd energize upstream :)
<Riddell> yeah.  kde-artist.  that.  I'll try and bounce it off tackat
<whiprush> replace the gear with the ubuntu circle, that'd look neat.
<jdub> abusing the ubuntu logo is kinda problematic
<whiprush> upstream would probably think the same.
* lamont makes an early night of it
* whiprush shuts up with his hairbrained ideas ...
<jdub> nah, it's a good one, but stupid technicalities get in the way
<jdub> i liked Riddell's gears in the same shape
<Riddell> http://muse.19inch.net/~jr/tmp/kubuntu1.png  just needs someone with tallent to perfect it
<Riddell> and i need to get an SVG 'k' off tackat
<whiprush> heh, clever.
<jdub> what do you call gears on the inside?
<jdub> perhaps those would be cool
<whiprush> If I'm reading google right, the big one is called the wheel, and the smaller ones are called pinions
<mdz> kubuntu.png is on distrowatch already
<Riddell> didn't take them long
<mdz> #4 on the 6-month chart now
<mdz> their announcement is better than mine :-)
<tseng> cdbs-edit-patch rocks
<bob2> hah
<bob2> mdz: do you happen to remember which bug # is "ipv6 makes dns slow"?
<mdz> bob2: https://bugzilla.ubuntu.com/show_bug.cgi?id=2381
<bob2> ah, thanks
<mdz> (no, but I searched for it ;-) )
<bob2> bugzilla's search thing appears to not actually do anything
<mdz> that is true of the simple search
<bob2> ah
<mdz> but the advanced search works
<mdz> 69.109.184.174 - - [04/Mar/2005:02:21:31 +0000]  "GET /~mdz/kubuntu/kubuntu.png HTTP/1.1" 200 109718 "http://forums.somethingawful.com/showthread.php?s=&threadid=1481466" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0"
<mdz> now spread to somethingawful
<bob2> hahahaha
<hiweed> thank u, bob2
<jdub> mdz: ha ha
<bob2> web forums truly bring out the best in people
<bob2> from the stupid nicks, abusive taglines, terrible spelling, it's all there
<zenrox> thx bob2 i love you too
<zenrox> lol
<hiweed> hey all, I am the team leader of Hiweed-Debian GNU/Linux. I wanna join the Ubuntu Developers team. How to?
<bob2> whats "hiweed-debian gnu/linux"?
<tseng> hiweed: hi, see http://www.ubuntulinux.org/wiki/MOTU please
<hiweed> bob2: http://linux.hiweed.com
<tseng> chinese localized distro it looks
<hiweed> yeah
<tseng> http://freshmeat.net/projects/hiweed/?branch_id=51410&release_id=188054
<tseng> I can actually read that one.
<hiweed> hehh
<hiweed> thanks tseng.
<tseng> if you are interested in translation, youll want to look to the docs team instead
<hiweed> no thanks
<tseng> MOTU is for up and coming package maintainers
<hiweed> I am interested in the Chinese relative pacakges 
<hiweed> hehh
<hiweed> thx tseng
<tseng> no problems. good luck
<hiweed> :)
<jbailey> tseng: If you're still looking for a package which uses dpatch without cdbs, glibc sort of qualifies ;)
<tseng> jbailey: nope, but thanks
<thully> hi - anyone tested Kubuntu ISO yet?
<thully> I just did - it works
<mdz> kubuntu live-i386 works fine for me, of course.  I'm trying install-amd64 now
<thully> I used install-i386
<thully> One small little question - any clue on how to get icons on the KDE root menu?  There are very few icons on the KDE root menu
<Riddell> thully: you'd be wanting the KDE 3.4 packages to solve that
<thully> OK - is that what's likely going to be released with Hoary?
<thully> or is Kubuntu on an independent release cycle?
<Riddell> deb http://jasmine.19inch.net/~jr/away/kubuntu/ ./
<Riddell> thully: kubuntu will be released with hoary (fingers crossed et al)
<thully> Will these enable udev/hal recognition of CDs, USb sticks, ...?
<Riddell> future releases should be released with ubuntu as well but may be delayed if there's a KDE release coming out shortly after
<Riddell> thully: with any luck yes
<thully> Why not just bring the KDE 3.4 beta packages into Hoary, in the same way the GNOME 2.10 beta packages are?
<Riddell> thully: because I only just finished compiling them and they should be tested first
<thully> so, is it looking like Hoary will release w/3.3 or 3.4?
<thully> Is there any chance we may see Firefox as the browser (instead of Konqueror) in KUbuntu - I've found Firefox faster and more reliable at rendering websites correctly
<calc> kde uses konqueror for a bit more than just a browser
<calc> interesting seeing luis in here
<jdub> calc: gnome livecd :)
<calc> ah i must just not see him much since i don't have net access at work
<thully> yes - but as a browser Firefox seems to be the better choice - Konqueror could still be there for file management, though
<calc> jdub: oh yea
<thully> Also, has the kdesu sudo issue been handled in KDE 3.4?
<Riddell> thully: that's on my schedule for tomorrow
<jdub> thully: probably best to take these questions to #ubuntu or #kubuntu
<thully> one more idea for kubuntu - use something like geramik or gtk-qt-engine to make the GTK apps look better in KDE
<jdub> thully: #kubuntu is the right place :)
<calc> port ClearLooks to KDE
<calc> keramik is vile on anything
<calc> and 3.4 uses plastik anyway
<thully> I just thought this had to do with Ubuntu development, as this deals with package choices and development of Ubuntu
<jdub> thully: the kubuntu developers maintain kde
<Amaranth> lets seem if totem crashes loading jdub's TV show again :)
<jdub> Amaranth: it's off
<Amaranth> oh
<thully> well, anything is better than just seeing GTK themes on KDE
<Amaranth> does kubuntu use gtk-qt?
<Riddell> Amaranth: not currently, it's a good idea though
<jdub> whiprush: http://www.metallikop.com/blog/index.php?p=60
<jdub> whiprush: heh
<jdub> *smack*
<whiprush> heh
<Amaranth> who here has seen the iTunes app talked about at http://www.advogato.org/person/rbultje/diary.html?start=90 ?
<whiprush> he knows it isn't the default.
<whiprush> He should embrace the nakedness.
<jdub> lord knows we do!
<Amaranth> if you've used it, did it play m4a preview files?
<calc> Amaranth: i have heard rumors of one like that, that also has the feature of no DRM
<Amaranth> if so, what did you do?
<Amaranth> calc: It exists. ;)
<jdub> so
<whiprush> Everyone gets excited when it's the blonde's turn for ubuntu-calendar.
<Amaranth> ubuntu-calendar? where is that? :)
<jdub> i have a cool idea for anyone who wants to do a bit of gnome hacking
<calc> Amaranth: yea i just tried encoding a file to m4a using faac and found that 1. ubuntu's faac is broken and 2. it appears faac doesn't work on amd64 anyway
<Amaranth> calc: faad
<Amaranth> gstreamer-faad is hopeless
<calc> the broken bit has to do with faac not supporting encoding to mp4/m4a/etc
<calc> Amaranth: faad spit a bunch of errors
<jdub> make something (gnome-settings-daemon most likely) monitor the currently selected background image and/or xml file
<jdub> so when it changes, the background refreshes
<jdub> thus, when doing an ubuntu-calendar-* upgrade with the monthly calendar chosen, you'll get the new desktop immediately
<Amaranth> jdub: Out of my league, I'm a pygtk hacker. :)
<Amaranth> oh, ubuntu-calendar is a background?
<jdub> i should blog this
<calc> automagic pr0n updates
<calc> Amaranth: so would you know how to make faac encode a file so that faad can decode it without errors?
<Amaranth> calc: Nope, I'm as clueless as you.
<calc> Amaranth: ok
<Amaranth> Pretty sad, I helped write code that plays an m4a file with gstreamer and I can't even use it. :P
<calc> it hasn't been updated in a long time so i wouldn't be surprised if its not 64bit clean
<bytee> jdub: hey dude. i'm still unpacking ;)
<whiprush> jdub: sounds like a gnome-love kind of thing.
* bytee looks around for an ubuntu hoary box
<bytee> btw, does ubuntu/ppc run on the PegasosPPC boxes? i've got one sitting here..
<jbailey> bytee: You can't install it, but after you get past that, it runs. ;)
<jbailey> bytee: I got Debian on mine, and then upgraded it to Hoary and it's my main machine now.
<jbailey> bytee: Have to be a bit careful with the kernels.  Need to tweak the initrd settings, and I use grub2 to boot.
<Amaranth> install something that will run on it and use their bootloader?
<calc> Amaranth: this is what i see btw: Warning: Pulse coding not allowed in short blocks
<jdub> bytee: yo!
<jdub> bytee: ph#?
<Amaranth> calc: I have no idea. :)
<bytee> jbailey: ok. so its an installer issue. well when i get past getting fedora running on it, i'll try ubuntu
<calc> Amaranth: ok
<mdz> jdub: a/s/l?
<Amaranth> calc: I'm just trying to get gstreamer to work, period. Most of the time totem and rhythmbox won't play anything (gstreamer issues) and this app won't play an m4a using gstreamer.
<calc> -1/n/hell
<jdub> mdz: u want 2 see my cam??!?!
<jbailey> bytee: Sure.  I don't know if we provide debootstrap as a separate package that can be run on rpm systems, but if not, Debian does, and you can use that to install an Ubuntu system.  Not ideal, but official Pegasos support isn't due until the release after Hoary.
<Amaranth> jdub: lugradio didn't make fun of your name, i'm surprised
<bytee> jbailey: cool
<jdub> Amaranth: not after i drew crop circles in their front lawns with our orbital laser platform
<Amaranth> hehe
<Amaranth> you cried on the phone about it before the interview? ;)
* Amaranth hides
<jdub> haha
<bob2> lugradio seems pretty dodgy
<Amaranth> holy shit, gstreamer-faad is working
* Amaranth cheers
<tritium> warning re: evolution 2.1.6 - it forces the user to setup an email account.  A way around it is to use "None" for server type and sendmail as sender.
<tritium> my wife (who only uses the calendar and contacts) discovered this today
<calc> Amaranth: yea its a 64bit issue i guess, i installed the 32bit versions and it seems to work fine
<calc> Decoding cdda.aac took:  3.73 sec. 86.52x real-time.
<jdub> http://www.gnome.org/~jdub/blog/projects/ubuntu/1109907672
<jdub> if anyone's interestedr
<jbailey> jdub: Right.  What's an Ubuntu Calendar Background? =)
<jdub> jbailey: apt-get install ubuntu-calendar
<jdub> jbailey: not work safe
<jdub> jbailey: ... ! :-)
<jbailey> jdub: I'll make sure my boss isn't looking over my shoulder. ;)
* Liblit waves to mdz.
<jdub> yo Liblit 
<jdub> you were quick :)
<Liblit> Hey, jdub.
<Liblit> Oh, jdub == Jeff Waugh.  How 'bout that?
* Liblit waves to jdub.
<Liblit> Well, I'm sitting here sucking down Hoary CD images, so I figured I'd drop by and say hello.
<jbailey> jdub: Ah, handy.
<jdub> jbailey: see the recommends for more
<jbailey> jdub: Mmm, neither of those seem to have recommends or suggests on them.
<Amaranth> jbailey: get ubuntu-calendar-december
<jdub> jbailey: ubuntu-calendar does
<jdub> hrm
<jdub> hrrrm
<jbailey> jdub: Perhaps apt-cache is defective for me then.
<jdub> weeeeiird
<jdub> Recommends: ubuntu-calendar-october, ubuntu-calendar-november, ubuntu-calendar-december, ubuntu-calendar-january. ubuntu-calendar-february, ubuntu-calendar, march
<jdub> that's in debian/control
<Amaranth> not in the deb :)
<tritium> so, by calendar, you can tell what month it is by the image?
<Amaranth> not as far as i can see
<tritium> (if you learn to associate an image with a month)
<jdub> aha
* jdub fixes.
<tritium> mdz, I saw mythtv-frontend in the UniversePackageWithoutDesktopFile wiki page, along with other multiverse packages.
<tritium> are multiverse packages okay to work on?
<mdz> tritium: if that's a legal question, I can't advise you
<mdz> Liblit: hello
<Liblit> mdz: Howdy.
<Liblit> mdz: Thought I'd come by and say hello while waiting for the Hoary CD images to come down my DSL pipe.
<mdz> Liblit: ubuntu or kubuntu?
* Liblit looks sheepish.
<Liblit> Umm, what's kubuntu?
<mdz> heh
<mdz> we just announced a preliminary test image today; it's rather new
* Liblit gets his Google on.
<mdz> an Ubuntu derivative with a KDE desktop rather than Gnome
<tritium> mdz, okay...well from your perspective, should multiverse packages be removed from that page, or would you welcome contributed .desktop files for multiverse packages?
<Liblit> OK, I suppose that was obvious enough.  :-)
<jdub> Liblit: Ubuntu... with a K! :)
<Liblit> jdub: :-D
<mdz> tritium: from my perspective as an Ubuntu developer, I would like to see proper .desktop files for most everything which is not installed by default
<Liblit> mdz: Well, in answer to your question: Ubuntu, not Kubuntu.  I happen to be partial to GNOME.
<jdub> where most everything == stuff that will be of direct interest to graphical desktop users :)
<mdz> Liblit: as am I, but to each his own ;-)
<mdz> it's a good step
* jdub will have a minor fit if we get psql.desktop or similar ;-)
<Liblit> mdz: Agreed.  Let a thousand desktops bloom.
<mdz> jdub: :-P desktop apps
<jdub> mdz: and none of this pseudo tv business! ;)
<jdub> i really should try mythtv soon
<jdub> are the latest releases cool for dvb?
<tritium> okay, just trying to get some guidance from you before I try to help.  Perhaps I'll not touch mythtv-frontend
<mdz> jdub: we ain't got no dvb in 'merica
<jdub> tritium: hold on, i'm kidding, it might be appropriate :)
* Liblit looks around for a spare hard drive on which to install Hoary.
<tritium> jdub, I'm here :)
<zul> *pphfft* americans :)
<jdub> mdz: so if i put a dvb enabled box in front of you at UDU... :)
<mdz> a .desktop file for mythtv-frontend would be an entirely appropriate thing to have
<mdz> jdub: I'll stare right through it?
<mdz> like the mad zombie that I will be?
<jdub> ok, don't leave burn marks or anything
<mdz> it'll be like the first week and the second week of an Ubuntu conference combined
<zul> i wouldnt mind some of the bof at the conference to be online
<zul> for those who cant make it
<tritium> mdz, I started to take a look at one, anyway.
<zul> anyways im going to bed
<zul> night
<hiweed> hey all, would you please tell me, who is resonsible for Ubuntu's Debian-CD package? I made a local ubuntu mirror( hoary/i386 only) and build a hoary-base iso using the debian-cd package downloaded from http://archive.ubuntu.com/cdimage/code/debian-cd.tar.bz2, but got a `kernel panic' error.
<hiweed> error screen shot: http://linux.hiweed.com/images/tmp/kernel-panic.png
<Liblit> hiweed: I have nothing useful to tell you, but I've got to ask: how did you take that screen shot?
<zul> hiweed: it cant find your boot block
<hiweed> I took that screen shot using VMware
<hiweed> the same error ocurred under qemu, too.
<hiweed> zul: thx. so I wondered what I had done wrong.
<tritium> mako, how do you prefer to receive signed codes of conduct?
<Liblit> hiweed: Aah, OK.  Thanks.
<hiweed> Liblit: nop :)
<sivang> morning all
<calc> hmm i see a few weeks ago ppl were ranting about gnome icons on ddl
<calc> are the icons they are talking about the ones in ubuntu as well?
* calc is pretty sure everaldo is on crack
<jdub> which icons?
<calc> the ones that people were saying were ugly (the default gnome ones)
<jdub> those people are stupid
<Amaranth> jdub: splash look awesome
<calc> it seems if its not at least as cartoony as keramik everaldo doesn't like it
<Amaranth> when will ubuntu get it in 2.9? :)
<jdub> the only suboptimal thing about the gnome icons is a few palette problems
<jdub> Amaranth: ubuntu has it's own splash
<Amaranth> :/
<jdub> Amaranth: but i imagine the file will be available in the next gnome-session upgrade
* calc likes the way gnome icons/theme look a lot better than kde
<jdub> Riddell: around?
<jdub> $ lsb_release
<jdub> LSB Version:    n/a
<daniels> jdub: you lie
<jdub> daniels: i do
<jdub> smelly hiding daniels!
<jdub> daniels: i think the fixes in 0.23.[12]  are worth it
<jdub> daniels: plus, beagle.
<daniels> jdub: mmm ... but if we break other dbus apps?
<jdub> via semantics changes?
<jdub> s/cs/c
<daniels> yeah
<daniels> that's what I'm most concerned about
<whiprush> inotify pretty much out for hoary at this point?
<jdub> whiprush: it's in, but not turned on by default
* whiprush nods
<sivang> jdub: do you know if there is a ready made GtkMessageDialog that returns a value accoridng to what the user clicked or must I use callbacks ?
<jdub> sivang: zenity. ;-)
<jdub> kinda different programming environment, of course.
<jdub> not sure.
<jdub> #gtk-devel or #gnome-hackers
<jdub> er, sorry
<jdub> #gtk+ or #gnome-hackers
<sivang> jdub: ah right :) thanks alot anyways!
<whiprush> jdub: Clearlooks olive on a chocolate background is awesome. To whom shall I make the bribery check to?
<jdub> whiprush: Richard Stellingwerff and Daniel Borgmann :-)
<whiprush> heh
<svenl> daniels: ...
<svenl> daniels: you still there ? 
<sivang> jdub: muntyan helped me :)
<sivang> jdub: on $gtk+
<sivang> jdub: we almost have one click enable ipp browsing support :)
<dholbach> hai
<sivang> hey dholbach 
<dholbach> hi sivan!
<jdub> sivang: rad
<sivang> jdub:  :)
<dholbach> tell pitti and jbailey, they rock, when they come, ok? i'm just out with my dog :-)
<sivang> hey dholbach :)
<doko> morning all
<sivang> morning doko
<pitti> Morning
<crimsun> morn'
<sivang> pitti: morning!
<sivang> pitti: I'm preparing patches, and a debdiff :-)
<sivang> pitti: couple of API reading, asking here and there, and we have a very nice result I think :-)
<pitti> mdz: here=
<pitti> s/=/?/ (grr)
<sivang> pitti: http://muse.19inch.net/~sivan/g-c-m_browse_support.debdiff :-)
<sivang> pitti: btw, could you tell me what is the service that needs restarting as well as cupsys to make the printers appear?
<sivang> pitti: (I might try add that later)
<pitti> sivang: I'm already working at that
<pitti> sivang: it's a bug in g-c-m
<pitti> sivang: it works if you have a local printer in addition :-)
<dholbach> hi pitti 
<dholbach> pitti: you rock!
<pitti> Hi dholbach 
<pitti> dholbach: I do?
<pitti> cdbs-edit-patch?
<dholbach> pitti: thanks for working on CDBS *big smile*
<pitti> no worries :-)
<dholbach> :-D
<pitti> I'm using it for myself a lot, too
<sivang> pitti: what's the bug number?
<sivang> dholbach: I also used pitti's cdbs-edit-path today :)
<pitti> sivang: http://bugzilla.gnome.org/show_bug.cgi?id=168881
<sivang> pitti: thanks
<kagou> hi
<sivang> pitti: strange bug
<kagou> i have somes ideas for the live cd ....
<kagou> I'v tested Slax/PClinuxOS/Live+ and hoary
<kagou> Hoary rocks with my wifi card
<kagou> but the look of gnome instead kde look of others distro is not pretty
<kagou> I think that the applet for keyboard selection must be installed by default with some layout (fr/de/ ...)
<kagou> and network manager applet must be loaded too
<kagou> May be the utilisation of gdesklets in the live cd can render the hoary live look more pretty
<zenrox> kagou,  the live cd is ment to run on all cpus even the little ones gdeklets and extra applets will slow the thang down
<kagou> zenrox, it was just an idea for the look
<Treenaks> talk about useful changelog entries:
<Treenaks>     - renamed prep-boot PReP boot partition name to prep.
<kagou> zenrox, what do you think about my ideas for applets ?
<jdub> kagou: we don't ship one yet
<jdub> kagou: it will most likely be on by default in the release after hoary
<kagou> thnx jdub :)
<sivang> morning sabdfl 
<svenl> Mmm, seems that the YDL ddcprobe code in their Xautoconfig works on pegasos, while the one in xresprobe fails :/
<sabdfl> svenl: send that code off to daniels, he might be able to figure out what's needed in xresprobe
<svenl> sabdfl: yep, i tried to speak to him directly, and i filled #7144 yesterday, but i guess we are too far in timezones or something, we might be able to figure that out ourselves, i think.
<svenl> sabdfl: xresprobe radeon only outputs the disptype right now, so this is why it fails, i think
<svenl> There is no man page for xresprobe though :/
<sabdfl> daniels: also, fglrx is still not happy with xorg 6.8.2 on my PCI Express X800
<Kamion> morning
<dholbach> hi Kamion 
<mvo> hey Kamion, hey dholbach 
<dholbach> hai mvo
<dholbach> mvo: i'll be back at home this afternoon, any plans for tonight yet? :-)
<mvo> Kamion: did you recovered a bit from the array marathon?
<mvo> dholbach: I play hockey tonight ... but after that :)
<dholbach> mvo: what about the mv-guy?
<Kamion> mvo: slightly; I plan to take this afternoon off in exchange (cleared with mdz)
<Kamion> still rather worn out
<mvo> Kamion: yeah! do that, it will be good :)
<jdub> mvo: have you noticed that update-notifier puts phantom spacing into the notification area?
<mvo> jdub: not really yet. is there a way to reproduce it?
<mvo> dholbach: let's phone when you back from your trip?
<dholbach> mvo: alright
<sabdfl> smurfix: are you around for a meeting with mako, jdub & me later?
<dholbach> bye everyone, see you later
<sivang> c'ya dholbach 
<dholbach> bye sivan
<sivang> going to get some sleep, laterz all
<pitti> sleep well, sivang
<Kamion> ok, let's see if this morning's kubuntu CD installs cleanly
<doko> who's reviewing patches, which should go to hoary? email to ubuntu-devel?
<Mithrandir> seb128: is it known that the location selector in the weather applet is broken?
<seb128> should be fixed is yesterday's upload
<seb128> what is broken now ?
<pitti> seb128: works fine for me :-)
<seb128> :)
<mvo> works for me too
<Mithrandir> seb128: let me run an update, then, and I'll see
<seb128> k
<Mithrandir> I mean, I haven't updated in 12 hours, so it might be fixed. :)
<seb128> that's fixed in 0ubuntu2 for gnome-applets
<Mithrandir> yeah, seems fixed.
<ajmitch> seb128: gnome-backgrounds has a conflicting file with ubuntu-artwork, btw
<seb128> known
<ajmitch> great
<Kamion> doko: for preview freeze, clear with mdz/jdub I believe
<sabdfl> Kamion: unexpected glimpse of a question about changing debconf priorities before reboot on last nights daily... should i file a bug?
<Kamion> sabdfl: yes please, include /var/log/*; that sounds like it fell off the end of the normal menu
<Kamion> /var/log/installer/* rather, I guess you've rebooted
<sabdfl> k willdo
<Kamion> today's kubuntu daily is fine in that regard, and should be the same ...
<sabdfl> kubuntu!
<pitti> sabdfl: do you know that "kubuntu" sounds in German like "colorful cow"?
<Kamion> haha
<jdub> ha ha
<d3vic3> hahaha
<sabdfl> moo hic?
<Kamion> kbuntu
<pitti> mooobuntu
<seb128_> grumpf, dsl hangup
<sabdfl> ok, we get to leave bouncing cow in that one
<pitti> seb128welcome back
<seb128_> :)
<pitti> wherehasmyspacekeygone?
<pitti> bah, debugging sucks today
<pitti> any gdb experts here?
<pitti> Program received signal SIGTRAP, Trace/breakpoint trap.
<pitti> [Switching to Thread -1233482832 (LWP 17121)] 
<pitti> 0xb79cd58e in __nptl_death_event () from /lib/tls/i686/cmov/libpthread.so.0
<pitti> impossible to debug a program with this :-(
<d3vic3> seb128_,  trying to overwrite `/usr/share/icons/hicolor/48x48/apps/gnome-run.png', which is also in package gnome-panel-data
<seb128_> what package is that ?
<d3vic3> seb128, gnome-icon-theme_2.9.92-0ubuntu1_all.deb
<seb128> and gnome-panel-data ?
<d3vic3> yes
<seb128> no
<seb128> what version
<mvo> seb128: can eggtrayicon have a transparent background? I got a bugreport that update-notifer looks "grayish" when the panel is set to a transparent background.
<Treenaks> mvo: just use a transparent png?
<seb128> mvo: dunno how the notify area handles transparent backgrounds
<d3vic3> seb128, doesn't say, I thinks its the latest becouse I'm trying to upgrade 
<mvo> Treenaks: the background of the icon is set to transparent
<pitti> mvo: btw, what should this icon represent? it is too small for the relatively complex graphics
<seb128> d3vic3: $ dpkg -L gnome-panel-data | grep gnome-run
<seb128> $
<rburton> mvo: i think there are hacky patches in bugzilla to make that work
<seb128> d3vic3: I don't get this file here, what version ?
<mvo> pitti: draw a better one? seriously, jdub told me that the artist who draws icons for us has the update-notifier icon on it's list
<pitti> mvo: ah, good to know :-) but what _is_ it currently?
<d3vic3> seb128, 2.9.90-0ubuntu1
<mvo> pitti: it's a scaled down version of the current synaptic icon :)
<seb128> d3vic3: update to 2.9.92
<d3vic3> ok 
<pitti> mvo: aha :-)
<jordi> mvo: did strings change since my last update?
<jordi> I found a typo anyway
<mvo> jordi: don't think so, synaptic is string-froozen. you are allowed to slap me if they did
<jordi> mvo: kewl
* jordi uploads alsa-utils.
* mvo checks if the strings really didn't changed 'cause he's afraid of jordi beating him up
<Treenaks> mvo: don't worry, he's out of shape :P
<mvo> jdub: any news from the person that draws the icons for us? people complain about the ugly update-notifier icon :)
<jordi> I've lost two kilos in the last two weeks or so
<mvo> Treenaks: I guess he's still in _far_ better shape than most other people :)
<jordi> fuck fuck fuck
<ajmitch> hey jordi 
<jordi> alsa-utils upload b0rjed
<jordi> borked even
<seb128> jdub: this about GNOME entry rocks :)
<jordi> damn ISP, closed my link
<jordi> ajmitch: hi andrew
<mvo> rburton: you don't have a bugnumber for the transparent thing by chance :) ?
<rburton> mvo: sorry. iirc it was mentioned on d-d-l recently
<mvo> rburton: I found something in bugzilla.g.o (no patch, but still :)
<pitti> yay
* pitti finally found a fix for g-c-m cupsys restart
<mvo> pitti: is this the stuff that shivang was working on? the gksudo problem ?
<pitti> mvo: related
<pitti> mvo: if you only have one printer and restart cupsys, then g-c-m does not display your printers any more
<pitti> mvo: that's the bug I chased now
<mvo> pitti: cool!
<pitti> mvo: sivang works on a frontend for enabling/disabling cupsys browsing
<pitti> mvo: if we have that, handling IPP printers is really easy
<mvo> pitti: yeah! how is his progress? 
<pitti> mvo: I already made the necessary cupsys backend changes, so it's only a matter of some gtk code
<pitti> mvo: sivan's patch works in general, but I had some nitpicks :-)
<pitti> mvo: he will continue it later/tomorrow
<pitti> mvo: -> nothing for preview maybe, but for final
<mvo> pitti: ok
<mvo> pitti: nice :)
<pitti> we really need to improve printing support...
<thom> 8.770  (4694.9 MB up / 535.3 MB down) (kubuntu live on my bittorrent client since last night)
<Kamion> where is \ on a German console keymap?
<pitti> Kamion: AltGr+
<pitti> Kamion: that's the key right of '0'
<Kamion> where is ? :-)
<Kamion> oh, thanks
<thom> Kamion: d'you wanna generate a torrent for the kubuntu installer?
<jdub> mvo: next icon drop :)
<mvo> jdub: great, can't wait :)
<Kamion> thom: it's only a daily, but sure
<Kamion> whoa, I confused cdebconf lots
<Kamion> it won't let me delete the full name in passwd.config now
<thom> Kamion: (mdz and i got the daily live torrent up last night)
<Kamion> yeah, I saw
<Kamion> thom: done
<Micksa> does gnome (or whatever) have some sort of pop-up-notification app?
<jdub> not really
<jdub> what for?
<jdub> depends what you need
<jdub> ooh, gaim just crashed
<Micksa> anything :)
<jdub> ...
<Micksa> like, one that you could configure to notify you of whatever
<jdub> do you want it to just randomly pop up notifications for no reason?
<Treenaks> Micksa: evolution
<jdub> if you want something that notifies about appointments, use evo
<jdub> if you want something to do the popping up, use zenity (for shell scripting)
<Micksa> man, I so gotta write an app for this
<Micksa> THEN I WILL HAVE MY FAME AND FORTUNE
<ajmitch> I thought you had to be a MOTU for fame & fortune? :)
<jdub> WARNING: SALES PITCH IN PROGRESS
<Treenaks> ajmitch: no, that's only the fame part
<ogra> ajmitch, yes, you have ;) morning guys
<ajmitch> Treenaks: true, I haven't seen much fortune coming in :)
<ajmitch> morning ogra 
<ogra> Micksa: if you only want something to pop up, have a look at zenity
<ajmitch> jdub: we're always trying to recruit..
<Kamion> jdub: ok to upload https://bugzilla.ubuntu.com/attachment.cgi?id=1509 for #668?
<jdub> Kamion: sure :-)
<ajmitch> ogra: gnomebaker would be fine to review if the person had supplied a source package :)
<ogra> heh
<mvo> lifeless: could you please check if #5412 (aptitude wants to remove running kernel) when you do your next upgrade? I believe it is fixed with the current aptitude version in hoary (not urgent, I'm just fostering my buglist right now)
* Kamion needs to get back into the habit of this ask-for-approval thing ...
<ogra> its a warty package anyway, if i understood it right
<ajmitch> ogra: I doubt there'd be much warty-specific stuff in the package except versioning, perhaps
<lifeless> mvo: yeah, will do.
<ogra> ajmitch, without a source its only a warty package ;)
<mvo> lifeless: great, thanks :)
<ajmitch> ogra: there are probably a few more package requests in the list archives that haven't made it onto the wiki
<ogra> ajmitch: hmm, do you think we need an additional announcement for UniveseCandidates ?
<ogra> +r
<ajmitch> possibly
<ajmitch> or we could trawl the archives for requests
<ogra> its been mentioned quite often...
<ajmitch> hi doko 
<doko> ajmitch: hi
<sabdfl> is postgresql not in main?
<Kamion> shadow (1:4.0.3-30.7ubuntu10) hoary; urgency=low
<Kamion>   * Never generate invalid default usernames (part of Ubuntu #668).
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Fri,  4 Mar 2005 11:09:13 +0000
<Kamion> oops
<Treenaks> sabdfl: it was in warty
<Kamion> cjwatson@rookery:~$ madison-lite postgresql
<Kamion> postgresql |    7.4.5-3 |    warty/main | source, amd64, i386, powerpc
<Kamion> postgresql | 7.4.5-3ubuntu0.4 | warty-security/main | source, amd64, i386, powerpc
<Kamion> postgresql | 7.4.7-2ubuntu2 |    hoary/main | source, amd64, i386, ia64, powerpc
<sabdfl> interesting
<sabdfl> it's not appearing on mpt's brand new hoary
<sabdfl> in synaptic
<sabdfl> any idea why?
<Kamion> did he answer "no" to "download packages from the internet"?
<Kamion> or did something go wrong in the second stage? I do know of one base-config bug in that area, that got introduced in the process of #6390
<mpt_london> Kamion: I didn't answer "no" to anything like that, but I think Mark did (if you mean during the install)
<sabdfl> yes, he answered no :-)
<sabdfl> Kamion: we should still enable network sources in apt.sources, even if the user doesn't do it right away
<sabdfl> Kamion: should i file a bug on that behaviour?
<sabdfl> any idea where postgresql-contrib has gone for hoary?
<ajmitch> sabdfl: universe, it seems
<thom> Kamion: torrents running for kubuntu installer
<Riddell> jdub: around now
<jdub> sabdfl: mdz and i had a long discussion about this
<jdub> sabdfl: came to the conclusion that it is desireable behaviour, but not until the tools improve
<sabdfl> jdub: please put a bof on that topic onto the list for UDU
<jdub> cool
<sabdfl> Kamion: what's your thought on enabling the network apt sources list irrespective?
<Kamion> 11:30 < sabdfl> Kamion: we should still enable network sources in apt.sources, even if the user doesn't do it right away
<Kamion> that's what we do, if you answer "yes"; the network is not used now *during* the installation, just set up for after it (and for language packs etc.)
<Kamion> sabdfl: mdz and I talked about that, and mdz felt that apt was not currently up to that
<Kamion> sabdfl: if you try that without a network, you get lots of error messages all the time
<Kamion> we should do better later, but I think the current behaviour (modulo base-config doing a slightly better job of cleaning up when stuff goes wrong) is about the best we can do for hoary
<Kamion> #6390 is a general bug about all of this
<Kamion> wow, something really made netboot astoundingly unhappy
<Kamion> INPUT <anything> / GO to debconf returns "100 problem"
* Kamion has never seen that particular error code before
<ajmitch> night all
<dredg> night ajmitch 
<dredg> have a good weekend :)
<Kamion> jdub: hmm
<Kamion> jdub: would there be a problem with forcing "yes" to that apt-setup question if a network is available?
<jdub> Kamion: one for mdz
<Kamion> jdub: I think the previous discussion was more about forcing "yes" to it regardless, which won't work yet
<sabdfl> night aj
<jdub> i'd lean to yes
<sabdfl> mitch
<Kamion> ah, in fact that appears to be what I intended to go on to do, reviewing #6390
<Kamion> I'll try to get that sorted for preview
<Keybuk> thom: you made a mistake in the rpm packages ... it should be spelt "d. p. k. g."
<thom> say what?
* Keybuk hands thom a pot of coffee
<thom> i have tea, i still have no clue if you're joking or what
<Keybuk> I'm joking :)
<mpt_london> thom, sabdfl says I need a chinstrap account, pretty please
<thom> goodo, i'll go back to ignoring you then :P
<thom> mpt_london: https://wiki.canonical.com/NewStaffTasks
<thom> mpt_london: specifically, the email you need to send
<mpt_london> ah, which first requires sabdfl to sign my gpg key
<mpt_london> ok, thanks
<thom> np
<jdub> seb128: do you see "Desktop Folder|Desktop" in Places?
<rburton> when keeping stuff in arch do people use arch-tag in source, or just rely on explicit ids?
<Kamion> I much prefer explicit
<Kamion> arch-tag is cute but you can't use it on all files, so better to be able to be consistent
<rburton> i bow to your superior judgement
<Kamion> my judgement is not superior where arch is concerned :-)
<rburton> ha
<Kamion> just MHO
* Mithrandir agrees with Kamion 
<T-Bone> hey Kamion :)
<Kamion> morning T-Bone
<T-Bone> Mithrandir: ia64? :)
* T-Bone ducks, it's 10h too early
<sabdfl> rburton: policy in launchpad is always explicit, never arch-tag
<Mithrandir> T-Bone: nah, not 10h too early, more like five or six.  I'm trying to hack a bit on multiarch first.
<Mithrandir> T-Bone: 1700-ish UTC is fine
<Kamion> netboot breakage reproduced in a chroot, now I stand a chance of debugging it
<T-Bone> Mithrandir: roger that
<T-Bone> i'll see if someone can help me with the firefox issue in the meantime
<T-Bone> that one is particularly strange
<sabdfl> jdub: evince is very nice
<sabdfl> any reason not to replace xpdf for hoary?
<jdub> sabdfl: it's very new
<pitti> sabdfl: it sucks for big documents
<jdub> sabdfl: veeeery new
<sabdfl> 0.1.5
<sabdfl> nice clean gnomish ui
<sabdfl> bendy? breezy?
<jdub> sabdfl: there's an element of boring and rigid that must be seen to. :-)
<jdub> definitely bendy
<sabdfl> true
<jdub> it will be in gnome 2.12
<pitti> although it is great for translating
<jdub> and under release process guidance, etc.
<jordi> pitti: how big?
<jdub> pitti: lots of strings to translate! :)
<jdub> sabdfl: that said, i am *very* tempted.
<pitti> jordi: I tried it with my friend's diploma thesis (153 pages) and it took four minutes to process it
<jordi> from the Catalan POV... evince is ready to go :)
<pitti> jordi: during that time, it was completely unresponsive and I killed it (I thought it was crashed)
<jordi> pitti: many images?
<Treenaks> jordi: ... for now
<jordi> pitti: the LliureX manual is ~400 and it's reasonable
<pitti> jordi: the problem is the thumbnail preview generation
<jordi> pitti: it takes a bit the first time as it generates thumbnails
<pitti> http://bugzilla.gnome.org/show_bug.cgi?id=165413
<pitti> http://bugzilla.gnome.org/show_bug.cgi?id=166825
<pitti> ^ these _suck_
<jordi> weird, it was reasonable here with 400 pages
<pitti> but if these are settled, evince is really great
<jordi> ok 166825 is bad :)
<pitti> jordi: try with http://people.ubuntu.com/~pitti/diplom.pdf
<jordi> 1 min
<rburton> argh baz die die die
<jordi> pitti: definitely not unresponsive here
<jordi> a lot faster than the manual
<jdub> pitti: pulls a chunk of cpu :)
<jdub> pitti: but not horrific
<jordi> but my work box is pretty ok though
<pitti> jordi: it should process the images in the background with a lower cpu usage
<jdub> yeah
<pitti> jordi: for me evice gets completely unresponsive
<mvo> works pretty ok here too
<pitti> you guys have too fast computers...
<pitti> :-)
<jordi> heh
<jordi> only 256 megs of ram
<mvo> 1Ghz :)
<jordi> whoever built my office box was on crack
<pitti> hmm, then it's odd
<jordi> 2.6ghz with 256 megs of ram
<pitti> I've a celeron 1.3
<pitti> s/celeron/duron/
* mvo is really impressed from evince
<thom> pitti: it took longer to download diplom.pdf than it did for evince to thumbnail and render it
<pitti> I'm confused
<jbailey> jdub: Are you a person to talk to about if a patch is important enough for the preview or not, or does it need to wait for mdz?
<pitti> why does it work for everybody but me?
<jordi> mvo: yeah, evince is something we badly needed.
<jdub> jbailey: both, but i often defer to mdz on rough ones
<jordi> next, marco needs to work on database management ui. :)
<pitti> thom: it's okay for the first 5 seconds, then it completely hangs
<thom> pitti: this is on a 3Ghz+ amd64 with a gb of ram though
<jordi> thom: offt
<pitti> now it uses 100% cpu and does not react to clicks or keypresses at all
<jordi> thom: pfft even. You're so spoilt
<T-Bone> thom: remember that firefox bug you've been investigating on? Do you think you'd have some time to give it another shot?
<mvo> jordi: what does it use to render pdf?
<jdub> xpdf
<jbailey> jdub: 6562 pppoe problems with weird usernames that are apparently common in .de.  I've reviewed the diff from Debian and it's just the patch +PO changes for English.  I'd like to just request a sync of it and be done with it.  Is that doable or do I need to patch it by hand (assuming it's approved)
<jdub> the newly forked fdo one
<mvo> cooolll
<jordi> jdub: is there anything good in that fork already?
<jdub> jordi: good chunk of the cairo renderer :)
<jdub> jordi: bunch of bugfixes from gpdf and kpdf
<martink> jordi, do you know the secret behind marco's success?
<martink> jordi, he's on dialup
<martink> 0.1.5 doesn't use the forked renderer, that's in 0.1.6
<jdub> didn't 0.1.6 just go in?
<jdub> oh, no, that was f-r-l
<T-Bone> thom: actually i'm pretty much convinced it is not a firefox bug (or else it has been there for age). I've been able to reproduce with 1.2 and 1.6
<jdub> jbailey: sync for that is fine
<thom> T-Bone: 1.2? firefox is only at 1.0; i guess you mean mozilla?
<jbailey> jdub: Cool.  From whom do I request it?
<T-Bone> thom: sorry, i meant 1-2 and 1-6
<seb128> jdub: nop, I need to package the fdo xpdf, we don't have it in the archive atm
<jdub> jbailey: elmo, cc mdz and myself
<jbailey> jdub: Thx.
<jdub> seb128: ok, rad
<T-Bone> thom: packages from debian sarge and sid, installed on hoary
<thom> and they do the same? hrm
<T-Bone> thom: yeah. And as i explained, this only happens when registering a locale pack
<T-Bone> thom: if you don't install a locale pack, update-chrome works flawlessly, as well as firefox
<T-Bone> thom: so i was wondering whether we may have strange bits in our locale packs
<pitti> T-Bone: btw, I fixed ffox language packs wrt update-chrome yesterday
<T-Bone> pitti: ah! lemme check that
<thom> pitti: "fixed"?
<pitti> thom: the locale packages did not check whether update-chrome was available before calling it
<pitti> thom: we lost that patch in the m-f-locale-all source package transition
<thom> oh, not interesting to this problem then; k
<pitti> T-Bone: dunno if that is the bug you mean
<T-Bone> pitti: yeah I think so
<T-Bone> err "don't"
<jdub> thom: you still have font rendering problems in ff?
<T-Bone> thom: there wouldn't be some kind of s3cr3t dependencies on language-support, from mozilla locales (just a thought)?
<jba> jdub, you're still up and at home on a friday night?
<thom> jdub: none at all
<jba> hehe
<jdub> jba: when the cat's away, the mice will play :)
<jdub> thom: gar.
<jba> hehe, well i have a baby now, so i can't go out :)
<thom> T-Bone: if so, then we'd see the problem everywhere, not just ia64
<T-Bone> thom: that's not what i meant: ia64 doesn't have language support. Maybe that's the source of problems?
<jba> jdub, i don't suppose you're a grub guru?
* jba crosses fingers
<T-Bone> thom: fwiw, i couldn't reproduce this on Debian
<jdub> just a grub
<jba> drats
<jba> can you finger any resident ubuntu grub guru's around here for me to nag?
<thom> T-Bone: oh, hrm
<thom> it's possible i guess
<jba> am trying to install ubuntu (hoary array 3) on my second disk, disk 1 has win2k with ntldr on it
<Treenaks> jba: try array 6
<jba> no matter where I put grub i can't get ntldr to chain load it (using the dd boot sector peeling technique)
<jdub> jba: easier to ask straight out to everyone
<jdub> thom: aha
<T-Bone> thom: if it happens to be the case we might want to add the proper dependencies to the package :)
<jdub> thom: if you have no hinting on
<jdub> thom: all hell breaks loose in text areas such as ubuntu bugzilla's
<T-Bone> thom: we'll have to wait for Mithrandir to help me with oo.o 32bit, then we should hopefully have language support on ia64
<T-Bone> :_
<T-Bone> (that was meant to be a smiley, sigh(
<thom> jdub: interesting
<jdub> thom: dissing my font preferences is not a valid fix, btw. ;-) ;-)
<thom> jdub: i contemplated doing tha
<thom> t
<thom> but it's obviously unnecessary
<maswan> jdub: Subject: Bounced message for 'gimpnet-opers'
<maswan> User: jdub@giardia.ultraserve.net.au
<maswan>       (500) unknown user: "jdub"
<Kamion> T-Bone: oh, BTW, I fixed the Task: ubuntu-desktop issue on ia64
<jdub> maswan: s/jdub@aphid.net/jdub@perkypants.org/ :-)
<maswan> jdub: Ok.
<Kamion> T-Bone: as a welcome side effect of some emergency patching I had to do for Array CD 6
<jdub> maswan: or pop me off the list actually; there's no .au host right now
<jdub> maswan: thanks :)
<maswan> jdub: Ok.
<Kamion> T-Bone: it's not fixed in the archive, but the CD images now get Task: ubuntu-desktop regenerated to match whatever they think desktop looks like
<maswan> jdub: and you're off :)
<mpt_london> thom: request sent
<Kamion> works rather neatly for kubuntu-desktop, too
<T-Bone> Kamion: so that means that it will not try to install broken stuff on ia64? :)
<thom> mpt_london: ok; i need to hop out for a while but i'll do it as soon as i get back
<Kamion> T-Bone: right
<Kamion> T-Bone: it didn't anyway, because that was hacked around; but I've removed that hack now
<thom> mpt_london: i assume it's not a total blocker for you?
<T-Bone> Kamion: sweet! that's nice ;)
<jba> i've been chainloading linux bootloaders with ntldr for as far back as I can remember, but for some reason i can't get it to work with ubuntu
<jba> even had fc2 on the second disk working fine
<jba> decided to put ubuntu on it, and now no matter which partition i install grub to, when I peel the first 512 bytes of that partition ntldr still cannot get grub to boot
<jba> all I get is the letter "GRUB " and then nothing
<jba> Treenaks, i plan on apt-geting up to array 6, just don't want to dl the image if i don't need to
<T-Bone> btw, i don't know how it works on hoary since i don't have an x86, but i've spread a few copies of Warty at work and people asked me "how do i make windows the default OS?". Maybe an install-question triggered only when double boot is detected would be nice (if we don't already have it)
<mpt_london> thom: Um, it is, actually :-)
<jba> do i need to mark the /boot partition on the second disc with the bootable flag?
<T-Bone> Kamion: ^^^
<jordi> martink: woah I didn't know that
<jordi> martink: he was on IRC before at least
<jba> okay i'll try a different tack, is there a way to boot into a freshly installed ubuntu installation off the install cd, aka the red hat rescue cd mode ?
<jba> at least then i could try a few different grub tricks without hacing to re-install ubuntu every time
<jordi> martink: I guess you mean he doesn't waste time on jabber, planets and all-time sucker IRC as we do
<Kamion> T-Bone: I'd prefer to punt that off to the desktop; isn't there a "Boot Configuration" thing in GNOME?
<T-Bone> Kamion: dunno. You need to edit grub conf's to do that...
<Kamion> T-Bone: yes, gnome-system-tools does that kind of thing
<thom> mpt_london: k
<martink> jordi, yeah, he is on IRC, but gets disconnected every other hour
<T-Bone> Kamion: it wasn't on warty, was it?
<mpt_london> thom: I need it to get rocketfuel going, and I need rocketfuel going to hack at the Launchpad design, which is the dirty part of my job
<Kamion> T-Bone: me no desktop guru ;)
<T-Bone> hehe
<Kamion> I'm sure I did see a Boot Configuration thingy in warty though
<T-Bone> Kamion: well it might not be clear enough, that question has been asked to me a few times
<Kamion> jba: type "rescue", follow the prompt
<Kamion> s
<Kamion> jba: (at the CD's boot: prompt)
<Kamion> T-Bone: the installer's job is to get the system on there and get out of the way as fast as possible; it's not really (in Ubuntu at least) a good place for fine customisation or detailed information dissemination
<jba> Kamion, thanks, which array did the rescue boot option debut in ?
<T-Bone> Kamion: sure i'm on the same line. I'm just reporting end users' questions ;)
<Kamion> T-Bone: especially since the first boot *has* to be into Ubuntu by default in order to do the second stage
<T-Bone> Kamion: yeah I tought of that too... OTOH the default boot OS question seemed relevant... Maybe that could be sorted out in the second stage?
<jdub> Kamion: (it's disabled)
<Kamion> jba: Array CD 3. Its UI really sucked until 5 though
<Kamion> (now it only sucks a bit)
<Kamion> T-Bone: no questions in the second stage; that's a requirement
<Kamion> T-Bone: really I think this is a desktop thing
<Kamion> and document it better if users can't find it
<T-Bone> Kamion: then i'm clueless... We're going "you installed Ubuntu, you'll boot it by default or die" ? :)
<Kamion> T-Bone: yep
<T-Bone> heh
<T-Bone> kinda rude :)
<Kamion> T-Bone: the *installer* does that. the desktop lets you configure it.
<jba> Kamion, I did this:
<jba> boot: rescue
<jba> and it sasy Could not find kernel image rescue
<jba> or there abouts
<Kamion> jba: architecture?
<T-Bone> Kamion: it might be a desktop things, but it needs enlightenment for the user (pointers/disclaimers/documentation whatever) i think
<Kamion> T-Bone: sure
<jba> hoary array 3 cd for x86
<jba> i'm running an athlong 1.4Ghz
<Kamion> jba: oh, Array CD 3 probably didn't have the 'rescue' option in isolinux; you had to boot 'linux rescue/enable=true'
<jba> cool thanks dude
<jba> I'll remember that one
<jba> linux rescue/enable=true
<jba> exactly like that?
<Kamion> shouldn't have to remember it for long, I added the rescue option 'cos clearly that approach was crap :)
<Kamion> yes, exactly like that
<jba> that's more like it
<jba> is it possible grub doesn't like not being on the first disk?
<Kamion> could be
<T-Bone> jba: i'd say it's possible if your BIOS forcibly boots the first disk first
<Kamion> the grub tricks you're doing are already beyond me though
* T-Bone had that kind of issue with a lilo setup on second disk
<jba> i've got one more trick left up my sleave, make the / partition contain /boot
<jba> it seems no one is awake over in #grub
<thom> mpt_london: you got mail
<jba> success
<jba> Kamion, jdub, T-Bone FYI, the solution was to install grub to (and then peel the first 512 bytes of) /dev/hdb (NOT /dev/hdb1)
<jba> not sure why that mattered but it did
<jba> time to go restore my /home partition and update to array 6
<T-Bone> weird
<pitti> jdub: it seems that http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule is out of date
<jba> sigh
<jba> I was wrong
<ogra> thom: why is the firefox industrial forms patch not gone in ? http://linuxart.com/dir/stuff/screenshots/partial/firefox-forms1.png
<jba> Error 6: mismatched or corrupt versions of stage 1/stage 2
<ogra> thom: it makes ff look really consistent
<pitti> jdub: oh no, I just interpreted the dates wrong, sorry
<thom> ogra: because it's an absolute apin
<thom> pain
<T-Bone> ogra: yep, looks neat
<ogra> thom: why ? it just replaces the css and some graphics i thought
<thom> i'll try and get it in for 1.0.1 if i can
<ogra> yeah
<jba> grub is really starting to piss me off now
* thom -> out
<tseng> ogra: how does that work for !industrial engines?
<T-Bone> grub is 3v1l
<Kamion> jdub: ok to upload http://riva.ucam.org/~cjwatson/tmp/choose-mirror.ftp.diff? fixes a netboot crasher that svenl discovered
<torkel> jba: just wait till you try to install it on your ninth disk ;-)
<thom> tseng: the forms stuff is different to theming, and not tied to gtk particularly
<Kamion> (due to the templates file being full of random blank lines)
<ogra> tseng: hmm, good question, i think the forms will go on displaying industrial
<tseng> actually, i think the scroll bars will be rethemed
<thom> yes, it's an all-or-nothing proposition
<tseng> and only the drop boxes and checkboxes he themed
<thom> either you have industrial forms, or you don't
<tseng> I've tried this before
* jba suspexts a need to re-install grub stage 2
<thom> which is another reason i'm leary of it
<ogra> thom: its still better then the rough motif like edges of the default
<thom> mmm
<Kamion> jdub: also, I have discovered an interesting new piece of hotplug-induced installer damage
<T-Bone> damn, is it just me or does xorg's ATI driver plain sucks?
<Kamion> jdub: since we coldplug everything we can at boot, it's entirely possible for a hw-detect run to have no modules to load, at which point it tries to ask a multiselect question with no choices
<Kamion> jdub: cdebconf bombs out when you try to do that, and thus some later parts of hardware detection don't get run
<Mithrandir> Kamion: rotfl (:
<Kamion> jdub: the fix is to add an enormous if around a block of code; ok to do so?
<trulux> heya folks
<Kamion> I think this *might* explain some CD-ROM detection problems, although I noticed it in netboot while investigating why hw-detect was exiting without cleaning up its progress bar
<trulux> heh, new result: 8/10 in English subject :)
<tseng> ogra: oh wow.. try that forms mod on ubuntu bugzilla and the radio buttons to close a bug
<trulux> err
<trulux> 8:55/10
* T-Bone can't have a decent acceleration on hoary on his ATI card, while he had on warty. Sigh
<trulux> 8.55
<trulux> :)
<ogra> tseng: what does it do ?
<tseng> it has a red box around it, maybe from css
* ogra has no bugs he could close right away atm
<tseng> and looks pretty yuck
<tseng> dont need to close, its on every bug page
<ogra> downloading it....wait a sec
<jba> god dman it, it's not meant to be this hard !!!!
<T-Bone> jba: no, it's meant to be harder :^)
<ogra> tseng: i dont see a red box around the radiobuttons here
<tseng> hm
<tseng> ok
<ogra> there is a dashed square though
<ogra> but not red
<trulux> jdub: ping
<Kamion> jdub: (http://riva.ucam.org/~cjwatson/tmp/ddetect.empty-list.diff should fix the above problem; slightly less enormous if than I thought)
<tritium> Good morning trulux
* lamont takes kids to school, runs errands.
<lamont> back on in about 3 hours or so.
<trulux> tritium: hey! howya?
<tritium> trulux, great.  You?
<trulux> tritium: great but a bit upset with the English teacher
<tritium> trulux, sorry...
<trulux> tritium: it's just that she pretends to gimme just 8.55/10
<trulux> tritium: and says that "z" spelling is wrong (ie. organize) and "s" so-british-leet spelling is OK
<trulux> she writes *everything* in english, school results, personal notes.... all
<trulux> it's kinda fun
<trulux> :)
<trulux> maybe she is scared on forgetting it
* trulux ducks
<trulux> anyways
<tritium> heh
<trulux> I'm waiting for Maths results
<trulux> and a few others
<tritium> Well, good luck to you on those.
<lunitik> tritium: weren't you one of the folks that uses mpd?
<lunitik> tritium: if so, let me direct your attention to #ubuntu  :P
<zul> hey
<tritium> lunitik, no, but I'll go see what's going on.  Thanks.
<tritium> lunitik, maybe you're remembering that I use gnump3d
<trulux> tritium: thanks :) ubuntu-hardened ready
<trulux> going to announce
<tritium> trulux, Congratulations!
<trulux> thanks :)
<tritium> trulux, Now, let's convince the Purdue guys at Cerias to open a mirror, now that we can argue the security focus of ubuntu
<tritium> trulux, I could use your help with that, as I was turned down the first time.
<Kamion> trulux: there are worse things than being taught British English ;)
<trulux> tritium: they won't do again if they are considerated
<trulux> Kamion: I can't imagine in a first looking
<tritium> trulux, at least you don't have to pronounce the letter "r" :)
<T-Bone> Kamion: sure, that includes being taught 'baz' at 1AM  8)
<zul> whinner :)
<T-Bone> lol
<mdke> the ubuntu live cd has bootsplash, but not the normal installation. Is it not available at all?
<Riddell> just tried the kubuntu install CD on my thinkpad and the keyboard didn't work :(
<Kamion> T-Bone: heh
<Kamion> mdke: no; when we tried to add it to our kernels it broke the installer, and in discussions following that event we determined that it was fundamentally the wrong approach.
<Kamion> mdke: the Warty live CD is quite different from the install CD in many ways. They've been unified in Hoary.
<mdke> Kamion, i c. why fundamentally wrong?
<Kamion> mdke: puts far too much into the kernel (and requires far too much to be compiled in monolithically, not as modules) that doesn't belong there
<mdke> ah right, yes that is true
<Kamion> hence usplash, which unfortunately hasn't made hoary, but should hopefully be ready for the next release
<mdke> i wonder if there is a wiki for bootsplash on ubuntu
<trulux> tritium: hah
<Kamion> mdke: http://www.ubuntulinux.org/wiki/USplash is the design document
<daniels> sabdfl: ok, will check it out.  i've got a pcie x850 here, and i'm pretty sure we'll need a new upstream fglrx here.
<mdke> Kamion, ty
<zul> daniels: did you do any debugging for the xfs and stripping bug you reported?
<daniels> zul: not yet sorry, I've been run off my feet with a combination of xorg and real-life
<zul> daniels: no probs there is a bug open upsteam on bugme
<daniels> yah, ta
<daniels> Kamion: oh and btw, we still read edid via the of /proc tree with xresprobe :)
<daniels> Kamion: remember the C hack we decided should probably just be replaced with your shell script in Oxford?
<mvo> seb128: I noticed that python-vte lacks "forkpty()" judging from the code it looks like a oversight. can I send you a patch?
<Kamion> daniels: ah yes
<daniels> anyway, must sleep now
<daniels> mdz: been bashing at the debconfiscation, think it's in a fair bit better shape now
<sabdfl> whiprush, smurfix: around?
<Keybuk> dd: reading `/dev/hdc': Input/output error
<Keybuk> c9ddc826f1716f1246ce17eccf18a717  -
<Keybuk> *sigh*  I'm clearly doomed
<Kamion> disk or CD
<Kamion> ?
<Keybuk> CD
<Kamion> reburn?
<Keybuk> that's about the 6th reburn so far
<whiprush> sabdfl: I'm here
<sabdfl> hey whiprush
<seb128> mvo: sure
<daniels> mjg59: oh, fwiw, there's no way I can keep i810 from HEAD in hoary, so no matter what happens with the kernel, we just won't have DRI across suspend/resume.  it's really too stuffed and I can't get my hands on any hardware.
<ogra> Keybuk: time for a new writer ?
<whiprush> what's up?
<sabdfl> daniels: i think my X40 is i810
<dholbach> re
<whiprush> sabdfl: I'm leaving for work in a minute ... did you need something?
<sabdfl> whiprush: sent you a /invite
<sabdfl> but there may be a client problem, noone else seems to have gotten it
<tseng> Riddell: hey if you have some spare cycles at any point, can I point out that there are several KDE-related packages that need some help on UniversePythonTransitionTODO
<Riddell> tseng: yes, but we're working on KDE 3.4 packages so no point fixing 3.3 when 3.4 will have to be fixed up soon anyway
<tseng> sure, thanks
<tseng> would you mind reflecting on that page which packages are affected by this?
<tseng> or just give me a quick list and I'll handle it
<mjg59> daniels: Oh, the xserver side of it? Suck.
<tseng> (trying to keep the "unresolved" list as up to date as possible)
<ogra> tseng: what will we do about these ? drop them ?
<tseng> ogra: the kde packs? just assumed that riddel was the best guy to look at them / already had it on his list
<mvo> seb128: send vte patch as gnome bug #169201
<tseng> so I could check it off our master list
<tseng> into "being transitioned"
<tseng> im looking at boost, atm
<Riddell> tseng: I'll look at the python stuff after we get 3.4 packaged
<ogra> tseng: ah, ok.... sounded like they are not touched bacause of 3.4
<tseng> Riddell: ok, thanks.
<ogra> because even
<tseng> Riddell: what im saying is.. they are on a todo list for all motus and volunteers. if its on your list, i should move them to Being Transitioned with your name so that no one wastes time mucking with them until your done 3.4. am I making more sense now?
<tseng> sorry if it was less than clear
<svenl> daniels: you there ? can we discuss this #7144 issue ? 
<Riddell> tseng: ok yeah, that's all cool, put me down as transitioner
<tseng> Riddell: ok wonderful. thanks
<dholbach> tseng, Riddell: you rock :-)
<Riddell> dholbach: ment to compliment you on that motu report, works well, good job
* dholbach curtseys... thanks :-)
<tseng> dholbach: i mailed you a neat tip :)
<dholbach> tseng: *having a look*
<seb128> mvo: k
<haggai> Riddell: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2005-February/000079.html
<tritium> seb128, is it worth noting somewhere that the latest update to evolution requires a user to setup an email account?  (i.e. you can't just use it for calendar, contacts without at least a dummy email account)
* haggai is catching up with debian packagers' status
<haggai> Riddell: oops that was for #kubuntu-devel
<Mithrandir> jdub: where's the march calendar?
<ogra> Mithrandir: hmm, http://people.ubuntu.com/~lamont/buildLogs/u/ubuntu-calendar/5.03-1/ubuntu-calendar_5.03-1_20050304-0436-i386-successful
<ogra> seems it got lost between the buildd and the archive
<tseng> ogra: thats odd, pyparsing is in a similar situation it looks like
<ogra> tseng: did you aks elmo or lamont ?
<ogra> ask even
<tseng> not yet
<pitti> elmo: ping
<tseng> just realized it before bed last night
<pitti> lamont: ping
<ogra> pitti: you make us famous at heise.de :) the only mentioning of ubuntu i find there, are several entrys about ubuntu beig the fastes in fixing security holes :)
<pitti> ogra: I already saw that, yes :-)
<pitti> ogra: although Ubuntu was pretty often mentioned in comments
<ogra> but borchers still talks about the "southafrican linux distribution" heh
<pitti> ogra: after warty was released I wrote about 10 mails to the newsticker team to mention Ubuntu release
* ogra wonders who pays them to try to ignore ubuntu completely....
<ogra> pitti: me too...
<pitti> ogra: however, I was a bit sad that it took four months until Ubuntu was presented in the c't
<seb128> tritium: evolution 2.0 works in this way too, and you can create a dummy account
<ogra> and i know juergen kuri and detlef borchers (coming from hannover)
<pitti> ogra: and the article was not even very good ("just another Debian release, and that's it")
<ogra> bah
<tritium> seb128, yes, but it wasn't enabled until the latest upgrade to 2.1.6
<pitti> ogra: seems we have to kick them harder for hoary :-)
<ogra> pitti: lets just ignore them from now on, they are not worth it
<seb128> tritium: you saying than a wizard to create an account for new users is a bad idea ? I don't think so
<pitti> but a lot of people read heise newsticker
<tritium> seb128, no, not saying that at all
<ogra> pitti, if the attitude is "just another...." kicking wont change it
<seb128> tritium: 2.1.5 used to do that
<pitti> ogra: by "kick" I mean "present the advantages" :-)
<tritium> seb128, just last night my wife was forced to setup an email account.  Before yesterday, she had only used calendar and contacts
<tritium> That's all I was pointing out.
<ogra> yup...i think this time there will be a proper announcement....
<seb128> tritium: right, could be a whishlist, but I think that's not a standard usecase .. you can't cancel it ?
<ogra> ...we can send it to them....but the question is if they will use it
<tritium> seb128, no, jpr told me just to setup server as "None" and sendmail for outgoing
<seb128> k
<pitti> ogra: IIRC last time I did send them a link to the announcement
<ogra> hrm
<seb128> tritium: feel free to put a wishlist in bugzilla.ximian though :)
<ogra> di*kheads
<pitti> ogra: but at that time we did not have many killer features
<tritium> seb128, a way to cancel out would be nice, or perhaps a little note in README.debian, or somehting
<pitti> ogra: hoary has more :-)
<tritium> seb128, okay.  Thanks.
<ogra> warty was a killer feature per se ;)
<pitti> indeed :-)
<seb128> tritium: a note say what ? evolution works in this way for ages, they just turn the option in the devel branch
<seb128> tritium: ie: an user following stable branches will not get any change
<tritium> seb128, I believe you, but I've not seen it force an email account setup until yesterday
<tritium> I just meant a note about using server type "None" to get around it, that's all.
<seb128> k
<seb128> if you want to write the note patches are welcome
<seb128> :)
<tritium> :)
<Amaranth> "That said, I think it's high time we eliminate the session splash (and perhaps the session manager) altogether and just make login fast." <--what he said :)
<tseng> good thing ubuntu has its own splash
<mdz> morning
<ogra> morning
<zul> morning mdz
<mdz> pitti: yes?
<pitti> Hi mdz 
* pitti tries to remember what he wanted to ask mdz
<pitti> mdz: ah, yes; language packs (of course :-) )
<pitti> mdz: I replied to the mailing list
<pitti> mdz: however, do you agree that we should settle this by the preview?
<pitti> mdz: I also asked Mako to gather some statistics (no reply yet)
<mako> pitti: hey dude.. talking with mark
<mako> pitti: saw your email
<pitti> mako: hi mako!
<pitti> mako: did you find a good measure?
<mdz> pitti: yes, we absolutely should settle this by preview
<pitti> mdz: in short I proposed to use more space for hoary (~ 30 MB) and split the packages into -desktop and -supported for hoary+1 if necessary (if space becomes tight)
<pitti> mdz: I think it would really be a pity to make hoary worse than warty...
<mdz> pitti: what did sabdfl say?
<pitti> mdz: no reply on the lists, I can ask him on irc
<_d4vid> hi all
<sabdfl> he's listening, what's up?
<pitti> sabdfl: we need to find a reasonably quick solution to the outstanding langpack questions
<pitti> sabdfl: a while ago I mailed to ubuntu-devel ("Language support summary/discussion")
<pitti> sabdfl: short-short version: I proposed to devote ~ 30 MB for language packs for Hoary
<pitti> sabdfl: we have the space now and should not make Hoary worse than Warty (which included translations)
<pitti> sabdfl: if space becomes an issue for hoary+1, we can always split the desktop part of the langpacks to save space
<pitti> sabdfl: what do you think about this?
<mdz> sabdfl: note that this proposal conflicts with the idea of providing complete support for languages on the CD (spell checking, etc.)
<mdz> unfortunately we must choose
<sabdfl> mdz: no hope for 750MB?
<pitti> sabdfl: we can strip some more packages
<sabdfl> is the issue with 750MB the burners or the readers?
<sabdfl> pitti: from the ship list?
<mdz> I don't think it matters; either would be a deal-breaker
<pitti> sabdfl: yes
<mdz> we could remove thunderbird and a few things like that from ship
<sabdfl> erk
<pitti> mdz: so you additionally want to include some l-support pakcages?
<sabdfl> pitti - if someone chooses a language, it makes sense that they want to create content in that language
<mdz> pitti: we _must_ include l-s-en, and preferably support for the most common languages
<sabdfl> so spell checkers, input methods, etc should Just work
<pitti> mdz: well, the l-s-en packages are mostly already in ship anyway
<mdz> pitti: I cannot imagine a user who wants applications translated into a language, but will not write their documents in that language
<mdz> pitti: oh?
<pitti> mdz: indeed
<mdz> oh, -en, yes
<tseng> why does the pkgstriptranslations package touch a file in /var/lib/update-notifier?
<mdz> only English
<pitti> mdz: we already ship and install oo.o l10n and such
<pitti> tseng: eh?
<sabdfl> pitti: what do you mean by "worse than hoary". fewer languages?
<sabdfl> as i see it we are shipping fewer languages on cd but supporting them much better
<tseng> Setting up pkgstriptranslations (8) ...
<tseng> Installing new version of config file /etc/pkgstriptranslations.conf ...
<tseng> touch: cannot touch `/var/lib/update-notifier/dpkg-run-stamp': No such file or directory
<mdz> sabdfl: localization data for fewer languages on the CD
<pitti> sabdfl: a friend of mine already complained that warty was fully translated into German
<tseng> pitti: doing it in my pbuilder update
<pitti> sabdfl: now with hoary, he gets a crazy wild mix of English with some German translatiosn in between
<mdz> pitti: did he install without a network?
<pitti> sabdfl: German from the .desktop files, all other stuff english
<sabdfl> hmm... in the installer, or after install?
<pitti> mdz: live cd, and he only has modem
<pitti> mdz: -> so yes, without network
<pitti> mdz: most of "normal" computer users here use modem
<pitti> it's completely sufficient for mail reading and some browsing
<pitti> mdz: the live CD looks ugly either way because it does not install langpacks from network
<tseng> pitti: theres obviously nothing in rules doing that, I guess i have to bug mvo 
<pitti> mdz: OTOH many people want/need a translated desktop, they will see it before they even attempt to open OO.o and such
<sabdfl> mdz: is it feasible, for hoary, to have it download the langpacks if you say "yes" to the download new software question?
<pitti> mdz: if we have the space, then of course ffox locales etc. would rock, too
<pitti> sabdfl: already done
<sabdfl> so f someone chooses hungarian, and then network install, they get hungarian even if it was not on the cd?
<mdz> sabdfl: yes, it already does that
<pitti> sabdfl: this already happens
<sabdfl> nice
<pitti> sabdfl: just not for the live cd
<mdz> it could be done for the live CD, but this would be slow and cost a lot of memory
<sabdfl> hmm...
<mdz> better to preinstall as much as possible
<pitti> mdz: then maybe for the live CD you should skip the language question
<sabdfl> could the live cd have all the languages pre-installed? would the cost be the winfoss?
<pitti> mdz: better a consistent English interface than this embarrassing mix
<mdz> pitti: we will localize it as much as possible within the space available, as with the install CD
<pitti> mdz: ah, ok
<pitti> mdz: would it be possible to install an English locale for non-available language packs?
<mdz> pitti: configure for an english locale by default, you mean?
<mdz> (if the language pack is not available for that language)?
<pitti> mdz: nobody will complain if the live CD does not contain Zulu translations, but it shouldn't be a mix between Zulu and English languages
<mdz> that seems worse than not offering the option, if we disregard it
<pitti> mdz: yes
<pitti> mdz: have you ever seen a live CD in non-English?
* lunitik wonders why language-pack-en for instance will install like 20 locales... surely this is somewhat overkill?
<pitti> mdz: you get two languages within the same sentence or menu
<pitti> mdz: this is awful
<pitti> mdz: better to have it consistent
<mdz> pitti: well, how many language packs can we fit on the live CD?
<mdz> pitti: we will add language  packs to the live seed
<pitti> mdz: I don't have the images on this computer, how much space can we devote?
<mdz> this has been intended from the start
<mdz> pitti: we don't know without a test
* lunitik thinks they should be seperated further, to l-p-us-en for instance... takes like 2-3 mins to generate the locales otherwise  :(
<pitti> mdz: with 35 MB we can have the full list of the world's 11 most popular langs
<mdz> lunitik: we pregenerate all of the necessary locales on the live CD
<mdz> pitti: 35MB installed-size?
<pitti> mdz: no, debs
<pitti> mdz: does the uncompressed size matter?
<lunitik> mdz: I don't use the LiveCD much though... but have sat through a couple upgrades to locales... promptly removed the lang pack  :(
<mdz> pitti: the compression ratio we get with .debs is different from that of the cloop image
<pitti> ah
<mdz> we get a ratio of about 2.6:1
<mdz> lunitik: we are discussing the live CD at the moment
<pitti> mdz: an well-translated language pack (french, German, etc.) is about 10 MB uncompressed
<lunitik> mdz: oh... well, still somewhat on topic  :P
<mdz> lunitik: yes, we agree with you about the number of english locales being excessive, and think it should be made smarter
<lunitik> mdz: cool
* lunitik wonders off   :P
<mdz> lunitik: time is very limited, though, and performance issues are secondary.  patches gratefully received.
<mdz> especially one-time performance issues that only affect the install
<lunitik> mdz: depends... I have not used the stable branch much, so I get a lot of locales upgrades... I guess its something I have to live with for now though  :)
<luis_> hrm
* luis_ is reminded that he has not played with languages + liveCD at all
<mdz> currently, the daily live CD offers a localized bootstrap, and an English-only runtime environment
* thom &|
<mdz> pitti: so about 3.8M of live CD space
<mdz> pitti: current live CD is 480M
<mdz> winfoss is ~100M
<mdz> leaving us with ~70M for additional languages
<mdz> let's add the top 10 immediately
<luis_> mdz: yeah, I know; I'm installing the es language pack right now on my liveCD to test it
<pitti> mdz: so these 11 packs would need 35/2.6*3 = 40 MB
<pitti> mdz: given that we can split the packages for hoary+1, this seems adequate to me. What do you think?
<pitti> mdz: we should be able to get another 10 MB from stripping, too
<mdz> pitti: ok, please go ahead and add the packs to the ship seed
<mdz> er
<mdz> live seed
<pitti> mdz: ah, ok. ship will be discussed separately?
<doko> mdz, jdub: confirmation for uploading fixes to #6651 (documentation issue), and #6686 (bug fix for gs-esp in .ps file)
<doko> ?
<mdz> pitti: it seems we are more constrained on the install CD
<pitti> mdz: is it right that "live" only contains 4 packages by now?
<mdz> pitti: yes. it is in addition to desktop
<pitti> ah
<mdz> doko: 6651 fine
<mdz> doko: 6686 OK as well
<doko> thanks
<pitti> mdz: hmm, French is the 11th language...
<mdz> pitti: go ahead, there is room for it
<doko> mdz: need to fix the lib32gcc symlink in gcc-3.4 as well. can I update the package to the compiler version I build for haggai, just fix the symlink, or delay anything after the preview release?
<mdz> doko: what build-depends on 3.4?
<pitti> mdz: btw, I already rounded up for the 30 MB, so it shouln't be 35 MB
<mdz> doko: bug#?
<doko> firefox and mozilla on amd64, and grub. wait, I already did close it, after fixing 4.0
<doko> #7099
<mdz> doko: doesn't grub build with -m32?
<mdz> does this mean that it is FTBFS right now?
<pitti> mdz: okay, added (10 new packs, English was already there). Shall we wait for Mako's results what to do for ship?
<mdz> pitti: what is mako working on?
<doko> mdz: yes, but doesn't depend on the shared libgcc1_32
<mako> pitti: give me 15 minutes.. i'm done with the meeting with mark
<pitti> mdz: I asked him to gather some statistics about languages, countries where Ubuntu is popular and so on
<mdz> doko: the only change is to add a symlink, yes?  if so, go ahead
<pitti> mako: it's not _that_ urgent :-)
<mako> pitti: i can get the country stuff pretty quickly
<mako> i already have the code to do it
<mdz> doko: and promise me that we can use gcc-4.0 for everything in hoary+1 :-)
<mako> i've done it for jane several times
<doko> to _change_ the symlink
<mdz> mako: please do; this is critical for preview
<mdz> doko: OK
<doko> mdz: we'll see, we have 3.4 as ABI compatible backup :)
<luis_> may I ask what the ten languages you just shoved on the liveCD were?
<luis_> and will those be on tomorrow's daily build or is that for the future at some point?
<mdz> luis_: the next daily build
<mdz> luis_: is that going to run you out of space?
<luis_> mdz: don't think so
<luis_> mdz: I mean, worst case, I can always nuke french ;)
<doko> mdz, mvo: could we decide on the seed changes needed for ISDN?
<luis_> mdz: though I'm a little worried about fonts and such taking up additional space, not sure. Do the lang packs directly depend on the necessary fonts or are they already on there?
<mdz> doko: did you fix the issues that I raised in response to your previous proposal?
<mdz> luis_: the fonts are already there
<doko> mdz: the i386 only thing? yes, removed, because it's i386 only
<luis_> right, but I think maybe I nuked some from my build in my space-creating zeal ;)
<netdur> hey, I don't know if I should report about this or not (I don't like bugzilla), if you try to install apache* via synaptic, the intall process will stick forever because the instalation requit some confugrations, which you not notice if you hide the terminl in install process
<luis_> we'll see, I guess :)
<HiddenWolf>  netdur: file a bug
<doko> the remaining question was, if driver and firmware stuff should be installed by default on a desktop install
<mdz> doko: isdnutils is already in ship
<pitti> doko: it seems that the battle for CD space has begun :-)
<mvo> HiddenWolf, netdur: this problem is probably caused by the fact that libgnome2-perl is not installed by default. this is needed to get graphical debconf support
<mdz> doko: it's too late to add non-trivial things to the desktop, certainly for preview (and likely for final as well)
<mdz> doko: I see no package named pppdplugin
<HiddenWolf> mvo: why isn't it installed by default?
<mdz> I guess you meant pppdcapiplugin
<mvo> mdz: please reconsider this. capituils where packages we asked for inclusion to ship for some time 
<mdz> mvo: I said desktop, not ship
<mvo> mdz: sorry
<doko> mdz: correct
<mvo> HiddenWolf: I hope it will be changed for the hoary-final. there where some concerns about it (the gui is not too nice)
<doko> drdsl needs to be imported from non-free to restricted
<doko> and avm-fritz-firmware added to linux-meta, and then added to the ship seed as well.
<HiddenWolf> mvo: isn't it just possible to supress those few config questions that arise, or pop up a dialog to open the terminal if there is a question that can't be avoided?
<mdz> lamont: ping
<froud> mdz: if you are gonna have desktoip changes please notify ubuntu-doc. thanks
<mdz> froud: what desktop changes?
<mvo> HiddenWolf: detecting the questions on a terminal seems to be impossible. supressing is already done, we have debconf priority=high. so most of the stuff is supressed anyway, but the remaining questions are imported and should be asked
<mdz> froud: do you mean ubuntu-docs?
<pitti> bah, why does ubuntu-base depend on telnet?
<mdz> pitti: because silly people use it instead of netcat
* pitti pats netcat
<mdz> I think that very few people use the actual telnet protocol these days :-)
<doko> mdz: we shouldn't put isdnutils in ship, isdnutils-base, ipppd, (maybe isdnlog), capiutils and pppdcapiplugin are enough
<mdz> doko: isdnutils has been in ship for the entire hoary cycle
<froud> mdz: yes ubuntu-docs and only if there will be changes to the desktop menu options
<froud> mdz: that is the default that installs
<doko> mdz: ok, then only capiutils and pppdcapiplugin
<mdz> froud: we will be adding the faqguide and quickguide to the default install, but I do not think that they have menu options
<froud> mdz: just until release
<mdz> doko: I have alreaday done this; see my followup on ubuntu-devel
<froud> mdz: no I mean if you decide to add new apps to any of the menus.
<froud> mdz: just tell us
<mdz> froud: as I was saying above, we should not make that kind of change at this point in the release cycle
<doko> mdz: elmo just wanted to have an ok to move drdsl to restricted.
<mdz> doko: elmo's laptop is broken, he is offline
<froud> mdz: should not but you never know ;-) so I ask if per chance it does happen let us know, please
<mdz> oh, maybe not
<mdz> elmo: fine with me to move drdsl to restricted
<mdz> elmo: please also promote the ubuntu-docs stuff to main
<elmo> ubuntu-doc stuff is in main, I thoguht
<mdz> elmo: so it is. retroactive thanks
<mdz> elmo: do you publish the output from wotshername automatically anywhere? (pending promotions/demotions)
<mdz> pitti: let's carry out your proposal for ship
<mdz> pitti: but we must decide what to do about language-support-*
<elmo> mdz: no not yet
<pitti> mdz: right
<pitti> mdz: yesterday I installed array 6 with de, and downloading l-s-de with dependencies alone was 26 MB compressed
<mdz> pitti: can you calculate the total size of each l-s-* and its dependencies?
<pitti> mdz: i. e. if we want to put support packages on it, we can only add about two langs
<mdz> pitti: yes, I think it is unfortunately too much to download during the install in many cases
<pitti> mdz: I prepare a list
<seb128> <rlove> the next release is going to fix every inotify bug, ever
<seb128> <rlove> seriously, I will have a patch out--hopefully today--that eradicates every bug
<pitti> MUHAHA
<pitti> seb128: would rock
<seb128> yep
<Riddell> sabdfl: should the artwork competition use the name canonical, ubuntu or kubuntu?
* mvo is away to play hockey
<koke> about translations...
<koke> it would be great to have xscreensaver lock dialog translated
<koke> I guess the problem is the same that about linking to gtk
<koke> isn't it?
<mdz> seb128: who is the Oliver mentioned in #6959?
* T-Bone looks at Mithrandir's stats on planet.debian.org... Looks like there are quite a bunch of ia64 users out there ;}
<seb128> mdz:   * Include pretty lock dialogue patch from Oliver Grawert.
<mdz> hmm
* mdz looks at ogra
<seb128> the guy who has wroten the patch apparently
<seb128> yeah :)
<ogra> yup, here, whats wrong?
<pitti> mdz: people.ubuntu.com/~pitti/support-bysize.txt
<mdz> enrico: I still don't see the faqguide or quickguide in yelp; I thought you were updating the package?
* ogra looks at bugzilla
<ogra> mdz: i have a 80% done patch i temporary dropped until after hwdb-client is done....does this need to be fixed before preview ?
<mdz> ogra: no, but definitely for final
<ogra> (in fact its 100% done, but jdub wanted me to revert some things)
<mdz> seb128: when do the 2.10 tarballs start appearing?
<ogra> seb128: hmm, why is that assigned to you....can i claim it as a reminder ?
<ogra> (reassign it to me that is)
<seb128> mdz: monday
<mdz> sivang: http://linmagazine.co.il/node/view/7242
<pitti> mdz: http://people.ubuntu.com/~pitti/support-bypopularity.txt
<pitti> mdz: ^ I think that's better than the size-sorted list
<seb128> ogra: dunno why that's assigned to me, feel free to reassign it :)
<pitti> mdz: pretty big stuff...
<ogra> seb128: thanks :)
<mdz> pitti: HUGE
<pitti> mdz: the list shows the sum of deb sizes per language support
<pitti> mdz: yes, dictionaries, help files, etc. cost a lot
<pitti> mdz: that's what I mean, if we want to ship them, we can't do more than two languages
<enrico> mdz: I uploaded a new package; if you install ubuntu-docs, you should see about and release notes.   QuickGuide and FAQGuide show up if you install them.
<enrico> mdz: However, they all should show up in the Others category
<elmo> mdz: btw, http://people.ubuntu.com/~james/paste/sync.txt if you wanted a once off update, I'll try and cron that to somewhere public when I get back
<pitti> mdz: I gotta go now, sorry. can we continue this later?
<pitti> mdz: if you have some suggestions, could you reply on the mailing list?
<mdz> enrico: what version of ubuntu-docs?  they don't show up here
<mdz> pitti: I will be here all day and probably all weekend too
<enrico> mdz: 0.2-1
<pitti> mdz: okay
<mdz> enrico: the latest version in Ubuntu is 0.1-1
<enrico> mdz: I've uploaded them this afternoon
<enrico> mdz: 3 hours ago, if you have a different concept of a'noon :)
<mdz> enrico: did you receive an accepted message?
<elmo> ubuntu-docs_0.2-1_i386.changes
<elmo> REJECT
<elmo> Rejected: binary uploads are not allowed - please only upload source.
<enrico> oh darn!
<enrico> ok, re-upping
<mdz> enrico: is your email address not whitelisted?
<enrico> mdz: I didn't get the mail, no
<elmo> I just whitelisted it
<mdz> thanks
<mdz> elmo: would there be any particular problem with publishing that log?
<enrico> mdz: I've used enrico@enricozini.org
<enrico> elmo: thanks
<mdz> elmo: or does it mix in the security stuff in the same place?
<elmo> mdz: unfortunately yes, it mixes security stuff
<mdz> doh
<enrico> what was the debuild switch for source-only upload?
<pitti> -S
<enrico> pitti: thanks
<ogra> elmo: looks like ubuntu-calendar got lost between buildd and archive somehow....
<tseng> elmo: i *think* the same happened to pyparsing
<elmo> pyparsing was in NEW, I cleared it a couple of hours ago
<elmo> ubuntu-calendar always gets lost - it's an artificat of how we force it into warty-security
<elmo> I'll fix it now
<tseng> ah thanks elmo 
<ogra> heh, good to know, then ill shut up next month ;)
<pitti> mdz: after seeing the list, do you still think that we should add support packages?
<enrico> mdz: uploading again now...
<mdz> pitti: I cannot think of any 2 we could add which would be a reasonable choice over the others :-/
<mdz> enrico: DeveloperResources has a checklist for uploads
<mdz> pitti: why does l-s-it not depend on oo.o-thesaurus-it?
<enrico> mdz: thanks
<pitti> mdz: dunno, maybe it did not exist at the time I created the support packages
<pitti> mdz: no problem to add, though
<enrico> Can I link DeveloperResources from Uploads?
<enrico> pitti: it didn't exist
<enrico> pitti: the it thesaurus is quite new
<pitti> hmm, I still cannot find it
<pitti> mdz: where is this package?
<enrico> pitti: and I uploaded a new improved version in Debian yesterday
<enrico> upstream told me there's tons of new words
<pitti> enrico: thanks, that explains it
<mdz> pitti: openoffice.org-thesaurus-it | 0+20041114.2-0.1 | http://archive.ubuntu.com hoary/main Packages
<enrico> pitti: the IT thesaurus has been developed recently by a network of high schools
<enrico> so it comes out quite independently from the rest of OOo
<pitti> mdz: ah, ok, I add it to the support package then
<enrico> more so because the italian OOo community is pissed at Sun and releases their things GPL-only
<mdz> elmo: I don't see where python-hip is coming from; it isn't in the germinate output for hoary or kubuntu-hoary
<mdz> (Colin's output, that is)
<enrico> mdz: uploaded.  No mail yet; I'm going to dinner
<elmo> python-hip                       | libmp3hip                     | kubuntu-desktop                          | Myers W. Carpenter <myers@fil.org>    
<mdz> mizar:[...nonical/seeds/kubuntu/hoary]  grep python-hip desktop
<mdz> zsh: exit 1     grep python-hip desktop
<mdz> that was removed ages ago
<mdz> kubuntu-desktop doesn't depend on it either
<elmo> kubuntu-desktop |       0.25 |         hoary | sparc
<elmo> kubuntu-desktop |       0.29 |         hoary | amd64, i386, ia64, powerpc
<elmo> unfortunately the old sparc one does
<elmo> I can take sparc out of the germinate arches  for now, but that'll fill the list with false positives about wanting to remove sparc specific stuff
<mdz> pitti: also, l-s-en should depend on openoffice.org-thesaurus-en-us
<mdz> elmo: is that because sparc isn't building any packages?
<elmo> mdz: yes
<mdz> I wonder which breakage is worse
<mdz> the false positives for sparc-specific stuff, or the false positives for sparc out-of-date stuff
<elmo> if I could think of a way to trivally purge out-of-date sparc binaries that might be easiest
<Disaster> sorry... someone try to compile Canon I250 driver for ubuntu ?
<mdz> Disaster: #ubuntu for support
<Disaster> mdz... i'm trying...
<mdz> Disaster: thanks
<mdz> lamont: ping
<mdz> meta-kde is sparc fallout too
<mdz> elmo: how did kubuntu-meta manage to remain in universe while its binaries were promoted to main?
<elmo> mdz: 'cos the promotion script isn't smart about that, I fixed it just now tho
<mdz> thanks
<elmo> I need to run an audit of that tho, as there's going to be other cases
<mxpxpod> seb128: thanks for the gtkmm update
<mxpxpod> you rawk
<mdz> elmo: emailed you a batch of stuff, including the two cases of that that I see in the current list
<seb128> mxpxpod: np, you should thanks dholbach who is working on the packages :)
<mxpxpod> dholbach: you rawk :)
<dholbach> mxpxpod: thanks :-)
<T-Bone> Mithrandir: ping64? :)
<T-Bone> mdz: ?
<mdz> T-Bone?
<T-Bone> mdz: i just received an auto-discard notification for a mail you sent to kernel-team. Any idea why?
<mdz> T-Bone: I did indeed send a mail to kernel-team, but I have no idea why it would be discarded
<mdz> did someone add me to the discard list?
<T-Bone> mdz: to the contrary, i added you to the accept list
* T-Bone checks
<Amaranth> sorry, xchat-gnome is buggy
<T-Bone> mdz: you'll need to ask lamont, i don't have enough rights to check
<mdz> T-Bone: sure enough, I'm on the discard list
<T-Bone> mdz: hell, have i screwed?
<mdz> T-Bone: I fixed it
<mdz> I can't say how it happened
<T-Bone> more than strange. I'm pretty certain I chose to add you to auto accept list
<T-Bone> and I don't recall handling list administrativia while being drunk :}
<Kamion> mdz: could I upload http://riva.ucam.org/~cjwatson/tmp/choose-mirror.ftp.diff (fixes a netboot crasher that svenl discovered) and http://riva.ucam.org/~cjwatson/tmp/ddetect.empty-list.diff (fixes a nasty hw-detect crasher if all modules were already coldplugged, that probably causes some other hardware detection problems), please?
* mdz runs away in horror at that perl RE
<mdz> Kamion: yes
<Kamion> yeah, I probably wouldn't do it that way if it were new code, but ...
<Mithrandir> T-Bone: pong128
<mdz> ogra: so speaking of hwdb, will we hit our target for preview?
<ogra> 8th ?
<ogra> i think so
<mdz> lamont: where are you?
<ogra> the -gui is almost ready....
<T-Bone> Mithrandir: yay! ready for it?
<mdz> ogra: I have looked at what is in hoary; it looks very nice but the functionality does not seem to be there yet :-)
<Mithrandir> T-Bone: yes; I don't have very much time, but we'll see what we can get done in the timeframe.
<T-Bone> Mithrandir: awsome
<ogra> mdz: it is working here :), the send stuff is missing and i have to write something to glue it together.... done within two days i think....i'll roll an updated package today with the completed ui stuff 
<mdz> ogra: great
<zul> mdz: lamont might be asleep
<mdz> zul: oh?
<zul> mdz: im just guessing not sure exactly
<mdz> zul: it's 1230 in lamont's time zone :-)
<zul> mdz: heh people can sleep in til 1230 i certainly do somethimes
<zul> or he could of have been hit by a bus
<mdz> lamont is usually here at about 0900
<zul> true speak of the devil
<mdz> lamont_r: good morning, everything ok?
* T-Bone blinks at lamont_r's hostname :}
<lamont_r> T-Bone, shsh
<zul> hey lamont_r
<T-Bone> lol
<lamont_r> mdz: yeah - errands took way longer than planned, then had promised to help a buddy out for an hour or so this afternnon...
<mdz> jbailey: #1080?
<mdz> lamont_r: do we have kubuntu cloop images for all architectures?
* lamont_r will check
<mdz> elmo: the only weird one remaining in sync.txt seems to be boost; I can't easily tell whether that falls into one of the existing classes of weirdness or not
<lamont__r> mdz: all.  For values of all which do not include ia64.
<mdz> lamont__r: good enough
<mdz> Kamion: will the daily run fail because of that?
<mdz> Kamion: if so, can we set the default arch list to exclude ia64 for kubuntu?
<lamont__r> mdz: may as well set the arch list to !ia64 until firefox is fixed
<elmo> libboost-python-dev              | boost                         | kdeedu (Build-Depend)              
<elmo> is where boost comes from according to my germinate
<mdz> why does that stuff show up in your germinate, and not in colin's published one?
<mdz> http://people.ubuntu.com/~cjwatson/germinate-output/kubuntu-hoary/all doesn't even have kdeedu in it
<mdz> oh, I wonder if that's sparc fallout
<elmo> yeah, could be
<mdz> must be; I think Colin's is i386-only or something
<elmo> kdeedu -> kde-amusements -> meta-kde
<mdz> kde-amusements isn't pulled in by anything today, but it might be in the old broken sparc ubuntu-desktop
<Riddell> mdz: is it possible to remove update-notifier from the seed?
<elmo> lemme just purge the specific sparc packages that are cuasing us grief, i.e. mostly kubuntu-desktop
<mdz> elmo: there are only like 2 sparc-specific packages; I think it'd be better to exclude it if it's not easy to purge
<mdz> Riddell: certainly
<lamont__r> elmo: note that the sparc buildd died shortly after fabbione went away...
<elmo> lamont__r: I know
<elmo> mdz: what else would I need to purge?
<elmo> I've killed kubuntu-* for sparc
<mdz> Riddell: seeds updated; I'll upload kubuntu-meta in >=17 minutes
<mdz> elmo: all of the examples we've seen so far seem to go back to kubuntu-desktop
<mdz> the openoffice stuff will disappear when pitti uploads new langpacks
<Riddell> mdz: cool thanks, then once we get the 3.4 packages in that should mean no gnome stuff is being brought in
<mdz> Riddell: I just built a new set of kubuntu live CDs
<lamont__r> how sane are the current dailies?  or should I pull array 6?
<mdz> Riddell: now for i386, amd64 and powerpc
<elmo> mdz: ok, I'll regen the list after cron.daily
<mdz> Riddell: if you'd like to make an announcement about it
<mdz> lamont__r: should be quite sane
<Riddell> mdz: are we going to get daily live CDs?
<mdz> Riddell: yes, starting tomorrow morning UTC
<haggai> Riddell: yup 6am UTC
<mdz> lamont__r: the cloop builds are dailified too, right?
<mdz> (for kubuntu)
<Riddell> mdz: cool stuff
* Riddell wonders about announcing to all of {k,}ubuntu-{devel,users}
* lamont__r ponders the absent state of ppc livecd
<mdz> lamont__r: http://weddell.buildd/%7Ebuildd/livecd/ubuntu/current/livecd.ubuntu.cloop:
<mdz> 08:04:07 ERROR 404: Not Found.
<lamont__r> weddell == ia64, see abover
<lamont__r> hrm.. I guess I could hand migrate the ubuntu rootfs image over there.. give me a second
<mdz> hmm
<mdz> no obvious error in powerpc
<mdz> Kamion: still here?
<lamont__r> ubuntu should be better
<mdz> hmm?
<lamont__r> ia64/ubuntu shouldn't be 404 anymore
<mdz> I'm looking for a reason why the ubuntu hoary-live-powerpc.iso went missing
<mdz> oh
<mdz> it failed because of ia64, apparently
<mdz> doing a new live build now
<Riddell> I'm missing a package, knetworkconf seems to have disappeared, how can I find out what's happened to it
<mdz> Riddell: disappeared from where?
<mdz> it doesn't appear to have ever existed in the Ubuntu archive
<mdz> or in Debian
<Riddell> mdz: I'm sure it used to be in universe
<mdz> or is knetworkconf a program in a package with a different name?
<Riddell> maybe it was in some other source line that I've since removed
<Riddell> ah yes, kalyxo it must have been
<Riddell> is there a last date for adding this to and modifying universe?
<Riddell> s/this/things/
<seb128> Mithrandir: here ?
<Mithrandir> seb128: pong
<seb128> Mithrandir: what wm do you use ?
<Mithrandir> openbox
<seb128> do you need this hack ? https://bugzilla.ubuntu.com/show_bug.cgi?id=7049
<mdz> Riddell: at this point there are no plans for a universe freeze
<mdz> Riddell: it's essentially up to MOTU as far as I'm concerned
<mdz> what is there at release is what we get :-)
<Riddell> mdz: so it'll just be forked on april 4th?
<ajmitch> mdz: we don't have a real freeze for universe?
<mdz> lamont__r: full set of live ubuntu live isos now
<Mithrandir> seb128: I think I just did openbox --replace when I first started it and whacked metacity out of the gnome-session stuff.
<ajmitch> that's good, in a way 
<mdz> ajmitch: see above
<seb128> Mithrandir: k, thanks
<tseng> openbox --replace, and then save session on log out is easiest
<seb128> Mithrandir: what do you have is this key ?
<Mithrandir> seb128: I haven't touched that file, that's sure.
<seb128> that's a gconf key
<seb128> and I'm wondering if GNOME is changing it when you do that
<Mithrandir> /usr/bin/gnome-wm is a file. :P
<seb128> /desktop/gnome/applications/window_manager/default I mean :)
<Mithrandir> : tfheen@thosu ~ > gconftool-2 -g /desktop/gnome/applications/window_manager/default
<Mithrandir> No value set for `/desktop/gnome/applications/window_manager/default'
<seb128> weird 
<lamont__r> mdz: fwiw, I'm going to work on bootstrapping as many circular-deps as I can find this evening, unless there's something more urgent that you dump on me.
<seb128> oh
<seb128> Mithrandir: /desktop/gnome/applications/window_manager/current ?
<Mithrandir> /usr/bin/metacity
<seb128> k, I get it
<seb128> thanks
<Mithrandir> though:
<Mithrandir> : tfheen@thosu ~ > ps ax | grep openbox
<Mithrandir>  9135 ?        Ss     0:06 openbox --sm-save-file /home/tfheen/.local/share/openbox/sessions/1102093921-5222-1361235971.obs
<seb128> yeah, the session is taking care of it I guess
* lamont__r wanders for a few minutes
<seb128> you have it in ~/.gnome2/session, right ?
<Mithrandir> seb128: yes, it's a RestartCommand
<seb128> k, thanks
<mdz> lamont__r: bootstrapping circular deps on which architecture?
<mdz> lamont__r: what is the status of the patch review?  patches were scheduled to start flowing to Debian today
<trukulo> hi ppl
<sabdfl> hey trukulo
<Nafallo> hi there trukulo :-)
<trukulo> looking here about xorg in my laptop in hoary
<trukulo> :)
<abelli> smurfix: ping
<zul> tseng/jdub: inotify 0.20 for 2.6.11 has been released
<trukulo> i have one question, is dri enabled in 2.6.10-4-k7 ?
<elmo> mdz: updated
<Loevborg> trukulo, of course, yes.
<trukulo> Loevborg, ok, only wanna know for testing my igp 320m , thanks
<trukulo> it's very strange because live cd with glxinfo gives me Direct Rendering, and hoary installed not
<seb128> zul: should fixes the issues with the current version, are you going to update it ? :)
<zul> seb128: of course its on my todo list for this weekend
<seb128> cool
<zul> later folks
<mdz> elmo: much better
<jammcq> like more than 10 mins ago?
<jammcq> oops :)
<trukulo> hi Oliver
<ogra> trukulo: hi
<ogra> trukulo: didnt you say graveman should enter sid soon ? last week it wasnt in....
* lamont__r wanders off for a few
<trukulo> ogra, ask elmo, it's waiting for ftpmaster action three weeks
<trukulo> ;)
<ogra> oh
<trukulo> debian seems going slowly to accept new packages (i'm not an expert, just only seems to me)
<abelli> mvo: ciao
<crimsun> I'm wondering if we will move to 2.6.11.1
<crimsun> as a base point, that is. 2.6.x or 2.6.x.y
<crimsun> (and I don't mean for Hoary, since it makes sense to stick with .10)
<mvo> abelli: hi
<abelli> jdub: ping
<Riddell> mvo: could I get write access to kynaptic's repository? there's a few things I'd like to tidy up
<abelli> Burgundavia: hi
<mvo> Riddell: I can ask gustavo about it. until then I can commit your patches
<Riddell> mvo: ok
<mvo> Riddell: I investigated the konsole kpart and it looks like it's not usefull for our purpose :( it seems to lack a "fork_pty" method. synaptic forks of a pty and call dpkgpm->Go() in the child. all output is then displayed in the terminal window (because vte supports fork_pty)
<mvo> Riddell: I need a prefered username and a htpasswd -m crypted password for your account to the kynaptic svn
* mdz has had quite enough of monsoon season in LA
* ogra had the last time 40cm snow in march when he was a child
<mvo> mdz: any chance to sneak a synaptic and update-manager update in for the preview? both fix a bunch of (small) bugs
<mdz> mvo: please mail me diffs
<mvo> mdz: the (deb)diffs are ready, I guess I need to explain a bit about them and link to the bugs they fix. I'll send you a mail tonight 
<Burgundavia> abelli: hey
<mdz> mvo: if it is not something which is critical for preview, I'm inclined to wait.  we need to be very cautious at this stage
<mdz> mvo: there will be time for more small fixes after preview
<trukulo> ogra, you there?
<ogra> yup
<mdz> mvo: but I am happy to review these specific cases with you
<ogra> (eating)
<trukulo> i have graveman package 0.3.8 if you want it
<trukulo> talk to me when you finish
<ogra> trukulo: usual place ?
<trukulo> ogra, no
<trukulo> in my computer
<ogra> oh
<trukulo> when i build it, i can put it on web
<ogra> trukulo: great
<trukulo> with description changed
<zul> hilo
<trukulo> i will put it on http://mercurio.homeip.net/debian
<trukulo> remember, it's for sid
<ogra> trukulo: i do :)
<trukulo> ogra, uploaded
<ogra> trukulo: i'll pull them tonight...upload during the weekend, thanks :)
<trukulo> ok
<lupusBE> daniels, ping
<mvo> hey Mitario 
<Mitario> hi everyone
<Mitario> mvo, hi!
<tseng> mvo: hey. any idea why pkgstriptranslations would want to touch a file in update-notifier
<tseng> /var/lib/update-notifier/dpkg-status or something like that
#ubuntu-devel 2005-03-16
<tseng> its breaking my pbuilder
<mvo> tseng: a not purged update-notifier maybe? it looks like debris in /etc/apt/apt.conf.d/99update-notifier ?
<tseng> mvo: will look. it shouldve never had update-notifer, its a chroot
<tseng> no X
<mvo> tseng: I know :) it looks looks like this config-file :)
<dholbach> tseng: you cleared unneeded stuff in /etc/pbuilder/apt.conf.d/ ?
<tseng> dholbach: hm its in there in fact
<tseng> dholbach: good call!
<mdz> jdub: update on #6582?
<dholbach> tseng: ran into it too :-)
<tseng> dholbach: I better note that on the wiki
<dholbach> tseng: yeah... good thinking
<tseng> its very vexxing
<dholbach> i guess i'm off for tonight... good night
<tseng> bye again dholbach 
<dholbach> bye tseng 
<sivang> hey all
<jdub> mdz: no traction from upstream, so two choices: go with oss by default, or revert to esound.
* sivang is here for about an hour or so
<mdz> jdub: ok, I know pitti encounters this bug, so perhaps he can have a look
<mdz> daniels: ping?
<mdz> zul: are you guys planning another kernel upload before preview, or no?
<seb128> mdz: 
<seb128> <seb128> zul: should fixes the issues with the current version, are you going to update it ? :)
<seb128> <zul> seb128: of course its on my todo list for this weekend
<seb128> mdz: that's speaking about the inotify update
<zul> mdz: yeah there is a couple of bug fixes including inotify update
<seb128> oh zul is here
<seb128> :)
<zul> im around
<seb128> yeah, I've seen that :)
<T-Bone> so am i (but not for long) :)
<seb128> BTW mdk has just rolled back to dnotify for 10.2
<zul> mdz: the bugs i seen for some keyboard problems, with ps/2 keyboards locking up on some chipsets there is a patch in ac serries that prevents it from loking up
<seb128> I'm curious to know if they will switch again :)
<zul> mdz: http://www.dragoninc.on.ca/mail-archives/linux-kernel/2004-07/5260.html
<zul> plus the 3ware proc_name stuff
* zul goes wonder off
<tseng> bye zul 
<tseng> seb128: w/o looking in the source.. whats "openbox fixes" mean
* T-Bone calls it a night, bye all
<seb128> tseng: read the bugzilla for it :p
<mdz> zul: that patch looks very sketchy :-)  but if it works...
<seb128> tseng: basically need to add a session management option to start openbox
<tseng> oh there is the bug number
<tseng> im dumb
<jdub> seb128: in gnome-panel i now have "Home Folder" and "Desktop Folder|Desktop" - you seeing this?
<seb128> jdub: nop
<zul> mdz: it was included in fc2
<seb128> jdub: weird "...|" is a comment for translators usually
<seb128> jdub: what locale is that ?
<tseng> it sounds like a bong .po file
<seb128> yep
<tseng> similar happened to me in muine cvs recently
<zul> damn it...i hate inotify sometimes
<tseng> zul: sometimes?
<seb128> :)
<jdub> en_AU.UTF-8
<zul> ok...most times
<seb128> jdub: is that a real locale ? :p
<seb128> no .po for that, hum
* jdub spanks seb128 
<seb128> :p
<Riddell> I seem to be able to edit the ubuntu website
<Riddell> I don't think I should be able to
<jdub> people.ubuntu.com/~jdub/screenshots/odd-places-menu.png
<seb128> jdub: en_AU is using any langpack ?
<jdub> the en langpack
<jdub> i'll check if there's a translation
<seb128> thanks
<Riddell> http://muse.19inch.net/~jr/tmp/ubuntu-edit.png
<seb128> I don't have that in "C" locale here
<seb128> urg
<seb128> that's ugly
<seb128> what browser is that ?
<jdub> no language
<tseng> konqueror, the worst usability kludge ever
<seb128> utch
<Riddell> should I be able to edit the ubuntu website?
<jdub> seb128: is 'utch' french for 'ouch'? :)
<seb128> correct ;)
<seb128> or a variant, you can use both :)
<seb128> BTW the spinner is ugly on this screenshot, and the icons bigs/weirds 
<jdub> Uploading via ftp clearlooks_0.4-0ubuntu1_source.changes: done.
<jdub> Successfully uploaded packages.
<tseng> seb128: to each his own
<tseng> jdub: rock.
<seb128> gnome-panel/panel-menu-items.c:                         Q_("Desktop Folder|Desktop")
<jdub> seb128: is "Desktop Folder" our change?
<seb128> nop
<seb128> that's a comment for translators
<jdub> oh
<seb128> and from the upstream source
<jdub> thought it was other way around, my bong
<seb128> Q(..|...) is comment|string
<seb128> I don't understand why that's bong on your system :)
<jdub> cl 0.4 has animated progress bars :)
<seb128> cool
<seb128> grumpf
<kent> clear looks is a nice engine. :)
* seb128 doesn't like language pack slowing the translations updates
<Riddell> should I be able to edit the ubuntu website?
<jdub> not really
<sivang> Riddell: you can edit some areas of it with your wiki loging
<sivang> Riddell: login, even
<sivang> Riddell: I for instance, add news items , sidebar announcments, faqs etc
<Riddell> sivang: like security notices?
<sivang> Riddell: that I am not sure. You would have to ask mdz/pitti how they do it , or about anybody else who deals with security
<elmo> jdub: package name changed?
<sivang> Riddell: (e.g., not sure if the USNs are part of the doc team allowed content editing sections)
<seb128> #. Translators: Desktop is
<seb128> #. * Folder" (this is not the
<seb128> #. * not keep "Desktop Folder|"
<seb128> #: ../gnome-panel/panel-menu-bar.c:622
<seb128> msgid "Desktop Folder|Desktop"
<seb128> msgstr "Desktop Folder|Desktop"
<seb128> in the en_GB.po
<mdz> Riddell: only security personnel can modify the security notices
<seb128> bah, translators don't read the comments :p
<Riddell> mdz: I seem to be able to modify them
<mdz> Riddell: URL?
<Riddell> http://www.ubuntulinux.org/support/documentation/usn/usn-1-1 for example
<Riddell> mdz: http://muse.19inch.net/~jr/tmp/ubuntu-edit1.png
<mdz> Riddell: what happens if you click the edit tab?
<Riddell> mdz: then I can edit and save
<mdz> how unfortunate
<mdz> I fucking hate plone
<Keybuk> how much do you hate it?  On a scale of 1 to Arch?
<mdz> sqrt(arch)
<zul> lol
<aj> Keybuk: woah, *ouch* dude!
* seb128 kicks the language packs
<seb128> jdub: I get the issue too with the french locale without the language pack with the deb :p
<zul> mdz: do you have a representative for the kernel team for the meeting next friday?
<mdz> zul: lamont will presumably attend, but any and all are welcome
<zul> mdz: k cool
* lamont will be there
<zul> better be :)
<seb128> jdub: 
<seb128> en_GB.po
<seb128> et.po
<seb128> fr.po
<seb128> mk.po
<seb128> jdub: these are the bugged po file ... are you sure you are not using "en_GB" ? :)
<Nafallo> would someone here have the time to implement lookup for SRV-records in gaim's jabbercode post-hoary? should I sign a bug about it?
<jdub> seb128: ah, it must be falling back through it; yeah
<jdub> $ cat /etc/environment
<jdub> LANGUAGE="en_AU:en_US:en_GB:en"
* Liblit waves to seb128.
<mdz> Nafallo: it isn't generally useful to file bugs asking for features unless they are trivial
<seb128> hi Liblit 
<seb128> jdub: k, that's it :)
<Liblit> Howdy.
<jdub> cool :)
<jdub> you Liblit 
<Liblit> No specific questions at the moment.  Just being neighborly.
<seb128> jdub: I'll bug translators
<seb128> Liblit: k
<Liblit> jdub: me Liblit.  You jdub.  Where Tarzan?
<seb128> :)
<Nafallo> mdz: oki. upstream just asked for a patch for it on my RFE. I haven't got the skills though. maybe I could try and someone could review it? :-)
<jdub> heh
<seb128> Liblit: calling mdz Tarzan ? :p
<jdub> we have a jane, too ;)
* Liblit isn't calling anybody anything, and should probably go home before he gets himself in trouble.
<mdz> Nafallo: sure, ask on #ubuntu-motu
<mdz> Nafallo: we simply can't accept feature requests for all of the features that the world would like to see in open source software :-)
<Nafallo> mdz: I know. just had to try first. the situation is so... awfully dumb. all servers supports SRV but I have yet to see a client that does. and that's for a thing being in the XMPP Core RFC.
<seb128> lamont: around ?
<lamont> yo
<seb128> do you have an idea on the gtk-doc issue ?
<seb128> works fine in an hoary pbuilder here
<seb128> apt-get source gtk-doc
<lamont> I haven't bothered to track down which package is Depend'ing openjade, but the solution is to either fix gtk-doc to not Conflict: openjade (whatever that takes), or to change whatever Depends: openjade to accept something else
<seb128> and debuild
<seb128> that works in a pbuilder
<seb128> the buildd gets the Recommends or what ?
* lamont tries giving it back
<seb128> k
<lamont> pbuilder picks Depends differently than sbuild
<seb128> apt-get source gtk-doc
<seb128> Package openjade is not installed, so not removed
<seb128> The following NEW packages will be installed:
<seb128>   cdbs debconf-utils debhelper docbook docbook-dsssl docbook-xml docbook-xsl file gettext html2text intltool-debian jade
<seb128>   libmagic1 libosp4 libostyle1 libsp1 libxml2 libxml2-utils libxslt1.1 po-debconf sgml-base sgml-data xml-core xsltproc
<seb128> 0 upgraded, 24 newly installed, 0 to remove and 69 not upgraded.
<seb128> 
<seb128> does that in a pbuilder
<seb128> a Depends is a Depends
<seb128> there is different way to pick them ?
<lamont> yeah, but | lists are handled differently
<seb128> k
<Keybuk> hrm, dangerous; half a bottle of red wine seems to have vanished
<lamont> (our) sbuild takes the first installable one, [debian's sbuild takes the first one, period] , and pbuilder takes the last one
<seb128> and xorg crash, nice :p
* lamont reproduces the build failure on his machine, updates the chroot. :-)
<seb128> docbook-dsssl
<seb128> Depends: openjade | jade
<seb128> 
<seb128> I guess that's it
<lamont> The following NEW packages will be installed:
<lamont>   cdbs debconf debconf-i18n debconf-utils debhelper docbook docbook-dsssl
<lamont>   docbook-xml docbook-xsl file gettext gettext-base html2text intltool-debian
<lamont>   jade liblocale-gettext-perl libmagic1 libosp4 libostyle1 libsp1
<lamont>   libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libxml2
<lamont>   libxml2-utils libxslt1.1 openjade po-debconf sgml-base sgml-data xml-core
<lamont>   xsltproc
<lamont> could be
<seb128> "  * [debian/control]  Added Build-Conflicts-Indep: openjade to ensure that jade
<seb128>     rather than openjade is detected (the runtime dependency is on jade, not
<seb128>     openjade). (Closes: #247542)
<seb128> "
<seb128> for J.H.M in the changelog
<seb128> I tend to blame sbuild here :p
<lamont> one could re-order the tests?
<lamont> Kamion: you about?
<lamont> build-conflicts are just vile things....
* lamont hates them
<lamont> so the simple fix would be to fix the Depends order for docbook-dsssl :0)
<seb128> bah
<seb128> and an another package will require the other order
<sivang> seb128: since that upgrade I told you about, my system never got back to itself , did you have anybody else report the same?
<seb128> and we are screwed :p
<seb128> the fix is to fix sbuild
<seb128> jade | openjade is correct, apt-get source handles it fine
<sivang> seb128: redrawing a window takes ~2secs second
<seb128> no
<lamont> seb128: somehow, I fear you are correct.
<seb128> :)
<sivang> seb128: I have antoher ubuntu hoary, on another hd, which works fine. you have any idea what to check?
* lamont grumbles at mdz for breaking emacs21
<seb128> try to install something different from gnome
<seb128> ie: wmaker
<seb128> or perhaps that's due to the xorg driver
<lamont> seb128: jade | openjade is what I suggested changing it to. :-)
<sivang> seb128: I would suspect the xorg driver , maybe I should try install xfree86 ?
<daniels> mdz: pong
<seb128> lamont: yeah, but the order should not matter :)
<seb128> sivang: what video card and what driver do you use ?
<lamont> seb128: true.  But then, | lists are evil and shouldn't be there anyway
<lamont> that's what virtual packages are for
<lupusBE> daniels, do you need any other info about my bug? otherwise I can go to bed :)
<lamont> seb128: btw, feel free to beat on daniels about gossip_0.8-1ubuntu2
<seb128> lamont: even with virtual package you may want to set a preference
<lamont> checking for XScreenSaverRegister in -lXss... yes
<lamont> configure: error: Couldn't find XScreenSaver extension.
<lamont> m
<lamont> I just love that...
<seb128> I've already looked on gossip and pinged daniel
<seb128> I don't understand what's wrong
<lamont> seb128: actually, the policy? on virtual packages is that you Depend: real | virtual, with real being the highest priority alternative
<seb128> it used to work fine and has not changed, and the config.log doesn't show anything special
<seb128> lamont: right
<lamont> it says it found it in -lXss, and then immediately says it couldn't find it.... sounds like a configure script issue to me.....
<lamont> but really nfc
<sivang> seb128: using xorg 6.8.2-2, nvidia Geforce2
<seb128> yeah, I've tried to track it a bit but doesn't seems obvious
* lamont will stare at sbuild and see what can be done...
<lamont> where oh where is Kamion when I need him to do perl hacking for me???
<seb128> lamont: jade/openjade doesn't provide anything ... what do you suggest, changing the | order ?
<seb128> (ugly hack)
<lamont> the immediate fix is to change the order.  The longer term fix is for me (er, Kamion?) to fix sbuild....
<seb128> k
<lamont> in debian, the only fix is to change the order, fwiw
<sivang> seb128: 32M vid ram
<seb128> lamont: it builds fine in debian ...
<seb128> sivang: dunno, do you have the composite ?
<lamont> ah, cool.  it's Kamion's hack for layer'ed building. :-)
<sivang> seb128: what is composite? ;-)
<seb128> lamont: ups, no
<seb128> lamont: it's a "all" package, so no buildd used in debian for it
<seb128> sivang: transparancy stuff 
<sivang> seb128: where do I check it? xorg.conf?
<seb128> nm
<seb128> if you don't know about it you have not played with that
<lamont> seb128: doh. right
<daniels> lupusBE: which bug was that, sorry?  i have a lot ...
<sivang> seb128: ah ok
<lupusBE> daniels, https://bugzilla.ubuntu.com/show_bug.cgi?id=7123
<mdz> lamont: it's not obvious to me how to fix #7109.  can you take care of it?
<lamont> mdz: is that emacs?
<mdz> lamont: yes
<daniels> lupusBE: ah, -dev.  i don't know
<lamont> the choices are a well placed 'touch', or add autocrap to the Build-Depends... (which is what I did for zsh when it had a similar problem...) thoughts?
<lupusBE> yeah some problem with the linking :)
<mdz> lamont: touch
<lamont> ok.  the touch in zsh was lost deep in the bowels of something and I got tired of looking... This one should be trivial
<lamont> mdz: wanna do some perl hacking for me while I fix emacs?
<mdz> lamont: pardon?
<mdz> oh god not sbuild
<lamont> sbuild needs a little more love in it's build-dep selection algorithm.
<elmo> eh, why do you want to fix sbuild?
<lamont> which is on the edges of what I understand
<mdz> lamont: apt-get build-dep <package>
<daniels> elmo: any luck with dvi?
<lupusBE> going to bed :) hf daniels ;)
<lamont> mdz: understood
<lamont> elmo: gtk-doc is ftbfs
<lamont> and I have to agree that apt-get build-dep would do the right thing
<elmo> daniels: given up - I'm just using a 2nd laptop as a terminal to the dead powerbook
<lamont> mdz: although apt-get will randomize which virtual package gets selected, no?
<mdz> not that I am at all advocating that change at this time
<daniels> elmo: dude, that bites
<elmo> lamont: lemme get this straight it b-d's on a | b and conflicts with b?
<mdz> lamont: for pure virtual, it will abort and yell at you
<daniels> elmo: maybe your video hardware is totally shot?
<mdz> lamont: for a | b, it tries a, and sort of vaguely attempts to fall back to b
<lamont> elmo: it build-deps docbook-dsssl, which build-depends openjade | jade.  gtk-doc build-conflcts openjade
<mdz> elmo: have gtk-doc build-dep docbook-dsssl and jade
<lamont> the last great hackery on this code was by Kamion (thank you Kamion) to have it find the first package in the list that was installable (ogre modle)
<elmo> daniels: could well be, it'll need to be RMAed when I get to back to the UK in any event
<lamont> mdz: I like that idea...
<mdz> er, s/elmo/lamont/
<elmo> lamont: err, second  build-dep == dep?
<lamont> Build-Depends: cdbs, debhelper (>= 4.1.0), docbook-dsssl, xsltproc, jade (>= 1.2.1-35), libxml2-utils, docbook-xml, docbook-xsl
<lamont> Build-Conflicts-Indep: openjade
<lamont> sadly, so did the maintainer
<lamont> elmo: yes
<mdz> lamont: right, so put jade ahead of docbook-dsssl ;-)
<lamont> lol. /me tries
<mdz> are there actually valid use cases for build
<mdz> build-conflicts?
<lamont> yeah.  build-conflicts/.
<jba> guys why is it so damn hard to find a hoary download link on the ubuntulinux.org website?
<jba> i mean it's here in the topic, but I'm damned if i can find it on the website
<lamont> WOOOHOOO!!!
<lamont> seb128: I'm gonna upload a new gtk-doc, if that's OK with you...
<daniels> jba: because it's a development version -- it's not there for the masses
<jdub> jba: think of the children!
<seb128> lamont: np, go for it :)
<jba> daniels: i can appreciate that, but it is there, somewhere. It just pains me every time i need to go searching for it
<lamont> seb128/mdz: and we'll make sure that bob (lunchpad) handles the use case
<seb128> k
<jba> someone suggested I try array 6 last night cause i was having grub issues
<lamont> seb128: done
<jba> can someone sned a linky to array 6 please ?
<jba> or will a daily suffice?
<lamont> seb128: and that was _MUCH_ easier than perl hacking. :-)
<jba> please sir, i want some more
<jdub> cdimage.ubuntu.com
<tseng> http://cdimage.ubuntu.com/releases/hoary/array-6/
<tseng> that is posted many places.
<jba> tah fellas
<lamont> right.   emacs21
<jba> jdub: have you noticed that bit torrnet ports have been throttled in australian networks lately?
<jba> these days it's quicker to direct dl, than to torrent
<jdub> hrm, i don't tend to see that here
<seb128> lamont: yeah, nice way to get that solved :)
<jba> jdub: i'm on optusnet, it may just be specific to them
<lamont> seb128: not the most informative changelog entry, I admit.
<seb128> he he
<lamont> but moving the docbook-dsssl link after jade fixes things
<lamont> worst of it is that I understand why...
<lamont> mdz: what command did you use to (1) unpack and (2) pack the emacs21 upload?
* lamont bets on apt-get source and debuild
<zul> ok new test kernel with new inotify is being built now
<jdub> woo
<jdub> 2.6.10 or 11?
<zul> hopefully it will work
<zul> 2.6.11 didnt apply cleanly so i had to much around it
<zul> s/much/muck/g
<jdub> ahr
<mdz> lamont: dpkg-source and dpkg-source
<mdz> well, dpkg-buildpackage in the latter case, but indirectly dpkg-source
<lamont> mdz: ok.
<mdz> it was probably on a tmpfs, if you're wondering why you get a different order than I did
<lamont> of course, the other solution is to vi emacs21*.diff.gz :-)
* lamont ducks
* mdz throws rotten tomatoes at lamont for his gtk-doc changelog entry
<lamont> mdz: missed a step on that one...
<lamont> (1) try something, which means saying _something_ in changelog.  (1b) iterate.  (2) fix changelog to something proper.  (3) upload.
* lamont missed (2). :-(
<lamont> and realized that at 3.5
<lamont>  clean: debian-sync
<lamont> +       touch debian/autofiles.diff
<lamont>         ${checkdir}
* lamont feels unclean
<lamont>   * Fix ftbfs by touching autofiles.diff in clean target.  Closes: #7109
<lamont> that any better than gtk-doc???
* lamont uploads
<lamont> er, um... hrm...
<lamont> about those uploads...
<lamont> was I supposed to get permission first?
<lamont> DOH!
* lamont kinda thinks they were both defacto-approved, but ....
<lamont> where is the debian amd64 archive?
<azeem> on alioth, AFAIK
<lamont> azeem: somewhere on/under alioth, yes... was after the actual URL...
<azeem> http://alioth.debian.org/projects/debian-amd64/
<lamont> thanks
<mdz> lamont: FTBFS have implicit approval
* mdz hopes he doesn't regret saying that
<lamont> lol
* lamont hands mdz some valium
<mdz> I am so far beyond valium's reach
<daniels> mdz: smack is your friend
<zul> or crank
<daniels> mdz: so I'm going to roll the i810 driver back to 6.8.2, because HEAD is just broken to shit
<mdz> daniels: are you planning to try to squeeze in a xorg upload for preview?
<daniels> mdz: i810 needs to go
<mdz> daniels: when will you be ready?  I'd like to review the changes with you
<daniels> mdz: i'll try for asap
<daniels> mdz: probably not before you go to sleep tonight though
<mdz> I will be here tomorrow
<mdz> and sunday
<mdz> the repo man has all night, every night
<daniels> indeed he does
<daniels> i'll bounce you a link and changelog in /msg when it's done
* daniels looks at the pretty hailstorm out his window.
<jba> okay guys will check in if i get it working
<jdub> daniels: i810 is the source of the slowness bugs?
<daniels> jdub: nope, no idea what's up with that (works for me on i810 and radeon, and people have reported it with tdfx and nvidia also)
<jdub> hrm
<daniels> jdub: but mode validation on crts has been busted for a while (so desktop people can't use it, not even if they put in sync ranges), and I don't have time to fix it; apparently some laptop stuff is now rooted too
<jdub> i don't think i'm getting it here
<daniels> the two things we lose are: a) DRI around suspend/resume, b) support for widescreen panels
<daniels> jdub: i pulled i810 from HEAD a while back.  it is, imo, terminally broken.
<daniels> jdub: the features we get are DRI around suspend/resume (previously after you suspended, that's it; we need kernel support we don't have for that anyway), and support for widescreen panels without needing nasty hacks
<daniels> jdub: unfortunately, alanh doesn't believe in death by a thousand cuts, so his massive Tungsten code drop broke mode validation on CRTs (it will reject any mode above 800x600 @ 53Hz), and apparently you now need esoteric sync ranges for some laptop panels where you didn't before
<daniels> i don't have time to fix either of those issues before release (not that I have i8xx desktop hardware), and I don't think those two features (one of which we don't get anyway) are worth it for breaking a whole swathe of Intel hardware
<Keybuk> why does g-v-m always segfault on upgrade?
<jdub> weird, that never happened to me until very recently
<zul> it happens alot
<zul> i get the same thing
<stuNNed> so if i run 'nv' driver instead of 'nvidia' i won't have the slownessness?
<stuNNed> daniels: thanks for the info
<daniels> Keybuk: either dbus semantics have changed under us, or we've regressed a patch
<Keybuk> it's a recentish thing
* lamont decides that even though 10 packages are blocked by gcc-2.95 d-w: gcc-2.95, it won't get bootstrapped.
* ..[topic/#ubuntu-devel:fgx] : /whois fgx
<fgx> sorry
<fgx> mdz, im sorry
<Keybuk> is it me or is python2.4-psycopg broken?
<Keybuk> no, it's me
<daniels> does anyone have the topic in /lastlog?
<stuNNed> Topic for #ubuntu-devel: Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for
<stuNNed>           getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources |
<stuNNed>           http://www.ubuntulinux.org/wiki/HoaryGoals | If your system hangs at login on Hoary, upgrade to kernel
<stuNNed>           2.6.10-24 | http://cdimage.ubuntu.com/kubuntu/daily-live/current/
<stuNNed> sorry
* ..[topic/#ubuntu-devel:daniels] : 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 | If your system hangs at login on Hoary, upgrade to kernel 2.6.10-24 | http://cdimage.ubuntu.com/kubuntu/daily-live/current/
<daniels> stuNNed: thanks a lot
<stuNNed> daniels: you're welcome
<mdz> what was fgx apologizing for?
<mdz> oh, clobbering the topic I suppose
<lamont> ghc6 takes 3 &*()& hours to build??? sigh
<marcin_ant> hi
<marcin_ant> I would like to ask what is a status of gnome-bluetooth package?
<lamont> looks to be in the archive on all architectures...
<lamont> http://archive.ubuntu.com/ubuntu/pool/universe/g/gnome-bluetooth
<marcin_ant> I got this on my system but it doesn't work with nautilus.... is this package broken?
<lamont> nfc
<lamont> and that really sounds like a #ubuntu question
<marcin_ant> hmm maybe
<lamont> marcin_ant: this would be the channel to discuss your patch that fixes the problem you're seeing
<marcin_ant> ok - but now I don't know if it's problem with my desktop or with package
<marcin_ant> anyway I'll try again on #ubuntu
<lamont> which is why you discuss that in #ubuntu
<marcin_ant> ok ok
* usual yawwwnnns
<jba> success, finally
<jba> i got array 6 to boot off my second drive, but only after setting up grub to install on the MBR of the first disk
<jba> I'm too annoyed to try and chain loaded at this stage, and am gonna leave it as is
<jba> but how come I can't tell the weather applet that I'm in sydney?
<jba> shit updates galore
<jba> okay will wait for the updates to install before proceeding 
<mdz> stupid X.org
<mdz> I moved xorg.conf away to try to reproduce #6286
<mdz> but the silly thing just works anyway
* mdz introduces a syntax error instead
<zul> heh
<zul> inotify is so much fun
* lamont finally sleeps
<mdz> lamont: night
<zul> night lamont
<mdz> no rest for the wicked
<zul> yeah i just cant sleep just yet
<zul> im going to get 2.6.11 cleaned up this weekend hopefully as well
<mdz> 95 bugs to go
<zul> rc bugs?
<mdz> 95 more in the list of bugs to review tonight
<zul> ouch
<zul> night..
<zul> kernel is compiling i can go to bed now :)
<Amaranth> 95 bugs in what?
<Amaranth> ack
<Amaranth> ubuntu bugzilla crashed firefox
<pitti> Morning
<pitti> mdz: still here?
<da_bon_bon> how do i help in translation of ubuntu to hindi language ?
<pitti> da_bon_bon: in the near future you can use Rosetta for this
<pitti> da_bon_bon: https://launchpad.ubuntu.com/
<da_bon_bon> whats rosetta ?
<pitti> jdub: ping
<Micksa> anyone care to recommend an app for watching network bandwidth over snmp?
<Micksa> something that draws pretty graphs?
<Micksa> with varying averaging windows maybe
<pitti> Hi dholbach 
<dholbach> hi pitti!
<dholbach> hi everyone
<herzi> Treenaks: ping
<Treenaks> herzi: pong
<herzi> Treenaks: did you take a look at the packages?
<Treenaks> herzi: which ones?
<herzi> the hula ones
<Treenaks> uh, not yet
<Treenaks> (hm: "applications" is white when I click it, "Places" and "System" are black.. CleanLooks or whatever the new theme is called)
<Treenaks> herzi: Only -2  I guess?
<herzi> yes, i already have -3 but that won\t get uploaded until monday
<dholbach> herzi: did you read my query?
<dholbach> morning sabdfl 
<sabdfl> hi daniel
<dholbach> sabdfl: you know if there are any plans for rss-feeds in malone? i think it'd be easier for people (debian and us) to track bugs and patches with them
<dholbach> sabdfl: i, for example, track new upstream releases with them and think they're much nicer than a bunch of emails :-)
<sabdfl> daniels: what determines the look of the pointer? specifically the please-wait-i'm-working one? it was much nicer in warty, and i'd like that back!
<sabdfl> dholbach: plans, not code yet, for rss
<Treenaks> sabdfl: the mouse pointer is a theme thing, afaik
<sabdfl> dholbach: also, an email interface for malone, which will let you avoid the web in favour of pure email working
<sabdfl> even when X is first starting?
<Treenaks> sabdfl: and the default was changed a few months ago, no reason given
<sabdfl> hmm... clearlooks rocks
<sabdfl> (speaking of themes)
<dholbach> sabdfl: oh ok... cool, the redland stuff seems worth investigating there, i'll ask bradb if he turns up
<Micksa> anyone here ever used xvfb-run? :)
<dholbach> Micksa: just in a build-script, once
<Micksa> I'm trying to get a "virtual X session" going with xvfb and vnc.
<Micksa> not much luck yet.
<dholbach> Micksa: sorry, can't help you there... just know it was called by the script since xvfb-run was broken in that X version, but is fixed now
<Micksa> oh what the fuck
<Micksa> it just started magically working :)
<Micksa> I think it's an xauth-related issue
<Micksa> which means I have to figure out how xauth et al work :)
<Micksa> shit.
<dholbach> Micksa: hope someone turns up who can help you there
<Micksa> bingo
<Micksa> it creates is on Xauthority file
<Micksa> and doesn't tell anyone about it
<dholbach> hellas mvo
<mvo> hi dholbach
<abelli> sabdfl: ping
<sabdfl> abelli: pong
<sabdfl> dholbach: redland?
<dholbach> sabdfl: libraries to generate rdf-stuff, they even have python bindings
<abelli> have you got 10 mins for me, id like to ask for a advice
<sabdfl> ah, cool
<sabdfl> go ahead
<trukulo> ogra, are you awake ?
<ogra> yup
<dholbach> hi seb128 
<seb128> morning
<trukulo> ogra, have you tried graveman packages? any problem?
<trukulo> morning everybody
<ogra> trukulo: havent had time to build them yet....if there are probs, i'll fix them and let you know.....(i'm working hard on hwdb-client to get it ready before preview)
<trukulo> ok ogra
<trukulo> good luck with hwdb
<ogra> thanks :)
<trukulo> daniels, r u awake?
<Micksa> http://knobbits.org/ws.png
<Micksa> dammit dammit dammit :)
<abelli> Kqikxs on #ubuntu is a spambot
<psy> hi
<abelli> ciao
* psy is curious about the graphical installer
<abelli> Djyuf on #ubuntu is a spambot
<abelli> :)
<psy> is there anyway i can help with the graphical installer?
* psy read the wiki and thougth 'why not write the installer in python? using pygtk?'
<ogra> psy: you would need pygtk in the installer image....which would involve a lot of other stuff...but thats not the main prob with the intaller....
<ogra> psy: you need a graphical driver that works on all systems we support ....
<psy> with the right scripting you could run through a series of drivers until you find one that works, running back to the old installer when everything else failes
<ogra> psy: i think the way to go is plain C and gtk but first there has to be a graphical (framebuffer or tinyX etc...) environment that works right everywhere....
<sivang> ogra: that's probably it :) Howdy btw?
<ogra> psy: thats the plan, but still, you need soething that works and doesnt suck.....there will be more decisions after release, since its a goal for hoary+1
<ogra> hi sivang 
* ogra curses at CanvasRichText
<sivang> ogra: I thought you like the canvas and it's subclasses? ;-)
<ogra> heh, only if they do what i want.....
<psy> CanvasRichText... something java?
<ogra> or if i can explain why they dont....
<ogra> psy: pygtk.....gnomecanvas
<psy> :)
<ogra> i use it as a transparent textinput field......as long as text is in there, everything is fine....if its empty, the cursor is glued to the right border....
<psy> :p
<ogra> which is kind of weird (execpt for sivang who starts wirting at this side)
<sivang> ogra: hehe , well, and not even in most of the cases :)
<ogra> heh
<psy> ogra: when you choose high-level language and libs that run on different lowlevel-drivers without having to change its source you can divide the project in two parts, one for the hardware-support and one for the software-support (release-info, packages, install-types etc...)
<psy> when good and clear decisions are made about the medium between the two you get fast and good results.
<psy> or am i talking rubbish/
<psy> ?
<ogra> psy: and exactly the decision about the lowlevel drivers is missin
<ogra> g
<ogra> writing the gtk stuff will be a quick thing (its just themeing the content in another way)
<psy> is there a list of options? or isn't there?
<ogra> options ?
<sivang> ogra: I also recall discussoins about some redesign over cdebconf to allow the asynchronous way of asking and "answering" install questions, has this already been done?
<psy> ogra: which drivers are still in the race ;)
<ogra> sivang, dunno, but i doubt there was time for it
<ogra> psy: i think all of them since the decision was postponed....
<ogra> psy: it will be discussed after hoary....
<ogra> s/be/get
<psy> ok
<ogra> sivang: how is your printmanager stuff evolving ?
<sivang> ogra: actually done and working :) pitti has to fix another bug in g-c-m which related to the way it communicates with the cups server, and we're set :)
<ogra> yay
<sivang> ogra: (by working , I mean that all of the frontend stuff I had trobule are solved, but pitti must close that upstream bug before the functionality is complete)
<ogra> he will do, i'm sure :)
<sivang> ogra: actually, he may have already :) I need to check
<jdub> mdz: around?
<ogra> jdub, any idea what happend to the march calendar ?
<trukulo> daniels, are you online?
<jdub> ogra: it was uploaded
<jdub> ogra: some people clearly have it...
<jdub> $ apt-cache show ubuntu-calendar-march | grep ^Filename
<jdub> Filename: pool/main/u/ubuntu-calendar-march/ubuntu-calendar-march_5.03_all.deb
<trukulo> jdub, can we have pics of mila jovovic on bakground by default?
<trukulo> it's a superb feature
<trukulo> lol
<trukulo> better if she is nude
<jdub> i think we'd have to pay her more htan the current models
<trukulo> fucking is included in price?
<jdub> now now
<trukulo> xD
* dholbach is glad he has some words written in invisible ink
<ogra> jdub: hmm, didnt get updated automatically here.....installing it now....
* ogra wonders when ubuntu-calendar was removed from is system......cant remember seeing it uninstalling...
<froud> who here other than mvo is working on update-manager?
<dholbach> froud: shall i tell him something from you?
<froud> no I am writing the docs and need a query chat
<dholbach> ah ok
<froud> dholbach: when does mvo normally come on
<dholbach> froud: it's weekend, so i dunno
<froud> OK, thanks
<dholbach> froud: maybe he drops in tonight
<dholbach> *shrug*
<abelli> froud: he was around this morning
<froud> what nick does Michiel go by
<dholbach> mitario
<froud> Hmm also not here
* froud thanks dholbach 
<dholbach> de rien :-)
<mg__> hi, does anyone here use an ibm t40?
<jdub> lamont: ping
<jdub> lamont: not that you should be around at this time :)
<abelli> jdub: ping
<abelli> jdub: i need to advertise canonical in some mails
<abelli> can you help me
<abelli> ?
<ogra> jamesh: ping....
<jdub> abelli: ?
<abelli> jdub: i need to speak about canonical, 
<abelli> can you give me an "how-things-work-here" lesson please?
<Keybuk> yay, we passed Mandrake on the 3-month list today
<dholbach> Keybuk: 3-month list? what's that?
<Keybuk> dholbach: www.distrowatch.com
<abelli> jdub: people here in italy are not well informed in differences between debian and ubuntu, what you are doing.. etc.
<abelli> jdub: so we want && we should, as Italian Community to clarify how things are, or at least try to.
* ogra is not really interested in whom we pass anymore, but in how many years will we stay on #1
<dholbach> Keybuk: we rock! :-)
<abelli> ogra: yrs?... weeks maybe
<abelli> ;)
<Keybuk> ogra: it'll be interesting when an Ubuntu derivative (such as Kubuntu) passes Ubuntu itself
<abelli> and why not days.. april is not far
<ogra> abelli: pessimist
<ogra> Keybuk: or guadalinux :)
<abelli> ogra, Keybuk: or maybe when ubuntu will pass ubuntu-+1
<ogra> do they distinguish between releases ?
<abelli> itll be a fight with itself
<Keybuk> no, just distributions
<Keybuk> so hoary will increase the popularity with any luck
<ogra> heh, so we'll keep #1 for a while....
<jdub> abelli: perhaps you should do a direct translation of the website and ask fabio to check it with jane.
<abelli> jdub: we are almost finished
<jdub> abelli: please get fabio to check it with jane.
<abelli> ok
<abelli> thank you
<jdub> abelli: you have to be very careful to not appear to be speaking for canonical.
<ogra> jdub: do you know anybody i could ask about a pygtk canvas prob ? there seem to be a lot of missing functions or i'm just to blind...
<jdub> ogra: jamesh, jdahlin, #pygtk on gimpnet...
<abelli> abelli: obviously.
<ogra> ah, gimpnet, thanks...i was looking around here
<abelli> jdub: yeah, it's clear.
<abelli> jdub: but as Italian LoCo I am supposed to inform, gently  make ppl respect the Code of Conduct, and so on right?
<jdub> sure
<abelli> ok
<abelli> thank you
<psy>  /me slaps copyright
* psy slaps copyright
<psy> :p
<psy> damn hard to come up with an original project-name
<psy> :P
<jdub> seb128: around?
<seb128> jdub: yep
<jdub> yo
<seb128> hey :)
<mg__> anybody use a t40 series laptop?
<abelli> jordi: sup
<jordi> hullo
<seb128> oh, lazy boy here
<seb128> jordi: evo 2.0.4 ? :)
<jordi> seb128: I'm waiting for Margarita's patches.
<jdub> hordi!
<seb128> ahah
<jordi> jdub jdub jdub 
<jordi> EVERYONE WATCH jdubTV
<jdub> ahr, it is not on atm
<jdub> but i want to turn it on
<jdub> to show my world domination map
<jordi> ooh
<zul> arrghhh...
<zul> fs/read_write.c: In function `vfs_read':
<zul> fs/read_write.c:234: error: `inode' undeclared (first use in this function)
<zul> fs/read_write.c:234: error: (Each undeclared identifier is reported only once
<zul> fs/read_write.c:234: error: for each function it appears in.)
<zul> fs/read_write.c: In function `vfs_write':
<zul> fs/read_write.c:280: error: `inode' undeclared (first use in this function)
<zul> sorry..
<zul> must spread the pain around
<daniels> sabdfl: it's a gnome/gtk thing -- jdub is on top of it (comes down to a freakish hack vs  correct-but-hard-and-waiting-for-upstrea-anyway type decision)
<seb128> daniels: about what ?
<jdub> yeah, what am i humping now?
<daniels> seb128: 09:51 < sabdfl> daniels: what determines the look of the pointer? specifically the please-wait-i'm-working one? it was much
<daniels>           nicer in warty, and i'd like that back!
<jdub> oh right
<jdub> hrm, not very hard, just pointless ;)
<Treenaks> pointer-less? :P
<jdub> if upstream don't pull their fingers out, i'll have to do it in ubuntu-artwor
<jdub> yo drbyte 
<abelli> is someone here having problems with spambot in #ubuntu?
<drbyte> hey jdub 
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<jdub> behind my head, you can see the World Domination Map
<jdub> :-)
<drbyte> haha. i should take a gander
<drbyte> traffic is almost free now... 2am time
<sabdfl> jdub: open with (in hoary)?
<jdub> totem, xine, mplayer...
<jdub> bit of nick cave for 02:00 :)
* ogra fires up totem
<jdub> http://www.kryogenix.org/days/2005/02/01/lugradioBastards
<jdub> haha
<ogra> grrr, why is there no equivalent to gnome_canvas_rich_text_get_buffer in pygtk.....
* ogra cries
<drbyte> i see the smile jdub 
<drbyte> and the eyeball
<sivang> anybody know if we have a precompiled nvidia support for kernel 2.6.11 ?
<sivang> seems missing from the archive
<ogra> sivang, we dont have a official 2.6.11 yet afaik this is a bittkeeper snapshot to play with....
<lamont> jdub: sup?
<jdub> lamont: nm, but thanks :)
<sivang> ogra: eh I see, oh well, I thought it would solve the very poor GFX redraw and X perforamnce I got here
<lamont> ok
<seb128> jdub: any objection to a glibmm/gtkmm update (GNOME bindings) ?
<mg__> anybody use a an ibm t4x?
<jdub> seb128: not at all
<seb128> cool
* ogra grr's at gnomecanvas
<dholbach> see you later
<zul> sivang; 2.6.11 is experimental just right now we have to clean it up a bit
<sivang> zul: ah ok
<sivang> zul: cool
<lamont> seb128: you're going to, um, howl at gnumeric...
<lamont> creating gdaif.la
<lamont> /bin/sed: can't read /usr/lib/libhowl.la: No such file or directory
<lamont> everywhere
<seb128> how nice
<lamont> yeah, isn't it, though. :-(
<seb128> I'll fix it
<sivang> seb128: there seems to be a light improvement with the redraw performance, any fixed to pango or gtk?
<seb128> no, you are the only one to have an issue here
<lamont> we need a libtool option that says 'no matter what, ignore _this_ library' :-)
<sivang> seb128: oh :-(
<sivang> seb128: well, it appears that it comes and goes. oh well.
* lamont takes the plunge and upgrades his desktop
<ogra> sivang: did you try the hibernate function ? if yes, and it failed, it might be that you are working without swap....which coul solw down your system a lot
<ogra> could slow down... even....
<sivang> ogra: already checked that, I have swap working 
<jdub> lamont: -Wl,--as-needed would help here massively :)
<lamont> jdub: would it be hiding a bug, or helping?
<jdub> lamont: it would mean packages far up the stack wouldn't be unnecessarily depending on stuff way down the stack
<jdub> lamont: so in this case, pre-emptively helping
<jdub> lamont: it would also help library transitions (cf. gnutls)
* lamont tests jdub's theory
<jdub> lamont: see my mail about it to u-d
<seb128> lamont: it would fix issues by not trying to build against not needed stuff
<jdub> meanwhile, bedtime for me
<seb128> 'night jdub 
<lamont> night jdub 
<zul> night jdub
* lamont wonders if jdub's mail got any followup on u-d
<lamont> ye
<Kamion> lamont: yo
<Kamion> you were looking for me?
<lamont> sup?
<lamont> well, if you're really bored, I have a small perl project for you...
<Kamion> ah, maybe Monday then
<lamont> yeah - no big deal either way
<Kamion> only here for a few hours, and allocated most of that to Debian :)
<lamont> np
<lamont> hrm.. updated gnome, X, kernel, etc... gues I should reboot, eh?
<lamont> from the 'decidedly evil crontab entries' department: 
<lamont> @reboot /sbin/ifconfig eth0 mtu 1496
<mdz> jdub: pong
* ogra curses the pygtk devolpers for forgetting half of the C functions
<seb128> you are rude here
* ogra is REALLY ANGRY
<seb128> half ?
<ogra> http://developer.gnome.org/doc/API/2.0/libgnomecanvas/GnomeCanvasRichText.html
<ogra> grrrr
<lamont> seb128: that means "at least 2 that he really wanted"
* sivang always knew GTK goes together with C :)
<seb128> lamont: yeah, seems so :p
<ogra> seb128:  want to use a transparent input field on a canvas.....but there is no function to get the data out of it, since they decided not to implement  gnome_canvas_rich_text_get_buffer
<sivang> ogra: btw, why do you need it to be transparent?
<ogra> seb128: i was trying to use get_property('text') or get_property('user-data') but these are empty.... so no way
<ogra> sivang: because it looks ugly otherwise
<Kamion> svenl: fixed your choose-mirror breakage now I think; thanks for the report
<Kamion> mdz: you were looking for me last night?
<mdz> Kamion: I don't remember why...probably something about a bug, or bugs in general
<mdz> last night I was reviewing high-severity bugs for Hoary
<svenl> Kamion: ok.
<Kamion> mdz: I noticed that from my inbox :-)
<ogra> seb128, even perl has this function: http://gtk2-perl.sourceforge.net/doc/pod/Gnome2/Canvas/RichText.html
<ogra> seb128, but anyway, sorry for being rude ...
<seb128> ogra: no pb
<seb128> ogra: feel free to switch to perl if you think that will help you :)
<ogra> seb128: hwdb-client is nearly done, i dont feel i will rewrite the whole ui :-P
<seb128> :)
<lamont> jdub: sounds like somthing to turn on in hoary+1 (--as-needed)
* lamont sees the time, runs away for about 45 minutes
<Kamion> so is there any half-decent speech recognition software in main/universe/whatever?
<Kamion> there's sphinx2, but I'm not entirely sure how to integrate it into general terminal use or what-have-you
<stackpopper> I was wondering are there any successful boots with array6 on imac g5's?
<Kamion> dunno about Array 6, though I'm pretty sure we've had successful installs with earlier milestone releases
<stackpopper> so the issue is fixed?
<stackpopper> Your next release is due in May right?
<stackpopper> I'd like to help resolve the issue before then
<Kamion> which issue?
<Kamion> release is mid-April
<stackpopper> well ubuntu not booting on imac g5's
<Kamion> you mean Ubuntu 4.10, or a Hoary test CD?
<stackpopper> both
<Kamion> there have certainly been kernel fixes since 4.10 which have been reported to fix problems on certain G5 models, but testing is always appreciated
<Kamion> since it seems to depend on the exact model
<stackpopper> :/
<stackpopper> k thanks
<mdz> Riddell: here?
<mdz> Riddell: I see you uploaded amarok, but didn't correct the dependency issue that I mailed kubuntu-devel about...did my message not get through?
<Riddell> mdz: yes it did, that upload was just a new version, I need to think about the dependency issues but that's after I solve the sudo issue which is today's challenge
<zenwhy> is it just me
<zenwhy> or is the array 6 installer broken
<mdz> neither
<zenwhy> it copied the packages to the disk
<zenwhy> and stopped
<mdz> zenwhy: for future reference, we test the Array images before releasing them, so it is safe to assume that it worked for us
<zenwhy> I had my mind set on doing this all week
<zenwhy> Well, it isnt working over here
<mdz> stopped with what on the screen?
<zenwhy> I mean, do i have a reason to lie about it
<zenwhy> the blue background with the grey line at the bottom
<mdz> check tty3 (control+alt+f3) and see if there is anything on the screen
<zenwhy> it just stopped after it copied the remaining packages to the disk
<mdz> if you are able to work at the command line, you can press control+alt+f2 and get a shell
<zenwhy> it stopped with reiserfs progs for some odd reason
<mdz> most problems like this are the result of bad media; I suggest burning a new copy at a lower speed
<zenwhy> oh
<zenwhy> fun
<mdz> Riddell: so you expect to have a sudo solution for preview?
<ogra> zenwhy: which speed did you use ?
<zenwhy> the speed my media is rated at
<zenwhy> which was 16x
<zenwhy> ill try again I suppose
<ogra> zenwhy: the suggestion is not faster then 8x but 4x is safe
<ogra> so better try 4x
<Riddell> mdz: yes, working on it now, stuck on why a user can kill su but not sudo
<opi> Riddell, maybe sudo starts with +s
<opi> Riddell, so it's not user process anymore
<Riddell> opi: sure, but so does su and you can kill that
<buga> opi: it's not a good reason, /bin/su is also a setuid binary
<mdz> ogra: are you (MOTU) reviewing the list of uninstallable packages in universe?  the last time I looked, there were several packages which just needed to be rebuilt (shared library transitions)
<mdz> Riddell: why do you need to kill it?
<Riddell> mdz: seems kdesu like to start su/sudo to see if it needs a password, then kill it then pop up the password dialogue if needed then start su/sudo for real
<tseng> mdz: we're most focused on the python transition
<ogra> mdz: its a while ago that i had a look there....(you mean the list Kamion generates ?)
<jani> mdz, you mean the -lX stuff?
<Riddell> also it does a kill -0 just to check that it's still alive before passing password
<ogra> jani: -lX is nearly solved .....
<mdz> ogra: if he generates one for universe, yes, that would be the one
<mdz> http://people.ubuntu.com/~cjwatson/testing/hoary_probs.html is only main
<Kamion> as I have said before, I merely mirror that list, I don't (any more) generate it
<Kamion> I set up the initial scripts for it, but they run on jackass and I don't have an account there
<Kamion> I think I set them up before universe existed :)
<ogra> Kamion: would it be possible to adjust it for universe ?
<mdz> ogra: see above
<mdz> sounds like it is elmo territory now
<Kamion> it is
<ogra> hmm, i see, so we'll have to wait until he gts back.....
<ogra> gets even
<mdz> he has been checking in periodically while he is away
<ogra> yup...i saw him several times
<Kamion> it should just be a matter of catting the Packages and Sources files for all the required components together
<mdz> wow, so many sites reprint stories from distrowatch
<robertj> speaking of which, Ubuntu passed Mandrake to obtain the top spot on the 3 month list sometime last night
<Riddell> mdz: examples?
<ogra> robertj: we will keep that the next years ;)
<zul> ogra: you optimist
<ogra> :-D
<zul> its lunch time already?
<robertj> really, Mandrake probably still outnumbers ubuntu users by quite a bit but they aren't the distrowatch visiting sort
<robertj> so I doubt it means much
<mdz> Riddell: tod-os.com, usalug.org, lots
<mdz> just from watching the access logs related to the kubuntu announcement
<mdz> many of them are reprints or direct translations of the distrowatch story
<robertj> is nautilus cd burning currently b0rk on hoary?
<mdz> no
<sivang> mdz: we have a reference for that ever here on the major linux portals :-) kubuntu has created much interest here
<Riddell> mdz: do you have any thoughts on handling publicity for kubuntu, like when we should get a website and announce proper?
<mdz> Riddell: sounds like something to raise at Tuesday's CC meeting
<opi> kubuntu.org is taken
<opi> kubuntulinux.org it's not
<zenlol> reburned the array six iso
<zenlol> im giving it another go
<Riddell> opi: kubuntu.org has been taken since someone at canonical said "oh god they really are going to call it kubuntu arn't they, we'd better buy that domain name"
<Riddell> mdz: good plan, /me adds to agenda
<opi> Riddell, ok :)
<Kamion> (the name Kubuntu was first suggested before we even went public, from what I remember)
<mdz> right, kubuntu.org isn't so much taken, as reserved for Kubuntu :-)
<mdz> Kamion: oxford
<Kamion> I thought Jeff mentioned it before that
<Kamion> but ok, that was before the preview anyhow
<opi> I prefer Ubuntu/KDE :-)
<opi> but Riddell and guys should pick it up
<robertj> Ubuntu/KDE sounds like one might reasonably expect it to release at the sime time as Ubuntu
<zenlol> I am glad kubuntu exits, so as to keep the regular ubuntu to one disk.
<mdz> enrico: is there a plan to fix the categorization in Yelp, to get the ubuntu-docs items to the front?
<zenlol> exists*
<Riddell> opi: I was overruled on the name
<robertj> I kinda had this delusion that the lack of a Kubuntu might force Debian to actually make a release :(
<jordi> meh
<jordi> no mvo here
<robertj> how often do yall end up doing slash & burn reinstalls?
<zenlol> i am doing one now
<zenlol> at least i hope i am
<Kamion> all the time, but I'm a special case ;)
<opi> robertj, I just killed Debian box to turn it into Ubuntu 
<Kamion> for my real systems as opposed to test ones, never
<zenlol> well
<robertj> I've resisted doing one on principle on my main desktop but things seem to get more and more broke, although they are better han they were
<zenlol> i guess i wont be installing array six
<opi> robertj, but if something is stable, it's just sits there
<robertj> My array stuff seems ok for the most part
<zenlol> it stops installing on my system after it copies the packages to the disk
<Kamion> zenlol: it's not *entirely* impossible that that's an archive-copier bug, but it seems unlikely
<zenlol> media should be ruled out at this point as i burned at 4x
<zenlol> and the iso was good
<Kamion> zenlol: 'ps x' on tty2; what's it going?
<Kamion> doing?
<zenlol> ps x?
<Kamion> type that
<zenlol> what information are you wanting
<Kamion> there should be a .postinst running somewhere
<zenlol> theres just a huge list of stuff there
<zenlol> theres a lot of stuff
<zenlol> but that isnt one of them
<Kamion> what're the last few lines?
<zenlol> we;;
<zenlol> ps aux | grep post shows it running
<zenlol> but nothing it happening at all
<zenlol> is*
<Kamion> just the last few lines of 'ps x' please
<Kamion> process names
<zenlol> im not on that computer
<zenlol> ill have to type it all out
<Kamion> the last three or four process names should not be hard work to type
<enrico> mdz: not from the docteam: we tried, but we didn't figure out much on how to do it
<Kamion> I don't care about the PID,Uid,VmSize,Stat columns
<zenlol> well then i dont have what you need because these arent process names. Ill just home i can fix it somehow on my own
<Kamion> eh?
<zenlol> i think its dying trying ti mount an ntfs drive
<zenlol> that i didnt tell it to mount
<Kamion> 'busybox ps x' on a real system shows me:
<Kamion>  7441 cjwatson   1360 S   pterm -fn -misc-fixed-medium-r-semicondensed--13-120-
<Kamion>  7442 cjwatson   2008 S   -bash
<Kamion>  7461 cjwatson    740 R   ps x
<Kamion> so like the bits from 'pterm' on
<Kamion> ok, the installer does go around mounting all filesystems it can find at some stages
<zenlol> it dies trying to mount an ntfs drive
<Kamion> you could put 'exit 0' on the second line of /bin/os-prober as a workaround
<Kamion> that sounds like a kernel issue then
<zenlol> oh
<zenlol> yeah thats what its doing
<zenlol> kernel issue?
<zenlol> thats odd
* lamont grumbles at dict-moby-thesaurus_1.0-5ubuntu1
<lamont> elmo?
<zenlol> my hardware couldnt be more standard
<zenlol> so i can kill the os prober
* lamont reboots - brb
<zenlol> and get past this?
<zenlol> what do i need to do to dso that. Ive never had an installation issue with ubuntu before this.
<Kamion> it seems unlikely that it is a hardware issue; I imagine there's a bug in the NTFS driver
<Kamion> nano /bin/os-prober
<Kamion> at some point after 'retrieving installer modules', e.g. while installing the base system
<Kamion> this will cause e.g. Windows not to appear in your grub configuration, but you can't have everything ...
<Kamion> I have never heard of an issue like this before though
<zenlol> oh
<zenlol> well i know for a fact that its not a hardware issue
<krix> hi
<zenlol> i suppose i will just wait then
<Kamion> wait for what?
<krix> hm. i don't know it is a right question on this chan :) but i installed ubuntu array6 on an amd64 system. I upgraded it and installed kernel-2.6.11-1
<zenlol> to use array 6. I dont have the luxury up updating.
<krix> now i want to install nvidia driver from nvidia.com and then i got compile errors.
<zenlol> My system is broken due to backports.
<Kamion> zenlol: please file a bug, component 'linux'
<zenlol> and I am on dialup.
<zenlol> This clean install was going to get me back on the right path. :/
<krix> and i got this error: http://paste.msunix.org/view.php?id=1912
<krix> please somebody look that
<krix> i don't know it is a bug in 2.6.11-1 package or a bug in me :)
<lamont> wow.  42 seconds from 'Starting ubuntu' to a prompt in gdm.
<Kamion> krix: looks like the nvidia guys need to update their module, to me
<krix> Kamion, hm i don't know, i installed this module at Fedora Core 3
<zul> 2.6.11.1 was like released yesterday so nvidia probably hasnt caught up
<krix> without those problems.
<krix> s/module/nvidia-driver/
<crimsun> RE: Nvidia: http://sh.nu/t/67mgw
<ogra> Kamion: i thought the 2.6.11 packjage was only a bitkeeper snapshot currently
<ogra> -j
<krix> no
<zul> there isnt a 2.6.11.1 package yet
<robertj> Do you guys think it would be worth the trouble to have an Ubuntu.ics that listed arrays, freeze dates, and releases?
<krix> zui: then what i installed ?
<krix> :)
<zenlol> ill install array 4 and upgrade to array six from the disk
<zul> did you install it throught apt?
<krix> ii  linux-image-2. 2.6.11-0.2     Linux kernel image for version 2.6.11 on AMD
<krix> ^^
<krix> yes
<zenlol> and use my own kernel configuration
<ogra> zul: there is one in universe afaik....
<zenlol> ill be sure to file a bug though
<Kamion> yeah, that's an unofficial package that we have for the purposes of experimentation
<krix> Filename: pool/universe/l/linux-source-2.6.11/linux-image-2.6.11-1-amd64-k8_2.6.11-0.2_amd64.deb
<Kamion> Hoary'll be releasing with 2.6.10, I believe
<krix> so it comes from universe
<ogra> zul: which fabbione built for playing with 
<zul> krix: its experimental and its based on a bitkeeper snapshot
<crimsun> krix: that's not 2.6.11.1
<krix> no? :)
<zul> and what crimsun said
<crimsun> krix: look at the build date via ,,uname -a''
<krix> krics@ubuntu:~$ uname -a
<krix> Linux ubuntu 2.6.11-1-amd64-k8 #1 Fri Feb 11 14:45:56 UTC 2005 x86_64 GNU/Linux
* ogra guesses mid feb
<krix> hm
<krix> that is intresting yep. on Feb11 there wasn't 2.6.11 released :)
<krix> so. then i will switch back to 2.6.10 :)
<krix> thanks for your time and sorry for false reporting.
<krix> now go to reboot. bye :)
<zul> i should fix that when i get a chance
<ogra> or suppress the package anyhow.....
<Riddell> mdz: what's the issue with libmad?  is it mp3 can go on the servers but not on the CD?
<zul> ogra: yeah
<ogra> there are may ppl upgrading to 2.6.11 if they see it i guess.....
<mdz> robertj: yes, a calendar would be great
<zenlol> i really cant understand why not having mp3 capability at install time is such an issue for some people. enabling universe will be easier than ever with hoary, and installing mp3 capable players and backends is simple.
<robertj> mdz: would that be too much of a burden to assign to someone who already had web access ;)
<mdz> robertj: web access?
<mdz> the release schedule is maintained in the wiki
<ogra> zenlol: google for mp3 license fee
<robertj> oh, so stick it on as an attachment?
<ogra> zenlol: and probably: price
<mdz> robertj: yes, that seems simplest
<zenlol> ogra
<zenlol> my statement was against including it
<ogra> zenlol: lol, sorry i missed "not having" in your sentence
<zenlol> all that would be gained from paying the mp3 licensing fees would be the placation of lazy users
<sivang> seb128: ping
* sivang wonders who can review and approve his patch for #2251
<zenlol> a "preview release" is coming soon correct?
<sivang> zenlol: yes
<zenlol> cool
<zenlol> I will upgrade to that from array 4 when it comes then
<zenlol> being on dialup and having to use my friends for my downloads is a hassle
<sivang> zenlol: where are you in?
<zenlol> \I plan to stay current and be active in the filing of bug reports in a couple months when I am no longer saddled with this horrible internet connection.
<zenlol> I am in kentucky, USA. Most of my state has availbale broadband but I am in a very rural earea. five miles to the east and west of me people have broadband.
<zenlol> I am part of the last mile effort.
<zenlol> lol
<sivang> zenlol: oh nice :)
<zenlol> area*
<zenwhen> greetings from hoary
* ogra misses his gtk-perl
<sivang> ogra: would you like to test a a binary pkg?
<sivang> ogra: (the g-c-m stuff)
<ogra> sivang: got amd64 for me ?
<ogra> oh, i have no printer around atm....sorry
<seb128> sivang: pong
<lamont> if ! killall -0 xsane && killall -0 ptal-mlcd; then
<lamont>         /etc/init.d/hpoj stop
<lamont>         /etc/init.d/hpoj start
<lamont> fi
<lamont> probably a bit too gross for 6771, eh?
<sivang> ogra: ah no :-( only source, but I will have seb upload it now and you can get it from the archive already :)
<sivang> seb128: done with #2251, can you upload/review?
<seb128> sivang: tomorrow, I'll go for dinner in a few min
<lamont> daniels: around?
<sivang> seb128: ok, thanks
<seb128> np
<zenwhen> o
<[m0rph] > which package contains the file "usr/X11R6/include/X11/extensions/scrnsaver.h"? (debian had it in xlibs-dev)
<Kamion> [m0rph] : http://higgs.djpig.de/ubuntu/www/
<Kamion> libxss-dev
<[m0rph] > Kamion: thx
<Loevborg> Kamion, are there plans to do an official version of that service?
<Ryaan> http://www.otomotivshow.com/
<Kamion> Loevborg: see the top News item on that page
<zul> there inotify finally building at last
<Loevborg> Kamion, thanks.
<tseng> zul: rock
<Keiven> http://www.tcpsecurity.com/
<zul> tseng: ill test it on my pc first and once im sure its not going to break anything ill put it up at the usualy place for you to test if you want
<tseng> ok
<tseng> im at the conference all
<tseng> day, i wont be mucking with my kernel
<zul> ok
<tseng> before my talk at least.
<tseng> heh
<zul> well its going to take a while for the thing to build
<sivang> ogra: you can get the source pkgs here: http://muse.19inch.net/~sivan/g-c-m/
<sivang> ogra: (as well as i386 bin ones)
<ogra> sivang: ok, i'll look at them if i solved my pygtk issue with hwdb.....
<sivang> ogra:  lemme know if it breaks anything :)
<ogra> yup
<sivang> but I'm away from now and probably for the weekedn
<sivang> laterz all
<ogra> sivang: i'll follow up to your bug if thats ok
<sivang> ogra: make sure cupsys is installed , becuase if it's not, nothing special will happen :)
<sivang> ogra: I'll see you later.
<ogra> sivang, yup (btw... cupsys is installed by default)
<Treenaks> something "special" ? :)
<ogra> Treenaks: ?? special ??
<Treenaks> oh nothing special
<Treenaks> wait
* Treenaks read that as "something psecial"
<Treenaks> special, too
<ogra> Treenaks: yeah, if cupsys is installed someting special will happen
<Treenaks> ogra: I just read it wrong.. 
<ogra> Treenaks: dunno what though (beside that it will show an additional checkbox) but probably sivang comes around and does your dishes or something ;)
<pitti> Hi
<zenwhen> wow
<zenwhen> my scroll wheel goes back and forward in firefox
<zenwhen> and the back and forward buttons scroll
<zenwhen> i may just go back to warty and stay there for a long time lol
<psy> hi
<pitti> mdz: here?
<pitti> Hi psy
<lamont> hrm... really need to make /home shared across multiple machines in the house...
<psy> lamont: samba?
<lamont> prolly
<Treenaks> ubuntu/win32 ? :P
<lamont> Treenaks: no winblows boxen  here
<lamont> although I've been instructed to install it on one machine
* psy gives lamont shfs :p
<lamont> damn windoze-only school software
<Treenaks> lamont: doesn't wine work?
<lamont> shfs?
<lamont> Treenaks: non trivial code
<Treenaks> lamont: ugh
<lamont> is ok.  the box will be dmz'ed to hell and gone, with nearly 0 internet connectivity
<psy> lamont: secure host file system.
<psy> does not work with windows, but hey :p
<Nafallo> cygwin+shfs?
<Nafallo> aha, kernel module...
<mdz> pitti: yes
<ogra> mdz: thanks for the followup :)
* psy is sharing his linux desktop of his laptop over vnc. and i have placed the wireless mouse and keyboard of my parents windows computer next to it :p (damn touchpad)
<lamont> psy: package name or what module?
<pitti> mdz: Hi! didn't catch you this morning, is there any news about langpack/ship?
<mdz> pitti: apart from what we agreed yesterday?
<pitti> mdz: yesterday we decided only about the live CD AFAIK
<psy> lamont: shfs-utils
<mdz> pitti: no, I said to go ahead with ship as well
<psy> or shfs-source, haven't installed it on ubuntu yet. :p
<pitti> mdz: oh, I thought we don't have enough space for all 10 packages, so that we need further discussion
<pitti> mdz: but I'm happy to seed them
<mdz> oh, we don't?
<mdz> I thought it was only 30M or so
<pitti> mdz: should fit even on the ppc, though
<pitti> yes
<mdz> there is enough space, then
<pitti> mdz: btw, when is germinate updated with the new seeds?
<mdz> pitti: daily, I think.  check with Kamion
<pitti> mdz: we threw lesstif1 out of the seeds over a week ago, but it's still in main
<mdz> pitti: that's probably due to sparc
<Kamion> 0 0 * * *               update-germinate
<pitti> ok, I'll ask him
<Kamion> that output is just informational, but I can make it happen more often if you like
<mdz> pitti: did you check whether it shows up in germinate?
<pitti> Kamion: hm, any idea why lesstif1 is still there?
<Kamion> pitti: look at rdepends/
<mdz> pitti: if it shows up in germinate, rdepends/ will tell why
<pitti> mdz: I checked p.u.c./~cjwatson/germinate-hoary-output (or so)
<Kamion> 2 * * * *               update-germinate
<mdz> pitti: if it isn't in germinate, it's probably sparc
<Kamion> there, should be a bit more useful
<pitti> mdz, Kamion: also, I checked with madision
<pitti>   lesstif1 | 1:0.93.94-11ubuntu2 |         hoary | amd64, i386, ia64, powerpc, sparc
<mdz> pitti: when you checked germinate-output/hoary, did you see lesstif1 or no?
<pitti> mdz: I saw it
<Kamion> it's not there for me
<mdz> http://people.ubuntu.com/~cjwatson/germinate-output/hoary/rdepends/lesstif1-1/
<Kamion> mdz: that's for lesstif2
<mdz> lesstif1 is in extra, so it should be able to move to universe fine
<pitti> hmm
<Kamion> they come from the same source package
<pitti> lesstif-dev                               | lesstif1-1                      | Generated by lesstif1-1
<mdz> Kamion: lesstif1 is built by lesstif1-1
<Kamion> pitti: I do not see that in all
<pitti> Kamion: yes, but I thought we can throw some binaries of a source package to universe?
<Kamion> pitti: don't bother looking in *extra
<Kamion> pitti: yes
<pitti> oh, I did
<mdz> http://people.ubuntu.com/~james/paste/sync.txt
<pitti> oh, indeed
<mdz> it's not james' list
<mdz> but that may be due to sparc
<pitti> Kamion: but why does madison lie?
<Kamion> pitti: it does not lie
<mdz> pitti: madison does not lie; it is in main
<Kamion> pitti: demotion to universe is manual, not automatic
<lamont> Kamion: muppomatic :-)
<mdz> pitti: I think we need for elmo to exclude sparc from his germinate runs until it is fixed
<mdz> there will be other packages like this
<pitti> mdz: it would be great to throw this out, lesstif1 is a PITA
<dd> www.otomotivshow.com
<ogra> gah, spambots
<zenwhen> everything works in hoary but my mouse wheel
<zenwhen> lol
<zenwhen> and theres no reason it shouldnt be because my xconfig is the same as I have used in every distro i have ever used
<zenwhen> and it worked in warty
<mdz> zenwhen: I suggest letting the system generate your X configuration rather than copying it; then your scroll wheel is likely to work
<pitti> Kamion: if I put some language-pack-foo stuff in Ship, do I need to remove them from Supported?
<Kamion> pitti: you don't have to, but I generally do; being in ship implies supported already
<mdz> yes, it's redundant to have them in both places
<pitti> Kamion: I know, but it might be easier to change
<pitti> okay, I remove it
<pitti> mdz: btw, l-support-en is already in ship
<mdz> pitti: yes, I realize
<mdz> likewise for live
<Kamion> mdz: ok to remove the installer question about whether you want to update from the network?
<Kamion> mdz: just always answering 'yes' works fine now due to the rearrangements for #6390, although if the network is not available then it leaves the network entries commented out
* lamont bbiab
<krix> hello again.
<ogra> pitti: do you want me to include a question about language settings in hwdb-client ?
<krix> in ubuntu array6 version at 2.6.10-4 version of kernel. It did not contains the SB Live 24! Bit driver. This driver is snd-card-ca0106 any support for this in the future updates of 2.6.10 kernels about this problem ? 
<krix> sorry if i'm speaking lame things or stupidity :) i'm new for ubuntu and new for this community too.
<Kamion> are NFS mounts with a Hoary client incredibly slow for anyone else?
<ogra> nope
<Kamion> maybe it's my server
<ogra> (hoary server and client)
<Kamion> pretty sure it used to be fine with a Warty client
<ogra> but i have set mount options like rsize and wsize to 8192
<ogra> maybe that affects the speed a bit
<krix> So anyone to  my soundcard support question? :)
<Kamion> krix: I don't see the string 'ca0106' anywhere in the kernel source we have
<krix> mhm
<krix> http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=Creative+Labs&card=Sound+Blaster+Live+24bit.&chip=SB0310%2C+P17&module=ca0106
<krix> i think this is in alsa-sources
<ogra> krix: isnt that a usb device ?
<krix> no
<krix> ogra, it is an integrated SB Live 24! bit soundcard. 
<krix> Which is stays at my MSi K8N SLI Platinum Motherboard :)
<krix> lspci identify him as SB Audigy LS
<krix> btw google and others things say that i need snd-ca0106 module for this card.
<krix> http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix
<krix> you can see on here.
<krix> ogra, Kamion : and the kernel package which is in universe tree (2.6.11-1) contains this module.
<Kamion> ok, presumably it got merged upstream; it's really too late for us to switch to a new upstream kernel for hoary though
<Kamion> krix: please file a bug, component 'linux', asking for that driver to be merged; I don't know if it will be merged, but if you don't file a bug, it probably won't. :-)
<krix> ah :)
<krix> hm i hope :)
<abelli> did smurfix show up today?
<zul> it just never ends
<abelli> zul: hu?
<zul> im just talking to myself kind of
<abelli> ahh.. ok
<abelli> ;)
<krix> Kamion, https://bugzilla.ubuntu.com/show_bug.cgi?id=7220 filled
<zul> krix: thanks
<krix> i hope isn't a bad bugreport :) I'm not a bugreporting expert :)
<krix> zul, i thanks :)
<Kamion> I did ask for component 'linux'
<krix> ooo
<krix> so i ask, what "component 'linux' " means? :)
<krix> the Package ??
<krix> I found only one place where i can specify linux :) And that was the OS :)
<krix> sorry, i'm not a bugzilla using expert
<krix> i can correct out if you say what to correct.
<ogra> krix: the package should be linux
<krix> oh. 
<krix> corrected out. Sorry for this.
<ogra> :)
<dd> www.otomotivshow.com
<Treenaks> again?
<krix> heh. 
<krix> now bye
<mdz> Kamion: absolutely
<Kamion> mdz: done
<mdz> great
<Kamion> mdz: I think I know why people are missing linux-restricted-modules a lot in install reports; it'll require a base-installer change, possibly best a merge of a new version from Debian
<Kamion> but I'm only here very briefly and need to go again, I'll look at it on Monday
<abelli> good night everyone
<zenwhen> is himem enabled in ubuntu smp kernels
<zenwhen> ?
<mdz> zenwhen: yes
<mdz> it's enabled in everything except the -386 flavour, I believe
<zenwhen> cool
<zenwhen> Ive decided to start using the official kernels, and stop mixing in non ubuntu packages
<zenwhen> my last install is thoroughly hosed
<zenwhen> lol
<zenrox> thank god for using a seprate partion for /home right
<zenwhen> yes
<zenwhen> but i hack so many things to my liking outside of home
<zenrox> make back up in the /home for that
<zenwhen> that I am still kind of bummed
<zenwhen> my poor beautiful install ;_;
<zenrox> so you just have to copy and paste
#ubuntu-devel 2005-03-17
* lamont wonders when x0rg will quit asking those damn questions
<lamont> dpkg: error processing /var/cache/apt/archives/gnome-icon-theme_2.9.92-0ubuntu1_all.deb (--unpack):
<lamont>  trying to overwrite `/usr/share/icons/hicolor/48x48/apps/gnome-run.png', which is also in package gnome-panel-data
<lamont> dpkg-deb: subprocess paste killed by signal (Broken pipe)
* lamont grumbles
<zul> there there....there there
<zul> ooh...braveheart and a bugs life is on tv tonight
<lamont> zul: which to watch.  which to watch.
<zul> both of course
<zul> the movies are one after the other
<lamont> ah, not simulcast, or you have DVR technology?
<lamont> ah, much better
<zul> nah...im too cheap
* lamont has TiVo technology - way cool
<zul> we cant get tivo in canada..we can go only get tivo like technology from either the cable company or the phone company
<lamont> feh
<GoneBoB> heh
<GoneBoB> that technology is in a massive not-giong-anywhere-omg-legal-ramifications debacle here
<mdke> i've tried #ubuntu, and they can't help me. is anyone willing to help me out for a few minutes? i can't log into gnome (hoary)
<AndyR> hi all
<AndyR> has anyone seen this on hoary? usb 1-1: device not accepting address 11, error -110
<lamont> seb128: you around?
<seb128> yep
<mdke> this sucks. I can't log into gnome because of weird permissions in my ~/. I can't change the permissions of my home directory, and when I create a new user it can't add a user to the home directory. 
<lamont> gnome-icon-theme replaces: gnome-panel-data? (/usr/share/icons/hicolor/48x48/apps/gnome-run.png)?
<seb128> lamont: just fixed it by an upload like 20s ago
<lamont> gnome-panel 2.9.3-0ubuntu1 was the old gnome-panel-data
<lamont> cool
<lamont> it would help if my daughter actually had RAM in her computer... :0)
<lamont> seb128: just wanted to make sure it wasn't sliding through the cracks.
<seb128> :)
<mdke> is anyone able to help me? perhaps this is a known issue?
<lamont> mdke: that's a #ubuntu question
<lamont> and without a bunch more info, no clue what you need to fix
<mdke> they have not been able to help me
<mdke> i tried :(
<mdke> i was wondering if this was a known issue in hoary atm
<seb128> is your partition mounted in ro ?
<seb128> no
<mdke> seb128, yes that appears to be the problem
<mdke> errors=remount-ro
<seb128> have you tried to reboot the box ?
<mdke> seb128, yeah :(
<zenwhen> i am trying to upgrade from array 4 to array 6
<zenwhen> i get this error
<seb128> (g-i-t/panel ?)
<mdke> ?
<seb128> mdke: what ?
<mdke> seb128, i wondered if what you said was aimed at me and i didn't understand it
<seb128> nop
<zenwhen> unable ot overwrite /usr/share/icons/hicolor/48x48/apps/gnome-run, which is also in package gnome-pnael-data
<seb128> speaking about this msg :p
<seb128> gnome-icon-theme/gnome-panel conflict
<zenwhen> What should I do
<seb128> zenwhen: sudo apt-get -f install
<lamont> zenwhen: or install gnome-panel until it makes it, and then dist-upgrade again...
<lamont> seb128: how much of the libhowl elimination was you spacing out the uploads to let things build before their build-depending packages built?
<seb128> time to get them available by apt on archive.u.c on my box
<seb128> why ?
<lamont> seb128: because sparc and hppa may have some challenges, then, I expect...
<lamont> not a big deal, more just curious
<seb128> k
<seb128> BTW I need to fix gnomedb for gnumeric
<seb128> will do tomorrow
<lamont> that is, if timing was part of it, then that explains those issues...
<lamont> (hppa currently has a libgnomeui build that fails because howl isn't there...
<seb128> yeah, just keep kicking build to sort that :p
<lamont> there's nothing under it that I can see that needs it - gonna have to actually debug it I fear. :-)
<seb128> I wonder if updating the Build-Depends is a better solution
<zenwhen> ok
<zenwhen> I am running array six now
<seb128> based on the update speed I've picked that option
<seb128> I don't like to change the Build-Depends that much for this reason
<lamont> yeah - not a big issues
<zenwhen> does grub seem a lot slower to anyone else?
<lamont> seb128: my mirror is also generally struggling to keep up, so that could be it too...
<seb128> lamont: libgnomeui needs libgnome (2.9.1-0ubuntu2), libbonoboui (2.8.1-1ubuntu1)
<lamont> Unpacking libgnome2-dev (from .../libgnome2-dev_2.9.2-0ubuntu1_hppa.deb) ...
<lamont> Unpacking libbonoboui2-dev (from .../libbonoboui2-dev_2.8.1-1ubuntu1_hppa.deb)
<lamont> libtool: link: `/usr/lib/libhowl.la' is not a valid libtool archive
<lamont> hence my grumbling to myself
<seb128> grep howl /usr/lib/*.la ?
<lamont> yeah - installing build-deps now
<zenwhen> new linux users are going to be 500% more impressed with hoary than they were with warty
<zul> thanks
<lamont> grep -l libhowl /usr/lib/*
<lamont> /usr/lib/libbonoboui-2.la
<zenwhen> so much has happened between array 4 and array 6
<zenwhen> little things
<lamont> seb128: which is to say that libbonoboui got built too soon...
* lamont brutalizes it
<zenwhen> is gnome enu editing going to be fixed soon?
<zenwhen> menu*
<seb128> not sure, we'll probably put a menu editor in universe for hoary
<jdub> in gnome itself, it definitely won't be fixed for hoary
<thierry> hi, I'd like to try to fix ubuntu bug 4724 but I don't know where to take the source... can anyone tell me?
<seb128> apt-get source mozilla-firefox ?
<thierry> seb128, and where will this go?
<seb128> in your current directory
<thierry> ok thanks
<seb128> np
<srbaker> anyone install from today's image?
<sabdfl> night all
<lamont> seb128: fwiw, glibm2.4, gst-plugins0.8, and gtkmm2.4 all have non-PIC in shared libaries now...
<seb128> lamont: ftbfs ?
<lamont> checking that now - I believe amd64 will bitch
<lamont> interesting.
<seb128> how have you noticed that ?
<lamont> hppa
<seb128> that surprising
<lamont> which is also doing -Wl,--as-needed... /me turns that back off
<srbaker> what partition tools exist that let me resize existing partitions.  anyone?
<lamont> seb128: forget I said anything about those 3
<seb128> that's due to -Wl,--as-needed ?
<lamont> dunno yet, but there aren't failures for amd64 or ia64, and I know ia64 would bitch
<seb128> k
<lamont> config changed, given back, we'll see how they do.  But I need to take a youngster shopping
<daniels> lamont: sup?
<zenwhen> should gnome "feel" slower now than it did in array 4?
<lamont> daniels: either I was bitching about xorg asking config questions over and over, or was going to comment on the PSC1315 issue
<seb128> no
<zenwhen> well everything is drawing a bit slower. firefox scrolls choppier.
<zenwhen> stuff like that
<daniels> lamont: heh :)
<seb128> jdub: do you know what component handles the dynamic menu shortcuts ? gtk ?
<jdub> yeah
<lamont> daniels: I found a gross hack that will let my wife use her psc1315, you see..
<seb128> jdub: is that supposed to be kept ?
<lamont> comment in the bug
<seb128> jdub: ie, if you restart the app
<jdub> seb128: hrm...
<seb128> (because it doesn't)
<jdub> seb128: and now there's a public preference for it... ;)
<jdub> seb128: maybe ask one of the gtk dudes, i don't know if it's supposed since 1.x
<seb128> k, thanks
<daniels> lamont: oh?
<lamont> yeah... anytime xane isn't running, and ptal-mlcd is, you stop/start hpoj.  do that in a cronjob every 10 minutes and you get printing again.. :)
<seb128> if anybody wants to debug the gossip ftbfs he's welcome
<zenwhen> My rendering slowness went away by disabling nvidia's renderaccell. 
<seb128> gossip has not changed dunno why it doesn't like XScreenSaver
<zenwhen> perhaps the new packages dont play well with it
<lamont> the strange thing is that it claims to find it, and in the next line claims that it couldn't.
<seb128> yeah
<lamont> lets blame autocrap?
<seb128> seems to be an autofoo issue
<seb128> yep
<lamont> Installing new version of config file /etc/init.d/cupsys ...
<lamont> Hmm, cupsys won't stop... I wait 5 seconds...
<lamont> Retrying to stop...
<lamont>  * Starting Common Unix Printing System: cupsd                           [ ok ] 
* lamont screams
<lamont> otoh, it did actually stop
<lamont> just not quickly enough
<seb128> do we care about 386 support ?
<elmo> no
<elmo> our gcc compiles 486 code
<seb128> k, thanks, what I was thinking
<lamont> wow. -Wl,--as-needed b0rkage. bad jdub
* lamont goes shopping
<jdub> ooh, you found breakage?
<lamont> yeah.  glibmm2.4 is ftbfs (non-PIC in shared lib) with that, builds fine without
<lamont> ditto two others, see above
<lamont> well, I expect..
<jdub> nice!
<lamont> happy to send you both logs, if you want them.  admittedly, they're from hppa.... :)
<jdub> haha
<daniels> lamont: blegh
<daniels> zenwhen: yeah, my current thinking is that render is broken
<lamont> daniels: I _SAID_ it was a gross hack...
<daniels> i just don't know HOW
<seb128> and jdub was trying to push the pkg-gnome guys to use that now
<seb128> bad jdub :)
<jdub> i was trying to convince them not to :)
<jdub> "don't do it by default"
<jdub> ^ very important point :)
<seb128> ah ah
<jdub> one mention and suddenly they're all talking about "fixing" cdbs to use it
<jdub> finding breakage is good though
<lamont> seb128: for that matter, debian's gcc compiles 486 code
<seb128> if that's how we fix bug I'm curious to know how we break stuff :p
<seb128> lamont: k
<jdub> crazy debian kids :)
<lamont> back in a while
<jbailey> jdub: I already said for it in general.  Offered it to sb for the Gnome module and he said no.  Open and closed, nice and easy...
<jbailey> already said no, that is.
<jdub> yeah, this was about discussion before that
<elmo> lamont: no it doesn't; it's libstdc++ uses a 486 locking instruction - it doesn't force 486 for everything tho, like we do
<elmo> </pedant>
<seb128> is somebody using an http proxy and evolution webcal stuff ?
<daniels> seb128: you're just an apt-get install squid away from having it yourself ;)
<seb128> yeah, but I'm lazy :p
<seb128> daniels: BTW what's the standard way to know that xorg crashed ?
<seb128> daniels: #7183, the guy has bugged on gdm but I guess that's an xorg crash
<daniels> seb128: segfaults are typically recorded in Xorg.0.log
<daniels> seb128: if it went down really, really, really hard, gdm will usually record it
<seb128> daniels: k, I'll ask if he has something in the gdm logs
<sivang> seb128: awake so late?
<seb128> no, I'm sleeping
<sivang> seb128: hehe , so you're IRCing in your sleep then :)
<seb128> some people talk while they sleep, I reply to bugzilla bugs for my part
<daniels> seb128: already asked
<sivang> seb128: lol, well, if you like uploading packages as well let me know :)
<seb128> daniels: thanks
<seb128> sivang: nop, just doing some bug cleanup, I keep the real work for tomorrow :)
<sivang> seb128: ok my freind, well, laterz then - I will also head for bed :)
<ogra> hmm, esc should be disabled in pw dialog....tsts
<seb128> ogra: it should not be counted as a char for the password :)
<ogra> hmm, but then we also should disable every non PW char .....
<ogra> F keys.... special chars
<seb128> right
<seb128> but some people hit esc to clear something
<ogra> i know...but thats the default behavior of this pw dialog, i didnt touch anything in this area....
<seb128> gksudo does that fine
<seb128> grab the code
<seb128> jdub: you don't use an http proxy by any chance ? :p
<jdub> i do
<ogra> i'll have to write a patch anyway for the finetuning before release... i'll look at it...
<jdub> being on the other end of two tin cans and a piece of string from you
<seb128> ah ah ah
<seb128> jdub: adding a webcal:// in the calendar works fine with a proxy ?
* ogra slaps the string...
<jdub> one sec
<seb128> jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=7212 ... in fact evolution and eds just crash if you set a proxy without having one
<seb128> but dunno if you have one :)
<jdub> well, evo just dies in the arse on startup atm
<seb128> utch
* jdub pulls tb
<seb128> how nice, they have just changed the context menu in 2.1.6 this week
<seb128> and they have dropped the "mark as read/..." options
<jdub> http://rafb.net/paste/results/WCWThy30.html
<seb128> with a working proxy ?
<seb128> nice, I get the same with the IP of a non-proxy box as proxy
<jdub> this is on startup
<seb128> thanks
<jdub> eds crashes, then evo crashes
<jdub> i have webcal stuff
<jdub> and it's opening the calendar at startup
<seb128> and if you don't use a proxy ?
<seb128> I guess that fixes the issue
<jdub> heh
<jdub> suck :)
<jdub> no crash
<seb128> yep, that's it
<seb128> thanks :)
<jdub> oh
<jdub> found another nice calendar bug
<jdub> if you assign a colour to Personal, a new calendar is created
<jdub> restart, and you have two Personal calendars
<jdub> the real one still doesn't have a colour ;)
<seb128> I don't get this one
<seb128> my default calendar has a color
<seb128> and I can change it
<ogra> works fine here
<seb128> proxy or color ?
<ogra> color
<srbaker> anyone here know if i can get the extended life battery for the X20 ?
<srbaker> or is it only the X40?
<Benoni> Where would I find the Kerberos 5 command line tools (e.g. "kinit") for Ubuntu Hoary?
<Benoni> Question withdrawn: #ubuntu folks pointed me at the "universe" repository.
<wasabi> http://www.martianrock.com/
<thierry> I'd like to fix ubuntu bug 3176 but I don't know where to make the changes in the firefox source... any ideas?
<pvh> I recently updated Hoary and I noticed there was some gui integration of power management mentioned in a config file, but I have not seen any evidence of it in Ubuntu itself.
<wasabi> i just upgraded and noticed my laptop has a suspect feature in the logoff screen
<wasabi> scared to try it. ;)
* wasabi gives it a go!
<pvh> wasabi: Bye!
<wasabi> wow, it went to sleep,
<wasabi> <---- over there
<pvh> wasabi: Hmm. I wonder why mine didn't show up.
<wasabi> but that's nothing new
<wasabi> the real question is can it wake up
<pvh> wasabi: Did you sleep or hibernate?
<wasabi> suspend.
<wasabi> no idea
<pvh> I can suspend as long as my wireless card isn't in the machine.
<wasabi> it's not waking up. it looks turned off now.
<wasabi> but the power button doesn't work
<pvh> Huh.
<wasabi> naw, caps lock light works.
<pvh> Oh!
<wasabi> it's just not waking up
<pvh> Move your mouse?
<wasabi> not even responding to pings
<pvh> Did it suspend fully?
<wasabi> yeah. it did.
<wasabi> then I tried to wake it
<wasabi> It hasn't been able to wake up since I used some guys custom kernel a year ago
<pvh> What kind of laptop?
<wasabi> iBook2
<pvh> Ah, beyond my ken.
<jdub> pvh: log out dialogue
<lamont> elmo: see the changelog for gcc-3.3_1:3.3.2ds0-0pre0:
<lamont>   * Change ix86 default CPU type for code generation:
<lamont>     - i386-linux       -> i486-linux
<lamont> </pedant>
<pvh> jdub: Yes, it's not in there.
<jdub> pvh: you probably haven't restarted gnome-session since upgrading
<lamont> elmo: 12 Aug 2003
<pvh> jdub: I have, many times. :)
<jdub> check /etc/default/acpi-support settings
<pvh> jdub: Okay, any specific file?
<jdub> that's pretty specific already
<pvh> Er, sorry, any specific setting .:)
<jdub> delve, discover, experiment
<jdub> check the patch
<jdub> etc.
<pvh> jdub: I'm quite familiar with the laptop settings.
<pvh> jdub: I've been using the command-line to do everything for a couple months now.
<pvh> jdub: I was hoping you would be referring to some line in acpi-support which I didn't have.
<pvh> jdub: "like ENABLE_LOGOUT_MENU or such"
<pvh> alas.
<lamont> cdrecord: Warning: Running on Linux-2.6.10-3-k7
<lamont> cdrecord: There are unsettled issues with Linux-2.5 and newer.
<lamont> cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
<lamont> WTH?
* lamont sleeps
<Amaranth> jdub: What's up with #twisted? :)
<sivang> morning
<crimsun> morning :-)
<sivang> hey crimsun 
<crimsun> 'lo sivang 
<sivang> crimsun: what's up? working on kubuntu?
<crimsun> actually extracting some patches from beep-media-player's release_0_9_7_1 branch
<crimsun> yourself?
<sivang> crimsun: just woke up, after about 3 hours of sleep, couldn't continue sleeping though :)
<sivang> crimsun: oh goody, I will test them, I wanted to get beep since I first saw it over a freind's house 2 days ago :)
<crimsun> sivang: sunlight too bright? ;-)
<sivang> crimsun: hehe, not even that. you know, it happens sometime, doubts, thoughts, fears for the future - they can sometime keep you up :)
<crimsun> sivang: true :-)
<sid77> hi
<crimsun> 'lo
<sid77> >_<
<sivang> hey dilinger 
<sivang> oops
<sivang> hey sid77 
<sid77> yup
<Kamion> jdub: for future reference, the answer to pvh's PM question was that he needs to set RESUME= in /etc/mkinitrd/mkinitrd.conf and regenerate the initrd
<tp__> anybody know any wireless dropping not able to reconnect problems with hoary (ibm t42, new install)
<GheRivero> res people
<tp__> is daniels there
<sabdfl> tp__: do you have netapplet installed?
<sabdfl> hey rubenv
<tp__> doesn't look like it
<sivang> hey sabdfl 
<sabdfl> sivang!
<tp__> sabdfl: just rebooting the laptop so I can get my network back. :-)
<sivang> sabdfl: Yes Mark, Did I do anything wrong? :-)
<sivang> sabdfl: finished burning daily live, will give it a couple of runs now :)
<rubenv> sabdfl: goodmorning
<sabdfl> not afaik, except maybe forgetting to enjoy the sunshine on a sunday. i'm in london, there is no sunshine, that's my excuse
<sabdfl> rubenv: i've been hacking on the bounty tracker this weekend
<tp__> sabdfl: sunny in leeds here but inside working :-(
<rubenv> sabdfl: is it running on the dogfood thing?
<sabdfl> now allows for subscriptions to bounties, so people can keep up to date with a bounty
<rubenv> sabdfl: i've been thinking about interface details, perhaps I should write em down
<sabdfl> also, beginnings of ability to link a bounty to projects, products or distros
<sabdfl> subscriptions don't actually do anything, but in future will have email notifications
<rubenv> sabdfl: excellent, tracking is what makes bugzilla kick arse, it's definitely something needed in bounties
<sivang> sabdfl: oh well, not that sunny here currently, it's getting couldy, the short term summer we've had is ending as it seems :)
<tp__> sabdfl: yes I do have netapplet installed
<rubenv> it's sunny here, but the pool is still frozen, i'd rather not go outside now ;-)
<sabdfl> tp__: it's crackful, remove it from your panel
<tp__> ok cheers!!
<sivang> rubenv: you in .au right?
<sabdfl> see if that helps
<rubenv> sivang: .be
<tp__> sabdfl: I'll send some of my sunshine down if it works ;-)
<sivang> rubenv: oh, EU right?
<sivang> seb128: Bon Jour :)
<rubenv> wish i was in .au, then i could go to ubuntu down under (well, if university stops bugging me :))
<rubenv> sivang: belgium, a neighbour country of germany :-)
<seb128> afternoon
<sivang> rubenv: I just wasn't sure about .be being belguim, but I know where it is :)
<rubenv> sabdfl: I really wish I had the time to poke around with zope, stupid university
<rubenv> well, not stupid, important but annoying :-)
<sivang> sabdfl: is the bounties tracker already available from the launchpad domain?
<rubenv> sabdfl: we'll also need to find a way to insert mockups etc, like gnome does, I really like those
<rubenv> sabdfl: starting to look very neat
* rubenv out to study
<sivang> seb128: http://muse.19inch.net/~sivan/g-c-m/ :-)
<sivang> sabdfl: are we going to support KDE in rosetta also? (thinking of launchpad integration into the desktop implications)
<opi> I think Rosetta is needed also for KDE
<daniels> sivang: i believe so, yes
<daniels> given it's in main and all ;)
<Riddell> what's the advantage of rosetta?  KDE is already translated into oodles of langauges?
<opi> Riddell, some projects aren't :)
<opi> Riddell, it won't hurt to have something for a quick help
<opi> Riddell, and this translation will be commited upstream, so project authors will be happy :-)
<daniels> Riddell: mainly just having a central co-ordination prospect.  even assuming the world is kde, it means you don't need an account for kde, all of the external kde apps, d-bus, gstreamer, etc, etc.
<tp__> daniels: do you mind if I ask about your x40 package. Have people provided feedback on whether it works for t42?
<daniels> tp__: sure -- dunno, should just work out of the box without my packages
<tp__> tp__: thanks.. it's the suspend to disk I'm looking at.. I'll play some more to see where I can get :-)
<tp__> daniels: ermm.. :-)
<daniels> dunno about StD, to be honest
<daniels> never used it
<tp__> daniels: do you just power off? or suspend to ram?
<daniels> tp__: str has always worked fine for me
<tp__> daniels: thanks again
<sivang> daniels: that's what I feard :) oh well, hard work is good for you.
<psy__> hi carlos 
<carlos> hi
* jdub boggles at #7229
<abelli> could someone explain me differences between abiword, abiword-common, abiword-gnome?
<jdub> abiword-common is used by both
<jdub> abiword-gnome is built against gnome libs
<abelli> mmm... ahh right so the difference is in the "GTK2", and "GTK2/GNOME2"
<abelli> jdub: thank you
<abelli> ;)
<zul> jdub: ping
<zenwhen> sup
<zul> not much you?
<zenwhen> Guys, I am pretty sure that pango is slow as crap in hoary right now. I can't be dreaming this.
<zenwhen> My system feels like its a 300Mhz celeron with 128MB of ram when i switch tabs in firefox or xchat.
<zenwhen> Rendering is slow as crap.
<zenwhen> Thats whats up wiht me. :P
<nasdaq> 300mhz celeron
<zenwhen> with*
<nasdaq> those were good days
<zenwhen> my fingers are dyslexic
<zenwhen> lol
<zenwhen> not when you are really running a 3Ghz P4
<nasdaq> i was 10 years younger
<zenwhen> :(
<zul> oh yeah...inotify 0.20 is working on my system if anyone is keeping out with it
<seb128> there is a kernel with it in the archive ?
<zul> not yet
<zul> im still testing it i can make it available if you want
<seb128> not now, but thanks
<zul> ok ill wait for tseng then
<zul> it hasnt crashed on me yet though
<jlj> anyone with a US credit card feel like testing pymusique? http://fuware.nanocrew.net/pymusique/
<nasdaq> HEHE
<tseng> hi zul 
<zul> inotify 0.20 is ready for you to test
<tseng> i see, thank you
<tseng> have you tried mounting/unmounting usb drives?
<zul> yeah no problems for me no oopses or anything
<thierry> hi, I'd like to fix ubuntu bug 3176 but I can't find where to fix it in the firefox source... anyone can help me?
<tseng> zul: i cant automount my ipod
<zul> crap. whats wrong?
<tseng> dunno yet
<tseng> ill look for it in hal
<tseng> actually hal-device-manager looks to be missing most things
<zul> you did inotify at boot?
<tseng> restarting hal fixed, maybe not related
<tseng> yeah.
<zul> and you got the following inotify device minor=63?
<tseng> I can unmount and eject w/ no oops
<tseng> yes
<zul> ok
<tseng> could just be a random hal thing
<zul> good
<zul> and gamin should be working like it usually does
<tseng> almost
<tseng> inotify backend still has the /media polling issue
<zul> almost?
<zul> ah
<zul> ill be around later though
<tseng> bye.
<zul> have to go do errands
<thierry> hi, I'd like to fix ubuntu bug 3176 but I can't find where to fix it in the firefox source... anyone can help me?
<zenwhen> 7MB faq :/ 
<zenwhen> this is going to make upgrading hoary a pain
<zenwhen> on dialup
<psy__> thierry: where are the bug-reports?
<psy__> nm, found it
<Q-FUNK> hi!  where does this meeting take place? http://www.ubuntulinux.org/wiki/CommunityCouncilAgenda
<ogra> Q-FUNK: in #ubuntu-meeting
<ogra> but the agenda is totally outdated.....thets the one from the last meeting
<Q-FUNK> orgo, thanks
<ogra> s/thets/thats
<Q-FUNK> well... I just added myself to the agenda.
<ogra> MartinEricRacine ?
<Q-FUNK> ogra: I'll let you update the agenda then.  :)
<Q-FUNK> yup
<ogra> its a mako job....i'll tell him that your entry should stay
<Q-FUNK> ogra: ok, thanks :)
<Q-FUNK> is the march 8th date and time still good, though?
<ogra> yup
<Q-FUNK> good.
<ogra> Q-FUNK: btw, are you going for MOTU ?
<Q-FUNK> ogra: I'll be happy enough just maintaining my existing Debian packages and uploading them directly to Ubuntu also.
<Q-FUNK> ogra: but sure, why not. ;)
<ogra> Q-FUNK: so feel invited to #ubuntu-motu then ;)
<pitti> Hi
<abelli> pitti: bon hour
<abelli> ..bon jour
<ogra> hi pitti
<pitti> Hi abelli, hi ogra
* pitti just returned from skiing
<pitti> heaps and heaps of snow here :-)
* abelli is not able to
<ogra> yup, here too
<pitti> abelli: you should learn it, it's fun
<abelli> the same here. and i'm hill
<pitti> and exercise
* ogra watches the news with tons of crash reports
<_d4vid> hi all
<abelli> pitti: i like sleds
<pitti> abelli: ill? that's bad
<abelli> pitti: mmm yeah.. a real saturday night fever
<abelli> :(
<jordi> w
<seb128> pitti: here ?
<pitti> seb128: yes, hi Seb
<seb128> hey
<seb128> could you please update the language-pack ?
<pitti> which one?
<pitti> all?
<seb128> yeah
<seb128> that's a shame, we have the current GNOME bug with outdated translation
<pitti> actually I wanted to update them at Tuesday
<seb128> that bother people who want to make that good for 2.10
<pitti> but I can do it earlier if necessary
<seb128> or screenshots for 2.10
<seb128> now please
<pitti> seb128: however, the langpacks are still imperfect
<seb128> it that some real work or just a batch tor run ?
<pitti> seb128: without Rosetta, I miss lots of translations
<seb128> pitti: yeah, but I get complain from GNOME translators
<seb128> pitti: the upstream level is good and we fuck it up 
<pitti> seb128: did you upload the new packages?
<seb128> what new package ?
<seb128> I've updated GNOME stuff all the week
<jordi> seb128: how many ubuntu specific strings are there in Hoary?
<jordi> where can I find them to translate them in a little while?
<seb128> jordi: really few
<seb128> jordi: s/Computer/System for the panel :p
<pitti> seb128: okay, I kick langpack-o-matic
<seb128> pitti: thanks
<pitti> carlos: any ETA for Rosetta?
<pitti> seb128: basically I just ignore all packages which have two or more domains
<jordi> poor carlos and daf
<pitti> seb128: i. e. gtk etc.
<seb128> pitti: so we don't have translations for this ?
<dholbach> hai
<jordi> seb128: how can I know if Catalan is up to date with that string?
<pitti> seb128: no, my current hackish scripts don't support multiple domains
<jordi> seb128: and if it isn't, it's "Sistema" :)
<carlos> pitti: working on it
<seb128> jordi: dunno, talk with Rosetta guy, we are supposed to have some integration with the distro :p
<seb128> pitti: arrrg
<jordi> heh
<carlos> pitti: daf comes back to Valencia with me to finish it
<pitti> seb128: gosh, and we recently modified the output format
<pitti> seb128: so I first have to hack on my scripts before I can trigger the update
<pitti> and before that I need to fix pkgstriptranslations
<seb128> k
<pitti> brrrr
<seb128> utch
<Goshawk> please say to me if this is off topic: Something that we can call "usermode splash" (or maybe usplash) have been relased at 0.1 alpha, i need some testers, is there somebody that want to try it?
<jordi> seb128: ok so he's telling me I'm supposed to download the ubuntu gnome-panel source and submit a patch
<jordi> ugh.
<seb128> jordi: no really
<seb128> not really even
<seb128> jordi: see with carlos/rosetta guys/pitti how the translations are managed for the language-packs
<carlos> seb128: until we finish Rosetta changes, he needs to do that
<jordi> seb128: see? :)
<carlos> seb128: if he cannot wait
<seb128> I can't handle updating translations for every single GNOME package
<seb128> I'm already busy without that
<jordi> nothing like chatting with someone 3 metres away from you :)
<seb128> ah ah
<kent> Goshawk, i can test it. I run Hoary. (Is it the usplash mentioned on ubuntu's wiki?
<jordi> seb128: d'oh I^Wwe thought you were superseb.
<Goshawk> kent, it started in collaboratio with Paul SLaden (Usplash project manager)
<Goshawk> kent, but it works a bit different
<seb128> jordi: update evo to 2.0.4 and I'll consider updating the ca.po :p
<Goshawk> kent, more quick and easy
<Goshawk> kent, since it is all in one porgram
<Goshawk> kent, no, usrquit, usplat and so on
<Goshawk> kent, just one executable: "/sbin/usplash" 
<jordi> seb128: grumble. hrm.
<Goshawk> kent, http://81.113.230.186/kalatlug/phpwiki/index.php/UsplashHowDoesItWork
* jordi starts a gal build.
<kent> Goshawk, will read that page soon.
<Goshawk> kent, in that page there is also the link
<jordi> seb128 is silly an annoying. I just want you guys to know. :)
<Goshawk> for the deb download
* seb128 slaps jordi 
<jordi> luckily sabdfl didn't read what I just said.
<kent> Goshawk, will installing that deb package configure it, or is there some files to read in that archive?
<Goshawk> kent, no
<Goshawk> kent, all is done by postinst script
<Goshawk> you have to do
<sabdfl> tut tut. trading favours.
<jordi> heh
<Goshawk> dpkg -i usplash..... and reebot
<Goshawk> kent, you can download the sources from svn 
<Goshawk> kent, all the specifications are in that page
<kent> Goshawk, Downloading it now.  Give me a few minutes and you will get a report on how it worked :)
<Goshawk> thanks
<Goshawk> kent, it works at 100% on my pc, but it is the same pc wher it is developed
<kent> Goshawk, so I have installed it now. (Do mind i run Hoary, i dont know if that will be a problem..).  Im rebooting now to check it. By  by :)
<Goshawk> i hope it will work fine
<Goshawk> yes???
* froud leaving message for mvo and mitario. Please contact me when you come on I need to release Update Manager Manual V0.0.1 to you.
<Goshawk> kent, yes or not?
<kent> Goshawk, error 23: error while parsing number.
<Goshawk> when?? after swithced to tty8?
<Mithrandir> jdub: flumotion doesn't work properly on amd64! :(
<kent> Goshawk, I get that errror right after grub has loaded.
<Goshawk> uhm... it seems a postinst problem
<Goshawk> kent, just one thing, can you mail me your /boot/grub/menu.lst?
<Riddell> jdub: any idea what the typeface used in the ubuntu logo is?
<Goshawk> vincenzo.ampolo--at--gmail.com
<kent> Goshawk, yes, wait a second. I booted with the rescue-kernel so i have no X at the moment. Il mail you as soon as  I can :)
<Goshawk> ok... thanks again... but is the frmebuffer active?
<kent> Goshawk, if you meen if the framebuffer is active when i get that message, No.. i dont think so, though im unsure of how to tell that right now :(
<kent> Goshawk i will quit irc for a min. Will mail you soon. By for now.
<ogra> Riddell: looked at kubuntu yesterday, nice work....
<jordi> omg
<jordi> I will kill
<jordi> so evolution bumps the gal dependency to 2.2.5
<jordi> the changes between 2.2.4 and 2.2.5 is an Italian update
<Riddell> convert -kubuntu ogra
<ogra> nah
<ogra> Riddell: i would suggest to get rid of the bracket stuff from the menu, its improved a lot already, but still a bit to much info :)
<Riddell> ogra: bracket stuff?
<doko> pitti: ping?
<pitti> doko: pong
<kent> Goshawk, could you please again tell me your email?  /msg me if you dont want to repeat publicly..     Im in X now so i can send you the file..
<ogra> Riddell: in the normal menus you have a nice description as menu entry plus the app name in brackets
<Goshawk> thanks kent 
<Goshawk> i think that the problem is there
<Riddell> ogra: oh yes.  KDE likes  "Description (AppName)"
<ogra> Riddell: in the game menus you have the category as entry and the appname in brackets .... etc
<Riddell> ogra: gnome likes "Description" which seems strange to me
<Riddell> ogra: what's your preference?
<ogra> Riddell: not if you only have one app for every task....
<Riddell> ogra: what does gnome do if you have two e-mail clients installed for example?
<ogra> Riddell: it gets weird if you have one app twice for one task though
<ogra> Riddell: there is only one that is named Emal Client (only the gnome included one (evo)) the other shows its name
<Riddell> ogra: dunno if I like not having app names, seems strange to me
<ogra> Riddell: so keep the app names....as you like, but i would definately get rid of one of them....
<ogra> ...but i'm only a gnome guy, so dont take me to serious ;)
<Riddell> ogra: when it comes to usability I do take gnome seriously
<Riddell> except for file open dialogues :)
<zenwhen> what
<zenwhen> i like gnome's file open dialogues
<zenwhen> I dont feel that there is only one "right way" to do file open dialogues
<ogra> Riddell: they are getting better ;)
<ogra> Riddell: there just was a complete redisign of the file open dialogue....so it takes some time to get it right....
<Riddell> must..resist..flamewar..
<zenwhen> lol
<zenwhen> i kind of left #slackware and the distro because the kde guys were always throwing  in these little "clever remarks" whenever someone mentioned gnome. then Pat dropped gnome.
<Riddell> zenwhen: you should see #ubuntu whenever someone mentions KDE.  not pretty
<zenwhen> I cam to Ubuntu because of the "no KDE", and kubuntu keeps it at a safe distance from my install disk. So by association with my anti-kde feelings, I alove the kubuntu project. :)
<zenwhen> came*
<zenwhen> love*
<kent> Goshawk, with the vga correcly set it now boots. But the graphic looks borked (not so good at english, but i think that word could descripe it.) 
<Goshawk> borked? i'm not english native...
<Goshawk> gonna see to bork on dict
<mdz> that's ok, borked isn't an english word :-)
<mdz> it means approximately "broken"
* psy__ came to ubuntu by accident, i wrecked my gentoo and ubuntu was the only distro around at the time. :p
<psy__> i love it :)
<Goshawk> broken??? uhm... in wich sense?? do you get a black screen?
<zenwhen> I am running totally up to date hoary
<zenwhen> and though it could be better in areas I love it
<psy__> Goshawk: in the sence the package-manager did not work anymore and the basic tools like cat, cp, mv, ls and ln where linked to a non-existing copy of busybox.
<psy__> gotta get some food, brb
* Mithrandir kicks gstreamer
<jordi> ok
<jordi> hopefully I won't regret this
* jordi starts uploading evolution bits.
<ogra> bits ?
<tseng> zul: still no crashes
<tseng> zul: im happy.
<jordi> ogra: gal, gtkhtml, etc
<Treenaks> jordi: *shudder*
<jordi> Treenaks: yeah dude
<ogra> jordi: so it could be that i see the fonts in one mail in the same size for every row again ?
<jordi> I might get some ninjas in the hotel room tonight
<ogra> that'd be so great
<jordi> no, that would mean Kitame wants to kill little jordi
<ogra> heh
<ogra> he wont get you ... youre a to fast runner i guess :)
<ogra> even with ninjys
<ogra> ninjas even
<jordi> ninjas can throw sharp stuff at you
<ogra> jordi: depends how far youre away then, youre not the thickes iirc ----
<psy__> re
<jordi> ogra: heh, yeah that could be an advantage.
<jordi> I could shield behind carlos too
<ogra> lol
<jordi> ogra: so we met in Matar?
<ogra> yup
<jordi> damn, I'm so bad at remembering peole
<carlos> jordi: carlos? carlos? where? when?
<carlos> :-P
<jordi> sorry :)
<Treenaks> jordi: he's one of the german guys :P
<jordi> ah
<ogra> jordi: http://ubuntulinux.org/wiki/OliverGrawert
<jordi> if you were near treenaks, he got all the attention :)
<kent> Goshawk, I do get some grapgics, its just that its.. hard to see the logo.  Have you ever  used a monitor which tries to use modes it cant have? Its sort of like that, but since its a low resolution, its something else that is broken.. dont know what. Im not a native speaker aswell, so its very hard to explain :(
<ogra> hehe
<Treenaks> jordi: I did? :)
<ogra> true
<jordi> hm
<jordi> I remember perfectly now
<jordi> Treenaks: of course dude
<Treenaks> cool :)
<jordi> it's cool that you remember me. :)
<jordi> Hey I now have my own mag.,
<jordi> it is great, have a look, gimme a second to find an url
<jordi> http://jacobo.tarrio.org/Imagen:Jmdudes.jpg
<jordi> 3 and it's yours
<jordi> good articles in there
<ogra> hamm, catalan class included ?
<jordi> that's Spanish, but yeah, issue #2 has this great "learn Catalan in 13 minutes" course
<ogra> learn Catalan in 13 minutes if you know spanish you mean....
<jordi> no, no. No previous knowledge required. I tell you, my mag is going to be great and I'll be rich in 3 months.
<abelli> jordi: what about me?
<psy__> is there a way to put unicode-strings in gtk-Labels ?
<ogra> pango
<psy__> k
<jordi> abelli: are you left handed?
<abelli> jordi: no
<abelli> jordi: not that i know ;)
<jordi> abelli: sorry then. I'm going to use an indecent amount of money paying left handed people to annoy right handed people. It will be a worldwide lefthanded revolt, for all the years we've been using scissors, pens, oven gloves, computer mouses and laptop touchpads designed for righthanded.
<jordi> this is going to be great.
<jordi> anyway, this is offtopic here. :)
<abelli> jordi: i can be the most left handed for an arm developer's board
<abelli> ...it'll be a life-lasting contract
<abelli> :)
<dholbach> jordi: if you keep on telling me your plans for world domination, please give me a subscription of your mag, send it to ...
<dholbach> :-)
<abelli> jordi: are you jdub's allied?
<psy__> pango is confusing me :p
<Treenaks> abelli: he's the European uplink station for the GNOME orbital laser platform, afaik
<jordi> hehe
<abelli> Treenaks: ohh i see.
<abelli> jordi: what about your magazine?
<zul> tseng: good no crashes
<jordi> abelli: people will buy it massively because it's cool. It's like a fundraiser for my evil anti-right-handed plans.
<abelli> jordi: can we have a bonus-just-to-get-known trial?
<jordi> nope, sorry. this is going to sell all alone, no ads or anything needed
<abelli> right. no bonus copies then?
<psy__> does anyone know a good pango tutorial?
<dholbach> psy__: had a look in devhelp?
<pitti> seb128: I just built and uploaded new update langpacks
<seb128> pitti: thanks!
<HiddenWolf> pitti: will those be updated after hoary is stable?
<seb128> you rock :)
<pitti> HiddenWolf: yes
<pitti> HiddenWolf: monthly, as it seems now
<HiddenWolf> good, that's a relief. :)
<pitti> HiddenWolf: that's the biggest reason why we go though this langpack trouble :-)
<pitti> HiddenWolf: well, the other big one is that folks can use Rosetta for translations :-)
<HiddenWolf> pitti: will there be anything like that debian repro for volatile software? virus scanners etc?
<HiddenWolf> pitti: how's rosetta coming along?
<sivang> pitti: Hi Martin :)
<pitti> Hi sivang 
<pitti> HiddenWolf: volatile> not decided yet, could make a good topic at the conference
* dilinger waves at pitti
<pitti> HiddenWolf: it evolves, but please rather ask the gurus (carlos and daf)
* pitti waves back at dilinger
<tseng> hi dilinger.
<tseng> thoughts on 2.6.11.x?
<dilinger> hello
<HiddenWolf> pitti: ok, thanks
<dilinger> i've posted a few things to lkml
<tseng> ah ive not read all the thread yet
<tseng> my mistake.
<dilinger> i'm a little worried by their restrictions excluding security fixes
<dilinger> wow, that's.. interesting
<dilinger> http://lists.netsys.com/pipermail/full-disclosure/2005-March/032240.html
<pitti> lamont: here?
<HiddenWolf> dilinger: isn't that a tad drastic?
<Mithrandir> mdz: about?
<mdz> Mithrandir: yes
<pitti> Hi mdz 
<tseng> dilinger: yeah.. embarassing
<mdz> Mithrandir: did you get my email?  need to know what's happening with the migration tool
<tseng> dilinger: fix is rolled in grsec 2.1.2
<Mithrandir> mdz: I have a much improved version, so I'd like a freeze excemption
<mdz> Mithrandir: go ahead.  as far as i'm aware, it isn't even enabled yet
<mdz> which is the next problem
<Mithrandir> the old version doesn't actually work, since gdm and python's configfileparser disagree on the format of .dmrc.
<Mithrandir> (upper-lowercase and significance of whitespace)
<Mithrandir> it uses update-manager's notification stuff
<mdz> I don't think it's feasible to force this in for preview
<Mithrandir> ok
<mdz> that's unfortunate because a lot of people will upgrade from Warty when the preview comes out
<mdz> but we can't possibly test it sufficiently
<Mithrandir> it's not really a problem; they won't have utf8 locales, but once they upgrade to final, it'll be good.
<Mithrandir> and we can ensure that it's tested well enough by then
<mdz> ok
<mdz> let's update it as soon as preview is out
<Mithrandir> ok, so I should hold off the upload  for a few days?
<mdz> yes
<mdz> until preview is announced
<Mithrandir> that's fine
<Mithrandir> I'll work on it further as there are some issues that needs to be worked out anyway (what's the way to utf8-enable a C locale?)
<T-Bone> Mithrandir: hi! Any news about ia32-libs upload?
<dholbach> see you later
<HiddenWolf> Hm, isn't there any interest in redesigning the website?
<sivang> HiddenWolf: I think there was a contest wrt to it
<zenwhen> wrt?
<HiddenWolf> wiith regard to
<HiddenWolf> sivang: not much happening so far? 
<sivang> HiddenWolf: not that I heared off, the winning one was probably not yet decided upon
<HiddenWolf> sivang: any place where I can look at the competitors?
<sivang> HiddenWolf: no idea, I am clueless as much as wrt to this.
<wasabi__> wrt to
<wasabi__> with regard to to
<opi> mako
<mako> opi: hye there
<abelli> mako: u here?
<opi> mako, the push-cork-inside-with-a-pen is a poor ripoff of my -with-a-fork technique
<mako> abelli: yes
<ogra> mako: could it be that the CC agenda has not been flushed ? 
<mako> ogra: possible
<mako> ogra: i thought i did it.. but it's possible i forgot last time
<opi> don't flush KDE stuff by accident :)
<ogra> mako: i think its still there....and i think there are some new MaintainerCandidate names
<jordi> do you sleep with the server omn?
<jordi> or is it in another room?
<jordi> mAKO!!!
<jordi> mako: I'm getting a strange, suspicious sound that I might want to get looked at at the Apple store or whatever.
<jordi> But carlos says I need the receipt.
<jordi> mako: tell me you still keep my stuff
<sivang> jordi: going to buy a new PPC ?
<jordi> no, mine is new already.
<jordi> I want to see if this sound it makes is normal
<mroth> jordi: what does it sound like?
<sivang> jordi: ah, another one?
<carlos> jordi: dude, it's a feature!!!
<jordi> mroth: it's fun
<carlos> you know when someone is trying to hack your computer :-D
<mako> jordi: hey dude
<mako> jordi: yeah dude.. i have everything
<jordi> mroth: when the pcmcia wireless card transmits or recieves packets, it makes a funny noise
<jordi> I tried daf's card and still
<jordi> mako: that's great!
<mroth> wow thats bizarre
<carlos> mroth: no, that's cool
<jordi> mako: I wonder what'd be the best way to get all the stuff delivered in Valencia. Normal postal service would be enough?
<mako> jordi: just take it into an apple licensed store though. you should be fine. it's not you bought it from somebody other than apple
<carlos> you have sound while download things
<jordi> "all" means the powercord, cdrom and all the shit
<mroth> make recordings of certain patterns before you get it fixed... "heres what a port scan sounds like!"
<jordi> mako: that's true :)
<carlos> it's the ipod integrated into the powerbook!
<jordi> mroth: haha
<seb128> mdz: here ?
<trulux> hey
<macewan> Hrm, how do I get around this?? -->>  WARNING: The following packages cannot be securely authenticated!
<mdz> seb128: yes
<seb128> mdz: was about the hibernate mail but I've replied rather, and now you have forwarded :p
<seb128> mdz: BTW about the gossip FTBFS if somebody has an idea on it ...
<mdz> seb128: if you have no idea, perhaps it should go in universe
<seb128> mdz: I've looked on it, seems to be an autostuff issue but I don't understand why it breaks, the config.log finds XScreenSaver and breaks just after
<wasabi> mdz, debian bug 225648, added an apt option to bypass apt auth checks. What is that option
<wasabi> cannot find it in the docs
<mdz> wasabi: man apt-get
<wasabi> Doh.
<wasabi> Here I am searching thru man apt.conf
<seb128> mdz: hum, k. I'll have a look again on it :)
<mdz> seb128: is gossip important? we have gaim
<seb128> a part of the GNOME users don't like gaim, gossip is not big and nice to have
<mdz> it is very small when it FTBFS :-)
<seb128> but not, that's not important, just nice to have
<seb128> bah, the same package used to build fine and builds fine in debian
<seb128> I tend to blame xorg :)
<mdz> /tmp/ccylnX49.o(.text+0xa): In function `main':
<mdz> /tmp/gossip-0.8/conftest.c:37: undefined reference to `XScreenSaverRegister'
<mdz> collect2: ld returned 1 exit status
<mdz> nm
<mdz> that's the first test
<mdz> it seems like the AC_TRY_COMPILE must be failing
<zenwhen> is "firefox scrolls really slow" a valid bug report?
<zenwhen> lol
<dholbach> re
<seb128> hey dholbach 
<seb128> dholbach: gtkmm 2.6 to package :)
<dholbach> seb128: rocking
<zul> jdub around?
<dholbach> seb128: it finally does break API?
<seb128> dholbach: ??
<dholbach> seb128: 2.6 reminded me of: we're brand new and breaking API now
<dholbach> seb128: but even better if it doesnt :-)
<mdz> seb128: hmm
<mdz> seb128: I added some debugging echos and re-ran autoconf, and now it succeeds
<seb128> mdz: building the small .c works here
<seb128> hum
<seb128> weird
<seb128> just autoconf ?
<seb128> doesn't fix it here
<mdz> seb128: right, same here
<mdz> seb128: I think configure.in is just wrong
<mdz> look at this
<mdz>    AC_TRY_COMPILE([
<mdz> #include <X11/extensions/scrnsaver.h>
<mdz>                 ] ,[] ,[enable_xss=no] ,[
<mdz>                 AC_DEFINE(USE_SCREENSAVER, 1, [Define if we're using XScreenSaver.] )
<mdz>                 ] )
<mdz> that means that if the compile succeeds, it will do enable_xss=no
<mdz> and if it fails, it does the AC_DEFINE
<seb128> hum
<mdz> seems backwards
<seb128> what I don't get that the same package is in the archive, why does it break now
<mdz> does it compile in Debian?
<seb128> yep
<mdz> does Debian have it in libXss or libXext?
<mdz> hmm, wouldn't matter
<mdz> I bet that in Debian, it gets built without xss support
<seb128> http://buildd.debian.org/fetch.php?&pkg=gossip&ver=0.8-1&arch=powerpc&stamp=1104928942&file=log&as=raw
<seb128> checking for XScreenSaverRegister in -lXext... no
<seb128> checking for XScreenSaverRegister in -lXss... yes
<seb128> 
<seb128> nop
<mdz> that means nothing
<mdz> what matters is enable_xss
<mdz> if enable_xss is anything but "no" it doesn't give the error
<mdz> by default enable_xss will be ""
<mdz> config.log from Debian would be enlightening
<mdz> but honestly I think the test is backwards
<seb128> yep, I'm starting a pbuilder
<seb128> we can just fix it
<mdz> yes
<mdz> I think maybe X11/extensions/scrnsaver.h is missing in the Debian build
<mdz> if you have a Debian chroot with the build-deps installed, see if it's there
<seb128> a min, updating it
<GheRivero> res
<seb128> hi GheRivero 
<seb128> mdz: 
<seb128> # ls -l /usr/X11R6/include/X11/extensions/scrnsaver.h
<seb128> -rw-r--r--  1 root root 4510 2004-12-15 20:12 /usr/X11R6/include/X11/extensions/scrnsaver.h
<mdz> hmmm
<mdz> I would like to see config.log if possible
<seb128> yep, I'm putting it online
<seb128> a sec
<seb128> mdz: http://pkg-gnome.alioth.debian.org/config.log
<mdz> bingo
<seb128> mdz: right, the /scrnsaver.h seems to be broken 
<mdz> In file included from conftest.c:27:
<mdz> /usr/X11R6/include/X11/extensions/scrnsaver.h:39: error: parse error before "Bool"
<mdz> so the test is backwards, and it worked because the compile failed :-)
<seb128> yep :)
<Zaww> www.otomotivshow.com
<zenwhen> http://zenhardwhere.com/images/up2date.png
<zenwhen> first time i have ever caught up with hoary
<zenwhen> lol
<zenwhen> dialup sucks
<zenrox> zenwhen,  dont i know ill never go back to dialup
<zenwhen> ive no other option
<zenwhen> or i wouldnt be using it
<zenrox> move to a place that has brodband
<zenwhen> oh gee
<zenwhen> i sure hadnt thought of that
<zenwhen> @_@
<zenrox> lol
<zenwhen> I am in a couple months
<zenrox> kewl
<zenrox> what are you gona get cable,fiber,adsl
<zenrox> ya for me even getting updates is slow 
<zenrox> 768k in/ 128k out
<GoneBoB> well in australia you can choose between ridiculously slow expensive links
<GoneBoB> and really quite fast inexpensive links
<GoneBoB> and it's somewhat random as to what is available depending on your location
<zenwhen> zenrox, I will have 4Mbit/256k
<zenwhen> for 40 bucks a month
<zenwhen> cable
<tseng> hey dudes, this is getting a bit off topic
<zenwhen> oh
<zenwhen> It was silent, sorry.
<zenrox> lol
<psy__> dholbach: devhelp is nice, thanx for the reference :)
<dholbach> psy__: cool :-)
<psy__> only thing is, just about every entry in it makes sence to me... except pango :p (gonna google some more, and place my findings next to it. to see if i get somewhere that way :p)
#ubuntu-devel 2005-03-18
<psy__> T-None: ?
<T-None> psy__: what? I'm not there for long
<jdub> http://live.gnome.org/ProjectUtopia_2fPowerManagement_2fScreenshots
<jdub> yay team
<tseng> the second shot down is a little "heavy"
<jdub> yeah
<jdub> davidz :)
<psy__> T-None: why the nick-change?
<psy__> jdub: :)
<thierry> I'd like to help, do you have any easy to fix bugs for me?
<psy__> thierry: you silly... if anyone knows on fore-hand a bug is easy to fix... wouldn't it been done already?
<thierry> :) yeah but some too busy people sometimes get to harder task to I tough maybe someone could point me some easy ones...
* psy__ just noticed the gnome weather-applet in hoary knows the difference between day and night
<seb128> mdz, jdub: is that ok to update gksu to the new version ? The new version is basically the merge of the differents patches with some changes that fix the sound issue 
<seb128> it's in debian for a week
<jdub> if you've checked it and are happy with it, sure :)
<seb128> yep, I have
<seb128> k, thanks ;)
* psy__ celebrates his use unicode... next stop 'gettext'
<thierry> seb128, I want fix Ubuntu bug 3176 but I don't know where to add the code, any Idea?
<seb128> I think you have already asked a bunch of time here and on the gnome IRC today, nop, sorry
<thierry> k... It's really easy to fix but I just don't know where
<seb128> look on a default bookmark and grep for it in the mozilla-firefox sources
<seb128> (just an idea)
<thierry> seb128, already tried but I didn't work... can you give me example of the use of grep for like bob bookmark
<jdub> seb128: just testing gnome#169347 ;)
<ajmitch> afternoon all
<jdub> thierry: grep -irl bookmark *
<jdub> man grep is pretty handy :)
<thierry> jdub, I know but it's hard to find exactly what you want in it
<seb128> jdub: nice, quick patch on this one :)
<seb128> thierry: grep "www\.oneurl" 
<seb128> thierry: the URL is probably not in a lot of places
<thierry> seb128, great idea! thanks
<seb128> np
<thierry> seb128, I did grep "http://www.mozilla.org/support/firefox/" but it stands there like if was waiting something... I know search can be long but it's been about 5 minutes and still nothing
<seb128> hum
<seb128> k, I'm downloading the sources
<thierry> seb128, that's what happen about 4 time on 5 when I grep something
<seb128> firefox sources not small
<thierry> k
<seb128> are not small even
<seb128> it's going to take some minutes to download
<thierry> k
<psy__> nn
<seb128> jdub: working on #7239 ? 
<jdub> seb128: looking at it ;)
<seb128> cool, thanks :)
<thierry> seb128: about 10 minutes and still nothing...
<thierry> just waiting...
<seb128> you ?
<seb128> hum
<seb128> if you don't give a second argument to grep you can wait forever :p
<thierry> seb128, and what is supposed to be the second argument?
<seb128> man grep
<seb128> where grep should search 
<thierry> ho ok!
<seb128> thierry: I think than you are looking for profile/defaults/bookmarks.html in the sources
<thierry> seb128: sort of but in the top of this file there's this :
<thierry> <!-- This is an automatically generated file.
<thierry> It will be read and overwritten.
<thierry> Do Not Edit! -->
<thierry> seb128, so I don't think this it...
<seb128> that's probably true once installed
<seb128> but I'm not sure in the source package
<seb128> you can try to build a package with it changed
<zul> jdub: ping
<jdub> zul: pong
<zul> jdub: did tseng talk to you?
<thierry> seb128, ok I'll try
<mdz> seb128: gksu is OK by me
<seb128> mdz: k, thanks
<zul> jdub: inotify 0.20  homer kernel: inotify enabled!
<zul> Mar  6 08:37:27 homer kernel: inotify device minor=63
<tseng> everything works but gamin polling /media still
<tseng> i think ill have to post to the mailing list about that
<jdub> rockin'!
<zul> <elvis>thank you...thank you very much</elvis>
<srbaker> anyone here have any luck with eclipse with gcj4 ?
<thierry> seb128, Ok I've made the changes, now how do I build this firefox from source without broking my current firefox installation?
<mdz> jdub: so it looks like we may have been bailed out as far as inotify for hoary
<mdz> jdub: but what about polypaudio?
<jdub> mdz: no traction from upstream, i think we should bail out
<jdub> mdz: no huge loss, esound still works
<jdub> and i've fixed an annoying bug in esound
* jdub wonders if ds has fixed the bitrate detection bug
<seb128> after breaking it first :p
<seb128> *g* :)
<jdub> it's no fun otherwise :)
<jdub> seb128: dude, what did you have for breakfast this morning?
<mdz> FREEDOM JUICE
<dholbach> :-)
<mdz> jdub: what are the blockers, apart from it apparently being total shit on ppc?
<seb128> jdub: that's sunday, just some good sleep :p
<jdub> mdz: esound protocol sample caching issues
<jdub> mdz: (login/out sounds, unreliable sound effects)
<jdub> mdz: /tmp/.esd not killed when daemon exits
<mdz> I haven't seen any problems with sound effects, and the last time we discussed the login/out problem it sounded like it was fixable
<jdub> it's fixable unreliably atm
<jdub> you're probably not noticing that sound effects only happen intermittently :)
<jdub> general cpu usage issues, but probably fixable by changing frame periods, etc.
<jdub> also verbose logging (seb128's favourite)
<seb128> robtaylor has a lag between image and sound in totem too
<HrdwrBoB> yeah running esound with movies can result in enourmous lag
<HrdwrBoB> gets to be several seconds by the end of a 1.5hr movie
<jdub> seb128: that's fixable, but i wouldn't regard it as a regression (esound is worse) ;-)
<tseng> actually ive noticed some lag with muine
<seb128> yeah :)
<crimsun> it does seem to be notoriously unreliable across many ubuntu hoary installs; some people have to wrangle to get sounds to work
<crimsun> others have it work by default
<jdub> there's also something really weird going on between upgrades and sessions
<jdub> crimsun: yeah
<jdub> i do not get that one at all
<crimsun> neither do I, but it's a significant problem for people dist-upgrading from warty
<jdub> significant in that we can't determine why it works sometimes and doesn't other timgs ;)
<crimsun> true
<mdz> daniels: thanks for the update to the doc team
<daniels> mdz: no worries.  i'll be unreachable for most of today, but public transport is a double-edged sword: it takes a bit longer, but I can work on it.  so I'll be hacking on the Debconfiscation, 'cause I think I have a pretty good idea of how to fix it for upgrades.
<zul> mdz: i just sent an update on inotify to the kernel mailing list
<mdz> daniels: I think we need to release preview with what we have now; there isn't time to test debconfiscation changes
<mdz> zul: kernel-team@?
<daniels> mdz: *nod*, those were my thoughts also
<zul> mdz: yep
<daniels> mdz: allows me a bit more time for testing all the possible scenarios also
<mdz> daniels: and to triage the oodles of bug reports we'll get from preview
<jdub> seb128: i'm tempted to link libesd.so.0 to libesd.so.1 -> your call?
<mdz> thom: around?
<daniels> mdz: yeah
<seb128> jdub: urg
* seb128 apt-cache rdepends
<mdz> haggai: I am very excited that oo.o2 can open files with spaces in the pathname :-)
<seb128> jdub: why libesd.so.1 ?
<jdub> seb128: stupid proprietary software (flash)
<daniels> mdz: ok, i'll likely be gone for the next ... realistically about 7h
<daniels> mdz: with any luck, this should be the last of the paperwork
<mdz> daniels: can you send me an approximate calendar for you for this week?
<mdz> daniels: do you have an estimated date for broadband yet?
<seb128> jdub: that's really ugly ... but there is a new esound with a soname change around ?
<daniels> mdz: mind if I do that when I get back?  just about to run out the door to catch the last bus for the next hour now
<daniels> mdz: when I move in + about a week or two; i'll have a better idea after today.  even while I'm on dialup, I'll be walking distance from 100MBit though, so I can burst as much as I need
<mdz> daniels: ok, please
<daniels> mdz: i've got my phone with me if needed
* daniels -> city
<dholbach> seb128: i have glibmm and gnome-vfsmm ready on http://ubuntu.gplan.info/mm
<seb128> dholbach: nice
<jdub> seb128: strings ~/.mozilla/plugins/libflashplayer.so | grep esd
<seb128> "No such file"
<seb128> flash sucks :p
<jdub> heh
<mdz> jordi: did you realize that you have sold your soul?
<dholbach> seb128: i'll need glibmm-2.6.0 for gtkmm-2.6.0 and gtkmm-2.6.0 for the other ones
<jdub> $ strings ~/.mozilla/plugins/libflashplayer.so | grep libesd
<jdub> libesd.so
<jdub> libesd.so.1
<jdub> it's bizarre
<seb128> $ strings /usr/lib/mozilla-firefox/plugins/libflashplayer.so | grep esd
<seb128> libesd.so.1
<seb128> right :)
<jdub> sucks so much you installed it system wide!
<jdub> :-)
<seb128> :p
<seb128> remember, I'm french :)
<zul> heh..french :)
<Burgundavia> mdz: updates to doc team?
<mdz> Burgundavia: x.org summary for the release notes
<Burgundavia> mdz: ah
<lupusBE> bleh c'est une language tres difficile pour moi :)
<seb128> he he
<mroth> crimsun: what should I do with the kern.log, open a new bug with it in bugzilla, or is there something else to check first?
<crimsun> mroth: you need to compare it with output from booting the machine with the usb device plugged in
<mroth> alright, i'll boot it again for sake of consistency, bbiaf with results
<mroth> crimsun: hrm, interestingly enough, it appears the freeze is prior to kernel logging begins, since kern.log isnt touched from the boots where it freezes
<crimsun> mroth: zul suggested it very well could be an irq conflict
<mroth> wouldnt that happen independantly of the software then?  since the problem is linux specific
<zul> is this a new install?
<mroth> no, its been on hoary for the past 3-4 months at least
<zul> latop/desktop?
<mroth> desktop
<zul> have you tried with booting pci=noacpi and the like?
<mroth> yeah, sometimes that fixes it, but I tend to not do that since I'd rather unplug the thing before boot and still have ACPI
<mroth> since it works fine if you plug it in post-boot
<zul> well open up a bug and will have a look at it closer
<mroth> kernel-package?
<zul> linux
<mroth> entered as bug #7258
<zul> thanks
<mroth> should I set target to 5.04 to indicate this is experienced in hoary?
<zul> sure..can you include your demsg as well thanks
<mroth> sure.. how would I obtain dmesg from an unsuccessful boot?  I assume you want one from a bad boot, not a successful one without the reader
<zul> you can check your kern.log i believe
<mdz> mroth: the target milestone field is used for us to catalogue which bugs need to be fixed in which stage of the release
<mdz> mroth: please leave it untouched
<mroth> mdz: I thought that might be what it was for, which is why I asked, heh
<mroth> (left untouched)
<mroth> zul: kern.log isnt being written for the bad boots, i think its freezing prior to kernel logging to disk being init'd
<zul> hmm ok 
<mroth> hmm.. i could probably turn off quiet mode and just take a digicam pic of the screen?
<zul> bbl
<mroth> is there a kernel arg for verbose logging to screen?  going to see how much info i can nab
<zul> mroth: you could try removing quiet from your grub when you first boot
<mroth> yeah, removing quiet doesnt seem to be quite as verbose as what normally gets put in kern.log though
<ogra> night
<zul> later
<mdz> ogra: you rock
<dholbach> mdz: he's to bed already
<dholbach> mdz: but i'll tell him, he'll be pleased to hear :-)
<mdz> dholbach: thanks
<dholbach> mdz: de rien
<mdz> dholbach: do you live near ogra?
<mdz> I suppose not, if you're awake
<dholbach> mdz: it's 150km to him :-)
<dholbach> and i'm just mad to be still awake
<mdz> apparently
<dholbach> hehe :-)
<dholbach> i wanted to finish the libg*mm updates
* mjg59 finishes hacking for the evening
<mjg59> I've managed to make nstx solid. Go me.
<HrdwrBoB> daniels wanted nstx to use cnames because telstra blocked the TXT records
<mjg59> Haha
<dholbach> well i'm off to bed now... good night
<mdz> dholbach: night
<Benoni> jdub, mdz ... either of you fellows around?
<Benoni> OK, I'll throw this out to the general crowd then.
<Benoni> I'm working on a change to the build processes for an Ubuntu package.
<ajmitch> what changes?
<Benoni> Starting with "*.orig.tar.gz" and "*.diff.gz", how should I organize things so as to make it as easy as possible to build a new "*.diff.gz" file after I've made my changes?
<Benoni> ajmitch, this is some experimental work with bug-hunting feedback instrumenation.
<ajmitch> add a new version in the changelog, when you build the package a new .diff.gz will be built
<ajmitch> if you wish to go that way
<Benoni> I've been chatting with jdub, seb128, mdz, and Luis Villa about it in e-mail.
<Benoni> ajmitch, what I don't understand is how the diff is built later.  There's the tree I've modified, but where does it look for the pristine reference tree?
<crimsun> orig.tar.gz
<Benoni> Oh, I see.  So the diff-building tool looks for the pristine sources right in the gzip'd tarball.  Cool.
<Benoni> That's easy enough.
<Benoni> Thanks, crimsun.
* Benoni has a head full of RPM trivia, and is still learning his way around the Debian packaging universe.
<jdub> yo Benoni 
<Benoni> Hey, jdub!
<Benoni> As you can see, your colleagues are keeping my questions nice and answered.
<jdub> :-)
<Benoni> Quck status update:
<Benoni> I've got reasonable ".deb" packages being built for my instrumentor and the various supporting tools.
<Benoni> The instrumenting compiler seems to be working just fine, no changes required at all.
<Benoni> Now I'm looking at what it takes to CBI'ify a sample application.  Rhythmbox is my chosen test subject.
<Benoni> I expect I'll end up with a couple of "dh_*" helper commands that one tosses into the "debian/rules" file in appropriate places.
<Benoni> That should cover most of what's needed beyond just switching compilers.
<jdub> hrm, what kind of stuff?
<Benoni> As I noted in an earlier e-mail message, there are a few assorted other things to do, e.g.:
<Benoni> install an extra GConf spec file
<Benoni> move actual binaries out of /usr/bin and replace them with wrapper scripts that call the real binaries stored elsewhere
<jdub> a new schema file per package?
<Benoni> Yeah.
<Benoni> "GConf spec file" should have been "GConf schema file"
<jdub> we could do those on the buildd
<Benoni> What's "the buildd"?
<jdub> the machines that build everything :-)
<Benoni> Ah.
<Benoni> So I guess my question for you is how should I codify the changes that are required when building a CBI-instrumented package?
<Benoni> I was assuming it would be codified as changes to "debian/rules" and perhaps a few extra files also under "debian".
<Benoni> But perhaps that's not the most useful form.
<jdub> doing it in one package and documenting your changes is good
<Benoni> OK.
<jdub> so if we decide to do it for a large selection of packages, we can fiddle with the buildd
<Benoni> To whatever extent I can, I'll try to encapsulate the changes in scripts that figure things out by themselves.
<Benoni> For the most part, those scripts already exist and are used when building instrumened RPMs.
<Benoni> Ack, late-night high-priority support request from a colleague in an inconvenient time zone.  I'll have to pick this discussion up later.
* Benoni wave to jdub et al.
* Benoni waves to jdub et al.
<whiprush> man, those web design entries are awesome.
<fabbione> hey
<crimsun> wb fabbione!
<fabbione> hey crimsun 
<crimsun> things going well?
<fabbione> crimsun: well first day at work after honeymoon... you decide :)
<opi> fabbione: sounds nasty :)
<crimsun> :-)
<opi> fabbione: one hint: don't read mails or/and see what's on voicemail :P
<fabbione> opi: ahha
<fabbione> hey pitti
<pitti> Morning
<pitti> Hi fabbione, welcome back!!!
<fabbione> thanks dude
<pitti> fabbione: did you have a nice honeymoon?
<fabbione> yeah it was cool
<pitti> or, rather, warm? :-)
<fabbione> heheh that too :-)
<daniels> fabio!
<fabbione> hey kid!
<daniels> ciao bella!  how was your honeymoon?
<fabbione> it was great fun
<fabbione> i am gonna put pics online later today
<fabbione> me with galapagos penguins :-)
<daniels> heheh
<daniels> fantastic!
<daniels> i gotta go help mum with food now, back a bit later
<fabbione> sure later
<Micksa> why would gnome-panel and nautilus segv on startup, from a clean account?
<Micksa> in hoary
<Benoni> In a "debian/control" file, can one use backslashes to break up long Build-Depends lists over several lines?
<elmo> no
<fabbione> Benoni: nope.. it has to be on one line
<fabbione> hey elmo!
<Micksa> I think my problem might be due to missing packages but I wouldn't know which ones I need
<elmo> hey fabbione - have a good time?
<fabbione> elmo: i need to send you a pic that you must put on galapagos in the dc :-)
<Micksa> besides "gnome-panel" :)
<fabbione> elmo: oh yeah.. it was great
* Benoni pouts.
<Benoni> OK fabbione, thanks for the info.  Too bad it wasn't what I was hoping to hear.  ;-)
<fabbione> np
* Benoni discovers the joys of cdps.
<dholbach> good morning
<T-None> hey fabbione! Welcome back aboard! :)
* T-None points fabbione at #u-kernel and runs to work
* fabbione sighs
<fabbione> ok
<abelli> fabbione: ciao.
<fabbione> ciao
<daniels> can you guys please grab http://people.ubuntu.com/~daniels/pcibustype.c, compile it (with -DDEBUG if you want), and point it at your video card, and let me know if it works out pci/agp/pcie correctly?
<daniels> to find out your video card's PCI ID, run lspci -X | grep 'VGA compatible controller' | cut -f1 -d' '
<daniels> e.g. sudo ./pcibustype $(lspci -X | grep 'VGA Compatible controller' | cut -f1 -d' ')
<fabbione> daniels: remind me in a few minutes :-)
<daniels> er, sorry
<daniels> e.g. sudo ./pcibustype $(lspci -X | grep 'VGA compatible controller' | cut -f1 -d' ')
<daniels> fabbione: sure :)
<pitti> daniels: 
<pitti> $ ./a.out PCI:1:0:0
<pitti> failed reading from offset %
<pitti> couldn't read capability
<daniels> pitti: sweet!
<daniels> that's on powerpc, yeah?
<pitti> daniels: no, i386
<daniels> really?
<jdub> $ sudo ./pcibustype PCI:0:2:0 pci
<crimsun> fails here, too. i686.
<daniels> pitti: could you please build with -DDEBUG and /msg me the output?
<jdub> run it with sudo
<daniels> er yeah, sudo is important :)
<jdub> $ ./pcibustype PCI:0:2:0
<jdub> failed reading from offset %
<jdub> couldn't read capability
<pitti> daniels: oops, forgot sudo
<jdub> :-)
<daniels> only root can read the PCI caps
<pitti> daniels: on i386: "agp"
<daniels> pitti: is that right? :)
<pitti> daniels: yes, that's right
<crimsun> for me: "agp". That is correct.
<daniels> pitti: for bonus points, could you please try on powerpc?
<pitti> daniels: on my iBook G4: "pci" (without sudo)
<daniels> pitti: hmm.  is it an agp card, d'you know?
<pitti> daniels: with sudo: "agp" too
<jdub> pci on my laptop, agp on my desktop
<pitti> daniels: err, "pci", too
<daniels> pitti: ah right
<daniels> er, hm
<pitti> daniels: actually this should be agp, too...
<daniels> pitti: if you run sudo lspci -v -v -v, is it listed as having AGP in the capabilities section?
<pitti> daniels: but I'm not sure
<pitti> okay
<daniels> turns out that the one in my laptop is PCI as well; may be something to do with an integrated bridge?  who knows
<pitti> daniels: Capabilities: [58]  AGP version 2.0
<daniels> d'oh
<pitti> daniels: DEBUG then?
<jordi> mdz: hmm? because of evolution? :)
<daniels> could you please build with -DDEBUG and send me the full output in /msg?
<daniels> yeah
<jordi> mdz: I'm worried, yes. :)
<jdub> daniels: all fine here, my laptop doesn't seem to have agp
<fabbione> daniels:
<fabbione>    * Use "Dev Phys" and USB device IDs in xorg.conf, instead of relying on the
<fabbione>      hotplug handlers to set up /dev/multiuser.
<fabbione> this is wrong :-)
<daniels> fabbione: bah
<daniels> fabbione: hotplug never cauthg PS/2, for one
<fabbione> it does
<fabbione> it takes longer due to the nature of the bus
<daniels> hmm.  well, on my system and on gus's too, we just never got it
<daniels> even after sleeping for 10 seconds
<fabbione> it was working here
<daniels> so we were losing a lot of input ... that was just my quick fix
<daniels> hm.  well if we can fix it that would be great, but that was just what I had to do to get it working for both of us
<daniels> jdub: cool
<fabbione> the reason why you should not use Dev Phys in xorg.conf is because you bind 2 config files even more
<fabbione> if the admin wants to move a keyboard from one hub to another
<fabbione> it needs to change config in 2 places
<fabbione> and restart all of X
<fabbione> for all the 4 heads
<fabbione> with the other solution is one change and one kill -USR2
<fabbione> that was the all reason of updating the evdev patch to allow path to /dev
<daniels> well, we have multiseat-configurator now
<daniels> so theoretically you update multiseat.conf and re-run m-c
<fabbione> did you update the code in hotplug to kill the proper server?
<daniels> but yeah ... if we can get the hotplug stuff fixed (lots of devices just weren't registering for me -- i missed one usb mouse and one ps/2; gus was missing the ps/2 and two usb, iirc), i'm happy to keep using that :)
<daniels> nope
<fabbione> on my test install with 0.4 only the ps2 was NOT detected
<fabbione> but i figured that there was something else wrong
<fabbione> and it wasn't a multiseat error
<fabbione> i think the entry in /proc/bus/input/devices is created only after the first ps2 bytes are received on the bus
<daniels> oh
<daniels> that's shit
<fabbione> becuase strangely enough it was always the last entry in that list
<fabbione> but had no time to dig more into it
<fabbione> galapagos were waiting for me :-)
<daniels> heh, yeah :) fair enough, too
<daniels> fabbione: pcibustype.c at least solves the 'which card is AGP?' problem
<daniels> stupid VGA routing :\
<fabbione> what problem is that?
<daniels> you HAVE to bring up the primary card (i.e. the one taking VGA interrupts) last
<daniels> else your machine will hang solid
<fabbione> uh?
<daniels> i wasn't seeing this problem because the agp card in my machine was listed last in lspci
<fabbione> i always init AGP as first in my setup
<fabbione> and it works fine
<daniels> so if you look in multiseat-configurator, we make sure the agp card comes last, since that's generally the primary
<daniels> weird -- could be a revision-specific thing with gus's setup?
<fabbione> weird
<daniels> but it was definitely hanging until we did that
<fabbione> hmmm
<daniels> which was a 'what the hell, trying this can't hurt' thing at 5am
<fabbione> now.. i remember the old multiseat setup from that was doing that
<fabbione> init the agp as last
<daniels> yeah
<fabbione> but i never had that problem with our setup
<daniels> might be a motherboard thing
<daniels> or even a bios rev thing
<fabbione> yup
<daniels> vga routing is a tricky beast
<daniels> there are lots of good things about vga.  and so, so many bad things.
<pitti> Hi mvo
<mvo> hi pitti 
<froud> mvo
<froud> do you read your memoserv
<daniels> pitti: it's OK thanks, I can throw a PCI card in my amd64 here
<pitti> daniels: ok
<daniels> thanks for the testing though
<pitti> you're welcome
<dholbach> hellas mvo 
<froud> mvo: I have a draft of the update-manager manual ready, but no access to svn, so can't get it to you. Also have questions.
<mvo> hi froud, hi dholbach, morning all
<mvo> froud: I don't read my memos, didn't knew that I have any :)
<froud> :-)
<froud> ok'
<froud> how can I get this stuff over to you
<mvo> froud: just send it via mail to me, that's savest
<mvo> froud: I'll try to talk to mithario about your account again
<daniels> lamont: ping
<pitti> Morning carlos
<carlos> pitti: morning
<fabbione> ola carlos
<carlos> fabbione: hey!
<carlos> fabbione: welcome
* fabbione feels full of spanish these days :-)
<carlos> fabbione: how was your trip?
<fabbione> it was great
<fabbione> lot of fun
<carlos> cool
<mvo> fabbione: hey! welcome back!
<fabbione> hey mvo!
<carlos_> fabbione: dude, jordi does not remembered that he was your AM!!
<fabbione> ehhehe
<daniels> ah, back when fabio was a little nm :)
<fabbione> that's because, as any good padowa, i overtook his place of jedimaster
<carlos> (jordi) that's bullshit dude :)
<carlos> jordi is without network atm
<mvo> ping doko
<Kamion> hey fabbione, welcome back
<abelli> Kamion: is there any netinst in ubuntu?
<Kamion> abelli: no
<abelli> Kamion: thx
<fabbione> hey Kamion! thanks
<fabbione> Kamion: how is the overall situation?
<Kamion> with regard to what? :)
<fabbione> everything? :)
<Kamion> looking pretty good for hoary preview
<fabbione> cool
<fabbione> ok mails are done.. time to start upgrading some machines
<Kamion> if you mean personally, all well :) still deep in wedding planning, we have a meeting with caterers today
<fabbione> 17K mails -> trash
<fabbione> Kamion: thanks god i am over it
<abelli> ehehe
<fabbione> Kamion: but you are going to have a lot of fun with planning
<Kamion> yeah, I know :)
<dholbach> hi dredg 
<dholbach> what do i do wrong, when i get    dbus_bindings.DBusException: Connection ":1.7" is not allowed to add more match rules (increase limits in configuration file if required)    when i start hal-device-manager?
<mvo> dholbach: you have it too?
<mvo> I got a bug assigned about that problem
<mvo> dholbach: don't touch your system, I want to know what it is!
<Treenaks> h-d-m DOES set a lot of match ruls..
<Treenaks> +e
<dholbach> mvo: i'll set up some black tea, when will you be here?
<dholbach> mvo: :-)
<doko> pong: mvo
<mvo> doko: you have mail :)
<fabbione> hey seb!
<daniels> yo seb
<seb128> morning
<pitti> Hi seb128 
<mirak> why does ubuntu ppc on macintosh tries to install quik boot loader instead of Yaboot ?
<mirak> how can I change this default
<seb128> hi fabbione daniels pitti :)
* pitti heartily curses at polypaudio
<Kamion> mirak: what kind of Mac?
<dholbach> hai seb128 
<Kamion> mirak: also what does 'archdetect' say if you run it on tty2?
<dholbach> seb128: gtkmm and gnomeuimm are up, at http://ubuntu.gplan.info/mm/, libglademm has to wait for gtkmm
<jdub> pitti: ?
<pitti> jdub: still debugging the assertion failure on ppc
<jdub> pitti: golly.
<pitti> jdub: it tries to play a 682 byte block with 16 Bit/stereo
<pitti> jdub: which has a frame size of 4 bytes, and 682 % 4 != 0
<pitti> jdub: I think it forgets to update the block size on mono->stereo remixing
<pitti> jdub: because the original mono sample is 682 bytes, too
<pitti> jdub: or that is not #bytes, but #frames
<pitti> jdub: but the source code is so spaghetti-like, it is hard to grok it
<abelli> cat vmlinuz > /dev/audio
<jdub> pitti: the kind of code that would appeal to a kernel hacker? :)
<pitti> jdub: no, totally different :-)
<jdub> heh
<pitti> jdub: lots of void*, lots of asynchronous code
<pitti> jdub: event-based
<jdub> aha
<pitti> jdub: and, of course, without useful comments :-(
<daniels> everyone loves void pointers
<pitti> yeah, they are so easy to debug
* jdub coughs "german engineering"
<jdub> ;-)
<jdub> pitti: lennart would love your feedback, he's been really response (at least until he went to egypt)
<jdub> responsive
<pitti> jdub: does he know about this bug already?
<jdub> pitti: yes, but hasn't been around much at all
<jdub> pitti: he came back from egypt, mailed once, but radio silence since then
<pitti> :-(
<jdub> pitti: have you looked at polyp svn?
<pitti> fears our bashing :-)
<pitti> jdub: no, just the current package
<mvo> daniels: can you please have a quick look over #7188 (dbus) and tell me if my proposed solution sounds about right
<Keybuk> meh :-/  so it wasn't just laptop I was using last time
<Keybuk> something about my home network and Mark's NAT are not friends
<ajmitch> pitti: seen the pax breakage on bugtraq?
<jdub> Keybuk: you're in his mac list?
<daniels> jdub: he doesn't have one
<daniels> Keybuk: pic seems to ditch ssh keepalives, among others
<daniels> er, pix
<daniels> mvo: sounds fine to me, feel free to upload
<mvo> daniels: thanks
<pitti> jdub: just looked at the svn, last commit is 2 months ago
<Keybuk> jdub: no, last time going directly through his pix rather than through hagrid solved it
* Keybuk waits for mark to reappear
<pitti> ajmitch: yes, I saw it
<pitti> ajmitch: I have to update my -hardened kernel
<pitti> ajmitch: but I still have high-priority stuff to do before this
<ajmitch> yes, that's why I was asking ,not that I've used them :)
<pitti> ajmitch: however, was a pretty big shock :-(
<ajmitch> yeah, I was surprised
* pitti discovers http://higgs.djpig.de/ubuntu/www/
<pitti> coool
<lifeless> __keybuk: tell mark to do the reconfiguration I've prepped
<lifeless> __keybuk: it may help
<pitti> I was so often asked about a web-based package info interface for Ubuntu...
<lifeless> the ssh keepalive thing will be the pix's short session lifetime counter
<lifeless> (the first thing I do to any pix is ratchet that way up
<daniels> my first step usually involves setting fire to it
<__keybuk> lifeless: *shrug* going directly to the pix works fine (as now)
<robtaylor_> jdub: there?
<jdub> yeah
<robtaylor_> jdub: ah, cool. backlog telle me you were chatting with seb about the polypaudio lag issue..
<mirak> Kamion: a mac G3, so not an oldworld
<robtaylor_> jdub: i get a second of lag atm =)
<mirak> Kamion: archdetect command not found
<mirak> Kamion: that's a debian I switched to ubuntu
<robtaylor_> jdub: i was chatting with the gstreamer guys and they pointed at esdsink not haveing delay reporting as a possible reason..
<robtaylor_> jdub: that might also explain the varying lags you've seen
<jdub> robtaylor_: yeah, that affects everything though
<Kamion> mirak: archdetect> I mean while the installer is still running
<jdub> robtaylor_: but both esound and polypaudio lag with other tools (xine)
<mirak> Kamion: I don't know, I didn't installed ubuntu
<mirak> I upgraded from debian
<robtaylor_> jdub: so so we know what conetxt the lags are appearing?
<Kamion> mirak: oh, what exactly are you talking about then?
<mirak> on debian it was using yaboot
<Kamion> 10:06 < mirak> why does ubuntu ppc on macintosh tries to install quik boot loader instead of Yaboot ?
<robtaylor_> i've only tested with mpegs locally .
<mirak> I also have debian on an oldworld and it runs quik
<Kamion> while doing what?
<mirak> Kamion: a dist-upgrade
<mirak> upgrade of the kernel image
<jdub> robtaylor_: polyp improves on esound, but it's not perfect yet
<Kamion> *that's* the information I was looking for
<mirak> Kamion: I though it was obvious :)
<Kamion> no, it was not
<Kamion> ok, I'll have a look at it
<robtaylor_> jdub: well its does improve in a number of ways, but a second lag on playing video is something terrible
<jdub> robtaylor_: you'll get worse out of esound
<lunitik> jdub: I still think at the least, we need a tool like Red Hat's s-c-sound or whatever... too many people have sound issues! 
<robtaylor_> jdub: i'm not here as a user dude =)
<jdub> seb128: (yikes - woooosh!)
<seb128> :)
<robtaylor_> jdub: what i want to know is if there enough known to attack the problem
<jdub> robtaylor_: sure, but you'd be wanting to speak to the gstreamer guys and lennart for polyp
<jdub> robtaylor_: another option is fixing the gst-polyp src/sink
<jdub> (possibly more useful than fixing esdsink)
<robtaylor_> jdub: might do that.. i have to learn about the sync stuff anyway for my rtp plugin =)
<jdub> (you know, it would be a kinda neat hack to use rtp for network audio)
<robtaylor_> jdub: i know, that was the otehr thing iw as going to chatr you about..
<Mithrandir> jdub: seems flumotion doesn't have any amd64 love; gst falls over and dies.
<jdub> Mithrandir: ooh, really?
<sivang> Hello everybody
<jdub> Mithrandir: doing something simple?
<pitti> Hi sivang
<sivang> hey pitti  :)
<Mithrandir> jdub: starting the director, a worker and the admin interface.
<robtaylor_> jdub: i've been thinking for a while that it would be neat to use jackd with the jackd-asyn sink, and use rtp for remote stuff ( again going to a locally running jackd with jackd-asyn at the end)
<seb128> jdub: about g-a-i/desktop files ?
<jdub> Date: Mon,  7 Mar 2005 04:56:46 -0500 (EST)
<jdub> ^ gnome-games on f-r-l
<jdub> Date: Mon,  7 Mar 2005 11:24:52 +0100
<robtaylor_> jdub: and pro guys can stick run the security hole, but it wound't necessarily be needed for normal users ;)
<jdub> ^ gnome-games on hoary-changes
<haggai> Mithrandir: any idea about #6762?  The crash is in pango
<jdub> ;-)
<jdub> seb128: been working on it today
<haggai> Mithrandir: could it perhaps be fixed already?  I remember you doing something to pango
<jdub> Mithrandir: so you're not actually running a flow?
<Mithrandir> jdub: before I even get to that.
<Mithrandir> jdub: seems like the video test source is crashing, actually.
<Mithrandir> haggai: oopadmin/spadmin probably isn't wrapped in my glorious pango hack
<haggai> Mithrandir: ah right
<Mithrandir> haggai: that's my first guess at least.
<haggai> Mithrandir: sounds like a good guess
<Mithrandir> haggai: you want me to look at it post-preview?
<haggai> Mithrandir: yes please if you could, I don't have a machine here.  How complicated is your pango hack?  An alternative would be to disable the gtk frontend for padmin, would be a simple envvar export in the script
<Mithrandir> haggai: it's a LD_PRELOAD
<haggai> Mithrandir: ah so similar effort
<sivang> gtk-gnutella is still b0rked right?
<sivang> (I just checked and I see it's missing the binary)
<crimsun> sivang: yes, I'm building & signing a new upload
<sivang> crimsun: yay!
<sivang> crimsun: what was the problem preventing clean build of the binary?
<crimsun> sivang: gtk-gnutella source included its own progress bar cell renderer which conflicts with GTK+-2.6's
<sivang> crimsun: ah, figures.
<crimsun> sivang: I took the opportunity to also grab a fix for a possible NULL pointer deref
<sivang> crimsun: superb!
<dholbach> seb128: got the message on gtkmm and gnomeuimm? don't want to bother you... just make sure :-)
<ogra> fabbione is back !!
<ogra> morning everybody
<trukulo> hi oliver
<seb128> dholbach: nop
<fabbione> ogra: no you are only dreaming
<dholbach> <dholbach> seb128: gtkmm and gnomeuimm are up, at http://ubuntu.gplan.info/mm/, libglademm has to wait for gtkmm
<seb128> dholbach: where ?
<seb128> dholbach: k, thanks
<ogra> heh, dreaming of fabbione 
<trukulo> fabbione, what about your wedding?
<fabbione> trukulo: what about it?
<trukulo> fabbione, are you a married man now?
<fabbione> it was cool and cold :-)
<trukulo> lol
<fabbione> getting married in a snow storm wasn't 100% fun
<Mithrandir> fabbione: where were you?
<trukulo> fabbione, you should be nude to be 100% fun
<ogra> but something you can tell your  kids about
<fabbione> Mithrandir: copenhagen
<trukulo> ogra, i see graveman 0.3.8 from sid is in hoary, good work
<Mithrandir> fabbione: on the honeymoon? :)
<fabbione> http://www.fabbione.net/wedding/IMG_0854.html
<ogra> trukulo: i have added a cdrdao dependency.... 
<fabbione> Mithrandir: ecuador and galapagos
<ogra> trukulo: else, thanks for the good upstream work ;)
<Mithrandir> fabbione: oooh, sounds nice. :)
<trukulo> ogra, good point, i'll tell otavio
<fabbione> Mithrandir: it was :-)
<fabbione> Mithrandir: galapagos > *
<Mithrandir> fabbione: got loads of pics?
<sivang> fabbione ! Welcome Back :)
<fabbione> Mithrandir: 2Gb of digital + 10 x 36 films + 2 x 28(?) underwater pics
<Riddell> elmo: could you look at the kdebase compile when you have time?
<trukulo> fabbione, you seem a funny penguin dreesed like that
<Mithrandir> fabbione: nicey. :)
<trukulo> it's kinda geek, heh
<fabbione> trukulo: i looked like one.. yeah :-)
<fabbione> Mithrandir: i am trying to complete the sync of my mirrors before putting them online.. something hanged badly a while ago
<trukulo> fabbione, then, now you are back with us again... i have a weird question for you
<fabbione> i am back
<fabbione> from this morning
<fabbione> but for weird questions.. hmmm 
<fabbione> gimme 2 minutes :-)
<trukulo> can you blow yourself?
<fabbione> mother nature is calling
<trukulo> ups, that's not for you
<trukulo> i'll wait
<trukulo> :)
<fabbione> no i can't blow myself :-)
<trukulo> fabbione, you've tried then...
<Kamion> Riddell: elmo won't be around most of today
<Riddell> Kamion: humph
<fabbione> trukulo: ehhee
<fabbione> ok so what's the weird question?
<trukulo> well, i have an ati igp 320m
<fabbione> -> daniels
<trukulo> good answer
<sivang> fabbione: you have turtule photos? ;-)
<fabbione> sivang: hey.. yes
<trukulo> fabbione, but you was X dev
<fabbione> both land and sea turtles
<fabbione> trukulo: i am out of X since we met in Mataro...
<trukulo> it's a question about dri enabled in livecd, and not in hoary installed
<trukulo> uf, lot of time then, ok, ask daniels
<fabbione> trukulo: that could depend on dri modules loaded properly or not
<trukulo> fabbione, i assure you i've read a LOT
<fabbione> be sure that the kernel modules are loaded properly
<trukulo> and have proper modules loaded
<trukulo> drm, ati_igp, agpgart,radeon and dependant modules
<daniels> trukulo: i don't think dri works on the 320
<trukulo> strange is, glxinfo say DRI=yes in livecd, and not in hoary installed
<daniels> really?  that is weird
<daniels> not installing fglrx or nvidia or anything else strange?
<fabbione> check the diff between lsmod and xorg.conf in both livecd and installed version
<trukulo> daniels, in livecd i swear you it said to me : yes
<trukulo> i'm aware about 3d problem with 320m
<trukulo> no, livecd as is
<trukulo> fabbione, same one
<trukulo> and i use same xorg.conf than in livecd
<fabbione> kernel version is the same?
<trukulo> i'm completely lost
<trukulo> fabbione, no, kernel is different
<fabbione> well you got your answer :-)
<trukulo> 2.4.9 in livecd, and 2.4.10-k7 in installed
<trukulo> yes, but why? modules are the same, isn't it?
<fabbione> no
<fabbione> try a more recent livecd
<trukulo> and igp320m it's not supossed to have 3D
<fabbione> 2.6.9 is obsoleted
<trukulo> fabbione, 2.6.9 works
<trukulo> in fact, it's 2.4.10-4-k7 that doesn't work
<trukulo> i said, it's very weird
<trukulo> could be dri enabled different in 2.4.9 than in 2.4.10 ?
<fabbione> yes
<fabbione> they are
<trukulo> then that's it
<trukulo> in 2.4.9 glxinfo reports dri enabled, and with 2.4.10 not
<fabbione> archives hates me
<trukulo> fabbione, i understand that poor archives
<trukulo> well, doesn't matter, just wanna know what's that
<trukulo> see you in 10 mins
<HiddenWolf> woohoo, 2.10 packages! :)
<daniels> trukthat's really weird ... 
<abelli> sladen: uml, or vserver?
* lunitik wishes there was a 'seperator' applet...
<lunitik> Wasn't there one once upon a time?
<Kamion> sepArator :-0
<Kamion> :-)
<lunitik> Would make it so much easier to visually organize my panels  :(
<lunitik> Kamion: gah... thats why I don't major in English  :P
<pitti> jdub: ping
<jdub> pong
<pitti> jdub: still no luck with polypaudio
<pitti> jdub: do you think it would hurt us much to default to oss sink, at least on ppc?
<jdub> pitti: mdz and i were talking about reverting to esound for hoary, which i'm happy with
<jdub> pitti: if you're not getting any love with that change, that's the last nail in the coffin
<pitti> jdub: it works fine with oss
<jdub> yeah
<jdub> i know
<jdub> but cumulatively, we're better off reverting
<pitti> jdub: I'm just not sure whether it makes sense for me to spend hours and hours on it
<jdub> stop now :-)
<jdub> before we lose you in the spaghetti :)
<pitti> I still have one trace, I think I give myself another half an hour
<pitti> okay=
<jdub> heh
<pitti> okay?
<jdub> sure
<sivang> spaghetti ? somebody said spaghetti? boy, /me is hungry
<pitti> sivang: go eat some asynchronous polypaudio code :-)
* ogra too
<jdub> whoa, language pack a-go-go
* jdub is updating mirror
<Keybuk> heeeere's johnny!
<sivang> pitti:  :)))
<Burgundavia> jdub: might this fun with polypaudio be the reason that muine is currently borked on my machine?
<dholbach> bbl
<jdub> Burgundavia: depends on your configuration and what the b0rkage is
<Burgundavia> jdub: hmm. Well muine starts but simply doesn't play and rhythmbox throws up an error about alsa device is use, and I assume those are connected. I just did a search of bugzilla, but didn't see anything
<jdub> run gstreamer-properties, see what gstreamer is configured to use
<Burgundavia> alsa
<Burgundavia> hmm, changed to esd and it worked
<Burgundavia> got that for Oss and Alsa - Failed to construct test pipeline for 'OSS - Open Sound System
<jdub> esd is the correct configuration if you're using polypaudio
<jdub> (and it is the default)
<Burgundavia> ah
<Burgundavia> I had some issues with that several months ago, and that is why it was changed
<Burgundavia> however, I am a little confused. Is there an easy place I can start reading about Alsa/Esd/etc. and where all the pieces fit?
<jdub> hrm, don't think so
<Goshawk> is there someone interested to try a alpha package of an "usermode splash" booting process?
<Burgundavia> jdub: right I shall dig. Thanks for the quick help
<jdub> i can give you a quick run down
<jdub> alsa is the kernel interface to the sound hardware
<jdub> libasound is the alsa user level libraries, used to access the kernel interface
<jdub> esd is a userspace daemon run as the user that mixes audio, does sample caching, and network audio
<Treenaks> it's mostly used for the mixing and sample-caching parts though
<jdub> gstreamer is a multimedia framework that includes sinks (output plugins) for alsa, esd, etc.
<jdub> polypaudio is a less neanderthal replacement for esd (but early stage)
<jdub> oss is the old kernel audio interface
<jdub> anything else you missed?
<robtaylor_> jdub: remind me again why we decided alsa dmix as a bad idea? ;)
<Burgundavia> so apps talk to gst --> esd/polpy --> alsa/oss ?
<ogra> or gst -->  alsa/oss
<jdub> robtaylor_: because it's unreliable, doesn't handle network audio, is a pita to configure, etc.
<jdub> Burgundavia: by default in warty, apps that use gstreamer talk to esd -> oss
<jdub> Burgundavia: in hoary, we were hoping for that to be polyp -> alsa
<robtaylor_> jdub: heh, well i think its back to it on my system rather than suffer esound again =)
<ogra> Burgundavia: but without a mixing component like esd ppaudio between gst and alsa/oss you are only able to play one sound at a time
<jdub> unless your audio hardware support multiple writers
<jdub> (which is not the case on any of my new hardware)
<ogra> Burgundavia: thats why you get the error in RB if esd/ppaudio is running in the background 
<jdub> (and the primary reason why i didn't give a crap about any of this when i had an sb live)
* netjoined: irc.freenode.net -> benford.freenode.net
<robtaylor_> jdub: seems ok on centrino chipset =)
<jdub> the 810 audio chip doesn't support multiple writers
<jdub> that's why you're using dmix
<Burgundavia> I see why they say audio on linux is a mess
<HiddenWolf> Burgundavia: more things than just audio are a mess. One of the disadvantages of not having strict corporate control.
<robtaylor_> jdub: ah, misread above text =)
<jdub> don't assume windows is much better
<Burgundavia> so the perfect world is gst with ppaudio and alsa?
<Burgundavia> is that doable in hoary+1?
<HiddenWolf> jdub: windows is smoother to work on, linux is safer/more reliable 
<dredg> all bets are off when it comes to i8xx, be that sound or video :)
* dredg smacks his laptop
<crimsun_> Burgundavia, ideally we wouldn't need anything like esound, polypaudio, or their ilk
<jdub> HiddenWolf: i'm referring to your audio comment.
<crimsun_> Burgundavia, it'd be nice if alsa-lib's dmix were fully up to snuff, but unfortunately that's not the case
<HiddenWolf> jdub: never had a windows machine give out on me soundwise
<jdub> HiddenWolf: that has nothing to do with available audio interfaces and "mess"
<ogra> how does macos solve that ?
<pitti> jdub: I think I'm close to the problem now :-)
<ogra> pitti: i have added a question about language settings to hwdb-client.....
<ogra> pitti: it currently reads:  Is the system language setting ok ?
<ogra> pitti: any better suggestions for a question would be very welcome
<pitti> ogra: <bitch>It should read "Ist die Spracheinstellung korrekt?</bitch> :-)
<ogra> grrr....
<ogra> :)
<pitti> ogra: maybe s/system/default/ or s/system//
<ogra> hmm, the default ? 
<pitti> ogra: you can change it in gdm
<ogra> dont i have to select one on installation ?
<pitti> ogra: right
<pitti> ogra: you select a default
<pitti> ogra: maybe just drop "system"
<ogra> hmm, ok
<pitti> any other opinions?
<ogra> i'll do it this way
<crimsun_> I vote for "correct" instead of "ok"
<ogra> yeah, sounds better :)
<pitti> YAHOOOOOOOOOOOOOOOOOOO
* pitti now happily plays through polypaudio on ppc
<pitti> jdub: got it
<jdub> :-)
<Burgundavia> jdub: for the unwise: http://gnomedesktop.org/node/feed
<Burgundavia> jdub: try that http://www.linux-mag.com/2004-12/sound_01.html
<Burgundavia> how is this mess? http://www.linux-mag.com/2004-12/img2/sound_01.gif
<pitti> jdub: stupid bug: pa queried the block duration in ns from ALSA and used this time (682 ns) as buffer size
<pitti> jdub: AARRGH
<jdub> Burgundavia: good one
<jdub> Burgundavia: it's much simpler on real distributions
<crimsun_> pitti, eek!
<jdub> Burgundavia: you have one line to traverse
<Burgundavia> jdub: ?
<jdub> that graph is meaningless on normal systems
<Burgundavia> ah
<fabbione> humpf
<fabbione> jetlag is hitting me :-)
<Treenaks> pitti: crack!
<jdub> pitti: that's pretty remarkable
<jdub> pitti: why does it only manifest on ppc?
<pitti> jdub: pure coincidence, AFAICS
<jdub> cunning :)
<pitti> jdub: I'm testing the patch with several use cases now, and later on my i386
<pitti> jdub: it's only an one-line patch
<jdub> heh
<jdub> congrats, and thanks :)
<pitti> you're welcome :-)
* pitti now listens Simon&Garfunkel on his iBook 
<ogra> haha, Linux's sound architecture is multi-layered and complex.....
<ogra> ....sure, if i display it this way.....
* Kamion attempts to disentangle base-installer's kernel metapackage handling
<Treenaks> ogra: Linux sound architecture is like an onion!
<Treenaks> </shrek>
<ogra> Treenaks: does that look like an onion to you ? http://www.linux-mag.com/2004-12/img2/sound_01.gif
<ogra> *g*
<Treenaks> ogra: *fires up gimp*
* ogra thinks linux inst complicated...... just its documentation is.....
<ogra> s/inst/isnt
<tseng> cool @ redesign winners
<tseng> i especially like the Download Ubuntu thing here:
<tseng> http://people.ubuntu.com/~jdub/2005/webcomp/brad-griffith.png
<jdub> tseng: yeah
<Treenaks> tseng: it looks very mozilla.orgish
<jdub> pitti: hmm, that should have a nice impact in general, really
<tseng> Treenaks: in a good way
<pitti> jdub: I'm just _really_ puzzled that this only occurred on ppc
<pitti> jdub: it's probably sound chip dependent, not arch-dependent
<lamont> fabbione: word to the wise - before uploading any gnome packages for sparc, make sure they don't reference libhowl, or life gets painful...
<lamont> daniels: ack
<seb128> jdub: a guy on #gnome would like to get this fix to clearlook: http://sourceforge.net/tracker/index.php?func=detail&aid=1156793&group_id=129376&atid=714612
<pitti> lamont: Hi
<pitti> lamont: the stripped tarballs are fine now
<pitti> lamont: can you please move all tarballs but today's to old-translations/ and update the directory *.txt files?
<daniels> lamont: yo ... l-r-m 2.6.11? :)
<jdub> seb128: i'm sure upstream will fix that quickly
<jdub> seb128: i'll remind them
<seb128> k
* jdub fixes Humanity in the mean time
<lamont> daniels: ??
<fabbione> hey lamont 
<trukulo> hey, one question... on topic : upgrade to kernel 2.6.10-24
<trukulo> shouldn't be : 2.6.10-4
<trukulo> ?
<fabbione> -24?.....
<lamont> morning fabbione  - sorry about the mailing list thing...
<fabbione> lamont: no problem..
<fabbione> already placed the filters around
<fabbione> hmm that's why it was looking weird...
<lamont> -23 had a bad inotify patch... :-(
<daniels> lamont: is it planned?
<Kamion> trukulo: 2.6.10-24 is the package version, 2.6.10-4 is the kernel version with module ABI
<Kamion> trukulo: try not to confuse the two
<lamont> daniels: fabbione is doing 2.6.11....
<trukulo> Kamion, ok, thanks
<fabbione> as soon as i get my local mirror synced again
<fabbione> just to be able to download the sources...
<Kamion> trukulo: the topic's good the way it is
<lamont> trukulo: and 2.6.10-4_2.6.10-23 was bad, 2.6.10-4_2.6.10-24 was good...
<fabbione> but yeah.. i can get .11 out tomorrow or something
<fabbione> i need to resync with 2.6.10 first
<lamont> fabbione: arch repository for 2.6.10 debian tree is in rookery:~lamont/Archives/kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10
<trukulo> ok, ok , i understand now , thanks for info
<fabbione> lamont: ok thanks :-)
<lamont> fabbione: s/arch/baz/ btws
<fabbione> yeah
<lamont> fabbione: and fwiw, the sparc buildd died shortly after you left. :-(
<lamont> s/died/went non-responsive/
<fabbione> lamont: yup.. i read the mail and started it again
<fabbione> lamont: for some reason the machine just went back to OBP
<fabbione> no idea why
<lamont> OBP?
<fabbione> Open Boot Prom
<daniels> ah cool
<lamont> ah, 'k.
* lamont must take kids to school
* fabbione must get some sleep
* daniels must sleep also.
* trukulo must be rich
<fabbione> later guys
<fabbione> i need to sleep a bit to get over the jetlag
<jordi> fabbione: dude?
<jordi> damn
* thom stands on jordi's shoulders
<daniels> thom: that won't get you very far
<zul> heylo
<tseng> hi zul 
<zul> hi tseng 
<sivang> seb128: do you know where on fd.o there's the manual for the .desktop file spec?
<amu> pitti: could you please review dbus-qt for a move into main 
<carlos> amu: is KDE moving into main for Hoary?
<amu> carlos: yep
<ogra> sivang: look in software for something like xdg
<sivang> ogra: eh I thought they were in the specs, and googled but nothing :)
<trukulo> ogra, you there?
<sivang> ogra: nah, not there
<trukulo> ogra, why do you added cdrdao as a depend?
<trukulo> i'm looking changelog, and cdrdao is included in cvs, not in 0.3.8 , i'm i wrong?
<jordi> thom: that is going to crush me if you do it again
<ogra> trukulo: it is used by 0.3.8
<trukulo> ogra, http://savannah.nongnu.org/cgi-bin/viewcvs/graveman/graveman/current/ChangeLog?rev=1.42&content-type=text/vnd.viewcvs-markup
<trukulo> read it, it's used (changelog said) in 0.3.8 cvs, not released
<trukulo> otavio and i are using 0.3.8 released
<ogra> sivang: http://specs.freedesktop.org/wiki/Standards/desktop-entry-spec
<trukulo> cvs version will ber 0.4
<sivang> ogra: thanks, how did you search ? 
<amu> elmo: please could you sync libassuan-dev from debian into universe
<jdub> buildds are working overtime tonight! :)
<ogra> trukulo: so your version has no reference to cdrdao in its settings ?
<trukulo> ogra, so, as i know, 0.3.8 we use doesn't use cdrdao
<trukulo> it shouldn't, but i'm not sure as it's made by otavio, not me
<ogra> mine has
<trukulo> could be, i'll ask otavio when i see him
<ogra> trukulo: havent had the time to try it out extensively, but was assuming it would be used if the settings have such an option
<trukulo> ogra, not sure, anyway, that depend would be ok for next version
<ogra> yeah for preventive dependencys
<trukulo> :) yeah
<seb128> sivang: http://standards.freedesktop.org/desktop-entry-spec/
<sivang> seb128: thanks again :-) 
<ogra> sivang: what are you working on `
<ogra> ?
<sivang> ogra: trying to see how oowriter is executed, as per #6202
<ogra> sivang: das i thought you were bored enough to go for this one : https://www.ubuntulinux.org/wiki/UniversePackageWithoutDesktopFile
<ogra> s/das/sad
<ogra> *g*
<sivang> ogra: hrm, one question, how did you form this list? :-)
<ogra> i didnt...it suddenly appeared out of nowhere.....
<sivang> I think that it's either done using a script, or some madman :)
<ogra> ...but it would be nice to have a conversion script from the debian menu entrys
<sivang> from menu entirs to desktop files , hmmm
<sivang> interesting bit
<HiddenWolf> sivang: you'd better hope it's a script. :)
<sivang> HiddenWolf: yeah, I nearly fainted to the length
<sivang> ogra: well, the guy who wrote the script can just as easy write a conversion script I think :)
<ogra> i think half of this list doesnt need an entry....
<ogra> sivang: true....
<sivang> ogra: or else we can create a script to read this wiki page, and create desktop files for each pkg there :)
<ogra> heh
<HiddenWolf> I see gnome 2.10 entering hoary, but it's not done yet, right?
<rburton> HiddenWolf: releasing tomorrow morning
<pitti> daniels: you were too fast with replying to #7138 :-)
<pitti> daniels: I wanted to include both outputs since they differ
<rburton> HiddenWolf: so i expect seb128 would have it all done by then
<jdub> HiddenWolf: hoary gets packages as they're uploaded to gnome ftp
<jdub> there's only one last thing to optimise out
<jdub> but he's french
<jdub> and we like him
<jdub> so we keep him around :-)
<rburton> seb128 is needed so we've got a free tomboy logo
<ogra> jdub: move him to .au :)
<HiddenWolf> jdub: does gnome usually ship with ~1050 open bugs?
* seb128 slaps rburton 
<jdub> rburton: good point
<jdub> HiddenWolf: huh?
<HiddenWolf> http://bugzilla.gnome.org/reports/gnome-210-report.html
<rburton> HiddenWolf: are you suggesting that software is generally released without any bugs?
* jdub boggles
<HiddenWolf> rburton: just suprized at the amount and impact of them, really
<jdub> dude, those are only the bugs that are *reported*
<rburton> i just did my bit and removed the SJ bug from that list
<Treenaks> jdub: why not do a 2.10.1 "bugfixes only, please" release then? :)
<HiddenWolf> jdub: I figured that.
<zul> only ~1050? wow...windows must have less
<rburton> Treenaks: gnome does exactly that
<Treenaks> HiddenWolf: also, lots of those are NEW and UNVERIFIED etc.
<Treenaks> HiddenWolf: I guess
<jdub> Treenaks: we've done that for every release i can remember
<jdub> oh
<jdub> except 1.4.1
<jdub> that's a funny one
<Treenaks> jdub: that one's ancient, too.
<jdub> though we ended up officially releasing it at one point, as a tribute
<HiddenWolf> Will that bug be fixed that prevents the mouse theme from showing?
<jdub> HiddenWolf: no such bug exists
<tseng> are you talking about a bug where the cursor theme is missing?
<jdub> currently, there is no cursor theme on the disk
<tseng> HiddenWolf: if you get the ximian-artwork tarball you can throw it in ~/.iconts
<tseng> icons
<HiddenWolf> jdub: the ubuntu themed cursors got replaced with the ugly industrial ones, i thought that was a bug.
<tseng> uhm
<jdub> HiddenWolf: entirely the wrong way around :)
<tseng> industrial got replaced with X defaults
<pitti> lamont: ping
<jdub> HiddenWolf: the industrial ones were dropped on the floor in a major reshuffle upstream
<HiddenWolf> jdub: doh, sorry :S
<jdub> HiddenWolf: it's best to ask questions before making statements like these.
<tseng> or look around bugzilla :P
<HiddenWolf> :$
<HiddenWolf> jdub: will the theme be back?
<jdub> yes
<seb128> jdub: grrr, this guy on #gnome-debian ...
<jdub> yeah
<thom> seb128: hostinggeek (aka Gmail, shimen) ? there's a reason he's banned here
<seb128> I start to understand why :p
<ogra> argh, he is in gnome-debian now ?
<Treenaks> thom: he wants to come to ubuntu down under
<ogra> AAAHH
<Treenaks> or so he said this morning
<sivang> ARGH
<thom> oh sweet baby jesus
<ogra> seb128: currently we have hom as pet in ubuntu-motu
<ogra> him even
<thom> i've had him on ignore for a long, long time
<tseng> some pet
<tseng> he keeps biting me in the ankles
<sivang> tseng: heheh
<bob2> it'll be cool
<zul> tseng: its a love bite :)
<ogra> hehe
<bob2> someone will snap and beat him up
<jdub> he thinks you will
<bob2> s/someone/everyone/, I guess
<tseng> jdub: kicked off a thread on gamin-list about /media/* and inotify
<jdub> tseng: was just about to mention :)
<jdub> tseng: the problem is that there's a lot of duplicated functionality between dnotify and inotify
<jdub> tseng: and the problem with *that* is that it's not completely duplicated :)
<tseng> I figured as much
<jdub> needs a bit of refactoring
<tseng> but he just posted with no small confidence that it was solved
<jdub> oh, DV replied?
<tseng> I figure if i point it out, he'll test and quickly solve the issue
<tseng> no, his most recent post
<tseng> http://mail.gnome.org/archives/gamin-list/2005-March/msg00000.html
<jdub> he's only testing against dnotify
<tseng> makes sense
<tseng> ill bbiab, might even poke at the code if its obvious
<jdub> tseng: do you have a blog?
<tseng> planning on it soon
<jdub> cool
<tseng> dholbach wants to track motu daily routine
<tseng> which is a nice idea
<pitti> amu: which package shall I review again?
<pitti> amu: (sorry for the lag, lots of stuff to do...)
<amu> pitti: no prob, dbus-1-qt, it's needed as a builddepends for kdebase, which blocks atm everything  
<pitti> amu: but it's already in main??
<pitti> amu: dbus-qt-1, at least
<amu> Filename: pool/universe/d/dbus/dbus-qt-1-dev_0.23-1ubuntu6_powerpc.deb
<amu> http://people.ubuntu.com/~lamont/buildLogs/k/kdebase/4:3.4.0-0pre1ubuntu1/kdebase_4:3.4.0-0pre1ubuntu1_20050307-1408-i386-failed
<ogra> amu: tried kubuntu, nice piece, congrats :)
<sivang> jdub: can I take the Ubuntu logo , just translate the letters of the name and put on the .IL wiki ? who can permit that?
<sivang> jdub: (into hebrew , ofcourse)
<jdub> mail info@ubuntu.com
<sivang> jdub: ok, thanks/.
<bob2> so
<bob2> something that sucks is having some key get stuck during resume
<bob2> so it's impossible to unlock xscreensaver, as the password box gets filled with a thousand chars
<ogra> ouch
<bob2> I blame mjg59 in some way
<mjg59> Gah. Not my fault.
<ogra> hmm, does anyone remember a bug where the keyboard doesnt work right in X, you switch to a console where everything works but is uppercase ? i'm just expiriencing that.....
<ogra> it gets lowerscase after one login/logout cycle and X is fine again
* ogra wonders what to blame for this one
<bob2> mjg59: have you ever seen it happen?
<mjg59> Yeah.
<mjg59> The 8042 driver needs to reset more state on resume
<bob2> ah
<mvo> is archive.ubuntu.com a bit slow right now?
<dholbach> mvo: yes... for me too
<mvo> wb dholbach !
* ogra heard this question on #ubuntu before today
<dholbach> mvo: merci beaucoup
<mvo> dholbach: excellent your french :)
<dholbach> hehe... seb128 would laugh about it ;-)
<seb128> ah ah :p
* dholbach needs to catch up on it, once the thesis and everything have settled
<seb128> and we have no op on #gnome-debian ...
* tseng gives seb128 a power bar
<Kamion> ogra: if you type your username in all-caps, getty assumes you're on an ancient terminal where lowercase didn't work properly and forces everything to uppercase
<ogra> Kamion: i dont type caps...but they get displayed....
<pitti> Kamion: ah, thanks. I already thought there was a bug with shift lock in the kernel
<Kamion> well, something evidently threw some capital letters at that tty
<ogra> Kamion: i remember seeing this one with 2.0 and 2.2 kernels as well
<ogra> where it occured even via ssh
<Kamion> the code's been there for eons; I don't remember exactly where it lives
<ogra> yeah, i thought it was solved long ago.... i'll have a look after preview if i find the ancient bugfix...
<ogra> Kamion: oh, and btw, its on all ttys and even the issue text and login are capitalised
<lamont> ogra: that code has been standard-unix for as long as I can remember...
<lamont> ogra: it forces _everything_ into uppercase
<zul> hey lamont
<lamont> morning zul
<ogra> ah....
* ogra starts to understand....
<Treenaks> lamont: but: how do you get out of that mode?
<lamont> Treenaks: start a new tty
<ogra> Treenaks: login/logout
<lamont> or fail to login 3 times
<Treenaks> lamont: urgh.. that sounds windowsish
<ogra> what worries me is that it seems connected to a berakage in X
<lamont> it's a fall back mode in case you're stuck in the 1970's.
<ogra> breakage even
<lamont> ogra: b0rkage :-)
<ogra> since i only discovered it through a not working keyboard in X ....
<ogra> lamont, heh
<Mithrandir> thom: is jackass broken?
<thom> Mithrandir: ...
<Mithrandir> thom: http://archive.ubuntu.com just sits there
<Kamion> jackass != archive.u.c
<thom> that's not jackass
<Mithrandir> oh, sorry
<Mithrandir> archive.u.c, then :P
<lamont>     /* Handle names with upper case and no lower case. */
<lamont>     if ((cp->capslock = caps_lock(logname))) {
<lamont>         for (bp = logname; *bp; bp++)
<lamont>             if (isupper(*bp))
<lamont>                 *bp = tolower(*bp);             /* map name to lower case */
<lamont>     }
<lamont> you mean that code?
<Mithrandir> thom: thanks
<thom> sure
<ogra> lamont: ah, ok, that shows why i can log in....but it doesnt show why the uppercase mode was triggered...
<lamont> ogra: yeah.  not sure whether to blame getty or tty driver for that...
<sivang_livecd> bah, locale settings is pretty weird I had to wait for about 20 locales to be generated, and after choosing hebrew as the language (which was alos nicely detected by the keyboard selector) I had a default desktop with hebrew only input 
<lamont> (that code was from getty, fwiw)
<ogra> lamont: thanks :)
<sivang_livecd> eh well, need to open a bug report
<pitti> thom: do you have an ETA for ffox 1.0.1? and moz 1.7.6?
<thom> i'm gonna get 1.0.1 finished after lunch, then start on 1.7.6
<pitti> oh, cool
<pitti> thom: so you don't wait for Debian?
<pitti> thom: Eric said that he will package 1.0.1 soon, too
<thom> 1.0.1 is in debian
<pitti> oh, even better
<thom> i don't really want to use it, but i will do to get the security bugs nailed
<Kamion> mdz: the place where you've put the copying of debian-installer/keymap is pretty dodgy, and won't work when we move to debconf-copydb
<Kamion> mdz: (in casper)
<Mithrandir> Kamion: is initrd as of yesterday broken wrt choose-mirror and countryprefix?
<Kamion> mdz: it happens to work because the confmodule from before the pivot is still running, but couldn't the copy happen before chroot/pivot?
<Kamion> Mithrandir: hm, possibly :( I'll check
<Mithrandir> it seems to try to download http://${countryprefix}archive.ubuntu.com(null)/ubuntu, which doesn work. :P
<Kamion> that's supposed to have been SUBSTed
<Mithrandir> it's what it outputs on tty4
<Mithrandir> (or tty3, not sure)
<Kamion> Mithrandir: I think I fixed that on Saturday; check the choose-mirror version in that initrd
<Mithrandir> 1.06ubuntu5
<Kamion> 1.06ubuntu6 was the fix
<Mithrandir> ok
<Mithrandir> I'll download a new initrd, then
<pitti> elmo: can I please have dchroot warty access on concordia and davis?
<Goshawk> is there someone that has 1 minute to try this script? http://81.113.230.186/kalatlug/Projects/usplash/test-script.sh
<Mithrandir> Kamion: same problem
<Mithrandir> Kamion: is there a workaround?
<Goshawk> just one minute... -(you need hoary + xorg)
<pitti> Goshawk: I did, shall I /msg you the output? or mail?
<Goshawk> for me is the same
<Goshawk> thanks
<Goshawk> ok thanks
<Goshawk> i've found the problem
<Goshawk> thanks a lot!
<bluefoxicy> http://rafb.net/paste/results/HXV38h96.html
<bluefoxicy> Is this known
<pitti> Goshawk: shall I try again?
<Goshawk> pitti, thanks to you a usplash bug is solved
<pitti> Goshawk: I'm honored, and I didn't even do anything :-)
<Goshawk> ^__^
<ogra> Goshawk: interested in output from a amd64 widescreen laptop ?
<Goshawk> yep
<fabbione> seb128: you around?
<seb128> yep
<fabbione> seb128: did you fix the build-dep order for libhowl being dropped?
<seb128> order ?
<fabbione> well sparc buildd is bitching a lot about it
<seb128> yeah
<Kamion> Mithrandir: I just noticed the same thing. Please don't ask me for workarounds when I have no idea what the problem is yet. :)
<seb128> fabbione: lamont knows about it
<bluefoxicy> libgnome2-common installation is still hanging in apt
<fabbione> seb128
<fabbione> seb128: he told me something about it
<fabbione> but i would like to hear from our gtk/gnome guru
<Goshawk> ogra, thanks also to you
<Goshawk> ^__^
<seb128> I've uploaded gnome-vfs2, libgnome, libbonoboui, libgnomeui, ... in the right order with space to build between them
<seb128> fabbione: kicking again has worked fine on i386/ppc/amd64/ia64, dunno about sparc
<fabbione> seb128: yes, but sparc was lagging way behind for other reasons
<fabbione> so what is the correct thing to do?
<mdz> Kamion: yes, I could move it to before the pivot
<fabbione> seb128: sparc buildd died 18 days ago :-)
<pitti> Morning mdz
<seb128> fabbione: find the /usr/lib/*.la with a mention to howl
<Goshawk> ogra, pitti the problem was that the case value was too short for big values more that 1024x768, thanks 
<fabbione> so it knowns nothing about it
<fabbione> hey mdz :-)
* Kamion wonders why DEBCONF_DEBUG=20 isn't working, and tries booting the whole installer with DEBCONF_DEBUG=20
<mdz> fabbione: hey!
<mdz> fabbione: how was your trip?
<Kamion> bet this'll be fast
<fabbione> seb128: ok... if i find something with it.. what should i do?
<fabbione> mdz: cool!
<fabbione> mdz: it is seriously worth all the money
<ogra> mdz: hi, thanks for the nightly flowers :-D
<fabbione> galapagos > *
<mdz> I have wanted to go there
<fabbione> mdz: after i will put the pics online, you will go there
<pitti> mdz: at least we now can see how it looks like, from Fabio's photos :-)
<seb128> fabbione: the order for the libs is: gnome-vfs2 libgnome libbonoboui libgnomeui 
<seb128> fabbione: you should build them in this order with the new version of the previous one to kick howl out of the .la files
<fabbione> seb128: hold on...
<seb128> fabbione: if there is an issue with a package already built we can reupload or you can do a binary NMU ...
<bluefoxicy> stat64("/usr/share/locale/en/LC_MESSAGES/dpkg.mo", 0xbffff698) = -1 ENOENT (No such file or directory)
<theine> Hey seb128, thanks for applying the openbox patch
<pitti> bluefoxicy: that's normal
<seb128> theine: np :)
<pitti> bluefoxicy: you have to install a language pack
<fabbione> so those are the only 4 packages affected by that problem?
<bluefoxicy> pitti:  i'm stracing dpkg to find out why it's hanging on gnome2-common and gnome2-vfs
<seb128> fabbione: no, but after that kicking should be enough
<fabbione> seb128: argh....
<pitti> bluefoxicy: erm, is that the reason for the hang???
<bluefoxicy> pitti:  apparently the only thing it's doing is repetedly iterating through all locales looking for dpkg.mo; nothing else is happening at all
<seb128> fabbione: that's a real mess, thanks to libtool ...
<bluefoxicy> however I'm guessing on faith that maybe the other processes forked and aren't straced?
<lamont> seb128: the build-deps not getting updated mean that buildd's running through the whole lot at once hit b0rkage
<pitti> bluefoxicy: it does these iterations for every string to be translated
<seb128> lamont: that's bad
<fabbione> seb128: couldn't you build-conflict or something?
<pitti> bluefoxicy: after preview I will probably upload a new libc which caches result
<pitti> bluefoxicy: s
<bluefoxicy>  strace dpkg --configure -a 2>&1 | grep -v "locale"
<seb128> fabbione, lamont: we could libgnomevfs2-dev conflicts on libhowl-dev ?
<bluefoxicy> ok it's doing a brk() every few seconds, must be something else.
<fabbione> seb128: if that's enough, i don't see why not
<seb128> fabbione: the current libgnomevfs2-dev .la file has a mention to howl on sparc ?
<lamont> that'd fix the libgnomevfs2-dev build, but maybe not others?
* lamont dunno
<bluefoxicy> pitti:  I just can't see acpid or gnome2-common flicking the disk light once every 10-15 seconds (I have mldonkey running, that's probably the disk access), and taking >5 minutes to install, maybe I'm just impatient?
<fabbione> dpkg -c libgnomevfs2-dev_2.9.91-0ubuntu1_sparc.deb | grep howl | wc -l
<fabbione> 0
<fabbione> seb128: ^^
<pitti> bluefoxicy: hmm, no idea
* bluefoxicy decides to leave Setting up libgnomevfs2-common (2.10.0-0ubuntu1) for about 15 minutes to confirm that this isn't just him being impatient; after all this is a 64 bit system, 15 minutes counts as several orders of magnitude of overkill ;)
<seb128> fabbione: no, "grep howl  /usr/lib/libgnomevfs-2.la"
<fabbione> ah hold on
<bluefoxicy> (every time I run dpkg --configure -a it switches which is first, gnome2-common or libgnomevfs2-common)
<seb128> grep howl /usr/lib/*.la
<seb128> to have an idea on what you want to rebuild
<jdub> ogra: ping
<ogra> jdub: pong
<fabbione> Binary file libgnomevfs-2.a matches
<fabbione> libgnomevfs-2.la:dependency_libs=
<fabbione> seb128: so yes.. it doess
<tseng> is there an email/post somewhere explaining why all the howl stuff is being removed?
<jdub> ogra: did you have a new xss patch?
<ogra> only the one you already have, i wanted to work on that during preview
<seb128> fabbione: 2.9.92-0ubuntu1 ?
<jdub> ok
<fabbione> seb128: that's the last one i have..
<jdub> thanks
<Goshawk> fabbione, sei italiano?
<fabbione> seb128: as i wrote before the buildd died 18 days ago
<doko> mvo: could you validate the missing 'noauth' in peers/ppp0
<ogra> jdub: tell me if you need it earlier
<fabbione> Goshawk: yes i am italian
<seb128> fabbione: you have started the buildd again now, 2.9.92-0ubuntu1 build is ok ?
<mvo> doko: no, works for me :(
<fabbione> seb128: it's in the queue
<seb128> start by it
<fabbione> seb128: i can build it manually if you want me
<fabbione> seb128: there are tons of other packages before it
<seb128> that's the first to change
<seb128> once you have change it other one will ftbfs if they are not built in the right order
<jdub> ogra: would be nice to have it for preview, but that's ok
<seb128> ups
<seb128> once you have changed it, the other ones will ftbfs if they are not built in the right order
<ogra> jdub: lets see how hwdb-client comes along, probably i can send you a last minute patch....
<jdub> ogra: hwdb-client is waaaaay more important :)
<ogra> sure :)
<fabbione> seb128: ok thanks
<jdub> waaaaay like curds and wheeeeeey
<seb128> np
<fabbione> AHHHHHH
<fabbione> i know why the sparcbuildd died!
* fabbione kicks sun's OBP!
<pitti> fabbione: you didn't give him enough food for two weeks? :-)
<zul> bwahaha
<fabbione> pitti: ahaha 
<fabbione> ssh sparctamagochi -l buildd
<fabbione> ops
<fabbione> ;)
<mdz> fabbione: sparc has a LOT of catching up to do
<fabbione> mdz: i know!
<fabbione> i am working on it
<fabbione> it died and i just understood wht
<fabbione> why
<fabbione> i forgot to set in the OBP: do not die if the serial machine connected on the other side does not responde = true
<pitti> lamont: here?
<bluefoxicy> it's still setting up libgnomevfs2-common
<bluefoxicy> so yeah, I think it's broken.
<bluefoxicy> it set up a few other packages.
<fabbione> seb128: i am going to build 2.10 directly.. 2.9.92 is already out of my cache/mirror
<lamont> pitti: yes
<seb128> k
<seb128> start by gnome-vfs2
<seb128> libgnome
<bluefoxicy> this is on x86 btw, I'm on an amd64 box but running a 32 bit system for some odd reason (I was using xen)
<seb128> libbonoboui
<seb128> libgnome
<seb128> and be sure to have the new libgnomevfs2-dev with howl in the .la 
<wasabi_> isn't howl being removed?
<seb128> s/with/without/
<wasabi_> k
* pitti curses at perl's build system
<pitti> anybody out there who ever built perl?
* infinity raises his hand tentatively.
<pitti> infinity: 
<pitti> autosplit_lib_modules(@ARGV)' lib/*.pm
<pitti> Errno architecture (i386-linux-thread-multi-2.6.8.1) does not match executable architecture (i386-linux-thread-multi-2.6.10-4-k7) at /usr/lib/perl/5.8/Errno.pm line 11.
<pitti> Compilation failed in require at lib/File/Path.pm line 166.
<pitti> infinity: any idea?
<pitti> infinity: this even happens in a clean pbuilder
<infinity> No left over files from a previous build?
<infinity> Dirty source package, maybe?
<infinity> Otherwise, I'm as lost as you.  That's a new one.
<infinity> Time to get your grep on, I guess.
<pitti> infinity: okay, thanks
<pitti> infinity: yes, fresh source package
<infinity> Tahnking people for not being helpful is a novel approach. :)
<pitti> infinity: first, I directly applied my patch
<thom> infinity: he's just added you to the list of people to bully into doing security work
<mdz> pitti: did you do the patch/unpatch dance?
<pitti> infinity: then I even added it to debian/patches and patches-applied (strange build system9
<pitti> mdz: oh, that's new?
<pitti> mdz: as I said, strange build system...
<pitti> HAH
<mdz> pitti: the last time I built perl, you had to do "debian/rules unpatch patch" to get everything into the right state
<mdz> after adding a patch
<pitti> mdz: now I tried to build the pristine source package from Debian
<pitti> mdz: still the same bug
* pitti cries
<mdz> ick
<pitti> mdz: I tried this on warty and hoary, on two computers
<mdz> the kernel version number should NOT be in that string
<mdz> hmm
<mdz> mizar:[/tmp]  perl -MConfig -e 'print "$Config{'archname'}-$Config{'osvers'}\n";'
<mdz> i386-linux-thread-multi-2.6.8.1
<mdz> pitti: where do you get i386-linux-thread-multi-2.6.10-4-k7?
<mdz> is that from Errno.pm in the build tree?
<pitti> mdz: it's not even in the source package
<pitti> just Errno.t
* pitti pinged bod in #d-devel
<pitti> ah
<pitti> ./ext/Errno/Errno_pm.PL
<pitti> use Config;
<pitti> use strict;
<pitti> "\$Config{'archname'}-\$Config{'osvers'}" eq
<pitti> "$Config{'archname'}-$Config{'osvers'}" or
<pitti>         die "Errno architecture ($Config{'archname'}-$Config{'osvers'}) does not match executable architecture (\$Config{'archname'}-\$Config{'osvers'})";
<dholbach> seb128: have glibmm2.6.1 ready on http://ubuntu.gplan.info/mm
<lamont> mdz: any plans to burn new livecd rootfs images in the next hour or so?
<pitti> What the hell should this do?
<seb128> dholbach: k, thanks
<dholbach> seb128: cool
* lamont decides that's a 'no' from mdz... :-)
<tseng> jdub: see that post? inotify backend doesnt support poll atm
<jdub> yeah
<tseng> jdub: the code in gam_dnotify.c for poll is obvious
<tseng> i wonder if copying it over helps
<mdz> lamont: none
<mdz> pitti: that's very weird
<pitti> mdz: hmm, I can just toss it at the hoary buildd and see what happens there, but actually this is not really a satisfying solution...
<mdz> pitti: was bod able to help you?
<pitti> mdz: he did not reply, he's probably asleep
<tseng> hm right.. poll isnt called in functions that have counterparts in gam_inotify
<pitti> mdz: last message from 6 hours ago
<pitti> mdz: I think I defer this until tomorrow
<tseng> jdub: would it be smart to maybe disable inotify backend for gamin?
<tseng> or leave it since we have it off in the kernel
<tseng> and we wont be getting beagle this time around
<infinity> pitti : If it's still bugging you tomorrow and I;m around, delegate it my way.
* infinity -> bed.
<mdz> tseng: .since it seems to fall back gracefully, I think we should leave it enabled
<pitti> infinity: okay, I'll do :-) Sleep well
<mdz> it's possible that we'll enable inotify after preview, if the testing continues to go well
<fabbione> hmmmm
<fabbione> after a dist-upgrade my machine is turtle slow
<tseng> mdz: well, my point is that that will cause what looks to the user like a regression in gamin
<mdz> tseng: how so?
<tseng> mdz: are you familiar with the bug where automounted devices arent shown in drivemount-applet or nautilus on mount?
<tseng> it was solved by switching /media/* to use polling in gamin
<tseng> which isnt supported by the inotify backend.
<jdub> mdz: the "gamin doesn't fully implement inotify" bug is still relevant
<mdz> so either we do something about that, or just stick with dnotify
<tseng> right.
<pitti> *sigh* dnotify sucks...
<jdub> tseng: daniel is DV on #gnome-hackers (gimpnet)
<tseng> ok
<jdub> tseng: dunno where john hangs out, but would be very useful to get in touch with him
<jdub> tseng: doing anything for hoary will be hacky
<tseng> yes
<jdub> but post-hoary, it needs refactoring so less stuff is dumped into the backends
<dholbach> i'm off... see you later
<jdub> later dholbach 
<dholbach> bye jdub 
<tseng> yep as I just posted with the current status of the server backends, its beyond my skills to produce a patch
<tseng> if no one else is interested, its definately post-hoary.. but leaves the question of what to do with inotify
* sivang amazes by the rate the new gnome is flowing in 
<jdub> tseng: current decision is to keep it in, but off by default
<tseng> which is workable
<jdub> it means rml will not mate with me
<jdub> but there's always next year's season
<tseng> because of this "issue" i'd have to suggest it stays off after preview
<tseng> its not major or anything, but its a user visible regression
<jdub> yeah
<fabbione> seb128: ok i confirm that gnome-vfs2 2.10 does not have the howl stuff now (sparc)
<fabbione> seb128: the rest will just build in the right order
<seb128> cool
<fabbione> seb128: or i will kick it back when needed
<seb128> if it's not in the right order it'll ftbfs
<seb128> need to kick
<pitti> seb128: you rock
<pitti> seb128: (and you are killing the buildds :-) )
<seb128> thanks :)
<seb128> (he he)
<Goshawk> mdz, can i talk with you in private
<Goshawk> ?
<mdz> Goshawk: about what?
<Goshawk> usplash
<mdz> usplash discussion is on-topic for this channel; I'd prefer to have the conversation here
<Goshawk> ok
<Goshawk> how do you say USplash has been officially deferred to the
<Goshawk> next release (Ubuntu 5.10, due in October). if there is nothing about that?
<Goshawk> i worked with sladen
<mdz> I announced this in the release update, for which I provided a URL
<mdz> and it is also noted on HoaryGoals
<Goshawk> and there is not much more than a Proof of concept tarball
<mdz> and sladen and I discussed it at FeatureFReeze
<Goshawk> yes... but there is nothing....
<mdz> I don't understand your point
<Goshawk> there is not "any" source code of that, only the work that i've done (tht you readed on the forum)
<mdz> the fact that it hasn't been developed yet is the reason why it won't be part of the Hoary release
<Goshawk> but... there is a but
<Goshawk> there is an "alpha" for developers about a "usermode splash" i need the sladen agree to call it "usplash"
<mdz> I am having difficulty understanding you
<mdz> it sounds like you are saying that you have developed an implementation, and would like to call it usplash
<Goshawk> yep...
<mdz> were you aware of the Ubuntu project when you chose this name?
<Goshawk> the thing that is developed works at 100% on my pc
<Goshawk> it started on December.. in that period i was waiting the ubuntu sources of usplash from sladen, and when he said that nothing was deleped i started devloping this idea
<Goshawk> but now  it works away from the main idea
<Goshawk> all the stuff is made by a single utility
<mdz> where can I download it?
<Goshawk> http://81.113.230.186/kalatlug/phpwiki/index.php/UsplashHowDoesItWork
<Goshawk> but wait
<Goshawk> i've solved a bug just now
<Goshawk> and i'm compilig the alpha2
<Goshawk> if you want i can make a video of my boot process
<Goshawk> in that page is written how it works
<mdz> there is no source code there
<Goshawk> and as you could say.. it differs from the main idea
<Goshawk> there is the svn for sources
<Goshawk> the server is linked at that page
<Goshawk> svn co http://81.113.230.186/svn/bootsplash/v2
<Goshawk> the svn is already updated
<Goshawk> mdz, the best news is that
<mdz> pitti: perl builds fine for me on Hoary (no chroot, no pbuilder)
<Goshawk> i treat fd0 as a file
<pitti> mdz: *sigh*
<pitti> mdz: thanks for trying, though
<mdz> version 5.8.4-6
<Goshawk> not a mmaped memory (as the usplash proof of concept treats)
<mdz> fd0?  you mean fb0?
<Goshawk> yep,, excuse me
<pitti> mdz: I tried -7 from incoming and -6ubuntu1 (with an extracted security patch)
<Keybuk> heh, aww; I was hoping for boot symphony on 3.5" floppy
<Goshawk> and.. there is a problem in the URL, it is : svn co http://81.113.230.186/svn/bootsplash/
<Goshawk> without the v2
<Goshawk> mdz, it will be not ready to work on hoary but we can develop it
<mdz> Goshawk: yes, this looks very interesting.  I am confused about what you were asking me originally, however
<mdz> are you proposing that we use your work as the basis for the usplash feature in Ubuntu?
<Goshawk> yes.. mainly that
<mdz> ok, that was a very strange way of asking :-)
<sabdfl> seb128: you superstar. wonderful to see 2.10 coming in. thank you!
<mdz> Goshawk: could you send a message to the ubuntu-devel mailing list about this?
<kent> Goshawk, have you made a new version of it? I have some issues with the one i tried last time. It sort of works, but the graphics is strange.. its like it cant use that resolution or something. Its very hard for me to explain,  I can sort of see a scrambled picture of the logo when it boots.. 
<seb128> sabdfl: thanks :)
<pitti> sabdfl: good to have 128 Sebs to do uploads :-)
<Goshawk> mdz, yep
<koke> seb128: just one comment, look at the intltool-update.in file in the gnome 2.10 tarballs
<mdz> Goshawk: I won't have much time to look at this due to the Hoary release, but I would like to start a discussion about it for Hoary+1
<koke> I've just looked at ftp.gnome.org's tarballs and they are "clean"
<Goshawk> kent, yep.. a lot of "ubuntu" lines in black an white
<sabdfl> breezy!
<seb128> koke: ?
<Goshawk> mdz, me too... the problem was about that msg taht you are reading
<seb128> koke: what do you call "clean" ?
<koke> ok
<seb128> ?
<seb128> waht are you trying to say ?
<seb128> you are not clear
<koke> I've tested control-center and intltool-update looks for xgettext at /usr/bin
<mdz> Goshawk: "something is moving in the underground" was not a very clear way to say "I have been working on an alternative implementation of usplash" :-)
<koke> whith, in example, apt-get source gnome-desktop in hoary
<Goshawk> mdz, since for  "something is moving underground" is not for hoary.. but usplash code 
<koke> I get an intltool-update looking for gettext in /opt/gnome2
<koke> nautilus-sendto in /mnt/data/gnome
<koke> ...
<mdz> Goshawk: and the last message on that forum says "Unless you install a new kernel, or have to move, or there's a power outage, or you install new hardware, or..."
<mdz> Goshawk: so you can understand my confusion, I think :-)
<Goshawk> yep.. i'm confused as you ^__^
<Goshawk> thanks for all mdz 
<Mithrandir> mdz: what will be the procedure for uploads after preview is out?
<seb128> koke: 
<seb128> $ grep "/opt" gnome-desktop-2.10.0/intltool-update.in
<seb128> $
<Goshawk> gonna open a ubuntu-devel topic
<koke> mm ok
<trulux> heya
<koke> koke@ababol ~/Devel/ubuntu/gnome-desktop-2.10.0 $ grep xgettext intltool-update.in | head -1
<koke>     my $XGETTEXT = $ENV{"XGETTEXT"} || "/gnome/usr/bin/xgettext";
<mdz> Goshawk: great, thanks
<koke> my memory failed :D
<mdz> Mithrandir: we'll reopen for general bugfixing initially, basically FeatureFreeze process
<Mithrandir> mdz: ok
<seb128> koke: http://ftp.gnome.org/pub/GNOME/sources/gnome-desktop/2.10/gnome-desktop-2.10.0.tar.bz2
<seb128> koke:     my $XGETTEXT = $ENV{"XGETTEXT"} || "/gnome/usr/bin/xgettext";
<seb128> koke: how is the upstream tarball "clean" ?
<koke> ok, I haven't seen them all.
<koke> I've randomly chosen the bad from ubuntu and the good from gnome :(
<seb128> you are trying to say than packages have issue ? or do you have issues with upstream tarballs ?
<koke> nop, it seems the problem is at upstream
<seb128> k
<Kamion> Mithrandir: ok, I think I just suck, I was trying to SUBST into Default:, which debconf-devel(7) explicitly says won't work
<mdz> elmo: are you around?  when do you head home?
<elmo> mdz: in about 4.5 hours
<mdz> elmo: can you do some germinate/archive resync before then?
* OddAbe19 is away: Gone... Like the French in a battle.
<elmo> mdz: updated sync.txt - did I miss approval for any on that list?
<mdz> elmo: dbus-qt-1-dev
<elmo> ok, done too
<mdz> it is possible that KDE 3.4 will require a few more
<mdz> I'm trying to get a list from #kubuntu-devel now
<jordi> mdz: moo
<mdz> jordi: baaa
<elmo> Kamion: sdf got demoted - if you care; sdf-doc is still seeded tho...
<lamont> fabbione: you around?
<mdz> pitti: did you and daniels resolve the german keymap issue?
<pitti> mdz: not yet, I just sent him some debug output
<mdz> it would be nice to be able to fix that for preview
<elmo> pitti: done
<pitti> elmo: thanks
<pitti> mdz: indeed, it's pretty ugly for the live CD
<Kamion> elmo: not especially :)
<mdz> elmo: what's pulling in hevea?  it's not in Kamion's germinate output
<mdz> sparc?
<Kamion> we could unseed sdf-doc
<elmo> mdz: yapps2 b-d
<elmo> can't see how that could be sparc
<lamont> fabbione: has your buildd tried gmime2.1 yet?
<elmo> hevea                                             | hevea                           | yapps2 (Build-Depend)                           
<elmo> yapps2                                            | yapps2                          | keymapper (Build-Depend)                     
<mdz> but the rdepends tree ends there
<mdz> hmm, incomplete rdepends from germinate then
<mdz> elmo: hevea can be promoted
<Kamion> it doesn't follow back through reverse build-deps, I'm not entirely sure why
<Kamion> it would be useful if it did
<mdz> we already have the crazy ocaml stuff in main
<elmo> mdz: I put my 'ALL' in the same dir, FWIW
<mdz> thanks
<elmo> and promoted hevea
<Mithrandir> Kamion: oh, that sucks.
<Kamion> Mithrandir: (I'm fixing it)
<Kamion> just attempting to test
<elmo> promoting libkipi source as obvious
<elmo> IMO libkipi0-dev would be too - i.e. we already have libkipi
<mdz> pitti: do you have a moment to review t1utils?  it seems to be another part of the hpoj build-depends mess
<mdz> elmo: agreed
<pitti> mdz: yes, I'll do that
<elmo> done, updated sync.txt
<mdz> elmo: python2.4-dictdlib is fine
<pitti> mdz: looks fine to me (and, in fact, useful :-) )
<mdz> elmo: and t1utils (thanks, pitti)
<pitti> mdz: btw, do you think we can keep polypaudio for Hoary?
<mdz> pitti: it is working well for me, but jdub seems to feel that we should revert to esound
<pitti> mdz: hmm, a pity, I spent over 4 hours to get it fixed :-/
<Kamion> didn't jdub say that before it got fixed?
<pitti> yes
<pitti> but I don't know his opinion now
<pitti> it's now working fine both on my i386 and my ppc
<ogra> i think there was no clear statement after the fix from him
* pitti -> food
<elmo> mdz: both done
<mdz> Kamion: he was saying that as recently as yesterday
<mdz> pitti: can you review sqlite3 for kubuntu?
<mdz> elmo: if scribus doesn't depend on sqlite3, it can go in as well
<mdz> doesn't look like it does
<mdz> seb128: wow, lots of good stuff for totem
<tseng> has seb set a record yet for most consecutive uploads?
<seb128> mdz: yep
<lamont> mdz: looking for input on #6232 (installing postfix won't add an alias for root to an existing /etc/aliases)
<seb128> mdz: this one is impressive too: http://ftp.gnome.org/pub/GNOME/sources/gst-plugins/0.8/gst-plugins-0.8.8.news
<elmo> mdz: done
<trukulo> ogra, you there?
<ogra> yup
<trukulo> nothing, i was going to tell you about uploading clearworks engine gtk2 to hoary... but it's uploaded  :)
<trukulo> forget it
* lamont wonders if postfix's postinst should treat the absense of a root alias in /etc/aliases as sufficient cause for it to install one (if alias_database == hash:/etc/aliases, that is...)
<elmo> pitti: DUDE
<elmo> why are you rebuilding stuff that's in freaking universe?
<Mithrandir> lamont: possibly on initial install, not on upgrades.
<lamont> Mithrandir: right
<Mithrandir> lamont: the right solution is of course to have an /etc/aliases.d directory which is used to generate /var/lib/aliases.db which is used by different mailers.
<Mithrandir> and stuff in /etc/aliases.d be conffiles)
<Mithrandir> s/\)//
* lamont vomits on Mithrandir's keyboard
<lamont> it's a file with a fixed format, and a long history...
<Mithrandir> lamont: seriously, how would you else do it?
<mxpxpod> does gnome-volume-control not work for anyone else on ppc?
<Mithrandir> lamont: how do you handle the case of an user changing from exim4 to postfix and having removed the root alias from /etc/aliases?
<mxpxpod> wait, nevermind... it's now working
<lamont> Mithrandir: well, the issue is that root shouldn't go to it's own mailbox, since no sane individual actually runs an MUA as root....
<lamont> that and postfix delivers root mail as nobody
<mvo> ping Mithrandir 
<Mithrandir> mvo: no need to ping me when I'm active in the channel :)
<mvo> Mithrandir: sorry, it was this stupid xchat completion
<mvo> Mitario: ping
<Mithrandir> lamont: imagine /root/.forward or using procmail to do Stuff to root's mail.
<mvo> Mithrandir: see :) it just _always_ get's the nicks wrong :)
<Kamion> mdz: it only got fixed this morning though :)
<Mithrandir> mvo: it's allowed to actually _read_ what you're typing. :)
<lamont> Mithrandir: right.  and postfix will happy toss root's mail to procmail. with an euid=ruid=nobody
<Mithrandir> that can be fine to do.
<Mithrandir> lamont: if you modify files in /etc you might very easily be overwriting local changes.  That's bad.
<lamont> ah, so you're saying that if ~root/.forward exists, then it shouldn't create the alias either?
<Mithrandir> I'm just saying that's a possible use case and there's no real way to do what you want to do without using a directory which is aggregated.
<Mithrandir> no matter whether it's ugly or not
<mvo> Mithrandir: heh :) sometimes I type faster than I think (well, actually most of the time ;)
<trukulo> ogra, new graveman doesn't discover devices
<ogra> hmm, it does here
<trukulo> ogra, it doesn't if device is mounted
<trukulo> if not, works well
<ogra> oh
<trukulo> interesting
<trukulo> problems with hal, it seems
<ogra> trukulo, do you know if he switched to hal
<trukulo> i don't think so , because in debian we don't use it
<ogra> i suggested that to him and he said hw would try....
<ogra> trukulo: how does n-c-b work then in debian ? afaik it uses hal the same way
<trukulo> ogra, if it's installed yes
<mdz> seb128: wow, that's great too
<trukulo> but you can use gnome without hal
<mdz> the gstreamer and totem guys have been busy
<ogra> trukulo: i mustadmint that i didnt try the detection with a mountd disc....
<trukulo> ogra, i did unconsciently, you know
<trukulo> and i see the problem
* mvo needs to leave for ~1,5h
<Kamion> Mithrandir: ok, choose-mirror 1.06ubuntu7 really fixes it
<Mithrandir> Kamion: cool, thanks.  We worked around it, though.
<Kamion> Mithrandir: I'm guessing preseeding mirror/http/mirror and mirror/http/directory would have worked around it
<Mithrandir> possibly, yes
<trukulo> fabbione, are you there? how can i upgrade from linux-2.6.10-X to last version?
<trukulo> i mean, 2.6.10-25
<fabbione> trukulo: the same way you did up till now :-)
<mdz> Kamion: are you feeling pretty confident about the base-installer kernel stuff now?
<pitti> elmo: I'm back, what's wrong?
<trukulo> fabbione, aptitude dist-upgrade ?
<elmo> pitti: muine is in your list of "things with which to make mirrors regret having ever heard of Ubuntu" and it's not in main
<Treenaks> elmo: it's huge, uploaded often and universe?
<pitti> elmo: you mean in http://people.ubuntu.com/~pitti/unstripped-hoary-main.txt ? It's not there
<trukulo> fabbione, forget it, i'll read on google
<jdub> finally, the gst-plugins and totem releases we've been waiting for!
<jdub> hooray for upstream!
<jdub> hooray for seb!
<jdub> but mostly hooray for seb ;)
<elmo> pitti: lamont pointed me at http://people.ubuntu.com/~pitti/hoary-main-gettext.txt 
<ogra> yay+
<mdz> elmo: kubuntu is going to need at least one new package in main (not in Ubuntu at all yet)
<pitti> elmo: ah, for this one; hmm, no idea how it got there...
<mdz> pitti: sqlite3 seems fairly sane; do you agree?
<pitti> mdz: was at dinner, just returned. I take a look now
<mdz> pitti: thanks
* OddAbe19 is away: Gone... Like the French in a battle.
<elmo> pitti: tomboy too
<pitti> elmo: I will update the list ASAP
<elmo> pitti: in the mean time, I've installed the build-depends in both i386 and amd64 chroots on concordia
<pitti> elmo: cool, thanks
<pitti> elmo: including pkgstriptranslations?
<elmo> mdz: need as in need before I fly or ?
<pitti> elmo: I can install this locally if necessary
<dholbach> seb128: uploaded libglademm2.4 (http://ubuntu.gplan.info/mm)
<seb128> dholbach: k
<mxpxpod> fabbione: ping
<mdz> elmo: if at all possible
<elmo> pitti: installed
<fabbione> mxpxpod: pong
<mxpxpod> fabbione: back from the honeymoon?
<pitti> elmo: can you please enable it in /etc/pkgstriptranslations.conf?
<elmo> uh
<elmo> what's that do?
<fabbione> mxpxpod: yes :-(
<pitti> elmo: if you don't want to do this, then I install pkgstriptranslations in my $HOME/Bin
<mxpxpod> fabbione: how was it?
<pitti> elmo: it was decided to disable it by default, so that users don't mess up their builds if they accidentially install it
<pitti> elmo: I think $HOME/bin is actually a good idea, then other folks can still use the dchroots for their purposes
<fabbione> mxpxpod: great, thanks
<tseng> wb fabbione
<mxpxpod> fabbione: how long will it be until we get 2.6.11 into universe (not the -rc's)
<fabbione> mxpxpod: a few days.. i need to catch up on a lot of things and .11 is not high priority
<mxpxpod> fabbione: that's cool... just wanted an eta
<fabbione> but i will try my best :-)
<mxpxpod> I'd like to try out .11 asap because of the ppc changes
<pitti> mdz: sqlite3 is thumbs up (debs and packaging)
<mxpxpod> fabbione: awesome... btw, congrats on the marriage
<fabbione> mxpxpod: most of the ppc changes have been backported to .10 afaics
<mdz> pitti: thanks
<fabbione> mxpxpod: eheh thanks
<mxpxpod> fabbione: yeah, I've tried the 2.6.10 changes (and the 2.6.10 ubuntu kernel) and it freezes
<fabbione> mxpxpod: did you report the problem?
<mxpxpod> fabbione: nah, didn't have a connection at the time
<fabbione> well.. now you do :-)
<fabbione> please report it in details
<mxpxpod> fabbione: I have to get back to work in a minute
<mxpxpod> fabbione: I'll do it after work
<fabbione> ok
<mxpxpod> fabbione: what do you mean by, "in details"
<fabbione> with all possible details
<fabbione> dmesg
<fabbione> logs
<mxpxpod> I don't know many details except that it froze on wakeup
<amu> elmo: now it's urgent, please sync libassuan-dev asap
<fabbione> is it reproducible?
<fabbione> or it happened only once...
<fabbione> and so on...
<mxpxpod> fabbione: yeah, it did it twice
<elmo> amu: source pkg names for sync requests, pls
<mxpxpod> fabbione: ok, will do
<Kamion> mdz: can I upload to fix that mdadm fail message?
<mx|gone> fabbione: time to get back to work :)
<Kamion> mdz: I've tested my base-installer changes of today and I'm pretty sure they're right
<mdz> Kamion: yes
<amu> elmo: libassuan
<elmo> [Updating]  libassuan (0.6.8-1 [ubuntu]  < 0.6.9-2 [debian] )
<elmo> this is presumably going to main if it's needed for kubuntu ... ?
<elmo> if so, new upstream version okay, mdz?
<mdz> it's in universe presently
<mdz> so yes, fine
<mdz> elmo: this is one of the packages which will need to move into main when 3.4 is uploaded, as I understand it
* elmo makes note in file "how to bypass UVF 101"
<Kamion> elmo: please move GNOME to universe, kthxbye
<elmo> Kamion: done
<trukulo> Kamion, heh
* dholbach helps out seb128 before GNOME gets moved back to main. ;-)
<Kamion> that'll be my contribution to tonight's mirror hit
<amu> Kamion: hehe
<Kamion> tseng: record> I think doko's probably still out in front with one of his zope or python upload extravaganzas
<tseng> heh, i forgot about those
<Kamion> the last of those was 26 consecutive
<Kamion> seb's managed more consecutive uploads than this before, though :)
<Kamion>      48 From: Matthias Klose <m@klose.in-berlin.de>
<Kamion> after some auto-merges from Scott and another few entries by doko, seb's next with 18
<Kamion> at least in the hoary cycle
<Keybuk> heh, I win :p
<thom> Keybuk: you've not *done* any of those uploads, though
<Mithrandir> doko?
<Keybuk> right food time
<Keybuk> l8r 
<doko> Mithrandir: I'm working on automating these ...
<Mithrandir> doko: ia32-libs on ia64 needs to provide libgcc1 for ia32-libs-openoffice.org, but the latter has a versioned dependency.  Any thoughts?
<crimsun_> elmo, has my email address been added to the white-list for uploads, and has my GPG key been added to the keyring?
<tseng> are we going to pick up the memory optimization patches after preview?
<tseng> for gnome that is
<doko> Mithrandir: hmm, not really ... maybe I'll build a cross compiler for hoary+1, just building the 32 bit libgcc1 ...
<Mithrandir> doko: I'm hoping to have some multiarch stuff in hoary+1 which should be enough for that.
<dholbach> elmo: could you please sync gtranslator from sid, if you find the time?
<doko> mdz: ok to upload gsfonts to fix #3138 (bold Nimbus Roman font isn't displayed)
<doko> ?
<mdz> doko: ooh, yes please
<sabdfl> doko: lovely!
<doko> long search, small fix
<thom> mdz: ok to upload firefox 1.0.1? (security fixes, etc)
<dholbach> thom: yes! go! go! go! :-)
<pitti> thom: ++
<mdz> thom: hmmm
<mdz> I'm not sure that's wise for preview
<pitti> pleeeeease :-)
<pitti> 1.0.1-1ubuntu2reverted-to-1.0.0 ... :-)
* thom smacks pitti :-)
<dholbach> hehe
<mdz> it's certainly fine for final, I'm just unsure about preview
<mdz> we have only two days to sort out any issues
* T-Bone eagerly awaits the ia32-libs stuff to mark ooffice as "we have it" on ia64, and see if that also fixes the firefox locales issue
<mdz> thom: what's your risk assessment?
<Mithrandir> doko: do you have any good ideas on how to solve the problem for ia64 for hoary?
<Mithrandir> I have one idea, which is to have ia32-libs generate an lib32gcc1 package.. but that's _ugly_
<mdz> thom: can you mail me a debdiff?
<thom> mdz: the debdiff is *big*
<mdz> thom: if your response is "omfg no, it's 50 megs"...
<mdz> then that's an indication that maybe we should be cautious with it :-)
<thom> mdz: because a tonne of patches have gone from me cherry picking to upstream
<thom> oh, real debdiff sorry
<thom> hang on
<pitti> mdz: okay for you to upload a lesstif1-1 security fix? I'm asking because the fix for CAN-2004-0914 is very big
<pitti> mdz: however, it is well tested from Warty and X.org
<mdz> pitti: how severe is the vulnerability?
<pitti> mdz: the usual thing, buffer overflow with malicious xpm files; no server applications using it, though (-> no priv escalation)
<doko> mithrandir: let me build a cross compiler, and see, how the cross compiled libgcc 1 is looking
<elmo> lesstif just got demoted
<Mithrandir> doko: ok
<elmo> I think
<pitti> elmo: lesstif1 (thaaaaaaanks!!!), but not lesstif2
<mdz> I was just about to say
<mdz> what is it doing in main?
<thom> sweet mother of god. debdiff is trying to extract 2 firefox sourcetrees into /tmp
<mdz> so yes, go ahead
* thom changes his TMPDIR
<pitti> mdz: the fixes affect lesstif2, too
<pitti> mdz: I don't understand why we put lesstif1 into main for warty, too; now it's causing me headaches :-/
<lamont> mdz: I'll plan on uploading 6232 after the preview, unless you want it before
<amu> pitti: could i delay kdegraphics (xpdf) a bit? is it urgent? is tomorrow fine for you?   
<elmo> vim??
<pitti> amu: depends on whether mdz wants it for the preview
<haggai> amu: I can look at it
<elmo> (that's why we have lesstif apparently)
<elmo> that and xpdf
<mdz> pitti, amu: what is the question?
<pitti> elmo: vim does not need lesstif1, neither does xpdf (that uses lesstif2)
<mdz> elmo: hmm, so when we move to gpdf, we can get rid of it
<mdz> pitti: he was talking about lesstif2
<mdz> it would be nice to demote lesstif2 to universe too :-)
<pitti> right :-)
<pitti> still, why vim?
* dholbach creates MOTUGhostTrain
<mdz> vim-lesstif
<mdz> for the ugliest editor possible
<pitti> ah, build dependency
<elmo> vim-will-build-frontend-for-food
<pitti> D'oh
<thom> mdz:  416 files changed, 5298 insertions(+), 3016 deletions(-)
<bluefoxicy> uh
<pitti> mdz: I'm sure that we can drop vim-lesstif for hoary+1 :-)
<lamont> fabbione: around?
* bluefoxicy tries to get vim highlighting like it did in gentoo
<fabbione> lamont: yes
<ajmitch> dholbach: ghost train?
* pitti hands bluefoxicy a neat .vimrc
<lamont> is the sparc wanna-build --list=all output wgetable somewhere?
<pitti> bluefoxicy: what's wrong with the Ubuntu version?
<lamont> hrm.. I suppose I could just login and check,.....
<sivang> pitti: there are patches to make cupsys and g-c-l use dbus and listen for printer hotplug events, what do you think about including them to make new printers automatically appear (_local_ ones) when plugged into the computer?
<fabbione> lamont: no, but i can make it so in a sec :-)
<bluefoxicy> pitti:  in Gentoo, vim comes with something that makes everything colorful
<mdz> thom: gzip+mail?
<pitti> bluefoxicy: Ubuntu has that, too
<bluefoxicy> like if you edit a .c file, comments are dark blue, if statements and variable types are green, etc.
<pitti> bluefoxicy: :syntax enable
<thom> mdz: yup, doing so now
<dholbach> ajmitch: because of "<mdz> it would be nice to demote lesstif2 to universe too :-)"
<bluefoxicy> pitti:  Oh, it's in there but not on by default
<fabbione> lamont: do you need it constantly updated?
* bluefoxicy was looking for the package to install
<ajmitch> dholbach: ok, I must be missing some reference or something :)
<lamont> nah
<fabbione> ok
<lamont> actually just want to know if gmime2.1 built
<bluefoxicy> pitti:  thanks, added it to my .exrc
<fabbione> lamont: bbl.. dinner is ready
<pitti> mdz: lesstif successfully built, tested and ready to upload. now or after preview?
<lamont> bah. mono
<lamont> now I'm going to have to actually _figure_out_ what changed and such. :-(
<tseng> whats up lamont 
<mdz> pitti: if you test xpdf first, yes
<pitti> mdz: already tested :-)
<mdz> ok
<trukulo> one question: warty is iso-code-based and hoary utf8, isn't it?
<thom> mdz: the docshell changes are the fix for the window injection vuln and that's the biggest change
<Kamion> that's simplistic. You can use UTF-8 in Warty.
<Kamion> Warty's default for most languages is non-UTF-8, and Hoary's default is UTF-8.
<lamont> tseng: was looking at a bug that involved sparc and gmime2.1 (but not a gmime2.1 bug)
<lamont> gmime2.1 is currently ftbfs on hoary/sparc because mono-utils is missing.
<tseng> ah
<lamont> so I get to go really look at what's going on.
<mdz> window injection doesn't scare me much
<lamont> so much for the trivial 'doesn't apply to hoary' check
<mdz> firefox churn before preview scares me more :-)
<thom> heh, fair enough
<thom> i'll hold it and mozilla till thursday then 
<lamont> mdz: you're only saying that because of the firefox/warty cluster.
<trukulo> Kamion, yes, i ask 'by default'
<trukulo> will be any script that automatically change iso codes from warty to hoary when it's released?
<trukulo> i mean, not having to do by hand 'sudo dpkg-reconfigure locales'
<mdz> lamont: fool me once, shame on you...
<lamont> mds: "fool me 27 times....."
<mdz> md "rigid and boring" z
* lamont misses 3rd rock
<thom> mdz: *giggle* at zsh advocacy in the bash completion thread
<T-Bone> lamont: heh, you betcha :)
<mdz> thom: do you think it's doable to have auto-torrent-love starting with preview?
<trukulo> and does tty* can use utf8 ?
<mdz> thom: how badly does it screw downloaders when the tracker gets restarted?
<thom> mdz: hardly at all, they just reconnect
<thom> mdz: i'm gonna take a hammer to it tomorrow and make sure it works
<mdz> great, thanks
<mdz> I expect that we'll be asking a lot of users to download the dailies following preview to test fixes; it'd be good to have torrents for them
<thom> sure
<LBM> ipw2200 module is quite outdated
<LBM> lot's of fixes
<LBM> ubuntu version is 0.19, latest release is 1.0.1
<zul> yes we know
<LBM> any plans about bumping the version?
<zul> yes after hoary is released
<LBM> :/
<LBM> well, okay
<mdz> LBM: 0.19 was current at the time our freeze began
<LBM> mdz: when did you freeze?
<mdz> LBM: early January
<mdz> 0.19 released December 20th
<LBM> mdz: i see, a shame
<LBM> lot's of resume related bugs fixed, right now
<mdz> 0.19 works pretty well for me, though it does occasionally get confused and log errors
<LBM> right now it's quite sensitive
<mdz> it's up to the kernel team whether they feel it would be safe to update it before the hoary release
<mdz> though we definitely won't be changing it for the preview release
<LBM> would be great
<T-Bone> i suppose we could have a look, but it will require testing
<T-Bone> *thorough* testing, that is
<LBM> i'm ready to help you out
<T-Bone> that's good news
<LBM> hand me some debs ;9
<T-Bone> heh. As mdz pointed out, you'll have to wait post preview freeze
<T-Bone> that is, nothing before next week
<LBM> sounds great
<LBM> and netapplet, any plans on that one?
<mdz> netapplet was a target for Hoary, but it just isn't ready
<mdz> post-Hoary we'll probably go for NetworkManager
<mdz> meanwhile, netapplet is available in universe
* lamont scratches his head at 6213..  damnedest fix I've ever seen
<LBM> i noticed that, yes
<fabbione> lamont: http://www.fabbione.net/sparc-list
<thom> lamont: what was the fix?
<lamont> -Files: /usr/share/doc/libxslt1-dev/html/*.html
<lamont> -Files: /usr/share/doc/libxslt1-dev/EXSLT/*.html
<lamont> -Files: /usr/share/doc/libxslt1-dev/EXSLT/html/*.html
<lamont> -Files: /usr/share/doc/libxslt1-dev/tutorial*/*.html
<lamont> + /usr/share/doc/libxslt1-dev/html/*.html
<lamont> + /usr/share/doc/libxslt1-dev/EXSLT/*.html
<lamont> + /usr/share/doc/libxslt1-dev/EXSLT/html/*.html
<lamont> + /usr/share/doc/libxslt1-dev/tutorial*/*.html
<lamont> which is to say, fix the input data instead of the actual segv-causing-source
<thom> meh
<sivang> hey mvo 
<mvo> hey sivang 
<dholbach> wb mvo
<lamont> thom: exactly
<sladen> abrelli: depends what for, Xen, UML, vserver have an overlapping feature set in someways, but shine in certain circumstances
<zul> later off to shovel snow whoope..
* lamont prepares to go fetch kidlets
<seb128> pitti: around ?
<pitti> seb128: yes
* dholbach hands seb128 an energy drink
<seb128> could you kick new language-packs ?
<pitti> seb128: I can, when is your upload rave finished=
<pitti> s/=/?/
<seb128> should be fine for today, that's why I'm asking
<pitti> seb128: I mean, the packages must be finished building
<seb128> I would like to take screenshot for the 2.10 french announce
<seb128> and I need working translations :p
<pitti> seb128: okay, this will certainly require some domain overrides
<pitti> seb128: and some packages produce more than one domain, I have to pick there
<pitti> seb128: are there still unbuilt packages?
<seb128> what do you call "domain" ?
<pitti> seb128: translation domain
* T-Bone will have a new efibootmgr to upload post-preview freeze
<seb128> apt-get wants to downgrade  gnome-system-monitor gpdf libglademm-2.4-1 libgtop2-5 libgtop2-dev
<pitti> seb128: /usr/share/locale/<lang>/LC_MESSAGES/<domain>.mo
<seb128> do I guess these ones for today, but that's good enough
<seb128> oh, k
<seb128> like gtk ? :)
<pitti> seb128: yes, gtk is the most prominent example
<seb128> so you just drop one of the domains ?
<pitti> ye
<pitti> s
<seb128> urg
<pitti> seb128: sorry :-(
<seb128> bah, probably not a big deal, but still ugly :)
<pitti> seb128: but I'm barely awake enough to kick new langpacks, I can't rewrite the scripts today any more
<seb128> apps have one domain so that's mostly fine
<seb128> pitti: don't bother, update them tomorrow, take some sleep now if you want
<seb128> I can take the screenshots tomorrow
<pitti> seb128: I start now, but will probably finish tomorrow
<seb128> k, thanks
<ogra> seb128: lots of nice traffic on hoary changes today, thanks.... :)
<seb128> thank you :)
<elmo> iz gnome build bot
<ogra> yay
<sivang> seb128: screenshots?
<sivang> seb128: ah, just read the backlog :)
<seb128> sivang: of what ?
<seb128> k
<pitti> seb128: people.ubuntu.com/~lamont/translations/20050307   -> lots of stuff :-)
<ogra> sivang: nah, its rather a daemon
<sivang> ogra: what?
<seb128> pitti: yeah, pretty nice packaging day :)
<ogra> sivang,  gnome build bot :)
<sivang> ogra: ah hehe
<ajmitch> seb128: you make our internet connections hurt today :)
<ogra> sivang, you know, it runs in the background and suddenly throws a hell of a lot of packages at you
* lamont bbl
<seb128> ajmitch: ah ah
<ogra> sivang, and its really mature (v128 already)
<sivang> seb128: btw, finished 2.10 ?
<seb128> nop
<sivang> seb128: ah ok, but was a bug bunch today :)
<sivang> s/bug/big/
<seb128> yeah
<seb128> tomorrow probably all the ximian stuff
<Amaranth> ximian stuff?
<sivang> seb128: all I can say, thank you for turning apt into my cvs frontend :)
<seb128> ;)
<jordi> tomorrow daf will take us to belfast
<jordi> OH YEAH
<jordi> Picadilly line, all the way to the Catholic area.
<haggai> lamont: mdz says I can ask you to add a dep-wait for me.  Amarok needs to dep-wait on kdebase 4:3.4.0-0pre1ubuntu2
<pitti> mdz: the perl failure is new to 5.8.4-7, bod experienced it, too
<Riddell> jordi: what are you doing in belfast?
<jordi> Riddell: I'm in London with the Rosetta dudes. But we'll take the tube to Belfast tomorrow.
<Riddell> jordi: tube to belfast eh?  that must be a new line on the underground
<jordi> Riddell: yeah dude! it's so great
<jordi> the other end takes you to Manchester, but I have no more time for Manchester (or liverpool)
<Riddell> jordi: but what's the crack in Belfast?  Going to add Ulster Scots?
<jordi> Riddell: there's lots of police there
<Riddell> jordi: well just don't take a black taxi, they're dodgey as anything
<Amaranth> wow
<Amaranth> i read about the new release of gstreamer plugins _after_ i already had them
<mdke> mplayer is in universe/multiverse now right? it is better to use the ubuntu version than the marillat ones?
<tseng> ubuntu is synced from marillat iirc
<trukulo> mdke, depend if you want things like w32codecs or dvdcss
<mdke> just mplayer pls
<trukulo> tseng, with support for w32codecs too ?
<mdke> i'm trying to make some sense of the restricted formats wiki
<tseng> well, mplayer supports w32codecs as soon as you add them
<tseng> they just arent in ubuntu
<trukulo> ah, ok
<tseng> xine can use them also
<mdke> tseng, so mplayer-*-ubuntu* will work with w32codecs?
<trukulo> so you can add it from marillat repository
<mdke> its not necessary to have mplayer-*-woody from marillat?
<HrdwrBoB> mdke: yes, the w32codecs just plonk windows files in s directory which mplayer reads
<HrdwrBoB> there's no actual libraries or anything
<mdke> HrdwrBoB, ok thanks.
<mdke> one more thing
<mdke> is it better to use the ubuntu mplayer build or the marillat/woody one?
<HrdwrBoB> not sure tbh
<HrdwrBoB> if you're using the marillat repository anyway
<lamont> haggai: note that pre1ubuntu1 was ftbfs...
<HrdwrBoB> put them both in
<HrdwrBoB> and just get whatever comes in first :)
<haggai> lamont: I just uploaded 2
<lamont> and amarok is currently building a place or 2 - I'll have to d-w it after it finishes failing...
<lamont> but will do so
<HrdwrBoB> (bear in mind that the defaults for marillat are somewhat braindead and default to using 'x11' rather than xv or sdl
<haggai> lamont: thanks
<mdke> HrdwrBoB, hmm
<lamont> right now, I need to be not here... back in about 90 min or so
<mdke> anyone else have an opinion on the mplayer-marillat / mplayer-ubuntu build difference?
<tseng> we've gave you several I believe
<tseng> *given
<mdke> erm
<tseng> btw, this isnt a support channel. this question would be better asked on #ubuntu in the future please
<mdke> i'm not asking for support
<mdke> but i hear and obey
<psy_> hi
<pitti> seb128: d'oh, many packages don't have a pot file 
<seb128> pitti: do you need it ?
<pitti> seb128: I use it as a heuristic to find out the translation domain
<pitti> seb128: now I have to alter my scripts
<seb128> bah, do that tomorrow
<seb128> I don't want to bother you
<pitti> seb128: I have to do that anyway
<dholbach> i'm off to bed
<dholbach> good night everyone
<pitti> night dholbach 
<dholbach> bye pitti
* mvo goes to bed now too
<pitti> lamont: is it possible that some buildds still have the old pkgstriptranslations? I still have some broken tarballs without mo files
<pitti> mvo: night
<mvo> pitti: good night
<jbailey> T-Bone: ping?
<lamont> pitti: adare had 8
<lamont> fixed
<pitti> lamont: ah, that explains it, thanks
<lamont> lesstif1-1 doesn't like you, but I assume you know that (ubuntu1.2, that is)
<seb128> lamont: any build issue with 2.10 packages ?
<lamont> seb128: the only logfiles I currently have in =buildd/main are from a package of pitti's/
<T-Bone> jbailey: pong
<T-Bone> jbailey: sorry, was watching some Anime again :)
<jbailey> T-Bone: Lol, what?  You're not just sitting around waiting for me to talk to you?  For shame! ;)
<T-Bone> jbailey: damn you ;)
<seb128> lamont: nice :)
<T-Bone> jbailey: otoh I'm improving my anime knowledge database for you :)
<lamont> so popcon.ubuntu.com is the real location, yes?
<enrico> Hello.  Is #ubuntu-meeting free next thursday from 17.00 to 18.00 UTC?
<lamont> thom: you around?
<pitti> seb128: still here?
<seb128> pitti: yep probably 2 hours before sleeping
<pitti> seb128: do you still have a gnome-themes build tree? can you please check that the translation domain is indeed "gnome-themes"?
<pitti> seb128: that's one of the packages with a broken translation tarball
<seb128> pitti: gnome-themes.mo
<pitti> seb128: thanks
<seb128> np
<seb128> hum
<seb128> do we have a build chain change ?
<ogra> enrico: MOTU uses it monthly on thursdays at this time but the next MOTU meeting is on march 31, so i would assume yes....
<seb128> wnck has jus dropped a list of internal symboles with no reason
<enrico> ogra: ok.  Then the Docteam 0WNZ it
* ogra thinks we should have a schedule for #ubuntu-meeting
<seb128> no code change with the previous upload
<enrico> if it's busy, then we take the room in the front
<ogra> heh
<seb128> lamont: ?
<ogra> enrico: i just thought we could have a testcase for the new hula-server package thats about to enter universe :) 
<enrico> hula-server?
<ogra> yup, herzi packaged it 
<enrico> ogra: does it have something to do with those large rings one spins around their body?
<thom> lamont: sortakinda
<lamont> seb128: buildd auto upgrades every night
<ogra> enrico: lol, probably.... i didnt choose the name... http://www.hula-project.org/Hula_Server
<lamont> but it shouldn't drop things unless someone turned on --as-needed or something silly like that...
<enrico> ogra: I like the description!
<lamont> thom: popcon.ubuntu.com, with it's 5 submissions, is the real location?
<thom> real location, need to fix the server
<thom> prolly tomorrow
<ogra> enrico: yep and you can test it soon :)
<pitti> seb128: same for libgnome?
<enrico> ogra: I'm curious.  However it seems a bit too featureful to be easy to use: I hope I'm wrong, though
<seb128> pitti: libgnome-2.0.mo
<lamont> thom: other question - is MYHOST_ID still used?
<thom> uh, yeah
* lamont got pinged by the debian popcon folks, wanted to have some sort of sanity in his reply...
<seb128> pitti: libgnome-2.0.mo
<seb128> ups
<pitti> seb128: oh, thanks. that would have been wrong :-)
<thom> lamont: i have mail from them too, have been ignoring it for lack of time
<lamont> thom: /etc/popularity-contest.conf isn't even used in popcon-upload.py....
<lamont> ah, mine just showed up w/in the last hour
<ogra> enrico: i didnt try it myself, i'm just happy to have a packge in from a marketing perspective ;) its very fameous
<enrico> ogra: cool!
<thom> lamont: no, the hostid is used by popcon itself
<lamont> thom: so which one of us wants to (a) fix all the debian references in ubuntu's popcon, and (2) answer their mail?
<lamont> thom: oh.  ok
<pitti> seb128: okay, no problems any more with today's stripped tarballs
<seb128> cool
<lamont> and the destination host for popcon-upload.py is kinda hardcoded right now too, I note.
<thierry> it would be great if there was something in the developper wiki to explain how to make patch...
<pitti> seb128: if everything is built, then I can trigger an update
* lamont files a bug in bz for them.
<thom> lamont: bounce me your mail or file a bug and i'll do both
<seb128> pitti: go go go :)
<lamont> thom: coolness
* pitti goes
<seb128> Removed: _wnck_activate
<seb128> Removed: _wnck_activate_workspace
<seb128> Removed: _wnck_application_add_window
<seb128> Removed: _wnck_application_create
<seb128> Removed: _wnck_application_destroy
<seb128> etc
<lamont> bounced
* seb128 doesn't get why these symboles are dropped of the nm -D
<seb128> same package
<thom> yes, hardcoded since i are teh lazy
<seb128> built one week ago and now
<thom> anyway, bbl
<lamont> thom: np
<seb128> anybody has an idea on what could change that ?
<seb128> that's a diff of the nm -D listing on the lib
<lamont> thom: I'll go ahead and reply quickly to them to tell them that I've filed a bug for us to fix our debian references..
<thom> k
* T-Bone is off to bed
<lamont> thom: #7288 has the email body in it, just for giggles.
<thom> lamont: k, cc me on your reply?
<lamont> certainly
<lamont> thom.may@ubuntu.com, yes?
<thom> just thom
#ubuntu-devel 2005-03-19
<seb128> $ nm -D /usr/lib/libwnck-1.so.16 | grep _wnck_read_icons
<seb128> 00021847 T _wnck_read_icons
<seb128> $ nm tmp/usr/lib/libwnck-1.so.16 | grep _wnck_read_icons
<seb128> 000218e0 t _wnck_read_icons
<seb128> 
<seb128> somebody understand the difference ? 
<Kamion> http://www.xciv.org/~meta/Journal/2005/03/tune.png
<Kamion> ^-- hoary song
<mdke> harsh
<ogra> Kamion: this bad ?
<T-None> seb128: in one case the symbol is local, in the other it's global
<T-None> seb128: else i've nothing to say :)
<Kamion> actually the context is really tax, but :)
<seb128> any idea of what could make that change ?
<jbailey> seb128: link time visibility flags?
<T-None> as jbailey says
* T-None is really off
<T-None> bye all
<seb128> jbailey: that's libwnck package build one week ago and now
<seb128> jbailey: any idea on what in the buildchain or whatever could do that ?
<seb128> same source package
<seb128> jbailey: have you changed something in cdbs to do that ? :p
<jbailey> seb128: Does it update libtool at buildtime?
<seb128> nop
<seb128> that's a cdbs gnome.mk
<seb128> ie: ./configure && make
<jbailey> seb128: No, the only cdbs change in hoary was to add pitti's cdbs-edit-patch script.
<seb128> k
<jbailey> seb128: Do you have both build logs?
<seb128> http://people.ubuntu.com/~lamont/buildLogs/libw/libwnck/2.9.92.1-0ubuntu1/
<seb128> http://people.ubuntu.com/~lamont/buildLogs/libw/libwnck/2.10.0-0ubuntu1/
<seb128> 
<seb128> the only changes are translation between both
<jbailey> And by "same source package" you mean...
<jbailey> Ah. =)
<seb128> rebuilding the first one today gives the same result as 2.10
<lamont> jbailey: everything that is not build-essential is fresh-installed each build
* ..[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
<jbailey> Err -Wl,--export-dynamic was dropped from the LIBWNCK_LIBS configure line.
<seb128> $ grep LIBWNCK_LIBS libwnck_2.9.92.1-0ubuntu1_i386.build
<seb128> checking LIBWNCK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lstartup-notification-1
<seb128> 
<seb128> just built on my box
<seb128> something is doing that in the buildchain so
<lamont> haggai: kdebase -ubuntu2 ftbfs
<lamont> ld: cannot find -lxkbfile_pic
<seb128> jbailey: where does it come from ?
<jbailey> Gimme a sec, I don't have deb-src lines on this box.
<seb128> k
<haggai> lamont: seen it, some nasty auto* stuff thanks
<lamont> enjoy. :-(
<psy__> ?!
<psy__> :p
<jbailey> seb128: Looks like your problem is from gtk 2.6.3 to 2.6.4
<jbailey> LIBWNCK_LIBS is provided by pkg-config for gtk.
<jbailey> Which seems like screwball naming of it to me.
<pitti> seb128: new langpacks built and uploaded, please inform me about any troubles
<pitti> good night everybody
* pitti falls asleep
<jbailey> g'n Martin.
<lamont> ./libtool: line 4696: /usr/bin/expr: Argument list too long
<lamont> using piecewise archive linking...
<lamont> now that's just precious.
<lamont> jbailey??? ^^^
<lamont> ok.  libtool would be Keybuk, not jbailey. nm
<seb128> jbailey: oh
<lamont> doko: fwiw, that's from gcc-4.0
<seb128> jbailey: gtk 2.6.4 has this change "* Move a lot of const data to the .rodata section [Matthias Clasen] "
<seb128> jbailey: nothing to do with that ?
<seb128> I don't think so
<seb128> the changelog is pretty small
<jbailey> lamont: of all the things to blame on me, please not libtool. =)
<jbailey> seb128: Can you easily play with the two versions?  It would be interesting to see the output from
<jbailey> pkg-config --libs "gtk+-2.0 >= 2.5.4 $STARTUP_NOTIFICATION_PACKAGE"
<jbailey> Err.  Lesse what's in that variable. =)
<zenwhen> am i the only person for whom firefox is just insanely slow right now?
<doko> lamont: do you still have the build?
<seb128> jbailey: -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 (2.6.4)
<seb128> jbailey: -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 (2.6.3)
<lamont> doko: it's still running
<lamont> jbailey: sorry still trying to overcome my lumping of *dbs in with autocrap/libstool.
<lamont> :-)
<jbailey> seb128: Was that an accidental uparrow/Enter or was that from each version?
<seb128> each version
<seb128> pkg-config --libs "gtk+-2.0 >= 2.5.4"
<jbailey> Lemme see what's in $STARTUP_NOTIFICATION_PACKAGE.
<jbailey> Oh look, libstartup-notification. =)
<jbailey> But it's the same version, so that's not where it's from.
<jbailey> pkg-config is the same.
<jbailey> hrm
<seb128> $ grep export-dynamic /usr/lib/pkgconfig/*.pc
<seb128> /usr/lib/pkgconfig/gmodule-2.0.pc:Libs: -L${libdir} -Wl,--export-dynamic -lgmodule-2.0 -ldl
<lamont> jbailey: and glib2.0 has diff versions, too.. :-) (in seb128's nearly identical lines above...)
<jbailey> Does gtk automatically pull in glib?
<jbailey> Hmm.
<jbailey> I see that.
<seb128> lamont: no, (2.6.3) (2.6.4) is from me
<seb128> that's the gtk version :p
<seb128> jbailey: oh ?
* lamont bows out of the conversation, before he confuses more than himself
<seb128> :)
<jbailey> seb128: How is libwnck breaking, are you getting linktime or runtime errors?
<seb128> jbailey: it's not
<seb128> jbailey: in fact, here is the issue
<jbailey> seb128: Are you cruising the ABIs for fun? =)
<seb128> no
<jbailey> And you say I'm sick for enjoying hacking on glibc... ;)
<seb128> lol
<seb128> Removed: _wnck_pager_get_n_workspaces
<seb128> Removed: _wnck_pager_get_workspace
<seb128> Removed: _wnck_pager_get_workspace_name
<seb128> 
<seb128> I've such changes in the nm -D output
<seb128> there are private symboles right ? (starting by "_")
<seb128> should not be an issue
<seb128> but 
<seb128> (there is a but)
<seb128> devilspie uses that to do its trick with the windows
<seb128> so when I try to build it
<seb128> vilspie-action-debug.o(.text+0x11d): In function `___1_devilspie_action_debug_run':
<seb128> /tmp/devilspie-0.7/src/devilspie-action-debug.gob:18: undefined reference to `_wnck_atom_get'
<seb128> devilspie-action-debug.o(.text+0x133):/tmp/devilspie-0.7/src/devilspie-action-debug.gob:18: undefined reference to `_wnck_get_string_property_latin1'
<seb128> 
<seb128> etc
<jordi> ooh
<jordi> devilspie is evil
<jordi> evil as the devil
<jordi> dudes
<jordi> I'm going to sleep
<jordi> My Harrods story is finished.
<ajmitch> night jordi 
<thierry> hi, I'd like to help, what can I do?
<seb128> bug triage ? :)
<jordi> epiphany has a lot of open bugs that are probly not an issue anymore >(
<jordi> err
<jordi> :)
<seb128> jordi: look on your new package, evolution
<jordi> shuddup seb
<seb128> and then you can scream :p
<jbailey> seb128: Interesting.  devilspie should never have linked.  There's a linker regex in there that keeps these symbols from being included.
<jbailey> Whatever was providing that export and isn't now was exposing stuff the author intentionally marked as not.
<jbailey> seb128: If you're willing to play with libtool magic, try patching out the regex in libwnck/Makefile.am
<seb128> k, thanks
<jbailey> seb128: The right answer in the end is to get libwnck to export whatever functionlity devilspie needs.  I suspect we won't make too many friends by overexposing the internals.
<seb128> yeah
<seb128> I think I've found the change
<seb128> 2005-01-07  Matthias Clasen  <mclasen@redhat.com>
<seb128> 	* configure.in:
<seb128> 	* Makefile.am: Generate and distribute gmodule-export-2.0.pc,
<seb128> 	which is currently just a copy of gmodule-2.0.pc, but makes
<seb128> 	it explicit that it adds --export-dynamic.
<jbailey> Oy yeah.
<seb128> in glib
<jbailey> In a feeder project like glib, globally changing symbol handling is bad karma. =)
<seb128> :)
<Kamion> bah, why is the volume control icon appearing permanently muted on this upgraded-from-warty install, but not in the fresh-hoary install on the same machine
<seb128> is the volume level to 0 on the boot on the upgrade ?
<jbailey> Or maybe rights to the audio device.
<Kamion> I can't unmute it even if I try, I doubt it's that
<Kamion> nah, I'm in the audio group
<seb128> is the sound working with aplay ?
<seb128> and amixer
<jbailey> Ooo!  you said fresh install!
<jbailey> Kamion: can you check something for me after? =)
<Kamion> not that fresh :)
<Kamion> but I'll be doing loads of fresh installs tomorrow
<jbailey> Kamion: 'kay.  I uploaded an initrd-tools that I think should get the swappartition detection right for resume, but I don't know if it worked.
<jbailey> I uploaded it..  Friday, I think.
<Kamion> amixer says [off]  for everything, aplay doesn't complain but doesn't do anything useful either
<ogra> Kamion: try to change the device in the gnome-volume control
<ogra> app
<Kamion> aha!
<Kamion> thanks, that works :)
<ogra> lamont and i had the same prob...we should have a bug to remember it for upgrade notes i guess
<ogra> (or to solve it indeed)
<doko> Mithrandir: The `--enable' options recognized by software in the gas distribution are:
<doko> `--enable-targets=...'
<doko>      This causes one or more specified configurations to be added to those for
<doko>      which BFD support is compiled.  Currently gas cannot use any format other
<doko>      than its compiled-in default, so this option is not very useful.
<doko> so, cannot build lib32gcc1, until elmo builds an i486 assembler for ia64 ...
<doko> ... is not very useful ...
<jbailey> Hmm.  I wonder if it's expected that failing to recover a suspend-to-disk leaves me without a usable swap signature.
<daniels> Mithrandir: you were seeing lots of questions asked on xorg upgrade, right?
<haggai> doko: thanks for your gsfonts upload
<mjg59> thom: Did we ever get round to uploading an acpi-support set which used the locking?
<thom> yeah, 0.19
<mjg59> Rock
<zenwhen> lots of upgrades today\
<zenwhen> nothing that looks like it will make firefox less of a CPU hog though :/
<thom> zenwhen: ...
<zenwhen> thom, upgrading from array 4 to current a couple days ago made firefox render and perform like a total pig.
<thom> zenwhen: stop powernowd and see if it still happens
<zenwhen> ok
<zenwhen> wow
<zenwhen> that seems a lot faster
<zenwhen> what the hell is powernowd?
<zenwhen> if it isn't important, I might kiss you.
<thom> right, looks like kernel changes has made frequency scaling a lot more aggressive for some people
<thom> zenwhen: reduces clock speed when you're not using it
<jdub> thom: did you see the bug about the ondemand governor in the kernel?
<thom> yep
* jdub has been trying it -> pretty good
<zenwhen> thom, wow... and it is enabled by default in hoary?
<thom> it's enabled by default in warty
<thom> and has been since day 0 pretty much
<zenwhen> it must behave a bit differently in hoaryt
<zenwhen> I never had this issue before now
<thom> like i said, i think it's a kernel change, but icbwe
<daniels> thom: a *lot* more aggressive, it seems
<thom> uh, s/e$//
<thom> daniels: nod
<zenwhen> Thanks a lot though
<zenwhen> I suppose my bug I filed on firefox is fixed
<zenwhen> :D
<mroth> daniels: yes, it likes to speedstep my 3.2GHz cpu down to 400MHz if you let it ;-)
<daniels> awesome
<mroth> I get around it by editing /sys/devices/system/cpu/cpu0/cpufreq
<mroth>  /scaling_min_freq
<mdz> thom: these reports of powernowd issues only started recently, much more recently than the most recent kernel update
<mdz> I don't understand what changed
<thom> mdz: certainly powernow didn't, althought it maybe that it's able to control more cpus due to the way the fallback happens from detected to smi to the acpi controller
<mdz> thom: that stuff has been in for weeks/months too, though
<mdz> these bug reports seem to have started rolling in about a week ago
<thom> mmm, ubuntu9 shouldn't have made many noticeable changes
<daniels> thom: did acpi-support change?
<daniels> i thought we disabled powernowd on desktops
<mroth> if so, it got re-enabled at some point
<thom> no, we never disabled on desktops
<lamont> mdz: I just filed comments on 5207 - dunno if we want to sync or not - I'll dig into it more tomorrow
<lamont> (if you're not terribly averse to syncing it after reading the comments, that'd make my life much easier...)
<mdz> daniels: powernowd is enabled on any system which supports scaling
<mdz> which means it isn't enabled on very many desktops
<daniels> mdz: er, most modern desktops
<daniels> my athlonxp supported it, my a64 does
<daniels> i believe p3s and p4s generally support it
<mdz> lamont: what are the reverse build-deps?
<mroth> I didn't know my P4 supported it until this week, but it did
<thom> my amd64 doesn't, but lots and lots of desktop chips do
<mdz> daniels: my athlon XP doesn't
<lamont>   netpipe-mpich,libmpich1.0
<lamont>   libpetsc2.2.0,libmpich1.0
<lamont>   libluminate6,libmpich1.0
<lamont>   illuminator-demo,libmpich1.0
<lamont>   blacs-mpich-test,libmpich1.0
<lamont>   mpich,libmpich1.0 1.2.5.3-1.1
<mdz> my laptop is the only machine here which does
<lamont> which is to say, not much....
<mdz> out of 3 desktops and 2 laptops
<mdz> mpich                                     | mpich                           | python-scientific (Build-Depend)         | Adam C. Powell, IV <hazelsct@debian.org>                                  |         1109900 |            5540
<lamont> mdz: my desktop does scaling..
<zenwhen> my desktop has been scaling
<zenwhen> without my permission
<zenwhen> :(
<lamont> zenwhen: it just assumes that you want to save power.
* lamont goes to run errands with his daughter for a bit
<jdub> which you do, don't you?
<zenwhen> well it was destroying the performance of my system.
<thom> worth disabling it for desktops, via laptop-detect in postinst?
<jdub> or are you one of those dolphin-killing types?
<lamont> thom: I have no issue with it being enabled on my desktoip
<zenwhen> I dont care how may trees have to burn to make my firefox faster. >:O
<mroth> the current scaling is too aggressive, it scales too low and then takes too long to ramp back up
<lamont> why run at 2.4GHz when 299MHz is enough...
<mjg59> mroth: What speed does it scale to?
* lamont hadn't noticed
<zenwhen> It made my system very crappy
<thom> lamont: yes, but you're used to ia64s
<zul> hey
<zenwhen> Now I am happy again
<lamont> thom: heh
<thom> they're that slow anyway
<lamont> actually, I'm used to ENORAM
<zenwhen> You might want to make it a little less agressive before hoary goes final
<mroth> mjg59: my P4 3.2GHZ scales down to 400MHz
<mjg59> If it's working on desktop CPUs, then the latency to speed up again may be increased
<zenwhen> people are going to say ubuntu is slow
<mjg59> mroth: Eww. Sounds like throttling rather than frequency modulation.
<mroth> its possible.
<mjg59> thom: We're still missing pointy-clicky ACPI enabling, right?
<thom> mjg59: nod
<mroth> its especially noticeable when you first go to drag a window or whatnot, and get a lot of ghosting
<zenwhen> mroth, I am right there with you
<zenwhen> what chip and chipset?
<mjg59> thom: Is that something that's reasonable for final, or should we just document it in the release notes for now and think about enabling it by default in hoary+1?
<mroth> zenwhen: intel p4 3.2 on an asus mobo
<mjg59> On non-laptops, it might well make sense to keep the minimum speed higher
<zenwhen> mroth, Intel 3.0Ghz P4, abit motherboard
<mjg59> Hrm. 
<mjg59> Actually, we should probably never be loading cpufreq-clockmod
<mroth> yeah, on my desktop, I'd want it to be MUCH less aggresive.. only scale down after 5 minutes or inactivity, rather than a few seconds
<zenwhen> I just disabled it
<mjg59> Uh, p4-clockmod
<zenwhen> :/
<mjg59> p4-clockmod drops speed, but not frequency, so it does nothing of any great use to reduce power consumption
<thom> oh, right
<mdz> thom: which signatures did you add in ubuntu9?
<mjg59> Mobile P4s ought to be using speedstep
<mroth> ewh, thats no good then, not even reducing my power bill
<thom> that'd do it
<mdz> aha
<thom>         Intel\(R\)\ Pentium\(R\)\ 4\ CPU*)
<thom>             MODULE=p4-clockmod$EXT;;
<mjg59> I mean speed but not power
<mjg59> The frequency drops
<Quarupt> Wow, you are the guys who helped make Ubuntu?
<mjg59> And they're not designed to ramp up quickly
<thom> mdz: permission to revert for prerelease?
<Kamion> Quarupt: most of the developers hang out here, yeah
<mjg59> thom: Yeah, that one probably wants dropping
<mdz> thom: yep
<jdub> woohoo :-)
<mjg59> thom: Check that it does something different for mobile P4s
<Quarupt> Well I just want o say thanks, cause Ubuntu is by far the best distro i have ever used :)
<Kamion> you're welcome :-)
<Quarupt> Is there anything i can do to help?
<zenwhen> I love how accessable and friendly you devs are.
<Quarupt> I have allready handed out over 1000 copies of Warty at my Univ
<mdz> Quarupt: right now we are preparing for the Hoary preview release on wednesday
<mjg59> What's the procedure for getting something added to the release notes?
<zenwhen> getting my system to stop running like crap has made my night.
<thom> mjg59: yes, it does
<zenwhen> :D
<mdz> Quarupt: and we need as much installation and live CD testing as we can get
<mjg59> thom: Rock
<jdub> Quarupt: watch out for ubuntu love days -> www.ubuntu.com/wiki/UbuntuLove
<mroth> you guys need any log/config files on #7259, or is it 'nailed'? =)
<Kamion> bug triaging and squashing if you can too; stuff >= major is generally bad
<Quarupt> will do
<thom> mroth: testing and uploading now
<mjg59> Oh, argh. Lack of suspend to disk scripts on PPC.
<Quarupt> hey who is the Kubuntu guy(s)
<Kamion> mjg59: yeah; I thought I mentioned that to you the other day
<zenwhen> #kubuntu-devel is the channel for the kubuntu guys
<Kamion> mjg59: pbbuttonsd doesn't have a "suspend to disk" command in its control interface, either
<Quarupt> cause i think there should be a sys icon for updates in Kubuntu like in gtk, if possible
<mjg59> Kamion: Yeah - sorry, I've had no time whatsoever to do anything Ubuntu related (Gnome release stuff)
<Kamion> mjg59: nod
<Quarupt> oh ok
<mjg59> Kamion: Feck. Hmm.
<sabdfl> night all
<mjg59> Kamion: Is there a suspend to disk button on your machine?
<Kamion> mjg59: no separate button, but you can configure pbbuttonsd to suspend to disk on whatever actions you wnt
<Kamion> want
<Kamion> mjg59: well, unless you count the power button
<mjg59> Kamion: Ah - you can do it but there's no nice UI to let you select it?
<Kamion> mjg59: since my lid doesn't close properly, I prefer to keep the power button as s-t-r personally
<Kamion> mjg59: well, you still need to provide /etc/power/ scripts
<mjg59> Kamion: And s-t-r works nicely now?
<Kamion> s-t-r works fine, yeah
<mjg59> Kamion: Yeah. We actually basically want the x86 scripts, but with some cruft removed
<Kamion> mjg59: elmo said the current kernel killed his display hardware by permanently turning off the fans, though
<Kamion> so I'm a bit leery of running it permanently at the moment
<mjg59> Wurgh. Nothing to do with me, as far as I know.
<Kamion> dunno if it really is the kernel or just elmo's bad luck
<mjg59> Killed killed? On his powerbook?
<Kamion> yes, his powerbook still switches on but the display hardware is dead
<mroth> wow, thats a frightening bug
<mjg59> They /are/ under software control, but I'm pretty sure there's hardware sanity override
<Kamion> he was using a second laptop as a terminal to it in Vancouver
<Kamion> could've been unrelated, I don't really know yet
<Quarupt> where are ya guys based, do you have any physical offices or anything?
<Kamion> Quarupt: all over the place; most of us work from home
<mjg59> Quarupt: This is about as close as you get
<mroth> mjg59: I'd think so too, but now I *am* remembering reading something about something similar happening on Apple hardware under another situation where something was software controlled without a hardware sanity
<zul> wha...what happened to elmo's laptop?
<daniels> zul: AFAICT, display hardware is dead in the water
<Kamion> Quarupt: (those of us employed by Canonical, that is; there are lots of community hackers too)
<Quarupt> I love the open source community, it just has a good feel
<daniels> internal LCD doesn't work, neither does the TMDS transmitter
<zul> oh that really really sucks
<mroth> was he under warranty?
<daniels> so you're looking at GPU having burnt out or similar
<Kamion> mroth: think so, it was newish
<mjg59> mroth: Given that it was a replacement for one that got stolen last year, yeah
<mroth> thats forunate
<daniels> yeah, it was only bought in Septemberish
<zul> daniels: well at least he is vancouver
<mroth> fortunate even
<mjg59> Ok, none of my patches seem to touch the code path
<thom> ubuntu10 uploaded, clockmod not loaded
<Kamion> elmo is vancouver? he looked smaller than that last time I saw him
<Quarupt> Will the final Hoary installer hav an option of default window manager? If Kubuntu is stable by then?
<thom> y'all will want to unload p4-clockmod and restart powernowd; or just reboot
<sabdfl> Quarupt: if you install  Kubuntu, you will get KDE, Ubuntu, Gnome
<Quarupt> or will it continue to use Gnome?
<mroth> thom: when package hits archive i'll reboot and make sure it fixes itself by default
<jbailey> Erp.
<Quarupt> Oh so they are like seperate Distro's?
<thom> mroth: cool, thanks
<sabdfl> and you can of course switch using synaptic any time
<jbailey> That means I used to live inside elmo.
<sabdfl> like
<thom> jbailey: now there's a scary thought for you
<Quarupt> but why make a different distro just wor a different WM?
<mdz> Quarupt: KDE and GNOME are not window managers
<Quarupt> s/wor/for
<Quarupt> sorry desktop enviroments
<jdub> Quarupt: the distro itself is not hugely different, but the packages chosen for the default install and livecd are
<Quarupt> whatever
<mdz> there are many reasons why it makes sense to keep them separate
<Quarupt> but the live cd is just a modified Morphix isnt it?
<mdz> there is a lot of work which goes into integrating the system nicely with the desktop environment
<mdz> and there isn't enough space on a single CD to fit both
<daniels> Kamion: the evils of fast food, eh? :\ that and Krispy Kreme, I assume
<jdub> Quarupt: doing this means we can have really incredibly cool GNOME version and really incredibly cool KDE version, both optimised for their users
<mdz> Quarupt: the Ubuntu 4.10 live CD was based on Morphix; the Hoary live CD is a new creation
<Quarupt> Oh
<mjg59> Kamion: Well, I guess we'll find out whether it kills hardware in a couple of days :)
<Quarupt> hrm, I think i will dl the new live cd, i just have the warty one
<jdub> Quarupt: but sharing the same underlying OS, so they both benefit from enhancements underneath
<mjg59> mako: Around?
<Kamion> mjg59: you getting a powerbook?
<mjg59> Kamion: No, people will be installing preview
<daniels> mjg59: do not be tempted!
<Quarupt> Asking all these dumb questions is just holding you guys back from your work im sorry
<Kamion> mjg59: oh right :)
<jdub> i dunno how to do this on our website,
<mdz> lamont: is amarok finished churning so that you can add that dep-wait?
<mroth> is OOo 2.0 on schedule to be out in time for someone in MOTU to sync it for hoary?
<jdub> www.gnome.org + planet.gnome.org
<Quarupt> This is so cool, this is why open source rules, not like i could go into #windows and talk to the actual developers
<jdub> but i think it's pretty important
<haggai> lamont: ping
<thierry> seb128: How can I make a patch for ubuntu? I only know the cvs diff -up > 123456.patch command for the gnome sources...
<Quarupt> I can't wait untill all software patents are gone
<Quarupt> but anyways im switching back to gnome
<zul> Quarupt: you are going to be waiting for a while
<zenwhen> hey, is there some ETA on the ability to edit the gnome menu being added again?
<seb128> thierry: basically the same
<thierry> seb128: so I go in the directory and do cvs diff -up > 123456.patch ?
<seb128> no
<zenwhen> will Hoary release with the gnome menu still being static and unchangable by the user?
<seb128> the package doesn't use cvs
<jdub> zenwhen: yes
<jdub> zenwhen: (unless you edit files in ~/.local, as per the menu spec)
<seb128> thierry: diff between the source package and your copy modifier
<seb128> modified
<zenwhen> jdub, why was such a step backwards taken?
<seb128> that discussion again ?
<seb128> please read the list archives
<jdub> zenwhen: menu editing was never a supported feature anyway
<thom> please not again
<thierry> seb128: ok... could you show me a command example of this?
<seb128> thierry: man diff
<zenwhen> jdub: oh well. It seems like a huge loss to me.
<seb128> thierry: diff -ur dir1 dir2
<Quarupt> Is there anyway i could get on some kinda list so i can get one of the first Hoary cd's when it goes final?
<mjg59> zenwhen: I think it's recognised that it's a desirable feature. However, no workable mechanism was presented for 2.10, so it's not there. With luck, we'll have a solution for 2.12.
<seb128> zenwhen: desktop apps provide a menu entry so that should not be needed
<seb128> zenwhen: would be nice to have but there is no such editor for GNOME atm
<zenwhen> I sometimes add applkications that arent installed by apt to the menu. I suppose I am not big on change that limits my ability to do things they way i am used to. I am sure I will adjust.
<zenwhen> applications*
<Kamion> Quarupt: http://www.ubuntulinux.org/support/documentation/faq/shipit has some stuff about Hoary CDs
<Quarupt> cool
<Quarupt> also
<Kamion> apt doesn't install anything to menus
<Quarupt> can i sell Ubuntu for the exact price of a blank CD so i can keep distributing them?
<Kamion> kind of deprecated if you got the CDs from us for free :-)
<Quarupt> There are getting pretty popular at my Univ, one of the labs might even deploy em on some machines for testing
<Quarupt> well yea but you guys only send me like 50 at a time
<Kamion> but if you burn them yourself, there shouldn't be anything wrong with that; obviously check the various licensing conditions for things like the requirements on providing source
<Quarupt> I am distrubuting almost 100 a week at my school
<thierry> seb128: with diff -ur dir1 dir2, where is supposed to be the patch after that?
<zenwhen> I once gave an ubuntu disk set to a girl and she fell in love with me and we had babies.
<zenwhen> Well, I did give her a disk set.
<Kamion> thierry: on standard output; if you want it in a file, do 'diff -ur dir1 dir2 > file'
<Quarupt> You guys will never sell out like RH or Suse will ya?
<zenwhen> :/
<mdz> Quarupt: you can have as many as you can give away :-)
<mdz> Quarupt: it is permissible to burn CDs and sell them at any price, of course
<Quarupt> Cause i really feel like i finally found a distro with a good community that i can back 100%
<mdz> Quarupt: but it's preferable to distribute the pressed CDs, because they have a much lower failure rate
<lamont> haggai: amarok build kicked
<Quarupt> true
<jdub> Quarupt: where do you live?
<lamont> haggai: tell me that kdebase is really already in the archive?
<mdz> lamont: thanks
<Quarupt> but i doubt you guys would send me over 1000 cd's a month
<Quarupt> Washington
<Quarupt> US
<jdub> Quarupt: going to local LUGs is good
<mdz> lamont: http://people.ubuntu.com/~lamont/buildLogs/k/kdebase/4:3.4.0-0pre1ubuntu4/
<Quarupt> I am a CS major at Western Washington Univ
<mdz> lamont: it built nearly an hour ago, so I should hope so
<lamont> haggai: saw the build failure on -ubuntu2, didn't see the amarok build finish (was just looking at main), got distracted.  my bad
<jdub> Quarupt: plus, you could start a LoCo team
<lamont> mdz: coolness
<zenwhen> jdub: I am afraid I am going to have to ask you to slow development so I dont get left behind on my dialup connection.
<jbailey> Quarupt: In Bellingham?
<zenwhen> it is only fair
<mroth> Quarupt: heh, I think I know someone on your network staff there
<zenwhen> :P
<jbailey> Quarupt: How do you find people to give 1000 CD's a month to there? =)
<Quarupt> Yea, but i am only just now learning C and Java
<thierry> seb128: is it normal that the .patch file I'm getting isn't looking like the .patch files I got with cvs diff -up > 123456.patch ?
<Quarupt> I set up an open source kiosk
<Quarupt> in the main hall
<mdz> there aren't much more than 1000 people in Bellingham ;-)
<seb128> thierry: what do you mean ?
<Quarupt> with info on the open source movement
<lamont> anything more before I run to the feed store?
<Quarupt> Many students take 5 or 10 cd's for family and friends
<Quarupt> we have gone to WASu Eastern even some local community colleges
<Quarupt> We used to distribute Sarge and SID but after we found Ubuntu we switched after 2 days of testing
<Quarupt> I wanna go down to seattle some time and set up my lil open source Kiosk
<mjg59> Kamion: I'll look into making pbuttonsd do useful stuff for suspend to disk
<Quarupt> Maybe even redmond, just to be ironic ;)
<thierry> seb128, forget it, my fault...
* lamont bbiah
<Kamion> mjg59: coooooooool, thanks
<Quarupt> Anyays guys keep up the good work, im sure you guys are on your way to making one of the most world recognized Distro's since RH
<mjg59> Kamion: Of course, I'm hampered by not having any hardware with a pmu...
<Quarupt> Anyone will to work with me for a lil bit to work on this prob i have been having?
<Quarupt> jdub, maybe?
<calc> mjg59: i have a jpeg of that oops if you are interested
<mjg59> calc: Oh, yeah
<mjg59> calc: URL?
* calc uploads it to his server
<mjg59> Kamion: http://pbbuttons.sourceforge.net/projects/powerprefs/gfx/pp-sleeplocks-o.png is the UI in question?
<haggai> lamont: thanks
<Kamion> mjg59: I haven't used powerprefs much ...
<mjg59> Kamion: Is that the GUI you were talking about, or is there another one for config?
<jdub> jdubtv! -> http://node.waugh.id.au/
<tseng> rock!
<tseng> connection refused
<jdub> oh
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<tseng> oh i tried 8080
<mroth> jdub: er.. what app should that be opened in?
<tseng> totem
<thierry> seb128, I want to make .patch for the ubuntu firefox package... any idea? The problem is that I have the source changed for ubuntu, the .diff of the changes and the orginal source... I did the changes to the ubuntu source. Now what are my two directory to make my .patch with diff? 
<tseng> do i want to watch battlestar, or jdub dancing?
<tseng> good jdub 
<tseng> quite synced, id say
<crimsun> pants, of course
<zul> i think the answer is simple...jdub of course
<tseng> PANTS OFF
<seb128> thierry: I don't get what you say but basically: apt-get source package && cp package package1 && make your changes in package 1 && diff -ur package package1
<mroth> the framerate is pretty nice
<Kamion> mjg59: did I mention a GUI?
<Kamion> 01:07 < Kamion> mjg59: no separate button, but you can configure pbbuttonsd to suspend to disk on whatever actions you wnt
<mroth> jdub: what app are you using for the actual streaming?
<Kamion> mjg59: oh, I meant in pbbuttonsd.conf. there might be a GUI, I'm not sure ...
<thierry> seb128: ok
<mjg59> Kamion: Ah, I see what you mean
<mjg59> <Kamion> mjg59: pbbuttonsd doesn't have a suspend to disk command in its control interface, either
<mjg59> Which control interface?
<Kamion> mdz: so do you care which locale I pick to be artifically always supported in order to pull in language-{pack,support}-en
<Kamion> mjg59: oh, I meant pbbcmd
<Kamion>        TAG_GOTOSLEEP          command     config
<Kamion>               Trigger sleep mode.
<mjg59> Kamion: Ah, right
<Kamion> that's s-t-r
<Kamion> and it's what powermanagement-interface uses
<Kamion> but there's no s-t-d equivalent, as far as I can see
<mdz> Kamion: nope
<Kamion> en_US.UTF-8 it is then
<mjg59> Kamion: Ok, that may be fixable
<jdub> mroth: flumotion
<schweeb> has there been much talk of Xen in Ubuntu?  updated packages possibly?  I've been messing around with it a bit lately
<mako> mjg59: hey dude
<mako> mjg59: was eating dinner
<mjg59> mako: What's the procedure for getting stuff in the release notes?
<mako> mjg59: the release notes are being done by the docteam
<mjg59> It would be good to note that suspend to RAM is disabled by default, how to enable it and note that it won't work everywhere
<mako> mjg59: write up what you want in there and email it to ubuntu-doc@l.d.o i guess is the best way
<mjg59> mako: l.d.o? Really?
<thom> mjg59/ Kamion: what elmo said to be was basically that either s-t-r or s-t-d would work, but almost never both on the same ppc system; if you set sleep as s-t-d, tag_gotosleep will give you s-t-d 
<mjg59> thom: Oh, bongtastic. I'll look at that.
<thom> which is why pmi capabilities is as crack as it is
<mjg59> I'll see if I can fix that up in pbbuttons
<Quarupt> Hey, can anyone tell me what ports the remote desktop app use?
<mjg59> thom: Hrm. I can't actually see any code to do that.
<Quarupt> and why we cant choose a port
<mjg59> GOTOSLEEP always seems to do TORAM
<thom> huh, the docs suggest otherwise
<thom> or, my memory of them does
<mjg59>                case TAG_GOTOSLEEP:
<mjg59>                         if (cfgure)     power_suspend (ACTION_TORAM);
<Quarupt> No one seems yo know what ports i need to forward for remote desktop to work
<mjg59> Quarupt: You're better off asking on #ubuntu
<Quarupt> i did
<Quarupt> I thought maybe you guys would know if they didnt
<zul> Quarupt: or you could check google
<zenwhen> This is more a development discussion channel
<zenwhen> not so much tech support
<mjg59> thom: There is code to do disk suspend in there, but no obvious way of calling it from pbcmd (or whatever)
<Quarupt> sorry
<zenwhen> Though many times you cna get an answer :P
<zenwhen> can*
<thom> huh
<wasabi> Hmm. ANy consideration been given to EVMS support in the ubuntu installer?
<thom> mjg59: irritating
<mjg59> thom: That's easy enough to fix, though
<mako> mjg59: ergh
<mako> mjg59: you know what i mean :)
<thom> mjg59: truth
* thom hugs libnss-mdns once more
<thom> yes, it means i use evil and non-free software to do local resolving
<thom> but boy does it kick ass
<schweeb> hehe
<Kamion> wasabi: we've talked about it, and I think it'd rock, but nobody's dedicated any time to it
<Kamion> I'd love to have the default partitioning be LVM of some flavour
<Kamion> there's a partman-auto-lvm package that Anton wrote in Oldenburg, but I don't know its current status
<thierry> seb128: when I do a diff to create a patch, I get a french output at the end : Seulement dans mozilla-firefox-1.0+dfsg.1/profile/defaults: bookmarks.html~ do I keep it?
<wasabi> Yeah. I saw the LVM support in the installer.
<wasabi> I *love* it.
<wasabi> it's so intelligent, how it lays out the LVM partitions, in teh same view, etc
<seb128> thierry: as you want, it's not useful
<wasabi> It's just got the "this was done right" feeling to it.
<mjg59> Could someone on PPC see if http://www.codon.org.uk/~mjg59/tmp/pb.diff builds?
<thierry> k
<thom> mjg59: building now
<Kamion> wasabi_: yeah, it's nice; there are definitely internal improvements that could be made to it, and the way the "configure LVM" bit is disconnected from everything else is suboptimal, but it's a good start
<thom> mjg59: Starting pbbuttonsd: pbbuttonsd 0.6.6: iBook/G3 PB Pismo/G4 PB Titanium (PMU version: 12)
<thom> it even runs
<thom> although it thinks my dual g4 desktop is a powerbook
<mjg59> thom: Does doing pbcmd TAG_GOTODISK do anything?
<Kamion> pbbcmd
<thom> mjg59: can't test, not supported
<thom> (desktop system)
<thom> mjg59: however:
<thom> Mar  8 02:11:01 localhost pbbuttonsd: INFO: Script '/etc/power/pmcs-pbbuttonsd suspend ac disk' launched and exited normally
<Kamion> kick ass
<thom> mjg59: also, fwiw the cmdline is  "pbbcmd config TAG_GOTODISK 1"
<mjg59> thom: Rock. So we just need that patch and a script there that supports that.
<thom> yah
<mjg59> thom: The script probably just wants to be the x86 suspend to disk one, except without the fiddling of /sys/power/disk and without any of the video stuff
* lamont returns
<mjg59> mako: My post is being held for moderation - any chance of clearing it through?
<mroth> thom: testing clean boot after update to powernowd10... looks like powernowd was not enabled at boot now
<mroth> yep looks good
<thom> mroth: rock, thanks for testing
<mroth> mroth@shadowfax:~ $ sudo /etc/init.d/powernowd start
<mroth> This processor "Intel(R) Pentium(R) 4 CPU 3.20GHz" is known _not_ to support power-saving.
<mroth>  * Starting powernowd...
<mroth>  * CPU frequency scaling not supported                                   [ ok ] 
<mako> mjg59: i'm not a moderator.. let me see if i know the password
<mroth> thom: thanks for fixing ;-)
<mako> mjg59: grr.. hmm.
<mako> jdub
<lamont> thom: what if I _want_ scaling on my desktop?
<thierry> sent a patch to ubuntu bug 3176 (branding)... If anyone want to check
<thierry> good night
<jdub> mako: hmm?
<jdub> mjg59: which list?
<thom> lamont: set FREQDRIVER to p4-clockmod in /etc/default/powernowd
<lamont> ok
<mjg59> jdub: ubuntu-doc
<mroth> based on what was said in here earlier though, p4-clockmod doesnt actually provide power savings, correct?
<tseng> p4-clockmod actually degrades performance in some cases in my experience
<lamont> tseng: I was partially just playing devils advocate...
<tseng> heh
<thom> (i was just pointing out that it's still doable)
<lamont> tseng: see - thom knows me...
<lamont> :-)
<mroth> release a special "nostalgia" version of ubuntu with p4-clockmod set to a static max of 233MHz
<mroth> for those who pine for the good ole days
<lamont> mroth: that fast??
<Kamion> nah, 4.77MHz
<Kamion> Ubuntu XT
<mjg59> mroth: It provides some power savings, but not a lot
<mroth> heh, anything less i dont think people would get past the login screen
<mako> jdub: ubuntu doc
<mako> jdub: so about ubuntu-doc
<mako> jdub: the moderator basically resigned
<mako> jdub: from the project. not from the list (apprently)
<mjg59> thom: Ph33r my power management skills in providing functionality on hardware I don't own
<Kamion> heh
<mjg59> If that could be included, it would be great. The GUI stuff probably needs updating as well, but that's not a great pain.
<mjg59> And then it just needs the script.
<daniels> Kamion: xt > xp
<thom> mjg59: i'll sneak it in after preview
<mjg59> thom: Rocking
<mjg59> thom: Then we just need a GUI for x86...
<mjg59> thom: Oh, suspend to disk should be supported on desktops. Dunno about SMP, though.
<jdub> mako: uh huh
<thom> mjg59: i think benh said that pmu support on desktop ppc was minimal to non-existant
<mjg59> thom: suspend-to-disk doesn't use pmu
<thom> mjg59: not at all?
<mjg59> It's just swsusp
<thom> huh, ok
<mjg59> There's only a tiny amount of ppc code, the rest is platform-generic
<mroth> my desktop has a s-t-d option on logout screen, I havent been brave enough to test it yet... should I?
<mjg59> mroth: Give it a go
<mroth> FOR SCIENCE!
<mjg59> No idea what it'll do :)
<mroth> (my uptime is really taking a beating today)
<mjg59> Make sure that RESUME is set in /etc/mkinitrd/mkinitrd.conf
<mjg59> If it isn't, set it and generate a new initrd (then reboot)
<Kamion> daniels: haha
<jdub> mako: so... who should be admin?
<mroth> mjg59: its not currently set in mkinitrd.  which means that the logout menu probably should be hacked to not show me the s-t-d option, no?
* Kamion sets off lots of CD image rsyncs for use tomorrow, and goes to bed
* thom really -> sleep as i've been threatening for the last hour
<mdz> thom: night
<mdz> Kamion: night
<mako> jdub: enrico if he wants it.. else maybe froud or trickie
<mjg59> mroth: Probably, yeah
<mjg59> mroth: We'll worry about that after preview :)
<bluefoxicy> Setting up libgnome2-common (2.10.0-0ubuntu1) ...  <-- now I know four hours is too long for this.
<bluefoxicy> (everybody knows already, just comic relief, moving on. . .)
<mjg59> bluefoxicy: Most of the Gnome 2.10 tarballs have been uploaded
<bluefoxicy> mjg59:  yeah it's just hanging on about 5 or 6 packages now when configuring them
<bluefoxicy> it literally does nothing
<bluefoxicy> but I ahve an unkillable process ATM so it may be fucked kernel state.
<mjg59> bluefoxicy: Oh, I see what you mean
* bluefoxicy doesn't want to reboot.
<bluefoxicy> eth0      Link encap:Ethernet  HWaddr 00:E0:7D:78:CF:05
<bluefoxicy>           RX bytes:3175903291 (2.9 GiB)  TX bytes:1705823287 (1.5 GiB)
<bluefoxicy> As you can see, I don't reboot much :)
<bob2> mjg59: having resume= on the kernel command line isn't enough?
<lamont> WTH is nano a preferred alternative over vim??
<mjg59> bob2: That's also adequate
<mjg59> lamont: For non-unix people, nano is massively preferable to vim
<lamont> mjg59: yeah, but it meant I finally had to figure out how to run update-alternatives.. :-)
<daniels> bluefoxicy: that counter is crap anyway, it wraps too readily
<bob2> I wrap 4gb every couple of days
<bob2> that's not an impressive uptimometer
<lamont>           RX bytes:9469925605 (8.8 GiB)  TX bytes:6379688640 (5.9 GiB)
<lamont> bob2: you need bigger hardware
<daniels> lamont: no matter what hardware you have, the TX meter won't represent ~7TB
<macewan> upgrading to 2.10 right now for testing - 
<bob2> lamont: haha
<lamont> daniels: really?
<daniels> lamont: not AFAIK
<mjg59> Oh, man, don't say that sort of thing to lamont
<daniels> i resorted to looking at how many bytes had passed the OUTPUT table
<mjg59> He'll pull some hppa thing out from somewhere
<lamont> mjg59: heh
<daniels> as long as he gives it to me, it's all good
<bob2> it's not a 64-bit counter on 64-bit arches?
<bob2> that seems stupid
<lamont> 7TB is only 7*2^40 - there's still 8 orders of magnitude left
<bluefoxicy> reboot fixed it.
<deeznutz> hey all... anyone got time to help me with a modprobe question?
<lamont> Kamion: awake?
<lamont> somehow I didn't think so
<lamont> mdz: where does passwd.config live?
<mdz> lamont: in the passwd package
<lamont> doh
<mdz> lamont: can you dep-wait amarok on kdemultimedia 4:3.4.0-0pre1ubuntu1?
<lamont> mdz: done
<mdz> thanks
<lamont> _bc-py.c:8:20: Python.h: No such file or directory
<lamont> beecrypt needs love
<macewan> Nice work on 2.10 
<bluefoxicy> Hi.  Can someone think up a better name than "System Health Information Terminal" for me?  I'll have a pastebin in a second.
<macewan> S.H.I.T.?
<tseng> hah!
<Quarupt> lmao
<Quarupt> its true
<Riddell> what does Needs-Build mean in buildLogs/Lists?
<Quarupt> call it SHIT man
<bluefoxicy> gimme about 15-20 minutes
<Quarupt> nono even better
<Quarupt> "the SHIT"
<bluefoxicy> I was looking at the smartmontools integration post and had a "better" idea on the same lines
<Quarupt> which one of you wites all the howto's and stuff thats on the wiki page?
<Quarupt> or is it allot of people who do it?
<lamont> mdz: I'm planning on a postfix upload after preview, to close #2683, #6232.
<mdz> Riddell: pretty much what it says; there is a new source version available and it needs to be built
<mdz> afaik
<lamont> btw, what's the process for post-preview, anyway?
<mdz> lamont: ok
<mdz> post-preview is going to be pretty much like FeatureFreeze, at least to start
<mdz> we'll likely be rushing to fix new stuff that's uncovered by preview
<lamont> ok.  then eventually it becomes "as for a blessing from mdz/jdub for every upload" I expect?
<mdz> when we get close to the release candidate, yes, we'll be more strict
<lamont> woot
<mdz> Quarupt: there are a lot of people who have written howtos in the wiki
<Quarupt> ok
<mjg59> Uh. It turns out that it's policy for the release notes not to refer to other documentation, because it might move.
* mjg59 boggles slightly
<zul> mdz: some of the sound problems we are seeing might be if they have a slmodem isntalled as well, i need to verify it, just a theory though
<zul> sound cards that use snd_intel8x0
<bluefoxicy> ok
<bluefoxicy> http://rafb.net/paste/results/caaUvh34.html  <-- System Health Information Terminal
<mdz> zul: bug #2011?
<bluefoxicy> taht's just a rough outline idea, and of course some things are obviously just "to give an idea," i.e. Ubuntu doesn't use PaX/GrSec (possibly in the future?) or supply "Firewall modules"
<zul> mdz: 6810
<bluefoxicy> think I should fire it at ubuntu-devel@ and see what the ML thinks?
<mdz> zul: it shouldn't be a problem with jdthood's changes to use a higher index for that driver
<bluefoxicy> there was talk about coding a Gnome applet or task tray thingy to give feedback based on smartmontools, so maybe a more complete attack on system health monitoring would also be good to consider
<zul> mdz: ok just a theory though
<zul> because i have snd_intel8x10 and i dont have a problem but i dont have a modem 
* bluefoxicy decides to bug ubuntu-devel@ with it.
<zul> anyways im off to bed
<mdz> lamont: what's the expected lag time for the retry of amarok to happen, now that kdemultimedia has built?
<mdz> lamont: does kdemultimedia need to be Installed first?
<lamont> it will free up in the cron.daily run that installs kdemultimedia
<lamont> (no autobuilding of accepted here...)
<Quarupt> anyone ever tried to use wine with dreamweaver?
<mdz> lamont: so kdemultimedia installed at :03, amarok installed at :33?
<lamont> assuming that it builds in < 20 minutes, yes
<mdz> (assuming it succeeds)
<mdz> it built in less than 20m on my desktop, so I should hope so
<lamont> installed at :03, amarok build begins < 5 min later.  must be done and signed by :29 to meet the :00 cron.hourly
<ogra> night
<mdz> ogra: night
<Mithrandir> doko: ok, so ia32-libs should make a lib32gcc1 package on ia64.
<Mithrandir> daniels: correct
<daniels> Mithrandir: cool.  think I've got a fixed package for you.
<Mithrandir> daniels: rock.  Can it wait for a few hours so I don't wake Karianne?
<Mithrandir> it's 05:19 here atm, but I couldn't sleep.
<daniels> Mithrandir: sure :)
* lamont considers just turning off the livecd build attempts on ia64 for a while
<fabbione> morning
<cybrjackle> How come gnome-2.10 packages are in hoary if gnome-2.10 isn't release yet?
<fabbione> daniels: ping
<daniels> pong
<fabbione> daniels: i think there is a bug in xorg 6.8.2 that is a regression on 6.8.1
<mdz> lamont: hmm, amarok doesn't seem to be Building yet
<fabbione> the lib that pass the video info (size) to players is broken somehow
<lamont> cybrjackle: because hoary is taking risks...
<lamont> mdz: grumble
<fabbione> but i need to investigate it more
<daniels> fabbione: libXv?
<daniels> seems to work ok here ...
<cybrjackle> thx lamont 
<fabbione> daniels: can you try it on a dual head + xinerama?
<stuNNed> thnx for your diligent work fixing teh xorg issues :D
<fabbione> daniels: i get the problem when i go full screen with xv
<fabbione> mplayer gets a really distorted image
<fabbione> it is like half of the movie goes out of screen
<fabbione> it seems like it tries to scale the movie to both heads, but plays only on one screen
<fabbione> hence half movie
<daniels> fabbione: oh, a Xinerama issue?
<daniels> fabbione: not right at the moment
<Benoni> What's a good way for a configure script to identify that it is running on Ubuntu, and to further identify the specific Ubuntu release (e.g. Hoary)?
<daniels> but I'll check it out for you
<lamont> mdz: Mar  8 04:05:04 buildd-mail: kdemultimedia must be manually dinstall-ed -- delayed
<lamont> ENOEMLO
<fabbione> daniels: just let me know if you can reproduce it
<mdz> Benoni: /etc/lsb-release
<daniels> fabbione: sure
<fabbione> daniels: i think it is a combinantion actually. not only xinerama
<lamont> er, ENOELMO, ENEW
<thully> incidentally, it also looks like kde 3.4 is going in at the same time
<Benoni> mdz: Sweet.  Looks like exactly what I needed.  Thanks!
<lamont> cybrjackle: those 2.10 packages are the current release candidates, iirc.  but I really don't know.
<Amaranth> no elmo?
<cybrjackle> thats what i was thinking since ftp.gnome.org is still at 2.9.91
<thully> well, one side benefit of KDE packages going in main the issues with not having a more advanced cd burning app are partially solved by having k3b there
<mdz> lamont: I am a virtual elmo
<lamont> mdz: that helsp
<Amaranth> thully: kde libs have been there since warty
<Amaranth> oh, you mean in main
<thully> yes - in main
<cybrjackle> What about graveman?
<thully> isn't that universe?
<mdz> lamont: ACCEPTed
<thully> I looked at the newly-built set of DVD images, and it looks like they don't include KDE except for libs.  Why? 
<lamont> mdz: through the wonders of cron.daily love, you can speed things up by 25 minutes or so...
<mdz> thully: because we don't build Kubuntu DVDs yet
<thully> yes, but I thought those DVDs were supposed to contain all of main
<lamont> mdz: I thought the plan was to have the DVD's include all of main, no?
<thully> It would be nice to have an "everything DVD" for the release, with all of main (with KDE) and a KDE/GNOME live image
<mdz> they use the Ubuntu germinate output
<mdz> and they are to include all of Ubuntu supported, which is not the same as main at this point
<mdz> we'll have to figure out what this means for the DVD
<lamont> ah, ok
<jdub> lamont: (we get the gnome tarballs as they're released - there just hasn't been an official aggregate release yet.)
<thully> so, so the KDE packages aren't supported?  Does that just refer to commercial support, or bug reports as well
<lamont> jdub: ah, even better than I'd kinda thought
<mdz> lamont: I am not going to tempt fate by messing with cron.daily
<lamont> thully: there is Ubuntu-supported, and Kubuntu-supported
<lamont> mdz: kubuntu livecd rootfs is b0rked, but I expect you knew that
<mdz> lamont: no, I didn't. why?
<mdz> lamont: can we have those logs published somewhere automagically?
<thully> oh - well, I thought Ubuntu and Kubuntu were the same distro, just with a different selection of packages (as they share the same repos, and website)
<mdz> thully: they are different distributions
<bluefoxicy> <Psyda> hmm...  find your keyboard layout by pressing some keys sounds interesting
<bluefoxicy> <Psyda> mine isn't in the list.  I have a canadian bilingual
<bluefoxicy> you people actually deployed that thing in the array 6 installer?  o.O
* bluefoxicy guesses it's an untested concept and it might, MIGHT actually prove to be not so annoying yet very helpful for nontechnical users who for some odd reason have a non-standard keyboard
<jdub> bluefoxicy: that's not a particularly diplomatic or positive way to ask your question
<bluefoxicy> jdub:  it wasn't meant to be.
<macewan> Like the Device Manager Hardware Database thingy. Nice.
<bluefoxicy> it was a highly opinionated comment
<jdub> bluefoxicy: then you should probably leave, and come back when you're ready to play nice.
<lamont> dpkg: error processing /var/cache/apt/archives/ksvg_4%3a3.3.2-1ubuntu4_i386.deb (--unpack):
<lamont>  trying to overwrite `/usr/share/mimelnk/image/svg-xml.desktop', which is also in package kdelibs-data
<mdz> lamont: Riddell has gone to sleep, and amu isn't awake yet
<lamont> mdz: they're available in-LAN, but that's all right now...
<mdz> lamont: what are?
<mdz> oh, the los
<lamont> I can work on making them published tomorrow
<mdz> logs
<lamont> build logs
<mdz> lamont: did that run just recently?
<lamont> http://<host>/~buildd/livecd/*ubuntu/latest/*.out :-(
<lamont> 04:15 is the kubuntu runtime
<lamont> is now 04:52
<mdz> I guess it has most of the latest stuff, then
<lamont> yeah -probably just a missing replaces or 4
<lamont> (4 pkgs had errors)
<mdz> KDE likes to move things around between releases
<lamont> more fun that way, eh?
<mdz> Riddell did upload a new kdegraphics
<mdz> so that will probably avoid this issue and let us get a rootfs built
<mdz> but please file a bug so they can fix it tomorrow
<lamont> mdz: I'll file a bug with all the errors
<lamont> been thinking...
<mdz> once the new kdegraphics builds, we can retry it
<mdz> http://people.ubuntu.com/~lamont/buildLogs/k/kdegraphics/4:3.4.0-0pre1ubuntu1/
<mdz> or not
<lamont> with all seb128's uploads today, the livecd tomorrow is going to be nearly a full download anyway...  do we want to toss amd64 to the wolves now?  (well, OK maybe not that big a change, overall...)
<Mithrandir> lamont: thanks for the xpdf hint
<lamont> really depends on how much the binaries changed between the two releases
<lamont> Mithrandir: looking at that more, I don't know if it'll help... just need to s/int/long/ in those two variables...
<lamont> but it looked like it was passing an int in a pointer, not the otherway around
<lamont> could be something in a called lib with the same error, though
<Mithrandir> yeah, I did the trivial fix and we'll see if that helps.
<mdz> lamont: sure, tonight's probably as good a night as any
<lamont> ok.  tanking away then.
<lamont> last chance to say 'no'
<lamont> well, ok.  it isn't really, but I don't want to have to copy it back in...
<lamont> gone
<lamont> (which is to say, amd64 will get a brand new, virgin rootfs image, and therefore not rsync very well at all tomorrow.)
<Mithrandir> lamont: let them burn, poor amd64 users.  Or something.  A clean rootfs would be nice for preview anyhow.
<lamont> yeah
<lamont> Mithrandir: if you want both worlds, get me a working partimage :-)
<Mithrandir> I guess that goes in the "nontrivial to fix" category?
<lamont> uh, yeah
<lamont> partimage believes in sizeof(long)==sizeof(ptr)==4, quite strongly
<bluefoxicy> <Psyda> it says ./dists/hoary/main/binary-i386/Packages failed the MD5 checksum
<bluefoxicy> whoever invented CD-Rs needs to be shot with the intar
<lamont> mdz: you want that filed against livecd? I assume?
<mdz> lamont: no, against the package at fault
<Mithrandir> lamont: you can use the 32 bit version for making the fs, though that's horribly ugly.
<lamont> mdz: right
<mdz> it'll break for upgraders too, I assume
<bluefoxicy> wyh are cd-rs so fragile, and is there a way to deal with this error
<lamont> Mithrandir: I'm not going to create a while i386 chroot on the beast just to do that
<lamont> bluefoxicy: slower speed?
<Mithrandir> lamont: understandably.
<mdz> GAH, amarok failed again
<bluefoxicy> lamont:  it was already burned at 1x
<mdz> ah, it got the old kdemultimedia again
<lamont> mdz: pay no attention to amarok for a minute
<bluefoxicy> lamont:  also the only system iwth a CD R there is now blank and needs to be installed
<bluefoxicy> no CDs can be burned until then.
<mdz> amarok is what I am waiting for so that I can bring it into main and update kubuntu-meta
<lamont> yeah - I made an assumption about kdemultimedia and gave it back manually right before I figured out ==NEW
<lamont> is now building on all 3
<lamont> err, 4
<Mithrandir> lamont: does the problem show while building or when running?
<bluefoxicy> so there's no way to install and ignore all MD5 sum failures?
<mdz> fabbione: how is sparc doing with the backlog? :-)
<fabbione> mdz: it is catching up. already done libc6. it is munging gcc3.4 and gcc4.0 is next
<fabbione> mdz: already manually unrolled the libhowl problem
<lamont> Mithrandir: was a user complaint that sometimes it failed while he was running it
<fabbione> mdz: it will take a few days to really catch up on everything :(
<lamont> mdz: it didn't help that about 3 other packages were dep-wait kdemultimedia, it seems
<mdz> fabbione: if you could arrange for ubuntu-meta to be built soon, that would help
<fabbione> mdz: sure i can
<Mithrandir> lamont: do you have a command line invocation for the beast?
<mdz> thanks
<lamont> Mithrandir: xpdf {filename}
<fabbione> mdz: if there is more just tell me because gcc takes ages to build here
<fabbione> does debhelper have any option to show only udebs from a control file?
<Mithrandir> lamont: no, the partimage stuff.
<fabbione> ala dh_listpackages ?
<Mithrandir> fabbione: no, because there is no flag in debian/control saying "this is a udeb"
<lamont> oh. partimage.
<lamont> hard coded check in the build is the first failure.
<lamont> defeating that only leads to pain and suffering
<Mithrandir> lamont: builds fine on my amd64 here.
<lamont> ah, run it.
<lamont> with any args, iirc.
<Mithrandir> ah
<fabbione> Mithrandir: what about the XC-Package-Type: udeb
<Mithrandir> it's a start
<fabbione> ?
<Mithrandir> fabbione: new-fangled stuff. :)
<lamont> partimage -b -z0 --nodesc -f3 -c -o -y save $DEV partimg-${IMGNAME}
<lamont> where dev is /dev/hda5 or whatever, and parimg-${IMGNAME} is some file name
<Mithrandir> yup, thanks
<thully> mdz: one little question concerning Kubuntu/Ubuntu relation - if you run both GNOME and KDE, is that a valid bug reporting platform?  I wonder what distribution that would be, *[Uu] buntu, maybe?   :)
<fabbione> mdz: ubuntu-meta uploaded. anything else i need to do manually?
* lamont grumbles about how bz is the quickest way he knows to overrun his bandwidth quota for any given 5-minute sample
* Mithrandir wonders if he found the ultimate, evil fix for the evilness that is partimage.
<lamont> mdz: actually, these fails-to-install bugs are in a virgin install...  so it's not really a replaces' thing after all... :-(
<lamont> Mithrandir: what's taht?
* lamont thinks he already tried that...
<Mithrandir> lamont: redefining DWORD to be int
<lamont> yeah
<lamont> tried that
<Mithrandir> blows up in interesting ways?
<lamont> uh, yeah.  iirc
<Mithrandir> people using DWORD and shit in their code should be kicked in the nuts.
<Mithrandir> (IMVHO)
<lamont> it likes to cast DWORD -> pointer, iirc.
<Mithrandir> argh
<Mithrandir> this is C++, why does it do all that kind of stuff?
<lamont> yeah - it's an amusing build log if you do the redefine...
<Mithrandir> I can see that..
<Mithrandir> compiling now.
<lamont> C++ does not force good coding.  it merely makes it easier to deal with if you _do_ write good code.
<Mithrandir> it might just be work to fix that, though.
<lamont> sadly, many places believe the reverse of that
<Mithrandir> I don't like C++, but it does actually give you some decent tools to write applications instead of fiddling bits, which is what you very easily end up with C.
<Mithrandir> s/end up/& doing/
<lamont> yeah, guess so.,
<Mithrandir> C is just the wrong language for a lot of the stuff people are using it for.
<lamont> +../../../../amarok/src/plugin/libplugin.la -lkdecore -lakode 
<lamont> grep: /usr/lib/libltdl.la: No such file or directory
<lamont> /bin/sed: can't read /usr/lib/libltdl.la: No such file or directory
<lamont> sorry mdz
<lamont> mdz: that's with the new kdemultimedia
<Mithrandir> ew, partimage has BEGIN; and RETURN; as part of different methods and stuff.
<mdz> lamont: kdegraphics is busticated, too
<lamont> ah, I see..
<mdz> looks like amu will have work to do when he wakes up
<crimsun> sound-juicer eventually hardlocks my machine, and it appears to be sg-related
<crimsun> eh, wtf. I meant gnome-cd, not sound-juicer.
<fabbione> anybody up for reviewing a couple of patches? (kernel and kernel-wedge related)
<fabbione> http://people.ubuntu.com/~fabbione/k-w.diff <- kernel wedge
<daniels> lamont: needs libltdl-dev
<fabbione> the patch is harmless and it does not break backward compatibility
<fabbione> it allows the kernel to export the pkgfilterlist env var to limit the list of packages to process
<fabbione> like the ones that ends in -di ;)
<fabbione> casually.. they match the udebs we need to process, skipping the others
<fabbione> the other patch is a change to the kernel debian/rules to export such env var
<mdz> can anyone give me the 60-second tutorial on how to add a patch to a package which uses cdbs simple-patchsys?
<mvo> mdz: cdbs-edit-patch should do with recent cdbs
<Treenaks> cdbs-edit-patch?
<Treenaks> hmm.. mvo is faster..
<Treenaks> *needcoffee*
<mdz> there are some patches in debian/patches, and some in debian/patches/common
<mdz> which one will cdbs-edit-patch act on?
<mvo> mdz: probably debian/patches
<mdz> I don't understand the difference between that and /common/
<mvo> mdz: what packages is that? I haven't seen such a layout yet
<mdz> DEB_PATCHDIRS := debian/patches/common debian/patches
<mdz> kdegraphics
<froud> mvo: good morning. 
<froud> mvo guten morgen
<mvo> hey froud! any luck with svn?
<mvo> froud: guten morgen, man spricht deutsch ;)
<froud> mvo: nien!!! Mithario still has not sorted out his svn problem and frankly I want to complete the update-manager manual. I am not waiting for him any longer. please email me your changes and I will email the file back to you when I am finished
<mvo> froud: :( it's a very unfortunate situation. I'll send you the update-manager.xml file from trunk and will merge it back to svn. let's hope we find a solution quickly :/
<froud> mvo: it's not the best way to work, but at least if we can shuttle the document between us and you can do the commits it will be better than full-gas in neutral
<froud> mvo: thank
<froud> mvo: danke schurn
<mvo> froud: I need to look over the comments again, give me ~30minutes
<mvo> froud: my comments are in "<!-- mvo:"
<mvo> style comments
<Mithrandir> if I understand correctly, the usplash stuff would have to go in the initrd, right?  So using C++ there is something we _really_ don't want, unless we want libstdc++ and friends in the initrd?
<Quarupt> man, the usb thumb drive you guys put together is so fool proof, and faster than windows great job
<Quarupt> usb thumb drive integration *
<fabbione> mdz: do i have green light to upload kernel-wedge with that change?
<fabbione> (lamont agress that it is the less intrusive change at 4 weeks from release)
<fabbione> it is not essential for preview, but it will give us time to have it propagated and test the other fixes to the kernel build system
<Mithrandir> yay:
<Mithrandir> dbus-send --print-reply --system --dest=no.err.tpbd /no/err/tpbd/tpbd no.err.tpbd.key_state_get string:thinklight
<Mithrandir> method return; sender=:1.31
<Mithrandir> boolean:false
* Mithrandir presses thinklight button
<Mithrandir>  dbus-send --print-reply --system --dest=no.err.tpbd /no/err/tpbd/tpbd no.err.tpbd.key_state_get string:thinklight
<Mithrandir> method return; sender=:1.31
<Mithrandir> boolean:true
* lamont sleeps
<mdz> fabbione: if it is not essential for preview, please wait until after preview
<fabbione> mdz: sure.. no problem at all
<mdz> we will not build a new kernel untitl then anyway
<fabbione> not at distro level, but it will help me having it in the different chroots for test build on all arches
<fabbione> since there are a few tweaks that needs to be done here and there
<mdz> need sleep, good night
<fabbione> good night
<sabdfl> morning all
<froud> mvo: thanks got it
<Mithrandir> good morning, o' glorious leader.
<sabdfl> Mithrandir: steady on there, big guy :-)
<fabbione> morning sabdfl 
<sabdfl> fabbione: ! settling back?
<sabdfl> got to head out now, back later
<fabbione> sabdfl: already rocking 100%
<sabdfl> and the last 10%?
<fabbione> sabdfl: coming up today...
<fabbione> i had to get over the jetlag :(
<sabdfl> interview this morning on CNN, will try and plug FREE SOFTWARE
<sabdfl> cheers
<fabbione> good luck sabdfl 
<Mithrandir> oh, cool.
<daniels> sabdfl: enjoy
<pitti> Morning
<fabbione> hey pitti
<Mithrandir> it would be nice to get it a copy of that
<pitti> daniels: hey
<daniels> pitti: hey dude :)
<pitti> daniels: do you think we can solve the X keyboard problem today?
<daniels> pitti: let me get those two for you
<pitti> daniels: (didn't read my mails yet)
<daniels> pitti: the german thing?  i'm not really sure, to be honest, but I'll have a look
<pitti> daniels: do you think this is German-specific?
<pitti> daniels: setting PC104/U.S. seems like a general fallback
<pitti> daniels: and your detection script almost got it right
<daniels> Mithrandir: xorg 6.8.2-3 builds are spinning on concordia, davis, halley and my laptop; grab xserver-xorg, xorg-common and xserver-common for amd64 when concordia's finished (I'll ping you if I notice first) and your upgrade issues should be solved
<daniels> Mithrandir: I'd upload mine, but xserver-xorg is 50MB
<pitti> daniels: I'm currently booting the live cd, shall I try another language?
<pitti> daniels: btw, if you build another X, please think about CAN-2005-0605
<daniels> pitti: have to work out why the German thing is happening
<daniels> pitti: yeah, working on that too
<daniels> stupid xpm
<pitti> daniels: didn't the script debug output help?
<pitti> daniels: I don't know which thing is writing the wrong values into xorg.conf
<pitti> daniels: shall I boot with another language?
<daniels> pitti: the script debug output confused me -- it *should* be working
<daniels> i'll look into it today though
<pitti> okay, thanks
<pitti> daniels: I currently download the current live cd, then we can test again with the latest crack
<fabbione> daniels: an ati radeon 7500 is any good?
<Mithrandir> daniels: nice
<daniels> pitti: cool
<daniels> fabbione: good, no.  useful to me, yes. :)
<daniels> fabbione: i mean, it works, and it will do basic 3d stuff
<daniels> but not games
<fabbione> i don't need 3d
<daniels> very well supported under xorg
<fabbione> only 2D
<daniels> ah cool
<daniels> then it's fine
<jdub> hrrm
* jdub doesn't feel ill, but can't stay awake for more than a couple of hours at a time :|
<fabbione> daniels: do you know if it has dual head or tv out capabilities?
<daniels> fabbione: in some cards, yes
<daniels> fabbione: people kept making radeon 7500s for pci very late, so if you get a newer pci 7500, it should have both of those things
<daniels> jdub: :\
<fabbione> daniels: well i will check what i get if i get it
<daniels> fabbione: cool
<daniels> fabbione: i have a whole bunch of radeons here, all served me very well
<fabbione> daniels: good
<daniels> fabbione: 7500 (pci -- i think; it's coming), 8500 (agp), 9000 (agp), 9200 (agp), x300 se (pcie), and x850 xt pe (pcie)
<daniels> all good cards
<fabbione> good to know
<Mithrandir> is the x300 and x850 possible to use with free drivers?
<fabbione> HMMMMM
<fabbione> dist-upgrade of multiseat went really wrong
<daniels> fabbione: oh?
<daniels> Mithrandir: 3d, no
<fabbione> daniels: (EE) Generic Keyboard 3: cannot register with evdev brain
<fabbione> that's the X changes to the config
<Mithrandir> daniels: suckage.  I'll stay with my 8500, then
<fabbione> (EE) Configured Mouse 3: cannot register with evdev brain
<daniels> fabbione: how would X be writing out 3 config files, then?
<daniels> Mithrandir: good plan
<daniels> fabbione: er, 3 input devices ... make that 4, if we're zero-based :)
<fabbione> daniels: these are inside the layouts
<fabbione> it was starting before
<fabbione> now it doesn't :-)
<Mithrandir> daniels: problem is, once I switch mainboard, I probably won't have AGP any more
<daniels> fabbione: right, which means it's either PCI or PCIE
<daniels> s/fabbione/Mithrandir/
<daniels> fabbione: OH
<daniels> fabbione: s/Device/Dev Device/ in the config file
<daniels> fabbione: the config file *parser* fills in /dev/psaux if Device is empty
<fabbione> it doesn't start even with the old config
<fabbione> BAH
<daniels> fabbione: so you couldn't specify Dev Phys/Dev Name and not a device :\
<fabbione> jeee it was working like a charm before
<pitti> Kamion, mdz: here?
<fabbione> daniels: but why did you change Device -> Dev Device?
<daniels> fabbione: because Device was always filled in
<daniels> fabbione: if you didn't want to specify it, it would get filled with /dev/psaux
<daniels> because the config file parser is crap
<fabbione> it was never empty with the old config
<daniels> so you'd be listening for events on a non-evdev device
<fabbione> becuase we were using Device to point to /dev/multiseat/<device>
<daniels> right, but remember I was telling you about how the devices didn't get registered with the old setup?
<daniels> neither me nor gus ever got a full set of mice
<fabbione> yes but you basically killed keyboard and mouse hotplug
<fabbione> that is just plain wrong
<fabbione> becuase X doesn't understand regexps
<daniels> i know, but it was either have it all working with no hotplug, or have half of it working with hotplug
<daniels> err ... you do know that the evdev driver does take and evaluate regexps, right?
<daniels> for Dev Phys
<fabbione> well the new config doesn't start 2 heads out of 4 here
<daniels> have a look at xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_evdev.c
<daniels> ok, what's the error?
<fabbione> (WW) Option "Dev Phys" requires an string value
<fabbione> (EE) Generic Keyboard 3: cannot register with evdev brain
<fabbione> (WW) Option "Dev Phys" requires an string value
<fabbione> (EE) Configured Mouse 3: cannot register with evdev brain
<daniels> i'm willing to solve any problems -- and I know that hotplug needs to be solved -- but this is the only thing that was even close to working for me and gus
<daniels> and what's the Dev Phys option there now?
<fabbione>         Option          "Dev Phys"              ""
<fabbione> the other config seems ok, but it doesn't start
<fabbione> the last head is missing the PCI id too
<pitti> yay, hal 0.5.0
* pitti uploads
<pitti> (just kidding)
<daniels> hmmm
<fabbione> this is weird
<daniels> ok, looks like the $agp* stuff is broken
<daniels> can you please run multiseat-configurator with sh -x and email me the output?
<fabbione> Layout0 starts, but it doesn't display anything
<fabbione> daniels: you can ssh to cerberus :-)
<torkel> pitti: together with dbus 0.31? :-)
<fabbione> daniels: you also have sudo access
<pitti> torkel: yes; however, all hoary+1 crack (but goood crack)
<pitti> torkel: this should finally get rid of hanging hal processes on USB races
<torkel> ah
<pitti> torkel: also it supports unified ACPI/APM/PMU power management
<pitti> and lots of other stuff
<torkel> pitti: I look forward to try it :-)
<daniels> OH, I see, crap
<daniels> fabbione: you have both 1:0:0 and 5:4:0
<fabbione> 1:0:0 is the AGP
<fabbione> the others are PCI
<daniels> yeah
<daniels> i'll install multiseat 0.9.5, which has pcibustype integrated
<daniels> fabbione: try that
<fabbione> multiseat-configurator only?
<daniels> already configured, gdm should work now if you restart it tho
<fabbione> nice
<fabbione> it did hang very hard
<fabbione> initializing the AGP card as last
<daniels> hmmmmmmmmmmmmmmm
<daniels> is that the primary display?
<daniels> gotta grab dinner, brb
<fabbione> yes it is
<fabbione> ok
<daniels> hmmm
<daniels> try putting the primary display first?
<fabbione> i am testing...
<doko> fabbione: do you plan a kernel upload before the preview release?
<fabbione> doko: no
<doko> ok, could you have a look at http://lists.ubuntu.com/archives/kernel-team/2005-March/000086.html?
<fabbione> is that the mISDN stuff?
<fabbione> doko: i have no problems with it
<doko> no, that is just a dependency package. ok. I'm uploading it.
<fabbione> after preview please
<fabbione> otherwise you need to get mdz, jdub greenlight
<doko> fabbione: yes, I'll ask, or else, the now existing drivers won't work, if the firmware is missing
<doko> the mISDN stuff should be enabled after the preview, disabled the avmfritz portion, verified that it works with the hfcpci driver
<fabbione> doko: i am not too happy about mISDN
<fabbione> upstream has been inactive for too long
<doko> well, the snapshot is dated 20050225, but I didn't monitor their activity ...
<fabbione> doko: it was removed because upstream didn't update in months
<fabbione> and i am not happy at all to readd it
<fabbione> specially if they are going to disappear again
<fabbione> daniels: starting Layout3 as first crash the machine in a more interesting way
<fabbione> it starts the server
<fabbione> and as soon as the gdm login appears, X crashes and the machine hangs
<daniels> hmmmm
<dholbach> goooood morning
<doko> smurfix: ping
<smurfix> doko: 
<Treenaks> morning sabdfl
<sabdfl> hiya Treenaks
<sabdfl> haggai: around?
<opi> hi sabdfl 
<sabdfl> hi opi
<mvo> Mithrandir: around?
<jordi> mvo: I'm first on the queue dude :)
<mvo> jordi: hrm, crap :)
<jordi> Simira would be helpful too.
<jordi> Where are the Norwegians today...
<mvo> jordi: Mithrandir was around when I got up at 6 in the morning. not sure if the was still up or got up even earlier :)
<jordi> mvo: dude
<jordi> mvo: we're bashing synaptic right now
<jordi> mpt_london has introduced me to this fine sport
<jordi> mvo: I'm looking for translation errors, and I see a few issues in prefs
<mvo> jordi: be nice and gentle to synaptic. it dosn't like to be hurt!
<mvo> jordi: why is mpt_london bashing synaptic?
<mvo> and don't forgot to send me the translation errors :)
<jordi> There's missing mnemonics in "Distribution", "Network"
<jordi> mvo: he's doing usability reviews :)
<jordi> he went to ubuntu bugzilla to file a bug, but it was already there
<jordi> oh well. :)
<jordi> oh
<jordi> colors also lacks mnemonics
<jordi> and the checkboxes in fonts
<crimsun> I have a Build-Depends question: if a package wants calls autoheader for some strange reason, should I add the relevant packages to debian/control:Build-Depends? I remember this is strongly frowned upon...
<jordi> hmm, actually in all the taabs some mnemonics are missing
<crimsun> s/wants//g
<jordi> Why is there Apply, Ok and Cancel?
<jordi> mvo: I keep wondering if I should get svn access at some point.
<jordi> If you trust me, etc. :)
<mvo> jordi: there is a bug about missing mnemonics? what bug number? 
<jordi> mvo: no, that's my IRC bug. mpt_london was about synaptic complaining about something neeeding root, instead of prompting for the root passwd I think
<mpt_london> I don't think it's a synaptic bug in particular
<mpt_london> When I run synaptic directly, I get prompted for a password, which is good
<mvo> jordi, mpt_london: aha, ok
<mpt_london> But when I select a package and try to "Open With..." synaptic, I get an error complaining that I'm not "root"
<mvo> jordi: feel free to file a bug or send a patch about the missing mnemonics. I simply overlooked that :/
* mpt_london resists the urge to giggle at the word root
<mvo> mpt_london: direct install of deb packages is not supported by apt and therefore not by synaptic unfortunately
<mpt_london> mvo: Well yes, but that's a separate bug <https://bugzilla.ubuntu.com/show_bug.cgi?id=2706>
<mvo> (and it's something I not encourage :)
<jordi> mvo: yup, I pointed him at gdeb for now
<jordi> but it's not installable in ubuntu
<jordi> needs recompile I guess
<mpt_london> Oh, the hilarity
<mvo> mpt_london: look at the debian bugnumer that is linked in the ubuntu bugreport and check the age ;)
<mpt_london> mvo: Let's package like it's 1999!
<mvo> mpt_london: no, don't get me wrong. I just wanted to say that it's tricky to solve that problem, not that we shouldn't solve it
<mpt_london> sure
<jordi> mvo: hmm, I guess there's a reason for not us using the gnome-wide proxy sdettings, righgt?
<jordi> mostly because it's not your gconf settings that matter, but root's?
<mvo> jordi: exactly, the reason is that synaptic runs as root 
<mvo> it would need a architecual redesign and a lot of testing to change that
<jordi> nod
<pitti> daniels: time for an USN review?
<jordi> just having the option for setups with mandatory gconf keys wouldn't be too cool
<mvo> jordi: mandatory gconf keys?
<jordi> for proxy settings
<jordi> in /etc/gconf
<Kamion> pitti: yes?
<Kamion> lamont: still around?
<pitti> Kamion: I'd like to build current langpack updates right before the preview tomorrow, but this needs some coordination
<jordi> mvo: ok, I have a small update for some glaring Catalan errors in prefs
<pitti> Kamion: when would be a good time for it?
<pitti> Kamion: i. e. after all other uploads, but before building CD images
<mvo> jordi: so for that I just connect to gconf as root? that sounds like it's usefull
<jordi> mvo: try running gconf-editor as root
<jordi> you'll get the mandatory menu item activated
<jordi> whatever you set there, it will be immutable for all users.
<daniels> pitti: s/caches/the cache/
<Treenaks> jordi: ooh.. multi-user huge-office type stuff :)
<mvo> jordi: very nice! is this a new feature?
<jordi> yeah. You can play "I'm the bastard" games with that.
<pitti> daniels: thanks
<Treenaks> jordi: *clickety* *click*
<jordi> mvo: 2.8 iirc
<jordi> little daniel!
<daniels> little hordi!
<jordi> daniels: you should have come to harrods with me. It was fun.
<daniels> jordi: haha
<daniels> jordi: i read about it
<pitti> daniels: still wrong keyboard with current live cd :-(
<mvo> jordi: I created #7314 about the gconf stuff
<daniels> pitti: bleh
<jordi> there was more about it, but I wanted to sleep. Dude, everything is carpeted, and there's not a single carpet that isn't totally horrific
<jordi> mvo: lemme read
<jordi> mvo: oh
<jordi> well, the mandatory stuff in gconf has been there since the early days
<mvo> jordi: beef it up if you want :)
<jordi> gconf-editor gave it ui recently
<mvo> jordi: aha
<jordi> muuh.
<jordi> what's my bugzilla passwd now..
<Treenaks> jordi: "ken sent me"
<jordi> actually, both pass and email were wrong
<Mithrandir> mvo: pong
<daniels> Mithrandir: packages are on concordia whenever you're ready
<Mithrandir> daniels: cool, thanks.
<Mithrandir> seems like I don
<Mithrandir> 't have an account on her, though
<Kamion> pitti: TBH I really don't know what time everything else will be finished yet
<fabbione> hey Kamion 
<pitti> Kamion: okay, so this will be coordinated on the fly? :-)
<Kamion> pitti: there may well be last-minute uploads right up to the wire
<pitti> Kamion: as long as they don't change translations, I don't care
<Kamion> pitti: that's the best I can do so far :) tomorrow lunchtime or so would probably work, I guess
<Kamion> fabbione: morning
<pitti> Kamion: I'm more concerned about the new gnome stuff, where translations really make a difference
<Kamion> yeah
<fabbione> Kamion: i think i got the kernel-wedge check || true thingy solved and lamont agrees with the fix. I would like also your opinion on it
<Kamion> fabbione: ok
<fabbione> Kamion: basically the root of the problem is dh_listfiles since it doesn't know how to list only udebs
<fabbione> but that's a more general problem since the special entry for debian/control has been introduced only recently (if i understood correctly Mith)
<pitti> Hi seb128 
<fabbione> so something that works is to filter the file list the kernel-wedge check will check
<fabbione> http://people.ubuntu.com/~fabbione/k-w.diff
<fabbione> Kamion: this is the diff
<fabbione> and it does not break backward compatibility
<seb128> hey pitti 
<fabbione> or normal debian builds
<fabbione> Kamion: with the difference that i can export an env var in the ubuntu kernel build
<fabbione> to get only the list of udebs that kernel-wedge should check
<fabbione> in our case the env var is set to "di"
<fabbione> that matches all the Packages with -di (our udebs)
<fabbione> it is the less introsive change i could think
<fabbione> but better options are welcome
<fabbione> (none of this will be uploaded before preview)
<seb128> pitti: g-v-m 1.2.0, you are going to package it or it's for me ? That's probably a translation update tarball
<pitti> seb128: I can do it if you want
<pitti> seb128: I might know the quirks of it better
<seb128> yeah, please :)
<pitti> seb128: I will coordinate with Kamion, I'll built last-minute langpack updates right before the preview tomorrow
<seb128> pitti: http://ftp.gnome.org/pub/GNOME/sources/gnome-volume-manager/1.2/gnome-volume-manager-1.2.0.tar.gz
<seb128> k
<Kamion> fabbione: mm, looks odd. externally supplied environment variables should be in ALL CAPS, I think.
<Kamion> fabbione: kernel-wedge is responsible for adding the -di suffix itself; why not just hardcode that in check?
<Kamion> I think I'd find that neater
<fabbione> Kamion: i did hardcoded it in the beginning and removed it later :-)
<fabbione> but if you think that hardcoding it is ok, it is fine with me
<Kamion> yeah, I think it's ok
<fabbione> ok
<fabbione> testing now
<daniels> heheh
<dholbach> hi seb128 
<seb128> morning
<Walker> www.otomotivshow.com
<trukulo> hi
<haggai> sabdfl: here
<thom> fabbione: (aka the kernel team, but YKWIM); can you look at #7121? 
<pitti> carlos: FYI, translation tarballs are flowing (I'm rebuilding the relevant main packages)
<carlos> pitti: cool, thanks
<zenwhen> hey
<zenwhen> I am trying to instal k3b in hoary
<zenwhen> i get this error
<zenwhen> E: /var/cache/apt/archives/kcontrol_40x1.ad1500000004ep-8893.3.2-1ubuntu7_i386.deb:  trying to overwrite `/usr/bin/kcmshell', which is also in package kdelibs-bin
<crimsun> ...huh?
<daniels> what *is* that version??
<zenwhen> kcontrol cant be installed
<crimsun> that has to be the most screwed version I've ever seen
<zenwhen> because it is trying to write something that is alrready in kdelibs
<Treenaks> daniels: format string bug?
<zenwhen> its what was in the repo
<zenwhen> hoary
<trukulo> zenrox, are you using external sources or only hoary sourceS?
<zenwhen> I have nothing in my sources.list but hoary
<zenwhen> nothing
<zenwhen> I didnt even putanything in there
<zenwhen> aynaptic did
<zenwhen> synaptic*
<trukulo> zenwhen, try sudo aptitude clean
<trukulo> and try again
<zenwhen> clean?
<crimsun> zenwhen: on my system, kcontrol 3.3.2-1ubuntu7 and kdelibs-bin 3.4.0-0pre1ubuntu1 coexist fine
<zenwhen> well
<crimsun> zenwhen: I use aptitude
<zenwhen> I dont know whats going on then
<zenwhen> maybe this is a kcontrol that was just there last night
<haggai> zenwhen: that isn't the kcontrol in hoary that your machine is trying to install
<zenwhen> but it *was* there last night
<zenwhen> how could it try to install anything else?
<haggai> zenwhen: what is the output of 'apt-cache policy kcontrol | grep ubuntu'
<zenwhen> Ive never had non hoary sources on this machine
<zenwhen>  Candidate: 4:3.3.2-1ubuntu7
<zenwhen>      4:3.3.2-1ubuntu7 0
<zenwhen>         500 http://archive.ubuntu.com hoary/main Packages
<zenwhen>      4:3.3.2-1ubuntu7 0
<haggai> zenwhen: your Packages lists are out of date (or your mirror is)
<trukulo> zenwhen: sudo aptitude update
<zenwhen> :/
<zenwhen> i hope this doesnt force me to upgrade all the kde stuff again
<zenwhen> because i am on bad dialup and that k3b install took half the night
<zenwhen> it was all done from the official hoary mirrors with no repo updating in between. I must have caught them in the middle of an upload.
<sabdfl> will we be shipping evo 2.2?
<sabdfl> in hoary :-)
<fabbione> ehhe
<Kamion> I hope we're shipping something with that "please don't even think about using this unless you're a hardcore developer" splash message turned off, at least
<zenwhen> lol
<daniels> Kamion: 'hardcaw'
* Kamion runs into another udev race on install, and shifts hw-detect's udevstart about a bit to see if that helps
<jordi> udev can be annoying when it wants
<sivang> g'afternoon all
<dholbach> hai sivan!
<pitti> Hi sivang 
<sivang> dholbach: hey :)
<sivang> pitti: Hi Martin
<seb128> <gjc> seb128: my hoary systems have a nasty habit of starting updatedb every time I boot, lately :|
<seb128> <gjc> well, that's really bad, it shouldn't be there
<seb128> <gjc> it makes the system very slow, without warning, imagine how a newbie would feel... "this ubuntu distribution is so slow"
<seb128> 
<seb128> is there a bug open somewhere about this ?
<fabbione> i think it's called anacron 
<thom> anacron
<seb128> thanks, but I know why
<sivang> seb128: I don't think so, but it happens everyday in a certain hour , not when you boot
<seb128> I just ask if we have a bug about the issue raised
<sivang> seb128: Why does it happen ?
<fabbione> thombot
<seb128> sivang: because of /etc/cron.daily/slocate and anacron
<sivang> heheh
<mvo> mjg59: around?
<thom> fabbione: ciao!
<sivang> seb128: well, the database need be updated once in a while to make slocate efficient no?
<fabbione> thom: what's up dude?
<seb128> sivang: if you don't run updatedb the base is not updated
<seb128> and locate is pretty useless
<thom> fabbione: popcon joy :-) how was the honeymoon?
<fabbione> sivang: this is true, but the perception of slowlyness will stay
<fabbione> thom: cool :-)
<Keybuk> *shrug* locate and updatedb shouldn't be in base
<fabbione> thom: i have a pic of me and galapagos' penguins i want you to put on galapagos at the dc :-)
<fabbione> thom: as splash screen ;)
<sivang> fabbione: hehe, publish online so we all could see :)
<fabbione> sivang: i will soon.. i need to filter them first
<fabbione> there are plenty of bad shots
<fabbione> and so on...
<thom> fabbione: well, if you can make it ascii art i can make a label...
<fabbione> thom: i think we can manage ;)
<Kamion> whoa, locate *so* should be in base
<Kamion> I argued this at the time
<Kamion> Unices without locate are REALLY FUCKING ANNOYING
<thom> Kamion: agreed
<Keybuk> Kamion: unices with out of date locate databases are worst :p
<Kamion> Keybuk: that's not ideal, but in the case of locate databases I'd take out-of-date over missing
<mjg59> mvo: Hi
<fabbione> here is the future DPL ;)
<Keybuk> Branden's on here ?!
<dholbach> couldnt updatedb be nice'd or something?
<fabbione> ahaha
<mvo> mjg59: I would like to ask you about your opinion on #5737 (nessus-plugins non-free). I wonder if it affects us
<ogra> dholbach: i was taught (in this channel) that nice doesnt speed up disk access
<Kamion> right, updatedb is not sucking CPU
<dholbach> hmm
<Kamion> and it is niced
<Keybuk> oddly, with the 2.6 kernel, there's no reason you can't have some kind of "ionice" setting
<Kamion> 10 by default
<Keybuk> you just don't
<mvo> mjg59: I want to write a mail to the nessus people and ask for clarification. it would be very kind if you could look over it (assuming that you are pretty familar with license issues)
<dredg> how good is yelp at handling man pages? i just told it to dig one there (bash) and it's having a field day on my ram and cpu...
<mjg59> mvo: Eurgh, what a mess.
<mjg59> Yeah, contact upstream - but in that sort of situation, don't expect a straight answer
<mvo> mjg59: can I /msg you my current mail? 
<mjg59> mvo: A link would be better
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/tmp/scrollkeeper-errors known?
<Kamion> dredg: bash(1) is a reasonable groff test case; zshall(1) is better though :)
<Kamion> I bet yelp isn't as fast as groff
<thom> yelp's man stuff isn't really production ready yet, AIUI
<pitti> mvo: does update-manager somehow remember which CDs it already saw?
<pitti> mvo: I tried to upgrade from CD, but this failed due to some dependency breakage
<pitti> mvo: now I tried again (even with restarting my session and removing the cd-rom  from fstab), but the dialog does not come up again
<mvo> pitti: yes, if the cd was scanned already it will not prompt
<pitti> mvo: how can I remove this cache?
<mvo> pitti: remove it from /var/lib/apt/cdroms.list
<seb128> Kamion: nop, I'll have a look, thanks
<Kamion> seb128: thanks
<pitti> mvo: that helped, thanks
<mvo> I wonder if it's a usefull feature. I'm unsure about it. OTOH I don't want to come up with this dialog everytime a user inserts his distro CD. OTOH when he inserts it, he usually will want to do something with it (i.e. install packages) :)
<seb128> np
<Kamion> it's ugly on installations :)
<seb128> yeah
<mvo> what do the others think?
<pitti> mvo: I would ask everytime
<dredg> Kamion: yerrr... that was an interesting exercise in 'how fast does the OOM killer kick in?'
<Kamion> will people really insert their distro CD all that often?
<pitti> mvo: instead you should suppress the question if I insert a powerpc CD on i386 or a live CD
<Kamion> although the DVD, maybe - but as you say that'll be to install packages from it
<pitti> Kamion: yes, if they want to install more pacakges or reattempt a failed upgrade
<pitti> arrgh
<Kamion> pitti: yeah, I think that's much more likely with the DVD than with the CD
<pitti> mvo: I thought you already fixed that bug "synaptic still downloads from the net if upgrading from CD"?
<mvo> pitti: ? if a version is available it will fetch it from the net
<ogra> mvo: put a "ask again ?" checkbox in the dialog
<pitti> mvo: I thought we wanted to force the CD-ROm version then?
<mvo> pitti: live-cd is a bug. power-pc on i386 is a good idea
<mvo> ogra: yes, that sounds reasonable
<mvo> pitti: even if the version on the net is newer?
<pitti> mvo: yes, that's what _I_ want now (not sure about the others)
<mdz> morning
<pitti> mvo: I download/get the CD to _avoid_ downloading from net
<Treenaks> pitti: how about security fixes then?
<pitti> mdz: hi
<pitti> Treenaks: if I click on the update-manager icon, I want upgrades and newer versions from net
<pitti> Treenaks: but not if I upgrade my system from a CD
<ogra> morning mdz
<pitti> I don't need the CD if 3/4 of the packages are downloaded from the net
<Treenaks> pitti: it's criminal to NOT do security upgrades when you're connected to the net, imho
<pitti> Treenaks: okay, then security updates from the net, and packages from CD
<pitti> Treenaks: however, I don't even want security updates when I'm on dialup
<pitti> Treenaks: not if I insert a CD; I can upgrade them manually with the icon
<Treenaks> so you're trying to make an artificial distinction between "normal" upgrades and "security" upgrades
<mvo> pitti: it's not that easy. file a whishlist bug against synaptic please
<pitti> Treenaks: no, I make a distinction between "I want security updates" and "I want to upgrade my system from CD"
<pitti> mvo: hmm, I think the particular strategy should be discussed with more people
<Treenaks> pitti: send a RFC to -devel?
<pitti> Treenaks: modem people will beat us up if we tell them that they are supposed to download 200M of debs _although_ they have a recent CD
<pitti> Treenaks: yes, good idea
<pitti> Treenaks: after preview :-)
* pitti adds to todo
<Treenaks> pitti: :)
<mvo> pitti: there are some more problems involved here. synaptic needs to know from where the packages are actually fetched. this is a information that may not yet available (or expensive to get). there may be more than one source for a given version
<mvo> etc
<mvo> pitti: file a bug, I will look into it and see how it could be done 
<pitti> mvo: okay, post-preview :-)
<pitti> mvo: can't you temporarily ignore non-CD-ROM sources?
<pitti> mvo: that's what I did now, I commented out the http:// sources from sources.list
<mvo> pitti: not easily at least
<pitti> mvo: apt-get -c /tmp/cdrom-only-apt.conf ?
<pitti> mvo: oh, even better
<pitti> mvo: apt-get -o Dir::Etc::SourceList=/tmp/cdrom-only-sources.list
<mvo> pitti: sure, the problem can be solved with brute-force. I consider this a very hackish solution
<pitti> it is.. :-)
<pitti> anyway, let's discuss that later
<mvo> pitti: ok
<Kamion> mdz: I've fixed the issue where a whole CD image build fell over if something went wrong on one architecture
<mdz> Kamion: thnks
<mdz> thanks
<Kamion> mdz: so in general you probably never want to do stuff like ARCHES='amd64 i386 powerpc' cron.daily-live any more - just let it fail on ia64
<Kamion> if it goes wrong, let me know :)
<Kamion> mdz: also, live filesystem manifests should now be published as hoary-live-$arch.manifest
<Kamion> running a test now
<mdz> nice
<mdz> whoa, my panel just crashed randomly
<Burgundavia> test
<ogra> Burgundavia: failed :-P
<Kamion> mdz: any idea what time we should expect to be able to freeze the world for preview?
<Kamion> (tomorrow sometime, I assume)
<mdz> Kamion: GNOME 2.10 is the only remaining factor
<mdz> so whenever they finish releasing tarballs, and seb128 finishes uploading them
<mdz> jdub: ?
<Mithrandir> elmo: any comments on http://sources.redhat.com/ml/binutils/2004-09/msg00299.html ?  It would be a nice thing to pull in, I think.
<Kamion> ok. I probably need to upload debian-installer at some point; a non-daily build of that would be good
<Burgundavia> ogra: damn
<ogra> heh
<rightclicker> need some assistance, using an Acer Travelmate 230 Laptop - Ubuntu - Im getting X Server error - i can view some details on the output, im a Newbie.
<thom> rightclicker: support questions in #ubuntu, please
<rightclicker> cheers
<mdz> Kamion: would it be straightforward to generate a list of uninstallable packages in universe (deps unresolvable in main+universe, but only output packages which are in universe)?
<Kamion> mdz: hm, dunno, I'd have to try it
<ogra> Kamion: that would be absolutely great :)
<Kamion> I expect it would be easier to generate a list of uninstallable packages everywhere, and there aren't that many in main
<ogra> Kamion: that would be sufficient too i think, we can remove the main packages ourselves....
<Kamion> http://cdimage.ubuntu.com/daily-live/current/hoary-live-i386.manifest # hooray
<Treenaks> "hoaray"
<thom> http://popcon.ubuntu.com/ lala
<doko> mdz, jdub: fabbione is ok with the proposed avm-fritz-firmware package, I'd like upload that package before the prerelease and include it in the ship so that the avm drivers are actually working
<thom> it, uh, needs branding and some fixing
<Mithrandir> thom: a tiny bit, yes
<thom> but there are at least 175 people submitting
<tseng> would be useful to see what tops universe
<Mithrandir> I should get popcon installed on my amd64 boxes, then
<Burgundavia> is the popcon package for hoary pointed there?
<tseng> most of main is pretty obvious as it comes ootb
<thom> Burgundavia: yes
<mdz> hehe
<thom> tseng: nod
<mdz> our popcon results are much flatter than Debian's
<Burgundavia> so I am one of just 175 people who are reporting?
<mdz> Burgundavia: yes, once thom has everything in good shape, he'll make an announcement to remind people of popcon's existence and tell them how to participate
<mdz> (it doesn't submit anything by default)
<tseng> anyone have a particular cd they want tested?
<Burgundavia> right, I remember the question in the nstaller
<tseng> doing an install.
* thom sighs at perl scripts with stacks of html in their code
<Burgundavia> mdz: regarding derooting, popcon mentions that it be derooted in the FAQ
<Mithrandir> thom: how can I check that my boxes have actually sent in something?
<thom> Mithrandir: what is in your /etc/popularity-contest.conf? if you tell me your host-id i can check
<Mithrandir> thom: people are going to ask the question, I can imagine.  "c9aabcce3ca24b9cb59f57dddd048195" and "1e08140075aed3bc01ed90ca5d634c59"
<thom> yes, they're both submitting
<thom> if PARTICIPATE=yes there's no reason for it not to work
<Mithrandir> so I'm 20% of the amd64 population. :)
<lamont> moof
<thom> Mithrandir: looks that way
* ogra increases the amd64 crowd
<Mithrandir> ogra: go go go! :)
<ogra> done
<ogra> thom: just running popularity-contest is enough ? or do i have to call popcon-upload separately ?
<Mithrandir> ogra: just install popuplarity-contest and it should submit
<mdz> ogra: it runs weekly
<ogra> Mithrandir: its installed since i got this machine, but PARTICIPATE was set to no
<zul> morning
<Mithrandir> hi chuck
<zul> hey Mithrandir
<lamont> thom: should I enable popcon on my hppa box?
<thom> ogra: if you want to hurry the process just sudo /etc/cron.weekly/popularity-contest
<thom> lamont: meh.
<lamont> ii  popularity-con 1.26ubuntu3    Vote for your favourite packages automatical
<lamont> Linux gw 2.6.11-rc4-pa1 #7 Wed Feb 16 16:58:22 MST 2005 parisc GNU/Linux
<maswan> Should I hurry and try to migrate a cluster or two? :)
* thom &|
<Kamion> Mithrandir: popularity-contest is in base
<Mithrandir> Kamion: ok, but it's not enabled by default.
<Kamion> right
<pitti> ogra: hehe - http://www.heise.de/security/news/foren/go.shtml?read=1&msg_id=7568932&forum_id=75063
<Kamion> somebody should apply Ubuntu branding to 'dpkg-reconfigure popularity-contest'
<ogra> pitti: yeah, youre our marketing department, i always knew it ;)
<pitti> *giggle*
<sivang> pitti, what does it say?
<sivang> pitti: I mean, the article that you pasted the link to :)
<ogra> sivang: that ubuntu is fastest in security fixes and that its impressing for such a young distro
<sivang> ogra: oh, very nice.
<pitti> sivang: "Again Ubuntu belongs to the first ones which provide corrected packages after publication of a security hole. A good start for a distribution which is known for only half a year."
<sivang> pitti: they should say who is the guy who is responsible for that ;-)
<pitti> sivang: ah, don't worry
<pitti> sivang: this was an user comment
<pitti> sivang: not an article of the newsticker
<pitti> sivang: besides, the article mentions "Ubuntu", that's the important part :-)
<ogra> sivang: heise refused to report about ubuntu from the beginning, there were lots of people pointing to the warty release announcement and they didnt react until today....
<Burgundavia> if you look at lwn security round up each week, Ubuntu is almost always the first distro to patch
<pitti> cool
<sivang> pitti: true :)
<ogra> sivang: in fact there is one article where "this new southafrican distribution called ubuntu" is mentioned...in the whole archive
<ogra> and thats all....
<pitti> there was a short article in the magazine, though
<ogra> quite poor for the leading german IT news site
<pitti> ogra: trust me, I will send them the Hoary announcement again :-)
<Burgundavia> I think it is funny that distrowatch lists ubuntu as coming from the isle of man rather than sa. Yes, I know canonical is based there
<pitti> ogra: (all other German guys should, too :-) )
<ogra> pitti: i will poke them too
<ogra> Burgundavia: regarding the uploads of the last days it might be based in france ;)
<ogra> it always depends on the citeria you use for measuring *g*
<Burgundavia> tracking the country is kind of meaningless with linux devel work
<ogra> yup....as tracking the adress of a LTD is :)
<Burgundavia> while we are on security, can I ask why don't have firefox 1.0.1?
<pitti> Burgundavia: we will have
<pitti> Burgundavia: just not for the preview
<pitti> Burgundavia: since the risk of destabilizing the preview is too big
<Burgundavia> ok
<Mithrandir> maswan: what would "the Ubuntu developers" be in Swedish?  Are you allowed to say "Ubuntuutvecklarna" or do you say "Ubuntu-utvecklarna"?
<Burgundavia> however, the new version came out Feb 24, the same day as the preview freeze
<maswan> "Ubuntu-utvecklarna", since "Ubuntu" is a name, not a common word
* Kamion spies somebody doing branding
<maswan> or a foreign word for that matter
<Mithrandir> maswan: for debian, it's Debianutvecklarna, though.
<Mithrandir> Kamion: correct.
<maswan> Mithrandir: Hmm.. True.
* maswan looks around for "Svenska skrivregler"
<Mithrandir> but a double U wouldn't be correct in Norwegian at least, and the languages are quite similar
<maswan> hmm.. probably have that at home only, go for "Ubuntu-utvecklarna"
<Mithrandir> ok
<maswan> I'll try and remember to check this evening when I get home
<Mithrandir> but Ubuntupaket is ok?
<maswan> I think so, yes.
<maswan> It looks ok. :)
<Mithrandir> Kamion: Ubuntu is just Ubuntu, even in Czech, right?
<Mithrandir> we should have a "localizing Debian packages with sed" wiki page
<lamont> Mithrandir: it gets transliterated into say, japanese, but otherwise, I expect so
<Kamion> Mithrandir: I don't have an answer for Czech
<Mithrandir> lamont: Debian is Debianu in some cases for Czech.
<Kamion> Mithrandir: everything I know on this subject is in http://www.ubuntulinux.org/wiki/DistributionDefaultsAndBranding
<Kamion> Mithrandir: I just leave everything else fuzzy
<Mithrandir> Kamion: ok
<Kamion> there are some languages where the form isn't just "Ubuntu" regardless of case, such as Finnish
<doko> Priority: source ???
<Kamion> doko: I noticed that, seems to be a bug in the override file
<Mithrandir> Kamion: well, they can file bugs. :)
<Kamion> Mithrandir: right :)
<doko> kamion, ok, thanks
<Mithrandir> it's not like I know Ukrainian or Russian either, but they're simple to ubuntifiscate.
<koke> d3vic3: are you working on the omniorb4 package?
<Treenaks> Mithrandir: how about verbs around it? they might change because of the starting/ending sounds of words
<Treenaks> or other "modifications"
<Kamion> Treenaks: so far nobody's told me of any examples of that
<Kamion> Treenaks: apart from English: "a Debian ..." -> "an Ubuntu ..."
<Kamion> it's certainly possible though
<Treenaks> Kamion: yeah, but most of you know English :)
<Kamion> Treenaks: since I do the installer branding, I get most of the reports about this.
<Mithrandir> Treenaks: yes, they can.  If so, we have a wiki page and a bugzilla.
<Kamion> oh, there's "d'Ubuntu" in some languages too
<Kamion> but not universal, I think some are still "de Ubuntu"
<d3vic3> koke, I haven't started on it yet 
<Burgundavia> branding issue: python package mentions debian
* infinity is shocked that today is the very first day he's had private mail from an Ubuntu user about packages with his name on them somewhere.
<infinity> Not sure if this means Ubuntu users are more polite/sane than Debian users, or if they just don't like to mail people.
<koke> d3vic3: I'm packaging synopsis and depends on it
<koke> d3vic3: maybe I'll try to package omniorb first
<d3vic3> koke, ok 
<sivang> hmm nice, either openoffice2 takes LOADS of memory, or my gnome uprgades are just slowing down my machines :)
<Treenaks> sivang: both
<sivang> Treenaks: you also see the slowdown with the latest gnome updateS?
<Treenaks> sivang: try switching to a simpler theme
<Treenaks> I hope it's not a build-flag thing
<sivang> Treenaks: bah, right. what do you consider a simple theme? :)
<Treenaks> sivang: well, try "simple" :P
<Treenaks> or default
<Treenaks> even industrial is not as heavy as clearlooks
<Treenaks> afaik
<mdz> Kamion: haha, I completely got my bugs crossed in #966
<mdz> I was reading email about the kernel package install bug, and writing about the mdadm.conf bug
<Kamion> yeah, I thought so :)
<mdz> seb128: do you know when we will have a full set of 2.10 packages in Hoary, so that we can start testing for preview?
<seb128> mdz: within 1 hour
<mdz> seb128: fabulous
<seb128> mdz: where is the hoary page in yelp ?
<mdz> seb128: under "other documentation" right now
<seb128> or on the hdd
* ogra joins haggai in lease contract termination :(
<mdz> /usr/share/ubuntu-docs/C/about-ubuntu.xml
<mdz> /usr/share/omf/ubuntu-docs/about-ubuntu-C.omf
<fabbione> thom: ping?
<seb128> mdz: thanks
<thom> fabbione: just walking out the door, sorry
<seb128> mdz: I'll do a panel upload to fix that
<mdz> seb128: we will be changing the yelp category stuff, but probably not the location on disk
<seb128> k
<fabbione> thom: ok
<fabbione> thanks
<ogra> mdz: so when will we freeze then ? ( i just got struck by some real world problems (landlord terminated my contract for the house))
<mdz> ogra: ouch!
<ogra> yup
<mdz> ogra: we are already frozen :-)
<ogra> oh
<ogra> i thought today or tomorrow was the date
<mdz> mako: around?
<mako> mdz: yeah
<mdz> mako: I had this fantastic idea
<mdz> mako: that for preview, we prepare the release announcement _ahead of time_
<mako> ?
<pitti> mdz: erm?
<pitti> mdz: vaporware?
<mdz> pitti: hmm?
<pitti> mdz: ah, sorry, I misread
<ogra> mdz: isnt that done anyway
<mdz> ogra: tomorrow is the preview release
<mdz> ogra: preview freeze began 6 days ago
<mdz> ogra: see my release updates on ubuntu-devel
<ogra> ah, ok, i muddled these two
<mako> mdz: sounds great
<mdz> mako: do you think you can fit that in sometime today?
<mako> mdz: want to select the highlights from the release notes?
<mdz> mako: yeah
<mdz> mako: also, we're hoping to release a Kubuntu preview at the same time
<mako> i need to make sure shipit is ready to take new orders but i think that's working
<mako> anyone want to help me test a new shipit?
<mdz> mako: however, we probably want to paint it in a different light, since Kubuntu is only just coming together, while Ubuntu has been stabilizing for some time
<mako> alright
<Treenaks> mako: cool
<mdz> mako: is that enough to go on, or should I send some bullet points?
<Treenaks> mako: I probably could help you
<mako> Treenaks: devel.yukidoke.org/shipit/user.cgi
<Treenaks> mako: old logins don't work?
<mako> mdz: i will go through the release notes and pick out highlights i like. if there's stuff you think is essential
<mako> Treenaks: they should.. but also try to create a new one.. abuse it a bit
<mako> Treenaks: i did a lot of work on it in the last week
<Treenaks> mako: where do I report bugs? :)
<mako> Treenaks: /query mako
<dilinger> mako: hi
<mdz> seb128: gv wants to move to universe now; did gnome-gv depend on it before or something?
<seb128> mdz: I've not changed the Depends, that's weird
<mdz> it has never been seeded, so something depended on it
<mdz> it was in universe in warty
<mdz> weird
<mdz> lamont: kdegraphics needs a dep-wait on imlib+png2_1.9.14-16.2ubuntu1
<mdz> Kamion: amd64 install from today's daily is gold
* fabbione larts pitti with a huge stick
<fabbione> ok you can quote me on this:
<pitti> fabbione: hey, don't shoot the messenger :-)
<mdz> I need more sleep. back in a few hours
<fabbione> "if CAN was a dildo, i would be goatse now"
<fabbione> mdz: sleep tight (rememebr the cc meeting in one hour)
<pitti> goatse -> no dictionary entry :-(
<pitti> mdz: good night :-)
<mako> pitti: do you know ProSieben?
<dholbach> mako: i know it... what about them?
<pitti> mako: sure
<pitti> mako: I don't have a TV, though
<mako> dholbach, pitti: what is? they want to make a show about my website
<dholbach> wow :-)
<pitti> mako: that's a famous German TV station
<mako> www.unhappybirthday.com
<dholbach> rocking
<mako> are they cool?
<pitti> mako: dunno, during the last five years I watched TV only for a few hours (in total)
<dholbach> they're a private station, so they send a lot of crap (in my opinion), but they're huge
<mako> pitti: i don't have a tv either. especially not one that receives german stations
<dholbach> s/private/company
* dholbach doesnt have one either
* pitti thinks TV is mostly crap :-)
<dholbach> but i'd surely find someone who records it for me
<lamont> checking for png_read_info in -lpng... no
<lamont> configure: error: *** PNG library not found ***
<lamont> mdz: better make that imlib+png2 >>1.9.14-16.2ubuntu1
<dholbach> mako: while you're talking to them, tell them they could make a show on ubuntu :-)
<mako> dholbach: i will!
<dholbach> mako: you rock! :-)
<dredg> specifically, a puppet show
<Treenaks> for some reason, I keep thinking "at-spi" is some SPI version of the 'at' program..
* pitti too
<lamont> seb128: are we nearly there yet? (how many more packages you got, anyway???)
<dholbach> lamont: millions
<ogra> hopefully not
<dholbach> lamont: i'm subscribed to the gnome-release rss feed
<seb128> lamont: I've uploaded all the tarball excepted gnome-cups-manager and libgnomecups which have a regression according to pitti and so not for the preview and gdm
<lamont> seb128: woot.
<seb128> lamont: we can go without the new gdm if you want
<seb128> how are the builds going ?
<lamont> slogging along
<dredg> dholbach: rss feed url?
<lamont> there was one failure because the build-deps were wrong (well, old), but I just depwaited it
<lamont> libgnomecups1.0 was the dep-wait, now 0.2.0, build-dep only dragged in 0.1.4
<seb128> what failure ?
<dholbach> dredg: http://ftp.gnome.org/pub/GNOME/LATEST.xml
<seb128> lamont: what package is that ?
<dredg> dholbach: cheers
<lamont> had to go find it.
<lamont> libgnomeprint
<lamont> the failure log should be on p.u.c - if not holler, because that means I "found" the wrong package...
<seb128> arg
<lamont> it
<lamont> seb128: it's dealt with
<seb128> lamont: no
<lamont> although it would be good to fix the package...
<seb128> <seb128> lamont: I've uploaded all the tarball excepted gnome-cups-manager and libgnomecups which have a regression according to pitti
<lamont> pkgconfig barfs
<seb128> I've not uploaded the new libgnomecups
<lamont> oh. DOH!
<seb128> pitti: ?
* pitti listens
<pitti> seb128: do we really need the new libgnomecups?
<seb128> pitti: new libgnomeprint/printui depends on the libgnomecups you don't want to get uploaded
<pitti> arrgh
<wasabi_> hmm, after the last hoary update (yesterday) i have an xorg that is spinning CPU uselessly
<seb128> pitti: is that a big regression for a preview ?
<pitti> seb128, lamont: well, it's not the worst bug in the world, but I wanted to avoid having it in the preview
<pitti> seb128, lamont: but if it blocks anything, go ahead and upload it
<seb128> k
<lamont> pitti: is fixable?
<lamont> pitti: it blocks
<pitti> seb128: however, we should fix it after preview
<seb128> sure
<seb128> that's probably easy to fix
<pitti> lamont: I hope it is fixable, but not until tomorrow, I'm afraid
<lamont> right
<seb128> the diff between previous version and this one is like 200 lines
* lamont bbiab
<pitti> seb128: okay, then upload it
<pitti> seb128: I will take a look at it ASAP
<pitti> seb128: can you please put the source package somewhere
<wasabi_> hmmm. spinning update-notifier
<wasabi_> spinning notification area
<ogra> seb128: this totem downloads DLLs changelog entry is just weird.... did hadess say anything about that ?
<pitti> seb128: nevermind, I can also download it after you uploaded it
<seb128> pitti: k
<seb128> ogra: what changelog entry ?
<seb128> ogra: a guy already mailed ubuntu-user about a such stuff this morning
<ogra> * Automatic download of the Windows DLL plugins
<ogra> apt-cache show totem
<ogra> very strange
<seb128> that's not new
<ogra> oh
<seb128> the description has not changed for months
* ogra hopes that entry isnt true
<seb128> what entry ?
<seb128> be clear
<wasabi_>     * Automatic download of the Windows DLL plugins
<ogra> the one i just posted
<wasabi_> wow! what a feature!
<ogra> scary...
<seb128> wasabi_: thanks but that's not a changelog, that's a package description
* seb128 doesn't understand what is the issue
<ogra> seb128: simple....its wrong 
<seb128> if you put w32codecs totem uses them
<seb128> that's all
<seb128> and that's not new
<ogra> seb128: but it doesnt download them automatically
<seb128> bad english perhaps
<ogra> :)
<seb128> it loads them from the disc
<seb128> grrr
* seb128 hates such dumb discussion
<seb128> if you want to make a mess now about an english sentence beeing in the description for month be clear
* ogra dives back into his programmers cave to let seb do his work.....
<ogra> seb128, sorry...
<seb128> np
<seb128> but that's really an useful discussion
<wasabi_> hmm, would it be possible to make the install cd grub boot screen continue after a minute or such?
<wasabi_> why doesn't it?
<wasabi_> I had this crazy idea that I want to install on this pc using a serial console, but can't get past the boot. ;)
<wasabi_> hmm i wonder if there is someway to make grub touch the serial console...
<Kamion> it wouldn't help you if you can't type 'linux console=ttyS0' or whatever at it
<Kamion> and that isn't grub, it's isolinux
<wasabi_> is it? same diff.
<wasabi_> hmmm. wonder if the kernel could multiplex to both ttyS0 and the screen. ;)
<pitti> wasabi_: this works fine with lilo
<pitti> wasabi_: (multiplexing)
<wasabi_> the install cd doesn't use lilo. =/
<pitti> yes, I know
<wasabi_> as i just discovered!
<pitti> wasabi_: but you asked for the kernel :-)
<wasabi_> =)
<wasabi_> I dunno what I'm asking for. All I know is I have this box here, and the only available monitor is halfway across the office and it's a 19" crt and it's heavy. =)
<wasabi_> and I want to put ubuntu on it!
<torkel> should work fine with grub too (not tried it with Ubuntu yet though)
<pitti> wasabi_: automatic boot after a certain timeout would certainly help :-)
<Kamion> if you do autoboot and the timeout is too short, people file bugs saying that they were in the middle of reading the help messages and suddenly it autobooted
<Kamion> if you do autoboot and the timeout is too long, people file bugs saying they grew old and died waiting for it, or simply don't realise that autoboot will happen at all
<Kamion> so we don't do autoboot :P
<wasabi_> what about isolinux using tty0 like lilo supposadly does?
<wasabi_> ttyS0
<wasabi_> does it support it or would it have to be added?
<mako> can anyone else help me out with testing shipit?
<pitti> mako: I can, what do I have to do?
<Mithrandir> order a shipload of CDs, most likely?
<Mithrandir> :)
<pitti> Mithrandir: I already tried to provoke SQL injections for an hour :-)
<tseng> i can order cds if thats it mako 
<pitti> mako: shall I just order some CDs?
<mako> pitti: just go to http://devel.yukidoke.org/shipit/user.cgi
<mako> pitti: create an account, log in, etc
<fabbione> at what time does the daily iso/live build run?
<mako> pitti: it's a scratch db
<mako> pitti: just go nuts
<mako> tseng: you too
<tseng> will do
<fabbione> hey mako
<pitti> mako: oh, can I actually try SQL statements that will kill the db?
<mako> tseng: there is some room for improvement but i'm thinking it's stable enough to use for the tomorrow
<mako> pitti: that bug is fixed :)
<wasabi_> heh. i can't believe i gave away the 50 warty cds I had
<pitti> mako: last time I tried to do something observable which does not actually damage anything
<wasabi_> i didn't even know I knew 50 people
<mako> pitti: either should be fine here.. this is not the live db
<mako> pitti: and the code is a lot more robust now
<mako> pitti: i spent much of last week introducing new bugs.. i mean improving it
* Amaranth has a big install fest coming up and no more ubuntu CDs :/
<mako> Amaranth: i am very low on cds
<mako> Amaranth: (that means tens of thousands)
<Amaranth> I wouldn't want to give them warty now anyway.
* mako nods
<Amaranth> I'll probably go buy 100 spindle of CD-Rs and bore myself to death burning and testing them.
<pitti> mako: one small bug so far: if I do anything wrong (invalid number or so), my country setting is forgotten
<Kamion> wasabi_: no idea, I don't actually own any serial console hardware ...
<mako> pitti: yeah. i noticed that too.
<Kamion> fabbione: 
<Kamion> 21 8 * * *      /srv/cdimage.no-name-yet.com/bin/cron.daily
<Kamion> 1 8 * * *       /srv/cdimage.no-name-yet.com/bin/cron.daily-live
<Kamion> 17 12 * * 6     /srv/cdimage.no-name-yet.com/bin/cron.weekly-dvd
<Kamion> 14 5 * * *      /srv/cdimage.no-name-yet.com/bin/cron.kubuntu-daily
<Kamion> 1 6 * * *       /srv/cdimage.no-name-yet.com/bin/cron.kubuntu-daily-live
<Kamion> fabbione: (colin.watson@canonical.com--2005/cdimage--mainline--0, etc/crontab)
<Kamion> er, s/2005/2004/
<lamont> Kamion: speaking of cdimage...
* lamont will pester Kamion post-preview
<fabbione> Kamion: thanks :-)
* Kamion argues with somebody mailing owner@bugs.debian.org about how he doesn't understand shell pathname expansion (I paraphrase). sigh.
<Kamion> "no, tr [A-Z]  [a-z]  is Just Wrong"
<Kamion> lamont: hopefully post-preview I'll have the time to try following the procedure myself :-)
<lamont> Kamion: heh.  yeah
<lamont> wow. 47 deg F -> 37 deg F in 15 minutes
<mako> Community Council Meeting in #ubuntu-meeting
<mako> And Community Council Meeting Time is... PARTY TIME
<mdz> lamont: wtf, re: imlib+png2
<mdz> lamont: it built for me locally
<mdz> lamont: can I get config.log?
<lamont> mdz: I think so... second
<mdz> er
<mdz> lamont: which package was that log snippet from?
<lamont> mdz: snippet was from imlib
<mdz> lamont: imlib+png2?
<lamont> config.log is at p.u.c/~lamont/logs/imlib+png2.config.log
<lamont> yeah
<mdz> http://people.ubuntu.com/~lamont/buildLogs/i/imlib+png2/1.9.14-16ubuntu1/
<mdz> but it succeeded
<lamont>       467 Log for failed build of imlib+png2_1.9.14-16.2ubuntu1 (dist=hoary)
<lamont> but that's newer
<lamont> and is the version you uploaded...
<mdz> oh, the dirindex isn't sorted in version order in this case
<lamont> correct
<lamont> dirindex is, sadly, alphasort
<mdz> I see, I had libpng12-dev installed
<mvo> mdz: can I talk to you about #5737 (nessus-plugins) when you have time?
<mdz> lamont: do you know if -I/usr/include/libpng10 or s/png/png10/ is the correct fix?
<lamont> mdz: dunno off the top of my pointy
<lamont> -I/usr/include/libpng10 will get you the files
<lamont> if it was a question of /usr/include/libpng vs /usr/include/libpng10, that is....
<mdz> yeah, it works either way
<mdz> it was a question of changing the include path or the include preprocessor statements
<mdz> I went with the former
<mdz> uploaded
<lamont> ah, ok.
<seb128> archive.u.c is lagging ?
<lamont> seb128: on days like this, I kinda expect it.
<seb128> k
<lamont> seb128: "like this" == lots of packages to mirror, and everybody and their grandmother downloading
<seb128> yeah
<mdz> lamont: fixed imlib built
<lamont> mdz: then whatever we depwaited on it should build right after :03
<Kamion> mdz: can you grab a weekly DVD or two and give that a test? or shall I generate a fresh set first?
<mdz> Kamion: fresh set would be good
<mdz> Kamion: we need to write up an install test plan
<mdz> {server,desktop} via {CD,DVD}, try to get some code coverage
<dholbach> see you later
<Kamion> fresh set kicked
<Kamion> mdz: yeah, acknowledged
<mdz> I'll start rsyncing the old ones
<mdz> er
<mdz> Length: -1,549,498,368 [application/octet-stream] 
<mdz>     [ <=>                                 ]  0             --.--K/s
<mdz> 09:11:01 (0.00 B/s) - `hoary-install-amd64.iso' saved [0/-1549498368] )
<mdz> either wget or apache is b0rked on large files
<lamont> lol
<Mithrandir> url?
<Kamion> I thought apache got fixed
<fabbione> i had say apache 
<Mithrandir> yeah, a2 is b0rken
<mdz> looks like apache
<Mithrandir> you need 2.2
<mdz> Mithrandir: http://cdimage.ubuntu.com/weekly-dvd/current/
<Kamion> $ HEAD http://cdimage.ubuntu.com/weekly-dvd/current/hoary-install-amd64.iso
<Kamion> 200 OK
<Kamion> Content-Length: 2745468928
<Kamion> [...] 
* Kamion blames wget
<fabbione> mdz: afaik thom installed 2.2 on people only for testing
<Kamion> fabbione: nope, he installed it on cdimage too
<mdz> Kamion: firefox broke too
<fabbione> o
<mdz> I'm using rsync now
<Kamion> go LFS, it's your birthday
<Kamion> mdz: try downloading stuff on an amd64 box instead to avoid the problem? :-)
<mdz> 20th birthday maybe
<mdz> nah, I'll just tie up an rsync slot for an hour, thanks :-P
<mako> so, is elmo going to reappear today?
<mdz> mako: I understand he's at the data centre
<mako> i rather badly need a new version of shipit installed today
<mako> so i can reset the database for hoary orders tonight before we announce the preview tomorrow
<mako> think i should sms him?
<mdz> mako: he should be textable for urgent stuff
<mako> to put it on his radar?
<mako> it's "Today" urgent.. not "right now" urgent
<mdz> hmm, I should be rsyncing this DVD onto a CD iso
<mdz> Kamion: so I guess we're going to delay the release of the combo DVD
<Kamion> for what?
<lamont> mako: so shipit is still warty orders?
<mdz> Kamion: because we haven't even tried it yet? :-)
<Kamion> the one you're rsyncing is a combo
<Kamion> minor details :-)
<mako> lamont: like for hours
<mdz> oh, that's why it's so huge
<mdz> I didn't realize you'd done that
<mako> lamont: but no.. we're out of cds
<Kamion> I'm happy not to release it this time round, but we do need to get wider testing of it if it's for hoary final
<mdz> so I should rsync it into a concatenation of install+live :-)
<lamont> mako: heh
<mako> lamont: i have a special reserve :)
<Kamion> yeah, I thought I'd mentioned it
<Kamion> mdz: yes :-)
<mdz> I don't think DVD is critical for preview
<Kamion> that should work rather well actually
* lamont was gonna order hoary disks, but I guess not today
<mako> lamont: tomorrow.. or late today
* lamont still has about 20 warty CD's
<mdz> I'm completely out
<mako> i'm nearly completely out
<lamont> are we admitting to how many we pressed/shipped?
<tseng> i think we gave away most of 200 at the security conference here
<mdz> mako: you have Ubuntu CDs between the cushions of your couch
<mdz> you will be finding them for years to come
<lamont> mako: is shipit email-addr == user id, or can you change your email addr?
<mdz> your apartment is saturated
<mako> mdz: yeah.. i have a lot of them everwhere
<mdz> sabdfl: do you care if we release DVD images for preview, rather than only for final?
<mako> lamont: you can change email address
<mako> lamont: there is a uniq number i don't let you change
<mdz> sabdfl: it takes a lot of time to download and test them
<wasabi__> yay for my first ubuntu server
<lamont> mako: yeah - but that involves remembering my password... :-(
* lamont finds the magic link
<mako> lamont: you can have your passwords regenerated and mailed
<mdz> mvo: nessus-plugins?
<mvo> mdz: yes, I contacted upstream about the non-frees of the plugins and he claims that we can't distribute them. only the "nessus-plugins-gpl-2.2.3" is distriubtable according to him. I would suggest to sync nessus-plugins from debian/unstable, they removed all the non-free bits already. details are in #5737 and I can forward you the answer from Renaud (if you are interessted)
<mdz> mvo: will the plugins from unstable work with our nessus?
<aj> what's jdub's actual role/title in ubuntu?
<Mithrandir> RM, iirc
<mdz> aj: "release manager" at last count, but we're fairly fluid about this sort of thing at the moment
<aj> ta
<mvo> mdz: apparently, I updated the package and tested it. I also looked over the changed and it looks like nothing changed that could break the scripts from 2.2.0 to 2.2.3. I can double check tonight again. 
<Mithrandir> and "dog dragging shiny stuff back home, stuffing it into the distribution, breaking it", I think.
* Mithrandir hides
<mdz> mvo: ok, let's plan to sync it after preview
<pitti> lamont: did you get my mail regarding blacklisting kde-i18n-*?
<mvo> mdz: sounds good, thanks. I'll double check again tonight/tomorrow morning if it does not break anything
<lamont> pitti: and replied
<pitti> lamont: in case you didn't do it yet, there is another package that needs blacklisting: iso-codes
<pitti> lamont: oh, reading mail now
<lamont> grumble
* lamont goes to edit another 12 files.
<pitti> lamont: sorry
<Kamion> aj: I'm sure he also used to be desktop team leader, except according to the web site that seems to be one "Gill Bates" now
<Kamion> god, how do I look at the history of a page in plone?
<mdz> Kamion: cry
<Mithrandir> you could probably run less on the zodb.
<Kamion> GO ZOPE
<tseng> jdub: oh hey, in the never ending quest to get rml to bear your seed
<tseng> jdub: do you think he would be interested in making gamin <3 inotify?
<sabdfl> erm... moin isn't exactly going to keep that Gill bitch at bay, you know
<tseng> elmo: any chance you could sync f-spot 0.0.10 from sid? tia
<sabdfl> mdz: w.r.t. dvd images, as long as they get some testing before final, i don't mind
<sabdfl> the dvd images will be the ones people can choose to cover the costs of shipping and production on, so it would be awkward if they had poorer QA
<T-Bone> hi sabdfl!
<mdz> sabdfl: very few of us have the bandwidth to iteratively test them
* T-Bone has and can help as best as he can
<dredg> fantastic.
<T-Bone> Mithrandir, doko: anything new wrt lib32gcc1? :)
* dredg loves his elected representatives
* dredg kills McCreevy in the face
<Kamion> mdz: new DVD images up
<mdz> Kamion: old one still rsyncing
<mdz> eek
<mdz>   1719225600  62%   15.65kB/s   18:12:59
<T-Bone> yum
<sabdfl> mdz: let's do a DVD in two weeks when the packages themselves are really stable
<mdz> ok
<mdz> no DVD release for preview
<sabdfl> or just announce what's there now, and make changes without rebuilding the DVD, and just test one DVD per week
<sabdfl> your call
<mdz> I don't think DVD is important for preview
<mdz> and it certainly won't help the bandwidth problem
* mvo is away for ~2h
<fabbione> acutally
<fabbione> if we build the dvd daily the rsync would be way faster
<fabbione> on a weekly base the changes are too big and rsync is useless
<fabbione> (or almost)
<T-Bone> assuming they're built rsync-friendly... Haven't followed that issue, tho
<Kamion> they're as rsync-friendly as the CDs
<Kamion> which is pretty friendly
<fabbione> anyway.. i need to go and cook dinner... wife is calling :-)
<T-Bone> lol
<Kamion> I could build the DVD daily, but I'm afraid elmo would kill me for the disk space usage
<Kamion> and I really don't think people would actually download and test it daily
<T-Bone> indeed
<Kamion> maybe somewhere in between would be better, although crontab syntax gets awkward then :)
<fabbione> Kamion: indeed, but we can rsync daily.. that would make the time to sync to the latest much shorter
<Kamion> every Saturday and every Wednesday, or something
<fabbione> Kamion: what about a daily and we keep a shorter amount of previous-days stored?
<fabbione> like only one or two days?
<pitti> elmo: here?
<fabbione> sorry.. i really need to go
* fabbione &
<Kamion> fabbione: possible, I guess
<fabbione> Kamion: just an idea.. you decide ;)
<Kamion> I'll certainly think about it :)
<lamont> Kamion: combo dvd == kubuntu+ubuntu?
<lamont> or live+install?
<Kamion> live+install
<Kamion> don't really have the technology for kubuntu+ubuntu to be useful yet
<Kamion> (no means to allow picking one at install time)
<mdz> I'm getting totally crap transfer rates from cdimage now
<mdz> are elmo and thom up to no good?
<mdz> fabbione: I was rsyncing against a concatenation of the daily install+live CDs :-)
<Riddell> Kamion: some people like to install both
<lamont> Kamion: an ubuntu isnstall+live dvd that happened to have kubuntu-desktop and it's depends on the dvd as well would be really nice for release  - hell, for that matter, I'm in favor of slapping main on the dvd... but that's just me
<Kamion> Riddell: we don't have the installer tech yet to do that either :)
<Kamion> lamont: I'd have to do something like concatenating germinate output
<mdz> elmo does that already, so there's code
<Kamion> the original intention was to have main on the DVD, but then kubuntu happened :-)
<Kamion> at the moment it's just Ubuntu supported
<Kamion> lamont: but I agree with you, it'd be nice
<mdz> seb128: gtkhtml accepted
<lamont> Kamion: ubuntu+kubuntu > 4GB?
<jon1012> hello everybody :)
<lamont> Kamion: kubuntu is making me rethink my home mirror as well: main-> ubuntu-supported
<ogra> 7join #ubuntu-meeting
<ogra> ehe
<Kamion> lamont: not sure
<Kamion> grr. right, that's it, I'm fixing that stupid base-config bug when the desktop install fails
<mdz> Kamion: the one where it dumps you into aptitude? :-P
<Kamion> no, the one where it dumps you into aptitude without fixing your sources.list first
<mdz> I really don't see the point of launching aptitude
<Kamion> dumping you into aptitude is better than dumping you at a shell prompt
<mdz> if the user knows how to get around in aptitude, they know how to launch it too
<mdz> marginally
<Mithrandir> T-Bone: ia32-libs will make a lib32gcc1 package on ia64 only.  It's freaking ugly, but it should work fine.  I haven't sat down and coded it, but it should be easy enough.
<Kamion> I don't think that's true; I realise aptitude's UI is complex madness, but at least it *has* a UI and you stand some chance of discovering what to do
<T-Bone> Mithrandir: anything you want, as long as it works :)
<T-Bone> Mithrandir: need Nekkid up?
<mdz> seb128: you said +1 hour 4 hours ago; does that mean you're finished?
<Mithrandir> T-Bone: not really, no.
<T-Bone> k
<Mithrandir> T-Bone: not at the moment, at least.  I'm making dinner now anyhow
<T-Bone> hehe ok
<Kamion> mdz: so what should I do about this live CD isolinux options thing?
<seb128> mdz: if there is no ftbfs that's fine with me
<mdz> Kamion: I'm happy with it as-is until overridden by sabdfl
<Kamion> my preferred option is to add a non-default 'auto' boot option that boots into US English, and document that on the front screen
<mdz> seb128: I guess we need to rebuild evolution for the new gtkhtml?
<seb128> mdz: there is a new gdm minor release but I would like to run it some time before pushing it
<seb128> mdz: that should be done 
<Kamion> ('auto' rather than 'english' or whatever because I don't want the implication to be that we intend to create automatic boot options for every language)
<seb128> mdz: archive is lagging ?
<mdz> seb128: gtkhtml was in queue/new
<seb128> en evo has a versionned build-dep on it
<mdz> lamont: is evo auto-depwaited?
<mdz> lamont: if not, please retry it
<lamont> mdz: no email here - will check
<mdz> lamont: hmm, s/retry/dep-wait/, gtkhtml is in queue/accepted
<mdz> http://people.ubuntu.com/~lamont/buildLogs/e/evolution/2.2.0-0ubuntu1/evolution_2.2.0-0ubuntu1_20050308-1440-i386-failed
<lamont> mdz: gtkhtml3.6 is new
<lamont> will auto-launch once that's in the archive
<mdz> lamont: it already is
<mdz> see above
<mdz> that is to say, it was new
<mdz> it is new no longer
<mdz> but is not in the archive yet
<mdz> oh, yes it is
<lamont> should be now...
* lamont tickles a few buildds
<Keybuk> mdz: we almost certainly want to sync libtool 1.5.6-5 from Debian
<mdz> Keybuk: let's talk about itafter preview, and after it actually enters Debian
<Kamion> doesn't even seem to be in the queue yet
<Keybuk> ok :)  but seb128 probably won't be able to build libgnomevfs2 without it :)
<Keybuk> Kamion: it's just uploading to ftp-master now
<seb128> Keybuk: I don't relibtoolize gnome-vfs2 :)
<seb128> Keybuk: gnome-vfs2 2.10 is in hoary since yesterday
<Keybuk> fair enough; fixes the "1000 is not a non-negative integer" bug anyhoo
<xadas> hi all, i want to send some hw data but ubuntu hw manager doesn't work. [Please wait while the hardware data gets prepared]  (10 minutes and nothing)
<mdz> xadas: we aren't ready to receive that data yet
<xadas> mdz: thx
<mdz> xadas: thanks for testing, though.  we'll make an announcement about it when we're ready to receive submissions
<pitti> thom: here?
<mdz> lamont: attempting kubuntu livefs builds now; let me know how they turn out
<xadas> bug: run gedit->undock toolbar->release it somewhere / now try to dock it back :-) bug in gnome?. Same with gnome-vim
<bluefoxicy> WARNING: Failed to parse default value `(-,)' for schema (/schemas/apps/gnome-terminal/global/active_encodings)
<bluefoxicy> can someone tell me what language that is?
<bluefoxicy> it looks hebrew?
<mdz> lamont: looks like all of them have exited; did we get any successes?
<lamont> Errors were encountered while processing:
<lamont>  /var/cache/apt/archives/konq-plugins_4%3a3.3.2-1ubuntu1_i386.deb
<lamont>  /var/cache/apt/archives/kdeartwork-style_4%3a3.3.2-1ubuntu2_i386.deb
<lamont>  /var/cache/apt/archives/kdeartwork-theme-window_4%3a3.3.2-1ubuntu2_i386.deb
<lamont> which I believe are 3 of the 4 bugs from last night...
<Riddell> lamont: we could remove kdeaddons and kdeartwork from the seed
<lamont> 7304-7306
<lamont> mdz: want me to turn the crank on that?
<mdz> lamont: which?
<lamont> <Riddell> lamont: we could remove kdeaddons and kdeartwork from the seed\
<lamont> that
<mdz> sure, move them to supported
<lamont> grumble.  where are the kubuntu seeds?
* lamont bets on kubuntu-devel@...
<Riddell> lamont: http://people.ubuntu.com/~cjwatson/seeds/kubuntu-hoary/
<lamont> committed... now how long do we need to wait mdz?
<mdz> lamont: max 17 minutes, or nag Kamion
<lamont> hrm.. I have write access to the files, but not to lots and lots of stuff under {arch}
<abelli> smurfix: ping
* lamont grows impatient, finds himself tempted to just edit them.
<smurfix> abelli: here
<lamont> and he beat me to it
<sabdfl> Kamion: let's go with your approach to the isolinux live cd options, see if that makes silbs happy
<sabdfl> did morphix use isolinux too, or different boot system altogether?
<dredg> morphix used grub afaik
<lamont> kubuntu-meta_0.33 uploaded
<lamont> mdz: if cron.daily has finished, you could kick it again
<lamont> well, after cron.hourly, of course
<mdz> sabdfl: yes, morphix used grub
<mdz> sabdfl: which is the reason why it failed to boot on a variety of hardware where the Hoary live CD works
<mdz> (one of the reasons)
<sabdfl> ok. does anyone on our team track grub2?
<mdz> jbailey does
<mdz> in fact he uses it to boot his desktop, I think
<mdz> (ppc)
<mdz> speaking of which, where is jbailey?  he had connectivity issues at home, but was settled into a cafe last I checked
<sabdfl> he's out, will you ask him to keep us in the loop s we can adopt grub2 when its ready?
<T-Bone> he does
<T-Bone> but grub2 seems rather buggy afaict. And for ppc, it lacks quite a few essential features, like various FS support
<T-Bone> grub2 can't boot from anything else than ext2/ext3 fs, last time i checked
<mdz> sabdfl: yeah, from what I've heard, it is not a likely candidate for bendy/breezy/breedy/etc.
<sabdfl> ok
<dredg> bouncy?
<seb128> pitti: you can kick new language-packs if you want :)
<lamont> dredg: well, b0rky is right out. :-)
<seb128> pitti: GNOME 2.10 stuff for preview are ok
* lamont shakes his head at kdegames
<lamont> Trying patch debian/patches/02_disable_no_undefined.diff at level
<lamont> +0...1...2...failure.
<mdz> lamont: ->#kubuntu-devel, please
<lamont> doh
<mdz> lamont: how big a project would it be to email failures to the uploader?
<daniels> mdz: i suppose it would involve knowledge of whether it's an actual upload or whether it's been brought in via the autoimporter
<pitti> seb128: I wait until tomorrow
<lamont> mdz: that's an archive project
<pitti> seb128: and I have to update the import scripts before
<lamont> well, maybe not.
<mdz> daniels: uploader if they're in the whitelist, otherwise a mailing list or such
<lamont> mdz: the only worry would be to make sure that the uploader was the correct email, and not someone else (like the debian developer...)
<mdz> lamont: I think the whitelist should take care of that
<lamont> yeah
<lamont> using katie's whitelist?
<mdz> and a little gzip+MIME love to make the sizes more reasonable
<mdz> right
<lamont> bzip2, dude. :-)
<seb128> pitti: k
<lamont> mdz: there does exist a little bit of confusion that way, because of the arch: all packages (which fail on 3/4 of the architectures, most of the time - sometimes they get built before the !i386 machines get to them..)
<lamont> and, of course, for the normal ftbfs failure, you'll get 4 copies of the failure.
* lamont will need to discuss with elmo how this fits into the DC infrastructure/dmz-maze.
<lamont> but beyond that, it shouldn't be too difficult
* T-Bone sees fedora opening an ia64 dev mailing list, shrugs
<lamont> mdz: hrm... logfile doesn't have the uploader address in it... that makes things a bit more ugly, at least for my side of things.
<tritium> mako, I got my key signed.  I'm strongly connnected now :)
<lamont> mdz: and note that our, um, fix, is rather abusive to emacs21, and means anyone hacking on it needs to go through a bit of pain.
<lamont> specifically, reversing our fix, debian/rules clean, reapply our fix.  or evilness happens.
<Kamion> sabdfl: ok, will do
<sabdfl> cool
<mdz> lamont: kubuntu-live*4 in queue/accepted
<lamont> mdz: and awaiting cron.daily?
<mdz> lamont: yep
<mdz> Kamion: shall we put together a preview candidate and call for testing?
<mdz> looks like everything is in
<mdz> oh, except langpacks
<mdz> pitti: when do you expect to have updated langpacks uploaded?
<mdz> pitti: bod seems to have a fix for the perl FTBFS issue, good
<Kamion> mdz: hang on, bit of stuff still to do for this live CD thing
<daniels> mdz: i'll be out all day; working a bit while I'm out, but doing the bulk of my work later on in the day
<daniels> mdz: (bulk of my work -> triaging a hojillion bugs)
<mdz> daniels: the only one I'm curious about for preview is the german keymap one
* lamont schedules kubuntu-live rootfs builds
<daniels> mdz: still haven't worked that out, but will probe further
<Kamion> the fact that we're using pc104/pc105 keymaps on powerpc worries me in general
<Kamion> shouldn't it be macintosh?
<thom> Kamion: to get torrents to work right and be auto-triggered we need a third, minimal rsync target; basically just current for daily and sounders/arrays/whatever, and releases
<mdz> dunno
<thom> is that do-able?
<mdz> my keyboard is a pc105 and I use it with a G4
<daniels> Kamion: my understanding was that modern (non-adb-based) macs used pc105 just as well as, if not better than, macintosh
<Kamion> thom: noted, I'll have a look
<mdz> thom: can we do it with --exclude/--include?
<Kamion> daniels: hm, ok
<Kamion> mdz: not with restricted ssh keys, I imagine
<Kamion> hardlinked rsync targets are doable
<daniels> Kamion: happy to be proven wrong, however
<Kamion> grr, I'm beginning to run out of kernel argument space
<lamont> Kamion: that's tunable, yes?
<Kamion> nope, hardcoded in the kernel
<Kamion> they increased it in 2.6.11, though, I think
<Kamion> if I could use a preseed file, this would be saner, but currently I can't for stuff that early
<Kamion> should be able to fix that in breezy though
<Kamion> sabdfl: hmm. This is more problematic than I thought; the new keyboard chooser is more difficult to preseed (partly because the raw keyboard names differ between AT and USB keyboards), and trying to do so causes me to run out of kernel argument space. I have a strategy to fix it (alter the initrd-preseed package to allow selectable preseed files in the initrd, and go from there), but I think it's best left until afte
<Kamion> although, hm, I could possibly use kickstart to do it
<Kamion> wonder if that would work
* mdz 's eyes go wide with fear
<lamont> mdz: i386 is building locales
<mdz> lamont: yay!
<mdz> lamont: are the others chugging away?
<Kamion> mdz: fancy a live CD mode that gets a Kickstart file off the CD-ROM as its first action? :-)
<Kamion> it'd probably actually work
<mdz> Kamion: sounds like a good plan for breezy
<Kamion> ... oh, except that kickseed only preseeds console-keymaps-at/keymap, not the others; that was silly of me
<Kamion> ok, we'll go with my previous plan for post-preview then if there are no objections
<lamont> mdz: well, weddell finished already, but we kinda expected that.... :-)
<mdz> I've removed weddell from my script :-P
<mdz> temporarily, of course
<mdz> because I know there are legions of ia64 users hungry for live CDs
* lamont believes that there are more hppa users who want it than ia64 users... :))
<thom> i can't believe there are legions of hungry ia64 users - they can use the fricking machine to cook on without problems
<lamont> thom: itanium was the hottest chip on the market when it shipped.
<mdz> it still is
* lamont had thought one of the amd64 chips out heated it.
<mdz> fifty thousand watts of mind-boggling slowness
<lamont> or maybe it was some other vendor's custom CPU.  can't remember
<pitti> mdz: I'm still at updating the langpack-o-matic scripts (implementing new spec), but I can generate new packs at any time
<thom> lamont: amd64 is pretty cool actually
<lamont> yeah - was someone's...
<mdz> > The world's first live CD that allows users to save their data back to the CD has been born.
<mdz> that's actually a damn fine idea
<pitti> mdz: however, I'd like to wait until all packages are uploaded
<Kamion> mdz: terrifying
* mdz adds it to the list for UDU
<pitti> mdz: perl> bod pinged me nad there is a new sid upload; will do this tomorrow
<Kamion> if the burn goes wrong, you're toast
<lamont> mdz: uh... that scares me...
<thom> it'd be an impressive trick for a cd-r...
<mdz> Kamion: yeah, it gets rid of that pesky "no risk" live CD angle
<Kamion> unless it does weird multisession tricks
<mdz> I'm sure it does multisession
<mdz> but I think that if you screw that up, you're still toast
<lamont> brings new meanings to "having a backup"
<Kamion> "a backup system, somewhere else"
<lamont> heh
* lamont screams, notes that amd64 is leading the race
<lamont> i386 and powerpc restarted, this time they should actually get 0.33 :-(
<mdz> er
<mdz> lamont: how did they get that far if they didn't get 0.33?
<pitti> thom: can you install packages in the dchroots?
<lamont> they die _installing_ kubuntu-desktop, not before
<lamont> duh :-(
<lamont> kinda woke me up too.
<pitti> elmo: ping
<elmo> pitti: ?
<pitti> elmo: can you please install me some build-dependencies in concordia's hoary dchroot?
<pitti> elmo: I need the build-deps for http://people.ubuntu.com/~pitti/todo-rebuild.txt
<pitti> elmo: this is the list of packages that failed to build today
<sabdfl> can it put "it will probably work" on the Quotes page?
<sabdfl> Kamion: your call
<sabdfl> just trying to find low-hanging fruit to make the new livecd *feel* faster, much like the reboot stuff
<sabdfl> even though the new tech is much better, it feels like a regression to joe user to have the questions
<sabdfl> if there's no low-hanging fruit, don't climb up into the branches on my account at this stage
<dholbach> hai mvo
<mvo> hey dholbach 
<ogra> has anybody else problems with gpg ?
<mdz> sabdfl: if it's really that important, there is low-hanging fruit where we can get real performance gains out of the live CD
<Kamion> sabdfl: nod, filing a bug to let us track it
<mdz> sabdfl: but please not for preview
<sabdfl> mdz: np
<ogra> i cant sign anything anymore and in  ~/.gnupg i have pubring.gpg~ and pubring.gpg.tmp suddenly, but pubring.gpg has 0 bytes
<mdz> I have not yet begun to optimize
<Treenaks> ogra: replace pubring.gpg by pubring.gpg~ -- but ONLY if there are no gpg processes running
<Treenaks> ogra: (i.e. restore the backup -~ file)
<mdz> bear in mind that the new live CD *does* a lot more than the warty one
<ogra> Treenaks: i know how to solve it
<mdz> if performance is more important, I can turn some of that stuff off
<ogra> Treenaks: but this simply shouldnt happen without a good reason....
<Treenaks> ogra: like, killall -9 gpg or something
<Kamion> #7336
<mdz> sabdfl: for example, it automagically configures the panel to have the battery applet if you're on a laptop
<mdz> that takes a few seconds
<ogra> Treenaks: nope, not running....
<dredg> mdz: it depends on what kind of hardware this is being aimed at.
<mdz> I could do the user creation stuff with lower-level tools; it takes a long time to load adduser off of the CD
<mdz> my focus was on clean design and a reasonable feature set, not performance
<lamont> This filesystem will be automatically checked every 31 mounts or
<lamont> 180 days, whichever comes first.  Use tune2fs -c or -i to override.
<lamont> woot!
<ogra> Treenaks: i suspect evo messed it up...
<elmo> pitti: done on both chroots
<pitti> elmo: thanks
<zul> later
<lamont> woot filesystem even
<mdz> wewy nice
<lamont> so amd64 will be done pretty soon - that's the last text before we begin rsync'ing to the (new) filesystem image
<mdz> let me know when we're ready to kick off a new set of live CDs
<lamont> yeah
<lamont> or do you want to know when amd64 is done, since the other 2 are behind by ~20 minutes?
<mdz> Kamion: given the deferral of the live CD madn^Wenhancements, can we agree to a freeze and a test cycle?
<mdz> lamont: I just want to know when they're all done
<lamont> ok
<HiddenWolf> is anyone writing up the improvements warty -> hoary ?
<Kamion> mdz: yep, certainly. I'm just building Kubuntu install CDs now, as soon as that's finished I'll switch to building Ubuntu stuff
<Kamion> mdz: oh, I need a d-i rebuild
<Kamion> just kicked one off
* Riddell hugs Kamion for putting kubuntu first :)
<mdz> Kamion: better get it in before elmo falls over
<mdz> Riddell: kubuntu is the squeaky wheel at the moment :-)
<lamont> amd64 compressing
<elmo> mdz: don't worry, I've got several server boxes to sleep in - I'm sorted
<mdz> elmo: nothing like a warm box after a transatlantic flight
<mdz> Riddell: kuickshow and kview are scheduled to move out to universe unless you want them
<Kamion> Riddell: you just got there first, is all ;)
<Riddell> mdz: out they go please
<mdz> lamont: we'll want to roll a new Ubuntu live fs as soon as kubuntu is done
<lamont> sure, np
<mdz> HiddenWolf: the documentation team has a set of release notes; they're part of the desktop install now
<mdz> HiddenWolf: mako is working on a preview release announcement
<lamont> mdz: ok to kick the ubuntu livecd image?
<lamont> fsimage, that is
<lamont> figured I'd let amd64 stay ahead...
<mdz> lamont: yep, whenever you're ready
<jdub> morning all
<thom> no it's not
<lamont> mdz: ubuntu builds queued up waiting for the kubuntu build to finish on i386, ppc.  ia64 building
<lamont> s/ia64/amd64/
* lamont needs to go fetch a kid from school pretty soon
* lamont checks to see if the wife is available to do it
<mdz> lamont: how will I know when they're done?
<ogra> jdub: morning
<Kamion> elmo: d-i builds should be there; can you let me know when they're byhanded, and I'll start a test candidate run?
<lamont> wife available. /me stays
<T-Bone> lamont: wife exited with status 0? :^)
* T-Bone ducks
<elmo> Kamion: a ubuntu21?
<Kamion> elmo: no, a triggered daily
<Kamion> ubuntu20.something
<lamont> wow. that's a collection of languages on the livecd
<elmo> will that have broken if I didn't process the existing daily build?
<Kamion> um. oh.
<Kamion> I guess so.
<elmo> (to be fair I was over the atlantic at the time it appeared ;)
<Kamion> sowwy ...
<elmo> I'll process it now and you can try again?
<Kamion> ok
<Kamion> hopefully w-b won't be too confused by the whole deal
<lamont> [ if cron.daily runs after the d-i daily build, but before it is byhand-ed, then a subsequent d-i daily build uses the same binNMU number.  if you launch 2 before cron.daily runs, then it gets the right binNMU number... ] 
<lamont> I suppose I could keep state outside of w-b...
<lamont> Kamion: do we care enough to tweak this post hoary?
<lamont> or post preview, or...
<Kamion> I was kind of thinking of writing a katie patch that taught it how to process raw-installer automatically
<lamont> btw, what exactly is done with that?
<Kamion> which would render that by and large irrelevant
<Kamion> with what?
<lamont> the d-i upload
<lamont> where does the tar.gz go?
<Kamion> unpacked into dists/hoary/main/installer-$arch/
<lamont> ah, ok
<dholbach> elmo: could you please sync zvbi and gtranslator from sid, if you find the time?
<mako> mdz: oh wait
<mako> mdz: is there a final verdict on architectures we'll be printing up and shiping?
<mdz> mako: same as warty
<mako> mdz: good
<elmo> dholbach: gtranslator is in main - that'll need approval
<dholbach> elmo: oh ok... sorry
<elmo> dholbach: zvbi done
<dholbach> elmo: i'll have another look what the issue with gtranslator was
* T-Bone will wait post-preview to upload efibootmgr
<dholbach> elmo: thanks
<smurfix> Kamion: Can you tell me which preseed arguments the keyboard chooser now needs vs. what it needed before? Maybe I can fix that
<Kamion> smurfix: kbd-chooser/method="big long string"
<Kamion> smurfix: I realise that it can take kbd-chooser/method=us etc., which is cool
<Kamion> smurfix: but that doesn't really work in this use case, because console-keymaps-at requires "us" while console-keymaps-usb requires "mac-usb-us"
<Kamion> so the keymaps have to be preseeded separately anyway
<windows-farhan> question does any of the ubuntu versions have speakup support for the blind so i don't waste a cd burning useless stuff. lol
<Kamion> smurfix: as it turns out I doubt kbd-chooser is going to block me, I'll just invent a way to put multiple optional preseed files in the initrd
<mdz> lamont: any joy for kubuntu cloops?
<windows-farhan> ok..ight
<Kamion> windows-farhan: one sec
<windows-farhan> k
<lamont> kubuntu is happy
<mdz> windows-farhan: http://www.ubuntulinux.org/wiki/AccessibleHoaryLiveCDDerivitive
<windows-farhan> wait
<windows-farhan> is there a installer version i can grab?
<windows-farhan> i wana instal it. 
<mdz> windows-farhan: there is not currently an accessible installer
<lamont> amd64 is setting up libsane, i386 is building locales, and ppc is chunking along trying to keep up with its big brothers
<windows-farhan> uh
<mdz> lamont: oh, kubuntu is done x3?
<windows-farhan> wiat. how do i actually use this. oh hell i'll go to the website
<windows-farhan> thanks
<lamont> kubuntu x3
<mdz> ok
<mdz> Kamion: safe to kick off kubuntu live CD builds?
<lamont> ppc is actually downloading ubuntu debs atm
<mdz> load average on little looks relatively safe
<windows-farhan> crap
<windows-farhan> it didn't coppy
<Kamion> windows-farhan: http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004516.html
<windows-farhan> can you throw me that link again? please?
<Kamion> mdz: sure
<Kamion> windows-farhan: http://www.ubuntulinux.org/wiki/AccessibleHoaryLiveCDDerivitive
<Kamion> sigh, I hate misspelled URLs
<Kamion> misspelled wiki pages, rather
<mdz> heh, I didn't even notice, I copy/pasted from google
<windows-farhan> wow
<smurfix> Kamion: OK.
<windows-farhan> i'm going to get this. and how?
<windows-farhan> hmm
<windows-farhan> arg
<windows-farhan> the link is broken
<mdz> windows-farhan: we're in the middle of some development work right now, please take this over to #ubuntu
<mdz> Kamion: hmm
<mdz> Kamion: cron.kubuntu-daily-live just failed due to ia64
<mdz> Kamion: and didn't go on to try powerpc, which should have worked
<Riddell> you can remove kdegames if you need a more space
<mdz> 588M hoary-live-amd64.iso  571M hoary-live-i386.iso
<mdz> looks OK
<Kamion> mdz: damn. ok, I'll look
<mdz> Kamion: go ahead and kick off a kubuntu-daily-live build when you're ready
<mdz> lamont: ubuntu cloops ready?
<Kamion> haha, ok, my new code fell over. whoops
<doko> mdz: ok to upload linux-meta to add the avm-fritz-firmware package (fabbione did agree)?
<mdz> doko: after preview
<doko> I'd like to have at Cebit for presentation, if at all possible
<mdz> doko: when is cebit?
<lamont> mdz: amd64 done, i386 in partimage, ppc in locale generation
<doko> starting this thursday, I'm there friday, as a fallback I can present from a notebook, but the cd as a handout would be nice.
<mdz> Kamion: looks good
<mdz> 565M hoary-live-amd64.iso   43M hoary-live-ia64.iso
<mdz> 550M hoary-live-i386.iso   622M hoary-live-powerpc.iso
<mdz> two guesses which one is broken
<dholbach> seb128: libxml++2.6 is universe, so no worries for you anymore :-)
<seb128> dholbach: cool
<Kamion> I wonder why it published ia64
<Kamion> oh, it had a cloop, it was just empty
<pitti> seb128: gwenview's po file layout in the source package does not fit into my scripts; this one must stay obsolete, I'm afraid
<seb128> pitti: is that a package name ?
<seb128> dunno about it
<elmo> it's a kde thing
<T-Bone> Kamion: i expect that the cloop issue to be resolved when we'll have proper language-support on ia64. I wonder whether the firefox locale issue is just pending ooffice support, actually
<lamont> mdz: i386,amd64 done.  ppc in scrollkeeper purgatory
<pitti> seb128: source package name
<T-Bone> (sort of)
<Kamion> mdz: ok, that shouldn't happen again
<pitti> seb128: oh yes, seems to belong to kde
<seb128> pitti: k, I don't know about it, so I don't care :p
<elmo> Kamion: oh, crap, sorry, I forgot to mention, you can d-i at will
<pitti> seb128: never mind, then
<elmo> \o/
<pitti> mdz: when shall I do new langpacks? now or tomorrow (i. e. in about 10 hours)?
<pitti> Kamion: ^
<mdz> pitti: now would be best, if possible
<mdz> seb128 says he is finished with GNOME
<pitti> mdz: they are still not perfect, but should do pretty well
<pitti> mdz: I'm almost inclined to do new base packages... 
<Kamion> elmo: cool, running now
<elmo> mdz: oh no! who are we going to sucker into doing that insane number of uploads now??
<pitti> elmo: I can wait a bit if necessary
<elmo> pitti: ? huh?  I was trolling mdz, poorly, ignore me
<pitti> elmo: or just do new update packages (which means wasting space, but the heck with it)
<mdz> jbailey: can you provide any insight on the canadian keyboard layout issue on ubuntu-devel?
<jbailey> Lemme look.  I had let u-d slip over the last 2 days.
<mdz> elmo: when would be the best time for the mirror hit to regenerate new base langpacks?
<Kamion> cjwatson@little:~/cdimage/scratch/kubuntu/live$ ls
<Kamion> amd64.cloop  amd64.manifest  i386.cloop  i386.manifest  powerpc.cloop  powerpc.manifest
<Kamion> much better
<Kamion> elmo: d-i builds ready for love
<jbailey> mdz: Ah.  Those are French Canadian keyboards, and I don't think they're in common usage, but I haven't done any work in hardcore French areas.  Even the Alliance Franaise in Toronto doesn't use those.
<elmo> mdz: for who?  us or them?  for them, doesn't matter - for us, sometime not near an array/milestone release
<jbailey> (still working my way through the thread)
<mdz> pitti: sounds like today is better than tomorrow
<pitti> mdz: I'm already at it
<pitti> mdz: however, there are so many updates, I just build a clean set of new base packages and empty updates
<mdz> jbailey: I think it comes down to a question of nomenclature
<mdz> jbailey: and choosing the best default
<mdz> pitti: right, that's what I meant
<pitti> mdz: okay, please distract elmo for a minute, I push the trigger now :-)
<mdz> elmo: uh, why is load on jackass 45.3?
<elmo> it's not?
<mdz> pitti: QUICKLY
<elmo> bah
<mdz> my distraction did not last very long
<elmo> y'all suck
<T-Bone> lol
<elmo> mdz: next time choose a host I won't have multiple shells open on
<Loevborg> the old two-headed monkey trick usually works better.
<Kamion> hahaha
<pitti> Loevborg: two heads? that's a new one then
<mdz> elmo: I don't have accounts on machines like that, it wouldn't be convincing
<mdz> lamont: all done?
<lamont> ppc is in partimage
<lamont> figure about 5-10 more minutes
<mdz> ppc sure does take its time
<lamont> eta is 3 min on the partimage restore, then we have to compress.
<pitti> mdz: uploads done
<mdz> I suppose slow is better than randomly-segfaulting
<lamont> mdz: that's 'slow and occasionally SIGILLing'
<lamont> although not so much recently
<lamont> or maybe not - I masked myself from seeing that... 
<Kamion> heh. "SIGILL? what SIGILL?"
<ari> it must be sick
<lamont> Kamion: the autodepwaiter tells those to retry. :-)
<elmo> Kamion: done
<lamont> mdz: go
<mdz> lamont: going
<Kamion> elmo: thanks
<Kamion> hey, locking in a cdimage script
<Kamion> THAT MUST BE REMOVED IMMEDIATELY
<Kamion> lamont: how come the ia64 d-i dailies seem to start at .200503080, etc.?
<mdz> Kamion: oop, did I step on your toes?
<elmo> kamion: I don't know, but it's driving me nuts
<lamont> Kamion: because when it ran, there was a .YYYYMMDD already in existance sometime in the past, on YYYYMMDD
<lamont> the only way to do a second d-i build that day is to either steal tomorrow, or add a trailing 0.  once you add the trailing zero, you can't remove it.
<lamont> and, no, you only have _DIGITS_ to use in that field
<Kamion> mdz: no, I was just running anonftpsync to see what installer-* looked like
<Kamion> lamont: um, the sequence in daily-installer-ia64 is 200503070, 200503080, 200503081
<Kamion> lamont: I don't see how that tallies?
<Kamion> lamont: oh, never mind, I understand
<Kamion> 200503081 > 20050309
<lamont> yeah, somewhere back when we did '20050306' and 200503060
<lamont> exactly
<lamont> therefore it's 200503090
<lamont> and if it causes too much stress, then you do a sourceful upload
<Kamion> lamont: right, you told me this a while back, but I forgot the explanation 'cos it's, err, so obvious. :-)
<lamont> ugly hacks have a way of compounding themselvesd
<lamont> Kamion: if you want, I could change it to a consistant YYYYMMDDHHmm :0)
<Kamion> lamont: let's not, eh? :)
<lamont> 'k.
<Kamion> mdz: live seems done, I've kicked an install CD build
<Kamion> that'll be a while, so I'm taking a break, back in an hour or so
#ubuntu-devel 2005-03-20
<pitti> night everybody
<dholbach> good night pitti 
* HiddenWolf wonders how long it will be untill amd64 is the primary arch
<sabdfl> night all
<jon1012> good night everybody :)
<dholbach> i'm off too
<dholbach> good night
<doko> mithrandir: ping?
<Kamion> HiddenWolf: shrug, I test i386 images on my amd64 at least half the time ;)
<Kamion> they're quicker to burn than the amd64 images, and the amd64 is quicker at testing them ...
<zenwhen> whats the name of the default theme used for KDE in Hoary?
<Riddell> zenwhen: plastik style, crystal icons
<zenwhen> I assume it is the one I see k3b using.
<Riddell> zenwhen: if it's horrible then that's keramik from kde 3.3
<zenwhen> it doesnt look half bad for a kde theme
<Riddell> must be plastik then
<HiddenWolf> kamion: what i ment was; intel will get those x64 celerons out, and after that, i'll be watching to see how long it takes for 64bit to mature
<zenwhen> I am buying Intel's first dual core chip.
<HiddenWolf> I want to see that amd64 4200 with sse3 et all. :)
<HiddenWolf> btw, media is saying dual core won't be good on the desktop for the forseeable future, how is that under linux? it seems better suited to it.
<shaya> has anyone ever ever configure a linux fiber san?
<HiddenWolf> Anyone here?
<mdz> Kamion: why quicker?  the i386 and amd64 ISOs are very nearly the same size
<HiddenWolf> mdz, can you check something for me?
<seb128> mdz: are we rolling the preview iso now ? 
<seb128> mdz: or these are pre-preview isos ?
<mdz> seb128: pre-preview
<mdz> seb128: why, is there something you would like to upload?
<HiddenWolf> seb128/mdz: if you guys select the applications menu, does the text turn white? does the same happen for places/system?
<seb128> grab and include some "System" translations for the menu
<mdz> HiddenWolf: we're preparing for the preview release and quite busy at the moment; please try to restrict conversation to development topics, and take other subjects to #ubuntu
<seb128> and change the warty about to hoary
<HiddenWolf> mdz: I want to know if it's a bug or something, sorry
<seb128> ie: a gnome-panel upload
<mdz> seb128: ok, but the translations will require new langpacks
<seb128> hum
<seb128> these are details, so that's as you want
<mdz> it would be good to have the translations in the archive so that they will go into the next set of langpacks
<seb128> k
<Kamion> mdz: *shrug* if I can save 20MB, I see no reason not to do so
<seb128> is that ok tu upload now ? or is there a freeze to get the same content for differents images ?
<elmo> Kamion/mdz: you guys need anything from me for preview of doom before I run away?
<mdz> elmo: not unless Kamion needs to do another d-i upload
<Kamion> not as far as I know
<mdz> seb128: that's fine
<seb128> k, I'll upload in ~30min so
<Kamion> and in the event of an emergency I can probably guess at what needs to be done / bug thom
<lamont> mdz: fyi - off to fire training in about 40 minutes, gone until probably 2230 local
<elmo> Kamion: not sure thom's anymore awake than me, but mdz has supah-fly katie powahs atm
<mdz> get 'em while they last
<Kamion> elmo: oh of course, thom's in the DC too, oh well
<elmo> Kamion: ha ha.  no he's not, but he muttered about going to bed early when he left
<elmo> SEVERAL HOURS AGO
<Kamion> I can probably make a good guess at what d-i byhand processing requires, but I have no intention of trying right now :-)
<elmo> </bitter ;>
<Kamion> heh
<elmo> I put my cheet sheeti n ~james/ on jackass I think
<Kamion> elmo: speaking of, if I hacked up katie to do that automatically for raw-installer, would you take that patch?
<ajmitch> elmo: sync for universe still? I've just uploaded gnue-common, gnue-forms, gnue-appserver to sid
<elmo> Kamion: if it was sane, sure
<ogra> ajmitch: we havent defined a real freeze for universe yet
<Kamion> mkay
<ajmitch> ogra: I know, it's on the agenda for next weeks meeting, iirc
<Kamion> since that was kind of the point of the raw-installer change ;)
<ogra> ajmitch: since there is a lot to do it will probably require newer versions more often....so i would call it a "soft freeze"
<Kamion> gar, it would be nice if dak CVS were actually sanely usable by non-committers though
<ajmitch> ogra: quite a slushy freeze then?
<elmo> Kamion: how do you mean?
<elmo> there's a package in the archive now :P
<elmo> well not our archive, but stil
<Kamion> cvs server: failed to create lock directory for `/cvs/dak/dak' (/cvs/dak/dak/#cvs.lock): Permission denied
<lamont> hrm.. we used to call those 'chill's.
<elmo> Kamion: as you or anoncvs?
<elmo> if you, surely that's a problem for everything you don't have write privs to?
<Kamion> elmo: hm, as me; is anoncvs liable to work better?
<ogra> ajmitch: lets call it a freeze, behave like in a freeze, but keep in mind that we wont be able to really freeze, since i suspect we will fix things until the last day
<ajmitch> ogra: alright
<ogra> ajmitch: simply to many packages
<elmo> Kamion: anoncvs definitely works
<Kamion> elmo: ah, ok, I'm just being special then, thanks
<Kamion> yeah, that works
<lamont> ogra/ajmitch: speaking of universe... I occassionally give everything back in universe, just to see what else falls out...
<dholbach> lamont: i dont understand
<ajmitch> lamont: where do you keep the lists of unbuildables? and is there a list of uninstallables somewhere?
<ajmitch> dholbach: push unbuilt packages back to the buildds
<ogra> ajmitch: Kamion will assemble one if i understood it right
<ajmitch> great
<dholbach> oh yes, good
<ajmitch> another MOTUTodo list :)
<ogra> ajmitch: so lets be patient ;)
<Kamion> er, well that's the plan, it's in the ever-growing pile I affectionately call my to-do list
<lamont> http://people.ubuntu.com/~lamont/buildLogs/List/hoary.all.i386 (etc)
<lamont> if it's marked Building, and someone didn't upload it recently, then it's really 'Failed'....
<Kamion> use apt-cache unmet or something like that in the meantime
<lamont> those are the ones I give back
<ogra> Kamion: thats why i said patient :)
<lamont> likewise, http://people.ubuntu.com/~lamont/buildLogs/List/hoary.building.i386
<Kamion> although apt-cache unmet bitches about all kinds of stuff nobody cares about, like unsatisfied Suggests
<ogra> we have enough to do to fill the time :)
<lamont> is shorter. :-)
<ajmitch> lamont: thanks
<lamont> er, s/List/Lists/
<ogra> lamont: what means "not ours" in a failed list ?
<Kamion> mdz: cron.daily done
<dholbach> now really *wave*
<ogra> night dholbach
<ajmitch> night dholbach 
<zul> hey
<lamont> ogra: architecture not specified in arch list
<ogra> ah
<lamont> but not in PaS
<ogra> PaS ?
<lamont> Packages-arch-specific
<lamont> if a package is in PaS, then it won't even be in the list.
<lamont> oh, and arch-all packags are only in the listings when they haven't been built - they're only built on i386
<ogra> yup, thats oune i figuread already :)
<ogra> lamont, thanks :)
<zenwhen> wow
<zenwhen> k3b realy slowed down a lot
<zenwhen> my dvd burner wont burn over 2.4x now
<zenwhen> even though its an 8x burner
<Kamion> mdz: what time will preview be?
<jdub> Kamion: some time after 10am UTC, at least :)
<Kamion> what's at 10am UTC?
<jdub> gnome 2.10
<Kamion> heh, ok :)
<Kamion> last time round was 4pm UTC IIRC, but I might not RC
<jdub> yeah, it was
<jdub> we should aim for earlier though
<jdub> that kinda sucked for europe
<Kamion> full set of CD builds takes around an hour nowadays
<Kamion> need to take that into account
<Kamion> jdub: if most stuff is done, we should probably freeze for all but emergency stuff and new GNOME tarballs now so that people can test the pre-preview candidate
* ..[topic/#ubuntu-devel:Kamion] : 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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/20050308.1/, http://cdimage.ubuntu.com/daily-live/20050308.2/
<jdub> Kamion: yeah; i have an ubuntu-artwork to go in
<jdub> other than that, i can't think of anything important
<jdub> (that isn't dangerous)
<seb128> 'night
<Kamion> ubuntu-artwork is always last :P
<jdub> ;)
<jdub> seb128: dude
<jdub> seb128: thanks :-)
<mdz> Kamion: 10am UTC works for me
<jdub> seb128: and have a very good sleep :-)
<lamont> seb128: good long hard work.
* lamont is glad he isn't seb.
<seb128> jdub: Thanks :)
<Kamion> mdz: we will need to check tomorrow morning that we are still up-to-date with GNOME, and if not then wait for jdub/seb128's go-ahead
* lamont found out this week that the reason he can't get DSL right now is "lack of pairs", which is bull crap.
<lamont> must apply pressure to the phone company.
<ogra> seb128: night, great work :)
<jdub> Kamion: unless there's anything critical, i don't think it's worth updating gnome stuff in general
<HrdwrBoB> lamont: burn fown your exchange
<HrdwrBoB> down
<lamont> HrdwrBoB: no. that'd be bad
<Kamion> in that event it'll be whenever-uploads-are-ready + one hour for builds + time for testing
<lamont> besides, it's 10 miles away
<HrdwrBoB> 10 miles and you want DSL?
<seb128> mdz: panel need to some other hacks for the translations, I'll do that after the preview
<jdub> Kamion: but i can track gnome stuff up to the minute of release, and do uploads if absolutely necessary
<Kamion> jdub: ok
<lamont> HrdwrBoB: the RT is only 3 miles away
<HrdwrBoB> ah ok
<seb128> jdub: we want all the modules uptodate ?
<lamont> and then fiber back to the CO
<Kamion> mdz: if there are no new GNOME uploads, are our current live CDs sufficiently final?
<jdub> seb128: i'm find with what we have; will only upload if there's something super critical (unlikely)
* lamont really really goes to fire training. back in about 4 hours
<lamont> well, 4.5
<mdz> Kamion: I have a full set here and am starting a test cycle
<Kamion> mdz: likewise (well, of install anyway, will have to catch up with the live-amd64 rootfs regen)
<seb128> jdub: k, because there is a gdm 2.6.0.7 to 2.6.0.8, but with some conflict and changes, I prefer to upload it after preview
<jdub> cool
<mdz> I have install CDs, too; I'll do powerpc and amd64 after testing the live CDs
<mdz> I can't clobber my i386  at the moment
<Kamion> we still have that ugly scrollkeeper error at the end of the install; can we fix that?
<Kamion> it's a wart
<jdub> and we're not warty anymore :)
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/scrollkeeper-errors
<jdub> what do you think the duplicate to damage ratio is?
<Kamion> duplicate to damage?
<jdub> duplicate bugs of that error vs. potential damage of fix
<Kamion> it's a bad-first-impression thing; on slow machines that error message will hang around there for some time
<Kamion> potential damage seems low to me, but I'm no expert
<jdub> i'll find out now
<Kamion> thanks
<Kamion> other than that, install-i386 seems fine
<jbailey> Kamion: Got a fresh instal handy? =)
<Kamion> aha, yes
<Kamion> hmm
<Kamion> no RESUME=
<jbailey> Yar.
<Kamion> any debugging I can do?
<jbailey> I need to know what /proc/swaps looks like at install time, and whether that exact same device exists in /dev
<jbailey> mdz thought that it should be LSB naming in /proc/swaps, and the the lsb device should exist, just as a symlink.
<Kamion> ok, will check for you
<Kamion> LSB naming?
<jbailey> So I weakened the test for the /dev file from wanting a block device to wanting any file.  Thought that should've done it.
<jbailey> Kamion: /dev/hda, or whatever.
<Kamion> right
<mdz> Kamion: all 3 live CDs are releasable
<Kamion> hmm, /dev might not be bind-mounted into /target
<mdz> the login sound doesn't play, due to the known polypaudio breakage
<mdz> and I noticed one odd thing
<mdz> that the default sound effect for the terminal bell was different on powerpc than on i386
<mdz> on i386 it was the "clack" and on powerpc the "bloomp"
<jdub> *boggle*
<jdub> load-sample x11-bell /usr/share/sounds/generic.wav
<jdub> ^ default.pa
<jdub> mdz: you chose not to revert to esound for preview?
<mdz> jdub: right, it was too last-minute
<jdub> ok
<mdz> we'll talk on friday about what to do for final
<zenwhen> so preview is tonight?
<Kamion> zenwhen: what timezone are you in?
<mdz> zenwhen: preview is on the day it was scheduled 6 months ago
<zenwhen> lol
<zenwhen> Eastern
<jdub> i'd lean towards the last minute reversion instead of the preview bugs, though
<Kamion> zenwhen: sometime early morning your time, then
<zenwhen> oh cool
<zenwhen> If I could, I would update.
<schweeb> just in time for an early morning reinstall
<mdz> jdub: I would lean toward not having rushed into this particular burning building in the first place
<zenwhen> But I will do so after preview.
<schweeb> should fill up the work day nicely
<jdub> mdz: it had to be tested
<Kamion> jbailey: /dev/scsi/host0/bus0/target0/lun0/part5 partition       497972  0       -1
<zenwhen> The only bug I noticed is that k3b now hates my Lite-On ldw-811s
<jdub> mdz: if you're that unhappy with it, pull it out now; that's been my recommendation
<Kamion> jbailey: definitely not LSB naming in /proc/swaps, and that device probably won't exist in /target
<mdz> jdub: not if upstream had already bugged out on us
<Kamion> jbailey: a hard one, I'm afraid
<Kamion> jbailey: I think it'll have to be kludged in base-installer
<mdz> jdub: there is no way I am doing that hours before preview
<jbailey> Kamion: Ugh.  Thanks for checking.
<Kamion> jbailey: note that base-installer already does some mkinitrd.conf munging
<Kamion> jbailey: I don't know the exact semantics of what it's doing, though
<jbailey> Kamion: Ah?  I hadn't realised.  So it's not that ugly then.
<Kamion> but it looks like it could be slotted in there somehow
<jdub> mdz: right, i'm not really suggesting that, just expressing surprise.
<Kamion> jbailey: but probably post-preview now, given that we'll need time to test it :( Sorry I didn't get round to checking this out earlier
<Kamion> hm, that sucks, lots of people will install preview then upgrade
<mdz> jdub: it doesn't seem like a disaster functionality-wise; the reason that I'm leaning toward reverting it for final is that we have no upstream support
<Kamion> I could test by hacking base-installer on the fly ...
<schweeb> mdz: I noticed in some recent mailing list posts that you were sort of interested in Xen for ubuntu... anyone else express interest in it?  I've been looking at it recently, and am willing to help, but am not sure I can devote a ton of time on it (plus, I need to gain a little experience too)
<jbailey> Kamion: Is `mapdevfs` the tool for doing the conversion?
<mdz> schweeb: yes, others have expressed interest, and with the same disclaimer
<Kamion> jbailey: yep.
<Kamion> jbailey: base-installer already depends on it
<jbailey> Kamion: What's the best way to get the fix in without causing a race condition with you?
<jbailey> (and with suitable timing and such)
<jdub> mdz: yes, that's what i've said, in addition to certain regressions for stuff we use.
<schweeb> mdz: heh, alright... regular users can create wiki pages, right?  possibly I'll post some results to a wiki page so at least interested people have a reference
<Kamion> base-installer isn't in the d-i initrd, so it's just an upload; but we should both read over the diff
<mdz> schweeb: yes
<mdz> I'm surprised there isn't already a page (if indeed there isn't)
<schweeb> there isn't that I could find
<schweeb> just a few mentions of how it's a possible target of opportunity
<schweeb> haven't been able to get it booting on ubuntu yet, but I'm guesing that's a possible udev issue or something... worked essentially oob w/ sarge
<jbailey> Kamion: Do you know off hand if awk and wc are available at that point?
<jbailey> Mm, and sort and head.
<Kamion> jbailey: no awk
<jbailey> I know that they're not available in a busybox environment.
<Kamion> this is a busybox environment
<Kamion> you have wc, sort, head
<jbailey> It's not gnu sort, so my "sort by the third column to find the biggest swap" won't work. =)
<Kamion> you could do:
<Kamion> while read file a size b c; do if [ "$size" -ge "$maxsize" ] ; then maxsize="$size"; maxfile="$file"; fi; done
<Kamion> or words to that effect
<jordi> fabbione: ping
<Kamion> obviously with initialisation and stuff
<mdz> hmm
<mdz> this sucks
<mdz> I just realized that update-manager won't add/remove packages
<mdz> so people upgrading from preview will need to use synaptic to get seed changes
<jbailey> Kamion: Oh, is read posix?  Nice.
<Kamion> yeah
<mdz> oh, even better
<Kamion> you don't have all of bash's read options I don't think, but you rarely need them
<jdub> mdz: if we assume that most update-manager users will not be on devel branch, should we switch it to dist-ugprade?
<mdke_laptop> does anyone know if the wiki's can have multiple parents? sorry to disturb
<Kamion> WHOA
<Kamion> locale generation fell over
<mdz> jdub: until Hoary is released, every single update-manager user is on the development branch
<mdz> mdke_laptop: no, they can't
<Kamion> fuck, it tried to generate "en_GB.UTF-8en_US.UTF-8"
<mdz> DOH
<mdke_laptop> mdz, thanks
<jdub> mdz: that's correct, but not useful :)
<Kamion> and I seem to have old language packs on this CD
<mdz> jdub: it is, in the same way as it's useful to change the dpkg force-overwrite flag before release
<jdub> mdz: we're not going to be making dramatic seed or dependency changes
<mdz> jdub: well, we're most likely going to polypaudio->esound
<schweeb> mdz: hrm, interesting... there's no mention of xen that the search engine can find either... guess I'll make a wiki page
<mdz> which is a seed and dependency change
<mdz> and we made such changes the last time around too
<jdub> mdz: and we know exactly what the effect of that is, it's not unmeasurable or dramatic
<mdz> jdub: and it isn't handled by update-manager. that was my point.
<jdub> also mine
<jdub> given that we know dist-upgrade won't be dangerous for most update-manager users
<jdub> should it use dist-upgrade?
<mdke_laptop> mdz, is it a conscious choice not to allow wikis to have multiple parents, or just a limitation with the software?
<Kamion> mdz: ok, I will work around this in base-config rather than requiring a localechooser change (which => d-i initrd rbeuild)
<Kamion> rebuild
<mdz> mdke_laptop: I don't know
<\sh> hola ogra
<jdub> that does mean it will be slightly scarier if the users hugs the devel branch
<ogra> whoo \sh
<mdz> no hugging is required
<mdz> this means that upgrades from preview->final can't be done with update-manager
<jdub> but in the common case, not too bad
<jdub> no
<jdub> dude
<ogra> nice to see you here \sh 
<mdz> which is a shame
<mdke_laptop> hi ogra
<ogra> hi
<jdub> currently, yes it does mean that
<\sh> ogra: hehe...wanna see how you prepare your releases :)
<jdub> however, i am asking if we should switch update-manager to use dist-upgrade
<ogra> \sh, you old gentoo spy ;)
<mdz> I haven't read the code
<mdz> I don't know how update-manager works yet
<Kamion> oh, crap, no, I have to change localechooser; /etc/locale.gen is broken
<\sh> ogra: hehe...
<jdub> perhaps i've confused you by mentioning the drawbacks while introducing this idea
<mdz> omg
<mdz> I shouldn't be reading this
<Burgundavia> jdub: are we going to offer the users a choice to upgrade?
<jdub> Burgundavia: ?
<jdub> there is always a choice
<ogra> heh
<jdub> you have to very explicitly choose to upgrade
<Burgundavia> I will just shutup now
<Burgundavia> I should never jump into the middle of conversation while reading the beginning
<\sh> choice? i thought this was the gentoo way ;)
<ogra> \sh, i thought it was compiling in lonely nights
<\sh> ogra: i'm not lonely ;)
<Burgundavia> my hero, Johnny from Sun said that Linux was about vendor lock-in ;)
<mdz> jdub: yes, I do think we should switch it over to dist-upgrade, but not for preview
<mdke_laptop> ogra, its nice to have a compile going on those rainy days...
<ogra> mdke_laptop: at least you got rain.....we got snow
<mdke_laptop> lol
<\sh> ogra: we got rain as wenn in kerpen ;)
<mdke_laptop> ogra, its always raining in the uk
<\sh> as well
<Kamion> mdz: well, that allows upgrading preview->final in two steps. :-) first one upgrades update-manager ...
<mdz> jdub: is there any mechanism to shut down polypaudio at all, or do we need to recommend a reboot/killall after the switch to esound?
<ogra> \sh, i absoltely dont miss this place ;) (even i have to come around next week)
<mdz> Kamion: right, so, how about some sleep between now and byhanding d-i?
<mdz> Kamion: I don't think I'm really up for that right now
<jdub> mdz: polypaudio -k
<zul> heylog
<\sh> ogra: but I'm missing the meetings and the discussions about linux in the cantine with u :)
<mdz> jdub: I meant automatically
<ogra> \sh, we can have them here ;)
<mdz> jdub: but that's one of the bugs, isn't it. it doesn't get killed?
<Kamion> mdz: it's going to be RSN
<mdz> Kamion: what is?
<jdub> mdz: oh, at logout? no, it should die
<Kamion> mdz: d-i build
<Kamion> mdz: well, depends how much sleep you need :)
<mdz> Kamion: oh, are you going to byhand it onto little or something?
<Kamion> no
<mdz> you have a magic knob in the CD build to pull it from a directory outside of the archive?
<Kamion> no ...
<mdz> don't keep me in suspense
<Kamion> just uploading now
<Kamion> (localechooser)
<mdz> localechooser is in the initrd, yes?
<Kamion> ok, if you need sleep before the half an hour or whatever it is, go for it
<Kamion> yes, sadly
<mdz> so this change requires that somebody byhand d-i
<Kamion> right
<mdz> you said that you didn't want to do it
<Kamion> ok, let's leave it until after you've slept
<mdz> I'm significantly less confident about it
<mdz> I'm happy for elmo to do it in the morning, and release in the afternoon
<mdz> though I'm not sure what time elmo's morning will be, given that he just flew in
<Kamion> sorry 'bout the breakage, I'd hoped not to have to do this
<mdz> not a big deal
<mdz> we've been ahead of schedule this time around
<\sh> ogra: have to leave now..need to help thomas...cu here in kerpen...btw...branislav has his farewell drink 1) thursday, 5:30pm bowling center and 2) next week tuesday in cologne...
<mdz> consider
<mdz> this is the day BEFORE it's due :-)
<Kamion> hah
<Kamion> ok, time for coffee
<mdz> if we're going to leave it overnight
<ogra> \sh, i'll be there on thursday
<mdz> jdub has nearly convinced me to throw caution to the wind and revert to esound
<Clint> mdz: the baz completion function expression to grab the baz version is broken; which number from the baz --version output is safe to count on?
<ogra> \sh, i'll have to do that as well i think
<\sh> ogra: after this, i have to leave to bonn for a luusa meeting :) u can join for a beer as well there ;) 
<mdz> Clint: which number?
<ogra> \sh, yeah lets see ... :)
<Clint> mdz: 1.1.1 or 1.2 is repeated a few times
<\sh> ok cu bro :)
<mdz> Clint: the current version is 1.2
<mdz> Clint: I'm not sure how to answer your question more accurately than that
<Clint> mdz: lemme rephrase.  unless there's a better way, I'm going to grab the value in between "baz Bazaar version" and "(thelove@canonical.com"
<mdz> I think "Bazaar version (word)" is probably safest
<mdz> but honestly I have no idea if the bazaar developers plan to change that output format
<mdz> somebody in #bazaar might now
<Clint> okay, I'll go there
<jdub> mdz: overnight to which hour in UTC?
<mdz> jdub: sometime after 1000
<jdub> mdz: it really is just a matter of changing the seed for this one
<Kamion> I'll be up from ~0900
<jdub> mdz: heh
<jdub> mdz: aha!
<mdz> I have a choice between staying up to 1000, or sleeping and joining up later
<mdz> jdub: the preview was looking too perfect and I didn't want to curse it by fiddling in the last hours
<mdz> jdub: but now that a bug has turned up, I feel more relaxed :-)
<jdub> :)
<Kamion> so does that mean we can fix these scrollkeeper errors too? :)
<mdz> Kamion: what scrollkeeper errors?
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/scrollkeeper-errors, on every install
<jdub> Kamion: so i know how to fix the first two (easy, not dangerous)
<Kamion> jdub: the first two are the ugliest
<mdz> jdub: * committed ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-184
<jdub> Kamion: gotta do some searching for the last one
<mdz> and may god have mercy on my soul
<Kamion> localechooser 0.04.0ubuntu7 fixes the locale generation bug
<jdub> mdz: :-)
<mdz> Kamion: can you kick the published seeds?
<jdub> mdz: you kicked out alsa and x11 too?
<Kamion> mdz: done
<Burgundavia> jdub: who is working on the front page redesign?
<mdz> jdub: zsh: exit 1     grep polypaudio desktop
<jdub> bonus
<Kamion> - * polypaudio-alsa
<Kamion> - * polypaudio-x11
<Kamion> + * esound
<jdub> Burgundavia: henrik, ryan (forums dude) and the guys who won the comp
<Burgundavia> jdub: thanks
<mdz> uploaded ubuntu-meta 0.38
<zenwhen> jdub, have you heard any complaints about dvd burn speeds dropping after having gone from warty to hoary?
<Kamion> mdz: not leaving polypaudio in supported?
<Kamion> of course polypaudio-clients is in supported still
<mdz> Kamion: the reason we're ditching it is that it's unsupportable, so I see no reason to keep it in main
<jdub> zenwhen: no
<mdz> I'll fix that
<zenwhen> jdub, Oh. Maybe it is just me then. :(
<Kamion> mdz: 'k
<mdz> dear baz
<mdz> please make me type in my passphrase more
<mdz> love, mdz
<jdub> mdz: gnome-gpg :)
<mdz> I do not trust that thing with my key
* Kamion tries to laugh quietly to avoid waking up fiancee
<mdz> it doesn't even lock memory!
<Kamion> but but but it's got "gnome-" on the front
<Kamion> I'll get my coat
* jdub uses it for convenience, not because it's gnome-based.
<mdz> when ubuntu-desktop comes around on the cron.daily train, I'll build new cloop images
<Kamion> jdub: teasing :)
<mdz> that'll be 43 minutes
<Kamion> quintuple-agent looked less bad last time I investigated
<Kamion> IIRC it locks memory
<jdub> there's some new gpg agent around too
<jdub> gpg 4?
<mdz> Kamion: I did not seem to encounter this locale problem; what should I be looking for?
<mdz> jdub: gnupg2
<mdz> KDE 3.4 uses it
<mdz> looks a bit like ssh-agent
<mdz> from the outside anyway
<Kamion> mdz: look in /etc/locale.gen; I noticed it going past while language-pack-* was being installed
<Kamion> mdz: but it won't happen if you did an en_US install
<mdz> Kamion: my /etc/locale.gen looks pretty normal
<mdz> ah
<mdz> I did
<Kamion> it appends en_US.UTF-8 to supported-locales if the locale was not en_US.UTF-8
<Kamion> but I forgot a space, so localechooser/prebaseconfig and base-config/lib/menu/pkgsel got confused
<mdz> gotcha
<mdz> I just didn't realize US was magic
<Kamion> yeah, it seemed silly to set it to "en_US.UTF-8, en_US.UTF-8" by default :)
<schweeb> dammit, I'm a moron... is there any way to change your name in the wiki?  I managed to mistype my own last name
<schweeb> s/the wiki/plone/
<mdke_laptop> schweeb, preferences are pretty limited
<schweeb> indeed
* schweeb undoes all changes and tries to re-register, in hopes of fixing his name
<schweeb> bah, can only register an email once
<mdke_laptop> also you can't change your email address i don't think
<schweeb> nope
<schweeb> is there any chance I could trouble our Ubuntu overlords to fix my error?
<mdke_laptop> lol i doubt that
* schweeb desperately tugs on jdub's pant leg
<mdz> schweeb: mail webmaster@
<schweeb> mdz comes through again, thx
<mdke_laptop> :)
<mdz> no problem, but please try to keep the conversation on-topic in here; we're under release pressure
<schweeb> mdz: alright, sorry.  assumed the person responsible would be more likely to see my call for help here.  I'll go back to lurking and working on Xen
<mdz> Kamion: does there exist a cheat sheet for d-i byhanding?
<Kamion> mdz: elmo said he'd left one in jackass:~james/
<mdz> Kamion: I see no instructions, but there is a script
<Kamion> ICBW, but I'd expect it's mostly "tar xzvf" in the right place
<Kamion> and maybe cleaning up old directories
<mdz> the script has two sections, like the intent is for one of them to be cut and pasted
<mdz> ah, one for daily builds and one for real uploads
<Kamion> oh, daily builds would probably have installer-i386/ in their tarballs, but expand into daily-installer-i386/, which might be interesting
<mdz> yeah, it mv's that stuff around
<mdz> it isn't terribly frightening, but there's a bit more to it than I'd like
<mdz> mailed you a copy
<Kamion> thanks
<mdz> it would be nice to be able to send out a request for overnight testing
<Kamion> I started writing a katie patch to do it automatically; most of it will probably be sanity-checking the tarball
<Kamion> localechooser 0.04.0ubuntu7 has not hit archive.u.c yet
<Kamion> ah, there it is
<mdz> should be there right now
<mdz> as well as ubuntu-meta 0.38
<Kamion> mdz: could you kick the d-i build? the machine with my script on it is currently running an install
<mdz> oh fuck
<mdz> polypaudio Provides: esound
<mdz> Kamion: kicked
<Kamion> tas
<Kamion> ta
<mdz> Kamion: what do you think we should do about esound?
<mdz> what a mess
<mdz> could upload polypaudio without the Provides, I suppose
* jdub thinks
<jdub> that would break polypaudio unnicely
<Kamion> no idea, I mean it'll work for new installs but not for upgrades
<mdz> break?
<mdz> Kamion: right
<Kamion> do we care?
<mdz> well, I'd really appreciate the testing
<jdub> we could just add to release notes "those testing with polypaudio before the preview should install esound"
<mdz> and at some point we need to upgrade people
<Kamion> a versioned dep from ubuntu-desktop would do it
<jdub> yeah
<Kamion> bit weird though
<mdz> and there's no infrastructure in ubuntu-meta for it
<mdz> ubuntu-desktop could conflict with polypaudio
<jdub> yucky
<Kamion> that would be foul, and probably cause upgrade issues
<mdz> that's the best idea I've got
<jdub> do we need to forcibly upgrade those people who have polypaudio?
<Kamion> since ubuntu-desktop would have to be deconfigured (at least) during the upgrade
<Kamion> I suspect we would end up with some confused people without ubuntu-desktop
<mdz> Kamion: nah, it should go fine, since ubuntu-desktop is being upgraded at the same time
<Kamion> it will still have to be deconfigured
<mdz> it will be unpacked and unconfigured anyway
<mdz> the installed version won't be deconfigured
<mdz> the new version just gets unpacked over it
<jdub> hmm
<jdub> so
<Kamion> since polypaudio will have to be totally removed before the new ubuntu-desktop is unpacked
<jdub> not a lot depends on esound
<Kamion> a versioned dependency on esound is much, much cleaner than that
<jdub> we could remove the provides
<mdz> Kamion: the d-i builds all exited; I have no idea if they succeeded
<jdub> and add it again later
<Kamion> and doesn't break the people who are actually trying to test polypaudio
<mdz> Kamion: ross failed due to an ssh host key mismatch; do you know which arch that is?
<Kamion> mdz: powerpc I think
<jdub> but it does break polypaudio in the mean time
<Kamion> mdz: just run that one again by hand?
<mdz> Kamion: retrying
<mdz> jdub: how does removing the provides break polypaudio?
<jdub> mdz: it means you can't install it without removing libesd...
<Kamion> oh, is it another damn fam/gamin-style thing?
<mdz> jdub: hmm?
<Clint> mdz: s/star_merge/merge/g in _baz and your problem should be gone
<jdub> mdz: which doesn't break polypaudio itself, but is pretty solidly broken
<Kamion> library depends on daemon
<jdub> Kamion: yes
<mdz> Clint: I was sure I did that in the first place
<Clint> oh
<jdub> Kamion: libesd talks to esound *and* polypaudio
<jdub> Kamion: fam was a little bit different
<Kamion> how about libesd depends esound | polypaudio, then?
<jdub> ok
<jdub> will do that now
<mdz> I have no qualms at all about breaking polypaudio if that's what it takes
<jdub> much saner :-)
<mdz> but I'd prefer not to mess with esound
<mdz> at least not right now
<Kamion> we could break polypaudio for preview, and fix it again right afterwards
<Kamion> with the above method
<jdub> Kamion: doesn't fix the upgrade issue though
<jdub> unless we do the versioned esound
<Kamion> jdub: if polypaudio stops providing esound, the ubuntu-desktop upgrade will install real esound
<jdub> Kamion: (referring to libesd change only)
<jdub> it doesn't depend anyway, just sugests
<jdub> have we thrown out versioned esound depend entirely?
<Kamion> whoa, billions of scrollkeeper errors on powerpc
<Kamion> gcalctool apparently
<jdub> Kamion: can you put output up again?
<Kamion> yeah, just doing
<Kamion> jdub: http://people.ubuntu.com/~cjwatson/tmp/scrollkeeper-errors-powerpc
<mdz> ubuntu-desktop conflicts: polypaudio is perfectly reasonable to me
<mdz> we actively do not want supported systems to have polypaudio
<mdz> apt will prefer to upgrade ubuntu-desktop and install esound, rather than remove ubuntu-desktop and keep polypaudio
<mdz> but I suppose we can punt on it for preview
<mdz> kicking live fs builds
<Kamion> jdub: locale is de_DE.UTF-8, btw
<Kamion> but weirdly a scrollkeeper-rebuilddb after install doesn't show the gcalctool errors
<mdz> Kamion: what do you want to do about the d-i build?
<jdub> Kamion: it doesn't do anything for me after a recent rebuilddb
<Kamion> jdub: yeah, maybe transient weirdness :(
<Kamion> mdz: if you can byhand it, I think that would be best
<jdub> Kamion: not getting any xmllint issues with any of those
<jdub> Kamion: can you try on ppc?
<mdz> Kamion: so I want the lower half, right?
<Kamion> mdz: no, upper
<mdz> oh, it's a daily
<Kamion> yes
<mdz> ARCHS="i386 amd64 powerpc ia64"
<mdz> TAR_VERSION=20041227ubuntu20.0.200503090
<mdz> VERSION=20041227ubuntu20.0.200503090
<mdz> look correct?
<Kamion> yes, if that matches the tarball version
<mdz> Kamion: done
<mdz> er, not yet
<mdz> it drops me to a shell at one point
<mdz> and I don't actually know what to do with it
<mdz> it looks like everything is in order
<Kamion> jdub: nor I, assuming it goes out on stderr
<Kamion> mdz: I think it's for you to check it over, and also possibly to clean up old subdirectories of daily-installer-*
<jdub> Kamion: oh well; the others will be fixed in a couple of minues
<Kamion> jdub: cool
<Kamion> thanks
<Kamion> I wonder where jbailey went to; I wanted to discuss the base-installer RESUME= fix with him
<mdz> hmm
<mdz> Kamion: it drops me into lisa, but i'm not sure what I should tell lisa to do with these
<mdz> so I'm going to leave them in queue/byhand for now
<Kamion> lisa = ?
<Kamion> oh, NEW processor
<mdz> Kamion: stuff should be synching now
<Kamion> mdz: I think you just tell it to accept
<Kamion> it checks whether byhand components are still present, and does not offer [A] ccept if so
<mdz> oh, ok
<mdz> accepted, then
<mdz> notified elmo
<opi> jdub, ping? ;)
<jdub> opi: pong
<opi> jdub, query :-)
<Kamion> http://people.ubuntu.com/~cjwatson/base-installer.resume.diff <- should make suspend-to-disk work out of the box, still testing
<Kamion> tested with one swap partition and it's fine, I'll test with >1 and with none as well
<bluefoxicy> is there some way i can tell if my cds were sent
<bluefoxicy> I ordered some CDs for warty from shipit back in november
<bluefoxicy> after noticing a message that it was "Reopened by popular request" or something
<opi> Kamion, S-T-D is planed for Hoary, right?
<bluefoxicy> opi:  protection lanned for Hoary :)
<Kamion> opi: yes
<opi> Kamion, yeah, super -- it's really missing
<Kamion> I'm trying to make this work for preview even though it's very late, because it needs installer support and a lot of people will install with the preview and upgrade to final
<Kamion> opi: it should work now if you put a suitable RESUME= in /etc/mkinitrd/mkinitrd.conf and regenerate your initrd
<wasabi> haha so how long until the live cd is able to save data to itself? :)
<opi> Kamion, remind me, resume should point to partiton that is swap type?
<wasabi> It'd be a pretty easy interface edition, at log off check HAL to see if hte device the cd is in is a cd-rw, etc, then ask user if he wants to save. ;)
<Kamion> opi: yes
<opi> Kamion, is snapshoting to file impossible (or, hard to achive?)
<Kamion> opi: no idea
<Kamion> I'm no swsusp expert
<opi> Kamion, because it would be hard to change my partiton table now
<opi> or can I use my old swap
<opi> because it's up before swapon /dev/xxx
<opi> Kamion, ok, I'll google
<Kamion> you can use the swap partition you're already using for swap
<opi> ok, then I'm home
<opi> :-)
<Kamion> or whatever, really; it just has to be a scratch partition
<Kamion> as far as I know
<opi> thanks
<opi> in that case, a hackinsh solution would be to mount file as a loop device and try to save it thre ;-)
<Kamion> I doubt you'd be able to resume if you tried that
<opi> well, what about initrd?
<Kamion> if you feel like teaching it how to do that ...
<opi> nah, I'm just doing a blind guesses
<opi> I guess I'll better patch kernel myself and test it
<Kamion> the initrd is what implements resuming
<opi> but there's a part of the script that resumes the kernel state, no?
<Kamion> however, /sys/power/resume only supports block devices
<opi> ah, so that's seattled
<Kamion> I suspect you'd be in for some fairly major hacking
<mdz> Kamion: is [ "$foo" ]  in general a good idea, in contrast to [ -n "$foo" ]  ?
<mdz> seems like it could cause a syntax error depending on the value
<Kamion> it does seem that way at first glance, but leaving out -n is fine; test(1) has some very strange argument handling rules
<Kamion>     1 argument:
<Kamion>         Exit true (0) if $1 is not null; otherwise, exit false.
<Kamion> http://www.opengroup.org/onlinepubs/009695399/utilities/test.html
<mdz> weird
<mdz> I just built a new set of live CDs with esound
<Kamion> one reason why avoiding -a and -o is a good idea is so that you can use the normal && and || argument handling rules rather than the strange test(1) rules
<mdz> Kamion: localechooser ubuntu7 is the good one?
<Kamion> mdz: yes
<mdz> ok
<mdz> current live build has all the goodies, then
* Kamion rsyncs
<mdz>    589543424 100%    9.44MB/s    0:00:59  (1, 33.3% of 3)
<mdz> rsyncs nicely
* Kamion -> hot chocolate
<Amaranth> hey, take a look at http://www.euphorochrome.com.nyud.net:8090/photoblog/images/131.jpg
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/20050308.1/, http://cdimage.ubuntu.com/daily-live/current/
<dilinger> whoa, nice pic
<zul> how is the release coming?
<mdz> zul: needs testing
<zul> i could test it when i get in tomorrow
<zul> night though
<mdz> hmm, I thought seb128 was going to make an upload to fix About Ubuntu
<mdz> Mar 08 15:52:20 <seb128>        k, I'll upload in ~30min so
<jdub> mdz: which fix?
<mdz> jdub: About Ubuntu points to the ubuntu-artwork Warty page
<jdub> mdz: that's hard to fix
<jdub> well
<jdub> unless i fix it very hackily, non-i18n style
<jdub> which i'm happy to do
<mdz> well, you're going to upload ubuntu-artwork anyway
<mdz> so we may as well fix it there, at least for now
* Kamion slaps partman
<Kamion> why does resizing a swap partition even take any time at all?
<mdz> Kamion: fwiw, I'm not able to reproduce the boot-di-from-USB-cdrom problem at the moment
<mdz> not that I was able to consistently reproduce it before
<Kamion> mdz: you mean #5732?
<Kamion> mdz: adding udevstart to hw-detect may have made a number of mysterious bugs go away, or at least manifest differently
<Kamion> base-installer change works fine with three swap partitions, the middle one being the biggest
<Kamion> now to try with no swap partitions
<mdz> Kamion: yes, #5732
<mdz> Kamion: current generation of live CDs are good (login/logout sounds and all)
<mdz> Kamion: also that "setenv boot-device cd:" seems to have done the trick; that'll save me gobs of time, thanks
<Kamion> cool
* Kamion wonders if rhythmbox to his NFS jukebox is usable on the live CD
<Kamion> hooray, yes, it is
<mdz> neat
<mdz> would be neater if you could "Connect to server..." to an NFS server
<mdz> neater still would be if there were a network filesystem which didn't suck ass
<Kamion> connect to server> yes, why don't we have that, anyway?
<crimsun> mdz: RE: #6810, I've chatted with only one person who uses the modem module (snd-intel8x0m). I agree with Chuck RE: blacklisting it.
<mdz> Kamion: would *you* want to implement an NFS client in libgnomevfs?
<Kamion> mdz: it doesn't just use mount(8)?
<mdz> Kamion: no, it does the protocol itself
<Kamion> oh
<mdz> Kamion: hence being able to access SMB shares without root, anonftp, etc.
<mdz> crimsun: ok, can you remind me about it after preview is out?
<crimsun> mdz: absolutely.
<Kamion> being able to do mount(8) from the GUI would be good
<Kamion> (for non-gnomevfs-integrated stuff)
<mdz> that reminds me, I need to remember to implement mounting of hard disk partitions in casper sometime
<mdz> we should work out a way to share that code between casper and the installer
<Kamion> rescue mode does that too
<mdz> oh? hmm, maybe I can squeeze it in for hoary hten
<Kamion> although its use case is different
<Kamion> well, rescue mode just mounts the partition you tell it too actually, that's quite different
<Kamion> s/too/to/ # gah
<mdz> oh
<mdz> what I want is to poke around like os-prober does
<mdz> make up some reasonable names for what it finds, and mount using those names
<Kamion> yeah, sorry, realised that belatedly
<mdz> maybe it should be an extension to os-prober
<Kamion> "like os-prober does"> ITYM "using os-prober" :-)
<Kamion> os-prober produces quite usable output
<mdz> is os-prober already generic enough?
<mdz> oh, good
<Kamion> should be
<Kamion> it's used in several wildly different applications
<Kamion> duplicating the logic on top of that isn't great but wouldn't be too bad for hoary
<mdz> jdub: cliff said he would come by tonight so that we can finalize stuff for preview; have you heard from him in the past 1-1.5 hours?
<mdz> Kamion: anything on your list besides base-installer?
<Kamion> mdz: no
<Kamion> mdz: oh, those scrollkeeper fixes, jdub said he'd upload them in a few minutes two hours ago
<mdz> Kamion: I'm happy with the live CD except for artwork, and am ready for install testing when you are
<Kamion> jdub: ping :-)
<Kamion> yeah, nearly done with base-installer testing now
<Kamion> how do I un-suspend-from-disk, anyway? pressing the power button just seems to reboot from scratch
<mdz> that means it didn't find your RESUME
<mdz> it works for me when I set RESUME manually
<Kamion> traditional device name, right?
<mdz> that's what I use
<mdz> of course it needs to be on a device which is visible in initrd-land
<mdz> though it's pretty unusual for swap to be on a different physical device than root
<mdz> different controller, that is
<Kamion> it all looks fine
<Kamion> could be that the laptop is just odd; it is a Via after all
<mdz> unfortunately I don't think it provides any debugging at all
<mdz> Kamion: do you have /sys/power/resume?
<Kamion> yes, in the real system
<Kamion> how come initrd-tools' initrd does not mount /sys?
<Kamion> oh, never mind, it does
<Kamion> shrug, dunno, I'm pretty sure the configuration is correct now
<mdz> Kamion: anything in dmesg?
<mdz> if there's some problem reading the resume data, I assume the kernel would log
<fabbione> morning
<Kamion> oh, hey, that time it worked
<m_tthew> ever closer to the 'totally' in 'totally rad'
<mdz> the amd64 test box will suspend
<mdz> but it doesn't quite resume
<Kamion> ok, base-installer 1.15ubuntu7 uploaded
<mdz> I think my jaw would have dropped if it had
<mdz> apparently it supports cpu frequency scaling, too, which I hadn't noticed before
<jdub> Kamion: those aren't up?
<jdub> i have .upload files here...
<fabbione> guys, what is the status for preview cd?
* fabbione just woke up and ready to test
<lamont> morning fabbione 
<fabbione> hey lamont
* lamont gives serious consideration to working from the internet cafe tomorrow
<Kamion> jdub: nothing on hoary-changes
<m_tthew> I like the 'determine my layout by pressing some keys'
<bradg> Will 2.6.11 be the default in the final release of hoary or does feature freeze dictate that we have to stick with 2.6.10?  I ask because 2.6.11 adds support for my sound card that isn't in 2.6.10.
<lamont> 2.6.10
<lamont> although 2.6.11 will be in universe
<Kamion> jdub: ah, there it is. just gnome-applets?
<jdub> Kamion: also gnome-doc-utils
<jdub> although i'm double checking my fix, because i can't believe it
<fabbione> speaking of which....
<fabbione> we could actually go 2.6.11.1
<stub> If I suspend my laptop whilst playing music with Rythmbox, after I resume Rythmbox can no longer make a sound (could not pause playback, could not open resource). Should I file a bug against rythmbox, acpi-support or polypaudio ?
<Kamion> elmo: probably best not to bother processing the next daily d-i build
<bradg> jdub, Has there been any progress on the move to dbus-0.23.2?  Are there API incompatibilities that are sticking us to 0.23.0 for hoary?
<jdub> Kamion: hrm, so the ugly ones are easy, but the last one i can't be sure of
<jdub> bradg: there's an api change which we could stub, and may do so before final if it's worth it
<Kamion> jdub: nod
<bradg> jdub, The major benefit I see is just that it will allow for wider testing recent versions of beagle.  Anyway, good luck on the release tomorrow!  Ubuntu has been great (the software but especially the community)!  I'm glad to be involved (Web design contest - heh, it's something).
<jdub> :)
<fabbione> doko: ping
<Kamion> jdub: I think we can live without the last one
<Kamion> mdz: decided not to wait any longer, new install CDs building
<Kamion> we have to rebuild later for ubuntu-artwork anyway
<fabbione> Kamion: can you give me the green light for rsync and start testing?
<Kamion> mdz: go ahead and test when ready; I'm going to get a little sleep
<Kamion> fabbione: no, see above :)
<Kamion> fabbione: now + 1 hour should be safe
<fabbione> Kamion: roger that and good night houston. Apollo 13 out.
<Kamion> erk, cancel that, I have to wait for the kubuntu dailies to finish
* fabbione sighs
<Kamion> oh, no I don't. whoops.
* fabbione smiles
* m_tthew cheers
* fabbione hands and extra cup of coffee to Kamion 
<Kamion> really building
* Kamion &
<mdz> Kamion: you were waiting?
* lamont sleeps
<fabbione> night lamont
* ..[topic/#ubuntu-devel:mako] : 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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/20050308.1/, http://cdimage.ubuntu.com/daily-live/current/ | read, review, and edit the preview release announcement: http://www.ubuntulinux.org/wiki/Draf
* ..[topic/#ubuntu-devel:mako] : 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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/20050308.1/, http://cdimage.ubuntu.com/daily-live/current/ | review preview ann.: http://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<mako> fabbione: can you point sabdfl to that preview announcement when you see him?
<fabbione> mako: sure
<mako> fabbione: i think i told i'd put it there but i suspect he'll forget :)
<mako> and i'm gonna crash
<mako> but i'll be up soon
<fabbione> mako: ehehe ok.. good night
<jdub> mdz: do you want the (non-i18n-happy) About Ubuntu change done?
<mdz> jdub: meaning we replace the existing .html with a new .html?
<jdub> no
<jdub> we change what it launches
<jdub> to open the english-only docteam version
<mako> mdz: ok, you saw the announcement url
<mdz> mako: I didn't, but I have now
<mako> mdz: good enough
<mdz> mako: maybe swap the first two paragraphs?
<mako> mdz: fine with me.. i'm not going to touch it for a bit.. i need to crash
<jdub> mako: "automated install support with Kickstart compatibility"?
<mdz> mako: ok, thanks
<Burgundavia> mako: I had the same thought regarding the 1st two paras
<mako> i'm really not partial to the order of the paragraphs :)
<Burgundavia> mako: future announcements of this type? could that be changed to something more specific?
<pitti> Morning
<mako> Burgundavia: could just be future announcements
<Burgundavia> mako: ok, why not say future release announcments?
<jdub_> mdz: about ubuntu change? i have to do it soon
<mdz> jdub_: why do you want to change the panel to launch a different program, rather than swapping in a new HTML file?
<jdub_> because the new about ubuntu doc is docbook, to be viewed in yelp
<jdub_> i could render it to html and swap it in
<mdz> it's trivial to convert it into HTML
<jdub_> but it will look a bit arsey
<mdz> if the panel change is absolutely simple and safe, go for it
<mdz> I just don't want to destabilize things there
<dholbach> good morning
<pitti> Hi dholbach 
<dholbach> morning pitti
<m_tthew> fabbione : looks like the build is up
<fabbione> m_tthew: thanks.
<mdz> yep
<mdz> rsyncing it now
* fabbione rsyncs
<mdz> we're still going to need a gnome-panel and ubuntu-artwork from jdub before this is over
* fabbione sighs
<mdz> jdub_: did you find out what happened to those two lost uploads?
<fabbione> well
<m_tthew> this will be the last build I can test before sleep
<fabbione> jdub_: wrong target for the upload?
<mdz> the key for this build is working hibernate
<fabbione> sparc is catching up pretty fast
<fabbione> but gcc-4 has a wrong build-dep
<fabbione> that means rebuilding it again after all the libs are done
<mdz> jdub_: ah, I see them now. gnome-applets and gnome-doc-utils
<mdz> hmm, no, I'm seeing seb128's gnome-doc-utils upload
<mdz> jdub_: do you have a gnome-doc-utils upload to make, or no?
<jdub_> no
<jdub_> decided not to
<mdz> ok
<mdz> so only ubuntu-artwork and gnome-panel?
<jdub> yes
<mdz> once you've uploaded those, I'll need to do livefs builds, and then a full set of install+live CDs
<mdz> so I'm going to try to take a nap until then
<mdz> please SMS me if there are any issues
<jdub> going to be > 1hr
<doko> fabbione: pong
<fabbione> doko: gcc-4 FTBFS on sparc... interested in the log?
<fabbione> it looks to me it needs a newer version of libcairo... 
<fabbione> if so it needs a versioned build-dep
<fabbione> but i might be 100% wrong here
<doko> it builds ok with the version in hoary on the other archs ... 0.3.0-1
<fabbione> fuck irc!
<fabbione> i hate this protocol
<fabbione> yeah i had an older version of cairo
<fabbione> i will kick it back as soon as libcairo will build
<fabbione> but it should still have a better version build-dep imho
<fabbione> if that's the problem
<doko> ok, added for the next version
<fabbione> i will let you know to be 100% sure
<Treenaks> anyone with basic knowledge of US legalese here? :)
<fabbione> it will take sometime before i can actually kick back gcc
<Burgundavia> Treenaks: I might be able to help
<Treenaks> Burgundavia: can I /msg you? :)
<pitti> Moin mvo
<mvo> hey pitti! good morning
<dholbach> hai mvo
<mvo> hey dholbach 
<amu> moins 
<pitti> erm, why does cdrecord ignore my speed attribute (speed=4) ???
* pitti successfully installs the latest ppc/install CD
<carlos> pitti: when is the base language pack released? with the Ubuntu preview or with final release?
<pitti> carlos: I uploaded up-to-date packs yesterday night
<carlos> the *final* base language pack
<carlos> pitti: I know, that's why I'm asking
<pitti> carlos: right before the final Hoary version, I will update them again, of course
<carlos> ok, that was the question
<carlos> thanks
<pitti> carlos: btw, the tarballs of yesterday's rebuilds are in ~lamont/translations/20050306
<pitti> carlos: that's a "fake" directory :-)
<pitti> carlos: I also generated an index file, so you should be able to import it normally
<carlos> perfect, thanks
<pitti> carlos: btw, yesterday I defined a lot of domain overrides, so that I now have a complete set for hoary/main
<pitti> carlos: do you have any use for it?
<pitti> s/it/them/
<carlos> pitti: please, send me them, it will help while cleaning up the first main import
<pitti> carlos: you can always grab the latest ones from rookery
<pitti> carlos: /home/pitti/strip2lparc/domain-overrides
<pitti> carlos: there are some 0 byte files, that means that this source package is completely ignored
<pitti> carlos: this is necessary sometimes
<carlos> ok
<pitti> carlos: like, e. g. flex-old and flex have the same domain (flex), so I cannot install translations for both of them
<carlos> pitti: does it means we have two packages with the same domain but with different .pot and .po files?
<pitti> carlos: yes, flex-old is an -- erm -- older version
<pitti> carlos: I only use the translations from the newer flex
<carlos> and how is that we are supporting flex-old if it's not being developed anymore?
<pitti> carlos: it's a build-dep of some pacakges
<carlos> pitti: what about patching it so it uses flex-old domain name?
<pitti> carlos: that would be possible; but I didn't do this last night, too much other stuff
<pitti> carlos: besides, nobody will care about translations for flex-old anyway
<carlos> pitti: I know, but that makes us handle an special case so doing the rename could be better than just ignore it
<pitti> carlos: you need ignore-overrides anyway for some odd KDE packages :-)
<carlos> pitti: well, in this case I prefer if you don't create the tarballs for those packages than ignore them from my side :-)
<pitti> carlos: hmm, that's more difficult
<pitti> carlos: I can't know which domains collide before I actually build the tarballs
<pitti> argh
<carlos> don't worry, I need to talk with Mark about it today
<carlos> I suppose we will find an easy solution 
* pitti opens "About Ubuntu" and is greeted with "Welcome to Warty Warthog Release"
<pitti> Kamion, mdz: ^ can we fix this for preview?
<Mithrandir> doko: pong
<doko> Mithrandir: built a binutils-i486 for ia64, needs now something like kernel-headers-i486 and glibc-headers-i486, not sure if that is less ugly than including the gcc source in the ia32-libs tarball.
<Mithrandir> doko: that's horrible, it's way better to just include the gcc source in the ia32-libs tarball.
<Mithrandir> imho, at least
<Keybuk> hmm, oops; anyone using aptitude will now have broken sound
<doko> so where was the problem building lib32gcc1 from ia32-libs?
<Keybuk> (because polypaudio provides esound, so that satisifies the dependency of ubuntu-desktop ... so you don't get esound, just a polypaudio without the alsa or x11 drivers)
<Mithrandir> doko: it's not really a problem, I think I just asked whether gcc could generate lib32gcc1 on ia64 :)
<trukulo> jdub, hei, you awake?
<trukulo> morning to everybody
<Treenaks> hi trukulo 
<jdub> yes
<jdub> very busy atm
<jdub> leave it a couple of hours :)
<trukulo> k jdub, just to say bittorrent 4 has multiple downloads and gtk interface
<doko> Mithrandir: no
<pitti> jdub: why does the live cd (ppc at least) use esd, while the install cd uses polypaudio?
<jdub> pitti: install cds probably haven't finished building yet
<jdub> or there's a desync
<pitti> jdub: oh, did we switch back to esd finally?
<carlos> jdub: do you know that with polypaudio the welcome and session end sounds are not played anymore?
<mpt_london> carlos: That's not a bug, it's a feature
<Keybuk> jdub: read my comment above
<Keybuk> polypaudio provides esound
<carlos> mpt_london: ;-)
<Keybuk> so ubuntu-desktop still depends on polypaudio
<jdub> carlos: yes
<jdub> Keybuk: mdz put in a fix for that
* jdub is very busy atm
<jdub> mdz will be back again soon
<Keybuk> jdub: where?  it wasn't in his 01:45 upload
<trukulo> anyone but jdub who knows anything about torrent support in hoary? i mean, wouldn't be good to include bt 4.0.0 ?
<Treenaks> trukulo: I think this'll be the same as the firefox 0.93/1.0 thing in warty :(
<fabbione> hmmm no
<fabbione> there is also a licence change with bt that needs to be investigated afaik
<Treenaks> fabbione: no?
<fabbione> + UVF = NO NO NO
<fabbione> it will stay as it is
<Treenaks> fabbione: that's what I said..
<fabbione> i was answering to trukulo :)
<mdz> Keybuk: ubuntu-desktop doesn't depend on polypaudio; polypaudio provides: esound
<trukulo> fabbione, ok, i understand, only say that new bt have multiple downloads, and gtk interface
<fabbione> so does the actual one :-)
<trukulo> exactly what you was looking for in u-d-l
<trukulo> no, the actual one use wxwidgets
<trukulo> as i know
<trukulo> and no multiple downloads in the same window
<fabbione> just goodies.. 
<fabbione> it's nothing critical for release
<Keybuk> mdz: yes, that's what I was just saying
<trukulo> fabbione, i agree, i was only questioning ;)
<Keybuk> mdz: so you end up with polypaudio instead of esound sometimes
<pitti> mdz: right now install uses polypaudio, live uses esd
<Keybuk> apt (at least aptitude) doesn't appear to favour real packages instead of providers
<pitti> mdz: at least on the ppc CDs from this morning
<pitti> mdz: but polypaudio is broken again for ppc/install on the current CDs :-(
<mdz> Keybuk: apt and aptitude shouldn't enter into it; only esound should be on the CD
<mdz> looking at it now
<Mithrandir> mdz: make ubuntu-desktop have a versioned depends (>= 0) on esound?
<mdz> pitti: there is no polypaudio on the daily/current CDs
<mdz> Mithrandir: scroll back a few hours; we talked about this
<pitti> mdz: I just installed this morning's ppc/install without network (no chance of downloading), and this uses polypaudio
<mdz> pitti: md5sum?
<Keybuk> mdz: yeah, but at the point the cd stuff gets installed, it's already added the network to sources.list hasn't it
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/daily/current $ grep polypaudio *.list
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/daily/current $
<mdz> Keybuk: nope
<mdz> it explicitly does the desktop install with only the CD in sources.list
<Keybuk> there's also the fact that ubuntu-desktop breaks polypaudio without forcing esound
<pitti> mdz: 642877440 2005-03-09 08:43 hoary-install-powerpc.iso
<pitti> mdz: 54baddb324353badb9be9bf7ce9434b3  hoary-install-powerpc.iso
<Keybuk> so anyone tracking needs to make sure they replace polypaudio with esound manually
<mdz> 2e33c1f0cccb268a4605399d3b2ac5b9  hoary-install-powerpc.iso
<mdz> pitti: ^^ that's current
<mdz> Keybuk: we discussed all of this hours ago; it's not important for the preview release
* pitti used rsync://cdimage.ubuntu.com/cdimage/daily/current/hoary-install-powerpc.iso
<mdz> we'll deal with the upgrade issue later
<mdz> pitti: how long ago?
<pitti> mdz: downloaded 2 hours ago (7:43 UTC)
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/daily $ grep 54baddb324353badb9be9bf7ce9434b3 */MD5SUMS
<mdz> 20050308.1/MD5SUMS:54baddb324353badb9be9bf7ce9434b3  hoary-install-powerpc.iso
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/daily $ ls -l current
<mdz> lrwxrwxr-x    1 cjwatson cdimage         8 Mar  9 07:24 current -> 20050309
<mdz> you have 20050308.1
<mdz> 20050309 is current
<pitti> bah
<pitti> maybe the current symlink was wrong then?
* pitti updates again
<Keybuk> mdz: I wasn't awake hours ago :p
<mdz> Keybuk: we're going to remove the provides from polypaudio
<Keybuk> yeah, that's pretty much what I'd do
<mdz> Keybuk: I wasn't particularly awake myself :-P
<Keybuk> "Hoary Hedgehog Preview Release ... brought to you by CAFFIENE!"
<mdz> jdub: ETA for ubuntu-artwork?
<jdub> mdz: conferring with mark/jane atm
<jdub> er, in a moment
<dholbach> hi seb128 
<Treenaks> Good morning France! :)
<jdub> yoseb
<jdub> seb128: see gnome-panel upload
<pitti> Hi seb128 
<seb128> hey hey
<seb128> jdub: thanks for the applets & panel love :)
<jdub> seb128: we'll fix that before preview :)
<jdub> erer
<jdub> er
<jdub> eeek
<jdub> final
<seb128> fix what ?
<jdub> the panel hack
<jdub> (it is not i18n aware, due to doc package)
<seb128> that's not a hack
<jdub> but ok for preview ;)
<seb128> oh, right
<jdub> it so is dude ;)
<seb128> but there is no translation of that atm
<jdub> we should do yelp ghelp:about-ubuntu or whatever
<jdub> yeah
<seb128> bah, a .desktop file doesn't seems to be a hack
<jdub> hopefully taht'll be fxied for final too ;)
<seb128> do we already have the preview images ?
<mdz> seb128: we are waiting for ubuntu-artwork from jdub
<mdz> and then we should be able to test the next (and possibly last) candidate
<seb128> bah, that's only a preview
<seb128> (this panel menu not localized bother me)
<pitti> mdz: is it possible to s/Warty Warthog/Hoary Hedgehog/ on the "About Ubuntu" html page?
<pitti> mdz: which package provides this?
<jdub> pitti: we don't need to
<mdz> pitti: jdub's gnome-panel upload points it to a new file
<jdub> pitti: it's going to be removed anyway
<pitti> ah, ok
<pitti> cool
<seb128> pitti: you have not planned any language-pack update before preview ?
<pitti> seb128: I uploaded all the crack about midnight
<pitti> seb128: please don't tell me you uploaded packages with heaps of new strings afterwards ....
<seb128> no
<mdz> pitti: are you still having problems with your keyboard layout on the live CD?
<pitti> seb128: I can always publish new ones, but they need to be built and put into the CDs
<seb128> I'm just bothered to have a "System" menu not localized in the middle of my french GNOME
<pitti> mdz: yes, same thing
<pitti> mdz: I replied to the bug
<seb128> and that's probably the same for all the different languages :p
<mdz> pitti: but it works on install?  that is very strange if so
<Treenaks> seb128: same here in Dutch
<seb128> that's a really bad effect
<pitti> mdz: maybe the reason is that xorg.conf is readonly on the live CD?
<pitti> mdz: yes, it works (almost) fine on install; for install it only configures pc104 instead of pc105, but this is a minor thing
<mdz> pitti: if that were so, X would not work at all
<pitti> hmm, right
<Treenaks> seb128: someone added a comment about this here: https://bugzilla.ubuntu.com/show_bug.cgi?id=7285                                
<mdz> pitti: can you send me /var/cache/debconf/config.dat from the live CD?
<pitti> mdz: yes, let me boot it
<seb128> Treenaks: I know, I don't understand anything of this "Ad ..:" and I've read the comment several times
<Treenaks> seb128: it's just backreferences.. "Ad 1" refers to [1] 
<pitti> mdz: btw, keyboard on text consoles is fine
<seb128> Treenaks: that's no sense
<mdz> pitti: yes, that's handled by a less hairy mechanism :-)
<seb128> Treenaks: "- Add/Remove Programs[2] " == "Ubuntu-package: not translated at all (isolate i18n-strings and use pygettext to create po-template)"
<seb128> Treenaks: what does pygettext does in that ?
<Treenaks> seb128: he's a gnome person.. not a lot of ubuntu experience
<mdz> jdub: how is the GNOME release?
<pitti> mdz: http://people.ubuntu.com/~pitti/config.dat-ppc-live-german
<mdz> Name: debian-installer/keymap
<mdz> Template: debian-installer/keymap
<mdz> Value: mac-usb-de-latin1-nodeadkeys
<mdz> Owners: base-config, d-i
<mdz> that looks reasonable
<pitti> ack
<pitti> mdz: btw, daniels' detection script works fine, too
<mdz> pitti: that's so strange
<pitti> $ sudo ./detect-keyboard.sh
<pitti> layout is de
<pitti> rules are xorg
<pitti> model is pc104
<pitti> options are nodeadkeys
<mdz> pitti: look at /var/lib/dpkg/info/xserver-xorg.config, line 1715
<mdz> this should be the same code as detect-keyboard.sh
<mdz> I don't see an entry in the case statement which corresponds to mac-usb-de-latin1-nodeadkeys
<mdz> oh, I see, this fallback:
<mdz>     *--de*) XMAP="de"; OPTIONS="nodeadkeys";;
<mdz> that is based purely on LANG
<mdz> so perhaps $LANG is not set properly at that point
<mdz> mvo: do you have this problem as well?
<mdz> it seems like it may be specific to the mac-* layouts
<pitti> mdz: maybe, locale in the running system is correct; maybe it is read too late
<mvo> mdz: I had it, but I can't test right now, my test-systems cdrom seems to be b0rked today
<pitti> mdz: however, the real fix seems to be to add the mac-usb keymaps then
<pitti> mdz: since we already saw that locale-based choice is wrong
<mdz> pitti: the question is whether $LANG is set in d-i
<mdz> I would expect so, but perhaps not
<pitti> mdz: ah, that's the reason why the detection script works in the running system
<pitti> because LANG is correct then
<mdz> pitti: could you paste our conversation into the bug so that we do not forget?
<pitti> yes
<mdz> pitti: yes, it seems very likely that this is the source of the problem
<mdz> mvo: are you on powerpc as well?
<mdz> pitti: what is the bug#?
<pitti> mdz: 7138
<pitti> mdz: just posted the followup
<mdz> thanks
<mvo> mdz: no, i386. I could get access to a  ppc if it is required/urgent
<mdz> mvo: I'm very interested to know if it happens for you on i386
<mvo> mdz: live-cd image is downloaded in ~2 minutes, then I'll burn it on a CD-R (my testsystem has either problems with it's cdrom or my cdrws are all faulty now). I'll keep you updated
<mdz> mvo: thanks
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current/ | review preview ann.: http://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<fabbione> mdz: do we have also the last gnome stuff?
<mdz> fabbione: we have everything except ubuntu-artwork from jdub
<fabbione> ok
* fabbione rsyncs
<Mithrandir> elmo: http://sources.redhat.com/ml/binutils/2004-09/msg00299.html ; do you have any thoughts on the patch or should I ask doko?
<fabbione> hmm no
<fabbione> they are not propagate to the CD yet, are they?
<mdz> did Kamion mention at what time he intended to return?
<mdz> fabbione: there are a few small things which are not on the CD yet, because I am waiting for ubuntu-artwork to do a full set of builds (live fs, install CDs, live CDs)
<elmo> Mithrandir: h j lu patches are to be avoided unless they're a) approved, b) have had a two week cooling off period to ensure they haven't broken random shit
<elmo> IMO
<doko> elmo: approved by amodra
<elmo> then it works for me
<elmo> however, I hope you're not thinking we need this for hoary?
<Mithrandir> it would be nice to have so ld would barf instead of falling over with an assertion error.
<Mithrandir> collect2: ld terminated with signal 11 [Segmentation fault] 
<Mithrandir> /usr/bin/ld: BFD 2.15 assertion fail ../../bfd/elflink.c:6081
<elmo> Mithrandir: we're at preview - is it really worth changing the way ld dies now?
<Mithrandir> elmo: ok, hoary+1, then.
<fabbione> mdz: ok..
<Mithrandir> you know binutils better than I do. :)
<doko> first class funeral are important ;)
<elmo> probably not, but I do bear H.J.Lu-scars
<seb128> mdz, jdub: I've a gnome-panel with "System" localized in all the locale (the string comes from yelp 2.6) ... any change to get that in the preview ?
<mdz> seb128: it would require that pitti do new langpacks
<jordi> seb128: are the translations in hoary the official ones in the GNOME tarballs?
<mdz> jordi: yes
<jordi> cool
<pitti> mdz: I can do update packages, they are relatively cheap
<jordi> so everything but "System" will be translated?
<mdz> pitti: they worry me, though
<jordi> that's a very visible string
<seb128> mdz: I know, but that's the most visible string on screen
<pitti> mdz: let's get it perfect for final
<mdz> pitti: because we have not fixed bug #164595
<seb128> s/that's/that's like/
<seb128> I'm a bit annoyed to ship a preview with a panel not localized correctly
<pitti> mdz: we worked around this by a Pre-Dependency
<seb128> you see 3 labels on the desktop and one of them is "System" in english
<mdz> pitti: oh, ok
<mdz> seb128: go ahead, pitti can update the langpacks
<jordi> I curse jdub, I gotta sort a few things with sabdfl and he's  totally centered on him
<pitti> mdz: so the -base package will be installed first in any case
<seb128> mdz: thanks
<pitti> seb128: ping me if the package is built
<pitti> seb128: because I need the translation tarball
<jordi> seb128: can you confirm ca does have that translation?
<seb128> pitti: I know, don't worry
<jordi> should be. It's "Sistema" in any case
<mdz> seb128: so you were able to get translations for System in many languages from yelp?
<seb128> jordi: 
<seb128> msgid "System"
<seb128> msgstr "Sistema"
<jordi> thanks
* pitti now installs 20050309 ppc
<jordi> I hope about ubuntu and stuff is preserved since warty
<jordi> but anyway
<seb128> mdz: 76 languages
<mdz> jordi: you could help us by testing the live CD :-)
<jordi> mdz: which doesn't have ca translations :(
<pitti> mdz: am I right with my assumption that now is not a good time to upload a perl security update to Hoary?
<seb128> jordi: nop, About Ubuntu is a temporary .desktop hack atm
<jordi> I've tried, I tell you
<mdz> pitti: that is correct
<mdz> jordi: it doesn't?  which one did you try?
<mdz> oh, right
<jordi> mdz: but sure, point me to an image I can use and I will rush to test it
<jordi> mdz: hmm array6
<mdz> ca is not in the list for the live CD
<mdz> we may have some space left to add more languages, but not much
<jordi> mdz: oh dude YOU WOULD MAKE ME HAPPY
<seb128> mdz: panel uploaded
<seb128> pitti: I'll let you know when the build is ok
<pitti> ok
<mdz> pitti: after preview, can you check to see how many more langpacks we could fit on the live CD?
<pitti> seb128: luckily I just improved langpack-o-matic to spit out minimal update packages without much effort
<seb128> thanks guys for that, better to have the menu in user's locale :)
<jordi> mdz: and I would start promoting those live CD's against "Catix" (knoppix based crappy Catalan distro) egemony in Catalonia
<pitti> mdz: yes, of course; after preview I also wanted to do some -0ubuntu0 uploads for stripping the handful of big packages you selected
<jordi> mdz: I mistakenly suggested people to download array6 and then we discoevered ca wasn't n
<mdz> jordi: unfortunately I don't think we can change this for preview, but we will try to support more languages after
<jordi> in
<jordi> mdz: hrm. The other day I thought about having some extra cd images with some other langs
<jordi> but if ca can go in final, hey that rocks :)
* mvo is away for a couple of minutes to test the live-cd on his main system
<mdz> jordi: it would be very easy to build a customized live CD with ca support
<mdz> jordi: http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<mdz> just a little bit of time and disk space
<mdz> but hopefully we can support it by default for final
<jordi> mdz: can I do something so you remember to have a look?
<mdz> jordi: you can remind pitti in a few days :-)
<pitti> mdz: so the battle for langpack CD space officially begins :-)
<jordi> pitti: I am going to be like your shadow
<mdz> jdub: I need an answer on ubuntu-artwork
<mdz> jdub: it will take 2+ hours to get a candidate built once we say go
<seb128> jdub: I've a patch ready for the submenus switches in System
<pitti> Hi sivang
<pitti> hrm
<pitti> Morning sivang 
<sivang> pitti: Morning :)
* Amaranth pokes around for a GNOME dev
<Amaranth> anyone know why gnome.org is down?
<mdz> 2.10 release overload?
<Treenaks> Amaranth: because they're releasing?
<Amaranth> wow, i don't even think mozilla.org when down when firefox came out
<Amaranth> well, not for this long
<Amaranth> err, went
<Amaranth> it's 5am
<pitti> mvo: successful?
<mdz> perhaps they were h4x0red
<mvo> pitti, mdz: yes, booting with german as language gives me a pc105 german keyboard in X
<mdz> at any rate, that'd be a question for #gnome or such
<pitti> mvo: okay, it's the lack of detection support for mac-usb keyboards for sure
<Amaranth> yeah, they're pretty idle, figures someone here would know
<mdz> mvo: ok, so I think we are confident abotu the nature of pitti's problem
<pitti> mvo: good to hear that i386 works fine :-)
<mdz> and it affects relatively few systems
<pitti> yes, that's relieving
<pitti> it would be a shame if the live CD was broken for i386
<pitti> because it is so much better than warty's :-)
* mvo will go to get a new cdrom after lunch
* sivang --> brb
<mvo> yeah, the new live cd really rocks!
<pitti> sivang: connection problems today?
<mdz> mvo: it has this great new feature where it actually boots most of the time ;-)
<pitti> mdz: indeed, the live CD failed for 75% of the people I gave it to
<pitti> mdz: (warty's)
<mdz> it failed for many people I know, too :-//
<pitti> pretty embarassing...
<mvo> mdz: yes, that's one of it's strong points :) I like the design too
<sivang> pitti: since yesterday :-/ had a nice time of no problems at all, then suddenly 3 days ago things b0rk3d, cable infrastructure seems fine, so maybe this is only a problem with the ISP's routing etc..
<sivang> pitti: so since about 3 days I having accesss that comes and goes with no apparent reason
<mdz> I am unable to reach jdub or sabdfl
<mdz> does anyone know what is going on?
<jdub> mdz: we're on the phone
<jdub> mdz: you're not going to like the results
<jdub> mdz: brb
<mdz> jdub: I'm OK with whatever as long as we don't delay preview further
<jdub> is elmo around?
<mdz> yes
<pitti> seb128: gnome-panel_2.10.0-0ubuntu3_translations.tar.gz is present
<pitti> seb128: that should be the right one?
<mdz> jdub: whenever you guys would like to bring me into the loop regarding the release, I'm standing by.  running on little sleep over here
* pitti watches ugly errors when "Registering Documentation"...
<elmo> jdub: yes
<jdub> mdz: will get off in a sec
<seb128> pitti: correct
<pitti> seb128: okay, I can build new update packs if everything is in
<pitti> I mean _really_ :-)
<seb128> as far as I'm concerned go for it
<jdub> ok
<jdub> mdz: we need to get clearlooks in main
<jdub> gtk2-engines-clearlooks
<mdz> beg your pardon?
<jdub> yeah, serious
<mdz> I am not sure that I am prepared to stay up an extra hour for this
<jdub> can Kamion take over?
<mdz> Kamion is dead asleep
<seb128> jdub: you want to switch the default theme for preview ?
<mdz> he was up until 6am or osmething
<jdub> seb128: sabdfl has asked us to, yes
<fabbione> that means seeding -> archive propagation -> cd rebuild
<fabbione> + testing
<fabbione> = 2 hours if we are all here
<fabbione> (at least!)
<seb128> jdub: we have the fix for the label colors ?
<Amaranth> oh sure, now you work on clearlooks, after i install from source :P
<mdz> fabbione: it is much more than that
<jdub> well, gnome 2.10 is not out yet anyway
<mdz> the live fs build alone is 20-30 minutes
<jdub> Amaranth: it's in universe
* Amaranth hugs clearlooks-indubstrial
<seb128> Amaranth: it's in universe for a week or so
<Amaranth> d'oh
<jdub> seb128: we have a different gtk theme anyway
<Amaranth> i installed from source 4 days ago
<seb128> jdub: different of what ?
<mdz> jdub: clearlooks is new code
<jdub> mdz: it's well tested
<seb128> jdub: you want to use clearlooks for what ? not gtk ?
<mdz> jdub: not in Ubuntu it isn't
<jdub> seb128: yes
<Amaranth> isn't there already a clearlooks-human theme?
<mdz> this is madness
<jdub> mdz: you need to call sabdfl 
<mdz> I SMSed him
<jdub> i'm just the messenger
<jdub> and i told him no one would like the message
<pitti> jdub: does clearlooks involve any translations?
<mdz> jdub: I would have liked it fine a week ago
<jdub> pitti: no, it's a widget theme
<jdub> mdz: i understand
<jdub> mdz: i boringly and rigidly said no.
<fabbione> jdub: is that why you are telling us to do it? ;)
* fabbione hides
<Amaranth> sabdfl == Mark?
<jdub> i also told mark that my testicles would be blue at UDU because of this
<jdub> i'm fundamentally aware of the problem
<mpt_london> Amaranth: yes
<Amaranth> ah, that explains a lot
<theine> Hi, are there any plans for including gnome-bluetooth into main?
<pitti> theine: not for hoary
<theine> ok
<pitti> theine: can you please ask this again in some days?
<pitti> theine: the folks are currently very busy with the preview release
<theine> sure, no problem
* mpt_london installs this clearlooks thing to see what everyone's talking about
<ogra> morning
<pitti> Hi ogra
<mdz> jdub: spoke with Mark, I'm crashing, please do what needs to be done, see you in 7 hours
<ogra> clearlooks hasnt a human colorset yet, i'm using it since about a week and it seems stable....
<pitti> mdz: sleep well, mdz
<ogra> g'night mdz
<jdub> mdz: thanks; sleep very well
<jdub> ogra: that's coming in ubuntu-artwork
<dholbach> good night mdz
<ogra> jdub, i just read up.....(just wated to take mdz's fear abour stability a bit) :)
<seb128> 'night mdz 
<ogra> s/abor/about
<dholbach> hi ogra
<jdub> ok, making seed change now
<elmo> jdub: please tell me what to promote too - waiting for seeds to propogate will take time
<jdub> gtk2-engines-clearlooks
<elmo> ok, promoted
<sivang> hi ogra , dholbach 
<dholbach> hi sivan!
<ogra> morning sivang 
<jdub> so what we're doing
<jdub> so everyone groks what's going on
<jdub> is adding the clearlooks theme to the desktop (and thus the CD)
<jdub> and using it as the default theme
<jdub> to make maximum impact
<jdub> though it does mean we delay
<jdub> meanwhile, if anyone hadn't noticed, GNOME 2.10 hasn't been released yet because the servers are down
<pitti> *sigh*
<seb128> jdub: anybody knows what's going on with the servers ?
<sivang> jdub: yeah, I thought it was becasue of the load on the servers?
<jdub> so everyone's having fun tonight it seems :)
<jdub> seb128: haven't got a reasonable answer yet
<seb128> k
<jdub> seb128: going to ring owen soon
<fabbione> jdub: and what are the 2.10 pkgs we are shipping now?
<jdub> fabbione: the latest seb did hours ago
<jdub> fabbione: the ones that will be in the release
<ogra> fabbione: sneak preview ;)
<jdub> (the tarballs are gathered a couple of days before the release)
<pitti> seb128: I need your help
<seb128> fabbione: he's speaking about official announce for 2.10
<jdub> ah, fuck it, going to call owen now
<fabbione> seb128: ahhhhhh
<seb128> fabbione: the tarballs/packages are the 2.10 ones
<pitti> seb128: tarball for gnome-panel is broken (no mo files)
<maswan> jdub: not the ftp server though, right?
<fabbione> seb128: you rock!
<pitti> seb128: and there is only one pot file "yelp.pot"
<fabbione> seb128: even if you are a gtk bug!
<seb128> pitti: are you kidding me ?
<jdub> maswan: no
<pitti> seb128: is the domain really "yelp"?
<jdub> ah
<jdub> fuck
<jdub> man
<maswan> Good, had it been the ftp server, I should have heard of it (and been working hard on fixing it) by now.
<pitti> seb128: is the domain "gnome-panel"?
<seb128> pitti: correct
<seb128> pitti: the yelp.pot has been copied with the System strings from yelp
<seb128> pitti: but I don't get the "there is no .mo"
<seb128> I've not changed anything out of adding a string to the .po files
<pitti> seb128: erm, I just found an older tarball, there it is "gnome-panel-2.0"
<seb128> pitti: arg
<seb128> lemme check
<pitti> seb128: no, really, in the latest upload there is a "yelp.pot"
* pitti kicks pkgstriptranslations
<seb128> pitti: <seb128> pitti: the yelp.pot has been copied with the System strings from yelp
<Kamion> fuck, sorry, overslept; anything I need to do now?
<fabbione> Kamion: no.. we released already
<seb128> pitti: I can fix it since we are delayed for the gtk2-engines stuff
<ogra> Kamion: waiting
<pitti> seb128: find -name "*.mo" -exec basename '{}' \; | sort -u
<ogra> Kamion: for inclusion of clearlooks in main
<Kamion> fabbione: I've read enough scrollback not to be fooled by that :)
<pitti> seb128: no need to fix it, I just need the correct domain
<Kamion> 11:42 < elmo> ok, promoted
<fabbione> Kamion: :P
<pitti> seb128: I think it is gnome-panel-2.0
<seb128> pitti: gnome-panel-2.0
<seb128> pitti: let me fix it
<seb128> pitti: there is no hurry due to clearlooks
<pitti> seb128: no worries, I add an override
<elmo> Kamion: if we're going to need another d-i for this (can't see why), lemme know, as we still have this morning's cron.daily in q/byhand
<Kamion> elmo: nope, best not
<pitti> lamont: ping?
<Kamion> jdub: have you done ubuntu-meta, or do you want me to?
<jdub> Kamion: please do
<Kamion> will have to wait until cron.daily
<jdub> when's that?
<Kamion> +4mins
<jdub> making related u-a changes
<Kamion> jdub: what needs to change to make clearlooks the default theme, rather than just present? just u-a?
<jdub> yes
<jdub> it will be called Human
<jdub> so no default changes or anything
<sivang> what's with gamin_server , everytime I do an upgrade it eats CPU cycles and apparently scans all my drives, bringing the system to a painful slowdown..
<jdub> (*phew*)
<pitti> seb128: "there is no .mo" -> not your fault
<seb128> pitti: oh ?
<pitti> seb128: either one buildd is outdated, or there is another bug in pkgstriptranslations
<seb128> pitti: BTW I'm doing an upload now to fix that
<pitti> seb128: what was wrong? how did the yelp.pot file came into the g-panel source package?
<Kamion> man, I had dreams last night that I had to fix installer bugs for preview
<seb128> pitti: the 76 "System" translations come from yelp
<fabbione> Kamion: and did you write down the patches before waking up?
<seb128> pitti: I've made a quick python script to grab "System" in all the po files and copy it with the translation in the panel po files
<seb128> pitti: and it has grabbed the .pot with them
<pitti> ah, ok
<seb128> look on the .pot :p
<pitti> seb128: because older tarballs do not ship a pot file at all (which is another bug, because the Rosetta guys need it)
<seb128> k
<Kamion> fabbione: nope :)
<pitti> seb128: but I don't need the pot for langpack-o-matic, so this has time
<Kamion> are there more langpack changes needed for preview?
<pitti> Kamion: yes, I was just asked to upload new update packages for the gnome-panel changes
<seb128> Kamion: I've added the "System" translations in 76 languages to the panel, better to have the menu title translated
* thom reboots to test the new daily on amd64
<Kamion> ok, tell me when those are done since I won't see them on hoary-changes
<Kamion> jdub: intentional that indubstrial's still in desktop?
<jdub> industrial? yes
<Kamion> er, yeah, that
<Kamion> ok
<pitti> Kamion: ok
* pitti uploaded new language packs
<Kamion> ubuntu-meta done, too
<Kamion> jdub: will ubuntu-artwork make this cron.daily?
<jdub> could do
<jdub> no
<jdub> Kamion: uploading now
<fabbione> Kamion: what about desktop-sparc?
<fabbione> (ubuntu-meta)
<koke> seb128: the System panel menu keeps appearing to me as "Desktop" (and untranslated)
<koke> seb128: using 2.10.0-0ubuntu3
<Kamion> fabbione: it didn't want to auto-update; I have no intention of waiting for it
<fabbione> ah ok
<seb128> koke: should be "System", you have probably and old translation somewhere
<jdub> Kamion: you've got gnome-panel 2.10.0-0ubuntu2 ?
<fabbione> works for me
* jdub tries upload again
<seb128> jdub: upload what ?
<fabbione> jdub: there is gnome-panel ubuntu4 from seb....
<Kamion> jdub: gnome-panel | 2.10.0-0ubuntu3 |         hoary | amd64, i386, ia64, powerpc, source
<jdub> oh man
<Kamion> I guess ubuntu4 will make it next cron.daily
<seb128> .daily ?
<Kamion> oh, actually, next but one cron.daily since it has to build
<elmo> jdub: try again - you'd managhed to upload just the .dsc
<Kamion> pitti: what version of language-pack-*-update am I watching out for?
<jdub> seb128: ubuntu-artwork
<jdub> my net's fucked
<jdub> sec
<jdub> oh
<jdub> right
<jdub> great
<jdub> n/m
<jdub> am i back?
<Kamion> yes
<pitti> Kamion: no -update; language-pack-foo 20050309
<Kamion> all at once
<Kamion> pitti: oh, duh, yeah
<Kamion> thanks
<pitti> Kamion: the -base packages remain at 20050308
<jdub> yo?
<jdub> fuck
<Kamion> jdub: PING
<Kamion> jdub: PONG
<Kamion> 12:31 < jdub> yo?
<thom> Kamion: grub install on i386 just bombed with "The file /boot/grub/stage1 not read correctly", current daily built from jigdo
<thom> could be jfs related (testing it for kicks), trying ext3 now
<Kamion> I doubt jfs /boot will work, it's just a missing check
<thom> ok
<Kamion> you should be able to use ext3 /boot and jfs / though
<thom> nod; i don'tmuch care, was just curious and figured i should report it
<Kamion> yep, thanks
* thom wonders idly if the x86 install will overtake the powerpc install
* thom blinks; is there no way that the language pack stuff could be samrter about generating locales? i don't even know what en_PH is
<ogra> thom: philosophical english ?
<Treenaks> thom: PH is Philippines
<thom> Treenaks: i was kinda assuming that was the case, ut even so
<Kamion> the installer already puts en_* locales into locale.gen; perhaps it could check to see whether relevant locales are already present, and not be too stressed about regenerating if they are
<elmo> thom: see u-d and my previous whinings
<thom> ah, you already whined? cool cool
<elmo> (or more to the point, mdz's reply)
<koke> seb128: it's ok, my System menu appears now as system after cleaning /usr/local :)
<jdub> back on air?
<jdub> aha
<jdub> i am
<tseng> you're live, jdub 
<seb128> koke: nice
<seb128> jdub: is there somebody working on the translations updates for the desktop/hoary ?
<jdub> seb128: rosetta people?
<seb128> jdub: ie: is that worth than I make a list of the hoary specific strings all over the desktop and mail the lists ?
<Kamion> jdub: oh, if you're changing Human, what happens to the old Human theme?
<seb128> jdub: dunno but nobody has sent any string atm, the current system obviously doesn't work. I guess that rosetta people are busy on the tool and doesn't bother about what should be put in and pointed to people :)
<jdub> Kamion: gone.
<jdub> seb128: yeah
<Kamion> ok
<jdub> Kamion: it's not a hugely major change, and you can always click back to industrial
<carlos> seb128: dude, we are busy because we are finishing the Ubuntu's l10n infrastructure
<seb128> jdub: same about the hoary xml files pointed by the about ubuntu  ... is there anything running for that ? If not I'll tackle that this afternoon
<carlos> seb128: working full time on it
<seb128> carlos: I don't blame anybody, I just note than we don't have any localization for the ubuntu changes atm
<Kamion> hm, the blue-on-brown thing with clearlooks is a bit weird
<jdub> seb128: i don't think the doc i18n stuff is sorted with rosetta yet
<jdub> Kamion: blue on brown?
<carlos> seb128: I know, and you can blame us, we are out of schedule
<Kamion> blue window title bars, brown background
<jdub> erm
<Kamion> desktop background
<jdub> Kamion: choose Human
<carlos> jdub: right, no documentation translations with Rosetta for Hoary
<Kamion> oh, it'll munge the colours? ok.
<seb128> carlos: don't worry, I'll push on that, I just don't want to dup work with you guys
<jdub> Kamion: yeah, gtk+ theme defines the colours
<seb128> jdub: we can use the same system as GNOME 2.10 /xml-po stuff ?
<jdub> Kamion: phheeew, you had me worried for a sec
<jdub> seb128: yes
<jdub> seb128: well, probably
<carlos> seb128: if you put the translations inside the source package, it will be added automatically to Rosetta, so you will not duplicate any work
<Kamion> jdub: well it hasn't been uploaded yet, so I just have to guess :P
<jdub> it has
<Kamion> jdub: 12:30 < elmo> jdub: try again - you'd managhed to upload just the .dsc
<jdub> it's already up
<seb128> jdub: k, I'll do that today if you don't mind (ie: no other stuff for me to do first)
<jdub> i did again
<Kamion> no it isn't
<Kamion> hoary-changes does not have mail
<jdub> argh
<jdub> -rw-r--r--  1 jdub jdub  457 2005-03-09 23:36 ubuntu-artwork_0.2.19-1_source.upload
<seb128> jdub: I'm sure than some locale teams can translate that for hoary if we provide the po files
<carlos> seb128: too late to move into xml-po for Hoary
<jdub> i'll do again
<seb128> carlos: ?
<carlos> seb128: you asked: " we can use the same system as GNOME 2.10 /xml-po stuff ?"
<seb128> carlos: not speaking about you, I'm working that around 
<seb128> carlos: yeah, GNOME 2.10 notes are translated using that, I want to copy the system 
<sabdfl> hi all
<carlos> seb128: if you handle it by hand to create the .pot file, we are able to use Rosetta, yes
<Kamion> afternoon Mark
<seb128> hey sabdfl 
<sabdfl> Kamion: thanks for the marathon session last night
<jordi> Hmm, it's nearly time to pack up. I don't think I'll be back at the appartment.
<seb128> carlos: that's the idea
<sabdfl> seb128, Kamion, jdub: can you guys give me a quick status please
<Kamion> sabdfl: just a shame I didn't quite make it up again before mdz went to sleep :)
<pitti> Hi sabdfl 
<sabdfl> Kamion: i had to force mdz to rest
<ogra> hi sabdfl 
<sabdfl> hey ogra
<Kamion> sabdfl: as far as I know we're now just waiting for ubuntu-artwork, then I'll kick install CDs, live cloops, and live CDs in turn
<sabdfl> ok
<Kamion> since we'll likely be ready before mdz gets up again, who's doing the announcement?
<sabdfl> we'll wait for mdz
<Kamion> ok
<sabdfl> jdub: hard deadline of 3pm UTC for the artwork uploads
<sabdfl> Kamion: please start the rebuild no later than 3pm
<sabdfl> do we have any mirrors we can trigger?
<Kamion> sabdfl: jdub is trying to get it uploaded right now, he just ran into upload glitches
<sabdfl> Kamion: in case there are ongoing issues, i want to have a hard cutoff
<sabdfl> agreed with mdz
<Kamion> fine
<sabdfl> Kamion: how long does the build process take, usually?
<jdub> gnome isn't even out yet ;)
<sabdfl> is it going to change from what we have?
<Kamion> sabdfl: about an hour to build
<Kamion> everything
<jordi> jdub: are all the tarballs released though?
<Kamion> then time for people to download and test
<jdub> sabdfl: it's already done
<jdub> but i'm having network issues, evidently
<jdub> jordi: of course
<jdub> jordi: due date is monday
<Kamion> can you scp to somewhere more reliable and upload from there?
<jdub> attempting to upload 4MB with this packet loss is ridiculous
<Kamion> sabdfl: two hours from beginning of build to being able to say go is a comfortable timeframe; we can pull it lower than that but I'd rather not
<sabdfl> aiming for 19h00 UTC
<sabdfl> mdz will be up 18h00 UTC
<sabdfl> would like to have it rolled, mirrored as widely as possible, and tested by then
<jdub> yeah, trying that
<sabdfl> do we have any mirrors we can trigger
<sabdfl> ?
<Kamion> elmo: can we give mirrors some notice?
<sabdfl> jdub: will the gnome code change at all before release? or are we good to go
<jdub> sabdfl: we're fine
<sabdfl> eta on the gnome release?
<sabdfl> jdub: ^
<sabdfl> i have to step out for half an hour
<sabdfl> jdub, kamion, i think it would be poor form to release before gnome
<ogra> hmm, gnome.org is still down....
<sabdfl> can you guys discuss and come up with a plan if gnome.org is still down at 18h00 UTC
<sabdfl> brb
<mvo> hi froud 
<HiddenWolf> gnome.org down? whoops
<jdub> why does everyone keep asking that? :)
<jdub> gnome tarballs were due two days ago
<jdub> we don't need any updates at all
<Kamion> elmo: can we kill boot-floppies from universe? :-) There seems little point in trying to build it
<jdub|piractical> ahar!
<ogra> heh
<jdub|piractical> uploading via alternate route :-)
<Kamion> "piratical" :-)
<jdub|piractical> it's up!
<thom> jdub|piractical: next doors dsl?
<thom> :P
<jdub|piractical> fie on my stinkin' upstream bandwidth, me hearties!
<jdub|piractical> i be shippin' with me neighbour!
<jdub|piractical> thom: ahaye
<Kamion> elmo: could you hurry this one through?
<jdub> and sshing back home, where the connection seems fine :|
<thom> ok, crrent dailies are fine on amd64/i386/powerpc for me; only minor issue is the scrollkeeper spew which i know colin has already mentioned
<Kamion> yeah, current daily still has old gnome-applets
<fabbione> Kamion: do you have the new gnome-applets?
<fabbione> perhaps i can test the DVD, if you feel like updating it
<Kamion> I'm not going to update the DVD just yet, 'cos it'll take ages and block the CD build
<fabbione> ah ok
<fabbione> i didn't know it was a blocker
<Kamion> I'll do it after the CD builds are all done, though
<Kamion> well, it's just insufficient locking/separation on cdimage
<Kamion> I think I can do Ubuntu and Kubuntu builds in parallel
<Kamion> but I cannot do multiple Ubuntu builds at once, or multiple Kubuntu builds at once
<Kamion> gnome-applets | 2.10.0-0ubuntu2 |         hoary | amd64, i386, ia64, powerpc, source
<lamont> Kamion: which version of postfix is on the install CD these days, I wonder
<Kamion> lamont: 2.1.5-9ubuntu1
<lamont> GRRR
<sabdfl> back
<Kamion> sabdfl: we have ubuntu-artwork source now, waiting for buildds
<dholbach> {ftp,mail}.gnome.org are online
<ogra> dholbach: havent been of afauk
<ogra> s/u/i
<ogra> off even
<dholbach> ah ok
<dholbach> i see
<HiddenWolf> why is gnome.org off?
<jdub> no answer yet.
<ogra> probably the webmaster slipped on a banana peel.....
<ogra> ...there were a lot around these days
<sabdfl> Kamion: thanks
<sabdfl> while  we're waiting, Kamion, could you take a turn backing on:
<sabdfl> http://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<Kamion> I'm keeping little warmed up building kubuntu CDs
<sabdfl> let's add in as much technical stuff as possible to the list
<Hannes_> Gnome.org is changing looks for 2.10 release :P
<Hannes_> or not
<dholbach> ubuntu-artwork built on i386
<jdub> Hannes_: that's mourning for europe.
<Treenaks> has the final name for hoary+1 been chosen yet?
<sabdfl> Treenaks: yes
<thom> Treenaks: cold turkey
<sabdfl> :-)
* thom ducks and runs
<jordi> woa, if it's a secret, I was veery close to talk too much :)
<lamont> dholbach: and since it's arch: all, that's the only one that matters.
<Treenaks> thom: :P
<dholbach> lamont: i imagined that, but didnt have a closer look :-)
<sabdfl> jdub: when's the best time to announce the name for hoary+1?
<jdub> sabdfl: preview release announcement would be awesome
<jdub> sabdfl: certainly better there than in the final release announcement
<sivang> jdub: shouldn't we mention a word or two about gnome-app-install on the technical list?  (A pointy clicky way to install/remove new applications)
<jdub> sabdfl: or do you want to do a separate one?
<jdub> sivang: hrm, last i read we had a general install/update tools thing
* jdub loads
<sabdfl> jdub: yes, i'm happy with preview release, would also go in final release
<seb128_> jdub: do we gave updated desktop files ?
<sabdfl> Kamion: done with the announcement?
<jdub> sabdfl: seems a bit "don't look now but..." for final
<jdub> seb128_: not for preview
<jdub> sivang: yeah, what's in there is fine
<seb128_> k, so no need to point g-i-a
<sivang> jdub: ok cool
<Kamion> sabdfl: just made a couple more tweaks
<Kamion> sabdfl: done for now
<sabdfl> ok
<sabdfl> seb128: could you take a turn on it?
<sabdfl> http://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<sabdfl> i'm playing "plone locking system" today
<sabdfl> call me the BPL
<Kamion> BPL?
<Kamion> oh :-)
<jdub> sabdfl: hrm, would be good to switch from 'their' to 'our'
* Kamion optimises away sabdfl and replaces him with a fine-grained locking system
<ogra> busy plone locker ?
<jdub> sabdfl: seems more personal
<pitti> ogra: s/busy/big/ ?
<Kamion> ogra: analogy with BKL
<ogra> K ?
<sabdfl> that's a trouble entendre if i ever saw one
<thom> big kernel lock
<ogra> ahh
<zul> gday
<sivang> when are we expecting to release? I want to know when to spread over the local portals etc.
<Kamion> sivang: currently aiming for 1900 UTC
<Treenaks> sivang: not to mention release parties :P
<sivang> Treenaks: right :)
<sivang> btw, how would you explain "shrinkwrapped" cds?
<koke> where is the source for release-notes??
<koke> are they going to be translated?
<sivang> "..includes all of Debian as well as most of the packages of apt-get.org.." => is this referring to universe?
<Treenaks> sivang: yes
<sivang> Treenaks: did the motus take many packages from there? :)
<Treenaks> sivang: unknown. :)
<sivang> Treenaks: this mention of apt-get.org was a surprising bit in the announcment draft
<abelli> what package is ssh.h in?
<ogra> sivang: nope
<sivang> abelli: apt-file search ssh.h
<Burgundavia> To be more specific with this line - "To sign up for future announcements of this type" what about changing of this type to "about Ubuntu releases" or something similar
<sivang> abelli: but you have to install apt-file first.
<Hannes_> abelli: openssl-dev?
<Kamion> ssh != ssl
<Hannes_> abelli: openssh-dev?
<Kamion> no such package
<abelli> dont have it
* Kamion <- openssh maintainer
<abelli> Kamion, hello my friend.. -:)
<Kamion> openssh does not ship an ssh.h; there's an ssh.h buried in kdelibs4-dev
<Kamion> usr/include/kde/kdesu/ssh.h                                 libdevel/kdelibs4-dev
<sivang> abelli: kdelibs4-dev: usr/include/kde/kdesu/ssh.h
* ogra wonders how apt-get.org got in there
<sivang> Kamion: ;-)
<Kamion> but that's all
<abelli> ok so no Pure package avaible..
<abelli> thank you all
<Kamion> "Pure package"?
<Treenaks> Kamion: "libssh-dev"
<abelli> not regarding KDE...
<Kamion> Treenaks: huh?
<Treenaks> Kamion: that'd be a clean package with ssh.h in it.. libssh-dev
<Kamion> Treenaks: but there is no openssh -dev package at all
<Treenaks> Kamion: but I think that's what he's looking for?
<Kamion> AFAIK no SSH implementation exposes its internals like that
<Kamion> all ssh.h would give you, hypothetically, would be SSH protocol constants
<Kamion> if you're competent enough to do anything with those, you're also competent enough to write the header file yourself :)
<abelli> that's why i am asking it here: i'm not competent at all.
<Treenaks> abelli: may we quote you on that one?
<abelli> :) but i think that i'll just change the configure
<Kamion> abelli: perhaps it would help if you said what you're trying to do
<abelli> Kamion, yeah right, i'm sorry, i'm trying to compile paranoy, which is
<abelli> an email client with crypto mailboxes and config files..
<abelli> really nothing important, but before trying to package it i need to build it.
<abelli> Kamion, thank you
* sivang just added another bit to the preview release announce draft, but it probably needs rework a bit.
<koke> mako: is there a release-notes source .xml anywhere on the net?
<dholbach> www.gnome.org is back
<Kamion> sivang: needs rather more technical detail
<Kamion> I feel
<ogra> dholbach: yay
<dholbach> they only have some "banana republic" warning on their front page
<Kamion> many people would say we are not multimedia-ready, because we don't support MP3 or whatever out of the box
<Kamion> so maybe more backup for the buzzwords :-)
<sivang> Kamion: I thought of being breif and summing .
<Kamion> sivang: see the top of the page
<Kamion> MarkShuttleworth -- I think this preview announcement should be aimed at the technical audience and include a much longer list of technical enhancements since Hoary. Go into the bling and the plumbing.
<Kamion> abelli: ssh.h is a typo in configure, it's really looking for openssl/ssl.h
<sivang> Kamion: ok, I'll break those up to a list. :)
<Kamion> abelli: so install libssl-dev
<Kamion> sivang: and really I'd be inclined to leave out the multimedia bit
<abelli> Kamion, thank you
<abelli> ;)
<sivang> Kamion: sure, whatever you say , Sir :)
<Kamion> it's not an order, just a suggestion :-)
<fabbione> "Dear Kamion the allmighty, i have some issues with ...."
<fabbione> this how we should address Kamion ;)
<sivang> fabbione: hehe
<jdub> or "duderino" for short :-)
<sivang> fabbione: I tell him this in /msg , all the time :)
<fabbione> Kamion: kernel-wedge || true doesn't exist anymore..
<fabbione> Kamion: tested and verified
* ogra aded some moe technical stuff to https://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<Kamion> fabbione: hooray
<ogra> added even
<Hannes_> 1601.10 < abelli> ok so no Pure package avaible..
<Hannes_> sorry
<abelli> Hannes_, huh?
<ogra> Kamion, thanks :)
<pitti> sabdfl: would you mind if I add a small note about derooting to DraftHoaryPreviewAnnouncement?
<Kamion> damnit, after all that waiting I got distracted
<Kamion> probably-preview CD images building now
<Kamion> and live cloops
<jdub> gnome servers are up
<jdub> should be out soon
* jdub hammers with plastic play tools.
<sabdfl> pitti: i would *love* you to add a note about derooting
<pitti> sabdfl: I would *love* to do it :-)
<abelli> pitti, did you build the new -hardened?
<pitti> abelli: sorry, not yet
<pitti> abelli: I have to convert to 2.6.11 and review all Ubuntu patches for this
<abelli> pitti, YOU don't HAVE to be sorry
<pitti> abelli: so this is non-trivial
<abelli> pitti, right.
<tseng> abelli: when 2.6.11 is in, grsecurity should go on clean besides 2 patches
<tseng> spender merged the bits fron 2.6.11.1, ppc64 and input fixes
<tseng> im imagining ubuntu will merge them as well
<abelli> yeah what about the rootly hole they found?
<tseng> its fixed.
<abelli> no suicides? beautiful.
* Kamion does a kubuntu install test while he's waiting
<tseng> if pitti doesnt find the time I'll try it once 2.6.11 is in universe
<tseng> it should be much easier than .10, no fighting with the elf security fixes
<jordi> jdub: it's been great to hear you over the phone :P
<jordi> I'm leaving London now, ttyl
<sabdfl> pitti: tell me when i can edit the preview announcement again please
<jdub> jordi: ;-)
<pitti> sabdfl: just finished
<Kamion> heh, language pack installation is amusingly O(n^2) on the live CD cloop builds
<pitti> tseng: once our kernel team finishes 2.6.11 final, it's a piece of cake to build the -hardened kernels
<tseng> yeah it should be very easy
<Kamion> maybe locale-gen should grow an --only-new option or something
<pitti> tseng: the hard thing is to build a 2.6.11 kernel in the first place
<lamont> Kamion: heh
<lamont> livecd would love you
<tseng> pitti: thats why we have fabbione :)
<Treenaks> tseng: and his Crack Team of Kernel Commandos
<zul> tseng: and the rest of us is chopped liver? :)
<fabbione> 2.6.11 is very very low priority for hoary guys
<tseng> zul: yes.
<zul> tseng: oh ok
<sabdfl> elmo: "as well as most of the packages of apt-get.org"... are my pants on fire?
<jdub> jdubtv! -> http://node.waugh.id.au/
<tseng> :8800
<sivang> sabdfl: yeah, we wondered about it
* jdub is no longer grimacing, so turned it on
<sivang> sabdfl: :)
<jdub> tseng: ugh, thanks
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<sabdfl> well, i did ask for it to be made so
<sabdfl> elmo: ?
<pitti> tseng: what do you use for displaying the stream?
<tseng> pitti: totem
<tseng> just append the address to the command line
<tseng> or Open Location
<Kamion> firefox wants to use rhythmbox by default
<fabbione> jdub: omg.. i couldn't remember you were so.. hairy
<jdub> :-)
<sivang> jdub: hey jdub :)
<jdub> not like a penguin
<fabbione> i am gonna buy a webcam tomorrow
<carlos> jdub: do you have screenshots of the new Ubuntu look?
<fabbione> any good suggestion?
<theine> Are there any plans for updating the ipw2100 driver in the Ubuntu Kernel to the newest version (1.0.5)?
<tseng> not very good here jdub 
* pitti curses at his high-latency net link, which makes live video streaming impossible
<fabbione> theine: not for hoary
<zul> yeah not quickcam
<jdub> carlos: one sec
<theine> ok
<tseng> on the sync
<sivang> jdub: bah, I got the voice after you talk :)
<sivang> jdub: what's the other display for ? :) (I see you looking over it all the time)
<sabdfl> theine: what version do we currently have?
<theine> savdfl: 1.0.2
<jdub> sivang: big screen, close webcam
* sivang pats totem for being so fine :)
<sivang> s/pats/pets/
<pitti> sivang: isn't "pat" corrent?
<Treenaks> pitti: both are :)
<Kamion> either would work with somewhat different meanings, "pat" would be more usual I think
<sivang> pitti: hm, not sure :)
<jdub> pat is correct in uk/au
<jdub> pet is correct in USA
<pitti> isn't "correct" correct...
<sabdfl> fabbione: could you look into theine's version issue for ipw2100 please?
* sivang always wondered the why the differences between all those "dialects" of english.
<fabbione> sabdfl: sure
<maswan> jdub: Done at Wed Mar  9 15:30:15 MET 2005
<sabdfl> also ipw2200
<jdub> maswan: rocking :-)
<sabdfl> thom: are you near elmo?
<fabbione> theine: what problems do you have with 1.0.2?
<jdub> maswan: has luis pinged you about the livecd?
<maswan> jdub: I haven't heard anything. Currently, ftp.gnome.org will be happy to handle the load tohugh. :)
<jdub> maswan: http://torrent.linux.duke.edu/gnome-livecd-2.10.torrent
<theine> fabbione: not too severe ones actually, it's just that network-admin frequently hangs and the signal strength is not displayed correctly
<sivang> jdub: we want to see some quality programming! I'd vote for a lugradio show over your place :)
<maswan> jdub: ah, want an http source for that too on ftp.gnome.org?
<theine> fabbione: Of course I'm not quite sure if that's an driver issue or not
<jdub> maswan: if you think it can handle it
<sivang> jdub: *with* live video :)
<jdub> sivang: live gnome release not good enough for you? :)
<sivang> jdub: heheh, sure it does, the best :-)
<fabbione> theine: you can try building the 1.0.5 externally and see if it helps.. changing upstream version so close to release is quite dangerous because it might introduce more bugs than it fixes
<maswan> jdub: Will take a while to get it from the torrent though
<Treenaks> jdub: we want to have your terminal output scrolling as an overlay over jdub-tv!
<Treenaks> jdub: WHILE you release gnome
<theine> fabbione: I had some problems building 1.0.5 against the ubuntu kernel headers but I'll try again
<sivang> Treenaks: wow that would be COOOOOL
<maswan> jdub: current estimate is 2 hours.
<fabbione> theine: thanks
<Treenaks> sivang: exactly
<jdub> maswan: ok
<jdub> maswan: ping me when you have it, i'll add it to the mirror list
<maswan> jdub: thanks, I will
<maswan> jdub: Hm. got a bit more speed now, so it might get here sooner. we'll see. :)
<koke> jdub: do you need more mirrors??
<koke> downloading at http://pulsar.unizar.es/~koke/mirror/gnome-livecd-2.10/
<maswan> jdub: hmm.. will this be a one-off thing or will it be something more permanent that we could mirror?
<koke> jdub: forget that, not enough free space :(
<sivang> jdub: what was that? beer? :)
<jdub> carlos: http://people.ubuntu.com/~jdub/screenshots/ubuntu-hoary-preview.jpg
<thom> sabdfl: nowhere close
<jdub> maswan: possibly more permanent
<carlos> jdub: thanks
<jdub> maswan: but it will most likely be part of the ubuntu derivatives set later on
<sivang> jdub: nice tune, and cool artwork!
<kent> jdub, still defaults to the gnome icons for folders etc?
<Kamion> jdub: the inner one seems to be the old theme
<maswan> jdub: Ok, I'll just throw this into the temp/ folder then instead of creating a proper gnome-livecd folder etc.
<jdub> Kamion: hrm, nup
<jdub> kent: yes
<maswan> jdub: "temp" meaning that they do not have a proper updating mechanism etc
<jdub> yeah
<fabbione> b/wind goto 1
<fabbione> ops
<jdub> ah bum
<jdub> missed one file in ubuntu-artwork
<jdub> :)
<Kamion> ok, I have to go help out ill fiancee
<Kamion> jdub: no not say stuff like that
<fabbione> jdub: you kidding?
<Kamion> s/no/do/
<jdub> Kamion: not critical :-)
<Kamion> what did you forget?
<jdub> cursor theme definition
<jdub> can do update straight after preview though
<jdub> no biggie
<sivang> heheh
<Kamion> ok
<Kamion> install CD's building
<Kamion> please download and test when it's done
<Kamion> ETA 20 minutes or so
<fabbione> Kamion: roger
<HiddenWolf> jdub: is the old artwork still available? this looks rough
<jdub> switch to the industrial theme
<koke> HiddenWolf: http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-artwork/
<koke> HiddenWolf: three versions there
* HiddenWolf can't see the 'highlight' in the menu's when hovering with the mousecursor
* Kamion expects to be back about 1600 UTC
<sivang> jdub: yeah, what was it?
<jdub> madonna
<jdub> never mind
<jdub> (yeeesh)
<jdub> you can tell i'm concentrating or something
<HiddenWolf> jdub: I can't find the industrial theme in the selector
<mpt_londo1> HiddenWolf: That's not a bug, it's a feature!
<mpt_londo1> wah
* mpt_londo1 meant that to come after HiddenWolf's *previous* line
<HiddenWolf> Is this the final theme for ubuntu hoary?
<koke> well, have to eat smth. bye, and happy hacking :)
<sivang> jdub: eh, what a classic
<jbailey> I discovered last night when trying to fix my wife's machine to boot without Internet access that single user mode is pretty useless when root doesn't have a password. =)
<pitti> jbailey: init=/bin/bash helps a lot :-)
<jbailey> pitti: Yeah, I'm thinking from the perspective of possibly having to support people on these systems.  I was wondering if the script should be hacked to just drop to a rootshell without prompting for a password.
<jbailey> If you've got that kind of physical access to the machine all bets are off for security anyway.
<jdub> that's what it did for warty
<maswan> jdub: http://ftp.acc.umu.se/mirror/temp/gnome-livecd-2.10/
<thom> jbailey: it did for warty; has that been dropped?
* thom goes and looks
<jbailey> Her machine is running pretty-current Hoary, but it was an upgrade from Debian.  I'll check to make sure the changed init script isn't sitting as a .dpkg-new file.
<jdub> maswan: ta!
<thom> jbailey: it's not a changed init script; it's a fix to sulogin
<schweeb_> jbailey: I'm pretty sure that single user still asks for password in hoary
<pitti> jbailey: probably a good idea, yes
<schweeb_> I could check, if you like
<jbailey> thom: Ah?  Hmm, I see that in my script here.  I had always assumed it just fired up bash =)
<thom> jbailey: nup; does passwd checking then starts the shell
<lamont> jbailey: that's what init=/bin/sh is for
<jbailey> lamont: I'll make sure I refer the first support call where we don't have a password to the system and some 80 year old doing a first time linux install to you then. ;)
<thom> jbailey: works for me
<theine> fabbione: I have the same issues with ipw2100 1.0.5
<lamont> jbailey: heh/
<lamont> yeah, phone support with that kinda sucks
<fabbione> theine: such as?
<thom> jbailey: what is root's password in shadow set to?
<theine> fabbione: such as network-admin hanging and wrongly displayed signal strength
<thom> jbailey: ( i just rebooted to single user on a clean install and wasn't prompted for a password)
<fabbione> theine: so it doesn't solve the problem....
<jbailey> thom: I'm not near the machine atm, I have no net connection at home.  I think I may have set it to * though, judging by what I have on this laptop.
<theine> fabbione: no
<jbailey> (which is also an upgrade for me)
<fabbione> theine: ok. thanks for testing tho
<theine> fabbione: np
<thom> jbailey: * and ! both work fine, *LOCK* will cause problems
<jbailey> thom: Thanks.  now that I know that it's suppoed to work, I'll do some troubleshooting. =)
<fabbione> theine: i think we will stay with .2 for hoary. at least it is known to work as is
<Kamion> lamont: can you check if all the cloops are done?
<theine> fabbione: sure, that's probably a good idea
<lamont> Kamion: checking
<jbailey> Mithrandir: Did doko talk to you about an ia64->i486 cross compiler?  He tried to get the three of us together last night, but it didn't work out.
<fabbione> yup
<lamont> Kamion: no
<Mithrandir> jbailey: yes, and I'll just do it another way which is way less pain.
<Mithrandir> jbailey: I'm telling myself that ia32-libs is temporary and multiarch is the right solution, so.. :)
<lamont> Kamion: you didn't happen to try to fire them off in parallel (on the same machine) did you?
<Kamion> lamont: I did all four in parallel, yeah
<jbailey> Mithrandir: 'kay.  Is the goal to eventually build cross compilers for the various target arch's?  With multilibs it should be dead easy, and gcc already likes having the TRIPLE-program setup.
* Kamion -> pick up child from school
<Mithrandir> jbailey: no, you need more than just a compiler.  I think multiarch runtime is a good start -- most apps won't need multiarch build-time as well
<lamont> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/k/kdepim/ktnef_3.3.2-1ubuntu3_amd64.deb  Bad header line
<lamont> ew
<lamont> all 4 architectures in parallel is fine
<lamont> but BuildLiveCD kubuntu & BuildLiveCD ubuntu & will verifiy the locking code...  they build in the same chroot
<lamont> so one will wait/fail
<lamont> Kamion: I'll get both builds done on all 3 (that'll succeed) and let you know
<jbailey> Mithrandir: True.  Years of Hurd hacking have left me with a strong desire to make getting a packaged cross-compiler alot easier.
<jbailey> Mithrandir: The idea where you just install the libs and pass a parameter to debuild for gcc is kinda fun. =)
<ronalde> saving a translation in rosetta fails with "A system error occurred." any clues?
<maswan> jdub: oh, oops. http://ftp.gnome.org/mirror/temp/gnome-livecd-2.10/
<lamont> Kamion: i386 is in pass 2/2 in partimage, then will need to compress
<maswan> jdub: same hosts, but still, that's more on-topic. :)
<jdub> maswan: ;)
<sabdfl> maswan: what's that?
<HiddenWolf> jdub: is this artwork the final version for hoary?
<maswan> sabdfl: oh, it's the gnome livecd for the coming gnome release, perhaps we should be off in a more gnome-related channel for this. :)
<maswan> sabdfl: ftp.acc.umu.se, which I admin, is also known as ftp.gnome.org
<jdub> luis's ubuntu-based gnome branded livecd
<sabdfl> cool!
<jdub> HiddenWolf: not entirely
<HiddenWolf> jdub: i've got some usability issues with it, can I file bugs?
<Mithrandir> jbailey: sure, and it should work.  You need support in the whole toolchain for it to work, though
<sivang> btw, does anybody know if anything advanced in the direction of having d-i translatable through rosetta?
<pitti> yay, new daily CDs
<ronalde> saving a translation in rosetta fails with "A system error occurred." any clues?
<jdub> of course
<lamont> Kamion: _ubuntu_ cloops are done everywhere
<Simira> carlos: a lot of people are complaining on that error ronalde is talking about
* mvo downloads new daily
<pitti> Kamion: are the 20050309.1 CDs the final candidates?
<jbailey> Mithrandir: Yes, but a cross binutils is generally trivial to produce.
<lamont> Kamion: kubuntu: i386 compressing, amd64 installing kubuntu-desktop et al, ppc in debootstrap
* fabbione rsyncs
<Mithrandir> jbailey: you need dpkg-cross too and if you want to do funky stuff, pkg-config with cross support and so on.
<carlos> Simira: I know, and I have a patch already, mailing list and Rosetta's bts knows that already
<Simira> carlos: ok, I saw your answer on the thread, just seemed to still be a problem
<ronalde> carlos: is there an intermediate procedure to get translated stuff uploaded?
<sivang> carlos: any knowledge about when the installer will be translatable through rosetta?
<jbailey> Mithrandir: Yeah.  I've worked with dpkg-cross a bunch, and in practice most of things I want a cross compiler for are bootstrapping toolchains and the bare essentials on another arch.    I can see it being a godsend for embedded targets, though.
<Mithrandir> jbailey: absolutely.. would be nice for my WRT54GS, for instance.
<carlos> Simira: it's just that there is a delay since I prepare a patch and it's applied to the server, that's all
<jbailey> Mithrandir: Someone the other day was asking me for advice on porting Ubuntu to sh3 - He was running into problems building glibc in scratchbox.  Little things like that could be made so much easier.
<Mithrandir> jbailey: I'm also quite excited about the stuff we can do with linux support in the BSD kernels, for Debian.
<carlos> ronalde: not sure, it depends on pitti accepting translations directly to the language packs or sending it to the maintainer of the package you are translating, none of them easy to maintain later
<mako> sabdfl: changes to the announcement look great
<fabbione> Mar  9 15:27 hoary-install-i386.iso
<Mithrandir> (port everything which really wants BSD, multiarch the rest)
<fabbione> is this the last one?
<pitti> carlos, ronalde: if I get po files with translation domains, I can put them directly into the language packs
<carlos> sivang: no idea, when we finish the Rosetta changes we have been designed  recently, it should be soon, but I have said it too much times already...
<ronalde> pitti: i'll send you the Dutch translation of gksu
<carlos> pitti: but they are going to be lost when we start using Rosetta, unless you upload them later
<carlos> pitti: please, remember that
<pitti> carlos: is gksu already in Rosetta?
<ronalde> pitti, carlos: yes
<pitti> carlos: is there an easier way than the web interface to upload a po?
<ronalde> pitti, carlos: https://launchpad.ubuntu.com/rosetta/products/gksu/gksu-1.2.2/
<pitti> ronalde: please upload them there
<pitti> ronalde: I can download them from Rosetta
<carlos> pitti: current modules are not going to be reused for hoary, those are for upstream releases not Hoary ones
<ronalde> pitti: i can' t thats the problem ...
<carlos> pitti: we have a bug atm that prevents the use of Rosetta, it's pending to get the patch applied
<pitti> ronalde: please upload them later then
<pitti> ronalde: I cannot upload new packs today anyway
<pitti> ronalde: preview freeze
<ronalde> pitti: i see, i wished to get it included in hoary
<pitti> ronalde: no problem for the final
<carlos> ronalde: in theory, Rosetta will be on time to translate hoary
<ronalde> carlos: great!
<metallikop> Could someone please explain why pbuilder wants to use older versions of the -dev packages?
<tseng> metallikop: is your pbuilder up to date?
<metallikop> afaik
<tseng> it has its own apt cache
<metallikop> oh oh , that'd be my problem then, haven't had any issues with it thus far
<tseng> sudo pbuilder update
<tseng> and have another go :)
<metallikop> hehehe, that'll fix it, i'm sure.
<tseng> if you really need the newer depend.. you'll want to be sure to mark it as such in debian/control
<metallikop> thanks, all fixed now
<Kamion> lamont: oh, sorry if I confused you, I only actually care about Ubuntu right now
<fabbione> lamont: what's the status with LiveCD?
<Kamion> lamont: I just said BuildLiveCD, no 'ubuntu'
<lamont> Kamion: ubuntu is all done
<Kamion> yes, to those who asked, 20050309.1 is candidate
<lamont> Kamion: no args == 'ubuntu kubuntu'
<Kamion> ok, live CDs building
<Kamion> lamont: oh, oops, will adapt
<lamont> and kubuntu/ppc is generating locales
<lamont> and if you try enough, then you run the ppc and amd64 machine out of disk space, and I have to slap you
* fabbione starts installing on i386
* lamont prunes
<fabbione> hell! this cdrom doesn't read CD-RW
<lamont> fabbione: I hate it when I run into that...
* lamont has a few such machines. :-(
* toresbe has maany
<Kamion> my bug reporters have many :P
<Mithrandir> you all live in the stone age. :P
<fabbione> ok.. i can't find the other CD-RW.. i will test netinstall from cd :(
<mpt_london> fabbione: Is the error message nice and helpful?
<fabbione> that's all i can do atm
<fabbione> mpt_london: there is no error message.. when you boot from cd the bios says.. no bootable cd found
<fabbione> because i can hear that is not reading it properly
<mpt_london> Oh, and you can't file bugs against the bios
<mpt_london> dang :-)
<Kamion> live CD candidates up, 20050309.1
<zul> you can they will be ignored though :)
<tseng> mako: ping?
<mako> tseng: yes
<tseng> may I msg for just a moment?
* lamont dist-upgrades
* pitti installs 20050309.1 ppc
* fabbione kicks his CD box
<fabbione> there 2309209302932 CD and only 2 RW in there that i can use
<fabbione> of course i can't find them!
<zul> heh the irony
* pitti hands fabbione one of his 25 R/Ws
* fabbione hangs on a skyscraper ala godzilla and starts to yell
<fabbione> and the funny thing is that i have 590 DVD that i could use....
* thom jigdos
<jbailey> daniels: ping?
<thom> jbailey: asleep, i think
<jbailey> Yeah, probably, but you can never tell with him ;)
<thom> 14:03 < daniels> night dudes ;-)
<thom> 2 hours ago
<jbailey> Thanks.
<fabbione> ahh i might have found some other media.. 
* fabbione burns
<thom> jigdo is a work of art
<fabbione> thom: my problem is not to rsyunc the cd
<Mithrandir> for some value of art including "huge amounts of crack"?
<fabbione> is to find proper media
<thom> Mithrandir: possibly
<thom> but since i have a local mirror rsync seems like a huge waste of time
<jbailey> Mithrandir: Modern art.  The kind you find in government funded museums. =)
<fabbione> thom: i have both mirror of the pool and the cd images
<fabbione> thom: a daily sync takes no more than few minutes
<thom> fabbione: i used to, but it seems pointless
<Mithrandir> jbailey: guess so. :)
<fabbione> i am pretty sure less than jidgo
<Mithrandir> jigdo can use the old .iso
<fabbione> can it?
<Mithrandir> iirc, yes
<fabbione> there must have been a lot of water flowing under the bridges since last time i tested it
<thom> top
<Mithrandir> fabbione: been there for ages, iirc
<thom> uh, wrong keyboar
<thom> d
<fabbione> thom: time to install Xmdx ?
<fabbione> meh Xdmx
<thom> no, just time to stop reinstalling my desktop
<thom> oh well, it just took jigdo 8 minutes to build 3 cds, so i'm not sure nightly rsyncs would win much if anything over that
<fabbione>  /mirrors/ubuntu-cd/hoary-live-i386.iso
<fabbione> sent 162829 bytes  received 22426870 bytes  79401.40 bytes/sec
<fabbione> total size is 540127232  speedup is 23.91
<fabbione> of course it depends a lot of bw you have
<fabbione> i am ok with rsync
<fabbione> and offload my machine
<fabbione> i am not one of these lucky bastards
<fabbione> with amd64 and 64GB of ram
<Kamion> thom: hey, jigdo actually works still? cool. somebody complained it didn't.
<Kamion> I'd been meaning to test
<seb128> jdub: is there a public archive for the devel version of g-a-i ?
<jdub> in ross's arch repo
<fabbione> Kamion: grub-install fail
<seb128> jdub: k
<fabbione> Kamion: grub-install /dev/hda
<fabbione> bum 
<jdub> seb128: burtonini.com/arch
<seb128> thanks
<maswan> Mithrandir: Well, it _can_ use the old iso, but that involves non-obvious but somehwat documented trickery
<fabbione> nope.. it doesn't recover
<thom> it worked just peachily for last two dailies
<fabbione> oh this is WEIRD!
<fabbione> it's an IDE only machine.. partitioner saw the disk properly
<fabbione> now cat /proc/partitions
<fabbione> and it's all SCSI?
<fabbione> since when we can update IDE to SCSI via software?
<zul> sata?
<fabbione> that's a really cool feature
<fabbione> zul: not that i am aware of...
<fabbione> it still makes people think that they have IDE and at end it is seen as SCSI
<zul> thats weird
<thom> the new background is pretty sexy
<tseng> thom: the new gdm is pretty not
<lamont> Kamion: installing on a multi-disk machine the other day, it wanted me to type in where to put the boot record...  the cute part was it suggesting hda, when the machine is SCSI...
<thom> hrm, not sure i noticed or saw
<tseng> it just makes the ubuntu logo 2x bigger
<Kamion> lamont: grub-installer makes my head hurt, in general
<jdub> tseng: gdm is not? it's the same apart from the logo
<thom> yeah, the multidisk grub message is pretty darn awful :(
<tseng> jdub: "not sexy"
<Kamion> fabbione: we turned on LIBATA_ENABLE_ATAPI, or whatever it's called
<jdub> tseng: you don't like it?
<tseng> no =/
<jdub> man
<jdub> you're like
<fabbione> Kamion: ah
<jdub> the only person in the entire world
<tseng> i liked the nice subtle size
<Mithrandir> maswan: I thought it asked?
<fabbione> Kamion: that can mostlikely break....
<Kamion> fabbione: for #1440
<Kamion> fabbione: sabdfl override for #1440, we were running out of options
<tseng> jdub: ill get over it :P
<maswan> Mithrandir: Oh, it did? Well, I've never looked that hard, since I've always had a package mirror close enough.
<thom> yeah, it asks for an oldiso
<Mithrandir> maswan: how strange. ;)
<ogra> tseng: didnt you know ? it woll grow with each 1mio new users ;-P
<ogra> will even
<tseng> ah
<tseng> 10000000 served
* lamont must run sick kid to town for a bit.  sigh.
<lamont> Kamion: heh
* thom likes his "Apache: trillions and trillions served" tshirt
<fabbione> Kamion: ok....
<thom> woah!
<fabbione> anyway netistall wasn't too happy
<thom> that is one big ubuntu logo
* thom keanus
<fabbione> Kamion: i got aptitude at base-config
<fabbione> and running manually the aptitude install ubuntu-desktop was ok
<fabbione> i will have to check again
<thom> jdub: two people in the entire world, now
<jdub> thom: hrm
<jdub> thom: too big?
<seb128> jdub: are we going to have a new g-i-a in the archive soon ? Just wondering for the translations mail I'm writting. 
<thom> yep
<jdub> thom: can you sshot?
<seb128> jdub: the translations should be sent to ross ?
<jdub> seb128: unlikely
<thom> sure
<jdub> seb128: no, we should do them
<seb128> grumpf
<thom> when this install run finishes
<jdub> seb128: ross is away for two weeks
<seb128> oh
<seb128> and we are not updating to a translated g-i-a soon ?
<jdub> seb128: just focusing on gnome release atm
<mvo> jdub, seb128 : I already branched a archive, I can deal with it 
<seb128> jdub: right, sorry
<seb128> mvo: I put your mail for update-manager/update-notifier/gnome-app-install translations ?
<mvo> seb128: yes
<seb128> thanks
<Kamion> fabbione: base-config does 'aptitude install ~tubuntu-desktop', not just ubuntu-desktop
<mvo> jdub: I removed the "services" menu from my gnome-app-install branch (#7311). IIRC you said you don't want to use it for -final?
<Kamion> fabbione: the Task headers in the archive are probably out of date; bug elmo to update them
<jdub> mvo: later please :)
<mvo> jdub: we can talk later about it, I guess you are busy, sorry
<mvo> sure :)
<Kamion> fabbione: so what should it have been, instead of /dev/hda?
<fabbione> Kamion: i had to put /dev/sda but now i have a doubt that i will need to check again later
<fabbione> i am not 100% sure it was hda in partitioner 
<fabbione> or sda
<Kamion> ok
<fabbione> i just read the partition numbers without too much care
<fabbione> if the 2 matches is ok
<fabbione> but if they don't than it's an issue for the user
<fabbione> YES this media can boot
<fabbione> Kamion: testing cd install now
* Kamion is back home and busy burning
<thom> looks good from here so far
<Kamion> that ide/scsi thing is kinda bad, not sure it should delay preview since we have no clue what it is, but we need to look at it for final
<Kamion> I have no scsi systems though
<fabbione> Kamion: this is IDE
<Kamion> or any that think they're scsi :) only an SATA system that works fine
<fabbione> the cdrom fails here
<fabbione> it fails loading the installer components
<Kamion> has it successfully mounted /cdrom?
<fabbione> Kamion: can you give me the md5sum for the install iso?
<fabbione> Kamion: checking
<fabbione> Kamion: yes it is mounted
<Kamion> fabbione: there's an MD5SUMS file next to the ISOs ...
<Kamion> 90fae3a5bc65db83d8fa8fe4aa8c0d8a  hoary-install-i386.iso
<thom> this is a mixed pata/sata system and it's great
<fabbione> 90fae3a5bc65db83d8fa8fe4aa8c0d8a  hoary-install-i386.iso
<fabbione> looks ok
* fabbione sighs and check the burned iso
* Kamion swings test rigs into action
<fabbione> weird.. this is all weird
<fabbione> at the second read is ok
<pitti> mdz, Kamion: 20050309.1 ppc/install on iBook G4 works fine
* pitti looks at the cool new background
* Mithrandir looks, then switches back to monthly pr0n.
<thom> amd64 is locale-gen-of-justice'ing
<Mithrandir> (:
<thom> Kamion: amd64 looks good for me
* HiddenWolf thinks the new gtk theme is quite unreadable
<fabbione> Kamion: forget about the IDE/SCSI thingy
<fabbione> it is ok
<Kamion> fabbione: what went wrong the first time?
<fabbione> me reading partitioner
<fabbione> the hda/sda is on top
<zul> hah!
<fabbione> and i didn't even check it since there is only one disk
<fabbione> and i looked only at the partition numbers
<fabbione> but i knew that it was hda from the last installs i did
<Kamion> but did grub-installer not do the right thing by default?
<fabbione> (it's the multiarse setup i am testing on)
<fabbione> Kamion: grub did prompt to know to which partition or disk i wanted him to install the MBR
<Kamion> oh, and you typed in the wrong thing by hand?
<fabbione> yes.. since i knew it was hda
<Kamion> heh, ok
<Kamion> right, that's a relief
<fabbione> yes
<fabbione> definetely
<jdub> gnome's shipped
<sivang> jdub: yay!
<fabbione> i am installing again via net
<fabbione> to see the second stage problem with ubuntu-desktop
* thom becomes angry with cdrecord
<Kamion> elmo: you around? could you regenerate hoary's Task headers?
<fabbione> that would be helpful
<fabbione> i can put the install in sleep for a little while :-)
<fabbione> while i test the live CD
<fabbione> the first install cd doesn't go 
<fabbione> it must be a media problem
<ogra> yeah, Celebrating the release of GNOME 2.10!
<sivang> ogra: wheeee
<fabbione> Kamion: i am sorry but i get the same error from the installer on the LiveCD
* thom boots ppc box and tests that
<fabbione> i doubt it is only a cd burning issue
<fabbione> "Unable to load installer components"
<fabbione> and i am not doing anything weird.. just booting
<pitti> mdz, Kamion: 20050309.1 ppc/live on iBook G4 works great, too
<fabbione> and also on this machine (NON-SATA) my disk is now scsi
<pitti> now I really have to run
<pitti> cu tomorrow
<fabbione> weird enough.. they are all intel chipsets
<pitti> jdub: congrats for 2.10 :-)
<jdub> pitti: :)
<thom> yaaargh
<thom> auto key guesser doesn't get a UK powerpc usb keyboard at all correct
<thom> it ended up asking me for a set of keys none of which i had
<Kamion> fabbione: please look through syslog and try to figure out why it's doing that
<fabbione> Kamion: i am working on it. don't worry :-)
<fabbione> ah i found one machine where it works
<fabbione> the other 2 have the same problem
<Kamion> both install-i386 and install-amd64 are going well for me so far
<fabbione> Kamion: ok.. 2 things.. machine 1 & 2: boot from net -> ok. boot from cd -> nok. machine 3 is ok.
<fabbione> it's not really a GO for me
<fabbione> also because this is pretty common hardware
<Kamion> i386 on Averatec test laptop, amd64 on SATA disk / IDE CD
<Kamion> fabbione: dude I can't do anything until you give me log details :)
<fabbione> Kamion: yes.. i am working on it :-)
<Kamion> we're also well past sabdfl's deadline for starting the final build for preview
<fabbione> well.. it's a preview
<Kamion> so we may just have to diagnose issues as best we can and do Array 7 ASAP
<fabbione> right
<thom> ppc is installing core packages
<thom> amd64 and x86 (same box) are go from here
<fabbione> thom: do you have i386 to test?
<fabbione> a plain i386?
<thom> fabbione: amd64 in x86 mode
<thom> no difference
<Kamion> i386 unpacking desktop, amd64 downloading language-support-de deps
<thom> i can do a netboot on my laptop now i guess
<fablive> live seems ok
<fablive> let's go back in debugging
* mvo tests livecd now, brb
<fabbione> Kamion: i found 3 possible reasons of failure
<fabbione> Kamion: just a sec that i need to copy and paste manually
<fabbione> DEBUG: unable to find (libc6) ignored
<fabbione> main-menu: sed: Unsupported command T
<fabbione> main-menu: cat /proc/ide/*/media : No such file or dir
<fabbione> (possibly due to the change to scsi)
<Kamion> jdub: hm, no rounded window corners in Human?
<fabbione> anna[<pid>] ; WARNING **: parser_rfc822: lek! Don't find end of field, it seems to be after the end of line!
<Kamion> fabbione: the sed T thing should be harmless; need to implement that in busybox, will probably do it pre-final
<jdub> Kamion: mark wanted the old wm theme, not the clearlooks one
<fabbione> anna[<pid>] ; ERROR: can't find packages file
<Kamion> fabbione: hm, ok, does /cdrom/dists/hoary/main/debian-installer/binary-i386/Packages* look sane?
<jdub> Kamion: i expect that a bug will be opened about that, lots of people *love* the clearlooks wm theme
<fabbione> main-menu: Configuring 'load-cdrom' failed without error code 1
<Kamion> jdub: the wm thing seemed to be the biggest change in clearlooks; don't really get the point of switching otherwise :-)
* jdub is jigdoing
<jdub> Kamion: all the lovely widgets!
<fabbione> Kamion: no. it's corrupted
<fabbione> approx at 53%
<fabbione> Packages: input-modules-blabla
<fabbione> in the description
<fabbione> and later too
<fabbione> around 60%
<lamont_r> how goes the RC?
<Kamion> fabbione: that would be it then ...
<fabbione> Kamion: does it look corrupted on your machine too?
<fabbione> because the md5sum matches with the iso's
<fabbione> and both Live and install?
<Kamion> the /proc/ide/*/media thing is from a udev script, either ide-devfs.sh or scsi-devfs.sh
<Kamion> fabbione: it's fine on mine or it wouldn't have installed successfully
<fabbione> zcat Packages.gz | more
<fabbione> zcat: inflate error
<fabbione> 1
<Kamion> looks fine here
<Kamion> live-i386
<Kamion> md5sum 24323b5da4533d415d1821cb7a3ded24
<fabbione> checking with a 3rd reader
<Kamion> (of the Packages.gz file)
<fabbione> yes the md5sums of the iso's are ok
<mvo|live> live-cd looks fine here (boots, comes up with correct keyboard, X, sound, network). anything particular you want me to test?
<trukulo> fabbione, 2.6.11.2 out (if you don't know)
<Kamion> fabbione: check md5sum /cdrom/dists/hoary/main/debian-installer/binary-i386/Packages.gz
<fabbione> Kamion: yes. doing that now
<fabbione> 24323b5da4533d415d1821cb7a3ded24  Packages.gz
<fabbione> looks ok!
<jdub> OK: Checksums match, image is good!
<Kamion> what was the gdm change people were complaining about?
<fabbione> this is so weird....
<Kamion> it looks about the same to me
<thom> Kamion: the UBUNTU logo is ginormous
<lamont_r> Kamion: does the preview get a weekly-dvd?
<Kamion> lamont_r: no
<fabbione> i suspect some memory corruption due to the last changes
<lamont_r> partypooper
<fabbione> since on the machine where the file is ok
<fabbione> the cdrom is recognized as IDE
<fabbione> and not as SCSI
<fabbione> elmo: sorry dude, did you update the task list?
<Kamion> fabbione: live-i386 boots fine here, sorry I can't help more
<fabbione> Kamion: don't worry...
<fabbione> that's the only thing i can think of
<fabbione> and it would definetely matches the only changes that have been done to the kernel
<fabbione> and that scares the hell out of me
<Kamion> fabbione: yeah, could be libata screwage
<Kamion> fabbione: IIRC zul mentioned libata had had some more work done to it in 2.6.11
<ogra> lamont_r, is that the semi official name for the preview ? (perky partypooper ?)
<Kamion> lamont_r: mdz's decision :)
<lamont_r> Kamion: OK, then.  mdz is a party pooper.  I'll quote you on that. :-))
<lamont_r> just lack of testing time?
<fabbione> does busybox implements md5sum?
<lamont_r> fabbione: trying to decide which answer would confuse me more...
<Kamion> fabbione: yes
<Kamion> thom: seems ok here
<fabbione> lamont_r ?
<lamont_r> fabbione: on busybox/md5sum
<fabbione> ok
<fabbione> libata is screwed
<fabbione> confirmed
<lamont_r> neat
<fabbione> md5sum of Packages.gz via busybox is totally different
<Kamion> yay :-/
<Kamion> so I guess that's an errata item
<fabbione> unless somebody wants a fix on the fly
<fabbione> no correction
<fabbione> unless somebody wants to find and produce a fix on the fly
<zul> but it works on some and not on others?
<sivang> have we released yet? 
<Kamion> sivang: no
<lamont_r> fabbione: the "only change" was defining two config vars
<fabbione> i am afraid that the others didn't even see the problem
<Kamion> sivang: I told you we were aiming for 1900 UTC, it is now 1742
<Kamion> speaking of kernel stuff, can we please please please revert that powerpc LEDs thing post-preview?
<sivang> Kamion: right sorry.
<Kamion> s/LEDs/LED/
<jdub> Kamion: ugh, yeah
<jdub> Kamion: already getting complaints about it
<Kamion> or make it switchable default off, but preferably just nuke it for hoary
<sivang> when can we agree on the preview release announcment being final? I want to start transalte it :)
* lamont_r has no objection
<thom> ppc up to ttf-malayalam-fonts
<lamont_r> wrt LED
<sivang> (althought it can probably be left to about 30 minutes before release)
<fabbione> lamont_r: i am checking what these 2 vars do
<fabbione> it can be a driver <-> scsi remapping thing
<fabbione> not necessarely a bug in libata
<Nafallo> fabbione: got time for a question about 2.6?
<fabbione> no
<Nafallo> dang
<fabbione> Nafallo: sorry but i am very busy atm
<lamont_r> about 5 min, and I must go fetch kid.
<Nafallo> fabbione: that's okey :-).
<lamont_r> Kamion: the fact that she's sick seemed (to her) insufficient reason to miss the nationa latin exam...
<Kei> hey google www.otomotivshow.com 
<jdub> hrm, my cd burners are all unhappy today
<thom> PPC is a GO!
<Kamion> lamont_r: heh
<thom> lamont_r: new install:
<thom> Mar  9 17:53:37 localhost postfix/local[9097] : fatal: open database /etc/aliases.db: No such file or directory
<thom> Mar  9 17:53:38 localhost postfix/master[7122] : warning: process /usr/lib/postfix/local pid 9097 exit status 1
<thom> Mar  9 17:53:38 localhost postfix/master[7122] : warning: /usr/lib/postfix/local: bad command startup -- throttling
<lamont_r> thom: see 6232, iirc
<lamont_r> fixed in -9ubuntu2, scheduled to upload tonight, after the preview ships
<fabbione> who has a piix chipset handy? meaning that you can try stuff on it?
<lamont_r> thom: very interesting interactions between base-installer (et.al.) and postfix's postinst
<lamont_r>   * On initial install, make sure that /etc/aliases.db gets created.
<lamont_r>     Closes: Ubuntu#2683, Ubuntu#6232 (debian #293889)
<mdz> good morning
<thom> hey matt
<jdub> morning
<mdz> what's on the menu?
<fabbione> Kamion: we might have a fix...
<Kamion> looking pretty good so far, apart from a libata regression reported by fabbione
<fabbione> it's only on piix chipset
<Kamion> ok
<fabbione> we are isolating and taking a decision on what to do
<mdz> oh good, new kernel, we hadn't changed that one yet :-P
<Kamion> haha
<Kamion> I doubt we'll try to fix it for preview
<Kamion> mdz: everything else is in, built, tested though
<lamont_r> back in about 45 minutes
<fabbione> Kamion: we actually can
<fabbione> it's a 2 line revert a patch for sabdfl 1440 override
<fabbione> or we can sabdfl what he prefer :-)
<Kamion> that breaks other systems
<fabbione> silent data corruption..
<mpt_london> here comes the sab
<Kamion> fabbione: we could, but any rebuild now takes us way past the deadline
<sabdfl> hi all
<fabbione> Kamion, mdz: your call
<sabdfl> where are we?
<mdz> fabbione: you can reproduce the bug?
<fabbione> mdz: yes, on 2 boxes
<fabbione> i found it
<T-Bone> hey sabdfl
<mdz> that patch fixed unable-to-install problems for a lot of users
<sabdfl> mdz, Kamion, fabbione: what's the status please
<mdz> sabdfl: I just got here, catching up myself
<fabbione> mdz: the other introduces silent data corruption and mostlike another bunch of "i am unable to install" users
<mdz> sabdfl: fabbione has found a kernel problem
<sabdfl> ok. AIUI the kernel we are about to ship still has 1440?
<mdz> sabdfl: no, it has 1440 fixed
<Kamion> a kernel rebuild now pushes us way into tomorrow UTC, and simply exchanges bugs for bugs
<T-Bone> mdz: as i said on #u-kernel: i think it's not a good thing to introduce yet another untested "fix". Reverting to the previous situation were some users couldn't install but others were safe seems preferable, for 'preview' timeframe
<mdz> sabdfl: and fabbione says that the fix introduced a bug
<fabbione> sabdfl: no. it has the fix for 1440 that introduces another bug
<fabbione> sabdfl: like I/O corruption. for what i can see only on CDROM
<T-Bone> mdz: after preview we'll have more time to find a better solution
<fabbione> sabdfl: but it means another set of people won't be able to install
<fabbione> not even to see the LiveCD
<Kamion> my feeling is that it is too late to revert for preview
<mdz> how are you guys certain that this is caused by that patch?
<fabbione> mdz: 99,9%
<mdz> how, not how much
<fabbione> because both these machines have piix controllers
<fabbione> and the change to ATA_ENABLE_PATA
<sabdfl> fabbione: do you have a fix for the new problem? has this been discussed and solved upstream or elsewhere?
<fabbione> adds 4 pci ids to the list of ata_piix.c
<fabbione> that matches the 2 machines i have
<fabbione> as a result my ide disks are recognized as scsi
<Kamion> would using some other module instead work around the problem?
<fabbione> booting from the normal kernel (as IDE)
<fabbione> everything works fine
<mdz> this patch has been in our kernel for over a month
<Kamion> as in, could we monkey-patch modules.pcimap or something? :-)
<fabbione> sabdfl: i discovered it 1 hour ago Mark.. working with the others..
<Kamion> right now anything is preferable to a kernel rebuild
<T-Bone> mdz: the libpata enable? No. 2 weeks at max
<mdz>   * Enable ATAPI support in libata [Chuck Short <zulcss@gmail.com>] 
<mdz>     Patch: enable_atapi_ata.dpatch
<mdz>     Closes: #1440
<mdz>  -- Thibaut VARENE <varenet@debian.org>  Tue, 01 Feb 2005 19:56:33 +0100
<fabbione> mdz: no it's very recent..
<mdz> T-Bone: is that not when you uploaded that kernel?
<fabbione> it was introduced while i was away
<T-Bone> hmmm
<fabbione> that means between the 17th of Feb and no
<fabbione> now
<jbailey> T-Bone: The changelog entry says 1 Feb, which has got to be way wrong.
<T-Bone> definitely
<fabbione> sabdfl: a possible fix would be to revert the change for preview and reopen 1440
<mdz> hmm, yes, the changelog is not right
<T-Bone> mdz: if it's -25, it's one or two weeks old
<mdz> it was built on 2005-03-02
<mdz> T-Bone: why is the date wrong in the changelog?
<fabbione> so a week ago
<T-Bone> mdz: no clue
<mdz> sabdfl: reverting the patch means missing our date
<Kamion> mdz: bad clock on build machine probably
<T-Bone> mdz: in any case, if taking action on the kernel means missing our date. we're in hell
<sabdfl> this is a bug that has bitten us again and again
<fabbione> mdz: that's for sure.. it will need another round of testing everywhere
<sabdfl> i've personally encountered it when demonstrating warty to potential hardware oem partners
<Kamion> fabbione: forget that, even just the build time practically takes us into tomorrow
<mdz> I think we should go out with the kernel we have
<sabdfl> any high end new machine has all-SATA drives, and pata cdroms, right?
<fabbione> Kamion: exactly...
<T-Bone> mdz: the shortest path solution to that problem is reverting the patch. It needs 2 lines, and a set of builds
<mdz> and tackle this bug after preview
<T-Bone> mdz: that way we're back to known state
<Kamion> T-Bone: that's not a shortest path
<T-Bone> and not tempting anything dangerous
<Kamion> T-Bone: it is minimum 6 hours
<fabbione> mdz: i am afraid of one thing only...
<mdz> T-Bone: I'm not convinced that the old state is better, and as I said, that's going to make us miss our release date
<T-Bone> Kamion: i don't see anything shorter
<fabbione> mdz: right now i saw cdrom I/O corruption
<Kamion> T-Bone: listing it as an errata item
<sabdfl> mdz: so the current kernel does not have 1440, but has a new bug that affects an unknown number of machines?
<fabbione> mdz: allow me to run some tests on the disks
<mdz> sabdfl: correct
<fabbione> mdz: just be sure we are not going to trash anything else
<T-Bone> Kamion: hell of an errata :(
<mdz> fabbione: by all means
<sabdfl> do we know which has the fewer number of affected machines? does it only affect a subset of the machines that 1440 affects, for example?
<fabbione> i had say approx 40 minutes of bonnie or md5 to stuff
<mdz> sabdfl: we have no reasonable data for that; there isn't time
<fabbione> sabdfl: everybody that has a piix controller with the following pc ids:
<Kamion> sabdfl: so far piix is the only chipset from which we've had a reported problem
<Kamion> to my knowledge, anyway
<mdz> sabdfl: it affects an entirely different set of machines
<sabdfl> it's very common
<fabbione> #ifdef ATA_ENABLE_PATA
<fabbione>         { 0x8086, 0x7111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, piix4_pata },
<fabbione>         { 0x8086, 0x24db, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<fabbione>         { 0x8086, 0x25a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<fabbione> #endif
<Kamion> might be worth trawling the mailing lists for reports since array 6
<fabbione> so anybody using cdrom from that chipset = BUUM
<mdz> I really don't feel that we have a choice
<Kamion> if it's only cdrom, it will not lose people's data
* fabbione goes and starts some disks i/o tests
<jbailey> fabbione: But only if they happen to get the ata_piix driver loaded instead of piix, right?
<mdz> nobody spotted this in the past week, that we know of, and we are _out of time_
<fabbione> Kamion: i really want to be sure
<T-Bone> fabbione: it's worse than that. It's not 'buum', it's silent corruption. Very hard to figure out for the average user
<fabbione> T-Bone: right.. 
<mdz> Kamion: is the current set of CDs our best candidate, apart from this bug?
<mako> erghh..
<mdz> Kamion: it has all the grumble last-minute artwork changes?
<Kamion> mdz: right
<sabdfl> mdz: and we don't have a known-good fix, so delaying doesn't really help, we either get 1440 back or this new thing back
<T-Bone> sabdfl: correct
<sabdfl> mdz: let's release
<mdz> I'd sort of like to test the release first
<fabbione> sabdfl: please allow me to run some disk I/O tests first
<fabbione> sabdfl: we must be 100% that the bug affects only cdrom
* mako nods
<mdz> fabbione: please do
<fabbione> we don't want to destroy people data for a mistake
<sabdfl> ok. how about defer decision for a specific time, say 3 hours, to do tests
<Kamion> I suppose Message-Id: <20050304045649.64C6887@orb.sasl.smtp.pobox.com> is similar
<mdz> I'm going to do around of install+live testing
<mdz> I need <1 hour
<fabbione> sabdfl: i am already running the tests.. i had say one hour?
<sabdfl> in the meanwhile, mirrors are running, and we can ask people to help us test
<sabdfl> can we get -devel to help out?
<sabdfl> "here is the candidate, we have a potential erratum on cdrom corruption, please test and send feedback to this email address before 21h00 UTC"
<tseng> -devel responses pan out over days
<T-Bone> true
<T-Bone> the best channel is here
<T-Bone> it has the lowest latency of all
<thom> might be worth asking in #ubuntu if anyone has piix mobos
<T-Bone> right
<thom> or controllers
* Kamion sends a few mails to ubuntu-users
<sabdfl> Kamion: is there an iso we can point people at immediately?
<mdz> fabbione: is DMA  enabled on your CD-ROM in d-i by any chance?
<mdz> sabdfl: yeah, the stuff in the topic
<T-Bone> we should warn in big letters of the potential dangers
<Kamion> we've actually had several reports of new problems on array 6, but none of them mentioned the chipset
<Nafallo> only s-ata computers, right?
<sivang> oops, wasn't here for sometime, what is the bug needs testing?
<Kamion> I'm trying to find each of them and follow up now
<sivang> (and could it possibly corrput)
<mvo> thom: I have a test-system with PIIX4 ...
<Kamion> there's a report of a problem on an old 233mhz laptop; would something of that vintage have piix?
<T-Bone> Kamion: yes
<mdz> seb128: I just had my panel crash again, when gaim failed to connect to jabber
<mdz> I was a moron though and didn't get a backtrace
<jbailey> Kamion: My p3 900mhz laptop has piix, so it might.
<sabdfl> piix has been around forever
<mdz> I clicked through it because I was in the middle of something
<mdz> jbailey: can you test?
<T-Bone> right
<Kamion> I found three reports
<Kamion> but I can't say for sure that they're the same bug
<jbailey> mdz: Yes, but I'm trying to get an answer to my driver question.  I've asked twice with no answer. =)
<thom> mvo: can you test current preview on that machine and see if you have problems/
<mvo> I think I see this problem here. my cdrom/disks are detected as scsi and installation fails with "can't get stuff from cd"
<Kamion> sabdfl: do we have mirrors running?
<fabbione> mdz: i didn't check. i can do it now
<mvo> (this is a p2/400, pretty old machine)
<sabdfl> Kamion: i believe so... is the image on releases.ubuntu.com?
<Kamion> sabdfl: no, because it is not released
<Kamion> I need a go-ahead for that
<seb128> mdz: weird. I'm trying to play with gaim/jabber
<Kamion> I also want to test on powerpc first; about to do so
<sabdfl> ok, i thought we might be putting it somewhere as a .file which we could then just symlink to
<sabdfl> making the final mirror trivially fast
<sabdfl> can we do that for the final release?
* fabbione really needs 5 minutes of break
<fabbione> brb
<Kamion> yes, I can do that now too, er probably
<Kamion> test cycles tend to leave me in a slightly awkward situation machine-wise :-)
<mdz> seb128: jabber is flaky today, so hopefully it will happen again
<Kamion> and I don't actually have any script support for that yet so I'll do it by hand
<mvo> ok, I have a system that is affected. how can I help now ?
<trukulo> gaim works well here
<sivang> here also
<trukulo> with last hoary package
<Nafallo> what do I need to test, an up2date hoary kernel?
<mdz> er
<mdz> the amd64 live CD still has the old artwork?
<martink> seb128, poppler 0.1.2 announce mail: "... plus the cairo version we check for now actually works with poppler" ;-)
<seb128> martink: nice
<mdz> mvo: :-(
<mdz> mvo: I thought you tested the live CD earlier today
<mvo> mdz: yes :( anything I can do now? any workarounds I could try? 
<mdz> mvo: we haven't changed anything since then
<mdz> in the kernel
<mdz> mvo: or are you talking about the jabber problem?
<mvo> mdz: yes :( I thought my cdrom in my old test-machine
<mvo> mdz: on my "real" system live-cd works fine
<mdz> mvo: so you are testing in a different machine than earlier?
<mvo> mdz: I now tested on a older machine (p2/400) 
<mvo> mdz: on my desktop (k7) everything is fine
<mdz> mvo: what does hdparm on the cdrom say?
<mdz> mvo: on the machine which experiences the bug?
<mdz> ARGH
<mdz> langpack upgrades are broken
<mdz> and pitti is gone
<mvo> mdz: IO_support = 0, readonly=0, readahead=256, HDIO_GETGEO failed
<trukulo> mdz, i've got problems with langpack, removing it and installing again solved the problem
<mdz> trukulo: yes, it's buggy
<seb128> mdz: what is broken with langpack ?
<mvo> mdz: I'm really angry about myself because I did test the cd earlier today in this old machine but I suspected a broken cdrom :(
<trukulo> mdz, i know, it's a file included in langpack and langpack-base collisioning
<Kamion> mdz: amd64 live CD is up-to-date here; I'm running it now
<trukulo> but if i remove them, and install again, it works
<fabbione> mdz: no DMA enabled
<mdz> gah, I missed an rsync step
<fabbione> mdz: and i can't turn it on with libata
<fabbione> it complains that it is an invalid IOCTL
<Kamion> sabdfl: I'm putting them in .pool now
<Kamion> I'll have to do some grotty removing to stop them showing up in cdimage.ubuntu.com/releases/ though
<Kamion> but that's ok
<sabdfl> Kamion: if they had .filenames, would they show up in HTTP and FTP LS?
<Kamion> sabdfl: no
<Kamion> sabdfl: really I'd rather just remove them from cdimage, it's too complicated otherwise
<Kamion> they can still go on releases.ubuntu.com/.pool/ which is what you wanted
<sabdfl> ok
<sabdfl> releases.ubuntu.com should get lots more mirroring long term
<sabdfl> so my thought was to stick them in .pool there as we get close to release
<sabdfl> then on the last day it's just a question of creating the symlink to that
<Kamion> yes, that's what I'm going to do now
<sabdfl> then, when we release final, we remve preview
<fabbione> Kamion: is there anyway to ban a module from being loaded ?
<sabdfl> ok
<fabbione> like an anna option or something?
<Treenaks> bug on releases.ubuntu.com: clicking the "warty" link links to a page with the title: Ubuntu 5.04 (Hoary Hedgehog)"
<sabdfl> and we can still point people at the url with the .pool filename for testing just before the release
<Kamion> fabbione: er I can't check right now, could you check the anna source please?
<mdz> fabbione: you think we can use ide-generic instead or something?
<fabbione> mdz: i am checking if removing the modules from /lib/<kernel>/ helps
<fabbione> Kamion: not atm...
<Kamion> sabdfl: that doesn't work so well, hoary/hoary-preview-*.iso is a *symlink* to .pool/whatever
<Kamion> sabdfl: so we have to rely on mirrors mirroring hard links properly, and I have no idea if they do so at the moment
<Kamion> fabbione: generally I rm the thing
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current | broken: PIIX support, langpacks/ | review preview ann.: http://www.ubuntulinux.org/wik
* ..[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/DraftHoaryPreviewAnnouncement
<Kamion> fabbione: the wonderful world of hotplug hardware detection means that the installer has very little opportunity to intervene otherwise :-P
<mdz> gah
<tseng> =/
<Kamion> sabdfl: let's talk about this outside a release panic
<Kamion> Treenaks: will fix in a sec
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current | broken: PIIX support, langpacks/ | review preview ann.: http://www.ubuntulinux.org/wik
<sabdfl> Kamion: i did mean symlink
<sabdfl> and said symlink too
<Kamion> sabdfl: yeah, but if you have hoary/hoary-preview-*.iso symlink -> .pool/hoary-*.iso then you can't update .pool/hoary-*.iso or the preview ISO that people see will change
<fabbione> Kamion: checking that too :(
<sabdfl> Kamion: i figured to have a spare, unlinked iso in .pool
<Kamion> sabdfl: like I say let's talk about this outside a release panic, when I have a chance to think about it :-)
<sabdfl> Kamion: ok
<mdz> can we hold off on changing the mirror layout and focus on the showstopper bugs in the preview release?
<Kamion> fabbione: there might be /etc/hotplug/blacklist too, but that's not per-pci-id
<fabbione> brb.. dinner is ready
<mdz> lamont: ping
<mdz> mvo: can you try fabbione's test?
<mdz> mvo: see if suppressing the loading of the module works around the problem?
<mdz> mvo: and do you have Martin Pitt's telephone number?
<mdz> (or anyone else)
<mvo> mdz: I will try to supress the module loading
<Kamion> isn't it on the canonical wiki?
<mdz> Kamion: no
<mdz> ah, it is on the business card list though
<mvo> mdz: should I call him?
<mdz> mvo: yes, please get him online ASAP
<lamont> mdz: ack
<mvo> mdz: calling
<mdz> lamont: do you have a PC with a PIIX chipset?
<Kamion> sabdfl: syncing .pool out to syncproxy,auckland,mirnyy now
<lamont> mdz: what's the best way to tell?
<mdz> lamont: lspci
<ogra> lamont: or look if the module is loaded
<mdz> right
<lamont> 00:04.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
<lamont> like that?
<ogra> yup
<jbailey> lamont: The module on my laptop appears as piix, on my sata box as ata-piix
<lamont> ogra: that particular machine happens to be the mail server
<mvo> mdz: not reached on mobile and normal phone, will try again in 10 minutes
<ogra> lamont, ouch
* lamont watches the other likely-candidate finish booting
<schweeb> mdz: something wrong with piix?  I have one too if you need something tested
<mdz> lamont: yes, please get a copy of the latest live CD for testing
<mdz> schweeb: yes, CD-ROM drives attached to those controllers seem not to work
* ogra just got an old i386 piix laptop back today ... but no iso yet.... :(
<mdz> schweeb: if you can get a copy of the latest live or install image, it would help us with testing
<lamont> daily-live/current/hoary-live-i386.iso
<lamont>    214515339  39%    1.08kB/s   83:42:26
* lamont grumbles
* lamont kisses his bandwidth allocation good bye
<schweeb> mdz: http://archive.ubuntu.com/cdimage/daily-live/20050309.1/ that the newest?
<jbailey> Looks like we're all having the same speed issues to cdimage
<mdz> schweeb: /daily-live/current/
<lamont> jbailey: seb128 uploaded everything, so it's a huge beast
<mdz> jbailey: Kamion is updating the mirrors right now I think
<Kamion> right, they just finished
<schweeb> alright... tell ya in about an hour
<jbailey> CAn anyone other than fabionne currently reproduce the problem at all right now?
<Kamion> sabdfl: synced; know of any mirrors that can be kicked?
<mdz> mvo: were you able to leave messages for him?
<Kamion> Treenaks: fixed your index issue now, thanks
<mvo> mdz: no, no answer phone, I'll send him a SMS now
<tseng> who is in charge of the new "about ubuntu"?
<mdz> tseng: doc team
<lamont> 0000:00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
<lamont> grumble
<tseng> the title doesnt show on the sidebar in yelo
<tseng> off to search bugs
<mvo> Kamion: is there a way to supress the loading of certain modules on the cd boot-prompt? (sorry if that was discussed before)
<Kamion> mvo: no
<sabdfl> Kamion: thats elmo's department
<Kamion> hotplug makes that practically impossible for the installer to control in any sane way, AFAICT
<sabdfl> how do i look to see if my computer is a candidate for the problem?
<Kamion> sabdfl: lspci | grep -i piix should be a start
<Kamion> mvo: you have to rm the module before it gets a chance to load it
<mvo> Kamion: it's loaded before I have the chance even when running as expert :(
<sabdfl> nup
<sabdfl> neither box will help
<mdz> mvo: a good way to do it is to use the install CD, and switch consoles at the hostname dialog
<Kamion> mvo: boot init=/bin/sh
<Kamion> mdz: that won't help if the module is in the initrd
<Kamion> mvo: then rm the module and exec /sbin/init
<tseng> mdz: huh, can I close 7310?
<jdub> morning whiprush 
<mdz> Kamion: I thought you arranged for it not to be loaded until "detecting disks and all other hardware"
<mdz> tseng: is it a preview-critical issue?
<Kamion> mdz: nope, don't see a sensible way to do that without killing e.g. CD-ROM detection
<tseng> mdz: no, its fixed
<mdz> ah, right
<Kamion> and it is kind of nice to have the modules loaded early if possible - *usually*
<mdz> tseng: can we talk about it tomorrow?  we're in crisis mode here
<tseng> ok sorry.
* ogra reads u-d
<mdz> schweeb: can you try what Kamion described above?
<ogra> many people seem to have issues with the theme upgrade ?
<jdub> ogra: two
<schweeb> mdz: which thing?
<tseng> ogra:you will always find someone to resist a change
<mvo> Kamion: ok, deleted, what now?
<Kamion> mvo: exec /sbin/init and continue
<ogra> jdub: HiddenWolf showed me a screenshot before....it were plain gtk widgets, somehow clearlooks didnt get insalled for him
<sivang> ogra: yes I also had it, like disturbed picture of the windows etc.
<Kamion> ogra: update-manager doesn't do dist-upgrade
<ogra> ah, ok
<mdz> schweeb: boot with init=/bin/sh
<mdz> schweeb: rm the piix module
<ogra> thanks again, Kamion 
<mvo> ogra: and the version pending has a warning if it detects that a dist-upgrade is needed
<mdz> schweeb: then exec /sbin/init
<mdz> (on the install or live CD)
<Kamion> and new ubuntu-artwork does not depend on gtk2-engines-clearlooks
<mdz> Kamion: is that a bug?
<jdub> Kamion: uuuuggghhh
<Kamion> mdz: judging from jdub's reaction I'd say "maybe" ;)
<jdub> Kamion: but u-d does, so, not to scary
<schweeb> mdz: will do, give the results in about an hour
<jdub> not too
<Kamion> jdub: quite bad if it actually needs it; 'apt-get upgrade' will break otherwise, since ubuntu-artwork will be upgraded but not ubuntu-desktop
<Kamion> or, for that matter, update-manager
<HiddenWolf> ogra: i didn't dist-upgrade, artwork doesn't depend on clearlooks, but desktop does, I think.
<lamont> gah.  even unthrottled at my end, it's 2 hours to finish the downlaod.
<lamont> time to visit the neighbor
<schweeb> mdz: shall I try it without that first to see if my cdrom works?
<jdub> Kamion: yeah, for people who don't have u-d, it sucks
<jdub> is it worth the upload?
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current | broken: PIIX support, langpack upgrades, ubuntu-artwork upgrades/ | review preview ann
<Kamion> jdub: even for people who do have u-d it sucks.
<ogra> HiddenWolf: yep
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current | broken: PIIX support, langpack upgrades, ubuntu-artwork upgrades
<Kamion> jdub: because if they have an old u-d it will simply be held back
<lamont> back online in about 10-15 minutes
<Kamion> mdz: what PCI ids are involved here?
<mdz> Kamion: fabbione pasted them a ways back
<jdub> Kamion: upgrade won't work, but dist-upgrade will, right?
<sivang> Kamion: then we should add this the the depends of -artwork no?
<jdub> sivang: yes, there is no question about that
<dholbach> re
<mdz> Mar 09 10:18:34 <fabbione>      #ifdef ATA_ENABLE_PATA
<mdz> Mar 09 10:18:35 <fabbione>              { 0x8086, 0x7111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, piix4_pata },
<mdz> Mar 09 10:18:35 <fabbione>              { 0x8086, 0x24db, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<mdz> Mar 09 10:18:35 <fabbione>              { 0x8086, 0x25a2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich5_pata },
<mdz> Mar 09 10:18:35 <fabbione>      #endif
<Kamion> ah yes, and modules.pcimap lists *both* ata_piix and piix for those
<Kamion> so there is hope
<Kamion> jdub: right
<Kamion> jdub: really nothing else can ever rely on ubuntu-desktop's dependencies for anything much, even if u-d is installed
<jdub> Kamion: so i can fix that straight after preview
<Kamion> jdub: yep
<schweeb> 0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
<schweeb> that's the PCI ID of mine if that helps
<Kamion> schweeb: that's not a PCI id, you need to use 'lspci -n' and find the corresponding line
<Kamion> with 0000:00:1f.1 at the beginning
<schweeb> whoops, meant to do that, sorry
<schweeb> 0000:00:1f.1 0101: 8086:248a (rev 02)
<Kamion> schweeb: is that broken?
<Kamion> pcimap only lists piix for that
<schweeb> thought piix was the offending module?
<Kamion> schweeb: only certain ones we think; however, if you could try it out anyway, we'd be very grateful indeed
<zul> hold on i have ata_piix loaded on my pc
<Kamion> schweeb: if our current hypothesis holds, your machine should be OK
<Simira> is anyone from Ubuntu going to "The gathering", in Norway in the Easter?
<schweeb> Kamion: alright... downloading the livecd for testing now... the drive worked fine from array 5, if that's any indication
<mdz> ok
<mdz> executive decision
<mdz> preview is going out tomorrow
<Kamion> schweeb: array 6 would be an indication
<Kamion> array 5 predates this change
<ogra> mdz :(
<Kamion> although it is a useful control
<mdz> zul: are you here?
<zul> mdz: yes
<Kamion> so are we changing this in the kernel, or in hotplug?
<Kamion> s/in hotplug/hacking hotplug/
<mdz> zul: can you do an upload to revert the patch from #1440?
<Kamion> mdz: can I suggest an alternative?
<mdz> Kamion: to which?
<Kamion> mdz: a total revert
<zul> I dont have access to main
<Kamion> mdz: we could instead just stop those PCI ids showing up in ata_piix
<Kamion> which is a two-line kernel patch
<mvo> Kamion, mdz: removing the module works so far. it gives a ugly error message at startup, but otherwise it is ok so far (install-cd)
<mdz> Kamion: hmm
<Kamion> since so far it sounds like only piix is affected, and this way we don't have to revert the whole thing
<mdz> Kamion: so the change is actually causing a different module to be loaded for these controllers?
<mdz> (one which doesn't work)?
<Kamion> mdz: yes, ata_piix gains three PCI ids #ifdef ATA_ENABLE_PATA
<mdz> or just changing behaviour for those IDs?
<Kamion> those PCI ids are also registered with piix
<Kamion> in fact I wonder if the problem could be that *both* modules are being loaded
<mdz> does ata_piix have any IDs that piix doesn't?
<mdz> or can we just blacklist it?
<Kamion> mdz: yes
<Kamion> it has other IDs
<mdz> hm
<Kamion> I have an idea
<mdz> I'm not very confident about pushing forward on this, rather than rolling back
<Kamion> mvo: could you please try booting without removing the module, go through until it fails, and then run 'lsmod | grep piix' for me?
<mdz> not least because I can't get my hands on this bug due to lack of hardware
<mvo> Kamion: yes
<Kamion> mdz: bear with me here just for a little bit
<mvo> Kamion: piix and ata_piix are both loaded
<mdz> Kamion: certainly
<mvo> your guess was correct
<Kamion> mvo: ok, which module did you remove the first time round?
<mjg59> Having two devices think they're running the DMA engine on there is going to make things very unhappy
<Kamion> yes, that's my thought
<mvo> Kamion: libata and ata_piix
<Kamion> mvo: this time, try removing piix
<mjg59> I'm surprised the kernel's letting that happen. At least one driver isn't doing the right thing for PCI.
* mvo reboots the machine once-more
<mdz> mjg59: e100 and eepro100 used to do this as well
<mjg59> mdz: 2.6 makes it a lot harder to do this
<zul> sata_nv does it as well if i recall
<mjg59> But IDE drivers are weird and wonderful and ALL BROKEN
<lamont_r> mjg59: but clearly these drivers have worked hard to get around 2.6's limitation... :-)
<fabbione> re
<mdz> fabbione: so we seem to have a clearer idea what is going on; two modules are being loaded for the same device
<T-Bone> re
* lamont_r rsyncs the livecd
<Kamion> the patch now ought to be trivial
<abelli> smurfix: ping 
<smurfix> abelli: ?
<fabbione> mdz: yes i know that, but we can't avoid ata_piix to be loaded
<fabbione> that means breaking
<fabbione> i did try removing it and restarting hotplug/udev stufd
<Kamion> fabbione: mvo is testing
<fabbione> the cdrom detection will hang since some scsi stuff is still loaded
<thom> smurfix: how do i debug the keyboard chooser magic? it got my UK apple usb keyboard very wrong (wound up giving me a bunch of symbols, none of which i have on the keyboard)
<fabbione> Kamion: if test is trying to remove one of the driver, i did already once removing the ata_piix and it doesn't work
<mdz> jdub: please upload ubuntu-artwork with the dependency fix
<jdub> mdz: ok, preparing as we speak
<Kamion> fabbione: instead, we're trying removing piix
<fabbione> Kamion: i can test that too
<smurfix> thom: I need to know which keys you pressed, and their keycodes
<Kamion> fabbione: like I say, bear with me
<Kamion> fabbione: please do
<smurfix> thom: (should add some logging for that)
<mvo> Kamion: removed piix this time. but it does not work
<fabbione> Kamion: already doing
<Kamion> mvo: hm, ok
<Kamion> let me do a quick audit of pcimap entries
<lamont_r> smurfix: I magine a report of "I couldn't identify your keyboard.  The magic answers are: ..., ..., ..., ... - please file a bug", eh?
<Kamion> mvo: you definitely booted with init=/bin/sh and removed it before doing anything else? could you check with lsmod to make sure it hasn't reappeared?
<mdz> seb128: there are no more translation updates, right?
<mdz> seb128: I am rolling new langpacks by hand
<lamont_r> 200kbytes/sec seems so slow some days
<mvo> Kamion: just did that (lsmod). I only have ata_piix loaded, no other piix driver
<fabbione> Kamion: no it doesn't work
<fabbione> Kamion: the cdrom still has I/O corruption
<smurfix> lamont_r: Yeah, something like that.
<fabbione> anyway the disk I/O looks ok
<thom> smurfix: pressing ` got "keycode 86 was not expected"
<fabbione> badblocks has been running for over an hour now
<fabbione> so what is the decision?
<smurfix> thom: That's the last step -- I need to log the keycodes before that.
<lamont_r> if we revert the PATA change, what do we break again?
<fabbione> 1440
<jbailey> and the timeline.
<T-Bone> at least it's a "safe" break
<smurfix> lamont_r: On second thought that's not so easy because I also need to know which of the possible keys the user meant to press. :-/
<mdz> the timeline is shot
<mdz> we are releasing preview tomorrow
<T-Bone> yeah, that one is more troublesome (re timeline)
<fabbione> mdz: ok
<mdz> sabdfl has decided it for us
<Kamion> awk -F' ' '{ print $2 "-" $3 " " $1 }' /lib/modules/2.6.10-4-amd64-generic/modules.pcimap | sort -u | uniq -t' ' -W1 -D | less
<smurfix> lamont_r: and the mind reading driver isn't ready for the kernel yet
<Kamion> there are a fair few duplicate ids in there; some harmless/intentional (e.g. mptbase/mptscsih)
<thom> smurfix: that was only the second question i answered
<jbailey> piix and ata_piix on their own seem to be fine - I've had system running each of these for a couple of weeks.
<T-Bone> so we're going to release with a *big warning*?
<smurfix> thom: That should make things easier.
<mdz> T-Bone: no, we're going to delay the release
<thom> smurfix: anyway, how should i go about getting any more info
<fabbione> mdz: should we roll out another kernel on the fly?
<smurfix> thom: Can you tell me the symbol and keycode of the first key you pressed?
<mdz> fabbione: as soon as we decide which fix to use
<Kamion> now that the timeline's shot, I think I agree that we should revert the #1440 fix
<fabbione> is there anybody other than me able to reproduce the problem?
<T-Bone> mdz: err?? I must have missed something then
<Kamion> fabbione: several
<mdz> fabbione: we can either revert the patch from 1440, or back out only the PIIX changes
<mdz> T-Bone: you missed me announcing that at least twice so far
<Kamion> T-Bone: scroll up
<mvo> fabbione: me
<Kamion> 19:26 < mdz> the timeline is shot
<Kamion> 19:26 < mdz> we are releasing preview tomorrow
<Kamion> 19:26 < mdz> sabdfl has decided it for us
<Kamion> like two minutes ago
<fabbione> mdz: the patch changes 2 things. ATA_ENABLE_ATAPI and ATA_ENABLE_PATA
<smurfix> thom: switch to text console, run "showkey", press the key in question
<thom> ah, cool
<fabbione> mdz: we can roll out one kernel that reverts the PATA, NOW
<Kamion> fabbione: are they independent?
<T-Bone> err... I didn't understand. To me tomorrow is 4h away...
<fabbione> mdz: and see if that is enough
<fabbione> Kamion: apparently they are
<fabbione> mdz: and if it is not we revert the other one
<mdz> Kamion: does tomorrow 1800UTC work for you?
<Kamion> mdz: as good as any
<fabbione> so in the worst is 2 kernel uploads
<fabbione> but we a precise and test "fix"
* ..[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 | please test pre-preview candidates: http://cdimage.ubuntu.com/daily/current/, http://cdimage.ubuntu.com/daily-live/current | broken: PIIX support, langpack upgrades, ubuntu-artwork upgrades | preview release: 20
<thom> smurfix: don't have showkeys
<Kamion> fabbione: would it be possible to come up with a list of the extra module/PCI-id pairs created by each of those?
<lamont_r> fabbione: so you're thinking upload -26 with just PATA turned back off, and see what that breaks/fixes?
<mdz> is there a length limit on the topic or something?
<Kamion> fabbione: I could then compare that against my list of duplicated PCI ids
<Kamion> mdz: there generally is
<lamont_r> mdz: usually, and freenode bumps it up to something larger,but finite
* ..[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 | preview release: 20
<fabbione> Kamion: for the piix there are only the 4 i listed before
<Kamion> fabbione: kernel-wide
* ..[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 | preview release: 2005-03-10 1800UTC
<mdz> apologies for the noise
<fabbione> lamont_r: let see what mdz suggest
<svenl> hi all.
<mdz> fabbione: let me look at the code a moment
<fabbione> Kamion: i am not sure how
<fabbione> mdz: sure
<Kamion> fabbione: I may be able to try
<smurfix> thom: console-tools: /usr/bin/showkey
<T-Bone> mdz:  TOPICLEN=450
<fabbione> Kamion: if you know a way, go for it
<T-Bone> (from login messages)
<Kamion> fabbione: *shrug* doesn't have to be a clean way :-)
<svenl> Kamion: i got yaboot from netboot working on pegasos, and i guess that from cd will be ok too, need to try.
<Kamion> svenl: ok, sorry but we're in the middle of a release panic and I haven't had any time at all to look
<seb128> mdz: nop, translations are fine
<fabbione> Kamion: yes.. i understand that :-) but right now is like 15 hours that i am around.. and not really a 100% clear mind to think even to extra hacks
<Kamion> svenl: but that's very cool :-)
<Kamion> fabbione: you and me both dude
<svenl> Kamion: no problem.
<fabbione> Kamion: ok.. let's try to think...
<svenl> Kamion: release panic -> that would be hoary release ? 
<Kamion> svenl: if that's something we can introduce cleanly post-preview, I'd like to try
<fabbione> Kamion: what we need exactly is the pci ids listed in the kernel?
<Kamion> svenl: hoary preview release
<svenl> Kamion: well, it is an OF upgrade, will need no change to yaboot itself.
<Kamion> fabbione: right. I'm grepping now
<Kamion> svenl: rock
<fabbione> Kamion: we need to grep for: static struct pci_device_id piix_pci_tbl[]  = {
<svenl> Kamion: xresprobe (#7144) and yaboot-installer will need fixing then.
<fabbione> pci_device_id is the struct that keep all the pci ids info
<Kamion> fabbione: no, I mean grepping for ATA_ENABLE_PATA, try it it's much quicker :)
<mdz> fabbione: ATA_ENABLE_PATA was not mentioned in the bug report; I did not even realize we had enabled that
<Kamion> fabbione: there are like five mentions of that, in two drivers
<svenl> mmm, netboot tries to detect keys :/
<thom> smurfix: 'q' was the first character, 0x10 0x90
<fabbione> Kamion: i think a simple process of that thing can give us all the pci ids
<Kamion> piix and pata_pdc2027x
<fabbione> Kamion: yes.. i know
<Kamion> sorry, ata_piix and ...
<fabbione> mdz: it has been enabled in the same patch and i am sorry because i have no idea why
<Kamion> all those pata_pdc2027x ids show up as duplicates
<Kamion> so I say definitely revert ATA_ENABLE_PATA
<mdz> zul should know, I think he rolled the patch
<fabbione> mdz: and i think reverting the PATA is enough
<zul> fabbione: i have a kernel with pata disabled if you want to test
<fabbione> but i need someway to test it
<fabbione> zul: i need that kernel into a cdrom installer to test
<fabbione> or something like that
* mvo just checked again, removing piix is not enough, ata_piix does not work on my test-system
<fabbione> simply installing the kernel is not enough
<fabbione> mvo: it's a combination...
<zul> frig..
<jbailey> Right, because initrd-tools isn't that bright.
<mvo> fabbione: ah, ok
<mdz> fabbione: it seems to only affect the ata_piix module from what I see in grep, so it should be sufficient to test with a replacement ata_piix module
<fabbione> jbailey: bingo
<Kamion> fabbione: stick the udebs in debian-installer/build/localudebs/, build
<thom> smurfix: then ` which is 0x56 0xd6 ; and that was the unrecognised one
<Kamion> although that won't be quite right
<Kamion> ... what mdz said
<smurfix> thom: what other symbols are on that key on your keyboard?
<zul> fabbione: couldnt we just copy the .ko?
<Kamion> you probably need to depmod too
<fabbione> Kamion: i don't think it works.. the kernel modules are still downloaded at whatever time
<smurfix> thom: ... and what's the correct console keymap for it?
<Kamion> fabbione: run in expert mode and then you have time to replace them
<thom> smurfix: ` ~
<fabbione> mdz: it should be enough to rever that module.. yes
<Kamion> fabbione: and anyway ata_piix is very likely in the initrd and not downloaded at all
<fabbione> ok.. gimme a few secs
<Kamion> although it'll depend on your image
<fabbione> Kamion: hmmmm
<fabbione> Kamion: i have the same images as you do
<mdz> zul: can you make your ata_piix.ko available for download?
<fabbione> i can craft the one from netinstall
<mdz> Kamion: yes, and depmod
<zul> zul: that is what im doing right now
<Kamion> svenl: yaboot-installer is easy enough, but I have no clue about #7144
<fabbione> and see if i can read cdrom with an older ata_piix
<Kamion> fabbione: I mean, cdrom or netboot?
<Alessio> sorry, what do you think about ipodder in ubuntu?
<Alessio> for podcasting
<fabbione> Kamion: i can use both
<fabbione> Kamion: which one do you suggest to craft?
<fabbione> Kamion: netboot is the fastest one to reload imho
<fabbione> without having to burn a cd
<smurfix> thom: Ah, that's the additional key on the pc105 keyboard. *Sigh*. I'll have a look.
<Kamion> fabbione: hm, ok, plan:
<Kamion> fabbione: use netboot in expert mode; run through until after "retrieving installer components"; pause at the menu; wget new ata_piix.ko, drop into place; continue
<Kamion> the installer will depmod for you
<thom> smurfix: (it's a british english apple usb keyboard)
<zul> fabbione: ata_pixx.ko without pata http://zulinux.homelinux.net/ubuntu/kernel
<fabbione> Kamion: ok
<smurfix> thom: Yeah, and there's no good console keymap for it, is there?
<zul> fabbione: #define ATA_ENABLE_ATAPI  #undef ATA_ENABLE_PATA
<Kamion> zul: that still has the dup PCI ids
<Kamion> zul: checked with modinfo, it has 24db 25a2 7111
<zul> Kamion: ok
<fabbione> Kamion: while i boot can you kindly get ata_piix.ko from the morgue?
<fabbione> just to be 100000% sure is the old one?
<Kamion> fabbione: which version?
<thom> smurfix: mac-usb-uk is fine, afaik
<lamont_r> Kamion: I think -24 was pre-ata patch
<fabbione> Kamion: linux-source-2.6.10 (2.6.10-24) hoary; urgency=low
* lamont_r doublechecks
<zul> it was
<fabbione> yes -24
<lamont_r> fabbione: beate me
<Kamion> mdz: ATA_ENABLE_ATAPI does not introduce any PCI id changes, as far as I can see
<fabbione> Kamion: no it doesn't
<fabbione> it's only the PATA that adds pci ids
<mdz> zul: you are confident that ATA_ENABLE_ATAPI alone addresses #1440?
<Kamion> fabbione: http://people.ubuntu.com/~cjwatson/ata_piix.ko
<mdz> Kamion: that's from linux-image-2.6.10-4-386 2.6.10-24?
<Kamion> yes, and confirmed that it does not have the offending PCI ids
<fabbione> HMMM
<fabbione> there is no ata_piix on the system right now
<fabbione> so it means it will be downloaded via sata-modules
<mdz> ?
<Kamion> there won't be until after "retrieving installer components"
<fabbione> mdz: sorry that's for Kamion
<Kamion> sata-modules is not in the netboot initrd
<Kamion> right, it will be downloaded
<Kamion> but if you're in expert mode, you will have an opportunity to replace it
<fabbione> but i can just tell d-i not to install it
<Kamion> no don't
<Kamion> do what I said earlier
<zul> mdz: yes i looked through the mandrake patches and that was the only one there
<Kamion> 19:39 < Kamion> fabbione: use netboot in expert mode; run through until after "retrieving installer components"; pause at the menu; wget new ata_piix.ko,
<fabbione> ok
<Kamion>                 drop into place; continue
<mdz> zul: so they are enabling ATA_ENABLE_PATA?
<zul> mdz: yes
<mdz> interesting
* lamont_r finishes downloading, heads back home
<jbailey> I woner if they do hotplug based autodetection then?
<lamont_r> eta 10 min or so
<Kamion> entirely possible they don't
<Kamion> Mandrake are a kudzu shop aren't they?
<zul> from mandrake: 
<zul> -#undef ATA_ENABLE_ATAPI                /* define to enable ATAPI support */
<zul> -#undef ATA_ENABLE_PATA         /* define to enable PATA support in some
<zul> +#define ATA_ENABLE_ATAPI               /* define to enable ATAPI support */
<zul> +#define ATA_ENABLE_PATA                /* define to enable PATA support in some                                 * low-level drivers */
<Kamion> zul: if they don't use hotplug, they probably won't hit the bug
<mvo> zul: trying to load your ata_piix with the install-cd gave me a "ata_pixx: disagrees about the version of struct_module"
<zul> its based on -25
<fabbione> can anybody paste me again the md5sum for Packages.gz on livecd dists/hoary/main/debian-installer/binary-i386 ?
<Kamion> mvo: try http://people.ubuntu.com/~cjwatson/ata_piix.ko
<fabbione> as well as Packages
<Kamion> fabbione: one sec
<Kamion> ba22054987588dc3847b52bdd794a54e  dists/hoary/main/debian-installer/binary-i386/Packages
<mvo> Kamion: ok. it takes a bit, I need to put it on a usb-stick and copy it over
<Kamion> 24323b5da4533d415d1821cb7a3ded24  dists/hoary/main/debian-installer/binary-i386/Packages.gz
<Kamion> fabbione: ^--
<fabbione> well 
<mdz> fabbione: 24323b5da4533d415d1821cb7a3ded24  /mnt/dists/hoary/main/debian-installer/binary-i386/Packages.gz
<maswan> jdub: :), a bit of increased traffic the last couple of hours: http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<fabbione> let's turn off PATA bunch of wankers!
<fabbione> and let's make this damn preview RELEASE!
<zul> Kamion: they use hotplug
<smurfix> thom: I *hate* these keymaps, they're incomplete as *hell*.
<thom> smurfix: :(
<mdz> fabbione: do we need to have the #1440 people re-test?
<thom> smurfix: totally unsurprised
<fabbione> mdz: yes
<smurfix> thom: If you look at the keymap you'll find that that key is not assigned *anywhere*
<fabbione> mdz: that fixes the I/O corruption on piix cdrom
<zul> Kamion: probably not in the install though
<thom> smurfix: joy :(
<fabbione> mdz: in full hounestly i didn't have the time to read all of #1440
<smurfix> thom: which means it gets its setting from the kernel ... or the keymap that's been installed before it. :-/
<Kamion> let's roll a new kernel without ATA_ENABLE_PATA then, and we can roll new d-i based on it
<fabbione> Kamion: ok
<fabbione> lamont: ping?
<Kamion> if mdz's ok with that plan
<fabbione> mdz: ?
<mdz> go for it
<fabbione> ok
<fabbione> it will 25.1
<Kamion> we still have lots of time for a complete revert if need be
<mdz> fabbione: why not 26?
<fabbione> Kamion: exactly
<mdz> oh, you have a 26 prepared already
<smurfix> thom: I'll go and fix the immediate problem but a review of the whole mess will have to wait after the prerelease. :-/
<fabbione> mdz: because i have it already in RCS with tons of other changes that we do NOT want now
<smurfix> thom: can you email me your "dumpkeys" output please?
* Kamion -> dinner
<mvo> Kamion: is it still worthwhile that I test your ata_piix module with the new plan?
* sivang --> out for the night, maybe be back later.
<Kamion> mvo: yes
<Kamion> mvo: the new plan will be a better test, but it's worth a shot
<mvo> Kamion: ok, doing it now
<ogra> smurfix: how about dumpkeys collection in hwdb-client in hoary+1 ? sounds ike you could need the data
<thom> smurfix: sure
* thom -> out for a couple of hours
<thom> smurfix: smurf@debian.org
<smurfix> ogra: All I need to do is to preload the table with the standard kernel layout
<smurfix> thom: sure
<smurfix> ogra: and then check what's missing
<ogra> smurfix, ah, so youre doing that on the fly anyway....
<smurfix> ogra: should be a straightforward if annoying piece of programming
<smurfix> ogra: yes and no -- I precompile the decision table
<smurfix> ogra: The job takes too long to do it at install time.
<ogra> ah
<mvo> Kamion: with your ata_piix module it works here. both modules (piix, ata_piix are loaded, but ata_piix is not in use and piix seems to be in control 
* jbailey runs off for lunch.
<thom> smurfix: http://people.ubuntu.com/~thom/dumpkeys-mac-usb-uk (sorry, easier than email right now)
<mdz> mvo: great
<mvo> mdz: I'm standing by here, if there is more I can do, just tell me
<fabbione> stuff can wrong
<fabbione> ops
<smurfix> thom: Thanks.
* mvo is having dinner now
<smurfix> thom: keycode  86 = less             greater          bar
<lamont> fabbione: pack
<lamont> er, ackj
<fabbione> lamont: ok.. i have almost done
<fabbione> i am updating the patch now
<smurfix> thom: ... which doesn't look like  ` ~ to me ...
<smurfix> thom: please verify.
<fabbione> lamont: 25.1 won't be under rcs.. not from me at least
<fabbione> lamont: my wife is already yelling and screaming that i am still here
<lamont> fabbione: you upload, I'll commit
<fabbione> lamont: ok
<schweeb> mdz, Kamion: booted into the livecd now, worked fine... cdrom's working and everything
<fabbione> lamont, mdz: almost done...
<mdz> schweeb: interesting; which piix module(s) were loaded for you?
<fabbione> lamont: i also committed the last changes i had to pre26
<mdz> schweeb: it may be that your particular PCI device is not affected
<fabbione> so it only needs 25.1 merging
<fabbione> just check the lspci -n and compare the IDs
<schweeb> mdz: just piix
<schweeb> then the rest of the regular ide_* drivers
<lamont> fabbione: ok.  we'll see how well baz does with the merge-of-duplicates. :-)
<fabbione> we MUST get rid of that patch madness
<T-Bone> indeed
<zul> 2.6.11 would be a good canidate to start
<T-Bone> indeed :)
* lamont burns a livecd...
* lamont feels somehow useless
<fabbione> zul: we will come out with 2.6.11 when we will have the time
<zul> fabbione: true
<fabbione> and we redo the packaging immediatly after hoary
<fabbione> now .10 has max priority
<T-Bone> lamont: burn some wood, it'll produce more heat :}
<lamont> fabbione: speaking of which, eta to upload?
<fabbione> lamont: uploading now
<fabbione> Uploading via ftp linux-source-2.6.10_2.6.10-25.1.diff.gz: 
<lamont> woot
<fabbione> Successfully uploaded packages.
<fabbione> have fun
<lamont> thanks
<fabbione> i lost katie for a few secs...
<fabbione> too bad
<fabbione> i will just wait the ACCEPT mails
<fabbione> and i am think i will be off for today
<zul> later fabbione 
<fabbione> 6am -> 10pm is a long run
<fabbione> zul: not yet...
<fabbione> there it is
<fabbione> linux-source-2.6.10_2.6.10-25.1_source.changes ACCEPTED
<T-Bone> sweet
<lamont> fabbione: and you beat cron.daily... woot
<fabbione> ehehe
<fabbione> ok.. mail to changes too
<lamont> fabbione: that means I only have to wait about 10 minutes for source, instead of 40
<fabbione> 6 minutes actually
<fabbione> daily is at 33 ;)
<fabbione> 5 now....
<fabbione> lucky eh? :)
<lamont> yeah, plus a couple for the stuff to propogate
<fabbione> last hit on the new album and i am off
<fabbione> i have too much adrenaline to sleep right away
<schweeb> odd
<fabbione> schweeb: what?
<schweeb> in OO.o 1.1.3 CUPS printing appears not to be working
<schweeb> works everywhere else
<fabbione> Kamion: i think we should all get some good night sleep and meet tomorrow morning early to test together again
<fabbione> Kamion: what about 6 UTC?
<schweeb> and in the OO.o 2 preview
<fabbione> i definetely cannot wait 2 hours for CD images this night
<schweeb> the odd thing is the job gets queued and sent to the printer, but the receive light blinks a couple times and does nothing
<fabbione> or my wife will ask for divorce :)
<schweeb> lol
<T-Bone> fabbione: this would be quite soon for that heh :)
<T-Bone> s/soon/early/
* T-Bone can't type
<lamont> fabbione: at this stage, many jurisdictions would permit an annulment... but you don't want to go there either
<T-Bone> lol
<fabbione> ehhehe
<T-Bone> lamont: is it because you're living in the us that you see the legal matter before everything else? :^)
<zul> fabbione: already some celebrities last a month
<fabbione> lamont: see.. after the first 2 weeks we knew eachother she told me: "I hate italians and i don't like nerds..."
<fabbione> lamont: that's why we got married ;)
<zul> lol
<lamont> lol
<T-Bone> fabbione: rotfl
<fabbione> lamont: so now i would like to show that even a nerd can have a life ;)
* T-Bone has to fortune
<fabbione> T-Bone: at this speed your fortune will have 99% of my entries
<T-Bone> fabbione: heh. jbailey is quite a candidate you know :)
<T-Bone> i'll make sure to make it available somewhere anyway :)
<fabbione> ok i am off
<T-Bone> see ya
<fabbione> lamont: can you make sure with Kamion that the new kernel is in any of the CD (live or install) by 5 UTC?
<fabbione> lamont: i usually wake up at that time and i can start testing immediatly after
<mdz> fabbione: good night and thanks
<fabbione> mdz: no problem
<mdz> fabbione: welcome back ;-)
<fabbione> I WANT THIS PREVIEW OUT!
<fabbione> mdz: ehehhe
<lamont> night fabbione - np on the kernel being there.
<fabbione> lamont: perfect
<fabbione> cya in a few hours
<fabbione> and get some rest while the kernel propagate
<fabbione> it's pointless to watch the logs ;)
* fabbione &
<mvo> mdz: I have pitti at the phone, he asks what's wrong with the lang-packs
<mdz> mvo: bug #164595
<mdz> mvo: dpkg: error processing /var/cache/apt/archives/language-pack-en-base_20050308_all.deb (--unpack):
<mdz>  trying to overwrite `/usr/share/locale-langpack/en_CA/LC_MESSAGES/gnome-panel-2.0.mo', which is also in package language-pack-en
<mvo> mdz: pitti says he solved it with a pre-depends? does it not work?
* lamont fetches source, lunches while he waits
<mvo> mdz: he is at a place with not network, he'll see to it tomorrow morning. is there a deadline for him?
<mdz> mvo: it does not work
<mdz> mvo: the pre-depends needs to be versioned
<mdz> mvo: it can be dealt with first thing in the morning
<mvo> mdz: ok, he'll deal with it then
<svenl> Kamion: 7144 is under control, i just need to find time, but there is this OF work, and the debian 2.6.11 kernels, and the 2.4.27 mess and so on.
<mdz> jdub: what is the delay on the new ubuntu-artwork?
<HiddenWolf> mdz: it's uploaded, isn't it?
<svenl> 7144 is tzo-sided. one is simply to detect that a pegasos needs BusType "PCI", and add it to the config file, the second is to fix xresprobe, and io will provide a patch for it.
<ogra> HiddenWolf: nope
<mdz> HiddenWolf: no, it's missing a dependency
<HiddenWolf> mdz: ah, that.
<Kamion> schweeb: good, according to our guessed diagnosis your machine should not have been affected, so I'm glad that's how it really is
<Kamion> fabbione: I can't be there by 6 UTC; Kirsten is ill and I need to do a certain amount of looking after her
<mdz> I'll be here at 6 UTC
<Kamion> I think others may have to take care of the d-i build and a new CD build
<Kamion> I have disabled the CD cron jobs (apart from Kubuntu), so any builds will have to be manual
<Kamion> anyway, I'll be around for a couple more hours
<zul> later
<Kamion> mdz: should we mail ubuntu-devel@ to explain the delay, and to say that preview freeze is still in effect?
<Mithrandir> Kamion: I think that would be good.
<Kamion> I can do that if you want
<mdz> Kamion: yes, that's a good idea. I'll do it
<Kamion> ok, thanks
* Kamion doesn't want to be picking up the pieces from somebody assuming that we were back to feature freeze status :)
* lamont finds another piix machine in the house.
<lamont> the 7th grader will be a bit inconvenienced.
<T-Bone> lol
<lamont> hrm... I really have to do something about the 23 minute startup time in my mirror-archive script
<daniels> svenl: the BusType PCI thing shouldn't be needed, though -- it's indicative of broken hardware
<svenl> daniels: it is indicative of broken radeon drivers in the ubuntu packages. Xfree86 4.3 as used in debian had no such problem.
<svenl> daniels: the pegasos hardware uses a NB which had no agp bus, so fakes a pci-x bus into being an agp one.
<svenl> daniels: this is a feature, not broken hardware.
<svenl> daniels: and the agp-express guys have a similar solution on x86 even.
<svenl> daniels: so the sane thing would be to do like the debian X packages, if for whatever reason loading agpgart fails, fall back to pcigart transparently.
<daniels> svenl: how is it a feature?  do you even use that agp bus?
<daniels> svenl: i agree it should fall back to pcigart transparently, and my understanding was that that was happening
<daniels> but setting up an agp gart was either hanging or reporting success
<tritium> Hi.  What's the policy on new packages in universe regarding .menu and .desktop files?  Do they need both?  Only .desktop?
<svenl> daniels: it is a feature because with a NB without agp bus, you can use agp cards, which are more easy to find.
<svenl> daniels: there is thus no agpgart.
* lamont does a testinstall with the new postfix bits.
<lamont> (which won't upload until after the preview...)
<svenl> daniels: and the agp express do the same, they add pci-faked-as-agp slot on intel pci-express motherboard for compatibility reason, so you will see this case outside of the pegasos too.
<svenl> daniels: it doesn't happen. neither michel's dri-trunk, not ubuntu's X.org have the transparent fallback magic in it.
<daniels> svenl: i think it's a pathologically dumb case, but there you go -- bear in mind that i've never heard of this needing to be done anywhere else, so either no-one owns the intel pcie motherboards, or they did it properly
<daniels> svenl: well, patches welcome.
<svenl> daniels: it is a new thing for compatibility with older hardware.
<daniels> yes, I know, I have a PCIE motherboards
<svenl> daniels: xresprobe and yaboot support in OF have priority :)
<daniels> s/.$//
<svenl> daniels: but not on with this new AGP-express thingy. I believe it is from ECS or something.
<daniels> yes, well that would be the reason why I don't have it
<daniels> anyway, gotta go now; follow up in the bug report if you like
<svenl> daniels: for hoary it will be more easy to simply detect a pegasos machine and but the bustype accordyingly though.
<svenl> daniels: does this mean that you will do nothing about it unless i provide a patch ? Is your pegasos machine running ?
<lamont> what was the magic incantation to turn off the archive copier?
<T-Bone> kill -9 -1 ;)
* T-Bone runs away screaming
<lamont> archive-copier/copy=false
<mdz> Kamion: at what point do you want to tackle the WinFOSS-on-livecd stuff?  I think we should start shipping it quite soon after preview
<mdz> T-Bone: fuser -k ;-)
<T-Bone> mdz: hehe ;)
<lamont> it's just a tarball to unpack right before the mkisofs
<lamont> fuser -k mdz :-)
<T-Bone> LOL
<mdz> lamont: did the last round of kubuntu cloops build OK?
<Kamion> mdz: damn, I forgot about that
<Kamion> mdz: soon after preview is good
* lamont looks
<tseng> mako: i started a draft on the wiki as UnsignedGpgKey, id appreciate your review at some point
<zenwhen> in a half hour I will have all the preview packages
<zenwhen> :D
* Kamion adds it to ~/ubuntu/status
<tseng> mako: unless you are part of the release crunch.
<lamont> mdz: the last [k] ubuntu builds of cloops worked on !ia64
<lamont> that is our (full) report :-)
<Kamion> tritium: nowadays probably just .desktop is fine
<Kamion> tritium: although others might disagree here
<Kamion> mdz: I'd actually meant to do that for preview
<Kamion> think I can squeeze it in?
<tritium> Kamion, thanks.  Okay, I did run it by ogra.  It is a new package, so I believe I'll still with .desktop.
<tritium> s/still/stick
<svenl> Kamion: yaboot on pmacs/cds, it has just a plain iso9660 on the cds, or some extra magic ?
<Kamion> svenl: hybrid iso9660/hfs (same as Debian)
<Kamion> svenl: I think pegasos OF is fine with it, although you might want to check
<svenl> Kamion: because yaboot sees that there are no partitions on my cd, and then tries each filesystem it knows, but not iso9660.
<Kamion> yaboot doesn't implement ISO9660 itself
<svenl> ext2, reiserfs, xfs, and then OF fallback, but it adds a extra :00 to the of call, which confuses my OF :/
<Kamion> I believe it defers to OF to do that
<svenl> yep, but adds bogus arguments to the OF prom_open call :/
<Kamion>      strncpy(buffer, dev_name, 768);
<Kamion>      strcat(buffer, ":");
<Kamion>      if (part) {
<Kamion>           char pn[3] ;
<Kamion>           sprintf(pn, "%02d", part->part_number);
<Kamion>           strcat(buffer, pn);
<Kamion>      }
<Kamion> hmm
<svenl> Kamion: also, do you know how the cds can boot on ibm chrps, if they don't have a yaboot.conf in a separate /etc ?
<Kamion> svenl: I suspect they don't
<svenl> Kamion: where is that ?
<svenl> Kamion: :)))
<Kamion> I should probably stick a symlink in or something
<Kamion> svenl: yaboot/second/fs_of.c:of_open()
<Kamion> svenl: probably the question to ask is how come part is non-NULL
<svenl> Kamion: that i know :)
<svenl> because partition.c partitions_lookup sets it to a iso9660 partition.
<zenwhen> do any of you devs use reiserfs?
* svenl guesses yaboot is over buggy, and we can't even fix it without a 6+ month flamewar with Ethan :/
<mdz> Kamion: if you want to squeeze in the winfoss stuff, sure
<mdz> it doesn't get much safer
<svenl> zenwhen: reiserfs is a data eater.
* svenl wonders how comes this works on pmacs :/
<Kamion> I'm happy to fix yaboot in Ubuntu if it's clear the code change doesn't affect pmac
* T-Bone uses reiser and xfs
<Kamion> can Pegasos OF be fixed not to mind the :00?
<svenl> Kamion: can you build a yaboot with full debug and try it on a pmac from a CD ?
<Kamion> well, "fixed", whatever
<Kamion> svenl: sure, but not today; I've made a note
<svenl> Kamion: well, it could, but who knows what else may be broken.
<svenl> Kamion: i can hack OF until tomorrow 16h00 only.
<Kamion> yes, and I have a release to sort out now
<Kamion> I will try to do it tomorrow morning
<svenl> Ok, cool.
<Kamion> svenl: oh, do you still want that yaboot.conf?
<svenl> I plan to see if i can fix it.
<thom> smurfix: i suspect that the console keymap i have doesn't actually look much like the keyboard :/
<svenl> Kamion: i think not.
<svenl> Kamion: err, yes, i want it.
<Kamion> I can get you one now if need be, I have a recent installation
<svenl> but less urgently.
<svenl> Kamion: ok, get it and mail it to me.
<svenl> so i can play with it.
<smurfix> thom: *sigh*. Can you write one that does? I'd do it but I don't have your keyboard. :-/
<Kamion> mailed
<Kamion> there's a whole bunch of entries at the end that are worked out from os-prober, you can ignore those
<svenl> I guess this code you pasted above is just plain broken, the right fix would be to set the partition number to -1 in partitions.c, and then do a check for that there.
<svenl> ok.
<svenl> or maybe check for a partition of size 0, i don't think there are any valid partitions entries where the first partition has a size of 0.
<svenl> oh well.
<mvo> Kamion, mdz: when do you think there will be something to test for me (and my piix system)? is it worth to stay up? or should I do it as first thing in the morning?
<Kamion> mvo: some of the kernel builds are done, so maybe a couple of hours if mdz is happy to do another d-i byhand (or if elmo is up)
<thom> smurfix: i'll add it to my todo *sigh*
<lamont> Kamion: is the install CD actually checking gpg sigs and such on Releases?
<thom> i can byhand if necessary, but if elmo is around i'd prefer to defer
<thom> to him
<Kamion> lamont: CD doesn't bother, netboot does
<Kamion> lamont: it does check that the Packages md5sums match what's in Release though
<smurfix> thom: Sorry that I can't be somewhat more helpful. Of course you could package up the keyboard and UPS it to me ;-)
<lamont> Kamion: Menu item 'apt-setup-udeb' failed...
<mvo> if apt-cdrom add is used, it will also check the signature and only copy the gpg file if they match
<lamont> what did I b0rk?
* smurfix => bed ...
<lamont> (rewritten Packages...)
<Kamion> lamont: that's not d-i
<thom> smurfix: heh
<lamont> Configuriing same exited 1
<Kamion> lamont: yeah, that whole thing kinda sucks
<lamont> oh wait.
<thom> smurfix: well, i do have two of them, but that seems a little excessive :-)
<lamont> lack of net connectivity wouldn't do that, would it?
<Kamion> lamont: I want to turn off *all* authentication on the CD somehow, if possible; it's too damn hard to customise it at the moment
<mdz> elmo: are you around?
<lamont> Kamion: built a new Release file with the right md5sums and such, I think
<Kamion> mvo: will apt-cdrom add be happy with a missing Release.gpg?
<Kamion> lamont: it'll be more the invalid Release.gpg sig, I'd expect
<Kamion> well, that too, at least
<mvo> Kamion: yes
<thom> mdz: if he's not in the datacenter he has no laptop
<Kamion> I killed some of the authentication on the CD for #5723
<mdz> thom: is he one of those weirdos who doesn't have a real computer?
<thom> mdz: unless he's arranged to steal one
<Kamion> and the fact that I remembered that bug number without even looking is scary
<mdz> only a laptop?
<thom> mdz: naw, but he's in london rahter than leeds
<mdz> ah
<mvo> Kamion: indeed :)
<lamont> Kamion: well, I built a new Release.gpg, but of course the key is mine, not the CD image key...
<lamont> where do I replace/add the key?
<Kamion> you might be able to glue it into ubuntu-keyring then
* lamont just whacked /target/etc/apt/trusted.gpg and continued...
<lamont> but I'd like to have it nicer...
<lamont> that is, what package actually delivers /etc/apt/trusted.gpg?
<mvo> lamont: you could just add it to the ubuntu-keyring package
<mvo> lamont: /usr/share/keyrings/ubuntu-archive-keyring.gpg
<lamont> mvo: to ubuntu-archive-keyring.gpg?
<lamont> cook
<lamont> cool, even
<svenl> Kamion: if i mail you a small yaboot patch, can you try it tomorrow on your pmac ? 
<lamont> good to know for the next time.
<lamont> but I'm manually past the annoyance for this pass
<Kamion> svenl: yeah
<lamont> "Configuring base system" isn't lsb-ized
<lamont> s/base/the base/
<Kamion> "lsb-ized"?
<svenl> Kamion: basically i test in the above function if the partition is 0 sized and the only one, which is the iso9660 configuration.
<Kamion> that's not an init script, it's something that base-config says
<sabdfl> hi guys
<sabdfl> just read the scrollback
<sabdfl> mdz: what times did you set for the release tomorrow?
<zenwhen> preview is slick guys
<zenwhen> :)
<Kamion> zenwhen: no preview yet ...
<zenwhen> huh
<zenwhen> i thought I saw an announcement
<zenwhen> was it premature?
<Kamion> where?
<zenwhen> a link
<zenwhen> in this channel
<zenwhen> that spoke as if the preview was done
<Kamion> that was a draft, and had "Draft" in the URL
<zenwhen> and linked to images
<zenwhen> Oh
<zenwhen> well whatever this is, is really slick
<zenwhen> ;)
<Kamion> real preview should be tomorrow, very small change from what you have though
<Kamion> sabdfl: he put it in the topic: "preview release: 2005-03-10 1800UTC"
<zenwhen> its nice to see gnome 2.10 on my desktop on release date instead of three weeks later when I was running slackware.
<zenwhen> I switched to ubuntu because quick gnome 2.8 inclusion, and am impressed as hell to be running 2.10 on release day
<zenwhen> of^
<Kamion> sabdfl: bonus of the delay, though: releases.u.c mirrors should all have today's image, and the rsync to tomorrow's will be pretty small
<Kamion> few tens of MB per CD maybe
<sabdfl> Kamion: perfect!
<Kamion> not that I'm suggesting we go through this hell every time ;)
<Kamion> hmmm. should change the cdebconf password widget to display *s.
<sabdfl> Kamion: everything on our release checklist sorted?
<sabdfl> do we need to add anything to that list for final?
<sabdfl> other than:
<Kamion> where's the checklist again?
<sabdfl>  - get final artwork in A WEEK BEFORE
<jon1012> hello :)
<sabdfl>  - get kernel sorted TWO WEEKS BEFORE :-)
<T-Bone> lol
<Kamion> er, hmm. should we remove "Development Branch" from lsb-release and stuff?
<Kamion> and we should change Release
<mako> tseng: i hacked on https://www.ubuntulinux.org/wiki/UnsignedGpgKey after dholbach pointed it out to me
<Kamion> I guess "Development Branch" can stay until just before final
<mako> tseng: i added a bunch
<sabdfl> http://www.ubuntulinux.org/wiki/ReleaseChecklist
<sabdfl> Kamion: ^
<mdz> sabdfl: 1800 UTC is the target
* Kamion changes debian-cd/CONF.sh's OFFICIAL line, oops
<sabdfl> so final build in by 12:00 UTC?
<Kamion> perhaps we should s/Development Branch/Preview/g
<Kamion> sabdfl: I think that's doable; need to get elmo to change dists/hoary/Release, ideally
<Kamion> although "Ubuntu Hoary Unreleased" is not too bad
<mdz> sabdfl: we can do the final build tonight in fact
<mdz> new kernel build is up, at least on i386
<sabdfl> ok
<Kamion> still waiting for powerpc and (to a lesser extent) ia64
<mdz> mvo: still here?
<mvo> mdz: yes
<mvo> mdz: but a bit sleepy :)
<mdz> mvo: are you able to do a test run with the new kernel?
<mvo> mdz: yes, what needs to be done?
<sabdfl> let's let kamion, elmo get a good nights rest
<sabdfl> there will be lots to do tomorrow
<sabdfl> make the most of the delay
<mdz> Kamion: which udebs will mvo need to swap in in order to test?
<Kamion> mdz: sata-modules
<mdz> oh, never mind, it'll be in the initrd, won' t it
<mvo> mdz: I think so, it is with the current cd
<Kamion> yes
<mdz> we could do a daily d-i build for i386
<Kamion> mdz: ok, I'll start kicking them off
<Kamion> i386 and amd64 d-i builds kicked
<jdub> morning
* jdub growls about loud leaf blowers in the morning
<Liblit> Hey, jdub.
* T-Bone wonders who was saying mac sucked...
<T-Bone> seems that Linus doesn't agree :)
<T-Bone> which is way cool: maybe we'll have a rock solid linux kernel on ppc now :)
<thom> T-Bone: he has a big power5 box now doesn't he?
<T-Bone> yeah
<dredg> T-Bone: feh, what does linux know? :)
<dredg> er, linus
<T-Bone> dredg: nothing much, He just "switched"
<T-Bone> his main platform is no longer x86 :)
<T-Bone> http://www.zdnet.com.au/news/0,39023165,39183867,00.htm
<Kamion> linus has had a powerpc box for ages
* dredg is getting annoyed at the way his hands automatically type words...
<Kamion> it's why powerpc went mainline
<mdz> and still we have random SIGILLs
<T-Bone> Kamion: yeah, but making it his main machine is brand new
<T-Bone> mdz: i hope that this will be fixed soon, if that's effectively a kernel bug. I bet he'll notice and get annoyed enough to fix it :)
<whiprush> anyone know the right mirror contact email offhand? mirrors@canonical.com is bouncing and I'd like to fix the wiki entry.
<Kamion> I've never seen those SIGILLs outside the context of a buildd
<T-Bone> Kamion: yeah. That's a hint imho
<Mithrandir> whiprush: uhm, just edit the wiki? :)
* lamont looks around for fabbione, or, alternatively, root@rookery
<whiprush> I don't know what the right address to fix it to is though.
<lamont> elmo/thom??
<whiprush> Or should we just add mirrors and forget the email contact?
<Kamion> T-Bone: probably just that it only occurs under fairly heavy load ...
<thom> lamont?
<mxpxpod> fabbione: good work on the linux-source-2.6.10 package :)
<Kamion> mdz: i386 and amd64 d-i builds done
<lamont> thom: on rookery, please: find ~lamont/public_html/Archives ! -user lamont -perm -0200 ! -perm -020 | xargs chmod g+w
<lamont> and lart fabbione for me.
<T-Bone> Kamion: buildd workload is quite specific. There are other things generating much more load
<mdz> Kamion: shall I byhand them, or pull out an initrd for mvo?
<Kamion> T-Bone: true
<Kamion> mdz: byhanding would be good
<T-Bone> Kamion: that sigill stuff could be toolchain related, i think
<thom> done
<Kamion> lamont: how far along are the powerpc and ia64 kernel builds?
<ogra_live> hmm, piix works fine on my old lappie .... funny
<lamont> linux-source-2.6.10_2.6.10-25.1_20050309-2037 04:04:41 (2 entries, sigma 00:03:10)
<lamont> that's ppc.
<mdz> Kamion: done, syncing
<lamont> ia64, if it goes true-to-form, will just miss the kubuntu CD build, since it will upload right around 0415 or so
<lamont> and ppc will be in the archive at about 0103 your time
<lamont> ia64: linux-source-2.6.10_2.6.10-25.1_20050309-2037 07:29:45 (6 entries, sigma 00:09:07)
<lamont> i386: linux-source-2.6.10_2.6.10-25.1_20050309-2040 02:25:58 (13 entries, sigma 01:01:29) (and builds the most kernels, plus arch: all)
<lamont> amd64: linux-source-2.6.10_2.6.10-25.1_20050309-2037 01:23:13 (12 entries, sigma 00:40:43)
<thom> ia64 takes 7 hours?!?
<lamont> thom: it's a P-O-S box
<lamont> thom: 1GHz CPU, 2GB RAM
<lamont> and _SLOW_ disks
<lamont> uniprocessor
<thom> true
<lamont> but it is itanium2
<lamont> oh, and minimal cache
<T-Bone> lamont: IDE?
<ogra_live> jdub, is it intentional that gstreamer-properties is in the desktop settings ?
<lamont> T-Bone: dev/hda is the CDROM, and there is /dev/sda*, so, no.
<T-Bone> then why "slow"?
<jdub> ogra_live: it will be out before final
<ogra_live> ah, good
<lamont> because it's special?
<lamont> zx1600, iirc
<T-Bone> lamont: i2 comes at least with 10k disks, neh?
<lamont> T-Bone: 10k is _SLOW_
<T-Bone> 1600? Does such a thing exist? :)
<T-Bone> lamont: hell. I wonder how you describe the Xserve G5 SATA disks then :)
<Kamion> lamont: could you please kick a d-i build on ross once the powerpc kernel reaches the archive, and ask mdz to byhand it?
<lamont> T-Bone: take itanium 2 products from HP.  find the lowest price point.  that's the one in the data center
<lamont> certainly
<lamont> the others are done already?
<T-Bone> lamont: can't be. IDE disks on i2 *are* slow
<Kamion> i386 and amd64 are
<Kamion> ia64, obviously, will have to wait
<lamont> T-Bone: those disks are scsi
<T-Bone> lamont: in the xserve?
<Kamion> lamont: hmm. elmo didn't byhand this morning's d-i builds, at my request. Will that have confused things?
#ubuntu-devel 2006-03-13
<nictuku> hi
<LaserJock> hi
<nate__> hallo, can anyone point me to any resources that outline hacking the ubuntu install?  I'd like to customize an install for forensics, possibly adding a package or two
<Burgwork> nate__, search the wiki for customizing install cds
<nate__> Burgwork, thanks :D
<whiprush> Burgwork: ping
<Burgwork> whiprush, pong
<whiprush> Burgwork: hey what was that filtering extension you mentioned the other day?
<Burgwork> whiprush, filtering extension to what?
<Burgwork> whiprush, the one that ogra wants to package? Willow
<whiprush> yeah
<whiprush> thanks
<Burgwork> if you package that, I will love you forever (well, maybe not)
<infinity> slomo: Done.
<slomo> infinity: thanks
<Mez> infinity, got chance to look at that code yet 
<infinity> Mez: Nah, launchpad ate my baby.  I can look at it right nowish, whilst waking up.
<Mez> infinity, cool
<Mez> you need the link again?
<infinity> Nah, my irssi never forgets.
<nate__> Burgwork, I lub you
<Burgwork> nate__, really? wow
<nate__> Burgwork, that was PRECISELY what I was looking for and it has made my workload TONS lighter.
<ajmitch> infinity: just waking up now?
<Burgwork> nate__, now can you write a pygtk tool to make the process easier?
<infinity> ajmitch: *grunt*
<infinity> ajmitch: was up late last night (and technically, I work from 11am to 7pm, cause I just hate mornings THAT MUCH)
<ajmitch> I can sympathise with that
<nate__> Burgwork, let me get on that.....sometime in the next century.....
<Burgwork> nate__, ok
<nate__> Burgwork, but I wouldn't mind some better GUI development IDEs myself, tell me if you come accross any that are worth their salt.
<slomo> infinity: failed again... seems to be a buildd failure... http://librarian.launchpad.net/1663088/buildlog_ubuntu-dapper-powerpc.liboil_0.3.7-0ubuntu4_FAILEDTOBUILD.txt.gz
<nate__> Burgwork, I even bought komodo from activestate...what a wasted $300
<slomo> infinity: all other builds on ross fail the same way
<infinity> slomo: I know.  Fixing.
* nate__ wishes he knew enough to be a developer....good thing we have YOU guys :D
<dAndy> Kamion: you around?
<Burgwork> whiprush, are you looking at using that for detriot?
<Burgwork> whiprush, s/that/willow
<nate__> anyone know this?  If I have a remote and a local repository for the same section in the sources.list, 'breezy' for instance, if the remote connection fails, will it failover to the local one?
<tseng> are they both breezy main?
<tseng> im not sure apt would be very happy if they were
<nate__> yeah
<nate__> so if i have breezy main universe multiverse resticted
<nate__> will it fail over?
<tseng> it doesnt complain like I thought
<nate__> ok, but that doesn't speak to failover :)
<nate__> thanks for checkin it out then
<nate__> then = though*
<infinity> Yes, it fails over gracefully if the remote repo is unreachable or if the remote repo throws a 404 for a file.
<nate__> SWEET :D
<infinity> (Well, "remote/local" is meaningless, it starts at the top of the list, and works its way down)
<nate__> thanks
<nate__> infinity: i lub you, have my babies.  that's sooooooo awesome, it makes my job even easier
<infinity> I tend to use that feature in the opposite way, by having my local mirror first, then archive.ubuntu.com second.
<nate__> yeah, that's what i'm gonna do
<infinity> So, if my mirror isn't fresh, is broken, or whatever, I fallback to grabbing files over the slow link to archive (which is always "right")
<nate__> so if they take it home
<infinity> Our installer does the same thing if you install from CD.
<infinity> You'll not it lists the CD entry first, then the http://archive entries.
<infinity> So, if your CD doesn't have the right files (not enough space, or they've been updated for security), it falls back to getting it from the network.
<infinity> s/not it lists/note it lists/
<nate__> coolness
<infinity> Also, I don't want to be a jerk (even if I often am), but these softs of questions should really be asked in #ubuntu... #ubuntu-devel is for development of Ubuntu, not a "talk to the developers about stuff" channel.
<nate__> awwww ;D
<infinity> s/softs/sorts/
<infinity> I really need to learn to type.
<nate__> i know what ya mean
<nate__> Well, I'm developing a forensics distro based on ubuntu and wanted to know how that worked because of we would prefer to keep their boxes off the network, but if they did want to take them home we wouldn't want apt to break
<nate__> so it actually is development related
<nate__> but maybe not related in the way this channel was intended for :D
<nate__> so ignore me..
<joelbryan> how do I post images from wiki?
<Burgundavia> joelbryan: you mean upload them to the wiki?
<joelbryan> Burgundavia: yes! as attachment.
<Burgundavia> joelbryan: go to the page you want to add the image to. In the middle of hte screen, there is a drop down menu. Choose "Upload attachment" (I don't remember the exact wording)
<joelbryan> Burgundavia: is it available while editing the page?
<Burgundavia> joelbryan: finish editing, the upload
<joelbryan> then upload
<joelbryan> Burgundavia: It's on ubuntu wiki, I 
<joelbryan> I can't see any link
<Burgundavia> do you see the "more actions" drop down
<Burgundavia> ?
<joelbryan> Burgundavia: thanks! man, I got it!
<Burgundavia> joelbryan: np
<wasabi> Hahah nice.
<corey_> wasabi: hmm?
<wasabi> my gf said she got a pop up message saying that a drive was full
<Burgundavia> that message needs to be tweaks
<Burgundavia> ed\
<wasabi> Is there such a message?
<wasabi> I haven't seen it yet.
<irvin> wasabi, afaik there is on dapper
<wasabi> I think then it popped up and said our CD was full.
<wasabi> Which, as most ROMs go, is true. ;)
<ajmitch> yes, and it'll hopefully be disabled/configurable soon
<wasabi> That's what she says anyways.
<wasabi> What component is responsible for the notification?
<Burgundavia> wasabi: I believe it is gnome-volume-manager and I believe a bug has already been filed
<Kyral> Okay....are there any reports of major breakage?
<Mez> Kyral: are you having major breakage 
<Mez> ??
<Kyral> yah
<Kyral> like most of GNOME freaking out
<Kyral> I try to start GNOME and a crapload of errors come up
<Mez> Kyral, define "freaking out"
<Mez> Kyral, are you on ia32 /
<Mez> ?
<Kyral> Yah
<Kyral> x86
<Mez> yes or no to ia32 ?
<Kyral> Like suddenly NONE of my panel apps come up
<Kyral> ia32 == x86 last I knew
<Kyral> KDE works fine
<Kyral> but it seems like any GTK app fails
<Mez> when did you update and get these problems
<Mez> and when did you update before then ?
<Kyral> I'm up to date NOW
<Mez> so I can narrow it down
<Kyral> I've been updating everyday
<Kyral> I just noticed it today because I have been using KDE for the past two days
<Mez> doko: ping
<Kyral> and it worked then :P
<Kyral> brb switching over to Konversation
<Kyral> Wierd...they seem to work in KDE...
<Kyral> maybe...could it be the Compositors for XFCE and MetaCity acting up?
<Drac[Server] > Hi. you're going to hate me for this, but I'm afraid the idiots in #ubuntu will only give me X-based support. How the hell do I adjust the keyboard layout for the console? I need to enable USB keyboard support!
<LaserJock> Drac[Server] : I would think "dpkg-reconfigure" might help
<Drac[Server] > Yes, but for what?
<Drac[Server] > What package?
<LaserJock> seems like xorg-server or something like that
<Drac[Server] > ...
<Drac[Server] > What part of CONSOLE do people not understand?! D:
<LaserJock> xorg-xserver
<Drac[Server] > I need to change the CONSOLE'S keyboard layour.
<LaserJock> locale perhaps then
<Drac[Server] > It's xserver-xorg, and that's for X! I don't want to know how to change X's keyboard layout! I want to know how to make the console see my USB keyboard!
<infinity> Drac[Server] : Your attitude's probably not helping much, but what you want is dpkg-reconfigure console-data.
<Kyral> Thats a hardware detection problem
<LaserJock> infinity: ++
<infinity> Drac[Server] : Can you please leave the anger at home the next time you feel the urge to seek free support from "idiots"?
<Drac[Server] > I've been asking for 30 minutes.
<infinity> Drac[Server] : OTOH, if the keyboard isn't working at all, you're likely lacking some hotplug/udev magic to make it go when you plug it in.
<Drac[Server] > Everyone keeps telling me that I should reconfigure X.
<LaserJock> Drac[Server] : well, honestly that is usually what people want
<Drac[Server] > The USB keyboard worked fine when the installer was running. Why doesn't it now?
<Drac[Server] > ...
* Kyral twitches at Drac[Server] 
<Drac[Server] > I unplugged it, plugged it back in, and it worked...
<Kyral> Yanno, I'm gonna leave now before I go BOFH
<Drac[Server] > I've been a little bitch about this. Sorry.
<LaserJock> Kyral: settle down boy ;-)
<Drac[Server] > I'm eager to finish this project.
<Drac[Server] > I'm putting an AT machine in a Tandy 1000 case. :D
<Kyral> LaserJock: I'm tired and I have an exam tomorrow, and its like 4 days 'til break
<Drac[Server] > Thanks for the support. :)
<LaserJock> Kyral: maybe you need to go packages something ;-)
<LaserJock> hmm, ok then
<LaserJock> thanks infinity 
<wasabi> So, any AppArmor asperations? :)
<Burgundavia> wasabi: ajmitch is the person to talk to 
<wasabi> k
<ajmitch> Burgundavia: thanks..
<wasabi> Heh.
<wasabi> I'm reading the docs on it now.
<Burgundavia> ajmitch: do I sense some sarcasm?
<ajmitch> Burgundavia: yes
<Burgundavia> ajmitch: I figured it would be better if you shot him down
<wasabi> Heh.
<wasabi> So why not, or why not so?
<Burgundavia> wasabi: basically because selinux is established and apparmour is not
<wasabi> Didn't think SELInux covered the same use cases.
<ajmitch> it covers all apparmor does & more
<ajmitch> the '& more' part happens to be useful
<wasabi> k
<wasabi> Well, I'm just excited about the prospect of the distro (ya'll) being able to distribute a profile for each application which defines what it should have access to.
<ajmitch> which is what we're doing with selinux & modular policy
<wasabi> cool. ;0
<ajmitch> just don't expect to see much in dapper
<wasabi> Completely different subject:  Anybody aware of a pam module for recursive group memberships?
* desrt uses his WPA home network from his dapper G4 powerbook without a PCMCIA card
<ajmitch> desrt: broadcom driver working nicely then?
<desrt> ajmitch; it's a bit unstable.  my ssh connection seems to die randomly and i have to stop/restart wpa_supplicant and reconnect
<desrt> ajmitch; it's been fine for the past 10 mins or so, though
<desrt> all told it makes me pretty darn happy
<ajmitch> I should pester BenC to get the latest ipw2200 driver in, if possible
<ajmitch> should be enough time to get some testing in before kernel freeze
<desrt> what is ipw2200?
<infinity> Intel Pro Wireless 2200
<ajmitch> intel driver, popular in many laptops these days
<desrt> gotcha
<infinity> (and 2915)
<desrt> i have a bad attitude
<infinity> Oh!  They released a new stable release of ipw2200.  Interesting.
<desrt> i'm very much of the "to hell with freezes, i want new everything" mindset
<ajmitch> infinity: that's mainly why I want it, it apparantly fixes a few bugs
<infinity> I certainly wouldn't mind it on my 2915 either.
<Burgundavia> desrt: you couldn't be part of the that, could you?
<desrt> the that?
<nictuku> infinity, yeah that was mentioned in the ubuntu-devel list 
<joelbryan> will the OpenOffice splash screens be changed in final version?
<Burgundavia> joelbryan: nope
<Burgundavia> ;)
<Gagatan> wasabi: I think the later pam/nss-ldap from padl.com supports recursive group memberships
<joelbryan> Burgundavia: why?
<Burgundavia> joelbryan: I am kidding
<pitti> Good morning
<ajmitch> hey pitti 
<ajmitch> how's it going?
<joelbryan> :-)
<joelbryan> look at this, https://wiki.ubuntu.com/DapperArtUserProposals/OpenOfficeSplash
<pitti> ajmitch: hi! great :) and you?
<ajmitch> still alive, I think
<Burgundavia> joelbryan: those look cool
<joelbryan> really?! wow
* ajmitch saw them earlier, today, was impressed
<ajmitch> though I'd like it if it was easily selectable, since I don't use brown on my box :)
<Lathiat> bottom one is the best (fits the theme best)
<Lathiat> personally i like the blue tho..
<Lathiat> i noticed ubununtu on "the real hustle" the other day
<Burgundavia> oh, where?'
<ajmitch> ?
<Lathiat> some uk bbc tv show where they go and scam people, then give them ther emoney back and tell them
<Lathiat> they did a wifi scam
<Lathiat> setting up a faek AP
<Lathiat> with fake credit card GW
<Lathiat> in episode 3
<Lathiat> i think it was ubuntu
<Lathiat> had the screensaver dialog
<Lathiat> that i only saw in ubuntu
<Lathiat> the gnome one from breezy i think it is
<joelbryan> yeah, that sux, people are using ubuntu ship-it cd's for spam purposes.
<joelbryan> like my friend receive a package mail, with an ubuntu cd and a spam mail.
<jdub> joelbryan: was the CD ordered from shipit?
<joelbryan> yes
<joelbryan> it's hoary 5.04
<jdub> joelbryan: what was the 'spam'?
<joelbryan> it's about insurance
<pitti> hi Huahua 
<jdub> joelbryan: did it include a cover letter?
<Huahua> hi, pitti 
<joelbryan> yeah, I'll ask my friend about it.
<joelbryan> I'll tell you every detail about the mail
<joelbryan> jdub: I need to contact him if he still got the mail, I only know that it's version 5.04, and a insurance plans.
<jdub> joelbryan: thanks
<joelbryan> I'm trying to add a theme for the shutdown dialog, what source should I get?
<joelbryan> I mean, I will try to add a theme
<desrt> joelbryan; gnome-panel
<joelbryan> desrt: is gnome-session included too?
<desrt> actually, now that you mention it, i'm not sure
<desrt> it's one of the two
<pitti> hi desrt 
<joelbryan> thanks
<desrt> hello
<desrt> where do you live?
<highvoltage> jdub: hi
* desrt pokes pitti a bit
<pitti> *eek*
<pitti> desrt: btw, thanks for your unmount dialog - I modified it a bit and put it into nautilus yesterday
<desrt> oh.  freakin' awesome.
<desrt> gonna be in dapper?
<pitti> yes, it was overdue
<desrt> you get 3 cool points for that
<pitti> desrt: it *is* in dapper :) seb128 will beautify it a bit, but it works
<ajmitch> only 3 points?
<desrt> ajmitch; i don't want to encourage overinflation
<desrt> ajmitch; cool points are worth a lot :)
<ajmitch> I need to earn some
<desrt> getting muine-shell into main would earn you a couple :)
<joelbryan> desrt: how do I see the unmount dialog?
<pitti> joelbryan: well, unmount a removable device :)
<pitti> joelbryan: it's not actually a 'dialog', just a warning window
<ajmitch> desrt: probably too late for that
<desrt> pitti; it appears not to have hit the archives yet
<desrt> ajmitch; which is why you'd get cool points.  it would be a slightly heroic act.
<ajmitch> desrt: and it'd be up to pitti, so he'd deserve the points as well
<desrt> it's seriously up to pitti?
<pitti> desrt: hm, FTBFS on powerpc...
<desrt> i've seen that acronym earlier tonight.  what does it mean?
<ajmitch> pitti manages the main inclusion reports
* pitti is the main inclusion approval bitch
<desrt> oh.  this is more suited for universe, i think
<joelbryan> that's cool, it's says "Writing data to CD-RW" and there's a pulsating progress bar.
<pitti> erm, CD-RW?
<infinity> desrt: Fails To Build From Source.
<desrt> infinity; a hah
<joelbryan> there's just eject, but not unmount?
<joelbryan> when I right click in nautilus.
<pitti> infinity: 
<desrt> pitti; incidentally, i first wrote that dialog on a powerpc
<pitti> sh: /dev/null: Permission denied
<pitti> infinity: WTF??
<jdub> highvoltage: pong
<desrt> crw-rw-rw- 1 root root 1, 3 2006-03-02 10:36 /dev/null
<pitti> desrt: oh, the code itself is fine, just seems to be a stupid problem on the buildd
<desrt> freshly upgraded and rebooted about an hour ago ^^
<infinity> pitti: Already given-back.
<pitti> infinity: ah, thanks
<pitti> infinity: oh ia64, too?
<desrt> goodnight guys
<infinity> pitti: There's a really subtle bug somewhere in something that occasionally (you'll love this one) breaks out of the buildd chroots and resets permissions on /dev/null in the base system.
<desrt> ajmitch; earn your cool points.
* desrt falls into bed
<pitti> infinity: that sounds cool
<pitti> infinity: cprov asked me to modify pkgstriptranslations to copy the tarball out of the chroot
<pitti> infinity: so you need to teach me about this one :)
<infinity> Uhm, say what?
<pitti> infinity: seriously, would it be possible to reenable the sbuild hack to get tarballs exported again?
<infinity> Did he know what he was asking? :)
<infinity> I didn't DISABLE the hack...
<pitti> infinity: I explained it :)
<infinity> Let me look at it again.
<infinity> (Are the uploaded tarballs not quite cutting it yet?)
<pitti> infinity: well, rosetta still has some problems with their import
<infinity> Joy.
<pitti> infinity: carlos had to completely rewrite the import queue, this needs a review and rollout
<pitti> infinity: so I'd just like to have a fallback :)
<infinity> pitti: Yeah, uhm, the hack is still there, unmodified...
<infinity> pitti: Hasn't changed since the wanna-build days.
<jdub> robitaille: posted the dell thing on the fridge - to the front page, too ;)
<pitti> hmm, odd
<pitti> infinity: any idea why they don't get exported any more?
<jdub> anyone tried dapper on top of linux 2.4?
<robitaille> jdub: that's great
<infinity> pitti: I dunno, but I blame you. :)
<infinity> pitti: (looking)
* pitti hugs infinity 
<pitti> (and gives him a decent poke in the side for the blame)
<infinity> pitti: They stopped exporting right after the last upload, so I dunno... Coincidence? :)
<pitti> infinity: 'last upload' of what?
<pitti> it stopped on Feb 25
<infinity> pitti: pkgstriptranslations
<pitti> this might have been the day we switched to the dpkg-distaddfile method
<infinity> It was.
<pitti> so, the additional .changes entry confuses sbuild?
<infinity> At least, if your changelog can be trusted.
<pitti> yes, I think it can
<infinity> Oh, wait.
<infinity> Of course...
<infinity> I'll bet our call to export the tarball comes AFTER sbuild moves all the files (referenced in the .changes) from the chroot to the base system.
<infinity> Duh.
* infinity pokes at that theory.
<pitti> sounds plausible at least
<infinity> Immediately after, in fact.
<infinity> Which would seem to be the correct behaviour, had we wanted to switch completely from method A to method B...
<infinity> Which we apparently didn't. :/
<pitti> it's not like I wouldn't want to :/
<infinity> Right, well I'll just move our hideous hack up about 40 lines, and you'll get them back again.
<pitti> infinity: thanks
<pitti> hi mpt__ 
<mpt__> hi pitti 
<Vylar1978> Hi every one
<pitti> yes, my dear g-p-m, after telling me 5 times that my battery is charged, I *know* it now
* Lathiat laughs
<robitaille> hey, tonight my g-p-m didn't tell me that my battery was charged.  I miss having reminders every 30 seconds :)
<pitti> unfortunately the fixed version is ftbfs on powerpc - infinity, could you please try a g-b for g-p-m?
<ajmitch> robitaille: I only saw it once, I'm so unlucky
<zakame> hi all
<pitti> hi zakame 
<ajmitch> hey zakame 
<zakame> hello pitti ajmitch
<infinity> pitti: Given-back, though it may be a victim of an underlying library snag... We'll see.
<infinity> pitti: Fixed sbuild rolled out, for great translation justice.
<pitti> \o/
<joelbryan> I can't seems to find where logout is? I tried whereis logout
<infinity> joelbryan: It's a shell builtin.
<joelbryan> ok
<infinity> joelbryan: "help logout"
<joelbryan> i thought it was from gnome
<Burgundavia> joelbryan: you are talking about the ubuntu specific logout dialog?
<joelbryan> yes
<infinity> Oh, that's something entirely different. :)
<Burgundavia> that is gnome-session, no?
<freeflying> pitti: https://launchpad.net/malone/bugs/34054
<Ubugtu> malone bug 34054 in language-support-ko "language-support-ko needs to be depended on scim-gtk2-immodule" [Normal,Unconfirmed]  
<joelbryan> Burgundavia: yes, but it's the old logout dialog.
<pitti> freeflying: assigned to me, will fix soon
<pitti> hi carlos 
<Burgundavia> joelbryan: can you show me a screenshot of the dialog you want?
<carlos> pitti: hi
<freeflying> pitti: and also language-support-zh 
<pitti> freeflying: which bug?
<jdub> hrm
<jdub> bind comes up after ntpdate
<freeflying> pitti: need add the depends on scim-gtk2-immodlue to language-support-zh 
<jdub> which hurts for hosts that use local nameserver only
<joelbryan> Burgundavia: the new upstream version, with the logout, switch user, lock screen on top, and at the bottom sleep, hibernate, restart, shutdown.
<Burgundavia> joelbryan: the single dialog one? That is not upstream, that is ubuntu specific
<joelbryan> Burgundavia: and at the very bottom, there is a cancel button.
<fabbione> jdub: move ntp-date :)
<pitti> freeflying: ah, I see
<Burgundavia> joelbryan: yes, Manu cornet develops that. Probably best to chat with him about it (manu on irc)
<joelbryan> Burgundavia: what package is affected by that?
<freeflying> pitti: actually , an this be included in the install cd 
<freeflying> s/an/can
<joelbryan> Burgundavia: what package is that?, I can help him.
<freeflying> pitti: and put scim-qtimm in kubuntu's install cd 
<joelbryan> I think it's a good idea to make the fade-out screen brownish or maroon? what do you think?
<joelbryan> s/screen/effects/g
<Burgundavia> joelbryan: it is in gnome-session
<pitti> freeflying: ok, can you please add that to the bug report?
<freeflying> pitti: alright
<joelbryan> I compiled the latest gnome-session, but it's the old logout.
<Burgundavia> joelbryan: from where? gnome cvs or ubuntu sources?
<joelbryan> ubuntu sources
<freeflying> pitti: file a new one , or use the existed
<joelbryan> manu is not online, I like to talk to him, for making it pretty
<pitti> freeflying: just use the existing one for ko
<freeflying> pitti: thx
<joelbryan> and I like to share this. I'm fascinated about this observation, can you tell me if this has a sense at all, but when I /usr/lib/cat * > /dev/null everything works faster! tried it too in openoffice and firefox.
<infinity> joelbryan: You're reading files into memory (then throwing them away), so the disk cache is being seeded and you don't have to re-read from the disk the next time you access it.
<infinity> joelbryan: Nothing weird about it.
<infinity> joelbryan: As for gnome-session, I suspect you're building it with "make; make install", instead of using the debian packaging scripts (which would apply the debian patches)?
<joelbryan> I applied the debian patches
<joelbryan> sudo apt-get source packagename does apply the patches automatically.
<joelbryan> should it have a patch to cat everything in > /dev/null before GNOME starts up, or a cron job that does that every 30 minutes?
<joelbryan> hmm.. i'm working on it right now, using sed, if someone cares for it.
<infinity> joelbryan: No, it doesn't apply the patches automatically.
<infinity> joelbryan: See the "debian/patches" directory in the source.  If you used "dpkg-buildpackage", those patches would be automatically applied during build.
<Burgundavia> pitti: you seen this --> http://blog.fubar.dk/?p=66
<Treenaks> Burgundavia: but: is it crack?
<Burgundavia> Treenaks: no idea. I trust pitti to tell me that
<Burgundavia> seems sane, having less code running as root
* jdub is upgrading his server to dapper.
<jdub> i love dapper.
<jdub> fuck those other versions.
<jdub> they were crap.
<jdub> dapper is the one true ubuntu release.
<jdub> we can point at warty and laugh.
<jdub> we can also point at warty users and laugh.
<jdub> then help them upgrade.
<jdub> because we are givers of life.
<jdub> and brown.
<jdub> we are givers of brown.
<seb128> morning jdub :)
<seb128> did you get some sleep this week? :)
<dholbach> hey Jeff :-))))
<Burgundavia> jdub: just to keep people off balance, we shoudl change our colour scheme to green for dapper+1
<jdub> seb128: sleep is for the week.
<jdub> Burgundavia: funnily enough, i am doing a green theme at this very moment.
<seb128> jdub: weak you mean?
<highvoltage> Burgundavia: as long as it's not blue and green!
<Burgundavia> highvoltage: just straight green
<jdub> seb128: no, week.
<Tm_T> Mirv: indeed
<jdub> seb128: the weekend is for partying, which seldom involves sleep.
<seb128> right
<Burgundavia> jdub: this green theme. I assume we are talking about an option for dapper, not by default?
<pitti> Burgundavia: will look at it later, breakfast now :)
<seb128> pitti: morning
<dholbach> green is soooo *out*
<jdub> seb128: it is a stupid english pun. french puns are always better than english puns, because they involve an element of philosophy not understood by mere english speakers.
<seb128> pitti: even in that timezone you are up before me :)
<jdub> Burgundavia: i might not even bother packaging it
<Tm_T> dholbach: yeah, blue is always in, just look at KDE ;)
<jdub> Burgundavia: but then, i might stick it in for fun
<seb128> hey vuntz_
<Burgundavia> pitti: is 1am here. Need to go to bed my self
<jdub> Burgundavia: if people like it enough, it could even go in ubuntu-artwork
<jdub> but i doubt it
<dholbach> Tm_T: luckily we can have different opinions :)
<Tm_T> dholbach: and options )
<Burgundavia> jdub: I would love a good green theme for dapper. I am going to sell the idea of green to SILC when I meet with them tomorrow
* jdub doesn't want to put multiple themes in u-a if he can help it, but a funky green theme package would be good
<seb128> jdub: if you are doing it yourself people will LOVE IT
<Tm_T> dholbach: best part of it, you can have non-blue KDE ;)
<dholbach> Tm_T: oh, i thought that was hardcoded
<Tm_T> dholbach: me too
<Tm_T> but then I accidentally opened kcontrol ;(
<Tm_T> I will always regret that day
<jdub> seb128: i was thinking of doing some concept bits and then asking klepas or andreasn to do really slick versions (they are real artistes)
<Tm_T> jdub: when you have something ready, share a pic or something, I'm always interested to see different :)
<jdub> Tm_T: yeah, i will blog
<Kamion> pitti: have you already sorted out switching language-support-* over to the openoffice.org-* world (as opposed to openoffice.org2-*)?
<Tm_T> I have something yellow-green-grey thing going on in my desktop: http://www.tm-travolta.net/shots/current.png
<adamcasl> is dapper compiled i686 by default? i'm noticing cmov instructions in some of the /usr/bin binaries
<adamcasl> because that breaks stuff on via c3's
<infinity> Shouldn't be.
<infinity> Which binaries?
<adamcasl> objdump -D -a /usr/bin/* | grep -i cmov
<adamcasl>  808ee7b:       0f 4a 54 89 96          cmovp  0xffffff96(%ecx,%ecx,4),%edx
<adamcasl> hmm, now to figure out which one
<fabbione> adamcasl: for i in /usr/bin/*; do echo $i && objdump -D -a /usr/bin/* | grep -i cmov; done
<fabbione> the one that will have the grep is your binary
<fabbione> or
<fabbione> adamcasl: for i in /usr/bin/*; do if [ -n "$(objdump -D -a /usr/bin/* | grep -i cmov)" ] ; then echo $i; fi; done
<fabbione> ops
<fabbione> almost
<fabbione> adamcasl: for i in /usr/bin/*; do if [ -n "$(objdump -D -a /usr/bin/$i | grep -i cmov)" ] ; then echo $i; fi; done
<fabbione> there
<jdub> lamont: ping
<fabbione> adamcasl: use the very last one
<fabbione>  /usr/bin/a2p
<fabbione> there are a bunch
<adamcasl> fabbione: thanks
<adamcasl> there you go guys, looks like we've got i686 stuff there
<fabbione> infinity: change the objdump call to use $i instead of /usr/bin/$i
<adamcasl> and it breaks via c3 which sells heavily in asia low cost desktops
<siretart> anyone working on bug #30962?
<Ubugtu> malone bug 30962 in linux-source-2.6.15 "2G/2G kernels break many applications, including wine and lisp packages." [Normal,Confirmed]  http://launchpad.net/bugs/30962
<mjr> curious
<fabbione> siretart: yes. BenC 
<adamcasl> is there some way to tell the install to force i586
<siretart> ok
* infinity grumbles.
<infinity> Looks like we need doko for this one.
<pitti> re
<pitti> Kamion: yes, I did that last Sunday
<adamcasl> infinity: cool. well, i'm gonna go. if there's something i can do to help, let me know, i have a c3 inhouse
* highvoltage realises he has a c3 under his desk as well
<fabbione> wasn't cmov also in i486 =
<fabbione> =
<highvoltage> what's the best way to test platform support, is there a wiki page for that?
<adamcasl> fabbione: it's an optional extension
<highvoltage> or do you just boot and look if it works?
<fabbione> adamcasl: hmmmm
<fabbione> ok
<adamcasl> so via left it out
<fabbione> adamcasl: i see.... hmmm
<fabbione> adamcasl: are we sure that we don't emulate it in libc6?
<infinity> fabbione: No, that's why we have /usr/lib/i686 and /usr/lib/i686/cmov
<infinity> fabbione: The latter for machines that support cmov.
<joelbryan> Hi devs, check out https://wiki.ubuntu.com/CacheWarmUp, maybe some interesting stuff.
<infinity> I suspect something terribly wrong has gone on with GCC tuning.
<fabbione> infinity: but the linker should chose the right one automatically.. like for libc/v9v and libc/ultra3
<fabbione> and that's decided according to CPU HW CAP
<siretart> yay. mass rebuild the whole archive. sounds like fun!
<siretart> :/
<infinity> joelbryan: Check out the "readahead" package, we install it by default and it does exactly what you want.
<fabbione> adamcasl: can you please run this on one of these via c3? LD_SHOW_AUXV=1 /lib/libc.so.6 --version  | grep AT_HWCAP
<infinity> fabbione: Yes, the linker will choose the correct libraries.  Of course, if we're building incorrect binaries, that doesn't help.
<fabbione> infinity: yes i agree..
<fabbione> is the cmov call only cmov in asm?
<fabbione> or there are more variants like fcmovb ?
<joelbryan> man that is cool!
<jdub> joelbryan: ping
<doko> infinity, fabbione: unnice, looking ...
<fabbione> doko: if the function is really called  ONLY cmov, than we are fine
<fabbione> but if there are variants, like i said.. sucks to rebuild all the archive
<fabbione> (or almost)
<joelbryan> jdub: he says he can't find the mail.
<infinity> doko: For the record, we're building with "-mcpu=pentium4 -march=i486"
<infinity> doko: Which, afaik, should definitely not be generating cmov instructions.
* infinity goes out for food.
<joelbryan> I get a WARNING: unsafe ownership on configuration file `/home/joelbryan/.gnupg/gpg.conf' in dpkg-buildpackage
<joelbryan> should I export GPG=mygpgkeys?
<doko> infinity: you mean -mtune=pentium4 ?
<infinity> doko: Err, yes... tune... -mcpu was for gcc-3.3
<jdub> joelbryan: really would help if we knew more details - could you ask your friend to email shipit@ubuntu.com and tell them about it?
<infinity> doko: gcc-4.0 is called with "-mtune=pentium4 -march=i486"
<joelbryan> jdub: ok
<infinity> doko: Straight "gcc" and "g++" are called with no tune/arch options, since the cpu/tune thing changed over time and we can't really tell which to use.
<joelbryan> I'm using dpkg-buildpackage, but I get a gpg: WARNING: unsafe ownership on configuration file `/home/joelbryan/.gnupg/gpg.conf' - what should I do?
<Kinnison> fix the permissions on that file?
<joelbryan> Kinnison: or i'll do a -rfakeroot
<Kinnison> oh gods, I didn't realise you weren't doing that
<Kinnison> sorry, my fingers find it hard to type dpkg-buildpackage on a commandline without adding -rfakeroot automagically
<joelbryan> I'm sorry, I didn't know anything about the -rfakeroot option, just browsed it in the internet.
<pitti> Kamion: I think poppler is in NEW since the lib got a new soname; can you please ack it? (not very urgent, though)
<Robot101> ogra: gnome-screensaver is locking my screen after 10 minutes even when I'm not idle :(
<mdz__> infinity: around?
<pitti> hey mdz__
<Kinnison> mjg59: I'm trying to do this gconftool mungery in g-p-m's postinst, but I can't work out how to tell it to set a systemwide setting
<mdz-sprint> pitti: good morning
<pitti> Kamion, Riddell: to provide good OOTB input support for Asian languages, we need to put scim and scim-gtk2-immodule (together ~ 850 kB) into ubuntu-desktop, and skim/scim-qtimm (together ~ 1.3 MB) to kubuntu-desktop; do you have objections to that?
<sivang> hi all
<pitti> hi sivang 
<freeflying> hi all can dapper be install from hdd ?
<Kamion> pitti: I'm fine with that for Ubuntu
<sivang> pitti: hey martin, what's up?
<freeflying> Kamion: can dapper support install from hdd
<Kamion> freeflying: not really
<Kamion> freeflying: but in any case you should look in the installation manual rather than asking me
<Kamion> http://doc.ubuntu.com/ubuntu/install/i386/
<freeflying> Kamion: because tmany guys ask me about that ,and they say it can not instal from hdd, so I wanna confirm from you
<Kamion> I'm afraid I am very busy at the moment and cannot provide personal support
<koke> mvo: I have a suggestion for gai I don't know how to implement by now
<koke> It'd be nice to have a better search function
<koke> I mean,  sorting results by relevance
<koke> if I put "thunder" in the search entry I get thunderbird as last option
<Kamion> pitti: poppler isn't in NEW at the moment
<pitti> hmm, seb128, where is it? ^
<jdub> koke: maybe we should beaglise gai ;)
<pitti> seb128: it built everywhere, but the debs are not in the archive
<seb128> pitti: don't ask me
<koke> jdub: someday beagle will be able to find anything in the house, but it's not the moment by now ;P
<pitti> Kinnison: could you please have a look what happened to poppler 0.5.1-0ubuntu1? it built everywhere yesterday, but no debs in the archive. it *should* be in NEW, but it isn't
<seb128> pitti: archive has 0.5.1 sources and no binary, I would say they are waiting in NEW if you ask me
<pitti> seb128: right, that's what I thought, too
<Kinnison> pitti: what suite?
<pitti> Kinnison: dapper/main
<Kinnison> hmm
<ogra> Robot101, generally or only after suspend ?
<seb128> Kinnison: some soname change over previous version
<seb128> Kinnison: so dunno where new binaries go by default
<Robot101> ogra: hm, this was after a suspend/resume
<ogra> Robot101, can you follow up on bug 33539 ?
<Ubugtu> malone bug 33539 in gnome-screensaver "doesn't seem to detect activity after resuming from suspend" [Normal,Unconfirmed]  http://launchpad.net/bugs/33539
<ogra> i suspect we have a communication problem between g-p-m and g-s-s
<ogra> g-p-m seems to ignore if g-s-s isnt locked and suspends the screen anyway ...
<ogra> Kinnison, ? ^^
<Mithrandir> ogra: g-p-m wasn't running, so should be irrelevant
<Kinnison> ogra: g-p-m only does the lock-screen action if g-ss signals it to go idle
<ogra> Mithrandir, i heard this very often recently ...
<Mithrandir> ogra: dude, I filed 33539
<ogra> Mithrandir, i heard very often that it happened and that it was solved through killing g-p-m, might not be exactly your bug but thats what i see very often
<Mithrandir> sure, but 33539 has nothing to do with g-p-m
<Mithrandir> unless you're accusing it of being psychic or something. :-)
<ogra> Robot101, so please file a separate bug then ...
<Kinnison> pitti: they all got rejected during accept phase
<Kinnison> pitti: exception: 'Description'
* Kinnison investigates what that could be
* pitti blames seb128
<pitti> seb128: (just kidding *hug*)
<Robot101> ogra: er, what makes you think that my bug *is* due to g-p-m when Mithrandir's isn't?
<Robot101> ogra: surely the simpler explanation is just that g-s-s is broken at detecting idleness? :P
<ogra> Robot101, follow up there or open a new one as you think it is related *sigh*
<seb128> pitti: iz gtk bog? :)
<MrFaber> hi all
<ogra> it apparently happens only after suspend, so it must be suspend related ...
<MrFaber> Does anyone useing module assistant?
<Mithrandir> Robot101: I don't know about your system, but I experience the bug independent of g-p-m.  If you only see it with g-p-m, it's another bug, I suspect.
<ogra> according to many people who had it is disappears after killing g-p-m
<Robot101> ogra: yes, but it can be broken inside of itself, maybe to do with the clock skipping or something, without needing to interact with g-p-m to become broken :P
<Robot101> Mithrandir: I've not stopped g-p-m to determine whether it is or not
<Mithrandir> Robot101: g-p-m stopped all by itself for me. :-P
<ogra> Robot101, so if it occurs and g-p-m is running, please chack if killing it fixes it ...
<Kinnison> pitti: Is it possible that those binaries lack 'Description' control files?
<Robot101> ogra: doing so now
<Kamion> +Depends: ${shlibs:Depends}, ${misc:Depends}
<Kamion> +       Description: PDF rendering library
<Kamion> broken control file
<Kinnison> pitti: In fact, libpoppler1 lacks a Description, thus the upload was rejected
<Kinnison> Kamion: star
<ogra> Robot101, thanks 
<Kinnison> Kamion: do you have problems with your livecd test machine saying "no space left on device" when it clearly has over 100 megs of free ram?
<Kamion> Kinnison: it does seem to run out unconscionably early
<Kamion> look at 'df /'
<Kinnison> Kamion: it seems 320 megs isn't enough for compiling etc
<Kinnison> Kamion: which is really annoying because if I give it 512 megs, my host machine runs like a sedated dead dog being pulled backwards
<Kinnison> At this rate, I'm gonna have to expense a 1G SODIMM
<Mithrandir> Kinnison: tmpfs-es will only use half your total memory.
<Kamion> does something in between work?
<Robot101> grrr
<Robot101> now its not happening
<Kinnison> Mithrandir: Erm, I want it to use the swap I provided it with
<Kinnison> Mithrandir: any way for it to do that?
<Mithrandir> Kinnison: it should do that automatically, I thought.
<Kinnison> well it's not
<Kinnison> this is most irritating
* Kinnison will build on the host for now
<Kinnison> that'll make things easier
<Kinnison> seb128: how do I set a systemwide gconf setting from a postinst?
<pitti> Kamion: can you please promote scim-gtk2-immodule to main so that I can update the metapackages?
<Kamion> pitti: I need to wait for cprov to get up before I can use change-override.py, I'm afraid
<pitti> Kamion: ah, I see
<Kamion> it's still pointing to emperor and I don't have write access to the file in question
<ogra> Robot101, i wont fix it today :) take your time to reproduce it ;)
<Kamion> although it's fixed in infinity's branch
<seb128> Kinnison: what do you mean?
<Kinnison> seb128: in g-p-m's postinst, I need to do some prodding of the host machine and decide whether or not to enable suspend to ram
<Kinnison> seb128: having decided, I need to set a gconf key which will be picked up in the user session
<seb128> ah
<seb128> Kinnison: modify the schemas before it's registred?
<sivang> can anyone remind me how I can "detach" from an xdmcp login so the remote desktop wil continue running and I can go back to my local one?
<seb128> Kinnison: the postinst does the schemas registration which have the default values for the keys for the app
<sivang> (I recall there was a hot key combination)
<Robot101> sivang: do you just mean switching VT's to the local session?
<Kinnison> seb128: yuck, you're seriously advocating futzing with the schema?
<Kinnison> seb128: there's no better way?
<seb128> Kinnison: there is plenty of ways
<seb128> Kinnison: you can use a .gconf-default too
<Kinnison> how does that come into play?
<seb128> Kinnison: or you can set you key with a call to gconftool-2 --set
<sivang> Robot101: sort of, but getting back to my local GDM/ XScreenSaver lock screen :)
<Kinnison> seb128: running gconftool-2 --set as root doesn't seem to set a systemwide key, but rather root's key
<seb128> Kinnison: you need to use --direct
<seb128> Kinnison: gconftool-2 --direct --config-source xml:readwrite:/var/lib/gconf/defaults --type ... --set ...
<ogra> maswan, what was the url with the iso download stats on teh .se mirror ? (i tend to loose it)
<Lathiat> www.acc.umu.se
<Kinnison> seb128: doesn't seem to have been noticed by my session, should it be?
<Lathiat> should be able to find it from there
<Lathiat> http://www.acc.umu.se/technical/statistics/ftp/index.html.en
<jono_> hey
<ogra> Lathiat, ta
<infinity> mdz-sprint: I'm vaguely around now.
<MrFaber_> Does anyone have used module assistant in dapper?
<mdz-sprint> infinity: sabdfl is asking for quickfile, offline (if not built in in 1.5), and typeahead find thunderbird extensions to be included by default in ubuntu
<mvo> koke: hello, sorry for the lag. what idea for g-a-i?
<infinity> mdz-sprint: Offline is builtin, typaheadfind is in main (does he want it in the main package instead of as an extension, then?), and I have no idea about quickfile.
<Mithrandir> I don't think quickfile is packaged.
<koke> mvo: I've written it before
<infinity> mdz-sprint: Speaking of "on by default" extensions, I wouldn't mind adding "redirect" (UNIX-style bouncing), since it's the first thing I ask people to install to debug broken email. :)
<infinity> mdz-sprint: Though I'd be fine with a FF exception to package it and get it in the archive, having it builtin might confuse some users.
<mdz-sprint> infinity: please find out about quickfile; that's one that mark funded, I believe
<mdz-sprint> if typeahead find is already packaged, perhaps adding it as a dependency would be the right thing
<infinity> Ahh, indeed he has funded it, according to http://www.paultomlin.com/projects/mozilla/thunderbird/quickfile/
<infinity> mdz-sprint: Well, it's built from the main source package, so if we want it as a dependency, we may as well just have it in the package.
<infinity> mdz-sprint: Though, the behavior is irritating enough (to some) to justify it being a seperate package, IMO...
<infinity> (ie: I don't like it and don't have it installed)
<infinity> mdz-sprint: quickfile's not had a release since early last year, I doubt it supports tbird 1.5... But I can give it a spin tomorrow.
<slomo_> infinity: two of my uploads from yesterday are not in the archives yet although they built fine hours ago... known problem?
<infinity> mdz-sprint: Oh, nevermind, he claims it works on 1.5... I'll spin it tomorrow and see about packaging it.
<mdz-sprint> infinity: oh, it's the same source? hmm
<mdz-sprint> infinity: I'm pretty sure mark is using it with 1.5 today
<infinity> mdz-sprint: Yeah, I assumed as much, hence my confusion until I found the comment about "updating the installer to support 1.5"
<infinity> mdz-sprint: Anyhow, I'll give it a spin as a package tomorrow and see about including it.
<Mithrandir> infinity: it definitively works on 1.5; I've used it.
<infinity> mdz-sprint: Would Mark be happy with Recommends as a strong enough way to get the "default extensions" on people's desktops without pissing people like me off who might not want them? :)
<infinity> Mithrandir: Cool.
<Mithrandir> infinity: very useful for having M-q as a quick way to move junk to my spam folder. :-P
<infinity> slomo_: How many hours ago did they build fine?
<infinity> slomo_: The publisher cycle isn't the fastest thing around, but if it's actually not publishing anything, cprov would like to hear about it, I'm sure.
<slomo_> infinity: one of them more than 12 hours ago, the other > 8 hours
<jono_> are we in UI freeze now?
<ogra> jono_, tomorrow
<jono_> ogra, ahh cool
<mdz-sprint> jono_: wiki.ubuntu.com/DapperReleaseSchedule
<jono_> the splash screen cracks me up
<jono_> mdke, cheers :)
<jono_> oops
<jono_> mdz-sprint, cheers :)
<jono_> mdz-sprint, where is the sprint at?
<mdz-sprint> London
<jono_> mdz-sprint, ahhh cool
<MrFaber_> Does anyone useing debian module-assistant in dapper or has used it?
<tepsipakki> MrFaber_: works with lirc-modules
<seb128> Kinnison: sorry, network issue
<seb128> I was saying
<seb128> <seb128> Kinnison: you need to restart gconfd-2
<seb128> <seb128> a sighup should be enough
<seb128> <seb128> Kinnison: other way we have the .gconf-default stuff now. you put package.gconf-defaults with "/apps/your_app/a_key value" to your debian directory, and it's installed to /usr/share/gconf/defaults, dh_gconf has the magic to register it and it's used before the upstream values
<seb128> <seb128> Kinnison: we do use that for CDD
<torkel> MrFaber_: and for openafs-modules
<infinity> mdz-sprint: I need to head to bed.  I'll make a note to package quickfile tomorrow and then ping you/Mark about where we want to go from there, alright?
<mdz-sprint> infinity: good, thanks
<MrFaber_> tepsipakki, doesn work with nvidia, fglrx and loop-aes
<MrFaber_> I have only tested it with loop-aes but another one with nvidia and fglrx
<MrFaber_> always the same error
<MrFaber_> tepsipakki, torkel in dapper?
<MrFaber_> In Breezy everything works fine, but not in dapper.
<torkel> MrFaber_: yes
<MrFaber_> torkel, a lirc-modules in repository?
<MrFaber_> *are
<tepsipakki> MrFaber: yes. why don't you use the nvidi/fglrx-modules provided by dapper?
<tepsipakki> +a
<MrFaber_> I have no problem with them only with loop-aes
<MrFaber_> a friend of mine has tested it with this one
<torkel> MrFaber_: I have only tried with openafs but it worked when I upgraded to the 17.2X kernel, and rebuilt the openafs modules
<MrFaber_> testing now the lirc modules in dapper
<MrFaber_> doesn't work but not the same error
<MrFaber_> I am useing "m-a a-i lirc-modules
<MrFaber_> "
<tepsipakki> I'm wondering, what would it need to make "official" lirc-modules packages for the current kernel? something like the resctricted-modules is..
<MrFaber_> torkel, ok, now testing openafs
<MrFaber_> torkel, how do you build them?
<MrFaber_> torkel, openafs seems to work
<MrFaber_> the first module in dapper
<torkel> MrFaber_: fakeroot module-assistat -t -u /scratch/afs build openafs
<MrFaber_> that works for me
<MrFaber_> torkel, can yo please test loop-aes if you have dapper?
<MrFaber_> sudo m-a a-i loop-aes
<MrFaber_> or your method, don't know if it works always
<MrFaber_> yes, openafs works fine
<torkel> MrFaber_: I don't have the kernel-source installed and I'm a bit short of time to fiddle with it to much right now. Sorry
<MrFaber_> torkel, np
<MrFaber_> thanks
<MrFaber_> torkel, btw a funny thing is that you can create loop-aes in debian sid without source, only with headers, but not in ubuntu
<torkel> MrFaber_: with the same versions of loop-aes and m-a in both distributions?
<MrFaber_> nomeata, different I think
<MrFaber_> *no
<torkel> MrFaber_: It might be an idea to try to build the debian version on ubuntu and see if that works
<Kamion> pitti: scim-gtk2-immodule done for next publisher run
<pitti> thank you
<MrFaber_> torkel, that could be a temporary solution
<ogra> Kamion, can you also do the missing bits for schooltool (they are approved by pitti) ... 
* ogra looks up the package names
<MrFaber_> torkel, loop-aes in debian sid is 3.1.c and in dapper 3.1b
<Kamion> ogra: nothing in anastacia mentions schooltool
<ogra> Kamion, python-mechanize and python-clientform
<ogra> err ... clientform and pullparser 
<ogra> mechanize is only blocked by one of them ...
<janimo> Kamion, don't forget the xfce bits ;)
<Kamion> janimo: currently blocked on a mail discussion about implications for Canonical support on having stuff we don't support in main
<Kamion> I'll deal with it as soon as possible *after* that discussion has completeed
<janimo> Kamion,ok
<ogra> Kamion, oh, and i just see python2.4-twisted-web2 isnt promoted yet as well (thought that was in already)...
<Kamion> ogra: python-mechanize and python-clientform promoted; python-pullparser is not mentioned in anastacia output
<MrFaber_> torkel, yes, debian sid loop-aes package works in dapper
<MrFaber_> so it is no fault of the module-assistant
<Kamion> ogra: twisted-web2 done too
<ogra> thanks :)
<Riddell> pitti: that's fine for kubuntu
<Riddell> pitti: qtparted is ready for main review when you can, so we can get espresso kde onto the cd
<pitti> Riddell: alright; I committed the necessary bits into the seeds; ogra or I will build new metapackages after the next publisher run
<pitti> Riddell: ok, doing right now
<MrFaber_> torkel, or anyone else, how to contact the loop-aes-source package builder?
<torkel> MrFaber_: file a bug? and/or try #ubuntu-motu as it is a package in universe
<pitti> Riddell: qtparted approved
<Riddell> pitti: thanks much
<Riddell> doko: do you know where the openoffice splash screen is?
<doko> Riddell: I cannot make an KDE specific one
<Riddell> doko: we know
<Riddell> but that's not what I asked :)
<Kamion> Riddell: and qtparted promoted
<Riddell> Kamion: thanks, I'll put kde-espresso in the seed
<doko> Riddell: I know
<Riddell> doko: so... do you know where it is?
<Riddell> is it only in the source?
<doko> Riddell: sure, it's in the source
<MrFaber_> torkel, I have made a bug report five weeks ago or something like that
<MrFaber_> Toadstool, but I am testing the channel, thanks
<doko> Riddell: that was all?
<Riddell> doko: where in the source?
<doko> ooo-build/src
<ogra> mdz-sprint, ping ... 
<joelbryan> Hi, I successfully implimented a shutdown logo, where will I send my modifications?
<HiddenWolf> joelbryan: you can ask in #dapper-look I guess. :)
<ogra> joelbryan, or file a bug and attach the patch
<joelbryan> how do I make a patch?
<MrFaber_> cu all
<lamont> jdub: ack - but running out the door momentarily
<lamont> jdub: go ahead and ramble on in /query - I'll be back on in 45-60 minutes, and will see it then.  meetings much of today, so spotty connectivity.
<jdub> lamont: wanted to ask about potential postfix bug, if i don't remember when you get back
<jdub> ok
<lamont> ok
<lamont> later
<fabbione> lamont: one sec.. still around?
<fabbione> lamont: never mind..
* fabbione will wait
<ogra> mdz-sprint, !
<mdz-sprint> ogra: ?
<ogra> mdz-sprint, could you take a look at bug 33732 ?
<Ubugtu> malone bug 33732 in initscripts "initscripts postinst should respect administrator settings and not overwrite changes in rcS.d" [Normal,Rejected]  http://launchpad.net/bugs/33732
<ogra> mdz-sprint, i'm not sure what to do, Keabuk told me he''ll reject it again if i'll repoen, but i dont think we should release this way
<Keybuk> when did I say I'd reject it again? ...
<ogra> when we talked last 
<Keybuk> no I didn't
<Keybuk> I said I didn't think it was a bug, I didn't say I'd play reopen/reject tennis
<ogra> then i did get you wrong ... that how i understood you ... sorry, my fault then
<Keybuk> I still don't think it's a bug though
<ogra> i do
<Keybuk> it's far more important that everyone's dapper machine boots, even if they've previously fiddled with the boot sequence imo
<ogra> if they did that, they must have skills to do it 
<ogra> i dont want any fschk stuff in a netbooting system ...
<Keybuk> if ltsp mucks around with init scripts, it has to do it on install as initscripts will create the symlinks
<Keybuk> so it also has to do it on upgrade, surely?
<ogra> it does it on install of the client chroot
<pitti> mdz-sprint: I would like to upload a new source package which provides locale packages for tbird 1.5; technically a new upstream version, so I'd like to get formal approval (the old locale packages can be removed, they don't work anyway)
<Keybuk> so can't that also do it on upgrade of the client chroot?
<ogra> upgrades should only be chroot /ltsproot apt-get dist-upgrade and not break the setup
<ogra> i wont write an upgrade tool ... 
<Keybuk> is it an install tool that changes the symlinks then?
<ogra> the biggest advantage our ltsp has over all others is the easy upgradeability 
<Keybuk> I assumed from your description that it was a script postinst
<ogra> we'll be in the redhat camp if you need a tool
<ogra> your postinst ...
<ogra> not mine :)
<Keybuk> what *removes* the symlinks?
<Lathiat> how can i tell why an install failed? im trying kubutnu daily and it does "Setting up kubunut-dekstop'.. and then "WARNING: configuration pkgsel failed with error code 1
<Keybuk> initscripts postinst will create all those symlinks
<Lathiat> postinst kubuntu-desktop fialed or something?
<Keybuk> so what in ltsp removes them again?
<Kamion> Lathiat: look further back
<Kamion> or post the entire /var/log/syslog somewhere that I can see it
<ogra> Keybuk:
<ogra>     for link in $RC_DIR; do
<ogra>         if [ ! $(echo $link|grep ^K) ] ; then
<ogra>             name=$(echo $link|sed s/^[S,K,0-9] *//g)
<ogra>             printf -v seq_number %.2s $(echo $link|sed s/[a-z,\.,S,K,-] *//g)
<ogra>             if [ ! README = $name ] ; then
<ogra>                 chroot $ROOT update-rc.d -f $name remove 2>&1 >/dev/null
<ogra>                 chroot $ROOT update-rc.d $name stop $seq_number $suffix . 2>&1 >/dev/null
<Lathiat> how can i get the syslog out of the installer environment?
<ogra>             fi
<ogra>         fi
<ogra>     done
<Lathiat> wonder if scp is installed in the chroot now
<Kamion> Lathiat: go back to main menu, select "Save debug logs"
<Keybuk> ogra: where's that code?
<Kamion> Lathiat: or anna-install openssh-client-udeb outside the chroot
<mjg59> Kamion: mdz-sprint: I'd be happy moving to the new ipw2200 release. They've been good at avoiding regressions, and for the people the firmware restarting bug hits the machine is basically unusable.
<Kamion> (to get scp)
<mdz-sprint> ogra: ltsp should deal with the init stuff at boot time in order to handle the chroot being upgraded
<Lathiat> whoah
<ogra> Keybuk, ltsp-build-client in ltsp-server
<Lathiat> it can start a web server
<Lathiat> wth is that running?
<ogra> mdz-sprint, if all works as documented there is no need
<Kamion> Lathiat: it's a web server in busybox sh
<Keybuk> ogra: ok, so it's an "install tool" then; I assumed you'd put that in the ltsp postinst or something
<Kamion> don't ask :)
<mdz-sprint> pitti: tbird locale packages -> fine
<ogra> Keybuk, its the bottsrap for the client chroot 
<Kamion> well, sh and nc
<mdz-sprint> ogra: ltsp shouldn't use update-rc.d for this
<ogra> mdz-sprint, update-rc.d guarantees that symlinks with a K are not touched ...
<ogra> if we break that behavior...
<Keybuk> ogra: you'd still get the extra init scripts added though
<Lathiat> seems to be a bunch of errors relate dto bluez-cups/cups
<mdz-sprint> Keybuk: can you explain what the issue is which risks the system not booting properly?
<ogra> Keybuk, i just dont want the ones re enabled that i just disabled
<ogra> since that guaranteed behavior ...
<Keybuk> mdz-sprint: people who've moved around init scripts to try and make their boot faster.  if we tested for the exact numeric existance of a script first, and only moved it if it wasn't already moved/removed, then that user would end up with a practically random order boot which would likely not work
<Lathiat> http://bur.st/~lathiat/syslog
<Lathiat> still uploading hold a sec
<ogra> if it changed we should tell that in the manpage instead of giving a not working example how to disable system initscripts
<Lathiat> done
<ogra> many users rely on that behavior though ...
<Keybuk> ogra: initscripts postinst has *always* done this
<ogra> Keybuk, it doesnt in debian 
<Keybuk> ogra: damn well does
<mdz-sprint> ogra: this is a bit of a special case; we've reorganized the boot process, these are fundamental system scripts that the user should never need to customize
<Keybuk> the only change I made was to the version in the if header
<Keybuk> every time Debian move initscripts around, they use remove/install
<ogra> mdz-sprint, but currently it will leave me with a lot of useless scripts in a customized setup ...
<Lathiat> Mar  8 22:00:23 in-target: Setting up cupsys (1.1.99.b1.r4929-0ubuntu3) ...
<Lathiat> Mar  8 22:00:23 debconf: Obsolete command TITLE Configuring cupsys called
<Lathiat> i assume thats the culprit
<Lathiat> Mar  8 22:00:24 in-target: adduser: The group `scanner' does not exist.
<Lathiat> Mar  8 22:00:24 in-target: dpkg: error processing cupsys (--configure):
<ogra> as i said before, netbooting shouldnt have any fsck running on boot ...
<ogra> for example ...
<ogra> ltsp only uses two of the rcS scripts in that list
<Keybuk> why not?
<Keybuk> you can't fsck an NFS root or tmpfs, so that script should be a no-op
<sabdfl> Keybuk: because ;-0
<ogra> what for do i need do do a fsck in a nfs mounte root ? 
<mjg59> Kinnison: http://www.gnome.org/learn/admin-guide/latest/ch01s05.html
<mdz-sprint> ogra: this is why I left the init scripts alone in the first place; the only reason you're doing this is to make the clients boot faster
<Keybuk> it'll just exit 0 after doing nothing
<mdz-sprint> ogra: it doesn't break anything
<mjg59> sabdfl: Are we supposed to be trying to support Centrino duo laptops this time round?
<Kinnison> mjg59: yep, done that now thanks
<sabdfl> mjg59: yes
<mjg59> Kinnison: Cool
<ogra> mdz-sprint, and to avoid tons of error messages on boot because of a readonly filesystem
<mjg59> sabdfl: Ok. In that case, something to test the ipw3945 driver on would probably be helpful
<mdz-sprint> mjg59: that ipw2200 proposal sounds familiar; didn't we endure a painful upstream update in hopes of fixing firmware errors already?
<ogra> mdz-sprint, its ugly and breaks my dapper goal ...
<ogra> mdz-sprint, but thats not the point ...
<mjg59> mdz-sprint: Uhm. Not that I recall. But quite possibly - there's been several sources of them.
<mdz-sprint> ogra: there are much simpler ways of avoiding those error messages
<ogra> mdz-sprint, my point is that we have clear examples in the documentation we ship and reality doesnt match at all
<mjg59> mdz-sprint: The upgrade is a matter of updating the driver and adding the new firmware to the kernel image, so it's not insanely painful
<sabdfl> mjg59: i've got an x60 on order (at leastI think i do but lenovo are not being helpful)
<mjg59> sabdfl: Ok - any idea if it's likely to turn up in a sensible timeframe?
<mjg59> We should possibly just add the driver and hope...
<sabdfl> mjg59: that's what they're being unhelpful about
<Keybuk> ogra: ??
<mjg59> sabdfl: Ah
<ogra> mdz-sprint, i can live with that breakage in ltsp, but its an important issue that people looking at the manpage also get the right info imho
<Keybuk> documentation says
<Keybuk>        A common system administration error is to delete the  links  with  the
<Keybuk>        thought that this will "disable" the service, i.e., that this will pre
<Keybuk>        vent the service from being started.  However, if all links  have  been
<Keybuk>        deleted  then  the  next  time  the  package is upgraded, the packages
<Keybuk>        postinst script will run update-rc.d  again  and  this  will  reinstall
<Keybuk>        links  at  their factory default locations.
<sabdfl> mjg59: we have a good relationship with intel, we could ask them to test
<mjg59> sabdfl: True
<mdz-sprint> ogra: what are you proposing that we do instead?
<ogra> Keybuk,     Example of a command for disabling a system initialization-and-shutdown script:
<ogra>           update-rc.d -f foobar remove
<ogra>           update-rc.d foobar stop 45 S .
<mjg59> sabdfl: Oh, wireless works on the Mac now
<Keybuk> ogra: that's an example for the *postinst*
<ogra> mdz-sprint, at least fix the manpage
<mdz-sprint> ogra: you're exaggerating a bit about the documentation; this is true in general but there are exceptions
<Keybuk> ogra: you don't use update-rc.d as a sysadmin
<sabdfl> mjg59: nice. what's the box like, generally?
<mjg59> I'm working with HP so we can try to get a bootloader, but once that's sorted we ought to be able to ship
<mjg59> sabdfl: Fairly well made, impressively fast
<sabdfl> v cool
<mdz-sprint> my X is fucked, brb
<ogra> Keybuk, no matter how i make the S links K links, your postinst will revert my change
<mjg59> You can have it back in a couple of weeks, and it can stop cluttering my living room
<ogra> Keybuk, and *i* use update-rc.d in scripts ...
<Keybuk> ogra: well, yes. but it's the Debian postinst, please; not mine
<Keybuk> I didn't spuriously do it this way, and have largely done it the way you suggest in other packages
<ogra> Keybuk, its not the one used in sarge, i didnt look at sid
<Lathiat> Kamion: ping?
<Keybuk> ogra: sarge one calls -f ... remove
<ogra> hmm, where did i look at then :(
<Keybuk> I think the reason they do it is also that initscripts doesn't call update-rc.d
<Keybuk> (to add the scripts)
<Kamion> Lathiat: yes?
<Lathiat> Kamion: can you take a look at my syslog? im fairly sure its the cupsys install error?
<Kamion> Lathiat: yes, it is
<Lathiat> ok, cheers
<Lathiat> is that known already?
<Kamion> Lathiat: no
<Lathiat> ok, i'll take a look
<Kamion> Lathiat: I'm going to bet that you were reusing an old /home partition
<Lathiat> Kamion: nope, clean disk
<Kamion> Lathiat: or perhaps you installed in expert mode and opted not to create a user
<Lathiat> nope
<Kamion> come on, help me out here, anything unusual about your install?
* Lathiat thinks
<Lathiat> nope
<Kamion> FAT32 /home?
<Lathiat> nope
<Lathiat> bgi fat / ext34
<Lathiat> ext3
<Lathiat> on a freshly created vmware so its empty as
<Treenaks> ext34
<Treenaks> when will that be?
<Treenaks> :P
<Lathiat> its now
<Kamion> oh, I see, user-setup-apply doesn't run until prebaseconfig
<Lathiat> im so hard core
<Lathiat> im bleeding edge
<Kamion> whoopsie
<Kamion> please file a bug on user-setup saying that user-setup-apply should be moved to post-base-installer
<rob^^^> "Ubuntu is now the most popular desktop distribution on Dell PCs, it may not be a year from now." <-- hrmm
<Keybuk> rob^^^: source?
<Lathiat> Kamion: assign it to you?
<rob^^^> http://desktoplinux.com/news/NS3822185143.html quoting Michael Dell
<rob^^^> I did not know their pre-shipment imaging would do custom-configs if Linux
<Kamion> Lathiat: yes
<Kamion> thanks
<segfault> kamion: Some strings in the post-installation of Ubuntu are untranslated, how can i translate that? Do i have to wait until Rosetta publishes it? Those strings are: Preparing PACKAGE, Configuring PACKAGE, Installed PACKAGE and so on.
<segfault> that progress bar after the first reboot.
<Keybuk> rob^^^: if it's from Michael himself, that's damned cool :)
<Kamion> segfault: you're talking about breezy; that progress bar has gone away in dapper
<Kamion> segfault: I'm afraid there's no way to make Rosetta translations affect the installer short of new uploads
<Kamion> segfault: anyway, those strings are in apt; they'll probably still affect the dapper installer, just pre-first-reboot
<Kamion> so translate them in apt and let mvo know that he needs to pull
<segfault> kamion: that's weird, i'm installing dapper right now and has it
<Kamion> segfault: what, a progress bar after the first reboot?
<Kamion> that's ... not possible
<Kamion> all the infrastructure for that has been deleted
<segfault> kamion: just before the GRUB installation
<Kamion> segfault: that's *not* after the first reboot! :-)
<Diziet> Oof, I had my client stuck in screen scrollback.
<segfault> however... i made a installer CD using jigdo
<Kamion> 14:36 < Kamion> segfault: anyway, those strings are in apt; they'll probably still affect the dapper installer, just pre-first-reboot
<Kamion> 14:36 < Kamion> so translate them in apt and let mvo know that he needs to pull
<Kamion> segfault: see the above
<Diziet> Should I add https://launchpad.net/distros/ubuntu/+addticket to the ff bookmarks in place of the bugzilla link ?
<segfault> kamion: oops, sorry then
<lamont> fabbione: am now
<mvo> segfault: what bits do you need?
* lamont needs to teach xchat to ignore my proxy changing my nick, and then I can make my nick change when I leave all the channels...
<segfault> mvo: some untranslated apt strings, like: "Preparing %s", "Configuring %s" and "Installed %s", in the installation, just before GRUB gets installed
<rob^^^> Keybuk, yeah it's the top story on /. I think he is right though, the initial undercurrent of the interview seems to be that Dell refuses to be a "King Maker" and wants to wait to pick the dominant player.
<segfault> mvo: should i wait for dapper being ready in rosetta or there's other way to translate them?
<pitti> Kamion: sorry to bother you again, can you please NEW thunderbird-locales? (not urgent, though)
<mvo> segfault: you have various options, the easiest maybe to apt-get source apt
<mkrufky> infinity: ping
<Kamion> pitti: main or universe?
<segfault> mvo: sure. i'll do that and send you the updated PO files
<mvo> segfault: thanks a lot. this is for the pt translation?
<pitti> Kamion: eventually for main
<pitti> Kamion: but I need to update the language-support packages for them
<mvo> segfault: if so, please have a look first at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355798
<Ubugtu> debian bug 355798 in apt "[INTL:pt]  Portuguese translation update" [Wishlist,Open]  
<mkrufky> well, I realize that infinity is the php maintainer, but we're in different time zones, and I dont know how to get ahold of him... I have most mssql functionality working through the use of the php5-sybase package .... but it doesnt let me use stored procedures... I've googled it, and everything I found says that it should work with php4.1 and later...  I need access to the functions, "mssql_init(), mssql_bind(), and mssql_execute()"  ... what else do I n
* lamont wonders if anyone plans to make findutils_4.2.27-1 not FTBFS
<lamont> hrm... guess I should file a bug if there isn't one
<segfault> mvo: ok
<Kamion> pitti: so universe for now?
<segfault> mvo: mine is for pt_BR, it's slightly different :)
<Kamion> pitti: actually, main seems harmless and less work
<pitti> Kamion: if you can immediately put them iunto main, that would be easier
<Kamion> pitti: accepted
<pitti> Kamion: thank you very much
<pitti> Kamion: I'll update l-support as soon as they are in the archive
* lamont marks #27870 confirmed
<mvo> segfault: ah, right :) I knew it was something with pt :)
<lamont> mkrufky: infinity does read scrollback
<segfault> mvo: hehe :0
<segfault> :)
<mkrufky> lamont: he didnt reply to me yesterday... I will hang tight, hopefully he'll respond tonight
<mkrufky> infinity: you can contact me via email, if im not around .... my irc nick at linuxtv dot org
<azeem> mkrufky: if you're on all the time anyway, it might make more sense to just state the problem instead of pinging him.  Saves one round of handshaking
<jdub> hey azeem 
<azeem> heya
<Chipzz> hi jdub ;)
<mkrufky> azeem: good point...  thats exactly what i did 10 minutes ago
<mkrufky> azeem: i can re-post, but i dont want to break irc netiquette
<mkrufky> ;-)
<joelbryan> I've successfully implimented a shutdown_logo on top of shutdown dialog. How do I send a patch?
<mkrufky> for good measure:
<mkrufky> well, I realize that infinity is the php maintainer, but we're in different time zones, and I dont know how to get ahold of him... I have most mssql functionality working through the use of the php5-sybase package .... but it doesnt let me use stored procedures... I've googled it, and everything I found says that it should work with php4.1 and later...  I need access to the functions, "mssql_init(), mssql_bind(), and mssql_execute()"  ... what else do I n
<jdub> yo Chipzz 
<ogra> jdub, is it possible to make the vendor logo in ubuntu-artwork a alternative ? i'd like to replace it in edubuntu-artwork but dont like to fiddle with dpkg-divert if possible
<Kamion> mkrufky: e-mail is the traditional way to solve the timezone problem ;-)
<mkrufky> Kamion: where can I find his email?  ...or is there anyone else in addition that can answer php / tds questions ?
<Kamion> mkrufky: https://launchpad.net/people/adconrad
<joelbryan> jdub: how do I send a patch to ubuntu artwork?
<mkrufky> that you :-D
<mkrufky> oops
<mkrufky> THANK you :-D
<jdub> joelbryan: if you've changed images, you'll have to put them up on a website or email them
<JaneW> mdz: ping
<joelbryan> jdub: it's a patch in logout to have a shutdown_logo
<jdub> joelbryan: i imagine that's a gnome-session patch, correct?
<jdub> joelbryan: you should ask in #ubuntu-desktop
<joelbryan> yes
<ogra> or in #dapper-look
<lamont> mkrufky: and yeah, this channel tends to have enough volume that it's easy to miss a comment or two
<mkrufky> lamont: completely understandable
<Keybuk> ogra: random thought
* ogra listens
<Keybuk> hmm, no, ignore me
<ogra> heh
* sivang loves the new artowkr.
<Keybuk> just wondering what happened if you removed /etc/init.d/* rather than the symlinks :)
<Keybuk> I suspect it'd work, and survive upgrades
<Keybuk> but probably sick, twisted, evil and too late
<ogra> hmm, but that leaves no option for the admin to enable it later ...
<ogra> i think we (i) need to rework the concept in dapper+1 
<jdub> SMF! SMF!
<ogra> smf ?
<sivang> smf ?
<simira> soon middle freeze?
<tepsipakki> "service management facility"
<tepsipakki> from solaris
<sivang> tepsipakki: what would have Jeff with Solaris? :-)
<ogra> tepsipakki, thanks 
<ogra> jdub, yeah !!
<ogra> jdub, when do we see a test implementation for dapper+1 ?
<ogra> :)
<Keybuk> jdub: I have an implementation of that here <g>
<ogra> Keybuk, 
<ogra> +case "$oldver" in
<ogra> +	2.85-1[0-5] )
<ogra> +		update-rc.d -f mountvirtfs remove >/dev/null 2>&1 ||:
<ogra> +		;;
<ogra> +esac
<ogra> thats all i find in sarge 
<Keybuk> I'm going to propose it for dapper+1
<Keybuk> ogra: right, see, uses -f remove ... then in sid they added the block I just extended
<ogra> for exactly one initscript
<ogra> i dont care about the adding, update-rc.d does the right thing there ... i care about the forced rmoval that stops it from doing the right thing
<Keybuk> but it won't break ltsp
<ogra> +nope
<Keybuk> it'll just make ltsp boot a second or two slower
<Keybuk> playing symlink-checking games will *break* other systems
<ogra> and show you a bunch of errors if you disable usplash
<Keybuk> if there are errors, we can fix those
<ogra> we cant ...
<jdub> pitti: ping
<Keybuk> tbh, if scripts are taking ages to no-op, those should be fixed too
<ogra> they are caused by having a readonly filesystem
<pitti> hey jdub
<Keybuk> nothing during boot should be writing to / now
<ogra> Keybuk, even a no op on a 200Mhz/64MB system can take 5 seconds :)
<jdub> pitti: have you tested mailman on dapper?
<Keybuk> ogra: it shouldn't take 5s to noop
<pitti> jdub: no, why me?
<jdub> pitti: because i momentarily confused you with Micksa 
<jdub> Mithrandir: 
<jdub> Mithrandir: ping
<jdub> pitti: n/m ;-)
<Keybuk> ogra: either way, I still don't think breaking people's systems just to avoid upgraded ltsp boxes booting slowly is the right call
<ogra> Keybuk, it can ...
<Keybuk> didn't those symlinks exist in breezy anyway?
<ogra> Keybuk, they did 
<Keybuk> I thought you only did your rcS.d purge for the dapper cycle
<Keybuk> uh
<Keybuk> so what's the problem?
<ogra> security updates 
<Keybuk> if rcS.d is full on breezy systems, me changing the postinst isn't going to change that
<Keybuk> security updates of what?
<ogra> people that did test installs wuring development
<ogra> *during
<ogra> initscripts ?
<Keybuk> an initscripts security update wouldn't run that code
<Keybuk> it's guarded by a version check
<jdub> Keybuk: smf userland code + some reasonable replacement for contracts, or...?
<ogra> Keybuk, in any case we should find something saner for dapper+1 
<Keybuk> jdub: completely different implementation/design that fulfils the same use cases
<Keybuk> ogra: sure, dapper+1 we can think about it better
<Keybuk> hell, I'm hoping we get something !sysvinit at least "on the table" for dapper+1
<ogra> Keybuk, i'm already in contact with pere about it and he talks to the sysv-init team
<ogra> ah, even better
<jdub> Keybuk: that doesn't seem as exciting to me as driving a common solution
<Keybuk> pere is the sysvinit team, isn't he?
<ogra> Keybuk, dunno
<Keybuk> jdub: *shrug* the Solaris solution is crap; not to mention badly licenced
<ogra> Keybuk, he just told me he'd carry the issue to it
* jdub gars.
<jdub> there is nothing wrong with the license for the userland stuff
<tseng> doko: did you mean to remove /usr/lib/tclrrd-1.2.11 from rrdtool-tcl?
<tseng> doko: (most recent changes are by you it seems)
<Keybuk> Mar  8 10:14:21 localhost NetworkManager: <WARNING>^I  (): get_scan_results(): card took too much time scanning.  Get a better one.
<Keybuk> ROFL
<Keybuk> polite error message
<doko> tseng: can't remember ...
<siretart> Keybuk: well, just a warning, no? ;)
<tseng> doko: if not, it would be nice to have it back.
<tseng> doko: /usr/lib/tclrrd1.2.11/pkgIndex.tcl is pretty useful
<doko> tseng: could you summarize that in a bug report?
<tseng> doko: sure.
<doko> thanks
<tseng> doko: I assigned it to you for now.
<ogra> tseng, just fix it :P youre main uploader :)
<tseng> ogra: i might later.
<ogra> :)
<tseng> ogra: i dont keep a gpg key on my work pcs
<ogra> yeah, safer that is
<desrt> dholbach; the story is we're not sure :)
<dholbach> then better find out :)
<desrt> dholbach; i know that at some point in the past i apt-get installed it.... but i think it might have been in some exotic 3rd party repo
<desrt> dholbach; so it very well may be NEW
<dholbach> NEW is not to be discussed with me.
<mdz> dholbach: patch emailed
<dholbach> mdz: merci beaucoup
<jbailey> Is http://cdimage.ubuntu.com/releases/breezy/release/ expected to only contain DVDs?
<jbailey> I'm looking for the CD ISOs.
<tepsipakki> mjg59: in case you haven't seen this: http://refit.sourceforge.net/
<tepsipakki> might help porting ubuntu to mactel
<mdke> hey jbailey, quick and immensely trivial question: is it ok to GPL your script.sh that you wrote for the purposes of translating xml in ubuntu-docs?
<jbailey> mdke: Most shell scripts that I write are intended for the public domain.  I try to do that for anything that takes me less than an hour to write.  Did I forget to put a header on it?
<mdke> jbailey, yes, but we will do it. So you'd prefer public domain to gpl?
<jbailey> mdke: Unless there's a good reason not to.
<coyctecm> damn big war here, I've packaged libdvdcss2 for amd64 and storing it some finnish server :)Now admins of that server are checking is that legal or not
<mjr> coyctecm, is that what started that s.a.l thread where I just posted? :] 
<mdke> jbailey, right, I can't think of one
<coyctecm> I think it is legal distribute libdvdcss in finland :)
<mjr> coyctecm, I think it isn't, but I'm doing it anyway and baiting the authorities, in hopes to be proven wrong :)
<coyctecm> mjr: actually yes, i started that thread :)
<coyctecm> mjr: I've mailed to tanja karpela ;)
<mdke> coyctecm, mjr, can you discuss in #ubuntu-offtopic?
<mjr> yah, sorry
<coyctecm> sorry :)
<mjr> actually, off to home anyways
<Mithrandir> jdub: pong
<mjg59> tepsipakki: It's alrady ported
<mjg59> We just need a working elilo
<jdub> Mithrandir: have you tested mailman on dapper?
<Mithrandir> jdub: no.  I suspect it needs /var/run/ and /var/lock love.
<Kamion> jbailey: yes, expected, although I need to add a link there at some point
<Kamion> jbailey: see http://releases.ubuntu.com/breezy/
<jdub> Mithrandir: yeah :-)
<tepsipakki> mjg59: ah, ok.. you've also seen the hacks on elilo?
<jbailey> Kamion: Cool, thanks.  Wanted to make sure it wasn't just broken.
<mjg59> tepsipakki: The basic problem is that we can't build a working elilo under Ubuntu
<tepsipakki> mjg59: ok
<mdke> jdub, since you're here, would you do the indian loco team mailing list at some stage when you have a moment, the loco chap says they are very keen to have their own mailing list
<mdke> jdub, (the team was recognised yesterday at the CC meeting)
<coyctecm> I'm thinking to start project, clone k3b for gtk2
<sladen> mjg59: how come, does it not like GCC4?
<mjg59> sladen: Fuck knows.
<mjg59> sladen: It's certainly not happy with /our/ gcc4 and /our/ binutils
<tepsipakki> quality stuff ;)
<sivang> re
<sladen> doesn't it look exciting: http://www.paul.sladen.org/ubuntu/qemu-livecd/wine-qemu-win32-dapper-live.png ...y'urm
<jbailey> mjg59: Failed build, or useless binary?
<mjg59> jbailey: Useless binary
<jbailey> Ugh.
<jbailey> Any difference if you try older gcc or optimisation disabled?
<mjg59> I've tried older gcc
<mjg59> It doesn't use optimisation
<azeem> mjg59: do you think gentoo kept as that?
<azeem> +it, or something
<mjg59> azeem: Yes
<sladen> mjg59: does a binary diff and disabling the differences give you anything (or something as simple of running a pe32-happy objdump over it)
<azeem> whoa :)
<mjg59> As far as I could tell
<sladen> mjg59: s/disabling/disassembling/
<mjg59> sladen: I'll look at objdump at some stage
* lamont wonders how to tell dpkg it's running on a different architecture.
<Treenaks> dpkg --force-something
<Treenaks> ?
<trappist> there is a --force-architecture
<desrt> these 'low disk space warning' popups are particularly useless
<seb128> I don't think so
<desrt> i get them for drives with 25gig free
<seb128> the values are not really wisely choosed
<desrt> just because they're over a certain percent
<Burgwork> I believe is 20%
<seb128> but the concept is useful
<seb128> yeah,  that's a known issue
<desrt> /dev/sda3             152G  120G   24G  84% /mnt/media
<desrt> crikey.
<desrt> i also get it for my mp3 player
<desrt> which is a bit odd.
<seb128> but that's just "it fires up at the wrong moment"
<seb128> it should be like 4% or 500M
<seb128> and maybe an ignore list for some categories of device
<desrt> and it keeps popping up....
<seb128> make some space :)
<desrt> my vorbis player is supposed to be full :p
<seb128> that a category of devics to ignore :)
<desrt> but i mean, as i add (and even delete) files from it, it pops up again and again
<seb128> hal probably has a capability or something for music players than we can filter on
<seb128> no?
<desrt> wait a minute
<desrt> did martin say he added my unmount dialog to nautilus?
* desrt wonders if this means that it won't work if you use drivemount applet
<seb128> he patches nautilus based on your patch
<desrt> crap :(
<desrt> oh well, i sent him an email in any case
* desrt goes to school
<seb128> desrt: that's better than nothing
<seb128> brb
<desrt> seb128; but not as good as it could be.
<seb128> desrt: right, but minimal change after freeze, etc
<desrt> nod....
<desrt> speaking of not making changes... when is the WPA stuff going to go into dapper's network manager?
<segfault> desrt: it's unlikely to happen
<desrt> crack.
<desrt> y'all need to break freezes more casually :)
<Burgwork> desrt, really? can I quote you on that?
<desrt> only if you include the ":)"
<segfault> desrt: heh, keybuk has some good reasons to not make it happen (yet), maybe for dapper+1
<Mithrandir> Kamion: I can reproduce your "readahead takes forever" bug now.  I guess I'll just work around it in casper by rm-ing /sbin/readahead-list.
<desrt> dapper+1 is called edgy
<segfault> really?
<desrt> yes.
<desrt> you may also quote me on this.
<segfault> haha
* desrt yawns.  see y'all.
<Kamion> Mithrandir: ok
<Kamion> Mithrandir: I did it by rm-ing /etc/init.d/*readahead*
<highvoltage> desrt: the edgy what?
<Mithrandir> Kamion: *shrug*; either works for me.  Just not having to wait forever for the readahead to finish.
<segfault> is possible to translate hte gfxboot menu men the usre choose it's language pressing F2?
<segfault> my keyb is on crack, sorry.
<Kamion> segfault: no, that uses the native name for each language and is not otherwise translatable
<Kamion> consider that the user might have selected your language by accident
<Kamion> Mithrandir: keymap page layout change in my espresso archive, FYI
<Kamion> segfault: or do you mean the rest of the gfxboot menu, not the language menu on F2?
<segfault> no... i mean, translate the options the user has, like: Install to the hard disk, Install  aserver, etc. to its native language after he chose in the F2 menu
<Kamion> segfault: sure, send me a translation of gfxboot-theme-ubuntu and I'll incorporate it
<segfault> kamion: great, i'll do that.
<Mithrandir> Kamion: 'k
<Kamion> Mithrandir: can you think of any reason not to move the keymap page after the location page? it came up as a suggestion at the UI sprint
<highvoltage> anyone know which aninal edgy is?
<highvoltage> edgy elmo?
<Kamion> Mithrandir: and it would probably help to pick a better default keymap
<Kamion> highvoltage: desrt said you could quote him. The question is, is his information reliable? :-)
<Mithrandir> Kamion: true, no, can't really think of any if we're asking the question anyway.
<highvoltage> Kamion: ah, good point :)
<Kamion> Mithrandir: OK, I'll do that if it won't interfere with anything you're doing then
<Mithrandir> Kamion: sure, feel free.
<Kamion> Riddell: any reason that liveinstaller.py can't be generated on the fly by build-depending on pyqt-tools?
<Burgwork> highvoltage, desrt is canadian. Slippery folks, those canucks. Can't be trusted
<highvoltage> Burgwork: ah, like Burgandavia
<highvoltage> wait a tick...
<highvoltage> nevermind :)
<Riddell> Kamion: actually it shouldn't be generated at all, but there's a bug in pykdeextensions that stops it working as a include foo.ui if it's in a subdirectory, so I didn't change to build time creating liveinstaller.py because that should get fixed soon, but I don't mind it being done at build time at all
<Kamion> Riddell: hmm, when I generate it with pyuic it loses the imports of kdecore and kdeui though
<Kamion> I guess you must have added those in by hand - or is there a magic option I'm missing?
<Riddell> Kamion: use kdepyuic
<Kamion> aha
<segfault> kamion: are the accelerator keys used in gfxboot? (the original string says that ^ should be placed before it)
<Kamion> segfault: no, not at the moment
<Kamion> you might as well add them for now but they won't do anything yet
<segfault> kamion: ok
<jdub> holy crap
<jdub> mysql-a-go-go
<tseng> jdub: eh?
<jdub> on my linode
<jdub> mysql is forking heaps
<jdub> lots of processes
<jdub> crazy
<tseng> jdub: turn off innodb
<jdub> yeah, done
<tseng> no luck?
<jdub> ('cos it saves 10MB straight out)
<jdub> no, have always had it disabled
<tseng> hm, it takes down my thread count
<jdub> this seems to be a blowout
<jdub> more than normal behaviour
<ik5pvx> good evening
<fabbione> hey ik5pvx 
<fabbione> lamont: meet ik5pvx 
<fabbione> ik5pvx: meet lamont
<ik5pvx> hi lamont
<fabbione> on the right side of the ring.. US champion on bind maintaince for only 160 lbs.. LAMONT
<lamont> fabbione: 195lbs
<ik5pvx> :)
<fabbione> on the left side of the ring.. Italian champion for butterfly liftling.... ik5pvx 
<fabbione> !
<lamont> lol
<lamont> ik5pvx: what's the issue?
<sivang> hehe
<sivang> guys, please . stop it, people here are trying to work :)
<sivang> but instead they are rolling on the floor laughing and making terrible spelling mistakes ;-)
<ik5pvx> well, I realized today (you know, better late than ever) that default installation of bind is open to recursive queries to the world. This is considered a mild security risk in the ISP world
<sivang> ik5pvx: can that take down the DNS completely?
<lamont> and sadly not really something that's fixable
<sivang> (DoS)
<lamont> the presumption of the user is that once you install bind, you can use the daemon...
<ik5pvx> lamont, so I wanted to know what would be your opinion of shipping it by default open only to localhost and (possibly, if it easibly doable) the local networks
<lamont> and I have no clue what network blocks you _want_ to allow recursion from.
<lamont> it kinda breaks the config, sorta...
<ik5pvx> sivang no, it doesn't take down *your* server... they usually do amplification attacks with this. 
<lamont> for example, I live on 15.238.4.0/22, but recursion should probably be allowed for 15/8
<lamont> I'd have no issue with adding a comment to the config file, although I'm torn on whether to default to disabled or not.... after all, you don't install bind unless you want to answer queries...
<ik5pvx> what about, say:  (in named.conf.options)
<lamont> I'll ponder it though... since I used the same argument to make postfix only relay for the local network by default (or was that localhost??)
<ik5pvx> acl our-nets { 127.0.0.1; };  options { allow-recursion { our-nets; }; };
<ik5pvx> and a big comment saying that you need to add local networks addresses for recursion to work, or remove the statement for a publicly accessible server in a very large isp ?
<maswan> ik5pvx: well, alloing localnet by default would probably be good too
<maswan> well, "localhost" + "localnets"
<ik5pvx> I don't know if there is an easy way at postint stage to detect what are the local networks 
<ik5pvx> and if there's an easy way of cooking them into the config file
<ik5pvx> bind nicely allows includes, though
<maswan> ik5pvx: bind has built-in acls for localhost and localnets
<ik5pvx> see, there's always something to learn
<maswan> to me, this seems like a sensible default
<ik5pvx> what are they ?
<maswan> ik5pvx: the IPs for your local interfaces, and the networks your local interfaces are on.
* ik5pvx tries to skip rtfm
<ik5pvx> maswan I meant what are the keywords to use :)
<maswan> ik5pvx: "localhost" + "localnets"
<ik5pvx> ok
<maswan> we recently got the word from our networking people that public recursion was not o
<maswan> not ok
<maswan> since it is a big ddos-amplifier
<ik5pvx> so shipping with "allow-recursion { localhost; localnets; };" could do ?
<maswan> ik5pvx: it's what I'd suggest
<maswan> perhaps with a "my-networks" too, which has a dummy define with comments on how to extend it
<maswan> IIRC, it should be harder to cache-poison a server not allowing public recursion too, but I'm not sure on that
<lucas> hi
<ik5pvx> lamont what's your opinion on this approach ?
<lamont> ik5pvx: that's what I need to ponder some tonight
<ik5pvx> I wonder if that "ponder" means "diluting with huge quantities of beer"
<ik5pvx> :)
<bluefoxicy> Violation of security best practices, what is the severity?
<bluefoxicy> (I've located several programs with executable stacks on x86-64)
<maswan> lamont: IMO, "localnets" will catch the common case. A pointer towards defining your own ACLs should be good enough for the rest.
<Burgwork> bluefoxicy, I would talk to pitti
<bluefoxicy> Burgwork:  nods.  It's not an actual vuln though.  The thing is that if you have an actual vuln of specific type (shellcode injection into executable stack via stack buffer overflow), it will be likely a denial of service attack
<bluefoxicy> but if the stack is actually executable, then you can easily hijack the program for a remote shell
<bluefoxicy> of course if the program is without a real vuln this isn't a problem but ;)
<fabbione> bluefoxicy: still pitti
<bluefoxicy> Burgwork:  i'll leave it as normal until I see pitty
<bluefoxicy> pitti
<bluefoxicy> fabbione:  nod
<doko> Kamion: please could you promote python-pullparser?
* bluefoxicy reports the same in clock-applet, but marks as minor, because theoretically there is no way to privilege escallate by hacking clock-applet
<Kamion> doko: done
<doko> Kamion: great, zope3 installable :)
<doko> ogra: ^^^
<ogra> doko, YAY !!!
<bluefoxicy> there, I have reported 4 bugs.
* ogra wonders by how many MB his CDs will overflow now with zope3 on it :)
<ik5pvx> lamont, maswan ... thanks for the discussion and good $localtime
<lamont> ik5pvx: thanks for getting me to think on it.
<Kamion> Riddell: I give up, I can't see how you generated that exact file
<Kamion> all the kdepyuic invocations I can come up with generate something different, mostly with respect to the i18n stuff
<sivang> ogra: you're shipping zope with Edubuntu?
<ogra> sivang, schooltoll
<ogra> *tool
<sivang> ogra: ah right, nice. out of the box ready schooltool in an Edubuntu CD. Someday I've gotta put my hands on this nice niche of ubunut.
<Burgwork> I am meeting someone tonight who is going to be rolling out many dozens of Ubuntu desktops
<Burgwork> they were quite interested in Edubuntu when I mentioned it
<ogra> yay
<doko> ohh nooo ... I fear we'll need an ia32-libs-scim package ... Mithrandir, do you volunteer? ;-P
<siretart> doko: can we have a ia32-libs-sdl package? or add libsdl to some other package?
<Kamion> Riddell: I've moved the keymap page before the location page in Espresso's KDE frontend (as well as GTK), but unfortunately I haven't managed to set up a suitable test environment; can you test and make sure it still works?
<Kamion> er, once it's finished pushing that is
<Kamion> pushed
<doko> siretart: why is this needed?
<siretart> doko: there are nonfree 32bit applications which need a libsdl and don't bundle one
<siretart> doko: most notably is quake4, an id ego shooter game. when I try to run it in a 32bit chroot, it just segfaults for me, and I have no idea why. running it outside a chroot and letting /etc/ld.so.conf point to some dir with a 32bit libsdl makes the game work like a charm
<siretart> jamie jones prepared a ia32-libs-universe package (not uploaded): http://revu.tauware.de/details.py?upid=1399 - it contains amongs others libsdl, and makes quake4 work
<doko> siretart: could you make this package a bit saner? just base it on i.e. ia32-libs-kde, and apply the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355766
<siretart> doko: will do. which libs would you accept besides sdl and how should it be named?
<doko> siretart: -universe looks fine, but maybe ask Mithrandir. IMO as few libs as possible
<siretart> well, I find it a bit confusing, because libsdl is a package in 'main', but I don't really mind
<doko> ia32-libs-unsupported? 
<Kamion> don't see why not to just call it what it is, -sdl
<Kamion> ?
<ogra> way to obvious :)
<Kamion> I'd rather have slightly more binaries than badly named binaries, personally
<Kamion> well, s/badly/non-informatively/
<ogra> you train the creative regions of the brain of our users if you do that :)
<ogra> ubuntu - enhancing your congnitive capabilities :)
<siretart> well, Jamies idea was to add more than just sdl
<doko> Kamion, didn't look at the contents, if it's only sdl
<siretart> therefore the name -universe, because he wanted to include libs which are in universe as well
<ogra> if it doesnt contain more, there is no need for another name
<Kamion> siretart: I think we should be moving towards one binary per library rather than enormous collections, personally
<ogra> i'd see -universe as a metapackage that depends on the different ia32-libs-* packages
<Kamion> provided that it doesn't bloat Packages up beyond all recognition, obviously
<Kamion> ogra: I'd see it as unnecessary ...
<siretart> ok, then I'll name it ia32-libs-sdl and put only sdl libs in there
<Kamion> well, or maybe ia32-libs-all I guess
<ogra> Kamion, yes, but thats what comes up if i hear the -universe name :)
<siretart> jamies list of packages can be seen here: http://revu.tauware.de/revu1-incoming/ia32-libs-universe-0601051305/ia32-libs-universe-1.0ubuntu1/fetch-and-build
<ogra> thats a bunch more than sdl
<doko> -any, they are binary-arch ;)
<elmo> Kamion: wasn't there a variant of serial console install that simply got  the  network up, installed openssh-server and did the rest over that?
<Kamion> in Debian, yes, but we've never supported that
<Kamion> it was basically an s390 hack ...
<elmo> whine, I wish we could - serial consoles make me want to poke my eyes out with a straw
<Kamion> network-console is in universe
<Kamion> might think about supporting that post-dapper
<ajmitch_> morning
<mkrufky> infinity: you around?  I have a php question
<mkrufky> I have most mssql functionality working through the use of php5-sybase .... but it doesnt let me use stored procedures... I've googled it, and everything I found says that it should work with php4.1 and later...  I need access to the procedures, "mssql_init(), mssql_bind(), and mssql_execute()"  ... what else do I need to do to get this functionality?
<mkrufky> i tried the dapper packages -- nothing changed
<infinity> mkrufky: I realise you've been asking for a while, but can you avoid spamming me in 3 different locations at once? :)
<tepsipakki> could we get a newer libpam-krb5 for dapper (has: 1.2.0-1, in sid: 1.2.0-2)?
<tepsipakki> openssh doesn't save the tickets
<tepsipakki> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339734
<tepsipakki> poor ubugtu :)
<Seveas> hmm
<Seveas> ubugtu should take that
<Seveas> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339734
<Seveas> gnaaaa stupid way-too-freeform syntax of debbugs
<tepsipakki> heh
<Seveas> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339734
<Ubugtu> debian bug 339734 in openssh-server "Kerberos tickets are not saved (pam_krb5)" [Important,Closed]  
<Seveas> there. conquered debbugs once again
<Seveas> (really debbugs still sucks for this, even malone has a better machine-readable export)
<tepsipakki> it was reassigned to libpam-krb5 :)
<Seveas> that's what I mean
<tepsipakki> ah
<Seveas> I have to parse the whole f*ing mbo
<Seveas> mbox
<Seveas> and have dozens of rules
<Seveas> well, no F*ing way - I keep it simple
<infinity> Seveas: There is an LDAP interface...
<Seveas> infinity, really... no one told me that yet
<lucas> I have a problem with hibernate and my video driver. How can I re-request an X autoconfiguration as in dapper's install ?
<Seveas> now I have to learn ldap 
<Seveas> (simplicity is good, correctness is better)
<Seveas> infinity, any quick pointer to it / its usage?
<infinity> Seveas: <shrug>... The LDAP interface is no more "correct" than any other, but it's probably less hassle to get info like bug status, package ownership of bug, etc.
<Seveas> infinity, I meant correctness of Ubugtu
<Seveas> ubugtu now is simple, but sometimes incorrect since I don't parse it all
<Seveas> www.debian.org/Bugs says nothing about an ldap interface
<infinity> Yeah, I'm looking.  It's a transient thing. :)
<Seveas> heh
<Seveas> infinity, is it this: http://people.debian.org/~aba/bts2ldap/
<infinity> That one would certainly work.  I could have sworn we had one on a project machine, but maybe it's dead again.
* infinity shrugs.
<infinity> Oh, funny.  That's actually hosted in .au, and about 4 hops from me.
<infinity> That's a first.
<infinity> Maybe I shouldn't complain about it not being on a Debian Project machine.
<Seveas> hmm
<Seveas> ldapsearch on a bug id seems to fail for certain bugs
<infinity> Bugs that exist?
<Seveas> 130076 for example works, but 300000 not
<Seveas> both exist
<infinity> Right, nevermind then.
<infinity> I vaguely recalled the LDAP gateway not sucking, back when it was hosted on master.debian.org. :)
<infinity> (Though you could mail the current maintainer and ask him WTF, if you're so inclined)
<Seveas> I'm thinking 'meh'
* infinity nods.
<infinity> That's about how much I care too. :)
<Seveas> I'll just cope with parsing mboxes and errors in Ubugtu
* infinity scratches his head at update-notifier...
<infinity> Mouseover on the icon says "20 updates available", the window title in the update app says "you can install 25 updates"
<infinity> Which one's lying?
#ubuntu-devel 2006-03-14
<Seveas> infinity, sounds like bistromathics during happy hour ;)
<wil`yum> is there a channel or on-line forum where i can find out about testing?
<Seveas> wil`yum, people who test Ubuntu dapper hang out in #ubuntu+1
<wil`yum> thank you Seveas
<siretart> does some other ia32-libs-* package provide libasound2?
<siretart> any objections to name the new ia32-libs package ia32-libs-games, containing sdl and asound for now? this is whats needed for commercial games. Kamion: would you accept this for universe?
<siretart> Kamion: ?
<Seveas> --- [Kamion]  idle 01:06:11, signon: Wed Mar  8 07:44:08
<Seveas> wouldn't surprise me if he's sleeping
<siretart> ah, ok
<infinity> Who authorised that?
<Seveas> lol 
<siretart> ah, hi infinity 
<tseng> Sleep exception authorized by Matt Zimmerman
<siretart> infinity: I asked doko before, he told me to apply a patch from mrvn and only include really needed libraries
<siretart> infinity: I have now a ia32-libs-games package ready for upload, containing libsdl and libasound2
<infinity> tseng: I'll have to have a word with Matt about that one.  If we let Colin sleep, the release will never happen.
<siretart> infinity: whom do I need to ask for authorisation to upload?
<infinity> siretart: Have you double-checked that asound doesn't live somewhere else?
* siretart checks again
<infinity> siretart: Like, say, lib32asound2
<infinity> (maybe?)
<siretart> interesting. since when do we have that package?
<infinity> It's been a few weeks, I think.
<siretart> ah, I see.
<doko> siretart: so probably ia32-libs-games should depend on lib32asound2
<siretart> doko: yepp. will do
<sivang> Seveas: who started #ubuntu+1 ?
<sivang> Seveas: and since when? :)
<Seveas> ompaul and myself did that quite recently
<Seveas> to reduce the traffic in #ubuntu
<sivang> Seveas: ah, sounds good. I see there are many users there, nice.
<siretart> doko: should it be called ia32-libs-games or ia32-libs-sdl? it contains just sdl libs for now
<sivang> Seveas: did it helps for hte ubuntu traffic?
<Seveas> Freenode having a burp helped better
<Seveas> but I got mad at lilo for that ;)
<Seveas> but yeah, it helps
<sivang> Seveas: he told me there are some servers added etc, I wonder if this ever took place..
<Seveas> few days ago the complete net was restarted
<Seveas> and some fuckups in the code caused everyone to be kicked from #ubuntu
<Seveas> never been more quiet in there
<sivang> hehe
<sivang> send lilo my thanks :)
<Burgwork> Seveas, how do I go about getting a mask?
<Seveas> step one is becoming a member
<Seveas> step two is poking me
<Seveas> having done both, you should just wait until I talk to lilo again
<Burgwork> can I have it for Burgundavia and Burglaptop as well?
<Seveas> you should link them
<infinity> Burgwork: Those should be aliases under one nickserv account.
<Seveas>  /ns link Burgundavia burgundavias_password
<Seveas> same for BurgLaptop
<sivang> isn't Burgwork a member?
<Burgwork> work and laptop are linked to Burgundavia
<Seveas> sivang, of course he is
<Seveas> there are now 75 people with ubuntu/member cloaks
<Burgwork> Seveas, cheers, thanks
<Seveas> Burgwork, you wil be the 76th, I didn't speak to lilo yet
<Burgwork> Seveas, I am thanking you in advance
<Seveas> hehe, you're welcome
* Seveas gone, bedtime
<siretart> infinity: assuming that there are no other packages providing 32bit sdl, I have a ia32-libs-sdl package ready. it depends on lib32asound2 and makes my quake4 work. whom do I need to ask for permission to upload this?
<infinity> siretart: Kamion/mdz, I suspect.  Are you taking responsibility for watching libsdl uploads and making sure your package stays in sync with the i386 binaries in the archive?
<siretart> infinity: in the scope of my duty as motu-games team lead, yes, I intend to do so
<siretart> whee: cc1: error: scripttrack.c: Input/output error
<siretart> scripttrack.c:1: internal compiler error: Segmentation fault
<siretart> Please submit a full bug report,
<siretart> I hate it when this happens :(
<siretart> hi mdz. 
<siretart> (coincidence?, I just finished my mail to you)
<mdz> siretart: good evening
<infinity> mdz: There's yet another new upstream release of fglrx, can I get a UVF exception?  (It includes some bugfixes, and more importanly, some new hardware support)
<DanielSHaischt> hello, I am trying to dist-upgrade a debian system to dapper. unfortunatly at the time I am getting an arror in /var/lib/dpkg/info/initscripts.postinst ...
<DanielSHaischt> line 'mount -n --move /var/run /tmp/.var.run' at the near end of the file fails with a permission denied
<Amaranth> mjg59: ping
<mjg59> Amaranth: Hi
<Amaranth> mjg59: you packaged aiglx, right?
<mjg59> Yes
<Amaranth> don't suppose you'd know why i'm getting ioctl(4, DECODER_SET_PICTURE, 0x7fb30fd8) = -1 EACCES (Permission denied) when i try running spiftacity
<Amaranth> that's from strace
<mjg59> Nope
<Amaranth> hrm
<Amaranth> makes it drop down to mesa indirect rendering which is slow
<Amaranth> and i get solid white window fun
<Amaranth> the only thing i could think of was bad permissions on /dev/dri/card0, but changing those doesn't seem to help
<Amaranth> brb
<Amaranth> ok, so it's definately aiglx's fault
<Amaranth> with xorg glxinfo doesn't give me that error
<Amaranth> wait, yes it does
<Amaranth> but direct rendering still works
<Amaranth> so it must be a worthless error message
<pitti> Good morning
<Rotund> anyone here have info about the QA position jdub advertised on his blog?
<pitti> Rotund: yes - http://www.ubuntu.com/employment
<Burgundavia> morning pitti
<pitti> Hi Burgundavia, how are you?
<Rotund> I was wondering more about things like "is it work from home?"
<Burgundavia> pitti: not bad. Grinding through the reviews on this Ubuntu book
<jdub> Rotund: no, it wouldn't be
<Rotund> jdub: where would one work from?
<jdub> Rotund: an office in montreal
<Rotund> jdub: any chance you could give me the information on how the organization would work?  (where on works from, general expected salary, benefits)  I'm currently quite happy with my job, but the prospect of working on Linux is quite appealling.
<Rotund> you answered the where already
<jdub> Rotund: you should reply to the job posting using the addresses provided :-)
<Rotund> I agree, but I was wanting a little background on the rest of what the job would entail.  I wouldn't want to apply for a job that requiring moving to Australia or such (no offense, just too far from home).  I suppose Canada also sets the "would I get health insurance?" answer =)  I'm certainly willing to take some "hit" to be able to work on Linux instead of killing people (in QA for military work now).  Anywho, thanks.
<jdub> Rotund: you don't have to apply to reply :-)
<jdub> ('course, i don't know if replying without applying would necessarily encourage a lot of answers, but you never know.)
<Rotund> cool.  thanks a lot.
<joelbryan> jdub: what do you think of this patch https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/34088 ?
<Ubugtu> malone bug 34088 in gnome-session "[PATCH]  Logo in Logout Dialog" [Normal,Unconfirmed]  
<jdub> joelbryan: it's really unnecessary branding, and looks pretty ugly actually - sorry
<Burgundavia> joelbryan: we try and avoid over branding the desktop. It makes it difficult for our derivatives
<jdub> that's not the reason why
<jdub> a huge part of it is that making our software look like a sponsored racing car with stickers all over it is just ugly and intrusive
<lifeless> yeah but racing cars get chicks in bikinis
<lifeless> if the software came with hot chicks in bikinis....
<Burgundavia> lifeless: down boy :)
<jdub> lifeless: we stopped shipping porn :)
<lifeless> jdub: and I still regret that ;)
<ajmitch_> lifeless: weren't you getting married soon? :)
<ajmitch_> hi viviersf 
<viviersf> yo ajmitch_ 
<viviersf> sup ?
<lifeless> ajmitch_: yes
<lifeless> ajmitch_: so the last time I'll ever have sex is approaching.... and ?
<ajmitch_> haha
<joelbryan> jdub: don't take those images personally, those where just my examples, I'm just helping the user what to expect with those button actions.
<jdub> joelbryan: an ubuntu logo doesn't help the user understand what to expect. tooltips would.
<jdub> better icons would.
<joelbryan> a message would.
<jdub> you can't put text in an image
<jdub> it won't adapt to the users font settings, or be translatable (without a lot of unnecessary work)
<joelbryan> I'm about to use Xegl with my s3 trio vc, i've been up all night.. how will i provide patches for xegl?
<wasabi> I really dislike the current dialog btw.
<Amaranth> send them to the xorg list
<wasabi> Just to voice my opinion.
<wasabi> 6 buttons is too much.
<Amaranth> wasabi: i'm just happy we got out logout menu item back :P
<joelbryan> Amaranth: xorg?
<ajmitch_> wasabi: yeah, that opinion has been voiced a bit :)
<wasabi> It's not clear or easy at all.
<Amaranth> err, our
<wasabi> I like apples.
<joelbryan> is not in ubuntu?
<wasabi> You click shutdown, it asks you if you want to.
<wasabi> Simple.
<Amaranth> joelbryan: xegl? no
<wasabi> I don't propose to know where to put all the other options. ;)
<joelbryan> I can now use vesa with xegl and compiz
<Amaranth> joelbryan: no, you use vesa with xglx and compiz
<Amaranth> which would be...slow
<joelbryan> Amaranth: I'm close to it..
<Amaranth> xegl is something completely different
<wasabi> Also I think there is a big distinction between the two actions one might want to do: manage the machine, and manage the session.
<Amaranth> it's basically a rewrite of the xserver to run on straight OpenGL
<joelbryan> wasabi: yes, I think 6 buttons is too much.
<joelbryan> there should be a way to hide those icons
<jdub> wasabi: that's what every other system (including GNOME 2.14) does
<wasabi> There are too many options also. I just don't know how to fix it.
<jdub> wasabi: fix == revert to GNOME 2.14 setup :-)
<wasabi> what the heck is the diff ebtween sleep and hibernate?
<wasabi> even i don't know.
<Amaranth> doesn't gnome-panel upstream basically have a copy of what OS X does?
<jdub> sleep == ram, hibernate == disk (hibernate means you won't lose your session ever, whatever your power status)
<jdub> Amaranth: roughly
<Amaranth> wasabi: these are windows terms :P
<wasabi> Here's an interesting question.
<wasabi> I know this will be weird. ;)
<wasabi> Why would you ever want to Shutdown, if you have Sleep and Restart available?
<Amaranth> jdub: last time i checked the text was _exactly_ the same, gnome just had an extra button
<wasabi> ANd Hibernate.
<joelbryan> how about expander? titled "Other Options" and Sleep, Hibernate, Switch user and Lock screen"
<Amaranth> wasabi: drivers suck
<wasabi> Amaranth: excuse. :)
<Amaranth> wasabi: zombies?
<lifeless> wasabi: because
<Treenaks> Amaranth: fix the zombie-causers ;)
<wasabi> Amaranth: reboot.
<wasabi> heh
<Amaranth> Treenaks: you mean make burning a cd not suck? :)
<wasabi> Reboot, Sleep, Hibernate.
<jdub> joelbryan: that just gets in the way. look at the way it's done in GNOME 2.14 - much clearer.
<Treenaks> Amaranth: I've never had zombies while burning CDs; zombies hate fire :P
<Amaranth> wasabi: so now i have to reboot, wait for the computer to come back up, then sleep?
<Burgundavia> I would even elimine hibernate
<wasabi> Amaranth: why would you?
<joelbryan> and the logout  _icons_ are not themeable
<Burgundavia> if you select sleep, the system also hibernates at the same time
<minghua> wasabi: when you want to change harddrive? ;-)
<jdub> joelbryan: they will be
<Burgundavia> thus if you lose power, you get the same session regardless
<wasabi> Pssh. I know. I'm just bring up stupid points.
<Amaranth> wasabi: i'm taking the computer somewhere and want to clear out zombies
<joelbryan> I can fix it!
<Amaranth> :P
<jdub> Burgundavia: it takes a lot longer (and more power) to hibernate
<wasabi> Well, I still maintain there is a very big difference between session and power management.
<jdub> Burgundavia: other systems sleep until there's only enough battery left to hibernate, then they hibernate and switch off
<wasabi> And there's no reason to combine the two.
<Burgundavia> that is the other solution
<Burgundavia> I wondered if that was possible
<wasabi> System > Power;  System > Exit
<jdub> wasabi: with different strings
<wasabi> Power brings up *simple dialog*, Shutdown, Restart, Sleep, Hibernate.
<joelbryan> the hibernate feature in flight cd 1 works for me, but now I got the latest release, hibernate doesn't work anymore.
<jdub> wasabi: mark's rationale is that users want a single "go away now" button
<wasabi> jdub: well they have 7.
<wasabi> now.
<joelbryan> how about Mac OSX style?
<wasabi> The simple "go away" button should be on the front of their case.
<wasabi> WHen you press it, it hibernates.
<wasabi> Heh
<jdub> wasabi: no, one single button to get to that point
<wasabi> Well, I don't see why.
<wasabi> Pssh and even then, the string is named Log Out $user now.
<joelbryan> I'll make a patch, of what other possible looks for hiding other things.
<wasabi> Which might not be accurate if you don't actually log out.
<wasabi> System > Exit.
<wasabi> That might work. :0
<jdub> joelbryan: GNOME upstream does it 'Mac OS X' style.
<joelbryan> cool!
<jdub> wasabi: it will be changed to 'Quit', I believe
<wasabi> I can handle that.
<wasabi> Still think the big dialog is too unweildy, though.
<wasabi> It takes me time to scan it.
<joelbryan> the only visible option is Logout, Restart, Shutdown. and other will be clickable.
<Burgundavia> wasabi: there is a bug open fot it
<lifeless> so whats the ui sprint been all about ?
<wasabi> Anyways, my desktop rocks. That is all.
<wasabi> Good night.
<jdub> lifeless: polish.
<lifeless> you don't mean western europeans with funny accents do you ?
<Burgundavia> jdub: what are you thoughts on the WinFoss stuff on the cd?
<jdub> Burgundavia: i like it. what are you asking?
<Burgundavia> jdub: just wondering. I have two minds. One part of me says get rid of it, due to space. The other part wonders if we are under utilizing the marketing potential there
<jdub> we're not telling enough people about it
<jdub> if there's space there, it's useful
<Burgundavia> should we add a note to the download page about the windows stuff?
<jdub> and the CD cover
<Kamion> 06:04 < jdub> Rotund: an office in montreal
<Kamion> jdub: er - are you sure you aren't confusing support and QA there?
<Kamion> jdub: last I checked (when I was interviewing a candidate for the QA position), the QA job was work-from-home
<Burgundavia> ie "This cd also contains Free/Open Source Windows software"
<jdub> Kamion: oh, i must've missed his mention of QA
<CarlFK> shouldn't there be a dapper entry? http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=libmjpegtools0
<ajmitch_> CarlFK: try libmjpegtools0c2a
<CarlFK> roger
<carlk> lives: Depends: libmjpegtools0 (>= 1:1.6.3+rc2-0.0ubuntu2) but it is not installable
<ajmitch_> file a bug on it
<carlk> I was wondering how to ask... thanks
<ajmitch_> morning pitti 
<pitti> hi ajmitch_ 
<dAndy> Kamion: anymore I can do on the debian-installer nfs stuff?
<sivang> morning all
* sivang runs out
<Kamion> dAndy: I've punted to the kernel guys for now
<dAndy> Kamion: saw that, sounds good, thanks
<ajmitch_> morning mvo 
<mvo> hello ajmitch_
<Burgundavia> mvo: morning. Where are you at with automaticupdates? It is dying on being run for me
<Mithrandir> ogra: apparently, gss doesn't do the "let's lock every five minutes" dance if g-p-m is running..
<mvo> Burgundavia: dying in what way?
<ogra> Mithrandir, ah, intresting 
<tepsipakki> uhm, the current mountnfs doesn't mount nfs4-shares, because they need rpc.idmap/rpc.gssd running which are started by nfs-common
<Kinnison> Morning guys
<JaneW> ping: BenC, dholbach, fabbione, infinity, iwj, jbailey, heno, Kinnison, keybuk, ogra,  seb128, sivan ,Riddell -> meeting
<fabbione> i am here
<CarlFK> no dapper-live.jigdo ?
<Mithrandir> CarlFK: it wouldn't make any kind of sense.
<CarlFK> Mithrandir: there are ones for server and desktop
<CarlFK> desktop = .. um.. normal
<Mithrandir> CarlFK: do you know how jigdo works? :-)
<CarlFK> yup
<CarlFK> you? ;)
<Mithrandir> yes
<Mithrandir> given that you most likely don't have a local mirror with something resembling casper/filesystem.squashfs jigdo would just give you a 500MB-ish .template file.
<CarlFK> good.  I have ubuntu and -userver.  I bet the live CD uses many of the files from those, I bet I am close
<Mithrandir> no, the compression on the live cd is different than in the .debs
<Mithrandir> just use rsync instead.
<CarlFK> ahh right 
<CarlFK> you should have asked me if I knew how the live CD was ... um.. compressed.
<CarlFK> ;)
<Mithrandir> heh
<CarlFK> you seem on top of this - is there an RSS feed that anounces when new .torrents are up?
<Mithrandir> not that I know of
<Mithrandir> we do put them up daily or more often, though
<CarlFK> yeah - I cron/wget the .torrents evey hour between 1 and 5am so that by 7 BT has it
<CarlFK> Mithrandir: got an e-mail addr I can send a write up I did on combining BT with jigdo?
<Mithrandir> CarlFK: what kind of write-up?  As in, to me, or to upstream or .. ?
<CarlFK> I was posted to the jigdo list, but that is the deades list ever
<CarlFK> to someone ;)
<Mithrandir> debian-cd@lists.debian.org, possibly?
<CarlFK> to whoever is interested in reducing server/mirror load
<CarlFK> ug.. antother list ;)
<CarlFK> but ok
<Mithrandir> you can post to it without being subscribed
<CarlFK> if someone thinks it is the right place, ill post
<Mithrandir> I'd guess it might be, at least.
<CarlFK> well, it is on 90% baked - I want to be around for the response 
<CarlFK> have the signup url handy?
<Mithrandir> echo subscribe | mail debian-cd-request@lists.debian.org, iirc
<Kamion> http://lists.debian.org/debian-cd/
<CarlFK> thanks 2x
<maswan> CarlFK: it's fairly low traffic. reducing server load isn't a huge priority though.
<Mithrandir> maswan: but shiny stuff is, isn't it? :-)
<maswan> Mithrandir: sure
<CarlFK> lol
<CarlFK> swell
<CarlFK> maybe this will fall into that category ;)
<maswan> CarlFK: doing torrent seeding with just a main mirror and a jigdo+template file?
<CarlFK> yup
<CarlFK> BT can update a dir of files without too much "waste"
<CarlFK> so use BT to move the files around and jigdo to assemble the .iso
<maswan> ah
<maswan> that way around
<CarlFK> speaking of BT - dapper-live-i386.iso.torrent has been looking for a seed for 20 min
<Mithrandir> CarlFK: but as I said, generally it's just as useful to just use rsync to update the ISOs.
<CarlFK> im trying to be nice to your servers ;)
<CarlFK> but okee dokee - i can do rsync... I sync I have that url around here somewhere
<Mithrandir> cdimage.ubuntu.com::cdimage/daily-live/current/dapper-live-i386.iso
<CarlFK> thanks
<seb128> jdub: around?
<infinity> siretart: That changelog for ia32-libs-sdl doesn't really seem right. :)
<Kamion> I noticed that, but the package itself seemed O
<Kamion> K
<siretart> gnarf. this was the result of the confusion about the name yesterday
<infinity> siretart: The name, whether or not it contains libasound (it doesn't, right), etc...
<infinity> siretart: IOW, the whole chanelog looks wrong.  <grin>
<siretart> infinity: I'll fix it in the next upload, okay?
<infinity> siretart: Yup, I've got nothing against revisionist history in changelogs. :)
<siretart> Kamion: btw, I uploaded a package for multiverse, x264 some time ago. was it rejected? is it still in NEW?
<pitti> Kamion: mozilla-thunderbird-locale-{ca,de,fr,it,nl,pl,uk} sources+binaries can be removed
<pitti> Kamion: also, I think that the new binaries from thunderbird-locales are in NEW
<Kamion> siretart: still in NEW, sorry, I think I was too scared to do multiverse stuff
<Kamion> pitti: queued
<Kamion> pitti: don't see them there
<siretart> ah, okay
<pitti> hmm
<siretart> Kamion: its basically taken from marillat. we have already a bunch of other packages from him in multiverse, so I thought that would be okay for multiverse
<pitti> Kinnison: I uploaded a new source thunderbird-locales yesterday, the debs are mostly NEW, but they aren't in the NEW queue; any idea what happened to them?
<Kinnison> Not without looking
<Kinnison> Give me 10 minutes and then I'll go look. If Kamion hasn't found them in the meantime :-)
<Kamion> siretart: oh, probably, I just don't entirely know the ropes on what we allow
<Kinnison> Kamion: ^^^
<pitti> Kinnison: maybe they have the same fate as yesterday's disappeared/rejected poppler debs
<Kinnison> maybe, but without my usb keyfob I can't do anything and I'll get yelled at if I go back into the bedroom before rob's ready :-)
<Kinnison> pitti: right, gotta restbreak now before my computer explodes at me, will look the moment I get back
<Mithrandir> Kamion/mdz: any chance of an UVF exception for tailor?  We have 0.9.19-2, a trivial recompile of 0.9.20 works correctly with bzr in dapper.
<pitti> Kinnison: enjoy breakfast :) thanks
<infinity> Kamion/mdz: While you're in the UVF mood, I need a UVF exception for the latest fglrx (adds support for more ATI cards to the binary driver), and minor bump for AVM Fritz (and amd64 only) to make doko's isdn doohickey like him better.
<pitti> how can I edit my bug contacts in Malone?
<Kamion> Mithrandir: link to the upstream changelog?
<Kamion> infinity: that one I think I'll leave to mdz :-)
<Kamion> pitti: +subscribe on the relevant source package
<pitti> ah, thanks
<Kamion> linked as "Bugmail Settings" in the right-hand-side portlet
<Kamion> pitti: no idea what happened to thunderbird-locales, I can't find it in lp_archive's mailboxes?
<Kamion> Kinnison: where else should I look other than /var/mail/lp_archive and ~lp_archive/mbox?
<infinity> Kamion: Spoilsport.
<Mithrandir> Kamion: http://progetti.arstecnica.it/tailor/timeline?from=23%2F12%2F2005&daysback=42&milestone=on&changeset=on&update=Update is the clostest I could find.
<Kamion> Mithrandir: ok, go ahead
<Kinnison> Kamion: /srv/launchpad.net/builddmaster
* Kinnison goes to look anyway now
<CarlFK> is launchpad the place for:  live cd, f1 for help, f3 for "boot methods" - the text says do this and that at "the boot prompt" but that went away
<Kinnison> pitti: 
<Kinnison> 15:32:16 INFO    Rejected: 15:32:16 INFO    mozilla-thunderbird-locale-de_1.5ubuntu20060130_all.deb: Version older than that in the archive. 1.5ubuntu20060130 <= 1:1.0.7-1ubuntu1 
<pitti> Kinnison: argh, I love epochs
<Kinnison> :-)
* Kinnison hugs pitti 
<pitti> Kinnison: sorry for bothering then
<Kinnison> that's okay
<Kinnison> I need to find some way to append the upload log to the build item I think
<Kamion> CarlFK: you can still just press enter ... it's just that the "boot prompt" is now a full screen
<Kinnison> it'd help
<Kamion> CarlFK: if you want to file a bug, use the debian-installer source package (which for a change is actually accurate, not a catch-all)
<CarlFK> heh ;)
<pitti> Kinnison: any idea what's wrong with the poppler debs?
<ogra> Kamion, do you know if there is winfoss on my edubuntu live cds ? (i actually never tested it but i'm a bit shocked by 30MB overhead on amd64)
<ogra> (is there a way to find that out easily ?)
<doko> Kamion: now that libgcj-common is built from gcj-4.1 it should be possible to demote the gcj-4.0 source to universe. maybe manual intervention is needed for the cyclic gcj-4.0/libgcj6-dev dependency
<Kinnison> pitti: kamion told you what was up. the control file was misformatted (or have you fixed that now?)
<pitti> Kinnison: oh, I didn't see that; seb128, did you? ^
<seb128> no
<seb128> how misformed?
<seb128> misformated
<Kinnison> the description for libpoppler1 I think
<Kinnison> certainly the libpoppler1 deb is missing a Description field so it can't be imported into the archive
<tepsipakki> bah, nfs-utils is b0rked nfs4-wise.. need to package it myself
<seb128> Kinnison: ah right, thank you
<Kinnison> seb128: should be an easy fix :-)
<seb128> Kinnison: would be nice to have some mail for soyuz in that case :p
<Kinnison> seb128: yeah, it's hard to decide what to do when a binary upload fails
<Kinnison> seb128: I'm fairly sure katie dropped it on the floor too
<Kamion> ogra: no, there isn't
<seb128> tell the maintainer seems to be useful in any failure case, no?
<Kamion> ogra: look in colin.watson@canonical.com--2005/cdimage--mainline--0 bin/find-live-filesystem
<Kamion> seb128: not really, often causes maintainers to randomly work around things that are actually a buildd problem
<ogra> thanks 
<seb128> Kamion: right
<Kamion> seb128: although I agree with you in the case of binary upload failures, just not "any failure case"
<Kamion> doko: cyclic dependencies shouldn't confuse germinate/anastacia
<Kamion> for poppler, there was a tab or spaces or something before Description in the control file
<Kinnison> To be honest, that *ought* to have failed the package build
<Kinnison> we should try and teach dpkg-gencontrol some basic requirements
<Kinnison> IMO
<Kamion> doko: libcommons-net-java in main build-depends-indep: gcj-4.0
<doko> Kamion: ok, thanks, forgot the build-deps ...
<mdz_> infinity: back online now, what's up?
<infinity> mdz_: Just mailed you.
<Kamion> see http://people.ubuntu.com/~cjwatson/germinate-output/dapper/rdepends/gcj-4.0/
<doko> Kamion: is there a script to tell you about source packages with binaries both in main and universe?
<infinity> mdz_: Re: UVF exception for AVM Fritz and fglrx.
<Kamion> doko: no, but that isn't a bug ...?
<doko> Kamion: just wanted to look at these packages
<Kamion> doko: using germinate is really the easiest way to find this stuff out - it's packaged, you can run it yourself
<Kamion> if the reports on the web aren't enough (which they aren't always, since http://people.ubuntu.com/~cjwatson/germinate-output/ is i386-only at the moment)
<Mithrandir> is there any way to make gaim _not_ pop up the main window when it reconnects?
<sivang> Mithrandir: should be somewhere in the preferences I thin
<Kamion> Diziet: could you arrange to add autopkgtest to some appropriate seed so that it can be promoted to main? Ubuntu supported would be fine
* ogra ponders where to rip out 1.2MB from the amd64 CD ...
<Treenaks> ogra: xserver-xorg
<ogra> haha
<ogra> yes, since we will ship with Xgl (as heise.de reported) :P
<dholbach> Their Ubuntu-News-Department is a bit ... erm ... confused.
<ogra> (they call it the most notable improvement btw)
<ogra> heh ...
<ajmitch_> heh
<ogra> it always was
<ajmitch_> and people complain about how unstable Xgl is - as if a cvs dump is going to be perfectly stable & amazing
<ogra> heh
<ogra> yes
<Pygi> ajmitch: XGL works fine here ^^
<ajmitch_> Pygi: that's great, but it doesn't mean it'll work fine for everyone :)
<Pygi> ajmitch: true ^^
<Kinnison> Kamion: one day I'll look back at this week and laugh, until then, I hate everyone who managed to get me anywhere near gtkmm, okay?
* Kinnison will have this gparted stuff finished fairly soon
<Kamion> Kinnison: :-/
<Diziet> kamion: Willdo.
* Mithrandir hugs Kinnison 
<mdke> Kinnison, if you're on gparted and want an easy bug to close, would you take a look at bug #33866?
<Ubugtu> malone bug 33866 in gparted "HIG compliant menu entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/33866
<azeem> (W 31
<azeem> bah, sorry
<Kinnison> mdke: urgh, I'm kinda just hacking on the stuff for the installer
<Kinnison> mdke: If you can attach a patch to that bug, I'll drop it into the package before I upload
<mdke> Kinnison, ok
* ogra eeks loudly ...
<ogra> "Assignee: (unassigned) => Ubuntu Core Development Team"
<ogra> meh
<Mithrandir> is there anything like viewcvs for bzr?
<Kinnison> there have been various attempts at it. Dunno if anyone has kept any of them up-to-date with the api
<lifeless> Mithrandir: yes
<lifeless> bzr webserve
<lifeless> its a plugin, link on the wiki, maintained by goffedo barcelloni
<Mithrandir> uh, so bzr is then running continiously?
<lifeless> yes. there are cgi like ones around too
<lifeless> but not as nice ;)
<sivang> lifeless: does it uses mod_python ?
<janimo> mvo, hi got my mail yesterday?
<mvo> janimo: yes, but I haven't read it yet, sorry
* pitti tests live CD and espresso, bbl
<lifeless> sivang: not sure
<ogra> lifeless, it urgently needs the little subway map bzrk uses :)
<ogra> (makes me feel like railroad tycoon while using bzr ;) )
<mdke> Kinnison, there is a patch on bug #33866 for you, hope it works
<Ubugtu> malone bug 33866 in gparted "HIG compliant menu entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/33866
<Kinnison> thanks, I'll look later when I'm less confused :-)
<mdke> cool
<doko> lamont, infinity: please requeue mdbtools on ia64
<mdke> Kinnison, i'll assign you the bug so you can see it whenever is convenient
<Kinnison> thanks
<pitti_live> espresso is funny - it doesn't reformat my fat partition, but if I reformat it as reiserfs, it does format it as ext2...
<Seveas> who made splash-down?
<pitti_live> Seveas: infinity
<Seveas> k
<Seveas> then I'll have to poke him via malone
<pitti_live> Kinnison: are espresso partitioner bugs yours now? or fabbione's?
<Treenaks> Seveas: why? :)
<fabbione> pitti_live: my code didn't land yet :)
<fabbione> pitti_live: it can't be my bug
<Kinnison> pitti_live: I think for now they're kamion's
<Kinnison> pitti_live: I'm working on the gparted/espresso integration but that's it currently
<Seveas> Treenaks, kaarsemaker.net/~dennis/splash_down_b0rken.jpg
<Treenaks> Seveas: nice colors
<pitti_live> Kinnison: alright
<Seveas> urgh, why can't malone sort searches :S
<Seveas> hmm, it can - ok why does firefox break when hovering over a link?
<infinity> Seveas: On boot, your splash has correct colours, though?
<sivang> ogra: is bzrk a complete frontend in GTK for bzr, or just shows the revision tree?
<Seveas> infinity, yes
<Seveas> infinity, it was filed in malone already, I added a comment and subscribed you
<Kinnison> sivang: It just visualises the ancestry
<ogra> and has a quite cool patchviewer included :)
<Kinnison> aye
<highquality>  laptop for sale 500$ want it gone today. price includes shipping, case, wireless router. message me if interested on aim at ogd443 or msn at mcsltd2@hotmail.com
<Seveas> highquality, bugger off...
<Kamion> seb128: (or anyone) shouldn't libpoppler1-qt depend on libqt somehow?
<pitti> wohoo, my first finished espresso installation
<pitti> Kamion: I collected a bunch of bugs on my paper sheet here; what do you generally prefer, malone spam or talking about the bugs in IRC before?
<Seveas> pitti, search malone for espresso bugs first - there already are quite a few of them ;)
<pitti> yes, of course
<Kamion> pitti: malone
<jbailey> mdz: g'm!  I uploaded at to hoary-updates a while ago, and haven't seen it in the archive, and I don't think I've seen a rejected note.  Is it still in the queue for processing?  I don't think I can see into it.
<Kamion> pitti: the format thing is one I know about, it's just hardcoded to ext3 at the moment because nothing passes through the desired partition type
<Kamion> Kinnison and I taled about that one yesterday
<pitti> Kamion: alright, I'll file/comment on bugs
<Kinnison> jbailey: IIRC launchpad has no chroots for hoary-updates
<jbailey> Kinnison: Err, really? =)
<Kinnison> jbailey: indeed
<Kinnison> jbailey: so bug infinity to prepare some :-)
<jbailey> Would the same also apply to warty?
<jbailey> I have glibc updates for all current releases that need to go in, but I'd been waiting to see this one finished, and then got distracted with other things.
<jbailey> Kinnison: Should Launchpad notify me when an upload I've done is impossible to service?
<jbailey> (I'm wondering how I could've traced this)
<Kinnison> jbailey: No, we should have done the chroots by now
<Kamion> Listing ubuntu/hoary (UNAPPROVED) 4/4
<Kamion> ---------|----|----------------------|----------------------|---------------
<Kamion>     1832 | S- | at                   | 3.1.8-11ubuntu4      | three weeks
<Kamion>          | at/3.1.8-11ubuntu4 Component: main Section: admin
<Kamion>     2891 | S- | at                   | 3.1.8-11ubuntu5      | three weeks
<Kamion>          | at/3.1.8-11ubuntu5 Component: main Section: admin
* Kamion goes to have a look
<Kamion> Kinnison: if infinity creates the chroots, will they Just Work?
<Kinnison> Kamion: in theory, yes
<Kamion> jbailey: in atd.c, I'd have used %*s rather than dynamically constructing a format string, myself
<jbailey> Kamion: Patch pulled from newer version.
<jbailey> Kamion: It's not exactly as I'd have done it, but I wan't to show that I was just pulling back the fixes.
<Kamion> Kinnison: what will happen if I process the queue before that?
<jbailey> Kamion: If you'd prefer I can update with that, though.
<Kinnison> Kamion: the sources will go in and no binaries will build for now
<Kamion> jbailey: no, don't worry, just a comment
<Kamion> jbailey: er ... there were already 3.1.8-11ubuntu4 and 3.1.8-11ubuntu5 versions in breezy
<Kamion> indeed 3.1.8-11ubuntu5 is current in breezy
<Kamion> soyuz should really have rejected that IMO
<Kamion> jbailey: also, you appear to have missed at least one bit of the patch:
<Kamion> -    fprintf(fp, "#!/bin/sh\n# atrun uid=%d gid=%d\n# mail %8s %d\n",
<Kamion> +
<Kamion> +    fprintf(fp, "#!/bin/sh\n# atrun uid=%d gid=%d\n# mail %s %d\n",
<Kamion> (in at.c)
<jbailey> Kamion: In what way?  The point of the patch is that usernames aren't limited to 8 characters anymore.
<Kamion> jbailey: and I think also some free(mailname) calls in atd.c, so you probably have a memory leak
<Kamion> jbailey: the patch pasted above is in the hoary->dapper diff, but not in your upload
<infinity> Kinnison: I'll do chroots soon and we'll test this Just Works theory. :)
<Kinnison> infinity: :-)
<infinity> Kinnison: Does this mean *-backports is also good to go?  (I'd really love to clear all those PENDING backports builds out of the queue)
<Kamion> "I'd like to test that theory."
<jbailey> Lemme go through the patch diff again.  At this point, I don't really remember it.  I went through it at the time.
<Kinnison> infinity: in terms of building yes
<Kinnison> infinity: in terms of getting source in, dunnoi
<infinity> Kinnison: well, source must be there somehow.. Unless that source all came from the dak days...
<infinity> (Which is possible, I guess)
<Kamion> jbailey: anyway, I'll reject due to the version clash; it'll have to be reuploaded as 3.1.8-11ubuntu3.1 in any case
<Kamion> sorry for taking so long to look at it
<jbailey> Kamion: Is there something clever I can do with the version numbers to make this easier, like 3.1.8-11ubuntu3hoary1 or so?  That way for updates, I don't have to guess at numbers which don't conflict with random other things in the pool?
<jbailey> I don't know if issues would come up with 3warty1 being a higher number than 3hoary1 or so.
<infinity> jbailey: In security, we've taken to doing some sketchy things like 3.1.8-11ubuntu3.05.10 3.1.8-11ubuntu3.05.04 3.1.8-11ubuntu3.04.10
* Kamion files https://launchpad.net/products/launchpad-upload-and-queue/+bug/34210
<infinity> jbailey: So, lower than ubuntu4, higher than ubuntu3, and the dists are all in order.
<Ubugtu> malone bug 34210 in launchpad-upload-and-queue "should reject uploads whose versions already exist in other distroreleases" [Normal,Unconfirmed]  
* jbailey squirms.
<jbailey> Kamion: Thanks
<Kamion> jbailey: just check other versions in the pool first
<Kamion> if the version in the next distrorelease up is greater than the version in the distrorelease you care about, just use some non-clashing scheme such as -XubuntuY.Z
<Kamion> you only have to mess with .5.10 or whatever if the versions in several distroreleases are identical
<Kamion> (which wasn't the case for at)
<jbailey> Kamion: 'kay.  I was hoping for something to consistantly apply so that I can be lazier with it.  I'll look, though.
<infinity> Well, the .05.10 scheme isn't so ugly as a standard, once you get used to it.
<infinity> (and an update to that would be .05.10.1, then .05.10.2, etc.
<ogra> argl
<infinity> )
<jbailey> Right, looks sane enough.
<Kamion> the initial zero is a bit redundant; dpkg compares numeric portions of version numbers numerically anyway
<ogra> Kamion, linux-source upload .
<Kamion> so .10.4 > .5.10
<ogra> ...
<Kamion> ogra: yeah, I know, apparently we need it
<infinity> Kamion: yes, but it sorts nicely for humand when we release Ubuntu 10.04 :)
<Ubugtu> ubuntu bug 1 in openssl "openssl: Expired certificates and recertification" [Normal,Resolved: notwarty]  http://bugzilla.ubuntu.com/show_bug.cgi?id=1
<ogra> ah, k
<infinity> s/humand/humans/
<jbailey> Ubugtu: Why did you decide to say that? =)
<Kamion> surely anything presented to humans should sort by the canonical version ordering algorithm. :-)
<jbailey> Kamion: 'ls' in ftp isn't so compliant as that. =)
<infinity> Kamion: Yes, but humans like fixed-width numbers. :)
<infinity> Humans also like sleep, so this one should stop alluding to it, and get some.
<Kamion> somebody should hack ls --version into lftp
<jbailey> infinity: G'n adam.  Thanks.
<infinity> Kamion: How many times have I called you a "sick fuck" in the past?
<infinity> Kamion: I think I feel another coming on.
<Kamion> about a thousand
<Keybuk> Kamion: which one of the two canonical version ordering algorithms? :)
<Seveas> <jbailey> Ubugtu: Why did you decide to say that? =)
<Seveas> you ask an intriguing question...
<jbailey> Seveas: I do?
<Seveas> yes
<Kamion> I've accepted Tollef's evms hoary-updates upload to give the buildds some exercise
<Kamion> Keybuk: the one you meant, obviously
<Seveas> anyway, Ubugtu won't make such silly mistakes again - I adjusted the regex a bit
<ogra> Seveas, we wont talk often about ubuntu 10.04 yet i guess :)
<Seveas> hehe
<Seveas> the trick is that it was rigged up to exclude version numbers (like 2.12 or 5.04)
<Seveas> it just had a slight decennium problem
<Seveas> (10.04 would correctly not match, but the 1 would)
<Seveas> the regex now is: r"""\b(?P<bt>(([a-z] +)?\s+bug|[a-z] +))\s+#?(?P<bug>\d+(?!\d*\.\d+)(,\s*#?\d+(?!\d*\.\d+))*)"""
<ohoel> Has there been any talk about renaming a "repository" to a channel?
<Seveas> (which matches every line with an integer, there's more logic later to filter only real bugtrackers ;))
<ogra> :)
<Kamion> pitti: I'm a little mystified as to the necessity of xine-lib 1.0-1ubuntu3.4 in hoary-updates, although it looks OK (in that it's identical to hoary-security in all but the changelog)
<Kamion> ohoel: why?
<ohoel> ohoel: just wondering.. translating update-manager via gnomecvs... the latter case would make more sense in direct translation atleast
<Kamion> channel is more jargon and less understandable in English
<Kamion> to me at least
<ohoel> Kamion, We ship the one maintained in gnome cvs right?
<Kamion> ohoel: absolutely no idea
<Kamion> mvo would know
<ohoel> I'll just wait for mvo then ;)
<pitti> Kamion: AFAIR, I integrated the hoary-updates fix into hoary-security, so the -updates branch is obsolete anyway
<Kamion> should I accept it anyway in case we need to branch hoary-updates again? I guess that would make sense
<pitti> Kamion: same case with e. g. evolution; I'd love to actually remove obsolete -updates branches since it would avoid confusion (and clean up ubuntu-cve)
<Kamion> not sure I want to go there :)
<Kamion> I'll accept it for now, we can think about better solutions later
<pitti> Kamion: anyway, we have 3.3 in h-u already, so having 3.4 there doesn't do  any harm
<Kamion> right
<Kamion> that's hoary-updates unapproved empty, now just 13 entries in breezy-updates unapproved *sigh*
<jono> Keybuk, ping
<Kamion> Mithrandir: your evms upload to breezy-updates (2.5.2-1ubuntu1.1) seems to have a bunch of .po/.pot changes - intentional?
<Mithrandir> Kamion: no, not really.
<Kamion> Mithrandir: could you reupload with just the backported fix?
<Keybuk> jono: hey dude
<Keybuk> jono: why am I not getting a Thanks in your book; for all those burgers! :)
<Solatis> hey, which kernel version is currently active for dapper?
<Mithrandir> Kamion: sure.  I thought I did the right upload, but apparently not.
<jono> Keybuk, who said you don't get a thanks ?
<Keybuk> jono: am kidding just from your blog <g>
<jono> Keybuk, heh
<jono> Keybuk, thought you knew something I didnt there
<Keybuk> lol
<Keybuk> how goes it?
<jono> Keybuk, good, you?
<seb128> Kamion: dunno for libpoppler1-qt, according to ldd it doesn't link to it (which is weird)
<Keybuk> yeah am not too bad
<Kamion> Solatis: 2.6.15
<jono> Keybuk, can I ask a quick q?
<Keybuk> jono: sure, go for it
<jono> Keybuk, you good for your talk at RLL06 to be at 12pm on the Sat (22nd July) ?
<jono> LRL06 that is
<Keybuk> sure
<Keybuk> should be up by then :)
<Solatis> Kamion: ok thank you!
<jono> Keybuk, :)
<Mithrandir> \o/ *-desktop seems to be installable again.
<pitti> mvo: did you send your tetex-bin patch to Debian? ('remove the old formats before cleaning environment')
<mvo> pitti: no, but the debian package changed in this area already IIRC
<pitti> ah, ok
<bmonty> elmo: please sync m17n-db from debian unstable, UVF exception request was approved (Malone #33706)
<Ubugtu> malone bug 33706 in m17n-db "UVF exception request" [Normal,Confirmed]  http://launchpad.net/bugs/33706
<LarstiQ> where should I report the windows firefox on the dapper installcd being old?
<ogra> whats up with the archive mails, did yomething change ? seems my filters dont catch it anymore
<ogra> Mithrandir, does the above mean you create liveFS's ?
<ogra> (edubuntu could need a new one too)
<Mithrandir> ogra: no, we want the new kernel and some other bits in first.
<ogra> ah, k
<ogra> what are the other bits ? big stuff ?
<ogra> (i'm heavily under space pressure)
<Mithrandir> ogra: you need to fix your space problem, yes. :-)
<ogra> Mithrandir, could you trigger another livefs build anyway, i belive the last edubuntu-live fixes it
<Mithrandir> ogra: started.
<ogra> thansk a lot :)
<Mithrandir> then I'm off for an hour or so.
* Diziet boggles.  firefox's preinst has weird hackery for conffiles which contains the md5sums of (I think) some old versions hardcoded.
<ogra> boggle, what is gtk2-engines-ubuntulooks ? 
* ogra sees his CDs explode again
<highvoltage> ogra: a new human theme? :)
<ogra> might be ... the last bits that replaced something older were twice as big as their previous versions, thats waht i fear 
<jdub> ogra: new gtk theme :-)
<ogra> edubuntu already cant include the new asian fonts ... they add 2MB ... 
<ogra> jdub, bigger or not ? 
<ogra> i dont even have kilobytes left
<jdub> ogra: there's nothing very big about gtk engines
<ogra> then i'm fine
<ogra> jdub, i got the space pictures for the screensaver-default-image thingie... do you want to make the package or should i ?
<jdub> go for it
<jdub> separate source for great justice
<Kinnison> ogra: how come edubuntu is so much bigger than the other flavours?
<jdub> Kinnison: has to ship kde and gnome bits, for a start
<fabbione> Kinnison: for the extra junk^Wshiness
<ogra> Kinnison, we include 5 KDE apps 
<Kinnison> urgh
<Kinnison> fair enough
<ogra> Kinnison, that pulls in ~100MB of qt and friends :)
<jdub> 'friends
<jdub> '
<ogra> (the kde apps themselves are < 5MB )
<Kinnison> ogra: which QT apps do you need?
<ogra> kdeedu
<ogra> and scribus
<Kinnison> scribus? Isn't that essentially abiword for kde?
<ogra> nope
<ogra> thats pagemaker for linux ;)
<Kinnison> aah
<ogra> the best DTP we have
<highvoltage> i don't think scribus is widely used by edubuntu users, though.
<ogra> highvoltage, i had other impressions at times ... but you're the guy at the frontline :)
<jdub> yeah, seems like an odd ship-by-default choice for edubuntu
<ogra> i'm pondering to either drop kdeedu in dapper+1 or switching to 2 CDs
<ogra> but i'll do anything i can to avoid the latter
<highvoltage> :)
<highvoltage> at least you changed your mind from "no way" to "considering" for the 2 CD's :)
<ogra> nope, i'm considering for dropping kdeedu
<highvoltage> ah, ok.
<ogra> if that doesnt work at all 2 CDs are a (very very bad) fallback
<Kinnison> I take it that edubuntu doesn't ship with the gnome games etc?
<ogra> Kinnison, it ships with what ubuntu has, plus edubuntu-server and the edu apps
<Kinnison> ogra: aah
<ogra> thats what makes it big... and hard to maintain as well
<Kinnison> ogra: strikes me that removing some of the ubuntu stuff might be worthwhile
<ogra> Kinnison, yes, but i wont cripple the core desktop ...
<Kinnison> fair enough
<Kinnison> Switch to DVD-only distribution?
<Kinnison> that'd give you loads of room :-)
<tseng> how much of the target audience has a dvd burner
<tseng> (none)
<ogra> the right way is to find proper replacements for kdeedu in the gnome world and get rid of tens of MBVs of libqt/kdelibs overhead
<fabbione> Riddell, ogra: i just updated kubuntu and edubuntu seeds for the new kernel with ABI changes.
<ogra> meh
<ogra> i'm in the middle of some test iso builds for the space probs
<fabbione> ogra: without ABI you won't have a kernel in about ~20 minutes
<ogra> fabbione, i have the one i had yesterday :) 
<fabbione> ogra: i can revert the change if you want
<ogra> but without meta package it wont do no harm 
<highvoltage> Riddell: does kde-edu ship with the kubuntu CD?
<Riddell> don't worry fabbione, I love you
<Riddell> highvoltage: no
<highvoltage> ok.
<fabbione> Riddell: i am not :)
* Kinnison makes more plaintive noises about gtkmm and recompiles gparted once more
<ogra> yeah gtkmm is fun :P
<ogra> (rewrite it in pygtk ;) )
<tseng> or snuggle up to dh
<tseng> dholbach
<ogra> heh
<Kinnison> snuggling with dholbach won't help now, despite how nice it might be
<Kinnison> ogra: that's the post-dapper idea
<ogra> yeah
<ogra> (considering what has all been kept back for dapper+1 it must become a pretty weird freakshow of feature :) )
* highvoltage can't wait
<Kamion> fabbione: no point reverting the change for edubuntu; once d-i lands, building working images without updated seeds will be impossible anyway
<Kamion> LarstiQ: I think you must mean the live CD (the Windows stuff isn't on the install CD), but don't bother, we just updated it today as it happens
<LarstiQ> Kamion: you're probably right
<Kinnison> Kamion: at last:
<Kinnison> Kamion: http://rafb.net/paste/results/OKJfXl36.html
<Kamion> hooray
<ogra> okay ... edubuntu-live is tamed :-D
<pitti> ogra: I saw you dropping language packs :'-(
<ogra> pitti, only german ... nobody needs that ;)
<pitti> ich nicht spreche deudsch
<ogra> heh
<highvoltage> deutch?
<jdub> is 'deudsch' like surfer-german?
<ogra> i'll look what i can do for final ...
<ogra> its just weird german :)
<pitti> highvoltage: nevermind :)
<highvoltage> jdub: yeah, like L.A. surfer german, dude
<Keybuk> I didn't think Germany had a coastline ...
<jdub> i am with my deudsch, ridin' the waves on berlin beach
<Kinnison> Kamion: All I have to do, to ensure that espresso doesn't explode with this gparted is to change the line where it reads the response from gparted
<ogra> Keybuk, haha ...
<pitti> Keybuk: I'll show you both the Baltic and the North sea then :)
<Keybuk> pitti: my geography isn't great, though ;)
<Kinnison> Kamion: If you want, you can do the obvious fix there and I'll just punt gparted at the archive, conflicting with whatever is there currently
<jdub> Keybuk: that's why they invaded poland. needed the coastline.
<Keybuk> jdub: dude, don't mention the war!  that's so not shiny
<ogra> pitti, my prob is that each lang in edubuntu is about 5-15Mb bigger than in ubuntu ... i ship kde and gnome langpacks for each lang
<jdub> lies
<jdub> the german uniforms were very shiny
<ogra> Keybuk, its fine, just dont do it while being in germany :)
<pitti> alright, bus comes in 10 minutes, cu tomorrow!
<Keybuk> ogra: with my german, they wouldn't understand what I was saying anyway
<Kinnison> Keybuk: that's because you use too many lls, chs and ws in whatever foreign language you speak :-)
<jdub> haw haw haw
<ogra> i'm sure they would, you got enough colleagues around you all the time for translation, i'm sure :)
<Keybuk> Er erwhnte den Krieg! erhalten Sie ihn!
<ogra> erhalten ? 
* Keybuk points at babelfish
<ogra> ah, you meant keep :)
<Keybuk> "get" apparently
<ogra> haltet ihn !
<seb128> Kamion: can you accept/promote ubuntulooks when you get it to NEW?
<seb128> Kamion: that's the new GTK theme
<Kamion> Kinnison: if you could send me a branch or patch or whatever that'd be better - I'm up to my elbows in the userinfo page at the moment
<Kamion> seb128: ok, please seed it
<seb128> Kamion: ubuntu-artworks Depends on it
<Kinnison> Kamion: sure
<Kinnison> Kamion: I'll say when I've pushed
<Kamion> seb128: ok
<Kamion> seb128: (grr. folks are trying to prepare CDs at the moment, please don't break dependencies)
<seb128> Kamion: some UI sprinter really wants new theme to work though ...
<seb128> Kamion: I'm sorry if I broke the CD but UI freeze is today and we better to push the new theme now
<ogra> seb128, i dont even have got my official final theme for edubuntu, cant be that urgent 
<seb128> ogra: you are not in London for UI sprint this week neither ...
<ogra> seb128, sadly not ... 
<ogra> edubuntu would have benefited from that ...
<Mithrandir> Keybuk: is modprobe -Q accepted upstream yet?
<ogra> seb128, especially sinc you have the disgnners there that make my artwork
* ogra stares at his fingers ...
<Keybuk> Mithrandir: don't think that one is
<ogra> ohoel, is that the equivalent to depmod -Q ?
<ogra> grmbl
<ogra> s/ohoel/oh
<ohoel> everybody does that ;] 
<Mithrandir> Keybuk: it'd be nice to push it upstream and/or into Debian so I don't end up with gratious when people adopt casper in Debian
<ogra> my xchat started recently to autocomplete on commas ... no idea why ...
<seb128> they changed the default from ":" to "," I think
<Keybuk> Mithrandir: I did send it to Rusty, but he pushed back
<Keybuk> I think it's in Debian
<Mithrandir> Keybuk: doesn't look like it.  -q is, though.
<Keybuk> if it's not in Debian, it's because Md didn't want it I guess
<Keybuk> he's had the patch
<Kinnison> Kamion: pushed to http://people.ubuntu.com/~dsilvers/bzr/espresso/gparted-updates
<Kinnison> Kamion: gparted upload ready to rock and roll when you are
<hub> hi
<hub> I have an issue
<highvoltage> #ubuntu?
<hub> the issue is that some patches are applied to fix bug in some package
<hub> and upstream never got them
* hub is upstream in that case
<hub> example: https://launchpad.net/distros/ubuntu/+source/libgphoto2/+bug/18409
<Ubugtu> malone bug 18409 in libgphoto2 libgphoto2-2 "Problem importing photos from hp photosmart 850" [Normal,Fix released]  
<hub> the fix it the debian packages. but the cvs does not have them because no bug has been filed upstream
<hub> nor the maintainer emailed about it
<ogra> but you could apply them to the ubuntu package, cant you ?
<seb128> that's a people issue
<seb128> hub: you should ping who did the upload rather, but that happens, there is stuff not sent upstream
<hub> ogra: they are in the ubuntu package. but I'm talking UPSTREAM
<hub> I commented the bug anyway about that
<hub> and I filed a bug in Debian for the same thing
<Kamion> seb128: UploadError made it out to the main loop: Unable to find distrorelease: unstable
<Kamion> seb128: ubuntulooks
<seb128> arg
<ogra> hub, about time you start working towards main maintenance, eh ? so you can send the patches yourself :)
<seb128> Kamion: thanks (hate working from my laptop)
<hub> ogra: I was going thru the changelog reading the package diff
<hub> so that is a pure coincidence
<hub> I have a 2.1.99.1 release to make
<seb128> Kamion: fixed version uploaded
<hub> seb128: re: working on laptop: that's why I have strong requirement on laptop choice, hence making my choice limited
<hub> seb128: and IBM/Lenovo have the best keyboards ever
<highvoltage> hub: i totally agre. nothing beets a thinkpad keyboard!
<highvoltage> (although some of the new lenovo keyboards have windows buttons on them- yuck)
<hub> highvoltage: my PowerBook G3 was okay, so did the PowerBook G4 (Ti)
<hub> highvoltage: mine has it. but it is easier to live with than the Microsoft tax I had to pay on the unused disk space
<highvoltage> yeah, i (or the company i work for) had to pay that too :(
<hub> highvoltage: in my case it is my CreditCard
<ohoel> ECS laptops tend to have fantastic keyboards too
<Kamion> seb128: source accepted - unfortunately I won't be able to process the binaries now until rather later this evening
<mjg59> ohoel: You have got to be kidding me
<ogra> that leaves me time to land a ltsp fix, before flight 5, great :)
* ogra loved the old sony laptop keyboards ...
<ogra> i never had such a good one again ...
<ohoel> mjg59: the g556... mmm
<Kamion> Kinnison: Depends: gparted (>= 0.1-0ubuntu2); Conflicts: gparted (<< 0.1-0ubuntu3) is a bit daft :-) I'll consolidate those into a single Depends
<Kinnison> Kamion: oops, yes
<Kinnison> :-)
* Kinnison didn't spot that
<Kamion> Kinnison: ready to upload when you are
<Kinnison> dputting now then
<hunger> Is it normal that changing themes crashes *all* gnome apps?!
* hunger tried all kinds of widget themes and suddenly all apps died one after the other.
<mdke_> does anyone know what the decision is on whether the battery icon from g-p-m is shown by default while charging? the consensus on the desktop list seems to be fairly resoundingly in favour of "yes".
<Kamion> Kinnison: uploaded
<Kinnison> Kamion: rock on
<janimo> hunger: I saw that too in xfce but with firefox only
<hunger> It is the "Raleigh" theme that does that here... I am filing a bug about that.
<janimo> and it was along freeze rather than a crash
<mdke_> Kinnison, thanks for the gparted patch
<Kinnison> mdke_: y'welcome
<mdke_> Kinnison, you do g-p-m right? do you know the answer to my question above about icon-when-on-AC?
<Kinnison> mdke_: the default icon policy is 'charge' which means it will
<mdke_> hmm
<mdke_> so the thread on the desktop list is based kinda on a false premise, i.e. that it isn't
<Kinnison> well yes
<Kinnison> the default policy has been 'charge' for some time now
<mdke_> right
<mdke_> thanks
<hunger> janimo: I get a pop-up informing me about the crash, one per app.
<hunger> Just got a message that my panel is still running on login.
<hunger> So I slayed (aka. send a kill signal) to all processes of that user... which locked up my box hard (no ping, nothing:-()
<seb128> known bug
<hunger> seb128: Good! Then I do not need to send a bugreport:-)
<mdke_> Kinnison, oh hang on, it doesn't display when _fully charged_?
<seb128> no need ;)
<slomo> Kamion: please promote mono-tools (and nant/nunit) to main... main inclusion reports were approved by pitti more than a week ago :)
<Kamion> slomo: already done earlier today
<slomo> Kamion: oh cool... didn't notice it yet. thanks :)
<hunger> seb128: Wait a sec... is it a known bug that the panel stays around after a logout or that the bex freezes when killing all processes of a user?
<hunger> s/bex/box/
<seb128> panel staying around, there is some bugs about it
<seb128> freeze the box is a linux issue
<seb128> no app can freeze a box
<seb128> or xorg issue if it breaks all the input
<hunger> seb128: I know...
<hunger> seb128: but it still is a bug (even though I have no idea what to report that against, so I won't).
<seb128> sure it is, but probably not easy to figure it
<hunger> Might be X or kernel...
<seb128> need a good bug with backtrace, stracing, log, etc
<hunger> seb128: Yes:-( But I can't get that from my frozen box. So let's just assume it never happened;-)
<Kinnison> mdke_: well once fully charged, it's no longer (dis)charging so no, by default the icon does not display under that circumstance
<Diziet> Damn, I forgot to prime my ccache and now this ff build is taking forever.
* Kinnison needs to re-prime his ccache on his laptop
<Diziet> Argh, apt is very annoying.
<Diziet> How can I test `dist-upgrade but with these .debs here replacing the corresponding ones' ?
<Keybuk> Diziet: I thought you only used dpkg-ftp ;)
<Diziet> Yes, and Mozilla, and Emacs 19, etc.  But this is company time which is different :-).
<Keybuk> Diziet: random FF question ... if I double click on a "ram" file on the desktop, realplay loads.
<Keybuk> if I click on a ram link in FF, totem loads
<Keybuk> and FF no longer lets me change that
<Diziet> keybuk: This is the `you have chosen to open' dialogue.  It's coming back but it still won't be the gnome app selector.
<Keybuk> ok, iz bug then
<rcaskey_> hey all, I did a dist-upgrade for the first time in almost a week and now all sound is playing back through my PC speaker ;)
<rcaskey_> any ideas on what package to file that bug against?
<Keybuk> rcaskey_: kernel? alsa-drivers? something like that
<Keybuk> you'll need to give a *lot* of information for that one
<rcaskey_> Keybuk: joy, any suggestions?
<Keybuk> for example, how your PC speaker manages to produce more sounds than just "beep"
<Keybuk> which sounds rather like your PC speaker is actually connected to the output of your sound card
<rcaskey_> Keybuk: it's a G5, they have those "business audio" speakers built in
<Keybuk> rcaskey_: what sound card you have, output of "lspci" and "lspci -n -v", etc.
<rcaskey_> I think even Dells have that as an option now
<Keybuk> also check things like the volume control
<Keybuk> you may find you have the option to turn down the speaker and up the output jack
<Keybuk> could be that the last update added support for the internal one
* Diziet installs breezy for the third time today.
<Kinnison> Diziet: You need vmware
<Kinnison> Diziet: or I guess qemu
<ogra> quemu only if youre very very patient :)
<Kinnison> ogra: :-)
<Mithrandir> qemu with accellerator is supposedly not so bad.
<Kinnison> ogra: I remember testing the warty livecd in qemu
<sladen> infinity: http://www.paul.sladen.org/ubuntu/upload/usplash_0.1-31usplashdown1.debdiff http://www.paul.sladen.org/ubuntu/upload/sysvinit_2.86.ds1-6ubuntu17-usplashdown1.debdiff for the reverse-video on usplashdown
<ogra> Mithrandir, you mean the kernel module ? or is there something i'm not aware of
<Mithrandir> ogra: yes, the kernel module.
<sladen> Kinnison: it's only about 15minutes to desktop without the accelorator ;-)
<Mithrandir> sladen: if you could track down wtf is up with qemu + windows and the live cd, I'd appreciate. :-)
<sladen> Mithrandir: in what way?  anyting in particular
<Mithrandir> sladen: you filed a bug about it not working, iirc?
<Kinnison> sladen: aye, but once you hit desktop you pause the emu, save the state, and then you have a breezy snapshot you can work with for upgrade tests :-)
<sladen> Mithrandir: yeah, that wasn't specific to windows or qemu, nor was it repeatable..
<sladen> Kinnison: cooo.  like it
<Kinnison> sladen: I used to use qemu's snapshots for doing linux kernel dev
<Kinnison> sladen: I had a qemu setup so that I started the qemu machine, pressed <enter> it mounted the virtual cdrom with the new module on it, loaded it, and ran the test suite
<Kinnison> sladen: then when it crashed, I could compile a fix, make a new iso, rinse and repeat
<sladen> Kinnison: juicy
<Mithrandir> sladen: the /dev/null 660 bug?  If you can't repeat it, I'll just close it with "result of too much cosmic radiation" or something. :-)
* Kinnison thinks we need a new closed state of "Aliens ate my bug reporter" for when the reporter goes awol and you can't work out how to reproduce the problem
<sladen> Mithrandir: yup.  If I don't see it again in the next 24hours I will.  Any suggestions what codepath would have got there?
<sladen> Mithrandir: in the same session that happened, there was no pointer and no /dev/input/mice either
<Mithrandir> sladen: udevd could be freaking out, for some reason.
<Mithrandir> sladen: I think I saw it in a circumstance a bit like that..
<Diziet> kinnison: I have Xen and LVM which I'm working on for automated testing; I might be able to use it for this too but of course I'm in too much of a hurry to set it up for this ...
<Kinnison> Diziet: :-)
<Mithrandir> sladen: actually, it's a squashfs bug which I thought was fixed in newer kernels.  Can you verify that you have a semi-recent snapshot and try to reproduce it?  IIRC, it could be caused by a broken kernel module somehow.
<Diziet> Xen is soooo coool.  Even though it is a bit annoying at times.
<Mithrandir> anyway, cinema.
<Diziet> My question about apt was serious, btw.  I need to test a dist-upgrade but have it use my newly-built to-be-tested ff packages instead of the real ones.
<hunger> Diziet: Would be cool to have Xen in ubuntu:-)
<Diziet> hunger: It's not in Debian yet.  There are some, erm, problems with the upstream packaging.  There are guys working on it.
<hunger> Diziet: The problem is with the kernel stuff.
<Diziet> The thing is, the hard part is setting up a machine to be a Xen host.  You have to have a different kernel, mess with the boot config, etc.  All easy if done by hand but quite a PITA to do safely automatically.
<Diziet> The current unofficial packages are quite good - they get you most of the way there and just leave the tricky (dangerous) bits to you.
<hunger> Diziet: The userspace stuff is pretty simple.
<Diziet> Yes.
<Robot101> er, provided your networking config is simple
<Diziet> I meant the current unoffial hypervisor.
<Diziet> Yes, the default networking scripts are a bit TOTALLY INSANE.
<Diziet> And upstream seem to be ignoring me about their stupid tcp csum `optimisation'.
<Diziet> I might go and badger them on the -devel list instead :-).
<Robot101> rename eth0 to peth0. make a new virtual interface pair with yourself. make up some MAC addresses. join some interfaces together in a bridge. smoke lots of crack. copy some IP addresses around...
<hunger> Diziet: The hypervisor is simple to package, too... (apart from integrating it into grub of course).
<Robot101> it doesn't help that the bridge code is just buggy
<Robot101> if your network wibbles in a certain way, you win an interface you can never use again with the bridge
<Diziet> Joy.
<sladen> Mithrandir: that's a point, I also have a backtrace from squashfs.ko crashing
<Diziet> The supplied route scripts are less insane.  Although they do turn on ip_forward without asking, which is a bit loony.
<Robot101> Diziet: I've been quite tempted to just rip a lot of it out and set up what we actually want in /etc/network/interfaces
<Robot101> at least we'll know what the hell is going on then
<Diziet> Yes.  My testbed builder script just writes /etc/network/interfaces for you.
<Diziet> And uses a script=<its own script> which does a more sensible thing.
<Robot101> the vif-bridge script is reasonable, make a virtual interface, add it to the bridge
<Robot101> yeah
<Diziet> Right.  It's the setup that's insane.
<Robot101> I don't like the way that xencons mystically disappears your serial devices
<Robot101> that's *fucking annoying*
<Diziet> You have to have   <distro>.adt.<your-domain-here>  in your DNS for my script, which is a bit evil, but I haven't done any config parsing for it :-).
<Robot101> if xencons is on, both your hardware serial devices disappear, so you can't use ttyS1 from userland any more
<Diziet> robot101: Hrmf.  Also, the handling of the VGA and keyboard is a bit mad.
<Robot101> and also if you have serial built as a module, that module fails to load, so you can't use any PCI serial devices either
<Robot101> so we've got some totally insane bodge together of built-in serial that doesn't work, bios console redirection, and hnnarhghn nangllkrha nrnad
<sladen> Robot101: presumbly you map the real serial devices to one of the virtual kernels?
<Robot101> sladen: oh no, that'd actually work. they removed the ability to delegate PCI devices to domains in the initial 3.0 release, I think its back now.
<Diziet> On the other hand, unlike just about every other virtualisation scheme out there, it doesn't totally suck.
<Robot101> sladen: but the hypervisor itself sits on both hardware serial ports, and then exposes only one of them as your /dev/tty in dom0.
<sladen> Robot101: did they start employing feature-removal experts from GNOME?
<coyctecm> there are some updates for breezy but depencies are not ok
<Robot101> sladen: which if you had a pair of machines which were serial consoling each other, is more than slightly annoying
<sladen> Robot101: in that case, the hypervisor is buggy
<rcaskey_> Keybuk: thanks for your help, filed at https://launchpad.net/distros/ubuntu/+source/alsa-driver/+bug/34237
<Ubugtu> malone bug 34237 in alsa-driver "Powermac G5 plays audio from internal speaker when speakers are connected" [Normal,Unconfirmed]  
<Robot101> sladen: actually, it might be the serial driver, if it can't get both ttyS0 and ttyS1, it bails
<Robot101> sladen: but the way that "xencons" pretends to be your ttyS0 is just sheer crack cut with iron filings
<sladen> Robot101: so, setserial ttyS1 uart none  doesn't help 
<Robot101> sladen: no, that'd talk to the serial driver, which has already failed to load and given up on both ttyS0 and S1
<Diziet> Does that mean no-one knows the answer to my apt question ?  Perhaps you can't do it with apt.
<Diziet> I could use dpkg-ftp but I suspect that's not quite going to be an accurate test of the normal user experience.
<Robot101> Diziet: you need to make a Packages list and add the packages to sources.list
<mvo> Diziet: what was your apt question again?
<Diziet> robot101: Urgh, pain.
<Robot101> Diziet: apt has a file:/ method, and you don't need to do a full dists/bla/bla tree, you can just do deb file://home/foo/bar /
<sladen> Diziet: sudo dpkg -i firefox*iwj*.deb   Ctrl-C  sudo apt-get dist-upgrade ?
<Diziet> sladen: I tried that already.  That's why I'm reinstalling.
<Diziet> Robot101: Ah, thanks.  I'll try that.
<Robot101> Diziet: then obviously apt-ftparchive packages . >Packages or dpkg-scanpackages . /dev/null >Packages
<Robot101> depending on how you feel on that particular day. :)
<mvo> Diziet: do you know when you will come to london to talk about malone?
<Diziet> dpkg-scanpackages seemed to work nicely.
<Diziet> mvo: Week after next, probably.
<Diziet> The sprint is still going then IIRC ?
<mvo> Diziet: yes, AFAIK it's two weeks
<Robot101> surely it might become more of a bedraggled crawl after that long? :)
* Robot101 ducks
<Diziet> Tomorrow I'll send a mail inviting the distro team to think about what they want me to say to you, and then hopefully they'll all mail me while I'm on holiday and I can clarify when I get back and come to London on Wed or Thu or so.
<sabdfl> JaneW: how do you like the spec system changes?
<rcaskey_> btw fridge is busted
<rcaskey_> top tabs are in the middle of the 2nd article
<BenC> Unpacking slocate (from .../slocate_2.7-4_i386.deb) ...
<BenC> Removing `diversion of /etc/cron.daily/find to /etc/cron.daily/find.notslocate by slocate'
<BenC> dpkg-divert: rename involves overwriting `/etc/cron.daily/find' with
<BenC>   different file `/etc/cron.daily/find.notslocate', not allowed
<BenC> anyone know what is up with that? That is supposedly from a fresh install of breezy trying to upgrade
<BenC> s/upgrade/update/ to latest security patches
<Diziet> benc: I just upgraded a fresh breezy to latest security patches.  Three times today already.  And it didn't do that :-).
<BenC> did slocate end up being installed?
<ogra> ita in the default install, it should be there
<ogra> *its
<Diziet> BenC: Yes.,
<BenC> somehow this guy can't seem to get a clean install to start with, and then he has this problem after the install
<BenC> also, somehow his sources.list is showing http://.archive.ubuntu.com (notice the period before archive)
<ogra> there was a bug during development where mirrors were not prefixed right i remember ...
<BenC> this is a released Ubuntu 5.10 CD, supposedly
<ogra> hmm
<ogra> do you know his locale ? 
<BenC> I think korea, but I'm not positive
<mdke_> Kinnison, that's what has bothered everyone on the desktop list. it should def. display when fully charged too. Otherwise, to figure out your battery is fully charged, you have to rely on the _absence_ of the icon, which is crazy stuff.
<Kinnison> mdke_: I may yet change it back to 'always' now that 'always' means 'always unless you're a desktop'
<mdke_> Kinnison, oh that would be wonderful.
<mdke_> Kinnison, i suppose there is no chance of taking it out of the notification area and putting in the applet area? =)
<ogra> mdke_, that'd be a rewrite and you would get problems displaying this many icons ...
<ogra> g-p-m handles way more than laptop batteries
<ogra> s/handles/is designed to handle :)/s
<mdke_> ogra, yes, it was a joke. I know it can't be done for this release. But it shouldn't be in the notification area, in the long term
<Kinnison> mdke_: try using g-p-m on a machine with a UPS and wireless keyboard and mouse plugged in
<ogra> yeah
<mdke_> i don't mind, I'll be happy if you set 'always'
<Kamion> BenC: sounds like a weird choose-mirror bug which I thought was fixed
<Kamion> actually, no, probably apt-setup
<Kamion> BenC: he should file a bug on apt-setup (as a first guess) with /var/log/syslog from the installer
<BenC> Kamion: well, I asked him to try a new install using UK
<Kamion> which is /var/log/installer/syslog after installation
<Kamion> BenC: I'd very much like to extract the syslog before he blats it
<Kamion> meh, UI sprint lot have disappeared
* Kamion goes to fix ubuntulooks
<BenC> Kamion: I'll see if I can get the log
* netjoined: irc.freenode.net -> herbert.freenode.net
<BenC> do raw-installer uploads have to be added to the archive by-hand?
<bronson> Is there any talk about packaging ivtv for Ubuntu?
<tseng> ivtv requires binary firmware that isnt distributable
<tseng> its not exactly a candidate imo
<bronson> That's too bad.  Dapper makes a pretty good myth box.  I love the short boot times.
<tseng> we typically dont ship half of a driver
<bronson> You mean without the firmware?
<tseng> yes
<bronson> Do you suppose a mscorefonts-style download would be OK?
<bronson> Seems like it would be -- the files are on multiple sites for free download.
<bronson> The problem is shipping *with* Ubuntu.
<bronson> Assuming the firmware isn't a problem, how tough would it be to make an ivtv package?
<bronson> The problem would be keeping up with all the new kernels.
<bronson> I would like to package ivtv... but I can't imagine spinning a new package every week...
<trappist> could package ivtv source and let m-a build it
<bronson> trappist, m-a?
<trappist> module-assistant
<bronson> sounds good.
* bronson heads off to look at m-a...
<trappist> of course if you could get ivtv into the kernel package, you wouldn't have to keep up with anything
<bronson> amen to that.
<bronson> they're working on it... about half done.
<bronson> but that was the easy half.  i2c drivers & stuff like that.
<trappist> no I mean into the ubuntu kernel, not the linus kernel
<bronson> Oh.
<bronson> Well, true.  I'd ask Ben?
<trappist> might see if they're interested in #ubuntu-kernel
<bronson> ok, will do.
<trappist> I'm guessing no, though
<trappist> seeing as how it wants that pesky firmware
<trappist> but it's worth a shot
<bronson> Well, *I'd* say no, if I were maintaining it
<bronson> but, as you say, worth a shot.  :)
<trappist> maybe somebody over there has a new hauppauge card and will be sympathetic :)
<thetide> these need to go today 2 laptops, both made by good manufacturers. price is 500$ each for them and include shipping, case and wireless router.  message me if interested on aim at ogd443 or msn at mcsltd2@hotmail.com
<thetide> these need to go today 2 laptops, both made by good manufacturers. price is 500$ each for them and include shipping, case and wireless router.  message me if interested on aim at ogd443 or msn at mcsltd2@hotmail.com
<bronson> op bronson
<bronson> heh
<bronson> thetide is systematically spamming a whole bunch of channels.  sigh.
<CarlFK> trying to scp the logs off from todays dapper "cups error"  - what do I anna-install to get scp?
<CarlFK> anna-install openssh-client-udeb
<Kamion> FYI: all archive processing stalled, soyuz bug
#ubuntu-devel 2006-03-15
<ogra> meh
<ccharles> does anyone wknow what the freeze date for dapper is?
<LaserJock> ccharles: wiki.ubuntu.com/DapperReleaseSchedule
<hub> it is currently
<LaserJock> hub: depends on what freeze we are talking about ;-)
<Surak> speaking on that, string freeze is five days from now on. someone at ubuntubrasil said that the wiser would be translate for breezy, that dapper will sync strings from breezy's rosetta. is this correct?
<hub> LaserJock: ah right
<Surak> I put two of my employees translating ubuntu on rosetta for breezy for eight hours a day, so we can improve ubuntu. Is breezy the correct target?
<Burgwork> Surak, the person you need to talk to Martin Pitt, who lives in Germany and is thus likely asleep
<Surak> Burgwork: do you know what nickname he uses here, so I can leave him a memo?
<Burgwork> Surak, pitti
<ajmitch_> I'd send an email rather than hoping he checks memos on freenode
<Surak> ajmitch_ : you are correct. done.
<Kyral> I think I found a cause to my GTK Breakiness
<Surak> Kyral : which kind of break?
<Surak> /s what 
<Kyral> GNOME and XFCE breakign on startup like CRAZY
<Kyral> I've noticed a wierd error in my Dist-Upgrades...
<Kyral> lemme get it again and pastebin it
<Kyral> ...in 15 mins when its finished...
<Kyral> http://paste.ubuntu-nl.org/9944
<Kyral> Thats the error
<ajmitch_> Kyral: and have you filed a bug?
<Kyral> ajmitch_: I dunno what package to file it on
<Kyral> its affecting waaay too much
<Mez> infinity, ping
<infinity> pong
<infinity> Are you volunteering to do Flight-5 prep testing? :)
<infinity> How kind.
<LaserJock> infinity: does that mean Flight5 will be out soonish?
<infinity> LaserJock: That's the general plan... Unless it doesn't happen.
* infinity needs to hack the livecds a bit.
<ajmitch_> great, I imght have a new amd64 box to test it on next week
<Mez> infinity, well - I'd love to - but i'd need a machine to install to :d
<infinity> And by next week, you mean "right now", right?
<Mez> infinity, no - referring to the scim hack - you looked at it yet
<LaserJock> infinity: ok, I was thinking of installing Flight4 but I'll just wait until 5 is out
<infinity> Mez: Nope.  Let me take 5 minutes out and poke it right now, so you can stop bugging me. :)
<Mez> infinity, lol ;)
<Lathiat> infinity: im up for some testing
<Lathiat> infinity: is the bug i reported fixed? breaking kubuntu installs atm
<Lathiat> dunno if itl break an ubuntu install or not
<Kamion> Lathiat: yes
<Mez> Lathiat, which bug?
<Lathiat> Kamion: sweet
<Kamion> fixed as of this morning, although there may not have been new CD builds yet
<Mez> ;)
<Mez> so wen can we expect espresso ?
<Kamion> er ... in fact there probably won't have been since the CD cronjobs are disabled
<Lathiat> ive got two laptops and an amd64 ready and waiting for testing :)
<Lathiat> Kamion: heh
<Kamion> Mez: oh, I dunno, how about the Flight CD 4 release announcement
<Mez> Kamion, oh...
* Lathiat laughs
<infinity> Kamion: Keep 'em disabled anyway, dailies will just mess with my head. :)
<Mez> er
<Lathiat> i have to try that
<Kamion> infinity: right
<Mez> Kamion, whoops ;)
<Mez> Kamion, I dont really read them as i update hourly - I assume I've got all the new features ;)
<infinity> Mez: Erm, dude.  libscim8 conflicts with libscim8, libscim-dev depends on libscim8c2a, and a variety of other breakages...
<Surak> Kamion: espresso is not available for translation in rosetta, isn't it?
<infinity> Mez: Also, why change bits of the packaging that shouldn't relate at all (changing the config.{sub,guess} handling from symlinks to copies?
<Mez> infinity, lol - ok - but - er - still - the control file needs fixing - but the issue is it not being overwritten
<Kamion> Surak: not yet, I still need to sort out internationalisation of it in general, sorry
<Mez> infinity, that change was because it FTBFS unless I changed it
<Kamion> and before doing that I need to make a somewhat complicated extension to debconf
<Kamion> should happen soon though
* infinity does some tests in a clean breezy chroot..
<Kamion> Mez: most of the reason I bother writing release announcements is to describe the things that can't be seen by people just updating regularly
<Kamion> i.e. installer / live CD changes
<Mez> Kamion, ah - see-  I didnt know that - I thought it was just to keep people up to date with new stuff ;)
<Kamion> it's only very recently that they've described *anything* other than installer and live CD changes
<infinity> Mez: Dude.  Is it okay for me to visit violence on you now? :)
<minghua> Mez: infinity what is this scim problem you are discussing?
<Mez> infinity, lol - not exactly
<Mez> seeing as it still doesnt solve my question
<infinity> minghua: Just some backporting issues Mez is having.
<Mez> which is why is the control hack not working
<Mez> at all
<Mez> it's not even replacing the control file
<infinity> Right, which is obvious.
<infinity> So, you want to use lsb_release in your debian/rules, right?
<minghua> yeah, I figured that out when I remember Mez is the backport guy
<infinity> And build-deps from from the .dsc file, right?
<infinity> Which is generated when the source package is built, with dapper's control file.
<infinity> (build-deps need to be the same in both control files)
<infinity> The end.
<Mez> the B-D's are fine :D
<infinity> Uhm, no, they're not.
<infinity> Look again.
<Mez> whats wrong with it ?
<infinity> I just explained.
<infinity> Build-deps are parse from the .dsc file, which is generated from debian/control.  You only added your build-deps to debian/control-breezy
<infinity> You can't do that.
<infinity> Build-dpes are parsed way before your hack comes into effect.
<infinity> deps, too.
<Mez> build deps dont change ...
<infinity> (base)adconrad@cthulhu:~/scim/scim-1.4.4/debian$ diff -u control control-breezy
<infinity> -Build-Depends: debhelper (>= 4.0.0), dpatch, autotools-dev, intltool, x-dev | xlibs-dev, libx11-dev | xlibs-dev, libgtk2.0-dev (>= 2.4.0), libxt-dev | xlibs-dev
<infinity> +Build-Depends: debhelper (>= 4.0.0), dpatch, autotools-dev, intltool, x-dev | xlibs-dev, libx11-dev | xlibs-dev, libgtk2.0-dev (>= 2.4.0), libxt-dev | xlibs-dev, base-files, lsb-release
<Mez> ah - lol that was cause i forgot to remove that from the -breezy one ;)
<Mez> lol
<Mez> as you said before I didnt need it
<infinity> You don't need base-files, you /do/ need lsb-release
<infinity> It's hard to call it if it isn't there.
<Mez> maybe thats why it isnt working
* Mez trie
<Mez> or is there something else I'm missing ?
<infinity> In other news, your hack breaks the clean target.
<Mez> o_O
<infinity> You really want something more robust like "if [ blah ] ; then mv control control-dapper && cp control-breezy control; fi" and the reverse in clean.
<infinity> Otherwise, you've just overwritten control with control-breezy, and a new build of the source package will get breezy's control.
<infinity> (err, make that first mv a cp as well)
<infinity> But you get the idea.
<Mez> I see...
<Mez> though I never thought about it being outside of a chroot environment
<Mez> like pbuild or a buildd
<infinity> In theory, from any point in a build, you should be able to do "debian/rules clean" and return to pristine source.
<infinity> There are some notably broken exceptions in the archive, but I'd prefer they remain exceptions, rather than becoming the rule. :)
<minghua> infinity: even if one of the target in debian/rules is not finished?  that would be pretty hard, I think
<infinity> minghua: Well, not if it's still running, but if it's "finished", as in "died", then yes.
<minghua> not every upstream makefile cleans very well after an interrupt in buildding
<infinity> minghua: But yes, some upstream makefiles are broken (I've fixed a few to clean properly in packages I've maintained)
<infinity> minghua: And some are so hopelessly broken that a more violent approach (copy everything to build/ and rm -rf build/ in clean) works well. :)
<minghua> infinity: Hmm, I see.  Maybe I should learn autotools and start fixing upstream makefiles as well
<Mez> infinity, I've made the changes to the control/rules files
<Mez> I'll test and upload again to revu if it doesnt work
<infinity> Mez: Upload to REVU anyway, I'd like to give it a once-over.
<Mez> infinity, no probs
<Mez> I dont even know why I'm doing this
* Mez shouts at launchpad guys to get backports working
<infinity> Backports may magically work in a few days.  Shhh.
<Mez> infinity, maybe - but isnt that because of the whole making it an uploadable target?
<Mez> or have you been playing with the buildds?
<infinity> The latter.
<Mez> lol ;)
<Mez> fair enough
<Mez> I thought it was laiunchpad not the buildd's
<Mez> ;)
<Mez> though - we still gotta get them past elmo - and he's gotta re-make his scripts for soyuz
<Mez> or not ...
<Mez> mv: cannot stat `debian/control-breezy': No such file or directory
<Mez> it nearly worked
<infinity> You want cp -f
<Mez> cp -f?
<Mez> what difference does that make if it cant find the file ?
<infinity> Oh, right.
<Mez> lol
<infinity> [ -f foo ]  && cp foo
<Mez> though that was before I made the changes
<Mez> so I'll try again
<Kinnison> g'night
<ogra> night Kinnison 
<Mez> night Kinnison 
<Mez> msg infinity I'm getting a strange error now
<Mez> grr
<Mez> s/msg//
<Mez> /bin/sh: -c: line 1: syntax error: unexpected end of file
<infinity> I'll let you figure that one out yourself by retracing your steps. :)
<Kamion> that's usually because you forgot a trailing ` or ) or something like that in one of your commands
<Mez> hmmles
<sbalneav> Evening all
<Mez> ]  EXPECTED
<Mez> wtf?
<infinity> Still missing a closing quote or something.
<Mez>         if [ `lsb_release -c -s` = "breezy" ] ;
<Mez>          then
<Mez>                 cp debian/control debian/control-dapper
<Mez>                 cp debian/control-breezy debian/control
<Mez>         fi
<Mez> I dont see a missing closing quote
<Kamion> I don't see any backslashes for command continuation across lines either
<Kamion> this is make - commands are single-line-only unless you put a backslash at the end to tell it otherwise
<Mez> I'm editing the wrong bit thats why
<Mez> grr
<Mez> /bin/sh: line 0: [: missing `] '
<Mez> still gives me that though
<infinity> if [ foo ] ; then \
<infinity> bar
<infinity> Err.. A \ on that bar too. :)
<Mez> if [ `lsb_release -c -s` = "breezy"] ; then \
<Mez>                 cp debian/control debian/control-breezy; \
<Mez>                 cp debian/control-dapper debian/control; \
<Mez>         fi
<Mez> is what I have
<Mez> it works now
<Mez> but is still giving me a "/bin/sh: line 0: [: missing `] '"
<ogra> put a space in 
<ajmitch_> whitespace is important
<ogra>  if [ `lsb_release -c -s` = "breezy"] ; then \ should be
<ogra>  if [ `lsb_release -c -s` = "breezy" ] ; then \
<infinity> win 16
<infinity> lose 17
<infinity> Oh well.
<Surak> night people.
<hub> interested in a dist-upgrade that cause trouble booting?
<hub> just happened for the second time on the same PC
<hub> *sigh*
<infinity> hub: Might be interested in bug reports, if you know what package is angering you.
<hub> infinity: it hangs on "Loading hardware drivers..."
<hub> at least it did just before
<hub> seems to go trhu this time
<hub> but really slowly
<Amaranth> great, a security bug in gpg
<hub> infinity: what package would it be?
<minghua> Amaranth: another one?
<Amaranth> minghua: this one is on slashdot, it might be the one you're thinking of
<Amaranth> basically signing something proves nothing, which is loads of fun
<minghua> Amaranth: oh no, this is a new one, and sounds more serious
<Amaranth> http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html
<Amaranth> just published today
<Amaranth> so it's new
<minghua> the one I was thinking of is not a security bug per se
<minghua> and metioned at the beginning of the mail Amaranth links to
<Amaranth> holy shit, the diff between 1.4.2.1 and 1.4.2.2 is 101k
<hub> uh oh
<Amaranth> that's going to be hell to backport to breezy and hoary versions
<Amaranth> pitti is going to be very angry tomorrow :P
<hub> Amaranth: why not just backporting the complete package in that case?
<Amaranth> that's probably what'll have to happen
<Amaranth> if it took a 101k patch to fix the very latest release...
<infinity> hub: You could start with udev (which Keybuk loves getting bugs on) and work with him to debug from there if it's a kernel bug, or udev hanging.
<hub> infinity: that machine has booted this time
<hub> infinity: after kicking it with the power switch
<hub> infinity: reminds me the office :-/
<infinity> hub: Kay, well, please don't file it unless you can reproduce it, or it'll be impossible to find. :)
<hub> infinity: yeah
<hub> infinity: that's why I came here first
<hub> sort of
<fabbione> morning
<ajmitch_> morning fabbione 
<hub> hey
* ..[topic/#ubuntu-devel:fabbione] : 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 | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity |  UI  sprint in #dapper-look | Flight5 in preparation - all uploads must be authorized by infinity/mithandir
* ..[topic/#ubuntu-devel:fabbione] : 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 | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity |  UI  sprint in #dapper-look | Flight5 in preparation - all uploads must be authorized by infinity/mithrandir
<fabbione> for people that do NOT read the topic:
<fabbione>  Flight5 in preparation - all uploads must be authorized by infinity/mithrandir <-
<fabbione> we want an installable archive, hmmmml?
<fabbione> s/ml/mk/
<ajmitch_> fabbione: all uploads to main, or really all?
<LaserJock> jeeze, will the kernel source troll never end?
<Mithrandir> ajmitch_: just main should be fine, unless you have something lying about which is in universe but makes main uninstallable.
<infinity> (Which would be a neat trick)
* infinity runs off and will be back shortly.
<Mithrandir> ajmitch_: we do use a few things in universe for building the CDs, like squashfs-tools, so I'll be very unhappy if you manage to break that in such a way that the cd building fails, for instance. :-)
<Mithrandir> unsure if we use the dapper or breezy version, though
<ajmitch_> Mithrandir: I'm not likely to do uploads for a couple of days anyway, though breaking a cd build is the best way to get lots of people angry at me :)
<fabbione> LaserJock: what kernel source troll?
<fabbione> LaserJock: the one about .12 source code?
<LaserJock> fabbione: yeah, the second time
<fabbione> just ignore him
<LaserJock> sure, I can ignore him, but sometimes I like to vent a little frustration on that type of behaviour. I wonder what he is thinking or what his motivation is.
* LaserJock shuts up
<fabbione> LaserJock: instaed of trying to give him apt-get source commands
<ajmitch_> hopefully it's just ignorance?
<fabbione> just give him the URL to the source
<fabbione> his sources.list might be pointing to something royally wrong
<fabbione> end of the story :)
<LaserJock> I suppose, I just like being passive-agressive I guess. ;-)
* ajmitch_ would rather just be aggressive at times :)
<LaserJock> I'm not very good at being aggresive, that is why it is good to have ajmitch_  around
<ajmitch_> haha
<ajmitch_> I was rather calm & polite dealing with someone on the forums yesterday - my sole purpose there is to tell them to file proper bugs in malone
<LaserJock> I though you did a great job of showing restraint. I think I would have been harsher
<ajmitch_> anyway, back to NZ & active ubuntu hacking tomorrow
<pitti> Good morning
<ajmitch_> morning pitti 
<pitti> hey ajmitch_, how are you donig?
<pitti> doing, even
<Kyral> night all
<ajmitch_> good, how are you?
<pitti> ajmitch_: pretty tired, but ok :)
<ajmitch_> yeah :)
<ajmitch_> have you been at the UI sprint?
<Kyral> I love that little exchange "Morning..." "Good night" :P
<pitti> ajmitch_: no, I am at home
<pitti> ajmitch_: you shouldn't let me near UI design :-P
<ajmitch_> heh
* ajmitch_ is the same
<ajmitch_> I'm finally going to get back to ubuntu hacking next week, flying back to NZ tomorrow :)
<freeflying-ibook> pitti: hey ,will you be at the i18n sprint  next week ?
<pitti> ajmitch_: oh, where are you now?
<pitti> freeflying-ibook: hey
<pitti> freeflying-ibook: no, nobody told me about it :/
<ajmitch_> pitti: brisbane, australia
* ajmitch_ imagines there'll still be enough bugs left for me to fix next week
<pitti> ajmitch_: quick, before we kill 'em all  :)
<ajmitch_> I'd better hurry..
<pitti> Hey zyga, how are you?
<zyga> pitti: hey, fine
<zyga> I'm slowly getting to work today, how about you? :)
<pitti> same for me, trying to get fully awake
<zyga> I've just upgraded and noticed the brand new theme
<zyga> what do you think about it?
<pitti> zyga: I didn't see it yet, I have to create a fresh test user for it
<zyga> pitti: there are some problems with it
<zyga> vuntz has a nice screenshot
<zyga> same thing has happened to me
<vuntz> nice screenshot is http://tmp.vuntz.net/Screenshot-Ubuntu%20Servers:%20%23ubuntu-desktop-1.png
<pitti> whoa - orange
<Kamion> I like the new progress bars
<Kamion> concur with "whoa - orange" :-)
* zyga wonders how to test the progress bar
<zyga> oh segmented!
<Kamion> vuntz: I don't get anything like the grey gradient on your menus
<Kamion> whoa, weird scrollbar grips
<zyga> Kamion: it happened to me twice, unable to reproduce again
<jdub> mm, the scrollbar ends are a little bit odd
<zyga> heh
<jdub> vuntz: switch to a totally different engine, then back to ubuntulooks
<zyga> we should rename dapper dake to ubuntu revolution
<jdub> vuntz: you on x86?
<Kamion> I can see how they're useful, but they do have a very distracting effect by drawing your eyes a long way away from the mouse pointer
<vuntz> jdub: I did it :-) doing it again
<vuntz> jdub: yes
<jdub> vuntz: that's a pity, i was hoping i could blame some second-tier architecture completely by guesswork
<vuntz> mmhhh... nice nuclearish green :-)
* vuntz goes back to clearlooks
<irvin> hehe
<zyga> firefox consumes 100% cpu after few theme changes
<ajmitch_> jdub: yeah I get the lovely green/black effects also, it's quite colourful
<infinity> jdub: The new theme ate my leftover pizza and raped my girlfriend.
<irvin> the red/orange gradient effect hurts my eyes
<HrdwrBoB> the new theme made my mother yell at me over the phone
* ajmitch_ imagines it will get some tweaking
* pitti just tried the new theme, but after two minutes it hurts my eyes
<dilinger> haha
* zyga LOVES the sound juicer icon
<zyga> the best icon I've seen in quite some time
<infinity> Kamion: A) Why are you alive, B) Are you down with the inner workings of the publisher?
<infinity> Kamion: Err s/alive/alive already/
<fabbione> i think Kamion is on the way to London for the UI sprint
<infinity> Oh, well he was here 15 mins ago. :)
<zyga> bye guys, have to get to work 
<Burgundavia> salut sabdfl
* Kinnison hugs burgey
* Burgundavia hugs Kinnison
<Burgundavia> Kinnison: I will blog tomorrow, but I have very cool news about Ubuntu and Edubuntu being used for a large local project here
<Kinnison> burg: cool
<sabdfl> hey all, Burgundavia
<highvoltage> hi sabdfl 
<sabdfl> hey hey
* infinity builds new livefs images all over the place.
<Burgundavia> sabdfl: we need a press release heralding the fact that dapper can now run on Intel Macs
<sabdfl> Burgundavia: can run, but i'm not sure that dapper will detect and install correctly without nudging
<Burgundavia> I think we should release it just after Flight 5, assuming it works
<infinity> Install CDs building.
<highvoltage> Burgundavia: would that be the i386 version?
<infinity> fabbione: Including one for you, out of the kindness of little's heart.
<Burgundavia> highvoltage: I assume so
<fabbione> infinity: cool
<sabdfl> Burgundavia: if the release support intel mac's then HELL YES
<fabbione> thanks dude
<Burgundavia> infinity: do you know of flight 5 will work ootb on Mactel?
<infinity> Burgundavia: Not sure, you'd have to ask mjg59, but I think we may still be a few patches short.
<infinity> Burgundavia: I'm all for people trying, though. :)
<infinity> Oh, wait, I think elilo still needs love.
<infinity> So you probably won't be able to boot it. :)
<Burgundavia> damn
<infinity> A minor issue.
<infinity> I hear booting is for pansies.
<Burgundavia> the reason I say it now is that MS just announced it will not support EFI for Vista
<infinity> We noticed.
<infinity> We'll "probably" support it ootb for dapper, and definitely for dapper+1.
<Burgundavia> and no other distro has said anything
<infinity> There's plenty of effort going on to make it happen for dapper, though (if it doesn't destabilise the world in the process)
<Burgundavia> infinity: sabdfl, if elilo is not ready, I won't kill myself and stay up till 3 writing a press release. Beta is not too far away. I think that would be great target as well
<infinity> Burgundavia: Oh, no point in a release for RIGHT NOW, but if you want to prepare one on the off chance that we can use it in a week or two, go nuts. :)
<Burgundavia> infinity: I will do so over the weekend
* Mithrandir points seb128 to the topic, preemptively.
* infinity laughs.
<pitti> seb128: hey
<Burgundavia> anyway, night all
<seb128> Mithrandir: I'm going to do some artwork upload today probably
<seb128> pitti: hi
<infinity> seb128: Not right now, you're not. :)
<Mithrandir> seb128: after flight-5, please.
<Mithrandir> unless it's OH MY GOD THE SKY IS FALLING-critical
<seb128> Mithrandir: after UI sprint when I'm home you mean? :)
<Mithrandir> seb128: sure.  Flight-5 is today unless the world falls down over our heads.
<pitti> dholbach: *hug*
* Mithrandir points dholbach too to the topic.
<Mithrandir> (also preemptively)
<infinity> Poor ia64, still uninstallable... I guess I get to fix that on Monday.
<seb128> Mithrandir: joke aside, when is flight 5? Because that's likely we will have to do some uploads for UI sprint today
<infinity> seb128: we're working on it right now.
<seb128> k
<infinity> seb128: Can you queue the uploads?
<Mithrandir> seb128: today.  install images are built, live images are building.
<dholbach> Mithrandir: fine with me
* dholbach hugs pitti
<dholbach> hi everybody
<seb128> infinity: if Mark is happy with it sure
<infinity> Mithrandir: You're assuming those are the only images we're building. :)
<infinity> s/we're/you're/ to be perfectly clear, since I'm not here all night. ;)
<seb128> do you guys have the new ubuntu-artwork and ubuntulooks theme on those images you are doing?
<infinity> seb128: Yep.
<seb128> rock
<infinity> seb128: For better or worse.
<pitti> seb128, dholbach: would it be possible to make the new theme just a little less eye-hurting? (i. e. less orange)
<dholbach> pitti: no
<pitti> :(
<dholbach> pitti: it's perfect as it is - we will reject every bug :)
<seb128> pitti: come here to London express yourself :)
<seb128> pitti: it's much less flashy it was 2 days ago
<pitti> OMG, I'm glad that I didn't see that one then
<seb128> pitti: what part is an issue for you? wm bar color? Selection color?
<pitti> seb128: the design and everything is cool, it's just the bright orange that hurts
<pitti> seb128: window bar etc.
<Mithrandir> infinity: uh, yes?  For each project, naturally.
<Treenaks> pitti: The Dutch will love it ;)
<infinity> Mithrandir: Confident there won't be any showstoppers?
* infinity gets out and pushes rsync a bit harder.
<Mithrandir> infinity: oh, we might to build them a few more times, true.
<infinity> I wonder if this process is geting slower, or I'm getting older and more impatient.
<Treenaks> infinity: you just need more bandwidth
<Mithrandir> oh, good.  Edubuntu live images no longer oversized.
<seb128> pitti: can you make a screenshot?
<seb128> pitti: in case I've a local theme different atm
<infinity> Hrm, cute.
<seb128> pitti: because the window bars are midway between brown and orange here
<infinity> Aren't ports CDs meant to publish to a different directory?
<infinity> Maybe I confused the poor thing by asking it to build "amd64 i386 powerpc sparc"
<fabbione> infinity: yes they are published in ports/
<infinity> fabbione: Well, not today, apparently. :)
<pitti> seb128: http://tmp.vuntz.net/Screenshot-Ubuntu%20Servers:%20%23ubuntu-desktop-1.png
<infinity> http://cdimage.ubuntu.com/daily/20060310/
<pitti> seb128: it's mainly the bright orange icons and the orange window bar that make my eyes bleed
<seb128> pitti: the green selection you have, not the theme
<fabbione> infinity: meh no dude.. move it.. otherwise you screw mirrors
<fabbione> infinity: and my rsync
<pitti> seb128: green selection?
<seb128> pitti: need to restart the apps after installing it
<seb128> pitti: xchat channel selection
<infinity> fabbione: Mirrors don't mirror cdimage, unless they're insane...
<seb128> the green you have on #ubuntu-deskop
<seb128> desktop
<fabbione> <- i am insane
<pitti> seb128: oh, that's not my desktop, but vuntz'
<fabbione> <- me man with 2T of disk to fill somehow
<pitti> seb128: I make one for you, minute
* infinity ponders how to fix this after the fact.
<seb128> pitti: oh, right ... so is the menus selection color fine or you?
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/Screenshot.jpg
<seb128> pitti: right, correct new theme for you. So you find the "light" orange (the one from icons, etc) too flashy?
<pitti> seb128: selections (in menu etc.) look a bit better, the active window in the desktop switcher in the panel is horrible, icons and window bars hurt
<seb128> k, noted
<pitti> seb128: everything is way too intense for my taste
<irvin> i agree with pitti 
<pitti> seb128: well, it's easy enough to change for me (I prefer smokey blue), it's just some feedback in case you guys collec tit
<pitti> collect it *cough*
<seb128> pitti: yeah, feedback is welcome
* pitti <3 smokey blue + Tango icons
<seb128> pitti: and what do you think about the colored parts used on scrollbar?
<Treenaks> seb128: they're nice!; also the 'progress bar' dividers look cool
<seb128> :)
<pitti> seb128: color: too bright; they look cool, but I don't know what they are good for
<Treenaks> pitti: flashy l33tness, of course
<pitti> seb128: maybe you can convince Mark to exchange orange for light brownish everywhere?
<Treenaks> pitti: imagine this on MovieOS^WXGL
<seb128> pitti: I doubt it
<seb128> pitti: would mean to redo all the icons and everything
<seb128> pitti: and we are past UI freeze now
<pitti> hmkay
<Treenaks> seb128: isn't there a 'brown' in the icon palette?
<pitti> I'm just afraid of the reviews we'll get :/
<Treenaks> pitti: Current reviews: "It works OK, but it's brown"
<Treenaks> pitti: Future reviews: "It works OK, but my eyes burned at the sight of orange"
<Treenaks> ?
<dholbach> i like it much better
<seb128> pitti: I find it shiny, better that the color we had before
<pitti> seb128: hm, it hurted me after two minutes, I can't imagine seeing it for 12 hours a day, but that might be just me
<infinity> Unpacking ia32-libs-kde (from .../ia32-libs-kde_3_amd64.deb) ...
<infinity> dpkg: error processing /var/cache/apt/archives/ia32-libs-kde_3_amd64.deb (--unpack):
<infinity>  trying to overwrite `/etc/qt3/qtrc', which is also in package libqt3-mt
<infinity> ^--- Whose fault is that one?
<jordi> mvo: hey room mate!
<seb128> pitti: I'm working with it for 2 days, I like it
<seb128> pitti: but let's wait user feedback
<pitti> yes, let's :)
<seb128> pitti: mightbe you should play with your screen settings to make it better ;)
<Mithrandir> infinity: whoever thought having conffiles in libs was a good idea.
<infinity> fabbione: Your sparc image now lives in ports.  booboo undone.  <cough>
<fabbione> infinity: ahha thanks .)
<Mithrandir> Riddell_: around?
<infinity> Okay, can I get everyone to test their little hearts out on this:
<infinity> http://cdimage.ubuntu.com/daily/20060310/
<Lathiat> most certainly can
<infinity> ^--- Flight-5 candidate 1 (and maybe the last, if we're lucky)
* Treenaks rsyncs
<Lathiat> whats highest priority to test?
<Lathiat> takes me an ahour and a half to get each iso down
<Lathiat> ;p
<Lathiat> i cando i386, amd64
<Riddell_> Mithrandir: hi
<infinity> Lathiat: Pick what you think no one else has. :)
<infinity> Lathiat: amd64, perhaps.
<Mithrandir> Riddell_: see the dpkg error from infinity above.  
<Treenaks> hm.. I need to buy new CD-Rs
<Lathiat> infinity: also, kubuntu?
<Mithrandir> Riddell_: also, /etc/qt3/qtrc has: libraryPath=/usr/lib/kde3/plugins/
<infinity> Riddell_: You get no Flight until you fix that. :)
<Riddell_> Mithrandir: am building a chroot on my amd64 now
<infinity> Lathiat: No kubuntu yet.
<Mithrandir> Riddell_: you can work around it like it's done for pango, but you'll run into c++ symbol mangling madness, I suspect.
* infinity starts building LiveCDs.
<pitti> Mithrandir, infinity: I guess it's not an ideal time for uploading new language-support-* packages then?
<pitti> (they aren't on the CDs)
<infinity> pitti: Some are in live...
<seb128> can I upload new GTK? :)
<infinity> seb128: You may die now. :)
<pitti> infinity: urgh? at most en, I'd asssume
<Mithrandir> seb128: do you like being spanked? :-)
<infinity> pitti: I tihnk just en, but I'm not positive.  Check the seeds. :)
<seb128> infinity: hum, ok ok, I back off for now :p
<Mithrandir> pitti: please hold them off, they might not be on the CDs, but I would like to not have changes in the archive today unless we need them for flight.
<pitti> seb128: only with an API break, please
<mvo> jordi: hello! 
<pitti> Mithrandir: yes, that's fine for me
<seb128> pitti: yeah, soname change to get some fun
<Mithrandir> ogra: you might want to whip together your edubuntu testers to do install tests.
<infinity> Mithrandir: Which will have to wait for a for-project edubuntu build. :)
<infinity> Mithrandir: Was next on my list after the livecd build finishes up.
<Mithrandir> infinity: well, he needs to whip them together before he can herd them
<infinity> Mithrandir: <grin>
<infinity> Catnip.
<olemke> seb128, how about shipping the old human theme under a different name to give people a chance to switch back to the old look?
<seb128> olemke: can be done
<olemke> seb128, that would be really nice :-)
<mjr> as for the name, "badger" seems the obvious choice...
<jdub> seb128: (i've been thinking of shipping separate release packages for u-a, such as ubuntu-artwork-dapper, ubuntu-artwork-breezy, etc)
<infinity> LiveCD Flight-5 candidates are up here, again, testing required:
<infinity> http://cdimage.ubuntu.com/daily-live/20060310/
<seb128> infinity: means I can upload again?
<infinity> seb128: No. :)
<Mithrandir> seb128: no.  Wait until we have released.
<Mithrandir> seb128: we might need to rebuild the images.
<Mithrandir> and if so, it'd be bad if we had to chase down new issues.
<seb128> grumpf
<infinity> dholbach: I suck at getting people excited, can you make sure everyone in the channel downloads and tests at least one livecd/installer image for me? :)
<seb128> Mithrandir: if I do an upload that new theme tweaking
<seb128> s/that/that's
<mdke> if someone with main access has a few minutes to fix an easy bug on xmms, could they have a look at the patch attached to bug #30694, and if appropriate, apply/upload? thanks
<Ubugtu> malone bug 30694 in xmms "unfriendly menu entry for XMMS" [Normal,Unconfirmed]  http://launchpad.net/bugs/30694
<Mithrandir> mdke: no, they may not upload until flight-5 is out.
<Mithrandir> seb128: which package?
<mdke> Mithrandir, ok thanks. After that then maybe?
<Mithrandir> mdke: after is fine with me.
<mdke> not that xmms goes on the cd
<infinity> I'm fine with uploads that don't hit the CD, but I'm also outside of my core hours and working from the kindness of my heart, so it's Mithrandir's show. :)
<seb128> Mithrandir: ubuntu-artwork and ubuntulooks
<seb128> I'm fine with waiting an hour but we will want to play with that and get feedback for the UI sprint today
<seb128> so if the CD testing takes the day that's not going to be cool
<Mithrandir> seb128: I would really, really prefer if you put it on http somewhere and just pointed people to the deb.
<Mithrandir> seb128: it'll _hopefully_ just take a couple of hours, but it might very well take the day.
<seb128> grumpf
<seb128> I'm fine either way, but if Mark wants us to upload I'll upload
<seb128> I'll ping you before anyway
<dholbach> infinity: i'll do an announcement later on - as I can't test the images myself
<Mithrandir> seb128: thanks.  It doesn't look scary, I'm just being very conservative.
<seb128> Mithrandir: yeah I understand, but I'm pretty confident it doesn't break anything since it's just some theme tweaking
<infinity> dholbach: I just meant whip up some enthusiasm in here. :)
<infinity> dholbach: An announcement email may be too late, we could have Flight-5 released before we've asked people to test the candidate daily. :)
<dholbach> arg hm
<Mithrandir> seb128: how do I get my "places" thingy in nautilus to appear again?  It seems to have disappeared on one of my machines
<seb128> Mithrandir: from the desktop?
<Mithrandir> seb128: yes, when opening a folder.
<seb128> Mithrandir: what do you call places? bookmarks? from the panel? nautilus?
<Mithrandir> seb128: the list of places which correspond to what I have in my "Places" menu.
<seb128> the places menu has different things
<Mithrandir> it has ~, Desktop, "File System" and my sftp/webdav mounts
<seb128> volumes listed by gnome-vfs (hal), bookmarks from ~/.gtk-bookmarks, hardcoded stuff
* Mithrandir takes a screenshot
<Treenaks> seb128: Pressing Ctrl+F in Nautilus brings up a different 'Find file' dialog than the one in the 'Location' menu (at the top menu bar)
<crimsun> do you mean F9?
<crimsun> (in nautilus)
<crimsun> then choose Places from the drop-down menu
<crimsun> anything customised looks like it'd be in ~/.gtk-bookmarks
<Mithrandir> seb128: I'd like to go from http://err.no/tmp/desktop-2.png to http://err.no/tmp/desktop-1.png
<seb128> Mithrandir: oh, you want to switch from spatial to browser
<seb128> Mithrandir: Edit menu, preferences, behaviour, always open in a browser window
<Mithrandir> seb128: thanks.
<seb128> np
<jdub> fabbione: you rock :-)
<fabbione> jdub: go for the fridge man :)
<jdub> fabbione: hell yeah!
<fabbione> jdub: http://www.sun.com/servers/coolthreads/t2000/ <- box..
<fabbione> jdub: http://www.sun.com/processors/UltraSPARC-T1/ <- CPU
<tepsipakki> when is the next developer-meeting held, and where?
<tepsipakki> if known
<Treenaks> or user-meeting
<Treenaks> or ANY ubuntu-meeting ;)
<tepsipakki> Treenaks: feeling lonely?-)
<Treenaks> tepsipakki: yeah :)
<jono> hey all
<jono> so is the UI freeze sticking? is anything going to change?
* GmanPUB throws some tinsel on jono
<jono> heya GmanPUB, hows the teeth ?
<GmanPUB> solid.
<jono> :)
* jono has a deep and feverish love for AC/DC
<jono> :)
<jono> so yeah, can anyone let me know if the UI freezy is staying or are icons stilll being ponced around with ?
<infinity> Guys, we need as much testing as possible of the images at http://cdimage.ubuntu.com/daily-live/20060310/ and http://cdimage.ubuntu.com/daily/20060310/ so they can (hopefully) be released as Flight-5.
* olemke installing on i386 right now
<jono> infinity, is that the current image?
<Treenaks> infinity: is that also /current now?
<infinity> Treenaks / jono: Yes.
<jono> testing it now
<jono> does anyone know if all UI is set now? I need to take screenshots today?
<Mithrandir> jono: I think seb wanted to do some minor theme tweaks.
<JaneW> jono: the UI sprint is still happening... so there may be minor changes till the end of today
<seb128> I've the package ready to upload
<seb128> but uploads are blocked for flight 5 
<jono> ok, so its best to leave screenshotting until maybe tomorrow
<Mithrandir> jono: yes, or get the package off seb and install it.
* jono kisses goodbye to Saturday :P
<jono> I will wait for seb to do his thang :)
<JaneW> jono: or get the package from seb and kiss him? ;)
<seb128> jono: http://people.ubuntu.com/~seb128/gtk2-engines-ubuntulooks_0.9.2-1_i386.deb
<jono> JaneW, no thanks :)
<Mithrandir> jono: he's very cute, though
<jono> well, my mum thinks my dad is cute, but I don't kiss him all that much either :P
<seb128> JaneW: heh, without the kissing is fine too
<JaneW> touche!
<jono> seb128, so if I just install that package is that gonna be the likely final look of Dapper?
<seb128> jono: I can't promise they don't change something else today
<jono> no worries
<jono> I will wait till tomorrow :)
<seb128> would be better to wait a few hours to get over UI sprint 
<seb128> k
<jono> when are the daily ISOs generated ?
<jono> cheers seb128 :)
<infinity> These ones?  About an hour ago.
<jono> I mean the first daily with the final UI tweaks included
<Mithrandir> we're still supposed to have "this is not the final artwork" thingy?
<jono> Mithrandir, heh
<Mithrandir> jono: tomorrow at about 9-10 UTC they should be around.
<jono> Mithrandir, cool :)
<infinity> jono: Dailies are normally generated at ~07:30 UTC (so, published an hour or so after that)
<JaneW> jono: sorry about your saturday...
<mdke> jono, also strings aren't frozen til next thursday, so words in the ui might change, I think
* JaneW tries to actually finish the weekly report.
<Mithrandir> haha, mdzzzz.ogg is example-content. :-)
<jono> JaneW, no worries, its crunch time for the book
<JaneW> Mithrandir: really? Excellent!
<JaneW> Mithrandir: no wait - I was in that!
<Mithrandir> JaneW: yes, you'll be on a MILLION CDs.
<jono> mdke, is that just ubuntu specific stuff - I assume applications (gaim, OOo, Firefox etc) are likely to not include string changes?
<JaneW> ARGH!
<Treenaks> Mithrandir: you could add sabdfls moviegotchi ('Hi, I'm this geek from South Africa, can you tell me more about this Ubuntu thing?')
<Mithrandir> Treenaks: I'm just testing the i386 live cd.  Seems to work for me.
<Treenaks> Mithrandir: cool :)
<Mithrandir> so, now it's the amd64 live cd.
* infinity is burning the ppc livecd and wondering why he picked such a slow burn rate.
<infinity> Paranoia took over, I guess.
<Kamion> jono: espresso UI still isn't final unfortunately, although it's much closer than it was
<Kamion> in particular there will be images down the left-hand side of each page, probably
<jono> cool
<jono> Kamion, no worries
<jono> I will hold off on shots as long as I can :)
<mdke> jono, menu entries, etc
<jono> mdke, cool, so when the theme has settled down, I can probably take screens of applications they are unlikely to change, right?
<mdke> jono, i would have thought so, they are unlikely to be serious changes
<jono> cool, thanks :)
<Mithrandir> what's Jani Monoses IRC nick?
<simira> Janimo, iirc
<Mithrandir> grr, he's not on IRC and not respecting the flight-5 freeze.
<Mithrandir> I'll mail him
<infinity> Probably because his stuff won't land on our CDs.
<Mithrandir> or because he's not here.
<jono> ugh, anyone got horrible transparent menus in OOo
<Mithrandir> starting gimp and ooo on the live cd takes a little while..
<jono> hey sabdfl
<sabdfl> howdy
<Seveas> pitti, ping
<pitti> Hi Seveas 
<Seveas> are you working on the gnupg vulnerability?
<pitti> 'the'?
<pitti> the one fixed in 1.4.2.2?
<Seveas> yes
<pitti> on my radar, will do ASAP
<Mithrandir> jono: not transparent on the amd64 live cd, at least
<Seveas> if ASAP is a few hours/days away I see a great opportunity for me to contribute, is it ok if I try to make preliminary patches for breezy and earlier?
<pitti> Seveas: oh, of course :) that would rock
<infinity> Mithrandir: If you're keeping a tally sheet, PPC LiveCD is good on an iBook over here.
<Seveas> I assume dapper will get a UVF exception and just have the correvt version ;)
<jono> Mithrandir, odd
<Mithrandir> infinity: thanks.
<pitti> Seveas: if the only change is that bug fix, very likely
* infinity reboots to test on his thinkpad.
<Mithrandir> Riddell: what's the state of ia32-libs-kde fixage?
<Mithrandir> anybody with a powerpc around who could test an install of the flight 5 candidate?
<Riddell> Mithrandir: I just uploaded a fix, delete /etc/qt3 in the install rule
<minghua> pitti: Amaranth said here earlier that the diff between 1.4.2.1 and 1.4.2.2 is 101k (I haven't tried to confirm myself though)
<pitti> ouch
<Mithrandir> Riddell: thanks.
<Mithrandir> Riddell: any chance you could test or find testers for kubuntu cds?
<Mithrandir> (once they're built)
<Kamion> Mithrandir: janimo's stuff is in universe, so whatever
<infinity_live> Alright, WAY too late in the process to fix this now, but...
<infinity_live> Why do we have both nm-applet and the GNOME network thingee in the default live profile?
<Mithrandir> infinity: that should probably be fixed, yes.  Minor detail, really.
<infinity_live> Oh, because it's in the default laptop profile, period, and we don't tweak it on live.
<infinity_live> Mithrandir: Are you making a note of stuff like this to polish later? :)
<Riddell> Mithrandir: I can't really, don't have the bandwidth here even for an rsync and I doubt we'll fine people to test all the CDs
<Mithrandir> Riddell: do you want to release kubuntu flight-5 later or not at all, or?
<infinity_live> Mithrandir: Anyhow, everything is working perfectly on my Thinkpad.  Like a dream.
<Riddell> Mithrandir: yeah, next week I think
<Mithrandir> Riddell: ok; your call.
<Mithrandir> infinity_live: yes, I'm taking notes.
<Riddell> that means we'll get the UI changes in too
<Mithrandir> infinity_live: the edubuntu images should be built now, shouldn't they?
<Riddell> so I'm happy for a separate kubuntu flight 5
<Pygi> Mithrandir: does Edubuntu images need testing as well?
<infinity_live> Mithrandir: Yes, edubuntu is all ready for testing.
<Mithrandir> Pygi: yes.  I'm trying to find out if they're built yet or not.
<infinity_live> Mithrandir: live and install.
<Mithrandir> infinity_live: excellent.
<Mithrandir> Pygi: yes, as infinity_live says.  Live and install.  Please do tell me about what arches you test and whether you're successful or not.
<Pygi> Mithrandir: well, i386...k, I'll do the testing
<Mithrandir> Pygi: excellent, thanks.
<Pygi> Mithrandir: nevertheless, I already had it installed on like 25 computers, and it worked fairly good
<Kamion> to clarify Mithrandir's request above, I would very much like somebody to test Espresso on powerpc now
<Kamion> it *should* now get the yaboot configuration right, but I've been unable to test it myself due to hardware problems
<Mithrandir> Pygi: please do test both the live installer and the old installer if you have the time.
<Pygi> I tried the old one...It worked...
<Pygi> only the live installer more to test..
<Mithrandir> Pygi: did you test it with the images from http://cdimage.ubuntu.com/edubuntu/daily/20060310/ ?
<Pygi> Mithrandir: nop...
<Pygi> Mithrandir: Will do tho ...
<Mithrandir> Pygi: thanks.
<olemke> Mithrandir, ubuntu install on i386 worked fine, except that it still created 7 floppy drives although I don't have a single one
<Kamion> olemke: known udev bug
<Mithrandir> olemke: ok, that's not a new bug and not a critical bug, but I'll note it anyway.  Thanks a lot for testing.
<olemke> Mithrandir, np
<Kamion> https://launchpad.net/distros/ubuntu/+source/udev/+bug/27926
<Ubugtu> malone bug 27926 in udev "fstab  contains 8 floppy drives but PC does not have any" [Minor,Confirmed]  
<olemke> Kamion, ah ok, i thought it was already fixed
<Kamion> the devfs-paths compatibility helper is getting a little bit ... enthusiastic
<Kamion> olemke: nope, diagnosed somewhat but not fixed
<Kamion> I may have to start trying to think up workarounds soon
<infinity_live> Kamion: I don't have permission to install anything on the iBook here, unfortunately...
<infinity_live> Kamion: Though, speaking of the iBook in question, do we have the utility to extract Broadcom firmware on the livecd?
<Kamion> no, not sure it's even packaged
<Kamion> although I believe there are packages in Debian contrib or something - we should look
<Kamion> damnit, gotta fix madison-lite's regex search mode
<Kamion> bcm43xx-fwcutter
<infinity_live> Well, doesn't do me much good with no way to get it on the laptop. :)
<Kamion> it's an installer package in fact
<infinity_live> But we should make a note to get that on the CD, perhaps.
<infinity_live> Oh, it's nonfree?
<Kamion> the linksys firmware is available in a wgettable location so it grabs that
<Mithrandir> infinity_live: USB stick? :-)
<infinity_live> Ahh, can't it also cut firmware from MacOS, though?
<infinity_live> (which would be helpful in my case)
<Kamion> infinity_live: fwcutter itself isn't, but the fact that it's grabbing non-free stuff from the web pushes the package into contrib
<Kamion> infinity_live: yes
* infinity_live pisses off for the evening.
<infinity_live> Mithrandir: Good luck testing.
<Kamion> if we just make the question default to false, should be fine to suck into our archive
<Mithrandir> infinity: thanks, enjoy your evening.
<Kamion> I think
<seb128> Kamion, Mithrandir, infinity, whoever does a note for flight5: openoffice menus are broken (transparents) with current theme, that's known and already fixed
<seb128> if you could mention it so we don't get a zillion of bug on it
<Kamion> not me, delegation ;-)
<Kamion> perhaps somebody could put that on wiki/DapperFlight5
<Mithrandir> seb128: I'll note it.
<seb128> Mithrandir: thank you
<Mithrandir> jono: ^^^, btw
<jono> Mithrandir, :)
<infinity> seb128: Can you upload for that (and double-check the theme you're uploading doesn't break in new ways), so that if we have to redo the images for some other reason, we get that fix for free?
<infinity> Mithrandir: Assuming you're okay with that scenario.
<Mithrandir> infinity: ok.
<infinity> seb128: I'm sure you're aware of this, due to Mark running Tbird religiously, but the new theme kinda makes Thunderbird... Uhm.. Ugly... No better description than that, really. :)
<infinity> seb128: The 3D column header buttons look kinda sketchy, and the separator between the message list and preview window is an off colour, etc.
<seb128> infinity: didn't hear anything about that yet
<infinity> seb128: AND, this has resurrected the "progress bars draw outside the lines" bug that we previously had.
<infinity> (Just noticed that)
<Mithrandir> nautilus' sftp stuff needs a go-faster mode.
<seb128> infinity: no surprise, it's using cairo again
<Treenaks> Mithrandir: A 'turbo boost' button!
<infinity> seb128: Right, well, a fix would be nice. :)
<seb128> infinity: do you still have the bug number handy?
<seb128> infinity: or a testcase or something
<infinity> Testcase is "do anything with thunderbird that involves a progress bar"
<seb128> infinity: clearlooks guys are to UI sprint to I can show them
<infinity> (So, send mail, check a mailbox, etc)
<seb128> hum, k
* infinity digs for the bug.
<seb128> I would have it handy at home
<seb128> but laptop doesn't make things easy :/
<infinity> https://launchpad.net/distros/ubuntu/+source/gtk2-engines/+bug/31480
<Ubugtu> malone bug 31480 in gtk2-engines "progress bar colours waay outside the lines" [Minor,Confirmed]  
<janimo> Mithrandir: does the restriction in topic apply to universe uploads as well?
<Mithrandir> janimo: yes, that is, I'd like to be very conservative this time around.
<janimo> ok
<Mithrandir> it should possibly have gone out on u-d-a too, since not everybody is on irc too much
<Mithrandir> infinity: it's only for the "I don't know how much time this will take" progress bars, though.
<infinity> Mithrandir: Once the ia32-libs-kde build and installs, you should be able to trigger a kubuntu livefs build on king (amd64) again, then do a full CD set for kubuntu.
<Mithrandir> infinity: nobody around who can test it properly, though.
<infinity> Mithrandir: Yeah, it's just the bouncing bars, I think seb and I discussed that the last time we talked about the bug. :)
<Mithrandir> I can't test ppc and I might not have time for kubuntu in addition to ubuntu.
<infinity> Mithrandir: True, but if you call 20030310 the candidate anyway, and make Riddell and Co test it over the next day or two.. :)
<Riddell> infinity: I'm not at home to test stuff, I'd rather just do it early next week
<infinity> Riddell: Fair enough.
<Kamion> Mithrandir: universe and multiverse uploads haven't caused me problems in the past, so I think we can lift the restriction on those guys
<Mithrandir> Kamion: ok.
<Mithrandir> janimo: fire away, then as long as it goes to universe.
* ..[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 | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity |  UI  sprint in #dapper-look | Flight5 in preparation - uploads to main must be authorized by infinity/mithrandir
<janimo> Mithrandir: ok, I have no uploads pending but wanted to be aware just in case
<infinity> seb128: Oh, another bug I'll have to bug you about later involves NetworkManager's interaction with this theme...
<Mithrandir> janimo: it's the first flight where I'm pretending to be Colin, so I'm extra careful.
<janimo> Mithrandir: undesrtood. good luck :)
<Mithrandir> janimo: speaking of, is xubuntu going to have flight-5 too?
<seb128> infinity: the look of the bars for the signal?
<Mithrandir> or, you're not on cdimage yet.
<infinity> seb128: (The NM icon was perfectly flat/transparent with the old theme, but with both this one and the one I previous had progress bar issues with, NM's icon doesn't quite live happily in the notification area)
<janimo> Mithrandir: not until the packages are in main which is blocked according to Colin
<infinity> seb128: The icon seems a bit "raised" or drop-shadowed, but only with these cairo-enabled themes, not with the old-skool themes.
<seb128> infinity: I would say it's a nm-applet bug
<infinity> seb128: Conceivably, though odd that it was fine a day ago. :)
<Mithrandir> janimo: ok
<seb128> infinity: that's because the panel has the same color has the icon background?
<infinity> seb128: It seems more than just a colour issue, since I see a paticularly dark line at the bottom of the icon.
<infinity> seb128: But I'm also passing out and in need of sleep, so I'll whine about this one (with blown up screenshots and arrows and charts) later.
<seb128> k, I'll have a look today if there is time for it
<janimo> seb128: according to Manu on u-devel, the logout dialog asks gdm if suspend is supported
<janimo> is that final for dapper?
<seb128> exact
<seb128> dunno yet
<pitti> infinity, Kamion: FYI, rookery:~pitti/bin/checkrdepends is a script that checks for reverse build/binary dependencies for all arches (melanie -n -R replacement)
<seb128> why?
<janimo> seb128: I use hal for this in xfce logout too
<janimo> and it's weird to suspend through hal
<seb128> "too"?
<seb128> we use gdm
<janimo> but ask about the capabiliti behind its' back
<janimo> seb128: aha
<seb128> ??
<seb128> what is funny?
<janimo> I thoigh it's through g-p-m
<seb128> no
<janimo> nothing I said aha not haha
<seb128> you just ask if it uses gdm
<seb128> oh, k
<doko> pitti: please reference myspell-sw myspell-th in the language packs
<janimo> so the logout dialog does not use gpm_can_suspend()?
<janimo> which in turn asks hal
<Kamion> pitti: cool, thanks!
* Kamion copies that to drescher
<pitti> doko: I'm not supposed to upload anything right now, I'll queue it
<doko> pitti: that's what I meant
<pitti> Kamion: be warned, it's really slow and hideous (wget/grep-dctrl shell)
<pitti> Kamion: but it's good enough on rookery for me
<seb128> janimo: no, it uses gdm like for breezy, hoary, etc
<janimo> seb128: ah, ok.I thought that with g-p-m in all that is offered is used
<seb128> EPARSE
<seb128> anyway we might switch
<janimo> al that is offered: query/action for suspend methods through hal
<seb128> I'll have to discuss it with Kinnison
<janimo> which wraps pmi in ourt case but it's cleaner
<janimo> or pitti who is here :)
<janimo> there's a mention of pmi in hal changelog but no code that I found
<infinity> pitti: The wget can be circumvented on drescher, since we're on, y'know, drescher. :)
<pitti> infinity: sure, feel free to hack it however you like :)
<pitti> infinity: but I need the wget on rookery
<Lathiat> infinity: any live or kubuntus?
<infinity> Lathiat: ubuntu-live has been ready for ages.
<pitti> infinity: it told me that the gnutls transition is still a loong way to go on the SCCs
<Lathiat> latest build i assume?
<infinity> Lathiat: Riddell has opted to hold off on Kubuntu until early next week, since he can't really test it right now.
<Lathiat> infinity: ok, cheers
<infinity> Lathiat: Yes, current for daily-live please.
<Kamion> pitti: fine by me
<infinity> pitti: How long is long (not counting hppa, please)
<Kamion> infinity: (it'll also be fast on drescher)
<Mithrandir> we _really_ need somebody to test installation on ppc, though
<infinity> Kamion: You going to pop it in lp_archive's ~/bin?
<infinity> Mithrandir: Wish I could. :/
<Kamion> infinity: done ... except whoops, no grep-dctrl on drescher
<infinity> pitti: Do you have your laptop and a spare partition handy to do PPC install testing?  Or are you sitting behind a skinny pipe right now?
* Kamion goes to file an RT request
<pitti> infinity: http://people.ubuntu.com/~pitti/tmp/gnutls11.txt
<Mithrandir> infinity: I know you can't.  That won't stop me from whining until somebody tests, though.
<pitti> infinity: hppa is the worst, right, but ia64 doesn't look much better; otherwise it's mainly evolutino
<infinity> Mithrandir: <grin>
<pitti> infinity: yes, I can test ppc
* pitti jigdos
<infinity> pitti: Well, I said "not hppa" because there's nothing I can about it until we light up the hppa buildds in the DC.
<Mithrandir> ok, whoever told me of the gksudo-on-the-live-cd bug.  I can reproduce it, gksudo doesn't work unless sudo has run first.
<infinity> pitti: I can do something about ia64 and sparc. :)
<pitti> infinity: right
<Kamion> Mithrandir: heh, do we need to quickly make espresso-gtkui.desktop use sudo instead?
<Kamion> because otherwise the icon won't work ...
<Mithrandir> Kamion: we need to fix it somehow, at least, yes.
<infinity> pitti: Yeah, I should be able to sort all of the non-hppa stuff first thing next week.
<Kamion> I'll do that quickly then
<pitti> any idea why? gksudo gedit worked fine for me, although I got a nasty warning
<Mithrandir> pitti: on the live cd?
<Mithrandir> pitti: also, what kind of warning?
<infinity> pitti: If hppa continues to drag, we may have to intentionally break it for a while for the sake of the other arches. :/
<pitti> Mithrandir: yes
<pitti> Mithrandir: something like 'cannot retrieve authentication info'
<Mithrandir> pitti: uh, that's crack.
<pitti> Mithrandir: but it works nevertheless usually, just not for espresso
<Kamion> my guess is that it's due to the .sudo_as_admin_successful thing
<Kamion> mvo says gksudo is pretty fragile
<pitti> oh, does gksudo check for that file?
<Kamion> it parses the output of sudo, so the extra text might well have broken it
<Mithrandir> there's no extra text output?
<pitti> Kamion: sudo doesn't output anything different
<Mithrandir> that's bash
<Kamion> oh
<Kamion> don't believe it checks for that file, but dunno
<Kamion> can somebody make sure a bug report is filed?
<Kamion> (mvo asks)
<mvo> and please subscribe me as well (if I'm not default subscriber already)?
<Mithrandir> Kamion: I need to test this a tiny bit more before we reroll cds.
<pitti> I will once I'm in a live system again
<infinity> seb128: Still working on that ubuntulooks/ubuntu-artwork update?
<Kamion> sudo will work in a .desktop file on the live CD, right? it has passwordless sudo - it won't mind running without a tty?
<seb128> infinity: was about to upload, is that still ok?
<infinity> seb128: Now's your big chance to get it in, there's talk of respinning CDs.
<infinity> seb128: Yes, upload. :)
<Mithrandir> Kamion: that'll work, yes.
<Mithrandir> Kamion: please change espresso.desktop, then. :-(
<Kamion> doing
<infinity> Mithrandir: You're down with the process to spin livefs builds and image builds and jazz?
<Mithrandir> infinity: yes.
<Mithrandir> infinity: I've done live cds, but not regular cds before.
<Mithrandir> oh well, I get to test the i386 regular cd while we wait, then.
<seb128> infinity: done
<infinity> Mithrandir: Rock.  I'll leave you alone then, may you develop an Irish accent by the end of the day.
<Kamion> it's easy, 'for-project ubuntu cron.daily' and 'for-project ubuntu cron.daily-live'. no hassle
<Mithrandir> infinity: thanks.  Now get some sleep and have a good weekend.
<infinity> Will try, on both counts.
<infinity> PENGUINS!
<Mithrandir> penguins++
<Mithrandir> pitti: if you could test the regular installer for ppc in the meantime, I'd be happy
<pitti> Mithrandir: yes, I will
<Mithrandir> pitti: thanks a lot.
<pitti> Mithrandir: download is nearly complete, then I'll start the install
<pitti> Mithrandir: shall I test any amd64 images?
<Mithrandir> pitti: feel free, though they seem to work for me so I'm not very fussed about those.
<pitti> ok, if they have already been tested, good
<Mithrandir> if you feel like doing some mindless tasks, excellent, I have only tested them on one machine here, but I can't imagine that much being broken on them..
<pitti> my last test cycle was yesterday, so I agree
<infinity> pitti: Testing espresso on PPC live (after curcumventing the gksudo bug) might be nice, so Kamion doesn't have to do two espresso uploads. :)
<pitti> infinity: yes, I'd be glad to do that
<infinity> circumventing, too.
<pitti> I never tried espresso on ppc so far
<Kamion> Mithrandir: uploaded and pushed
<Kamion> infinity: too late
<Kamion> although testing would be good, obviously :)
<infinity> Oh, well, s/two uploads/two image release cycles/ :)
<pitti> yesterday was pretty catastrophic, but with current packages it should look much better
<Kamion> right, the adduser bug being fixed will help a lot, if nothing else
* Mithrandir decides to do this i386 install in catalan
<Mithrandir> (what could possibly go wrong?)
<seb128> infinity: <Remenic> seb128: ok, firefox/thunderbird bug fixed too now
<bSON> hi
<bSON> i noticed fat partitions are always put into fstab in a way they can only be accessed by root (no "user")... why?
<Kamion> bSON: known bug
<bSON> Kamion: "bug" means it wasn't planned that way, i guess
<Mithrandir> Kamion: any idea why https://launchpad.net/distros/ubuntu/+source/espresso doesn't show your latest upload?  Source hasn't been published yet?
<Kamion> Mithrandir: publisher runs at the top of the hour, and I uploaded around 12:30 - i.e. it's still in accepted
<Mithrandir> ok, and that page shows stuff which is published.
<Kamion> right
<Kamion> I don't think there's a web UI for queue state yet
<Mithrandir> ooh, the transparent menus were.. shiny.
<Mithrandir> or something
<pitti> Kamion: hm, I still get the proxy question without network, I thought this was fixed already?
<Kamion> pitti: I thought it was too. choose-mirror bug with installer syslog?
<Kamion> JaneW: 90-12 = 78 not 88, right? ;-)
<pitti> Kamion: yep, will
<JaneW> Kamion: argh
* JaneW kicks self in butt... 
<Mithrandir> i386 install worked fine
<jordi> seb128: ping
<jordi> does anyone know offhand which Ubuntu package provides the "About Ubuntu" menu item?
<pitti> Mithrandir: '49710d 6h28m15s remaining' - that'll still take a while ;)
* pitti -> lunch
<jordi> pitti!
<Mithrandir> jordi: I'm running in catalan now.
<Mithrandir> just for you
<jordi> Mithrandir: really? :)
<Mithrandir> yes
<Mithrandir> in my test install, but still
<jordi> so, Open the system menu and have a look at that menu item
<jordi> You'll find a funny feature in Ubuntu Catalan :)
<Mithrandir> Ubuntututututu
<jordi> alias a "Quant a Ubuntututututututu" string
<jordi> so, it's funny but I can't find that string anywhere.
<Mithrandir> haha, how excellent.
<mdke> jordi, might it be in ubuntu-docs?
<mdke> otherwise, gnome-panel, I spose
<jordi> mdke: hmm.
<jordi> let's try that
<jordi> mdke: ubuntudocs does have that string
<jordi> but I was supposing it was something in the doc
<mdke> I'm not sure
<ogra> grumble ... 
<ogra> one shouldnt write and iso to CD while rsyncing it ... gah
<Treenaks> ogra: rsync needs cdrecord capabilities!
<ogra> yeah !
<Treenaks> and a mail client!
<ogra> i think you even could do that with packetcd :)
<irvin> ploum: you there?
<ploum> irvin: yes
<ogra> Mithrandir, Kamion, i need a new build for edubuntu :(
<ogra> (dunno why the last one worked and this one misses ldm :( )
<Mithrandir> ogra: live or both?
<ogra> Mithrandir, i first need to fix it, only install for now
<Mithrandir> ogra: are you going to use espresso too?
<ogra> (ltsp breaks the install if ldm is gone ... )
<ogra> its there but i'm not sure yet ...
<ogra> it will depend on the branding i think ... if we can get all the nifty flash stuff ready etc, i think we'll have it, yes
<ogra> but i dont think a ubuntu branded one makes sense ... not sure
<ogra> so how do i get ldm on the CD quickly now ... 
* ogra adds it to the server seed
<Mithrandir> pitti: did the ppc install work out?
<pitti> Mithrandir: finished the installation two minutes ago
<pitti> Mithrandir: have gdm now, I'll test the basic functionality with a fresh user
<Mithrandir> pitti: thanks
<pitti> Mithrandir: apart from the absolutely grave bug 'time estimate wrong while installing packages' it went without problems
<pitti> :)
<Mithrandir> pitti: well-known aptitude bug. :-)
* Mez should really clear out old kernels
* ogra twiddles thumbs waiting for the seeds to join ... to build a new metapackage ...
<Mithrandir> ogra: btw, feel free to upload that once you have it, please just make sure it looks sane before uploading. :-)
<ogra> yep
* ogra whould love to be able to just push it through the buildds ... given that it will take 1-2h to reach the archive :/
<infinity> 2 hours now that cron.daily has just started.
<infinity> If you'd uploaded 5 minutes ago, you'd have had a better turnaround. :)
<ogra> i first have to wait for my seed push to show up ... add that time :)
<pitti> ogra: oh, you do the seed stuff on your local box?
<Mithrandir> ogra: nah, as long as it takes less than an hour, you're fine.
<pitti> ogra: with the current bzr that'd take ages...
<infinity> I think we're going to need to get cron.daily cycles happening faster before we hit release crunch next month...
<ogra> pitti, i push it via sftp ... but i have to wait until the cronjob moves it
<ogra> pitti, its not about bzr 
<pitti> ogra: I do seed stuff on chinstrap with a local branch, that's much faster
<ogra> pitti, i dont care about push/pull colin merges the edubuntu changes in the public seed branch via cronjob every 20min
<ogra> thats what i'm waiting for now ...
<ogra> before i can run the update script in the metapackage
<ogra> (during flights these idly moments waiting for a single fix are the suck)
<pitti> Mithrandir: I deem ppc/install fine now
<Mithrandir> pitti: excellent
<pitti> Mithrandir: a fresh user profile doesn't have g-p-m, but the old battstat thingy, but that's not really a blocker
<Mithrandir> pitti: I end up reading "fresh" as "french" and wondered "hmm, so the French have different user profiles too?  Oh well.."
<Treenaks> Mithrandir: of course they do.. all acronyms have to be reversed
<pitti> *chuckle*
<pitti> Kinnison: is that known? ^ (battstat instead of g-p-m in fresh user profile)
<Genman> Hi
<Genman> Can anyone tell me how to report a bug in the fridge site ?
<ogra> Kamion, can you speed up my last seed push to show up in the public part ? 
<seb128> jordi: gnome-panel
<Genman> Hmm.. if anyone care. fridge site has a bug. the menu is going to the buttom of the site.
<ogra> yay, finally
<Kinnison> pitti: Hmm, that's odd
<Kinnison> seb128: I thought you'd removed battstat from the default session?
<seb128> pitti: you should have both
<seb128> Kinnison: no, didn't come yet to do it with the UI sprint
<seb128> next week with GNOME 2.14.0
<pitti> Kinnison: ah, wait, maybe I don't see the icon by default if I take out the battery?
<Kinnison> pitti: no you won't
<pitti> Kinnison: I do see an icon in my own profile, but that's a customized one
<Kinnison> pitti: Hmm
<pitti> Kinnison: ah, ok, PEBCAK then :) thanks
<seb128> pitti: the battstat applet is an applet
<seb128> pitti: g-p-m uses the notify area, ie: it's not in the panel profile
<seb128> no?
<pitti> is it planned to remove battstat for new profiles?
<ogra> if we ship g-p-m we should ...
<Kamion> ogra: I imagine it's got there by now ...
<ogra> Kamion, yup
<seb128> pitti: yeah, but it's not clear if we should stop building the applet or let it as a choice
<ogra> already running update
<pitti> seb128: oh, it isn't possible to just not activate it by default?
<seb128> if we stop building it we can drop it from panel profiles on update
<pitti> that would solve it for upgrades, too, right?
<seb128> pitti: there is an gnome-applets tool to mark applets as deprecated so they get dropped cleanly on update
<ogra> but then its gone permanently
<seb128> pitti: yeah
<pitti> Mithrandir: does the live CD delibarately drop into text mode after setting up X and the account?
<Mithrandir> pitti: ddcprobe does it in some cases through a chvt
<Mithrandir> I'm not sure how to fix it
<pitti> well, not a blocker anyway, I was just curious whether it's deliberate for debugging or a bug
<infinity> We'll figure something out in the next month.
<pitti> anyway, ppc/live boots fine
<infinity> pitti: It's a bug, but a deliberate one, currently.
<infinity> If that even makes sense.
<Mithrandir> it's a bug, but not an important one ATM
<Mithrandir> pitti: we're rolling new live images now
<pitti> infinity: I'm still trying to redefine the word 'bug' to match 'deliberate' :)
<pitti> Mithrandir: ooh, my quota will love you :)
<Mithrandir> pitti: rsync, dude. :-)
<pitti> Mithrandir: even with rsync
<pitti> Mithrandir: anyway, ping me when they are public, then I can help testing htem
<pitti> Mithrandir: (I'm just scraping at the 92% mark now, so I have to be a little aware of what I'm doing, but nevermind)
<Mithrandir> pitti: willdo
<seb128> Mithrandir: I've an another theme update fixing progress bar with firefox and thunderbird and an another bug, should I upload it or better to wait?
<Mithrandir> seb128: I'd prefer if you waited at least until we have one of the live CDs tested, which should be on the range of half an hour to an hour.
<infinity> seb128: I can live with the Tbird bug for a day. :)  It's not critical.
<ogra> oh, kubuntu live ppc is oversized ? 
<ogra> Riddell, ^^ are you aware ?
<Kamion> "oversized" now means "won't burn on regular CD media", BTW
<Kamion> since we upped the image size to 700MB across the board
<seb128> Mithrandir, infinity: oki
<pitti> hmm, logout on (ppc) live CD doesn't do anything but hang the panel
<Riddell> ogra: these crazy powerpcs and their 50 different linux builds
<ogra> heh
<Mithrandir> seb128: the install cds will have the transparent menus bug since I'd prefer to end this day at some point.  The live CDs will be fixed, though.
<ogra> Riddell, just drop a language :) 
<infinity> pitti: It worked for me...
<pitti> after 30 seconds it does
<pitti> anyway, not a biggie either
<pitti> shutdown hangs after ejcting the CD, too
<pitti> hm, this worked yesterday
* pitti blames wrong moon phase
<Mithrandir> pitti: press enter
<pitti> that worked
<irvin> pitti: got a sec? i have a one quick question.
<pitti> IIRC yesterday it auto-powered-off after 30 seconds or so
<pitti> irvin: go ahead
<seb128> Mithrandir: ok, so please keep the flight5 note about it :)
<ogra> so we need to ship a Mithrandir with every CD that tells you "press enter" in the end ? 
<Mithrandir> seb128: yes, will do.
<Mithrandir> ogra: no, it says on the screen.  It's really a casper bug.  Or usplash.  Or something.
<ogra> ah ...
<ogra> but i liked the idea :)
<Mithrandir> I don't like support work, so I don't. :-P
<ogra> "includes a personal assistant now"
<sladen> Mithrandir: transparent menus?  Is that the Xorg-configure bug where the shell and menus both appear at the same time?
<Mithrandir> sladen: uh, no, it's a theme bug, afaik.
<Mithrandir> sladen: which just affects ooo
<Treenaks> Mithrandir: everything is an OOo bug :P
<doko> Treenaks: write your next spec with OOo ...
<zul> heylo
<Treenaks> doko: Are you trying to kill me?!
<Treenaks> doko: :P
<derekS_> quick question, just reading the DapperDevSatatus, what is the difference between Implemented and Approved? Is something that is approved already implemented?
<Kamion> approved => specification (design document) approved so implementation can safely proceed
<Kamion> implemented => implementation actually done
<derekS_> so a lot of these things that say "approved" weren't actually done?
<Kamion> indeed, anything that says just Approved isn't complete yet
<Kamion> but if it's still in the report then I believe we're still shooting for completion
<ogra> oh, why was 20060310 deleted from my daily-live dir ?
<Kamion> (though I'm not sure, I haven't seen today's report)
<derekS_> Kamion: so anything that says "deferred" isn't being worked on (or most likely won't be completed) but anything that says approved will hopefully be done?
<derekS_> i got it now :)
<mgalvin> Kamion: just to be sure you know, i am finishing up the review now, i will let you know when its ready
<Kamion> mgalvin: thanks - Mithrandir and infinity are coordinating this release
<Kamion> derekS_: right
<Kamion> ogra: must've been deleted manually, as far as I can tell
<ogra> strange
<Kamion> the log for 20060310.1 doesn't say that it's purging it
<Mithrandir> mgalvin: excellent, thanks.
<Mithrandir> ogra: is edubuntu getting there?
<mgalvin> Mithrandir: np, half way there now
<ogra> Mithrandir, once -meta is in the archive...
<ogra> does anybody else find the LP build log overview less usable than lamonts ? 
<Kamion> pitti: hmm - could I get questions.dat from that install too?
<Kamion> sorry, should've asked for that to start with but I didn't remind myself of the code first
<pitti> Kamion: of course, will attach
<Kamion> thanks
<pitti> ahh, booting current dapper on powerpc is sooo nice again - display, sound, network, everything is working :)
<mjg59> Sleep?
<pitti> mjg59: that has never been broken fortunately
<Engla> pitti: that sounds great
<Engla> what model do you have?
<pitti> Engla: iBook G4
<pitti> Engla: 800 MHz, with ATI Radeon 9200
<pitti> Kamion: attached
<ogra> Mithrandir, do you ping if the new liveCD is ready for testing ? 
<Engla> pitti: do you have dri /3d enabled by default?
<infinity> seb128: BTW, remember how I said Thunderbird got "ugly" with broken 3D widgets and weird coloured separation bars?
<infinity> seb128: Your last upload fixed that.
<pitti> Engla: yes
<Engla> Last daily livecd I tried gave me that
<Engla> I was thrilled
<pitti> Engla: that has worked since warty
<infinity> seb128: So, if your next upload fixes the progress bar bug, the Thunderbird is happy again.
<Riddell> pitti: MainInclusionReportKwinCrystal up, quickish review appreciated if possible so I can upload the new kubuntu-default-settings from the uisprint
<seb128> infinity: nice :) There is also a bug on update which vanish once the app restarted
<Engla> pitti: doesn't work by default on my ibook in breezy
<seb128> s/app restarted/app is restarted
<Mithrandir> ogra: the new ubuntu or edubuntu one?
<seb128> infinity: BTW do you ever sleep? :)
<ogra> Mithrandir, i thought the whole livefs needs a rebuild ? 
<pitti> Riddell: yes, doing now
<ogra> Mithrandir, i can trigger the edubuntu live build myself if you notify me
<Mithrandir> ogra: oh, you need an edubuntu livefs rebuild?  Just a second and I'll trigger you one
<ogra> Mithrandir, noo
<ogra> Mithrandir, you said we'd need a new live build in #c
<ogra> since i didnt see one yet, i was waiting for a new one to show up
<Mithrandir> ogra: edubuntu livefs != ubuntu livefs.   It'd be bloody helpful if you told me which one you were talking about.
<ogra> if i mistook that, dont bother
<ogra> i always talk about edubuntu ;)
<infinity> seb128: Sometimes.
<ogra> wow, daniels is on a bug triage session ...
<simira> :-)
<infinity> s/triage/unassign/
<pitti> Riddell: oh, that's a trivial one, go ahead
<Mithrandir> pitti: feel free to test new live now.
<Mithrandir> I'm taking a break while my images sync down
<pitti> yay, /me cranks up rsync
<Mez> what happened to network-manager anyways
<Mez> ah - nm-applet has been made into it's won package
<Mez> grr
<Mez> network-manager is completely broken
<Mez> other than the dispatcherd
<Q-FUNK> is there any repository where I could find versions of ubuntu-artwork prior to 3? i.e. prior to ubuntulooks
<ogra> Mithrandir, edubuntu live are all fine (apart from usplash timing out on ppc and a missing opportunity to select widescreen resolutions for non detected lcd panels (read that as *all* lcd's i have here))
<Mithrandir> ogra: goodie.
<ogra> yep
<ogra> even if i still see it as major regression that i have no opportunity to use the liveCd on any of my laptops around without getting headdaches from blurry streched screens :)
<ogra> we need to find a way to capture that for dapper+1 ...
<Mithrandir> ogra: patches accepted. :-)
<pitti> Mithrandir: latest ppc/live looks good; any changes compared to the previous image that I should put particular attention to?
<ogra> Mithrandir, ENOTIME (in this release cycle) 
<ogra> i bet you want some g-s-s fixes rather :)
<Mithrandir> pitti: check that double-clicking espresso starts espresso, and if you have time, do a full install
<Mithrandir> ogra: I'm just pondering switching to xscreesaver, to be honest.  gss is still a bit funky for me.
<pitti> hm, then I'll trash my freshly installed dapper, but oh well..
<ogra> Mithrandir, inderstood ... i'll do what i can ...
<ogra> *understood even
<Mithrandir> pitti: if it's fresh, no harm in nuking it. ;-)
<pitti> Mithrandir: right, just a matter of time
<pitti> Mithrandir: confirmed, espresso starts now with the icon
<Mithrandir> pitti: excellent
<pitti> the s/gksudo/sudo/ hack?
<Mithrandir> yup
<ogra> does anyone know if these horrible apricot colors are final ? 
<Mithrandir> ogra: TTBOMK, yes
<mgalvin> Mithrandir: the "this is not the final artwork" splash still shows up for me, not sure if you guys have fixed that yet for the flight
* pitti has a nice script for turning a default isntallation to his prefered setup anyway, so that'll be quick
<ogra> (they look totally awful with edubuntu wallpaper and gartoon icons) 
<jsgotangco> i like the one with the handwriting
<jsgotangco> lol
<Mithrandir> mgalvin: I see it too.  I don't think artwork (as in, example content, splash, etc) is final
<mgalvin> ok, i just saw it when i rebooted and wanted to make sure you guys were aware of it
<ogra> dapper-install-powerpc.iso         10-Mar-2006 16:41  696M 
<ogra> feel the edge !
<jsgotangco> lol
* ogra rsyncs
<Mithrandir> I'll be offline for a few more hours then returning for a few final tests before we can release.
<ogra> i should be ready by then
<Mithrandir> excellent.
<ogra> (unless i discover new breakage now)
<Mithrandir> yeah, if so we might end up postponing until tomorrow
<Mithrandir> anyway, I'm off
<ogra> enjoy
<pitti> Mithrandir: espresso crashes right after selecting the timezone, so I won't trash my install (I'll file a bug)
<Kamion> Mithrandir: pitti's bug 34332 suggests to me that espresso may be hosed on powerpc; not entirely sure
<Ubugtu> malone bug 34332 in espresso "crashes right after timezone selection" [Normal,Unconfirmed]  http://launchpad.net/bugs/34332
<Kamion> debconf.DebconfError: (10, "console-data/keymap/qwerty/layout doesn't exist")
<dooglus> when I run "dpkg-reconfigure xserver-xorg" in dapper, chroot'ed to an etch partition, my desktop wallpaper gets replaced with weird pictures.  should I report that against dapper or etch?
<trappist> dooglus: I'd say it's dappers job to keep your chroot chrooted.  if stuff is escaping I'd say report it against the running OS.
<LaserJock> pitti: ping?
<pitti> hi LaserJock 
<LaserJock> pitti: do you take care of tetex-base?
<pitti> not particularly
<dooglus> trappist: it seems that dapper is letting etch write to the X server's memory - I guess that's allowed
<pitti> LaserJock: but I can fix easy bugs in it, of course (just assign them to me in LP)
<LaserJock> pitti: well, I was just going to say that I saw that Debian released some major (RC and other) bug fixes that we don't have. I was wondering if it would be a good idea to sync?
<pitti> LaserJock: looks safe enough, I'll do some tests and upgrade it (probably on Monday"
<pitti> s/"/)/
<LaserJock> pitti: ok great
<ogra> Mithrandir, Kamion, edubuntu install all arches are go ...
<ogra> so in case Riddell is ready, w can release
<mkrufky> ok, i'd like to announce that I (finally) got stored procedures working for m$sql under php5 / breezy, after patching the php code and recompiling from scratch.....  I already understand that this functionality will not be officially added to Ubuntu until after dapper+1 , so, I'd like to upload these packages somewhere, in case someone else can benefit.  Is there a place where I can do that, or should I use my own server?
<mkrufky> ...in other words....... I have a working php5-mssql package... anybody want it?
<Chipzz> wont that be a problem since it has a non-free build-dependency? (I presume)
<mkrufky> nope
<mkrufky> nothing non-free about it
<Chipzz> no m$sql headers or something involved?
<mkrufky> the current php5 code has support for php5-mssql over TDS .... it is just not being compiled in the current ubuntu distros
<mkrufky> nope, no m$sql headers needed at all
<Chipzz> I had mostly the same issues some years ago
<mkrufky> ...and I cant even take the credit for this -- infinity told me how to do it
<mkrufky> oh ya?  what did you end up do ing?
<Chipzz> I had a patch for php-java support in debian
<Chipzz> back when java was in non-free/contrib
<LaserJock> mkrufky: -motu would help if you want to get it into Universe
<mkrufky> interesting
<mkrufky> LaserJock: hmm... I dont wanna step on infinity's toes... He told me he was planning to add it to dapper+1 ...  
<Chipzz> basically I submitted it to the maintainer, and got an answer that it couldn't go in the package since the package was for main and as such it coulnd't depend on anything in non-free/contrib
<mkrufky> LaserJock: i was mainly thinking it would be nice for an intermediate package for users that cant wait for dapper+1
<Chipzz> dunnow about the ubuntu policies about such things
<mkrufky> Chipzz: that kinda thing is fine with Ubuntu, because there are alternate repos (universe, multiverse, etc) for exactly that purpose
<LaserJock> mkrufky: well, if you want MOTUs to take a look at the package you can upload it to REVU
<mkrufky> LaserJock: sounds good.... is there a howto somewhere that explains the rules, and where to upload them?
<mkrufky> (not sure what REVU is, but the howto should probably cover that also)
<mkrufky> lol -- REVU = review, doesnt it?  (i should have known)
<LaserJock> mkrufky: sorry, phone. check out wiki.ubuntu.com/REVU and the #ubuntu-motu channel
<Chipzz> > My packages were built against the unofficial j2sdk1.4 blackdown packa-
<Chipzz> > ges, you may want to change that.
<Chipzz> PHP4 already has quite a hefty list of build-dependencies that we need
<Chipzz> to be able to trim down, so adding another module to the list of those
<Chipzz> being built is not a high priority.  Using Blackdown's JDK is also a
<Chipzz> non-starter, since it would require moving PHP to contrib.
<mkrufky> LaserJock: ok, good stuff.  I will do that.  Thanks
<Chipzz> in that case, I think a non-free build-dep would have caused php to contrib
<Chipzz> but no matter, I'm probably mistaken ;)
<mkrufky> Chipzz: this particular case is not a 'non-free' type of package.....  All I did was backport a patch from php 5.1.x  into php 5.0.5 (which fixed stored procedure abilities for mssql) and enabled the php5-mssql package (currently disabled in both breezy and dapper) .... none of it includes any extra headers...
<mkrufky> anyway, i'm going to test this a bit more, then I'll look into the motu stuff... maybe get it included into universe, but I dont think they will accept it, because I know infinity had plans for this at a later date.... we'll see what happens
<Chipzz> mkrufky: all the better then ;)
<LaserJock> mkrufky: of course I doubt infinity will mind if you do all the work for him ;-)
<mkrufky> :-D
<mkrufky> good point
<sistpoty> FYI: motu-meeting in #ubuntu-meeting now
<Treenaks> hmm.. should gfxboot hang the machine? (I can boot the installer properly with shift held down)
<Treenaks> (20060310 daily)
<CarlFK> dapper, shutting down - why do I see "stopping bit torrent tracker"?
* mdke yays at sabdfl
<Pygi> CarlFK: perhaps it's stoping a service? :-)
<CarlFK> perhaps, but I sure didn't ask for it
<Burgwork> CarlFK, there is a bug open for it
<CarlFK> thanks
<sladen> CarlFK: bittorrent isn't actually run
<CarlFK> sladen: I didn't think so, but the message was alarming
<CarlFK> root@viao:~# apt-cache search --names-only LiVES; lives - Powerful video editing tool
<CarlFK> why is what it found in lower case?
<sladen> probably because it does lower-case matching by converting everything to lowercase first
<CarlFK> nope
<Treenaks> because packages with uppercase names suck ;)
<CarlFK> cuz I couldn't find lives 
<CarlFK> normally... but not in this case ;)
<CarlFK> oh wait... 
<CarlFK> I added a repo it was in between search lives and Lives
<CarlFK> my scientific method is not very scientific 
<CarlFK> the search is not case sensitive:  apt-cache search --names-only lives = lives - powerful video editing tool
<CarlFK> supposedly it should be in main, but isn't.  is it too late to get added to universe?
<Mithrandir> Kamion: grr, ok.  That's my bug.  Should we postpone until Monday so I can fix the bug in the meantime?
<Seveas> lives in main? it's way too buggy for that...
<CarlFK> even if it wasn't, isn't it way too late?
<keherman> is it too late to request a package upgrade for Dapper?
<mkrufky> keherman: make the request... the worst that can happen is the request gets denied
<keherman> mkrufky, how do i request?
<keherman> i have a deb and everythign for them to use1
<ogra_> keherman, depends on the rationale ... generally we are past both freezes that block inclusion, but if important bugs are fixed and the change is small exceptions are possible
<Seveas> CarlFK, it's too late even for universe
<keherman> Adobe Acroread is not being upgraded
<CarlFK> shucks.  thanks.
<Seveas> even though sabdfl wants to postpone dapper
<keherman> staying at 7.0.1
<ogra_> Seveas, yes :((
<trappist> have you all seen mark's proposal to push the release back?
<keherman> but 7.0.5 includes revamped printing support to add CUPS
<Seveas> ogra_, it's sad indeed
<Seveas> 6 whole weeks
<trappist> I guess so.
<keherman> you mean Dapper is being dealyed over a month?
<mkrufky> :'(
<ogra_> i understand the reasons, but i dont agree we should do that ...
<tseng> its a proposal kids
<tseng> nto a mandate
* mkrufky wants dapper.... I'm afraid to install xorg7.0 on my own
<Seveas> keherman, it's not certain
<ogra_> it will be decided by the TB anyway
<keherman> it will be 6.06?
<ogra_> heh, good question
<trappist> god, so many docs would have to be modified
<tseng> sed is cool
<trappist> I'm afraid it would catch stuff that doesn't want to be caught
<Seveas> trappist, that alone may be quite a good reason not to push back
<mdke> I think it's a good idea to postpone
<trappist> not good enough by itself, but worth putting on the list for sure
<keherman> what are the reasons for a proposed delay?
<mdke> too many things are being done at the last minute for dapper, and dapper needs to be just right
<Seveas> mdke, true, but 6 weeks?
<mdke> 6 weeks is a little long
<Seveas> that's 1/4 of the cycle for dapper+1
<Treenaks> 2-3 weeks would be enough then
<keherman> Michael Dell will be watching closely
<mdke> 4 weeks would work I think
<keherman> Just to let you guys know, I work for IBM and we have 30 machines running Breezy and connecting via LDAP to a main server -- we are really looking forward to Dapper
<mdke> cool
<keherman> This is at my University of Massachusetts
<mdke> keherman, the more you look forward to it, the most it has to be right
<mdke> right now, the translations are late, the art is late, lots of stuff is late
<keherman> we did the Steve Ballmer protest at our school, dressed up as penuins...
<keherman> *penguins
<keherman> there is a hugs Ubuntu following here, and we would rather a delay than kill the image of Ubuntu as 'just working'
<keherman> http://video.google.com/videoplay?docid=-5336561617389993359&q=microsoft+linux
<mdke> that's pretty cool
<Mithrandir> I think we'll delay flight-5 till at least tomorrow.  Espresso doesn't work right on ppc, I need to fix that before we can release.
<Mithrandir> Kamion: 
<Mithrandir> Kamion: ^^^, even
<Mithrandir> sorry about that; my bug, but it's getting late here now and I'm tired, so the chance of me breaking something up is too big compared to the chance of me getting it right
* mdke hugs Mithrandir 
<Pygi> mithrandir: and I am *downloading* the Edubuntu one to test
<ogra_> Pygi, ppc ?
<Pygi> ogra: no, i386
<ogra_> so dont worry then :)
<Pygi> I do not worry, just wanted to say that I'll be testing it :)
<ogra_> Pygi, great, live or install ?
<Pygi> ogra: both...
<Pygi> I will test the espresso installation, and regular installation
<ogra_> cool, thanks for that :)
<Pygi> yw, but that's nothing :)
<Pygi> ogra: perphaps you might know if we will finally start releasing a server flight's ? :)
<ogra_> nope 
<ogra_> ask #ubuntu-server ;)
<Pygi> bah, people in there are sleepy :-P
<Pygi> thanks anyway ;)
<ogra_> but since edubuntu is a server distro, we already release a server version ;)
<Pygi> bah, agreed, but not the actual -server one ;) I remember colin (is that correct name? ;) ) telling that nobody wanted to build it for flight 4, and he was too busy, so was just wondering...
<ogra_> its up to the server team 
<ogra_> but actually the only stuff that really needs testing there is the kernels i guess
<Pygi> yup, running that kernels all the time...installation needed testing as well a few weeks ago as well, if I remember correctly
<sladen> jeez.  Did the new theme designer have her monitor badly adjusted.  Because I'm going to have to badly adjust mine to carry on working without having the back of my eye-balls burnt out
<Treenaks> sladen: ORANGEY GOODNESS
<Burgwork> Welcome to Ubuntu*
<Burgwork> *Now sponsored by Orange
<Pygi> slanden: lol :)))
<Treenaks> Burgwork: it's perfect for the Dutch football fans at the world championship this summer ;)
<sladen> Treenaks: I should switch to Kubuntu if I had a desire to spend more time looking at the window-border bling than the contents of my xterm
<sladen> s/should/would/
<Burgwork> sladen, jdud will be glad to know he has suddnetly changed sexes
<sladen> jdub: ORANGE?!?
<minghua> doko: hi, I posted a patch for ttf-dejavu, I saw that you subscribed to that bug as well
<Burgwork> oops, jdub (that was not a delibrate slip)
<minghua> doko: I'll test for version 2.3 soon
<doko> minghua: thanks, preparing 2.3 packages
<minghua> doko: great to hear that.  but I assume the upload has to happen after flight 5 is out
<doko> minghua: yes
<doko> lamont: please file a report for the python breezy thing
<sladen> jdub: you've moved the hue from ~25 to ~19 (the brown->orange slant), the saturation was gone from ~55% to ~70% which is the less appealing change as this reduces the contrast between the background and 'white' (effectively making the background gradients into foreground colours)
<sladen> jdub: if you reduce the saturation back to what it was, there's a probably that your changes should become more useable and less distracting
<doko> sladen: +1
<alicia> If dapper is going to be released 6 weeks later than originally planned, will the latest NetworkManager with WPA support be included?
<tseng> nope.
<tseng> reasons for extending dapper dont include 'throwing in more crack'
<alicia> I thought the crack was the way Ubuntu modified NM? Thats what I read on the NM devel lists
<tseng> crack is used pretty loosely around here
<tseng> but if you want a full list of reasons for not including the latest NM, see ubuntu-devel list
<alicia> I read Ubuntu-devel
<alicia> Off and on. Was it the atheros stuff?
<siretart> there is a pretty good explanation why updating to NM 0.6 is out of question
<tseng> no, it has nothing to do with athereos
<tseng> https://lists.ubuntu.com/archives/ubuntu-devel/2006-March/016170.html
<alicia> I must have missed it
<alicia> tseng: Thanks. Fair enough
<alicia> But I'm going to guess it will be in good shape for dapper + 1
<tseng> np
<tseng> quite likely
<alicia> excellent
#ubuntu-devel 2006-03-16
<jdub> sladen: -> #dapper-look, not my changes
<Burgwork> jdub, planet.u.c hits my system pretty hard when rendering
<Seveas> planet.u.c rss feed is brokn
<Burgwork> Seveas, is that what is causing it?
<Seveas> probably not
<jdub> Seveas: fixing
<jdub> Burgwork: when 'rendering'?
<Seveas> jdub, did you get my pm yesterday about the spammer on ubuntu-users?
<jdub> Seveas: yeah, unsubbed. you weren't around when i replied.
<Seveas> great, thanks
<Seveas> <jdub> Burgwork: when 'rendering'? <-- I assume in his browser
<Seveas> Heavy CSS 
<jdub> that's what i assumed too, but... ?!
* jdub blames firefox 1.5
<jdub> if he means his desktop system
<Burgwork> jdub, it loads the page, the page title changes, and then I get about 1-2 sec of 100% cpu usage
<Burgwork> Epiphany 1.6 on FC4 at work, actually
<jdub> same thing
<Seveas> same here - planet Ubuntu CSS is not the lightest
<jdub> it's not exactly complicated
<Seveas> maybe reduce the number of entries on it?
<Burgwork> wow, FF on this machine is even worse
<Burgwork> ff is 1.0.4
<Burgwork> anyway, known issue?
<desrt> is a version number like 0ubuntu1desrt1 a sane thing to do?
<sistpoty> desrt: not really...
<desrt> how should i do this?
<sistpoty> desrt: for what purpose?
<desrt> i want to have a package in my repo that apt will upgrade to automatically
<desrt> but... when you guys release a new one i want it to go back to yours until i reupdate my repo
<sistpoty> desrt: so that you can both ubuntu and your repository?
<sistpoty> +use 
<desrt> well.. like say i don't like a particular aspect of gnome-panel in ubuntu
<slomo> 0ubuntu1desrt1 would be sane imho
<desrt> and i want to ship my own package based on the ubuntu version... but unpatched
<slomo> for your personal repository
<tseng> desrt: looks fine to me
<desrt> cool.
<slomo> desrt: the logout dialog? or which aspect? ;)
<desrt> slomo; maybe :)
<desrt> tseng; our mission is clear!
<sistpoty> but will 0ubuntu2 be higher than? 
<tseng> desrt: aqua teen hunger force, assemble
<desrt> tseng; are your trayicon/inotify plugins any different than the stock ones?
<slomo> sistpoty: yes
<desrt> (ie: all your changes are to the core app, right....)
<tseng> desrt: trayicon, yes
<tseng> inotify, no
<slomo> sistpoty: ask dpkg --compare-version if in doubt :)
<desrt> er.  when i say 'stock' i mean 'dapper'
<tseng> um
<tseng> no and no
<desrt> good.
<desrt> this means we only need to maintain one separate package for that :)
<calc> so would the push back of dapper cause 6.10 to be pushed back as well, or just shorten its dev cycle?
<psusi> anyone seen Daniel Stone today?
<Burgundavia> psusi: daniels now works for a large finnish mobile phone company
<psusi> ohh crap
<psusi> so he's no longer maintaining Xwindows for ubuntu?
<Burgundavia> psusi: nope
<psusi> nobody is?
<Burgundavia> hmm, don;t know who
<tseng> infinity, fabbione know what they are doing with X in the mean time
<psusi> well, I've had a bug filed for a few months now that is a regression from breezy where intellimice get their forward/back buttons screwed up
<psusi> it really needs fixed before dapper goes final, and the bug has now been assigned to nobody
<Burgundavia> psusi: I have a bug where my touchpad is slow
<psusi> intellimice have the forward/back buttons on the side... myself and a few other users have noticed that they are broken in dapper... there are only 7 buttons on the mouse and firefox looks for 6 and 7 to be the forward/back buttons
<psusi> but about a month or two into dapper's cycle X decided that they are buttons 8 and 9... when the mouse only HAS 7 buttons... heh
<minghua> "only" 7 buttons? :-P
<Burgundavia> <troll>It is a KDE mouse</troll>'
<psusi> yea... left, right, middle, up, down, forwards, backwards
<sistpoty> hm... I use kde, and I rarely touch my mouse :P (win+q opens konsole for me, and there's alt-f2 *g*)
* psusi hugs his scroll wheel
<psusi> it's just odd that X thinks they are buttons 8 and 9 when you specifically tell it that it's a 7 button mouse
<minghua> so you probably mean a 2D scroll wheel count as four buttons in X?  then I understand
* minghua knows his scroll wheel is counted as button 4 and 5 in xorg.conf
<psusi> my mouse has a wheel... it counts as button 3 when I click it, 4 and 5 when I scroll it
<psusi> then there's a button on either side of the mouse that firefox uses for go forward and go backwards... handy those...
<psusi> they used to be considered buttons 6 and 7, which is what firefox still expects, but X decided midway during dapper's cycle that they are buttons 8 and 9
<Toma-> is the 10th March daily build bootable?
<whiprush> jdub: permissions on the award story don't let me add a "Discuss" link. (aka no edit privs)
<ajmitch> hey whiprush 
* sistpoty is off to bed... gn8 everyone
<whiprush> hey ajmitch 
<crimsun> off to Atlanta, back next week.
<crimsun> ECHANNEL
<Amaranth> eek
<Amaranth> bye
<elkbuntu> people seem to be having problems with dist-upgrade. they're doing it and getting seg faults and blank screens. 2 people in the last 10 mins have joined #ubuntu+1 with major problems
<elkbuntu> one of them was dist-upgrading direct from breezy, the other was already in dapper just doing a routine dist-upgrade
<desrt> http://veimages.gsfc.nasa.gov//7100/world.topo.bathy.200401.3x21600x21600.A2.jpg
<desrt> does anyone's firefox crash when trying to view this?
<desrt> The program 'Gecko' received an X Window System error.
<desrt> The error was 'BadAlloc (insufficient resources for operation)'.
<minghua> desrt: I get "The image ... cannot be displayed, because it contains errors"
<desrt> my firefox just pukes
<desrt> eog opens it just fine
<minghua> desrt: nah.  eog here doesn't seem to work either.  it just hangs
<minghua> just a data point for you
<desrt> wfm.
<desrt> perhaps you didn't download it correctly
<desrt> https://bugzilla.mozilla.org/show_bug.cgi?id=321581
<desrt> looks like this bug
<Ubugtu> mozilla bug 321581 in General "large image crashes firefox" [Critical,New]  
<desrt> Ubugtu; have a botsnack
<shawn_home> Ubugtu, bot snack
<shawn_home> its not an infobot;)
<minghua> I have sha1sum 489efd5349b4e7d9fb307686d282f083127e87e7 for that jpeg file
<Burgundavia> wow, Vista not booting on Intel Mac is getting people talking
<LaserJock> cool, I sure hope to try Dapper soon :)
<LaserJock> I'm having quite a bit of difficulties with my intel iMac with anything other than offical Apple stuff
<desrt> so..... my X server causes a kernel panic when it starts up
<desrt> this is new.
<desrt> infinity; i think it's the new fglrx
<desrt> infinity; seems it causes a kernel panic if the X server exits quickly
<desrt> infinity; does not occur with open source drivers
<calc> so use good non binary only crap :)
<CarlFK> dapper, 3 vga cards: 1agp, 2 pci.  what defiens which one ends up as the primary? 
<CarlFK> it is one of the pci, which seems odd
<enyc> moo meep
<Kamion> calc: I asked Mark that yesterday evening; in the event that we do go for a delayed release, then we'll probably shorten the next three release cycles by two weeks each to compensate
<siretart> Kamion: will the delay affect the date of the developers conference for dapper+1?
<Kamion> siretart: yes
<Kamion> and "would the delay ..." - subjunctive mood is appropriate since it's not settled yet :)
<siretart> right
<Burgundavia> 6 weeks is June 1st
<robotgeek> minghua: sorry about confusion
<doko> good morning
<mdke> morning
<mdke> do xubuntu and ubuntu-server count as "derivatives"?
<Mithrandir> xubuntu does, at least.  Unsure about -server.
<mdke> it's time to update the derivatives page on the website, I think
<Mithrandir> Kamion: speaking of which, should we have a flight-5 for u-s as well?
* mdke searches for the meaning of "derivative"
<mdke> there is basically no information about ubuntu-server on the website, so I might include it too
<sladen> mdke: this for the book?
<sladen> mdke: it's just another subset of packages... but I think Fabio has plans for it to be more
<mdke> no, for the website.
<mdke> there is a CD, so I think it should be visible
<sladen> I guess a difference might be that nothing /extra/ was imported into 'main' to build -server.  Whereas with K/Edu/X-, extra packages have been imported in order to make them possible
<mdke> possibly, but they are all in main now
<mdke> except for xubuntu, at present
<mdke> but there is no real good information about ubuntu-server even on the wiki, except for the ServerFaq page...
<mdke> tricky
<sladen> it's just a way to get your apt-cache pre-populated with most of the common LAMP programs you'd wan
<mdke> well kubuntu is also like that
<mdke> ditto the localised isos
<Riddell> there's a different server linux build I believe
<Kamion> Mithrandir: theoretically but only if folks have time to test it etc.
<Kamion> sladen: that's not true
<Kamion> sladen: I've certainly promoted stuff just for -server
<sladen> Kamion: ooh, okay.  This would be useful to know;  do you remember anything in particular---I can add it to the wiki if you do
<Kamion> ipvsadm and keepalived recently
<Kamion> let's see if I can get a bigger list from germinate
<mdke> how about this: http://www.ubuntu.com/download/derivatives
<mdke> perhaps it is a little early for xubuntu to be in "supported"
<Kamion> ltsp-utils and the -server kernels are the other things that are germinated only by ubuntu-server seeds
<Kamion> xubuntu will receive security support but not technical support (the latter at least not by Canonical, although if somebody else steps up to guarantee an SLA then that would obviously be great)
<Kamion> we're still thrashing out the details, hence the delay in promotion
<mdke> i'll put it in "other" for now, maybe
<Kamion> Gnoppix too
<mdke> ok
<jordi> seb128: ping
<seb128> hi
<seb128> jordi: not pong
<seb128> infinity, Mithrandir: are upload still frozen?
<jordi> seb128: so I downloaded ubuntu panel source, applied patches, no trace of "About Ubuntu" in the pot
<Kamion> seb128: nope
<seb128> jordi: it's in debian directory and I need to patch the po/POTFILES.in, I'll do with next upload
<Kamion> seb128: Flight CD 5 is just pending mirroring before an announcement now
<jordi> seb128: oh man
<seb128> Kamion: thank you
* ..[topic/#ubuntu-devel:Kamion] : 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 | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity | UI sprint in #dapper-look
<seb128> Kamion: and thank you for the stable uploads accepted ;)
<seb128> Kamion: is flight-5 available? or it has been delayed?
<Kamion> 11:04 < Kamion> seb128: Flight CD 5 is just pending mirroring before an announcement now
<jordi> seb128: can you do me a big favour?
<Kamion> no problem, still a few to go but the queue is much better than it was
<seb128> ups, sorry was typing and skipped that one
<seb128> jordi: maybe, ask :)
<jordi> --- ubuntu-about.desktop.orig   2006-03-11 12:05:13.631395978 +0100
<jordi> +++ ubuntu-about.desktop        2006-03-11 12:05:20.326522715 +0100
<jordi> -Name[ca] =Quant a Ubuntutu
<jordi> +Name[ca] =Quant a Ubuntu
<jordi> *that* was embarrasing
<jordi> And it's been there for 2 releases.
<seb128> lol
<jordi> heh
<seb128> I'll fix it monday with 2.14 upload, promize :)
<jordi> 0K D00D!
<seb128> promise rather :p
<seb128> anyway, I don't intend to spend my saturday on IRC, just wanted to know if I can upload the ubuntulooks and gtk upload I had pending yesterday
<seb128> see you
<jordi> seb128: don't forget!
<jordi> Or I will kill!
<jordi> seb128: are you in London still?
<jordi> any chance we'll meet?
<seb128> jordi: no, I'm back home
<jordi> seb128: you suck dude
* seb128 slaps jordi
<jordi> k
<seb128> thank you :p
<seb128> we will probably meet at GUADEC
<seb128> you are going to GUADEC, right?
<jordi> seb128: don't forget or you'll break my heart!
<jordi> yah
<seb128> don't worry, I'll fix that :)
<jordi> seb128: you totally missed out FOSDEM man
<seb128> see you!
<jordi> bye
<seb128> yeah I know, next time
<seb128> see you :)
<sladen> so... did seb128 do the upload?
<jordi> oi sladen 
<jpatrick> on monday he said
<jordi> sladen: are you in FI, or IUK?
<sladen> jpatrick: oh bah, that means another 2days of eye-sore
<sladen> jordi: I'm actually in the UK, but the wrong end of it.  Maybe I'll pop back to London at some point
<jordi> heh
<sladen> Kamion: ta
<jc-denton> hi all
<jc-denton> i'm not sure if this question is realted to this channel but i ask
<jc-denton> why is https://lists.ubuntu.com/archives/ubuntu-art/2006-March/000734.html on ubuntu-art
<jc-denton> rather then ubuntu-devel ?
<spacey> jc-denton: i got that mail as well, it has been sent to several lists
<spacey> jc-denton: ubuntu-devel-announce
<jc-denton> ok
<jc-denton> there has been a discussion about wpa_supplicant in main
<jc-denton> they said it's not possible to include it because it's too much work
<Treenaks> Which, in combination with network-manager 0.6 would rock, but that's too much work
<Treenaks> yes
<jc-denton> with a delay of 6 weeks would this bee possible?
<Treenaks> we'd need 1 or 2 new packages, and we'd need to sanitize the wpasupplicant packaging
<Treenaks> AND we'd need to test a lot
<Treenaks> maybe, but not likely
<Pygi> well, you can start packagin'/testing it for dapper+1 after all
<Treenaks> oh sure
<Pygi> that way we have a lot more time to test
<jc-denton> my school's wlan requires wpa_supplicant
<Treenaks> jc-denton: yes, but you can still run it
<jc-denton> and if dapper will be used in commercial environments it would be good for it
<jc-denton> yes
<Treenaks> jc-denton: you just won't be able to get it from _main_ and use network-manager to manage it
<Treenaks> that's all
<jc-denton> but try to explain how to an average user
<jc-denton> :D
<Treenaks> it still works
<Treenaks> jc-denton: easier than explaining why it's broken for his chipset with all kinds of new untested packages
* Pygi - lunch
<jc-denton> yes but the trouble with drivers on linux is not ubuntu's problem
<spacey> jc-denton: i would say bring it up for discussion in that upcoming townhall meeting
<jc-denton> i think
<jc-denton> i cannot go to these meetings
<spacey> wpa is quite essential these days
<jc-denton> but shall i ask again on #ubuntu-devel?
<spacey> jc-denton: you already did :P better put it to discussion on a mailinglist
<spacey> wider audience that way
<spacey> easy to miss something on irc:)
<jc-denton> lol
<jc-denton> err i mean on the ubuntu-devel mailing list?
<spacey> why not, although i'm not a dev:P
<jc-denton> me neither
<spacey> well can't hurt right ;P
<spacey> if you don't take a shot you always miss :P
<Kamion> http://www.xanna.org/images/silly/zoobuntu.png
<Kamion> (taken in our living room)
<Lathiat> are the daily images not being generated?
<Lathiat> (kubuntun notably)
<Kamion> http://xanna.livejournal.com/51821.html in fact
<Kamion> Lathiat: no
<Kamion> Lathiat: we always turn them off when preparing Flight releases
<elkbuntu> ok, if that is not the cover of the cd cases for dapper, i'm switching back to windows :P
<Lathiat> hrm i was hopign to get an install cd with that cupsys bug fixed
<Lathiat> since kubuntu flight5 isnt being done for a week
<Lathiat> can you do a kubuntu run?
<elkbuntu> thats just so cute, Kamion
<_lemsx1_> Kamion: nice image. very good for "ubuntu kids"
<elkbuntu> or "ubuntu inner-kids" ;)
<Mithrandir> Kamion: I suspect we can turn on dailies again now?
<Mithrandir> Lathiat: I can build you one, sure
<Surak> Hello, does someone have a screenshot of dapper's new orange color scheme? I didn't find in archives now
<Lathiat> Mithrandir: cheers
<Kamion> Mithrandir: sure, done
<raphink-pbook> wow the openoffice deps are all broken!!!
<raphink-pbook> taht's a mess
<Kamion> huh? installs fine for me
<Kamion> which exact package are you talking about?
<raphink-pbook> well look
<raphink-pbook>  $ sudo dpkg -r language-support-en
<raphink-pbook> dpkg: dependency problems prevent removal of language-support-en:
<raphink-pbook>  openoffice.org-l10n-en-gb depends on openoffice.org-core (>> 2.0.2) | language-support-en; however:
<raphink-pbook>   Package openoffice.org-core is not installed.
<raphink-pbook> and more
<raphink-pbook> but then
<raphink-pbook> $ sudo dpkg -r openoffice.org-l10n-en-gb
<raphink-pbook> dpkg: dependency problems prevent removal of openoffice.org-l10n-en-gb:
<raphink-pbook>  language-support-en depends on openoffice.org-l10n-en-gb.
<Pygi> you needed to do sudo apt-get dist-upgrade
<raphink-pbook> this looks like a loop dependency
<Pygi> raphink: look up :)
<Kamion> oh, new openoffice.org-l10n needs new openoffice.org I guess
<raphink-pbook> Pygi: doesn't do anything
<raphink-pbook> and I can't install kubuntu-desktop
<Kamion> shrug, should be fixed soon, doko uploaded openoffice.org not long ago
<raphink-pbook> cause it has lots of conflicts around
<raphink-pbook> ok
<Kamion> leave it alone and go do something else on Saturday :-)
<raphink-pbook> hehe
<Pygi> Kamion: hehe ;)
<raphink-pbook> well I need some tools that didn't get upgraded in kubuntu-desktop
<raphink-pbook> so I'll have to install them as standalone
<jpatrick> raphink-pbook: Riddell has to updat k-d-s I think
<raphink-pbook> since kubuntu-desktop is not installable
<Kamion> so do so for now
<raphink-pbook> jpatrick: w/ openoffice?
<jpatrick> yes
<raphink-pbook> well at least if it's a known issue that's good
<Kamion> doko: all I can say is I'm glad I didn't accept openoffice.org-l10n past NEW while Flight 5 was still in preparation :-P
<jpatrick> raphink-pbook: I did poke him a few days a go on it....
<raphink-pbook> Kamion: hehe :)
<raphink-pbook> jpatrick: ok
<doko> Kamion: yes, but we talk on #irc about it
<Kamion> I've just looked over our discussion and it wasn't at all clear that I should avoid processing those packages
<Kamion> I only avoided doing so out of paranoia
<Kamion> oh well
<doko> anyway, then the current build should finish quickly ...
<Seveas> who broke the openoffice help again? 
<Seveas> ah, I see it already 
<Pygi> nobody broke it ;) just the new OO is there with some unresolved deps (conflicts) I suppose ;)
<Seveas> yeah
<Seveas> it's not as bad as what some users do
<Pygi> hehe ;)
<Seveas> $someone just installed libstdc++ from debian
<Seveas> and then apt-get -f install
<Seveas> half the system was removed
<Pygi> buh, no good :-S
<Seveas> And still people think I'm overreacting when I say mixing debian and ubuntu repos is a recipe for disaster 
<elkbuntu> i dont :)
<Pygi> Seveas: bah, same thing with RPM's....people use RPM from different distros, and when they experience dependency hells, then they argue ;)
<Seveas> that even happens with rpms from the same distro
<Seveas> rpm is just [non-COC-compliant-comment-censored] 
<Aegir`> I've had that when they've installed large pieces of software, like OpenOffice.org2 via Alien, and come complaining to me that their system is half trashed.
<Pygi> Seveas: btw. if I am not mistaken we have libstdc++ in our repos as well? well, ok, RPM was a bad example ;)
<Aegir`> Somtimes I wish I never brought my Ubuntu laden laptop to school...
<Seveas> hehe
<Seveas> well, oo.O-help in dapper is quite busted now too
<Seveas> waiting for other builds to finish
<Aegir`> This was in Breezy ;)
<Pygi> Seveas: the greatest bug for now in dapper is the gtk theme ;)
<elkbuntu> Seveas, the situation would be alot easier if people didnt keep 'suggesting' dist-upgrade to anyone who wants to know why package x doesnt work
<elkbuntu> and i'm not talking within #ubuntu+1 either
<Aegir`> After he got yelled at by two or three different people, he removed the alien converted packages, and surprise surprise, everything worked again. Now we just have to convince him to ditch his dodgy 802.11b card that causes his entire notebook to freeze (Using ndiswrapper), then he'll be just about sorted...
<Seveas> Pygi, not a bug - design issue
<elkbuntu> the colors scare me
<Pygi> Seveas: yes, I know ;) just using bug as a phrase ;)
<Seveas> Pygi, no single theme will please everyone - I hope the discussions will move to sounder
<Pygi> Seveas: yup, true, but still...ah, well, you can suggest that..and see if people will listen ;)
<Seveas> they won't
<Pygi> Seveas: bah, ok, lemme try then ^^
<Seveas> I've been on a crusade lately in -dapper to send people to the right places, helps marginally
<Seveas> -devel*
<Pygi> yup, I'll try to tell them now
<Pygi> yes, yes, I saw that you are on crusade ;)
<Pygi> Seveas: there...perphaps it will help ;)
<iceman> ok, installed ubuntu live dapper, tried to reboot, and at grub i get a error 14 ? help 
<coyctecm> so dapper will be late?
<iceman>  ok, installed ubuntu live dapper, tried to reboot, and at grub i get a error 14 ? help 
<Pygi> iceman, not twice ;)
<iceman> np 
<iceman> i will try a reinstall .... 
<iceman> well whats error 14 mean ? 
<Pygi>  Filesystem compatibility error
<iceman> Pygi just upgraded from breezy to dappey wonder why thet would happen ? 
<Pygi> Some of the filesystem reading code in GRUB has limits on the length of the files it can read. This error is returned when the user runs into such a limit. 
<Pygi> what DS are you using?
<Pygi> FS*
<iceman> sounds like the formating of the harddrive, might need to wipe it completly before installing dapper
<Pygi> hm, perhaps
<iceman> fs will be base for live cd, ext2 or ext3 ... 
<iceman> Linux gets funny on the quick format it does .... had that as issues in moving from distro to distro before ... 
<Pygi> ;)
<iceman> well i'll try 1 more reboot, then toast the drive ... full install ... first i'll full format ... 
<coyctecm> https://lists.ubuntu.com/archives/ubuntu-art/2006-March/000734.html
<coyctecm> that really sounds good :)
<JustinLynn> coyctecm> thanks for the heads up regarding the proposal. I for one am in agreement with our SABDFL.
<coyctecm> ok
<JustinLynn> coyctecm> will this affect the release schedule of dapper+1 ?
<coyctecm> I don't know, im not right person to ask that, sorry
<elkbuntu> i heard someone adamently claim earlier that it would not
<Pygi> anyone except Matt that can actually change this page? http://www.ubuntu.com/testing/flight5
<Pygi> elkbuntu: yup, it shouldn't move the dapper+1 deadline
<elkbuntu> i would even have the specific convo in logs, if youse want more beef of the convo
<Amaranth> so if dapper gets pushed back 6 weeks dapper+1 only has 4 1/2 months
<Pygi> yes, but most likely dapper+1 won't be supported for that much years...not sure tho
<Amaranth> take a month off of that for bugfixing and you've got 3 1/2 months to add new stuff
<Pygi> amaranth: and what do you want? to release it "AS IS" and get a bunch of trolling about why the system, deps, or anything else doesn't work? :P
<Pygi> we have enough beavers already as it is
<Amaranth> Pygi: no, i'm saying push dapper+1 back too
<Pygi> Amaranth: maybe...but that would cause a glimpse in dapper release cycles
<Pygi> you'll see how many beavers we will have around when they hear about this
<elkbuntu> they'd be better off limiting the amount of change in dapper+
<elkbuntu> making it a small advance
<Amaranth> elkbuntu: dapper was supposed to be that
<Amaranth> elkbuntu: dapper+1 is supposed to be the one where we get to do crazy things again :P
<Pygi> amaranth: I disagree...dapper is supposed to be most supported and stable with as much extra features as possible
<elkbuntu> Amaranth, and so they should learn from their mistakes. it's all fine being ambitious, but ambitions take time
<Pygi> amaranth: we cant build dapper+1 on top of dapper, if dapper is not good enough
<elkbuntu> Pygi, if they had have stuck with the smaller changes and done them well, then the base would have been good enough
<Pygi> well, we have done that with server release....but desktop needed a bit of changes, well just to be...a lil' different ;)
<elkbuntu> Pygi, orange is certainly... different
<Lathiat> mjg59: ping
<Pygi> elkbuntu: bah, if you saw my post on -devel list, then you know what I think about it ;)
<elkbuntu> Pygi, i'm not a fan of lists. the only one i'm on is accessibility
<Pygi> hm, sec then pls
<elkbuntu> pygi and only cos i made them an info bot
<elkbuntu> Pygi, i wouldnt have bothered with the list if not for that fact
<Pygi> hehe ;)
<coyctecm> orange is better than brown. 
<elkbuntu> Pygi, well, from the average user point of view, the aesthetics are going to be the noticable changes
<Pygi> yup, but not everybody like the same looks
<elkbuntu> coyctecm, orange yes, better... but sunglasses should be optional, not necissary ;)
<coyctecm> elkbuntu: :D 
<elkbuntu> the bright orange square on the desk grid is irking me
<elkbuntu> meanwhile, it's 3am i should head to bed
<Pygi> elkbuntu: k, good night....
<JustinLynn> elkbuntu> our future's so bright, we have to wear shades... :)
<coyctecm> actually almost everybody change defaults 
<elkbuntu|snoring> JustinLynn, i still stand by 'optional, not necissarily
<elkbuntu|snoring> coyctecm, i'm opposite to everybody. only thing i change is the wallpaper
<JustinLynn> elkbuntu> i agree... just couldn't resist :)
<coyctecm> and what ever color is chosen there is always people who doesn't like it :)
<elkbuntu|snoring> coyctecm, retina health, dear, retina health
<coyctecm> elkbuntu|snoring: :)
<Pygi> there is a modified version of that theme, not to look so bright...but anyway, this is not good channel for this...
<Pygi> perhaps go to #ubuntu-art or #ubuntu-offtopic ?
<tseng> #dapper-look
<elkbuntu|snoring> Pygi, the modified i have now, but there's still the occasional BRIGHT
<Pygi> thanks tseng ;)
<elkbuntu|snoring> i trust that i am not the only one dissatisfied, and my typing is bearing the brunt of time, so i really am off now
<ogra_> jdub, around ? 
<KaiL_> why is default fr .deb files in dapper to open them with archive manager and not with .deb-Installer?
<Pygi> KaiL: because maybe someone doesn't want to install that package? :-/
<Iceman> well live cd installer sucks still ... 
<Iceman> for dapper
<Pygi> Iceman: what happened*
<Pygi> ?
<Iceman> grub gives a error 15 after reboot
<Iceman> Sucks having to reinstall.... now on Winblows .... ubuntu dead ... i'll get the install cd and re-install 
<Pygi> heh, I didn't got that
<Iceman> Live cd installed and ran great, but the installer sucked ... Grub gives a error 15 .. file not found error after reboot 
<Pygi> But I'll testing the 10.3. daily build today/tommorow
<Pygi> so I'll see what happens
<Iceman> no biggie, my bag for trying the live cd, but posting the info, and sharing the issues, helps it improve .. 
<Pygi> yup, thanks for that ^^
<Pygi> did the install cd (10.3 build) worked for you well?
<Iceman> i'll burn the iso for the install cd, and get myself out of Virus vurnalable winblows ... 
<Iceman> lol :) 
<Pygi> do you have install cd 10.3. cd iso? 
<Pygi> what's now funny?
<Iceman> downloading the daily iso from http://cdimage.ubuntu.com/daily/current/
<Iceman> 10-Mar-2006 08:58  668M  Install CD for PC (Intel x86)
<Pygi> k, good ;)
<Iceman> take it thats the 10/3 iso 
<Iceman> march 10th iso ... 10 / 3 .. now i follow it 
<Pygi> please do tell me how it works, ok?
<Iceman> no problem about 4 hours tell i get the full iso downloaded ... lol 
<Pygi> k, read pm
<Iceman> Wish someone woud fix the ubuntu video installer ... 
<Iceman> Installing ubuntu ... any version on a Dell System, always have to install using the bios set to the Dell onboard, then reconfigure the drivers and the bios to use a nvidia card... dell does not allow full disable of the video in the bios 
<mjg59> Lathiat: Hi
<mjg59> Lathiat: Ok, I finally have time to test it today. Just going to grab an appropriate machine.
<wasabi> Hmm. My Ubuntu install is missing a mounted usbfs by default.
<wasabi> That normal?
<Lathiat> mjg59: haha
<Lathiat> mjg59: howd you guess? ;p
<mjg59> I'm a smart guy
<Lathiat> evidently :)
<Lathiat> got the email?
<wasabi> Yeah, new dapper is missing it.
<wasabi> SUp with that?
<mjg59> (I've also just been handed an Intel Mac Mini. My life is getting increasingly odd)
<Lathiat> mjg59: hehe
<Iceman> wow 3 hours 19 min to get the iso for dapper install cd ... 
<ajmitch> morning
<Lathiat> mjg59: basically want to knwo if those settings are over sensitive on synaptics, if they are we need to hack somethign in, fi not we can just change the defaults
<mjg59> Lathiat: Sure
<Lathiat> dont suppose this has been fixed upstream?
* Lathiat wonders where to look
<Iceman> can you install daily updates for dapper 
<Lathiat> mjg59: hrm, i just tried 0.14.4 and it works fine
<Lathiat> mjg59: i notice an off-by-one bugfix in the changelog
<Lathiat> might be it
<Lathiat> ahve to look closer i guess
<Lathiat> we have 0.14.3
<Lathiat> hrm that fix was in .3
<mjg59> Lathiat: Ok, that's unusably fast
<Lathiat> mjg59: interestingly i just compiled upstreams 0.14.3 which works fine
<Lathiat> (same versons as ours)
<mjg59> Lathiat: Hrm.
<Lathiat> just diffing
<mjg59> Lathiat: Ok, in that case you get to play check the diff :)
<Lathiat> ..
<Lathiat> no differences
<mjg59> Hm
<Lathiat> ther eis some makefile changes
<mjg59> Wonder if it's some change in a header...
<mjg59> What happens if you rebuild the debian package?
<Lathiat> just changing paths and stuff
<Lathiat> mjg59: that didnt help last time
<mjg59> (And you've undone your xorg.conf changes for testing, right?)
<Lathiat> but i was just tryign that again
<Lathiat> mjg59: yeh
<mjg59> Presumably we just need different defaults for alps and synaptics?
<Lathiat> including re-checking its broken on the package
<mjg59> If all else fails we can bodge it
<Lathiat> mjg59: odd thign is it works in new upstream..
<Lathiat> but yeh
<Lathiat> we can
<Lathiat> rebuild doesnt help
<mjg59> Lathiat: So upstream works, but ours doesn't?
<Lathiat> right
<Lathiat> and no .c or .h differences 
<mjg59> Can you copy the debian directory into the upstream source and build it?
<Lathiat> some changes to the build stuff tho
<mjg59> Then see what happens
<Lathiat> well
<Lathiat> dunno
<Lathiat> theres some file and path changes in the diff
<Lathiat> can only try i guess
<Lathiat> right
<Lathiat> that works
<mjg59> Ha
<Lathiat> hrm that was on 0.14.4 tho
<mjg59> Hm
<Lathiat> let me try .3 hangon
<mjg59> Thanks
<Lathiat> (.3 works manually compiled)
<Lathiat> let me try debianize it
<Lathiat> must be the build system changes
<Lathiat> somehow messing it up
<mjg59> Yeah
<mjg59> Weird
<_lemsx1_> can somebody tell me why gnome-terminal seems to go back to the first 22 or so characters for every character i type (on dapper)
<_lemsx1_> using the same .bashrc, .bash_profile on a remote computer (in the same gnome-terminal screen) shows the cursor just fine
<_lemsx1_> oh, and xterm works fine locally or remotely
<Lathiat> mjg59: found the offending change
<Lathiat> mjg59: no idea hwo it causes that
<Lathiat> but the change from LD to CC
<Lathiat> and -sahred -module
<Lathiat> and to a .so file
<Lathiat> makes it slow
<mjg59> Lathiat: Now that's utterly fucked
<Lathiat> mjg59: oh yeh :)
<mjg59> Christ. Uhm, can you ask daniels about that?
<mjg59> He knows a lot more about the X module loader than I do
<Lathiat> i'll drop him an email
<Lathiat> mjg59: notably
<Lathiat> if i leave it as a .o
<Lathiat> and with LD
<Lathiat> and -r
<Lathiat> it run fine
<Lathiat> any idea why that change would have been made?
<mjg59> I think we standardised on .sos
* Lathiat tries -O0
<Lathiat> hrm no diff
<Seveas> Who's the new Ubuntu X guru now daniels is gone?
<mjg59> Seveas: A good question
<Seveas> hmm, I didn't expect that answer 
<simira> has he quit X totally now?
<Seveas> too bad 
<simira> probably seb, if my guess is right?
<mjg59> simira: He's pretty busy in Helsinki right now
<Seveas> he flooded malone yesterday getting rid of all bugs assigned to him 
<simira> mjg59: I'd guess. 
<Lathiat> hrm
<Lathiat> is it worth emailign him about it then?
<Lathiat> mjg59: whats he doign in helsinki?
<mjg59> Lathiat: Working for Nokia
<mjg59> But yeah, it's worth emailing him to see if he has any ideas
<Lathiat> time for bed
<mjg59> Lathiat: Ah. When you build the .o, is it actually /loading/ the synaptics driver?
<mjg59> Or just falling back to ps2?
<Lathiat> mjg59: i was just wondering that
<Lathiat> mjg59: and daniels just relpied witht he same thing ;p
<Lathiat> mjg59: heh indeed it doesnt.. ;p
<mjg59> Lathiat: Right, that would explain things
<Lathiat> back to square 1
<mjg59> So we probably need to change the code to have different defaults depending on the pad type. Sigh.
<Lathiat> yeh
<Lathiat> woot
<Lathiat> hrm actually
<Lathiat> mm, yeh it will load a .so
<Lathiat> err, .o
<Lathiat> but not from /usr/X11R6/lib/modules/input which is where it puts it by default
<Lathiat> if it loads it from /usr/lbi/xorg/modules/input then its slow again
<mjg59> Right
* Lathiat ponders
<zyga> hello
<soumyadip> hi I installed mozilla-imagezoom, and the problem is that neither did it install properly, nor is it being removed, due to some bug in the postinst script
<soumyadip> as a result of which my dpkg is borked
<soumyadip> what can I do to force the removal ?
<soumyadip> I tried dpkg -r --force-all mozilla-imagezoom to no avail
<zyga> soumyadip: --force--help, or just remove the postrm script
<zyga> soumyadip: but this kind of question usualy goes to #ubuntu
<soumyadip> zyga: didn't quite understand the "remove the postrm script" part
<soumyadip> zyga: ya well, I asked  there too, no responses, people seem to busy with Xgl
<zyga> soumyadip: remove the post-remove script that fails, it's in /var/dpkg/ somewhere
<zyga> or just fix it if the change is trivial
<soumyadip> ah ok, zyga thanks for the tip
<zyga> good luck
<soumyadip> I'll look around the script, if I can manage to make any headway I'll probably file a bug with a patch
<zyga> soumyadip: that's the spirit :-)
<zyga> soumyadip: /var/lib/dpkg/info
<zyga> look for package-name.postrm or .prerm
<soumyadip> zyga: uh this looks really bad
<soumyadip> zyga: soumyadip@collabgate:~$ ls /var/lib/mozilla-thunderbird/extensions -l
<soumyadip> total 0
<soumyadip> lrwxrwxrwx 1 root root 64 2006-03-12 04:37 installed-extensions.txt -> /var/lib/mozilla-thunderbird/extensions/installed-extensions.txt
<soumyadip> it seems that the symbolic link is pointing to itself
<zyga> I don't really know how extensions are packaged but that's not really good to point to yourself in a filesystem
<soumyadip> yup, and that is the reason dpkg is borking
<soumyadip> let me see who's maintaining thunderbird
<soumyadip> how do I find out which package installed a particular file ?
<zyga> dpkg-query -S /path/to/file
<soumyadip> thanks a ton zyga
<zyga> cheers
<soumyadip> gaah !! dpkg: /var/lib/mozilla-thunderbird/extensions/installed-extensions.txt not found
<soumyadip> where did that symlink come from ???
<zyga> a script has created it probably
<zyga> too bad that's not covered by dpkg's tracking mechanism
<soumyadip> anyway, I got my dpkg back in shape
<soumyadip> now to go looking for the bug
<soumyadip> ok I filed a bug in Malone
<soumyadip> #34490
<soumyadip> can anyone tell me how to choose which locales to generate ? dpkg-reconfigure locales doesn't seem to do the trick
<soumyadip> I mean I can always hand call locale-gen, but that isn't very elegant
<soumyadip> brb
* Pygi argues why do we force gcc 4 :-/
<ompaul> Pygi, one guesses longevtiy
<Pygi> ompaul: ah
<Pygi> ompaul: 3.3. or 3.4 is much better option :-/
<ompaul> for 5 years?
<Seveas> 4.0 is good
<Seveas> it's much stricter
<Seveas> stricter is better
<lamont> pdftoepdf.cc:35:32: error: poppler/UGooString.h: No such file or directory
* lamont kicks tetex-bin
<doko> infinity, Kinnison, lamont: please requeue openoffice.org on i386, sparc, powerpc
<mgalvin> Mithrandir: ping?
<Mithrandir> mgalvin: pong
<mgalvin> Mithrandir: not sure if you know but digg.com jumped the gun a bit... it was suggested that i make a note on the flight5 review stating that it has not been released yet... any opinon?
<Mithrandir> mgalvin: let's rather just release it. :-)
<mgalvin> or do we know when it will be release
<mgalvin> ok :)
<Pygi> Mithrandir: there are a lot of issues around that...
<Mithrandir> Pygi: around what?
<desrt> does anyone get a problem with the wobbly compiz plugin where once they stop moving a window it won't retain its original shape until you move the mouse around a bit more?
<Mithrandir> well, I've just been busy this afternoon and waiting for the image to sync, so.
<mgalvin> i want to update the screenshots but its not to big a deal
<Pygi> Mithrandir: well, that page stating that Flight5 is out ;)
<desrt> ie: it freezes in its deformed shape until you give some more input events
<desrt> i thought it was just me but a friend has it too now (different video cards, even)
<Pygi> Mithrandir: ok, so what will we do? just release flight5?
<Mithrandir> Pygi: it's released, just not announced.
<Pygi> Mithrandir: ah, ok :-/
* ..[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 | Flight 5 released | If your initramfs is broken in any way, please save a copy for infinity | UI sprint in #dapper-look
<mgalvin> Mithranddir: did the new ubuntulooks (with the more brownish color (0.9.5-1)) make it on the flight 5 cd?
<tseng> mgalvin: no.
<mgalvin> tseng: ok thanks, i am not gonna worry about the screenshot then :)
<Mithrandir> mgalvin: live, yes, install, no.
<Mithrandir> iirc.
<tseng> Mithrandir: live looked very orange to me
<Mithrandir> tseng: seb did sneak in some theme fixes, not sure if they were de-oranged.
<tseng> yeah, he fixed some bugs
<tseng> like openoffice menus
<tseng> i still didnt see de-oranging go by
<Mithrandir> ok
<mgalvin> ok, i am d/l'ing the cd now, so if it did get in i could always just quickly retake and swap the screenshots
<mgalvin> no biggie
<tseng> he did upload, but 6:30am my time
<molinero> :D
<nictuku> I wonder how can I suppress apt_pkg (python) messages when instantiating a cache class. I tried redirect stdout and stderr, with no success
<Mithrandir> http://err.no/tmp/flight5.txt ; if people could read through it and point out any omissions, errors, etc, I'd appreciate it.
<Treenaks> \o/ less orange :P
<KaiL_> Pygi, (about .deb mime handling) well, that's nice - but the archive manager doesn't know anything to do with those files afaik
<Burgundavia> Mithrandir: the first paragraph is kind of weak. I would say "Flight 5, the latest alpha of Dapper Drake, is available. These releases are tested to be reasonably free of show stopper bugs, but are obiviously still alpha quality, so do not use these on your production systems. You can download the Flight 5 cd here:
<Mithrandir> Burgundavia: it's more or less a C&P from Colin's f4 announce, but sure, I'll fix that.
<Pygi> Kail_: agreed...but don't you think that one might click it by accident, and install it? :-/
<Pygi> and how would it do? invoke dpkg -i?
<KaiL_> gdebi? ;)
<KaiL_> which is btw. in the list of apps to handle this - but only on second place
<Burgundavia> Mithrandir: I think my rewording makes its clear what is actually available, while not losing the "this may break" caveat
<Mithrandir> Burgundavia: sure, fixed.
<Mithrandir> (in my local copy)
<Pygi> Kail_;hm, well... Don't you think it's easier to explain to Joe Average why it does this way, and doesn't install it automaticly?
<Pygi> and what would a user do when some disputes arise? :-/
<Pygi> we are talking about regular user
<Mithrandir> Burgundavia: flight5.txt updated too
<KaiL_> Pygi, if we have gdebi, we should use it
<Kamion> Mithrandir: (dodgy line-wrapping, if you care)
<Burgundavia> Mithrandir: cool, thanks
<KaiL_> and not start some tool, which doesn't know, what kind of file this is
* Burgundavia wonders why Autopackage uses a python-based wiki if they think python sucks
<KaiL_> oh, sorry, it can
<KaiL_> ... but doesn't give any usefull result
<Kamion> because not everyone works in a "foo sucks" / "foo rocks" bipolar world?
<KaiL_> uhm, shouldn't going to sleep lock the screen? :)
<KaiL_> as it did in breezy
<Mithrandir> Kamion: pasted again with line-wrapping turned off in the emacs I'm pasting into
<Burgundavia> Kamion: indeed
<Pygi> Kail: it's a matter of personal preference I would say
<KaiL_> Pygi, agreed - where's the pref? ;)
<KaiL_> for now, you can NOT lock and sleep with dapper...
<Pygi> Kail_: Ah :-P
<KaiL_> oh, btw. who wants a list of those "one line to fix and seperate bugreports are a waste of time and bugzilla space" bugreports? :_)
<KaiL_> but the biggest one has only 3 letters: WPA
<KaiL_> or is there something in the work for the last days? ;)
<Pygi> Kail: nop, not the WPA again
<Pygi> why are people so ignorant
<KaiL_> ignorant?
<KaiL_> did I miss something?
<Pygi> no, but they were told 10000 times that WPA supplicant can't get into dapper :-P
<KaiL_> this is - uhm - baaaad
<Treenaks> it can go into DAPPER
<Treenaks> just not into main
<Treenaks> and no new network-manager
<Pygi> yup, true ;)
<Treenaks> just the current way of configuring
<Pygi> but people want it in Main
<KaiL_> bad enough...:/
<KaiL_> Pygi, to be exact, they want it to be on the CD
<KaiL_> as it has some very special problem: you need Internet to get Internet 
<KaiL_> who has stolen gnomebakers icon?
<Pygi> buh? what are you talkin' about?
<KaiL_> gnomebaker, a CD burning tool. In breezy it had an icon
<KaiL_> ah, there's the problem
<jpatrick> KaiL_: working on it
<KaiL_> jpatrick, gnomebaker?
<KaiL_> it had afull icon path in breezy. That file is still there, but the.desktop changed
<jpatrick> KaiL_: made a mistake gotta go now
<KaiL_> ..that saves one bug from being reported :)
<jdub> ogra_: pong
<ogra_> jdub, i'd like to ship a verndor logo in edubuntu-artwork 
<ogra_> but i dont like to let the packages conflict ...
<ogra_> can you make it an alternative in ubuntu-artwork ? 
<elmo> [ia64 + powerpc buildds are going down for some maintenance] 
<Mithrandir> there, fixed NM to not crash on !utf8 essids, at least.
<YokoZar> Hey, has the disks manager applet improved at all in Dapper over Breezy?  I started writing an old spec on it a while back that never got finished
<YokoZar> It still needs review, and I'm not sure who to send it to at this point.  https://wiki.ubuntu.com/UsefulDisksManagerSpec
#ubuntu-devel 2006-03-17
<joelbryan> Is the parental control bounty still open?
* mkde congratulates Mithrandir and everyone on flight 5, nice work!
<ogra_> mkde ?
<ogra_> you are mixed up :P
<mkde> heh
<mkde> I can't access my home server so need to use this nick
<ogra_> or are you writing docs for kubuntu ? 
<ogra_> ah
<mkde> no, I haven't gone to the extreme of using kde yet
<ogra_> heh
<ogra_> i wonder how the ubuntu themed gnome apps look in the blue kubuntu now ...
<mkde> on drugs
<ogra_> i imagine it will bite mixing that bright orange with a bright blue 
<ogra_> heh, yes
<Mez> ogra_, they look really really weird
<ogra_> yes, thats what i'd expect
<Mez> ogra_, hehe :D
<Mez> though mine doesnt hae any orange
<Mez> hae *
<Mez> have *
<Mez> godamn v key
<Mez> though i'm just about to update ubuntulooks ;)
<Mez> so I'll tell you in a mo
<Mez> however - before I used to get blue stuff in kubuntu with brown stuff in gnome
<tsdgeos> hi, does ispellcat have a mantainer?
<tsdgeos> if not who do i have to bribe to /me beign the mantainer so i can fix the bugs there ?
<Mez> W: Unable to locate package ispellcat
<tsdgeos> aspell-ca
<ogra_> ogra@edubuntu:/mnt/devel/packages/edubuntu-artwork-0.1.0$ apt-cache madison ispellcat
<ogra_>  ispellcat |      0.4-6 | http://archive.ubuntu.com dapper/main Sources
<ogra_> its in main ...
<tsdgeos> yeah, but it is uber outdated
<Mez> ah - source package
<ogra_> were past all freezes .... will need an exception ...
<Mez> tsdgeos, it's synced from debian I believe
<tsdgeos> Mez: so i must bribe someone on debian?
<ogra_> tsdgeos, nope
* tsdgeos goes to look for isaac
<mkde> tsdgeos: new versions are unlikely. you can fix bugs though: file bugs and post patches
<Mez> tsdgeos, nope - if there are bugs-  then bribe the MOTU
<Mez> well
<ogra_> new versions will work as well if the changes are small
<Mez> an ubuntu de
<tsdgeos> MOTU ?
<Mez> but - new versions arent likely to hit till after dapper
<tsdgeos> well, the thing is that 0.4 is very old, there is 0.5 and 20040130 (that you can see is old)
<ogra_> tsdgeos, MOTU = masters of the universe, but that package is in main ... you need a main developer 
<tsdgeos> but that 20040130 fixes the problems i'm facing
<tsdgeos> i already filed a bug
<mkde> tsdgeos: Ubuntu is frozen for new versions, but if you have easy patches to fix bugs, you can attach them to bug reports
<Mez> tsdgeos, if the diff is small - it can be fixed
<tsdgeos> but of course i never expected noone to care for catalan
<Mez> if not - then well - it'll have to wai
<tsdgeos> ok
<Mez> tsdgeos, link to bug?
<tsdgeos> then i'll have to ditch ubuntu
<tsdgeos> bah
<tsdgeos> no distro fits me
<tsdgeos> :-(
<ogra_> tsdgeos, hey jordi works in the translation team of ubuntu :)
<tsdgeos> https://launchpad.net/distros/ubuntu/+source/ispellcat/+bug/32984
<Ubugtu> malone bug 32984 in ispellcat aspell-ca "Package is outdated" [Normal,Unconfirmed]  
<ogra_> indeed we care about catalan :)
<Mez> tsdgeos, we care about everyone
<tsdgeos> well, then why do you have a 2 versions old packge of the spellchecker? when newest version is already 2 years old?
<mkde> tsdgeos: you may also be able to install the new version manually
<tsdgeos> mkde: of course, i may intall everything from source, but then i'd not be running any distro but TSDgeos Linux
<mkde> tsdgeos: how about just installing this one thing
<mkde> but the reason it is old is likely because the debian package is out of date
<tsdgeos> mkde: how about fixing it so every catalan user out there (there are 6 millions of us) gets this fixed and not only me?
<tsdgeos> and well
<mkde> tsdgeos: it may be possible to get an exception for the freeze, but in general, freezes are there to protect you
<mkde> you just don't realise it
<tsdgeos> yeah of course
<jordi> tsdgeos: hey man, cam down a bit
<tsdgeos> he he
<tsdgeos> fucking me
<jordi> what do you mean "uberoutdated"?
<tsdgeos> i only entered here to tell i wanted to fix it
<jordi> sure, it's not the very last version from joan's site, but what are you missing specifically?
<tsdgeos> and here i am flaming everyong
<tsdgeos> sorry dudes
<tsdgeos> jordi: it does not gets apostrophed words right
<tsdgeos> l'home <- error
<jordi> tsdgeos: I am the maintainer of aspell-ca
<tsdgeos> l'estiu <- error
<jordi> and that's fixedf  in the newer version?
<tsdgeos> when using mandriva files all works perfect
<jordi> I'll have a look this week.
<tsdgeos> i guess because i would not hope mandriva specially patched their files to fix that
<tsdgeos> jordi: uber is german for very or so
<tsdgeos> KDE deformation of my wording
<jordi> t might well be that the Debian mods breaki that somehow.
<jordi> I know what uber is :)
<jordi> damn I hate this keyboard
<tsdgeos> well, then uberuoutdated means that, the package is 0.4 when there are 2 newer versions ;-)
<tsdgeos> jordi: that two squares i see are typos? 
<tsdgeos> or are sucky fonts on my side?
<jordi> it's funny thatthey hve 0.5
<ogra_> tsdgeos, i'd rather translate ber with extreme 
<jordi> because I invent the version numbers.
<ogra_> (as a german)
<tsdgeos> jordi: ????? ftp://ftp.gnu.org/gnu/aspell/dict/ca
<tsdgeos> 0.5 here
<tsdgeos> and 20040130 that's newer than 0.5
<tsdgeos> or you are not using that pacakges?
<tsdgeos> ogra_: ok, thanks for the clarification
<jordi> tsdgeos: nope
<jordi> tsdgeos: debian source uses softcatala's dictioanri
<jordi> www.jmoratinos.com
<tsdgeos> doh
<jordi> tsdgeos: I'll have a look, don't worry
<tsdgeos> well, why aren't you (softcatala) contributing back changes? seems your work is newer but has some problems like the l'home thing i said
<tsdgeos> jordi: thanks dude
<tsdgeos> the other day i was looking for you on irc but tough you used oskuro or somethign similar and failed
<jordi> I've been jordi for a long time now
<jordi> http://oskuro.net/blog/freesoftware/nickname-change-2004-09-15-00.58?showcomments=yes :)
<jordi> tsdgeos: not sure, I'll have to ask jmo
<tsdgeos> jordi: sure it was not because oskuro had a K in it ;-)
<tsdgeos> well i think it's nice to have a nick similar to your name, i always have the same problem of people not associating tsdgeos with the aacid kde svn account :D
<tsdgeos> anyway sleep time
<tsdgeos> jordi: thanks a lot for having a look, hope you can find the problem
<jordi> sure
<tsdgeos> if you need testers or so i'm usually on freenode so just ping me
<jordi> no, the k wasnt a problem ;)
<jordi> (not in this case ;)
<jordi> ok
<jdahlin> Was CONFIG_KPROBES turned on recently in ubuntu kernels?
<Mez> infinity, ping
<Burgundavia> jdahlin: you need to talk to BenC about that
<jdahlin> oh, there isa #ubuntu-kernel
<santiagoroza> there's this spec (or spec-wannabe) i'd like ubuntu developers to take a look at, i think it could be a nice step forward in usability ...
<santiagoroza> it's wiki.ubuntu.com/RestrictedFormatsAssistant
<jdahlin> Burgundavia: thanks
<Burgundavia> santiagoroza: that is at the earliest dapper+1 material
<Burgundavia> santiagoroza: you should also look at DesktopHooks
<santiagoroza> yeah i looked at that
<santiagoroza> but it's a different approach
<maxie> is it me, or is the kubuntu flight5 link broken>
<santiagoroza> i just wanted to know who should i talk to, in order to get the spec looked at
<santiagoroza> because it'd be nice to have easy mp3/dvd support, while staying legal of course
<mkde> santiagoroza: it is best to leave it until after dapper is released, and raise it at or before the developer conference
<santiagoroza> and the developer conference will be when?  i wouldn't know since i'm not a dev
<Burgundavia> santiagoroza: I think desktop install hooks is the proper way to go
<Burgundavia> santiagoroza: may, if dapper releases on time
<santiagoroza> Burgundavia: it might be the proper way to go, for not-so-common things
<santiagoroza> but it's completely wrong for common things like mp3 or dvd
<Burgundavia> umm, why?
<santiagoroza> because that way
<Burgundavia> this is what winodws media player does
<santiagoroza> no
<santiagoroza> windows media player ships with mp3 at least
<santiagoroza> and btw not everything they do is right  :)
<santiagoroza> i was saying
<santiagoroza> because that way
<Burgundavia> no, but they do have this right
<santiagoroza> users have to download stuff every time they open a simple movie or song
<Burgundavia> people want mp3 playback, not restricted formats
<santiagoroza> that's ok for uncommon codecs
<santiagoroza> not for stuff everyone will eventually need
<santiagoroza> people want mp3 playback... and dvds and quicktime
<Burgundavia> I disagree with the "everyone will need it"
<santiagoroza> well we ship a music player don't we?
<Burgundavia> regardless, this is not the place to talk about it
<Burgundavia> the topic is well understood
<santiagoroza> ok, what's the place then?
<Burgundavia> the spec and at the deveopment conference
<santiagoroza> ok, thanks then
<desrt> yay!  more time to convince seb about the logout dialog box
<mkde> desrt: don't jump the gun
<Mez> desrt always jumps the gun
<Mez> he thoguht i wasnt gonna let him back into the room ;) so he went and ate without me
<Mez> infinity, ping
<ajmitch> heh
<ajmitch> nothing like dining with the fine cuisine of mcdonalds though
<desrt> :)
<desrt> which one of you was it that got me lost?
<ajmitch> mez, of course
<desrt> "oh.. i know where the mcdonalds is..."
<Mez> desrt, I sorta did ;)
<Mez> I swear there was a closer one ;)
<Mez> lol
<Mez> me and riddell found it easily
<desrt> by statistics alone i believe you
<Mez> but i really cant work out how we couldnt find it again
<desrt> since the one we ended up at was impossibly far :)
<Mez> if only riddell was on hand... :D
<desrt> for a brit, your english is awful
<jdub> yeah, you speak like a canuck
<desrt> glare.
<mkde> is that a compliment?
<jdub> more a glass door for desrt to walk into
<Mez> desrt, how so?
<desrt> Mez; "me and riddle"
<Mez> ah - lol :D
<Mez> that's just me being lazy
<desrt> and also, you want "had only riddle been on hand..."
* Mez slaps desrt 
<desrt> or "if only riddel were on hand"
<Mez> I'm a lazy typer :D
<Mez> and meh - 
<Mez> *shrugs*
<desrt> or even "if only riddle had been on hand" if you really looking for lots of typing :)
<ajmitch> desrt: pedant
<Mez> ajmitch, well said
<desrt> true story
<desrt> my friends call me grammar nazi
<mkde> you should get together with trappist 
<desrt> a reasonable subset of them even thank me
<mkde> he has that nickname too
<timetolag> must go NOW 2 alienware laptops price 550 altogether for both.  want them gone today message me on aim at ogd443 or msn at mcsltd1@hotmail.com or yahoo at thishastogotoday
<mkde> after a week with the docteam
<mkde> oh bog off timetolag 
<desrt> oh man
<desrt> lamer smalltime irc spam
* ajmitch looks for jdub 
<Mez> desrt:I'm usually a grammar nazi too - but - not all the time
<desrt> Mez; inappropriate use of what i can only assume are meant to be emdashes
* mode/#ubuntu-devel [+o jdub]  by ChanServ
<ajmitch> grammar nazi is not a part-time job
* timetolag was kicked off #ubuntu-devel by jdub (jdub)
<Mez> /kick desert nazi
<LaserJock> way to go jdub!
<desrt> Mez; in appropriate use of the letter 'e'
<ajmitch> why do I get all these bugs which I can't reproduce?
* mode/#ubuntu-devel [-o jdub]  by jdub
<LaserJock> ajmitch: has sabdfl blessed your computer or something? ;-)
<Mez> desrt: this is starting to sound like mau
<ajmitch> LaserJock: I wish..
<desrt> Mez; i was just thinking that :)
<Mez> ;)
* Mez misses mau
<desrt> i play it at school
<desrt> people love it or hate it
<ajmitch> LaserJock: it's just f-spot where I can't reproduce bugs, but I suspect upstream has fixed them in cvs
<ajmitch> Mez: mao, I presume?
<Mez> ajmitch, yeah - I always forget the spelling
<desrt> ajmitch; yes.  on his sandwiches
* desrt is growing bored, finds something better to do
<mkde> desrt: you can read the Ubuntu guides and do some grammar nazi-ing, if you like that sort of thing, then submit patches
<desrt> mkde; where are those?
<mkde> desrt: they're at http://doc.ubuntu.com or in Yelp on dapper. The source is at https://docteam.ubuntu.com/repos/trunk, all other info is at https://wiki.ubuntu.com/DocumentationTeam/GettingStarted or #ubuntu-doc
<mkde> :)
<desrt> wow.  nice sales pitch.  jdub is bound to kick you soon :)
<mkde> heh
<desrt> here's a neat question -- will it still be 6.04 if it is delayed?
<mkde> depends by how long, I suppose
<Burgundavia> 6 weeks is June 1st
<desrt> 6.06
* mkde volunteers Burgundavia to update the wiki accordingly
<desrt> mkde; do you guys have a style guide?
<mkde> desrt: yeah, doc.ubuntu.com for that too
<desrt> stuff like
<desrt> 1, 2, and 3.
<desrt> vs
<desrt> 1, 2 and 3.
<desrt> have some internal inconsistency
<mkde> yes, it's the former for the moment
<Mez> desrt: fancy writing documents for a KDE app?
<desrt> definitely not :)
<Mez> desrt: it's a cool app ;)
<mkde> desrt: http://doc.ubuntu.com/ubuntu/styleguide/en/ch04s02.html
<jdub> mkde: hey, that page was not generated with the chunk name
<desrt> mkde; IBMs?  what an awful example :)
<mkde> jdub: come again?
<mkde> desrt: we accept patches on the styleguide too :)
<desrt> mkde; for the only case i can imagine IBM's is, indeed, correct
<jdub> mkde: 'ch04s02.html' -> that's the autogenerated name, not the chunk name
<mkde> jdub: right, the norm walsh stylesheets do that by default, iirc
<jdub> you can tell them to use chunk names
<jdub> it's just a parameter
<mkde> sure
<jdub> 'course, then you need chunk names
<jdub> but those are just the ids
<jdub> makes it neater, and more likely to keep sane urls
<mkde> yes, that would be a good thing to get right
<mkde> i've heard complaints on #ubuntu about that
<mkde> alright then
<jdub> (that's one thing i find frustrating about this kind of generation - you have to be very anal retentive about chunk name changes to make sure urls stay the same, both by name and semantics)
<jdub> hmm, might be cool to add a test to check when chunk names are changed
<mkde> jdub: that sounds like a lot of work. I've fixed the filename thing though
<mkde> the id's in the styleguide are pretty dodgy though
<desrt> mkde; ... crikey!
* desrt is terrified
<jdub> mkde: should only be a bit of xpath hackery, following the logic of the stylesheets (which is fairly simple for chunking rules, i believe)
<wickers> I think I found a bug or two with the flight 5 liveCD
<wickers> The desktop is not writable. 
<Burgundavia> wickers: please file them. If you have a solution
<Burgundavia> wickers: this is the place to discuss your solution to a bug, not the bug itself
<wickers> Ahh.. ok.. chmod
<wickers> ;)
<wickers> just kiddin
<wickers> I'll check out where to file bug reports. 
<mkde> woof
<mkde> sorry desrt, missed everything you said (if anything) after "crickey", I pulled my network cable out of the wall
<desrt> mkde; a few more notes about the style guide
<desrt> mkde; in general, your use of commas is a bit weird
<mkde> yes, we've discussed this a bit on the ML recently
<desrt> mkde; also, quotations aren't covered completely
* desrt says "pwned."
<desrt> vs
* desrt says "pwned".
<desrt> the 2nd seems to be more popular in our setting
<mkde> you are just trappist in disguise, right?
<desrt> no.
<LaserJock> desrt: you need to read the ubuntu-doc ML. We discussed that too
<desrt> hah
<LaserJock> great word-nazises think alike?
<mkde> desrt: anyway, def. be glad to have you join in the discussion on that, or do any proofreading, or even contribute the odd section before string freeze
<desrt> mkde; i'm not really sure i can commit any real time to this, unfortunately
<mkde> desrt: np, whatever you want
<desrt> mkde; and it seems that my random observations are already known... so that's good :)
<mkde> :)
<elkbuntu> is this bad, and if so, known? http://pastebin.com/597336
<jdub> mkde: how much of the ubuntu styleguide points to or directly uses the gnome styleguide?
<mkde> jdub: I think the answer is "some but not all", but I am not 100% sure, if you send a mail to the list, the author will answer
<theCore> quick question, does the 6-weeks delay will affect the Freezes?
<minghua> elkbuntu: nothing to be worried about.  but see bug #6614 if you are interested to fix it :-)
<Ubugtu> malone bug 6614 in gs-common "Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 108" [Normal,Unconfirmed]  http://launchpad.net/bugs/6614
<elkbuntu> minghua, heh i wish i had a clue
<theCore> nevermind
<Lathiat> Kamion: hrm that kubutu daily doesnt seem to have gone through
<elkbuntu> just a question before i file a bug report: what are the privs for /home/username/.xauthority supposed to be?
<Lathiat> .Xauthority, u+rw,u-x,go-rwx
<Lathiat> owned by $user
<Mez> ls: /home/username/.xauthority: No such file or directory
<Lathiat> .<x>authority shouldnt exist
<Mez> ls: /home/mez/.xauthority: No such file or directory
<Lathiat> but i assume thats a typo
<Mez> -rw------- 1 mez mez 1162 2006-03-10 15:31 /home/mez/.Xauthority
<elkbuntu> well... it exists and is stopping the gksudo
<elkbuntu> ls -l /home/melissa/.Xauthority gives: -rw------- 1 root root 0 2006-03-02 18:32 /home/melissa/.Xauthority
<elkbuntu> so it's the same as for Mez
<Mez> elkbuntu, not exactly
<Mez> elkbuntu, try this: sudo chown melissa:melissa /home/melissa/.Xauthority
<Mez> that's your problem ;)
<elkbuntu> ah
<Mez> t's owned by the wrong user
<elkbuntu> i didnt do anything to change this however
<Mez> *shrugs*
<Mez> you rpobably tried sudo'ing and running X as root or something to get that to happen
<Mez> sudo chown melissa:melissa /home/melissa/.Xauthority
<Mez> will fix it though
<elkbuntu> aye, but so long as the updates fix it, since i'd place my life on a bet that the updates made it like that
<Mez> elkbuntu, er ...
<Mez> not likely
<Mez> but that comand'll fix it
<elkbuntu> i hadnt installed anything, just run updates this past week
* Mez shrugs
<Mez> it's probably just an accident somewhere ;)
<elkbuntu> yep
<Mez> the command fixes it
<elkbuntu> but so long as it's not a permanent accident i'm happy
<Mez> shouldn't be
<elkbuntu> good, because i ran updates immediately before coming in here
<desrt> oh.  i see.  orange.
<desrt> has ubuntu gone mental?
<desrt> erp.  wrong channel.
<fabbione> LOL
<fabbione> desrt: ehehe
<elkbuntu> that's been a common reaction...
<Aegir`> I like the orange. Better than brown.
<Aegir`> But mind you, I also quite liked the brown.
<Burgundavia> opinions were very mixed on that one
<Lathiat> 1 thing with the brown
<Lathiat> it was distinctive
<Lathiat> you see ubuntu, you know its ubuntu :)
<Lathiat> i havent seen the orange yet
<Lathiat> so i'm holding back my opinions :)
<Aegir`> I'm not sure wether theres really an issue either way. Theres always clearlooks, and whatnot, still availible.
<jdub> Aegir`: the issue is out-of-the-box love
<Aegir`> Well, I've got a lot of love for orange.
<jdub> (and hate, because it's not good enough just to be boring)
<elkbuntu> its not the colour orange i dislike, it's the intensity of it
<elkbuntu> the desktop grid on the panel is still annoying me :P
<fabbione> jdub: thanks for the posting on the fridge.. HeavYMetaL
<jdub> ROAR! :-)
<jdub> fabbione: which irc channel are you using for it? wasn't mentioned in your post
<fabbione> #ubuntu-ports
<minghua> elkbuntu: yeah, I agree the desktop icon sucks
<elkbuntu> minghua, i want the little application icons back on them too :(
<jsgotangco> roar?
<jsgotangco> jdub: fridge sucks so much on epiphany
<jdub> jsgotangco: ?!
<jsgotangco> jdub: the link tabs get relocated radomly
<jdub> jsgotangco: hrm, thought i fixed that sucker
<minghua> jdub: I have the same problem in firefox
<jdub> yeah, same issue everywhere
<jdub> i thought i'd fixed it
<desrt> if the ubuntu installer crashes inside of qemu..... whose fault is it....
<fabbione> hey pitti
<fabbione> desrt: it depends from the crash?
<pitti> Hi guys
<pitti> hey fabbione 
<desrt> "Downloading file 655 of 838 (0s remaining)"
<fabbione> pitti: how do I make sure a buffer is 64bit alligned?
<desrt> this is a neat thing to see from an ubuntu install on a box that's not connected to the net
<fabbione> desrt: network connection stalled?
<desrt> fabbione; no.  it's going pretty fast....
<pitti> fabbione: uh, no idea in C
<fabbione> pitti: ok
<desrt> fabbione; you can use the gcc allignment attribute
<fabbione> desrt: can you elaborate please?
<ajmitch> morning guys
<pitti> hey ajmitch 
* ajmitch seems to have a very broken box here now
<desrt> fabbione; __attribute__((aligned(8)))
<desrt> fabbione; ie: align to the nearest 8-byte boundry
<desrt> fabbione; gcc-only
<desrt> fabbione; don't expect that to work with automatic variables
<fabbione>         __attribute__((aligned(8))) unsigned char buf[BLOCK_SIZE] ;
<fabbione> this works
<fabbione> but i guess i need to make it conditional
<fabbione> I think only sparc and alpha requires 64bit allignment
<fabbione> and i can't care less about alpha
<elkbuntu> is there a reason netstat runs as a zombie process at boot?
<Burgundavia> jdub: you don;'t need to worry about the ubuntu-users mailing list. I can deal with it
<Burgundavia> jdub: (i assume it is you who is clearing out the spam queue)
<Pygi> elkbuntu: huh :-/
<jdub> Burgundavia: it's just part of my morning listadmin run
<Burgundavia> jdub: ok
<elkbuntu> i've JUST booted 7 mins ago cos i noticed netstat and firefox running as zombie processes.. so right after boot, i ps -el | grep 'Z' and get: 0 Z  1000  5197  5138  0  79   0 -     0 exit   ?        00:00:00 netstat <defunct>
<Pygi> no good :-/
<elkbuntu> i'll pastebin the output from before boot
<elkbuntu> with ff in there too
<Pygi> k, thanks
<elkbuntu> http://pastebin.com/597531
* Pygi goes looking...
<elkbuntu> however this time firefox isnt zombied, but it sorta tried crashing at a page i went to it might have been the cause of that, since ff is a little instable right now
<Pygi> what ff are you running? ff 1.5.1. or nigthly build?
<elkbuntu> whatever is in the repos
<Pygi> huh, that one has extreme problems with javascript code :-/
<elkbuntu> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060311 Ubuntu/dapper Firefox/1.5.0.1
<elkbuntu> i'm really wondering why the heck netstat would be running zombie anyway, it's like single threaded
<Pygi> hm...
<elkbuntu> pygi will you be around for a few hours yet? i'll be guineapig but i need to go afk a while
<Pygi> elkbuntu: probably...talk to you later then....
<elkbuntu> okies, thanks :)
* Lathiat wonders why synaptic has breezy badger sources
<Pygi> Lathiat: ? where? In dapper?
<robitaille> Lathiat:  I don't have any breezy in my repos
<Lathiat> Pygi: yeh, fresh flight5 install
<Lathiat> if i goto repoisotries
<Lathiat> and click add
<Lathiat> i can add breezy sources
<robitaille> oh...yes
<Pygi> Lathiat: yup, true...
<Pygi> perhaps someone want to use old libs/app until new ones are stable enough
<Lathiat> thats likely to cause total hell
<Pygi> I bealive it will be truncated once the final release is made
<Pygi> Lathiat: most probably, but that's why you won't use it ;)
<Burgundavia> ugg, the add dialog sucks
<Pygi> Lathiat: People who use it should know what can they get with that :P
<Lathiat> Burgundavia: yeh it shouldnt be an add dialog it should be some kind of matrix
<Pygi> Lathiat: And you would explain that how to regular user? :-/
<Burgundavia> no, there is no use case for not adding updates and security when you add a dialog
<Lathiat> Burgundavia: heh
<Lathiat> right
<Burgundavia> s/dialog/repo
<Burgundavia> however, you have to capture that complexity
<Burgundavia> maybe a |> expander?
<Lathiat> also, i hope theres an option to turn these low disk notifications off
<Lathiat> like a UI accessible option
<Lathiat> i know many people that fill disks up on purpose
<Pygi> Burgundavia: well, if you really wanted, you could always edit sources.list manually
<Lathiat> anyoen got an idea?
<Burgundavia> Pygi: indeed
<Pygi> Lathiat: yup, an option to turn it off might be a good idea, but filling disk up to the top is not a good idea at all
<Lathiat> Pygi: sure it is
<Lathiat> Pygi: i have a 200G drive full of .. files
<Lathiat> i dont care that its full
<Lathiat> its there to be used
<Lathiat> i mean having / not full is fine
<Lathiat> and i agree
<Lathiat> but other drives can be filled intentionally
<Lathiat> windows used to drive me nuts with that
<Pygi> hm, imagine a situation where you have /home1 with 1000 users on LDAP on a server
<Burgundavia> it needs two things: 1) smarter default as to what mount points to care about
<Lathiat> also, anyone knwo how i can make mounted drives show up in the places menu
<Burgundavia> 2) gui options to chat it
<Lathiat> 'user' used to do it
<Burgundavia> change it
<Pygi> and each user has a quote....we really do need that reminder in that case
<Lathiat> Pygi: sure
<Lathiat> Pygi: theres both uses cases
<Lathiat>  / or /home shoudl most certainly not be full
<Lathiat> but other drives can be
<Lathiat> so
<ajmitch> Pygi: sure, a reminder is useful, but having no options to change it is less than optimal
<Pygi> ajmitch: yup, scrool up...being able to turn it off is great
<Lathiat> any ide aon the disk thing?
<Pygi> I don't even know if that reminder would work with a quote on LDAP server /home dirs
<Lathiat> thats annoying a mate of mine as well, if the drives arent on his desktop he goes nuts :)
<Lathiat> Pygi: probably doesnt take quotas in to count
<Pygi> Lathiat: O, joy...
<Lathiat> Pygi: can fix that ;p
<Pygi> That's a issue for users then
<Pygi> Lathiat: if you can...fix it ;) it would be great ;)
<Lathiat> i'll pass? ;p
<Pygi> ok ;)
<Lathiat> i dont need it ;p
<Pygi> Latguat; bah, that's not a good opinion ;) If you don't need a C compiler, then we shouldn't fix C compiler? ;) (joke)
* Lathiat grins
<Pygi> Lathiat: hehe ;)
<glatzor> hi jsgotangco. good to see you! as suggested by mark there will be some interface changes in g-a-i.
<jsgotangco> gahhh
<jsgotangco> glatzor, do you have a list?
* jsgotangco just arrived from travel last night
<glatzor> jsgotangco: the "add channel/section" button will be removed. mainly we restored the old behavior.
<glatzor> so if you click on install and the section/channel is not in your sources.list a dialog pops up.
<glatzor> furthermore I would like to change the term "component" to "section". this is the one used by debian.
<glatzor> jsgotangco: I changed the wording of some dialogs a little bit to reflect the new workflow.
<Burgundavia> glatzor: component and section are differnt in debian
<glatzor> the channels get "enabled" and not "added"
<Burgundavia> glatzor: sections is what type of program, component is what license it has
<glatzor> Burgundavia: http://www.debian.org/doc/manuals/apt-howto/ch-basico.en.html
<Burgundavia> glatzor: you also the issue of this: http://www.ubuntu.com/ubuntu/components
<glatzor> Burgundavia: Ok. I will revert the change
<jsgotangco> ok i will check changes and amend as needed
<Burgundavia> glatzor: the more common usage of section in debian is the type of package
<glatzor> Burgundavia: the man page of sources.list also speaks of components. 
<Burgundavia> hmm
<glatzor> glatzor: it seems to be a bug in APT HOWTO.
<glatzor> Burgundavia: thanks that you were here and stopped me :)
<Burgundavia> glatzor: yes. In a package, section clearly is about what the package is, not where it is
<glatzor> jsgotangco: do know when the new theme will be stable to take the screenshots?
<jsgotangco> i will make new shots later
<jsgotangco> the theme is pretty stable already
<jsgotangco> i dunno about the icons
<Pygi> oh, new "rainbow" theme ... joy ;)
<Lathiat> i hope th etheme isnt stable
<Burgundavia> glatzor: I don't we have ever met before
<jsgotangco> Burgundavia, that's sebastien heinlen
<Pygi> Lathiat: lol ;)
<glatzor> jsgotangco: I don't know if mvo includes my polishing for the software-properties dialogs. if yes these dialogs need new screenshots. too. but I could take them myself.
<glatzor> jsgotangco: Burgundavia: yes the famouse one :)
<jsgotangco> lol
<jsgotangco> glatzor, i'm currently updating another box, i'll see more changes i guess
<joelbryan> why does the current gnome-vfs is striipped down? start-here:, all-applications: doesn't work anymore.
<Burgundavia> glatzor: where you at UBZ?
<glatzor> Burgundavia: I helped mvo on synaptic some years ago - mainly doing documentation, translations and UI stuff.
<Burgundavia> ah
<glatzor> Burgundavia: I stopped my open source engagement because of time reasons. This January I filled a bug against gnome-app-install not following the GNOME HIG.
<Burgundavia> ah
<Burgundavia> I quit a job because it contrained by OSS stuff too much
<glatzor> Since mvo was low on time, so I did a patch. :)
<glatzor> Burgundavia: this is my way to Ubuntu. :)
<jsgotangco> you quit userful?
<Burgundavia> jsgotangco: no, microserve
<jsgotangco> ahhh
<Burgundavia> back in Feb 2005
<_lemsx1_> anybody around?
<_lemsx1_> Bug #34570
<Ubugtu> malone bug 34570 in gksu "gksu -u root segfault (dapper)" [Normal,Unconfirmed]  http://launchpad.net/bugs/34570
<_lemsx1_> $> gksu echo foo
<_lemsx1_> foo
<_lemsx1_> $> gksu -u root echo foo
<_lemsx1_> Segmentation fault
<Burgundavia> _lemsx1_: if you filed a bug, that is all that is needed
<Burgundavia> developers will respond on the bug
<Burgundavia> if you have a fix, please respond there too
<_lemsx1_> Burgundavia: ok. let me see what causes this... thanks
<Burgundavia> glatzor: have you worked on smart?
<glatzor> Burgundavia: h. no. I've even learned python last month. :)
<Burgundavia> hmm
<glatzor> Burgundavia: you know the 'fantastic' webboard? :) it is my first app.
<Burgundavia> glatzor: no, never heard of it. Is that a good thing or a bad thing?
<glatzor> Burgundavia: I think that I am not the right one to answer this question. But it could be of use if you use GNOME and a pastebin server.
<Burgundavia> jsgotangco: can you search on the url bar in epiphany?
<glatzor> Burgundavia: http://gnomefiles.org/app.php?soft_id=1269 <-- even features a screencast
<Burgundavia> hmm, seems cool
<Burgundavia> and I award you bonus points for not using flash
<Burgundavia> futher points for using epiphany
* ajmitch finds the magic sqlite sauce to fix up f-spot bugs
<Seveas> webboard is nice
<Seveas> glatzor, you should fix /usr/bin/webboard though ;)
<glatzor> Burgundavia: jsgotangco: the term "channel", "source" and "repository" are used in different ways in g-a-i/software-properties and documentation
<Burgundavia> glatzor: oh joy
<glatzor> Burgundavia: Canonical wants to use "channel"?
<Burgundavia> I disagree complete with the word channel
<jsgotangco> im currently in breezy
<Burgundavia> that is word they were throwing around at UBZ
<glatzor> Burgundavia: there should be a consence on this pretty soon.
<Burgundavia> a channel would be a component
<Burgundavia> that is what I think they meant
<Burgundavia> so you would add a channel for universe or for skype
<glatzor> but this doesn't follow the desgin of apt
<Burgundavia> I think we are switching to smart for dapper+!
<glatzor> but the next release is dapper+0. :)
<Seveas> Burgundavia, you almost gave me a heart attack
<Burgundavia> Seveas: why?
<Seveas> I don't like smart too much
<jdub> smart is sweet
<Burgundavia> canonical did hire the lead developer of smart in 2005
<jdub> the ui is bong
<jdub> but that's no problem
<Burgundavia> presumably for more than just baking cookies
<Burgundavia> glatzor: https://wiki.ubuntu.com/RepositoryDialogRedesign
<glatzor> Burgundavia: Because of this spec I renamed all "repositories" to "channels"
<glatzor> Burgundavia: hm. the screencast seems a little bit "direct in your face". perhaps I should move it to its own wiki site
<Burgundavia> just move it down
<Burgundavia> https://launchpad.net/distros/ubuntu/+spec/third-party-packages
<Seveas> heh
<Seveas> nice quit msg
<glatzor> Burgundavia: should I add a topic "braindump" to the spec?
<Burgundavia> glatzor: which spec?
<glatzor> the redesign one
<Burgundavia> https://launchpad.net/products/gnome-app-install/+spec/ui <-- this one?
<glatzor> https://wiki.ubuntu.com/RepositoryDialogRedesign
<Burgundavia> it is already at braindump
<jsgotangco> brb
<glatzor> Burgundavia: should i bring the "channel/source/repository" issue to the ubuntu-devel and ubuntu-doc list?
<Burgundavia> glatzor: ubuntu-devel for now
<glatzor> Seveas: does the drag and drop of files to the webboard applet work for you?
<Burgundavia> jdub: why is fileroller creating blah.zip_FILES directories again. I thought that was a bug that had been fixed?
<glatzor> it seems that it stopped working here without any known changes
<Lathiat> Burgundavia: how is that a bug?
<Lathiat> 99% of  .zips dont have a subdirectory, it makes sense to make one ?
<Seveas> glatzor, yes - didn't know that feature yet 
<Burgundavia> Lathiat: localization bug
<Burgundavia> Lathiat: it should just create a folder with the name of the zip/tar.gz/etc. file
<Lathiat> Burgundavia: it cant have the same name
<Lathiat> Burgundavia: you cant have a file and directory witht he same name?
<Burgundavia> why not?
<Lathiat> or you mean to take the .tar.gz off it?
<Lathiat> (or .zip, or whatever)
<Burgundavia> that works too
<Burgundavia> _FILES looks hideous, aside from the obvious issues with i10n
<Burgundavia> ok, why is python barfing "import: command not found" for all python programs?
<glatzor> Seveas: It is fixed in my local bzr repository
<Seveas> Burgundavia, bad #! interpreter?
<Seveas> sounds like the shell is interpreting your pythin files
<Burgundavia> ya, that is it
<glatzor> jsgotangco: do know how to open scrollkeeper docs in khelp?
<klepas> curious, will breezy users be able to update to GNOME 2.14 when it comes out?
<klepas> without updating to dapper i mean
* _lemsx1_ backporting Gnome takes a lot of courage
<klepas> so no i guess
<_lemsx1_> dunno. i'm not a dev
<klepas> that's it, i'm updating to dapper on the 14th :)
<_lemsx1_> that's perhaps the wisest thing to do... testing gnome2.14 was done on dapper after all...
<klepas> yea
<klepas> you're using dapper already?
<_lemsx1_> klepas: isn't everybody?
<_lemsx1_> ;-)
<klepas> ^^
<jsgotangco> lol
<Mithrandir> Keybuk: so, I have a patch to NM to fix https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/33322 ; it doesn't allow you to join non-utf8 essids but at least stops NM from going "aieee".  Do you want the patch or should I just upload?
<Ubugtu> malone bug 33322 in network-manager "segfaults on invalid UTF-8 ESSIDs" [Normal,Unconfirmed]  
<Mithrandir> Keybuk: also, debuild ; debuild in NM seems to fail.
<Keybuk> Mithrandir: ask me tomorrow
<Mithrandir> k
<sivang> hi all!
<nictuku> hi
<Keybuk> Mithrandir: (watching F1, just online for live-f1 support :p ... and then will be off for the afternoon)
<Mithrandir> Keybuk: yeah, I noticed the live-f1 stuff. :-P
<Mithrandir> myself, I'm busy putting together a jigsaw
<jeroenvrp> hi folks
<jeroenvrp> I have a problem with apt-get (dapper) the last days
<jeroenvrp> not with apt-get actually, but with openoffice 2.0.2 being not complete
<jeroenvrp> I only have the dutch language component of 2.0.2 lin my list
<jeroenvrp> and when I want to upgrade this, it wants to remove OOo completely, because the rest is still 2.0.1
<jeroenvrp> I hoped the rest of OOo would be in the repos, but no luck for allready 2 days
<jeroenvrp> hopefully you read this
<Seveas> jeroenvrp, known problem
<Seveas> just wait
<jeroenvrp> Seveas: ok, thanks - so its not me
<cassidy> elmo: ping
<Riddell> Mez: on hand?
<ogra_> Kamion, disabling the screensaver on start of your is the second method, but if your app crashes it stays disabled, thats why i prefer the timeout pinger ...
<ogra_> s/your/your app/
* ompaul pokes mako
<elkbuntu> if Pygi comes back looking for me, tell him i left him a memo with memoserv
<jeroenvrp> Seveas: they are now in the repos
<jeroenvrp> thanks
<Riddell> what's the program that I can change my laptop brightness with in gnome?
<Mithrandir> Riddell: gnome-power-manager?
<Riddell> Mithrandir: that's just a daemon, I'm looking for the front end
<Mithrandir> the applet is /usr/bin/gnome-power-manager
<dradul> {j #ubuntu
<mako> ompaul: yah
<ompaul> mako, you said we should have a chat about gnubuntu is your mobile on?
<mako> hmm.. 
<mako> yes we should
<mako> nows not the best time
<ompaul> okay, no worries 
<ompaul> my afternoon is fun anyway writing up a presentation for teachers about the joys of free software and the like 
<Seveas> Kamion, ping
<desrt> mvo; 'sup.
<ssam> sorry to disturb people but this looks like rather a serious security bug https://launchpad.net/distros/ubuntu/+bug/34606/
<Ubugtu> malone bug 34606 in Nexenta OS "Administrator root password readable in cleartext on Breezy" [Normal,Unconfirmed]  
<fabbione> ssam: wrong channel. that's Nexenta
<ssam> apparently it effects ubuntu too
<fabbione> impossible
<ssam> i'd hope so, but people are confirming it in the forums
<fabbione> oh halt
<fabbione> that's from the installer
* fabbione checks
<mjg59> Interesting. Certainly wasn't the case in Hoary.
<ssam> i dont see it on my machine though, powerpc default install
<mjg59> ssam: A stock install of breezy?
<ssam> yes
<mjg59> Ok
<mjg59> How odd, then
<mjg59> I don't think I have any machines that were installed as Breezy
<fabbione> it's not in dapper
<fabbione> and i don't have breezy
* fabbione checks around
<fabbione> no i have no such machine
<tseng> doesnt seem to be the case here
<tseng> dapper box installed with breezy
<sladen> wow.  I processed *3* PGP slips.  r.
<siretart> sladen: thanks for the sigs :)
<bddebian> Hi folks
<bddebian> Do we have any documentation on how MoM works?
<bddebian> Where the heck is everyone? :-(
<ajmitch> asleep or drinking
<bddebian> ajmitch!
<bddebian> ajmitch: What is Scott's nick?
<ajmitch> keybuk?
<bddebian> Oh yeah.. Man I'm dense
<jono> hi all
<bddebian> ajmitch: Do you know if we have any wiki pages on setting up a buildd?
<jono> anyone know where the gstreamer 0.10 equivilent of gstreamer0.8-lame is ?
<ajmitch> bddebian: nope
<sivang> hye jono , 'sup?
<sivang> hey bddebian 
<ajmitch> jono: gstreamer0.10-plugins-ugly-multiverse
<jono> hey sivang 
<bddebian> Hi sivang
<jono> ajmitch, thanks
<ajmitch> I think 
<jono> sivang, hows it going?
<jono> ajmitch, any idea which package 'mad' is in?
<ajmitch> similar, gstreamer0.10-plugins-ugly
<jono> ok thanks
<ajmitch> how goes the book writing?
<jono> when unmounting usb devices in dapper, do we still need to leave a minute or so after icon disappears to ensure it was cleanly unmounted?
<mvo> jono: the last version of dapper should have a notification when it can be plugged out
<jono> mvo, ok, does it throw up a dialog box when it does this?
<mvo> jono: it should come up with a dialog when you click unmount, but I'm not 100% up-to-date on this (seb128 or pitti are) 
<jono> ok thanks
* mvo needs to go now
<jono> thanks mvo
<Kamion> ssam: noted, thanks, I'll check it out at the earliest possible opportunity
<ssam> Kamion, thanks, lets hope this does not get overexcitedly posted on all the news site
<Kamion> I can reproduce it in the vmware install of breezy I did ages ago
<Kamion> but I want to dig through the installer to work out *why* it's happening, since there's explicit code in there to prevent it
<Seveas> Kamion, fwiw I have a hoary, breezy and dapper install here - none of them exhibit this bug
<ogra> my edubuntu breezy does ... :/
<Kamion> I'll fix it for existing installs with a base-config update
<Kamion> but as I say, I want to figure out why on earth it's happening first
<ogra> seems not to happen genrally ...
<ogra> *generally
<soumyadip> can anyone tell me how to select locales other than english, like maybe hi_IN and bn_IN in Dapper ?
<soumyadip> dpkg-reconfigure locales no longer works
<Kamion> locale-gen
<soumyadip> hand calling it ?
<Kamion> or install language-pack-$LL for whatever $LL you want
<sivang> jono: good , good, you?
<jono> sivang, not bad, busy as usual :)
<soumyadip> Kamion, well I'll try the langpack route
<jono> any ideas if Dapper is going to be delayed yet?
<Kamion> calling it by hand is perfectly acceptable, although you probably want to install the language pack anyway
<Kamion> jono: no, that's what the meetings on Tuesday will be about
<ogra> jono, we'll know after next TB meeting i guess
<Kamion> it's only a proposal at present
<jono> Kamion, ahhh cool
<jono> personally I think it makes sense
<Kamion> what would it mean for your book deadline?
<soumyadip> Kamion, well won't n00bs be afraid, I mean it is one thing to select hi_IN from a list and another thing to type locale-gen hi_IN at a console
<jono> Kamion, Mark asked me about this - it should be fine, the book deadline pretty much moves alongside the dapper deadline
<Kamion> soumyadip: dpkg-reconfigure was never particularly newbie-accessible anyway
<Kamion> soumyadip: newbies can use the language selector which lets them select their language from a graphical list
<jono> if it gets delayed, I suspect it will make dapper better and will also make the book better :)
<Kamion> soumyadip: that will install the language pack and thereby create the locale
<jono> more time to polish :)
<soumyadip> Kamion, there is a language selector ? damn it I must've missed it
<Kamion> soumyadip: yeah, should be in your menus
<soumyadip> Kamion, looking for it
<ogra> in the System menu
<Kamion> well, I can reproduce the password bug here - now for an instrumented run
<Pygi> jono: writing book about dapper?
<Kamion> god, how the hell did this slip past
<jono> Pygi, yep
<Pygi> jono: k, great ;) Now we'll have two :-P
<jono> Pygi, you doing one?
<Pygi> jono: aha ;)
<jono> Pygi, who is yours for?
* jono is working on the Official Ubuntu Guide
<Pygi> great jono...continue the good work ;)
<jono> Pygi, :)
<Pygi> If you need any help with writing, let me know...
<Pygi> Mine isn't on english... ;)
<soumyadip> Kamion, ogra, hey thanks a ton for pointing the Language selector
<jono> Pygi, croatian ?
<Pygi> jono: yup
<jono> cool :)
<jono> good luck with it :)
<Pygi> jono: thanks ;) good luck to you as well ;)
<Pygi> if you need me to write few portions of book, please let me know ;)
<jono> Pygi, man you like the ;)  :)
<Pygi> jono: :)
<jono> Pygi, cool thanks :)
<jono> Pygi, we are nearly there
<Pygi> jono: k...what's the focus in the book? regular users/what specificly?
<jono> Pygi, its aimed at introducing new users to ubuntu
<Kamion> soumyadip: np
<Pygi> jono:  to only ubuntu or linux in general as well?
<Pygi> jono: I guess it doesn't explain linux filesystem or somethin' along that lines?
<jono> its just ubuntu
<jono> Pygi, it covers the filesystem
<Pygi> jono: hm, that's not really for people who just want to use system...but heh, your book :)
<jono> Pygi, we just cover the basics
<Pygi> jono: that's much better ^^
<jono> :)
<Pygi> let's move to #ubuntu-offtopic, ok? this is not appropriate channel..
<Seveas> jono, I just mailed appendix A back to prentice hall, book looks not bad so far 
<jono> Seveas, cool, its getting there :)
<Seveas> I'm waiting for the revised chapters ;)
<ssam> Kamion, eek http://www.osnews.com/story.php?news_id=13951
<ajmitch> ssam: it wouldn't take long
<Kamion> yay osnews :-/
<Kamion> I think I've isolated the twin causes
<ajmitch> Kamion: is espresso the recommended install method for testing now?
<Kamion> one is a very convoluted bug in cdebconf's passthrough implementation, and the other is an unfortunate consequence of using passthrough that we failed to work around
<Kamion> ajmitch: mu
<ajmitch> sorry :)
<Kamion> ajmitch: (you assume there is a single recommended install method for testing ...)
<ajmitch> heh
<Kamion> I've phoned pitti, he'll be back shortly and I'll try to get an update out tonight if at all possible
<Kamion> bloody hyperactive news sites
<tepsipakki> :)
<YokoZar> Hey, could someone running dapper tell me if clicking both the left and right mouse buttons simultaneously still does a middle click?  We should disable that behavior by default, since it screws up trying to click both mouse buttons in some apps (eg: games)
<mjg59> YokoZar: It shouldn't if you've ever pushed the middle mouse button
<mjg59> (I believe)
<YokoZar> mjg59: well on breezy pushing both left + right acts as middle click
<YokoZar> select some text and see it copy/paste it for yourself
<mjg59> If I had a breezy machine handy, I would do so. But I don't.
<YokoZar> So it doesn't on Dapper?
<mjg59> If you feel it's a bug, then please report it. However, we're not likely to cripple the system for people who have two buttoned mice (such as most laptop users)
* sivang is surprised how something like that security hole had breeached our testing and polish last release.
<Kamion> so am I
<Kamion> we should add "grep -r yourpassword /var/log" to some testing procedure somewhere
<YokoZar> mjg59: I had a bug on this a while ago
<YokoZar> The main problem is we can't configure the left/right click behavior from the mouse applet
<mjg59> That's correct
<mjg59> There's no mechanism for you to do so
<mjg59> It's an X server preference, not a per-user preference
<YokoZar> Other than hand editing x's config
<mjg59> The same issue applies to synaptics configuration
<YokoZar> The point is that SHOULD be adjustable per-user
<YokoZar> Like, some sort of X extension that lets it be changed for the session
<mjg59> To make it adjustable per-user would involve writing a new X extension
<mjg59> Given that we don't currently have an X maintainer, that's unlikely to happen in the near future
<YokoZar> ;)
<YokoZar> Maybe I'll draft a spec
<mjg59> Ideally, incorporate synaptics configuration
<mjg59> The same issues apply to both
<YokoZar> And forward it to the xorg people
<YokoZar> wait, what do you mean about synaptics configuration?
<mjg59> Synaptics trackpad configuration is impractical without a similar X extension
<YokoZar> Mouse configuration spec or somesuch
<Chipzz> YokoZar: I feel the urge to hurt you ;P
<Chipzz> YokoZar: how would I be supposed to paste on my laptop?
<YokoZar> Chipzz: ctrl-v?
<Chipzz> no
<YokoZar> right click, paste?
<Chipzz> I use BOTH ctrl-c/ctrl-v AND pasting using the mouse button
<YokoZar> copy/paste is still horribly broken anyway.  I've lost count of the number of times I've hit control-c, gone to another program, hit ctrl-v, and had nothing happen
<Chipzz> and vim copy/paste in vim, and when that is not enough (and if available) the screen copy/paste keys ;P
<YokoZar> Particularly annoying when you select all, copy, then close the window expecting your text to be alive
<mjg59> YokoZar: There are two mechanisms for copy/paste. The middle mouse button one is separate to ctrl+c/ctrl+v
<YokoZar> mjg59: right.  That's really strange in and of itself, but I don't use the middle mouse one at all and still see rather broken things like above
<Chipzz> and having both available is a blessing (for me) :)
<Chipzz> and I suspect for other users too
<YokoZar> As much as it pains me to say, copy/paste seems to work a lot better and clear on Windows
<Chipzz> that's a whole seperate issue
<Chipzz> btw I'm using rxvt, which doesn't support ctrl-c/ctrl-v
<Chipzz> and I suspect neither does xterm :P
* ogra would go on a rage if he had to use any key to paste selectd text 
<ogra> and since my laptops all only have two keys, emulate3button is essential
<ogra> s/keys/buttons/
<YokoZar> Chipzz: xterm does support shift+insert instead of ctrl-v
<pitti> hello
<zyga> hey pitti
<Kamion> hi, just sending you mail
<zyga> do you happen to own a mac mini?
<pitti> no, unfortunately not :)
<zyga> I'm looking at my box, wide open and wondering wether I should 'upgrade' the cpu by removing some resistors
<zyga> hmm
* zyga has just seen the /var/log/debian-installer bug on digg
<Kamion> it would be so nice if folks would give a guy time to fix the damn thing on a Sunday
<zyga> Kamion: ay, is there any way to fix this apart from chown root:root $damn_file && chmod 600 $damn_file?
<Kamion> zyga: I'm working on it, the fewer questions the better if you don't mind
<ogra> zyga, just wait for the fix
<zyga> sure, sorry
<Kamion> (more questions => fix will take longer, I'm critical path)
<zyga> I'm not affected actually
<YokoZar> In Dapper, if you open up the disks manager applet, click partition properties, and then click browse, will it still open it with root privileges?
<YokoZar> I'd like to close/reopen this bug, as it is a security issue: http://bugzilla.ubuntu.com/show_bug.cgi?id=17049
<Ubugtu> ubuntu bug 17049 in gnome-system-tools "Browsing as root from disks manager" [Normal,New]  
<LaserJock> YokoZar: the bug is "Unconfirmed" in Malone
<YokoZar> LaserJock: well, I can confirm it for Breezy, heh.
<LaserJock> YokoZar: well, that doesn't help much for Dapper
<YokoZar> If you're on Dapper, you can try it yourself right now by opening up the disks manager
<YokoZar> system->admin->disks, click partitions, click browse.  Make a file, see if it was made by root or your user
<LaserJock> hmm, I don't have my Dapper box running at the moment
<LaserJock> YokoZar: I'm getting a couple guys in #ubuntu-motu to try it. ;-)
<YokoZar> Thanks LaserJock
<zyga> I'm on dapper if anyone needs
<YokoZar> We've confirmed it zyga
<zyga> ok
<ogra> YokoZar, why do you think its a bug ? if i run under root rights, i expect that behavior
<ogra> i think its at least very questionable to call it a bug
<YokoZar> Because I would expect it to open without root privs, like every other nautilus window.
<ogra> not if i just gave my password and was told i work in admin mode 
<ogra> its exactly waht i'd expect in this case
<LaserJock> ogra: do you have to start disk manager as root? I mean put in a password to open it up?
<ogra> yep
<ogra> you have to sudo 
<LaserJock> oh, well then I see your point
<YokoZar> At the very least it needs to be made clear it's not a normal nautilus window
<zyga> tip: yellowish background!
<YokoZar> see this: https://wiki.ubuntu.com/UsefulDisksManagerSpec
<ogra> just change the wording of the button would be my fix
<ogra> "Browse in admin mode"
<zyga> ogra, then there'll be bugs about missing button: browse in normal mode
<ogra> haha
<YokoZar> He's right, you know
<ogra> nope...
<YokoZar> I'd prefer the normal mode button anyway
<ogra> what for ? 
<YokoZar> Why do you need to nautilus around with root privs?
<ogra> you can just use a normal filemanager if you want to browse files
<zyga> ogra: then the button is useless, if someone just wants to browse files she/he cannot use it
<ogra> its pointless to have a "browse" button there if its not for root, since you can just use your nautilus
<YokoZar> Then you have to find the partition you just created by hand.  The whole point is it gets a lot easier to just click it from inside the applet
<zyga> I agree about changing the wording but there is obviously a bigger bug here
<YokoZar> Maybe we should finish drafting that spec I posted
<YokoZar> Lots of work could be done on the disks manager
<ogra> either drop the button or change the wording, but a user "browse" button is useless
#ubuntu-devel 2006-03-18
<zyga> I disagree really but that's not for me to decide
<ogra> anyway, adding partitions is a very advanced task ...
<YokoZar> ogra: I present myself as evidence to the contrary, since I wouldn't have found this bug if it were useless ;)
<zyga> user has to use the root mode because that's how things work but the applet should probably follow the principle, do something that has to be done by root and go back to normal user mode
<zyga> ogra: true!
<jordi> jdub: dude
<jordi> jdub: ping ping
<jdub> jordi: pong pong! :)
<jordi> jdub: that was FAST DUDE
<jdub> jordi: that list was already created, btw
<jordi> jdub: was that between my second ping and now=
<jdub> jordi: i think the guy who is pinging you is not the person who requested the list in the first place
<jordi> oh. Hmm.
<jordi> ok, I'll tell g0sub
<jordi> second. I wonder if I should be in planetubuntu.
<jdub> hell yeah
<jdub> want me to put you up?
<jordi> and if yes, if you can add my Ubuntutu entry by hand or something
<jordi> I guess so
<jdub> hrm, it'll probably turn up in the feed
<jordi> will it suck all the feed?
<jordi> there's anther entry after that one
<jdub> on the first go, it only lets in the first two
<jordi> oh, the first two
<jordi> then it's ok
<jordi> DO IT
<jordi> I'll be posting rosetta stuff if I'm in PU I guess.
<jordi> and of course, cool news about the Catalan Liberation Front.
* jdub would yell out some cry of support, but does not know what to say. "VIVE!" doesn't sound right. although you are a bunch of french gypsies/
<jordi> VISCA!!! would be quite acceptable in Barcelona.
<jordi> learn that one for your talks @ guadec
<jordi> they will love it
<jordi> VISCA EL GNOME!
<Treenaks> that sounds like 'viscerate'
* jordi disintegrates Treenaks 
<jdub> so what is your nick now, jordim, or jordi?
<jordi> jordi on feenode
<jdub> oh
<jordi> jordim on gimpnet, as jordi is taken.
<jdub> ok, i will use jordi then
<jordi> k
<jordi> I'd like it to be jordi everywhere.
<jordi> but doing a hostile takeover on gimpnet against one of my liberation front mates is not that cool :)
<jordi> we need the nickname thing on planet debian
<jordi> jdub: I don0t see ubuntu-in in the mailman listing at all. what's the list name=
<jordi> ?
<jdub> it's not available until the list admin has a chance to fix it up
<jordi> aha
<jdub> you can sneak peek if you know the mailman url scheme ;)
<jordi> oh
<jordi> it does work now
<jordi> it didn't before
<jordi> I swear
<jordi> I know you fixed it.
* jordi points at jdub.
<jdub> haha
<jdub> the unpublished url?
<jordi> it was saying "ubuntu-in does not exist"
<jordi> now it says it is run by pantless people
<jdub> jordi: eek, good point. i better change that, or she might not.
<jordi> heh
<jordi> jdub: so did you add me to planet
<jono> hey
<Burgundavia> salut jono
<jono> hey Burgundavia :)
<jono> Burgundavia, hows the writing going?
<Burgundavia> jono: working on the community chapter. You?
<jono> I worked on some bits of chap 3 and added some of the reviewer comments - I think my chapter missed some important bits out, so I filled much of it in
<jono> tomorrow I will finish that, merge in the new contributions to chap 7 and then start merging a couple of others together
<Burgundavia> jono: are you working full time on the book right now?
<jono> Burgundavia, not full time, but I do work on it a reasonable amount during the day
<Burgundavia> you are a lucky man
<jono> Burgundavia, I work as an Open Source evanglist full time so it comes under my remit :)
<Burgundavia> 8 hours of work made it hard to concentrate enough to write in the evenings
<jono> Burgundavia, its a tough job writing a book
<sladen> elmo: http://www.ubuntu.com/htdocs/ubuntuweb/css/screen-standard.css has disappeared and the Ubuntu website is fairly broken as a result.
<robertj> apt-cache search libgl
<robertj> doh ;)
<robertj> http://paste.ubuntu-nl.org/10100 <- getting undefined symbols consistant with having mismatched libGL & DRI drivers but have installed both from packages...
<sladen> elmo: or rather, the NTL caches have eaten it.  Your end is fine.
<infinity> robertj: Erm, that can't be the paste you wanted to show..
<infinity> robertj: Anyhow, if you're suffering libGL mismatches, do you by any chance have nvidia-glx or xorg-driver-fglrx installed, but are using the free drivers (ati or nv) instead?
<infinity> robertj: That'll confuse the world in pretty harsh ways.  If you're not using them, you have to completely remove the non-free drivers, not just remove them from xorg.conf
<infinity> robertj: (ie: dpkg --purge xorg-driver-fglrx)
<khermans> Installation Password Vulnerability code
<khermans> http://www.ubuntuforums.org/showpost.php?p=818304&postcount=74
<khermans> i wrote a quick perl script to see if you are vulnerable
<infinity> khermans: And we've already released a fix.  This probably isn't the right channel to discuss it much further (unless you want to discuss how to fix it better)
<sladen> khermans: http://www.ubuntu.com/usn/usn-262-1  done, dusted
* Kamion fixes one of the twin root causes of the installer password vulnerability upstream
<Kamion> (cdebconf failed to honour accept_types/reject_types for templates received over passthrough)
<infinity> Oh dear god, OpenOffice 2.0.2 actually starts in under a minute.  Someone actually optimised something.. \o/
<bddebian> heh
<Amaranth> that reminds me, do we have/will we have michael meeks' glibc stuff that makes C++ apps start faster?
* infinity drops everything to go write some pointless documents and spreadsheets in celebration.
<infinity> Amaranth: When/where was this committed?
* Lathiat laughs at infinity 
<infinity> Amaranth: We're certainly not bumping a new glibc minor version in (since glibc minor versions are pretty, uhh, major)
<Amaranth> infinity: i don't think it was
<Amaranth> infinity: they didn't want it, said you should just use preload
<infinity> s/load/link/ I assume you mean?
<Amaranth> yeah
<Amaranth> i haven't used it in a long time :)
<Amaranth> something for dapper+1 though? it'd make OOo and KDE users happy, i'm sure
* infinity shrugs... File a wishlist bug with a pointer to the relevant mailing list discussions and patch.
<infinity> It can certainly be evaluated for dapper+1
<Amaranth> will do
<sladen> Kamion: what's the other one.  I just found a password of mine on a customer's box... 
<Kamion> sladen: the other one is that initial-passwd-udeb.postinst doesn't clear out the password in the installer's cdebconf database, although the password is cleared out by passwd.config from the debconf database in /target
<Kamion> sladen: either fix alone is sufficient to avoid the bug; I haven't fixed the initial-passwd-udeb.postinst bug anywhere yet because that entire chunk of code is gone upstream and from dapper
<sladen> Kamion: messy.  I guess   grep -r sEcReTpAsSwOrD /  is something to add to the testsuite
<stratus> are the libgnome locale messages missing from the package (2.3.90-0ubuntu3) or i'm missing something?
<Kamion> .mo files are stripped from everything in main and go into language-pack-* instead
<sladen> stratus: they're separated off into langpacks
<stratus> bingo!
<stratus> i forgot that, sorry.
<dotwaffle> I swear, if ONE MORE USER tries to cat the install log file on my upgraded hoary install, I will actually be willing to reconsider my stance on execution...
<bddebian> Yikes
* Kamion verifies fresh dapper installs free of the password disclosure bug
<dotwaffle> Kamion: It only affects 5.10, you're safe unless you dist-upgraded from Breezy.
<Amaranth> It only affects you if you installed using 5.10
<infinity> dotwaffle: Kamion is the installer maintainer, he's likely aware of the exposure (and is testing to make sure that's true)
<dotwaffle> I just reread what I'd written. I need sleep - you're obviously doing something to check it's not still borked.
<dotwaffle> infinity: I know, but somehow, sleep prevented me from remembering that...
<dotwaffle> Right, that's it, I just tried to specify $1 field insertions using bash aliases, I need sleep... night...
<HrdwrBoB> https://launchpad.net/distros/ubuntu/+source/glibc/+bug/29768
<Ubugtu> malone bug 29768 in glibc "Australian timezones incorrect for 2006" [Normal,Confirmed]  
<HrdwrBoB> wtf is going on with this?
<elkbuntu> hmm what updates in the past 5 hours have meddled with/removed the minicommander panel applet?
<robertj> infinity: sorry for being afk and your right this pastebin script is not returning results properly, but that was the problem, I just took out a radeon card
<robertj> infinity: is that a known issue where having xorg-driver-fglrx will cause it to b0rk?
<infinity> robertj: Yeah, I've put some effort into figuring out a clever way to work around it, but because fglrx/nvidia use their own libGL (and not the system libGL), it's a messy thing.
<infinity> robertj: They have to divert the system libGL out of the way to function, but then other drivers break.
<robertj> infinity: ended up not being able to stand the extra noise generated when I had a radeon in this system
<infinity> robertj: Generally considered an okay compromise, since if you install fglrx or nvidia-glx, you probably wanted to use it too.
<robertj> infinity: doesn't that make liveCDs sad?
<infinity> How would it?
<robertj> I guess you can still install it on-the-fly then
<infinity> If you're very lucky...
<infinity> Lots of DRI/DRM combinations tend to be completely unloadable at the kernel level.
<infinity> So you'd probably have to use a persistent LiveCD to install fglrx/nvidia-glx and reboot.
<infinity> I can't imagine this is a use case many people care terribly much about, though.
<robertj> be back in a second, still unhappy, restarting Xorg
<robertj> infinity: btw, that made Xgl happy too
<robertj> although Xgl shows direct rendering no and is very slow, is that normal?
<robertj> I guess that's one for ubuntu-xgl
<infinity> Yeah, I know very little about Xgl.
<setuid> Question: Why would a source package fail to build clean, when all deps are satisfied? 
<setuid> i.e. 'apt-get source foo' && cd foo && debuild
<setuid> http://rafb.net/paste/results/rfER5i98.html
<setuid> ...along with about 78 lines of error below that
<setuid> Those files don't even exist in all of Debian or Ubuntu, in any package
<infinity> setuid: Which package is this?
<setuid> infinity: libmp4v2-0
<setuid> Upstream CVS source for that doesn't build either... needs some serious work. Sigh. 
<setuid> So I can't build gtkpod 
<setuid> whee! 
<SEJeff> I have an rtf file that will segfault the latest openoffice in dapper (2.02)
<setuid> SEJeff: backtrace? 
<SEJeff> I ran soffice.bin in gdb to get a backtrace
<SEJeff> And it keeps asking me to press enter after thousands of lines of output
<SEJeff> Is there any way to have gdb log to a file?
<SEJeff> Because I'm not going to copy / paste this many lines
<SEJeff> Actually, I am having a friend do this and I am using NX to help him troubleshoot it
<SEJeff> any ideas
<infinity> setuid: I can't reproduce the failure here.  It builds fine in a clean chroot with the build-deps installed (which was to be expected, since it also worked on the buildds).  There's something goofy with your local setup.
<setuid> I'm on Breezy, might that make a difference? 
<infinity> Erm, quite possibly.
<setuid> It definitely does not build here, using any version of automake/autoconf/autoheader/aclocal
<infinity> I was building the dapper sources in a dapper chroot.
<setuid> I guess its broken in Breezy
<setuid> But the source package is _identical_ between Breezy and Dapper, unchanged. 
* infinity tests in breezy, out of curiosity.
<setuid> I'm using faad2-2.0.0+cvs20040908+mp4v2+bmp
<setuid> Which is what 'apt-get source' brings down
<setuid> debuild bootstraps the chroot, no? 
<infinity> Err, what?
<infinity> debuild has nothing to do with chroots.
<infinity> It's just a small wrapper around dpkg-buildpackage
<setuid> hrm
<setuid> I thought it did the whole chroot + dpkg-buildpackage mess
<setuid> How are you building this? 
<setuid> It can't possibly build, there are files that are required, completely missing from any and all .debs in the whole pool
<setuid> faad2.h:28:26: error: codec_plugin.h: No such file or directory
<setuid> faad2.cpp:22:32: error: mpeg4_audio_config.h: No such file or directory
<setuid> faad2.cpp:23:23: error: mpeg4_sdp.h: No such file or directory
<infinity> Which I'd expect to be in the faad2 source.
<setuid> Nope
<setuid> Even googling for them comes up blank
<setuid> Well, I'm heading to sleep. Thanks. 
<LaserJock> setuid: pbuilder builds packages in a chroot envioronment.
<setuid> LaserJock: Sure, so what bootstraps pbuilder? 
<LaserJock> debootstrap
<setuid> Ok, let me try this a different way
<setuid> I have a tree of unpacked source from Ubuntu, which has a ./debian directory in it. I'd like to rebuild that source into .debs I can then install, which should replace the existing versions on my system. 
<setuid> How do I do that, without a 45-step process? 
<LaserJock> setuid: debuild and the pbuilder is how I usually do it
<infinity> Either build it in your base system (apt-get install build-essential fakeroot; apt-get build-dep <package>; cd <package_version>; dpkg-buildpackage -rfakeroot -uc -us -b)
<infinity> Or, set up chroots and do it in there.
<infinity> Or, use sbuild or pbuilder.
<infinity> Or, come up with your own fancy solution. :)
<LaserJock> setuid: or pdebuild in one step
<setuid> Well, pdebuild requires some setup too 
<LaserJock> setuid: pdebuild is debuild+pbuilder
<infinity> Anyhow, it appears to build fine in my breezy chroot to... <shrug>
<setuid> This does nothing: apt-get build-dep libmp4v2-0 
<infinity> So, you have the build-deps installed.
<setuid> Yep
<setuid> Trying dpkg-buildpackage -rfakeroot -uc -us -b now
<setuid> Same errors
<infinity> That's more or less what debuild will do for you, so if debuild doesn't work, neither will dpkg-buildpackage.
<setuid> In file included from faad2.cpp:21:
<setuid> faad2.h:28:26: error: codec_plugin.h: No such file or directory
<setuid> faad2.cpp:22:32: error: mpeg4_audio_config.h: No such file or directory
<setuid> faad2.cpp:23:23: error: mpeg4_sdp.h: No such file or directory
<infinity> Your problem is more fundamental, I suspect.
<setuid> ^ those files simply do not exist, anywhere, in any of these sources
<setuid> Right
<infinity> (You didn't change the source in any way, did you?)
<setuid> Nope, just rm'd and did a clean 'apt-get source' on it 
<setuid> apt-get source libmp4v2-0
<setuid> cd faad2-2.0.0+cvs20040908+mp4v2+bmp
<setuid> dpkg-buildpackage -rfakeroot -uc -us -b
<setuid> (chug chug) 
<setuid> then the errors above
<Chipzz> setuid: what about debootstrapping breezy, trying to build it there, and if it works see where those files come from?
<setuid> Chipzz: No idea what you mean 
<setuid> I'm *ON* Breezy
<Chipzz> 06:12 < infinity> Anyhow, it appears to build fine in my breezy chroot to... <shrug>
<infinity> s/to/too/
<Chipzz> infinity: you could always do a dpkg -S for those files? :)
<infinity> setuid: The build normally doesn't even attempt to build the mpeg4ip plugin (where the broken includes come from), as far as I can tell, so sometihng on your system (whacky environment, who knows) is making things unpleasant.
<setuid> I'm not even sure how you can get it to build, when faad2.h clearly references a non-existant file
<Chipzz> or rather, locate and dpkg -S
<infinity> Chipzz: Oh, no, the files really don't exist, but they also don't get included in the default package build.
<Chipzz> ah ok
<infinity> DEB_CONFIGURE_EXTRA_FLAGS := --with-xmms --with-bmp --with-drm --with-mp4v2 --disable-mpeg4ip
<infinity> ^--- From debian/rules
<setuid> DEB_CONFIGURE_EXTRA_FLAGS := --with-xmms --with-bmp --with-drm --with-mp4v2 --disable-mpeg4ip
<setuid> Same here
<setuid> But it still tries to build it 
<setuid> I just yanked it from the Makefile, trying now
<infinity> Right, so figure out why that is, or use a chroot. :)
<Chipzz> setuid: take a look at the Makefile.am and look on what condition that dir gets build
<infinity> We've gone way out of the scope of "this package is broken" (which I and the buildds disagree with)
<setuid> Doesn't "dpkg-buildpackage -rfakeroot" use a chroot? 
<infinity> No.
<Amaranth> setup a breezy pbuilder
<zerokarmaleft> when i use pbuilder + bindmounted local apt repository, the packages i've built specifically to meet BuildDepends aren't tried during satisfydepends
<setuid> Ok, looks like --disable-mpeg4ip doesn't actually disable it 
<Chipzz> setuid: on a seperate note, why do we use --with-xmms ?
<Chipzz> hrm wait, probably cause that's installed by default :P
<setuid> Yep
<Chipzz> I just nuked it from my system :P
<Chipzz> no gtk+ 1.2 apps here ;)
<zerokarmaleft> here's the bash script i'm using to call pbuilder + local bindmount - http://pastebin.com/599151
<Bicchi> If dapper doesn't have the lattest version of a software, how do i report/suggest an upgrade? What is the procedure?
<nictuku> Bicchi, dapper is in feature freeze
<LaserJock> Bicchi: most packages in Ubuntu come from Debian. And we are under a upstream version freeze
<Bicchi> so it means nothing can be added to it. until the next release of ubuntu. the one after dapper that is.
<LaserJock> Bicchi: we do have exceptions for  important bug fix releases but they have to be approved, etc.
<Bicchi> but again, if i see that the package doesn't get upgraded, should i notifiy Debian instead?
<LaserJock> well, they don't have a version freeze at the moment and we would sync from debian sid for Dapper+1 so it would definately be one way to go
<zerokarmaleft> and the pbuilder output - http://pastebin.com/599156 - the package i'm building BuildDepends on rake (>= 0.6.0) and i've got rake-0.7.0 sitting in my local apt repos
<LaserJock> zerokarmaleft: I used another machine to host my apt repo so I didn't use bind mounts. It worked fine that way
<highvoltage> i see nexenta listed in launchpad as a distro, does this mean we'll soon have a solaris for human beings as well?
<highvoltage> hi ubuntu-devel. there's been no announcement yet about the Ubuntu initial user password being stored as clear text, readable by all users. will there be one soon?
<Burgundavia> highvoltage: already fixed
<robitaille> highvoltage: http://www.ubuntu.com/usn/usn-262-1
<highvoltage> ah, thanks
<Burgundavia> highvoltage: plus it is a local only exploit
<maswan> Was any of the flight-N installers vulnerable?
<fabbione> maswan: no
* maswan chmods install-logs, just to be sure
<fabbione> dapper is o
<maswan> fabbione: Ah, ok. Good.
<fabbione> +k
<maswan> fabbione: Well, that could also be interpreted as "current dapper is OK", or "released dapper will be OK" from the USN.
<fabbione> maswan: well there is no support for Dapper.. afaik Dapper was never vulnerable
* robitaille wonders if bug 34606  should be marked fixed
<Ubugtu> malone bug 34606 in Nexenta OS "Administrator root password readable in cleartext on Breezy" [Normal,Unconfirmed]  http://launchpad.net/bugs/34606
<CarlFK> dapper was (is)
<maswan> fabbione: Yeah. I just happen to have a debian/ubuntu devel machine for amd64 that was installed with flight-3 that I was curious on. All other machines are FAIed at both work and the computer club, so no worries.
<fabbione> maswan: ok :)
<CarlFK> ( is = daily I have, guessing the fixed one will get to me in a few hours)
* maswan saw the bug and looked carefully in questions.dat without finding his password from that flight-3 install
<fabbione> CarlFK: dapper mostlikely never had the problem
<jdub> infinity: ping
<CarlFK> fabbione: I have many dapper intsalls, all have it
<CarlFK> juser@dhcp24:/var/log/installer/cdebconf$ grep useme questions.dat
<CarlFK> Value: useme
<infinity> jdub: pong, but only because you're lucky. :)
<jdub> infinity: ;-)
<jdub> infinity: now mysql 5 is sig11 on startup
<CarlFK> -rw-r--r-- 1 root root   71670 2006-03-12 23:51 questions.dat
<infinity> jdub: ...
<infinity> jdub: Can you work out how to get a backtrace and file a bug?
<jdub> infinity: just got gdb on, shouldn't be long
<infinity> jdub: I'm about 5 seconds from running out the door for dinner and such.
<infinity> jdub: Cool, thanks.
<infinity> jdub: Assign the bug to me explicitely, I don't think I'm the Malone bug contact for MySQL.
<maswan> CarlFK: to which question is that Value: ?
<CarlFK> Name: passwd/user-password
<jdub> infinity: erm, what happens if a stack trace ends with (nil) ?
<CarlFK> and Name: passwd/user-password-again ;)
<maswan> CarlFK: not logged for my flight-3 install.
<CarlFK> think it matters that I used a preseed file?
<jdub> infinity: it didn't pass the stack range sanity check
<maswan> CarlFK: Possibly, since I just did a normal cd install and didn't get it logged.
<CarlFK> speaking of preseed, not that base-config is gone, how do I run commands like I did with base-config/late_command ?
<CarlFK> s/not/now
<tepsipakki> how much effort would it need to move some libraries and binaries from /usr/{lib,sbin} ->/{lib,sbin}? It isn't possible for dapper, that's quite evident, but for dapper+1
<tepsipakki> I'm talking about libkrb5, libgssapi, rpc.gssd, rpc.idmapd which are needed for nfs4-mounts
<tepsipakki> oh, libidmap too
<tepsipakki> libnfsidmap, that is..
<pitti> Good morning
<ajmitch> morning pitti 
<tepsipakki> Guten Morgen
<pitti> hey ajmitch, hallo tepsipakki :)
<maswan> Chipzz: I have no clue, we use FAI everywhere, no preseeds. :)
<Burgundavia> salut pitti, have a fun sunday?
<pitti> Burgundavia: heh, yes, I had :)
<pitti> Burgundavia: Good morning
<Lathiat> so, the password disclosure vuln helped a mate of mine
<Lathiat> hed lost a password, and gave up tryign to brute force it
<Lathiat> turns out it was the same he used in his isntall, so got it back :)
<dholbach> good morning
<netstar> infinity: when you say YOUR initramfs, can that mean any other user-generated with new kerenls?
<netstar> I've had problems but just gave in and build into the kernel
<netstar> I pressumed I was being dumb, but couldn; figure why
<Lathiat> netstar: you trying to load a module from initramfs?
<netstar> Was trying, but having problems
<Lathiat> iirc, you need to put the module in /etc/modules and re-generate your initramfs, may need to put it in the modules file in /etc/mkinitramfs somewhere
<Lathiat> to regen, dpkg-reconfigure linux-image-`uname -r`
<netstar> Lathiat: yes
<sivang> morning all
<janimo> pitti, hi
<janimo> which of the gnome stack is responsible with calling pmount
<janimo> and getting the label of the inserted usbdisk for example
<netstar> gnome-volume-manager ?
<janimo> pmount-hal seems to get it from hal
<janimo> netstar, looked at g-v-m sources and could not find pmount there
<pitti> janimo: right, g-v-m calls pmount-hal
<janimo> I'm interested how gnome determines what label to assign 
<pitti> janimo: and pmount-hal requests label and policy from hal and calls pmount
<janimo> and g-v-m finds out the label by looking at what was mounted? or asks hal itself?
<pitti> janimo: as I said, pmount-hal asks the label from hal
<janimo> since pmount does not return mountpoint
<pitti> janimo: g-v-m just sees 'ah, a new storage device, let's call pmount-hal to mount it'
<janimo> pitti, right
<janimo> but the label on the icon, where is that taken from since pmount does not return it
<janimo> being a command and all
<janimo> replicating what pmount asked from hal or looking at mountpoints
<janimo> so it's not sda1 but usbdisk
<netstar> hal-device ?
<pitti> janimo: ah, I see what you mean
<pitti> janimo: g-v-m queries the mount point from hal after the mounting
<pitti> mount_point = libhal_device_get_property_string (hal_ctx, udi, "volume.mount_point", &error)
<janimo> pitti, aha thanks.
<pitti> janimo: it's actually two invocations
<pitti> 1. new device plugged in -> hal -> g-v-m 'oh, new device' -> pmount-hal
<pitti> 2. the mount triggers a new hal event 'device property changed'
<pitti> 3. hal -> g-v-m 'oh, changed dev property' -> get mount point -> nautilus
<pitti> janimo: ^ a bit clearer now?
<pitti> hey seb128 
<janimo> pitti, yes thank you
<seb128> Hey pitti :)
<dholbach> hey seb128!
<seb128> Hey dholbach
<janimo> pitti, btw do you know why hal upstream is prefering gnome-mount instead of pmount
<pitti> I'm going to test new warty/hoary kernels now, brb
<pitti> janimo: yes, I know
<seb128> pitti: does xpdf-reader ships /usr/bin/pdftoppm ?
<pitti> janimo: but way too late for dapper to change
<pitti> seb128: I added a Replaces: some minutes ago
<seb128> pitti: I was thinking the manpage should be dropped from xpdf-reader rather
<seb128> pitti: yeah, that's why I ask that :)
<seb128> no point to ship a manpage if the package has not the corresponding binary
<pitti> seb128: right it shuold be fixed in debian
<pitti> alright, testing kernels now, bbl
<tepsipakki> could libpam-krb5 (universe) be synced from debian? In dapper we have 1.2.0-1, sid has 1.2.0-2
<janimo> mjg59 ping
* sivang wonders if the clear text problem with cdebconf had alrready been fixed.
<Seveas> sivang, there was a security update today
<Seveas> (it only affects breezy)
<sivang> Seveas: or, for that matter, upgraded dappers?
<Treenaks> Seveas: and upgraded breezys I suspect?
<Seveas> yes
<sivang> okay, let's see if the update fixes it.
<sivang> (I'm affected)
<Seveas> I have no breezy-installed systems 
<Seveas> my laptop is a brand new dapper flight 4
<Treenaks> Oh great: http://it.slashdot.org/it/06/03/13/0525254.shtml
<Seveas> and server is a hoary->breezy
<Seveas> pitti, hi
<Burgundavia> Treenaks: we got some bad press. It happens
<Treenaks> Burgundavia: Yeah, I know
<Treenaks> Burgundavia: but still :)
<Seveas> it is quite a serious mistake
<Burgundavia> thankfully it is a local only mistake
<Seveas> tell that to the admin with a 3000+ users machine who got rooted ;)
<Seveas> (didn't hear of such a thing yet) 
<Treenaks> Seveas: weren't you adminning a cluster of Ubuntu boxes? :)
<Seveas> still hoary
<Seveas> and /var/log/*installer removed
<Seveas> If dapper isn't delayed too much it'll be a dapper cluster in june
<spacey> good thing my users are retards
<spacey> :P
<Treenaks> spacey: Real ones, or just children? :)
<spacey> mostly children :)
<pitti> Hi Keybuk 
<ploum> hello
<ploum> I just saw the p-6 weeks delay proposed by sabdfl
<ploum> As a lot of "normal users" that I know are waiting for Dapper in april. They are already talking about
<ploum> I just have an idea
<seb128> ploum: hey ploum
<ploum> hello seb128 :-)
<seb128> ploum: want a "public" first version and a corporate then? :)
<ploum> indeed :-)
<ploum> but I didn't follow the discussion
<seb128> Mandriva does (did?) it that way no?
<ploum> so I suppose someone had it
<Keybuk> hey berpitti
<chmj> winkle: 7
<ploum> seb128: I really don't know much about mandriva
<seb128> ploum: people can as well install a flight-n
<ploum> seb128: the "flight" name is quite "experimental"
<seb128> ploum: right, but in case we have a delay that's not make things extra stable ... calling the first version "dapper" would be as misleading
<ploum> I was thinking that a first "public" release would allow a wide testing
<ajmitch> ploum: we also have a beta release coming up
<ploum> my first idea was : "We must do everything as usual then, after the release, take an extra 6 weeks of bugs squashing"
<seb128> ploum: we have a candidate 1 month before version usually
<seb128> there no need to have 2 differents candidate
<Keybuk> seb128: has the Debian menu deliberately appeared again?
<seb128> Keybuk: you probably installed menu-xdg?
<ploum> where is the discussion about this ? I didn't saw anything on ubuntu-dev list (but there is a lot of noise so I perhaps missed it)
<seb128> ploum: there is no discussion about that atm
<Keybuk> seb128: gnome-panel depends on it
<seb128> ploum: but there is no 6 weeks delay atm neither
<Keybuk> or something else did
<seb128> Keybuk: no it doesn't
<Keybuk> how did it get installed then?
<seb128> Keybuk: but it "Recommends" it ... you can argue it should be changed to "Suggests" for Ubuntu
<ogra> hey gang
<seb128> Keybuk: you use something installing Recommends for you?
<Keybuk> I use aptitude
<seb128> Keybuk: which does install Recommends for you :)
<Keybuk> right, because it's supposed to?
<seb128> Keybuk: yeah, what I said, it should probably be changed to Suggests for Ubuntu
<seb128> Keybuk: but I don't think the situation is new
<seb128> hi mdz
(mjg59/#ubuntu-devel) jono: Does the disks manager not let you?
(mjg59/#ubuntu-devel) I have "Access Path" and the ability to change it
<seb128> it's not persistant change
<seb128> ie: doesn't change the fstab
<mjg59> Oh. That sounds like a bug.
<seb128> <seb128> there is a bug open about that
<mjg59> Yes, I should read more closely
* jono thwacks mjg59 in the chops
<jono> :)
<jono> would be nice if the installer could pick up on other partitions and automatically create the mount points
<seb128> jono: we can try to fix it for dapper but a patch would be welcome :)
<seb128> all the windows partitions should be installed to fstab at installation imho
<jsgotangco> well it does mount /dev/hda1 (windows) when it sees it 
<jono> seb128, would love to if it werent for the fact that all my C has dripped out the side of my head and been replaced with python and visions of grandeur
<seb128> many users expect to get datas from there
<jsgotangco> the only bug is that when its ntfs
<jsgotangco> (with breezy)
<seb128> jsgotangco: no it doesn't
<jsgotangco> huh?
<seb128> jsgotangco: or at least the liveCD doesn't
<ogra> jono, hey, if we postpone dapper you'll hav eenough time to refresh your C skills ;)
<bddebian> heh
<jono> ogra, I honestly wish it worked that way :P
<ogra> heh
<jono> thanks chaps
* jono gets back to writing
<pitti> arrgh, dapper kernel breaks capabilities
<mjg59> I clicked on the irritating lightbulb in openoffice and it crashed
<mjg59> Or, rather, froze
<mjg59> Best. Software. Ever.
<mjg59> So when openoffice says "recovery succesful", what does it actually /mean/?
<ogra> that it feels better now ? 
<ogra> seb128, gnome-screensaver:
<ogra> checking for X11/extensions/XScreenSaver.h... no
<ogra> checking for X11/extensions/scrnsaver.h... no
<ogra> checking for X11/extensions/xidle.h... no
<ogra> any idea why we dont use these ?
<seb128> because we lack some Build-Depends maybe?
* ogra tries to add them for test
<ogra> seb128, yes, i'm just wondering why :)
<ogra> might probably solve one or the other bug :)
<fabbione> ogra: you lack a bunch of B-D :)
<fabbione> not just some
<ogra> yep
<sivang> hrm
<mjg59> ogra: It says that it's recovered them, but doesn't actually /show/ them to me
<ogra> the fun is it compiles fine without them ... maybe thats why nobody ever noticed :)
<sivang> breezy fales to correctly setup Xorg on this new AMD64 X600 RADEON machine..
<sivang> failes, even
<ogra> mjg59, hmm, i always see them listed ... (which often doesnt help kbecause the doc crashes immediately again)
<Fawzib> sorry about asking here but don't know where else to ask. How can I start a 'server-expert' install with the new menu in Flight 5?
<Seveas> Fawzib, #ubuntu is for support (and the menu has an 'Install a server option')
<ogra> yay, finally the right dots in the unlock dialog 
<pitti> mdz: I fixed leases file rewriting in dhcp3 for breezy (bug 26645) by backporting a dapper patch (pretty easy one); can you please approve/deny it?
<Ubugtu> malone bug 26645 in dhcp3 dhcp3-client "dhclient prevents itself from accessing its own leases file" [Normal,Fix released]  http://launchpad.net/bugs/26645
<Fawzib> Seveas: I know asked there nobody answered, I saw the "server" but not the "server-expert" option (which is different)
<mdz> pitti: approved
<pitti> thanks
<pitti> uploaded
<sivang> pitti: how do I tell debclean or what do I need to put in the changlog so it will crate a full source (not diff) upload? My skeleton package debuild creates a diff only upload for some reason.
<sivang> pitti: s/debclean/debuild/
<sivang> pitti:(it does this although this is the first release)
<CarlFK> my daily dapper is still saving the password in -rw-r--r-- 1 root root   71797 2006-03-13 09:37 questions.dat
<dholbach> ogra: I do the gnome-screensaver update just now - if you don't mind
<ogra> i do
<ogra> because i'm reworking the buiold deps since an hour
<dholbach> the build deps?
<ogra> seems there was missing a lot and nobody noticed
<ogra> i'm nearly done 
<dholbach> configure.ac indicates no changes
<dholbach> and it builds in pbuilder
<ogra> yes, but the hack dont work right without scrnsaver.h for example
<ogra> *hacks
<ogra> checking for X11/extensions/xidle.h... no 
<ogra> ^^^ could also solve some issues to have it :)
<dholbach> ok
<Seveas> urgh, meetings are going to be a mess tomorrow
<elkbuntu> Seveas, i'm yet to attend an online meeting that isnt chaotic ;)
<Seveas> elkbuntu, this is going to be worse
<Seveas> there already are several people in #u-meeting just for that and I heard from a *LOT* more people that they were going to attend
<elkbuntu> Seveas, there's going to need to be some serious flood control
<Seveas> elkbuntu, alreday in place 
<elkbuntu> what restrictions?
<Seveas> when needed I can +mi the channel and redirect the listeners to an overflow channel where the conversation is relayed
<pitti> sivang: debuild -sa
<pitti> sivang: by default it includes the orig.tar only for the revision -1
<mdz> ogra: what is the cause of the flickering in so many screensavers?
<elkbuntu> well, i know for sure i cant come listen on the 1st one, if it's 25 hours from now. not sure about the second
<ogra> mdz, see above i think its caused by missing build deps, my prob is that i cant reproduce it here ...
<Seveas> the one in 25 hours is the second one
<sivang> pitti: many, many thanks.
<ogra> mdz, it doesnt happen on my nvidia card and i have only an ati card in my ibook, where it doesnt happen 
<ogra> mdz, does it flicker for you ? 
<pitti> ogra: it does for me on my iBook
<elkbuntu> Seveas, ooh
<mdz> ogra: it happens here and on jordi's laptop also
<pitti> mdz: can you please ack the b-updates dhcp3 upload?
<elkbuntu> the first one being closed?
<mdz> ogra: and on my desktop
<Seveas> the first one is in 16 hours
<ogra> only GL savers or all of them ? 
<jordi> mdz: which is also a ppc
<jordi> my laptop, that is
<elkbuntu> as in, restricted attendance?
<mdz> my laptop and desktop are both i386
<ogra> jordi, known fact ;)
<mdz> pitti: I have never done it before, but if it is urgent I can have a look
<pitti> mdz: oh, not that urgent; I'll ask Kamion tomorrow then
<mdz> ogra: what's a good non-GL one to test?
<jordi> ogra: aha :)
<ogra> mdz, fuzzyFlakes 
<pitti> wb carlos
<pitti> carlos: how's the import queue looking? does the backlog get smaller?
<carlos> pitti: hi
<mdz> ogra: how can I run it full-screen like xscreensaver or gnome-screensaver does?
<carlos> pitti: I'm blocked on PQM accepting my branch....
<pitti> OIC
(ogra/#ubuntu-devel) lock your screen with it selected (as long as we dont have a preview button)
<mdz> ogra: yes, it's the GL ones
<mdz> ogra: and it flickers even in the preview window
<ogra> hmm, k
<ogra> i'll check if we need a build dep on the gl headers for g-s-s even i cant imagine it helps since the GL hacks are only called by g-s-s
<ogra> it shouldnt need it ..
<mdz> ogra: do you have DRI enabled?
<mdz> ogra: what kind of graphics cards have you tested?
<jordi> ogra: so, I see hwdb-client is installed in dapper, but it has no icon at all
<jordi> does that make sense?
<ogra> ati FireGL Mobility T2e and a nvidia ...
<jordi> why isn't it in the menus?
<ogra> jordi, simplifying menus spec 
<seb128> jordi: because it's masked by default
<jordi> nod
<jordi> how do people use it?
<seb128> jordi: it doesn't make sense to the menu, it's a stuff you run one time, probably after install
<jordi> nod
<seb128> jordi: should be runned after installation probably
<mdz> ogra: both jordi's laptop and mine and my desktop are radeons
<ogra> nvidia GForce FX Go5700 to be precise
<jordi> my home box is radeon as well
<jordi> but that one does dri
<ogra> mdz, try with 2.14 if it built 
<ogra> i hope it solves some issues
<ogra> sadly libgnomeui is currently broken on ppc, so jordi wont get it yet
<jordi> oh my goooooooodness
<mdz> ogra: mvo's laptop doesn't do DRI but it doesn't flicker either
<jordi> I QUIT!!!1
<ogra> ah
<ogra> do other GL apps flicker ? 
<ogra> i.e. pinball ?
<mdz> testing
<mdz> ogra: pinball doesn't work
<mdz> ogra: but the screensavers work fine when run on their own
<ogra> hmm 
<mdz> and they are GL
<mdz> it is something to do with gnome-screensaver
<ogra> yep
<ogra> lets see if the additional build deps help ...
<mdz> ogra: do you have a test build for me?
<ogra> wait, only ppc currently...
<ogra> oh, jordi :) want a test package ;)
<jordi> ogra: shure
* ogra scp's
<jordi> mdz: omg, ogra is also h4x0r1ng me
<ogra> http://people.ubuntu.com/~ogra/gnome-screensaver_2.14.0-0ubuntu1_powerpc.deb
<ogra> jordi, ^^
<dholbach> mdz: thanks for libgsf review, uploaded.
<ogra> mdz, i have dri loaded as well here on the ati/ppc and dont see any flickering ...
<ogra> as well as on the amd64/nvidia lappie
<jordi> so this fixes two in one I guess
<jordi> the suspend thing and the flickery
<jordi> lets find put
<jordi> out e ven
<jordi> damn
<ogra> ??
<ogra> youre speaking in foreign togues :)
<mdz> seb128: did you hear anything back about that X cursor problem?
<seb128> mdz: no
<mdz> seb128: is it in malone?
<seb128> yeah
<mdz> seb128: needs to be fixed for dapper
<mdz> what's the bug#?
<seb128> https://launchpad.net/distros/ubuntu/+source/xorg/+bug/27589
<Ubugtu> malone bug 27589 in xorg "X default cursor is displayed instead of the Human Theme one." [Normal,Unconfirmed]  
<seb128> and I've already targetted it for dapper for some time
<fabbione> seb128: does the problem happen only with the human theme?
<seb128> fabbione: no, it just doesn't use the alternative
<fabbione> ok
<fabbione> oh well.. i will get to X one century or another..
* fabbione goes offline for the day
<seb128> fabbione: I talked a bit about it with daniels the afternoon he was at UI sprint
<seb128> he thinks that's a xserver-xorg bug and tried to track it quickly but with no luck...
<fabbione> seb128: i am pretty sure it's just a missing patch from breezy -> dapper
<seb128> could be
<fabbione> if you know where this x-cursor-theme alternative was and is now..
<fabbione> it should be easy to track
<seb128> right, it's on my list for dapper
<seb128> but so many bugs ... I'll come to it, but later :)
<fabbione> ehhe
<fabbione> i also have a liboil and gst bug for you..
<fabbione> but first i need to see if i can handle you something with a patch
<seb128> liboil? there was some issue due to see code, slomo has uploaded without see for now
* fabbione goes offline for real
<seb128> is that the same?
<sivang> fabbione: do you of anything that would prevent breezy from setting out of the box an ATI X600 on a AMD64 machine? there seems to be a duplicate symbol on one of the libs Xorg needs.
<seb128> see you fabbione
<sivang>  fabbione symbol is rol_long
<seb128> SSE rather
<fabbione> sivang: noidea..
<fabbione> sivang: fix it and send me a patch? ;)
<fabbione> me must go really now
<fabbione> bye
<sivang> fabbione: okay :)
<sivang> fabbione: laters!
<jordi> ogra: hey, it doesn't suspend while typing after suspend anymore!
* sivang arghs as the open source driver is also no go :-(
<ogra> jordi, great :)
<jordi> because IT CRASHES badly after suspedn :P
<ogra> :P
<ogra> jordi, mdz already forwarded the error :)
<jordi> its cool, huh
<ogra> its strange ...
<ogra> i got it running here
<mdz> ogra: are you sure you are using the same gnome-screensaver that we are?
<ogra> heh
<mdz> ogra: if not, please upload yours; it sounds better :-P
<ogra> i'm running the one jordi just downloaded
<ogra> i guess it needs some dependency tightening ... :(
<ogra> jordi, did you kill the old gnome-screensaver process properly after installing ? 
<mdz> ogra: he logged out
<ogra> k
<jordi> if that didn't kill it its another story
<ogra> that would have killed it 
<ogra> jordi, yous system is up to date ? 
<ogra> *your
<jordi> I beleive
<jordi> let me see
<jordi> well
<jordi> the Packages file in dapper changes every 20 seconds
<ogra> heh
<jordi> ok, Ive got a few for update now
<ogra> complain at the gnome team :)
<jordi> libpango, libgnomecanvas, libvte, scim
<ogra> libgnomeui by chance ? 
<jordi> nope
<jordi> I mean
<jono> should rhythmbox display an ipod if it is plugged in ?
<jordi> they will
<jordi> but it seems only the arch:all packages are avaliable
<jordi> not the ppc binaries yet
<ogra> yep
<jordi> S'han mantingut els segents paquets: libeel2-data libgnome2-common libgnomeui-common
<jordi> ^^ held packages
<ogra> hmpf .
<ogra> ..
<jordi> you think the crash is related to that update?
<seb128> jono: it does list it yep
<ogra> jordi, i think the crash is related to a loose dependency we need to tighten ...
<jono> cheers seb128 
<ogra> i have no idea why it runs flawless for me 
<jordi> nod
<jordi> ogra: cuz you cheat
<ogra> on the other hand i have never had any of these issues you have
<jono> and if I plug in a digital camera, does pop up the dialog box asking to get photos from the camera?
<jono> this stuff is difficult to test in vmware :P
<seb128> jono: yep, it does that too
<jono> :)
<jono> seb128, I assume it still loads gthumb right?
<seb128> correct
<jordi> Kamion: ping
<jordi> seb128: what's the status of mono+ubuntu?
<seb128> jordi: some apps are main, some other universe
<seb128> jordi: but better to ask slomo or tseng or ajmitch about it
<jordi> fspot looks like a candidate to replace gthumb :)
<seb128> yeah, I would have liked to get that for that cycle ... for next cycle probably
<Amaranth> jordi: we need a super-magical compression technology to fit it on the CD
<ogra> Amaranth, we just need to convince the industry to switch to 900MB CDs by default :)
<Amaranth> heh
<Amaranth> or drop other things from the CD
<Keybuk> . o O { OpenOffice {
<Mithrandir> Amaranth: be careful about what you ask for. ;-)
<Mithrandir> we could just put all the debs on the cd in a squashfs fs.
<ogra> we could drop alacarte to make some room :P
<Amaranth> i thought we did
<Amaranth> ogra: 100kb doesn't save much :P
<ogra> Amaranth, squashfs -> only on the liveCD
<Amaranth> ah
<hunger> Can I use usplash to get user input (passphrase for HDD) with dapper?
<Keybuk> no, usplash has no user input functionality
<Chipzz> hrrm
<Chipzz> would be nice :)
<hunger> OK, then I'll stick with my turn-it-off solution:-)
<hunger> Chipzz: There was talk about adding such functionality when usplash was first implemented. Let's hope someone will really need it (and do the work;-)
<Keybuk> "Patches Welcome"
<Keybuk> hunger: sounds like you really need it ;)
<hunger> Keybuk: As always;-)
<hunger> Keybuk: Nope. I do not have usplash installed:-)
<hunger> Keybuk: I was just wondering whether I need to update the init-script I attached to a bug.
<ogra> mdz, http://people.ubuntu.com/~ogra/gnome-screensaver_2.14.0-0ubuntu1_i386.deb in case the buildds take *another* hour until it shows up
<ogra> (sorry it took so long, i had to create a x86 pbuilder first)
<ogra> but i'm still faster than LP :P
<ogra> mdz, ah, now it hit the archive as well ...
<LaserJock> are failed builds retried automatically by soyuz?
<pitti> LaserJock: only if they fail because of missing dependencies
<LaserJock> pitti: so do I need to upload a buildX to get it rebuilt
<ogra> nope
<ogra> poke a buildd admin
<LaserJock> infinity | lamont : can I get supercollider given back? thanks.
<Bicchi> Dapper is based on software from Debian (etch or sid). Which one testing/unstable ?
<Amaranth> sid
<Bicchi> So it will allways pull from unstable ?
<dholbach> Bicchi: unstable = sid, etch = testing
<dholbach> Bicchi: and that's more of a #ubuntu question
<ogra> Mithrandir, can you test the suspend issue with the new g-s-s from the archive  ?
<Mithrandir> ogra: not now, please remind me tomorrow
<ogra> yep
<jordi> Kamion: let's chat tomorrow, or when you're back, of espresso translation.
<GFDL> in dapper (updated today):
<GFDL> xrdb -merge .Xresources
<GFDL> Predefined macro file '/usr/lib/gcc/i486-linux-gnu/4.0.3/include/mcpp_gcc40_predef_old.h' is not found
<GFDL> Predefined macro file '/usr/lib/gcc/i486-linux-gnu/4.0.3/include/mcpp_gcc40_predef_std.h' is not found
<GFDL> .Xresources file get's merged OK though
<GFDL> s/get's/gets
<mdke_> Riddell, ping?
<LaserJock> lamont: ping?
<mdke_> Riddell, leaving a /query
<ulaas> hi. is XGL broken or working.?
<Amaranth> ulaas: #ubuntu-xgl
<ulaas> Amaranth: right ;) danko
<Tm_T> ulaas: even when it's broken, it can work
<arp> nautilus, libeel, libeel-data and nautilus-cd-burner still broken with ppc?
<seb128> no idea, what about just trying if you have a ppc?
<seb128> and filling a bug if required
<ploum> hello
<ploum> did anyone notice the problem with cups ?
<ploum> the file /var/log/cups/access_log was 1,5Go on my computer !
<ploum> it seems that cups print the line :
<ploum> localhost - - [13/Mar/2006:23:11:44 +0100]  "POST / HTTP/1.1" 200 72 CUPS-Get-Default successful-ok
<ploum> every 5 seconds
<ssam> arp, do you need someone to test?
<ploum> ssam: do you have this in your logs ?
<ploum> sorry
<ploum> (I think you were talking to me)
<ssam> ploum, dont worry :-)
<seb128> ploum: it's supposed to be fixed for a week or so
<seb128> ploum: maybe you just noticed
<seb128> if you drop it, does it keep happening?
<ploum> seb128: drop what ?  I restarted cups and I have a new line every 5 second
<ploum> (and I deleted the 1,5Go file)
<seb128> ah, so that still happens now?
<dholbach> night guys
<ploum> good night
<seb128> ploum: what version of cupsys do you have?
<seb128>  cupsys (1.1.99.b1.r4929-0ubuntu3) dapper; urgency=low
<seb128> ...
<ploum> seb128: yes. Fully-distupgraded from today. But I must maybe reboot
<seb128>    * Add debian/patches/51_dont_log_ipp_printer_query.dpatch: Do not flood
<seb128>      access_log with successful CUPS-Get-Printers and Get-Printer-Attributes
<seb128>      queries (which are generated by gnome-cups-icon every 3 seconds). This is
<seb128>      a hideous and hackish patch, but it has to do until we dbusify cupsys
<seb128>      properly. (Malone #29895)
<Ubugtu> malone bug 29895 in cupsys "same action is repeatedly logged" [Major,Fix released]  http://launchpad.net/bugs/29895
<ploum>  1.1.99.b1.r4929-0ubuntu4
<seb128> ploum: that doesn't tell me if the buildd has buitl it, etc
<seb128> ploum: when people ask for a version that because they want the version :)
<seb128> ploum: yeah, should be fixed
<seb128> ploum: ping pitti tomorrow about it
<seb128> or comment on 29895
<ploum> seb128: thanks. I will add a comment to the bug
<seb128> thank you
<ploum> ok, I'm not alone
<ploum> good night all :-)
#ubuntu-devel 2006-03-19
<robertj> would it be too late to get Wesnoth added to gnome-app-install?
<robertj> oh doh, it's already there under "Battle for Wesnoth"
<robertj> <blush />
<LaserJock> robertj: glad we could help ;-)
<nictuku> -)
* Burgwork waves the retroactive feature request wand
<LaserJock> those are my favorite bug fixes
* robertj goes off to file & resolve the bug on launchpad
<Burgwork> robertj, generally, if it has a .desktop file, it should already be in g-a-i
<Burgwork> robertj, what would be great is to find things that don't have a .desktop file and file a bug for those
<Burgwork> preferably with a .desktop in the bug
<robertj> yeah, I wonder if Wesnoth 1.1 should be shipped w/ dapper, it's a development release and online multiplayer doesn't work
<robertj> whereas 1.0 is stable and has online multiplayer
<Kyral> hmm
<Kyral> how wanted is an easy setup for Xen in Dapper?
<Burgwork> Kyral, not likely for dapper, but dapper+1
<Kyral> Yah I should have said in general lol
<Burgwork> Kyral, as we are too late into freeze
<Burgwork> but yes, Xen would be great
* Kyral has been obsessed with Xen recently, hence his lack of Ubuntu work
<Burgwork> somebody did some work for SoC
<Kyral> Yah
<Kyral> Ed Despard
<Kyral> he went to my university :P
<Kyral> We had his server around in the COSI until recently
<LaserJock> hmmm
<Kyral> I guess I could start by writing something for the Wiki (my domain azuredreams.us runs on XenBreezy)
<infinity> LaserJock: Giving it back isn't going to help, it needs some scons abuse love first.
<LaserJock> infinity: yeah, slomo told me about that
<LaserJock> infinity: is that in the works?
<Mez> jdub: ping
<Mez> jdub isnt here
<Mez> hmm
<Burgwork> Mez, he was active in gnome-hackers on gimpnet not 5 minutes ago
<jdub> Mez: pong (geez, give me a second at least...)
<Mez> oh hey jdub :D
<Mez> didnt see you there :d
<Mez> It's not showing you in /names
<Mez> jdub: is it me - or does it seem a bit wrong to be able to - with the default ubuntu setup have the word "bullshit" appear in huge letters on your screen?
<Mez> (and quite possibly in the edubuntu default install too - havent tested that yet)
<jdub> if you gave me some context, i could probably answer
<infinity> LaserJock: I'll sort it today.
<Mez> jdub: context
<Mez> you're sitting there nicely doodling on a pad next to your computer 
<LaserJock> infinity: oh cool. Thanks.
<Mez> the screensaver kicks in and you see the words "wave your bullshit wand with me" scrolling across the screen
<jdub> if you're saying that planet ubuntu shouldn't be used as the RSS source for the screensavers, i agree.
<jdub> i dunno why you're asking me though.
<Mez> jdub: is that where it came from?
<jdub> sounds like a worthwhile bug.
<Mez> jdub: didnt know it was getting it from planet
<jdub> and i'd suggest using the fridge instead.
<Mez> but it jsut severly f**ked up a presentation :D
<Kyral> Actually I should email Jeff about linking in my blog to Planet
<jdub> please do - planet ubuntu is a bit slow ;-)
<Mez> jdub: I only asked you as your name appeared next to it
<Mez> I didnt know it was getting it from planet
<jdub> ogra: ping (rss url in screensavers)
<Mez> but It's not good when trying to persuade people the ability of ubuntu to hae that scrolling across the screen on a projector ;)
<Mez> jdub: should I report a bug
<jdub> Mez: yeah
<Mez> x-screensaver?
<jdub> Mez: make sure to cc ogra on it
<jdub> yeah
<Mez> https://launchpad.net/distros/ubuntu/+source/xscreensaver/+bug/34829
<Ubugtu> malone bug 34829 in xscreensaver "RSS feed from planet" [Normal,Unconfirmed]  
<Mez> hey jdong 
<jdong> hey, mez
<jdong> Dapper's coming together quite nicely
<jdong> I've upgraded most of my systems over to Dapper
<jdong> successful upgrades, BTW
<jdong> great work, everyone
<Mez> jdong: couldnt agree more
<Mez> though - the orange ...
<jdong> Mez: it brightens up my desktop a bit :)
<jdong> and I appreciate that
<jdong> Mez: aren't you a kubuntu user anyway? ;)
<Mez> jdong: yes
<Mez> so I'm lucky
<Mez> I get blue
<jdong> HEH
<Kyral> mmm KDE...
<jdong> geez is cdimage.ubuntu.com slow
* jdong tries torrenting flight5
<Mez> jdub: oh, your blog is down
<jdub> yep
<PuppiesOnAcid> How come XChat wasn't included in Dapper Flight 5?
<Burgwork> PuppiesOnAcid, we are no longer shipping a seperate IRC client
* sivang also neesd his blog to be in planel, when he starts to write on it.
* Kyral blinks
<Kyral> "seperate"
<Kyral> wasn't XChat the default client?
<Burgwork> sivang, I want to see backup hotness
<PuppiesOnAcid> Burgwork: What'st he reason for that?  I'm just curious.
<jdub> Kyral: you can install xchat very easily
<Burgwork> PuppiesOnAcid, not enough of the user base is actuallly using irc
<jdub> Burgwork: don't confuse it by saying it like that
<PuppiesOnAcid> Burgwork: Ah, interesting.
<Burgwork> jdub, hmm?
<Kyral> jdub, I know :P
<Burgwork> that is my understanding
<Kyral> jdub, frankly I use Konversation or Irssi
<Burgwork> oh, I said seperate because of gaim
<jdub> Burgwork: that's a very confusing and roundabout way to say what we've done
<jdub> exactly
<jdub> that's irrelevant :0
<Burgwork> ok
<jdub> :) rather
<Kyral> Burgwork, you consider GAIM's lame excuse of a client an IRC Client?
<Burgwork> Kyral, it exists. It has no bearing on not shipping xchat
* Kyral falls down
<jdub> "we're not shipping a gui irc client out of the box, because it only serves the needs of a very small niche"
<Kyral> jdub, doesn't the default homepage mention IRC? (I haven't seen it in a while)
<jdub> "you can install it very easily in moments"
<jdub> Kyral: i believe that's changed
<Burgwork> Kyral, yes it does and the doc team is discussing what to do
* Kyral sighs
<jdub> (but it wasn't a hugely useful thing to say anyway)
<Kyral> oy oy oy
<Kyral> I'm just getting flashbacks to the reason why Build-Essential isn't installed by default...
<Burgwork> neither b-e or xchat is going to be used by your mother, or the guy in the next cubicle
<jdub> man, the rationale for skipping b-e is even stronger than xchat
<Kyral> Burgwork, you don't know how much crap I get from my Linux friends about the fact that they have to manually install a compiler
<Burgwork> Kyral, there are lots of other linux distros out there...
<Burgwork> plus, it really is easy to install
<Kyral> Burgwork, I know, I sometimes just get sick of the multiple jokes at Ubuntu's expense in the COSI
<Kyral> it's just venting ATM
<Burgwork> what people really want is a stable system
<Kyral> "Ubuntu is for Communists"
<HrdwrBoB> apt-get install build-essential is so head?
<jdub> Kyral: technically proficient person being teased by technically proficient people for installing something that is not of interest or use to 99% of the population is not great rationale for shipping something that is not of interest or use to 99% of the population
<HrdwrBoB> hard
<Burgwork> my boss is busy discovering what happens when you base your product on a non-stable platform (Fedora)
<Kyral> HrdwrBoB, I think its just taking cracks at Ubuntu's success
<HrdwrBoB> Kyral: it's basically old school unix people who think that things should be hard
<HrdwrBoB> and can't see a reason why you would make it easy
* sladen makes technical jdub regarding gnome-print dialogues, gnome file-dialogues ^L, gnome-screensaver configure button, .... ;-)
<Kyral> HrdwrBoB, I get that way sometimes lol
<sladen> technical jab at jdub
<jdub> sladen: actually take a jab then
<Kyral> I'm one of those idiots who gets nostaligic at doing the ./configure && make && sudo make install dance
<Kyral> who wants to do a LFS install "just to see what its like"
<Kyral> -ERANT
<Burgwork> I am not and that is why I like Ubuntu
<Kyral> Burgwork, Oh I get lazy sometimes. But I'm curious as all hell
<Burgwork> I don't call it lazy. I have a finite amount of time. I would rather spend it on more interesting (to me) things
<LaserJock> Burgwork: +1
<Kyral> Burgwork, and this is interesting lol
* sivang had the privilige to see how things evolved from sort of that way, to the out of the box way currently in dapper. this is _sweet_
<Kyral> I mean I COULD have done my webserver without Xen
<Kyral> and have it done easier
<HrdwrBoB> Kyral: I'm old and agree with Burgwork 
<Kyral> but I wanted to learn about Xen
<HrdwrBoB> I choose to spend my time on more productive things
<jdub> Kyral: different use case
<Kyral> Then again, Burgwork, you guilt trip people into packaging for you :P
<Burgwork> Kyral, I find packaging hard and baffling. That time thing again
<Kyral> lol
<Kyral> Burgwork, I know :P
<Kyral> ack! Gotta fetch the dog!
* Kyral shrugs
<Kyral> sorry for the rant lol
<Kyral> I mean I know people want things to just work. When I install my on my laptop I want it to go quick
<Kyral> (why am I using Debian Sid then...)
<Kyral> Acutally when I do that Xen thing (maybe, depends on how much time I have during he summer)
<Kyral> I plan to write a GUI for it as well
<Kyral> granted this means learning PyGTK and how to integrate it into the GNOME and KDE control centers...
<Kyral> but, more tools under my belt, more skills to go on the resume
* sivang waits for bzr to finishi pushing.
<Kyral> hey bddebian
<bddebian> Howdy Kyral
<tritium> hey bddebian
<bddebian> tritium!!!
<tritium> :)
<nate_> can someone point me to the d-i preseed file docs?
<infinity> Riddell: kde-systemsettings is FTBFS, seems to want to $DISPLAY set during the build or some such..
<robscheck> has anyone already packaged up gnash (FSF's flash player) on any of the repos?
<LaserJock> Seveas: ping?
<infinity> LaserJock: supercollider isn't 64-bit clean, it looks like.  Fails on ia64 and amd64 while trying to cast a 64-bit int to a 32-bit one (Woo, special).. Looking at a successful build on one of the 32-bit arches, it looks like the source suffers from type schizophrenia all over the place.  Fix all the warning on i386, and it'll be happy on amd64.
<LaserJock> infinity: ok, thanks for looking at it
<infinity> LaserJock: Anyhow, the buildd problem that was making it fail everywhere has been fixed, so if you fix the type issues, it'll be all good.
<dholbach> morning
<Burgundavia> morning dholbach
<Mithrandir> iz triplicate dholbach.
<dholbach> Mithrandir: :-p
<infinity> Ah-ha, just the man I was looking for.
<infinity> dholbach: gnome-applets is FTBFS on all arches, and it's ALL YOUR FAULT.
<infinity> dholbach: Or something. :)
<dholbach> infinity: merci
<dholbach> will poke it
<sivang> morning all
<sivang> Burgundavia: can I use you as a helping hand then ? :)
<Burgundavia> sivang: for which? testing?
<sivang> Burgundavia: erm, a bit of development still to go? 
<sivang> morning dholbach , Mithrandir 
<Mithrandir> hi sivang
<sivang> and former canadian infinity 
<Burgundavia> sivang: you asking me to produce actual code? That wierd stuff called "C" or "Python"? :)
<dholbach> hi sivang
<sivang> Burgundavia: ah ah ah
<sivang> Burgundavia: the less weird Python :)
<Burgundavia> you really don't want to see my python
<Burgundavia> I realized about a year ago that my talents are better suited away from code, packaging and those internal bits
<fabbione> dholbach: ping?
<dholbach> fabbione: pong
<fabbione> dholbach: i am having an issue with libgstreamer.. is there any way i can enable some extra debugging options without rebuiling?
<fabbione> (using gdb is not an option atm)
<dholbach> fabbione: what does it do/not do?
<fabbione> dholbach: it BusError on sparc when used in combination with liboil. I need to find the code in libgstreamer that does use liboil.
<fabbione> dholbach: so i am reducing the complexity of the code to get there.. and turned to be enough to call gst_init to make a mess
<dholbach> there are quite some parts which use liboil
<fabbione> dholbach: now.. i need to step trough gst_init -> gst_init_check to see where it dies
<fabbione> dholbach: it's right at initialization
<fabbione> so i don't need to get utterly crazy
<dholbach> we have *-dbg packages
<fabbione> yes and they are installed
<fabbione> but it seems there is the option to enable some extra printf?
<fabbione>   ctx = g_option_context_new ("- GStreamer initialization");
<fabbione> for example
<fabbione> how can i make that stuff to be logged somewhere?
<dholbach> checking
<fabbione> thanks
<dholbach> '--gst-debug-level=5'
<dholbach> http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines
<fabbione> ok thanks
<dholbach> thank you
<jsgotangco> lol @ Seveas
<zakame> hi all
<Mithrandir> Seveas: you might want to +o yourself to be ready to kick people to get the crowd to be quiet.
<Seveas> yeah
<jono> hey, what time is the community meeting today ?
<Treenaks> jono: now, on ubuntu-meeting
<Treenaks> jono: (1 hour ago, but still going)
<jdub> jono: but it is not random discussion. ie. ssshhh. :)
<jono> :)
<jono> so have I missed anything major in the meeting?
<jono> is the delay confirmed?
<Treenaks> jono: no, not really
<jono> ahh
<Mithrandir> jono: no, it's not confirmed and won't be decided now anyway.  There's a meeting tonight too.
<Treenaks> jono: first hour or so was summing up comments/etc
<Treenaks> jono: now sabdfl is replying
<Mithrandir> jono: read the log as posted in topic on u-m
<jono> ahhh of course
<jono> Mithrandir, cool
<jdub> ogra: suse article?
<whiprush> ogra: link pls.
<whiprush> jono: did you get my book feedback?
<jono> whiprush, certainly did, great feedback
<jono> whiprush, the chapter I wrote was a little rushed due to insane schedules, so the feedback has been really useful :)
<jono> I have added lots of new bits to it :)
<whiprush> jono: this book will rule nonetheless. :)
<jono> it will with feedback like yours whiprush :)
<ogra> whiprush, jdub printed press
<jono> can anyone make comments in this meeting or only certain people ?
<Treenaks> jono: if you have a comment, /msg Seveas 
<jono> ok
<jdub> ogra: synopsis?
<ogra> jdub, suse got a very bad article in yesterdays german "linux user" 
<ogra> essentially about missing features, missing drivers and that they didnt even make it even they postponed the release 4 weeks
<jdub> ah
<highvoltage> i'm asking here, as apposed to in meeting, has the option of having two 6.04 releases been mentioned yet, as in a 6.04 dapper, and then another 6.06 enterprise dapper?
<jdub> highvoltage: btw, nexenta has always been based on ubuntu
<jdub> highvoltage: yes, very early on, and discarded - we can't develop so many branches
<highvoltage> jdub: ok on multi-versions, perhaps i should update my blog entry... /me grumbles...
<jono> jdub, every time you say "heavy metal" in the meeting, my knees quiver with metal pride :P
<sivang> seb128: do you have any idea what ubuntu-fr are using for their content management?
<sivang> smurf: is there a possibility to have MoinMoin as it's on the ubuntu.com website installed for a loco team site?
<seb128> no
<sivang> smurf: (provided it's no longer Zope/Plone as I Understood)
<vuntz_> sivang: for the ubuntu-fr wiki?
<Mithrandir> Seveas: (re the "Never seen a CEO take the community so serious" comment)  read http://azure.humbug.org.au/~aj/blog/2005/06/07?seemore=y ; scroll down to "community". :-)
<vuntz_> sivang: or the content management for antoher page?
<Kamion> jono: my notes on the issue you raised say:
<Kamion>   * Diagnosed why partition automounting isn't working in the
<Kamion>     auto-resize case (method and acting_filesystem files not copied over
<Kamion>     to the new partman device directory). Not yet sure why or how to fix
<Kamion>     it.
<Kamion> jono: AFAIK it's only a problem in the case where you're resizing an existing Windows partition
<Kamion> jono: and it's just a bug, not a new feature that needs to be added
<seb128> Kamion: there is no automounting on the liveCD neither
<Kamion> seb128: Mithrandir had code for that; not sure what happened to it
<seb128> Kamion: people tend to be disapointed by that because usually when they use the liveCD they would like to be able to use their win partition from the box
<seb128> Mithrandir: ping?
<Mithrandir> seb128: pong
<Kamion> but that's an entirely separate problem, and not my problem ;)
<seb128> k
<Kamion> yay conflation
<seb128> Mithrandir: auto-mounting on win partitions for liveCD will happen before dapper?
<seb128> s/on/of
<Mithrandir> seb128: we could do that, sure.
<Mithrandir> just mount them all in /media should work?
<jono> Kamion, from the users perspective it would be useful if any windows partitions were detected and device icons placed on the desktop
<seb128> Mithrandir: yep
<jono> Kamion, is that a resize issue?
<pitti> I guess we could grab unmounted vfat partitions from hal and automount them
<pitti> but that would require us to change our policy wrt to that
<seb128> Mithrandir: that seems to be one of the frequent complain of people trying it on their box, they expect to be able to use their win partition (ie: have icons for them on the desktop)
<Mithrandir> pitti: the live cd can do whatever it wants to.  I'll probably chuck them in the fstab.
<pitti> Mithrandir: true
<Mithrandir> seb128: I'm wondering if we should mount them R/O or not, as IIRC, NTFS writing isn't too well supported.
<pitti> Mithrandir: hmm, since the installer already puts them into fstab by default, that should reasonably settle installs too
<jono> I think its a real showstopper for many people - you install this awesome distro graphically and then need need to hack /etc/fstab to get your windows disks to work
<Kamion> jono: Windows partitions are put in fstab already if you're not using the auto-resize thing
<mjg59> The kernel will refuse to mount ntfs partitions read/write unless you force it
<mjg59> So if they're going in fstab, they might as well go in rw
<Kamion> jono: if you know of cases where it fails to work if you *aren't* resizing an existing Windows partition, I would like to know about it
<seb128> Mithrandir: vfat RW, ntfs RO
<jono> Kamion, ahhh maybe I am wrong
<Mithrandir> seb128: agreed, but we'll get complaints about it.
<seb128> there is no other way around
<Kamion> jono: icons on the desktop aren't my problem or domain of expertise
<seb128> ntfs writting doesn't work
<mjg59> Mithrandir: NTFS write support is broken to the point where creating, removing or resizing files will corrupt the filesystem
<Mithrandir> mjg59: joy.
<spacey> jono: my ntfs disk is available in dapper, i never requested that
<mjg59> Mithrandir: But that's ok, because even if you ask to mount it rw, the kernel will ignore you
<Kamion> jono: it is possible that it's broken in cases other than auto-resize - I'm serious about wanting bug reports about that
* spacey will remove it from fstab :P
<jono> Kamion, ok, but are you willling to deal with the wrath of Susan when I install dapper on her machine and it eats the world :P
<ogra> mdz, http://wiki.debian.org/DebianEdu/LtspBoot :)
<marty> can't ubuntu have a "out-of-box-experience" dialog that asks users how they want to handle the NTFS partitions it has found.  i definitely wouldn't want NTFS write my default for atleast  6 months or more of solid testing in the wild
<seb128> marty: why asking, we just have to mount seems has readonly
<seb128> s/has/as
<jdub> marty: how would you word that dialogue such that it didn't sound like the doc in BTTF explaining how the flux capacitor works?
<Treenaks> jdub: Marty McFly?
<jdub> Treenaks: i don't think that would adequately explain the issue
<Treenaks> jdub: it does explain the BTTF experience
<whiprush> flux capacitor ... fluxing
<tepsipakki> mjg59: making ntfs show up as rw in fstab would confuse people
<marty> jdub, true true - i guess might not want to scare the natives
<ogra> jdub !!!!
<seb128> Kinnison: new g-p-m if you want to update it
<ogra> bug 34829
<Ubugtu> malone bug 34829 in xscreensaver "RSS feed from planet" [Normal,Unconfirmed]  http://launchpad.net/bugs/34829
<seb128> ogra: did you do the g-s-s update yesterday?
<ogra> jdub, calm your voice !
<ogra> seb128, yep
<seb128> k, just cleaning the "to package" list :p
<ogra> seb128, ppc ftbfs though
<jdub> ogra: hrm?
<seb128> pitti: you did do g-v-m yet?
<seb128> ogra: where do you find build logs nowadays?
<ogra> jdub, see 34829
<jdub> oh yeah
<jdub> you should totally use the fridge feed instead
<seb128> https://launchpad.net/distros/ubuntu/+builds page has logs from previous month
<ogra> https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/2.14.0-0ubuntu1
<Kamion> marty: there's no point until the kernel doesn't eat filesystems when you turn it on
<ogra> seb128, see the right portlet
<seb128> ogra: you go package by package?
<ogra> its a bit tricky to get there 
<seb128> ogra: that's not suitable when you do 40 uploads in a row :/
<ogra> seb128, its the best opportunity until the buildlog page is fixed
<jdub> ROAR sebuild ROAR
<seb128> ogra: yeah, I know that page, but I don't want to browse every single upload I did
<seb128> ogra: other is to wait for bugs, that's what I'm going to do
<ogra> seb128, i understand ... i'm not fond of the logs page either
<seb128> jdub: :)
<ogra> but there are more important LP bugs i guess
<pitti> seb128: no, sorry, but I will now
<pitti> Kinnison: hey Daniel, got a minute?
<seb128> pitti: np, before tomorrow would be nice so we have new GNOME on time :)
<pitti> alright, will do now
<pitti> seb128: before I'll do some bug triage to collect and sort all the free space notification bugs
<pitti> seb128: btw, it would be good to get fresh langpacks tomorrow, right?
<seb128> pitti: ok, they did quite some changes to it according to the ChangeLog
<pitti> seb128: right, and I'd like to sort/fix the bugs alongside 
<seb128> pitti: that would rock, we will have new GNOME in by today, perfect timing
<pitti> carlos: any chance to get rosetta data for tomorrow? or shall I build the packs the ol' way?
* pitti reenables his cronjobs 
<carlos> pitti: dapper?
<pitti> yes
<carlos> pitti: no, sorry, still fighting with our test machinery that is preventing me to move my code into production
<tepsipakki> seb128: how about malone #30384 for dapper? it's a oneliner, and fixes a bug
<Ubugtu> malone bug 30384 in gnome-session "gnome-session-save presents a gui always" [Normal,Confirmed]  http://launchpad.net/bugs/30384
<pitti> seb128: current dload-strippedtar.txt looks pretty good, thanks to your pot generation fixes
<seb128> tepsipakki: I'll have a look later but I'm not convinced it's useful and should go upstream
<seb128> pitti: do you have it somewhere? I though it was pending on pqm or something?
<seb128> pitti: you're welcome :)
<pitti> seb128: 'it'?
<seb128> dload-strippedtar.txt
<tepsipakki> seb128: well, is there another way of shutting the session down from cmdline?
<seb128> tepsipakki: no, but there is an API which should be used from programs and which works fine
<jono> do we have any further idea if the shipit CDs will just include the Live CD with espresso?
<tepsipakki> seb128: ok, but making gnome-screensaver use that certainly wouldn't cut it in time ;)
<seb128> why the heck doesn't a screensaver needs to save your session?
<pitti> seb128: it's on the usual place: http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt
<tepsipakki> classroom use: you have the screen locked for a preset time and then anyone can log you out
<pitti> seb128: that's just my script that builds a rosetta-like tarball from the buildd output
<seb128> pitti: it was not updated for some time, I though it was broken by move to soyuz or something
<pitti> seb128: right, we fixed it again
<seb128> ah, ok, I though that was pending an action from carlos in fact
<seb128> cool
<pitti> seb128: well, it wasn't exactly broken in the bug sense, it was just designed that way before
<seb128> it still has outdated datas, I guess it has missed some uploads and will update those with next upload?
<seb128> like gnumeric
<seb128> "W: gnumeric_1.6.2-0ubuntu3: 2 domains, but 0 pot files"
<Kamion> apologies for cdimage breakage today, was due to some non-g+s directories - fixed builds are in progress now
<seb128> and we have gnumeric_1.6.2-0ubuntu4 atm
<pitti> seb128: right, many tarballs weren't exported, specifically the ones between Feb 25 and March 3 (or so)
<thep> Kamion, hello from localisation sprint. I'm Thep from Thailand.
<jono> does the PC version of Dapper work on Xeon?
<Mithrandir> jono: yes.
<HrdwrBoB> yes
<pitti> hi thep
<jono> thanks
<thep> pitti, hi
* nate_ does a little dance
<thep> I'd like to check what's done for Thai environment in ubuntu installer
<thep> http://linux.thai.net/~thep/ubuntu/thai-issues.html <-- Here are summarised issues for Thai. The packaging are mostly done. But the installer concern remains.
<Kamion> thep: #  Thai environment in installer + live CD
<Kamion>     * th_TH.TIS-620, th_TH.UTF-8 locale generation
<Kamion> this one?
<Kamion> console-tools, console-data: Thai console fonts and keymap
<Kamion> presumably that too
<Kamion> the locale should be generated automatically when language-pack-th is installed, although at present only UTF-8 locales are generated
<Kamion> Thai has no translations in d-i at present
<thep> yup.
<Kamion> does Thai require combining character support?
<Kamion> are there any console fonts for it at present?
<thep> Yes.
<Kamion> yes to which? sorry I asked two yes/no questions at once
<thep> I also plan to do it after desktop tasks.
<thep> I mean, the console fonts.
<Kamion> ok
<thep> and keymap
<Kamion> it is very difficult to incorporate new installer translations after upstream version freeze :(
<Kamion> there are several dozen packages involved and all of them have to be uploaded
<thep> I see.
<Kamion> it might be easier to concentrate on espresso for now ... though the localisation framework for that isn't complete yet, which is my problem and something I have to work on RSN
<jordi> Kamion: hey dude
<thep> What is espresso?
<Kamion> thep: live CD-based installer
<jordi> Kamion: regarding espresso, I wanted to talk to you about it.
<Kamion> jordi: yes, I saw your question, but there's probably not much I can say until I get the localisation framework done ...
<jordi> mdz tells me you've tried to reuse strings from di
<Kamion> yes
<jordi> oh.
<mdz> there will be important new strings though
<jordi> is it safe to create a master-file by hand now that I can feed people with?
<Kamion> indeed, we can only reuse a subset
<Kamion> jordi: no no no no no
<Kamion> sorry
<jordi> ok ok ok :)
<Kamion> it's just not in place yet
<mdz> Kamion: what sort of work needs to be done there?
<jordi> ok, was just wondering
<Kamion> mdz: debconf escape extension so that I can put multi-line strings there
<jordi> this is planned for dapper still, right?
<Kamion> yes
<jordi> k
<mdz> Kamion: can you get Mithrandir or Kinnison cracking on that?
<Kamion> mdz: please, I've already got it mostly done, don't make me farm it out now :)
<jordi> :)
<Kamion> it would not be productive to give it to somebody else at this stage
<thep> Regarding XKB setup, it's done in xserver-xorg, right?
<Kamion> thep: yeah
<thep> I remember debian's xorg left some incomplete default for Thai keymap
<thep> Just not sure about ubuntu
<thep> The default keymap should be the combined us,th
<Kamion> th isn't in the list at present
<Kamion> console-data support is a prerequisite for that
<Seveas> mdz, sabdfl, ping
<Kamion> because xorg calculates the default XKB setup from the console font selected by d-i
<thep> Oh, so, I need to do console-data, anyway.
<soumyadip> Kamion, can you spare a couple of minutes ?
<thep> s/I/we/
<Kamion> soumyadip: not lots - what's it about?
<soumyadip> Kamion, well I'm facing a problem with font selection for Bengali in Firefox
<pitti> soumyadip: can you please open a bug about it against firefox?
<mdz> Seveas: ?
<soumyadip> Kamion, for Bengali the default font is Freeserif
<soumyadip> pitti, well I'm not sure it is a Firefox bug
<pitti> mvo: ^ this might be sth for your spring
<pitti> sprint, too
<thep> Actually, I used to patch debian's old version of console-data and console-tools. Just need to update the patches.
<pitti> soumyadip: mvo is currently on an l10n sprint with some Asian guys, maybe they can work that out?
<soumyadip> Kamion, for all other languages like Hindi, Tamil, the appropriate fonts from ttf-indic-fonts is substituted
<soumyadip> pitti, which channel ?
<pitti> mvo? ^
<mvo> #ubuntu-l10n
<soumyadip> ok mvo 
* soumyadip taking the firefox Bengali discussion to #ubuntu-l10n
<Kamion> soumyadip: sorry, I really don't know anything about X font configuration
<Kamion> thep: happy to take such patches
<soumyadip> Kamion, ok, I'm talking to the people on #ubuntu-l10n
<thep> Kamion, will do it soon in this sprint.
<ogra> Mithrandir, could you check the g-s-s suspend issue during the day ? 
<jono> is there any docs anywhere which dictate how a server install differs from a normal install ?
<Mithrandir> ogra: I haven't seen it affect me today, but I could kill g-p-m and see if that "fixes" it.
<ogra> heh
<ogra> but that sounds promising ...
<Mithrandir> ogra: if I yell at you in five minutes, it's still broken. :-)
<ogra> so i'd have at least one bug squashed with the last upload, seems the flickering still happens
<ogra> *sigh*
<Kamion> jono: /preseed/server.seed on the CD images
<jono> Kamion, cheers
<mdz> ogra: any news on the gnome-screensaver flickering?
<ogra> mdz, only that its still there 
<ogra> at least according to the people on the bugs ...
<ogra> but i hope i have the "ignores input after suspend" bug fixed 
<ogra> (waiting for feedback)
<sladen> ogra: I'll test it now
<Seveas> Meeting Summary done - mail sent to devel/users/sounder lists. 
<mdz> ogra: jordi should be able to confirm
<ogra> mdz, i know the flickering is still there, i have several bugs where people confirmed ...
<ogra> having one of the two majors fixed would already be cool though ...
<elkbuntu> i'm about to restart x or reboot, which would youse prefer for testing purposes ;)
<sivang> any X experts aroud to debug an X600 ati Xorg problem with breezy on a brand new AMD64 machine?
<sivang> (I reckon it's more then the average user problem, that's why I'd ask here)
<fabbione> Kamion: do you have 2 minutes to do a couple of override magic tricks for me?
<elkbuntu> everyone seems mostly absent or very busy with other things at the moment sivang
<janimo> sivang, what probem
<janimo> lockup?
<janimo> pci id of card?
<doko> Kamion, ogra, pitti: please could one of you check #34884 on powerpc, first without upgrading?
<Kamion> fabbione: sure
<ogra> bug #34884
<Ubugtu> malone bug 34884 in Ubuntu "crash when opening oo.o" [Normal,Unconfirmed]  http://launchpad.net/bugs/34884
<fabbione> Kamion: great!.. libc6-sparc*
<fabbione> Kamion: i did seed them as you asked into minimal.. i think i have done it properly
<fabbione> Kamion: but they still don't get installed by default..
<sivang> janimo: looks like pci id of card
<sivang> janimo: and duplicate symbol problem when using the open source driver
<fabbione> Kamion: do you need to also change the overrides somewhere else?
<janimo> what is the pci id of the card? :))
<ogra> doko, starts here, but i'm pretty outdated with my system
<fabbione> Kamion: note that i did use netinstall 
<Kamion> fabbione: I can't change priorities yet - tool problem
<janimo> sivang, fresh breezy install fails to start X, gives SIGILL or similar?
<Kamion> fabbione: your packages are on the list at http://people.ubuntu.com/~cjwatson/jessica.txt, but I just can't process them yet
<fabbione> Kamion: ah ok.. do you want me to remind you or will it autohappen?
<fabbione> Kamion: ah ok :) thanks
<ogra> doko, still using 2.0.1-0ubuntu3
<sivang> janimo: fails to start X
<janimo> sivang, there's an old bug open even from bugzilla times on this X600 issue
<janimo> set option NoAccel true in xorg.conf under Device section
<sivang> janimo: let's see, why aren't we fixing it ? :)
<sivang> janimo: /me checks 
<janimo> sivang, cause it's breezy
<fabbione> sivang: because you didn't provide us a patch yet?
<ogra> doko, for the upgrade i'll have to wait until DSL is back, i'm currently on ISDN ... (ETA 17:00)
<janimo> fabbione: there was a patch actually but this did not make it to breezy updates after all
<sivang> fabbione: indeed, true :)
<fabbione> and it probably doesn't even apply anymore
<fabbione> sivang: well check and see if it fixes the problem
<janimo> fabbione: for breezy it applies, the problem is not in dapper
<janimo> fabbione: he'd need to rebuild xorg for that :)
<fabbione> janimo: so ?
<sivang> fabbione: what do you mean " doea not apply?" , not trying to bug, just trying to understand :)
<fabbione> it doesn't take long
<janimo> there are i386 debs attac hed to the pacth but no amd64 ones
<janimo> fabbione: but it takes knowledge
<sivang> fabbione: I need to pull out also Xorg build macros or something, I missed those when I tried to fix the Xgl rgb.txt path bug.
<fabbione> janimo: you joking?
<fabbione> janimo: apt-get source && patch && apt-get build-dep && dpkg-buildpackage
<fabbione> janimo: what knowledge do you need to do that?
<ogra> and dpkg -i :)
<janimo> fabbione: no I am not. telling users to rebuild iis not a solution to fixing bugs :)
<fabbione> janimo: sivang is not a noirmal user
* sivang blushes
<fabbione> janimo: otherwise i wouldn't asked
<janimo> otherwise there would be no need for buildd, just source packages in the archive
<janimo> fabbione: sivang said he's got a friend with the problem
<janimo> skill may not be transmittable over phone for instance ;)
<fabbione> janimo: and i give sivang the extra hint to start debugging it himself...
<fabbione> also.. if that's the case he shouldn't be asking here..
<janimo> fabbione: ok
<janimo> fabbione: btw is there a mechanism when generating xorg conf to tailor it to specific cards, with blacklisting and such
<janimo> say if a pci id is known to behave bad with dri not put a dri option in xorg.conf?
<janimo> in the ubuntu install obviously
<fabbione> janimo: somehow...
<janimo> details? source pkg?
<fabbione> x-common or xorg-common iirc
<elkbuntu> why is there 2 different screensaver preferences dialog things in the system -> preferences menu?
<ogra> elkbuntu, because you have xscreensaver installed... remove it ... as the upgrade tool does if you use it :)
<Robot101> ogra: I discovered that this not-detecting-activity bug only happens when on battery power
<elkbuntu> ogra, i've been upgrading, i upgraded about half an hour ago...
* Treenaks pokes Gnome bugzilla
<ogra> elkbuntu, with the distro upgrade tool from mvo's repository ? 
<ogra> Robot101, does it still happen for you with 2.14 ?
<elkbuntu> ogra, uh i did, sudo apt-get dist-upgrade, what is this tool?
<Robot101> ogra: aha, let me upgrade
<ogra> (there was a patch upstream that should have solved it)
<ogra> and since Mithrandir didnt yell at me it seems its at least fixed for him :)
<elkbuntu> ogra was that to me or Robot101?
<ogra> elkbuntu, to Robot101 
<Robot101> ogra: hm, ubuntu-desktop seems to dep on xscreensaver-{data,gl}
<Robot101> does gnome-screensaver use them?
<ogra> Robot101, thats fine, they holde the hacks
<ogra> yup
<Treenaks> is gnome bugzilla slow, or is it just me?
<ogra> elkbuntu, see the ubuntu-devel mailing list, the tool is announced there anywhere
* elkbuntu is not a fan of mailing lists
<ogra> elkbuntu, thats where development coordiantion happens :)
<elkbuntu> is this distro upgrade tool very recent?
<ogra> its developed in the dapper dev cycle
<elkbuntu> the dev mailing list archives are not displayed on the forum?
<ogra> nope
<ogra> (afaik)
* ogra never reads forums
* Treenaks kicks gnome bugzilla
<Treenaks> Internal Server Error
<elkbuntu> hehe, where can i see archives of the list then?
<ogra> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<ogra> sladen, wow, thanks a lot for that summary ... i'll look into it
<elkbuntu> ogra, i'm not sure this is making a difference since my system is already at up-to-date dapper...
<elkbuntu> actually, i rephrase, this is not making any difference. both screensaver things are still there
<ogra> just uninstall xscreensaver... the upgrade tool would/should do it for you if you use it
<Robot101> did anyone start hacking on sending dbus messages over X?
<Robot101> I remember someone talking about it here...? Mithrandir?
<Robot101> ogra: do you know of any dbus/X crack?
<Mithrandir> Robot101: I've pondered doing it, yes.
<Mithrandir> Robot101: it should be easy enough to do
<sivang> janimo: this settings should work only with fglrx or ati FOSS driver?
<janimo> sivang: ati for sure don't know about fglrx
<janimo> but the UI will be very slow
<janimo> so probably use fglrx for the moment
<sivang> janimo: okay, I'll try.
<ogra> Robot101, we'll need it for ltsp local device support, which was postponed to dapper+1
<Robot101> ogra: people are discussing it in #dbus atm
<ogra> cool, so we might get it for free in dapper+1 :)
<nate_> ok, time to annoy you guys now
* ogra is out for 2-3h
<ogra> bbl
<Mithrandir> Robot101: fsvo discussion.  It seems quite slow.
<Robot101> Mithrandir: well, we kinda discussed it already.. 
<Mithrandir> care to drop me the log?
<zul> heylo
<Robot101> Mithrandir: http://pastebin.com/601334
<Mithrandir> Robot101: cheers
<Mithrandir> Robot101: ok, so not much interesting really, more "would it be possible".
<Mithrandir> Robot101: I'm not sure what to use for the actual communication, pondering X properties, but that's evil too.
<Robot101> Mithrandir: if we are going to talk about it --> #dbus :)
* sivang args as NoAccel doesn't help, wonders where is the bug report.
<thep> Kamion, Thai patches for console-tools and console-data are done.
<Kamion> in malone?
<thep> http://linux.thai.net/~thep/ubuntu/debs/
<thep> source is under source/*
<thep> console-tools is patched for Thai keysyms.
<thep> Then, console-data provides the keyboard layout based on the keysyms. So, it also recommends the corresponding version of console-tools
<bddebian> Hey folks.  I'm trying to install Flight-5 server install on a Compaq Proliant ML350 and I get the following:  ACPI:  Looking for DSDT... Not found!  And it's hung.  Any ideas?
<Kamion> mdz: second iteration of debconf escape patch checked in upstream - just asking joeyh to re-review it now
<tseng> Kamion: hm gtk-sharp didnt get demoted
<Kamion> tseng: hm I didn't get round to it
<tseng> Kamion: no problem.
<mdz> Kamion: ok
<Kamion> tseng: I have to go to the hardware store 
<Kamion> just now, but I'll look when I get back
<doko> Mithrandir, Kamion: booting on powerpc, I get a kernel panic: RAMDISK: ran out of compressed data
<doko> up to date dapper
<tseng> Kamion: hey, thanks alot.
<Mithrandir> doko: cd boot?
<doko> Mithrandir: no, just updated an existing installation
<Mithrandir> doko: hmm, sounds like your initramfs is broken, then
<doko> Mithrandir: which script does create the initramfs? from which maintainer script?
<CarlFK> doko: does PPC have something like ramdisk_size=16098?
<Mithrandir> doko: update-initramfs, the kernel
<ogra> doko, postinst of linux-image-$(uname -r) calls update-initramfs
<ogra> iirc
<doko> Mithrandir: hmm, the script doesn't check for file system full?
<Mithrandir> doko: no idea.
<nate_> dapper....upgrade...taking....forever
<Mithrandir> doko: (I have no idea why you're asking me; I haven't hacked those scripts at all, it's infinity-land)
<ogra> doko, youre a dev, youre supposed to have enough diskspace :P
<jsgotangco> lol
<CarlFK> I think middle click isn't working on yesterdays dapper.
<pitti> Keybuk: hi
<pitti> Keybuk: is there a modern counterpart for /proc/bus/usb/devices? or just pick the devices out of sysfs manually?
<pitti> Keybuk: gnome-pilot is currently broken (bug 25653), and changuing /proc to /dev is not a biggie, but it reads /p/b/u/devices, too
<Ubugtu> malone bug 25653 in gnome-pilot "Synchronization with Palm Zire31 not working." [Normal,Needs info]  http://launchpad.net/bugs/25653
<bddebian> Heya tseng, long time no "see"
<tseng> bddebian: yeah really
<sladen> ogra: it now fades out (1second) and then immediately jumps back to the desktop and 0.1 seconds later the g-p-m adjusts the backlight brightness
<ogra> sladen, but you dont have constant screensaving approaches after you unlocked it ?
<ogra> i.e. it cares for user action ? 
* sladen now gets the 10second fade just as you typed that
<sladen> ogra: bollocks does it
<ogra> hmm
<ogra> Mithrandir ?? ^^
<Mithrandir> ogra: no, I haven't seen it today.
<ogra> good ... so one special case less :)
<sladen> Ooooh, 10second-fade.  Flash to full desktop.  1second-fade, flash to full desktop, g-p-m backlight adjustment ...it keeps getting better
<Treenaks> sladen: the crack is kicking in?
* ogra doesnt even see the flash here ... 
<ogra> i'v seen it on other systems though
<ogra> i wonder whats so spethial about me that i dont encounter *any* of the bugs i get reported
<sladen> ogra: if it's any consolation, it is happening /less/ today.  eg.  I didn't get anything until 5minutes ago
<sladen> I like the flash is the gamma is being ramped down to zero, the action being cancelled (by $something) and then being reverted to normal gamma, followed the power-manger lowing the brightness
<sladen> s/I like/I think/
<ogra> yeah, the power manager should just grab the value the user has set and store that 
<ogra> i see the dimming in the lock screen though ...
<ogra> finally one bug i can reproduce
<ploum> seb128: is this chan a good place to talk ? ;-)
<seb128> ploum: no
<seb128> ploum: try #ubuntu-desktop rather :)
<highvoltage> Znarl: i can't ping to outside from humboldt, i created a ticket for this in RT, is that OK?
<Znarl> highvoltage : humboldt does not respond to ICMP, firewall restriction.  Is that a problem for you?
<highvoltage> Znarl: nope. the problem is that i can't wget http://drupal.com/file from humboldt
<pitti> Kamion: can you please ack dhcp3 for breezy-updates? (bug 26645, ack'ed by mdz)
<highvoltage> Znarl: so i tried to ping drupal.org and ubuntu.com FROM humboldt, and it didn't work
<Ubugtu> malone bug 26645 in dhcp3 dhcp3-client "dhclient prevents itself from accessing its own leases file" [Normal,Fix released]  http://launchpad.net/bugs/26645
<highvoltage> Znarl: it worked before, so i assumed something wasn't right?
<Znarl> highvoltage : /msg-ing you.
<highvoltage> Znarl: ok
<Kamion> I wish mdz would learn how to work soyuz instead ;-)
<Kamion> I'll look at it now
<Kamion> pitti: done
<pitti> thank you
<desrt> it's funny.  i look at my /ignore list in irssi
<sivang> rehi all
<desrt> it contains 4 items.  all of them are lilo as freenode has changed its hostmask format policy of the week
<CarlFK> yesterday's dapper install - the middle button on my ps2 mouse isn't working, middle on a usb mouse does. - ps2 middle click on a link in FF doesn't do anything, usb opens link in new tab.  ps2 mouse on an older box works fine.  this isn't quite enough for a bug report - what should I look at?
<Kamion> mvo: there are still some wrong font paths in thaifonts-scalable
<Kamion> look through the .diff.gz for X11R6 ...
<Kamion> mvo: also repacking an .orig.tar.gz just to remove CVS directories is generally considered bad
<Kamion> the CVS directories are harmless so it's just unnecessary deviation
<mvo> Kamion: ok, thanks
* sivang wonders if mvo is maintaining parts of X now :)
<mvo> Kamion: I will remember next time. or should I redo it ?
<Kamion> mvo: nah, already accepted
<Kamion> (the rest was OK)
<doko> pitti: is pkg_striptranslations inactive?
<pitti> doko: no, it works fine, why?
<doko> pitti: nevermind, I did look in the wrong package :-/
<Kamion> tseng: done
<doko> pitti: are you sure, that you save the GSI*.sdf files as well?
<pitti> ah, heh
<pitti> if [ "$srcname" = "openoffice.org2" ] ; then
<pitti>     # grab sdf files from OO.o2
<pitti>     find debian/ -name "*.sdf" -exec install -D -m 644 '{}' "$tmp/source/{}" \;
<pitti> fi
<pitti> doko: spot the bug :)
<doko> pitti!
* pitti fixes
<fabbione> pitti: hey dude...
<pitti> doko: just 'openoffice.org' source package is right, I assume?
* pitti hugs fabbione 
<doko> pitti: yes
<fabbione> pitti: :)
<fabbione> pitti: i need your hal fu ....
<bddebian> Damnit, boot: server acpi=off and it still hangs :-(
<fabbione> pitti: the daemon dies with exit 1 on sparc as soon as it forks
<fabbione> pitti: and i can't understand why...
<fabbione> pitti: how can i enable DEBUG of death?
<pitti> doko: fix uploaded
<doko> pitti: so I should ask infinity when it's installed on the buildd's
<pitti> fabbione: sudo hald --verbose=yes --daemon=no 2>&1 | tee hal.txt
<pitti> doko: that happens as soon as it's in the archive; AFAIUI the buildds now auto-update themselves
<fabbione> pitti: roger that!
<desrt> pitti; this ejectable patch you applied to drivemount doesn't make sense
<pitti> desrt: hm, I don't remember that
<desrt>   * Add debian/patches/15_gnomevfs_query_eject.patch:
<desrt>  -- Martin Pitt <martin.pitt@ubuntu.com>  Fri,  3 Mar 2006 14:22:54 +0100
<pitti> ah, this one
<pitti> desrt: why not?
<desrt> ejectable in this sense means 'the device needs to be (USB) ejected on unmount'
<fabbione> pitti: ok.. what i am looking for? or do you want that file?
<desrt> or, it can mean this.
<pitti> desrt: right, that's what it's supposed to do
<pitti> fabbione: where does it crash?
<desrt> if 'eject' appears in the UI i think that word should solely be reserved for optical drives and the like
* sivang awaits bzr to complete pushing.
<desrt> pitti; drivemount applet is offering to eject my mp3 player, for example... quite odd
<pitti> sivang: get a coffee, dude :)
<pitti> desrt: but we want that, since e. g. iPods need to be ejected
<sivang> pitti: yeah, last time I got an instant soup :)
<fabbione> pitti: it appears to crash scanning block devices..
<desrt> pitti; they should just be auto-ejected on unmount...
<pitti> fabbione: a gdb trace would rock as well, then please send me hal.txt and the backtrace
<sivang> pitti: I even once forgot I was pushing in the backgorund, and continued hacking, then tried to commit while push in progress. boom!
<seb128> desrt: upstream does the distinction but in a ugly way instead of using the hal property,no?
<desrt> seb128; ya.  we say "is it a cd/dvd/zip/jaz/etc"
<seb128> so what's wrong to rely on the hal property rather than using special case?
<desrt> pitti; maybe the word "disconnected" would be a better choice if we could somehow do it
<Kamion> fabbione: can you get keepalived built against openssl 0.9.8?
<desrt> seb128; the meaning of 'eject' in the HAL property isn't the same as the meaning of eject in drivemount applet
<pitti> desrt: right, that would just break translations, that's why I didn't want to change the string; especially not deviate from upstream
<doko> mvo: ping
<fabbione> pitti: people:~fabbione/hal.txt but i can't gdb it.. long story..
<desrt> seb128; often the ejectable property in HAL means "please run 'eject -s' (disconnect scsi device) when you're done with me"
<fabbione> Kamion: i think so.. i will try
<fabbione> Kamion: how urgent is it?
<sivang> fabbione: enevtually I used the vesa driver, as this is a VMWare sever machine (the amd64 at work). I might check to see what went wrong there sometime if you would provide the debugging starting point, if that X600 bug source is not yet know.
<mvo> doko: pong
<seb128> desrt: we should always use "remove" or somethin neutral so, users don't care about unmount or eject
<Kamion> fabbione: it's uninstallable on ubuntu-server CDs, that's all
<fabbione> Kamion: ok thanks
<fabbione> Kamion: will look at it
<pitti> fabbione: hm, the output doesn't help too much; I'm afraid I do need a bt
<desrt> seb128; i like 'disconnect' for pluggable stuff... and 'eject' is fine for things that actually eject (like cds)
<fabbione> pitti: we can't bt there ...
<pitti> fabbione: oh?
<desrt> seb128; note: it might make sense to be able to either disconnect a firewire cd drive -or- eject the cd inside it
<fabbione> pitti: gdb isn't very very happy on sparc.. not with all software at least
<desrt> seb128; so they really are different ideas
<fabbione> pitti: and hal is one of the bad boys
<seb128> desrt: right
<pitti> fabbione: gdb gdb hald :)
<fabbione> pitti: i think the error appears only when daemonizing
<pitti> fabbione: ah, you mean it actually ran when you started it manually?
<fabbione> 18:42:33.815 [E]  hald_dbus.c:3258: dbus_bus_get(): Failed to get foreground console
<fabbione> Sent kill to 5653
<fabbione> Sent kill to 5652
<desrt> seb128; also might make sense to unmount without ejecting.... but this is a questionable use case
<pitti> fabbione: ah, so it didn't crash when you debugged it?
<seb128> desrt: we already had that bug and it got rejected upstream
<desrt> seb128; what bug?
<seb128> desrt: arguing that unmounting is not useful since apps using the drive should be able to do that without asking you
<seb128> desrt: "please provide an unmount action next to eject"
<desrt> seb128; ah yes.  or the kernel fixed to not mess them up because it's mounted
<fabbione> pitti: it's weird...
<fabbione> pitti: it did exit.. 
<desrt> seb128; i do believe that 'unmount' is not a useful user-visible action
<pitti> desrt: *agree*
<fabbione> pitti: ok thanks.. i am going to play with it a bit more.. if i won't success you will have root access :)
<desrt> i guess this is something to work on for edgy
<desrt> once gnome translation opens up again
<pitti> fabbione: heh ;) well, maybe I can find sth out with strace, or add some more debug statements
<pitti> desrt: right, the UI should just have 'Remove'
<desrt> pitti; no.  see example above for why this is bad.
<desrt> pitti; eject and disconnect really ought to be separate
<pitti> desrt: ah, right
<desrt> pitti; ejecting and disconnecting my external cdrom drive are entirely different things
<pitti> true
<fabbione> pitti: ok :)
<pitti> desrt: but you don't usually tell the UI that you disconnect the drive, do you? you just unplug it
* ogra would prefer to have it solved at a lower level once and for all ... and just make sure sync is called afetr every access to a removable device
<ogra> then you could just unplug ...
<pitti> ogra: that's something different
<pitti> ogra: that won't ever work
<sivang> pitti: btw, seeing this discussion, how would I got about mounting and unmounting media/devices from a program that doesn't want to depedend on gnome-vfs ? exec the pmount command with the required args as a subprocess ?
<desrt> pitti; the idea is that many scsi devices require to be disconnected before being unplugged
<desrt> pitti; this is why we must 'eject' ipods in the first place (even though we've already unmounted them)
<pitti> ogra: there might be apps still accessing the drive, etc; the user needs to tell the OS that it wants to remove a drive
<ogra> pitti, i meant a *really* low level ...
<desrt> anyway.  gotta run to school.
<desrt> peace
<ogra> pitti, windows solves the "apps accessing the device" apparently somehow
* highvoltage stares at desrt and wonders about this 'edgy' thing
<pitti> highvoltage: dapper+1 apparently
<highvoltage> pitti: i know he said that we can quote him on that, and other people said yes, i can, but that doesn't mean it's true :)
<pitti> right :)
<jdub> highvoltage: i think we've satisfactorily seeded his brain on it by now :-)
<highvoltage> jdub: <g>
<ogra> jdub, be careful, if we dont call it edgy he might be confuzed and do no work at all for it ...
<pitti> jdub: I assume the similarity to Etch is nothing but a pure coincidence? :)
<jdub> pitti: yeah
<jdub> pitti: though doubly funny if you ask japanese speakers about 'etch' and 'edgy'
* pitti doesn't speak Japanese, not a word
<mdz> Kamion: you mean that he will not be able to attend the TB meeting tonight?
<mdz> (if not, there won't be one)
<Kamion> he said he would attend the TB meeting
<Kamion> Keybuk: are you going to be around for this town hall meeting?
<dholbach> pitti: sayonara? arigato? :-)
<pitti> dholbach: I don't know the second one
<dholbach> "thanks"
<doko> mdz: is there a chance that somebody at the sprint can check scim input methods with OOo?
<mdz> doko: yes, please talk to abelcheung about it
<doko> mdz: on amd64 as well?
<doko> mdz: is there an extra channel for the sprint?
<mdz> doko: the server here is an amd64 but it is running 32-bit for vmware I think
<mdz> doko: no, not that I know of. this channel is fine
<elmo> there's still an amd64 install on that box, you'd just have to boot off the first SATA, rather than the second, FWIW
<highvoltage> 322 nicks! is that a record for ubuntu-meeting?
<bddebian> Where's the best place to ask about a Flight-5 server install problem besides #ubuntu+1?  Is ubuntu-devel the appropriate place?
<pitti> malone would be :)
<slomo> infinity, lamont: please give-back gnome-user-share on ppc
<pitti> unless you need to discuss various approaches and so on, which is on topic here
<bddebian> pitti: Well I could use an approach.  I have tried acpi=off pci=noacpi DEBCONF_DEBUG=5 BOOT_DEBUG=2 and all I get is a hang :-(
<pitti> bddebian: baad - anyone in #ubuntu-kernel who could help maybe?
<Mithrandir> bddebian: noapic?
<bddebian> Mithrandir: Haven't tried that, I will
<netzmeister> bddebian:  what's your problem? buggy interrupt controller?
<bddebian> netzmeister: I don't know because it just hangs with no output.  BUt this machine has been a Windows 2003 server for ages with no problems so I don't think it's hardware
<siretart> is there already a name for dapper+1?
<netzmeister> siretart:  dapper+1 ! :-D
<bddebian> netzmeister: It hangs right after freeing initrd
<netzmeister> bddebian:  post the last lines before it hangs..
<netzmeister> ah k
<siretart> Edgy Elephant?
<netzmeister> siretart:  yes
* highvoltage looks on wikispecies for other animals starting with "E"
<bddebian> Mithrandir: noapic didn't help :-(
<bddebian> pitti: Should I ask in #ubuntu-kernel?
<pitti> bddebian: yes, worth a try
<bddebian> pitti: OK, thx
<netzmeister> bddebian:  i think with no information nobody can help you..
<bddebian> netzmeister: No information?  What else can I give you?
<netzmeister> hmm let's see..
<bddebian> And I didn't mean that to be sarcastic if it came off that way
<bddebian> It's a Compaq Proliant ML350 1Ghz with 512Mb RAM and a Compaq Array controller.
<netzmeister> k
<netzmeister> have you tried another kernel?
<netzmeister> (recovery)
<bddebian> Hmm, no
<bddebian> I'd try breezy but I don't have HOURS to pull another iso today :-)
<netzmeister> try the recovery kernel..
<bddebian> OK, will do thx
<netzmeister> np..
<netzmeister> I'll wait.. ;-)
<Keybuk> Kamion: no :)  I'd popped out to the shops before the TB meeting :)
<Kamion> ok
<carlos> pitti, seb128: So I just got my branch merged
<bddebian> netzmeister: Same hang :-(
<carlos> that means that tomorrow, jordi and I will be able to start approving translation imports
<ogra> Keybuk, so you missed the decision that you have to fix up dapper in the 6 weeks delay while we others go on holiday :P
<sivang> hehe
<sivang> ogra: bare with him :)
<netzmeister> hm thats interessting..
<Keybuk> ogra: *shrug* I booked my holiday first <g>
<ogra> :P
<Keybuk> wouldn't mind that too much tbh, I've had not much to do this past week
<netzmeister> you have a clean install of breezy?
<Keybuk> udev is annoyingly working
<Keybuk> and n-m doesn't work, but is impossible to fix in the time allowed
<ogra> Keybuk, even with +6 weeks ? 
<Kamion> Keybuk: on udev, I'd really like some investigation of that devfs helper bug
<bddebian> netzmeister: No, I have all Dapper machines but I guess it's time to download breezy :-)
<Kamion> we've had like ten reports of it
<netzmeister> ah okay..
<Keybuk> Kamion: I've been doing that today, and I can't figure it
<Kamion> can you reproduce it?
<Keybuk> yeah, I *reported* it :)
<Kamion> oh :)
<netzmeister> bddebian:  no why download breezy. Dapper comes in a few weeks..
<Keybuk> do you run udevplug many times?
<Amaranth> Keybuk: n-m almosts works for me, i blame the bcm43xx driver
<Kamion> yeah, once per hw-detect
<bddebian> netzmeister: Not if I can't boot it :-)
<Keybuk> I *think* you get one new floppy device per hw-detect run
<Keybuk> which would make sense
<Kamion> that matches what I seemed to be seeing
<Kamion> there'd be a udevplug run or two in partman as well, I think
<Kamion> basically I was calling it fairly liberally when I needed new devices to be available, since you told me I could :)
<Keybuk> yeah, and I think what happens is that because each run causes a new "floppy ADD" event, that script gets run
<Keybuk> so each new run gets a newly enumerated floppy device symlink
<netzmeister> bddebian:  and there is really no output.. i can't believe it.. Kernel and no output.. :-)
<Kamion> can it just store some state somewhere about which devices it's already seen?
<Kamion> or even grep the existing symlinks
<Keybuk> there's the udevdb state
<Keybuk> there's udevd code to stop that happening though
<Keybuk> that's what seems to be not working :)
<bddebian> netzmeister: Well I mean I get no output on the hang, even with debug on.  I get all the normal bootup output right to the point of "Freeing initrd RAM..."
<Keybuk> a "do we already have a symlink" check at the top of the script is a sufficient fix for us
<Keybuk> you know what?  I'm an idiot
<netzmeister> bddebian:  and before the line is nothing unusual? 
<Keybuk> I just looked at the code again, and it's now glarying obvious why it doesn't work
<Keybuk> Kamion: excellent reminder timing, clearly my brain is now in the right gear :p
<bddebian> netzmeister: No, not that I can see.  I do get:  "ACPI: Finding DSDT Failed" or some such if I don't turn off acpi, but other than that, it looks pretty normal.
<Kamion> heh
<netzmeister> bddebian:  tell us your system configuration..
<netzmeister> bddebian:  do you have a knoppix cd?
<Keybuk> Kamion: it doesn't work because I use SYMLINK+= in the udev rule ... which means "add it to the list of existing symlinks"
<bddebian> Hmm, not here, I don't think.  Let me go look, bbiam
<Keybuk> the "keep only one symlink" code only affects SYMLINK= :)
<Kamion> aha!
<raphink> anyone knows what /usr/bin/lsprop is for on ppc ?
<raphink> there's no man, no --help|-h switches
<raphink> and no comment in the code
<raphink> and it's an old app from 1998
<raphink> :s
<crimsun> http://penguinppc.org/dev/
<Keybuk> what does it do if you run it? :)
<raphink> $ lsprop dirs
<raphink> dirs             7362696e 0a757372 2f62696e 0a657463 2f696e69 742e640a
<raphink> things like this
<raphink> or longer
<Kamion> it's for parsing stuff in /proc/device-tree/
<Keybuk> sounds like the OF device tree
<Kamion> really useful actually, I didn't know about that and had been looking at the files with vim ;-)
<raphink> is this useful?
<netzmeister> raphink:  checksum of the directorys?
<Kamion> cjwatson@cairhien:/proc/device-tree$ lsprop compatible
<Kamion> compatible       "PowerBook5,2"
<Kamion>                  "MacRISC3"
<raphink> netzmeister: not checksums no
<Kamion> hell yes
<Kamion>                  "Power Macintosh"
<raphink> Kamion: I was about to write manpages for this soft
<Kamion> it's a bit like udevinfo
<raphink> but there's not even a -h|--help
<Kamion> if you don't understand it, documenting it is probably not a good plan :)
<raphink> all I know is that when run without an argument it runs itself on all files in the current dir
<Kamion> I agree it's poorly (i.e. not) documented
<raphink> Kamion: yes I guess
<raphink> Kamion: if it's useful, I believe it should be documented
<Kamion> cd into /proc/device-tree/ somewhere and that behaviour is a lot more useful
<Kamion> I'm not arguing, but it's a developer debugging tool so it's not too urgent
<raphink> ic
<raphink> I am to remove backlight from the powerpc-utils package though
<raphink> there's no man either, and the -h says it's obsolete
<raphink> and should not be used anymore
<raphink> so I guess if a program claims to be obsolete it's not worth keeping
<bddebian> netzmeister: Apparently all my Breezy/knoppix/etc CD's are at home so I'll have to try tomorrow, thanks for your time!
<slomo> infinity, lamont: please give-back gnome-user-share on ppc and liferea on amd64/ppc, thanks :)
<netzmeister> bddebian:  no problem. cu tomorrow..
<Kamion> raphink: I'm not sure this is an ideal time to go on a rampage of removing obsolete stuff, personally
<raphink> Kamion: well I went into this since I saw there was no manpages for this
<Kamion> but I guess it's up to you
<raphink> searching for the options to write a manpages
<raphink> I saw this was obsolete
<raphink> so i'm adding manpages for fnset
<raphink> and at the same time removing backligth from the same package
<Kamion> yes, I'm just saying that feature freeze is a poor time to remove stuff
<raphink> hmm ok
<Kamion> because we have a suboptimal amount of time to put it back if it turns out that somebody needed it after all
<raphink> even things that are obviously obsolete and whose -h switch reports to another app?
<raphink>   *************         WARNING         ************
<raphink>   **  backlight is obsolete, please use fblevel   **
<raphink>   **************************************************
<raphink> taht's what you get running backlight -h
<raphink> but I get your point, doesn't hurt to keep it so far ;)
<natroll> hmm, someone messin with the dapper repos?
<natroll> i can't download http://us.archive.ubuntu.com/ubuntu/dists/dapper/universe/source/Sources.gz
<Nafallo> natroll: maybe the mirror is syncing right now? :-)
<natroll> i dunno, was just mentioning it in case there is an issue
<sivang> pitti: I have finally put the package on http://muse.19inch.net/~sivan/upbackup/ , (re what we talked last night) let me know if you prefer I'd emailed you or for any other comments regarding the package.
<bddebian> Wow a breezy download is MUCH faster than cdimage.  Maybe I can test breezy here at work today..
<sivang> pitti: also, I remind, this is for universe NOT main :)
<netzmeister> bddebian:  that sounds fine..
<sivang> pitti: crap, hold on, one mistake there , I'm fixing now.
<Surak> hello, where was happening the discussion about dapper's delay?
<bddebian> Surak: #ubuntu-meeting afaik
<dholbach> Surak: yes and it's TB meeting now
<enyc> TB ??
<Surak> enyc: technical board? 
<enyc> hrrm kk
<bddebian> Is there a wiki for setting up a repository? (Not LocalAptGet)
<zyga> hello
<tseng> bddebian: man apt-ftparchive
<tseng> bddebian: apt-ftparchive packages .
<tseng> bddebian: gzip -9 Packages
<tseng> apt-ftparchive sources .
<tseng> gzip -9 Sources
<bddebian> tseng: Thx :-)
<jbailey> bddebian: http://people.ubuntu.com/~jbailey/snapshot/genarchive.sh if you ever need it again. =)
<bddebian> jbailey: Thanks man
<tseng> jbailey: fancy
<bddebian> jbailey: Got a sec for a quick C++ question?
<jbailey> bddebian: Depends how hard the question is.
<bddebian> jbailey: I'm trying to kill PATH_MAX but I'm using C syntax in a C++ app:  http://www2.bddebian.com:8000/packages/qt-x11-free/qt-x11-free-3.3.5.diff
<jbailey> bddebian: Can you tell me what problem you're having?
<jbailey> bddebian: It'll be easier than disecting it bit by bit.
<bddebian> jbailey: Trying to eliminate the use of PATH_MAX.  http://www2.bddebian.com:8000/packages/qt-x11-free/qt-x11-free-3.3.5.diff
<jbailey> Yes.  That tells me what problem you're trying to solve.  You have a patch.  I assume that you're showing it to me because it doesn't work?
<bddebian> Well it "works" but I don't think I am necessarily doing it properly.  Especially for qfileinfo_unix.cpp
<mjg59> Kamion: Do you have access to the morgue?
<bddebian> Damn, netzmeister left?
<Kyral> time to give Flight 5 Espresso a whirl...as soon as the ISO is finished burning
<bddebian> Well Breezy pukes just like Dapper for me on my server install :'-(
<Kyral> heh
<Kyral> Well, when I get back to school I'm gonna reinstall clean
<Kyral> I have so much crap laying around from stuff like compiling XGL from scratch and whatnot
<Kyral> tthank god for my seperate /home
<wasabi> Why's it matter?
<wasabi> *nix isn't going to get unstable on you because of it. ;0
<Kyral> Actually its because something royally borked up XFCE and GNOME
<Kyral> and yes I filed a bug :P
<Kyral> But its been about time lol
<Kyral> I should really just checkinstall that crap *DUCKS!*
<sivang> pitti: still here?
<pitti> sivang: yes
<dholbach> good night guys
<sivang> night dholbach :)
<sivang> pitti: I'm ready, same location http://muse.19inch.net/~sivan/upbackup/ :) (Had to write a MANIFEST.in file to cater for proper source distribution build)
<pitti> added to my TODO list
<sivang> pitti: thank you :)
<pitti> SCNR, but it's fitting today: https://www.redhat.com/archives/fedora-test-list/2005-December/msg00583.html
<Burgwork> pitti, SCNR?
<pitti> Burgwork: Sorry, Could Not Resist
<Burgwork> ah
<bddebian> pitti: :-)
<Riddell> maswan: ping
<seb128> somebody good with alternatives around?
<seb128> how to tell them to change the target?
<bddebian> update-alternatives?
<seb128> like    "update-alternatives --install /some/path alternative-name /stuff/to/register 45"
<sivang> pitti: hehe
<seb128> I want to change "/some/path"
<bddebian> seb128: You want to change the link, not the path?
<sivang> bddebian: checking the manpage, I see generic name comes before the symlink
<sivang> bddebian: so I guess Seb's trying to change the generic name?
<bddebian>  <link> <name> <path>
<seb128> right
<sivang> I got confused: --install genname symlink  altern  priority , genname being refered to as the "master link"
<seb128> bddebian: issue is that:
<seb128>     update-alternatives \
<seb128>       --install /usr/X11R6/lib/X11/icons/default/index.theme \
<seb128>       x-cursor-theme /usr/share/themes/Human/cursor.theme 40
<seb128> bddebian: and now it has moved away from /usr/X11R6
<bddebian> Ugh
<seb128> bddebian: so I want to relocate it no a new place 
<sivang> seb128: --set looks to be doing the same as --config, but is scriptable
<sivang> seb128: maybe it helps?
<seb128> sivang: --set is to pick an option
<seb128> I don't want to pick an option
<lemsx1> ssl-cert bug #34962
<sivang> ah right! sorry
<Ubugtu> malone bug 34962 in ssl-cert "chgrp/chmod failed to change non-existing keys (dapper)" [Normal,Unconfirmed]  http://launchpad.net/bugs/34962
<bddebian> Probably have to do a remove and a --install?
* sivang shuts
<seb128> bddebian: I need to remove-all so ...
<seb128> bddebian: and what if other packages were registered?
<sivang> bddebian: good to see oyu're back, btw
<bddebian> Heh.  :-)
<sivang> bddebian: less busy with your work now?
<bddebian> A little
<sivang> cool
<bddebian> seb128: What happens if you just do --install?  Does it fail?
<seb128> bddebian: if I "update-alternatives --install /usr/share.... -cursor-theme /usr/share/theme/other_theme.... 45" 
<seb128> bddebian: it doesn't create /usr/share... but still use /usr/X11R6/lib/X11/icons/default/index.theme
<bddebian> Whacky
<bddebian> Just manually symlink them? :-)
<seb128> porky
<seb128> I'm considering using a new alternative for it :)
<bddebian> What if you just rm the /usr/share... Then --install?
<seb128> what do you mean?
<seb128> I want to create that /usr/share, there is nothing to rm
<seb128> maybe I should do a  if [ -L /usr/X11R6/lib/X11/icons/default/index.theme ] ; do update-alternatives --remove-all x-cursor-theme; done"
<seb128> and then doing my --install
<bddebian> Seems reasonable
<seb128> let's do that so
<seb128> I hate alternatives anyway :)
<seb128> where is the best place to rm ?
<seb128> to "update-alternatives --remove-all x-cursor-theme" I mean
<seb128> the preinst or in the postinst before the --install?
<bddebian> That I don't know.
<bddebian> I gotta head home, good luck :-)
<seb128> thank you
<sivang> night all
#ubuntu-devel 2007-03-12
<wick2o> is there a generic way to preseed the Disk psace to partition: ?
<wick2o> ive tried partman-auto/init_automatically_partition select Erase entire disk:*
<fabbione> morning
<LaserJock> hi fabbione 
<Hobbsee> hey fabbione!
<dholbach> good morning
<pitti> Good morning
<Hobbsee> heya pitti!
<dholbach> ogra: new dia
* tfheen waves to Hobbsee, pitti and Daniel
<pitti> hey tfheen 
<ajmitch> morning tfheen 
<fabbione> hey tfheen 
<tfheen> hiya Fabio; nice vacation?
<fabbione> tfheen: it was ok overall, but as good as i expected
<dfarning> good morning all,  I am working on my first spec.  Does anyone have moment to take a look at it to make sure I am on the right track
<fabbione> i didn't get around to finish my MythTV box, but i guess i will survive
<dfarning> https://blueprints.beta.launchpad.net/ubuntu/+spec/derivativeteam
<Hobbsee> heya tfheen!
* Fujitsu fends off clone-infinity.
<dholbach> hey Tollef
<tfheen> dfarning: sounds like it should be an informal spec at least.  The scope isn't well defined in the spec
<LaserJock> dfarning: is there a mailing list for derivatives?
<dfarning> tfheen, how would you define the scope more correctly
<dfarning> LaserJock, i have submitted a request ticket
<tfheen> dfarning: I'd probably move a bit of the bullet list from the summary to scope.  What is and what isn't covered by the spec?
<dfarning> tfheen, ok so who and what is affect defined more completely
<dfarning> does informal mean set is as drafting?
<tfheen> no, informal means there is no implementation
<tfheen> actually, sorry, I meant Informational, not informal. :-)
<dfarning> ok I remember reading about that
<dfarning> thanks
<dfarning> I'll go work on it some more
<fabbione> woooo go seb! go dani! more crack more crack :)
* Fujitsu watches the stable crack roll in.
<Lure> any archive-admin around? Somebody needs to get libkexiv2* through binary new in order to get digikam 0.9.1 built - would be great to have this for beta
<tfheen> Lure: looking
<carlos> pitti: hi
<pitti> hey carlos
<carlos> pitti: I had to delay again the time when lang packs are generated
<carlos> the process will start in 5 minutes (I think the delay was of two hours)
<pitti> carlos: ok, no problem
<pitti> carlos: how does feisty look?
<carlos> pitti: also, Feisty is more or less full imported now
<pitti> yay!
* pitti yearns for tarballs
<carlos> pitti: there are some remaining things, but need manual approval, so I think we should start preparing base lang packs
<carlos> pitti: you have already the ones from yesterday
<carlos> if you want to start playing with them, otherwise, in a couple of hours, you should have the new ones for toay
<carlos> today
<pitti> ok, couple of hours is alright, I need to do some CD testing right now
<carlos> ok
<carlos> pitti: same url schema as before
<carlos> http://people.ubuntu.com/~carlos/language-packs/feisty/
<carlos> once we do the release, it will become http://people.ubuntu.com/~carlos/language-packs/feisty-updates
* pitti -> breakfast, bbl
<mdke> are people working on the network-manager problem, bug 82335? it has a massive number of duplicates, looks difficult to fix, and hasn't been assigned to anyone yet.
<Ubugtu> Malone bug 82335 in network-manager "network-manager should not set offline mode when it manages no device" [High,Confirmed]  https://launchpad.net/bugs/82335
<pitti> mvo_: moin; can I bother you with upgrade-manager -d not working?
<Mithrandir> mdke: I don't know of anybody working on it, but I think it should be relativetly easy to solve.
<mdke> Mithrandir: removing network manager? :)
<Fujitsu> mdke: That's what everybody seems to suggest.
<Fujitsu> Feisty simply can't be released with that bug...
<mdke> agreed
<Lure> Mithrandir: it is not that simple: n-m does not know if there are other interfaces at all, therefore it consideres it has all
<Fujitsu> (it would be best if NM had proper static IP support, but I don't think that's going to happen)
<Lure> Mithrandir: backend would need to be changed to show all interfaces (also static) and just do not manage them
<Mithrandir> Fujitsu: not happening for feisty, at least.
<mdke> Fujitsu: it's not just the static ip support, but also the failure to detect perfectly normal dhcp configured interfaces
<Mithrandir> Lure: no, it wouldn't.
<Lure> Mithrandir: suse and fedora are presumably doing this proprely
<Fujitsu> mdke: True... It needs to be able to detect it better.
<Lure> Mithrandir: why not?
* Fujitsu looks at debian-backend, to see what can be done rather than just ignoring anything other than `inet dhcp'
<mvo_> pitti: what exactly is not working?
<pitti> mvo_: gpg verification fails
<pitti> it's not very verbose unfortunately
<pitti> and the /tmp/tmpUU.. doesn't exist any more
<mvo_> pitti: please update update-manager to the version in -proposed, its a known (and fixed) bug that waits for sru-verification
<mvo_> pitti: I will nag brian about it again so that it can move to -updates ASAP
<pitti> mvo_: ah, will try that
<pitti> mvo_: btw, I did apt-cdrom -m add before that to use the alternate CD as source; could this be the reason?
<mdke> Mithrandir: so will you maybe give someone a poke to look at that bug?
<Mithrandir> mdke: yes
<mdke> thanks a lot
<pitti> mvo_: (still no 'upgrade from CD' option in the u-n CD insertion dialog)
<mvo_> pitti: no. but if you have the altenravtive cd, please try sudo sh /cdrom/cdromupgrade"
<pitti> mvo_: ah, will do that
<mvo_> pitti: oh, no option from the dialog?
<mvo_> pitti: could you please also install the u-n from -proposed?
<pitti> mvo_: well, just 'open package manager' and another one (unrelated)
<pitti> mvo_: yup
<mvo_> pitti: thanks
<mvo_> pitti: I check the status of the two bugs now
<pitti> mvo_: with -proposed, the gpg error doesn't happen
<mvo_> pitti: great, thanks
<pitti> mvo_: so I'll do the test with both variants now ('apt-cdrom add, update-manager -d' and '/cdrom/upgrade')
<Fujitsu> Can somebody look at bug #91012? There are a heap of duplicates, and it only appeared 36 hours ago.
<Ubugtu> Malone bug 91012 in hal "[apport]  hal-device-manager crashed with ImportError in <module>() App crashed running "Hardware Information"" [High,Confirmed]  https://launchpad.net/bugs/91012
<mvo_> pitti: great, thanks. and please try also if update-notifier gives you a correct dialog with the version from -proposed
<pitti> mvo_: 'correct dialog'?
<mvo_> pitti:sorry. u-n should present a "upgrade from this volume" dialog when a upgradable CD is inserted. I will search for the bugnumber for this now
<pitti> mvo_: ah, when running the script on the CD?
<pitti> mvo_: I'm currently testing the u-m -d approach
<giftnudel> I know I keep nagging, but a german translator please fix bug 60527 , since xchat-gnome is annoying with this bug
<Ubugtu> Malone bug 60527 in language-pack-gnome-de "xchat-gnome /me misbehaviour" [Undecided,Confirmed]  https://launchpad.net/bugs/60527
<giftnudel> there are still strings wrong in both edgy and feisty
<cassidy> giftnudel: these translations bug should be fixed with last upstream release. The problem is Ubuntu using its own translations...
<giftnudel> yes, the upstream ones are correct
<markvandenborre> whom should I talk to on ubuntu installer iso localisation?
<markvandenborre> any ideas, ladies and gentlemen?
<Treenaks> markvandenborre: just wait until people wake up ;)
<markvandenborre> Treenaks, grapjas!
<markvandenborre> happy to see you out here, long time no see
<Treenaks> I've been here for ages ;)
* markvandenborre not...
<Fujitsu> Treenaks: Ages? I'd say ever.
<Treenaks> Fujitsu: something like that :)
<markvandenborre> let me clarify my question, just to make sure that I'm in the right channel...
<markvandenborre> I'd like to see auto generated iso's for my combination of language and region
<markvandenborre> (and for others obviously)
<markvandenborre> so an iso with a sensible default i18n, l10n, dictionaries, keyboard layout and if possible location specific packages (electronic id card reader for example for Belgium)
<Mithrandir> markvandenborre: we don't have the manpower to QA that well.
<markvandenborre> Mithrandir, perfectly sensible answer
<markvandenborre> is there a way locoteams could help with the QA process?
<markvandenborre> so as to lower the QA load?
<dfarning> markvandenborre, I am getting together a new team to work on just such issues
<Mithrandir> it would also require a massive increase in the storage space, etc on the ISO building machine.
<Mithrandir> I'm not saying it's impossible, I'm just pointing out a couple of problems which would need to be solved.
<markvandenborre> ok...
<dfarning> https://wiki.ubuntu.com/DerivativeTeam
<Mithrandir> building an ISO takes about one hour,  a bit.
<dfarning> There are several loco team working on localized distros
<markvandenborre> Mithrandir, in our case, I'm just trying to do some research to avoid duplication of work
<markvandenborre> we want a localised iso anyway for our locoteam
<markvandenborre> and there seem to be many more interested...
<dfarning> markvandenborre, what langugage
<markvandenborre> nl_be
<dfarning> can you send me an email at dfarning@gmail.com so I can follow up with you
<markvandenborre> will do
<dfarning> thanks
<dfarning> I think we have about 20 different localization distos out there right now
<markvandenborre> Mithrandir, can I help you convince decision makers to give this some priority by gathering support from locoteams around it?
<markvandenborre> this would prove demand, and guarantee you at least somewhat technically knowledgeable qa testers
<dfarning> markvandenborre, I doubt that Ubuntu will be able build and provide the localized distro for you any time soon
<Treenaks> I think providing a simple way to create the image(s) yourself would help
<Treenaks> 'make-live-image.sh nl_NL'
<markvandenborre> oh yes, I really don't need much hand holding
<Treenaks> markvandenborre: (or nl_BE)
<markvandenborre> and I'm not alone in this
<Mithrandir> markvandenborre: if we have people who have shown a commitment to test the regular ISOs for a while expressing interest in testing custom ISOs, that would make it more likely to happen.
<dfarning> Treenaks, I am putting together some derivative spec so we can put together the tools to easily develop such a localization
<markvandenborre> ok
<markvandenborre> Mithrandir, dfarning thx for your help
<markvandenborre> will try to find some people to rally around this
<pitti> mvo_: yay, u-manager dist-upgrade worked flawlessly
<pitti> mvo_: do I need edgy-proposed for the cdrom script as well?
<mvo_> pitti: no, that should work 
<mvo_> pitti: thanks for testing!
<Mithrandir> Riddell: can you please take a look at the kdegames ftbfs?
<Mithrandir> Riddell: same for kde-systemsettings
<Riddell> Mithrandir: ok
<cjwatson> markvandenborre: my standpoint has definitely always been that I'm happy to help people build the customised images more easily (e.g. the various documents on help.ubuntu.com/community/) but I don't think the Ubuntu CD image / release teams should ever get into doing it ourselve
<cjwatson> s
<pitti> carlos: so if I start the langpack cronjob at 0900 rookery time, will that be enough?
<carlos> pitti: for Breezy, Edgy and Dapper, yes
<carlos> pitti: Feisty is a full export and is not ready until 16:00
<carlos> hmm wait
<carlos> something is not correct here...
<carlos> pitti: For Feisty, I will tell you once it finish for today
<pitti> carlos: alright
<pitti> carlos: I build test packs right now, btw, just to see if there are any major problems
<carlos> pitti: it used to finish around 12:00, but for some reason, this weekend it took around 4 hours more
<carlos> pitti: ok
<markvandenborre> cjwatson, thx for your information
<mjg59> cjwatson: Does policy require that packages with an original-maintainer field have an @ubuntu.com address in maintainers?
<cjwatson> mjg59: no
<cjwatson> implementation might, which I would consider a bug
<Fujitsu> mjg59: Policy doesn't, but builds will fail otherwise.
<cjwatson> Fujitsu: well, that should be fixed. it's wrong.
<Fujitsu> (pkgmaintainermangler fails)
<Fujitsu> cjwatson: There's a bug about it.
<Fujitsu> It's because it tries to add Original-Maintainer, but it already exists.
<mjg59> Ok. My acpid upload failed because of that.
<mjg59> What's the appropriate thing to do? Wait for it to be fixed and then ask for the package to be rebuilt?
<Fujitsu> pitti's on that bug, I believe... What you do depends on when it's likely to be fixed, I guess.
<Mithrandir> mjg59: urgh, sorry about giving you extra mail by giving it back again.
<Fujitsu> It is a one-character change.
<mjg59> Fujitsu: Got a number?
<Fujitsu> Looking.
<mjg59> Thanks
<Fujitsu> Bug #91086
<Ubugtu> Malone bug 91086 in pkgbinarymangler "binary-mangler chokes on non-Ubuntu email addresses that contain a reference (string-wise) to MOTU" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/91086
<Fujitsu> The description isn't particularly true.
<Fujitsu> Sorry, summary.
<mjg59> Wishlist? Hm.
<Fujitsu> It's easy to work around.
<mjg59> Not relaly
<Fujitsu> You just need to use a whitelisted address.
<Fujitsu> (or convince pitti that a one-character change is worth it)
<cjwatson> mjg59: you could probably just fix pkgmaintainermangler yourself
<mjg59> Yeah
<pitti> erm, what's up?
<cjwatson> might need to prod folks to upgrade the buildd chroots - I forget
<mjg59> I'm nervous about poking that sort of infrastructure, though :)
<pitti> mjg59: I recently made it accept @kubuntu.org addresses, I can easily extend that
<cjwatson> pitti: why does there need to be a whitelist in the first place?
<pitti> ah, /me looks at that bug
<mjg59> pitti: Why not just make it accept any address if there's an original-maintainer field?
<Fujitsu> pitti: Why not just make it not kill the build when Original-Maintainer already exists?
<cjwatson> pitti: Maintainer: <anything> Original-Maintainer: <anything> should never error
<markvandenborre> cjwatson, regarding localised iso's you said: my standpoint has definitely always been that I'm happy to help people build the customised images more easily (e.g. the various documents on help.ubuntu.com/community/) but I don't think the Ubuntu CD image / release teams should ever get into doing it ourselves
<pitti> I don't know, infinity might have had his reasons
<Fujitsu> (that is, change `exit 2;' to `exit 0;' on line 63 or similar.
<pitti> cjwatson: it doesn't, it chokes on non-Ubuntuish maintainer fields, like MOTU Media Team <motumedia@tauware.de>
<markvandenborre> I wanted to make clear that I'm not talking so much about custom packages and stuff, rather about i18n, l10n and stuff...
<Fujitsu> pitti: It only chokes if both Original-Maintainer and a non-Ubuntu maintainer address are present.
<pitti> Fujitsu, cjwatson, mjg59: yup, it seems that it's time to remove this check, I'll look into it
<markvandenborre> I'm curious about where you draw the line
<cjwatson> pitti: right, that's a bug and should be fixed
<Fujitsu> Thanks pitti, it's pretty trivial.
* pitti adjusted the bug
<mjg59> pitti: Thanks
<cjwatson> markvandenborre: yeah, that's customisation. We can't afford combinatorial explosion on our own infrastructure; this is exactly the sort of thing where others should pitch in to build the customised images
<markvandenborre> but you would be able to, say, supply a dead easy customisation script and stuff?
<cjwatson> markvandenborre: I've never had time to write one myself, but I believe there are such scripts out there, or at least the beginnings of them
<markvandenborre> like Treenaks joked : sh customise_cd.sh -l nl_be or whatever?
<markvandenborre> cjwatson, sorry if I'm taking too much of your time here, just trying to look at the limits of what Canonical people could be expected to be able to contribute to
<cjwatson> markvandenborre: scripting and code fixes and stuff are reasonable enough, but in this case IIRC somebody else has already taken care of much of the scripting
<markvandenborre> would further development of clean high quality customisation code be an option?
<markvandenborre> ok, thx, that answered my question before I even asked it ;)
<cjwatson> markvandenborre: it would certainly be an option, although it always works better when the people who actually have the greatest need for doing it put something together that works for them ...
<cjwatson> I'd have no objection in principle to Canonical developers doing the sort of work you mention, but it would have to wait its turn behind other priorities so I'm just warning you that it might arrive later than you'd otherwise like. :-)
<markvandenborre> heh, thx, that's a very clear answer
<markvandenborre> so if I summarise you correctly, you say: just start fiddling with what's out there, and gather some interest behind it
<markvandenborre> and if you manage to do that, that will raise priority for us, but don't expect us to ever run an entire customised build infrastructure
<markvandenborre> cjwatson, except for Mithrandir and this dfarning guy, is there anyone in particular that should be kept into the loop on this?
<cjwatson> markvandenborre: I think that's a reasonable summary, yes. In general there should be few things (core infrastructure, basically) where Canonical participation is *required*, although there may be many situations where it's useful or the quickest way to get the job done
<markvandenborre> ok, perfect, we know where to start now
<markvandenborre> thx
<cjwatson> markvandenborre: me, and possibly jono in his capacity of locoteams coordination
<markvandenborre> yes, of course...
<markvandenborre> I wouldn't forget jono and you
<markvandenborre> thx for your time
<pitti> Fujitsu, mjg59: pkgbinarymangler fix uploaded
<Fujitsu> pitti: Will the buildds automatically update when it makes its way into the archives?
<StevenK> They won't, if I recall what infinity said previously.
<pitti> Fujitsu: yes, they will
<pitti> StevenK: Soyuz' do, katie's dont
* StevenK sits corrected
<pitti> Fujitsu: so this can be given-back as soon as archive.u.c has it
<Fujitsu> Isn't katie the autosyncer?
<Mithrandir> no
<cjwatson> Fujitsu: katie => old archive management software
<pitti> Fujitsu: sorry, katie is the old upload and archive mainteance software
<Fujitsu> Wasn't that dak?
<Fujitsu> OK....
<pitti> Fujitsu: the one Debian uses
<Mithrandir> katie is the old name for dak, which is the archive management software used in Debian and which we used.
<pitti> Fujitsu: right, it's dak
<Fujitsu> And I suppose that still manages security.
<pitti> right
<cjwatson> Mithrandir: FYI I've started moving some bits and pieces from people.u.c/~cjwatson to ~ubuntu-archive
<cjwatson> I've left redirects in place
<Mithrandir> cjwatson: thanks; I was going to gently prod you about it sometime.
<mjg59> pitti: Thank you!
<pitti> fabbione: CLK_TCK does not seem to be exported by linux-libc-dev any more; any idea what replaced it?
<fabbione> pitti: oh yeah that's old news.. i don't remember....
<Fujitsu> cjwatson: CLOCKS_PER_SEC
<Fujitsu> Oops.
<Fujitsu> pitti: CLOCKS_PER_SEC
<Fujitsu> Sorry cjwatson.
<pitti> Fujitsu: already tried that, doesn't work either
<Fujitsu> How strange.
<pitti> it's in time.h's includes, but it does not get exposed for some reason
* pitti currently fights with the syslinux FTBFS, which hasn't been rebuilt for ages
<Fujitsu> pitti: I just built something that uses CLOCKS_PER_SEC fine.
<Keybuk> pitti: bet you've got -ansi or -pedantic in your CFLAGS?
<pitti> gcc -m32 -mregparm=3 -DREGPARM=3 -D__COM32__ -W -Wall -march=i386 -Os -fomit-frame-pointer -fno-stack-protector
<pitti> not that I can see
<Keybuk> pitti: is sys/time.h included or time.h?
<pitti> Keybuk: time.h and sys/times.h
<pitti> but adding sys/time.h doesn't help either
<jdub> it's impossible to sleep/resume a machine running the nvidia proprietary driver, right?
<_ion> pitti: Btw, have you had time to review my changes to restricted-manager yet?
<pitti> _ion: not yet, sorry
<_ion> pitti: No hurry :-)
<Keybuk> pitti: hmm, I can't replicate it -- I get a __stack_chk_fail error instead
<pitti> Keybuk: right, I already fixed those
<Keybuk> pitti: which is the file that's failing for you?
<pitti> but since a trivial program with just #include <time.h> works, it must be somehting in syslinux itself
<pitti> Keybuk: com32/libutil/get_key.c
<Keybuk> pitti: if I change CLK_TCK to CLOCKS_PER_SEC, it's fine
<pitti> Keybuk: hm, not here; maybe it's different on amd64?
<pitti> get_key.c: In function get_key:
<pitti> get_key.c:140: error: CLOCKS_PER_SEC undeclared (first use in this function)
<pitti> get_key.c:140: error: (Each undeclared identifier is reported only once
<Keybuk> that's odd; you're compiling on amd64 for i386 ?
<pitti> that's what I get
<Keybuk> or on amd64 for amd64?
<pitti> Keybuk: amd64
<pitti> Keybuk: argh, there is an empty time.h in com32/include; I guess it fell over that one
<Keybuk> could be yeah
<Keybuk> ah yes
<Keybuk> the build line is totally different
<cjwatson> hmm, public_html/germinate-output/ is ever so slightly bigger than I thought
* cjwatson waits for it to copy to ~ubuntu-archive/
<Keybuk> Keybuk: making libutil_lnx.a it just does -I./include, but libutil_com.a it does -I../include as well
<Keybuk> s/Keybuk/pitti/
<pitti> right, and this makes sense if using the com32 includes for _com
<pitti> but the empty time.h there doesn't
<Keybuk> indeed
<Keybuk> that'd be included instead of the one in /usr/include
* pitti hardcodes it to 1000000l just for testing
<tkamppeter> I need some help concerning the Debian packaging system.
<pitti> tkamppeter: just ask
<tkamppeter> I have a file in /etc and I want that it is not marked as config file. See bug 36532 and bug 90988.
<Ubugtu> Malone bug 36532 in gs-esp ""Unsupported format" when trying to print" [Medium,Confirmed]  https://launchpad.net/bugs/36532
<Ubugtu> Malone bug 90988 in cupsys "printing any file give "Unsupported format 'the/format'" (dup-of: 36532)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90988
<Ubugtu> Malone bug 36532 in gs-esp ""Unsupported format" when trying to print" [Medium,Confirmed]  https://launchpad.net/bugs/36532
<pitti> tkamppeter: you want to create a new config file?
<apokryphos> Seveas: problem with the ubugtu timeout?
<pitti> tkamppeter: or convert an already existing conffile to a config file?
<elkbuntu> apokryphos, no... first message had 2 bug numbers, second bug title had a dupe number
<tkamppeter> No, gs-esp has a file /etc/cups/pstoraster.convs This file shouldNOT be considered as a config file.
<pitti> Mithrandir: for the record, I did my amd64 alternate and desktop tests (including autoresize this time), I didn't see anything that hasn't been reported before
<cjwatson> tkamppeter: if it's shipped in the deb, it must be a conffile. If you don't want it to be, you should move it somewhere other than /etc
<pitti> Mithrandir: edgy upgrades work fine with the /cdrom/upgrade script, but fail with edgy's update-manager; using the one from edgy-proposed works fine
<apokryphos> elkbuntu: yeah, I would've thought the timeout wouldn't (or probably, shouldn't) permit that though; doesn't matter much though I guess.
<tkamppeter> So should I make the postinst generate it then
<pitti> tkamppeter: you usually ship a template in /usr/share or generate it on the fly in postinst
<pitti> tkamppeter: but NB that you must gracefully handle and respect already existing files on upgrades
<pitti> tkamppeter: 'shouldNOT be considered as a config file' -> you mean conffile here, right?
<pitti> tkamppeter: if you really mean 'config file', then the file should be in /var/
<tkamppeter> Yes, I mean a conffile.
<cjwatson> for files in /etc whose format changes gradually over time, it's generally expected that either (a) it's a conffile so the user gets prompted about the changes or (b) the maintainer scripts take care to upgrade the contents of the file
<tkamppeter> /etc/cups/pstoraster.convs tells CUPS that there is the pstoraster fileter and how to use it.
<pitti> tkamppeter: since this already is a conffile, you must not touch it on upgrades
<pitti> tkamppeter: why do you want to change this, btw?
<pitti> tkamppeter: it's usually much easier to fix conffiles with package uploads than fixing config files
<tkamppeter> pitti, but this file is not supposed to be modified by the user. So the user got a stone-old version yeasr ago and it will never get updated.
<cjwatson> tkamppeter: incorrect: conffiles get automatically changed unless the user has changed them; otherwise the user will be prompted
<pitti> tkamppeter: your answer has several wrong concepts
<pitti> tkamppeter: everything in /etc can be modified by users
<cjwatson> (assuming there's a controlling terminal)
<pitti> tkamppeter: and "config files" will never be automatically updated; conffiles will
<pitti> tkamppeter: that's why I said that conffiles are usually what you want
<tkamppeter> So then how to fix bug 90988? The problem here is that the user got a file /etc/cups/pstoraster.convs from an old Ubuntu version and with the time the file was changed in the Ubuntu package gs-esp. Updates of gs-esp do not replace the file.
<Ubugtu> Malone bug 90988 in cupsys "printing any file give "Unsupported format 'the/format'" (dup-of: 36532)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90988
<Ubugtu> Malone bug 36532 in gs-esp ""Unsupported format" when trying to print" [Medium,Confirmed]  https://launchpad.net/bugs/36532
<cjwatson> tkamppeter: one mistake that may be responsible is that sometimes developers attempt to both ship a file as a conffile (i.e. in the .deb) AND edit it in maintainer scripts; this is wrong wrong wrong and can often lead to users getting erroneously prompted. If your package has 
<pitti> cjwatson: your reply was clipped, btw
<tkamppeter> Here it seems that the user never got prompted. He was always left with his old /etc/cups/pstoraster.convs file.
<cjwatson> tkamppeter: ... ever edited that file in a maintainer script as well as shipping it in a conffile, then that could be responsible for problems
<cjwatson> tkamppeter: that doesn't normally happen.
<cjwatson> tkamppeter: but if the file got edited and they upgraded using something which didn't present them with the standard conffile prompt, then it's possible
<tkamppeter> The current maintainer scripts do not touch pstoraster.convs.
<cjwatson> tkamppeter: there are the following suitable responses: (a) the user edited the file by hand => reject bugs about it not getting upgraded, as it's their problem now; (b) a maintainer script edited the file by hand => fix the maintainer script not to do that; (c) the file should never ever ever be edited by users under any circumstances => move it out of /etc
<hunger> why is all of the sudden linux-image-dbug-2.6.20-10-server going to get installed? I am using the -generic kernel...
<cjwatson> but don't move files out of /etc just because users edited the file by hand and then the usual conffile resolution process did the wrong thing for them
<StevenK> cjwatson: (d) use ucf, and open up a whole other raft of problems ?
<tkamppeter> The file really should not be edited by hand, so (c) should be the right solution, but problem is that CUPS only searches /etc for such files.
<pitti> tkamppeter: use a symlink then
<cjwatson> CUPS is free software and therefore patchable ...
<cjwatson> symlinks from /etc to elsewhere are a bit grotty
<tkamppeter> So the bug is an upstream bug of CUPS, so I should file a feature request for a second search place.
<cjwatson> that's the sort of thing it's perfectly reasonable to patch in locally
<pitti> tkamppeter: shuold be easy to fix ourselves
<pitti> tkamppeter: of course that patch should be proposed upstream as well
<tkamppeter> If I use the symlink from /etc to my own place, what would an update do. Would it replace the existing file by a symlink?
<pitti> tkamppeter: that would be wrong, so I hope dpkg won't
<tkamppeter> pitti, how would you solve it? In the CUPS package by patching CUPS to provide a second search location for .types and .convs files not editable by the user?
<pitti> tkamppeter: that definitively sounds cleaner
<tkamppeter> pitti, or do you have an idea for a fix inside the gs-esp package?
<cjwatson> fixes in one package aren't necessarily better than fixes in multiple packages
<pitti> tkamppeter: the gs-esp package should then stop shipping the conffile, rm it in the postinst on upgrades, and generate it on the fly in /var in postinst
<cjwatson> pitti: sounds like it should be in /usr, not /var? after all it's shipped at the moment, not generated dynamically
<tkamppeter> pitt, but this will only work if CUPS is changed to search in /var.
<pitti> cjwatson: I don't know
<cjwatson> tkamppeter: correct. Fixing cups sounds useful
<pitti> tkamppeter: will a static file version work for everyone, or does it need to be dynamically generated?
<tkamppeter> I think, /usr is correct, as pstoraster.convs ships as a ready-made file with constant content.
<pitti> tkamppeter: if the former, then it should be in some .d directory in /usr/share
<tkamppeter> pitti, the static file works for everyone.
<pitti> oh, not a .d directory
<cjwatson> cups should look in /etc first though, just in case somebody does need to generate it by hand
<cjwatson> and the thing that removes it in the postinst on upgrades should (a) only do so once, when upgrading to the version that removes the conffile (b) check against various known md5sums for the conffile before nuking itt
<cjwatson> it
<tkamppeter> So bug 90988 is a design bug of CUPS. So we must make CUPS searching in /etc plus the new directory and report an upstream bug (not a feature request) with this patch.
<Ubugtu> Malone bug 90988 in cupsys "printing any file give "Unsupported format 'the/format'" (dup-of: 36532)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90988
<Ubugtu> Malone bug 36532 in gs-esp ""Unsupported format" when trying to print" [Medium,Confirmed]  https://launchpad.net/bugs/36532
<tkamppeter> Then we must search all Ubunru packages for /etc/cups/*.types and etc/cups/*.convs files and do the same fix on them as we do on gs-esp.
<pitti> mjg59: hal FTBFSed on powerpc and sparc due to the new macbookpro patch; do you have a minute to take a look at it?
<tkamppeter> pitti, this looks all like a higher-impact change. Should this be done for Feisty?
<Riddell> mvo_: I've committed a fix to DistUpgradeViewKDE in update-manager, should it work if I just upload in the normal way?
<pitti> tkamppeter: adding another search path to cupsys doesn't sound particularly scary to me
<tkamppeter> So pitt, will you do it?
<tkamppeter> s/pitt/pitti/
<pitti> tkamppeter: I have some other high-urgency stuff on my plate, so I'd prefer not to
<Mithrandir> pitti: ok, thanks.  We should make sure to releasenote that bit, then
<pitti> seb128: http://people.ubuntu.com/~pitti/langpacks/daily/feisty/ !!
<seb128> pitti: waouh ;)
<pitti> seb128: I'll use tomorrow's rosetta tarball for beta; the current ones are just for testing and sorting out major issues with carlos today
<seb128> k, I'll give them a try
<ogra> pitti, how much is that in total ? 
<pitti> ogra: how much?
<ogra> i have pleanty of space on my add-on CD ...
<tkamppeter> Mithrandir, I think this is the best way then, as this file is usually really not manually modified or removed by users, the problemn in the bug does not happen. So we should tell in the release notes that when the user gets this problem he should do
<tkamppeter> dpkg -P --force-depends gs-esp
<ogra> pitti, the total size of all of these langpacks
<tkamppeter> apt-get install gs-esp
<pitti> tkamppeter: I think Mithrandir alluded to the edgy->feisty upgrade test results
<tkamppeter> and everything is reset to normal and the file will be regularly updated again.
<pitti> ogra: I didn't do any statistics yet, they just finished building
<ogra> ah
<ogra> well, i have easily 200M spare space for them ;)
<pitti> ogra: totally new words from you :-P
<ogra> yeah, thanks to mvo and cjwatson i'm a happy man with two CDs now :)
<pitti> where is the 'argh, donthavethetenbytesofadditionalspace' ogra?
<tkamppeter> pitti, Mithrandir, sorry. But perhaps we should really add a realeas note for this one, too. WDYT?
<pitti> tkamppeter: hm, if we would start documenting every bug in the release notes, they'd get pretty long
<pitti> tkamppeter: this bug should be fixed IMHO, not documented
<tkamppeter> So the best would be that I should change all the affected packages before beta?
<pitti> tkamppeter: it's just adding that three-line patch to cupsys and doing some shuffle in the gs-esp packaging, right? or does it affect more stuff?
<tkamppeter> I am not sure, there can be other packages with .types and .convs files.
<pitti> well, we can fix the others as we get to know about them
<pitti> as long as cups falls back to /usr/share/... only if the file isn't in /etc/cupsys/, that should DTRT
<cjwatson> tkamppeter: instead of the rune above, 'rm -f /etc/cups/pstoraster.convs && apt-get -o DPkg::options::=--force-confmiss --reinstall install gs-esp' is better
<cjwatson> (for the record)
<cjwatson> (point being that there's no need to purge/reinstall just to get dpkg to replace a conffile
<cjwatson> )
<tkamppeter> pitti, which /usr/share should be searched by CUPS? Should we introduce a new /usr/share/cups/mime and propose this one also upstream?
<Riddell> mvo_: I uploaded it, let's see what happens
<pitti> tkamppeter: sure, sounds sane
<^robertj> what magic-grub options need to be appended if you install grub by hand? ubiquity died at the end of the install when I ran it without with the migration assistant
<^robertj> (c2d laptop on amd64)
<^robertj> right now it hangs on or after USB
<tkamppeter> Only thing is that I do not like very much to make a distribution package be very much different to upstream, but the architecture of CUPS seems to be far away from (Ubuntu, Debian, ...) Linux requirements.
<^robertj> aha! it did timeout after a while
<pitti> *shrug* cupsys' debian/patches is an utter mess with or without that new patch
<mvo_> Riddell: uploading should work fine, thanks for the fix
<seb128> tkamppeter: do you know what libcups function is called when adding a printer from gnome-cups-manager? Trying to figure what URI it tries to use for the smb one
<bddebian> Heya
<^robertj> are nightlies mirrored anywhere on I2?
<crimsun> yes
<^robertj> is there a mirror list for nightlies?
<pitti> heno: re your mail about ISO testing: too late :) I already did everything and reported to Tollef
<tkamppeter> seb128, unfortunately, I do not know how the gnome-cups-manager tells the CUPS daemon how to create a new queue. Does an strace of gnome-cups-manager nowhere show a string starting with "smb://" or the host name or IP of the SMB server or printer?
<heno> pitti: yeah, I'm a bit behind the curve on this round :-/
<heno> pitti: does that mean you'd like to do more images for beta? :)
<pitti> heno: I can do OEM and expert on amd64/alternate as well if you want me, then I would have everything ever possible
<pitti> heno: took me about 3 hours today; workload leveling appreciated :)
<heno> pitti: as in more leveling would be appreciated or as in this was better than before?
<heno> pitti: this is the sort of feedback I need to balance things out
<pitti> heno: I meant that 3 hours seems quite appropriate to me, and I wouldn't mind doing OEM and expert in addition, but we shuold try to assign a roughly equal workload to folks; not just for boredom reasons, but also to minimize the critial path time
<pitti> heno: however, the 3 hours was a bit with cheating: I didn't count the time when d-i/ubiquity grinded away on their own in vmware (I did something else in between)
<pitti> so the actual 'start testing to mark everything as completely tested' turnaround is more like 7 hours
<heno> pitti: agree. Workload can be difficult to judge though, and the time used may depend on people's hardware, download speed, etc. So I appreciate the feedback
<pitti> right
<pitti> heno: the two upgrade tests were the ones which took a very large chunk of it (1.5 hours for each of the two test)
<pitti> and if I had done this on real hardware, it would have taken about 8 hours, I guess
<heno> pitti: I can imagine. And thanks for doing those; I for one am not set up to do those
<pitti> heno: oh, no problem
<pitti> heno: I use the feisty alternate CD as an additional apt source, so it doesn't eat too much bandwith
<pitti> width, even
<heno> hm, ok cool
<pitti> and I don't think that it is vital to do those upgrade tests on real hardware, vmware should do fine
<heno> I still need to catch up with mvo on this topic
* pitti waves to kwwii, how's it going?
<kwwii> dholbach: just pushed a new session splash
<kwwii> pitti: busy, busy, busy
<kwwii> ;-)
<kwwii> pitti: and you?
<pitti> likewise :)
<dholbach> kwwii: ok
<Mithrandir> seb128: did we end up with me taking the amd64 or i386 DVD?
<pitti> enrico: oh, shall I actually report to bug reports for this informal round?
<pitti> enrico: sorry, that wasn't for you
<pitti> heno: oh, shall I actually report to bug reports for this informal round?
<LeeJunFan> hrm, dbus in feisty doesn't play well with nfs booting.
<heno> pitti: please do yes, we need to debug the tracking system too :)
<pitti> alrighty
<seb128> Mithrandir: amd64
<Mithrandir> seb128: that's what I thougth too, thanks.
<seb128> np
<seb128> tkamppeter: the strace shows no URI starting with smb, let me look if there is the machine IP or name
<cypherbios> mvo_: what is the syntax to show a link for the bug in launchpad inside a changelog file -- parsed by Update Manager? (i.e.: 'Closes LP#89733' automatically links to http://launchpad.net/ubuntu/+bug/89733)
<Ubugtu> Malone bug 89733 in aptoncd ""Selecting packages" dialogue issues" [Low,Fix committed]  
<mvo_> cypherbios: just LP#349234 should work
<mvo_> cypherbios: it tries to be clever and detect debian bugs too
<cypherbios> mvo_: great! thank you.
<pitti> mvo_: which bug was the u-m gpg failure?
<mvo_> pitti: #78673
<pitti> mvo_: danke
<tepsipakki> Mithrandir: how about that discover-data sync?
<tepsipakki> Mithrandir: bug #90595
<Ubugtu> Malone bug 90595 in discover-data "sync a new version from debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90595
<mvo_> Riddell: could you please have a look at https://beta.launchpad.net/ubuntu/+source/update-manager/+bug/91072
<Ubugtu> Malone bug 91072 in update-manager "Upgrade to Kubuntu 7.04 - Upgrade Tool Crashed" [Undecided,Unconfirmed]  
<Mithrandir> tepsipakki: looks good to me.
<Mithrandir> tepsipakki: oh, and can you please get some sponsors and apply for -core-dev?  I'd like to sync as you, not as me. :-P
<seb128> Mithrandir: he has already
<Riddell> mvo_: that looks like a bug in the exception handler, presumably his extra sources.list lines caused the exception handler to be called
<Mithrandir> seb128: ok.
<seb128> Mithrandir: I mean, he's listed to ubuntu-dev, you can sync with his name
<tepsipakki> Mithrandir: oh, maybe I should
<tepsipakki> seb128: I haven't applied AFAIK ;)
<seb128> hum
<mvo_> Riddell: ok, but     KRun.runURL(KURL(url), "text/html") NameError: global name 'KRun' is not defined seems to be the error, no?
<seb128> tepsipakki: you are to ubuntu-dev which is enough to use your name for a sync, it has to be approved though, right
<Mithrandir> seb128: well, I don't sync into somewhere the person can't upload.
<seb128> Mithrandir: sorry, ignore me, i got confused between ubuntu-core-dev and ubuntu-dev :p
<mvo_> Riddell: #91104 seems to be releated
<seb128> bug #91104
<Ubugtu> Malone bug 91104 in update-manager "update" [Undecided,Confirmed]  https://launchpad.net/bugs/91104
<Riddell> mvo_: yes, that part is my fault
<mvo_> Riddell: np
<Riddell> mvo_: I was just wondering what caused the exception handler to be run at all
<mvo_> right
<ogra> geser, did you plan to package the fuse update ? 
* pitti thanks autoconf for breaking hal-device-manager and generating over 30 duplicate bugs
<ogra> hooray
<dholbach> ogra: new dia
<ogra> dholbach, already downloaded, i'm just busy with ltsp atm
<dholbach> ok
<dholbach> cool
* iwj watches this machine download GNOME from security.u.c.  Joy.
<ogra> i guess gss and gpm are to come today or tomorrow as well ...
<geser> ogra: I've packages ready at http://members.ping.de/~mb/fuse/ and bug #90919 got approved today
<Ubugtu> Malone bug 90919 in fuse "[UVF exception]  Merge fuse 2.6.3-1 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90919
<ogra> yep, i saw tollefs comment ...
<geser> should the changelog mention the uvf exception bug?
<ogra> yes
<geser> ok, then I'll add it now and prepare a new source package
<geser> ogra: an updated diff.gz is now at http://members.ping.de/~mb/fuse/
<Treenaks> bug 72079 -- I can send someone one device like that (to make driver-writing easier?)...
<Ubugtu> Malone bug 72079 in linux-source-2.6.20 "Keys of USB "handset" not working" [Undecided,Needs info]  https://launchpad.net/bugs/72079
<Treenaks> how/who should I contact? :)
<mvo_> Riddell: #91295 looks like one for you as well :)
<Riddell> mvo_: thanks
<pitti> tepsipakki: is there a new xserver-xorg-input-evdev upstream version? the current one doesn't seem to work with the new xorg (http://librarian.launchpad.net/6752857/buildlog_ubuntu-feisty-sparc.xserver-xorg-input-evdev_1%3A1.1.2-1ubuntu3_FAILEDTOBUILD.txt.gz)
<seb128> pitti: 1.1.5 is the xorg 7.2 version
<pitti> ah, so we should update this, too
<seb128> looking
<seb128> I think I looked at the update
<seb128> and I'm wondering if 1.1.5 was not a merge from a new branch and we didn't update on purpose
<seb128> pitti: hum, yeah, 1.1.5 has not been updated because there is many changes and it was not clear if that was really meant for xorg 7.2
<seb128> we should rather try to grab a patch for it
<maaks> hi
<maaks> i'm registered on lauchpad and i needed some help
<vcrobe> Hi people. I need some C programmer that can help me
<pitti> vcrobe: #ubuntu, please
<shawarma> Will doko be around today?
<vcrobe> nobody there can answer my question
<vcrobe> I've tried many days and nobody can help me
<vcrobe> today some guy told me that maybe in this channel somebody can help me
<shawarma> vcrobe: /msg me. Maybe I can point you in the right direction.
<vcrobe> shawarma: thanx
<kylem> shawarma, doko is off this week.
<shawarma> kylem: Ok. Bad timing, if you ask me. :-) SoC is open of apps this week.  
<shawarma> kylem: But thanks!
<vcrobe> shawarma: I can't send you private messages because I'm not registered here :-(
<shawarma> vcrobe: Either register or go to #shawarma :-)
<jdong> shawarma: free food served?
<vcrobe> I'll go to #shawarma ;-)
<maaks> it is said that i'm not an active member of launchpad 
<shawarma> jdong: Don't count on it, but you won't know if you don't go. ;-)
<maaks> does it mean i cannot help for developpement ?
<pitti> tepsipakki: filed as bug 91699, btw; there are other bugs against this package which seem to be due to this API change
<Ubugtu> Malone bug 91699 in xserver-xorg-input-evdev "FTBFS with current xorg headers" [High,Confirmed]  https://launchpad.net/bugs/91699
<ogra> geser, uploaded
<maaks> hello ?
<pochu> maaks: you can help, sure
<pochu> maaks: but better go to #ubuntu-motu, and read the topic ;)
<cjwatson> shawarma: Keybuk is also one of our SoC administrators; shouldn't matter that one of our two is on holiday
<maaks> pochu, ok thank you
<shawarma> cjwatson: Not unless I've already been talking to one of them. :-) 
<shawarma> cjwatson: But sure, I'll talk to Keybuk, if it's urgent.
<cjwatson> in the absence of a contact mailing list, it seems like a good idea to copy both of them unless it's private
<Keybuk> e-mails should be sent to ubuntu-soc-owner@lists.ubuntu.com
<iwj> Yes, I KNOW I have a `.local' domain.  I had it as documented in RFCwhatever before Apple stole it dammit.
<iwj> I don't use it for anything but I think I'll keep it because at least it suppresses crazy ad-hoc dns things.
<_ion> The ad-hoc dns thing 
<ogra> iwj, and dont forget, you keep something you can complain about if in bad mood ;)
<iwj> ogra: ROTFL
<iwj> Very good point :-).
* ..[topic/#ubuntu-devel:ogra] : 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 | Herd 5 releits the most important one ;)ased
<ogra> erg
* ogra kicks xchat and his tab key
<iwj> Boggle.
* ..[topic/#ubuntu-devel:ogra] : 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 | Herd 5 released
<Mithrandir> iwj: have you tested your LVM/mdadm stuff on real hardware?  I'm unable to get it to boot properly on a feisty box here.
<siretart> Mithrandir: try booting with 'break=mount', (re)run 'udevtrigger', wait 2 seks and press CTRL-D.
<siretart> Mithrandir: this helps at least on my box
<iwj> Mithrandir: Yes.
<iwj> But I didn't have a RAID mirror.
<Mithrandir> siretart: doesn't help because udevd isn't running.
<iwj> Or at least, not root-on-raid.
<iwj> I can see I'm going to have to make one.
<Mithrandir> this is root-on-raid1 + lvm-on-raid1 (on the same physical disks, but different partition)
<Mithrandir> iwj: something makes udevd blow up after init-premount, it seems, so no events get sent.
<Mithrandir> and the md+lvm volume never gets started.
<Mithrandir> unless I call local-top/mdadm by hand.
<siretart> Mithrandir: the behavior on my box is that udevd gets started, but fires off only 1 of 4 raid volumes
<iwj> udev _blows up_ ?
<Mithrandir> iwj: as in, there is no udevd process when it falls over after trying to mount /
<siretart> s/fires off/brings up/
<iwj> Mithrandir: Freaky.
<Mithrandir> I haven't strace-ed and friends yet.
<maaks> Is there a ubuntu dev that can help me , i'd like to contribute 
<Mithrandir> also, an upgrade calls update-initramfs just too many times.  I think it ran between ten and fifteen times on a one-month-old update.
<Mithrandir> iwj: this is the xen kernels in the archive, but I doubt that makes a difference to regular kernels.
<iwj> Mithrandir: update-initramfs> Yes, very true but not easy to fix.
<iwj> My root-on-lvm setup is not in Xen.
<pochu> heno: how went the iso testing this weekend? ;)
<Mithrandir> iwj: I believe this setup should be fairly easy to replicate in qemu, though.
<pitti> carlos: could future feisty tarball exports include the POT files?
<heno> pochu: we are still testing. See: https://wiki.ubuntu.com/Testing/Matrix
<siretart> maaks: please /join #ubuntu-motu
<pitti> carlos: I was asked to run some statistics on the gnome/kde languages, and I need the POT files for accurate numbers
<iwj> Mithrandir: I don't mind doing it on real hardware, really.
<Mithrandir> iwj: oh, sure.  I'd be fine with testing solutions, but some friends of mine are using the xen instances on the box, so I would prefer to not reboot too nilly-willy. :-)
<iwj> Mmm.
<iwj> I'll built a test setup tomorrow I think.  Debugging this at a distance isn't working.
<iwj> s/built/build/
<pitti> seb128: feisty langpacks look good for me so far, btw
<seb128> pitti: I haven't tried yet, still busy with GNOME 2.18.0
<geser> ogra: thanks for sponsoring
<Lure> carlos: can you check bug 88376
<Ubugtu> Malone bug 88376 in Baltix "Please backport wxmaxima and maxima from feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88376
<Lure> carlos: sorry, bug  88367
<Ubugtu> Malone bug 88367 in digikam "[Feisty]  Digikam is not translated in french" [Undecided,Confirmed]  https://launchpad.net/bugs/88367
<ogra> geser, thanks for preparing :)
<alex-weej> does LP have bug dependencies?
<alex-weej> i can't seem to find an option for it
<LaserJock> alex-weej: sounds like a question for #launchpad
<cjwatson> alex-weej: no
<alex-weej> cjwatson: i have reported a bug which is a symptom of another bug
<alex-weej> rather than mark it as a duplicate
<alex-weej> is there no better way to keep track of it?
<cjwatson> nothing with metadata. Put a comment in both bugs explaining the situation.
<alex-weej> cjwatson: done. thanks
<cypherbios> Mithrandir: what exactly does the README.diskdefines in Ubuntu CDs?
<ajmitch> morning
<geser> keescook: bug #90913 got approved, you can upload
<Ubugtu> Malone bug 90913 in gnupg2 "[UVF exception]  Merging gnupg2 2.0.3-1 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90913
<keescook> geser: ah, good.  thanks.
<Mithrandir> cypherbios: unsure.
<cypherbios> Mithrandir: do you think that could be an APT stuff?
<kronoman> does Ubuntu has some tool like Norton Utilities ? because I was thinking about making one, but I don't want to duplicate effort
<kronoman> some like a ncurses menu that calls fsck, badblocks, etc when needed
<Mithrandir> kronoman: the alternate CD has a rescue mode
<kronoman> ok, I'll check it
<adamant1988> Hello all, I was curious when SELinux is planned to be included with Ubuntu?
<ajmitch> when someone actually has time to work on it
<ogra> well, its included since ages ... just not enabled :)
<kronoman> mmm, I'm not sure this was what I was thinkin'
<kronoman> I was more about a tool like norton utilities, for 'grandma' use i.e
<kronoman> when your disk goes fsck, you just choose 'repair' instead of going to a console
<Mithrandir> mdz: is there a particular reasoning for naming the ubuntu milestones ubuntu-$name rather than just $name ?
<ogra> Mithrandir, derivatives ? 
<ogra> {ed,k,x}ubuntu ?
<Mithrandir> ogra: ttbomk, you don't have your own milestones?
<Mithrandir> and full derivatives have their own namespace.
<grndslm> just a thought, but would it be too much to ask for the installer to ask if the user's sure they don't want a separate /home partition??
<Keybuk> why would you want a separate partition?
<grndslm> i see users complain about not being able to reinstall easily....because they didn't even know that a separate /home dir was a good idea
<Keybuk> why would they need to reinstall?
<LaserJock> ?
<grndslm> everybody needs a fresh install every once in a while
<LaserJock> people reinstall like crazy :-)
<grndslm> no joke
<Keybuk> nobody should need a fresh install
<ajmitch> probably because of various things like automatix or random crack they install
<Keybuk> if there's a bug that causes that, we should fix that one
<grndslm> Keybuk:  this guy's complaining in #ubuntu about not being able to upgrade from dapper to edgy
<Keybuk> grndslm: has he filed bugs for the problem packages?
<LaserJock> many people just get to a point where they just give up and reinstall
<grndslm> Keybuk:  a bug is that the installer doesn't do "error checking" because most desktop users will want a /home dir, but some don't know it
<xhaker> Keybuk, open source is about choice!
<grndslm> because they're so overwhelmed...then once they get settled in and have 10gigs of data and no means of backup
<Keybuk> grndslm: I would argue that is wrong; most users do not want a /home
<grndslm> Keybuk:  he doesn't even know how to add repos to sources.list...
<geser> ogra: Florent Mertens mailed me about his started merge of fuse 2.6.3. Based on his additional changes I've prepared a new debdiff (fixes bug #87767)
<Ubugtu> Malone bug 87767 in fuse "Grep flags used in /etc/modoprobe.d/fuse do not work in initramfs" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87767
<grndslm> how would he know to track some bugs?
<Keybuk> if a user doesn't know how to do difficult things, then they definitely don't want /home to be seperate
<grndslm> bull junk
<grndslm> give me a practical desktop use case where /home shouldn't be separate??
<grndslm> i can't think of one
<ogra> geser, ah, yes, i saw that one .... its a trivial fix 
<Keybuk> an ordinary machine with a single desk
<Mithrandir> grndslm: in most cases, I just make / the full disk.
<Keybuk> uh, disk
<geser> ogra: the debdiff is at http://members.ping.de/~mb/debdiffs/. There are also debdiffs to rebuild ltspfs, ntfs-3g and linux-ntfs
<Keybuk> users will be filing bugs wondering why they can't upgrade (disk full)
<grndslm> Keybuk:  i have a single disk on my laptop
<Keybuk> or why they can't save more files (disk full)
<Keybuk> despite having plenty of free space
<grndslm> but i wouldn't be caught dead leaving /home on the root partition
<Keybuk> /home on a different *disk* makes sense
<geser> ogra: these 3 package need the FUSE_2.6 symbol but don't depend on libfuse2 >= 2.6
<Keybuk> but a different partition?  no point except for "old school did it that way" ness
<grndslm> Keybuk:  sure...but most people only use one disk
<Mithrandir> Keybuk: makes sense on servers, but they're not the use case we're discussing here.
<Keybuk> for a single-disk machine, I make one partition that fills the entire disk
<Keybuk> Mithrandir: exactly
<ogra> geser, why do you wipe the initscripts from the source ?
<ogra> just keep them but dont install them 
<Keybuk> Mithrandir: and even then, I'd argue that you're more likely to put /home on a different disk or even have it NFS mounted
<grndslm> Keybuk:  i can't believe you're seriously trying to tell me that /home should be under the root dir
<Keybuk> grndslm: yes
<Keybuk> I am seriously telling you that
<Lure> Keybuk: it makes sense if you have your laptop disk with dual boot (edgy + feisty) with shared /home
<geser> ogra: ok, will update the debdiff
<Keybuk> and I am arguing that doing otherwise has no practical benefits
<grndslm> to ask a question
<Mithrandir> Keybuk: I tend to RAID + LVM/EVMS stuff on servers because I might not know what needs I'll have in the future.
<Lure> Keybuk: but that is far from common case
<Keybuk> Lure: no reason to do that; use chroots
<grndslm> has no practical benefit
<grndslm> i just gave you one example
<Keybuk> grndslm: you haven't given a useful example
<Keybuk> "what if they fail to upgrade" -- solution = fix that issue
<grndslm> do you ever look at #ubuntu?
<Keybuk> yes, frequently
<grndslm> everyday i see people who can't upgrade from dapper to edgy easily for one reason or another
<grndslm> and when i tell them to just use the cd
* ajmitch has run into more problems with having a separate /home
<grndslm> they stare at me like this o_O
<Keybuk> then we should pay more attention to fixing upgrade issues
<Keybuk> which we have been doing
<grndslm> Keybuk:  or just ask one simple question
<grndslm> take your pick
<Keybuk> but your question doesn't solve the problem
<Keybuk> *AND* is utterly meaningless to the kind of user you're giving as an example
<grndslm> ok...it's not like there couldn't be an explanation
<grndslm> before the question
<Keybuk> Let me translate "Place /home on a separate partition?" into ordinary user speak for you
<Keybuk> "Place blah on wibble snarf?"
<ogra> Keybuk, nope
<Keybuk> users never read explanations before the checkbox/input box
<ogra> Keybuk, its talking about moving houses ...
<ogra> for sure !!
<grndslm> such as...if you are a desktop user...it's usually a good idea to but your /home directory on a separate partition, would you like to take more time and think about this or are you sure you know what you're doing???
<grndslm> something like that
<Keybuk> ogra: lol, I could just see that support request -- "Ubuntu wants me to move home!"
* _ion would gladly place blah on wibble snarf.
<ogra> yeah
<Keybuk> grndslm: but it's not a good idea
<grndslm> design is a great idea
<Keybuk> it doesn't help you at all
<grndslm> how not
<mjg59> The problem is "Users find it difficult to upgrade", not "/home is not on a separate partition"
<grndslm> i wouldn't have to explain to dumbasses on a daily basis why their /home should be separate
<Keybuk> you only do it because somewhere along the line, someone realised it was possible to split the UNIX filesytem across multiple disks
<Mithrandir> grndslm: but it shouldn't!
<Keybuk> and therefore everyone decided to do this
<kronoman> because is a good idea ;)
<Keybuk> and where they had a single disk, they split that into miniature partitions *just so they could do this*
<Keybuk> and someone noticed this allows you to wipe your install and start again
<Keybuk> a convenient bypass to tricky upgrades
<geser> ogra: a fixed debdiff it at the mentioned url
<ogra> btw we dont have dumbasses in ubuntu ... only some underskilled users :)
<Keybuk> this isn't a fix for tricky upgrades, it's ignoring the problem
<Keybuk> we should spend our time *fixing the upgrade problem*
<grndslm> Keybuk:  a convenient bypass to tricky upgrades is right
<Mithrandir> it also made sense back in the days when your file system blew up every so often so you wanted to limit the damage, but file systems have gotten way more robust over time.
<ogra> geser, ta
<grndslm> that's what i'm looking for...to educate newbies about this convenient bypass
<Keybuk> I would rather we spent development time removing the need for the bypass in the first place
<grndslm> Keybuk:  you never want a fresh start?
<Mithrandir> grndslm: the convenient bypass is "take a backup and restore that".  People shouldn't be running without backups, and certainly not upgrading without backups.
<ogra> grndslm, but you just fiddle around with the symptom instead of curing the cause
<grndslm> ogra:  so do most of the people who actually use ubuntu
<grndslm> ubuntu isn't just for devs anymore...it's for HUMANS!
<LaserJock> grndslm: we should have backup utilities (hubackup?) for reinstallations
<mjg59> I think this conversation has gone beyond the point where anything of any use is going to be gained from it
<Keybuk> mjg59: agreed
<grndslm> LaserJock:  most people don't have any other tape or disc to backup to!
<kronoman> normal people don't do backups
<kronoman> is reality 
<grndslm> exactly
<grndslm> which is why education about separate /home directory should be a no-brainer
<mjg59> grndslm: kronoman: Please note my previous statement
<LaserJock> but that's maybe what they should be doing
<kronoman> they just want to turn on the computer, solve their problems and thats all
<kronoman> mjg59: right
<ogra> mjg59, whle i have you here :) any idea for bug 81227 ?
<Ubugtu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
* kronoman goes to have some tea
<mjg59> ogra: Nope
* Keybuk goes back to trying to find out when his third-great grandmother married the lodger
<ogra> mjg59, sad ..
<mjg59> I'll try to get round to it at some point, I'm fighting ridiculous cluster setups right now
<LaserJock> Keybuk: good luck ;-)
<ogra> mjg59, ok, i'm still waiting for an answer from hughsie ... 
<grndslm> all i'm trying to tell you guys is that prevention is the easiest, cheapest, and fastest way to solve problems
<grndslm> if you want to cause more problems, then keep it the way it is
<grndslm> but i don't think that's what OSS and ubuntu in particular is about
<grndslm> at least i'm hoping
<Keybuk> Ubuntu is all about making an operating system that just works
<kronoman> grndslm: I can say that, today, my disk with / crashed, but I'm fine because /home is in a separate disk
<grndslm> exactly...and it'll work but most newbs will run into problems if they aren't educated about separating /home dir
<Keybuk> we'd rather make upgrades just work than confuse users by suggesting they should repartition their home in case the repo men come round
<_ion> "if you want to support terrorism, then keep it the way it is"
<grndslm> Keybuk:  it's not even about upgrading...it's about a fresh install
<grndslm> if i f*** somethin' up....i'm 100% confident that i haven't really lost anything
<Keybuk> grndslm: we'd rather make it so nobody ever needed to do a "fresh install"
<grndslm> most newbs don't know that...they're worried about reinstalling and losing
<grndslm> Keybuk:  yea, really good luck with that one
<Keybuk> thanks
<Mithrandir> my laptop has only been upgraded from Warty to Feisty all the way without a reinstall.
* ogra has a bunch of such systems too ...
<mc44> Mithrandir: clearly you dont install enough crack :)
<mjg59> Again, I seem to have fallen into this strange world where people acknowledge what I say and then ignore it anyway
<Keybuk> Mithrandir: heh, did you start on warty? :p
<fabbione> Mithrandir: slacker! that means you never tested the installer on your machine :)
<grndslm> Mithrandir:  because (a) you're a programmer (b) don't change too much stuff you don't know about
<grndslm> this doesn't apply to most people who use ubuntu, i'm sure
<Mithrandir> Keybuk: my laptop did, at least, given that I bought it after warty released.
<mjg59> So how about I put it this way - this discussion is pointless. Shut up, now.
<grndslm> aight...well, there goes down-up software
<mjg59> grndslm: If you have a strong feeling that this would provide strong technical benefits, then please write a spec
<Keybuk> Mithrandir: I saw a bug the other day which you could only get if you started off with sarge and went to warty
<Keybuk> I was impressed
<torkel> I have been upgrading from Debian unstable, pre Sarge, up until a week ago when the disk crashed...
<mjg59> It's clear that nobody here is going to change anyone else's mind
<grndslm> very clear
<Mithrandir> somehow, I don't think my workstation upgrade path is anywhere near supported.
<grndslm> i'll write the spec
<mjg59> Thank you
<Mithrandir> (slackware 96 -> rh 4.2 -> various newer RHs, Debian potato, woody, sid, warty, change of architecture, hoary, breezy, dapper, edgy, feisty)
<Keybuk> Mithrandir: pretty much my distro path
<LaserJock> Mithrandir: without reinstalling?
<Mithrandir> LaserJock: yes.
<LaserJock> holy cow!
<kylem> slink was a good releas.e
<Mithrandir> the "change from RH to Debian without rebooting" bit is.. fun.
<Keybuk> was slink the one that first shipped APT?
<ajmitch> heh
<Keybuk> I can remember my first flirt with Debian needing to get APT from a later distro
* ajmitch did end up reinstalling for switching from mandrake to debian
<LaserJock> I reinstall probably at least 2 times a release :/
<Mithrandir> this was also before debtakeover, so I had to do it by hand.
<Keybuk> Mithrandir: yes, but you're insane
<Keybuk> \o/ found their marriage!
<Mithrandir> as long as you do it with planning, it's fine.  A friend of mine did an accidential debootstrap over the wrong root partition which made for some interesting rescue bits.
<Mithrandir> luckily, he had irssi running so I dcc-ed him a copy of sash
<grndslm> i'm with LaserJock...i reinstall about 2 times a release also...how do you do it Mithrandir...what's the secret?
<Mithrandir> grndslm: fix the small problems before they grow into big problems.
<xhaker> he has a seperate /home of course.. joke!
<Mithrandir> if you do that, it's so much easier to fix the big problems when they show up once in a while.
<LaserJock> my reinstallations are generally not necessary, I do it to clean stuff up and test
<grndslm> yea...i still find it hard to believe
<grndslm> but i mean...how do you go from RH to deb??
<grndslm> with only a root partition and swap?
<grndslm> i'm assuming by backing up your /home directory
<Mithrandir> grndslm: rpm -e everything you don't need.  Squirrel libc.so.6 somewhere, start up a few copies of sash, emacs etc.
<Mithrandir> then you rpm -e the rest, and use sash's support for ar + tar+gz
<grndslm> wow...
<grndslm> and you expect most people who use ubuntu to do that?
<Mithrandir> no
<Riddell> do we use allow-hotplug in the interfaces file?
<Mithrandir> I don't expect people to switch distros without reinstalling.
<grndslm> well, how do i write a spec?
<grndslm> nm...i see it
<grndslm> i thought there were different request lists for edgy, feisty, etc..
<Keybuk> Riddell: no, "auto"
<kronoman> don't forget the people that actually wants the computer for doing something useful, people that can't spend the day removing and fixing stuff by hand
<kronoman> sometimes a reinstall takes less time than bug-hunting and fixing (specially if you aren't a expert)
<Riddell> Keybuk: thanks
<grndslm> no jack...i've been watching linux for at least 5 years...using ubuntu exclusively since hoary (even tho it really wasn't really that stable to begin with...i just hated windows)...and i still don't know how to solve most problems in linux because they're sooo friggin' obscure you don't even know where to begin...
<grndslm> nudges are helpful
<grndslm> just like the video driver issue...but that's all i'm gonna say
<grndslm> i'm out...just think about it, ya experts!
<shawarma> Mithrandir: How did you manage the arch change? 386 to amd64, I presume?
<Keybuk> Riddell: since we bring up all interfaces by "hotplug", there seemed little point distinguishing the two
<Mithrandir> shawarma: yes, i386 to amd64.  More or less the same way as rh -> deb, just remove everything temporarily, then unpack bits of the new system, make sure to keep rescue shells around.
<Keybuk> it's more impressive that you're on the same disk without it dying :p
<_Kent_> Anyone good with assembly and have the time to help me with something ?
<shawarma> Mithrandir: Yes, I suppose that would do it. I only tried doing it on a remote system where the only rescue option available was an 386 based one. I couldn't figure that one out.
<Mithrandir> Keybuk: I've switched the hardware around a few times too, including moving everything from disk to disk.
<_Kent_> Anyone ever tried to disassemble a windows driver ?
<Seveas> elmo, ping
<Lutin> bittorrent-gui uses python-wxgtk2.4 in its code, but seems to work fine with 2.6. is there a reason to stick to 2.4 ??
<jdong> Lutin: it artifacts sometimes with wx2.6
<jdong> Lutin: upstream for bittorrent and bittornado both don't recommend running 3.x.x with wx2.6
<Lutin> jdong: and won't even start with 2.4 
<jdong> Lutin: well that's a Ubuntu bug
<AlinuxOS> https://wiki.ubuntu.com/FeistyReleaseSchedule  here is feisty schedule... can you tell me gently ...the debian-installer translation deadline?
<jdong> I've been having a PITA time with python2.4 wxgtk apps too
<Lutin> jdong: yes, but I'm wondering if it comes from wxgtk2.4 not bieng in the default python path or because python-wxversion doesn't exist for python2.4 atm
<Lutin> (in feisty)
<jdong> heh well I don't know
<jdong> what I do know is that you're not supposed to run bittorrent 3.x with wx2.6
<Lutin> okay :)
<AlinuxOS> cjwatson, maybe you can tell me ?
<jdong> :)
<Lutin> jdong: I presume doko is the right person to poke for that ?
<jdong> not sure :)
<ogra> tepsipakki, is there a reason that all my synaptics touchpads suddenly have sideways scrolling enabled ? thats very annoying 
<Lutin> jdong: oh ?
<jdong> Lutin: bittorrent 3.x is a largely useless, not much maintained program :)
<jdong> Lutin: almost every other torrent client slaps the crap outta it....
<tepsipakki> ogra: it is?
<tepsipakki> ogra: annoying, that is
<tepsipakki> ogra: there were a number of reports requesting that
<jdong> tepsipakki: well I for one welcome our side-scrolling overlords
<ogra> tepsipakki, it got totally unprecise and if i use my taskbar for klicking on apps there which i do from time to time it starts to get mad 
<Lutin> jdong: even if not maintained, the intersting point is that for now, any program using python2.4 won't be able to use wxgtk :)
<tepsipakki> ogra: so there was a reason why it was off
<ogra> tepsipakki, i usually end up with 4-7 flashing apps in the taskbar if i try to switchto a specific one ...
<tepsipakki> not that the changelog mentioned it or anything
<jdong> Lutin: right, I think doko might do that wxgtk-version stuff :)
<ogra> only if i use the TP very very carefully i can acturlly reach the app
<Lutin> jdong: ok :). thanks
<tepsipakki> ogra: ah, because you use the area for horizontal movement trying to select an app?
<ogra> additionally my TP seems to react to my palm all the time, it didnt do that before my past dist-upgrade
<tepsipakki> ogra: did you regenerate your xorg.conf?
<ogra> tepsipakki, well, i move the mouse down to the taskbar, that gets me into that area, yes ...
<ogra> yes, i did
<tepsipakki> right
<ogra> my problem is that it is way to sensitive on my laptops ... 
<jdong> ogra: strange.... my touchpad uses the scrollzones as normal touchpad area, unless I scroll in them....
<jdong> if i enter from a non-scrolling zone it does not scroll
<ogra> jdong, if you move only slightly diagonal it goes mad here ...
<jdong> ogra: hmm interesting
<ogra> same for a slight touch with the palm while typing
<tepsipakki> hrm.. I asked around why it was disabled and nobody knew
<jdong> that should be an option exposed in mouse options *g*
<jdong> tepsipakki: the first thing I do is enable mine :)
<jdong> and special tapping corners
<ogra> right, but we dont have it as an option yet
<jdong> and 2/3-finger taps
<tepsipakki> it can be reverted
<ogra> i assume that was the reason to disable it
<tepsipakki> so it seems
<jdong> it'll revert just with a VScrollDelta
<jdong> or whatnot
<jdong> set to 0
<ogra> i'd try to get used to it, but it *feels* very buggy here ... on two different lappies
<tepsipakki> HorizScrollDelta
<tepsipakki> ogra: vertical scrolling works?
<ogra> always did 
<ogra> and does without probs now as well ...
<tepsipakki> strange thing that it's bugfree
<tepsipakki> oh well, maybe it just calls for a proper configuration gui
<ogra> well, its an area thats not as often used as the bottom ...
<tepsipakki> and keep safe defaults
<ogra> right
<sistpoty> Riddell: around? we just had some idea about the kde4 stuff, not quite sure what you'd make from it?
<pochu> I have just read the beta freeze announcement, and I have a little (maybe stupid?) question. Does the freeze affect also to Universe?
<sistpoty> pochu: I guess it'll be the same as for the recent freezes: universe uploads will just stack up until after freeze and then go through all at once
<ajmitch> oh damn, beta freeze already?
<pochu> ajmitch: this Thursday
<j1mc> have there been any pre-beta builds of xubuntu yet?  https://bugs.launchpad.net/ubuntu-iso-tests/+bugs  i see builds for kubuntu, ubuntu, and edubuntu . . .   no xubuntu.  :-(
<j1mc> howdy pochu
<ajmitch> pochu: good, I may still have a chance of bugging Mithrandir about f-spot
<pochu> heya j1mc :)
<pochu> hehe
<Mithrandir> ajmitch: I'm off to bed now, but I got your mail, yes.
<ajmitch> ok, good 
<pochu> j1mc: the fact that there are no reports about xubuntu in the iso test tracker doesn't mean that there are no images for xubuntu ;)
<pochu> j1mc: http://cdimage.ubuntu.com/xubuntu/daily-live/ and http://cdimage.ubuntu.com/xubuntu/daily/
<pochu> j1mc: regarding the bug reports, we still have to see what we're going to do
<pochu> heno: around?
<j1mc> pochu: i know that there are current images, but i just want to make sure that we can report our test results.
<pochu> j1mc: oh, ok :)
<pochu> Mithrandir: would it be possible to add xubuntu reports to the iso testing tracker?
<heno> pochu: yes
<pochu> heno: what do you think regarding xubuntu reports?
<j1mc> i have hordes of xubuntu testers ( https://launchpad.net/~xubuntu-testers/ ) that i am going to unleash on the ISO testing page on launchpad.  we are going to crash launchpad.  ;-)
<heno> j1mc: unlikely
<j1mc> ;-)  i know . . . i was joking.
<heno> j1mc: seriously, that's great!
<pochu> heno: I know it isn't oficialy supported, but as there are enough xubuntu testers, it would be interesting to have such bug reports, don't you think?
<heno> just have them file comments, that's fine
<heno> we do
<pochu> heno: really?
<heno> don't we?
* heno checks
<cjwatson> AlinuxOS: "NonLanguagePackTranslationDeadline" (the installer doesn't use language packs for its own translations)
<j1mc> heno: there were xubuntu builds here (  https://bugs.launchpad.net/ubuntu-iso-tests/+bugs ) for herd5, but they aren't there for the pre-beta.
<heno> j1mc: you're right. I'll file them now
<AlinuxOS> cjwatson, thanks, already helped me pochu.
<j1mc> heno: great, thank you!
<pochu> heno: thanks :)
<j1mc> pochu: thank you, too.
* j1mc goes off to unleash his hordes.  ;-)
<pochu> j1mc: enjoy your testing! ;)
<heno> j1mc: done
<j1mc> heno: thanks again
<heno> j1mc: when testing it might be worth looking at the bugs being tracked for beta https://beta.launchpad.net/ubuntu/+milestone/7.04-beta to see if it's possible to collect more information on any of them, confirm fixes, etc.
<j1mc> heno: thanks for the tip.  i'll be sure to share that will our testing group.
<heno> cool, thanks
<pochu> sistpoty: I thought in the other freezes universe was as usual, no stacks
<sistpoty> pochu: uploading was as usual, but the packages were still held back until after the freeze
<pochu> ah, ok
<pochu> sistpoty: thanks for the clarification :)
<sistpoty> np ;)
<elmo> Seveas: ?
<mdz> Mithrandir: I think they may need to start with a letter?  in any case I would think they would look a bit strange with only a version number and no words
<Lutin> elmo: hello. if you have a moment, could you have a look to https://answers.launchpad.net/launchpad/+ticket/3888 please ?
<tsmithe> Mithrandir, are you around?
<elmo> Lutin: you set your preferred email to lutin-@ubuntu.com
<elmo> Lutin: that gets you dropped from the @ubuntu.com forwarding because a) it's a loop and b) there's nowhere for it to be forwarded to
<Lutin> elmo: eek, indeed. going to change it
<Lutin> done
<elmo> sigh, hobbsee's also broken her mail forwarding
<LaserJock> elmo: does @ubuntu.com  work via LP preferred address again?
#ubuntu-devel 2007-03-13
<elmo> LaserJock: always has?
<elmo> for Ubuntu members anyway
<LaserJock> elmo: hmm, for some time I've had to do a RT if I change my preferred address
<LaserJock> so I thought they were independent of each other for some reason
<elmo> LaserJock: well, it's not 100% automated, because I don't trust LP and/or my scripts not to break ubuntu.com for everyone, so the diff gets mailed to us, and we have to ack it before it's applied
<elmo> LaserJock: so an RT ticket is a good way of poking people if it's taken more than a couple of days
<LaserJock> elmo: ahh
<Riddell> sistpoty: hmm?
<tsmithe> Mithrandir, well, i'm off to sleep. i'd just like to ask about a couple of packages in NEW. UbuntuStudio would like wired and enblend to get in (and they've been there since at least, if not before FF). seb128 said he'd had a look, but would like another ack or someone else to upload it entirely. could you take a peek? thanks :)
<sistpoty> Riddell: sorry, was afk for a moment... just sent a mail to -motu... what do you think of it?
<Riddell> sistpoty: luka has replied already
<sistpoty> Riddell: just read it...
<sistpoty> Riddell: however by removing the binaries (shortly before feisty releases), you could still make use of the build infrastructure until that point
<sistpoty> Riddell: and afterwards we could have binaries for feisty +1
<sistpoty> Riddell: the big difference would be that nobody would *need* to support the packages in feisty, once it's released
<sistpoty> Riddell: do you think that would totally defeat the purpose or would this be an option you could live with?
<Riddell> nobody has to support them anyway, they're just a useful platform to build upon
<Riddell> yes, it would be pointless to remove the binaries
<sistpoty> hm... ok
<krawek> hi
<krawek> I have a problem loading shared libraries on dapper, I get: undefined symbol: __gxx_personality_v0
<krawek> any idea?
<krawek> I'm compiling a ruby extension
<danohuiginn> anybody here want to review a simple patch? bug 91695
<Ubugtu> Malone bug 91695 in gtkgo "Missing a .desktop file" [Undecided,Confirmed]  https://launchpad.net/bugs/91695
<jwendell> krawek, try asking on #ubuntu
<krawek> ok
<jwendell> danohuiginn, i cannot try it right now, but you could add a changelog entry
<danohuiginn> thanks jwendell. Over on #ubuntu-bugs, I was just told to leave the changelog for a maintainer to update, but OK
<khermans__> ok, new ubiquity is *REALLY* broken
<danohuiginn> if I edit the changelog,I need to change the version number, right?
<LaserJock> danohuiginn: yeah
<danohuiginn> are there docs on that somewhere?
<LaserJock> well, the Ubuntu Packaging Guide
<LaserJock> !packagingguide > danohuiginn 
<jdong> what is this orange and red thing and what has it done to my login splash?
<danohuiginn> got it. thanks
<wick2o> anyone know what is wrong with this line? append debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/custom.seed initrd=install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
<wick2o> anyoen see an error in this?
<wick2o> it still prompts me for the locale and kbd-chooser when i try and do my install
<wick2o> anyone know what is wrong with this line? append debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/custom.seed initrd=install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
<wick2o> im having a hard time getting those first few questions preseeded
<supervillain> hello, is there a way to check each .deb file locally from the internet? I want to check it's md5, and signature validity, if it's not tampered by someone else.
<LaserJock> supervillain: if you create a mirror it should work
<supervillain> for example, I have /var/cache/apt/archives/lynx_2.8.5-1ubuntu2_i386.deb downloaded from ubuntu repository, is there a way I can get the MD5 of this file from the ubuntu repository?
<Fujitsu> supervillain, apt-get, aptitude, or synaptic will automatically check it.
<LaserJock> supervillain: I think that the Packages.gz file has the md5sum
<kronoman> there is a need for a Norton Utilities-like thing for Linux ?
<kronoman> I could code one, inspired on my yesterday hard disk crash
<TheMuso> kronoman: If you are referring to something like ghost, there are already several solutions for Linux
<TheMuso> As far as I know anyway.
<TheMuso> Partimage is one that comes to mind.
<kronoman> I was meaning something that come up when the system fails to boot
<kronoman> i.e my system crashed /
<kronoman> so I was dumped to a root terminal
<kronoman> if I were a grandma, I would have been in trouble to recover my data
<kronoman> would have been cool instead of the "run fsck manually" a menu with "try to backup data" "check hard disk for errors" etc
<kronoman> a text menu, I mean
<kronoman> that would make ubuntu more user friendly , I think
<kronoman> what I mean is, instead of dumping you to a root console in case of a boot failure, should try to provide with some options to recover, and a "go to root terminal" too
<kronoman> more like a integrator, for partimage, badblocks, fsck, etc
<kronoman> all-in-one place to call the tools to save your system
<pitti> Good morning
<Hobbsee> hey pitti!
* Hobbsee hugs pitti :)
* pitti hugs Hobbsee back
<ajmitch> hey pitti 
* elkbuntu hands jdub a h00ge bowl of chicken soup.
<Hobbsee> :)
<Seveas> elkbuntu, he's ill already, better give him something good instead of your soup
* Seveas now runs like the wind
<elkbuntu> rofl
<elkbuntu> shhh.. you'll ruin my plan!
<Mithrandir> tsmithe: I can poke at them.
<pitti> Mithrandir: can you please give-back workrave on ppc?
<Mithrandir> given-back
* Hobbsee hugs Mithrandir 
* Mithrandir hugs Hobbsee back
<Hobbsee> :)
<dholbach> good morning
<pitti> Mithrandir: thanks
<Mithrandir> Hobbsee: you need a proper hackergotchi with just your head and not any background. :-)
<dholbach> hey Hobbsee
<Hobbsee> Mithrandir: people keep saying that, but imbrandon tried, did a shocking job, because i tend to wear my hair down, which means that if you remove my hair, there's not much of my face left.
<Hobbsee> heya dholbach!
<ajmitch> morning Mithrandir 
<Mithrandir> morning, Andrew
<Mithrandir> Hobbsee: we could do something like http://planet.tut.no/heads/lene2.png (a friend of mine) ?
<Hobbsee> hrm, maybe
<Mithrandir> I could give it a shot if you give me a picture where your head is slightly bigger than 20x20 pixels. :-)
<giftnudel> good morning all
<Hobbsee> Mithrandir: ahh.  could be aranged, if you really want
<Mithrandir> Hobbsee: I could at least give it a shot.
<pitti> _ion: hm, I figured out some required packages for the nvidia_supported script, but it still fails with a NoMethodError
<pitti> mvo: can you confirm bug 91315?
<Ubugtu> Malone bug 91315 in restricted-manager "fglrx needs to be modprobed in /etc/modules" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91315
<mvo_> pitti: I give it a go now, but I'm not fully up-to-date
<mvo_> pitti: I don't have fglrx in my /etc/modules but it still works fine for me 
<pitti> mvo_: including DRI?
<mvo_> pitti: yes. let me add a comment to the bugreport
<pitti> mvo_: i. e. if X is loaded, it modprobes the module automaticallY?
<pitti> mvo_: hmm, anyway, if it doesn't work for some people, I better have r-m add it to /e/modules
<mvo_> pitti: right, it will not hurt
<lifeless> iwj: hi
<lifeless> iwj: sorry I haven't replied to your mail about protocols, got myself into a month long series of sprints
<lifeless> iwj: I'm doing so now
<_ion> pitti: Could you /msg me the whole error, please?
<pitti> _ion: done
<pitti> _ion: I merged your changes to trunk; the new hw detection rocks!
<pitti> _ion: there seems to be a race somewhere, though; sometimes I only see 'nvidia', and sometimes I also see the legacy driver
<_ion> Ouch... That shouldn't happen. :-\ What does lspci -n say about your card?
<pitti> _ion: 01:00.0 0300: 10de:0322 (rev a1)
<pitti> _ion: as I said, sometimes it works correctly
<pitti> I didn't figure out a pattern yet; maybe iff the driver is enabled
<_StefanS_> does the current feisty kernel support more than 2gigs of memory ?
<_ion> CONFIG_HIGHMEM4G=y
<_StefanS_> yes that is great... but does the STOCK ubuntu kernel support it ?
<mjg59> Yes
<_StefanS_> ok super !
<_ion> I pasted it from the stock kernel's config. :-)
<_StefanS_> _ion: oh, i'm sorry .. I thought you were trying to get smart with me, so meaning I should compile it by myself ;)
<_StefanS_> (to get the support I wanted)
<_StefanS_> great, then i'll go out and buy those extra 2gigs for for my lappie :)
<_ion> pitti: All right, the version of hpricot in feisty doesn't support the page / 'td[text() ^= "0x"] ' syntax for XPath searches yet. I had installed mechanize with rubygems. I'll modify the script to support the older API.
<pitti> _ion: there's no way to replace this with a simple shell/wget script?
<pitti> (or urllib)
<_ion> pitti: Oh. It *does* support the / syntax, but not the XPath expression i'm using.
<_ion> pitti: Of course it's possible, but it would be 5x longer without the mechanize magic. :-)
<pitti> ok :)
<pitti> _ion: I'll upload 0.5 now for more widespread testing; we'll need another upload tomorrow anyway I guess (after I got a reply to bug 91315 and maybe fixes for the hw detection)
<Ubugtu> Malone bug 91315 in restricted-manager "fglrx needs to be modprobed in /etc/modules" [Medium,Needs info]  https://launchpad.net/bugs/91315
<_ion> pitti: Screen-scraping doesn't get much easier than this: get 'http://www.nvidia.com/object/linux_display_archive.html'; click page.links.with.href(link_re); click page.links.with.text(/Supported Products List/); (page / 'td[text() ^= "0x"] ').map {|td| td.inner_html.strip.hex }
<_ion> That returns a list like [0x0112, 0x01A0, ...]  from a page like http://www.nvidia.com/object/IO_18897.html
<pitti> _ion: sweet ;)
<pitti> _ion: I still wonder why they maintain such detailed web pages instead of putting those lists into the modules themselves
<_ion> pitti: Indeed.
<pitti> _ion: uploaded and pushed; can you please merge?
<Lutin> mvo_: could you have a look at bug #83139 ? it seems that this program uses files that were in update-manager in edgy, but no longer in feisty
<Ubugtu> Malone bug 83139 in gapti "[apport]  gapti crashed with ImportError in <module>()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83139
<mvo_> Lutin: yes, I can fix that
<Lutin> mvo_: okay, thanks 
<_ion> pitti: Pushed the workaround for the version of hpricot in feisty.
<pitti> _ion: cool, thank you
<TheMuso> pitti: In your email re php4, are you referring to my UVF for drupal when you say its fixed in feisty?
<pitti> TheMuso: no idea, I just checked drupal's current dependencies, and it has php5 alternatives
<TheMuso> pitti: Oh ok. I was wondering that.
<_ion> pitti: Btw, is the problem with nvidia_legacy being listed still there after removing /var/cache/restricted-manager/*.restricted?
<slomo_> hm, half of gnome failed to build on ppc it seems
<seb128> slomo_: yeah, not only on ppc, there is quite some build errors on amd64 and ia64 also
<seb128> slomo_: I'll ask for retries when we are done with uploads
<slomo_> seb128: ok, thanks :)
<seb128> Mithrandir: gtkhtml upstream changed the lib name, any objection to upload a new source package, etc?
<seb128> Mithrandir: there is just new evolution to build with it, should be straigthforward
<dholbach> could it be that the libwnck for amd64 disappeared somewhere?
<pitti> libwnck18 | 2.17.92-0ubuntu2 | http://de.archive.ubuntu.com feisty/main Packages
<dholbach> should be 2.18.0-0ubuntu1
<seb128> dholbach: there is a bunch of things which didn't build on amd64
<dholbach> seb128: libwnck did build
<dholbach> and other stuff ftbfs because the binary is missing
<Mithrandir> seb128: go ahead
<seb128> Mithrandir: I'm running reprocess-failed-to-move
<seb128> that might fix libwnck and other builds
<seb128> 47 items there
<Mithrandir> ew
<Mithrandir> thanks
<Lutin> mvo_: btw, can I mark #86574 and #83563 as fixed ?
<seb128> np
* dholbach hugs the archiveadmins
* seb128 hugs dholbach back
<mvo_> bug  #86574  bug  #83563
<Ubugtu> Malone bug 86574 in software-properties "[apport]  software-properties-gtk crashed with NameError in add_source()" [Undecided,Fix committed]  https://launchpad.net/bugs/86574
<Ubugtu> Malone bug 83563 in update-manager "[apport]  update-manager crashed with NameError in init_proxy()" [Undecided,Fix committed]  https://launchpad.net/bugs/83563
<mvo_> Lutin: let me check
<mvo_> Lutin: yes
<Lutin> ok
<mvo_> Lutin: thanks!
<Lutin> mvo_: np
<Lutin> mvo_: I guess bug #84915 has been fixed as well
<Ubugtu> Malone bug 84915 in update-manager "exec error in DistUpgradeControler" [High,Fix committed]  https://launchpad.net/bugs/84915
<mvo_> Lutin: yes
<mvo_> Lutin: thanks
<bhale> Mithrandir: would you mind closing out uvf bug 88751 before beta hits us?
<Ubugtu> Malone bug 88751 in beagle "UVF - Beagle 0.2.16.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88751
<bhale> Mithrandir: please and thank you.
<dholbach> oooooh a new workrave version - finally finally finally
* Keybuk still doesn't use workrave
<bhale> dholbach: dose it have new dances?
<dholbach> it fixes a bunch of bugs i forwarded upstream ages ago - it took them quite a while until they rolled a new tarball
<pitti> dholbach: oh, so I can stop asking for give-backs on powerpc :) the current one failed two times due to some gnome library inconsistency
<Keybuk> fabbione: (switching to here since it's a bug)
<Keybuk> your ide device took 30s to show up, that's a little strance
<Keybuk> strange too
<Keybuk> could you mail me "lspci -vnn" output as well?
<fabbione> Keybuk: no it's not.. there are 4 scsi controllers on that machine that takes a long time to scan
<fabbione> Keybuk: 3 of them are Fc-HBA
<Keybuk> fabbione: yeah, but the ide device taking the time -> odd
<fabbione> sure  i can...
<fabbione> it's the last one to be scanned.. and it's a cdrom
<Keybuk> this is the time udev takes to process the rule, not the kernel find it
<fabbione> uh
<fabbione> on the way
<Keybuk> that's a hell of a machine
<fabbione> Keybuk: it's the T2000 Niagara + 3 FC-HBA controllers.. nothing more
<Keybuk> PHYSDEVPATH=/devices/pci0001:02/0001:02:00.0/0001:03:01.0/0001:04:00.2/0001:06:0
<Keybuk> 2.0/host1/port-1:1/end_device-1:1/target1:0:1/1:0:1:0
<fabbione> Keybuk: lucky that i didn't plug 2 of the controllers or you would see N times the same disks
<Keybuk> that's like Eurler's Koningsberg's Bridges Problem, but in PCI!
* Keybuk counts three PCI bridges there
<fabbione> Keybuk: want ssh access? :)
<fabbione> but yeah.. there are 3.. kind of weird
<Keybuk> I'd be afraid it'd try and takeover my mind over the connection
<Keybuk> I'd expect a PCI/E to PCI bridge
<fabbione> there are PCI-X and PCI-E slots only
<Keybuk> and then maybe I guess a bridge between pluggable boards or something
<fabbione> 3 PCI-E (the 3 Fc-HBA)
<StevenK> Keybuk: Euler Konigsberg, surely?
<Keybuk> sure, but you always have a PCI/E to PCI bridge so you can talk PCI at your PCI/E cards
<Keybuk> StevenK: I may be confusing the spelling with the car :p
<fabbione> 2 PCI-X one used for the internal scsi disks
<StevenK> Keybuk: Haha
<fabbione> Keybuk: + all the PCI integrated boards
<fabbione> yeah
<cjwatson> Keybuk: heh, I've been rereading "A Fire Upon The Deep" recently. If fabbione's computer is a deep-cover instance of the Blight then RUN AWAY
<Keybuk> ID_FS_USAGE=filesystem
<Keybuk> ID_FS_UUID=5dcafd4e-bbce-4d0e-a746-1d0221accc10
<Keybuk> DEVLINKS=/dev/disk/by-id/scsi-3500000e011554ee0-part1 /dev/disk/by-path/pci-0001
<Keybuk> :06:02.0-sas-0x500062b00000ad25:1:1-0x500000e011554ee2:1-part1 /dev/disk/by-uuid
<Keybuk> /5dcafd4e-bbce-4d0e-a746-1d0221accc10
<Keybuk> so it *should* be showing up
<Keybuk> oh, weird, that's for /dev/sdb not /dev/sdb1
* fabbione smells multipathd fucks up
<fabbione> yeah sdb2 is not there
<fabbione> not even as multipath entry
<fabbione> 0 lrwxrwxrwx 1 root root  30 2007-03-13 12:07 5dcafd4e-bbce-4d0e-a746-1d0221accc10 -> ../../mapper/3500000e011554ee0
<Keybuk> odd, you have a uuid for a dm-1 device as well
<fabbione> but this is the usual "added last takes over" situation
<fabbione> problem is sdb2 is just not there at all
<Keybuk> sdb2 is showing up as an LVM2 member
<fabbione>  /dev/sdb2 on / type ext3 (rw,errors=remount-ro)
<fabbione> for once i am really sure it's not LVM
<Keybuk> do vol_id /dev/sdb2 for me
<fabbione> vol_id /dev/sdb2
<fabbione> ID_FS_USAGE=raid
<fabbione> ID_FS_TYPE=LVM2_member
* fabbione looks puzzled in empty space
<Keybuk> was it an lvm2 member once, that you've quick formatted a new filesystem onto?
<fabbione> might be
<fabbione> it's a test disk/install
* fabbione attempts a cleanup
<Keybuk> oh, I see why you have a uuid for the dm-1 ... ian broke it
<Keybuk> (by-uuid is pointless for dm devices since they have fixed names anyway)
<fabbione> Keybuk: do you have a patch on the fly i can test?
<Keybuk> fabbione: not right now, give me a few hours
<fabbione> just because this thing is.. N O I S Y
<fabbione> Keybuk: ok
<fabbione> i can test it tomorrow then
<Keybuk> will look into it after lunch/ken
<fabbione> yeps that's ok
<fabbione> i am gonna power it off
<fabbione> you REMEMBER the noise, don't you? :)
<Keybuk> I remember the noise
<kwwii> dholbach: I am pushing a gdm branch with a list enabled theme (although not as default)
<kwwii> dholbach: can you check that I did the setup.py and .cfg correctly?
<iwj> OK, I give up.  How do you install a system with root-on-raid ?
<iwj> I've tried: today's feisty daily ubiquity (no apparent support for raid); edgy d-i (likewise) and dapper d-i.
<iwj> dapper is closest but I can't seem to get it to let me designate my new md device as the root fs.
<ogra> since when does ubiquity do raid ? 
<ogra> i thought only alternate does
<iwj> ogra: Apparently never but I didn't know that when I started :-).
<ogra> heh, ah ... 
<StevenK> edgy's d-i should do it
<iwj> OMG `Rebuild status : 16% complete'  but I only just created it!
<iwj> Let me check this edgy d-i again.  Maybe I made some silly mistake.
<fabbione> iwj: i used the manual partitioner in d-i
<fabbione> iwj: first create the partitions, tell d-i to use them as raid
<fabbione> go to the raid configuration menu
<fabbione> create the raid
<fabbione> go back to the partitioner, select the raid and format it/mount it.. etc
<robertj_> is it too late for items in universe to go to main for feisty if a main inclusion requests is filled out & approved? libpam-keyring is the greatest thing since sliced bread :)
<iwj> Perhaps part of the problem was that I was trying to use an LV as one of my raid components and that doesn't seem to work.
<fabbione> no d-i only supports raid on real partitions
<fabbione> best you can do is FS over LV over RAID
<iwj> fabbione: Right.  That's fine, I've cleared way for that now.
<iwj> Why does it need to rebuild it right after I've created it ??
<StevenK> Oh drat, openoffice.org-voikko got promoted.
<fabbione> iwj: it depends from the raid I think.. raid1 will just wait for that...
<StevenK> Would someone mind uploading openoffice.org-voikko  1.1-4build2 to fix #90485
<iwj> Aha!  The raid md device shows up in this list _this time_.
<Mez> anyone have any idea why my crontabs arent running (using dapper_)
* fabbione takes a break
<pitti> robertj_: it's not too late in general
<pitti> robertj_: you just need to convince iwj or me hard enough to approve it
<xerxas> how do i update to from edgy to herd5 ? 
<xerxas> without update-manager -c -d 
<iwj> OH FFS.  The two things I made the raid1 md out of are different sizes and the raid has chosen to make the md the _larger_ !
<xerxas> (I'm remotely connected)  
<pitti> xerxas: man apt-get, and #ubuntu, please
<xerxas> pitti,  sorry 
<xerxas> OT , I know apt-get / /etc/apt/sources.list 
<apokryphos> xeros: see the FAQ in #ubuntu topic
<xerxas> but that was a simple question ,  I want to update to do some bug triaging 
<Hobbsee> xerxas: it's nto development related, and either #ubuntu or #ubuntu+1 would have told you
<xerxas> ok , running update-manager -d remotely , too lazy to change /etc/apt/sources.list :)
<xerxas> sorry for OT 
<iwj> ... but only if you don't wait for it to resync.
<dholbach> kwwii: ok
<geser> ogra: are you going to upload the debdiffs for rebuilding ltspfs and linux-ntfs? or should I open bugs for it?
<bddebian> Heya
<_ion> last black
<_ion> Whoops. Should be more careful with /foreach window; forgot the / from '/last black'
<PhinnFort> ping jdong
<jdong> yes
<PhinnFort> n/m
<PhinnFort> just had some trouble setting up prevu, but suddenly it works...
<PhinnFort> got "W: Failure trying to run: chroot /var/cache/prevu/builds/21062/. mount -t proc proc /proc", but now everything is nice
<PhinnFort> it's darn nice, btw
<jdong> hmm, that would be a pbuilder failure of some sort
<jdong> don't know what would be causing it though
<PhinnFort> it seems to be running smoothly now, though
<jdong> (prevu hands over the actual build task to pbuilder, it just sets up the source code to build)
<PhinnFort> aha
<jdong> most builds don't need /proc anyway ;-?)
<PhinnFort> well, i thought the whole /proc subsystem was deprecated in Linux
<PhinnFort> ;)
<jdong> lol, no, far from that :)
<jdong> /proc is deprecated for interacting with drivers, hardware, etc
<jdong> but it is still the way of interacting with PROCcess information
<jdong> like it was meant to.
<PhinnFort> aha
<PhinnFort> that clears up some stuff;)
<PhinnFort> i always wondered what "proc" had to do with driver interfaces
<jdong> it really doesn't have anything to do
<jdong> but /proc was a nice virtual filesystem that kernel drivers can use to interact with userland
<jdong> and with nothing else available for the job, /proc got abused
<robertj_> what happened to the 2007-02-11 MainInclusionReportPamKeyring?
<PhinnFort> isn't /sys getting deprecated too, now?
<jdong> PhinnFort: really? haven't heard that.
<PhinnFort> i might have dreamt that up
<jdong> :)
<PhinnFort> ;)
<mjg59> /sys is here to stay
<bddebian>  /usr needs to die :)
<elmo> mjg59: are you using feisty on your macbook pro?
<PhinnFort> not die, just disappear
<PhinnFort> and maybe /opt
<bddebian> mjg59: Can I ask one more time about laptop-mode? :-)
<mjg59> elmo: Yes
<mjg59> Also, grub
<PhinnFort> bddebian: have you tried gobolinux?
<elmo> mjg59: meh
<mjg59> I've no idea what's up with that initrd.img stuff
<elmo> mjg59: can I install grub and have it work?
<mjg59> On xfs? Erm.
<mjg59> Probably nowadays, to be honest
<elmo> mjg59: feisty is killing me with lilo
<bddebian> PhinnFort: No, I play on GNU/Hurd though :-)
<mjg59> The only issue I'm hitting is that the keyboard doesn't always work
<mjg59> But I get the same with isolinux
<ogra> geser, i'm doing ltspfs now ...
<mjg59> bddebian: Bit busy with real work right now, I'm afraid
<sabdfl> elmo: sheesh, what's next, dropping dselect from the seeds?
<elmo> sabdfl: huh?
<sabdfl> lilo => grub...
<elmo> sabdfl: I detest lilo, I never use it unless I'm forced to
<elmo> sabdfl: always have
<sabdfl> ok
<bddebian> mjg59: All I really needed to know is if it's viable to 'fix' it in Feisty.  There are a couple LP bugs on it.
<mjg59> Probably
<bddebian> That's an autoritative answer ;-P
<danohuiginn> if I want a package to use dpatch I have to change debian/rules, right?
<mjg59> bddebian: I'm trying to finish my PhD - available time to look at LP is pretty tiny
<thom> danohuiginn: yes
<mjg59> Sorry about that
<mjg59> danohuiginn: Changing the build system can make it harder to get stuff back into Debian, though conversely using dpatch can make it easier - you need to balance the two to a certain extent
<danohuiginn> Thanks, thom. That means somebody should update http://doc.ubuntu.com/ubuntu/packagingguide/C/updating-chap.html
<bddebian> mjg59: No worries, I'm just giving you a hard time.
<elmo> mjg59: so, sorry, just to confirm, grub-install should DTRT in feisty?
<mjg59> elmo: Assuming your partition table is fine, yeah. As far as I know, it can deal with xfs now.
<mjg59> There's certainly no Mac-specific reason to use lilo
<elmo> mjg59: XFS is a red herring
<mjg59> Ok
<elmo> or at least it is for me, I'm not using it
<kylem> elmo, want to build with the patch for me?
<mjg59> In that case, yeah, go for it
<elmo> kylem: which patch is that, sorry?
<kylem> #88219
<elmo> oh, I forgot to subscribe to that
<cjwatson> elmo: yes, I'm with mjg59, grub (a) should work and (b) works for me on an iMac
<cjwatson> elmo: might need to gptsync (refit package) if you haven't done so before)
<danohuiginn> mjg59: OK, thanks. I was just trying to find the simplest way to submit a patch, and seem to have failed ;)
<mjg59> danohuiginn: If you can't upload, then debdiff is probably the easiest
<mjg59> cjwatson: If lilo's working, then the partition table is good enough (I believe)
<elmo> cjwatson: ok, I'll try that on the vein hope it may help with my assploding initramfs problems
<elmo> gptsync is happy
<elmo> already reran it
<geser> ogra: thanks
<danohuiginn> OK, mjg59. I'll do it that way
<ogra> geser, linux-ntfs done as well
<geser> thanks again
<goliath23> hi
<goliath23> does anyone know what color-palette is used in the (edgy) usplash when the text-colors are specified?
<Riddell> goliath23: #ubuntu-art (or whatever it's called) might
<goliath23> hm ok
<elmo> kylem: I think it's generating 0 byte initrd's because they're for 2.6.17 btw
<kylem> argh.
<goliath23> Riddell: do you think, you could send me the source code where I could read what palette is used in the end? on ubuntu-artwork everyone seems to be asleep
<Riddell> goliath23: https://beta.launchpad.net/ubuntu/+source/usplash-theme-ubuntu/0.12
<Riddell> without the "beta"
<elmo> kylem: also, no go on your patch
<goliath23> thanks, but thats the theme. I'd need the source of the usplash library
<kylem> elmo, no go in which sense
<elmo> kylem: still get the Fatal: empty map, and exit code of 1
<goliath23> Riddell: the one that provides usplash_backend.h I guess
<kylem> sigh.
<kylem> elmo, does the Warning: print?
<elmo> nope
<kylem> i bet the problem is that it's stat() the symlink
<goliath23> Riddell: got it
<elmo> man, feisty hates this macbook pro with a passion that I can only respect and admire
<highvoltage> elmo: hehe
<elmo> kylem: 2.6.20-10 really really hates this macbook pro
<elmo> 2.6.20-9 is a lot happier
<elmo> in fact, it's booting
<kylem> whack.
<_ion> summon pitti
<bddebian> Can someone explain to me where the hell tutos2 came from?
<elmo> so, umm, who would 'feisty doesn't work with lilo' go against?  the initramfs works fine with grub, but explodes on lilo.  not sure if that's an initramfs, linux-source or lilo bug
<elmo> Mithrandir: 91940 is another one I think that should probably be milestoned, FWIW
<Mithrandir> I'd guess at it being a lilo bug with lilo not managing to load the whole initramfs or something like that
<elmo> Mithrandir: ok, thanks, will report that in a sec
<Mithrandir> thanks, looking
<kylem> elmo, can you try passing in libata.display_hpa=0 to 2.6.20-10?
<hunger> cpu frequency scaling seems to be broken on my thinkpad. is that a known issue with the feisty -9-generic kernel?
<Seiya> Scaling appears to be working normally on my thinkpad
<hunger> Hmmm... setting it to powersave throttles my cpu.
<hunger> Dynamic always runs at max speed, even is the box is 98% idle.
<Seiya> Definitely not the behavior I'm seeing on my T40
<Ng> -9-generic seems ok on my thinkpad atm
<Ng> of course I've completely forgotten how to find out which scaler I'm using
<Seiya> I'm actually using KDE at the moment, but that really shouldn't make that big a difference
<hunger> powersave works as expected...
<hunger> Seiya: So do I.
<iwj> I'm amazed anyone is using root-on-raid at all, seeing how flakey this all is.
<hunger> performance is fine as well, but dynamic seems to be identical to performance:-)
<Seiya> Got me, then
<Seiya> What model thinkpad?
<hunger> Seiya: T43p.
<geser> Ng: look in /sys/devices/system/cpu/cpu0/cpufreq/
<siretart> iwj: it was quite stable and reliable in dapper and edgy, it sucks in feisty :/
<iwj> siretart: Well, the edgy installer hasn't impressed me with it so far.
<Ng> geser: ta
<iwj> And now my upgrade has bombed out in a crazy way.
<siretart> iwj: TBH, I've used the dapper live cd and created the raid volumes and volume groups manually, then rsync'ed an existing rootfs over
<iwj> siretart: Yers.
<siretart> iwj: I made much better experiences with the debian installer
<hunger> Seiya: You are right... after switching back and forth for a while it works for me as well.
<iwj> I might well take that approach myself.
<hunger> Seiya: Strange... I'll have to keep an eye on this.
<iwj> I mean I've spent most of the day so far just trying to get to a point where I can reproduce your bug ...
<siretart> :(
<iwj> The thing that makes /initrd.img.old empty is particularly annoying.  Why oh why etc. etc. ??
<iwj> Are usage messages from modprobe expected ?
<iwj> In the initramfs.
<iwj> Yay!  I have reproduced your bug!
<mjg59> elmo: ^
<elmo> the one I haven't even filed yet?  neato
<mjg59> So b0rked initramfs seems reproducible
<iwj> elmo: ... ?
<iwj> I'm talking about bug 75681.
<Ubugtu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<mjg59> iwj: elmo had broken initramfs images earler, which then in turn broke lilo
<iwj> I'm not sure that's the same thing.
<iwj> elmo: You mean the `empty map file' thing ?
<elmo> iwj: no, I mean the usage message from modprobe
<elmo> that sounds like the breakage I had, when I tried to use lilo on feisty
<iwj> elmo: Oh, I think they're a red herring.
<elmo> ok
<elmo> well we may be talking about very different things
<iwj> But you have a machine that doesn't boot I taken it then ?
<elmo> iwj: yes, a Macbook Pro, using lilo
<elmo> it boots fine with grub though
<iwj> Mmmhmm.
<elmo> no root-on-raid or lvm or any other of that jazz
<iwj> Oh.
<elmo> it's a simple ext3 fs
<iwj> Dunno what that is.
<cjwatson> it's not fallout from hda->sda migration is it?
<iwj> I don't think it's related to modprobe and my lilo systems boot fine except for the fact that they're all root-on-weirdshit.
<cjwatson> i.e. device major number now being wrong?
<iwj> cjwatson: Sounds like a good bet to me.
<iwj> elmo: Can you do me a favour and try an experiment ?
<kylem> that doesn't explain why it works alright with grub...
<elmo> iwj: not right now, no - it's not my laptop and the person who owns it is using it to work :)
<iwj> Oh :-).
<cjwatson> kylem: grub has UUID handling ...
<kylem> hmm, true.
<cjwatson> could be lilo.conf just wasn't munged appropriately, whereas grub munges its own menu.lst
<kylem> elmo, could they run 'rdev /vmlinuz'? :)
<iwj> I had a bug here where lilo looks up the devino of the root fs and then encodes those numbers into your boot setup.
<iwj> This is nowadays wrong.
<kylem> everything lilo does is wrong nowadays...
<iwj> The answer is to move root=... from being a lilo directive to a kernel command line arg in append=.  Ie,  append="root=/dev/something rest of append thing goes here"
<iwj> The only trouble with this setup for reproducing this md bug is that I've used a usb stick as one of the raid components to make sure I always lose the race.  Which is fine but usb sticks are damn slow.
<Riddell> cjwatson: is the ubiquity warning page being kept for beta?
<cjwatson> Riddell: the intro?
<Riddell> cjwatson: the warning this is not a final release.  I can't remember if it gets removed before or after the beta
<cjwatson> Riddell: no, I'll remove it; thanks for reminding me
<Riddell> cjwatson: hmm, if I don't format the partition for / I don't get any warning, but there's an error part way into the install
<cjwatson> Riddell: version of ubiquity? I fixed that recently
<Riddell> cjwatson: today's daily CD, Kubuntu
<Riddell> 1.3.26
<cjwatson> ubiquity (1.3.27) feisty; urgency=low
<elmo> kylem: oh, the person with the laptop snuck off :-( I'll have to finish testing tomorrow
<cjwatson>   * New partitioner: Add validation for system partitions being formatted
<cjwatson>     (LP: #89461).
<cjwatson> your livefs is out of date
<kylem> ok
<ogra> does anybody else see weird behavior with the latest firefox ? 
<ogra> seems it cant open any non local page here ... 
<ogra> oh, i lied, it just takes 5min to open a webpage
<ogra> hmm
<pitti> carlos: oh, fresh langpacks from today :)
<carlos> pitti: we do them every day ;-)
<pitti> seb128: I started building current langpacks and will upload tonight; did you see any problem with yesterday's? the German ones worked great
<pitti> ogra, mvo, seb128: thoroughly testing restricted-manager again would be appreciated; a lot of code improvements in 0.5 and 0.6
<_ion> pitti: I think i fixed the problem with nvidia_legacy still being visible some times. I had erroneously put the parsing of modalias.overwrite *after* the module cache was saved.
<pitti> ah :)
<ogra> BenC, did anything change wrt networking in the recent kernel ? i cant get pings with a 128 byte packetsize and above through ... 
<_ion> pitti: I've pushed the change to my branch.
* pitti merges
<BenC> ogra: bcm43xx?
<pkern> Do you produce installer images for USB sticks somewhere?
<ogra> pitti, i'd love to, but currrently i can be happy to have an IRC connection it seems ...
<ogra> BenC, yep
<ogra> i saw nothing in the changelog
<pitti> ogra: ah, alright :/
<ogra> but it looks like a driver prob
<BenC> ogra: None that I'm aware of
<pkern> Hm yes... http://de.archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386/current/images/netboot/ ... Ok, not really hidden.
<bluefoxicy> In case anyone hasn't noticed, Dell's Linux survey asks what kind of commercially supported distro you would like to see installed on Dell systems
<pitti> carlos: will the feisty tarballs continue to be generated in the afternoon, or will you move them to the mornings again? and back to a weekly cycle?
<bluefoxicy> One choice is Ubuntu.  So everyone clap for yourselves, because you did a good enough job to get on Dell's radar without being a multi-million dollar publicly traded stock.
<iwj> siretart: AYT?  Could you email me (iwj@ubuntu.com) your initramfs ?  Unless it has a password or something in it ...
<seb128> pitti: will try the language pack now, I've been swamped with GNOME 2.18 since yesterday
<pitti> seb128: oh, don't worry
<carlos> pitti: well, I don't understand how's that it takes so long to be generated...
<pitti> seb128: if you wait for another hour or so, you can test the new ones right away
<carlos> pitti: and didn't have time to see what's going on
<seb128> pitti: k, will do that then, I still have to fix libgnomeui and gtk updates for GNOME 2.18
<pitti> carlos: ok, no problem
<pitti> carlos: after those, I'll just generate them together with the stable ones in the morning and stop worrying about them
* pitti hugs seb128
<pitti> seb128: sorry for bothering you then, I'll find other guys to hassle :)
<carlos> pitti: ok
<Lure> pitti: can you review https://wiki.ubuntu.com/MainInclusionReportDigikamImagePlugins when you find some time?
<pitti> Mithrandir: I'd like to upload the feisty langpack flood this evening; just want to confirm that's ok with you?
* seb128 hugs pitti, you don't bother me, I'm happy to test, the GNOME 2.18 update has had some bugs and it took some time, it's mostly sorted now
<Mithrandir> pitti: go for it.
<siretart> iwj: as soon as I return home (ETA ~2h)
<pitti> Lure: what's the urgency? "OMG, we need it yesterday for the beta freeze" or slightly lower?
<iwj> siretart: OK.
<Lure> pitti: lower, it is just in supported now, but may get on cd after beta
<iwj> siretart: When you do you might like to try removing /usr/share/initramfs-tools/scripts/local-top/mdrun and updating your initramfs.
<Lure> pitti: if space allows it
<pitti> Lure: ok, non-CD packags can be promoted later still
<siretart> iwj: sounds scary, because I need that script to boot my system..
<pitti> Lure: then I'll do my OMGbetafreeze tasks first, if that's ok with you
<siretart> (by manually calling it)
<iwj> siretart: Oh.
<iwj> You do have a spare initramfs though don't you ?
<iwj> I suppose you probably don't.
<Lure> pitti: no problem, was just told that it is best to ping you when we have MIR ready ;-)
<pitti> Lure: right, and please continue nagging me if I forget
<siretart> iwj: that can be arranged.. ;)
<Lure> pitti: will do after beta, thanks ;-)
<iwj> This whole wobbly pile is far to fragile and the thing has no proper plan B setup.
<iwj> So err sorry if I break your system with my crazy requests.
<iwj> Unfortunately my copy of your symptoms seems to have gone away.
<siretart> oh
<iwj> But I have a different set of symptoms which I think are due to lilo and perhaps when I've investigated and fixed those it will be better.
<siretart> the system is already broken for weeks, but that's it with development versions :/
<iwj> Quite.
<siretart> ok, driving home now
<iwj> You should have, I think, /usr/share/initramfs-tools/scripts/local-top/mdadm too.  That's the correct script which should DTRT.
<siretart> cu later!
<iwj> ttfn
<pitti> carlos: https://translations.beta.launchpad.net/ubuntu/feisty/+source/restricted-manager/+translations -> no templates available; how come? I thought universe was imported as well?
<bddebian> pitti: phpmymoney has been orphaned in Debian and hasn't seen an upstream update since 2003 afaics.  Do you think we should drop it?
<pitti> bddebian: I'm all for decruftification :)
<carlos> pitti: no, universe is not yet imported
<pitti> carlos: ah, ok; doing the good old vi po/de.po then :)
<bddebian> pitti: Well if it stays in Debian, will it just get re-synced again?
<carlos> pitti: ;-)
<pitti> bddebian: I don't know yet; I wasn't yet introduced to the technical side of blacklisting
<bddebian> Ahh :-)
<pitti> Keybuk, Mithrandir: is there a blacklist on drescher where I should add removed packages which should not be resynced?
<Keybuk> pitti: /srv/launchpad.net/dak/sync-blacklist.txt
<pitti> Keybuk: thanks; I'll add that to ArchiveAdmin
<PhinnFort> jdong: ping, again
<cjwatson> pitti: (note that that's in bzr)
<pitti> Keybuk: hmm, the 'Be sure to "bzr commit" after any changes.' is not to be taken too seriously? :)
<pitti> cjwatson: right, with lots of uncommitted changes
<alex-weej> does anybody feel like upping the importance of this? https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/78288
<Ubugtu> Malone bug 78288 in linux-source-2.6.20 "kernel 2.6.20-10 doesn't boot with sata-hd" [Medium,Confirmed]  
<bddebian> pitti: I guess my question is more:  Do I attempt it with PHP5 or not bother? :-)
<Keybuk> pitti: bad people
<pitti> bddebian: *shrug* I don't know; Personally I couldn't care less about that php stuff
<pitti> Keybuk: I'll commit it now
<bddebian> pitti: Know anyone that does? :-)
<pitti> bddebian: I'll just kill it; really noone should use 4 years old php software; it's got more holes in it than Swiss cheese, probably
<iwj> elmo: If I were to feed you a sh fragment that I was going to try putting in the lilo postinst to fix up this root= problem, would you be able to test it ?
<iwj> siretart: Now I've fixed my lilo problem the md race has gone away for me but I do think it's still there lurking in that mdrun script.
<elmo> iwj: the laptop has left the building - but I can test it tomorrow for you
<pitti> bddebian: there it goes  /me makes a flushing noise
<bddebian> pitti: :)
<mvo> iwj: can you give me a hint when dpkg throws this error: "dpkg: error processing wpasupplicant (--remove):
<mvo>  Package is in a very bad inconsistent state - you should reinstall it before attempting a removal." ? is there anything that the user can do if he does not have the original package anymore?
* kwwii is out for dinner
<iwj> mvo: Best thing is to dpkg -i as similar a .deb as can be found.
<iwj> Err on the side of an earlier one.
<iwj> This state can only arise if dpkg's unpack is interrupted eg by the system crashing or dpkg crashing or some such.
<mvo> iwj: ok, thanks
<cjwatson> Mithrandir: could you give-back gnome-panel/amd64?
<cjwatson> at least the reported problem should be fixed now
<seb128> there is probably a lot of other packages to build retry on amd64 and ppc
<seb128> cjwatson: do you know if other builds have been retried yet?
<cjwatson> yes, but that's the one that's obviously blocking my feisty upgrade ... :)
<cjwatson> I don't know
<seb128> ah ok ;)
<seb128> I'll have a look and make a list
<cjwatson> quite impressively too, there's a Breaks/Depends loop and apt-get just refuses to do anything
<cjwatson> I'll try just upgrading the kernel and related stuff, which is what I actually need
<mdz> mvo: around?
<mdz> mvo_: how about you?
<mvo_> mdz: hello!
<mdz> mvo_: I'm attempting an upgrade test from 6.10 to feisty, and update-manager failed. I've pasted you the output in /ms
<mdz>  /msg, even
<mvo_> mdz: please update your update-manager to the version in edgy-proposed
<mvo_> mdz: that should fix the problem
<mdz> mvo_: eek. who is affected?
<mdz> this is a bone stock 6.10 install in vmware
<mvo_> mdz: the update is uploaded to edgy-updates as well, but not yet approved
<mvo_> mdz: everyone without a .gnupg dir :(
<mdz> I'll create a .gnupg dir for now
<mvo_> mdz: that will fix it as well
<mdz> mvo_: have you already spoken to an archive admin about accepting it?  this is fairly critical for upgrade testing
<pitti> mvo_, mdz: we talked about it yesterday; if mvo_ uploaded the fix now, I'll accept it
<mvo_> mdz: I haven't pushed for it yet, its only recently sru-verified (it was in the queue for sru-verification for some time, but the queue was processed slowly)
<mvo_> pitti: its uploaded
<mdz> mvo_: at what point will 6.10 start to recognize feisty CDs as an upgrade opportunity?
<pitti> mvo_: eek, config.{guess,sub} changes
<pitti> mvo_: after getting bitten by 30 bug duplicates about a broken hal because of autotools changes, I have to refuse this
<mvo_> pitti: ok, I will reupload
<pitti> mvo_: ok, rejected, you are free to upload again
<pitti> mvo_: sorry for the hassle
<mdz> pitti: if that's to be standard policy, please document it on StableReleaseUpdates as it will be a common error
<pitti> mdz: it is actually; 'please make sure that there are no changes except the changelog' or sth. similar
<pitti> "The package difference must be a minimal change to fix the bug. Spurious changes to build systems, documentation, functionality will be rejected."
<pitti> and "Make no other changes relative to the version in -proposed."
<pitti> (relative to 'add a changelog entry')
<mdz> pitti: oh, the version in -proposed didn't update those files?
<mdz> pitti: if they can cause problems, we probably shouldn't change them in -proposed either
<pitti> mdz: I'm not sure; but I'm anal about the -proposed vs. -updates diff being only the changelog
<pitti> i. e. release exactly what has been tested in -proposed
<mdz> agreed; once LP supports it that will be an exact copy, binaries and all
<pitti> mdz: I agree, and I usually complain about them
<crimsun> sabdfl: Ben informed me that Feisty's 2.6.20-10.17 regressed your audio. When you have a moment, please attach separately the requested info from the "Reporting Sound Bugs" section on https://help.ubuntu.com/community/DebuggingSoundProblems to bug 69529  (if that X60 is in fact the affected one)
<Ubugtu> Malone bug 69529 in linux-source-2.6.17 "Sound intermittently not working on ThinkPad X60" [Medium,In progress]  https://launchpad.net/bugs/69529
<pitti> mdz: I'm strict for main, and less strict for universe (e. g. config.guess/sub should usually be harmless)
<mdz> pitti: I think that's appropriate
<mvo_> mdz: cd detection should work, I will test that now in vmware
<pitti> mvo_: it worked for me, but it doesn't offer upgrading; just 'start synaptic' and 'ignore'
<pitti> mvo_: (or something similar to 'ignore')
<mvo_> mdz, pitti: it has the same .gnupg dir problem  :/
<pitti> mvo_: hm, that worked for me with just edgy-proposed; I tested that carefullyh
<mdz> mvo_: I just tried it; it was only detected as a CD with packages on it
<pitti> mdz: likewise; I had to do 'sudo sh /cdrom/cdromupgrade', that worked without the -proposed fix
<mvo_> mdz: after you added .gnupg ? did it detect it correctly then?
<mdz> mvo_: oh, I did not attempt that
<mdz> I will try that now
<mvo_> mdz: sorry for. its the same bug as before, gnupg insists in creating a $GNUPGHOME/trustedb file whatever option you give it
<mdz> mvo_: yes, I remember this from apt-key. it is not very cooperative
<mdz> I tried everything to suppress that
<mdz> in the end I had to use --trustdb-name
<mdz> mvo_: is that how you fixed this one as well?
<wick2o> afternoon
<elmo> mvo_: are you using gpgv?
<elmo> + yet - those kind of issues go away when you do
<mvo_> mdz: I set --homedir to the tempdir that is used for the extraction
<elmo> obviously I realise it's too late for edgy, I mean for feisty onwards
<mdz> mvo_: ok, after creating .gnupg, I get Cancel/Start Package Manager/Run Upgrade
<mdz> mvo_: it would be nice if we could improve that dialog
<mvo_> elmo: currently I use the python GnuPGInterface 
<mvo_> mdz: improve in what way exactly?
<mdz> it's not very clear what it means; it should say that it's a new version of Ubuntu and ask if they want to upgrade
<mdz> It says "A distribution volume with software packages has been detected"
<mdz> it should say something like "This volume contains a new release of Ubuntu.  Would you like to upgrade to it?  Don't upgrade/Upgrade"
<wick2o> APPEND debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/preseed/ubuntu-custom.seed initrd=/install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
<mdz> and preferably state the version
<wick2o> anything in there jump out at anyone as being wrong?
<wick2o> the debain-installer and kbd-chooser doesnt seem to work
<mvo_> mdz: ok, I will do that
<wick2o> the preseeded stuff works great
<mdz> mvo_: the dialog about whether to use the network could be tweaked as well, while you're there
<mvo_> mdz: I'm happy to do that, what bits are unclear?
<mdz> "Include latest updates from the Internet?"  "The upgrade process can automatically download the latest updates and install them during the upgrade.  The upgrade will take longer, but when it is complete, your system will be fully up to date.  You can choose not to do this, but you should install the latest updates soon after upgrading."  "Install updates/Skip updates"
<mvo_> mdz: thanks, that sounds much better indeed
<mdz> (install updates should be the default option of course, I reversed the button order)
<mdz> mvo_: what happens if the user has packages from universe installed and they attempt a CD upgrade?
<mvo_> mdz: a lot of packages will be kept back, but otherwise it should work. when he runs a apt-get update with network next time u-m will prompt to finish the upgrade
<mdz> mvo_: that's pretty good
<mdz> mvo_: I wonder how many universe packages tolerate it, though
<mdz> partial upgrades won't be well tested
* pitti discovers ctrl+shift+t in firefox - how useful!
<mvo_> mdz: its only as good as the apt problem resolver
<cjwatson> wick2o: what release of Ubuntu?
<mvo_> mdz: I can do some testing on this though
<mdz> pitti: what does it do?
<pitti> mdz: restores the most recently closed tab
<mdz> mvo_: I was also thinking that because downloading and installing the updates are separate progress bars, they should be separate steps in the dialog too.  what do you think?
<pitti> the 'whoops, ctrl+w' undo
<mdz> mvo_: so instead of preparing/modifying/downloading+installing/..., preparing/modifying/downloading/installing/...
<mdz> mvo_: does the API support that?
<mvo_> mdz: that should be straightforward to add
<mdz> mvo_: ok, I'll file a bug
<mvo_> mdz: thanks
<mdz> pitti: oh, how nice
<pitti> mdz: one of those small and nice things you discover when releasing shift too late :)
<_ion> pitti: I got rid of "whoops, ^W" problems by making Gtk use Emacs key bindings. :-)
<mdz> pitti: I usually "discover" my xchat closing
<_ion> pitti: Now ^W does the right thing in text fields, even in Firefox.
<mdz> because I remapped close to shift+ctrl+w to be able to use it for kill-word
<mdz> _ion: that used to DTRT, but no longer
<Keybuk> pitti: what does that one do?
<pitti> Keybuk: <pitti> mdz: restores the most recently closed tab
<dneary> Hi
<dneary> jono: About?
<mdz> mvo_: does update-manager attempt to check whether it is out of date with -updates before doing an upgrade?
<jono> dneary: two ticks, phone
<dneary> jono: No rush, I'm between raindrops and was looking for a chinwag
<mdz> mvo_: do you think that would be a good idea?
<mvo_> mdz: currently not, but it is on the list of things to implement. its a good idea for sure, lack of time was the problem so far 
<mdz> since anyone who has not installed updates for 10 days at beta will not be able to upgrade
<mdz> mvo_: understood
<mdz> I guess the thing to do would be to provide a simple way to upgrade only update-manager and nothing else
<mdz> to avoid having to install 6 months of updates just to upgrade to the next release
<mvo_> mdz: the way the system is designed (downloading the special upgrade tarball) we come close already. I was thinking of adding a dependency mechanism to this as well so that it can check if it has e.g. the version of adept apt it needs etc. this should be straightfoward to implement and will avoid problems. it espcially important for the kde-part of u-m as this needs a updated konsole otherwise it will not work at all
<mdz> mvo_: hmm, you're right. it would be better to make them dependencies of the upgrader than of update-manager
<mdz> pseudo-dependencies, anyway
<mvo_> mdz: yes, that was what I was thinking. it could even update the required packages before it starts etc
<mdz> mvo_: hmm, I suppose we would need to include (N-1)-updates on the (N) CDs
<mdz> to fully support upgrades without internet access
<mvo_> mdz: yes, we are not very good at this currently. it works for ubuntu CD->CD upgrades on systems that haven't used the net. but for e.g. kubuntu it will not work as it is right now
<mdz> mvo_: right, i mean that to implement the pre-dependency feature for the upgrader, we would need to start doing that
<mvo_> mdz: right
<mdz> mvo_: do you think it is likely that we will encounter this situation again, so that it is worthwhile to implement this feature proactively?
<mdz> implementing it in the upgrader itself has the nice property that we don't need to do it in advance; we can wait and do it only if needed
<mvo_> mdz: I think its likely - the chances to have a anoying bug that needs to be fixed prior the upgrade are there
<wick2o> cjwatson: dapper
<wick2o> 6.06.1 -server
<wick2o> sorry for the late response, computer went down at work
<pitti> seb128: there, new langpacks!
<pitti> Riddell: are you interested in giving the French KDE feisty langpacks a quick test?
<seb128> pitti: same place as usual?
<pitti> seb128: yup
<pitti> deb http://people.ubuntu.com/~pitti/langpacks/daily/feisty/ ./
<pitti> seb128, Riddell: ^
<mdz> mvo_: ok, I'll put it on the agenda for UDS then
<Riddell> pitti: sure
* pitti uploads the third restricted-manager version for today to close the last open bug report and fix it harder
<pitti> ^ new testing bait for the ATI-owning folks (Nvidia testing appreciated as well)
<pitti> mvo_: FYI, nothing yet in the edgy-updates queue; did the upload fail or didn't you do it yet?
<mvo_> pitti: in 2 minutes, building it in a chroot now
<pitti> mvo_: ah, ok; no hurry, just checking
<cjwatson> wick2o: looks fine; check /proc/cmdline after booting to make sure that those options are really being used
<mvo_> pitti: uploaded now
<wick2o> cjwatson: cjwatson checkin it out now..
<pitti> mvo_: accepted, thanks
<mvo_> pitti: cool, thanks
<wick2o> cjwatson: i think i found my error, for some reason when id copy the iso to my usb key and then unmount it wouldnt override the copy that was already there, so when i tried it in vmware it didnt work because it was an older image that didnt have the changes :\...at leasat this is my theory since it works with qemu
<wick2o> ill give it another go after an rm of the iso and i recopy to my usbkey
<wick2o> if this was my problem, i swear i should be stabbed
<wick2o> :)
<iwj> siretart: Any progress with(out) .../mdrun ?
<jwendell> keescook, around?
<keescook> jwendell: howdy, yup.  what's up?
<jwendell> keescook, there is a new upstream version (security fix) for vnc4 (4.1.2). Did you know or should i fill a bug about it?
<keescook> jwendell: does it have a CVE associated with it?
<jwendell> keescook, no, but this version is from may,2006 !!
<jwendell> keescook, http://www.realvnc.com/
<keescook> Hm, I suspect that's already been taken care of: https://launchpad.net/ubuntu/edgy/+source/vnc4/+changelog
<keescook> unfortunately, edgy and feisty's vnc4 aren't stable and no one has figured out why.  :(
<jwendell> keescook, ah, right. why ubuntu's version number is different from upstream?
<keescook> jwendell: because when doing security fixes, only the fixes are back-ported.
<keescook> i.e. the version number stays the same.
<iwj> This modem wasn't working because of a _faulty telephone cable_ between the laptop and the wall socket!  Honestly.
<jwendell> keescook, that's not the feisty case, right?
<keescook> jwendell: in feisty's case, no one has packaged 4.1.2, so the fixes were just backported to the existing package.
<keescook> jwendell: if you wanted to figure out why edgy/feisty doesn't work, I (and maybe people) would be very grateful
<keescook> https://launchpad.net/bugs/78282
<Ubugtu> Malone bug 78282 in vnc4 "vnc4server does not start Desktop environment after security update" [High,Confirmed]  
<jwendell> keescook, it works for me
<jwendell> keescook, as client. as server i use vino :)
<keescook> jwendell: heh.  okay, fair enough.  The security issue was only on the server side, IIRC.
<_MMA_> Hi guys. How do I find out if something in Main will get updated? Mainly (hehe) wacom-tools and xserver-xorg-input-wacom.
<_MMA_> I was helping a user on the forums with a HOW-TO I maintain. http://ubuntuforums.org/showthread.php?t=25151 I realized that the version of wacom-tools he needed was  0.7.6-4 and Ubuntu (Feisty) uses 0.7.2.
<Mithrandir> cjwatson: given-back
<cjwatson> thanks
<kronoman> I think Ubuntu needs a better crash-in-boot handling
<kronoman> to make easier for novice users to recover after a crash (i.e hard disk crash)
<wick2o> kronoman: i think there are way too many varables for that to happen
<wick2o> its not like windows has very good crash-in-boot handling either
<kronoman> maybe just a menu with options to call fsck, badblocks, etc
<kronoman> instead of dumping to a root terminal
<wick2o> honestly, if it happends that often that you would need a menu, id think it would be time to replace the harddrive ;)
<wick2o> i guess they COULD setup a bit or a 0/1 somewhere in /proc for "did my system crash"
<wick2o> and run fsck or its true
<wick2o> i wouldnt that it would be that hard for you to create your own bash script with these functions
<kronoman> really, I just crashed once and replaced the disk after data recovery, but I thought, if this happens to a normal user.... 
<kronoman> I mean, the concept of dumping to a root terminal if the system crashes goes against the "for human beings" thingy
<sabdfl> crimsun: ok, am filing bug with all that data
<crimsun> sabdfl: thanks
<wick2o> kronoman: true i guess
<wick2o> i mostly use ubuntu-server...i a huge fan of the LTS build
<wick2o> if that continues ( a realse every 5 or so years with full sec. updates) im going to switch all my servers over the ubunut
<sabdfl> crimsun: https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92005
<Ubugtu> Malone bug 92005 in linux-source-2.6.20 "Sound not working on x60 with 2.6.20-10 in feisty beta" [Undecided,Unconfirmed]  
<crimsun> sabdfl: looking.
<siretart> iwj: puh. returned from lunch, sitting at my workstation now
<crimsun> sabdfl: it actually should work fine presently, but likely you'll need to try [echo options snd-hda-intel model=thinkpad |sudo tee -a /etc/modprobe.d/alsa-base]  if it's still inaudible in the next kernel
<shawarma> siretart: Lunch?!? Arent' you in Germany?
<siretart> iwj: surprisingly, the system bootet without intervention after an system upgrade. let's see if it was only luck
<siretart> shawarma: s/lunch/dinner/
<siretart> ;)
<shawarma> siretart: Oh.
<shawarma> siretart: :-)
<Treenaks> hacking so hard, you forget time ;)
<siretart> Treenaks: I was on a buisness trip to munich for two days, and have just returned home
<Treenaks> siretart: blame it on jet lag -- germany is so big 8)
<siretart> Treenaks: ;)
<siretart> iwj: ok, reboot failed then :(
<pitti> Riddell, seb128: good to upload the current langpacks?
<mdz> wick2o: we do need a simple way to force a check; that's on the discussion agenda for the next summit
<mdz> as for doing something intelligent if the root filesystem is corrupted, that's a tough one
<mdz> it's not safe to bring the system up far enough to behave in a friendly way
<Riddell> pitti: works fine for me
<pitti> Riddell: great, thanks for testing
<siretart> iwj: okay, I now removed the local-top/mdadm script, with the behavior, that NONE md volumes appear in /proc/mdstat. Before I had one of four devices listed
<siretart> iwj: another difference is that udevtrigger doesn't help anymore
<_ion> Ooo, cool. I don't know whether it's a new feature in libvte or xfce4-terminal, but now the background colors of the bottom line and the rightmost column are spread to the window boundary if the window size isn't a multiple of the font size.
<Adri2000> http://librarian.launchpad.net/6335769/buildlog_ubuntu-feisty-i386.avidemux_1%3A2.3.0-0.0ubuntu2_FAILEDTOBUILD.txt.gz < any idea how to fix that is welcome... Mithrandir maybe?
<siretart> iwj: initramfs is underway
<juliux> hi, it is possible to copy the ubuntu desktop cd image to an usb stick and to start the live system from the usb stick? i don't want to install ubuntu on the usb stick
<iwj> siretart: No, I wanted you to remove the _mdrun_ script.  You should have an _mdadm_ script too which is the one I think is correct.
<iwj> But thanks for the initramfs.  Must go now but I'll look at it tomorrow.
<lando> what version of gnome will feisty ship with?
<pochu> lando: 2.18
<lando> ah thanks 
<lando> um u sure? the gnome site states that 2.16 is the latest
<seb128> lando: it already has 2.18
<seb128> lando: 2.18 official date is tomorrow
<lando> nice thanks 
<seb128> np
<Mithrandir> seb128: I'm doing a bunch of give-backs on gnome stuff, so if you get duplicated ftbfs messages, you know why.
<seb128> Mithrandir: yeah, thank you, I was going to make a list but if you can do massive retry that's better
<seb128> Mithrandir: probably due to the packages which have not been moved correctly and were not installable on amd64 and ppc
<Mithrandir> seb128: nah, I go through the list of out-of-dates, that's easy enough.
<seb128> ok
<Mithrandir> seb128: yeah, that's what I think too
<sabdfl> tepsipakki: ping, #ubuntu-meeting
<sabdfl> mjg59: we have two -core-dev applications in #ubuntu-meeting if you have a sec
<danohuiginn> anyone here got time to review two simple patches? bug 91694 and bug 91695
<Ubugtu> Malone bug 91694 in cgoban "No .desktop file" [Undecided,In progress]  https://launchpad.net/bugs/91694
<Ubugtu> Malone bug 91695 in gtkgo "Missing a .desktop file" [Undecided,Confirmed]  https://launchpad.net/bugs/91695
<danohuiginn> both just adding in application menu items
<pochu> danohuiginn: are both packages in main?
<danohuiginn> no, both in universe
<pochu> danohuiginn: then it's better that you ask in #ubuntu-motu ;)
<danohuiginn> OK. Thanks, pochu. One day I'll work out what channel is for what
<pochu> danohuiginn: yw
#ubuntu-devel 2007-03-14
<ne78> All window clients using the new xcb backed Xlib make an _XCBUnlockDisplay error. is there a solution ?
<cjwatson> I would just like to say that filesystem corruption in /lib/udev/devices/std{in,out,err} is particularly annoying to try to recover from
<jdong> is restricted-manager to be installed by default?
<mdz> jdong: that's the plan
<jdong> mdz: awesome, that's nice to hear :)
<mdz> cjwatson: I wonder why those aren't created on the fly
<jdong> mdz: will it be made apparent to users that Restricted Manager is available?
<jdong> i.e. if fglrx/nvidia cards are detected, pop up a first-boot notification bubble, etc
<mdz> jdong: it will be in the menu and the release notes; do you mean something more?
<mdz> jdong: something along those lines is intended, yes
<jdong> mdz:  yeah, having it inform the user "Additional 3D acceleration is available for your hardware through proprietary drivers. Click this icon for more info" would be good.
<cjwatson> mdz: Debian's udev has the facility to do it, but for some reason Scott decided it was evil
<bddebian> Sounds evil :-)
<cjwatson> and indeed I think Debian's udev is configured that way by default, with /etc/udev/links.conf
<jdong> bddebian: how about a little BonziBuddy-like GPL advisor (like a RMS buddy? :D)
<mdz> cjwatson: I expect there are already plenty of targets in /lib such that corruption is more likely to take out something else critical
<cjwatson> it's curious that just those three inodes got clobbered
<bddebian> jdong: Haha.  Yeah he pops up "THAT SOFTWARE IS NON_FREE!!"
<cjwatson> they seem unusually related for random corruption
<jdong> bddebian: New Malone bug 666666 in restricted-manager "RMS buddy leaves facial hair artifacts after closing" [High, Confirmed] 
<bddebian> haha
<kronoman> I think that Ubuntu needs a better failure recovery, for novice users
<kronoman> I mean, the concept of dumping to a root terminal if the system crashes goes against the "for human beings" thingy
<cjwatson> kronoman: you've made your point multiple times now, and mdz commented on it earlier as well. I don't think it's necessary to keep bringing it up
<mdz> maybe it's a bot
<cjwatson> there are enough variations that I think not
<lifeless> markov chain?
<Arch_NME> personally motivated suggestion... develop some support for cellular internet services into future ubuntu release
<Arch_NME> that is all
<TheMuso> c
<TheMuso> damn kvm
<jdong> I'm guessing not the virtualization solution :)
<TheMuso> jdong: no
* kronoman is back in the house
<kronoman> cjwatson: so, is worth that I start coding something like that ? or is already done ?
<kronoman> cjwatson: I could make like a 'agent' that could guide the user in the recovery steps
<fabbione> morning
<Fujitsu> Hi fabbione.
<fabbione> yo
* fabbione prepares the sodomotron to kill somebody
<Fujitsu> fabbione: Who broke what?
<fabbione> update from yesterday to today.. something took down my network.. network manager told NOT to touch my wired network, was spinning at 100% CPU unkillable and unable to reconfigure my network interface.. = full lock of the machine
<fabbione> now i have tons of corrupted crap in my /home
<fabbione> somebody is going to suffer a lot of pain today
<Fujitsu> Ouch.
<Fujitsu> My NM exploded when I upgraded this afternoon, too... But it didn't kill the machine.
<fabbione> the machine was killed because i have some stuff over nfs
<Fujitsu> Oh.
<fabbione> NM should not have touched my network since i told it NOT too in the first place
<Fujitsu> Heh, heh, heh.
<Fujitsu> That was the change, I believe.
<Fujitsu> You might want to check the changelog.
<fabbione> Fujitsu: already done...
<Lutin> hey there
<Lutin> doko: are you around ?
<doko> Lutin: not really ...
<Lutin> doko: ok, see you later then
<Mithrandir> mdke: regarding 82335> if you believe my fix doesn't cover all the cases, please tell me what you don't think is covered by my fix and I will be happy to take a look at that.
<fabbione> Mithrandir: mind to check outdate for ppc? i think gnome-panel-data is outdated... 
<fabbione> or tell me where it is now and i will look at it
<Mithrandir> stuff moved to http://people.ubuntu.com/~ubuntu-archive/
<Mithrandir> I should send a mail to u-d-a about it.
<fabbione> thanks
<fabbione> Mithrandir: i guess ppc could use a general giveback
<Mithrandir> pitti: you win 42 new source language packs. :-)
<pitti> Mithrandir: accepted 30 seconds ago :)
<Mithrandir> pitti: great. :-)
<pitti> Good morning everyone, btw
<mvo> good morning pitti
<mantiena> heloo all
<mantiena> There are no builds at cdimage.ubuntu.com/livecd-base/  for 4 days at least, anobody knows why ?
<StevenK> Mithrandir: If I give you a debdiff for openoffice.org-voikko, would you mind uploading it?
<Mithrandir> StevenK: please.
<StevenK> Mithrandir: http://wedontsleep.org/~steven/ooo-voikko.debdiff
<StevenK> Mithrandir: It's just a build1 -> build2 kick
<Mithrandir> ah, sure.
<StevenK> I tested it last night, I seriously doubt anything shattering has happened to the archive in the mean time.
* Fujitsu shatters the archive.
<Mithrandir> StevenK: uploaded
<Mithrandir> Fujitsu: just too late. :-)
<Fujitsu> Damn.
<Fujitsu> I've got another 20 minutes, surely?
<Mithrandir> maybe, if you're in the DC.
<Fujitsu> And another hour after that before it starts building.
* Fujitsu gets to it.
<StevenK> Mithrandir: Thanks
<StevenK> Mithrandir: I managed to get to the (7am) tech board meeting, and got a +1 from mdz and sabdfl for -core-dev, by the way
<Mithrandir> StevenK: yay. :-)
<StevenK> Oh yes. :-)
<tepsipakki> StevenK: have you tested that ooo-voikko would get correct Conflicts by a simple rebuild? I've talked to the maintainer who said that it doesn't currently handle rc-versions
<Fujitsu> StevenK: Congrats :)
<Mithrandir> tepsipakki: sorry I wasn't around last night for your core-dev application
<StevenK> tepsipakki: I can look again, if you like.
<tepsipakki> Mithrandir: np, I forgot to ask you to be there ;)
<tepsipakki> pitti: I'll look at vesa later today
<tepsipakki> sorry, evdev
<pitti> tepsipakki: vesa? context?
<pitti> aah
<pitti> tepsipakki: thank you
<pitti> tepsipakki, Mithrandir: FYI, the meeting didn't handle applications, at least not until an hour after it started
<pitti> tepsipakki: applications are supposed to be handled through email to the TB first now
<tepsipakki> there is 1.1.5 which was released for 7.2 but maybe we should just find the commit to make it build
<tepsipakki> pitti: oh, ok
<pitti> tepsipakki: backporting++, unless we can exhaustively test this easily
<tepsipakki> I can do both
<pitti> does 1.1.5 officially belong to 7.2?
<tepsipakki> evdev isn't used by default anyway
<tepsipakki> yes
<pitti> if it's a stable branch from upstream, that might even be better; in this case we should just eyeball the diff for suspicious changes
<tepsipakki> but the list of changes wrt to 1.1.2 is long
<tepsipakki> but either way
<pitti> the other bug that I saw that crashed a program due to that API/ABI change wasn't very encouraging
<tepsipakki> due to evdev?
<pitti> yes; I mentioned that other bug in the FTBFS bug report
<tepsipakki> ah
<fabbione> Setting up network-manager (0.6.4-6ubuntu3) ...
<fabbione>  * Reloading system message bus config...                                                                                           [ OK ]  
<fabbione>  * Restarting network connection manager NetworkManager                                                                                    
<fabbione> BAHM
<fabbione> and 2
<fabbione> Mithrandir: i think the last network manager update is breaking hard
<Mithrandir> fabbione: that's a terrible bug report. :-P
<fabbione> Mithrandir: i can give you all details.. basically ifaces are not wireless and configured via interfaces to use dhcp
<fabbione> Mithrandir: for some reasons NM takes them down and it's not capable of bringing them up again
<fabbione> and that's bad when you have NFS mounted stuff
<Mithrandir> hm, you have multiple active interfaces?
<mdke> Mithrandir: your changelog entry says that it fixes the bug for people who use static interfaces. But the bug occurs also for people who use dhcp, and has them configured in /etc/network/interfaces, as I understand it NM simply ignores them
<mantiena> who is responsible forf cdimage.ubuntu.com mirroring ? livecd-base mirroring doesn't work, because REMOTE HOST IDENTIFICATION HAS CHANGED
<fabbione> Mithrandir: yes i do.. most of them are virtual interfaces tho
<fabbione> Mithrandir: on my i386 there is only one real and plenty between vmware and tunnels
<fabbione> Mithrandir: on laptop is one wired ether and 2 wireless.. tho i told NM NOT to touch any of them
<Mithrandir> mdke: no, it doesn't.
<fabbione> on both machines.. 
<fabbione> and during the upgrade it does try to take them over
<mdke> Mithrandir: ok, well lots of people on that bug report say that it happens on their system (and it does on mine - I don't use static, I use dhcp)
<Mithrandir> mdke: can you attach your /etc/network/interfaces to the bug report, please?
<mdke> mantiena: https://launchpad.net/~ubuntu-cdimage
<mdke> Mithrandir: sure
<mantiena> mdke: what ? I'm talkink about mirroring scripts
<mantiena> mdke: it seems womeone just forgot to upload new ssh key
<mdke> mantiena: I was answering your question
<mdke> "who is responsible for cdimage.ubuntu.com..."
<Mithrandir> fabbione: the solution in your case might then be "don't use NM".
<khermans1> it appears that many packages are depending ~gnome < 2.18
<fabbione> Mithrandir: well i told NM not to touch my networks.. at least i think it is supposed to keep settings?
<khermans1> but >= 2.18 are being installed
<Mithrandir> fabbione: uh, how did you tell NM that?
<Fujitsu> fabbione: As I said before, the change in the last version modified that behaviour.
<fabbione> from the applet: "Enable Networking".. i thought it meant.. keep your NM hands away from my settings
<fabbione> Fujitsu: yes.. i got that...
<Fujitsu> Oh, that way.
<mdke> Mithrandir: done
<Mithrandir> fabbione: no, it doesn't, and it's not what it says on the lid either.
<khermans1> ie -> libwnck18 depends libwnck-common (<2.18) but 2.18.0 will is installed
<mantiena> cjwatson:  cdimage.ubuntu.com/livecd-base mirroring doesn't work, because REMOTE HOST IDENTIFICATION HAS CHANGED - look at cd-build-logs on people.ubuntu.com/~cjwatson
<Mithrandir> khermans1: we just had a new revision of gnome uploaded, the archive isn't consistent yet.  No need to nag us about it, it's being tended to.
<khermans1> Mithrandir: i see that and i was wondering if you knew -- now i know
<khermans1> Mithrandir: is there a HOWTO for unb0rking my apt/dpkg now that i screwed myself with the last dist-upgrade?
<Mithrandir> khermans1: wait until it doesn't give errors and then upgrade.
<Mithrandir> mdke: your interfaces file ought to work with the new NM.
<khermans1> Mithrandir: :-(
* khermans1 install xubuntu
<Mithrandir> mdke: I haven't tried, but from my changes and how your file looks, I believe that case is also fixed with the latest NM upload.
<mdke> Mithrandir: alright, I'll check and close the bug if so. I maybe misunderstood your changelog entry
<Mithrandir> mdke: it might not respect the wireless-essid setting, though, which would be a bug.
<Mithrandir> mdke: or my changelog entry wasn't good enough
<mdke> Mithrandir: :)
<sabdfl> i'm about to do an upgrade, is apt / apt-utils b0rked? should I hold off a few hours?
<Mithrandir> sabdfl: no, but you shouldn't force through updates if apt tells you that it can't install everything.  We had a full gnome upload yesterday and the archive is still slightly busy sorting the bits.
<Treenaks> Mithrandir: yeah, I noticed.. after it had removed gnome-panel :)
<Fujitsu> I noticed (what I presume to be a result of) it when my gnome-panel crashed a few times a second.
<Treenaks> Fujitsu: that too
<Fujitsu> But then something else updated and it started up fine.
<mdke> Mithrandir: yes, works. Wow, the applet is quite cool all of a sudden
<Mithrandir> mdke: does it pick up the wireless setting correctly too?
<mdke> Mithrandir: I had to left click on the applet and select my network, then it connected
<mdke> no idea if i was already connected or not
<Mithrandir> mdke: ok, it probably ignore it, then.  I should probably make it call ifup/ifdown and not manage it itself.
<mdke> ok, well I'm happy anyway
* mdke hugs Mithrandir 
<dholbach> good morning
<pitti> hey dholbach 
<dholbach> hey pitti
<Kagou> it's seems that daily-live feisty iso for i386 is too big today
<pitti> mvo: erk, the 'reboot required' dialog's German translation has lots of  signs in it
<pitti> carlos: ^ I thought that would have been fixed?
<carlos> ggrrr, I forgot to send the request to the DBA :-( It's my fault
<Hobbsee> BenC: linux-backports-modules-2.6.20 is in depwait - sure the build-deps for that are right?  (it's referencing -8 headers, not -9)
<carlos> I'm going to do it now so I'm sure I will not forget it again
<pitti> carlos: thanks
<pitti> Hobbsee: and now we are at -10 already
<Hobbsee> pitti: true that, but it seems that it's behind, or something.  the 9.3 built with the -8 headers, so i'm confused.
<Mithrandir> the control file for l-b-m is wrong
<Hobbsee> i suspected as much, what should it be?
<Hobbsee> ie to point to -9, or -10?
<Mithrandir> -10, but it's not a manual process.
<Mithrandir> I can fix it.
<Mithrandir> Hobbsee: thanks, fixed.  Good catch.
<mneptok> +sexy
* mneptok woggles an eyebrow
* Mithrandir slaps mneptok 
<Hobbsee> Mithrandir: :)
* Hobbsee attacks mneptok with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
* Fujitsu drops the broken linux-backports-modules-2.6.20 on mneptok.
<mneptok> Mithrandir: careful. that's Hobbsee's job.
<Hobbsee> mneptok: you wish it was.
<Mithrandir> mneptok: you dirty old man.
<mneptok> Hobbsee: the GF is pleased to know that women continue to abuse me as she sleeps. it's like a weird trade union.
<Hobbsee> heh
<dholbach> could somebody please give back gnome-python-desktop on amd64?
<Mithrandir> dholbach: done, and same for ppc done
* dholbach hugs Mithrandir
<dholbach> Mithrandir: you ROCK :)
<Mithrandir> thanks. :-)
<dholbach> :-))
<Mithrandir> huzzah, evo built fine now
<dholbach> hey seb128
<seb128> hi dholbach
* pitti hugs seb128
* seb128 hugs pitti back
<seb128> pitti: language packs seem to work fine
<pitti> seb128: yay
<pitti> for me, too
<pitti> high time, eh
<Mithrandir> iwj: pdf2ps segfaults in the opensp build, would you like to take a look at it?  http://librarian.launchpad.net/6640435/buildlog_ubuntu-feisty-powerpc.opensp_1.5.2-3build2_FAILEDTOBUILD.txt.gz
<Mithrandir> iwj: seems to be ppc specific.
<Mithrandir> seb128: your pyorbit upload blew up sideways, you might want to take a look http://librarian.launchpad.net/6601939/buildlog_ubuntu-feisty-i386.pyorbit_2.14.2-0ubuntu2_FAILEDTOBUILD.txt.gz
<seb128> Mithrandir: I've asked doko if he could have look some time ago, it's due to the python-dbg changes :/
<Mithrandir> seb128: from the build log, it doesn't look like that.  Looks more like libtool fell over.
<seb128> Mithrandir: yeah, and autotools are runned for the python-dbg changes
<dholbach> seb128: if you want, I'll try to take a look?
<seb128> dholbach: if you want to do so you are welcome
<dholbach> ok, just looking at a new workrave, will do it afterwards
<seb128> Mithrandir: when is beta freeze starting?
<Mithrandir> seb128: tomorrow.
<seb128> oh, good
<pitti> arrgh
<pitti> mvo: I just wasted 20 minutes banging my head on the table before I discovered that gksu does not propagate the exit status
<pitti> 'gksu false' exiting with 0 is wrong...
<seb128> speaking about sudo it behaves weirdly for users not to the admin group on my desktop
<seb128> sudo command asks for the password
<seb128> and then do nothing
<seb128> no error, no message, it just don't do the action and acts like it was doing
<seb128> ah, there is a bug open: https://beta.launchpad.net/ubuntu/+source/sudo/+bug/81140
<Ubugtu> Malone bug 81140 in sudo "sudo (edgy) silently fails when user is not a member of admin" [Undecided,Unconfirmed]  
<pitti> mvo: ah, it's already filed as bug 51633
<Ubugtu> Malone bug 51633 in gksu "Doesn't return correct system exit code" [Undecided,Confirmed]  https://launchpad.net/bugs/51633
<pitti> seb128: hm, I get 'joe is not in the sudoers file.  This incident will be reported.'
<seb128> pitti: I don't
<seb128> if you need any debug info let me know ;)
* pitti takes a needle and sews together desktop-effects and restricted-manager now
<Mithrandir> seb128: the pyorbit build failure is due to the CC=$PYTHON_CC in configure.in, but you'll need to change the AC_SUBST([ACLOCAL_AMFLAGS] , [..]  line too, to change $ac_macro_dir to (the string) m4.
<Fujitsu> I get both sudo behaviours across various machines.
<pitti> Fujitsu: comparing sudoers and group memberships on both machines would be appreciated
<Fujitsu> I can't recall which has which, but I'll have a look tomorrow.
<seb128> Mithrandir: ok, thank you
<Mithrandir> seb128: (and you need to run autoconf once after changing configure.in).
<pitti> Fujitsu: thanks
<seb128> dholbach: ^ if you are on pyorbit
* pitti wonders at which orbital height Python is
<Mithrandir> seb128: at least it completes building here.
<seb128> Mithrandir: good, thank you for looking at it!
<Mithrandir> np
<dholbach> Mithrandir: do you have any idea, why gnome-python-desktop just ftbfs? i successfully updated my powerpc to python-gnome2-dev (2.18.0-0ubuntu1) a minute ago
<Mithrandir> dholbach: I'll take a look in a second
<dholbach> Mithrandir: gracias
* Mithrandir stares at the output from cruft-checker:
<Mithrandir>  * php4-ps_1.3.4-3ubuntu1 builds: php5-ps
<Mithrandir>       but no longer builds:
<Mithrandir>         o 1.3.4-2: php4-ps
<Mithrandir> maybe a rename of the source package is in order?
* Mithrandir takes immense pleasure in removing php4 binaries from the archive
<pitti> Mithrandir: yay!
<Mithrandir> dholbach: probably just unfortunate timing wrt when python-gnome2 was happy, given-back
<dholbach> yoohoo
<Mithrandir> dholbach: seems to be building now at least
<StevenK> Mithrandir: Reaccept it, and purge it out again.
<dholbach> Mithrandir: super - I'll pester with you some other give-back requests later, so gnome 2.18 is installable on powerpc and amd64 again
<Mithrandir> dholbach: if it's on outdate.txt, I'll tend to it by myself, so unless you see something stuck for a while, you don't need to ask me.
<dholbach> ok
<dholbach> thanks
<mvo> pitti: yeah, that gksu problem is very anoying
<cjwatson> Mithrandir: I didn't see any need to mail -devel-announce about the report URL changes since I left redirects in place
<cjwatson> khermans1: you made a comment the other day that "the new ubiquity is broken" or some such. Care to give details?
<Mithrandir> cjwatson: well, point, but telling people that "you might want to poke around at ~ubuntu-archive to see if you find interesting information" might not be a bad idea?
<cjwatson> Mithrandir: true
<imbrandon> Mithrandir, do i need to poke you ( or another archive admin ) about a edgy-proposed upload , or will it automajicly get accepted ( sru page said something about poke to make sure the versioning was sane )
<imbrandon> versioning is/was mod-mono_1.1.17-3 -->  mod-mono_1.1.17-3build1~proposed1 fyi 
<pitti> mvo: shall I take a look at gksu?
<mvo> pitti: if you have spare cycles, that would be great
<Mithrandir> imbrandon: why the build1 in there?
<pitti> mvo: well, not exactly 'spare', but it makes the destop-effects/restricted-manager integration look bad, and that's my top goal ATM
<Mithrandir> imbrandon: sorry, you do of course need something like that, ignore me. :-)
<imbrandon> Mithrandir, because its only a rebuild ( but i was told it needed to be a SRU )
<mvo> pitti: right, if you would fix it, g-a-i would benefit as well, so I'm all for it :)
<imbrandon> no real changes
<pitti> mvo: ok; doesn't sound hard
<imbrandon> Mithrandir, 17-3 is whats currently in the archive 
<Mithrandir> imbrandon: yes, I see that.
<Mithrandir> imbrandon: I'd probably have named it 1.1.17-3edgy1~proposed1 to show that it's an edgy branch.
<imbrandon> sure i can do that if you can remove the upload i just did, only take me 2 seconds to change
<Mithrandir> pitti: are you aware of the langpacks in edgy-proposed NEW?
<pitti> Mithrandir: oh, I thought I already rejected them; doing now, thanks
<Mithrandir> imbrandon: rejected.
<imbrandon> Mithrandir, k
* pitti cleans up the langpack clutter in feisty/NEW as well
<imbrandon> Mithrandir, ok re-uploaded , so if you get a sec can you push that through
<imbrandon> moins pitti 
<Mithrandir> imbrandon: will do once it shows up in the queue (at :45)
<pitti> hey imbrandon 
<imbrandon> Mithrandir, ok, thanks ;)
* mneptok slaps imbrandon's butt
<imbrandon> wheeowww
<imbrandon> ;)
<mneptok> *muah* hey sailor :)
<iwj> Mithrandir: Sure, I'll look at your pdf2ps bug.
<Mithrandir> iwj: thanks a lot
<ogra> seb128, do you have any hint for me for bug 82527 ? do i need anything special to register with dbus ?
<Ubugtu> Malone bug 82527 in gnome-screensaver "gnome-screensaver-command doesn't work for gnome-screesaver instances started from /etx/X11/Xsession.d" [Undecided,Confirmed]  https://launchpad.net/bugs/82527
<seb128> ogra: does it need some environment variable?
<ogra> (not for the gss issue there, but we need the student-control-panel client working)
* seb128 opens the bug
<ogra> seb128, nope .... we have an Xsession.d script that starts scp-client on thin client sessions ...
<ogra> it needs the LTSP_CLIENT env variable set to actually start the binary, but that happens fine ...
<ogra> it just cant communicate thrugh dbus
<ogra> as the screensaver apparently cant either f not started by gnome-session ...
<seb128> ogra: it probably requires something in the environment which is set with gnome-session
<ogra> hmm, k, i'll dig in that direction, thanks for the pointer
<seb128> np
<pitti> mvo: erk, this is much worse than I imagined
<pitti> mvo: so this would involve API changes, rebuilds of several packages and extensive changes in libgksu gksu
<ogra> seb128, heh, got it ... syou shouldnt execute stuff from Xsession.d scripts but just add them to $STARTUP so it gets DBUS_SESSION_BUS_ADDRESS set in the environment :)
<ogra> the scp-client script only executed the command ...
<seb128> k
<mvo> pitti: I vaguely remeber that I looked at it some months ago and felt that its a can of worms too
<Mithrandir> it feels like I've given-back half the archive now.
<imbrandon> lol @ Mithrandir 
<Hobbsee> Mithrandir: must be time for you to give back the other half then.
<ogra> seb128, i had various reports about shutdown not working anymore from the logout dialog ... did you just switch recently from gdm to gpm for gnome-session ? 
<seb128> no
<ogra> hmm, k
<seb128> when did you start getting them?
<ogra> then i'll try to get more info 
<ogra> jammcq said with the last update he did this week, but he's not completely up to date yet ... i'll wait until he upgraded
<ogra> i just thought i missed the switch or something 
<Fujitsu> seb128: Did you do the processing of -proposed uploads a couple of hours ago?
<Mithrandir> Fujitsu: no, I did a couple for edgy-proposed.
<seb128> Fujitsu: no, I don't do SRU
* Hobbsee wonders who broke cupsys
<Mithrandir> Hobbsee: broken how?
<pitti> Hobbsee: Till did some pretty intrusive changes recently; can you please talk to him?
<pitti> Hobbsee: I saw a lot of bug reports about not-working backends any more
<Hobbsee> Mithrandir: pitti https://beta.launchpad.net/ubuntu/+source/cupsys/+bug/92205
<pitti> Hobbsee: I guess something in the backend enabling/disabling broke
<Ubugtu> Malone bug 92205 in cupsys "Error on cupsys update" [Undecided,Unconfirmed]  
<Hobbsee> installing error
<Fujitsu> Mithrandir: Aren't you meant to set the bug to fixcommitted?
<pitti> Hobbsee: oh, I see
<Mithrandir> Hobbsee: ouch
<pitti> Hobbsee: right, that's the recently uploaded version
* pitti mangles the bug
<Hobbsee> yes
<geser> Mithrandir: is it possible to sync linux-ntfs from Debian unstable to fix bug #86231 aka Debian bug #379628 ?
<Hobbsee> it's only just come thru, doesnt appear to have any dupes yet
<Mithrandir> Fujitsu: hm, I don't think that has been discussed in the new MOTU SRU proposal.  I think it'd make sense for the uploader to set it to fix committer.
<Ubugtu> Malone bug 86231 in linux-ntfs "Installer won't resize Windows Vista NTFS-partitions" [Undecided,Confirmed]  https://launchpad.net/bugs/86231
<Ubugtu> Debian bug 379628 in ntfsprogs "ntfsresize: resizing a Vista NTFS partition leads to corrupted" [Critical,Closed]  http://bugs.debian.org/379628
<Mithrandir> geser: I believe cjwatson has been pondering how to attack that problem.  Try asking him?
<geser> ok
<Fujitsu> `After the upload, archive administrators should then verify that the version number of the upload is sane and accept the package into -proposed. They set the bug status to Fix committed.'
<Fujitsu> Mithrandir: Some people won't be on [old release] -changes, so won't see the notification of the acceptance unless there's a change on the bug.
<geser> cjwatson: is it possible to sync linux-ntfs from Debian unstable to fix bug #86231 aka Debian bug #379628 ?
<Ubugtu> Malone bug 86231 in linux-ntfs "Installer won't resize Windows Vista NTFS-partitions" [Undecided,Confirmed]  https://launchpad.net/bugs/86231
<Ubugtu> Debian bug 379628 in ntfsprogs "ntfsresize: resizing a Vista NTFS partition leads to corrupted" [Critical,Closed]  http://bugs.debian.org/379628
<cjwatson> geser: uh, surely that was a partman problem
<cjwatson> at least, a partman problem as well
<cjwatson> happy to take 1.13.1-6 from testing though, probably; will check
<cjwatson> Mithrandir: everything from partman-base 100 to 105 looks OK - http://svn.debian.org/wsvn/d-i/trunk/packages/partman/partman-base/debian/changelog?op=file&rev=0&sc=0 - UVFe?
<geser> it's only a 2 line change which is also in the bug report
<cjwatson> geser: there was definitely a partman problem; I know because I spent a couple of hours reviewing the patch
<Mithrandir> cjwatson: looks sane; go for it.
<Mithrandir> cjwatson: are you planning on a d-i upload for the new kernel too?
<cjwatson> oh, was there another ABI bump? yes then, but not just yet
<Mithrandir> -10 is in the archive now and default, so yes.
<Mithrandir> just a gentle push
<fabbione> Mithrandir: i know ben is about to upload -11 to fix all the audio mess that happened with -10
<Mithrandir> ok
<imbrandon> hum means i will need to reupload lirc, is there a way to have that package rebuilt on a new kern upload ?
<imbrandon> like the lrm is etc
<Mithrandir> imbrandon: no, there isn't.
<imbrandon> hum okies /me adds it to a personal soyuz wishlist
<Mithrandir> dholbach: the libgnome-desktop-dev build-dependency of deskbar-applet is ever-so-slightly optimistic, isn't it?
<Tonio_> hi
<Tonio_> BenC: ping ?
<imbrandon> moins Tonio_ 
<Tonio_> hey imbrandon :)
<Hobbsee> Tonio_: [23:11]  [Whois]  BenC has been idle for 11 hours, 2 minutes, and 32 seconds.
<Tonio_> Hobbsee: indeed
<Tonio_> Hobbsee: heard about a kernel problem with the latest released ? it doesn't boot on macbook machines, so I wondered if I should report the bug
<Tonio_> Hobbsee: as you follow malone carefully.... ;)
<Hobbsee> Tonio_: cant say i've been following, with the >20 sec load time on every single launchpad page, and i dont get that in my email.
* Hobbsee has been avoiding LP on that basis
<imbrandon> Tonio_, from what i seen a few minutes ago in here BenC is planned to upload -11 soonish, maybe that will fix it, if not i would file a bug
<slomo_> Mithrandir: hi :) can you take a look at bug #91639 ?
<Ubugtu> Malone bug 91639 in ndesk-dbus "UVF exception: ndesk-dbus 0.4.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91639
<Tonio_> Hobbsee: I'll have a look and report that toonight
<Hobbsee> Tonio_: however, i havent really looked in -bugs that much either.
<Tonio_> Hobbsee: the point is I also needed to test a kernel patch for the speakers but I can't since it fails to boot
<Hobbsee> useufl
<Hobbsee> *useful
<Mithrandir> dholbach: care to take a look at the gnome-games ftbfs?
<Mithrandir> slomo_: looking.
<dholbach> Mithrandir: sure
<Keybuk> cupsys is broken :-/
<Hobbsee> Keybuk: known.  want the bug id?
<Keybuk> sure
<Hobbsee> oh bugger, then i have to find it
<Hobbsee> Keybuk: https://launchpad.net/bugs/92205
<Ubugtu> Malone bug 92205 in cupsys "Error on cupsys update" [Undecided,Confirmed]  
* Keybuk bets it worked on Mandriva
<pitti> huh?
<pitti> I just set this to High
<Fujitsu> pitti: Apparently not.
<Mithrandir> pitti: uh, apparently lp did something funky and removed it when I milestoned it.
<pitti> Mithrandir: we probably changed it at the same time
<pitti> I set it to high, assigned it to Till, and milestoned
<Fujitsu> pitti: It was 9 minutes apart.
<Mithrandir> pitti: no, we didn't.  I remember seeing you had assigned it to Till already.
<Mithrandir> but it wasn't milestoned.
<Hobbsee> it's still milestoned, etc.
<Mithrandir> anyway, it's high/till-ed now
* pitti mangles again and blames cosmic rays
* Fujitsu blames dodgy Malone instead.
<Hobbsee> clearly Ubugtu hasnt gotten an updated email or something yet - it's always a bit delaye
<Hobbsee> d
<Hobbsee> heh
* Hobbsee BLAMES SEVEAS!
<dholbach> Mithrandir: lunch first :)
<Fujitsu> Hobbsee: No, the status on the actual bug got reset.
<Hobbsee> oh, weird
<Hobbsee> oh, meh.  3 people trying to modify the same bug at once always causes large amounts of trouble
<Fujitsu> Hobbsee: Mithrandir was some 8 minutes later. Milestoning seems to reset it.
<Mithrandir> slomo_: how well tested is this?
<Keybuk> pitti: I have a patch already I think
<slomo_> Mithrandir: works fine for me since the day of the release
<Keybuk> in the sense that I have an upload that restores cups to its formerly working state
<slomo_> Mithrandir: and i tested it with almost all packages that depend on it
<Mithrandir> slomo_: and no ille effects?
<Mithrandir> Keybuk: it looks fairly easy to just adjust its perception of where the mime database should be instead?
<Keybuk> Mithrandir: the problem is that cups doesn't support path:path:path :p
<cjwatson> I think it would be good to finish the job rather than reverting if possible
<cjwatson> the idea was to add such support to cups, I understood
<cjwatson> was discussed on IRC the other day
<pitti> Keybuk: it's supposed to support it now
<Keybuk> the patch uploaded only changes the string of paths, it doesn't add any kind of support for looking in multiple directories
<Keybuk> pitti: this is signed by your key ... did you test it before upload?
<slomo_> Mithrandir: nope, everything perfect :)
<pitti> Keybuk: not this time, I started trusting Till's uploads
<pitti> and time crunch, sorry
* pitti needs to run for about two hours, bbl
<Mithrandir> slomo_: ok, approved.
<slomo_> Mithrandir: thanks
<ogra> seb128, jammcq> hey, even after applying 130mb of updates, it still locks up when I try and shutdown, but shutting down from GDM seems to be fine
<ogra> seems like gpm or gnome-session misbehave
<bmm> Hi everybody. I'm packaging the io language interperter, do I need to post an ITP somewhere (like with debian)?
<Fujitsu> ogra: locks up like how? When I last tried it (an hour or two ago) the button pressed, but then the session froze before it popped up again.
<seb128> ogra: gpm is not used for shutdown
<ogra> seb128, oh, you didnt switch at all ?
<ogra> i thought you had planned that
<ogra> Fujitsu, the logout dialog just hangs on a greyed out desktop
<seb128> ogra: and I decided to do it next cycle because it was late in the cycle already, etc
<ogra> ok
<Fujitsu> ogra: I can confirm that.
<seb128> ogra: do you have network-manager installed? does it happen without it?
<seb128> we had a bug where it happens to guy and it's fixed without n-m
<ogra> dunno, i'll ask jammcq to join here
<seb128> maybe it takes the lo interface down or something
<shawarma> bmm: Try #ubuntu-motu
<ogra> hey jammcq 
<jammcq> hello ogra 
<seb128> hi jammcq
<jammcq> hello seb128 
<ogra> jammcq, <seb128> ogra: do you have network-manager installed? does it happen without it?
<ogra> <seb128> we had a bug where it happens to guy and it's fixed without n-m
<bmm> shawarma: will do, thanks
<jammcq> having a small problem withfeisty
<jammcq> yes, I have nm installed, and that's working fine.  haven't tried without it
<ogra> jammcq, see above
<ogra> seems it has cases where it touches the lo interface
<jammcq> how do I try without it?  remove it?
<Fujitsu> Does NM have a habit of making lo vanish? Mine does sometimes.
<seb128> jammcq: uninstall the package
<seb128> Fujitsu: no idea
<jammcq> my nm has been working wonderfully for the last 4 weeks or so
<heno> Hobbsee: do you still see 20 sec load times on LP? I find it's improved over the past 3-4 days
<jammcq> seb128: ok, i'll remove it right now
<heno> Hobbsee: I'm asking so I can give useful feedback to the LP team
<ogra> Fujitsu, it has way more evil habits than touching lo ... i.e. shutting down static interfaces you run servers on ... :)
<Fujitsu> ogra: I find touching lo to be worse.
<ogra> even though killing lo might be similary evil
<Hobbsee> heno: yes.  before it was 45+.  i'm speaking to SteveA at the moment about it, and he's testing.
<Fujitsu> It breaks my mpd regularly :(
<heno> Hobbsee: ok, thanks. it's never been that bad here, 20, but not 45 I think
<Hobbsee> heno: yes, but you're not aussie
<heno> about 2-3 seconds now at worst
<Hobbsee> at worst.  that'd be at best, for here.  lucky.
<tepsipakki> jammcq: put "exit 0" to /etc/default/NetworkManager and /etc/default/NetworkManagerDispatcher..
<tepsipakki> that's how I disable it
<tepsipakki> that could also be documented somewhere
<heno> Hobbsee: do you have caching of SSL enabled?
<Hobbsee> heno: no, we were asked to test without it
<heno> right, ok
<jammcq> seb128: ok, removed nm, rebooted.  shutdown still hangs :(
<seb128> ok, not it then
<seb128> dunno what it would be :/
<jammcq> can I just re-install nm now?
<seb128> yep
<Mithrandir> heno: ssl caching doesn't seem to make any difference for me here.
<jammcq> also, on the updates that I installed today, cups seems to have a problem with post-inst
<jammcq> I got this:
<Hobbsee> jammcq: known.
<imbrandon> Mithrandir, should that mod-mono build show up on LP even from -proposed ? ( i'm not seeing it yet is why i ask )
<Mithrandir> ogra: have you had a chance to look at the gnome-power-manager build failure on sparc?
<ogra> seb128, its weird that it works from gdm directly though ... do you know the status of the current console kit implementation we use ? might be that its needing it now ...
<jammcq>    E: cupsys:subprocess post-installation script returned error exit status 2
<heno> Mithrandir: as in 'it's fixed to be equally good', or equally bad?
<seb128> ogra: we don't use console kit
<jammcq> Hobbsee: known issue on the shutdown problem?
<Hobbsee> jammcq: https://launchpad.net/bugs/92205
<Ubugtu> Malone bug 92205 in cupsys "Error on cupsys update" [High,Fix committed]  
<ogra> Mithrandir, i looked at the ftbfs log and understood that i have no clue how to fix it ...
<jammcq> oh
<heno> if that makes sense
<Hobbsee> jammcq: no, the cupsys
<jammcq> cool, i won't worry about it then
<ogra> Mithrandir, nothing beyond that yet
<Mithrandir> ogra: have you solicited help?
<ogra> not yet #
<Mithrandir> heno: it's between 1 and 5 seconds for me.
<Mithrandir> so quite bad, but nowhere near the times Hobbsee are seeing.
<ogra> the ftbfs log is here, in case some sparc god is listening ... http://librarian.launchpad.net/6761499/buildlog_ubuntu-feisty-sparc.gnome-power-manager_2.18.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> ogra: don't use -Werror ;)
<seb128> I'm not a sparc god, that's a workaround though :p
<seb128> Werror doesn't bring much to a stable version
<ogra> hmm
<fabbione> ogra: it's problably complaining that the stuff is not 64bit alligned
<fabbione> even if userland is 32
<seb128> GNOME tarball usually use Werror on SVN only
<fabbione> all the access must be 64bit alligned
<ogra> well, amd64 doesnt make probs ... 
<fabbione> amd64 does not require allignment
<ogra> neither do i get reports fro ppc64
<fabbione> same
<ogra> ah
<ogra> ok
<fabbione> sparc is the only one that forces it
<ogra> fabbione, but since its only a warning, it should do no harm to just disable Werror ? 
<ogra> or do i need to hack up the upstream code ?
<fabbione> ogra: i am ok if you want to disable -Werror only for sparc
<ogra> well, since seb128 says its disabled in upstream releases anyway i'm fine to switch it off everywhere ... dunno why gpm didnt do that 
<ogra> configure.in has a commented line without Werror, likely just an oversight of hughsie
<iwj> Feh, the pdf from my i386 build of opensp doesn't make powerpc's pdf2ps crash.  I'll have to build opensp on davis.
* Mithrandir sighs and starts hacking on getting grub to work with gcc 4.1
<iwj> Mithrandir: That opensp build WFM when I build it by hand on davis.
<Mithrandir> iwj: ugh.  I could try a give-back and see if it's just a bogon which hit the buildd at the wrong time.
<iwj> Mithrandir: I think it may be a difference in the gs versions.
<Mithrandir> iwj: well, I just gave it back; let's hope it works this time around, else we can ask for a freshening of the davis chroot?
<iwj> Just a mo ...
<iwj> ... the buildd used gs-esp and davis is using gs-gpl.
<iwj> gs-esp is 8.15 and full of bugs.
<iwj> *sigh*
<iwj> I think that for feisty I might try and see if I can persuade Till that we should make gs-gpl the default.
<Mithrandir> I'm scared of doing that change at this point.
<iwj> Yers.  Well the alternative is to have me debug it and find a bug which will turn out to have been fixed in 8.54.
<iwj> But I can do that if that's what you want :-).  I quite _enjoy_ bughunting in gs, but it seems a bit silly when the bug is already fixed elsewhere and we just don't know which one it is ...
<Mithrandir> changing the build-deps should be the easy way out on this one.
<iwj> Mithrandir: Err, yes.  Nice kludge.
<iwj> OK, shall I do that ?
<Mithrandir> yes, please.
<iwj> OK.
<Mithrandir> I was more worried about changing the default, but if you can make a good case for it, we can certainly discuss it.
<Mithrandir> 8.54 > 8.15, after all. :-)
<iwj> Quite.  The problem is that there are quite a few printers which aren't supported in gs-gpl but are in gs-esp.
<iwj> Ideally we'd use gs-gpl for ps processing and stuff and gs-esp just as a backend.
<Mithrandir> hmm.  If this was two months ago, I'd think that would be a swell idea. :-)
<asac> source thaifonts-scalable is not in merges (main) list ... i guess this is an automatically sync'ed package, right?
<Hobbsee> asac: might be on the manual merge page
<Hobbsee> asac: version number suggests that it's nto an autosync
<asac> right ... so what does this mean ... in regards to updating it to latest?
<Hobbsee> asac: well, the version number means that it's nto in debian, or wasnt at the time of packaging, so you can just update it in ubuntu (and get a UVFe because we're in freeze)
<Hobbsee> if it's in debian now, then you should merge it with the debian packaging, to get debian fixes.  if it's really whacked, dont bother, just grab any fixes in there
<asac> ah ok :)
<Keybuk> cjwatson: mbp has found an amusing bug
<Keybuk> cjwatson: the rescue thing on the alternate CD doesn't have a "normal" /sbin/init, does it? :p
<cjwatson> no ...?
<cjwatson> busybox init
<Keybuk> so when you upgrade upstart, and the postinst sends SIGTERM to pid 1 to tell the running one to reexec ... what do you think happens? :p
<cjwatson> heh
<cjwatson> sysvinit used to check whether it was running in a chroot, I'm sure
<cjwatson> hmm, maybe not, dunno
<Keybuk> nah, sysvinit used to use /dev/initctl to tell it to rexec
<Treenaks> Keybuk: now you know why ;)
<Keybuk> upstart uses the signal since most of the time I need to do it is when I've wedged it
<Keybuk> and signal handlers have the advantage of not needing the main loop to be working properly :p
<Keybuk> is there a way to tell you're running in a chroot?
<siretart_> iwj: are you still interested in my 'initramfs'?
<BenC>   * quickcam: Add 0.6.6 driver (from qc-usb package).
<BenC>     - GIT-SHA 6cfdbcfc6427769567a0b4bb593751c089f3d852
<BenC> Nafallo: ^^
<cjwatson> Mithrandir: could you quickly review kboot-installer? I need it in main
<cjwatson> (it's in NEW)
<pitti> Keybuk: Till just sent me a new cupsys package; did you already upload something?
<Keybuk> pitti: nope
<Keybuk> go for it
<pitti> alright
<pitti> mvo: btw, isn't this cups thingy a perfect test case for the u-m apport integration?
<mvo> pitti: yes! 
<pochu> Mithrandir: there have been some request for xubuntu PPC, would it be possible to build theme in xubuntu/ports?
<mvo> pitti: the integration is there
<mvo> or rather, should be there :)
<pitti> mvo: I don't see any bugs for it
<pitti> mvo: anyway, I'll do an upgrade to the broken version and check it
<mvo> pitti: thanks. keep me updated
<Mithrandir> pochu: yes, sure.
<pochu> Mithrandir: thanks :)
<Mithrandir> pitti: are you ok with me just putting kboot-installer in main?  It's written by Colin, it's a d-i component and looks perfectly fine to me.
<pitti> Mithrandir: of course; in-house developments are no problem
<Mithrandir> cjwatson: accepted.
<Mithrandir> pitti: thanks; I still wanted to check with you
<pitti> mvo: hm, I got the postinst failure, and the final dialog with the error message, but no apport report
<cjwatson> Mithrandir: thanks
<cjwatson> pitti: any chance you could review ps3pf-utils for main? (ideally ps3-kboot as well but that's (a) more complicated and (b) less urgent)
<pitti> cjwatson: can do, yes
<cjwatson> thanks
<pitti> cjwatson: after cupsys, though
<mvo> pitti: strange. I will investiage, thanks
<pitti> mvo: echo hallo | /usr/share/apport/package_hook -p cupsys still works (and that's testcase'd as well)
<pitti> hi tkamppeter 
* pitti uploads fixed cupsys package, this time tested
<tkamppeter> pitti, can you upload cupsys quickly, as there is bug 92205, one of the "make system totally unusable" thingies. 
<Ubugtu> Malone bug 92205 in cupsys "Error on cupsys update" [High,Fix released]  https://launchpad.net/bugs/92205
<tkamppeter> You are much faster than me and Ubugtu.
<pitti> tkamppeter: it would be nice if 96_more-bug-fixes-between-cups-1.2.8-1.2.9 would unapply (but that's much lower priority)
<pitti> tkamppeter: building the package, and then cleaning it doesn't work ATM
<tkamppeter> Thnks pitti, otherwise we will get a similar duplicate collection as with hal
<tkamppeter> This is strange,  96_more-bug-fixes-between-cups-1.2.8-1.2.9 is simply a patch generated with dpatch-edit-patch.
<tkamppeter> Or do I have to list all patches explicitly also for unapplying (for applying they are in 00list)?
<pitti> tkamppeter: it has some junk in it (*.orig) which might be the reason; or some of the files it touches are modified during build
<jdong> hmm, where can I find a picture of mako?
<jdong> I think I walked past him 5 minutes ago, without realizing....
<tkamppeter> If CUPS 1.2.9 comes out before release simply lets make an UVF ER, as with this patch we are simply approaching 1.2.9 (all minor releases of CUPS are pue
<tkamppeter> pure bug fix releases.
<tepsipakki> jdong: planet.u.c
<Spads> jdong: http://mako.cc/images/mako_suit2-small.png
<jdong> looks.... strikingly similar
<jdong> I saw someone looking very similar, but with a longer beard, walking near the Stata center
<jdong> with an Asian girl
<tkamppeter> pitti, can you also upload gutenprint and gs-esp to fix bug 36532
<Ubugtu> Malone bug 36532 in gutenprint ""Unsupported format" when trying to print" [Medium,Fix committed]  https://launchpad.net/bugs/36532
<pitti> tkamppeter: can do a bit later; please mail me
<Mithrandir> jdong: his wife looks Asian, iirc.
<jdong> aww are you serious?
<sore_loser> I hate myself
<tkamppeter> pitti, I have already mailed you.
<cjwatson> she's of Japanese extraction I believe
<sore_loser> http://www.flickr.com/photos/krysalist/156408781/in/set-514981/
<sore_loser> yeah
<sore_loser> that's them
<sore_loser> I suck at life....
<pitti> sore_loser: http://mako.cc/copyrighteous/reflections/20060502-00.html
<sore_loser> yeah, definitely them
<pitti> cjwatson: packaging/quick source code review/QA looks good, approved
<cjwatson> pitti: thanks
<nixternal> Keybuk: pinging you letting you know that Palmer has issues building. It failed to build kubuntu-docs 7.04-3 and gnome games as well just a few minutes ago
<nixternal> ^^ or anyone else on the BDM
<hunger> Any fix to cups in the queue yet?
<cjwatson> pitti: 15:04  * pitti uploads fixed cupsys package, this time tested
<pitti> hunger: uploaded 30 minutes ago
<cjwatson> er
<cjwatson> hunger: ^--
<nixternal> pitti: you rock!!!
<hunger> pitti: Wow, you guys are fast! Thanks!
<nixternal> now I can print out my midterm cheat sheets :)
<pitti> nixternal: well, I don't; I should have tested the sponsored upload in the first place
<nixternal> pitti: well I should have done the same the otherday with kubuntu-docs
<nixternal> thank god they "DIDN'T" overwrite ubuntu-docs :)
<jdong> nixternal: we got one of those.... it was a mockery.....
<nixternal> heh
<jdong> "The area of a square with side s is s^2"
<jdong> thanks a lot.
<nixternal> lol
* hunger still has a broken cupsys and kubuntu-docs. I guess I'll have to wait a while longer for your uploads to get visible on my mirror.
<jdong> (it was for a multivariable calculus exam... TA's apparenlty find stuff like this funny)
<pitti> hunger: or dpkg -i the previous version in your apt cache
<hunger> pitti: Not that much of a problem. I hardly ever print anyway.
<nixternal> hunger: palmer broke down during the building of the new kubuntu-docs :) so you have to wait even longer for that one
<jdong> nixternal: actually it saw my xgl upload and went off to clean itself
<hunger> nixternal: Well, who needs docs anyway?
<nixternal> hehe
<nixternal> hey now, don't say that, I spent 5 months rewriting them
<hunger> nixternal: Oh, I'll better shut up then. Maybe I should even read them for a change.
<nixternal> heh, they aren't good
<nixternal> lol
<hunger> nixternal: What did you do those 5 month then? Stare at the blank screen wondering what to write?;-)
<nixternal> shh, there are to many *big whigs* in here ;p
<jdong_> nixternal: excellent use of the word "pervasive" :)
<jdong_> though I think pervasive availability = ubiquity </pun>
<Nafallo> BenC: thanks :-)
<ogra> pochu, could you please use real adresses in your mails ? "To: 	undisclosed-recipients : ;" makes my spamfilter unhappy
<pochu> ogra: sorry, but that mail was to about 30 or 40 people... and I'm not happy if then somebody does "reply all" ;)
<pochu> ogra: they were BBC
<ogra> ok ...
<pitti> ogra: hm, that's fairly common, though
<pitti> ogra: and I never saw it in actual spam
<ogra> just dont count on me seeing them then ...
<ogra> pitti, i filter *all* undisclosed-recipients mails to my spam folder, i never saw it in any regular mail 
<pochu> ogra: if had set up a ML, I would have spamed it ;)
<ogra> only from script mailers yet
<pochu> if you also
<mako> jdong: actually, that was me
<mako> jdong: i just walked by the stat center with an asian girl about 2 hours ago
<jdong> mako!!! :)
<jdong> mako: I was the nerdy looking asian kid crossing the street in front of stata :)
<mako> jdong: i didn't realize you were local
<mako> i thought you were in the midwest for some reason
<jdong> yeah, just got here spring term....
<jdong> I used to live in Michigan
<mako> jdong: you a student here now?
<jdong> mako: yeah
<mako> awesome :)
<jdong> awesome place :)
<mako> want to have lunch outside with some media labbers?
<iwj> Bah!  My dom0 still crashes even now I've made the machine have plenty of RAM.
<jdong> mako: aww already ate lunch, and got a calc exam tomorrow that I'm not ready for... perhaps another time :)
<Spads> iwj: all hail Xen, destroyer of nodes
<jdong> Spads: isn't that reiser? oh wait not inodes
<Spads> haha
<iwj> reiser - destroys more than just inodes.
<jdong> oh boy, a murder joke
* jdong braces
<Spads> jdong: it cuts down your btrees too
<jdong> we used "he cdr up piece by piece" in scheme class the other day :D
<shawarma> How many /win 2
<shawarma> Nice one.. 
<tkamppeter> pitti, I am putting up another cupsys package, 0ubuntu7, to fix bug 92042. Can you upload it. Thanks.
<Ubugtu> Malone bug 92042 in cupsys "cupsys in feisty doesn't put any backends into /usr/lib/cups/backend/" [Medium,Fix committed]  https://launchpad.net/bugs/92042
<pitti> tkamppeter: does this also fix the patch?
<jwendell> pitti, i have a file control.in with this inside: Build-Depends: @cdbs@,...
<jwendell> pitti, when i run debuild it fails saying there is no control file
<tkamppeter> Yes, I have removed two unneeded .orig files from it.
<pitti> jwendell: that's from the Dark Side of the Force
<pitti> tkamppeter: thanks
<jwendell> haha
<jwendell> pitti, how to generate control from control.in ?
<pitti> jwendell: look in debian/rules, there ought to be a special target for it
<jwendell> pitti, there isn't
<jwendell> #DEB_AUTO_UPDATE_DEBIAN_CONTROL:=yes
<jwendell> pitti, is that?
<pitti> jwendell: please don't enable it
<jwendell> :)
<pitti> jwendell: TBH, the cleanest fix would be to just move control.in to control, add the necessary build-deps, and rest in peace
<jwendell> pitti, ok, thanks :)
<pitti> jwendell: if not, temporarily uncomment that line, clean the package once, and comment it back
<ogra> pitti, isnt that even in the reject faq of debian ... ? i wonder how all these control.in hacks make it into the distro
<pitti> ogra: no idea about the reject faq; however, most Gnome packages have it as well
<pitti> ogra: it updates the Uploaders: field on build
<pitti> ogra: and having 'debian/rules generate-control' is fine; it's just evil to change it on clean or build IMHO
<ogra> i know what it does ... i got tricked by it often enough :)
<moox> hi there. Where are libapache2-mod-php4 for feisty ?
<ogra> pitti, http://ftp-master.debian.org/REJECT-FAQ.html 
<ogra> but its about changing build-deps, not maintainers/uploaders
<malix0> hi all
<geser> moox: php4 got removed from feisty
<moox> geser: mmh... baaad for me
<malix0> I have recompiled a package (with my patch) and installed it with dpkg, but now apt-get upgrade want upgrade the package with the one on-line, the two packages (the one recompiled from me and the one in the edgy-updates) have the same version
<geser> moox: can't you use php5?
<malix0> I have tried to use a local repository too, but the package on-line have precedence
<malix0> did someone can help me, thanks
<geser> malix0: you can set it to hold or better add an own suffix to your version
<malix0> geser: how ?
<geser> add an own changelog entry
<moox> geser: no, I must use ezpublish (php4 only). I'll install edgy using kvm :)
<pitti> moox: you so much don't want to install any Ubuntu php4 version
<pitti> moox: PHP 4 is not supported any more since breezy
<malix0> geser: with dh_installchangelogs ?
<jdong> oh look RHEL5 is out.
<ogra> malix0, update the version in the sourcepackages changelog before building the package 
<geser> malix0: no, edit debian/changelog
<moox> pitti: ok. I didn't know..thanx
<shawarma> How many SoC applications did we get last year?
<malix0> geser: ok now I'm rebuilding the package
<malix0> geser: I change the debin/changelog manually, but is there a tool that I can use for this task?
<geser> malix0: dch from the devscripts package
<malix0> geser: thanks :)
<malix0> geser: excuse me, I have another question
<ogra> seb128, hughsie will care for the sparc fix upstream he said ... (alongside with fixing -Werror)
<tkamppeter> pitti, ich habe jetzt noch ein neues foo2zjs-Paket zum hochladen fuer dich, fuer bug 92216 (biff)
<Ubugtu> Malone bug 92216 in foo2zjs "File in foo2zjs conflicts with mcompress" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92216
<ogra> so we just have to wait
<malix0> geser: this time regarding package repository. I follow the Debian repository how to  and create a repository tree
<seb128> ogra: k
<ogra> he said leaving Werror in place was intentional to find build errors :P
<malix0> geser: but how can I manage the pool tree? Is there a tool?
<tkamppeter> pitti, but there is one thing which has to be done by a release manager. foo2zjs depends on mscompress now and mscompress is in universe
<tkamppeter> Can you move mscompress to main?
<pitti> tkamppeter: that requires a main inclusion report and review
<tkamppeter> pitti, also needed if it is taken in by a dependency?
<pitti> tkamppeter: yes, of course
<pitti> tkamppeter: urgh, why is that thing necessary? cupsys certainly doesn't need mscompress'ed files?
<ogra> pitti, GDI drivers ? 
<pitti> tkamppeter: please mail me for all pending uploads
* pitti -> dinner, bbl
<mvo> pitti: I fixed a bug in the apport integration code, new upload soon
<pitti> mvo: great, thanks
<mvo> pitti: thanks for verifiying it
<wolferine> <Seveas> i try to help you, you respond with personal atacks. You get banned. Simple <-- how did I personally attack you?
<ogra> wolferine, please stop spamming all channels
<Treenaks> wolferine: don't take fights from other channels here
<mjg59> Mithrandir: Are you able to trigger another rebuild of acpid?
<jwendell> seb128, we have entire gtk 2.10.10 in feisty, right?
<seb128> jwendell: we have 2.10.10 patched to work (equivalent of 2.10.11)
<seb128> jwendell: I did upload it before getting the tab bug fixed
<seb128> s/did/didn't
<jwendell> seb128, right, i guess there was a mistake on 2.10.10 release...
<seb128> jwendell: they don't roll a new tarball in the next day for nothing ;)
<bddebian> Heya
<Toadstool> smart-notifier (0.28-1ubuntu2) feisty; urgency=low
<Toadstool>   * debian/smart-notifier.postinst: no need to restart dbus daemon anymore
<Toadstool> oops
* Toadstool hides
<Mithrandir> mjg59: not when LP is offline, no.  If it ftbfs, I can trigger it when I get home again (I'm on my way out the door)
<pochu> Mithrandir: just the beta is offline (dunno if that helps)
<Mithrandir> mjg59: it didn't ftbfs, so no, I can't trigger a rebuild.  Just upload a new version.
<pitti> Mithrandir: what would you think about fixing bug 87292 with http://pastebin.ca/394978 ?
<Ubugtu> Malone bug 87292 in python2.5 "packaging backend crashes with "Interrupted system call"" [Medium,Confirmed]  https://launchpad.net/bugs/87292
<pitti> Mithrandir: we can fix it in python proper and thus solve the problem for other Python applications as well, or I stuff it in apport to just fix the bug there; the former has the theoretical impact of breaking apps which *expect* EINTR to be thrown from subprocess (although I cannot conceive why someone would want this)
* nixternal hugs pitti - thanks for fixing cups - cheat sheets gallore
<mjg59> Mithrandir: ? It did ftbfs, surely?
<mjg59> Or has it been pushed through again since then?
<pitti> Mithrandir: I attached the debdiff to the bug as well
<jwendell> seb128, can ubuntu backport that patch? (bug 83278)
<Ubugtu> Malone bug 83278 in gtk+2.0 "Phantom space in Notification Area" [Low,Fix committed]  https://launchpad.net/bugs/83278
<asac> cdimage.ubuntu.com gives me 23Kb/s :(
<seb128> jwendell: it was on my list
<jwendell> seb128, 'was' ?
<seb128> it was already on my list
<jwendell> hehe
* jwendell hugs seb128 !
* seb128 hugs jwendell
<trycyt> Can update-alternatives be used to manage symlinks in /usr/lib/cups/backend ?
<trycyt> Anyone?
<seb128> trycyt: is that required?
<seb128> trycyt: better to avoid alternatives when they are not really required
<trycyt> seb128: I'm making a package in which a CUPS backend has to be determined through a symlink.
<dholbach> Riddell: when you updated decibel - did you change the packaging to split out different libraries? different library packages?
<Riddell> dholbach: there is only 1 library, I renamed the binary packages
<Riddell> dholbach: although I see now I forgot to update the shlibs lines in debian/rules
<trycyt> seb128: So the symlink /usr/lib/cups/backend/smb would point to an alternative spooler besides /usr/bin/smbspool
<dholbach> Riddell: ok, just wanted to make sure
<dholbach> Riddell: was the consensus to just upload "that stuff" now?
<trycyt> seb128: And as far as I've seen, alternatives are used liberally in other Debian packages.
<Riddell> dholbach: from the kubuntu side it was :)
<ajmitch> morning
<dholbach> Riddell: as I said in the thread - we should probably talk about that with the TB - as the TB approved the spec
<ajmitch> a shame we just missed a TB meeting yesterday 
<dholbach> Riddell: i really don't want to argue and fight over it
<seb128> trycyt: yeah, extra complexity create bugs, I just don't like alternatives much because of that
<Riddell> I'm happy to have tech board consider it
<dholbach> hi ajmitch
<ajmitch> hey daniel
<dholbach> it seems that some people thought that the MC decided something already - which was not the case
<dholbach> some people merely expressed concerns
<dholbach> I wouldn't like to have tension over that topic or block people's work that much.
<ajmitch> if the MC makes a decision, people won't be happy
<ajmitch> same if the KC makes a decision :)
<dholbach> "we're going to do it anyway" is just not an option
<dholbach> might be that the MC was the wrong group to ask and the TB would have been the better place
<trycyt> seb128: Hmm, also, would a package maintainer ever need to add anything in the Depends: line other than ${shlibs:Depends} ?
<trycyt> seb128: According to what I've read it appears as though I wouldn't, but is it just redundant if I include the dependencies anyway?
<trycyt> seb128: Or is it actually necessary?
<seb128> trycyt: shlibs work for libraries, not for icon theme, other binaries, utils required, etc
<tkamppeter> pitti, I have done a MainInclusionRequest for mscompress, so the foo2zjs problem can be fixed for the Feisty beta.
<tkamppeter> pitti, I have also sent mails to you about all needed package updates. There were many today.
<trycyt> seb128: So a program needs it to be compiled, ${shlibs:Depends} would automagically know of which package to use?
<pochu> do you guys know when we will the first beta candidate? Mithrandir ?
<tkamppeter> Mithrandir, pitti, some minutes ago ESP GhostScript 8.15.4 was announced, the last ESP GhostScript at all (after that ESP GS and GPL GS will merge). This release is a pure bug fix release and most of these fixes are already in our package by means of patches. Should I package 8.15.4 for Feisty (beta)?
<dholbach> pochu: http://wiki.ubuntu.com/FeistyReleaseSchedule
<ajmitch> hm, strigi was uploaded?
<pochu> dholbach: there it says when beta will be out, but not the beta candidates (to test them, as Testing/Matrix)
<dholbach> ah ok
<pochu> thanks anyway :)
<dholbach> good night everybody - see you tomorrow
<mdz> pochu: not until the freeze begins, at the earliest
<pochu> mdz: ok, ty
<pochu> mdz: the freeze is tonight, isn't it? :)
<trycyt> So does update-alternatives not work with anything outside of /usr/bin? As in, can I do something like sudo update-alternatives --install /usr/lib/cups/backend/mytest mytest /usr/bin/myprogram 50 ?
<trycyt> It doesn't seem to be working for whatever reason.
<Treenaks> trycyt: works fine for /usr/share (ls -l /etc/alternatives)
<evo_> is there a way to see a list of projects ubuntu is looking to find developers for?
<Treenaks> evo_: do you mean http://www.ubuntu.com/employment or https://blueprints.launchpad.net/ubuntu/+specs?
<trycyt> Treenaks: It seems to generate a broken symlink for me.
<evo_> Treenaks: more like package maintainer stuff
<Treenaks> evo_: ah.. wiki.ubuntu.com/MOTU ?
<evo_> that looks like the one, thanks!
<seb128> trycyt: shlibs will list all the libs your program is using
<ogra> seb128, ogra@edubuntu:~/packages/ltspfs-0.4.3$ yelp 
<ogra> Segmentation fault (core dumped)
<ogra> :(
<ogra> thats 2.18
<seb128> ogra: what libgnomevfs2-0 version?
<ogra> the last 2.17 ... 
<ogra> shouldnt there be a versioned dep ? 
<mjg59> And license their cores
<mjg59> Oops.
* ogra upgrades libgnomevfs2-0
<seb128> ogra: could you get the exact version you are using?
<seb128> ogra: 2.18.0 is buggy, 2.17 is not
<ogra> 2.18.0-0ubuntu1
<seb128> ogt
<ogra> aha
<seb128> ok
<seb128> you want 2.18.0.1
<seb128> it fixes the yelp crasher and has been uploaded yesterday
<ogra> yep, just getting 
<ogra> thanks
<seb128> np
<ogra> i havnet seen the edubuntu docs yet, i was already worried they cause a crash :)
<Mithrandir> mjg59: I gave it back after pitti uploaded the pkgmaintainermangler fix the other day.
<Mithrandir> tkamppeter: can you give me a debdiff and a list of the bugs in LP it fixes?
<mjg59> Mithrandir: Ah, excellent. No worries, then.
<Mithrandir> happy to help. :-)
<imbrandon> Mithrandir, hum is there a reason mod-mono still hasent built yet ?
<Mithrandir> imbrandon: it's still in the queue, since I'm a slacker.
<imbrandon> ahh ok , no worries, just was asking someone to test and it wasent there 
<imbrandon> hehe
<imbrandon> thought something might have went wrong
<Mithrandir> imbrandon: can you set the bug to fix committed?  It should be referenced in the changelog.
<imbrandon> sure
<Mithrandir> ok, accepted.
<imbrandon> you rock
<Mithrandir> it just didn't make this cycle, so it'll be published in about 1.5 hours, then built in the next cycle, so the binaries should be around a little before midnight UTC, I think.
<imbrandon> Mithrandir, k, thanks
<Gwaihir> can somebody help me with a package-find issue? or at least tell me where can I ask...
<Gwaihir> I'm looking for the desktop-effects package... to translate it...
<pochu> Gwaihir: have you tried in Launchpad?
<Gwaihir> nope... I'll try... thx
<ogra> yay GNOME 2.18 released \Q/
<jdong> yay are there any buttons left on the print dialog?
* jdong ducks
<seb128> jdong: what do you mean?
<jdong> it seems like printer options tend to disappear from GNOME over time :)
<seb128> weird
<tepsipakki> the new dialog is nice
<seb128> the new GTK+ API should have most of useful options
<jdong> like what's the justification for not presenting printer options to the user at print-time?
<tepsipakki> if only OO.org used it
<seb128> what dialog are you speaking about?
<seb128> libgnomeprintui is crap
<jdong> seb128: i.e. epiphany's Print dialog
<seb128> the new GTK dialog should be fine
<jdong> ok, haven't tried the new one yet
<seb128> what option do you lack? margin?
<jdong> seb128: print quality
<seb128> epiphany uses GtkPrint
<jdong> seb128: I have a photo printer, and that setting makes a huge difference between ink used and outpt quality
<Fujitsu> jdong: Print quality is the big one I miss.
<seb128> do you have an advanced teb?
<seb128> tab
<jdong> seb128: the option is availabe from the cups manager thing
<jdong> seb128: but lacking in any print dialogs... I know Edgy didn't have any advanced tabs
<seb128> maybe it depends on your printer
<Fujitsu> It's certainly not there in Feisty.
* jdong hcecks
<seb128> epiphany has an advanced tab with a "print mode" and a "resolution, quality, ink type, media" option
<jdong> no, not in Feisty either
<jdong> how do you get all those options?
<seb128> I don't have them when printing to a file
<jdong> hmm
<seb128> using a printer I've them though
<jdong> maybe that's different in Feisty then
<jdong> that'd be a great improvement
<jdong> and I just noticed that Feisty allows custom print commands
<jdong> which is wonderful...
<seb128> jdong: now is a good time to try feisty rather than describing edgy bug
<jdong> all our campus printers are lpr/kerberos
<jdong> seb128: since coming to college I don't have access to my photo printer anymore
<seb128> jdong: that's not a design decision, works fine with my deskjet printer, feel free to open a bug, it's either due to cupsys or gtk
<jdong> ok, thanks
<seb128> jdong: np
<jdong> seb128: btw did you ever figure out what's the deal with that fglrx compiz patch?
<seb128> it's on my list of things to do, I've been busy with GNOME 2.18.0, I'll probably upload that tomorrow
<jdong> don't work too hard :)
<pitti> Mithrandir: still awake?
<tkamppeter> Mithrandir, I am creating the new ESP GS package now and will send you an UVF ER mail with debdiff and upstream ChangeLog when done.
<tkamppeter> Anyone still awake who can approve a UVF ER?
<sistpoty> tkamppeter: does it still have the x/nox split, as I'm just gathering a few possible breakages on bug #83597 (not that I could approve an UVFe though)
<Ubugtu> Malone bug 83597 in kdegraphics "Unknown device: x11alpha " [Medium,Confirmed]  https://launchpad.net/bugs/83597
<tkamppeter> sistpoty, it has the split, and the split will stay, as it is a feature to reduce the installed size of servers.
<sistpoty> tkamppeter: sure, makes sense
<mjg59> slomo_: Any chance I can convince you that Liferea 1.2.8 is a good plan?
<mjg59> slomo_: Significant performance improvements, no other changes
<ogra> urgh
* ogra gets bombed with session recovery dialog from FF
<ogra> *dialogs
<jdong> ogra: now you know how Congress feels after summer recess.
<ogra> heh
#ubuntu-devel 2007-03-15
<pitti> hi Keybuk 
<cliebow_> tkamppeter:i notice in ppc dist-upgrade to feisty from edgy that cups seems not to start..Ill pass on tomorrow anything if you are interested
<cliebow_> tkamppeter, ogra suggested i mention this
<pitti> cliebow_: I guess that's already fixed
<_ion> http://popey.com/Ubuntu_is_sexy_alright (The answer: yes, it could: http://seveas.ubuntulinux.nl/falcon-2.png)
<cliebow_> ok..ill  poke at it again tomorrow
<Seveas> _ion, :p
<pitti> cliebow_: just try dist-upgrading
<ogra> Seiya, well, he's right :)
<ogra> Seveas, ^^
<Seveas> ogra, yeah, but I have an excuse
<ogra> Seveas, but at least yours only shows one gender and no act ...
<Seveas> I'm horrible with graphics :)
<ogra> heh
<tkamppeter> cliebow_, you are probably hitten by bug 92205, wait for at least CUPS 1.2.8-0ubuntu6 reaching your mirror.
<Ubugtu> Malone bug 92205 in cupsys "Error on cupsys update" [High,Fix released]  https://launchpad.net/bugs/92205
<cliebow_> tkamppeter, very  good..will do!
<tkamppeter> pitti, you are still around? I have packaged ESP GhostScript 8.15.4 which was released today and is the last ESP GhostScript at all (biff).
<pitti> tkamppeter: this needs UVF exception from Tollef
<cliebow_> pitti:UVF?
<pitti> upstream version freeze
<cliebow_> thank you..just learning...ltsp guy here...
<tkamppeter> pitti, yes, therefore this mails is primarily addressed to Tollef, but also to others who perhaps can approve this. You are CCed because you will probably upload it as sson as it is approved.
<pitti> right
<cjwatson> tkamppeter: (approved, see mail)
<tkamppeter> pitti, ESP GS is approved, can you upload it ASAP so that it hits the beta?
<tkamppeter> cjwatson, in how many hours from now is the freeze?
<pitti> tkamppeter: no breakages and properly tested this time? :)
<cjwatson> tkamppeter: I don't know exactly; tomorrow European business daytime sometime
<ogra> tkamppeter, traditionally the freezes started with the dev meeting, but that might have changed and is not a policy or something
<tkamppeter> pitti, yes, there are no changes in dependencies, pre/postinstall scripts, ... I hab
<ogra> cjwatson, we should probably set a time at some point and make it policy ... its easier to work towards a deadline you know
<tkamppeter> have printed through it and displayed files with it, discovering that bug 42446 is fixed but many other bugs reported to Ubuntu are not fixed, but I did not find any regression.
<Ubugtu> Malone bug 42446 in gs-esp "Ghostscript uses wrong font size with x11alpha (Dapper)" [Medium,Unconfirmed]  https://launchpad.net/bugs/42446
<cjwatson> I don't know about Tollef but I know that at least I wanted to encourage people not to work towards any particular time on freeze day
<cjwatson> but it's Tollef's call now
<ogra> why didnt you want that ? 
<cjwatson> you get pathological results when people try to play the deadline to the nearest minute
<kwwii> minute? I count the seconds :p
<ogra> for me knowing i have to be done at 16:00 UTC helps a lot since i know i can sleep some hours and go on tomorrow morning ...
* cjwatson prefers to know that he's done when he leaves work the day before
<ogra> as long as i dont know that i will go on working and not sleep until i've done everything
<tkamppeter> But it is also bad if someone plans to do something at a certain hour, and then out of the blue, shortly before he finishes, the freeze gets announced.
<cjwatson> then it doesn't have to be radically different for different people
<cjwatson> tkamppeter: this is why it's a really, really, really bad idea to plan to land things on freeze day
<ogra> tkamppeter, yes, thats why i work tonight
<cjwatson> sometimes things have to slip right up to the freeze, which happens, but it shouldn't be the norm
<ogra> tkamppeter, and i guess its the reson for pitti as well ...
<pitti> ogra: indeed ;)
<cjwatson> of course I'm breaking my own guidelines by being up late working tonight ;)
<ogra> heh
<tkamppeter> For me it happened that ESP GS 8,15,4 was announced at 9pm GMT and I remembered Ubuntu deadlines being at midnight GMT and so I submitted my UVF ER shortly before midnight to meet the deadline.
<cjwatson> I don't recall any deadline ever *actually* being at midnight
<cjwatson> but my memory may not be perfect
<cjwatson> sometimes Chinese Whispers comes into play
<tkamppeter> Originally, I did not know that this release will happen today and has a chance to hit the beta.
<cjwatson> I'm perfectly OK with the result of freezes being that sometimes upstream releases don't make it
<pitti> tkamppeter: well, would it hurt too hard if we upload it after beta?
<cjwatson> anything this close to the beta needs to be reviewed pretty carefully anyway
<pitti> tkamppeter: i. e. does the current version have 'OMGskyisfalling' bugs?
<tkamppeter> There were many deadlines set to the beginning GMT midnight of a Thursday, as on Thursday there is devel meeting.
<tkamppeter> What are 'OMGskyisfalling' bugs? These ones like the recent ones of hal and cupsys where we get more than 10 duplicates quickly as they break important functionality?
<pitti> yes, stuff like that
<cliebow_> i do like to sit in..gives me a feel for how it goes together
<tkamppeter> I have never made so many Ubuntu packages on one day as today, fixing up bugs before the beta deadline.
<cjwatson> tkamppeter: I think that's Chinese Whispers (if the idiom is difficult, that means rumours getting gradually corrupted as they pass from person to person). I can't find any announcements that actually specified that time.
<pitti> tkamppeter: bug 92042 seems to be quite serious
<Ubugtu> Malone bug 92042 in cupsys "cupsys in feisty doesn't put any backends into /usr/lib/cups/backend/" [Medium,Fix committed]  https://launchpad.net/bugs/92042
<cjwatson> I think it's possible that somebody told you that time, but that's not the same as it being announced as such ...
<pitti> cjwatson: ah, thanks for the 'Chinese Whispers' :) in German we have a similar phrase ("Stille Post")
<cjwatson> anyway, not really important now
<tkamppeter> I hate deadlines being announced only by the day and not by the time, especially in international projects like Ubuntu
<tkamppeter> bug 92042 I have fixed, should be done in cupsys 1.2.8-0ubuntu7, pitti, have you uploded
<Ubugtu> Malone bug 92042 in cupsys "cupsys in feisty doesn't put any backends into /usr/lib/cups/backend/" [Medium,Fix committed]  https://launchpad.net/bugs/92042
<cjwatson> assume the least favourable interpretation to you and you'll never be disappointed
<pitti> tkamppeter: right, I meant that this should go into beta
<tkamppeter> it? I had it ready hours before the potential deadline.
<pitti> tkamppeter: doing now; I was at Taekwondo this evening, and I cannot always immediately sponsor packages
<pitti> tkamppeter: cupsys> you tested upgrades and fresh install?
<pitti> tkamppeter_: cupsys> you tested upgrades and fresh install?
<tkamppeter_> Yes, now I let the postinstall script always recreate the links, independent whether the user has done changes via debconf or not.
<pitti> tkamppeter_: weird, I don't have links, I have file copies
<pitti> ah, those are hardlinks
<tkamppeter_> pitti, the links are hard links. the postinstall script does "ln" without "-s".
<pitti> tkamppeter_: hm, symlinks would be a bit clearer, but *shrug*
<tkamppeter_> I do not know why these are hard links. Probably someone at Debian opted for this way.
<pitti> tkamppeter_: why are there more files in backend/ than in backend-available? (beh, bluetooth, canon, epson, hp, hpfax)
<pitti> ah, those are from other packages
<pitti> tkamppeter: gs-esp does not have an updated Maintainer: field; please use current feisty's dpkg
<pitti> tkamppeter: I set it now
<tkamppeter> I have always used current Feisty's dpkg. Strange, for all other packages it complained with a bad Maintainer: field.
<pitti> tkamppeter: also, the source diff.gz has changes to upstream code, although the package uses dpatch
* pitti waves to iwj
<tkamppeter> I have done my Debian morning gymnastics every day (sudo apt-get dist-upgrade).
<pitti> tkamppeter: ah, you don't have an Ubuntuish DEBEMAIL, that's why dpkg doesn't fail any more (it just warns)
<tkamppeter> These changes in diff.gz seem to comne from Debian. There were always there and I never touched them.
<pitti> tkamppeter: still these three added files in the diff.gz are alright?
<pitti> ok
<tkamppeter> Yes, by the last upstream one of these files has even gone away (src/gdevpdfo.c).
<pitti> alright, 'nuff for today
* pitti hits the sack, good night everyone
<_ion> Good night.
<tkamppeter> Good night pitti, and thanks for the quick reviews and uploads.
<Sambis> Hi
<Sambis> I hate microsoft
<Sambis> I am doing a degree in IT and you have to use MS OFFICE
<Sambis> $400 later.
<Sambis> I'm bitter
<Sambis> and I'm twisted
<Sambis> Keep up the good fight.
<Sambis> roll on SOLIDIERS
<lifeless> Sambis: you can't use open office?
<Sambis> No
<Sambis> they wont let you or atleast your marks will be lower.
<fabbione> morning
<Sambis> We are living in a microsoft world. 
<lifeless> Sambis: how would they know?
<Sambis> o00oo and MS are a bit different
<lifeless> anyhow, its really offtopic here, but frankly, I wouldn't take such a course.
<Treenaks> Sambis:  We all live in a Windows subroutine 
<Sambis> lol
<Sambis> HAha.
<Sambis> funniest thing ive seen all day.
<Sambis> anyway back on topic
<Treenaks> fabbione: do you know who I should contact, or where I should look for someone who wants an USB device for driver development?
<slomo_> mjg59: sure, i'll look at it later today
<fabbione> Treenaks: it depends from the device i guess
<fabbione> what is it?
<Treenaks> fabbione: A "phone" (USB audio device; this part works, with a bunch of buttons, that don't work) (bug 72079)
<Ubugtu> Malone bug 72079 in linux-source-2.6.20 "Keys of USB "handset" not working" [Undecided,Needs info]  https://launchpad.net/bugs/72079
<Treenaks> The only place I've seen those buttons working is using a special driver from the manufacturer, in skype, in windows
<fabbione> Treenaks: it's a skype phone.. they used to have a driver for linux too
<Treenaks> fabbione: but I don't want skype, I want ekiga ;)
<fabbione> let me rephrase
<fabbione> skype wrote a linux driver for the keys
<fabbione> no matter for what app you use it
<Treenaks> oh.. cool
<Treenaks> hmm
<fabbione> give me a little bit
<fabbione> i will ask the skype guys
<Treenaks> fabbione: there's a "Yealink" driver for some kind of Skype phone in the kernel already, but that doesn't work for this device
<fabbione> Treenaks: can you please add all these info to the bug?
<Treenaks> fabbione: will do
<Treenaks> can I quote this IRC conversation?
<fabbione> yeps
<Treenaks> fabbione: done
<fabbione> thanks
<Treenaks> (I've also added the hardware offer)
<Lure> cjwatson: seen that? http://weblog.obso1337.org/2007/user-based-testing-expected-for-digikam-and-ubiquity/
<pitti> Good morning
<ajmitch> morning pitti 
<Mithrandir> pitti: I'm awake now.
<pitti> Hello Mithrandir 
<Mithrandir> morning
<pitti> Mithrandir: if you have a minute, I'd like to get your general gut feeling about bug 87292
<Ubugtu> Malone bug 87292 in apport "packaging backend crashes with "Interrupted system call"" [Medium,In progress]  https://launchpad.net/bugs/87292
<Mithrandir> pitti: ah, yes, I looked a bit at it last night.
<pitti> Mithrandir: i. e. should we fix this in python itself to fix it for all Python programs, or just fix it in apport
<Mithrandir> I'm fine with fixing it in python, but I wonder why you seem to effectively remove the 1MB size limit exception for exceptions?
<pitti> -            data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
<pitti> +            data = self._read_all(errpipe_read, 1048576) # Exceptions limited to 1 MB
<pitti> Mithrandir: I do?
<pitti> Mithrandir: if I did that inadvertedly, I'll fix it of course
<Mithrandir> ++        def _read_all(self, fd, buffersize):
<Mithrandir> ++            """Like os.read, but retries on EINTR, and reads until EOF"""
<Mithrandir> ++            all = ""
<Mithrandir> ++            while True:
<Mithrandir> ++                data = self._read_no_intr(fd, buffersize)
<Mithrandir> ++                    return all
<Mithrandir> ++                all += data
<Mithrandir> ++                if data == "":
<Mithrandir> that seems to read all the data and the buffer size is just that, a buffer size?
<pitti> ah, indeed
<pitti> -                data = self._read_no_intr(fd, buffersize)
<pitti> +                data = self._read_no_intr(fd, buffersize-len(data))
<pitti> Mithrandir: ^ that should do
<khermans__> "... cmon ... developers, developers, developers, developers, developers ... "
<pitti> erm, len(all) of course
<pitti> Mithrandir: thanks for catching this
<Mithrandir> pitti: can you attach a new debdiff and I'll review that?
<pitti> Mithrandir: sure, but I'll build and run the test suite first
<Mithrandir> pitti: also, do you know what python upstream thinks of it?
<pitti> Mithrandir: I sent it to http://sourceforge.net/tracker/index.php?func=detail&aid=1068268&group_id=5470&atid=105470
<Ubugtu> Sourceforge bug 1068268 "subprocess is not EINTR-safe" [Pri: 3,Open]  
<pitti> Mithrandir: but no answer yet
<pitti> Mithrandir: it has been reported 3 years ago already
<Mithrandir> I'm wondering if we should make it optional, but that entails changing the API (but it'd be backwards-compatible by using a default argument)
<pitti> and google is full of this kind of error
<Mithrandir> hmkay
<pitti> uh, new kernel just before the beta freeze
<dholbach> good morning
<_ion> Morning.
<dholbach> hi _ion
<pitti> dholbach: does launchpad.HTMLOperations already know how to scrape an LP bug list page and return a list of bug numbers?
<dholbach> pitti: yes
<dholbach> pitti: BugList() should do that
<_ion> Eww, parsing HTML with regexps
<dholbach> we'll try to move to xpath in 0.2
<ajmitch> hi dholbach 
<dholbach> hi ajmitch
<_ion> I love WWW::Mechanize for screen scraping: http://codebrowse.launchpad.net/~ion/restricted-manager/ion/annotate/johan%40kiviniemi.name-20070313142552-ftr0w5oheprva94w?file_id=nvidia_supported-20070310133217-8rcwj3c0tsd5pv1w-2
<_ion> It's a Ruby module, though.
<pitti> Mithrandir: updated debdiff: http://librarian.launchpad.net/6820346/python2.5.87292.debdiff , actual code changes: http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch
<_ion> dholbach: The gist of that code is basically: get 'http://www.nvidia.com/object/linux_display_archive.html'; click page.links.with.href(link_re); click page.links.with.text(/Supported Products List/); (page / 'td[text() ^= "0x"] ').map {|td| td.inner_html.strip.hex }
<_ion> dholbach: That returns an array such as [0x0112, 0x01A0, 0x0111, ...]  scraped from a page such as http://www.nvidia.com/object/IO_18897.html
<dholbach> looks nice
<pitti> Mithrandir: hmm, bug 91699 is a very interesting RM decision :/
<Ubugtu> Malone bug 91699 in xserver-xorg-input-evdev "FTBFS with current xorg headers" [High,Confirmed]  https://launchpad.net/bugs/91699
<dholbach> although I think I'd prefer xpath statements somehow
<pitti> Mithrandir: busted if you do, busted if you don't...
<_ion> dholbach: The 'td[text() ^= "0x"] ' is an xpath statement. :-)
<dholbach> yeah :)
<Mithrandir> pitti: won't _write_no_intr return the wrong value if you get eintr?  You don't save the return value anywhere?  (But I'm not sure if python gives you that?)
<pitti> Mithrandir: not sure what you mean? it's immediately returned
<pitti> Mithrandir: the only other exit point is the raise
<pitti> return os.write(fd, s)
<Mithrandir> pitti: true, eintr is only returned if you were interrupted before any data was written.
<Mithrandir> pitti: I'm unsure if python correctly handles the case of some being written and you then getting a signal (since the return value will then be less than len(data))
<Mithrandir> pitti: but that's a different problem
<pitti> Mithrandir: that should be identical to write(2)
<pitti> Mithrandir: i. e. if it's interrupted in the middle, the whole write(2) call fails with EINTR
<pitti> and we don't know how much was written
<Mithrandir> that's not what write(2) says.
<pitti> Mithrandir: so the only way to ensure integrity is write(2) itself - it has to roll back the writing on EINTR
<Mithrandir>        EINTR  The call was interrupted by a signal before any data  was  writ
<Mithrandir>               ten.
<pitti> ah, nice
<Mithrandir> in some cases, you can't roll back.  Think a TCP connection.
<pitti> Mithrandir: so write() seems to make sure that it is transactional
<Mithrandir> pitti: no.  write writes as much as it can, but if you're interrupted in the middle, you'll have a return value that's smaller than count.
<pitti> Mithrandir: right, but then it won't return -1, but a positive number, and thus isn't regarded as 'failed'?
<Mithrandir> I doubt many python programs handle that case correctly; they expect an exception if not all the data is written.
<fabbione> hey Keybuk 
<Mithrandir> pitti: correct.  It just didn't do what the programmer expected.
<Keybuk> heyhey
<Mithrandir> pitti: anyway, looks good, go for it.
<pitti> Mithrandir: yup
<pitti> Mithrandir: but I still think that _write_no_intr() doesn't change that semantics
<Keybuk> Mithrandir: throwing an exception and erroring is at least better than most C programs, which carry on regardless :p
<Mithrandir> Keybuk: but python won't be throwing an exception here, I'm fairly sure.
<pitti> Mithrandir: if a program does the wrong thing with _write_no_intr(), it will do the same wrong thing with a plain write(), too
<Mithrandir> pitti: you're correct, it doesn't.
<Mithrandir> Keybuk: the joy of entering in the middle of a larger discussion. :-)
<pitti> Mithrandir: alright; thank you very much for the review!
<pitti> hi Keybuk 
<Keybuk> Mithrandir: ahh
<Keybuk> sorry
<Mithrandir> Keybuk: we're discussing what happens if you write(2), then get a signal.  In C, you'll just get a smaller return value than what you expected, but I think it's even less common for python programs to handle this correctly (and I don't think python gives you an exception in that case)
<imbrandon> moins all
<fabbione> Keybuk: once you are settled, do you mind to drive me a few minutes to the UUID transition procedure?
<Keybuk> fabbione: sure
<Keybuk> Mithrandir: varies on how you set the signal handler
<fabbione> great thanks
<Keybuk> you can get either a smaller value, -EINTR or the value you expected to be written
<pitti> Mithrandir: ah, the fileobj write method does not return a value; that might mean that it checks for written == buffer size and throws an exception on inequality
<pitti> Mithrandir: that would indeed be much more pythonic
* pitti checks the code
<uatschitchun> Good morning!
<uatschitchun> Someone here who is able to answer a little question concerning .desktop-files?
<Keybuk> (SA_RESTART ftw [* conditions apply; may not be fully implemented by your kernel; your kernel is at risk if you don't keep up payments on your mortgage or any other loan secured on it; full written terms available on request] 
<TheMuso> uatschitchun: Might be better asking in #ubuntu-motu.
<uatschitchun> It's in connection with debs and a not-showing menu item after installation ... so this one is better placed in motu?
<pitti> Mithrandir: indeed, it does pretty much that
<TheMuso> uatschitchun: What package?
<uatschitchun> my own package beeing on the way to get into buntu
<pitti> Mithrandir: I don't see how it helps to ensure data integrity, but *shrug*
<TheMuso> uatschitchun: Well #ubuntu-motu will be your best bet.
<uatschitchun> k
<uatschitchun> so have a nice day ;)
<stephanbuys> hi all, anyone working on: https://wiki.ubuntu.com/BetterBluetoothSupport ?
<stephanbuys> I am developing some gnome bluetooth utilities and I'm searching for the best place to co-ordinate work. 
<seb128> dholbach: ^
<dholbach> stephanbuys: nice - what are you working on?
<stephanbuys> dholbach, my "itch" that I'm scratching is that I want to use my cellphone's serial port to do dial-up networking via bluetooth
<stephanbuys> dholbach, thus the app is a very simple pygtk/dbus app to detect devices in range, allow you to auth and create /dev/rcomm* with a couple of clicks
<stephanbuys> dholbach, then I'll try and make sure that network-manager recognizes the ports created in the process
<dholbach> stephanbuys: that sounds awesome
<stephanbuys> dholbach, its very simple and uses a lot of the established dbus apps (for pins, device discovery etc)
<dholbach> stephanbuys: I suggest you add it to wiki.ubuntu.com/Bluetooth and send a mail to ubuntu-bluetooth@googlegroups.com - so people can test it
<dholbach> stephanbuys: i fear it's too late to get it into feisty - but for feisty+1 we should definitely consider it
<dholbach> stephanbuys: what do you think?
<stephanbuys> dholbach, perfect. it wont be ready for feisty anyway. I just needed what you just provided to let people know what I'm up to
<stephanbuys> dholbach, to avoid yet-another-bluetooth-app :-)
<dholbach> stephanbuys: Marcell Holtmann also reads that list, so I think it's a good place to talk about it
* dholbach hugs stephanbuys
<dholbach> good work
<stephanbuys> dholbach, thanks!
<dholbach> :-)
<Tonio_> Mithrandir: is that too late to upload in main ? I have a new kmplayer, bugfix release, ready for upload
<Mithrandir> Tonio_: we're not frozen yet, if that's what you are asking about
<Tonio_> Mithrandir: that's the real question indeed ;) let's go with upload then, thanks
<pitti> Keybuk: you wanted restricted-manager on the live system for beta, right? if so, I should go on and promote/seed/ubuntu-meta it
<pitti> Keybuk: I'm now reasonably confident that it won't break people's boxes too hard any more
<tbf> seb128: switching channels to avoid upsetting fcrozat too much ;-)
<seb128> tbf: ok ;)
<tbf> seb128: what was the pretty dist-upgrade command again?
<Keybuk> pitti: yes please
<seb128> tbf: update-manager -d?
<tbf> seb128: ah. indeed :-)
<seb128> hate hate hate quilt
<pitti> seb128: ?
<seb128> pitti: 
<seb128> quilt --quiltrc /dev/null pop -a -R || test $? = 2
<seb128> Patch 099_autoreconf does not remove cleanly (refresh it or enforce with -f)
<seb128> make: *** [clean]  Error 1
<seb128> 
<seb128> $ grep 099_autoreconf taglib-1.4/* -r
<seb128> $
<pitti> seb128: well, that's usually not quilt's fault; this happens with othe rpatch systems, too
<seb128> it happens with quilt only on my desktop
<pitti> seb128: oh, hmm
<seb128> and I don't know where it's looking for that one
<seb128> usually that happens when there is no debian/patches
<seb128> mkdir debian/patches and then debuild fixes it
<seb128> in that case there is a debian/patches with a series and 01_update-libtool.diff
<fabbione> Keybuk: i am going to grab a bit.. are you up for that UUID conversion in 30 minutes or so? i just need to know what packages to look at and how some stuff is done
<fabbione> bit/bite
* fabbione can't really survive on bits and bytes
<Keybuk> fabbione: 30 mins is too early, sorry
* Keybuk is really busy this morning
<fabbione> Keybuk: sure that's fine...
<Riddell> carlos_: still no progress on bug 46982?
<Ubugtu> Malone bug 46982 in rosetta "Need to support KDE like plural forms" [Critical,Confirmed]  https://launchpad.net/bugs/46982
<carlos_> Riddell: I'm finishing the bits required to implement that
<Riddell> carlos: ooh, cool
<Mithrandir> dholbach: hm, do you want universe to have a proper beta freeze too or should I just wave uploads to there through?
<dholbach> wave through
<Mithrandir> ok
* ..[topic/#ubuntu-devel:Mithrandir] : 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 beta
<dholbach> (as along as they don't hinder you)
<Mithrandir> nah, that's fine, I'll just ignore them.
<tepsipakki> so now it's frozen?
<tepsipakki> bah
<tepsipakki> :)
<Mithrandir> it is.
<Fujitsu> Hrm, the dbgsym packages don't seem to do epochs well. Like, they ignore them and thus fail to install.
<pitti> Fujitsu: pkg-create-dbgsym bug report appreciated
<Fujitsu> pitti: Shall do.
<ogra> Mithrandir, edubuntu is still behind with the artwork and will still need a bit (will be done before the meeting), is that ok with you ?
<Mithrandir> ogra: sure.
<ogra> thanks :)
<Fujitsu> pitti: Actually, it seems to not affect everything... libgcc1-dbgsym breaks, while others work...
<ogra> pitti, for future use, is there any way to make apport shut up temporary while i'm developing gui apps that frequently crash ? 
<pitti> ogra: it shouldn't trigger on non-packaged programs
<ogra> it can get quite annoying if yu search for a crasher :)
<ogra> well it was a packaged program :)
<pitti> oh, you do 'sudo vi /usr/bin/foo'?
<pitti> ogra: well, /etc/init.d/apport stop
<ogra> but we should have a gconf key or something for feisty+1
<cjwatson> Mithrandir: couple of oem-config fixes needed - last two patches on http://codebrowse.launchpad.net/~ubuntu-core-dev/oem-config/trunk/changes
<cjwatson> 268 and 269
<Mithrandir> cjwatson: looks good, go ahead
<ogra> pitti, do you already have the langpack list in ubuntu ? 
<ogra> (th efinal one)
<pitti> ogra: no, I'm going to shuffle the language priorities around a bit wrt. bug 67925
<Ubugtu> Malone bug 67925 in Ubuntu "Do not ship translations without matching input support" [High,In progress]  https://launchpad.net/bugs/67925
<pitti> ogra: I'll do that RSN (today)
<Mithrandir> pitti: I assume you already knew, but please merge that to derivatives too.
<ogra> pitti, ok, i want to have a look at the list to fill the edubuntu CDs 
<pitti> Mithrandir: of course
<Mithrandir> cjwatson: care to let my u-d-a post through, once it hits the queue?
<cjwatson> Mithrandir: done
<Mithrandir> thanks
<pitti> Mithrandir: I just promoted restricted-manager to main; is the publisher still on auto, so that this will take effect in the archive?
<Mithrandir> pitti: yes.
<Mithrandir> (and it'll most likely be on auto at least until after the weekend)
<pitti> ogra: do you want to manage the list of languages yourself for edubuntu?
<ogra> pitti, for the server and add-on CD at least ...
<pitti> Riddell: ^ same question; if not, can you please merge the kubuntu seeds to the ubuntu changes, so that I don't have trouble with mangling languages?
<ogra> the desktop one should be the same as ubuntus if possible 
<ogra> (wit langs dropped based on space)
<pitti> ogra: ok; if you want me to mangle it for you, can you please merge your seeds as well?
<ogra> pitti, i have some 100s of free megabytes ... 
<ogra> i could make a langpack CD out of my add-on CD i guess :)
<Riddell> pitti: merged
<pitti> Riddell: thanks
<ogra> pitti, hmm, i only see commits from Keybuk in bzr missing
<ogra> oh
<ogra> i should use ubuntu.feisty i guess :P
<ogra> instead of .edgy ...
<ogra> but seems Keybuk made the same mistake using the wrong release *g*
<Keybuk> ages ago
<ogra> yeah
<ogra> but thats a pattern if i'm already the second to make the same mistake... we should improve it .... ;)
<Keybuk> timestamp: Tue 2006-11-14 16:09:58 -0800
<Keybuk> message:
<Keybuk>   undo my changes to THE WRONG RELEASE
<pitti> too bad that there's no --seal in bzr :)
<ogra> yeah
<Keybuk> funny thing is I actually did that fresh
<Keybuk> checked out the edgy seeds, changed them, commitetd them
<ogra> heh
<Keybuk> and then only realised the next day that we were doing feisty now
<Keybuk> pitti: that'd be a technical solution to a human problem? :p
<Treenaks> pitti: there's chmod -w ;)
<pitti> Treenaks: not accessible on bazaar.lp.net
<pitti> Keybuk: well, just the same way as pedestrian pavement fences are to keep people from walking onto the road :)
<Treenaks> pitti: 'they can still do it, but it's more annoying'? :P
<pitti> Mithrandir, ogra, Riddell: FYI: http://people.ubuntu.com/~pitti/tmp/langpack-size.txt updated for current feisty packs, with new prioritization
<ogra> meh, lots of conflicts
<ogra> oh, we ship f-spot ? when was that added ? 
<pitti> ages ago
<ogra> do we have migration scripts to import the existing gthumb collections ? 
<pitti> ogra: NB that we didn't remove gthumb
<Fujitsu> Hasn't F-Spot been default since mid-Edgy?
<ogra> oh
<ogra> phew, thats a lot of languages on the desktop CD
<pitti> ogra: btw, we now also need to add the necessary input support if you ship languages that need it
<pitti> cjwatson: can I add a new file 'langpacks.txt' to the seeds without breaking something? I'd like to add some instructions and templates
<iwj> So has network-mangler ever worked properly with dialup ?
<heno> Mithrandir: are DVDs rsyncable? (or can they be set up to be?)
<Mithrandir> heno: yes, they are.
<heno> ok, thanks
<ogra> phew, that was a huge merge
<ogra> pitti, done ... waiting to see my livecd explode
<ogra> iwj, nope
<pitti> ogra, Riddell: I'll do this in two steps: (1) trim the langpack list to a small number to fix the current overflows, and (2) add more stuff tomorrow when I see how much space we actually have left; doing it in one step today is pretty hard due to the scim stuff
<ogra> yep
<iwj> ogra: IC.  And here I am wrestling with winmodems !
<Riddell> pitti: cool
<ogra> iwj, does it have an option to configure dialup stuff now ? 
<ogra> i'd expect to have to do it through network-admin 
<ogra> (just because it has this little phone icon, no idea how well that works, i got no modem around)
<pitti> joy. ppc/alternates are 28 MB oversized without having a single non-English langpack on them
<iwj> Yes, well, I configured the network setup in network-admin but the configuration doesn't work (even if I pppd call ppp0 from an xterm).
<Hobbsee> pitti: ouch...
<ogra> iwj, does it work with pppconfig ? 
<iwj> Haven't tried that yet.
<iwj> My goal is not just to get this thing to work; it's to make it so that random users who have no idea what they're doing can get it to work too.
<ogra> iwj, imho we should have pppoeconf and pppconfig integrated in the system-tools since quite some time, but nobody took the task to do that
<iwj> Right.  network-manager failed to put noauth in the peer spec file.
<ogra> usually both of these commandline tools do perfectly work right
<mjg59> pppconfig isn't really a good answer
<mjg59> iwj: network-manager or network-admin? (not putting noauth in)
<ogra> mjg59, but it usually works right
<iwj> mjg59: Err, (b) I mean.
<iwj> network-admin
<mjg59> Right
<cjwatson> pitti: random files that aren't in STRUCTURE should be no-ops
<mjg59> I've had success with network-admin in the past, but it may be broken now
<cjwatson> pitti: maybe a doc/ directory?
<pitti> cjwatson: sounds good
<iwj> mjg59: There's a comment in ppp/options suggesting that the default has changed to `auth'.
<mjg59> Oh, right. Sounds irritating.
<mjg59> Probably a trivial fix to network-admin, though
<BenC> Mithrandir: FYI, I have lrm, linux-meta and ldm to go with the -11 kernel I uploaded last night, and I also have to do another (non-ABI bump) kernel upload to fix two major bugs
<iwj> mjg59: Indeed.
<fabbione> BenC: i pushed a one liner for printk(KERN_ERR -> KERN_INFO
<pitti> Riddell: wow, you have heaps of space
<fabbione> BenC:  i couldn't stand anymore scsi_proc.c telling me that drivers are not support /proc interface anylonger
<BenC> fabbione: this morning?
<fabbione> yes
<BenC> ok
<BenC> fabbione: I'll pick it up when I sync, thanks
<fabbione> BenC: no problem. thanks to you
<fabbione> BenC: btw.. dm-multipath and OCFS2 in cluster mode are gold...
<fabbione> BenC: waiting only for local mount to be fixed..
<BenC> fabbione: nice
<fabbione> BenC: also qlogic 24xx is good
<BenC> fabbione: you have that hw?
<fabbione> BenC: i need to test the PCI-X versions but the PCI-E is goof
<fabbione> good
<BenC> fabbione: Excellent. So are you using it for rootfs?
<fabbione> BenC: yes i got 3 qlogic cards.. 1 PCI-E for Niagara and 2 PCI-X for whatever
<fabbione> BenC: not yet no...
<fabbione> BenC: i didn't have time to install the PCI-X in x86 hw
<Riddell> pitti: is that sarcasm?
<fabbione> BenC: and OBP doesn't really know how to scan on it.. does it?
<pitti> Riddell: it's not; most of your CDs have some 40 MB free
<BenC> fabbione: OBP wouldn't even know it was there other than it's a PCI device of some kind
<pitti> Riddell: however, you don't have any langpacks on them ATM already, so nothing to clean up for me
<pitti> Riddell: shall I fill them up to 695 MB for you tomorrow?
<fabbione> BenC: exactly :)
<Mithrandir> BenC: ok, go ahead.
<fabbione> BenC: but i will let you know once i get to install the hw.. i need to do more urgent stuff atm
<Riddell> pitti: sure, I only have space because there's no languages at the moment.  and ppc is overflowing (had to take off en-support), no idea why ppc is so large.
<Riddell> pitti: please do fill them up
<fabbione> Riddell: 2 kernels compared to 1 in other arches
<pitti> Riddell: oh, oops, I just added it again, thought that was a mistake
<pitti> Riddell: ubuntu ppc/alternates CDs are huge as well; no idea why either
<Riddell> pitti: actually ppc live does have 20Megs free, maybe language-support would fit
<Riddell> pitti: do you think it might be an idea to promote German on the Kubuntu CD above other languages?
<pitti> Riddell: new priority list is now 'en es xh pt de fr bn hi ar'...
<pitti> Riddell: i. e. first the languages which don't require special input support
<Riddell> xh doesn't require special input?
<pitti> Riddell: and as I said, I'm just removing all non-English langpacks from all CDs to have a clean slate for adding them tomorrwo
<pitti> Riddell: apparently not, it's just Latin characters from what I could see
<Riddell> there's no KDE translation in xh I'm sure
<iwj> Damn!  It has suddenly started working and I have no idea why.
<pitti> Riddell: right, almost nothing
<Seveas> Mithrandir, I have a patch for usplash-theme-ubuntu fixing the text color problem - I think ot would be a good thing to have in the beta :) Who should I poke to get it applied?
<BenC> Mithrandir: linux-meta, linux-restricted-modules-2.6.20 and linux-backports-modules-2.6.20 uploaded for -11 ABI
<Mithrandir> BenC: cheers.
<Mithrandir> Seveas: I'll be happy to review it.
<Seveas> Mithrandir, it's a very straightforward patch: http://paste.ubuntu-nl.org/10473/
<BenC> Mithrandir: thanks, I'll have new linux-source-2.6.20 uploaded tonight for you in the morning
<Seveas> just changing color values
<Mithrandir> BenC: cheers.
<Mithrandir> Seveas: hm, looks good, can you upload or should I?
<Seveas> Mithrandir, I can't but I just realised a stupid mistake. Fixed patch coming up in a minute
<Seveas> http://paste.ubuntu-nl.org/10474/ (first theme has only 16 colors)
<Seveas> if you could upload that, then a few usplash-theme-ubuntu bugs will be fixed :)
<Seveas> I'll check the kubuntu and xubuntu themes as well
<kwwii> Mithrandir: howdy, I just uploaded the last of the artwork changes for the beta for ubuntu and kubuntu...is there still time to include it?
<Mithrandir> kwwii: yes.
<Mithrandir> kwwii: which packages?
<Seveas> kwwii, heh, I'm just fixing the usplash themes :)
<kwwii> Mithrandir: kubuntu-default-settings, feisty-gdm-themes and feisty-session-splashes
<Mithrandir> kwwii: sure, will let them through.
<kwwii> Seveas: cool, what is the change?
<Seveas> kwwii, Mithrandir I'll have a patch for kubuntu-default-settings in a few minutes
<Seveas> kwwii, color indexes
<kwwii> Seveas: great :-)
<kwwii> Mithrandir: thanks
<pitti> Mithrandir: ok to upload a new language-support-lt with an added aspell-lt dependency? (I just promoted it to main, source and myspell-lt were already in main)
<Mithrandir> pitti: yes, go ahead
<Seveas> Mithrandir / kwwii - patch for kubuntu-default-settings: http://paste.ubuntu-nl.org/10476/
<pitti> Mithrandir: uploaded
<Riddell> Seveas: it fails to apply
<Seveas> Riddell, hmm I apt-get sourced minutes ago - maybe you have an older version?
<Riddell> Seveas: what version do you have?
<Seveas> 1:7.04-31
<Riddell> should be fine
<Riddell> Seveas: could you put the patch on a web server somewhere, the pastebin might be corrupting it
<Seveas> not if you grab http://paste.ubuntu-nl.org/10476/plain/
<Seveas> did you do patch -psomething? it's debdiff output :)
<jdong> pastebin, the world's best patch sharing mechanism :)
<jdong> Seveas: patch -psomething works fine for debdiffs ;-)
<Riddell> Seveas: like all pastebins that one has the habit of converting it to windows line endings
<Seveas> hmmz
* Seveas slaps self 
<Riddell> carlos: do you know why kopete translations have disappeared in feisty?
<jdong> Riddell: "Trailer trash" as we call it in the US ;-)
<Riddell> Seveas: or just put your usplash-theme-kubuntu.c file online somewhere
<Seveas> Riddell, http://www.kaarsemaker.net/files/usplashcolors-k.patch
<Seveas> Mithrandir, if you also have problems with the ubuntu usplash patch: http://www.kaarsemaker.net/files/usplashcolors.patch
<Riddell> Seveas: that did it
<Mithrandir> Seveas: it applied fine for me using emacs's diff mode, but not patch
<Seveas> stupid http/pastebin/firefox interaction
<Seveas> anyway, patch for ubuntu also coming up
<Seveas> xubuntu*
<jdong> emacs has a _diff_ mode???
<Mithrandir> jdong: of course.
<jdong> does it have a "scratch my back" mode too?
<jdong> cuz there's this spot I can't reach.
<Mithrandir> not that I know of.  I have a wife for reaching those bits of my back.
<jdong> :)
<Mithrandir> (I have her for other reasons too, but it's a nice bonus)
<jdong> I've noticed some students around here checking their e-mail with emacs.....
<Hobbsee> heh
<Hobbsee> Mithrandir: careful...she might read that :P 
<jdong> or spending extended periods of time talking to Doctor.
<Mithrandir> jdong: yes, I use gnus too.  It's a wonderful client.
<Mithrandir> Hobbsee: given she's in the channel, she might very well.
<Riddell> carlos: the kopete issue is that the source packages has changed from kopete to kdenetwork, is it possible to fix that in rosetta?
<pitti> Mithrandir: new ubuntu-meta uploaded (addition of restricted-manager)
<Riddell> pitti: restiricted-manager killed my X!
<pitti> Riddell: how so?
<Riddell> pitti: see bugs reported, I seem to have a monopoly on restricted-manager bugs just now
<pitti> Riddell: can you please file a bug report with the details? (new xorg.conf, how it should have looked like, lspci)
<pitti> Riddell: ah, ok, thanks
<pitti> Riddell: It got the bug list down to zero this morning
<jdong> Riddell: ha I held that title a few days back :)
* pitti -> back in 10 minutes
<pitti> jdong: yes, but I succeeded in fighting you back :)
<jdong> pitti: speaking of that, any idea on the BusID issue and when it'll get fixed? :)
<jdong> It changed the driver from ati to fglrx. It also changed the busid from PCI:1:5:0 to PCI:0:5:0.
<jdong> *cough* pitti *cough*
<pitti> jdong: no idea where that came from in the first place; did you configure this manually?
<jdong> :)
<jdong> pitti: no, RM definitely does it
<Riddell> I confirm
<jdong> pitti: the BusID is correct before running it, and magically it chanes to 0:5:0
<jdong> I have no idea where 0:5:0 comes from
<pitti> jdong: if you do sudo dpkg-reconfigure xserver-xorg, do you get the same?
<jdong> pitti: not sure.... ask Riddell :D
* jdong needs working laptop for class today :)
<jdong> but so far we have 3 reports of that
<pitti> Riddell: if you do sudo dpkg-reconfigure xserver-xorg, do you get the same?
<pitti> r-m just sets the debconf values for driver and calls dexconf, nothing else
<Riddell> pitti: nope, it finds 1:5:0
<pitti> Riddell: with fglrx?
<pitti> oh, and it enables the glx module, but that can hardly be the cause as well
<jdong> pitti: yeah I looked thru the code and saw nothing that could screw up BusID....
<Riddell> pitti: yes, fglrx defaults to 1:5:0, but r-m changed it to 0:5:0
<jdong> but nonehteless it happens consistently
<pitti> Riddell: I need lspci for bug 92485
<Ubugtu> Malone bug 92485 in restricted-manager "no drivers listed, enable button broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92485
* pitti -> really away now, back in 10
<jdong> is it just me or is LP really slow today?
<jdong> Riddell: bug 92498 probably dupe-of bug #91036
<Ubugtu> Malone bug 92498 in restricted-manager "breaks X for ati radeon 330m/340m/350m (rs200 IGP)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92498
<Ubugtu> Malone bug 91036 in xorg "restricted-manager picks wrong BusID for video cards" [Undecided,Confirmed]  https://launchpad.net/bugs/91036
<jdong> that makes 3 reports: 2 fglrx 1 nvidia, busid 0:5:0
* jdong -> class
<Riddell> jdong: there's also the main bug which is that it changes it to fglrx which doesn't work with my video card
<mvo> pitti: if I enable fglrx, should it rewrite my xorg.conf? and if it didn't, what can I do to debug the issue?
<jdong> Riddell: interesting... so apparently pitti's detection for supported cards is incorrect too :)
* mvo restarts X
<bddebian> Heya
<carlos> Riddell: yeah, I will take a look to fix kopete, I saw there was something weird there, but I hadn't time to check it with you. Thanks for your input
<pitti> Riddell: I don't understand that as well, we have several different issues here: (1) your ATI card isn't actually supported by fglrx? (2) was or wasn't it displayed in the list? (3) if it wasn't dispayed, how did you enable it?
<mvo> pitti: anything you needfor bug 92524? if not, I will fix xorg.conf by hand now
<Ubugtu> Malone bug 92524 in restricted-manager "Breaks X when disabling fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92524
<pitti> wb mvo
<pitti> mvo: yes, enabling fglrx should change the driver in xorg.conf
<Riddell> pitti: it isn't supported (from what I've read), it was displayed in the r-m list, enabling it broke my X
<mvo> pitti: anything I can do to help diagnose why it didn't? does r-m keep a log somewhere or something?
<pitti> Riddell: ... 'there are no drivers listed.'
<pitti> Riddell: and fixing the PCI ID doesn't help?
<Riddell> fixing the PCI ID didn't help no
<Riddell> pitti: they are two different bugs from two different machines
<pitti> Riddell: ah, I see
<Mithrandir> Riddell: digikamimageplugins > are those just a split-out from digikam or a whole new source package?
<Riddell> Mithrandir: new source package
<Mithrandir> Riddell: ok.
<pitti> mvo: /var/cache/debconf/config.dat would be helpful 
<Mithrandir> (I didn't see the MIR before now)
<mvo> pitti: the complete thing? or just the bits about X?
<pitti> mvo: the xorg bits are enough, of course
<pitti> mvo: oh, is /var/cache/restricted-manager/fglrx.olddriver == 'fglrx'?
<pitti> mvo: that would indeed explain it
<Mithrandir> Keybuk: you seeded git-email ages ago; it needs a few MIRs to be useful.  Are you going to do those or should I remove it from supported?
<mvo> pitti: no, there is no flglrx file in that dir (after i rebootet at least)
<pitti> Riddell: so bug 92498 was the one with the card that is not supported by the fglrx driver?
<Ubugtu> Malone bug 92498 in restricted-manager "breaks X for ati radeon 330m/340m/350m (rs200 IGP)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92498
<Riddell> pitti: yes
<pitti> mvo: ah, right, it's removed after you disable the driver
<pitti> mvo: I have an idea how this could have happened, though
<pitti> mvo: you manually edited xorg.conf to use fglrx before, and debconf still had 'ati'?
<pitti> erm, no, that doesn't work
<mvo> pitti: that is very possible
<mvo> pitti: I edited xorg.conf for some modifications (e.g. scrolling with the trackpoint etc)
<mvo> pitti: I probably set the driver then to fglrx too 
<pitti> mvo: ok, I think I know how to make it more robust against that
<mvo> pitti: ok, cool
<mvo> pitti: there is this other issue that my video card seem to not work with vesa, so my only option is fglrx (X1400) - but that is a seperate problem
<pitti> mvo: neither with ati?
<pitti> mvo: how do you install that system in the first place?
<mvo> pitti: no, no way with ati
<pitti> vga??
<mvo> pitti: I think it was vesa, but it seems the feisty vesa does not work anymore, but I will investigate a bit more
<mvo> pitti: but the more recent mobile ati cards do not have support from the "ati" driver (not even for 2d)
<pitti> Riddell: in bug 92485, was it correct that there are no drivers displayed?
<Ubugtu> Malone bug 92485 in restricted-manager "no drivers listed, enable button broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92485
<Mithrandir> pitti: you need to write a MIR for notify-python:
<_ion> pitti: Seems like there isn't any hardware with restricted drivers in the lspci listing, http://librarian.launchpad.net/6823780/lspci
<pitti> Mithrandir: argh, that one
<Riddell> pitti: how do you mean correct?  I don't know enough but what drivers we have to say if some should have been listed but it's an amd64 without nvidia or ati video card
<mvo> pitti: sorry, false alarm, vesa works, was probably just a unclean state of the gfxcard or something
<Keybuk> Mithrandir: ? it didn't need anything at the time
<pitti> Riddell: ah, that sounds about right then, unless you have an ipw3945 wifi or a ISDN card
<Keybuk> Mithrandir: nothing to do with me, I was just doing MIR/anastacia I expect
<mvo> pitti: so disabling should rewrite it to vesa, ati does definitely not work
<pitti> mvo: it sets it back to whatever it was before you enabled it
<pitti> mvo: i. e. what the debconf value was
<Mithrandir> Keybuk: hm, ok.  I'll just remove it again, then.
<mvo> pitti: aha, ok. that will work :)
<pitti> mvo: however, if the 'previous' driver is already fglrx, then I better consider it as enabled already
<mvo> pitti: *nod*
<pitti> mvo: hm, it does already
<pitti> mvo: is_enabled = return driver == "fglrx" and self.package_installed(self.driver_package)
<pitti> mvo: i. e. it would have been shown as disabled when you had debconf configured as fglrx, but the xorg-driver-fglrx package wasn't installed
<pitti> _ion: which bug is that from?
<_ion> pitti: The one you asked Riddell about.
<pitti> _ion: no, that was http://librarian.launchpad.net/6823789/lspci
<pitti> _ion: oh, nevermind me; that was the other bug
<_ion> pitti: Uh, interesting. I get the link i pasted instead of that. I'm using launchpad beta, are you?
<_ion> Alright.
<pitti> _ion: any idea about bug 92498? 
<Ubugtu> Malone bug 92498 in restricted-manager "breaks X for ati radeon 330m/340m/350m (rs200 IGP)" [Undecided,Confirmed]  https://launchpad.net/bugs/92498
<pitti> _ion: does that mean the fglrx module claims to support a device which it doesn't work with?
<mjg59> It sounds more like it's just a bug
<mjg59> Oh, actually, maybe not
<_ion> pitti: fglrx itself doesn't claim to support any hardware, so i just added to modalias.append:
<mjg59> rs200 IGP is not the same as IGP200M
<_ion> alias pci:v00001002d*sv*sd*bc03sc00i* fglrx
<_ion> That is, "all VGA controllers by ATI".
<_ion> That should be fixed by finding an accurate list of devices supported by the driver.
<pitti> _ion: oh, dear
<_ion> Just like i did with the nvidia driver.
<_ion> I did take a quick look at the ATI site and the files in the fglrx driver "source", but didn't find such a list. I didn't look very hard.
<pitti> mvo: that config.dat was the one *after* disabling the driver? it says ati
<mvo> pitti: let me re-check
<Mithrandir> Riddell: is the kdenetwork upload done by Tonio_ ok with you?  "Removed kubuntu_04_kopete_style_contacts.diff, closes Malone #90020" is the changelog entry
<Ubugtu> Malone bug 90020 in kdenetwork "Kopete should not use a patched contact list by default" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90020
<Riddell> Mithrandir: yes, please let that through
<Riddell> Mithrandir: I also uploaded a kdebase earlier with a compile fix
<mvo> pitti: sorry, wrong file. I corrected it, the driver is vesa
<pitti> mvo: that keeps it mysterious, though
<Mithrandir> Riddell: accepted.
<pitti> mvo: so you disabled fglrx, and ended up with 'vesa' in debconf, and fglrx in xorg.conf?
<mvo> pitti: correct
<pitti> mvo: that's even more inexplicable then; r-m reads the old driver from fglrx.olddriver, sets debconf driver to it, and then calls dexconf
<pitti> mvo: 'dexconf -o /tmp/xorg.conf' has vesa then?
<pitti> Riddell: what is 'grep -A 2 'xserver-xorg/config/device/bus_id$' /var/cache/debconf/config.dat' on the machine with the broken BusID?
<mvo> pitti: yes
<pitti> mvo: if you enable and disable it in r-m, do you still have the issue? is the file changed at all?
<mvo> pitti: this is all a bit mysterious. it seems that when I clicked disable this time it wrote a complete new xorg.conf overwriting my old changes. this is really not what I want as i e.g. customized the scrolling behaviour of the trackpoint
<mvo> pitti: but it set the (correct) vesa driver
<pitti> mvo: right, as I said, it just uses dexconf
<pitti> mvo: it back up all previous xorg.conf's at least
<mvo> pitti: and enabling it gives me the correct fglrx driver now
<ogra> pitti, why not xserver-xorg's postinst like we do in the liveCD and ltsp ? 
<mvo> pitti: maybe we could add a warning or something that customization gets lost?
<ogra> that should preseed some settings before running dexconf ... so its less likely you break existing configs
<pitti> ogra: I don't know; I just started looking at all of this mess a few days ago
<Seveas> Mithrandir, http://www.kaarsemaker.net/files/usplashcolors-x.patch http://www.kaarsemaker.net/files/usplashcolors-e.patch - patches for xubuntu-artwork and edubuntu-artwork. The edubuntu one also fixes a broken pulsating progressbar
<pitti> ogra: the postinst doesn't use dexconf? why do we have that then?
<mvo> pitti: desktop-effects does not work with ati, correct? I just get a mesage about composition not enabled
<ogra> pitti, the postinst uses dexconf after setting preseed values
<pitti> mvo: right
<mvo> thanks
<pitti> ogra: so these should already be in debconf db, no?
<ogra> there is a lot of hardcoded stuff as well as debconf values that get preseeded
<pitti> mvo: desktop-effects will not offer to install fgrlx, just nvidia
<ogra> pitti, right
<ogra> but using that seems less likely to break existing stuff
<ogra> indeed it doesnt guarantee that manually tweaked configs stay as they are
<ogra> but at least the debconf values should be safe
<cjwatson> Mithrandir: whoa. I just reproduced one of the major remaining causes of ubiquity crashes, I think
<cjwatson> Mithrandir: how does http://paste.ubuntu-nl.org/10489/ grab you?
<cjwatson> Mithrandir: I'm still working on proving that flock() returning EINTR was what caused it to crash for me, but it makes a lot of sense
<pitti> Chipzz: http://trac.galago-project.org/ticket/121 was an Ubuntu specific bug that has recently been fixed, btw
<pitti> Mithrandir: https://wiki.ubuntu.com/MainInclusionReportNotifyPython
<pitti> Mithrandir: I'll promote it 
<pitti> ogra: you mean 'DEBIAN_FRONTEND=noninteractive sudo dpkg-reconfigure xserver-xorg' would be better than calling dexconf directly?
<ogra> pitti, i think so ... 
<ogra> im not aware that we use plain dexconf anywhere in the distro
<pitti> Keybuk: do you still remember why you call dexconf directly instead of dpkg-reconfigure xserver-xorg?
<pitti> Keybuk: (in restricted-manager)
<Keybuk> pitti: because the latter outputs a whole bunch of stuff to stdout, and maybe asks debconf questions, etc.
<pitti> Keybuk: with DEBIAN_FRONTEND=noninteractive?
<ogra> Keybuk, you can quiten it
<tepsipakki> or -phigh
<pitti> it doesn't ask me anything with noninteractive, but that might just be me
<Keybuk> pitti: it outputs stuff about md5sums changing
<pitti> Keybuk: right; but *shrug*
<Keybuk> and if they modified their xorg.conf, it does nothing
<Keybuk> which would require more work from r-m :p
<pitti> it happily clobbers my customized version
<Keybuk> :D
<Keybuk> I preferred that behaviour
<Keybuk> I changed my X driver and my xorg.conf changed bugs => explainable
<pitti> so after all it could be better to call that
<Keybuk> I changed my X driver and nothing happened => harder to debug <g>
<ogra> pitti, see configure_x http://people.ubuntu.com/~ogra/ltsp-client.ltsp-client-setup.init
* Keybuk didn't write Restricted Manager anyway
<Keybuk> it was a different Keybuk
<pitti> Keybuk: I can set stderr/out to subprocess.PIPE to quieten it, if that md5sum stuff annoys you
<Keybuk> a lazier Keybuk
<Keybuk> with 500 other annoying things that needed to be done that week too
<Keybuk> <g>
<pitti> Keybuk: ok, thanks
* mvo_ just lost his network while upgrading network-manager
* ogra hands mvo_ a cable ... 
<ogra> for a new start :)
<mvo_> ogra: haha
<mvo_> ogra: seriously, I'm not impressed
<ogra> plant it in a pot and give it enough water :)
<ogra> mvo_, static device ? 
<mvo_> ogra: wireless network
<ogra> ah
<ogra> didnt happen to me yet ... wireless seems stable ... the only issues i had so far was NM shutting down my static server interface when starting wlan ...
<mvo_> ogra: pretty nice as well :)
<ogra> which meant being without dhcp and dns for my whole network as soon as i logged into my lappie
<ogra> but that didnt happe since some time ... i assume its fixed
<mvo_> *nod* 
<mvo_> I did a big update today and while that was in progress the thing vanished and with it my network
<ogra> evil
<mvo_> ogra: yep
* mvo_ goes back to fixing bugs
<Keybuk> mvo_: something crashed maybe?
<Keybuk> it tends to be gnome-power-manager that breaks for me on upgrades
<mvo_> Keybuk: interessting, let me check
<mjg59> Keybuk: Any chance you can look at 82680?
<mjg59> The driver looks like it should be sending out events when the user inserts an SD card
<mjg59> But udev doesn't seem to do anything with them
<Keybuk> that's marked fix released?
* mjg59 shrugs
<mjg59> That seems incorrect
<Keybuk> I almost certainly don't have time, I'm afraid; and certainly don't have the hardware
<Keybuk> try one of the kernel team
<mjg59> Well, it doesn't appear to be a kernel issue
<mjg59> The event is generated - udev does nothing useful with it
<Keybuk> what should udev do with it?
<mjg59> Load tifm_sd
<Keybuk> tifm_sd has no aliases
<Keybuk> so it won't be automatically loaded
<mjg59> What sort of aliases should it have?
<Keybuk> it either needs some kind of subsystem:wildcard alias which matches devices exposed from sysfs
<Keybuk> or udev needs something added to 90-modprobe.rules to load it for a particular event
<mjg59> Ok
<mjg59> I'll figure out exactly what's being exposed and get back to you
<kylem> mjg59, related to: https://bugs.beta.launchpad.net/ubuntu/+source/udev/+bug/65042?
<Ubugtu> Malone bug 65042 in udev "SD/MMC Card Reader not working (worked in Dapper) - not all modules loaded" [Undecided,Confirmed]  
<mjg59> Yeah
<mjg59> Dupe
<Keybuk> generally speaking
<Keybuk> udev automatically loads a module if the module exports an alias, and the device exports a MODALIAS string
<Keybuk> and they fnmatch
<Keybuk> we also have a bunch of manual loading rules for "this type of device and this module" for where a modalias isn't possible/feasible/easy
<Keybuk> e.g. we have one that looks in /proc/ide for the device type and loads the appropriate ide module
<Keybuk> because it's easier than dealing with the ide subsytem maintainer, or patching the ide subsystem :p
<Riddell> pitti: your r-m .deb seems to fix the PCI issue for me
<pitti> Riddell: yay
<pitti> Riddell: I'll wait for jdong's confirmation as well
<pitti> Riddell: thanks for testing
<ogra> pitti, i can test as soon as i'm done with the edubuntu-artwork package (around meeting time)
<pitti> ogra: that would be nice
<pitti> ogra: new deb is attached to bug 91036
<Ubugtu> Malone bug 91036 in xorg "restricted-manager picks wrong BusID for video cards" [High,Needs info]  https://launchpad.net/bugs/91036
<ogra> but my card doesnt do any compiz stuff i can only test if fglrx is used
<pitti> ogra: right, that should be fine
<czester> Hello. Anyone familiar to suspend feature?
<czester> I need ubuntu not to lock screen after suspend/resume
<czester> Is this possible? I use KDE
<jrib> czester: this channel isn't really for support
<czester> Yes, I know that
<jrib> yet you ask a support question :)
<czester> I want to turn off screen locking after suspend
<czester> tried /etc/default/acpi-support but it doesn't work
<jrib> czester: you are more likely to get help in #ubuntu is what I am telling you
<czester> There is more that 1k people 
<dholbach> Mithrandir: can you give back gnome-games?
<czester> ;-)
<LaserJock> czester: actually, you'd want #kubuntu
<czester> I'm there 
<LaserJock> czester: that is one of the few things where I know Gnome has a conf setting for it but haven't seen a KDE one for it
<LaserJock> czester: but I'm sure it *has* to be somewhere
<czester> Yes, I sure about that too ;-) 
<czester> Or maybe I just *damage* kde locking app ;DD
<czester> It should work ;-)
<jrib> heh, that would be one way
<czester> I have a clue
<czester> dcop kdesktop KScreensaverIface
<czester> I've installed ubuntu after 3 years of using gentoo ;-)
<czester> Everything seems to be so nice and easy ;-)
<ogra> ugh
<ogra> what replaces usplash-dev ? 
<cjwatson> libusplash-dev
<ogra> thanks
<ogra> Seveas, you changed colors in usplash ? 
<Seveas> ogra, the hex values were bogus (and out-of-pallette-range in many cases) and copied from bogus values in the usplash theme
<ogra> so what do i need to do for edubuntu ? 
<Seveas> ogra, I prepared an edubuntu patch as well
<ogra> where ? 
<Seveas> (which also fixes a broken progressbar)
<Seveas> Mithrandir, http://www.kaarsemaker.net/files/usplashcolors-x.patch http://www.kaarsemaker.net/files/usplashcolors-e.patch - patches for xubuntu-artwork and edubuntu-artwork. The edubuntu one also fixes a broken pulsating progressbar
<Seveas> (there)
<ogra> our current progressbar is fine ...
<Riddell> czester: untick the tickbox in guidance-power-manager in feisty
<ogra> whats broken there ? 
<Seveas> ogra, the pulsating part was busted
<ogra> ah, right ... that piece on the liveCD i always ignore :P
<Seveas> covered only roughly 2/3 of the bar
<Seveas> for feisty+1 I hope to redo some drawing code and remove the flicker
<czester> Riddell: I use edgy.
<Seveas> planned that for feisty, but time didn't permit me to do so
<czester> Riddell: Besides: This is not a laptop, quitting ...
<ogra> Seveas, you wouldnt belive how much i *planned* for feisty ... 
<Seveas> ogra, heh :)
<ogra> but i ended up with only three of 8 specs implemented :(
<ogra> my worst release evar
<Seveas> ouch
<ogra> well, next time will get better and i hopefully will have someone to share some work on edubuntu by then 
<ogra> finally
<czester> Bye
<ogra> Err http://archive.ubuntu.com feisty/main yelp 2.16.2-1ubuntu8                                                                                
<ogra>   404 Not Found [IP: 91.189.89.6 80] 
<ogra> how weird ... why does my -artwork package try to get yelp 2.16 ? 
<ogra> there is no dep or something
<mvo_> pitti: what is the name of the apport qt/kde frontend package?
<pitti> mvo_: apport-qt
<pitti> (I know, hideously misnamed :) )
<mvo_> pitti: heh :) something eat my /var/lib/apt/lists/ (probably me) that is why apt-cache did not found it. but thanks for bearing with such obvious questions
* pitti hugs mvo_, kein Problem
* mvo_ hugs pitti back
<cjwatson> Mithrandir: can I upload the changes in http://codebrowse.launchpad.net/~ubuntu-core-dev/ubiquity/trunk/changes from r1947?
<ogra> grmbl ...
* ogra deletes five of his ltsp chroots to not always run out of diskspace
<bdmurray> pitti: I 'm getting a memory error with apport retrace on one firefox bug in particular
<ogra> pitti, did you already use 2.6.20-10-powerpc ? i just heard its not booting ...
<ogra> (didnt try myself yet)
<pitti> ogra: no, didn't try it yet
<pitti> bdmurray: get more memory then :)
* pitti -> back to cooking dinner
<bdmurray> heh
<gnomefreak> bdmurray: what bug#?
<bdmurray> pitti: checking
<bdmurray> 88035 I believe
<gnomefreak> ty
<gnomefreak> ick another 64bit
<gnomefreak> i assigned it to asac for now incase you cant get it
<bdmurray> gnomefreak: apport-retrace just dies on me when I try to retrace that bug
<gnomefreak> no warnings?
<bdmurray> I believe it complained about being out of memory in the gzip python module
<gnomefreak> thats a new errror/warning for me
<gnomefreak> i cant do 64bit retraces yet
<gnomefreak> i have one or two i can play with to see if i get it. maybe ill try the 64bit one anyway just to see if i get it
<dholbach> Mithrandir: please wave through the gnome-phone-manager/gnome-bluetooth uploads - that way we can drop libopenobex1 (and use libopenobex everywhere instead)
<czester> One of the operators on #ubuntu is abusing users
<czester> ;-)
<czester> PriceChild: 
<czester> He banned user just because he's from poland
<czester> And there is ban on #ubuntu for 90% of polish users
<czester> Why?
<dholbach> czester: better to ask PriceChild than in this channel
<czester> *!*@*.neoplus.adsl.tpnet.pl affects massive number of polish users
<czester> dholbach: I did, he banned me
<dholbach> i think there is #ubuntu-ops
<czester> Well I belive he has some power there too.
<gnomefreak> there is
<czester> jacekowski did nothink and he was banned
<dholbach> that's more appropriate there
<dholbach> please move to #ubuntu-ops
<PriceChild> czester, #ubuntu-ops please
<czester> ok
<ogra> seeeeb !
<ogra> grmbl
<PriceChild> Sorry about those two users spilling over into this channel.
<ogra> dholbach, any idea why gdm allows you to kill yourself with /etc/init.d/gdm restart ? it used to queue that until logout
<dholbach> ogra: I don't think it ever did that
* ogra just trashed his work of the last hours
<dholbach> I can't remember a time, when that was the behaviour
<ogra> dholbach, it used to say something "not restarting gdm, waiting until all sessions ended"
<ogra> or similar
<dholbach> no, that's just when you update the package
<ogra> meh 
<dholbach> or update language-packs
<ogra> right 
* ogra shouldnt do serious work with only 2h of sleep ... but then artwork is no serious work :P
<tepsipakki> ogra: thats 'reload' ;)
<ogra> tepsipakki, argh, silly me indeed !
<tepsipakki> hehe
<Moniker42> hey, i was wondering if anyone else has been getting this bug
<Moniker42> firefox doesn't seem to be displaying the ubuntu homepage right
<Moniker42> it's just this bright orange messy thing, nothing like the nice clean thing i was on yesterday...
<Moniker42> so has anyone else been experiencing this bug?
<Keybuk> Moniker42: the home page just changed; try holding down shift and click reload
<Seiya> Moniker42:Displays properly for me.
<Moniker42> it's still horrible and orange
<tepsipakki> oooh, shiny new page
<Seiya> Does is display correctly in any other browsers you have access to?
<Moniker42> hmph.... thinly veiled dig at the new website
<Moniker42> i'm obviously being too subtle ;)
<Moniker42> it's a horrible shade of orange... and the navigation makes even less sense than the old site
<Moniker42> which was a little weird but decent.
<ogra> its darn slow here 
<Seiya> Ahh. I missed this. My english is not perfect. :)
<Moniker42> Seiya, no problem lol, you could have pretended you knew all along and were just playing along ;)
<Seiya> Heh
<Moniker42> i think i'm defending my position on the website fairly well...
<Moniker42> <adamant1988> I have to say.. the new design is a LOT more friendly than the last one
<Moniker42> <Moniker42> it is? i'd say it's a LOT more colour-blind friendly.
<Moniker42> <Moniker42> i.e. people that can't see anything but particularly bright shades of orange.
<asac> pitti: is ppc retracing on davis known to be broken?
<pitti> asac: well, not really, but I should really upgrade it to the latest infrastructure
<asac> pitti: hmmm i get some dpkg errors when running
<asac> pitti: and of course no useful results ... no matter what bug
<asac> pitti: http://paste.ubuntu-nl.org/10509/
<asac> thats in between of WARNING: ...
<asac> pitti: here with a bit more context: http://paste.ubuntu-nl.org/10510/
<pitti> asac: whoops
<pitti> asac: let me just tear this down and set up a fresh one
<pitti> asac: the ones on ronne work pretty good now
<asac> pitti: please :)
<asac> pitti: if i need to rm -rf something, let me know :)
<pitti> asac: no, rm -rf worked fine
* pitti sets up the new stuff
<BenC> pitti: Are you on archive NEW duty today?
<pitti> BenC: tomorrow, but if you quickly need something, I can do it right now
<pitti> BenC: shall I wave through the new kernels?
<BenC> pitti: I need latest linux-source-2.6.20 processed...it's built
<BenC> pitti: yes, please :)
<pitti> Mithrandir: ^ just checking, ok to get 2.6.20-11 into feisty right now?
<ogra> please !
<ogra> it will fix my broadcom 
<pitti> asac: done
<BenC> pitti: He already approved it, and the lrm/linux-meta behind it
<pitti> asac: hmm, 3:30 minutes to setup a complete retracing environment from scratch ;)
<pitti> BenC: alright
<asac> pitti: well done
<pitti> asac: please don't redirect stdin any more
<BenC> pitti: thanks very much
<pitti> asac: it will now display the traces, ask for confirmation, and attach them back to the bug
<BenC> I need to get out a -11.19 with two important fixes, but I need abi/module listings from the current build
<asac> pitti: ok ... lets try this innovation :)
<pitti> asac: please, I didn't test the new instance yet
<pitti> BenC: done; too bad that we just missed a cron.daily
<asac> pitti: i am fine to be the front
<pitti> asac: I'm standing by with my shell and vi arsenal to fix things up behind you :)
<asac> ;)
<asac> thats why its so slow :) ... its pitti-driven :)
<pitti> asac: but according to ps aux things grind away happily ATM
<pitti> asac: *cough*
<pitti> asac: I have some ideas how to speed it up, but that requires some heavy code and time
<pitti> it's rough, but it kind of works at least
<asac> pitti: no thats no problem
<pitti> asac: hm, processes finished - that was a bit too quick?
<asac> maybe ... a semi-good-backtrace
<pitti> oh, so it worked?
<asac> it has: Backtrace stopped: frame did not save the PC
<asac> but some symbols came out of it
<asac> yes ... so probably worked
<pitti> asac: hmm
<asac> we often get that
<pitti> asac: did you see version mismatches?
<asac> WARNING: ... ?
<pitti> asac: and did the confirmation/bug attaching work?
<asac> let me see
<asac> i was asked to
<asac> did answer y
<asac> so
<pitti> asac: yes, those; 'bug needs version 1, but version 2 is available'
<asac> yeah attaching worked:
<asac> http://librarian.launchpad.net/6836565/%3Cfdopen%3E
<pitti> asac: hm, maybe it helps to build ffox with -fno-omit-frame-pointer or so?
<pitti> asac: ouch, I should fix the attachment file names :)
<asac> hehe
<asac> pitti: http://paste.ubuntu-nl.org/10512/
<asac> this is some output
<asac> but i have never seen a retrace go through without such warnings
<pitti> asac: well, that doesn't look too bad?
<asac> the trace or the warnings?
<Adri2000> pitti: http://people.ubuntu.com/~pitti/ddebs/pool/main/t/tk8.4/ any reason for that -0ubuntu2 ddebs are only powerpc and sparc?
<pitti> asac: trace
<pitti> Adri2000: ugh, no, I don't
<pitti> Adri2000: if these were built in the last 7 days, I might be able to recover them
<asac> pitti: some are worse ... but I saw traces with this frame pointer warning which looked pretty different when properly retraced.
<pitti> asac: '/usr/lib/libbonobo-2.so.0.0.0 was loaded at runtime, but is not available'
<pitti> asac: ^ for those I already have an idea
<asac> maybe fno-omit-frame-pointer might help though
<Adri2000> pitti: 7 Jan 2007 :/
<pitti> asac: if/when we have a reasonably up-to-date Contents.gz, I could use that to find the matching packages and install them
<asac> yes
<pitti> asac: those refer to libraries which appear in /proc/pid/maps, but aren't covered by dependencies
<asac> does it work practically?
<pitti> asac: usually plugins loaded at runtime and such
<pitti> asac: I'm not sure whether we keep Contents.gz up to date; we didnt' build it in the past, but that might have changed
<pitti> asac: if we do, then it's a SMOP from my side
<pochu> Adri2000: debugging amsn? ;)
<pitti> asac: I have tons of ideas how to make this stuff work better, but it's not on my current official assignment list, so I can't spend to much time on it
<Adri2000> pochu: yep, trying :p
<asac> pitti: sure
<asac>  pitti anyway can we keep old versions of dbgsym packages at least?
<pitti> asac: for 14 days now
<pitti> asac: however, it just comes into my mind that they won't appear in Packages.gz, so apt-get won't be able to install them (and apport-retrace doesn't try either)
<asac> pitti: i do most crash work in feisty and asking to reproduce is not an option as most are not easily reproducible :)
<pitti> so older traces have to be retraced with manual love
<asac> pitti: how? is there a thing like "feisty archive" where i can find old sources>?
<pitti> asac: my current project is an automatic retracing service, that should help a bit against outdated bugs
<asac> pitti: yeah :)
<pitti> asac: no, only from the ddebs, not from the archive debs
<asac> pitti: so how can you retrace them with manual love :)
<pitti> asac: if you have the old debs, dpkg -i the matching ddebs
<asac> yeah ... ok :)
<pitti> but it's a PITA
<asac> first you need the debs
<asac> second you won't have debug symbols without sources :/
<pitti> you don't need the matching sources
<pitti> just the debs
<asac> you mean the -dbg.deb files?
<pitti> -dbgsym.ddeb
<pitti> and the actual package .debs
<asac> sure ... ok
<asac> i assumed that the -dbgsym packages are gone
<pitti> asac: those are kept for 14 days after a new version appears
<pitti> but they aren't actually useful ATM
<pitti> needs more code .... needs even more code ...
<asac> yes i see :)
<asac> hope it will be automatic soon ... then such things should disappear
<asac> of course not, if user is not up-to-date
<pitti> dholbach: if I want to add something to p-lp-bugs (such as tag editing), should I rather branch from bughelper.main or bughelper.0.1?
<pitti> asac: right, we can't handle old user installations
<dholbach> .main is 0.2 -> feisty+1
<pitti> asac: but for stables that shouldn't matter so much, and for feisty we can just say 'upgrade to latest packages'
<dholbach> pitti: ^
<pitti> dholbach: read it, thanks
* dholbach hugs pitti
<pitti> asac: i. e. for a ffox crash, if ffox itself is outdated, we can just ask the user to upgrade
<asac> pitti: yes ... the shame is that i need lots of traces
<pitti> asac: and if just some gtk library is out of date for a ffox crash, it shouldn't make the traceback much worse
<asac> pitti: and users won't be able to reproduce
<asac> so at best i could retrace every crash report.
<asac> but as you said ... once automatic reports are there, old reports will only come for a few days ... so no problem for ffox
<asac> actually pretty happy to have crash reports at all :)
<_ion> http://librarian.launchpad.net/6836446/vte_0.16.0-0ubuntu3.debdiff seems to fix bug #89524, whee.
<Ubugtu> Malone bug 89524 in vte "[apport]  GNOME Terminal Unicode SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/89524
<pitti> right, I think it came a long way compared to what we had in dapper
<asac> gives me a damn good understanding of stability ... and what crashes happen how often
<tsmithe> pitti, could i poke you about a couple of NEW packages for your duty tomorrow? (i'm sorry to pester)
<pitti> tsmithe: I'll do all binary NEWs, and some source NEWs in FIFO order
<tsmithe> excellent
<tsmithe> thanks :)
<pitti> tsmithe: anything that's particularly feisty/beta important/
<tsmithe> (these are source NEWs)
<pitti> ?
<tsmithe> yea - wired and enblend
<tsmithe> i've spoken to seb128, but he said he wanted another ack/someone else to do the processing
* ogra is going mad .... 4th attempt to uplaod edubuntu-artwork (6MB) the last three i stopped after 20-30min ...
<dholbach> ogra: upload it to chinstrap (maybe with trickle and an upstream limitation) and from there to upload.u.c
<ogra> dholbach, i cant get it off the laptop ad have no second PC around 
<ogra> only way is the wlan card 
<dholbach> why don't you upload it to chinstrap from there?
<ogra> which obviously doesnt work 
<ogra> from where ?
<dholbach> the laptop?
<ogra> everything i try to get over the broadcom card thats bigger than 100k just dies
* ogra groans in anger
<dholbach> don't you have an usb key or a cross cable or something?
<ogra> yes, and then ? 
<ogra> auswringen in  den telefonhoerer ? 
<ogra> i only have my laptop here ... no other computers near me
<ogra> no wired network ... no cable
<jdong> ogra: tried swapping out hard drives?
<ogra> but a package i spent my whole day on ...
<jdong> if it's IDE you can also assemble a makeshift dual-port cable
<Burgwork> ogra: rar, if you have it installed, you can split it up
<ogra> jdong, swapping with what ? 
<jdong> ogra: what are you transferring to?
<Fujitsu> Burgwork: split can also split files, and it's free.
<jdong> ogra: tried split?
<Burgwork> true
<ogra> jdong, my laptop to upload.ubuntu.com
<jdong> ogra: ah, ok... yikes :-/
<Fujitsu> ogra: Your laptop to chinstrap.
<ogra> oh wait, this time it finished ... !!!
<ogra> sigh, it still took 30 min ... for shitty 6MB
<ogra> i want a proper broadcom driver !!!
<ogra> intrestingly only upstream is slow ... down its fast as expected
<Mithrandir> pitti: 2.6.20-11> yes, that's ok.
<ogra> Mithrandir, my edubuntu-artwork is up and waiting for your approval :)
<jdong> seb128: why was the LD_PRELOAD workaround for Xgl dropped from /usr/bin/compiz?
<Mithrandir> cjwatson: ubiquity bits> approved
<LaserJock> seb128: bug #92648
<Ubugtu> Malone bug 92648 in gnome-panel "no menu item for About Edubuntu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92648
<seb128> LaserJock: thank you
<seb128> jdong: dunno, we synced the package on Debian
<jdong> seb128: :( would you object to bringing it back? 
<seb128> jdong: no
<seb128> jdong: and why ":(", bug happens
<jdong> seb128: ok, I thought it was dropped for Xgl political reasons
<ogra> well
<pitti> hi jdong 
<jdong> hi pitti
<ogra> LD_PRELOAD is generally evil
<seb128> jdong: I don't care about Xgl but I would not drop patches if they were useful ;)
<pitti> jdong: testing new restricted-manager crack would be highly appreciated (for that pci id stuff)
<seb128> jdong: I just have no idea about it and I don't want to start working on it, I've enough to do already
<jdong> seb128: ok let me find the workaround and investigate it a bit more, then maybe bug you with a patch
<seb128> k
<jdong> pitti: ok, I filed that bug on behalf of a friend, let me get him in here
<adamant1988> Hello
<Mithrandir> dholbach: gnome-games given-back.
<jdong> pitti: adamant1988
<pitti> jdong: that would be splendid
<pitti> adamant1988: hello
<adamant1988> pitti: hello :)
<dholbach> gracias Mithrandir
<pitti> adamant1988: I attached a new restricted-manager package to bug 91036
<Ubugtu> Malone bug 91036 in xorg "restricted-manager picks wrong BusID for video cards" [High,Needs info]  https://launchpad.net/bugs/91036
<adamant1988> pitti: yes?
<Mithrandir> cjwatson: flock> that'd make sense, yes.
<pitti> adamant1988: could you install that and check whether restricted-manager now does the right thing?
<adamant1988> Oh dear.. I'm gonna cry if this breaks again lol
<adamant1988> But OK
<jdong> adamant1988: make backup of xorg.conf to xorg.conf.back
<pitti> adamant1988: i. e. not break xorg.conf and X any more when you enable the ATI fglrx driver?
<jdong> that way you can always get back
<adamant1988> jdong: got it
<pitti> adamant1988: don't worry, r-m creates backups of xorg.conf on its own
<adamant1988> pitti: That's pretty nifty then
<pitti> adamant1988: you just need to know how to login to a text console and move files around with sudo
<adamant1988> pitti: I can do that
<pitti> adamant1988: if you have IRC on a separate box, I can walk you through it if necessary
<pitti> adamant1988: thank you very much!
<adamant1988> Where do I get this at?
<jdong> adamant1988: it's on the bug report
<jdong> attachment
<pitti> adamant1988: I have confirmation from someone else that it fixes the issue, but I'd like to get it from the other reporters as well before I claim this fixed
* pitti -> back to meeting
<cjwatson> Mithrandir: turns out the bug I was encountering wasn't that, so it's just speculation that that might be what's causing other failures
<adamant1988> Ok, so I download "working patch"?
<cjwatson> Mithrandir: any opinions as to whether I should upload it pre-beta anyway?
<ogra> asac, is there a reason wny my FF always starts the about page and the firefox homepage in session recovery mode ? 
<asac> yeah ... you probably don't close ff
<asac> at the end
<Mithrandir> cjwatson: worst-case, it looks harmless.
<asac> thats why the property that indicates that you are *not* running old version is not persisted
<adamant1988> nevermind I got it
<asac> i will remove this milestone feature again
<ogra> asac, no i never close it ... i developed a habit of keeping tabs instead of bookmarks :)
<asac> yes :)
<asac> so its sane
<asac> you can edit
<asac> about:config
<ogra> ah
<asac> search 'mstone'
<asac> set that to ignore
<ogra> ok
<adamant1988> pitti: What do you want me to do with it?
<asac> ogra: haha
<adamant1988> disable and then re-enable my driver?
<ogra> asac, thanks :)
<asac> won't safe 
<pitti> adamant1988: right
<asac> close it once :)
<asac> ogra: or edit prefs.js
<pitti> adamant1988: btw, clicking on the deb gave gdebi to you, the graphical installer?
<adamant1988> pitti: yes
<adamant1988> ok says I need a system restart
<adamant1988> not really sure why.. I haven't downloaded anything and the fglrx is still installing, hehe
<seb128> grrr bugs flood, received like 60 bug mails between 6pm and 10pm
<adamant1988> ok brb pitti 
<adamant1988> hopefully
<pitti> adamant1988: good luck!
<tepsipakki> seb128: hopefully most of them were bugs that I closed :)
<tepsipakki> (not even close)
<pitti> seb128: Instant Karma!
<seb128> tepsipakki: not quite, after marking as read all the things I don't need to comment on I still have 30 new bugs or comments which need a reply :/
<LaserJock> pitti: like he needs any more ;-)
<seb128> pitti: rather another short night if I want to keep that under 100 :/
<pitti> LaserJock: he wants to get back to K10M with the current counting :)
<LaserJock> lol
<Fujitsu> That'd take a while.
* pitti hugs seb128 
<seb128> pitti: I'm happy to let you take some of the desktop bugs karma if you want ;)
* seb128 hugs pitti back
<LaserJock> probably will take seb128 at least Feisty+1 to get there
<seb128> at least your retracing make getting debug backtraces easy
<pitti> seb128: hm, lp.net/~apport didn't collect a single Karma point yet :(
<ogra> pitti, karma is overrated, its so inflational that it doesnt really matter :)
<Keybuk> ogra: it's fixed to not be, now
<Fujitsu> pitti: Is the auto-retracing waiting on anything more than being able to specify tags in uploaded blobs?
<ogra> Keybuk, until it gets fixed the next time ? :)
<pitti> Fujitsu: well, me completing the malone scraping engine
<pitti> Fujitsu: I actually have that ready
<pitti> Fujitsu: just need the python-launchpad-bugs addition to mangle tags
<pitti> adamant1988: welcome back!
<adamant1988> pitti: Nope, It can't seem to re-enable the driver
<adamant1988> First off it uninstalled fglrx, when I told it to "activate" it again, it doesn't even make an attempt
<pitti> adamant1988: what does it do?
<adamant1988> uno momento, let me run it from bash so I have a log
<jdong> seb128: http://web.mit.edu/~jdong/www/compiz-xgl.debdiff
<pitti> adamant1988: hm, there won't be much logging
<ogra> pitti, did you thnk about stealing the code from the fglrx-config package ? 
<jdong> seb128: that makes compiz work on Xgl again
<seb128> jdong: could you open a bug on launchpad rather?
<jdong> seb128: ok, will do
<pitti> ogra: I'll have another look at it
<seb128> thank you
<ogra> might be easier
<adamant1988> pitti: xserver-xorg postinst warning: overwriting possibly-customised configuration
<adamant1988>    file; backup in /etc/X11/xorg.conf.20070315173647
<pitti> adamant1988: that's fine
<adamant1988> except it's not doing anything
<adamant1988> it's not downloading or installing fglrx
<pitti> hmm
<pitti> adamant1988: what does 'grep fgl /etc/X11/xorg.conf' say now?
<adamant1988> pitti: uno momento
<pitti> adamant1988: and is the driver shown as enabled?
<adamant1988> pitti: No.
<jdong> seb128: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/92657
<Ubugtu> Malone bug 92657 in compiz "Set xlibmesa LD_PRELOAD when Xgl is present" [Undecided,Unconfirmed]  
<adamant1988> I try to re-enable it and it pulls up a screen asking me to enable it.  Then when I say "OK" it does nothing
<adamant1988> the grep fgl is empty too.
<seb128> jdong: k
<pitti> adamant1988: will you still be online for a bit? I'd like to debug this with you after my meeting if you can afford some minutes?
<adamant1988> pitti: sure, I'd kind of like my fglrx back.
<adamant1988> Since it uninstalled the package I'm assuming that I won't be able to use my old xorg.conf anyway
<jdong> adamant1988: sudo apt-get install xorg-driver-fglrx
<jdong> I'm not sure if RM does any more blacklisting though
<adamant1988> jdong: I'll just wait for him, so I can help him bug-fix it.
<jdong> sounds good
<adamant1988> part of that contributing thing, haha
<pitti> adamant1988: ok, can you please put your current xorg.conf into a pastebin?
<adamant1988> pitti: sure
<adamant1988> pitti: http://paste.ubuntu-nl.org/10522/
<pitti> adamant1988: 'lsmod | grep fgl' is empty?
<pitti> adamant1988: and 'cat /etc/modprobe.d/blacklist-restricted' shows fglrx?
<adamant1988> yes to the first
<pitti> adamant1988: btw, let's do this in /msg to not spam other people
<adamant1988> cat: /etc/modprobe.d/blacklist-restricted: No such file or directory
<ogra> pitti, oh, i forgot to file the bug for you about the /etc/modprobe.d/fglrx file you wanted to fix ... might be the same issue
<ogra> adamant1988, do you have such a file ? 
<adamant1988> ogra: Hrmm? 
<jdong> adamant1988: that's polite-speak for "get outta my channel" ;-)
<ogra> adamant1988, /etc/modprobe.d/fglrx
<adamant1988> ogra: just a moment
<cjwatson> Seveas: hope you're OK with me assigning bug 64408 to you based on what I understood from IRC earlier; trying to arrange assignees for more beta-targeted bugs
<Ubugtu> Malone bug 64408 in usplash ""Urgent" text is poorly readable due to low contrast (blue on black)" [Medium,Confirmed]  https://launchpad.net/bugs/64408
<Seveas> cjwatson, patches for all 4 themes (ubuntu, kubuntu, edubuntu, xubuntu) are available. The kubuntu one has been applied and uploaded. The others are waiting for someone to upload
<Seveas> cjwatson, I poked Mithrandir earlier and he said he'd review
<cjwatson> righto
<Seveas> but yeah, assigning to me is fine
<Seveas> actually, the same bug *may* have caused segfaults especially in amd64 but I didn't take a close look at that yet and actually suspect this is not the case
<dholbach> can somebody of the archive admins wave through gnome-bluetooth too? so we can kill openobex1.0?
<dholbach> libopenobex1.0 that is
<kwwii> dholbach: did you include the new session splash as well?
<dholbach> no
<ogra> :(
<dholbach> i didn't realize you had pushed the changes already
<kwwii> dholbach: !!! please do
* ogra was already looking forward to see ubuntu-users explode 
<dholbach> !!!
<kwwii> dholbach: yeah, I did that at the same time as gdm today :-)
<kwwii> sorry for the mixup
<Chipzz> pitti: not sure why you pasted that url for me :)
<ajmitch> ogra: oh, why would they explode this time?
<dholbach> doing it
<Chipzz> pitti: sure it wasn't meant for someone else? :)
<pitti> Chipzz: oh, i thought you were chipx86 sleeping
<cjwatson> dholbach: done
<pitti> Chipzz: sorry
<dholbach> cjwatson: thanks!
<Chipzz> pitti: no problem :)
<ogra> kwwii, your svg hacks to the gdm theme are extremely cool ... i used the ubuntu theme as base for the new edubuntu one ...
<kwwii> ogra: thanks :-)
<Chipzz> pitti: other people have assumed the same thing ;)
<Chipzz> pitti: /whois chipzz ;)
<pitti> Chipzz: right, no real name there :(
<Chipzz> pitti: hrrrm you're right
<kwwii> dholbach: that one is kinda important :D
<Chipzz> but: 22:55 [OPN]  -!- Chipzz [i=chipzz@safehex.be] 
<Chipzz> :)
<Chipzz> pitti: anyway no harm done, and thx I guess :)
<dholbach> kwwii: relax :-)
<Chipzz> pitti: chip86 is on #gtk+ on irc.gimp.org I think
<Mithrandir> tepsipakki: about the -vesa upload; has this been tested?
<Mithrandir> Riddell: you win the chance to write a MIR for pyopengl
<dholbach> kwwii: updated, so you don't have to change setup.py any more, tested, pushed and uploaded
<kwwii> dholbach: sweet, thanks :-)
<Riddell> Mithrandir: or send qt-gl packages to universe?
* dholbach is out for a beer - see you
<kwwii> dholbach: enjoy, thanks for the help today
<dholbach> no problem
<Mithrandir> Riddell: for some reason, anastacia wants to bring them back in when I demote them
* dholbach hugs kwwii
<dholbach> *wave*
<cjwatson> oh, reminds me, I should fix the seeds not to keep pulling in lowlatency kernels
<Mithrandir> cjwatson: yes, please.
<Keybuk> http://code.google.com/p/google-summer-of-code/issues/detail?id=10&can=2&q=
<cjwatson> mdz: I think I'll have to go back to the huge list of kernel packages in supported, unfortunately
<Keybuk> heh
<Mithrandir> cjwatson: doesn't the Exclude mechanism work there?
<mdz> cjwatson: oh, why?
<cjwatson> mdz: lowlatency shouldn't be in main
<cjwatson> Mithrandir: no, that's only for stuff pulled in by Extra-Include, not by basic globbing
<LaserJock> Keybuk: do you have to have a specific project in mind to mentor GSoC? or can you just be an available person?
<cjwatson> oh, hmm, I wonder how intelligent germinate's regex matching is
<Keybuk> LaserJock: available person, and pick and choose from the student applications available
<LaserJock> Keybuk: is there a need for more mentors?
<mdz> cjwatson: the re module supports (?!
<mdz> yay for exponential time though, I expect
<cjwatson> score
<Keybuk> LaserJock: it depends how many good applications we get
<cjwatson> who cares :)
<cjwatson>         if pattern.startswith('/') and pattern.endswith('/'):
<cjwatson>             patternre = re.compile(pattern[1:-1] )
<cjwatson>             filtered = [p for p in packages if patternre.search(p) is not None] 
<Keybuk> LaserJock: you can always sign up, and then not take on any students
<LaserJock> Keybuk: ok, thanks for the info
<Keybuk> (but you won't get a t-shirt :p)
<LaserJock> doh!
<Mithrandir> cjwatson: ok.  Do you have any idea why anastacia claims python-qt3-gl should be in main?  I feel useless trying to debug this.
<LaserJock> I already got a Google t-shirt from Mt. View though
<cjwatson> negative lookbehind would do it
<cjwatson> Mithrandir: have you checked germinate rdepends already?
<Mithrandir> LaserJock: the SoC t-shirts are different (and not generally available unless you're a student or mentor)
<Laser_away> :-)
<Mithrandir> cjwatson: yes, and it doesn't make sense.
<kylem> hawk 'em on ebay
<cjwatson> Mithrandir: http://people.ubuntu.com/~ubuntu-archive/germinate-output/feisty/rdepends/ALL/python-qt3-gl
<mdz> Mithrandir: I need 181946 approved; is that ok with you?
<cjwatson> Mithrandir: ok, so what's happening is that one of the other binaries in that source is in main, so Extra-Include: *-dbg matches the -dbg package, which then depends on python-qt3-gl
<cjwatson> Mithrandir: this is what Extra-Exclude is there for
<Mithrandir> cjwatson: ah, ok
<cjwatson> just say Extra-Exclude: python-qt3-gl-dbg somewhere in supported
<cjwatson> probably Kubuntu supported, I'm guessing
<Riddell> cjwatson: I'll add that now
<cjwatson> thanks
<Mithrandir> mdz: the setup.py looks like it has a syntax error.
<Mithrandir> +    if match:
<Mithrandir> +  version = match.group(1)
<Mithrandir> that's not legal, is it?
* Fujitsu thinks not.
<mdz> depending on the indentation, it should be
<mdz> Mithrandir: is there a script to do a debdiff based on the queue id?
<Mithrandir> that's a c&p from the diff.
<Mithrandir> mdz: no, but q fetch + mdebdiff is generally quite useful.
<Mithrandir> mdebdiff -s $suite (defaults to feisty) blah.dsc
<Mithrandir> (as lp_archive)
<mdz> Mithrandir: there is a non-code change in there which needs to go in tonight, one way or another
<mdz> (de-phallifying the gnome splash)
<Mithrandir> mdz: ah, point.
<mdz> Mithrandir: that c&p just looks tab-mangled, I'll have a peek
<mdz> Mithrandir: looks fine to me in non-IRC form
<_ion> "de-phallify" is one of the most interesting words i've heard for a while.
<mdz> but I'll do a test build to be sure
<Mithrandir> mdz: hm, indeed it does.  It'll still fail to build since version won't be in scope at that point, though?
<Mithrandir> mdz: I'm fine with it as long as it builds, but it's getting close to midnight here and I'd like some sleep so if you could get it through, I'd appreciate that.
<mdz> Mithrandir: somehow, it builds
<Mithrandir> mdz: ok, colour me confused.
<cjwatson> version will be in scope
<cjwatson> if blocks don't introduce a new scope
<Mithrandir> cjwatson: ok
<Mithrandir> mdz: accepted
<cjwatson> it will break if version never gets assigned to
<mdz> cjwatson: if it doesn't match, version won't be declared
<cjwatson> mdz: right
<mdz> but it does
<cjwatson> and you'll get a NameError in that case
<cjwatson> but that should be a NeverHappensError
<mdz> right
<mdz> dpkg-parsechangelog would probably barf too
<mdz> Mithrandir: thanks
<cjwatson> hmm, I wish germinate had an "any binaries from this source matching this regex" feature
<cjwatson> bit of a one-case feature though
<adamant1988> pitti: ping
<pitti> adamant1988: hi
<adamant1988> pitti: I have an issue.  Feisty has decided that my once great ATI Radeon X600 is now known as "generic video card"
<ulisse> 'lo people
<adamant1988> Which means that even with fglrx, I'm not getting any kind of meaningful acceleration, apparently..
<pitti> adamant1988: where do you see that text?
<adamant1988> it's in my xorg.conf
<adamant1988> I can't open up the hardware info to check
<adamant1988> it just crashes
<pitti> adamant1988: you mean the 'Identifier' in the 'Section "Device"'?
<adamant1988> uh huh
<ulisse> does GNOME sets a BROWSER variable for the user? I was using openwengo and I noticed it was opening URLs in Opera instead of Firefox, that was my default browser...
<pitti> adamant1988: that's usually not really important, as long as it's the same in section "Device" and "Screen"
<ulisse> I asked people on #openwengo and htey sayd that Wengophone uses portland to open files, so it checks for the BROWSER variable
<adamant1988> pitti: ok, yeah it's the same in both
<pitti> ulisse: Gnome has a gconf key for that
<adamant1988> so why don't have I have 3d acceleration?
<pitti> adamant1988: so as long as "Driver" uses fglrx, it should use that
<ulisse> pitti: but is it set by the "preferred apps" dialog?
<pitti> ulisse: this dialog sets that gconf key, right
<ulisse> hmm...
<pitti> adamant1988: module is loaded?
<adamant1988> pitti: how do I check?
<pitti> adamant1988: grep fgl /etc/X11/xorg.conf
<adamant1988> I know I have it in my modules to load at startup
<pitti> adamant1988: erm, scratch that
<pitti> adamant1988: lsmod | grep fgl
<ulisse> pitti: I'm sure that in the dialog there was "/usr/bin/firefox", but wengo still opened it with opera
<ulisse> pitti: I had to do "sudo update-alternatives --config x-www-browser" to make it change
<pitti> ulisse: seems that portland doesn't respect the gconf key then
<ulisse> pitti: is there a "global" BROWSER key, like a root one?
<ulisse> what do I change with update-alternatives?
<pitti> ulisse: there's a common environment variable, yes
<pitti> ulisse: you change /etc/alternatives/x-www-browser with that
<ulisse> pitti: now I wonder why opera stes itself as default in that var when you install it...
<ulisse> it shouldn't
<pitti> ulisse: I don't know; that's really #ubuntu material now
<ulisse> ok, thanks for now ;)
<ulisse> pitti: it seems that on #openwengo there is a guy that knows well portland, and it says that it looks for a VAR named BROWSER, not a gconf key...
<pitti> ulisse: right, as I said, the $BROWSER environment variable
<pitti> that's just not what Gnome uses for its default browser
<ulisse> pitti: so $BROWSER is not necessarly the same as the BROWSER key in gconf, right?
<pitti> ulisse: the gconf key is not called BROWSER, but yes
<ulisse> and how a user could set that $BROWSER var?
<pitti> . o O { #ubuntu! }
<ulisse> ok, ok, sorry
<pitti> ulisse: in /etc/environment (global) or ~/.bashrc
<pitti> ulisse: but instead the portland guys should fix that component to respect the gnome setting, IMHO
<ulisse> I think the same
<ulisse> as I know GNOME but not portland
<ulisse> and I know that GNOME is fo r usability :)
<khermans_> is this the proper place to discuss karma?
<sistpoty> khermans_: I guess #launchpad might be better
<sladen> khermans_: #launchpad maybe a better place
<khermans_> thx
#ubuntu-devel 2007-03-16
<Fujitsu> Mithrandir: I've just realised I forgot something in the pymol I just uploaded. Can you please reject it when you get around to doing that sort of thing?
<Fujitsu> Mithrandir: It seems I was able to overwrite it by uploading with the same version number again, so it's fine. Sorry for the noise.
<keescook> Mithrandir: I have a security fix for CVE-2007-1420 (DoS) for mysql-dfsg-5.0, okay to upload?
<asac> how can i get a launchpad hosted bazaar archive for my mozilla packaging?
<asac> bzr
<asac> :)
<cjwatson> asac: 'bzr push sftp://bazaar.launchpad.net/~asac/NAME-OF-SOME-LAUNCHPAD-PRODUCT/NAME-OF-BRANCH'
<cjwatson> asac: or replace ~asac with ~TEAMNAME if you want it to be writeable by other members of a team
<cjwatson> just do that in a bzr branch you have on your disk and it'll magically appea
<cjwatson> r
<asac> cjwatson: so just push? without registering product?
<asac> cool
<cjwatson> no, the product needs to exist first
<cjwatson> should be one for firefox already though surely
<asac> hmm
<asac> ok
<cjwatson> namely 'firefox'
<asac> so bzr archives are bound to product
<cjwatson> right
* asac still confused about products/teams/projects and whats the difference
<cjwatson> it's easy to create a product though if need be
<asac> e.g. from technical perspective
<cjwatson> ok, so
<cjwatson> products => single upstream things. Firefox is a product. mplayer is a product. totem is a product. etc.
<cjwatson> projects => collections of upstream things that are closely related. Mozilla, GNOME, d-i, etc. are projects
<cjwatson> bzr branches are associated with products because the bulk of bzr branches are expected to be branches from imports of upstream code, which is going to be of a particular product
<cjwatson> people/teams are a different ... I believe the term in LP-speak is "pillar"
<Fujitsu> Beware, products are currently being renamed to projects, and projects to project groups.
<cjwatson> different category, anyway. Person => generally a human, though some people in LP are automatic imports that basically just model an e-mail address
<Fujitsu> There's a lot of ambiguity on beta at the moment.
<asac> hmmm so why is ~asac ~teamname in the bzr url? where do people sync from? not just http://bazaar.launchpad.net/NAME-OF-SOME-LAUNCHPAD-PRODUCT/NAME-OF-BRANCH
<cjwatson> team => collection of people; generally you ought to be able to use people and teams interchangeably in almost any context in LP
<cjwatson> asac: just s/sftp/http/ - it's like public_html
<asac> is it just a permission thing?
<asac> ah ok
<cjwatson> yeah, pretty much
<asac> ok ... i think i get it
<cjwatson> it's like a g+w directory in public_html with the relevant group
<asac> multiple users / teams could have their own branch of a product
<cjwatson> not implemented that way, but never mind
<cjwatson> right, exactly
<asac> but is there an url for the ULTIMATE master branch ;)
<cjwatson> well, it's distributed VC, so not really :-) you see ~vcs-imports sometimes though, which corresponds to bzr imports of upstream CVS or svn or whatever
<cjwatson> I think firefox has been too huge and complicated to import up to now
<cjwatson> see also BzrMaintainedPackages on the wiki for some links you can follow into how people are using this stuff in practice in Ubuntu
<cjwatson> hmm, I should update those URLs
<poningru> halp
<asac> cjwatson: the idea would be to just upload debian directory and maintain patches inside it
<Fujitsu> asac: That's the `merge' functionality of bzr-builddeb.
<asac> cjwatson: its not for current package which is a sinking ship, but for a new great future :)
<asac> Fujitsu: he?
<asac> Fujitsu: what can this do?
<cjwatson> asac: yep, should be workable
<imbrandon> moins
<popey> I just installed a feisty herd 5 *command line* system, and it finished with multiverse and universe enabled out of the box.. is that not the wrong thing to do?
<poningru> popey: been doing that for all the installs now
<poningru> installed desktop today
<popey> ah, ok, fair enough
<poningru> turned out it had everything enabled by default
<poningru> well except for source
<popey> just seemed odd, i have never done a command line install
<popey> this has source too
<popey> only thing that isn't is backports
<licio> where is the update-manager logs?
<licio> uhm.. synapit/files/history
<licio> :)
<bhale> Mithrandir: i actually uploaded beagle 0.2.16.3, very minor increment off the bugfix svn branch (exception for .2). I can make a uvf later if really needed, upstream has been really pushing to get the stable branch updates in
<rourke> in default dapper and edgy, freetype's "without_bytecode_interpreter" variable is set to 0 or 1?
<pitti> Good morning
<Fujitsu> Hi pitti.
<pitti> hey Fujitsu 
<ajmitch> hi pitti 
<rourke> in default dapper and edgy, freetype's "without_bytecode_interpreter" variable is set to 0 or 1?
<Mithrandir> keescook: sure, feel free to upload.
<Mithrandir> Fujitsu: please don't upload multiple items with the same version numbers.  It confuses the archive admins.
<Mithrandir> Fujitsu: I've rejected one of them, I'm hoping for the right one
<Fujitsu> Mithrandir: Ah, I presumed it had overwritten. Sorry.
<Fujitsu> (I would have thought it wouldn't have accepted two of them, but I thought I'd try)
<Mithrandir> no, both end up in unapproved.  I call it a design bug.
<Fujitsu> That is a little silly, IMO.
<Mithrandir> yes, it is.
<imbrandon> no timestamp?
<imbrandon> btw, moins all
* Hobbsee is back.  
<Hobbsee> hopefully i wont get kicked out of here so quickly.
<Mithrandir> imbrandon: they're timestamped, so that bit is fine.  Still annoying.
<Mithrandir> Hobbsee! :-)
<imbrandon> Mithrandir, ahh true
* LongPointyStick hugs Mithrandir 
<Fujitsu> Argh, attack of the clones.
* Hobbsee hugs Mithrandir :)
<Fujitsu> You did accept the right one, Mithrandir. Thanks, and sorry.
<Mithrandir> bhale: changelog says * Update relibtoolize.dpatch, but it's disabled in 00list.  Is that on purpose?
<Mithrandir> Riddell: qt4-x11 FTBFS with references to your home directory.
<Mithrandir> slomo__: could you do a MIR for libxml-twig-perl?  It seems to be needed for libnet-dbus-perl.
<OpenNo> sup geeks
<Hobbsee> ...
<OpenNo> hobbsee my ol mate.
<Hobbsee> oh...i know who you are...
<OpenNo> who am I?
<OpenNo> do we even exist?
<OpenNo> lol sorry dude. How you been keeping?
<Hobbsee> just fine, thanks
<Hobbsee> why are you back here?
<OpenNo> huh?
<OpenNo> Because I have the right to be here.
<dholbach> good morning
<Hobbsee> hey dholbach!
<Fujitsu> Hi dholbach.
<Hobbsee> OpenNo: okay, just dont troll.  and i remember you from months ago.
<dholbach> hey Hobbsee, hey Fujitsu
<OpenNo> hey dholbach dude, what's happenin man? 
<OpenNo> I brought Vista on DVD and deleted it after first day. It chokes man.
<dholbach> i'm just waking up and ready for the day :)
<mdke> morning dholbach 
<dholbach> hey mdke
<Hobbsee> heya mdke 
<mdke> dholbach: what's the status in terms of freezes and such for an ubuntu-docs upload?
<Hobbsee> mdke: we're in main freeze at least.  ask a member of the release team
<dholbach> mdke: we're frozen for beta, but if you think it's necessary for the docs to go in, you have to talk to Mithrandir
<Mithrandir> mdke: I'm fine with docs being uploaded if you'd want them in for beta.
<mdke> Mithrandir: we have some new strings I'd like to get into the archive asap
<dholbach> mdke: ok, i'll do an update then
<Mithrandir> sure, talk to dholbach or whoever usually sponsors you.
<mdke> thanks dudes
<OpenNo> I found a bug in my Coffee.
<Hobbsee> OpenNo: hooray.  #ubuntu-offtopic
<OpenNo> I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant
<dholbach> OpenNo: the topic indicates that this channel is for development discussions of ubuntu - if you have nothing worthwhile to add, please don't disturb the rest of us
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Mithrandir> OpenNo: please stay on topic or leave the channel.
* mode/#ubuntu-devel [+b *!*@219-89-21-152.dialup.xtra.co.nz]  by Hobbsee
* OpenNo was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<Mithrandir> thanks Hobbsee
<Hobbsee> bloody trolls
<Fujitsu> Mithrandir: You know he's been here before a number of times, right?
<Hobbsee> pity i cant kickban on sight.
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<dholbach> hey mvo
<mvo> hey dholbach
<Hobbsee> ah, here we go.  predictable, he's gone to #ubuntu-ops
<Fujitsu> Is it publically logged?
<dholbach> mdke: can you add something like     export DEBFULLNAME='Daniel Holbach'
<dholbach> export DEBEMAIL='daniel.holbach@ubuntu.com'      to your ~/.bashrc ?
<dholbach> mdke: the changelog says   matt@kalliope    again
<Hobbsee> Fujitsu: somewhere.  just join
<mdke> dholbach: whoosh
<mdke> sorry
<dholbach> np
<Hobbsee> Mithrandir: and he's gone from the entire network.  nice. :D
<dholbach> mdke: -> query
<mneptok> Hobbsee: i can kb on host recognition, but i don't feel like scripting the bits to get a +o to actually do it.
<Hobbsee> heh
<mneptok> torpor FTW!
<dholbach> mdke: i sent you a list of files that are not in server guide any more - I suppose you've rushed off to work. I'll upload it now, the docs work for me. If stuff breaks, drop me a mail and I'll update it again
<dholbach> mdke: glad to see that was alright
<mdke> yep, all good
<mdke> Mithrandir: if you can poke it through as/when necessary, that'd be great
<Mithrandir> sure
<tepsipakki> what is the correct format for an automatic bug-closing entry in the package changelog?
<tepsipakki> I've tried some but they don't work
<cjwatson> tepsipakki: correct
<cjwatson> tepsipakki: the LP side isn't implemented
<cjwatson> tepsipakki: if you do (LP: #bugnum) you should get a Launchpad-Bugs-Fixed: field in your .changes, but it won't do anything else yet (like actually close bugs)
<tepsipakki> oh, ok
<tepsipakki> I thought it was in use already.. that's the format I've used recently
<pitti> hi asac
<tepsipakki> Mithrandir: I have a new xresprobe & xorg waiting for upload. The xresprobe situation should be familiar from the discussion on u-d, and xorg fixes two bugs
<tepsipakki> so should I ask for approval first?
<pitti> hmm, no cdimage /ports/edubuntu?
<cjwatson> never built
<pitti> ok, thanks, ignoring for langpack filling then
<Mithrandir> tepsipakki: ok, please get it uploaded.
<seb128> Mithrandir: I've uploaded a new GTK+, 2.10.11 is 2.10.10 with a bug fix we already had and I've added an another patch from upstream (which is to SVN now) to try fixing all the gnome-panel crashes happening on upgrade
<Mithrandir> seb128: wonderful
<dholbach> release team: what about bug 92183? (maybe after beta freeze)
<Ubugtu> Malone bug 92183 in workrave "UVF: workrave 1.8.3 -> 1.8.4" [Medium,Unconfirmed]  https://launchpad.net/bugs/92183
<Mithrandir> dholbach: scarily big is my initial thought
<dholbach> Mithrandir: i know... we've waited for a release for quite a long time - I think I forwarded some of the bugs that got fixed during breezy
<Mithrandir> dholbach: if we can get it well tested, I'm ok with it, but I think it's a bit on the large side.
<dholbach> Mithrandir: well tested like "upload it and if people complain about bugs too much, roll back"?
<sladen> Mithrandir: policy issue, stick with upstream, or remain consistent with Ubuntu?  https://launchpad.net/bugs/91665
<Ubugtu> Malone bug 91665 in mesa "glxgears -iacknowledgethisisnotabenchmark patch dropped" [Undecided,Unconfirmed]  
<Mithrandir> dholbach: for instance.
<dholbach> Mithrandir: ok, I'll keep looking at those bugs (and upload after beta - or do you want me to do it earlier?)
<Mithrandir> sladen: *shrug*; I don't really care either way.
<Mithrandir> dholbach: post-beta, yes.
<dholbach> ok
<seb128> no need to carry diff for that imho
<dholbach> I get this "ATA: abnormal status 0x7F on port 0xCC07" with a test machine with 2.6.20-11
<dholbach> works with -9
<sladen> Mithrandir: seb128: rock. ta
<seb128> np
<seb128> sladen: BTW if you could look at the list of similar bugs displayed on launchpad when opening one that would be nice, you tend to file a lot of dup
<fabbione> dholbach: it seems related to the changes kyle did on HPA
<fabbione> dholbach:  i get something similar too, but my disks keep working
<dholbach> bug 84359
<Ubugtu> Malone bug 84359 in linux-source-2.6.20 "ATA: abnormal status 0x7F on port 0xD407" [Medium,Confirmed]  https://launchpad.net/bugs/84359
<dholbach> *subscribing to it*
<fabbione> Mithrandir: do you think we can upload the new d-i to grab 2.6.20-11 ?
<Mithrandir> fabbione: I'd like cjwatson to do the steps, unless he's busy today.
<fabbione> Mithrandir: sure.. that works for me
<pitti> mvo: I'll need to upload *-meta soon for language input support; we should combine that with your command-not-found upload IMHO
<mvo> pitti: yes, that sounds good
<slomo__> Mithrandir: is there anything in main using libnet-dbus-perl anyway?
<mvo> pitti: I haven't updated the seeds yet, I will do that after I finished fighting with vte (~5min)
<pitti> mvo: I can add it for you if you want
<pitti> mvo: just adding (command-not-found) to standard?
<mvo> pitti: yeah, cool
<mvo> pitti: thanks!
<sladen> seb128: I like dups.  I actual get useful new information from each one and an overview of the scale of the issue, rather than "me too!"s from people who /think/ they have the same bug
<seb128> sladen: we don't like dups so please don't file them for the fun
<Mithrandir> there, NEW and unapproved queue published as ubuntu-archive and not me.
<seb128> sladen: the dup flood makes almost impossible to get any work done
<sladen> seb128: preference noted WRT to desktop bugs
<mvo> Mithrandir: should network-manager respect interfaces in /etc/network/interfaces and leave them alone? or this this not done yet?
<pitti> Mithrandir: \o/
<Mithrandir> mvo: what do you mean by "respect interfaces in /e/n/i"?
<pitti> mvo: if they only have 'dhcp auto' without options, n-m will manage them
<sladen> mvo: if you go  Network Manager->Static Connection, does NM then respect that interface?
<pitti> mvo: otherwise they should be ignored by n-m
<mvo> Mithrandir: I noticed that after my last big upgrade my eth0 interface that has a static IP is not having a IP anymore when NM is runing
<Mithrandir> pitti: no, I tweaked the logic slightly.
<pochu> Mithrandir: do you know when the first beta candidates will be available?
<pitti> mvo: ah, right, same here; n-m only has the concept of 'one active interface', it seems
<Mithrandir> pochu: maybe today, more likely monday.
<pitti> Mithrandir: oh, you manage static interfaces now?
<pochu> Mithrandir: ok, thanks!
<pitti> Mithrandir: I thought the idea was just to check whether they are active, but not mangle them?
<Mithrandir> pitti: yes, at least some bits of it.  Or at least it considers them and thereby avoids marking the whole system as offline.
<pitti> mvo: will you take care of writing a MIR for command-not-found?
<pitti> mvo: oh, nevermind, it's already approved
<pitti> mvo: "not ready according to mvo; contact him before promoting"
<mvo> pitti: cool
<pitti> mvo: ok, seeded, I'll promote it now
<mvo> sladen: its very strange, its in roaming mode when I look at the static configuration
<mvo> pitti: aha, right. I have the same problem. I can only choose one active interface, the other is taken offline
<Mithrandir> mvo: that is how NM works.  Currently, if you don't want that, don't use NM.
<pitti> mvo: I had to purge n-m for that on my desktop
<Mithrandir> you can just disable it instead of purging it.
<pitti> right, but I don't need it anyway
<mvo> Mithrandir: ok, thanks
<pitti> maybe we should use our fancy laptop-detect scripts to only enable n-m on laptops
<sladen> and even when you /do/ want to roam, sometimes NM just refuses to configure stuff and you need to do things manually (particulary if it involves keys, which it puts in a keyring and which are protected and you don't enter the passphrase quick enough)
<giftnudel> sladen: or if you need to do fancy stuff with wpa_supplicant
<Mithrandir> patches accepted for all those special cases.
<giftnudel> well, there is a patch for my problem somewhere on the nm-devel list ...
<giftnudel> but its for 6.5 ...
<giftnudel> well there was the idea of providing a "I'm online!" button in the applet which would serve as a workaround
<giftnudel> or maybe a option to disable network manager in the applet ... that would help, too
<cjwatson> fabbione: yeah, but I want to see if I can do anything about the keymapper us/jp confusion first
<pochu> hey heno! Vorian says he can test Kubuntu, do I change his choice, and mail him?
<fabbione> cjwatson: sure..
<pochu> heno: we really need kubuntu auto-resize
<heno> pochu: yes, please do. I think we may still get more ubuntu testers
<pochu> k
<mvo> Mithrandir: could you please accept vte? a very small change that fixes a bug in the keep-fd code that is needed for update-manager
<Mithrandir> mvo: accepted
<mvo> Mithrandir: thanks \o/
* ogra cant belive the iso builds from tonight are right .... at least not the edubuntu desktop ones .... no oversizedness at all ...
<Mithrandir> ogra: they don't contain any langpacks.
<ogra> Mithrandir, not even the ones i seeded ?
<ogra> why is that ?
<Mithrandir> ogra: when did you seed them?
<pitti> ogra: I just filled them again
<ogra> Mithrandir, yesterady
<pitti> ogra: I told you yesterday, remember?
<pitti> ogra: I emptied all CDs to have a clean slate, and today I filled them again with the new priority/input support/etc.
<ogra> pitti, i merged your ubuntu change, which enabled them again for me (i only had en enabled since feisty started)
<pitti> ogra: now I'm waiting for this cron.daily cycle, then I can update some -meta pacakges, then I'll ask for respins
* ogra goes to check the packagelist .... i'm sure i enabled langpacks in the live seed
<pitti> ogra: ok, please; I modified the seeds about an hour ago, and assume that the current seeds reflected the current CD sizes
<ogra> pitti, ok
<ogra> there is only en ... weird ...
<ogra>  * Languages: zh es bn hi ar xh pt ru ja fr
<ogra>  * language-pack-${Languages} [i386] 
<ogra>  * language-pack-gnome-${Languages} [i386] 
<ogra>  * language-pack-kde-${Languages}  [i386] 
<ogra> thats my seeds
<pitti> Mithrandir: I'd like to upload a new desktop-effects to fix bug 92681; I just modified a label in the .glade file
<Ubugtu> Malone bug 92681 in desktop-effects "Must warn user before attempting to enable" [Medium,In progress]  https://launchpad.net/bugs/92681
<pitti> ogra: erm, those are not the ones I modified
<Mithrandir> pitti: ok.
<pitti> ogra: you need *lots* of input support for zh, ja, and some for bn, hi, ar, and ru
<ogra> pitti, anyway, this change was yesterday and todays build of edubuntu doesnt have them ... smells like the livefs isnt respun properly 
<Mithrandir> ogra: your checkout is old.
<pitti> ogra: hm, did you really push the seed commits?
<ogra> Mithrandir, ? i do a bzr update before i modify anything
<Mithrandir> ogra: what revision are you on?
<ogra> pitti, pretty sure, regarding the huge list of changes my -meta had
<ogra> 573
<Mithrandir> that's old.
<Mithrandir> 577 is the latest.
<mvo> pitti: if -meta is not yet up, I would like to add update-manager-core to -standard as well
<cjwatson> ogra: you sure you created your seed checkout using 'bzr checkout', not 'bzr branch'?
<cjwatson> ogra: you sure you created your seed checkout using 'bzr checkout', not 'bzr branch(or synonyms) 
<mvo> pitti: its required for release-upgrades on the server with the upgrade tool
<pitti> ogra: 574 was my cleanup
<cjwatson> (sorry, wireless problems and hideous ssh lag to my client)
<ogra> cjwatson, pretty sure ...
<pitti> mvo: sure, go ahead
<ogra> i mean irt worked all the release :)
<cjwatson> well, work it out and fix it. you're in the best position to do so now that you know your checkout is out of date
<pitti> Mithrandir: d-e uploaded
<Riddell> mvo: I was looking at bug 91329 but realised it affected the gtk frontend too, where on earth has xinput gone?
<Ubugtu> Malone bug 91329 in language-selector "[apport]  qt-language-selector crashed with OSError in __input_method_config_changed()" [Undecided,Confirmed]  https://launchpad.net/bugs/91329
<sladen> Mithrandir: there's a 2-line hotkey-setup patch in the queue to prevent upgrades from failing
<sladen> Mithrandir: 2-line mesa upload in the queue to make GoogleEarth useable on feisty
<tepsipakki> sladen: already approved
<tepsipakki> the mesa one
<tepsipakki> but it's neither just two lines nor in the queue yet :)
<pitti> tepsipakki: mesa is in accepted already
<Mithrandir> sladen: hotkey-setup, accepted.
<sladen> Mithrandir: groovy, ta
<tepsipakki> pitti: ah, darn
* tepsipakki stops doing duplicate work
<pitti> tepsipakki: 'darn'? we can reject it from approved if it's broken
<mvo> Riddell: checking
<tepsipakki> pitti: no not that, it's good. Just that I started doing it already :)
<Mithrandir> tepsipakki: meh, sorry, I thought it was the upload from you, the diff was at least the same.
<tepsipakki> it's cool
<Mithrandir> pitti: desktop-effects accepted.
<pitti> merci
<sladen> tepsipakki: ah, did you beat me to it :)
<pitti> Mithrandir: is there anything wrong with this command?  change-override.py -c main -S command-not-found
<tepsipakki> sladen: no, you did :)
<tepsipakki> I was just slow
<pitti> Mithrandir: I did it two times now, cron.daily is over for a long time already, and it's still in universe
<sladen> tepsipakki: would have been quicker, bar the 60 minute wait while it built locally so I could test it.  X got modularised, so they made mesa monolithic just to make up for it
<tepsipakki> heh
<tepsipakki> well, I didn't reply to the bug so my bad
<Mithrandir> pitti: no, looks correct.  I re-ran it for good measure
<pitti> weird
<bhale> Mithrandir: no, missed readding it
<bhale> Mithrandir: fixing
<pitti> Mithrandir: oh, it's actually promoted; it's just madison lying
<pitti> (lieing? argh)
<Keybuk> seb128, dholbach: having a very weird GNOME Terminal/vte bug
<seb128> Keybuk: refresh not correct sometimes?
<Keybuk> when switching desktops, it doesn't repaint at all
<pitti> ^ speaking of that, my terminals still don't redraw correctly
<seb128> Keybuk: known
<Keybuk> so I'm left with a white window
<seb128> pitti: known
<pitti> right, same here
<Keybuk> or, if the workspace switcher window was slightly over it, just that bit <g>
<pitti> seb128: do you still need a test case or do you have one?
<Keybuk> ah, coolies
<Mithrandir> pitti: (lying)
<seb128> pitti: would be better with one
<pitti> seb128: I didn't find an immediate reproducer
<seb128> https://launchpad.net/ubuntu/+source/vte/+bug/92405
<Ubugtu> Malone bug 92405 in vte "[Feisty]  gnome-terminal doesn't always redraw after switching desktops" [High,Confirmed]  
<seb128> ah
<pitti> seb128: just letting it sit on another workspace while I work, and switchign to it after, say 15 minutes, reproduces it
<seb128> looks like upstream got details
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=414716
<Ubugtu> Gnome bug 414716 in VteTerminal "Refresh issue after changing workspaces" [Normal,Assigned]  
* Keybuk targets it
<seb128> pitti: no need to bother
<pitti> yay
<pitti> mvo: ok, -metas are good to refresh now; do you, shall I?
<seb128> Keybuk: I already did, no?
<Keybuk> seb128: maybe, it wasn't there; but LP has been dropping status edits recently
<seb128> anyway it's on my list
<seb128> it'll be fixed for feisty
<Keybuk> thanks seb
<seb128> do we really need to get it fixed for beta?
<seb128> np
<Keybuk> we don't have a release milestone yet :p
<seb128> we do
<bhale> Mithrandir: 00list fixed, uploaded
<seb128> I'm using 7.04 for weeks now
<pitti> Keybuk: meh?
<seb128> I've a good bunch of desktop bugs there
<Keybuk> oh, silly me
<Keybuk> ubuntu-7.04
<Keybuk> I didn't go that far  down the list
<Keybuk> I'll retarget it to that
<ogra> seb128, do you want the patch from bug 67919 for beta ?
<Ubugtu> Malone bug 67919 in gnome-screensaver "Xinerama problem with log out and unlock dialogues" [Medium,Confirmed]  https://launchpad.net/bugs/67919
<pitti> Keybuk: right, yay for inconsistent naming :)
<seb128> ogra: after beta is fine I think
<ogra> ok
<seb128> ogra: but if you want to do that now feel free ;)
<ogra> i'm just looking through the screensaver bugs for patches .... if i find something else additionally i'll roll a package
<cjwatson> pitti: try 'rm -rf .madison-lite/cache' if that happens
<seb128> ogra: ok, cool
<ogra> hmm, an automatic "bugs with patches attached" search feature would be really nice
<cjwatson> I think it can sometimes screw up its timestamps if you run madison-lite right while the mirror is updating
<cjwatson> pitti: (and "lying" is correct)
<pitti> cjwatson: ah, thanks for the hint; indeed it works now
<mvo> pitti: go ahead, fine with me
<seb128> ogra: there is a "look only for bugs with patch" case you can use on launchpad search
* ogra checks
<ogra> wow
<cjwatson> indeed, it searches for bugs with attachments where the attacher checked the patch checkbox
<Keybuk> hmm, that's a bit poo
<Keybuk> Cherry don't seem to make the G80-3000 anymore :-/
<pitti> mvo: u-manager-core isn't for kubuntu/edubuntu?
<mvo> urgh, my bad
<pitti> mvo: oh, nevermind
<ogra> Keybuk, build it yourself then http://steampunkworkshop.com/keyboard.shtml ;)
<pitti> mvo: -standard is shared amongst all derivatives
<Keybuk> ogra: that requires a keyboard to start from
<mvo> pitti: ah, good. that is what I expected, but you made me nervous :)
<Keybuk> the problem is that I've managed to wear this one out
<Keybuk> the space bar has a tendancy to repeat
<Keybuk> admittedly this keyboard is anything from 4-8 years old now
<Keybuk> and is the third G80-3000 I've owned
<ogra> ah
* ogra has a shitty cheap sun usb keyboard under his fingers
<pitti> Mithrandir: new {,k}ubuntu-meta uploaded (adding input support for shipped translations, command-not-found, and update-manager-core for mvo)
* pitti pats his Kinesis Ergo -- takes a while to get used to, but it's just *great*
<Riddell> what is update-manager-core?
<ogra> the one with the hill ?
<pitti> ogra: http://www.kinesis-ergo.com/classic.htm
<ogra> ah, thats different from what i thought
<pitti> I didn't have any wrist/thumb problems any more since I have that
<ogra> requires you to stricht 10finger typing ...
<pitti> and it's comfy
<eXistenZ> I downloaded the source package of Kalcul and tried to rebuild it with pbuilder. Can anyone help me with this error: http://rafb.net/p/qoAWS270.html .
<ogra> not for smokers :P
<mvo> Riddell: the code that can fetch the update from the net, its required if you want to do server upgrades
<pitti> ogra: there's a black one, too :-p
<ogra> pitti, i measn the forced 10 finger usage :)
<Keybuk> http://www.microwarehouse.co.uk/catalogue/item/CHEKE010
<Keybuk> \o/
<Keybuk> (not in stock though :-/)
<Riddell> mvo: so it's distUpgrade tool core?
<mvo> Riddell: the fetcher part of it
<Riddell> right
<mvo> Riddell: well, fetching + gpg verification
<pitti> Keybuk: http://www.datahand.com/products/proii.htm :)
<Keybuk> pitti: heh
<pitti> Keybuk: I'd love to try out this one
<pitti> but I guess the learning curve is close to a vertical wall
<ogra> its missing belts
<StevenK> "Adapter included to hook the DataHand System and flat keyboard to computer system simultaneously" - is that so you can still type after you've given up with the first one? :-)
<pitti> ogra: but you won't need a password with this one any more :)
<ogra> lol
<StevenK> pitti: That's for sure.
<Keybuk> http://www.cherrykeyboardsrus.co.uk/G803000+Series-Details.htm
<Keybuk> yay
<Keybuk> (and what a domain name, lol)
<StevenK> pitti: You could leave the root password on a slip of paper and still be safe.
<Riddell> mvo: if I install chinese that xinput-all_ALL alternative appears, but I'm not sure what creates it or what language-selector should do if it doesn't exist
<mvo> Riddell: ok, please assign it to me then
<pitti> seb128: I just got an evolution notification that my call with Keybuk at 1300 is in *one* hour (it should be 30 minutes...)
<Keybuk> no, it should be in one hour 30 minutes
<pitti> ok, that's me mixing up UTC again, but evo should display '30 minutes', not '1 hour'
<fabbione> Keybuk: hey dude.. got time now?
<Keybuk> fabbione: sure, what's up?
<fabbione> Keybuk: UUID transition handling... i need to know what packages are involved and how they interact with each other...
<fabbione> Keybuk: i could find stuff in volumeid.postinst to convert fstab
<Keybuk> right
<Keybuk> that's all there is
<fabbione> Keybuk: but i don't understand where the sparc filter is
<Keybuk> sparc filter?
<Keybuk> there isn't a sparc filter
<fabbione> root is not converted?
<fabbione> or actually...
<Keybuk> oh, because that's in the boot loader <g>
<Keybuk> see grub postinst
<Keybuk> (actually, see update-grub)
<StevenK> Or root will be unconverted to UUID if it's LVM
<Keybuk> LVM is exempt from UUID  conversion
<fabbione> Keybuk: what about d-i? is there any package involved there?
<Keybuk> as are any devmapper devices
<Keybuk> fabbione: d-i writes the fstab out as uuids
<fabbione> since d-i writes the first fstab
<fabbione> hmmmm
<Keybuk> I suspect you're just missing the silo bit
<fabbione> cjwatson: what package generate fstab in d-i?
<sistpoty> Mithrandir: any news on removing binary packages for broken packages yet?
<seb128> pitti: so many bugs :(
<fabbione> Keybuk: silo for sure.. silo-installer too, but i think there is one more
<fabbione> Keybuk: the problem is that silo doesn't understand root=UUID= so ideally i would change that to root=/dev/disk/by
<fabbione> root=/dev/disk/by-uuid
<fabbione> it would require less testing and much less mangling of silo code
<Keybuk> silo reads the root=  bit?
<Mithrandir> sistpoty: cjwatson doesn't like the idea and I'm somewhat in agreement with him.
<Keybuk> root=UUID=* and root=/dev/disk/by-uuid/* are the same; since that's all initramfs does when it seems the former
<fabbione> Keybuk: silo reads root= to check if the config is valid and to do other stuff.. but it doesn't understand UUID=
<Keybuk> ok
<fabbione> Keybuk: and i know that they are the same
<fabbione> but if i pass /dev/disk... silo is ok
<fabbione> it resolves the symlink etc.
<fabbione> but teaching UUID= is complicated
<sistpoty> Mithrandir: ok. Out of curiosity, what are the reasons for that?
<fabbione> Keybuk: so just to make sure i understood everything... d-i already write fstab with UUID, volumeid does the conversion on upgrades, update-grub takes care of grub..
<fabbione> Keybuk: for sparc i will need to check generated fstab from d-i, volumeid will work, silo-installer to point to /dev/disk/by-uuid and silo to convert silo.conf on updates
<pitti> Mithrandir: could you please accept the -meta uploads, so that they'll go in quickly and we can verify new CD sizes?
<pitti> Mithrandir: I can accept them as well if you want me to
<Mithrandir> pitti: looking.
<pitti> <pitti> Mithrandir: new {,k}ubuntu-meta uploaded (adding input support for shipped translations, command-not-found, and update-manager-core for mvo)
<Mithrandir> sistpoty: archive admin overhead as well as it being really surprising if new packages showed up in -updates
<Mithrandir> pitti: no edubuntu-meta?
<pitti> Mithrandir: not necessary, no changes
<Keybuk> fabbione: shouldn't need to check the fstab
<Mithrandir> pitti: ok
<Keybuk> grub doesn't, it just converts the uuid of the device
<pitti> Mithrandir: command-not-found and update-manager are standard, which is shared amongst all derivatives
<Mithrandir> (accepted)
<pitti> Mithrandir: thanks
<fabbione> Keybuk: yes i saw update-grub. 
<fabbione> Keybuk: ok thanks
<cjwatson> fabbione: partman-target with help from the rest of partman depending on the filesystem type
<sistpoty> Mithrandir: k, thanks
<fabbione> cjwatson: thanks
<cjwatson> fabbione: but from the above, you shouldn't need to touch that - just make silo-installer munge it
<cjwatson> there's no reason why the generated fstab should be wrong - it's not architecture-dependent at that level
<fabbione> cjwatson: ok. i just need to get this right at the first shot so extra paranoia applies.. nothing fancy
<fabbione> and it wasn't really planned.. but things have started blewing up so i need to get it done
<cjwatson> fabbione: I thought sparc64-installer was all done and tested ...
<fabbione> cjwatson: we never did the UUID conversion for silo.
<fabbione> cjwatson: because silo doesn't understand root=UUID.. as simple as that
<fabbione> up to edgy everything was "working" fine
<fabbione> in feisty it needs love because devices are not appearing in the same order anymore
<sladen> fabbione: surely silo just has to ignore root=... and pass it through to the kernel?
<fabbione> sladen: no it does sanity checks on the config everywhere
<_ion> seb128: The patch in bug #89524 seems to have fixed the problem at least for me and the bug's original reporter.
<Ubugtu> Malone bug 89524 in vte "[apport]  GNOME Terminal Unicode SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/89524
<fabbione> anyway it's all fixable.. it's a matter of few changes in 2 scripts
<seb128> _ion: good
<sladen> Mithrandir: that mesa upload ftbfs as Xext.h has moved to another -dev package since the last upload.  I don't have more time today to spend another hour rebuilding inside pbuilder to verify it.  Shall I just do a source-upload with that extra build-dep [it may fail again if more headers have been moved] 
<Mithrandir> sladen: yes, please.
<_ion> seb128: As a different -ubuntu3 was released, i attached a new debdiff.
<seb128> _ion: ok
<pitti> _ion: I had a look on the ati.amd.com site yesterday, I didn't find a comprehensive product ID mapping either :(
<_ion> pitti: :-(
<pitti> _ion: however, the fglrx docs have a list of the names of the supported cards
<pitti> maybe we'll find a different web page which lists the product IDs
<pitti> _ion: something like http://www.pcidatabase.com/search.php?device_search_str=Radeon&device_search=Search
<pitti> _ion: this website is quite nice
<fabbione> ah craptastic.. i can't test the changes without a new d-i
<_ion> I wonder if the names in that list are accurate enough that it could be compared to /usr/share/misc/pci.ids
<pitti> _ion: I guess we should add a manual supported list for now
<jdong> pitti: could also check distros like Sababayon that detect AIGLX vs Xgl at bootup
<pitti> oh, hi jdong
<jdong> hi :)
<pitti> jdong: I just added another test package to bug 91036
<Ubugtu> Malone bug 91036 in restricted-manager "restricted-manager picks wrong BusID for video cards" [High,Needs info]  https://launchpad.net/bugs/91036
<pitti> _ion: indeed, that looks sufficient
<pitti> _ion: would you like to look into that, or can you give me a quick cheatsheet how to write those modinfo lists?
<jdong> pitti: cool I'll find my buddy this afternoon and see
<jdong> mmm, jdong's homemade wake up after 2 hours of sleep recipe.... take 3 spoons of powdered coffee and hold under tongue
<jdong> repeat as needed.
<_ion> pitti: For example, a random device in my system: pci:v00001013d00006003sv0000153Bsd0000112Ebc04sc01i00...
<sladen> Mithrandir: done;  I added three -dev packages based on a  grep -r  for likely headers;  the last one maybe more than required
<_ion> pitti: That means, v: 00001013, d: 00006003, sv: 0000153B, sd: 0000112E, bc: 04, sc: 01, i: 00...
<pitti> _ion: right, that's clear
<pitti> _ion: 'v'endor, 'd'evice, 'subVendor', 'subDevice'?
<_ion> pitti: v = vendor ID, d = device ID, sv = subvendor ID, sd = subdevice ID, bc is device class, sc is device subclass. I don't remember what the i is, but nothing seems to be using it.
<_ion> pitti: And the patterns are simply fnmatch patterns
<_ion> The pattern could be "pci:*" and it would "work", but canonically the equivalent pattern would be written as pci:v*d*sv*sd*bc*sc*i*
<pitti> _ion: ah, that's easy enough; thank you!
<_ion> And in a real situation, there are IDs in place of some of those *s 
<pitti> _ion: when do you use .append and when .override? does that mean that 'ath_hal' and 'ipw3945' do not have any internal modaliases (thus need additions), and nv has too generic ones (thus need overrides)?
<_ion> pitti: Indeed.
<pitti> _ion: ok, so for now I'll just make that 'pci:v00001002d*sv*sd*bc03sc00i* fglrx' more fine-grained
<_ion> pitti: All the additions and overrides *currently* being used could be just overrides with the same result, but i thought that perhaps there's going to be a case in the future where a module that has a list of is own needs to have additional patterns.
<_ion> pitti: I could take a look at that fglrx list as well, perhaps even write a program that compares the list to pci.ids
<jdong> or try to start the card with fglrx and if it doesn't work, then it's obviously not supported :D
* jdong ducks
<_ion> :-D
<jdong> wonder how Sabayon does it
<jdong> they should be our prime authority on 3D detection and bling.
<pitti> _ion: !
<pitti> _ion: http://wiki.cchtml.com/index.php/Hardware
<_ion> pitti: That doesn't specify the version of the fglrx driver.
<_ion> It doesn't list the ID for every card either.
<pitti> _ion: but it should be good enough for using pci.ids
<pitti> _ion: http://ati.amd.com/online/rss/atilinuxdriver.rss?OTC-rssfeedlinux
<pitti> _ion: the links on this are per-version
<_ion> Alright.
<_ion_> Sigh. It sucks that i have to download 120 megabytes of linux-restricted-modules when i only want the fglrx "source".
<_ion> pitti: Whoa! % strings x710/usr/X11R6/lib/modules/drivers/fglrx_drv.so | egrep '^0x[0-9A-F] {4}$'
<pitti> _ion: I don't hvae that installed
<pitti> _ion: does it have a list of supported product IDs?
<_ion> pitti: Seems very much like that's the list.
<pitti> _ion: rock! that means we could add another script that parses it out of that file and adds it to the modules list?
<_ion> Yeah, i'll do that a bit later.
<Kagou> i'm under feisty. and i just bought a DLINK DWL G650. I plug it (wifi) all is fine (wep/wpa2). But restricted manager said that i'm using non-free/restricted drivers for this. Are madwifi drivers non free ? I believe they are GPL...
<pitti> Kagou: some modues are in l-r-m at least
<pitti> /lib/modules/2.6.20-11-generic/madwifi/wlan.ko
<pitti> ^ from dpkg -L linux-restricted-modules-2.6.20-11-generic
<mjg59> Kagou: madwifi is non-free
<fabbione> Keybuk, Mithrandir: http://people.ubuntu.com/~fabbione/silo.debdiff and http://people.ubuntu.com/~fabbione/silo-installer.debdiff
<fabbione> Mithrandir: i could test silo easily, but i need to wait new d-i to test silo-installer
<fabbione> Mithrandir: because of the kernel ABI change..
<fabbione> once it's tested i would like to upload
<fabbione> anyway,, i am done for the day
<fabbione> brain is melting
<fabbione> later everybody
<Fujitsu> Bye fabbione.
<Kagou> oh ! just wlan.ko i understand. Thanks pitti . mjg59 -> http://freshmeat.net/projects/madwifi/  non free ?
<Kagou> mjg59: sorry you'r right (except for the binary-only HAL)
<Mithrandir> fabbione: looks sane to me, so if it's ok with Keybuk then go for it.
<fabbione> Mithrandir: i want to test silo-installer too... i don't like blind uploads. and silo-installer is not in the d-i initrd and can be uploaded "anytime"
<fabbione> thanks for the approval. once i know that both work i will upload
<fabbione> (pending Keybuk of course)
<fabbione> time to enjoy we
* fabbione &
<kylem> fabbione, have a god one
<fabbione> thanks dude
<fabbione> you too
<viviersf> soz to ask this in the #
<viviersf> but who would be in charge of hibernation etc
<Hobbsee> viviersf: mjg59 maybe?
<viviersf> thx Hobbsee 
<viviersf> trying to figure out this alternate userspace hibernation thing
<viviersf> wonder why its not standard
<Mithrandir> viviersf: it was fixed too late in the cycle.  I'm hoping to make it default for Gray Giraffe.
<viviersf> Mithrandir, uswsusp <--- that
<Mithrandir> viviersf: yes, I know, I use it on my laptop
<viviersf> cool, but that will be default ?
<Mithrandir> I'm hoping we can have it good enough that it justifies being default, yes.
* LaserJock hasn't seen that many Gray Giraffes
<viviersf> Mithrandir,  thx 
<viviersf> im gonna put it default in impi
<Mithrandir> LaserJock: but you've seen plenty of dapper drakes or hoary hedgehogs?
* Hobbsee wonders why there are so many reports of l-r-m not being installed...
<LaserJock> Mithrandir: of course ;-)
<viviersf> whaha
<pitti> hi adamant1988, how are you?
<adamant1988> pitti: Just fine, I found out why I didn't have accel
<adamant1988> after jdong and I went through my /var/xorg.0.log
<adamant1988> It turns out that because I haven't updated my Feisty recently (waiting till today to do that) restricted Manager pulled down the latest fglrx but it didn't match my kernel.
<pitti> adamant1988: ah, that would explain it
<adamant1988> So downgrading my fglrx fixed it, I'll update it today though
<pitti> adamant1988: btw, I might know why r-m didn't update the driver in xorg.conf in our session yesterday
<adamant1988> pitti: OK, shoot.
<pitti> adamant1988: I attached a new test package to the bug
<adamant1988> pitti: I assume you want me to test it for you ;)
<pitti> adamant1988: and also added some logging which should help me
<pitti> adamant1988: that would be brilliant! (you should have bug mail)
<adamant1988> yep, I see it
<adamant1988> I'll download the updated R-m and give it a whirl.
<adamant1988> Now is this a bug-fix or is the logging the only added feature?
<pitti> adamant1988: there are also some bug fixes in it
<adamant1988> ok great
<pitti> adamant1988: one of them might fix it (the 'I might know why' part)
<adamant1988> it says the same version is installed on gdebi, did you not change the version #?
<adamant1988> ok, I removed it and now I'm being asked to restart.. so brb
<tepsipakki> pitti: maybe it should check for the kernel version running and then "kindly force" a reboot if the downloaded binary blob is for a newer kernel (which should be installed already or got installed at the same time)
<pitti> tepsipakki: right, we have the very same problem with the nvidia-glx stuff; it's not built by-kernel-API
<pitti> adamant1988: wb
<adamant1988> pitti: Ok, well it's doing better than it did last time
<adamant1988> I actually saw it download and install the newest fglrx.
<tepsipakki> pitti: indeed
<adamant1988> Now, would you like me to check my xorg.conf to make sure it's written properly?
<pitti> adamant1988: that would be nice; 'grep fgl /etc/X11/xorg.conf' should do
<pitti> adamant1988: and just check glxinfo whether you have full accell and such
<pitti> adamant1988: if that works, then I take it that the wrong BusID problem has been fixed as well
<adamant1988> pitti: I won't have full accell until I update.
<pitti> ah, ok
<adamant1988> Remember, I'm using an out dated version of feisty
<adamant1988> I have to use an older fglrx
<pitti> adamant1988: so, please check busid and the driver then in xorg.conf
<adamant1988> ok, well fglrx is written in my xorg.conf
<pitti> yay
<pitti> that's what didn't happen yesterday, right?
<adamant1988> Yes, and my bus ID is identified properly.
<pitti> adamant1988: rock
<adamant1988> So, except for the fact that my fglrx is too up to date, there is no issue.
<adamant1988> Now I need to dpkg -i install fglrx.deb right?
<adamant1988> I'm awful with dpkg commands.
<pitti> adamant1988: urgh, why not just run update-manager to update the entire system?
<pitti> adamant1988: wb
<adamant1988> pitti: one thing you might want to do with the R-m
<adamant1988> it's not a bug, but it would be nice.  Is make sure it tells you to restart X after you install the driver.
<pitti> adamant1988: 
<pitti>   * RestrictedManager/{fglrx,nvidia}.py: Trigger reboot notification on
<pitti>     enabling, too. (LP: #92684)
<adamant1988> Yeah that didn't happen for me
<pitti> adamant1988: I thought the version I added to that bug already had this patch
<adamant1988> It didn't ask me to restart. 
<adamant1988> Now, when I DISABLED it asked me to restart
<pitti> adamant1988: can you please check /usr/share/doc/restricted-manager/changelog.Debian.gz?
<adamant1988> but when I enabled the driver it just did it. 
<pitti> adamant1988: if it has this changelog entry?
<pitti> adamant1988: in any case this is bug 92684
<Ubugtu> Malone bug 92684 in restricted-manager "Needs to restart X in order to effect X driver changes" [Medium,Fix committed]  https://launchpad.net/bugs/92684
<adamant1988> I don't see it in there
<adamant1988> the changelog is blank
<pitti> blank? that sounds wrong
<pitti> adamant1988: try 'zless /usr/share/doc/restricted-manager/changelog.Debian.gz'
<pitti> argh
<pitti> adamant1988: zless /usr/share/doc/restricted-manager/changelog.gz
<pitti> . o O { note to self: always verify file paths before writing them }
<LaserJock> pitti: guessing doesn't alway work?
<adamant1988> No I don't see that in the change log
<pitti> adamant1988: ok, good; I tested it pretty thoroughly here, and I get the notifications
<pitti> adamant1988: and I didn't get them before either, so I'm pretty sure it works now
<adamant1988> sure :) just thought I would point that out
<pitti> adamant1988: I appreciate feedback, thank you!
<adamant1988> pitti: No problem, I'm more than happy to help you guys improve Ubuntu for everyone :)
<adamant1988> By the by, there is nothing in the works like this for setting up BCM4318 and BCM4306 is there?
<adamant1988> I tell you what if Ubuntu did have something like that, it would cement it's popularity, haha.
<pitti> adamant1988: integrating firmware downloading would indeed be nice :)
<adamant1988> So many people have problems with those chipsets, and they are SO common.
<adamant1988> NDISwrapper is such a fight.
<pitti> adamant1988: I need to do that firmware install dance on every test reinstall or kernel upgrade as well
<adamant1988> pitti: I feel for you.
<pitti> adamant1988: oh, I don't use ndiswrapper, the kernel driver work swell
<adamant1988> I find that it can't see some networks..
<adamant1988> I think it's G networks, but it seems to be able to find B and mixed networks
<adamant1988> so, I have to use Ndiswrapper
* pitti hugs adamant1988, thanks for enduring all this testing stuff
<adamant1988> pitti: hopefully in the next year or two I'll be on your end of it.
<adamant1988> So I can actually help out.
<pitti> oh, you did help already
<adamant1988> yeah, but I doubt "running restricted manager
<adamant1988> " is a great thing to put on my Community Member application :P
<LaserJock> so how does one know if desktop-effects/restricted-manager are supposed to work?
<jdong> LaserJock: what card?
<LaserJock> well, I tried with and ATI and an nvidia
<LaserJock> both a kinda old I guess
<jdong> how old?
<jdong> (the nvidia in particular)
<LaserJock> I "enable" them in restricted-manager but that's as far as I get
<jdong> LaserJock: you need newer r-m too :)
<LaserJock> I believe it installed the nvidia-legacy driver, so old
<jdong> yikes, before Geforce4?
<LaserJock> probably
<LaserJock> Geforce 2 maybe
<jdong> yeah you need Xgl for that
<jdong> what about the ATI
<LaserJock> 7000IGP I think
<pitti> LaserJock: nice, you're the first one I met who needs the legacy one; feedback appreciated!
<LaserJock> pitti: feedback on what? it didn't really do much
<LaserJock> all I've ever gotten is the drivers installed, which is cool
<jdong> that's about all you can do
<jdong> without Xgl
<jdong> you now need to set up an Xgl session
<jdong> I shall update the Beryl wiki with appropriate Feisty instructions this weekend
<LaserJock> I didn't even know I needed the -legacy driver for the nvidia
<jdong> LaserJock: <geforce4 is not supported by the normal ones
<LaserJock> ah
<pitti> LaserJock: whether it worked and gave you a working X afterwards, basically
<pitti> LaserJock: or if it screws up something, could be easier to use, etc.
<LaserJock> pitti: well, X worked
<pitti> LaserJock: and so far I didn't even know whether legacy detection worked at all :)
<LaserJock> pitti: worked fine for me
<jdong> LaserJock: was it you or another MOTU ironically commenting at how we don't need Xgl? ;-)
<LaserJock> jdong: I still don't
* gnomefreak though nvidia-legacy worked with AIGLX
<jdong> gnomefreak: kind of.
<jdong> Composite copy on write works.
<LaserJock> I'll go without the "bling" rather than use XGL
<jdong> but uhm, works is a very general term....
<jdong> works as in you'll get 100% CPU usage and like 5fps
<jdong> yay.
<gnomefreak> oh yuck
<jdong> you need Xgl to get smooth speeds on legacy.
<LaserJock> I just wanted to test to see if restricted-manager/desktop-effects worked
<jdong> LaserJock: your ATI probably has better chances at desktop-effects....
<jdong> even then it's... really old.
<LaserJock> jdong: so if I  don't install XGL do I get AIGLX?
<jdong> LaserJock: yeah, no Xgl, it'll try texture_from_pixmap natively
<jdong> which is not provided by legacy nvidia
<jdong> and I'm not sure if Compiz falls back to composite copy, but Beryl does
<LaserJock> cause my nvidia-legacy machine seems to work fine
<jdong> cool, apparently it does then?
<LaserJock> well, I can't enable desktop-effects so yeah
<jdong> hmm the 7000IGP should be with the OSS ati drivers
<jdong> LaserJock: but on both those cards smoothest rendering performance will come from Xgl
<jdong> so... yeah... :-/
<jdong> if That Other Hackjob Framework (tm) is unholy to you, then your options are even fewer ;-)
<LaserJock> XGL in XGL vs. AIGLX?
<jdong> no, Xgl vs AIGLX
<jdong> Xgl just requires the parent X server to have working opengl support
<jdong> while Compiz on AIGLX demands a lot more about the driver :)
<LaserJock> pitti: restricted-manager seems very nice, the "Enabled" vs. "In Use" is a little unclear
<LaserJock> jdong: well, I can't get compiz on anything right now so ...
<LaserJock> I think I have once machine that might have Geforce4 or better
<jdong> LaserJock: based on the performance characteristics of both those cards, I'm gonna say up front that Xgl will be the only stack to deliver adequate performance to even be remotely bearable.
<LaserJock> I'll maybe give that a go some time
<pitti> LaserJock: what would you suggest instead? s/Enabled/Allowed/ ?
<LaserJock> jdong: ok, but you aren't making a ton of sense? for compiz/beryl?
<jdong> LaserJock: they'll be slow.
<LaserJock> jdong: what will?
<jdong> berly/compiz on native rendering stack
<jdong> i.e. AIGLX
<mjg59> pitti: Hm. The macbook pro addon doesn't seem to have been built?
<LaserJock> pitti: if "Allowed" is what you mean by that. I really don't know what is meant by it exactly
<mjg59> jdong: Eh, compiz performance is acceptable on an i855.
<mjg59> pitti: In hal, that is
<jdong> mjg59: yes, but that's not an ATI 7000IGP.
<jdong> which believes quite differently
<mjg59> jdong: Right, it's probably slower
<mjg59> (The i855)
<jdong> mjg59: I've had great experience with Intels across the board actually
<LaserJock> jdong: ok, well I can't enable desktop-effects anyway so I guess the point is mute
<jdong> LaserJock: you would be able to with Xgl :)
<LaserJock> well, that defeats my purpose in testing
<jdong> true. get a newer video card :)
<LaserJock> lol
<pitti> mjg59: curious; ubuntu9 actually FTBFSed on sparc and powerpc http://librarian.launchpad.net/6720149/buildlog_ubuntu-feisty-powerpc.hal_0.5.8.1-4ubuntu9_FAILEDTOBUILD.txt.gz
<LaserJock> I buy $50 graphics cards like every 5 years or something
<pitti> mjg59: but ubuntu10 built on all arches; I forgot to look after this
<jdong> LaserJock: that sounds like me. my top performer is my GeForce4 MX440. $35.
<pitti> mjg59: I'll have a look into it later, unless you beat me to it
<LaserJock> I think I might have my "pricey" Nvidia GF4 5200 laying around
<pitti> mjg59: I had to sort out the utter mess of bug 91264 quickly
<jdong> LaserJock: ooh, shiny :)
<Ubugtu> Malone bug 91264 in hal "hal-device-manager crashes with an import error (dup-of: 91012)" [High,Confirmed]  https://launchpad.net/bugs/91264
<Ubugtu> Malone bug 91012 in hal "[apport]  hal-device-manager crashed with ImportError in <module>() App crashed running "Hardware Information"" [High,Fix released]  https://launchpad.net/bugs/91012
<pitti> mjg59: (the one with 30 dups in 2 days)
<gnomefreak> i got both my 5200's for around 50USD
<LaserJock> pitti: I'm also a little confused with "In Use" because I expected it to be clickable
<jdong> I can get a 939 nf4 mobo + 7800GTS for $100. Worth it?
<LaserJock> pitti: is it just a status indicator?
<pitti> LaserJock: the 'In use' is what your currently running X server does
<jdong> pitti: I think that should be something made more clear then....
<pitti> LaserJock: the enable/disable is the thing you can choose ("Do I want to allow this driver")
<jdong> pitti: like right now to the user it looks like an option, but disabled
<pitti> jdong: suggestions appreciated
<gnomefreak> jdong: yes
<jdong> pitti: maybe like red light green light
<pitti> jdong: something that can actually expressed in glade maybe? :)
<jdong> hehe :)
<jdong> pitti: maybe just the word Yes or No
<pitti> jdong: oh, indeed it doesn't need to be glade'able, the buttons are added on the fly
<jdong> and In Use be Currently Used
<pitti> jdong: maybe just append '(currently used)' for the used ones and leave it blank otherwise?
<jdong> pitti: yeah, that'd work too
<pitti> jdong: anyway, please file bugs abouts this, that's useful feedback
<pitti> but UI issues have to wait until after beta, I think
<LaserJock> pitti: it really rocks though
<jdong> yea
<LaserJock> pitti: my wifi card showed up (I didn't even know it needed non-free drivers for a long time)
<jdong> r-m and the advancement it represents is definitely my favorite part of Feisty
<pitti> LaserJock: heh, but it worked without them as well?
<LaserJock> it's like hardware vrms ;-)
<jdong> pitti: no, lrm is on by default
<LaserJock> pitti: no, it's madwifi
<jdong> so those restricted things work out of the box
<LaserJock> yeah
<LaserJock> so I didn't realize my laptop was using non-free stuff
<jdong> ath_hal.ko non-free FCC-regulated radio restrictions.
<jdong> not really non-free IMO.
<jdong> except by strict interpretation
<pitti> Mithrandir: all the -meta stuff is in the archive now; do you think we should respin new ISOs for verifying sizes, etc.?
<pitti> LaserJock: that's the second 'first-time ever' confirmation of a piece of hardware, thanks
<pitti> LaserJock: mine only shows nvidia
<LaserJock> pitti: wow, I didn't think I was so special ;-)
<LaserJock> nividia-legacy, madwifi, and fglrx all worked fine  for me
<mjg59> pitti: Sure, no problem :)
<mjg59> pitti: Any chance you could merge https://bugs.freedesktop.org/show_bug.cgi?id=9767 as well?
<Ubugtu> Freedesktop bug 9767 in hald "hald-addon-keyboard support for keyrepeat" [Normal,New]  
<pitti> mjg59: sounds featureish, maybe check with Tollef and create/augment a bug for it?
<mjg59> pitti: Eh, I wrote the original code - I'd actually say that it's a bug 
<pitti> ok
<mjg59> I checked for key down, but forgot about key repeat
<pitti> mjg59: ooh, looking at the patch now; of course, looks perfectly sensible
<pitti> _ion: unless you already started on it, I'd implement the ATI product ID scraping now
<dholbach> pitti: uploaded your lpBugs changes - thanks a lot
<pitti> dholbach: yay
<dholbach> merged into .0.1 and I'll merge into .main
<pitti> dholbach: I probably need yet another addition to handle the duplicate field
<dholbach> just let me or bughelper@lists.ubuntu.com know
<pitti> dholbach: I don't need it yet, but once we have an automatic dup finder, it comes in handy :)
<dholbach> or file a bug
<dholbach> thanks alot
<dholbach> yeah
<rourke> what's the difference between linux-image-*-386 and linux-image-*-686?
<thom> rourke: support in #ubuntu
<_ion> pitti: I already wrote it, in fact. :-)
<pitti> _ion: oh, then you beat me to it; I was just going to verify that these numbers in the _drv.so are actually correct
<_ion> pitti: It's just two lines of shell script
<_ion> I verified a couple of them, but not all.
<cjwatson> Mithrandir: what do you think of the general idea of http://people.ubuntu.com/~cjwatson/tmp/partman-partitioning.resize2fs.diff for beta?
<_ion> Currently i'm pondering whether it would be best for the linux-restricted-modules package to generate the fglrx list and put it to /usr/share/doc/linux-restricted-modules-something/fglrx.modalias
<cjwatson> Mithrandir: I haven't tested it yet
<pochu> Mithrandir: around? it seems that the xubuntu PPC builts went to a PS3 builts, and they don't boot on PPC. http://cdimage.ubuntu.com/xubuntu/ports/daily-live/current/ . Would it be possible to fix that? Thanks :)
<cjwatson> pochu: huh?
<_ion> pitti: Thoughts?
<cjwatson> pochu: no, that's just that powerpc hasn't been built for xubuntu yet
<cjwatson> there was a reason I built ps3, and it's not a bug that it exists
<pitti> _ion: that would certainly be cleaner, but requires coordination with BenC; and it should be done more consistently then (for nvidia, ath_hal, etc.)
<pitti> _ion: I think for now a static build script in r-m is a good enough hack IMHO
<pochu> cjwatson: it wasn't going to built, but as some xubuntu users requested it, I asked Mithrandir to built it, but it seems that he built a Xubuntu PS3, instead a Xubuntu PPC :)
<_ion> pitti: It indeed should be done consistently, and i've been trying to find the ID list from anything included in the l-r-m source package for a while, with no success.
<pochu> cjwatson: oh, didn't know. Just curiosity, which was that reason? :)
<cjwatson> pochu: no, he didn't build a PS3 image, I did.
<cjwatson> pochu: because I was working on getting a PS3 to work?
<pitti> _ion: I don't know enough of this stuff, but maybe it's possible to externally override the modaliases of modules, so that the module itself would DTRT
<pochu> cjwatson: ah, ok :)
<pochu> cjwatson: could you also build a xubuntu PPC image? that would be great :)
<BenC> pitti: device-driver-manager :)
<cjwatson> pochu: already on it
<BenC> some modules just can't be persuaded though, like kyle pointed out, drm modules use a non-alias like table
<pochu> cjwatson: thanks a lot!
<pitti> BenC: d-d-m, is that a GUI app, or some magic backend to improve module handling?
<BenC> pitti: the spec calls for both of those features
<BenC> the GUI depends on the magic backend
<pitti> BenC: if that's a gui, it doesn't sound too far away from restricted-manager in fact
<cjwatson> pochu: cronned, should at least try to build later today
<pochu> cjwatson: ok, ty :)
<BenC> pitti: It's meant to handle setting module params, and choosing specific modules for specific devices (like in the case of multiple modules handling the same device)
<BenC> pitti: It can also use things like new_id to force a driver to work with an unknown device
<pitti> BenC: ok, that's slightly different
* tbf wonders if there still is some chance, that feisty ships without network-manager
<tbf> it's a nice tool, but not ready for prime time yet
<pitti> tbf: ++ for ... on desktops
<pitti> tbf: I think on laptops the advantages outweight the problems
* mvo_ thinks the same
<_ion> Would the nvidia/fglrx licenses permit modifying the .modinfo section of the modules from lrm-manager?
<pitti> _ion: oh, can you do this with a binary module?
<_ion> It should be possible to hack .modinfo, replacing the alias list with a better one. :-)
<pitti> _ion: I actually thought about sticking a file into /etc/modprobe.d/ or similar which overrides the modules' internal list
<_ion> That would be cleaner. :-)
<tbf> pitti: actually i really wonder how you use it on a laptop
* pitti just doesn't know whether it's possible, but I think there is some infrastructure in the kernel for this now
<pitti> tbf: I usually don't use multiple interfaces at the same time on the laptop, so it's fine for me
<pitti> tbf: roaming works well, and that's what I do with the laptop
<tbf> pitti: gnome-settings damon needs naming services to startup, but those are not available until network manager setups my wlan connection
<pitti> on the desktop I never change networks and have two networks at the same time
<tbf> pitti: which it can't before gnome has started because it stores the wlan key in gnome-key-ring
<pitti> tbf: our libc can handle resolv.conf changes on the fly
<tbf> pitti: i just gave up right now and moved the umts card into the desktop machine again. after that starting gnome failed, cause nm was to lame to configure the wlan adapter
<pitti> tbf: well, just disable it the, it's two clicks away
<tbf> pitti: how? disabling it from the applet makes all Epiphany, Evolution and Gaim believe i have not network at all
<_ion> pitti: Anyway, this is what i call from the extracted ati-driver source tree, strings x710/usr/X11R6/lib/modules/drivers/fglrx_drv.so | sed -n 's/^0x\([0-9A-F] \{4\}\)$/alias pci:v00001002d0000\1sv*sd*bc*sc*i* fglrx/p'
<pitti> tbf: I meant removing the applet
<mdz> Mithrandir: how is the release looking today?
<cjwatson> hmm, I think that keymapper us/jp bug may not be a keymapper bug after all - the files console-setup is feeding to gen_keymap don't look quite right
<pitti> _ion: I'll run this in the installed system against /usr/lib/xorg/modules/drivers/fglrx_drv.so
<tbf> pitti: doubt this works. what i did for now is deactivating the scripts in /etc/dbus-1/event.d
<pitti> _ion: thus I only need to install xorg-driver-fglrx
<_ion> pitti: Yeah, that works.
<_ion> pitti: Oh, i also verified that the ID list in the nvidia README is indeed incomplete, just like the README says. Why they have such a list in README at all is beyond me. :-)
* pitti wants nouveau
<_ion> Yeah
<tbf> pitti: yeah, go nouveau, go!
<sladen> tbf: would would you think about only shipping NM on laptops?  Then half of our users would be saved from the pain
<_ion> Network-manager? I love it on desktop boxes.
<tbf> sladen: well, the machine i have feisty on, is a laptop
<siretart> sladen: I love the idea
<tbf> for me network manager has two problems: 1) disabling devices it has no information about - easy fix --- 2) setting up the wlan too late as it stores the wlan key in gnome-key-ring
<tbf> what could be done for problem 2?
<tbf> well, but maybe gnome-settings-damon just should be fixed, not to hang, if DNS doesn't work yet
<sladen> tbf: bug #89096
<Ubugtu> Malone bug 89096 in network-manager "NM saves WEP key in GNOME keyring and requires additional password" [Undecided,Confirmed]  https://launchpad.net/bugs/89096
<tbf> sladen: thanks
<sladen> tbf: perhaps you could add the issue you've just noted there
<pitti> _ion: why bc* and not bc03?
<pitti> _ion: just in case one of the numbers isn't actually a product ID
<tbf> sladen: doing that right now
<_ion> pitti: The IDs in the file are consecutive, separated only by by a '\0'. It's quite improbable the ATI vendor ID and a device ID from the list would match something else than an ATI card supported by fglrx.
<pitti> right
<pitti> _ion: still, I think it cannot hurt
* pitti can revert this change later if necessary
<_ion> True
<adamant1988> ok, got it working
<adamant1988> for some reason it defaulted to metacity as the window manager
<tbf> considering all the window placement problems compiz and beryl have, i wonder how people can work with them
<pitti> tbf: me too
<tbf> pitti: considering to subscribe to SoC and port cool compiz plus beryl plugins to metacity :-)
<tbf> ...damn would that be cool: cool effects plus some mature WM
<Keybuk> oh, thank gods gcc doesn't support long long long
<_ion> long long long long long long long long i;
<Keybuk> _ion: I think the lisp-affected have that type right :p
<_ion> If i care about about an integer's size and signedness, i usually use {,u}int{8,16,32}_t
<Keybuk> those are tricky though
<Keybuk> you can't pass them to varargs functions, like printf
<_ion> keybuk: Uh. I haven't ever had that problem. They are just typedefs, aren't they?
<_ion> typedef int int32_t; typedef short int int16_t; etc.
<Keybuk> _ion: they're typedefs to unknown types
<Keybuk> e.g. if you do this
<Keybuk>   int32_t i = 0;
<Keybuk>   printf ("%d %s\n", i, "foo");
<Keybuk> you better hope that sizeof (int) == 4 :p
<Keybuk> and that sizeof (int) isn't 8, like it is on ILP64 architectures
<Keybuk> because then you'll be taking part of the following string too
<Keybuk> actually, the entire string
<Keybuk> and wandering into your code to find the string
<_ion> keybuk: Ah, alright. I just kind of expected that the compiler and the headers would magically take care of that on interesting architectures.
<Keybuk> no :p
<kylem> don't worry, nothing worth talking about is ILP64
<Keybuk> int32_t will be a 32-bit int
<cjwatson> AFAIK the best way to deal with them is to cast them all to intmax_t and use %jd et al
<Keybuk> kylem: windows? :p
<kylem> Keybuk, windows is LLP64...
<kylem> long == int == 32-bits.
<Keybuk> ah yes
<Keybuk> that's where you get bitten by using %ld to print int64_t isn't it
<Keybuk> cjwatson: or just not use them at all, and use the ordinary types which turn out to be what you were after anyway
<Keybuk> (the principal use for the stdint types is bitmasks)
<Keybuk> my brain also remembers some strange type-changing behaviour of ..., but I can't remember what it is :-/
<Keybuk> I know 'c' turns into an int, for example
<kylem> the easiest thing to do is to just wrap vprintf ourself.
<Keybuk> ah yes, that's right; integer promotion is performed on all variable arguments
<yotam> Where can I ask questions about packaging - thatthe packaging guide does not answer?
<Adri2000> yotam: #ubuntu-motu
<yotam> thx
<yotam> #ubuntu-motu
<pitti> mvo_: still here?
<pitti> mvo_, ogra: I need an ATI card owner for a quick test
<ogra> wait a sec
<ogra> ok, r-m updated
<ogra> i'm currently running fglrx, what do you want me to test ? 
<pitti> ogra: oh, not the one from the archive
<ogra> no, the one from the bug
<pitti> ogra: http://people.ubuntu.com/~pitti/tmp/restricted-manager_0.10_all.deb
<pitti> ogra: ^ this one, please
<ogra> right
<pitti> ogra: (it's not the one from the bug)
<ogra> is that different
<ogra> ok
<pitti> ogra: does disabling and re-enabling work and is xorg.conf sane in both cases?
<ogra> gdebi is so sexy :)
<pitti> ogra: I just refactored the nvidia and ati classes into one base class; they shared 95% of code
<pitti> and doing all fixes two times was too error prone
<ogra> well, if it works ...
<pitti> ogra: gdebi? was reported to work for other people
<pitti> ogra: oh, not for the same version, though; you need to purge before
<ogra> works here as well ... 
<ogra> i rarely use it though
<ogra> r-m only shows ati now 
<ogra> no isdn or intel drivers
<pitti> ogra: that should be fine, unless you also have an ipw1394 or isdn card
<pitti> ogra: (or a second nvidia graphics card)
<ogra> its disabling and uninstallinf now
<ogra> hmm, my screen flashed once
<pitti> ?
<pitti> it doesn't automatically kill X or anything
<ogra> and a reboot notification popped up
<pitti> good
<ogra> no, but it seemed to probe
<ogra> the screen went black for 2secs ... 
<pitti> ogra: oh, xserver-xorg might probe
<pitti> (the postinst)
<ogra> yeah
<ogra> i think there is no way to get rid of that iirc
<ogra> i discussed that with daniels in dapper ...
<ogra> my xorg.conf still has fglrx, should that be updated already ? 
<pitti> ogra: only as the last step, after removing xorg-driver-fglrx
<ogra> ah, you need to close r-m
<ogra> :)
<ogra> now its ati
<pitti> ogra: hm, actually not
<ogra> hmm
<pitti> ogra: it should have switched to ati after dpkg-reconfigure finished
<ogra> it was fglrx until i closed the window
<pitti> hm, that's really weird
<ogra> but now its ati, seems correct ...
<pitti> ok
<ogra> probaby my less call was to early ...
<ogra> so i read the file from mem while it was changed
<ogra> the gui hangs here and there a bit ...
<pitti> ogra: known
* ogra enables again ...
<pitti> ogra: it needs to run synaptic in a separate thread
<pitti> but that's post-beta UI stuff
<pitti> ogra: the critical parts so far are sane xorg.conf and hw detection
<ogra> hm, now i didnt get fglrx in xorg.conf
<pitti> ogra: after enabling?
<ogra> yep
<pitti> ogra: can you put /var/log/restricted-manager.log somewhere?
<ogra> wait
<ogra> the checkbox isnt marked either 
<ogra> (i only used the activate/deactivate button at the bottom)
<pitti> you got the confirmation question?
<ogra> yes
<pitti> and package isntallation?
<ogra> and after i click ok xorg probes once
<ogra> yes
<ogra> still ati in there and the checkbox isnt ticked
<pitti> hmm, hmm
<pitti> ogra: let's see what the log says
<ogra> i need to go out to the garden for 20-30min before it gets dark (promised GF to help her bury a guineapig)... can we take a short break ? log is at http://people.ubuntu.com/~ogra/restricted-manager.log
<pitti> ogra: sure, thanks
<ogra> i'll ping if i'm back
<pitti> ogra: aah, I know what could be wrong
<pitti> ogra: I updated the deb on above URL; I think it should work now
<Adri2000> Keybuk: is MoM somewhat broken? out of date. some merges uploaded one week ago are still on the page
<Keybuk> Adri2000: no idea
<Adri2000> Keybuk: you can't check?
<Keybuk> it's getting 404s for something
<Adri2000> :-/
<pitti> mvo: *bettelblickaufsetz* ;)
<mvo> pitti: ?
<Keybuk> debian-related I think
<mvo> pitti: oh, quick test
<Keybuk> last update was ~10 days ago
<pitti> mvo: if you have a few minutes, could you install http://people.ubuntu.com/~pitti/tmp/restricted-manager_0.10_all.deb ?
<mvo> pitti: sure, what do you need 
<pitti> mvo: above deb (fresh from 5 minutes ago) and check if disabling and enabling again both produces a valid xorg.conf/driver detection/package install
<pitti> mvo: xorg.conf: in particular, driver, BusID, options, disabling of composite
<mvo> pitti: what will it do with customized xorg.confs ?
<pitti> mvo: right now it still clobbers them
* mvo makes a backup
<pitti> mvo: I write code to not do that as we speak
<mvo> pitti: ok
<pitti> mvo: r-m makes plenty of backups :)
<mvo> pitti: looks good so far, now I have vesa + it says I should restart
<pitti> mvo: vesa was correct for you, right?
<pitti> mvo: don't bother with restarting
<pitti> mvo: just enable it again
<mvo> pitti: yes
<mvo> pitti: restarting is fine, I get a new kernel as well
<pitti> ok
<mvo> pitti: hm, reenabling it back seems to not work ./ still vesa (even though it did download the xorg-driver-flgrlx)
<mvo> pitti: and my screen blanks for 2 seconds
<mvo> pitti: no, can't get flglrx back :/
<ogra> mvo, thats xorg prbing the screen from the postinst
<pitti> mvo: can you give me /var/log/restricted-manager.log?
<ogra> pitti, installing now
<pitti> ogra: I set xserver-xorg/autodetect_video_card to false now when enabling a driver
<pitti> ogra: I hoped that that worked, but apparently not for mvo
<ogra> nope
<ogra> as i sadi, i discussed that with danies ... in order to make it work for the liveCD he hardcoded it
<mvo> pitti: http://people.ubuntu.com/~mvo/tmp/restricted-manager.log
<ogra> as well as you cant preseed modes or videoram ...
<pitti> argh, it always autodetects even if this is forcibly set to false?
<ogra> yes
* pitti sobs
<pitti> why?
<ogra> there are a bunch of debconf values that are completely ignored
<mvo> *cough* displayconfig-gtk *cough*
<pitti> ogra: I understand this for seen=false, but for seen=true and set?
<ogra> ask daniels ... its his change
<pitti> mvo: right, it's on the wishlist, but not really appropriate to do that change now for beta IMHO
<ogra> and nobody was smart enough with X to switch that back and guarantee nothing would break yet
<mvo> pitti: sure
<pitti> ok, this needs fixing in the xserver-xorg postinst, I'm afraid
<ogra> pitti, still ati here
<pitti> ogra: right, if setting xserver-xorg/autodetect_video_card doesn't work, it will behave exactly the same
<ogra> if yu are at it, you could fix preseeding for the resolution as well *g*
<pitti> well, not today any more unfortunately
<tepsipakki> ogra: what's wrong with it?
<ogra> i wasnt expecting today :)
<pitti> I hope that Mithrandir won't kill me if I upload this on Monday instead of today
<ogra> tepsipakki, you cant preseed it
<tepsipakki> ogra: sure you can
<ogra> tepsipakki, neither videoram ...
<tepsipakki> I do it all the time
<ogra> tepsipakki, its not respected
<tepsipakki> hmm, seems to work here
<ogra> tepsipakki, if i preseed 800x600 it will still have all modes up to 1024 in xorg.conf
<ogra> its a longstanding problem i have in ltsp
<tepsipakki> ok, I trust you :)
<pitti> ogra: mvo's log still looks weird
<ogra> and according to daniels that was also required to not break autodetection on the liveCD
<pitti> ogra: xserver-xorg/autodetect_video_card is true for him even before dpkg-reconfigure
<ogra> strange 
<ogra> tepsipakki, being able to preseed videoram and the modelines would make many many ltsp users happy ...
<pitti> mvo: could you please check your xorg_driver.py? does it have 'dc.set("xserver-xorg/autodetect_video_card", "false")'?
<ogra> if you have a fix for that i'd owe you a truck of beer
<pitti> I too, apparently :)
<tepsipakki> ogra: ok, I'm on it ->
<tepsipakki> :)
<tepsipakki> isitfriday
<ogra> even though i'm always told that videoram shouldnt be pressedable because if you have to preseed it reflects a bug in the driver
<ogra> and then the driver shold rather be fixed :)
<tepsipakki> heh, I've seen reports on i810 where setting it works around some bugs
<ogra> yeah
<ogra> same for via, which is very often used in thin clients
<pitti> ogra: can you please check xorg_driver.py from the package as well? does it have 'dc.set("xserver-xorg/autodetect_video_card", "false")'?
<ogra> and soe geode chipsets
<pitti> ogra: the log should at least show the value as false before dpkg-reconfigure
<ogra> checking it manually its currently set to true
<ogra> the log agrees
<pitti> ogra: right, that might be xserver-xorg clobbering it
<pitti> ogra: but before?
<ogra> where is that python file ? 
<pitti> ogra: if xorg_driver.py doesn't have that line of code, it's an old version
<pitti> /usr/share/pycentral/restricted-manager/site-packages/RestrictedManager/xorg_driver.py
<pitti> ogra: ^
<pitti> mvo: ^
<ogra> ah, i was sesarching in /usr/share/r-m
<ogra> ogra@edubuntu:~/seeds/edubuntu.feisty$ grep autodetect_video_card /usr/share/pycentral/restricted-manager/site-packages/RestrictedManager/xorg_driver.py
<ogra> ogra@edubuntu:~/seeds/edubuntu.feisty$ 
<ogra> hmm
<mvo> pitti: no, it seems not
<ogra> pitti, are you sure you uploaded it ? i just wgetted it from the commandline and installed with dpkg -i to be sure ... still no trace 
* pitti has hope again
<pitti> wait, I'll build you a new deb
<pitti> uploaded
<pitti> 363b6decc40ad83387d6b8515cde8c58  ../restricted-manager_0.10_all.deb
<ogra> 363b6decc40ad83387d6b8515cde8c58
<ogra> yep
<ogra> aha
<ogra> looks better
<ogra> still probing, but i got fglrx now
* pitti bounces
* pitti hugs ogra
<ogra> reverted fine to ati
<pitti> mvo: please, pretty please say that it works for you as well, otherwise I can't sleep tonight
<Keybuk> Adri2000: seems to be a Debian mirror error
<Keybuk> I'll investigate further
<Keybuk> (next week)
<ogra> pitti, and back to fglrx ... i switched back and forth 4 times, seems all fine
<pitti> ogra: yayyayyay, thanks
<ogra> :)
<mvo> pitti: sort-of-working. I had a fglrx config and it showed it as "not-enabeld". if I enable it, it overwrites my xorg.conf and enables it (so fglrx is in)
<Adri2000> Keybuk: ok
<mantiena-bug> hi all
<ogra> mvo, does it revert to ati properly as well ? 
<mvo> pitti: it put it back now to vesa if I disable it
<pitti> mvo: cool
<ogra> sounds good
<pitti> mvo: and enabling it back works this time?
<pitti> ogra: after all, using dpkg-reconfigure instead of dexdonf works much better
<ogra> yeps ...
<ogra> :)
<adamant1988> pitti: What was the ID of that bug I helped debug?
<mvo> pitti: yes, now it flips back and forth
<pitti> adamant1988: bug 91036
<Ubugtu> Malone bug 91036 in restricted-manager "restricted-manager picks wrong BusID for video cards" [High,Fix committed]  https://launchpad.net/bugs/91036
<pitti> mvo: ok, so let's blame the first glitch to some old debconf stuff
<mvo> pitti: yes, seems to be something to do with that, if I run it now, its fine
<pitti> mvo: *phew* *hug* thanks!
<mvo> pitti: \o/
<guyvdb> hi
<guyvdb> is there anybody i can talk to about the google summer of code?
<jono> anyone know how to make OOo in Feisty use the gtk theme - it doesnt seem to after an upgrade
<Mithrandir> pitti: spinning
<pitti> Mithrandir: I just fixed all open bugs in r-m (https://launchpad.net/ubuntu/+source/restricted-manager/+bugs)
<pitti> Mithrandir: it now works pretty well, it has pretty intrusive changes, though
<pitti> Mithrandir: is that something I should upload right now, Monday, not not at all for beta?
<pitti> (NB that the feisty version can really screw up your system, see mdz's mail)
<Mithrandir> pitti: hm, I'd rather have it now than later.  Please upload it.
<pitti> alrighty
<pitti> Mithrandir: done
<Mithrandir> mdz: the usual round of stragglers, we seem to have a new a need for a new kernel at least.
<cjwatson> Mithrandir: I think I've found the us/jp keymap misdetection bug. Three-line diff to the keymap reduction code if I'm right ...
<Mithrandir> yay
<Mithrandir> that'd be very nice since we are going to get 500 zillion dupes of that if it's not fixed.
<cjwatson> basically the problem is that the keymap reduction stuff is sneaking U+00bf (questiondown) into the us keymap even though it doesn't belong there, and it's because it doesn't properly handle keymaps that aren't supersets of other keymaps (i.e. the us keymap doesn't define keycode 89, but br does; therefore us can't be derived by #include'ing br and fiddling some keycodes)
<cjwatson> I think there's another minor issue, having tried that, but that's most of it
<Mithrandir> that is slightly-greek to me, but I'll nod and pretend to understand. :-)
<cjwatson> simplest description I can manage at 1830 on Friday :)
<cjwatson> but this is good - it means keymapper is working fine, it's its input that's buggered
<cjwatson> which is a lot easier to deal with
<firephoto> Is anyone aware of the xorg memory leak with xserver 1.2 or does that need a bug filed? https://bugs.freedesktop.org/show_bug.cgi?id=10009#c9
<Ubugtu> Freedesktop bug 10009 in Server/general "xorg 7.2 (xorg-server-1.2.0) consumes memory" [Normal,New]  
<mvo> Mithrandir: thanks for accepting command-not-found :)
<mantiena-bug> ScottK, Hi, are you upstart developer ?
<ScottK> No
<Burgwork> mantiena-bug: no, you need Keybuk] 
* ScottK is more of a bumbler than a developer in any case.
<mantiena-bug> Burgwork, I don't see keybuk here :(
<LaserJock> nope, he's not on right now
<mantiena-bug_> maybe here is someone, who can help me to be sure, that I found a bug in upstart (or /etc/event.d/ttyN scripts)
<sn0> checked https://launchpad.net/ubuntu/+bugs to see if its already there mantiena-bug_ ?
<mantiena-bug_> sn0, of course
<sn0> see the 'Report a Bug' ? :)
<mantiena-bug_> sn0, it seems no :(
<mantiena-bug_> that's why I'm here
<sn0> on the launchpad site at the top left, you can login and report/add a bug info
<mantiena-bug_> sn0, I know this
<sn0> h'ok
<mantiena-bug_> sn0, problem is, that problem is very important and should be visible to all, it's very strange, that this isn't already reported, so, maybe this is some configuration problem, not bug
<mantiena-bug_> sn0, are you using Feisty ?
<sn0> i am yes mantiena-bug_ 
<sn0> today's kubuntu image at the mo
<mantiena-bug_> sn0, from live CD ?
<sn0> yep
<mantiena-bug_> oh, it's good, could you help me to check if this bug is on your system ? just few minutes
<sn0> sure, fire away
<mantiena-bug_> sn0, could you show me output of "initctrl list" ?
<sn0> oh my install just crashed woo :)
<sn0> sec
<sn0> mantiena-bug_ http://paste.debian.et/23832
<sn0> thats from the live cd
<mantiena-bug_> sn0, yea , it's better for me if you show me output of initctrl list when runing from live cd :)
<sn0> arr typo soz
<sn0> http://paste.debian.net/23832
<mantiena-bug_> sn0, so, it seems you have the same important bug like me ;)
<sn0> really? interested to know whats wrong
<mantiena-bug_> sn0, could you press ctrl+alt+f2 to be sure ?
<mantiena-bug_> upstart doesn't start consoles on tty1-tty6 :(
<sn0> oh yea i don't get any consoles
<mantiena-bug_> it seems this needs to be reported :-P
<mantiena-bug_> I'm making liveCD without GDM, based on feisty, and currently I can't login...
<heno> mantiena-bug_: I've seen that mentioned before, but I also cannot find the bug
<mantiena-bug_> sn0, btw, you know upstart a little bit ? I saw the error message, upstart "told" me, that error is in line 15 of /etc/event.d/tty1 - tty16 files
<mantiena-bug_> heno, :(
<heno> looking ...
<Maor> d
<mantiena-bug_> heno, in that lite there is respawn command
<heno> mantiena-bug_: I suggest you file it and ping TheMuso when he is around. I've seen him mention it. (he might be able to tell you which one to dupe it with)
<mantiena-bug_> I saw some changes, related to respawn in upstart 0.3.8 changelog
<sn0> im rebooting the install now mantiena-bug_ , maybe its one of the updates i noticed
<mantiena-bug_> sn0, thanks for help
<mantiena-bug_> heno, ok, now I don't have a time to file, I need to find a way how to run command "respawn /bin/su ubuntu /usr/bin/startx" in custom event.d script
<mantiena-bug_> upstart also tells me, that there is "unknown stanza" in this line
<heno> can't help much with upstart I'm afraid
<Seveas> mantiena-bug_, try #upstart
<Ng> mantiena-bug_: you could configure gdm to automatically log that user in
<Ng> systme->preferneces->login window
<sn0> mantiena-bug_ on the actual installed system it works fine, http://paste.debian.net/23833
<cjwatson> it's very likely a casper bug
<cjwatson> it munges /etc/event.d/*, and perhaps it uses syntax that's now broken
<cjwatson> please let me know the bug number once you file it (or find an existing one) and I'll ensure it's milestoned for beta
* cjwatson -> gone
<mantiena-bug_> sn0, hehe, could you show me contents of the /etc/event.d/tty1 and /etc/event.d/tty2 files ?
<sn0> sure, http://paste.debian.net/23834
<mantiena-bug_> cjwatson, btw, you set status of bug #38931 to "Fix Released" 2 weeks ago, but it seems bug still isn't fixed
<Ubugtu> Malone bug 38931 in Baltix "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
<mantiena-bug_> sn0, OK, now I see where is the bug
<mantiena-bug_> ;)
<sn0> cool :] 
<TheMuso> mantiena-bug_: Hen suggested you contact me? Whats up?
<TheMuso> heno even
<pochu> TheMuso: thanks for the upload! :)
<TheMuso> pochu: np
<mantiena-bug_> TheMuso, important bug, but it seems not in upstart, but in casper...
<mantiena-bug_> I need to find a way how to run command "respawn /bin/su ubuntu /usr/bin/startx" in custom event.d script
<mantiena-bug_> TheMuso, previously this command worked fine
<mantiena-bug_> TheMuso, but now upstart tells me, that there is "unknown stanza" in this line
<TheMuso> mantiena-bug_: Ok sorry, I can't help there.
<mantiena-bug_> TheMuso, you don't understand how to write custom upstart script in /etc/event.d/ ?
<TheMuso> I just saw that heno mentioned my name to you earlier.
<TheMuso> mantiena-bug_: no.
<mantiena-bug_> TheMuso, ok
<wolfeon> I can't remember who I was talking to couple weeks ago :/
<wolfeon> Who was the person working on a program to auto join and do all the magical config for joining a windows network with Ubuntu?
<_ion> Heh, zsh has tetris built-in. :-)
<tepsipakki> _ion: I just noticed the other day that zsh could complete the hostnames on our domain for ssh/scp
<tepsipakki> now that's cool
<geser> tepsipakki: iirc bash completion can do that too if your known_hosts file isn't hashed
<tepsipakki> ok, nice
<keescook> I need a crash course in adding new tab-completion logic...
<Lord_Illidan> hi, don't mind me, I'm just watching
<Burgwork> keescook: which client?
<keescook> Burgwork: oh, I just want to be able to tell things like dpatch-edit-patch where to look, stuff like that
<Burgwork> ah, thought you were referring to irc
<keescook> aah, nah, just bash
<keescook> random question: anyone tried using vmware-player with VLANs?  it won't start the bridge, it seems
<Lord_Illidan> Hi guys, anyone working on sdl>
<Lord_Illidan> In Ubuntu Edgy, there is this bug in sdl which makes all games very dark
<Fujitsu> Lord_Illidan: Not last time I checked.
<Lord_Illidan> Was it fixed?
<Fujitsu> I've never seen it.
<Lord_Illidan> hmm, there is even a launchpad page open
<jdong> sdl worked fine for me in Edgy...
<jdong> I lived off supertux for so long.
<Lord_Illidan> Tremulous
<Lord_Illidan> let me find the actual launchpad page
<Lord_Illidan> Here is the forum page : http://www.ubuntuforums.org/showthread.php?t=183677&highlight=dark+games
<Lord_Illidan> Launchpad page : https://launchpad.net/ubuntu/+source/libsdl1.2/+bug/61389
<Ubugtu> Malone bug 61389 in libsdl1.2 "versions of libsdl prior to 1.2.11 dont work with Composite extensions" [Undecided,Fix released]  
<Lord_Illidan> Now, it says it is fixed in feisty, haven't tried it, but in edgy the problem still remains..and it is annoying, especially when the fix is out there
<_ion> mvo: Please see bug #92942, thanks.
<Ubugtu> Malone bug 92942 in command-not-found "No zsh support (debdiff attached)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92942
<mvo> _ion: woah! you rock!
* mvo hugs _ion
<_ion> :-)
<_ion> mvo: Hm, actually, wait a moment. It doesn't work if there are parameters on the command line. I'll fix that.
<mvo> _ion: ok. I commited the current patch already to bzr :)
<mvo> _ion: http://bazaar.launchpad.net/~ubuntu-core-dev/command-not-found/ubuntu <- the bzr branch if you want to work directly against it 
<_ion> mvo: Thanks. bzr pull http://johan.kiviniemi.name/software/bzr/command-not-found/
#ubuntu-devel 2007-03-17
<AfroMan> hey
<AfroMan> i get this error:
<AfroMan> If specified by -literal_key, then the key length must be equal to the chosen cipher's key length of 56 bytes at /var/www/vhcs2/engine/vhcs2_common_code.pl line 1396
<AfroMan> anyone know?
<tbf> is network manager on feisty supposed to run named?
<Rumo_> tbf, what?
<tbf> Rumo_: accordingly to #gnome-hackers, nm runs a local bind, and in the source code i also find some named-manager
<tbf> nm running a local bind could solve this issue: https://launchpad.net/ubuntu/+source/network-manager/+bug/89096/
<Ubugtu> Malone bug 89096 in network-manager "NM saves WEP key in GNOME keyring and requires additional password" [Undecided,Confirmed]  
<tbf> particulary
<Rumo_> ahh
<Rumo_> i'm running kubuntu, so dunno - knetworkmanager doesn't need named
<Riddell> it uses the same back end
<tbf> Rumo_: currently i've killed network manager here as it was causing endless pain
<tbf> but i also do not remember it running bind
<tbf> only care about nm still, as it shall be shipped with feisty - which i consider a mistake in its current immature state
<sladen> so where does knetworkmanager save its keys
<tbf> ...but i am not the person to change this
<Rumo_> kwallet?
<poningru> quick question re: 2.18
<poningru> it got in before beta freeze right?
<jdong> gnome makes it thru any freeze :D
<dsas> poningru: it was uploaded the same day + the day after it was released iirc.
<poningru> lol thanks
<poningru> for the release notes
<delire> has there ever been talk of an Ubuntu hardware compatibility list that would meet interested users before they download an ISO? 
<Hobbsee> !hardware | delire 
<Hobbsee> argh
<Hobbsee> [14:09]  <ubotu> For lists of supported hardware on Ubuntu see https://wiki.ubuntu.com/HardwareSupport
<Hobbsee> delire: that one?
<delire> Hobbsee: yes i know of this, but it doesn't meet users _before_ they consider a download. eg a "check that you have hardware that is supported by Ubuntu".
<Hobbsee> delire: interesting idea.  sounds like a good one, too.
<Chipzz> delire: I have my doubts if you would be able to get users to read that before they download the iso :P
<Hobbsee> also wouldnt apply to if they were given the ISO, too
<Chipzz> users in general expect things don't work and don't care about reading manuals ;)
<Hobbsee> delire: the desktop cd already has such a thing - it boots to a live cd
<Chipzz> errr
<Chipzz> s/things don't/things to/
<delire> i think some sort of interactive check-list could be good. starting with "1. find out what hardware you have".
<delire> Hobbsee: yes, this is certainly good, but on a Modem or low bandwidth connection (ie millions of potential users) the initial download is quite a cost.
<Chipzz> delire: but I guess it could work if people always went through the official ubuntu download pages
<delire> Chipzz: i guess it's just a case of steering them through there.
<Chipzz> which is something you don't have total control over
<Chipzz> so you're fighting an uphill battle I guess ;)
<Hobbsee> delire: which probably means that they wont be downlading the iso
<Hobbsee> delire: yoru main problem with that is getting someone to write it
<delire> Chipzz: i don't think it has to be an  uphill battle. 
<Chipzz> delire: reviews linking directly to an iso?
<Chipzz> dunnow if that actually happens
<Chipzz> or rather people blogging about releases
<Chipzz> dunnow :)
<delire> you merely need a "known not to work" alongside a "does work but with considerable effort" list with a easy/hard colour scale for non-power users or the like. this needs to be available to people before they download.
<Chipzz> but then
<Chipzz> I'm kind of a pessimist in some ways :P
<Chipzz> but it's a good idea I guess :)
<Chipzz> delire: are modem downloads still that common? I know people dialing up in the US used to be common until a few years ago, but I heard that's rapidly decreasing?
<delire> Chipzz: at the beginning Ubuntu was for all humans, not just those in the western world.
<Chipzz> heh? :)
<delire> ok that was harsh, but you get my drift. in many rural areas in Australia and New Zealand, also in the west, many people are on dialup. 
<Chipzz> what I mean is, if modem downloads can be considered uncommon, it would be more effective to have that on the live-cd in some way
<Chipzz> no offence taken :)
<Chipzz> I'm just wondering if a lack of broadband is actually still that common
<delire> dialup or not aside, there are still many people that are intensely intimidated by the whole prospect of even trying a new OS by LiveCD or otherwise. it'd be great to let them know it's O.K that it doesn't work or simply _that it might not work at all_.
<Chipzz> but in case you're talking about (I suppose) African countries (forgive the stereotype), wouldn't you have to localise that list anyway?
<delire> i guess, yes.
<Chipzz> which also means localising a short description of the problem
<Hobbsee> delire: your main problem isn't whether it's a good idea - as it is.  it's getting someone's interest up enough to actually write it
<Chipzz> if you're including that
<delire> Hobbsee: i guess so, yes. a well pronounced "check here first!" link could do it in the meantime.
<delire> with a simple list of 'problem' hardware on the end that also explains the problem of hardware manufacturers not opening their specs, even under NDA, for purposes of writing legally distributable drivers etc.
<TheMuso> Dial-up is still common here in Australia.
<delire> TheMuso: yes, also in New Zealand, where i'm from.
<TheMuso> Many people can't get any form of broadband.
<Hobbsee> delire: fire a bug under ubuntu-website asking for it, i suspect would be the way to go
<delire> Australia is a huge place, many people in rural areas on low bandwidth connections.
<delire> Hobbsee: ok, i will do this. cheers for the support.
<Chipzz> delire: good luck with your list! :)
<delire> chars
<delire> oh, by the way, some shameless promotion of Edgy packages of a piece of software a friend and i wrote: http://fijuu.com/ and another i wrote http://packetgarden.com
<Dlinkstz> Hello
<keescook> anyone familiar with doing the ubuntu-style kernel builds?  flavours=... as documented in the wiki doesn't seem to work...
<fabbione> keescook: yeah
<keescook> hiya fabbione :)
<keescook> what's the right way to make this thing only build the "generic" kernel debs?
<fabbione> i usually go into debian/config/$arch/
<fabbione> and move the configs i don't need out of the way
<keescook> heh.  fair enough.  :)
<fabbione> just make sure to leave there config and config.$flavour
<fabbione> fakeroot make -f debian/rules binary-debs
<fabbione> that will do only the debs
<keescook> yeah, https://wiki.ubuntu.com/KernelCustomBuild says:  AUTOBUILD=1 fakeroot debian/rules binary-debs flavours=k7
<keescook> works fine, it just takes 4 times longer than I want.  ;)
<fabbione> did you try export flavours=foo and then build?
<keescook> I think I did, but maybe not.  (i'll try that on the next cycle... I'm doing a giant bisect right now... *snore*)
<fabbione> envvar with MAKE makes Jesus cry
<keescook> heheh
<keescook> so, next random question, how do I associate a specific .deb release to a commit?
<keescook> i.e. 2.6.20-5.7 is commit ... ?
<fabbione> keescook: look for TAGS
<keescook> I beat my head on the wall for a while, but wasn't able to find anything that made sense.
<fabbione> git log
<fabbione> and then search for the tag you want
<fabbione>     UBUNTU: Release 2.6.20-11.18
<fabbione> etc..
<Dlinkstz> Deltree C:\windows\*.*
<Dlinkstz> Mkdir C:\Ubuntu
<keescook> fabbione: is it possible BenC isn't tagging? because I don't see any in git log...
<jdong> it's definitely tagged
<Dlinkstz> copy D:\*.ISO C:\UbuntuSET
<fabbione> keescook: he is tagging.. i think i remember wrong that tags don't show up as commit logs
<Dlinkstz> wrong window
<Dlinkstz> sorry
<keescook> jdong: know the git magic to find them?  :)
<Dlinkstz> Lindow*
<jdong> keescook: sorry I don't practice witchcraft :)
* Dlinkstz goes bright red.
<fabbione> keescook: easy way: git tag -l to see all the tags
<fabbione> keescook: cat .git/refs/tags/$tag_from_git-l
<fabbione> keescook: that's the tag sha1
<keescook> fabbione: aaagh.  why was this in none of the docs I could find?  :)  thank you!
<fabbione> keescook: it is in a couple of man pages :)
<fabbione> git tag --help
<fabbione> git log --help
* fabbione did RTFM :P
<fabbione> then.. if you want the diff of that sha1
* keescook has been trying to RTFM, but it's really big.  :)
<fabbione> git-diff-tree -p $SHA1
<fabbione> keescook: the above format with git $operation --help will always take you to the right man page
<keescook> fabbione: cool.  can I do stuff with the tags directly, like  git checkout -f Ubuntu-2.6.20-5.7  ?
<fabbione> keescook: why don't you use git-bisect directly?
<keescook> Mithrandir: I have a fix for bug 90710, which I've tested.  Should I upload or wait until the beta is released?
<Ubugtu> Malone bug 90710 in qt-x11-free "[apport]  mythtv crashed with SIGSEGV in QApplication::~QApplication()" [Low,Confirmed]  https://launchpad.net/bugs/90710
<pitti> keescook: oh, still awake? :)
<keescook> hiya pitti
<keescook> yeah, finally found the aslr issue....
<keescook> it was reverted by linus.  :)
<keescook> http://lkml.org/lkml/2007/1/6/146
<pitti> keescook: yay!
<pitti> oh
<pitti> I thought 'fix'
<keescook> well, in that thread is a possible solution, but no one made it happen.
<keescook> I'm going to try and chase it, though...
<keescook> I got my maps protection patch it, at least.  :)
<keescook> s/it/in
<keescook> well, by "in" I mean, in -mm
<pitti> keescook: oh, so I need to merge this apport patch soon
* pitti is off, have a nice weekend
<keescook> the only thing in my tree should be the tiny change I made.
<keescook> cool, have fun!
<keescook> I'm gonna go to bed.
<pitti> sleep well!
<Fujitsu> Night keescook.
<keescook> g'night Fujitsu!  :)
<Mez> who's the current X.org maintainer ?
<tepsipakki> Mez: there's no such thing ;)
<Mez> tepsipakki, hmmles... darn. cause xkb is borked
<Mez> and has been for a while
<Mez> I thought that someone was... 
* Mez tries and remembers name
<tepsipakki> do you have a bug?
<tepsipakki> what does "for a while" mean?
<Mez> as in since I re-installed feisty
<Mez> aka that you cant chage keyboard layout
<Mez> (I'm stuck on a US keyboard)
<tepsipakki> works for me
<tepsipakki> please file a bug
<tepsipakki> or look for one if there already is
<Mez> I think I did file one
<Mez> tepsipakki, using gnome ?
<tepsipakki> yes
<tepsipakki> I've tested livecd's and I always forget to change the layout on the boot options
* Mez is using kubuntu
* Mez tries and rememebers the kcm module
<Mithrandir> keescook: mythtv > multiverse, hence not beta-frozen.  Do as you want.
<keescook> Mithrandir: the bug is in qt-x11-free :)
<Mithrandir> oh
<Mithrandir> keescook: tested with both new and old mysql server?
<keescook> uhm, just new I guess; it's the qt3 mysql glue library's shutdown code that is fixed, as I understand it.
<saispo> anyone have more information about : https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/67936
<Ubugtu> Malone bug 67936 in gnome-system-tools "[network-admin]  Crash when starting from menu." [Medium,Fix released]  
<cjwatson> Mithrandir: uploading console-setup 1.13ubuntu9, which should fix bug 74375
<Ubugtu> Malone bug 74375 in console-setup "us misdetected as jp" [High,Confirmed]  https://launchpad.net/bugs/74375
<saispo> i have this bugs and i don't want to reinstall my laptop :/
<saispo> hi cjwatson :)
<cjwatson> Mithrandir: please review when you get a chance
<Mez> basically, in /etc/X11/xkb/rules/ there is no xorg file
<Mez> which I believe there should be
<Mithrandir> cjwatson: thanks.
<cjwatson> Mez: /etc/X11/xkb/rules should be a symlink to /usr/share/X11/xkb/rules
<cjwatson> lrwxrwxrwx 1 root root 4 2006-11-28 14:25 /etc/X11/xkb/rules/xorg -> base
<cjwatson> if it doesn't exist on the live CD then somebody does need to investigate
<Mez> cjwatson, lrwxrwxrwx 1 root root 24 2007-02-22 12:32 xkb/rules -> /usr/share/X11/xkb/rules
<Mez> cjwatson... It only started after i did a fresh install of dapper, and upgraded to feisty
<cjwatson> $ dpkg -L xkb-data | grep rules/xorg
<cjwatson> /usr/share/X11/xkb/rules/xorg
<cjwatson> make sure you have xkb-data installed
<Mez> cjwatson,  http://rafb.net/p/B3HCK289.html
* Mez does an apt-get install --reinstall
<cjwatson> well if the file doesn't exist then it looks like you (or something) manually removed it
<cjwatson> indeed
<Mez> cjwatson, I certainly didn't
<Mez> this was after a fresh upgrade from dapper->feisty!
<Mez> and now it works
<Mez> finally an english keyboard
* Mez sighs a huge sigh of relief
<keescook> Mithrandir: let me know how I should handle the qt fix (all mythtv users will be very happy to see it get published)  I'm off to bed (again, for real)
<Mez> whats the bet that seeing as i've been using it for a month now, that I'm too used to the americanised keyboard
<Mez> :D
* Mez switches to dvorak and throws everything off
<Mithrandir> keescook: I'm fine with it as long as it's well-tested.  Can you run it past Riddell too, since qt is mostly his area?
<Riddell> Mithrandir, keescook: where can I find it?
<Mithrandir> Riddell:                 https://launchpad.net/bugs/90710
<Ubugtu> Malone bug 90710 in qt-x11-free "[apport]  mythtv crashed with SIGSEGV in QApplication::~QApplication()" [Low,Confirmed]  
<Mithrandir> link to a diff near the end
<heno> The ubuntu-server image fails to load kernel modules -- under what package/product should I report that?
<heno> (as tested in VirualBox; other d-i installs work fine there)
<fabbione> heno: it's normal.
<fabbione> kernel did change ABI, but there has been no new debian-installer upload
<fabbione> heno: cjwatson knows about it already
<fabbione> and problably we need to check the seeds as well
<heno> fabbione: ok, and of course it then fails to boot later
<fabbione> it shouldn't even install afaik
<heno> should be targeted for Beta I guess
<heno> it installed :)
<fabbione> heno: cjwatson knows already.
<fabbione> oh
<heno> ok, cool
<fabbione> so it does install but it fails to boot?
<heno> but didn't start a network
<heno> right
<fabbione> hmmmm
<heno> kernel fails on first boot
<Riddell> Mithrandir, keescook: I don't really have a comment on that Qt patch, I'm not familiar with that part of the code at all, if it works and it's in suse then I'm happy with it
<fabbione> heno: is the kernel used to install the same as the one installed?
<heno> it did warn me that I shouldn't bother completing the install though
<Riddell> Mithrandir: however qt 3.3.8 seems to have problems with displaying a lot of CKJ characters, we might need to revert to 3.3.7
<heno> fabbione: I don't know
<fabbione> heno: worth checking that
<heno> right, how? :) install logs?
<fabbione> heno: boot the cd and check dmesg
<fabbione> go to rescue mode and chroot on the target and check in /target/boot
<fabbione> probably the logs have info too
<heno> ok
<mdke> heno: did it go ok with the Switching From Windows guide?
<heno> mdke: it's just in the pipeline :)
<mdke> cool
<mdke> I don't really download isos much to see
<heno> I'm placing a link with an icon on the about ubuntu page
<heno> Looks OK, IMO
<mdke> heno: is that the landing page for the autorun?
<heno> mdke: no, it's one click in
<heno> but it will be quite prominent on that page
* Hobbsee waves
<mdke> heno: sounds good
<heno> mdke: I'll send you a screenshot now
<Fujitsu> Hi Hobbsee.
<mdke> heno: :)
<Hobbsee> heya Fujitsu 
<giskard> hello *
<keescook> Riddell, Mithrandir: so, should I upload the qt-x11-free fix?  90710 is getting dup'd somewhat regularly.  :)
<disposable> i have two SATA drives(sda,sdb) in AHCI mode. feisty install went ok (to sda), grub went onto (hd0). when i try to boot i get no bootable device. what could be wrong?
<BenC> Mithrandir: ping
<BenC> Mithrandir: I just uploaded a new mesa with a simple one liner fix to compile just i965_dri.so with gcc-3.4...that bug was known just before edgy released, and without it, 965 graphics have horribly broken GL (as in it pretends to work, but just shows a white screen)
<BenC> Mithrandir: I would have though it would have been fixed now, but my bug report is missing, and my re-install of my core2duo desktop showed it was still a problem, so I figured might as well get it in for beta
<neighborlee> is it just me, or are other people seeing very slow download times when doing update  for feisty ( HURD5) ? ;)
<neighborlee> I have comcast, and last week or more im consistently seeing on average it seems of 30-45KB/s..
<ivoks> it's you or your mirror :D
<neighborlee> ivoks, hm so your seeing much  higher  speeds then I take it
<adamant1988> neighborlee: the repos are a bit slow many times, but I use a mirror
<neighborlee> your using comcast or.. ?
<neighborlee> adamant1988, ic
<ivoks> neighborlee: yes, i get 100MB/s... maybe because i'm next to the mirror :D
<neighborlee> hm ive never had to change a mirror due to slowness,,
<adamant1988> neighborlee: I was only getting like 20 kb/s from archive.ubuntu.com or w/e
<ivoks> make that 10MB/s, not 100 :)
<neighborlee> im not worried or angry whatsoever..I realize bandwidth isn't cheap and that distance  to mirror does matter..
<adamant1988> I switched to another mirror and got a nice speed boost
<neighborlee> I"ve heard internet had been 'hacked' , and I thought hmm i'd ask and see what others have been seeing
<neighborlee> ivoks, hehe yeah I was going to say woah man LOL
<jdong> anl.gov's mirror is always the fastest for me
<jdong> and archive has been crawling for the past two months
<neighborlee> hmm
<neighborlee> so the default most likely is set to archive ?
<jdong> right
<neighborlee> ok thx jdong 
<neighborlee> no wonder ;)
<cjwatson> Mithrandir: new d-i uploading, though we'll need another one since Ben has one more ABI bump to come
<Riddell> keescook: sure
<BenC> Mithrandir: ping, linux-source-2.6.20-12.19 uploaded, if you could process it for build, please. Thanks
* cjwatson accepts linux-source-2.6.20 and debian-installer
<cjwatson> oh, crap, I meant to do console-setup before debian-installer ... oh well, there'll be another upload of the latter before beta
<jdong> cjwatson: what are your feelings on trivial source-change backports?
<jdong> cjwatson: i.e. some packages have elevated build-deps just to force rebuild against newer libfoo in feisty, but would work just fine in Edgy if that build-dep was loosened
<jdong> keescook: what's the situation with clamav right now? I'm getting whining from people again :)
<neighborlee> hi..I presume that my CPU useage that never goes below 4%, is due to running fesity that may have debug code running ? ( I just stopped anacron and bluetooth, which got me down to 4% LOL) 
<cjwatson> jdong: fine by me but they'll need a core-dev sponsor
<jdong> cjwatson: is there a set process for asking for a core-dev sponsor, or is it coming in here and asking if anyone wants to sponsor?
<cjwatson> I do wish we could split up the functions of build-depends somehow - i.e. stuff that's actually required for the package to build at all versus how we *want* the package to build in our development branch
<crimsun_> jdong: a core-dev sponsor for what? note that some do lurk in -motu.
<cjwatson> jdong: I think there's an ubuntu-main-sponsors team or something along those lines
<jdong> cjwatson: ok
<jdong> crimsun_: source-change backports in general
<jdong> ones that untighten build-deps taht were put there to force a rebuild against some newer feisty lib, etc
<cjwatson> in fact, something exactly along those lines
<jdong> cjwatson: ah, ok, I was only aware of its universe counterpart
#ubuntu-devel 2007-03-18
<terlmann> hey guys , thanks for the origin tab in synaptic. it is very useful.
<jdong> how does synaptic do the origin magic, bTW
<terlmann> ehe, about how hard is it to update breezy straight to feisty ? because I did it over the past 24 hours, and lucky me, I got it working ;-)
<Fujitsu> terlmann: Probably not a good idea... But if it worked, you were rather lucky.
<jdong> terlmann: ha, that sounds like something I would do!
<jdong> and it does eventually work out
<jdong> might take a few aspirins but it'll eventually force on :)
<terlmann> multistep ;-) and I dared not try a reboot till I got a new kernel installed. it crapped out tones of errors first few times, but I did some red-neck hacking at things and got it working.
<terlmann> just aptitude and apt
<terlmann> had to do some dist-upgrade -f and some without the -f 
<jdong> that sounded like my edgy->feisty experience
* jdong ducks
<_ion> :-)
<terlmann> meh, I liked the old look in breezy. the new looks are kinda *fresh* , but the old looks were a classic. not to mention, my system is just old enough to do better without live when it is installing , the new merging into one disk - I thought, this stinks.
<cjwatson> breezy->feisty: you get to keep all the pieces, no matter how many it breaks into
<cjwatson> it's probably technically possible but ISTR some places where pre-dapper upgrade compatibility was intentionally discarded in the cause of simplification so I'm quite sure you'll have a fair bit of difficulty
* cjwatson -> bed
<Fujitsu> Night cjwatson.
<terlmann> well, for me, almost everthing had to be removed ,as during the course of time the packages had been renamed
<terlmann> everything'
<Seveas> terlmann, breezy -> feisty will break, iirc on an lvm2 upgrade. So you btter know dpkg and apt very well
<terlmann> it broke a fw times ;-)
<terlmann> i fixed it
<terlmann> hacking versions is my skill
* terlmann is teh uber-resolver
<terlmann> hey guys , an extreemly technical question... considering the fact I could install the whole set of tools for using rpm, could , I , like, install portage or pacman into ubuntu , and use them for things like source compiles ?
<terlmann> and I know about apt-src
<Seveas> terlmann, this channel is only for development of ubuntu
<Fujitsu> Not for doing completely stupid things on Ubuntu.
<Seveas> completely stupid things often make nice experiments
<_ion> But better do them in a virtual machine or a box you don't actually need to use. :-)
<terlmann> well, anyway , no matter how dumb it sounds, I was serious
<jdong> "Stupid Ubuntu Tricks with jdong" -- an hour long podcast of me doing crackpot things with Ubuntu?
<Seveas> jdong, you could fill days...
<Seveas> :)
<jdong> hehe :)
<terlmann> all-in-one swiss linux  system..
<_ion> jdong: I would listen to that. :-)
* jdong should blog his ntfs-3g system some day :)
<Amaranth> terlmann: the databases won't be the same
<Amaranth> package databases
<terlmann> jdong : did you make the Christmas edition ?
<terlmann> yea
<terlmann> I know
<terlmann> I would have to handle that
<terlmann> on paper
<jdong> terlmann: no, I don't usually publish such things :)
<terlmann> ehehe
<jdong> I figure that Ubuntu devs would feel their hearts momentarily skip beats every time I did :)
<terlmann> haha!
<terlmann> evill
<terlmann> Microsoft Visual COBOL - heard it before , passing it on...
* Fujitsu feels dizzy.
<terlmann> Microsoft Ruby.NET
<jdong> that's actually coming.
<terlmann> oh noes!
<jdong> apparently MS is funding some OSS attempt to implement ruby on.NET
<jdong> IronRuby?
<jdong> maybe RustyRuby or something
* jdong ducks
<Seveas> low.. :)
<terlmann> Microsoft Visual python.net
<Fujitsu> terlmann: That's IronPython.
<jdong> ahem, IronPython?
* jdong wonders if writing up a MIR for IronPython would be a joke or plain wrong :)
<Fujitsu> jdong: You wouldn't survive for more than 30 seconds, I don't think.
<terlmann> ehe
<terlmann> ahaha
<jdong> :)
<jdong> it's... a product from Microsoft, which means it's high quality right?
<jdong> besides, this GNU thing that popped up overnight can't run a computer from ground up without the windows
<Fujitsu> jdong: Of course not! We need Windows to boot it.
<jdong> Fujitsu: yeah, all those Windows critical services.
<terlmann> Microsoft Linux - the most secure in the world. best looking due to microsoft compiz and microsoft invented aiglx.
<Seveas> terlmann, MS linux == suse
<terlmann> we HAVE to copywright that NOW - before they do - then they can never make *microsoft linux* without changing the name.
<jdong>  xcb        - Pigeon holes for your cut and paste selections
<jdong> hmm.
<Seveas> linux is a trademark
<jdong> never thought I could find pigeons in the apt db
<terlmann> em , not really , novell linux has always sucked- and this is the latest publicity stunt to keep the relic alive - it wont last long.
<terlmann> remember the distrowatch *climb* and the impressive media coverage /
<terlmann> ?
<jdong> gah, I'm so ashamed of myself...
* jdong is trying to construct random dirty search regexes that match a package
<jdong> I think I need a life.
<jcmasters_hm> It's St. Patrick's day. Go drink beer!
<jdong> it is?
<jdong> oh it is.
<jcmasters_hm> jdong: and you're probably down the street from me! :P
<jdong> that sounds like more fun than trying to build dirty phrases out of 'pigeon holes'
<jcmasters_hm> Plenty of stuff going on in Harvard Sq. when I looked earlier.
<jdong> cool
<jcmasters_hm> I'm working, but I might head over to one of the bars here in Central later.
<jdong> ha, I still got 3 years to go :)
<jcmasters_hm> Oh yeah, silly US drinking laws :-)
<jcmasters_hm> That's why I didn't come here until I was 21.
<jdong> lucky :P
<_ion> Bars are annoying.
<Mithrandir> BenC: mesa> rejecting since you're not basing it on the version in the queue already.
* jdong mutters "anti-social"
<Mithrandir> Riddell: ugh, ok.
<terlmann> I wish I could drink. I would shoot a senator if it helped me. All I wanted was a glass of wine, at a friends wedding , already voted and had the farking stupid military paper mailed me, and still no booze.
<jcmasters_hm> terlmann: Well, I can drink but not vote. Though I pay US taxes...and as a Brit, I must protest against taxation without representation! :P
<Mithrandir> BenC: please do upload a new one, though.
<jcmasters_hm> Somehow, I became "old". I'm 26 this year.
<bhale> taxation without representation was a scam, if the british parliment had given the americans fair representation by population they would have had no effective power
<jcmasters_hm> bhale: obviously
<bhale> thats why we had to throw your ass out.
<jcmasters_hm> Don't have to tell me. I was down in Boston Harbor on December 16 pouring tea into the water.
<Seveas> Mithrandir, did you find some time to look at the usplash themes or should I poke someone else?
<jcmasters_hm> Well, I had an American do that while I watched :P
<Mithrandir> Seveas: I thought I uploaded it, but please poke somebody else since I'm about to go to sleep.
<jcmasters_hm> (December 16 1773, Boston Tea Party)
<Mithrandir> Seveas: hm, actually, it ended up being just dark blue still
<Mithrandir> iirc
<Mithrandir> jcmasters_hm: you're wildly offtopic for this channel, please go to #ubuntu-offtopic or something.
<Seveas> Mithrandir, nothing was uploaded, only the kubuntu theme by riddell
<Seveas> Mithrandir, and the theme really is fixed, I tested it :)
<Mithrandir> Seveas: ok. :-)
<Seveas> but I'll poke $someoneelse tomorrow, bedtime here as well
<Mithrandir> thanks.
<jdong> are there any technical reasons why l-r-m is not split out?
<jdong> a more modular approach would make it easier for 3rd parties to package kernel modules for Ubuntu
<Mithrandir> jdong: it's more work if it's split out
<bhale> hi Mithrandir 
<jdong> hmm I see.
<Mithrandir> hiya bhale 
<sladen> Mithrandir: can you poke 'mesa' through for the FTBFS change
<Mithrandir> sladen: I did so a fair bit of time ago
<sladen> Mithrandir: strange, do you know why it hasn't been built https://launchpad.net/ubuntu/+source/mesa/6.5.2-3ubuntu3
<sladen> Mithrandir: showing "Published", but "No builds recorded."
<Mithrandir> yes, the buildd sequencer hasn't run yet; it's published in this publisher run.
<sladen> okay, I misread the dates, it was cleared about an hour ago, but is just sat in the queue awaiting its turn.   yes, nod
<sladen> makes sense
<sladen> meh.
<BenC> Mithrandir: Ok, didn't know there was one in the queue
<BenC> Mithrandir: is the new version in the archive, or is there some place I can get it?
<sladen> BenC: I just did a mesa upload just now.  Do you have a debdiff handy and I'll combine it
<jdong> ah, that sounds so wonder twin :)
<jdong> debdiffs - UNITE
<Mithrandir> BenC: http://people.ubuntu.com/~ubuntu-archive/queue/feisty/unapproved has the NEW queue, but it should be published now so you can get it using apt-get
<TheMuso> c
<Hobbsee> d
<kukost> hi
<kukost> I've just got a question/suggestion for the ubuntu developers
<kukost> how about making a "ubuntu tutorial" the first time people run it? it can make the change a lot more easy for people trying ubuntu and linux for the first time
<Hobbsee> kukost: how about you write one?
<mdke> kukost: did you try System->Help?
<Hobbsee> kukost: ie, there are lots of suggestions, many of which are good, and limited resources.
<giftnudel> ha, my dad was on the cebit and brought me some ubuntu sticker, yes!
<malverian> mjg59: ping
<jwendell> how can i run 'automake' from debian/rules?
<mikerob1> Would a like weight online installer be a good summer of code project?
<sn0> isn't there one already mikerob1 , the windows based installer?
<mikerob1> I wouldn't know, that would be useless to me
<sn0> i believe the summer of code applications has paused for the summer
<mikerob1> ???
<mikerob1> The app deadline is the 24th
<sn0> "http://code.google.com/soc/" at least on google
<sn0> err
<sn0> We are no longer accepting applications from open source organizations. even :)
<mikerob1> Ubuntu has already been accepted
<dsas> sn0: that deadline was for organisations, there's another deadline for students.
<mikerob1> sn0 don't worry about the deadline an answer my question
<mikerob1> would it be a good project?
<sn0> oh i see
<mikerob1> I hate having to install 200mb of outdated packages
<rouzic> Hi all
<mikerob1> hi
<sn0> im not sure of a network / small iso image for installs, i know on debian there exists such a thing
<rouzic> I have a problem with a kernel 2.6.20-10 and 2.6.20-11 in a MacBook
<j1mc> rouzic, i think there's already a bug for that: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91940
<Ubugtu> Malone bug 91940 in linux-source-2.6.20 "2.6.20-10 regression from 2.6.20-9, Macbook Pro no longer boots" [Undecided,Confirmed]  
<rouzic> j1mc: yes, that bug :)
<j1mc> rouzic, that bug is being tracked for the beta, so hopefully it will be fixed soon.
<rouzic> oks, thanks j1mc
<j1mc> rouzic, keep an eye on the status of that bug report.  if it gets fixed, be sure to test the fix.
<rouzic> This it is the mistake that me appears to my
<mikerob1> Are there any documents describing how the installer ISO's are built?
<dsas> mikerob1: if there are it'll be on wiki.ubuntu.com
<mikerob1> I've usually only found broken links on the wiki
<Lathiat> i believe they are build with some scripts that you can't actually get
<Lathiat> but i could be wrong, please check that :)
<mikerob1> Are they some kind of secret?
<dsas> mikerob1: these are the people that run the process: https://beta.launchpad.net/~ubuntu-cdimage/+members
<dsas> uhm, remove the beta. from that url.
<BenC> Mithrandir: mesa_6.5.2-3ubuntu5 uploaded, based on -3ubuntu4build1
<cjwatson> mdz: your seed commit (r913) that restored gnome-btdownload appears to have (accidentally?) reverted some of the Recommends changes you made just beforehand. Could you check that that was what you meant to do?
<LaserJock> how's/act
<LaserJock> bah
<sladen> BenC: that last SMP cpufreq issue is probably that the kernel should remember the value before and after suspend/resume  (it's remembering it for the first CPU, but not subsequent ones)
<sladen> BenC: I can have acpi-support or some such actively save the state during suspend/resume  (though I'm not sure it's quite the right solution)
<BenC> sladen: Can you confirm that it is actually doing that for the first cpu?
<sladen> BenC: I don't have a SMP laptop, but the first comment in the bugreport shows before/after for cpu0 and cpu1.  cpu0 remains 'ondemand', and cpu1 reverts to 'performance'
<BenC> sladen: Just wondering if userspace is setting ondemand for cpu0 or kernel is actually saving that state
<sladen> BenC: powernowd isn't a daemon anymore, just an init.d script that load modules and echo's 'ondemand'
<sladen> BenC: so the initscript is only run on the initial bootup
<BenC> ah, so likely userspace
<sladen> BenC: my hunch is that the kernel [the cpufreq driver in question?]  is making the effort to do the save;  but the save code was likely written before SMP laptop cpus
<BenC> well the cpufreq and suspend/resume is not laptop specific, so let's leave that part out of the equation :)
<BenC> most likely you are correct though
* sladen goes to apt-get the source
<BenC> sladen: I just confirmed that problem on my core2duo workstation
<BenC> cpu1 reverted to performance
<BenC> cpu0 is at ondemand
<jdong> BenC: what's up with P965/JMicron in Feisty?
<jdong> BenC: hearing from multiple users that system hangs on boot, detecting IDE drives
<sladen> BenC: based on the contents of   cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors   if you try pasting something else in we can 110% sure  (something that isn't ondemand, performance or userspace)
<BenC> sladen: jmicron should be fixed in -12
<BenC> sladen: Set it to conservative, and it still went back to performance
<jdong> BenC: ok, thanks for the info :)
<jdong> BenC: p.s. you're right iwlwifi is glitchy :D
<BenC> jdong: Ah, wrong person, but good you were paying attention :)
<jdong> :)
<BenC>         /* only handle each CPU group once */
<BenC>         if (unlikely(cpu_policy->cpu != cpu)) {
<BenC>                 cpufreq_cpu_put(cpu_policy);
<BenC>                 return 0;
<BenC>         }
<BenC> sladen: Wonder if that has something to do with it. That's in the suspend callback
<delrey> or should it be mypackage_0-ubuntu0.0.0_i386.deb ?
<delrey> is mypackage_0-ubuntu0.0.0.deb appropriately named?
<lifeless> delrey: I think you want #ubuntu-motu :)
<delrey> what's the difference between the channels (i asked there before coming here, which is why the questions are out of order)
<lifeless> ubuntu-devel is for the core development, of ubuntu-main, ubuntu-motu is for prospective developers like yourself, and for development of universe.
<delrey> oh
<delrey> gotcha, so quick question, why wouldn't you guys have this place password protected or something or invite only?
<delrey> seeing as though it has to do with core developers, shouldn't only the leetest of ubuntu devs get the honor of being here?
<BenC> delrey: it's open, it's just we have a specific topic for this channel
<BenC> just like you don't go to #netbsd to ask a Win98 question
<lifeless> delrey: you're welcome to stay
<delrey> well, i'd be pretty useless in this channel
<lifeless> delrey: its just that there is a focus to the discussions here, thats all.
<BenC> delrey: The topic of the channel describes what is on-topic
<lifeless> BenC: perhaps we could add main to that though.
<BenC> and also points to #ubuntu-motu for your particular interest :)
<BenC> lifeless: It just says "for getting involved in development"
<lifeless> yeh
<lifeless> I can see that ;)
<delrey> I'm thinking of getting involved in the Google Summer of Code for Ubuntu, especially for better integration of a source code compilation mechanism - something like emerge on Gentoo to replace apt-get. Is that too ambitious?
<jdong> delrey: that's what apt-build does :)
<delrey> Yeargh, I'll look into that.
<jdong> delrey: and I don't think what you're trying to accomplish is too ambitious, but getting that to fit in with the Debian/Ubuntu community will be.
<jdong> delrey: the technology/mechanisms for simulating Portage on Ubuntu/Debian is well available :)
<delrey> Darn, all the good ideas are taken :'(
<jdong> delrey: I got it! Make an automatic codec installer!
* jdong hides
<BenC> delrey: The Device Driver Manager spec is something I'm proposing for SoC, if you are interested
<delrey> Well, I'm going into EECS, so I'm looking for something more specifically related to that this summer (assuming I even get accepted). But if the emerge thing is taken, there's not much interest for me in other projects. The closest would possibly be getting drivers written for X that would help all distributinos that use X, but that's about it. I don't mean to be a jerk, but it's just not my thing.
<lifeless> well
<lifeless> apt-build is not really that close to emerge
<lifeless> it only builds completely predefined things
<jdong> lifeless: meh make special soruce packages that just fetch the source tarballs during build :)
<jdong> lifeless: probably violates every policy but... oh well :D
<lifeless> jdong: that doesn't address the other 16K packages
<jdong> lifeless: heh no it doesn't.... a uupdate script would do that though
<jdong> for the packages that build without dropping patches
<jdong> lifeless: I've considered such an extension onto prevu but decided every developer would probably burn my house down :D
<Burgundavia> delrey: to be brutally honest, I can think of about a dozen projects that might better suit Ubuntu than a source package builder
#ubuntu-devel 2008-03-10
<YokoZar> brainstorm needs a "worst ideas" button
<LaserJock> heh
<pwnguin> if bash is any indicator
<pwnguin> racist jokes
<pwnguin> but i woudln't infer too much from worst ideas; the possible reasons someone might vote an idea down are wide and contradictory
 * Hobbsee waves
<LaserJock> hi
 * Hobbsee dies, looking at excessive email
<Hobbsee> i should actually read this...
<pitti> Good morning
<pitti> Hobbsee: tzdata> erk; we need to debug this; can you reproduce this? does it happen with install --reinstall the old version, too? (I didn't change any packaging)
<dholbach> good morning
 * pitti hugs dholbach
 * RAOF never gets the hugs :`(
 * dholbach hugs RAOF and pitti
<RAOF> Yay!
 * RAOF gives hugs.
<pwnguin> so when is ff3 supposed to go final?
<dholbach> afaik the theme was supposed to have changed - it somehow didn't change for me yet
<dholbach> pwnguin: best to ask asac that
<pwnguin> the theme looks like it changed a bit
<pwnguin> the icons for left right and the like
<pwnguin> but more importantly, google browser sync isn't published yet for ff3
<dholbach> hrm..... seems that alsa is broken for me with 2.6.24-12
<pwnguin> maybe it's time to investigate mozilla weave
<pitti> doko_: I guess tzdata's javazic-fixup.patch should actually be applied? I'll add it to debian/patches/series
<doko_> pitti: it is applied during the build
<pitti> doko_: oh, argh, just see it in debian/rules
<Ng> dholbach: bug 200338 :)
<pitti> doko: do you plan to introduce the javazic binary to some proper package in Debian?
<pitti> doko: (I wonder about forwarding this patch to Debian, but the sharutils .uu one is really nasty)
<doko> pitti: Aurelian already knows. once we have OpenJDK in main, that can go away
<pitti> ah, nice
<dholbach> thank Ng
<Ng> dholbach: it's quite impressive, the bug is 10 hours old and has 40 comments and 12 duplicates already ;)
<dholbach> Ng: yeah it is - I guess bdmurray can come up with even more impressive bug reports :)
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] https://launchpad.net/bugs/200338
<slangasek> oh, is *that* why sound wasn't working?  I thought it was just because I tried out -12 before lum was available
<mdke> morning all
<mdke> is about-this-computer going to be implemented by hardy, does anyone know?
<mdke> or has it missed feature freeze?
<dholbach> seb128: did you already see the bug-o-meter on  http://daniel.holba.ch/really-fix-it/ ?
<seb128> dholbach: ah, nice ;-)
<pitti> hi seb128
<seb128> hey pitti
<seb128> pitti: so, I've been looking at login speed a bit again and doing some stracing and graphs about the issue
<pitti> bdmurray: do you plan a new p-lp-bugs upload soon?
<seb128> pitti: jockey-gtk --check takes 11 seconds there! and it does that at every boot where I don't need it
<crevette> good morning
<pitti> bdmurray: once we have that, we should do an SRU for that, to fix the retracers, and scripts people run on gutsy
<seb128> pitti: is there a way to cache the value? it seems to call a lot apt-cache and modinfo and that's sloooow
<pitti> seb128: ah, good point
<seb128> no cookie for mvo neither
<dholbach> hey thekorn
<pitti> seb128: I'll think about it
<seb128> update-notifier call apt-check which takes 7 seconds on my laptop there
<pitti> it should at least run in parallel with other stuff
<pitti> seb128: caching should be no problem
<seb128> pitti: it does, but that and update manager give a 5 seconds impact on a 25 seconds login time there
<seb128> it adds to the load
<pitti> 25 seconds? lucky you
<pitti> seb128: right, understood; thanks for pointing out
<seb128> pitti: could you do a graph of your laptop login?
 * dholbach hugs super-seb128
<pitti> seb128: how do I get a graph of session start?
<thekorn> morning dholbach et al.
<pitti> hi thekorn, how are you?
<thekorn> pitti, I'm fine thanks
<seb128> pitti: start a debug xorg session, run "strace -ttt -f -o login.log gnome-session", wait until having the desktop loaded, ctrl-C it, download http://people.ubuntu.com/~seb128/plot-timeline.py, run plot-timeline.py login.log -o login.png, copy the png somewhere
<pitti> seb128: debug xorg session -> how?
<pitti> just X from a VT?
<pitti> and DISPLAY=:0 gnome-session from another VT?
<seb128> pitti: it's called xterm session in the gdm login menu or something similar
<pitti> ah, that
<seb128> just any way you want which doesn't run gnome-session for you work
<seb128> since you need to run it under strace
 * seb128 hugs dholbach too
<seb128> dholbach: do you have a box where login is slow? want to do a graph on it too? ;-)
<pitti> hm, ctrl-c doesn't work, ctrl+alt+backspace does it :)
<seb128> pitti: yeah, did the same yesterday, not sure why it doesn't work
<pitti> wow
<pitti> login.log -> 147 MB
<seb128> strace is verbose ;-)
<seb128> but that also means we do a lot of access at login
<dholbach> pitti: my login.log is "just" 77,1MB
<pitti> hm, I don't even have unusual stuff
<dholbach> seb128: http://daniel.holba.ch/temp/login.png
<pitti> to the contrary, I ê«­
<pitti> already disabled tracker
 * pitti beats scim really hard
<pitti> grrrrr
<pitti> python /tmp/plot-timeline.py /tmp/login.log
<seb128> pitti:  -o login.png
<seb128> dholbach: thanks
<dholbach> de rien
<pitti> seb128: ^ that produces a 1400x34200 pixel graphics whihc is entirely black
<pitti> python /tmp/plot-timeline.py -o /tmp/desktop-login.png /tmp/login.log
<pitti> right, I used that
<seb128> pitti: hum, weird
<seb128> pitti: it should do something similar to http://daniel.holba.ch/temp/login.png
<pitti> seb128: hm, I ran it on my desktop; let me re-run it on the laptop itself
<seb128> dholbach: if you want to do some extra testing you can disable jockey-gtk and update-notifier, reboot and try again to see the difference
<seb128> hey mvo
<mvo> hey seb128
<seb128> mvo: so I've been looking at the login speed, update-notifier runs apt-check on login which takes 7 seconds on my laptop, what can you do to make things better there? ;-)
<mvo> seb128: woah, that is a long time. sure, we can delay the run of apt-check. could gnome-session not run some stuff in parallel? is u-n blocking other stuff from starting?
<pitti> seb128: same result :/ png in eog is black, and firefox crashes when opening it
<seb128> pitti: :-(
<mvo> seb128: with what app do you measure the login speed btw?
<dholbach> pitti: you have python-cairo installed?
<seb128> mvo: pitti: start a debug xorg session, run "strace -ttt -f -o login.log gnome-session", wait until having the desktop loaded, ctrl-C it, download http://people.ubuntu.com/~seb128/plot-timeline.py, run plot-timeline.py login.log -o login.png, copy the png somewhere
<pitti> seb128: cairo> installed
<seb128> mvo: that gives graphs similar to http://daniel.holba.ch/temp/login.png
<seb128> mvo: it's ran it parallele but those add to the load and that doesn't make things better
<pitti> seb128: shouldn't an strace -ttt -e execve -o login.log give pretty much the same info?
<pitti> (and -f)
<seb128> pitti: it should, I didn't try though
 * pitti tries
<seb128> pitti: not sure why the graph things doesn't work for you
<dholbach> arg.... gnome-session-save.... arg!!!!
<funman> hi
<dholbach> seb128: hum... I disabled jockey and update-notifier but it seems that update-notifier still runs
<seb128> dholbach: maybe try to move the desktop away from /etc/xdg/autostart, I tried this way yesterday
<dholbach> at least in the "start programs" thing
<dholbach> ngh
<dholbach> ok
<seb128> but the GUI should work
<seb128> I'll look at that later
<dholbach> it's unchecked, but still it ran
<funman> i notice a strange bug on a live cd session
<funman> i'd like to get opinions
 * dholbach restarts and tries again
<funman> getcwd() returns NULL / ENOENT in cvs
<pitti> funman: cvs, as in the revision control?
<funman> but surrounding the code calling it with the same call to getcwd() (both before and after) shows that getcwd() works
<funman> yes
<funman> i suspected squashfs, but it fails also on ext3
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/login-execve.log
<seb128> pitti: still no luck with the graph?
<pitti> seb128: ah, so the script takes the time between execve and SIGCHLD?
<pitti> clever
<pitti> seb128: trying with that reduced one
<seb128> waouh
<seb128> that's slow login
<seb128> 85 seconds!
<pitti> yeah, as I said
<dholbach> seb128: http://daniel.holba.ch/temp/login2.png (without jockey and update-notifier)
<pwnguin> maybe upgrade manager should sleep for five minutes on startup?
<pitti> seb128: ah, png works
<pitti> seb128: http://people.ubuntu.com/~pitti/tmp/login.png
<seb128> dholbach: weird, they are still ran apparently there, you have lot of apt-cache and modinfo and dpkg calls
<dholbach> no idea why *shrug*
<seb128> pwnguin: 60 seconds would be enough
<dholbach> I moved away the files and unchecked them in the gnome-session UI
<dholbach> pitti seems to start a lot of applets and terminals and stuff too
<dholbach> firefoxes too
<pitti> I have two terminals
<pitti> no firefox
<pitti> and a terminal with mutt inside
<dholbach> it says that on the .png file
<pitti> applets> just deskbar, the rest is standard
<dholbach> multiload?
<pitti> dholbach: hm, weird; I might have a starter for it, but ffox doesn't start
<pitti> right, I use multiload, too
<dholbach> cpufreq-applet
<seb128> pitti: you have a gap of almost 15 seconds after the cpuload applet load
<seb128> cpufreq I mean
<pitti> indeed
<pitti> whoa
<seb128> but it's not clear the gap is due to it, since things are ran in a async way you can't say which one is still running there
<dholbach> cpufreq seems to call modinfo later on too
<dholbach> (or might be)
<seb128> another way to get a boot graph is too install bootchart
<seb128> dholbach: no, that's jockey, things are async
<dholbach> hmok
<seb128> apt-cache and modinfo are jockey
<seb128> apt-check and dpkg-query are update-notifier
<lool> pitti: Heya; dunno who accepted elisa and pigment from binary new, but now there's likely a problem: we need pigment-python, and elisa-plugins-{bad,ugly,good} (all new sources)
<seb128> I see pitti's disk is slow on those take a while
<lool> pitti: Or should I be talking to whoever is on archive admin duty today (I guess slangasek)?
<funman> http://pastebin.ca/936294
<seb128> pitti: another way to get informations is apt-get install bootchart, mv /etc/init.d/stop-bootchart somewhere and run sudo ./stop-bootchart start one logged
<pitti> lool: those were split out?
<seb128> pitti: this way you get a bootchart until desktop loading
<pitti> seb128: ah, nice
<funman> i would say the bug is in glibc, but i can not read that code
<lool> pitti: pigment-python yes, elisa-plugins-* not really
<pitti> seb128: I'll enable autologin for that then?
<seb128> pitti: that gives better informations on what takes how long and do lot if io
<lool> pitti: elisa gained a plugin architecture and the main UI is in one of the packages (-bad)
<seb128> pitti: yes
<lool> (don't laugh)
<Tonio_> hi there
<pitti> lol
<Tonio_> seb128: did you have to change something to network-manager-gnome recently ?
<seb128> Tonio_: asac updated to a new version if that's the question, he maintains it, as an user no I didn't, why?
<lool> it's inspired by the gstreamer package names, except you're forced to install -bad -- unless you want to run the elisa server though
<Tonio_> seb128: knetworkmanager broke with latest updates. It fails to initiate wireless connection. nm-applet works
<seb128> Tonio_: nm-applet has been updated to a new version too
<seb128> I guess upstream did whatever is required to have those in sync and working
<lool> pitti: If you work on accepting the new sources, then if you like we can discuss main promotion as well (if you need to discuss anything)
<Tonio_> seb128: okay then I suspect I should investigate this with knetworkmanager upstream
<Tonio_> seb128: libnl is probably the cause somehow
<pitti> lool: I'll accept them to universe first anyway
<lool> pitti: elisa at least starts for me in the new version now on Intel; didn't try with compiz running though
<pitti> E: elisa-plugins-bad: not found
<pitti> oh, experimental?
<lool> pitti: It's uploaded already
<lool> pitti: It should be in NEW
<pitti> lool: ah, I thought I should sync it
<lool> I uploaded them manually because the plugins-* are still in Debian NEW
<lool> Basically the Debian ftpmasters took the same shortcut as Ubuntu's
<pwnguin> maybe if you optimized your PATH ;)
<pitti> lool: and python-pigment?
<lool> pitti: Also
<asac> Tonio_: for me knetworkmanager works
<lool> In fact it used to replace python-pigment, but now it doesn't anymore so it's a new source with new binaries
<lool> (python-pgm is the new name
<lool> )
<asac> Tonio_: though i cannot rule out that it needs an update because of new networkmanager 0.6.6
<lool> pitti: New: pigment-python 0.3.3-1~hardy1 elisa-plugins-good 0.3.4-1~hardy1 elisa-plugins-ugly 0.3.4-1~hardy1 elisa-plugins-bad 0.3.4-1~hardy1
<lool> It's a long chain of build-deps on build-deps now    :-/
<lool> (elisa-plugins-* need python-elisa from elisa which needs python-pgm from pigment-python which needs libpigment from pigment)
<lool> And naturally the lib changes SONAME frequently   :-/
<Tonio_> asac: it works ? no issue connecting to any wireless network ?
<Tonio_> asac: I can't initiate any connection, but it works when used together with nm-applet
<Tonio_> asac: I'll ask other people, maybe that's just a local issue
<asac> Tonio_: strange ... haven't tested today, but tested before and after the upload
<Tonio_> asac: hum, do you have nm-applet running when you use it ?
<Tonio_> asac: if yes, you won't see the issue since they'll start the connection together, and nm-applet finally succeeds
<asac> Tonio_: not when i tested this
<asac> Tonio_: yep i know. i will test  in a few
<Tonio_> asac: hum........ okay I'll keep investigating then
<asac> (to be sure)
<asac> i think i didn't test with 0.6.6 ... just with 0.6.6~rc2
<asac> but there where no significant changes
<Tonio_> asac: looked to me more a problem with libnl than with network-manager itself
<asac> Tonio_: point is that nm-applet 0.6.5 still works as well
<asac> thats why i doubt that knetworkmanager is broken
<Tonio_> hum yep, well the codebase is completly different
<\sh> hmmm...how stole my sound?
<Tonio_> maybe the code is simply broken with libnl1 or something....
<Tonio_> \sh: general issue, looks like
<asac> Tonio_: yes, libnl is a good idea to look at
<asac> Tonio_: though i am not even sure why knetworkmanager needs libnl
<asac> imo it should just talk to network-manager
<\sh> Tonio_: cool :) I was wondering if my company workstation just lost its sound ability
<Tonio_> asac: as I said, just ideas thrown to the air ;) I need to investigate more
<Tonio_> also fonts changed recently no ?
<Tonio_> "sans" of size 8 just looks strange....
<asac> ArneGoetje: hey, did the thai font update ever happen? (just looking at not finished mail threads and found the one from thep i forwarded)
<lool> pitti: Oh and you might have to wipe your .elisa to get the default set of plugins of the new version enable automatically -- if you already ran an older elisa version before that is
<funman> ok .. cvs uses some rpl_getcwd() instead of getcwd()
<funman> some autotools magic *sigh*
<dholbach> \sh: <Ng> dholbach: bug 200338 :)
<ubotu> Launchpad bug 200338 in linux-ubuntu-modules-2.6.24 "no sound hardy kernel 2.6.24-12 " [Critical,Confirmed] https://launchpad.net/bugs/200338
<pitti> ArneGoetje: WDYT about assinging the scim switch key to a combination that's less likely to be hit accidentally?
<pitti> ArneGoetje: maybe just ctrl+space or left+right ctrl, instead of shift+space?
<dholbach> I use ctrl-space in liferea :-/
<Mithrandir> pitti: I think we should use ctrl-alt-shift-f7
<pitti> well, I guess it should still be *easy* to do, but deliberately
<pwnguin> my keyboard doesn't have a right control ^_^
<pitti> let's map it to 's' then
<pitti> no uer need uch a letter
<pwnguin> no, c
<pwnguin> everything kan be spelled without it
<pitti> pwnguin: but only for KDE users!
<Mithrandir> pwnguin: at least in sensible languages, like Norwegian.
<pwnguin> how bout tilda
<pwnguin> nobody really uses it
<pitti> ctlr+esc?
<pitti> pwnguin: tilde == home directory
<pwnguin> pitti: where/
<Mithrandir> and aptitude search patterns.
<Chipzz> pwnguin: that was one hell of a clueless remark :P
<pwnguin> heh
<Chipzz> not to mention that tilde is often used in urls
<Chipzz> for user-homedirs
<pwnguin> get rid of the ugly reset X key combo and use that ;)
<pwnguin> it'll be hilarious trying to convince people that's really the combination
<Chipzz> oh wait
 * Chipzz slaps self for missing sarcasm :P
<Chipzz> hrrrrm
<Chipzz> what about caps-lock with some key? ctrl-capslock maybe?
<Chipzz> then finally that bloody key will have an actual use :P
<pwnguin> contrl alt \?
 * Chipzz is actually surprised that keyboard manufacturers still put caps lock on keyboards these days
<pwnguin> it's only gonna get worse as compiz gets more popular
<pitti> Chipzz: it's a great Esc key for me :)
<pwnguin> Chipzz: the thing is, everyone wants everyone ELSE'S capslock gone
<Chipzz> pitti: yea, but you're hardly a normal user ;)
<Chipzz> pwnguin: even when I do type something all caps, I still use shift
<pwnguin> plus, i think unreal tournament maps capslock to scoreboard
<Chipzz> yeah but I mentioned ctrl-caps lock
<TheMuso> 5/c
<mvo> pitti: is scim still enabled for you? the latest upload should have disabled it again for non CJK languages
<Mithrandir> I don't have a caps lock
<pitti> mvo: yes, it has never been disabled again for me
<Chipzz> Mithrandir: hh kayb? :)
<lool> Mithrandir: Put a brick on the shift key; the OS should cope
<pitti> mvo: although I tried to disable it in the configuration dialo
<pitti> g
<Mithrandir> Chipzz: no, compose key.
<pitti> mvo: but I didn't fiddle with it on my laptop, and it's still enabled there, too
<Chipzz> Mithrandir: ah, sun (UNIX) keyboard?
<pitti> mvo: maybe I need to reset some gconf keys or so?
<mvo> pitti: I guess you did logged out/in again since the package was updated?
<Mithrandir> Chipzz: no, thinkpad.
<pitti> mvo: yes, often
<mvo> hrm, not good
<mvo> pitti: as a workaround (for now) you can run gnome-language-selector and disable it there in the checkbox
<mvo> pitti: that is a good test for the code anyway :)
<Chipzz> anyway, I think caps lock (with or without modifier) makes sense; it's used to "alter" the meaning of keys you press now anyway
<pitti> mvo: btw, it should move from Administration to Preferences
<pitti> mvo: wow, a reboot?
<mvo> pitti: not really, a relogin is enough
<pitti> mvo: not just logout/login
<pitti> martin   28630  0.0  0.0      0     0 ?        Z    09:24   0:00 [scim] <defunct>
<pitti> mvo: btw, I have had this broken process forever
<pitti> what's the deal with it?
<pitti> (since day 1 when we enabled it)
<mvo> pitti: but strangely for new gdm defaults we need to reboot, it used to work to send it a reload, but that seems to be no longer the case
 * pitti reboots, brb
<mvo> pitti: no idea about this one, that must be something in the im-swich package
<mvo> pitti: move to preferences because it does not require gksu anymore to start? what is our policy here, langpack install still requires gksu, so do we consider it something for preferences or more something for admin?
<seb128> mvo: gksu = admin
<mvo> seb128: its a bit unfortunate that it currently mixes system-wide stuff (langpacks) with user stuff (im-switch config)
<pitti> mvo: right, but as long as normal users are supposed to use it, it shouldn't have X-KDE-SubstituteUID=true at least
<pitti> since otherwise non-admins won't see it at all
<pitti> yay sanity!
<pitti> mvo: disabling scim worked
<mvo> pitti: nice, when ArneGoetje is back, we should look at the root cause of the problem
<mvo> doko: your python-central fix works, dapper->hardy lts upgrades with ubuntu-desktop work again :)
<dholbach> pitti: can you please reject the five-a-day upload to Ubuntu I just did?
<pitti> dholbach: is it NEW?
<dholbach> yes, it should be
<pitti> argh, my ssh hates me again
 * dholbach gives pitti a big hug
<pitti> dholbach: will do as soon as ssh works again or seb128 beats me to it
<dholbach> thanks a lot, pitti and seb128
<seb128> dholbach, pitti: done
<pitti> merci
<mvo> pitti: I would like to upload cupsys with a fix for #156634 (test if /var/run/cups is not available and if not, create it before the chown call. ok with you?
<seb128> de rien
<seb128> dholbach: five-a-day 0.17, that was it, right?
<pitti> mvo: sure; please send the debdiff for me for committing into svn
<dholbach> seb128: exactly
<dholbach> seb128: I should have directly uploaded to 5-a-day-ppa instead :/
<pitti> mvo: although, nevermind; MoM will mail it to me automatically
<seb128> ok, upload rejected
<dholbach> thanks :)
<seb128> dholbach: ok ;-)
<seb128> you are welcome
<mvo> pitti: http://paste.ubuntu.com/5517/
<pitti> mvo: hold on
<pitti> mvo: you forgot a || true
 * mvo holds
<pitti> or a proper if..then
<mvo> meh, right
<pitti> <nitpick>does not exists -> does not exist</nitpick>
<pitti> mvo: I wonder whether it should just not be chown'ed in that case, though
<pitti> but it won't harm
<mvo_> pitti: http://paste.ubuntu.com/5518 would be the alternative for unnedded chmoding, whatever style you like better
<pitti> mvo_: I think I like the latter one
 * pitti hugs mvo, thanks
<mvo_> pitti: great, thanks for looking over it
 * mvo_ hugs pitti back
<mvo_> pitti: this is something that people asked for a SRU for feisty->gutsy too, how do you feel about it?
<pitti> mvo_: if that's still relevant, ok for me
<doko> mvo: good to know
<\sh> guys, is lzma now a valid option for creating deb files?
<pitti> \sh: yes
<\sh> pitti: but it's not default, right?
<pitti> \sh: right, you need to use dh_builddeb -- -Zlzma
<\sh> pitti: cool :)
<ogra_cmpc> grmbl ... gvfs renders my classmate unusable while developing ....
<pitti> \sh: oh, and Pre-Depends: dpkg (>= 1.14.12ubuntu3)
<ogra_cmpc> no, dear nautilus, you dont need to open a godammden 15M eating window for *every* mount while i'm working
<\sh> pitti: so in all binary packages we need to add Pre-Depends: ?
<ogra_cmpc> i wonder if the gvfs guys ever worked on systems where you only have 64M freely uable ram
<pitti> \sh: in all that use lzma, yes
<pitti> \sh: soyuz will reject built binaries which don't have it
<\sh> pitti: ok..so it's not a good solution when we want to backport pkgs...
<pitti> \sh: yes, unless you add some runtime tests to debian/rules and use some substvars magic
<\sh> pitti: well, I wonder how much reduction we have when using lzma...are there any stats on it?
<pitti> \sh: ia32-libs shrunk by more than 50% (41 MB -> 20 MB)
<pitti> \sh: the entire alternate CD shrinks in the order of 200 MB
<\sh> pitti: wow...
<pitti> but it entirely depends on the particular package, of course
<\sh> pitti: that sounds promising
<pitti> \sh: wow indeed :)
<YokoZar> pitti: Will we then default to lzma for Hardy+1 now that we know we have it?
<YokoZar> I mean, no more need for pre-depends for Hardy+1
<pitti> YokoZar: hopefully
<pitti> we'll still need the Pre-Depends
<pitti> at least until dapper goes out of support
<pitti> (for backports, etc.)
<pitti> but we should find a way to add it automatically
<pitti> (pkgbinarymangler FTW *cough*)
<YokoZar> pitti: Ahh, ok.  But we won't expect people to upgrade Dapper->Hardy+1
<pitti> right
<pitti> but we might do source backports from intrepid to pre-hardy
<YokoZar> Would we also move lzma out of universe?
<pitti> we did, it's in main of course
<YokoZar> Err, I meant for Gutsy.  Or does that not make sense since backports can depend on universe packages anyway
<pitti> YokoZar: we won't build lzma packages for pre-hardy
<Riddell> hmm, no calc, anyone know what's happening with openoffice.org-l10n-en-us ?
<TheMuso> pitti: Has lzma for live CDs been considered for future releases? Or is there too much of a performance hit?
<ogra_cmpc> TheMuso, that would mean we'd have to patche the kernel in a way upsytream doesnt like
<ryanhaig1> im trying to rebuild nautilus without tracker integration on gutsy, i have downloaded the source but I dont know what to change to disable tracker, is it a command line option when using debuild or do i need to change a file?
<TheMuso> ogra_cmpc: oh ok.
<ogra_cmpc> and lzma has a immensely higher ressource hunger so having a whole squashfs in lzma will be a resource hog
<pitti> TheMuso: AFAIK there are working plans for lzma squashfs
<ogra_cmpc> you trade performance against comression rate
<pitti> TheMuso: no idea about its status, though
<ryanhaig1> is this not the right channgel to ask the question?
<MacSlow> Greetings everybody!
<pitti> hi MacSlow
<MacSlow> hey pitti
<ogra_cmpc> pitti, do i miss any kind pof approval for the classmate-tools package ? seems it built fine but the publisher apparently doesnt copy the binary to a.u.c
<pitti> ogra_cmpc: it's in binary NEW (see https://edge.launchpad.net/ubuntu/+source/classmate-tools/0.2-0ubuntu1)
<Hobbsee> pitti: i'd changed /etc/timezone myself, to a valid config, iirc, and it barfed.  should be reasonably easy to reproduce
 * Hobbsee found a better way to do it, but still
<pitti> Hobbsee: with dpkg-reconfigure tzdata or tzconfig, or manually?
<pitti> Hobbsee: i. e. maybe /etc/timezone and /etc/localtime were out of sync for you?
<Hobbsee> pitti: i think i'd tried tzconfig, but it appaered to do nothing.  they would have been out of sync, yes.
<Hobbsee> dholbach: any chance you can add thta you have to join the 5-a-day LP team to the instructions if you haven't already done so?
<dholbach> Hobbsee: it was there all the time
<Hobbsee> dholbach: oh, so multiple people have missed it?  at least 3?
<Hobbsee> (another one was asking about it in #lp today)
<dholbach> doko and you are all I know about, 110+ made in their successfully :)
<dholbach> right
<dholbach> I can make it BOLD if you like
<Hobbsee> right.  apparently i'm just dumb then.
<dholbach> that's not what I said - one point on the list can be missed easily
<dholbach> I'll make it bold - safe is safe :)
 * Hobbsee looks at the page again
<doko> slomo_: will you sync gstreamer + plugins again for hardy?
<Hobbsee> oh
<Hobbsee> dholbach: right, i'm dumb.
<dholbach> no worries :)
 * dholbach goes out for lunch - see you guys later
<Hobbsee> dholbach: i suspect that everyone' slooking at the steps that actually have a code box underneath them
<dholbach> Hobbsee: yeah, that makes sense :)
<Hobbsee> more <br>'s may help there
<Hobbsee> oh wow.  i somehow feature on that list
<seb128> TheMuso: hi, will you do the a11y GNOME updates?
<pitti> seb128: what does "time gtk/jockey-gtk  --list" print for you? (real time)
<seb128> pitti:
<seb128> $ time /usr/bin/jockey-gtk --list
<seb128> real	0m5.777s
<pitti> seb128: could you replace /usr/lib/python2.5/site-packages/jockey/detection.py with http://people.ubuntu.com/~pitti/tmp/detection.py and check again?
<seb128> pitti: do you know how to disable the caching?
<pitti> it should print the same drivers, but *much* faster
<seb128> I know you can do it by echoing something somewhere
<pitti> seb128: which caching?
<seb128> the disk cache
<seb128> because
<pitti> seb128: the jockey slowness is 95% due to inefficient data structures, and only 5% due to modinfo/apt-cache calls
<seb128> ok
<doko> seb128: will you upload gnome-menus before beta?
<pitti> seb128: although I already optimized apt-cache show calls
<seb128> $ time /usr/bin/jockey-gtk --list
<seb128> real	0m4.955s
<pitti> ugh
<seb128> doko: yes, GNOME 2.22.0 tarballs flying today
<pitti> seb128: maybe try to remove the .pyc?
<doko> ok, thanks
<seb128> pitti: no, that's still the old version, with hot cache
<pitti> ah
<seb128> trying the new one now
<seb128> pitti:
<seb128> $ time /usr/bin/jockey-gtk --list
<seb128> real	0m1.648s
<seb128> much better ;-)
<doko> seb128: deskbar-applet alacarte  as well?
<pitti> hm, here it dropped from 5.5 to 0.9, but still
<seb128> doko: deskbar-applet yes, alacarte likely but I can do an upload if they don't roll a new tarball
<pitti> seb128: might be even faster with the .pyc then
<seb128> doko: do they just need a rebuild?
<pitti> seb128: ok, thanks; I think I can speed it up even further, but that's already something
<doko> seb128: yes, just trying to avoid unnecessary rebuilds
<seb128> pitti:
<seb128> $ time /usr/bin/jockey-gtk --list
<seb128> real	0m1.012s
<seb128> pitti: with the pyc
<pitti> \o/
 * seb128 hugs pitti
<seb128> doko: ok, will upload those
<seb128> pitti: so 5.7s to 1.0, that's good ;-)
<pitti> seb128: most of the time is spent on modalias pattern matching
<pitti> seb128: i. e. testing whether a modalias matches any of the globs in /lib/modules/2.6.24-12-generic/modules.alias
<seb128> pitti: can you cache that?
<pitti> seb128: I could pickle the entire (huge) data structure
<seb128> pitti: in fact is there any need to run jockey at all on a configuration which didn't change?
<pitti> seb128: depends; there might be a new driver available
<pitti> seb128: later, if we have remote driver DB check, I need to come up with something new
<pitti> seb128: but for now I could trash the cache if there's a new kernel or new hw
<seb128> pitti: right
<seb128> pitti: if the code is hard to optimize we can also try to delay the startup by 60 seconds or something
<pitti> seb128: that would indeed be better
<pitti> seb128: eventually, with network lookups, it'd might run a minute
<pitti> seb128: does gnome-session start jobs in parallel?
<seb128> yes
<pitti> ok, so it is just slow because it actually takes much CPU/IO
<seb128> the issue is mostly the number of ios
<pitti> not because the later session scripts are blocking on the previous one
<seb128> if you log again with a hot cache it's blasing fast
<seb128> like 5 seconds instead of 30 seconds on my laptop
<pitti> right
<lamont> seb128: it'd be wonderful if gnome-session allowed me to say "and wait for this to exit before launching anything else"
<pitti> seb128: hm, can I specify a delay in the .desktop file, or do I need a --sleep n option in jockey?
<seb128> lamont: would be nice but it's not designed for that right now
<lamont> yeah
<seb128> pitti: you need a --sleep for now
<pitti> seb128: ok; that's easy to add
<seb128> pitti: but we might want to consider for next cycle a way to delay startups and speak with upstream about it
<lamont> I've been resolving that since warty with a shell script and dpkg-divert
<pitti> seb128: Exec= is shell, or an actual command?
<pitti> seb128: i. e. would Exec=sleep 60; jockey-gtk --check work?
<pitti> s/command/program/
<seb128> pitti: I think it's a command, not sure though
<seb128> I've to go for lunch now but I'll have a look after that
<pitti> lunch -> me 2
<Amaranth> making gnome-session start compiz first and finish starting it before continuing with everything would probably speed it up quite a lot
<seb128> Amaranth: why?
<Amaranth> seb128: because it wouldn't have to deal with copying so many pixmaps into textures right at start time
<Amaranth> although that's something that should be faster (almost free) as drivers get better
<PecisDarbs> does daily livecd still goes in gdm login loop?
<Amaranth> PecisDarbs: you're an ati mobility user?
<PecisDarbs> well, yes, but this loop also appeared on non-ATI systems too
<PecisDarbs> Xorg starts succesfully, but when gdm counts secs and tries to login, it fails after some time and starts again
<Amaranth> ok then, not something i need to deal with :)
<PecisDarbs> :)
<Amaranth> on the ati that'd be your driver crashing Xorg as it tries to start compiz
<PecisDarbs> btw, live cd finally launches Xorg for Radeon Mobility successfully, thanks. Before that it screwed up frequencies up.
<ryanakca> dholbach: can you break your lock on the 5-a-day branch? http://pastebin.ca/936470
<dholbach> ryanakca: done - thanks for letting me know
<ryanakca> dholbach: cheers :)
<dholbach> ryanakca: I think you could have broken it yourself by just running      bzr break-lock      in the branch
<dholbach> but I'm not 100% sure
<dholbach> thanks in any case :)
<pitti> mvo: hm, according to you https://bugs.edge.launchpad.net/ubuntu/+source/scim/+bug/199030/comments/18 should be wrong?
<mvo> pitti: it used to be a global setting, but after some discussion it was decided it should be per-user
<tseliot> mvo: have you reviewed EnvyNG?
<zul> slangasek: pin
<zul> er ping even
 * jdong kicks scim
<jdong> I don't know what I'm pressing by accident, but my keyboard randomly switches to arabic
<jdong> as amusing as that is, it does get a bit irritating
<seb128> jdong: ctrl-space?
<jdstrand> hi pitti! how are you?
<jdong> seb128: ah, that's it
 * jdong unbinds the key
<ubotu> Launchpad bug 199030 in scim "Can't close SCIM" [High,Confirmed]
<mvo> tseliot: not yet, sorry
<ion_> Also shift-space
<tseliot> mvo: no problem, BenC has to review it too
<pitti> seb128: jockey autostart delay of a minute committed
 * seb128 hugs pitti, thanks ;-)
 * persia comments that ALT+` is a common alternate combination to open the IME for keyboards lacking a sensible åè§ï¼å¨è§ key for Japanese locales, if there is still interest in finding an alternative keystroke combination (shift-space is especially annoying when one has several IME-specific keys)
<ArneGoetje> persia: shift+space was the default key combination in kinput2 for japanese IME
<persia> ArneGoetje: Yes, I know.  I turned that off too :)
<ArneGoetje> persia: I don't linke it either.
<ion_> Alt+` would be a much nicer default.
<persia> Still, when one has a åè§ï¼å¨è§ one ought to be able to use it, and Alt+` seems to be the current standard choice for switching when one doesn't have special keys, for IMEs in common use by the average computer user.
<ArneGoetje> persia: and the debian package of scim also doesn't use it... so, I don't know who made the patch and why, but I suggest that it'll be changed. BUt we need to have some comments from japanese users here I huess...
<ArneGoetje> guess
<persia> ArneGoetje: I suppose it could be raised at the LoCo meeting tomorrow, if there is time...
<ArneGoetje> persia: that wold be an idea, yes
<pitti> glatzor: hi!
<pitti> glatzor: WDYT about changing p-distutils-extra to not merge po files all the time?
<persia> ArneGoetje: On another note, I'm still catching up on email backlog, but was it ever determined who could negotiate with IPA to help set an appropriate license?
<pitti> glatzor: it creates a lot of clutter in VCS, and at least I usually want to run it manually anyway
<ArneGoetje> persia: not that I know of. I just made my comment but I don't feel to be in a position to negotiate with them
<persia> ArneGoetje: Is that something you can escalate, or should I be chasing someone else?
<ArneGoetje> persia: I thought Jun Kobayashi has contact with IPA...
<ArneGoetje> persia: this is not only a Ubuntu specific issue...
<glatzor> pitti: servus, you are my prime user :) Feel free to change it. I am mostly using bzr-buildpackage, so I don't get any clutter
<pitti> glatzor: ah, that avoids it? nice
<glatzor> pitti: it builds in a different folder
<pitti> glatzor: ok, thanks; I'll think I'll fix it anyway and introduce a 'setup.py merge-po' command?
<persia> He does, but at the 2008 Spring Tokyo Open Source Convention, he reported that his discussions were left that they would like to discuss with someone representing Ubuntu internationalisation.  Do you feel that it should be delegated to Kobayashi-san, acting on behalf of Ubuntu?
<glatzor> pitti: got idea
<glatzor> good idea
<glatzor> :)
<ArneGoetje> persia: I'm not sure... if they want to talk to someone from Canonical, that would indicate that they really want to keep their self crafted license and just adjust it so that we can redistribute it as a partner package or so... but I'm of the opinion, that they should scrap their self-made license and adopt a available open source license... as I have never done such license negotiations before, I'd like to have some comments/advice from so
<persia> ArneGoetje: Well, I think it is somewhat complicated by the differences in the meaning of copyright in Japan and other places.  Japan is civil law, but not as flexible as many European jurisdictions.  Many standard open-source licenses are technically illegal.
<ArneGoetje> persia: see, I have no idea about that... so, I'm definietely not the right person to do the negotiations then... ;)
<persia> (not in that they violate the law, but in that they indicate actions not explicitly permitted by the law)
<persia> ArneGoetje: OK.  Maybe there is a licensing contact with whom Kobayashi-san can coordinate?
<ArneGoetje> persia: hmm... I don't know who does this kind of things... Business department?
<mvo> pitti: could you name it "setup.py update-po" ? that would be more consistent with the makefiles usually found in po/ ?
<persia> ArneGoetje: I've no idea at all.  Last person I asked suggested I contact you :)
<ArneGoetje> persia: not for licensing though. ;)
 * persia suspects it was a reflex CJK-fonts -> ArneGoetje response
<ArneGoetje> persia: probably
<dholbach> I doubt the business department can help with that - the archive admins deal with source code licenses the most
<ArneGoetje> dholbach: anyone you can suggest?
<persia> Any archive admins feel like coordinating with ubuntu-ja to help convince a Japanese government agency to release fonts in a DFSG manner?
<dholbach> ArneGoetje: anybody on https://launchpad.net/~ubuntu-archive/+members might know
<pitti> mvo: sure, I don't particularly mind
<mvo> thanks
<geser> pitti: Hi, please give-back: packagekit-gnome. Thanks
<wasabi> So is policykit going to slowly supplant gksudo?
<Mithrandir> geser: given-back.
<Amaranth> wasabi: that's the idea
<Amaranth> at least at first
<wasabi> I really like it.
<wasabi> Except when I logged in just now, it prompted me for my password... to cahnge timezones.
<wasabi> With no indication about WHY it wanted to change timezones.
<wasabi> And then the timezone got changed to the wrong one. :)
<luisbg> dholbach, ping
<dholbach> luisbg: pong
<pitti> geser: done
<Diablo-D3> hey all
<Diablo-D3> is it me, or has alsa broken on the newest kernel in hardy?
<stdin> http://launchpad.net/bugs/200338
<ubotwo> Launchpad bug 200338 in linux "no sound hardy kernel 2.6.24-12 " [Critical,Fix released]
<_MMA_> hahahah. Just started a new install because I thought I miffed something. :P
<Diablo-D3> thank god I left -11 installed
<ion_> Nice punctuation! In the bug report, i mean! That is, the one about the sound problem!
 * _MMA_ sees it most often from European kids and just doesn't get it.
<ArneGoetje> I'm a bit puzzeled with LP bug 199592, as I cannot reproduce it at all. Neither on the current Live CD image (from today), nor on my local system with the latest packages installed... Can anyone else reproduce the reported crash? Aparently it should be a common issue, as there are so many duplicate bug reports for it... :-/
<ubotwo> ArneGoetje: Bug 199592 on http://launchpad.net/bugs/199592 is private
<pitti> cjwatson, TheMuso: any chance you could test the newer b43-fwcutter from Debian? (bug 199994)
<ubotwo> Launchpad bug 199994 in b43-fwcutter "Use version 4.80.53.0 of Broadcom's proprietary driver. " [Undecided,In progress] https://launchpad.net/bugs/199994
<adrian15> Hi... Is there any Ubuntu installation - GRUB setup developer round here? Or anyone who can point me to its source code? I want to know if you use device commands to contemplate the Windows chainloading of Ubuntu's grub partition boot sector codes.
<slangasek> zul: pong
<zul> slangasek: hi, a couple of things I notcied that there is samba-2.0.28a in the svn tree I was wondering when its going to be in unstable, and there is a whole bunch of ebox modules that is stuck in new I was wondering if you can get those in the archive
<slangasek> zul: I don't have an eta for samba 3.0.28a in Debian, I'm leaving that up to Christian; the NEW processing I'm working through this morning, yes
<zul> slangasek: thanks..
<shaya> is there a problem w/ sound in feisty's kernel?
<shaya> I mean gutsy's
<shaya> snd: Unknown symbol unregister_sound_special (and the like)
<ion_> Yes. A fix is being built.
<slangasek> you mean hardy's... :)
<shaya> right
<shaya> yes
<Pici> shaya: see topic in #ubuntu+1
<shaya> ah, ok
<slomo_> doko: yes
<doko> slomo_: thanks, last d/b-d on python-xml in main
<slomo_> doko: don't worry, tomorrow early in the morning :)  did you take a look at my patch? my python is not good and it works but that's all i can say about it ;)
<doko> slomo_: I don't care as long as you can still read the docs ;)
<ion_> themuso: Re: your change in initramfs-tools 0.85eubuntu27, wouldnât cp -al suffice instead of ln -f || cp -a?
<ion_> themuso: Sorry, i remembered how -l works incorrectly.
<LaserJock> anybody know if shipit is going to ship Ubuntu Alternate CDs for hardy?
<LaserJock> I haven't heard anything yet
 * _MMA_ waves at LaserJock but doesn't know the answer.
<LaserJock> pfft, lotta good you are ;p
<_MMA_> Yay! I'm useless!
<mario_limonciell> _MMA_, why?
<_MMA_> mario_limonciell: Because of my inability to answer Jordan. ;)
<mario_limonciell> oh I thought you were meaning because of the sound fiasco atm :)
<LaserJock> mario_limonciell: no, he must have an answer to all of my questions to feel any sense of usefulness ;-)
<_MMA_> Yes. It's tied to my self-worth.
<mario_limonciell> well some people have "mommy issues" or "daddy issues".  you've just got issues with independence.  i guess that's alright
<LaserJock> "LaserJock issues"
<mario_limonciell> step 1 is admitting you've got a problem.  we'll work on it at UDS
<_MMA_> Or Jordan and I will work on it if I get him to Raleigh. ;)
<LaserJock> lol
<ar3ac> latest update give me troubles with my sound card
<_MMA_> ar3ac: Known on Hardy. Use old (-11) kernel.
<ar3ac> ok thanks
<ar3ac> i'm reading the launchpad now
<ar3ac> even quicker workaround:
<ar3ac> sudo cp /lib/modules/2.6.24-11-generic/kernel/sound/soundcore.ko /lib/modules/2.6.24-12-generic/kernel/sound/
<ar3ac> sudo depmod -a
<ar3ac> sudo modprobe snd-hda-intel (or whatever you need)
<ar3ac> and sound works again :)
<slangasek> ogra_cmpc: why does classmate-tools depend on the desktop metapackages?  that seems an odd way to arrange it
<ogra_cmpc> slangasek, its a tray icon it needs a system tray and an xdg capable desktop
<slangasek> huh, ok
<mario_limonciell> surely there are saner ways to install xdg compatible desktops?
<ogra_cmpc> might be
<slangasek> mario_limonciell: saner ways to request an xdg-compatible desktop, I would think
<slangasek> but no matter
<mario_limonciell> well but doing it this way, what if someone was to want to remove say ubuntu-desktop because they were maybe removing evolution since they didn't need it.  wouldn't classmate-tools break then?
<slangasek> it would uninstall
<nxvl> is there any ubuntu-drivers channel?
<mario_limonciell> exactly, so it really should be depending on the packages that provide the system tray, like gnome-panel, pypanel, etc then
<cjwatson> nxvl: you mean like the ubuntu-drivers team in Launchpad, or like kernel drivers?
<nxvl> cjwatson: i mean the irc channel where the people who take care of the driver are, where i can find someone to report the problem with my sound card
<nxvl> or/and to point me where i can report it
<nxvl> :D
<_MMA_> nxvl: -12 hardy kernel?
<zdzichuBG> heh, fedora people also lost sound with latest kernel upgrade ;)
<_MMA_> nxvl: If so, known issue. Will be fixed. Use -11.
<cjwatson> nxvl: #ubuntu-kernel; if it's sound, they're already on it
<mario_limonciell> nxvl, yeah it's been quite reported.  you can look at http://launchpad.net/bugs/200338 if you'd like to see about it
<nxvl> _MMA_: yep, that's it, when i upgraded it to -12 problems started :D
<nxvl> thanks all for his reponses!!
 * nxvl HUGS all
<LaserJock> cjwatson: do you know if Ubuntu Alt will be available on shipit for Edubuntu?
<cjwatson> LaserJock: I don't, sorry; I can ask
<cjwatson> LaserJock: the relevant people have gone home, though, so send me mail to remind me?
<LaserJock> cjwatson: k, I just wondered as we had some questions in #edubuntu and I didn't really know what to say
<_MMA_> Anyone know if samba is not working in Hardy? (might just be me)
<candrews> https://bugs.launchpad.net/ubuntu/+bug/199754 I'm attempting to solve that issue (packaging mod_auth_cas). I have a package made, but when I load the module into apache, I get: Can't locate API module structure `authcas_module' in file /usr/lib/apache2/modules/mod_auth_cas.so: /usr/lib/apache2/modules/mod_auth_cas.so: undefined symbol: authcas_module
<candrews> Can someone give me a hand to finish up this package?
<slangasek> _MMA_: I know I just uploaded it yesterday, what's up?
 * lamont wonders if slangasek gets annoyed by sync requests prior to dinstall even running...
<_MMA_> slangasek: Well trying to browse with "Network" doesnt work. And after installing samba, smbfs and setting up fstab, the mounts dont come up.
<slangasek> lamont: no, I just sit on them in favor of using my time more wisely :)
<slangasek> _MMA_: is this a recent behavior change for you?
<_MMA_> slangasek: Well, because using "Network" previously threw an error, I didn't jump to Hardy. After testing dailies, and saw the error was gone, I did a clean install on my main box thinking all was fine.
<_MMA_> slangasek: Ive set things up the same way since Warty. Im unsure what's different.
<slangasek> _MMA_: what's the server that you're trying to mount from?
<_MMA_> slangasek: Ubuntu-Gutsy running samba.
<lamont> slangasek: heh. ok
<lamont> slangasek: it'll be a sync request for bind9 1:9.4.2-5 for hardy.
<slangasek> _MMA_: oh, curious then.  The smbfs kernel driver is deprecated now in favor of cifs and mount.smbfs is now a thin compat layer on cifs, but that shouldn't normally be a problem for samba<->samba
<slangasek> _MMA_: are you using credentials files?
<_MMA_> slangasek: No. I have the user/pass defined in the fstab line.
<lamont> feh.  for that matter, it's easier to file the sync request after packages.d.o updates
 * lamont adds to tomorrows list
<slangasek> _MMA_: I think I'd need to see the fstab line (minus the password) to diagnose, then
<_MMA_> slangasek: Sure. 1 sec in PM.
<wasabi> I just ran into another app that failed on Ubuntu 64 because of missing winbind nss/pam modules.
<wasabi> (32 bit app)
<wasabi> Alas.
 * wasabi finds existing bug report from a year ago.
<candrews> I'm attempting to package mod_auth_cas, I have everything done, except when I try to load the module into apache, I get this error: /usr/lib/apache2/modules/mod_auth_cas.so: /usr/lib/apache2/modules/mod_auth_cas.so: undefined symbol: authcas_module
<candrews> Can someone help?
<_MMA_> candrews: Packaging help is best in #ubuntu-motu.
<candrews> thank you - I'll ask there.
<_MMA_> np
<slangasek> wasabi: what app, OOI?
<TheMuso> ion_: The idea is to hard link, rather than copy. We only copy if the hard link fails.
<ion_> themuso: Yes, and i misremembered that cp -l behaved just like that. :-)
<ion_> themuso: Instead, it just fails if linking fails.
<slangasek> glatzor: packagekit-gnome: "refreshing the cash"? :)
<glatzor> slangasek: :)
<slangasek> glatzor: s/cash/cache/, if that wasn't evident
<glatzor> slangasek: I am currently uploading new packages to the ppa of the packagekit team.
<glatzor> slangasek: the packages in universe are quite "rough"
<slangasek> heh, ok
<TheMuso> seb128: Yes, I'm on a11y stuff, which is mostly sponsored uploads.
<seb128> TheMuso: right, that was not the case when I asked some hours ago ;-)
<blueyed> Does somebody know if apt is supposed to resolve the "virtualbox-ose-modules" dependency of virtualbox-ose correctly (bug 188579) or if there's a workaround to give more hints for apt?
<blueyed> It's fairly critical, because often wifi fails with the (new) -386 kernel.
<blueyed> https://launchpad.net/bugs/188579
<soren> blueyed: If I apt-get install virtualbox-ose-modules, apt wants to install   virtualbox-ose-modules virtualbox-ose-modules-2.6.24-12-generic virtualbox-ose-modules-generic
<soren> blueyed: That looks correct, doesn't it?
<shaya> the updated kernel for hardy that fixes sound taints the kernel
<shaya>  snd: no version for "unregister_sound_special" found: kernel tainted.
<blueyed> soren: yes, that looks correct. But if you apt-get install virtualbox-ose it's more likely to do not so..
<soren> blueyed: http://paste.ubuntu-nl.org/59198/
<blueyed> soren: are you on amd64 maybe? Do you have virtualbox-ose-modules-386 installable?
<soren> blueyed: Ah, good point.
<blueyed> I've thought about changing order as a (particular) workaround already, but that's not the root cause, so..
<alefteris> could someone please point me to the package/code that is setting up the keyboard layouts (depenting on the language selection at boot) in the live cd and also the installed system?
<tjaalton> alefteris: xkeyboard-config
<blueyed> soren: http://paste.ubuntu-nl.org/59200/
<soren> blueyed: Why is virtualbox-ose-modules a real package?
<blueyed> soren: For automatic upgrades.. with only virtual packages they weren't upgraded automatically.. also the required(?) Replaces caused problems..
<alefteris> tjaalton, will I be ale to define what layouts are loaded by default when a user selects for ex. Greek during the live cd boot? currentry in alpha 6 no latin layout is loaded, only the greek one. So its difficult to use the live cd or make the installation
<cjwatson> alefteris: tjaalton is correct in that that's where the data comes from, but console-setup and xserver-xorg between them are what actually do the work
<cody-somerville> The latest uploads seem to break sound on my laptop :/
<blueyed> soren: Maybe depending on a particular kernel image in the meta packages would help?!
<tjaalton> alefteris: I'm not that familiar with how it works, so can't answer :/
<cjwatson> alefteris: console-setup has a scheme for dealing with that; please file a bug on https://bugs.launchpad.net/ubuntu/+source/console-setup/+filebug and we can deal with it
<soren> blueyed: Only for users of -generic kernels :)
<alefteris> ok thanks cjwatson and tjaalton
<cjwatson> alefteris: interestingly, it's supposed to be dealt with properly already
<cjwatson> alefteris: so there's a deeper bug somewhere and I'd definitely like a report so that we remember to investigate
<mamefan> there's an ALSA bugfix that's been in the ALSA source for a while.  How does that get into ubuntu (it's still broken for me in the ubuntu packages)?
<cjwatson> alefteris: please attach /etc/default/console-setup and /etc/X11/xorg.conf to the bug you file
<amitk> mamefan: we are using alsa from upstream. Best way to track your problem is to file a bug in launchpad.net and point to the patch.
<soren> blueyed: Maybe I can find a bit of time tomorrow to look into it. Right now, I need some sleep.
<blueyed> soren: that would be great. AFAIR it also affects apparmor e.g.
<cjwatson> alefteris: ... and /var/log/casper.log while you're at it
<mamefan> amtik:  forgive my ignorance but I'm not really sure what that means.  I don't know what "patch" to point to.  I simply know that if I donwload the alsa-driver source from alsa and compile it on my machine it works.
<alefteris> cjwatson, its difficult to issue them, without chaning the default live cd keyboard settings, as Im not able to type in latin, so I would have to add manualy the us layout before issuing those commands. is that ok?
<cjwatson> alefteris: if you do it in GNOME, yes, that's fine
<cjwatson> alefteris: failing that, a precise description of exactly what you selected at the CD boot menu will probably be enough
<alefteris> ok i will get to it right away, thanks
<YokoZa1> Does apt URL support multiple package downloads in a single link?
<YokoZa1> Like can I do something like apt://package1+package2  ?
<cjwatson> could somebody please provide a French->English translation of bug 199457?
<ubotwo> Launchpad bug 199457 in openoffice.org "Impossible de filtrer les enregistrements dans un mailing" [Undecided,New] https://launchpad.net/bugs/199457
<LjL> i'll try
<cjwatson> thanks
<LjL> done, as well as i could
<cjwatson> LjL: thanks!
<Riddell> pitti, doko: would either of you be able to MIR review bug 200799 before beta freeze?  it's just a widget style
<ubotwo> Launchpad bug 200799 in kde-style-qtcurve "kde-style-qtcurve inclusion to the main repository" [Undecided,New] https://launchpad.net/bugs/200799
<alefteris> cjwatson, here you are https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/200803
<ubotwo> alefteris: Error: Could not parse data returned by Launchpad: The read operation timed out
<cjwatson> alefteris: thanks
#ubuntu-devel 2008-03-11
<doko> Riddell: I'll look at it tomorrow. please ping me after lunch. heading to bed now
<essial> can anyone here spare a moment to help get me started contributing to ubuntu as a developer?
<RAOF> essial: #ubuntu-motu is probably where you want to be.
<essial> thats what I was looking for! thanks
<TheMuso> Hrm. Rsync server seems to be struggling a bit.
<wasabi> Hmm. Some reason current hardy won't load the sound alsa modules for my driver on one of my machines. Spews out about unknown symbols in nearly all of the alsa modules.
<ScottK2> wasabi: Known issue.  I new kernel is being rolled.
<wasabi> Ahh. OKay.
<_MMA_> wasabi: Update. Should be fixed now.
<wasabi> Upgrade new machine to hardy, and hit it on a day something is broken. =)
<jdong> wasabi: yeah I ran into that earlier today; quite amusing :)
<calc> anyone know how to fix the timezone stuff in hardy to work for the US?
 * calc looks to see if there are any updated packages to fix it
<johanbr> calc: What needs fixing?
<calc> it still thinks i am CST (US Central) its CDT (US Central Daylight) now
<calc> i thought that was updated several releases ago
<johanbr> It switched correctly for me.
<johanbr> I'm not in CST though.
<calc> johanbr: the US changed the date switchover a while back
<calc> so i am confused why it is affecting me
<calc> lamont: ping
<calc> oh he just timed out reconnected
<johanbr> I know. As did Canada.
<calc> ah you are in canada :)
<ScottK2> calc: nixternal is in your timezone and runs hardy.  We should check with him ...
<superm1> i'm CST too nad run hardy
<superm1> had no problems with mine
<calc> nixternal: ping
<calc> superm1: oh
<calc> hmm, i'll rerun the time setup program
<superm1> calc, what timezone do you currently have listed in /etc/timezone?
<superm1> I just put America/Chicago
<superm1> .
<calc> yea that
<superm1> hm
<calc> what the hell
<calc> Therefore TZ='America/Chicago' will be used.
<calc> Local time is now:	Mon Mar 10 21:35:11 CDT 2008.
<calc> Universal Time is now:	Tue Mar 11 02:35:11 UTC 2008.
<calc> root@laptop-c2d:~# date -R
<calc> Mon, 10 Mar 2008 20:35:22 -0600
<slangasek> calc: yes, is this hardy/GNOME?
<calc> yea hardy/gnome
<slangasek> do you have the clock applet on your panel?
<calc> does Gnome hate the US? ;-)
<calc> yea
<superm1> i'm on hardy/gnome too :)
<slangasek> right-click it, what does it give you for 'locations'?
<slangasek> eh, left-click rather
<nixternal> what's up?
<calc> london, uk and houston
<nixternal> wasabi calc
<superm1> nixternal, you broke calc
<superm1> way to go.
<calc> it got put as America/Monterrey for Houston
<calc> grr
<nixternal> yay!
<slangasek> calc: right, there you go :)
<nixternal> I got my tzupdate at 02:00 on Sunday
<calc> slangasek: why does that screw up root's idea of time?
<nixternal> none of the Windows boxes recognize the change in time, but Kubuntu did
<slangasek> calc: because when you choose a location from the clock applet, it uses policykit to set the timezone for the system :P
<calc> i'm pretty sure i had set it to america/chicago in the past as well
<wasabi> Hi.
<wasabi> Oh yeah, when I got into work this morning PolicyKit asked me to auth.
<wasabi> And then it changed my timezone. Wrongly.
<calc> slangasek: which overrides tzselect and /etc/timezone?
<slangasek> which makes it all the more annoying that the new clock UI is so cumbersome
<wasabi> It obviously WANTED to change something. Which confused me. I thought the timezone dealt with it and wouldn't need to be changed.
<slangasek> calc: yes
<calc> slangasek: eek, that sux :-\
<wasabi> Apparently it sent me to America/Monterry. Which I am not in. Also I *hate* our usage of the city-based timezones.
<wasabi> I much prefered the good ol' days of US/Central
<wasabi> And not having to pick the city that sort of lined up with where I live.
<calc> wasabi: apparently cities is easier than determining if your location has screwed up timezone rules
<calc> eg Indiana ;-)
<wasabi> I see. Then somebody should add all possible cities.
<wasabi> =)
 * superm1 nominates nixternal
<slangasek> how about if they first work on getting the panel to not segfault when you pick a city it doesn't like
<wasabi> Hehe.
 * calc wonders why gconftool is using 100$ cpu
<calc> er 100%
<wasabi> By the way. THis should obviously Just Work if you have a gps.
<wasabi> OBVIOUSLY
<johanbr> Speaking of the clock, does anyone know where it gets the weather data? My weather is always off.
<slangasek> johanbr: weather.noaa.gov; mine's off too, it fails to match the information at the source website
<ion_> An airport.
<calc> johanbr: type a city and hit find
<_MMA_> Ahh... So that's why there's that extra space to the side of the date. Looks odd though if you dont have a location set. Maybe weather/temp shouldnt be enabled by default?
<calc> johanbr: i missed the find button part at first
<slangasek> johanbr: I haven't figured out yet if it's a bug in libgweather or the panel, debugging your panel is a PITA
 * calc somewhat dislikes it doesn't display all the same info as the weather app
<calc> so it reimplements it poorly
<calc> OMG
<calc> i just refound Houston and it set the Timezone back to America/Monterrey
<calc> so it is broken itself
 * calc kicks gnome clock applet pos
<slangasek> calc: feel free to append to bug #199582 :)
<ubotwo> Launchpad bug 199582 in gnome-panel "worldclock picks wrong timezone for Portland, OR" [Undecided,Confirmed] https://launchpad.net/bugs/199582
<calc> great :-) the I HATE GNOME thread, lol
<slangasek> I don't hate GNOME, just the new clock that doesn't work right
<calc> heh
 * calc was joking
 * ScottK2 doesn't hate Gnome either.  He just doesn't use it.
<ion_> I hate Gnome, but itâs not as if there are any viable alternatives. ;-)
<johanbr> The Portland part of that bug is somewhat hypothetical, since Portland and Vancouver *are* in the same time zone.
 * TheMuso watches as the can of worms is opened up.
<slangasek> johanbr: no, they're not
<johanbr> Sure they are.
<slangasek> Portland is in America/Los_Angeles, Vancouver is in America/Vancouver.
<johanbr> Which, as far as timekeeping is concerned, are identical.
<ScottK2> calc: Why is Houston America/Monterrey?  Won't Mexico have different TZ rules?
<TheMuso> Is it just me, or is cdimage quite busy/slow atm?
<slangasek> johanbr: The two zones are *currently* in sync.  They have not been, historically.
<ogra_cmpc2> TheMuso: it was shaky for me the last week already ... havent snced since friday though
<ogra_cmpc2> *synced
<calc> ScottK2: that is the bug
 * calc rereads his message
<calc> yea i wrote it correctly
<calc> gnome suggests monterrey it should suggest chicago
<ScottK2> calc: OK.  Got it now.
<johanbr> Now I know why my weather is off: http://bugzilla.gnome.org/show_bug.cgi?id=514333
<ubotwo> Gnome bug 514333 in clock "'world clock applet' and 'weather report applet' show different temperatures" [Normal,Unconfirmed]
<calc> johanbr: i think the weather functionality is rather useless in the clock since it doesn't fully replace the weather applet
<calc> so if you are actually interested in the weather you need the weather applet still :-\
 * ogra_cmpc2 dances around http://people.ubuntu.com/~ogra/classmate/images/hardy/ :)
<ogra_cmpc2> (and goes to bed...)
<johanbr> calc: Just because my beer in the fridge doesn't replace a full-scale brewery, that doesn't mean it's useless. :)
<calc> johanbr: it gives the feels like temperature, no pressure, no humidity, no various other things, no forecast, no weather map
<calc> johanbr: and if you enable it eats as much space as a full weather applet on your taskbar
<johanbr> Right. But if I'm just too lazy to look out the window, it'll do fine. :)
<calc> actually that last part can be turned off apparently
 * calc can't determine humidity, etc from looking out a window ;-)
<slangasek> johanbr: except for the part where it can't tell the temperature right...
 * calc thinks it should use the weather applet so if you click on it pops open
<calc> have the icon in the locations part be a link to the full screen bit that pops up from the weather applet
<calc> er 'Details'
<calc> that way i could get details of any cities i want to have in locations without having to have a seperate weather applet icon for each on my taskbar
 * calc should file a gnome bug about it
<calc> what changed recently with fonts in Gnome?
<calc> it seems much different
<calc> everything seems er fatter
<calc> or at least the bold stuff does
<Fujitsu> I think the fonts are nicer, except for a couple of glitches, and the bold.
<calc> yea they look like an improvement, i was just wondering what changed
<calc> would be helpful to know so i can try to fix openoffice to be the same
<venenux> alguien habla espaÃ±ol???
<venenux> somebody speak spanish???
<venenux> ok i need some help with ubiquity installer
<venenux> somebody know about it?
<venenux> helloooooooo
<Fujitsu> !es
<ubotwo> Si busca ayuda en espaÃ±ol por favor entre en los canales #ubuntu-es o #kubuntu-es, allÃ­ obtendrÃ¡ mÃ¡s ayuda.
<venenux> i speak english too
<venenux> but do you can helpme in english ??
<Fujitsu> Perhaps in #ubuntu. This channel is not for support.
<venenux> ok thanks for nothing
<ion_> Eh :-)
<venenux> i hate ubuntu users you think ubuntu is the best but dont, is too slow
<StevenK> Nice to meet you, too.
<Fujitsu> Indeed.
<ion_> But itâs true, AmigaOS can calculate digits of Ï 50% faster than Ubuntu.
<Fujitsu> Looks like artigas needs kicking.
<infinity> Fujitsu: Kicked.
<Fujitsu> infinity: Thankyou muchly.
<Fujitsu> Hmmm, why is there stuff with ~hardy1 versioning in Hardy's NEW?
<dholbach> good morning
<Fujitsu> Hi dholbach.
<dholbach> hey Fujitsu
<dholbach> how are you doing?
<Fujitsu> Not great, but getting better. Been a bit sick over the past week or so.
<Fujitsu> You?
<superm1> Fujitsu, stuff that was synced from debian by a core-dev or motu i'd guess?
<dholbach> ugh... hope you're up to your usual 150% soon again!
<superm1> and they didn't want to go through the "normal" sync
<dholbach> hey superm1
<superm1> hey dholbach good morning
<Fujitsu> superm1: I guess, but there are cleaner ways to fake a sync.
<superm1> Fujitsu, but if that's the reason, then I assume they didn't realize it'd end up in NEW
<Mithrandir> pitti: sparc being broken, is that known? http://launchpadlibrarian.net/12550921/buildlog_ubuntu-hardy-sparc.bluez-gnome_0.23-0ubuntu3_FAILEDTOBUILD.txt.gz
<Mithrandir> pitti: pkgbinarymangler's striptranslations seems to be the culprit.
<infinity> Mithrandir: Eh?
<infinity> Mithrandir: How is pkgstriptranslations to blame for libg* being out of sync on Sparc?
<Mithrandir> infinity: sorry, it's still early morning here and I managed to think the conffile prompt broke something.
<Mithrandir> infinity: I'm not sure how I managed that, but bigger wonders have happened in the early mornings.
 * Mithrandir goes back to hiding under a rock
<Vhata> what's the status of this: https://wiki.ubuntu.com/LTSUpgrades ?  (And where's the right place to discuss it?)  It seems to be at a standstill, and it's quite an important feature - I know a lot of people are relying on it to get from dapper to hardy on their servers
<Vhata> it's marked as 'essential' here: https://blueprints.launchpad.net/ubuntu/hardy  - but it's the only one that isn't approved
<pitti> Good morning
<pitti> Riddell: ok, I'll have a look at MIR today
<pitti> Mithrandir: hm, that looks like an absolutely normal arch/any desync to me, as we always get with new GNOMEs
<pitti> Mithrandir: given back
<infinity> pitti: It'll fail again, I'm sure.  I need to probably untangle sparc.
<pitti> hm
<infinity> Slow arches always get screwed with new GNOME.
<infinity> pitti: If you want to trace it back through sparc failure and untangle it for me, more power to you.  I need sleep.
<slangasek> pitti: speaking of MIR; is 195519 on your list, or are you and I deadlocked thinking the other is going to look at it first?
<pitti> slangasek: actually locked on someone getting it into universe
<pitti> o_O
<pitti> update-signature crashed
<pitti>   File "/usr/lib/python2.5/site-packages/launchpadbugs/http_connection.py", line 121, in _safe_urlopen
<pitti>     raise Error.LPUrlError("login failed", url)
<pitti> launchpadbugs.bughelper_error.LPUrlError: 'login failed https://launchpad.net/bugs/200089/+text'
<ubotwo> pitti: Error: This bug is private
<pitti> thekorn: ^
<pitti> ah, private
<pitti> dholbach: ^ seems update-signature does not get along with private bugs
<slangasek> pitti: oh, then I don't think that was communicated to the submitter; your last comment was that PPA was sufficient for an MIR review?
<dholbach> pitti: grmbl
<pitti> slangasek: right; I just made a followup comment for clarifying
<slangasek> pitti: ok, cheers
<dholbach> pitti: bug filed
<mdke> hi all. Does anyone know if about-this-computer is going to be included in hardy?
<pitti> Keybuk: ^ ?
<Fujitsu> Can I convince someone to kick suitesparse through binary NEW now?
<mdke> thanks pitti - I will try the desktop ML
<stgraber> moin
<dholbach> GRRRR
 * Fujitsu runs.
<dholbach> why does my ubuntu-docs upload stall at 37125k / 37126k
<dholbach> for the second time now
 * dholbach uploads to a faster host and re-uploads from there
<dholbach> Â¡Â¡Â¡ GRRRR !!!
<\sh> how broke the shadows on intel gras? ;)
 * Fujitsu quickly attacks said faster host.
 * dholbach strangles Fujitsu with passion
 * Fujitsu predicted that.
<dholbach> :)
 * dholbach hugs Fujitsu
<pitti> hi stgraber
<stgraber> hi pitti
<dholbach> sladen: I subscribed you to a bunch of acpi-support patches on http://people.ubuntu.com/~dholbach/sponsoring - do you think you'll have some time to look at them?
<pitti> Fujitsu: suitesparse NEWed
<Fujitsu> pitti: Danke.
<MacSlow> hey seb128, mvo, pitti, asac
<asac> hi!
<pitti> hey MacSlow
<\sh> hmm...for what is feisty-gdm-themes for? it creates a strange /usr/shareFeisty
<mvo> hey MacSlow
<Chipzz>   din> http://launchpad.net/bugs/200338
<ubotwo> Launchpad bug 200338 in linux "no sound hardy kernel 2.6.24-12 " [Critical,Fix released]
<Keybuk> mdke: at this point, I would say no
<soren> I'm curious what'd happen if an ubuntu bug had a bug task against ubuntu-doc and it got closed by changelog-closes-bugs..
<Keybuk> soren: the ubuntu task gets closed, the ubuntu-doc one shouldn't
<soren> mkay.
<soren> Erk... Edgy's usplash looks *horrible* in kvm.
<soren> Hm.. Only the amd64 one. *shrug*
<soren> whoops
<Wartorn> It seems the newest xserver-xorg-video-intel is even worse than the previous version (alpha 6), compiz is now running terribly slow, 3d games have tons of artifacts etc (Intel X3100). Anyone know about this?
<tjaalton> Wartorn: Xorg.0.log or didn't happen
<Wartorn> http://pastebin.org/23187
<Wartorn> contains some weird warnings etc, not sure what to make of it..
<tjaalton> Wartorn: seems like the new greedy patch is broken after all
<Wartorn> greedy?
<Mithrandir> Wartorn: fwiw, I got just fine performance from flightgear, but I see the artifacts.
<Wartorn> You have the X3100 chip?
<tjaalton> Wartorn: EXA feature
<Wartorn> "fine performance" means what? im getting like 5-10 fps no matter what setting
<Wartorn> Though, this isnt really an issue of performance per se, since it seems the intel driver cant really use the x3100 chip properly. its just the compiz slowness/artifacts
<tjaalton> I'll upgrade my laptop first and check out what's going on
<tjaalton> Wartorn: hmm? it has supported it for a long time
<Wartorn> Well, prolly has, but im getting terrible performance and opengl crashes all the time.. seems others are too, as far as i can tell from browsing the web
<tjaalton> Wartorn: you are talking about mesa
<Wartorn> oh, okay
<Wartorn> Dont know too much about the driver-system in nix yet
<tjaalton> 2D driver works fine, 3D most likely has some issues
<Mithrandir> Wartorn: 40-50 fps, I think
<Wartorn> yeah, 2d works fine
<tjaalton> but that holds true for other drivers too
<Wartorn> Mithrandir: What card?
<Mithrandir> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<Mithrandir> whatever that translates to in marketing terms.
<Wartorn> You kidding me? damnit, i got the same, and its running at 5-10 fps max
<soren> mvo: Do you have a clue about https://bugs.edge.launchpad.net/ubuntu/+source/virtualbox-ose-modules/+bug/188579 ?
<ubotwo> Launchpad bug 188579 in apt "Installing virtualbox-ose-modules pulls in 386 kernel (on -generic)" [Medium,Confirmed]
<tjaalton> Mithrandir: are you running -1ubuntu3?
<Mithrandir> well, I didn't count it, but it was running just fine, performance-wise.
<Wartorn> Its not with me :(
<Mithrandir> tjaalton: just let me reboot this laptop to make sure I'm actually using the latest kernel and all.
<Wartorn> Man, this is an issue that has been annoying me for ages.
<tjaalton> Wartorn: where did you upgrade from?
<tjaalton> which version I mean
<Wartorn> What do you mean?
<tjaalton> gutsy or earlier hardy?
<Wartorn> 7.10 to hardy about a week ago, and the update i did today broke stuff
<Wartorn> or, well, gave me the artifacts etc
<tjaalton> but before the latest update the performance was fine?
<Wartorn> Well, not FlightGear fps etc, but Compiz worked fine
<Wartorn> Compiz just makes video very slow, and all the fading effects jitter/are not smooth
<tjaalton> there's another patch for that
<Wartorn> well, generally, the whole usage feels slower with it on, now
<Wartorn> oh, and even with compizconfig-settings-manager installed, i cant select "custom" settings on the appearance menu anymore
<tjaalton> mvo: you had the patch for -intel that enables hw-overlay for 965 video?
<RAOF> Wartorn: That's because it's now hooked up to ccsm-simple, or some such.
<Wartorn> RAOF: Not sure exactly what that means :) Any way to fix it?
<RAOF> Wartorn: "sudo aptitude install simple-ccsm" :)
<Wartorn> But i'd be amazingly happy if anyone could fix my issues with the graphics chip. 8 fps in flightgear in 800x600, with my x3100, 2ghz dualcore and 2 gig ram just seems absurd
<Wartorn> aight, thanks :)
<Mithrandir> tjaalton: yes, I am.
<Mithrandir> still fine performance.  I see glitches though.
<mvo> tjaalton: yes, I have that one
<Wartorn> Mithrandir/mvo: Have you done anything to fix the X3100 out of the box? if so, what?
<mvo> tjaalton: last time I talked with bryce about it he was hesitant to include it, but I think its quite important
<Mithrandir> Wartorn: no, I havent' fiddled with the xorg setup at all, except enabling wacom
<ionstorm> why is there a fps difference when compiz is enabled
<tjaalton> mvo: url? I'll test it on my laptop
<mvo> Wartorn: I did a package for -intel some days ago that changed i965 to use hardware overlay, I need to check if it is still up-to-date
<ionstorm> ever try glx gears with compiz enabled and then disabled? big fps difference on nvidia cards
<ionstorm> thousands of frames
<RAOF> Because glxgears isn't a benchmark of 3d performance.
<Wartorn> Would that make my flightgear fps better or not? just asking, to make sure we're discussing the same thing
<ionstorm> RAOF, what is a good benchmark?
<RAOF> ionstorm: A game?  OpenArena?
<ionstorm> btw, anyone know how to enable showfps
<ionstorm> in openarena
<mvo> tjaalton: http://people.ubuntu.com/~mvo/tmp/xserver-xorg-video-intel_2.2.1-1ubuntu3.debdiff <- that is the debdiff - you need to set "TexturedVideo" to "false" in the device section to make it work (that should be the default in the final patch)
<pitti> cjwatson: "can't use authenticated mode on repository 'http://launchpad.net/~ubuntu-core-dev/launchpad-integration/ubuntu' since it is not a known repository (e.g. alioth)"
<ionstorm> RAOF, what is the /showfps command for openarena
<pitti> cjwatson: I thought that was fixed in debcheckout?
<tjaalton> mvo: thanks, I'll try it
<RAOF> ionstorm: I don't know?  /showfps? :)
<mvo> Wartorn: its currently a bit experimental, I think I would like it polish it a bit first before it can get wider testing
<ionstorm> RAOF, rofl, no idea
<cjwatson> pitti: should be bazaar.launchpad.net not launchpad.net
<pitti> cjwatson: ah; well, bzr get'ing that URL works
<tjaalton> yeah, greedy is definately not enabled with the latest version
<mvo> Wartorn: but if you are adventurous please follow the instructions I gave tjaalton :)
<Wartorn> Well, the state im in now, with graphics basically broken, i'd be glad to help
<cjwatson> pitti: ah, hmm
<pitti> cjwatson: I'll change it, though
<Wartorn> yeah, but how do i use a debdiff file like that?
<tjaalton> Mithrandir: check that your xorg.conf does not have anything extra :)
<cjwatson> pitti: do file a bug against devscripts though
<tjaalton> Wartorn: just set 'Option "MigrationHeuristic" "greedy"' for now, until a fix is uploaded
<Wartorn> in Xorg.conf?
<tjaalton> yep
<mvo> tjaalton: even with greedy (at least I think it was enabled) fullscreen video was not very impressive for me
<tjaalton> device-section
<tjaalton> mvo: yep, jerky as h*ll
<pitti> cjwatson: done, bug 200924
<ubotwo> Launchpad bug 200924 in devscripts "debcheckout does not regognize http://launchpad.net/ URLs" [Undecided,New] https://launchpad.net/bugs/200924
<cjwatson> ta
<Wartorn> tjaalton: Okay, so how do i know when a patch is released (and when can we expect it?) and do i need to remove it then?
<tjaalton> sigh.. nvidia really should fix the memleaks.. compiz eats all my RAM after a couple of days
<tjaalton> Wartorn: you don't need to remove it then. just check your updates
<RAOF> tjaalton: That's nvidia telling you to get a 512Mb card :P
<Wartorn> Just another question.. How come Mithrandir gets 5 times more FPS than me, with Flightgear when we have the same chip? i dont get this..
<tjaalton> RAOF: yeah, it's a measly GF7950
<Wartorn> Ah well, gonna test that xorg.conf thing.. Thanks for all your help so far :)
<mvo> tjaalton, bryce: if there is a good chance that this patch enters -intel I'm happy to work on it again and resolve the outstanding issue (but only if the chances are good that we actually include it)
<tjaalton> mvo: I'm in favour of it, since it's from upstream anyway?
<tjaalton> bryce is asleep atm
<tjaalton> but I'll test it first to see if there are any issues
<mvo> tjaalton: not really from upstream, but upstream seems to be in favor of it (but I haven't checked the latest messages on the xorg list about it)
<mvo> tjaalton: thanks :)
<tjaalton> mvo: is there an upstream bug report about it?
<Wartorn> Thanks, the line to xorg.conf fixed the compiz issues. Though not the lousy fps in flightgear.
<mvo> tjaalton: http://thread.gmane.org/gmane.comp.freedesktop.xorg/26334 <- that is the discussion about it, looks like it got commited to git already
<tjaalton> mvo: yep, nice
<Mez> does anyone have an AMD64 build machine that I can use ?
<Mez> (I need to test some builds on amd64, but dont have access to one currently(
<tjaalton> Mez: PPA?
<Mez> tjaalton, I need to build against debian too :(
<Wartorn> tjaalton: Just a question, if i install the hardware overlay patch, could this increase my opengl performance? like games wise, not just video?
<tjaalton> Wartorn: nope
<tseliot> Wartorn: have you tried putting this option in the Section "Device" of your xorg.conf?
<tseliot> Option "AccelMethod" "XAA"
<Wartorn> No, i have not
<Wartorn> i will try :)
<tseliot> Wartorn: try it and restart the Xserver
<Wartorn> allright, be right back
<Wartorn> sadly, no improvement on the FPS in flightgear whatsoever :(
<Wartorn> Seems to use XAA for acceleration though, according to the logs
<Mithrandir> tjaalton: http://pastebin.com/f3da10a8a
<Mithrandir> tjaalton: that's my xorg.conf
<Wartorn> I dont get it, same chipset as me, but better fps..
<tjaalton> Mithrandir: looks clean enough, and since you mentioned the glitches you are not running with greedy migration :)
<tjaalton> hmm, not much I can do about the intel breakage before bryce gets back, since the new patch touches another part of the source than the previous one
<Wartorn> Oh, is AHCI preffered to be on or off in the BIOS, when running ubuntu btw?
<Wartorn> cant seem to find any hard info on the topic
<infinity> Wartorn: AHCI, as in your SATA controller?
<infinity> Wartorn: That's somewhat useful to have enabled.
<Wartorn> Yeah, SATA controller. Okay, thanks :)
<Wartorn> I just know that XP SP1 wont install with it on, gotta have SP2. Just wondered about the ubuntu support for it
<infinity> Wartorn: The AHCI drivers are "cleaner" than the mess of chipset-specific drivers and, in my experience, tend to do the right thing more often.
<Wartorn> Okay, thanks alot for the info.
<tjaalton> mvo: video is better with that patch, but still not that good
<tjaalton> mvo: fullscreen is usable also without it, but when you get something else on the screen (like when changing volume) it slows down
<mvo> tjaalton: thanks for giving it a go! does it matter if you have exa or xaa for the tests? i.e. is one of them faster or is it all the same?
<ogra_cmpc> mvo, asac, http://people.ubuntu.com/~ogra/classmate/images/8.04/
<ogra_cmpc> i'd appreciate some install testing (takes about 30min (with only 5 needing your attention))
<mvo> ogra_cmpc: downloading now
<ogra_cmpc> thanks :)
<tjaalton> mvo: totem crashes with XAA
<mvo> tjaalton: with badalloc?
<tjaalton> yep
<mvo> tjaalton: and ""TexturedVideo" is set to "false" in the config?
<mvo> that is strange, my understanding is that it should work :/
<tjaalton> mvo: I grabbed the upstream patch
<mvo> tjaalton: I think the upstream patch provides two Xv ports, but uses the textured one as default
<asac> ogra_cmpc: getting the bits right now
<ogra_cmpc> thanks :)
<Tonio_> carlos: ping ? There is a little problem with kdesudo translations missing in the langpacks....
<carlos> Tonio_: hi
<mvo> ogra_cmpc: if you make suspend to ram work, I will love the cmpc much more ...
<carlos> Tonio_: which distro series?
<Tonio_> carlos: it's been in main for 8 month now, and also the pot file is correctly exported to rosetta
<carlos> Tonio_: Hardy?
<ogra_cmpc> mvo, just waiting for amitk to blow the horn
<tjaalton> mvo: ok I'll try the original version next
<Tonio_> carlos: both gutsy and hardy.... no issue for gutsy, but it would be nice having it in hardy
<Tonio_> carlos: yes
<ogra_cmpc> mvo, at least the daily builds seem to work fine now so changes will be there the next day
<Tonio_> carlos: afaics, the pot file is already mostly translated in rosetta btw
<Tonio_> carlos: but no kdesudo.mo available in any package
<pitti> StevenK, Hobbsee: for bug 192507, do you generally consider "Monday" as start of the week? the current en_AU locale uses Sunday
<ubotwo> Launchpad bug 192507 in langpack-locales "en_AU locale: first day of week incorrect" [Undecided,New] https://launchpad.net/bugs/192507
<mvo> ogra_cmpc: nice!
<ogra_cmpc> :D
<infinity> pitti: When I lived in .au, it still seemed to be a Sun->Sat type of place.
<infinity> pitti: I'm not sure if there's a government standard or anything, though.
<Tonio_> carlos: there is probably something going wrong with the rosetta export, but I can't figure out what exactly
<carlos> Tonio_: next language pack should have it, we didn't have it tagged as something to export to the language packs
<carlos> I fixed it for gutsy and Hardy
<Tonio_> carlos: ho that's done manually ? I thought it was automatic for packages in main ?
<abogani> keescook: Hi Kees! I have just cherry-picked fix against Gutsy git repo for bug #162642. After applied this cifs module still works. Do you find it useful?
<abogani> BenC: ^^^
<ubotwo> Launchpad bug 162642 in linux-source-2.6.22 "[CVE-2007-5904] Multiple buffer overflows in CIFS VFS in Linux kernel 2.6.23 and earlier" [High,Triaged] https://launchpad.net/bugs/162642
<Tonio_> carlos: I'll remember this in order to ping you once we add something to the distro by default ;)
<Tonio_> carlos: also are you aware of a bug reguarding to kde menus ?
<carlos> Tonio_: no, we do it once. there are some translations that we don't export in hte language pack, like ubuntu-docs
<Tonio_> carlos: those are only partly translated for 2 weeks
<carlos> Tonio_: well, when something new is added, we set that flag
<carlos> when we approve it the first time
<Tonio_> carlos: okay:)
<carlos> but I guess we did a mistake with kdesudo...
<infinity> pitti: I *do* agree with the wishlist part of the bug, though; first day of the week should be readily configurable.
<pitti> yeah :/
<Tonio_> carlos: not a big deal as long as hardy has it
<infinity> pitti: (I live in a "sunday first" country, but wouldn't mind my calendar showing Monday first, as it makes more "sense" to a mon-fri working man..)
<Tonio_> carlos: so about kde menus ? is that known problem ?
 * ogra_cmpc really wonders how someone can consider the last day of a weekEND as the start ...
<pitti> infinity: "In Australia the majority of the calendars are printed with Monday as the first day of the week"
<ogra_cmpc> crazy non-europeans
<carlos> Tonio_: what's wrong with KDE menus?
<pitti> infinity: hmm, I can just follow what the Australians recommend me
<pitti> infinity: I added that gnome-panel task, anyway
<Tonio_> carlos: translation is broken, only is the menus, the rest of applications are translated
<Tonio_> carlos: I suspect langpacks are not involved, that's probable a code issue
<infinity> pitti: The fact that his only reference is to quote ISO8601 (which is country-agnostic, and all about computer dates) isn't helpful, though.
<carlos> Tonio_: no translations at all in all menu entries?
<Hobbsee> pitti: seems both are valid.  i tend to use sunday as the first day of the week, but a lot use monday, particularly working people
<Tonio_> carlos: 80% is in english, some menus are translated
<Hobbsee> mon-sun is probably the "norm", i suspect
<carlos> Tonio_: yeah, that sounds like a problem with the code that handle menus
<Tonio_> it happened once a few years ago
<carlos> Tonio_: talk with Riddell about it
<Tonio_> yep
<infinity> pitti: Not even sure about the printed calendar statement, TBH.  Could just as easily be that the people he knows buys calendars that start with Monday. :)
<pitti> heh
<infinity> pitti: *shrug*... One man's anecdotal evidence does not a standard make.
<infinity> (And if you change it, someone else will complain, because their calendar changed after being Sun-Sat for the last 3 years that they've been using Ubuntu)
<Hobbsee> mine here is a sun-sat calendar
<pitti> right, I backed it out and set it to wontfix; thanks for your input
<infinity> pitti: My biggest argument would be the inertia one, really.  Having your calendar re-base itself to Monday on upgrade can be jarring, if you've read it the other way for 3 years.
<pitti> right
<Tonio_> carlos: I was talking about bug 196106
<ubotwo> Launchpad bug 196106 in rosetta "context menu entry "Paste File" [and other dialogs] not translated into German (anymore)" [Critical,In progress] https://launchpad.net/bugs/196106
<seb128> pitti: what gnome-panel task?
<infinity> Most numerical standards entirely sidestep the issue by making Sunday be both 0 and 7, so you can be 0-6 or 1-7, mood permitting.  There's no way to visually represent that, though.
<Tonio_> carlos: sorry for the long time to find out the issue
<infinity> So, yeah, having an option would be a Good Thing.
<carlos> Tonio_: that's not related with menus...
<seb128> hey carlos
<carlos> Tonio_: that's only related with plural forms and usually, Dapper
<carlos> seb128: hi
<Tonio_> carlos: afaics, hardy is broken the same way
<seb128> carlos: any news about this list of packages which don't have updated translations you were support to have 10 days ago? ;-)
<Tonio_> carlos: or maybe that's another bug then ?
<seb128> carlos: we really need to fix those now, beta is next week
<carlos> Tonio_: Could you show me an example, because I can tell you for sure is not the same issue
<carlos> ?
<carlos> seb128: I just got back access to the db mirror to prepare such report
<carlos> I lost access to it before I had time to finish the report
<seb128> carlos: ah, you were kicked out?-á¤)
<Tonio_> http://toniox.org/temp/capture85.pnb
<carlos> I will try to give you it today
<seb128> hate hate hate hate hate hate scim
<carlos> seb128: kind off ;-)
<Tonio_> carlos: the menu on top is mostly in english
<seb128> carlos: thanks
<infinity> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/langpack-locales/+bug/192507
<ubotwo> Launchpad bug 192507 in gnome-panel "en_AU locale: first day of week incorrect" [Wishlist,Confirmed]
<carlos> seb128: me too, I just purged all those packages, to prevent that kind of problem
<infinity> seb128: (In response to your question to pitti)
<carlos> seb128: we don't have an easy way to disable it!
<carlos> Tonio_: the bug you pointed to me is not about menus...
<carlos> or I misread it...
<Tonio_> carlos: I'm not sure only the menus are broken in fact :)
<Tonio_> carlos: looks more general issue, but I'll investigate, don't waste your time, Riddell and I are aware of the issue
<carlos> Tonio_: in fact, confirmed, that bug is not about Hardy at all
<Tonio_> carlos: okay
<carlos> Tonio_: that's something we are working on and I'm completely sure it's not possible to happen in Hardy, so if something similar happens, it's a new bug
<carlos> with a different solucion
<carlos> solution
<tjaalton> mvo: still crashes with TexturedVideo false
<Tonio_> hum, I'll invesgate and if I can't find, then I'll report it
<seb128> infinity, pitti: I'm closing the panel task there
<carlos> seb128: sudo dpkg --purge scim scim-bridge-agent scim-bridge-client-gtk scim-gtk2-immodule scim-modules-socket scim-modules-table scim-tables-additional libscim8c2a
<carlos> seb128: ;-)
<carlos> seb128: that will lock your desktop, though, so do it when you are going to reboot
<seb128> carlos: yeah, I'll do something like that I think
<Riddell> xhaker: about?
<seb128> infinity, pitti: we already have bugs on the topic, I'm just too lazy to look for the exact numbers
<infinity> seb128: As long as you know it's already filed (and say so when you close it). ;)
<infinity> seb128: I might avoid using the word "lazy" in your closing comment, though.
<seb128> infinity: I used "there is already other gnome-panel bugs about similar issue, closing this one"
<tjaalton> mvo: but with EXA it works, and it's a lot faster, since it's not trying any translucent effects on top of the video (that's what textured video is for right?)
<infinity> seb128: Yeah, I read it. :)
<Riddell> xhaker: question on bug     - Remove hotplug references - Remove bashism in debian/rules to rename udev files. - Install libmtp7.rules
<Riddell> hmm
<Riddell> xhaker: question on bug 199504
<ubotwo> Launchpad bug 199504 in libmtp "Please sync libmtp_0.2.6-1 from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/199504
<Riddell> geser: can you attend to bug 199645 ?
<ubotwo> Launchpad bug 199645 in libcompizconfig-backend-kconfig "[Remove] Please remove libcompizconfig-backend-kconfig from hardy" [Undecided,Incomplete] https://launchpad.net/bugs/199645
<mvo> ogra_cmpc_: installing is good so far, how detailed do you want the report? tzdata gives me some stange options (like Etc and SystemV)
<Wartorn> Is there any way i can just cat iso > usbstick somehow, and make it bootable? all guides i can find seem to use some bootloader etc, is this really necessary when you have a bootable iso? Thinking about reinstalling ubuntu with the latest alpha image, and not having go buy new cds :P
<ogra> mvo, "it works" is a good enough report for now :)
<Kano> hi, could somebody update this: http://packages.debian.org/sid/ov51x-jpeg-source
<Kano> because hardy's version is too old for kernel 2.6.24
<Kano> and it is not in lum
 * lamont ponders where in the mess of cdbs makefile crap one turns on a debug unstripped build
<mvo> ogra: "it works" (tm)
<ogra> :)
<mvo> ogra: all seems to work well, nice work
<persia> lamont: just set DEB_BUILD_OPTIONS=nostrip, and it does it automagically
<mvo> ogra: the firefox welcome page is still 7.10
<mvo> ogra: and acpi has no rate information
<ogra> mvo, yeah, thats edubuntu artworks fault
<ogra> you mean no battery info ?
<mvo> ogra: at least no charge info
<ogra> hmm, k
<ogra> i'll check that
<ogra> it has here on one machine at least
<mvo> ogra: and no discharge info too it seems
<ogra> weird
<ogra> is the battery module loaded ?
<asac> ogra: oh .. i completely forgot about the  install :)
<asac> apparently it just finished
<asac> lets see
<asac> ogra: firefox startup time was about 10s. not that bad
<asac> ogra: do we still need to do something about the tabs?
<ogra> no, apparently not
<asac> ogra: charge level is properly displayed (while charging)
<ogra> i can at least work with three of them at the same time without probs
<asac> three tabs?
<ogra> even the details ?
<ogra> yeah, three tabs :)
<ogra> at least if you dont run any other big app
<asac> present rate is unknown
<asac> but that is expected while charing it guess
<ogra> right
<asac> let me unplug
<ogra> apparently it needs some time to measure first
<ogra> mvo said he has the rate now
<asac> hmm ... still unknown while discharging
<asac> lets wait a bit
<ogra> yeah
<asac> ogra: screen was not dimmed when unplugging. is that wanted?
<jordi> pitti: hey
<ogra> thats not the -12 kernel yet anyway, i'll see what tonights image gives me with that
<ogra> the classmate-tools arent in yet either (screen switcher etc)
<jordi> pitti: I'm not entirely sure why hardy didn't get alsa-lib 1.0.16, but I just uploaded -2 which fixes a regression that was hitting many people
<ogra> for now hearing that it works on the other machines makes me happy already, the installer was my main issue :)
<asac> ogra: ok ... makes me happy too then ;)
<ogra> and ff just recently started to behave out of the blue ... inetween tehre was a release that was barely starting :)
<asac> ogra: you have any special firefox settings?
<ogra> but suddenly you can even use it without disabling the caches
<ogra> not anymore
<asac> cool
<ogra> it seemed to work fine in the current image
<ogra> if it regresses i can still drop cache settings
<asac> feels pretty responsive imo
<ogra> yeah
<asac> congrats ;)
<ogra> thanks :) not only my work (i dont maintain the browser ;) )
<asac> ogra: in system you have "about ubuntu" + "about edubuntu" ... is that expected?
<ogra> yes
<asac> k
<ogra> that they both have the same icon is a bug though, but we carry that since more than one release and its a very intrusive change
<asac> cool. hardy on classmate. now even me feels better ;)
<ogra> heh
<asac> ogra: define very intrusive?
<asac> does suspend work?
<ogra> well, the about ubuntu thing is hardcoded ... ther would be needed some automation
<mvo> ogra: its gone again (the rate) after a reboot
<ogra> not yet
<asac> ok ... just becaues i get that option in the power-manager applet
<ogra> tonights image wil have te capability (needs linux -12)
<mvo> ogra: battery is loaded and I waited ~5min and it didn't come back
<asac> ogra: present rate still unknown here
<ogra> "didnt come back" ?
<asac> and remaining capacity is only 2880 ... that sounds too low?
<asac> hmm. apparently not. design is 4000
<mvo> ogra: I had remaining capacity information before reboot, then I rebooteted and now its gone and is not available anymore
<ogra> you mean the icon ?
<ogra> or the info on te icon
 * ogra finishes a fresh install on the spare cmpc ... lets see
<mvo> ogra: sorry, the info
<ogra> ah, hmm
<mvo> ogra: both with the icon and when I run the plain "acpi" command
<ogra> sounds like a kernel issue
<ogra> lets wait for -12
<Tonio_> carlos: concerning the "kde menus", it looks like the strings are in kdelibs.pot on rosetta anymore
<ogra> hmm, "Computer is running on battery ... Laptop battery 4 hours and 45 minutes remaining (63%)" ...
<ogra> mvo, thats what my tooltip says
<Tonio_> carlos: the file is patched during the build process, and I'd like to know if the pot is imported before or after the patching
<Tonio_> carlos: what to grep in the build log for the launchpad import ?
<carlos> Tonio_: we get it after the patch is done
<ogra> "discharge time is currently unknown" below that though
<carlos> Tonio_: unless there is a bug, of course
<Tonio_> carlos: that's what I'm trying to find out
<carlos> Tonio_: I'm not an ubuntu developer. so you need Riddell or any other developer to give you that information
<Tonio_> carlos do you have access to the source pot file on rosetta ?
<Tonio_> carlos I'd like to compare kdelibs.pot content on gutsy and hardy in the source possibly, not the generated ones from launchpad
<Riddell> its a buildd question
<carlos> Tonio_: no, those files are not stored once we import them
<Riddell> pitti: do you know when .pot files get extracted from builds into launchpad?
<Tonio_> carlos: okay
<pitti> Riddell: extraction happens at the time dpkg-deb runs
<cjwatson> pitti: bug 200831 has a crash report attached in an unusual way. Is it possible for the retracer to operate on it anyway?
<ubotwo> Launchpad bug 200831 in man-db "man-db exits return code 139 and seg faults" [Undecided,New] https://launchpad.net/bugs/200831
<pitti> Riddell: the tarball with .pot and .po is then added to the .changes and uploaded together with the debs, then fed to LP translations
<Tonio_> carlos: what I can see : the strings causing problems are now commented in the downloaded pot
<Tonio_> carlos: Riddell told me that means they are not in the last pot imported
<carlos> that's right
<Tonio_> carlos: okay so here is the problem
<Tonio_> pitti: dpkg-deb ? okay looking
<pitti> cjwatson: not ATM unfortunately, that's bug 173591
<ubotwo> Launchpad bug 173591 in apport "tool for fixing a LP bug with a .crash attachment" [Medium,Triaged] https://launchpad.net/bugs/173591
<cjwatson> pitti: can I do it by hand?
<asac> cjwatson: i tend to ask the reporter to submit a new bug by double clicking on it. maybe you can do that by yourself
<pitti> cjwatson: it can be downloaded and fed to apport-retrace, yes
<ogra> asac, btw fo all the ram testing we did i recently discovered htop ... its the awesome if you need to watch resouces
<Riddell> Tonio_: "Publishing chroot-autobuild/build/buildd/kdelibs_3.5.9-0ubuntu2_i386_translations.tar.gz for rosetta" I guess
<Riddell> that happens after the msgmerge
<pitti> cjwatson: you need to do that in the appropriate release (or chroot), add the ddeb apt sources, and then do something like apport-retrace -s -u foo.crash (see manpage)
<pitti> Tonio_: that's the latest possible time to strip the binaries
<pitti> Tonio_: so it usually picks up all the generated .pot files
<Tonio_> pitti: okay
<mvo> ogra: htop looks quite nice
<pitti> cjwatson: ah, it doesn't even have package info, etc., so you need to use -R
<Tonio_> Riddell: afaics, the msgcat is performed after kdelibs4-doc package is beeing built, but way before the other packages
<ogra> yeah
<Tonio_> Riddell: what I don't understand is why patching the pot file that late ?
<Tonio_> Riddell: is there a reason not patching it at the very begining of the build, like makebuilddir or something ?
<ogra> and it gives you intresting accumulated ram info :) it helped me a lot with the classmate ... the current default desktop needs lss tan 100M to run :)
<Riddell> Tonio_: kdelibs.pot doesn't exist then
<ogra> (vs around 180M for teh normal ubuntu)
<Tonio_> Riddell: hum, true :)
<Tonio_> Riddell: okay I'll build locally and see if the file is beeing patched....
<cjwatson> pitti: can I do that in the retracer chroot on ronne?
<Tonio_> Riddell:
<Tonio_> 	msgcat kde.pot po/kdelibs.pot > kdelibs.pot-merged
<Tonio_> 	mv kdelibs.pot-merged po/kdelibs.pot
<cjwatson> ISTR managing that before
<Tonio_> isn't that just an overriding question thing ?
<pitti> yes, should be possible
<cjwatson> ~pitti/bin/retracer-login-i386 seems to DTRT
<pitti> cjwatson: haven't used that for a while, but it should still work, yes
<Riddell> Tonio_: a what?
<pitti> cjwatson: I just fixed the chroots this morning, so they should be  current and working
<Tonio_> overwritting question problem
<cjwatson> pitti: ~pitti/bin/retracer-login-amd64 breaks
<Riddell> Tonio_: I don't understand
<cjwatson> -su: /home/pitti/apport-retracer-amd64/environ: No such file or directory
<cjwatson> -su: apport-chroot: command not found
<pitti> cjwatson: right, wrong path; let me fix them
<Tonio_> Riddell: bah mv is trying to overwrite the existing file
<Tonio_> Riddell: what will happen by default ? yes or no ? I'm unsure what will happen
<Tonio_> mv -f, I know :) mv only, I'm unsure
<Riddell> Tonio_: it'll overwrite the file
<Tonio_> hum okay
<pitti> cjwatson: fixed
<pitti> cjwatson: you should be able to login, apt-get install wget, fetch the attachment, and call apport-retrace -Ru -s (or -g if you want gdb instead of stacktrace stdout)
<Tonio_> Riddell: debuild -nc started, we will know what happens in an hour (about)
<cjwatson> pitti: 'apport-retrace -Ru -s /tmp/_usr_lib_man-db_mandb.6.crash' fails, and after adding a Package line it fails in an even more obscure way; help?
<pitti> cjwatson: don't change the .crash file; -R should take care of providing the missing packaging info
<pitti> cjwatson: how does it fail?
 * pitti tries the same
<cjwatson>   File "/tmp/tmpoTgkRH/usr/bin/apport-retrace", line 199, in install_missing_packages
<cjwatson>     (pkg, version) = l.split()[:2]
<cjwatson> ValueError: need more than 1 value to unpack
<cjwatson> is the second crash
<cjwatson> first one is: report file does not contain required fields: CoreDump Package ExecutablePath
<pitti> cjwatson: second crash> apparently you introduced an empty line
<cjwatson> blink
<pitti> the first one should actually be taken care of with -R, weird
<cjwatson> I'm sure I didn't, unless the vi in that chroot is very broken
<pitti> cjwatson: ah, reproduced here; hang on
<tseliot> mvo: just FYI I've tried hardy on my laptop with an Intel 945GM and I've noticed that I'm no longer affected by the problem with Compiz (with EXA) and xv. Therefore I don't think the old patch is necessary.
<pitti> cjwatson: aah
<pitti> cjwatson: so, the report did not have Package: field
<pitti> cjwatson: and -R was not able to map /usr/lib/man-db/mandb to a package because dpkg -S doesn't work for it (since man-db is not installed)
<pitti> cjwatson: so, apt-get install man-db (yes, it'll fail to configure), then it at least runs
<pitti> useless stack trace, though :(
<cjwatson> ah. Perhaps a command-line argument to apport-retrace to force the package name without having to do that
<pitti> cjwatson: right
<cjwatson> E: Unable to find a source package for man-db
 * pitti wishes he had more time to hack on apport
<cjwatson> and then a useless stack trace
<\sh> damn...I forgot that ffmpeg is in main...
<pitti> cjwatson: that's just for a source-annotated stack trace; it doesn't affect the symbols in the 'normal' stack trace
<mantiena-baltix> keescook: hi, could we talk about inkscape 0.46 a little bit ?
<cjwatson> ah, perhaps I need to use a gutsy retracer
<pitti> WARNING: /lib/libc-2.6.1.so is needed, but cannot be mapped to a package
<pitti> right, seems to be gutsy
<Gatestone> Where can I find the signing keys for Ubuntu repositories? Does "WARNING: The following packages cannot be authenticated!" mean I don't have a key, or does is mean the packages are not signed?
<pitti> cjwatson: indeed, the bug says so
<pitti> cjwatson: I don't have wrapper scripts for that, I can create some
<cjwatson> doesn't matter, easy to do by hand
<pitti> right, it's just s/hardy.tar.gz/gutsy.tar.gz/
<BenC> cjwatson: cell => powerpc64-smp compat meta packages just uploaded
<pitti> cjwatson: argh, that chroot seems to be a bit broken; let me fix it first
<Gatestone> To answer my question: do "apt-get install debian-archive-keyring" to stop signing WARNINGs about official non-3rd-party packages.
<Tonio_> carlos: last question, should I reupload kdesudo so that launchpad catches the pot ?
<carlos> Tonio_: well, the fact that we were not exporting it doesn't mean it was not exported
<carlos> Tonio_: is there any problem with the one published ?
<cjwatson> pitti: oh, ok, I just purged some stuff first and it left me with something that seems usable
<pitti> cjwatson: right; chroot is updated now
<pitti> with apt-get -f install being happy now
 * pitti sighs at fakechroot bugs
<pitti> one day, one day...
<cjwatson> Gatestone: the message means either that you don't have a key or that the archive is unsigned; it doesn't distinguish
<\sh> I wonder if "adding a new binary which was never build from source" needs a FFe? :)
<jdong> pitti: can you take a peek at bug 193784 for me?
<ubotwo> Launchpad bug 193784 in gutsy-backports "Amarok Size Mismatch (gutsy-backports)" [Undecided,Confirmed] https://launchpad.net/bugs/193784
<\sh> new binary here means "a tool from ffmpeg" ;)
<jdong> \sh: I thought that meant a member of ~motumedia
<jdong> :D
<Tonio_> carlos: nope, the one on launchpad is good, so I'll just wait for the next langpacks then ;)
<carlos> Tonio_: yeah ;-)
<\sh> jdong: lol
<dholbach> http://daniel.holba.ch/really-fix-it - We have 194/1381 already! Keep It Up! :)
<Amaranth> dholbach: how do i clear something off of there? the compiz-fusion-plugins-extra one is not a correct fix
<dholbach> Amaranth: you can remove the 'patch' flag from the attachment
<Amaranth> how?
<dholbach> open the bug
<dholbach> attachments (on the left side)
<dholbach> (edit) link
<Amaranth> ah
<dholbach> it's a bit of a hacky solution, but ... *shrug*
<Amaranth> alright then, next upload of compiz should clear it from the really-fix-it list then :)
<dholbach> PARTY ON
 * dholbach hugs Amaranth
<Amaranth> hehe
<\sh> brb
<pitti> jdong: uh, weird; mvo, any idea bout bug 193784?
<ubotwo> Launchpad bug 193784 in gutsy-backports "Amarok Size Mismatch (gutsy-backports)" [Undecided,Confirmed] https://launchpad.net/bugs/193784
<mantiena-baltix> seb128_: hi, do you have some time to talk about gnome-panel's menu icon bugs ? Or you are not right person to talk about gnome-panel in Ubuntu ?
<mantiena-baltix> Problem is in appearance of gnome-panel menu (Applications, Places, System) and main-menu applets - it seems both applets uses same icon, but main-menu applet can use wide icons, while menu applet can't.
<seb128_> mantiena-baltix: I don't understand the description
<seb128_> what wide icons?
<seb128_> menus use 24x24 icons
<mantiena-baltix> seb128_: wine=not proportional, for example main-menu applet can use 24x48 or 24x60 icons
<seb128_> what is main-menu applet?
<mantiena-baltix> Because of this I wanna to use different icons for these applets, but still didn't found a way how to do this - it seems ubuntu uses same start-here icon for both
<mantiena-baltix> seb128_: Add to Panel->Utilities->Main menu
<seb128_> mantiena-baltix: I've no such item, that's something you installed?
<seb128_> mantiena-baltix: is that gnome-main-menu, the applet used by novel which has preferred applications, etc?
<mantiena-baltix> no, this is not gnome-main-menu applet by novell.
<mantiena-baltix> as default ubuntu doesn't display main menu applet, it must be included into panel manually
<mantiena-baltix> wait a minute, I will put screenshot
<seb128_> you mean the menu with 1 ubuntu logo rather than the labels?
<mantiena-baltix> yes
<seb128_> ok
<seb128_> what about this one?
<seb128_> you want different icons in the applets list?
<seb128_> or you don't want to use an ubuntu icon there?
<mantiena-baltix> seb128_: I wanna to use different icons for main-menu applet and for default ubuntu menu bar (icon is at left to Applications)
<Tonio_> pitti: re ! about the pot file export when there are multiple debs, is the export performed while running the first dpkg-deb ?
<seb128_> mantiena-baltix: why?
<_MMA_> seb128_: Normally the distributor logo is used there. I *think* there's a way to use different images for the applets but I only have a vague memory of how its done.
<seb128_> mantiena-baltix, _MMA_: is the issue the list of what is on screen once added?
<Tonio_> pitti: our fix to kdelibs.pot occurs in the middle of the debhelper process, kdelibs deb is already build, as well as kdelibs-data.... I suspect here is the reason it works randomly
<mantiena-baltix> _MMA_: bug is, that not distributor logo is used, but start-here
<_MMA_> mantiena-baltix: Most of the time one is just symlinked to the other.
<_MMA_> bbl
<mantiena-baltix> _MMA_: I know about these symlinks, but distributor-logo isn't really used even if I remove symlinks and put real svg file instead
<seb128_> mantiena-baltix: that looks like a bug rather than a question
<mantiena-baltix> seb128_: I've found, that file start-here.svg from selected icon theme is used for both icons - main menu and Applications menu bar
<mantiena-baltix> seb128_: yea, this is question about bug ;)
<seb128_> and you would like distributor-logo to be used?
<seb128_> I've no strong opinion either way
<seb128_> but was is wrong with start-here?
<mantiena-baltix> seb128_: according to some gnome bugreports for main menu applet icon, named gnome-main-menu should be used
<mantiena-baltix> currently this is a symlink to start-here
<mantiena-baltix> but gnome-main-menu isn't really used even if I remove symlinks and put real svg file instead :(
<seb128_> there is no gnome-main-menu mention in the source
<seb128_> out of ChangeLog references
<seb128_> so your informations are wrong
<seb128_> the code uses start-here
<seb128_> and it uses it for both applets
<mantiena-baltix> seb128_: my sources are Mark McLoughlin (gnome-panel developer), see latest comment in http://bugzilla.gnome.org/show_bug.cgi?id=103778
<ubotwo> Gnome bug 103778 in general "Theme or make configurable main menu icon" [Normal,Resolved: fixed]
<seb128_> mantiena-baltix: that was 5 years ago
<seb128_> mantiena-baltix: code changed since
<mantiena-baltix> seb128_: so, now there are no way to use different icons for main-menu and menu-bar objects ?
<seb128_> no
<saivann> BenC : ping
<mantiena-baltix> seb128_: thanks for info, it seems I should report an upstream bugreport (I thought, that this is ubuntu problem, because in gnome bugreport found, that gnome-panel should use gnome-main-menu icon, not start-here).
<seb128_> mantiena-baltix: well, that's an upstream bug, 5 years is a lot in open source world and things change
<seb128_> mantiena-baltix: opening a bug on bugzilla is likely the right thing to do
<BenC> saivann: ?
<mantiena-baltix> seb128_: this problem is pretty important in multi-user system, where some users use menu-bar, and others (who wanna to have Windows-like system) - main-menu applet
<seb128_> why?
<seb128_> the ubuntu logo can be used in both cases no?
<cjwatson> (argh; "want to" not "wanna to"; "wanna" is slang for "want to")
<seb128_> the change is likely easy to do though, it's a one line include
<seb128_> we just need an icon to use for the other one
<mantiena-baltix> seb128_: because Ubuntu logo doesn't have label "Start" or "Launch", like in Windows ;)
<seb128_> you want to add the label to the icon?
<seb128_> that's so the wrong thing to do there
<saivann> BenC : Hi, I wanted to abuse of your knowledge about bug 129910 and find a solution because this bug was marked as invalid even if it can be reproduced by many people, maybe we can discuss of this in #ubuntu-bugs if your prefer
<seb128_> it'll not scale correctly, not be translatable
<ubotwo> Launchpad bug 129910 in linux "Blank ttys when using vesafb (vga=xxx)" [Medium,Confirmed] https://launchpad.net/bugs/129910
<saivann> BenC : If you have time for it of course
<cjwatson> saivann: that bug is Confirmed in linux, as ubotwo indicates
<cjwatson> saivann: some of the individual tasks are marked Invalid, but the bug as a whole is still open
<saivann> cjwatson : I just did it, but I want to confirm that it should be confirmed in linux, and I want to ask if I can do something to help with that bug since it's really polluted ( like opening a brand new bug and marking all these as duplicates )
<cjwatson> saivann: ... oh, sorry, you did that; never mind me ...
<mantiena-baltix> seb128_: It's not so important if there will be a label "Start" or simply big and easy to notice Icon, simmilar to Windows "Start" button - as I told you before, main-menu applet can use non-proprotional icons, for example 24x60 !
<saivann> cjwatson : :) np
<seb128_> mantiena-baltix: you should have a look to gnome-main-menu maybe if you want to imitate windows
<mantiena-baltix> seb128_: it's pretty hard to point with the mouse on small, 24x24 icon, like start-here is now
<ion_> Itâs pretty easy to hit a corner of the screen.
<seb128_> mantiena-baltix: usually this icon is in the corner so it's easy to point, just go all the way there
<mantiena-baltix> seb128_: thanks for info, I know gnome-main-menu applet
<seb128_> mantiena-baltix: anyway having different icons is likely no problem, as said it's a one line change
<seb128_> mantiena-baltix: the issue is that we need to update all the icon theme to have the new icon if we do that
<seb128_> or to add some sort of fallback in the code in case it's not available
<mantiena-baltix> ion_, seb128_: it's easy to point to the corner for people like us, but for computer-newbies it's not easy ;)
<seb128_> mantiena-baltix: it's easy because the corner stops you, you just have to move a lot in the corner direction, hard to miss
<Amaranth> mantiena-baltix: the corner should be easier for them because they don't have to be precise with the mouse
<mantiena-baltix> AFAIK gnome-main-menu icon is in all gnome themes (in most themes this is a symlink to start-here), so, this shouldn't couse any problems
<seb128_> mantiena-baltix: just give a good kick in the mouse it'll go in the corner and stop there
<mantiena-baltix> seb128_: hehe, you shouldn't me to teach how to work with mouse, I know ;)
<pitti> seb128_: http://people.ubuntu.com/~pitti/tmp/hardy-20080311-1.png
<seb128_> mantiena-baltix: most of theme installed on my desktop don't have this icon apparently
<mantiena-baltix> but I meet lots of people, which I should tell the same words about corners, like you told me :)
<seb128_> pitti: interesting
<seb128_> pitti: wpa_suppliant starts a  job using perl which does 35 seconds of IO hammering
<sudobash> why perl use c++
<mantiena-baltix> seb128_: strange, look here: http://packages.ubuntu.com/search?searchon=contents&keywords=gnome-main-menu&mode=filename&suite=hardy&arch=any
<sudobash> perl and python are good but there is nothing like the power of c++
<pitti> seb128_: eww; network-manager?
<pitti> seb128_: I still have the 0.7 packages from asac
<sudobash> ifconfig all theway
<seb128_> pitti: yeah
<asac> seb128_: perl?
<asac> strange
<seb128_> apt-check hammers your disk for 45 seconds too
<cjwatson> sudobash: these comments are not helpful here
<seb128_> mvo: update-notifier is nasty
<seb128_> mvo: we should delay it a few minutes to not impact on login speed
<seb128_> asac: look at http://people.ubuntu.com/~pitti/tmp/hardy-20080311-1.png
<ion_> sudobash: C++ would be nice if it were object-oriented. ;-)
<seb128_> mantiena-baltix: very few themes listed there
<BenC> saivann: so the bug is still valid against latest hardy? Because I'm sure it was fixed
<cody-somerville> ion_, C++ is.
<saivann> BenC : Last comments says that it's still valid with latest Hardy, yes
<pitti> seb128_: I haven't even found wpasupplicant on the list yet
<BenC> saivann: cjwatson's last few comments seem to answer the issue
<cjwatson> they don't
<cjwatson> I was just answering Loye, not the bug as a whole
<seb128_> pitti: the graph you mean?
<pitti> seb128_: yes
<ogra_cmpc> seb128_, wow, what kind of jpg is that ? my classmate runs out of ram if i open it
<cjwatson> if people are getting blank screens, that's still a bug somewhere
<ogra_cmpc> err png
<mantiena-baltix> seb128_: few ?  tango-icon-theme, human-icon-theme, tangerine-icon-theme, gnome-accessibility-themes, ubuntustudio-icon-theme, gnome-themes-extras, gnome-icon-theme-nuovo, gnome-icon-theme-dlg-neu, gnome-icon-theme-gartoon, gnome-icon-theme-gperfection2 :)
<ion_> cody-somerville: âActually I made up the term âobject-orientedâ, and I can tell you I did not have C++ in mind.â â Alan Kay
<seb128_> pitti: the first colored long bar you get after login on top if the perl io thing
 * mantiena-baltix is going to report a bug
<BenC> cjwatson: ah, ok
<seb128_> pitti: go to the bar before it, it's wpa_supplicant
<seb128_> mantiena-baltix: do you know how many icons theme there is around? ;-)
<saivann> BenC : Yes, that's why I want to clarify this because this bug is somewhat huge
<seb128_> mantiena-baltix: well, not really constructive discussion now, we should make sure all the icons themes in ubuntu have this icon before changing
<mantiena-baltix> seb128_: ;) should I report also to launchpad, or ubuntu developers will not care about this bug and I need to report only into gnome bugzilla ?
<BenC> saivann: I have ignored this bug mostly because extracting anything useful out of it is difficult at best
<pitti> seb128_: right, see it; but I don't see it having much IO?
<seb128_> mantiena-baltix: I would tend to not care since it's not a priority and nobody else really asked for it
<BenC> well over 300 comments
<seb128_> pitti: all the pink color is IO on the perl bar no?
<saivann> BenC : I agree, would that be a solution if I open a clean new bug that refers to this bug in the description and if I set all these bugs as duplicate of the new clean bug?
<pitti> seb128_: ah, right; you mean wpasupplicant starts that process?
<pitti> seb128_: sorry, that's more or less the first time I look at such a thing
<seb128_> pitti: yes
<mantiena-baltix> keescook: hi, are you online ?
<seb128_> pitti: me too, might be looking wrong, Keybuk knows better ;-)
<seb128_> mantiena-baltix: if that's something you need for baltix we can look at doing the change, open a bug upstream and one on launchpad and add the task
<BenC> saivann: not really...what would be nice is a good summary of the problem...as far as I can tell, the basic idea is that we disable automatic framebuffer loading, but manually loading them is fine (e.g. if you put it in /etc/modules)
<pitti> seb128_: installing hardy's nm/wpasupplicant now
<pitti> better for dogfooding anyway
<seb128_> pitti: my understanding is that what costs on loging is IOs, which are pink bars there
<seb128_> pitti: there is no surprise that gnome-panel, nautilus, deskbar cost there
<Keybuk> seb128_, pitti: hello ?
<seb128_> pitti: but there is also this perl one on your chart and apt-check which seems to do a lot there
<seb128_> Keybuk: http://people.ubuntu.com/~pitti/tmp/hardy-20080311-1.png
<BenC> saivann: I believe this is the bug right here: scripts/init-top/framebuffer:modprobe -Qb ${FB} ${OPTS}
<pitti> erk, it seems utterly hard to roll back NetworkManager to hardy
<saivann> BenC : As far as I know, people remove vesafb from the blacklisted modules to gain access to VGA= modes, bug since Gutsy, nothing is shown in any ttys when using VGA=
<seb128_> Keybuk: my understanding is that pink bars are what we should try to reduce there?
<BenC> saivann: basically the initramfs scripts doesn't ignore blacklists, but in this case, I think it should
<seb128_> Keybuk: is that correct?
<ogra_cmpc_> asac, thats pretty weird, opening the bootchart image from above in ff makes it demand over 120M ... the png is only 500something K big
<seb128_> Keybuk: like the perl pink bar, it's started by wpa_supplicant and costs a lot of IOs, is that correct reading of the graph?
<Keybuk> pink is I/O
<asac> hmm
<ogra_cmpc_> try it on the classmate, it runs out of ram
<asac> ogra_cmpc_: why would i want to try it then :)
<ogra_cmpc_> if i hand ff the url on commandline it refuses to start
<asac> i don't want to trash my primary work environment (cough)
<Keybuk> seb128_: possibly run by wpa_supplicant
<Keybuk> the sort is just pid order
<seb128_> ah
<seb128_> I though the dot line between those was what run what
<Keybuk> he has a desktop running at that point
<mjg59> BenC: There's nothing in initramfs-tools to copy the vesafb module into the initramfs
<Keybuk> seb128_: I can't think of anything perlish that wpa_supplicant runs
<BenC> mjg59: Sure there is...it copies /lib/modules/`uname -r`/initrd
<saivann> BenC : hmm, but this bug can't be reproduced without removing vesafb from the blacklisted modules, so apparently that the initramfs does not load anything from vesafb by default
<BenC> mjg59: and the kernel build puts vesafb in there
<BenC> saivann: it doesn't but it uses -Qb, which means it honors the blacklist, when it shouldn't
<cjwatson> BenC: vesafb isn't there on my system ...
<mjg59> BenC: Not here
<saivann> BenC : Oh
<seb128_> Keybuk: hum, k, any easy way to know the exact command rather just having "perl" written there?
<BenC> cjwatson, mjg59: Hmm, ok, then it should be :)
<BenC> I'll get that fixed as well
<saivann> BenC : Great, thanks for finding this out. Do you think that it might be the cause of this issue?
<mjg59> Nothing will load vesafb unless it's in the initramfs
<mjg59> Which would then lead to black vts
<saivann> I'm very glad to ear that we're finding a solution
<seb128_> pitti: I'm also wondering why does gnome-terminal grins on IOS for a while
<Keybuk> pitti: edit stop-bootchart and add -n to the java call, then regenerate that chart ?
<Keybuk> also comment out the line that removes the TARBALL
<seb128_> it's takes 35 seconds to gnome-terminal to start mutt there, wtf?
<BenC> mjg59: vesafb being in initramfs would lead to black vt's?
<pitti> seb128_: ugh, 35 seconds? my maildirs are quite small
<seb128_> pitti: no, that's 35 seconds before starting bash and other things
<seb128_> pitti: look at the g-t bar
<mjg59> BenC: No. It not being in initramfs would lead to black screens
<seb128_> and most of those are pinked, which means it's really busy
<seb128_> I'm wondering what it's doing
<pitti> asac: I just downgraded nm from 0.7 (your ppa) to 0.6 (hardy); nm-applet fails now with "nma_dbus_init(): could not acquire its service, blabla, org.freedesktop.NetworkManagerInfo security policy bla"
<ForgeAus> wouldn't an updated icbs be useful?
<seb128_> pitti: did you downgrade libnm* and the applet too?
<BenC> mjg59: ok, then I just need to find out why the logic in the kernel build isn't hard linking vesafb.ko to initrd/ subdir
<pitti> seb128_: yes, I purged everything, then reinstalled
<BenC> uploaded a fixed initramfs-tools
<mjg59> BenC: In fact, I don't hae anything in my 2.6.24 initrd directories
<dholbach> jdong: do you plan to roll a new transmission release? we have 6 bugs fixed upstream on http://daniel.holba.ch/really-fix-it
<asac> pitti: did you downgrade nma as well?
<mjg59> In the 2.6.22 ones, I get capability.ko
<pitti> asac: nma?
<asac> nm-applet :)
<pitti> asac: netwokr-manager-gnome? yes, of course
<asac> pitti: you need to restart dbus i guess
<BenC> mjg59: yeah, the dir gets created unconditionally, and there's a "if [ -f ..." after it for vesafb.ko, but it doesn't seem to eval to true
<pitti> asac: ah, that's it; /etc/init.d/dbus reload did it
<asac> cool
<pitti> asac: thanks
<asac> pitti: in fact i wasted 3 hours or so because of that at some point :)
<asac> when i did the 0.6.6 package ;)
<asac> but for me reload didn't help
<asac> i needed a full dbus restart
<pitti> Keybuk: /usr/bin/java -n -jar, or ... bootchart.jar -n?
<Keybuk> bootchart.jar -n
<pitti> ok, done; rebooting
<pitti> Keybuk: what does that do, out of interest?
<Keybuk> stops it pruning the output chart
<Keybuk> leaves everything in it
<saivann> BenC : Thanks for your work on this. I will stay on this bug report to see the comments about your latest upload. I set back the status in linux to invalid
<geser> Riddell, slangasek: re bug #199645: according to p.u.c compiz-kde depends on compizconfig-backend-kconfig (note the missing lib)
<ubotwo> Launchpad bug 199645 in libcompizconfig-backend-kconfig "[Remove] Please remove libcompizconfig-backend-kconfig from hardy" [Undecided,Incomplete] https://launchpad.net/bugs/199645
<pitti> Keybuk: erk, that just produces a completely empty/transparent giant pic
<pitti> anyway, gotta run, cu later
<Keybuk> OOM?
<mvo> seb128_: I can delay the apt-check stuff
<seb128_> mvo: would be nice ;-)
<Keybuk> seb128_: I have the PERL OF DOOM too
<Keybuk> and I'm not runninh WPA
<seb128_> ok
<seb128_> Keybuk: can you get a bootchart with -n? ;-)
<Keybuk> there's actually two perl processes
<Keybuk> 9957 dbus-daemon
<Keybuk> 9958  `- perl
<Keybuk> 9959      `- dbus-daemon
<Keybuk> 9960          `- perl
<Keybuk> err
<Keybuk> sorry
<Keybuk> 9957 dbus-daemon
<Keybuk> 9958  `- perl
<Keybuk> 9959 dbus-daemon
<Keybuk> 9960  `- perl
<Keybuk> (second dbus daemon isn't a child of the perl)
<seb128_> hum
<seb128_> is that system-tools-backends?
<Keybuk> both dbus-daemon processes are children of another dbus-daemon
<Keybuk> could well be
<seb128_> likely something to investigate there
<seb128_> Keybuk: btw could we do desktop readahead easily?
<seb128_> Keybuk: there is a forum post about that and some users tried and comment on the "gutsy login is too slow" bug saying they win a lot using it
<wasabi> trying to track down what is loading kvm and kvm-intel at boot. Is it udev doing it? I have them both in the standard blacklist and they're still being loaded.
<Keybuk> seb128_: sure, but it's pretty subjective
<Keybuk> and once you start adding/removing applets, it can be a net lose
<Keybuk> since we'd be readaheading things they don't use
<wasabi> I did a simple script to do desktop reload. It ruined performance in my experiment.
<seb128_> hum, right
<wasabi> The kernel just can't prioritize IO right.
<seb128_> Keybuk: we could readahead standard things everybody use though
<Keybuk> seb128_: maybe
<seb128_> wasabi: what ruined performance?
<Keybuk> I think prefetch-type things are a better win long-term
<seb128_> right
<wasabi> My script submitted many IO requests for all the files I was about to use. But the kernel decided on average to work on them out of order.
<wasabi> So instead of, for instance, the panel being loaded first, it spent time loading nautilus before loading the panel. So it all LOOKED slower.
<seb128_> I'm looking on easy things we could try doing for hardy now though, since login speed is a frequent user complain
<cody-somerville> Is gnomescan included in the gnome FF exception?
<Keybuk> wasabi: did you submit IO requests or readahead ioctl()s ?
<seb128_> and the graphs made by kagoo shows ubuntu is quite bad there
<seb128_> cody-somerville: no
<wasabi> Keybuk: What's the difference?
<Keybuk> wasabi: the ioctl is "just do it"
<seb128_> cody-somerville: updating it could be a good idea though
<wasabi> They were all async. Which I accomplished using a very very very crappy technique in bash, with ionice set to niceest.
<cody-somerville> seb128_, It depends on a package not currently in the archive
<Keybuk> seb128_: last time I experimented, our login speed problems were largely due to our default desktop
<wasabi> So instead of waiting for one before submitting the other, it effectively submitted many.
<seb128_> Keybuk: well, I found interesting things
<seb128_> Keybuk: jockey-gtk --check was taking 11 seconds on my new laptop for example
<Keybuk> yeah, that one takes a while
<seb128_> Keybuk: apt-check is taking 7 seconds, on pitti graphs it's over 35 seconds
<Keybuk> deskbar-applet usually does too
<Keybuk> tracker *kills* you
<cody-somerville> Detecting hardware eats up like 15 seconds on my boot (where it didn't in Gutsy)
<Keybuk> cody-somerville: we don't detect hardware on boot?
<Keybuk> do you mean loading drivers?
<cody-somerville> Keybuk, Yea, sorry.
<cody-somerville> Let me reboot and make sure what it is saying
<seb128_> Keybuk: I've been trying on stock profile so tracker is not an issue
<Keybuk> seb128_: did we disable tracker?
<seb128_> no
<seb128_> but when there is nothing to index it's quiet
<wasabi> stuff like tracker gives me a long term performance hit (significant), but not at boot.
<Keybuk> iiiish
<Keybuk> it'll still walk your home dir
<Keybuk> seb128_: confirmed that it's system-tools-backends
<Keybuk> running with -m SMBConfig and -m NFSConfig
<Keybuk> (respectively)
<wasabi> Anybody aware of any desktop software for smart monitoring? Anything that might raise a notification when a hard drive's smart test begins to pre-fail?
<Amaranth> oh man, tracker walking your home dir on login is so annoying
<Amaranth> it wouldn't have to if we had more inotify watches :)
<wasabi> There's always a hole between the time the system starts and tracker sets up it's inotifies.
<seb128_> Keybuk: what process is that?
<seb128_> Keybuk: another reason to drop shares-admin and use nautilus-share
<Amaranth> wasabi: and in that time you're going to change a non-hidden file in $HOME?
<seb128_> I should really write this MIR now
<wasabi> Amaranth: If ~ is sahred between systems, probably.
<wasabi> Amaranth: Hard to say.
<wasabi> Its interesting contrasting this with how ms did it in ntfs. The FS itself maintains a journal that can be read.
<sladen> dholbach: ack.
<wasabi> Why does tracker scanning ~ slow the system down? That's the real question
<Keybuk> seb128_: the two perl scripts
<Keybuk> wasabi: find ~ kills the kernel
<wasabi> It's either because the kernel cannot schedule the IO properly to get out of the way, or the IO leads to a side effect (such as dumping useful loaded pages)
<Keybuk> it's something the kernel or filesystem or whatever is just not able to do
<dholbach> sladen: ROCK
<Keybuk> any tree iteration has the same effect
<dholbach> sladen: there are even more on http://daniel.holba.ch/really-fix-it
<Keybuk> (it's why jockey is slow, for example - it has to walk /lib/modules/$VER)
<wasabi> Keybuk: So teh act of statting cannot have a priority that makes it behave right along side other IO?
<Keybuk> wasabi: stat or readdir, etc.
<seb128_> Keybuk: do you have smb or nfs shares?
<slangasek> geser: ah; for some reason I have an older version of compiz-kde visible in my apt cache, let me try to see what that's all about
<wasabi> Maybe that's the problem to focus on.
<Keybuk> seb128_: nope
<slangasek> geser: grmbl, gutsy-security is what that's all about; ok, I'll nuke the libcompiz-fwibble package
<zdzichuBG> how to kill scim applet?
<\sh> zdzichuBG: sudo im-switch -z all_ALL -c none and relog
<zdzichuBG> thanks. this should be in release notes. It activates all the time while switching "screen" windows
<Wartorn> I was here earlier complaining about the performance of the X3100 intel graphics chip (was getting terribly lousy fps in flightgear for an example). Just an addition to how lousy it is: Even the "helios" screensaver draws at what.. 5 fps. This on a freshly installed hardy
<Wartorn> with all updates installed
<Wartorn> and why does the keyboard language keep changing when i press shift+space? between amharic and norwegian
<Amaranth> because you want to type in amharic
<Wartorn> Uh, no?
<Wartorn> removed the shortcut keys, but that shouldnt be default..
<slangasek> there's supposed to be a fix in the pipe that disables SCIM's interference by default for people with Latin locales, I think
<Wartorn> Okay, great
<Tonio_> carlos: me again, sorry ;) how long should I wait after a package is build for the pot to be extracted and the changes visible in a downloaded pot file on launchpad ?
<Tonio_> carlos: we are trying a fix with Riddell, but robably don't want to wait fo the next langpacks to be sure it worked out :)
<carlos> I cannot give you an exact time, but I would say between 5-7 hours
<carlos> Tonio_: you can follow the process, though
<carlos> Tonio_: https://translations.edge.launchpad.net/ubuntu/hardy/+source/kdelibs/+imports
<carlos> Tonio_: https://translations.launchpad.net/ubuntu/hardy/+source/kdelibs/+imports
<carlos> Tonio_: there you can see the .pot file we got from the build process
<carlos> and when it's already imported
<carlos> it will disappear 3 days after it's imported, though
<cjwatson> Wartorn: it's not supposed to be on by default. What locale are you using, and what does 'update-alternatives --display xinput-all_ALL' say?
<Riddell> carlos, Tonio_: the po/kdelibs.pot file there does have the strings we are missing
<carlos> Riddell: is that a fixed version? or does it mean we have a problem when it's imported?
<Tonio_> Riddell: that's probably not the fixed version, as you probably didn't upload yet ;)
<carlos> Tonio_: it was imported an hour ago
<carlos> so it's quite recent
<Riddell> well, I'm confused then
<Tonio_> carlos yeah, but the fixed one should be imported in a few minutes
<Tonio_> Riddell: did you upload ubuntu3 package ? that's the one with the fix
<Riddell> Tonio_: yes, a few minutes ago
<Tonio_> Riddell: so we have to wait for the next import
<Riddell> Tonio_: it won't be any different if the strings are there already
<Tonio_> Riddell: are the strings in there ?
<carlos> Tonio_: could you confirm whether launchpad has now the strings?
<Tonio_> carlos lemme look
<Riddell> Tonio_: they're in http://launchpadlibrarian.net/12582194/kdelibs.pot (from -0ubuntu2)
<Tonio_> Riddell: as I said, that happened before, it is possible that this is a random result
<Riddell> possible yes
<Riddell> unlikely though, computers aren't usually random
<carlos> Riddell: btw, I wonder why is that it has a header like http://paste.ubuntu.com/5585/
<Tonio_> Riddell: with the fix it shouldn't be random, as we patch the file way before any debhelper tool is started and dpkg-deb used
<carlos> Riddell: are you using msgmerge to produce the template?
<Riddell> carlos: because its a merge of two .pot files
<Riddell> carlos: yes
<carlos> Riddell: you should ignore one of the headers and leave just one
<Tonio_> Riddell: we will pobably hardly understand what is going wrong, but fixing should be possible with ubuntu3
<carlos> Riddell: it only makes sense for translations, because need to be reviewed, for headers... is useless
<Riddell> carlos: we use "msgcat kde.pot po/kdelibs.pot"
<Tonio_> Riddell: one thing is sure, there is a difference between the pot with ubuntu1 & ubuntu2 packages, without any change on our own
<carlos> Riddell: could you change it to be: msgcat po/kdelibs.pot kde.pot --use-first  ?
<Tonio_> Riddell: I had comments on the pot file, you don't :)
<Tonio_> carlos: when can we expect new langpacks released ?
<carlos> no need to reupload everything, but just to be sure that future uploads do it in that way?
<Riddell> carlos: can do
<carlos> Tonio_: we do it twice per week, next one is supposed to happen tonight, so it should be ready tomorrow
<carlos> Riddell: cool, thanks
<Tonio_> carlos: oki I'll check if it gets resolved
<carlos> ok
<Wartorn> cjwatson: it says that status is manual
<Wartorn> locale is norwegian
<alefteris> cjwatson, thanks a lot for fixing the gfxboot-theme-ubuntu bug :) is there any way for me to test it? has the fix made it into an iso daily build?
<ScottK2> slangasek: You're beta approaching mail says, "...uploadswill require approval from the release team..." - I assume you mean Main/Restricted uploads?  Is it safe to assume that people understand this or perhaps does it need to be clarified?
<ogra_cmpc_> hmm, so 2.6.24-12 doesnt boot on the classmate ...
<slangasek> ScottK2: the beta freeze is not a soft freeze, so all archive uploads must be "approved" by someone on the release team
<slangasek> ScottK2: I'll try to be sure to clarify that when announcing the actual freeze
<ogra_cmpc_> BenC, are there any known issues with 2.6.24-12 that it cant find/load the initramfs ?
<BenC> ogra_cmpc_: none that I'm aware of
<ogra_cmpc_> hrm
<ogra_cmpc_> weird
<ogra_cmpc_> it panics here
<BenC> ogra_cmpc_: sounds like a bad initramfs or bootloader issue
<ogra_cmpc_> asking me to append a root= option
<ogra_cmpc_> which if i do that doesnt change anything
<ScottK2> slangasek: OK.  Thanks.  That makes sense.
<cjwatson> alefteris: I haven't checked, but it should be in today's
<cjwatson> Wartorn: ok, 'sudo update-alternatives --auto xinput-all_ALL' should clear it up, though it's interesting that it ended up that way
<slangasek> cjwatson: fwiw, I had the same here
<cjwatson> I put it on tomorrow's platform meeting agenda
<cjwatson> it may be that it's just for people who upgraded through specific versions
<cjwatson> but I'd like to have a plan for confirming that
<Wartorn> i installed hardy with the alpha6 iso, and updated.
 * slangasek nods
<Riddell> seb128: ubuntu-desktop uninstallable due to old gnome-about ?
<seb128> Riddell: what arch?
<Riddell> seb128: amd64
<seb128> rather the other way around
<Riddell> I see it failed to build
<seb128> you need a buildd admin to kick everything which failed to build while libgnome was not installable
<Riddell> seb128: I see lamont just joined :)
<seb128> right, he's a good candidate for buildd kicking ;-)
<emgent> PriceChild, ping
<PriceChild> emgent: pong
<emgent> PriceChild, we solved problem to u-hardened
<emgent> now we use ubotwo :P
<emgent> thanks to LjL
<PriceChild> cool :)
<lamont> Riddell: I've been bouncing around all day
<lamont> Riddell: and I'm not a buildd admin.....
<Riddell> evand: you owned us :) https://lists.ubuntu.com/archives/kubuntu-users/2008-March/026221.html
<Riddell> ScottK2: do you have any contacts with clam upstream to discuss that ^^ ?
<evand> hahahaha
<evand> that made my day
<ScottK2> Looking
<ScottK2> Riddell: I'm not sure from that what the issue is.
<Riddell> ScottK2: clam thinks wubi is adware
<ScottK2> Riddell: So this is a windows user of clam that's the concern?
<Riddell> ScottK2: I think he's on a mac, but yes he's concerned that clam AV has spotted that file as being adware
<ScottK2> I can file a bug with clam.  They tend to look at them seriously.  They're at an RC for a major release right now (yeah for bad timing with our release once again), so I don't know how responsive they'll be right now.
<mjg59> keescook: Ok, I've implemented most of the libdisasm integration. I'll get around to testing it at some point :)
<ScottK2> Riddell: Looking into the clamav.net bug reporting criteria it's not reportable directly to them.  Hans Meyer (who sent the mail above) needs to report it to the source he downloaded clamav from.
<xhaker> Riddell: about bug 199504 : debian has every needed change.
<ubotwo> Launchpad bug 199504 in libmtp "Please sync libmtp_0.2.6-1 from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/199504
<pitti> re
<pitti> Keybuk, seb128: I don't even have tracker running AFAIK
<Keybuk> pitti: +1 for the Tracker Must Die camp?
<pitti> Keybuk: I never ever use it (I know where I put my files), so no need for me to waste resources on it
<Riddell> xhaker: ok, synced
<pitti> Keybuk: anyway, does bootchart -n work for you?
<Keybuk> sometimes
<Keybuk> sometimes not
<pitti> Keybuk: it just gave me a completely transparent png
<Keybuk> that means it core dumped
<pitti> I just got some java GC warnings about allocating big chunks
<Keybuk> OOM usually
<Keybuk> s'ok, we found the culprit
<Keybuk> system-tools-backends for SMBConfig and NMBConfig
<pitti> ah
<pitti> why's that activated at all?
<Keybuk> dunno
<pitti> shouldn't it be dbus activation nowadays?
<Keybuk> it's just one of many things
<Keybuk> they are dbus activated
<Keybuk> something is activating them
<pitti> so something tries to poke it
<Keybuk> the trouble is that it's not any one thing we're running on login
<highvoltage> ooh, did I hear tracker must die? where do I vote!?
<Keybuk> it's the amount of things that we're running on login
<pitti> right
<Keybuk> and especially, the amount of things that are written in Python or Perl
<Keybuk> (or Mono, but people add those)
<zul> slangasek: there seems to be a problem with ucf and the smb.conf file
<nixternal> BenC: Rock on for making my multimedia keys work again with my lappy and the Intel HDA!
<nixternal> superm1: I heard you had something to do with it as well...I guess I could say thank you, just so I don't get a dead fish on my door step :p
<johanbr> "dead fish"? Sounds like the persuasion business in Chicago has gone downhill. :)
<BenC> johanbr: yeah, usually they take you to the fishes, not the other way around
<Wartorn> i have some hardware keys that are not in use on my zepto laptop, any way to make them launch apps? also, my numpad works like holding down the FN key and pressing some of the letters.. this does not work (though other FN functions do), any way to fix?
<slangasek> zul: are you referring to bug #201059?
<ubotwo> Launchpad bug 201059 in samba "conffile prompt on latest upgrade in hardy" [Undecided,Confirmed] https://launchpad.net/bugs/201059
<zul> slangasek: yes
<ogra_cmpc> amitk, doesnt work :(
<slangasek> zul: yeah, not really a problem, it only affects users who are already running a hardy version of the package; am following up
<ogra_cmpc> amitk, i just tested with yeasterdays image and installed -12 on it ... the values in the sysfs seem all to be set to 1 anyway though
<slangasek> zul: there are /other/ problems which I mean to fix, but this isn't one of them :)
<zul> slangasek: heh what do you think about 2.0.28a for beta as well?
<slangasek> zul: probably needs a FFe, I'm probably too close to it to be objective so it should preferably be reviewed by another member of the release team
<zul> slangasek: yeah Im in the middle of seeing what needs to be done first :)
<pitti> seb128: do you see a compelling reason why s-t-b should run at session start?
<pitti> seb128: or is that something we can work on?
<keescook> mjg59: sick and wonderful.  :)  I found a machine with an 8xxx card -- I just need to find some time to reboot it to 64bit and play with it
<tjaalton> keescook, mjg59: ooh you are fixing the nv&64bit problem? there are a ton of dupes about it and possibly ones that haven't been found yet :)
<booxter> hello! is there any ubuntu locales/language selector devs?
<carlos> seb128: hi, I have a present for you ;-)
<keescook> tjaalton: yeah!  I'm not expecting that it will be easy -- we've been working on the infrastructure needed to debug it since the last UDS.  :P
<seb128> carlos: hey ;-)
<carlos> seb128: http://people.ubuntu.com/~carlos/broken-templates.txt
<carlos> it's not a full list
<seb128> pitti: that's clearly a bug, we want to replace shares-admin with nautilus-share though
<seb128> pitti: so it might just go away
<seb128> I need to write the MIR, will do tomorrow
<tjaalton> keescook: I've got a GF8600GT here, but it's 32bit currently
<nixternal> johanbr: when they put a dead fish on your door step, that means they are coming for you to take you to sleep with the fishes :)
<booxter> hello! is there any ubuntu locales/language selector devs?
<tjaalton> keescook: so if you want a confirmation that it works I'll be able to do that
<seb128> carlos: thanks
<asac> anyone has a working or broken iwl3945 + WPA + network-manager 0.6.6 setup :-P?
<asac> stgraber: most likely you do?
<bardyr> mine is close
<stgraber> asac: yep
<asac> does it work?
<stgraber> asac: well, it's wpa2 but shouldn't be that different ... WPA2 works fine and I'm pretty sure I was connected to WPA1 this morning
<asac> strange
<stgraber> yes, the AP I was connected to this morning is WPA-PSK TKIP, so WPA1
<asac> i received some bugs about iwl3945 now being broken :/
<asac> hopefully just noise.
<asac> lets review when they attached the required info
<stgraber> asac: this lappy was running NM 0.7 and then was downgraded
<asac> stgraber: did you downgrade supplicant as well?
<keescook> tjaalton: okay, good to note.  we've still got the find the bug first.  ;)
<stgraber> asac: I think so, 0.6.0+0.5.8-0ubuntu1 is my current version
<keescook> s/the/to/
<asac> hmm ... thats correct
<asac> stgraber: do you get issues if you restart network-manager multiple times ... or using the kill-switch?
<stgraber> asac: I just tried kill-switch and it worked correctly (NM disconnected 5-6 sec after I pushed it, then reconnected after 2-3 sec)
<keescook> doko: can you explain to me the sqlite changes you made to python-launchpad-bugs?  bug 200870 says python-pysqlite2 is in universe, but it's not.  I'm confused.  :)
<ubotwo> Launchpad bug 200870 in python-launchpad-bugs "please remove dependency on python-pysqlite2" [Undecided,New] https://launchpad.net/bugs/200870
<doko> keescook: now it can be demoted =)
<keescook> doko: aaah! okay.  :)
<keescook> doko: btw, please use bzr.  :)  I've commited your .29 changes there now
<doko> keescook: didn't see that I have write permisson ...
<keescook> oh, hm, good point.  join the team!  :)
<bdmurray> heh
<doko> thanks for checking in ...
<keescook> np
<pitti> keescook: shouldn't the team just be ~ubuntu-core-dev, given that they can upload the package anyway?
<pitti> or, at least, put ~ubuntu-core-dev into the team?
<keescook> pitti: that makes sense.  bdmurray can you do that?
<carlos> seb128: http://people.ubuntu.com/~carlos/not-generated-templates.txt and http://people.ubuntu.com/~carlos/not-updated-templates.txt
<carlos> seb128: both files should cover 99% of the broken templates
<seb128> carlos: thanks
<carlos> not-generated-templates are the ones that we don't even have an old version in Launchpad
<carlos> not-updated-templates are the ones we have in Launchpad but that were not updated with latest package built and published
<carlos> seb128: I will try to update it daily
<seb128> jamiemcc_: around?
<carlos> if you need more information, tell me and I will see what could I provide to you. Also, if you detect anything that shouldn't be there, tell me it too so I can improve the queries that produce that information
<seb128> carlos: ok, I'm in a meeting now but I'll look at those tomorrow and let you know
 * seb128 hugs carlos
<carlos> ok
<bdmurray> keescook: I reckon so
<bdmurray> pitti: do you know who would have the ability to approve ubuntu-core-dev membership in the bughelper-dev team?
<ScottK2> bdmurray: How much new mail is this going to get me?
<bdmurray> ScottK2: How should I determine that?
<ScottK2> bdmurray: I don't know exactly, but I guess if bughelper-dev members get mail that would mean all ubuntu-core-dev would get it.
<bdmurray> ScottK2: It looks to me like e-mail goes to the bughelper mailing list so that shouldn't be an issue.
<ScottK2> bdmurray: OK.  Thanks
<mvo> Riddell: apt with the fix is upload and I'm uploading a new update-manager with better kde terminal support now too, it should be pretty good now
<pitti> bdmurray: ugh, yay complicated LP team maintenance
<bdmurray> pitti: ;) I wanted to proactively let someone know
<pitti> bdmurray: I didn't get a mail (as u-c-d member), so I guess only the team owner can?
<bdmurray> pitti: Well, I haven't done it yet.  And yes you are corect only the owner can.
<jamiemcc_> seb128: hi yes
<slangasek> james_w: so am I right on #201059 that this was a feisty install originally?
<james_w> slangasek: yes, you're right. I confirmed in the report.
<slangasek> james_w: ok, thanks
<slangasek> now we just need a magic solution for munging smb.confs created with other versions of samba so that ucf is happy :/
<slangasek> though I'll be honest, I was pleased that we went as long as we did (in Debian or Ubuntu) without someone complaining that the new ucf was broken :)
<mathiaz> slangasek: I have a cyrus-sasl2 merge ready to be uploaded - it's not a new upstream revision. However the new Debian revision added a new binary (saslfinger) beside bug fixes. Should I ask for a FFe ?
<slangasek> mathiaz: how big's the binary?
<soren> Since I apt-get upgraded this morning, I just get a black screen with my mouse pointer on it, when I log into gnome.. Is this known?
<slangasek> (and which package is it added to?)
<mathiaz> slangasek: http://paste.ubuntu-nl.org/59284/
<mdke> Keybuk: right, thanks for the info (shame though!)
<slangasek> mathiaz: FFe granted ;)
<mathiaz> slangasek: Thanks ! - \o/
<seb128> soren: no, not known
<soren> seb128: I just noticed that it seems that gnome-panel got removed.
<seb128> soren: does it happen with an another user? what did you update?
<soren> seb128: ..and is not uninstallable.
<seb128> soren: using !i386?
<soren> ER..
<soren> Is *now* uninstallable.
<soren> Yes, amd64.
<seb128> bad idea
<soren> Hah!
<slangasek> did you click 'yes' to 'partial upgrade'? :)
<seb128> wait until some buildd admin wake up and kick the builds
<soren> apt-get dist-upgrade ftw!
<slangasek> yeah, bad idea :)
<seb128> and read what dist-upgrade asks next time ;-)
<soren> I read whatever I want!
<soren> :)
<soren> *shrug* I like pain.
<pitti> seb128: what shall I kick?
<seb128> pitti: world on amd64
<pitti> seb128.expand('world')
<seb128> let me look through the mails I got
<pitti> source package list, separated with spaces and NO commas preferred :)
<seb128> buildds admin should really have an automatic retry for things which broken due to installability issues
<seb128> pitti: alright ;-)
<pitti> iz sbuild bug
<pitti> (or soyuz)
<pitti> it doesn't properly detect this as a DEPWAIT condition
<slangasek> bryce, tjaalton: is bug #164974 tractable for hardy?
<ubotwo> Launchpad bug 164974 in dell "[Hardy] [XPS M1330] Resume from suspend/hibernate doesn't always work (i965)" [Undecided,Confirmed] https://launchpad.net/bugs/164974
<TheMuso> Could an archive admin please give back mousetweaks? I've no amd64 so I can't confirm whether it will build now, but it failed due to package uninstallability.
<bryce> slangasek: not really; comment #1 from Dell captures the situation for resume issues
<TheMuso> s/archive admin/build admin/
<slangasek> bryce: uh... which one of these comments is from Dell? :)
<bryce> Jose De la Rosa is our dell contact
<slangasek> ok
<seb128> pitti: gnome-desktop nautilus eel2 nautilus-cd-burner tomboy gnome-panel gnome-settings-daemon  gnome-media evince
<pitti> seb128: all done (on all failed arches)
<seb128> pitti: danke
 * seb128 hugs pitti
<pitti> de rien
<TheMuso> pitti: ^^ re mousetweaks if you don't mind please.
<pitti> TheMuso: what about mousetweaks?
<TheMuso> pitti: Could you please give it back? If failed on amd64 due to package installability issues.
<pitti> TheMuso: ah, sure; nudged
<TheMuso> thanks.
<pochu> pitti: and gnome-build gdl eclipse pretty please :)
<pitti> pochu: done
<pitti> good night everyone
<seb128> 'night pitti
<pochu> good night pitti, and thank you
#ubuntu-devel 2008-03-12
<Hobbsee> Fujitsu: hmm, was the hal fixing the dimming brightness for you too for a while?
<Hobbsee> or am i just going mad?
<bryce> is anyone here running Xgl?  If so could you run xvinfo | grep Xgl ?
<jdong>   Adaptor #0: "Xgl Generic Texture Video"
<jdong> bryce: ^^ :)
<jdong> after all these years, fglrx 8.40.4+Xgl is STILL the most stable/smooth setup for my mobility x1400
<jdong> I just gave up on Catalyst 8-3 after a week's time with it
<bryce> jdong whoohoo thanks!
<bryce> jdong: could you also run 'xrandr -v' ?
<jdong> Server reports RandR version 1.2
<bryce> interesting!  thanks
<RAOF> jdong: That's disappointing.  I was hoping that xgl could go away.
<bryce> jdong: fwiw, my bet is that Xgl+fglrx 8.40.4 does not actually do xrandr 1.2, so the xserver is sort of fibbing a little
<jdong> RAOF: tell me about it; I actually shed some tears when catalyst 8-3 failed to deliver
<jdong> bryce: I agree
<RAOF> tjaalton: Do you have any debugging tips you'd like done for bug #194214?  It's annoying, and doesn't seem to be the kernel's fault.
<ubotwo> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [High,Confirmed] https://launchpad.net/bugs/194214
<compbrain> Anyone happen to know if there is a py module kicking around for reading .dsc's?
<james_w> compbrain: python-debian should do it.
<lamont> slangasek: you around?
 * ScottK wonders about python-apt
<james_w> ScottK: python-apt can do it as well probably, but doing it in python-debian is pretty simple.
<compbrain> ScottK: I didn't see anything in python-apt that could do stuff with a non-deb
<emgent> heya fabbione :)
<ScottK2> compbrain: OK.  I guess I won't wonder anymore
<fabbione> hi emgent
<slangasek> lamont: moo
<fabbione> morning guys
 * slangasek waves
<nxvl> how do i write new blueprints?
<nxvl> i don't find the option
<emgent> nxvl, https://blueprints.edge.launchpad.net/specs/+new
<nxvl> emethnx
<nxvl> emgent: thnx
<emgent> np :P
<tjaalton> RAOF: sorry no, it needs to be reported upstream
<tjaalton> RAOF: I've been meaning to do that, but instead selfishly prioritized the bugs that I'm seeing when triaging ;)
<tjaalton> hm, s/when.*//
<RAOF> tjaalton: That's OK.  I was going to try building xserver without the smart scheduling patch, on the basis that it seems to have been added around the time this started and seems vaguely like a candidate.
<RAOF> tjaalton: Following that, I was going to try raw upstream git xserver.
<dholbach> good morning
<pitti> Good morning
<Hobbsee> morning pitti, dholbach
<Fujitsu> Hi Hobbsee, pitti, dholbach.
<tjaalton> RAOF: excellent, thanks
<pitti> doko_: ah, python-xml in component-mismatches \o/ demoted
<pitti> doko_: p-pysqlite2: http://paste.ubuntu.com/5609/
<pitti> lool: ah, elisa finally starts up, thanks!
<pitti> lool: apparently I'm just too dumb to do anything with it :/ the configuration area just has themes, the photo/video thingies don't allow me to set any file path, and the audio file browser does not go above my home dir
<doko> pitti: python-xml: asked ScottK to do the same in universe, and then remove it
<lool> pitti: I think your initial experience with elisa is interesting to note down
<lool> pitti: I'm sure you can easily workaround your issues with the config file(s); but it's interesting to see how it was a pain for you to start with
<pitti> lool: it would be nice if there was 'paths' section in the configuration, where I could point it to the root dirs of my audio/video/photos
<lool> pitti: To some extent, it's meant to be configured once (or using the defaults) on a dedicate box near your TV
<dwa> hello, my x keeps hanging when i use an ftp mount. Is there a known bug about this?
<pitti> lool: how is that done? vi .elisa/config?
<lool> pitti: /usr/share/doc/elisa/FIRST_RUN
<lool> pitti: In .elisa/elisa.conf
<lool> pitti: Also, elisa is supposed to have grown client/server capabilities, a bit like mythtv; I didn't play with it myself, it's new with these uploads, but if you do I'm interested in your experience as well
<lool> pitti: I'm happy to relay your impressions to the elisa folks; I'm sure they would be interested
<pitti> lool: ah, that works now, I added the paths to the config file
<pitti> I find it a bit difficult to steer (pressing Esc always throws me out of the entire program, no obvious method to pause/continue a video, etc.), but it looks nice
 * pitti hugs lool, thanks for your work for fixing it
<lool> pitti: FIRST_RUN covers the important keybindings (enter for play/pause)
<pitti> lool: right, just getting used to it :)
<lool> Keybuk: I think you had issues with elisa as well; it might be a good occasion to give it a try as well
<lool> pitti: Oh reminds me: are you still looking at its main promotion?
<pitti> lool: yes, now that it actually works
<lool> pitti: Also FYI, there's a bugfix release which came out yesterday; it's currently held up by understanding a python-central bug wiht egg-info files and finding a fix or workaround
<lool> But shouldn't change SONAME or anything, just bug fixes AIUI
<ogra_cmpc_> wow
 * ogra_cmpc_ just noticed the vesa driver is as fast as the intel driver on the cmpc .... while eating only half the ram i810 does
<pitti> Riddell: hey
<ogra_cmpc_> lool, you had a consolekit hack for for startx in mobile, right ? how evil is that change ? its really mean to disable all users that use startx from doing administrative desktop tasks imho so if it doesnt rip huge security holes that would probably be a nice addition...
<pitti> Riddell: I'd like to have your opinion about hwdb-client in bug 195519
<pitti> Riddell: i. e. do you rather want to keep hwdb-client-kde, or drop it entirely, given that it is mostly useless?
<ogra_cmpc_> pitti, cr3 had promised me the new gui would be done for hardy (doesnt seem to be the case though :( )
<lool> ogra_cmpc_: We're working on it, but it isn't working for now
<ogra_cmpc_> ah, k, i thought you had it solved already
<lool> ogra_cmpc_: What we managed doing is starting a CK session; there are many ways to do this
<lool> The problem we're facing at the moment is making that session the active one
<pitti> seb128: FYI, I gave-back gnome-games, libgnomeui, eel, and eog for now
<ogra_cmpc_> yeah, i have a similar prob with ltsp logins
<pitti> seb128: sorry if that causes some more FTBFS spam
<lool> It would seem that using a root-only CK call to start the session with the relevant params might help it, but we didn't solve this yet
<seb128> pitti: thanks, don't worry about the mails, I just mark those all read usually
<lool> ogra_cmpc_: Finally, we have a stop gap workaround ATM which is to use a root running daemon to fix the CK session
<cjwatson> lool: I have code that marks the session active by hand, if it would help
<lool> cjwatson: Does it require root?
<ogra_cmpc_> well, in any case it would be nice to have it un the general distro package so we can make use of it everywhere if its not to hackishj
<pitti> seb128: I wait until libgnomeui is built and published, then I'll give back everything else
<lool> cjwatson: Anyway, any contribution at this point is useful
 * lool grabs bug id
<seb128> pitti: alright
<lool> https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/199486
<lool> ogra_cmpc_, cjwatson ^^^
<lool> pitti: You're also welcome to comment
<cjwatson> lool: not certain
<lool> I discussed this with mccann and he told us to use ck-start-session or something, which is only available in newer consolekit
<ogra_cmpc_> is that like the pam thing wrapped ?
<lool> However it's not helping as it's not aware of the DISPLAY at the moment it's launching the session
<lool> ogra_cmpc_: Exactly, so doesn't solve the issue we're having
<ogra_cmpc_> yeah
<lool> I didn't have time to resume discussion
<cjwatson> you probably don't want to use the pam module as such
<ogra_cmpc_> right
<lool> cjwatson: Oh why not?  We planned doing so
<cjwatson> why doesn't xinit have root privileges?
<cjwatson> oh, if you're willing to hack complete PAM support into xinit, sure
<lool> cjwatson: It wasn't enough, but I think it did as well as ck-start-sesison
<cjwatson> I didn't think it started a PAM session at the moment, though
<lool> cjwatson: We're using "su" before starting startx
<cjwatson> starting a PAM session requires root at *some* point
<pitti> lool: if ck-launch-session helps you, we can certainly port it
<lool> pitti: I think not
<pitti> lool: sounds just like a shallow wrapper around open_session_with_parameters()?
<lool> pitti: Michael checked the code and it basically does what the xinit patch did
<ogra_cmpc_> pitti, it does the same as the already existing pam module
<pitti> ah, ok
<lool> pitti: Unfortunately that call is root-only
<pitti> so the problem is not that you need a CLI tool instead of a lib call, but the place where to do it
<lool> pitti: So we'd have to move to the Xorg server *shiver*
<lool> pitti: Exactly
<pitti> lool: right, it must be root only
<lool> pitti: I'm just mentionning this because upstream told us so, but I think it was misguiding
<cjwatson> lool: I've attached the openssh patch to the bug, but I'm not sure how much it'll help you
<lool> cjwatson: Thanks
<cjwatson> lool: why is starting the CK session as root not an option? As you say, you do have root at some point in the process
<lool> cjwatson: Because we don't have the display at that time
<lool> cjwatson: It's basically su launching startx as ume which spawns Xorg as root
<lool> (I mean Xorg is suid root)
<cjwatson> oh, right
<lool> cjwatson: Thanks for the patch
<cjwatson> doing it in the X server would be too evil for words
<lool> cjwatson: What's the reason for merging it into ssh instead of pushing for the PAM module?  Is this for non-PAM sshd uses?
<lool> cjwatson: haha
<cjwatson> you can't use the PAM module with openssh for reasons too tedious to enumerate
<cjwatson> basically privilege separation awkwardness
<lool> Is this a design issue of the CK PAM module?
<cjwatson> no
<lool> As in, it should be using some helper to gain the privs it needs
<lool> AH
<cjwatson> no, it's just how openssh internals are arranged
<cjwatson> actually sort of similar to your problem in some ways - when the PAM session is opened, you don't know DISPLAY yet
<lool> It's sad to have PAM and to not be able touse it
<cjwatson> because the client hasn't yet requested the forwarded X connection
<lool> Oh
<lool> Ok
<cjwatson> or, for that matter, the tty
<cjwatson> you can have ttyless ssh sessions, you see ...
<lool> Sure
<lool> I understand the tty can be requested at any time, just like you can add port forwarding or X11 forwarding
<lool> And it's way too late to hope to use sshd root rights or PAM
<cjwatson> openssh actually does have a method to get back to root
<lool> cjwatson: Thanks for the explanations
<cjwatson> which in fact is used by the consolekit patch
<ogra_cmpc_> you could probably ssh -X localhost and have a sshd listen on lo
<cjwatson> but I don't think that's relevant to your problem
<lool> cjwatson: Oh; I wouldn't have expected that
<cjwatson> it's very carefully constrained
<lool> cjwatson: It's not relevant, but interesting nevertheless :)
<ogra_cmpc_> i.e. bring up your X server and loop back to run xinint though ssh
<cjwatson> if you see a mention of the "monitor" in openssh source, that's what that's doing
<cjwatson> lool: I sort of feel that, instead of running the whole of startx under su, the su ought to be deeper
 * lool slaps ogra_cmpc_ 
<ogra_cmpc_> heh
<lool> ;)
<cjwatson> so that you can pass some bits of information back up to something running as root that can open the CK session for you
<cjwatson> of course there is a certain historical expectation that running startx as a mortal user will DTRT
<lool> Yes
<ogra_cmpc_> ++
<lool> I've used it for years when I considered gdm dangerous for my X sessions
<ogra_cmpc_> gdm is fine as long as you dont want to restart or stop it :)
<lool> Also, I guess it's going to make us start a Xsession as root too
<cjwatson> exactly which dbus call is root-only?
<lool> cjwatson: The one with params
<lool> cjwatson: Which are required to pass the x11-display
<lool> cjwatson: The FD bug has some details of the params which we might want to set
<cjwatson> because I thought I remembered testing this as an ordinary user
<lool> Michael Frey told me it wouldn't work as it was root only I think
<lool> He commented as such in the FD bug
<cjwatson> ah, yes, you're right
 * ogra_cmpc_ thinks it was to early for CK inclusion
<lool> Now, I wonder whether it would make sense to let Xorg report to CK when a display is spawned and a VT allocated
<cjwatson> I guess I must have been using sudo dbus-send
<cjwatson> this really doesn't feel right in the X server at all
<lool> I understand we don't want to start a CK session there, but as Xorg is setting the VT etc.
<lool> cjwatson: But Xorg is the exact place where the system objects are requested/created
<lool> And where the DISPLAY comes to life
<lool> Naturally, I'm not happy with DBus coming into play with Xorg  :-/
<pitti> to me it feels slightly ugly to make X.org depend on CK
<pitti> (for a library call)
<pitti> it's less ugly to try and call ck-create-session, and just ignore if it isn't there
<lool> What about a Xorg module?
<cjwatson> the X server is wrong because if you're using remote X then it is on the wrong machine
<cjwatson> the CK session is a client-side concept, not server-side
<cjwatson> (with the usual confused X meanings of client and server)
<lool> cjwatson: I see; so we can have multiple sessions with the same display?
<cjwatson> consider X sessions forwarded over ssh
<cjwatson> they share an X server, but the actual DISPLAY variable is something different on a different host
<cjwatson> same goes for xdmcp
<cjwatson> this is why it should be the responsibility of the session manager
<cjwatson> or the display manager if relevant
<lool> Yes, but then apps launched in the remote SSH session are going to which CK session?  One spawned by sshd and related to the virtual DISPLAY, no?
<cjwatson> maybe you just need a trivial display manager
<lool> Or is this extending the local CK session?
<cjwatson> right, in the case of ssh the CK session is started by sshd, because sshd is effectively acting as a trivial display manager
<cjwatson> and session manager, rolled into one
<lool> cjwatson: So sshd is where the virtual DISPLAY comes to birth
<cjwatson> sort of, but I think that's the wrong way to think about it
<ogra_cmpc_> its a proxy server
<cjwatson> display managers are actually quite easy to write
<cjwatson> if you aren't trying to be gdm
<cjwatson> LTSP has a trivial one called ldm, and I wrote adapted versions of that for oem-config and ubiquity
<lool> cjwatson: Do we have anything close to such a dumb DM?
<lool> Ah LDM, thanks
<cjwatson> it's 100-odd lines of Python
<ogra_cmpc_> well, ldm is C now
<cjwatson> right, oem-config-dm isn't though ;-)
<ogra_cmpc_> look at the pre gutsy code for ldm in python
<lool> cjwatson, ogra_cmpc_, pitti: mind if I copy this log to the bug report?
<cjwatson> oem-config-dm is probably a better place to start as it doesn't have the ssh stuff
<cjwatson> not at all
<pitti> of course not
<ogra_cmpc_> fine with me
<pitti> it's publically logged anyway
<lool> pitti: (Yeah, but I asked for politeness ;)
<cjwatson> in oem-config-dm's case, it is told the display by its caller
<cjwatson> but the same usually goes for xinit as called by startx, doesn't it?
<lool> Yes
<ogra_cmpc_> yep
<cjwatson> I guess providing a display to startx isn't mandatory
<lool> I think the act of creating the CK session in xinit makes sense; we just have to figure a way for it do provision the DISPLAY information
<lool> From what I understand, xinit starts the server and then a client and it does know about the VT and the DISPLAY
<lool> It just needs enough power to tell CK about it
<cjwatson> the display manager could do that - it starts processes inside the display
<asac> ArneGoetje: do you still need someone who still sees the scim issue?
<cjwatson> oem-config-dm starts X, a window manager, stuff like gnome-settings-daemon, and the main "greeter" (in this case, oem-config
<cjwatson> )
<lool> cjwatson: But when you just "startx", you don't have a DM
<cjwatson> right, I'm suggesting not using startx
<lool> Yeah, I got your suggestion about using a DM for our concrete problem right now, but I thought we were back to discussing the CK fix for startx users
<lool> Since after all this ought to work as well
<cjwatson> oh, if we're talking *theory*
<lool> Well would we fix startx we wouldn't have to use a DM either
<cjwatson> maybe xinit needs to be setuid
<lool> So I've noted that we have some sample DMs that I could look into, and I think we'll probably use that, but the original problem is about xinit CK awareness
<cjwatson> and drop privileges when executing the client, obviously
<lool> Perhaps we could tell CK to please update it's information by looking at DISPLAY?
<lool> This kind of helper might not need any special rights at all
<cjwatson> if you can't do OpenSessionWithParameters as root, then logically you ought not to be able to do the same thing in other ways
<lool> "Hey, I think you should try to connect to :0.0 and see what VT it uses, you might want to add the data you find to your database"
<cjwatson> if you can, then either consolekit's permissions are too strict, or we are attempting to exploit a security hole
<cjwatson> which is all very well but not a good thing to build an application around
<lool> Well OpenSessionWithParameters implies that the params will be trusted
<lool> While what I'm proposing is that CK be pinged to please refresh its info
<cjwatson> sorry, I meant "if you can only do OpenSessionWithParameters as root" above
<cjwatson> CK does have helpers to figure stuff out from an X display
<lool> Oh perhaps it's the only thing we're missing
<lool> We have bits to start a session
<lool> We just need to tell it about VT and DISPLAY of this session
<lool> Hmm this is probably the security limit
<cjwatson> you only need to tell it DISPLAY
<cjwatson> (in theory)
<ogra_cmpc_> and the content of DISPLAY needs to contain your hostname ... then the session will become active automatically i was told
<lool> The security limit is probably related to "who are you to tell me what DISPLAY this CK session is using" I guess
<lool> Ah well, let's just stop at the conclusions that xinit might need to be suid and that we should use a trivial DM for now
<lool> Thanks all for discussion
<ogra_cmpc_> thanks for answering my question :)
 * ogra_cmpc_ beats i810 with a bat
<ogra_cmpc_> why the heck does that thing eat 50M extra if i use it ...
<cjwatson> lool: have you tried just calling org.freedesktop.ConsoleKit.Manager.OpenSession?
<cjwatson> and letting it guess?
<cjwatson> of course the process that calls that needs to run for the lifetime of the session, otherwise dbus will notice and close the session on you
<cjwatson> so it can't just be dbus-send
<cjwatson> (we need a dbus-send --exec=command or something)
<lool> cjwatson: I didn't try this
<lool> I wonder why I didn't try to start the session under Xorg
<cjwatson> it looks in /proc/blah/environ to fish out DISPLAY
<lool> But just ck-launch-session from within Xorg should simply work
<ogra_cmpc_> and i wonder why we dont make it mandatory to have that dbus call in x-session-manager ...
<ogra_cmpc_> that way we wouldnt need to hack up all display managers
<lool> I'll try to hook it to Xsession.d
<cjwatson> does ck-launch-session spawn a subprocess with the rest of your session?
<lool> I don't know; we don't have it; I think it does based on the xinit patch I've seen from fedora
<lool> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-xinit/xinitrc?r1=1.3&r2=1.4
<cjwatson> yes, it appears to
<cjwatson> http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;h=73111816d3785996ee25c18dc24e0a3657272428;hb=4740245c6f6137175ef51be2207c35185f4d98f1;f=tools/ck-launch-session.c
<cjwatson> that would be perfect, then
<lool> I really have a brain bug
<cjwatson> it wraps OpenSession, not OpenSessionWithParameters
<cjwatson> so it doesn't require root
<lool> So it exactly does what it's supposed to do: look at the DISPLAY of the calling process
<cjwatson> so the whole discussion above is overengineering :-)
<lool> Ok, let us ship a Xsession script within consolekit then?
<cjwatson> hmm, it should only call ck-launch-session if XDG_SESSION_COOKIE isn't already set
<cjwatson> but yes, that does sound like a good solution
<lool> Sure
<doko> pitti: please demote the python-qt4-gl binary package, we don't want to have the pyopengl dependency in main
<pitti> doko: hm, that's not in component-mismatches; I wonder what holds it in main
<pitti> (argh, ENOSSH again)
<doko> pitti, hmm I see it there
<YokoZar> I have a package (zsnes) that recently started building on amd64.  The last upload added amd64 arch to the control file, and it builds fine if I use dpkg-buildpackage.  However, looking it up on launchpad, the build daemon isn't even trying to build it on amd64, and gnome-app-install has it unclickable still
<pitti> doko: I don't
<pitti> doko: (should be in 'binary-only demotion')
<doko> http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt shows it in "Source and binary promotions to main"
<pitti> doko: right; most likely it's just held in main as part of a "rescued..." (i. e. trying to keep all binaries in main)
<pitti> doko: once I get back ssh, I'll demote it
<lool> cjwatson: Interestingly, it also means starting a CK session from PAM would be harmful
<Mirv> seb128: there's a rather weird problem that came with today's updates: tsclient and policykit-gnome lost their .desktop translations and f-spot reverted to upstream's (tested with two machines). any idea if it's a bug in language packs or somewhere else?
<seb128> Mirv: what did you update?
<seb128> Mirv: tsclient didn't change for a while, not like due to it, did you update language packs today?
<Mirv> seb128: everything since yesterday, it's hard to say but indeed tsclient lost its X-Ubuntu-Gettext-Domain patch already months ago but somehow the .desktop translation was there until today. I did update the language packs, but I'm not sure what the actual problem is.
<Mirv> policykit-gnome never even had that tag, but somehow the translation was there until today
<Mirv> (and there's no upstream translation for policykit-gnome)
<Mirv> seb128: the translations for the .desktop items are still there in the .mo files for all of those three
<seb128> ah, I know
<seb128> will fix it
<seb128> it's all lool fault ;-)
<seb128> he asked for a glib2.0 sync
<seb128> but we have a gettext patch there which is not in the debian serie
<Mirv> seb128: whee, great. I feel so like a poor bug reporter since I have no clue what happened :)
<seb128> fixing it now
<TheMuso> n/
<TheMuso> ugh
<seb128> carlos: how do you build your "not uptodate list"?
<seb128> carlos: ie, gnome-desktop is on it but the build log indicates that it generates a pot correctly, is that just because it was waiting for rosetta import when you made the list?
<YokoZar> https://edge.launchpad.net/ubuntu/+source/zsnes/1.510-2ubuntu1   <--- note how architectures = i386 and amd64, but there is no build attempt for amd64 (successful or failed). What do I do here?
<lool> doko: I think it would be excellent if we could get PySignal_SetWakeupFd() in our python
<lool> doko: Do you think that's risky/doable?
<cjwatson> lool: not if XDG_SESSION_COOKIE were set, which it would be
<lool> cjwatson: Well if we don't start a session when XDG_SESSION_COOKIE is set, how does CK know about the display?
<lool> doko: Background in http://bugzilla.gnome.org/show_bug.cgi?id=481569
<lool> doko: This is included in our pygobject and pygtk
<ArneGoetje> asac: if you have time, please do. :)
<doko> lool: hmm, I thought I had this done, but apparently not ...
<Riddell> pitti: I'm fine with dropping hwdb-client-kde.  I'd like to see a Qt version of hwtest soon though if that's the replacement but obviously too late for hardy.
<pitti> doko: demoted python-qt4-gl
 * lool &
<pitti> Riddell: thanks
<carlos> seb128: I check that the upload date is newer than latest template update and that it's already published and that there is no .pot file in the import queue pending to be imported
<pitti> Riddell: so, I'll just unseed it for Kubuntu then?
<carlos> seb128: but I guess there may be some race conditions
<seb128> carlos: ok
<carlos> seb128: like gnome-desktop one
<Riddell> pitti: I'll do it
<pitti> Riddell: ok, please let me commit the changes to ubuntu/gobuntu first
<pitti> Riddell: so that it can become  a proper merge
<pitti> Riddell: committed to ubuntu.hardy, feel free to merge now
<pitti> ogra_cmpc: would you mind merging the edubuntu.hardy seed? it's nontrivial
<ogra_cmpc> pitti, you sure thats needed ? edubuntu depends on ubuntu-desktop
<Riddell> pitti: merging the seeds doesn't really work any more
<pitti> ogra_cmpc: ah, right, seems it's not; so they are not real branches any more
<ogra_cmpc> right
<pitti> Riddell: I see; ok, then just kill hwdb-client, please
<ogra_cmpc> there is a dependency chain in place now
<pitti> hm, I still had to do it for gobuntu
<pitti> seems that isn't converted yet then?
<pitti> (maybe ubuntu should be on top of gobuntu, since ubuntu adds restricted stuff?)
<TheMuso> 661/c
<TheMuso> damn wireless keyboard needs resyncing again...
<pitti> TheMuso: .00000220333333333333
 * dholbach likes the new pitti-bot
<dholbach> pitti: 100 Rupies in Euros
<pitti> dholbach: 6250
<YokoZar> pitti: poke
<pitti> hi YokoZar
<pitti> TheMuso: .00000220485870603287 actually :)
<YokoZar> pitti: Any idea why the buildd doesn't seem to be attempting to build this on amd64?  https://edge.launchpad.net/ubuntu/+source/zsnes/1.510-2ubuntu1
<TheMuso> pitti: heh
<dholbach> . o O { pitti-bot needs a serious update }
<YokoZar> pitti: amd64 was added to control as an arch last upload
<pitti> YokoZar: control file has Architecture: i386 here
<pitti> in 1.510-1
<YokoZar> Err that link is to 1.510-2ubuntu1
<YokoZar> Which is newer
<pitti> oh, it's in universe now, sorry
<YokoZar> On the left of that page launchpad says its for amd64 and i386
<pitti> I bet it's P-a-S'ed
<YokoZar> Did it just get demoted or something?
<pitti> $ grep zsnes /srv/launchpad.net/builddmaster/Packages-arch-specific
<pitti> zsnes: i386     # Mostly written in i386 assembler
<pitti> there we go
<pitti> YokoZar: something for infinity or lamont to fix
<YokoZar> pitti: Ahh, cool.  Should I bug them or you?
<pitti> YokoZar: we keep them in sync with Debian, so I can't change them
<ogra_cmpc> woah, i think vesa is the solution for all my probs i ever had on the classmate ....
 * pitti wonders why it needs a Pas entry in the first place
 * ogra_cmpc cant belive that
<pitti> if the Architecture: is right, we shouldn't need it?
<pitti> lamont, infinity: ^
<pitti> ogra_cmpc: ... vesa? there goes your performance?
<YokoZar> pitti: Yeah.  If the control file just says i386 no need to hardcode that elsewhere.
<ogra_cmpc> pitti, exactly the opposite o_O
<YokoZar> People have been managing to build it on amd64 according to forum posts (though the current version of the package is segfaulting for me)
<YokoZar> By linking with 32 bit libraries (in much the same way Wine works on 64 bit)
<ogra_cmpc> pitti, well, performance migh get a very small not really noticeable overhead ... but it saves 50M ... which means i currently have a classmate that has firefox, aisle riot, abiword, gnumeric and two gnome terminals running at the same time and the system uses 170M of the acailable 241 ... and it still feels totally snappy
<ogra_cmpc> *available
<pitti> ogra_cmpc: awesome
<pitti> YokoZar: ah, ia32-libs to the rescue? :)
<ogra_cmpc> .... and i never even thought remotely about testing vesa here ... just did that by accident
<cjwatson> lool: XDG_SESSION_COOKIE is set after the CK session is created, not the other way round
<cjwatson> pitti: I didn't quite get as far as converting the Gobuntu seeds to the new world order
<YokoZar> pitti: Indeed.  We seem to be getting more dependent on it every release, when the intention was to use it as a temporary solution, heh.
<pitti> it's a hideous hack and a maintenance nightmare (not even mentioning unfixed security bugs)
<doko> pitti: please accept openjdk-6 (binary NEW)
<YokoZar> pitti: Is there even a mechanism to push a new build of ia32-libs whenever one of its components gets a security update?  Right now it seems like packages need to be freshened manually
<pitti> YokoZar: that's usually not a problem for the development release
<pitti> but that thing bitrots fast in stables
<YokoZar> On the plus side, only a few programs seem to depend on it
<YokoZar> On the down side, we're never going to get Wine to not depend on it (or separately made 32 bit versions of all the 20+ components it uses ala lib32z1), and Wine isn't going away.
<YokoZar> Actually I wonder if this would be a worthwhile project for Hardy +1 -- slowly phasing out everything in ia32-libs into separate lib32foo type packages
<RAOF> YokoZar: Please implement multiarch dpkg.  kthxbye
<pitti> YokoZar: that'll introduce a lot of source changes and complex multibuild setups
<pitti> YokoZar: you should just be able to apt-get install an i386 deb on amd64 and be done with it
<YokoZar> pitti: and have it magically go into /usr/lib32 ;)
<pitti> there are other issues, like file conflicts to all other files to the amd64 .deb
<pitti> so they would need some special magic, right
<YokoZar> pitti: Yeah, it's a huge mess, which is why no one's really done it.  Still, would making lib32-* packages be less bad than ia32-libs?
<pitti> but I guess the best answer for now is "if you can't live without i386, then install it and forget about amd64"
<pitti> or, as a compromise, debootstrap an i386 chroot
<Fujitsu> Is the default SCIMááµá¨á­ áá¢áá á¶ á áá½áá á áµ á³á¦á áá¢ááµ?
<Fujitsu> Erm.
<Fujitsu> That didn't work.
<Fujitsu> Is the default SCIM hotkey going to change at some point?
<pitti> Fujitsu: it's disabled by default again
<Fujitsu> (for reasons shown above)
<Fujitsu> Ah, good.
<pitti> Fujitsu: for us poor souls^Wdaily upgraders, disable it in the language chooser
<Fujitsu> What's such a thing doing in the tool traditionally used to install new languages?
<YokoZar> pitti: I'm not sure we're ever going to get rid of 32 bit i386 support completely.  Especially because of Wine and all the 32 bit apps out there it'll want to run.  Hell, even MS can't get rid of 16 bit windows libs (Wine can handle these though ;) )
<RAOF> There _was_ that multiarch spec lying dead on a Debian wiki somewhere.  Can it be resurrected?
<pitti> YokoZar: why do you run amd64 in the first place then, if you need that many i386 apps?
<YokoZar> pitti: Most users don't though.  They just need that one.  Which is about 90% of the use case of Wine, really - that one old legacy app.
<TheMuso> pitti: I can think of one situation where I would want to run an amd64 app but also use i386 apps via wine. Its called audio production to use > 2GBof RAM for audi osamples, plus audio VTS plugins via wine for virtual instruments not availab el in Linux yet.
<ogra_cmpc> mvo !!!!!!!!!!!!!!!!!
<ogra_cmpc> mvo, i just installed atlantik from universe on the cmpc .... USING G-A-I !!!
 * ogra_cmpc dances
<mvo> ogra_cmpc: ROCK! what did you had to change to make it work?
<ogra_cmpc> and that even with a gnome-terminal open running htop (which steals about 20M extra)
<ogra_cmpc> mvo, using vesa
<ogra_cmpc> that gained me more than 50M while only having a minimal performance loss
<mvo> cool!
<ogra_cmpc> my only prob now is that gdm starts up in panning mode (800x60)
<ogra_cmpc> *600
<YokoZar> So the last mail to the multiarch mailing list was in July 2006.
<ogra_cmpc> seb128, is there any way that i could inject a xrandr call into gdm so it resizes the screen yo proper 800x480 ? i tried /etc/gdm/Init/ but that didnt seem to work
<ogra_cmpc> s/yo/to/
<seb128> ogra_cmpc: no idea
<seb128> ogra_cmpc: why not updating the xorg configuration rather?
<ogra_cmpc> seb128, becuse i need a panning mode ... my xorg.conf has a Virtual directive that sets the screen to 800x600 ... the i810 driver defaults gdm to what it gets from the display and uses panning in the session only ... vesa operates exactly the other way round, so i have a panning gdm screen
<ogra_cmpc> seb128, and i would like to switch to vesa ... but that means convincing gdm to not start in the biggest size it can find in xorg.conf
<ogra_cmpc> inside the session, even in Xsession.d a call to xrandr -s 800x480 works fine ...
<ogra_cmpc> just not for the initial screen
<seb128> no idea about the issue
<ogra_cmpc> well, isnt /etc/gdm/Init/Default to be executed after X is up and beforre the greeter shows up ?
<YokoZar> pitti: I think having a discussion about how to best kill ia32-libs is a good idea for next UDS ;)
<seb128> ogra_cmpc: look to the gdm documentation, it tries :0, hostname, and then default
<seb128> ogra_cmpc: maybe you have one of the others which is used?
<pitti> YokoZar: heh, yeah
<seb128> ogra_cmpc: I never tried that though so I'm not sure if it works correctly
<ogra_cmpc> seb128, thanks i'll look i dont have anything inside /etc/gdm/Init but Default though
<seb128> ogra_cmpc: upstream are responsive on their list
<ogra_cmpc> ok
<seb128> you can try there
<soren> Can someone who has just a smidgeon of emacs knowledge grab bug 188218? I have *no* clue.
<ogra_cmpc> well, mccann is a resident in #ltsp recently i'll ping him this afternoon
<asac> ArneGoetje: [reed] in #ubuntu-mozillateam appears to still have issues
<jdstrand> doko, cjwatson, slangasek: as the author of ufw, I still believe shorewall should be in main. ufw works well as a host-based firewall, but shorewall is more complete (routing firewall, qos, etc)
<cjwatson> jdstrand: ok, that's good to know, thanks
<jdstrand> ufw won't hinder qos or routing mind you, but it doesn't help any more than iptables-restore helps in that regard
<TheMuso> Wow! First time I've been able to reliably differ between my user being in, and not being in, the pulse-rt group for pulseaudio...
<TheMuso> tjaalton: Yeah I've seen that pulse hangs around after logout. I'll confirm your bug now, but don't have any ideas at this point.
<tjaalton> TheMuso: cool
<TheMuso> Hrm. What package is responsible for GNOME's logging out? I wonder if it tries to kill a non-existant esd process, and simply needs a tweak to killa pulseaudio process...
<soren> TheMuso: gnome-session, I guess.
<seb128> they moved esd things out of there though
<seb128> now gnome-settings-daemon does the server init
<seb128> I don't think anything try to stop esd on logout
<TheMuso> seb128: Yeah, thats what I'm trying to remember. I don't remember if esd used to get killed on logout either.
<tjaalton> I've used the gdm PostSession hooks to kill stray processes
<seb128> TheMuso: gnome-session used to do that
<TheMuso> seb128: Right, so I guess if esd was used now, similar behavior would be experienced.
<seb128> what is the issue?
<TheMuso> Hrm, I'll have to test that one.
<TheMuso> seb128: After one logs out, pulseaudio is still running.
<TheMuso> bug 201359
<seb128> TheMuso: shouldn't it autoexit if nothing is using it for some time?
<TheMuso> seb128: It releases its hold on the sound device yes, but it doesn't shut down/kill itself if thats what you mean.
<seb128> it should
 * TheMuso logs out of another box with pulse running, and lets it sit to see what happens...
<Hobbsee> die scim, die.
<Hobbsee> hm
<Hobbsee> i can't even run any commands on the command line, as scim puts my text into chinese or something.
<Hobbsee> way cool.  whenever i hit "c"
<Hobbsee> or v.
<Hobbsee> yet whenever i purge it, my apps all take forever to come up, and start crashing.
<Hobbsee> and exit doesn't exit the thing.
 * Hobbsee sets it back to the english/european again
<Hobbsee> and now space.
<ogra_cmpc> seb128, gdm behaves sane, its xrandr thats mad with my issue
<seb128> ogra_cmpc: ok, good ;-)
<jdstrand> cjwatson, doko, slangasek: IMO, ufw should stay in standard seed and shorewall in supported, or 'desktop-supported' if that ever comes to be
<jdstrand> ufw is very well suited for desktops and bastion hosts
<TheMuso> Ok, as expected, after a box sitting there for 5 minutes doing nothing after logging out of GNOME with pulse being active in the user session, the pulseaudio process is still active.
<doko> jdstrand: ok, I'll readd shorewall to the supported seed
<jdstrand> doko: thanks!
<Hobbsee> hurrah.  purged enough, all the way down to im-switch.
<Hobbsee> i can type multiple words in non-kde programs now!  \o/
<Hobbsee> instead of a few letters, then nothing.
<cjwatson> Hobbsee: 'sudo update-alternatives --auto xinput-all_ALL' should have cleared it up
<cjwatson> or language-selector, check and uncheck the checkbox
<lool> cjwatson: What I mean is that if we don't create a new session in the new Xsession snippet, and rely on one created by pam-ck-connector, the session will lack info on the new DISPLAY, no?
<lool> So this would mean that if the XDG COOKIE thing is set, we should probably remove it and create a new session
<cjwatson> lool: don't use pam-ck-connector then
<cjwatson> I think if it is used then you should trust it and leave it alone
<cjwatson> the display manager might have known what it was doing
<cjwatson> in your case, you should take care not to use pam-ck-connector
<lool> Hmm ok
<lool> I hope they don't merge the xinit CK support then
<cjwatson> if they do, one hopes that they would arrange to tell it about DISPLAY
<Hobbsee> cjwatson: grumble.  that wasn't on the bug, but thanks.
<ion_> doko: Since you made the last kexec-tools change, perhaps youâd be interested in bug #201094 (thereâs a debdiff).
<ion_> doko: Oh, no URL bot. https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/201094
<doko> ion_: debdiff?
<doko> ahh, int the report
<ScottK2> doko: I've run into what appears to be a python-central (or some python tool chain) problem in my python-xml transition work.  When I test build eric python:depends claims it depends on python-central 0.6 (which obviously isn't going to work).  Same package built against Sid wants python-central 0.5.8.
<doko> ScottK: why not?
<ScottK2> Do we have 0.6 in Ubuntu and I missed it?
 * ScottK2 looks
<ScottK2> Sure enough
<ScottK2> doko: Nevermind.  Looks like my pbuilder was more up to date than my system.
<doko> heh
 * ScottK2 makes note about having test box pointing at a mirror when the pbuilder points at a.u.c.
<cjwatson>   * Add 100_sloppy_lock.diff, which reverses the locking logic, ie. sloppy
<cjwatson>     locking is the default. To disable that, set the environment variable
<cjwatson>     LIBXCB_DISABLE_SLOPPY_LOCK to any value. (LP: #87947)
<cjwatson> tjaalton: I hope that's "any value other than 1"?
<cjwatson> tjaalton: ... oh, never mind, it was previously LIBXCB_ALLOW_SLOPPY_LOCK not DISABLE
<lool> cjwatson: I saw your comments on policy on update-alternatives; I believe update-rc.d is in a similar situation with the new sysv replacements
<lool> (e.g. we had to update-rc.d remove forcefully dbus on upgrades to move it around the init sequence)
<cjwatson> kind of, though that's in exceptional cases rather than routine
<cjwatson> in the case of update-alternatives, you get this problem all the time
<lool> Sure; the similarities made me want to mention them to you though
<doko> ion_: done
<ion_> doko: Thanks
<cjwatson> lool: yeah, there are definitely similarities elsewhere; I'm mostly trying to get it through Manoj's head that it's worth documenting
<cjwatson> not least because I don't even know the most correct way to use it, and I've studied it
<TomaszD> \sh, hi. Remember https://bugs.launchpad.net/ubuntu/+source/wine/+bug/198761 ? Someone screwed up along the way, because it seems the translation was copied and pasted from the browser window, without changing the encoding to UTF8, now the translation looks horrible.
<\sh> TomaszD: please file a bug :) YokoZar or I are dealing with it
<TomaszD> \sh, right-o.
<\sh> TomaszD: thx :)
<YokoZar> TomaszD: my fault.  I thought I enabled the locale in firefox before doing that, apparently not
<jdstrand> pitti: I told apport to ignore further crashes with a particular version, is there a way to 'unignore'? (please just point me to docs if it's written up somewhere)
<YokoZar> TomaszD: Just reopen that bug actually
<TomaszD> YokoZar, ok.
<TomaszD> YokoZar, done
<pitti> jdstrand: just remove ~/.apport-ignore.xml, or edit it if you need other ignores
<jdstrand> pitti: ah thanks
<jdstrand> pitti: actually it was /root/.apport-ignore.xml here
<pitti> ah, for system crashes, yes
<seb128> lool, Mithrandir: can any of you look to bug #190700 (gnome-bluetooth new version sponsoring request)? it looks easy, if you don't I'll do it
<TheInfinity> tjaalton, bryce: hmm ... just a question for a bug - can you look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/196242 soon if you have some time for this? because its difficult to make alphatesting of live cd without xorg ... thanks :)
<tjaalton> TheInfinity: 64bit with nvidia?
<TheInfinity> tjaalton: yes
<tjaalton> TheInfinity: try disabling usplash with nousplash
<tjaalton> TheInfinity: on the kernel cmdline
<TheInfinity> ok i'll test it :)
<seb128> hum
<seb128> is anybody looking at updating consolekit in hardy?
<seb128> we have 0.2.3 where upstream has 0.2.10
<pitti> seb128: anything that we particularly need from the new version?
<pitti> seb128: there was a huge discussion about that new CK feature to control shutdown/reboot, and many people want it reverted
<ogra_cmpc_> pitti, didnt you talk bout ck-register-session before today ?
<ogra_cmpc_> that would likely require the new version
<pitti> right
 * ogra_cmpc_ scratches head about whiptails menu function ...
<pitti> but I'm not comfortable with updating such a fundamental thing now just because it's a new version number
<pitti> IOW, we should consider it if the new version has things we really need
<seb128> pitti, TheMuso: discussing with a redhat guy the esd not stopped on logout issue
<pitti> seb128: pulse in our case?
<seb128> yes
<pitti> ah
<seb128> he says that consolekit is supposed to revoke the right on the sound device
<ogra_cmpc_> so i have a tag and an item for every line in the whiptail --menu function ... with --noitem it supresses the item, else it shows both  ... if i select somethng tag is returned .... why do i have item at all then ?
 * ogra_cmpc_ doesnt understand the purpose ... apart from adding comments or so as item text
<seb128> pitti: do you know what set the permission on the sound device at login?
<pitti> seb128: how on earth should CK revoke access to the soundcard?
<ChickenCutlass> I would vote for upgrading to the new consolekit -- UME needs the new utility ck-launch-session, that is included
<pitti> seb128: it never changes in Ubuntu, it's always root:audio 660
<seb128> pitti: I don't understand how the thing work
<pitti> seb128: we haven't CK'ized sound card device access yet
<pitti> (not sure we should either)
<huats> seb128: I have put the debdiff for the new yelp
<pitti> what we should do is to kill pulse on session shutdown
<seb128> huats: thanks
<huats> I am putting the bug number on the wiki...
<huats> seb128: and thanks to you ;)
<ogra_cmpc_> pitti, CK is still pretty immature imho ... the less we have of it in hardy the better
<cjwatson> ChickenCutlass: there are other ways to deal with that, such as a backport
<pitti> ogra_cmpc_: well, we have used it since gutsy, but we use it for more things in hardy admittedly
<ogra_cmpc_> right
<cjwatson> the Debian consolekit maintainer has some serious objections to the newer consolekit and refuses to update; there was a long thread on the hal list about it; while I'm not sure I necessarily agree, we shouldn't just ignore those objections
<ChickenCutlass> cjwatson, true
<cjwatson> and objections like that are a pretty good reason not to make such a substantial update during feature freeze
<ogra_cmpc_> i dont say the code or design is flawed ... but its not been used in context much yet ...
<pitti> it would just have been pretty much (pointless) work to work against upstream and make gnome work without CK/PK
<ogra_cmpc_> and is still pretty much in flux
<ogra_cmpc_> yeah
<ogra_cmpc_> i dont say its our fault :)
<ogra_cmpc_> i just think upstream switched to early
<cjwatson> ChickenCutlass: I suspect a backport is fairly straightforward; when I looked at the ck-launch-session code it seemed fairly self-contained
<ChickenCutlass> cjwatson, yes -- I already looked at it as well.  I am going to try it and see if it solves our problem this week
<seb128> pitti: I've no real reason for the update, I just noticed we were many version behind and was wondering if that's an update we should consider
<seb128> TheMuso: http://bugzilla.gnome.org/show_bug.cgi?id=522017
<doko> lool: PySignal_SetWakeupFd is now uploaded, had it backported, but not applied. please wait until both python2.4 and python2.5 are built on all archs
 * pitti wonders why our different hardy kernels switch back and forth between hda and sda (i. e. using scsi drivers for IDE drives)
<ogra_cmpc> pitti, i thought that was generalized to scsi for everything now
<pitti> right, I had that for quite a while
<pitti> but nowadays I'm back to hda
<pitti> BenC: ^ is that intended?
<BenC> pitti: yeah, just needed settling down
<soren> pitti: How do you notice that?
<pitti> soren: well, I have /dev/hda*
<soren> I know how to check it, sure, but I'd never notice if it changed on my box, I think.
<soren> UUID based fstab ftw.
<pitti> it just occured to me by accident, when I tried to run my 'test-fsck' script from a few weeks ago
<pitti> yeah, UUIDs DTRT here for mounting
<pitti> but the script died with pain and anger because /dev/sda3 didn't exist any more
<soren> I was just surprised since we have the same laptop, and I hadn't noticed anything like that at all.
<pitti> soren: I'm speakign about my desktop
<pitti> soren: my laptop has SATA, I think they have always been treated as SCSI
<soren> pitti: Oh, ok.
<lool> doko: Cool, thanks!
<Loevborg> I hope this is the right place to ask. IÂ´m thinking about creating a modified version of ubuntu for the asus eeepx (small laptop w/ 4GB of flash disk). What I want to do is, among other things, add a modified madwifi driver and change some of the defaults of desktop applications.
<Loevborg> For instance, thunderbirdÂ´s icons should be smaller by default.
<Loevborg> So I think creating a custom USB stick install would be the right thing to do, and keep everything as close to ubuntu as possible. What I worry about is packages being updated to a stock Ubuntu version when apt-get updating.
<Loevborg> Are there any active projects that do something like this, i.e. customize Ubuntu for specific hardware?
<ogra_cmpc> Loevborg, i'm the guy developing the classmate version
<ogra_cmpc> i have a builder script and an installer that works with such devices and creates an installable image out of a squashfs ... currently its classmate specific but i plan to make it more generic in intrepid
<ogra_cmpc> Loevborg, http://people.ubuntu.com/~ogra/classmate/images/
<ogra_cmpc> its *very* hw specific though and the classmate has way worse specs than the eeepc
<Loevborg> ogra_cmpc: sounds great. So I guess youÂ´re facing the same problems? Will you use standard ubuntu apt repository?
<ogra_cmpc> but you could try out one of these :)
<ogra_cmpc> indeed i will
<ogra_cmpc> s/will/do :)
<ogra_cmpc> there is only one universe package i add (915resolution) ... all the rest is standard
<ogra_cmpc> from the main archive
<Loevborg> is there a mailing list or something/
<Loevborg> ?
<ogra_cmpc> no
<ogra_cmpc> i was thinking about starting a subnotebook desktop project
<ogra_cmpc> bryce, ^^^ how about that ?
<Loevborg> ogra_cmpc: that would be awsome
<Nafallo> ogra_cmpc: eee covered?
<ogra_cmpc> Nafallo, 800x480 low power machines covered
<Nafallo> :-)
<ogra_cmpc> not hw specific
<bryce> ogra_cmpc: badly needed
<ogra_cmpc> its about the desktop
<Loevborg> there already are some EEEpc ubuntu customiyations, but they are hackish AFAICT
<Nafallo> Loevborg: they really are.
<Daviey> There is a asus eeepc kernel module
<ogra_cmpc> Loevborg, the classmate one as well ... well, not hackish but for example not dist-upgradeable by design
<Loevborg> I thought it is time for a soultion done right.
<Nafallo> Daviey: that does what?
<Daviey> Nafallo: Gives you extra ACPI control
<ogra_cmpc> the prob is that you cant do it right if you go with such heavy desktop HW
<ogra_cmpc> s/HW/SW
<Nafallo> Daviey: ah. the overclock button :-P
<ogra_cmpc> and with heavy i include xfce here ....
<Loevborg> Daviey: yes, the eeepc might need a custom kernel. Or maybe it doesnÂ´. It would be better if it worked without one.
<Daviey> Nafallo: been to scared to try that - more switching the fan off :)
<Daviey> too*
<ogra_cmpc> Loevborg, i thinnk it works without specific kernel changes ... but ypou need extra stuff for wlan etc
 * ogra_cmpc envys the eee users for their HUGE keyboard
<Daviey> Loevborg: imo, there isn't a problem with big customisations - providing it's all packaged and a subnotebook-desktop meta package created :)
<Loevborg> ogra, yes, the keyboard perfectly usable
<Loevborg> Daviey: what about changed font defaults for thunderbird etc.? thatÂ´s what makes the default xandros on the eeepc neat.
<Loevborg> ogra_cmpc: where do I find the script you mentioned?
<ogra_cmpc> on my build machine
<ogra_cmpc> as soon as i'm done (end of teh week) i'll release a bzr branch
<Daviey> Loevborg: I think that is a whole custom theme for thunderbird
<Daviey> and one for FF AIUI
<Loevborg> ogra, could you drop me a line when itÂ´s done?
<ogra_cmpc> sure
<ogra_cmpc> Loevborg, btw http://people.ubuntu.com/~ogra/LightBrowser/
<ogra_cmpc> and bryce works on a 800x480 inkscape version atm
<Daviey> ooo, that is lightweight
<Daviey> ogra_cmpc: gecko based?
<bryce> ogra_cmpc: that was just a prototype/proof-of-concept btw, I'm not actively developing that - it was just to stimulate other inkscape developers to work on
<ogra_cmpc> Daviey, xulrunner based
<bryce> ogra_cmpc: good news is that several people are already working actively on that for 0.47
<ogra_cmpc> bryce, cool
<Daviey> Loevborg: I'd quite like to get involved with this.
<ogra_cmpc> i'm looking for a javascript eager develope to take over lightbrowser :)
<Loevborg> Daviey: so a custom ff/thunderbird can just be dropped in without changing the ff/tb package?
<Daviey> i'm yet to meet a developer keen on js
<bryce> ogra_cmpc: https://blueprints.launchpad.net/inkscape/+spec/kidscape-project,https://blueprints.launchpad.net/inkscape/+spec/toolbar-resize
<Daviey> Loevborg: hmm, might need a package on top that depends on standard FF/TB
<ogra_cmpc> oh, wow, you specced it already
<Loevborg> Daviey: Cool. It would be great to have a few people working on a general solution. so you also have an eee?
<Daviey> Loevborg: I have 2 :)
<Loevborg> ogra_cmpc: my email address is pesterhayz@gmx.net btw
<Loevborg> rats
<Loevborg> ogra_cmpc: pesterhazy@gmx.net
<ogra_cmpc> oki
<ogra_cmpc> ogra@ubuntu.com fwiw
<mvo> tseliot: thanks for your mails, I will answr today
<tseliot> mvo: thanks :-)
<ScottK2> slangasek: Do you have any feelings either way about further new package exceptions for OLPC/Sugar related packages?
<ogra_cmpc> ScottK, getting the squeak update ready (and past the license police) would also be a good thing (tm)
<ogra_cmpc> i know its used a lot on OLPC
<ogra_cmpc> (as well as in edubuntu :) )
<ScottK2> ogra_cmpc: I'm not packaging it, I'm just trying to get some RM feedback to help decide on a Universe FFe.
<ogra_cmpc> ah
<pitti> mvo: did you ever encounter bug 174128 again?
<ubotwo> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
<ion_> doko: kexec-tools failed to build because something set LDFLAGS=-Wl,-Bsymbolic-functions and the Makefile did ld $(LDFLAGS) instead of cc $(LDFLAGS). Iâll post a debdiff in a while. Should i use 20070330-4ubuntu2 or 20070330-4ubuntu3?
<kbueno> !ciao
<ubotwo> How should I know?
<ion_> doko: Hereâs a debdiff that should fix the FTBFS: http://heh.fi/tmp/kexec-tools_20070330-4ubuntu2.debdiff. I hope itâs ok i used 20070330-4ubuntu2 as the version number instead of bumping it.
<geser> ion_: it needs a new version, as -4ubuntu2 already exists in the archive (in this case only a source)
<slangasek> ScottK2: well, my feeling is that it would be nice to have some follow-through on things like bug #183021, #183015, #183017 before piling in new packages...
<ubotwo> Launchpad bug 183021 in sugar-datastore "package-installs-python-pyc" [High,Confirmed] https://launchpad.net/bugs/183021
<ubotwo> Launchpad bug 183015 in sugar-presence-service "python-script-but-no-python-dep" [Medium,Confirmed] https://launchpad.net/bugs/183015
<ubotwo> Launchpad bug 183017 in sugar-datastore "python-script-but-no-python-dep" [Medium,Confirmed] https://launchpad.net/bugs/183017
<ScottK> slangasek: Thanks.
<ion_> geser: Alright, thanks.
<jdstrand> keescook: re bug #144900
<ubotwo> Launchpad bug 144900 in usplash "usplash crashed with SIGSEGV in __svgalib_get_perm()" [Medium,Confirmed] https://launchpad.net/bugs/144900
<jdstrand> I rebooted into the -12 kernel and it crashed.  I then rebooted back into the -11 kernel and it did not
<jdstrand> I only did each reboot once though
<ion_> doko: http://heh.fi/tmp/kexec-tools_20070330-4ubuntu3.debdiff
<bdmurray> pitti: I've heard of a couple of apport-crashes where ubuntu-crashes-universe had to be subscribed manually
<compbrain> wth does &>> not work in bash?
<pitti> bdmurray: probably because apport-retrace was buggy at that time (broken p-lp-bugs), so it removed the tag, and then crashed before sub'ing the team
<bdmurray> pitti: okay, its working now?
<slangasek> compbrain: instead of >>  2>&1 ?
<pitti> bdmurray: yes, should
<keescook> jdstrand: usplash crash> does it crash every time you boot -12 ?
<jdstrand> keescook: I knew you were going to ask that ;)
<keescook> haha
<jdstrand> keescook: I can't reboot right now, but I'll let you know
<keescook> jdstrand: okay, I think I saw this crash when I booted -12 for the first time (when snd was missing), but on the next attempt, it didn't (with working snd)
<compbrain> slangasek: Yeah.
<compbrain> zsh does the right thing, bash bails
<jdstrand> keescook: maybe I don't understand usplash at all, but am curious why snd has anything to do with it
<keescook> what's very very odd-ball about the crash is that it's during an "in" instruction ... the only way that can crash is if the kernel allowed the ioperm() call, and then later revoked it... which ... I thought wasn't possible
<keescook> jdstrand: right, I doubt that's the cause, but I meant I'm suspicious of -12 too
<keescook> I'll try a few reboots now for fun... :P
<jdstrand> keescook: I see
<slangasek> compbrain: "the right thing" is defined by the documentation of the app in question; that's not standardized by any stretch of the imagination
<cjwatson> compbrain: FYI, http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_07 is the standard for shell redirections
<jdstrand> keescook: well, maybe I'm still seeing the crash because my nvidia driver doesn't load anymore
<jdstrand> keescook: based on our conversation, and I don't know why this would be the case at all, if there is some sort of error on boot then usplash crashes
<cjwatson> mathiaz: I don't understand how bug 193696 is an installer bug
<ubotwo> Launchpad bug 193696 in postgresql-8.3 "Postgresql 8.3 not installed on hardy-server - unable to create /dev/null" [Low,Invalid] https://launchpad.net/bugs/193696
<cjwatson> mathiaz: d-i most definitely doesn't create a system with a broken /dev/null, or we'd know about it from more than pg :-)
<mathiaz> cjwatson: hum.. So where the message "Mar 11 03:19:59 in-target: SH: CANNOT CREATE /DEV/NULL: PERMISSION DENIED^M" would come from ?
<cjwatson> mathiaz: are you sure your bug is the same as Murray's? Even if it is, all you've demonstrated is that postgres fails in both scenarios
<ogra_cmpc> /etc/udev/rules.d/40-permissions.rules ?
<cjwatson> mathiaz: Murray says it fails outside d-i, you say it fails inside d-i. That doesn't suggest a d-i bug
<mathiaz> cjwatson: right - I start to think that murray's bug is different
<cjwatson> mathiaz: they may well be the same
<mathiaz> cjwatson: well - an apt-get install postgresql-8.3 works for me in hardy
<cjwatson> all I'm saying is you haven't demonstrated it either way :)
<mathiaz> cjwatson: correct - I'll try to look into that.
<cjwatson> if you can't reproduce Murray's problem in a similar environment, we need to talk with Murray to find out how his environment differs
<cjwatson> mathiaz: also, checking permissions on /target/dev/null when that happens would be useful
<mathiaz> cjwatson: right - so I may need to open a new bug then.
<cjwatson> mathiaz: please don't yet
<cjwatson> mathiaz: another possibility is that some other package is trashing /dev/null
<cjwatson> for example, if a maintainer script did 'rm /dev/null' (or similar) before postgresql-8.3 is installed, then you'd see these symptoms
<mathiaz> cjwatson: ok - but there is definetly a bug with the postgresql tasksel in d-i.
<ogra_cmpc> wow, intresting that you are actually the first person on the bug asking for ls output of /dev/null
<cjwatson> mathiaz: and that would not be a d-i bug, but a bug in the package that does this
<mathiaz> cjwatson: whether it's the same bug as the one reported by murray is still be discussed
<cjwatson> indeed, but it may well provide clues
<cjwatson> I will download the Hardy server CD and try to reproduce as well
<mathiaz> cjwatson: this has been around at least since alpha3
<cjwatson> if a package is indeed trashing /dev/null, then that's very serious and may well be biting people in all kinds of ways
<cjwatson> and it would be easy to ask if Murray has that package installed
 * ogra_cmpc wonders what happens if something cats to /dev/null before udev it creates ... does udev just overwrite it ?
<slangasek> ogra_cmpc: debootstrap is supposed to create /dev/null as part of its initial chroot
<ogra_cmpc> h, indeed, no udev running inside the chroot ..
<slangasek> isn't udev supposed to be involved in setting up in-target nodes, so that bootloaders work right?
<cjwatson> slangasek: yes, it is
<cjwatson> slangasek: but that doesn't prevent some maintainer script removing a node that udev had previously created
<slangasek> yes, true
<slangasek> I was just wondering about ogra_cmpc's comment about no udev running inside the chroot; I don't know whether there's supposed to be, or if it's handled by the main process running outside the chroot
<cjwatson> udev is bind-mounted into /target by base-installer
<cjwatson> I didn't see ogra_cmpc's comment due to ISP breakage
<slangasek> ah, so
<cjwatson> oh, actually, that bind-mount is just for the duration of base-installer and doesn't in general apply to in-target
<ogra_cmpc> not in d-i: before udev runs there is a static dev with the most basic devices you need ... that gets moved to /dev/.static/dev  if udev starts up
<ogra_cmpc> i guess thats the /dev deboostrap created
<cjwatson> MAKEDEV creates /dev/null with proper permissions though
<cjwatson> $ deb-extract-file /mirror/ubuntu/pool/main/d/debootstrap/debootstrap-udeb_1.0.8_all.udeb ./usr/share/debootstrap/devices.tar.gz | tar tzvf - | grep null
<cjwatson> crw-rw-rw- root/root       1,3 2008-01-15 12:48 dev/null
<slangasek> it also shouldn't be 'cannot create [...]' if it were a permissions error, either
<cjwatson> right
<cjwatson> if /dev/null had been removed, then the next thing to do >/dev/null would need to have write permission to /dev
<cjwatson> which would be consistent with the error message
<cjwatson> we've seen occasional instances of /dev/null winding up as a regular file, but never been able to track them down; those are almost certainly caused by something removing /dev/null, too
<cjwatson> (since if the next thing to write to /dev/null is running as root, it can create it as a regular file)
<candrews> https://bugs.launchpad.net/ubuntu/+bug/199754 That package has been completed, builds, and works on Ubuntu. How does it get included in the repository?
<ubotwo> Launchpad bug 199754 in ubuntu "[needs-packaging] mod_auth_cas" [Wishlist,Incomplete]
<ogra_cmpc> candrews, through REVU ... the guys in #ubuntu-motu cen help you
<ogra_cmpc> *can
<candrews> thank you - I'll redirect my question there
<juliank> Could we get ndisgtk added to the ship and ship-live seeds (amd64,i386)?  I am no core-dev, so I can't do this.
<ogra_cmpc> juliank, the quesion is why ...
<ogra_cmpc> ... are you no core-dev yet :)
<ogra_cmpc> juliank, do you know if that was discussed and agreed on ?
<juliank> ogra_cmpc: The MIR bug got "Fix released" and pitti wrote: " - get it seeded to somewhere, so that it will stay in main", that's what I want to do now. What is needed to do this?
<rsc> Good evening. Is somebody able to tell me, whether Ubuntu builds ships openssl linked against kerberos5 per default?!
<compbrain> slangasek: Yeah.
<compbrain> cjwatson: Thanks
<ogra_cmpc> juliank, added
<juliank> ogra_cmpc: thx
<yennes> has anyone sucessfully installed boost
<yennes> ??
<Seveas> yennes, #ubuntu for support
<alex-weej> i really need an ubuntu archive mirror that is reasonably up to date and that doesn't crawl along at 80kB/s on my 20Mb connection
<alex-weej> are the main mirrors doing throttling on purpose?
<alex-weej> both the UK and the main archive are dog slow
<Chipzz> alex-weej: just put 2 mirrors in your sources.list?
<Chipzz> if you put them in te right order it will fetch files it can fetch from the faster mirror, and the other files from the other one
<Keybuk> alex-weej: it could be your ISP, you're on NTL so anything is possible :-/
<alex-weej> yeah could be :/
<pochu> or select the option in software-properties to download the packages in the background
<alex-weej> they do run their own mirror
<alex-weej> but it's literally days out of date i think
<alex-weej> Chipzz: that's a good idea...
<alex-weej> Chipzz: how do i do this then? i want the repo data to be taken from archive.ubuntu.com but the files from virginmedia when possible
<alex-weej> virgin media is like 4 days out of date... :(
<alex-weej> should be peer to peer
<alex-weej> man that would rock
<twb> Is there an equivalent to snapshot.debian.net for Ubuntu?
<ScottK2> Not that I know of.
<keescook> slangasek: can you take a look at bug 199674 in the hopes of me getting it uploaded before beta freeze?
<ubotu> Launchpad bug 199674 in inkscape "Feature Freeze Exception for 0.46 final" [Undecided,New] https://launchpad.net/bugs/199674
<dajhorn> If I have a package with an open bug, and the bug is fixed upstream, but I cannot increase the main version, should the LaunchPad ticket be set "closed" or "fixed committed"?
<dajhorn> Or "in progress" or somesuch.  I don't see the answer in the policy document.
<cjwatson> dajhorn: there should be two tasks on the Launchpad bug, one for Ubuntu and one for upstream; the upstream task should be fix released (if it's a bug tracking system that Launchpad understands, it'll do this for you)
<cjwatson> if you do it that way then it shows up in searches for "bugs fixed elsewhere"
<dajhorn> cjwatson: Ty.
<dajhorn> cjwatson: The dev in charge is closing the tickets, they are being re-reported and marked as duplicates, and so we're getting some hate mail.
<slangasek> keescook: I have a couple in the queue ahead of that one, but I'll look at it today, does that suffice?
<keescook> slangasek: yup, that's cool.  I've just been itching to dput it.  :)
<xipietotec> hey, weird question, can anyone tell me what the suspend/hibernate daemon (service, kernel module, whatever) that ubuntu uses by default in gutsy? I err, installed suspend2, and broke everything
<YokoZar> lamont + infinity: Did you see pitti's request above?
<YokoZar> zsnes should build on amd64 now but it's PASed: https://bugs.edge.launchpad.net/ubuntu/+source/zsnes/+bug/184255
<ubotu> Launchpad bug 184255 in zsnes "[patch] build amd64 package of zsnes" [Wishlist,Confirmed]
<lamont> YokoZar: no - hadn't seen it...
<lamont> is that zsnes in debian as well??
<YokoZar> lamont: not sure.  Probably not actually.
<YokoZar> lamont: but the package only lists i386 in its control file anyway, so it doesn't really need to be PASed at all
<YokoZar> Err, the package now also lists amd64, but the debian one is probably only i386
<lamont> However, apt-get --build source zsnes will work (though when I did this it would segfault on startup). Something weird is going on.
<lamont> so...  does it actually work?
<slangasek> I suspect it builds with -m32 :-P
<compbrain> Today on bad ideas: strace -f a debootstrap process...
 * lamont decides to leave zsnes for infinity to decide about, although I might poke joshk about it if I see him any time soon
<lamont> compbrain: sounds, uh, lengthy
<compbrain> lamont: Indeed.
 * milli recalls that lamont needs to be somewhere
<lool> Would it make sense to promote desktop-file-utils to desktop-common?
<YokoZar> lamont: it segfaults for me too, but according to forum posts some people have gotten it working
<lool> AFAIK, it's common to XDG DE
<lamont> YokoZar: I'd kinda like to see it "just work" if installed, rather than require lots of hackery
<lool> It's pulled by Xfce and GNOME thingies ATM
<YokoZar> lamont: so the segfaulting is likely just a problem with the package build script, one I'm pretty sure hasn't gone checked since, well, the package isn't being built at all now
<lamont> esp since adding it to PaS will result in the debian maintainer getting bugs when it fails to build or whatever.
<lool> In fact it's pulled by ubuntustudio-desktop, ubuntu-desktop, thunar
<YokoZar> lamont: no it's in PaS already and needs to be removed from there.  The control file should be preventing its build on anything but i386 as is.
<lamont> it's getting built by both the people who get segvs and the people who don't....
<lool> and gobuntu-desktop
<slangasek> lamont: so when are you going to put P-a-s in bzr so that we can have separate Debian and Ubuntu branches? ;)
<lamont> slangasek: EPAIN
<lamont> as in OMFG NO
<slangasek> pff
<lool> Hmm as mobile is based on minimal, it wouldn't work anyway
<slangasek> 'bzr pull' -- done
<lamont> merge conflicts would be _PLENTIFUL_
<Fujitsu> lamont: Just write your own merge algorithm for P-a-s.
<slangasek> not if you continued to use the Debian one as the main branch and only diverged in the Ubuntu branch
<lamont> slangasek: not true.
<lamont> debian changes a line, and ubuntu changes 2 lines away...
<lamont> pain
<lamont> and then there's the whole git vs bzr discussion for the debian tree.
<slangasek> er?  surely bzr's merge algo is better than that?
<lamont> does bzr allow me to hit a git repo and be happy these days?
<lamont> slangasek: maybe..... dunno
<slangasek> I think bzr lets you hit any drugs you want and be happy
<lamont> most files find that things next to each other are _uh_ related.
<lamont> note that happy and successful are not necessarily congruent.
<YokoZar> lamont: in the case of zsnes, which in debian has i386 only in its control file and ubuntu has i386 amd64, you agree with me that there's no need for it?
<lamont> gah.
<lamont> coffee shop times out in it's nat config... gonna have to turn on keepalives, it looks like
<milli> lamont: you can tunnel out through hashmal via openvpn if you need to, just have to gen you a client key.  Varous ports are blocked at that coffee shop.
<lamont> milli: I'll bug you later
<lamont> is EOD for me, kids to fetch and such
<lamont> milli: it's more the ssh windows going *poof* without warning, mixed with me not remembering which system they were on, that is the issue.
<lamont> the far end is a screen session, so it's not a bad thing, just an annoying thing
<james_w> lamont: hopefully soon we'll support specialist merge algorithms, so you can ignore context in the merge, and so you want get a conflict.
<james_w> and we'll also be able to merge debian/changelog as well.
<james_w> but unfortunately bzr-git is still pretty poor.
<milli> lamont: screen is your friend, of course.
<wasabi> This is silly. System keeps resetting my timezone to Monterrey.
<seb128> wasabi: why would your timezone change automatically?
<wasabi> Got me. Looks like everytime I reboot.
<wasabi> Hmmm. What significance does /etc/timezone have anymore? None?
<seb128> it's the timezone you are using
<wasabi> Is set to US/Central.
<wasabi> Which does not even appear as an option anymore in the gnome-UI
<Chipzz> twb: you can get old versions of packages on launchpad though
<seb128> not sure what the clock applet is using
<slangasek> /etc/timezone doesn't appear to really be read by anything
<Chipzz> alex-weej: sbeen a while since I had such a setup; basically you just have 2 deb lines for the some distro/release etc, and order matters
<Chipzz> alex-weej: you put the out-of-date one first iirc
<Chipzz> but
<twb> Chipzz: I don't understand.
<Chipzz> the repo data will always be taken from both mirrors
<twb> Chipzz: the whole point of the exercise is to get old versions; why is this a "... though"?
<Chipzz> twb: well, if you want an older version of a package, you click around on launchpad
<Chipzz> the binary debs are there
<slangasek> wasabi: go to the clock applet, "edit", select your location (what city, BTW?), "edit", choose America/Chicago
<wasabi> I did.
<slangasek> and it reset after that?
<Chipzz> twb: yes, and you can
<wasabi> I did it yesterday. Just a moment ago I noticed it was back to Monterry
<wasabi> Yeah.
<slangasek> hmm
<twb> Chipzz: oh, sorry.
<slangasek> I haven't had it reset on me in that fashion
<twb> Chipzz: I also asked the question in #ubuntu-server, and I got an answer there
<wasabi> I can't think of anything that might potentially do that other than dhclient.
<slangasek> once you save, the value is supposed to be saved to gconf
<wasabi> But if /etc/timezone isn't even used....
<twb> Chipzz: I thought you were continuing that discussion ^_^;;
<wasabi> hmm. It makes me authenticate to change it.
<wasabi> Which I thought was required because it was a system setting.
<Chipzz> twb: launchpad just does not provide you with the possibility of putting date-based deb lines in your sources.list
<Chipzz> you download files manually
<Chipzz> alex-weej: the out-of-date mirror will be used for downloading packages that are available there; the other mirror will be used for the packages which are not
<slangasek> wasabi: /etc/localtime is the relevant file, which is copied from /usr/share/zoneinfo; /etc/timezone is at most a hint about which file to copy
<wasabi> /etc/localtime is a symlink to America/Chicago
<wasabi> So, that's right.
<wasabi> So something is resetting it somewhere.
<wasabi> first suspicion is dhclient
<slangasek> mine is gnome-panel
<slangasek> because I've seen how special the new gnome-panel's timezone handling is :P
<wasabi> Heh.
<seb128> there is not real reason it should trigger a timezone change if you don't use it though
<wasabi> Does it consult /etc/timezone at all?
<seb128> to be sure you can remove it from the panel and reboot and look if that's still happening
<slangasek> no, it doesn't consult /etc/timezone
<wasabi> I wonder if it's not finding a match for what's in /etc/timezone, and so setting it to the default.
<wasabi> k
<slangasek> it consults getenv("TZ"), or it looks at your list of configured locations
<slangasek> /etc/timezone is used by tzdata to store information about what zone to copy to /etc/localtime
<slangasek> I don't think it's used for anything else
<seb128> slangasek: it does
<seb128> tz.c tz_get_system_timezone()
<seb128>   etc_timezone = g_fopen ("/etc/timezone", "r");
<slangasek> oh, so it does, sorry
<wasabi> Hmm. So when a program cares about the timezone, it reads /etc/localtime?
<seb128> the code is really confusing
<slangasek> wasabi: what does gconftool -g /apps/panel/applets/clock_screen0/prefs/cities give you for the timezone value?
<seb128> it has all sort of different cases
<wasabi> [<location name="Dallas" timezone="America/Monterrey" latitude="32.896946" longitude="-97.021942" code="KDFW" current="true"/>]
<wasabi> Haha
<slangasek> the comment says "This tries to get the system timezone from: + TZ environment variable + OS specific stuff + /etc/timezone + /etc/localtime"
<wasabi> I am actually in Dallas. But US/Dallas i not an option.
<wasabi> Where else would Dallas be stored?
<slangasek> wasabi: right; that's to be expected, worldclock's TZ autodetection is off its rocker
<wasabi> Oh I seeeeee.
<slangasek> it looks for the city with a timezone named after it which is geographically closest to you
<wasabi> It's set in Locations.
<wasabi> Which is not realated to the timezone cpanel.
<wasabi> or something.
<wasabi> This is all stupid. I miss US/Central.
<Nafallo> ehrm
 * Nafallo hides
<slangasek> replacing this with a useful city->TZ database is impractical in the near term
 * Nafallo curses cpanel a bit more and then hides again
<wasabi> I'd prefer a plain TZ selection, until such a point where we have a useful database.
<slangasek> so I think we'd be better off fixing the clock to, by default, only prompt you for a timezone and not a city
<wasabi> At least offer the user a choice he can make properly.
<slangasek> yes, exactly
<wasabi> You can't offer him an unanswerable question. That just sucks.
<wasabi> Evolution was the first app I noticed with this method... I hated it then.
<wasabi> I don't even remember adding Dallas to this list.
<wasabi> And also that the option is in two places is sort of bad. =)
<seb128> wasabi: is that the wrong timezone, like wrong hour?
<wasabi> Monterry is wrong.
<wasabi> Dallas should be... Chicago.
<seb128> wasabi: wrong time or just not the nearest?
<wasabi> Oh I see.
<wasabi> It's an hour off.
<seb128> ah, that is not good
<wasabi> This 10 page timezone menu is a bit unwieldy.
<seb128> ?
<wasabi> To change the timezone. I have to scroll for ages. =)
<wasabi> It's a drop down with every possible timezone in it.
<seb128> ah
<seb128> right
<wasabi> I don't understand this. There's this database of Cities... which maps me to America/Monterrey... which is also a database of cities.
<wasabi> As far as I can tell.
<seb128> what do you mean?
<slangasek> seb128: wrong DST rule
<slangasek> also wrong country
<wasabi> Why would Dallas map to America/Monterry and not US/Central
<wasabi> Why is this American/Monterry thing even an issue?
<seb128> wasabi: the code to select a timezone for a town seems to be buggy
<seb128> but I didn't look at this one yet
<slangasek> wasabi: as I said, the algorithm it uses is one of geographical proximity
<wasabi> Yeah, what I mean is why are timezones represented as cities?
<wasabi> Hmm.
<seb128> wasabi: they are not
<wasabi> Even if asked to manually select a timezone, why are my options America/Chicago and not US/Central.
<seb128> wasabi: it just tries to be helpful and set a timezone near of your city
<slangasek> which is singularly unhelpful
<slangasek> because the values of "near" are huge
<seb128> right, this dialog is really ugly
<wasabi> I guess maybe my question is not understood. Dallas is in the city list when I hit "Find..."
<seb128> wasabi: that's the list of weather stations
<slangasek> wasabi: that database doesn't include timezone information; it does include lat/lon coordinates
<wasabi> oh.
<seb128> you pick a town which has a weather station
<seb128> and he gives you a timezone for free
<slangasek> wasabi: so what this clever applet does is find the nearest city with a timezone named after it
<seb128> you can change that if you don't agree
<wasabi> Oh. Okay.
<seb128> but since it's wrong I think it should pick nothing
<wasabi> Okay, let me once again rephrase my question. I live in the US. I know my timezone as "Central"
<wasabi> It's what the TV stations say. "4 PM CST"
<wasabi> I know Pacific and Eastern and Mountain.
<wasabi> Why are my options that of cities?
<seb128> what cities?
<wasabi> Chicago.
<seb128> the first choice is a town for weather
<seb128> the second combo is a timezone
<wasabi> And teh second is a list of cities ALSO
<seb128> no
<seb128> it's a list of timezone
<seb128> I think the second one is what tzdata lists
<seb128> which is what we usually have in other GNOME applications
<wasabi> I recognize what you are telling me technically, but it's wrong.
<slangasek> wasabi: because for whatever reason, that's how the timezones are named in glibc: America/Los_Angeles, America/Boise, America/Chicago, America/New_York, ...
<wasabi> Yes, it's a list of tzdata. But it's a completely useless list.
<wasabi> I need to see a list offering choices of Central, Eastern, Pacific and MOuntain.
<seb128> it's not
<wasabi> Not cities I may or may not know are close or in the same timezone as myself.
<slangasek> seb128: he's right that most users don't associate their time zones with city names
<seb128> america is likely different from europe
<slangasek> perhaps
<seb128> we don't have weird names for timezones
<wasabi> If I went around the office right now, and asked people what timezone chicago was in, most would not know.
<tritium> It's not useless, but it isn't preferable.
<wasabi> Simple as that.
<seb128> wasabi: well, that's not new issue
<tritium> seb128: and we don't associate our times zones with other cities that we don't live in
<seb128> wasabi: evolution and gst have similar timezone lists since warty
<wasabi> seb128: I *used* to select my timezone in tzdata and had options such as US/Central.
<wasabi> Which is still reflected in my /etc/timezone file.
<ScottK2> slangasek: I'd like to upload an update to tasksel to fix a missed a spot in the mail-server task.  Since we're so close to the freeze, I thought I'd check with you.  It's the last debdiff listed in Bug #164837
<ubotu> Launchpad bug 164837 in dovecot "Dovecot SASL for postfix" [Low,In progress] https://launchpad.net/bugs/164837
<wasabi> What happened to US/Central?
<mjg59> Yeah, tzdata includes the US timezones as US timezones
<mjg59> But the UI isn't presenting that
<slangasek> right
<slangasek> and if it did, given the UI, it'd take an hour to scroll to them :-P
<wasabi> seb128: ANd yes, Evo has this same issue, and it is equally an issue.
<mjg59> Yeah, the UI is stab-in-the-face bad
<seb128> the new location selection UI is really ugly, I'm wondering who wrote that
<wasabi> Crap, I'd prefer a UI that let me select +6 GMT.
<infinity> Somewhere along the way, something forced my timezone to switch from "Canada/Mountain" to "America/Edmonton" too.  I assume this is all the same meta-bug.
<slangasek> ScottK2: er, wow, this is considered an appropriate way to configure tasks?
<slangasek> infinity: yep
<wasabi> Sub menus are not THAT hard in Gtk. :0
<wasabi> Or a treeview heh
<TheMuso> ScottK2: You are aware that there is an ubuntu tasksel bzr branch right?
<ScottK2> TheMuso: No
<slangasek> the one problem with doing US/Mountain and whatnot is that your configured TZ becomes less accurate in case of those cities who've historically been unable to make up their minds
<ScottK2> slangasek: I'm only personally acquainted with the postfix end of the change and for that, yes.  This is the best way to do it.
<ScottK2> slangasek: You can torture ivoks over the dovecot part if you want.
<tritium> slangasek: that's becoming a smaller set of cities as time goes on.  AZ and IN have changed recently.
<slangasek> so historical timestamps on files would suddenly become inaccurate
<slangasek> tritium: no, it becomes a *larger* set of cities because the TZ rules have more permutations over time
<wasabi> Hmm. How is it less accurate?
<infinity> slangasek: Canada/Mountain gets along a bit better than all of US/Mountain.
<slangasek> infinity: they get along to where?
<wasabi> Users in those cities are certainly aware of what their timezoen is.
<infinity> slangasek: (Canada/Mountain and America/Edmonton are likely identical)
<slangasek> infinity: sure; but everyone in Canada/Mountain knows where Edmonton is ;)
<wasabi> In fact, as I see it, attempting to hard code a database full of city->TZ mappings is what's hardest to deal with.
<infinity> slangasek: Perhaps, yes. :)
<infinity> slangasek: I still think that identifying timezones by city (except when cities are the exception to the rule) tends to be contentious, if only superficially.
<infinity> slangasek: (ie: Screw Edmonton, the Oilers suck, Wayne Gretzky was a pansy, I don't want to be in that timezone!)
<infinity> slangasek: There must be parts of the world where it's slightly more politically charged than just hockey rivalry, though. :)
<slangasek> ScottK2: well, patching another package's config file in a task postinst sets off warning bells for me.  This strikes me as a policy violation... in terms of whether it's ok to upload now I have no release-based objections, I just wonder if it's a reasonable thing to upload ever :)
<ScottK2> Right
<ScottK2> slangasek: For postfix, calling postconf is the defined tool for doing that.  Let me look at the other again.
<tritium> slangasek: I'm not suggesting you keep track of historical changes.  The present set of cities that don't follow DST is smaller than it was a year ago.
<slangasek> wasabi: it's less accurate because if you know that your timezone is "Central" because that's what the government says you are, but in reality you've been following different timezone rules than the usual CST/CDT group up until 6 months ago, listing yourself as US/Central is going to break your local timestamp reckoning for everything older than that
<mathiaz> slangasek: well - I'd risk to ask if tasksel postinst scripts are considered as maitainer scripts ?
<slangasek> tritium: you may have noticed that computers are occasionally used for keeping track of historical data...
<slangasek> mathiaz: IMHO they should be
<mathiaz> slangasek: the postinst script for a task wouldn't be allowed to modify the configuration file ?
<ScottK2> slangasek: After looking at the dovecot stuff again I tend to agree with you.  I'll hold off.
<tritium> slangasek: sure, but when configuring my time zone, I care about the present
<ScottK2> slangasek: Thanks for looking at it.
<infinity> Since when do tasks have postinsts anyway?
<wasabi> slangasek: Works on Windows.
 * wasabi ducks.
<infinity> (And does "apt-get install task^" run them?)
<slangasek> wasabi: yeah, everyone *loves* Windows TZ handling
<wasabi> Just the UI.
<mathiaz> infinity: well - that's what we choose to use tasks postinst to handle dovecot/postfix integration
<slangasek> wasabi: Windows == no monotonic clock == loss
<wasabi> What's that mean?
<mathiaz> infinity: we couldn't do it from the package postinst script
<slangasek> mathiaz: I would note that if this patch were uploaded, it would be the only task on my system that *has* a postinst script...
<mathiaz> infinity: so we've tried to use a postinst script from tasksel task
<wasabi> Oh, you mean to adjust the time by fast forwarding
<slangasek> yes
<mathiaz> slangasek: correct.
<tritium> Well, I don't live in Denver, nor do I have any association whatsoever with Denver (other than my city is also one mile above sea level), yet that is my timezone selection.  Quite annoying...
<wasabi> Well, seperate subject from the UI.
<mathiaz> slangasek: so what are the purpose of postinst task scripts ?
<wasabi> service has determined which time sample is best, based on the above criteria, it adjusts the local clock rate to allow it to converge toward the correct time. I
<slangasek> wasabi: or by stepping it back; the result either way is that you have a discontinuity across DST changes that makes log keeping a problem
<wasabi> ^ From 2000
<mathiaz> IIUC tasks are used to install a set of packages and then glue them so that they're integrated correctly.
<slangasek> mathiaz: presumably, the same as for regular package postinst scripts except when you install a task
<wasabi> Windows does in fact have whatever you just said it didn't.
<keescook> hm, where did the "removable drives" settings in "removable drives and media settings" go?
<slangasek> wasabi: er?
<mathiaz> slangasek: so what's the difference between a meta-package and a task in tasksel ?
<slangasek> mathiaz: I don't know anymore
<infinity> Doing something like this in tasksel, instead of a meta-package, strikes me as just plain wrong.
<infinity> Nevermind the wrongness of futzing with other packages' config files in the first place.
<mathiaz> infinity: well - tasksel is what is used in the installer
<infinity> "apt-get install mail-server^" won't have the same effect as installing from tasksel.
<wasabi> slangasek: Since 2k it does gradually slow down or speed up the clock to correct small differences.
<wasabi> As long as it's within 3 minutes, it says.
<slangasek> wasabi: which is either not relevant in the case of DST changes, or completely the wrong solution
<mathiaz> infinity: does apt-get understand tasks from tasksel ?
<slangasek> right - that doesn't give you correction for a 1-hour difference
<wasabi> Eh? I do not see how convergence is relative to time zones.
<wasabi> I said that when you first brought it up.
<infinity> mathiaz: Oh, is mail-server not a "real" task?  (ie: not in the seeds, not in Packages.gz?)
<mathiaz> infinity: for now it don't see the difference between a meta-package and a task in taskel
<infinity> No, it's a real task...
<slangasek> wasabi: I didn't say "convergence", I said "discontinuity"
<infinity> adconrad@ziggup:~$ apt-cache show postfix | grep ^Task
<infinity> Task: mail-server
<mathiaz> infinity: I guess I'm not fully aware of the difference between the two.
<wasabi> slangasek: I guess I don't know waht you mean. File times on NT are kept in UTC.
<wasabi> slangasek: So the DST is unrelated to all of that.
<infinity> mathiaz: apt-get just installs "all packages with a Task header matching 'task^'".
<slangasek> wasabi: well, that's an improvement over what I remember then; but isn't the BIOS clock still kept in local time?
<wasabi> slangasek: But that's been true since NT4.
<infinity> mathiaz: A metapackage would be a package that depends on a bunch of other packages, and has a postinst, preinst, etc.
<wasabi> Yes, the bios clock is still local time. That does suck
<mathiaz> infinity: gotcha. So what's the difference between a tasksel task and a meta-package ?
<infinity> mathiaz: A task could certainly point at a metapackage, but having a task have "magic" on its own that's outside the packaging system is, IMO, wrong.
<wasabi> First thing NT does is read it, convert it to current timezone, and use keep time in software (like linux)
<mathiaz> infinity: it's just that it shows up during the install ?
<infinity> mathiaz: A task is a group of packages.  A metapackage is a package that depends on packages.
<slangasek> mathiaz: historically, the difference between tasks and metapackages was "recommends"
<slangasek> well, that's true even today on Ubuntu
<wasabi> Uh huh.
<wasabi> This is all NT stuff. 9x was all screwed up, which everybody admits.
<wasabi> But that was a long time ago now.
<infinity> slangasek: I could be way out of touch, having not ever wanted to even look at tasksel, but any task that can't be reproduced with "apt-get install <package, package, package>" or "apt-get install task^" seems broken to me.
<wasabi> Do we have any source of data defining regions of the earth that are under a timezone? Not cities, but lat/lon regions.
<mathiaz> infinity: well - then what is the purpose of tasksel ?
<wasabi> Combining that with the weather database which has lat/long seems more reasonable.
<infinity> slangasek: To be honest, I'd prefer to see something like this in a "postfix-sasl-integration" package, which could then be part of the mail-server task.
<infinity> mathiaz: The purpose of tasksel is to select tasks? :)
<infinity> mathiaz: (It also used to be the canonical list of tasks, before we had a Task: header in Packages.gz)
<slangasek> infinity: tasks can have "optional" packages that are installed by default if available; metapackages cannot, without recommends-by-default
<infinity> slangasek: Yeah, there's that too.  That line's blurry in Ubuntu.
<mathiaz> slangasek: isn't recommends-by-default the default for hardy ?
<infinity> slangasek: Either way, a task having a postinst (rather than depending on a package with a postinst) feels broken.
<slangasek> wasabi: no; nor do we have code in gnome-panel that lets us calculate whether a given lat/lon pair is within a bounded region... :)
<slangasek> mathiaz: I thought we still didn't have recommends-by-default in hardy
<infinity> mathiaz: A more practical example of this breakage is that if we set a precedent here, someone may decide to (god forbid) add a tasksel postinst to "ubuntu-desktop"...
<slangasek> mathiaz: not in apt-get, that is
<infinity> mathiaz: ubuntu-desktop, on the livecds (and, hence, the installer), is installed with apt-get, not tasksel.
<infinity> mathiaz: So, alternate installs would differ from livecd installs.
<mathiaz> slangasek: but aptitude does it, right ?
<seb128_> wasabi: I think the easiest thing to do for hardy is either to let the code like this or to not select a timezone when picking a city
<slangasek> mathiaz: yes, aptitude has for quite some time; but aptitude is not the default package management tool in Ubuntu
<slangasek> seb128_: I believe the latter is the correct course of action
<seb128_> wasabi: but not picking a timezone mean every user has to go through this ugly list to select one
<mathiaz> slangasek: agreed - just trying to understand this whole thing.
<wasabi> seb128, a real issue is that there are two places to configure this independently, one which overrides the other. The Date & Time cpanel lets you chagne timezone.
<wasabi> But then the gnome-panel thing resets it.
<seb128_> slangasek: I would agree if the timezone selection widget was easier to use
<wasabi> That's probably required to fix for release
<seb128_> wasabi: yes, that's a bug
<slangasek> wasabi: I don't see a "Date & Time" selector anywhere here, is that installed by default?
<wasabi> Eh. Time and date
<infinity> mathiaz: Anyhow, the whole discussion (and me wondering why tasksel even ALLOWS this) are perhaps windy and off-topic.
<seb128_> slangasek: system, administration
<slangasek> another bug is that you pick a timezone in the installer, but gnome-panel doesn't see this
<wasabi> Can't this crap just be knocked out of Gnome-panel?
<slangasek> seb128_: right, I didn't think to look under "T" :-)
<wasabi> Until somebody does it right?
<infinity> mathiaz: But I still think the "better" way to do this is to have a "postfix-sasl-integration" package that does what you want it to do, and add that package to the "mail-server" task.
<seb128_> what is standard timezone location, not speaking about GNOME
<slangasek> wasabi: it was done right, then they replaced it with the worldclock ;)
<seb128_> rather the system one
<infinity> mathiaz: That way, people using apt-get can have it work the same way, people who already have half the packages installed can just grab the integration package, etc.
<wasabi> seb128 /etc/timezone seems to be used by tzdata, which also has it stored in debconf
<seb128_> is that just a matter to write to timezone rather than localtime?
<slangasek> seb128_: hrm, but as usual GNOME seems to believe it is the system ;) - if you choose a different location in the panel, the system timezone changes
<seb128_> in which case we should update the panel code to prefer timezone over localtime
 * lamont wonders if he wants to be involved in the postfix discussion
<wasabi> No, /etc/timezone is the NAME of the time.  Just state. /etc/localtime is a symlink to the tzdata information in /usr/share/tz/data/$(cat /etc/timezone)
<wasabi> apparently.
<seb128_> that applet really didn't land the best way
<infinity> lamont: Not when you see the diff involved, you don't.
<seb128_> that was a change suse had
<seb128_> redhat did work on something similar
<slangasek> on most systems, /etc/localtime is a copy of the tzdata, not a symlink
<lamont> infinity: heh
<wasabi> Oh. My system has it as a symlink.
<seb128_> and upstream decided to just land the change in a hurry rather than having random distro adding different patches to do that
<wasabi> Oh. Heh. I just reconfigured tzdata and it replaced it.
<wasabi> Go figure.
<slangasek> right :)
<slangasek> wasabi: "copy" because if /usr isn't available at boot, you can't get the timezone
<slangasek> and fsck goes wobbly
<tritium> I'd just prefer to choose an actual timezone, e.g. US/Mountain, not a city in another state.  Cities are not timezones.
<slangasek> so, then you keep /etc/timezone around so you can figure out the name of the currently-configured system timezone without having to walk all of /usr/share/zoneinfo and hope you find a current match
<wasabi> Hee hee.
<seb128_> tritium: you don't select a city as timezone
<wasabi> tritium: Apparently everywhere other than the US that is the case.
<tritium> seb128_: yes, I select America/Denver, even though it's 6 hours away.
<wasabi> Think this is a language barrier. In the US we do not refer to our timezones by city name.
<wasabi> Europe seems to.
<tritium> Perhaps.
<seb128_> how many timezone do you have? 8?
<wasabi> Maybe that's why they say stuff like "Paris time"
<seb128_> you have a name to remember for every of those?
<slangasek> seb128_: you pick a timezone that's named for a city, which is the same thing for those of us in countries who don't normally label our timezones that way
<tritium> seb128_: more like 4
<wasabi> seb128, most people don't leave their own.
<slangasek> US/Central, US/Pacific, US/Mountain, US/Hawaii, US/Eastern, US/Alaska, ...
<wasabi> But yes, 8.
<wasabi> Samoa, Hawaii
<seb128_> that's complicated ;-)
<wasabi> Atlantic
<slangasek> US/Arizona
<seb128_> I like the european way better
<slangasek> Atlantic isn't a US timezone, it's a Canadian one
<seb128_> you go to england you select the london timezone
<wasabi> Wait, let me see what Windows lists!
<slangasek> seb128_: if you go to Spain, which timezone do you choose?
<seb128_> madrid
<wasabi> Yeah. So that's it.
<slangasek> are you sure? :)
<wasabi> Windows lists the european timezones by city name.
<seb128_> or barcelona
<slangasek> the Canary Islands are part of Spain
<wasabi> But hte US ones are listed by US name.
<seb128_> any spain town will do
<slangasek> and aren't in the same timezone
<seb128_> slangasek: they are in the list
<wasabi> Pacific Time (US & Canada); Tijuana
<Ng> could the map that shows timezones not actually show the timezones, like on normal maps that show timezones? :)
<seb128_> slangasek: I pick the nearest city in the country
<wasabi> seb128 what if that crosses tz borders?
<Ng> (also, is the map zooming in the alpha6 installer going to stay?)
<slangasek> seb128_: but when you're in spain and you ask them what timezone you're in, I don't think they're going to tell you "Madrid", so how do you know where the border is between the timezones unless you know the other name for the zone?
<slangasek> (ok, Atlantic/Canary might be obvious enough...)
<ion_> wasabi: How about taking a single look at a local clock? :-P
<slangasek> some of us like to know the time before we land ;-)
<wasabi> GMT +01 (Brussels, Copenhagen, Madrid, Paris)
<Ng> wrt the panel locations thing, I object to using the Find thing to drill down to europe, UK, London, City Airport when the whole country is a single timezone. show me a map with the timezones :)
<seb128_> slangasek: not sure to understand the question, ask said I go to uk I use london, continental spain madrid, canary canary, etc
<seb128_> slangasek: we usually have 1 timezone by country
<slangasek> Ng: yes, that's the other thing - you're really picking a weather zone and getting the TZ autopopulated, when the opposite would be more useful by default :)
<wasabi> http://www.time.gov/
<tritium> seb128_: that's great for smaller countries, geographically
<seb128_> canary is not spain
<slangasek> seb128_: huh?  The Canary Islands are Spain
<seb128_> slangasek: right, but that's like saying that reunion is france
<slangasek> seb128_: Russia is another example, though
<slangasek> erm
<seb128_> those are french island but they are no near
<seb128_> and I'll not expect those to be on continental time
<slangasek> Las Canarias are only 1 hour offset from Madrid, IIRC
<Ng> slangasek: indeed. being able to select a city isn't the worst thing in the world if you use it to track the time of the people you converse with, but at least the system timezone and the installer timezone should just let you click on the bands of one of these: http://members.shaw.ca/emg.pbm/timezone.gif
<seb128_> well, wouldn't work much better with a system like the us one
<theunixgeek> What do you think of gtkmm over GTK+? (C++ GTK vs C GTK)
<wasabi> oh hey
<Ng> but anyway, I have more urgent things to try and get fixed :)
<seb128_> right, that going off track
<tritium> Ng: that would be nice.
<ion_> ng: Agreed.
<seb128_> let's not try to solve how countries use timezone
<seb128_> and see what we can do which is not too intrusive for hardy
<slangasek> :-)
<slangasek> step one would probably be to get a saner timezone selector instead of the single pull-down list
<seb128_> right
<seb128_> logical choice would be a map
<tritium> seb128_: we're not solving how countries use timezones.  But we are pointing out that the chooser forces ways that countries do _not_ use timezones.
<seb128_> like ubiquite, evolution, gst are using
<slangasek> sure.  then if that's done, we can flip the location/timezone choices
<slangasek> so that you choose a timezone first, and optionally a location after
<seb128_> tritium: it does not
<seb128_> tritium: there is just a bug which is that the interface doesn't list the US timezones
<tritium> seb128_: yes, the US does _not_ use city names for timezones, e.g. America/Denver.  It uses US/Mountain.
<seb128_> it should list what is has now, and US*
<seb128_> tritium: that's just a bug, not a design issue
<tritium> okay, seb128_
<wasabi> Depends on your definition of bug. =)
<slangasek> seb128_: what about Brazil, Canada, Chile, Mexico?  These each have directories in /usr/share/zoneinfo but aren't in the selector
<mathiaz> infinity: slangasek: thanks for your explanation on the tasksel stuff.
<slangasek> mathiaz: sure
<mathiaz> infinity: slangasek: so now the question is: what are the other option to automate the integration of dovecot and postfix ?
<ScottK2> mathiaz: I didn't see anything in the dovecot patch that was obviously wrong for the default config provided by dovecot.
<mathiaz> ScottK2: so we could shipp a default dovecot file that provides the necessary bits for postfix integration ?
<seb128_> slangasek: I officially hate this configuration dialog
<slangasek> seb128_: what's tricky about this is that, for some time now, I believe we've been using the America/Los_Angeles [...] zones as the authoritative choices for time zones in Debian/Ubuntu; but we've never made users have to pick a city name before
<slangasek> seb128_: I'm glad we're on the same page ;)
<mathiaz> ScottK2: so whenever dovecot is installed it would provide a socket in /var/spool/postfix/private/auth even if postfix is not installed ?
<seb128_> slangasek: one thing we could do is to make the applet not set timezone for one thing
<seb128_> slangasek: and keep using the dialog we had before
<seb128_> slangasek: I think it's nice to be able to list different location there and the local time and weather
<seb128_> but we can still use the admin tool for configuration the zone to use
<slangasek> seb128_: I'm not sure I understand you; are you saying that if there's only one location configured, don't change the timezone?
<slangasek> that seems like a workaround to me
<seb128_> no
<seb128_> but the applet will have no timezone by default in the list
<seb128_> you can add some
<seb128_> you will get the time and weather for those
<seb128_> which is nice and informative
<slangasek> how do you get the time for it if you don't set a timezone?
<slangasek> remember, part of the problem is that cities close together have different timezones
<seb128_> well, that's still an issue
<seb128_> I'm trying to solve the "don't mix with the system timezone config" first
<seb128_> which is the important one
<slangasek> well
<seb128_> then we can deal with the UI issue for adding extra timezones
<slangasek> I wouldn't mind it messing with the system timezone, if it did it *right* :)
<ScottK2> mathiaz: Since postfix is our default/standard MTA, I don't see a problem with configuring other programs to work with it by default.
<slangasek> i.e., was able to correctly pull the timezone configured at install time as an initial default location; don't guess at timezone based on distance
<slangasek> ScottK2: +1
<mathiaz> ScottK2: right.
<mathiaz> But to make things clear, calling postconf from a maintainer script isn't against the policy ?
<ScottK2> mathiaz: I certainly don't think so.  That's what it's for.  I don't recall the policy reference exactly, but IIRC that's how it says to do it.
<slangasek> postconf is a package-provided interface; so as long as it doesn't get called in ways that will *repeatedly* stomp on the local config...
<ScottK2> mathiaz: ^^^ Which is why I was against using it in an init script.
<mathiaz> ScottK2: right - but what about calling postconf on every package upgrade ?
<slangasek> that would be bad
<slangasek> :)
<slangasek> because it means a user who disagreed with one of your settings could never override it without uninstalling that package
<mathiaz> hum - actually we don't need to call on each upgrade - just on install
<slangasek> right
 * slangasek tries to understand why a bug requesting a freeze exception for inkscape gets marked as applying to Baltix
<ScottK2> slangasek: I often wonder the same thing about Ubuntu Backports bugs.
<slangasek> pitti: btw, would you mind doing the FFe request for samba?  I think it might be better to have someone other than me doing it
<mathiaz> ScottK2: so what about this: modify the default dovecot configuration file to export its sasl socket to /var/spool/postfix/private/auth, create a new package that depends on postfix and dovecot and call the postconf commands to setup postfix to run with sasl from the postinst script ?
<slangasek> ScottK2: I can at least see in theory how a backport bug might apply to more than one distribution
<ScottK2> slangasek: I suppose, but it's the "Ubuntu Backports" project.  Even if they want the same package, it's off topic for the bug.
<lamont> slangasek: because the baltix guys like to mark everything as applying to them?  dunno
<lamont> that's because the backport bug is a task, not a bug.
<ScottK2> mathiaz: And then mail-server tasksel can install that?
<mathiaz> ScottK2: yes - we'd add the new package to the mail-server task
<ScottK2> lamont: It is a bug against a separate project
<ScottK2> mathiaz: Sounds much saner than what we have now.
<slangasek> ScottK2: well, bugs can apply to more than one project, that's how we mark upstream tasks ttoo..
<ScottK2> I'd run it by slangasek
<mathiaz> ScottK2: now I wonder if we could add the postconf call in dovecot postinst script
<ScottK2> mathiaz: I'd say not.  Not all those things are specific to dovecot integration.
<mathiaz> ScottK2: right - actually it's just postfix specific
<mathiaz> ScottK2: it's just a package that configures postfix to run with sasl
<ScottK2> mathiaz: Yes.
<slangasek> ScottK2: sounds fine to me
<mathiaz> ScottK2: slangasek: great ! I'll update the bug with the proposal
<lamont> slangasek: what (if anything) do you need before you can sync bind9 from sid (bug 200739)
<ubotu> Launchpad bug 200739 in bind9 "bind9 apparmor profile is named apparmor-profile" [Undecided,Fix committed] https://launchpad.net/bugs/200739
<slangasek> lamont: a time transplant
<lamont> meh
<lamont> because of freeze, or something else?
<slangasek> lamont: because the worldclock stole my time and sold it to Monterrey
<lamont> heh
<slangasek> lamont: seriously, it's on my list; I don't think I'm missing any info for it, I just need to get to it
<lamont> no worries
<lamont> I just wanted to make sure it was on the list.
 * Hobbsee adds a bug to the beta list, and knocks one out.  yay!
<lamont> and not blocked on something stupid from me.
<lamont> Hobbsee: bad to play with overflow like that
<Hobbsee> heh
<slangasek> lamont: oh - actually, that wasn't an FFe, which means it's really on the list of whoever's on archive duty today ;)
<keescook> mjg59: did you push a branch with the usplash/libdisasm goo somewhere?
<slangasek> bryce, keescook: hnngh, who puts a changelog in *alphabetical* order?
<Hobbsee> slangasek: |sort does?  :0
<slangasek> inkscape == sort, gotcha
<keescook> slangasek: something that auto-extracts from a svn log?
<Hobbsee> slangasek: should i just chuck a blanket "no" on anything filed 24h bfeore beta?
<slangasek> Hobbsee: heh, your prerogative to do so if you'd like to
<Hobbsee> slangasek: gnumeric would be nice though, having seen the last one
<Hobbsee> slangasek: (i've no idea if you want me doing u-release bugs)
<slangasek> Hobbsee: also your prerogative if you'd like to, I won't turn away the help :)
<Hobbsee> slangasek: heh :)
<Hobbsee> slangasek: i still have the mighty powers.  haven't wanted to risk them being taken away though
<slangasek> Hobbsee: in fact, you're welcome to review samba, which I'm recusing myself on
<Hobbsee> ew
 * Hobbsee pukes
<Hobbsee> Nexuiz is packaged a little "strangely." There's no source package, per se, but there are source zip files contained in the binary release.
<Hobbsee> wth?
<keescook> niiice
<keescook> Hobbsee: is that new?  I swear I compiled something when I was playing with nexuiz and the hardening options (benchmarks)
<Hobbsee> ScottK2: any objections to putting a blanket "no" on most of the release stuff?
<Hobbsee> keescook: i've no idea.  i'm just going thru the quuee
<keescook> Hobbsee: the only thing in the queue I'd really like to see get through is setools
<ScottK2> Hobbsee: For universe we still have a fair amount of time.  I think we should still look at them.
<Hobbsee> ScottK2: a lot of them require archive admin stuff
<TheMuso> ScottK2: I agree.
<Hobbsee> keescook: main or universe?
<ScottK2> Hobbsee: For New packages I agree.
<ScottK2> For sync's I think it's no so bad.  If you're worried about that we can just have motu-release use syncpackage.py
<Hobbsee> ScottK2: just ones which create new binaries, etc.
<ScottK2> OK
<ScottK2> Those I'd look very hard at.
<keescook> Hobbsee: universe (for main, I'm hoping to get inkscape through)
<Hobbsee> (split into -data, etc)
 * Hobbsee keeps trying to drop the queue size
<Hobbsee> 50 down to...31!
<Hobbsee> keescook: done setools, but please do the transitional packages too
#ubuntu-devel 2008-03-13
<slangasek> Fix degenerate perspective due to collinear X and Z vanishing points and origin, which caused computing preimages of canvas points to not work.
<slangasek> Now *that's* a changelog entry
<jbf2> hi all
<slangasek> jbf2: hello
<Hobbsee> haha
<jbf2> I got a bug assigned to me some time ago, and I just made a fix, now the big question is, do I change the "status" field in launchpad? :)
 * Hobbsee wants launchpad to start sorting in random order, to show which ones she should look at
<slangasek> jbf2: when you say you "made" a fix, what do you mean - it's fixed upstream, it's committed to a package VCS repository, it's uploaded?
<jbf2> slangasek: the package (drscheme) is almost orphaned in debian, but a recent rebase (can I say that? :) in upstream made some init-scrips break/defunct, so I uploaded a debdiff to launchpad ... last time I did that someone assigned the bug to me .. :)
<slangasek> "almost" orphaned, eh?
<slangasek> I thought it's been orphaned at the end of every semester for the past 5 years...
<jbf2> hehe
<slangasek> well, so - if there's a diff uploaded to launchpad, the next step would be to subscribe ubuntu-universe-sponsors and mark the bug as *not* assigned to you
<keescook> Hobbsee: thanks.  I'll ping them, they mentioned today they had finished the transitional packages.
<Hobbsee> keescook: cool
<jbf2> slangasek: asign to whom? ubuntu-universe-sponsors?
<Hobbsee> jbf2: subscribe them.  see https://wiki.ubuntu.com/MOTU/Contributing
<jbf2> Hobbsee: thx
<slangasek> keescook: inkscape acked, go, go!
<Hobbsee> hehe :)
 * Hobbsee gives slangasek more work
 * slangasek deftly dodges the approaching work
<Hobbsee> you can't.  it's on your queue, and you don't want me doing it.
<slangasek> where's your queue, so I can negate both halves of that sentence at once? :)
<Hobbsee> slangasek: wlel, technically i'm still aprt of -archive.
<keescook> slangasek: woot!  thank you muchly, sir!
<Hobbsee> slangasek: so you *could* say i'ts my queue too.
<slangasek> that's the spirit!
<Hobbsee> slangasek: but you're paid for this.  i'm not.
<Hobbsee> and i have uni stuff to do.
<slangasek> well, there is that
<Hobbsee> of course, if you *want* to do all my uni work, then i'll sync. but i'd need drescher access first :P
<slangasek> heh
<Hobbsee> and another bug to you.
<jbf2> slangasek, Hobbsee: thanks for the hand-holding
<jbf2> bye
<TheMuso> asac: So far so good for network manager with ipw2100.
<asac> TheMuso: wpa?
<asac> TheMuso: or no encryption?
<TheMuso> asac: WPA2.
<asac> ok thanks
<TheMuso> np
<asac> TheMuso: can you test wep?
<TheMuso> asac: Yep, give me 5.
<TheMuso> asac: hrm ok it was WPA. I'll try WEP, and then try WPA2.
<TheMuso> asac: Ok wep is good, only 64-bit atm, but I assume higher bitrates would also be ok. Can check if you like, now will do WPA2.
<Hobbsee> doko: would it be a silly question if i asked why icedtea-java7-doc was effectively empty?
<doko> Hobbsee: bug
<doko> openjdk-6-doc is not empty
<Hobbsee> doko: any ETA on it beign fixed?
<doko> ^^
<TheMuso> asac: Ok WPA2 is also good.
<asac> TheMuso: thanks. that should be enough
<TheMuso> np
<protonchris> Any ubuntu main sponsors around?
 * TheMuso sighs with satisfactino after working with an upstrea author to fix a bug found by stack smashing. :)
<TheMuso> gah satisfaction
<protonchris> LaserJock: Are you up for taking a look at a sync request and sponsoring it?
<LaserJock> what's the app?
<protonchris> https://bugs.launchpad.net/ubuntu/+source/libgda3/+bug/200292
<ubotu> Launchpad bug 200292 in libgda3 "Sync libgda3_3.0.2-2 from debian unstable" [Undecided,Confirmed]
<ScottK2> For a moment a read that as libyada and shuddered.
<StevenK> Haha
<protonchris> I haven't been forced to use yada ..... yet
<protonchris> In general, how long does it take from an upload be available from the repositories?
<StevenK> A few hours
<protonchris> Hmm.  I had a package uploaded/sponsored 22 hours ago and I haven't seen it available on us.archive.ubuntu.com yet.
<StevenK> It could be in NEW or so. What package/version?
<protonchris> 2.9.82-0ubuntu1
<protonchris> whoops.
<protonchris> libgdamm3.0_2.9.82-0ubuntu1
<protonchris> That is the source package.
<StevenK>  hardy i386   Successfully built  (NEW)
<StevenK> It's in binary NEW, so you have to wait for the archive admins to review it and approve it
<protonchris> Ah.  Good to know.
<protonchris> Thanks.
<Frederick> folks which package is supposed to hold libmawt?
<protonchris> Frederick: sun-java6-bin holds libmawt.so
<Frederick> protonchris: thanks but I humbly think it doesnt :p
<Frederick> my netbeans crashes Ive tried the fix but seems I dont have such lib
<protonchris> Frederick: well, maybe that file is provided by more that one package :)
<LaserJock> looks like iced-tea or the sun-java's have it
<Hobbsee> ScottK2: you're evil.  now someone should package libyada.
<ScottK2> Hobbsee: What would it do?
<Hobbsee> ScottK2: rm -rf / in the postinst.
<Hobbsee> with the appropriate force optoins.
<ScottK2> Sounds about right.
<ionstorm> latest hardy with latest libc update borked my system, I cannot boot nor chroot in, how can I chroot in?
<RAOF> ionstorm: Since libc's borked you probably can't chroot in (because it'll be using the chroot's libc, which is borked).
<RAOF> ionstorm: Option 2 might simply be to copy a known-good libc.so.whatever from your livecd to your real filesystem.  The nice thing is, it's really, really hard to break it more than it already is ;)
<Amaranth> RAOF: so don't upgrade libc6 then? ;)
<_MMA_> After spending the day on a clean install of Hardy, and just getting that update that ^^^ wasn't good to hear.
<RAOF> Amaranth: Given that people have been kind enough to guinnie pig this for me, I'll be aptitude forbid-version'ing this libc tootsweet.
<protonchris> LaserJock: I am going to step away for a bit.  Let me know if there is anything I need to do regarding my sync request.  Thanks.
<LaserJock> protonchris: just ack'd it
<protonchris> LaserJock: do I need to do anything other than wait?
<LaserJock> nope, should be all good
<protonchris> LaserJock: one last question. Do I need to do anything for my other package that is sitting in binary NEW?
<LaserJock> nope
<LaserJock> if it's in NEW it in the archive admins hands
<protonchris> Thanks for all of your help
<LaserJock> you might gently poke if it's nobody looks at it for a few days
<LaserJock> s/it's//
<protonchris> Thanks for the advice.  I am sure they are quite busy.
<milli> Everything just blew up with latest package updates. :(   bug 201694.
<ubotu> Launchpad bug 201694 in ubuntu "System crashed on the from the lastest update." [Undecided,New] https://launchpad.net/bugs/201694
<RAOF> milli: #ubuntu+1 has links in the topic about what to do about your broken libc
<StevenK> RAOF: Send scathing e-mail to ubuntu-devel-discuss?
<RAOF> StevenK: Nah, that's already been done.  It'd just seem lame now :P
<StevenK> Heh
<milli> RAOF: ty
<Mithrandir> StevenK: have you seen that bug?
<Mithrandir> if it's correct, we should call elmo and get the update blocked.
<Mithrandir> I'd rather not update my system and discover it blows up. :-P
<superm1> Mithrandir, i saw it and so did minghua
<superm1> and my system is going to blow up as soon as I reboot :)
<RAOF> The magical incantation _should_ be "sudo aptitude forbid-version libc6=2.7-9ubuntu1" ;)
<StevenK> Mithrandir: I've seen the bug in a new Hardy chroot
<minghua> Mithrandir: Yes, I saw it.  It would be nice if the update can be blocked.
<StevenK> Mithrandir: slangasek has also reproduced
<Mithrandir> StevenK: do you want to wake elmo or should I?
<Mithrandir> as for it seeming mean, he's asked us to do that when shit like this happens.
<StevenK> Mithrandir: Go ahead
<Mithrandir> ok, blocked in the DC.
<minghua> Mithrandir: Thanks!  And thanks to elmo too, I assume.
<compbrain> minghua: The update is blocked, afaict
<compbrain> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-i386_2.7-9ubuntu1_amd64.deb  403 Forbidden [IP: 91.189.88.45 80]
<dholbach> good morning
<emgent> hyea :)
<pitti> Good morning
<seb128> hey hey pitti
<emgent> heya pitti :)
<Fujitsu> Hi pitti.
<abogani> Hi Guys! I have just update my Hardy machine. All variants of the sudo commands (sudo -i, sudo -s , sudo command) abort with backtrace. It isn't possible use apt-get or simply reboot!
<pitti> slangasek: samba FFe> sure, will look at it
<Fujitsu> abogani: See #ubuntu+1.
<Fujitsu> libc6 is broken.
<Fujitsu> There is a link to a solution in there.
<abogani> Fujitsu: Fiuuuu. Thanks for tip! Excuse for disturb! :-)
<dholbach> we should add https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/201673 to the topic too
<ubotu> Launchpad bug 201673 in glibc "Hardy: "invalid pointer: 0xb7ef4b70" no program will start." [Critical,Confirmed]
<Fujitsu> dholbach: There's no +t here.
<dholbach> hrm... chanserv won't give me op - can't fix it
<soren> Funny... I was soooo close to convincing my wife to upgrade to hardy yesterday.
<soren> dholbach: You can just change it, can't you?
* dholbach changed the topic of #ubuntu-devel to: Archive: Feature freeze | 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 | glib broken: https://launchpad.net/bugs/
<Mithrandir> glibc, you mean?
<dholbach> nghghghg, I knew it :)
<seb128> oh glibc borkage
<ln-> what releases are affected?
<Mithrandir> hardy
<seb128> thanks to whoever blocked the deb on the server
<seb128> I would have updated otherwise
* dholbach changed the topic of #ubuntu-devel to: Archive: Feature freeze | Development of Ubuntu (no support, not
<dholbach> gra
<Mithrandir> seb128: his name is elmo and his uid is 0.
<pitti> ah, I just wondered about the Forbidden: messages from apt
<seb128> Mithrandir: ;-)
<dholbach> can somebody fix the topic? somehow xchat-gnome does not like it
<pitti> looking
<dholbach> Archive: Feature freeze | 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 | glibc broken: https://launchpad.net/bugs/201673
<ubotu> Launchpad bug 201673 in glibc "Hardy: "invalid pointer: 0xb7ef4b70" no program will start." [Critical,Confirmed]
<dholbach> something like that
<pitti> ok, you beat me to it
* emgent changed the topic of #ubuntu-devel to: Archive: Feature freeze | 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 | glibc broken: https://launchpad.net/bugs/201673
<dholbach> gracias
<emgent> np :)
<dholbach> xchat-gnome got a bit confused it seems - freenode gave me " application :Unknown command"
<pitti> seb128: ah, libgnomeui is happy now, I'll do another give-back round if you don't mind?
<seb128> pitti: sure
<pitti> seb128: ok, give-back-from-hell started; there will likely be more fallouts, I'll just kick it again once this round built; sorry for the mail spam, but it's easiest that way IMHO
 * pitti cleans up NBS too, that should make hardy_outdate.txt shorter
<seb128> pitti: no problem, mails are easy to filter
<pitti> seb128: I'd say, just delete all of the gnome FTBFS mails you got
<pitti> seb128: we'll see them in outdate
<seb128> alright
<pitti> after a few rounds of give-back we'll see what's left
<soren> slangasek: We should probably put up some semi-official instructions of how to recover.
<seb128> pitti: any language pack update planned before beta?
<seb128> pitti: now than GNOME 2.22 is in hardy we should update translations
<pitti> seb128: they are automatically updated on Wednesdays and Sundays
<pitti> seb128: so yesterday's should already have some bits
<seb128> ok
<pitti> seb128: the one from Sunday will be appropriate, I think?
<seb128> should be yes
<pitti> I create them two hours after LP exports them, so I can't be much faster than the cronjob
<pitti> s/^I create/They are created/
 * pitti pats his collection of "pitti does some work" scripts everywhere
<pitti> seb128: btw, I looked at the retracers last night, seem to work now
<seb128> pitti: yes, it was working after you left
<seb128> I verified it retraced several bugs correctly
<seb128> thanks again for fixing it
 * seb128 hugs pitti
<Tonio_> hi there
<pitti> \o/
 * pitti hugs seb128
<pitti> hi Tonio_
<Tonio_> can I install a debconf response file so that installing a new package via dist-upgrade goes silent ?
<Tonio_> I know how to do that with FAI for example, but not on the desktop side
<pitti> DEBCONF_PRIORITY=critical?
<Tonio_> what will that do ?
<pitti> it will only show critical questions, not 'high' priority ones
<broonie> You can also get the relevant db_sets run prior to installing the package which will do the preseeding.
<Tonio_> hum interesting
<broonie> There's no namespace enforcement.
<ogra_cmpc> pitti, could you take a look at bug #201536 ? any chance to get that in still ? stgraber is very confident it solves a lot of issues for us and given that he works extemly close with upstream to get all ubuntu changes in i think we should take the update
<ubotu> Launchpad bug 201536 in italc "FF exception, new release of iTalc (1.0.7)" [Undecided,New] https://launchpad.net/bugs/201536
<Tonio_> pitti: putting this in /etc/environment could help ?
<pitti> Tonio_: preseeding might be more what you want; depends on your use cases, but in general we don't have a lot of debconf questions
<Tonio_> pitti: that's for work, we have to replace sendmail by postfix silently
<pitti> Tonio_: and sometimes dpkg asks about conffiles, etc., so getting the dist-upgrade completely automatic is not really recommended at least for hardy (development releasese)
<Tonio_> I don't wan't to repackage postfix removing the debconf stuff
<ogra_cmpc> Tonio_, sounds like you would also want DEBCONF_FRONTEND=noniteractive
<pitti> ^ that's better in this case, yes
<Tonio_> ogra_cmpc: hu mcould be this, yes
<Tonio_> ogra_cmpc: simply export it and that's okay ?
<cjwatson> soren: I think slangasek has gone to bed; do you have suitable instructions handy?
<ogra_cmpc> well, you should preseed values for debconf if you dont want the package defaults
<ogra_cmpc> but yes, simply exporting it before you run the package manager should be enough
<Tonio_> ogra_cmpc: simply use defaults in that case, so no need to do it, but if you know how to proceed, that would be nice
<Tonio_> ogra_cmpc: how to preseed values ?
<Tonio_> on the client side, that's what I don't know in fact :)
<soren> cjwatson: Not in any publishable form, no.
<pitti> ogra_cmpc: ah, looking; (1) the [] are comments from you, right? (2) you shold actually subscribe ~ubuntu-release for FF exceptions :)
 * cjwatson looks up #ubuntu+1 which apparently has held instructions on recovery
<ogra_cmpc> pitti, ... wollte erst die lage sondiern :)
<soren> cjwatson: I think there's something that's almost usable in the bug report (booting the live cd and doing dpkg --root or something, but I haven't tried it myself (as I was lucky enough to be lazy enough to not have updated this morning)).
<Tonio_> ogra_cmpc: doesn't seem to work for me.... exporting doesn't change anything...
<cjwatson> (I'm following DWCIU, in case that isn't obvious)
<Tonio_> doesn't apt overrides the variable value ?
<ogra_cmpc> Tonio_, DEBCONF_FRONTEND=noniteractive apt-get install blah
<ogra_cmpc> that way it should work ...
<pitti> ogra_cmpc: replied
<ogra_cmpc> but exporting shoud as well, weird
<Tonio_> ogra_cmpc: yes, but no, it doesn't :)
<ogra_cmpc> pitti, thanks
<mjg59> keescook: Not yet - still need to make it work. Just realised a subtle aspect that makes this all much harder
<Tonio_> ogra_cmpc: I just tried with postfix, I'm still questionned
<mjg59> keescook: The remaining issue is that there might be reads from the video ROM, and x86 doesn't let us separate readable and executable pages properly
<mjg59> Except possibly with nx, but still
<pitti> seb128: hm, is deskbar-applet still broken for you as well? I only see web searches, none of the other plugins (like devhelp)
<seb128> pitti: yes
<seb128> pitti: we will remove it for hardy
<pitti> you mean deskbar?
<pitti> erk, I now re-enabled some modules (devhelp, dict) and now it hangs
<foka_> join #ubuntu-devel
<foka_> Argh!  Oops, sorry...
<pitti> but you are already here :)
<emgent> ehehe
<ogra_cmpc> impatience :)
<foka_> Hehe, sorry.  I blame XChat for eating my key.  :-D
<Tonio_> ogra_cmpc: interesting, it works if I dpkg-reconfigure debconf, but but setting the env variable..... I suspect there is a bug in there :)
<ogra_cmpc> there are different veriables for the same purpose, might be that you need DEBIAN_FRONTEND here, try that
<cjwatson> pitti: interestingly, I have reproduced mathiaz's postgresql installation problem; this kvm d-i run has a mode 0660 /dev/null
<pitti> cjwatson: heh, new security feature?
<pitti> preventing wearout of /dev/null
<ion_> Heh
<cjwatson> heh
<cjwatson> I'll try to figure out at what stage it's happening, though only in the background since I'm dealing with the glibc thing
<dholbach> Riddell: do you think somebody could update the kubuntu-leaflet in example-content to say 8.04 instead of 6.06?
<emgent> glibc 2.7.9ubuntu2 FTBFS ? https://edge.launchpad.net/ubuntu/+source/glibc/2.7-9ubuntu2
<mdz> asac: I just had firefox crash on a "Save link as..." while the gtk file save dialog was still loading.  unfortunately, apport wasn't able to save a core dump, and I tried again on the same link but it works
<Riddell> dholbach: hmm, it would need the source from kwwii
<ion_> Is there going to be a default configuration for ufw in hardy, or why is it installed by default?
<dholbach> Riddell: that'd be nice
<pitti> ion_: I don't know about jdstrand's plan, but I wouldn't think so
<cjwatson> emgent: we know, we're dealing with it
<pitti> ion_: if we wouldn't want a port being open by default, we wouldn't open it in the first place
<ion_> Indeed. :-)
<pitti> ion_: and we still ship with no open TCP ports by default (just the usual DNS/avahi UDP ones)
<emgent> cjwatson: cool
<asac> mdz: ok. thanks anyway.
<mdz> asac: if you have any guesses about how I might try to trigger it further, or hear other reports, let me know
<asac> mdz: sure .... but most likely a follow-up of something. there are still plenty of crashes getting fixed every day.
<ogra_cmpc> asac, when is beta4 due (i'm eager to test the memory management improvements on teh cmpc)
<Wartorn> i just noticed the e: lib6: subprocess error, what should i do?
<asac> ogra_cmpc: we have a regression in epiphany which holds back the release.
<ogra_cmpc> gah
<asac> ogra_cmpc: otherwise the package is ready
<asac> ogra_cmpc: currently performing a binary search respin to track down the bad commit
<asac> cannot give an ETA though
<ogra_cmpc> yeah understood
<asac> pitti: how can it happen that there is no core dump created on crash?
<pitti> asac: /var/log/apport.log usually tells
<mdz> asac: it said there was not enough free memory
<asac> oh. ok
<mdz> not sure what that means, as I thought it streamed the core dump out to disk
<mdz> pitti?
<pitti> various reasons: the app has its own signal handler, or the core dump is too large
<asac> too large in which regards? ulimit?
<pitti> /etc/default/apport
<pitti> # set maximum core dump file size (default: 209715200 bytes == 200 MB)
<pitti> maxsize=209715200
<pitti> they are also capped on available memory size, since processing them takes ages and swaps (we got tons of complaints about this)
<Fujitsu> Hm, so lpia won't be official for Hardy?
<jdstrand> ion_: ufw is installed by default as it's in the standard seed. it does have a default configuration when enabled, and works quite well as a host-based firewall after performing 'sudo ufw enable'
<jdstrand> ion_: since having a 'default on' firewall would break things in non-obvious ways, it comes off by default, and is something users have to explicitly enable
<jdstrand> pitti: ^^
<ion_> k
<ion_> Ok, that is.
<zul> pitti: hi, I just uploaded the new version of samba-3.0.28a
<\sh> oh well...good to know that glibc behaves like wine with introduced LDFLAGS ;)
<Wartorn> what should i do? my update manager seems to have crashed, and i cant open the link in the topic
<pitti> zul: ah, great
<sabdfl> cjwatson: morning, thanks for your comments on #201673, makes me reassured
<sabdfl> since i don't have a Live CD handy and nothing is working :-P
<cjwatson> sabdfl: I'm preparing recovery notes now; see http://paste.ubuntu.com/5653/
<cjwatson> if you have a root password set and haven't rebooted, you can recover on the spot, though a reboot would then be advisable
<cjwatson> I haven't tested these yet though - am working on getting a spare system upgraded to the point where it exhibits the bug
<cjwatson> there is a cunning trick from Keybuk to recover even without a live CD, though I'm a little hesitant to recommend it in general since it depends on exactly when you upgraded from
<sabdfl> cjwatson: su b0rks for me too
<cjwatson> sigh, somebody said that worked
<cjwatson> yes, breaks in my chroot too
<sabdfl> both sudo and su seem borked
<Hobbsee> development releases and testing...
<ogra_cmpc> init=/bin/bash ?
<sabdfl> i have the .deb, though
<cjwatson> ok, Keybuk's trick is to boot with break=mount, then 'cp /lib/libc.so.6 /root/lib/libc-2.7.so'
<Keybuk> ogra_cmpc: bash will crash too
<cjwatson> (init=/bin/dash works)
<ogra_cmpc> dash then ?
<sabdfl> dash seems to work
<sabdfl> reboot to init=/bin/dash, then dpkg -i the .deb?
<Keybuk> cjwatson: for a fully forked trick, it'd have to be
<cjwatson> the break=mount trick works provided that the initramfs hasn't been regenerated since the break
<Keybuk>   break=bottom
<Fujitsu> cjwatson: Couldn't one ar and tar stuff out of an old deb which is likely present in /var/cache/apt/archives?
<Keybuk>   mount -o rw,remount /root
<Keybuk> then the cp
<cjwatson> Fujitsu: why ar and tar when dpkg works fine?
<Fujitsu> Does it? I presumed otherwise.
<Keybuk> (I broke at mount and mounted it manually rw, but that's more hard-code than it needed to be - I just wasn't sure how much was broken)
<cjwatson> Fujitsu: tested
<Fujitsu> Ah, good.
<cjwatson> sabdfl: yes, that will work
<Keybuk> sabdfl: if you init=/bin/dash - you will need to mount -o rw,remount /
<cjwatson> doh, yes
<pitti> Keybuk: btw, didn't we complain about the absence of OMGKITTENSDIE bugs just yesterday on the phone? :)
<asac> anyone here with ath_pci or hostap wifi?
<soren> asac: Yes.
<asac> soren: which?
<asac> soren: do you run network manager?
<soren> ath_pci
<soren> Yes.
<asac> 0.6.6?
<soren> It's on my old laptop which is not up-to-date. I can fire it up and update if you want me to?
<asac> soren: please do
<asac> have to figure if we still need driver tweaks for it
<soren> asac: Alright. It'll be a while :)
<asac> trying to get input from bugs is just ... aehm ... cumbersome
<asac> :)
<soren> I feel your pain :)
<sabdfl> so, to be certain:
<sabdfl> reboot
<sabdfl> at the grub menu, add init=/bin/dash to the kernel boot command
<sabdfl> when at the root prompt
<sabdfl> mount -o rw,remount /
<sabdfl> dpkg -i /path/to/working/libc.deb
<sabdfl> right?
<cjwatson> note that (I am told) you will not see the root prompt when booting with init=/bin/dash due to some fuckedness somewhere; wait for a bit and type 'ls' to confirm the system's up
<cjwatson> but otherwise that's right
<ogra_cmpc> there he goes
<Keybuk> pitti: yes ...
<Keybuk> I was right, the phone call was too early for them to show up
<Keybuk> a few hours too early ;)
<cjwatson> oops, now everything segfaults
<cjwatson> I guess gutsy's libc doesn't work so well for that trick
<ogra_cmpc> Keybuk, did you bribe doko secretly to develop a proof of concept ?
<Keybuk> we should just be glad we didn't get a libc security update, and find out after hardy was released :)
<ogra_cmpc>  yeah
<Fujitsu> Keybuk: You can be sure that a security update for something else will cause similar breakage due to that LDFLAGS change.
<Wartorn> how can i fix the libc thing? i cant seem to update anymore, gotta format?
<ogra_cmpc> Wartorn, see /topic
<Pici> Wartorn: #ubuntu+1 is probably the place you want to be :)
<cjwatson> Wartorn: I'm going to be posting semi-official workaround instructions as soon as I've got them tested
<cjwatson> I will post them to the bug URL in the topic
<Pici> cjwatson: Do you mind pinging me or another op  when you do so? So that the link can be added to the topic in #ubuntu+1?
<Wartorn> thing is, i cant open firefox anymore
<ogra_cmpc> Wartorn, w3m is installed by default ... you can use it from the commandline
<slytherin> dholbach: I am trying to fix evolution-scalix package. I am patching configure.in. How do I generate configure script in build process?
<slytherin> oops, wrong channel
<seb128> asac: do we have any firefox bookmarks customization?
<seb128> slytherin: don't, create a autoconf patch rather
<seb128> slytherin: cdbs-edit-patch 99_autoconf_update; autoconf; rm -rf autom4te.cache; exit
<slytherin> seb128: Ok. I will continue discussion with dholbach in #ubuntu-motu. :-)
<dholbach> slytherin: I'm about to leave for a dogwalk
<dholbach> slytherin: I recommend seb128's approach
<asac> seb128: why?
<seb128> asac: I want to do similar changes for epiphany and I could reuse the labels and urls you added for firefox if you did that
<seb128> asac: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/137491
<ubotu> Launchpad bug 137491 in epiphany-browser "epiphany does not have launchpad customizations by default" [Wishlist,Triaged]
<asac> i still have them ... but that might be from the old profile
<asac> let me look
<seb128> asac: I though it would be in ubufox but it doesn't seem to be there
<asac> seb128: yes. we had patched that in ffox 2... i didn't move that to ubufox yet
<asac> seb128: but its not even decided what to put there afaik
<asac> seb128: anyway ... you could start firefox-2 and use the bookmarks.html created in your profile if you need something
<asac> now
<seb128> asac: ok, thanks
<ogra_cmpc> oh sabdfl is alive
<cjwatson> sabdfl: Keybuk and I figured out what was going on with dpkg; PATH wasn't set (or didn't contain /sbin and /usr/sbin), and stderr isn't set up properly in the initramfs
<cjwatson> the advice I'm preparing for the bug report will not include using dpkg from the initramfs
<sabdfl> that was an entertaining detour
<sabdfl> thanks keybuk
<sabdfl> and cjwatson
<sabdfl> do we have any sort of download count on the number of people affected?
<Fujitsu> From what I can tell, lots of people are still getting it from mirrors.
<emgent> if mirror count download i think yes
<cjwatson> probably not a terribly accurate one since most will be mirrors
<cjwatson> FWIW, fixed versions are publishing now
<cjwatson> they should be available from archive.u.c within the hour
<ogra_cmpc> yippie
<ogra_cmpc> these are the days where i realize how much deboootstrap my work involves
<sabdfl> can we pulse mirrors?
<cjwatson> no point yet
<cjwatson> but once it is published, we automatically pulse all of the ones that we can, AIUI
<cjwatson> the ones that don't update rapidly are the ones where we don't have push-mirroring
<cjwatson> I will be doing an incident report afterwards, although not a full-blown one since this is a pre-beta development release
<Hobbsee> cjwatson: who would have figures on how many bad SRU's there have been, that have gone and broken things?
<Hobbsee> as in, while still being tested
<ogra_cmpc> do we move the freeze by one day ? i imagine that a lot of work couldnt be done today
<Hobbsee> (and excluding security fixes, which don't go thru sru)
<cjwatson> Hobbsee: there have been three stable updates serious enough to warrant internal incident reports
<Hobbsee> cjwatson: how many of those were security?
<cjwatson> two
<Hobbsee> cjwatson: what was the other?
<cjwatson> the infamous X update in 2006
<cjwatson> I wouldn't try to infer anything from that division though - the sample size is far too small for it to be statistically valid
<Hobbsee> cjwatson: oh.  i thought that was the first security one.
<cjwatson> no, it was a regular update
<Hobbsee> ah
<Hobbsee> cjwatson: thanks.  was just curious
<juliank> Could version 0.6-0ubuntu3 of ndisgtk be removed from the archive? ndisgtk is now Architectures: i386, amd64 (changed in Debian, because it depends on packages only available on these platforms) - this old Architecture: all version is still in the archive.
<ogra_cmpc> juliank, oh, why/how did the code change ? last time i looked it was pygtk ... did they port it to C ?
<ogra_cmpc> i wouoldnt restrict it to two arches only if there are chances someone ports it for other driver installations etc
<cjwatson> juliank: nobody's added it to Packages-arch-specific
<juliank> ogra_cmpc: It's still Python, but it needs ndiswrapper which is only available on i386 and amd64. Windows drivers are only available for these architectures.
<cjwatson> ogra_cmpc: it depends on ndiswrapper-utils-1.9 which is in P-a-s
<cjwatson> juliank: could you please mail one of the addresses listed at the top of http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.738&root=dak&view=markup to get this corrected
<cjwatson> ?
<ogra_cmpc> juliank, its a frontend gui that could easily operate with xyzwrapper for sparc for example...
<juliank> cjwatson: I did this a long time ago. In Debian, the old "all" package is removed, only i386 and amd64 packages are left.
<cjwatson> juliank: if you did, it has not been applied
<cjwatson> juliank: so I would advise doing so again
<cjwatson> juliank: I've removed it from hardy, although until P-a-s is changed it may well try to build again
<juliank> cjwatson: I also noted ndisgtk in my email "Adding Install-Architecture to debian/control" http://lists.debian.org/debian-devel/2008/02/msg00045.html
<Riddell> siretart: can you play dvds in hardy xine?
<dholbach> thekorn: what do you think about       <pitti>  dholbach: if plpbugs now gets along with the ffox 3 cookies.db, then we should probably extend the heuristics to check for ~/.mozilla/*/*/cookies.sqlite first? and then fall back to s/sqlite/txt/?
<pitti> dholbach: NB that this shouldn't be a default in p-lp-bugs itself
<pitti> but in the apps using it
<dholbach> pitti: oh, hm
<thekorn> I agree with pitti
<dholbach> to me it looks like we'll have that check in a lot of different places then
<pitti> well, maybe we can put that function into p-lp-bugs
<pitti> find_mozilla_cookie() or so
<pitti> but it shouldn't be called by default in the library IMHO
<pitti> since it's prone to use cookies you don't intend to use
<dholbach> that makes sense to me
<dholbach> of course
<ion_> 2.7-9ubuntu2 seems to have hit archive.ubuntu.com
<cjwatson> correct
<cjwatson> I already updated the bug
<cjwatson> I do wish my test system would upgrade more quickly so that I could post tested workaround instructions
<cjwatson> pitti: is bug 197667 yours? seems to be talking about usplash-fsck integration problems
<ubotu> Launchpad bug 197667 in usplash "problem with new display of FSCK" [Undecided,New] https://launchpad.net/bugs/197667
<pitti> cjwatson: yes, it is; I assigned it to mow
<pitti> me, even
<asac> soren: any ETA till your laptop has been upgraded to latest?
 * pitti hopes that fsck will output useful progress information for this case; otherwise we are quite doomed
<soren> asac: I needed to wait until there was a usable libc6.. It's running now. I need to downgrade nm, though (I was using the one from your ppa that we tested at the sprint in London).
<soren> The upgrade is running now, I mean.
<ryanakca> Ummm. I'm getting this when running an upgrade http://pastebin.ca/941103 (403 Forbidden). Is that what the topic means by "glibc is broken" ?
<asac> soren: thanks. remember to downgrade wpasupplicant as well
<asac> soren:  but nm 0.7 worked right?
<soren> asac: Well, I left it installed, so I'm guessing yes. :)
<Riddell> pitti: how do I test jockey if I don't have any proprietry drivers needed?
<asac> soren: intersting. ok lets see how hard 0.6.6 striked you
<pitti> Riddell: check out the ubuntu branch and run jockey-kde -H examples/handlers/
<pitti> Riddell: tests/run-qt will also show it
<pitti> Riddell: speaking about jockey, do you know anyone who is interested in fixing some UI bugs in the qt implementation?
<Riddell> pitti: I was going to take a quick look at the ones you e-mailed mhb
<pitti> ah, great
<ryanakca> pitti: What kind of UI bugs? I have the day off. Do they involve much coding, or just fireing up qt-designer?
<pitti> ryanakca: stuff like "default column width is wrong", "icon missing", etc.
<pitti> ryanakca: so it's some lightweight pyqt coding (maybe this can be fixed in the designer, too, not sure
 * pitti <- pyqt noob
<ryanakca> pitti: oh, I could probably do that if Riddell/mhb don't have dibs on it. I'm guessing all the bugs are under Launchpad?
<ryanakca> pitti: me too :)
<Riddell> ryanakca: I can forward you pitti's e-mail
<pitti> ryanakca: some are
<ryanakca> Riddell: please :)
<pitti> right, that would be good, thanks
<pitti> ryanakca: in general it should behave similar to the gtk implementation
<ryanakca> pitti: I'll try to get through as many as I can :)
<pitti> ryanakca: so if you could install both and get a feeling what's missing?
<ryanakca> pitti: ok
<ryanakca> yep
<pitti> ryanakca: awesome, thank you
<superm1> asac, did you still need some input on ath_pci with nm 0.6.6?
<ryanakca> pitti: Cheers :)
<lamont> slangasek: I wonder... if a package is ftbfs in feisty, and unchanged since feisty, can we justify nuking the binary from the archive for hardy?
<cjwatson> excellent, working initramfs restore instructions
<cjwatson> now I just need this live CD to finish booting so I can test that
<\sh> now recreating all hardy chroots ... fun :)
<Wartorn> When will the libc error be fixed?
<ion_> It has been fixed.
<asac> superm1: yes
<superm1> asac, what are you looking for exactly regarding it?
<asac> superm1: does it work for you (open network, WEP, WPA1/2)?
<superm1> asac, it kinda works - i use wpa2 here.  it doesn't come up on boot consistently
<Wartorn> okay, cause i cant seem to use update manager, nor can i open a terminal, cant even use one of the tty terminals
<Wartorn> any solution other than formatting?
<superm1> asac, i've got to retry picking the network a few times
<superm1> but once it's up, it stays up
<asac> superm1: can you open a bug for the "not automatically" connecting issue?
<asac> and attach the complete syslog?
<asac> superm1: and if possible, please aslo try WEP
<asac> and maybe HIDDEN network
<ogra_cmpc> Wartorn, detailed instructions will be attached to the bugreport
<superm1> asac, sure.
<asac> superm1: are you sure you are using wpasupplicant from hardy (and not the one i released for nm 0.7)?
<superm1> as for the hidden network, i've got a hidden wep one in my appt too on my AP :)
<asac> superm1: hmm bad combination as i don't know if either works :)
<asac> superm1: if it works then its most likely fine :)
<superm1> asac, i've not enable your network manager 0.7 PPA - so i shouldn't have wpasupplicant from it
<asac> superm1: which version?
<superm1> 0.6.0+0.5.8-0ubuntu2
<asac> ok thats fine
<ion_> wartorn: There are workarounds mentioned in the bug report (see topic).
<asac> superm1: did you ever manage to connect to hidden network with ath_pci?
<superm1> asac, well yes - but i should warn this hidden network is on the same AP, so same BSSID (just different ESSID)
<superm1> asac, so it starts to act wonky on that hidden network
<asac> interesting what kind of setups exist
<superm1> asac, i had to set it up that way to make nintendo ds's work on my network without buying a second AP :)
<asac> nintendo can only do WEP?
<superm1> the DS can only do WEP, the wii can do wpa2
<superm1> asac, bug 201828
<ubotu> Launchpad bug 201828 in network-manager "ath_pci doesn't consistently connect on boot to WPA2" [Undecided,New] https://launchpad.net/bugs/201828
<superm1> I'll be able to test the WEP after work, and get back to you on that.
<superm1> asac, i'll be afk for most of the rest of the day, so is there anything else you'd like me to append to that bug before hand?
<asac> superm1: let me see
<asac> superm1: i only see a successful connect attempt
<asac> maybe post at what time i can see the failed one
<asac> superm1: are you really sure you are running the hardy supplicant ?
<asac> there are messages i have only seen in 0.6
<asac> anyway
<superm1> asac, mar 13 at 1:26 or so
<superm1> it doesn't get fully connected
<superm1> so it tries again
<twi_> hi
<ogra_cmpc> hmm, i still cant debbootstrap, strange
<asac> superm1: can you post that time in the bug?
<superm1> asac, sure will do
<asac> at best the start line in syslog
<asac> thanks a lot
<twi_> pitti hi, I work on elisa
<twi_> pitti re https://bugs.launchpad.net/ubuntu/+source/elisa/+bug/186647/ tell me if you need help with the MIR or anything else
<ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New]
<ogra_cmpc> heh, not using a mirror helps
<superm1> ogra_cmpc, i understand there were a few updates needed for the mythbuntu LTSP plugin from laga, did you ever get those in place?
<ogra_cmpc> superm1, not all of them yet, i'm on it ... my prob was that i need working debootsrap to test them so it wqasnt possible this morning yet
<ogra_cmpc> i'm going through the ltsp buglist asw we speak, lagas are among them
<superm1> ogra_cmpc, okay great thanks. good luck getting a good debootsrap :)
<ogra_cmpc> seems to work now
<ogra_cmpc> i had forgotten that my apt-proxy pointed to a mirror where the new libc isnt in place yet
<protonchris> Is there a way to see what is currently in the binary NEW queue?
<ryanakca> pitti: is jockey in a bzr branch or do I patch the package directly?
<ryanakca> ... and nevermind, I figured it out myself :)
<cjwatson> workaround instructions on bug 201673 now
<ubotu> Launchpad bug 201673 in glibc "REGRESSION: glibc 2.7-9ubuntu1 NSS module broken due to toolchain changes" [Critical,Fix released] https://launchpad.net/bugs/201673
<sistpoty|work> protonchris: https://launchpad.net/ubuntu/hardy/+queue
<nixternal> cjwatson: groovy! thanks. I tried to forewarn people last night...the forums were active and had a viable fix up within an hour it seems
<pitti> ryanakca: yes, it's in bzr (both upstream and the ubuntu package)
<soren> asac: nm-applet gives me: nm-applet: symbol lookup error: nm-applet: undefined symbol: dbus_method_dispatcher_new
<cody-somerville> infinity, Can you take a look at bug #194912 ? thanks.
<ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
<asac> soren: downgraded as well?
<soren> asac: Oh, sorry. Leftover libnm-* stuff
<asac> k
<\sh> hmm...
<\sh> can someone explain why php5-modules on amd64 are installed in /usr/lib/php5/20060613 and on i386 in /usr/lib/php5/20060613+lfs ?
<soren> IIRC the directory was changed on i386 because the ABI was broken (when adding large file support (hence the lfs suffix)).
<soren> asac: Works fine (using WEP encryption).
<\sh> soren: grmpf...
<soren> \sh: What?
<\sh> soren: it's bad when you provide .ini files for extentions and you need to change them depending on the arch
<\sh> soren: question is, can we drop this +lfs for hardy and join back to one directory name for i386+amd64+others?
<soren> Has the ABI been bumped?
<Amaranth> wow, glibc had the same problem wine had?
<ion_> amaranth: kexec-tools FTBFSâd because of a similar problem. :-)
<\sh> soren: I have to check php src pkg...to see when it was introduced :)
<soren> Amaranth: Lots of stuff broke.
<cjwatson> Amaranth: I did not know that wine had the same problem; do you have a reference?
<soren> Amaranth: dpkg itself, for instance :)
<cjwatson> soren: it did? reference?
<soren> I'm assuming "the same problem" refers to the failure to build when passed LDFLAGS and friends as environment variables?
<pitti> seb128: FYI, triggering the next round of give-backs
<soren> If not, pardon me for spreading FUD :)
<cjwatson> soren: I don't see anything relevant in the dpkg changelog since the LDFLAGS change was made
<Amaranth> cjwatson: https://edge.launchpad.net/ubuntu/hardy/+source/wine/0.9.56-0ubuntu1
<cjwatson> soren: are you saying that dpkg failed to build or otherwise broke due to being passed LDFLAGS as an environment variable from dpkg-buildpackage?
<cjwatson> Amaranth: thanks
<soren> cjwatson: Er... Sorry, my mistake.
<soren> cjwatson: Same upload, though. Different problem.
<cjwatson> soren: I really need you to be verbose
<seb128> pitti: ok
<soren> cjwatson: Yes, sorry.
<soren> cjwatson: grub failed to build due to it, though.
<soren> 0.97-29ubuntu15 fixed that.
<cjwatson> that looks like CFLAGS rather than LDFLAGS
<soren> cjwatson: The dpkg problem I was thinking about was the one about pkg-create-dbgsym, which caused dpkg itself to fail to build.
<cjwatson> right, that looks disconnected though?
<soren> cjwatson: Hence the "and friends".
<soren> cjwatson: Let me start over..
<cjwatson> as in, that was a separate problem with dpkg's perl modules used by pkg-create-dbgsym
<soren> cjwatson: The change to dpkg-buildpackage to make it pass a set of environment variables to was introduced at the same time as the change that broke pkg-create-dbgsym.  The former change broke grub, the latter broke a lot of stuff (including dpkg itself).
<cjwatson> right, I only care about the former right now. :-)
<cjwatson> wine is the only other case I've heard of where the failure was at run-time
<soren> Ok. While it wasn't LDFLAGS specifically that broke it, it was "one of the environment variables the dpkg-buildpackage has recently started setting".
<cjwatson> ok
<soren> I seem to be causing more confusion than I'm helping, so I'll wander off now.
<cjwatson> CFLAGS and friends seemed to be set to -g -O2 in the case of grub
<cjwatson> it seems to be specifically -g that grub hates
<nixternal> ahhh man, I am back in heaven here
<soren> cjwatson: How do you come to that conclusion? I'm not contesting it, I'm just curious.
<cjwatson> soren: because dpkg-buildpackage sets -O2 -g, and grub/configure.ac sets -O2
<cjwatson> (and others)
<keescook> infinity: can you check why "zsnes" isn't even attempting to build on amd64?  the control file lists "i386 amd64" ...
<soren> cjwatson: Makes sense.
<soren> zsnes: i386     # Mostly written in i386 assembler
<soren> keescook: ^^ from p-a-s
<keescook> soren: p-a-s ?
<soren> Packages-arch-specific
<keescook> what file is that?
<soren> The file we share with Debian that actually defines which architectures we'll try to build stuff on.
<keescook> *boggle* control file is ignored?
<soren> Yes.
<soren> I share your boggliness.
<keescook> anyway, zsnes was specifically patched to build on amd64.
<keescook> so, what is the process to fix p-a-s?
<soren> Tell lamont, infinity, or slangasek.
<soren> I believe they have access to the cvs repository where it's kept.
<lamont> keescook: we share Packages-arch-specific with debian.  and no, we're not going to fork it.
<lamont> and yes, control file is ignored.
<lamont> well, not so much ignored as overridden
<cjwatson> it's not quite ignored; if the control file says "don't build on this arch" then it will try but fail
<lamont> cjwatson: right
<soren> keescook: I believe the rationale is something along the lines of: buildd maintainers allegedly know better than package maintainers if a given package will build on their architecture, so the architectures: field is ignored.
<keescook> fun
<lamont> if PaS says to ignore it, then wanna-build (and the launchpad equivalent) ignore the package for that architecture
<cjwatson> the rationale is that historically package maintainers demonstrably had no idea
<soren> *g*.
<keescook> okay, I will sum it up for the bug I saw.  :P
<lamont> porters know better than package maintainers whether or not their architecture can handle it
<lamont> keescook: and the issue I had was that the package still doesn't work for people who have been building it, apparently (from the bug)
<soren> Well, a lot of folks know a lot of stuff better than a lot of other folks. :)
<soren> That's why we file bugs against packages to fix such things.
<keescook> lamont: I can believe that -- I was just curious about the lack of soyuz-build-attempt
<soren> *shrug* I'm not really in the mood to discuss it again.
<keescook> soren: what's the url for that file, btw?
<soren> http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.738&root=dak&view=log
<lamont> keescook: soyuz uses debian's Packages-arch-specific
<lamont> always has
<keescook> cool
<soren> If the people with access to p-a-s are happy to make changes, it's not a problem per se.
<soren> (and they are, so we're all good)
<soren> I'm curious... Does anyone know if there's a large delta between what the packages' arch fields say and what p-a-s says?
<soren> I mean... If we decided to trust the architectures field of our packages, how swamped would be we with build failures?
<\sh> soren: even with the trust in the arch maintainers of our buildds we are bugged with many build failures for packages...
<soren> Ok, rephrasing..
<soren> If we decided to trust the architectures field of our packages, how *much more* swamped would we be with build failures?
<YokoZar> lamont: speaking of PAS...would removing zsnes from there (or adding amd64 to it) be appropriate?  :)
<\sh> soren: the problem is not the arch, but the developers who only know i386 and nowadays amd64 and who have no clue about other archs...
<soren> Well, the default is to build on all archs.
<\sh> soren: not for people who only know linux
<\sh> soren: on i386
<YokoZar> Is there anything horribly wrong with letting the buildd just fail?
<soren> So, to limit it to a smaller set of archs, we'd just have to change the package rather than p-a-s. That's not much different.
<soren> YokoZar: Waste of resources.
<soren> YokoZar: And time. And it fills my inbox with build failure logs.
<\sh> soren: tbh, most of the build failures nowdays are from hppa, sparc
<soren> \sh: I don't see your point.
<YokoZar> Well, once you get the build failures you could change the package, and then soon enough we'd have reliable control files to use instead of PAS
<\sh> soren: there are archs which are not well supported...one is hppa (in our case) and also sparc, just because most of the people don't have a clue about those archs...how many people do you know in here who are actively trying to fix all failed packages e.g. on hppa?
<soren> Well, the *real* point, as I see it, is that that's how they got added to p-a-s to begin with.
<soren> \sh: How does that relate to whether we set the build architectures in p-a-s vs. the control file?
<\sh> soren: it doesn't...but what you said, about "your|mine|our resources" it relates...well it's annoying to get every week a failed buildlog for <insert pkg here> on <insert port arch here> for software, which isn't even supported officially (means packages which are not in main)
<soren> \sh: Yes.
<\sh> ok..time to go home...
<pitti> YokoZar: problem arises if the build succeeds, but the package wouldn't actually work
<seb128> is there a policy about what perl applications should use betwen "env perl" and "/usr/bin/perl"?
<Keybuk> I think it slants towards the latter
<seb128> bug #199134 is the issue
<ubotu> Launchpad bug 199134 in gnome-system-tools "Perl upgrade breaks gnome system tools" [Undecided,New] https://launchpad.net/bugs/199134
<ion_> For tarballs ditributed for whatever platform, iâd go with /usr/bin/env perl, but for Debian packages, /usr/bin/perl.
<Keybuk> doesn't the perl installer thing take care of setting the #! in the script to the correct full path of the interpreter?
<ogra> argh
 * ogra just came back to his desktop which is also his build server ....
<ogra> i havent seen the desktop here since the weekend ... and my build scripts loop mount about ten times in every run
<slytherin> can anyone of the buildd admins please give back evolution-jescs?
<ogra> ps ax|grep nautilus|wc -l
<ogra> 328
<ogra> *sigh*
<ion_> UUOG ;-)
<cjwatson> Pici: belatedly, I've edited the description of https://launchpad.net/bugs/201673 with workaround documentation
<ubotu> Launchpad bug 201673 in glibc "REGRESSION: glibc 2.7-9ubuntu1 NSS module broken due to toolchain changes" [Critical,Fix released]
<pitti> slytherin: done
<slytherin> pitti: thanks
<Pici> cjwatson: okay, I had stuck that in the #u+1 topic anyhow :)
<cjwatson> Pici: thanks
<cjwatson> Keybuk: not everyone bothers using ExtUtils::MakeMaker and friends; too heavyweight for many purposes
<Keybuk> cjwatson: not everybody bothers showering once a day
<ion_> find debian/$(cdbs_curpkg) -name '*.pl' -print0 | xargs sed -i -re '1s,^#!.*,#!/usr/bin/perl,' :-)
<ion_> xargs -0r, that is
<ion_> Would it be appropriate for dh_make to do that, btw?
<cjwatson> Keybuk: thpppt, using EU::MM is total overkill for an ordinary script :)
<seb128> slangasek: what do you plan to put the freeze in action? ;-)
<ogra_cmpc> seb128, do you have to poke him about it ... he probably forgot and now you reminded him
<pitti> mvo: yay, I just fixed the last two conffile prompt bugs on the hardy milestone list
<mvo> pitti: rock!
<seb128> ogra_cmpc: yeah, but later ;-)
<pitti> mvo: except, of course, bug 174128, which I still can't reproduce
<ubotu> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
<pitti> mvo: btw, do you get diff -Nur for /etc on upgrade tests now?
<ogra_cmpc> seb128, well, given that much was blocked today i'd relly propose to slip one day
<pitti> we should fix that as well for a really working upgrade
<seb128> right
<mvo> pitti: I can generate diffs now, haven't looked over them in a while though
<slangasek> lamont: ah, if a package is ftbfs in feisty and unchanged since feisty, did anyone file a bug about the build failure or is this the first time anyone's noticed it? :)
<ogra_cmpc> i know i wont make all i planned in time
<pitti> mvo: could they be put onto p.u.c. automatically?
<slangasek> lamont: but yes, nuking the binary in any case seems reasonable...
<mvo> pitti: its a problem as the kvm based upgrade tester is not available in the data center
<slangasek> soren: I don't have any commit access to P-a-s, btw
<mvo> pitti: but I should setup something semi-automatic on my home machine
<soren> slangasek: Noted :)
<arcticpenguin380> why does every new *ubuntu neeed more ram/
<slytherin> arcticpenguin380: what do you mean?
<pitti> asac: are you handling bug 194379? if so, care to assign it to you? if not, want me to check the patch and apply/upload?
<ubotu> Launchpad bug 194379 in gnash "enable xulrunner 1.9/firefox 3.0" [High,Confirmed] https://launchpad.net/bugs/194379
<slytherin> pitti: I think it is already fixed.
<arcticpenguin380> dapper.edgy fiesty required 256 but gutsy needs 320mb ram and now hardy needs 384MB
<slytherin> pitti: Indeed that is fixed with latest gnash upload
<pitti> slytherin: ah, thanks;  I'll close it then
<pitti> indeed, I see it in the changelog
 * pitti hugs asasc
<cjwatson> arcticpenguin380: the gutsy number was probably not very accurate, to be honest, and 384 would probably have been closer for it; it was due to some problems in (we think) the kernel that have never been fully tracked down, as well as new desktop features
<pitti> and asac too
<arcticpenguin380> is that for just the live cd?
<cjwatson> arcticpenguin380: there's been work done recently on something called 'compcache' which promises to be able to reduce the memory load significantly for intrepid (I think it's too late now for hardy, unfortunately), and we plan to do some other performance work then too
<cjwatson> arcticpenguin380: it should be possible to install the alternate CD with significantly less memory, though 256MB is probably still about the lower end to be able to run the standard Ubuntu desktop
<arcticpenguin380> cjwatson: is that for the next ubuntu release or the kernel itself?
<slytherin> is anyone already working on OOo FTBFS for powerpc?
<ion_> compcache â¥
<cjwatson> arcticpenguin380: next Ubuntu release
<cjwatson> (after hardy)
<arcticpenguin380> i know itrepids next im on hardy now
<ScottK2> FWIW, I run Hardy Kubuntu (KDE3) on a laptop with 256MB ram and it works reasonably (if slowly) well.
<ion_> cjwatson: Does the compcache patch support the feature being disabled unless a kernel cmdline parameter is given?
<arcticpenguin380> think ext4 will be in intrepid?
<cjwatson> ion_: sorry, I don't know the answer to questions about compcache in general, I'm just vaguely aware of it
<cjwatson> arcticpenguin380: depends on whether it's accepted upstream; we don't propose to inflict experimental filesystems on our users and then have to deal with the cleanup
<cjwatson> pitti: what do you think of bug 201852?
<ubotu> Launchpad bug 201852 in casper "[Hardy] casper should configure PolicyKit to avoid asking paswd for user ubuntu in live mode" [Undecided,New] https://launchpad.net/bugs/201852
<cjwatson> seems to make sense to me
<pitti> cjwatson: indeed it does; assigned to me, will fix tomorrow
<pitti> thanks for pointing out
<cjwatson> pitti: cool, thanks
<ion_> cjwatson: Apparently compcache consists of a kernel module and nothing more intrusive, so it should be possible to include it in linux-ubuntu-modules and just not load it by default, or package it to be used with module-assistant.
<ion_> cjwatson: Iâd be very happy to get it to l-u-m. :-)
<ion_> cjwatson: There seems to be a bug report about it with a debdiff, https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/200765
<ubotu> Launchpad bug 200765 in linux-ubuntu-modules-2.6.24 "Add compcache modules, allowing ubiquity installs on 256MB machines." [Medium,Triaged]
<TheMuso> slangasek: Just wondering whether any more of the FFe queue will be processed before beta freeze. I'd like to get eSpeak in if I could... bug 200370
<ubotu> Launchpad bug 200370 in espeak "FF Exception, new upstrea version of Espeak." [Undecided,New] https://launchpad.net/bugs/200370
<seb128> hey TheMuso
<TheMuso> Hey seb128.
<seb128> TheMuso: have you read the GNOME bug I pointed about the pulseaudio issue the other day?
<TheMuso> seb128: Yes I have, and I tried the suggestion, which works. Not sure whether we shoudl install that package as well however.
<seb128> why not?
<TheMuso> seb128: Thats the conclusion I've come to.
<TheMuso> The question is now whether its better to seed it, or make it a dependency.
<jdstrand> lamont: I was curious as to the status of bug #200739
<ubotu> Launchpad bug 200739 in bind9 "bind9 apparmor profile is named apparmor-profile" [Undecided,Fix committed] https://launchpad.net/bugs/200739
<jdstrand> lamont: I see you requested a sync, but it's not in hardy yet
<jdstrand> lamont: I issued bug #201954 and was preparing a fix
<ubotu> Launchpad bug 201954 in bind9 "bind9 apparmor profile does not allow access to /var/lib/bind" [Medium,Triaged] https://launchpad.net/bugs/201954
<lamont> jdstrand: that's a "pester the archive-admin-of-the-day" thing
 * jdstrand goes to see who the admin is
<lamont> jdstrand: git clone git://git.debian.org/~lamont/bind9.git :-)
<lamont> and then git checkout -b v9.4.2 origin/stable/v9.4.2
<lamont> jdstrand: or just grab the bits from debian
<lamont> or pester $archive-admin to do the sync
 * jdstrand nods
<jdstrand> lamont: going the git route, since I know better now ;)
<lamont> jdstrand: it was just pointed out that the git tree is a little sideways atm... gimme a minute
<lamont> tags in place. doh
<jdstrand> lamont: I am already running clone, I guess I'll just do a pull? (I'm a git newbie)
<jdstrand> after it's done that is
<lamont> git fetch origin
<jdstrand> ok
<lamont> it's just tags that are missing
<emgent> hi jdstrand :)
<jdstrand> hi emgent!
<lamont> jdstrand: then git commit; git-format-patch (see man); git-send-email
<jdstrand> \m/-- a git tutorial
<lamont> jdstrand: and then pester the bzr folks to give you a bzr interface that sits on top of git plumbing so that you can use the bzr UI and still just fetch from the upstream git server....
<jdstrand> I thouth bzr-git existed?
<lamont> jdstrand: it gives you read access to a git tree
<jdstrand> ok
<lamont> and I don't know but what it just converts a git tree into a bzr tree, and then you can't freshen the tree without recreating it...
<lamont> could be totally wrong, fiww
<Mithrandir> git-bzr supports pulling, I think
<Mithrandir> bzr-git, even
<cjwatson_> I'd be amazed if it didn't
<cjwatson> that's how bzr-$vcs works as a general rule
<mdke> can anyone help in translating bug 144498, I don't really understand it
<ubotu> Launchpad bug 144498 in gnome-user-docs "autopkgtest gutsy gnome-user-docs: erroneous package!" [High,New] https://launchpad.net/bugs/144498
<cjwatson> mdke: you need to look at the original description, which has the full log; it's a build failure bug
<cjwatson> mdke: it appears to be because:
<cjwatson> /bin/bash /home/daniel/bzr/build-area/gnome-user-docs-2.18.2+svn20070912ubuntu1/install-sh -d /root/adt-downtmp/dsc0-build/gnome-user-docs-2.18.2+svn20070912ubuntu1/debian/gnome-user-guide//usr/share/gnome/help/user-guide/C
<cjwatson> /bin/bash: /home/daniel/bzr/build-area/gnome-user-docs-2.18.2+svn20070912ubuntu1/install-sh: No such file or directory
<cjwatson> mdke: i.e. hardcoded path to the home directory of whoever built the source package lying around in the source package
<mdke> oh, the log is cut off?
<cjwatson> yeah
<mdke> hehe
<mdke> is that test done regularly?
<mdke> i.e. if there isn't a bug for it in hardy do I need to worry about it?
<cjwatson> it was at one point, I don't think it is at the moment
<cjwatson> grep for that path in the source package ...
<cjwatson> assuming Daniel did the last build
<cjwatson> oh, he didn't. grep for your home directory then
<cjwatson> but, TBH, if it built on the buildds you're probably OK
<mdke> I think he did
<mdke> will try
<mdke> thanks cjwatson
<mdke> cjwatson: grepping for my home directory in the test source package I just did shows the path, also the latest gutsy package shows daniel's, but the various packages have never ftbfs on launchpad
<mdke> at least afaik
<cjwatson> it may be that they don't fail when run under dpkg-buildpackage, but do when run as 'debian/rules build; fakeroot debian/rules binary'
<cjwatson> both are valid
<cjwatson> it's possible for something never to fail in Launchpad builds but still be buggy
<mdke> ok, so we should get it fixed. I'll ask Daniel if he knows how
<mdke> i haven't got a clue
<ompaul> cjwatson, btw figured that thing out - it was not looking for a proxy server so it hung on a network where there was a proxy server - solution - install while not networked -
<infinity> mdke: A quick look at the build log would lead me to believe that some sort of configure script is running in the "clean" target, rather than the "build" target.  Since dpkg-buildpackage runs "clean" before "build", it works, but autopkgtest doesn't do so (so is stuck with the configured variables from the "clean" run right before the source package was built).
<mdke> infinity: aha, that sounds very helpful, thanks.
<infinity> mdke: A look at a launchpad build log confirms that; configure is being run in "clean", not in "build".
<mdke> infinity: great, I've added that to the bug report.
<mdke> cheers
<seb128> mdke: speaking about gnome-user-docs, are you going to update it to the new gnome version?
<mdke> seb128: I've filed the bug for sponsoring already :)
<seb128> mdke: good, let me look at it
<azeem> soo, would be possible and welcome to update opensync-related packages to 0.22 for hardy, or is it too late now?
<mdke> seb128: bug 201955
<ubotu> Launchpad bug 201955 in gnome-user-docs "Sync from upstream" [Undecided,New] https://launchpad.net/bugs/201955
<seb128> doh
<seb128> it's in bzr
* slangasek changed the topic of #ubuntu-devel to: Archive: Beta freeze | 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 | glibc broken: https://launchpad.net/bugs/201673
<seb128> I'll let dholbach do it tomorrow ;-)
<seb128> slangasek: are we frozen now?
<mdke> seb128: ok! Maybe he will fix the issue we talked about above too, I mailed him about it
<slangasek> seb128: ... as soon as I can find the actual button in launchpad...
<StevenK> Haha
<seb128> slangasek: ok, in a few hours then ;-)
<slangasek> I think it may have moved in the intervening months while we were doing soft freezes :/
<TheMuso> slangasek: thank you.
<mdke> it will be big, and red
<compbrain> Can you make make-kpkg give you a source package instead of a binary
<LaserJock> slangasek: so I wasn't totally sure, but does Beta Freeze apply just the same to Universe this time?
<slangasek> LaserJock: beta freeze applies to universe in the sense that it's a hard freeze so all packages have to go through it
<slangasek> I'm not planning on subjecting universe packages to any additional scrutiny during the beta freeze, though; I think we've always considered it a bug that freezing can't be done per-component
<ogra_cmpc> oh, you really will freeze tonight ?
<slangasek> ... yes? :)
<slangasek> *if* someone can push the button for me, turns out the reason I can't find it is because of a permissions issue
 * ogra_cmpc goes to make more coffee then ... having lost half the day due to not being able to build ltsp chroots didnt help much :/
<persia> LaserJock: For gutsy, we treated BetaFreeze as guidance for universe, and RCFreeze as requiring motu-uvf approval for freeze exceptions.  For hardy, we likely want to take special care for xubuntu and ubuntustudio.
<LaserJock> persia: hmm, we should perhaps have their seeds "germinated" into a list of "don't mess with" for freezes and such
<LaserJock> I'm not sure if their deps would necessarily be easy to spot or not
<LaserJock> but the rest of Universe surely doesn't care about Beta Freeze
<persia> LaserJock: That sounds like a good idea, perhaps asking for approval from xubuntu-dev or ubuntustudio-dev for freeze exceptions.
<persia> slangasek: How painful would an extra check for universe-based CDs be for your processes?
<slangasek> persia: verbose++, please?
<persia> slangasek: How painful would it be for your processes to check that post-BetaFreeze uploads to packages that will end up on xubuntu and ubuntustudio CDs close a freeze exception bug approved by the relevant -dev team?
<infinity> persia: Very.
<persia> Right.  We'll go with peer pressure then :)
<infinity> persia: In the past, we just handed off universe uploads to the MOTU folk for approval.
<infinity> persia: If the MOTU exception team wants to further divide their efforts to look for Xubuntu uploads, that works fine, but I'm not sure the people handling main will have the time to parse all universe uploads for "oh, this might be Xubuntu".
<persia> infinity: I'm just talking about universe.  Packages in main already have to get BetaFreeze exception approval through ubuntu-archive review of the updates during the manual acceptance.  universe is typically waved through, but it might be nice to have a check for the CDs.
<slangasek> if someone could provide a trivial (i.e., reviewable, and not painful to run) script to check whether the package is in one of the universe CDs, it might not slow us down too much to run that
<infinity> persia: Right, but my point is that going from "we traditionally ignore universe entirely and/or offload it" to "we now have to check all universe uploads against a list" is rough.
<slangasek> OTOH, I guess I would expect that most of the universe packages on the Xubuntu CD are maintained by the xubuntu developers, who know what they're about?
<persia> infinity: Agreed, although it seems a sane consequence of allowing CD builds against universe.
<persia> slangasek: Should be: I'd expect the number of exceptions to be fairly low.
<infinity> Having a clever check in the soyuz queue that checked germinate output and tagged anything that will land on a CD with a marker would be cute, but very not doable before release.
<infinity> Writing a screen-scraping filter around the queue tool that did the same thing would also be doable, but only if it's really necessary...
<persia> infinity: Certainly not doable in the queue.  Having an unofficial script to do that is maybe less hard.
<calc> so is firefox broken for everyone else on hardy?
<infinity> (Though I concede that it would also be handy for main as well, so we can see at a glance if an upload will affect a CD build)
<infinity> calc: Works For Me.  Slowly.
<calc> it won't even start for me
<calc> "Could not find compatible GRE between version 1.9b3 and 1.9b3.
<calc> that shows up in xsession-errors
<infinity> calc: And that's too cryptic for you?  Sheesh.  Get a compatible GRE already!
<infinity> (Whatever that means...)
<slangasek> and it's not just that you're running the broken glibc?
<crimsun> firefox-3.0_3.0~b4+nobinonly-0ubuntu1_amd64.deb                                13-Mar-2008 22:06
<persia> Given the timing, let's see if such a script appears by Monday.  If not, it's likely too annoying to change workflow for hardy.
<crimsun> (http://archive.ubuntu.com/ubuntu/pool/main/f/firefox-3.0/)
<calc> slangasek: i don't think i am other stuff still works
<infinity> slangasek: So, we're hard frozen now.  Time to do my final import of the archive and start another test build run?
<crimsun> calc: (I'm assuming you're using that arch - amd64)
<calc> 2.7-9ubuntu2
<slangasek> infinity: yes please
<calc> on i386
<slangasek> calc: ok, that's the !broken one :)
<slangasek> I don't know then
<calc> my laptop is just i386 since amd64 doesn't resume on it
<crimsun> calc: and you're /certain/ both the xulrunner and firefox-3.0 packages are ~b4 ?
<calc> crimsun: checking
<calc> oh no my mozilla is still b3 for whatever reason
<crimsun> (e.g., check  dpkg -l |awk '/^ii(.)*~b4/ {print $2}' )
 * calc sees if the mirrors have b4 yet
<calc> ah now they do
<crimsun> they do for amd64, i386, and powerpc
<calc> apparently it pushed out a bit later than xulrunner so i didn't get it yet
 * cjwatson breathes a sigh of relief
<calc> sorry for scaring everyone :)
<cjwatson> I don't think I could have coped with firefox blowing up today
<calc> i don't guess a tight dependency isn't wanted for it?
<cjwatson> firefox-3.0 depends: xulrunner-1.9 (>= 1.9~b4~)
<cjwatson> ah, but
<calc> but xulrunner doesn't conflict with old firefox
<cjwatson> xulrunner-1.9 Breaks: firefox-3.0 (<< 3.0~b3)
<cjwatson> that should be b4
<calc> ah
<cjwatson> could you file a bug on xulrunner-1.9 for that?
<calc> ok
<calc> once i get firefox running again :)
<calc> should be in a couple minutes
<cjwatson> only affects intra-hardy upgrades, but still
<calc> yea
<slangasek> infinity: it may be advantageous for you to wait a few days before starting the rebuild tests, actually, since I'll be having my first look at o-o-d packages since the last alpha starting today and we might hammer some of those out without you needing to get duplicate failure reports
<Amaranth> o-o-d?
<crimsun> calc: I'll reopen, retitle, and reassign 201938 for that purpose
<infinity> Amaranth: out-of-date.
<Amaranth> thought so
<calc> crimsun: ah ok :)
<infinity> slangasek: I'm happy to hold off until Mondayish, if that gives you enough time to try to get some archive settling.
<infinity> slangasek: Should give me fewer failures if I have a few more build-deps in sync by then too.
<infinity> slangasek: (Every rebuild test seems to happen right after a new GNOME or new KDE, which invariably leads to dozens of false positives I need to filter through due to arch any/all sync issues)
<crimsun> calc: d'oh, I pasted right after you ;)
<slangasek> infinity: right
<seb128> slangasek: should we ask you before uploading thing or do you review things in the queue once uploaded?
<slangasek> seb128: if you're comfortable that it's sane, please upload and let the review happen in the queue; otherwise it's basically a double-review
<infinity> seb128: I tend to prefer the "upload, then ask permission" workflow, as it's a bit faster than hunting people down before you upload (and with a hard freeze, it's trivial to reject).
<slangasek> if you have doubts about whether it's sane, ask so that you don't spend a lot of time preparing packages that I'll reject :)
<infinity> slangasek: Oh, but since I exercise my core-dev hat about once per release now, I should ask exactly *who* I'm asking permission from after I upload. ;)
<infinity> slangasek: Just you?  Any of ubuntu-release (excluding the uploader)?
<slangasek> any of ubuntu-release excluding the uploader, yes
<slangasek> though anyone other than me has the luxury of passing the buck :)
<infinity> slangasek: :)
<seb128> would "Use printing devices" be a good description for lpadmin in users-admin?
<seb128> that's for the list of groups in which ones the user is
<infinity> Can only lpadmin write to printers?
<slangasek> seb128: I guess by "printing devices" you mean "printer device nodes"?
<seb128> anybody giving an opinion can run users-admin, unlock, click on add and look the list there
<infinity> If so, I suppose "Access printers" "use printers" "print stuff" all work. ;)
<seb128> slangasek: "Use printers"? ;-)
<slangasek> (I wouldn't phrase it either of those two ways; the first is ambiguous -- what is a "printing device" but a "printer", the second is too jargony)
<slangasek> seb128: yes, that's what I would've written :)
<seb128> ok, thanks
<infinity> "Transfer information from RAM to paper".
<infinity> seb128: "Use audio devices" suffers from the same problem, sort of, but it's harder to rewrite than "Use printers"...
 * infinity shrugs.
<slangasek> "Use printers" "make noises"
<infinity> Hah.
<infinity> I can make noises all I want without any UNIX perms!
<seb128> "click there to get a working computer"
<infinity> *unf*
<StevenK> chmod a-rwx infinity
<seb128> slangasek: gnome-system-tools uploaded if you want to review it, I've added lpadmin to list of known groups so it can be used when adding users and did some quick description and patch cleaning which should not be an issue
<crimsun> for straight syncs from Debian, at this point should I still be filing a bug/subscribing ~ubuntu-archive?  I'd think it's lighter to request a sync of gst-pulse from sid, which fixes bug 189854
<ubotu> Launchpad bug 189854 in gst-pulse "sound is complete noise when pulseaudio is running" [Low,Incomplete] https://launchpad.net/bugs/189854
<slangasek> seb128: ok; it's not in the queue yet and I'm working through other stuff at the moment, but I'll certainly review it later.  OOI, is this change in response to a bug?  I can't see why a user needs direct access to printer devices
<slangasek> or are printer devices the issue, either?
<seb128> bug #152107
<ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed] https://launchpad.net/bugs/152107
<seb128> the non lpamdin users can't modify the cups config
<seb128> which means likely they can't add printers, etc
<slangasek> seb128: ah, so really "Manage printers" might've been a better name, ohwell :)
<infinity> crimsun: If a sync will be bugfix-only, and pretty much the same upload you'd make by hand to Ubuntu, yes, still request syncs, but they'll need RM approval and such now.
<seb128> slangasek: hum, right
<seb128> slangasek: can you reject the upload?
<crimsun> infinity: nod.
<seb128> I'll do an another one
<infinity> crimsun: So the syn requests should include full debdiffs, and you should notify slangasek and friends.
<seb128> "Configure printers"?
<seb128> or is manage better there?
<infinity> Configure, Manage, something like that.
<infinity> Needs to be clear that you don't need to be in lpadmin to USE printers.
<seb128> right
<infinity> (WHich is why I asked earlier "You need to be in lpadmin to print stuff?")
<seb128> I've changed to configure now
<infinity> Do we have GUI tools for lpadmin to mangle print queues?
<slangasek> seb128: rejected, cheers
<infinity> (ie: deleting jobs owned by other users, etc)
<infinity> seb128: ^^
<slangasek> infinity: yes, the cups tools
<infinity> seb128: If so, "Manage" is more correct.
<infinity> seb128: "COnfigure" would be just about "creating printers, and changing their settings".
<seb128> infinity: run system-config-printer
<seb128> and tell me what you think he does exactly ;-)
<infinity> seb128: I have no printers, so it's all a bit opaque here. ;)
<infinity> seb128: But if I can mangle print queues (vorlon says yes), then I'd prefer "Manage" to "Configure".
<StevenK> That's the best number of printers to have.
<infinity> seb128: Since "Manage" encompasses "set up printers", "changes settings", and "fiddle with printer-related stuff, like active jobs".
<seb128> "Configure and manage printers"?
<infinity> seb128: "Configure" just sounds like setup, not ongoing job management.
<seb128> I hate having to decide on labels
<slangasek> I think "configuration" is a subset of "management"
<seb128> or does manage include initial configuration?
<slangasek> so "Manage printers" should be sufficient
<seb128> ok
<seb128> thanks
#ubuntu-devel 2008-03-14
<infinity> seb128: I'm with vorlon.
<infinity> And this is why openjdk is evil.  Run a few test builds in the background, and I have nothing better to do than have OPINIONS in #-devel...
<slangasek> heh
<seb128> ok, gst reuploaded
<slangasek> well, that's nice; I try to reproduce bug #149791 using the 'test' button in gstreamer-properties, and X crashes
<ubotu> Launchpad bug 149791 in xserver-xorg-video-ati "Black & White Video Output (Gutsy)" [Undecided,Invalid] https://launchpad.net/bugs/149791
<slangasek> moral: only try to reproduce milestoned bugs of >= high importance
<Hobbsee> anyone fixing scim yet?
<TheMuso> Hobbsee: There was an upload for it not long ago.
<Hobbsee> TheMuso: ubuntu3, or?
<Hobbsee> ah, yes, i see
<slangasek> "fixing" is such a subjective thing
<superm1> glancing over https://edge.launchpad.net/ubuntu/+source/scim , I don't suspect what Hobbsee meant was resolved, that being that it lives in the tray and won't die?
<slangasek> she may mean that ubuntu3 failed to install at all because I'm a putz
<Hobbsee> superm1: i meant the latter
<Hobbsee> for the former, i've purged scim off the face of the planet, so i don't care.
<superm1> Hobbsee, ah okay.
<superm1> haha
<Amaranth> hrm, apport removed the need-i386-retrace tag from bug 202021 but didn't do the retrace
<ubotu> Launchpad bug 202021 in compiz "compiz.real crashed with SIGSEGV in updateWindowAttributes()" [Undecided,New] https://launchpad.net/bugs/202021
<Amaranth> s/apport/retracer/
<Amaranth> oh, that core dump looks bad, only 11kb
<StevenK> Shouldn't compiz core dumps be full of 3D textures and bling? :-P
<Amaranth> my worry is that a patch i wrote changed one call to updateWindowAttributes and added another one and now i've got my first ever crash report in updateWindowAttributes
<StevenK> Heh
<pitti> Good morning
<Mithrandir> hm, I wonder if we should move the gzip level in initramfs from -9 to -6.  On my initramfs here, the size then changes from 8763263 to 8847664 bytes which is an increase of almost 1%, but the time to create it goes from ~15s to ~2.5s.
<nepbabu> where should i ask loco related questions?
<nepbabu> where should i ask loco related questions?
<seb128> slangasek: any reason you didn't accept the g-s-t changes?
<slangasek> seb128: mental backlog
<seb128> ok, that's a good reason ;-)
<pitti> seb128: http://launchpadlibrarian.net/12662959/buildlog_ubuntu-hardy-i386.gtk%2B2.0_2.12.9-2_FAILEDTOBUILD.txt.gz looks weird
<pitti> seb128: looks like a pkgstriptranslations bug
<pitti> but it seems something in gtk+2.0 changed recently
<seb128> pitti: give it a retry?
<pitti> seb128: I already did
<pitti> it failed again
<seb128> pitti: -1 and -2 have only extra includes to avoid an implicit definition change
<pitti> the .mo files seem to be dangling symlinks or something like that
<seb128> pitti: doesn't make sense, did you change pkgstriptranslations recently?
<pitti> seb128: on Feb 28, but only the conffile (not strip restricted any more)
<pitti> the last pkgstriptranslations script change was on 27 Mar 2007
<seb128> pitti: weird, gtk built 3 days ago
<seb128> and as said that's only an implicit declaration fix in the new revision
<pitti> right, I believe you
<pitti> seb128: certainly new glibc :)
<seb128> I've no idea about the issue
<seb128> yeah ;-)
<pitti> seb128: anyway, I'm not sure whether I already gave back that one
<pitti> I'll try it again
<pitti> and if it fails again, I'll build it locally with pkgbinarymangler
<pitti> but need to do some archive admin first
<seb128> the build 3 days ago failed and I asked you to try I think
<seb128> and that worked
<pitti> anyone attached to aptitude? needs libcwidget0 -> libcwidget3 transition
 * pitti pokes that one
<slangasek> it needs a new upstream version to be buildable against libcwidget3 :/
<slangasek> (or a backport of some sort)
<pitti> erk
<slangasek> I tried to pin it on doko since he did the cwidget merge, but he's fled to Texas :)
<seb128> slomo: ^ discussion just before about gtk
<slomo> oh, good ;)
<pitti> so mono-tools still b-deps on libxul-dev, although the changelog says "build against firefox"
<pitti> geser ^
<pitti> oh, not online
<slomo> pitti: do you want to get rid of gtkhtml3.8 from main for hardy (iirc libgtkhtml2.0-cil was the last rdepend)? requires new upstream versions, a NEW package and getting that NEW package to main ;) oh, and a patch for f-spot (and another universe package)
<pitti> oh, tempting
<pitti> slomo: new source? or just new binary of libgtkhtml2.0-cil?
<pitti> sounds pretty intrusive, though
<pitti> so maybe at least not for beta
<slomo> pitti: new source... gnome-desktop-sharp2 + new binary packages from that one (it's in debian/experimental atm)
<slomo> pitti: for beta of course not, the changes are not exactly small... if it wasn't for getting an old package removed it wouldn't even ask you for hardy ;)
 * pitti hugs slomo
<pitti> we should definitively look at it at least
<slomo> pitti: well, i can only say that things work fine for me ;)
 * pitti looks at rpm, which was uploaded with a broken patch
<slangasek> not a broken patch... a completely absent patch \o/
<pitti> right
<pitti> slangasek: permission to upload that? it just more or less restores ubuntu4
<slangasek> pitti: yes, you don't need to ask permission for those kinds of fixes
<pitti> ok, thanks
<dholbach> good morning
<seb128> hey hey dholbach
<dholbach> heya seb128
<pitti> seb128: so, a good deal of the gnome related FTBFS on sparc are due to xulrunner-1.9 not building on sparc
<Mithrandir> is it just for me that firefox is failing to load any pages?
<Mithrandir> ah, no
<Mithrandir> firefox suddenly picks up the gnome proxy settings.. that's.. unfortunate.
<Mithrandir> oh, it can be turned off
<cjwatson> Mithrandir: I like that idea; it's a very noticeable part of the install process
<cjwatson> Mithrandir: (update-initramfs and gzip -6)
<cjwatson> needs a comment though :)
<pitti> slangasek: shall I update ubuntu-meta or are you on it?
<Mithrandir> cjwatson: should I just fix it?  It looks harmless enough and the impact is tiny.
<cjwatson> Mithrandir: the drop from me is only from 15 to 10 seconds rather than 15 to 2.5, but still
<cjwatson> and an increase of 37KB
<Mithrandir> my test was on amd64
<cjwatson> Mithrandir: I think so. Just drop the -9 (since -6 is the default) rather than explicitly selecting?
<Mithrandir> yeah, might make sense.
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<pitti> Mithrandir: btw, bug 195305 is waiting for a comment from you
<ubotu> Launchpad bug 195305 in stardict "Please sync stardict 3.0.1-1 (universe) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/195305
<Mithrandir> pitti: I asked lool to pick that up.
<tkamppeter> pitti, it seems that Saivann and me have hit a real bug in the Launchpad upload mechanism.
<pitti> thanks
<pitti> tkamppeter: --verbose ?
<tkamppeter> pitti, it is about bug 202072, the upload of the Brother drivers.
<ubotu> Launchpad bug 202072 in ubuntu "FreezeException for brother-lpr-drivers-* packages" [High,Fix committed] https://launchpad.net/bugs/202072
<Mithrandir> cjwatson: the full update-initramfs time goes from 17.6s to 11.1s for me, so that's in line with what you're seeing.
<pitti> tkamppeter: right, I see the packages in the queue; I'll get to them
<tkamppeter> For the packages brother-lpr-drivers-laser, brother-lpr-drivers-laser1, brother-lpr-drivers-mfc9420cn, and brother-lpr-drivers-common I get a reject with "MD5 sum of uploaded file does not match existing file in archive" twice.
<cjwatson> tkamppeter: they look like duplicate uploads
<cjwatson> brother-lpr-drivers-laser1 was already in the archive, and then an upload arrived for the same version; brother-lpr-drivers-mfc9420cn was already in the archive, and then an upload arrived for a lower version
<tkamppeter> Saivann got also the same error when uploading to his PPA. So I rebuilt the source package files with "debuild -S -sa" and signed again to regenerate all checksums.
<cjwatson> the others are already in the archive too
<cjwatson> why is Saivann trying to upload them again
<cjwatson> ?
<soren> Ok, I'm getting confused trying to answer this myself... When exactly is grub's device.map used and for what?
<pitti> tkamppeter: right; you need to reuse the current orig.tar.gz, or (if you really need to change it), rename it
<tkamppeter> cjwatson, Saivann has done corrections on them, and probably he did not really know about that some of them were approved and so he still worked on the versioning concept for them.
<pitti> tkamppeter: e. g. 2.0.1-2 or 2.0.1-1+1 or so
<soren> It maps between the devices as seen by the BIOS and what the OS calls it. I get that, but when is that needed, exactly?
<pitti> tkamppeter: (btw, unusual that upstream versions have -1 in them)
<seb128> slangasek: tracker uploaded which desactive indexing and watching by default as decided by the technical board
<tkamppeter> pitti, so I think you should answer to Saivanns mail from 03/13/2008 09:25 PM CET telling him about the correct versioning, file naming, and also giving him a list of what is already in the archives, so that he can recreate his packages to get a working update of what is already there.
<pitti> tkamppeter: can you do this, please? I'm really busy ATM
<pitti> tkamppeter: apt-cache showsrc tells you which are already in the archive; or rmadison
<pitti> apt-cache search/show for the binary packages
<tkamppeter> pitti, no problem, I will lead him through all the Debian concept stuff for his packages getting in, or I will simply overtake packaging for now, as all brother-printer-specific is in, I only need to put the Debian layer over it.
<pitti> tkamppeter: ok, thanks
<tkamppeter> pitti, all will be ready today in the afternoon or during the next week. Saivann has done well for now and the next step of the MOTU course for him will follow later.
<zdzichuBG> ouch, no LTS for SPARC? sad.
<tkamppeter> Saivannn is already very close to getting MOTU ...
<pitti> slangasek: bug 200785 looks reasonable to me
<ubotu> Launchpad bug 200785 in xserver-xorg-video-nv "please sync from Debian unstable" [Undecided,New] https://launchpad.net/bugs/200785
<tjaalton> pitti, slangasek: I have a fix for bug 201596, the textured video was not turned off by default like it should've been
<ubotu> Launchpad bug 201596 in xserver-xorg-video-intel "xv is not working on intel when using compiz" [Undecided,Confirmed] https://launchpad.net/bugs/201596
<tkamppeter> pitti, MOTU lesson to Saivann is on its way (you are CCed) ...
<tkamppeter> Anyone knows how to proceed if spam comments are added to bugs?
<tkamppeter> Like the last comment in bug 43824?
<ubotu> Launchpad bug 43824 in foo2zjs "HP Laserjet 1000 doesn't work with cups2 (dup-of: 65618)" [Medium,Fix released] https://launchpad.net/bugs/43824
<ubotu> Launchpad bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix released] https://launchpad.net/bugs/65618
<tkamppeter> Can I subscribe this bug to a special admin team or so?
<elmo> tkamppeter: ask in #launchpad - or ask a question on answers.launchpad.net on the launchpad product itself
<tjaalton> pitti, slangasek: I uploaded the new -intel, the change was a oneliner
<tjaalton> and tested
<asac> pitti: is saivann your motu student?
<asac> tkamppeter: or your?
<asac> ^^
<pitti> ATM, rather tkamppeter's
<pitti> but I occasionally chime in with some hints
<PecisDarbs> crap, newest updates for fglrx makes my Radeon Mobility go black blank
<pitti> ogra_cmpc: python-ltsp wants to go to universe, is that ok?
<ogra_cmpc> yup
<ogra_cmpc> its only used by tools that are not even uploaded
<ogra_cmpc> thin-client-manager should be in the demotion list as well though
<pitti> ogra_cmpc: hm, it's not
<ogra_cmpc> ugh
<pitti> -- hardy/main i386 deps on thin-client-manager-gnome:
<pitti> edubuntu-desktop-kde
<pitti> student-control-panel
<ogra_cmpc> yeah
<pitti> -- hardy/main amd64 deps on thin-client-manager-backend:
<pitti> edubuntu-desktop
<ogra_cmpc> just saw that (thus the ugh)
<ogra_cmpc> i was aware about the backend ...
<ogra_cmpc> but not that -kde depends on -gnome :P
 * ogra_cmpc fixes seeds
<pitti> ogra_cmpc: while you are at it, italc wants to go to universe, too
<pitti> ogra_cmpc: I assume that needs to be seeded as well?
<ogra_cmpc> yup
<pitti> lool, seb128: gnome-vfs-obexftp wants to go to universe; seed or demote?
<pitti> (or should it be a dependency?)
<ogra_cmpc> i wonder if i keep tcm in ship ... hmm
<pitti> Riddell: kde-style-polyester and ksplash-engine-moodin want to go to universe; is that ok?
<jdstrand_> hi mvo!
<jdstrand_> mvo: I know that apt-get dist-upgrade is not officially supported-- is aptitude full-upgrade, or should we always use do-release-upgrade?
<lool> pitti: Hmm I wonder whether the gvfs version is pulled
<lool> I think it is
<jdstrand_> mvo: (this is from release-release, eg gutsy-hardy)
<pitti> lool: ?
<lool> pitti: This package has been requested for a long long time to allow people to browse phones or other bluetooth devices from the bluetooth applet
<pitti> lool: right, I dimly remember the MIR
<pitti> lool: so I assume it should become a dependency of something, or be seeded into desktop?
<lool> pitti: What I'd like to check is whether we could get the new obex gvfs backend pulled and used by default instead
<lool> There's /usr/lib/gvfs/gvfsd-obexftp
<pitti> oh
<pitti> right, gnome-vfs -> old
 * lool removes gnome-vfs-obexftp
<Mithrandir> pitti: gnome-vfs-obexftp can go, it's old.
<Mithrandir> pitti: new gvfs has obex support built in
<pitti> ok, great
<pitti> demoted then
<soren> I haven't followed the discussion, so I'm not sure what you mean by "remove"?
<soren> Oh, good.
<lool> Failed
<lool> Mithrandir: It works for you?
<soren> remove == demote. Then I'm fine. :)
<lool> Mithrandir: I just tried from the bluetooth applet and it errored in an ugly way
<Mithrandir> lool: iirc, it worked last time I tested, yes.
<Mithrandir> I don't have an obexftp capable cell phone here now.
<mvo> jdstrand_: for dapper->hardy apt-get/aptitude will not be able to do a work dist-upgrade, we need the do-release-upgrade. for gutsy->hardy do-release-upgrade is recommended, but apt-get/aptitude will work (also you need to do the hand-holding manually and read the release notes to e.g. change slocate to mlocate etc)
 * mvo -> lunch
<lool> All my attempts to gvfs-ls failed
<pitti> gosh, is that fam thing *still* in Debian
<pitti> oh, we actually modified glib2.0 in Ubuntu; we should swap the libfam-dev alternatives
<dholbach> sometimes it's hard to let go :)
<sjoerd> pitti: fam is still usefull for nfs mounts apparently
<Riddell> pitti: that's fine, they can go to universe
<pitti> Riddell: thanks
<pitti> TheMuso, Riddell: you actually use festival in Kubuntu? it's still seeded, but in universe
<pitti> and AFAIR it was obsolete (by espeak?)
<lool> pitti, Mithrandir: so it works *only* if you gvfs-mount manually
<lool> But in all cases gnome-vfs-obexftp should be demoted
<lool> sjoerd: I think it's useless on linux systems even if you have nfs
<lool> sjoerd: I understand that inotify is selected no matter what if it's available on the system
<sjoerd> lool: how would you get notifications for directories/files on nfs mounts in linux without fam ?
<lool> Instead of looking whether this is specific to the mount point / directory
<lool> sjoerd: You don't...
<sjoerd> :)
<lool> sjoerd: We were discussing this with Np237 yesterday or so
<sjoerd> ah, and?
<sjoerd> conclusion was, just don't get events and live with it ?
<lool> sjoerd: Well the gnome-vfs patch should be ported to gvfs, but slomo and I told Joss to talk to upstream
<Riddell> pitti: not any more, I'll remove it from the seeds
<pitti> Riddell: thanks
<lool> sjoerd: Conclusion was let upstream now
<lool> *know
 * lool got to run for lunch now
<sjoerd> :)
<slomo> lool: did he already talk with upstream?
<seb128> pitti: I think gnome-vfs-obexftp can go to universe since we use gvfs now, confirm with the mobile team though
<pitti> seb128: right, done above; demoted, thank you
<seb128> you are welcome
<jdstrand_> mvo: ok thanks.  I asked because I had a gutsy vm and tried to upgrade to hardy, and only do-release-upgrade would work. Internal error couldn't configure tzdata (or some such)
<jdstrand_> mvo: if you're interested, I could recreate the gutsy vm and get the exact error (I since used do-release-upgrade and lost the exact message)
<pitti> cjwatson: clock-setup started to depend on rdate-udeb; is that deliberate, or should it actually use ntpdate?
<cjwatson> it's deliberate actually, I've been meaning to ask for a MIR for it
<cjwatson> there was a long discussion which did include ntpdate, though I don't recall why they chose rdate
 * cjwatson tries to find out
<pitti> cjwatson: ok, thanks; if it's deliberate, I'll look at it
<pitti> cjwatson: heh, bug 191224
<ubotu> Launchpad bug 191224 in rdate "Rdate-udeb not installed during installation per clock-setup's dependencies" [Undecided,New] https://launchpad.net/bugs/191224
<cjwatson> it uses it in SNTP mode
<cjwatson> not trad rdate (rfc868)
<lool> slomo: No idea
<pitti> cjwatson: looks harmless enough to me, and Debian maintenance is adequate
<cjwatson> we'd only need the udeb; you could leave the deb in universe
<pitti> cjwatson: I closed the bug for MIR promotion; does it need a d-i rebuild? (in that case I shuold reopen it)
<cjwatson> oh, no, that isn't true, clock-setup would want rdate (deb) when used in ubiquity
<pitti> ok, I promoted the entire source for now
<pitti> (-S)
<cjwatson> clock-setup isn't in the initrd so it doesn't need a d-i rebuild
<cjwatson> thanks!
<cody-somerville> Can someone please push gnumerics?
<pitti> cody-somerville: it's a new upstream version, and doesn't mention any bug report in the changelog
<cody-somerville> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/gnumeric/+bug/199874
<ubotu> Launchpad bug 199874 in gnumeric "[FFe] Please merge gnumeric 1.8.2-1 from debian unstable" [Medium,In progress]
<cody-somerville> pitti, Sorry about forgetting the bug number.
<pitti> ok; it doesn't affect the CDs, so it's safe enough for the beta freeze
<ogra_cmpc> just dont break it ... i use it on the classmate image
<cody-somerville> :S
<cody-somerville> If it breaks, you can slap me around a bit in Prague.
 * Hobbsee slaps cody-somerville around a bit regardless.
<cody-somerville> :)
<tkamppeter> pitti, I have a question to you, for both Saivanns MOTU course and my core-dev course ...
<Hobbsee> there are courses now?
<twi_> pitti hi, is there anything that I could do to help with https://bugs.launchpad.net/ubuntu/+source/elisa/+bug/186647 ?
<ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New]
<mvo> Riddell: do you know about this file overwrite error in koffice: http://paste.ubuntu.com/5677/
<mvo> (gutsy->hardy)
<Riddell> mvo: I do not
<Riddell> mvo: thanks, will fix
<Riddell> mvo: packages on today's CDs seem all good
<mvo> Riddell: thanks
<mvo> Riddell: great!
 * lamont has a spousal-support issue...
<Hobbsee> oh dear
<lamont> so we upgraded her machine from feisty to gutsy finally, and now clicking on links in evo fails to bring up firefox
<lamont> of course, when she had feisty on the machine, it brought up mozilla...
<lamont> so... what do I whack where to teach evo that it should use firefox instead of mozilla.
<lamont> ??
<Hobbsee> system, preferences, preferred apps
<lamont> woot
<Hobbsee> lamont: works?
<lamont> *HUGS*
<Hobbsee> :D
<lamont> and I misspoke.  she had 'custom: mozilla-firefox %s' configured for the web browser
<Hobbsee> yep, that'll do it
<Hobbsee> (open in new tab, in same window, iirc)
 * lamont has no idea which release originally got installed on that machine, but it's been dist-upgraded ever sense
<lamont> since, even
<lamont> root@mitzi:~# which mozilla-firefox
<lamont> root@mitzi:~#
<lamont> actually, it does nothing.
<Hobbsee> it's a transitional package
<lamont> and it's grey'ed out on the screen
<asac> lamont: is that in hardy?
<asac> (aka ffox 3)
<lamont> asac: that's on a $ancient install, dist-upgraded through feisty to gutsy
<lamont> so ffox 2
<lamont> we just finally ran into it being broken.
<lamont> (so, sorry for the support questions for ancient releases (e.g., gutsy) in this channel.... my bad and all that..)
<lamont> OTOH, I married an irish redhead.
<thom> asac: is it know that ff3 occasionally gets bored and starts in offline mode?
<lamont> thom: wtf???
<ogra_cmpc> sounds like a nm problem
<asac> thom: what does networkmanager show you
<asac> thom: how are you online?
<ogra_cmpc> ff queries that now, no?
<asac> yes it does
<asac> thom: there is a known issue that nm doesn't say its "online" if you are using ppp
<asac> thom: if you have such a setup i would be happy to work with you to get it resolved
<thom> asac: wired
<ogra_cmpc> well, you migh proabbly get races if the system is under heavy load and nm doesnt answer in time
<thom> hrm, nm applet claims not to have any network devices
<thom> i guess that would probably do it
<ogra_cmpc> thom, it wont if you defined them in /e/n/i
<asac> thom: please paste your /etc/network/interfaces
<thom> asac: http://pastie.caboo.se/165688
<asac> thom: how does the nm applet icon look like?
<asac> just two black screens?
<asac> or is there a red cross?
<thom> two black screens, triangle with an exclamation mark
<asac> can you please restart network manager and see if it still looks the same?
<asac> you say that its randomly? so sometimes network manager doesn't think its offline?
<wasabi> It seems odd that Ubuntu gives me the option of launching software off of a Windows CD
<wasabi> Which of course does not work.
<thom> it seems like about 90% of the time i get offline mode
<asac> thom: please try to restart network manager to see if the triangle really goes away sometimes
<asac> and file a bug posting your /var/log/syslog ... and your /etc/network/interfaces above
<asac> might be a bug in our eni parser
<thom> k
<thom> i'll play around a bit
<asac> thanks
<asac> would be wired if its really random
<asac> but you never know
<superm1> any particular reason that the manifest is old on http://cdimages.ubuntu.com/daily-live/current/ , but the image isn't?
<thom> clobbering all of /e/n/i means that it sees my wired network at least
<superm1> does this mean the live stuff was generated 2 days ago but just used again in today's image?
<asac> thom: looking at your eni i don't think you really want that
<asac> network manager should do what you attempt to do imo
<thom> i think so too
<thom> but i figured i'd try
 * Mithrandir sighs over the back/forward buttons on the mouse being broken in latest firefox.
<dholbach> hum.... does anybody with an x40 have no working volume-up / volume-down display in hardy?
<soren> dholbach: Works for me.
<dholbach> hrm
<dholbach> how do I do the "grab keycode" thing again?
<soren> dholbach: Running metacity, though.
<soren> Won't work.
<Mithrandir> dholbach: xev?
<soren> It doesn't emit keycodes, afair.
<dholbach> you'Re right, it doesn't
<dholbach> thanks Mithrandir
<soren> It just changes the volume which "something" notices.
<dholbach> somehow I don't get the fancy onscreen dialog anymore
<dholbach> ahhhh ok
<ogra_cmpc> dbus-monitor might help
<ogra_cmpc> but you need some sane filtering i guess
<ogra_cmpc> (wherever the event comes from, it will go through dbus)
<\sh> cjwatson: I replied on your mail to u-d-d about the ldflags story...to claim it here, no I didn't press anyone to investigate in this, because I thought those settings were tested at least with our toolchain/libc chain..
 * \sh always thinks it's just him who stumble upon those probs...
<cjwatson> \sh: we had done a test rebuild of glibc, but as it turns out the test rebuild didn't build anything else *against* that glibc build
<cjwatson> \sh: the next test rebuild will use its own output where it can, I'm told, to increase the chance of catching these problems
<dholbach> ok... at least the sound works again
<dholbach> (skype doesn't but that's probably unrelated :))
<pitti> tkamppeter: re
<pitti> twi_: right, I'll look at those today
<twi_> pitti great
<\sh> cjwatson: well, all this can happen...if I had known what were the flags I would have searched earlier on in wines bugzilla for this damn bug with strange LDFLAGs ;) anyways...the next time we know what to do :)
<cjwatson> \sh: I wasn't trying to interrogate you, FWIW; I just want to gather as much information as I can about the events leading up to this
<cjwatson> although if you ask "why didn't somebody else notice this", your own actions are relevant too :-)
<Keybuk> I noticed it when libc broke :)
<Keybuk> which is, after all, the whole point of open development releases
<sistpoty|work> to break libc? *g*
<\sh> cjwatson: yeah...but even reading the changelogs of all important uploads (dpkg, gcc etc.) after wine 0.9.54 wasn't giving me any clue about the real bugger...and TBH we were walking in the dark...(actually I never watched closely to the output of LDFLAGS setting during builds)
<Keybuk> sistpoty|work: to have lots of people testing them, so when things inevitably break, we know about them
<sistpoty|work> Keybuk: sure, was just kidding... sorry if inappropriate
<Lamego> Keybuk, the point is to keep it working, not breaking, breaking in an unexpected event :P
<Keybuk> Lamego: ish, the point is to release something that's working
<\sh> Keybuk: I think it would be cool to have a PPA for changes to dpkg, e.g. for testing sane flags, as it was introduced, because those little flags can make a real difference ;)
<Keybuk> \sh: they were discussed for ages before introduction
<Keybuk> with some of the foremost experts debating it
<Keybuk> we didn't know of anything that would break
<Keybuk> now we know what does :)
<\sh> Keybuk: do you have a pointer of the discussion or actually the flags being discussed, because reading the wiki page about it wasn't enough for me to get the changes
<Keybuk> not off-hand, I only briefly took part in it
<cjwatson> it was discussed at UDS
<Keybuk> in fact, I think my entire contribution was "is that like -Bsymbolic, but just for functions?  neat"
<Amaranth> that reminds me, anyone ever figure out why icedtea is broken on amd64 when built by the buildds?
<Amaranth> has been since gutsy
<Keybuk> tbh, I don't see why the libc problem has as much attention as it does
<Keybuk> to me, it was a perfectly ordinary "development event"
<xhaker> Amaranth: isn't the current plan to get openjdk-6 replace icedtea?
<\sh> cjwatson: yes, I would have guessed, as it's written on https://wiki.ubuntu.com/DistCompilerFlags but not "what will change, what are the real flags etc." and people knowing about stuff which was discussed at UDS without attending (even remotely) is somehow not possible ;)
<\sh> Keybuk: well, it was fun for people not prepared for those things ;)
<Keybuk> \sh: the discussions at UDS are streamed on both VoIP and icecast
<Keybuk> \sh: if you're running a development release, you *should* be prepared
<Keybuk> I know that I've personally rendered past development releases unupgradeable (I broke dpkg) and unbootable
<Amaranth> xhaker: I imagine it'll have the same problem
<\sh> Keybuk: not everyone can sit at work and listening to voip / icecast streams...so I wonder if it's feasable to document the outcome of those discussions after those changes are settled
<Amaranth> Keybuk: Yeah, thanks for that, by the way :P
<xhaker> Amaranth: what kind of broken are you experiencing?
<Amaranth> xhaker: bug 152362
<ubotu> Launchpad bug 152362 in icedtea-java7 "icedtea-java7-plugin always crashes firefox" [High,Confirmed] https://launchpad.net/bugs/152362
<\sh> Keybuk: and actually I was amused about the borked glibc...because I was waiting for this all the time during hardy cycle ;)
<cjwatson> \sh: indeed, that spec says that LDFLAGS will be empty by default and so is actively wrong
<cjwatson> I'll edit it now to reflect reality
<cjwatson> Keybuk: this was interesting because it was simultaneously unupgradeable and unbootable
<dholbach> thekorn, bdmurray: could it be that the text interface's milestone filtering is broken?
<Keybuk> \sh: isn't that exactly what the specification attempts to do?
<Keybuk> (note - attempts)
<dholbach> thekorn, bdmurray: you can try bug 95168 (which is milestoned as 'later')
<ubotu> Launchpad bug 95168 in update-manager "please make distro-specific strings a build-time parameter" [Wishlist,Confirmed] https://launchpad.net/bugs/95168
<Keybuk> specifications can only ever accurately represent the precise way in which we're *not* going to do it
<jeromeg> I would love to be able to have my local bash as a contact in pidgin. Thatâd be awesome ^_^
<jeromeg> â¦just randomly thought of that.
<jeromeg> Oh yeah, weâll get that after we dismantle the window paradigm; nevermind. That may be a whileâ¦.
<jeromeg> sorry
<jeromeg> wrong window
<\sh> Keybuk: it should do, yes, actually, as cjwatson correctly stated, the spec says something else...and I wonder if anyone else saw the change in those settings directly when building the packages ;) even with buildlogs mailed to my inbox I'm only interested in other things then LDFLAGS flowing down the screen ;)
<thekorn> dholbach, let me check this
<\sh> keybuk: I'm trusting my toolchain providers too much instead of questioning them :)
<\sh> anyways problem solved...solution found :)
<dholbach> thekorn: hum, it doesn't seem to work in html either
<thekorn> dholbach, hmm, looking
 * dholbach hugs thekorn
<pitti> cjwatson: what was the way again to 'unrescue' a package from component-mismatches? g77-doc pulls in the entire gcc-3.4, so I demoted it, but britney still wants both back
<pitti> (we want gfortran-doc in main only, and it's just a metapackage anyway)
<cjwatson> extra-exclude
<pitti> ah, thanks
<cjwatson> in supported
<cjwatson> you'll need it in all supported seeds though :-/
<thekorn> dholbach, can you please file a bug, I will add a fix for the text interface soonish
 * dholbach hugs thekorn - will do! :)
 * thekorn hugs dholbach bach, thanks
<thekorn> back, even
<dholbach> thekorn: instead of using True/False in task.remote would it make sense to assign it the URL of the watch?
<dholbach> "if not task.watch:" would still work :)
<thekorn> dholbach, you are right, that makes sense as this information is available in both interfaces
<dholbach> ROCK :)
<tkamppeter> pitti, are you still there?
<pitti> tkamppeter: yes
<tkamppeter> pitti, Is there a possibility to directly pass over packages from a user's PPA to multiverse or universe? Or do I always need to download the files to my local box?
<pitti> tkamppeter: if they have the correct version number, we can copy them
<cjwatson> last I checked, we couldn't copy binaries from a PPA
<cjwatson> just the source
<cjwatson> (but that might be OK
<cjwatson> )
<pitti> right, but I think that's sufficien tfor tkamppeter
<pitti> cjwatson: that's still true, BTW
<cjwatson> good!
<tkamppeter> pitti, I have now downloaded the Brother drivers from Saivanns private site, signed, and then dput them to multiverse.
<tkamppeter> pitti, as dput has the possibility to supply the URL pf a source.changes file, one should be able to transfer packages directly from server to server with it.
<tkamppeter> Are the source.changes files of the uploaders available in PPAs?
<sistpoty|work> tkamppeter: they have been, but that was a nasty security bug (I could grab your changes file and source package and upload that to ubuntu then)
<cjwatson> you don't need them; we have other ways to copy source packages from PPAs to the main archive
<tkamppeter> cjwatson, have I as a MOTU access to them?
<cjwatson> no, it's an archive admin operation
<cjwatson> you can request it though, like you would a sync
<cjwatson> (and it's really just a different kind of sync)
<tkamppeter> pitti, all the four packages were accepted by the system and are now in "Waiting for approval" state.
<cjwatson> in future we hope that Launchpad will offer a UI for it, since there's no intrinsic reason for it to be a restricted operation other than the current implementation being a shell command from a privileged account
<ogra_cmpc> pitti, http://ftp-master.debian.org/new/squeak-vm_3.9.12+svn1820.dfsg-1.html :D
<ogra_cmpc> looks like debian solved our license prob :)
<pitti> oh, that's an awesome web view of Debian NEW
<ogra_cmpc> that as well
 * ogra_cmpc was a bit to much  intrested in the content to notice :)
<cody-somerville> mdz, Can you think of a less awkward solution?
<cody-somerville> mdz: (re xubuntu seeds)
<mdz> cody-somerville: not really.  the way launchpad does access control for branches makes this awkward
<mdz> cody-somerville: I emailed the relevant developers and pointed to this as something which is awkward in Launchpad today
<mdz> I believe there is a plan for separate ACLs at some point
 * cody-somerville nods.
<pitti> Riddell: can you please commit your casper 1.121 to bzr and re-merge my 1.121 upload/commit to be 1.122?
<pitti> I just got a rejection message about 1.121 already existing
<Riddell> erm, I didn't commit?
<pitti> maybe you forgot to push?
<pitti> seb128: I'm test-building gtk here now, to track down this FTBFS
<Riddell> pitti: pushed
<pitti> Riddell: hm, I'll fix the version number in bzr; your upload was 1.121, not 1.1.22
<pitti> Riddell: oh, or didn't you upload 1.122 yet? ("Fix paths in About Kubuntu links")
<Riddell> pitti: it's in unapproved
<pitti> Riddell: ah, I see; ok, thanks
<annoia> Is glibc still broken?
<jpatrick> annoia: fixed, see #ubuntu+1
<annoia> Oh
<annoia> Thanks
* cjwatson changed the topic of #ubuntu-devel to: Archive: Beta freeze | 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 | glibc was broken, now fixed: https://launchpad.net/bugs/201673
<pitti> geser: I tried to quick-fix mono-tools, but a simple s/libxul-dev/firefox-dev/ isn't sufficient; it FTBFSes; any idea?
<pitti> pochu: ^ or you?
<pochu> pitti: do you have a log handy?
<pitti> http://people.ubuntu.com/~pitti/tmp/mono-tools_1.2.6-2ubuntu2_amd64.build
<pitti> pochu: (current hardy package dep-waits on libxul-dev which is in universe)
<pochu> isn't firefox-dev in universe as well?
<pitti> it's a metapackge for firefox-3.0-dev now
<pitti> ogra_cmpc: edubuntu-addon-light is supposed to be universe?
<ogra_cmpc> its xfce
<ogra_cmpc> so yes
<pitti> seb128: I think it's an error that libglib2.0-data isn't depended on by anything? in particular not by libglib2.0-0?
<pitti> ogra_cmpc: ok, I'll demote it then
<ogra_cmpc> actually i think i can rip it out completely
<pochu> pitti: then it likely needs some changes to the build system so that it detects gecko 1.9 properly. perhaps asac has already a patch for it, as he has been transitioning the firefox-dev rdepends
<pitti> pochu: it's now one of the three remaining packages in http://people.ubuntu.com/~ubuntu-archive/testing/hardy_outdate.txt
<pitti> (I already fixed human-theme)
<slangasek> pitti: you're welcome to do the ubuntu-meta update if you haven't already, thankfully I was not on it at 2:30 am :)
<pitti> slangasek: done this morning
<slangasek> ok :)
<pitti> seb128: gtk+2.0 builds fine locally, with pkgstriptranslations enabled. WTH???
<pitti> anyway, /me -> off
<\sh> pitti: have a nice weekend :)
<pitti> and you!
<\sh> pitti: going out for dinner with Mrs. Amarok Community Manager ;)
<pitti> oh, heh
<pitti> enjoy
<\sh> while my wife is in cameroon visiting her parents (without me)
<ogra_cmpc> how mean
<\sh> ogra_cmpc: I had to decide...new job or cameroon ;)
<ogra_cmpc> well, would have been clear for me ... but then ... i love my current job anyway :)
<geser> pitti: a s/libxul-dev/xulrunner-1.9-dev/ worked last time I build it but from the last comment on bug 183895 it might be not enough
<ubotu> Launchpad bug 183895 in mono-tools "[hardy] Replace build-dependency on libxul-dev with xulrunner-1.9-dev" [Undecided,New] https://launchpad.net/bugs/183895
<\sh> ogra_cmpc: hehehe...I love my current job too..pushing all software which we use into ubuntu is fun..and pushing ubuntu on our servers is more fun :)
<emgent> hi \sh :)
<\sh> hey emgent
<ogra_cmpc> \sh, do you remember ingo draheim ?
<\sh> ogra_cmpc: hmm...doesn't ring a bell
<\sh> ogra_cmpc: from ish?
<ogra_cmpc> right hand of the ish CTO back then
<ogra_cmpc> anyway, i just heard he and one of my former team colleagues founded a company, selling ubuntu servers and support :)
<\sh> ogra_cmpc: which company?
<\sh> ogra_cmpc: somewhere around cologne?
<ogra> http://www.mydato.de/
<\sh> ogra_cmpc: so this guy http://www.linkedin.com/pub/0/583/776 ;)
<ogra_cmpc> yup
<sistpoty|work> tkamppeter: you uploaded quite strange versioned packages there
<sistpoty|work> (as in new upstream version, but I assume that it should just have been a new ubuntu revision)
<\sh> ogra_cmpc: looks very windows to me ;)
<ogra_cmpc> \sh, grin, i just see he sells the SW he wrote at ish .... (he was never hired as a programmer there)
<ogra_cmpc> yeah all the frontend stuff is VB with office ... but they seem to use ubuntu for infrastucture and server
<\sh> ogra_cmpc: hehe...which is good :)
<ogra_cmpc> yeah, indeed
<ogra_cmpc> \sh, i'm not registered with this account
<\sh> ogra_cmpc: ah :)
<\sh> ogra_cmpc: fire up xmpp ;)
<\sh> s/xmpp/jabber/ :)
<ogra_cmpc> ugh
<ogra_cmpc> i dont even know my login data anymore
<\sh> ogra_cmpc: forget it, i'm leaving in a few...
<\sh> ogra_cmpc: btw..let's talk again via phone...send me your home phone via email or so...or sms me on the number on my imprint on www.sourcecode.de
<ogra> if i only wouldnt be that lazy :P
<vignatti> hi there
<vignatti> is there a channel only for ubuntu mobile?
<\sh> #ubuntu-mobile ?
<vignatti> \sh: ohh, of course :) tkx
<Riddell> does ubuntu include a "File manager as root" menu entry still?
<slangasek> Amaranth: hi, do you know about the xaos merge in the beta freeze queue?  it appears to have dropped the changes from your last upload with no explanation; I'd rather not approve it without your confirmation
<ogra> slangasek, thats mine
<slangasek> ogra: did you know you dropped Amaranth's changes?
<ogra> oh, there were additional changes
<ogra> that was me then
<ogra> meh
<ogra> can you reject ? i'll add that
<slangasek> will do, thanks
<ogra> thankls for the heads up
<Amaranth> slangasek: afaik it was fixed another way
<Amaranth> slangasek: there was another patch to make it skip over visuals with alpha when iterating through them looking for one, it got applied upstream for the next release too
<ogra> Amaranth, you said it was not
<ogra> we discussed that
<Amaranth> i dunno if that is in this package
<Amaranth> we did?
<ogra> yes
<Amaranth> i don't remember this
<ogra> man, youre ten years younger than me ...
<ogra> or even more
<slangasek> Amaranth: I didn't see anything more in the upstream diff that would show this was fixed another way
<Amaranth> the other guy (i'm bad with names) did a one line change to change a 32 to a 31 or something
<Amaranth> https://bugs.edge.launchpad.net/ubuntu/+source/xaos/+bug/192882/comments/13
<ubotu> Launchpad bug 192882 in xaos "Xaos display problem with compiz" [Low,Fix committed]
<Amaranth> that is the patch we should use
<slangasek> ok - that wasn't applied in what ogra uploaded, so a new upload is warranted in any case
<Amaranth> tormod said he included it in the debdiff for the merge :/
<ogra> +  * src/ui/ui-drv/x11/ui_x11.c: added window-id option (LP: #189475)
<ogra> +  * src/ui/ui-drv/x11/ui_x11.c: turn off root/fullscreen if windowid
<ogra> +  * src/ui/ui-drv/x11/xlib.c: fix -root and -fullscreen crashers
<ogra> thats the three non packaging related fixes
<cody-somerville> Can an archive admin push xubuntu-default-settings?
<slytherin> Hi all, I am having strange problem with all xulrunner dependent apps. FF, yelp, debhelp, liferea. The menu in firefox are so bug vertically that I can not use it. And in rest of the apps fonts are too big. I can not read anything. Can anyone tell me where should I look for the reason?
<cody-somerville> Do we now install recommends by default?
<ogra> at least from the cd installs
<ogra> oh sigh
<ogra> slangasek, sorry to be a pain in the ass, can you reject xaos again ? seems joey included stuff from us in 3.2-9 and there is an updated patch as well
<slangasek> ogra: why does that need rejected, though, instead of accepted now and accepted again later?
<ogra> well, indeed
<jdstrand> lamont: sent patch for bug #201954 to lp
<ubotu> Launchpad bug 201954 in bind9 "bind9 apparmor profile does not allow access to /var/lib/bind" [Medium,In progress] https://launchpad.net/bugs/201954
<jdstrand> lamont: hi btw :)
<slangasek> mdke: hrm, how is it that the bug closed in this gnome-user-docs upload is a private bug?
<slangasek> mdke: this package also has a horribly broken clean target, this makes for unpleasant debdiff reviews
<xhaker> raphink: maybe you should remove the revu-tools dep on linda
<AlinuxOS> Hello all, I've filed a bug against Ubiquity. There is no Georgian entry when choosing language: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/202291.
<ubotu> Launchpad bug 202291 in ubiquity "Georgian (ka) á¥áá áá£áá language isn't present on installation menu. " [Undecided,New]
<vignatti> hi huys
<vignatti> *guys
<vignatti> I'm facing a strange noise here in my macbook
<vignatti> it's kind a beep which certainly _doesn't_ comes from the speaker
<vignatti> every time I put a cd in its drive the noise disappears
<vignatti> so I saw in apple forum that whenever some components will be turned off is normal to hear some noise
<vignatti> unfortunately I'm hearing it all the time (when no cd in is
<vignatti> the drive
<vignatti> so I remembered that gutsy (my SO) recently updated the kernel
<vignatti> so, it could be possible that ubuntu is doing something to turn some components off all the time that can be causing that crap noise?
<slangasek> tkamppeter: why is brother-lpr-drivers-laser split into 23 different binary packages?
<slangasek> ... and half of them are empty except for documentation
<sistpoty> slangasek: after some considerations, we're going to do the gfortran transition for universe (bug #201962)... any vetoes from your side for that, as it will involve a few library name changes?
<ubotu> Launchpad bug 201962 in arpack "gfortran transition" [Wishlist,In progress] https://launchpad.net/bugs/201962
<LaserJock> sistpoty: as well as a blanket FFe for that, correct?
<slangasek> sistpoty: hrm?  I thought that transition was well under way?
<sistpoty> LaserJock: right
<LaserJock> slangasek: well under way in Debian for sure
<sistpoty> slangasek: it was started, but only a few packages have done it so far, leaving us in an inconsistent state atm
<slangasek> ok
<sistpoty> (almost finished in unstable, if the wiki can be trusted)
<slangasek> well, no vetoes from me anyway
<sistpoty> slangasek: ok, thanks
<ScottK2> sistpoty: I vote for blanket FFe for version increases needed for the transition.
<sistpoty> ScottK2: so do I
<sistpoty> (better to stay as close to unstable in this case, I guess)
<ScottK2> sistpoty: Then mark it approved and add it to the standing FFe list.
<ScottK2> Yes
<sistpoty> ScottK2: mark what as approved? (there are quite some bugs in the gfortran transition bug... would take some time)
<ScottK2> sistpoty: The global FFe
<ScottK2> I'd just comment it in that bug and add it to our list
<sistpoty> ScottK2: oh, we have a list? (damn, I'm a louse motu-release member, I guess)
<ScottK2> It's linked off the FFe page.
<TheMuso> pitti, Riddell, what package? I'd be happy to look into it, and get it to use espeak instead.
<ScottK2> Just for the standing ones
<sistpoty> ScottK2: almost done, thanks!
<ScottK2> Is it by design or by accident that ufw cannot be removed without taking ubuntu-standard with it?
 * ion_ packaged compcache and made an init script that handles its initialization nicely. I guess the package wonât make it to hardy, though.
<slangasek> it's probably an accident that it's a depends instead of a recommends; but surely ufw is trivial enough to leave it installed when you're not using it?
<ScottK2> slangasek: I have not investigated what knobs it has, what it does by default, or how to turn those knobs.  I've got iptables scripts I'm statisfied with where I feel I need them.
<seb128> slangasek: I"ve sponsored ted gnome-power-manager update to hardy
<jdstrand> ScottK2: it does nothing by default
<ScottK2> jdstrand: OK.
<jdstrand> ScottK2: you have to run 'sudo ufw enable' to turn it on
<ScottK2> jdstrand: Thanks.  I'll mark the bug low then.
<jdstrand> ScottK2: try running '/etc/init.d/ufw start' on your system
<jdstrand> it should say Skipping firewall: ufw (not enabled)
<seb128> slangasek: the new version should be alright and ted did some changes which have been tested and would be better to have in beta to make sure they are working correctly so it would be nice to accept it there
<ScottK2> K.  I will.
<mdke> slangasek: (gnome-user-docs) the bug shouldn't be private, are you sure? As for the clean target, I saw that last night, it's bug 144498 - daniel suggested we fix it in intrepid
<ubotu> Launchpad bug 144498 in gnome-user-docs "autopkgtest gutsy gnome-user-docs: erroneous package!" [Low,New] https://launchpad.net/bugs/144498
<slangasek> mdke: when I tried to go to the LP bug listed in the changelog, I got permission denied
<mdke> slangasek: maybe a typo in the changelog, lemme check
<mdke> slangasek: gah, you're right, it is 201955, not 201995.
<slangasek> I probably wouldn't mind seeing the clean target fixed before hardy, but it's also not urgent
<mdke> slangasek: I don't know how to fix it myself, but I'm happy to pass that onto daniel if he has the time
<mdke> slangasek: do you need the bug number fixed?
<slangasek> mdke: *I* don't, no - it's already been accepted, so it's up to you whether you fix that for the next upload
<slangasek> mdke: in any case, I suppose you need to close the bug by hand :)
<mdke> slangasek: ok, thanks a lot. I will amend it in bzr for the next upload
<blueyed> Is there a replacement for /proc/bus/usb/devices, which has been removed in Gutsy already? bug 156085
<ubotu> Launchpad bug 156085 in qemu "Could not open /proc/bus/usb/devices" [Low,Confirmed] https://launchpad.net/bugs/156085
<blueyed> Well, especially a replacement for /dev/bus/usb/devices seems to be required.
<geser> blueyed: what did it contain?
<blueyed> The best thing apparently might be to enable the commented code, documented as "Magic to make /proc/bus/usb work" in /etc/init.d/mountdevsubfs.sh
<geser> there is /sys/bus/usb/devices/
<blueyed> geser: a list of devices I'd say, see e.g. the upstream report at http://www.virtualbox.org/ticket/747
<proprietarysucks> anyone in here know why ubuntu 7.10 64-bit cannot install over pxe?
<proprietarysucks> we have 606,610,704,710 both 32 and 64 bit and out of all of those systems only 64-bit 710 doesn't work
<mdke> is there any way to find out what Dell do to configure DVD support? It'd be nice to include identical instructions in the system docs and we don't have 100% accurate dvd-enabling documentation right now. is there a way to find out?
<proprietarysucks> I've verified with checksum that it is not corrupted, and in fact re-downloaded and re-checked it
<blueyed> geser: there's a lot more info in /dev/bus/usb/devices - I don't know if you can get that from /sys/bus/usb/devices/
<blueyed> I've re-opened the bug (156085)
<blueyed> (for sysvinit)
<sistpoty> slangasek: I'm still trying to find the right answer to murrayc for https://bugs.launchpad.net/ubuntu/+source/libgdamm3.0/+bug/190744/comments/22 ...
<ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Fix released]
<sistpoty> maybe using -version-info and -release (of libtool) for unstable versions and only -release for stable ones?
<Riddell> TheMuso: no package uses festival, we put it in universe
<TheMuso> Riddell: Yeah but pitti was saying something to do with kubuntu and festival...
<Riddell> TheMuso: yes, he wanted to know if anything used it.  nothing does, so it has been demoted
<stefano> is there a Q&A channel for ubuntu development?
<bdmurray> Riddell: bug 175597 is Fix Released for dolpin but the kdebase affects is still Confirmed is that correct?
<ubotu> Launchpad bug 175597 in kdebase "KDE: Error - KIOExec: error messages when opening links from system menu" [High,Confirmed] https://launchpad.net/bugs/175597
<Riddell> bdmurray: it's actually a fix in kdebase-kde4.  kdebase and dolphin source packages have nothing to do with it
<bdmurray> So the kdebase bit should be Invalid then?
<Riddell> bdmurray: yes
<Riddell> and the dolphin bit
<bdmurray> Okay, thanks.
<proprietarysucks> no one has any idea?
<proprietarysucks> is there some difference to 710 64-bit ?
<lamont> jdstrand: cool
<lamont> jdstrand: does that want to be in for beta?
<Amaranth> mdke: Doesn't Dell just install lindvd?
<emgent> hi cody :)
<cody-somerville> heya emgent :)
#ubuntu-devel 2008-03-15
<sistpoty> could an archive admin please let the ghc6 upload through? thanks!
<nixternal> in sispoty style: could an archive admin please rock out the keurocalc-kde4 upload? thanks :)
<IOU> does anyone find the 2.6.24-12 kernel slower than the 2.6.24-11 ?
<IOU> hrm i joined the wrong room to ask that, My Apologies
<Hobbsee> cody-somerville: re; recommends; only for metapackages
<Hobbsee> Fujitsu: which version of compiz actually worked/
<Hobbsee> was it the last one, uploaded on the 7th, or 2 before/
<Amaranth> eh?
<Hobbsee> Amaranth: the special keys is back again
<Hobbsee> Amaranth: it actually went away for a while
<Hobbsee> now i've hit it twice in less than 24 hours.
<Amaranth> special keys?
<Hobbsee> alt, meta, shift, win, etc
<Hobbsee> press-and-hold, focus
<Hobbsee> there's a bug open.  no one's [been able to, bothered] to track it down.'
<Hobbsee> no caps, either.]
<Amaranth> oh, that's xorg stuff
<Hobbsee> and i can't seem to remember how to downgrade
<Amaranth> compiz can't fix it, it happens with metacity too
<Hobbsee> i know, but i didn't think xorg had changed
<Hobbsee> oh wait, it is
<Hobbsee> er, did
<RAOF> Hobbsee: You mean the bug where when you hold a key down and make a mouse event that key is then permanently pressed?
<Hobbsee> RAOF: i'm holding no key.  but effectively, yes.
<Hobbsee> RAOF: yeah, looks like it.
<Hobbsee> RAOF: i think it's a phantom key though - it doesn't seem to produce any output on the terminal
<Hobbsee> whereas pageup, etc, will just give pageup spam on the terminal
<Fujitsu> Hobbsee: Check using xev next time it happens.
<macogw> Is the Rhythmbox maintainer around?
<macogw> guess not
<jdub> 6.06 mailman security update bug seen?
<jdub>             mlist.subject_prefix = Utils.canonstr(
<jdub>         elif property == 'info':
<jdub> in /var/lib/mailman/Mailman/Gui/General.py
<jdub> makes mailman inoperable (daemon doesn't run)
<jdub> emgent: ping?
<jdub> (oh, that was gusty not dapper)
<mdke> Amaranth: interesting, I haven't heard of that; will investigate
<vik_3278> Hi, is this the correct channel to ask about manual back-porting?
<vik_3278> or is that #ubuntu ?
<vik_3278> no one here?
<jpatrick> vik_3278: #ubuntu-motu
<jpatrick> !weekend | vik_3278
<ubotu> vik_3278: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<vik_3278> kk cheers
<vik_3278> yeah I guess it's the weekend huh.
<jdub> bug mentioned above is #202332
<soren> jdub: What? There's a bug about people not working enough over the weekend? :p
<afflux> apport is just removing the need-i386-retrace tag from bug 201071 :(
<ubotu> Bug 201071 on http://launchpad.net/bugs/201071 is private
<Hobbsee> soren: now that should be filed.
<ogra_cmpc> asac, around by chance ?
<pitti> geser: oh, xulrunner-dev works? why did you previously patch it to build with firefox?
<geser> pitti: I merged the last version because mono-tools was missing a build-dependency and did the test-build with universe enabled so I didn't catch that libxul-dev was in universe
<pitti> ah, ok
<mdke> pitti: did you poke ubuntu-docs from gutsy-proposed to gutsy-updates already?
<jeromeg> ScottK: hello
<jeromeg> jdong acked the pidgin backport, if I provide a debdiff, could you please upload it for me ?
<emgent> jdub: pong
<emgent> i'm working to it, sorry for delay
<jdub> emgent: no worries, just wanted to make sure it became known quickly :-)
<jdub> emgent: thanks!
<emgent> np :P
<emgent> stupid error in ../Mailman/Gui/GUIBase.py
<jdub> and /var/lib/mailman/Mailman/Gui/General.py
<jdub> see #202332 (if you haven't already)
<emgent> yes I saw
<emgent> anyway, i will attach new patch, but i think that it will upload 17/18 th.. weekend time..
<jdub> emgent: the problem is, the current security update breaks mailman
<emgent> i know.
<Hobbsee> emgent: please don't bug me in query, but is this for hardy or gutsy?
<jdub> gusty
<Hobbsee> <sigh>
<Hobbsee> emgent: where is it then, and have you actually tested this one?
<Fujitsu> emgent: Ping a security person as soon as you have a tested fix; you may be able to get it done earlier.
<cody-somerville> superm1, ping
<emgent> ok i will do.
<erle-> will monodevelop 1.0 and mono 2.0 be available in hardy?
<pitti> mdke: ah, no; the changelog failed to include a bug ref, so I didn't see it
<pitti> mdke: done
<Hobbsee> hi pitti
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back
<cjwatson> emgent: has anybody been raised on the phone for this yet? security regressions => bad news
<emgent> cjwatson: debdiff attached and now i'm putting up fix in my PPA too.
<cjwatson> I'll make some calls
<emgent> kees sleep.
<emgent> cjwatson: ok cool.
<emgent> only kees and jamie can upload in -security
<cjwatson> it's not an absurd hour for Jamie
<emgent> ok thanks cjwatson
<iwkse> hi all, anybody tried to install a live with a usb-cdrom device?
<iwkse> i'm experiencing a bug in the initramfs
<iwkse> while using an usb-cdrom device the new_root is mounted before the cdrom is recognized giving the (initramfs) prompt
<iwkse> and after few seconds it recognize the cdrom and allow me to mount it
<iwkse> now...i would really like to boot from initramfs but i don't know how to do
<iwkse> so i was searching a way to delay the mounting of root
<iwkse> root/new_root
<iwkse> anybody experienced it?
<Hobbsee> !weekend | iwkse
<ubotu> iwkse: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<mdke> pitti: sorry about that - and thanks!
<Mithrandir> iwkse: I installed hardy in that configuration at least.
<pitti> emgent: hi
<yao_ziyuan> i want to suggest something, very important
<yao_ziyuan> i want a Language tray icon in a freshly installed ubuntu/kubuntu, just like windows does
<yao_ziyuan> because many east asian users are used to find their input methods there
<yao_ziyuan> well, essentially, it's a SCIM tray icon
<yao_ziyuan> so what i mean is, install and run scim by default
<yao_ziyuan> no matter what the installation/system language is
<ogra_cmpc> yao_ziyuan, did you try out hardy ?
<yao_ziyuan> does hardy do that?
<ogra_cmpc> it does exactly that if an asian language is used :)
<ogra_cmpc> and you can easily enable it on all others with one checkbox
<yao_ziyuan> but an east asian user is used to select his language from a tray icon, not from a system menu
<Hobbsee> yao_ziyuan: ubuntu does that.
<ogra_cmpc> why wouldnt an asian user not install his native language ?
<ogra_cmpc> i guess you rather mean keymap than language
<yao_ziyuan> ...
<yao_ziyuan> because of windows experience
<yao_ziyuan> trust me. a little default tray icon can lead you to wonder
<Hobbsee> ...with the endless popups and the spyware.  a really good idea to duplicate it.
<ogra_cmpc> if you have installed any of the asian languages the scim applet is started by default
<yao_ziyuan> then, put a default tray icon that opens the install language dialog box
<ogra_cmpc> but you have to select your language before boot of the cd anyway ... why add another applet ? you cant boot hardy Cds without having selected the language
<ogra_cmpc> if that language is asian the scim applet will be in the panel
<cjwatson> yao_ziyuan: we install it by default for all languages in hardy, but we don't run it because scim's default keybindings confuse non-Asian users
<cjwatson> yao_ziyuan: this was actually quite a big issue over the last week; it got accidentally turned on by default and caused a great deal of confusion
<cjwatson> yao_ziyuan: so I think we're fine as we are in hardy :-)
<yao_ziyuan> many keybindings in scim are not necessary even for east asians
<yao_ziyuan> it just needs a Ctrl+Space
<yao_ziyuan> and a Shift+Ctrl
<cjwatson> this was exactly what confused people
<yao_ziyuan>  Shift+Ctrl is optional too
<ogra_cmpc> thhats exactly been the biggest issue :)
<cjwatson> people hit that a lot by accident. We are absolutely not turning that on by default, sorry
<yao_ziyuan> what about Ctrl+Space?
<cjwatson> yes
<yao_ziyuan> sigh
<cjwatson> but it's more prominent in hardy than it was in gutsy; I think it's still an improvement
<yao_ziyuan> then don't activate any keybindings unless the user chooses Chinese/Japanese/Korean in the tray icon menu
<yao_ziyuan> i mean, choose by mouse
<ogra_cmpc> yao_ziyuan, thats what we do
<cjwatson> we'd welcome a patch for that
<cjwatson> ogra_cmpc: no, it isn't
<ogra_cmpc> but you select it earlier
<Hobbsee> cjwatson: yao_ziyuan is a kubuntu user.  he probably didn't see it
<ogra_cmpc> cjwatson, well, we force lang selection upon the user on boot
<yao_ziyuan> my concern is that almost all computer users in china are using backdoored windows
<cjwatson> ogra_cmpc: if your locale isn't CJKV or Thai, scim isn't run
<cjwatson> 14:32 <yao_ziyuan> then don't activate any keybindings unless the user chooses Chinese/Japanese/Korean in the tray icon menu
<cjwatson> 14:32 <yao_ziyuan> i mean, choose by mouse
<cjwatson> 14:32 <ogra_cmpc> yao_ziyuan, thats what we do
<yao_ziyuan> that hurts their democracy enterprise greatly
<ogra_cmpc> right
<cjwatson> ogra_cmpc: yes, we make the user select a language at boot, but your description above is absolutely not accurate
<yao_ziyuan> i want them to switch to linux
<yao_ziyuan> but there has to be a way to activate a chinese input method similar to that in windows
<yao_ziyuan> choosing language upon installation is indeed good for novices
<yao_ziyuan> i didn't know vietnamese and thais also need input methods :)
<ogra_cmpc> yao_ziyuan, is it a general habit in asia to not choose the sysem to be in your native lang ?
<yao_ziyuan> no
<ogra_cmpc> then the existing sysem inded doesnt gain much ...
<yao_ziyuan> but for bilinguists like me
<yao_ziyuan> i prefer to remain english as default
<yao_ziyuan> by no i mean yes
<ogra_cmpc> heh
<yao_ziyuan> they choose native languages
<ogra_cmpc> thats how i understood it :)
<ogra_cmpc> so for the majority it will likely be an improvement as it is in hardy then
<yao_ziyuan> in kubuntu 7.10, if you choose chinese upon installation, you will get a default font that displays english letters in an ugly fixed-width way
<yao_ziyuan> yeah i also want to mention, if the user adds chinese, you should use the latest wenquanyi fonts
<yao_ziyuan> but ubuntu's chinese fonts are fine
<yao_ziyuan> i mean kubuntu
<ogra_cmpc> i think especially wrt fonts hardy has improved a lot, the person who is responsible for font and input handling since hardy lives in asia, you should probably take a look, beta wil come out soon
<yao_ziyuan> it's a lot lagging behind
<yao_ziyuan> i'm downloading kubuntu hardy alpha 6
<yao_ziyuan> ubuntu and fedora have perfect chinese display and input
<yao_ziyuan> but they still require you to add chinese from a system menu, rather than from a tray icon, which would be more prominent
<yao_ziyuan> for kubuntu 7.10, it sucks at its default chinese font and its way to enable chinese input: you have to "add language: chinese" AND THEN "set system language: chinese"
<yao_ziyuan> i didn't know i should "set system language: chinese" in my early kubuntu days so i had a lot of frustration getting scim working
 * ogra_cmpc cant comment on kde
<yao_ziyuan> i found the best way so far to enable scim in kubuntu is to install ubuntu first, and then enable chinese input in ubuntu, and then install kubuntu-desktop. and then i log into a kde session, and then Ctrl+Space will give me the input method.
<yao_ziyuan> but this way i still have to manually download the latest chinese fonts from wenquanyi's website
<yao_ziyuan> or else chinese characters in my firefox will be junk
<jdstrand> lamont: I think it should go in sooner than later, but I am working through upgrade scenarios and will be more conservative on upgrades from pre-hardy
<jdstrand> lamont: this isn't bind9-specific, we are working out the details for migrating profiles/etc for all apparmor enforcing packages
<lamont> jdstrand: fwiw, bind9 runs just fine with the file on dapper... :-)
<jdstrand> lamont: bottom-line, I hope to have some postinst and doc changes
<lamont> ah, for bind9?
<jdstrand> lamont: heh, yes it would be fine on dapper
<jdstrand> lamont: yes-- we will put the profile in complain mode on certain upgrades and enforce on new install
<jdstrand> lamont: so as not to break a dapper-hardy upgrade
<lamont> ah, ok.  we'll want to chat about those, I expect.
<lamont> because there are far more configs out there than the default config
<jdstrand> lamont: all the details aren't worked out yet, but once I dig into it more, we can chat
<yao_ziyuan> cjwatson: how is it "more prominent" in hardy than in gutsy?
<jdstrand> lamont: oh sure-- and this isn't bind9 specific
<jdstrand> lamont: but it will affect the apparmor snippet in postinst somewhat
<lamont> jdstrand: those fun little other-configs are the reason that bind doesn't force the chroot or user name on upgrades.  (well, doesn't default to chroot in any case)
<lamont> right
 * lamont grumbles about jdstrand including a (&*^(&*)_)($&%)*_)(^*&%^(_ changelog entry in his patch
<lamont> and manually applies the patch
<jdstrand> lamont: oh-- you don't want the changelog entry too? I was trying to make it easier for you
<lamont> 1) changelog never merges cleanly
<lamont> 2) I autogenerate it at the very end (note the diff on any revision whose commit log says 'changelog: release' :0)
<jdstrand> ok-- I was thinking of the patch as a debdiff.  I'll know for next time
<lamont> if I had just git-am'ed your patch, the changelog record would have been:  Fix for LP: #201954 (apparmor profile does not allow access to /var/lib/bind)
<lamont> you still have the git tree?
<jdstrand> lamont: yes
<yao_ziyuan> kubuntu makes such a distinction between "installed languages" and "system language"
<lamont>     Addresses-Ubuntu-Bug: 200739
<lamont> the changelog basically gets line one of the commit log (the short log print), and will add the LP# syntax if Addresses-{Debian,Ubuntu}-Bug: NNN is there
<yao_ziyuan> i want kubuntu to have a simple Languages listbox like ubuntu does
<yao_ziyuan> and like fedora does
<yao_ziyuan> the Language Selector
<lamont> jdstrand: and the sad part about me munging your change around is that it'll make for merge fun when you refresh after I push it.
<lamont> (for you)
<jdstrand> lamont: it'll help me remember
<jdstrand> ;)
<lamont> lol
<lamont> hrm....
<lamont> jdstrand: so do we make /etc/bind/* read-only and force people to either edit the profile or "fix" their config to be conformant?
<lamont> the default fresh install should make it read only
<lamont> upgrades may want it to be rw
<jdstrand> lamont: I think it would be wise to be conservative in terms of functionality, and leave it rw. The unix permissions will then handle it properly.
<lamont> ah, true
<jdstrand> lamont: from a security perspective, I would want it 'r', but it is really very little gain for potentially a lot of pain
 * lamont steals the bug, marks it fix-committed
<lamont> yeah - the admin can always tweak the file - we shouldn't need to change it much once it's done "enough"
 * jdstrand nods
 * lamont really needs to push bug 191530 upstream
<ubotu> Launchpad bug 191530 in bind9 ""host" cannot see sites in .org" [Medium,Triaged] https://launchpad.net/bugs/191530
<lamont> it's a simple case of host not going the distance
<jdstrand> heh
<lamont> .com nameserver return glue as A RRs (violation of spec), because it works better
<lamont> .org nameservers don't.
<lamont> so if your .org domain has nameservers outside of .org, then host doesn't print things.
<lamont> of course, the real answer is "use dig. kthx"
<jdstrand> interesting-- haven't hit that myself
<lamont> there's a domain name in the bug
<Mithrandir> I'm wondering if we should think about shipping some compat versions of older tools, so people can still go host $blah, and get similar-formatted output, but from dig.
<lamont> and I might have those details wrong, too.
<Mithrandir> ditto for traceroute/mtr.
<jdstrand> yeah, I get 'sourceforge.org has no NS record' too
<lamont> and if you look at the dig output, you can see why
<lamont> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
<lamont> vs dig ns sourceforge.com @a.gtld-servers.net
<lamont> ;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
 * jdstrand nods
 * lamont would welcome someone going through http://bugs.debian.org/src:bind9 and triaging them
<lamont> most of which are "does this still happen" questions for the submitter...
 * lamont wonders about debian bug 408432 and whether it was fully addressed (well, in debian, so I could close it...)
<ubotu> Debian bug 408432 in bind9 "BIND remote exploit" [Important,Open] http://bugs.debian.org/408432
<jdstrand> lamont: I can dig into it on monday (pun intended)
<lamont> heh
<lamont> #431663: dig can be made to crash using -f, named pipes, and signals
<lamont> "and your point?" :-)
<Wartorn> Just wanted to let you know, the "hardware testing" crashed on me, when it came to the mouse-test and i pressed next, now my cpu keeps running at 100%, even after a reboot
<Wartorn> and it keeps alternating between the cores, where one keeps running at around 5% and the other at 100%
<iwkse> any developers around here? :)
<jpatrick> !weekend > iwkse (:))
<iwkse> :)
<iwkse> lazy hackers
<pitti> !ask | iwkse
<ubotu> iwkse: Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-)
<Vadi> Is there a list of requirements somewhere for getting an @ubuntu.com forwarding email address?
<jpatrick> Vadi: you have to be a member
<iwkse> pitti: i did the question before, but i can repeat it..wait
<jpatrick> ubotu: tell Vadi about member
<iwkse> <iwkse> i'm experiencing a bug in the initramfs
<iwkse> <iwkse> while using an usb-cdrom device the new_root is mounted before the cdrom is recognized giving the (initramfs) prompt
<iwkse> <iwkse> and after few seconds it recognize the cdrom and allow me to mount it
<iwkse> <iwkse> now...i would really like to boot from initramfs but i don't know how to do
<iwkse> <iwkse> so i was searching a way to delay the mounting of new_root
<Vadi> jpatrick: Ok, thanks
<superm1> cody-somerville, hey what's up?
<alex-weej> please can a developer take a quick look at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/201127 ? i've posted the changes that I think are suitable for resolution
<ubotu> Launchpad bug 201127 in network-manager "(Hardy) please remove Network Manager Editor from Internet and Preferences" [Undecided,New]
<enarxe0> hi
<Rotund> Is there any chance of getting a new package in for Hardy yet?  Something that's in community?
<LaserJock> Rotund: like an updated package or a completely new one?
<ScottK2> In January serpentine dropped from Main to Universe.  If it's going to stay there, there's some stuff that can be re-enabled.  I'm working on an upload to support python-xml removal.  I can deal with that at the same time unless someone knows of plans to promote it again?
<slangasek> ScottK2: nope, I'm pretty sure that dropping it in favor of brasero was deliberate
<ScottK2> OK.  Just checking.  Didn"t want to do a bunch of work someone would just have to undo later.
<ScottK2> Thnks
<jpatrick> Kopfgeldjaeger: ##fix_your_connection
<slangasek> mjg59: ping
<emgent> heya
#ubuntu-devel 2008-03-16
<platyhelminth> lol dev team for ubuntu
<platyhelminth> hi
<platyhelminth> I am happy to see people wich made this beautiful OS for me for free
<Vadi> Which channel is appropriate for "application development on Ubuntu" ?
<james_w> Vadi: I'm not sure I'm afraid.
<james_w> this isn't really right, it's about developing Ubuntu itself.
<ScottK> To the extent there is an answer for that, I'm afraid it's #ubuntu, which isn't a very good answer.
<ion_> Application development on Ubuntu is just like application development on any other similar platform. If youâre using OpenGL, find an OpenGL channel. If youâre using Ruby, find a Ruby channel etc.
<jdong> I like ion_'s answer the best
<Vad1> Find a channel for C is hard
<Vad1> *finding
<james_w> isn't there ##c?
<slangasek> the unofficial channel for the C project?  What would be required to have an official one? :)
<jdong> slangasek: some holy language/compiler wars?
<wasabi> I think this conversation has hilighted something in my mind that we sort of fail at.
<calc> java is better than all of them... er yea ;-\
<wasabi> Many people daily have the exact same question Vad1 just had, for WIndows.
<wasabi> And they actually get sent to a single site with a bunch of choices.
<LaserJock> Fortran Forever!
 * calc kicks java for causing so many OOo problems
<calc> wasabi: msdn.microsoft.com ?
<wasabi> Basically.
<wasabi> Good, bad? I dunno. Different.
<calc> wasabi: well we could point them at /usr/share/doc
<wasabi> Hehe.
<calc> wasabi: assuming they have the dev docs installed
<wasabi> I wonder what the real statistical benefit of that is. That is, the lack of choice.
<calc> lack of choice causes uniformity which makes it more likely to find someone that knows what you need (i guess)
<Fujitsu> But the Win32 API sucks.
<wasabi> People use .Net now.
<wasabi> Also means one place can serve the population, with a set of answers and common development paradigm.
<Vad1> calc: That's assuming that answer does exist in that small population.
<calc> Vad1: yea
<pwnguin> wasabi: just point em to #debian ;)
<Vad1> james_w: Thanks, ##c helped me out.
<Vad1> wasabi: it will be different, and I think good. Having a unified (keyword) resource that's for everything programming, with all info in one place, will be really nice and make things easier. I don't see msdn failing - it's still going, so it must be working out. Meanwhile I'm reading some comments on brainstorm from people who do know how to code, but getting into it is difficult because of a lack of proper resourc
<Vad1> I was typing that so long that I started going in circles in the end. Oops.
<mjg59> slangasek: Yo?
<slangasek> mjg59: ok, asynchronous it is then. :)  I've taken on responsibility for getting some fixes to acpi-support in for hardy (bug #193842), and there was some doubt expressed at the last platform team meeting about whether this is even still the right package for handling suspend/resume fix-ups; can you confirm that this stuff is all still in the path?
<ubotu> Launchpad bug 193842 in acpi-support "Please sponsor cherrypicked fixes for acpi-support into Hardy" [Medium,Triaged] https://launchpad.net/bugs/193842
<famicom> Yo
<famicom> anyone here which part of the ubuntu isntaller defines what gets installed
<stgraber> famicom: that's not really a "part of the ubuntu installer", it's defined in the preseed/ubuntu.seed file
<stgraber> on a normal Ubuntu install, the "ubuntu-desktop" task is selected, so every packages assigned to that task will be installed
<famicom> why isnt there a simple cli switch or the option to feed ubiquity an external seed file
<famicom> i mean, gee, why should i have to download another whole godd*mn disk to have a functionality that is allready available on the same disk
<famicom> that is assbackwards
<stgraber> there is a simple switch which you can give it an URL to a preseed file which will give it a different package list (that at least work with debian-installer and should now also work with ubiquity preseeding)
<famicom> ah
<famicom> and where can i find that in the documentation
<stgraber> in the ubuntu install-guide, there is a preseeding chapter
<famicom> blegh
<famicom> the "official" ubuntu documentation needs to be updated
<famicom> right now its less helpfull than windows help/support
<stgraber> famicom: https://help.ubuntu.com/7.04/installation-guide/i386/preseed-intro.html
<stgraber> famicom: http://evalicious.com/evan.seed for an example
<famicom> yeah, i know how they work
<famicom> anywyas
<famicom> thanks dude
<Wartorn> Just had an issue with libxml2-dev package. I have a project that uses this, and i included libxml/xmlmemory.h etc, but this wouldnt compile, if i changed the include to libxml2/libxml/xmlmemory.h it got one step further, but then xmlmemory.h itself couldnt find some files (cause it too includes only the libxml/<file> path), so i had to move /usr/include/libxml2/libxml to /usr/include/libxml, which worked fine. Is it supposed to be lik
<afancy> Hi, when i install a software on Ubuntu, I met the following error: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
<afancy> what is the matter?
<stgraber> Wartorn: please check topic, this channel is about Ubuntu development not development on Ubuntu
<Seveas> Wartorn, afancy: this is not a support channel
<Wartorn> well, im just asking the devs if its something wrong with the package
<afancy> why?
<Seveas> Wartorn, no there is not
<afancy> so where i should ask this question?
<Seveas> afancy, #ubuntu
<Wartorn> Well, on my older hardy installation (not updated) this project worked out of the box.
<Wartorn> when libxml itself cant find its own files, theres gotta be something wrong, and its installed through aptitude, so it cant be my fault
<Seveas> Wartorn, you manually moved files around instead of fixing your -L call (or better: use pkg-config). That breaks things.
<Seveas> and given that this is not a support channel, please don't expect support :)
<Wartorn> im not looking for support, i found a way to compile it, breakage or not, im just saying it doesent work out of the box anymore
<Wartorn> so if its a package error, i just thought this would be the place to go
<Seveas> it is not a package error, and if it were, irc channels are not the place to report bugs
<Wartorn> Well, fine. Sorry for the hassly.
<Wartorn> hassle
<Hobbsee> Seveas: have you always been so helpful?
<Hobbsee> Wartorn: have you checked for a bug on it already?
<Wartorn> Well, no. Sorry. Probably should've done that
<Seveas> Hobbsee, I have :) I can't help it he doesn't use pkg-config properly to avoid this
<Wartorn> Thing is, why should i have to do that at all?
<Seveas> because that's what pkg-config is for.
<Hobbsee> Wartorn: as it is, 244 packages build with that in hardy, it looks like, so we would have expected mass breakage if it can't find files
<Hobbsee> and there is no bug for it
 * Hobbsee suspects an issue with the package you're compiling
<Seveas> Hobbsee, it's not a package, it's his own code :)
<Wartorn> well, its my own program. But on my other computer it worked fine, out of the box (hardy too, not been updated in a while)
<Wartorn> And i have no problems with any of the other dependencies the program has
<Seveas> Wartorn, that still doesn't make it a bug in the package. You should use the proper way of specifying -I and -l flags
<Wartorn> Well, okay. thanks
<Hobbsee> damn.  finally hit the x bug again.
<Hobbsee> how does one find out what a particular keypress event actually is, if one has the serial/
<Fujitsu> Hobbsee: xev should normally give a name for it if it knows.
<Hobbsee> Fujitsu: that's what i thought.  how do you find out what it is if it doesn't know/
<Fujitsu> Hobbsee: No idea.
 * lamont reads the growisofs manpage and scratches his head looking for how to erase a dvd-rw...
<unggnu> hi all
<unggnu> sorry for bothering but I guess this bug report is important and should be fixed before release Bug #197167
<ubotu> Launchpad bug 197167 in e2fsprogs "Please sync e2fsprogs e2fsprogs 1.40.7-1 with Debian" [Undecided,Confirmed] https://launchpad.net/bugs/197167
<unggnu> It seems that e2fsprogs has some serious issues, at least tune2fs.
<mjg59> slangasek: No, suspend/resume doesn't use it at all
<cody-somerville> If there any archive admins around, please push xubuntu-default-settings through please :)
<highvoltage> PPC isn't supported anymore, right?
<jdong> officially, no
<highvoltage> jdong: I asked in #ubuntu-bugs too, but timing isn't too good, what should happen with a bug like this: https://launchpad.net/bugs/44265
<ubotu> Launchpad bug 44265 in usplash "dapper flight 7 PPC fails to install (more infos)" [Medium,Confirmed]
<highvoltage> jdong: should it be closed?
<jdong> highvoltage: I'm not sure, I wouldn't close it
<highvoltage> ok
<cody-somerville> fabbione, ping
<sivang> hi all
<sivang> does anybody know how to pass parallel build instructions through DEB_BUILD_OPTIONS or some other way that will not require patching each package rules file?
 * sivang apologizes in advance for the off topicness
<sivang> hey sabdfl , how's it going ?
<emgent> heya people
<sabdfl> hey sivang, good thanks
<sabdfl> am on holiday
<sabdfl> just wrapped a week boarding in wyoming
<sabdfl> now off to british columbia
<sabdfl> you?
<highvoltage> hey there sabdfl and sivang
<cody-somerville> Can a core-dev complete this merge for me? https://code.edge.launchpad.net/~xubuntu-devel/ubuntu-seeds/xubuntu.hardy/+merge/163 - thanks :)
<sivang> sabdfl: cool
<sabdfl> hey highvoltage
<sabdfl> cheers all
<highvoltage> cheers, have lots of fun!
<calc> wow brasero is either really slow on images or my system is broken somehow
<calc> it took ~ 15m for it to checksum the image it was going to burn
<calc> hmm then it failed to actually start the burn :\
 * calc wonders why his burns are taking so long
<calc> 20x dvd burner burning 16x dvds it taking ~ 17m to burn a disc
<Nafallo> ehrm
<Nafallo> their is more to the system then the actual burner :-)
<Sjimmie> exactly, add the System Monitor to a panel with cpu and disk inthere and then burn again and watch ur load
 * lamont wonders if he should be concerned that the version of openvpn in hardy is currently ~rc7...
<superm1_> asac, unfortunately that ath_pci situation with NM 0.6.6 just got worse for me.  In cleaning up ~ a little bit, I accidentally wiped my stored networks.  Now I can't even get NM to associate period with this AP (copying and pasting the key from openwrt's nvram output)
<slangasek> mjg59: bah; why doesn't it? :)
<mjg59> slangasek: Because we use pm-utils instead, and have done for months
<slangasek> mjg59: in all cases?  would it be better to pull the suspend/resume code out of acpi-support?
<mjg59> slangasek: Yes
<slangasek> ok
<mjg59> slangasek: The problem is that they're in /etc, so conffiles
<slangasek> right
<superm1_> still can be removed via a postinst for a new version of acpi-support though, can it not?
<slangasek> yes; it's an annoying process though
<slangasek> you have to get md5sums for each of the conffiles you want to remove, and only remove those that match
<superm1_> ah that would be rather tedious
<wasabi> so this new cups admin thing almost works.... except it won't accept my password to change any settings.
<cody-somerville> wasabi, You probably have to add your user to the lpadmin group
<wasabi> seems so.
<wasabi> error message sucks.
<asac> superm1_: ok. i think ath_pci hacks are still required then. i'll prepare a test package
<superm1_> asac, okay sounds good.  i'm online from another laptop, so i'll be glad to test any debs that you prepare
<superm1_> asac, an additional comment: I came across bug 111068, which mentioned using 'iwpriv ath0 mode 3'.  I'm assuming something similar is listed in your ath_pci hacks when connecting to a 'g' network.  that makes things work again.
<ubotu> Launchpad bug 111068 in network-manager "A bug between Atheros Communications AR5212 802.11abg nic and  Ubuntus network applet" [Medium,Triaged] https://launchpad.net/bugs/111068
<asac> superm1_: i don't think we have such a hack... but not sure right now
<superm1_> asac, okay.  well i'll test whatever it is that you have in there once you've got it ready
<cody-somerville> superm1_, Would you be willing to regenerate and upload xubuntu-meta for me please? :)
<superm1_> cody-somerville, sure
<cody-somerville> superm1_, thanks :)
<superm1_> cody-somerville, wasn't slangasek doing that the other day though?
<cody-somerville> superm1_, It needs to be done again
<superm1_> cody-somerville, ah okay.
<cody-somerville> Thanks :)
<emgent> goalllllllll
<emgent> IAAAAAAAAAAAAAAAAAAAAAAAAQUINTAAAAAAAAAAAAAAa
<emgent> ops
<emgent> wrong room.
 * emgent dude
<superm1_> cody-somerville, it's uploaded, but likely will need a release manager to take it out of the queue
<slangasek> cody-somerville: does this round get the CD size down where it needs to be? :)
<Stroganoff> will there be no more low memory mode in hardy?
<slangasek> cody-somerville, superm1_: accepted, but dropping example-content is not going to be enough on its own to get the hardy alternate i386 CD size down below the limit...
<xsakalik> Doesn't someone have experience with plugin architectures? -> Is it reasonable to put plugins into separate process (instead of threading) to ensure stability?
<wasabi> Depends what you want those plugins to do.
<wasabi> Look at dbus.
<xsakalik> wasabi I've looked, but i'd rather use sockets as IPC. I was just thinking if that approach isn't totally ridiculous. Don't you know any project that utilizes processes?
<wasabi> No. I mean look at dbus itself.
<wasabi> dbus services themselves are your hypothetical 'plugin system'
<xsakalik> wasabi, can you elaborate it? (little more)
<wasabi> And I suspect you should just use a better language if you're having crashes in one plugin crash another.
<wasabi> dbus loads processes.
<wasabi> On demand.
<wasabi> Basically exactly like what you are talking about.
<wasabi> also this is a bit offtopic for this #
<xsakalik> Sorry, what channel should I go to?
<wasabi> Got me.
<Stroganoff> #c
<xsakalik> ok, I'll try it there, thx
<LaserJock> maybe that should be our new default
<LaserJock> "go to ##c"
<iwkse> hi all, i was speaking last day about the initramfs bug on booting from usb-cdrom
<iwkse> there's anyone here to speak?
<Seveas> iwkse, bugreports should go to launchpad
<Seveas> !bugs | iwkse
<ubotu> iwkse: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots
<iwkse> Seveas: thanks, i'm trying to check if it's duplicated
#ubuntu-devel 2009-03-09
<tkamppeter> johanbr, then your manual call and the call by cupsfilter uses different command line options and the call out of the print queue even others.
<tkamppeter> Try to find out which command line options get actually used and which ones make pdftopdf break. If the original PDF produced by evince is good then we probably have a pdftopdf bug.
<calc> LaserJock: yea
<calc> LaserJock: but poorly, so i have to determine how to fix it or disable it entirely and use fuse
<calc> LaserJock: fuse was buggy as well so it wasn't working until the next release 1.1.8 will work with OOo
<calc> LaserJock: it didn't support truncate at all but now does for trivial cases (0 or same size as file)
<LaserJock> calc: bummer
<ebroder> Has, uh, anybody run into weird issues with Jaunty's libc running under Lenny's kernel?
<tkamppeter> johanbr, is the file already the evince output or the original file? If it is the original, give me also the evince output.
<TheMuso> 8/c
<calc> LaserJock: well gvfs fuse will work in time for jaunty, but i was trying to fix the OOo native support which takes learning how they actually work, heh
<calc> i have to make a decision by beta though to make sure it works for everyone
<johanbr> tkamppeter: that's the original
<johanbr> just a sec
<tkamppeter> johanbr, seems that your LaTeX PDF file makes evince turning all fonts to graphics when converting PDF to PDF (probably with Poppler).
<tkamppeter> Great would be if one could let evince pass the input PDF directly through to the output to minimize the number of conversions (and losses caused by them).
<johanbr> Oh, I see. Well, that explains the enormous file size.
<johanbr> tkamppeter: If you pass the original pdf file through pdftopdf, you should also get a large file (~100 megs). Is that also because it turns fonts into graphics?
<tkamppeter> pdftopdf should do page management only, not re-render the file. Please try passing the original PDF to pdftopdf. The size of the output should be in the order of the size of the input.
<johanbr> tkamppeter: nope
<johanbr> cat original_filename.pdf |/usr/lib/cups/filter/pdftopdf job1234 username test 1 jobname.pdf >copy.pdf
<johanbr> gives a copy.pdf that's 92 megs large
<tkamppeter> johanbr, strange. pdftopdf bug probably. pdftopdf is Poppler-based, evince probably too and the two Poppler treatments perhaps produce 5 * (92/5)^2 MB.
<johanbr> could the problem be fixed directly in poppler?
<johanbr> or does the library not have enough information to know that it can just return the pdf file unmodified?
<johanbr> and evince does indeed use poppler
<Hobbsee> asac: ping?
<Mavericks> any way to find out whether gnome or openGL developer positions (work at home) for canonical are wide open at this point of time apart from looking at webapps.ubuntu.employment
<Mavericks> *webapps.ubuntu.com/employment - surprisingly it has URL starts with webapps
<Mavericks> ooh oops sorry if i  offended canonical staff here - any help will be appreciated
<LaserJock> generally we don't know anymore than anybody else about Canonical's hiring
<LaserJock> I suppose you could email Canonical's HR but I'm not sure if they'd tell you anything helpful regarding how "wide open" positions are
<Mavericks> yes, there is a time frame of 21days about notification after applying for a position
<Mavericks> couldn't find HR  and there seem to be lot of ideal or desirable work-at-home positions but recession only makes it tougher
<ScottK> Mavericks: It's really OT here regardless.
<Mavericks> ScottK: thank you , i know that
<LaserJock> Mavericks: HR is simply hr@canonical.com
 * calc read something interesting about intel ssd today, apparently they are limited to 20GB/day transfer to stay within warranty specs, and supposedly slow down so that you can't do more than that disk io
<andersk> Hey, anyone want to look at an awesome libc bug?  bug 339743
<ubottu> Launchpad bug 339743 in glibc "Jaunty i386 popen() misbehaves on Lenny 2.6.26-1-amd64 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/339743
<Hobbsee> andersk: probably people on the other side of the world, who are asleep now.  Also, they get mailed about bugs that they care about
 * ScottK wonders how it's even a bug.
<ebroder> It's problematic if your Jaunty build chroots are running on a Lenny system
<ScottK> "Hey, your libc doesn't work with some other distro's kernel"
<andersk> Surely a statically compiled binary is supposed to work on other distro's kernels.
<ArneGoetje> slangasek: the -base langpacks contain all translations which were exported from Rosetta at a given point in time. the other langpacks is a diff to what has changed since then.
<andersk> It works in Intrepid.
<ArneGoetje> slangasek: due to a bug the first -base langpacks didn't include any mozilla and kde translations. That's why I generated a new one. Mozilla diffs only work when the -base pack has mozilla xpis already, which was not the case.
<ArneGoetje> slangasek: the duplicate xulrunner and firefox for bn_IN, es_ES, pt_PT and sv_SE are due to in import error into Rosetta and will hopefully be removed from the database soon. As soon as this happens I will generate new -base langpacks. Another -base generation will happen shortly before release. Please do expect them to grow in size!
<calc> so 10.04 LTS will have gnome 3.0 ?
<TheMuso> calc: IMO that would be too risky.
<TheMuso> Or, we extend the cycle to fix bugs.
<ScottK> TheMuso: So far it's seemed to me that the general view for LTS is better grab the latest so it'll be supported longer.
<ScottK> Perhaps next time around it'll be the opposite.
<TheMuso> ScottK: Yeah but GNOME 3.0 will have some pretty significant changes
 * ScottK doesn't really know about it.
<ScottK> From what I'd read in blogs it seemed likely to arrive with Perl 6.
<TheMuso> heh right
<ScottK> TheMuso: At the last release team meeting I brought up the Qt 4.5 ICE on PowerPC and there were some actions assigned to look into it.
<TheMuso> ScottK: I didn't know about that ICE
<ScottK> Since then I see that GCC FTBFS on powerpc in the last upload in the g++ tests.
<calc> ScottK: well aiui gnome 2.30 == 3.0
<ScottK> This one http://launchpadlibrarian.net/23244739/buildlog_ubuntu-jaunty-powerpc.kde-style-skulpture_0.2.2-0ubuntu1_FAILEDTOBUILD.txt.gz is a much smaller app, but it looks like the same/very similar failure.
<ScottK> calc: KDE got a new version so we want one too?
<calc> ScottK: something like that probably ;-)
<calc> ScottK: they get to drop deprecated api's at 3.0 as well iirc
<ScottK> Right.
<calc> I'm going to try running a debug build with gio for OOo if it doesn't show anything obvious I'm going to drop gvfs/gio from OOo and go to gvfs fuse for jaunty :-\
<LaserJock> calc: where did you hear that 2.30 == 3.0? I can't imagine that actually happening
<calc> LaserJock: don't remember now
<calc> LaserJock: may not have been a reliable source
<calc> LaserJock: http://www.phoronix.com/scan.php?page=news_item&px=NjU4Mg
<calc> LaserJock: it seems that 2.30 will really be 3.0 unless they change their mind in july
<ScottK> So it sounds like the decision is not so much about what they'll add, but what they'll drop?
<TheMuso> Corba for one
<johanbr> I guess the gnome-shell thingie will be part of 3.0.
<TheMuso> That will be interesting accessibility wise.
<calc> wow i'm glad i got the gvfs truncate fix in when i did, next release is 2.26.0
<LaserJock> so I wonder if they're going to branch or something
<LaserJock> I can't imagine doing all the Gtk/Gnome 3.0 breakage in 1 release
<johanbr> Well, there are already branches of some things. I know of the gnome shell and gtk with multi-pointer support. Probably other stuff too.
<TheMuso> and gnome-speech may be going away, actually it will go away if I have anything to do with it.
<LaserJock> johanbr: yeah, but if it's really supposed to be "revolutionary" the core stuff I'd think would need to be starting fairly soon
<LaserJock> http://live.gnome.org/ThreePointZero seems a bit bare
<calc> LaserJock: apparently they forgot to update the page after guadec
<dholbach> good morning
<IntuitiveNipple> morning :)
<dholbach> hi IntuitiveNipple
<crimsun> TheMuso: ok, latest /ubuntu is go for Alpha 6
<ebroder> Anyone around who could do an upload for bug 339449? I'd like to make a6
<ubottu> Launchpad bug 339449 in mit-scheme "FeatureFreezeException: Merge mit-scheme with Debian" [High,Confirmed] https://launchpad.net/bugs/339449
<slangasek> ArneGoetje: right, my question isn't really "why do we have -base langpacks" so much as "why, during the development cycle, do we ever have any translations in the normal langpacks instead of just updating the -base langpacks?"
<slangasek> ArneGoetje: btw, please remember to turn off the upload cronjob, alpha 6 this week :)
<pitti> Good morning
<Hobbsee> heya pitti!
 * pitti hugs Hobbsee
<Mithrandir> yo, Hobbsee, pitti
<Hobbsee> :)
 * Hobbsee hugs pitti back, and waves to Mithrandir
<pitti> hey Mithrandir, how's it going?
<Mithrandir> pitti: good, good.  Was in CPH over the weekend, which was nice.
<StevenK> Morning pitti
<StevenK> pitti: So, you didn't accept syslinux.
<pitti> StevenK: was I supposed to?
<pitti> Mithrandir: nice, I've never been to Denmark yet
<StevenK> pitti: I thought you said you'd look at it on Friday?
<pitti> oh, SRU? sorry
<Mithrandir> pitti: Isn't it weird not having visited a neighbouring country?
<StevenK> pitti: Yeah, the SRU
<pitti> Mithrandir: I visited all 8 others
<StevenK> pitti: Fix it? :-)
<pitti> StevenK: ok, seems I need to do SRUs today again
<pitti> StevenK: got buried in meetings on Friday, I apologize
<ebroder> I'm not entirely clear on the process here. Does bug #339618 require a freeze exception?
<ubottu> Launchpad bug 339618 in mpb "Update libctl to use guile-1.8" [Undecided,New] https://launchpad.net/bugs/339618
<siretart> kirkland: do you have any plans to backport screen-profiles to hardy/intrepid and eventually debian?
<Hobbsee> siretart: it's already in a ppa?
<Hobbsee> at least for intrepid
<siretart> Hobbsee: I have no problem recompiling it for me personally. Actually, I'm most interested in having it in lenny-backports :-)
<Hobbsee> siretart: ahhh
<tkamppeter> Hi, any Python experts here? It is about bug 153610. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed.
<ubottu> Launchpad bug 153610 in system-config-printer "applet.py crashed with IOError in module>()" [Low,Triaged] https://launchpad.net/bugs/153610
<pitti> mvo, soren: could anyone test vm-builder in hardy-proposed, which rots there for 214 days already? If not, I'll just remove it from -proposed
<mvo> pitti: I did the upload, but I can do the verification as well
<pitti> mvo: much better than no feedback at all, and if you use the actual .deb from -proposed, and not a local build, and exercise a few standard cases, that would suffice
<pitti> mvo: danke!
<tkamppeter> Sorry, wrong bug. I mean the following: It is about bug 203808. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed.
<ubottu> Launchpad bug 203808 in system-config-printer "applet.py crashed with ImportError in <module>()" [Undecided,Fix released] https://launchpad.net/bugs/203808
<tkamppeter> This only happens with Python programs which are not directly started by the user, like the system-config-printer applet which is auto-started on login or hal_lpadmin which is triggered by HAL.
<pitti> tkamppeter: that bug is very old, and closed..
<tkamppeter> pitti, I will look for other examples then ...
<tkamppeter> pitti, bug 336707
<ubottu> Launchpad bug 336707 in hal-cups-utils "hal_lpadmin crashed with ImportError in <module>() (dup-of: 291035)" [Undecided,New] https://launchpad.net/bugs/336707
<ubottu> Launchpad bug 291035 in hal-cups-utils "hal_lpadmin crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/291035
<asac> Hobbsee: hi. pong
<Hobbsee> asac: greetings.  I presume you've been keeping tab on n-m bugs?  It seems there's a fair bit more tempramental (or plain broken) behaviour for multiple wifi cards, and I was wondering if you knew anything about it
<pitti> tkamppeter: I think you can close them; I fixed s-c-p for python2.6 in 1.1.3+git20090218-0ubuntu4
<asac> Hobbsee: hmm. depends. i know that there are still issues with some types WPA enterprise. Any particular wifi chipset you have issues with?
<Hobbsee> asac: there was a broadcom mentioned earlier, and I was having temporary problems with my iwl3945 card
<tkamppeter> pitti, the mentioned ones are on hal-cups-utils. Or is it because hal-cups-utils uses a lib of s-c-p?
<pitti> aah
<Hobbsee> asac: the broadcom got reported, I think i saw another couple in bugs, and I don't still have logs of my (now working) iwl3945
<pitti> tkamppeter: yes, python-cupshelpers  is built by the s-c-p source (#336707)
<pitti> tkamppeter: that should be good now
<pitti> tkamppeter: the other two bugs fail on importing "usb"
<pitti> thus they are different
<pitti> tkamppeter: I don't have an usb.py on my box
<asac> Hobbsee: yes, broadcom is one of the few drivers that is no in mainline kernel afaik ... which is bad as it cannot be fixed.
<pitti> tkamppeter: so I think bug 291035 is real
<ubottu> Launchpad bug 291035 in hal-cups-utils "hal_lpadmin crashed with ImportError in <module>()" [Undecided,Confirmed] https://launchpad.net/bugs/291035
<Hobbsee> asac: ah, right
<tkamppeter> pitti, so python-usb needs to be fixed, too? It is required by hal-cups-utils. Should I assign these bugs to python-usb then?
<pitti> tkamppeter: maybe it's missing a dependency to python-usb?
<pitti> oh, it's usb.so
<pitti> $ python -c 'import usb'
<pitti> works for me
<pitti> tkamppeter: no, should be fine; doko rebuilt it on Sun, 22 Feb 2009
<tkamppeter> pitti, I have checked and hal-cups-utils requires python-usb, it is the only package to keep python-usb in a standard installation.
<pitti> tkamppeter: hm; no idea then, I'm afraid
<pitti> tkamppeter: ah, look at Dependencies.txt in #291035
<pitti> tkamppeter: he still has the old python-usb installed (not ubuntu1, which was the 2.6 rebuild)
 * pitti hugs apport
<pitti> tkamppeter: so, I'd reassign it to python-usb and close it with the last entry of /usr/share/doc/python-usb/changelog.Debian.gz
<pitti> mvo: would you mind applying the intrepid SRU patch for compiz to jaunty, too? (bug 269805); it's an alpha-6 blocker
<ubottu> Launchpad bug 269805 in compiz "gnome-window-properties gives error about configuration tool not being "registered"" [High,In progress] https://launchpad.net/bugs/269805
<tkamppeter> pitti, I have simply closed this bug now with a comment added that the user should update.
<pitti> tkamppeter: right
<tkamppeter> pitti, I see another problem.
<tkamppeter> I have kept s-c-p all the time identical to upstream and now there was a major patch done due to the notifications.
<mvo> pitti: thanks, this is already in bzr
<tkamppeter> What was the problem to have buttons in the notifications?
<pitti> tkamppeter: right, please prod the dx team to forward the patch upstream
<pitti> tkamppeter: notify-osd doesn't support actions in notifications
<pitti> so they'd end up as dialogs
<mvo> pitti: any word about the freeze exception for the compiz with protobuf support ? or should I wait for slangasek ?
<tkamppeter> pitti, is this a Ubuntu policy or a GNOME policy?
<pitti> tkamppeter: it's not a policy; by design, notify-osd doesn't support actions
<pitti> tkamppeter: and libnotify doesn't promise that the implementation does
<pitti> tkamppeter: s-c-p just assumed that it can; with the patch, it checks whether the notification daemon actually supports actions, and if not, it does something different
<tkamppeter> pitti, and why is notifying system replaced by an inferior one only for eye-candy?
<pitti> mvo: I didn't answer yet; a 0.5 MB impact on the CD for relatively little gain, after FF, and with new potential bugs due to new implementation doesn't exactly make me happy..
<ion_> I donât understand why notification-daemon couldnât have been patched with the eyecandy.
<pitti> mvo: but "pitti feels bad about it" might not be sufficient to say "no" :)
<pitti> ion_: (1) the patch would exchange the entire code, and (2) we want the original n-d to be available, too
<mvo> pitti: well, startup improvement gain of 20-30% is not "relatively little"
<pitti> tkamppeter: it's not just eye candy, but a new usability design
<mvo> pitti: but I certainly understand this
<pitti> mvo: I'm actually more concerned about changing the entire underlying configuration parsing structure that late
<pitti> if we can spare the space on the CDs, I'm fine with it, but I'd really like to have slangasek decide that
<mvo> pitti: sure, I wait for him. if we do it, we should do it today IMO
<pitti> yes, indeed
<tkamppeter> piiti, would "if os.environ.get('GDMSESSION') == "gnome-stracciatella":" also work on non-Ubuntu distros to check whether the notify daemon is capable of actions?
<tkamppeter> pitti: ^^^
<pitti> tkamppeter: no, please don't ever use that outside of Ubuntu
<pitti> tkamppeter: it's meant for something entirely different
<pitti> tkamppeter: for checking action support, you need to call
<pitti> GList *notify_get_server_caps(void);
<pitti> (/usr/include/libnotify/notify.h)
<tkamppeter> Is there a possibility for a Python program to check whether the notification daemon supports actions?
<pitti> (this also exists in python-notify)
<tkamppeter> pitti, then the patch should be changed to that.
<pitti> tkamppeter: indeed it should
<pitti> kenvandine_wk: ^
<pitti> tkamppeter: thanks for pointing out
<tkamppeter> pitti, kenvandine_wk: With this fixed I would commit the patch upstream.
<pitti> tkamppeter: if it checks server caps, it absolutely makes sense to commit it to upstream, since this is a real bug (assuming that actions are supported without testing for them)
<pitti> tkamppeter: the stracciatella test is an ubuntu specific hack and should remain Ubuntu patches
<tkamppeter> pitti, I have reported bug 339847 on the s-c-p notification problem.
<ubottu> Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847
<pitti> tkamppeter: thanks; please assign to ken-vandine
<tkamppeter> pitti, I have already done so.
<hayalci> Hi, any chance that flashplugin-nonfree gets some love ? :) https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/304969/
<ubottu> Ubuntu bug 304969 in flashplugin-nonfree "Hardy: Flash can't be installed since install_flash_player_9_linux.tar.gz can't be retrieved " [Undecided,New]
<cjwatson> calc: GPT is the default when creating a new partition table on some (sub)architectures, of course (ia64 and Intel-based Macs), but without some way to detect whether the BIOS supports it we can't make it the default
<cjwatson> calc: I hate the DOS partition table format as much as anyone else sensible does, but I don't much like the idea of either breaking support for anything that isn't incredibly new, or having to ask an unintelligible question
<directhex> cjwatson, detecting EFI?
<cjwatson> I guess looking for /sys/efi or whatever might work, but ...
<cjwatson> we do already use gpt for disks larger than 2TB
<directhex> except it gets more complex when using BIOS emulation
<cjwatson> indeed
<directhex> i.e. my mac has no /sys/firmware/efi
<directhex> my altix does
<cjwatson> isn't support for /sys/firmware/efi in a kernel module?
<cjwatson> efivars or some such
<cjwatson> but yes, BIOS emulation on Macs does throw a spanner in the works, and the installer has a special case for Intel-based Macs for that reason
<cjwatson> I don't know whether the same goes for modern non-Mac x86 hardware
<directhex> i think MSI are the ones beginning to put EFI on their motherboards
<directhex> most don't
<cjwatson> for Macs it's easy; we do the equivalent of dmidecode and see if it says Apple ...
<cjwatson> but I'm not about to go hardcoding that for every BIOS manufacturer on the planet
<directhex> i thought it might help to know who was at it :/
<directhex> aren't MSI canonical partners? i thought their netbook was ubuntu based
<directhex> you could try & get ahold of one of their boards to take a peek
<directhex> elilo sucks, though. that's unfortunate
<cjwatson> mm, I'm not exactly overflowing with space for more hardware
<cjwatson> realistically I suspect EFI systems are an excuse to try out grub2
<ion_> Incidentally, i installed grub2 recently. Seems to work fine. :-)
<ion_> (jaunty)
<cjwatson> we should have a wiki page with success/failure plus actual hardware details
<ogra> cjwatson, just expense a new house :P
<cjwatson> slangasek: were you going to set up something like that as part of the grub2 spec?
<cjwatson> ogra: now there's an idea
<ogra> :)
<directhex> my shiny new muddleboard has no EFI... MSI warranties were inferior
<davmor2> Guys testing 20090309 the sound is crackly but it only seems really bad on the login music.  I've had a quick look at https://wiki.ubuntu.com/DebuggingSoundProblems but I can't see anything for debugging the login sound.
<ion_> keybuk: How soon will we get module-init-tools 3.7~, btw? :-)
<seb128> slangasek: can we get freetype 2.3.8 in jaunty? ;-) it fixes evince rendering issues
<pitti> seb128: bug fix only release?
<seb128> pitti: "This is a bugfix release for the 2.3 series. All users should upgrade." is what is writting  on the website
<pitti> seb128: if the changelog confirms this, then this doesn't need any exception; bug fixes are fine
<seb128> pitti: I don't plan to do the update, slangasek is the debian maintainer for it, I was just suggesting that he should have a look at doing the update ;-)
<pitti> ah, I see
<seb128> just tried it to confirm it fixes evince displaying wrong chars on some documents
<seb128> where is doko?
<seb128> bug #339337
<ubottu> Launchpad bug 339337 in gnome-games "sudoko tracker crash" [Undecided,Confirmed] https://launchpad.net/bugs/339337
<directhex> hiding
<seb128> slangasek: ^  that's due to the python-numpy change
<TheMuso> asac: I see why bug 278095 is appearing again, seems I clobbered your patch. :p uploading the re-introduced patch now
<ubottu> Launchpad bug 278095 in at-spi "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,In progress] https://launchpad.net/bugs/278095
<asac> TheMuso: yeah. you also clobbered the changelog ;) (not nice)
<TheMuso> No I know. I'm putting it back in as well
<asac> TheMuso: so upstream redid most of the code, but ignored our bug :(
<asac> TheMuso: well. the patch doesnt apply anyway
<asac> TheMuso: let me give you a new proposed patch
<TheMuso> asac: ok, won't adjusting the current patch to the new code work, or will that only break things further?
<asac> TheMuso: http://pastebin.com/f2fa4dd57
<TheMuso> because if the former, I can do that here
<TheMuso> oh ok thanks
<asac> TheMuso: try that.
<asac> TheMuso: i am not sure if it works, but i would think so ;)
<TheMuso> ok
<asac> TheMuso: can you read https://bugzilla.mozilla.org/show_bug.cgi?id=460926
<ubottu> Mozilla bug 460926 in Disability Access APIs "A11y hierarchy is broken on Ubuntu 8.10 (GNOME 2.24)" [Blocker,Resolved: fixed]
<TheMuso> ok I'll have a look
<asac> TheMuso: and tell me if that means that we shouldnt use at-spi at all in firefox?
<asac> TheMuso: i think their fix does just opt-out from at-spi
<asac> TheMuso: so if we do that we might not even need the AT_SHUTDOWN patch
<TheMuso> right, I don't know enough about that to coment whether we should be using at-=spi or not
<asac> TheMuso: yeah. lets both read the mozilla bug and discuss later today or tomorrow what to do ;)
<TheMuso> ok
<TheMuso> asac: I am going to try your patch anyway, because I want to see if it corrects some other behiavior I am seeing in GNOME itself...
 * ogra wonders, if i have a system with an empty modules.dep it seems module-init-tools still gives me a "no such file or directory"
<asac> TheMuso: hmm are there crashes elsewhere?
<TheMuso> asac: No crashes, but thigns not being accessible...
<asac> TheMuso: i would think that this patch is really just for crahes at shutdown
 * ogra wonders why that is, at least the error should be different
<TheMuso> asac: that new patch of yours is already applied...
<TheMuso> asac: ah ok. Anyway it seems the first 2 hunks are already present, but hunk 3 fails to apply, so I'll look over the bug more closely later and we can chat about it when I'm more awake. :)
<asac> TheMuso: first two hunks? are you talking about the original patch we had?
<TheMuso> asac: no, the one you pastebinned.
<asac> TheMuso: i dont understand. i did an apt-get source like 1h ago
<asac> TheMuso: how can it not apply?
<TheMuso> ok i'll double check
<TheMuso> yep it applies, I wasn't doing things properly.
<seb128> hey doko
<ogra> cjwatson, uboot-mkimage made it to main without MIR ? can we do the same for flash-kernel ?
<Keybuk> ion_: as soon as I've cleared out everything that it depend son
<ogra> (it fulfills a very special usecase only, so i would expect thats ok)
<cjwatson> ogra: I'm fairly sure that somebody on the MIR team looked over it. Please don't ask me to work around that
<ogra> ok
 * ogra writes a MIR then
<tkamppeter> pitti, I see that the notifications patch for s-c-p seems to be originally created by David Barth and not by Ken VanDine, Ken only packaged it (see bug 328604). Should I assign bug 339847 to David?
<ubottu> Launchpad bug 328604 in system-config-printer "system-config-printer shouldn't use notifications with actions" [Undecided,Fix released] https://launchpad.net/bugs/328604
<ubottu> Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847
<tjaalton> has falcon been removed from jaunty?
<persia> tjaalton, bug #336389
<ubottu> Launchpad bug 336389 in falcon "Please remove falcon source and binary from Jaunty" [Wishlist,Fix released] https://launchpad.net/bugs/336389
<tjaalton> pitti: sigh, ok
<tjaalton> need to look for a replacement then
<persia> Or just port the django :)
<tjaalton> less likely ;(
<tjaalton> oops, ;)
<persia> For distribution, you might switch to a PPA.  For auto-source-building, you might look at deb-o-matic.
<tjaalton> I can't dump matlab etc to a PPA :)
<persia> Ah, no :)
<tjaalton> well, hardy still has it, so it's not urgent
<tkamppeter> kenvandine_wk: Can you have a look at bug 339847? I want to upstreamize the notification patch, but it needs a proper generic detection of the notification daemon type. Can you fix that? Thanks.
<ubottu> Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847
<kenvandine_wk> tkamppeter: i agree, will work on that
<tkamppeter> kenvandine_wk: Thanks in advance.
<kenvandine_wk> :)
<kenvandine_wk> tkamppeter: sorry i didn't catch it when we were pushing it through... seems pretty obviously wrong now
<Keybuk> I noticed an interesting side effect of the "YOU HAVE UPDATES!" behaviour today
<Keybuk> if you run apt-get update, and it's been a while, that triggers the window of death
<Keybuk> which makes you more inclined to use it than running apt-get again ;)
<directhex> the window of death can kiss my wookie
<directhex> just because OSX does it, doesn't make it right
<Keybuk> directhex: just use sreadahead instead of readahead-list
<Keybuk> then it freaks out that you've manually broken ubuntu-desktop's deps and won't do anything <g>
<wgrant> Is publisher broken?
<wgrant> There are binaries 3.5 hours in ACCEPTED.
<wgrant> s/hours/hours old/
<wgrant> And sources approaching 2 hours old that I can see.
<KaiL> already any plans how to get 3D accelleration for ATI GPUs in 9.04? I guess, "radeonhd" isn't really usable?
<cjwatson> wgrant: something to do with ports.ubuntu.com mirroring freaking out, I think
<wgrant> cjwatson: Ah, wonderful...
<cjwatson> wgrant: I believe the root cause has been fixed, but some state cleanup is going to be needed as the publisher's crashing now
<directhex> KaiL, the plan is "panic until april, then force people to use one of the slow Free drivers"
<wgrant> cjwatson: Eww.
<wgrant> Sounds lovely.
<KaiL> directhex, so you guess, there might be hope to get ATI to do their work? ;)
<directhex> KaiL, if they feel like it
<tjaalton> they are going to drop support for anything older than r6xx
<directhex> KaiL, superm1 is keeping on top of what's working and what isn't
<cjwatson> it's trying to republish kde4libs 4.1.4-0ubuntu1~intrepid1.1
<tjaalton> at least according to phoronix
<KaiL> tjaalton, yes, and definitly not adding X-Server 1.6 this month
<KaiL> (was just a news on heise.de)
<directhex> sodding ATI
<KaiL> so for R300-R500 the default can be changed to "radeon" today...
<KaiL> which gives at least 2D acc and a rather slow 3D
<Amaranth> KaiL: It's not that slow
<KaiL> situation on GPUs is getting much worse these days; intels GMA 500 is another problem: last driver ran on 7.10
<directhex> "older than r600" seems highly excessive - 2k-series radeons?
<directhex> KaiL, yes, poulsbo is junk. blame powervr.
<KaiL> 2k Serie will still be supported
<directhex> yeah, but not 1k?
<KaiL> no 1k, no Xxxx, no 9xxx
<KaiL> or in very short: support droped for all non-DX10-chips
<KaiL> Amaranth, afaik even fglrx is far behind Windows performance, so how much worse is the free one?
<KaiL> power consumption will be another problem; esp. on Laptops
<Amaranth> KaiL: fglrx should be close to the windows version, radeon should be about 70% of that, power usage is a little higher than fglrx but not much and will get better
<Amaranth> I never did any benchmarks on my X1400 or whatever though, so that's all from phoronix :P
<directhex> i'm planning on doing some benchmarking actually
<directhex> i have a gtx260 and a radeon 4870 to test with
<KaiL> I remember my old 9250, where page flip helped a lot ;)
<directhex> i have a PPA with latest radeon/nvidia in it, for intrepid, which will help
<KaiL> I guess, the radeon-driver from intrepid might differ quite a lot from the ones in jaunty ;)
<KaiL> .o0(I hope, in the right direction ;)
<directhex> well, fglrx anyway
<directhex> i wish there were more engines to test with though. where's freaking UT3? o_o
<KaiL> the "Unigine" test might be interesting ;)
<KaiL> "Tropic" should land arround 13,5 with fglrx, so that's quite demanding
<directhex> yes, ungine is one i've got
<directhex> and there's etqw as the latest id tech engine one
<directhex> but what else?
<KaiL> Nexuiz?
<KaiL> based on Q1, but much extended
<ArneGoetje> slangasek: 1. a full export from Rosetta for the -base langpacks puts significant stress onto the Launchpad database. The last export took almost 3 days to complete. The resulting tarball is about 500MB in size. The converting into language packs on rookery takes about 3.5 hours then, plus the buildds take another 2 days or so to build all the -base packs.
<ArneGoetje> slangasek: 2. the users will have to download the full set of translations every time, instead of just a few kB of diffs.
<directhex> nah, no offense to the developers, but a nexuiz benchmark is worhtless. doesn't do anything in a remotely modern way, wouldn't stress a modern gpu in a sensible manner
<KaiL> Prey is another id tech afaik, but maybe newer than etqw
<KaiL> directhex, maybe UT2004? Better than no UT engine at all
<directhex> hm, unigine is really spot on for this.
<KaiL> hehe
<KaiL> looks great, but eats TFlops for breakfast ;)
<seb128> doko, slangasek: bug #339337 due to the pygtk, numpy change
<ubottu> Launchpad bug 339337 in gnome-games "sudoko tracker crash" [Medium,Confirmed] https://launchpad.net/bugs/339337
<directhex> KaiL, my benchmarking machine is a core i7 with 6 giggles of ram. should hopefully be gpu-limited
<KaiL> I guess yes
<KaiL> I know, that in a 4GHz C2Q eben Quad-SLI is GPU limited
<KaiL> even
<tjaalton> Riddell: hey, you aware of bug 337791?
<ubottu> Launchpad bug 337791 in cmake "package cmake 2.6.0-4ubuntu2, E: Sub-process /usr/bin/dpkg returned an error code (1)" [High,Confirmed] https://launchpad.net/bugs/337791
<tjaalton> Riddell: installing kde-devel fails, so cmake needs to depend on emacsen-common (a merge would do)
<ScottK> tjaalton: Riddell is on travel at a conference AFAIK.
<ScottK> tjaalton: If you haven't, would you please comment in the bug and I'll see if I can get someone to look at it.
<doko> seb128: fgrep -r multiarray /usr/share/python-support/gnome-games-data/gnome_sudoku doesn't show anything
<slangasek> mvo, pitti: enabling protobuf is almost certainly going to cost us a langpack on one or more CDs, unless we find something else to offset it.  Are there some help translations we can split?
<tjaalton> ScottK: sure, thanks
<kirkland> siretart: absolutely;  i was planning on doing that as soon as jaunty hit beta freeze
<slangasek> cjwatson: wasn't planning to set up a wiki page for it, so much as figure out how to leverage the hardware DB
<kirkland> siretart: it should be stable enough at that point to get it into backports
<kirkland> siretart:  in the meantime, there is a ppa set aside for it: https://edge.launchpad.net/~screen-profiles/+archive/ppa
<kirkland> siretart: as for debian, that would be really cool too, if there's a DD out there who wants to run with it, i'm happy to help
<seb128> slangasek: what do they want to add to the CD?
<slangasek> seb128: ah, all we need is freetype 2.3.8?  easy-peasy
<slangasek> (IIRC 2.3.8 is /not/ the version they recalled due to ABI breakage :)
<seb128> slangasek: "all" dunno, not sure if that fix the crasher from the other day but that fixes bug #330438
<ubottu> Launchpad bug 330438 in freetype "incorrect fonts displayed in Hydro-Quebec invoices" [Low,Triaged] https://launchpad.net/bugs/330438
<slangasek> seb128: aha, gotcha
<seb128> I did try locally using a ./configure && make && LD_PRELOAD
<slangasek> seb128: add to the CD> compiz wants protobuf, a huge C++ library to speed up startup
<slangasek> seb128: (huge ~= 500KB)
<seb128> ah ok
<slangasek> seb128: is that something you could make room for?
<calc> cjwatson: the post i read on tytso's blog indicated if grub was in the MBR that GPT would work regardless of if you have EFI or not, but only for linux, Vista can read GPT but only boot from it if you have EFI which was why it wouldn't work for dual boot situations
<seb128> slangasek: we could make room, ie split gnome-games documentation for example, but how much speed win is that? ie is that worth the effort?
<seb128> I would not want to drop translations for 0.5 second win
<KaiL> calc, wasn't it, that Vista 64 requires GPT?
<pitti> tkamppeter: I think kenvandine_wk can negotiate that with david
<Keybuk> seb128: multiple seconds
<Keybuk> I've benchmarks that say it cuts compiz startup from 9s to 3s
<pitti> slangasek: splitting help translations is quite a lot of manual packaging work; I'd try my luck with lzma first
<seb128> Keybuk: are you sure? the code mvo made me tried the other day was winning 0.5 seconds I think
<Keybuk> seems to cut an average of 3-5s across the different bits of hardware I have
<calc> KaiL: no from what i read vista can only boot from GPT if your system uses EFI which other than Macs is very rare
<Keybuk> seb128: what hardware did you try it on?
<mvo> seb128: well, 0,5s from a 1s startup :)
<slangasek> pitti: well, do we have a current list of packages that benefit from lzma?
<seb128> Keybuk: that was hot cache login though so not really revelant
<mvo> seb128: it got me 1s (from 3s to 2s). but the mini9 takes a bit longer to start compiz
<pitti> slangasek: not ATM
<seb128> one CD limitation starts being *really* annoying
<tkamppeter> pitti, according to what Ken told some hours ago here on IRC he will look into it.
<calc> slangasek: doing the lzma bit shouldn't be too hard for someone who has an alternate disk
<mvo> seb128: I can help with the split
<Keybuk> seb128: which reminds me, I have some boot-performance related patches for nautilus and gnome-panel ;)
<Keybuk> I'll send them upstream, obv.
<pitti> slangasek: I'll look at the current alternate and check out the biggest ones for potential savings
 * calc thinks we should just flip a switch on the buildds to default to using lzma :)
<slangasek> pitti: and lzma doesn't help us for desktop CDs, of course, which is where we've been having trouble keeping langpacks on
<tkamppeter> pitti, I have also passed through an Apport crash report on Jockey now, triggered by Plug'n'Print.
<pitti> slangasek: oh, good point
<seb128> Keybuk: what sort of changes?
<Keybuk> seb128: removing nautilus's fade-in of the background image on initial startup
<seb128> Keybuk: please give me the bug numbers when you do so I can track that and do some nagging ;-)
<calc> pitti: iirc one of the gl libs was a big saving if it hasn't been converted yet
<Keybuk> seb128: removing gnome-panel's slide-in of the panel on initial startup
<Keybuk> because we are not 5 years old, and those two patches add 7s to the boot!
<calc> pitti: but it has been 2 years since i looked at it so things will have changed since my test
<Keybuk> (take off 7s, that is)
<pitti> calc: I think we already did that
<calc> pitti: ok
<seb128> Keybuk: urg, 7 seconds seems a lot, my GNOME login time is around 20 seconds nowadays
<wgrant> Keybuk: Thankyou! They always look crap unless everything's cached already anyway.
<tkamppeter> slangasek, what about bug 335116
<ubottu> Launchpad bug 335116 in hplip "FFE Request: HPLIP 3.9.2 released one day after FF" [Undecided,New] https://launchpad.net/bugs/335116
<seb128> Keybuk: can you please open the nautilus bug now? alex is going to roll new tarballs today most likely, could be nice to get before those and the code freeze for 2.26
<Keybuk> seb128: I'll open it today
<seb128> thanks
<Keybuk> likewise for gnome-panel
<Keybuk> the nautilus patch is the cause of the compiz black screen on startup, btw ;)
<tkamppeter> slangasek, anything still needed? I have tested and all GUI apps seem to still work correctly.
<Keybuk> turns out that sending 100s of slightly different massive textures at compiz while it's starting is not a plan made entirely of win
<Keybuk> nautilus feature, I should say
<slangasek> tkamppeter: mmm, you didn't write to the bug that you'd tested, your last mail said "please test" :)
<tkamppeter> I hoped to get Linus also to test, but he is probably not listening any more.
<slangasek> tkamppeter: if it's tested, then that's fine for an FFe, yes
<jcastro> Keybuk: sucks that that adds so much time, I was quite liking the way the panels looked when I logged in
<Keybuk> jcastro: fwict, you're lucky to see any kind of animation at all
<Keybuk> this kind of thing is far better done with KMS anyway
<Keybuk> then you can have all sorts of snazzy "fade/skew/slide/bounce in the desktop when it's ready" effects
<Keybuk> (ie. don't repaint from gdm to desktop)
<siretart> kirkland: does that mean you're looking for a sponsor to upload it to unstable? - or for DD to take over maintenance in debian?
<kirkland> siretart: both, i think
<jcastro> Keybuk: ah so it's entirely feasable for this to come back at some point in the future?
<kirkland> siretart: the package compiles and runs fine on debian
<kirkland> siretart: a couple of lines of packaging would be needed to make the debian build do the debian profiles, and the ubuntu build do the ubuntu profiles
<kirkland> siretart: but that's trivial, i'll do that
<mvo> slangasek: if I get your ok, I would like to upload the compiz changes today so that it lands in time for alpha6 - its now officially released so it will not be 0.7.9+git but nice version numbers instead :)
<kirkland> siretart: i don't really have time or interest though in maintaining the package in debian too
<siretart> kirkland: well, how about keeping you as maintainer and me in uploaders for the package? do you perhaps even have an debian packaging branch ready?
<kirkland> siretart: i don't ... let me add that bit of logic as to inserting the @ or the \o/ logo in the profile
<kirkland> siretart: after that, the build should just 'work' in debian
<kirkland> siretart: the build would just need to version it properly in dch for debian
<kirkland> siretart: are you DD?
<siretart> kirkland: ok, in that case, I'll file an ITP now and wait for you to tell me what bzr branch we will use for the debian package, OK?
<siretart> kirkland: yes, I'm a DD
<kirkland> siretart: excellent, that sounds perfect ;-)
<seb128> siretart: hello, did you read my comment before?
<siretart> seb128: I think I've skipped it, could you repeat, please?
<seb128> slangasek: oh, the freetype update also fixes the crasher
<slangasek> seb128, mvo, pitti: if nothing else changes in size, we *currently* have room for protobuf without dropping any langpacks; do you think it's reasonable to reclaim that space somewhere after alpha6?
<seb128> siretart: I was asking if you know if anybody look at the ffmpeg-debian bugs in launchpad, the jaunty version seems to be crashland
<slangasek> seb128: ah great, I'll make sure I get that packaged up today.  Do you have a bug number for the rendering issue?
<seb128> slangasek: can we have an estimation of what language packs we have, which ones we could add by making some space and how much we need by language?
<seb128> slangasek: bug #330438
<ubottu> Launchpad bug 330438 in freetype "incorrect fonts displayed in Hydro-Quebec invoices" [Low,Triaged] https://launchpad.net/bugs/330438
<siretart> seb128: I've noticed that a huge bunch of crashed were reassigned to ffmpeg, but I really suspect that most of them are actually caused by gstreamer0.10-ffmpeg
<seb128> slangasek: bug #277294 is the crasher
<ubottu> Launchpad bug 277294 in freetype "evince crashed with SIGFPE, trying to seek in KXTGA930.PDF" [High,Confirmed] https://launchpad.net/bugs/277294
<siretart> seb128: every one I've seen so far miss an example file to demonstrate the crash
<slangasek> seb128: on liveCD, we're currently down to en es xh on amd64 and en es xh pt de fr on i386
<Keybuk> bryce_: around?
<slangasek> seb128: pitti has a langpacksize script that says how much space each of those needs; I don't remember the original source for the script
<pitti> slangasek: cd /usr/share/gconf/schemas; cat ekiga.schemas epiphany.schemas gnome-search-tool.schemas desktop_gnome_url_handlers.schemas | gzip -9 | wc -c
<pitti> 608904
<siretart> seb128: and since I have no idea about the gstreamer0.10-ffmpeg codebase (but a bit of ffmpeg), I fear there is not much I can do about them other than trying to reproduce them with ffplay
<slangasek> seb128: but it's roughly 9MB for pt, 5MB for de, 6MB for fr
<seb128> siretart: why do you think that's due to gst-ffmpeg?
<pitti> slangasek: in other words, by rebuilding four packages, we should be able to claim back 600 KB
<seb128> siretart: there is several bugs with example and valgrind logs which show libavcodec issues
<siretart> seb128: because I know that gst-ffmpeg uses quite a bunch of ffmpeg internals that are not supposed to be used externally
<pitti> seb128: langpacksize: http://people.ubuntu.com/~pitti/scripts/langpacksize
<slangasek> pitti: if you think that's reasonable, then I'm ok to have mvo upload the protobuf change
<pitti> seb128: orignal is in bzr get lp:langpack-o-matic
<seb128> slangasek, pitti: thanks
<siretart> seb128: and slomo regularily tells me about problems when I update ffmpeg
<pitti> slangasek: yes, I want to rebuild those packages with large gconf translation trees anyway, to downsize them
<seb128> siretart: seems we need better coordination there then
<slangasek> mvo: ok, please go ahead with protobuf for alpha6
<pitti> slangasek: ekiga alone will give us 270 KB
<pitti> slangasek: I'll upload a rebuild
<mvo> thanks slangasek and pitti \o/
<siretart> seb128: of course valgrind reports problems in avcodec. But since avcodec is a *decoding* library, it's really a garbage in - garbage out problem
<siretart> valgrind cannot possibly know if gst-ffmpeg is passing garbage to avcodec
<slangasek> seb128: if we want to be able to get de or fr onto amd64 desktop, though, we still need to find more savings :(
<seb128> siretart: ok, so you are not happy with stacktrace + valgrind + example, what else do you need?
<slangasek> (just a little bit - less than 1MB)
<siretart> and that's why I have to insist to have example files attached
<seb128> slangasek: I will have a look to how much gnome-games split would give us
<slangasek> (unless we want both, then we need 8MB :)
<siretart> seb128: I need the bug to be reproducible with ffplay
<pitti> slangasek: ah, on the desktop CDs, the savings of those rebuilds will be bigger, since it also affects /var/lib/gconf/defaults/
<slangasek> pitti: great :)
<siretart> then I can forward it upstream, but not earlier, unfurtunately
<seb128> siretart: bug #339854 has a video available for download
<ubottu> Launchpad bug 339854 in ffmpeg-debian "nautilus crashed with SIGSEGV in memset()" [Medium,New] https://launchpad.net/bugs/339854
<seb128> siretart: it's a bit big for my download speed but if you can give it a try
<siretart> seb128: yeah, such huge example files are really a PITA. in most case the first few MB are sufficient to expose the bug
<siretart> another reason why I have to insist to have the example files *ATTACHED* to the launchpad report, not only linked
<seb128> siretart: can you ask for that on this bug? using dd should do the trick?
<seb128> siretart: bug #335595 has an example too
<ubottu> Launchpad bug 335595 in totem "totem-gstreamer crashed with SIGSEGV" [Undecided,Invalid] https://launchpad.net/bugs/335595
<seb128> and bug #335595
<siretart> seb128: see also http://ffmpeg.org/bugreports.html, section "Submitting Sample Media"
<siretart> seb128: the video referenced from bug #339854 works just fine with ffplay.
<ubottu> Launchpad bug 339854 in ffmpeg-debian "nautilus crashed with SIGSEGV in memset()" [Medium,New] https://launchpad.net/bugs/339854
<slangasek> dendrobates: ubuntu-server ISOs are still 8MB oversized
<slangasek> (well, 7 and change)
<siretart> seb128: video from bug #335595 works fine for me as well
<ubottu> Launchpad bug 335595 in totem "totem-gstreamer crashed with SIGSEGV" [Undecided,Invalid] https://launchpad.net/bugs/335595
<dendrobates> slangasek: I am checking it now.
<seb128> siretart: ok, so basically totem and rhythmbox are crash land in ffmpeg code and that's nobody's problem, great
<ogra> slangasek, you are ubuntu-mir as well, right ?
<slangasek> ArneGoetje: thanks for clarifying wrt the -base problem.  That makes sense, even though it makes it harder to estimate for alphas
<slangasek> ogra: nope
<siretart> seb128: and that's a pretty common experience I have with these forwarded bugs. in the last weeks, I focused on getting ffmpeg updated to 0.5 and started to work on mplayer rc3
<ogra> meh
<siretart> seb128: no, that's not what I've said
<calc> seb128: do you know when we will have 2.26.0, after alpha 6 correct?
<siretart> seb128: I've said the problem is most likely in gst-ffmpeg having broken demultiplexers and feeding garbage to libavcodec
 * ogra tries to fins a -mir person to approve bug 339947 before A6
<ubottu> Launchpad bug 339947 in flash-kernel "MIR for flash-kernel" [Undecided,New] https://launchpad.net/bugs/339947
<seb128> siretart: yeah, let's focus on making a player which we ship with no ubuntu flavor be stable and don't bother about everything else
<ogra> *find even
<seb128> siretart: sorry I'm slightly frustrated, I should calm down before continuing this discussion
<siretart> seb128: I see
<ogra> oh, lool is -mir, i didnt know
<seb128> the end result is the same, totem and rhythmbox are crash land and nobody bother
 * ogra grins widely in lool's direction ... 
<seb128> calc: yes
<siretart> seb128: what would be really helpful would be someone knowledgable of gst-ffmpeg internals
<jcastro> seb128: can you look at python-webkitgtk sometime? I think it's in NEW
<seb128> jcastro: why is it in NEW?
<jcastro> binary NEW?
<calc> seb128: ok thanks :)
<siretart> seb128: I could turn it the other way round: remove gst-ffmpeg from those systems, and the crashed would dissappear as well: most of the presented videos won't work in totem at all and all folks would be using vlc instead (the package I've been working on before mplayer and ffmpeg)
<jcastro> seb128: I think it was renamed? https://edge.launchpad.net/ubuntu/jaunty/+source/pywebkitgtk/1.0.2-1ubuntu1
<seb128> jcastro: sorry I've a zillion of things going on right now, any urgency there?
<seb128> siretart: that would not be the other way round, that's still "let's screw users who run ubuntu softwares"
<siretart> seb128: and as for 'frustration', I'm slightly frustrated as well about the load of unreproducable crashers that are beeing reassinged to ffmpeg as well
<jcastro> seb128: we're blocking a gwibber upload but it's not critical, is there someone else I can ping?
<pitti> slangasek: while we are at CD space hog confessions, I also need to work on bug 335888, i. e. add some more themes
<ubottu> Launchpad bug 335888 in gnome-themes-extras "default set of installed themes needs to be changed" [High,In progress] https://launchpad.net/bugs/335888
<seb128> jcastro: you can let archive admin do their work when they have a free slot, or try another member of the team, today is slangasek's day
<pitti> slangasek: not necessarily for a6, though
<jcastro> seb128: ah ok, I didn't know there was a rotation, thanks
<dendrobates> cjwatson: open-iscsi-udeb depends on scsi-modules-2.6.28-2-386-di which pulls in the old kernel.  Can you fix?
<siretart> seb128: uh, I think an incapable player that can be replaced with a capable one is slightly less frustrating than having to replace a crashing one with a capable one. but YMMV, of course
<slangasek> pitti: what will that cost us (in MB or in bloodpressure)? :)
<pitti> slangasek: don't worry, just about 10 MB
 * pitti sees slangasek jump
<pitti> slangasek: let me check
<slangasek> pitti: I think you mean "lunge" :-)
<geser> jcastro: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
<seb128> siretart: it would help if somebody would go through those bugs and write wiki instruction on how to triage specific cases
<slangasek> dendrobates: I thought that open-iscsi-udeb dep was going to go away?
<pitti> slangasek: oooh, F***
<seb128> siretart: or are least triage some bugs as an example and give a pointer on the bugsquad list
<pitti> slangasek: I shouldn't have said that; I expected some 300 KB
<jcastro> geser: sweet, thanks for that
<slangasek> (didn't I have a discussion with kirkland about this @ the sprint?)
<seb128> siretart: right know bug triagers have no clue about what to do with those bugs and ffmpeg maintainers ignore most of those because they don't have the requested informations
<pitti> slangasek: but Ken attached a 5.3 MB tarball
<slangasek> haha
<pitti> slangasek: oh, but hang on, not everything is needed by default
<pitti> slangasek: okay, should be about 800 KB
 * slangasek nods
<pitti> slangasek: I'll work on adding the themes to gnome-themes-extra today, but I won't do the seed change for a6
<siretart> seb128: oh, I remember having tried that before, with very little success :(
<slangasek> pitti: ack, thanks
<pitti> slangasek: after I did the packaging, I have a precise idea about the size
<kirkland> slangasek: i remember discussing it;  don't remember the conclusion; do remember that we couldn't make any change at the moment due to the freeze :-)
<seb128> siretart: trying what? triaging some? if you do email bugsquad to let them know what to use as example
<seb128> siretart: or to point to the wiki guidelines
<seb128> siretart: I don't think i've read any emails about this before
<siretart> seb128: however that involved rather xine + ffmpeg. perhaps (if I find the triaging instructions of ffmpeg in the wiki) I can try to improve them again
<seb128> siretart: I for one would be happy to use stock replies when reassigning
<slangasek> kirkland: hrm, I don't remember that, I would've happily given the go-ahead for the open-isci change - but maybe we were waiting for a kernel change first
<siretart> seb128: where would you expect the stock reply for an incomplete ffmpeg bug to be found?
<seb128> siretart: https://wiki.ubuntu.com/Bugs/Responses
<seb128> siretart: it has a "xine-lib and ffmpeg bugs" section already
<seb128> siretart: should that be used for gstreamer crashers as well
<siretart> aah, these are the notes I've been looking for as well
<siretart> seb128: I'd suggest the xine part to be removed, and ahve it applied to *ALL* bugs being reassigned to ffmpeg
<seb128> ok
<seb128> pedro_: ^ can you get that done?
<seb128> pedro_: not sure if bugsquad discuss changes for this page or directly edit
<slangasek> kirkland, dendrobates: oh, but it's amd64 that's the oversized image, so scsi-modules-2.6.28-2-*386*-di isn't relevant there?
<slangasek> (not that we shouldn't trim it anyway...)
<tkamppeter> slangasek, HPLIP 3.9.2 uploaded.
<pedro_> seb128: yes no problem, no need to discuss such changes if the person who take care of those bugs is requesting that, i'll do it
<slangasek> tkamppeter: cheers
<seb128> pedro_: thanks
<kirkland> slangasek: so that dep just needs to be dropped from open-iscsi-udeb?   reasoning that the kernel provides it?
<slangasek> kirkland: maybe.  actually, that may not really be the fix we want; scsi-modules should be in the initramfs, so germinate should be smart enough that we don't need to change open-iscsi further, hmm
<slangasek> kirkland: so let me poke at that end
<slangasek> anyway, amd64 is still oversized
<dendrobates> slangasek: perhaps not, the mysteries of di are many, and it is a bug.
<siretart> pedro_: if you don't mind, I will extend that part a bit later today, ok?
<pedro_> siretart: no problem at all, feel free to do it
<seb128> siretart: thanks, and sorry for the rant, but half of the crashers we get on multimedia apps right now are in libavcodec
<slangasek> dendrobates: something pulls libc6-i386 into the server CD?
<slangasek> yuck, why is samba-tools being pulled in?
<siretart> seb128: sure, no problem. but as said, I think that more than 2/3 of those bugs don't actually belong there.
<dendrobates> slangasek: samba-dbg is also there.
<siretart> but rather gst-ffmpeg
<slangasek> dendrobates: samba-tools is much less useful than samba-dbg :-)
<seb128> siretart: perhaps we should really go back at making gst-ffmpeg use its ffmpeg copy and not the system one if that doesn't work
<slangasek> apparently we're including "everything built from samba source" in server-ship, blargh
<siretart> seb128: I was about to propose that as well. but we buy that with security maintenance nightmare. the "proper" solution would be to fix gst-ffmpeg, I'd think
<slangasek> dendrobates, zul: I propose dropping swat, samba-tools, and samba-dbg from server-ship, does that sound reasonable?
<seb128> siretart: nobody has a clue about gst-ffmpeg apparently so that's not really going to work
<dendrobates> slangasek: yes, I have some other changes as well.  I'll get back to you in a bit.
<siretart> seb128: I leave that discussion better to the gnome and security team, and prefer to focus on ffmpeg
<seb128> siretart: ok thanks
<slangasek> dendrobates: libsmbclient-dev, too
<slangasek> dendrobates: so that saves you at least 43MB on the amd64 CD, we're probably good now :)
<slangasek> btw, I see php5 is also seeded by source, and there's a php5-dbg in the archive now too
<lool> ogra: So it's needed in main?
<ogra> lool, right
<slangasek> php5-dbg is a measly 8MB though
<ogra> lool, to finish the slug install
<lool> ogra: Why so? -- just curious
<ogra> lool, d-i needs udebs it uses in main
<ogra> lool, to enable d-i to have flash-kernel in the slug firmware flash-kernel (and its udeb) indeed needs to move
<ogra> else the udeb wont be in the d-i firmware image and d-i automatically switches to a bootloader-less install
<tkamppeter> Anyone is maintaining a package which is translated into 40 or more languages by upstream? Do you always get one spam mail per language from Rosetta when you upload it?
<tkamppeter> This happened to me now with system-config-printer.
<ScottK> tkamppeter: The last guy that uploaded KDE l10n got over 14,000 before he got #launchpad to kill it.
<ogra> which leaves you with a fine installed userspcae on your USB disk but no kernel in the flash ... so it reboots into the d-i firmware again after install ... starting over
<pitti> tkamppeter: yes, known bug
<KaiL> slangasek, is dropping swat such a good idea?
<slangasek> oh suck, lsb-core implies lib32z1 on amd64?
<slangasek> KaiL: yes, it's a *very* good idea
<slangasek> swat is terrible
<slangasek> but I'll defer to the server team if they think they want it
<cjwatson> calc: I have seen systems for which that doesn't hold, unfortunately. I definitely know of BIOSes that look at the partition table in more complicated ways than that
<smb_tp> pitti, Hi Martin, I somewhat remember that at some sprint someone got the solution to my console-kit-daemon spews general protection messages on ubuntu-server. I can remember the solution was to install some package but I forgot even who came up with the solution. Was that you?
<cjwatson> dendrobates: I'll see what I can do but it's a bit of a complicated mess
<pitti> smb_tp: hm, it *might* be bug 275432
<ubottu> Launchpad bug 275432 in policykit "libpolkit requires files from policykit for polkit_context_init to work" [High,In progress] https://launchpad.net/bugs/275432
<cjwatson> kirkland: please leave open-iscsi-udeb alone for now rather than perturbing the problem :-
<cjwatson> )
<kirkland> cjwatson: sure, no problem
<smb_tp> pitti, Might be. Was not installed. Just installed it and will see. Thanks
<slangasek> seb128: mmm, I think freetype 2.3.8 might've been the one with ABI breakage after all
<slangasek> 2.3.9 is due out soon, though
<seb128> slangasek: hum, ok
<seb128> slangasek: any change you backport fixes for the issues I poined if those are not part of the ABI changes? ;-)
<slangasek> (the mailing list archives are down so I'm having a hard time checking - but 2.3.8 is missing from some of the savannah mirrors, which is why I suspect)
<slangasek> seb128: mm, I'll probably check on upstream's ETA for the new version first
<seb128> slangasek: ok thanks
<KaiL> just found a driver for the matrox M-Series - anybody interested in packaging it? ;)
<cjwatson> there are some very subtle things that happen when you put udebs into seeds other than the installer seed. This open-iscsi-udeb thing is one of them. Unfortunately open-iscsi-udeb probably shouldn't go in the installer seed because that would add 170KB to all the other images.
<lool> ogra: Ok; I thought d-i could be built from universe, thanks for letting me know
<cjwatson> yes, ogra is correct
<ogra> lool, not sure about that, cjwatson might have more info here
<ogra> ah
<cjwatson> d-i only uses bits from main
<cjwatson> (and restricted)
<lool> cjwatson: Thanks
<slangasek> seb128: found a list archive that's up - 2.3.8 is the broken one - 2.3.9 is expected "within a week or so" of March 3
<cjwatson> I wonder if the right answer is to make server-ship inherit from installer. IIRC that caused some subtle problem several years ago though ...
<slangasek> seb128: if they don't deliver, I'll look at backporting
<cjwatson> it would make some kind of logical sense though
<lool> ogra: Note: XB-Subarchitecture might have to be extended in control for babbage and perhaps for marvell if we ever support the installer there -- I doubt it though
<ogra> right, we also might need ubuntu patches for babbage
<lool> Well basically flash-kernel will have to be porter including its udev parts
<ogra> thats why i mentioned it in the MIR
<lool> ogra: What's the MIR bug?
<seb128> slangasek: thanks
<ogra> lool, Bug 339947
<ubottu> Launchpad bug 339947 in flash-kernel "MIR for flash-kernel" [Critical,New] https://launchpad.net/bugs/339947
<lool> Erf the rules have this:
<lool> pwd=$(shell pwd)
<lool> TOPDIR := $(shell pwd)
<lool> t=${TOPDIR}/debian/${PACKAGE}
<lool> And none of these vars is ever used
<ogra> heh
<ogra> its as odd as all the other debian arm scripting
<ogra> (like swapping kernels and d-i while thats not needed etc)
<lool> ogra: approved
<ogra> thanks
<lool> ogra: well := $(shell pwd) should be $(CURDIR)
<ogra> cjwatson, i assume flash-kernel will be pulled in automatically without any of us doing anything (prio should be correct for that) once its in main ?
<lool> and defining pwd to not use it a line below is a bit weird, just like defining stuff you don't use
<ogra> looks liek a leftover from some hacking or so
<cjwatson> ogra: please add flash-kernel-installer to the installer seed
<cjwatson> preferably in an appropriate section with [armel]
<lool> ogra: I'm on it
<dholbach> doko: geser told me that CDBS was patched to use  --install-layout=deb  - would it make sense to change that in a more central place?
<ogra> lool, on what ? seed or fixing the vars ?
<lool> seeds
<ogra> thanks
<cjwatson> lool: I've removed the unused cruft from debian/rules upstream
<lool> cjwatson: thanks
<ogra> well, that would have been my first seed change this cycle
 * ogra cant belive he had nothing that touched the seeds in jaunty 
<doko> dholbach: what is more central?
<lool> (pushed)
<ogra> thanks :)
<dholbach> doko: or patch debhelper also?
<geser> doko: dholbach found out that debhelper7 is missing that option
<doko> dholbach: debhelper doesn't call python setup.py install, does it?
<geser> doko: dh7 does it in dh_auto_install
<doko> geser: sure, then please go ahead
<dholbach> I think I missed some memo... why is this necessary atm? I'd just like to explain it properly when it comes up again :)
<geser> dholbach: python2.6 transition
<dholbach> that much I knew already...  :)
<dholbach> I'll try to find out more info - nevermind :)
<ScottK> dholbach: There was a mail where doko explained this.  I think it was ubuntu-devel.
<geser> https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027439.html has some explanation about it
<dholbach> ahhh!
<dholbach> got it
<dholbach> thanks a lot
<Keybuk> we need a developer's knowledge base with such things
<dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase links to https://wiki.ubuntu.com/UbuntuPackagingChanges - maybe a note about it should be on there?
<geser> dholbach: apply http://www.bienia.de/tmp/debhelper.diff on debhelper and python-django-lint will build fine then
<jdong> Dear World: Which xorg-video-intel freezes bug is the one that I am experiencing in Jaunty? :)
<dholbach> geser: thanks a bunch
<smb_tp> pitti, This seems to have been that issue. Looks like the libpolicy-kit-daemon messages are gone now
<Keybuk> cjwatson: I'm -> <- this far away from writing ubuntuhelper
<ogra> haha
<Keybuk> which will contain one tool, uh_conffiles
<Keybuk> that reads a file from the debian directory that contains things like:
<Keybuk>   rm /some/file
<ogra> great naming :)
<Keybuk>   mv /another/file /somewhere/else
<Keybuk> and generates all the preinst, postinst and postrm mumbo-jumbo
<ogra> so you should call it ubuntugenerationhelper ... that would make it ugh_conffiles :)
<pitti> Keybuk: I wouldn't mind doing that in debian/control instead, or debian/conffiles
<dholbach> Keybuk: talk to mvo about it... I guess he'll add a     uh_maintainerscripts        :-)
<pitti> declarative, not command-based
<Keybuk> how would you do it declarative?
<Keybuk> debian/conffiles is already an "owned" file
<Keybuk> dholbach: why mvo?
<dholbach> Keybuk: I think he has a strong opinion on where maintainer scripts should go :)
<Keybuk> dholbach: in /var/lib/dpkg/info .. ?
<pitti> debian/control-> ObsoleteConffile: /etc/foo\nRenamedConffile: /etc/foo /etc/bar
<pitti> or so
<Keybuk> dholbach: unless I'm missing something
<mvo> Keybuk: I dislike maintainer script failures strongly during upgrades
<Keybuk> pitti: why that way?
<dholbach> Keybuk: I think "to hell" would be his answer
<dholbach> ... maybe in a politer way
<Keybuk> mvo: well, the kinda point here is to do the magic in one tested place ;)
<Keybuk> instead of replicating it a billion times badly
<Keybuk> even debhelper get sit wrong
<doko> dholbach: sorry, currently in a meeting ...
<pitti> Keybuk: with declarations we can provide one robust central implementation, and change it; replacing scripts with other scripts won't fix the problem that we currently have with it?
<Keybuk> (fails to cope with the aborted upgrade case)
<Keybuk> pitti: but then you hit a simple problem
<dholbach> doko: sure, no worries
<mvo> Keybuk: yeah, having a central place is already a great step forward
<pitti> (which is largely that those scripts are often wrong, and incomplete)
<Keybuk> what reads debian/control?
<Keybuk> putting it in debian/control just seems wrong
<cjwatson> I'd be happy to have a conffile management helper but (a) I don't think it should have rm and mv type syntax because that will encourage people to think they can do other shell-like things there (b) would it actually be hard to get it into debhelper? it sounds to me like the sort of thing that joeyh would accept even if he hasn't worked out the interface yet
<Keybuk> after all you don't have the contents of debian/*.install, debian/*.manpages, etc. in there
<pitti> Keybuk: the same mechanics that also reads Depends:?
<pitti> Keybuk: anyway, I'm not fussed about control, but fussed about just saying what you mean, instead of telling dpkg how to do it
<cjwatson> if this were to be done in dpkg proper, it probably shouldn't be in control, but in another file in the control area of the .deb
<Keybuk> cjwatson: getting it in debhelper means writing in Perl
<Keybuk> my Perl-fu is so rusty, I would rather not
<cjwatson> Keybuk: let me dry your tears
<cjwatson> it's not that hard :)
<Keybuk> especially if it has to be reviewed by someone as ... careful as joeyh
<calc> cjwatson: ah ok (wrt gpt issue)
<cjwatson> you can run it through me first, I'll put it into joeyh-compatible form
<siretart> pedro_: seb128: I've now enhanced https://wiki.ubuntu.com/Bugs/Responses#ffmpeg%20(mostly%20libavcodec%20and%20libavformat)%20bugs - it now contains instructions for both triagers and submitters. I hope that's okay like it is...
<cjwatson> joeyh has historically liked my perl
<Keybuk> maybe
<Keybuk> will see
<Keybuk> actually I'd want a third option in there
<cjwatson> the other thing is that it should take care of the version guards too, so the syntax suggested above is a bit too simple
<Keybuk> "move", "remove" and "rename or drop"
<Keybuk> actually, joey when I talked about it was of the strong opinion that it shouldn't
<Keybuk> and that you should instead treat the file simply as a list of changes you need to make to any installed package
<seb128> siretart: there is some wiki formatting issue but otherwise that looks good, thanks!
<cjwatson> hmm, ok, I was just going with modelling existing behaviour
<davmor2> siretart: did you miss something it looks like there is some code visible there that shouldn't be
<siretart> davmor2: possibly. The page uses more moin-FU that I know.
<siretart> than I know.
<davmor2> siretart: have a quick look and see if you have a trailing space after the table enclosure
<pedro_> siretart: looks good, thanks you. btw I've fixed the wiki format
<davmor2> pedro_: what was it?
<pedro_> davmor2: the spaces were causing the issue
<davmor2> :)
<Keybuk> cjwatson: could you push your recent pcmciautils upload to the repository plz :p
<calc> does anyone know what script keeps creating a '1' file in /root ?
<calc> probably some incorrect redirection to /dev/null
<ebroder> Anyone willing to do an upload for bug #339449? I'd like it to make alpha 6
<ubottu> Launchpad bug 339449 in mit-scheme "FeatureFreezeException: Merge mit-scheme with Debian" [High,Confirmed] https://launchpad.net/bugs/339449
<cjwatson> kekey	
<cjwatson> oops
<cjwatson> Keybuk: uh, my branch is a checkout
<cjwatson> Keybuk: http://people.ubuntu.com/~cjwatson/bzr/pcmciautils/ubuntu already up to date
<Keybuk> cjwatson: lies
<Keybuk> cjwatson: because I can quite clearly see an upload in the archive
<Keybuk> made by you
<Keybuk> that's not in this repo ;)
<cjwatson> 'bzr revno sftp://rookery/home/cjwatson/public_html/bzr/pcmciautils/ubuntu/' is r74
<cjwatson> $ bzr revno; head -n1 debian/changelog
<cjwatson> 74
<cjwatson> pcmciautils (014-4ubuntu3) UNRELEASED; urgency=low
<Keybuk> ahh
<Keybuk> doh
<Keybuk> I'm reading this backwards ;)
<Keybuk> you _haven't_ made an upload
<cjwatson> that's correct
<Keybuk> I assume it's ok to upload that?
<cjwatson> sure
<cjwatson> it just wasn't worth an upload just for that
<Keybuk> cjwatson: lp:~scott/pcmciautils/ubuntu
<Keybuk> (when it pushes ...)
<Keybuk> pushed
<primes2h> pitti: I tested  bug #211710 package from -proposed works nice!
<ubottu> Launchpad bug 211710 in xaos "Wrong characters codification in Xaos translation - broken UTF support" [Undecided,Fix committed] https://launchpad.net/bugs/211710
<primes2h> pitti: you can go on on that.
<pitti> primes2h: thansk! can you please say so in the bug report?
<doko> ubuntu-archive: please could you process openjdk-6/6b14-1.4.1-0ubuntu3 in NEW?
<pitti> slangasek: okay, I shook a little more than 1 MB out of my sleeve
<primes2h> pitti: already done! ;-)
<slangasek> pitti: :-)
<kirkland> what does a leading % mean in the seeds?
<kirkland> eg, %exim4 ?
<slangasek> kirkland: "all binaries from this source"
<slangasek> i.e.: "this is wrong for any seed that's on a CD" :-)
<kirkland> dendrobates: ^
<kirkland> dendrobates: there's a number of those on server-ship
<dendrobates> kirkland: fix them.
<kirkland> dendrobates: yessir
<slangasek> :-)
<cjwatson> Keybuk: pulled, thanks
<Keybuk> cjwatson: that should reduce the ubuntu diff even further, right?
<liw> cjwatson, "the majority of problems people report with upgrades using apt-get or aptitude are in fact bugs in individual packages, and it's far simpler to fix them there than to fix them in individual packages" -- I assume you meant "in update-manager" at the end? or am I too tired to understand anything?
<cjwatson> Keybuk: I think so, haven't checked yet
<cjwatson> liw: yes, apparently I did
 * cjwatson corrects himself on sounder@
<slangasek> dendrobates, kirkland: ubuntu-server down to ~660MB :)
<kirkland> slangasek: nice ;-)
<kirkland> slangasek: i'm going to send you and dendrobates a diff in a moment, of the cleanups he requested, plus the "%" expansion (compression), before committing it
<slangasek> kirkland: a diff or a mergeable branch?
<kirkland> slangasek: whatever you would like
<kirkland> slangasek: i was just going to attach a diff, but a branch would be just as well
<slangasek> branch please :-)
<kirkland> slangasek: sure thing
<slangasek> seb128, doko: libgegl-0.0-0 depends on libavformat52 depends on libavcodec52, which is blacklisted from the CDs per the TB; are you aware of this, is this related to the ffmpeg-debian discussion above?
<seb128> slangasek: I've no clue about libgegl and ffmpeg
<slangasek> ok
 * slangasek aims the nukes at gegl debian/control
<slangasek> nice, the avformat b-d was added in an Ubuntu upload, with no mention in the changelog :/
<Keybuk> slangasek: can I do #338825
<Keybuk> doesn't affect CD size
<seb128> bug #338825
<ubottu> Launchpad bug 338825 in bootchart "Replace with Python version" [Undecided,New] https://launchpad.net/bugs/338825
<cjwatson> Keybuk: FYI people are reporting that they still have problems with installer device handling races :-(
<cjwatson> in case you haven't seen
<cjwatson> I haven't got far enough to reproduce it myself yet
<Keybuk> cjwatson: I saw timo reopen the bug
<Keybuk> but then I also remember him saying it was fixed
<cjwatson> well, races are like that ...
<cjwatson> I thought he said "I think it's fixed but am not quite sure" but ...
<kirkland> slangasek: dendrobates: https://code.edge.launchpad.net/~kirkland/+junk/ubuntu.jaunty
<Keybuk> cjwatson: sure
<slangasek> Keybuk: no new deps of a strange and furry nature?
<Keybuk> slangasek: just python, cairo, etc.
<Keybuk> drops all the strange java entanglements
<slangasek> Keybuk: ok, cool
<kirkland> slangasek: i'll await your review of those changes before committing
<kirkland> slangasek: or you're welcome to merge/commit
<cjwatson> Keybuk: davmor2 also said he encountered this, BTW
<slangasek> kirkland: is exim4 binary package the right one to seed on DVD?
<slangasek> I know exim4 has umpteen different binaries
<slangasek> hmm, why do we still seed subversion, we should replace that with bzr-svn ;)
<kirkland> slangasek: oh, good question
<kirkland> slangasek: moving stuff to the dvd was the conservative decision by dendrobates
<slangasek> yes, I'm just thinking aloud
<kirkland> slangasek: ie, to keep it around, but get it out of the cd seed
<kirkland> slangasek: ah, that was a joke, no?
<slangasek> and trying to judge by the channel's reaction whether it's a good idea
<ScottK> I know a number of people who have a real commitment to svn for $WORK and so I think we really do want it in Main.
<ScottK> It may not be used so much here, but it's definitely used a lot out there ....
<slangasek> kirkland: not a joke, just a thought
<cjwatson> I don't think I'd want to use bzr-svn for e.g. upstream d-i commits
<slangasek> true
<slangasek> kirkland: seems unnecessary to seed mysql-common directly
<slangasek> ditto postgresql-common
<ScottK> Approximately everything I use a VCS for outside Ubuntu is svn plus a very little git.
<kirkland> slangasek: that crossed my mind
<slangasek> kirkland: should we seed apache2-mpm-prefork directly?  I think the only reason anyone cares about it is php5, which is also seeded
<slangasek> "" apache2-common
<slangasek> actually, apache2-common doesn't exist
<kirkland> slangasek: dropped each of the -common
<slangasek> (it's apache2.2-common, and yadda yadda)
<slangasek> cool
<kirkland> slangasek: -prefork ...  i suppose that's fine too
<pitti> Keybuk: the aliases you added to the Ubuntu kernel, are they upstream as well?
<kirkland> slangasek: ie, letting -prefork get pulled in by php
<pitti> Keybuk: I'm a bit concerned about tailoring our userspace tools to the ubuntu kernel too much (or the other way round, deviating our kernel too much)
<kirkland> slangasek: re: exim, your choices are: exim4-base, exim4-config, exim4-daemon-heavy, exim4-daemon-light-dbg, exim4-daemon-light, exim4-dbg, exim4-dev, eximon4
<kirkland> slangasek: and just "exim4"
<Keybuk> pitti: they will go upstream shortly
<pitti> Keybuk: ah, nice
<Keybuk> some of them already have
<kirkland> slangasek: just "exim4" seemed to be the most direct
<slangasek> kirkland: sounds good
<pitti> Keybuk: I bought a 16 GB usb stick today, so that I can install jaunty on it and play around with sreadahead and compare how a flash disk feels like :)
<Keybuk> pitti: you'll be massively slowed down by USB
<slangasek> kirkland: dunno if that will cause /all/ of the -daemon- packages to be pulled onto the DVD, but I also don't know whether we want that
<pitti> Keybuk: (I want it as a "portable workstation" anyway, so I won't install it in vain)
<kirkland> slangasek: well, dendrobates and i sort of discussed that exim4 is not the preferred MTA of the server team, which is why we're moving it off of the cd
<slangasek> yes
<slangasek> it's not supposed to be the preferred MTA in Ubuntu; it kinda gets pulled in because it's the default in Debian
<slangasek> (which we're trying to get decoupled in squeeze)
<ScottK> AFAIK Canonicla uses it internally too.
<ScottK> Canonicla/Canonical.
<slangasek> ScottK: dunno; not for mail.c.c.
<ScottK> slangasek: Just checked the most recent bugmail header I got from LP and it has Exim in the path.
<ScottK> At least it claims to be Exim.
<slangasek> heh, ok
<RainCT> seb128: thanks for sponsoring scim :)
<seb128> RainCT: you're welcome; did anybody sent the change to debian btw?
<seb128> I've to run bbl
<cjwatson> dendrobates,kirkland: I've committed a seed change to get rid of the -386-di stuff on server CDs that you mentioned
<kirkland> cjwatson: cool, thanks.
<kirkland> slangasek: are you still reviewing that branch I posted?  or are we just hung up on exim4?
<slangasek> kirkland: oh - not hung up, I was done reviewing.  Do you want to commit or shall I?
<kirkland> slangasek: i can
<RainCT> err.. why did LP just spam me with something about "translation import"? :P
<slangasek> kirkland: the +junk branch doesn't appear to reflect your -common changes, so I guess you should :)
<kirkland> slangasek: haven't committed those yet
<slangasek> ok
<kirkland> slangasek: what's your thought on the exim4 bits?
<slangasek> kirkland: I suppose it's important to have all of the exim4 -daemon- variants included on the DVD, at least if there's room
<mvo> RainCT: a "feature" in LP - there is a bug open and it anoys a lot of people
<mvo> I just got 300 mails from LP
<RainCT> ouch
<kirkland> slangasek: okay, sounds good
<kirkland> slangasek: minus exim-daemon-light-dbg, of course
<ScottK> RainCT: I know one guy got 14,000.
<calc> pitti: ping
<directhex> bleh, another patch needed for all current releases for pidgin
<Laney> what died?
<directhex> icq
<directhex> it's "maybe" a server-side fault
<Laney> huge bug with a million people commenting ahoy?
<directhex> Bug #340075
<ubottu> Launchpad bug 340075 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.") (2009-03-09)" [High,Confirmed] https://launchpad.net/bugs/340075
<elmo> wiki.ubuntu.com/SeedManagement could do with some love
<elmo> lots of Gutsy references
<emgent> hallo
<kirkland> RainCT: hi, you were asking about the kill-window keybinding ....
<kirkland> RainCT: i actually replaced F5 with "reload profile" right around UI-freeze
<kirkland> RainCT: kill window is still <ctrl-a-k>
<kirkland> RainCT: which was easier than "ctrl-a-: source $HOME/.screen-profiles/profile"
<kirkland> RainCT: and F5 sort of has that "reload" mentality
<kirkland> RainCT: sorry for the inconvenience
<kirkland> Keybuk: question about "  * Bump debhelper version for updated udev rules path, add Breaks to ensure we use the right version of udev."
<kirkland> Keybuk: i'm trying to get kvm-84 to build on hardy for a potential backport
<kirkland> Keybuk: what's my best way to work around this issue?
<RainCT> kirkland: ah, alright. thanks for the explanation
<kirkland> RainCT: yup, thanks for the question ... i knew someone would ask :-)
<kirkland> RainCT: the upshot is that it allows you to change your profile, keybindings, escape key, etc. on the fly
<kirkland> RainCT: without exiting and restarting screen, or typing that really long command
<kirkland> RainCT: it also reruns all of your status indicators
<kirkland> RainCT: so, you'd freshen those as well :-)
<RainCT> kirkland: ah, something more: I don't get the  \o/  in the status bar here
<kirkland> RainCT: it's 1/3 of the ubuntu logo
<RainCT> I know :)
<RainCT> but I don't have it.. dunno why
<kirkland> RainCT: debian's is easy, a red @ on a white background
<kirkland> RainCT: ?
<calc> pitti: emailed you a question
<kirkland> RainCT: that's *really* strange
<kirkland> RainCT: do you have any overrides in your .screenrc?
<RainCT> kirkland: err yes, sorry :P
<kirkland> RainCT: if you can pastebin your .screenrc and your .screen-profiles/profile, i'll have a look
<kirkland> RainCT: also, what version of screen-profiles are you running?
<RainCT> kirkland: nevermind, I had a "hardstatus string ..." in there, getting rid of it fixed it
<kirkland> RainCT: ah, yeah, that'll do it ;-)
<kirkland> RainCT: sweet
<RainCT> kirkland: "jaunty" would look nicer capitalized :P
 * calc wonders if bzr is going to be fixed in jaunty before release so it stops complaining about deprecated python
<kirkland> RainCT: bug against base-files: /etc/lsb-release
<kirkland> calc: i'm tired of those too :-)
<RainCT> calc: are you sure it's not a plugin?
<calc> RainCT: in bzr? if it is its a common one because i didn't do anything special
<Keybuk> kirkland: change the build-depend for the backport
<RainCT> here I had some plugins causing this.. but OTOH I'm running bzr from the PPA :P
<calc> i have bzr, bzrtools installed only bzr related stuff afaik
<calc> my bzr is 1.12-1build1
<directhex> i've worked out why the "skip this track" case for notifications hasn't carried any weight!
<kirkland> Keybuk: okay, that's all there is too it...  it only breaks a modern udev
<RainCT> calc: I have the same, no warnings there
<kirkland> Keybuk: cool, it's building in my ppa already, i was just checking on any other side effects ;-)
<RainCT> calc: look into ~/.bazaar/plugins, perhaps you've got something there
<directhex> media buttons on keyboards! http://www.pragmatik.org/blog/wp-content/uploads/import/keyboard0105.jpg
<Adri2000> calc: about md5/sha and hashlib?
<calc> Adri2000: yes
<calc> RainCT: no ~/.bazaar/plugins on my system afaict
<Adri2000> it's bzr-builddeb
<Adri2000> and the fix is already committed
<RainCT> directhex: err. that's pretty standards (well, not with buttons as weird as those :P)
<calc> Adri2000: afaict i don't have that binary
<directhex> RainCT, my last keyboard didn't have 'em :(
<directhex> RainCT, hence relying on banshee's notification's "skip this track" button
<RainCT> directhex: System -> Preferences -> Keyboard bindings
<Adri2000> /usr/lib/python2.6/dist-packages/bzrlib/plugins/builddeb/import_dsc.py:33: DeprecationWarning: the md5 module is deprecated; use hashlib instead
<Adri2000> /usr/lib/python2.6/dist-packages/bzrlib/plugins/builddeb/repack_tarball.py:26: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
<Adri2000> calc: that?
<calc> Adri2000: let me see, i'll run it again
<RainCT> directhex: and set Ctrl+<RightArrow> or something to move forward, etc.  How could you live without that? o.O
<calc> it just shows this:
<calc> usr/lib/python2.6/dist-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead from sha import *
<calc> /usr/lib/python2.6/dist-packages/Crypto/Hash/MD5.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead from md5 import *
<calc> is that python2.6 complaining about itself from inside bzr
<calc> ?
<calc> dpkg can't find the owner of that file
<directhex> RainCT, how? by clicking the notification, duh!
<RainCT> directhex: not on Jaunty ;)
<Adri2000> calc: looks like bug #337073
<ubottu> Launchpad bug 337073 in python-crypto "python-crypto uses sha module that's deprecated in python2.6" [Medium,Confirmed] https://launchpad.net/bugs/337073
<calc> Adri2000: ok
<Adri2000> DistroRelease: /usr/bin/lsb_release:81: DeprecationWarning: the sets module is deprecated import sets Ubuntu 9.04
<Adri2000> ahah
<Keybuk> can someone lend me a hand with python-support?
<Keybuk> I just can't seem to get this module to show up
<fta> who is managing packages.u.c? would be nice to have -security there..
<jcastro> fta: I tried to mail the guy to get patches.u.c linked from there, but no answer. :-/
<fta> jcastro, hm, he seems active, last commit in his git branch was 4 days ago
<jcastro> fta: maybe he just hates me, if you get ahold of him let me know pls.
<Daviey> i had a response from the chap around 18 months ago.. was pretty quick iirc
<Daviey> jcastro: ^^
<bdmurray> TheMuso: is bug 287862 fixed now?
<ubottu> Launchpad bug 287862 in ubuntustudio-meta "UbuntuStudio sounds do not play unless ubuntu sound theme is installed." [Critical,Triaged] https://launchpad.net/bugs/287862
<TheMuso> slangasek: If you haven't let linux-rt through binary new yet, don't, since I need to upload anothre revision thats based against latest jaunty mainline, which has an ABI bump.
<calc> TheMuso: do you have a powerpc running jaunty?
<TheMuso> calc: Indeed.
<calc> TheMuso: can you comment on bug 250825 when you have spare time, not high priority :)
<ubottu> Launchpad bug 250825 in openoffice.org "OpenOffice.org - Java on PowerPC is broken" [Undecided,Incomplete] https://launchpad.net/bugs/250825
<calc> TheMuso: i think it may be fixed now as it builds with java support afaict
<TheMuso> calc: ok will have a look at some point
<calc> TheMuso: thanks :)
<bdmurray> TheMuso: is bug 287862 fixed now?
<ubottu> Launchpad bug 287862 in ubuntustudio-meta "UbuntuStudio sounds do not play unless ubuntu sound theme is installed." [Critical,Triaged] https://launchpad.net/bugs/287862
<TheMuso> bdmurray: I'll have to check, and I need to set up a studio install in a VM for that.
<bdmurray> TheMuso: okay, it looks like ubuntustudio-desktop depended on ubuntu-sounds now
<bdmurray> I wasn't sure if that was the issue or not
<slangasek> TheMuso: alrighty :)
<TheMuso> hrm I thought we got rid of that. I'll fix that up in my seed shuffle this morning.
<Ampelbein> I just reported bug #340151 to get version 2.5.5 in jaunty. Can someone experienced look and see if the report is complete and i can subscribe ubuntu-release now? Thanks.
<ubottu> Launchpad bug 340151 in pidgin "[Freeze exception] Update to Version 2.5.5 to enable ICQ again" [High,New] https://launchpad.net/bugs/340151
<directhex> ta slangasek
<slangasek> directhex: you're welcome for whatever it was :)
<directhex> [Updating] cecil-flowanalysis (0.1~svn.68457-5 [Ubuntu] < 0.1~svn.68457-7 [Debian])
<slangasek> right
<directhex> five smerge bugs are all that remains of the transition. i'm pretty pleased that we got the thing done for jaunty
<cjwatson> Keybuk: is there a way to change the udevd log level at run-time?
<Keybuk> udevadm control --log_priority=info
<cjwatson> I'd like to be able to get a debug log just across partitioning commit, rather than for EVERYTHING
<cjwatson> aha
<cjwatson> thanks
<Keybuk> I tend to just kill udevd and start it again, mind you
<Keybuk> since then I can redirect it useful places
<cjwatson> Keybuk: that doesn't cause it to coldplug?
<Keybuk> no
<Keybuk> only udevadm trigger does that
<cjwatson> Keybuk: I can't reproduce this apparent race between libparted telling the kernel to reread the partition table and udev myself; but would a udev debug log across the relevant time be useful to you anyway?
<cjwatson> Keybuk: when removing an ordinary block device, does udev open the device being removed *at all*?
<cjwatson> Keybuk: http://people.ubuntu.com/~cjwatson/tmp/udev.log - I inserted three blank lines before the point where I told it to commit partitioning changes
<cjwatson> that said I'm slightly curious what the crap just before that is
<cjwatson> I killed udevd and restarted it at (I think) the first guided partitioning prompt, and I believe the stuff from line 369 onwards was from the next couple of guided partitioning steps (which shouldn't actually have done much to the disk, unless I'm much mistaken)
<cjwatson> Keybuk: hmm. libparted opens devices read-write if it can - could this be causing a problem?
<cjwatson> Keybuk: although I don't *think* it opens anything read-write between removing and adding partitions, so I think this can only be responsible for some noise at most
<cjwatson> maybe we should settle before committing, just to make sure everything is out of the way
<bertolo>  i am portuguese, 20 years old, student and low level coder (mainly C). how can i contribute ?
<directhex> first, try #ubuntu-motu
<bertolo> sure :D
<TheMuso> hrm looks like module-init-tools install is broken. Just got an FTBF sfor a build due to it not being able to be installed successfully.
<TheMuso> hrm its because it can't find update-initramfs.
 * TheMuso digs further.
<tormod> can somebody please build a new ports/daily-live? Since all non-xrandr 1.2 drivers were broken in Jaunty until xorg-server 1.6 was included, it would be nice to have a new live CD for testing.
<TheMuso> Keybuk: seems like module-init-tools should depend on initramfs-tools, since update-initramfs is called in its postinst.
<tormod> slangasek: I was suggested to ask you nicely about the above ports/daily-live rebuild. Please :)
<slangasek> tormod: mm, let me have a look
<TheMuso> I would actuall think it would make more sense to wait till we have the latest ports kernel ready to be put onto the disks myself.
<slangasek> right, there's that
<tormod> ETA?
<slangasek> 1.5h
<tormod> oh that was fast! Thanks!
 * TheMuso preps and uploads linux-ports-meta in preparation.
<slangasek> TheMuso: linux-ports is just accepted, so yeah :)
<TheMuso> slangasek: on its way up now
<slangasek> well, livefs builds are going to fail anyway because compiz is uninstallable
<TheMuso> hah
<directhex> not guilty!
<TheMuso> c
<slangasek> Amaranth___: do you happen to know why compiz now depends on non-existent compiz-plugins-*, instead of compiz-fusion-plugins-*?
#ubuntu-devel 2009-03-10
<mathiaz> slangasek: do you have an idea what went wrong in bug 328525?
<ubottu> Launchpad bug 328525 in openldap "package libldap-2.4-2 2.4.11-0ubuntu6.1 failed to install/upgrade: package libldap-2.4-2 is already installed and configured" [Undecided,New] https://launchpad.net/bugs/328525
<TheMuso> calc: what functionality in OpenOffice needs java, so I have something I can test?
<calc> TheMuso: help - search for item
<calc> er 'Find'
<calc> it doesn't install it by default but i believe if you have either 'openoffice.org' installed or at minimum openoffice.org-java-common it should work
<TheMuso> calc: ok
<TheMuso> calc: there is no search option in the help menu, do I have to go into OpenOffice help?
<TheMuso> I am in writer
<TheMuso> calc: nvm found it
<TheMuso> calc: ok once I made sure I had openoffice.org-java-common installed, the find function in the help worked without issue. WIll add my comment to the bug.
<calc> TheMuso: cool thanks :)
<calc> TheMuso: that uses java so it seems it does work now :)
<TheMuso> Great!
<calc> TheMuso: so i can close the bug after you follow up to it, and if anyone else has troubles they can always reopen it :)
<TheMuso> calc: I've followed up to it.
<calc> TheMuso: ok thanks
<calc> yea in the past ppc wouldn't even compile with java enabled at all so i think it should be fine now that you have verified it
<TheMuso> Sweeet!
<stgraber> TheMuso: is there a known bug in Jaunty's pulseaudio that'd make it using way more CPU than it should (10-15% with a single sound input) and making the sound to cut sometimes (especially during movies) ?
<stgraber> TheMuso: I see a few bugs that could cause that on LP but couldn't find THE bug
<TheMuso> stgraber: what ver are you using currently? A new version was uploaded several hours ago, please make sure you have that before filing bugs etc.
<TheMuso> ubuntu11
<stgraber> still running 10, will update and retry.
<TheMuso> ok thanks
<TheMuso> a lot of work went into 11, as you might see from the changelog.
<stgraber> yeah, just saw the changelog on LP :) lot of changes.
<TheMuso> Yep.
<TheMuso> Thanks to Daniel for all that hard work to get Pulse running stable. :)
<stgraber> good to know siretart is back at work :)
<stgraber> TheMuso: no glitch so far, seems to have fixed it. thanks
<TheMuso> stgraber: thanks dtchen. :)
<TheMuso> s/thanks/thank/
<johanbr> stgraber: did the cpu usage go down at all?
<stgraber> johanbr: nope but sound is perfect now
<johanbr> alright. always something. :)
<stgraber> still some 10% of CPU usage from pulse .. though that's on an Atom cpu so ...
<dtchen> johanbr: "high cpu usage" was due to two major culprits: spinning on snd_pcm_avail_update() and cpu-intensive resampler. both have been addressed for the most common hardware.
<johanbr> dtchen: That's good to hear. I should give pulse a try again. Thanks.
<stgraber> dtchen: thx for fixing pulse
<ScottK> I have a novice archive-admin question for one of you who's more experienced if someone is around?
<StevenK> ScottK: Shoot
<ScottK> StevenK: I'm looking at a package that is one BSD file, one file that's explicitly GPL v2 and later, and the rest say GPL v2.  Debian/copyright lumps the V2 files and the V2 and later file together and describes them as V2 and later.
<StevenK> Ahh, that's licensing
<ScottK> Is incorrectly describing files as V2 and later that are just V2 a reject or an accept and file a bug?
<StevenK> ScottK: It doesn't mention the BSD file, and isn't clear, since V2 is different from V2 and later
<ScottK> It does mention the BSD file.  That part is fine.
<ScottK> The problem as I see it is listing V2 files as V2 and later.
<ScottK> No advertising clause on the BSD file, so that's OK to mix with GPL.
<ScottK> It's mythnettv if you'd rather just look.
<StevenK> ScottK: Right, but the BSD file isn't shown in the copyright file?
<ScottK> It is.
<ScottK> It's fine.
<StevenK> Ah
<ScottK> It's not separating the GPL v2 only and the GPL v2 and later.  Sorry I'm not being clear.
<StevenK> ScottK: Not sure, to be honest
<cjwatson> I would be inclined to reject it for that; it should be simple to fix
<ScottK> It's got some interesting packaging issues like build-dep on python-central and build-dep-indep on python-support.
<StevenK> ScottK: Eeek
<ScottK> cjwatson: Thanks.  I'll do that along with some commentary on the packaging.
<JanC> ScottK: that sounds just plain wrong ?
<ScottK> It is.
<ScottK> And it's a cdbs rules file, so I have no idea what would actually happen if one built it.
<ScottK> The guy that uploaded it is new, so ....
<slangasek> mathiaz: smells to me like a dpkg/trigger bug
<slangasek> mathiaz: in fact, the 'Processing triggers' line 7 lines earlier is fairly conclusive IMHO :)
<calc> i tried adding a local repo to sources.list but apt just claims 'Ign file: ./ Packages'
<calc> in intrepid
<calc> the same setup works in jaunty
<calc> the sources.list contains deb file:/root/debs ./
<cjwatson> check which files it's actually accessing
<calc> and in /root/debs/ i ran apt-ftparchive packages . > Packages
<cjwatson> you need to give it a Packages.gz, IIRC
<calc> does the same thing for Packages.gz
<cjwatson> or maybe even Packages.bz2
<cjwatson> cf. Debian #440973
<ubottu> Debian bug 440973 in dpkg-dev "dpkg-scanpackages.1.gz: bzip2 vs. gzip" [Minor,Closed] http://bugs.debian.org/440973
<cjwatson> anyway, my advice stands, strace it or something to see what it's actually trying to fetch
<StevenK> --print-uris works, too
<calc> cjwatson: hmm that seems to work with bzip2, but doesn't seem to be needed on jaunty for some reason
<calc> hmm actually that didn't seem to work but it made the Hit/Ign line go away, i'll strace and see what is going on
<cjwatson> apt (0.7.17~exp2) experimental; urgency=low
<cjwatson>   [ Eugene V. Lyubimkin ]
<cjwatson>   * apt-pkg/acquire-item.cc:
<cjwatson>     - Added fallback to uncompressed 'Packages' if neither 'bz2' nor 'gz'
<cjwatson>       available. (Closes: #409284)
<cjwatson>        apt | 0.7.14ubuntu6 |      intrepid | source, amd64, i386
<calc> ok so it did download it, hmm
<calc> but it still doesn't show up in apt-cache policy
<calc> i see it in /var/lib/apt/lists/_root_debs_._Packages
 * calc kicks himself
<calc> i am trying to install amd64 debs on... i386, argh!!!
<calc> no wonder it didn't work
<calc> cjwatson: sorry for bugging you earlier :\
<Hobbsee> way cool.  kernel panic on hibernation now.  I'm sure this was working a week ago!
<TheMuso> Hobbsee: what wireless driver are you using?
<Hobbsee> TheMuso: iwl3945
<lifeless> Hobbsee: we're moving the panics closer to the start of the uptime
<Hobbsee> lifeless: ahhh.  is that the problem... right ;)
<lifeless> TheMuso: abentley was reporting hangs on iwl3945, on intrepid, but didn't that get a kernel update recent?
<Hobbsee> not sure if it got a kernel headers update, though?
<TheMuso> lifeless: don't know.
<Hobbsee> oh, hmm.  they're all together
 * calc deletes his remaining i386 vm's since he doesn't need them anymore
 * Amaranth reports an i386 OOo bug for calc 
<wgrant> .win 4
<wgrant> Grmph.
<calc> Amaranth: you can keep it ;-)
<calc> Amaranth: i wasn't able to run amd64 vm's until i upgraded my laptop this past month since the cpu didn't have the right support
<calc> Amaranth: and so whenever i build test packages i had to remember to build them for i386, but i don't need to anymore :)
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | frozen for alpha-6 | 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 | LP believed fixed - please report any further timeouts to #launchpad
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | frozen for alpha-6 | 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
<LaserJock> slangasek: it's Tuesday already? :-)
<slangasek> yep
<TheMuso> By almost 5 hours
<TheMuso> UTC time
<LaserJock> TheMuso: should be end of Tuesday UTC :-)
<TheMuso> LaserJock: What, and push the alpha out bya day? :p
<persia> LaserJock, Why?  We've been midnight-starting for a while now.
<persia> Often enough the alpha doesn't get out until well into Friday on this side of the world anyway.
<LaserJock> persia: I don't have a particular reason. I need to do a couple Edubuntu uploads to make edubuntu-desktop properly installable but I think that shouldn't be a problem.
<persia> LaserJock, The do them.  It's a "soft freeze".  You should feel guilty that they are late.
<persia> s/The/Then/
<persia> Just make sure to inform the release managers if the Edubuntu alpha CDs need rerolling once candidates are ready.
<persia> (and don't do it too often or the release managers may not reroll)
<StevenK> Or the release managers might sharpen weapons while re-rolling
<persia> That too :)
 * Hobbsee sharpens her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<Kamping_Kaiser> ah oh
<Kamping_Kaiser> :)
<TheMuso> How often does ddebs.ubuntu.com get updated with dbgsym packages?
<TheMuso> nvm my local screw up here
<slangasek> Tonio_: hrm; why does "libk3b4" contain libk3b.so.6?
<l3ftm1n0r> how do packages get included into the synaptic package manager? like how is it decided that a particular package needs to be there in the online repositories
<dholbach> good morning
<LaserJock> slangasek: I just uploaded edubuntu-artwork. Due to a miscommunication pitti removed the entire source package instead of just the edubuntu-artwork-usplash .deb so it's going to land in NEW :(
<persia> l3ftm1n0r, Essentially, a developer uploads it.  See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for more information.
<l3ftm1n0r> persia, thanks
<l3ftm1n0r> persia, the reason i asked was that some packages for ubuntu arent on the synaptic but are available on the developers site ( case in point frostwire and limewire deb packages)
<LaserJock> l3ftm1n0r: often times those sorts of packages are not in Ubuntu for license/patent reasons
<l3ftm1n0r> LaserJock, ok. but i guess frostwire is os?
<LaserJock> l3ftm1n0r: I think there were still some problems with it, I can't remember for sure though
<l3ftm1n0r> LaserJock, maybe the whole jacking off the Ui of limewire :P
<directhex> slangasek, to avoid going through binary NEW?
<KaiL> damn, we need a fresh pidgin once again :/
<KaiL> 2.5.5 works ;)
<pitti> Good morning
<pitti> calc: pong
<KaiL> also good morning from here ;)
<pitti> LaserJock: oh, sorry; I thought you entirely wanted to drop it
<LaserJock> pitti: no, we have other artwork (gdm, FF homepage, etc.) that we still keep
<LaserJock> it's all in the same source
<LaserJock> unlike ubuntu I think which has separate source packages
<LaserJock> pitti: no harm done though, we got it back :-)
<mvo> thanks slangasek
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, good morning
<doko> james_w: could you upload the patch for python-crypto? I'm still in Hamburg
<dholbach> doko: james_w is in .au :)
<doko> ahh
<doko> he was awake 1h ago :)
<james_w> doko: I would have if it wasn't in main :-)
<dholbach> doko: and james_w is not in core-dev :)
<doko> aha ...
<doko> ok, will do tomorrow
<james_w> thanks
<dholbach> totally unjustified in my opinion, but looks like James is working on it: https://wiki.ubuntu.com/JamesWestby/CoreDevApplication :-)
 * pitti puts up the "James for core-dev!" sign
<dholbach> pitti: you can speed up the process by adding your endorsement to the wiki page :)
 * dholbach hugs pitti, james_w and doko
 * pitti hugs dholback
 * james_w hugs dholbach 
<ara> doko, don't you hug anybody?
 * seb128 hugs dholbach
 * dholbach hugs seb128 back
 * dholbach hugs ara too
 * ara hugs dholbach :D
 * juanje likes hugs as well and hugs dholbach :-P
 * dholbach hugs juanje
<dholbach> juanje: (-: Â¡hola! Â¿como estas? :-)
<juanje> dholbach: fine, trying to do so many things at the same time... but I like to come to this channel because is so full of love :-D hehe
<dholbach> juanje: so how's guadalinex coming together?
<juanje> dholbach: I post it some things we've done in Guadalinex (btw, you are there :-P) and I'm working now in some i18n stuff, some documentation in Spanish for our collaborators and a bit on Ubiquity and casper
<dholbach> juanje: are you in touch with the ubuntu installer folks for ubiquity and casper?
<juanje> dholbach: I'm still have some things I don't know well how to work with in Launchpad, but I'll try step by step...
<juanje> dholbach: no much for now, just about some missing strings for translations, but I planning to do for some stuff.
<dholbach> juanje: just ask :)
<juanje> dholbach: but actually we did a kind of wrapper for the frontend so we don't need to touch so much by now the Installer
<juanje> dholbach: anyway, I was wondering if is still possible to touch things there (ie. in casper)
<dholbach> juanje: evand and cjwatson might be good people to judge if it can go into Jaunty or if it should wait
<juanje> dholbach: yeah, I guessed so, I was thinking to ask them today or tomorrow (before it be too late) about it
<juanje> dholbach: but I like to create branches with solutions (when I know about it) before put a bug a bug or bother someone
<juanje> dholbach: maybe I should ask first, i don't know....
<dholbach> juanje: best to just ask quickly :)
<juanje> dholbach:  yeah, you right ;-)
<Tonio_> slangasek: concerning k3b that's for historical reasons... previous version was libk3b3 and contained libk3b.so.5, same for the one before etc...
<directhex> yay for historical raisins
<Tonio_> slangasek: I prefered not to change the naming schema, still debian will use that one to (they started to package it) in order to remain sync
<Tonio_> slangasek: also, that upload was targetted to my ppa, shouldn't have reached the archives... we're currently testing it and I'll it reviewed before upload
<Mirv> mvo: great news, the new libcompizconfig does, like I suspected, take ca. 4-5 seconds away from GNOME login. Keybuk will be happy probably as well, if he was the one doing boot time improvements.
<Tonio_> slangasek: I've reuploaded back the kde3 version for the moment...
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<mvo> Mirv: excellent! thanks for confirming this :)
<Tonio_> directhex: to say it differently, I prefer to stay sync with debian naming convention on that package, and I don't have the all history behind it, it's just the way it is for long now...
<Tonio_> slangasek: hum, just looked again, k3b-kde3 had libk3bdevice.so.5 and libk3b.so.3 in fact...
<Tonio_> slangasek: now it's been sync to be all .so.6.... so maybe I should fix to libk3b6, you're right
<Tonio_> slangasek: but I have to see with debian since afaik, the maintainer is using 4 too...
<gaspa> dholbach, james_w: nbs and edos up again (and sorry for the long delay...)
<gaspa> dholbach: i'm updating harvest-data to point to the right urls.
 * dholbach hugs gaspa
<dholbach> awesome
<gaspa> dholbach: :)
 * dholbach hugs gaspa
<dholbach> awesome :-)
<Mirv> Keybuk: hi. the new libcompizconfig should do something visible to your grub -> desktop bootcharts :) in the case of warm login the difference is huge, since compiz was the only thing that prevented warm login (no disk access needed) from being ca. 3s
<Keybuk> Mirv: yes, I know, mvo and I have been discussing it for a while
<Mirv> Keybuk: ok.
<cjwatson> slangasek: I uploaded base-installer to fix bug 340308
<ubottu> Launchpad bug 340308 in base-installer "keyboard layout gets reset when console-setup is installed during base system installation" [Undecided,Fix released] https://launchpad.net/bugs/340308
<cjwatson> ubiquity ought to see an upload too
<pitti> doko: with pycentral, how can I tell XS-Python-Version: to only use python >= 2.5?
<pitti> doko: or do I need to use pysupport for that?
<Keybuk> pitti: 2.5-
<pitti> doko: debian/pyversions is already 2.5-, but it still tries to compile for 2.4, which fails
<pitti> Keybuk: ah, indeed; that's not documented on http://wiki.debian.org/DebianPython/NewPolicy
<pitti> Keybuk: thanks
<Keybuk> though I had endless problems with pycentral last night, and switched to pysupport
<Keybuk> I had lots of problems with that too, but at least they weren't endless ;)
<pitti> pyversions: error parsing Python-Version attribute
<pitti> it doesn't seem to like this very much
<pitti> Keybuk: I give up, and switch to pysupport, too, I think
<geser> pitti: try ">= 2.5" for XS-Python-Version (it's mentioned on the wiki page and pyversions seems to like it too)
<pitti> aah
<cjwatson> slangasek: ok, ubiquity and casper (for a slight security problem) uploaded now too
<cjwatson> Keybuk: could you look at bug 340188? it has a udev debug log now, although the problem went away upon cranking up the log level
<ubottu> Launchpad bug 340188 in debian-installer "Jaunty alternate ISO fails to partition using Guided / use entire disk" [Undecided,New] https://launchpad.net/bugs/340188
<Keybuk> cjwatson: I have too much else to do right now, sorry
<cjwatson> Keybuk: this is critical for alpha-6 - can I have some advice at least?
<Keybuk> what's the problem?
<cjwatson> Keybuk: recurrence of the partitioning races we saw in alpha-5
<cjwatson> BLKPG_DEL_PARTITION* then BLKPG_ADD_PARTITION says busy
<Keybuk> meh
<cjwatson> I've had multiple reports
<Keybuk> are there change events i nvolved?
<cjwatson> yes
<Keybuk> then vol_id or something is probably running on the partition
<Keybuk> I had a random thought
<cjwatson> I asked the reporter to add a udevadm settle before we tell parted_server to commit, and that didn't help
<Keybuk> why do we even have those rules in udev in the installer?
<cjwatson> libparted *does* open devices read-write
<Keybuk> do you use /dev/disk/by-uuid at all?
<Keybuk> or udevinfo ?
<Keybuk> why does libparted open devices at all?
<cjwatson> err, it kind of has to write to them sometimes
<cjwatson> I don't think we use /dev/disk/by-uuid/
<cjwatson> I was wondering if adding system("udevadm settle") after the BLKPG_DEL_PARTITION calls might be a good idea
<Keybuk> though I guess postinst's and stuff might
<Keybuk> settle won't help here
<Keybuk> since it won't want for the inotify event
<Keybuk> if libparted closes a device, at some point later udev will check the device for changes
<cjwatson> oof. we really need a way to make that synchronous
<cjwatson> Keybuk: I've had scattered previous reports suggesting that this may happen in ubiquity too, where it isn't so easy to just strip stuff out of the udeb
<KaiL> ...is there a bug about misspositioned window decoration known, or is my local config screwn up?
<cjwatson> basically, this sounds as though the problem is that if you open a device read-write and close it, then at some random point later udev will open it and fiddle with it, and you have absolutely no way to control when
<Keybuk> right
<Keybuk> because udev is checking to see what you changed
<cjwatson> I have a really hard time seeing how this could possibly be fixed anywhere other than udev
<Keybuk> sure, don't open block devices for writing unless you intend to write to them?
<Keybuk> I don't see why libparted is doing that if it's about to remove the partition
<cjwatson> it's doing it at some previous point for something else, I imagine, and it's just outracing udev
<cjwatson> why can't udev also check that the inotify queue is empty when you say udevadm settle?
<Keybuk> because there's no such thing
<Keybuk> where are you adding the settle call?
<cjwatson> it could at least check for pending inotify evenets!
<cjwatson> events
<Keybuk> if it's also affecting ubiquity, it would need to be in parted itself, surely?
<Keybuk> cjwatson: it doesn't work that way
<cjwatson> I added it in partman-base right before it tells parted_server to COMMIT
<cjwatson> that code is common to d-i and ubiquity
<cjwatson> Keybuk: why doesn't it work that way?
<cjwatson> when you close the fd, the kernel writes to inotify watchers, does it not?
<Keybuk> when you run udevadm settle, you don't have access to udevd's inotify file descriptor
<Keybuk> obviously
<cjwatson> Keybuk: can udevadm not communicate with udevd?
<Keybuk> that would be a hell of a lot of overhead
<cjwatson> better than the sleep 5 I'm going to have to insert otherwise
<Keybuk> since you're not even giving me a chance to think about this, go with the sleep 5 for now
<cjwatson> I've no problem at all with you thinking about this :-) It's just that you're rejecting everything I come up with out of hand and this is making me (I think understandably) rather frustrated.
<Keybuk> I told you, I'm in the middle of other things right now
<Keybuk> hassling me about a bug when I've already said I'm busy is not exactly going to elicit the most helpful responses from me
<cjwatson> well, I'm sorry that things are urgent
<Keybuk> everything's urgent
<Keybuk> we're at that point of the release cycle
<cjwatson> I've lost several days fighting with this
<Keybuk> I assume that this also affects non-LVM cases?
<cjwatson> yes
<Keybuk> what syscall actually returns an error?
<cjwatson> BTW, if the answer is "go away for several hours and I'll look later today" or something, that would be fine - you just didn't give me any idea of timescale
<cjwatson> ioctl(fd, BLKPG, {BLKPG_ADD_PARTITION, 0, datalen, data})
<Keybuk> I'm trying to understand where you're thinking of sticking the settle call
<Keybuk> I assume you're looking through the libparted code
<Keybuk> is there an obvious point to do so?
<Keybuk> ie. you can see it opening block devices, closing them again, etc.
<Keybuk> it doesn't make any sense to me that it's the BLKPG_ADD_PARTITION that fails with "in use"
<cjwatson> note that errors from BLKPG_DEL_PARTITION are not checked
<cjwatson> I expect that it's failing too
<Keybuk> I could understand if it were the BLKPG_DEL_PARTITION :)
<sladen> KaiL: file it, I had somebody show me that yesterday (and also asked them to file it)
<Keybuk> isn't that a bit error-prone?
<cjwatson> well, you'll always get an error from BLKPG_ADD_PARTITION if BLKPG_DEL_PARTITION failed, so it doesn't matter except in that you get slightly more confusing error messages
<Keybuk> where were you thinking of putting the settle?
<cjwatson> the point where I asked a user affected by this to add udevadm settle is outside libparted, but effectively immediately before the first BLKPG_DEL_PARTITION
<cjwatson> thinking about it, there's of course no point in calling settle after BLKPG_DEL_PARTITION
<Keybuk> indeed
<Keybuk> I'm assuming it's the partition deletion that's actually failing
<Keybuk> ie. you're doing
<cjwatson> yes, I think so
<Keybuk>  <change block device>
<Keybuk>  <delete partition>
<Keybuk>  <add new partition>
<Keybuk> and the delete is failing, because changing the block device causes it to be opened
<cjwatson> right
<cjwatson> so I can probably fudge things such that the change goes away
<cjwatson> but I'm concerned that there will be cases where I can't, simply because it's a race
<Keybuk> sure, so there's a few obvious solutions
<Keybuk> firstly is to try and eliminate the change
<Keybuk> the second is to fix settle so that you can call it between the change and delete and have it actually wait
<cjwatson> or perhaps something based around udevadm control (I see stuff like --stop-exec-queue?)
<Keybuk> right, that's another option
<Keybuk> also you can just do evil things
<Keybuk> before the change, do
<Keybuk>   echo -n remove > /sys/block/*/*/uevent ;)
<Keybuk> (filling in the *s)
<cjwatson> heh
<Keybuk> you'll lose the device node though
<cjwatson> I suspect the change is actually fairly unrelated (i.e. at that point I don't yet know I'm going to remove the device)
<Keybuk> right
<Keybuk> fixing settle seems the right approach
<cjwatson> but ok, that gives me enough to work with
<cjwatson> thanks a lot
<Keybuk> the problem there is that udevd receives the inotify watch
<Keybuk> but doesn't immediately process it
<Keybuk> instead it asks the kernel to send a change event for that device
<Keybuk> so there's a gap between the two
<Keybuk> I'm thinking that the right solution there is to add a second line to /dev/.udev/uevent_seqnum when inotify events are received
<Keybuk> and clear that second line when uevents are received
<Keybuk> and have udevsettle wait unconditionally if that second line exists
<Keybuk> that's still not perfect though
<Keybuk> since you don't know that there aren't pending inotify events that udevd hasn't picked up yet
<cjwatson> you'd have to make sure that udevd picks up inotify events before you do the rest of the settle
<cjwatson> that wouldn't be atomic though :-/
<Keybuk> I have a thought
<Keybuk> udevadm control obviously sends messages to udev
<cjwatson> at the moment, it looks like udevd might actually synthesise the change event after it has received a remove event for the same device, in some cases
<Keybuk> cjwatson: that shouldn't happen
<Keybuk> no idea whether there's a sanity check on it though <g>
<Keybuk> this is actually a fun problem <g>
<Keybuk> a test case should be easy to do
<Keybuk> have a udev rule that sleeps for a minute on change
<Keybuk> and try removing a partition during that minute
<cjwatson> oh, good idea
<cjwatson> ok, will do that
<Keybuk> right, need to download a couple of dailies now for these HPs
<Keybuk> I'm all yours for a bit ;)
<Keybuk> this USB key has moblin on it ... *screams a war cry and deletes it* :p
<StevenK> Hah
<KaiL> sladen, bug 340423; I hope that information helps ;)
<ubottu> Launchpad bug 340423 in metacity "missplaced window decoration" [Undecided,New] https://launchpad.net/bugs/340423
<Keybuk> cjwatson: obv. you need to "open" the block device for that minute
<cjwatson> I was just about to say the exact same thing :-)
<Keybuk> ie. RUN+="/bin/sh -c 'sleep 60 < %k'"
<cjwatson> just setting that up now
<Keybuk> sorry, you know how it is
<Keybuk> certain debugging patterns are so deep-rooted in your brain you forget that other people might now know them enough to know which one you mean
<ogra> cjwatson, do you plan a d-i upload before A6 (i see no changes in bzr)
 * ogra is wondering if the seed changes will end up in the slug firmware image without rebuild 
<cjwatson> ogra: seed changes shouldn't need a d-i upload
<cjwatson> d-i uploads are just for the initrd bit
<ogra> right, but the firmware is a bit special
<Keybuk> err $root/$name not %k ;p
<ogra> i wasnt sure it pulls in flash-kernel automatically
<Keybuk> well, you certainly can't delete a partition if anything has it open
<ogra> but i trust you if you say it is so :)
<Keybuk> BLKPG ioctl returns -EBUSY
<cjwatson> ogra: it should just require it to be priority standard; let me check
<ogra> prio should be fine, i just wasnt sure the info ends up in the initrd without rebiuld, since its so oddly merged into a firmware image
<cjwatson> yes, it's priority standrd
<cjwatson> a
<cjwatson> ogra: well, the point is that this isn't information that goes in the initrd at all
<cjwatson> ogra: remind me which d-i image this is?
<cjwatson> ixp4xx/netboot?
<ogra> yep
<ogra> di-nslu2.bin
<cjwatson> ogra: the way the initrd image is packed is essentially not relevant here
<ogra> ok
<cjwatson> ogra: what happens is that the initrd contains code to bring up the network and retrieve package lists from it (net-retriever)
<ogra> just wanted to be sure it pulls the info late enough and doesnt need it inside
<ogra> right
<cjwatson> ogra: and anna then figures out from the information delivered by net-retriever which packages it needs to install
<cjwatson> ogra: so as long as it can bring up the network, it'll be fine
<cjwatson> it'll syslog what it installs, though, so you can check without having to wait for the end of the install
<cjwatson> or you can look in /var/lib/dpkg/status in the running installer after it installs additional components
<ogra> right, but it takes over 8h to do one install so i want to exclude all surprises as early as possible :)
<ogra> its about 3h to get to net-retriever
<cjwatson> fair enough :-)
<cjwatson> Keybuk: what I'm seeing here is that settle waits for the change events; presumably it was lucky enough to happen to run after udevd processed the inotifies
<cjwatson> so the race is actually between inotify and udevadm settle
<Keybuk> cjwatson: right
<Keybuk> well
<Keybuk> the race is between the close() and the settle
<Keybuk> if you do them quick enough, udev may not have received the inotify event or sent the change event
<cjwatson> yeah, I think I might nobble udevd to be slower about processing the inotify or something
<cjwatson> for the purposes of reproducing this
 * cjwatson hacks up 'udevadm control --slow-inotify'
<sivang> hi all
 * lamont looks around for a blkid-clueful person
<lamont> sivang: howdy
<sivang> how is everybody?
<Keybuk> lamont: blkid or volid?
<sivang> lamont: hey there, how are you ?
 * sivang dicts the words in urban-dict
<Keybuk> lamont: or blkid"-ng"
<lamont> Keybuk: specifically, why fsck -A decides to try to fsck /dev/sda2 instead of /dev/md1, which appears to be the direct result of blkid_get_devname()
<lamont> hardy
<Keybuk> lamont: bad information in /etc/blkid.tab usually
<Keybuk> though why is your fsck calling blkid_get_devname() ?  we patch that in Ubuntu to use vol_id instead
<lamont> Keybuk: really?
<lamont> 1.40.8-2ubuntu2 seems to, um, not
<Keybuk> oh, e2fsprogs fsck or util-linux-ng fsck? :p
<sivang> hey Keybuk
<tkamppeter> pitti, did you write the apport hook for printing? It has a problem. See bug 340298. It says "CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log'". You, or whoever has written the apport hook seem to have forgotten that the access to this file is restricted.
<ubottu> Launchpad bug 340298 in cups "[Jaunty] Canon Pixus 550i stopped working a few days ago" [Undecided,New] https://launchpad.net/bugs/340298
<lamont> Keybuk: e2fsprogs fsck is the one that lands in sb
<lamont> sbin
<lamont> and hence the one that the system uses
<pitti> tkamppeter: yes, that can't work for reporting bugs
<Keybuk> lamont: oh, right, that one might still use blkid ;)
<Keybuk> it's all a bit of a mess really
<Keybuk> but yes, likely wrong information in /etc/blkid.tab then
<pitti> tkamppeter: but we should eventually fix the log file to be readable by adm group, then it'll work
<Keybuk> probably blkid utterly failing to realise that /dev/sda2 is part of a RAID-1 and it should use /dev/md1 instead
<cjwatson> tkamppeter: is bug 83957 something you can look at? I'm not sure who deals with scanners ...
<ubottu> Launchpad bug 83957 in sane-backends "Cracking noise on Canon lide30, possibility for hardware failure" [High,Triaged] https://launchpad.net/bugs/83957
<Keybuk> :> /etc/blkid.tab
<lamont> yeah - especially when one has a non-root RAID1 array, and mdadm grabs it before init.d/checkfs.sh runs, and then you get a ZOMG IZ INUSE HALP
<lamont> does it auto-regen later just to hurt me?
<tkamppeter> pitt, can you do that?
<Keybuk> lamont: it writes to it every time it thinks it can
<Keybuk> this is all fixed in util-linux-ng's new blkid
<tkamppeter> cjwatson, I do not deal with scanners. Only the scannner driver of HPLIP is under the packages which I maintain. See debian/changelog of the SANE package to find the right person.
<cjwatson> yeah, sane is a bit of a village bike in Ubuntu by the looks of things
<cjwatson> pitti: ^- (83957)/
<cjwatson> ?
<Keybuk> cjwatson: so, thinking about this
<Keybuk> will a super-settle really be the right way to fix this?
<lamont> Keybuk: so which package gets the bug that the hardy system FAILS TO BOOT if there is a non-root RAID1 array with a filesystem on it?
<Keybuk> ie. make it mean "udev is not about to do anything else unless somebody else tells it to"
<Keybuk> lamont: mdadm
<Keybuk> lamont: though if it's caused by bad data in blkid.tab, it's pretty likely you caused the bug by accident somehow
<Keybuk> ie. even by just running a test suite or something
<lamont> it's possibly more than that :-)
<pitti> cjwatson: will have a look
<cjwatson> ta
<lamont> palo-installer kinda makes assumptions about where /boot lives, and um, /dev/mdN isn't one of the options.  And then you get out a hammer
<lamont> and deleting the ext* entries for /dev/sd* from blkid.tab fix0rs things.  go figure
<Keybuk> lamont: bug on palo-installer? :p
<lamont> Keybuk: yeah
<cjwatson> Keybuk: that's basically what I had expected it to do, although I now realise that my expectation was a bit simplistic based on current code
<lamont> Keybuk: $beverage+=1
<Keybuk> cjwatson: basically we need something that says "if inotify is pending, process it" and, most importantly, replies after the processing is done
<Keybuk> you can guarantee that the kernel seqnum has increased once the inotify write has been finished
<Keybuk> any control message will wake up udev's main loop
<cjwatson> I was wondering whether the performance of udevadm settle was especially important
<Keybuk> well, reasonably
<cjwatson> would it matter if it just always talked to udevd?
<Keybuk> ie. it's not a place for sleep 1s
<Keybuk> cjwatson: the problem there is complexity
<cjwatson> oh, sure, I meant within reasonable bounds
<Keybuk> ie. there really isn't a useful local 2-way message socket in UNIX :p
<cjwatson> hmm, granted
<Keybuk> I have an idea though
<bigon> any buildd admin around? could it be possible to remove python2.5-minimal from the buildd as it is not needed by any other pkgs?
<pitti> bigon: how do you mean, from the buildd?
<pitti> bigon: from the archive?
<persia> Or from the base buildd chroot?
<pitti> bigon: that needs to be done in the python2.5 source first
<bigon> yeah from the buildd chroot
<bigon> The following packages were automatically installed and are no longer required:  python2.5-minimal << http://launchpadlibrarian.net/23697414/buildlog_ubuntu-jaunty-i386.telepathy-gabble_0.7.22-1_FAILEDTOBUILD.txt.gz
<persia> That needs more than just a buildd admin.
<persia> In all honesty, it's unlikely to be dropped until the buildd chroots are recreated for karmic.
<cjwatson> buildd chroots get refreshed every now and then for performance reasons anyway
<cjwatson> infinity: ^-
<persia> Is there any schedule for that, or just on an as-one-gets-to-it basis?
<Keybuk> cjwatson: http://people.ubuntu.com/~scott/udevd-settle.patch
<Keybuk> how I've missed random X server crashes
<directhex> they're fun! i get them on my laptop if i play a game then quit it
<directhex> i think it's the x server telling nme to keep playing
<pitti> directhex: s/keep/stop/?
<directhex> pitti, nah, X only dies when i quit the game
<pitti> lol
<mvo> directhex: nvidia?
<directhex> mvo, intel
<cjwatson> Keybuk: udevd-settle> coo, thanks, will give that a try
<mvo> directhex: interessting, I see something similar with nvidia
<cjwatson> Keybuk: can I upload that if I get people to test that it works?
<Keybuk> cjwatson: I'd rather do the upload since it's a patch in git
<Keybuk> and thus needs git -> bzr -> ubuntu repo massaging
 * cjwatson nodes
<Keybuk> otherwise I'll go nuts when Kay merges it
<cjwatson> nods, even
<Keybuk> cjwatson: uploaded to my PPA if people want to test it
<cjwatson> I'll kill the local build I had in progress then
<cjwatson> ... no I won't, it's done
<mnabil> guys, how can i download (only) package and their dependency in a certain directory using apt ?
<directhex> mnabil, using apt-get install --download-only?
<directhex> and -o Dir::Cache::Archives=/tmp/foobor/
<mnabil> directhex, actually this didn't work when i had the packages already installed
<Keybuk> mnabil: did you read "man apt-get" ?
<Canaman> hello people. I'm trying to develop a gtk interface with glade. When i created a new window, add a frame then add a label, the label uses all frame area, i can't set it to be small than the frame.
<cr3> should /usr/lib/python2.6/site-packages be a symlink to /usr/lib/python2.6/dist-packages?
<slytherin> Canaman: wrong channel.
<ScottK> cr3: No.  /usr/lib/python2.6/site-packages should not exist in a Debianized package.
<ScottK> /usr/lib/python2.6/site-packages is for things not installed via the packaging system.
<cr3> ScottK: was that the same in previous releases of ubuntu?
<Kamping_Kaiser> Is there a page that documents what repositories have to be enabled for a package to build? currently linux-image-{386,generic} in -security require -updates to be enabled. This seems a bit wrong to me, hence i'm asking
<ScottK> cr3: No.  It's new with Python 2.6.
<cr3> ScottK: is there a way to keep a single package compatible across releases then?
<Kamping_Kaiser> (IIRC an ubuntu-mozilla person rebuilt firefox for us so it no longer depended on -updates in this exact situation)
<ScottK> cr3: If it has a distutils setup.py using install-layout=deb should put things in the right place for 2.5 (site-packages) and 2.6 (dist-packages).
<cr3> ScottK: so the upstream setup.py will be compatible, but the resulting package needs to be built separately for each release
<cr3> ScottK: by the way, if I have some source files which go in one package and other source files in another package, all under the same project, how can I prevent my debian/*.install files from referring explicitly to site-packages or dist-packages?
<ScottK> cr3: I'm not sure you'll have to.  i haven't tested it, but I think older releases will just ignore the unknown option.
<cr3> ScottK: aha! I know, I simply use /usr/lib/python*/*-packages/...
<ScottK> cr3: Yes.
<ScottK> You type faster than I do.
<cr3> ScottK: what I meant before that *-packages is that the resulting package I build on jaunty could only be installed on jaunty, not on previous releases. however, the same source code could be used to build packages for all releases probably because the unknown option will be ignored as you said
<ScottK> cr3: Yes.  That's generally true anyway as there will be binary version dependencies generated that would prevent something built on Jaunty installing in an earlier release.
<cr3> ScottK: that actually solves another unrelated dilemna I had yesterday, thanks man!
<ScottK> yw
<mnabil> directhex, i got this ! E: Archive directory /home/mnabil/home2/testing/partial is missing  and no package in there !
<directhex> mnabil, so create it
<mnabil> directhex, k, thanks
<cr3> ScottK: fyi, --install-layout is not being ignored gracefully: error: option --install-layout not recognized
<ScottK> cr3: OK.  Thanks for letting me know.  That's unfortunate.
<cr3> ScottK: your assumption was good though :)
<pitti> cjwatson, evand: is ubiquity meant to work for installing on an USB hard disk?
<evand> pitti: there's no reason it shouldn't work, provided ubiquity is running from the live CD
<pitti> evand: okay; I filed a bug about it, but wondered whether it's even meant to work
<pitti> evand: grub-install completely falls over :(
<cr3> ScottK: I've had to derive the distutils.install.install class in order to properly ignore the --install-layout option, this is really sad :(
<pitti> I admit I have never fully understand how to make grub-install work what I want, but I wasn't able at all to install grub on the non-primary hard disk
<evand> pitti: yikes, ok
<pitti> evand: bug 340498 FYI
<ubottu> Launchpad bug 340498 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader() [failed to install grub on USB drive]" [Undecided,New] https://launchpad.net/bugs/340498
<mathiaz> dendrobates: are you still working on bug 121337?
<ubottu> Launchpad bug 121337 in openldap "openldap should enforce ubuntu's default password policy" [Wishlist,Confirmed] https://launchpad.net/bugs/121337
<evand> indeed, already there :)
<dendrobates> mathiaz: no
<kirkland> lool: hi there, are you still seeing https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/290680 in Jaunty?
<ubottu> Ubuntu bug 290680 in kvm "Partial display corruption when booting intrepid amd64 dvd iso in kvm" [Low,In progress]
<lool> kirkland: I'm not at home (oxford sprint), so not in front of my kvms; I'll check when I'm back home
<lool> kirkland: thanks a lot for working on it
<kirkland> lool: cool, no problem, i'll leave it 'incomplete' for now
<cjwatson> Keybuk: I think you need 'if (settle_pid > 0)' in your patch, rather than just 'if (settle_pid)' (which matches -1 ...)
<Keybuk> oh yeah
<cjwatson> Keybuk: sending SIGUSR1 to init breaks rather terminally :)
<Keybuk> really?
<Keybuk> it shouldn't do anything
<cjwatson> busybox init
<Keybuk> busybox init handles USR1 ?
<cjwatson> (actually, maybe >= 0 to match handle_ctrl_msg)
<Keybuk> and since kill (-1, ...) doesn't send to init ... :p
<Keybuk> but yes, it's wrong
<cjwatson> Keybuk: yeah, it maps it to halt
<cjwatson> observed behaviour is:
<cjwatson> User defined signal 1
<cjwatson> Kernel panic - not syncing: Attempting to kill init!
<cjwatson> anyway, the fix is obvious
<Keybuk> sure
<Keybuk> but since kill (-1, ...) doesn't send to init ... :p
<pitti> Keybuk: out of curiosity, how's current jaunty booting on your mini9 right now?
<Keybuk> pitti: FAST
<Keybuk> http://people.ubuntu.com/~scott/black-jaunty-20090310-4_cropped.png
<pitti> wow
<ion_> Nice
<pitti> Keybuk: the red line is the limit, or when the desktop is "usable"?
<primes2h> apw: Keybuk: Thanks for fixing floppy bug, you made happy a lot of people. :-)
<Keybuk> pitti: when I consider it complete
<Keybuk> pitti: I don't count nm-applet, that's the only bit to the right
<Keybuk> the desktop is fully usable a few seconds before the line
<pitti> that's awesome
<apw> primes2h, i am amazed so may oeioke eve
<apw>  
<apw> even have one
<apw> primes2h, i am amazed so many people even have one (even)
<ion_> keybuk: Do you think weâll get a HDD-enabled sreadahead for jaunty, btw?
<pitti> Keybuk: ah, you are using sreadahead now; what kind of impact does it have for you?
<Keybuk> pitti: on the mini9, it's totally worth it
<Keybuk> ion_: dunno, got a patch ? :p
<primes2h> apw: I know, there are country that still have it, and a lot of old pc have it as well...
<Keybuk> cjwatson: gnargh, bzr fast-import and git reset are not friends :p
<ion_> keybuk: Heh
<apw> Keybuk, sounds like a world of pain
<primes2h> apw: I don't have it on my laptop now as well, but I have some old pc (5-7 yo) in which it's present.
<primes2h> s/now/new
<primes2h> new laptop
<Keybuk> apw: today I'm learning about git fetch
<Keybuk> the hard way
<apw> git fetch == bzr pull mostly
<Keybuk> except without the changes to your branch, or the working tree
<apw> git pull does the merge after which i guess is what you are expecting
<slangasek> LaserJock: hmm, you know the NBS list generally gets taken care of semi-automatically by the archive admins?  No opportunity for miscommunication there :)
<slangasek> mvo: sure... :)
<slangasek> Tonio_: well, libk3b4 hasn't been approved into the Debian archive yet, so I wouldn't presume that it's going to get into Debian that way just because the maintainer is packaging it that way currently ;)
<slangasek> cjwatson: ack, thanks for the fixes
<Tonio_> slangasek: sure :) just that I wanted to stay sync with the debian upstream and sync the fix...
<Tonio_> slangasek: but you're right, now that all libs have the same soname, there's no reason not to version the package according to this...
<Tonio_> slangasek: anyway, that upload should have stay in my ppa, the packaging is currently in the work, unpolished...
<slangasek> right :)
<slangasek> I've rejected the binaries now, thanks
<Tonio_> slangasek: sorry for the ppa in archives... dput can be dangerous sometimes...
<cjwatson> Keybuk: ok, this at least boots now
<Keybuk> cjwatson: "at least boots" ?:)
<cjwatson> seems to complete partitioning successfully; I'll need to get the people who reported problems to test though
<Keybuk> I uploaded a new one to the PPA that fixes the pid issue
<cjwatson> Keybuk: any tests you want me to do here that would conclusively demonstrate that it fixes the race?
<Keybuk> can't think of anything
<Keybuk> did you try with the sleep rule for change?
<pitti> seb128: hm, seems that python2.6-doc is no longer in devhelp any more :(
<pitti> OMGkittensdie need documentation
<cjwatson> Keybuk: I did, but that doesn't guarantee encountering the race; if udevd has already noticed the inotify and fired off the change event, then the old udevadm settle works fine
<Keybuk> ah
<cjwatson> it only breaks if you manage to get udevadm settle in before udevd notices the inotify
<Keybuk> just trying it a few times I guess
<Keybuk> short of adding a sleep into udevd itself
<pitti> seb128: right, it lacks /usr/share/devhelp/
<Keybuk> (which I've tested here)
<cjwatson> if you've tested explicitly adding in a sleep, then I don't think I need to do anything more rigorous
<cjwatson> beyond making sure that it's this race we're hitting and not a different one :)
<Keybuk> right
<cjwatson> I'm pushing a CD image with this up at the moment
<Keybuk> we still could be fixing the wrong thing ;)
<seb128> slangasek: would a gnome-session upload to not flood logs with debugging informations be ok to upload now?
<slangasek> seb128: yes
<seb128> slangasek: ok thanks
<Keybuk> pitti: ya know
<Keybuk> I really want to kill usplash
<Keybuk> on the mini 9, usplash is visible for 6 seconds
<Keybuk> and then a black screen with a mouse cursor, thanks to X's long startup time and compiz's even longer startup time, is visible for 12 seconds :p
<jdong> sounds about right :)
<jdong> why does compiz take several seconds to start up?
<ogra> so kill X and compiz ... it takes longer than usplash :P
<pitti> Keybuk: heh
<pitti> Keybuk: see, I can enjoy it for about 50 seconds :)
<kirkland> slangasek: server cd's are looking much smaller ;-)
<slangasek> \o/
<Nafallo> kirkland: removed screen-profiles? ;-)
 * Nafallo ducks
<jdong> haha
<jdong> Nafallo: that only takes up SCREEN space :)
<Keybuk> pitti: that's because we have the I/O problem of doom
<Keybuk> tell apw all about it ;)
<pitti> apw: I can has fast IO?
 * pitti hugs apw
 * apw sends a couple of red-cross io-parcels your way
 * pitti bounces
<Keybuk> apw: I do have a sad bug to report
<apw> heh ?
<Keybuk> apw: you know how I said that setting the kernel default scaling governor to ondemand was ok, and shouldn't affect boot performance
<apw> yep ...
 * Keybuk was wrnog
<apw> ooops.  have we changed it yet?
<kirkland> Nafallo: no way dude ;-)
<Keybuk> no, I'm going to do some digging first
<apw> ok.  that was my memory of the UDS conversation
<Keybuk> I'm sure slangasek will not be my friend anymore if I ask you to upload a new kernel before alpha 6 :p
<rtg> Keybuk: rumor has it you want to change the default CPU governor?
<Keybuk> rtg: ;)
<Keybuk> rtg: not sure of the best way to do deal with it yet
<Keybuk> the default should be "ondemand"
<Keybuk> but during boot, we want it to be "performance" after all
<rtg> Keybuk: its just a config change
<Keybuk> sure, but I'm wondering whether we shouldn't leave it at ondemand in the kernel
<Keybuk> and temporarily set it to performance during the boot
<Keybuk> before setting it back again
<Keybuk> OR
<Keybuk> whether that's just mad
<Keybuk> and we should have it as performance in the kernel
<Keybuk> and set it to ondemand at the end of the boot
<Keybuk> what do you think?
<Keybuk> one of those ideas was so bad it crashed x-chat
<jdong> Keybuk: is there a huge power difference between performance and ondemand? Strangely I have been playing with that on Intel Core 2 laptop hardware and couldn't tell a big difference between the two...
<Keybuk> jdong: booting on the mini 9 with ondemand = 35s
<Keybuk> booting with performance = 25s
<Keybuk> I consider this a big difference ;)
<jdong> I meant power consumption difference
<jdong> i.e. idle power draw with lowest clockrate vs highest
<Keybuk> I'm not mjg59 ;)
<Keybuk> he cares about power consumption
<rtg> Keybuk: set it to performance on boot, then ondemand later.
<slangasek> Keybuk: your isdnutils upload FTBFS with a libtool version error? :)
<jdong> my anecdotal experience is that as long as the CPU is idle there's not a huge difference between the two settings, assuming your combined system draws more than like 8W on idle.
<jdong> maybe it's a 200mW difference at best that I could measure with acpitool
<EagleScreen> Hi all
<slangasek> Keybuk: surely changing it twice is inferior to changing it once? :)
<Keybuk> rtg: ok, well make that kernel change at your convenience ;)
<Keybuk> slangasek: ?
<Keybuk> pitti: hal has a cpufreq addon, right?
<slangasek> Keybuk: leaving the default to ondemand and changing it back and forth from userspace, vs. having the kernel default come up with what we want it to be at boot, then changing it after
<jdong> why can't we quirk it in initramfs or something to what we want?
<pitti> Keybuk: yes
<jdong> does it really hurt pre-initrd boot time that badly?
<slangasek> Keybuk: sorry, I'm interleaving
<pitti> Keybuk: I never looked what it does, though
<Keybuk> pitti: what does that do?
<Keybuk> pitti: it appears to be enabled here
 * pitti RTFS
<Keybuk> jdong: as slangasek almost said, why work around the kernel when you can change it? :p
<EagleScreen> linux 2.6.28 in jaunty turns on Bluetooth adapter in my laptop during system boot and keep it on consuming battery power when it is not in use, in linux 2.6.27 in intrepid, Bluetooth was off until I pressed the Bluetooth key
<jdong> Keybuk: well this is such a subtle point I think it'd be gracious to help those with custom-compiled kernels
<jdong> Keybuk: I don't think an extra line in initramfs hurts anything; could be a complementary solution
<Keybuk> jdong: ?!
<Keybuk> those compiling custom kernels are free to use our config
<Keybuk> or make up their own ;)
<Keybuk> if they make up their own - we shouldn't override their selected default governor
<jdong> Keybuk: well what I'm saying is, if I were looking at that option in make config, it wouldn't occur to me that a 30% difference in bootspeed can be incurred by choosing ondemand....
<jdong> but I see what you mean too wrt. overriding the kernel
<pitti> Keybuk: hm, puzzling; the entire addon just implements d-bus requests, but nothing in hal uses them
<pitti> Keybuk: apparently it's meant for tools like GNOME's cpu freq applet to provide the implementing backend
<pitti> Keybuk: or *should* it do something?
<Keybuk> pitti: no, that's what it should do
<Keybuk> was just making sure it didn't do anything else :p
<pitti> Keybuk: well, it's a 35kB source file, but from a cursory inspection it's entirely passive
<Keybuk> *nods*
<Keybuk> I thought gnome-power-manager used to use it, but apparently not anymore
<pitti> Keybuk: I didn't check that (used by g-p-m)
<pitti> door bell, dinner
<Keybuk>         Remove all the cpufreq code, as I keep being told I'm insane by Matthew.
<pitti> lol
<Keybuk>         See http://www.advogato.org/person/mjg59/diary.html?start=123 for rationale.
<jdong> Keybuk: so reading that, again, is there any real point to using ondemand?
<jdong> honestly here it even makes Firefox scrolling within Compiz noticeably more choppy for whatever reason
<Keybuk> jdong: it allegedly saves power
<Keybuk> of course, if your processor sucks at scaling, it won't help :p
<jdong> well my poor man's testing using battery draw feedback doesn't really show much of a difference between 800 and 1600MHz on a core duo
<Keybuk> which scaling driver?
<pitti> yes; reducing 1200 MHz to 800 MHz makes a lot of difference here, battery-wise
<jdong> I believe it's acpi_cpufreq?
<Keybuk> jdong: then to bugzilla.kernel.org with you!
<jdong> whatever is loaded by default for the core duo
<slangasek> Riddell: kubuntu livefs builds failing because packagekit wants dbus to be active during its postinst
<Keybuk> jdong: that's why I'm asking you ;)
<jdong> so it's supposed to help idle power draw?
<slangasek> cjwatson, Keybuk: should I be expecting a udev upload soon wrt that bug?  or an upload of something else?
<cjwatson> slangasek: still waiting for testing; charlie-tca gave it a try but there was a false start because I forgot to tell him about the extra magic wand he needed to wave
<slangasek> ok
<Keybuk> there's a magic wand?
<Keybuk> why don't I have a magic wand?
<Keybuk> I WANT A MAGIC WAND!
<ScottK> Keybuk: The Ponies have it.
<cjwatson> Keybuk: http://paste.ubuntu.com/129436/ <- magic wand
<Keybuk> scottK: is that because Ng didn't pay for the pony again, and Woody got turned to glue?
<ScottK> That or gelatin.
 * Nafallo has the magical forest :-P
<cjwatson> Keybuk: looks like no luck :-/
<Keybuk> cjwatson: then I really don't see how it can be udev with the device open ;)
<Keybuk> you could always just stick "pkill udevd" in there and start it again afterwards
<Keybuk> just to prove me wrong
<Riddell> glatzor: know anything about the problem slangasek is talking about?
<slangasek> Riddell: lp:~vorlon/packagekit/ubuntu-packagekit, if you want to pull
<slangasek> mm, but wait a few minutes so it finishes pushing first :)
<slangasek> Riddell, glatzor: anyway, why does this service run managed by dbus instead of having its own init script?  I thought we'd cured that problem when NetworkManager added its own init script
<glatzor> Hello slangasek, Riddell
<glatzor> slangasek, does it fail because of the dbus-send call?
<slangasek> yes
<glatzor> slangasek, the problem of package managers is the package cache. so this is why the daemon is only started on request.
<slangasek> ah
<glatzor> slangasek, actually this dbus-send call is not obligatory.
<slangasek> yes, I've just sent up a patch to not fail when dbus-send fails
<glatzor> slangasek, great. thanks a lot. I just have forgotten this use case.
<glatzor> slangasek, sorry.
<glatzor> for the extra work
<slangasek> glatzor: 'sok :)  uploading now - please merge lp:~vorlon/packagekit/ubuntu-packagekit
<glatzor> slangasek, I merged it. Thanks
<gnomefreak> did Jaunty get support for fingerprint scan?
<Tm_T> gnomefreak: by default you mean?
<gnomefreak> Tm_T: or drivers
<Tm_T> hmmm, I thought there were some support already
<gnomefreak> Tm_T: im running another search but i have yet found it
<gnomefreak> Tm_T: yep libpam-thinkfinger
<Tm_T> gnomefreak: I believe there has been something like that for ages already
<Tm_T> gnomefreak: as I remember installing stuff year ago
<Tm_T> never had time to make it work too, though
<gnomefreak> Tm_T: oh ok thanks
<Tm_T> but, what do I know anyway (;
<gnomefreak> Tm_T: when i get my laptop ill let you know how it goes
<Tm_T> danke
<Tm_T> I will need that feature some day soon
<Tm_T> with encrypted disk ofcourse
 * gnomefreak still hasnt tried the encryptFS yet
<Tm_T> me neither
<Tm_T> gnomefreak: my next Ubuntu hobby project will be https://www.alwaysinnovating.com/touchbook/
<Tm_T> with possible hardware modifications
<gnomefreak> Tm_T: good luck with that. I would have looked for an easier project
<gnomefreak> ill be back sunbird hates me today
<Mirv> seems to be a great day for I18N fixes, five new items fix released on JauntyTranslationIssues
 * Tm_T goes back digging memleaks somewhere ->
<cjwatson> gnomefreak: are you sure that bug 340652 is a ubiquity bug? it's not entirely clear to me that the installer has actually started, and that this isn't in fact an X bug or desktop bug instead
<ubottu> Launchpad bug 340652 in ubuntu "Jaunty desktop liveCD freezes on Intel iMacs on boot" [Undecided,New] https://launchpad.net/bugs/340652
<cjwatson> gnomefreak: BTW, you don't generally need to leave a comment when reassigning a bug to a different package unless there's something specific you want to say about it - the activity log is enough
<KaiL> oh, bug 317781 just got a news message on heise.de ;)
<ubottu> Launchpad bug 317781 in linux "Ext4 data loss" [High,Confirmed] https://launchpad.net/bugs/317781
<mdke> Mirv: around?
<Mirv> mdke: yes
<mdke> Mirv: I noticed on the page TranslatingUbuntu/JauntyTranslationIssues you've written "about ubuntu completely untranslated" - can you explain more about that? It shouldn't be the case
<mdke> Mirv: e.g. what languages have you tested? is /usr/share/gnome/help/about-ubuntu populated, etc?
<mdke> Mirv: ah, I can reproduce it actually on my jaunty system. That's definitely a bug I wasn't aware of, we need to look into it
<Mirv> mdke: System -> About Ubuntu gives all-English..
<Mirv> mdke: dpkg -L ubuntu-docs | grep about <- basically those are not included at all, only C
<mdke> hmm.
<mdke> Mirv: ok, looking at the build log, it seems to be working properly, the problem is probably that we need to do an import from Rosetta, because the translations used in the package from Intrepid don't get over the 75% barrier for inclusion in the package. Don't know why, but let's recheck after the first export from rosetta a bit later
<Mirv> mdke: ok, sounds fine, since it's not documentation string freeze yet anyway. good that there is no deeper problem.
<calc> does anyone else see a /root/1 file keep appearing?
<calc> something is creating it on my system but i'm not sure what
<calc> its a 0 byte file
<calc> happens on multiple systems so i think it is a packaging bug somewhere
<Mirv> calc: hah, interesting, I have /root/1 as well
<calc> Mirv: ok then it definitely is a packaging bug
<calc> i even have the 1 in my OOo build chroot
<jono> is something up with X - I just did an upgrade and got some Xsession errors
<jono> looked to be a gdm issue
<LaserJock> calc: because root is #1? ;-)
<calc> LaserJock: lol
<LaserJock> and he's ticked that we use sudo
<LaserJock> so he reminds us
<calc> LaserJock: i thought it was a foo > /dev/null 2>1 but couldn't find any scripts like that
<LaserJock> calc: funny you mention it I found an empty 1 in the edubuntu-artwork source package last night
<LaserJock> I suspect something like that happened there
<calc> LaserJock: heh
<calc> LaserJock: i keep removing the 1 and it keeps coming back
<calc> heh
<LaserJock> calc: so you looked at init scripts and cron jobs?
<JanC> hm, I had a /root/1 and a ~/1 file like that
<calc> LaserJock: yea but i might have glossed over the one that had the problem
<calc> LaserJock: eyes glaze over after seeing the same line repetivitely :)
<LaserJock> yeah
<calc> a simple grep to find >1 turned up nothing though
<calc> so it must be a bit more complicated than that
<cjwatson> so I have a theory about the udev/partitioning problem
<soren> calc: Are you a vi user?
<cjwatson> libparted does partitioning commit in two phases: the first is commit to the device and the second is commit to the OS
<cjwatson> in the first phase, it opens the device and writes out the new partition table to it
<cjwatson> (and closes it again). As a device write, this causes udev to fire off some change events.
<cjwatson> In the second phase, it does BLKPG_{DEL,ADD}_PARTITIONS calls.
<soren> calc: If you are, I'm going to guess something like <ESC>wq1  happened to you..
<soren> calc: Oh, it comes back on reboot?
<cjwatson> I speculate that adding udevadm settle between those two phases will help
<cjwatson> furthermore, the second phase is bracketed with ped_device_open and ped_device_close of the disk device, which will probably cause another set of change events at the end, so I bet we need to settle before that
<calc> soren: yea i use vi but it is always coming back as a 0 byte file, so i think it isn't that, might be though
<cjwatson> Keybuk: ^- would appreciate plausibility check
<calc> soren: not sure when the last time i rebooted was
<cjwatson> Keybuk: I think your udevadm settle change is sound and we'll need that - it just seems that we need a bit more too
<gnomefreak> cjwatson: looking bug back up but as i recall he stated in #ubuntu+1 that after setup his mouse cuased freeze and keyboard wasnt detected, looking at the bug it looks like he didnt state the same. i think i still have logs
<cjwatson> gnomefreak: freezes aren't usually installer bugs ...
<cjwatson> gnomefreak: the installer's a relatively ordinary application from this point of view; if the system freezes, it's usually a lower-level problem
<gnomefreak> it was afte3r install i was figuring more of livecd over d-i
<cjwatson> gnomefreak: I'm afraid I couldn't understand that sentence
<gnomefreak> freeze yes but keybourd detection is my concern but yes freezing would be X more so than anything
<cjwatson> Could you please use some punctuation? It would really help me to understand what you're saying.
<gnomefreak> cjwatson: since he stated that after install his keyboard wasnt detected "didnt work" i think he out it
<gnomefreak> cjwatson: sorry i dont have brace on. puttin git on now
<cjwatson> gnomefreak: If it has the wrong keyboard map, that could be an installer problem. If it just doesn't respond, it's something lower-level.
<gnomefreak> cjwatson: agreed I'm going by his 2nd paragraph more so than last. The mouse most likely is an X or graphics issue. the keyboard is either d-i or Ubiquity and thinking abou tit now d-i runs in background right? so maybe it is d-i?
<gnomefreak> cjwatson: i am however concerned about the 64bit install. The new intels for macs are 32bit i thought
<cjwatson> gnomefreak: ubiquity is a frontend over d-i, but that doesn't mean that d-i runs in the background in any reasonable sense
<cjwatson> gnomefreak: the only thing that d-i does in this case is set the keyboard map; it isn't responsible for interpreting keyboard events as they come in
<gnomefreak> cjwatson: i thought d-i did the work, where as ubiquity was just for looks/ewasy install, ect.
<cjwatson> gnomefreak: if the system was 32-bit only, it would have entirely failed to boot a 64-bit system at all; it wouldn't have got halfway up and then frozen
<cjwatson> gnomefreak: it does a lot of the work, but it doesn't replace things like the kernel and X which are responsible for handling keyboard events
<cjwatson> again, d-i only sets the keyboard map (via its console-setup component)
<gnomefreak> cjwatson: right 64bit can install either, that makes sense becuase to boot livecd kernel and X have to run
<cjwatson> but if you can't select the language, that's likely to be some lower-level issue
<gnomefreak> isnt lang still first setup?
<gnomefreak> right before keyboard layout
<cjwatson> gnomefreak: yes, but I think he's talking about the language selector in gfxboot which isn't part of d-i
<gnomefreak> cjwatson: in the 3rd paragraph he isnt as clear as i thought he was
<cjwatson> gnomefreak: in any case, driving the language chooser only requires cursor keys (in d-i) or the mouse (in ubiquity); it is more or less impossible for the problem as described to be an installer bug
<cjwatson> cursor keys are invariant across keymaps
<gnomefreak> cjwatson: ok that makes sense now.
<cjwatson> https://wiki.ubuntu.com/Installer/FAQ may help to untangle the different bits and pieces involved in the installer, although it doesn't talk about this problem specifically
<gnomefreak> cjwatson: thanks ill read it. I am unable to test this on an imac since the one i have is old very old
<cjwatson> it'll probably vary between models, particularly the speculated problem with the keyboard at gfxboot
<cjwatson> we have some other reports of the latter
<cjwatson> Keybuk: further data point: libparted/arch/linux.c has an obscure _flush_cache function that claims to have something to do with cache coherency, and that opens all the child partition devices for writing in order to fsync them; this is called upon opening a device, and upon closing a device if it's dirty
<cjwatson> Keybuk: hence lots of change events ...
<Keybuk> nice
<cjwatson> (it only does this for unmounted partition devices obviously)
<cjwatson> so I think this explains why the race is so tight
<cjwatson> bracketing linux_disk_commit with settles ought to do it I think
<cjwatson> Keybuk: could you upload the udev stuff you have so far?
<Keybuk> done
<cjwatson> thanks
<LiraNuna> "not app development on Ubuntu" what is, then?
<pbn> well that's not English LiraNuna
<LiraNuna> text was taken from the topic.
<LiraNuna> I came here thinking it's a channel for developers using ubuntu. Topic said I'm wrong. What is the correct channel then?
<Amaranth> LiraNuna: it's for developing ubuntu
<Amaranth> LiraNuna: generally for app development you want to go to the place for the tool you're using
<Amaranth> #gtk+ on GIMPNet, #qt on freenode, etc
<LiraNuna> I need help with packages and cross compiling
<LiraNuna> I don't know where to turn, since it's not API specific
<Amaranth> ah, perhaps #ubuntu-motu then, that's the place for packaging help
<LiraNuna> thank you
<cjwatson> pbn: we only have a limited number of characters in the topic, and at the time that was written, the only way we could fit all the required information in was to abbreviate "application"
<pbn> cjwatson: ah ok, sorry :)
<slangasek> cjwatson, Keybuk: where do we stand?  If the udev fix isn't imminent, I should probably go ahead with a d-i build anyway to get candidate CDs up
<cjwatson> the udev fix is uploaded and mostly built
<slangasek> ok
<cjwatson> I'm working on testing a parted fix to go with it
<cjwatson> which is based on a bit of an assumption - but I don't want to go round again with time-consuming hand-built images if possible
<mdke> quick question about the SRU process. After I do step 3 (subscribe ubuntu-sru), do I wait for intervention before step 4 (uploading to intrepid-proposed), or do I just go ahead and upload then wait for approval
<ScottK> Main or Universe?
<mdke> ScottK: main, but the question applies generally
<ScottK> Main you upload.  Universe I think you wait.
<mdke> ok, thanks
<cjwatson> you know what I hate? forgetting to edit debian/patches/00list
<directhex> i hate forgetting to run update-maintainer
<cjwatson> Keybuk: random note, it would make the logs marginally easier to understand if udevd logged a debug message when it sent the SIGUSR1
<cjwatson> Keybuk: then we could see not only when the SETTLE control message arrived, but when it finished
<cjwatson> (IYSWIM)
<Amaranth> calc: why do all OOo apps run under the same process?
<calc> Amaranth: its only one app
<Amaranth> calc: looks like 5 or so to me :P
<calc> Amaranth: different views in the same program
<Amaranth> calc: if I open presentation and it's waiting for me to finish the wizard I can't open writer
<calc> Amaranth: long time ago star office looked like a whole computer enivornment (iirc)
<calc> Amaranth: yep its just one app you have to finish the other one
<calc> Amaranth: look at how it is executed, you just run ooffice -math
<calc> to get a default math view
<Amaranth> makes it impossible for gnome-do to keep them separate :/
<calc> Amaranth: well nothing that can be done except work around it somehow in gnome-do
<calc> OOo is just OOo the 'apps' are just easy ways to start a view in the particular document format
<calc> it may be less confusing to just get rid of the extra menu options and only call it OpenOffice.org but I think its done in the present way to be clearer to users what is available from the menu
<calc> er less confusing in that it would be obvious then that it is only really one program
<calc> Amaranth: there currently isn't a menu option but if you run 'ooffice' it will become more clear what I am talking about
<Amaranth> wow that's...
<Amaranth> I don't even know how to describe the fail
<Amaranth> This is not how you write software :P
<calc> Amaranth: OOo is 20+ years old, heh
<Amaranth> So is Xorg
<Amaranth> Wait, forget I said that
<Amaranth> Yeah, I understand :)
<calc> it appears it was 'integrated' in 1994
<ajmitch> no wonder people accuse OOo of being bloated & slow
<calc> ajmitch: uh because it is? :)
<calc> ajmitch: i'm pretty sure no one could argue it isn't bloated and/or slow
<Amaranth> well it wasn't until very recently that Xorg wasn't an OS so I guess we can give OOo some time to stop being one
<Amaranth> I thought one of the goals for OOo 3.0 was to split them out
<calc> it takes 638MB VIRT and 97MB RES (afaict)
<calc> just to start up with nothing loaded
<calc> Amaranth: nope
<calc> Amaranth: i don't think anyone has ever proposed that it would be too huge a goal to do
<Amaranth> So the only solution is to nuke it from orbit and start over
 * Amaranth installs koffice
<calc> what they are considering doing is splitting some of the code into separate buildable bits, but you would still need pretty much all of it to use it
<calc> Amaranth: good luck with koffice :)
<calc> isn't it in a perpetual state of not quite ready? :)
<walters> virt is pretty much irrelevant
<calc> walters: doesn't that include what is mapped from libraries?
 * calc may be confused
<calc> or does RSS include that
<maix> hi, what does "fix commited" exactly mean?
<calc> maix: depends on who used it
<maix> hehe
<Amaranth> maix: it'll be in the next upload, usually
<maix> means how long?
<calc> maix: usually it means the fix is committed somewhere and usuall for the next upload
<maix> calc: https://bugs.launchpad.net/ubuntu/hardy/+source/pidgin/+bug/340151/+viewstatus
<Amaranth> whenever they do the next upload
<walters> calc: well, shared libraries can have both shared and non-shared parts
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/340151/+text)
<Amaranth> is that for a backport?
<calc> walters: i think i may be mistaken in thinking RSS was the private memory part for the application?
<Amaranth> jdong: what does Fix Committed mean for a backport request?
<maix> Amaranth: how often do they usually?
<jpds> Amaranth: Probably package uploaded to -backports pocket for release.
<calc> grr gtk_file_chooser_set_local_only does exactly what it says
<Amaranth> maix: depends on...everything
<Amaranth> maix: somewhere between 1 minute and the heat death of the universe
<cjwatson> maix: "fix committed" has absolutely no implication of timescale
<calc> it doesn't cause the file chooser to see the gvfs fuse paths, it just hides the gvfs file shares entirely
<maix> just roughly. less than one day?
<Amaranth> maix: Probably not
<maix> hm
<cjwatson> days, weeks, maybe months
<calc> walters: any ideas on how to get a gvfs fuse path out of gtk_file_chooser ?
<cjwatson> or maybe ten seconds
<maix> hm ok *g*
<cjwatson> "fix committed" just doesn't mean anything about time
<calc> walters: i want to disable gvfs in OOo but want the gtk file chooser still and want to be able to get to the gvfs fuse files
<walters> calc: there's information scattered on the web; http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html is one
<walters> calc: i don't have any gvfs-fu, sorry =/
<calc> walters: ok
<Amaranth> calc: I think we need that patch to make it always use FUSE paths for that to work
<Amaranth> although if it can figure out the FUSE path surely there must be an API to do so...
<maix> it's just some from ubuntu-de have just written an article describing what to do and i discovered that it's already "fix released" and thought maybe we wouldn't have to publish it then
<Amaranth> maix: wait a day or two
<maix> ok then we'll publish it
<Amaranth> although I still don't know if that is for backports or updates
<maix> well, it's an essential feature, must be updates :)
<calc> Amaranth: there is a path for that?
<Amaranth> calc: fedora has a patch to always use FUSE paths, iirc
<calc> Amaranth: er patch?
<maix> ok thanks then
<calc> Amaranth: hmm i thought their patch was to never use FUSE paths?
<Amaranth> calc: nah, that wouldn't make sense
<calc> Amaranth: they added support to desktop files to do: X-GIO-NoFuse=true
<Amaranth> ah, they've changed the patch then
<Amaranth> I know when gio/gvfs was first being used someone who works on fedora had a patch to always use FUSE paths
<Amaranth> seb128 may know more about it?
<calc> seb128_: ping
<calc> seb128_: any ideas about a fedora patch to always use fuse paths that Amaranth mentioned?
<seb128_> calc: pong, dunno of hand about how to change the fileselector to run gvfs fuse paths no
<calc> seb128_: ok
<seb128_> calc: what he was speaking about is the .desktop changes
<calc> seb128_: ok
<seb128_> to give fuse uris to apps when calling those
<calc> yea
<seb128_> but that's not gtkfileselector code
<calc> seb128_: yea that is what i need to find out how to get fuse paths out of :-\
<calc> its probably not terribly common to have a file dialog but no gio/gvfs support, heh
<seb128_> well, use the local mode
<Amaranth> hrm, I guess I misunderstood what they were doing
<seb128_> you can still browse .gvfs ;-)
<Amaranth> ah, davidz was trying to get it to always pass the FUSE path but must have gotten too much pushback
<Amaranth> calc: looks like g_file_get_path ()
<Amaranth> ha, a google search for that gives a bunch of ubuntu crash reports crashing on that function
<calc> Amaranth: hmm ok
<Amaranth> calc: so OOo would still have to use gio at least for that part
<calc> Amaranth: i'll have to add some debugging into OOo see what it spits out for various functions and then patch it properly :)
<tormod> slangasek and others: thanks for the new ports build, but why is .manifest not updated?
<calc> Amaranth: that should be fine since gio is in glib now
<Amaranth> calc: why disable gio/gvfs usage in OOo anyway?
<calc> Amaranth: the actual gio/gvfs saving support seems horribly broken which is why i am disabling that part as I don't know enough about it to fix it in the short time we have left
<calc> Amaranth: i got gvfs fuse support working for OOo properly as of 1.1.8 (filed a few bugs upstream) so that much will work if i can get the fuse paths
<slangasek> tormod: that would be a livefs build failure of some kind
<slangasek> tormod: i.e., http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
 * calc bbl, dinner
<tormod> slangasek: thanks, yes compiz breakage as you predicted yesterday
<slangasek> tormod: if that's the failure, it might be fixed by now - I'll do a test spin
<tormod> slangasek: thanks
<lool> Keybuk: modprobe dropped the -Q option it seems
<lool> Hmm weird, I don't see it every working
<lool>        -Q --silent
<lool>                  As -q with the addition that all warnings and errors are also
<lool>                  silenced.
<lool> Hmpf and /sbin -> /bin/lsmod hits more than just powernowd
<cjwatson> slangasek: I just reassigned a d-i bug to compiz about that, and I guess there's probably a small stack
<slangasek> cjwatson: about compiz installability?  should already be resolved as of last night
<cjwatson> yeah, I tend to get bugs whenever dailies are uninstallable, I don't always have time to look up the status
<cjwatson> usually just punt it to the right package and let them sort it out ...
<slangasek> ack, I'll chase it up
<slangasek> thanks :)
 * TheMuso notices that jaunty-changes is lagging somewhat...
<cjwatson> the list server has been loaded of late, I believe
<TheMuso> makes sense
<cjwatson> (several people have been asking on #is)
#ubuntu-devel 2009-03-11
<_cooper_> Hi.
<_cooper_> I'm about to generate an ubuntu package and found in the PackagingGuide how to name the package.
<_cooper_> The guide says:
<_cooper_> "If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.1.1-1 package was changed by Ubuntu, the version string would be 2.1.1-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1)."
<savvas> _cooper_: I think this is more of a #ubuntu-motu question :)
<savvas> (when you ask the question, that is :P)
<_cooper_> 'kay, thanks for the pointer.
<evolio> hi there, is jaunty going to have a new theme? has that been decided?
<directhex> who's on archive admin duty?
<persia> directhex, https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
<directhex> Riddell, did you just slash the NEW queue to ribbons?
<persia> I think you hit a gap, as it's no longer Tuesday in UTC+0, but it's not yet Wednesday in UTC-6
<directhex> persia, looking for context on a contextless REJECT
<StevenK> Ah, that's the if uploader == directhex check ...
 * StevenK hides
<directhex> StevenK, damn, i thought only the debian cabal had that
<directhex> well, they say a true genius is never appreciated in his own time...
<ScottK> Unfortunately the ubuntu-archive list archive is lagging badly.
<persia> I suspect it's the abovementioned slowness of the list server.  I'm not seeing context for REJECTs that I *know* were sent (because I received other copies).
<ScottK> Yes.  I know because I don't see one I sent.
<ScottK> ... and you were sent a copy of ...
<StevenK> directhex: Exercise patience, I doubt it was contextless
<persia> And that is 9 hours old.
<ScottK> Yep.
<directhex> StevenK, james_w got the reject message, and was asking ME if i knew context, so unless there's a follow-up lagging someplace
<pochu> slangasek: what do I need to get an UI freeze exception for bug 328606? :)
<ubottu> Launchpad bug 328606 in liferea "Liferea shouldn't include actions if notification server doesn't accept them" [Low,Triaged] https://launchpad.net/bugs/328606
<Amaranth> pochu: how is that a UI freeze exception?
<Amaranth> pochu: you have to get an exception to fix "the UI accidentally broke"?
<pochu> Amaranth: don't ask me, I'm the one who thinks it's a bug fix
<pochu> but some people seem to disagree
<TheMuso> c
<ScottK> Amaranth: It's more U/I doesn't work so well because someone changed the rules without much notice.
<ScottK> Pretty well amounts to the same thing, but there's no accident involved.
<slangasek> pochu: doesn't look to me like anything that needs a UI exception.
<slangasek> pochu: who was saying otherwise?
<ScottK> slangasek: Does U/I freeze actually apply to Universe (or at least the unseeded parts of Universe)?
<ScottK> Since the docs/translations teams don't (AFAIK) support those packages, I'm not sure what point it would serve.
<slangasek> ScottK: I don't think it should apply, and wasn't considering it to apply
<ScottK> Right, I just don't think our docs actually say that.
<ScottK> (that it doesn't apply)
 * ScottK looks
<ScottK> slangasek: https://wiki.ubuntu.com/UserInterfaceFreeze includes "all user-visible strings in applications", which one might well think inludes Universe.
<slangasek> ScottK: I'm happy to have that amended, though perhaps we should check with the doc team (mdke?) first to make sure that's consistent with their expectations
<ScottK> mdke: Would adding "...  which are installed by default" to that cause any issues for you?
<ScottK> It uses that construction earlier in the page.
<TheMuso> persia: Do you happen to be around now?
<TheMuso> slangasek: Got an install problem with studio disks, testing on amd64 but will likely affect i386 since its arch independant, a weird conflict issue with ubuntustudio-sounds and gnome-audio, working out how to address this, but likely enough a seed addition to blacklist gnome-audio will be enough.
<TheMuso> persia: never mind, worked around it.
<TheMuso> slangasek: If you could respin studio when you get a chance, that would be appreciated, fixed the problem in our seeds, which doesn't require an ubuntustudio-meta upload.
<TheMuso> 666/
<LaserJock> yikes
 * LaserJock wonders what window TheMuso was heading to :-)
<slangasek> TheMuso: respinning
<TheMuso> slangasek: thanks
<TheMuso> LaserJock: lol
<Amaranth> LaserJock: The channel which must not be named, of course
<slangasek> TheMuso: and build done
<TheMuso> slangasek: thanks again.
<persia> TheMuso, just back.  You know that germinate doesn't enforce blacklisting for tasks or meta, right?  I'm not sure just blacklisting will work without either adding a Provides: to ubuntustudio-sounds, or extending the Recommends for pulseaudio-module-x11
<TheMuso> persia: well gnome-audio is no longer on the disk so...
<persia> Hrm.  Odd.  I remember a similar issue with xfce-panel and MID where it kept showing up.  Anyway, if it works, it works.
<TheMuso> yeah
<TheMuso> persia: well the seed change I made fixed the problem to the point where the disk is installing.
<persia> Excellent.  That's enough for alpha.  It's probably worth trying a Desktop -> Studio crossgrade at some point to make sure that still works.  I'll see if I can do that this evening.
<TheMuso> ok
<dholbach> good morning
<mdke> ScottK2, slangasek: that sounds like it should be ok although I think we do have some documentation for the occasional universe package which would be affected if UI strings were changed late, From a quick review it's quite rare though
<pitti> Good morning
<Amaranth> $ ls -lh /var/log/syslog
<Amaranth> -rw-r----- 1 syslog adm 329M 2009-03-11 02:50 /var/log/syslog
<Amaranth> can we make pulseaudio shutup already? :/
<pitti> Amaranth: can you please file a bug against pulseaudio for that, with some excerpts from the log?}
<pitti> and maybe discuss with TheMuso
<Amaranth> yeah, doing that now
<pitti> certainly sounds worth fixing
<Amaranth> Mar 10 10:33:32 ronin pulseaudio[3715]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 13835058055252444064 bytes (418293347931 ms) Most likely this is a Linux bug. Please report this issue to the ALSA developers.
<Amaranth> oops, didn't mean to paste that here
<pitti> well, it's fine, just one line :)
<Amaranth> it's that over and over and I though crimsun uploaded a fix for it already
<Amaranth> ah, it's actually bug 340784
<ubottu> Launchpad bug 340784 in pulseaudio "[Jaunty] Pulseaudio fills my logfiles." [Undecided,New] https://launchpad.net/bugs/340784
 * Amaranth adds a comment
<Amaranth> looks like this actually may have already been fixed, the messages stopped right around the time I remember pulseaudio dying and having to restart it
<Amaranth> TheMuso: Thank you for making pulseaudio shutup about alsa :)
<Amaranth> or whoever did it
 * Amaranth &
<tkamppeter> pitti, there is still a CUPS SRU for Intrepid which you did not put into -proposed
<seb128> slomo: are you there?
<slomo> seb128: yes
<seb128> slomo: see #ubuntu-desktop log ;-)
<pitti> tkamppeter: oh, I see; added to my TODO list, thanks for the poke
<tkamppeter> pitti, thanks, this is already waiting for 6 weeks.
<KaiL> ..am I the only one, who needs to give gconf a kick from time to time?
<Keybuk> lool: it didn't so much as drop it
<Keybuk> it was an Ubuntu patch that upstream rejected
<Keybuk> just use -q/--quiet instead, that's fixed now
<pitti> mvo: I like the current update-manager version number
<pitti> 1:0.100.1, is that really still decimal? :-)
<directhex> pitti, that version number sucks. there's only one awesome version number in ubuntu, and it's 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
<pitti> mvo: will the next version be 1:0.101.0?
<pitti> directhex: yeah, "how to encode the changelog into a version number"
<seb128> slangasek: is now still a good time to do uploads? ;-)
<directhex> AKA "epochs hurt"
<DktrKranz> I hope they don't change their mind again, it can be hard to manage 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2+reallyreally9.0.120.0ubuntu1
 * pitti eyes at stgraber .. MirrorKit..
<mvo> pitti: I like it too and your idea as well, I think I will switch to this schema
<lool> Keybuk: Problem is that it breaks packages which used that
<lool> Keybuk: Like powernowd -- which is still installed on most systems
<Keybuk> lool: powernowd isn't seeded anymore?
<Keybuk> you just need to merge the seeds
<Keybuk> I have "remove powernowd from the archive" on my todo list
<lool> Keybuk: It's not seeded but it remains installed on upgrades...
<Keybuk> lool: didn't you use update-manager? :p
<Keybuk> also the modules powernowd tries to load are all compiled into the kernel now
<lool> Keybuk: Would update-manager have removed it?
<Keybuk> lool: should have done
<lool> I used aptitude
<Keybuk> I've been grepping the archive to make sure nothing uses -Q
<Keybuk> only a few ubuntu-specific things did
<lool> Ok, and these are fixed but you missed powernowd?
<Keybuk> I deliberately ignored powernowd, since it's going away ;)
<lool> Keybuk: Did you also use the occasion to grep for /sbin/lsmod.
<Keybuk> lool: no, that one's a simple packaging error
<lool> Keybuk: powernowd and acpid -- which we want to get rid off too -- are using it
<Keybuk> it should be in /bin
<lool> Keybuk: Some programs hardcode it
<Keybuk> lool: I couldn't find any reference to modprobe in acpid?
<lool> Keybuk: /sbin/lsmod
<Keybuk> oh
<Keybuk> like I said
<Keybuk> that's just a packaging error
<Keybuk> lsmod's always been in /bin in Debian/Ubuntu
<Keybuk> I hadn't noticed it was in sbin upstream
<lool> Keybuk: The other way around I think
<soren> ?
<cjwatson> I think it was moved intentionally in Debian since /sbin isn't on the default path there
<lool> Keybuk: What I'm saying is that packages are hardcoding /sbin/lsmod and they break with the move
<soren> We want to get rid of acpi?
<soren> acpid, I mean?
<cjwatson> but in any case packages should not hardcode the paths to executables
<lool> soren: Yes, do you need it?
<soren> lool: Err.. yes?
<Keybuk> lool: yes
<Keybuk> lool: and I'm saying the move was an accident
<Keybuk> lool: and I've already got a package to fix that
<lool> Keybuk: Oh it's an accident in the last upload which you'll revert
<Keybuk>  like I said
<Keybuk>  that's just a packaging error
<Keybuk> ;)
<soren> lool: Unless you've got something else that will shut down my system when it receives and acpi shutdown event?
<lool> Keybuk: I thought it was an ancient packaging error which you corrected in the last upload
<Keybuk> oh, no ;)
<lool> soren: Well on the desktop we have hal-hooked-up stuff
<soren> lool: Good for you :)
 * mvo is deeply anoyed by pycentral telling him there is no Python-Versions field in the package when there clerly is one 
<lool> Keybuk: Ok, good too hear lsmod will move back after A6 then,
<Keybuk> lool: I decided to go with a symlink
<Keybuk> on the basis that since /sbin/lsmod is the upstream locations, other things might be hard-coding that
<lool> Keybuk: That's what I'd have suggested too
<soren> lool: Oh, so by "get rid of" you just mean "stop seeding on the desktop"?
<soren> lool: Not as in "removing from the archive", which seems to be what Keybuk meant wrt. powernowd.
<lool> soren: Actually yes, after discussing it with you I remembered it's only for desktops that it was question of droppin git
<Keybuk> lool: I have that backwards, don't I :)
<Keybuk> /sbin/lsmod is the traditional Debian/Ubuntu location
<lool> /lib/udev/rules.d/85-regulatory.rules:KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/"
<Keybuk> but /bin/lsmod is the upstream location
<lool> hmpf :-(
<soren> lool: Ok, no worries then :)
<Keybuk> lool: ?
<amitk> lool: be careful what you write -"droppin git" will cause you many enemies in the kernel team :-p
<lool> soren: I'm actually happy that we'll keep it somewhere cause I spent some time cleaning it up and was sad that this was being dropped and hence my work wouldn't be that useful  :-)
<lool> amitk: Yeah, I almost wrote a joke about git after it
<lool> bryce: So 60x11-localhost broke login for me
<lool> bryce: startx returns me to the console; if I move the file away it doesn't anymore
<soren> lool: :)
<bryce> lool: update to u15
<Keybuk> wel
<lool> bryce: Ok, sorry and thanks
<Keybuk> why don't we just run gnome-power-manager on servers?
<amitk> lool: we're not affected by git jokes, we just point to bzr vs. speed :)
<Keybuk> or a headless equivalent?
<bryce> lool: no prob, we can blame redhat (bashism vs. dashism)
<lool> Keybuk: There was no headless equivalent until recently; devicekitpower might change that though
<Keybuk> lool: DK-power only replaces the HAL bit
<Keybuk> you need a policy agent to make the decisions
<mvo> could someone with knowledge about initramfs-tools please review my patch for #338563 ?
<Keybuk> mvo: looks sensible
<mvo> thanks Keybuk
<bryce> night
<Keybuk> bryce: morning
<davmor2> Guys I just completed a 64bit Ubuntu install from netboot mini.iso and am greeted with a nice little window that says....  Kerneloops-ui  Your system had a kernel failure
<lool> Archive admins: python-protobuf disappeared from the archive: it used to be in universe and was being promoted to main, then disappeared
<lool> I don't see it in rmadison in jaunty anymore
<pochu> slangasek: I think the dx team thought they needed UI freeze exceptions, but I may be wrong
<pochu> slangasek: at least they tagged the bugs with 'uif-jaunty'
<tkamppeter> Any Python expert here? It is about bugs like bug 335543, a Python app does not find a certain Python library (saying "ImportError in <module>()") but the library is installed. Reinstalling the library helps. This does not only happen to Jockey but also to hal_lpadmin, the system-config-printer tray applet, ... What is the problem here?
<ubottu> Launchpad bug 335543 in jockey "jockey-gtk crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/335543
<DktrKranz> tkamppeter: it's probably not transitioned for Python 2.6, a rebuild could fix it.
<DktrKranz> tkamppeter: I mean x-kit
<tkamppeter> DktrKranz: In the mentioned case a reinstall of the existing library package even helps (no rebuild of the package). Can it be that the postinstall scripts of all Python libraries need to get re-run after Python 2.6 installation? This should be automated in the update process.
<seb128> mvo is looking to similar issues
<mvo> tkamppeter: it looks like bug(s) in python-central
<mvo> tkamppeter: seb128 has a similar issue with bzrtools
<DktrKranz> tkamppeter: python-central has some links, probably new python version modified them a bit, so it can't find Python module anymore until a new installation is performed.
<seb128> I got things screwed after cleaning python2.4 yesterday
<tkamppeter> mvo, DktrKranz, perhaps you should move bug 335543 to python-central then.
<ubottu> Launchpad bug 335543 in jockey "jockey-gtk crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/335543
<dholbach> ara: are the "move files around" changes in ldtp in debian already?
<pitti> slangasek: for planning, gnome-themes-ubuntu_0.1_all.deb (which we need to add) is 279 kB
<ara> dholbach: no, but I talked with the debian maintainer and he's going to accept the changes
<pitti> slangasek: that's about the size I recently removed from gnome-themes, so I don't need to have a too bad conscience
<dholbach> ara: is that going to be part of 1.5.1-1?
<dholbach> the thing is: if files move from one package to the other, we need a conflicts/replaces (<< old version) - if we want syncability it'd be nice if we'd have the same versions in the conflicts/replaces
<ScottK> dholbach: I wanted to mention that I think your idea about more, short MOTU training sessions is a good one.
<dholbach> ScottK: excellent - I was planning to wait a bit longer until everybody had read the proposal and then send a mail to all the people who said "sounds good - count me in" to get planning
<ScottK> dholbach: Please note there was a distinct lack of 'count me in'.  My Ubuntu time is getting somewhat more limited, so I really can't take on new tasks currently.
<dholbach> ScottK: that's completely fine :)
<dholbach> I was happy with the feedback I got on the blog post - sounds like this is a more sustainable model. :)
<ara> dholbach: then, you could accept michael's debdiff, that does not include that change, I will send my changes to debian instead. those are not as urgent, but the new upstream version is :)
<ara> dholbach: the only change i do not agree with michael is that he changed site-packages to dist-packages, I would put *-packages, as ldtp can work with python2.5 as well
<dholbach> ara: OK, if Kartik makes those changes in 1.5.1-1 and uses a   Conflicts/Replaces: ldtp (<< 1.5.1-1)   I guess we should be fine with our changes in 1.5.1-0ubuntu1
<dholbach> ara: I personally am fine with both, you decide
<ara> dholbach: OK, then you can go ahead, as he already accepted the changes (informally). thanks for your help :)
<dholbach> ara: hum... does he have that package available somewhere? it'd be nice if we could just sync it instead of me guessing and hoping that the changes are going to be equivalent. my concern is the versioned conflicts/replaces - if we pick different version numbers there, we'll have to maintain that diff for another few releases
<ara> dholbach: :-) then, again, just use the michael's version, really (with the python2*/*-packages changes...)
<ara> dholbach: really, the other changes are not that urgent
<ara> dholbach: we can wait for debian
<dholbach> ara: can you please talk to Kartik and make sure that he uses (<< 1.5.1-1) in the conflicts/replaces? :-)
<ara> dholbach: if they are not in jaunty... that's not a problem
<ara> dholbach: sure, will do :)
<dholbach> ara: gracias
<ara> dholbach: danke to you :D
<pitti> mvo: hm, the task <-> assignee mapping in bug 35876 looks backwards to me
<ubottu> Launchpad bug 35876 in update-manager "'Downloading package information' and 'building dependency tree' progress dialogs request focus too often" [Low,Confirmed] https://launchpad.net/bugs/35876
<dholbach> ara: de nada :)
<pitti> mvo: realistically I don't think we'll be able to generally fix this in metacity; I just corrected the upstream bug link for metacity
<pitti> mvo: for a local solution, do you think the progress window should just never receive focus? or at least focus_on_map false or so?
<dholbach> ara: done
<ara> dholbach: danke!
<doko> pitti: can we promote icedtea-6-jre-cacao to main? I'd like to have it for arm and powerpc.
<bigon> infinity: hi, do you know how often the chroots are cleaned up on buildd?
<pitti> doko: sure; done
<doko> pitti: thanks
<pitti> doko: btw, is the cacao source still relevant with this?
<pitti> doko: it's already in main
<pitti> (icedtea-6-jre-cacao I mean)
<doko> pitti: no, not exactly, because openjdk has a copy of the cacao source again (cacao is still in universe)
<pitti> doko: right, I meant if the cacao-oj6 is now redundant and should be removed
<doko> pitti: but now we can remove the cacao-oj6 package
<pitti> doko: lp-remove-package.py -u pitti -m 'cacao now built from openjdk-6 source' cacao-oj6
<pitti> doko: does that sound correct?
<pitti> doko: as a rationale?
<doko> pitti: sounds ok
 * pitti makes a flushing noise
<doko> tkamppeter: it doesn't make sense to refer to a discussion on irc without including or summarizing it ...
<tkamppeter> doko, added.
<lamont> bigon: how do you mean "cleaned up"?  the chroot is freshly unpacked from a clean tarball every build, and dist-upgraded.  the tarball is freshened "from time to time" (manually)
<cjwatson> lamont: he's asking about the latter, because python2.5-minimal is still there and can go away now
<cjwatson> a dist-upgrade won't do that
<lamont> cjwatson: right
<doko> tkamppeter: why should it be a python-central error, if the usb module cannot be imported, which is managed by python-support?
<doko> DktrKranz: ^^^
<doko> mvo: ^^^
<seb128> doko: speaking about python error apt-get autoremove cleaning python2.4 yesterday on my install and since bzrtools is broken
<seb128> doko: ie
<seb128>  LC_ALL=C ls /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr*
<seb128> ls: cannot access /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr*: No such file or directory
<doko> seb128: bug report?
<rmcbride> doko: pitti: python-protobuf seems to have disappeared from Jaunty. Could this be related to the MIR for protobuf that got promoted yesterday?
<tkamppeter> doko, see IRC discussion, bug 335543
<ubottu> Launchpad bug 335543 in python-central "jockey-gtk crashed with ImportError in <module>()" [Undecided,New] https://launchpad.net/bugs/335543
<seb128> doko: what would be useful as extra infos in a bug report?
<seb128> doko: I think mvo was investigating but I will open a bug if he doesn't
<cjwatson> I've filed an RT ticket to have the buildd chroots refreshed, at lamont's suggestion
<bigon> lamont: well there are some package left behind (like python2.5-minimal) that make some pkg FTBFS
<doko> tkamppeter: what does this have to do with 291035?
<mvo> doko: I was refering to the problems that tkamppeter described and a issues that seb128 had with bzrtools. I don't know about usb modules
<tkamppeter> bug 291035 is also an ImportError which was reported recently (not very well done by the reporter, he hijacked an old, closed bug) and is also an ImportError, looks like his problem was also triggered by Python 2.6.
<ubottu> Launchpad bug 291035 in python-central "hal_lpadmin crashed with ImportError in <module>()" [Undecided,Incomplete] https://launchpad.net/bugs/291035
<tkamppeter> It has nothing to do with hal-cups-utils (the package correctly requires python-usb) and also not with the case that python-usb is a USB library.
<cjwatson> bigon: if packages break with it, they probably ought to use Build-Conflicts?
<bigon> cjwatson: actually the pkg will ftbfs with all python*-minimal as it need the std lib
<bigon> and the minimal doesn't provide that
<cjwatson> bigon: err, surely that means that it needs to build-depend on the appropriate extra packages, not that -minimal breaks it
<cjwatson> sounds like your package is just broken
<bigon> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474053 << actually it's that problem
<ubottu> Debian bug 474053 in python2.5-minimal "python2.5-minimal: looks like Python 2.5, but isn't" [Normal,Open]
<cjwatson> bigon: but that bug does not affect build-dependencies. You should build-depend on what you need
<cjwatson> that bug is about where the executable is located (and is a bit debatable anyway; I would be inclined to say that we should not change that in Ubuntu, although it's up to doko) and that cannot possibly affect build-dependencies
<bigon> the thing it's that the configure takes the smaller version of python, py2.6 is actually pulled but like py2.5 from python minimal is already there it takes that one
<doko> bigon: renaming doesn't make much sense. both are pulled, because the -minimal packages recommend the "complete" one
<Keybuk> seb128: I think I fixed the bootchart bug
<Keybuk> at least, it's far more reliable for me now
<MacSlow> seb128, hey there
<MacSlow> seb128, today is actually allocated to squash some bugs on notify-osd :)
<MacSlow> seb128, I'll see how much I can fix
<dholbach> MacSlow: crashers first!
<dholbach> :-)
<MacSlow> dholbach, I know :)
<cjwatson> bigon: "takes the least version of python" seems like a rather odd thing to do ...
<bigon> I don't know why it's done like that..
<mvo> pitti: looking at the bug now
<bigon> doko: recommended pkg are not pulled on buildd
<doko> bigon: is python2.5-minimal still installed on the buildd?
<bigon> doko: yep
<doko> infinity: ^^^ could this be fixed/removed please?
<cjwatson> doko: I filed an RT ticket for this already
<doko> ok, thanks
<bigon> cjwatson: do you have the url of that ticket?
<cjwatson> the relevant RT system is internal so it won't help you
<cjwatson> I'll let you know when it's done
<bigon> ok thx
<ogra> Keybuk, is it normal that i dont have any hwclock initscripts at all anymore ? (i still think the babbage passwd thing is related to clock issues, especially since my hwclock is at 01-01-1970)
<cjwatson> ogra: the kernel is supposed to sync the system clock from the hardware clock itself nowadays. If this isn't working here, that could well be the sort of thing that's quite architecture-specific
<ogra> right
<cjwatson> ogra: though if the hardware clock is wrong, then the hwclock init scripts wouldn't have made any difference anyway :)
<ogra> and i see on my x86 laptop that pw expiry is set to 13979
<ogra> days
<cjwatson> is it possible that you have multiple rtc devices, only some of which actually work?
<Keybuk> ogra: my hardware clock looks generally right to me
<ogra> no, only one and that works if i call hwclock manually
<Keybuk> ogra: run /sbin/hwclock --show
<ogra> Keybuk, i ran sudo hwclock
<ogra> and now ran sudo hwclock --systohc and rebooted
<ogra> which makes everything function correctly
<ogra> i have ttys
<cjwatson> the kernel's supposed to sync it on shutdown too ...
<Keybuk> cjwatson: no it's not
<ogra> and it depends
<cjwatson> do I misremember?
<cjwatson> ok
<ogra> from where would it sync it
<Keybuk> there was an init script on shutdown to do that
<ogra> i.e. if i dont have network attached ...
<ogra> it wouldnt getr a correct time at all
<cjwatson> well, the obvious answer is "the system clock". but if I've misremembered and it doesn't, then the question is moot.
<Keybuk> hah
<ogra> in any case 13979 days from 01 01 1970 definately is expired :)
<cjwatson> presence of the network is a red herring here; that is only relevant for setting the system clock, usually rather later
<Keybuk> right
<Keybuk> system clock set from hardware clock on power on
<Keybuk> system clock set from network on ifup
<Keybuk> hardware clock set from system clock on shutdown
<Keybuk> except I note that the init script is missing here ;)
<cjwatson> but if the system clock is set from the network relative to a completely broken hardware clock, that would certainly break stuff first time round
<ogra> right, but if you need a correct time on first boot and the board only has 01 01 1970 in the hwclock
<ogra> where would a correct time come from without net
<cjwatson> so does this mean network -> system clock needs to adjust password expiry too?
 * cjwatson vomits
<Keybuk> ogra: where would a correct time come from at all?
<Keybuk> cjwatson: I don't see what this has to do with password expiry?
<cjwatson> Keybuk: ok, I think this is the sequence of events
<cjwatson> 1) system boots; hardware clock says 1970 so system clock is initialised to that
<ogra> Keybuk, if your clock is at 01 01 1970 ... the default expiry value in /etc/shadow seems to be 13979
<cjwatson> 2) casper runs in the initramfs, and among other things it runs adduser and sets some kind of default expiry time
<ogra> 13979/365=38 years
<cjwatson> 3) network comes up and ntp runs
<ogra> which means its expired :)
<Keybuk> ogra: I have 99999 in my expiry field
<ogra> wrong field ? :=
<ogra> :)
<Keybuk> no...
<Keybuk> ubuntu:...:0:0:99999:7:::
 * ogra thought it was the second field
<Keybuk> second field is days *before* password may be changed
<Keybuk> third field is days *after which* password must be changed
<ogra> days since Jan 1, 1970 that password was last changed
<Keybuk> fields after that
<Keybuk> ie. username = ubuntu, pass = ..., last changed = 0, may be changed = 0, must be changed = 99999
<cjwatson> 99999 days == ~ 27 years
<ogra> yeah
<Keybuk> cjwatson: 273 years
<ogra> oh
<Keybuk> so while we will be bitten by this bug, I'm not going to worry about it too much ;)
<cjwatson> Keybuk: one of us can't divide
<Keybuk> I'll leave a note about it in my will
<cjwatson> 99999/365
<cjwatson> 27.39452054794520547945
<Keybuk> cjwatson: math 101, if you have ~100,000 and your dividing by order of 100-1000 your answer is going to be >100 and <1000
<Keybuk> so it's you :p
<ogra> 99999/365
<ogra> 273
<ogra> Keybuk, is right
<cjwatson> oh, grr
<cjwatson> my system is under load and there was a leading 9 to bc's input as a result
<cjwatson> which showed up rather earlier so I didn't notice ...
<cjwatson> fair point on maths 101 :)
<ogra> anyway, setting the hwclock manually solves my tty prob and gives me a different /etc/shadow
<Keybuk> so I agree that this problem looks like it's caused by the system clock being 1970 when adduser is run
<ion_> In that case, the result should have been 2739. :-P
<Keybuk> but I don't see why login is behaving that way at all
<Keybuk> the password still should not be expired
<Keybuk> if it was set in 1970, and is not due to expire until 2243 ...
<ogra> well, so we might hit a bug somewhere ... all i can say that a proper clock fixes all issues
<Keybuk>         if (spent->sp_lstchg == 0) {
<Keybuk>                 D(("need a new password"));
<Keybuk>                 *daysleft = 0;
<Keybuk>                 return PAM_NEW_AUTHTOK_REQD;
<Keybuk>         }
<Keybuk> hah
<Keybuk> hah
<Keybuk> hah
<Keybuk> someone special-cased 0 to mean "must change immediately"
<ogra> OH !!! and on a sidenote a fixed clock fixes https://bugs.launchpad.net/gnome-keyring/+bug/328167
<ubottu> Ubuntu bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [Medium,Triaged]
<ogra> seb128, ^^^^
<Keybuk> ogra: does the hardware clock keep time over a power off?
<ogra> apparently, yes
<ogra> it did for me right now
<Keybuk> sure?
<Keybuk> you just rebooted
<ogra> no, it took to long and i unplugged power
<Keybuk> oh, wait, this is a live image
<ogra> right, i was lazy
<Keybuk> so the hwclock shutdown script has been removed by casper
<cjwatson> heh, so the only valid times for the clock in Ubuntu must be 86400 seconds from epoch or greater
<cjwatson> we could change the kernel to guarantee that
<Keybuk> changing the kernel to work around a PAM feature sounds like exactly the kind of thing that won't be accepted upstream :-/
<cjwatson> 'cos there are so many systems that desperately need to have their clock set to 1 Jan 1970 at boot
<Keybuk> I did think of a sensible minimum time
<Keybuk> that the kernel has
<Keybuk> its own build time/date
<ogra> well, we could set it to 1 instead of 0
<Keybuk> ogra: then you'll hit the next bit ;)
<ogra> or to some fantasy value
<cjwatson> useradd could explicitly special-case this
<Keybuk> actually, no, you won't
<ogra> right, thats what i mean
<cjwatson> if the current time appears to be 0 days, add 1
<Keybuk> yes useradd could special-case this
<ogra> we set the passwd from casper anyway
<cjwatson> will anything care if password-last-changed > current-time?
<cjwatson> ogra: indeed, but useradd is a better place for the change
<ogra> but then it will apply everywhere
<cjwatson> not saying it's the best place, but definitely better than casper :)
<cjwatson> yes, it wil
<cjwatson> l
<cjwatson> is that a problem? that sounds like a feature to me
<ogra> while we actually only need it in live sessions, no ?
<Keybuk> cjwatson: you get a warning
<Keybuk> but it returns PAM_SUCCESS
<cjwatson> ogra: where possible, a design goal for the live CD should be to differ as little as possible from the normal system. If a bug fix is needed in the live CD that doesn't break anything reasonable in the normal system, we should fix the normal system
<cjwatson> since Keybuk has checked that this doesn't break cases where the system clock remains 1 Jan 1970 after boot, I can't think of any reasonable case that this useradd change would break
<ogra> right, understood, though the user handling of the live CD is special anyway, which was the reason for me to think we should fix it there, if it improves anything for a normal system i indeed agree
<Keybuk> do we care enough about systems with an empty hardware clock, and no network, to deal with the "what is the time mr wolf?" problem
<Keybuk> ie. ask the user what time it is ;)
<ogra> ugh
<ogra> that sounds evil
<ogra> like going back to the 90s :)
 * ogra remembers a d-i question in woody ...
<ogra> imho it should just not break ...
<cjwatson> ogra: we create a special user, yes, but "I ran useradd on a normal system that has a broken clock and can't log in with that new user" sounds like a reasonable enough bug to me too
<ogra> yeah, agreed
<Keybuk> ogra: well, those people will just get systems that think they're in 1970 all the time
<Keybuk> it depends whether you think that's breaking or not ;)
<ogra> if the functionallity is given i think thats fine
<Keybuk> and I tend to agree with something cjwatson said
<ogra> if its a desktop system you will notice it immediately
 * cjwatson falls over
<Keybuk> that at least if the clock is 1970, we _know_ what's happened
<Keybuk> whereas if we set it to some random time like the kernel's own build date, we won't have a clue
<ogra> indeed
<cjwatson> and also, users know what's happened; 1970 is a fairly familiar "hardware clock forgot its time" symptom to an entire generation of techies
<ogra> what are we discussing here ? (i never disagreed to that one actually)
<ogra> i wouldnt ask the user ... and i wouldnt set it to something random ...
<cjwatson> I think Scott is posing a question and then arguing with it himself :-)
<cjwatson> i.e. thinking out loud
<ogra> heh, yeah
<ogra> we might hit filesystem issues though, not sure
<ogra> i.e. enforced fsck
 * ogra isnt sure in what other areas of the system 1970 will have any effect
<cjwatson> largely, it shouldn't matter much. Only things that compute time in days are likely to have a problem
<cjwatson> for anything that works in seconds or less (i.e. nearly everything), it's non-zero and positive, so who cares
<cjwatson> obviously if the time is inconsistent, e.g. keeps going backwards after power removal, that's a problem
<ogra> right... and fsck will actually only kick in if the clock changes to a proper date
<seb128> ogra: good to know for the gnome-keyring issue
<ogra> seb128, meh, next reboot its back ... seems i was mislead
<ogra> it probably just dies after some time, i'm monitoring ti atm
<allquixotic> Has anyone else started to get Pidgin crashes in latest Jaunty? I gdb'ed it down to libpurple/protocol/msn/notification.c:941, there's a nice pointer1->pointer2->pointer dereference and the first or second one is NULL... it's never checked before it's used :)
<allquixotic> It was fine for days, now it's crashing on startup right as MSN connects
<Riddell> siretart: libavcodec52 is ending up on the CDs
<allquixotic> I checked our diff on Pidgin and we don't patch that file so it's in upstream
<Riddell> siretart: so is libxine1-ffmpeg
<Riddell> siretart: libxine1 should depend on  "libxine1-misc-plugins | libxine1-plugins" as it does in intrepid, it's the wrong way around in jaunty
<dholbach> allquixotic: did you try asking in #ubuntu-desktop?`people might give you a good answer there
<allquixotic> dholbach: Are they interested in Jaunty development over there too? Odd to have different development channels
<allquixotic> I've never been to #ubuntu-desktop before now :)
<dholbach> allquixotic: there's a lot of individual development channels around here (server, kernel, mobile, desktop, etc.)
<Riddell> siretart: changelog tells me we had same problem in intrepid fixed in xine-lib (1.1.14-1ubuntu2)
<Riddell> siretart: so I'll make that change now
<dholbach> allquixotic: thanks for working on pidgin - I'm sure a lot of people will appreciate it
<allquixotic> dholbach: The bug seems network/thread/code-up related, and C/GLib is right down my alley :) I will have a "fix" that causes it not to crash shortly, but I'd like to at least get someone else to acknowledge the problem :-/ Might just be my weird MSN account having a notification Pidgin doesn't know about, or something
<allquixotic> Fortunately this is the kind of code that someone who isn't an everyday Pidgin hacker can get their head around
<dholbach> allquixotic: rock on! :)
<Riddell> asac: I'd like to fix bug 340210 for alpha too
<ubottu> Launchpad bug 340210 in network-manager "network-manager should recommend plasma-widget-network-manager" [Undecided,New] https://launchpad.net/bugs/340210
<Riddell> just to let you know
<asac> Riddell: for alpha?
<asac> Riddell: what is with the -kde thing. can we remove that from the archive?
<mterry> dholbach: Thanks for the endorsement!  I didn't even notice it until I was adding to the page
<seb128> allquixotic: you better open pidgin bugs upstream directly there is no ubuntu pidgin hackers
<dholbach> mterry: no worries :)
<Riddell> asac: I'm undecided on removing it, the kde 4 version may still have a few scenarios where it doesn't work.  it should move to universe anyway
<asac> Riddell: well. from what i know the knetworkmanager never became feature complete either
<asac> Riddell: and seems to be abandoned upstream
<asac> (for 0.7)
<asac> Riddell: i would think that if plasma doesnt cover someone cases they can still use -gnome thing
<ScottK> Riddell: I'd like to suggest it move to the DVD so we have an installation medium with it for the scenario where someone only has wireless and the widget doesn't work (for just one release).
<asac> ScottK: Riddell: is there a particular scenario you have in mind that is broken?
<asac> (for plasma)
<ScottK> asac: I think the chances of us getting complete test coverage to know that everything is OK are low.
<pitti> rmcbride: hm, curious; seems it simply vanished inded
<asac> ScottK: well. we know that knetworkmanager is broken ;)
<rmcbride> pitti: seb128 and cprov are looking into it
<ScottK> I don't have a specific scenario I KNOW is broken, I just think it's prudent not to totally jump ship from one to another.
<asac> i wonder if anyone will consider it a loss if we remove it and point them to the official applet if they need more features
<ScottK> asac: More broken than historically?
<asac> ScottK: definitly more broken than with 0.6; knetworkmanager development for 0.7 seems to have stopped half way (e.g. just wired and basic wireless)
<pitti> rmcbride: seems to be a well-known soyuz bug; either way, seems we need a no-change upload and NEW it again
<ScottK> Right, but I'm using the 0.7ish one on Intrepid and it generally works.
<asac> ScottK: and plasma ;)?
 * ScottK is still on Intrepid, so hasn't used it yet.
<asac> heh. ok
<ScottK> I think leaving it on the DVD for one release is low risk and gives a decent fallback should unexpected hardware/scenario specific issues with the new widget pop up.
<ScottK> If it doesn't work either, the user is no worse off than if we'd removed it.
<siretart> Riddell: oh, indeed. thanks!
<asac> ScottK: if users wouldnt report stuff against network-manager i wouldn't care. from that point i would prefer that kde folks report bugs against plasma and then go to network-manager-gnome as a fallback (instead of yet another broken thing).
<Riddell> siretart: how do I use this hg thing?
<asac> just my suggestions. in the end kubuntu team has to decide.
<ScottK> Unless we seed network-manager-gnome and all the related depends on the dvd it doesn't really address my issue.  I'm mostsly worried about having and installation media that can be used without users having to resort to hand configuring networks.
<ScottK> Just my suggestions too.  Up to Riddell.
<siretart> Riddell: pretty similar to bzr, but use 'hg clone' instead of 'bzr get' to checkout
<asac> yeah. lets wait for Riddell. i just think that if users can connect somewhere with the current incomplete knetworkmanager, but can't do that with plasma then plasma is just not ready
<Riddell> siretart: E: Couldn't find package hg
<siretart> Riddell: apt-get install mercurial
<siretart> Riddell: however for such a small and uncontroversial change, I'd suggest to just upload to ubuntu, and I'll import the upload to the branch next time I work on it
<siretart> (or ping me and I'll do it in a minute)
<Riddell> siretart: kubuntu.org/~jriddell/tmp/xine-lib_1.1.16.2-1ubuntu2.debdiff
<siretart> Riddell: typo: s/whic/which/
<siretart> Riddell: and that change still seems a bit unnecessary to me, or rather a workaround for a limitiation in the cd creation scripts
<siretart> Riddell: the other alternative is perfectly valid (as your debdiff demonstrates). Why not respect that libavcodec52 is blacklisted and search for valid package set instead?
<cjwatson> siretart: the CD creation scripts try to mirror what apt will do where possible, and with the dependencies as they are, apt will prefer libxine1-plugins if that package is available
<cjwatson> siretart: I'd support Riddell's change, it looks correct to me
<cjwatson> siretart: remember that apt is used to build the live filesystem, and there's no way to tell it to blacklist a package
<cjwatson> so you have to get the dependencies such that apt DTRT, not focus on CD creation
<siretart> cjwatson: so `apt-get install gxine libavcodec52-` wouldn't work?
<siretart> appending '-' always worked for me for blacklisting packages
<cjwatson> I'm not actually sure. But I don't want to have to go hardcoding lots of stuff like that in livecd-rootfs!
<cjwatson> the stuff in there for Xubuntu is bad enough
<cjwatson> dependencies should just behave how we want things to be set up by default
<cjwatson> livecd-rootfs> also in tasksel for netboot installs, which would be a lot harder
<siretart> well, having a variable $BLACKLISTED_PACKAGES with "libavcodec52-" can't hurt maintainability of livecd-rootfs that badly, I'd imagine...
<siretart> but I have to admit that I haven't looked at that too closely yet
<cjwatson> I'd really prefer xine-lib to just have the dependencies the right way round for the default install, please
<cjwatson> it'll be a lot more fiddly than that in tasksel, trust me
<siretart> ok
<seb128> siretart: ok, the new gstreamer0.10-ffmpeg seems to be fixing quite some of those crashers
<seb128> siretart: just letting you know, I did follow up with slomo and on bugs
<siretart> seb128: excellent.
<siretart> seb128: perhaps we should syncronise more closely on ffmpeg updates for gstreamer0.10-ffmpeg
<siretart> seb128: does gstreamer upstream intend to switch to the 0.5 release of ffmpeg?
<seb128> slomo: ^ do you know?
<siretart> if yes, we could consider updating ffmpeg to 0.5 in both the package and gst-ffmpeg
<ScottK> Now that there's an actual release, it would be a shame not to use it.
<siretart> ScottK: does that imply a (granted) freeze exception? ;)
<catnap> hello - I'm not a developer, but I think I have a good development idea in my mind
<siretart> actually I have the 0.5 release package ready in my ppa
<catnap> people often get annoyded when they're typing something on the screen and some windows suddenly pops up and interupts the typing
<ScottK> siretart: No, but if the rdepends were tested and working, I'd defiinitely lean in that direction.
<catnap> why don't we make ubuntu so, that it detects when user is typing
<seb128> it does that
<seb128> and that's working most of the time
<catnap> seb128: that's great news
<catnap> this actually occured to me when I was using windows where the problem is much worse
<catnap> I wonder why they haven't fixed it so far
<catnap> what does ubuntu do, when new windows is about to interupt user?
<slomo> siretart: yes, gst-ffmpeg already contains ffmpeg 0.5 internally
<persia> So, anyone who hasn't voted for MC already really ought to do so: polls close in 8 hours or so.  https://launchpad.net/~ubuntu-dev/+polls
<catnap> or does that depend on wether you use kde or genome?
<siretart> slomo: can you please follow up then in bug #340303 about this? to me it seems then a very good idea to have gst-ffmpeg and ffmpeg-debian in sync
<ubottu> Launchpad bug 340303 in ffmpeg "Please sync with upstream release of ffmpeg .5" [Undecided,Triaged] https://launchpad.net/bugs/340303
<siretart> slomo: ideally we could syncronise on the next ffmpeg update, what do you think?
<slomo> siretart: you mean sync the next ffmpeg upload from debian?
<siretart> slomo: that would be too much, I'd think. no I mean the next upstream update
<cjwatson> Keybuk: heh, I just noticed that swapoff writes to devices internally in the kernel, as I'm guessing does umount
<pitti> calc: I try my luck on jaxme now
<cjwatson> Keybuk: so swapoff; lvremove is racy and you need swapoff; udevadm settle; lvremove
<tomeu> hi all, I'm wondering if the https://wiki.ubuntu.com/UserInterfaceFreeze applies to all software or just to stuff that gets installed by default or the translation and documentation team work on
<tomeu> we have some bugs that would be better fixed by adding a couple of strings
<tomeu> maybe should ask this in #ubuntu-motu?
<calc> pitti: ok
<pitti> calc: I just tried a xom rebuild for fun, but it still fails (thus isn't fixed with current openjdk)
<calc> pitti: afaict there are stubs in the svn version that might help, but they didn't all work as is
<calc> pitti: yea with xom it builds fine on most developer boxes but seems to always fail on the buildd
<pitti> calc: do you happen to know about maven-ant-helper?
<calc> pitti: not much other than maven pulls in a bunch of universe depends
<pitti> calc: no, I don't mean maven2, but maven-ant-helper
<pitti> Description: helper scripts for building Maven components with ant
<persia> tomeu, That question was answered here within the last 24 hours: it only applies to that which is either installed by default or documented on help.ubuntu.com
<tomeu> persia: so it's ok if I update that page?
<calc> pitti: oh no not really, i looked at the example package they listed in it and it seems they had to write new build.xml for it, so i was worried i would end up breaking things in undetectable ways
 * persia reviews backscroll carefully
<tomeu> the point "all user-visible strings in applications and the desktop. " is a bit ambiguous, IMO
<kenvandine_wk> kees: ping
<pitti> calc: it just might be a shimmer of hope :)
<calc> pitti: if you are pretty familiar with ant and maven it probably wouldn't be too hard to convert it over i guess
<calc> the only thing i know about either is there is cdbs support for ant, heh
<pitti> unfortunately I'm neither
<pitti> calc: so, the worst case for jaxme would be that we just keep building it with gcj, right?
<calc> pitti: yes, i believe jaxme still builds fine with gcj
<pitti> calc: it does, I just built it here
<pitti> I want to compare build logs, and everything
<calc> pitti: iirc xom still builds with gcj as well, xom just seems to die due a weird out of resources error
<persia> tomeu, I've updated to reflect what I believe was the agreed change, referencing the log.
<pitti> it's a recursive stack overflow
<calc> pitti: oh hmm, i wonder why it sometimes works during build and sometimes doesn't
<calc> pitti: is it infinite recursion or just recurses too much on the buildd?
<pitti> calc: infinite, as it looks
<calc> pitti: hmm :\
<pitti> I see the same stack frame over and over
<tomeu> looks awesome, thanks!
<pitti> it doesn't look like being related to too little RAM or anything like that
<calc> pitti: fwiw i built on amd64 and the buildd that builds it is i386, not sure if that would be related
<calc> pitti: i can try rebuilding it on my machine again and see if it still builds ok here, if so there might be some 32/64 bit issue
<pitti> calc: thanks
<pitti> calc: ok, I'll continue with jaxme
<persia> calc, pitti Do be careful of maven builds.  The current archive maven expects to pull from the internet when building.
<calc> persia: ugh!
<calc> isn't that forbidden in debian policy?
<persia> No.
<pitti> persia: I don't intend to actually use maven; thanks for the warning
<persia> It's forbidden to use that on a buildd.
<pitti> calc: in practice yes, because the buildds don't allow it
<calc> ah ok, i thought it had managed to make it into policy
<persia> Same as we support end-users pulling from cheeseshop or cpan.
<persia> But we can't do that when building our packages.
<pitti> doko: why does default-jdk-builddep depend on both default-jdk (openjdk) and java-gcj-compat-dev?
<calc> persia: well essentially i am surprised it doesn't support a buildd safe way to build as it is a build tool and other things use it (or maybe... they will use it eventually) ;-)
<doko> pitti: to build the gcj natively compiled parts
<calc> so i suppose either nothing currently uses it in the archive or packages have to hack around its tendency to download things
<pitti> doko: I thought we should get rid of gcj?
<calc> pitti: you might only need default-jdk depending on what it is
<persia> calc, https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec
<calc> persia: thanks for the pointer :)
<pitti> doko: just wondering how disastrous it would be to leave jaxme build with gcj in jaunty, if all attempts to make it build with openjdk fail
<persia> calc, Be warned that the spec is mostly abandoned, in favour of http://wiki.debian.org/Java/MavenRepoSpec (I believe)
<calc> persia: ok
<stgraber> pitti: didn't we decide that anything that wants to sound new must end with "kit" ? :)
<ScottK> No doubt with the kitkit to rule them all.
<directhex> it's a rip-off of BeOS, FYI
 * calc is seeing if xom will build or explode for him again
<directhex> http://en.wikipedia.org/wiki/Be_API
<pitti> calc: wear a helmet
<dholbach> KITT would rule them all!
<calc> pitti: built fine here
<directhex> Application Kit? OpenGL Kit?
<calc> pitti: i'm going to create a i386 chroot and see if i can make it explode
<calc> pitti: when you built it what platform did you try?
<pitti> calc: just for fun, fancy throwing it into your ppa?
<pitti> calc: I just retried it on the normal buildds, thus i386
<persia> pitti, We have a few packages that still build-depend on gcj (and default-jdk *is* gcj in Debian, which encourages that for now)
<calc> pitti: i think it probably is an i386 issue, so will try building on i386 now
<calc> pitti: all my systems are installed 64bit so i usually do all my builds that way which would explain the issue if it does just die on i386
<pitti> calc: at least it would give some reproducibility
<calc> pitti: yea, will see now
<doko> pitti: sure, that's an option. does ecj handle it? gcj still provides the fastest alternative for some archs. what I really do want to have is a conditional dependency: if gcj is installed/used, install the corresponding "-gcj" package.
<pitti> doko: didn't try with ecj, just with java-gcj-compat-dev
<pitti> and of course with default-jdk
<Keybuk> cjwatson: why is it racy with the lvremove?
<Keybuk> or do you mean swap-on-lv?
<doko> pitti: this is ecj then
<calc> YIPEE!
<calc> my OOo file chooser patch works!
<pitti> calc: for unbreaking gvfs, and using fuse?
<calc> pitti: for forcing OOo to use the fuse path, yea
<pitti> yay
<calc> it shows up like this more or less (in debugging)
<calc> SalGtkFilePicker::getSelectedFiles() - pURI1 = 'sftp://ccheney@127.0.0.1/home/ccheney' - pPATH = '/home/ccheney/.gvfs/sftp for ccheney on 127.0.0.1/home/ccheney' - pURI2 = 'file:///home/ccheney/.gvfs/sftp%20for%20ccheney%20on%20127.0.0.1/home/ccheney'
<calc> i take the file_path then stuff it back into a uri and send it along
<pitti> calc: I hope you don't have to cobble together the .gvfs path yourself :)
<calc> pitti: no, i just have to use the file_get_chooser for GFile instead of uri then pull the path out of it, then convert that to a uri then pass it back to OOo
<TheMuso> Amaranth: thank Daniel, he sorted that out. :)
<calc> too bad there is no obvious way to tell the chooser to just return a gvfs fuse uri to begin with
<pitti> calc: ah, I isolated the "build with java 6" patch from the svn; I'll see how that backports
<calc> pitti: cool :)
<pitti> it's just a 39 KB diff commit, so how bad can it be
 * pitti sobs
<calc> heh
<calc> so now OOo can't save to ftp but i can probably track down the bug in gvfs for that
<calc> i didn't try ftp before since sftp/smb already worked
<pitti> calc: just ftp, or sftp also?
<pitti> ah, nice
<calc> plain ftp
<pitti> *shrug*
<calc> sftp works, smb works, ftp doesn't
<ScottK> It'd be nice if sftp worked on non-gvfs systems.
<calc> but OOo is using straight fuse now so fuse just doesn't support something it needs
<pitti> calc: I'd call that a feature :)
<calc> pitti: heh yea
<calc> pitti: tbh i don't know if ftp support ever worked with OOo even in the past when gvfs had otherwise worked for it
<Amaranth> pitti: that's nothing, the diff from ffmpeg a month ago and ffmpeg 0.5 is 1.2MB
<calc> but it should be relatively trivial to find out why it is failing
<calc> pitti: testing the xom on i386 now
<alex-weej> any dev know what's happened to Qt in Jaunty to make it not respect fontconfig for hinting?
<cjwatson> Keybuk: swapoff/umount triggers change event, lvremove fails because device is busy
<cjwatson> I think
<cjwatson> and yes, I mean swap on lv
<cjwatson> or whatever's-being-umounted on lv
<Keybuk> right
<ScottK> alex-weej: The move to Qt 4.5 is recent.  You might ask in #kubuntu-devel.
<Keybuk> any fput in the kernel will trigger the inotify ;)
<alex-weej> scottK: done.ta.
<ogra> Keybuk, so looking at the babbage serial ttys i think they should have the same rules as ttyUSBX, do you want a bug for that ?
<Keybuk> that means they'd be in "dialout" ?
<ogra> right
<Keybuk> can you hijack jerone's existing bug and be more useful on it
<ogra> if thats correct for ttyUSB i do think thats fine for any other serial ports as well
<ogra> Keybuk, do you have a number ?
<Keybuk> no, I'm a name, not a number
<ogra> :P
<Keybuk> bug #340796
<ubottu> Launchpad bug 340796 in udev "Add udev rule to allow users to use Freescale VPU on ARM MX51 SoC based devices" [Wishlist,Incomplete] https://launchpad.net/bugs/340796
<ogra> for that bug indeed :)
<Keybuk> might as well retitle that one just "udev rules for Freescale ARM MX51 based devices"
 * ogra adds 
<ogra> yeah, thats for video devices
<ogra> Keybuk, oh, the kernel patches arent upstream yet
<ogra> and are unlikely to get there in time for jaunty i guess
<Keybuk> heh
<Keybuk> are they on lkml?
<Keybuk> as long as they've hit there, udev upstream is generally happy
<ogra> i doubt it, amitk only added the patchset to our kernel yesterday and i think he is still working on sanitizing it for us before anyone even thinks about sending tehm upstream
<directhex> "There was a rumour that, in the wake of the TomTom case, Canonical was seriously considering removing Mono from main and leaving it to multiverse as too dangerous to support (like mp3). I havenât been able to find any more info either way, asking around. "
<directhex> yay for boycottnovell :)
<soreau> Hello
<slangasek> mdke: do you think we should have a whitelist of those universe packages whose UIs wind up in the relevant documentation, or some other way to describe this?
<slangasek> pochu: ah, I don't know what semantics they're using for that tag, but they don't seem to have requested a UIF :)
<slangasek> (e)
<soreau> I know this may not be the correct place to ask but I am having the bug 99908 "The ext3 file system creation in partition # of SCSI (0,0,0) (sda) failed." on both Hardy and Intrepid alternate. Is there any possible way that I can get around this to install ubuntu?
<ubottu> Launchpad bug 99908 in ubiquity "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [Undecided,Incomplete] https://launchpad.net/bugs/99908
<slangasek> seb128: middle of the milestone freeze, so not really
<soreau> Actually, I am having the bug in the alt install, not the gui ubiquity (if they are different)
<seb128> slangasek: you reply to a question from 8 hours ago?
<slangasek> pitti: gnome-themes-ubuntu> sounds fine; also rescued some space because libavformat52 had been sneaking in when it shouldn't, and causing problems
<seb128> slangasek: if that was a "can I upload" I did upload what I wanted to get in beta6 so it's all good from my side ;-)
<slangasek> seb128: yes, that's what I do when people ask me questions in the middle of the night ;)
<seb128> slangasek: yeah, I was just not sure about the context
<seb128> I forgot, the day has been busy ;-)
<slangasek> ok. :)
<soreau> Does anyone have a suggestion to this issue I am experiencing?
<ogra> Keybuk, i'm not touching the bug until i have more info from kernel team
<cjwatson> soreau: firstly, I would strongly recommend that you regard your problem as a new bug, not tag along with an existing bug; that error message is general and can have many causes, and conflating lots of bugs into one report makes them less likely to get fixed
<cjwatson> soreau: secondly, we have had some recent (new!) problems in this area. Have you tried with *today's* daily build, since we installed some fixes yesterday?
<cjwatson> soreau: or are you referring to a problem in a stable release of Ubuntu?
<soreau> Only with 'stable' releases, 8.04 and 8.10 Alternate cd's
<cjwatson> soreau: can you please file a *new* bug and attach your logs to it? you can extract them by going back to the installer main menu and using the "Save debug logs" item
<cjwatson> then give me the bug number
<slangasek> Riddell: ah, you fixed the xine-lib issue, great :)
<soreau> No, I have grown weary with frustration. I was only wanting to know if there was a quick fix solution. Sorry, but I think I'll try that windows ubuntu installer next.. wubi?
<soreau> cjwatson: Thanks for your input though
<cjwatson> soreau: um, please?
<cjwatson> soreau: I can't investigate this and answer your question without seeing the logs
<cjwatson> soreau: if I see your logs, there might well be an easy answer for you
<cjwatson> but I can't tell you off the top of my head based on just a general error message
<ScottK> soreau: He's the senior developer on installer stuff so you won't get a better shot at an answer.
<soreau> cjwatson: Well now that I have been trying this so long, I decided to nuke the ntfs partition so am beginning to reinstall windows (not by my choice, all's I wanted to do was make my friends bug ridden xp install a dual boot linux pc)
<cjwatson> I'm also hoping that soreau might be one instance of a more general problem, in which case I might get to fix it for lots of people for 9.04
<soreau> cjwatson: But, if it will help you, and the alternate cd is capable of mounting my usb stick (any sane mount/umount command give 'invalid argument' btw) then tell me a list of logs you would like to see and I'll try my best to pastebin them for you
<soreau> dmesg was polluted with I/O errors so it may even be HW failure which would be puzzling since xp seems to have no such trouble installing
<cjwatson> I routinely need /var/log/syslog and /var/log/partman
<soreau> Yes, and what else?
<cjwatson> that's all
<cjwatson> soreau: do you have another computer on the same network that you can ssh into?
<cjwatson> or just network-accessible at all, I suppose
<soreau> Yes, but for what purpose?
<cjwatson> well, you can switch to tty2, run the command 'anna-install openssh-client-udeb', and then you can just scp the log files out
<soreau> This is only happening on this A45-S120. All my desktop pc's have never had this problem
<cjwatson> much easier than messing around with USB sticks
<soreau> cjwatson: Oh, you mean on the problem lappy..
<cjwatson> yes
<soreau> cjwatson: Ok, give me a few moments please
<soreau> cjwatson: To make sure and clarify, you want the logs after the failure (of course) correct?
<cjwatson> yes
<soreau> ok, sec
<soreau> cjwatson: I have the files but I need help because ifconfig isn't even available (?)
<soreau> What would a usb stick be list as in /dev?
<Keybuk> sd[a-z][0-9]+
<ogra> just look at the output of the dmesg command after you plugged it in
<soreau> ah yes
<calc> pitti: yea iirc i got that error when i was trying to backport the changes also
<calc> pitti: which was when i decided i didn't know enough about what I was doing to keep from breaking things, heh
<pitti> calc: oh, then it seems that I just duplicated your backporting work
<pitti> calc: yeah, NFC what this wants to tell me
<cjwatson> soreau: the network should already be up by the time you encounter this bug; you can use the ip command if you need it, things like 'ip addr show'
<soreau> cjwatson: /var/log/syslog -> http://pastebin.com/m34edc693 /var/log/partman -> http://pastebin.com/m5566d0fb
<soreau> doesn't look too good to me
<cjwatson> soreau: ok, so there are indeed a vast number of input/output errors in there, as you said earlier
<soreau> yup
<cjwatson> soreau: since you said that XP is fine, it's probably a Linux kernel bug; since it isn't an installer problem as such (the installer is just the victim) it's outside my realm of expertise
<soreau> okays
<cjwatson> soreau: if it were me I'd start by messing around with the boot options provided in the F6 ("Other Options") menu at the CD boot menu
<Keybuk> really?
<Keybuk> those errors are pretty much definitely dead disk
<cjwatson> XP being fine tends to suggest that it might be the 1% of cases where it's the driver that's busted
<soreau> cjwatson: I think I will try this wubi thing. Thanks for looking
<Keybuk> how would you test the Live CD on XP?
<cjwatson> assuming that XP is in fact still fine
 * Keybuk is looking at the sr0 I/O errors
<cjwatson> Keybuk: (a) this isn't a live CD (b) there are also a slew of I/O errors about sda
<Keybuk> ah
<cjwatson> soreau: this is just advice and you're free to ignore it, but I would be surprised if it worked any better. It'll be using the same disk driver
<Keybuk> there's some odd pnp errors too
<soreau> Keybuk: The sr0 errors I've seen on several different machines only with 8.10 disks
<cjwatson> CDs are the most unreliable allegedly-reliable medium I've ever encountered
<Keybuk> cjwatson: certainly CD+-*Rs :p
<cjwatson> a speck of dust on the lens causes immense confusion
<soreau> heh, perhaps there is a reason that's not the first time I've heard that
<cjwatson> and the physical media is so cheap nowadays that it's cheaply-*made* too, so gets scratched really easily
<soreau> cjwatson: How about ubuntu
<cjwatson> hmm?
<soreau> s fancy disk check program?
<cjwatson> you mean the checker on the CD boot menu?
<soreau> yea
<cjwatson> all it does is read through all the files on the CDs and check their checksums
<calc> pitti: you might try asking on their mailing list but it seems to have very low traffic
<calc> pitti: other than that i have no clue
<soreau> cjwatson: Not the entire cd as a whole collectively?
<soreau> iso image even
<cjwatson> in some cases it isn't guaranteed to throw up the same errors; I've seen some anecdotal evidence that read order makes a difference. But in any case it will not solve your problem
<cjwatson> soreau: (a) how would that help? (b) where would you store the checksum that it would compare against? :-)
<soreau> cjwatson: I have no idea, that's just how it's always worked in my head ;)
<cjwatson> soreau: it's easier and more useful to check at the filesystem level
<soreau> cjwatson: In any event, after I get the results from this wubi thing I'll let you know
<soreau> This is probably the worst nightmare I've ever had attempting to install linux but I blame the crappy hw in this laptop
<cjwatson> soreau: so Keybuk and I are looking at this, and what's happening under the covers is that the kernel has repeated trouble trying to talk to your disk (possibly relatively minor trouble but just lots of it; hard to say) and eventually decides that it's all too hard and disables the disk
<slangasek> NCommander: you can't recommend libxine1-ffmpeg in xubuntu, its dependencies are blacklisted from CDs by Ubuntu technical board resolution 2007-01-02.
<Keybuk> the disk errors the kernel is having are DMS related
 * NCommander peeks at the seed to see whats pulling it in
<slangasek> xfmedia
<Keybuk> err, DMA related
<NCommander> ew
 * NCommander guesses we'll have to drop xfmedia then
<TheMuso> or remove the recommends
<slangasek> instead of dropping xfmedia's recommends: on libxine1-ffmpeg?
<NCommander> The package more or less is useless without it
<TheMuso> NCommander: how so?
<cjwatson> it only seems to be on write. parted manages to *read* the partition table fine
<NCommander> Ugh, there was a bug on this
<NCommander> We added the recommends to close it
<soreau> cjwatson: I think it's noteworthy that after this problem rerunning the partitioner shows no partitions but only the main disk and update-dev does nothing to help. Rebooting shows the bootloader has been nuked. After running the xp install disk, it shows all partitions and reinstalling the XP BL to the MBR allows it to at least boot xp again
<pitti> calc: ok, disabling the test suite work around that weird init.sql problem
<soreau> cjwatson: If there's any possibility it may be running out of mem as this thing only has like ~230MB or so
<cjwatson> soreau: after this problem, the kernel has entirely disabled access to the disk
<soreau> Wow
<cjwatson> (until you reboot)
<soreau> no wonder
<slangasek> NCommander: so do you want to pull xfmedia from the ship seed, or should I upload xfmedia to drop the recommends?
<soreau> I wonder why it causes the boatloader on the mbr to disappear or malfunction
<cjwatson> soreau: I think out-of-memory is unlikely as it enabled swap just before the disk problems started; besides 230MB is well over spec for the alternate installer itself (although tight for the Ubuntu desktop)
<cjwatson> soreau: possibly it started writing the partition table but didn't complete the write
<calc> pitti: disabling test suites might not be a good idea depending on why they fail :)
<pitti> calc: yeah, it was just a test; I'm bisecting the test suite now to isolate it
<calc> pitti: iow will it fail with other software too
<cjwatson> the DOS partition table format does not really permit ideal resilience here
<calc> pitti: ah ok
<pitti> calc: any luck with xom?
<calc> pitti: let me see, i started it a bit ago
<calc> pitti: yea it fails on i386 for me, works on amd64 for me
<Keybuk> soreau: could you try a boot with libata.dma=0 on the kernel command line?
<calc> pitti: restarting on i386 to make sure it is consistently failing
<soreau> Keybuk: Yes, I can but I will need some time
<pitti> calc: hm, sounds like a java compiler error then?
<calc> pitti: it seems to consistent pass on amd64 and fail on i386
<calc> pitti: seems that way to me with my little knowledge of the situation
<pitti> calc: hm, isn't it arch:all?
<pitti> weird
<cjwatson> soreau: we're in no rush; I'm going out soon anyway
<calc> pitti: yea so it would seem to be something related to the openjdk on i386
<soreau> cjwatson: Thanks for looking into this, I appreciate it FWIW
<calc> pitti: java code that compiles on amd64 should compile the same on i386 (aiui anyway)
<soreau> Keybuk: ETA ~30-45mins
<NCommander> slangasek, https://bugs.edge.launchpad.net/ubuntu/+source/xfmedia/+bug/307578 - do we have another way to fix this, or is it simply not possible to ship MPEG support out of the box?
<ubottu> Ubuntu bug 307578 in xfmedia "libxine1-ffmpeg not installed with xfmedia" [Medium,Fix released]
<Keybuk> soreau: np. if you could grab the syslog and put the url here, I'll get beeped :p
<slangasek> NCommander: you can't ship MPEG support out of the box that relies on libavcodec52.
<slangasek> NCommander: you could seed totem instead, and then the codec finder would do the work for you :-P
<NCommander> ugh
<calc> pitti: when it failed the one time in the past for me i might have been trying it on an i386 chroot then too
 * NCommander doesn't even know when we made this seed change
<NCommander> slangasek, will dropping it to a Suggests work for you? I don't like changing seeds without talking to the other Xubuntu guys.
<calc> pitti: i occasionally build for i386 when testing things but not very often, but it is currently looking like it always fails on i386 and always passes on amd64
<Keybuk> ...I really quite like this HP Mini
<pitti> calc: if it fails building one particular file, maybe you can isolate it, so that upstream has a test case?
<Keybuk> much nicer than the Dell
<Keybuk> </blasphemy>
<calc> pitti: i'll see what i can find out
<slangasek> NCommander: yes, I can drop it to a suggests; and 'bzr blame' will tell you when the seed was changed
<NCommander> Keybuk, which HP?
<pitti> calc: having a bug filed about this would be nice, and then we can revert to gcj for jaunty
 * calc is also doing gvfs testing since it appears no one has done thorough testing of the fuse layer and needs it to work right for jaunty OOo :-\
<Keybuk> NCommander: "HP Mini"
<Keybuk> 1000 I assume
<calc> pitti: ok
<NCommander> Oh, I didn't realize there were multiple ones
<slangasek> NCommander: actually, the seed itself was changed back in 2008 - I think it's xine that has changed since then
<Keybuk> if there are, we're probably not supposed to know about them or talk about them ;)
<calc> pitti: i'm headed to lunch now, but i should be back in about an hour
<NCommander> I'll drop it to a Suggests, then I'll talk to Cody on what we want to do; I didn't know I was breaking a TB rule with recommending libxine1-ffmpeg
<Keybuk> you were breaking the law
<Keybuk> now, we break your legs
<Keybuk> :p
 * NCommander tries to find the TB resolution to cite in the changelog
<Keybuk> grep for "OMG WE'RE ALL GOING TO JAIL! I REFUSE TO BE YOUR BITCH, JAMES"
<NCommander> Oddly enough, all that popped up was a quote from House ...
<cjwatson> http://irclogs.ubuntu.com/2007/01/02/%23ubuntu-meeting.html
<RainCT> pitti: does the new gnome-power-manager add any nice features?
<pitti> RainCT: the statistics look fancier :)
<pitti> RainCT: but by and large, none that spring to your eye
<RainCT> Heh. I didn't know about the statistics, how can they be accessed from the GUI?
<pitti> RainCT: right-click on icon -> Energy consumption
<RainCT> ah, so I have to plug out the power cable to get there without using the terminal :P
<Turl> hi
 * Keybuk wonders why so many initramfs scripts grep /proc/cmdline to look for things
<Turl> I read this on a kernel changelog
<Turl>   * Set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y for i386/amd64/lpia
<Turl> why the change?
 * TheMuso discovers that studio is also shipping libavcodec52, however untangling it from our disks is a bit more difficult.
<pitti> I just checked, I still get CPU scaling, so it might not be as scary as it looks
<Keybuk> Turl: from ondemand?  because ondemand makes boot slow
<kees> MacSlow: heya; thanks for looking into the kerneloops breakage.
<Turl> Keybuk: but ondemand drains my battery :p
<kees> MacSlow: the bug still shows that kerneloops is "confirmed", should that be flipped to invalid now?
<Turl> performance, sorry :p
<cjwatson> Keybuk: IIRC, only foo=bar gets passed through as environment variables, not just foo
<NCommander> slangasek, http://paste.ubuntu.com/129851/ - here's my debdiff, if its Ok by you, I'll upload this after it finishes test building.
<Keybuk> cjwatson: right, but most of these are looking for that
<Keybuk> Turl: that's ok, it'll be set to ondemand once you've finished booting
<Turl> Keybuk: ok then, hope my laptop boots even faster :p
<pitti> Keybuk: scaling_governor is still "ondemand" for me
<pitti> Keybuk: is that set later in the boot sequence?
<slangasek> NCommander: mmm, please don't make changes for miscellaneous lintian warnings for an upload in the middle of the milestone freeze
<pitti> Keybuk: ah, you just said, nevermind
<Keybuk> pitti: well, not yet
<MacSlow> kees, well the fix in notify-osd to make the kernel oops is pushed upstream (notify-osd), what's missing still is a patch to upstream kerneloops (rather kerneloops-applet) to use a proper gtk+dialog and not a notification
<Keybuk> but then there's no kernel uploading with it no at ondemand yet either
 * NCommander fixes that
<MacSlow> kees, that's what I'm working on now
<pitti> Keybuk: hm, I thought I read it in the changelog, and I have -9 now
<pitti> ah, seems not recent enough
<Keybuk> I only see -8.28 on the changes list
<Turl> Keybuk: -9 -> http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_2.6.28-9.30/changelog
 * pitti has 2.6.28-9.29 installed
<TheMuso> a meta hasn't been uploaded either afaik
<slangasek> yes it has
<slangasek> but -9.30 which has the change FTBFS, seemingly because of m-i-t behavior changes ;)
<Keybuk> *blink*
<TheMuso> right launchpad tells me otherwise also
<Keybuk> why can't I see that on -changes
<TheMuso> because changes is laaaaaaaaaaaaaaagggggyyy?
<slangasek> s/changes/lists/
<Keybuk> slangasek: oh?
<MacSlow> kees, might still be tomorrow until I've that patch ready (for discussion) I'd first like to get feedback from the people in #kernel and #ubuntu-kernel on the look of the dialog
<TheMuso> slangasek: right
<Turl> another thing, about bug 337301, any idea when the kernel changes will be out there?
<ubottu> Launchpad bug 337301 in xserver-xorg-video-intel "Update to 2.6.3?" [Wishlist,Confirmed] https://launchpad.net/bugs/337301
<pitti> Keybuk: I saw it on -changes, FWIW
<slangasek> Keybuk: as far as we got with debugging it yesterday, yes.  I don't know if rtg has a handle on it today
<Keybuk> slangasek: nobody asked me about it
<NCommander> slangasek, http://paste.ubuntu.com/129853/ - how's this (followed by a bump-upload of xubuntu-meta once this publishes)
<Keybuk> what was the problem?
<slangasek> NCommander: the debdiff is fine.  why do you think you need to bump xubuntu-meta?
<NCommander> slangasek, won't xubuntu-meta ... oh right, I'm an idiot, we're not seeding libxine-ffmpeg directly
<slangasek> Keybuk: "depmod no workie"
<Keybuk> slangasek: -v
<NCommander> ignore me, I'm working without enough caffeine
<slangasek> Keybuk: that's as far as we got yesterday, rtg was still chasing the thread when I left
<soreau> Keybuk: To verify, is this correct?: file=/cdrom/pressed/ubuntu.seed initrd=/install/initrd.gz libata.dma=0 quiet --
<NCommander> slangasek, I just kicked off pbuilder, if its successful, I'll upload if that's fine by you
<Keybuk> soreau: yes
<slangasek> NCommander: I would prefer you upload immediately
<TheMuso> looks like 9.31 was uploaded a while back
<Keybuk> I'm pretty sure I've done multiple kernel builds with the new depmod and had no problems
<kees> MacSlow: cool great!  I'll excuse myself from this process now.  :)  I just got involved due to doing some packaging cleanups for the MIR, and then trying to debug the regression.  thanks!
<soreau> Keybuk: Unknown option 'libata.dma=0' ignoring
<Keybuk> soreau: oh
<Keybuk> slangasek: ohh, was somebody parsing depmod's *output* ? :p
<slangasek> yes
<Keybuk> oh
<Keybuk> yeah
<Keybuk> that's totally changed
<Keybuk> which is kinda the point, really
<slangasek> right, I didn't say it was m-i-t's /fault/ :)
<Keybuk> didn't say you did ;)
<Keybuk> but I like to know what I've broken
 * calc just realized he wasn't hungry, he is actually sick
<Keybuk> even if it's just so I can say "well, if you will put it there..."
<pitti> Keybuk: hm, /lib/modules/2.6.28-9-generic/modules.dep doesn't look any different to me; I just have an additional modules.dep.bin now
<Keybuk> pitti: it's missing the /lib/modules/2.6.28-9-generic/ bit
<calc> pitti: i'll update the xom bug and then i'm off for the day, hopefully i'll be better by tomorrow :)
<pitti> Keybuk: ah
<pitti> calc: no progress on the initdb front :(
<calc> pitti: ok
<pitti> calc: sick> ugh; get well soon!
<calc> pitti: thanks :)
 * calc updated the xom bug 329903 to indicate it appears to be openjdk's fault
<ubottu> Launchpad bug 329903 in xom "xom FTBFS in Jaunty on the i386 buildd but not on personal amd64" [Medium,Confirmed] https://launchpad.net/bugs/329903
<slangasek> NCommander: I guess you haven't uploaded yet?
 * calc off to bed now, if you need me (emergency) call me as I am sick
<cody-somerville> slangasek, is this a must do it now emergency?
 * NCommander was talking with cody since I got him just before I uploaded
<slangasek> cody-somerville: it's a "NCommander wanted to do the upload and I can't roll valid xubuntu CDs for the alpha until it's done and published" emergency
<cody-somerville> ah, Okay.
<cody-somerville> I'll de-seed xfmedia from ship
<slangasek> hrm?
<slangasek> why?
<cody-somerville> slangasek, xfmedia is in our ship seed as a courtesy
<slangasek> ah
<cody-somerville> slangasek, if people want to use xfmedia, I'd prefer it work for them
<cody-somerville> slangasek, so instead of removing the recommends I figure just de-seeding it is the optimal choice
<slangasek> cody-somerville: ok, fine with me - please unseed :)
 * cody-somerville waves his hands and casts some magic.
<NCommander> slangasek, side note, its a good thing I test built, the package FTBFS due to the change in the X11 headers itseems.
<MacSlow> pitti, ping
<cody-somerville> NCommander, YOU SHOULD ALWAYS TEST BUILD!
<cody-somerville> :D
<pitti> hi MacSlow
<NCommander> cody-somerville, of course. Rule number one of being a MOTU
 * cody-somerville hi5s NCommander.
<slangasek> NCommander: heh, ok
<Amaranth> NCommander: I thought rule number one of being a MOTU was to worship dholbach
<ScottK> worship/gang tackle at UDS
<cody-somerville> Is it worth it to upgrade to 18mb pipe from 10mb for an extra $40? :S
<ScottK> I'd go with no.
<Turl> cody-somerville: I'm in 3mb/256k, don't make me sad :p
<JanC> that's 18 millibit?  ;)
 * ScottK recently got upgraded from 10Mb to 17Mb or so for the price went down $0.50.
 * TheMuso is jellous.
<cody-somerville> ScottK, you went from 10mb to 17mb and the price *dropped*? What ISP are *you* with?
<ScottK> Verizon FIOS.  I was an early subscriber and they'd redone the plans.
<ScottK> I think that's what it was.
<cody-somerville> Verizon FIOS, is that ADSL or Cable?
<Amaranth> my grandma started with 5mbit cable and went up to 12mbit cable for less money as they upgraded the plans
 * TheMuso is currently on 8MB, which is the fastest in this area, unless i wanted to pay rip-off prices to our monopoly telco for faster speeds which aren't a certainty anyway.
<Amaranth> cody-somerville: It's...fiber
<cody-somerville> Oh, is fiber better than cable? :P
<ScottK> Definitely.
<slangasek> dietary fiber is better than dietary cable
<cody-somerville> So your 17mb fiber pwn my 18mb cable?
 * TheMuso would jump on HFC when he returns to sydney if the prices were reasonable.
 * Turl is on ADSL
<ScottK> cody-somerville: Well mine also comes with a stack of static IPs, so probably.
<Turl> T_T
<cody-somerville> oh wow
<Amaranth> cody-somerville: also his speed doesn't go down when his neighbor fires up bittorrent
<Amaranth> well, I guess that depends on how the system is setup but usually
<NCommander> cjwatson, is there any chance britney's run of ports could be fixed? It hasn't spit out a new page since 02/19: http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html
<TheMuso> NCommander: ouch really?
<NCommander> Yeah
<NCommander> See the generated date
<TheMuso> is this for CDs, or the archive in general?
<NCommander> Archive in general, so we have no up-to-date installability counts.
 * TheMuso nods
<Turl> libdrm-noveau1 is for nvidia cards, right?
<Turl> on its description it mentions intel instead of nvidia :/
<azeem> so file a bug
 * Turl filled bug 341294
<ubottu> Launchpad bug 341294 in libdrm "libdrm-nouveau1 mentions intel instead of nvidia on its description" [Undecided,New] https://launchpad.net/bugs/341294
<Lure> pitti: can you explain why such apport crashes are rejected - bug 341264
<ubottu> Bug 341264 on http://launchpad.net/bugs/341264 is private
<slangasek> pitti: a lot of duplicates on bug #335567 - do you know what's going on there?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/335567/+text)
<pitti> slangasek: haven't looked yet, but it's on my radar
<slangasek> pitti: ok. should it be milestoned for beta?
<pitti> slangasek: doing
<slangasek> ta
<pitti> Lure: because they have an absolutely useless stack trace and outdated packages
<pitti> Lure: in this particular case, the package isn't outdated, but rather nonexisting, hmm
<Lure> pitti: my system is up to date - and I do not hav gstreamer (Kubuntu)
<pitti> Lure: well, for this particular bug invalidating is probably alright, since there isn't much to be learned from it
<pitti> Lure: but in general, this "None" thing is interesting; can you please file an apport bug and give me the output of "dpkg -s phonon-backend-gstreamer"?
<Lure> pitti: I am more concerned about that other reports might be lost
<Lure> pitti: sure
<Lure> pitti: as I said no phonon-backend-gstreamer installed here, so apport message is correct ;-)
<pitti> Lure: this only happens on "useless stacktrace" && "outdated packages", so I don't think valuable bugs can get logs
<pitti> s/logs$/lost/, duh
<pitti> Lure: hm, sounds like an error with parsing alternative dependencies then
<Lure> pitti: ok, so should I still submit apport bug?
<pitti> Lure: it's purged?
<pitti> Lure: yes, please
<Lure> pitti: will check
<pitti> Lure: thanks
 * Lure is not sure as I got some gnome depens installed by accident
<pitti> Lure: it's the preferred alternative of "phonon"
<pitti> Depends: phonon-backend-gstreamer | phonon-backend
<pitti> I think that's what's confusing apport
<Lure> pitti: yes, that might be it
 * pitti calls it a day
<pitti> good night everyone
<Lure> pitti: good nite, and thanks
<cr3> might it be possible that something changed on jaunty where running debuild now creates files under debian/tmp/usr/local/share instead of debian/tmp/usr/share?
<TheMuso> cr3: are you working with a python package?
<cr3> TheMuso: yep
<TheMuso> cr3: if so, is it using distutils?
<cr3> TheMuso: yep again
<TheMuso> cr3: you need to add --install-layout=deb to the setup call I think it is, let me double check that.
<TheMuso> cr3: its part of the python 2.6 transition.
<cr3> TheMuso: I had that problem in another package, I didn't think that flag also affected the location of share files
<cr3> TheMuso: thanks for the tip, I know where I need to go from here :)
<TheMuso> cr3: yeah I think it does
<TheMuso> cr3: np
 * cr3 needs to go get some coffee, that's where he needs to go
<ScottK> cr3: TheMuso is correct.  It affects that too.
<ScottK> The idea is to get packages installed using just distutils into /usr/local and away from where the packaging system installs stuff.
<cr3> ScottK: reasonable enough :)
<ScottK> Yes, just slightly painful at the moment.
<slangasek> cr3, ScottK, TheMuso: hmm, nice discussion; 'zgrep usr/local dists/jaunty/Contents-i386.gz' points to a few bugs that need to be filed
<slangasek> I can't tell if the python-twisted ones are the fault of distutils though
<ScottK> slangasek: Probably faster to fix than file.
<slangasek> there is that
<ScottK> I think twisted does some weird stuff in /usr/local, but doko does mind the twisted stuff pretty well.
<slangasek> well, it installs binaries to /usr/local/bin, which is a policy violation
<ScottK> slangasek: Any chance you could pour the output from your zgrep into a wiki page we could point people at?
<doko> if there is stuff in /usr/local in packages, then the pkgbinarymangler doesn't work as expected :-/
<slangasek> ... why is it pkgbinarymangler's problem?  or is pkgbinarymangler supposed to abort?
<doko> it is
<slangasek> ah
<doko> if there's stuff in /usr/local, it's a bug in the apckage of course
<ScottK> I guess I shouldn't complain since the McDonald's wifi is free, but 2+ minutes for apt-get update is really annoying.
<davmor2> Guys I've just done a freesoftware only install and jockey is asking if I won't to install the nvidia drivers I thought this was disabled in fso version?
<mdke> slangasek: I'd like to ask the -doc mailing list, I'll copy you in if that's ok.
<slangasek> mdke: sounds good
<mdke> thanks
<kirkland> superm1: i have a couple of dkms issues at play here
<kirkland> superm1: one of which is the fact that i need the headers for the specific kernel that is being compiled against
<kirkland> superm1: (as well as any others that might be booted)
<kirkland> superm1: what do you think of having dkms depend on all of the kernel headers?
<kirkland> superm1: too heavy handed?
<slangasek> eew
<kirkland> slangasek: you eew'ing me?
<slangasek> kirkland: yes. :)
<cody-somerville> eww
<kirkland> slangasek: awesome!  then you can help me figure out how to solve this problem
<kirkland> slangasek: kvm-source provides a dkms module for kvm
<kirkland> slangasek: it needs the linux-headers for your kernel to build
<kirkland> slangasek: how do put this in a debian/control file correctly?
<kirkland> slangasek: linux-headers is a virtual package that tells you to install one of (*)
<kirkland> slangasek: nvidia depends on linux-headers | linux-headers-generic
<slangasek> heh, nvidia's is backwards then
<slangasek> it's meant to be linux-headers-generic | linux-headers (real package first, virtual package after)
<slangasek> cf. virtualbox-ose-source
<kirkland> slangasek: sorry, that's my transcription (not cut and paste)
<kirkland> slangasek: okay, how do i work linux-headers-server into that mix?
<slangasek> kirkland: poorly? :)
<slangasek> kirkland: you could get a set of metapackages that depend on "linux-headers-foo + linux-image-foo" and have an or'ed dep on those
<kirkland> slangasek: so you don't think linux-image-foo should just depend on linux-headers-foo, and bring it on with it
<kirkland> slangasek: it would be better to add this layer of another metapackage
<slangasek> I think it's useful to a lot of people who don't need dkms to be able to install linux-image-foo without the headers
<slangasek> but perhaps linux-foo should pull it in
<slangasek> it already pulls in lrm-foo today, after all
<kirkland> slangasek: 'twould solve my current issue ....
<slangasek> and is described as being "complete" :)
<kirkland> slangasek: are you still thinking on this?  can i ask the kernel folks to do this?  or does a more formal proposal need to be drafted and ratified?
<slangasek> kirkland: given that the desktop tasks all pull it in by default, and we're talking about also pulling it into server, refactoring so it's pulled in by linux-foo seems perfectly reasonable to me (while also leaving the Recommends: in place for desktop so that we don't also pull in lrm by default)
<slangasek> kirkland: I don't think it needs to be any more formal than a bug report
<kirkland> slangasek: i can do that, thanks.
<brettalton1> kirkland: I was just watching your UDS Jaunty video on YouTube: http://www.youtube.com/watch?v=R-783GBVLIg&feature=channel_page
<brettalton1> kirkland: and I was wondering, with Jaunty, if I have a 500GB hdd that is mounted as /storage, how would I fully encrypt that it using the same tools you created to encrypt /home?
<kirkland> brettalton1: well, you could do that with ecryptfs, but it might make more sense to use a device encryption scheme there
<kirkland> brettalton1: if you really want to do it with ecryptfs, you could do:  "sudo mount -t ecryptfs /storage /mnt"
<kirkland> brettalton1: you'll go through a few questions, choosing the passphrase, key size, crypto algorithm, etc.
<kirkland> brettalton1: then you'll read/write data to /mnt
<kirkland> brettalton1: the encrypted data will land in /storage
<brettalton1> kirkland: sounds easy enough :) what's the difference between ecryptfs and a device encryption scheme? one is through software (ecryptfs) and the other I assume is hardware-related, correct?
<kirkland> brettalton1: not at all
<kirkland> brettalton1: they're both through software
<kirkland> brettalton1: and they're both handled in the kernel
<kirkland> brettalton1: ecryptfs encrypts each individual file as a unit
<kirkland> brettalton1: device encryption encrypts the entire device as a unit
<brettalton1> kirkland: ahhhh, okay, so last question: what would I use/do to encrypt the whole device?
<kirkland> brettalton1: in this situation, i would use lvm + luks for encryption of that entire device
<kirkland> brettalton1: i believe that ecryptfs really shines on per-user encrypted home directories
<kirkland> brettalton1: even though it can be used for other things
<kirkland> brettalton1: https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto
<kirkland> brettalton1: it sounds like this is what you're trying to do ... encrypt an entire filesystem
<brettalton1> kirkland: perfect, I'll research that. I appreciate your time, especially since it's one on one time with an Ubuntu developer :)
<brettalton1> kirkland: exactly
<kirkland> brettalton1: ecryptfs is better at encrypting some subset of the filesystem
<brettalton1> kirkland: so /home inside /... got it
<kirkland> brettalton1: like your home directory, or just one "private" directory inside of your home directory
<kirkland> brettalton1: you're welcome.  cheers ;-)
<brettalton1> kirkland: makes sense, thank you!
<directhex> ecryptfs sounds a lot like encfs
<kirkland> slangasek: created https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/341405
<ubottu> Ubuntu bug 341405 in linux "linux-foo should depend on linux-headers-foo" [High,New]
<kirkland> directhex: it is, but ecryptfs is in the linux kernel;  encfs is entirely userspace
<directhex> kirkland, is that desirable?
<kirkland> directhex: it is to me
<directhex> fair enough
<kirkland> i'm a bit slammed right now, and don't really have the time to defend the strong points of ecryptfs, sorry
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/341405
<ubottu> Ubuntu bug 341405 in linux "linux-foo should depend on linux-headers-foo" [High,New]
<kirkland> slangasek: you can comment on that, if i've failed to do the justification justice
<directhex> kirkland, i'm not ranting, i was just curious. i'd heard only of encfs, so wondered what the difference was
<kirkland> directhex: https://wiki.ubuntu.com/EncryptedPrivateDirectory
<kirkland> directhex: search for encfs in that page
<kirkland> directhex: the sourceforge page is no more
<kirkland> directhex: https://answers.edge.launchpad.net/ecryptfs/+question/46302
<directhex> kirkland, srsly, go back to what you were workign on, don't let me disturb you
<kirkland> directhex: cheers
<kirkland> directhex: come debate it in #ecryptfs on irc.oftc.net, if you're interested in some answers;  there are other maintainers there too
<directhex> kirkland, not *that* interested, just noticed a small enough gap in my knowledge to ask ;)
<kirkland> directhex: sure.  it's a common question
<cjwatson> NCommander: whoops, sorry about that. Looks like I didn't sync the binary Python modules across from the non-ports run properly. I've fixed that and the page is now updated
<NCommander> cjwatson, thanks, no problem
 * NCommander is just beating his head in w.r.t. to GCC
<cjwatson> hmm, we seem not to be running maxb's outdate report for all components regularly, for some reason
 * maxb really ought to get around to making that include P-a-s information, come to think of it
<slangasek> ok, what keeps launching a separate copy of gnome-power-manager as root on my system?
<cjwatson> maxb: I've updated the relevant cron job to run your script now; sorry about that
<cjwatson> apparently we'd run it once and then forgotten about it, or something
<Amaranth> slangasek: gdm?
<slangasek> Amaranth: yuck then?
<seb128> Amaranth: we still use the old gdm codebase there is no reason it should start it
<seb128> Amaranth: and gdm runs as gdm user
<seb128> slangasek: it could be dbus activated by something you run under sudo
<slangasek> twitch
<dtchen> TheMuso: will need to work logic into removing the notifier hint for #328245, because we can't unconditionally remove it for derivatives not using PulseAudio
<TheMuso> dtchen: point
<dtchen> seb128: is there a timeline for $GNOME_DESKTOP_SESSION_ID going away (i see it's deprecated)? is there a recommended method of checking if GNOME is the user's active session?
<seb128> dtchen: I don't think it's going away soon, setting it is cheap and some softwares rely on it
<seb128> dtchen: check for DESKTOP_SESSION=gnome I guess
<dtchen> hm, it seems to be 'default' in a default 9.04 install
<dtchen> i can just check $GNOME_DESKTOP_SESSION_ID being defined, then. thanks.
<seb128> dtchen: http://bugzilla.gnome.org/show_bug.cgi?id=542880
<ubottu> Gnome bug 542880 in gnome-session "GNOME_DESKTOP_SESSION_ID not set anymore" [Major,Resolved: fixed]
<dtchen> seb128: right, thanks
<seb128> dtchen: yeah, do that or verify if gnome-session is running
<kirkland> superm1: let me know what you think about the dkms patch attached to https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/dkms/+bug/341159
<ubottu> Ubuntu bug 341159 in kvm "package kvm-source 1:84+dfsg-0ubuntu7 failed to install/upgrade: " [High,Triaged]
<blueyed> OFFTOPIC: need some rest? here's some horse porn: http://hellkeyhole.com/horse-porn
<Nafallo> ehrm.
<Nafallo> please don't link to porn in this channel...
<blueyed> Nafallo: sry, that's been the channel with the most nicks.. ^^
<Nafallo> why would that be relevant?
<blueyed> more people that would laugh per posted offtopic link.
<Nafallo> blueyed: you do realise that link includes some... ehrm... real porn at the bottom, right?
<ion_> Or more people to get annoyed by it. :-P
<blueyed> Nafallo: sry, haven't realized.. I've not thought about scrolling down after catching up from the floor..
<cody-somerville> there is porn right on the right!
<LjL> and the left! and the top!
<blueyed> ion_: yes, I don't want to disturb at the end.. but the picture itself was so funny after all.
<blueyed> porn in the bedroom?
<ajmitch> in other words, pasting that link was a seriously stupid thing to do
<cody-somerville> It isn't even that funny
<cody-somerville> FUNNY LINK FAIL
<blueyed> ajmitchm, cody-somerville: I'm still LOLLING about it.. but I get your point. Please execute me, I'm drunk.. ;P
<cody-somerville> blueyed, evidently
#ubuntu-devel 2009-03-12
<TheMuso> slangasek: Whats the reason for the studio rebuild?
<slangasek> TheMuso: update-manager on the ISO is broken miserably to the point where you can't run it to upgrade it to the fixed version
<TheMuso> slangasek: oh.
<slangasek> sorry - unexpected breakage from unsanctioned uploads during the milestone freeze. :/
<TheMuso> Oh well, I'll try and fit a couple of tests in today, but its up to the others to test studio, since my work day is almost done, and I'm off tomorrow. :)
<slangasek> TheMuso: ok - any names you want to give me of people to prod?
<TheMuso> slangasek: I know Cory/_MMA_ is testing, and I am about to put an email out to our community to see if I can cause an about face and get some testers.
<slangasek> ok, cheers :)
<slangasek> superm1: ^^ mythbuntu respun for the same reason, sorry
<ScottK> asac or fta: Is there some need for mozilla-devscripts to still depend on Python 2.4?
<fta> ScottK, none, i can update that if you want, i'm upstream
<ScottK> fta: Please.
 * fta makes a mental note for tomorrow
<calc> all the doctor could figure out about me was he thinks i have a virus that isn't the flu and says i should be well in 3-4 days :-\
 * calc goes back to bed
<superm1> slangasek, aw :(, for a once we were gonna be done with testing early
<slangasek> yeah
<slangasek> sorry, doesn't seem to ever work out that way :)
<slangasek> calc: get well soon!
<superm1> well at least nothing that i need to frantically chase down and write a patch for, always easier when it's other peoples stuff
<ebroder> Is there any chance of getting a feature freeze exception for bug #340993 if I prepared a patch?
<ubottu> Launchpad bug 340993 in alpine "alpine's ./configure wants Build-Depends and Depends: aspell" [Undecided,Confirmed] https://launchpad.net/bugs/340993
<ebroder> (It's a one line patch to the control file - alpine actually already depends on aspell)
<stgraber> ebroder: I'm not sure it would even need a FF exception as it looks like a bug (missing build-dep) and doesn't need any change to the code.
<ebroder> stgraber: Awesome. I'll go ahead and put the patch together. Thanks
<stgraber> hmm, don't we install recommends by default since Intrepid ? for some reason my LTSP install lacks ldminfod which I made a recommend of ltsp-server (ltsp-server is installed and ldminfod is on the cd ...)
 * stgraber must have missed something with what happens with recommends at install time
 * ScottK isn't sure it's meant to be fully expanded.  Direct recommends are installed, but not sure about recommends of dependencies.
<kirkland> slangasek: okay, so i have a well tested kvm upload that would fix 4 bugs, 2 of which are installation issues
<kirkland> slangasek: is this a candidate for upload during freeze?
<slangasek> kirkland: are you wanting the alpha-6 CDs respun in response to the upload too, or do you just want the fixes picked up opportunistically?
<kirkland> slangasek: the latter
<kirkland> slangasek: it can wait until tomorrow, no real rush
<kirkland> slangasek: whatever you recommend
<slangasek> kirkland: uploading now is fine; currently I don't anticipate any other problems that would necessitate an ubuntu-server respin, though
<kirkland> slangasek: awesome, thanks
<TheMuso> /c/
<IntuitiveNipple> Any indication of what time alpha-6 will be available?
<ScottK> When it's ready.
<ScottK> There are probably candidate ISO images that need testing.
<ScottK> At this point there's a very good chance that whatever you test is what will be Alpha 6 (no guarantees).
<JanC> alpha6 minus serious bugfixes I guess
<IntuitiveNipple> Thanks. I'm about to test on a bunch of notebooks and want to netboot and CD-boot test from alpha 6 images
<stgraber> https://iso.qa.ubuntu.com for links to the current iso images
<ScottK> JanC: At this point unless it's really disasterous we'd likely release note any significant problems discovered.
<IntuitiveNipple> stgraber: thanks... that confused me, the link wouldn't load. It's HTTP not HTTPS :)
<IntuitiveNipple> Now to figure out a pxeboot config to allow 32/64 bit images
<stgraber> IntuitiveNipple: right ... we still haven't https setup there.
<soreau> cjwatson: So I ended up using that wubi installer and got ubuntu installed though I guess it lives in ntfs land somehow now
<soreau> Would it be safe to install grub to the MBR like 'normal'? Currently the windoze boot loader loads grub
<dholbach> good morning
<ebroder> Hmm...how do you give a bug different statuses for different releases?
<ebroder> Can I do that, or does it have to be a MOTU or something?
<KaiL> I see all those blueprints about boot time - but they are all for the very early stages? If you go on that way, the X server will take half the boot time soon ;)
<pitti> Good morning
<KaiL> eeek
<KaiL> this bug hurts (esp. my ears) *G*
<pitti> thekorn: I'd like to write a test suite for apport's launchpad crashdb implementation, and after that, switch to your launchpadlib branch
<pitti> thekorn: mind if I commit a fix to storeblob.py to optionally use staging?
<thekorn> pitti, good idea, go go go ;)
<pitti> bdmurray: ^ I think you had that problem as well recently
<pitti> thekorn: storeblob.py needs to stay anyway, if i switch to LP, I'll just copy it back to the apport source
<Mez> did anyone know that the Jaunty alha 5 alternate CD is broken?
<soren> pitti: Perhaps you can answer this... The build log for opennebula clearly show an opennebula-dbgsym package being built, but I don't see it on ddebs.ubuntu.com?
<soren> pitti: Hm.... They're there for lpia, armel and i386.
<soren> pitti: Can you see what happened to the amd64 one?
<pitti> soren: when was it built?
<pitti> soren: sometimes they just get lost
<pitti> the stuff to build ddebs.u.c. is unfortunately quite brittle
<soren> Feb 20th.
<pitti> ok, too late to retrieve it from the buildds then
<pitti> soren: so, sorry, I can't check it any more
<soren> No worries. I'll rebuild locally and use that.
<siretart> seb128: thanks for your rocking ffmpeg bug triage!
<tjaalton> so.. every time the kernel ABI is changed, apparmor rules cannot be reloaded?
<tjaalton> until you reboot the new kernel
<seb128> siretart: you're welcome, thanks for the triaging hints
<seb128> siretart: there is still lot of users who have crashes on flv and mp4 files which seem due to gst-ffmpeg but I don't get those crash here
<directhex> bug triage on ffmpeg? that's a hero's job
<siretart> seb128: is there some (preferably commandline) utility like ffplay but that uses the gstreamer demuxers with avcodec?
<siretart> that would be helpful to verify if the gst-ffmpeg demuxer is producing garbage
<seb128> siretart: I don't know
<seb128> siretart: but see http://bugzilla.gnome.org/show_bug.cgi?id=573400
<ubottu> Gnome bug 573400 in gst-ffmpeg "[gstffmpegdec] crashes with hardware-accelerated decoders." [Blocker,Resolved: fixed]
<seb128> siretart: we will get the fix soon, I'm just wondering why it doesn't crash here if the code is obviously buggy
<directhex> you could use gst-launch with the right voodoo
<directhex> but it's a sucky command line
<seb128> gst-launch playbin uri=URI
<seb128> that's the equivalent of playing in totem
<seb128> but not what you want for such debugging
<siretart> whats the problem with "gst-launch playbin uri=URI"? it seems a useful debugging aid!
<siretart> as for vdpau, I don't know a single person with vdpau capable hardware. I have no idea if the current ffmpeg even works with vdpau properly
<seb128> none, but I though you wanted to get the demuxer output dumped somewhere
<siretart> perhaps it makes sense to disable it for 9.04, and retry with karmic
<seb128> siretart: well that's what the svn commit does
<seb128> siretart: we just have 22 duplicates of this bug and lot of users who can get the crash easily
<seb128> where I don't get an issue on any of the video they provided
<siretart> I mean if I should disable that in libavcodec52 as well
<seb128> I'm just wondering if that's video card dependant
<seb128> or something similar
<seb128> ah ...
<siretart> but wait, are these ppl having libavcodec52 or libavcodec-unstripped-52 installed?
<seb128> you are better placed to respond to that question ;-)
<seb128> siretart: does it make a difference?
<siretart> because only the latter one has vdpau support
 * seb128 tries
<siretart> for vdpau support I need to build depend on the vdpau headers, which are pacakged in 'restricted' and not in main
<directhex> i have vdpau-capable hardware, if that helps
<Keybuk> I bet my X server crashes when I do this ...
<seb128> E: Package libavcodec-unstripped-52 has no installation candidate
<seb128> siretart: ^?
<siretart> seb128: yes, that pacakge is in 'multiverse' for reasons that jono is currently clarifing
<seb128> siretart: gotcha
<siretart> directhex: I would appreciate if you could confirm that ffplay with libavcodec-unstripped-52 is able to make use of vdpau acceleration
<directhex> siretart, it'll have to wait until this evening, sadly
<siretart> no problem
<seb128> siretart: you rock!
<seb128> siretart: I get the crash too now
<siretart> :)
<seb128> siretart: so it's the unstripped version creating the issue
<seb128> there is lot of users who install that one apparently
<siretart> seb128: does it also crash with ffplay, or only with gst-launch?
<directhex> "unstripped" means "moar awesome"
<directhex> hang on, i thought gstreamer-ffmpeg used its own embedded copy of ffmpeg, hence why it's such a big package. is that no longer true?
<seb128> directhex: it has a --enable-system option to use the system ffmpeg rather
<siretart> directhex: 'unstripped' means 'no debian/strip.sh' has been applied to the source
<siretart> directhex: I should probably have called it 'uncrippled'
<directhex> seb128, oh, neato
<seb128> siretart: ffplay goes to 100%cpu usage and load the box heavily but doesn't crash
<seb128> siretart: tried on http://launchpadlibrarian.net/23766462/Romeo_-_Basement_Jaxx.flv
<seb128> siretart: you need to go at the end of the video to get the bug
<seb128> siretart: btw valgrind ffplay on this video
<seb128> ==10124== Conditional jump or move depends on uninitialised value(s)
<seb128> ==10124==    at 0x4293BF5: ff_print_debug_info (in /usr/lib/i686/cmov/libavcodec.so.52.11.0)
<seb128> and seeking doesn't work correctly
<seb128> ffplay clearly doesn't work correctly on those either bug doesn't crash
<siretart> I wasn't abe to verify that with ffplay from the 0.5 release (and a crippled avcodec)
<siretart> the video just played fine
<seb128> siretart: ok, I will try again when you will have get your ffe and uploaded 0.5 to jaunty ;-)
<pitti> thekorn: I pushed the staging flag thing to storeblob, btw
<siretart> seb128: actually I wonder if a FFE is actually necessary, since gst-ffmpeg didn't need one either but already introduced the newer ffmpeg
<siretart> but better safe than sorry
<seb128> siretart: gstreamer0.10-ffmpeg is a very different case ;-)
<seb128> siretart: it's in universe (where I'm authorized to grand desktop exceptions) and nothing depends on it
<thekorn> pitti, super
<siretart> oh, rihgt
<seb128_> re
<seb128_> siretart: sorry I got disconnected
<seb128_> siretart: I granted myself the exception for gst-ffmpeg ;-)
<seb128_> since it was fixing some of those flood of crashers we get
<seb128_> and it's not a public lib or anything ... no reason to not update
<siretart> sure
<siretart> I wasn't really serious anyway
<seb128_> siretart: thanks again for the unstripped hint, I can confirm bug #330165 and bug #332860 now
<ubottu> Launchpad bug 330165 in gstreamer0.10-ffmpeg "video crashes due to vdpau decoders" [Medium,Fix committed] https://launchpad.net/bugs/330165
<ubottu> Launchpad bug 332860 in gstreamer0.10-ffmpeg "nautilus crashed with SIGSEGV in memset(), when clicking proprieties menu" [Medium,New] https://launchpad.net/bugs/332860
<seb128_> and that the svn gst-ffmpeg to disable vdpau fixes the issue
<seb128_> those 2 bugs were most of the crashers we are receiving
<siretart> cool!
<seb128_> so good to have that nailed down and fixed soon
<siretart> indeed!
<siretart> ah, that means there is no real need to disable vdpau in libavcodec-unstripped-52?
<seb128_> siretart: ups, I spoke too soon
<seb128_> hum no
<seb128_> let me try again to just be sure
<seb128_> siretart: right, http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/diff/?id=59796dd0bc0e4e985d5c31777648dd01d01c1184 is enough to fix the totem crashes
<seb128_> siretart: I will let you decide what you do with ffmpeg itself, that probably impacts on mplayer only
<siretart> mplayer uses its internal copy, so no worries there..
<siretart> (multiverse only anyway)
<seb128_> ok, what is using ffmpeg directly then?
<seb128_> vlc?
<cjwatson> soreau: wow, I'm amazed Wubi worked given your previous problems. Anyway, I wouldn't advise installing grub to the MBR because Wubi uses its own special version of grub (grub4dos) and you'll probably make your system unbootable if you try that
<siretart> vlc and xine
<siretart> bbl, lunch
<pitti> thekorn: hm, maybe you have an idea about this:
<pitti> thekorn: I now have a "file bug on staging" test case, which works wonderfully
<pitti> thekorn: but for the "download" case, I'm using Bug.attachments.download()
<pitti> thekorn: problem is that it tries to download e. g. http://launchpadlibrarian.net/23739263/Dependencies.txt
<pitti> thekorn: but it should really be "staging.launchpadlibrarian.net/..."
<pitti> thekorn: did you have this problem as well with the p-lp-bugs test suite?
<pitti> thekorn: (I do everything on staging)
<thekorn> pitti, you can tell py-lp-bug to use staging, for example:
<pitti> thekorn: I did that
<pitti> thekorn:             Bug.set_connection_mode(HTTPCONNECTION.MODE.STAGING)
<thekorn> hmm, ok
<pitti> thekorn: uploading/downloading the non-attachment data work, too
<thekorn> let me check
<pitti> thekorn: I'm sure you tested attachment storing/retrieval?
<pitti> thekorn: https://bugs.staging.launchpad.net/ubuntu/+source/coreutils/+bug/340835 is a bug filed by my testsuite
<ubottu> Ubuntu bug 340835 in patchutils "editdiff should not update the file when the patch is unchanged" [Wishlist,New]
<pitti> thekorn: and the Dependencies.txt attachment points to staging.launchpadlibrarian
<pitti> but somehow that gets mangled in p-lp-bugs
<thekorn> pitti, ok, just had a look at the code, this is not working for launchpadlibrarian.net
<pitti> thekorn: http://paste.ubuntu.com/130111/ is the stacktrace
<thekorn> let me try to fix it
<cjwatson> kees,jdstrand,mdeslaur: apache2-mpm-itk needs to be merged into hardy-updates rather than copied, apparently (cocoplum is sending me nagmail about it)
<pitti> thekorn: well, I can have a look, I don't want to steal your time
<pitti> thekorn: I was just curious whether you stumbled over this before
<thekorn> pitti, no, never seen this before, py-lp-bug's tests are not *that* complete ;)
<pitti> thekorn: ah, ok
<pitti> thekorn: I'll poke the p-lp-bugs code a bit then
<thekorn> pitti, I'm on it, it's only a two line fix
<pitti> oh, awesome
<thekorn> does edge.launchpadlibrarian.net exist?
<pitti> apparently not
<pitti> just staging. and production
<thekorn> pitti, I think this is it: http://paste.ubuntu.com/130112/
<pitti> thekorn: trying..
<pitti> thekorn: confirmed, works fine; thanks! will you commit this, or shall I?
<thekorn> pitti, please do, I#ve no working bzr here
<pitti> thekorn: erledigt; danke!
<thekorn> gerne
<mdeslaur> cjwatson: odd...a copy should be fine
<mdeslaur> jdstrand: could you figure it out?
<cjwatson> mdeslaur: copy-report can't tell that automatically
<cjwatson> mdeslaur: apparently the version in hardy-security does not have the changelog from the version in hardy-updates
<cjwatson> mdeslaur: which is what we use to tell whether it's safe to overwrite
<cjwatson> mdeslaur: it seems that both 3.2 in hardy-security and 3.1 in hardy-updates were just no-change rebuilds, so if you tell me it's safe to overwrite, I'll do so
<mdeslaur> cjwatson: oh, yeah, I see the problem
<mdeslaur> cjwatson: please overwrite
<cjwatson> mdeslaur: done
<mdeslaur> thanks cjwatson
<IntuitiveNipple> Who would be responsible for Rosetta management on Launchpad? I've had a bunch of emails confirming I'd uploaded gnome-screensaver translations - but I never did!
<beuno> IntuitiveNipple, danilo or jtv on #launchpad
<IntuitiveNipple> thanks :)
<juanje> pitti: Hi, I was checking some issues with apport and I see apport-collect uses python-launchpadlib but is just a suggested dep for the package. You show a mesage to install the package from the code, but I don't know why it is not a normal dependency. Is there any reason?
<pitti> juanje: I don't want launchpad installed by default for the current version, since it stil mainly uses python-launchpad-bugs
<pitti> juanje: however, I'll switch apport to use launchpadlib completely soon, then I'll change it to depends
<juanje> pitti: ok. but is very confusing to have a tool installed which is not able to run. Maybe the tool could be in other place (in the meanwhile) or deactived or something
<pitti> juanje: *shrug* it's not a final release yet :)
<juanje> pitti: ok, ok :-P
<juanje> just asking
 * liw wishes for a way to tell launchpad to not show bugs that haven't had any activity since last seen
<cjwatson> pitti: oh, can launchpadlib run anonymously / without being in launchpad-beta-testers now?
<pitti> cjwatson: not anonymously, you need to log in
<pitti> cjwatson: I haven't heard any complaints yet that it doens't work for someone
<pitti> it might very well be that it needs beta-testers, though
<seb128> pitti: what do you need beta testers for?
<pitti> seb128: using launchpadlib
<seb128> if I can help let me know
<pitti> seb128: you are in beta-testers as well, I suppose?
<seb128> pitti: is that a launchpad team? I'm using edge, is that the same one?
<pitti> right
<pitti> seb128: aah, I think I know why the dup-of-a-dup handling is broken
<seb128> pitti: oh?
<pitti> seb128: p-lp-bugs' .duplicate_of field is broken, it always returns None
<seb128> doh
<pitti> my test suite just uncovered that and I spent a while scratching my head where my implementation is broken
<pitti> but it isn't
<MacSlow> seb128, hey there
<seb128> MacSlow: hello
<MacSlow> seb128, can you deterministically reproduce the notify-osd crash with epiphany?
<seb128> MacSlow: yes, just download something
<MacSlow> seb128, I can't but think I've fixed the crasher
<seb128> did you try to download something?
<MacSlow> seb128, yeah but it didn't trigger any bubble or crash-report
<seb128> MacSlow: epiphany-browser http://download.gnome.org/sources/gvfs/1.1/gvfs-1.1.8.tar.gz
<seb128> save as
<seb128> enter
<seb128> -> crash after download
<seb128> attach gdb to notify-osd to make sure it doesn't crash?
<seb128> maybe it does but you don't have apport running
<MacSlow> seb128, hm... doesn't ask me "Save As" just downloads
<seb128> MacSlow: go to preferences
<MacSlow> seb128, waiting for the download to finsish atm
<seb128> and change the automatically open option
<seb128> though it might just do the same on autodownload I didn't try
<MacSlow> changed epiphany's setting now... trying again
<MacSlow> seb128, net-access is terribly slow here in capetown
<MacSlow> I'll look for some other / smaller file
<MacSlow> seb128, grabbed a 238 Bytes file ... nothing happens
<seb128> MacSlow: try
<seb128> http://download.gnome.org/sources/alacarte/0.11/alacarte-0.11.7.tar.gz
<MacSlow> seb128, are notifications from epiphany also something one can configure?
<seb128> not that I know
<seb128> MacSlow: anyway I can test your patch if you want
<MacSlow> seb128, nevermind just saw the crash here now too
<seb128> MacSlow:
<seb128> ==12873== Invalid read of size 1
<seb128> ==12873==    at 0x448BCA8: gdk_cairo_set_source_pixbuf (gdkcairo.c:210)
<seb128> ==12873==    by 0x8056B44: _render_icon_title_body (bubble.c:927)
<seb128> ==12873==    by 0x8058828: expose_handler (bubble.c:1545)
<seb128> MacSlow: says valgrind
<cjwatson> pitti: certainly it used to require launchpad-beta-testers, and I hadn't heard that that's changed yet
<pitti> cjwatson: well, I still won't need the actual launchpadlib for filing apport bugs fortunately
<pitti> cjwatson: but apport-collect certainly needs it
<seb128> MacSlow:
<seb128> (gdb) p *self
<seb128> Cannot access memory at address 0x0
<pitti> and the retracer (but I can have that added to beta-testers for sure)
<seb128> MacSlow: in _render_icon_title_body()
<seb128> MacSlow: and you try to access priv->icon_pixbuf
<cjwatson> pitti: ah, ok
<MacSlow> seb128, I know, I know :)
<seb128> MacSlow: ok good
<MacSlow> seb128, it's some error in the icon-loading code, which I started but was touched by someone else and not properly unit-test covered ... that's biting us now
<pitti> seb128: duplicate handling ... ok
<seb128> pitti == superstar ;-)
<pitti> seb128: so I'll roll out the p-lp-bugs fix into the main retracer, but updating the chroots is a little more work
<pitti> seb128: since I can't upload to jaunty yet
<seb128> pitti: that can wait after freeze
<MacSlow> seb128, the reason of failure there is the messed up handling of stock icon names from gtk
<pitti> seb128: the i386 one crashed anyway
<MacSlow> seb128, ehm... not GTK+'s fault but the icon-loading code's fault in notify-osd
<seb128> pitti: yeah I noticed and I'm being too lazy to ssh to the box, sudo, log into the retracer, add a file, run subscribe script, open the browser on the bug, untag, clean, restart
<pitti> seb128: ah, broken bug?
<pitti> seb128: if it's a broken bug, I'd fix apport-retrace to not crash, and invalidate it insted
<seb128> pitti: dunno, I just did that 15 this week and I've enough of doing it so I didn't look at this one
 * pitti hugs seb128
<pitti> seb128: keep it for me :)
 * seb128 hugs pitti
<seb128> pitti: can I get apport lpcookie or something that I can use locally?
<seb128> pitti: having to ssh and run a zillion command is so annoying
<pitti> seb128: sure, you can copy the .lpcookie.txt from ronne
<seb128> ok, I didn't want to do that without asking
<seb128> will do that
<seb128> thanks
<pitti> seb128: btw, apport collected almost as much Karma than I :)
<seb128> ;-)
<seb128> I got a zillion karma from translations recently apparently
<pitti> how so?
<seb128> all those rosetta imports
<pitti> do we get rewarded for swallowing so much import spam?
<seb128> I guess that's a pack: get spamed but also get karma
<seb128> yeah
<ebroder> Hey - can someone mark bug #288000 and bug #217792 as fix released in Jaunty but confirmed in Intrepid?
<ubottu> Launchpad bug 288000 in mit-scheme "mit-scheme dependent package libltdl3 is not available" [Medium,Fix released] https://launchpad.net/bugs/288000
<ubottu> Launchpad bug 217792 in mit-scheme "MIT-Scheme will not launch" [Medium,Fix released] https://launchpad.net/bugs/217792
<ebroder> Or can I do that? I can't figure out how, so I'm assuming that I needs bits I don't have
<seb128> pitti:
<seb128> SystemError: W:Failed to fetch http://ddebs.ubuntu.com/dists/jaunty/main/binary-i386/Packages.gz  Hash Sum mismatch
<seb128> pitti: removing lock now
<pitti> bwaah
<seb128> pitti: or you are working on it?
<pitti> seb128: I think in those cases the retracer should just stop, and remove the lock itself
<seb128> pitti: agreed
<pitti> seb128: no, I'm not working on ronne ATM
<seb128> ok because there is a screen running there so I was not sure
<seb128> lock removed
<mvo> doko: did you had a chance to review my patch for #341014 ?
<mvo> bug #341014
<ubottu> Launchpad bug 341014 in python-central "package with no "Python-Version" can be half-installed but not removed" [Undecided,New] https://launchpad.net/bugs/341014
<soreau> cjwatson: Ok, thanks for your time and assistance
<Mirv> does apt-get update suddenly segfault for someone else, or just me? tried to /var/lib/apt but it just reappears after having downloaded archive information, in Reading package lists...
<IntuitiveNipple> Mirv: There's a guy on #ubuntu+1 with the same issue I'm trying to debug right now. bug #341402
<ubottu> Launchpad bug 341402 in apt "apt-get: segmentation fault (jaunty)" [Undecided,New] https://launchpad.net/bugs/341402
<Mirv> IntuitiveNipple: ok, thanks
<seb128> soren: is virt-manager known to be broken in jaunty? it refuses to create an image for me, give an error for some spool directory in var
<soren> seb128: Possibly. I haven't used that part of it in a while.
<seb128> ok, no jaunty testing for me then
<seb128> or rather no new install testing on this box
<MacSlow> seb128, ok this time I think I nailed it
<seb128> MacSlow: excellent!
<MacSlow> seb128, notification after finished download form epiphany now shows the bubble and thus doesn't crash :)
<MacSlow> seb128, never let other people touch your code :)
<dholbach> you could have just told notify-osd to ignore epiphany-browser bubbles - they're pretty much useless anyway -most download just take a few seconds anyway :)
<MacSlow> seb128, I'll do a few more test before I commit/push and then mark the bug as "Fix committed" will that implicitly also set all duplicates to "Fix committed"?
<MacSlow> dholbach, hm... it was a legit bug to fix... I've to give dbarth a tiny spanking for what he did there :)
<seb128> MacSlow: he was joking ;-)
<dholbach> MacSlow: please no more details about your team dynamics :-)
<MacSlow> seb128, dholbach: It's all love in the end :)
<MacSlow> *sigh* everything about the hbd-office is great ... but net-access (speed) is *sighÂ²*
<seb128> soren: "RuntimeError: Couldn't create default storage pool '/var/lib/libvirt/images" ... what source should be bugged for that?
<soren> seb128: Just assign it to virt-manager, and I'll see if it's actually a libvirt thing.
<MacSlow> seb128, I'll do a few more test before I commit/push and then mark the bug as "Fix committed" will that implicitly also set all duplicates to "Fix committed"?
<MacSlow> seb128, I'm not sure if you answered that already ... network here is very flaky
<seb128> MacSlow: no, they are duplicate so not open, you just have one bug to update
<seb128> soren: ok thanks
<IntuitiveNipple> Mirv: What archive mirror were you using when you had the apt SIGSEV ? The user I'm helping has just discovered switching from the co. to vz. mirror solved the issue
<MacSlow> seb128, ok
<cjwatson> Mirv,IntuitiveNipple: I hope somebody's capturing a tarball of /var/lib/apt/ (and maybe /var/lib/dpkg/ too) before erasing the evidence
<IntuitiveNipple> Too late :)
<IntuitiveNipple> I did notice that the Archive-update file-names were showing up... and have just gone
<cjwatson> always record current state before starting to mess about
<cjwatson> first rule of debugging
<IntuitiveNipple> We didn't know that was the issue
<IntuitiveNipple> It wasn't debugging anyhow... it was 'fixing' :)
<Mirv> IntuitiveNipple: I was using main archive.ubuntu.com
<IntuitiveNipple> cjwatson: Is there any reason why netconsole wouldn't operate from the casper initrd? I'm testing via PXE netboot and have adjusted the tftp initrd.gz image's /conf/modules to include e100 and netconsole, and checked in busybox that the module has been loaded, but the "nc -u -l -p 6666" listener isn't seeing anything. Pretty sure the "netconsole=@/eth0,@10.254.251.51/" line is correct (used that before in other circumstances)
<cjwatson> IntuitiveNipple: I don't know, maybe it needs to be parsed in userspace and casper isn't doing that? I'm not familiar with netconsole
<IntuitiveNipple> okay... I'll dig some more. Thanks.
<IntuitiveNipple> Usually (for monitoring servers etc) it is just a case of adding network-device + netconsole modules (in that order) and adding the netconsole command-line
<soren> IntuitiveNipple: Are you specifying the netconsole parameter on the kernel command line to as an argument to insmod/modprobe/whatever?
<IntuitiveNipple> kernel command line
<IntuitiveNipple> would it need to be in the initrd as an option?
<soren> I'm not sure, to be honest.
<IntuitiveNipple> I've always done it with the kernel command line without an issue, so unless there's something special about the casper scripts (haven't noticed anything) I don't think it needs to be in an options file
<soren> IntuitiveNipple: Alright, that's probably not it, then :)
<soren> IntuitiveNipple: It was just a guess.
<IntuitiveNipple> Thanks :) every bit of lateral thinking helps
<IntuitiveNipple> I did "break=init" to try and debug it, and there's no /proc/ :( - time to go back to bed!
<seb128> is bbc in totem working for anybody?
<seb128> it doesn't manage to connect to the server here
<IntuitiveNipple> bbc news?
<seb128> no, the bbc option in the totem sidepane
<IntuitiveNipple> oh
<IntuitiveNipple> Doesn't appear to be answering correctly. Get's the initial ACK but then nothing
<seb128> ok
<seb128> so iz BBC bog
<cjwatson> yeah, appears to be
<cjwatson> I can mail them if you like
<seb128> no, that's ok, I don't think it's important for beta6
<seb128> I was just doing CD testing and make sure the code is still working
<seb128> I will try again later
<seb128> beta6 -> alpha6
<seb128> we can email them if that's not fixed for beta
<x2b> hello everyone, i am trying to work with the dbus a little. Could you please tell me which package I need to install to develop applications using libdbus in C?? I have already searched synaptic, but I could not find any
<EtienneG> mneptok, yo dude!
<EtienneG> jdstrand, I believe you wrote most of auth-client-config and ldap-auth-client, right?
<cjwatson> seb128: I had a mail of theirs to reply to anyway, so I've mentioned it
<jdstrand> EtienneG: I wrote auth-client-config, yes, ldap-auth-client was mostly dendrobates
<seb128> cjwatson: thanks
<EtienneG> jdstrand, ok ... I was just wondering if there was a good reason why the lac_ldap profile configure the shadow nss database for ldap
<EtienneG> jdstrand, is that something you have an opinion about?
<jdstrand> EtienneG: IIRC the profile provided was based on the existing documentation in the wiki
<jdstrand> https://help.ubuntu.com/community/LDAPClientAuthentication
<jdstrand> EtienneG: that said, the profile was removed in intrepid (and later) due to the addition of pam-auth-update
<mneptok> EtienneG: oy!
<EtienneG> jdstrand, ok, get that.  I guess it is not worth filing a bug about if it change past hardy
<EtienneG> mneptok, can you believe it?  MagicFab Chaos Field took over your ex-cubicle
<EtienneG> if we do not do anything shortly, it will take over the entire office!
<jdstrand> EtienneG: my understanding is the profile is mostly meant as an example-- AFAIK we don't have a 'canonical' ldap setup
<mneptok> EtienneG: if you said "it took longer than 2 shifts" i'd be surprised. ;)
<EtienneG> mneptok, indeed: it took a single shift
<EtienneG> jdstrand, ok, get that.  I will leave it there
<seb128> hum
<seb128> do we really need freepats on the CD?
<seb128> installed-size: 34megas
<pitti> seb128: we didn't have that in the past IIRC
<seb128> pitti: it's on alpha6
<seb128> /usr/share/midi = 34 megas
 * seb128 does some baobab to see where we could win space
<seb128> apt-get remove works fine, nothing depends on it
<seb128> it must be a recommends of something
<pitti> humm
<seb128> doh
<seb128> sorry
<pitti> seb128: apt-get install ubuntu-desktop here doesn't pull it in
<seb128> I did let totem install some codecs ...
<pitti> aah
<seb128> that was too good ;-)
<seb128> I'm wondering if the extra mouse cursors are very useful next
<seb128> 1 mega for each themes
<BUGabundo> gonna need some help finding exaile memory leak... anyone wants to help?
<seb128> pitti: is system-config-printer-applet translated for you?
<pitti> hm, I don't currently have a printer here
<seb128> pitti: system-config-printer-applet --no-tray-icon
<seb128> pitti: the menus
<seb128> the menus title rather
<pitti> seb128: no, it's not
<pitti> the menu entries are
<seb128> ok
 * seb128 opens a bug
<seb128> the strings are in the .mo
<seb128> seems to be a code bug
<seb128> pitti, tkamppeter: bug #341765
<ubottu> Launchpad bug 341765 in system-config-printer "the dialog menu titles translations are not used " [Undecided,New] https://launchpad.net/bugs/341765
<BUGabundo> seb128: do you think you can help me running valgrind against exaile?
<BUGabundo> its memory leaking... I think its Pulse related tough
<seb128> BUGabundo: sure, "valgrind python $(which exaile)"?
<BUGabundo> ahh missed python
<BUGabundo> lol
<BUGabundo> $ valgrindB python $(which exaile)
<BUGabundo>   File "/usr/bin/exaile", line 2
<BUGabundo>     cd /usr/share/exaile
<BUGabundo>     ^
<BUGabundo> IndentationError: unexpected indent
<seb128> exaile is a wrapper?
<seb128> call the actual .py
<BUGabundo> ok
 * BUGabundo looking for it
<BUGabundo> seb128: nothing happens... it just closes it self
<BUGabundo> $ valgrindB python /usr/lib/exaile/exaile.py
<seb128> BUGabundo: let me install exaile
<BUGabundo> running this alias
<BUGabundo> alias valgrindB='G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=/tmp/valgrind%p.log'
<BUGabundo> just in case I messed it up, last time I went looking for gedit / seahorse plugins mem leak
<BUGabundo> $ apt-cache policy exaile   Installed: 0.2.14-0ubuntu2
<BUGabundo> jaunty
<seb128> BUGabundo: valgrind python /usr/lib/exaile/exaile.py
<seb128> that works here
<seb128> do you have an instance running which it could decide to reuse?
<seb128> hum, no, in fact it exit
<seb128> BUGabundo: cd /usr/lib/exaile and run the command there
<calc> anyone know of a public dav server or one that doesn't require much to register for?
<seb128> calc: apt-get install apache?
<seb128> calc: or try installing gnome-user-share that should make an easy config
<calc> seb128: ah ok
<BUGabundo> seb128: will do
<BUGabundo> ==30872== More than 100 errors detected.  Subsequent errors
<BUGabundo> ==30872== will still be recorded, but in less detail than before.
 * calc is still sick but trying to work through it
<BUGabundo> seb128: running now
 * calc thinks he may end sick for weeks :\
<calc> er end up
<pitti> calc: ugh; trouble with stomach?
<calc> pitti: yea, one time i was sick with that for nearly a month and lost ~ 10kg
<siretart> pitti: slangasek: re FFE for ffmpeg: there is no ABI/SONAME change, the new packages should just work as is. I'll upload right after alpha-6 release, OK?
<pitti> calc: ouch
<pitti> siretart: sounds good
<pitti> siretart: no abi change> relieving :)
<pitti> siretart: with a soname of 52 it's not all that obvious that it didn't change :)
<calc> pitti: caught it this time from my son :\
<BUGabundo> seb128: I think my playlist may be the root cause... deleting and trying again
<siretart> pitti: well, its a bit more complicated, because ffmpeg distinguishes between external and internal ABI. but in the last years, they have been pretty conservative about breaking the (external) ABI
<directhex> siretart, do command-line args still change weekly?
<siretart> pitti: right now, I know only about 2 prominent users of ffmpeg that use internals: gst-ffmpeg (the main reason for the FFE) and mplayer (which doesn't link against the packaged version anyway)
<siretart> directhex: libavcodec is a library. for the ffmpeg binary, I'd need to check my git history
<directhex> i've got a packaging linking against libavcodec, so let me know if i should check it still works
<BUGabundo> seb128: http://paste.ubuntu.com/130216/
<BUGabundo> removing the m3u helped a lot
<tkamppeter> seb128, thanks, added a comment to inform the upstream developer.
<seb128> tkamppeter: thank you
<seb128> BUGabundo: nothing obvious in this log
<seb128> bbl
<calc> anyone having problems with 2.6.28-9.29 just stop working on on intel wifi 5300?
<calc> it stopped for me a few minutes ago so i rebooted and it stopped working again within ~ 1min or so
<BUGabundo> calc: not it that one
<BUGabundo> -8 gave me probs wit 4965
<BUGabundo> something with backports
<BUGabundo> apw can explain better
<mvo> pitti, tkamppeter: any objections/comments about http://launchpadlibrarian.net/23781636/cups-pdf_2.5.0-1ubuntu2.debdiff ?
<pitti> mvo: yes, I object to cups-pdf :)
<pitti> mvo: seriously, looks fine; a pre-dep sounds wrong indeed
<mvo> pitti: heh :) great, thanks
<pitti> mvo: but I guess it was done for a reason
<pitti> mvo: does the pdf printer queue auto-setup still work wiht that?
<mvo> pitti: the changelogs says the reason is that the lpadmin group is missing without it, but I will double check that
 * calc thinks ubuntu kernel might need better regression testing so things like intel wifi don't get broken right before beta
<IntuitiveNipple> who broked it?
<IntuitiveNipple> I've not noticed anything... so far :)
<calc> IntuitiveNipple: apparently -8 was broken for BUGabundo and -9 is broken for me now with intel 5300
<IntuitiveNipple> okay... not affected iwl3945 so far
<directhex> is there any diff between 5300 and 5100 other than signal quality?
<Keybuk> calc: ah, but we *are* the regression testers ;)
<calc> directhex: well technically mine is 5350 which is a bit different, the main difference between 5100 and 5300 is it uses 3 channels simultaneously (aiui?)
<Keybuk> that's kinda the point
<jdong> directhex: antenna configuration?
<jdong> 1x2 vs 3x3
<calc> directhex: iirc 5300 can do 450Mbps
<tkamppeter> mvo, for me it looks OK. When the pre-dep on CUPS was only for the lpadmin group, your explicit creation of the lpadmin group eliminates the need of the pre-dep.
<jdong> calc: yeah the 5100 is 300mbit RX, 150mbit TX like a lot of 1x2's
<calc> is it network manager at fault or the kernel when the device name in network manager is the width of the screen?
<directhex> i could run an upgrade on my laptop tonight
<calc> jdong: aiui no routers do 450/450 yet but may in a few months
<mvo> thanks tkamppeter, I will double check if my assumption that its just the group is correct
<directhex> calc, in nm-tool or nm-applet?
<calc> directhex: nm-applet
<directhex> calc, blame nm-applet for not making the device name sane?
<jdong> calc: I think that's just a modulation scheme setting; I've seen ath9k modetables go up that high
<jdong> (not that ath9k itself can do it)
<calc> directhex: ok, will file a bug against it, it is literally ~ 85-90% the width of my 1280 screen to show the name of the device, lol
<calc> and it shows three of them when i think there should only be one (mobile broadband)
<kagou> tkamppeter, how can I test if a cups backend is enabled (in use) ? (i'm searching for a bug in dnssd discovery printer)
<jdong> is anyone running intel video on jaunty? My GMA950 hardlocks whenever compiz tries to engage.
<directhex> calc, did this laptop of yours run intrepid at any point?
<directhex> argh, statements like jdong's make me change my mind about upgrading my laptop
<calc> directhex: no
<directhex> calc, damn. i'm wondering if anyone other than me had issues with 0 connectivity to N routers
<calc> directhex: i'm connecting to g and i still have 0 connectivity after a couple minutes
<calc> directhex: it seemed to have started since yesterday
<calc> directhex: i had to plug in my ethernet cable to be online now :\
<directhex> calc, just think about how much more bandwidth you have via ethernet!
<kagou> tkamppeter, by default there are no options for Protocol in cups conf files, so is mdnssd enabled ?
<calc> directhex: infinitely more! :)
<calc> directhex: http://launchpadlibrarian.net/23781977/Screenshot.png :-)
<directhex> calc, that's awesome
<calc> i'm pretty sure it should only display one of those cards and not the name at all
<calc> i'm glad i reenabled my broadband card in the bios this morning
<calc> that would have been ugly in a release
 * calc doesn't actually use the card at least not yet, just bought it with his laptop
<mbana> hi, who maintains the firefox package
<Kamping_Kaiser> mbana, ubuntu-mozillateam
<mbana> i've noticed that firebox ignores the settings i .fonts.conf
<kees> wow, I had a TON of errors this morning while booting.  is this all module-init-tools fallout?
<slangasek> module-alert-tools
<ion_> Probably stuff still calling modprobe -Q
<ion_> Which is somewhat ironic, -Q causing it to dump crap to the terminal.
<tkamppeter> kagou, see http://www.cups.org/documentation.php/doc-1.4/ref-cupsd-conf.html, the default protocols are both cups and dnssd.
<mbana> i wonder how it's possible to miss these fonts bugs
<mbana> they're such a big issue
<geofft> anyone familiar with tasksel? I wonder if bug #326501 will be magically fixed by rebuilding
<ubottu> Launchpad bug 326501 in tasksel "wrong description for ubuntustudio-desktop " [Undecided,Confirmed] https://launchpad.net/bugs/326501
<geofft> It looks like it ... does a bzr get at build time to grab the descriptions?
<kees> cjwatson: still around?  I'd like to move the "compiler mismatch between -updates and -security" issue forward.  what should next-steps be?
<mbana> how can i find out who builds firefox?
<Kamping_Kaiser> mbana, /j #ubuntu-mozillateam
<cjwatson> geofft: one moment, am on the phone
<cjwatson> kees: ^- ditto
<kees> cjwatson: np, I sent email.
<cjwatson> geofft: it won't be magically fixed by rebuilding, no, because the seeds still have that phrase. The reason for that is that it's apparently needed in ubuntustudio installations because too many people got confused otherwise. I think perhaps we need to have two separate Description fields, one of which is used on new installs if it's set
<geofft> ...Oh, oops, I was testing './ubuntu-seeds.pl foo hardy ubuntustudio' instead of intrepid
<geofft> I'm not sure "must install" should be there on new installs either. It shows up at the file server / print server / etc. screen
<geofft> and is kind of weird, if you're installing a server off debian-installer
<cjwatson> geofft: only for netboot installs
<cjwatson> geofft: server installs from CD won't have the key package for that task present, and so won't display it
<cjwatson> geofft: I'm thinking about new ubuntustudio installations here
<cjwatson> but yes, it is wrong as it stands; I'm just trying to figure out how to fix it in a way that does not break the original requirement
<geofft> okay, thanks.
<Keybuk> note-to-self
<Keybuk> replacing the running X server driver DOES NOT WORK
<Keybuk> ... how do upgrades work then?
<kees> slangasek: you'd mentioned something a while back about PAM and posix file capabilities.  what's the state of that?
<slangasek> kees: not file capabilities per se, but inheritable capas and stuff.  somewhere in the depths of the bzr repo, you can find a patch to pam_limits that supports a syntax for twiddling capabilities
<slangasek> it was discarded because it hadn't worked right for years on Linux. :)
<kees> slangasek: heh, okay
<jdstrand> kees: I was thinking I would do an apparmor upload for two easy quick-fix bugs. are you planning an upload anytime soon?
<kees> jdstrand: I don't have anything scheduled.  Let me make sure my repo is committed, one sec
<kees> jdstrand: okay, yeah, i'm good.  go for it!  :)
<jdstrand> \m/ *rock* \m/
<slangasek> mathiaz: what do you think of another round of server ISO testing right now?  There's a fix for installing over a pre-existing LVM that might be useful to have
<mathiaz> slangasek: np
<mathiaz> slangasek: soren said he can now run *all* the tests in less than 20 mn
<slangasek> mathiaz: ok - posted, please test
<soren> mathiaz: Out of curiosity: How long does it take for you?
<mathiaz> soren: 3 hours
<mathiaz> soren: to run all the installs
<soren> mathiaz: Yikes!
<asac> hmm ... anyone has any idea why my nfs mount could have stopped working after todays reboot?
<asac> it tells me "access denied by server" ... i didnt change the server and i didnt change my IP on client
<pedro_> slangasek: it's ok to assign bug 280712 to you?
<ubottu> Launchpad bug 280712 in samba "Accessing printing properties for some drivers causes excessive load on CPU" [Medium,New] https://launchpad.net/bugs/280712
<Keybuk> bryce_: the question being why is it taking 5s to get to clients
<Keybuk> when the Moblin one takes only a second
<slangasek> pedro_: I'm not sure it would do any good to assign that one to me at this point; if someone from the server team can help with it, that would be better
<pedro_> slangasek: alright, i'll ping them then, thanks you
<pitti> slangasek: are we out of freeze already?
 * pitti just noticed an apparmor upload
<slangasek> pitti: let's wait for results on the extra round of server testing before unfreezing
<pitti> right, that's what I thought
<slangasek> oh, well, that's just because people don't actually seem to heed the freeze guidelines :-P
<slangasek> I think the current state is still better than when we did hard freezes for milestones, but it's trending in the wrong direction
<jdstrand> slangasek, pitti: meh, that was me. sorry
<pitti> jdstrand: don't worry, if a6 fails, it'll just be your fault alone :-)
<slangasek> jdstrand: this one was, though I'm speaking much more generally
<jdstrand> pitti: /hi5
<ebroder> If I'm trying to get an SRU, do I subscribe ubuntu-universe-sponsors at the same time that I subscribe motu-sru? The process looks like you upload to -proposed before motu-sru approves it?
<slangasek> pitti: kirkland beat him to invalidating all the jigdo templates, actually. :)
<pitti> heh
<pitti> good night everyone
<slangasek> 'night
<asomething> ebroder: AFAIK motu-sru needs to approve before it gets uploaded to -proposed
<jdong> ebroder: SRU is filed first, then ACK from motu-sru for upload, then you (or sponsor) uploads, then ubuntu-archive reviews/approves it in the queue.
<jdong> technically I think that means one should subscribe a sponsor *after* a motu-sru ACK
<slangasek> evand: have you seen bug #339898?
<ubottu> Launchpad bug 339898 in migration-assistant "jaunty: Migration-Assistant always comes on when os is present" [Undecided,New] https://launchpad.net/bugs/339898
<mrooney> isn't m-a super unmaintained? I thought it doesn't work for firefox and still calls pidgin "gaim"
<mrooney> well, doesn't work for firefox 3
<ebroder> Thanks. jdong, want to take a look at bug #341832?
<ubottu> Launchpad bug 341832 in mit-scheme "SRU: mit-scheme uninstallable on Intrpepid" [Undecided,New] https://launchpad.net/bugs/341832
<slangasek> mathiaz, soren: how go the server tests?
<soren> slangasek: I've been dinnering.
<soren> slangasek: I'm refreshing my mirrorr. I'll run them afterwards.
<slangasek> ok, thanks
<slangasek> this is the last thing on the list before we push alpha-6 out
<soren> slangasek: I'll make sure to tell debmirror to hurry up.
<soren> :p
<slangasek> :-)
<jdong> ebroder: I commented; waiting to solicit some more opinions :)
<unit3> Can someone point me at the right channel to ask about prevu?
<ebroder> jdong: Awesome, thanks again
<jdong> sure thing.
<jdong> unit3: --> #ubuntu-motu
<unit3> great, thx.
<mathiaz> slangasek: still running the installs
<mathiaz> slangasek: the results for amd64 should be posted soon
<slangasek> mathiaz: ok, cool
<soren> Kicking off my tests.... Now.
<soren> Oh, I can queue the i386 ones as well.
<mathiaz> soren: i386 that would be helpfull
<soren> I'm on it.
<soren> mathiaz: How does your scripts determine the architecture?
<soren> mathiaz: Ah, it just notices the differently named iso and everything works out?
 * soren tries
<soren> Yup, seems to be the case.
<asac> calc: does/did your modem work at all with NM?
<asac> calc: or is it just that you see dupe entries now?
<soren> mathiaz: Oh, err... Heh :) You usually keep the generated disk images around, right? Or do you just see that the install finishes and feel happy with that?
<calc> asac: never actually used it, its a built in broadband device, iirc in the past it only showed up once, not three separate bits
<calc> asac: i had it disabled for a while in the bios (ThinkPad X200)
<asac> calc: ok makes sense. the f3507g is one of the few things not yet supported oob
<asac> calc: ok. pleaes provide the info in the bug anyway ;)
<asac> calc: and set to in progress ;)
<calc> asac: ok will do
<asac> thx
<calc> asac: i see in the bug report i may not have been clear about the too long name bit, the name as shown in the screenshot was what i was complaining about, it takes up almost the entire width of the screen
<asac> calc: ok. can you file a new bug for that? its an indepenent issue and we should track that separately
<mathiaz> soren: oh no. I reboot every machine, log into it and run the test
<mathiaz> soren: http://testcases.qa.ubuntu.com/Install/ServerWhole
<calc> asac: ok
<asac> calc: i mean split the bug in "three devices" and "long name in notification"
<calc> i'll attach the lsubs log to this one and leave it as three devices?
<calc> er lsusb
<asac> calc: both are kind of release critical ... the latter is dxteam stuff
<calc> asac: anything needed for the too long name bug?
<asac> calc: attach the screenshot and refer to it to explain how long the title is ;)
<calc> ok
<mathiaz> soren: running the tests and reporting is the part that is still manual
<calc> asac: what package does the name too long belong to? still network-manager-applet?
<asac> calc: name too long is applet; the other bug is actually nm
<calc> oh ok
<asac> calc: maybe the too long thing should be dealt with by notify-osd. but for now its applet
<calc> wouldn't it have to be in applet since if you look at the applet it shows up too long in there?
<asac> calc: yes. thats the argument for the applet.
<calc> i don't actually use the device (yet) so i don't see the notifications for it
<calc> ok
<asac> calc: still i wonder if notify-osd should support some ellipses for overlong titles
<calc> ah yea
<asac> calc: ah. ok. so it might not be a problem in the notification. i think i misunderstood the bug then ;)
<asac> but well. now we have it
<asac> calc: if i didnt ask for syslog for the "three devices" bug, please attach that too
<asac> thanks
<slangasek> mathiaz: awesomesauce
<calc> asac: syslog attached now and the new bug is bug 341940
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/341940/+text)
<soren> mathiaz: Ah. Then I need to fix up my scripts.
<asac> calc: thanks
<mathiaz> soren: how many nodes do you use in your environment?
<soren> two
<soren> four cores each
<mathiaz> slangasek: i386 results posted: all good!
<soren> mathiaz: Well, seeing as my current run blows away the results after a succesful install, the results not of much use. All the installs went fine, though.
<soren> I'm heading to bed.
<slangasek> ok, thanks. :)
<slangasek> night, soren!
<soren> 'night, folks. Happy ISO testing.
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | alpha-6 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
<nxvl> seb128: ping
<nxvl> seb128: i'm getting this error in evolution:Error while Refreshing folder. \n cannot rollback - no transaction is active
<nxvl> seb128: did you have any idea of what can be?
<seb128> nxvl: no, what version?
<nxvl> seb128: jaunty
<nxvl> seb128: 2.25.96 i nthink
<nxvl> 2.25.92
<nxvl> seb128: i think is a database issue, but i already removed my .evolution and it still have the same issue, is there any other database i shold remove?
<seb128> nxvl: no, all the indexes a in .evolution
<nxvl> mm
<nxvl> k, will check, thank you!
<seb128> the error is mentioned on http://bugzilla.gnome.org/show_bug.cgi?id=554925
<ubottu> Gnome bug 554925 in Mailer "Error while storing IMAP folder: cannot commit - no transaction is active" [Normal,Unconfirmed]
<seb128> seems to be a very unfrequent error and due to sqlite
<xoox> Anyone know of if there are any Google Chrome (chromium) packages built somewhere?
<calc> cool alpha 6 released now i can upload the new cool OOo without gvfs/gio support :)
<nhandler> xoox: It looks like fta has a chromium-browser package in his ppa
<xoox> nhandler: Thanks.
<fta> xoox, my ppa or the dailies: https://edge.launchpad.net/~chromium-daily/+archive/ppa
<xoox> Thanks for building these fta
<fta> you're welcome
<wgrant> calc: *without* GVFS support?
 * slangasek blinks
<wgrant> slangasek: Was this blink spontaneous, or triggered by some external stimulus that we should know about?
<slangasek> wgrant: the preceding conversation
<slangasek> calc: are you seriously talking about uploading an OOo to jaunty that drops major functionality, this far after feature freeze?
<calc> slangasek: yes, going to using gvfs fuse
<calc> slangasek: gvfs support is currently completely broken afaict
<calc> slangasek: attempting to turn on gio support in the build causes it to not even start up at all
<calc> there are still a few bugs in gvfs fuse that cause webdav and ftp save support not to work, but i worked with upstream to get the smb/sftp save working in gvfs fuse
<calc> and have already filed the bugs about the ftp/webdav problems
<calc> OOo has long had problems when saving to network shares, that i think are mostly related to issues in either its gvfs support or gvfs itself, but don't know for certain, some of the bugs in gvfs bugzilla seem to indicate they are gvfs issues
<slangasek> so what's the syntax going to be to use the fuse stuff?
<slangasek> blah, yeah, I can confirm that gvfs saving doesn't work currently
<calc> slangasek: just click on the fuse mount on the left side in file dialog, i wrote a patch to the OOo gnome file dialog to use the fuse path
<slangasek> I don't see a 'fuse mount' in the left side of my file dialogs
<calc> slangasek: i tried determining why gvfs didn't work in OOo but ended up not having enough time to determine the cause and fix it properly so got the gvfs fuse bits working instead
<slangasek> oh, maybe I have permissions on this share set wrong. OOo can certainly open files over smb.
<calc> slangasek: do you have any gvfs mounts?
#ubuntu-devel 2009-03-13
<calc> slangasek: you normally see them on your desktop also if so
<slangasek> ah - yes, but it wasn't clear to me that this uses fuse
<calc> those use gio/gvfs
<calc> but you can grab the fuse path out of the GFile object as well and have it use fuse instead
<calc> since they weren't working properly using the native gio/gvfs i wrote a patch to pull out the fuse path
<calc> not too much trouble if you know what you are doing but took me a while since i had never done anything with gio/gvfs before, heh
 * calc wishes debian would update to current bzr on bzr.d.o
<slangasek> is bzr.d.o even running a smartserver?
<slangasek> last I checked, I don't think it was
<james_w> it is over ssh
<calc> it constantly complains to me that it needs to be upgraded but that has to be done on the server side :\
<calc> and debian doesn't have current bzr packaged in unstable last i checked
<james_w> it does now
<calc> james_w: ah ok
<james_w> but alioth runs stable
<calc> james_w: oh
<james_w> it will be upgraded to lenny at some point presumably
<calc> so bzr on bzr.d.o is currently 0.11?
<slangasek> 1.5
<Nafallo> stable = lenny no? :-)
<nhandler> Correct Nafallo
<StevenK> james_w: alioth is probably still running oldstable
<slangasek> yes, it is
<Nafallo> so it didn't use "stable" in sources.list then ;-)
 * Nafallo have heard horror stories about that one :-P
<calc> slangasek: ah so it is running 1.5 so repos could be upgraded i guess?
<slangasek> they could be upgraded to the 1.5 level, at least :)
<calc> too bad the error messages don't tell you the minimum bzr revision needed to make the messages go away
<directhex> hm. can anyone determine why a package was rejected from NEW, if no explanation seems to have been sent? in theory it was done on tuesday, which means Riddell was on archive duty
<Riddell> directhex: there was a mono package that had two versions, I think I rejected the older one and accepted the newer one
<directhex> Riddell, there were two debugger plugins for monodevelop - one for mdb (mono debugger, for mono apps) and one for gdb (um... gdb is gdb)
<directhex> Riddell, the mdb plugin was accepted, the gdb plugin was rejected
<comradekingu> I updated the roadmap-wiki with a link to the alpha 6 site. Hope it will trigger a few downloads.
<Riddell> directhex: ok I think I messed up due to soyuz's annoying name trunkating bug
<Riddell> directhex: I've accepted it now
<directhex> Riddell, oh, you can do that without a re-upload? thanks!
<jdong> :(
<Riddell> I hope I can, let me know if it doesn't appear
<jdong> alpha-6 still has the hardlock-on-login bug
<directhex> Riddell, mildly amusing circumstances, but thanks ;)
<ScottK> directhex: One can acept from rejected.
<ScottK> accept even.
<jdong> bryce_: Are there any known bugs with GMA950 hardware hardlocking X when compiz tries to start?
<jdong> I am reproducing this with Jaunty AMD64, on login it simply hangs where I'd expect compiz to be started
<bryce_> jdong, don't know offhand, try looking in launchpad
<directhex> ScottK, handy!
<jdong> bryce_: heh I tried looking through and couldn't tell if I had a dupe of an existing Jaunty intel problem or a new one...
<jdong> hmm I think bug 259385 sounds right
<ubottu> Launchpad bug 259385 in compiz "[i845] Intrepid Compiz hangs on login for i830MG, i845, (and i945GM?) video cards" [Medium,Fix released] https://launchpad.net/bugs/259385
<jdong> wrong release though :-/
<bryce_> jdong, if you're asking is it worthwhile to file a bug report about the issue, almost certainly yes
<jdong> bryce_: alright, I'll do so then
 * ScottK tosses fta a reminder about mozilla-devscripts and python2.4....
<bryce_> jdong, see the troubleshooting page off of http://wiki.ubuntu.com/X/ as well
<bryce_> the reporting page is good to review too, else your bug may just get lost in the noise
<jdong> bryce_: will do; it seems upstream; I've been able to reproduce this on Fedora 10 too...
<bryce_> jdong, if you also file it upstream, that would help a lot.  I'm way behind on -intel and probably won't catch up on newly filed stuff any time soon.
<jdong> ok
<ScottK> If apt-get -f install (after installing a local .deb via dpkg) wants to pull in more packages than apt-get install all the depends (python2.4 and python2.4-minimal), any suggestions on where to look for trouble?
<JanC> ScottK: they aren't recommends?
<ScottK> JanC: Nope.
<ScottK> After I let it install once I tried aptitude why python2.4 and it didn't know why.
<JanC> I guess sometimes "-f" tries to be too clever then  ;)
<ScottK> I think I'm going to guess environmental leakage from the base Intrepid system into the chroot.
<slangasek> ScottK: heh, so even trying to build python-4suite against python2.6 fails miserably here, consuming RAM and never doing anything - but that's not the problem reported upstream?
<ScottK> slangasek: I don't recall the exact problem.  The apt-get -f install problem I was whining about earlier is a different package.
 * ScottK has also been up for 18 hours after 3 hours of sleep, so don't expect great coherency.
<Mavericks> ever been up for 24 hours or more?
<ScottK> Certainly.
<ajmitch> last time I did that was probably before/after a UDS, I think
 * ScottK too.
<calc> if i just want fuse paths passed to my application (OOo) should i change the .desktop file to %F instead of %U ?
 * ScottK has done 96 hours on 3 hours of sleep too, but doesn't recommend it.
<calc> for the exec line
<calc> Mavericks: at around 36hr i am not good for anything
<calc> Mavericks: my wife was awake for around 500hr
<calc> Mavericks: hint... being awake 500hr is NOT good
<Mavericks> ScottK: excellent. although you can definitely beat those 3 hrs to go 99 - real fun ;)
<ScottK> I was also in the military and we were expending ordnance (for training) at the time, so it was a mix of extreme fatigue and high explosives.
<Mavericks> calc: *Time for high school questions* fill in the blank - 500 hr is putting _____ at jeopardy.
<calc> Mavericks: when even high level insomnia drugs don't work you can't do much about it :-\
<Mavericks> ScottK: oof
<calc> Mavericks: they _attempted_ to a sleep study but she failed... due to lack of sleep
<Mavericks> calc: Nice - haha - Stay away from ______. Ta daaaa.
<ajmitch> calc: for a minute I thought you must had made a typo & meant 50 hours, but 500? ouch
<calc> ajmitch: yea roughly 3 weeks without sleep
<ScottK> I give.   She wins.
<calc> ajmitch: even with the drugs they put her on she could only sleep maybe 1hr before popping back up
<calc> i'm not sure what actually ended up fixing the issue, or if it just resolved itself
<ScottK> Longest I've gone straight was ~50 hours.  Slept once I realized the people giving me advice on the programming project were hallucinations.
<calc> so no one knows about %F vs %U in desktop files?
 * calc thinks he will leave it at %U since it seems to work, though %F is probably more correct
 * ScottK votes for working over correctness.
<calc> it works both ways but with %U it seems that burn:// urls are passed to OOo still
<calc> i don't know if switching it to %F will cause any problems though
 * ScottK also favors leaving well enough alone.
<calc> uploading new OOo now with gnome-vfs disabled and set to use gvfs fuse :)
<shaya> anyone have an idea on how to go about debugging X, in that it freezes regularly in jaunty on an r300 card (T42p laptop w/ firegl card)
<dholbach> good morning
<cooloney> dholbach, good morning
<dholbach> hiya cooloney
<pitti> Good morning
<Mavericks> good morning
<imachine> hello
<imachine> I have some issues with evolution in jaunty.
<imachine> it says I can't get imap since there's no provider available.
<imachine> is that normal jaunty behaviour and I should just wait for a fix, or something is off with my local system?
<imachine> (had some nastiness during updates/upgrades, so it might be that some packages weren't completely installed)
<pitti> james_w: did you thoroughly test bzr 1.13 already?
<sbeattie> pitti: have you thought about privilege escalation for apport? I'd like to do a package hook for apparmor, but one of the things I'd like to collect requires root privs.
<pitti> sbeattie: right, for some cases we need hooks which run when the program crashes, not when you report it
<sbeattie> pitti: hrm, that, too. But I'm thinking more along the lines of including the output of apparmor_status, which requires root equivalent access.
<pitti> sbeattie: right, if you do "ubuntu-bug" as user, you can't have that
<pitti> sbeattie: if you ask people to "sudo ubuntu-bug", it'll work
<seb128> pitti: ls -l `locate coreutils.mo`
<seb128> pitti: do you know what is to blame for that?
<seb128> doko: ^ or you
<pitti> seb128: the symlinks you mean?
<seb128> pitti: the broken ones yes
<pitti> seb128: they are shipped in coreutils
<pitti> indeed, they should point to locale-langpack/
<pitti> they look pretty weird in the first place, though
<pitti> thekorn: FYI, I uploaded a new p-lp-bugs with another fix for parsing duplicates
<pitti> thekorn: and yesterday night I hacked a lot on the launchpadlib branch (just to avoid duplicate work by you)
<cody-somerville> mvo, ping
<mvo> pong
 * asac still wonders which package could have broken his nfs mount :(
<thekorn> pitti, yes, I've seen your bug mails, thanks for the upload
<pitti> no problem
<tseliot> asac: is it something that you mount manually? If yes, go to System/Administration/Authorisation and check that you have the authorisation (for policykit) to mount
<asac> tseliot: no its a /etc/fstab setup mount
<tseliot> asac: ah, ok
<asac> it worked for a decade ... now its gone. and i cannot read email anymore :(
<tseliot> :-/
<asac> hmm ... saw strange modprobe issues during this boot
<asac> output looked similar to what you get when you run modprobe without any module (e.g. --help)
<asac> tseliot: but a good idea. any idea where i setup such a manual mount ;)
 * asac found Network
<asac> thats not it ...
<tseliot> asac: sorry but I've never used nfs therefore I have no idea
<pitti> seb128: if the gdm transition code is available, what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/gdm-upgrade ?
<seb128> pitti: updating that was on my todo I just tested the transition code to make sure it worked before going to bed this night and I wanted to update the blueprint today, let me do that now
<pitti> seb128: ah, no hurry; I'm just updating the ReleaseStatus page (release meeting today)
<pitti> seb128: yay
<seb128> pitti: changed to implemented
<seb128> pitti: should I upload gdm-new to universe now? or is that late in the cycle?
<pitti> seb128: fine for me
<seb128> ok, let's do that
<seb128> few people find the ppa and it has other cracks too now
<pitti> tseliot: what's left for https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-options-editor ?
<tseliot> pitti: just a UI cleanup, which won't take place in Jaunty
<pitti> Riddell: can you please update the status of the kubuntu jaunty specs?
<pitti> tseliot: can you please update the status of the spec, and separate the remaining UI bits, e. g. into bug reports? Or do you think it's incomplete enough so that we have to pull it?
<tseliot> pitti: I think it's usable, it just doesn't have the best looking UI ever created. I'll update the status of the spec and file a bug report.
<Riddell> ok
<pitti> tseliot: thanks; please then refer to the bug report and set it to implemented, if all the functionality in the spec is covered now
<pitti> Riddell: thanks
<tseliot> pitti: ok
<tseliot> pitti: done
<pitti> tseliot: cheers
<tseliot> pitti: :-)
<Laney> doko: Is it intentional that python-support always makes public modules available for the current version, regardless of what pycompat says?
<pitti> thekorn: adding/removing tags on staging doesn't seem to work for me with p-lp-bugs; did you happen to notice that as well?
<pitti> thekorn: I tried for half an hour to find the bug in my test suite, but it really just gets swallowed, it seems
<pitti> thekorn: trying with launchpadlib now
<thekorn> pitti, no, can have a look at it in a bit
<thekorn> does it work on edge
<pitti> thekorn: no, just asking
<pitti> thekorn: haven't checked edge yet, let me try
<pitti> >>> b = Bug(89040)
<pitti> >>> b.tags
<pitti> ['apport']
<pitti> >>> b.tags.append('testsuite')
<pitti> >>> b.commit()
<pitti> thekorn: shouldn't that work?
<pitti> thekorn: ^ edge now
<thekorn> pitti, yes, this should work this way
<pitti> thekorn: hang on, perhaps for adding it stumbles over that silly new dialog box which asks you about "new tag OMG!" for every new pacakge
<pitti> but removing tags should work..
<pitti> hm, doesn't work on edge either
<pitti> seb128: ^ I think this is serious enough that we have to stop the retracers; otherwise they'll just retrace the same thing over and over
 * pitti checks the logs
<thekorn> pitti, removing works for me on edge
<seb128> pitti: ack
<directhex> hm. according to my figures, jaunty is 44 meg smaller than intrepid
<directhex> excluding a kernel
<pitti> thekorn, seb128: hm, it seems to work on ronne
<pitti> WTH?
<thekorn> pitti, adding too,
<pitti> thekorn: ok, thanks for checking; must be something on my end then
<thekorn> if you would like to add a 'new' tag, you can use    b.commit(force_changes=True)
<pitti> oh, should I always use that?
<pitti> thekorn: anyway, I now have the test suite succeed in the launchpadlib branch, so I'm going to switch over soon anyway
<pitti> just figuring out why the last set of tests I wrote fails
<thekorn> yuhu
<panesar_sandeep> what should be prerequisites in terms of prog languages that one should hv to start ubuntu developing??
<Keybuk> panesar_sandeep: it depends on the software you want to work on
<maxb> That's not really a meaningful question - Ubuntu is a combination of so many pieces of software. You need to know the languages used in the bits you intend to work on.
<Keybuk> much of the core of Linux is written in C
<panesar_sandeep> ok but still, i am intrested in debugging, but am not able to workout gdb well
<Keybuk> various add-on pieces use Perl or Python, and Bourne Shell is a must
<Keybuk> Desktop environments might use something like C# (GNOME pieces) or C++ (KDE)
<bigon> cjwatson: any news about the cleanup of the buildd chroots?
<panesar_sandeep> where can i get help/docs about using gdb or debugging in ubuntu...
<cjwatson> bigon: no
<Keybuk> panesar_sandeep: gdb includes its own manual
<Keybuk> panesar_sandeep: install gdb-doc and run "info gdb"
<directhex> panesar_sandeep, this isn't really the channel for learnign to program with ubuntu, as stated in /topic
<panesar_sandeep> keybuk, thnx :)
<panesar_sandeep> keybuk, sory too
<panesar_sandeep> :)
<directhex> or use monodevelop-debugger-gdb! \o/
<directhex> gotta test that
<james_w> pitti: I run bzr.dev, as do many people. There have been a few issues arise during testing this week, with fixes being cherry-picked to the release branch.
<directhex> james_w, we have monodevelop-debugger-gdb now, tested & working
<james_w> I saw, thanks
<directhex> hm, that was meant to be in #ubuntu-motu
<james_w> well, I didn't see it was tested and working, so even better :-)
<directhex> james_w, by "tested and working" i mean "setting breakpoints in a 10-line hello world app works"
<directhex> ditto for hello.cs with monodevelop-debugger-mdb
<Keybuk> directhex: there's still no way to import an existing project though?
<james_w> If you are skilled enough to write more than 10 lines of C you shouldn't need a debugger anyway
<directhex> Keybuk, no. but it's already buckets sexier than monodevelop 1.0 was
<directhex> Keybuk, that might even be a gsoc suggestion - autofoo import wizard
<Keybuk> directhex: it's a complete mystery to me how to even start a new autofoo C project in monodevelop
<PecisDarbs> hi people, tracker won't be installed by default in Jaunty anymore?
<directhex> Keybuk, i can't see how to do it fully. makefile stuff is under project options, but i get an error when i enable it & click ok. might be a bug. i'll ask upstream
<MacSlow> pitti, did you already touch the new notify-osd release?
<seb128> MacSlow: did you see my comment on #dx?
<seb128> MacSlow: where I was asked if we should look at updating notify-osd in jaunty
<MacSlow> seb128, sure I've done a 0.9.3 release which includes the fixes for the kerneloops-applet issue and the "epiphany-download" crasher
<seb128> MacSlow, pitti: ok, I'm looking at the update
<MacSlow> seb128, btw https://edge.launchpad.net/notify-osd/trunk/0.9.3
<seb128> thanks
<MacSlow> seb128, where do I indicate on LP that other packages are affected by changes to notify-osd?
<soren> MacSlow: "Also affects distribution"
<soren> MacSlow: And then find the package from there.
<seb128> MacSlow: open bugs on those or add task by click the "also affect" below the table
<pitti> seb128: re from lunch; shall I do the update, or are you on it?
<seb128> pitti: notify-osd? I'm on it
<pitti> seb128: okay; have release team meeting now
<seb128> pitti: feel free to tackle some other sponsoring request if you want, I cleaned some yesterday but there is still a few pending ones and 2.26 is due next week
<pitti> seb128: check if the packaging branch already has 0.9.3 first; if so, please merge from that, instead of just updating the ubuntu branch yourself
<pitti> seb128: right; bit crammed today
<seb128> pitti: no hurry don't worry, will do for the notify-osd update
<ogra> cjwatson, Keybuk ... do we already have a bug for the 1970 prob and useradd ?
<Keybuk> ogra: I didn't file one
<Keybuk> I'd suggest the bug is actually in useradd not adduser
<cjwatson> ogra said useradd ...
<Keybuk> so he did
<ogra> thats why i said so :)
<Keybuk> sorry, dunno how I read that wrong ;)
<cjwatson> (and I agree)
 * ogra has to run out for 1h
<mathiaz> ttx: it may be better to just upload/merge samba 3.3.2
<Aquina> I don't wanna be a nag but why is gFTP still unavailable with compiled SSL? It's no prob for me to do it but the n00bs out there probably can't. You think I should file that on launchpad? Yes, no, maybe? :-)
<beuno> Aquina, yes
<ttx> mathiaz: looking...
<mathiaz> ttx: there are a couple of major bug fixes included in 3.3.2
<ttx> mathiaz: yes... but it's a bigger change, then
<mathiaz> ttx: right - however most of the change seem to be bug fixes only.
<mathiaz> ttx: may at we should include the patches for the main issues?
<RainCT> Keybuk: hey
<mathiaz> ttx: may *be*
<RainCT> Keybuk: about bug #339612, which console? there's usplash so I don't see anything *g*
<ubottu> Launchpad bug 339612 in upstart "[jaunty] poweroff doesn't work, but halt does" [Low,Incomplete] https://launchpad.net/bugs/339612
<ttx> mathiaz: probably makes more sense to move to 3.3.2. I won't have time to pull it off before the end of the day though.
<mathiaz> ttx: sure.
<ttx> mathiaz: I guess we need an Ffe for that move as well.
<mathiaz> ttx: why?
<mathiaz> ttx: it seems that this is a bug fix only release
<ttx> mathiaz: hm, yes, indeed.
<cjwatson> mvo: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/ looks sort of out of date. Does it do any testing with more recent releases?
<cjwatson> mvo: (and should we add something to NewReleaseCycleProcess to remind you to update it?)
<soren> Would anyone mind if I added "karmic" to the list of acceptable distributions in vim's debchangelog syntax file now? It's always bugged me that it doesn't work when we get started on a new release.
 * soren glances at cjwatson
<pitti> soren: if we do it, it should be done in debchange and lintian as well IMHO
<soren> pitti: Indeed.
<pitti> and for the record, I wouldn't mind
<calc> anyone know of a reliable way to add a pre-depends package or a pre-depends line with package to a control file if the line doesn't exist?
<calc> i have a way to add it without checking but that isn't very good
<calc> eg: sed -i '/^Architecture:/a Pre-Depends: dpkg (>= 1.14.12ubuntu3)' debian/control
<pitti> calc: you mean with seddery?
<calc> pitti: yea or something similarly automated
<pitti> calc: I was using the same
<hyperair> \j #vartakblogs
<calc> pitti: i dropped my pre-depends for lzma because i needed another pre-depends on a package but need it still since soyuz still does the check
<hyperair> shit
<cjwatson> soren: fine by me
<soren> cjwatson: Cool.
<calc> pitti: so now for one of my packages in OOo there is already a pre-depends line so the second pre-depends line causes an error
<pitti> calc: you could run above once, and then vi over it, searching for /\nPre-Depends:.*\nPre-Depends/ ?
<Riddell> pitti: I just committed a small but important fix to jockey, will that be uploaded sometime before beta?
<calc> pitti: automated or do you mean to manually fix it up?
<pitti> Riddell: yes, I need to fix some things anyway
<calc> pitti: manual would probably work since i have a bug open on soyuz already
<pitti> calc: manually; I guess there won't be that many pre-depends duplications?
<calc> pitti: yea just one
<calc> pitti: hmm couldn't i do something like the above to merge the two lines in sed?
<pitti> calc: well, it's not that reliable, since it's not guaranteed that existing Pre-Depends: fields are always directly below Architecture:
<pitti> calc: there's certainly some seddery to do that, with using its buffer
<pitti> but my sed fu isn't that great, I'm afraid
<calc> ok
<soren> pitti: Thanks for reminding me of debchange. I wouldn't have thought of that one. I've uploaded all three (vim, devscripts, and lintian) now.
<pitti> soren: yay koalas!
<soren> Go go gadget dput!
<seb128> Keybuk: did you open bugs about those "don't do fading effect on login" changes btw?
<Keybuk> seb128: not yet, perfecting the patches
<seb128> Keybuk: ok, would be nice to get before beta if you can get those ready for next week
<Keybuk> RainCT: boot without "splash" >
<Keybuk> seb128: yeah, definitely will :p
<seb128> cool
<RainCT> Keybuk: heh ok..
<pitti> mvo: aaah! mystery in bug 315571 solved
<ubottu> Launchpad bug 315571 in python-apt "[jaunty] causes random Launchpad timeouts with python-apport" [High,New] https://launchpad.net/bugs/315571
<cjwatson> ScottK,doko: bug 342335 is the ICE blocking KDE on powerpc
<ubottu> Launchpad bug 342335 in gcc-4.3 "ICE compiling qt4-x11 on powerpc" [Undecided,New] https://launchpad.net/bugs/342335
<doko> cjwatson: I'll have a look tomorrow. does lowering optimizations help? using gcc-snapshot?
<cjwatson> haven't yet tried gcc-snapshot, I'll ask for that to be installed on davis
 * calc did the crappy edit a generated file way to fix the problem
<cjwatson> doko: -O2 -> -O1 does make it go away, so I'll try to bisect optimisations
<cjwatson> doko: from the source it appears to be something to do with PLT generation in PIC mode
<doko> cjwatson: works with 4.4
<cjwatson> -foptimize-sibling-calls appears to be relevant
<cjwatson> I'll lower optimisation for now
<mvo> pitti: yeah, it should be fixed
<wwoods> lazynet, I have a question: are ubuntu binaries built using BuildIDs? (e.g. if you do readelf -n /bin/sleep is there a build ID note)?
<ion_> Doesnât apt-cache policy coreutils suffice?
<wwoods> ion: long story short: no.
<wwoods> gdb (in RHEL/Fedora at least) uses the build IDs to get debugging symbols from files with unique filenames
<ion_> launchpad resolves the debugging symbols, it seems to work well.
<wwoods> retracing the debugging symbols server-side requires sending core dumps to a third party
<wwoods> that does not fly for me, or Fedora, or RHEL
<wwoods> so back to my simple yes-or-no question: can someone run readelf -n /bin/sleep and thus tell me if there's BUILD_ID notes in the binaries?
<calc> wwoods: no, is that a specific Fedora patch?
<calc> wwoods: you may want to propose a discussion for UDS about doing retracing the fedora way...
<calc> wwoods: assuming the features needed are available it probably wouldn't be too hard to implement if people can come to a consensus this a better way
<wwoods> calc: AFAIK it's in upstream ld but I might be wrong - still doing research, and I figured I could answer "does Ubuntu already use --build-id"? quickly
<calc> wwoods: it appears jaunty does not have build id in sleep
<calc> readelf -n /bin/sleep
<calc> Notes at offset 0x00000254 with length 0x00000020: Owner		Data size	Description GNU		0x00000010	NT_GNU_ABI_TAG (ABI version tag)
<calc> that is all that it returned for me
<wwoods> does ld --help mention build-id at all?
<slangasek> yes
<slangasek> I don't follow how that has anything to do with server-side retracing, though
<wwoods> I'm trying to eliminate server-side retracing
<wwoods> retrace on the client-side by downloading only the required debuginfo data over the internet
<pitti> yeah, it's pretty irrelevant for server-side retracing, since the problem isn't the debug symbols but the core dump
<wwoods> if you have unique build IDs it's trivial to determine exactly which individual files are necessary to retrace a core
<pitti> wwoods: that's actually one of apport's long-term wishlist bugs
<calc> wwoods: yea ld has build-id support
<pitti> wwoods: but since debugsyms are so terribly huge, there's not a lot of interest in it
<slangasek> wwoods: it's already trivial because you already know what libraries are loaded, what packages they come from, and what versions those packages are at
<wwoods> sooo if you have, say, a webdav share with all the debugging data for every binary
<slangasek> so you just install the corresponding -dbgsym packages
<wwoods> slangasek: installing the entire package is insanely wasteful
<wwoods> typically 95% of the installed data goes unused
<wwoods> not to mention the overhead of doing all the metadata parsing
<wwoods> package database updates
<wwoods> etc
<wwoods> so instead you have a webdav share with all the debugging data on it - they all have unique filenames, so you can have debugging data for multiple versions of the same package
<wwoods> the client mounts that share at /usr/lib/debug/.build-id, gdb only pulls the files it needs
<wwoods> voila - full retraces, client-side, without installing anything
<pitti> wwoods: that sounds like a fine idea
<pitti> wwoods: is the build ID any more fine-grained than the package version?
<wwoods> pitti: each individual binary gets its own UUID
<wwoods> so each bin in coreutils has its own build-id
<pitti> how does that help, though?
<pitti> since in a package build, all binaries get built at the same time anyway?
<wwoods> well, you need to be able to discern which file corresponds to /bin/sleep and which one is /bin/ls
<wwoods> I've got a working (albeit experimental) implementation of this in Fedora
<pitti> wwoods: right, I figured that would end up as something like /debugsyms/coreutils/1.2.3-4/bin/ls
<wwoods> it's one of the big roadblocks that keeps us from attempting to use Apport
<pitti> wwoods: are the build IDs a checksum, or a really uniqye number?
<wwoods> really unique
<pitti> wwoods: with a checksum I see the benefit of sharing identical files, but with UUIDs we could just as well use the package version?
<pitti> or is it just to avoid figugring out all the package versions?
<wwoods> AFAICT, anyway.
<wwoods> mostly it's such that gdb doesn't need to try to read the rpm database to figure out what version a package is
<wwoods> to figure out where to look for its debuginfo
<wwoods> anywya computer is freaking out, I will be back in a little bit
<wwoods> but you might ask google to give you the fedora wiki pages on buildid
<pitti> wwoods: anyway, I could see this getting abstracted in apport/packaging.py, such as a function that maps an ELF in the system to an URL for its debugging symbols
<wwoods> and debuginfofs
<pitti> wwoods: right, intersting idea; thanks!
<LaserJock> doko: so is this site-packages -> dist-packages change in python the same in Debian?
<Keybuk> bryce_: right
<bryce_> Keybuk: what?
<Keybuk> why does it take 5 seconds to get to the userspace for Ubuntu
<Keybuk> but only 1s in Moblin
<Keybuk> that's kinda the question really
<Keybuk> something about their X server makes it start a hell of a lot faster than ours :-/
<bryce_> Keybuk: did you see my email where I discussed this?
<bryce_> Keybuk: it looks to me like hal is delaying things
<Keybuk> it isn't
<Keybuk> I can put a sleep 10 there, and X still takes that long to start
<bryce_> Keybuk: well there's nothing in the X log between like 2.7 sec and the 5.8 sec mark.  I don't think X is doing anything during that period.
<bryce_> Keybuk: _I don't know_ what's going on during that period, but I don't think it's X doing anything particular
<Keybuk> 2.7s is still twice as long as Moblin ;)
<ion_> I donât know if thatâs relevant, but it seems X changes the screen mode to something, then switches back to the virtual console for a second, then changes the screen mode again and keeps doing that a couple of times, and then finally shows a cursor and gets to GDM.
<ion_> ...greeter
<slytherin> Keybuk: have some time? need help debugging "inaccessible DVD" problem again. Totem/VLC/Mplayer both complain and I have libdvdcss installed.
<Keybuk> ion_: it doesn't do that here
<Keybuk> slytherin: doesn't sound like I'm the right person
<Keybuk> unless you're getting Permission Denied
<slytherin> Keybuk: yes, totem says "you may not have permission to view". I thought this might have something to do with udev.
<Keybuk> most likely HAL
<Keybuk> udev doesn't assign permissions a user is expected to have
<slytherin> Keybuk: hmm. About a month ago we discussed similar issue, the device for DVD drive is /dev/hdc.
<slytherin> and at that time we concluded that the group for the device was set wrong by udev
<slytherin> or hal as you say
<Keybuk> slytherin: what does ls -l /dev/hdc say?
<slytherin> Keybuk: brw-rw----+ 1 root cdrom 22, 0 2009-03-13 22:29 /dev/hdc
<Keybuk> looks right to me
<Keybuk> slytherin: getfacl /dev/hdc
<Keybuk> bryce_:  could it be simply that gdm starts the X server, and is waiting too long before starting clients in it?
<wwoods> pitti: back - so, our gdb has some support for build-id - if it sees a build-id note in a binary, it assumes that the debuginfo can be found at e.g. /usr/lib/debug/.build-id/XX/XXX...X.debug
<wwoods> so gdb already automatically maps ELF->path
<slytherin> Keybuk: http://paste.ubuntu.com/130712/
<pitti> wwoods: ah, sweet
<wwoods> mount the debuginfo files at that path and you're done
<bryce_> Keybuk: is it the 0-2.7sec part you're asking about, or the 2.7-5.0 post-X stuff?
<wwoods> I think it uses just random UUIDs because, generally, the linker doesn't know the unique package ID that it's building
<pitti> wwoods: so I assume you can tell gdb to use a different basedir, such as ~/.gvfs/webdav-debugsyms/ or so
<Keybuk> bryce_: why it takes that long
<wwoods> pitti: exactly
<bryce_> Keybuk: which one?
<Keybuk> slytherin: the "onkar" user has access to that cdrom drive
<pitti> wwoods: that sounds like a nice way to speed up the version matching indeed
<Keybuk> bryce_: the problem I'm trying to solve is that our X takes longer than Moblin's X to start
<wwoods> although in the initial implementation I'm using the systemwide dir, so it works for all users
<Keybuk> nothing more than that
<bryce_> Keybuk: arghhh
<wwoods> esp. since debuginfo data isn't private or unique per-user
<Keybuk> bryce_: I'm not being clear?
<wwoods> we also cache the data very aggressively, so e.g. libgcc's debuginfo only gets pulled down the first time you attempt a trace
<bryce_> Keybuk: far from it!
<slytherin> Keybuk: yes, still it gives me this problem. I am not able to understand why.
<Keybuk> slytherin: then it's not a bug in udev or HAL but in whatever else you're using
<Keybuk> bryce_: ok
<bryce_> Keybuk: is your question, "Why does xorg take 2.7 sec to start up" or "what is happening after the 2.7 mark that is delaying xsession to start until after 5 sec?"
<Keybuk> bryce_: *both*
<wwoods> (plus fedora/red hat debuginfo is packaged with symlinks for those unique filenames)
<Keybuk> bryce_: the Moblin X server completes init at fwict 1.76s and the first client runs by 1.901s
<wwoods> pitti: so, anyway, I'd suggest that step 1 toward doing retracing client-side would be to turn on --build-id for new builds.. someday
<Keybuk> bryce_: our X server completes init at 2.74s and the first client doesn't run until 5.8s!
<Keybuk> on identical hardware
<Keybuk> both of these things are problems
<pitti> wwoods: right; however, with the myriad of ddebs existing already I guess we'd have a fallback to version-based paths at least for some time
<slytherin> Keybuk: gxine is playing the DVD. So I am wondering if it has anything to do with the libdvdread transition.
<bryce_> Keybuk: yes but I think they're _separate_ problems
<Keybuk> slytherin: no idea
<Keybuk> bryce_: sure, I'm happy to believe that ;)
<slytherin> I will check any similar bugs in Debian
<bryce_> but so far when I've talked about one, you've brought up the other, and vice versa, which is making me pull my hair out talking with you :-)
<Keybuk> bryce_: (#1) X server startup takes too long and (#2) X clients take too long to start
<Keybuk> bryce_: ok :p
<bryce_> Keybuk: for #2, what I've said is that it appears from the boot chart that HAL is doing a LOT of activity during that period, so I suspect it
<Keybuk> bryce_: it's not related to HAL
<bryce_> Keybuk: you've said that
<bryce_> Keybuk: you've not explained why it's not
<wwoods> pitti: yeah, you'd need a fallback somewhere. does your gdb have build-id magic? (try: gdb, "show build-id")
<Keybuk> bryce_: because almost all the activity you're seeing HAL do is *caused* by the various bits starting up
<pitti> wwoods: "undefined command"
<Keybuk> mostly gnome-power-manager
<Keybuk> and because
<Keybuk> if I start gdm by hand after the boot has long since finished
<Keybuk> then it still takes just as long
<wwoods> pitti: alas, that's a no
<wwoods> I'll have to ask if/when that's going upstream
<bryce_> ok
<Keybuk> bryce_: for example, http://people.ubuntu.com/~scott/mini9_jaunty-20090218-7.png
<Keybuk> bryce_: Xorg starts at 12.5s, "finishes" at 16s
<Keybuk> but all the HAL stuff is well done by 11.5s
<Keybuk> (I think the post-init delay might be gdm/ConsoleKit related
<Keybuk> since both times I see a gdm burst of I/O right after the X init finishes
<Keybuk> so I can rule that one out for now
<Keybuk> so it's just the #1 issue - 2.7s init vs. 1.7s init for allegedly identical code that interests me
<bryce_> ok, the #1 issue I can deal with more easily, since it's all outlined in the X log
<Keybuk> sorry for being overly confusing, but X is a big mystery to me still ;)
<bryce_> I guess the #2 issue is really 2.7->3.5sec but we lack log info so it's sort of a mystery at this point
<ion_> Is our X server slower than the rest, or is Moblinâs faster than the rest?
<wwoods> pitti: hrm. it's in the docs on sourceware.org, and I see patches sent upstream in Sep. 2007; I have to assume it's in upstream gdb
<pitti> wwoods: might need a configure option which we just didn't turn on
<wwoods> pitti: either way, if you have a way to map from a unique ELF file to a unique path name, then this method should work
<pitti> wwoods: either way, if there's a patch, that part should be easy
<bryce_> Keybuk: well fwiw, I notice just at the very tip start of the log file that already it's faster by 2x
<bryce_> [    0.017635] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 12 14:15:49 2009
<bryce_> vs
<bryce_> [0 sec: 005113 usec](==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 12 15:22:41 2009
<wwoods> I'm trying to make it as simple as possible to port the debuginfofs stuff for other distros
<wwoods> so we can all share.. and so apport can stop sending cores upstream. heh.
<bryce_> and actually in this case the Moblin case has printed out more lines of text into the log file, but X hasn't really even begun to do anything
<bryce_> Keybuk: have you ruled out other things like caching or compiler optimization or other system effects?
<Keybuk> bryce_: what kind of caching?
<Keybuk> the one thing I haven't tried is building our X packages with -march set to i686+sse2
<Keybuk> (their binary doesn't even work for some ddx-related reason)
<calc> uh translate-toolkit appears broken on the buildds
<calc> who needs to be made aware of this issue, IS?
<calc> or is it already being worked on?
<calc> __main__.PyCentralError: package has no field Python-Version
<calc> hmm
<calc> mvo: ping
<calc> mvo: looks like you were the one that broke it? :)
<mvo> calc: eh
<mvo> calc:  could you give me the buildlog please?
<mvo> calc: I fixed a bunch of stuff, I would not call that "broke it" ;)
<calc> mvo: heh :)
<calc> mvo: log is here http://launchpadlibrarian.net/23831853/buildlog_ubuntu-jaunty-amd64.openoffice.org_1%3A3.0.1-5ubuntu2_FAILEDTOBUILD.txt.gz
<calc> mvo: if i am reading that correctly now with new python-central translate-toolkit needs updating?
<mvo> calc: sounds like it, I can have a look. lots of package need updates
<calc> mvo: ok :)
<calc> mvo: i don't know what to do wrt fixing it so if you can fix it that would be great :)
 * calc hugs mvo
<pitti> jdstrand: would you have a minute to review gnome-themes-ubuntu in source NEW?
 * ogra sighs deeply about missing ctrl-alt-bkspc ... having a live image where gdm is constantly crashing and only one console makes that really needed
<jdstrand> pitti: sure
<ogra> bryce_, we really really hould consider keeping ctrl-alt-bkspc unitl RC during development releases, it has bitten me really often now that i was screwed through it missing on live images i worked on
<fader> ogra: +1
<ogra> i totally agree its not needed in releases ... but during development its a helpful safety net
<calc> ogra: its not needed in releases only in the all bugs are fixed case... (which in reality is never)
<calc> and sysrq-k doesnt work nearly as well
<calc> since it messes up the framebuffer, maybe KMS will fix that bit though
<ogra> well, its not *that* necessary in releases ... and you can easily install dontzap in the released version
<LaserJock> or doesn't work at all
<calc> ogra: you don't know you need it until its too late, generally
<calc> i guess once you get bitten once you then turn it on for recurrent cases
<ogra> but if i try to debug an X issue on a liveimage where my ttys die and i have to call all initscripts manually (which takes 30min or so) from single user mode ... and then ralize i have to start over because i cant kill X thats kind of wasting my dev time
<mvo> doko: is "Python-Version: current" something that python-central should support? the change I did to make invalid python-versions fail (in my recent upload) seems to now reject checkbox. do you have any hints for me?
<ogra> i didnt really need it yet on my work machine ...
<ogra> but i need it during work on images
<calc> ogra: i had to use it a few times already in the past month or so
<calc> ogra: i don't remember why anymore but i remember turning it back on after wishing it was still enabled
<ogra> i used it when i tested out UXA vs EXA here, and it was very handy ...
<ogra> but beyond that i dont need zapping for normal operation
<LaserJock> ogra: it'd make sense to turn it on during devel but I think it'd be good to have a wiki page or something that describes a devel -> stable delta so we know what things are bugs/regressions and which aren't
<ogra> right
<LaserJock> like if we want to bump up U-M checking frequency during devel
 * ogra wont comment on u-m anymore :P
<ogra> getting on lwn with my comment was really enough ... i'll keep away from that topic
 * ogra doesnt like being quoted as a CoC violation
<LaserJock> I can imagine
<calc> ogra: heh :)
<mvo> calc: almost done (I hope). the update to 2.6 requires quite a bit of manual labor for earch source
<mvo> calc: how can I test that?
<mvo> other than that it installs
<maswan> is there a mirror available that has intrepid-proposed included into intrepid? (trying to netinst test with the netinst images from -proposed isn't working all that great when trying to download modules from normal intrepid)
<cjwatson> maswan: have you tried booting with apt-setup/proposed=true?
<cjwatson> that's available for this purpose
<maswan> cjwatson: ah, right. sorry, that might have been too sane for me. :)
<cjwatson> might not, er, be documented anywhere
<mvo> calc: uploaded, good luck
<calc> mvo: if it installs then it probably works i guess, many programs use it for building
<calc> mvo: all i really know about it is it is needed for OOo
 * mvo wonders if there is a bzr tree for pycentral to figure out certain changes
<cjwatson> maswan: oh, https://wiki.ubuntu.com/Testing/EnableProposed
<cjwatson> I'll put it on Installer/FAQ too
<maswan> cjwatson: oh, look, there it is. I didn't see it for all the repo instructions, or something. :)
<tormod> Keybuk: how is the desktop user added to the /dev/dri/card0 ACL?
<Keybuk> tormod: is there one?
<tormod> I think so. Otherwise how do users (who should not be in "video" group) access it?
<tormod> I am not a video member, but the ACL has user:tormod:rw-
<Keybuk> ah
<Keybuk> it's done by HAL
<tormod> when I log in?
<Keybuk> yes
<tormod> is that a dbus request from gdm or something?
<Keybuk> gdm creates you a new ConsoleKit session
<Keybuk> ConsoleKit informs PolicyKit of the new session
<Keybuk> since HAL uses PolicyKit to apply ACLs, and generally has  "current session" authorisation
<Keybuk> it is alerted that the ACLs needed to change
<tormod> thanks, lots of new stuff to learn I see
<Keybuk> it's made of lots of awesome
<Keybuk> since if you logout, your acls go away ;)
<Keybuk> CK/PK do much, much more of course
<tormod> in the end, we just need to fix users-admin to not show and create the "video" group then.
<tormod> s/create/add
<Keybuk> none of those groups are relevant anymore
<Keybuk> other than perhaps "admin" :p
<tormod> where is this stuff configured, now that it's not in /etc/group any longer?
<Keybuk> tormod: System -> Administration -> Authorizations
<tormod> thanks, I meant file-wise
<Keybuk> the defaults are in /etc/PolicyKit/PolicyKit.conf
<Keybuk> granted authorisations are in /var/lib/PolicyKit
<wwoods> there's also the polkit-auth tool for managing them
<mvo> calc: I fixed a issue in pycental as well, I hope things are more happy when that is all published
<calc> mvo: ok
<ogra> mvo, wow, thats really cute ... !
 * ogra hugs mvo for getting rid of the need for KVM for sandbox upgrade tests
 * Nafallo_ ponders if ext4 is stable enough yet.
<mvo> ogra: heh :) glad that you like it
<adelie42> Hello, I am a long time hobby programmer, but new to this collaborative environment. I just spent today fixing some bugs, but I think I "did it wrong". I used 'apt-get source' to get the package, but now it looks like I should have gotten the source via 'bzr branch'. I have been following http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html but still feel a bit lost. Any assistance?
#ubuntu-devel 2009-03-14
<calc> grr, it seems the archive is staying in an inconsistent state
<calc> translate-toolkit was broken earlier today now openjdk-6-jdk can't install
<brettalton> I'm looking to subscribe to changes to individual packages, such as rhythmbox, pidgin, human-icon-theme, etc. I'm wondering if that
<brettalton> 's possible? I don't want bug reports, but rather source updates
<brettalton> e.g. https://launchpad.net/ubuntu/+source/rhythmbox... but subscribe to the changes
<brettalton> sorry: https://launchpad.net/ubuntu/+source/rhythmbox
<Hobbsee> afternoon all
<Hobbsee> soren: please do.  that always annoys me too.
<nhandler> Hey Hobbsee
<Hobbsee> oh, you did.  thanks :)
 * Hobbsee waves to nhandler :)
<ebroder> Hmm...if I want to get the fix for bug 340993 backported to Hardy, should I wait until the SRU process for bug 339815 is completed, or should I try to change it now?
<ubottu> Launchpad bug 340993 in alpine "alpine's ./configure wants Build-Depends and Depends: aspell" [Undecided,Fix released] https://launchpad.net/bugs/340993
<ubottu> Launchpad bug 339815 in alpine "SRU: Alpine on Hardy fails to build with GSSAPI support" [Undecided,Fix committed] https://launchpad.net/bugs/339815
<ebroder> (I realize that these are both my bugs and I should have thought this through harder)
<ebroder> (Well, sort of my bugs)
<virtuelv> could someone with knowledge about gvfs please look at https://bugs.launchpad.net/bugs/330383
<ubottu> Ubuntu bug 330383 in gvfs "MTP is preferred over UMS/MSC" [Undecided,New]
<virtuelv> it's reducing functionality of lots of devices, and completely breaking it for people who have different preferences than Rhythmbox
<mdke> could someone who understands a bit more about package dependencies than me take a look at the last comment on bug 281277?
<ubottu> Launchpad bug 281277 in gnome-user-docs "[Intrepid] "Assistive Tool" string shows untranslated" [Undecided,Confirmed] https://launchpad.net/bugs/281277
<cjwatson> mdke: followed up to the bug
<mdke> cjwatson: many thanks - I'll try adding the -proposed repository and installing the package from there to be double sure
<cody-somerville> cjwatson, I thought that if a relationship field has a version number attached then only real packages will be considered to see whether the relationship is satisfied.
<cjwatson> cody-somerville: correct; however, in this case, the relationship field is unversioned
<ion_> keybuk: Judging from the screenshot at http://code.google.com/p/pybootchartgui/ pybootchartgui should display CPU and IO usage in the process bars. Here it doesnât seem to do that. Any ideas why?
<cody-somerville> cjwatson, ugh, sorry. I had misread the output. :)
<mdke> cjwatson: seems to work, the upgrade tool and apt-get upgrade don't want to remove rarian-compat or install scrollkeeper so I guess it must be a problem with gdebi only
<mdke> cjwatson: thanks for looking into it
<jsgotangco> scrollkeeper! now that's a package i haven't heard for quite a while :)
<mdke> :)
<mdke> hi there jsgotangco
<jsgotangco> hello mdke
<rlameiro> hello
<rlameiro> anyone can help me here wit init scripts?
<rlameiro> I made a script to run in rc6.d
<rlameiro> to mount a samba share with cifs
<rlameiro> made the update-rc.d
<rlameiro> and the links apear at the places I want
<rlameiro> but the share does not apear
<rlameiro> if I run the script after reb oot by hand it works
<rlameiro> sorry, not the best place...
<directhex> mount? on rc6?
<rlameiro> no
<rlameiro> rc5.d
<rlameiro> sorry
<rlameiro> I misspelled it
<rlameiro> that is for rebbot preparation
<rlameiro> lol
<directhex> 5? on debbuntu?
<rlameiro> I want the share to be mounted after the network is up
<rlameiro> If I put it in fstab
<rlameiro> it will wait for network
<rlameiro> then fails and goes on with bot
<rlameiro> 8boot
<rlameiro> and the share gets mounted
<rlameiro> but i wanted to be mounted without waiting 2 minutes and fails
<rlameiro> is for  my htpc mythbuntu
<rlameiro> any thoughts?
<rlameiro> I used the update-rc.d
<rlameiro> and  the sym links appear in place
<directhex> you're using network-manager, or just static /etc/network/interfaces?
<rlameiro> netmanager
<rlameiro> network-manager
<rlameiro> well
<directhex> your approach is wrong, then.
<rlameiro> I ssh now
<directhex> firstly, debina/ubuntu don't use rc5
<rlameiro> and the link dont appears
<rlameiro> ...
<directhex> secondly, you can't guarantee your interface will be up in ANY runlevel with network-manager
<rlameiro> man
<rlameiro> ok
<directhex> take a peek in /etc/network/if-up.d/
<rlameiro> rc4.d?
<directhex> especially /etc/network/if-up.d/mountnfs
<rlameiro> ok
<directhex> debian/ubuntu use runlevel 2 for multi-user system.
<rlameiro> thankyou
<rlameiro> I read the runlevels in debian structure
<rlameiro> and they talked about rc5
<directhex> but i told you, it won't help if you can't be certain that the network will be up
<rlameiro> ok
<rlameiro> i will ssh pico the /etc/network/if-up.d/mountnfs
<rlameiro> directhex: can I just drop there at the end of the script the mouont line?
<rlameiro> I dont know sh scripting...
<rlameiro> well
<rlameiro> going for reboot now
<rlameiro> see if it works
<rlameiro> well
<rlameiro> didnt worked
<rlameiro> well I am without ideas for this
<slytherin> what is significance of device /dev/sr0?
<rlameiro> cdrom? maybe?
<cjwatson> yes
<slytherin> rlameiro: what happens if the device node is not present? I am getting permission denied error in totem while trying to play DVD. Could it be related?
<rlameiro> ...
<rlameiro> do you have the css codec?
<slytherin> yes, I have libdvdcss installed. xine plays the dvd fine. But anything that uses libdvdread is causing problem. totem (gstreamer), mplayer, vlc etc
<cjwatson> permission denied is likely to be a device-level error not anything to do with codecs
<cjwatson> check whether you can actually read from the device
<slytherin> cjwatson: xine plays the dvd fine.
<slytherin> gxine I mean
<cjwatson> find out what device those applications are using; check dmesg and such to find out whether that actually corresponds to the device you're using; further questions on this to #ubuntu unless you discover a bug in which case file it ...
<slytherin> I had discussion with Keybuk yesterday but I could not reach any conclusion.
<slytherin> and I remembered a bug I had filed regarding wrong permission with IDE DVD/CDROM which was fixed by him. So I was wondering if this is similar bug.
<rlameiro> slytherin, I have a problem to mount a cifs share at startup
<rlameiro> I think that ubuntu could have some kind of start script/conf file to add shares to be mounted after the network manager is up
<rlameiro> do you now anything about that?
<rlameiro> or cjwatson,?
<slytherin> rlameiro: nope
<cjwatson> rlameiro: no, and please ask support questions in #ubuntu; I realise that it's noisier there, but consider what it would be like here if everyone asked for user help here rather than in #ubuntu :-)
<rlameiro> this is not help
<rlameiro> it is more a feature request
<rlameiro> like to make a simple script
<rlameiro> where to put it etc
<rlameiro> I could make a python script after that to help people to make this
<rlameiro> like that they will not have the same problems that i have
<cjwatson> feature requests => bugs.launchpad.net/ubuntu
<cjwatson> we can't effectively track them on IRC
<cjwatson> and the people who would be best to deal with any given feature request are not around on IRC 24/7, so putting it somewhere where they can see it asynchronously is actually better for you
<rlameiro> ok
<cjwatson> or answers.launchpad.net/ubuntu if you're asking a question ("is this possible?") rather than filing a bug ("please make this possible")
<rlameiro> ok
<rlameiro> thanks
<rlameiro> no prob
<rlameiro> I will try someanoe answer me in #ubuntu
<RainCT_> argh.. nvidia glx180 is conflicting with itself since the last update in jaunty (that is, the normal package conflicts with -dev)
<slytherin> RainCT_: is normal package and -dev at same version?
<RainCT_> slytherin: yes
<RainCT_> to clarify, it's not that there is a Conflicts, but that it tries to override a file and dpkg doesn't like that
<slytherin> oh, that is problem then.
 * RainCT_ should read more carefully.. actually, it's dpkg-divert not wanting to divert :S
<RainCT_> it says something like:  name change means overwriting "/usr/lib/libGL.so" with "/usr/lib/nvidia/libGL.so.xlibmesa", not allowed
<BUGabundo> apw: ogasawara ping
<BUGabundo> wifi device is not working after suspend to memory on jaunty latest kernel
<BUGabundo> known or file new bug?
<RainCT_> weird
<RainCT_> I've uninstalled the -dev package, installed it again and this time it worked
<RainCT> alright, nvidia and compiz are working fine again
<BUGabundo> bug 342804
<ubottu> Launchpad bug 342804 in linux "wifi (intel 4965) fails to work after suspend to ram" [Undecided,New] https://launchpad.net/bugs/342804
<BUGabundo> RainCT: really?
<BUGabundo> I have to reload my desktop everytime I reboot!
<RainCT> BUGabundo: reload?
<BUGabundo> RainCT:  $ compiz --reload or fusion icon reload
<RainCT> BUGabundo: Ah. Here the problem I have is that if I switch to metacity I can't get Compiz back without restarting X
<BUGabundo> hum
<BUGabundo> don't know
<BUGabundo> mine wsa not working last week
<BUGabundo> but now I can just boot to compiz no problmo
<BUGabundo> let me change to metacity and back to see if it works!
<BUGabundo> do you have a prefered way for me to do it?
<BUGabundo> or can I just use Fusion Icon
<BUGabundo> ?
<RainCT> BUGabundo: fusion icon is fine
<RainCT> (is fine == you can use it. it fails the same as runing from Alt+F2)
<BUGabundo> ok Compiz>metacity worked
<BUGabundo> gonna try vs
 * BUGabundo prepares a terminal timeout with compiz --replace
<BUGabundo> almost worked
<BUGabundo> WM bars gone! needed to reload too
<BUGabundo> but I'm on compiz again!
<BUGabundo> NVidia 8400
<calc> i got a very strange failure to upload message on powerpc for OOo
<calc> it says this:
<BUGabundo> RainCT:  nvidia-glx-180:  Installed: 180.37-0ubuntu1
<calc> http://paste.ubuntu.com/131108/
<DreadKnight> hello, can't manage to install flash 10 for 64 bit ubuntu
 * RainCT has got a GeForce 9600M GT
<BUGabundo> DreadKnight: go to #ubuntu-mozillateam and ask fta or asac there
<calc> who should i ping about an issue like that?
<DreadKnight> BUGabundo, thanks, will do
<pARAd0X> hi
<pARAd0X> I want to know the complete list of features set in the Jakalope
<pARAd0X> is there any link, google haven't helped me much
<pARAd0X> ?
<pARAd0X> :'(
<pARAd0X> ho ho !
<pARAd0X> toc toc toc ! Is there anybody here ?
<LaserJock> pARAd0X: what do you mean by "feature set"?
<LaserJock> you might look at the 9.04 blueprints on Launchpad but that doesn't specifically tell you what all will be included
<JanC> there are also the release notes for the alpha releases
<JanC> and several other sources
<JanC> the "complete feature set" would be more than 10000 pages long I suppose  :-)
<pARAd0X> I need only one source, about what will be the Jakalope, I mean, news about DeviceKit, iBUS, DBus, XServer 1.6 or 1.7 ...
<pARAd0X> like what we found in the fedora site
<cjwatson> http://wiki.ubuntu.com/JauntyJackalope/TechnicalOverview
<cjwatson> obviously it needs to be fleshed out further, but that is the place
<cjwatson> (until such time as the marketing people start putting together presentations and such for www.ubuntu.com anyway)
<hyperair> that page misses out on the intel driver performance regressions
<cjwatson> yes
<cjwatson> it's a wiki
<cjwatson> it suffers from the fact that only the release team have made serious additions to it so far this cycle, rather than people who are specifically focused on documentation
<hyperair> heh right
<hyperair> maybe i should add that
<jdong> stupid question; can someone link/explain what were the "outstanding issues" with encrypted home dirs?
<IntuitiveNipple> jdong: I did see a report about the key-file being in the encrypted volume - not sure if that is relevant :p
<jdong> ROFL
<IntuitiveNipple> I suspect bug #277578 and #317895 are blockers
<ubottu> Launchpad bug 277578 in ecryptfs-utils "ecryptfs does not work properly over nfs, cifs, or samba" [High,Triaged] https://launchpad.net/bugs/277578
<ubottu> Launchpad bug 317895 in ecryptfs-utils "netboot newuser and ecryptfs fails to login" [High,Triaged] https://launchpad.net/bugs/317895
<cjwatson> jdong: installer doesn't force encrypted swap when you're using it
<cjwatson> (and it's tricky to do so because the partitioner's already finished by the time we get round to asking that question, so it requires some more thought)
<jdong> ah, I see
<jdong> that make sense
<cjwatson> that's the specific reason that led the security team to ask us to disable it; there may be other problems of course
<jdong> yeah, that's entirely legitimate
<ScottK> cjwatson: Thanks for fixing up qt4-x11 on powerpc.
<picklesworth> Hm... you folks may like this patch more than upstream will, since Jaunty's notification stuff is less obtrusive: http://bugzilla.gnome.org/show_bug.cgi?id=567880
<ubottu> Gnome bug 567880 in general "Changing keyboard layout should trigger visual feedback" [Enhancement,Unconfirmed]
<picklesworth> personally, I think it's awesome... although I am a little biased :P
<sistpoty> mdz, cjwatson, Keybuk: mind moderating my mail to u-d-a? (btw.: still a mystery who can moderate posts there, last time I failed pitti wrote me that I should've informed him earlier, but he's not mentioned in "list-run by ..." details, maybe other moerators aren't eitther?)
<ebroder> Hmm...I'm testing a build of the pyrex package in my jaunty chroot, and it's FTBFSing because it's installing the module into /usr/local. Anyone seen this?
<ebroder> Is there any special Python configuration in the buildd chroots that I might be missing?
<ebroder> Hmm...actually, I think this might have been broken by one of the recent python-central uploads
 * sistpoty goes to bed... gn8
<maxb> ebroder: Sounds like the source hasn't been modified for the Python 2.6 transition
<maxb> It is now required to pass --install-layout=deb to python setup.py
<ebroder> maxb: The source shouldn't need to be modified - it keys on the output of pyversions
<ebroder> Oh, really? Huh. Ok
<wgrant> ebroder: distutils needs --install-layout=deb passed now.
<ebroder> I eventually tracked that down, and I have a patch - bug #342936 and bug #342937
<ubottu> Launchpad bug 342936 in pyrex "pyrex FTBFS under Jaunty" [Undecided,New] https://launchpad.net/bugs/342936
<ubottu> Launchpad bug 342937 in pyrex "Pyrex needs to be rebuilt for Python 2.6" [Undecided,New] https://launchpad.net/bugs/342937
<ebroder> Are there going to be any mechanisms to catch other packages like this before release?
<wgrant> ebroder: I've almost finished an archive rebuild, and am currently triaging the failures.
<wgrant> I have around 70 that appear to result from this same Python issue.
<ebroder> wgrant: Awesome. Do you need help? I'd be glad to look at a few of those
<wgrant> ebroder: I haven't got a list at the moment, but should tomorrow.
<cjwatson> savvas: bug 316579: it's not your decision to make. copyright subsists by default; copyright holders need to disclaim interest for it to be public domain.
<ubottu> Launchpad bug 316579 in soyuz "Soyuz needs to switch to obtaining Packages-arch-specific from non-obsolete source" [High,Triaged] https://launchpad.net/bugs/316579
<cjwatson> ScottK: glad it works now. Were there any give-backs to do further up the stack as a result of the breakage?
<slangasek> cjwatson: well, under US law there's nothing copyrightable in that file because there's no originality
<slangasek> but obviously there are other laws besides US law that may be relevant here, since only one of the named parties is even a US resident :)
<cjwatson> slangasek: I didn't want to venture an opinion on whether there was originality or not
<cjwatson> UK law is ... not as clear on the subject as it might be, I think. The CDPA has some language about "creative works" but there are some parts of it that seemed very unclear last time I looked
<ScottK> cjwatson: I kicked off some retries (re qt4-x11). I haven't had a chance to see how they worked out.
<stephenr82> hey guys, simple question. Im looking here: https://launchpad.net/ubuntu/jaunty/+source/linux/2.6.28-9.31. How am i to apply this diff patch?
<stephenr82> if i gunzip the orig and get the diff file and do patch < difffile it can't find the files
<mdke> hi there. I just did a debdiff for a simple change for yelp, and without me touching anything the list of uploaders has been changed: is that normal? http://launchpadlibrarian.net/23868503/342972.debdiff
<dtchen> stephenr82: you need to either provide the starting path explicitly and/or you need to use -p
<wgrant> mdke: Yes, unfortunately.
<wgrant> mdke: GNOME packages are magic.
<wgrant> In a bad way.
<mdke> wgrant: do I need to do anything about it, or can I submit the debdiff like that?
<wgrant> mdke: You could always remove it, but it's reasonable to submit like that IMO.
<mdke> ok :)
<stephenr82> hi dtchen, the -p doesnt seem to work. I have done -p 17 and its still giving me:         can't find file to patch at input line 3 .... |--- linux-2.6.28.orig/Makefile
<dtchen> stephenr82: let's step into #ubuntu, please
#ubuntu-devel 2009-03-15
<ebroder> I'd kind of like to try and get the fix for bug #340993 SRU'd into Hardy and Intrepid. Does this seem reasonable? (it's just an additional build-dep and dep)
<ubottu> Launchpad bug 340993 in alpine "alpine's ./configure wants Build-Depends and Depends: aspell" [Undecided,Fix released] https://launchpad.net/bugs/340993
<jdong> bryce_: looks like someone already filed my bug indeed (bug 329039)
<ubottu> Launchpad bug 329039 in linux "jaunty alpha 4 live cd hangs on macbook when starting gnome" [Undecided,New] https://launchpad.net/bugs/329039
<jdong> the symptoms are frustratingly nondescript :)
<maco> jdong: are you able to do that bootchart hack that shows what's happening during gnome startup?
<jdong> I haven't tried; that's not really a priority right now
<bryce_> jdong: that's a pretty poorly done bug report though; no logs provided, bisection, or other sort of analysis that a dev would need to look into it.
<jdong> bryce_: indeed; what kind(s) of logs would be useful? After a hard reset I don't really see anything worthwhile in /var/log...
<jdong> the closest to bisecting the problem is "it didn't happen in Intrepid"...
<kees> oh excellent, -Os still leaves fortify enabled.
<bryce_> jdong: you really need to familiarize yourself with https://wiki.ubuntu.com/X/ ;-)
<bryce_> lots of stuff there that'll help you analyze that bug better
<jdong> I'll see how close I can get by watching over SSH as it hangs
<jdong> bryce_: heh I can log in post-hang; from Xorg.0.log I see exaCopyDirty: Pending damage region empty!
<jdong> then a re-EDID probe
<jdong> is that EXA message suspicious or normal?
<bryce_> I think it's normal
<jdong> ok, other than that I just see another EDID probe; nothing out of the ordinary
<jdong> Mar 15 06:39:16 ubuntu kernel: [  413.257002] [drm:i915_getparam] *ERROR* Unknown parameter 6
<jdong> is that normal?
<bryce_> no
<jdong> it doesn't coincide with the hang though; just happens whn X.org starts
<jdong> the hang is triggered by compiz --replace
<bryce_> if it doesn't coincide with the hang, it is probably not relevant
<jdong> ack this livecd booting is way too noisy; I'll do a quick install to disk and try to get a backtrace
<jdong> thanks for your time
<bryce_> yup
<jdong> bryce_: aha, got a backgrace
<jdong> backtrace*
<jdong> looks identical to bug 327844
<ubottu> Launchpad bug 327844 in xserver-xorg-video-intel "compiz freezes xorg on intel graphics card" [Undecided,Incomplete] https://launchpad.net/bugs/327844
<jdong> http://paste.ubuntu.com/131446/
<jdong> started compiz, first got a SIGPIPE, then continuing I got a hang on ioctl() / drm_intel_gem_bo_start_gtt_access
 * jdong wonders if his obscenely large fonts is a bug or feature
<Tm_T> jdong: feature, font sizes are over 8 by default
 * Tm_T hides
<jdong> ah, my DPI was at 112 for some reason.
<jdong> 96 looks "right" on my display
<Tm_T> thay all look wrong to me (:
<jdong> lol
 * Tm_T really hopes to get >160 dpi display some day
<Tm_T> it's not fun that you have to count pixels when you choose your font settings, or watch those pixels anyway
<jdong> haha it also look like jaunty display brightness setting is in gray coding :)
<wgrant> jdong: Feature. 96DPI just looks reasonable because you're used to it.
<wgrant> LCDs tend to look a lot less bad with the default DPI setting when you use full hinting rather than slight.
<directhex> is there a "right way" to mount network drives on boot, given n-m, yet?
 * hyperair doesn't think so
<hyperair> ifplugsomethingorother stuff is in /etc/network/if-*.d
<slytherin> pitti: is there any plan to update ekiga to 3.0.2? It adds settings/data migration from 2.x.
<yao_ziyuan> i want to use update-manager in kubuntu,
<yao_ziyuan> so i removed adept and kpackagekit,
<yao_ziyuan> and modified update-notifier-kde to launch update-manager when updates are available.
<yao_ziyuan> the remaining problem is how to set up a mechanism to periodically check apt for updates
<yao_ziyuan> since update-notifier-kde itself doesn't check for updates
<yao_ziyuan> solved.
<joaopinto> hello
<joaopinto> I am trying to automate the console-setup install into a schroot, any tip on how to force it to install without asking for the kbd layout ?
<bryce_> jdong, there's a page on the X wiki explaining about the changed font dpi situation
<fatal_> bryce_: hi... I'm having problems with graphics corruptions since updating to Jaunty. I see you have updated packages in your PPA that failed to build.... are there built ones available somewhere for testing?
<bryce_> fatal_: for -ati?  latest is in the archive now.
<fatal_> (xserver-xorg-video-intel)
<bryce_> oh, no it needs a kernel patch first before it'll build.
<fatal_> ok..
<jdong> bryce_: any hints on that backtrace I got for my X hang?
<jdong> http://paste.ubuntu.com/131446/
<jdong> #1  0x00007fd37cf383bd in drm_intel_gem_bo_start_gtt_access ()
<bryce_> jdong, when I was looking at the 2.6.2 cl there were a number of bo fixes, so perhaps that includes a fix for this issue
<bryce_> jdong, are you using UXA or EXA?
<jdong> bryce_: whatever the default is on the GMA950; I made no changes to xorg.conf; assuming EXA
<jdong> I tried explicitly using UXA and that hung right at GDM
<bryce_> hmm
<jdong> (a bunch of various kern.log oopses)
<bryce_> jdong, unfortunately calls #0 #1 and #2 in your trace don't have symbols.  Maybe you forgot to install the dbg package for libdrm?
<jdong> bryce_: could very well be; let me verify and augment the trace
<jdong> ah, -intel-dbg evaded me.
<jdong> bryce_: ok now you're gonna question my sanity.
<jdong> compiz loaded without crashing this time...
<jdong> albeit horrifically laggy
<jdong> *investigates*
<ScottK> jdong: I don't think anyone is confused about your sanity.
<jdong> :P
<jdong> I suspect a suspend/resume cycle did something. Let me reproduce.
<jdong> *cry* why is life so unfair; all I did was remove appletouch.
<jdong> and some USB autosuspending hacks.
<jdong> *sets off to reproduce bug*
<jdong> *sets off to reproduce bug*
<jdong> err
<jdong> ok only on freshboot blood.
<bryce_> heisenbug
<jdong> maybe it only works when I DON'T have a full symbol gdb stack ready ;-)
<jdong> ok got the hang to happen
<jdong> it doesn't seem to be using the intel debugsyms though?
<jdong> still get No symbol table info available.
<jdong> on /usr/lib/libdrm_intel.so.1 with libdrm-intel1-dbg installed
<jdong> PEBKAC
<jdong> wait
<jdong> bryce_: any hints on not being able to get symbols on libdrm_intel.so.1 and i915_dri.so? I've got their -dbg packages installed
<bryce_> hmm, that should do it
<bryce_> jdong, I assume you restarted X?
<jdong> I am pretty sure I did
<jdong> let me reboot the hung system to be sure.
<bryce_> I'm not seeing any errors in the libdrm rules script, I'm fairly sure this should all be there
<jdong> bryce_: getting closer, got a traceback but this one looks very different
<jdong> (I'll go grab drm symbols too, grumble)
<jdong> http://paste.ubuntu.com/131747/
<bryce_> jdong, maybe you should try seeing if Option "AccelMethod" "UXA" gives better stability for you
<jdong> bryce_: IIRC that gave me nasty kernel oops hangs
<jdong> I can try that next if you don't feel these backtraces are useful
<jdong> *tries UXA*
<bryce_> jdong, well, without the libdrm symbols it's hard to troubleshoot.  If it turns out to be an -intel EXA bug, upstream likely won't care about it, since they're moving on to UXA anyway
<jdong> bryce_: compiz didn't crash but I am getting one frame every 8-10s
<jdong> Mar 15 18:43:36 blackbook64 kernel: [  108.203351] [drm:i915_getparam] *ERROR* Unknown parameter 6
<jdong> got several of those again in dmesg
<jdong> (X does not seem to be CPU spinning at all)
<jdong> Xorg.0.log shows nothing of interest happening
<jdong> http://jdong.mit.edu/~jdong/broken_macbook_uxa.txt full log if that helps
<jdong> bryce_: SUCCESS -- turning off Sync to VBlank solves the performance issue
<bryce_> jdong, excellent
<bryce_> hmm, thought tjaalton had switched that off by default
<jdong> bryce_: hmm didn't seem to happen on my jaunty alpha6 stock install.
<jdong> bryce_: only bug is the display crashes on resume, I think I saw that bug filed
<geofft> directhex: (re 08:18) still around?
<directhex> hm?
<geofft> did you get your question about network manager on boot answered?
<directhex> no
<directhex> i reckon if-up.d/mountnfs is doing as it's supposed to though
<directhex> assuming the script is executed when nm brings up the interface (the script works, i haven't tested that it's triggered when it should be)
<geofft> I think that works
<directhex> unmount is another story
<directhex> cifs umounts after the network has disappeared involves a rather lengthy delay
<geofft> so, when I had a machine with wireless that needed to do networked login
<geofft> I wrote http://web.mit.edu/geofft/Public/start-network.py. It's a horrible hack but it sufficces
#ubuntu-devel 2010-03-15
<psusi> ugh, I hate hal... it is such an undocumented flaming mess
<Keybuk> fortunately it's mostly dead
<psusi> I still have a hald-addon-cpufreq running and can't figure out WTF it's doing... it doesn't recognize --help, has no man page, and I'm coming up short on google
<geoff-ysu> hello
<ScottK> cody-somerville: I suspect https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/538524/comments/5 applies to xdm if someone didn't make the equivalent change already.
<ubottu> Launchpad bug 538524 in kdebase-workspace "boot hangs on splash screen, doesn't switch to KDM" [High,In progress]
<slangasek> Keybuk: why is bug #538524 a kdm bug when plymouth is still marked as 'stop on starting kdm'?
<ubottu> Launchpad bug 538524 in kdebase-workspace "boot hangs on splash screen, doesn't switch to KDM" [High,In progress] https://launchpad.net/bugs/538524
<pitti> Good morning
<\sh> mvo: julian fixed the python-apt-doc bug in debian...I wonder if we can backport this or do you want to push new python-apt into ubuntu?
<\sh> mvo: and good morning ;)
<mvo> \sh: good morning! there is a freeze exception for this pending, I have not checked this morning. I would like to get the new p-apt
<\sh> mvo: sounds good :)
<mvo> :)
<mvo> otherwise I guess a backport is it
 * \sh needs more coffee
<dholbach> good morning
<\sh> moins dholbach
<dholbach> hi \sh
<mvo> hey dholbach
<dholbach> hey mvo
<lool> doko__: I don't think it's worth disabling the valgrind build on armel; it's probably easier to keep the binaries around to help debugging
<cjwatson> I wish people would attach log files as log files rather than tarring them up
<lool> cjwatson: perhaps we should point them more strongly at apport and make sure the hook does the right thing?
<cjwatson> not always feasible, and I'm not always talking about Ubuntu bugs anyway :-)
 * lool didn't mention Ubuntu either   :->
<doko__> lool: ok, fine with me
<lool> doko: thanks
<doko> kees: http://launchpadlibrarian.net/40944002/buildlog_ubuntu-lucid-ia64.qt4-x11_4%3A4.6.2-0ubuntu2_FAILEDTOBUILD.txt.gz  the build did succeed without your stack-protector patch; no clue if it's really related to this ...
<cjwatson> Keybuk: do you think it would be worth changing loadkeys to read the keymap with zlib directly rather than forking gzip?
<Keybuk> will it make much difference?
<cjwatson> the bootcharts have enough variance that I'm not sure I can measure accurately
<cjwatson> centiseconds maybe, I guess you want everything you can get though? :)
<Keybuk> the console-setup stuff creates about a 1s regression in time for me consistently
<cjwatson> there is a noticeable amount of CPU spent in loadkeys, although I'm not sure how much of that is the zillion ioctls
<cjwatson> really?  I couldn't see any regression on the bootcharts that I could pin on console-setup
<cjwatson> there were differences in time, but they seemed to be accountable to other things
<cjwatson> (I looked as carefully as I could last night)
<Keybuk> you're doing it on "starting" mountall, right?
<Keybuk> or something similar?
<cjwatson> the only regression I could see from console-setup was a 0.08s increase in plumbing time on SSD
<cjwatson> start on (virtual-filesystems or starting rcS or starting mountall-shell)
<Keybuk> on the SSD charts, they've got 0.3s slower since adding console-setup
<cjwatson> they seemed to have practically that much variance anyway
<Keybuk> yes, but they've gone up consistently since then
<cjwatson> right, but I looked at the bootcharts and I couldn't see how that accounted to console-setup
<cjwatson> not with any accuracy
<Keybuk> I guess because it runs alongside plymouth, ureadahead, mountall, udev, etc.
<Keybuk> so it slows all those things down
<Keybuk> it's probably "doing too many things at once"
<cjwatson> ok, well we're certainly doing something we weren't doing at all before, due to a bug
<cjwatson> but I can see if I can trim out any more fat
<Keybuk> thanks
<Keybuk> I'm kinda tired of the boot stuff; every time we speed it up, someone manages to slow it down again
<Keybuk> and mostly it's DX not you ;-)
<Keybuk> so please read my slight grumpiness as not directed towards you
<Keybuk> the console-setup stuff is obviously a needed thing we have to fit in there somehow :p
<cjwatson> in some cases I was seeing X actually starting faster after console-setup; I'm not sure I know how to read these as well as you do
<cjwatson> and the variance on the HDD charts is hopeless of course
<Keybuk> dunno, X seems a bit slower in general at the moment again
<Keybuk> yeah, HDD is crap to read
<cjwatson> oh I meant the start of X
<Keybuk> right, that's what I mean, X init phase
<Keybuk> that could be the fact plymouth isn't dicking around with it either of course
<cjwatson> no, I meant the point on the chart at which X starts :-)
<cjwatson> not the time it takes to start
<Keybuk> oh, that varies a bit
<Keybuk> but yeah, it's all a bit jumbly
<Keybuk> hoping that after Î²1, people will stop randomly changing stuff, and we'll be able to tweak it a little bit more
<cjwatson> so there's the double call to setfont I mentioned, and zlib might make a difference - we're punting 120K of data around over read/write when we don't need to.  won't be a whole lot but it might be enough to let other things be scheduled more efficiently
<Keybuk> on the bright side, the VT switch bug proves what I've been saying about compiz all along <g>
<Keybuk> yeah, sometimes minor tweaks like that can have the most effect
<cjwatson> we're also loading the font file in userspace six times, so it might be worth seeing if we can modify setfont so that we can call it just once after all the ttys are ready, although I'm a bit worried about that introducing new races
<Keybuk> it might remove some
<cjwatson> maybe, it's all annoyingly delicate
<Keybuk> talking of which, still need to debug these two remaining plymouth issues
<cjwatson> Keybuk: you know, we might gain by simply not bothering to gzip the font; none of the console font files are bigger than 34523 bytes uncompressed
<cjwatson> for the keymap it's more questionable, but we only load that once vs. six times
<Keybuk> makes sense
<Keybuk> when do you set the font btw?
<Keybuk> after fbcon is loaded, I assume?
<cjwatson> yes - well, both before and after unfortunately, as we don't really know whether fbcon is going to be loaded
<cjwatson> I'm not implacably opposed to removing the "before" if that turns out to make a big difference
<Keybuk> fbcon is always loaded?
<cjwatson> (and if it all still works ...)
<cjwatson> I think I was concerned about failures before fbcon manages to load
<cjwatson> but, like I say, can perhaps remove that
<bdrung> pitti: regarding units policy: should g_format_size_for_display() use IEC prefixes then?
<pitti> bdrung: like "KiB"?
<pitti> might be better, yes
<bdrung> pitti: yes
<pitti> but I think we should just fix the individual apps
<pitti> I added a nautilus task
<seb128> let's drop this glib change for lucid
<seb128> we don't know how many apps that impacts on
<seb128> it's not a change you start a beta time
<bdrung> pitti: we should write new functions for glib and the glib-maintainer should accept them. then all apps can be ported to use the new ones (otherwise every package needs the conversion function)
<pitti> bdrung: *nod*
<pitti> seb128: already uploaded, bugs updated, followed up upstream
<seb128> we should working on fixing bugs now, not on shuffling around everything
<seb128> pitti, you rock, thanks
 * seb128 hugs pitti
<pitti> seb128: I added a nautilus task instead
<pitti> which is really the most pressing one
<pitti> gvfs/system-monitor etc. don't use that broken function
<seb128> the function is not broken...
<bdrung> pitti: btw, your approach make this PPA https://launchpad.net/~bdrung/+archive/base-2 totally unmaintable
<seb128> I wish we would just stay away to touch that and keep what upstream is doing
<pitti> seb128: sure it is
<pitti> seb128: but unless upstream wants to accept this kind-of ABI breakage, there's no way to fix it
<seb128> pitti, it's not broken, or rather it's broken by design I think
<seb128> right
<pitti> broken by whatever, yes
<seb128> well, what we have now is consitent with other systems and what users are used to so it's the less confusing user experience imho
<seb128> it's also the reason why GNOME has not been changing it
<bdrung> even people that are aware of IEC prefixes make mistakes: bug 538732
<pitti> haha
<ubottu> Launchpad bug 538732 in gnome-disk-utility "wrong base-10 prefix KB (correct is kB)" [Undecided,New] https://launchpad.net/bugs/538732
<pitti> seb128: no, it's so much not consistent
<seb128> anyway let's not redo this discussion now, I just think we should wait for after the LTS to do such changes
<pitti> seb128: but at least right now we have known inconsistency
<seb128> pitti, right, that's what I mean by consistent with other systems
<pitti> seb128: the reason why GNOME hasn't changed it was that it can be considered an ABI break, not because (most of them) think that it's actually correct
<seb128> other distros and OSes are inconsistant the same way
<bdrung> seb128: is this consistent: http://launchpadlibrarian.net/40938824/karmic-disk-properties.png
<pitti> we'll fix that in nautilus itself
<seb128> bdrung, yes
<seb128> bdrung, the volume is make wrong on purpose to match what vendor write on units
<pitti> seb128: oh come on
<seb128> anyway lunch time
<seb128> bbl
<pitti> seb128: enjoy!
<pitti> lunch sounds fine
<seb128> pitti, thanks
<seb128> pitti, no "come on", but that's a topic people will never agree on
<seb128> and that's why I think we should not step in that controverse for the lts
<seb128> rather delay to next cycle
<seb128> anyway lunch
<pitti> seb128: I didn't see anyone so far who argues that "4.0 GB" == "3.7 GB" in that dialog is correct
<seb128> bbl
<bdrung> that's why i am glad about the policy
<cjwatson> bug 538165 is pretty doom-laden
<ubottu> Launchpad bug 538165 in nautilus "Lucid reads file size wrong" [Undecided,Invalid] https://launchpad.net/bugs/538165
<cjwatson> and right now I'm not seeing any change there that would actually measurably improve matters
<bdrung> cjohnston: i added "Wrong labeled devices" to https://wiki.ubuntu.com/UnitsPolicy
<cjwatson> fix your tab completeion
<cjwatson> -e
<pitti> cjwatson: we could make the html pages also print MB, not MiB?
<cjwatson> anyway, "wrong labeled" is a misnomer
<cjwatson> just as it is a reality that hard disks are labelled in decimal units, it is a reality that CDs are labelled in binary units.  complaining that this is wrong is equivalent to stamping your feet and shouting that the universe is broken
<directhex> the universe IS broken.
<cjwatson> the thing that is wrong here is that the policy does not account for these situations; reality is what it is
<cjwatson> pitti: controlled by apache, can't change it in cdimage
<pitti> ah, right
<cjwatson> not without completely taking over directory listing functionality, anyway, which would be a right pain
<persia> Just as a minor note, hard drives aren't actually labeled in sane decimal units: they are labeled in decimal multiples of binary units.
<bdrung> cjwatson: should i change it to "Misnomers of devices"?
<cjwatson> persia: yes, indeed
<cjwatson> bdrung: dict misnomer
<cjwatson> I'm saying that "wrong labeled" is a misnomer, not that the devices are misnomers (whatever that might mean)
<cjwatson> as in, that section heading is wrong
<cjwatson> "Device types that this policy fails to account for", perhaps
<bdrung> cjohnston: so what your proposed heading?
<cjwatson> *please fix your tab completion"
<bdrung> damn
<cjwatson> 12:05 <cjwatson> "Device types that this policy fails to account for", perhaps
<bdrung> cjwatson: and something shorter?
<cjwatson> "Bugs in this policy"
<bdrung> cjwatson: bugs sounds too hard. you can't create a units policy without "bugs". either DVDs don't match or CDs.
<cjwatson> it is a bug.  whether you can fix it is a different matteer.
<cjwatson> matter
<cjwatson> if you think it's hard, then I think that's you being defensive, TBH
<bdrung> cjwatson: how can we educate manufacturers to label the devices correct?
<cjwatson> we can't.  HTH
<cjwatson> it's much better to live with the fact that this is the way it is than to waste our time in fantasy
<bdrung> cjwatson: this section is about the devices, which are not labelled correct by the manufacturers. this section should help readers to understand the problems dealing with these devices.
<bdrung> cjwatson: feel free to improve the wording
<cjwatson> who are we to say that they are incorrect?
<persia> Just out of curiosity, how do CD and DVD labelling differ?
<cjwatson> let's live in the real world here, a little bit!
<cjwatson> we are an OSV with a small percentage of the market - if we had >50% we might be able to dictate this sort of thing, but we don't
<bdrung> cjwatson: we can say that they are abusing the SI standard
<cjwatson> and even if it changed, CDs labelled the "old" way would be around for a long time - changing the labelling would probably be worse
<cjwatson> bdrung: I'm pretty certain they don't care
<persia> Consistency in marketing labeling is to be preserved.
<persia> There is sufficient investment in the ways the numbers are counted that it is very expensive to change, regardless of the motivation.
<bdrung> cjwatson: do you really think that changing the CD label from 700 MB to 700 MiB would be worse?
<cjwatson> I think it's never going to happen, so why should we waste time talking about it?
<cjwatson> in reality, it is for us to deal with what's out there, not the other way round
<cjwatson> Note that I am not saying this is possible; not all bugs are fixable, and we should acknowledge even those bugs that we can't fix
<bdrung> cjwatson: agreed
<pitti> I'd strive for consistency within the system, e. g. in GNOME (to avoid having two different units in the same dialog, etc.)
<cjwatson> and in this case we're trading off sets of bugs against each other, and a clear accounting of the bugs flowing from each choice makes it possible to choose between them with a clear head
<pitti> we can't ever fix the entire world
<bdrung> cjwatson: you are free to change the wording of this questioned section
<bdrung> pitti: for fixing the world, we have to fix #1 first.
<bdrung> ;)
<cjwatson> bdrung: done
<cjwatson> so what about the fact that hard disks are actually measured in decimal multiples of 1024 bytes?
<cjwatson> we rather spectacularly failed to address that in the policy, so we're still going to be off in our measurements, just less so
<bdrung> cjwatson: thanks
<cjwatson> or at least so I understand; wikipedia doesn't back me up here, although persia and I appear to have the same understanding
<bdrung> cjwatson: hard disks measured in decimal multiples of 1024 bytes? when displaying the size in kB or greater, will there be a difference or is it rounded away?
<persia> Unfortunately, all the disks I've bought in the past couple years have been unboxed, so I can't be entirely sure, but I remember reading "One gigabyte is defined as 1,000,000 kilobytes"
<bdrung> pitti: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/369525/comments/17
<ubottu> Launchpad bug 369525 in glib2.0 "Use IEC standard for binary byte units " [Medium,Won't fix]
<persia> bdrung: There will be a 2.4% error, which may matter for >1TB drives.
<cjwatson> what he said.
<bdrung> [    1.145856] sd 2:0:0:0: [sdb] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
<bdrung> that is 1500301910016 bytes = 1.500 TB
<bdrung> no 2.4% error
<cjwatson> of course that doesn't necessarily prove it since -2.4% from that would be 1.465 TB which would round to 1.5, but OK
<cjwatson> I don't remember where I picked this up from; it was a while back
<bdrung> even the SSD is correct: [    1.145751] sd 1:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
<bdrung> 64023257088 bytes = 64 GB
<cjwatson> I have to say, though, after reading the bugs, I agree with various folks who said we should not be doing this for Lucid
<cjwatson> IIRC, we only voted for this in the TB on the understanding that we had time to pull it out if it seemed to be causing trouble
<pecisk> Is it right that Lucid will have OpenOffice.org 3.2.0, not 3.2.1?
<seb128> pecisk, when is 3.2.1 due?
<seb128> pecisk, when will 3.2.1 be availble rather?
<seb128> brb, session restart
<pecisk> seb128: sorry, seems like 3.2.1 is still long overdue. Upstream translations deadline is 29th April, but it says nothing that release will follow soon. Sorry to bother :)
<pecisk> seb128: they plan RC1 on 19th April, for a fact
<seb128> pecisk, that means 3.2.1 will be after lucid
<pecisk> yep
<seb128> so lucid can't really have it I guess
<pecisk> I see :)
<primes2h> pitti: Hello. apport-collect doesn't allow me to add info to an existing bug report because I'm not the original reporter (in Lucid). Is that a bug or this is the way it works? is there any workaround?
<pitti> primes2h: yes, it's supposed to be that way; you should subscribe to the bug if you participate in the discussion
<primes2h> pitti: it could be a problem if you need to report some info against the linux package.
<pitti> why?
<pitti> if you submit information, but aren't available to followup questions, this isn't very useful
<primes2h> pitti: Some people could have the same problem (same hardware) and the original reporter could not have time (in a particular period) to provide them. Others can save time providing info automatically.
<primes2h> pitti: They can open a new bug report
<primes2h> by the way
<primes2h> but then they need to mark it as a duplicate
<primes2h> I mean, to provide info
<primes2h> s/provide them/provide info
<pitti> primes2h: right, but why shouldn't they subscribe to the bug they are providing info for?
<pitti> apport will warn if you aren't the reporter, and will refuse if you are neither the reporter nor subscribed
<primes2h> pitti: you mean that if they subscribe to the bug they can provide info via apport-collect?
<pitti> correct
<csurbhi> I want to send a patch to the samba mailing list.. should i also include it on some ubuntu list ?
<pitti> (that's what the error message says, too)
<primes2h> pitti: ah, ok! I understand. Sorry for misunderstanding ;-)
<primes2h> pitti: Thank you. :-)
<pitti> np :)
<pitti> primes2h: we originally didn't have that limitation, but that resulted in a lot of bug spam
<pitti> primes2h: such as random people dumping info to unrelated bugs, which were evne invalid/duplicates/etc.
<pitti> so we had to make it a little more strict
<primes2h> pitti: yes, I agree with this.
<primes2h> pitti: I mean, with you about this
<Riddell> cjwatson: you fixed the user permissions issue in kde_ui?
<Riddell> cjwatson: I was just going to add a conditional to go back to the old code unless it's for UBIQUITY_ONLY
<Riddell> cjwatson: I got the progressDialog fixed anyway, and another wee bug
<Riddell> Hmm, still the "An attempt to configure apt to install additional packages from the CD failed." issue
<cjwatson> Riddell: yes, working on a bit more - kdesudo isn't meeting our needs here and I think a tiny bit of manual xauth passing will be quite sufficient
<cjwatson> Riddell: apt> installing from USB stick?
<Riddell> cjwatson: no CD
<cjwatson> Riddell: I think we can leave the permission handling around KApplication alone now; it will be clearer that way
<Riddell> cjwatson: your fix looks much nicer than my suggested workaround, thanks
<cjwatson> I'm going to replace it actually :)
<cjwatson> http://paste.ubuntu.com/395630/ should fix bug 526456 at the same time
<ubottu> Launchpad bug 526456 in ubiquity "shutdown does not work" [Undecided,Confirmed] https://launchpad.net/bugs/526456
<cjwatson> Riddell: can we fix the way the hostname box gets prefilled with "-desktop-desktop-desktop-desktop-desktop"?
<cjwatson> actually, I think I see where that bug is ...
<cjwatson> http://paste.ubuntu.com/395631/ look plausible?
<Riddell> cjwatson: yes it does
<cjwatson> Riddell: is the big progress bar during installation indeterminate for you as well, or did I just break something?
<Riddell> cjwatson: I just committed the fix for that
<cjwatson> ah good
<smoser> Keybuk, you have a minute ? bug 531494.  If you could give me some wild guesses as to where to look, I'd really appreciate it.
<ubottu> Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Critical,Incomplete] https://launchpad.net/bugs/531494
<Keybuk> look for what?
<smoser> At this point i really expect that the backlevel of upstart just masked the issue... all other evidence appears to point to timing.
<Keybuk> there are very strange things in your logs that I cannot explain
<smoser> "where to look" == where to try to find the source of the problem.
<Keybuk> like the fact /proc/self/mountinfo has information about /proc that can only come from fstab
<smoser> Keybuk, oh ? like what?
<Keybuk> and thus something must run "mount /proc"
<Keybuk> (like that)
<smoser> ok... let me paste you the /etc/fstab just to make sure its sane
<Keybuk> no, you misunderstand me
<Keybuk> this implies that I do not understand your boot
<Keybuk> Ubuntu does not mount /proc that way
<Keybuk> I think you need to do elementary level debugging
<smoser> http://paste.ubuntu.com/395643/
<Keybuk> adding echo statements everywhere to a log, with timings
<Keybuk> including printfs in C code, etc.
<smoser> well, thats /etc/fstab
<smoser> Keybuk, i really can't think of anything strange about the image at this level (ie, prior to cloud-init running).  other than that, it is just "ubuntu", so I don't know how it could mount /proc in a different way
<Keybuk> it's not just ubuntu - you don't have an initramfs
<Keybuk> but the logs you've pasted suggest to me that you *do* have an initramfs
<Keybuk> which is what confuses me
<smoser> which log ?
<Keybuk> the mountall debug log
<Keybuk> filesystems are already mounted in unusual ways
<smoser> it is possible that i've posted an initramfs log
<smoser> nah http://launchpadlibrarian.net/40094568/console-fail-debug.txt surely doesn't have a ramdisk.
<Keybuk> though kees is going to kill you for that fstab entry, y'know :p
<Keybuk> like proper axe-through-brain killing
<smoser> you'd see messages from the ramdisk if there was a ramdisk
<Keybuk> smoser: ok...
<Keybuk> answer me this
<Keybuk> why is there several seconds of log before mountall is started
<Keybuk> during which scsi devices are loaded
<Keybuk> md devices are scanned
<Keybuk> etc.
<Keybuk> if that was just builtins, I'd vaguely expect them to be further up than that ;)
<Keybuk> might be wrong, obv
<cjwatson> hmm, the installer writes out such a fstab line
<smoser> ok... well, that is possible. However, the only way that I can think of that I  would have posted a log that had a ramdisk log is if it was a ramdisk from a different kernel
<cjwatson> why did we never notice this before?
<smoser> in which case you'd see ramdisk messages like "can't find /lib/modules-OTHER_UNAME"
<Keybuk> cjwatson: why didn't we notice our installer wrote kernels world-writable? :p
<smoser> cjwatson, that fstab is written by vmbuilder
<tseliot1> pitti: what happens if I call "dpkg-trigger gmenucache" in gnome?
<cjwatson> smoser: ok, but partman-target does the same thing
<smoser> cjwatson, what is wrong with it so i can fix it?
<tseliot1> pitti: err, I meant in kde
<Keybuk> cjwatson: OOI, why does the installer put that in fstab?
<Keybuk> ignoring the fact it's wrong for the moment
<cjwatson> Keybuk: mostly hysterical raisins I expect; although presumably it means that 'mount /proc' works
<cjwatson> (in a chroot, say)
<Keybuk> cjwatson: but "mount /sys" wouldn't work
<Keybuk> and "mount /dev" wouldn't work
<cjwatson> granted on /sys; in a chroot, you'd typically want to bind-mount /dev
<Keybuk> (I actually have a vague plan to have mount read /lib/init/fstab too fwiw)
<Keybuk> I tend to think you want to bind-mount /proc too ;-)
<cjwatson> can that become an un-vague plan, and then I can get rid of this with a clear conscience? :-)
<Keybuk> sure
<Keybuk> but either way, that fstab entry is wrong
<Keybuk> security hole style wrong
<cjwatson> as in nodev,noexec,nosuid presumably
<Keybuk> right
<cjwatson> indeed - I'm just changing that now
<smoser> Keybuk, where do you see "several seconds of log before mountall is started" ?  are you referring to the "QEMU HARDDISK" kernel message line ?
<cjwatson> smoser: ^- you'll want to do the same in vmbuilder - "defaults" -> "nodev,noexec,nosuid" for the /proc line
<Keybuk> smoser: that stuff, yeah
<Keybuk> smoser: I'm sorry I'm not of help here
<smoser> Keybuk, those drivers are absolutely built in... there was another bug that we fixed to get them
<Keybuk> but I really don't know what's wrong with your system, any more than you do
<Keybuk> and since I don't have access to these systems, and nobody has ever reported this problem with Ubuntu on genuine hardware, I can't replicate it
<Keybuk> I think the most interesting comment is Steve's comment #9
<smoser> Keybuk, i can remedy the first
<Keybuk> in your failed logs, there is no event about sda1 from udev
<Keybuk> that's why I asked for the udev log from a failed boot
<Keybuk> but you haven't been able to provide that
<smoser> if you're truely interested. and "genuine hardware" is kvm guest, so.
<Keybuk> smoser: I don't have any machine capable of running kvm
<smoser> Keybuk, well the file isn't there... I presumed not written yet in the failed case.
<Keybuk> somehow, I have only managed to obtain laptops and desktops without hardware virtualisatio
<Keybuk> whoah
<Keybuk> back up a sec
<Keybuk> sda1 isn't there?
<smoser> no
<smoser> /var/log/udev.log
<Keybuk> confirm for me again
<Keybuk> oh, right
<Keybuk> so that implies udev didn't start either
<qense> pitti: Have you seen <https://launchpad.net/gudev-sharp>? I think that's what required for the Halsectomy of Banshee and the other C# apps. Something to watch for lucid+1?
<sladen> vish: http://launchpadlibrarian.net/40957362/light-themes-panel-misalignment.png
<smoser> cjwatson, i'll get that remedied in our builds and get bug opened for vmbuilder to soren
<smoser> thank you
<Keybuk> init: udevmonitor main process (81)
<Keybuk> smoser: ^ udev monitor is running
<Keybuk> so the log must be there
<smoser> so maybe it wasn't flushed...
<Keybuk> try /dev/.udev.log
<Keybuk> or whatever that damned filename is ;)
<smoser> i had to kill the instance then mounted loop back the disk image
<pitti> tseliot1: it shouldn't do anything at all
<pitti> qense: ah, I didn't; nice
<Keybuk> no, don't kill the instance
<Keybuk> you need to login to it while failed
<smoser> Keybuk, there is no way to do that.
<smoser> at least not that i can think of
<Keybuk> killing one of your VM instances is like saying you have a bug with the laptop
<Keybuk> but you binned the laptop
<pitti> qense: perhaps by that time we'll get gobject-introspection working
<tseliot1> pitti: so, about bug #522969 , do you think it's a gnome only issue?
<Keybuk> you have network I assume?
<ubottu> Launchpad bug 522969 in gnome-menus "doesn't add nvidia-settings to menu after installing" [Low,Fix released] https://launchpad.net/bugs/522969
<Keybuk> or a console to them?
<pitti> tseliot1: yes, it is
<smoser> Keybuk, except i can start it again in seconds.. (regarding the "like a laptop")
<smoser> Keybuk, we have serial console read-only
<Keybuk> smoser: no, you can start a totally different environment
<smoser> network istn' up
<Keybuk> ok, so use the serial console then
<Keybuk> put a root shell on it
<tseliot1> pitti: ok, thanks, I'll just add a "dpkg-trigger gmenucache || true" in the postinst then
<pitti> tseliot1: thanks
<smoser> Keybuk, well, yeah... its not *so* simple... but i can probably do that.
<smoser> not so simple because something else (Eucalyptus) starts the instance, and starts it with kvm console going to a file
<qense> pitti: And gudev-sharp is back to zero. Anyway, it would be a huge improvement considering the reluctance of the GTK# maintainer(s) to publish new features for GAPI, it's all kept in trunk.
<vish> sladen: ty
<Keybuk> at the point you have a root shell, on an instance, that is not running the job - then grab me
<Keybuk> and we'll debug it
<smoser> Keybuk, thank you.
<smoser> then, there is the race condition... hopefully this wont throw it off.
<jcastro> Keybuk: that box that had the enter bug has been solid over multiple boots all weekend
<Keybuk> jcastro: solidly replicating the bug? :p
<jcastro> Keybuk: no, solidly working. :)
<Keybuk> heh
<Keybuk> I need to amend that bug title
<Keybuk> since it actually looks like it happens on the DRM renderer too
<smoser> cjwatson, just to be crystal clear: http://paste.ubuntu.com/395650/ is what is "right" for /proc, right ?
<psusi> Keybuk: I was thinking... couldn't ureadahead be improved by having it not block everything else until after it finishes reading everything?  i.e. allow the jobs to run in paralell with readahead reading the blocks that the jobs don't need just yet, but will soon?
<cjwatson> smoser: yes
<smoser> cjwatson, second related question... how far back (dapper?) would those options be valid
<Keybuk> psusi: that's how it behaves on SSD
<cjwatson> smoser: forever, AFAIK
<smoser> ok. thanks.
<Keybuk> psusi: on HDD, that is the worst, possible, thing you can do
<psusi> Keybuk: only in so far as IF the other tasks try to access the page before readahead has fetched them yet... if you could somehow ( maybe by using IO priorities ) make sure that the other task blocks when this happens until ureadahead gets around to fetching the page in the order IT chose... it would be a speed up
<Keybuk> psusi: no
<Keybuk> psusi: if *any* task tries to access *any* page on the disk, that will incur a seek
<Keybuk> which will turn ureadahead's single one-sweep pass across the disk, into a seek-laden nightmare
<Keybuk> and seeks is precisely what ureadahead is trying to avoid
<psusi> Keybuk: right... so if you could make sure that the kernel does not service any other requests until after ureadahead finishes.... that would prevent the out of order access causing seeks, but still allow the other tasks to execute as much as they can as they can in paralell with ureadahead
<Keybuk> psusi: that's what ureadahead does
<Keybuk> but at that point in the boot, all the tasks want the disk
<Keybuk> so you have to wait for readahead
<psusi> huh?  no?  no other jobs are started until ureadahead finishes
<psusi> they want a mix of cpu, wait time, and IO.... they can do the cpu and wait time in paralell with ureadahead, it's just the IO becomes a problem if it is allowed to be intermixed with ureadahead doing it
<Keybuk> oh, right, I changed that in Upstart because otherwise you can end up with things running in a different order
<Keybuk> but seriously
<Keybuk> ureadahead is written how *I* know things work
<Keybuk> it wasn't written based on ideas
<Keybuk> it was very very heavily tested and tweaked to give the best performance
<Keybuk> with extensive use of things like blktrace
<Keybuk> but since I wrote it, it's based on what I know
<psusi> yes?
<Keybuk> so if you have different ideas, by all means, try them out!
<psusi> that's why I'm bouncing it off you... ;)
<Keybuk> why?
<Keybuk> I'm not a human blktrace
<Keybuk> I can't listen to your idea and tell you whether it's better or not
<Keybuk> I can only tell you why ureadahead is the way it is
<Keybuk> if you think I'm wrong, since you're arguing here, you clearly do
<Keybuk> then go ahead and actually prove it
<Keybuk> bring a blktrace of the boot with ureadahead how I wrote it
<Keybuk> and a blktrace of the boot with ureadahead how you'd write it
<psusi> to confirm my understanding of how it works right now... the key points being that 1) upstart waits for ureadahead to finish reading before starting other jobs, and 2) it does this because if it didn't, the other jobs would cause out of order IO, right?
<Keybuk> psusi: no
<Keybuk> psusi: it does this because if it didn't, fsck might happen first, and that can rearrange the disk about a bit on some filesystems
<Keybuk> iirc
<Keybuk> the upstart ordering is unrelated to "blocking on ureadahead" is that makes sense
<Keybuk> ureadahead on HDD already has CPU and I/O priorties set
<psusi> ohh... so ureadahead runs before fsck, while the filesystem is still mounted ro?
<Keybuk> yeeeees ;)
<psusi> so fsck has to wait for ureadahead to finish, and everything else waits on fsck...
<Keybuk> yeeeeees ;)
<psusi> what if you did readahead in two passes?  first pass gets everything needed up to the fsck, then once fsck finishes, start another ureadahead pass to fetch everything else, while the rest of the jobs start up in paralell?
<Keybuk> tried it
<Keybuk> slower
<Keybuk> seriously
<psusi> because the other jobs running in parallel get their IO intermixed with udreadahead, causing out of order reads?
<Keybuk> no
<Keybuk> because then you're doing two slow passes across the slow disk
<psusi> then why?
<Keybuk> instead of one slow pass across the slow disk
<Keybuk> if pass-across-the-disk costs (say) 7s
<Keybuk> doing two doesn't mean you get two of 3.5s
<Keybuk> it means you have two of 7s
<pitti> geser: I'll commit your recent cdbs upload to bzr
<Keybuk> well, in reality, they get a bit faster because you have more read than seek
<psusi> eh?  should be more like first pass is 1 second, and second pass is 6
<Keybuk> psusi: why?
<Keybuk> psusi: have you ever tried any of this stuff?
<Keybuk> seriously
<psusi> because first pass needs to only read the blocks needed by fsck and things before it, which should be a relatively small amount, and the second pass only needs to read blocks needed by what comes after
<psusi> no ;)
<Keybuk> the first pass still needs to seek over the disk
<Keybuk> still needs to seek between the blocks
<Keybuk> still needs to read the blocks
<psusi> ohh!
<Keybuk> still needs to open files
<Keybuk> etc.
<Keybuk> passing over a rotational hard drive is not free
<psusi> of course... since the files aren't stored on the disk in optimal order, it ends up having to go all over the disk looking for the first pass blocks, skipping over blocks the second pass needs anyhow in the process
<Keybuk> exactly
<psusi> if we were to pack the files in order though ;)
<Keybuk> sure
<Keybuk> in fact, if you wanted to do the most useful thing you could, it would be to write an online defrag for ext3 & ext4 that could accept ureadahead pack files as input, and refrig the pack file after the defrag
<tseliot1> pitti: two more things: 1) I need to call that dpkg-trigger in the postrm too; 2) I should do the same in nvidia-common in the alternatives library so that the trigger is called when we switch between drivers too
<psusi> online would be nice... but offline is workable, especially if you were to build it into an alternate initrd, you could have a grub menu choice to optimize the system
<pitti> tseliot1: ok, understood
<tseliot1> pitti: I'll work on it
<ion> Even nicer would be something that keeps track of *all* usage patterns (without hogging too much resources just for the statistics) and keeps reordering blocks in the background using spare IO time. :-)
<psusi> Keybuk: so ureadahead already uses io priority to make sure that IF another job does try to use a page that hasn't been read yet, it will block until ureadahead gets around to it in the correct order?
<Keybuk> yes
<Keybuk> it's like IO_PRIO_IVANOVA or something
<psusi> cool... then I need to try packing the files and splitting the ureadahead into two stages
<ion> IO_PRIO_GARYBRANDY
<cjwatson> asac: are you going to upload your patch in bug 527720, or are you waiting for review?
<ubottu> Launchpad bug 527720 in klibc "thumb2 porting issues identified: klibc uses mov.*pc" [High,Triaged] https://launchpad.net/bugs/527720
* cjwatson changed the topic of #ubuntu-devel to: Archive: Beta 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
<cjwatson> (I think the libplymouth2/mountall difficulty is sufficiently far in the past now)
<Keybuk> until the next time
<Keybuk> so, right
<Keybuk> M{aemo,oblin,eego}
<tseliot1> :-)
<Keybuk> does that mean that they're using Upstart now?
<Keybuk> and does that mean that Arjan van der Van has died, so they could do that over his dead body?
<tseliot1> heh
<cjwatson> what's he got against upstart?
<directhex> palm pre uses upstart. it's upstarty!
<Keybuk> cjwatson: I'm not sure if it's anything other than "we wrote it"
<Keybuk> he doesn't like ureadahead either
<Keybuk> as far as we know, Arjan was one of the main instigators of that whole Copyright Assignment flamewar - basically over Upstart
<james_w> mvo: do you know if anyone is looking in to the aptitude crash?
<mvo> james_w: I can do this today, I know what is causing it
<dpm> hey bryceh, I'm trying to set the right project for a bug someone mistakenly filed against the 'ubuntu-translations' project. Is there an upstream project associated with the 'x11-utils' in LP?
<james_w> mvo: would you like me to fix it? (If it's quicker for you to point me towards the issue than fix it yourself)
<james_w> it will be easier to fix it than to workaround it so that I can do local testbuilds in a clean chroot
<mvo> james_w: my "fix" is to revert the 13_screensize patch that is causing it and instead just increase the static buffer
<Keybuk> http://www.theregister.co.uk/2010/03/14/canonical_ceo_silber/
<mvo> james_w: if you want to look into it, that is welcome of course, I'm pretty sure its a bug in the screensize patch
<Keybuk> heh, that's the first article I've read on Jane taking over that references the fact she used to sell nuclear weapons
<james_w> mvo: that's what I assumed, but the reports didn't pour in until after a couple of weeks with the new patch
<mvo> james_w: hmmm
<james_w> no, sorry, the bug report *predates* the latest upload
<mvo> oh
<mvo> james_w: can you reproduce it?
<james_w> yeah
<mvo> ok, cool. then you can have it :)
<james_w> if LP wasn't timing out on the older uploads I would see if they could have affected it too
<james_w> damn :-(
<james_w> should be trivial to reproduce
<james_w> "aptitude changelog aptitude" should do it
<james_w> and now it works...
<mvo> works for me too
<mvo> (both i386 and amd64)
<_UsUrPeR_> Hey all. I'm using apt-mirror to create a local repository on an internal server at my office network. It's become a consensus that we no longer need to have a local mirror of the 8.04 LTS in the office, but I can't figure out how to remove all the old hardy packages. Does anybody know of a good way to purge all hardy packages from my server?
<_UsUrPeR_> We've also got a local repo of both 9.10 and 10.04 Alpha, so just deleting the repository directory would require a re-download of ~80 gigs
<mvo> james_w: a double dl_complete (cmdline_progress.cc) maybe? delete acqprogress; run twice
<mvo> james_w: I wonder if its something with sigc++ that causes the completed signal to be run twice
<james_w> mvo: yeah, I can't reproduce anymore. I'll come back to it if I can
 * Keybuk hugs cjwatson for converting ssh to Upstart
<Keybuk> huh
<Keybuk> bwahaha
<Keybuk> pitti: I think I just figured out the VT switch bug
<Keybuk> one cause of it, anyway :p
<Keybuk> if rc 2 finishes before gdm ...
<Keybuk> not sure why that would stop X from flipping it back though
<preseed> hello i d like to make a full automated install using preseed file but i get a " Syntax error : unable to determine template name "  in /var/lib/preseed/log   i do not find the documentation about it
<Keybuk> Mar 15 16:18:53 ratchet init: rc state changed from post-stop to waiting
<Keybuk> Mar 15 16:18:53 ratchet init: Handling stopped event
<Keybuk> Mar 15 16:18:53 ratchet init: plymouth goal changed from start to stop
<Keybuk> err.
<Keybuk> whut?
<Keybuk> you didn't boot *that* fast
<Keybuk> pitti: yup, I am a prize numpty
<pitti> Keybuk: you figured it out? rocking!
 * Keybuk decides to blame the server team
<Keybuk> yeah
<Keybuk> gdm deactivates plymouth when it's about to start X
<Keybuk> leaving it in an inactive state
<Keybuk> then when X is running, gdm tells plymouth to quit
<Keybuk> either saying everything was ok (leave the fb alone - X is on it) - or X failed (switch back to vt1, reset console, etc.)
<Keybuk> ...
<Keybuk> for the server people, when rc2 finishes, we run plymouth quit
<Keybuk> which happens to be the exact command that gdm runs to tell plymouth that X failed to start
<pitti> ah, haha
<geser> pitti: Thanks. Is there a real difference between lp:~ubuntu-core-dev/cdbs/ubuntu and lp:ubuntu/cdbs?
<pitti> geser: the second is an auto-import without real history
<Keybuk> the on_quit code is clearly wrong anyway
<pitti> we don't use the auto-imports for branches where we have history already (i. e. existing Vcs-Bzr:)
<Keybuk> since it checks the wrong variable
<Keybuk> but this is a niiice race
<pitti> Keybuk: so, what we roughly want is the end of rc2 not calling that if we either have gdm started, or will start it eventually (with the latter being pretty fuzzy in upstart terms, I figure)
<Keybuk> right, or something
<Keybuk> either rc2 should do plymouth quit --unless-deactivated
<Keybuk> or gdm should be doing plymouth quit --i-am-x
<pitti> ^ but if gdm is very slow, this would still go back to vt1?
<pitti> (i. e. if it didn't get to deactivate before rc2 finishes)
<Keybuk> sure
<Keybuk> but that's ok at least
<Keybuk> you'd get a black screen before X of course
<Keybuk> but X would flip VT back again
<pitti> a "login:" screen, anyway, but yes, it would at least be "more" correct
 * Keybuk shakes his fist at ubuntu-server
<Keybuk> at least we can tell people how to fix that -> "echo sleep 60 >> /etc/rc.local" :p
<pitti> easy, just put gdm into rc2.d *cough* *duck*
<Keybuk> that doesn't help in this case
<Keybuk> gdm is in the background once the gdm multiplexer is running
<Keybuk> the X server inits in the background
<Keybuk> always did
<Keybuk> the race is against X finishing init, not gdm starting
<pitti> Keybuk: I thought gdm would do a plymouth --deactivate thing first?
<Keybuk> it does
<Keybuk> that changes the meaning of any following "plymouth quit"
<Keybuk> the trouble is the "plymouth quit" didn't come from gdm ;)
<Keybuk> it came from rc2 ending
<Keybuk> so need to disambiguate that
<Keybuk> the only thing left then would be rc2 ending before gdm even started
<Keybuk> which would be "safe" just fugly
<dmart> Wow, you're talking about the precise issue I was just trying to debug
<Keybuk> dmart: the "login:" thing?
<dmart> Well, Xorg running on vt1 (at the same time as getty)
<Keybuk> Xorg shouldn't ever be running on vt1
<Keybuk> are you still seeing that?
<dmart> It looks like there is a race problem with the way Xorg magically chooses a vt--- but writing a wrapper script, it looks like getty has not launched yet when Xorg starts up
<Keybuk> the first X server does not chose a VT
<dmart> How not?
<Keybuk> it is hardcoded to use VT7
<dmart> Well, it uses tty1
<Keybuk> see debian/patches/05_initial_server_on_vt7.patch
<dmart> Hmmm, when did this patch go in?
<Keybuk> dmart: mid-karmic development
<Keybuk> dmart: you're still seeing an issue with today's lucid daily?
<dmart> I'm using a filesystem from a ~ 2 week old daily-live.  I'll try updating xorg and see if the problem persists
<Keybuk> you need to update plymouth, mountall and gdm
<dmart> OK, I'll try that
<Keybuk> pitti: thinking about it harder, I definitely think that it's gdm's commands that have to change
<Keybuk> since once deactivated, nothing else must quit plymouth
<Keybuk> X has taken over that VT
<Keybuk> so gdm should call something else (or with different flags)
<Keybuk> and the ordinary quit command should *fail* with a distinct error code
<Keybuk> the upstart pre-stop script should catch that error code, and abort stopping plymouth
 * Keybuk can think of a race there too
<Keybuk> argh
<Keybuk> argh
<Keybuk> argh
<Keybuk> if plymouth is stopped by rc2 ending
<Keybuk> then gdm tells it to quit
<Keybuk> the pre-stop runs quit, gets told not to
<Keybuk> so runs "start" to change the state
<Keybuk> but the "plymouth exiting due to SIGTERM" is still there
<Keybuk> I don't know what will happen in that case
<bryceh> dpm, xorg-server works as upstream for most x11-* stuff
<Keybuk> this could even trigger an Upstart bug
<dpm> ok, thanks bryceh
 * Keybuk cries
<Keybuk> ...and files bug #539175
<ubottu> Launchpad bug 539175 in upstart "init: cancelling pre-stop using "start" will cause ignoring of exited process during pre-stop invocation" [Undecided,New] https://launchpad.net/bugs/539175
<bryceh> pitti, is there a way to expand apport blobs after the fact?  E.g. bug 539069
<ubottu> Launchpad bug 539069 in xserver-xorg-video-intel "[i945GM] X hangs with black screen on login" [Undecided,New] https://launchpad.net/bugs/539069
<kees> Keybuk: I worry when people invoke my name to strike fear into the hearts of unbelievers.  :)  what's the fstab issue?  It didn't jump out at me in the scrollback
<Keybuk> kees: default fstab written by the installer has "defaults" for mount options
<Keybuk> rather than noexec,nosuid,nodev
<kees> Keybuk: I imagine some filesystems need suid and exec though?
<Keybuk> kees: sorry for /proc mount options
<kees> oh, hrm.  shouldn't we fix that for debug, security, and /var/run too?
<kees> (better yet, make "defaults" be noexec,nosuid,nodev heh, which would break _nobody_ I'm sure...)
<Keybuk> /var/run is nosuid already
<Keybuk> I think it has to have exec and dev for the various nefarious purposes it's used for
<kees> yeah.
<Keybuk> likewise I vaguely remember it being true for debug too
<Keybuk> security - no idea
<kees> debug requires _exec_?  that's odd.
<Keybuk> kees: something to do with mmap
<kees> and does it carry device nodes?
<kees> Keybuk: mmap should only require exec if something is very wrong.  (i.e. READ_IMPLIES_EXEC personality)
<Keybuk> dunno
<Keybuk> these are as you specified them ;)
<kees> what?
<mneptok> kees: wait, you *don't* like your name invoked to strike fear? does that mean you don't want me carrying my "KEES COOK KNOWS YOUR IP ADDRESS" placard outside Apple Stores?
<kees> heheh
<Keybuk> kees: we went though the mounted filesystem list ages ago at a millbank sprint
<kees> mneptok: well, it's a form of putting words in my mouth.
<Keybuk> and you indicated what mount options should be
<kees> Keybuk: ah, fair enough.  generally "as strict as possible" is my answer.  :)
<Keybuk> none            /sys/fs/fuse/connections  fusectl         optional                          0 0
<Keybuk> none            /sys/kernel/debug         debugfs         optional                          0 0
<Keybuk> none            /sys/kernel/security      securityfs      optional                          0 0
<Keybuk> those may be simply that you didn't know
<Keybuk> or maybe they post-date that conversation
<Keybuk> I don't think we should mount /sys/kernel/security at all
<Keybuk> it's clearly wrong
<kees> but noexec on /proc makes sense to avoid re-exec of /proc/$pid/exe
<Keybuk> :D
<kees> they post-date that conversation
<Keybuk> kees: right, I remember that and */fd being the obvious holes
<kees> makes AA and SELinux harder to use.  ;)
<Keybuk> kees: FEATURE
<kees> hehe
<pitti> bryceh: hm, expand to the bug doesn't currently work; but you can use apport-unpack on the .crash file to get the files locally
<kees> cjwatson: so it's partman that needs adjusting for this?  perhaps have a blanet test for anything with a leading /sys/ in the path to get the same defaults as /sys/ itself?
<Keybuk> kees: add them to the list to fix post-lucid
<kees> s/blanet/blanket/
<Keybuk> kees: partman only writes something for /proc
<bryceh> pitti, is there a bug against apport wishlisting this feature?  I run into needing it from time to time
<cjwatson> kees: what Keybuk said, and I've already uploaded a fix
 * kees goes to figure out how security is mounted these days...
<bryceh> pitti, e.g. people behind firewalls
<kees> probably my bug
<Keybuk> kees: mountall
<dmart> Keybuk: I upgraded upstart, mountall, plymouth, libplymouth2, xserver-xorg-core, but I still get my X-on-tty1 problem.  Did I miss something?
<Keybuk> kees: so as above
<Keybuk> dmart: I have no idea then
<pitti> bryceh: you can also file it as a _new_ bug with apport-bug /path/to/file.carsh
<kees> Keybuk: ah, you meant that for mountall.  I failed to see context, sorry.
<bryceh> pitti, related question, is it possible to file a bug with apport when X is not working at all?  (e.g. entirely from command line)
<Keybuk> kees: those are from /lib/init/fstab
<kees> Keybuk: not something to fix for lucid, post-beta?
<dmart> Keybuk: I'll do a dist-upgrade, maybe some other packages are out of date and causing a problem.  I'll get back to you if that still doesn't fix it.
<cjwatson> dmart: it would be generally sane to upgrade everything just to make sure - we're pretty close to beta-1 and the current state is probably more stable than the random thing you had
<Keybuk> kees: futzing around with kernel filesystem mount options this late in an LTS cycle strikes me as dangerous
<bryceh> pitti, ok
<pitti> bryceh: uploading a .crash file to an existing bug already has a bug, let me find it
<kees> Keybuk: well, it would break very obviously, if we got it wrong, yes?
<Keybuk> kees: not necessarily
<dmart> cjwatson: doubtless :)  The archive was temporarily broken when I built this system, so I fell back on an older daily-live
<Keybuk> we could break vmware or something
<kees> okay, fair enough.
<Sarvatt> dmart: did you remove splash from the kernel command line and forget to put it back?
<pitti> bryceh: bug 506885
<ubottu> Launchpad bug 506885 in apport "Allow user to upload a crash file to a certain bug" [Low,Triaged] https://launchpad.net/bugs/506885
<kees> I cannot think of anything immediately under user-control in security
<bryceh> pitti, great thanks
<ScottK> kees: Could you have a look at qt4-x11 on ia64.  It failed again and I wonder if it's related to your stack protector change.
<pitti> bryceh: yes, with apport-bug --save /tmp/foo.apport, move that to a different machine, and apport-bug downloads/foo.apport
<kees> same for fuse
<kees> ScottK: shouldn't be -- stack protector isn't enabled on ia64, I don't think.
<ScottK> kees: OK.
<ScottK> doko: ^^^ any other ideas?
<doko> ScottK: enoclue ... maybe retry on another buildd?
<doko> lamont: ^^^
<kees> cc1plus: error: .pch/release-shared/QtCore: No such file or directory
<kees> especially since this didn't fail:  g++ -g -Os -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -Os -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DELF_INTERPRETER=\"/lib/ld-linux-ia64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_S
<doko> my local build using the uploaded package is still building. let's see if it fails
<kees> (who is running qt on ia64?)
<\sh> kees: are you working on a (semi) automatic way to include the canonical partner repository during upgrade when using sun java6 packages from formerly multiverse? or at least a way to inform the user?
<dmart> Sarvatt: splash is not on my command line at all: I'm bringing up on a new platform.  I'd be concerned if having no splash screen is not supported... ?
<kees> \sh: I haven't been, no.  I imagine update-manager will prompt to remove it, which is the upgrade path I'm happiest with.  ;)
<cjwatson> slangasek: bug 539182 - seems like your casper fix didn't entirely take?
<ubottu> Launchpad bug 539182 in casper "Lucid Live CD fails to reboot after ejecting + enter" [Undecided,New] https://launchpad.net/bugs/539182
<\sh> kees: well, people won't be amused about that ;)
<\sh> kees: especially server people won't be amused, when sun-java6 is gone during dist-upgrade and having tomcat6 ;) (hint on security manager)
<cjwatson> \sh: what server people upgrade without reviewing the list of packages to be removed?
<cjwatson> and can I make sure none of them ever manage any servers I care about?
<cjwatson> this seems fairly basic diligence :)
<\sh> cjwatson: no...but as it seems there is no way to "remind" admins, that "this package moved from multiverse to whereever"
<mneptok> "Oracle"
<cjwatson> I guess that's what release notes are for
<ScottK> \sh: It's been removed from Ubuntu.  If they want it, they can figure out what repo to enable.
<\sh> cjwatson: +1 BUT when I upgraded to lucid, apt-get didn't tell me: "Dude, listen, this package will be removed, you sure you want it?"
<\sh> ScottK: I could agree, when there is an alternative, but regarding the special "tomcat6 + openjdk == no security manager, because it's not opensourced by sun, now known as oracle"...ok, I can agree multiverse is not the section where we push security updates regulary,
<ScottK> IIRC open security issues and no patches were a big part of why it got removed.
<\sh> but right now, regarding our LTS it would be really cool to "shout out loud that this package moved from multiverse to the partner repository".
<cjwatson> that would be a pretty major new feature in apt-get
<cjwatson> which has historically been something left to higher-level frontends
<cjwatson> better just put it in the release notes, I think
<kees> \sh: can you write something up for the release notes?
<\sh> cjwatson: regarding our idea to push "puppet" as default server configuration management, I don't think it will execute "do-release-upgrade" but apt-get or aptitude only...but that's really not the point
<cjwatson> I'm sorry but server admins can surely read release notes
<cjwatson> I have more sympathy for desktop cases
<\sh> kees: sure...pointer to the release note sandbox on w.u.c.?
<ScottK> \sh: File a bug against ubuntu-release-notes and attach the text.
<ScottK> (or just put it in the bug, it doesn't need to be an attachment)
<\sh> kees: ScottK: bug #539199 eventually someone who writes native english can fix errors in the text or make it more "bling bling"
<ubottu> Launchpad bug 539199 in ubuntu-release-notes "[Lucid Lynx] Release notes should mentioned removal of sun-java6-* packages and where it is now located" [Undecided,New] https://launchpad.net/bugs/539199
<zyga> mvo: hello
<zyga> mvo: I noticed you have cherry picked bzip2 fix from trunk, I wonder what is the point of having freeze exception for .41 then
<mvo> zyga: I leave that to you, I needed to do the upload for the scan.data update
<mvo> zyga: if you think we should postpone 2.41 that is fine with me
<mvo> zyga: I'm also fine with sponsoring the freeze exception, it contains some nice fixes/additions. either is ok with
<mvo> me
<zyga> well actually I'd like one thing from you: could you have a look at my bug for the exception and tell me what's missing?
<zyga> I read the whole procedure
<zyga> but it's a little hazy to me, I think the testing/packaging changes are missing but I'm not sure how to describe that
<mvo> zyga: I'm about to leave for the evening, I can mail you tomorrow morning about it, ok?
<zyga> sure, thanks mvo!
<Aquina> Hey guys! Does someone know how to change a launchpad account password? Is that damn function implemented?
<ScottK> Aquina: Ask in #launchpad
<Aquina> thx
<mvo> thanks zyga
<RoAkSoAx> cjohnston, i have a few doubts with dh-apport. If the source packages is called net-snmp and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary packages listed in debian/control, correct?
<RoAkSoAx> ups
<RoAkSoAx> cjwatson, i have a few doubts with dh-apport. If the source packages is called net-snmp and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary packages listed in debian/control, correct?
<RoAkSoAx> cjohnston, sry wrong person :)
<kirkland> pitti: howdy, around?
<kirkland> pitti: i noticed some strange desktop behavior in testdrive ...
<kirkland> pitti: using the same today's desktop amd64 ISO, in KVM there is no bottom panel in the desktop; while in VirtualBox there is ...
<kirkland> pitti: do you have any immediate explanation for the strange difference?  or should I start looking into a bug in qemu-kvm ?
<kirkland> pitti: oh, actually, looks like it has to do with resolution ...
<kirkland> pitti: if i use the default resolution (1024x768) in KVM, no bottom panel;  if I lower (to 800x600), it shows back up
<kirkland> bryceh: do you know anything about that ^ maybe?
<bryceh> kirkland, nope
<kirkland> bryceh: let me check one more thing ...
<kirkland> bryceh: pitti: false alarm, i'm a dope ... it's fine, just off my viewable area
<kirkland> alt-mouse FTW
<FlyingSpaghettiS> How now brown cow. I'm here to submit my job application! As(potentially) the new leader of your GUI design team, I'm sure I could come to an awesome and inspired revelation of proper element configuration for the new ubuntu. With absolutely no experience in any IT fields(or any other fields), my newly minted internship(with you of course) will pave the way to my worthless associates degree.
<jjardon> Hello, I wonder if firefox-gnome-support package could be compiled with Gio support instead GnomeVFS
<jjardon> Seems that all GNOME support libraries are optional: https://hg.mozilla.org/mozilla-central/file/69cb1df1cb0f/toolkit/system/gnome/nsGnomeModule.cpp
<zyga> I'm trying to boot current amd64 live cd on a system with gtx295 graphics card
<zyga> during normal boot the process seems to hang
<zyga> and the display shows some mess (black/white blocks + random pixels)
<zyga> is there a way to trigger no-fancy-graphics during boot to see what's going on?
<zyga> there was a 'safe graphics' mode in karmic, I wonder if something similar is available for lucid too
<zyga> hmm, I booted with noslash vga=771 and despite the fact that there was some corruption lucid booted correctly
<zyga> now I have x11 with native panel resolution, good!
<cr3> hm, .disk/info for 20100315 is "Alpha" for alternate and "Beta" for desktop. not something I expected
<cr3> I was expeting the date (20100315) and the official ("Alpha" or "Beta" in this case) where attributes of the build rather than attributes of the particular disk image
<cr3> s/where/to be/
<cjwatson> cr3: alternate and desktop are two separate builds that often happen to share a build number
<cjwatson> so I imagine what happened is that the code was switched over to say Beta between those two daily builds
<micahg> cjwatson: would I be able to get a release team ack on a TB3 update for Beta 1?
<cr3> cjwatson: I thought the images where just different germinate configurations
<cjwatson> cr3: it's a bit more complicated than that
<cjwatson> micahg: I'm on the phone right now, but what
<cjwatson> 's the bug number?
<micahg> bug 530405
<ubottu> Launchpad bug 530405 in thunderbird "Please update TB to version 3.0.3 in Lucid." [Wishlist,Triaged] https://launchpad.net/bugs/530405
<cjwatson> cr3: the relevant bit is that they're run at different times of day, though :)
<_UsUrPeR_> cjwatson: About preseed: I would like to make an install without a network interface, but I can't seem to find and netcfg
<_UsUrPeR_> err whoops
<_UsUrPeR_> to finish: but I can't seem to find any netcfg/disable function to stop the scary red screen from appearing
<_UsUrPeR_> the screen says "no network interface detected"
<_UsUrPeR_> any ideas?
<cjwatson> _UsUrPeR_: errors are not in general preseedable; what you need to do is arrange for the installer not to take the path where it encounters an error.  Unfortunately I'm not sure that that's sanely possible in this case (a bug).  I think you might need to rebuild the initrd and stub out netcfg to make it work, I'm afraid
<_UsUrPeR_> cjwatson: ok, thanks. I appreciate you checking in to this for me. It's unfortunate that there's no fix for this, but at least I can save myself some time by quitting while I'm ahead.
<cjwatson> micahg: I'm OK with the update for lucid; thunderbird is a substantial package that takes a while to build, though, and I think we might be better off arranging for this to be available right after beta-1, rather than taking up a big chunk of buildd time with it in the lead-up to beta-1?
<cjwatson> (I realise that it's a security update, but it *is* lucid and there's precedent for holding those off during freezes)
<micahg> cjwatson: well, my only concern is it being seeded on xubuntu CD with the old version
<cjwatson> beta-1 isn't something that people can sanely install and just leave there anyway; they'll have to continue upgrading
<cjwatson> I don't know, I'm just concerned about the 4.5 hour build time on armel
<micahg> amel is empty now :)
<cjwatson> slangasek, what do you think?
<micahg> cjwatson: I'd also like to get a new version of Firefox and Ubufox in if possible
<slangasek> cjwatson: looks like we have some idle armel builders right now; I think we can take it in
<slangasek> eh, firefox+thunderbird+ubufox?  now I think we're pushing it
<micahg> slangasek: next version of Firefox was tagged today which should be the version for release
<micahg> slangasek: and ubufox because report a bug in firefox is broke
<slangasek> ubufox is cheap to build, that's reasonable to take
<micahg> k, Firefox can wait as it's not technically released yet
<slangasek> firefox is not so cheap, and hits all images, including the armel ones; I don't want to delay image mastering for that
<micahg> slangasek: k, I'll have it ready for upload Friday then :)
<micahg> slangasek: but thunderbird's ok?
<slangasek> micahg: if you upload it in the next few hours, yes
<micahg> slangasek: k, I'll get chrisccoulson_ to do it as soon as he gets back :)
<micahg> slangasek: do I need a bug for you to release ack for ubufox?
<slangasek> micahg: if Feature Freeze is involved, yes
<slangasek> if it doesn't need an FFe, just upload
<micahg> slangasek: k, it's just bug fixes
<Sarvatt> dmart: if you dont have splash on the command line it starts X on VT1
<micahg> does adding ellipses to comply with HIG need an FFe?
<lifeless> when is string freeze?
<micahg> lifeless: Doc string freeze is next thursday
<RainCT> lifeless: .. and application string freeze was two weeks ago (part of UserInterfaceFreeze)
<micahg> RainCT: it's my Q if adding ellipses for HIG compliance requires an FFe
<micahg> slangasek: can I ask you about the ellipses HIG compliance issue whether it needs an FFe?
<RainCT> micahg: I can't answer that question, but maybe you could update the existing translations to add the ellipses there (so that the translators don't need to do that themselves).
<micahg> RainCT: they already are in the bzr branch :)
<slangasek> micahg: sorry, I don't know what that is - context?
<micahg> slangasek: Report a Problem in Firefox doesn't comply with HIG since it doesn't have elipses and it requires further action
<ScottK> micahg: Generally ANY U/I changes at this point need to be coordinated through the doc team (U/I freeze exception).
<micahg> so there's a fix committed to ubufox trunk
<ScottK> The point being to make sure that the docs match what we release.
<micahg> k, so it's easier if I don't pull that in at the moment
<ScottK> So I don't think HIG or not makes a difference.
<micahg> ScottK: k, thanks...maybe I'll skip it for now
<slangasek> right, HIG wouldn't get a free pass on FF
<ScottK> Units policy doesn't either (just saying)
<RoAkSoAx> cjwatson, I have a few doubts with dh-apport. If the source package is called 'net-snmp' and I have the apport hook in debian/net-snmp.apport, it should install the hook in the first binary package listed in debian/control, correct?
<kees> lool, persia: so, after I do mk-sbuild --arch armel .... what's the right way to start an instance of armel qemu?
<kees> ogra too :)  or anyone else that does this...
<slangasek> zul: I've reverted several changes you made to the server-ship seed, you can only seed binary package names and there were several source-only package names that had been seeded (paste, pastescript, pastebin)
<slangasek> zul: incidentally, why are these seeded in server-ship, instead of just in one of the 'supported' seeds?  Is there a task that will install them off of the CD?  If not, there's not much advantage to shipping them /on/ the CD
<kees> popey: did you ever make parts 2 and 3 of the screencasting screencast?
<cjwatson> RoAkSoAx: debian/net-snmp.apport specifically applies to the net-snmp binary package.  If you want to use the first binary package, just call it debian/apport
<cjwatson> RoAkSoAx: this is just standard behaviour for debhelper configuration files - it's not specific to dh_apport
<kees> asac (and micahg): you mentioned you had to do something funny to remember the firefox "middlemouse.contentLoadUrl" config setting.  is that still in -3.6?  it seems to get repeatedly triggered now that I'm using the "rm compatibility.ini" workaround for loading Greasemonkey.
<micahg> kees: idr, but I think I have a fix for the greasemonkey issue
<micahg> kees: are you running the daily from teh PPA?
<kees> micahg: I'm not, no, since it doesn't have the missing font patch.
<micahg> kees: k, well, as soon as I have approval for the patch, I'll drop it in the dailies and probably upload friday
<micahg> for the addons
<kees> excellent.
<kees> micahg: can you put the font patch in too?  :)
<micahg> kees: which one, the hinting or LCD?
<kees> micahg: which ever makes my eyes bleed with out it.  LCD, I think.
<kees> the one I reported and mdeslaur fixed
<micahg> kees: that one I have to see why cairo won't take it
<kees> micahg: right, but in the meantime, let's get it into firefox.  :)
<micahg> kees: can't...
 * kees goes back to avoiding discussion of this regression.  :)
<RoAkSoAx> cjwatson, oh ok, because in the dh_apport manpage says this: debian/source.apport Installed into /usr/share/apport/package-hooks/source_src.py (where src is the current source package name) in the package build directory of the first package dh_apport is told to act on.
<cjwatson> that's literally "source.apport"
<cjwatson> "source" isn't a substitution - if it were, it would be underlined like "package" is in "debian/package.apport" :-)
<RoAkSoAx> yeah that's why I thought using 'net-snmp.apport' would install as source_net-snmp.py
<cjwatson> no, use source.apport for that
<cjwatson> if you do that, the apport hook applies to all binary packages from that source
<RoAkSoAx> cjwatson, oh ok awesome :) thanks
<mdz> I'm having a problem with the netbook daily where the initramfs fails to find the live filesystem
<mdz> is this a known issue?
<cjwatson> not one I've seen
<mdz> cjwatson, oh hi
<cjwatson> hey
<mdz> the usb stick looks sane enough to me, and I can mount it from the initramfs with no problem
<mdz> AFAICT all it does is look for /casper/*.squashfs and that is definitely there
<cjwatson> I haven't been testing with USB sticks or with the netbook daily (though I don't think the latter should matter much)
<cjwatson> does anything in https://wiki.ubuntu.com/DebuggingCasper help?
<cjwatson> it at least has a couple of runes for cranking up debugging
<mdz> cjwatson, didn't know about that, i'll have a look
<mdz> cjwatson, it's failing the UUID Check
<mdz> + cat /conf/uuid.conf
<mdz> + uuid=ab72326c-1f54-4d17-b5c0-fd1698c95d27
<mdz> + [ -e /cdrom/.disk/casper-uuid-generic ]
<mdz> + cat /cdrom/.disk/casper-uuid-generic
<mdz> + try_uuid=
<mdz> + [ ab72326c-1f54-4d17-b5c0-fd1698c95d27 =  ]
<mdz> + return 1
<cjwatson> I wonder if usb-creator is failing to copy that?
<cjwatson> odd that we wouldn't have noticed before now
<cjwatson> was that file present in the source iso?
<mdz> cjwatson, looking into it
<mdz> the files are there, but 0 bytes
<mdz> cjwatson, argh, md5sum -c shows checksum failures
<mdz> looks like the stick is to blame
<mdz> I thought these things would be more reliable than CD-Rs...
<cjwatson> if you ever find a reliable medium, let me know
<cjwatson> I guess the ASR motto applies
<cjwatson> I do believe my grub2 change worked first time
 * cjwatson can die happy now
<lifeless> cjwatson: btrfs support
<lifeless> ?
<cjwatson> I'm not that clever
<mdz> cjwatson, I've been noticing the device mounted while usb-creator is working with it; I wonder if that's related
<lool> kees: I think you don't have to do anything, it will just work
<lool> kees: So just start it as usual
<lool> kees: Oh are you trying to start a vm?
<cjwatson> ev: ^- didn't you say something about problems along those lines just recently?
<lool> kees: I've started this page documenting various tools/approaches https://wiki.ubuntu.com/UbuntuDevelopment/Ports perhaps you'll find the answer you're looking for; it's still rough though
<mdz> just tried a microSD card, which has led to squashfs errors from the kernel. yawn.
<lifeless> I had a fun thing the other day, a usb drive which has to be formatted raw, no partition table - but usb-creator didn't want to do that
<lifeless> would an option for usb-creator be a reasonable feature request?
<mdz> lifeless, it can do that, it's just not very obvious
<mdz> find the parent device and click the 'format' button
<lifeless> mdz: IIRC, when I did that, it gave it a MBR, dos disklabel and a partition within that.
<lifeless> I shall try again.
<mdz> lifeless, oh, maybe I misunderstood what you meant
<mdz> you're saying you don't want a partition table on it?
<lifeless> right, it can't be booted of by the netbook I was installing otherwise
<lifeless> it needed to be treated like a floppy disk - filesystem on /dev/sdb with first block a boot record
<mdz> I just noticed that after clicking "quit" on the usb-creator dialog which says "everything is cool, go forth and boot that sucker" there is actually still a progress dialog in the background and a umount process still running
<mdz> I am totally blaming usb-creator
<psusi> say... the cpufreq gnome panel applet requires root privs for full functionality... I gather it should get them somehow with policy kit but I have no idea how that works... can anyone point me in the right direction?
<zyga> psusi: I remember that some part of that applet had to be setuid to work correctly, that was long time ago though
<psusi> zyga, yes, setting the binary to suid will make it work, but shouldn't it use polkit to elevate privs?
<psusi> so that normal users can still run it without root privs?
<zyga> psusi: it's not using polkit to do it as far as I know, and besides that - polkit is not the answer - you'd still need something running as root
<zyga> (something that would change cpu policy)
<RAOF> psusi: What you need, IIUC, is to have a dbus-activated setuid process which acutally does the action, then polkit arbitrates access to the setuid process.
<zyga> polkit would just authorize you to use that
<zyga> right
<RAOF> Alternatively, you could patch out the ability to set CPU frequency policy.
<psusi> exactly... polkit should be running the applet as root if the user has admin permissions
<zyga> psusi: running the applet as root is a bad idea
<zyga> psusi: the applet runs as your user
<psusi> it has to run as root to modify the settings
<zyga> psusi: the applet should request via polkit to access another process that just switches the policy and exits
<zyga> psusi: the applet should not modify the settings directly
<psusi> hrm... that sounds like a rewrite of the applet
<zyga> not really, just split
<RAOF> Just the CPU policy setting bit.
<zyga> just replace whatever_you_do_to_write_to_cpu_policy_governor_file
<psusi> hrm... guess I'll file a bug on that then and echo it upstream
<zyga> IMHO writing the "daemon" to do that is trivial, coupling that to dbus and polkit is more challenging
<zyga> AFAIR all you have to do is echo to some file in /sys or /proc to alter the CPU governor
<RAOF> Is it actually useful, though?
<zyga> well, yes, it is
<zyga> I remember how angry I was to find out that ubuntu shipped this package without setuid
<zyga> for security reasons, this is true but still
<RAOF> But what did you actually use it for?
<psusi> to manipulate the cpu frequency
<RAOF> Yes, that's obvious.  But why manipulate the CPU frequency?
<zyga> no
<zyga> to manipulate the CPU governor
<psusi> sometimes I don't want it speeding up
<RAOF> What is the goal for which manipulating the CPU governor is the most appropriate solution?
<zyga> the default governor sucked, it was on-demand
<zyga> so my laptop would suck all the power because of the crap flash advert running on some page
<psusi> exactly
<zyga> I always switched to powersave
<psusi> when you know you're running up because of some pile of shit flash app, you can lock the speed down
<zyga> funny thing though, that was like 3 years ago :D
<zyga> on my first laptop that would get very hot when doing anything CPU intensive
<zyga> upstream <-> downstream disparity is not so good in this case
<zyga> upstream ships setuid, ubuntu changes that
<zyga> eh
<RAOF> Stupid flash.
<zyga> I think it's more complex than 'stiupid flash'
<RAOF> Right.  You'd also like a thermal manager.
<psusi> crap, just to get it working I set suid on the binary and it crashes trying to load... xsession-errors shows: System exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0
<psusi> that used to work, just bad system policy
<zyga> psusi: don't do that
<zyga> apt-get source that-stuff
<zyga> AFAIR there are two parts
<zyga> the corba applet
<zyga> s/corba//
<zyga> the applet - it's loaded via corba but that is not relevant
<zyga> and a helper tool that needs to be setuid
<zyga> I'm not 100% sure but that's what I remember
<psusi> there is a command line tool that you can use to manipulate the settings, but setting it suid didn't let the applet change them
<zyga> psusi: reload the applet
<psusi> did
<zyga> actually, if you google a little, you might find the bug I opened for that issue, I'm not sure where it was exactly, I think that lp.net did not exist just yet
<zyga> probably gnome bugzilla IIRC
<psusi> I remember a few years back I found in the gnome help file that it could modify the settings and I think I looked into it and found that they install it suid root, but we don't... so I set it suid and it worked... but now making it suid craps out
#ubuntu-devel 2010-03-16
<psusi> hrm.. I'm a bit out of my realm here with all this dbus and gconf stuff, but it looks to me like the cpufreq panel is already broken up into two components where the cpufreq-selector-servervice is supposed to be run as root and called on by the panel
<psusi> there's an xml file in here that looks like it's supposed to define some sort of control interface methods at /org/gnome/CPUFreqSelector
<psusi> it doesn't look like it's actually getting installed though
<persia> kees: The point of the way mk-sbuild does things is that you don't need to start a VM: just `schroot -c` or `sbuild -d` as usual.  Plus what lool said.
<persia> kees: also, both armel and powerpc are known to work (armel works better).  I believe the rest of the architectures are untested (but bugs against qemu-kvm-extras-static would be nice if they don't)
<ccheney> anyone know of a simple code snippet for debian/rules to do patching if it isn't using cdbs?
<ccheney> or an example package that i can look at for it
<cjwatson> use dpkg-source v3, and then you can just leave the patches applied and not have to worry about junk in debian/rules
<persia> ccheney: there are a bundle of them.  What's your debian/rules look like now?
<ccheney> persia: i'm adding a patch to karmic webkit in particular for backport to hardy
<ccheney> cjwatson: hmm sounds cool but can't do that for hardy :)
<cjwatson> run what-patch to see what system it's using now
<cjwatson> you should always stay in line with that
<ccheney> cjwatson: good idea for lucid and neweer though :)
<ccheney> cjwatson: ok
<cjwatson> if it isn't using any patch system, just apply the patch directly
<ccheney> cjwatson: as best as i can tell it isn't using any patches at the moment
 * persia avoids repeating the obviously correct advice
<cjwatson> I must get round to finishing that blog post about my experiences with 3.0 (quilt)
<ccheney> ok so i'll have it applied directly along with a copy of the patches in debian/patches for anyone who wants to pull them out separately (if ever)
<cjwatson> oh, at best semi-relatedly but while I think about it, my current projection is that dh will overtake cdbs in unstable sometime in July
<ccheney> cjwatson: dh 7?
<cjwatson> the dh command in debhelper 7, yes
<ccheney> ah i see
<ccheney> cjwatson: is there a doc on how deb 3.0 works?
<ccheney> cjwatson: other than man dpkg-source i mean
<cjwatson> that was what I was going to recommend
<ccheney> so does it automatically create the debian tarball for you or do you do that yourself?
<micahg> cjwatson: any chance you can approve thunderbird and ubufox in the queue?
<ccheney> i didn't notice where it mentioned how that happens, i might have missed it
<cjwatson> it automatically creates it the same way as it automatically creates .diff.gz
<cjwatson> micahg: sorry, I'm just about to go to bed
<micahg> cjwatson: k
<cjwatson> micahg: poke on #ubuntu-release if you need to
<ccheney> cjwatson: ok, so you just need premade other tar.gz's but the debian one is automatically made?
<micahg> cjwatson: thanks
<cjwatson> ccheney: yes
<ccheney> cjwatson: ok thanks that helps a lot :)
<cjwatson> ccheney: oh, there's http://wiki.debian.org/Projects/DebSrc3.0 too
<ccheney> cjwatson: thanks
<ccheney> cjwatson: are we going to get xz support anytime soon (lucid/lucid+1 ?)
<cjwatson> lucid+1
<ccheney> ok
<cjwatson> I believe anyway, haven't paid terribly close attention but I saw some commits go by
 * ccheney will do the testing for that with OOo for lucid+1, aiui it works better than lzma
<ccheney> ok
<psusi> bug #356208 mentions: The reason appears to be that in order to work, the CPU applet (and a whole bunch of other things) attempt to validate that the "Desktop User" is a user who can perform administration. They look for the user who was setup during installation and not finding that user, they don't do anything. But, they also provide no errors, nor do they they attempt to use the "root" user.
<ubottu> Launchpad bug 356208 in gnome-applets "CPU Frequency Scaling Monitor Applet does not allow me to change CPU Frequency (Ubuntu 8.10)" [Low,New] https://launchpad.net/bugs/356208
<psusi> how exactly does the policy kit decide who is the admin?  or where can I start tracing that process?
<psusi> hrm.... here's a question... it seems that the default upstream policy is for the cpufreq applet to admin_auth_keep, so you have to type your password the first time it needs it...
<psusi> bug #455694 people are complaining about the password prompt... it seems like no harm can be caused by allowing admin users to set their cpu frequency without entering their password first
<ubottu> Launchpad bug 455694 in gnome-applets "CPU Frequency Scaling Monitor asks for authentication all the time" [Low,New] https://launchpad.net/bugs/455694
<psusi> if I were to attach a debdiff adding a patch changing it to just be allowed, would this be accepted?
<persia> psusi: How do you detect "admin user" then, if not by authentication?
<lifeless> persia: group membership ?
<psusi> persia, hrm... actually I guess just setting it to yes allows anyone to do it...
<persia> lifeless: Wasn't pitti trying to drop the "admin" group?
<lifeless> persia: so don't use that group :)
<psusi> the policy kit now has auth_admin_keep set... so you have to type your password the first time you try to change the frequency
<lifeless> personally I'd say the 'local' bit is policy kit should be enough
<psusi> some users on the forums have suggested editing it to just yes so it doesn't annoy you
<RAOF> lifeless: at_console?  Yeah, that's what I was thinking.
<psusi> eh?  at_console?  that a group or polkit rule?
<lifeless> RAOF: yah, if thats what its called.
<persia> psusi: That's the "stick it under the rug" solution.  Dig into policykit a bit more, and see if you can't determine whether the current user should be able to do that by other means, and only ask for authentication when this fails.
<persia> (at_console seems reasonable for most use cases)
<psusi> hrm... yea, I guess that's the question... is there something between allow_active=auth_admin_keep and yes
<psusi> oh wait, no... it sounds like allow_inactive lets anyone do it, and allow_active=yes means anyone on the local console can do it
<persia> "anyone at the local console" breaks the use case of doing something, opening a guest account, and handing it to the person next to you, but I'd hope that's a rare use case.
<lifeless> persia: for cpu frequency setting
<lifeless> persia: I don't think it matters
<psusi> yes, the guest would also be able to use it, but the most harm they can do is slow down the cpu, so...
<psusi> yea, don't think it really matters....
<lifeless> persia: because they can also take the machine and walk away :)
<persia> Agreed, hence my contrived use case : we generally don't care if a long-running job takes a little longer when *someone else* is currently at console.
<lifeless> persia: ok, now I understand. your description was a little opaque
<psusi> so I can change it to yes and attach the debdiff to the bug and request a sponsor upload and it should be accepted?
<persia> psusi: None of the folks in this conversation so far can upload it, so the answer is "maybe".
<persia> But if it does something sensible, and is still relatively secure, likely.
<psusi> it looks like there is no option to require admin, but NOT require them to enter their password again, shame...
<persia> Maybe it doesn't really require admin.
<persia> I think the lack of behaviour you see is to support things like computer labs, where most active users are *not* admins.
<psusi> wait, what was the magic phrase to put in the change log to auto close the lp bug?
<persia> (LP: #nnnnn)
<psusi> to allow the interactive user to set the cpu frequency without first authenticating as an admin.  Closes (LP: #455694).
<psusi> that look good?
<ScottK> You don't need closes
<persia> psusi: debuild -S -us -uc to get a source.changes : check for the launchpad-fixes-bugs header (or whatever it's called)
<psusi> hrm... ok
<psusi> so just "authenticating as an admin (LP: #455694)."?
<maco> "Closes: #12345" is Debian BTS syntax
<psusi> hrm... seems the existing quilt patches here all start with two digits... how should I choose a number for mine?
<psusi> or do I have to even?
<maco> number tells what order they were added to the package, usually
<psusi> ohh, it looks like it uses bzr... should I instead create a branch on lp and modify that, then link to the branch in the bug?  hrm...
<micahg> or what order they need to be applied sometimes
<micahg> nm,not for quilt
<psusi> I'm confused... why is it using quilt, if it already uses bzr?
<kees> lool: do we have kernels for anything besides versatileab from the list in  qemu-system-arm -M help
<kees> (I actually get _no_ output from qemu-system-arm when booting them)
<pitti> Good morning
<persia> kees: What are you trying to do at a higher level.
<pitti> persia, lifeless: CPU freq scaling admin group> I'll answer in the bug report; I have a plan for the similar problem in udisks
<persia> pitti: Excellent.  Thanks.
<dholbach> good morning
<jiboumans> TheMuso, crimsun: pitti says you might know about this; karmic + dell vostro + built in mic; any known issues with the mic not actually working?
<lool> kees: No, only versatilepb and ab (I think the kernel is configured for both)
<lool> kees: There's a qemu branch for OMAP3 and an OMAP3 kernel is pending, that might be a new combination in the future
<lool> kees: Make sure you pass -cpu cortex-a8 to qemu-system-arm
<lool> kees: The default for versatile is an older CPU, but our userspace needs armv7+
<lool> (cortex-a8 is v7; we also patched the versatile Kconfig to select v7)
<ev> mdz: would you be so kind as to file a bug for the usb-creator umount issue you ran into?
<ev> lifeless: I think that's perfectly reasonable as a command line option.  If you file a bug, I'll put it on my list for lucid+1.
<lifeless> ev: ok, I'll double check my facts and put a bug up for you
<ev> much appreciated
<lifeless> de nada
<mvo> Riddell: if you could have a look at #538522 that would be much appreciated
<Riddell> mvo: where do I look for the error in the test case logs? http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/
<mvo> Riddell: I pasted the relevant bits in the bugreport I think, its in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/apt-term.log
<mvo> Riddell: if you search for "dpkg: error" there
<mvo> Riddell: you will find the file overwrite problem
<mvo> Riddell: sorry, its not entirely user-friendly yet the output :/
<Riddell> oh aye there it is
<smb> pitti, Do you know off your head whether something from userspace already touches /sys/power/disk. I am looking at a bug for one system that requires the "shutdown" instead of the default "platform" method and I am wondering whether this justifies a new quirking method in the kernel or is much simpler done in user-space...
<pitti> smb: the only thing I know of is pm-utils' hibernate command, which writes a "hibernate mode" to /sys/power/disk (and then "disk" to /sys/power/state)
<pitti> I don't think we touch it anywhere else
<pitti> smb: I think this $HIBERNATE_MODE might be what you are looking for
<pitti> it can be overridden by hooks, I figure
<smb> pitti, Well mode would probably be what I am looking for. Right
<pitti> pm/defaults:# HIBERNATE_MODE="shutdown"
<pitti> ah, that's just a comment
<pitti> smb: our actual default is ""
<smb> pitti, Ok. But its a place to investigate further
<pitti> smb: in other words, we don't write /sys/power/disk by default
<pitti> smb: but if a suspend.d script would set it, it should respect it
<smb> pitti, Ok. Thanks. I think thats a starting point
<directhex> hm. i guess glxinfo shouldn't segfault, right?
<pecisk> right
<pecisk> :)
<pecisk> directhex: Xorg driver?
<directhex> pecisk, intel
<pecisk> directhex: bug reported?
<directhex> pecisk, doing it now
<directhex> eh? i appear to have nvidia libglx.so
<pecisk> wow
<pecisk> directhex: isn't some kind of new hardware you got there?
<directhex> pecisk, dell laptop.
<pecisk> directhex: brand new?
<directhex> pecisk, nope
<directhex> worked with karmic. wonder what happened
<pecisk> directhex: pastebin.ca lspci please
<directhex> http://paste.ubuntu.com/396106/
<pecisk> directhex: there is no Nvidia. Do you have nvidia-glx installed? Maybe remove it, restart and try again.
<directhex> wait a sec, this xorg.0.log is ancient.
<pecisk> ahh :)
<directhex> no, my mistake, was reading the Release Date line
<directhex> i really don't get it. md5sums for libglx.so match the xserver-xorg-core.md5sums file, yet Xorg.0.log says vendor="NVIDIA Corporation" on the module
<directhex> huh? strings says it's not nvidia's
<directhex> wtf is going on -_-
<pecisk> directhex: 'dpkg -l | grep nvidia' >> pastebin.ca :)
<directhex> wait a sec, it's this "nvidia-current". bleh @ constant renaming of nvidia packages. also, wtf did it come from?
<pecisk> directhex: nvidia-current I think is newest nvidia-glx driver, just so you don't have to remember which version of nvidia driver you have to install
<pecisk> just remove it and reboot machine
<pecisk> faulty dependencies I think
<pecisk> directhex: how did you installed Lucid?
<directhex> where is the log from an update-manager upgrade?
<pecisk> have no idea
<directhex> 2010-03-09 14:19:10 install nvidia-current <none> 195.36.08-0ubuntu1
<directhex> came in with my upgrade, i think
<pecisk> something pulled it in
<directhex> wobbly windows are back
<pecisk> yay \w/
<mvo> directhex: /var/log/dist-upgrade
<directhex> mvo, right. definitely came with the upgrade
<directhex> aha! libmyth-0.22-0
<directhex> so if you had mythtv on karmic, upgrading to lucid will break non-nvidia 3d
<directhex> that's probably a bug
<radoe> hm, I wonder if I did something wrong with bug #535090? It is marked as security vulnerability (although of lower impact). I grabbed it last week, linked branches with fixes from intrepid up to lucid and debdiffs for easier review. I think I subscribed the right groups, but nothing seems to happen about it.
<ubottu> Launchpad bug 535090 in erlang "CVE-2008-2371 (outer level option with alternatives caused crash)" [Low,Confirmed] https://launchpad.net/bugs/535090
<highvoltage> has anyone had any weird sudo behavior on the live cds? the first time I use sudo on the edubuntu livecd it kills gdm and shows some weird characters while it's restarting. after that it works fine
<persia> radoe: Everything looks right for that bug.  In the most recent secuirty team meeting, there was talk of a backlog: I suspect you've just hit that.
<superm1> directhex, mvo i'm not sure why libmyth-0.22-0 was even kept/upgraded during the upgrade though, nothing should be depending on it, and there is a 0.23-0 in the archive that should have pulled in libvdpau1 rather than anything nvidia
<directhex> superm1, well, that's the only culprit i can find for why it was there o_o
<radoe> persia: well, thx for this info.
<psusi> pitti: I see you got involved with the cpufreq polkit bug... last night I chanced the source code policy for gnome-applets to fix the policy file, then installed the new package, but the policy file on my system remained unchanged, and it doesn't look like the binary package contains that file... what gives?
<seb128> psusi, what file?
<psusi> also the package seems to be using both quilt and bzr, so which should I use?  make a quilt patch?  make a bzr branch?  make a quilt patch IN a bzr branch?
<seb128> psusi, the later option
<psusi> ugh, really?  use one vcs to change control another?
<seb128> psusi, quilt is used by the packaging, bzr is just where we store the changes
<psusi> that just seems.... wrong...
<seb128> psusi, quilt is used as a patch system not a vcs
<psusi> that seems like saying something is a car, not a vehicle ;)
<diwic> psusi: which then gets into a diff.gz, so in practice you have at least three indirection layers for a patch.
<seb128> psusi, the policy is in the -data binary btw, not sure if that reply to your question
<psusi> what is the purpose of continuing to use quilt IN bzr?  bzr should be providing you with everything quilt does and more
<seb128> psusi, the usecase we have usually is to drop a git commit from upstream in the patches dir
<seb128> psusi, we don't have the full source in bzr just the debian dir
<psusi> ohh
<seb128> psusi, and we keep upstream changes in the debian dir not in the diff.gz
<seb128> upstream -> distro
<psusi> I see
<diwic> psusi: People who gets the built source package don't necessarily have bzr
<psusi> as for what file, it was the polkit file... I can't recall exactly now but it was something like /usr/polkit-1/actions/org.freedesktop.cpufreq-selector
<psusi> I found where that file was in the source and changed the auth_admin_keep line to yes, and rebuilt... but that file does not seem to make it into the binary paackage
<seb128> psusi, the -data binary has it as said before
<diwic> psusi: It would be cool to make a system which uses git/bzr and created quilt patches directly from the commits instead of having yet another indirection layer
<seb128> psusi, did you install that one too?
<psusi> hrm... I didn't notice an additional .deb in the pbuilder directory... maybe I missed it
<psusi> that reminds me, isn't pbuiolder supposed to allow non root users to build packages via fakeroot?  so why do I always have to sudo it?
<psusi> ohh, and is there something wrong with dpkg these days?  it seemed to be taking AGES to install the dep packages last night in pbuilder... I noticed a thread about a massive slowdown on debian-dpkg, but it seems to be talking about a newer version that is in lucid
<persia> psusi: Yes.  A fix has been uploaded.
<persia> (for lucid)
<psusi> ohh... got a bug #?
<psusi> or I can go search for it...
<seb128> psusi, #537241
<psusi> ohh, so we DID backport the damn fsync patch to dpkg
<cjwatson> yes, because there was a bug with 200 duplicates fixed by it
<psusi> really?  what is that?  seems like the underlying bug is the default mount options for ext4 are dangerous
<pitti> ugh, that reinstall of my laptop took ages; now I mean what cjwatson meant with "dpkg performance regression"..
<psusi> yea, it's like a 10-50x slow down
<pitti> psusi: hm, I can't say without seeing your changes, I'm afraid
<pitti> psusi: ah, seems you already discussed that; but please don't change it in gnome-applets
<psusi> pitti: why is that?  I seem to be missing something about how that file gets from gnome-applets to /usr/polkit-1/actions.. I don't really understand polkit
<psusi> on the dpkg thing, last night when I had pbuilder build gnome-applets, it took like 5-10 minutes to install the dep packages, then only like 20 seconds to actually build gnome-applets... ssd = very nice, that dpkg sync patch = very bad
<pitti> psusi: there's no magic; it's just a file put into the .deb, which is built by the source
<psusi> pitti: I would have thuoght, but it iddn't get updated when I installed the new package, and when I did a dpkg -L, the file was not listed as belonging to the package... so I did a dpkg -x and sure enoguh, the file was not in there
<pitti> $ dpkg -S /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy
<pitti> gnome-applets-data: /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy
<pitti> works here
<psusi> ahh... ok, I must have missed the -data binary
<psusi> ohh, in fact, I know why I did... I was only looking for amd64, it's probably an _all
<cjwatson> psusi: please see debian-dpkg, I'm not going to repeat myself at that kind of length here :)
<cjwatson> anyway, the relevant small part of the patch has been reverted, so there's no need to continue to rant about how dreadful it is
<psusi> now you seem to not want to change it in the source because a server might not want that change?  but the change only allows INTERACTIVE users access, so for a server the only interactive user ever there shuold be the admin
<pitti> psusi: yes, it's Arch: all (as most of the -data packages, otherwise having them wouldn't make sense)
<pitti> psusi: you might also want to not have those policies in a business environment; having a separate package (1) is more flexible, and (2) avoids delta to Debian/upstream
<psusi> hrm... why is debconf hardly ever used?  it seems like this is the sort of thing that debconf should ask you when yuo install or reconfigure it, at least if you use the correct question priority level
<psusi> couldn't you set up debconf to have a low priority question to override it, and otherwise default to auth for server and yes for desktop?
<pitti> psusi: you'd have to debconfize many packages then, though
<psusi> what do you mean?
<pitti> and (1) we don't show debconf by default, and (2) most desktops are installed with the desktop CD, where pacakges don't get "installed" in teh dpkg/debconf sense
<pitti> psusi: you'd have to apply this to udisks, gnome-applets, gnome-panel (for the time setting), etc.
<psusi> I thought 1) the default was to ask only high priority questions at install, medium at manual instal, and low only get asked when you explicitly say so at install or reconfigure, and 2) since it would be a low priority that wouldn't really matter since they would need to explicitly dpkg-reconfigure and ask for low priority questions
<pitti> but if most people don't see it at all, why bother?
<psusi> ohh, right, because you're trying to bundle up changes to all of them at once...
<pitti> I think we should just configure servers and desktops with sane default permissions
<psusi> because isn't this kind of the purpose of debconf?  so that when I as a user go, why is this thing not set up the way I want?  let me see what debconf options I can tweek...
<pitti> debconf has never been really entailed by ubuntu, though
<pitti> erm, "adopted"
<psusi> yea... I've noticed, and find it kind of disappoiinting
<cjwatson> yes it has, just in contexts other than the default desktop
<psusi> well I know there have been a few times I've installed daemons on servers and wondered why I get no configuration options even on low priority debconf ;)
<pitti> psusi: on servers you'll see a few, for example mysql
<pitti> or web apps asking for an admin password or so
<cjwatson> obviously there are going to be exceptions, but we have not in general ripped out debconf questions that are in place in Debian
<psusi> yea, I've seen one or two high priority questiosn, but never medium or low
<pitti> psusi: right, our default priority is "high"; everything else below that isn't shown by default
<psusi> right, but even if I do a dpkg-reconfigure and ask it to show me low, nothing new shows up
<psusi> seems nobody bothers writing medium or low priority questions, probably because they assume nobody will ever see them
<psusi> cjwatson: rename() resulting in a file size of 0 after a crash problem that the sync patch seems to try to fix seems to have an ext4 mount option to fix: auto_da_alloc
<mdeslaur> siretart`: take a look at bug #539555
<ubottu> Launchpad bug 539555 in ogmrip "mencoder crashed with SIGSEGV in x264_nal_encode()" [Undecided,New] https://launchpad.net/bugs/539555
<mdeslaur> siretart`: mplayer in lucid isn't compatible with the x264 version in lucid it appears
<siretart`> mdeslaur: seems I need to backport more if not all of libmpcodecs/ve_x264.c. thanks for notifying me
<siretart`> mdeslaur: btw, any news on the ffmpeg patches?
<mdeslaur> siretart`: nobody assigned additional CVE numbers for the other issues. There were a couple of those CVEs that didn't seem to have patches associated to them in lucid...I was waiting to see what you thought of that
<mdeslaur> siretart`: did you get a chance to look at the CVEs that didn't seem to have patches in my email?
<mdeslaur> siretart`: ie: issue 16, 21 and 22?
<siretart`> oh right, the ball was in my camp. sorry, I didn't find time to look up the CVE numbers.
<siretart`> that time, I rather focused on roundup issue numbers and svn commits
<siretart`> now I have to match theses to your issues, which is terribly time consuming :(
<mdeslaur> siretart`: yeah, thanks for that
<mdeslaur> siretart`: actually, I gave you the list with everything already matched up
<mdeslaur> siretart`: the quoted part at the bottom of the email has the upstream commits, and the top part in my email has your corresponding patches in lucid
<siretart`> that list didn't contain svn commits in trunk, did it?
<mdeslaur> siretart`: yes! take a look at the quoted part at the bottom
<mdeslaur> siretart`: well, it's from upstream trunk, not your repo
<siretart`> yes, your mail links to mans git-svn import, that's at least straight forward to map
<siretart`> yes, I'll see that I can tackle this tonight
<mdeslaur> so, if we can decide what to do with the 2-3 missing patches, I'll then release updates for hardy-karmic
<siretart`> great!
<mdeslaur> with the existing list of CVE numbers
<mdeslaur> siretart`: again, thanks for your excellent work in pulling out all the patches :)
<jibel> psusi, from the tests I've done the auto_da_alloc doesn't prevent the 0 length problem, at least with dpkg
<psusi> jibel: really?  with data=ordered?
<psusi> because the man page specifically says: This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that  can happen  when  a  system  crashes  before  the delayed allocation blocks are forced to disk.
<jibel> psusi, yes with data=ordered
<psusi> hrm... sounds like a kernel bug then...
<jibel> psusi, it's written in the man page but it doesn't in the case of dpkg.
<cjwatson> there's no way dpkg can rely on kernel options anyway.
<jibel> psusi, no necessarily , you'd better talk with dpkg dev who knows dpkg's code path better than me.
<psusi> it should be able to rely on the filesystem not being broken though...
<cjwatson> "broken" is, apparently, a matter of opinion.  (yes, I know, and I have *my* opinion, but it apparently isn't shared by e.g. POSIX.)
<cjwatson> this was discussed at enormously tedious length last year ...
<jibel> psusi, you'll encounter this problem with all fs supporting delayed allocation.
<cjwatson> I agree that enabling auto_da_alloc by default would be sane, if it isn't already
<cjwatson> but if it doesn't entirely fix things for some arcane reason ... wewll
<cjwatson> *well
<psusi> then they are all broken... historically many applications have relied on rename() to provide an atomic replace... hell, even Microsoft wrote NTFS to detect this and make sure it worked properly
<cjwatson> I agree that any filesystem that does not treat rename() this way is *at best* wilfully ignoring 40 years of Unix history
<ScottK> Willfully ignoring history seems to be the order of the day (thus the KibiByte).
<cjwatson> and is only useful for specially written applications
<cjwatson> noting that e.g. shell scripts can't do the fsync thing
<psusi> indeed... and the read only mount flag no longer meaning read ONLY
<cjwatson> anyway, I stated my opinion on debian-dpkg.  dpkg should do its best to mitigate these issues up to some point that doesn't kill performance too badly, but there's a point where it becomes a kernel configuration problem.
<psusi> indeed
<jibel> cjwatson, I totally agree
<psusi> but if that mount option does not fix it then it seems it should be reported upstream as a kernel bug since it says it should
<stgraber> geser: ping, DMB meeting
<cjwatson> sure, somebody who has something more resembling a test case should push it upstream :)
<cjwatson> I just want to make it not suck for lucid
<directhex> mmm, i like the bootsplash i'm seeing on the laptop right now. the fsck message is rather more slick than it was in karmic
<psusi> I guess the unfortunate thing is that relying on rename() being a barrier is itself just a workaround to the filesystem apis lacking means to control barriers
<jcastro> directhex: yeah I just ran into a fsck the other day, it's quite lovely
<doko> seb128: http://blogs.gnome.org/alexl/2009/09/21/archer-gdb-macros-for-glib/  are these packaged?
<directhex> jcastro, haven't updated today, mind... it's a bit less pretty on the nvidia-based desktop
<seb128> doko, no
<jcastro> directhex: it's a tradeoff, do I want pretty boot or vdpau ... :)
<seb128> doko, debian don't install those because they "need an experimental gdb version"
<seb128> doko, I can change that in the next upload if we want those now
<doko> seb128: that would be nice
<seb128> doko, ok, will do after beta1
<amitk> Keybuk: have you had a change to look at bug 527666?
<ubottu> Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666
<Keybuk> amitk: I don't look at LVM bugs generally
<amitk> Keybuk: it contains mountall with --debug info
<Keybuk> so?
<Keybuk> it's unlikely to be a mountall issue
<Keybuk> it's more likely it's in fstab wrong, or LVM is configured wrong
<amitk> Keybuk: errm, you asked for it last time it was reported on ubunt-devel
<Keybuk> usually to prove it's not a mountall issue ;)
<highvoltage> Keybuk: the text plymouth theme is awesome!
<amitk> Keybuk: heh, ok. But 3-4 people are seeing this bug consistently. I guess I need to find someone who will look at LVM.
<Keybuk> amitk: sadly, without cloning, I'm just not able to look at all of the bugs that I'm a perfect person to look at
<Keybuk> there are too many bugs, and I'm the perfect person to look at too many different things
<Keybuk> and I'm not sure cloning would help, I'd just end up making out with myself :p
<Keybuk> highvoltage: I love how many people it's confusing
<cjwatson> narcissist
<jcastro> plus every subsequent clone would be worse, so after 3 or 4 you'd start creating more bugs I'd guess
<Keybuk> I actually had someone try and debug why the logo filename wasn't being picked up - they hadn't realised it was entirely faked :)
<highvoltage> Keybuk: hah! so they thought it was like an alt="" in an <img
<Keybuk> highvoltage: yes ;)
<highvoltage> awesome.
<Keybuk> exacty that in fact
<Keybuk> I do have the VGA 16 theme working now too
<Keybuk> that looks kinda neat
<Keybuk> though I can't decide whether it looks better with Flloyd-Steinberg or without
 * highvoltage racks brain to remember closest colour in aubergine to VGA16
<highvoltage> to aubergine, even
<Keybuk> highvoltage: just reprogram the VGA to know about aubergine
<highvoltage> ah, ok.
<Keybuk> though it looks quite fetching in MAGENTA http://twitpic.com/18nmqr
<highvoltage> Keybuk: but that won't work on EGA displays will it!?
<highvoltage> (sorry I shouldn't try to be ironic)
<directhex> i get a text-only boot :(
<Keybuk> highvoltage: I don't think they've ever made a 386 with EGA
<highvoltage> Keybuk: I've seen some, but I'm not sure whether they were sold like that
<Keybuk> for a start, I haven't seen any monitor with an old EGA connector in decades
<highvoltage> yes they died out quite quickly.
<ccheney> well VGA apparently came out in apr 1987 so some really old 386 had them but probably not too many
<tseliot> Keybuk: maybe you can try with purple? #800080
<tseliot> i.e. 128,0,128
<amitk> kirkland: bug 527666
<ubottu> Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666
<Keybuk> tseliot: for the vga16 stuff, I just reprogram the palette now
<Keybuk> so it's ubuntu aubergine
<xhaker> bdrung_: hi. is Eclipse 3.5.2 in the plan for inclusion in lucid? (noticed the merge in git)
<bdrung_> xhaker: yes
<tseliot> Keybuk: ah, nice. Does the logo look ok now?
<bdrung_> xhaker: we try to release 3.5.2-1 to debian really soon and sync it then
<Keybuk> tseliot: mostly, still fiddling with it
<Keybuk> tseliot: haven't released it yet because there are bugs with text mode I want to fix first ;)
<ccheney> anyone know how to modify a symbols file to work on multiple architectures? i backported webkit and it builds fine on amd64 but fails on i386 due to missing symbols, can i just add the i386 symbols (i would think it would then complain on amd64)?
<tseliot> Keybuk: good idea ;)
<siretart`> ccheney: depends :-)
<cjwatson> you can put architecture tags in the symbols files if that's appropriate.  see man dpkg-gensymbols
<ccheney> cjwatson: thanks, guess i need to look at each arch to see what it complains about to determine what to add to its specific symbol file
<siretart`> ccheney: for some libs it might be worth first checking if it really only exports symbols that are supposed to be exported
<xhaker> bdrung_: thanks
<ccheney> siretart`: ok
<tkamppeter> pitti, hi
<tkamppeter> rickspencer3, hi
<rickspencer3> hi tkamppeter
<pitti> hi tkamppeter
<tseliot> directhex: do you know anything about #536925 ?
<tkamppeter> pitti, I have seen you have worked on SRUs (moving verified packages to -updates), did you forget bug 293832?
<ubottu> Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832
<directhex> bug 536925 ?
<ubottu> Launchpad bug 536925 in mono "docky gmail checker is unable to connect to gnome-keyring" [Undecided,Confirmed] https://launchpad.net/bugs/536925
<directhex> tseliot, i don't know anything about it. i could take a look. the docky bug report seems entirely unhelpful
<tseliot> directhex: basically it doesn't seem to be able to access gnome-keyring. Is there anything else that you need to debug it?
<directhex> tseliot, running it from a console might help give some diagnostic output, but as i said, the developers seem actively unhelpful. "broken" as a term should be banned from launchpad
<directhex> tseliot, i can believe that there's an incompatible change to gnome-keyring, since adobe air apps are broken, but i see no evidence of any commits to g-k-s's svn repo for about a year
<pitti> tkamppeter: hm, there is no poppler upload in the queue
<tseliot> directhex: the console output is here: https://bugs.launchpad.net/docky/+bug/456166/comments/12
<ubottu> Launchpad bug 456166 in docky "gmail applet doesn't work" [Low,Fix released]
<tseliot> directhex: are you sure that libgnome-keyring1.0-cil hasn't changed recently?
<tseliot> recently = since karmic
<Laney> not substantively
<directhex> tseliot, only a build fix.
<tseliot> ok
<directhex> http://changelogs.ubuntu.com/changelogs/pool/main/g/gnome-keyring-sharp/gnome-keyring-sharp_1.0.0-2/changelog
<mathiaz> zul: hi - do you have any idea why ubuntu-server is a bug contact for the beautifulsoup package?
<zul> mathiaz: because it was apart of the lucid mir spec
<directhex> eek, and g-k-s is hand-rolled, not just gapi
<tkamppeter> pitti, there is a debdiff of poppler, as I cannot upload poppler.
<directhex> tseliot, it looks an awful lot like g-k-s 2.29 is incompatible with earlier versions, yet upstream didn't touch the soname. i.e. a big fat dollop of stupid.
<tseliot> directhex: ouch
<pitti> tkamppeter: ok, I'll sponsor in a bit
<Keybuk> bryceh, tjaalton: can you think of any hardware that nouveau actually works on OOI?
<mvo> james_w: moving to here because of the meeting in #ubuntu-desktop -- yes, I tested it a couple of times and it seems to work. I have not been able to reproduce the race so I can not say if it really fixes it, but from looking at it it appears it will
<tjaalton> Keybuk: my 8600gt works
<Keybuk> tjaalton: what hardware?
<Keybuk> this Dell Latitude D620, with nVidia G72M (7300?) just gets corrupt screen
<directhex> tseliot, developer resources will need to be spent cleaning up the g-k-s mess. but, i repeat, it's not unique to g-k-s, since adobe air apps no longer function either (as air cannot talk to the new gnome-keyring either)
<tjaalton> Keybuk: it's a desktop
<tjaalton> some intel chipset
<tjaalton> core duo
<tseliot> directhex: ok, I hope we don't release Lucid with this problem (unfortunately I wouldn't know where to begin with this bug)
<tjaalton> Keybuk: try without splash, that helps some people
<directhex> tseliot, assuming gnome-keyring isn't going to revert its incompatible changes, and nobody cares about the false soname it uses, then someone needs to port gnome-keyring-sharp to the new api
<Keybuk> tjaalton: I'm trying to *debug* the splash! :D
<tseliot> directhex: do we have a bug report filed upstream?
<directhex> tseliot, which upstream?
<Keybuk> tjaalton: I need to find something that nouveau modeset works on, so I can figure out why plymouth is having issues
<tseliot> directhex: gnome-keyring perhaps? Or whoever works on the bindings
<tjaalton> Keybuk: hah, of course :s
<seb128> hum
<seb128> Keybuk, cjwatson, slangasek: the check disk item from the livecd doesn't reboot on key press as it should, is that a known issue?
<seb128> is that a plymouth bug?
<Keybuk> there's one open about that
<cjwatson> it would either be plymouth or casper.  there's an open bug about casper not rebooting properly at the end of installation, but I'm not sure about after CD checking
<Keybuk> I think it doesn't get space or enter or something
<Keybuk> but gets random other keys
<seb128> well the text says "press any key"
<seb128> or it seems to work with random keys
<seb128> Keybuk, cjwatson: ok thanks
<cjwatson> I don't suppose it's in raw mode and failing to do scancode->keycode translation?
<cjwatson> that's the sort of thing that could appear to permute the keymap bizarrely
<Keybuk> plymouth always has the keymap in raw mode I think
<doko> seb128: the glib integration should only require gdb-7.0, which is in testing as well
<seb128> doko, ok thanks
<Keybuk> cjwatson, apw: so I talked to Ted about the O_PONIES, fsync, dpkg thing
<Keybuk> he can think of no reason that we need an fsync() in that path, except for crash-safe-ness
<Keybuk> there is absolutely no race if the power stays on
<cjwatson> right, I backed out that fsync already
<Keybuk> which makes sense
<tkamppeter> mvo, hi
<apw> Keybuk, good i was starting to think unix semantics were rubbish
<cjwatson> and I mailed a long semi-rant to debian-dpkg trying to clarify the desired semantics
<Keybuk> apw: I was confusing wiht the following
<Keybuk> open file, write, write ... other process doesn't see anything yet
<cjwatson> http://lists.debian.org/debian-dpkg/2010/03/msg00041.html
<apw> yeah that makes sense
<Keybuk> it might see a zero-byte file, but no data
<Keybuk> but that's different
<Keybuk> cjwatson: only one thing is wrong in that post
<Keybuk> since Essential packages are required
<Keybuk> to work at all times, even when semi-unpacked
<Keybuk> --
<Keybuk> no they bloody well are not ;)
<Keybuk> they are required to work when unpacked
<Keybuk> not semi-unpacked
<cjwatson> I wasn't sure about the exact requirement, but I know from things Ian has said in the past that the intention was to make sure that dpkg itself didn't do anything that could render your system unbootable if you had a power failure in the middle of dealing with an Essential package
<cjwatson> policy says "must be available and usable on the system at all times"
<cjwatson> (and qualifies that with "unconfigured (but unpacked) state", but that's the main body of the requirement)
<Keybuk> if you're semi-unpacked, you have different versions of files for the package over the filesystem
<cjwatson> I didn't say it was easy, or that everything got it right :)
<Keybuk> just seems a mad requirement to me
<Keybuk> and since I know for a fact that dpkg itself could never survive that ... ;P
<Keybuk> (dpkg and dpkg-deb tend to need to be the same version <g>)
<cjwatson> most essential packages are relatively simple packages with self-contained binaries.  there are a few things that are harder
<Keybuk> completely aside for a moment
<Keybuk> my installed cmdline was
<Keybuk>         append initrd=desktop/initrd.lz boot=casper netboot=nfs nfsroot=10.15.0.192:/var/lib/nfsroot/desktop only-ubiquity automatic-ubiquity debug-ubiquity ubiquity-debug file=/cdrom/daily/mario.seed quiet splash -- nouveau.modeset=0
<Keybuk> but after install, it hasn't copied nouveau.modeset=0
<Keybuk> that's a bug, right?
<cjwatson> yeah, that's odd
<cjwatson> definitely a bug
<cjwatson> hmm, I seem to have forgotten to make that change to grub-installer
<cjwatson> I think there's a bug about this already, it sounds familiar
 * hyperair is looking for a kind archive admin to take care of a sync..
<Keybuk> hyperair: we're in beta freeze
<hyperair> Keybuk: does that mean no syncs?
<seb128> hyperair, syncs bypass the queue
<hyperair> seb128: what queue?
<seb128> so no sync if not really required no
<Keybuk> hyperair: it means follow the procedure and request through the usual channels
<seb128> hyperair, the freeze one
<hyperair> ah
<seb128> hyperair, during freeze uploads go in a moderation queue
<hyperair> it's banshee
<cjwatson> Keybuk: I can't find the bug for this, so if you could file it on grub-installer, make it lucid/beta-2 and assign it to me, that would be good
<Keybuk> sure
<cjwatson> thank
<cjwatson> s
<Keybuk> tjaalton: so, with this card, I boot with mode setting enabled - and I just get a very pretty corrupt screen
<Keybuk> tjaalton: how would I debug this?
<sebner> hyperair: banshee \o/
<hyperair> =)
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> Any dbus expert around?
<pitti> tkamppeter: what's the actual problem?
<tkamppeter> pitti, I am sending a D-Bus signal:
<tkamppeter> dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin
<tkamppeter> update-notifier should catch it and start a program. This does not happen.
<tkamppeter> pitti, for you to test it, do "sudo -s", then "echo /usr/bin/gedit > /usr/bin/hplip-plugin-ubuntu" and then "exit"/
<tkamppeter> and sudo chmod +x /usr/bin/hplip-plugin-ubuntu
<pitti> tkamppeter: why would u-n catch a signal  sent to hplip?
<tkamppeter> pitti, update notifier has the following code: http://pastebin.ubuntu.com/396286/
<tkamppeter> AFAI understand, the hplip_init() function, which is called when update-notifier starts, makes a D-Bus Listener out of update-notifgier.
<seb128> tkamppeter, hi
<seb128> tkamppeter, have you seen bug #530218?
<tkamppeter> update-notifier runs as a daemon, with my user rights.
<tkamppeter> Seems that ubottu has left for the day ...
<ubottu> Launchpad bug 530218 in system-config-printer "PrinterDriversInstaller service: AccessDenied error" [Low,Confirmed] https://launchpad.net/bugs/530218
<tkamppeter> seb128, I did not change anything on the DBus mechanisms of s-c-p, seems that some policies of our distro have changed.
<tkamppeter> pitti, is this D-Bus code correct?
<mdeslaur> a|wen: I was just building the mediawiki packages :)
<mdeslaur> a|wen: is only hardy and intrepid affected by the regression?
<tkamppeter> And also the command?
<tkamppeter> pitti, I have also tried
<tkamppeter> dbus-send --system --dest=com.hp.hplip --print-reply --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin
<tkamppeter> and then dbus-send hangs until a timeout happens.
<a|wen> mdeslaur: cool :) the fix was introduced by the CVE-2009-0737 fix present in hardy, intrepid and jaunty ... i'm looking into jaunty now
<ubottu> Multiple cross-site scripting (XSS) vulnerabilities in the web-based installer (config/index.php) in MediaWiki 1.6 before 1.6.12, 1.12 before 1.12.4, and 1.13 before 1.13.4, when the installer is in active use, allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0737)
<mterry> slangasek, in recent cryptsetup, you added a hard dependency on plymouth.  To reduce extra messages to the console, apparently.  Can that not be done in a less plymouth-inducing way?
<mdeslaur> a|wen: hmm...the part of the patch you are removing is present in karmic and lucid...do you not need to encode $conf->DBtype?
<cjwatson> mterry: plymouth doesn't necessarily mean splash screen.  its purpose is in part to be a multiplexer for user interaction during boot, and we don't want to have multiple paths for that since it tends to create bugs
<mterry> cjwatson, understood.  I'm working on a project that doesn't want plymouth, so I was curious why the decidedly non-dependency was listed as such.  Seems like an issue for seeds, not fake Depends
<jdong> it's not a fake Depend if the upstart job / init script logs startup items via plymouth...
<Keybuk> mterry: why don't you want plymouth?
<mterry> jdong, oh, I didn't notice it doing that
<persia> mterry: Can you just use a text theme and pretend?
<mterry> Ideally I'd use plymouth.  But for the nonce I'm not.  And was curious why cryptsetup was requiring it.  Regardless of why I don't want plymouth, I think the critique stands
<tkamppeter> pitti, still there?
<a|wen> mdeslaur: the variable is already being quoted in config/index.php in hardy/intrepid while it isn't in the newer versions; looks like the handling has changed between 1.12 and 1.13... removing the quoting could work as well afaict; maybe that indeed is a better approach
<Keybuk> mterry: because we use plymouth to marshal input and output of the console during boot
<Keybuk> cryptsetup is run asynchronously on block device detection
<Keybuk> so you may need to ask for the passphrase for two different devices at the same time
<Keybuk> meanwhile mountall might be running fsck on a third block device
<Keybuk> so needs to display progress
<Keybuk> or may even need to tell you fsck failed, and ask whether you'd like to try again with --fix
<a|wen> mdeslaur: just tested; jaunty isn't affected
<Keybuk> plymouth deals with that for us
<Keybuk> we ask plymouth to ask
<Keybuk> it queues up the things wanting input
<Keybuk> and ensures things are displayed at different points on the screen
<Keybuk> it's one of the *main* reasons we're using it
<mterry> Keybuk, yar.  I agree those are all good arguments for why I should be using plymouth.  But not quite for why cryptsetup should hard-depend it
<mterry> Keybuk, vs, say the seed
<directhex> tseliot, i have a VERY full timetable this evening, but i'll try to look at g-k-s later
<mterry> Keybuk, unless asking for input just doesn't work at all without plymouth?
<Keybuk> mterry: because cryptsetup hard-depends on it
<Keybuk> all of the methods of asking for input without plymouth *cause* bugs
<Keybuk> so we've removed them
<Keybuk> ie. "crash your X server" bugs
<mterry> Keybuk, oh.  my quick grepping indicated it was always careful to [ -x /usr/bin/plymouth ]
<mterry> Keybuk, i see
<Keybuk> so you want plymouth :p
<highvoltage> Keybuk: any chance you could smack together some documentation or quick notes so that we can get the plymouth (and text-based plymouth) right for Edubuntu?
<mdeslaur> a|wen: I can't seem to locate where you say it's already being quoted in intrepid...
 * directhex is on text-based. sniff.
<Keybuk> highvoltage: see the log of this chanel
<Keybuk> earlier today
<highvoltage> Keybuk: ok, will do
<Keybuk> or the log of -desktop within the last hour
<a|wen> mdeslaur: in toggleDBarea('<?php echo Xml::encodeJsVar( $conf->DBtype ); ?>', ...  Xml::encodeJsVar( $conf->DBtype ) does in itself quote the variable
<mdeslaur> a|wen: but, that's the part your updated patch is removing
<JFo> pitti, had another bug reporter send me an odd error when trying apport-collect. I just sent it out via our e-mail thread from the other day.
<mdeslaur> a|wen: you're changing it back to: toggleDBarea('<?php echo $conf->DBtype; ?>'
 * psusi wonders why /etc/init/failsafe-x.conf is installed on server with no x or gdm
<a|wen> mdeslaur: true; there is two options to fixing the regression ... either we should skip the Xml::encodeJsVar or we should skip the quoting (in jaunty onwards the quoting is gone) ... currently i prepared the first option, but i'm considering if the second might be better
<a|wen> mdeslaur: i'll prepare a new set of patches using the second option and test them
<mdeslaur> a|wen: ok, cool.
<genii> Is there any plan to configure IRC default channel by way of localisation? eg: spanish install goes to #ubuntu-es     etc etc ?
<kklimonda> I use Linux at work, and have a Mac at home, and there is a lightyear sized gap between the two in useability. Example - I'm trying to set up an IRC chat program for a friend. I click on an "import accounts" button to transfer accoutns from another chat app already on the system. Nothing happens. No message, no indication that there was a problem, nothing.
<zyga> mvo: hi
<kklimonda> oh crap..
<kklimonda> sorry
<zyga> mvo: do you have the time to help me with the UVF exception process we talked about last time?
<pitti> ev: I'm not quite sure what bug 537986 is about -- what is the "superfluous help text"? isn't that a label as well?
<ubottu> Launchpad bug 537986 in ubiquity "Freeze exception request: inactive labels on the user setup page." [Undecided,New] https://launchpad.net/bugs/537986
<tjaalton> Keybuk: I haven't done much kms debugging, but unless it's completely hung maybe a sysrq-trace might give some ideas?
<pitti> ev: and since the screenshot also has a label with an explanatory text, how does it differ in practice?
<tseliot> directhex: thanks a lot
<pitti> ev: oh, nevermind, I understand
<a|wen> mdeslaur: new version of the regression fixes uploaded to bug 537974
<ubottu> Launchpad bug 537974 in mediawiki "1.15.2 security update released; CSS validation issue" [Undecided,Confirmed] https://launchpad.net/bugs/537974
<tjaalton> psusi: because it's installed by x11-common, which belongs to the standard task
<Keybuk> tjaalton: bryce thinks it's a modeline isasue
<tjaalton> Keybuk: but if kms works without plymouth?
<mdeslaur> thanks a|wen
<Keybuk> tjaalton: kms does not work at all
<tjaalton> Keybuk: ok then :)
<Keybuk> bug #539730 fwiw
<ubottu> Launchpad bug 539730 in xserver-xorg-video-nouveau "[G72M] Screen corruption when using KMS. Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300" [Undecided,New] https://launchpad.net/bugs/539730
<mvo> zyga: yes, let me quickly check the bug reference again
<tkamppeter> mvo, hi
<mvo> tkamppeter: hello
<zyga> mvo: thanks! it's bug 538306
<ubottu> Launchpad bug 538306 in command-not-found "[ffe] command-not-found 0.2.41" [Wishlist,New] https://launchpad.net/bugs/538306
<persia> genii: It would need a patch to each IRC client.  Needs a bug for discussion.
<zyga> mvo: BTW if it's too late today we can postpone this, I understand, people have life apart from their fun/work/etc :-)
<mvo> zyga: no worries, should be ok now. I think the outstanding items are "does it build, install/upgrade, not break"
<mvo> zyga: the later one is a non-issue because command-not-found has no rdepends
<zyga> mvo: right, okay, should I put a link to the ppa?
<mvo> zyga: yes
<zyga> the upgrade process could do one more thing though
<mvo> zyga: and maybe a script(1) log of installing it
<mvo> and that it does not fail then
<zyga> it could move the barely used .command-not-found.blacklist to XDG_CONF_DIR/commant-not-found/blacklist.conf
<zyga> but the old path is still supported
<zyga> so this step is not required, just it could be a tiny bit better
<zyga> hmm, I'll check out script
<zyga> what about pbuilder?
<tjaalton> Keybuk: yeah the timings are probably wrong
<tkamppeter> mvo, I have a problem with update-notifier, it does not react to the D-0Bus signal of HPLIP.
<Keybuk> tjaalton: that's just trial-and-error to get right though isn't it? :-/
<mvo> zyga: script would just create a "log" that installing from the PPA works just fine, pbuilder is not needed, the ppa builds it already in a pbuilder like environment
<tjaalton> Keybuk: well the devs probably know best.. too bad it's hard to test mainline .34rc1 because the api changed so you'd need to update libdrm and -nouveau too
<zyga> mvo: ok, I'll post a apt-get dist-upgrade session with to ppa package and point to the archive, do you think that is all I should add>
<mvo> tkamppeter: hm, I think it needs a slightly different way to send the singal from hplip. did you had a chance to discuss this with upstrema yet?
<mvo> tkamppeter: are they fine with us adding a "official" signal?
<mvo> zyga: I think that should be enough
<mvo> zyga: let me know when its there, I will add a note too
<zyga> ok thanks, let me add those changes now
<slangasek> mterry: short of a plymouth magic patch to capture and eat all console messages, no, it can't
<tjaalton> Keybuk: (noticed you were asking for it on #u-k)
<Keybuk> tjaalton: yeah, even .33 would be nice
<Keybuk> but apparently we don't build our mainline kernels against the lucid config
<Keybuk> which I keep forgetting
<Keybuk> slangasek: there is that magic, I just haven't turned it on yet
<tjaalton> why does it matter?
<tjaalton> .33 mainline should work fine
<Keybuk> tjaalton: because karmic's config doesn't enable nouveau, amongst other things
<tjaalton> karmic?
<slangasek> ah, didn't know it was written
<tjaalton> Keybuk: oh, the mainline config doesn't, yes
<Keybuk> slangasek: yeah, it redirects console output into /var/log/boot.log
<tkamppeter> mvo, I think I should get the full chain working and then I send a patch to upstream.
<tjaalton> Keybuk: just to make sure; it's the same without splash?
<tkamppeter> mvo, currently I send the signal via
<tkamppeter> mvo: dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin
<tkamppeter> The command runs as root.
<psusi> hrm... is there no way to query init for what events a job is waiting for?  or do you just have to read the conf file?
<tkamppeter> mvo: To avoid adding another library dependency, I let HPLIP run this command line.
<mvo> tkamppeter: right, I think the best way is to run it via the existing dbus service that hplip already ships, but that needs a bit of work on the hplip code. I'm currently looking at bug #516727, but when I finished with that I can have another look
<ubottu> Launchpad bug 516727 in apt "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Triaged] https://launchpad.net/bugs/516727
<Caesar> slangasek: what do you think about bug 539814 in terms of severity?
<ubottu> Launchpad bug 539814 in tar "Impossible to bootstrap Lucid on Dapper" [Undecided,New] https://launchpad.net/bugs/539814
<Keybuk> tjaalton:  yes ;p
<slangasek> Caesar: middling
<slangasek> Caesar: certainly not a beta-1 blocker
<Caesar> I'm chatting to bdale now to see if it can get fixed in sid
<slangasek> pitti: bug #539742 seems to be the same as the earlier "plymouthd still running" apport reports, except it didn't match the bug pattern and also doesn't include the new information from the updated hook?
<ubottu> Launchpad bug 539742 in plymouth "does not terminate at computer shutdown" [Undecided,New] https://launchpad.net/bugs/539742
<Caesar> Actually, it might be fixed in sid already
<zyga> mvo: as for c-n-f if the freeze exception works and we get 0.2.41 in the beta this will be a good way of checking if my choice of having auto-install option default to 'ask' was a good idea
<slangasek> Caesar: from lamont, I recall that there are other bits of lucid that are unhappy on a dapper kernel, fwiw
<slangasek> I think the solution there was "go through a lot of pain to get a hardy kernel running on the powerpc buildds"
<Caesar> Fun
<tjaalton> Keybuk: ok.. but did kms ever work with these?
<Keybuk> tjaalton: with this machine?  not that I know of
<tjaalton> Keybuk: what about the ati?
<Keybuk> tjaalton: likewise, not that I know of
<Keybuk> both worked in karmic
<tjaalton> ok
<Keybuk> but in lucid, neither works
<lamont> slangasek: karmic, actually
<slangasek> lamont: mmk
<lamont> amusingly, the only machine that hates that kernel is davis
<NCommander> lamont: what was the problem with karmic/lucid on davis? Oops?
<Caesar> slangasek: I think this particular issue is fixed in sid's tar (1.23)
<lamont> NCommander: yep.  and if you can tell me how to get a serial console on the box, I'll capture the oops output for you
<NCommander> lamont: is the serial port seen in dmesg? (or is /dev/ttyS0 exist?)
<lamont> yep
<tjaalton> Keybuk: you can try .33 mainline with ati though
<Keybuk> tjaalton: I can ;)
<NCommander> lamont: https://help.ubuntu.com/community/SerialConsoleHowto
<kklimonda> has the UnitsPolicy been discussed with other distributions and is a coordinated plan or are we doing that alone?
<lamont> NCommander: that's great.  now answer the question for yaboot
<NCommander> lamont: you want the bootloader on serial? That requires a trip to OpenFirmware land
<NCommander> lamont: power cycle the machine and hold down option-command-o-f to get to the 0 > prompt
<Keybuk> tjaalton: though I have to share a power supply between the two boxes
<Keybuk> so I wanted to drain debugging on this one at least first
<Caesar> slangasek: I plonked tar 1.23-1 into the chroot and that worked
<lamont> NCommander: I don't recall all the iterations I went through trying to get there.  I do recall that it's annoying needing to wait for someone to get back to the data center to boot it because you can't adequately recover from just a remote console over kvm
<tjaalton> Keybuk: you can ask darktama on #dri-devel about the nouveau if you like
<NCommander> lamont: you have to set the output-device in openfirmware to ttya I believe on xserves
<Keybuk> tjaalton: I asked on #nouveau - no reply yet
<Keybuk> (not directly at darktama)
<Caesar> So I guess I should turn bug 539814 into a sync request for tar?
<ubottu> Launchpad bug 539814 in tar "Impossible to bootstrap Lucid on Dapper" [Undecided,New] https://launchpad.net/bugs/539814
<tjaalton> Keybuk: ah ok, yeah I asked on #dri-devel and airlied pinged darktama, think he's away atm
<NCommander> lamont: actually, you don't need OF access
<lamont> NCommander: it's a bit below my radar since the buildds have been surviving just fine with it.
<NCommander> lamont: well with OF and yaboot over serial (which a google search confirmed works properly on xserves), you shouldn't ever need anyone to remotely manage unless the battery goes dead :-/
<lamont> or the case is opened.. or... :-(
<lamont> but yeah, some specific education in that regard would not be amiss
<lamont> and I might even make time to test taht
<lamont> esp if we can get the thing to oops again
<pitti> slangasek: hm, that's strange indeed -- I'll investigate the pattern failure first
<pitti> slangasek: hm, weird; it seems to work for me here; I guess one could workaround that check by collecting information on an offline system, and reporting the .crash file from another one
<pitti> but that's not very likely
<pitti> I'll ask in the bug
<kees> lool, persia: either of you around and got a running qemu armel image?  nothing I try works.  :(
<superm1> pitti, re bug 537986, i believe it's to remove the really wordy labels that accompany the dialogs in exchange for labels that only show up in gray on the text boxes when the text boxes are empty
<ubottu> Launchpad bug 537986 in ubiquity "Freeze exception request: inactive labels on the user setup page." [Undecided,New] https://launchpad.net/bugs/537986
<pitti> superm1: right, I figured that out 30 secs after pinging ev.. but thanks for confirming
<NCommander> lamont: maybe during UDS if there isn't a rush to force something newer on that box
<lamont> it'll almost certainly have lucid by that point
<psusi> why are there multiple ttyX.conf files in /etc/init?  can't a single conf file manage multiple instances?
<Keybuk> yes
<Keybuk> hysterical raisins mostly
<psusi> lol... Mmm... raisins...
<psusi> Keybuk: there's no secret switch to initctl status to list exactly what the events are that the job is waiting for is there? ;)
<Keybuk> psusi: no, but I do intend to write one
<Keybuk> I can tell you how to find out
<psusi> heheh, would be nice ;)
<Keybuk> as long as you promise to tell *nobody*
<Keybuk> especially not kees
<psusi> lol
<psusi> ok?
<Keybuk> what you need to is write an upstart .conf file
<Keybuk> that crashes upstart
<Keybuk> but crashes it in the child when you try and run it
<Keybuk> then you have a core file with all the init daemon state in it <g>
<psusi> rofl
<Keybuk> exec a path that doesn't exist seems to work well atm
<Keybuk> you may need "expect fork" in there, depending on the version of upstart
<psusi> kill -ABORT, heh
<Keybuk> exactly
<Keybuk> or just drive it against an assertion
<Keybuk> if you can predict the pids, it's even better
<Keybuk> you can attach gdb to it
<Keybuk> and then you have a live process you can do things like
<Keybuk> (gdb) p job_hash_lookup (...)
<Keybuk> against
 * kees looks around for target of great vengence and furious anger
<Keybuk> that's what I tend to do
<psusi> hrm... I'm a bit confused... I thought an event was implemented internally as a job with no main process, so once an event has fired, it should still show up as a job in the started/running state?
<Keybuk> no
<Keybuk> you're confusing events and jobs
<Keybuk> they're completely different
<psusi> ahh, yep, that explains it...
 * kees doesn't know why he'd be upset about init children dumping core.
<lamont> kees: because root could pwn the box?
<lamont> oh wait.  nm. :-D
<kees> 'zactly
<Keybuk> kees: I'm just invoking you
<Keybuk> because you seemed to like it so much yesterday :p
<Keybuk> it's fun
<\sh> hmmm...I hope I didn't blow up our production environment right now with my puppet script
<kees> Keybuk: yup, I just need to formalize my strike-from-above phrases
<lool> kees: Sure
<kees> lool: what is the magic?  I'm ready to learn
<Keybuk> kees: I have a manual override built into the ion cannon control
<Keybuk> it's linked to my foursquare account
<lool> kees: https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
<kees> Keybuk: haha
<Keybuk> you can't fire it within 5 miles of my current location
<lool> kees: rootstock does basically that behind the scenes
<lool> kees: I start my rootfs with qemu-system-arm -m 256  -drive file=lucid.img,media=disk -M versatilepb -cpu cortex-a8 -kernel linux-image-2.6.32-16-versatile_2.6.32-16.24/boot/vmlinuz-2.6.32-16-versatile -append 'root=/dev/sda rootwait'
<kees> Keybuk: I guess I'll use "beam weapon charging" for now
<lool> kees: I can upload the rootfs, but will take me a whilke
<lool> and it has installed crap in it
 * lool starts rsync
<kees> lool: I think it's the kernel that isn't working for me.
<lool> kees: just qemu-system-arm -m 256 -kernel <versatile-vmlinuz-from-lucid> -cpu cortex-a8 should work
<lool> kees: It might help to use serial console mode to see some debug messages, but really that should give you a SDL window with the fb output
<kees> lool: so not wget http://people.canonical.com/~lool/versatile-cortex-a8-zImage ?
<lool> kees: Oh no
<lool> kees: Well that might work
<kees> it's what the wiki says?
<kees> lool: which kernel image URL should I use?
<lool> kees: Sorry, it might work, not sure, but it's best to use the lucid one
<lool> http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/
<psusi> Keybuk: rc-sysinit.conf tests for FROM_SINGLE_USER_MODE... it looks like that's how rcS tells rc that the system has already been initialized, but I can't see any way for rc-sysinit to run with FROM_SINGLE_USER_MODE=y
<lool> kees: Will update wiki, thanks
<lool> kees: image wasn't available back then
<Keybuk> psusi: did you read rcS.conf ?
<kees> lool: okay
<lool> kees: updated, thanks
<psusi> Keybuk: yes... it sets it when it switches to another mode, but AFAICS, switching to another mode invokes rc.conf, not rc-sysinit.conf
<kees> lool: how does the initrd figure in?
<lool> kees: You can also unpack the vmlinuz from the linux-image-versatile.deb obviously, and you'll find modules in there as well
<lool> kees: Sadly, initrds are borken (help welcome!) as well as initramfs
<lool> kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893
<ubottu> Ubuntu bug 524893 in qemu-kvm "versatile: Can't boot initramfses" [Low,In progress]
<Keybuk> psusi: could you read the line out to the class?
<lool> I suspect our kernel is too big for the memory map assumptions, or something like that
<kees> lool: so what's the right way to boot a live environment?
<lool> (but I looked at the memory map and it seemed to leave plenty of space)
<slangasek> pitti: well, bug #539869 is another one
<ubottu> Launchpad bug 539869 in plymouth "does not terminate at computer shutdown (dup-of: 537262)" [Undecided,New] https://launchpad.net/bugs/539869
<lool> kees: Currently none, you could try with kexec though
<ubottu> Launchpad bug 537262 in plymouth "plymouth pid missing from OMITPIDS and terminated by sendsigs" [High,Confirmed] https://launchpad.net/bugs/537262
<slangasek> pitti: oh, you already triaged that ;)
<lool> kees: Do you mean a live env as in casper, or just a real system?
<lool> kees: Cause the kernel can boot a real system just fine, even without initrd
<psusi> Keybuk: which line?  you mean start --no-wait rc-sysinit FROM_SINGLE_USER_MODE=y
<pitti> slangasek: that one at least has Processes.txt and InitctlList.txt
<kees> lool: either, preferrably a real system
<lool> kees: casper does need initrd though
<pitti> slangasek: I was looking at https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=shutdown-hang&orderby=targetname and duplicating a few
<lool> kees: Oh just as I wrote with lucid.img earlier
<kees> lool: okay, so convert a debootstrapped system into an image, and boot that?
 * psusi facepalms
<pitti> slangasek: but it seems this is now going from a little bug fix to a major project..
<lool> kees: exactly
 * kees attempts to trick qemu-nbd into working...
<lool> kees: The page has the low level instructions, rootstock does the same thing as a script and outputs either an img or a tgz
<pitti> slangasek: I think we should probably disable this hook again after beta; it helped us to discover the plymouth issue (which really makes things worse), but the others are just too many; I've seen a couple of frozen mount processes or blkid, etc. (in "D" state)
<lool> kees: I'm uploading my fs, but will take a long while
<slangasek> pitti: huh, yes - and the initctllist.txt and process.txt there show the correct behavior
<lool> kees: Do you get fb output with the lucid kernels?
<slangasek> pitti: yep - hung mount processes are probably a network teardown issue
<slangasek> not something we need every user hitting it to be bothered with
<kees> lool: I did this time finally.
<psusi> ohh, I see.... it fires back to rc-sysinit so it can figure out what the runlevel should transition to
<pitti> slangasek: right, plymouth is running, but it fails to get added to $OMITPIDS
<slangasek> pitti: yes, but *not* because of a bug in 'initctl list', according to this output
<lool> kees: Great; sorry about the link to an obsolete kernel which was on this page I pointed at
<pitti> slangasek: hm, indeed; so it seems it's not a duplicate after all
<kees> lool: does qemu-nbd work for you?
<lool> kees: Happy to hear if you're stuck on any subsequent part of the install
<lool> kees: I'm not using it; I think I heard mention of it recently, but I don't remember in which context
<lool> kees: I think virtio could technically work for qemu disks, but my attempts at forcing it into arm kernels resulted in OOPSes
<kees> kirkland: have you used nbd recently?  it seems to just hang for me?
<slangasek> pitti: no, I think it is a duplicate, it just doesn't appear to be an upstart or plymouth bug :)
<lool> I'm not much of a kernel developer I'm afraid
<Keybuk> psusi: the one that says how rc-sysinit is started, and how that environment variable is passed to it, yes
<Keybuk> pitti: I've had reports of that from lots of things now
<pitti> slangasek: OTOH that initctl list is not the same as the sendsigs script is calling, but a new call from the apport hook
<Keybuk> pitti: there's one on udev for example
<pitti> Keybuk: yes, and I saw a hung blkid, etc.
<kees> kirkland: nevermind, PEBKAC
<Keybuk> but I do also see plymouth getting SIGKILL'd by sendsigs
<pitti> Keybuk: I'll do a round of triaging on those after beta-1; I guess we should disable the apport hook soon again, too
<lool> kees: ogra mentionned qemu-nbd on #ubuntu-arm recently, but had some issues as well; perhaps check with him
<slangasek> pitti: uh, grr then - I think we need it to be the same call to have reliable bug reports
<Keybuk> so sabdfl's slow shut down one evening has led us to finding a whole undiscovered nest of bugs under a rock
<slangasek> pitti: because if there *is* an initctl bug, it's almost certainly racy
<Keybuk> I doubt it's an initctl bug per se, that's just talking d-bus
<pitti> slangasek: well, OmitPids is by and large the output from it, too
<psusi> Keybuk: is the event case sensitive?  i.e. is start on runlevel S the same as start on runlevel s?
<Keybuk> sounds more like an upstart bug
<Keybuk> psusi: yes
<psusi> Keybuk: then it looks like runlevel s and runlevel S are handled slightly differnetly...
<slangasek> pitti: yes, but the question is, why is it *different* between the two runs
<slangasek> pitti: if it's a race, then showing that it *is* different between two runs doesn't help us debug
<pitti> *nod*
<pitti> what might help is a set -x output from sendsigs itself
<pitti> I used that a lot for debugging
<Keybuk> psusi: no
<kees> lool: I, uh, forgot to partition the lucid.img so my nbd devices didn't have any partitions.  *hang head*
<Keybuk> psusi: there is no runlevel s only zuul
<Keybuk> err, I mean runlevel S
<pitti> but even that wouldn't give us new info about a potential race
<psusi> Keybuk: it looks to me like rcS.conf only runs for runlevel S, which you get either by passing the kernel S or single, or -s
<psusi> but if you pass s then rcS.conf won't run?
<Keybuk> psusi: no...
<Keybuk> psusi: seriously, do you bother reading any code before you assume bugs? :p
<psusi> lol... I'm reading and trying to follow along, but it isn't easy ;)
<Keybuk> go read util/telinit.c in upstart
<Keybuk>         case 'S':
<Keybuk>         case 's':
<Keybuk>                 ret = sysv_change_runlevel ('S', extra_env, NULL, NULL);
<Keybuk>                 break;
<Keybuk> ^ that bit specifically
<psusi> ahh, ok... so telinit forces it to uppercase
<lool> kees: bah I don't partition my drives either
<lool> hence root=/dev/sda
<Keybuk> slangasek: I'm not sure where this bug lies
<Keybuk> it sounds like it could be upstart forgetting pids
 * psusi wonders if he could do it with initctl emit runlevel s ;)
<Keybuk> but it also sounds like it could be sendsigs not parsing initctl output right, so killing them anyway
<Keybuk> psusi: you can do that, but it won't get converted to uppercase
<Keybuk> psusi: and you're missing the environment
<slangasek> Keybuk: well, we know upstart hasn't forgotten them permanently, because when apport calls 'initctl list' again, the PID is there :)
<Keybuk> psusi: initctl emit runlevel RUNLEVEL=S PREVLEVEL=  is basically all "telinit S" does
<psusi> Keybuk: that's what I'm trying to do... get into runlevel 's' not 'S', hehe
<Keybuk> err
<Keybuk> psusi: initctl emit runlevel RUNLEVEL=S PREVLEVEL=$RUNLEVEL
<Keybuk> psusi: there is no 's'
<Keybuk> slangasek: oh, now that's more interesting - I hadn't got that bit
<slangasek> Keybuk: another possibility is that it's a race condition where plymouth has started *after* sendsigs has called initctl list
<Keybuk> slangasek: possible, but then it's starting very late
<slangasek> then calls ps, at which point plymouthd is there
<Keybuk> slangasek: and that wouldn't explain the udev bug ;-)
<Keybuk> which is certainly not started on shutdown <g>
<slangasek> ah, hadn't seen the udev bug
<Keybuk> yeah udevd -> didn't close on shutdown
<psusi> Keybuk: well, yea that's one way of looking at it... but an emit runlevel s would get you into runlevel s, just no jobs run in runlevel s, right?
 * kees stabs qemu-nbd in the face
<Keybuk> psusi: there is no runlevel 's'
<Keybuk> it would cause some events to be emitted
<Keybuk> but since System V doesn't define such a runlevel, nothing would be run
<psusi> insofar as there are no jobs defined for it... but manually emitting runlevel s would get runlevel to be s, which would effectively be a zombie runlevel no?
<Keybuk> you couldn't add an /etc/rcs.d and expect it to work, for example
<psusi> right... zombie runlevel ;)
<Keybuk> actually, that's not true, system v defines "s" to mean "I couldn't be bothered to hold down shift when I typed S"
<Keybuk> well
<Keybuk> you can do
<Keybuk>   initctl emit runlevel RUNLEVEL=allegro PREVLEVEL=$RUNLEVEL
<Keybuk> you can do whatever you want ;)
<Keybuk> but don't expect the system to play along
<Keybuk> for a start, those things won't end up in utmp/wtmp
<Keybuk> slangasek: bug #539402
<ubottu> Launchpad bug 539402 in udev "does not terminate at computer shutdown" [Undecided,New] https://launchpad.net/bugs/539402
<slangasek> Keybuk: neato
<Keybuk> though that one is also somewhat odd
<unggnu> hi all
<unggnu> Is the boot splash for Lucid final or are there still changes planned? I mean it looks great but I think the animation looks too much like a progress bar which is misleading imho.
<Keybuk> unggnu: I'm not aware of any changes planned
<Keybuk> it happens that 5s is the average time it's actually visible anyway ;-)
<Keybuk> so it's probably not an issue if it looks too much like a progress bar <g>
<unggnu> Keybuk: it depends on the system :)
<Keybuk> not really, splash shows after ureadahead, so even on HDD you're mostly just waiting for X to init
<unggnu> Keybuk: It wouldn't matter if it wouldn't already look so professionel :)
<Keybuk> if you feel your concerns are particularly strong - talk to the Design team
<Keybuk> they would need to approve any changes
<Keybuk> (filing a bug on plymouth is not a way of talking to them)
<unggnu> I guess I am now on the artwork channel
<Keybuk> sure
<directhex> i think i'm finding why docky doesn't work... and AIR... it's not a pretty issue if it's what i think
<unggnu> It seems that the start time is really fast through the "progress bar" and then suddenly it starts again.
<unggnu> (the animation)
<Keybuk> unggnu: huh, it if starts again, you have an old plymouth
<Keybuk> the current theme draws orange dots from left to right
<Keybuk> then replaces them with white dots from left to right
<Keybuk> and then repeats
<unggnu> Keybuk: this is what I meant with again :)
<Keybuk> only older versions fill from left-to-right then go back to five white
<unggnu> until the reds get replaced again you might think it is a progress bar
<Keybuk> I iz not designer
<Keybuk> when I last did a splash screen theme, it had a dancing monkey on it
<Keybuk> you need to talk to them :p
<unggnu> Keybuk: I am, but they are not there or not replying :D
<Keybuk> that's because it's close to 10pm in the UK
<directhex> what happened to the gnome-keyring socket?
<Keybuk> they're probably at home with their husbands, wives and dogs
<Keybuk> or down the pub
<unggnu> or in some fancy art gallery ;)
<directhex> there's no GNOME_KEYRING_SOCKET environment anymore, and no /tmp/keyring-foo32d987h273ry/socket file
<directhex> seb128, ^
<seb128> directhex, right
 * sebner waves at directhex :)
<Keybuk> Where does the +-sign come from?
<Keybuk> As far as I know, Ubuntu does not use ACL by default.
<Keybuk> heh, ... you iz wrong!
<seb128> directhex, you are supposed to use libgnome-keyring not hack other software sockets
<Keybuk> (/me catches up on ML for a few minutes)
<directhex> seb128, and the seemingly empty dbus interface?
<seb128> directhex, the dbus interface is the next generation way
<seb128> until now it had libgnome-keyring only
<seb128> it's being turned in a freedesktop.org dbus interface for GNOME3
<seb128> but that's work in progress started this cycle
<seb128> libgnome-keyring is still what is used by GNOME
<seb128> you can play with the dbus interface if you want though
<directhex> there doesn't seem to be anything exported via the dbus interface, if dbus-explorer is to be believed
<Keybuk> that just means the dbus server doesn't do introspection
<Keybuk> it's kinda optional
<Keybuk> you tend to add it the first time you have to debug your own d-bus interface, and wish you didn't have to keep writing client stuff and could just use d-feet :p
<Keybuk> the trick is to avoid writing the client as long as possible
<Keybuk> though then you end up with upstart 0.5 - where the server has a wonderfully rich d-bus interface, with full introspection
<Keybuk> and initctl had never caught up - cause I could do all my testing with dbus-send and d-feet :p
<directhex> hm. seems i have a rather short period of time to rewrite gnome-keyring-sharp from scratch then
<kees> lool: okay, so booting my debootstrap'd image, I get as far as mountall: Could not connect to Plymouth
<kees> Keybuk: if I'm starting a crazy arm image without an initrd, what do I have to do to trick mountall into starting plymouth on its own (instead of the initrd doing it)?
<directhex> is it an upstream change or an ubuntu change to remove the socket?
<Keybuk> kees: it doesn't
<Keybuk> kees: upstart should start mountall and plymouth ?
<kees> Keybuk: weird, I'm getting "mountall: Could not connect to Plymouth"
<Keybuk> implies plymouth isn't running
<kees> precisely.  :)
<Keybuk> you sure it's on that image?
<seb128> directhex, upstream, we don't have ubuntu changes to gnome-keyring
 * kees checks
<directhex> it seems to break any keyring usage in mono apps. which means f-spot can no longer store passwords, presumably. it also kills other things like bbc iplayer (or any adobe air app, really)
<seb128> directhex, you can a /tmp/keyring-nnnnn/control
<kees> Keybuk: neato, the debootstrap missed it.
<seb128> not sure what it's used for
<kees> is it part of -minimal?
<seb128> directhex, but it might be useful for what you need
<lool> kees: make sure you setup the network
<kees> lool: yup
<lool> kees: /etc/network/interfaces or network-manager
<lool> kees: the plymouth thing is just a warning
<kees> lool: yeah, I'm updating it via my schroot first, then will re-sync to the disk image.
<directhex> seb128, control appears not to be the same thing
<kees> lool: just a warning?  it didn't do anything after that.  :(
<Keybuk> pitti: maybe check http://websvn.kde.org/trunk/KDE/kdebase/workspace/ for blame?
<Keybuk> what file is the vt8 appearing in ?
<RAOF> Keybuk: You wanted to know if the lbm_nouveau patches can be dropped?  They can be.  It'll make the upstream nouveau testing PPA slightly harder to keep current, as it'll need to pull in patched plymouth & such, but Lucid doesn't need any of those patches.
<lool> kees: presumably it was waiting for some event to launch the ttys
<Keybuk> RAOF: so we still intend to support lbm-nouveau for lucid onwards?
<Keybuk> RAOF: what's in the "upstream nouveau testing PPA" ?
<lool> kees: Usually for me it's the network
<lool> kees: You can confirm things work by running /bin/sh
<kees> lool: yeah, init=/bin/sh worked
<lool> kees: You did the second stage part of your debootstrap already I guess
<Keybuk> pitti: I can't find vt8 grepping through the source
<lool> kees: You want your rootfs in /etc/fstab too
<kees> lool: I did the debootstrap via mk-sbuild
<Keybuk> pitti: ah, I can find vt%d
<lool> kees: Or you want to pass rw on the kernel cmdline
<kees> lool: oh, I bet I missed that.
<lool> kees: I think I filed that one against mountall, not sure
<lool> kees: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/527216
<ubottu> Ubuntu bug 527216 in mountall "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro" [Medium,Triaged]
<Keybuk> yeah we debugged that one
<lool> kees: I personally like loop mounting my rootfs quite often; I use a wrapper to launch a shell in the mount and umount on exit
<lool> kees: http://people.canonical.com/~lool/loop-mnt-do
<Keybuk> is caused by mountinfo having /dev/root in it
<lool> kees: (You might find this useful when changing the rootfs between boots)
<RAOF> Keybuk: The upstream nouveau testing PPA contains packages for bleeding edge upstream; the DDX, libdrm, and nouveau's linux branch.
<Keybuk> RAOF: -> kernel
<directhex> found it. Stef Walter broke the socket on 2009-12-17
<kees> lool: yup, missing fstab entry was it.
<lool> kees: Cool; so I guess you're working on the security features for ARM?
<kees> lool: no, just making a list of what's missing.
<lool> ok
<pitti> Keybuk: yeah, I already grepped code for ->serverVT, but didn't complete that yet (didn't see something obvious after 3 minuts)
<Keybuk> pitti: thinking about this now for a moment
<Keybuk> pitti: where is kdm pulling that 8 from?  have you found out?
<Riddell> pitti: amd64
<pitti> Keybuk: I'll look in a bit
<pitti> Riddell: if you are  on amd64, I can toss you the binary
<Keybuk> pitti: cause me thinking
<pitti> Riddell: great architecture that
<Keybuk> if kdm is guaranteed to always use 8, we don't need the patch "for the first server"
<Keybuk> that's there not to use plymouth's vt, but to make sure we don't use 1-6 right
<pitti> Keybuk: I'll check in a bit
<Keybuk> so all we really want is if plymouth-is-running use the currently active vt, whatever that might be
<pitti> Riddell: http://people.canonical.com/~pitti/tmp/kdm
<pitti> Riddell: copy that to /usr/bin, and restart
<pitti> Keybuk: ah, it seems to call get_active_vt()
<pitti> Keybuk: VT_GETSTATE on /dev/tty0
<pitti> Keybuk: which is a bit weird, I called kdm from tty3
<Keybuk> pitti: active vt will be 7 though ...
<pitti> Keybuk: ah, no, sorry; that was from the broken 104_kubuntu patch
<pitti> that code path won't be active
<pitti> nothing ever writes that stamp file
 * pitti searches further
<slangasek> Keybuk: plymouth is stopped on starting kdm, so what would "if plymouth-is-running" check?
<Keybuk> slangasek: huh?
<Keybuk> ECONTEXT
<slangasek> 15:15 < Keybuk> so all we really want is if plymouth-is-running use the currently active vt, whatever that might be
<Keybuk> ah
<Keybuk> right
<Keybuk> sorry
<Keybuk> if pitti is right, kdm is always pushing X to vt8
<Keybuk> it seems to be very insistent on always passing vtX
<Riddell> pitti: seems to do the job
<Keybuk> if that's true, kdm *is not* vulnerable to the getty-and-X-on-vt1 bug
<Keybuk> because kdm likes vt8
<Keybuk> if we can prove it's not vulnerable, we don't need this patch
<slangasek> so dropping the --retain-splash solves all the races/conflicts, and the remainder is just getting the X transition pretty?
<Keybuk> yes
<pitti> Keybuk: I looked through all instacnes of serverVT and reqSrvVT again, and I still don't find the code which sets those to 8
 * pitti searches harder
<Riddell> using pitti's KDM binary is much nicer than dropping --retain-splash, it doesn't drop me to a terminal for several seconds
<Keybuk> Riddell: it will though
<Keybuk> once we lose the --retain-splash
<pitti> Riddell: can you check user switching, with a second X? that should land on vt8 then
<pitti> I tested that here as well, but just to make sure
<kees> lool: what do you use for qemu networking?  i.e. how do you get your arm VM talking on the network?
<pitti> Keybuk: ah, it's in allocateVT() in kdm/backend/dm.c
<pitti> I don't see reqSrvVT being set anywhere, so it must be dynamic
<Keybuk> it's from config
<Riddell> pitti: user switching seems to work, I have one user on control-alt-F7 and one on control-alt-F9
<pitti> hm, and serverVTs starts with 7, so why doesn't it actually _pick_ 7 initially?
<Keybuk> because it queries whether each one is allocated in turn
<Keybuk> sees VT7 is in use
<pitti> and vt7 is allocated?
<Keybuk> so ++
<Keybuk> yes
<Keybuk> plymouth had it
<Riddell> F8 is blank with a cursor
<pitti> ah, ok
<Riddell> first user is on vt 8 second on vt 9
<Keybuk> plymouth didn't VT_DEALLOCATE
<Keybuk> it left it for X to find
<pitti> Keybuk: ok, so it seems that forcing it to vt7 is about as ugly/working as in gdm then
<Keybuk> right
<Keybuk> so this code is largely good
<Keybuk> it's safe from death by getty after all
<pitti> at least for beta-1 it's probably good enough
<Keybuk> yup
<pitti> I really hate those two patches, but *shrug*
<Keybuk> for beta-2, we want to include plymouthness in there, and use the current vt whatever that is, whether allocated or not
<pitti> working > beauty this close to release
<Keybuk> but beta-1 no need to change kdm
<pitti> oh?
<Keybuk> well, kdm works right?
<pitti> so we're going with the --retain-splash thing?
<Keybuk> it will use the first free vt from 7 onwards
<Keybuk> no, we're dropping --retain-splash
<Keybuk> steve and I talked about that separately
<pitti> ok, fine for me
<Keybuk> it introduces too many issues
<Keybuk> and a fix for the vt1 issue makes it harder to keep
<Keybuk> (login: for people)
<pitti> so you don't actually want me to upload that kdm patch then?
<tkamppeter> mvo, pitti, did one of you have another look at the D-Bus problem.
<pitti> tkamppeter: sorry, -EBUSY
<Keybuk> pitti: nope, but thanks very much for doing the work to figure out how kdm gets its vt
<Keybuk> that's useful knowledge!
<pitti> Keybuk: at least we have a patch on the shelf now, should we still need it
<pitti> brb, booting into an X session again
<kees> lool: ah, got it, was missing dhclient. har har
<pitti> Riddell, Keybuk: so the h4ck is on http://people.canonical.com/~pitti/tmp/kdm.firstserver-force-vt7.patch (that corresponds to http://people.canonical.com/~pitti/tmp/kdm)
<pitti> I won't delete it just yet :)
<pitti> Riddell, Keybuk: do you still need anything from me now for this issue?
<Keybuk> pitti: nope, thanks!
<pitti> Keybuk: thanks to you!
 * pitti cd /bed
<Riddell> Keybuk: so resolution is to drop --retain-splash and that's us sorted for beta?
<pitti> Riddell: current kdm won't at least run into the "start on vt1" problem, so it will look a bit ugly, but should work
<Keybuk> Riddell: yes
<Riddell> Keybuk: so you'll upload that tonight and have slangasek get us a new set of CDs to test tomorrow?
<Keybuk> yes
<Riddell> Keybuk: should I e-mail tseliot to tell him it's sorted for beta but the smooth transition patch is still needed if he is in a KDM patching mood?
<Keybuk> Riddell: yup
<Riddell> Keybuk: groovy, thanks for giving over your evening to this
<Keybuk> that's quite ok, thanks for your help
<Keybuk> good to get to the bottom of it
<Guest36494> kees, qemu-nbd definately had issues for me uin it from scripts, i had to call it twce to work
<Guest36494> s/uin/running/
#ubuntu-devel 2010-03-17
<kees> Guest36494: yeah, timing issues for me.
<kees> Guest36494: and sometimes i/o stalls :(
<Keybuk> I should plug the wrong AC adapter into Dells more often
<Keybuk> it's great for debugging
<Keybuk> you get a nice *BEEP*BEEP* and have to press F1
<Keybuk> otherwise it won't switch on/reboot
<lifeless> heh
<lifeless> still a dell adaper?
<Keybuk> so I can then press F1 and hold down shift ;)
<kees> slangasek, cjwatson: I thought P-a-s was in sync with debian?
<kees> we don't seem to have this change: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543601
<ubottu> Debian bug 543601 in buildd.debian.org "prelink compiles on all architectures" [Normal,Open]
<slangasek> kees: it's manually synced
<kees> gar
<cjwatson> lp:~ubuntu-core-dev/packages-arch-specific/ubuntu
<cjwatson> merged from lp:packages-arch-specific
 * kees fixes
<cjwatson> we've had our own branch for ... maybe a year now?
<kees> okay, I've merged the Debian changes from Feb and Mar now
<Keybuk> damnit bzr
<Keybuk> if you don't know a push location, why not try and see if you can push to the parent hmm?
 * slangasek grins
<lifeless> Keybuk: because thats usually the wrong thing
<Keybuk> no it isn't
<RAOF> lifeless: Really?  When is pushing to the parent the wrong thing?
<Keybuk> bzr branch lp:blahblahblah
<Keybuk> work on it
<Keybuk> bzr push
<lifeless> bbiab
<lifeless> RAOF: everytime you don't own the branch
<Keybuk> if you don't own it, you can't push to it
<Keybuk> so it'll fail
<Keybuk> and then you can say "no push location"
<Keybuk> it could at least *try* :)
<kees> lool: is there any way to run ARM with >256M of memory?  all it seems to do is segv if I try to change it.
<Keybuk> hell, surely at branch point it knows whether or not you can write?
<Keybuk> so bzr branch could save the push location as the parent if it happens to know it's writable
<barry> i'm wondering if anybody can help me understand something in the intersection between dh_install and policy kit on lucid
<slangasek> barry: shoot
<barry> slangasek: thanks.  so i'm nearly done with my dbus refactoring of computer janitor.  it needs to install a polkit policy.  mvo extended computerjanitor.install to install the policy file to /usr/share/PolicyKit/policy but that doesn't work.  i believe it needs to go to /usr/share/polkit-1/actions
<barry> slangasek: now, i've hacked the .install file to do that, but i had to explicitly mention the PolicyKit path and i'm wondering, shouldn't dh_install install it to the right place automatically?
<Sarvatt> kees: thats a limitation on the platform emulated by qemu afaik, I think lool has a patch to allow 512MB though but not sure it applies to the more recent qemu's or it'd be there I imagine
<barry> slangasek: otoh, i don't know all the magic that dh_install actually does ;)
<slangasek> barry: dh_install is the generic "install files where I tell you to" command
<slangasek> barry: there are many other specialized commands that install common files of various sorts in the obvious places, but there's no dh_policykit that I'm aware of
<barry> slangasek: i think you're right, i couldn't find a dh_installpolicykit either
<barry> slangasek: so, mvo had this originally in the computer-janitor.install file:
<barry> /usr/share/PolicyKit
<barry> i tried changing that to
<barry> er, no leading slash
<barry> usr/share/polkit-1
<barry> and dh_install --fail-missing complained
<slangasek> that was "/usr/share/PolicyKit" on a line by itself?
<barry> slangasek: usr/share/PolicyKit on a line by itself
<slangasek> barry: right, that's a magic rule meaning "copy debian/tmp/usr/share/PolicyKit to a tree of the same name in the package"
<slangasek> barry: so you need to do usr/share/PolicyKit/* usr/share/polkit-1 instead if you want dh_install to magic this away for you, I think
<barry> slangasek: how did computerjanitord/data/com.ubuntu.computerjanitor.policy get into usr/share/PolicyKit in the first place?
<slangasek> sec, let me pull the package to see
<barry> slangasek: oh wait.  i bet it's the setup.py that did it
<slangasek> could be
<barry> slangasek: cool, that fits together then.  let me try that.  thanks for the help!
<slangasek> sure thing
<slangasek> (fwiw, the package I grabbed doesn't seem to do what you're talking about, oops :)
<barry> slangasek: it would be lp:~barry/computer-janitor/dbus-merged
<barry> slangasek: ^^ is a new version of c-j i'm trying to get landed
<slangasek> ok
<barry> slangasek: yep, that was it.  thanks again
<Keybuk> bryceh: still around?
<bryceh> yeah, but a bit busy, what's up?
<Keybuk> bryceh: random question for you
<Keybuk> X multi-head
<Keybuk> laptop has widescreen netbookish LVDS
<Keybuk> plug into 4:3 external display
<Keybuk> X picks a very random resolution to clone both together
<Keybuk> 800x600 @ 60 hz or something
<Keybuk> it's not even the highest common resolution they both support
<Keybuk> why?
<bryceh> brain damage
<bryceh> usually the Xorg.0.log will list out the logic as to why it arrives at a particular resolution arrangement
<ion> Same here. The laptop has a 1280Ã800 display and itâs connected to a 1920Ã1200 monitor. X picks something like 800Ã600 by default.
<Keybuk> bryceh: xrandr --auto doesn't fix this either
<Keybuk> I have to --preferred each display
<bryceh> with cloning, it seems like there's three different ways it could be done, and no one of the three will cover all possible use cases
<bryceh> upstream seems to have picked an approach that suits the smallest of the three use cases.
<Keybuk> why does it clone by default at all?
<Keybuk> I guess that's what confused me
<ion> s/800Ã600/1024Ã768/ actually
<bryceh> I think it's for the projector use case, and assuming people will want to see everything on both screens
<bryceh> so it tries to find the lowest common matching resolution
<bryceh> with 4:3 and an HD monitor, there really isn't a good common denominator
<Keybuk> it's kinda annoying
<Keybuk> you see
<bryceh> I guess way back when, laptops also had 4:3 so that worke
<bryceh> d
<Keybuk> we put some amount of effort to support multi-head with plymouth
<Keybuk> so even if you have a monitor
<Keybuk> the splash screen looks sexy on both the panel and the monitor
<bryceh> now days it generally falls all the way down to one of the vesa modes
<Keybuk> not stretches
<Keybuk> all text on both
<Keybuk> etc.
<Keybuk> and that looks nice
<Keybuk> then gdm starts
<Keybuk> and you end up in the resolution from hell
<Keybuk> and the smooth transition doesn't look so slick after all ;)
 * bryceh nods
<bryceh> brain damage, like I said
<jmg> hi all
<jmg> who knows about mono
<RAOF> A number of people.  They're more likely to answer if you ask an actual question, though.
<jmg> ok
<jmg> looking for a ppa of mono2.6
<jmg> specifically libapache2-mod-mono 2.6
<RAOF> ...as long as that question is on-topic for #ubuntu-devel :)
<jmg> otherwise the status of mono 2.6 in ubuntu, and roadblocks if any
<RAOF> Status of mono 2.6 in Ubuntu Lucid: 2.6 is not a long term support release, 2.4 is.  We're sticking with 2.4.
<jmg> ffuuuu
<jmg> hmmm
<RAOF> Launchpad's pretty good at searching in PPAs now; just browse to the mono source package, and it'll list PPAs which build mono.
<jmg> ok thanks
<dholbach> good morning
<pitti> Good morning
<dholbach> hey pitti
<pitti> Keybuk: shall I commit your gdm changes to bzr, or did you do already and just need to push?
<tkamppeter> pitti, mvo, hi
<lool> kees: I don't think you need the rootfs anymore, but in case you do http://people.canonical.com/~lool/rootfs.img
<PetrolCB> Hi, I'm really looking forward to Beta 1... Is the exact time of release known? I know it's tomorrow, but when exactly does it become available?
<persia> PetrolCB: There's no precise time : sometime after the images are tested and confirmed beta-quality.
<PetrolCB> ok, thanks
<persia> PetrolCB: If you'd like to help out with testing, you may be able to help make it be sooner.
<PetrolCB> I've subscribed to ubuntu-announce so I guess I'll get an email not too long after it's been released
<PetrolCB> sure, how can I help?
<persia> Head over to #ubuntu-testing where the coordination happens, and someone will surely help you get started.
<tseliot> pitti: shall I upload nvidia too (in addition to fglrx) since they won't be approved anyway?
<pitti> tseliot: go ahead
<tseliot> pitti: ok, thanks
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> I have tried around with the dbus problem, and tried to use a session bus service.
<pitti> tkamppeter: what is the problem again?
<tkamppeter> The problem is that if a printer is connected and detected by HPLIP and it needs firmware, the udev script (running as root) sends a dbus message so that a program of the user's desktop can catch the signal and run a firmware download GUI (running as the user).
<pitti> tkamppeter: ah, right; was that added to update-notifier?
<tkamppeter> There was a suggestion to use ubuntu-notifier as the listener and mvo has written a piece of code to do the task: http://pastebin.ubuntu.com/396286/
<PetrolCB> thanks, persia
<tkamppeter> With this code ubuntu-notifier listens for a NeedPlugin signal on com.hp.hplip which root sends via
<tkamppeter> dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin
<pitti> hmm
<pitti> this adds a listener to the system bus
<pitti> mvo: ^ wouldn't that collide if you have more than one session?
<tkamppeter> Problem is probably here also that com.hp.hplip is already used by HPLIP for PolicyKit.
<mvo> pitti: the problem is that dbus-send does not really gives the right kind of signal, it need to come from the com.hp.hplip dbus server that is already there
<pitti> yes, it should be com.ubuntu.UpdateNotifier
<mvo>  or update-notifier needs to add low level matchers (I ahve code for this but its ugly)
<tkamppeter> My suggestion is to add a service to the session bus.
<pitti> mvo: oh, nevermind me; I read it the wrong way round
<pitti> mvo: u-m just connects to the existing hplip D-BUS service, right?
<pitti> and reads signals from it
<mvo> yes
<mvo> so we should add the signal there IMO
<tkamppeter> For a quick test I edited /usr/share/hplip/hpssd.py adding a new method to com.hplip.StatuisService:
<pitti> tkamppeter: with your dbus-send, you are sending a signal *to* the hplip D-BUS service
<pitti> tkamppeter: what you really need is having the D-BUS service (the process for com.hp.hplip) send out the NeedPlugin signal
<tkamppeter> http://pastebin.ubuntu.com/396603/
<tkamppeter> Name of the method is InstallPlugin
<tkamppeter> Problem of this is that it works only if the message is sent by the user, not by root.
<pitti> tkamppeter: so, the way it's meant to be is to have the hplip daemon listen to udev events (with libudev), pick out the "needs firmware" thing, and send the signal from its d-bus service
<pitti> sending that from udev rules doesn't work, since there is no process/D-BUS service attached to an udev rule invocation
<pitti> you can't send signals in the name of another process
<tkamppeter> pitti, but if an HPLIP daemonlistens, it could directly start the plugin-installer, without using update-notifier.
<pitti> tkamppeter: hplip runs as a root system daemon, though?
<pitti> and I thought you need a GUI
<tkamppeter> pitti, HPLIP does not have a root system daemon.
<tkamppeter> pitti, if hplip-gui is installed, there is a session daemon running as the user, hp-systray.
<pitti> tkamppeter: now, that is the client side component which could pick up a signal, or udev event
<pitti> tkamppeter: i. e. this could use libudev to watch out for firmware events
<pitti> (instead of the udev rule, dbus-send, and the other hackery)
<tkamppeter> hp-systray can pop up a GUI program when it gets a dbus message.
<pitti> tkamppeter: but if hplip doesn't have a daemon, there's nothign to send the d-bus message from; also, it'd be the wrong way around
<tkamppeter> pitti, you mean that the listener which runs as the user and pops up the plugin installer should listen for udev events and not for dbus messages?
<pitti> tkamppeter: I think hp-systray or u-m should just listen to the udev event
<pitti> it's how the system is meant to work, and the most robust way without hacks
<pitti> tkamppeter: correct
<tkamppeter> pitti, is a daemon needed to send dbus messages? dbus-send is not a daemon.
<pitti> tkamppeter: no, please drop the dbus-send stuff
<pitti> tkamppeter: you just need libudev (or python-gudev if it's python), and install a listener for the subsystem that the udev rule is currently listening to
<pitti> "firmware"?
<pitti> or usb, or whatever it's listening to
<pitti> tkamppeter: is that C or Python?
<tkamppeter> So what I need would be a small Python program which is started for the user session (via /etc/xdg/autostart/*.desktop) and it listens for plug events of firmware-needing printers?
<pitti> nonononono, please no more additional python programs
<seb128> yet another python process in the session?!
<pitti> tkamppeter: I thought there already was a hp-systray thing?
<pitti> tkamppeter: if there is none, we can use update-notifier
<pitti> it already uses gudev and listens to events
<tkamppeter> Can I make somehow make use of /lib/udev/rules.d/56-hpmud_support.rules
<pitti> it's dead cheap to add it there, instead of the current dbus listener
<mvo> pitti++
<mvo> I'm happy to add the code for that, its pretty trivial
<pitti> either to u-n, or system-config-printer
<pitti> the latter runs in the session anyway, too
<tkamppeter> mvo, can you chabge the src/hplip.c there, so that it listens to udev and not to dbus?
<mvo> tkamppeter: sure
<pitti> tkamppeter: the rule needs to be rewritten into C code, so you can use the logic of the rule
<tkamppeter> mvo, it is important that it works with both plugging the printer during the session and also if the printer got plugged before the session started.
<pitti> i. e. you listen for the correct subsystem (firmware/usb/whatever) and then check the attributes/properties of the udev_device you get in the event handler
<pitti> tkamppeter: for the latter you won't get an uevent; for that you need to iterate over all existing udev devices and pick out the existing ones
<pitti> but one thing at a time
<tkamppeter> Important in the rule is the use of hp-mkuri, as this HPLIP utility determines whether the printer needs the plugin or not.
<tkamppeter> pitti, mvo, in general, for the packaging it works well for now to have the listener in update-notifier, but for the future one needs to think about the following:
<tkamppeter> 1. system-config-printer is not a good place as upstream will never accept it. Fedora does not only have a "Do not ship proprietary software" policy, but a "Do not tell the user that proprietary software exists" policy.
<tkamppeter> 2. Is update-notifier GNOME-only? Or is it also available in Kubuntu?
<pitti> tkamppeter: 2. KDE has a counterpart, but it's different code
<pitti> I'm off IRC for some minutes to debug a suspend bug
<tkamppeter> pitti, mvo, so the code stub which we are adding to ubuntu-notifier now we better put into a separate C program which we ship with HPLIP
<tkamppeter> pitti, mvo: This would also be better for HPLIP upstream/
<tkamppeter> pitti, are you back?
<pitti> tkamppeter: yes
<tkamppeter> pitti, mvo, so the code stub which we are adding to ubuntu-notifier now we should better put into a separate C program which we ship with HPLIP, so that also KDE users get it working and in addition we can submit the code to HPLIP upstream, so that all HPLIP users get their firmware easily installed.
<pitti> tkamppeter: can we put it into u-n for lucid? it's a much less intrusive change, avoids yet another daemon to start up, and more packaging changes
<tkamppeter> pitti, OK, I will start separating it later.
<Riddell> tkamppeter: what does the code do?
<tkamppeter> Riddell, if udev discovers an HP printer which needs its firmware loaded whenever it gets turned on (only HP has such printers) then it should be popped up a GUI to download and install the proprietary firmware file.
<Riddell> tkamppeter: ok that sounds non-trivial to get ported to Kubuntu but maybe send me an e-mail so I don't forget about it
<tkamppeter> Riddell: HPLIP has a utility which is called by the udev rule and determines whether the firmware needs to be installed. For now only a message pops up, telling the user to run the firmware installer, but the firmware installer is not actually popped up.
<Riddell> an e-mail pointing at where the code is in update-notifier once it's in
<tkamppeter> pitti, mvo, Riddell: My idea of the separate code was that HPLIP gets added two files: The listener in C and an /etc/xdg/autostart/*.desktop file to start it and this way on all desktops the firmware installer pops up if needed.
<tkamppeter> pitti, mvo, Riddell: The update-notifier solution does not add files, but it is GNOME-only, would also need an additional KDE implementation, and so is perhaps more code addition to Lucid.
<Riddell> tkamppeter: if it's GUI code we would want it re-written for KDE preferably.  however there is a rewrite of the printer applet part of system-config-printer-kde happening currently so it might make sense to add it to that project
<tkamppeter> Riddell, the listener has no GUI at all. It is simply a process running as the desktop user, listening for udev messages and starting a program named hp-plugin-ubuntu (this program ships with HPLIP).
<tkamppeter> Riddell, so the listener is exactly the same for KDE and GNOME.
<Riddell> tkamppeter: but there must be a GUI part too no?
<tkamppeter> Riddell, we should also avoid to put any code for the proprietary plugin of HPLIP into s-c-p, as s-c-p upstream will not accept it.
<tkamppeter> Riddell, the GUI part is in hp-plugin-ubuntu.\
<Riddell> right
<tkamppeter> Riddell, HPLIP itself has only Qt-based GUIs, so hp-plugin-ubuntu checks whether Qt is there and if so starts the native HPLIP GUI for the plugin download, if no Qt is there it starts the interactive text mode interface for the plugin download in a terminal.
<Riddell> tkamppeter: so where does update-notifier come into it?
<tkamppeter> Riddell, update-notifier was only used to make use of an already existing user-session daemon. The idea was not to introduce another one.
<Riddell> dyfet: do we care about your plasma-widget-message-indicator upload for beta 1?
<persia> Riddell: You're probably best poised to answer that: it's an rdepend of kubnutu-desktop and kubuntu-netbook.  Currently it's stuck at 0.5.1 due to FTBFS, the upload would get 0.5.2.  You uploaded 0.5.2 on 10 march for some reason :)
<Riddell> persia: fair point :)
<Riddell> ev: on bug 534473 what's a Cruzer Micro?  I get that bug on my normal CD installs
<ubottu> Launchpad bug 534473 in ubiquity "Wrong CD device used when installed from a Cruzer Micro." [High,Triaged] https://launchpad.net/bugs/534473
<ev> Riddell: it's a usb disk.  I think they're the same bug, regardless.
<Riddell> ev: seems quite a nasty bug to have in for beta, means OEM install can't work.  I guess I can test in a virtual machine
<ev> indeed, I hadn't realized it affected regular CD installs until you just pointed it out
<ev> hrm
<ev> maybe this isn't the same bug after all
<ev> Riddell: did you have more than one CD inserted?
<Riddell> ev: no only 1 CD
<ev> yikes, okay
<ev> I'll undupe your bug then
<Riddell> happens on both of my machines
<cjwatson> maybe we should go back to bind-mounting /cdrom (though perhaps onto /media/apt or something) if we have it rather than letting apt-cdrom use libudev for that bit
<cjwatson> Riddell: FWIW I'm pretty sure it doesn't happen everywhere
<cjwatson> it's not clear exactly what's going on - I suspect that apt's libudev integration might be subtly wrong and doesn't catch all cases
<cjwatson> I'll do a test to double-check, but I'm pretty sure that that part of the installation works OK in kvm at least
<cjwatson> in which case I think we could release-note it for now
<Riddell> right, I don't get the problem in a virtual machine
<cjwatson> I bet it depends on the exact type of CD drive
<cjwatson> e.g. whether it's also DVD-capable
<ev> I looked at the code last week and thought the parameters we set in apt cause it to not go down the libudev path, but I could be very wrong.
<cjwatson> I think maybe in base-installer but not in ubiquity
<cjwatson> which is probably an oversight!
<cjwatson> list-devices (in debian-installer-utils) certainly checks several more cases than apt-cdrom does
<cjwatson> is there 'udevadm info -q all' output for one of these devices around somewhere?
<cjwatson> ('udevadm info -q all -n /dev/blah')
<ev> no, but I did get a udisks dump: http://launchpadlibrarian.net/40499554/udisks.txt
<cjwatson> sdc?
<ev> correct
<ev> with sr0 being the fake cdrom for windows drivers
<cjwatson> not clear from that though, or else I'm not smart enough to extract it
<tkamppeter> mvo. pitti, can you do the code change in update-notifier to pop up the plugin installer ("hp-plugin-ubuntu", not "hplip-plugin-ubuntu"), and tell me when you are ready, then I will do the HPLIP changes.
<mvo> tkamppeter: for the dbus stuff or does that need to be converted to udev ?
<tkamppeter> mvo, this must be converted to UDEV as I understand from our discussion.
<tkamppeter> mvo, if needed, I can add something to the UDEV rules file, so that these printers are somehow distinguishable from ordinary printers in the list of UDEV-reported devices.
<mvo> tkamppeter: if you could do the udev rule part, that would be nice, my experience there is limited
<tkamppeter> pitti, can you help on the UDEV part in the C code of update-notifier?
<pitti> tkamppeter: yes, but not today/tomorrow (hands full with beta stuff)
<tkamppeter> pitti, mvo, so let us move it out for after the beta release.
<mvo> tkamppeter: the udev C bits are no problem, the udev rule file is what I do not have a lot of experience iwth
<tkamppeter> mvo, the meaning is the following:
<pitti> tkamppeter: can you paste it somewhere? (I don't have it here); mvo, I'm happy to interpret it/help with tanslating to gudev
<tkamppeter> When a USB device is added and it has vendor ID 0x03f0 and product IS 0xXX17 (XXX are two arbitrary hex digits) then the command line is executed. The com,mand line sets the environment variable hp_model to the model ID (text vertsion) of the USB device and then runs "hp-mkuri -c" in the background.
<Keybuk> pitti: I did push!
<Keybuk> that branch is owned by the importer anyway - so if I hadn't pushed, it would have shown up
<pitti> Keybuk: ah, -EWRONGBRANCH then
<pitti> Keybuk: I'll commit it, don't worry
<Keybuk> pitti: ? I used lp:ubuntu/gdm
<pitti> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu
<tkamppeter> "hp-mkuri -c" checks whether the printer whose model name is suppied via the hp_model variable needs firmware and whether the firmware is already installed. IF and only if the printer needs firmware and the firmware is NOT installed, it generates a desktop notification and also sends a message to the system (currently via dbus, but I can change it to any other type of message.
<tkamppeter> mvo,  ^^^
<Keybuk> pitti: ah, I missed that
<Keybuk> pitti: still using debian-only packaging then?
<pitti> yes, for now; we'd loose all the history
<pitti> (and would be stuck with a much worse performance)
<Keybuk> pitti: of course, the nice thing is you can cherry-pick the change from lp:ubuntu/gdm no?
<tkamppeter> pitti, mvo, the udev-rules file is /lib/udev/rules.d/56-hpmud_support.rules and is part of the hplip package. Here it is pasted for all the Samsung printer users who have uninstalled HPLIP: http://pastebin.ubuntu.com/396702/
<pitti> Keybuk: I grabbed the diff from LP and committed it; all good now
<Keybuk> pitti: I've never figured out how to deal with these separated debian branches
<Keybuk> I can never get to the point I can build from them
<pitti> Keybuk: bzr-builddeb is awesome for those
<seb128> Keybuk, bzr-buildpackage
<Keybuk> still doesn't give me the source
<seb128> one command, gets the tarball and do everything for you too
<seb128> it does
<pitti> it auto-downloads the orig.tar.gz, and everything
<seb128> it gets the archive one or use the watch for new versions
<pitti> Keybuk: so usually you'd do "bzr bd-do", hack the (now full source) tree, and if you exit the shell it copies back the changes to debian/
<pitti> Keybuk: bzr bd -S -> build source, bzr bd -- -b -> build binaries, etc.
<seb128> bzr bd-do and edit-patch usually
<Keybuk> I did use edit-patch the other day
<Keybuk> kudos to mvo
<pitti> mvo: so basically, you use http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevClient.html#g-udev-client-new to listen to "usb" subsystem events (what the udev rule sya)
<mvo> pitti: ok, adding the code now
<mvo> Keybuk: :)
<pitti> mvo: and whenever you get an add or change event, you use http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevDevice.html#g-udev-device-get-sysfs-attr to check idVendor/idProduct
<pitti> mvo: you can just copy & paste the general listener stuff from the jockey firmware code
<pitti> mvo: or, even easier, just add it to that event handler, so that we don't need two listeners :)
<pitti> it's firmware either way, after all
<mvo> pitti: good point
<mvo> pitti: should I test for idVendor, idProduct or should it rather add a PROPERTY to look for in the udev rule file ?
<mvo> pitti: and I test on that property then?
<pitti> mvo: we should just drop the udev rule
<pitti> mvo: just check the attribute, that's fine
<mvo> aha, ok
<pitti> no need to needlessly add more stuff into the chain
<mvo> tkamppeter, pitti: what is %E{ID_MODEL} ? sysfsattr, property? something else?
<pitti> mvo: property
<mvo> thanks
<pitti> mvo: http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevDevice.html#g-udev-device-get-property
<pitti> mvo: but I wonder whether hp-mkuri is actually the program that we have to call? tkamppeter?
<mvo> thanks, I figured that :)
<mvo> tkamppeter: do I need to call hp-mkuri -c to check if the firmware is needed? or can I just unconditionally call the hp-plugin-ubuntu helper?
<jcastro> mvo: don't forget to respond to debian squid guy at some point!
<mvo> jcastro: weeh, right
<mvo> tkamppeter: I commited the changes to update-notifier now, it currently calls hp-mkuri -c, if that is unneeded, just let me know and I remove it
<mvo> tkamppeter: get it with lp:update-notifier and build with bzr-buildpackage to try it out
<tkamppeter> mvo, got it, thank you. I am building it now.
<mvo> tkamppeter: thanks, let me know about hp-mkuri -c (but feel free to just modify the code yourself)
<kobrien> hi, can someone direct me to a resource describing conventions in coding C for ubuntu if there are any?
<Keybuk> kobrien: there aren't any
<Keybuk> if you want to read some conventions, a good idea is to download a copy of the GNU Standards, print them out, and then BURN THEM!
<Keybuk> (actually, they're probably as good a guide as any - at least to building.  ie. your project should use autoconf + automake, etc.)
<ev> shtylman, Riddell: any idea why the kde frontend of ubiquity has started to consume 100% cpu (bug 538505)?  It's not happening in the GTK+ frontend, and my attempts so far at cracking this have proven unsuccessful.
<ubottu> Launchpad bug 538505 in ubiquity "Extremely slow reponsiveness / high CPU usage" [High,Confirmed] https://launchpad.net/bugs/538505
<Riddell> ev: I've not seen that issue (and I've done quite a few installs today)
<ev> Riddell: odd, I can reproduce it in KVM and on real hardware
<Riddell> ev: I'm more worried about https://launchpad.net/bugs/540275 currently
<ubottu> Ubuntu bug 540275 in ubiquity "Installing in French breaks the keyboard setup page" [Undecided,New]
<ev> gah
<Riddell> ev: it's a shtylman_ bug from his lovely keyboard page, something is being translated which shouldn't be, I'll take a look after I've had some lunch
 * ev shakes his fist at shtylman ;)
<ev> Riddell: cool, thanks
<Riddell> fish shaking is the wrong approach I'm sure, intravenous irn bru would work much better
<Riddell> umm, fist shaking :)
<shtylman_> ev Riddell :)
<shtylman_> life is boring without bugs
<shtylman_> ev: I will test the 100% cpu issue tonight.. ive never seen 100% cpu .. but do find parts of the installer slow... so maybe there is some race or other crazyness happening
<tkamppeter> mvo, I am currently fine-tuning your code by testing it with the actual printer (and also testing with HP printers which do not need firmware).
<tseliot> Riddell: do you know where debug() (e.g. server.c) in kdm writes to?
<tseliot> i.e. to what log file
<Riddell> tseliot: /var/log/kdm.log ?
<tseliot> Riddell: ok, thanks
<mvo> tkamppeter: sweet, once its ready let me know and I merge/upload
<mvo> tkamppeter: thanks!
<tkamppeter> mvo, first bug: in on_uevent() it must read
<tkamppeter> if (g_strcmp0 (action, "add") != 0 && g_strcmp0 (action, "change") != 0)
<tkamppeter> (&& and not ||)
<tkamppeter> mvo, after having corrected that, the firmware dialog actually popped up, but for all HP LaserJet and HP Color LaserJet printers, not only for my LaserJet 1020.
<kobrien> Keybuk: cheers, I use the gnu standards as it is. cool
<mvo> tkamppeter: aha, sorry. I think its not properly checking the return code of hp-mkuri, let me fix that
<tkamppeter> mvo, then I checked your use of hp-mkuri and saw that you do not check the exit status. See "hp-mkuri -h". Firmware installation should only happen if the exit status is 2 or 5.
<mvo> tkamppeter: ok, fixing ths now
<tkamppeter> mvo, I added if (ret != 2 && ret != 5) return TRUE; before calling the firmware installer.
<tkamppeter> mvo, In addition, I added more g_debug lines and this way I saw that after the hp-mkuri call ret was set to 512. Is ret not the exit status?
<mvo> tkamppeter: it needs to be converted via WEXITSTATUS()
<tkamppeter> mvo: 512/256 = 2, is the conversion shifting ret by 8 bits to the right?
<mvo> tkamppeter: man waitpid has the info, its available via the macro WEXITSTATUS()
<tkamppeter> mvo, thanks, trying WEXITSTATUS(ret) ...
<mvo> tkamppeter: or run bzr up
<mvo> tkamppeter: I added your fixes to my branch
<mvo> (including this one)
<kees> lool: cool, thanks.  if anything goes really weird in mind rootfs, I can compare it to yours.
<cjwatson> Keybuk: so, do we know that it's definitely on 'plymouth deactivate', rather than in ply_terminal_close?
<Keybuk> sorry, not following your question
<cjwatson> I'm grepping for paths that call ply_terminal_set_buffered_input
<cjwatson> there seem to be two, and I was wondering if we'd confirmed which one
<Keybuk> set_buffered_input should be guarded
<Keybuk> the one in ply_terminal_close() should return without doing anything because it's called in the deactivate path
<Keybuk> what has happened before is that we ended up with a ply_terminal_set_unbuffered_input() between those two
<Keybuk> so ply_terminal_close() set buffered again
<Keybuk> that was caused, amongst other things, by the fact every damned terminal write did it <g>
<tkamppeter> mvo, it is working now, do you need a patch?
<tseliot> cjwatson: any ideas as to what can be causing this code to exit with return code 10 ? http://pastebin.ubuntu.com/396800/
<cjwatson> I'm not following where the guard is
<cjwatson> but if this is boring, feel free to tell me and I'll stop pursuing it
<cjwatson> tseliot: have you used DEBCONF_DEBUG=developer?
<mvo> tkamppeter: plesae check if trunk/ works correctly, if it does we are good, otherwise I need the patch
<mvo> tkamppeter: I fixed the bits you mentioned
<tseliot> cjwatson: well, I can't reproduce the problem here. A user reproduced it when he was updating the kernel
<cjwatson> Keybuk: I'm finally getting around to remastering the CD to strace plymouth; is that still a useful thing for me to do, or are you already past it?
<cjwatson> tseliot: best ask them for that information
<tkamppeter> mv, I see you have already committed the correct version. Can you upload the package? I will update the HPLIP package.
<tseliot> ok, thanks
<cjwatson> tseliot: 10 can mean various things, I don't see anything blindingly obvious
<tseliot> me neither
<cjwatson> tseliot: it means "bad parameters" in general
<Keybuk> cjwatson: I have a CD with a plymouth installed that has -g -O0 no stripped and the source code in the right place :p
<cjwatson> it's like EINVAL
<Keybuk> I'm hoping this will help
<cjwatson> but, it typically comes with more information in the debconf debug output
<tseliot> cjwatson: ok, there must be something else that triggers this (as DKMS used to do). I'll ask the user to try again with that variable
<tseliot> thanks
<tkamppeter> mvo, stop, as expected, it does not work, I will tell you what needs to be changed ...
<mvo> tkamppeter: ok
<tseliot> cjwatson: it looks like that we have that kind of information already: http://pastebin.ubuntu.com/396803/
<tseliot> well, I don't know if it's the same as debconf debug
<cjwatson> tseliot: that'll do, and there you go, it tells you the problem
<cjwatson> DEBCONF_DEBUG=developer is less noisy for the same effect, but
<cjwatson> + RET='10 nvidia-common/obsolete doesn'\''t exist'
<tkamppeter> mvo, sorry, when I updated yourt code got mixed up with my code. Now I have reloaded your code and it works. Upload the package exactly as you have it in your repo.
<dmart> Does anyone know how to enable debug on a network interface in Ubuntu?
<mvo> tkamppeter: thanks for the fixes and the tests, I will do the upload now
<tkamppeter> mvo, does you new code also cover cold-plugging (printer is already connected and turned on before update-notifier starts)?
<tseliot> cjwatson: yes, I noticed that but I don't understand why it's happening
<dmart> BSD's ifconfig has a "debug" option, but Ubuntu's ifconfig doesn't seem to support this.  Currently I needed to write my own tool to set IFF_DEBUG on an interface...
<mvo> tkamppeter: no, not yet, shall we wait on this? I guess so, I can work on this after dinner or tomorrow
<zyga> mvo: I want to start filing bugs on each ubuntu package that is using the update-alternatives comment in any script
<cjwatson> tseliot: well, it just means that it isn't in the template database, which probably means the package that provides that template isn't installed yet (or is doing something mad)
<zyga> mvo: I want to make a blueprint on adding more metadata to debian packages to indicate all possible update-alternatives that a package install script might perform
<zyga> mvo: does this sound insane or should I go ahead with this project?
<kees> slangasek: as samba maintainer, what do you think of upstream's recent change: http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=bd269443e311d96ef495a9db47d1b95eb83bb8f4
<kees> slangasek: if we backport this, wide links would be disabled by default, which could break poeple using them.
<kees> slangasek: but it closes the CVE-2010-0926 hole
<ubottu> The default configuration of smbd in Samba before 3.3.11, 3.4.x before 3.4.6, and 3.5.x before 3.5.0rc3, when a writable share exists, allows remote authenticated users to leverage a directory traversal vulnerability, and access arbitrary files, by using the symlink command in smbclient to create a symlink containing .. (dot dot) sequences, related to the combination of the unix extensions and wide links options. (http://cve.mitre.org/cgi-bin/cvena
<Riddell> ev, shtylman_: I do see CPU at 90% now I look at top while ubiquity is running :(
<shtylman_> Riddell: it pains me to hear these things :(
<tseliot> cjwatson: I think nvidia-common was already installed (and I call debconf in the postinst anyway) as in this case its postinst was called by a kernel hook
<tseliot> maybe something removed the template?
<tseliot> BTW it's bug #533970
<ubottu> Launchpad bug 533970 in linux "package linux-image-2.6.31-20-generic 2.6.31-20.57 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Confirmed] https://launchpad.net/bugs/533970
<cjwatson> tseliot: I don't know, you're probably better-equipped to take it from here than I am TBH as you know those packages better
<cjwatson> debconf is just reporting the condition
<slangasek> kees: omitting the loadparm.c change would at least mitigate the user impact; widelinks would still be disabled by default *because* unix extensions are on by default, but anyone who's turned off unix extensions will have widelinks ok
<tseliot> cjwatson: ok, thanks
<cjwatson> sorry
<slangasek> kees: fwiw, as maintainer my answer to the bug reporter was "fixed in unstable, not screwing around with stable for this unless the security team asks me to"
<mdeslaur> slangasek, kees: that's not the commit I was looking at, hold on
<kees> mdeslaur: oh? that's what was tied to the CVE
<mdeslaur> oh, yes it was
<mdeslaur> please ignore me, like usual :)
<mvo> zyga: sounds good, ideally we would make it a declarative think and not part of maintainer scripts. but metadata is a start
<mdeslaur> slangasek, kees: it was further improved with http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=16e73d88944ce644cccfa19a99338f5903c061f0
<zyga> mvo: not part of the scripts, part of control file
<zyga> like x-provides-alternavies: xxx, yyy
<kees> slangasek: but that's just a small subset.  the people we're worried about are those using both wide links and unix extensions.
<slangasek> kees: well, I don't think most people are *using* wide links, I think they just unwittingly have them enabled
<slangasek> so I'm not sure how bad the impact on users would really be
<slangasek> but as I said, I'm not pushing to make this change in lenny
 * kees nods
<mdeslaur> slangasek: so, you're okay with everyone inadvertently sharing the whole filesystem in lenny?
<kees> slangasek: the problem is that it allows (DAC-limited) arbitrary file read from the server if a user has the ability to create symlinks
<mdeslaur> there's a cool metasploit module for it :)
<cjwatson> w/wg 47
<cjwatson> dok
<zyga> mvo: great, I assume I have your backing on this, I'll patch the harvester to support this and add this as a proof of concept to selected package, if it wokrs I'll draft a blueprint for review
<slangasek> mdeslaur: there are no public shares by default, users are discouraged from running Internet-facing samba servers; and as kees says it's DAC-limited.  Vs. suddenly breaking things for users who are intentionally using wide links, yeah, I'm ok with that
<slangasek> expecting your authenticated users to not be able to read world-readable files on the server just because they're not shared via SMB is right up there with expecting PHP safe mode to work, I think
<mdeslaur> slangasek: well, by "everyone", I meant "everyone who set up a corporate file server" :)
<tseliot> cjwatson: just to double check, the template should be /var/lib/dpkg/info/$package_name.templates,  right? (it's /var/lib/dpkg/info/nvidia-common.templates in my case)
<mdeslaur> slangasek: huh? I would assume most people who are running a samba file server don't let their users log into the box...
<kees> slangasek: I think samba shares are held to a higher standard that php safe mode.  :P
<cjwatson> tseliot: yes, though something needs to arrange to load that; see debconf-devel(7)
<cjwatson> tseliot: does nvidia-common ship a config file?
<tseliot> cjwatson: no, it doesn't anymore
<slangasek> mdeslaur, kees: my point is that I don't regard it as privilege escalation.  But you guys do what you think is best.:)
<kees> slangasek: okay, cool, thanks.
<mdeslaur> slangasek: ok, our samba update will disable php, thanks for your input :)
<tseliot> cjwatson: I got rid of the config file and moved the logic into the postinst as you suggested: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/nvidia-common/lucid/revision/23
<cjwatson> tseliot: hm, right, so it's possible the templates file hasn't been loaded yet if the template is being used from places other than the postinst file, as you indicate
<tseliot> oh
<cjwatson> tseliot: I think the best option would be to add a config script that is simply as follows:
<cjwatson> #! /bin/sh
<cjwatson> . /usr/share/debconf/confmodule
<cjwatson> exit 0
<cjwatson> that will cause debconf to load that templates file up-front
<cjwatson> might want a comment as well to explain why it exists :-)
<cjwatson> this is a bit of a gotcha, it's bitten me as well in the past.  the way debconf arranges to load templates at the right time is known-hackish
<tseliot> cjwatson: sure, I'll do that, thanks
<mathiaz> jelmer: hi - I was trying to run bzr update on a remote git repository: http://paste.ubuntu.com/396819/
<mathiaz> jelmer: ^^ is this a known bug?
<jelmer> mathiaz: Hi
<jelmer> mathiaz: Yep, it's a known bug - seems to be caused by a newer version of python that's now in Lucid
<cjwatson> Keybuk: I have the strace if it's any use, though I suspect it isn't
<jelmer> mathiaz: It's been fixed in bzr-git trunk, but I haven't had the time to upload new packages to Debian/Ubuntu yet (at a sprint atm)
<mathiaz> jelmer: great than - is there a workaround for now (or a bug number)?
<mathiaz> jelmer: ok - I'll look at the bzr-git trunk and fix it locally then
<Keybuk> cjwatson: please
<Keybuk> because right now, I'm about to say "it's not plymouth"
<cjwatson> I can see a few TCSETS at the end
<mathiaz> jelmer: is the fix revision 743?
<jelmer> mathiaz: yeah, sorry about the uninformative commit message
<cjwatson> strace doesn't tell me details
<cjwatson> Keybuk: attached to bug 540256
<ubottu> Launchpad bug 540256 in plymouth "enter kills X when booting with text plugin" [High,Confirmed] https://launchpad.net/bugs/540256
<Keybuk> huh
<Keybuk> ok, well
<Keybuk> I just traced every line of plymouth
<Keybuk> and it did not fail
<Keybuk> but enter doesn't kill X either
<cjwatson> oh, strace does tell me, I'm just being dim
<cjwatson> 273   17:29:05.425303 ioctl(8, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0
<cjwatson> Keybuk: there's a SIGWINCH terminal change right beforehand.  I have to say that this looks very much like it's in ply_terminal_close
<Keybuk> yes, but it can't be
<Keybuk> there's a great big guard at the top
<Keybuk> SIGWINCH though => hmmmmm
<Keybuk> why would you have SIGWINCH?!
<Keybuk> let me talk myself through the strace for a minute
<Keybuk> 273   17:28:25.803402 read(7, "D\0", 2) = 2
<Keybuk> ^ received deactivate
<cjwatson> it's not receiving SIGWINCH, it's ditching its handler for it
<Keybuk> 273   17:28:25.815653 rt_sigaction(SIGUSR1, {SIG_DFL, [USR1], SA_RESTART}, {0x6df710, [USR1], SA_RESTART}, 8) = 0
<Keybuk> 273   17:28:25.815938 rt_sigaction(SIGUSR2, {SIG_DFL, [USR2], SA_RESTART}, {0x6df710, [USR2], SA_RESTART}, 8) = 0
<Keybuk> 273   17:28:25.816149 ioctl(8, VIDIOC_ENUM_FMT or VT_SETMODE, 0xbfbfbe38) = 0
<Keybuk> restore VT back to VT_AUTO
<Keybuk> (and stop watching the signals)
<Keybuk> 273   17:28:25.816299 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
<Keybuk> put terminal back into Canonical Mode
<Keybuk> 273   17:28:25.816633 write(7, "\6", 1) = 1
<Keybuk> done
<Keybuk> right
<Keybuk> so that looksok
<cjwatson> and X starts at 17:28:26, according to its log file
<cjwatson> and will presumably switch back to raw mode
<Keybuk> 273   17:28:25.842325 read(7, "V\0", 2) = 2
<Keybuk> 273   17:28:25.842451 write(7, "\6", 1) = 1
<Keybuk> do we have an active vt?  => yes
<Keybuk> lots of polling, times and an occasional update of the screen while we wait for X to start
<Keybuk> ok
<Keybuk> no ioctl in that lot
<Keybuk> now
<Keybuk> 273   17:29:05.412303 read(7, "Q\2", 2) = 2
<Keybuk> that's "quit"
<Keybuk> so X is up, gdm wants us to leave
<Keybuk> looks like it's with --retain-splash given the \1\0
<Keybuk> 273   17:29:05.412435 read(7, "\1\0", 2) = 2
<Keybuk> 273   17:29:05.424512 ioctl(8, PIO_CMAP, 0x82a88f0) = 0
<Keybuk> reset the colour map
<Keybuk> (so vts don't stay purple forever)
<Keybuk> 273   17:29:05.425021 rt_sigaction(SIGWINCH, {SIG_DFL, [WINCH], SA_RESTART}, {0x6df710, [WINCH], SA_RESTART}, 8) = 0
<Keybuk> 273   17:29:05.425141 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
<Keybuk> 273   17:29:05.425227 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
<Keybuk> 273   17:29:05.425303 ioctl(8, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0
<Keybuk> 273   17:29:05.425394 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
<Keybuk> and
<Keybuk> like you say
<Keybuk> restore SIGWINCH
<cjwatson> (I'm rebuilding plymouthd with --enable-tracing)
<Keybuk> then fuck around with the console mode
<Keybuk> and
<Keybuk> like you say
<Keybuk> this must be ply_terminal_close
<Keybuk> we did each of those steps
<Keybuk> we restored the colour palette
<Keybuk> we removed the epoll watch on the tty fd
<Keybuk> we removed the signal for SIGWINCH
<Keybuk> then ply_terminal_set_buffered_input () gets called
<Keybuk> the first ioctl is TCGETS
<Keybuk> so that's the "get current terminal attributes"
<cjwatson> the guard at the top of ply_terminal_close is "has ply_terminal_close already been called?"
<Keybuk> it doesn't have ICANON
<Keybuk> so we don't return
<cjwatson> and AFAICS deactivate doesn't close the terminal?
<cjwatson> quit_splash, OTOH, does
<Keybuk> then we restore terminal settings
<Keybuk> so right
<Keybuk> this looks like we went through ply_terminal_set_buffered_input
<Keybuk> and reset the terminal back to Canonical Mode because X reset it to Raw Mode
<Keybuk> --
<Keybuk> no
<Keybuk> the guard at the top of ply_terminal_set_buffered_input
<Keybuk>    if (!terminal->is_unbuffered)
<Keybuk>      return true;
<Keybuk> clearly that must be false
<Keybuk> is_unbuffered starts false
<Keybuk> it's set to true by ply_terminal_set_unbuffered_input
<cjwatson> is it definitely the same ply_terminal_t?
<Keybuk> and set to false by ply_terminal_set_buffered_input
<Keybuk> should be state->terminal yeah
<Keybuk> ohhhhh
<Keybuk> hmmm
<Keybuk> look at the deactivate ioctl
<Keybuk> 273   17:28:25.816299 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
<Keybuk> ...
<Keybuk> the terminal was *already* ICANON
<Keybuk> something reset the terminal to Canonical Mode under plymouth!
<cjwatson> er, are we looking at the same one?
<Keybuk> scroll up
<cjwatson> oh I see what you mean
<Keybuk> so when deactivate was called
<Keybuk> we went into ply_terminal_set_buffered_input
<Keybuk> that did a tcgetattr (that ioctl)
<Keybuk> and was informed that the terminal was already in canonical mode
<Keybuk> now look at the code ...
<Keybuk> set_buffered_input returns at that point
<Keybuk> and *never* resets terminal->is_unbuffered
<Keybuk> so when we call the same function in ply_terminal_close ... the guard is wrong
<cjwatson> right, so we could work around this by updating the state flag there, but we need to know what's fiddling with the console
<Keybuk> so that tries again harder to set the terminal into buffered mode
<Keybuk> and since X has reset it back to raw mode since then
<Keybuk> plymouth helpfully resets it back
<Keybuk> we do yes
<cjwatson> console-setup might be the obvious culprit, but it's really careful to touch only tty[1-6]
<Keybuk> since if the terminal is in Canonical Mode under plymouth - then input and stuff doesn't work
<cjwatson> 'zactly
<Keybuk> and this explains why, when I stopped and restarted plymouth
<Keybuk> I couldn't replicate the problem
<Keybuk> it obviously happens relatively early in the boot sequence
<cjwatson> just a silly question, but
<cjwatson> it isn't upstart is it?
<cjwatson> that would explain the difference between a boot with plymouth in the initramfs (live CD) and one without (most installed systems)
<Keybuk> I was just thinking the same thing
<cjwatson> system_setup_console sets ICANON on whatever /dev/console is, which would be the foreground console, right?
<Keybuk> yes
<Keybuk> so
<Keybuk> putting plymouth in the initramfs, and rebooting
<Keybuk> should replicate this on any machine
<lucas> Is it normal to wait almost a week for syncs to be processed? should I upload fake syncs instead when I need the package in ubuntu ASAP?
<cjwatson> lucas: during beta freeze, yes it is.  what's the bug?
<cjwatson> +number
<lucas> #538271
<cjwatson> it's in main, but not AFAICT on CDs
 * cjwatson greps just to make sure
<cjwatson> no, that's on the server CD
<cjwatson> which is currently final for beta-1 and isn't due a respin (yet ...)
<lucas> ok, I see
<cjwatson> lucas: can this wait until after beta-1?  it should only be a day or so now
<cjwatson> I can make sure to do it ASAP after that
<lucas> cjwatson: it can, it's just that I would like to get as much testing in ubuntu as possible
<cjwatson> or is there a strong reason why it should be specifically in beta-1?
<Keybuk> cjwatson: confirmed, setting FRAMEBUFFER=y on a normal machine does the same thing
<cjwatson> mathiaz: ^- (can't see ttx), what do you think?
<cjwatson> if we need to rev upstart, we might well need to respin everything - this bug would break cryptsetup on a server system, for example
<mathiaz> cjwatson: bug 538271?
<lucas> cjwatson: well, puppet apparently breaks with the current ruby1.8 version. it's probably not major enough to rebuild the server CD.
<ubottu> Launchpad bug 538271 in ruby1.8 "Sync ruby1.8 1.8.7.249-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/538271
<cjwatson> mathiaz: yes
<mathiaz> cjwatson: right - I don't think it's worth respinning an iso for beta1
<cjwatson> do you have test cases for puppet?
<mathiaz> cjwatson: not yet
<cjwatson> perhaps we can address lucas' concerns by making sure that's explicitly and formally tested for beta-2?
<cjwatson> at least partially address, anyway
<mathiaz> cjwatson: yes - that's the plan
<lucas> cjwatson: well by testing I mean user testing.
<mathiaz> cjwatson: we're planning more QA testing on puppet later
<lucas> cjwatson: the original bug is a random+obscure hang
<mathiaz> cjwatson: as far as beta1 is concerned I don't it's worth a respin
<highvoltage> lamont: hi, are you around?
<mathiaz> cjwatson: I don't *think* it's worth a respin
<cjwatson> mathiaz: how about the upstart/plymouth bug in scrollback above?
<cjwatson> well, upstart's involvement is still conjectural but seems likely at this point
<mathiaz> lucas: does that seem reasonable to you (sync ruby after beta1 is released)?
<Keybuk> cjwatson: no, it is upstart
<Keybuk> I just commented out that code, and rebooted
<Keybuk> now enter doesn't kill X
<cjwatson> excellent
<lucas> mathiaz: yes
<Keybuk> cjwatson: I'm just trying to work out why that code is even there
<cjwatson> lucas: sorry we didn't catch this earlier, it was probably just at the start of beta freeze
<Keybuk> I think it's a case of "sysvinit did it"
<mathiaz> cjwatson: bug https://launchpad.net/bugs/540256?
<ubottu> Ubuntu bug 540256 in plymouth "enter kills X when booting with text plugin" [High,Confirmed]
<cjwatson> Keybuk: mm, doesn't the kernel set sane defaults?  (or does it, I'm not sure I trust the vt code to do anything ...)
<lucas> cjwatson: np
<cjwatson> mathiaz: yes
<Keybuk> cjwatson: I'm just reviewing that now
<cjwatson> mathiaz: don't go solely by the bug summary though; 17:50 <Keybuk> since if the terminal is in Canonical Mode under plymouth - then input and stuff doesn't work
<Keybuk> Canonical Mode being Purple ;-)
<mathiaz> cjwatson: ok - let me catch up on the bug
<highvoltage> heh, that explains why my X session was killed on the livecd when I typed 'sudo -s' (I didn't expect it to be the actual enter key that did it :) )
<cjwatson> mathiaz: I think the practical impact on server is that if you are using cryptsetup (and so the initramfs is built with FRAMEBUFFER=yes) then neither fsck nor cryptsetup will/may be able to accept input
<cjwatson> highvoltage: right, that's roughly where we came in, it's just taken all day to narrow it down
<Keybuk> well, it took all afternoon to narrow it down
<Keybuk> it took until then to wait for me to get out of bed :p
<cjwatson> I was working on it in the morning too, just less competently :-)
<mathiaz> cjwatson: so the impact is limited to cryptsetup server installation?
<cjwatson> mathiaz: I think so, I can't think of other situations where you get an initramfs with FRAMEBUFFER=yes on server?
<cjwatson> perhaps somebody can verify that from more reliable memory
<highvoltage> well, thanks to both of you for getting out of bed today :)
<Keybuk> the two things that I know that set that are cryptsetup and casper
<cjwatson> I get rousted out of sleep at god-awful-o-clock by a small child
<cjwatson> doesn't matter when I went to bed
<highvoltage> heh
<Keybuk> right
<Keybuk> I'm going to take a few minutes to collect state
<Keybuk> not to mention update the bug
<cjwatson> I'm going to leave at this point, as I'm due elsewhere.  Please SMS / google-talk me if I need to log in and poke the publisher or whatever, and I can do that
<mathiaz> cjwatson: I think it's *not* worth a -server iso respin for the plymounth/upstrart bug
<dahud> How far do I need to get in my education before I can begin to understand and work on Ubuntu?  Are there some lower-level tasks to be done?
<mathiaz> cjwatson: given that it only affects cryptsetup installations
<Keybuk> cjwatson: I can do that ;)
<cjwatson> mathiaz: OK, that will probably help matters, thanks
<highvoltage> dahud: reading https://wiki.ubuntu.com/ContributeToUbuntu and its sub pages will give you some idea
<dahud> highvoltage: Thanks
<highvoltage> dahud: anyone can with enough work and patience
<cjwatson> dahud: there's e.g. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize - but personally my advice has always been to find something that annoys you personally and seems like it ought not to be too hard, grab the code, and read through it until you've figured out how to fix it
<cjwatson> dahud: repeat a couple of hundred times :-)
<cjwatson> and then if you're (un)lucky you end up maintaining it ...
<psusi> say has any thought been given to disabling partition detection in the kernel and moving it to udev with partx?  I can't find any mention of it on the wik or -devel archive
<Keybuk> psusi: look in lkml
<cjwatson> IME working on things that other people have listed tends to be less fulfilling
<dahud> OK.  Another question: what IDE do you all use?
<zyga> dahud: I don't want to repeat anything everyone else said but basically most of the stuff depends on your ability to read/write code, many people can contribute without that feature
<cjwatson> dahud: you'll get a wide variety of answers, but many experienced long-term Ubuntu developers just use an advanced editor (vim or emacs) plus command-line tool
<cjwatson> s
<cjwatson> obviously there are IDEs available as well
<dahud> I mainly want the practice working with real code
<Keybuk> cjwatson: oh I wonder
<Keybuk> you know that whole plymouth-can't-catch-enter thing?
<Keybuk> could that be because Enter looks a lot like SIGQUIT to plymouth too ?
<Keybuk> or is this while still in casper?
<cjwatson> that's on shutdown, I think
<zyga> dahud: if you can read (x10) and write (x1) c/python you have access to vast majority of stuff around ubuntu :-),  still - please read that wiki first
<Keybuk> ah, ok
<Keybuk> so a new plymouth
<cjwatson> well, at least one of the instances is
<psusi> Keybuk: as an experiment I just tried using fdisk to add a new partition and the re-read ioctl fails since another partition is in use, but partx -a has no problem adding the new partition... I might have to look into getting gparted to use that
<cjwatson> IIRC there's a problem with CD checking too, which is on startup
<Keybuk> that's while within the initramfs though, right?
<cjwatson> good point, yes it is
<cjwatson> anyway, really gone
<psusi> damn... my search is turning up zero instances of partx on lkml...
<ogra> Keybuk, apparently the crash is already reported as bug 537262 and the flickering isnt reproducable on subsequent boots anymore
<ubottu> Launchpad bug 537262 in plymouth "plymouth pid missing from OMITPIDS and terminated by sendsigs" [High,Confirmed] https://launchpad.net/bugs/537262
<Keybuk> that's not a crash then, is it? :p
<ogra> well, it triggers apport
<ev> Riddell: confirmed and fixed
<ev> I'll do an upload now
<Riddell> ev: ooh
<Riddell> ev: so I was too quick to defame shtylman_?
<ev> we both were :)
<ev> I fixed this bug in console-setup at the sprint
<ev> but forgot to port it over to ubiquity
<Riddell> I always knew shtylman_ was unimpeachable
<shtylman_> Riddell ev: :)
<ev> lol
<mvo> Keybuk: i see this at boot now: "Your disk drives need to be checked for error, this may take some time " \o/ -- last week there was only a [C] :)
<jdong> is there a way to convince apport not to do dupe checking when filing bugs?
<jdong> in a telepathy-butterfly bug, it's pretty certain that a user's getting a TypeError crash on a different codepath as the bug that apport claims is a dupe
<jdong> and the user claims apport refuses to allow him to submit a new bug report, saying the bug is already reported at the bug opened in the web browser?
<lamont> highvoltage: am now
<ScottK> doko: All the Main stuff that was broken due to qt4-x11 on IA64 is built now.  Thanks for taking care of it.
<chrisccoulson> jdong - it's likely that the bug pattern needs editting
 * ScottK wants apport --please-for-the-love-of-god-let-me-file-this-bug
<chrisccoulson> jdong - try checking here: http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/annotate/head%3A/telepathy-butterfly.xml
<chrisccoulson> it's quite possible that the submitters bug inadvertently matches an existing pattern. If that's incorrect, then the pattern needs fixing
<slangasek> jdong: if the new bug is being refused, a bug pattern is set for it server-side; you'd need to have pitti change the bug pattern (maybe someone else has access, but I don't know who)
<micahg> slangasek: bug control should have access to the patterns
<micahg> so devs included
<chrisccoulson> i just pointed a link to the telepathy-butterfly patterns :)
<micahg> I don't know offhand how often they update
<slangasek> micahg: well, I can guarantee that not all of bug control has a clue where to set them :)
<thopiekar> hi .I'm a member of the Canola project and atm almost the only person working on Canola.. I need more people here at #canola to improve the code.. the player is great and many plugins are available.. please help. the developters that where working on it in the past were paied to work on it - now they have other priorities so - we need you!
 * Keybuk has returned
<Keybuk> zombies may crave brains, but Keybuks crave Spring Vegetable Soup and a mug of hot Tea
<Caesar> Does the "compiled with the following options" chunk of this excerpt of Universe's Packages file look strange to anyone else?
<Caesar> http://paste.ubuntu.com/396924/
<Keybuk> Caesar: I guess someone was taking notes in the control file and forgot to delete them ;-)
<lamont> stgraber: around?
<Caesar> Keybuk: zomg, debian/rules puts it there
<Keybuk> probably trying to add it to the description
<Caesar> and failing dismally
<Caesar> Oh fun, it works fine in Debian
<Caesar> It's something to do with the insertion of the Original-Maintainer maintainer field in Ubuntu
<Keybuk> yes
<Keybuk> it goes at the bottom
<Caesar> Not in this package
<Caesar> It's in the middle (see the pastebin thingy)
<lamont> highvoltage: you around?
<highvoltage> lamont: yep, hi!
<lamont> crying a little here...
<highvoltage> lamont: do you think you'll have a chance to look at that additional squashfs image on the edubuntu disc thisweek?
<highvoltage> lamont: crying? how so?
<lamont> Is there any way of getting the livecd tarball build to _NOT_ require install inetd and half the networking daemons in existance?
<lamont> wow.  that was almost english
<highvoltage> I understood it at least :)
<c_korn> is lucid going to have support for the SSD's trim command ? I read it will be in the 2.6.33 kernel.
<highvoltage> lamont: it currently tries to install that during the build? because it shouldn't
<lamont> iproute, tcpd, and openbsd-inetd are particularly offensive
<highvoltage> perhaps I accidentally made ltsp-livecd depend on ltsp-server (one moment while I check)
<lamont> ltsp-server depends on them, and ltsp-server provides ltsp-build-client and lts-update-image
<lamont> so I think you intentionally made it depend on ltsp-server
<highvoltage> we want ltsp-server to be shipped on the disc, not to beinstalled, I just checked and ltsp-livecd definitely doesn't depend on ltsp-server
 * highvoltage checks the seeds
<lamont> it's installed inside the chroot where we build the image
<lamont> which is what I'm bitching about
<highvoltage> just so that we're clear, inside the edubuntu chroot or in the ltsp chroot?
<lamont> on terranova is a build-lucid-live/chroot-lucid chroot in which we build build/chroot-live (which becomes the casper image), and the ltsp image chroot, which becomes your file
<lamont> my complaint is about ltsp-server's dependencies getting installed in build-lucid-live/chroot-lucid
<lamont> nbd-server belongs on the list too
<lamont> OTOH, we block all the services from starting, so it's not particularly bad, it just makes me want to stab myself in the eyes
<highvoltage> lamont: ok, I'm not sure where that comes from but I'll find out now and get it out, it really shouldn't be there
<highvoltage> lamont: heh, understood
<lamont> livecd-rootfs (installed in build-lucid-live/chroot-lucid) Depends: ltsp-server (to get those commands), which Depends: all kinds of crap that we don't actually start, so we don't actually need it.
<lamont> highvoltage: IOW, building the client image shouldn't be something that requires me to run it on the server.
<lamont> but that's a design bug that won't get fixed for lucid
<highvoltage> lamont: ok, I'm going to talk to stgraber, that package is in main so I can't change it myself, but I'll ask him to remove it and then give you a ping. thanks a lot for the feedback
<lamont> I won't let it block us this go round, but can we pretty please fix it for lucid+1?
<Keybuk> dear pbuilder, if I give you a changes file, you should know what to do - you're not bzr, you don't have to be pedantically annoying and difficult
<highvoltage> lamont: ok, for sure
<highvoltage> lamont: ok, so the fix for ltsp-server would be to add conditional dependencies on either something like dnsmasq and/or a dummy package that satisfies ltsp-server's dependencies (that would make you squirm less and we'd have a better looking livecd), unfortunately a dummy package would require a FFE and a promotion to main, so it will probably be done early in the M cycle.
<lamont> what's wrong with splitting the package into the part that builds the client and the part that needs the daemons?
<highvoltage> lamont: splitting it would require FFE's and main promitions right?
<lamont> yeah, for M
<highvoltage> lamont: yep, that could also work.
<lamont> because as soon as I upload 1.107, I'm going to file a bug against ltsp to split it, and then a bug against livecd-rootfs dependent on that bug to "NOT DEPEND: ltsp-server, but rather just the bits we need"
<lamont> I hate dummy packages
<highvoltage> so what would you recommend, having the scripts in a package that's something like ltsp-server-scripts and then have ltsp-server depend on that?
<lamont> they're nothing but clutter.  Also, I'd like to deploy ltsp in a couple of places, and can't use the packages, since the NFS server, tftp server, and dhcp server are 3 different machines, and no way I'm installing all of the daemons on all of the boxes
<lamont> yeah - that would be a good appraoch
<highvoltage> lamont: ok, great
<highvoltage> stgraber: nice timing :)
<highvoltage> stgraber: lamont suggess that (for the M release) the scripts from ltsp-server should rather go into something like ltsp-server-scripts that doesn't depend on anything, and then ltsp-server can depend on that
<highvoltage> stgraber: that also makes sense in the cases where (like his use case) people don't want everything on one server
<lamont> LiveCD/lucid/edubuntu/20100317.1/livecd.edubuntu-ltsp-20100317.1-i386.squashfs <-- highvoltage
<lamont> Squashfs filesystem, little endian, version 4.0, 55992121855 bytes, 38459 inodes, blocksize: 13 bytes <-- sound about right?
<lamont> the 13 byte blocksize seems a little funnhy
<highvoltage> lamont: *hug*
<highvoltage> lamont: yes it seems a lot funny
<lamont> it's also hardy's file command printing that
<lamont> anyway, once 1.107 is in lucid, wait a day and the image file will be there and you can pester the CD build process to deliver the file for you
<highvoltage> ok thanks, I'll look at it as soon as it's available
<lamont> yeah - seems there's this pesky beta1 freeze or something. :-(
<amitk> tearjerker
<cjwatson> so where does this "does not terminate at computer shutdown" apport thing come from?
<cjwatson> ah, /usr/share/apport/unkillable_shutdown
<sebner> cjwatson: do you know if "using stuff in Trash folder" will be fixed in Gnome3? I consider this as br0ken by design (gfvs) as you should be able to open an image (e.g on windows)
<cjwatson> sebner: hmm, do I have my fake plastic GNOME developer hat on or something? :)
<cjwatson> (I have no idea, I don't normally work on GNOME)
<slangasek> superm1: may I suggest http://mythbuntu.org/10.04/beta1 as a URL, since we're getting 2 betas this time 'round?
<seb128> sebner, what is broken?
<sebner> cjwatson: I see you as someone very wise and (nearly) omniscient :P
<sebner> seb128: broken by design. Files in Trash are not usable. e.g open a picture like it works unter windows
<cjwatson> sebner: not about this, try a desktop developer. :)
<seb128> sebner, how does it work under microsoft os-es?
<seb128> sebner, double clicking on an image in the trash do works in Ubuntu
<seb128> not sure what your issue is
<chrisccoulson> sebner - what image viewer do you use?
<sebner> seb128: not here, eog tells me about not found location and gvfs crashes :P
<sebner> chrisccoulson: eog
<chrisccoulson> hmm, it works fine here
<seb128> wfm
<sebner> videoplaying is also not working, with any player
<sebner> chrisccoulson: lucid
<sebner> ?
<chrisccoulson> sebner, yes
<sebner> chrisccoulson: weird
<cjwatson> wow, when I say "broken by design" it usually means I've confirmed this against the design ;-)
<superm1> slangasek, yeah that should be fine, i'll make sure the guys know
<slangasek> superm1: ok, thanks
<chrisccoulson> sebner, normally issues like that will arise for applications not using gio
<seb128> sebner, trash is a known uri for gvfs, any app using gio will be able to use it
<chrisccoulson> but that is not the case here
<seb128> sebner, if you have a crash send it using apport
<sebner> seb128: apport is too br0ken to send xD
<seb128> reinstall your box?
<seb128> it seems your install is screwed
<chrisccoulson> i was just thinking the same thing ;)
<sebner> seb128: not wondering. using it since lucid openend. I have to admit that it works *now* but I'm sure tomorrow I'll be able to produce a crash log
<sebner> chrisccoulson: lucid ftw! :P
<sebner> seb128: ever heard about apport complaining about not being able to send the bug report because there is no internet connection (when there *is* one) ?
<seb128> no
<seb128> do you use a proxy?
<chrisccoulson> sebner - there was a launchpad issue over the weekend. did you try recently?
<sebner> seb128: nope
<sebner> chrisccoulson: recently = 1-2 days ago, yes
<sebner> seb128: I guess my system is __really__ b0rken
<sebner> seb128: chrisccoulson : sorry for the noise and thx for your time :)
<chrisccoulson> yw ;)
<seb128> yw
<sebner> seb128: but playing videos is *not* supported I guess?
<seb128> ?
<seb128> you would image any modern operating system not able to play a video?
<seb128> oh, you mean from the trash
<seb128> totem should support gio locations just fine
<seb128> sebner, works there
<seb128> I just moved an ogg video in the trash and double clicked on it
<seb128> totem play it
<sebner> seb128: ah, here too (now), vlc is a bad boy then :)
<ion> vlc probably just doesnât know what to do with a gvfs URI.
<ion> Something like trash:///blah probably gets passed to it.
<sebner> kk :)
<seb128> yes
<seb128> ion, well if it does that's because it's .desktop is buggy
<seb128> hum, maybe not for trash: though, not sure about this one
<seb128> nautilus passes the .gvfs mounts for apps who don't handle uris
<Lord-Readman> hello
<Keybuk> I'm going to write  abot
<Keybuk> a bot too
<Lord-Readman> can someone please tell me the package that holds System > Administration > Printing in gnome ubuntu 10.04
<Lord-Readman> ?
<Keybuk> this bot, once a day, will go through all the bugs in LP that are at Confirmed or Triaged
<Keybuk> and will post
<Keybuk> THIS BUG IS STILL THERE!!!! OMG!!!!
<ion> That could be an internal feature of Launchpad.
<micahg> Keybuk: you should have the bot post it once for each subscriber...
<RAOF> ion: I'm sure that performance would be greatly improved with a local connection to the database :)
<cjwatson> Lord-Readman: here's how you find out:
<cjwatson> Lord-Readman: run System -> Administration -> Printing; open a terminal window and run 'xprop | grep WM_CLASS', then click on the window
<cjwatson> it says:
<cjwatson> WM_CLASS(STRING) = "system-config-printer.py", "System-config-printer.py"
<cjwatson> so run 'dpkg -S system-config-printer.py'
<cjwatson> system-config-printer-gnome: /usr/share/system-config-printer/system-config-printer.py
<elmo> is nano particularly highly scored in lucid or am I losing my mind?
<Lord-Readman> thanks
<rickspencer3> slangasek, for the beta announcement, should I remove things that were new in Alpha 3, but are no longer new for Beta 1?
<slangasek> rickspencer3: no, certainly not - the beta announcements are targeted to a different audience than the alphas
<rickspencer3> thanks
<rickspencer3> slangasek (that saves me a bit of work ;) )
#ubuntu-devel 2010-03-18
<crypt-0> what recent changes in bash make var=var=${var:0:40} invalid?
<crypt-0> *var=${var:0:40}
<crypt-0>        ${parameter:offset:length} is broken.
<Euyulio> how long till beta1?
<Keybuk> Euyulio: we need help with testing CD images before we can release beta 1
<Euyulio> lol alpha3 #&@! up my system
<Euyulio> was wondering if i could go to bed yet
<Keybuk> all the more reason you should help us test images before we declare a beta
<Keybuk> a 20100318 daily should be up, we'd appreciate any testing
<Keybuk> https://wiki.ubuntu.com/Testing/ISO
<Keybuk> in particular we're after testing Plymouth, https://wiki.ubuntu.com/Testing/Plymouth
<Euyulio> can i install it from this 9.04 cd
<Keybuk> that is not the kind of testing we need help with
<Euyulio> alright i'll check if i have a cd i'm tired & drunk, check-in will be a while
<superm1> slangasek, the images have been "rebuilding" since earlier today at http://iso.qa.ubuntu.com/qatracker/build/mythbuntu/all , is there something wrong?
<slangasek> superm1: yes, there was - bug #540256, now fixed
<ubottu> Launchpad bug 540256 in upstart "enter kills X when booting Live CD or w/cryptsetup with plymouth text plugin" [Critical,Fix released] https://launchpad.net/bugs/540256
<crypt-0> can someone run this code and confirm that bash *should* run it but does not? http://pastebin.com/57UV2Bb9
<johanbr> crypt-0, works for me
<crypt-0> johanbr, with sh script.name  or ./ script.name  ?
<johanbr> ./scriptname or "bash scriptname"
<johanbr> I think the string stuff on line 17 is a bashism
<crypt-0> ./script.name works for me sh script.name does not [rand-string.sh: 18: Bad substitution]
<slangasek> yes, because sh isn't bash
<slangasek> "bash should run it" - you're not calling bash when you type "sh" on Ubuntu
<crypt-0> ahh ok
<pitti> Good morning
<pitti> slangasek: bug patterns> ubuntu-dev has commit access to the bug patterns, FYI
<dholbach> good morning
 * pitti takes the plunge and updates wife's computer to lucid beta-1. OMG
<ravibn> Hi! I need help with my webcam
<ravibn> Hi! I have a problem with my Frontech ecam JIL 2214. When gstream-properties is used it works perfectly alright.
<ravibn> But when I use skype or any other application it does show blank
<ravibn> Can I re-direct this video from gstreamer to these applications ?
<\sh> jcastro: congrats dude
<Ng> pitti: if I'm seeing bug #275972 with a slightly different byte would you want that as a separate bug, or re-opening that one?
<ubottu> Launchpad bug 275972 in apport "apport-cli crashed with UnicodeDecodeError in ui_present_crash()" [Undecided,Fix released] https://launchpad.net/bugs/275972
<pitti> Ng: looks fine to reproduce that one, since it was never really investigated
<Ng> pitti: thanks, done
<Ng> pitti: I'm not super keen to attach my Xorg crash file to the bug, but I can make it available to you
<pitti> Ng: Xorg crash file? for apport?
<Ng> pitti: yeah, I was trying to report an Xorg crash when I got that unicode error
<pitti> Ng: perhaps put it on chinstrap and leave me the path in the bug report?
<Ng> k
<slangasek> NCommander, persia: will there be a separate release notes page for armel at https://wiki.ubuntu.com/ARM/LucidReleaseNotes as there was for last cycle, or are all the errata fixed? :)
<slangasek> asac: ^^
<pitti> jdong: if you have a minute, would you mind SRU-reviewing bug 476654? the other SRU team is quite busy with the beta-1 release ATM..
<ubottu> Launchpad bug 476654 in devicekit-disks "CD eject but not unmount when using drive button and CD is in fstab" [Medium,In progress] https://launchpad.net/bugs/476654
<slangasek> pitti: is bug #462704 still present in Lucid?  (and if so, should we be targeting it for fixing?)
<ubottu> Launchpad bug 462704 in ubuntu-release-notes "Crash when trying to set up wifi on Dell Mini 10v (Broadcom) in Kubuntu Netbook" [Undecided,Fix released] https://launchpad.net/bugs/462704
<asac> slangasek: most from the karmic page are fixed. do you want such a page for beta?
<asac> well ... the boards supported in karmic that had the issues are not supported anymore (e.g. no babage 2)
<slangasek> asac: I'm preparing the preliminary release notes, and want to know whether there will be such a page that I should link to - I don't have a preference for whether there will be one or not
<asac> slangasek: there surely will be release notes bits specific to arm, so i think it makes sense to keep it
<slangasek> asac: ok
<asac> unless you say that we should include such itesm in main release notes if the number of itesm is < X
<slangasek> asac: I was just about to say that ;)  Let's say < 5
<asac> with X being a number you define.
<slangasek> asac: yes, X = 5
<asac> slangasek: for now i would assume it will be > 5 ...
<slangasek> ok
<asac> but cant promise
<asac> ;)
<asac> but i think its safe to say that for now
<asac> will check with QA on our current issues today
<slangasek> StevenK: do you still have any plans to work on bug #439656, or is that irrelevant now that we're not shipping moblin remix? (haven't looked at what the proposed change was)
<ubottu> Launchpad bug 439656 in casper "Ubiquity installer should be in favorites for livecd" [Undecided,Confirmed] https://launchpad.net/bugs/439656
<cody-somerville> Is gnome-power-manager in lucid broken or something?
<cody-somerville> The following packages have unmet dependencies:
<cody-somerville>   ubuntu-netbook: Depends: gnome-power-manager but it is not going to be installed
<slangasek> cody-somerville: it's not broken, no; do you have something that conflicts with it?
<StevenK> slangasek: Irrelevant
<slangasek> StevenK: ok - want to mark it such? :)
<cody-somerville> slangasek, No. This is attempting to install the UNE task in a fresh chroot.
<slangasek> cody-somerville: out-of-date mirror, then?  we're in beta freeze, we certainly didn't leave core main packages uninstallable
<cody-somerville> oops. I think I know what the problem is. Will try again.
<alkisg> pitti: I think you're missing some important information on bug #460328, could I give you some feedback from Greece?
<ubottu> Launchpad bug 460328 in gnome-settings-daemon "Wrong keyboard settings when console-settings has multiple layouts" [High,In progress] https://launchpad.net/bugs/460328
<alkisg> "gdm is meant to pick precisely one keyboard layout (the one you want to
<alkisg> use by default), so we should not and will not support lists in gdm. "
<alkisg> That's an extremely wrong assumption
<alkisg> Many countries need 2 layouts *by default* and the PCs are unusable without 2 layouts
<pitti> alkisg: I think we have a different meaning of "default" here
<pitti> alkisg: of course you should have more than one layout available and configured in GNOME
<pitti> alkisg: but still, one of it must be set by default if you log in
<alkisg> E.g. in Greece it's *required* that we have [us,gr] as the preinstalled layouts, otherwise we can't even use a browser
<pitti> alkisg: I understand
<alkisg> So if gdm goes on to force the gconf key to just [us], it ruins our setup..
<pitti> alkisg: I'm using two layouts myself
<pitti> alkisg: it doesn't
<alkisg> Then I obviously misunderstood something
<pitti> alkisg: g-s-d should use $GDM_KEYBOARD_LAYOUT to pick the one it sets by default
<pitti> but it wouldn't remove existing layouts
<alkisg> The default is not to have any layout in that gconf key
<alkisg> gdm sees that none exists, so it adds a [us] there
<pitti> well, it should have [us,gr] in gconf
<alkisg> What package is responsible to put [us,gr] there?
<pitti> alkisg: oh, you mean right after installation? yes, that'd be a problem
<pitti> alkisg: gnome-settings-daemon
<alkisg> I assume g-s-d can't use /usr/share/gconf/defaults, as it's country-specific
<pitti> alkisg: thanks, I'll keep that in mind (first-time install case)
<alkisg> pitti: ok, thanks
<pitti> but once you have a sensible list of mappings in gconf, the main bug that I see is that the layout that you select in gdm doesn't become the default
<alkisg> So if gdm sees an empty value there, it should put all the layouts in the gconf key, not just the first one
<pitti> right
<alkisg> Yeah, we'd be fine with that, thanks :)
<pitti> (it's g-s-d, but nevermind)
<alkisg> Ah, ok
<alkisg> pitti: About gdm, it would be best if there was an additional entry there: "use the system default layout". This doesn't need any UI change. When a user selected that, the layouts from /etc/default/console-setup would be copied to the gconf key
<alkisg> So without actually supporting multiple layouts, you still enable gdm to work fine in countries like greece
<alkisg> (I'm talking about the combobox where the layout is selected in gdm)
<pitti> alkisg: it actually uses the system default layout to set the default value of the keyboard picker
<pitti> alkisg: I'll figure something out between gdm and gsd
<pitti> I think I really understand the problem now, and can replicate it
<alkisg> pitti: it uses just [us] for greece... ok, thanks again
<alkisg> And sorry for the direct ping :)
<pitti> alkisg: no problem :) I'm here for that reason
<jdub> Keybuk: about?
<jdub> still having problems with rsyslogd -- now getting "imklog: Cannot read proc file system, 1." with a supported kernel, 2.6.32-302-ec2
<daniel1234> Hi, where should I go to ask about apparmor profiles (of openldap in ubuntu specifically), and packaging guidelines?
<daniel1234> I have a service that I want to write a profile for, that service is using slapd. slapd already has a profile, but it doesn't cover the directories I need. Apparmor doesn't support having multiple profiles for one binary and it doesn't support "inheritance".. And you shouldn't touch files from other packages
<daniel1234> afaik at least.
<ev> kwwii: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/368060
<ubottu> Ubuntu bug 368060 in ubiquity "Map of Kashmir when selecting the timezone is incorrect" [High,Triaged]
<cnd> if I build a test version of an ubuntu package for a ppa, I should increment the version and add ~<something> to it?
<cnd> so if the package is currently version 0.3, I should make it 0.4~test?
<daniel1234> i'm not a packager, but i'dd say that you shouldn't increase the version that the package already has, so 0.3~test1 or something like that
<slangasek> That depends on what the package you're preparing is.  If it's a test version of a package that will be uploaded to the archive later, you want it to sort earlier than the eventual to-be-uploaded version, but *later* than what's already in the archive
<slangasek> so <upstream_version>-<debian_version>ubuntu<next_ubuntu_version>~test is pretty typical
<cnd> slangasek: ok, I think I've got my package versions right then
<cnd> thanks
<tseliot> Riddell: currently ServerAttempts is set to 1 in kdm. Shall I set it to 2 in order to make it retry if it fails the 1st time?
<Riddell> tseliot: is that a change from upstream?  does that interract with the bulletproof X stuff?  (I don't even know if bulletproof X still works in KDM)
<tseliot> Riddell: that's in our current source code (kdm/config.def). I have no idea abour bulletproof X in KDM either
<tseliot> Riddell: kubuntu_33_kdm_bulletproof_x.diff seems to hardcode that variable to 3
<Riddell> tseliot: mm, I wonder why that is
<Riddell> tseliot: but I guess that answers your question :)
<tseliot> Riddell: yes but at least you reminded me about bulletproof X. I'll make sure that my patch and that one don't conflict
<micahg> it seems like there's no hope for people me too'ing bugs....
<nigelb> micahg: what happened?
<micahg> nigelb: that plymouth bug
<nigelb> micahg: I wish bug control could turn the option off after sometime
<slangasek> micahg: not to worry though, they reapplied an image that had plymouth installed just this morning so they're legit to comment
<micahg> slangasek: k...
<slangasek> :)
<micahg> slangasek: It's just "funny" to watch you and pitt-i change the bug and then still have people comment
<slangasek> I remain firmly convinced that non-bugcontrollers should not be allowed to comment on bugs they didn't open
<slangasek> well, bugsquad I suppose
<micahg> slangasek: well, that's not good in some cases if some users are more technical and can more easily provide debugging information
<slangasek> micahg: they can file a new bug, and a triager can mark whichever report is better as master
<slangasek> the vast majority of users are not technical enough to correctly identify bugs as duplicates
<micahg> slangasek: interesting point...maybe we should bring this up in the next meeting
<cnd> pitti: slangasek: I sent out a CFT for pm-utils-powersave-policy to ubuntu-devel, but it's awaiting moderator approval
<jdub> jdstrand: will you be pushing a new ufw to lucid?
<slangasek> cnd: I'm not a moderator of ubuntu-devel
<cnd> slangasek: do you know who I should ping? or should I just wait?
<slangasek> cnd: also, I see it in my mailbox, so it seems to have been moderated :)
<cnd> slangasek: ahhh, cool
<slangasek> cnd: "slated for inclusion in lucid" - errr, no, I told apw in the release meeting two weeks ago that this was beta-1, or Lucid+1
<cnd> slangasek: the package is already in lucid, just without many scripts
<cnd> and it's still listed as a beta-2 activity on the blueprint
<apw> slangasek, yep thats my understanding
<cnd> https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-laptop-mode-tools-integration
<apw> cnd, that task is specifically for beta-2 yes, but note it says "in a PPA" at the end
<apw> and the 'in lucid' form of the task is postponed to MM
<cnd> ahhh, ok I was confused
<slangasek> cnd: "10 second audio codec power down" - this was explicitly *disabled* this cycle, again, because people were still getting popping; if we were going to release it, it needed to stay enabled through the cycle for testing and fixing if it was going to release
<slangasek> apw, cnd: ok, glad that's straightened out then :)
<slangasek> (FWIW, I think it was a mistake to redisable the audio codec powerdown when we did, but it's done now and nothing for it)
<apw> as i understand the plan we wanted to complete the work so it didn't need to be started all over again for M and not make it in time there either
<cnd> slangasek: this enables the power down only when on battery, in the past it was enabled through a module param at boot
<apw> slangasek, yeah specially as even with it disabled i get the popping :)
<slangasek> apw: heh
<apw> either that or disabling it didn't work
<slangasek> cnd: well, I see no reason not to enable that setting even on AC if it works, and no reason to tolerate the popping even on battery if it doesn't :)
<cnd> true
<apw> slangasek, right it either works or not, whether we have a battery is not the reason to change it
<apw> any more than turning on or off video downclocking is a battery based feature
<cnd> For me, if there's popping I don't want it when I'm plugged in cause it's annoying
<cnd> but I want the battery life when not plugged in
<mathiaz> pitti: hi - I'm reviewing bug 531978
<ubottu> Launchpad bug 531978 in vsftpd "Apport hook for vsftpd" [Wishlist,Confirmed] https://launchpad.net/bugs/531978
<cnd> so I'm willing to deal with popping in that case
<mathiaz> pitti: it adds a apport hook that uses ui.yesno("..
<slangasek> cnd: and for me, I'm willing to deal with the popping in both cases in order to save power, but I don't think either of those is a good default policy for the distro :)
<mathiaz> pitti: does this mean a UIFreezeException is required?
<pitti> mathiaz: I wouldn't go as far as requiring UIF for apport hooks
<mathiaz> pitti: so text used in ui.yesno() is not automatically translated?
<pitti> mathiaz: no; at this point (for reporting bugs) you need to speak English anyway
<pitti> mathiaz: well, of course you could call gettext for it, build .po files, etc., but I don't think it's worth the effort
<slangasek> pitti: fighting the urge to amuse myself by presenting counterexamples from LP
<slangasek> :)
 * mathiaz wonders if apport could enforce the "you need to speak english to report bugs to Ubuntu"
<pitti> slangasek: well -- yes :/
<seb128> slangasek, those are usually closed though with a request to open a new one in english
<slangasek> oh, is that what I was supposed to do
<slangasek> oops
<seb128> I don't think there is agreement on that
<micahg> seb128: idk about that
<seb128> but that's we do for desktop and what some active triagers do
<seb128> micahg, "idk"?
<slangasek> "i don't know"
<seb128> ah
<micahg> I usually try google translate, but I think the consensus was to subscribe the translations team
<seb128> well, there is so many bugs open anyway
<slangasek> I tend to reply to them myself for the novelty ;)
<micahg> or open a task in the translations project..can't rememberr which one
<seb128> there is no point to spend efforts trying to get one translated
<seb128> if the issue is one users care about somebody will open an english bug soon enough anyway
<seb128> often non english bugs are rather support requests than bugs anyway
<micahg> seb128: 1.  Sometimes things are lost in translation, 2. Ubuntu's internation base is growing, 3.  We have locos in a lot of places, maybe they can help
<seb128> micahg, I don't see the point of vasting efforts on that
<seb128> we already don't read half of the bugs we get, ETOOMANY
<seb128> what is the point to waste efforts to add extra ones with lower quality or hard communication with submitter
<pitti> it'd just mean to spend tons of manhours for somethign that we don't even want to encourage, IMHO
<pitti> we do NOT have the problem of having too few bug reports
<pitti> and people have to go through Launchpad either way, so it wouldn't be worth the effort unless it's done all the way through
<pitti> cnd: seems someone moderated it, thanks!
<tseliot> Riddell: do you know who wrote kubuntu_33_kdm_bulletproof_x.diff?
<slangasek> tseliot: IIRC, the debian/changelog attributes it
<tseliot> or do you know his nickname?
<tseliot> it's Eugene Tretyak
<tseliot> slangasek: yes, but nicknames are not there, unfortunately ;)
<cjwatson> launchpad.net/people is sometimes helpful for this
<Riddell> tseliot: etretyak but he hasn't been around for ages
<tseliot> good point
<tseliot> oh
<tseliot> Riddell: I can either merge my patch for plymouth with that patch or make my patch depend on that patch (which I will have to edit). Which one do you prefer?
<Riddell> tseliot: merging is fine, probably easier not to have overlapping patches
<tseliot> Riddell: yes, that's easier for me but I had to ask since I'm not the maintainer ;)
<Riddell> tseliot: oh we can fix that :)
<tseliot> Riddell: no, we can't :-P
<researcher1> which is the IRC channel for ubuntu 10.04?
<Laney> for support? #ubuntu+1
<tseliot> Keybuk, slangasek, Riddell: do you think pseudo-code this is correct? http://pastebin.ubuntu.com/397327/
<jdong> pitti: ok, just had a chance to look at bug 476654; it looks good
<ubottu> Launchpad bug 476654 in devicekit-disks "CD eject but not unmount when using drive button and CD is in fstab" [Medium,In progress] https://launchpad.net/bugs/476654
<slangasek> tseliot: why call 'plymouth quit' before restarting X?
<slangasek> (though, I don't see why you wouldn't call failsafe-X immediately, if starting failed the first time)
<Keybuk> right, with slangasek here
<Keybuk> you call plymouth quit because you've given up starting X servers
<Keybuk> it resets the terminal to text mode, switches to VT1, etc.
<Keybuk> so it'd be before you called failsafe X (in case that too failed to show up)
<tseliot> right, we don't want KD_GRAPHICS
<slangasek> Keybuk: in this case, it'd be after failsafe X, because kdm doesn't hook into the failsafe X upstart job, it spawns the server directly...
<tseliot> slangasek, Keybuk: when shall I call failsafe x then?
<Keybuk> slangasek: right, good point
<slangasek> tseliot: well, the *right* way to do it is to make kdm parallel what gdm does: exit with a special code on X server failure, trigger the separate failsafe-x upstart job.  But that's not realistic for Lucid
<tseliot> slangasek: oh, I misread your sentence
<slangasek> tseliot: for now, I think it should immediately fall back to failsafe-x, without trying to restart the normal X server at all
<tseliot> slangasek: so, I should try to stop plymouth and start failsafe X after that
<tseliot> ok, it's even easier
<pitti> jdong: cheers
<slangasek> tseliot: I think 'stop plymouth' belongs after 'start failsafe X' as part of the common cleanup path
<tseliot> slangasek: but if we're still in KD_GRAPHICS I won't be able to start X (failsafe X in this case)
<tseliot> or am I missing something?
<slangasek> tseliot: I don't know the terminology, but I know gdm doesn't call 'plymouth quit' until after the X server is started
<tseliot> slangasek: right, I can see that in the plymouth_transition patch. I'll trust whatever gdm does then ;)
<tseliot> and do the same in kdm
<slangasek> tseliot: explanation from #ubuntu-release yesterday: http://pastebin.com/aSuFz7YW
<tseliot> slangasek: right, I guess this confused me a bit though:
<tseliot>      if the X server starts ok
<tseliot>        call plymouth quit --retain-splash
<tseliot>      if the X server *fails to start)
<tseliot>        call plymouth quit
<slangasek> tseliot: yes; that's because if gdm can't start the X server, it gives up and a different job picks it up
<slangasek> or, perhaps, doesn't pick it up :)
<slangasek> kdm should only call 'plymouth quit' when it gives up
<tseliot> slangasek: so that's what I was missing
<slangasek> or after it's started the X server successfully
<tseliot> ok
<psusi> shouldn't device mapper devices default to using the noop scheduler instead of cfq?  don't need a scheduler on top of a scheduler on top of a scheduler do we?  should this be done in libdevicemapper or by udev I wonder?
<jaycount> Say if a student-developer wants to get started in open source development, is Ubuntu a good place to cut teeth?
<mathiaz> slangasek: IIRC for daemon using upstart, the default file should go away and be merged into the upstart job?
<cjwatson> It depends.  Distributions are a good place to get lots of variety, as long as you don't mind occasionally being told that you should go upstream.  People who work on distributions tend to quickly become expert build system engineers, and also get lots of direct contact with end users so it's excellent if you like maintaining and integrating code and trying to turn things into a polished product.
<cjwatson> jaycount: ^-
<kklimonda> jaycount: that depends - Ubuntu takes most of its software from the upstream so they may be a better place to start if you want to write some code.
<slangasek> mathiaz: typically yes, though I am loathe to do that without migrating settings on upgrade
<cjwatson> jaycount: If the student has some particular burning interest in a particular application, or whatever, then it's best to go straight to the source, as kklimonda says
<cjwatson> jaycount: although there's lots of software that's upstream-maintained by people who started out as distribution developers, either because it was written specifically for that distribution, or because nobody else was doing it so the package maintainer took it over
<jaycount> The upstream... you'll have to help me with that particular piece of jargon
<tseliot> upstream = the original authors
<jaycount> ahhhhh
<pitti> jaycount: it's generally the direction where code flows from/to from a particular person's perspective
<cjwatson> http://en.wikipedia.org/wiki/Upstream_%28software_development%29
<jaycount> I've been sitting around idle looking for an open source project to get started with and I'm comin up blank. I don't wanna get started on a project that's too big and just get caught in a bunch of devs but I don't wanna go into a small project that's just a remake and is going to fail
<jaycount> Really I just want to get some real life experience. I'm 2 years from  graduating and have no real world experience
<pitti> jaycount: e. g. lxde is a downstream from our side, since they base their distro on ubuntu; debian is upstream because we derive from them; and of course all the projects like gnome/firefox etc. are "upstream" from our POV
<jaycount> pitti, makes sense. thanks
<tseliot> right, it's a relative concept
<jcastro> jaycount: https://wiki.ubuntu.com/UbuntuDevelopment
<jaycount> jcastro, thanks for the link
<kn100> I just booted into my lucid setup today and my resolution is set at 1024x768 and won't let is any higher
<kn100> it's a nvidia card, and I am using the proprietary drivers
<tseliot> kn100: try nvidia-settings perhaps?
<kn100> tseliot, the higher resolutions aren't available
<kn100> tseliot, it worked fine yesterday
<kn100> I can't say it definitely is a lucid update, but that's the only change I remember making yesterday
<tseliot> kn100: are you sure that the driver was loaded correctly?
<tseliot> kn100: can you put /var/log/Xorg.0.log on pastebin, please?
<kn100> tseliot, well nvidia-settings is open and compiz is rendering as beautifully as ever along with my card not being span up to full like it does with the oss drivers, so I think so
<tseliot> also the output of "dmesg" might help
<cjwatson> jaycount: it doesn't work for everybody, but it works well for some people.  Lots of people (like me) got involved with Debian a bit before graduating, and ended up making a career of it
<kn100> tseliot, I'll get you both :)
<cjwatson> (Ubuntu didn't exist when I graduated)
<kn100> tseliot, both can be found here http://pastebin.com/LxKM2a4p
<ScottK> Heh.  Debian didn't exist when I graduated (nor Linux for that matter).
<kn100> tseliot, thanks for any help, and alphas are fun huh :P
<jaycount> good stuff on that ubuntu dev site, I'll prowl around some. thanks guys
<ogra> ScottK, that would have been a reason to wait with graduation !
 * cjwatson passes ScottK the honorary zimmer
<tseliot> kn100: it looks like (somehow) the driver can't read the EDID of your monitor. There are ways around it. Can I see your xorg.conf too, please?
<kn100> tseliot, of course :)
<kn100> tseliot, it's a dvi > vga adapter for the monitor, I didn't have any spare dvi cables
<pitti> cjwatson: "zimmer"? (that's German for "room"..)
<Laney> "zimmer frame" â comes from the name of a company
<maco> pitti: wait so mdz's last name...?
<slangasek> maco: "Chamberlain"
<tseliot> :-)
<pitti> maco: right, "Zimmerman" == "Carpenter" in German :)
<pitti> well, Zimmerman_n_
<cjwatson> and Carpenter is a fairly common surname in English
<slangasek> oh, carpenter?  huh
<maco> slangasek's translation is funnier
<alex-weej> since karmic and now on lucid alpha, my system has been scanning my ext4 root partition every single boot... is there any way to debug this, maybe get it to print out out the reason it decides to scan?
<slangasek> Laney: we don't have Zimmer frames over here, just walkers :)
<kn100> alex-weej, I also have that issue, and ureadahead exits with some status error right
<kn100> also tseliot my xorg, http://pastebin.com/S15rcGH4
<Laney> It's one of those names that has entered common parlance, like Hoover
<pitti> alex-weej: you mean really extensively?
<pitti> alex-weej: there has been a quick fsck at every boot forever
<alex-weej> pitti, well it's quick i guess because it's ext4, but it still takes 10-20 seconds or so
<pitti> alex-weej: ok, that's the "extensive" category already
<alex-weej> pitti, you know i may be falsely diagnosing this then...
<pitti> it usually should take a fraction of a second to see  that they are clean
<alex-weej> i assumed it was taking 10-20 seconds because my system does nothing for a while whilst i can hear some sort of disk activity, and then it prints the usual fsck "clean" message
<alex-weej> maybe bootchart will help?
 * psusi hates seeing bugs that have gone unfixed in thunderbird since 2004.. maybe it's time to find a new mail client...
<pitti> alex-weej: it might also be readahead, and fscking afterwards; hard to tell
<pitti> alex-weej: bootchart will definively show it, yes
<alex-weej> pitti, i will have a look now thanks
<tseliot> kn100: I guess there's no other way to solve your problem so
<tseliot> You can use nvidia-settings to get your EDID info. Run nvidia-settings, click on DFP-0 (or whatever your monitor is listed as), then click "Acquire EDID..." and save the file somewhere in your home directory (you may want to move it to another place after this though e.g. /etc/X11/
<tseliot> Then add something like this in the "Device" section of your xorg.conf:
<tseliot> Option "CustomEDID" "DFP-0:/etc/X11/your_edid_file"
<kn100> tseliot, any idea what might be going wrong? think I should try updating to see if any patches have come through
<tseliot> (replace DFP-0 with your monitor, which seems to be CRT-0, at least in the log)
<tseliot> kn100: (replace DFP-0 with your monitor, which seems to be CRT-0, at least in the log)
<tseliot> kn100: and I have no idea about the real cause of the problem. The driver is closed
<NCommander> what's the proper way to load a module at boot time? I'm packaging something that requires a specific kernel module to be loaded (it also includes a udev rule, but the rule doesn't load the module, nor am I sure if thats possible)
<slangasek> NCommander: by having it set proper aliases so udev loads it automatically
<NCommander> slangasek: aliases?
<slangasek> NCommander: /lib/modules/$(uname -r)/modules.alias
<kn100> tseliot, sorry for the constant join/parting, my internet has been as reliable as a donkey with no legs for the past week or so. Have you said anything?
<tseliot> kn100: I said that I have no idea about the real cause of the problem. The driver is closed.
<kn100> tseliot, switching back to the free ones doesn't fix it
<kn100> tseliot, and i like to use my hardware :)
<tseliot> kn100: if you do what I suggested you should get your resolution back
<kn100> tseliot, I didn't get anything you said
<kn100> tseliot, as in i physically didn't receive it, my modem kept rebooting
<tseliot> kn100: ok, let me put the instructions on pastebin (I don't want to spam the room with my instructions)
<kn100> tseliot, ok
<tseliot> kn100: http://pastebin.ubuntu.com/397366/
<kn100> tseliot, OK i'll try that if this update doesn't fix it
<tseliot> ok
<alex-weej> pitti, turns out it is ureadahead after all... the fsck.ext4 does indeed take a fraction of a second
<pitti> alex-weej: ok, *phew*
<alex-weej> still, there's nothing on screen for 8s -> 31s while ureadahead and plymouthd are running
<Laney> Would it be possible for someone to subscribe ubuntu-cli-mono-dev to all packages it can upload?
<Laney> I want a nice +packagebugs page... hopefully this can be done easily with the LP API
<Laney> although if that would cause bugmail to go to all team members, obviously not
 * Laney hopes that would not be the case
<seb128> it would if the team has no mailinglist
<Laney> yeah, it doesn't
<seb128> so set one ;-)
<Laney> is there a /dev/null solution?
<seb128> setting a list
<Laney> someone in the DMB will need to do that
<Laney> I guess an LP list would be fine
<seb128> right
 * Laney requests any passing DMB reader to do so
<smoser> pitti, are you around ?
<psusi> I thought that the kernel did not create a dev node for the extended partition.. as in the container itself, not the partitions in it?
<cjwatson> Laney: nominate an address
<cjwatson> Laney: or do you want me to create an LP list attached to ~ubuntu-cli-mono-dev?
<pitti> hi smoser
<smoser> I'm looking at http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/eucalyptus/lucid/annotate/head%3A/debian/source_eucalyptus.py . after working through some bugs in it, i'm to the point where I'm spinning in apport-cli (http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/lucid/apport/ubuntu/annotate/head%3A/bin/apport-cli) ~ line 208.  the files attached in the first link are large
<cjwatson> Laney: when I try that, it says "Ubuntu mailing lists should not be created here. Create them at lists.ubuntu.com instead.", although there's still an "Apply for Mailing List" button
<cjwatson> lamont: is it OK to create a list for ~ubuntu-cli-mono-dev on LP?  It seems a bit ... special-purpose for lists.u.c somehow?
<smoser> i do think its making progress, but it is very slow. is there a better way to attach large files ?
<Laney> cjwatson: I'm not fussed where it ends up... the main reason is so that I can get the team subscribed to all of the packages
<Laney> although maybe lists.u.c would be better so that it subscriptions can be open (don't know if the LP list would be)?
<cjwatson> Laney: well, once the list exists, you can certainly do the mass subscription yourself; distro_source_package has an addBugSubscription method
<Laney> cjwatson: I can't as I'm not a team adin
<cjwatson> LP list subscriptions wouldn't be open because you'd need to join the team
<Laney> admin*
<smoser> the files sizes are:  12M axis2c.log   10M cloud-debug.log   4.0K httpd-cc_error_log
<smoser>  26M cc.log      8.9M cloud-output.log
<smoser>  . I dont think it makes a lot of sense to show the user these through a pager.
<Laney> I can just give someone the script to run on my behalf though
<pitti> smoser: in that line it just compresses the data
<lamont> cjwatson: I don't see why not - is it creating enough volume on ubuntu-mono to warrant its own list?
<cjwatson> Laney: oh, indeed, it's restricted to Launchpad/team admin
<pitti> smoser: oh, sorry, it uncompresses it; apparently you chose to show the report?
<cjwatson> lamont: that team doesn't have a contact address right now; I'd be happy to set it to ubuntu-mono, if that's the right thing to do
<cjwatson> Laney: ^-
<smoser> hm.. i didn't htink i chose to. its apport-cli. just a minute i'll walk through again.
<cjwatson> (I wasn't aware of that list)
<pitti> smoser: we probably might not show values which are larger than a certain threshold
<cjwatson> ubuntu-mono seems to be getting bugmail already
<Laney> I don't know what ubuntu-mono is
<Laney> it's probably for that MOTU mono team
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-mono/
<smoser> pitti, i never answered that i want to see the log
<Laney> cjwatson: looks good then
<cjwatson> yes, it's getting bug notifications for MOTU Mono Team
<cjwatson> but two teams can't have the same contact address AFAIK
<pitti> smoser: ah, it's building the paged details before asking the question
 * Laney rolls eyes
<pitti> smoser: it should only build it if you agreed to showing it
<smoser> yeah, and i think the threshold is a good idea too
<smoser> there is no sense in sending dozens of megabytes to a pager
<smoser> no human is going to look at that.
<smoser> for EucalyptusCloudOutputLog, its spinning for minutes at this point
<psusi> so what are the odds on getting a patch in for lucid to fix parted to be able to manipulate partitions on a disk that has other partitions in use on it, like it could in karmic?  seems upstream tore out the code that used the new ioctls because it didn't check for errors removing partitions that were in use
<psusi> I'm seeing about putting it back in, with the correct error checking
<cjwatson> Laney: I don't know what to do here - if you want a list on lists.u.c, perhaps you could mail RT for it?
<Laney> cjwatson: I'll see if the subs can be moved over from ~mono
<ccheney> what time today is the beta freeze lifted?
<Laney> and then the mailing list moved over
<Laney> well, removed from ~mono
<directhex> ccheney, good question - i'm waiting for an archive admin to be freed from the shackles of freeziness & sync banshee
<ccheney> i'm prepping a OOo 3.2.0 upload using new deb format 3 so need to do some testing with it asap :)
<cjwatson> ccheney: it'll be tomorrow now, the respins yesterday pushed us back
<ccheney> cjwatson: ok no problem
<directhex> ccheney, debsrc 3.0? you trailblazer you!
 * ccheney will probably throw it in a ppa for early testing tonight
<ccheney> directhex: yea debian switched over already so i will follow them, easier than debugging the 1.0 stuff
<pitti> ccheney: we have quite a bunch of 3.0 packages in the archive now
<directhex> one of them's mine
<ccheney> also means we won't have a 100MB diff.gz anymore :)
<directhex> would be hellish to do moon with debsrc 1.0
<cjwatson> ccheney: (you know we don't support multiple .orig tarballs yet, right?)
<ccheney> pitti: yea i saw some of the comments about getting them in a while back, sounds like i shouldn't have any trouble assuming the rules file is ok
<ccheney> cjwatson: uh, we don't?
<directhex> cjwatson, you don't? it's in the archive & working...
<cjwatson> openssh is much more manageable as 3.0 (quilt)
<cjwatson> directhex: where?
<cjwatson> I was sure that was still unsuppoed
<cjwatson> unsupported
<ccheney> isn't that the main point of 3.0 support?
<cjwatson> no?
<directhex> cjwatson, http://packages.ubuntu.com/source/lucid/moon
<directhex> cjwatson, don't think bzr plays nice with it though
<directhex> for bzr buildpackage foo
<cjwatson> directhex: gosh
<cjwatson> I stand corrected
<ccheney> ok well i'll find out if we support multiple tarballs when i upload tomorrow i guess :)
<ccheney> the new OOo has 5 tarballs
<cjwatson> ccheney: the main point is to integrate patch systems into dpkg proper, but there are various other fringe benefits
<ccheney> cjwatson: ah ok
<ccheney> even at 5 it is still a grouping of tarballs of tarballs, heh
<directhex> oo build system is nutty
<directhex> and fruity
<cjwatson> obviously being able to get rid of tarball-in-tarball packaging is good as well, but the number of packages with multiple orig components is quite small (even if the packages themselves tend to be significant) so it can't really be described as the main point I think
<zyga> mvo: is there any way you could help me extract install scripts from all packages in the archive?
<zyga> mvo: I want to make a list of packages that need c-n-f related meta-data, a simple grep for 'update-alternatives' in the install script will solve that
<directhex> cjwatson, the big issue with debsrc 3.0 is backportiness... launchpad will reject debsrc 3.0 uploads for pre-lucid, including PPA uploads. which is vexatious for the whole backporting thing
<ccheney> directhex: eh, so i can't upload a debsrc 3.0 lucid ppa package?
<ScottK> You can for Lucid only.
<directhex> ccheney, lucid yes, but not karmic & earlier
<ccheney> ScottK: ah ok, i misparsed the sentenced
<ccheney> ed /d$//
<ccheney> directhex: lucid is a LTS so no need to backport past that ;-)
<cjwatson> directhex: for anything that isn't multiple-orig and doesn't have include-binaries switched on, it should just be a matter of rm -f debian/source/format
<cjwatson> directhex: it's fairly easy to glom any 3.0 package back to 1.0; you might not want to maintain the result afterwards (frex, worst case, just make it a giant native tarball, PLEASE DON'T DO THIS FOR OOO), but it would *work*
<micahg> cjwatson: I've noticed also packages are having the patch system stripped from build-dep as well
<ccheney> cjwatson: oh i don't need to do that for OOo we have the rules hacked to support 1.0 its just not well tested
<cjwatson> micahg: as is right and proper for 3.0.  but you don't *need* a patch system for 1.0
<micahg> cjwatson: right, but if there are patches, it needs to be added back...just noting that
<cjwatson> no, that doesn't hold
<cjwatson> in an unpacked 3.0 format package, all the patches are applied by dpkg
<cjwatson> therefore, just leave them in the applied state when you pack it back up in 1.0 format
<cjwatson> easy
<micahg> cjwatson: ah, ok, that's what you meant by not maintainable :)
<cjwatson> presumably for a backport you don't care anyway - if you're maintaining a backport as a non-trivial branch, you're probably doing it wrong
<micahg> cjwatson: yep, I just missed that originally
<ccheney> the OOo tarball for debian is only ~ 250K and only 2.1MB for Ubuntu, much better than the old diff.gz
<ccheney> er debian specific OOo tarball i meant to say
<smoser> pitti, i linked a branch to bug 486122 , which is what a dupe of the same issue i was talking about above.
<ubottu> Launchpad bug 486122 in apport "crashes when trying to show details with very large attachments" [Low,Triaged] https://launchpad.net/bugs/486122
<zyga> is there an easy way to know dpkg --print-architecture and (python) os.uname() values for amd64, ppc64 and arm?
<kees> if policykit-1 is "current", can we drop polickit from lucid?
<\sh> what was the magic kernel append param to disable the switch to colour frame buffer ?
<\sh> nomodeset or something?
<pitti> kees: I'd love to, but there's still a couple of universe packages which need it
<zyga> \sh: I think it's listed when you select F3 or F4
<zyga> \sh: (in grub menu screen)
<pitti> smoser: thanks, will have a look
<\sh> zyga: I don't have grub ;) I'm directly booting via pxe + dhcp + tftp a kernel ;)
<zyga> \sh: I think your guess was right, nomodeset, I can tell you for sure if you wait
<slangasek> \sh: no, "nomodeset" is a switch to disable KMS support in your video driver, and is exclusively a workaround for kernel+X bugs
<smoser> pitti, no hard feelings if you don't like hiding long files, but i do think there is no point in building the massive string if not being shown.
<pitti> smoser: right; that is obvious, it should be moved inside the if block
<pitti> kees: it's in universe now, at least
<rafiyr> nothing like a disk less workstation for some peace and quiet in the office
<slangasek> there is no switch to disable color framebuffers; there are switches to do other things which might disrupt your framebuffer display as a side effect
<\sh> slangasek: ok...how do I tell nowdays ubuntu kernel to not switch into framebuffer at all? looks like a ESX VMWare machine doesn't like it somehow
<rafiyr> (in resp to \sh)
<slangasek> \sh: if you boot without 'splash', then plymouth won't try to *use* the color framebuffer
<slangasek> but fbcon is still loaded and used as your default console
<\sh> slangasek: I don't have plymouth or something like that
<slangasek> then I have no idea what problem you're experiencing
<slangasek> maybe you're screen is blank *because* you don't have plymouth
<mvo> zyga: I have a script that can run over a local mirror that could help with that I guess
<slangasek> s/you're/your/
<kees> pitti: okay, cool
<\sh> slangasek: well not blank...but the last line is "Console: switching to..." and then *bing* stop
<zyga> mvo: is your script ready for that? (to produce list of packages that use update-alternatives)? If you give me the full list of packages I'll patch each one with meta-data myself
<\sh> I'm trying to debug it now...and wonder how can someone prevent the kernel from doing this switch
<slangasek> \sh: what does it say it's switching to?
<\sh> Console: switching to colour framebuffer device 80x30
<slangasek> the only way to prevent it is by preventing fbcon from loading, and there's no setting for that
<\sh> slangasek: initramfs magic?
<slangasek> \sh: is this lucid?
<\sh> slangasek: yes
<mvo> zyga: it will need a bit of tweaking, I can give it a go tomorrow
<slangasek> \sh: then unless you also have cryptsetup installed, fbcon isn't in your initramfs
<zyga> mvo: great, if I can write the script for you just tell me please
<slangasek> \sh: you could use 'break=init' to stop the initramfs before switching to the rootfs and fiddle by hand
<superm1> pitti could you take a look at http://pastebin.com/SGZyUmPa ? it appears to handle the immediate error i'm seeing with 540375, but i was hoping to get your eyes on it too
<\sh> slangasek: ok...let me try and debug this...trying to get fai + ubuntu lucid to work properly
<mvo> zyga: all it really takes is a "find" and "dpkg -I libnet1_1.1.4-2_i386.deb postinst|grep update-alternatives" I guess
<zyga> hmm, right
<mvo> zyga: if you write it and mail it to me I will run it on a local mirror
<pitti> superm1: hm, it was actually intended that way
<zyga> ok, any hint on how the mirror path/directory layout looks like?
<mvo> zyga: plus it needs to filter out the non-lucid packages from the mirror, so its probably not that trivial
<zyga> mvo: I can do that in another step, I want to hit as many packages as I can now
<pitti> superm1: I duped it to bug 540750
<ubottu> Launchpad bug 540750 in jockey "pops up "Download of package indexes failed" when offline" [Medium,Triaged] https://launchpad.net/bugs/540750
<mvo> zyga: its a pool/ direcotry that has all the debs from multiple distro relesaes
<zyga> mvo: ok, I'll figure the rest out - thanks
<mvo> zyga: the mirror will just look like archive.ubuntu.com/ubuntu/pool etc
<mvo> zyga: cool, thanks
<zyga> mvo: it's not perfect but: for pkg in /var/cache/apt/archives/*.deb; do ar p $pkg control.tar.gz | tar zxO ./postinst 2>/dev/null | grep --quiet update-alternatives && echo $pkg; done
<zyga> obviously the path needs to be switched
<zyga> (or you could splice find inside)
<mvo> zyga: dpkg-deb -I $pkg postinst does not work?
<zyga> -l ?
<zyga> no (unless my font is bad and I cannot distinguish -l from -something-vertical)
<cjwatson> capital i
<sebner> bdrung: you happen to be around? sebner@ubuntu:~$ eclipse
<sebner> Trace/breakpoint trap (core dumped)
<sebner> bdrung: hmm, I guess I'll wait until you upload 3.5.2 and see if it fixes it :)
<pitti> smoser: hm, did that actually work for you? %s % max_show looks like a crash
<smoser> really ?
<smoser> i did test it.
<smoser> you think %i there ?
<pitti> yes, it's an int surely?
<smoser> i think because an int can be converted to string
<pitti> oh, indeed
<pitti> Python does that automatically apparently
<pitti> smoser: ok, nevermind
<pitti> >>> print 'hello %s' % 3
<pitti> hello 3
<smoser> $ python -c 'f=1024 * 1024 ; print "%s\n" % f'
<smoser> 1048576
<smoser> right
<smoser> same thin g
<smoser> :)
<zyga> cjwatson: thanks, that was it
<zyga> cjwatson: strange, brute-force method is quite faster!
<zyga> dpkg-deb is slower than ar + tar
<cjwatson> zyga: seems like a bug; OTOH dpkg-deb actually works on all packages ;-)
<cjwatson> (actually that's probably unfair, control.tar.gz is always .gz AFAIK)
<cjwatson> the point is more relevant for dpkg --fsys-tarfile really
<ev> pitti: would you be so kind as to accept ubiquity/apport/source_ubiquity.py into apport upstream?  It would be handy for post-install debugging as ubiquity copies its install logs to the target system.
<pitti> ev: not into apport upstream, but certainly into the ubuntu package
<ev> pitti: ah, indeed
<pitti> ev: although I'd rather see it as an "installer" symptom
<pitti> this could then figure out whether it's d-i, ubiquity, or whatnot
<pitti> "ubuntu-bug installer"
<pitti> ev: but I guess we could have both actually
<ev> cool!
<pitti> ev: just want to commit it yourself, or shall I grab it for you?
<ev> pitti: Sure, I can do it.  Is it lp:~ubuntu-core-dev/ubuntu/lucid/apport/ubuntu ?
<pitti> ev: right; just add it to data/package-hooks/
<pitti> ev: I guess you'll also need to add a Replaces: ubiquity then?
<ev> indeed
<ev> done
<pitti> ev: looks fine, thanks
<ev> cool
<elmo> does anyone know if our cups supports discovery of printers via bonjour/avahi?  docs suggests it's possible but not enabled by default or exposed through the gui as an option, curious as to why
<elmo> tkamppeter/pitti: ^--
<pitti> elmo: it should work, but we do not enable printer discovery by default indeed
<pitti> elmo: because we have a policy that all discovered services must be clearly marked so for the user
<elmo> pitti: sorry, I should have been clear, the 'enable printer discovery' button in the gui only covers CUPS/IPP broadcasts
<pitti> elmo: and our GTK/KDE print dialogs currently don't
<elmo> (at least for me, on Karmic)
<pitti> it's not clear whether a printer is locally configured or just randomly picked up by auto-discovery
<elmo> pitti: right
<pitti> elmo: hmm; it should certainly enable avahi as well
<elmo> BrowseRemoteProtocols CUPS
<elmo> is all I get after clicking the button
<elmo> (and BrowseLocalProtocols which is more relevant is empty)
<pitti> tkamppeter: ^
<nemo> http://packages.ubuntu.com/intrepid/golly - horribly out of date. They are on 2.1 now and many cool demos do not work in it
<ScottK> nemo: Intrepid goes out of support next month, it's really quite old and out of date, as you've discovered.
<nemo> ScottK: also out of date in karmic
<nemo> ScottK: hasn't been updated in ages is what I'm getting at :)
<nemo> http://archive.ubuntu.com/ubuntu/pool/universe/g/golly/  - only 1.4
<jpds> nemo: It's maintained by Debian, and they uploaded a new package on the 1st of this month, by that time; we had frozen.
<nemo> aww
<nemo> oh well.
<nemo> luckily downloading and running 2.1 doesn't require building anything
<ScottK> You can ask for a freeze exception, but it'll take a bit of research.
<nemo> well, if at least 1.4 made it, that allows some stuff to run...
<nemo> it did
<nemo> yay
<nemo> but, for example: http://www.sq3.org.uk/wiki.pl?Von_Neumann%27s_Self-Reproducing_Universal_Constructor
<nemo> doesn't run in 1.4
<superm1> pitti, it was intended to check for bash, or just to generally check for a repo?
<superm1> pitti, particularly in my case the repo doesn't necessarily have bash on it, but it has a bunch of other interesting things
<ev> pitti: if you have a free moment, do you consider this a bug, or expected behavior: http://paste.ubuntu.com/397490/
<xorl> can any of you tell me why apache is so fixated on uid 33?
<cjwatson> that would be www-data
<xorl> I can't seem to FORCE it to use another user/group w/out it starting a process as the www-data (uid)
<xorl> but then magically the rest are my user/group defined
<cjwatson> oh, I thought you meant why that particular uid as opposed to that particular user.  no idea then.
<xorl> cjwatson: yeah, weird bug/glitch on Hardy Server LTS
<xorl> changed the configs to my own custom configs and now it just spawns one process as the magical www-data, and then the rest as what I specified in httpd.conf (User/Group)
<xorl> as soon as I renamed the www-data user, it changed it's identity so it must be fixated on that uid which is weird
#ubuntu-devel 2010-03-19
<bdrung> sebner: i am back. eclipse in lucid probably does not work with xulrunner 1.9.2. take eclipse 3.5.2-1 from sid.
<ccheney> NCommand1r: ping
<NCommand1r> ccheney: pong
<ccheney> NCommand1r: do you know if we need binfilter on arm? i'm trying to reduce our diff with debian and notice they don't enable it on arm
<NCommand1r> ccheney: I'd like to keep OOo on ARM as close as we can to i386/amd64
<ccheney> NCommand1r: aiui it causes the build to take substantially longer
<ccheney> NCommand1r: ok
 * ccheney personally would prefer to drop it on all archs, but that would probably cause some users to be annoyed
<xorl> This has got me brain stumped.
<xorl> Trying to figure out why apache is user bound to the user id 33
<xorl> driving me ape
<micahg> xorl: that's the user id for it?
<xorl> micahg: yeah, I have literally changed the www-data users name
<micahg> xorl: why?
<xorl> restarted apache, it took the name on, so it's some how bound to the straight uid
<xorl> micahg: custom layout
<xorl> I run 2 apache processes as different users (different access rights)
<xorl> problem being, i run it as a different user, somehow www-data is always the first process then the SECOND process is the User I specified
<xorl> was gonna rebuild the package but haven't found where said binding takes place
<micahg> xorl: probably a better question for #ubuntu-server or #httpd
<xorl> micahg: will head over there
<pitti> Good morning
<pitti> superm1: the intention of this thing was: (1) we assume that bash is always installed and from Ubuntu (at least right after installation), (2) if apt says that bash has no valid origin, then we assume that we do not have any package indexes and need to download them
<pitti> superm1: this is for the case right after install when the apt cronjob didn't run yet
<pitti> and thus any package info query fails
<superm1> pitti, hm.  well i've got a situation that's not fitting that too well then.  i've got package indexes that are entirely valid, but are generated from a pool that won't necessarily contain bash at the time that jockey is run (during install)
<superm1> pitti, so with the patch i showed you, it just checks that "something" is available (meaning that there is at least one package index available) - which i think should still work for your case too
<pitti> superm1: yeah, maybe; it looks very expensive, though, since you need to iterate through thousands of package records?
<superm1> pitti, well if you hit the first one and it's valid it's inexpensive...
<pitti> superm1: right, but it won't right after installation
<pitti> superm1: perhaps we should run a similar check again if we detect a handler which has a particular package, which we know nothing about
<pitti> then it could try to fetch the indexes again
<pitti> superm1: what is your use case? add a ppa and call jockey, but not run apt-get update in between or so?
<superm1> pitti, well mv the existing sources.list out of the way, generate a pool from a directory with apt-ftparchive, and put that list in sources.list.d, apt-get update, mv the old sources.list back into place.  the net result is then anything in that pool is apt-get'able, and to disable it, just rm the sources.list.d file
<superm1> so the idea is that it's easy to feed new/updated drivers into jockey by doing it that way
<superm1> i'm starting to think  maybe a switch that blocks jockey-text from trying to fetch index updates would be better for me than trying to fit into the current constraints
<pitti> superm1: hm, jockey already supports adding new repositories in handlers
<superm1> pitti, well this isn't just for jockey, it's actually so that ubiquity can install out of this pool too
<superm1> basically this gets run in an early command: http://linux.dell.com/git/?p=ubuntu-fid.git;a=blob;f=framework/scripts/pool.sh;h=648b81c7f95730bdc76871f9227b84bab1257222;hb=HEAD
<pitti> superm1: so the problem in this case is that jockey fetches indexes again, although you don't want it ti?
<pitti> s/ti/to/
<superm1> pitti, that's what it eventually boils down to, yes
<pitti> superm1: we could perhaps also check glob('/var/lib/apt/lists/*_Packages') != [] ?
<pitti> superm1: since bash is an approximation anyway, this will do as well
<superm1> pitti, that sounds like a saner way to go about it to me
<pitti> I tried to avoid making assumptions about apt's internals, but this is fine for me
<pitti> superm1: hm, I wonder if after an installation you would have a CD-ROM source
<superm1> pitti, in my scenario?  it should be irrelevant i think since any drivers that were available will be installed
<pitti> superm1: no, I mean for the original bug
<superm1> pitti, i dont think i've been seeing a cdrom source after installs in installs i've done lately
<superm1> i thought apt-cdrom used udev now for some of that magic too
<pitti> yes, I think so, too, but I think I'll do another test install to be 100% sure
<tkamppeter> elmo, hi
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> Can you have a look at bug 465916?
<ubottu> Launchpad bug 465916 in cups "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [High,Triaged] https://launchpad.net/bugs/465916
<tkamppeter> It is about the problem of CUPS not broadcasting via DNS-SD/Zeroconf since 1.4.x.
<tkamppeter> James Troup (elmo?) asks for how much work it is to solve this problem.
<tkamppeter> pitti ^^
<pitti> tkamppeter: is that the same problem that we discussed recently, abuot the old bonjour compat API of avahi vs. cups using the native api with that redhat patch?
<pitti> tkamppeter: you mentinoed that you got cups to build with the compat library with very few code changes
<cjwatson> pitti: you may well have a CD-ROM source after installation, yes, so you'll need to filter that out.  whether apt-cdrom uses libudev to get at it is irrelevant
<pitti> cjwatson: ah, thanks
<tkamppeter> pitti, I got it to build but it did not actually work. It needs some functions of the generic libdns which do not exist in the compat library of Avahi.
<tkamppeter> With my changes I got it compiling with the result of a cupsd which did not broadcast.
<pitti> tkamppeter: ok, that's not very useful then
<tkamppeter> pitti, the Red Hat patch only makes CUPS' dnssd backend working with the Avahi compat library, not the CUPS daemon.
<pitti> tkamppeter: hm, I thought it was the backend which would do the detection of bonjour-advertised printers on win/mac boxes?
<pitti> and not the daemon itself
<pitti> tkamppeter: or is it broadcasting cups' printers to mac/win over bonjour, i. e the other direction?
<pitti> ah, apparently it is, silly me
<tkamppeter> pitti, there are two parts: The dnssd backend makes available printers which advertize themselves via DNS-SD, as most modern network printers do, some cheaper ones even dropped the SNMP self-advertizing.
<pitti> right, and this direction works AFAIK?
<tkamppeter> The second (and not working) is as you say that the CUPS daemon should broadcast its locally defined queues via DNS-SD, so that Mac (and perhaps also Windows) clients see the printers.
<tkamppeter> The first works. If you run /usr/lib/cups/backend/dnssd, you see entries from network printers which use DNS-SD.
<tkamppeter> pitti ^^
<pitti> right, got you
<tseliot> pitti: the archive is still frozen (as per topic), right? If so, were the uploads that I see in lucid-changes approved?
<cjwatson> any uploads land in the unapproved queue, so they must have been approved
<seb128> speaking of which any eta for unfreeze?
<cjwatson> universe uploads are still being waved through
<cjwatson> seb128: a few hours, I think
<tseliot> cjwatson: ah, ok, that's what I wanted to know. Thanks
<seb128> I feel uncomfortable having an hundred of uploads landing in lucid after beta just when every runs away for weekend
<seb128> cjwatson, ok thanks
<persia> Could always not run away :)
<seb128> everybody
<seb128> persia, well experience tell me that people will not stay on friday night just to see if nothing breaks
<persia> seb128: Sadly, my experience parallels yours.
<directhex> cjwatson, so an archive admin could do a sync to universe if they felt like it, despite the freeze?
<cjwatson> yes, though I'd expect most archive admins to have other priorities just at the moment
<directhex> yeah, that was my guess
<tkamppeter> pitti, in bug 465916 Mark Shuttleworth suggests to package libdns, but I have told Mark that we are after FF.
<ubottu> Launchpad bug 465916 in cups "CUPS DNS-SD (Bonjour/mDNS/Zeroconf/Avahi) not broadcasting" [High,Triaged] https://launchpad.net/bugs/465916
<pitti> tkamppeter: but I guess that would also need new code in avahi to actually use it, no?
<pitti> tkamppeter: or does cups already have that code, and will use it if it's there?
<tkamppeter> pitti, CUPS will directly use the native libdns. If we package it, we remove Red Hat's patch for dnssd and then let CUPS use the native libdns for both daemon and dnssd, as designed by upstream.
<pitti> ah, this is like a parallel implementation of avahi then?
<tkamppeter> pitti, problem is only that we need to make CUPS use the native libdns and all other libdns-using packages of the distro the Avahi compat libdns to minimize possible regressions after the FF.
<tkamppeter> Yes, avahi did their own implementation of libdns (and our package installs it as /usr/lib/libdns.so.*) but incompletely.
<tkamppeter> pitti ^^
<pitti> tkamppeter: I think libdns.so.* is from bind9
<pitti> avahi is libdns_sd.so
<tkamppeter> pitti, sorry, thanks. I mean indeed libdns_sd.so.
<tkamppeter> pitti, will it be possible to have CUPS using the native libdns and all the rest using avahi compat?
<lucas> Can I assume that the Packages.gz file in dists/$DIST/main/binary-i386/ will NEVER be modified, and that all updates are done through $DIST-updates and $DIST-security?
<cjwatson> lucas: yes
<lucas> even for releases like 10.04.1?
<cjwatson> at least with our current archive model.  It does have the disadvantage that we can't remove a package in case of problems
<cjwatson> yes
<lucas> perfect, thanks
<cjwatson> lucas: what's this for?  if we ever change it, I'll try to remember to let you know ...
<lucas> that's great for legally-binding documents where you must write "MUST work with ubuntu 9.10" and describe what ubuntu 9.10 really is
<cjwatson> right
<pitti> tkamppeter: we'd need to name the libdns one differently
<pitti> tkamppeter: or, as you say, add it to the cups package and link statically or so
<pitti> tkamppeter: but I don't fancy a parallel implementation of avahi a lot, TBH
<cjwatson> Keybuk: console-setup 1.34ubuntu12 should with any luck be a fraction more efficient
<cjwatson> I can't see console-setup-tty on my bootchart any more
<tkamppeter> pitti, what do you mean with "but I don't fancy a parallel implementation of avahi a lot, TBH"? To finally switch to the real libdns_sd?
<pitti> tkamppeter: if libdns is a superset of the avahi API, then we can perhaps discuss that for lucid+1
<pitti> tkamppeter: but for now, so many things build/link against avahi that it's out of the question to switch the implementation for lucid
<pitti> (as a system library, I mean)
<tkamppeter> pitti, so for Lucid the only way is to take the lib into the CUPS package and link it statically.
<pitti> tkamppeter: yes, that or rename the installed library
<pitti> tkamppeter: but I wouldn't like to give a blanket exception for including libdnsf
<pitti> s/f$//
<pitti> it doesn't seem to be a small harmless library after all
<tkamppeter> pitti, how does one make a debian package with an extra upstream tarball, does one drop the extra upstream source into debian/local/?
<pitti> so this should get a proper MIR/FFE
<pitti> tkamppeter: no, please package it separately; it's way too messy otherwise
<pitti> renaming the library sounds better
<pitti> tkamppeter: forward-porting the 1.3 cups code for broadcasting is out of the question?
<pitti> tkamppeter: (the receiving direction alreayd works fine with avahi, so no reason to touch that)
<tkamppeter> pitti, thought also about that and it seems that the dns-sd code is not too much spread over CUPS. And due to the Red Hat patch we only need to forward-port the scheduler part.
<daniel1234> I have a service that I want to write an apparmor-profile for, that service is using slapd. slapd already has a profile, but it doesn't cover the directories I need. Afaik, Apparmor doesn't support having multiple profiles for one binary and it doesn't support "inheritance".. And you shouldn't touch files from other packages. Does anyone have ideas?
<mok0> Hm. Building atlas on the ppa fails for the following reason: Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU
<mok0> Is there any way to request a specific builder?
<persia> Not trivially.  Some of the buildd admins can hint stuff, but I think I remember the trick being something like "wait until everything but the target is busy, and then give the target job a priority of several milloin)
<happyaron> jcastro: ping
<mok0> persia: ... that's not a command mortals can use though?
<persia> mok0: No.  Only buildd-admins
<mok0> persia: ... and you can't upload a binary package to the ppa I guess
<persia> Well, no.  You can upload a source package that contains only a binary blob, but you'll need to make sure the license you have permits that.
<mok0> persia: The purpose would be to get the binary into the PPA
<mok0> persia: now that it won't build
<kitallis> pitti: there?
<pitti> hi kitallis
<kitallis> pitti: so apart from https://wiki.ubuntu.com/Apport/DeveloperHowTo ; any other documentation i can look at?
<pitti> kitallis: what do you want to do?
<kitallis> well, I want a way to access the crash report url it generates
<pitti> kitallis: "access"?
<pitti> kitallis: CrashDB.get_comment_url() generates that
<kitallis> I obtain, grab the randomized key
<pitti> for a particular crash dtabase
<pitti> such as apport/crashdb_impl/launchpad.py
<kitallis> ah
<kitallis> okay.
<kitallis> that should do.
<kitallis> thanks
<tseliot> Riddell, Keybuk: what can I do to trigger the problem with kdm and plymouth using the latest updates?
<tseliot> (of course I have rebuilt kdm with my patch)
<Keybuk> tseliot: which problem?
<tseliot> Keybuk: the one that was blocking the beta
<Keybuk> it's kinda tricky
<Keybuk> we fixed it in a way that ensures you can't trivially get it back ;)
<Keybuk> but you could, for example
<Keybuk> plymouthd
<Keybuk> plymouth --show-splash
<Keybuk> plymouth quit --retain-splash
<Keybuk> kdm
<Keybuk> in a console
<tseliot> ah, let me try
<tseliot> Keybuk: plymouthd seems to be still active but kdm showed up correctly
<Keybuk> err, if plymouth is active, you didn't get it right :p
<Keybuk> you did quit before kdm ?
<tseliot> right, there's something wrong
 * tseliot checks his patch
<tseliot> ah, wait there's the kdm log
<Keybuk> your patch?
<Keybuk> sorry, you've completely confusde me
<Keybuk> what patch?
<tseliot> Keybuk: here's what the log says: http://pastebin.ubuntu.com/397840/
<Keybuk> tseliot: wait, rewind a minute!
<Keybuk> *what* are you trying to test?
 * tseliot should look for another log
<Keybuk> what patch have you written?
<tseliot> Keybuk: it's the plymouth_transition patch for kdm
<Keybuk> yes
<Keybuk> which has nothing to do with any bug we've fixed
<Keybuk> the plymouth transition patch for kdm is about providing a seemless transition into kdm
<tseliot> Keybuk: but that patch would also make plymouth quit
<Keybuk> yes
<Keybuk> that's part of the transition
<Keybuk> to test it
<Keybuk> plymouthd ; plymouth --show-splash
<Keybuk> kdm
<Keybuk> you should see plymouth stop animating, a mouse cursor appear, then KDE
<Keybuk> with no black screen in between
<Keybuk> and plymouthd should exit
<tseliot> ok, I'll have to do something like "sleep 5 && sudo start kdm" as I'm using the same monitor for both my main computer and my testing box
<tseliot> Keybuk: no, I'm seeing this: splash -> black screen + loading cursor -> kdm
<tseliot> so, I did something wrong in my patch
<tseliot> as plymouthd is still on
<tseliot> but I would like to find the actual log to see what's happening
<Keybuk> right
<Keybuk> syslog?
<tseliot> Keybuk: never mind, I forgot to put a "!" in the 2nd condition last night: if (d->plymouth_is_running && d->failsafex_is_running)
<tseliot> no wonder plymouth is not stopped
<radoe> Someone else with connection problems when trying to upload to a launchpad ppa with dput? I keep getting [Errno 111] Connection refused.
<tseliot> Keybuk: ok, plymouth was stopped but I still can't see any kind of transition with nouveau but that's ok since somehow X was launched with -br instead of -nr: /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-gDWp6K
<radoe> Never mind, launchpad FTP seems to be up again...
<xnox> radoe: these type of questions are usually answered more quickly on #launchpad
<radoe> xnox: well thx, just found the channel.
<Keybuk> tseliot: there isn't a transition with nouveau
<Keybuk> well, not as complete a one as -intel anyway
<Keybuk> but yes, you need -nr
<Keybuk> actually, sorry, that was misleading - you still should get a smooth transition into X
<Keybuk> but it's not done using proper kernel buffers
<tseliot> Keybuk:  right, in nouveau you only have a variable which says that it works with -nr
 * tseliot has just found out that another patch sets -br -nolisten tcp in kdm/config.def :-/
<Keybuk> right, I think nouveau supports -nr
<Keybuk> was trying to remember ;)
<tseliot> Keybuk: as you said, things were implemented properly in -intel though
<mvo> bryceh: hey - why did you target bug #540519 ? do you know more aobut it (like e.g. how to reproduce)?
<ubottu> Launchpad bug 540519 in software-center "software-center crashed with SIGSEGV in webkit_web_view_execute_script()" [Undecided,Confirmed] https://launchpad.net/bugs/540519
<seb128> mvo, btw I want to sync new webkit from debian, what do you think about updating?
<seb128> mvo, I think they are working toward a 1.2 stable serie
<mvo> seb128: fine with me
<mvo> seb128: I assume you do basic testing first ;)
<mvo> seb128: but otherwise no objections, there is a patch I did for a a11y crash that we may want to import (or see if its fixed upstream already)
<tseliot> still no transition with -nr. I should try with gdm
<tseliot> Keybuk: I'm getting no smooth transition with gdm either. I'll test with -intel
<seb128> mvo, ok
<tseliot> Keybuk: I haven't ported the save_root_window patch which I guess it's the missing bit now
<Keybuk> tseliot: I was never sure what that did
<Keybuk> I think the purpose of that is to put the root pixmap in a special id
<Keybuk> so when nautilus comes along later, it sees that
<Keybuk> and rather than just painting its desktop image, it does a fadey transition
<Keybuk> (which we have disabled atm anyway0
<tseliot> Keybuk: right, gnome-settings-daemon was supposed to use that to create a cross fade effect
<tseliot> Keybuk: http://blogs.gnome.org/halfline/2009/11/28/plymouth-â¶-x-transition/
<Keybuk> tseliot: yes, I've read it ?
<Keybuk> it's way out of date now
<tseliot> Keybuk: yes, of course but it explains the purpose of the save_root patch, which we don't need
<Keybuk> right
<tseliot> well, that we don't use ;)
<Keybuk> in a matches-what-I-said kind of way ;)
<tseliot> yep
<spersaud> haha #debian-dev is invite only
<spersaud> debian is superior
<spersaud> we are proud of debian, Ubuntu is winky dinky distro
<cjwatson> (now it's invite-only for him - well, until he changes his IP address, but anyway)
<cjwatson> mvo: I punted bug 420307 to beta-2 - are you on the hook to review that?
<ubottu> Launchpad bug 420307 in computer-janitor "computer-janitor-gtk crashed with SIGSEGV in gdk_window_set_geometry_hints()" [Medium,Confirmed] https://launchpad.net/bugs/420307
<mvo> cjwatson: sure
<cjwatson> thanks
<mvo> cjwatson: there is a FFe comming from barry for computer-janitor 2.0
<mvo> with dbus support
<mvo> is this reproducable on your system?
<mvo> I would bet its threading
<mvo> and dbus makes it go away
<cjwatson> no idea, just looking through our stale beta-1 work items ...
<mvo> ok
* slangasek changed the topic of #ubuntu-devel to: Lucid Beta 1 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
<bryceh> mvo, yeah I reproduced it after clicking on a few "More Info" buttons - no info showed up
<mvo> bryceh: is it crashing?
<mvo> bryceh: or "just" not showing anything, if the later its likely just *very* slow
<mvo> bryceh: that is bug #514879
<ubottu> Launchpad bug 514879 in software-center "details update very very slow" [High,Triaged] https://launchpad.net/bugs/514879
<mvo> as in "several minutes"
<bryceh> mvo, don't recall seeing any particular slowness.
<bryceh> anyway, gotta run (pdx downtown meeting today).  hth
<mvo> ok
<mvo> pitti: is the exception in bug #531518 granted? I'm not fully sure by reading the updates or shoould I do another PPA upload that silences the deprecationwarnings first?
<ubottu> Launchpad bug 531518 in python-apt "Feature Freeze exception request" [Undecided,Confirmed] https://launchpad.net/bugs/531518
<pitti> mvo: the verbosity of apt.Cache() is slightly worrying me, since this might break more stuff than just apport (which is fixed in UNAPPROVED)
<pitti> mvo: if we can get this fixed, I'm fine with it
<mvo> I can fix that
<pitti> if it's not intended to be changed, it's also okay, but we need to watch out for regressions then
<mvo> the verbosity
<pitti> we have p-apt being used a lot, perhaps also in eucalyptus scripts and whatnot
<pitti> mvo: thanks
<mvo> well, the goal is to be 100% compatible
<mvo> pitti: I updated the bug that the exception is approved providing those two issues are fixed: a) deprecation warnings silent b) apt.Cache() not verbose
<pitti> mvo: *wipes off a tear* that'd be perfect, thanks!
<mvo> pitti: :) np
<seb128> if beta1 is released is there any reason to not unfreeze?
<Sarvatt> Keybuk, tseliot: all the code to copy the fb contents is already in upstream nouveau so all they need is the canDoBGNoneRoot, thats why the intel patch is alot bigger
<tseliot> Sarvatt: and do we have that code too?
<Sarvatt> yeah
<tseliot> maybe something else is broken here then
<Sarvatt> i see a couple of other situations where you might not see a transition
<Sarvatt> if the fb depth is different it wont copy it
<tseliot> :-/
<Sarvatt> there any warnings in the Xorg.0.log tseliot?
<Sarvatt> looks like most of the failure paths copying it will print something in the log at least if it happens
<tseliot> Sarvatt: I don't think I saw any errors. Let me try again
<slangasek> zul: regarding your samba-common.dhcp change currently in the freeze queue... have you tested this?  I can see no reason that an extra space would change anything
<zul> slangasek: that change is cosmetic i think
<tseliot> Sarvatt: nothing, apart from these lines
<tseliot> (--) Depth 24 pixmap format is 32 bpp
<tseliot> (EE) NOUVEAU(0): Error creating GPU channel: -19
<tseliot> (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
<slangasek> zul: also, the idiomatic way to change the logrotate script would be to run 'reload nmbd' instead of looking at pid files (which might disappear in the future)
<Sarvatt> ah tseliot give me the dmesg please
<zul> slangasek: ok i can change that
<slangasek> zul: oh; it had claimed to fix a bug, and I couldn't see how
<seb128> slangasek, can we unfreeze lucid if beta1 is there?
<slangasek> seb128: the LOSAs can - I've requested this
<seb128> slangasek, thanks
<Sarvatt> noaccel = no smooth transition afaik, should be able to figure out why from your dmesg
<Sarvatt> does anyone know  how to force firmware into the initrd? nouveau has a module option to use the blob firmware which is much less likely to to have accel issues but its not easily testable because it needs to be in there and the module doesn't claim it needs it so initramfs-tools isnt packing it in
<tseliot> Sarvatt: http://pastebin.com/QTP2zURs
<Sarvatt> tseliot: nvidia isn't blacklisted on your system?
<Sarvatt> can you pastebin the actual output from dmesg and not just /var/log/dmesg? the errors would be happening after what you pasted
<tseliot> Sarvatt: that was the output of dmesg > myfile
<Sarvatt> tseliot: try blacklisting nvidia, update-initramfs -u and reboot?
<tseliot> Sarvatt: nvidia is not loaded and in dmesg nvidia complains that it couldn't load nvidia (obviously because of nouveau)
<Sarvatt> tseliot: you're right, nevermind, I see the exact problem in  your log
<Sarvatt> your card isn't supported yet
<Sarvatt> basic 2D but not acceleration
<Sarvatt> [    6.856086] [drm] nouveau 0000:02:00.0: I don't know how to make a ctxprog for your NVa3 card.
<Sarvatt> tseliot: info for that card is desperately needed in #nouveau
<tseliot> Sarvatt: ok, that's definitely a problem
<tseliot> ah
<Sarvatt> they couldn't find anyone with one of those to do a mmiotrace so they can support it
<seb128> directhex, what does bug #536925 break in f-spot exactly?
<ubottu> Launchpad bug 536925 in gnome-keyring-sharp "gnome-keyring-sharp uses deprecated socket interface; apps cannot use keyring" [Critical,Confirmed] https://launchpad.net/bugs/536925
<tseliot> Keybuk: do you happen to have an mmiotrace enabled kernel?
<tseliot> for lucid
<Keybuk> tseliot: not on me
<tseliot> heh
 * ogra pokes mountall
<Keybuk> didn't apw enable it in git now?
<Keybuk> so you should just be able to build from there
<tseliot> Keybuk: yep, Sarvatt has just given me the link
<Sarvatt> he enabled it in the kernels we're testing for intel powersave issues - http://people.canonical.com/~apw/i915-fbc-broken-lucid/
<tkamppeter> Can someone unfreeze the archives? My uploads still say "Waiting for approval".
<ScottK> tkamppeter: It's been requested.  It takes a bit.
<slangasek> The archive is unfrozen.  Packages that are already in the approval queue have to be flushed by hand, which I'm doing now
<tkamppeter> slangasek, thanks, it is foo2zjs.
<cjwatson> tkamppeter: it won't go appreciably faster for any single package :-)
<Pici> hmm. Looks like http://www.ubuntu.com/testing/lucid/beta1 mentions the wrong version for nvidia-current
<lool> Would someone be so kind to NEW the linux-ti-omap kernel?
<tkamppeter> pitti, hi
<Keybuk> [./plugin.c] flush_area:palette has 345 colours
<Keybuk> tseliot: ^ you greedy person, you
<tseliot> Keybuk: lol
 * tseliot wants more colours
<Keybuk> clearly
<tseliot> Keybuk: you should be content with your 16 colours :-P
<Keybuk> yes, but when I wrote a quick "best fit" palette
<Keybuk> I got mostly white
<Keybuk> no aubergine in sight
<Keybuk> and it turns out, that's because you use 345 different shades of white to render the logo ;)
 * tseliot blames it on our artists :-P
<geser> a clear sign that the logo was designed by a woman as only women can distinguish that many colours :)
<ScottK> Sigh.
<ScottK> geser: I recognize the humor in that, but I suspect it's not the sort of thing that makes this feel like a welcoming place for the few women here.
 * geser apologizes to all women
<Keybuk> geser: I'll tell Otto you called him a woman
<doko> pitti: I'm replacing tk8.4-dev with tk8.5-dev in supported-development-desktop
<Pici> tseliot: ping.  I really hate to bug you, but we got a bunch of questions regarding the version of nvidia-graphics-drivers.  I saw on bug 13:56:31 >>>> tavish (~tavish@118.94.24.41) has quit [Ping timeout: 256 seconds]
<ubottu> Launchpad bug 13 in baz "empty signing rules lead to invalid checksums" [Medium,Fix released] https://launchpad.net/bugs/13
<Pici> arg.
<Pici> I saw on bug 533224 that you uploaded/were going to upload a new version, but I don't see that in the upload or build queue.
<ubottu> Launchpad bug 533224 in nvidia-graphics-drivers "fan speed issue in 195.36.08 and 195.36.03 (may potentially destroy the GPU)" [Medium,Fix committed] https://launchpad.net/bugs/533224
<tseliot> Pici: it doesn't depend on me
<Pici> tseliot: oh? Who should I bother?
<tseliot> cjwatson, slangasek: uploads are being processed now, right?
<seb128> tseliot, yes
<seb128> tseliot, see -changes and buildds
<tseliot> seb128: ok, thanks
<tseliot> Pici: you'll have to wait for a while I guess, until my upload is processed
<Pici> tseliot: Okay :)
<Pici> Just wanted to be able to give a status to people who ask.
<jbebel> Does every package that goes into -updates go through -proposed first?
<cjwatson> jbebel: some go through -security instead; all go through one or the other
<cjwatson> -security is automatically bulk-copied to -updates provided that there isn't a conflict
<jbebel> Ok.  I'm less concerned about -security.  If every non-security package goes through -proposed, that's good enough.
<cjwatson> right
<jbebel> Is there any required period of time that a package remains in -proposed, or is it just until someone verifies it, which could be very brief?
<cjwatson> https://wiki.ubuntu.com/ArchiveAdministration#Moving%20Packages%20to%20Updates prescribes 7 days
<cjwatson> occasionally an exception is made to that, but not often
<jbebel> Excellent.  Thanks.
<cjwatson> exceptions tend to be things like tzdata, for which we occasionally get very little notice of political changes
<RoAkSoAx> can anyone from the release team please review bug #407722, since it contains a security fix? Thank you.
<ubottu> Launchpad bug 407722 in lighttpd "[FFe] Please merge lighttpd 1.4.26-1 from Debian testing" [Wishlist,New] https://launchpad.net/bugs/407722
<slangasek> zul: this vsftpd upload seems to not have the debian/vsftpd.apport file
<slangasek> (accepted anyway, but if it doesn't FTBFS, at least the bug is still open...)
<zul> slangasek: k
<ccheney`> anyone happen to know why the new thinkpads no longer have the FHD lcd option?
<xnox> james_w`: Just saw jono blog post =) Didn't I like ask you about it yesterday? =)
<lamont> mdeslaur: wanna go chime in on bug 530107 for me?
<ubottu> Launchpad bug 530107 in bind9 "Please sync bind 9.7.0.dfsg.P1-1 from debian" [High,Confirmed] https://launchpad.net/bugs/530107
<Keybuk> tseliot: so I managed to get a 12-color palette that works
<tseliot> Keybuk: 12? Lazy boy :-P
<Keybuk> http://people.canonical.com/~scott/palette.html
<tseliot> Keybuk: they should be enough for the theme, I guess
<Keybuk> seems to be
<tseliot> apart from the shades of white that you mentioned
<tseliot> screenshots?
<Keybuk> I stripped all but the top two bits of each colour, and that's how many unique 6bpp colours you have in the theme
<Keybuk> so you have sufficient unique 6bpp colours to fit in a 4bpp palette
<Keybuk> hard to take screenshots of VGA output ;-)
<tseliot> you can use a camera
<Keybuk> wouldn't really show the theme
<Keybuk> it looks like the splash
<Keybuk> just with fewer colours
<tseliot> record a videoclip with the iphone perhaps?
 * tseliot doesn't own an iphone and what kind of quality its videoclips can have
 * tseliot uses a nexus :-)
<tseliot> Keybuk: is the logo easier to read, compared to your previous screenshot?
<Keybuk> yeah much
<tseliot> very good :-)
<tseliot> Keybuk: so, what's left now?
<mok0> Whoa RainCT
<Keybuk> http://people.canonical.com/~scott/vga16fb.jpg
<Keybuk> tseliot: ^
<Keybuk> can't really see from that
<tseliot> Keybuk: it looks much much better than before
<tseliot> congrats
<tseliot> Keybuk: so, when are you going to upload it?
<Keybuk> next week
<tseliot> great, excellent work, I can't wait to try it with nvidia
<tseliot> also, one of the nouveau guys has added the support for my nvidia card to the kernel driver (which I'm rebuilding) and I should be able to test the smooth transition with my nvidia card with nouveau soon :-)
<Keybuk> what card is yours?
<tseliot> GeForce GT 240
<tseliot> Keybuk: if you give them an mmio-trace and the output of another program they can add the support for your card in minutes
<tseliot> !
<Keybuk> yeah I did that with my G80-based thing in the D620
<Keybuk> darktama made a patch for me
<tseliot> so the driver works for you too now
<tseliot> :-)
<jrtayloriv> I think it would be a good idea to change the default settings of the Transmission bittorrent client to not have the web client enabled by default.
<jrtayloriv> Should I file a bug report for this? With whom, if so?
<jrtayloriv> Is that something that would be done w/ the Ubuntu package maintainers?
<mdeslaur> lamont: done
<xnox> jrtayloriv: in terminal type $ ubuntu-bug transmission
<xnox> to start bug reporting tool
<jrtayloriv> xnox thank you
<xnox> jrtayloriv: or you can use just launchpad https://edge.launchpad.net/ubuntu/+source/transmission/+filebug
<lamont> ta
<lamont> mdeslaur: ^^
<micahg> xnox: regular users can't file a bug with that link
<xnox> micahg: hmmm the edge bit?
<xnox> micahg: or no having account on lp?
<micahg> xnox: no, the filebug link redirects to the wiki
<micahg> or help.u.c
<xnox> really I didn't know. How come I can then?
<micahg> xnox: maybe because you are a universe contributor?
<xnox> micahg: aha =)
 * xnox feels special
<tseliot> Keybuk, slangasek: stopping plymouth from kdm either after or before calling failsafe X seems to leave the system in KD_GRAPHICS and I can't see the failsafe session but only a fixed image left by the bootsplash on the same vt. Running plymouth again (and killing failsafex) unlocks the system
<slangasek> tseliot: plymouth quit --retain-splash?
<cody-somerville> Whats the lang pack package name for pt_BR?
<tseliot> slangasek: no, according to the log that was just a "plymouth quit"
<Keybuk> plymouth quit won't leave the console in KD_GRAPHICS
<tseliot> slangasek: doing "plymouth quit && start kdm" works well though
<Keybuk> oh, wait
<Keybuk> hang on
<tseliot> ?
<Keybuk> plymouth deactivate , plymouth quit ?
<Keybuk> there may be a bug in -17 with that
<tseliot> oh
<tseliot> no, I think it's my fault
<tseliot> at least in this case
<Keybuk> I think the bug in -17 though is just that it won't dump console messages in that case
<tseliot> I should have added more debug() lines
<tseliot> Keybuk: what do you plan on doing about that? Make it more verbose when it does "deactivate"?
<Keybuk> tseliot: about the bug?
<Keybuk> I already fixed that
<Keybuk> noticed it when I was sending the patches upstream
<tseliot> Keybuk: yes, I was referring to the bug
<Keybuk> tseliot: it's the if statement in on_quit that's the wrong way round
<Keybuk> it needs to check the is_inactive case first
<tseliot> Keybuk: ah, it makes sense
<cody-somerville> Interesting. Even when you're not viewing a package with flash content, npviewer.bin causes tons of CPU wakeups.
<tseliot> Keybuk: I'm already using plymouth 0.8.0~-17 :-/
<Keybuk> yes?
<tseliot> Keybuk: ah, so you haven't uploaded your fix yet
<Keybuk> no, we were in beta freeze
<ninefingers> Hi all, does anyone know if anyone's attempting to package mpir (www.mpir.org) for ubuntu?
<Caesar> Keybuk: hey, you're around. Awesome.
<tseliot> Keybuk: ok, I just wanted to be sure
<Caesar> Keybuk: so from my observations, it seems like the runlevel 2 legacy init scripts can run before Upstart has brought up the network, leading to all sorts of sadness
<Caesar> I've already filed bugs against autofs5 and syslog-ng because they get bitten by this
<Caesar> But it's a fairly systemic problem
<Keybuk> this has always been the way
<Keybuk> it's not even a regression from pre-upstart days
<Caesar> I'm finding that hard to believe?
<Keybuk> *shrug* doesn't matter what you believe
<psusi> by "the network" do you mean lo or eth0?
<psusi> because I'm pretty sure upstart takes care to bring up lo first
<Caesar> psusi: eth0
<Caesar> e.g. syslog-ng's config has a remote loghost, syslog-ng fails to start because it can't resolve it
<psusi> you never could rely on that being up
<Caesar> e.g. autofs-ldap can't load its automount maps from LDAP, because the network isn't up yet
<Caesar> psusi: with legacy init scripts, the network (eth0) came up in rcS
<psusi> only if you configured it to
<Keybuk> Caesar: no it didn't
<Keybuk> not by default
<Caesar> Servers, not using NetworkManager?
<Keybuk> all rcS ever did was start the process of bringing up the network
<Keybuk> it was always brought up in the background while everything else was booting
 * Caesar looks at /etc/rcS.d/S40networking on Hardy
<Caesar> It calls ifup -a
<Caesar> You're telling me that ifup -a returns before the network has come up?
<Keybuk> and ifup is called for network devices from udev
<Keybuk> which means ifup -a ignores them
<Caesar> I have "auto etho" and "iface eth0 inet dhcp" in my /e/n/i
<Caesar> Keybuk: so when is udev also bringing up the network?
<Caesar> /etc/rcS.d/10udev ?
<ion> As soon as the network interfaces appear.
<Caesar> That's what I'm trying to determine when
<Caesar> It looks like /etc/rcS.d/10udev is a reasonable place to assume the network appears
<Caesar> So that's even earlier than /etc/rcS.d/S40networking
<psusi> it appears as soon as udev detects the interface
<Caesar> So I'm not seeing any reason for the network *not* to be up by the end of rcS.d
<psusi> you realize it can take some time for dhcpd to get a lease?
<Caesar> Yes. I guess that's a possibility
<Caesar> If udev isn't blocking on the ifup eth0 before it returns from a udevadm settle
<cjwatson> udevadm settle means "wait for the udev event queue to be empty"; it doesn't mean "wait until all devices have appeared" (which is impossible to determine)
<Caesar> cjwatson: ok, I wasn't sure if udev just spawned the ifup eth0 and waited for it or not
<Caesar> Sounds like does not
<cjwatson> when S10udev returns, the network device might not even have appeared yet
<Caesar> Special
<cjwatson> that's asynchronous device handling for you ...
<cjwatson> (of course there are differing probabilities attached to what happens in practice in any given environment)
<Caesar> I wonder if DHCP is slower on Lucid than Hardy for some reason...
<Caesar> I wouldn't have thought so
<Keybuk> Caesar: udev doesn't block
<Keybuk> you might think we realised this was a problem
<Keybuk> and that we'd need to have something that helped us sychronise things like this
<Keybuk> you might even think we wrote a replacement init daemon to handle it
<Keybuk> etc.
<Caesar> lol
<Caesar> Yes, I realise that the solution is to use an Upstart job
<Caesar> They're currently lacking for the two packages I ran into problems with
<Keybuk> but just pointing out that Upstart was not a solution looking for a problem
<Caesar> I never thought it was
<Caesar> I went to your talk in Barcelona :-)
<Keybuk> <Caesar> I'm finding that hard to believe?
<Caesar> Keybuk: it just took some explaining :-)
<slangasek> Keybuk: "ifup -a ignores them" - I'm not sure that's true, didn't it *attempt* them but with no guarantee that the underlying hardware was available yet?
<cwillu_at_work> Caesar, conveniently, upstart jobs are ridiculously easy to write :p
<Caesar> cwillu_at_work: I know, I've provided ones on the bugs I filed
<Keybuk> slangasek: I wrote the patch to make ifup -a skip the ones udev was already mid-bringing up ;)
<Keybuk> otherwise ifup -a would try and run a second dhclient for an interface already waiting for a dhcp lease
<Keybuk> etc.
<Caesar> That Keybuk, he's got his fingers in everything
<Keybuk> heh
<Keybuk> all bad apparently
 * Keybuk made the mistake of reading the forums again
<Keybuk> "I'm going out for a walk, I may be some time ..."
#ubuntu-devel 2010-03-20
<Keybuk> heh, gotta love the forums
<Keybuk> someone whinging that plymouth isn't working, and it should be removed
<Keybuk> reply asking if they might record a video of what they see
<Keybuk> they reply "I'm so angry! I don't deserve this abuse" type rant
<ion> You visited the forums and survived?
<Caesar> egad
<YokoZar> It looks like Transmission 1.92 fixes a few serious issues with 1.91, including a few security-related things.  1.91 is also apparently banned from a few trackers...
<Caesar> Keybuk: I love how Plymouth no longer looks like utter crap on systems with Nvidia graphics
<Caesar> It's very shiny now
<Keybuk> yeah nouveau ftw
<Caesar> Oh that's nouveau doing that?
<Caesar> Nice
<kklimonda> YokoZar: we know, it's going to be uploaded soon
<kklimonda> well, probably after the weekend as chrisccoulson is probably sound asleep already :)
<chrisccoulson> sleep? me?
<chrisccoulson> lol
<kklimonda> :D
<chrisccoulson> i might look at it before i go to bed ;)
<Keybuk> oh
<Keybuk> wow
<Keybuk> if I span the VGA rows *this way* it goes much faster
<Keybuk> you can almost not see it draw now ;-)
<directhex> nouveau doesn't work for me as far as i can tell. i could re-try i suppose.
<Keybuk> directhex: which card?  what does it do?
<Keybuk> it seems that many problems can be solved by sending upstream an mmiotrace of nvidia-glx starting X on your card
<directhex> gtx260, and x just wouldn't start.
<Keybuk> they send patches back
<directhex> let me try rebooting, and if it's buggered, you can talk me through that
<Keybuk> it involves compiling kernels atm
<directhex> hm, i get x now. but no compiz, sadly
<directhex> and boot time is still pretty slow... probably 15-20 secs between grub and plymouth starting
<Keybuk> oh, you won't have compiz with nouveau
<Keybuk> it's 2D only
<Keybuk> coo
<Keybuk> my mad optimised VGA code is *much* faster
<Keybuk> http://pastebin.ubuntu.com/398090/
<directhex> well, at least it displays something... but i value compiz more than pretty plymouth
<Keybuk> heh
<Keybuk> you value compiz more than you value FREEDOM!
<directhex> yes. correct. free software always has the *potential* to be the best there is. how true that may be in actual terms varies somewhat per project
<directhex> there we go, nvidia-glx is back
<directhex> and now, bedtime
<smoser> Keybuk, are you actually around
<smoser> ?
<Keybuk> smoser: yeah
<smoser> you mentioned getting a /bin/sh shell on console early in boot to help debug.
<smoser> how would i do that ?
<Keybuk> I've no idea
<Keybuk> it's your system
<Keybuk> I know nothing about cloud
<smoser> no. from upstart/boot perspective
<smoser> how would i enable it.
<smoser> i tried:
<smoser> start on starting
<smoser> task
<smoser> console output
<smoser> exec /bin/sh
<Keybuk> init=/bin/bash on the kernel command-line is always favourite
<smoser> (which i realize is busted -- the exec)
<Keybuk> the exec is fine
<Keybuk> nothing wrong with that
<Keybuk> though you mean "start on startup" I think ;-)
<smoser> i figured the fact that it was task would mean it wouldnt come back
<smoser> hmm... whats startup versus staring ?
<smoser> i've used starting before
<Keybuk> task makes no difference
<Keybuk> man 7 starting
<Keybuk> man 7 startup
<Keybuk> starting is to do with jobs
<Keybuk> startup is the first event emitted by upstart
<smoser> ok
<smoser> so, the init=/bin/bash route. i can get there, but then dont know hwere to go from there.
<smoser> exec /sbin/init
<smoser> is hardly going to be helpful :)
<Keybuk> right, set up debugging, then exec init
<Keybuk> oh, wow
<smoser> Keybuk, so with the above script in place, to launch 'sh'
<Keybuk> the "solar" theme on a 16-color framebuffer is simply glorious
<smoser> will it block the rest of boot ?
<Keybuk> no
<smoser> Keybuk, so if i got you a console on such a system with init=/bin/bash, could yo upoke around ?
<Keybuk> yes
<smoser> answering "dude, its friday night" is ok
<smoser> :)
<Keybuk> if you can give me a console on a system that's "hung" is great
<Keybuk> but it won't be right now ;)
<Keybuk> cause I'm literally off to bed in minutes
<smoser> ok. I'll ping you monday.
<genii> dude. It's Friday evening!
<Keybuk> but set one up for me on monday!
<smoser> you're UK now ?
<Keybuk> I'm usually UK
<smoser> yeah. i was just not expecting you here at 1:40 am
<Keybuk> of course, my sleep pattern is according to the timezone of fairy land
<Keybuk> my mother is snoring too loud, can't sleep
<smoser> right. thanks. will bother you monday.
<happyaron> jcastro: ping
<jcastro> happyaron: pong
<Caesar> jcastro: congrats
<jcastro> Caesar: thanks!
<jcastro> robbiew: awake?
<jcastro> anyone awake? nautilus and gnome-panel are broken on login
<jcastro> should probably fire off a warning on the twitter thing
<kklimonda> jcastro: actually a lot of things is broken as all .desktop files which have X-Ubuntu-Gettext-Domain are malformed
<kklimonda> at least those uploaded after beta1 freeze
<jcastro> kklimonda: can you help me find the package that caused this? And if there's a bug?
<LaserJock> is it a problem with gnome-pkg-tools?
<jcastro> I called robbie, so he's aware
<jcastro> so if we can help find out where it is exactly
<LaserJock> somehow when X-Ubuntu-Gettext-Domain is added it's getting added in the wrong place
<LaserJock> the .desktop files in the source packages are fine for the limited cases I checked
<robbiew> jcastro: done
<jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/525240
<ubottu> Ubuntu bug 525240 in gnome-panel "gnome-panel not starting on login" [High,New]
<jcastro> robbiew: this seems to be the bug
<robbiew> ack
<jcastro> hmm, no, that can't be right
<jcastro> mike saw the bug but I wonder if it's the same, he attached his stuff to an older bug
<LaserJock> seems like it
<LaserJock> that is a crash, right?
<kklimonda> jcastro: 525240 is too old for this being the same issue - bug 542343 is more like it but it has no real data
<ubottu> Launchpad bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [Undecided,New] https://launchpad.net/bugs/542343
<jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/542343 too
<ubottu> Ubuntu bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [Undecided,New]
<jcastro> kklimonda: *nod*
<Caesar> cjwatson: you still around?
<LaserJock> jcastro: somebody maybe want to update the topic in ubuntu+1?
<happyaron> well, and a desktop short cut to gnome-terminal, which helped me out temporary
<jcastro> alt-t
<happyaron> oh, I trid alt+f2 and it doesn't work
<jcastro> yeah, alt-f2 is provided by the panel
<kenvandine> yo yo
<jcastro> hi kenvandine
<jcastro> kenvandine: any place I can look to help find the problem?
<kenvandine> gnome-session[1341]: WARNING: Could not parse desktop file /etc/xdg/autostart/indicator-applet.desktop: Key file does not start with a group
<kenvandine> that looks weird
<jcastro> I get that too
<chrisccoulson> jcastro - it's a problem with the new langpack.mk
<kenvandine> hey chrisccoulson
<chrisccoulson> i reassigned bug 542343 accordingly
<ubottu> Launchpad bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [Undecided,New] https://launchpad.net/bugs/542343
 * kenvandine is trying to repro in a VM
<LaserJock> chrisccoulson: when did that get introduced? I couldn't find it
<chrisccoulson> LaserJock, yesterday just before gnome-panel
<kenvandine> i just verified that before updating, i do not have those autostart errors in .xsession-errors
<kenvandine> ok, i am seeing parse errors during the upgrade
<kenvandine> http://pastebin.ubuntu.com/398118/
<kenvandine> chrisccoulson, ^^
<kenvandine> chrisccoulson, they have the entry
<chrisccoulson> right
<chrisccoulson> basically every package built with the new cdbs version
<kenvandine> ugh!
<kenvandine> this is exactly what seb128 was worried about... with the archive opening up on a friday evening :/
<chrisccoulson> yeah, i know :(
<jcastro> that's exactly what he told us
<chrisccoulson> all of these packages will need a rebuild once cdbs is fixed
<kenvandine> seb128 is ALWAYS right
<chrisccoulson> plus any other package which is uploaded
<kenvandine> chrisccoulson, ok... is someone working on that?
<chrisccoulson> kenvandine, everyone is asleep now i think
<jcastro> kenvandine: don't think so, you two are the only ones here
<kenvandine> the baby just got sick again... i need to go :(
<chrisccoulson> pitti did the initial change, so i subscribed him to the bug
<jcastro> go take care of your kid
<wgrant> Is it worth flipping the buildds onto manual to stop any more damage?
<kenvandine> i couldn't fix cdbs anyway... i don't think
<kenvandine> wgrant, yes
<jcastro> robbiew_: what should we be doing?
<kenvandine> sigh... well i'll try to check back in later
<ScottK> wgrant: It doesn't affect everything.
<chrisccoulson> only things that ship a desktop file in main
<wgrant> ScottK: No, but it can be fixed within a publisher cycle if people are quick.
<ScottK> chrisccoulson: Not all packages use CDBS.
<chrisccoulson> yeah, that's true
<ScottK> The gettext stuff is, IIRC done differentl for KDE pacakges that still use CBDS, so that narrows the field further I think.
<ScottK> Toss a "y" in there somewhere for better spelling.
<emet> does the software store have an API/commandline args
<emet> I notice apt-url uses synaptic command line to issue package installation
<LaserJock> good luck guys, I'm off to bed
<psusi> hrm... seems plymouth still doesn't say press enter to reboot once the cd is ejected on beta 1 cd... also the dmraid bug still really needs fixed before release
<crypt-0> the latest kernel update broke grub it sets "	set root=(hd3,1)" instead of "	"set root=(hd2,1)" manual change no luck...
<crypt-0> error message cant find /dev/mapper/cryptroot
<crypt-0> anyone alive?
<persia> Most folk.
<persia> Some aren't, but that's just a matter of semantics regarding electronic entities.
<crypt-0> persia, any idea to the above problem?
<persia> None, but I'd suggest that #ubuntu+1 was a more appropriate forum to ask about issues with updates.
<persia> (or #ubuntu if you're running supported releases)
<crypt-0> yeah, no one has  a clue there...
<persia> Doesn't make this a support channel though.  Not sure where to direct you.
<crypt-0> i know
<crypt-0> sometimes people answer me though
<crypt-0> ...ive never haday help from #ubuntu
<crypt-0> just blank stares
<mneptok> well, to be fair, you haven't asked a question.
<crypt-0> the latest kernel update broke grub it sets "	set root=(hd3,1)" instead of "	"set root=(hd2,1)"
<crypt-0> error message cant find /dev/mapper/cryptroot
<crypt-0> any idea to the above problem?
<mneptok> that's a statement. not a question. and you should ask questions in #ubuntu or #ubuntu+1, as persia said
<persia> No, it's a question.
<persia> it's just an off-topic question, so there's a good chance nobody will answer.
<crypt-0> manual change of grub.cfg didn't work
<mneptok> crypt-0: please take the issue to one of the official support channels. this is the wrong channel to discuss this.
<crypt-0> there is a god chance no one will  answer in #ubuntu been over  an hour
<mneptok> that does not make this a support channel.
<persia> So, the GNOME desktop is broken.  I've seen discussion in backscroll, and in other channels.  #ubuntu-desktop logs show silence on the issue.  Am I correct that the fix is to revert the changes to address bug #535650, and reupload some stuff?  Has anyone already written a script to determine affected packages in launchpad?
<ubottu> Launchpad bug 535650 in cdbs "Evolution desktop entry does not load translations" [High,Fix released] https://launchpad.net/bugs/535650
<wgrant> It seems odd that everybody seems to have gone to sleep with the world broken and lots of users affected.
<persia> Indeed.  At this point, I'm willing to just fix it, but I want to make sure I'm actually fixing it.
<wgrant> Anything built in main in the last 8 hours depending on CDBS needs to be considered.
 * wgrant has a look.
 * happyaron perhaps we can send a mail to mailing lit
<happyaron> list
<persia> ajmitch, TheMuso, Hobbsee, StevenK: any of you currently about?
<wgrant> The Europe and the US are asleep. That's unlikely to help.
<happyaron> wgrant: we they are awake they may see the alert
<wgrant> That's a long time away yet.
<persia> happyaron: It will be fixed by then,.
<wgrant> Particularly as we are entering a weekend.
<happyaron> oh
<persia> In the worst case, I'll temporarily make myself core-dev (although I'd much rather some actual core-dev was around)
<happyaron> :)
<happyaron> people in Asia have been awake, and reports are rushing into our LoCo forum...
<persia> Indeed.  And lots of people in the Americas have gone to bed frustrated with broken envionments.
<persia> It mostly affects GNOME (login fails), but it also affects all the CDBS hacked .desktop files in the archives, so lots of applications are disappearing from menus.
<lifeless> persia: you're not core-dev?
<persia> lifeless: I'm not.
<lifeless> persia: but you can make yourself core-dev ?
<persia> Yes.
<lifeless> *blink*
<wgrant> DMB?
<persia> I'm not supposed to do that, but I'm willing to take the risk of losing my DMB appointment for this.
<persia> wgrant: Yes.
<lifeless> well, I'm in the US right now
<wgrant> We may have a core-dev or two incoming.
<persia> That would be good.
<lifeless> but if this is urgent, I'd escalate
<lifeless> e.g. by ringing stevenk's mobile ;)
<lifeless> speaking of which, gnight.
<persia> gnight.
<mneptok> it's not *that* late in parts of the US (2249 here in MDT)
<lifeless> mneptok: I'm in boston
<lifeless> nearly 1am
<persia> mneptok: Do you know some core-devs in that timezone?
<mneptok> lifeless: sorry to hear it. :P
 * happyaron sorry, what's DMB?
 * StevenK_ looks in
<persia> mneptok: Can you make them show up?
<dmb> who me?
<persia> StevenK: \o/
<persia> dmb: No.  Developer Membership Board.
<mneptok> persia: not sure if there are core devs in MDT, but there sure are in PDT
<wgrant> Ah good, my poking worked.
<persia> StevenK: GNOME is broken.  Please fix :)
<wgrant> StevenK: Bug #542343
<ubottu> Launchpad bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [Undecided,New] https://launchpad.net/bugs/542343
<dmb> :)
<persia> wgrant: Did you get the list?
<wgrant> CDBS needs reverting, and I'm working on a list of stuff that needs rebuilding.
<StevenK> So pitti's fix that was uploaded 8 hours ago is wrong?
<persia> At best, incomplete.
<wgrant> It's the one that broke it, it seems.
<persia> It fixes that one case, but breaks GNOME login.
 * StevenK looks at 1/rules/langpack.mk.in and then wishes he hadn't
<wgrant> +1
<StevenK> So I should just revert the ubuntu6 changes or do I need to do more?
<persia> Reversion is the easiest way out.
<persia> Causes a regression for bug #535650, but in this case the cure is worse than the disease.
<ubottu> Launchpad bug 535650 in cdbs "Evolution desktop entry does not load translations" [High,Fix released] https://launchpad.net/bugs/535650
<StevenK> persia, wgrant: cdbs uploaded
<wgrant> StevenK: Thanks.
<wgrant> LP is being stupid.
<persia> StevenK: Thank you.
<StevenK> Do I need to re-upload evolution in a while?
<wgrant> And lots of other stuff...
<StevenK> Give me a list of stuff in main and I'll sort it out
<persia> But we have to wait for the new CDBS to be on ftp.internal (or whatever it's called) first.
<StevenK> Absolutely, I know
<wgrant> Which will be around 80 minutes.
<wgrant> Oh, there's no actually that much broken.
<wgrant> I just grepped every binary built in the last 9 hours.
<persia> From my quick review of -changes, it looked like 6-7 packages.
<StevenK> How many are in main?
<wgrant> All the affected binaries are in main.
<wgrant> Since langpack.mk should only affect main.
<StevenK> Ah. What's the list?
<wgrant> Just rechecking.
<wgrant> http://paste.ubuntu.com/398158/ is the list of binaries that could be affected (they have the X-Ubuntu-Gettext-Domain mangling)
<wgrant> Some of them aren't actually broken, at least on i386, which is odd. Maybe they were built early enough.
<StevenK> Ooh, and ubiquity. Nice.
<wgrant> Arch skew is going to be annoying, since cdbs is arch-indep.
<wgrant> ubiquity is OK, at least on i386.
<wgrant> Oh, and it's arch-all, so it's fine.
<wgrant> http://paste.ubuntu.com/398160/ appears to be the full broken list for i386. My grep on other archs was flawed (they were rather behind, so more may be affected).
<StevenK> That's source or binary?
<wgrant> And the LP API sucks, so I can't filter on builds completed since X, nor can I get files for binaries published since X.
<persia> wgrant: Is that grep against built-binaries, or against the build logs?
<wgrant> That's against built binaries.
<wgrant> But those are source names.
<persia> Even if that isn't a complete list, it's likely enough to stop the noise.
<wgrant> Right.
<persia> And the rest can be hunted later.
<wgrant> gnome-panel and nautilus are the really important ones.
<persia> I've heard a bunch of complaints about rythmbox and totem because they disappear from the menus.
<wgrant> Right.
<wgrant> evolution too, but since everyone except me seems to use Gmail that shouldn't be less of a problem.
<wgrant> Er, should be less of a problem.
<persia> Rather, I think the noisest complainers are those who want their movies and music now.
<persia> I probably use gedit more than anything else on that list, personally.
<wgrant> Ah, activity on the bug.
<wgrant> Rick has assigned it.
<wgrant> But I suspect that won't be acted upon for quite a few hours yet.
<StevenK> I suspect I should update it
<wgrant> I've just commented.
<persia> That might be good.
<wgrant> If only the publisher was not so slow.
<persia> Isn't there some manual mode that lets it be triggered on-demand?
<persia> Or wouldn't that help in this case.
<wgrant> It would have only helped if we had disabled it just before cdbs was uploaded (thus avoiding a publisher run), and run it manually once cdbs had built.
<wgrant> It would have saved around half an hour.
<wgrant> StevenK: ftpmaster.internal is cocoplum itself, isn't it?
<ajmitch> persia: did I miss something?
<joe_> After upgrading to Lucid, I was unable to access my network drives with a message that some obsolete pkg version were installed. I then used the update manager to see if any updates were available and found the ones previously mentioned were among those recommended. I then found I could only do a Partial update and after doing so I could open my Home Folder icon, so I rebooted and now only...
<joe_> ...have an empty Desktop. Any help available to resolve this?
<wgrant> joe_: #ubuntu+1 for support please.
<wgrant> But this bug is known, and should be mostly fixed in about two hours.
<wgrant> joe_: For now, press Alt+T, and run gnome-panel.
<wgrant> That should get things mostly working.
<persia> ajmitch: bug #542343 : I was calling core-devs to find a volunteer to fix.  StevenK was faster than you.
<ubottu> Launchpad bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [High,Confirmed] https://launchpad.net/bugs/542343
<ajmitch> persia: ah good, I'm glad he got to it :)
<joe_> wgrant; Thanks
<joe_> After upgrading to Lucid, I was unable to access my network drives with a message that some obsolete pkg version were installed. I then used the update manager to see if any updates were available and found the ones previously mentioned were among those recommended. I then found I could only do a Partial update and after doing so I could open my Home Folder icon, so I rebooted and now only...
<joe_> ...have an empty Desktop. Any help available to resolve this?
<persia> joe_: ?  misplaced paste?
<joe_> persia: Yes, sorry.
<wgrant> persia, StevenK: Mirrors should be syncing in a minute or two, and except for possibly builds completing in the last hour, the source package list I gave is complete across all architectures.
 * persia looks at recent builds
<persia> I thik update-notifier on sparc is likely also munged, but since last I heard no lucid kernel booted on any sparc anyone had, I don't think it matters by comparison.
<wgrant> I'll recalculate the list later, including everything that finished between two hours ago and whenever the buildds catch up after now.
<wgrant> Odd -- a.u.c hasn't been updated.
<wgrant> It should have been around five minutes ago.
<wgrant> Ah, there we og.
<wgrant> Syncing now.
<wgrant> And cdbs is there.
<wgrant> Does somebody want to rebuild gnome-panel and nautilus noW?
<wgrant> StevenK: ^^
<persia> ajmitch: Now's your chance to be faster, if you like.
 * persia reopens bug #535650
<ubottu> Launchpad bug 535650 in cdbs "Evolution desktop entry does not load translations" [High,Fix released] https://launchpad.net/bugs/535650
<wgrant> They both take less than 10 minutes to build, so we shouldn't lose anything on i386 unless they're not uploaded in the next half hour.
<wgrant> amd64 is less lucky, though :/
<persia> Why so?
<wgrant> It has one buildd stuck on linux, and 3 packages in the queue.
<persia> That just needs a buildd admin.
<wgrant> Still, we have a conveniently placed buildd admin who can twiddle scores for us.
<wgrant> Hm, this is suboptimal.
<persia> Which?
<wgrant> Everyone seems to have run away.
<persia> Hobbsee TheMuso StevenK ajmitch : Would someone please rebuild the packages listed at http://paste.ubuntu.com/398160/ to address bug #542343?
<ubottu> Launchpad bug 542343 in gnome-panel "gnome-panel will not autostart on lucid" [High,Confirmed] https://launchpad.net/bugs/542343
<wgrant> Only gnome-panel and nautilus for now.
<wgrant> They are critical, and the others will compete for buildd time.
<persia> Why?
<persia> Ah.
<wgrant> And without Hobbsee, we cannot guarantee build order.
<persia> So we essentially need Hobbsee, really.
<wgrant> Attempting to contact by several means...
<wgrant> amd64 is probably a lost cause.
<wgrant> It's tied up for another 20 minutes. Unless we're very lucky.
<persia> Indeed.  amd64 will be very difficult to fix this publisher run.
<persia> Lesson for next time: when you corner a core-dev for timing sensitive stuff, get signed source packages available somewhere for independent upload later.
<wgrant> Indeed.
<StevenK> Sorry, I was adk
<StevenK> *afk
 * Hobbsee comes back too
<wgrant> Yay.
<StevenK> How about I just put a copy of my private key up on people.ubuntu.com? :-P
<wgrant> You now have around 20 minutes to rebuild gnome-panel and nautilus.
<wgrant> Or we miss another publisher run :/
 * StevenK works on rebuilds
 * Hobbsee fishes out buildd.py
<wgrant> Thanks.
<wgrant> We probably won't need rescoring.
<wgrant> But it would be a handy facility to have just in case.
<persia> No.  i386 has an empty queue, and we missed the window for amd64
<wgrant> amd64 still might just happen.
<persia> But not because of rescoring.
<wgrant> Right.
<wgrant> mysql-cluster should finish in a few minutes.
<persia> Oh, excellent.
<wgrant> Then we need about 20 minutes of buildd time from it.
<wgrant> In the next 37 minutes.
 * StevenK uploads gcc
 * wgrant stabs.
 * Hobbsee deflects wgrant's stabbing
 * wgrant hastily patches OOo.
<persia> actually, we could use a rescore on armel : we really don't want to have to build chromium-browser twice.
<StevenK> I have to upload chromium?
<Hobbsee> ok, let me know what you want rescored, and when
<wgrant> StevenK: No.
<persia> StevenK: We have a Hobbsee that can defend you from uploading chromium-browser
<persia> Yeah, sparc and armel both need rescoring support for the rebuilds.
<wgrant> They're less critical.
<persia> If I could boot a lucid kernel on any of my armel devices, I'd disagree with you :)
<wgrant> So, remaining steps in the world domination plan:
<wgrant>  1) Get those two rebuilt.
<wgrant>  2) Rebuild the rest of my list.
<wgrant>  3) Once the queues clear, I'll rerun the check and we rebuild the stuff that is newly broken.
<wgrant> Then all is fixed, except the original bug the fix for which broke everything.
<persia> Which was a workaround patch for a different bugfix that broke everything.
<StevenK> Right, uploading everything.
<wgrant> StevenK: Just those two, I hope?
<StevenK> No, we can rescore
<wgrant> No.
<StevenK> We can't?
<wgrant> We can't terminate a build once it's building.
<StevenK> Bleh
<wgrant> So we need to get those two accepted first.
 * StevenK sighs at * for not expanding in the order wgrant wanted
<persia> and then those two get rescored on amd64 / armel / sparc, and then everything else gets uploaded.
<wgrant> Right.
<StevenK> Pity I've already destroyed that plan
<wgrant> How much made it in?
<wgrant> All of them?
<StevenK> Yeah
 * persia checks
<wgrant> Hobbsee: Can you rescore the two critical ones on all archs, please?
<wgrant> We still may have time, if the first dispatched builds are short.
<persia> Hobbsee: Can you rescore nautilus and gnome-panel on amd64/armel/i386/sparc please?
<persia> Oh, right.  All architectures :(
<wgrant> Crap.
<Hobbsee> rightio
<wgrant> gedit/empathy/evolution
<wgrant> At least one of those doesn't sound too long.
<persia> empathy isn't so bad.
 * wgrant checks.
<wgrant> 5 jobs (16 minutes)
<wgrant> That looks OK.
 * persia has "3 jobs (eight minutes)
<StevenK> Remember that i386 is blazingly quick, when it wants to be
<StevenK> The amd64 builders, less so
<Hobbsee> The source version for 'nautilus' in Lucid (main) is at 1:2.29.92.1-0ubuntu2. <-- old, i'm guessing?
<wgrant> gedit takes 6 minutes.
<wgrant> empathy 12
<StevenK> I uploaded -0ubuntu3
<wgrant> evolution half an hour.
<Hobbsee> bah
<Hobbsee> how long does it take for launchpad to update so buildd picks it up?
<persia> That still gives us a chance at two buildes.
<wgrant> So we should be able to make it on i386 with about 10 minutes to spare.
<persia> powerpc will miss.
<persia> StevenK: Can we pause the publisher to get a few extra minutes?
<wgrant> Hobbsee: You might have to do it manually. If it's not working now, it probably won't work for half an hour.
<Hobbsee> well, so launchpad lib picks it up
<persia> (just in case)
<wgrant> We probably won't need it, but would be nice to know if it's an option.
<StevenK> I can, but I'd rather not hand-hold the publisher if I don't have to.
<persia> OK.  Let's hope it doesn't come to that.
<Hobbsee> nautilus prodded
<wgrant> OK, gedit finally finished installing build-deps, so we could have an i386 builder in a couple of minutes.
<Hobbsee> wonder why i can't modify the build scores inline anymore
<StevenK> wgrant: palmer is the quick one, too, remember
<wgrant> StevenK: It's not acting like it :/
<wgrant> Ah, finishing now.
<Hobbsee> all prodded
<persia> Hobbsee: Thank you.
<wgrant> Hobbsee: Thanks!
<Hobbsee> np
<wgrant> Oh I really with buildd-manager sucked less.
<StevenK> s/t/s/
<wgrant> That.
 * persia grumbles about debug symbols being nifty and all, but...
<wgrant> Oh.
<wgrant> empathy's done.
<wgrant> And gedit will be in a few seconds.
<persia> Is.
<persia> We're building the target packages
<wgrant> Ah, yes, DB replication lag.
<wgrant> Excellent.
<wgrant> amd64 has grabbed nautilus, too.
<wgrant> i386 should make it by 10 minutes, and amd64 might by a couple.
<persia> and amel
<persia> (but it won't make it : those are *slow*)
<wgrant> Heh.
<StevenK> gnome-panel is very nearly done
<wgrant> It's done.
<wgrant> And taken by a damn private build.
<wgrant> Fortunately we got what we wanted.
<StevenK> Will you two stop stressing now? :-P
<persia> Almost.
<persia> waiting on nautilus and publisher.
<StevenK> nautilus is just cleaning up
<persia> So should be fine.
<wgrant> nautilus is about to finish on amd64 too.
<wgrant> So gnome-panel might juuuuust make it.
<wgrant> i386 is safe.
<wgrant> All built.
<wgrant> yellow has gnome-panel... the race is on...
<persia> huito has gnome-panel too, not that it really matters, again.
 * wgrant sends more hamsters into yellow.
<persia> crested has reached pkgmaintainermangler, so we might get another buildd there, for the less critical stuff.
<wgrant> Looks like most of i386 will be done.
<persia> not that it matters in the next 5 minutes
<wgrant> gnome-panel on amd64 is finishing up.
<wgrant> It might just make it.
<wgrant> Now we can blame buildd-manager if gnome-panel misses it.
<persia> The extra nice thing about schroot is that it throws away the changes when used with sbuild, which is faster.
<wgrant> persia: Well, it extracts a fresh tarball anyway.
<wgrant> So removing everything is pointless.
<wgrant> Unless it makes use of it to stop services cleanly.
<wgrant> OK.
<wgrant> Finished and uploaded.
<StevenK> With 3 minutes to spare
<persia> StevenK: Thanks a lot for pushing those.
<wgrant> StevenK: It's :03, or :04?
<wgrant> So everything is good now.
 * StevenK checks
<wgrant> Thanks.
<StevenK> wgrant: The former.
<StevenK> So you two can buy me beer, even though wgrant is too young to buy it :-P
<wgrant> StevenK: Oy, I'm 18 now.
<wgrant> So unless we go to the US...
<StevenK> Pity you look 12 :-P
<persia> heh
<persia> 535650 all reopened.  Is someone else closing 542343?
<persia> Or do we wait for publisher to complete for this?
<wgrant> We'd best wait, I think.
<wgrant> Given that closing it is going to make everyone upgrade, inevitably :/
<persia> Good point.
<ajmitch> looks like I missed all the fun again
<wgrant> Looks like everything's done.
<persia> Excellent.
<lifeless> wgrant: persia: is it good now?
<wgrant> lifeless: Yes.
<wgrant> Somebody should probably tell ubuntustatus.
<wgrant> And force a mirror push.
<persia> mirror push happened post-publisher.
<wgrant> I believe a full external push only happens once every six hours.
<persia> But lots of mirrors are pull-only, which can be as rare as once each 8 hours.
<lifeless> wgrant: hourly for push mirrors
<wgrant> lifeless: I see some push mirrors out of date, though.
<persia> Or even once a day for a couple particularly special cases.
<wgrant> At least I thought they were push mirorrs.
<lifeless> pull mirrors can be arbitrarily far apart
 * wgrant checks the graphs.
<lifeless> wgrant: check their trace file
<wgrant> lifeless: That's what I'm looking at.
<persia> wgrant: I've been going by http://people.canonical.com/~jpds/mirrors/push-archive-mirrors-dot.png
<wgrant> persia: So have I.
<wgrant> ftp.acc.umu.se just updated a few minutes ago.
<wgrant> It had been unupdated for 5 hours.
<lifeless> ubuntustatus is a twitter/identica thing?
<wgrant> lifeless: Yeah.
<wgrant> It was updated last night by $UNKNOWN with a bad bug number for this issue.
<persia> Isn't that mostly a robbiew thing?
<wgrant> Probably.
<wgrant> It's sort of like launchpadstatus.
<wgrant> It's only updated when people are around to fix the issue quickly.
<wgrant> So it's not actually all that useful.
 * persia idly wonders why us.archive.ubuntu.com is none of the US Push Mirrors
<wgrant> persia: I believe discussions are ongoing.
<wgrant> But IIRC nobody wanted to take the load.
<persia> Ah.
<lifeless> because rsync is not a good fit for mirroring 400K files
<persia> Works for me.
<wgrant> lifeless: Yes. lmirror looks good.
<lifeless> and no one US mirror can handle us.archive.ubuntu.come load
<lifeless> wgrant: thanks
<lifeless> wgrant: did I mention it to you?
<persia> And they can't be round-robined?  There are current 4 servers claiming to be us.a.u.c
<wgrant> lifeless: No.
<wgrant> persia: round-robin with apt is unsafe unless they're in perfect sync.
<lifeless> wgrant: I'm curious (I haven't been hiding it, just not had it at the point to make noise till like, last night), how you ran across it
<wgrant> (like, say, prat, lithium, drescher, and jackass)
<persia> Isn't that mostly safe for push mirrors though?  I thought that the only guarantee of that was standard push-mirroring for drescher/lithium/prat/jackass
<wgrant> persia: Push mirrors are tiered, and each tier takes a few minutes.
<wgrant> (Until everybody moves to lmirror)
<lifeless> persia: its not safe unless the mirror update script pauses and sync, or they have exactl ythe same bw
<persia> lifeless: How do you mean pause and sync?  You mean something like the algorithm used in ubumirror?
<lifeless> wgrant: we did a scaling test last night; or rather jpds did and I wafted encouragement and bug fixes
<wgrant> Yeah, I heard it was pretty nice and quick.
<lifeless> wgrant: 0.24 seconds to mirror a change, 24K file repository
<wgrant> Awesome.
<lifeless> yeah
<wgrant> How long does journaling take?
<lifeless> ~ the same as an rsync run today.
<lifeless> but you should be able to write journals directly from LP, with appropriate thought.
<wgrant> Excellent.
<wgrant> Right.
<lifeless> persia: So, apt archives are tolerant of some forms of 'not-perfect':
<lifeless> you can have extra files
<wgrant> Although that's harder with apt-ftparchive, I guess we could easily generate it internally for the pool and then diff dists/.
<persia> lifeless: which I why I thought the sync pool/ sync dists/ clean pool/ model ought just work.
<wgrant> So you sync pool first, then wait until everybody is in sync, then quickly sync dists across all of them.
<lifeless> as jpds said to me when I apologised for only have a prototype - its a personal time thing - rome wasn't built in a day
<wgrant> But you'd need to two it in two phases.
<lifeless> persia: its not tolerant of missing files.
<wgrant> rsync pool without deleting, rsync dists, rsync pool with deleting?
<persia> also, when my mirror is out of sync, I just get a download failure, and bump to the next least distant mirror.
<lifeless> persia: and apt doesn't pin to a single mirror server in a rotation alias.
<persia> It's perfectly tolerant as long as there are backup servers in sources.list.
<persia> It just stops trusting that source for that file during that run.
<wgrant> persia: No, you get sig failures and alarms everywhere if dists is slightly out of sync.
<lifeless> persia: so, folk configured to point as us.archive.ubuntu.com generally don't have a backup 'server'
<persia> Ah, I'm thinking about pool/ out of sync.  dists/ sync is quick-like.
<persia> lifeless: Anyway, how does this lmirror thing work?  Should I try using it already, or isn't it ready yet?
<lifeless> persia: so the point is to never have a situation that lasts more than a few seconds where any of the servers in a rotation alias have missing files relative to a different servers Packages
<persia> Yeah, I can see that.
<lifeless> persia: early alpha; if you're interested checkout lp:lmirror and have a read
<hyperair> i generally sync the dists/ first to a separate temporary location, sync pool, and then sync dists with the aforementioned temporary location
<persia> I've been reading the source.  Just curious if you wanted users.
<lifeless> hyperair: thats only enough to be internally consistent, not consistent with other mirrors, which is the issue
<hyperair> lifeless: what do you mean consistent with other mirrors?
<lifeless> so you need to do the pool non-delete mirroring to all the other mirrors aliased to whatever rotation you're in.
<persia> hyperair: So if you have, say, 12 machines at sg.archive.ubuntu.com, they all need to be in sync.
<hyperair> persia: ah i see what you mean
<lifeless> and then do the dists + pool delete-mirroring to all the other mirros at the same time
<lifeless> persia: I'd be delighted if you wanted to play with it, file bugs, write docs, whatever.
<persia> lifeless: I'll need guidance for setup, etc.  I'm happy to run stuff, and try to script it to require less thought.
<lifeless> persia: it is not feature complete; specifically it doesn't have sanitised journals, signed journals, enough diagnostics nor signalling points to do cross-machine-update synchronisation yet.
<lifeless> persia: read the MANUAL.txt
<lifeless> persia: if its not guidance enough, file a bug ;)
<lifeless> (I'm serious)
<persia> lifeless: What target servers have lmirror enabled so far?
<persia> (even as dumb senders)
<lifeless> none
<lifeless> we only found out last night UK/east-coast US time zone that it could successfully mirror on the right scale.
<persia> lifeless: heh.  I'll need to get another server up first then.  If you enable it somewhere, and want to play with a peer, let me know.
<lifeless> persia: persure
<lifeless> what will probably happen is that jpds, elmo and I will become confident enough in it that we'll add it to the main mirror set at some point
<lifeless> at which point it can be used :)
 * wgrant slurps down the final chunk of binaries to check for more brokenness.
<persia> Makes sense.  I just have a feeling that timezone skew being what it is (why are you awake again), there's a chance I might be able to play peer before that happens.
<lifeless> persia: EJETLAG
<persia> heh
<persia> well it's evening now, so you should be all set to go to sleep for breakfast.
<lifeless> persia: :P
<lifeless> 6am is my normal rising time, so I was only ouy by 30 minutes or so anyway
<wgrant> Unless there's a build in the wild that I've missed, the archive is clean.
<wgrant> All finished broken builds have been superseded.
<persia> wgrant: sparc and armel aren't done yet.
<wgrant> persia: Right.
<wgrant> But those builds are good.
<persia> Oh, you mean that we no longer have any sources that need rebuilding?
<wgrant> Right. By 'the archive is clean' I meant 'it will clean itself up without intervention once the obscure slow archs finish'
<persia> sparc doesn't have to be slow, but hardware is annoyingly expensive.
<wgrant> Right.
<persia> armel isn't obscure, but there's *three* devices available in retail that can run lucid, and we don't have kernels for any of them.
<wgrant> Ow.
<persia> (and it is slow)
<lifeless>  isn't android armel?
<persia> lifeless: I thought it was available for both armel and i386.  I may be mistaken.
 * persia jumps on the "We have more platforms than you" trampoline some more, and then gets off ashamed, noticing Debian
<wgrant> We were close for a while.
<persia> Well, yeah, but we didn't have enough hppa users to sustain it (6 people does not a userbase make).
<persia> And lpia should never have existed in the first place.
<wgrant> Right.
<persia> MIPS would be nice, but runs into the "buildds are hard to get" issue.
<wgrant> Yeah...
<persia> I'm unsure how much longer we'll have ia64, because there aren't that many users.
<persia> (and only 3 developers I know about)
<lifeless> persia: I mean the android hardware platform that people buy, e.g. nexus one
<wgrant> That's ARM of some variety.
<wgrant> Probably armel.
<qense> Sometimes -- when Plymouth doesn't display the error message "init: ureadahead main process terminated with status 4 -- Plymouth seems having so much fun at changing the colours of the four dots under the text "Ubuntu 10.04" that it seems to forget that it needs to boot, it goes on forever. Is there already a bug report for this issue, if not, against what package should I report it? ureadahead, or plymouth?
<persia> lifeless: That's indeed armel.  That can't run lucid because 1) we don't have that kind of kenel, and 2) there's some silliness in the way the kernel loads taht means we can't easily replace it with a custom kernel if we wanted.
<lifeless> wgrant: as I thought :P
<wgrant> persia: Are they really ARMv7+thumb2?
<persia> qense: The 4 dots are independent of anything else.  File the bug against ureadahead and the plymouth theme.
<persia> wgrant: Supposedly.  I've not actually fiddled with one.
<qense> persia: OK, I'll do.
<qense> thanks
<persia> wgrant: More specifically, every ARMv7(a) solution is expected to support Thumb2 : it's part of the specification.
<wgrant> persia: Ah, I see.
<persia> The choice of instruction set (-marm vs. -mthumb2) is just a matter of code density.  -mthumb2 saves about 40% code size at about a 10% performance loss, which usually ends up at equivalent or better performance because of l2 cache sizes.
 * wgrant has just an ARMv5 device running Debian.
<persia> wgrant: As much as I'm happy with my NetWalker, until the kernel situation fixes itself (Go DeviceTree!), I can't recommend more unless you really want to hack on stuff.
 * persia kinda wishes someone would either port wine to powerpc/sparc/armel *OR* make the builds fail sooner
<wgrant> and/or P-a-s it.
<persia> I don't much like P-a-s.  Most of my experience with it has been finding it obnoxiously hard to get stuff *off* the list when it was overly precise to make new ports happen.
<persia> But wine has a specific call to check the platform that runs well into the build and dies if it doesn't match a set.  Such a check should happen *before* compiling everything.
<persia> Alternately, it should be dropped, and if people actually have powerpc or sparc Windows binaries, they can report bugs.
<persia> wine/armel is kinda special, because there never was a Windows port to armel.
<chrisccoulson> persia / wgrant / StevenK - thanks for fixing the GNOME breakage
<persia> chrisccoulson: Thank Hobbsee also, but it needed doing.
<chrisccoulson> oh, thank you Hobbsee too
<wgrant> chrisccoulson: No problem.
<chrisccoulson> (sorry, i thought i'd got everyone from the scrollback)
<wgrant> Somebody might want to poke ubuntustatus about it.
 * chrisccoulson thinks that we probably shouldn't unfreeze on a friday afternoon again
<wgrant> Possibly not.
<wgrant> But it wasn't too troublesome to fix, once we found a core-dev or two.
<chrisccoulson> yeah, i wish i could have helped a bit. i can't upload cdbs, but i could have uploaded most of the components that were broken
<wgrant> Oh, right, packagesets. Handy.
<chrisccoulson> yeah, i can upload stuff in the ubuntu-desktop packageset
<chrisccoulson> but cdbs isn't in that
<didrocks> chrisccoulson: +1 on not unfreezing on Friday
<chrisccoulson> didrocks - yeah, i think we should probably raise that on monday. i know seb128 was concerned too
<wgrant> I'm a little concerned that a whole lot of people knew it was broken, apparently pinged relevant people about it, then all went to bed.
<cjwatson> well, having the beta slip wasn't in anyone's original plan
<didrocks> chrisccoulson: I was too. Also, on my previous company, I have very very bad examples on "releasing" on Friday (unfreeze == release, especially after a beta/alpha when everyone will upgrade after installing themâ¦)
<didrocks> sure
<cjwatson> once it did slip, what else were we supposed to do?  people were screaming for an unfreeze
<chrisccoulson> cjwatson - do we really gain much by unfreezing on friday? i don't think it would have hurt to wait until monday...
<didrocks> sure, but at least, we have good examples know to show how wrong it happens and make people wait a little more (just some thoughts there)
<didrocks> chrisccoulson: the only thing is that people are testing on week-end, so, we basically waste a week
<cjwatson> chrisccoulson: hindsight is 20:20; yesterday, lots of people were clamouring for unfreezing
<persia> I think we gain a *lot* from friday unfreeze.
<persia> That said, in the rare event it happens, more folk should be around to cover until the next timezone becomes available.
<cjwatson> fwiw, from what I can see from scrollback, this got fixed nearly as quickly as it would have done on a Monday night
<cjwatson> and I can say that without particular defensiveness since I wasn't involved
<persia> Well, not quite.
<wgrant> We only decided to fix it nearly three hours after it was first brought up.
<persia> There were a couple core-dev who saw the problem and didn't jump on it shortly after discovery, and the heavy push didn't start until about 4 hours after discovery.
<didrocks> sure, nobody's to blame here and that's not the point. It's just that it's risky and can be in some cases more critical
<cjwatson> the timezone thing would have bitten the same way on Monday, wouldn't it?
<persia> didrocks: Agreed. My suggestion is that some of those folk in the far western timezones might stay a little later on a Friday night that we unfreeze until those in the far eastern timezones are around, rather than delaying the freeze another 3-4 days.
<kklimonda> ww/w 10
<persia> cjwatson: Depends.  Often people in the Americas stay late enough in their evenings to catch Asia/Oceania through to mnidday or so.
<kklimonda> persia: do you know how it sounds? "you guys have to stay for few more hours on the friday night"? ;)
<persia> kklimonda: Only on a release delay.
<persia> And we caught it anyway, just I think it's better than not unfreezing.
<persia> This happens once a year or so, so it oughtn't usually matter.
<chrisccoulson> i did stay around quite late last night, but i was powerless to do anything :/
<persia> Understood.
<wgrant> The privilege problem was easily solved with enough determination. Things might have been set in motion a bit quicker if it hadn't looked like the right people had been poked a few hours earlier.
<persia> Indeed.  It was explicit notification that some folks were going to bed without fixing it that helped get me noisy about it.
<cjwatson> Did anyone in Canonical invoke DealingWithCrisis for this?
<persia> (not that those folk had permission to fix, but the sense "the day is over now: it will get solved in the morning")
<persia> Not that I saw.
<cjwatson> That's perhaps a shame ...
<cjwatson> It doesn't look as though chmod 0 on the archive would have helped anything, but there are other measures there that can be helpful in this kind of situation
<cjwatson> particularly waking appropriate people
<wgrant> It didn't really need people to be woken. It just needed the people who were awake to be aware that it wasn't being handled by the normal people.
<persia> And once they were made aware, it got sorted about as fast as publisher could churn
<cjwatson> wgrant: one of the measures in DealingWithCrisis is an explicit statement that, if you're awake and know about a crisis, you have to explicitly hand it off to someone before going to sleep
<wgrant> cjwatson: Ah, good.
<cjwatson> it's designed as a recipe for remembering the things you always forget when things are going wrong
<wgrant> We could have saved some time with some judicious publisher hand-holding, but it went OK.
<cjwatson> so I think, in retrospect, it should have been used here
<cjwatson> perhaps we should make it, or some parts of it, public so that people not in Canonical can more easily DTRT; they may not have all the necessary phone numbers, but ...
<cjwatson> I'll follow up on that on Monday
<wgrant> Thanks.
<cjwatson> Caesar: let me know what you want, we're not necessarily available at the same time ...
<cjwatson> Caesar: (answering your ping from 02:26 UTC)
 * wgrant sleeps.
<asac> directhex: why didnt we get mono 2.6? ;)
<asac> is that a intrusive thing requiring all rdepends to get adjusted etc. ?
<ogra_cmpc> asac, x-loader sits in NEW, bug 542662 is filed, we just need a FFe and MIR for it now
<ubottu> Launchpad bug 542662 in ubuntu "[needs-packaging] x-loader for omap needs to be packaged to build beagleboard images" [Undecided,New] https://launchpad.net/bugs/542662
<ogra_cmpc> (i wasnt sure if i should put all three in the same bug)
<persia> Conserve bugs today!  Reduce, Reuse, Recycle!
 * persia finds it very frustrating to have to page back and forth through 3-4 bugs to track one issue
<ogra_cmpc> ok, i merged FFe and needs-packaging ... i suspect MIR needs to go separately though
<persia> Why?
<ogra_cmpc> because the upload will close the needs-packaging one :)
<persia> Well, it won't, because of a bug, but yeah, I see your point, and accept it.
<ogra_cmpc> heh, thanks
<persia> And there's stuff to be done post-upload pre-MIR (like setting a bug contact, etc.)
<ogra_cmpc> right
<emgent> good evening.
<jelmer> Laney, hi
<asac> ogra_cmpc: great ;)
<directhex> asac, because 2.4 is upstream's LTS branch. but yes, there'd be some fiddling involved in changing now. lots of fiddling.
<asac> directhex: asking because its claimed that all armel test failures are fixed there ;)
<asac> directhex: do we have a package somewhere so i could verify?
<directhex> i've heard that kind of assurance pretty frequently
<asac> maybe debian experimental?
<asac> hehe
<directhex> it's not in experimental yet. meebey's started on it, i believe
<asac> directhex: well, we vargaz backported one more patch to 2.4 ad that fixed 6 test cases ;) .... however, he said the rest is tough to backport because it relies on other changes
<asac> directhex: is it straight forward to build 2.6 from svnlocally?
<asac> directhex: or do i need a bunch of other libs to be updated etc.?`any idea?
<directhex> make sure it goes into a non-$PATH prefix
<asac> directhex: yeah. i can do that. do i need to run make install before running tests?
<directhex> and keep a close eye on library dependencies (i.e. you may need to manually call gacutil -i to install system mono libs into the svn mono GAC)
<directhex> tests, no, make test should be fine just from building
<asac> right. thats basically what i want to try only ;)
<asac> any important configure options i should use?
<directhex> nah, not really
<asac> cool
<directhex> brb, need to get some lunch
<asac> directhex: svn co svn://anonsvn.mono-project.com/source/trunk/mono  ?
<asac> or do i need more modules?
<directhex> asac, you need the mcs module too
<asac> kk
<asac> so that needs to get built first?
<asac> hmm. guess i need to install then
<directhex> nah, put mcs and mono in the same place, and mono configure will look in ../mcs/
<directhex> iirc
<asac> cool
<asac> thanks
<asac> enjoy lunch ;)
<directhex> asac, short version, if you're serious about 2.6 in lucid, you need to get meebey in here immediately and find some way to bribe him into reallocating all his "new gaming pc and game" time into "debian" time to have even the slightest hope of something being ready in time
<pitwalker> in lucid beta the runlevel 1's menu first entry why not work - "resume    Resume normal boot"?
<doko> pitti, kees: any idea about http://launchpadlibrarian.net/41422691/buildlog_ubuntu-lucid-amd64.gdb_7.1-1ubuntu1_FAILEDTOBUILD.txt.gz ?
<doko> Searching for duplicated docs in dependency gdb...
<doko> cd: 17: can't cd to debian/libgdb-dev/usr/share/doc/libgdb-dev
<doko> make: *** [binary-makedeb-IMPL/libgdb-dev] Error 2
<mnemo> how can I verify that a sync from Debian is safe? i.e. how can I fetch the Debian package and build it on Ubuntu ?
<persia> mnemo: `pull-debian-source foo; sbuild lucid foo.dsc`
<mnemo> persia: that gave me the squeeze (testing) version, but I want the sid (unstable) version of the Debian package
<mnemo> found it now.. "pull-debian-source blah unstable"
<lifeless> bzr branch lp:debian/unstable/packagename foo
<mnemo> the bzr way didn't work actually
<mnemo> http://paste.ubuntu.com/398367/
<mnemo> and if I use "pull-debian-source blah unstable", then sbuild fails :(
<mnemo> http://paste.ubuntu.com/398366/
<mnemo> I suppose I need to run "sbuild-createchroot" but I don't know what params to pass to it
<persia> mnemo: `mk-sbuild lucid` should do it, if you're running lucid.
<LaserJock> persia: does mk-sbuild only work with lvm?
<mnemo> "sbuild lucid foo.dsc" didn't work but "sbuild -d lucid-amd64 foo.dsc" worked perfectly
<mnemo> thanks persia and lifeless
<lifeless> anyone remember the website/script that reports on patches for packages across multiple distros?
<jcastro> harvest
<jcastro> lifeless: this what you're looking for? http://daniel.holba.ch/harvest/
<mneptok> jcastro: http://bit.ly/9phQJZ
<jcastro> mneptok: I am now aware of those, thanks!
 * mneptok bows
<lifeless> jcastro: no
<lifeless> jcastro: though it is, similar.
<pa__> hi
<pa__> is it normal that i have an ntop running since mar 03?
<pa__> that i cannot see on consoles?
<pa__>  /usr/sbin/ntop -d -L -u ntop -P /var/lib/ntop --access-log-file /var/log/ntop/access.log -i eth0 -p /etc/ntop/protocol.list -O /var/log/ntop
<kees> doko: I imagine it's from whatever change was made for "* Do not duplicate documentation in gdb64, gdb-source, and libgdb-dev.
<kees> "
<kees> but I've not see that error before
<lamont> so how come we still regenerate the font cache on every font install?
<lamont> seriously.  was it necessary to throw the max/min/kill buttons to the other side of the window?
<wgrant> lamont: That's what the Internet said.
<wgrant> But DX says yes.
<mnemo> (and also re-order them)
<Tm_T> lamont: I keep menu button in left side (double/tripleclick closes) and maximise in right side
<lamont> because yeah, 20 years of muscle memory is nothing
<xnox> To have room for zeitgeist button
<lamont> it was bad enough when karmic made the window borders 1 pixel so that I couldn't grab-n-drag to resize with my poor laptop built-in mouse, but really?
<wgrant> lamont: Oh, I thought I was the only one who noticed the thin window border thing.
<wgrant> That annoys the crap out of me.
 * lamont goes looking for a background that is less harsh on his eyes
<cjwatson> lamont: I like Cosmos
<lamont> cjwatson: it's very pretty.  and not very ergonomic
<lamont> "indicator-applet" closed unexpectedly, and apport doesn't support reporting that kind of crash.
<cjwatson> how can a wallpaper be ergonomic?
<lamont> I wonder how known that is
<cjwatson> (Cosmos is one of the default background selections.  Actually it's a slide-show)
<lamont> if it enhances eye-strain, it's not ergo
<wgrant> lamont: Was it an assertion failure?
<lamont> ISTR yes
<wgrant> I've had it did like that once.
<cjwatson> oh, I haven't noticed eyestrain from it
<cjwatson> of course, normally my wallpaper is hidden by maximised windows, and I only see it on occasion
<lamont> shift + super == ??
<lamont> yeah - I don't maximize windows, and get annoyed everytime an app (hello oo.o, evince, etc) believes that it should maximize on opening
<lamont> is it just me, or are the + and - header in xchat etc taking more spaces than the right/down arrows did?
<lamont>   devicekit-disks libparted1.8-12 <-- I wonder, do I need those, or does libvirt-bin need a good beating?
<lamont> so is there any easy config option in gnome to get the min/max/kill buttons back where my fingers think they are?
<tjaalton> yes
<tjaalton> /apps/metacity/general/button_layout
<tjaalton> from gconf-editor
<cjwatson> lamont: both devicekit-disks and libparted1.8-12 are obsolete
<cjwatson> unfortunately due to a conflicts in the *old* libparted runtime package (thus not deletable without time travel) the upgrade is more complicated than it ought to be
<tjaalton> move the colon in front
<Laney> and swap min/max
<lamont> yeah
<tjaalton> oh that too
<lamont> interesting... when the stupid typing monitor tells me to take a break now, I have to move the mouse before I can hit alt-p to delay the break...  this is not how I want that to work
<tjaalton> 'maximize,minimize:,close' seems best for me
<Laney> what's the comma?
<lamont> actually have to mouse over the button before the button decides to exist.
<lamont> Laney: a separator
<tjaalton> Laney: heh, the other one was extra in this case
<Laney> oh, I thought it might mean something in that context
<lamont> ok. so after I accidentally break a tab out of a firefox window by dragging it up and out, how the &*(%^)*&_%^_)  do I get it back into the tabbed window?
<Laney> you can just drag tabs between windows
<crimsun> kees: could you parse the second bullet in the initramfs-tools 0.92bubuntu69 changelog for me, please?
<lamont> and when there are no tabs?
<Laney> open a blank one so you get the tab bar, I guess
<lamont> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
<lamont> so... this release is causing me to dig into more and more arcane bits of gnome that I've never cared enough to tweak.
<lamont> how do I change that nice slate-grey background inside the app menus, so that I can actually read the text that comes up.
<lamont> that is, where is the *^( color theme defined/modified?
<wgrant> lamont: Most apps should have light text in their menus.
<wgrant> Except strange creatures like Evolution which override the text colour in parts.
<lamont> firefox, giving me ideas of what I'm typing, gives me a nice dark blue on grey which is completely  unreadabkle
<lamont> and it seems to have adopted the panel color
<lamont> and once I get far enough on this, I'll check that buildd
<geser> doko, kees: see http://launchpadlibrarian.net/41456559/gdb_7.1-1ubuntu1_7.1-1ubuntu2~ppa1.diff.gz for a gdb FTBFS fix. The problem was that the build symlinked the whole /usr/share/doc directory and that the symlink can only be resolved for the installed package and our symlinking code tried to access it. Disabling the doc symlinking for those two packages fixes it.
<cjwatson> lamont: IMO that firefox thing is just a bug and should be reported as such if it hasn't been already
<cjwatson> there's no way that can be a desirable default colour combination
<lamont> cjwatson: against firefox?
<doko> geser, kees: well, I'd rather disable the symlinking code if the docdir is a symlink
<cjwatson> lamont: dunno, that would be a start I guess ...
<cjwatson> or light-themes?  dunno
<doko> geser: there are more packages using symlinks for the doc dirs
<geser> doko: true
<doko> geser: I just can't see which change in cdbs did change this. it did work 10 days ago with the cdbs snapshot
<doko> gdb snapshot
<geser> doko: the rules file from the snapshot didn't symlink the /usr/share/doc directories, this change came with the merge/last upload (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gdb/lucid/revision/46#debian/rules)
<doko> geser: I'd rather fix cdbs to do nothing if a symlink is found
<geser> doko: I might have an idea how to fix it but want to talk to pitti first as I'm not fully sure about it
#ubuntu-devel 2010-03-21
<dylan-m> Anyone here happen to know if the software-center reviews / ratings feature is going to land for Lucid?
<nigelb> dylan-m: It is.  http://www.jonobacon.org/2010/02/23/awesome-ubuntu-software-center-updates/
<wgrant> The spec was updated a few days ago in ways which indicate that it has been deferred.
<wgrant> And I would hope that it had been deferred, at this point.
<nigelb> oh
<dylan-m> wgrant, nigelb: Indeed, I suspected that since the rating is using popcon data now :)
<dylan-m> Oh well, it was a bit gutsy for one cycle; lots of web infrastructure changes to make!
<wgrant> Yes.
<wgrant> And they were left far too late, as usual :/
<dylan-m> Makes my job easier :P
<wgrant> I might also point out that it looks like the Django backend is proprietary, so it's reasonable to complain :)
<dylan-m> (well, slightly. The slideshow probably wouldn't be mentioning reviews anyway, but somebody is bound to think it should).
<lamont> ScottK: do we want 2.6.6 in a karmic ppa somewhere?
<ScottK> lamont: I didn't look to see what's fixed in it.  It seems to me that Postfix is another package we ought to get TB permission to push through -updates.
<lamont> building it to toss in my ppa now, feel free to push on the TB - I'll even chime in with a +1
<ScottK> OK.
 * ScottK piles it on the TODO.
<lamont> tree pushing to alioth, package uploaded to ~lamont/+ppa/karmic
<lamont> so I realize it's all supposed to be magically intuitive and all that, but why do the window titles in the bottom panel have some random one lighter than the others?
<ion> Hm. I donât have such behavior. Lighter exactly how? The text or the background?
<persia> lamont: Does it appear to have any relation to focus?
<lamont> persia: yes
<ion> Desktops have been highlighting the focused window in the window list one way or another at least since Windows 95. :-P
<persia> lamont: In that case, I presume the answer is "To let users know which application they have focused right now"
<persia> ion: Depends on which window list.  The one I use doesn't do that (even in lucid)
<ScottK> It's funny how many systems insist on helping me solve this confusion that I really almost never seem to have.
<lamont> people.debian.org/~lamont/focus.png
<lamont> which reminds me that I should fix it so I can actually put things on people.u.c again
<lamont> there.  that wasn't hard
<lamont> except for the part where I need to do one more thing tomorrow
<lamont> persia: intersting.  zombies have taken over
<persia> It always ends up that way when the Trioxin containment fails.
<lamont> wgrant: bug 543162
<ubottu> Launchpad bug 543162 in launchpad-buildd "launchpad-buildd exception: Try to register an already registered process." [Undecided,New] https://launchpad.net/bugs/543162
<lamont> wgrant: you want anything more than the bug has before I stab them?
<wgrant> lamont: Let's have a look.
<lamont> wgrant: so from that, what we have is lp-buildd with a zombie scan-for-processes child, and no love.
<wgrant> lamont: Can you attach the lp-buildd log for the whole build, just in case?
<lamont> I'm firmly confident that a restart of lp-buildd will fix that immediate instance of the issue, beyond that, pain
<wgrant> Right.
<lamont> build-1550990-3166975  build-1569828-3204910 <-- pretty sure one of those just doesn't belong
<wgrant> Those are in /home/buildd?
<lamont> yeah
<wgrant> Sounds like something died a while ago, then...
<lamont> wgrant: and I'm gonna skip attaching 450KB of log
<Pretto> how can i file a bug about lucid updates messing with .desktop files?
<wgrant> Pretto: You mean adding X-Ubuntu-Gettext-Domain at the top of a few of them?
<Pretto> wgrant: yes
<wgrant> Pretto: That's been fixed for around 18 hours now.
<Pretto> wgrant: a lot of them
<Pretto> wgrant: ok so :D
<persia> Pretto: If you've a case where it's still that way after an update, please let us know, but we believe everything is fixed except gedit/armel
<Pretto> persia: updated today afternoon, got a lot of .desktop messes, actually i have a list of them
<wgrant> Pretto: Can you pastebin the list?
<persia> Pretto: Please put the list at paste.ubuntu.com : if there's something else needs doing, we can do it.
<Pretto> wgrant: of course
<lamont> builds slapped, building again
<wgrant> lamont: Thanks.
<persia> lamont: gedit/likewise-open?  Thank you.
<lamont> yep
<lamont> hrm... getting a screenshot of the crap colors in firefox will be problematic
<lamont> well, until I log into the machine from another machine to trigger the screen snapshot
<lamont> persia: mind you, there's no guarantee that they won't die in exactly the same way when they finish building this time
<persia> Well, I can hope :)
<lamont> heh
 * lamont wanders off.  g'night
<wgrant> Night.
<Pretto> wgrant: persia http://paste.ubuntu.com/398581/
<persia> Pretto: Which mirror are you using?
<Pretto> persia: main server
<persia> archive.ubuntu.com?
<wgrant> Those have all been fixed on archive.ubuntu.com for almost a day now.
<persia> Well, 18 hours, but yeah.
<wgrant> Right, something along those lines.
<Pretto>  persia yes
<wgrant> Pretto: Which version of gnome-panel do you have installed?
<persia> Pretto: Please try updating again.
<Pretto> wgrant: gnome 2.29.92
<wgrant> Pretto: I need the bit at the end as well.
<wgrant> -0ubuntuSOMETHING
<Pretto> persia: 19.6 mb of updates
<wgrant> Pretto: Install them and see if they help.
<Pretto> wgrant: gnome 2.29.92-0ubuntu1, but i will update now
<Pretto> by the way, i have fixed the .desktop manually
<lamont> do-release-upgrade -d
<lamont> Checking for a new ubuntu release
<lamont> No new release found
<lamont> ok.  what did I break underneath myself?
<persia> lamont: Are you perhaps already running lucid?
<wgrant> Or trying to upgrade Hardy->Lucid?
<lamont> hardy->lucid
<lamont> is that not yet believed in?
<wgrant> Lucid's not in meta-release-lts yet
<Pretto> got some parsing errors after update
<wgrant> Even as a development release.
<lamont> well, given that it works on a different machine, I'm inclined to believe that I'm just being cruel to the underlying host
<wgrant> Hm, maybe meta-release* aren't important any more.
<lamont> meta-release-lts gets fetched from changelogs.u.c still, yes?
<wgrant> Oh, oops, wrong file.
<wgrant> Yes.
<wgrant> OK, so Lucid is there.
<wgrant> So it should just work.
<lamont> yeah - blocked port.
<Pretto> wgrant: where can i find update log?
<wgrant> Pretto: /var/log/dpkg.log might help.
<wgrant> Pretto: Which versions of gnome-panel and nautilus do you have now?
<Pretto> wgrant: gnome panel Version: 1:2.29.92.1-0ubuntu3
<wgrant> Pretto: That's the fixed version of that one.
<Pretto> wgrant: but i saw parsing errors on .desktop files, but i cant see it on dpkg log
<persia> that would be ~/.xsession-errors
<lamont> amusing. running hardy: Prompt=lts --> lucid upgrade.  Prompt=normal --> intrepid upgrade
<Pretto> persia: no, i meant inside the xterm windows in the update-manager
<lamont> somehow that feels worthy of a bug
<persia> lamont: That's intentional.
<lamont> srsly?
<persia> lamont: Yes.  It looks odd here, but e.g. intrepid -> lucid isn't well tested, and may explode.
<persia> lamont: So, "normal" always goes to the next 18-month release.
<lamont> persia: not only untested, but expected to explode
<persia> No.
<persia> It might work.  We don't actually know.
<lamont> OTOH, if I'm running d-r-u, I'd want to at least get asked "oh, hey, which of these 2 supported upgrade targets do you want to use"
<persia> But we also don't know that it *will* explode.
<lamont> otherwise the less-attentive will wind up doing 4 upgrades in the place of 1
<persia> lamont: Now that's worth a bug.
<wgrant> Well, if you had upgrades set to 'normal', you would have been prompted to upgrade 18 months ago.
<ScottK> There won't be two supported upgrades.
<ScottK> Intrepid goes out of support ~ the same time Lucid becomes supported
<lamont> wgrant: and I might have said 'no'
<lamont> ScottK: probably.  there isn't actually any guarantee of that
<ScottK> lamont: True, but based on the promised support timeframes.
<lamont> and hopefully d-r-u DTRT when intrepid goes *poof* and then someone runs it (notice and use old-releases.u.c)
<lamont> we've overdelivered in the past
<lamont> not always, and sometimes by < 10 days, but...
<persia> I'm fairly certain d-r-u doesn't know about old-releases.u.c : I strongly suspect it needs a patch to Ubuntu.info.in in python-apt
<lamont> persia: you lie
<lamont> mvo added code for us when, um, hardy came out
<lamont> because of the fun manual "fire up another terminal and edit sources.list" step for doing edgy->F->G->hardy
<persia> Well, I know python-apt doesn't know about it.  If it's special-cased in do-release-upgrade, that's not entirely bad.
<lamont> it's in the tarballs that get downloaded
<lamont> d-r-u just parses the metafiles
<lamont> afaik
<lamont> anyway, bug 543165 filed, targeted at beta-2 just because
<ubottu> Launchpad bug 543165 in update-manager "do-release-upgrade -d tries to install intrepid" [Undecided,New] https://launchpad.net/bugs/543165
<persia> Well, d-r-u does a bit more than just parse, but yeah, if it's in the tarfiles, all is good.
<Pretto> persia: do you know the command to parse .desktop files? i mean to test all of them
<Pretto> something like a rebuild
<persia> There's validate-desktop-file for validation.
<persia> They are built as part of package build: there is no rebuild tool.
<wgrant> desktop-file-validate, actually.
<persia> RIght.
<persia> Although it doesn't get used that much.  I don't install a bunch of stuff, and have 62 validation errors of one sort or another.
<Pretto> too much work, i need to do it file by file
<Pretto> persia: it's ok now
<Pretto> the parser is oli reporting errors like this
<Pretto> only*
<Pretto>  key "StartupNotify" in group "Desktop Entry" contains invalid characters, boolean values must be "false" or "true"
 * abhinav is away: Abhinav|away
 * abhinav is away: breakfast
<persia> !away > abhinav
<ubottu> abhinav, please see my private message
<kees> crimsun: sorry, I massively wrecked that changelog english.  :(  It should read "scripts/init-top/framebuffer: create "fbmode" argument to allow forcing a mode via fb /sys interfaces, for framebuffers that do not correctly handle setting mode via module options."
<lamont> kees: the new version is english?
<lamont> :-D
<kees> lamont: heh.
<pda-> php5-cli in lucid seems to have lost its readline support.. anybody know anything about this, or know where I should look?
<micahg> pda-: you can check with the server team in #ubuntu-server
<pda-> ok cheers
<pda-> (re php5-cli/readline: I've submitted LP bug #543212)
<ubottu> Launchpad bug 543212 in php5 "php5-cli in lucid-beta1 missing readline/libedit support" [Undecided,New] https://launchpad.net/bugs/543212
<MTecknology> Is there any reason our default umask is 022 instead of say 0027?
<wgrant> MTecknology: https://blueprints.edge.launchpad.net/ubuntu/+spec/umask-to-0002 is relevant, but goes the other way.
<MTecknology> wgrant: WTF!?
<MTecknology> please for god sake tell me that's not actually going to make it into main...
<wgrant> Why not?
<wgrant> It has a good rationale.
<MTecknology> can that at least be a different default for server installs?
 * wgrant is not involved with it at all.
<MTecknology> the 022 seems very lax
<MTecknology> giving g+rwx seems like it's right next to permission 777 which is -brilliant-
<wgrant> But the default group contains only the user.
<MTecknology> i suppose, what about the thought of 007?
<MTecknology> would that sound reasonablY?
<MTecknology> wgrant: thanks for the link
<iulian> asac: Hi.  Have you got a couple of minutes to take a look at bug #482890 and say your opinion about it?
<ubottu> Launchpad bug 482890 in mozilla-noscript "Please sync mozilla-noscript 1.9.9.27-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/482890
<iulian> I'm inclined to accept it but I would like to hear your opinion as well.
<chrisccoulson> iulian, the current version in the archive doesn't work with 3.6 anyway
<chrisccoulson> iulian, we should either sync it or remove it from the archive entirely
<chrisccoulson> so i would just accept the sync
<iulian> chrisccoulson: OK.
<ScottK> iulian: I was going to say ....  Given the plans for Firefox getting continuous updates, I'm more inclined towards removal for such thing.  At some point in the next three years it's sure to be totally broken again.
<iulian> ScottK: Hm, alrighty.  Would you like to add a comment saying that?
<ScottK> iulian: I didn't put it in the bug, because I really wasn't sure.  You've already given it an ack, so I wouldn't propose that I'd override that.  Feel free to copy/paste into the bug if you think it's worthwhile.
<iulian> OK.
<chrisccoulson> ScottK - I've been going through the extensions in the archive recently to try and decide what to do with them with the new firefox support model
<chrisccoulson> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list
<chrisccoulson> you're more than welcome to share your opinion on any of those :)
<chrisccoulson> but, my preference for most of them is to just remove them
<ScottK> chrisccoulson: I don't have expertise to have an opinion on any specific one, generally I think that unless there is some reason to believe they'll be usable for a couple of years of Firefox updates, they should be removed.
<chrisccoulson> ScottK - there are some extensions that will be ported to newer Firefox versions in the future, but I think most extensions we have in the archive will break at some point during the life of the release when we roll out a new major firefox version
<chrisccoulson> directhex - do you look after beagle?
<ScottK> Even the ones that would be ported, the in archive version would still be broken.
<directhex> chrisccoulson, to a degree, that degree being "beagle's dead and we can't get it to work against the new gmime"
<chrisccoulson> directhex - excellent. if it's dead, would you mind disabling the mozilla extension? (i think it provides one doesn't it?)
<Laney> no, it's been ported
<Laney> there's just a crash that we haven't/can't debug, so won't upload
<directhex> Laney, i guess the moz bit needs porting to ff3.6... i think we should disbale it
<Laney> we need to upload to disable evo anyway
<chrisccoulson> Laney - the extension will most likely break again during the life of lucid, when new FF versions are introduced...
<chrisccoulson> so i'm not sure how we can maintain that
<Laney> but the reason we didn't upload isn't because we don't have a reason to, it's because we know it to be crashy :(
<chrisccoulson> ah ;)
<Laney> it's not even in squeeze atm
<Laney> chrisccoulson: I'd advise you to just do it in lucid
<Laney> maybe grab from svn and upload that
<chrisccoulson> Laney - ok, thanks. i'll do that when i next get the chance
<lamont> so... when uxterm is obscured by a terminator window, and then unobscured through a change in workspaces, it does not redraw the obscured portion... which package gets that bug (new to lucid)
<persia> lamont: Does this only happen with terminator, or other obstructions as well?
<lamont> not xchat, not other uxterms
<lamont> not firefox
<lamont> bored of checking
<lamont> just for the record: PII-233?  slow.
<persia> lamont: File against terminator then :)
<lamont> terminator maintainer, he say X
<lamont> if it's terminator, then it's really libgtk
<persia> Perhaps, or perhaps not taking advantage of one of those odd GTK_OPTION_WITH_REALLY_LONG_NAME_THAT_EVERY_APPLICATION_SHOULD_USE_BUT_IS_NOT_DEFAULT_FOR_NO_GOOD_REASON constants
<lamont> heh
<lamont> kinda like SO_REUSE, eh
<lamont> interesting... why did I wind up with grub1 on my upgraded box?  does grub2 not do root-on-lvm-on-raid yet?
<persia> I thought it did, but I also thought that there wasn't any automatic grub1->grub2 transition because there are too many corner cases.
<asac> iulian: acked too now
<lamont> ah.  that may be it - because my PII didn't get it either, and if ever there was a vanila config
<persia> SO_REUSE is a short one.  The one that caught my eye recently was gtk_image_menu_item_set_always_show_image (GTK_IMAGE_MENU_ITEM (item_toggle), TRUE)
<iulian> asac: Thank you.
<lamont> drwxr-xr-x 127 hpojlp lp 8192 2010-03-21 09:55 /etc
<lamont> say WUT?
<ubottu> Launchpad bug 8192 in ubuntu "woody->warty upgrade bugs and caveats" [Medium,Invalid] https://launchpad.net/bugs/8192
<lamont> thanks ubottu
<lamont> thanks not
<sebner> lamalex: hahaha! xD
 * lamont makes a note to see about reproducing that bug
<chrisccoulson> would a member of ubuntu-release be able to ACK bug 537900 for me please?
<ubottu> Launchpad bug 537900 in conkeror "[FFe] merge conkeror 0.9.1+git100220-1 from debian testing to get xulrunner-1.9.2 support" [Medium,Confirmed] https://launchpad.net/bugs/537900
<sheldon> hi, i cannot remove some packages from my personal ppa. I recevie this error
<sheldon> Unexpected form data
<sheldon> Launchpad doesn't understand the form data submitted in this request.
<micahg> sheldon: try #launchpad
<sheldon> thanks
<lamont>  â â´ââ¼âÂ°â¤ ââ¤ââ â¤âºâ¤â¼ â¼ââ¬ GRUB 2 â½âââ¤â» ââ½ Â°â¤â¼ââââºâ¼ââ Â°âºâ¼ â¤âºâ¤, ââÂ°âºâ¼â â¤âºâ¤
 * lamont thinks it may be confused
<AnAnt> Hello, will an update-alternatives method be provided to change the plymouth theme ?
<psusi> can anyone with more knowledge of udev weigh in on the proper fix to this important bug that really needs fixed before lucid ships?  dmraid currently goes into an infinite loop because every time it activates a raid array it deletes the partitions from the underlying disks, which causes another activation
<psusi> one way to fix it seems to be to modify the udev rule so that it only activates on add, not change
<psusi> another possibility would be to have udev remove the partitions when blkid detects that it is a raid member, rather than having dmraid do it on activation
<psusi> and I'm sure there's other ways I have not thought of...
<superm1> pitti, i was thinking as an alternative to checking glob(/var/lib/apt/ etc), you could probably instead just check for 'dkms' instead of 'bash'.  most of the drivers enabled via jockey would need DKMS anyhow, so having that on the repository should be a good indicator
<jcastro> crimsun: I have a machine that isn't remembering it's volume level in alamixer, I did the alsactl store 0 mention in SoundTroubleshooting, am I looking in the wrong place?
<ebroder> Does anybody understand how the openjdk packaging works? I want to try and get a commit from upstream cherry-picked, and I can't figure out how to do it
<micahg> if I have a package that FTBFS when it built, but builds fine now, do I need to bump the ubuntu version or can an archive admin respin (It FTBFS on everything except i386)
<ebroder> micahg: Whoever uploaded the package has a button they can click to rebuild
<wgrant> micahg: Anyone with upload rights can retry it. Which architecture?
<wgrant> Er, which package?
<micahg> libtunepimp
<wgrant> Ah, main. I can't help you there.
<micahg> wgrant: that's why I'm in here :)
<RAOF> micahg: How's gjs going?  When trying to get a jit-disabled package I found that armel ftbfs even with the jit disabled now, so that's not a winner :(
<micahg> RAOF: ok, we'll have to fix it before beta 2 then
<micahg> RAOF: I'll see if asac has any quick ideas
<micahg> RAOF: can you respin libtunepimp on amd64 for lucid?
 * RAOF is also not core-dev
<micahg> hmmm
<micahg> kubuntu-dev has rights as well if that helps anyone...
<cody-somerville> Link?
<micahg> cody-somerville: amd64: https://edge.launchpad.net/ubuntu/+source/libtunepimp/0.5.3-7.2ubuntu1/+build/1473412
<cody-somerville> micahg, What makes you think a rebuild will fix that issue?
<micahg> cody-somerville: I just tried it in pbuilder...I can upload to PPA if you want to see
<cody-somerville> Is it a newer version of libtool stuff that makes it build successfully now?
<cody-somerville> Anyhow, retried build
<micahg> cody-somerville: no idea
<micahg> didn't have time to look too much into it
<crimsun> jcastro: which release? what is appearing not to remember (e.g., GNOME login? gdm login-ready?)?
<micahg> cody-somerville: it built :) can you respin the rest of the arches?
<cody-somerville> micahg, aye, done.
<micahg> cody-somerville: thank you...that should save some xubuntu people trouble on upgrade :)
<jcastro> crimsun: lucid, the "Speaker" slider in alsamixer always reverts to 0
<jcastro> crimsun: I can slide it back and then the volume is normal, but it keeps reverting to 0 on reboot/login.
<crimsun> jcastro: so the stored gdm volume is 0. Nuke /var/lib/gdm/.pulse*
<jcastro> crimsun: ok, anything useful you need from it? It's a regression from karmic so I want to make sure the info goes to the right place
<crimsun> jcastro: the files themselves aren't useful; I'll just need to spend time this week working on an upgrade path
<crimsun> no idea how that's going to happen, since cansecwest is this week, too
 * ebroder sighs
<ebroder> Where are the docs on doing merges with bzr again?
<xnox> ebroder, wiki.ubuntu.com/DistributedDevelopment
<xnox> or something like that
<xnox> not sure typing by heart =)
<ebroder> Yeah, but I can't find it anywhere in there
<ebroder> https://wiki.ubuntu.com/DistributedDevelopment/ClientToolsV1Design is the closest I can find to actually having commands of any the pages /DistributedDevelopment links to, and that one doesn't actually help me
<cjwatson> look up a bit
<cjwatson> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<cjwatson> which links to https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<ebroder> Aha. That's a very small link on a comparatively long page
<ebroder> Hmm...I'm getting http://ubuntu.pastebin.com/HVpFcqri
<ebroder> And when I look at debian/control and debian/rules the whole file is just wrapped in conflict markers (i.e. there's nothing detected as common between the two revisions)
<cjwatson> 'bzr help remerge' might help
<cjwatson> if it works
<ebroder> Well...`bzr remerge --merge-type weave` seem to have...done something? Let me look
<ebroder> Yeah, it looks like that worked
#ubuntu-devel 2011-03-14
<Terminus> hello. it was suggested that i ask this question here. is there any chance that this fix will make it into lucid? --> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/584797
<ubottu> Ubuntu bug 584797 in vim (Ubuntu) "vim loses left/right cursor keys in insert mode when editing SQL" [Undecided,Fix released]
<nigelb> !sru | Terminus
<ubottu> Terminus: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<nigelb> You'll have to follow the guidelines there for an SRU
<Terminus> nigelb: i see. thanks.
<gua> hi, not sure if this is the best place to put this, but i noticed ubuntu-10.04 server torrents were linked under the "Ubuntu 10.10" header instead of 10.10 torrents at the bottom on http://www.ubuntu.com/desktop/get-ubuntu/alternative-download#bt
<micahg> gua: please file an issue here: https://bugs.launchpad.net/ubuntu-website/
<gua> ah ok
<nigelb> whoa, that took a few moments to figure out what was wrong :(
<pitti> Good morning
<didrocks> good morning
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<sirlatrom> hi, got a possible bug in apt-get or aptitude but not sure which of the two to submit it to
<sladen> sirlatrom: which did you type when the bug/issue appeared :)
<sirlatrom> aptitude, but it uses apt-get right?
<sladen> sirlatrom: http://launchpad.net/ubuntu/+source/aptitude/+filebug
<sirlatrom> sladen: ok, thanks
<amitk> njpatel: I still don't see the skype icon in the status bar after getting friday's updates. (And yes, it is merely invisible. Clicking on the empty space brings up the skype dialog)
<njpatel> amitk, Urgh, I can't reproduce that after the updates at all :/
<njpatel> amitk, can yo ufile a bug please?
<njpatel> I'll have another look this week
 * njpatel wonders what magic he can do to make it stay in the right stacking order
<SpamapS> wth? DMB moved their meeting to 12:00 UTC ?!
<geser> SpamapS: it alternates between 12:00 UTC and 19:00 UTC for some time now
<SpamapS> ahhh I didn't know that. :-/
<kirkland> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<SpamapS> well then..2 more weeks.
<kirkland> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: kirkland
<SpamapS> win 11
<SpamapS> doh
<SpamapS> kirkland: o/ morning
<kirkland> SpamapS: howdy
<geser> SpamapS: looks like you didn't miss anything as the DMB meeting was unquorate
<SpamapS> geser: right.. last time the quorum took 45 min to achieve, and I passed out from jet lag waiting for the meeting to complete. :-p
<kirkland> bryceh_: hi, about https://bugs.launchpad.net/ubuntu/+source/xchat-gnome/+bug/415586
<ubottu> Ubuntu bug 415586 in xchat-gnome (Ubuntu) "[Needs 0.27] xchat-gnome crashed with SIGSEGV in handle_command()" [High,Triaged]
<kirkland> bryceh_: i see the patch you attached,  i'm curious if there's a good reason you haven't uploaded yourself
<kirkland> bryceh_: I was about to do so as today's patchpilot, but wanted to check with you first
<kirkland> jamesh: ping
<kirkland> jamesh: i'm all kinds of confused about the state of lp:~jamesodhunt/ubuntu/natty/vim/add-upstart-syntax
<cjwatson> kirkland: (a) you have the wrong James, (b) I'm happy to handle that one since I handled the previous similar one
<kirkland> cjwatson: so i see (a), whoops
<kirkland> jhunt: ^
 * ogra_ was thinking upstart grew some python when seein (a) phew
<ogra_> *seeing
<cjwatson> lp:ubuntu/vim is out of date due to importer bugs
<cjwatson> which makes LP merge requests against it pretty confusing
<kirkland> cjwatson: yes, agreed
<cjwatson> I just processed the previous one by hand
<kirkland> cjwatson: i was about to import-dsc it
<cjwatson> I didn't bother :)
<kirkland> cjwatson: shall i just walk away from this one, then?
<cjwatson> as I say, I'm happy to handle it
<kirkland> cjwatson: k, thanks
<jhunt> cjwatson: thx from me too! :)
<cjwatson> jhunt: you should probably just 'apt-get source vim' for future changes, and file bugs with patches, until such time as the import is sorted out
<cjwatson> I'll massage this into 2:7.3.035+hg~8fdc12103333-1ubuntu4
<apw> cjwatson, jhunt, did either of you see my write up on the vesafb thingy?
<cjwatson> apw: not yet, where was it?
<apw> cjwatson, in the first instance direct email
<jhunt> cjwatson: ack
<apw> cjwatson, subject: framebuffer initialisation
<cjwatson> ah, drowned in my inbox
 * cjwatson finds it and will think hard about that
<cjwatson> vim> done (2:7.3.035+hg~8fdc12103333-1ubuntu5)
<jhunt> cjwatson: thx!
<kirkland> pitti: morning!
<kirkland> pitti: i'm reviewing https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/apport/bugfix-357847/+merge/53184  as part of my patch pilot day
<kirkland> pitti: against apport
<kirkland> pitti: i was wondering if you wanted to review that one yourself
<kirkland> pitti: and also if this one requires an FFe, in your opinion
<hallyn> hi all - there is a package in universe called celt, which is at version 0.7.1.  We need version 0.5.1 for another package.  Would it be best to create 'celt051' package?  (requiring users to pin seems so barbaric)  Is there a better name for the package?
<pitti> hey kirkland (sorry, was at the phone)
<kirkland> pitti: no problem
<kirkland> hallyn: that is the best way to solve that particular problem, but it's somewhat frowned upon, in my experience
<pitti> kirkland: hm, I'd rather avoid having that implementation in the shell wrapper
<kirkland> hallyn: usually, we lean heavily on the dependent package to modernize
<pitti> kirkland: so yes, I'd rather review it myself then; thanks for pointing out!
<kirkland> pitti: no problem
<hallyn> kirkland: so the name 'celt051' is ok?
<pitti> kirkland: (it should also be committed to trunk first)
<kirkland> pitti: right, i'll add a comment that I'm deferring to you
<hallyn> kirkland: you can see the depending's package's attitude to upgrading in the debian ITP  :)
<hallyn> IMO our options are (1) don't package it, (2) packaging something patched and incompatible with other distro's client/server, or (3) package 0.5.1.  I was hoping (2) would work better than it apparently will, so I'd started 2 in my ppa, but am now punting on that
<kirkland> hallyn: what's the depending package?
<hallyn> spice
<kirkland> hallyn: hah :-)
<hallyn> dev-zero is going to push the stuff in his ppa (with some modifications) into universe
<hallyn> (yay)
<hallyn> biab
<kirkland> hallyn: anyway, to answer your question, yes, that is the way to do it
<kirkland> hallyn: see python3, python2.6, python2.7
<abhinav-> ttx, thanks for reviewing it again :) . I did "bzr status" in my branch, it showed nothing, also I think catalina.policy is already present in conf/ ?
<ttx> ah?
<ttx> oh.
 * ttx branches and checks
<abhinav-> ttx :-)
<ttx> abhinav-: right, it's just the stock one, so it's already in.
<abhinav-> yes
<ttx> abhinav-: i'll test and sponsor that in. Tomorrow.
<manish> abhinav-: ping. on #ubuntu-in
<abhinav-> ttx,  ok thanks :)
<SpamapS> jhunt: /win 11
<SpamapS> dohh
<SpamapS> jhunt: hey.. I was just going to say hi, and let you know that I installed your upstart package.. no problems yet
<geser> jhunt: did you forward your upstart syntax changes for vim to Debian? so we have less delta for the next vim merge
<jhunt> geser: no - I forwarded them to vim.org.
<geser> that's also ok :)
<jhunt> geser: :)
<kirkland> pitti: hey, one more for you
<kirkland> pitti: i see you were the last to comment on https://bugs.launchpad.net/ubuntu/+source/langpack-locales/+bug/699886
<ubottu> Ubuntu bug 699886 in langpack-locales (Ubuntu) "Strange date format in en_SG locale" [Low,In progress]
<kirkland> pitti: the report has reported it upstream, as you requested
<kirkland> pitti: is it okay to apply the patch now to langpack-locales  and upload to natty?
<apw> cjwatson, thanks, i'd like you and jhunt to be happy before i go any further
<pitti> kirkland: sounds good! if you are at it, perhaps you can add the patch in bug 546581 as well?
<ubottu> Launchpad bug 546581 in langpack-locales (Ubuntu Natty) "Incorrect LC_MONETARY symbol of es_NI.utf-8" [Wishlist,Triaged] https://launchpad.net/bugs/546581
<ScottK> Bug #734957 <-- Less than one hour from reported to fix released ...
<ubottu> Launchpad bug 734957 in python3-defaults (Ubuntu) "py3compile fails on error output" [Undecided,Fix released] https://launchpad.net/bugs/734957
<slangasek> pitti: hi there; did you happen to see my bug about cdbs+python-scour making fontconfig unbuildable? (bug #734471)
<ubottu> Launchpad bug 734471 in cdbs (Ubuntu Natty) "cdbs python-scour dependency makes fontconfig unbuildable" [High,New] https://launchpad.net/bugs/734471
<pitti> hey slangasek
<pitti> slangasek: no, I didn't see it /me reading
<NCommander> directhex: you about?
<directhex> a little
<NCommander> directhex: need additional mono help :-(. trying that 2.10 setup with banshee failed with issues in Mono.Addins
<MadCow108> scottK:  haven't you reverted piotrs fix with your fix?
<MadCow108> which is in the same changelog entry ^^
<ScottK> No.  I added his.
<MadCow108> the diff only shows removal
<ScottK> We didn't have it in Ubuntu before.
<directhex> NCommander:  oh? odd, it should be using mono.addins from the gac. what does "/path/to/parallel/mono/bin/gacutil -l | grep -i addins" say?
<NCommander> directhex: no, that works, the problem is it throws exceptions
<ScottK> MadCow108: Yes.  Piotr's fix was to remove a bad change.
<directhex> NCommander: interesting. pastebin the errors?
<NCommander> directhex: give me a sec
<NCommander> directhex: root@risingsun:/# /opt/mono-2.10/bin/gacutil -l | grep -i addins
<NCommander> Mono.Addins, Version=0.4.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756
<pitti> slangasek: replied in the bug
<MadCow108> ah I understand, the log is from the cherry pick
<directhex> NCommander: yeah, the lib is definitely there. can you try erasing the addins cache from ~/.config/banshee-1/addins* ? there are lingering bugs in 0.4
<ScottK> Yes.
<NCommander> directhex: same crash
<directhex> weird
<NCommander> directhex: http://paste.ubuntu.com/580227/
<directhex> NCommander: /usr/bin/banshee is using your /opt banshee?
<directhex> um, /opt mono
<NCommander> directhex: yeah
<directhex> NCommander: can you try installing addins from sid? wait, did i remember to upload to sid?
<directhex> sigh, no
<NCommander> directhex: I can install them if you want
<NCommander> directhex: got a source package I can build?
<directhex> NCommander: in git
<NCommander> directhex: got it, building
<Laney> 14/03 18:32:54 <NCommander> directhex: I can install them if you want
<Laney> 14/03 18:33:04 <NCommander> directhex: got a source package I can build?
<Laney> 14/03 18:33:15 <directhex> NCommander: in git
<Laney> 14/03 18:36:05 <NCommander> directhex: got it, building
<Laney> OOPS
<Laney> sorry folks
<Laney> NCommander: you can run with MONO_LOG_LEVEL=debug to get even more output too
<directhex> bloody dsl
<lan3y> i got killed too, wasn't the dsl
<ari-tczew> ;o
<abhinav->  I just noticed that the application deadline for gsoc is over. I was wondering if Ubuntu applied or not ?
<highvoltage> lamont: hey there, I updated livecd-rootfs to install edubuntu theming in the ltsp chroot shipped with edubuntu. could you update it on the build machines so that we could have it in daily builds?
<hallyn> trying to install natty-desktop from friday's iso, from cd, it was hanging at partman.  (the hd had been pre-partitioned, which may or may not be relevant)  Anyone else see a problem like that?
<charlie-tca> hallyn: desktop cd's been doing it all weekend
<charlie-tca> ubi-partman error?
<MadCow108> can apparmor profiles handle XDG base desktop directories?
<MadCow108> XDG_CONFIG_DIR etc
<beuno> hallyn, I had that 2 weeks ago, and evan gave me a workaround which I can't find now
<beuno> it was bug #722198
<ubottu> Launchpad bug 722198 in partman-auto (Ubuntu Natty) "installation hangs on 15reuse w/ blank disk" [High,Confirmed] https://launchpad.net/bugs/722198
<jdstrand> MadCow108: I assume you mean dynamically at runtime. That would be 'no', though the situation could be improved somewhat by using variables in the profiles (which we don't yet)
<hallyn> charlie-tca: beuno:  thanks, great to know it's not just me :)
<hallyn> beuno: hm.  but i dont' have unpartitioned space.  it's all owned by lvm.  how is 'unpartitioned space' defined i wonder?
<MadCow108> with runtime you mean change it during apparmor running does not work? but it works when it does not change?
<charlie-tca> this is a different bug again, it is the old ubi-partman 141 error back
<charlie-tca> It doesn't care if there is blank drive space or not, from what I can tell
<jdstrand> MadCow108: by runtime, I mean something like @{HOM}/Private is mapped to something other translated string for 'Private'. that is not possible atm. One can update the profiles to use @{HOME}/<your translated 'Private'> and it would all work fine
<jdstrand> s/something/some/
<hallyn> charlie-tca: is there an open bug about it that you know of?
<leimy> Wondering about the ubuntu process of building release ISOs.  Is there some publicly available build scripts that could make it easy to make a derivative of ubuntu?
<charlie-tca> hallyn: I don't know. I saw an update for it today, hoping it got fixed and the images tomorrow will work
<leimy> For example I'd really like a 64bit version of JeOS.
 * ScottK drums his fingers and look around for barry ...
<leimy> but it looks like I might need to do that myself :-)
<NCommander> directhex: so upgraded mono-addins, still crashing and buring
<NCommander> f-spot works though ...
<hallyn> charlie-tca: i can roll with that.  will test tomorrow
<charlie-tca> I will be filing one if it fails again tomorrow
<hallyn> ok, thanks
<MadCow108> jdstrand: why does @{HOME}/.opera/** lrwk, allow opera to lock files in /usr/share? removing the k disallows it. there are no links to /usr/share in ~/.opera
<NCommander> directhex: I stil see no love. f-spot will crashes, and banshee still crashes. I find myself going out of my mind in debugging this
<cjwatson> charlie-tca: probably bug 729394
<ubottu> Launchpad bug 729394 in partman-auto (Ubuntu) "partman fails to load during install on LVM systems" [High,Fix released] https://launchpad.net/bugs/729394
<cjwatson> (it's not LVM-specific, despite the title)
<cjwatson> it won't necessarily be fixed tomorrow, since I'm probably not going to squeeze in another ubiquity upload before going to bed
<charlie-tca> Thanks
<MadCow108> ah great this is fixed, thanks
<MadCow108> was it related to bug 729556?
<ubottu> Launchpad bug 729556 in ubiquity (Ubuntu) "[Natty] Ubiquity takes forever to load partitioner (if exotic file systems are present?)" [Undecided,Confirmed] https://launchpad.net/bugs/729556
<LLStarks> ev, how do i trigger ubiquity-preserve-home?
<cjwatson> MadCow108: I imagine there were several duplicates
<directhex> NCommander: i have no idea what's happening with it
<cjwatson> I've duped it
<leimy> It's been a few hours so I thought I'd ask again.  Is there any kind of way to reproduce an ubuntu build process, or is it that one is just supposed to remaster new systems from selected packages.  I'm still not finding a lot of information on how Ubuntu derivative systems are actually built.
<ev> LLStarks: can you elaborate?  If you have an existing copy of Ubuntu, you'll have an option to reinstall or upgrade on the partitioning page on the natty desktop CD.
<leimy> Huh, and now the wiki page I was looking at for derivatives has been pulled?
<LLStarks> the feature is new to natty right, because i'm wondering whether to recommend a standard or separate-home installation for maverick/natty.
<LLStarks> to ev btw
<ev> LLStarks: it exists in versions prior to natty in the advanced partitioner
<LLStarks> i know,  but natty makes it idiot-proof, right?
<ev> LLStarks: if you go into the advanced partitioner and set your partitions back up as they were in the previous version of ubuntu, then uncheck the format button, it will clean out /, preserving /home, /usr/local, etc.
<LLStarks> haven't re/installed natty in a few weeks
<ev> LLStarks: correct
<ev> well, idiot-proof-ish
<ev> if you're recommending to people that they use this, please include a disclaimer that they should make a backup first
<ev> this will be the first release with this feature (I realize the / clearing stuff has been there for a while, but package reinstallation is new)
<ev> there will be bugs
<ogra_> fta, did you recently upload a chromium browser SRU that enables NEON in maverick ?
<LLStarks> gotcha, thanks ev
<ev> LLStarks: sure thing
 * ogra_ gets reports from people where it dies with SIGILL since a few days
<ogra_> and it seems to be the in-archive package they use
<SpamapS> The following NEW packages will be installed: ecryptfs-utils gettext-base keyutils libecryptfs0 libkeyutils1 libnspr4 libnss3 libnss3-1d libpopt0 lsof rsync
<SpamapS> Hmm.. more stuff in base files?
<fta> ogra, nope, the opposite. neon=0 thumb=1 everywhere, and armv7 on maverick+natty only
<ogra> did that recently change ?
<fta> ogra, why?
<ogra> because i have people in the ac100 community complaining to me that chromium doesnt start for them since a few days
<ogra> the browser dies with SIGILL on startup
<fta> since ch10, i enforced arm_neon=0 to fix a ftbfs
<ogra> so i was wondering if something recently changed in the package (ac100 has no NEON)
<fta> could be v7, which i flipped (the test was wrongly reversed before)
<ogra> v7 shuld be fine
<fta> ogra, http://paste.ubuntu.com/574525/  the various flags/tests in the chromium build system
<soren> SpamapS: adduser recommends ecryptfs-utils now.
<soren> SpamapS: Up from a suggests.
<zyga-ill> cjwatson, hi
<zyga-ill> cjwatson, I read your blog post, I'm sure you know that qemu -snashot -hda /dev/sda _does_ allow you to boot into the same operating system again, assuming you have enough storage for temporary files
<zyga-ill> -snapshot even
<ogra> fta, hmm, that looks to me like neon is on by default
<fta> ogra, i'm quite sure i disabled it: http://launchpadlibrarian.net/66221823/buildlog_ubuntu-maverick-armel.chromium-browser_10.0.648.133~r77742-0ubuntu0.10.10.1_BUILDING.txt.gz
<fta> wouldn't build otherwise
<fta> i can do a verbose build to confirm if you want
<ogra> no, looks fine
#ubuntu-devel 2011-03-15
<dylan-m> Hey, I'm getting an error when I try to build Unity: in PlaceFactoryFile, âDATADIR was not declared in this scope.â Have I upset it somehow?
<lamont> highvoltage: the livecd build process dist-upgrades the chroot.  if you changed BuildLiveCD, that requires intervention, but otherwise it's automatic
<highvoltage> lamont: great, thanks
<webmin> hi
<webmin> Hi i've setup a crontab to initiate a  every 10 minutes to copy /etc/mail from one server to another. My workplace are not to happy that im using root because of security reason. But when I try to use a standard user the process fails. Does anyone know why?
<webmin> if yes? is there a way of getting round this issue?
<StevenK> Yes, a standard user can't write to /etc/mail, but this is not a support channel. I suggest you follow up in #ubuntu.
<webmin> thanks steven. can I ask one last question.. is there a way of getting round this issue using sudo?
<StevenK> Haha
<pitti> Good morning
<didrocks> good morning
<hychen_> cjwatson, hi, can Grub2 change boot process bt partition active flag which mean mbr will chainload to a partition has a active flag?
<dholbach> good morning
<abhinav-> dholbach, good morning :)
<dholbach> hey abhinav-
<abhinav-> dholbach, GSOC application timeline has ended for mentoring organizations, when will the discussion about project ideas start ?
<dholbach> abhinav-, we don't even know that Ubuntu was accepted
<dholbach> we wait for Google's go-ahead
<dholbach> but if you have an idea you want to work on, you can start thinking some more about it already and flesh out a plan
<dholbach> :)
<abhinav-> ok. yes, that's right. :)
<evfool> any ureadahead developers here?
<zee313> Readon player is used for watching different channels on web. Do UBUNTU has such software?
<evfool> yes, you can try SopCast player for Ubuntu, or Miro for watching podcasts
<evfool> zee313 ^
<cjwatson> zyga: thanks, actually I didn't know that - qemu is full of stuff I haven't learned yet.  Updated my post, thanks :-)
<zyga> cjwatson, :-)
<zyga> cjwatson, I tried this on my laptop just now, unfortunately qemu and win7 don't like each other  so it crashes quickly
<zyga> cjwatson, but linux did boot okay
<cjwatson> hychen_: sounds like you might be looking for http://www.gnu.org/software/grub/manual/grub.html#parttool?
<zyga> cjwatson, you just have to be careful not to do C+s c (or was it C+s s) because that actually flushes the snapshot to backing device
<cjwatson> C-a s according to the man page
<hychen_> cjwatson, I want to know how does grub2 stage 1 find which partition it will boot? can it be set by I changed active flag of partition manually?
<cjwatson> firstly, terminology - GRUB 2 no longer calls it stage 1, see http://www.gnu.org/software/grub/manual/grub.html#Images
<cjwatson> secondly, GRUB (Legacy or 2) pays no attention whatsoever to the active flag
<cjwatson> thirdly, grub-install adjusts the image it installs to know which partition it's supposed to boot
<cjwatson> if the disk GRUB is being installed to is the same as where /boot/grub lives, then it just hardwires a partition number
<cjwatson> otherwise, it hardwires a UUID
<cjwatson> (I'm simplifying slightly, if you're using LVM or something for /boot/grub then it hardwires the GRUB device name for that)
<abhinav-> pitti, subprocess.check_output() would be ok to execute xprop and get its result back ?
<pitti> hey abhinav-
<pitti> abhinav-: sure
<pitti> abhinav-: btw, thanks for pointing this out, I didn't know about check_output yet
<pitti> that's new in 2.7
<abhinav-> pitti, :-)
<pitti> abhinav-: let me know if you need help with the test suite
<abhinav-> pitti, ok sure. I will implement this and get back to you about the test suite :-)
<pitti> abhinav-: test/run does the full thing, but if you are only hacking on apport/ui.py, then running "PYTHONPATH=. python apport/ui.py -v" is faster
<abhinav-> ok. I don't need to add anything to test suite ?
<pitti> abhinav-: you'll probably need to update test_parse_argv_apport_bug() for the new option
<pitti> abhinav-: btw, for even faster test suite runs you can also do
<pitti> PYTHONPATH=. python apport/ui.py _T.test_parse_argv_apport_bug _T.test_parse_argv_single_arg
<pitti> that'll just run these two, which take no time
<pitti> abhinav-: actually testing the functionality of the new --window argument is impractical in teh automatic tests, of course
<abhinav-> pitti, yes right :D
<pitti> abhinav-: it can only check that the argument is correctly recognized in the two different modes (apport-cli/gtk with full option suite, and the reduced ones in ubuntu-bug)
<abhinav-> yes
<pitti> thanks!
<abhinav-> btw pretty cool stuff in apport. Its a great source of learning :)
<Nafallo> cjwatson: it did on the next boot after I had installed more updates, interestingly. so I ended up with two rootflags= in my grub prompt, and apparently that made it dump me in initramfs as well. after that I had to change my fstab to use subvolid for home, cause for some reason subvol=@home stopped working :-)
<Nafallo> cjwatson: all in all, I don't think I can re-produce the "rootflags gone missing" issue any more :-(
<cjwatson> Nafallo: ok, if it happens again let me know
<cjwatson> sounds like something was odd at the btrfs level, TBH ...
<cjwatson> (if both grub-probe and mount were behaving oddly)
<Nafallo> yeah. both should have picked up the default subvol... I wonder if the thing just forgot what it was or something :-/
<apw> slangasek, wondering if we are expecting futher compiler updates from you, need to know for the kernel
<zyga> lifeless, ping
<lifeless> zyga: nearly 1am; suggest you mail me :)
<zyga> lifeless, sorry about that, I just wanted to ask you about cyclic dependency in python-testtools and python-fixtures but I think I can resolve that myself
<zyga> lifeless, where are you btw?
<beuno> zyga, he's in New Zealand
<zyga> oh
<cjwatson> Laney: is it just me, or is ghc6.triggers wrong?
<cjwatson> $ cat /var/lib/dpkg/info/ghc6.triggers
<cjwatson> interest /var/lib/ghc-6.12.1/package.conf.d
<cjwatson> $ dpkg -L ghc6 | grep var/lib | head -n3 | tail -n1
<cjwatson> /var/lib/ghc-6.12.3/package.conf.d
<Riddell> micahg: bug 699843 is waiting on you
<ubottu> Launchpad bug 699843 in pidgin-facebookchat (Ubuntu Lucid) "package pidgin-facebookchat (not installed) failed to install/upgrade: trying to overwrite '/usr/share/pixmaps/pidgin/protocols/16/facebook.png', which is also in package pidgin-data 1:2.7.9-1ubuntu0 pidgin1.10.04" [High,Incomplete] https://launchpad.net/bugs/699843
<om26er> kirkland, Hi! Can you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/totem/totem-fixes/+merge/53427
<Laney> cjwatson: oh, looks like it, doesn't it?
<Laney> I assumed that would be correctly dynamic, investigating...
<akheron> pitti: regarding bug 735341, how do I make it affect the shadow package again?
<ubottu> Launchpad bug 735341 in adduser (Ubuntu) "adduser creates expired system user" [Undecided,New] https://launchpad.net/bugs/735341
<pitti> akheron: open the triangle to the left of "adduser" in the yellow bar, and change it in teh input line
<cjwatson> Laney: I'm guessing we haven't noticed it on buildds because all the build-deps get installed in one pass
<akheron> pitti: ah, thanks
<akheron> there's no way to make it affect multiple ubuntu packages?
<pitti> akheron: there is; "also affects distribution..."
<akheron> ahh
<pitti> akheron: but before that is done the bug should actually be investigated
<Laney> cjwatson: it's fixed to be dynamic in darcs
<Laney> cherry-picking
<pitti> I'm afraid I'm out of my wisdom what's wrong there
<akheron> pitti: I'm out of my wisdom too
<akheron> I've seen this popping out every now and then since karmic for my installation
<cjwatson> Laney: thanks
<Laney> thanks for the spot
<akheron> pitti: would it be possible that the root user is expired?
<rsalveti> RAOF: was looking at the mesa package, and properly packaging the gles driver for powervr sgx 540 for omap 4, and was thinking if we should also provide/replace/conflict the gles -dev related packages, so other packages could basically replace them and depend on the virtual package
<pitti> akheron: I don't know; but root expiring really Should Not Happen(TM)
<rsalveti> RAOF: do you know how this is done for the normal desktop gl drivers?
<akheron> pitti: how do I check if it's expired?
<pitti> akheron: sudo chage -l root
<pitti> akheron: there you can also check sudo passwd -S postgres
<akheron> Account expires                                         : Jan 02, 1970
<akheron> hmm....
<pitti> that looks wrong
<pitti> it should be "account/password expires: never"
<akheron> I set it to this date with usermod -e 1 root and now chfn started working
<akheron> but how to set it to "never"?
<pitti> set it to -1, according to the manpage
<akheron> ah yes, but with chage
<akheron> usermod doesn't accept -1
<akheron> yay \o/
<akheron> now everything works again
<akheron> and hopefully my packages install cleanly in the future :)
<pitti> still werid..
<akheron> yep, how it got expired in the first place
<cjwatson> broder: did you ever get back to looking at rewriting hwmatch.lua in C?
<micahg> Riddell: ACK, will look again today
<roadmr> Hey all! I used to be able to get X memory usage info from /proc/dri/0/gem_objects, but as of kernel 2.6.38-6 (Natty recent dailies) it's gone - where can I get that information now?
<hallyn> kirkland: did you not 'pilot out' when you were done?
 * hallyn points at the topic
<kirkland> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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:
<kirkland> hallyn: evidently not :-)
<hallyn> kirkland: regarding bug 683957, did that that new default come in from upstream, or was it done on purpose?
<ubottu> Launchpad bug 683957 in qemu-kvm (Ubuntu) "guest ata controller becomes unresponsive" [Medium,Incomplete] https://launchpad.net/bugs/683957
<ChrisGagnon> roadmr: try your question in #ubuntu-kernel
<roadmr> thanks ChrisGagnon !! will do
<hallyn> kirkland: though comments #3 and #5 are not compatible
<hallyn> oh, i guess so
<dholbach> dendrobates, happy birthday! :)
<dendrobates> dholbach: thanks
<slangasek> apw: the compiler is going to be uploaded a second time this week for multiarch bootstrapping
<apw> slangasek, any idea when as we have to rebuild for compiler uploads generally
<psusi> hrm... is there a channel for webmasters?  help.ubuntu.com seems to have a bug: it is stripping the '/' separator from the page title so Foo/Subpage is shown as just "FooSubpage"
<micahg> psusi: #ubuntu-website
<psusi> ahh ;)
<slangasek> apw: sometime late today or tomorrow-ish, as the current upload needs to finish building on armel and then I need to upload eglibc, followed by a new gcc-4.5 build once eglibc is installed
<micahg> psusi: or you can file a bug against that project in LP
<apw> slangasek, so we are talking 2 days from now ish as armel takes 24 hours
<apw> slangasek, and is that it once the second one is done?
<barry> mvo: any thoughts on bug 735491 ?
<ubottu> Launchpad bug 735491 in apt (Ubuntu) "apt can't recover from file corruptions" [Undecided,New] https://launchpad.net/bugs/735491
<mvo> barry: yeah, I had a idea how to fix it
<barry> is it a viable work around to mv the files aside until apt-get update doesn't fail?
<slangasek> apw: that'll be it from my side
<mvo> barry: yeah, or remove them
<apw> slangasek, i guess i'll try and get an upload in the window while you are doing eglibc
<barry> mvo: cool, thanks.  a very interesting problem (thank you hotel :)
<mvo> heh :)
<slangasek> apw: would really be nice if someone would fix this misfeature that requires the exact same package version of the compiler :)
<barry> mvo: thanks!
<apw> slangasek, its not a miss feature, per see.  its all about those damn external modules which have to be built with a compiler which optimises in the same way to ensure that the calling convention matches
<apw> and given even and ubuntu1 -> ubuntu2 change can bring an entire new linaro compiler into the mix, we have little choice but to use the full version string
<apw> if we could get rid of those modules we could remove the interaction all together
<apw> indeed if we don't rebuild, then we simply can lose the binary drivers, which doesn't affect me as my machine is all intel
<dneary> mdz: ping?
<mdz> dneary, hi
<hallyn> charlie-tca: newly rsync'd desktop iso is still hanging for me in a vm.  Do you still have trouble?
<charlie-tca> yup, but cjwatson said yesterday the fix won't be out until tomorrow now
<charlie-tca> hallyn: yesterday's log
<charlie-tca> <cjwatson> it won't necessarily be fixed tomorrow, since I'm probably not going to squeeze in another ubiquity upload before going to bed
<hallyn> charlie-tca: i see, thanks.
<YokoZar> pitti: tyvm for wine1.3 :)
<abhinav-> pitti, I have made changes in ui.py, also updated test_parse_argv_apport_bug() . Now I was trying to build it using bzr bd but it gives error. Or should I use setup.py ?
<jdstrand> dholbach: hi! would it make sense for ubuntu-security-sponsors to be a member of ubuntu-reviewers?
<pitti> abhinav-: trunk doesn't have any packaging; just run it straight from the build tree
<pitti> abhinav-: PYTHONPATH=. gtk/apport-gtk --help
<dholbach> jdstrand, sure why not - nigelb: ^
<pitti> abhinav-: or if you just modified ui.py and nothing else, just PYTHONPATH=. ubuntu-bug ...
<cr3> slangasek: hi there, I've been working on bug #728611 with Carl Milette who commented on related bug #727925. since you seem to have experience with plymouth, might you have a minute to help us get somekind of interactive session when plymouth is running?
<ubottu> Launchpad bug 728611 in plymouth (Ubuntu Natty) "[natty] text does not display in plymouth (disk check, passphrase prompts)" [High,Confirmed] https://launchpad.net/bugs/728611
<ubottu> Launchpad bug 727925 in plymouth (Ubuntu Natty) "Kubuntu, when asking for encrypted fs password splash screen contains no instructions (dup-of: 728611)" [High,New] https://launchpad.net/bugs/727925
<maco> what's the script you can use to find out what someone's upload rights are or packageset info and suchlike?
<micahg> maco: edit-acl.py in ubuntu-archive-tools
<micahg> er, I think that's with an underscore actually
<maco> ...thats not a package
<Laney> lp:ubuntu-archive-tools
<Laney> (bzr)
<abhinav-> pitti, I am in my build tree and did PYTHONPATH=. gtk/apport-gtk --help but it is giving some errors: http://pastebin.com/LGNmTXpD
<geser> and the script is edit-acl.py
<abhinav-> pitti, I am totally new to PYTHONPATH, so might be doing something wrong :(
<Laney> no :(
<maco> got it
<Laney> ghc's unix package changes ABI
<Laney> but I need to upload a fix, but that would cause a transition
<Laney> toy -o                             |_| pram
<maco> Laney: you're a motu but not core-dev right?
<Laney> correct
<geser> ah right, pure MOTUs in DMB have some extra permissions due to how the teams are set up (e.g. are also members of ~ubuntu-desktop)
<maco> geser: thats what i was about to point out
<maco> http://paste.ubuntu.com/580659/
<maco> kubuntu-dev and ubuntu-server and such as well
<geser> maco: either take care that you don't use those rights by mistake or apply for core-dev :)
<maco> geser: hah im not applying for core-dev any time soon
<maco> kubuntu-dev i was gonna do at some point this year
 * micahg thought permission-wise DMB members are core-devs
<geser> micahg: DMB can add people to core-dev but hasn't upload right to main by definition
<micahg> geser: wasn't referring to actual rights (as in should do), but permissions (system allows)
<geser> micahg: depends on how a team got set up: DMB is the owner of ~ubuntu-core-dev (but not an admin), for other package set teams, the dmb is not owner but only admin (and therefore also member)
<micahg> geser: ah, so one of the owner/member bug was fixed?
<Laney> owner doesn't grant upload permissions
<Laney> only member does
<geser> I don't know about that bug
<geser> and admins are members, only the owner can not be a member but still add people to the team
<micahg> geser: nevermind, not important
<geser> and as I don't fully understand how all this admin/owner thing in LP works, I don't touch teams unless necessary
<slava__> I have integrated Wireless controller (connected with miniPCI) in my notebook. But the button, that should switch on it don't work. In windows I have to run special program to make this button work. I've written code that switch on wifi in ubuntu (that code uses /dev/ports), but I don't know how to hook this "wifi" key. What code in which package I may change to make it work properly?
<cjwatson> kees: where is your VCS branch for ubiquity 2.5.25?
<c2tarun> I created a natty chroot in kubuntu on different partition, can I use that chroot from ubuntu?
<kees> cjwatson: I put it in the bzr tree mentioned in the debian/control file
<kees> cjwatson: iirc, ~ubuntu-installer/ubiquity/trunk
<cjwatson> kees: it's not there
 * kees scratches his head
<cjwatson> if it had been I wouldn't be asking :-)
<kees> cjwatson: heh, right. let me check my tree, maybe it was a branch and not a checkout...
<slangasek> cr3: hi, what do you mean by 'interactive session'?
<cjwatson> kees: could you push it under ~kees somewhere and I'll deal with merging it?
<kees> cjwatson: sure, one sec
<slangasek> cr3: I don't have much in the way of time to spend on plymouth right now; that bug needs fixing to be sure, but I'm not sure I'm going to be able to help much
<kees> cjwatson: yup, looks like it was a branch that never pushed. I've pushed it to lp:~kees/ubiquity/ver-2.5.25 now
<cjwatson> kees: thanks, merged back now
<kees> cjwatson: cool; sorry about that glitch.
<jdstrand> hallyn: fyi, will upload your libvirt change today. the debdiff was malformed, but I saw what you wanted to do. added another patch and running through qrt now
<cjwatson> hallyn,charlie-tca: ubiquity 2.5.26 uploaded now
<charlie-tca> And that will fix the ubi-partman bug?
<charlie-tca> Thank You very much!
<cjwatson> Evan committed a fix for that which is included
<hallyn> jdstrand: i had a libvirt change?
<jdstrand> hallyn: yes, for the test suite
<jdstrand> Replace 9024-skip-broken-commandtest.patch with 9024-fix-broken-commandtest.patch from upstream
<jdstrand> hallyn: ^
<jdstrand> hallyn: you gave it to me a while ago, but I am only getting to it now
<hallyn> jdstrand: cool, thanks
<achiang> cjwatson: nice war story re: debugging wubi!
<cjwatson> achiang: it was an interesting ride
<achiang> cjwatson: the closest i've come to that was debugging kexec bugs; luckily where i was, we had a custom in-house full-platform simulator that allowed single-stepping a CPU and poking at memory
<achiang> cjwatson: i didn't have to deal with real mode though.... that sounds painful
<cjwatson> once you figure out what's going on, it's a matter of keeping a clear head, but it does take a while
<psusi> war story?
<achiang> psusi: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2011/03/15#2011-03-14-wubi-bug-693671
<cr3> slangasek: just wondering if I can drop to a shell from the cryptsetup script, adding /bin/sh before plymouth ask-for-password doesn't seem to work because, when I escape to the console, I see busybox but then it kicks me back to the graphical interface
<cr3> slangasek: also, if you might happen to know on top of your head how to get ply_trace to show stuff on the console, maybe I could fallback to printf debugging
<cr3> slangasek: I'll try not to take much of your time, mostly trying to refer to your experience without having you actually do anything :)
<cjwatson> cr3: it's easier to use plymouth:debug=file:/dev/.initramfs/plymouth.debug (requires natty)
<cjwatson> the console tends to scroll off too quickly
<cr3> cjwatson: I've noticed that plymouth: option somewhere in the source, but I didn't see where to specify that
 * cr3 is delving into plymouth for the first time, this is all new
<slangasek> cr3: specified on the kernel commandline
<GunnarHj> tedg: Hi Ted, did you see my new proposed solution to bug 636693? I believe it satisfies all the aspects we have discussed.
<ubottu> Launchpad bug 636693 in indicator-session (Ubuntu) "Premature lock when launching guest session" [Low,In progress] https://launchpad.net/bugs/636693
<GunnarHj> tedg: Btw, is that dbus option by-passing /usr/share/gdm/guest-session/guest-session-launch?
<mrc3_> hello! while trying to update gst-plugins-base and -good,  i'm getting a file collision that makes no sense to me:
<mrc3_> dpkg: error processing gstreamer0.10-plugins-good_0.10.28-0ubuntu1+ti0.24.12_armel.deb (--install): trying to overwrite '/usr/share/locale/ro/LC_MESSAGES/.mo', which is also in package libgstreamer-plugins-base0.10-0 0.10.32-1ubuntu3+ti0.24.12
<mrc3_> what did i miss that is making the mo file (from the po/ directory) install without a package name?
<bdrung> after todays natty update, gdm doesn't come up again. anyone else experience this issue?
<hallyn> bdrung: hm, that's with new upstart I presume.  (but no, I don't see that - though my system is messed up anyway, but at least gdm comes up)
<bdrung> hallyn: yes, that was probably upstart.
<hallyn> Quite sure I've got that update, but I"ll go try another update to make sure
<bdrung> downgrading gdm didn't help
<bdrung> s/gdm/upstart
<broder> bdrung: it was a change in gdm's upstart config
<bdrung> broder: i downgraded gdm and now gdm comes up correctly.
<bdrung> broder: should i file a bug report or is there already one open?
<broder> bdrung: don't know, but the relevant change is connected to bug #436936
<ubottu> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936
<hallyn> cjwatson: just to make sure, you've not beein looking at bug 717445 at all yet, right?
<ubottu> Launchpad bug 717445 in grub2 (Ubuntu Karmic) "grub2 in lucid doesn't work in qemu with '-vga std'" [Medium,Confirmed] https://launchpad.net/bugs/717445
<hallyn> (I intend to start looking in more detail at the guilty patch)
<bdrung> broder: probably. one change in the 2.32.0-0ubuntu10 upload is the reason.
<cjwatson> hallyn: not really no, sorry
<Daviey> lamont, Are you around?  If so, do you want to upload your bind9 package to lucid-proposed?  Or would you prefer i did it?
 * SpamapS just realized his compiz crashed 2 hours ago.. who needs a window manager when you've got 37 total inches of screen real estate? ;)
#ubuntu-devel 2011-03-16
<lamont> Daviey: go ahead, I'm afk for the evening as of about 30 sec ago
<Daviey> lamont, Okay, your PPA backport == the sid package?
 * Daviey diffs
<ScottK> You have to ask the questions before they are AFK.
<ScottK> ;-)
<lamont> Daviey: ISTR that there might be a dpkg change that required a tweak to the package for lucid
<lamont> Daviey: so I'd say grab the ppa.  not just because that's what I tested
<lamont> worst case, I should be able to do it tomorrow
<c2tarun> why I am getting this error curl: (6) Couldn't resolve host 'people.canonical.com'  on running rmadison kdeedu in natty chroot
<ScottK> Probably because you use dhcp and you got a new IP address since you created the chroot.
<psusi> ok... I have proposed tasks for lucid and maverick for bug #662194, backported the one line patch from natty to maverick and lucid, pushed the bzr branches to lp, proposed they be merged, linked them to the bug report, subscribed unbuntu-sru and ubuntu-sponsors... did I miss anything?
<ubottu> Launchpad bug 662194 in Nautilus "Nautilus: 'Remember this application for ..." option should be made inactive by default" [Medium,New] https://launchpad.net/bugs/662194
<nigelb> jdstrand: yes, go ahead :)
<nigelb> jdstrand: I don't have powers to do it, but probably dholbach has :)
<pitti> Good morning
<c2tarun> pitti, good morning :)
<c2tarun> pitti, hey can you please help me with splitting packages?
<pitti> what do you want to do?
<c2tarun> pitti, I was working on bug 683439
<ubottu> Launchpad bug 683439 in kdeedu (Ubuntu) "split kalgebra mobile" [Undecided,In progress] https://launchpad.net/bugs/683439
<c2tarun> pitti, its my first time and I dont know how to split, I did some steps but not sure I am right.
<c2tarun> pitti, I moved the mobile folder from kalgebra outside it and renamed it as kalgebra-mobile. In file kalgebra.install there is one line related to kalgebramobile so I copied that line to another file name kalgebra-mobile.install, I added lines for kalgebra-mobile in debian/control but dont know how to fill some fields. :/
<pitti> c2tarun: roughly, you have to add the new package to debian/control, then update all affected debian/pacakgename.install to install the files to the new package instead, and finally the new package needs a Breaks:/Replaces: <package which previously shipped the files> (<< your_new_version)
<c2tarun> pitti, is there any manual available for splitting packages?
<pitti> there isn't
<pitti> it's not really different to adding a new binary package, or doing packaging in general
<pitti> you need to know what debian/control does, and how dh_install works mostly
<pitti> the only extra thing is teh Breaks:/Replaces:
<c2tarun> pitti, ok, I'll look into dh_install first.
<c2tarun> pitti, does dh_install comes under automake tools?
<pitti> c2tarun: yes, well after; but the current package should already have it
<pitti> c2tarun: there's (usually) no need to modify debian/rules for this
<c2tarun> pitti, you said to add new pacakge to debian/contro, and then update all affected debian/pacakgename.install, I actually didn't get the second part.
<pitti> c2tarun: dh_install uses debian/packagename.install to put the installed project files into the various binary packages
<c2tarun> pitti, this question might sound silly, but how am I going to find affected packagename.install, I mean do I have to look into each *.install file and see if it is using kalgebramobile?
<pitti> c2tarun: well, that's the main point of the exercise -- determining the files you want to ship in the new package, i. e. teh parts you want to split out :)
<c2tarun> pitti, well thats kind of tricky, dont you think one have proper knowledge of the source code in order to determine the files.
<pitti> c2tarun: not really about the source, but about the installed files
<pitti> and yes, it is not a simple task for a large package like kdeedu
 * c2tarun i thought its not simple task for any package ;(
<c2tarun> pitti, do I have to move mobile folder out of kalgebra folder? I think it contains the source code.
<c2tarun> pitti, if you have some time please get the source code of kdeedu and please instruct me, this will help me in learning something important :/
<StevenK> c2tarun: I'd suggest you'd be better off asking Riddell what he had in mind to split out. The source code doesn't help in this case at all.
<c2tarun> StevenK, ok then I'll ping him on #kubuntu-devel thanks :)
<jono> hey folks
<jono> I just had a weird experience, I am running current Natty and I rebooted and it looks like X started but nothing loaded
<jono> I rebooted a few times and this happened, and I just rebooted now and X started fine
<jono> seems like some kind of odd race condition
<jono> is this a known bug?
<didrocks> good morning
<jono> hey didrocks
<didrocks> hey jono, how are you?
<jono> didrocks, good thanks :-)
<Amaranth> jono: Do you get the default X crosshatch background and "X" mouse cursor then?
<jono> Amaranth, no, it just looked like the display was turned on (you know how it goes a slightly brighter shade of black before the background is drawn)
<Amaranth> Hrm, perhaps plymouth failed to hand off to X
<jono> Amaranth, the fact that it just booted fine could suggest something racey is going on
<jono> anything I can dig out in a log file to help?
<Amaranth> jono: I don't exactly know how that part works so I wouldn't know what to look for
<Amaranth> Perhaps RAOF would know
<broder> jono: i saw some discussion from bdrung earlier that there was an issue with gdm
<broder> possibly connected to some upstart config changes
<jono> broder, ahhh
<broder> i had to run before i saw any conclusion
<Amaranth> Well, it seems his problem was caused by a fix for https://launchpad.net/bugs/436936
<ubottu> Ubuntu bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged]
<broder> Amaranth: rough theory: the gdm upstart job is triggering, which also triggers the plymouth-quit job, but something is keeping gdm from actually starting
<broder> haven't really worked out the finer points of that, but feel free to run with it
<RAOF> jono: âslightly brighter shade of blackâ?  You don't get the plymouth splash screen fading seamlessly into gdm (when gdm works âº)?
<jono> RAOF, I see no Ubuntu image when my laptop boots
<jono> and then no gdm was loaded
<jono> but also no colored background
<broder> jono: bug #735805
<ubottu> Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [Undecided,Confirmed] https://launchpad.net/bugs/735805
<broder> jono: though i'm not sure that's the same as yours since you said it worked sometimes
<jono> yeah it worked the last time I booted, and I need to work tomorrow so I am not rebooting tonight :-)
<broder> haha
<broder> RAOF: ooc, what component handles that theoretical seamless fade anyway? is it supposed to be g-s-d or something?
<RAOF> broder: Nah, that's X.
<broder> oh really? fancy
<jono> sorry folks, I have to head to bed
<RAOF> Plymouth leaves its image in the framebuffer, the X drivers copy said images into a pixmap and use it as the root window.
<jono> anything I can provide before I go? log files etc?
<jono> RAOF, ^
<RAOF>  /var/log/Xorg.0.log is always a good ideoa, as, in this case, might be /var/log/gdm/*
<RAOF> Although if upstart isn't even trying to start gdm, those would be useless, and I'm not sure what logs *would* be usef
<RAOF> ul.
<jono> right
<jono> I wasn't sure if I should see some errors somewhere
<broder> RAOF: my suspicion is that the gdm upstart job is running, but the script is short-circuiting
<broder> that's the only explanation i have for why plymouth would quit without gdm actually starting, since the plymouth-quit job gates on the gdm job
<RAOF> And we know plymouth has quit?
<RAOF> I'm not sure what a short-circuted upstart script would look like, either :)
<jono> ok, I best head to bed
<jono> let me know if there is anything else I can help with
<jono> thanks RAOF, broder, Amaranth
<dholbach> good morning
<exobuzz> https://launchpad.net/builders/ 10 hour delay for i386 :/
<exobuzz> has everyone decided to use their ppa all at once, or are there less builders or something for some reason ?
<tjaalton> is mounting iso's with exec somehow disabled, since even running 'mount -o loop,exec foo.iso bar' doesn't work
<tjaalton> well, it's still mounted noexec
<Daviey> exobuzz, Now 11 hours :)
<exobuzz> yeh.. argh
<Daviey> exobuzz, it's known, seems they are being used for other purposes at the moment.
<exobuzz> Daviey, thanks for the info.
<Riddell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: Riddell
<vila> can someone reminds me why I don't see a 'Nominate for release' button for https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075 ?
<ubottu> Ubuntu bug 707075 in Bazaar 2.4 "[sru] lp-propose fails with a 404 error" [High,Fix released]
<vila> I want to start the SRU process for bzr but I'm blocked on this step
<vila> ISTR someone did this for me (just creating the bugtask, I followed the process myself from there) last time but I don't remember *why* I can't do it myself
<nigelb> vila: I see it just fine.
<nigelb> vila: I tried logging out and looking too
<vila> nigelb: wow, it works now 8-) Thanks
<vila> hmm
<nigelb> vila: you probably looked for nominate for release but its nominate for series
<vila> almost
<vila> I've got an oops saying: NominationError: Only bug supervisors or owners can nominate bugs.
<Riddell> slomo: where can i find gstreamer0.10-fluendo-mpegdemux to confirm bug 731711 ?
<ubottu> Launchpad bug 731711 in gst-plugins-bad0.10 (Ubuntu) "mkv files with dvdsub broken after installing Fluendo Complete Playback Pack" [Undecided,Fix released] https://launchpad.net/bugs/731711
<nigelb> vila: arg, that isn't friendly, but you can go ahead with the process and one of us can nominate for you :)
<vila> nigelb: ok, will do that then
<slomo> Riddell: i don't know, ask your colleagues :) it's part of the fluendo codec pack, the free debian/ubuntu package was removed after lucid/before squeeze
<Riddell> slomo: thought so, but comment #1 suggests you are involved, which doesn't make sense, never mind
<slomo> Riddell: i did the original package which was in debian/ubuntu, maybe they reused it for the codec pack... oh and that bug was about an unnecessary conflict in gst-plugins-bad
<Riddell> yeah, I want to check the gstreamer0.10-fluendo-mpegdemux package to confirm it is unnecessary
<slomo> Riddell: the files are named different and the symbol conflict is gone since many gst-plugins-bad releases
<cdbs> Final Exams over, marking the end of my 4 month long study leave. This was my last leave, and so full steam ahead!
<cdbs> dholbach: pong
<dholbach> cdbs, errr... pong? hello! :)
<cdbs> dholbach: I am ponging to your email
<dholbach> :)
<dholbach> ok
<soren> Where can I find info on the /CurrentlyBuilding file that we see on the buildd's. I can't seem to spot any mention of it in the sbuild package.
<soren> wgrant: I'm sure you know this.
<wgrant> soren: We don't use system sbuild.
<wgrant> soren: It's hacked into launchpad's sbuild.. let me find a link.
<soren> wgrant: W00t.
<wgrant> soren: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/canonical/buildd/sbuild#L1181
<seb128> jhunt_, hi
<jhunt_> seb128: hi
<soren> wgrant: Excellent, thanks!
<seb128> jhunt_, the gdm patch you worked on seems to break some users
<seb128> jhunt_, bug #735805
<ubottu> Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [Undecided,Incomplete] https://launchpad.net/bugs/735805
<seb128> pitti, ^ one user confirmed downgrading the upstart job fixes it
<pitti> seb128: ah, would you mind assigning to jhunt_ then?
<jhunt_> seb128, pitti: hmm, I can only conclude that the bracketing of the start on is the problem, but can't recreate it atm. I'd really appreciate it if someone could either wikify or send me details of how to set up the multiple branches(lp:ubuntu/gdm + lp:~ubuntu-desktop/gdm/ubuntu?) required to rebuild gdm fully.
<pitti> jhunt_: you only need the latter branch; lp:ubunt/gdm is not the branch you are looking for <jedi wave>
<pitti> jhunt_: but you don't even need to build the branch, I guess you can just change /etc/init/gdm.conf for experiments
<pitti> jhunt_: https://wiki.ubuntu.com/DesktopTeam/Bzr has the documentation
<jhunt_> pitti: that's what I did for the change on bug 436936. However, the desktop branch only includes the debian/ directory, so how do I build?
<ubottu> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936
<seb128> jhunt_, you are not on natty?
<pitti> jhunt_: in short, it's "debcheckout gdm; cd gdm; bzr bd -- -b" (for binary paackage)
<seb128> jhunt_, why do you need to build from the vcs?
<cjwatson> 'bzr bd' knows how to glue the debian/ directory in VCS together with the .orig.tar.gz for everything else
<jhunt_> seb128, cjwatson: thx!
<Laney> has something changed with libffi on i386? http://launchpadlibrarian.net/66490258/buildlog_ubuntu-natty-i386.ghc6_6.12.3-1ubuntu6_FAILEDTOBUILD.txt.gz
<Laney> builds on amd64
<seb128> jhunt_, btw why do you need to rebuild gdm to hack the upstart job?
<seb128> jhunt_, if you don't have the issue maybe just ask for details on the bug, the users who have it will reply
<jhunt_> seb128: I don't for this bug, but wanted to know how to do it anyway for other purposes.
<seb128> jhunt_, ok
<seb128> jhunt_, bdrung gets the issue if you need details
<seb128> jhunt_, he confirmed that reverting your job tweak fixes it
<bdrung> jhunt_: let me know if i need more information or when i should test something.
<jibel> cjwatson, ev : ubiquity is broken this morning. bug 736060
<ubottu> Launchpad bug 736060 in ubiquity (Ubuntu) "ubiquity crashed with DebconfError in command(): (10, "debian-installer/fallbacklocale doesn't exist")" [Undecided,New] https://launchpad.net/bugs/736060
<cjwatson> jibel: drat, thanks
<cjwatson> well, I know why that would be, given the massive localechooser merge
<cjwatson> I did test it, believe it or not :-/
<abhinav-> ttx: hello :-)
<ttx> abhinav-: will look into the branch in a few. next on my TODO.
<abhinav-> ttx, no problem :-)  I was wanting to ask what to do on the first screen of submittodebian ? it opens the diff in a text editor but no changes shown in debian/changelog
<ttx> abhinav-: I confess I usually submit manually. But someone else here should ba able to help you.
<abhinav-> ttx: :-) Daviey submitted it for me last time
<bdrung> jhunt_: requested information attached to the gdm bug.
<Daviey> abhinav-, In the text editor, trim the patch down to stuff you just care about (maintaining the +++ and ---) lines.. other entries, clear out
<abhinav-> Daviey, ok and no need to create a new changelog entry (I already created it for submitting to launchpad) ?
<Daviey> abhinav-, Yeah, the Debian Maintainer will craft their own changelog entry.  But it's a good idea to have near the same contents in the actual bug report... which IIRC submittodebian helps with
<abhinav-> Daviey, Thanks. I will play with it to learn more. :-)
<Daviey> abhinav-, good stuff!
<abhinav-> pitti, Hi, I am running Maverick and it has Python Distutils 2.22, perhaps this is the reason I am not able to run :(
<cjwatson> jhunt_: I have a set -x log from gdm.conf.  would that help?
<cjwatson> jhunt_: http://paste.ubuntu.com/581088/ - looks like the previous runlevel is unknown so it decides it's now in single-user mode and gives up
<ttx> abhinav-: i'll push it to debian-java SVN directly. No real need for a bug.
<abhinav-> ttx: thanks :-)
<cjwatson> jhunt_: I expect this happens if the other start conditions for gdm are satisfied before we enter runlevel 2
<RoAkSoAx> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: RoAkSoAx, Riddell
<ttx> abhinav-: done
<abhinav-> ttx: Thank you :-)
<Riddell> slangasek: koffice compile has broken because libc moved out of /lib, how is that expected to be fixed?
<slangasek> Riddell: koffice is expected to use the linker path instead of looking for a hard-coded path to libc. Is there a build failure I can look at in LP for this?
<Riddell> slangasek: https://launchpad.net/ubuntu/+source/koffice/1:2.3.3-0ubuntu1/+buildjob/2324333/+files/buildlog_ubuntu-natty-i386.koffice_1%3A2.3.3-0ubuntu1_FAILEDTOBUILD.txt.gz
<Riddell> it's looking for iconv which can be a standalone library or part of libc
<slangasek> Riddell: right - but it shouldn't need to hardcode a path to libc to do this, it should simply link against '-lc'.  I can take a look in a bit
<Riddell> slangasek: if I change the cmake file to just use libc instead of searching for any of the various libraries it works ok, but I'm not sure that's the best long term solution
<slangasek> Riddell: well, indeed, the best long-term solution is to not bypass the compiler's linker path when searching for libraries
<slangasek> Riddell: looks to me like this may need to be fixed in cmake; ./cmake/modules/FindIconv.cmake itself looks sensible
<mvo> jibel: thanks a bunch for your script in 541595
<slangasek> Riddell: it makes me unhappy to see what cmake's FIND_LIBRARY() is doing internally.  autoconf got this right 20 years ago, I don't know why cmake had to go and reinvent poorly the search for libraries at buildtime
<slangasek> Riddell: can CMAKE_LIBRARY_PATH be set in the environment?  If so, I think that's the best way to handle this
<jibel> mvo, you're welcome.
<jhunt_> cjwatson: thx. I've updated bug 735805 with a possible fix
<ubottu> Launchpad bug 735805 in gdm (Ubuntu) "GDM fails to start" [High,Confirmed] https://launchpad.net/bugs/735805
<Riddell> slangasek: I don't see why it couldn't
<slangasek> Riddell: well, I can't tell from the code I'm looking at whether setting that in the environment does any good - I guess looking at the documentation would be better :)
<slangasek> actually, this ought to be fixed in cmake because a lot more libraries are going to be moving out of /lib, /usr/lib soon
<Riddell> slangasek: what is the way to find the linker path?
<jibel> mvo, btw this bug bit me yesterday during an upgrade from maverick to natty following a failure of libpango (bug 703230)
<ubottu> Launchpad bug 703230 in pango1.0 (Ubuntu Natty) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4" [High,Triaged] https://launchpad.net/bugs/703230
<jibel> mvo, so maybe it is reproducible
<slangasek> Riddell: for the stuff that's being done in cmake, it seems we want the runtime linker path, so the only reliable way for cmake to get that is by recursing /etc/ld.so.conf* (which it shouldn't do)
<Riddell> slangasek: then how does autoconf do it?
<slangasek> Riddell: for an env workaround, CMAKE_LIBRARY_PATH=/usr/local/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH):/lib/$(DEB_HOST_MULTIARCH) would be correct
<slangasek> Riddell: it trusts the compiler like it ought to!
<psusi> cjwatson: finally read that war story.. I had a very similar experience debugging the ReactOS boot loader several years ago... was using bochs instead of qemu I think though, and getting gdb to connect to it was a lifesaver
<slangasek> there's no good reason for cmake to be rooting around in runtime library directories and looking at sonames and all this other stuff
<mvo> jibel: thanks, I'm having a look now. I'm going through the bugreport currently trying to gather clues
<jibel> mvo, the logs from the failed upgrade are there https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/735441/+attachment/1909981/+files/dist-upgrade.tgz
<ubottu> Ubuntu bug 735441 in pango1.0 (Ubuntu) "package libpango1.0-0 1.28.3-4ubuntu1 failed to install/upgrade: pre-installation script returned error exit status 1 - rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory (dup-of: 703230)" [Undecided,New]
<ubottu> Ubuntu bug 703230 in pango1.0 (Ubuntu Natty) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4" [High,Triaged]
<slangasek> Riddell: for fixing this centrally in cmake, here's a command that would let you grab /gcc's/ search path at runtime and iterate through: for dir in $(gcc -print-search-dirs | cut -f2- -d'=' |sed -e's/:/\n/g'); do readlink -f $dir; done | uniq
<slangasek> so cmake could do the equivalent to that
<slangasek> or else since cmake is arch-dependent, it could just have the multiarch paths hard-coded
 * amitk swears at ubuntu-sso-login
<Riddell> slangasek: is multiarch in or about to be in debian too?
<pitti> abhinav-: hey! wanted to reply to your over-night ping
<slangasek> Riddell: about to be, yes
<pitti> abhinav-: yes, you need to run current trunk on natty, maverick doesn't yet work with the pygi stuff
<pitti> abhinav-: alternatively, run PYTHONPATH=. ubuntu-bug
<Riddell> slangasek: ok so I should discuss with KDE's cmake guru and debian about what to do
<pitti> abhinav-: that will use the GUI from maverick, but the ui.py from trunk; that should work, and won't need pygi
<pitti> abhinav-: it's not related to python-distutils
<slangasek> Riddell: ok - if they can get the multiarch dirs prepended to cmake's built in search path, that would be great - /usr/local/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH):/lib/$(DEB_HOST_MULTIARCH) should do the job (note, we need to be able to pass this in from the environment because $DEB_HOST_MULTIARCH != $DEB_HOST_GNU_TYPE on i386)
<slangasek> Riddell: do you have other, pending KDE uploads right now that don't depend on koffice?  I have more libraries to "break" wrt cmake this week, but I don't want to set you back unnecessarily - I can schedule those uploads around any builds you have queued
<Riddell> slangasek: you may be overestimating how well I plan KDE uploads :)
<Riddell> nothing planned but I expect uploads will happen
<slangasek> Riddell: well, it would be impolite of me to not at least /offer/ to coordinate ;)
<slangasek> but if it's undefined what's going to get uploaded when, I think I need to continue with my bootstrapping and we just need to get a cmake fix soonest
<Riddell> slangasek: but this doesn't break everything that uses cmake does it?  only packages which directly look for libc or other multiarch libraries
<slangasek> Riddell: yes, but bear in mind that by the end of the cycle a *lot* of libraries are going to be multiarch libraries
<pitti> dpm: hm, shouldn't I have a new base export at https://translations.launchpad.net/ubuntu/maverick/+language-packs by now? usually they finish in the morning
<slangasek> Riddell: I mean, qt4-x11 is in ia32-libs, so it's on the list somewhere :)
<Riddell> wibble
<dpm> pitti, did you request the export before Tuesday 14:00? Otherwise the export will be scheduled for next week - https://dev.launchpad.net/Translations/LanguagePackSchedule
<pitti> dpm: yes, on Monday I think
<dpm> pitti, yeah, I can confirm, on Monday I sent the announcement that we'd be delaying testing the langpacks
<amitk> anybody know what this ubuntu-sso-login is that keeps crashing but that I can't file a bug against through apport?
<dpm> pitti, I'm asking about it on #launchpad ^
<pitti> dpm: thanks
<seb128> jibel, mvo: if you want to fix the pango bug please just do it and forward the patch to debian, it should be trivial, just try to rmdir in the preinst or ignore errors, not sure why there is a directory there for some users
<jibel> seb128, we were talking about bug 541595 which is very common in dpkg and I said I got it and it was triggered by the pango bug.
<ubottu> Launchpad bug 541595 in dpkg (Ubuntu) "[Master] package failed to install/upgrade: package is already installed and configured" [Medium,New] https://launchpad.net/bugs/541595
<seb128> jibel: ok
<lamont> Daviey: what version string do you want for the bind9 upload?
<Daviey> lamont, I think it might need to be 1:9.7.0.dfsg.P1-1really9.7.3 ... which makes me sad.
<Daviey> lamont, what do you think?
<directhex> ._.
<directhex> what on earth is prompting that?
<Daviey> directhex, new upstream snapshot for lucid SRU...
<Daviey> should really be > 1:9.7.0.dfsg.P1-1 && < 1:9.7.1.dfsg.P2-2
<Daviey> Saying that.... If it's SRU'd to Lucid, Maverick and already in Natty - it could just be the same version string as Natty.
<Daviey> 1:9.7.3.dfsg-1
<Daviey> (I wasn't going to push for an SRU to Maverick, but we should do really)
<Daviey> Anyone else have any thoughts on that?
<lamont> I'm +1 on maverick as well
<stgraber> so you'll need to append the ubuntu version number / release name so you have different version strings for lucid, maverick and natty
<lamont> OTOH, thinking something like 1:9.7.3.dfsg-1~10.{04,10}
<stgraber> 1:9.7.3.dfsg-1~lucid1 or 1:9.7.3.dfsg-1~10.04 (as lamont just suggested)
<Daviey> sounds good to me
<lamont> Daviey: and uploaded to {lucid,maverick}-proposed?
<Daviey> lamont, Yeah.. that sounds super.  Do you have that covered?
<lamont> yeah
<Daviey> lamont, Make sure you grab me at UDS to redeem a beer token.
<lamont> Daviey: and thanks for doing the lifting around process/etc
 * Daviey gets back to shovelling e-paper.
<abhinav-> pitti: it also doesn't work. it says no module named packaging_impl , http://pastebin.com/Ssx9Cky8 .
<abhinav-> pitti,  I will try to ask someone who is running natty to try my branch or I will download the latest build of natty myself overnight  :)
<pitti> abhinav-: ah, sorry
<pitti> abhinav-: you need to do "./setup xx" once
<pitti> abhinav-: (teh xx doesnt' really matter, just needs to run once)
<abhinav-> oh ok :)
<pitti> abhinav-: that will install the apt backend
<abhinav-> pitti, it asks for python distutils 2.24 while maverick repository has 2.22 :( .
<abhinav-> I have downloaded the latest source code revision of distutils. I will try to install that
<pitti> abhinav-: cp backends/packaging-apt-dpkg.py apport/packaging_impl.py
<pitti> abhinav-: then you can avoid running setup.py
<lamont> Daviey: bind9  uploaded to {lucid,maverick}-proposed.  happy paperworking
<abhinav-> pitti, running now. Thanks for helping :)
<bdrung> jhunt_: it doesn't work :(
<jhunt_> bdrung: ack. I'll look in a sec...
<pitti> abhinav-: cool
<seb128> jhunt_, should I revert your gdm changes so people get back a starting system or do you think you will get a fix today?
<jhunt_> seb128: maybe a revert would be sensible. My concern is that I am not able to reproduce the issue which makes testing somewhat tricky :(
<seb128> jhunt_, seems to be a race or something, didn't cjwatson's debug infos helped to understand what's going on?
<cjwatson> I've applied jhunt's change for the next time I reboot, but I've been busy today
<cjwatson> it seemed sensible to me
<cjwatson> (the one in the bug report)
<seb128> cjwatson, bdrung said he doesn't work as it should it seems
<jhunt_> seb128: I based my proposed change on it. I suspect the bug was actually in the original gdm.conf but I'm exposing it.
<cjwatson> I still have my debugging code in place - just below 'script':
<cjwatson>     exec 2>>/dev/.initramfs/gdm.log
<cjwatson>     set -x
<jhunt_> seb128: well, we've got gdm working, but gdm starting from recovery mode (which was the whole point of my change) still isn't seemingly working.
<seb128> jhunt_, if gdm works in normal start I'm happy, should I just upload your suggested fix to natty?
<seb128> jhunt_, so you can debug from there the remaining issue and people get a working gdm?
<elmo> jhunt_: FWIW your 'possible fix' gdm.conf (complete with tmp file vulnerability) fixed gdm for me
<jhunt_> seb128: I'd prefer you asked bdrung that one :)
<tseliot> cjwatson: do you know what condition I should use in an upstart job to make sure that the backlight device is available in sys before I execute the script?
<seb128> jhunt_, why?
<jhunt_> elmo: yeah - debug, that's not for an actual system clearly :)
<seb128> jhunt_, ok, I'm reverting the recent change for now
<seb128> that seems like it's not going to sort today and we are screwing users
<jhunt_> tseliot: you should be able to use the upstart-udev-bridge-generated event
<seb128> we will put if back once it's sorted
<tseliot> jhunt_: so would udev have to emit an event when the device is created?
<jhunt_> seb128: that sounds like a good plan to me. It does raise the issue of how we test such changes as I tested on 3 releases in various scenarios and did not hit this issue.
<seb128> jhunt_, it seems likely to be a race
<jhunt_> seb128: agreed.
<seb128> jhunt_, but well unstable distro are for that in some way
<kees> elmo: tmp file vulnerabilities require an operating system that follows symlinks in world-writable directories. ;)
<jdstrand> hehe
 * jdstrand would still encourage people to *not* include them in their code though ;)
<jhunt_> tseliot: See the manpage for upstart-udev-bridge in natty. But from what I can see, you might be able to "start on backlight-device-added"
<tseliot> jhunt_: oh, I'm dealing with Natty. Too bad
<jhunt_> tseliot: ?
<tseliot> jhunt_: yes, I guess I'm better off with a udev rule to change the backlight permissions on boot in Lucid
<elmo> jhunt_: fwiw, it doesn't seem like a race to me, I rebooted 3-4 times trying to figure out what was broken, so if you want to test fixed scripts, I'm fairly confident I can reproduce the brokeness
<ogra> cjwatson, oops, thanks for closing the bug
<tseliot> cjwatson: never mind
<pitti> abhinav-: so with regards to the mail you sent me, is that start problem solved now?
<abhinav-> pitti, yes it is running now. but the code I wrote isn't working :-|
<bdrung> jhunt_: feel free to ping me to get gdm upstart changes tested
<jhunt_> bdrung, elmo: thx!
<fta> pitti, hi, i have a problem with apport on lucid. on one of my servers, milter-greylist is crashing randomly, i have apport enabled, but i never get anything in /var/crash, any idea?
<pitti> fta: do you have something in /var/log/apport.log about it?
<fta> pitti, nope
<pitti> fta: /proc/sys/kernel/core_pattern points to |/usr/share/apport/apport?
<pitti> fta: can you run that in the foreground, does it crash there as well?
<fta> # cat /proc/sys/kernel/core_pattern
<fta> |/usr/share/apport/apport %p %s %c
<pitti> that's right
<fta> i see the crashes in dmesg
<pitti> fta: usually it means that the program intercepts SIGSEGV (or whatever it is crashing with) itself
<fta> [463906.749929] milter-greylist[12390]: segfault at a0 ip 00c211e0 sp b5f81320 error 4 in libmilter.so.1.0.1[c17000+c000]
<pitti> hm, it wouldn't leave an imprint in dmesg then, thuogh
<fta> not sure if greylist is doing that
<pitti> it at least prints called for pid %s, signal %s very early on (into the log file)
<pitti> fta: if you do: sh -c 'kill -SEGV $$'
<pitti> fta: do you get a crash report?
<pitti> (for dash)
<fta> yes, -rw------- 1 root root 17457 2011-03-16 18:31 _bin_dash.0.crash
<pitti> ok, so that part works
<pitti> fta: no "cannot create lock file" in the log either?
<pitti> fta: so grep 12390 /var/log/apport.log returns nothing?
<fta> pitti, nope, nada. /var/log/apport.log just contains 3 lines for the dash crash you asked me to try
<fta> nada either in the older apport.log files
<pitti> fta: can you run the program from a terminal (if it isn't running right now), and send it a killall -SEGV milter-greylist?
<fta> pitti, it's a production server, with a lot of traffic :P
<fta> pitti, atm, i auto-restart it from cron, but it's far from ideal
<pitti> so, I ran out of the obvious ideas; now we need to watch it crash, and see what happens
<nh2> is there an archive containing all .debs ever released for Natty? I have a big regression in one of the drivers
<kklimonda> nh2: I think you can access all debs on Launchpad
<fta> pitti, http://paste.ubuntu.com/581214/
<fta> well, not the right one
<pitti> fta: hmm
<fta> hold on
<pitti> ah, you killed the upstart job
<pitti> init.d script actually
<nh2> kklimonda: hmm. http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-input-evdev/xserver-xorg-input-evdev_2.6.0-1ubuntu10/changelog shows a version 2.5.99, but I cannot find that one on https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev or one of the links there
<fta> pitti, just "Segmentation fault", no crash file
<fta> and no log
<pitti> fta: hm, is it possible that the program changes its core dump ulimit?
<pitti> nothing obvious in the source
<nh2> kklimonda: the 2.5.99 is not even in this changelog: https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+changelog so the changelogs must be different ones
<pitti> fta: I see a "signal(SIGSEGV, SIG_IGN);" in the code
<pitti> fta: which would be enabled if WORKAROUND_LIBMILTER_RACE_CONDITION is defined
<kklimonda> nh2: 2.5.99 come from debian, and was probably never released in ubuntu, you can check full publishing history to get a definite list of releases that were made in Ubuntu
<nh2> kklimonda: I checked it 4 days ago and am 100% sure that aptitude show said 2.5.99.something :/
<kklimonda> nh2: 2.6.0 has been released in january so unless you weren't updating your system it's unlikely.
<nh2> kklimonda: yes, my last update was around newyear, and 4 days ago I aptitude show'd and then updated
<mrc3_> hello! every time i try to build gst-plugins-base i get GETTEXT_PACKAGE removed from po/Makefile.in.in: http://pastie.org/1679467
<mrc3_> i'm trying to update rsalveti's g-p-base package
<fta> pitti, but WORKAROUND_LIBMILTER_RACE_CONDITION is not set, so the signals are not diverted
<pitti> fta: so if it just said "Segmentation fault" and not additionally "(core dumped)", then apport wasn't called at all
<mrc3_> the missing GETTEXT_PACKAGE wouldn't bother me except for the fact that .mo files are being installed without a name such as /usr/share/locale/ro/LC_MESSAGES/.mo
<mrc3_> so, my question is: what and why would remove GETTEXT_PACKAGE when using git-buildpackage?
<abhinav-> pitti, apport 1.9.x requires Python 2.7+ ?
<pitti> abhinav-: I'm not sure; does it fail with 2.6?
<pitti> (I don't test it with 2.6)
<abhinav-> no
<abhinav-> but subprocess.check_output is available in 2.7 only
<pitti> right
<abhinav-> so it won't work on my default python
<abhinav-> pitti: I changed the symlink to link /usr/bin/python to python3 then /usr/share/apport-gtk wont run with python3
<pitti> yes, it's not ported to py3 yet, at least not fully
<pitti> abhinav-: so use subprocess.Popen() and communicate()? it's not much more difficult
<abhinav-> ok. I will try that also :)
<broder> whoa...i didn't know about subprocess.check_output. that's amazingly useful
<abhinav-> broder, its short and sweet :-)
<broder> abhinav-: i'm sure. i think i've added something effectively the same as that function to a project's utility library at least 5 different times
<abhinav-> :-D yes it should have been added to python's batteries a long time ago
<blueyed> 736367, too.
<blueyed> cjwatson: re the ctags update, and given that you are good in C/debugging, you might want to include a fix for bug 736367, too.
<ubottu> Launchpad bug 736367 in exuberant-ctags (Ubuntu) "Infinite loop in vim mode/file with "command '...'"" [Undecided,New] https://launchpad.net/bugs/736367
<cjwatson> blueyed: will look, thanks, have been waiting 'til I can carve out a bit of Debian time
<blueyed> cjwatson: would be awesome if you could add a fix for this. It's probably trivial, and has good test case, but my gdb foo is not so good. Might be a matter of minutes for you. Thanks also again for looking into the snapshot itself.
<cjwatson> doesn't sound hard, no
<nh2> cnd: hi! It looks like the Xinput 2.1 support broke some touch screens. Could you tell me if that might be the case? (https://bugs.launchpad.net/ubuntu/+bug/573006?comments=all)
<ubottu> Ubuntu bug 573006 in Ubuntu "Touch screen driver clicks at wrong location" [Undecided,Confirmed]
<cnd> nh2, I'll take a look
<nh2> cnd: thanks
<cnd> nh2, the bug is old and is from lucid
<cnd> I'll take a closer look
<cnd> but it makes me wonder if it's xi 2.1 related
<nh2> cnd: I just bisected that (last 2 comments)
<cnd> nh2, did you bisect the linux kernel?
<nh2> cnd: no, the evdev part
<cnd> oh I see now
<cnd> nh2, which tree did you bisect?
<cnd> git.debian.org?
<nh2> cnd: I used debians repository, yes
<cnd> or something elsewhere?
<cnd> ok
<nh2> cnd it was broken on Maverick, then fixed on Natty in the beginning of January for some time, and is now broken again
<cnd> heh
<cnd> nh2, I left a comment with instructions
<nh2> cnd: awesome. Shall I do it with the latest Natty .deb?
<cnd> nh2, it doesn't matter what version of evdev you have
<cnd> you can leave it at a previous version if you need
<barry> rickspencer3: hi. allison said you have a question for me?
<directhex> where are ppc64 build logs?
<RoAkSoAx> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: Riddell
<nh2> cnd: ok, done
<nh2> the replay tool is indeed nice
<cnd> yep
<bryceh> launchpad down?
<ScottK> bryceh: http://www.downforeveryoneorjustme.com/launchpad.net
<sladen> Permission denied (publickey).
<sladen> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<sladen> is that just me, or are other people seeing that suddenly?
<mrc3_> bryceh == bryce harrington of inkscape fame?
<lifeless> rumour has it
<mrc3_> and tedg == ted gould of inkscape fame as well?
<mrc3_> boy, everyone is in here!
<sladen> mrc3_: welcome to Ubuntu!  ;-)
<tedg> mrc3_, Yes :)
<tumbleweed> would a core dev please accept the nominations on bug 642913 (bonus points for sponsoring the uploads)
<ubottu> Launchpad bug 642913 in Gnome Python Desktop "python wnck bindings have broken constants again" [Medium,New] https://launchpad.net/bugs/642913
<mrc3_> i used to cross-compile inkscape for windows three times a day some time ago
<lifeless> sladen: no, and its working for me, if you are talking about lp
<sladen> lifeless: ta.  dead ssh-agent
<sabdfl> mrc3_: you have both fame, and infamy, in the room
<mrc3_> sabdfl, of mine? gee, i've only been here for a day!
<sabdfl> i'd like to say "your reputation precedes you", but...
<sladen> tumbleweed: do you have an easy unittest/10 line test case that is broken before and works after?  Since I don't know the back-history this would make me happier to valid it
<tumbleweed> sladen: comment 5
<bryceh> mrc3_, yep heya
<sladen> tumbleweed: one line test case is even better ;-)
<mrc3_> hope you guys can show me around, because this ubuntu world is rather big
<tumbleweed> sladen: my pleasure :)
<mrc3_> i'm currently fighting the packaging. i'm losing.
<sladen> mrc3_: and a mere fraction of what it might be in a few more years.  After UDS in Paris I gave up having any hope of knowing who everyone was
<sladen> mrc3_: what paricular patr of packaging
<mrc3_> sladen, git-buildpackage removes a GETTEXT_PACKAGE variable from po/Makefile.in.in (for gst-plugins-base), and thus it installs some files as ".mo" instead of "gst-plugins-base.mo"
<Riddell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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:
<hallyn> cjwatson: should i be able to just 'fakeroot debian/rules binary' in a grub2 package tree, or is grub2 special?  (I was able to fakeroot debian/rules build, but binary complains)
<TheMuso> Is it possible to add more modified files to a patch when refreshing with quilt? If so how?
<TheMuso> nvm answered my question.
<sladen> mrc3_: don't sure I have a good answer for you.  is it definitely git-buildpackage rather than a particularly fragile makefile?
<mrc3_> sladen, this must have worked for rsalveti, since i'm trying to update his package
<mrc3_> this is basically gst-plugins-base + ti's patches for hardware-accelerated video encoding/decoding
 * sladen tries building the one of the archive first
<mrc3_> it must have been something i did while refreshing the patches, i guess. i'll do it all over again
<sladen> mrc3_: I don't know yet, it's still building
<kees> Keybuk: around? I'm curious about why ureadahead leaves /var/lib/ureadahead/debugfs mounted on most of my systems
<mrc3_> sladen, it's behaving better now: i reimported the upstream dsc, readded the patches, used --git-pristine-tar, and now `git diff po/` is showing nothing!
<dylan-m> Hey, any Unity folks about? I'm trying to figure out why something is how it is :)
<dylan-m> Best just say it: I'm wondering why PanelMenuView::OnWindowRestored uses bamf_matcher_get_active_window instead of using the xid that is passed as an argument
#ubuntu-devel 2011-03-17
<sladen> dylan-m: good, might be best put in the bug tracker.  Perhaps phrase it that dylan-m is ignoring the passed parameter
<sladen> dylan-m: good question, ...
<dylan-m> sladen: Yeah, I think I will. It was fine before, but my change adds a race condition or something.
<dylan-m> (Assuming any of our users are like me and enjoy torturing their window managers)
<sladen> dylan-m: I get several unity crashes per day, so that's probably as a result of torturing (what I call "normal use" :-)
<Keybuk> kees: hey
<Keybuk> kees: I don't think it does? I think it just leaves it in mtab
<kees> Keybuk: bug 736512. I'm scratching my head on this
<ubottu> Launchpad bug 736512 in ureadahead (Ubuntu) "leaves /var/lib/ureadahead/debugfs mounted" [Undecided,New] https://launchpad.net/bugs/736512
<kees> Keybuk: basically, something is putting /var/lib/ureadahead/debugfs in mtab and not removing it.
<kees> it doesn't really seem to be either ureadahead or mountall.
<Keybuk> yes
<Keybuk> mountall
<Keybuk> mountall has a function which iterates the mounted filesystems at the point / is remounted rw and puts them all in mtab ;)
<Keybuk> that debugfs mount point is mounted at that time
<Keybuk> so mountall sticks it in mtab
<Keybuk> and since ureadahead is just calling mount() itself, it never removes it from mtab
<Keybuk> now is probably a good time to have that "/etc/mtab should burn in fire" conversation
<sladen> Keybuk: stupid question, but why is it not just a symlink to  /proc/self/mounts  ?
<Keybuk> sladen: because /p/s/m doesn't carry any non-kernel recognised options
<Keybuk> such as those used by a whole raft of userspace mounts (nfs, smb, fuse, etc.)
<Keybuk> and the companion unmount tools of those generally *need* them
<slangasek> I thought they've gotten rid of all the non-kernel options for smb now (well, cifs really)
<Keybuk> slangasek: if they have: one down, a couple of billion to go
<Keybuk> now /proc/self/mountinfo does carry those
<slangasek> yep
<Keybuk> so if you're in a patchy mood ... ;-)
<Keybuk> Fedora have some hideous /dev/.run/mount crap I think too
<Keybuk> I'm not sure what that's about
<psusi> Keybuk, hey, question... you're still listed as the maintainer for usplash... it's dead right?  what should be done about the upstream project on lp?
<Keybuk> whatever anyone wants
<psusi> Keybuk, you're not maintaining it anymore though right, so at the very least, it shouldn't be telling people you do right? ;)
<Keybuk> it doesn't tell people I do
<Keybuk> it tells people I did in a previous life
<psusi> that's not neccesarily known to people looking at the page ;)
<psusi> let me rephrase that... it says a dead man is the maintainer ;)
<Keybuk> there's hundreds of pages on LP like that
<Keybuk> cf. ureadahead too
<psusi> well, I'm fixing to batch close all bugs against it in ubuntu, was thinking of doing the same for the upstream
<psusi> well yea, but ureadahead isn't dead...
<Keybuk> usplash isn't dead, as long as somebody remembers it ...
<psusi> just not found a replacement maintainer yet... probably should change that to ubuntu-dev or something
<psusi> well, I had it dropped from the archive because it can't be installed anymore, and debian is doing the same...
<psusi> I need to start looking over the plymouth sources again too... want to integrate uswsusp with it...
<psusi> can you get upstart to log the stderr of a daemon somewhere?
<hallyn> psusi: 'console output' in the .conf file should do that
<psusi> hallyn, that lets it go to the console... I want it logged
<broder> psusi: no, that's not currently possible without a shell redirects or something
<broder> it's been discussed, and Keybuk indicated that he didn't think it was particularly difficult, and that it should be possible to do more or less in isolation of other upstart development without having to worry much about conflicting changes or anything
<hallyn> psusi: ah  (i guess i misread 'somewhere')
<hyperair> on /media/origroot type none (rw,bind,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=600,commit=0,commit=600,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0)
<hyperair> hmmmm
<hyperair> something seems wrong about this
<broder> hyperair: pm-utils remounts filesystems when you go on and off of AC power, and /etc/mtap is dumb
<hyperair> yeah i know about the remounting bit
<hyperair> but the mtab bit is kinda funny =p
<hyperair> sounds like a bug somewhere
<broder> i'd argue that the bug is that /etc/mtab isn't just a symlink to /proc/mounts :)
<psusi> I frequently have a hanging entry in /etc/mtab for /var/lib/ureadahead/debugfs... it is unmounted during boot but the entry is still there so it shows up in df bug gets the root's details
<broder> psusi: oh, is that what that is? kees was asking about why debugfs was mounted earlier
<didrocks> good morning
<cjwatson> hallyn: normally it should be 'debian/rules build && fakeroot debian/rules binary' (by definition, build doesn't require (fake)root).  What's the complaint from binary?
<pitti> Good morning
<ion> that
<geser> good morning
<abhinav-> pitti,Good monring.  Its working now. but I am not very familiar with unit testing in python.
<abhinav-> pitti, you suggested to update test_parse_argv_apport_bug
<pitti> abhinav-: if you do "test/run local", it should already complain
<pitti> abhinav-: it has two test cases which check CLI arg parsing for teh full (apport-cli) and simplified (apport-bug/ubuntu-bug) case
<pitti> abhinav-: and since you added a new option, this will be missing
<pitti> so you mainly need to add them to the expected option dict
<abhinav-> oh ok. got it :)
<pitti> abhinav-: btw, you can run "python apport/ui.py -v", that's faster than running all tests
<tkamppeter> pitti, I have committed a fix in CUPS for bug 405116
<ubottu> Launchpad bug 405116 in HPLIP ""hpcups" driver of HPLIP has broken margins" [Undecided,Confirmed] https://launchpad.net/bugs/405116
<tkamppeter> pitti, can you upload the CUPS package to Debian and Ubuntu? Thanks.
<pitti> tkamppeter: can do
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: done
<tkamppeter> pitti, thanks.
<dholbach> TheMuso, thanks for the flowers
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: apw
<fta2> pitti, hi. i have another problem with apport... on a server (maverick), one of my services segfaults, i have a crash file with a core, yet apport rejects it as an unsupported "assertion failure".. it's clearly not an assertion
<pitti> fta2: it's a SIGABRT
<pitti> fta2: these come from abort(), which are commonly assertion failures
<fta2> pitti, i wrote the code, there's no abort() anywhere
<pitti> fta2: which signal did it crash with?
<pitti> fta2: if you want to report it anyway, you could edit the .crash file and remove the UnreportableReason: field
<pitti> fta2: but I'm fairly sure it has Signal: 6
<fta2> pitti, well no, i don't want to report it, i just want to use apport to resolve everything for me. I have the -dbg installed
<pitti> fta2: you can still use apport-retrace etc.
<fta2> apport-retrace? hmm
<fta2> where is it?
<pitti> fta2: and the .crash file should have complete data after you run it through the UI once (i. e. you see above error message)
<pitti> fta2: it's in a separate package
<pitti> fta2: apport-retrace -sv /var/crash/foo.crash -> trace to stdout; -gv will throw you into a gdb session
<pitti> fta2: (if you run that as root, it will install extra -dbg/-dbgsym)
<pitti> it's got a fairly complete manpage
<fta2> trying..
<fta2> hm, it dies horribly
<fta2> KeyError: 'Stacktrace'
<fta2> obviously, there's no such entry in the crash file
<pitti> what's the full trace?
<pitti> fta2: (I suspect it failed to generate one, so it can't print it)
<fta2> pitti, http://paste.ubuntu.com/581532/
<pitti> fta2: right, what I suspected; can you please try -g?
<pitti> (instead of -s)
<pitti> fta2: (I'll fix all these deprecation warnings, thanks for pointing out)
<fta2> pitti, ok, it's indeed a sig 6, but deep inside libc
<fta2> pitti, can i ask apport to resolve those anyway? it's not to report to lp, it's for me as upstream
<pitti> fta2: you mean make apport-retrace -s work?
<pitti> (which is equivalent to adding the Stacktrace: to the .crash file)
<fta2> pitti, i mean I'd like to have the Stacktrace/ThreadStacktrace/.. in the crash file even it is unreportable because it's an abort()
<pitti> fta2: right; yes, that should be possible
<fta2> would be great
<pitti> added to my todo list
<soren> cdbs: In the most recent runit merge, you moved the debconf magic to the bottom of postinst. I can't work out why, and it seems to be causing problems.
<abhinav-> pitti, I have made changes in the testsuite but cant really run it. It says: ' /etc/apport/crashdb.conf is damaged: No default database'
<abhinav-> perhaps because of maverick
<abhinav-> pitti: but I made the same changes in a branch of apport 1.4, and ran the tests, they were all ok
<pitti> abhinav-: nice!
<pitti> abhinav-: I can fix up the rest of this in the merge, so don't worry about thsi
<abhinav-> pitti, ok thanks. I will push the branch :)
<pitti> abhinav-: thanks a lot for your work! that's a nice feature indeed
<abhinav-> pitti, Thank you :). apport is really an interesting project
<cdbs> soren: you mean #DEBHELPER# or debconf?
<hallyn> cjwatson: it turned out iwas compiling maverick's grub2 in lucid.  lucid's compiled fine.  sorry for the noise
<cjwatson> hallyn: ok
<cjwatson> hallyn: perhaps missing build-dependencies then
<hallyn> cjwatson: maybe - it was complaining about some arch i'd never heard of before
<cjwatson> I think I'd need to have seen the exact error message ...
<hallyn> cjwatson: in any case i'll just need to try and cherrypick onto the lucid version, np.  thanks
<soren> cdbs: debconf
<soren> cdbs: You moved the confmodule inclusion to the bottom.
<cdbs> wait, did I?
<cdbs> Long time since I did it
 * cdbs looks into the package
<soren> cdbs: Cool, thanks.
<soren> cdbs: The problem is that including debconf/confmodule re-executes that postinst script.
<soren> cdbs: ...and the second time it executes, "start runsvcdir" fails, because it's already running.
<cdbs> wait, this change was made in Debian
<cdbs> but not included in the Changelog message
<soren> Oh, really?
<soren> Ah, yes.
 * cdbs confirms
<cdbs> soren: and, that isn't an ubuntu-specific change
<cdbs> soren: patches.ubuntu.com confirms that
<soren> Oh, I see the problem now.
<soren> They don't use upstart, so they don't have this problem.
<soren> "they" being Debian.
<cdbs> yes, I also get it
<cdbs> start fails, but why is runsvdir running then?
<soren> Because its started the first time the script runs.
<soren> Like I said, including confmodule re-execute the postinst.
<cdbs> soren: is there a bug # already?
<soren> two :)
 * soren waits for lp
<cdbs> soren: bug #708579
<ubottu> Launchpad bug 708579 in runit (Ubuntu) "package runit 2.1.1-6.2ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurÃ¼ck" [Medium,Triaged] https://launchpad.net/bugs/708579
<cdbs> I'll assign that to myself and look into the issue
<soren> cdbs: Cool, thanks!
<cdbs> soren: No, thank you for reporting the issue! :)
<cdbs> Mark enters the fray! ^^
<pitti> kees, jdstrand: new kernel releases to -updates and -security: karmic (linux linux-backports-modules-2.6.31 linux-ec2 linux-meta linux-meta-ec2 linux-ports-meta) and lucid (linux linux-backports-modules-2.6.32 linux-meta linux-ports-meta)
<hggdh> cjwatson, ISO installs are failing -- partman fails, and there is this error:  error while loading shared libraries: libext2fs.so.2 no such file or directory.
<hggdh> cjwatson, and good morning, and sorry to bother
<cjwatson> hggdh: thanks, no problem, I'll look
<cjwatson> hggdh: which images?
<hggdh> cjwatson, we are opening a bug, but you can grab the d-i syslog at (for example) http://204.236.234.12/view/ISO-server-Natty/job/natty-server-amd64_openssh-server/100/artifact/100/test-results/
<hggdh> cjwatson, amd64/i386 for the server and, I guess the alternates
<hggdh> cjwatson, http://204.236.234.12/view/ISO-server-Natty/ gives you an idea
<cjwatson> no more detail needed, thanks
<cjwatson> looks like a regression caused by multiarch support
<abhinav-> pitti, Thanks for accepting the patch and mentioning my name in NEWS :-). The patch had flaws,  I should have written better code looking at the rest of the code in the file :-)
<pitti> abhinav-: don't worry, it wasn't hard to clean up
<abhinav-> :)
<pitti> abhinav-: I have a few other things to do in trunk still, but I should be able to do a new release/upload by tomorrow
<abhinav-> pitti: that would be awesome :)
<Laney> Can someone take a quick look at the build failure here â nothing at all relating to libffi.h changed in ghc with this upload. http://launchpadlibrarian.net/66569327/buildlog_ubuntu-natty-i386.ghc6_6.12.3-1ubuntu6_FAILEDTOBUILD.txt.gz
<cdbs> soren: ah, fixed. Thanks again. Had someone notified me of it earlier I would have fixed it then and there
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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:
<soren> cdbs: Awesome, thanks.
<hggdh> cjwatson, for reference, this is bug 736908
<ubottu> Launchpad bug 736908 in debian-installer (Ubuntu) "debian-installer: partman fails to partition/format a disk" [Critical,New] https://launchpad.net/bugs/736908
<cjwatson> it's an e2fsprogs regression.  I'll look into it
<pitti> fta: I just tried bash -c 'kill -ABRT $$'
<pitti> fta: on current natty, and I do get a Stacktrace in the .crash file (even though apport complained about missing assert message); so I guess that was fixed since lucid
<pitti> fta: I added an automatic check for this to apport's test suite
<abhinav-> pitti, what do you think about bug 340970 ? I think it will require replacing ui_info_message with ui_question_yesno and calling update-manager if the user says yes ?
<ubottu> Launchpad bug 340970 in apport (Ubuntu) "When apport complains package is outdated, it doesn't let you update" [Wishlist,Triaged] https://launchpad.net/bugs/340970
<pitti> abhinav-: I wouldn't like to hardcode update-manager into apport (that would only work on ubuntu)
<abhinav-> right, that would be a problem
<pitti> abhinav-: so to do that, the apport/packaging.py API would need a new method run_package_update(), which the Ubuntu branch could then implement
<pitti> and a way to tell "is upgrading available"
<pitti> ui.py would check the latter, and run run_package_update() or so
<pitti> other distros could plug in packagekit or yast or whatever
<abhinav-> pitti, so define an abstract method in packaging.py ? and where will be the ubuntu specific code go ?
<pitti> abhinav-: into the ubuntu branch, in backends/packaging-apt-dpkg.py
<abhinav-> pitti, oh ok. got it.
<pitti> abhinav-: sorry, it's a bit indirect and abstract, but I really want to avoid any Ubuntu specifics in trunk
<pitti> abhinav-: this could also use python-aptdaemon.gtk3widgets instead of update-manager, not sure what's better
<pitti> or it could try both
<abhinav-> pitti, I understand, it would lead to more portable code :)
<abhinav-> pitti, I dont know about aptdaemon.gtk3widgets, I will try it. Also, perhaps I will now create a branch from lp:apport ? last time I messed it up :-D
<pitti> abhinav-: yes, working from trunk is appreciated
<abhinav-> thanks for helping :)
<mvo> pitti: update-manager uses the aptdaemon stuff internally (fwiw)
<seb128> slangasek, you broke the retracers!
<seb128> slangasek, hey btw ;-)
<seb128> today's libstdc++6 update leads to that error
<seb128> # apt-get update
<seb128> apt-get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by apt-get)
<seb128> apt-get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /tmp/tmpd0eoqh/usr/lib/libapt-pkg.so.4.10)
<pitti> (what a nice way to say "hello" :) )
<pitti> seb128: I guess it's a problem of running this in fakechroot under lucid?
<bjf> pitti, just any fyi, i sent email about new hardy pkgs
<pitti> seb128: we can try getting the natty dchroot upgraded to today's packages, and let the retracer run there
<seb128> pitti, could be, I just hate fakechroot I think ;-)
<pitti> bjf: yeah, I saw; will do ASAP
<pitti> seb128: so do I :)
<seb128> pitti, wdym by "getting the natty dchroot upgraded to today's packages, and let the retracer run there"?
<bjf> pitti, also :-) have you had a chance to look at the kernel sru workflow wiki page? any thoughts?
<pitti> seb128: right now the lucid/maverick/natty retracer runs in osageorange's lucid dchroot
<seb128> pitti, if we run the update and get the new libstd apt-get is broken, it will fail in the apt-get update call
<pitti> bjf: not yet, sorry :/ still knee-deep in other stuff
<pitti> seb128: I mean the dchroot, not the fakechroot
<bjf> pitti, that's what i figured, thanks
<YokoZar> pitti: slangasek: a fun side-effect of wine1.3 being in the archive now is that I need to add about 50 packages to ia32-libs unless I can make em multiarch ready ;)
<cjwatson> pitti: any further thoughts on bug 732860?  I'm just preparing a snapshot upload to Debian now, which will be syncable
<ubottu> Launchpad bug 732860 in exuberant-ctags (Ubuntu) "Please upgrade exuberant-ctags to 5.9 SVN snapshot" [Wishlist,New] https://launchpad.net/bugs/732860
<pitti> cjwatson: no strong opinion; seems fairly safe to me; so if you consider it appropriate, plesae go ahead
<cjwatson> OK - yeah, I do
<slangasek> seb128: interesting; does this retracer problem affect all archs or just i386?
<seb128> slangasek, both i386 and amd64 but seems due to the fact that the retracers are fakechroots running in a lucid environment
<seb128> slangasek, it works fine in a natty chroot, I switched to that for now (but that breaks the lucid retracers as a side effect)
<seb128> slangasek, I think it's rather another fakechroot issue than a bug in the update
<slangasek> seb128: lucid's libc should have already known about the multiarch paths, but I guess maybe they were at the /end/ of the library search path
<slangasek> YokoZar: well, I'm not going to speak in favor of adding anything to ia32-libs, but we're still laying foundations here - it's still much too early for me to suggest flipping multiarch on for end users as a means of installing wine
<YokoZar> slangasek: Will we be able to move anything out of ia32-libs and into proper multiarch in natty?
<slangasek> YokoZar: ia32-libs is not allowed to express a dependency on any 32-bit multiarch packages, so the most likely scenario is still that ia32-libs carries the whole stack that it does now for natty release
<slangasek> only once we've shaken multiarch down and are ready to turn it on for desktop users do we get to start pulling things out of ia32-libs
<cjwatson> slangasek: can you look into bug 736908?
<ubottu> Launchpad bug 736908 in e2fsprogs (Ubuntu) "debian-installer: partman fails to partition/format a disk" [Critical,Triaged] https://launchpad.net/bugs/736908
<slangasek> cjwatson: ah shoot, yes
<fta> pitti, re. /wrt apport, my production servers are running lucid or maverick, obviously not natty.
<slangasek> I swear I checked all the udebs before uploading this
<slangasek> apparently I missed one
<cjwatson> ta
<fta> pitti, also, just installing & enabling apport on a maverick server doesn't do much, apport-* all fail to add anything useful to the crash files.. until you install gdb (and something coming with dpkg-dev, not sure what)
<fta> pitti, .. and i usually don't have the dev tools in my serv-farms
<pitti> fta: ah, that was actually deliberate, as the server folks complained about having gdb by default, bug 354172
<ubottu> Launchpad bug 354172 in apport (Ubuntu) "gdb and python-xdg required dependencies for apport?" [Undecided,Fix released] https://launchpad.net/bugs/354172
<pitti> fta: hm, dpkg-dev? that shouldn't be
<fta> pitti, well, not dpkg-dev itself, one of its deps
<pitti> fta: ah, binutils perhaps
<pitti> although I don't immediately see anything in binutils which it would need
<fta> pitti, i had to install dpkg-dev on a pre-prod box to satisfy apt-get source (the unpack part), and it dragged a bunch of stuff with it, which made apport work
<Laney> slangasek, doko: Sorry to ping directly, but can one of you look at the ftbfs of ghc6/i386? gcc fails to find libffi.h â it doesn't appear to be on the default search path.
<slangasek> Laney: yes, libffi needs fixing for multiarch, known issue on my list - didn't realize it was blocking anything, I'll fix that now
<Laney> great, thanks
<slangasek> Laney: this failure is i386-only, right?
<Laney> yeah
<OdyX> tkamppeter: Grrrâ¦ Why did you upload the foomatic-db to Ubuntu ? It could easily have gone trough Debian + sync this timeâ¦
<slangasek> Laney: libffi 3.0.9-3ubuntu1 uploaded
<Laney> slangasek: thanks! will give ghc6 back when it hits :-)
<pitti> bjf: hm, seems the lrm upload includes every changelog made ever -- http://launchpadlibrarian.net/66520064/linux-restricted-modules-2.6.24_2.6.24.18-29.8_source.changes
<pitti> bjf: this will cause a lot of bug noise
<bjf> pitti, my bad
<bjf> pitti, i'll fix that
<pitti> ok, thanks
<bjf> pitti, i must have dropped the -v of the command line and didn't notice the changelog
 * pitti will do linux in the meantime
<pitti> that always takes longest anyway
<pitti> bjf: linux, l-u-m, and l-b-m done; waiting for a fixed l-r-m, and linux-meta is missing
<bjf> pitti, won't the linux-meta in -proposed suffice ?
<pitti> bjf: ah, it's already -29, right
<pitti> sorry
<bjf> pitti, np, always good to double check
<pitti> bjf: the hppa build has a proper ubuntu build record now (https://launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/2.6.24-29.38/+buildjob/2327416)
<ubottu> Error: Could not parse data returned by Ubuntu: 2 (https://launchpad.net/bugs/2)
<pitti> bjf: but of course without any hppa buildds that'll need to wait a bit
 * pitti checks https://launchpad.net/builders/kohnen
<pitti> trying to revive
<pitti> hm, it's back on, but on manual
<pitti> lamont: ^ kohnen (hppa) is on manual, is that deliberate?
<lamont> only slightly
<lamont> it's back to auto now
<pitti> ah, cheers
<pitti> bjf: linux hardy hppa building now
<slangasek> cjwatson: e2fsprogs fix inbound; any other multiarch breakage you're running into?
<cjwatson> slangasek: that's all I've heard of so far ...
<slangasek> ok
<cjwatson> do you have a list of libraries converted up to now?  I could go and double-check
<slangasek> cjwatson: the list of packages on https://launchpad.net/~vorlon/+archive/multiarch/+packages that are superseded by newer versions, basically :)
<cjwatson> that's as good as any other list
<cjwatson> ok
<cjwatson> slangasek: everything else there seems fine
<slangasek> ok, good to hear
<M0hamed> hello is this where I ask questions about how wubi installer works
<cjwatson> M0hamed: I suppose it's as good as anywhere else
<M0hamed> ok I was wondering how I could incorporate wubi-like functionality into other distributions
<M0hamed> debian based
<cjwatson> it would be a pretty giant amount of work
<cjwatson> wubi includes integration into the installer, and there are lots of pieces that aren't in Debian yet
<cjwatson> I'm not even sure I can enumerate them all and I wrote several of them
<M0hamed> but the veru first version of lupin was a side project thatuses the debian installer with no change in the actuall ubuntu source
<cjwatson> I know, but it did stuff like running sed over installer code at run-time
<cjwatson> it wasn't maintainable like that, so we integrated it into the installer instead
<M0hamed> so it wouldnt be a good GSoc project
<cjwatson> you're not the first to ask, but I suspect that it would be pretty challenging as GSoC projects go, yes ...
<M0hamed> cjwatson: can you tell me where to look for more info and how to build it from source
<cjwatson> I think at the very least you would need to limit the scope - for example, including "port ubiquity to Debian" in the scope would reduce its chances of success by a fair bit
<cjwatson> https://wiki.ubuntu.com/Installer/Development is about the best I can do for the Ubuntu installere
<cjwatson> *installer
<M0hamed> cjwatson: why not just use the debian installer
<cjwatson> that would be one option for a Debian port
<M0hamed> cjwatson: why ubiquity
<cjwatson> it would still require a good deal of work
<M0hamed> cjwatson: anyway that rules out that project because I am not that experienced in linux development and thought it was a good starting point
<cjwatson> you'd need to do a full analysis of wubi's preseeding and figure out which installer facilities need to be ported to Debian; separately, you would need to figure out how to integrate the post-install bits, so integrating lupin with live-initramfs, porting the grub2 pieces over, etc.
<cjwatson> and of course the Windows UI side of things
<M0hamed> the windows ui is the easiest
<M0hamed> cjwatson: its what I am experienced in the problem is on the linux side
<cjwatson> oh, and the patches to fuse and ntfs-3g to put it in the initramfs, which we submitted to Debian some time back and the relevant maintainers refused to include them
<cjwatson> (at least that's my memory ...)
<M0hamed> cjwatson: so would that be the case for any other debian based distribution
<M0hamed> or is it just debian itself lacking certain features
<cjwatson> hm, the fuse patch was rejected, ntfs-3g initramfs never got submitted, but the ntfs-3g udeb patch was marked wontfix with no explanation and that would be absolutely necessary
<cjwatson> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481335)
<ubottu> Debian bug 481335 in ntfs-3g "ntfs-3g: Please build udebs for installer ntfs-3g support" [Wishlist,Open]
<cjwatson> anything descended from Debian and not descended from Ubuntu is likely to have the same obstacles
<M0hamed> cjwatson: you were graet thank you
<M0hamed> cjwatson: although I will think twice before atempting such a feat
<M0hamed> cjwatson: but you really helped
<cjwatson> you're welcome
<hasenj> what's the preferred way to develop natty? dual boot? or a virtual machine?
<RoAkSoAx> hasenj: most of us work on the development version
<hasenj> so it's the only installed version basically ..?
<hasenj> I mean, you don't dual boot with 10.10 or anything like that?
<RoAkSoAx> hasenj: I don't
<RoAkSoAx> hasenj: i usually keep older kernels in case something goes wrong with graphics or stuff like that
<cjwatson> in the very early part of the cycle I usually use a chroot.  from alpha 1 onwards or so I just upgrade and run it natively.
<cjwatson> (but I know how to rescue myself if it breaks ...)
<Chipzz> cjwatson: have you asked the maintainer about the ntfs3f udeb bug?
<Chipzz> cjwatson: it appears he is on #debian-devel, I just asked him about it
<hasenj> ah, chroot, interesting
<cjwatson> Chipzz: somebody asked on the other bug he marked wontfix at the same time, and he did not respond
<cjwatson> so I didn't hold out any particular hope
<kirkland> how do i make the unity sidebar thing go away?
<kirkland> it's getting "stuck"
<kirkland> and rendering on top of my more important windows
<Martiini> elou ..
<Martiini> anyone here who belongs to devel team?
<Martiini> I have a question about ubuntu kernel .. kernel seems to configured not as well as some other distros
<Martiini> I have installed .. fedora, opensuse, ubuntu ..  and .. opensuse seem have best kernel+modules .. most laptops work out-of-box with acpi modules .. etc etc
<achiang> Martiini: there is an #ubuntu-kernel channel that might be more appropriate; additionally, you may have better luck if you try to make your question more specific
<Gatorade> hi
<Gatorade> hi
<mrc3_> sladen, i revisited gst-plugins-base, and i see now when it goes awry: with "include /usr/share/cdbs/1/rules/autoreconf.mk" in debian/rules
<sladen> mrc3_: autocrap.  joy.  mmm
#ubuntu-devel 2011-03-18
<psusi> switching back and forth between packages that leave quilt patches applied in bzr and ones that don't is driving me up the fscking wall!  for the love of root, will someone fix the auto package importer to deapply patches before committing?
<poolie> psusi, you're pretty sure that would be better across the board?
<poolie> there was a thread about this recently
<poolie> i can see the inconsistency would suck
<psusi> poolie, yes!  reviewing commits that add a quilt patch, AND modify the files the quilt patch touches is a royal pain in the ass
<poolie> yeah
<psusi> but yea, inconsistency is worse than that
<psusi> not to mention a needless bloating of the archive
 * ScottK still has trouble with Source V3 because starting with the patches already applied just feels wrong.
<psusi> indeed... they need to be deapplied in bzr
<psusi> working on packages where they are not applied is so nice... backporting to older releases is cake
<aroman> what in Ubuntu's livecd causes a "Desktop" folder to be created in the livecd desktop user's home folder?
<aroman> ls
<IanLiu> I'm trying to fix bitesize bugs from unity, but I'm in doubt on how to replace the current unity with my compiled one. Any help?
<ScottK> IanLiu: You might have more luck in #ubuntu-desktop or #ayatana.  I'm not sure which would be better.
<IanLiu> ScottK: Thanks, I will try asking there
<ohsix> ugh, random right clicks coming from touchpad, and mouse realllly slow even with the sensitivity set all the way up in natty
<tkamppeter> OdyX, we are after FF, I think activating a new sync after FF is not possible.
<micahg> tkamppeter, depending on the change, we can still sync, what's the question?
<tkamppeter> I have uploaded foomatic-db to Ubuntu, a new upstream source which adds a bug fix. This package is the same in Ubuntu and Debian. We want to have a sync here, but as we are after FF I thought that the sync is not possible, because arbitrary Debian uploads cannot go into Ubuntu.
<tkamppeter> micahg, does a sync not mean that every Debian upload goes automatically into Ubuntu?
<slangasek> no, syncs can be processed on packages individually
<slangasek> this is the purpose of the 'requestsync' tool, for instance
<pitti> Good morning
<micahg> tkamppeter, after DIF, syncs must be requested individually
<dholbach> good morning
<abhinav-> pitti, Good morning. I was wondering if we should call upgrade only for the package(s) for which the user was trying to report a bug/crash or simply run upgrade for all packages ?
<pitti> dpm: all maverick langpacks are built and in the archive, btw, so they can be tested now
<dpm> pitti, ok, cool, thanks, I'll send the announcement and prepare the wiki page. What's the version number?
<pitti> dpm: 1:10.10+20110315
<pitti>  kees, jdstrand: releaseing maverick kernel to -updates/-security (linux linux-backports-modules-2.6.35 linux-meta linux-ports-meta)
<brendand> has anyone noticed that bootchart has stopped working in recent natty images?
<brendand> it doesn't generate any data to /var/logs/bootchart
<brendand> when i install it i can see initrd is updated
<tjaalton> something wrong on the amd64 build chroot? nvidia fails to build, although the earlier upload today did build
<tjaalton> http://launchpadlibrarian.net/66646771/buildlog_ubuntu-natty-amd64.nvidia-graphics-drivers_270.30-0ubuntu2_FAILEDTOBUILD.txt.gz
<OdyX> What chance do I have to see usb-modeswitch{,-data} to get sync'ed from Debian ? IMHO it's worth having (less complication).
<jhunt> bdrung, elmo, cjwatson: could you try out the latest gdm.conf on bug 436936 (https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/436936/+attachment/1915134/+files/gdm.conf) when you get a chance?
<ubottu> Ubuntu bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged]
<ubottu> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936
<jhunt> bdrung, elmo, cjwatson: the "start on" is getting a bit "hairy". We have a cunning plan to simplify using abstract jobs for the next cycle.
<bdrung> jhunt: i will try it once restored everything after an harddisk upgrade
<jhunt> bdrung: thx!
<jelmer> pitti: hi
<pitti> hey jelmer, how are you?
<jelmer> pitti: I'm well, thanks :)
<jelmer> pitti: Vila and I are looking at a FFe for a bzr microrelease for natty
<jelmer> pitti: do we need one, even if bzr is part of MRE ?
<pitti> jelmer: should be fine
<pitti> jelmer: if they meet the MRE standards, it's mostly bug fixes anyway, is it?
<jelmer> pitti: yes
<pitti> bug fixes don't require a FFE
<ogra_> OptiPNG 0.6.4: Advanced PNG optimizer.
<ogra_> Copyright (C) 2001-2010 Cosmin Truta.
<ogra_> what calls that during a package build ?
<ogra_> it breaks unity-2d and i somehow need to disable it
<jelmer> pitti: thanks
<pitti> ogra_: that's pkgbinarnymangler
<pitti> ogra_: you can export NO_PNG_PKG_MANGLE=1 in debian/rules
<pitti> ogra_: but out of interest, how does it break?
<brendand> cjwatson - do you know that bootchart is broken in recent natty images? it seems since yesterday
<ogra_> pitti, but that will suppress other optimizations, no ?
<ogra_> pitti, Qt seems to not be able to handle 8bit images for stacking them onto alpha blended ones :)
<pitti> ogra_: no, that one just disables png optimizations
<pitti> ogra_: NO_PKG_MANGLE disables everything
<ogra_> ah, k
<ogra_> we could convert them during load but that would slow down the code
<janimo> ogra_, is this a known Qt issue, maybe with bug filed?
<ogra_> janimo, no bug afailk
<cjwatson> brendand: is that bug 723663, or something different?
<ubottu> Launchpad bug 723663 in pybootchartgui (Ubuntu) "ZeroDivisionError in bootchart when parsing data from a HP Proliant DL360 G5" [Medium,Confirmed] https://launchpad.net/bugs/723663
<brendand> cjwatson - no, that's just one machine generating bad data
<brendand> cjwatson - this is *everything* generating *no data*
<brendand> cjwatson - tried on vbox too
<cjwatson> ok, is there a bug?
<brendand> cjwatson - just now
<brendand> cjwatson - i ran ubuntu-bug bootchart. hope that gives decent logs
<cjwatson> bootchart itself hasn't been changed since lucid
<brendand> cjwatson - i believe you
<brendand> cjwatson - wonder what's affected it then
<cjwatson> not asserting your bug doesn't exist, just that it was likely caused by something else
<brendand> cjwatson - https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/737487
<ubottu> Ubuntu bug 737487 in bootchart (Ubuntu) "Bootchart data not generated" [Undecided,Confirmed]
<brendand> cjwatson - if there's anything further needed i'll be glad to gather it for you
<cjwatson> thanks, bumped to high
<cjwatson> jhunt: ^- do you have time to have a look at that?
<brendand> cjwatson, jhunt - do you reckon maybe the process which bootchart looks for to stop has changed somehow?
<cjwatson> brendand: it's multiarch fallout, we're discussing it
<brendand> cjwatson - it certainly looks like the problem is that it hasn't stopped
<brendand> cjwatson - on my Maverick system, the /var/run/bootchart directory is not there (because it's supposed to get cleaned up)
<brendand> cjwatson - but when the bootchart.tgz doesn't exist, the /var/run/bootchart directory does
<brendand> cjwatson - in this case
<cjwatson> brendand: jhunt has found the root cause, we're working on a fix
<cjwatson> as I say it's multiarch fallout - libc moved
<brendand> cjwatson - thanks
<jdstrand> kirkland: hi! you probably saw this, but qemu-kvm ftbfs on i386, which make qemu-kvm on amd64 uninstallable (cause of qemu-common)
<jdstrand> s/make/makes/
<jdstrand> hallyn: ^
<kirkland> jdstrand: hmm, i have not seen that
<jdstrand> kirkland: https://launchpad.net/ubuntu/+source/qemu-kvm/0.14.0+noroms-0ubuntu3/+buildjob/2325646
<ubottu> Error: Launchpad bug 0 not found
<kirkland> jdstrand: hallyn is out today, let me take a look ...
<kirkland> jdstrand: hmm, ugly
<kirkland> jdstrand: i wonder if that's multi-arch breakage?
<kirkland> gcc: Internal error: Killed (program cc1)
<jdstrand> yeah, I don't know :\
<kirkland> jdstrand: it built locally here before i uploaded
<kirkland> cjwatson: could you have a quick look at this build breakage for qemu-kvm and tell me if you think it's multi-arch related?  https://launchpad.net/ubuntu/+source/qemu-kvm/0.14.0+noroms-0ubuntu3/+buildjob/2325646
<ubottu> Error: Launchpad bug 0 not found
<kirkland> cjwatson: strange gcc error with little-to-no debug information
<abhinav-> dholbach, nice article, very informative :-)
<dholbach> thanks abhinav-
<dholbach> if you have any more feedback, let me know (or comment on the article)
<abhinav-> yup, sure, I will :)
<cjwatson> kirkland: doesn't seem likely
<cjwatson> "Killed" sounds like "somebody sent me SIGKILL"
<cjwatson> perhaps OOM?
<kirkland> cjwatson: yeah, that does sound like it
<mterry> If a friendly archive admin wanted to push the button on bug 736807, I'd be grateful
<ubottu> Launchpad bug 736807 in nlpsolver (Ubuntu) "Sync nlpsolver 0.9~beta1-5 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/736807
<abhinav-> dholbach, I am doing a session on UDD in my college during an open source unconference. I was just going to repeat whatever I learnt during developer week, but the ubuntu-packaging-guide will be an excellent source to get more information :)
<dholbach> abhinav-, sweet - I'm glad you like it!
<dholbach> let me know how the session goes!
<abhinav-> sure. I will :)
<ogra_> cjwatson, adding debian-installer/framebuffer=false to the headles images cmdline didnt change anything
<ogra_> oh, wait, its gone after first boot :P so once d-i starts it has a framebuffer again ... silly me
<cjwatson> ogra_: I mean preseeding it in the debconf database used by oem-config
<ogra_> cdmline wouldnt suffice ?
<ogra_> *cmd
<cjwatson> dunno offhand
<ogra_> its hard to distinguish if i'm on headless or not, but the initial cmdline is set during build based on $PROJECT
<ogra_> so setting it in advance is the easiest way, else i need detection code
<cjwatson> this is just for experimental purposes
<cjwatson> I want to know whether that makes a difference to narrow down the problem
<ScottK> OdyX: It depends a lot on what's in the update.  If it's pure bugfix it's no problem at all.
<ogra_> hmm, k
<OdyX> ScottK: it's notâ¦ But usb-modeswitc has rarely been broken by upstreamâ¦
<OdyX> ScottK: anyway, your call people. :-)
<ScottK> OdyX: You recommend we update?
<OdyX> ScottK: I do, as it gets rid of the -packed flavour (see -data changelog), but it is in unstable for two days only...
<OdyX> the -packed flavour finally was transitional, so It'd be nice to not have it in Natty.
<ScottK> OdyX: We need someone to make a Feature Freeze exception so the release team can evaluate it.  Unfortunately my schedule is packed right now.
<OdyX> ScottK: mine too.
<ScottK> cyphermox: ^^^ would you be interested in taking care of the FFe?
<ScottK> dholbach: You uploaded a fix for Bug #612885 that seems to both make appindicator support optional and add python-appindicator to depends.  As commented in the bug, I think adding the dependency now is wrong.
<ubottu> Launchpad bug 612885 in gtk-recordmydesktop "Startup of gtk-recordmydesktop fails with "TrayPopupMenu instance has no attribute 'popupmenu_continueitem'" error" [Undecided,New] https://launchpad.net/bugs/612885
<cyphermox> ScottK, reading the backlog now
<cyphermox> OdyX, so there's a new release of usb-modeswitch-data?
<OdyX> cyphermox: yes, 20110227-2
<OdyX> cyphermox: released 3 weeks ago, uploaded yesterday to unstable.
<cyphermox> OdyX, ok, I'll file the FFe bug in a minute
<cyphermox> ScottK, thanks for the notice :)
<OdyX> cyphermox: nice. Note you need usb-modeswitch 1.1.7 too
<cyphermox> OdyX, ok. both non-bugfix right?
<OdyX> cyphermox: it's debatable. :-)
<cyphermox> AFAIK if there isn't already an SRU special case for usb-modeswitch I think we might want one... it's not necessarily uncommon to see people with new usb 3g devices on a "final" release
<cyphermox> OdyX, usb-modeswitch is one thing that doesn't worry me too much. Plus if it breaks you're around, so we'll just blame it on you :)
<OdyX> cyphermox: fine for me.
<ogra_> cjwatson, cmdline didnt make a difference ... i'll try an explicit debconf-communicate call from the inird setup script to set it directly
<ogra_> *initrd
<dholbach> ScottK, I guess that depends on which experience we want users to have
<dholbach> ScottK, making it "optional" is something that would make sense upstream in any case
<mdz> skaet, where can I find a complete list of natty FFE requests and their status?
<ScottK> dholbach: For non-Ubuntu flavors that depends drags in the entire appindicator stack.
<ScottK> dholbach: If it were only about Ubuntu, I'd agree.
<ScottK> mdz: https://bugs.launchpad.net/~ubuntu-release has them for all releases.
<skaet> mdz, have been using launchpad, and tracking through new status.   https://bugs.launchpad.net/~ubuntu-release/+bugs?orderby=datecreated&field.status%3Alist=NEW
<kirkland> hmm, any gcc/toolchain experts around, in doko's absence?
<ogra> pitti, heh, the tag isnt enough for armel bugs ?
<dholbach> ScottK, alright, you have a point - I'll make it a Recommends
<kirkland> i'm trying to debug a build failure of qemu-kvm i386 on the buildd's
<ScottK> dholbach: Suggests please.  Recommends still get installed by default.  It's non-trivial for normal users to avoid them.
<dholbach> ScottK, my thinking was that for a gtk app that still makes sense
<dholbach> seb128, what do you think? moving python-appindicator from depends to recommends?
<dholbach> https://bugs.launchpad.net/ubuntu/+source/gtk-recordmydesktop/+bug/612885/comments/10
<ubottu> Ubuntu bug 612885 in gtk-recordmydesktop "Startup of gtk-recordmydesktop fails with "TrayPopupMenu instance has no attribute 'popupmenu_continueitem'" error" [Undecided,New]
<ScottK> dholbach: People should be able to use an application in their DE of choice independent of what toolkit it's writtenwith.
<ScottK> So I think "It's GTK" is not relevant.
<seb128> dholbach, recommends seems right to me
<mdz> skaet, thanks!
<ScottK> seb128: That's going to pull in a lot of dependencies for non Ubuntu-desktop users.
<seb128> ScottK, how so? libappindicator has been splitted out this cycle it's a small lib
<ScottK> seb128: Does it work with xfce or lxde?
<seb128> ScottK, the indicators do fallbacking to gtkstatusicon when there is no indicator loader from day one
<ScottK> (I think it would work correctly with Kubuntu since we seed libindicate-qt)
<ScottK> OK.
<ScottK> I guess it's OK then.  I'd forgotten it was a lot smaller now.
<dholbach> ok, great - I'll make it recommends and upload in a bit
<seb128> dholbach, ^ recommends
<seb128> dholbach, thanks
<dholbach> thanks ScottK for bringing it up
<kirkland> mdeslaur: jdstrand: the qemu-kvm build break has to be multiarch, or something else in the tool chain;  the diff since the last upload (and successful build) is trivial and unrelated: http://launchpadlibrarian.net/66546963/qemu-kvm_0.14.0%2Bnoroms-0ubuntu2_0.14.0%2Bnoroms-0ubuntu3.diff.gz
<jdstrand> kirkland: did you retry the build?
<abhinav-> pitti, what does  ui_shutdown do ? I am calling it inside the exception handler while running the run_package_upgrade method .
<kirkland> jdstrand: just pressed retry ~10 minutes ago
<kirkland> jdstrand: 13 minutes in;  last failure was at 17 minutes
 * jdstrand crosses fingers
<jdstrand> :)
<jdstrand> though if it is the toolchain, an up to date chroot should reproduce it locally
<kirkland> jdstrand: mdeslaur: kees: qemu-kvm i386 rebuild succeeded
<jdstrand> \o/
 * kirkland has no explanation
<jdstrand> probably a problem with the buildd
<mdeslaur> kirkland: cool
<pitti> abhinav-: see its docstring; it's not actually used anywhere in the gtk/kde/cli implementations, so I guess calls to it are fairly inconsistent
<pitti> abhinav-: but you shouldn't call it when you call the package update
<abhinav-> pitti, so if an error occurs I should simply return after displaying an error message ?
<pitti> abhinav-: yes; you should only call ui_shutdown() if you do an exit()
<abhinav-> ok. I think I got it
<micahg> ScottK, >re comment in ubuntu-meeting, I thought DSO linking wasn't reverted, just --as-needed
<ScottK> micahg: I think you're right.  The idea is still good though.  Thanks.
<mdeslaur> anybody know why gdm is showing me the "postfix" user in the chooser?
<seb128> mdeslaur, bug #696038
<ubottu> Launchpad bug 696038 in gdm (Ubuntu Natty) "system user appears in login list of users" [Low,Confirmed] https://launchpad.net/bugs/696038
<seb128> mdeslaur, it likely comes from the ck-history log
<seb128> not sure why it got a ck session now
<seb128> now -> though
<mdeslaur> seb128: ah, yes, that seems to be the appropriate bug...thanks!
<seb128> mdeslaur, you're welcome
<apw> slangasek, are the compilers stable for the moment?
<slangasek> apw: for the next while at least
<smoser> @pilot-in
<udevbot> Error: "pilot-in" is not a valid command.
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: smoser
 * dholbach hugs smoser :)
<pitti> ScottK: do you have some further info about bug 712554? (see comment 4)
<ubottu> Launchpad bug 712554 in jockey (Ubuntu Natty) "Unable to install Broadcom drivers from live session" [Medium,Incomplete] https://launchpad.net/bugs/712554
<ScottK> pitti: No.  I'll do install testing for Beta 1 and I'll see if it still happens.
<ScottK> (I didn't get the chance for Alpha 3).
<pitti> ScottK: ok, thanks
<mok0> My friend is a sysadm who has just found the need to enable disk-quotas. We are thinking about writing software that gives a users a notification (every 30 minutes, say) if the users' disk quota is exceeded. Do you think there is an interest in such a system for Ubuntu in general?
<abhinav-> pitti, I have added code for upgrading packages, but I dont seem to have any  obsolete packages to test with :-/
<pitti> abhinav-: just grab an older one from launchpad?
<abhinav-> pitti, oh ok. I will try with that. thanks
<beuno> chrisccoulson, ping
<chrisccoulson> hi beuno
<beuno> hey chrisccoulson, I just got poked about missing search providers in FF
<beuno> know anything about this?
<chrisccoulson> in maverick?
<beuno> chrisccoulson, yes
<chrisccoulson> beuno, i think that should be fixed already
<chrisccoulson> pitti - did the new langpacks get uploaded to maverick-proposed?
<pitti> chrisccoulson: yes, they are in
<chrisccoulson> beuno, how long ago was this?
<chrisccoulson> pitti - thanks
<pitti> chrisccoulson: I tested search plugins with de, dpm tested es and ca
<pitti> beuno: do you have language-pack-... 1:10.10+20110315 ?
<beuno> pitti, I haven't upgraded today, this is second-hand complaining  :)
<smoser> anyone with correct perms able to accept a trivial merge proposal ? https://bugs.launchpad.net/ubuntu/+source/txt2regex/+bug/736326
<ubottu> Ubuntu bug 736326 in txt2regex (Ubuntu) "typo in repetition subwindows" [Undecided,In progress]
<beuno> chrisccoulson, any ideas how long its been broken?
<chrisccoulson> beuno, since last friday
<beuno> chrisccoulson, and this is just maverick?
<chrisccoulson> beuno, just maverick-proposed
<beuno> chrisccoulson, ah, so low impact?
<chrisccoulson> beuno, yeah
<beuno> chrisccoulson, cool, thanks
<slangasek> jamespage: I'm not sure who normally takes care of openjdk-6 packaging; if you want to have a look at fixing bug #737603 I'm happy to provide support, or if you need this to be a foundations problem I can queue it up to work on here today/tomorrow
<ubottu> Launchpad bug 737603 in openjdk-6 (Ubuntu) "JNI unable to find libpam.so" [High,Triaged] https://launchpad.net/bugs/737603
<cjwatson> slangasek: normally doko
<jamespage> cjwatson beat me to it....
<slangasek> ok
<SpamapS> So.. the runit-run package uses dpkg-divert to replace /sbin/init ...
<SpamapS> I'm not sure if this is a huge critical bug or just an insanely weird package.
<jamespage> slangasek: it would be great if foundations could pick this up - is doko around?
<abhinav-> pitti, Interestingly, I have the latest linux header updates pending in the update manager, but apport simply starts with asking questions. I was thinking that report.obsolete_packages() checks the cache
<pitti> abhinav-: it only checks (transitive) dependencies of the crashed program, not all packages
<abhinav-> pitti, so apport-bug linux would check for linux and its dependencies ?
<pitti> abhinav-: yes, and as the kernel doesn't have many, it won't complain
<abhinav-> hmm
<pitti> abhinav-: you could e. g. install acl (or another small package) from maverick, and then try to report a bug against it
<pitti> abhinav-: or from lucid, if you are on natty; try installing http://archive.ubuntu.com/ubuntu/pool/main/a/acl/acl_2.2.49-2_i386.deb and then ubuntu-bug acl
<abhinav-> pitti, ah ok thanks. I am on maverick though.
<pitti> abhinav-: above is lucid's version, will work
<abhinav-> pitti, ok thanks. trying :)
<slangasek> jamespage: I think doko may still be traveling back from pycon?  at least that's what his TZ availability this week seems to suggest
<slangasek> right, PyCon ran through yesterday, so I guess he's traveling no
<slangasek> w
<slangasek> so I'll have a look at this
<slangasek> SpamapS: the runit-run package that no longer exists in Debian due to this critical bug? :)
<SpamapS> slangasek: YES that one.
<SpamapS> slangasek: shall we drop it as well?
<slangasek> I would think so
<SpamapS> slangasek: its also usurping 'man init' on manpages.ubuntu.com .. doh
 * slangasek chuckles
<abhinav_> pitti, acl is also in apt's cache, but apport is not reporting it as obsolete. I checked with my new code as well as with the current trunk
<slangasek> Riddell: if I understand your cmake change correctly, this populates the search path by invoking dpkg-architecture at runtime, right?
<slangasek> Riddell: in that case, you probably also want cmake to depend on dpkg-dev, since dpkg-dev isn't guaranteed to be installed on the systems of end users who are doing non-package-related development
<jamespage> slangasek: thankyou
<slangasek> (but this is a minor bug - the fix looks very nice, glad you guys were able to come up with a solution)
<slangasek> Riddell: as a side effect, this seems to fix cmake behavior for cross-compilation against libraries in multiarch paths... which is exactly what we want to see :-)
<Riddell> slangasek: yes, we're currently discussing in #k-d if we want to depend on dpkg-dev or hardcode it at package build time
<penguin42> smoser: Hi
<smoser> penguin42, hi
<penguin42> smoser: I proposed the merge of a branch against bug 725044 and wouldn't if I should do anything else
<ubottu> Launchpad bug 725044 in libsdl1.2 (Ubuntu Natty) "SDL rendering issue: graphic corruption while scrolling right" [Low,Triaged] https://launchpad.net/bugs/725044
<smoser> penguin42, i'll take a look
<penguin42> Thanks - ampelbein helped me through the process for the 1st time
<christer1>  /quit
<christer1> clear
<smoser> penguin42, i do not have upload access for libsdl, so i can't upload it. it looks good to me though.  I commented with one nitpick in the bug, and i think you  might as well fix that.
<smoser> s/bug/branch merge proposal/
<chrisccoulson> hi slangasek. would you mind taking a quick look at bug 737641? :)
<ubottu> Launchpad bug 737641 in make-dfsg (Ubuntu Natty) "Mozilla packages don't build in Natty (and blocking FF4.0 RC2/final)" [Critical,Triaged] https://launchpad.net/bugs/737641
<chrisccoulson> it seems multi-arch related
<penguin42> smoser: OK, thanks I can fix that up
<slangasek> chrisccoulson: sigh :/  what build system is this?
<slangasek> chrisccoulson: also, what's the corresponding source package in the archive that I should look at? I don't see thunderbird-3.3 anywhere
<chrisccoulson> slangasek, that's hard to describe, it's a fairly complex and customized build system just built around make
<chrisccoulson> slangasek, yeah, thunderbird-3.3 is in one of our PPA's, but the failure also affects the firefox and thunderbird packages in the archive
<chrisccoulson> although, they haven't been rebuilt since the changes yesterday. i wanted to upload the new release today before i hit the problem locally
<slangasek> chrisccoulson: ok, found the code responsible in make-dfsg; working on making it smarter
<chrisccoulson> slangasek, excellent, thank you :)
<MadCow108> is natty going to have multiarch support? I'm a bit surprised at all these uploads with multiarch in the changelog after feature freeze o_o
<vish> ScottK: hmm, Aubergine is not Ubuntu's color either, its just Canonical's color.. so its not flavored in anyway.. ;)
<vish> any* way
<ScottK> vish: OK.  It goes better with Orange than Blue in any case.
 * vish nods..
<ScottK> It would nice if such things were discussed before they were langed, particularly after feature freeze.
<charlie-tca> +1 ScottK
<slangasek> chrisccoulson: make fix uploaded
<chrisccoulson> slangasek, you rock! thanks :)
<slangasek> chrisccoulson: n/p, sorry for the breakage
<ScottK> charlie-tca: Please reply to the thread on ubuntu-devel.
<charlie-tca> I can't. I don't have rights there
<ScottK> charlie-tca: You can.  It just goes into a moderation queue.  It'll be delayed, but it will get there.
<charlie-tca> okay. I will then!
<till_> in my the dependencies in my control file, is there a way to say package depends on another package foo or a package bar, but if none is installed, just get foo?
<Ampelbein> till_: Depends: foo | bar
 * till_ facepalms
<till_> Ampelbein: thanks =)
<RoAkSoAx> bryceh: ping
<RoAkSoAx> bryceh: any ideas what might be cause this? http://me.roaksoax.com/dual-monitor.jpeg (Intel Video driver maybe?)
<bryceh> RoAkSoAx, could be a few things
<bryceh> RoAkSoAx, do you have compiz running?  (looks like no?)
<RoAkSoAx> bryceh: nope
<bryceh> RoAkSoAx, what video driver?
<RoAkSoAx> bryceh: just happens when laptop's LCD is off though
<bryceh> heh, here comes a game of 20 questions
<bryceh> RoAkSoAx, why don't you describe a bit more about your setup
<bryceh> what you did to reproduce, etc.
<RoAkSoAx> bryceh: Intel HD Video graphics. Lenovo x201 recently purchased. I connect it to VGA and when having the laptop's LCD on, then the external monitors work just fine
<RoAkSoAx> when turning off the LCD displayt and just leaving the external monitors, it shows that
<RoAkSoAx> bryceh: i connect to both external monitors via a dualhead2go, though when using another laptop with nvidia drivers, this doesn't happen
<RoAkSoAx> bryceh: and it doesn;t matter if I connect it to one external monitors, or the two (via dualhead2go). Same result
<bryceh> when you connect to one monitor, is that through the dualhead2go device or straight thru?
<RoAkSoAx> bryceh: straight thru
<bryceh> in what manner do you turn off the LCD display?
<RoAkSoAx> bryceh: gnome-display-properties
<bryceh> hmm
<slangasek> pitti: heh, fontconfig is not the only package broken by cdbs+python-scour; atk is as well
<bryceh> alright, so most likely it's either a kernel (KMS) problem with drm or potentially gnome-display-properties
<slangasek> and I just broke it
<slangasek> (on powerpc, anyway)
<RoAkSoAx> bryceh: if I use my other laptop with nVidia proprietary or with nouveau, I don't experience this at all
<bryceh> RoAkSoAx, well, it is almost certainly something unusual about that particular laptop's vga port
<bryceh> RoAkSoAx, however that does tend to rule out bad edid I suppose
<bryceh> RoAkSoAx, here is what I would do to diagnose it a bit further
<bryceh> a.  reboot with the monitor attached, and verify the problem still occurs
<bryceh> actually
<RoAkSoAx> bryceh: (oh forgot to mention, this worked fine in Maverick) and I've done a. and the problem persists
<bryceh> a.  reboot with the monitor attached and lvds left on, you should not see the problem
<bryceh> b.  now use xrandr to disable the lvds (not gnome-display-properties)
<bryceh> c.  if the issue still occurs at this point, run 'ubuntu-bug xorg' and I'll take a look
 * RoAkSoAx on it now
<bryceh> RoAkSoAx, otoh if it does not occur when disabling the monitor using xrandr, then the bug probably should be filed against gnome-display-properties
<bryceh> although, in either case I suspect the root cause may be kernel kms drm driver issues, but probably best to start from userspace for diagnostic purposes
<bryceh> RoAkSoAx, if you can also post a Xorg.0.log and 'xrandr --verbose' output from when it's working *correctly* for comparison purposes, that'll probably help
<cjwatson> bryceh: FYI Andy's kernel/udev/plymouth/gdm/etc. suite of changes is on its way up now
<bryceh> cjwatson, awesome!  many bug reports are about to fall
<cjwatson> nvidia is still problematic I think, but I added plymouth:force-drm which lets people experiment with the plymouth drm driver again on nouveau
<cjwatson> can't speak for ati
<bryceh> I'll email AMD and let them know
<bryceh> -fglrx is still unreleased
<cjwatson> haven't yet touched kdm
<cjwatson> but it shouldn't break them
<RoAkSoAx> bryceh: yeah ut seens to be gnome-display-properties then as I disable with xrandr and external monitors work just fine with LVDS off
<bryceh> RoAkSoAx, ok good, that narrows it down nicely
<bryceh> RoAkSoAx, ok i think you have enough info to file a bug report against gnome-display-properties, and xrandr should give you a workaround for now, but feel free to let me know if you have any other questions
<RoAkSoAx> bryceh: awesome! Tha nks a lot for the help
<bryceh> cjwatson, ok AMD is notified of the change.  Hopefully they'll catch any issues in their testing
<ScottK> cjwatson: Is there something it would be beneficial to do for KDM?
<slangasek> ScottK: yes, kdm needs an update to adjust its upstart start condition (cjwatson just commented it in the bug)
<ScottK> slangasek: Which bug?
<cjwatson> ScottK: bug 702090
<ubottu> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking" [High,In progress] https://launchpad.net/bugs/702090
<ScottK> cjwatson: Thanks.
<slangasek> cjwatson: force-drm> so drm is now off by default?  I'm clearly out of the loop on plymouth; is there a refresher course available to get me up to speed on the current architecture / assumptions ?:)
<cjwatson> ScottK: should be something along the lines of http://paste.ubuntu.com/582287/
<cjwatson> slangasek: that's specifically for nouveau, and you were the one who turned it off :-)
<cjwatson> slangasek: bug 539655, for a refresher
<ubottu> Launchpad bug 539655 in linux (Ubuntu) "nouveau hard lockup in nouveau_gem_ioctl_cpu_fini" [High,Incomplete] https://launchpad.net/bugs/539655
<ScottK> Thanks.  Now to figure out if cmake is fixed yet.
<slangasek> cjwatson: oh, that :-)
<slangasek> ok, so it's only needed on nouveau, gotcha :)
<cjwatson> slangasek: I just wanted to make it run-time so that we could test fixes
 * slangasek nods
<cjwatson> (if any)
<debfx> cjwatson: do you know why component-mismatches says that kdesvn-kio-plugins needs to be promoted to main even though it is only an alternate dependency of kdesdk?
<cjwatson> debfx: because the primary alternative, kdesdk-kio-plugins, is uninstallable on armel at the moment (it's out of sync, which is presumably why), so germinate fails to resolve it and falls back to the secondary alternative
<debfx> cjwatson: ok, thanks for the explanation
#ubuntu-devel 2011-03-19
<psusi> god damn I love emacs!
<psusi> diff-mode for the winz
<psusi> worked up a patch the other day to add an argument to a signal upwer emits over dbus... decided to change it from a string to a uint today... open the quilt patch, scan the lines I changed, tap C-c on each that might need modified to jump to the code, make change if needed, rinse, repeat, finally quilt refresh.  patch converted in under a minute
<ScottK> cjwatson: kdm's uploaded.  Thanks for the patch.
<bdrung> smoser: i came to an different conclusion for bug #736326 ;)
<ubottu> Launchpad bug 736326 in txt2regex (Ubuntu) "typo in repetition subwindows" [Undecided,In progress] https://launchpad.net/bugs/736326
<smoser> bdrung, oh?
<psusi> if the current maverick version is 0.9.5-4, then backporting a fix would bump the rev to what?  ubuntu1, or ubuntu0.1?
<bdrung> smoser: fix it and make it sound better and then forwarding it
<bdrung> psusi: -4ubuntu0.1
<psusi> k...
<smoser> oh. sorry. i just assumed the bug opener spoke language.
<smoser> i do not.
<smoser> but yeah, forwarding to debian is correct, definitely. thank you.
<bdrung> smoser: his fix was correct. i only improved it further
<psusi> reason #768 that quilt patches applied in bzr branches are evil: merge goes all fubar over the .pc stuff
<bdrung> psusi: agreed. bzr and quilt are not a good couple
<psusi> bdrung, they are a perfectly good couple.. as long as you keep the patches deapplied in the bzr repo
<psusi> works great as long as you do that
<bdrung> yes, but the package imported commits then applied
<ScottK> All the more reason not to bother with UDD.
<psusi> yea, that needs fixed...
<psusi> half the packages I've been working on lately I guess someone sane manually set up the repo so they are deapplied, and the other half the auto importer imported them applied... bad auto importer
<ScottK> Apparently it was thought to be a feature at one point.
<ScottK> I think it's not accidental it works that way, but I gather it's being reconsidered.
 * psusi takes whoever thought so out behind the tool shed
<broder> i still argue that it makes sense given that the resting state of a 3.0 (quilt) package is patches applied. if you don't like what bzr is doing, you really should be taking issue with what the source format is doing
<ScottK> I do, but that horse is already out of the barn.
<bdrung> broder: it's a pita to look at patches and bzr diffs!
<ScottK> The only place I use v3 is where I use it due to orig.tar.bz2.
<bdrung> broder: all the changes to files in .pc ...
<psusi> broder, say what?
<bdrung> ScottK: v3 is cool. you can configure it to apply the patches at the beginning and drop then when finished building
<psusi> it is a pita to look at and adds useless bloat to have the quilt patches already applied in the repo
<ScottK> bdrung: I think the idea of starting with patches applied is completely backwards.
<broder> psusi: i've had this argument with you before, and in the interests of keeping the channel civil, i'm going to pass on having it again at the end of the day on a friday
 * psusi can think of few better times to have such an argument ;)
<psusi> I'm now reviewing my changes before pushing to lp, and the bzr -p output from the quilt-applied package is 3x larger and nearly unreadable compared to the deapplied one
<bdrung> broder: should we file a bug report requesting a change of the importer?
<broder> bdrung: i'm not making a point either way. i'm strictly pointing out that you guys are complaining about the current state, whereas i'm arguing that there are a series of very reasonable decisions that get you to this state
<broder> i'm also suggesting that you need to understand (even if you disagree with) those decisions in order to have a chance at coming up with a satisfactory alternative
<bdrung> broder: i understand that you imported the package like dpkg-source gives them you.
<bdrung> broder: you do use dpkg-source, aren't you?
<broder> presumably
<bdrung> you can give dpkg-source an parameter to not apply the patches and add 'unapply-patches' to debian/source/local-options
<broder> sure
<bdrung> then the patches are not applied in the branch and they will be applied when you build the source
<bdrung> bzr bd builds the package outside the branch. therefore 'unapply-patches' in debian/source/local-options isn't required
<broder> like i said, i don't actually feel like arguing about this right now, and haven't formed a well-thought out opinion on what the bzr importer in particular should do anyway
<broder> i didn't actually mean to hit-and-run comment, so sorry
<bdrung> broder: the question is where we should discuss this topic. in a bug report or on ubuntu-devel ML?
 * psusi things u-d
<psusi> thinks even
<broder> u-d will get more eyes
<bdrung> psusi: do you volunteer to write the initial mail? my bed needs me...
<psusi> bdrung, if someone else doesn't, I'm sure I will eventually, but I actually can't post to the list without moderation yet, so ;)
 * psusi really needs to get that motu application in
<bdrung> psusi: just subscribe to it and then you can post without moderation
<psusi> bdrung, I've been subscribed since like 2005.. a few years ago it went moderator and developer only and -discuss was created to be public
<bdrung> wow, really?
<psusi> lol... you didn't notice the reduction of noise? ;)
<psusi> I'm subscribed to both and post to both, but my posts to devel sometimes don't make it at all, and if they do, take days for moderation
<psusi> usually end up having a full conversation via the private Cc:s off list then a few days later, my replies finally appear on list
<bdrung> psusi: my first mail to ubuntu-devel was on 2009-10-19 according to my email archive.
<ScottK> bdrung: There's a UDD mail list that would be the best place to send it.
<psusi> ohh, heh
<psusi> there is?  hrm... I should get on that
<ScottK> The issue has been discussed before.
<ScottK> Yep.
<bdrung> ScottK: my suggestion: use dpkg-source with '--no-preparation' - that's what sponsor-patch does
<psusi> hrm... all of my mailing list folders won't fit on the screen anymore if I sign up for 2-3 more ;)
<ScottK> bdrung: Thanks.  I'll have to try that.
<psusi> at least I stopped drinking from the lkml fire hose
<psusi> ok... complicated situation here and trying to sort out what I should do with the control fields... bug fix involves changes to 3 packages: upower, g-p-m, and indicator-session.  indicator-session and g-p-m already depend on upower
<psusi> I'm thinking I should update those two depends to require the new version or greater, and add a Breaks: to upower for older versions of both upower and indicator-session, is that right?
<andersk> Why did ghc6 6.12.3-1ubuntu6 change the ABI hash of unix from 49642 to e3bae?  In any event, that means that all the rdeps of libghc6-unix-dev-2.4.0.2-49642 need to be rebuilt.
<Ampelbein> psusi: what does that bugfix do? does it change all 3 packages?
<Ampelbein> psusi: and why 'Breaks:'? Does installing upower prevent older indicator-session versions from running?
<psusi> yes, I have changed all 3 packages... I modified the dbus api between upower and g-p-m so that g-p-m will once again, properly lock the screen on suspend/hibernate.   I also removed the code that was added to indicator-session to lock the screen before asking upower to hibernate that was added I think as a workaround for the fact that g-p-m was broken and not doing it
<psusi> so basically you need to upgrade all 3 packages in lock step
<Ampelbein> psusi: ok, sounds like your plan is right.
<bwright> Is usb-creator-gtk part of the Ubuntu project or is it an additional third party app?
<cjwatson> ScottK: kdm> great, thank you
<cjwatson> pitti: how is it possible to recover from http://launchpadlibrarian.net/66694492/buildlog_ubuntu-natty-powerpc.atk1.0_1.33.6-0ubuntu3_FAILEDTOBUILD.txt.gz ?
<cjwatson> pitti: since atk1.0 is out of sync, libatk1.0-0 is uninstallable on powerpc
<cjwatson> pitti: cdbs Depends: python-scour Depends: python-rsvg Depends: librsvg2-common Depends: libgtk2.0-0 Depends: libatk1.0-0
<cjwatson> pitti: (this is bad for bootstrapping new architectures, too)
<slangasek> cjwatson: bug #734471; I think the quickest way to recover is to upload cdbs w/o the python-scour dep
<ubottu> Launchpad bug 734471 in cdbs (Ubuntu Natty) "cdbs python-scour dependency makes fontconfig unbuildable" [High,New] https://launchpad.net/bugs/734471
<slangasek> (and then readd it after, I guess, until a better solution is found)
<cjwatson> well, the bootstrapping problem will still be there
<cjwatson> I'll note that in the bug
<sabdfl> hello folks
<sladen> hello Makr
<Kre10s> I have a question about packaging. If a hardware manufacturer provides an open source driver... who is responsible for packaging it?
<Kre10s> Am I allowed to package it?
<Ampelbein> Kre10s: if the license allows redistribution, yes.
<Kre10s> should I just read the license or send the manufacturer an email?
<sladen> Kre10s: yes, of course.  Try packaging it and getting into a PPA ... check with #ubuntu-motu (Masters of the Universe) if you need help checking the licence to see if you're allowed to
<sladen> Kre10s: have you got a URL to the licence?
<Kre10s> hmm. i'll go get one.
<Kre10s> heres the product http://www.peak-system.com/fileadmin/media/linux/index.htm and it says "The complete package is distributed under the GPL." GPL being a link to http://www.gnu.org/licenses/gpl.txt
<Kre10s> so that means i can try packaging it!?!
<Kre10s> I want to package it because I'm using it allot, and its bothersome to constantly install from source.
<Ampelbein> Kre10s: yes, you are allowed to package and redistribute.
<Kre10s> apt-getting it would be sweetness
<cjwatson> while it's possible to package it independently, you should really ask them to get it integrated into the upstream kernel
<cjwatson> out-of-tree kernel drivers tend to be sadness, ultimately
<Kre10s> ah. because you have to compile it for all the different kernel versions.
<cjwatson> Kre10s: or, nowadays, use dkms
<cjwatson> but it's still better to have it integrated upstream
<Kre10s> agreed.
<bdrung> hi, does anyone else have bash completion problems in natty? Try "ls /de" and then press tab
<bdrung> you will get "ls /dev " instead of "ls /dev/"
<ankreloaded> bdrung: no mine is just fine
<Ampelbein> bdrung: works for me on natty/amd64
<bdrung> hm, maybe a configuration problem.
<bdrung> do you know how to restore the configuration files of a package?
<Ampelbein> bdrung: hmm, 'aptitude reinstall'?
<ion> bdrung: Try resetting your .bashrc.
<bdrung> Ampelbein: that doesn't bring the config files back
<Ampelbein> bdrung: 'aptitude purge && aptitude reinstall' should do.
<bdrung> Ampelbein: yes, that works (but not for every kind of package - non-leaf packages)
<bdrung> thanks for all your comments. purging and reinstalling bash-completion fixes my issue
<chrisccoulson> bdrung, have acroread installed by any chance?
<bdrung> chrisccoulson: yes
<chrisccoulson> bdrung, bug 716008
<ubottu> Launchpad bug 716008 in bash-completion (Ubuntu) "strange bahavior on directory completion with bash built-in commands" [High,Triaged] https://launchpad.net/bugs/716008
<bdrung> (due to a bug in evince)
<chrisccoulson> i guess i should reassign that
<chrisccoulson> the acroread bash completion file is screwed
<bdrung> good to know
<ScottK> slangasek: What's the issue with python-scour on powerpc?  It broke my kdebase-workspace (for the kdm upstart fixes) upload?
<psusi> cjwatson, ping, it's been 11 days since I made those minor cleanups you asked for in lp:~psusi/ubuntu/natty/parted/fix-dmraid and lp:~psusi/ubuntu/natty/dmraid/fixes
<Ampelbein> hmm, can you access staging.lp.net via the python api? I get an "unauthorized token" error when trying 'lp-shell staging'
<ScottK> Ampelbein: --> #launchpad, but I think staging was being retired.
<Ampelbein> ScottK: oh, it is? thought only edge was put down. well then, testing scripts on live system ftw ;-)
<Ampelbein> ScottK: thanks.
<ScottK> Ampelbein: Maybe.  Dunno.
<ScottK> In any case, ask #launchpad.
<cjwatson> psusi: thanks, I'll look at them on Monday
<cjwatson> ScottK,Ampelbein: staging isn't being retired as far as I know
<ScottK> cjwatson: Yes, I was confusing it with edge.
<cjwatson> Ampelbein: does https://lists.launchpad.net/launchpad-users/msg06239.html help?
<Ampelbein> cjwatson: I did that conversion already, it is working on production. just not on staging. I just wanted to know if anyone else has the same problem. 'lp-shell' works, 'lp-shell staging' doesn't. (lp-shell is in ubuntu-dev-tools)
<slangasek> ScottK: circular build dependency between cdbs and the GNOME library stack due to the added feature of cleaning up SVGs at build time (bug #734471); I'd been waiting for guidance from pitti here, but we seem to be blocking/breaking enough now that I'll upload cdbs to drop this dep today and unblock us
<ubottu> Launchpad bug 734471 in cdbs (Ubuntu Natty) "cdbs python-scour dependency makes fontconfig unbuildable" [High,New] https://launchpad.net/bugs/734471
<ScottK> slangasek: Thanks.
<slangasek> (and then as long as I have a window where that circular dep is out of the way, I can upload fontconfig for multiarch :)
<ScottK> Since I ping'ed you it also broke kdeedu.
 * slangasek nods
<ScottK> slangasek: Speaking of kdeedu, it looks like there's more GL in there than we thought (see 707794)
<slangasek> yep, saw your mail
<ScottK> OK.
<cjwatson> slangasek: (I noticed the atk1.0 side of that breakage because it broke plymouth and gdm builds, BTW)
<slangasek> cjwatson: right, I'll have a go at http://people.canonical.com/~ubuntu-archive/testing-ports/natty_outdate.html once cdbs is in
<Laney> oh, cdbs is broken?
<slangasek> Laney: on powerpc only; just fixed
<slangasek> publishing this hour
<Laney> yeah
<Laney> will look out for it to mash retry
<Laney> slangasek: or will you arrange a mass give-back?
<slangasek> Laney: if you're around and at liberty to poke at it, I'd be grateful for the help
<slangasek> I still have openjdk to try to tackle today
<Laney> sure, i'll just hit it in a little while
<ScottK> slangasek: Still seems brokenish.  I just retried kdebase-workspace on powerpc and got  cdbs : Depends: python-scour but it is not going to be installed
<ScottK> (that one would have failed anyway due to pkg-kde-tools, but that's a separate issue)
<slangasek> ScottK: I'm a muppet; I removed the build-dependency but not the dependency
<slangasek> so that's another hour wasted
<slangasek> fixing now
<ScottK> Thanks to that I discovered pkg-kde-tools needs fixing, so it's not a complete waste.
#ubuntu-devel 2011-03-20
<killown> there is a logical explanation of why OSS emulation was removed from ubuntu?
<micahg> slangasek: libtool can't seem to find .la files in the multiarch paths, I don't see a bug filed yet, is it on your radar or should I file a bug?
<slangasek> micahg: that's probably a bug in a build-dependency of whatever you're building, for having a non-empty dependency_libs referencing another .la file by absolute path
<slangasek> micahg: can you point me at a specific failure?
<micahg> slangasek: I was building the new gnome-chemistry-utils, I could pastebin the failure if you want
<slangasek> yes please
<slangasek> the thing is, even if libtool can't find .la files, it doesn't *need* them when building packages; so the bug is in whichever build-dependency carries the hard-coded path pointing at something which has moved
<micahg> slangasek: http://paste.ubuntu.com/582804/
<slangasek> micahg: the buggy reference is in libgtkglext1-dev, which should be fixed to clean out dependency_libs at build time; can you file a bug against this package?
<micahg> slangasek: yes
<slangasek> micahg: you can assign it to me if you like; the change required is simple, examples can be found in gnome-pkg-tools' clean-la.mk
<micahg> slangasek: I can give it a shot I guess
<micahg> slangasek: BTW, how were you able to tell which file was the issue?
<slangasek> micahg: apt-get build-dep $pkg; grep dependency_libs.*atk /usr/lib/*.la
<micahg> ah, ok
<nigelb> someone ask sabdfl to fix his connection :)
<micahg> slangasek: can I just include that file in debian/rules and add a build-dep on gnome-pkg-tools?
<micahg> oh, nm, that's a bad idea
<slangasek> micahg: I wouldn't because the package is not otherwise using cdbs or the gnome packaging style
 * cdbs is not being used
<slangasek> better to simply copy the command into gtkglext's install: target
<micahg> slangasek: ok
<cdbs> Looks like sabdfl is on an unstable connection. /ignore joins
<nigelb> someone k-line him :P
<cdbs> nigelb: well, the operator-way to that is to banforward to ##fix_your_connection, but he's an exception :)
<nigelb> cdbs: I know that
<micahg> slangasek: hmm, that just seemed to generate new hard coded paths
<slangasek> micahg: shouldn't, if you're running it after calling the upstream install rule
<micahg> slangasek: I added lines 9-16 here: http://paste.ubuntu.com/582808/
<slangasek> micahg: ah, the .la files aren't under debian/libgtkglext1-dev at this point, they'll be in debian/tmp instead
<micahg> slangasek: I was using debian/*/usr before and it didn't work either
<slangasek> (more exactly, they'll be in $(DTMPDIR))
<slangasek> hmm, really?  let me see
<sabdfl> weird
<slangasek> micahg: the use of $(wildcard) is wrong here; that causes the * to be evaluated when the install: rule is run, when what we actually want is for the shell to expand it when called.  i.e.: http://paste.ubuntu.com/582811/
 * slangasek waves to sabdfl 
<sabdfl> hey slangasek
<sabdfl> multi-arch greasing into the home base, I see!
<slangasek> yep :)
<sabdfl> well done
<slangasek> thanks!
<micahg> slangasek: do I need to worry about the second multiarch part?
<slangasek> micahg: I wouldn't worry about it, that's really something that whoever converts gtkglext for multiarch should take care of
<micahg> slangasek: got it, thanks, can I upload if it works?
<slangasek> micahg: certainly
<AnAnt> Hello, are gtk2 & gtk3 API compatible ?
<cdbs> AnAnt: not completely
<cdbs> AnAnt: There are migration guides on gtk.org
<cdbs> AnAnt: http://library.gnome.org/devel/gtk3/3.0/migrating.html
<AnAnt> thanks
<AnAnt> btw, which libs are installed by default in Natty ? Gtk2 or 3 ?
<debfx> ScottK: could you please ack bug #738647
<ubottu> Launchpad bug 738647 in maverick-backports "Please backport libeatmydata 26-2" [Undecided,New] https://launchpad.net/bugs/738647
<ScottK> debfx: Done.  Once it's backported it'll hit New, so feel free to ping me to review it there when it lands.
<ari-tczew> java on natty again is broken :/
<cyberix_> Is there a live system on the web that could be used to check ssl keys against the openssl-blacklist?
<debfx> ScottK: thanks, will do
<ManateeLazyCat> Hey, guys, i'm writing package manager, how to get all mirror list at https://launchpad.net/ubuntu/+archivemirrors ? I know i can click to get mirror address, but i wonder have a way get *all* mirror address directly?
<ManateeLazyCat> Thanks! :)
<Daviey> bdrung, Merge updated for ubuntu-dev-tools
<geser> any TB member available by chance to moderate my mail to the TB mailing list?
<cjwatson> geser: done
<bdrung> Daviey: someday i will extent sponsor-patch to work on syncs too
<Daviey> bdrung, yeah, i've never used sponsor-patch - but i did take a quick sniff at it..  I think i need to try it in anger before i can look to extend it. :)
<Daviey> bdrung,  it does look cleaner, my patch for ack-sync was really to get it working for a specific bug i was encountering.. and seemed a good idea to push it.
<bdrung> Daviey: half of ack-sync should be rewritten.
<bdrung> Daviey: sponsor-patch does the correct thing in many places. it ask when there are multiple tasks / patches. it ask to upload it and gives you links to lintian / build log
<Daviey> yeah.. i can see that.. It looks like some of the crap i'm currently working on...  Good proof of concept, but trash - rewrite and use it as a reference. :)
<bdrung> instead of rewrite, just extend sponsor-patch
<bdrung> ;)
<Daviey> bdrung, Well yes, that is what i meant :)...
<Eren> I've installed binary ATI drivers, 11.2. However, all the files are gone into /usr/lib/fglrx (including libraries, x modules, etc.)
<Eren> I've set module path to /usr/lib/fglrx on X, however, these modules in fglrx directory searches for libraries in /usr/lib/fglrx/
<Eren> unfortunately, setting LD_LIBRARY_PATH before "service gdm start" does not work
<Eren> there are similar problems on the net with workarounds, but these workarounds do not work as well, any ideas?
<Chipzz> Eren: try #ubuntu-x
<Chipzz> also, keep in mind that it's weekend
<Eren> Chipzz: thanks
<Eren> Chipzz: oh, yes :) I know it's more like a power-user question but wiki is old-dated imho
<Chipzz> Eren: and keep in mind that only packages are supported
<Chipzz> if you manually install drivers from ATI's site, you're on your own I think
<Eren> Chipzz: yep
<Eren> but X does not take "LD_LIBRARY_PATH" into account, this is the problem right now
<Eren> does that count?
<Chipzz> no
<Chipzz> because I doubt that LD_LIBRARY_PATH does what you think it does
<Eren> Chipzz: I see from Xorg.0.log that "dlopen: libatiuki.so.1: cannot open shared object file: No such file or directory"
<Eren> whereas, this file is present in /usr/lib/fglrx directory
<Chipzz> yes, but if X dlopen's the driver with an absolute path, LD_LIBRARY_PATH is not taken into account
<Chipzz> like I said, you may *think* LD_LIBRARY_PATH does sth it very likely does NOT
<Chipzz> anyway I'm not an expert on X
<Chipzz> so better ask on #ubuntu-x
<Eren> Chipzz: thank you
<slangasek> apw: has lool coordinated with you around the next gcc-4.5 upload?  we need at least one more upload before beta
<apw> slangasek, actually leann is in charge for the next few weeks, i am on vacation
<slangasek> apw: ah, ok
<slangasek> ogasawara: ping
<ogasawara> slangasek: hi, what's up
<ogasawara> slangasek: so when do you anticipate the gcc upload prior to beta?  just so I have an idea of when I'll need to re upload the kernel.
<slangasek> ogasawara: well, I had the impression from apw that he wanted a break from the gcc reuploads... I can probably get it uploaded today/tomorrow if that's ok
<mr_pouit> slangasek: hi, I've a strange ftbfs on amd64 with xfce4-settings (when preparing a new upload) because of dbus: "
<mr_pouit> oups
<mr_pouit> "/usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory"
<mr_pouit> it seems that the cflags don't include the correct -I
<mr_pouit> (probably related to multiarch)
<slangasek> mr_pouit: sorry about that - looking at it now
<mr_pouit> thanks! :) (I found in the .pc "-I${prefix}/lib/dbus-1.0/include" which should probably be "-I${prefix}/lib/x86_64-linux-gnu/dbus-1.0/include", but I'm not sure if my chroot is in good shape or not)
<slangasek> you're right, it's exactly that; I should have noticed the sed was wrong
<slangasek> heh, in fact the sed seems to be completely wrong now; it should just not change anything
<slangasek> ogasawara: (hi again :) well, I had the impression from apw that he wanted a break from the gcc reuploads... I can probably get it uploaded today/tomorrow if that's ok
<ogasawara> slangasek: ideally we didn't want to have to do any more uploads before beta freeze, but there's always exceptions.  if you can get it uploaded today or early tomorrow that'd be good.  Then I'll get a no-change upload of the kernel ready.
<slangasek> ogasawara: ack
<slangasek> mr_pouit: new dbus uploaded
<mr_pouit> slangasek: Nice, thanks for the fast response.
<slangasek> mr_pouit: n/p - please shout if you run into any other regressions
#ubuntu-devel 2012-03-12
<infinity> apw: Your kernel build's been rescued and should be happy soon.
<infinity> ScottK: Ditto with kdevelop.
<bkerensa> https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/952694
<ubottu> Launchpad bug 952694 in bluez (Ubuntu) "Toggling Bluetooth off also Disables Wifi Networking (Wifi Hardware Switched Off)" [Undecided,New]
<ScottK> infinity: Thanks.
<pitti> Good morning
<jalcine> Heh, it's very early over here :) almost 2 AM.
<pitti> dupondje: split needs an FFE bug, there we can review debdiffs etc.
<pitti> dupondje: if the -bin package doesn't change the boot process (that's the point of it), and it has proper breaks:/replaces, it's safe
<pitti> apw: do you know why these kernel modules on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt want to go to universe? apparently they are not covered by linux-meta?
<pitti> apw: it'd be a _lot_ easier to have all binaries in main
<pitti> mixed main/universe is a real dealbreaker for our current kernel SRU process, as PPAs don't have components
<pitti> geser: done
<vibhav> How Do I download a git patch?
<vibhav> (https://github.com/openstack/nova/commit/74396d58810e9851a6d33aef3dc3b2185154abcb)
<pitti> vibhav: github doesn't seem to support that directly; probably easiest to ctrl+mouse-mark the patch and paste it into an editor
<vibhav> thanks pitti
<vibhav> pitti: Is this fine then? http://paste.ubuntu.com/879972/
<pitti> vibhav: you need to remove the blank lines, but sure :)
<vibhav> Do I need to remove the identation too?
<pitti> yes
<vibhav> Is this alright now? http://paste.ubuntu.com/879974/
<webjadmin_> g'night
<vibhav> webjadmin_: Good night
<vibhav> pitti :Is this alright now? http://paste.ubuntu.com/879974/
<pitti> just try, patch will complain if it isn't :)
<pitti> vibhav: sorry, actually the initial indentation was correct
<vibhav> The earlier pastebin was right?
<pitti> yes, except for the empty lines
<pitti> vibhav: it needs to look like the web veiw
<vibhav> alright
<vibhav> patch: **** Only garbage was found in the patch input.
<vibhav> It aint working
<pitti> vibhav: probably easiest to just apply the changes manually; its' just a few changed lines after all
<vibhav> pitti: I dont know how to do that :(
<dholbach> good morning
<apw> pitti, universe/main> erm, i presume they are threatening to move as they are LBM and not supported?  what do you mean not coverered by linux-meta ?
<pitti> apw: shouldn't there be some metapackage to depend on the ABI specific binaries?
<apw> pitti, there cirtainly should be in all cases, though that report looks to be showing one
<pitti> apw: oh, hang on -- there are the corresponding linux-meta binaries
<pitti> apw: I suppose we should seed the linux-meta ones
<apw> pitti, isn't the second line there all the meta packages for the ones demoting in the first
<apw> pitti, ahh of course, the meta package has the release name in it
<apw> pitti, so it'll need changing each release, i expect you have -oneiric- in oneiric
<pitti> supported-kernel-common: * /^linux-(backports-modules-(headers|net)-oneiric-|headers-)?(386|cell|dove|ec2|generic|linaro-omap|linaro-vexpress|omap|omap4|armadaxp|powerpc|ps3|server|virtual).*/
<pitti> that's it
 * pitti fixes
<pitti> it doesn't have -cw, but I'll add that as well
<apw> pitti, thanks ... i'll poke leann to add 'get the seeds fixed' to the schedule when LBM comes alive in Q
<pitti> apw: I think I got it, will check c-m in an hour
<apw> pitti, thanks a lot
<vibhav> shouldn't the FTBFS part in the topic be in #ubuntu-motu?
<apw> is anyone else seeing delayes during boot; with a new plymouth message "waiting for network configuration" (approximatly)
<pitti> apw: other than bug 949891?
<ubottu> Launchpad bug 949891 in apparmor (Ubuntu Precise) "apparmor caching is not working which has severely regressed boot time" [High,Fix released] https://launchpad.net/bugs/949891
<dupondje> pitti: for cryptsetup, you prefer an extra package that just provides the bins (and conflicts cryptsetup) or a real splitted up package, where cryptsetup requires cryptsetup-bin ? :)
<pitti> dupondje: the latter
<pitti> cryptsetup-bin would then be in the default install
<pitti> and cryptsetup would be installed by d-i if you configure encrypted disk
<pitti> (just as right now)
<dupondje> will check :)
<pitti> a conflict is awkward and unnecessary
<apw> pitti, i updated just 10m ago, so i'd expect to have that fix no?
<pitti> apw: ah, then you should
<pitti> apw: kernel gone from http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<dupondje> most of ubuntu delta is also in debian now :) (became co-maintainer of it in debian)
<pitti> ah, nice
<apw> pitti, am seeing this on two machines, and was seeing it on sunday on one of them on a physically dysperate network
<pitti> dupondje: I was just going to say, this should be coordinated with Debian, so that we don't carry the package split as a delta
<apw> pitti, does anyone know what the message actually referes to, i've cirtainly never seen it on my network before
<pitti> apw: not off-hand, no
<apw> pitti, ok i'll update a test box and confirm it there (in this location) and file something
<dupondje> pitti: http://artemis.dupie.be/dupondje/cryptsetup.patch what you think? :)
<pitti> dupondje: needs a Breaks:/Replaces: cryptsetup (<< version_of_the_split)
<pitti> dupondje: also, wrt. package description, I think it is "command line", not "commandline"
<pitti> dupondje: I can't verify debian/rules just by looking, checking the binary debdiffs would be easier for taht
<pitti> dupondje: but it looks fine
<dupondje> was not final indeed :) will check to create a debdiff today
<dupondje> also i'll add another patch that fixes a critical bug (and is only 1 line ^^)
<dupondje> pitti: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/343363
<ubottu> Launchpad bug 343363 in udisks (Ubuntu) "gnome functional depends on cryptsetup, but not in package management " [Low,Triaged]
<dupondje> uploaded debdiff
<pitti> dupondje: thanks!
<pitti> dupondje: will you also push that to Debian?
<kiko> hey there
<kiko> anybody seeing weird font issues in the precise terminal?
<ogra_> kiko, only in my panel
<ogra_> terminals look fine here
<pitti> kiko: WFM
<pitti> kiko: be sure that anything that breaks gnome terminals will raise a rebellion here :)
<pitti> like bug 948612
<ubottu> Launchpad bug 948612 in vte3 (Ubuntu Precise) "gnome-terminal does not scroll with mousewheel" [Medium,Fix released] https://launchpad.net/bugs/948612
<Claudinux> hi all, if a menu isn't shwon in the application menu but is visible only if i start a session in gnome-shell, the bug should be opened for unity or for the application?
<geser> ogra_: like in bug #947059 or different issue?
<ubottu> Launchpad bug 947059 in unity-2d (Ubuntu) "Panel fonts are green and blurry" [Undecided,Confirmed] https://launchpad.net/bugs/947059
<ogra_> geser, same thing
<ogra_> and funny colored notifications
<geser> are you using the light theme or the dark one? as I see this only with the light theme
<ogra_> light here
<pitti> I'm using the bright theme (Radiance) and it's fine
<ogra_> havent cross checked with dark
<geser> pitti: unity or unity-2d?
<pitti> 3d
<kiko> pitti, can you help me debug? this is kinda driving me crazy
<kiko> pitti, what sort of settings or dotfiles might come into play?
<pitti> kiko: probably better if the unity-2d guys have a look, I wouldn't know where to begin :(
<kiko> pitti, for terminal?
<geser> kiko: can you upload a screenshot of your terminal somewhere?
<kiko> geser, pitti: http://www.async.com.br/~kiko/term.png
<kiko> geser, that's a mutt threaded view
<geser> and it worked before?
<kiko> geser, definitely worked in natty
<geser> looks interesting
<kiko> geser, it happens with rxvt and xterm too
<kiko> it doesn't happen with other apps that I can see: Ã§Ã¡Ã©
<kiko> so it's something to do with fonts. but what?
<kiko> lemme try and move .font* out of the way
<geser> do other programs, that use line drawing /boxes work?
<kiko> geser, in the terminal nothing works
<kiko> even typing directly into the bash prompt
<kiko> but say gvim works
<kiko> it's really only to do with terminals
<kiko> hmmm
<kiko> what's special about rxvt, xterm and terminal
<kiko> that makes it different from, say xditview or qtconfig-qt4 or chromium
<geser> does it work in the real console (outside X)?
<kiko> yes
 * kiko installs terminator to test
<kiko> good news is that apart from this precise is killer!
<kiko> fast
<kiko> on my nfs-root setup
<kiko> weirdly much faster in fact
<kiko> geser, also busted in terminator
<kiko> wtf
<kiko> pitti, by looking at my screenshot anything you suggest I could investigate?
<geser> it looks like mutt (and other apps emit utf-8 codes) but the terminal doesn't handle it
<geser> but I don't have an idea how to verify it
<dupondje> pitti: will be commited into debian, but maby there will be first a release with some bugfixes in debian, and then the split release.
<dupondje> I take care we have no delta for Precise+1 :)
<kiko> I think I know what's wrong
<kiko> geser, locale lists everything as POSIX
<kiko> found the issue
<kiko> export LANG=en_US.UTF8
<kiko> how was this being set before I wonder
<ogra_> kiko, /etc/default/locale
<jalcine> kiko: perhaps via the environment?
<jalcine> or in a .bashrc file?
<kiko> yeah
<pitti> kiko: err, a locale setting causes the screen corruption?
<pitti> kiko: oh, the mutt one; yes, that's likely
<pitti> dupondje: that sounds fine
<dupondje> pitti: you'll sponsor it? I subscribed ubuntu-release.
<pitti> dupondje: yes, can do
<scott-work> cjwatson: good morning!  i have added my casper.log file to bug# 923810
<scott-work> bug #923810
<ubottu> Launchpad bug 923810 in casper (Ubuntu) "preseeding passwd/user-default-groups is ineffective" [Medium,Fix released] https://launchpad.net/bugs/923810
<scott-work> i was also wondering if anyone can point me in a direction to look or talk about unreadable ubiquity installer text ala bug #952462?
<ubottu> Launchpad bug 952462 in Ubuntu Studio "Ubuntustudio 12.04 installer has unreadable text" [Undecided,Confirmed] https://launchpad.net/bugs/952462
<scott-work> interestingly, this only affects the installer when choosen from the first menu, if the user lets the live FS come up and then chooses to install either from the applications menu or the "install" icon then the text appears normally
<ScottK> kenvandine and/or pitti: Is someone working on getting the farsight/farstream mess worked out?
<pitti> I assigned it to kenvandine
<pitti> ah, he's online now
<pitti> kenvandine: ^ RSVP
<kenvandine> hey pitti
<kenvandine> i was just reading that bug report
<pitti> kenvandine: bug 952136
<ubottu> Launchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/952136
<pitti> kenvandine: not a good thing to upload library changes on a Friday evening :/
<pitti> kenvandine: I was wondering, is there a particular reason for the libraries to conflict?
<pitti> kenvandine: even when switching papyon to farstream, it'll still cause apt to have a hard time during upgrades
<kenvandine> because they both provide the same gstreamer plugins
<pitti> ah
<kenvandine> we should make papyon get removed i think
<pitti> kenvandine: that ought to be a Breaks: then
<kenvandine> telepathy-butterfly isn't really supported upstream
<kenvandine> upstream switched to haze
<kenvandine> i'll do that
<pitti> kenvandine: i. e. add a Breaks: python-papyon somewhere?
<pitti> plus removal bug plus seed fix?
<kenvandine> is it seeded?
<ScottK> Is there an alternative for MSN support?
<ScottK> It's seeded in Kubuntu.
<pitti> kenvandine: something pulls it into Kubuntu, so I guess yes
<kenvandine> well actually we don't want to break papyon
<ScottK> That's what broke the Kubuntu images over the weekend.
<pitti> kenvandine: you need to Breaks: it if you want it removed in upgrades
<pitti> and if we keep papyon, the libraries can't conflict
<kenvandine> or make papyon depend on the new one
<pitti> right
<kenvandine> assuming it works
 * kenvandine checks with upstream
<ScottK> papyon seems pretty widely used "Task: ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active, edubuntu-desktop, edubuntu-usb, edubuntu-desktop-kde"
<pitti> python-papyon is kubuntu and edubuntu-desktop-kde only
<kenvandine> the only rdepends is telepathy-butterfly
<ScottK> OK.
<kenvandine> which telepathy will completely ignore now even if it is installed
<pitti> right, and it seems ubuntu uses something else than butterfly for MSN
<ScottK> Right.  Stale cache.
<kenvandine> it uses telepathy-haze now
<pitti> kenvandine: then it seems we can just as well remove the package and breaks: it?
<kenvandine> assuming the rdepends is accurate
<kenvandine> i am surprised it was seeded directly
<ScottK> pitti: Except then we lost msn support in the KDE telepathy stack (AIUI)
<kenvandine> ScottK, telepathy-mission-control-5 switched to haze for MSN
<kenvandine> and internally it migrates all the settings
<pitti> ScottK: is libpurple too heavy for kubuntu?
<kenvandine> they effectively blacklisted butterfly/papyon
<ScottK> pitti: I don't know.
<kenvandine> because it was breaking nearly weekly
<pitti> ah no, libpurpose is alreayd on kubuntu
<pitti> err, libpurple
<kenvandine> hehe
<pitti> so adding -haze shouldn't be a problem
<ScottK> I really don't know the telepathy stuff at all.
<jml> I just distupgraded and lost
<jml> *ahem*
<jml> I just dist-upgraded and lost unity.
<ScottK> The only reason I'm caring at the moment is kenvandine's upload on Friday broke our image builds.
<Riddell> pitti: oh really?  I wonder what that's for
<ScottK> Riddell: Do you understand how the telepathy stuff runs together well enough to figure the best path forward here?
<pitti> Riddell: http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/desktop.depends
<Riddell> oh it'll be telepathy-haze
<pitti> Riddell: telepathy-haze is already on the kubuntu images
<dupondje> msn worked fine this weekend :D
<Riddell> ScottK: what's the issue?
<pitti> so it seems we just need to drop -purpoe
<kenvandine> the haze/buttefly depends stuff changed a couple weeks ago
<pitti> err, t-butterfly
<ScottK> Riddell: See backscroll here.
<seb128> jml, will teach you to dist-upgrade and ack without reading? ;-)
 * pitti mutters "precise-proposed"
<Riddell> ScottK: I have, not worked out what the issue is yet :)
<Riddell> farsight/farstream ?
<jml> seb128: yeah, I guess.
<ScottK> Riddell: Yes.
<ironm> hello. May I ask one question, please? Why do I need an invitation for the #ubuntu-live channel? I have found some issues with live-builder on ubuntu 11.01 or 12.04 (server) but can't report them anywhere. I am looking for current documentation how to create live images on ubuntu.
<ironm> thank you in advance for any hints
<ScottK> Bug #952136 is why our builds broke over the weekend.
<ubottu> Launchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/952136
<kenvandine> they really conflict, but the question is does kubuntu really need papyon
<kenvandine> nothing rdepends on it
<kenvandine> besides telepathy-butterfly, which won't work anymore anyway
<Riddell> kenvandine: what's papyon ?
<ScottK> Riddell: kenvandine and pitti are suggesting getting rid of papyon is the right answer, but I don't know what else would provide msn support then.
<kenvandine> the msn library that telepathy-butterfly uses
<pitti> kenvandine: I suppose not, but we still need something to breaks: it, to get it cleaned up on upgrades
<jml> except there are only so many giant walls of text I can deal with in a given day, so I'll probably make the same mistake again
<pitti> ScottK: telepathy-haze does, which is already in K
<kenvandine> so it should be safe to drop it from the seed
<ScottK> OK.  So then the question is doe that work with telepathy KDE?
<Riddell> ScottK: for kde-telepathy?  I expect libpurple through telepathy-haze does but I can check
<Riddell> and kopete uses libmsn
<seb128> jml, stop using command line tools and use update-manager?
<ScottK> Riddell: Thanks.
<pitti> jml: actually, see bug 930217
<ubottu> Launchpad bug 930217 in Launchpad itself "Make proposed pocket useful for staging uploads" [Low,Triaged] https://launchpad.net/bugs/930217
<pitti> jml: if we get that, we can avoid temporary breakage like that
<ScottK> ironm: I suspect #ubuntu-installer is the channel you think you're looking for.
<pitti> jml: so if you happen to know a LP manager who can bump this... :-D
<jml> pitti: thanks.
<ironm> thank you very much ScottK  :)
<Riddell> kenvandine, ScottK: upstream kde-telepathy say telepathy uses telepathy-haze which uses libpurple
<kenvandine> ok, so it doesn't need to be seeded
<Riddell> kenvandine: he says farsight has something to do with video/audio support which isn't yet in kde-telepathy so it's not an issue for us (might be for empathy I guess)
<kenvandine> empathy already switched
<kenvandine> so we're good
 * kenvandine  is figuring out the right package to add the breaks too
<kenvandine> it got removed from my box on dist-upgrade
<kenvandine> i guess because of the farstream changed
<pitti> kenvandine: if apt can figure it out, that's ok
<pitti> kenvandine: but a single conflicts: in a library is usually relatively hard to get over
<pitti> without a replaces:/provides or a breaks: on the app package layer
<kenvandine> pitti, this is why we put it in the ubuntu-desktop ppa for a week first, to see if this caused any problems
<kenvandine> i guess the best place would be in telepathy-mission-control-5 since it is effectly what removed butterfly support
<pitti> kenvandine: yes, that sounds good
<kenvandine> but technically farstream is what breaks papyon :)
<ScottK> So can butterfly and papyon be removed entirely?
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: stgraber
<henrix> pitti: ping
<pitti> henrix: hello; please don't ping, just ask your question
<henrix> pitti: i've been waiting for a while for the oneiric (and -lts) kernels to be promoted to -proposed
<henrix> pitti: herton told me the right thing to do is to ping one of the arch admins...
<pitti> hm, I thought I did them all on Friday
<henrix> pitti: i guess not :)
<pitti> right, hit after my EOD on Friday
<pitti> ack, will do
<henrix> ok, no prob. i was just wondering whether there was something wrong.
<pitti> henrix: all done
<henrix> pitti: thanks!
<kenvandine> pitti, ScottK:  i talked to the debian maintainer, he says he thinks the current farstream conflicts is enough
<ScottK> OK.
<kenvandine> nobody reported any upgrade problems while it was in the ppa
<kenvandine> and i just did a dist-upgrade in a VM and it did the right thing
<ScottK> Right, but how many Kubuntu users use the PPA?
<kenvandine> so i think we are fine as is
<ScottK> OK.
<pitti> kenvandine: well, that's not an indication, as nobody using the PPA ran kubuntu apparently
<kenvandine> true
<kenvandine> but nothing in kubuntu actually depends on it
<kenvandine> just the seed
<pitti> our auto dist-upgrade testing has some kubuntu support, though
<pitti> kenvandine: ok, so this just needs testing; if the dep gets dropped from k-desktop, it should work as well as in ubuntu
<kenvandine> i think so
<kenvandine> is someone fixing that?  or should i look at kubuntu-desktop?
<kenvandine> pitti, ^^
<pitti> kenvandine: the seeds? please do
<kenvandine> ok, will do
<pitti> thanks
<ScottK> So it looks like the path to papyon for Kubuntu is kde-telepathy -> telepathy-butterfly -> python-papyon.
<kenvandine> ScottK, and nothing should pull in telepathy-butterfly anymore, haze replaced it
<ScottK> Right.  I can fix that.
<kenvandine> and it won't be installable
<ScottK> Looking now.
<Riddell> if telepathy-core drops telepathy-butterfly then it won't be on the kubuntu images any more
<Riddell> or ubuntu desktop or anything else
<Riddell> job done
<kenvandine> it still needs to be removed from the kubuntu-desktop seed though
<hallyn> the auto-quilt-pop-push in bzr merge is making for hard to review merges...
<hallyn> is there something better than 'bzr diff' and 'bzr st' to show what actually changed?
<hallyn> oh it didn't reapply them
<Riddell> kenvandine: it's not in the kubuntu-desktop seed
<kenvandine> ah, great~
<ScottK> Riddell: telepaty-butterfly provides Provides: telepathy-connection-manager
<kenvandine> i thought pitti said it was
<kenvandine> then i don't need to worry about it :)
<ScottK> That's why it's getting pulled in.
<Riddell> the only thing in the seed is kde-telepathy
<ScottK> which depends on telepathy-connection-manager
<Riddell> if that ends up with telepathy butterfly installed then indeed there is another problem somewhere
<ScottK> What else provides that?
<kenvandine> telepathy-gabble
<kenvandine> haze
<kenvandine> etc
<kenvandine> should
<Riddell> dunno, ask whoever maintaines telepathy
<ScottK> Haze does
<ScottK> We have that already.
<ScottK> Riddell: I think I know how to fix it.
<Riddell> so demote telepaty-butterfly and job done
<kenvandine> that is a good idea
<ScottK> kenvandine: Is there any reason not to just remove it?
<kenvandine> nope
<kenvandine> telepathy wouldn't use it even if it was installed
<kenvandine> so yeah, we can do that too
<ScottK> pitti: ^^^ Would you kill telepathy-butterfly, source and binary?
<cr3> pitti: I see you packaged postgresql, do you think that postgresql-plpython should have an actual meta package instead of a purely virtual one? the latter prevents me from specifying a dependency like postgresql-plpython (>= 8.4)
<ScottK> kenvandine: telepathy-gabble and telepathy-haze both provide telepathy-connection-manager.  Is one preferred?
<kenvandine> no
<kenvandine> different services
<kenvandine> gabble is jabber (including gtalk and facebook)
<ScottK> Riddell: It's also a package back in the meta-kde-telepathy package to only depend on a virtual package.  It should depend on realpackage | virtualpackage to avoid these kinds of problems.
<Riddell> aah
<ScottK> back/bug
<Riddell> ScottK: file a bug and ping me if you need packages removed
<ScottK> OK.
<Riddell> assuming it's a package I care about :)
<ScottK> First I'll fix meta-kde-telepathy.
<pitti> ScottK: removing
<ScottK> Thanks.
<pitti> and sync-blacklisted
<pitti> cr3: as the server-side extensions are version specific, it usually doesn't make too much sense to depend on an arbitrary one
<cr3> pitti: how can I express something like this then: postgresql (>= 8.4), postgresql-plpython (>= 8.4)
<cr3> pitti: even though the extension are version specific, the package depending on it might not now the specific version :)
<cr3> s/now/know/
<cr3> pitti: the only workaround I can think of would be to branch my project for each version of Ubuntu, which would seem unfortunate just because of postgresql-plpython :(
<pitti> cr3: how about Depends: postgresql (>= 8.4), postgresql-plpython
<cr3> pitti: I'll give that a try, thanks!
<cr3> pitti: worked like a charm, thanks!
<pitti> cr3: to be _really_ correct, you'd also need to require that server and plpython are of the same version, but that's hard to express with dependencies
<cr3> pitti: yeah, I do that within my own packages, like (= ${binary:Version}), but I wouldn't know how for external packages
<ScottK> pitti or Riddell: Bug #953061
<ubottu> Launchpad bug 953061 in papyon (Ubuntu) "Please remove papyon (source) and python-papyon (binaries) from precise" [Undecided,New] https://launchpad.net/bugs/953061
<pitti> doing
<ScottK> Thanks.
<lamont> http://paste.ubuntu.com/880433/ <-- d-r-u got lost on run 1, the second run I get this
<infinity> lamont: You might need to manually install at least libc6*, libstdc++*, libgcc*, libapt*, and apt_* from /var/cache/apt/archives. :/
<infinity> lamont: Things getting wedged halfway through can end badly for apt, if it's at just the wrong time.
<infinity> lamont: (And if any of those is actually unable to install/upgrade, bug reports plox!)
<lamont> yeah - working thruogh it now
<henrix> pitti: sorry to bother you again, but it looks like something went wrong during the upload
<henrix> pitti: take a look at comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949882/comments/2
<ubottu> Launchpad bug 949882 in Kernel SRU Workflow "linux: 3.0.0-17.30 -proposed tracker" [Undecided,In progress]
<m_3> mhall119: please ping me if you get a chance... I'd like help with summit production configuration
<infinity> henrix: Will fix.
<henrix> infinity: thanks for taking a look at it
<mhall119> m_3: ping
<m_3> mhall119: hey
<m_3> mhall119: so let me spin up a fresh stack of summit/postgresql/memcached
<infinity> henrix: Hrm.  Those meta packages appear to have always been in universe.
 * infinity will look again in a sec.
<henrix> infinity: interesting...
<pitti> henrix: I promoted all pacakges to main, are these comments a bit misleading?
<pitti> henrix: I. e. do they actually say "the package is in main, but should be in universe"?
<infinity> pitti: Did you?
<pitti> henrix: that's known; we can't do PPA copies and fix the components at the same time
<pitti> henrix: so I'm usually waiting for replies like this, and then fix them up individually
<infinity> pitti: Unless you just did (like, since the last publisher run), all these packages from linux-meta are still in universe.
<pitti> oh, I didn't override linux-meta
<infinity> pitti: But, it also seems like they always have been.
<pitti> since when does _that_ need overriding?
<infinity> linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.16.19 | oneiric-security/universe | amd64, i386
<infinity> linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.16.19 | oneiric-updates/universe | amd64, i386
<infinity> linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.17.20 | oneiric-proposed/universe | amd64, i386
<infinity> ^-- For example.
<infinity> pitti: It needs overriding when new backport packages are added.
<infinity> pitti: New is new is new. :P
<infinity> pitti: And it looks like the first time the -cw-3.2- stuff was added, it went to universe, and no one complained until now.  I guess.
<pitti> meh; pretty please let's stop mixing components for the kernel; it's a PITA
<infinity> pitti: We don't.
<pitti> they should all be in main really
<infinity> pitti: It should all be in main.
<infinity> pitti: But LP punts new packages to universe, and some AAs are lazy? :P
<infinity> pitti: AFAIK, everything from linux, linux-backports-modules, and linux-meta is meant to be in main.
<stgraber> can't we get regexp based component overrides? sounds like it'd help quite a bit with the kernel
<pitti> ok, overriding
<infinity> stgraber: There's a bug open to just change the automagic logic.
<pitti> henrix: fixed the overrides, thanks
<infinity> stgraber: It's my contention that new binaries should default to the same component as their source.
<stgraber> infinity: that'd make sense indeed
<pitti> +1
<infinity> stgraber: And others seem to agree.  But no one's bothered to fix it.  Was this you volunteering? ;)
 * pitti needs to reboot urgently, brb
<henrix> pitti: great, thanks. i'm just looking at the irc backlog to understand what happen...
<pitti> henrix: for hardy and lucid it's almost guaranteed that we'll get this kind of mail, and I'll fix it once we get it
<pitti> henrix: (just so that you aren't scared in the future)
<henrix> pitti: thanks :)
<henrix> pitti: i *was* scared actually :)
<geser> pitti, cr3: would it be even possible at all to specify a dependency on matching postgresql-plpython and server? given that several postgresql clusters can exists in different versions and it's possible that postgresql-plpython is only installed for one specific postgresql version and not the others
<pitti> geser: it's a nice academic exercise
<pitti> depends: (postgresql-8.4, postgresql-plpython-8.4) | (postgresql-9.1, postgresql-plpython-9.1)
<pitti> and then do the usual boolean transformation to rewrite this in conjunctive normal form
<herton> pitti, infinity, about component mismatches, we got on Lucid as well, because of the preempt packages (bug 947375). Well this one is the problem that on lucid not everything goes on main for this case
<ubottu> Launchpad bug 947375 in Kernel SRU Workflow "linux: 2.6.32-40.87 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/947375
<stgraber> infinity: not volunteering just yet but might end up having a look next time I get hit by it (usually when doing netinstalls) :)
<pitti> herton: oh, this sets the task to "incomplete", fixing my canned search to include this
<herton> pitti, I could change it back to confirmed, if you want
<herton> pitti, I mean, change the bot to do it instead of using incomplete
<pitti> herton: fixed my canned search, but thanks
<henrix> pitti: i got the same comment again on LP...
<pitti> henrix: it needs about half an hour up to an hour to get effective (needs a publisher run)
<henrix> pitti: ah, right. since the promote-to-proposed had changed to fix release, i though it was solved already
<henrix> pitti: but it went back to incomplete again. anyway, i'll wait :)
<pitti> henrix: well, I close it as soon as I fix the overrides
<pitti> I don't wait for a publisher
<herton> pitti, I'll change the bot to delay the check, 1 hour of delay should ensure things to be published?
<pitti> it's a hard enough process already :)
<pitti> herton: yes, 1 hour is guaranteed to be enough
<pitti> herton: publisher runs at :03 and :33 I believe
<herton> ok cool
<pitti> herton: cheers
<pitti> mvo: I'd appreciate a look from you at bug 950676; it does look like an apt problem, but it might be possible to add some dependency "hints" to work around it?
<ubottu> Launchpad bug 950676 in apt (Ubuntu Precise) "lucid->precise upgrade failure due to gir1.0->gir1.2 conflicts" [High,New] https://launchpad.net/bugs/950676
<mvo> pitti: will do, I'm curently on bug #940396
<ubottu> Launchpad bug 940396 in apt (Ubuntu Precise) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396
<pitti> mvo: ah, thanks; not that urgent, just if you could have a look in the next days
<pitti> queue a tab in firefox or so
<mvo> pitti: thanks, adding it now
<dupondje> When dh_installinit is executed in debian/rules. and there is an upstart file, does it start on all runlevels?
<pitti> henrix, herton: the checker seems to be wrong for omap4, see bug 950572
<ubottu> Launchpad bug 950572 in Kernel SRU Workflow "linux-ti-omap4: 3.0.0-1208.18 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/950572
<pitti> dupondje: upstart doesn't have it's own concept of runlevels; it'll start as soon as the "start on" condition is true
<pitti> dupondje: "start on" might say "on run levels 2 to 5"
<herton> pitti, I think it should have gone to main originally, as all linux-ti-omap4 packages were on main previously (for natty and maverick)
<pitti> herton: I agree; but that doesn't help us now, as oneiric release has it in universe
<herton> pitti, so couldn't it be moved to main on updates/proposed? But ok, I can add an exception for it, it this can't be done
<pitti> herton: it could, but in general we try to avoid changing components after release
<pitti> herton: e. g. linux-tools-omap4 might have a dependency on another universe package
<pitti> which wuold break if we promote it to main
<pitti> herton: I had assumed your script compares it against the component in the release, but seems not; is that a hardcoded mapping in your script?
<herton> pitti, depends, by default it checks the component on release, but for ti-omap4 it's a hardcoded enforce to be on main
<cjohnston> m_3, mhall119; mhall119, m_3    :-)
<m_3> cjohnston: thanks!... we've been PMing
<m_3> cjohnston: how would you like to handle the linuxplumbers theming?
<m_3> we can branch ubuntu_website and modify the template there
<cjohnston> m_3: thats probably what will heppen
<cjohnston> happen
<m_3> do they want to go with the ubuntu theme?
<m_3> ah, ok
<cjohnston> no.. we are going to use a plumbers theme...
<cjohnston> they can have the ubuntu theme for now tho
<cjohnston> i still havent gotten complete instructions
<dupondje> What trigger should be used in upstart to run on shutdown (after disks are umounted)
<m_3> cjohnston: ok, well maybe I can just pass it as a config param for the charm... i.e., the theme/site branch
<m_3> defaults to ubuntu_website
<cjohnston> ok
<m_3> currently set to http://bazaar.launchpad.net/~ubuntu-community-webthemes/ubuntu-community-webthemes/light-django-theme
<herton> pitti, I see here that linux-ti-omap4 were released originally on main actually: http://pastebin.ubuntu.com/880527/
<infinity> herton: Yes, but not linux-tools-omap4, which is from -meta.
<cjwatson> pitti: the publisher doesn't actually always quite manage to run every half-hour, as sometimes it overruns its slot; one hour is *usually* enough, I just wouldn't like to say "guarantee"
<stgraber> seb128: I'm looking at https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_quicklist/+merge/94170 just now, the submitter did the changes you requested and it looks good to me. I just wanted to check with you that it's indeed ok to upload this change at this point in the cycle as it's essentially adding new translatable strings
<herton> infinity, oh right, nevermind
<seb128> stgraber, hey, it's ok, we will warn the translators soon about the ones which got added in a batched way
<herton> pitti, infinity, I'll just fix the script to not enforce everything on main, the tools are on universe on maverick and natty as well
<herton> *not enforce everything on main for ti-omap4 meta
<pitti> cjwatson: ah, thanks; anyway, probably good enough for the checker scripts
<stgraber> seb128: ok, I'll make the upload then, unless you have a totem upload coming up soon?
<seb128> nothing planned so feel free to upload
<herton> pitti, infinity, fyi, this is the class which checks the components:  ktl/check_component.py, used by  stable/check-component and the bot (from git://kernel.ubuntu.com/ubuntu/kteam-tools.git)
<m_3> cjohnston: let's set up a walkthrough on managing the summit stack using the charms... I'm just waiting on info about which ec2 accounts to use, and then I'll be ready to go over it with you.
<cjohnston> ok
<stgraber> cjwatson: could you hardcode lxc in the ubuntu-server packageset? it tends to get out of it pretty often (as it's not actually seeded on any of the server seeds but it's definitely actively maintained by the server team)
<stgraber> (I just added it again manually but I suspect it'll be dropped next time the script runs)
<jamespage> micahg, around? can we discuss the native/non-native packages on the zentyal/ebox packages?
<micahg> jamespage: sure, I"m heere
<cjwatson> stgraber: yeah, please don't change the automatically-maintained package sets manually :)
<jamespage> micahg, sweet - so I just read your comments on bug 928501
<ubottu> Launchpad bug 928501 in ebox (Ubuntu) "Precise will ship totally broken ebox packages" [High,Confirmed] https://launchpad.net/bugs/928501
<cjwatson> stgraber: I've added an exception for it now (which has caused it to drop out of edubuntu, incidentally)
<micahg> stgraber: the source has dropped to universe for precise, is that intentional?
<stgraber> cjwatson: thanks
<jamespage> micahg: upstream don't ship tarballs; they release packages and only for ubuntu
<stgraber> micahg: yes, nothing in main depends on it and it's not seeded by anything but edubuntu at the moment
<jamespage> which was the thinking behind sticking with the native format - rather than switching to 3.0 (quilt) and adding in an extra step
<micahg> stgraber: i.e. do they not want it "officially" supported
<stgraber> micahg: it probably should be seeded by server though but that's a discussion for the server team to have :)
<tumbleweed> jamespage: is the Ubuntu pcakaging going to be maintained in their VCS branches?
<micahg> Daviey: ^^
<jamespage> tumbleweed, yes
<stgraber> micahg: I think we want to officialy support it and we kind of do, I'm all for an MIR + adding to at least supported seed. I remember the security review being a problem last time it was attempted though
<stgraber> micahg: hallyn would know more
<micahg> jamespage: yes, but as it's not an Ubuntu specific thing in the sense that it's tied to our archive in some way, I'd think they should really release tarballs or use bzr snapshots, but there should be an upstream tarball as they're an upstream of Ubuntu
<micahg> stgraber: ah, well, I don't want to increase security headaches ;)
<Daviey> stgraber: why would we seed something like this?
<micahg> jamespage: s/bzr/vcs/
<Daviey> jamespage: we don't want this in main do we?
<jamespage> micahg, I'm not seeing how its NOT an Ubuntu specific thing? maybe I'm missing something
<jamespage> Daviey, no
<Daviey> ahh, two discussions happening concurrently
 * Daviey switches on SMP.
<micahg> jamespage: it's Ubuntu specific in that they develop for Ubuntu not that it's inherently tied to Ubuntu
<stgraber> Daviey: I'm talking about lxc, not ebox :)
<infinity> I think lxc absolutely should go through the MIR dance and be supported.
<infinity> If for no other reason than it's the only way to approximate "virtualisation" (and I use the term loosely) on ARM.
<hallyn> stgraber: micahcg: sorry, i can't follow the above :)  when the otehr issues are done being discussed, pls ping me and re-ask
<Daviey> infinity: does qemu not work on arm? :)
<infinity> Daviey: Full emulation, sure, no paravirt.
<Daviey> infinity: Have you been tracking the work kvm and xen are doing to work on arm?
<infinity> Daviey: So, if you want a bunch of VMs that run at the speed of a TI graphinc calculator, you're set.
<m_3> mhall119: dude... Daviey has a custom manage command that'll work http://pb.daviey.com/MTUs/
<m_3> mhall119: can probably make that work for prepopulating menus too
<infinity> Daviey: kvm and xen paravirt on ARM will only happen for A15 cores and beyond.  The hardware support just ain't there in current hardware.
<micahg> jamespage: for instance if Debian or Fedora wanted ebox, from what I've read in that bug, the upstream developers would welcome patches
<jamespage> micahg: hmm
<mhall119> m_3: that would work for superuser
<mhall119> I think think it's better for us to make the code not crash when there isn't a menu (or summit)
<m_3> mhall119: well... ok :)
<micahg> jamespage: again, this is only for the distro packaging, for their own packaging purposes, they're free to use 3.0 (natiive)
<tumbleweed> jamespage: also, native packages make no separatino between packaging and upstream. Unless all developers who have upload rights for the packages have commit rights on their source branches (and exercise them), they're likely to get out of sync
<micahg> jamespage: and with source format 3.0, the upstream debian dir is ignored IIRC, so they don't conflict either
<jamespage> micahg, tumbleweed: so its really a) we fork the packaging and got with 3.0 (quilt) and have to merge each new upstream release in as we would do
<micahg> jamespage: yep, same as any other upstream :)
<jamespage> or b) we risk holding a delta over upstream by sticking with 3.0 (native)
<tumbleweed> a hard to manage delta
<micahg> I see b as wrong from the distro perspective which is why I mentioned it in the first place :)
<jamespage> micahg, I guess the challenge here is that upstream are also the maintainer of the packages...
<jamespage> hence adding in a step to switch the format of the packaging seems like extra work
<micahg> jamespage: but they're not as they're not Ubuntu developers (and we don't have maintainers in Ubuntu :))
<micahg> they're the upstream developers who may in time get upload rights to their packages
<tumbleweed> it's really not that big an extra step. It's trivial to add a tarball generating rule to debian/rules
<Daviey> tumbleweed: Yes, you'd think we'd know that, right? :)
 * tumbleweed has an (I beleive fairly rational) hatred of native packages :)
<Daviey> Seriously, this should not require so much consideration
<tumbleweed> that too
<infinity> It's easily handled with VCS branches.
<infinity> I used to maintain telepathy-glib upstream, Debian, and Maemo, and it was all just git branches of the same thing, with different debian directories plopped on top.
<infinity> The fact that "upstream" was also the maintainer in two distributions was handy, but not an argument for native packaging.
<dholbach> one day we'll have a world without tarballs
<infinity> (In fact, it maintained my sanity to have the debian-less upstream source be the "base")
<Daviey> native packages are policy compliant, i see their limitations, but really, why create extra work?
<infinity> dholbach: Meh, a tarball is no different from an upstream tag in a VCS.  You still want a snapshot of a released state.
<Daviey> it's upstream maintaining this, lets be flexible, but within policy
<infinity> dholbach: (And, in fact, Nokia's internal build system for Maemo created orig.tar.gzs out of thin air from git tags)
<infinity> Daviey: Oh, I don't care if people package natively.  But a project that seems open to being used in places other than Ubuntu might want advice on how best to do that, and native maintenance isn't it.
<infinity> Daviey: I imagine that's what micahg was driving at.  I hope.
<Daviey> right, and when that happens, let them switch the package to quilt
<dholbach> infinity, the current tarball + patch system + vcs world is very far from my ideal world :)
<infinity> dholbach: I don't mind it too much, except when people forget that the archive is authoritative because they live in a fantasy world where the VCS is. :P
<micahg> Daviey: infinity: yes, but I believe it's disingenuous to use 3.0 (native) for something that's not developed specifically by Ubuntu developers for use in the Ubuntu archive
<infinity> dholbach: (The Maemo "releases are tags" thing kinda fixed that for them)
<Daviey> micahg: currently that is the case.
<dholbach> infinity, if everything was all just branches, merging from each other would be a lot easier :)
<Daviey> micahg: If you want to take on the work to switch it, please do.
<infinity> micahg: native doesn't imply origin, it's an unfortunate name.
<micahg> and also, another argument is that it makes them always think about the packaging vs upstream difference which is important for distro uploaders
<micahg> infinity: it doesn't, but it makes sense from a distro perspective to use it that way
<micahg> Daviey: and as has been pointed out lp:ubuntu/foo will be the authoratative packaging branch regardless, it would seem to make sense to enforce that at a packaging level by using 3.0 (quilt)
<Daviey> micahg: great, please prepare the patches.
<micahg> assuming it's up to date
<infinity> micahg: The authoritative packaging branch is "apt-get source ebox". :P
<infinity> micahg: Anything else is a delusion.
<micahg> infinity: yes, well, that's why I said if it's up to date :P
<Daviey> (for now)
<infinity> (A delusion people are trying to make a reality, but until it all works right, I'm sticking with my statement)
<micahg> Daviey: I've got a few other things I'm working on at the moment, but it should just be a matter of generating an upstream tarball and switching the debian/source/format content, I know there are links somewhere on how to generate an upstream tarball from a VCS
<cjwatson> scott-work: nothing reconfigures jack at boot on ubuntustudio live systems - I guess we want that to happen?
<cjwatson> (923810)
<scott-work> cjwatson: yes please
<Daviey> micahg: dude, we know that.. but if you feel that is how it should be done, please do it.
<Daviey> (and liase with upstream)
<jamespage> micahg, Daviey: I'm really concerned that we are putting in place a barrier between Ubuntu and this upstream project
<jamespage> that we don't really need to have in place
<Daviey> right
<micahg> jamespage: Daviey: I don't think I should be obligated to fix something that's not even in the archive yet in order to have it follow sane packaging requirements
<Daviey> micahg: requirements ?
<Daviey> micahg: Are you suggeting ntive is anti-policy?
<micahg> that barrier is that there's a difference between upstream and distro developement
<micahg> Daviey: in this type of scenario, I think it is
<infinity> micahg: There isn't right now.  If they start accepting patches to work on other distros, there will be a difference between upstream and distro.
<infinity> micahg: For now, native, while perhaps not entirely correct, isn't entirely incorrect either.
<infinity> micahg: And it's trivial to change from native to non-native later.
<micahg> infinity: there is as we might patch things at the distro level that "upstream" never needs to see including SRUs
<infinity> micahg: I tend to agree with you on what I prefer to see, but it's not that meaningful in cases like this.
<micahg> infinity: I think it matters when people are trying to patch things
<infinity> micahg: Meh, we do SRUs of other native packages that often never need to go in the latest devel release.  I don't see the difference.
<jamespage> I also think we have an upstream project who will want to know about SRU updates
<jamespage> their entire product is based on Ubuntu...
<micahg> infinity: it's a pain to patch a native package especially when the last "patch" needs to be removed
<infinity> micahg: It... Is?
 * cjwatson patches native packages all the time; if it's hard you're doing it wrong
<infinity> micahg: Apply change, dpkg-buildpackage, done.
<infinity> micahg: It's arguably easier to patch native packages, not harder.
<cjwatson> (perhaps by mistakenly believing that patch systems are a good idea when applied to native packages)
<micahg> infinity: cjwatson: well, you're both AAs and seasoned developers, am I wrong to be taking such a strong stance against this?
<infinity> micahg: I think that, as long as they continue to target only Ubuntu (and it's a pretty specific set of tools), the point is kinda moot.
<pitti> I haven't followed the whole discussion, but why would we consider ebox a native package? because there's no upstream any more? (zentyal now)
<infinity> micahg: I agree with you that if/when they target other distros, they should perhaps branch packaging seperately from "upstream source", but I can't see how it matters one way or the other right now.
<infinity> micahg: I, personally, would have an upstream/distro division if it was my project, and obviously you would too, but if they literally ONLY release to Ubuntu right now, that's the definition of "native".
<pitti> i. e. they don't release at all, and don't have their own VCS, etc?
<infinity> micahg: And it's asking them to do extra busy work to do upstream release tags/tarballs/whatever if they don't actually do "upstream releases".
<micahg> infinity: to enforce the upstream/distro packaging difference?  it's easy for the "upstream" branch to get out of sync
<infinity> pitti: They have their own VCS, but AFAIUI, they only "release" to Ubuntu, not with "upstream releases".
<pitti> so if they have their own VCS and development, it's not a native package
<infinity> pitti: Err.
<micahg> infinity: also, someone's going to have to get some type of tarball from them to upload, they're not Ubuntu devs, so what does it matter if that is an .orig.tar.gz or a .tar.gz?
<tumbleweed> if they also plan to release to a PPA for older ubuntu releases, it' squite likely that there'll be times when the PPA packages will need to be different to current ubuntud dev release
<infinity> pitti: There are any number of native packages (or have been in the past) in Debian that don't use {cvs,bzr,arch,git,svn}.debian.org
<pitti> infinity: that's not what I meant
<infinity> pitti: The location of one's VCS doesn't define your release style, it's where you release to (in their case, the Ubuntu archive, not upstream tarballs)
<pitti> infinity: if they actually _use_ lp:ubuntu/ebox as their development trunk, it'd be native
<micahg> infinity: and in fact from their perspective, the tarball won't make a difference regardless of that source format in the archive (unless packaging changes are needed)
<pitti> if they have their own git or whatnot somewhere, then that his the trunk, and it can't conceptually be a native package
<infinity> pitti: Well, that was kinda my point.  Them not using UDD branches doesn't define how they're releasing.
 * infinity shrugs.
<pitti> infinity: it's not just about releasing (although _if_ they release tarballs, then that certainly matters), it's also how they develop
<pitti> and if their trunk can be different from our package, then it's not native, IMNSHO
 * micahg hugs pitti
<infinity> pitti: So, before UDD, nothing was native?  Or when UDD branches happened, any native package that didn't immediate switch all development work to that branch was wrong?
<infinity> (Hint, we have a few)
<pitti> infinity: I'm not speaking about UDD here; you can replace lp:ubuntu/precise with "apt-get source ebox"
<infinity> And while the UDD machinery keeps them magically in sync, sometimes that breaks.
<pitti> I just mean "whatever is in Ubuntu"
<infinity> pitti: Ahh, then yes, AFAIK, 'apt-get source ebox/precise' matches their latest released version.
<pitti> but anyway, I stated my opinion; it's apparently not unanimous, so I guess I STFU again and continue bug fixing :)
<infinity> pitti: Since they only release it to Ubuntu.
<infinity> pitti: That was sort of my point. :P
<pitti> infinity: so if they change something, they apt-get source, change, upload?
<pitti> that's certainly a very strange project indeed
<maxb> Perhaps the way to express it is "It is native if the VCS branch used for upstream development and the VCS branch used for uploads to Ubuntu are the same branch" ?
<infinity> pitti: No, they change it in their VCS and upload.  Just like half the native packages we ship.
<pitti> ok; that certainly is weird
<pitti> but I guess they can get away with a native package then
<jamespage> pitti, if you consider the project I don't think it is - its entirely based on Ubuntu
<infinity> I don't see it as any different from how we do kernel development, or some installer bits, or, or...
<infinity> The only argument here is that they're not devs, so they can't upload themselves, and somehow that's giving people hissy fits.
<infinity> But the development model is identical to how we do plenty of our own native packages.
<pitti> kernel is not native, FWIW, and it would certainly wrong for it to be
<pitti> but I see what you mean
<infinity> pitti: It often is, during development cycles, and flips non-native for release, actually.
<pitti> but d-i is inherently a distro thing, while ebox isn't
<infinity> pitti: Have you looked at ebox?
<infinity> pitti: It's wildly distro-specific right now.
<pitti> infinity: a few years ago, yes
<pitti> not recently
<pitti> frankly, I considered its concept quite broken back then, but that might have changed
<infinity> It's not inherently so, in that it could be extended to work with others, but no one's doing that work.
<infinity> I'm not a fan of it either, that's out of scope for this. :P
<micahg> infinity: it's more than they're not devs, it's that while they're work is based on Ubuntu and for Ubuntu, it's not Ubuntu in that's it's not developed as part of the project for the archive
<infinity> micahg: It is when you start uploading their for-the-archive releases to the archive? :P
<micahg> s/they're/their/
<infinity> micahg: There seems to be some chicken and egg issue there.
<micahg> infinity: no, distro-specific != native to the project
<infinity> I disagree.
<infinity> If it's distro-specific and in the archive, it's native.
<infinity> Unless, as you claim you're not, you make the distinction based on the identity of the uploader.
<infinity> s/uploader/changed-by/
 * infinity shrugs.
<infinity> Colin was smart enough to pretend not to have an opinion when asked.  I might do the same and go back to work. :P
<jamespage> well if you look at 'changed-by' most updates in the last 2 years have been done by ebox/zentyal guys...
<jamespage> just as sponsored uploades
<scott-work> cjwatson: please let me know if i can help with anything
<micahg> I'd posit that regardless of what you're targetting, what matters is where the development is done, the development for ebox is done as part of the ebox/zentyal project, not the Ubuntu project
 * scott-work realizes this is a pretty feeble offer
<dupondje> Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?
<infinity> micahg: I think that's again splitting hairs, if all releases are meant to be released to the Ubuntu archive, where the development "happens" doesn't matter to me.
 * micahg is thinking of adding an item to the TB agenda if they're not dealing with more important issues
<infinity> micahg: All the development for my latest native upload happened on my hard drive.  Totally not an Ubuntu-blessed VCS.  And it was part of my own "flip bits on my hard drive until a package comes out" project.
<infinity> (Which was successful, by the way, I'm a wizard with tiny magnets)
<micahg> infinity: I'm not referring specifically to the VCS location either
<infinity> micahg: The only difference at all between me and them is that I didn't need to beg a sponsor to bless my upload.
<infinity> micahg: As an added point, my latest native package actually could be used on any system with upstart, probably.  So it's even less valid as native than theirs is, but no one challenged it when I uploaded. :P
<infinity> micahg: And, if I decide to convert it to something I could upload to Debian, then I'd un-native it, and do some upstream/distro split.
<infinity> micahg: But as long as it exists in exactly one distro, and every change has been targetted at release to that one distro, that's perfectly valid as native.
<cjwatson> scott-work: shouldn't be desperately hard, just rsyncing a current image
<micahg> infinity: while I agree that defines it as native to Ubuntu, I don't agree that stuff in the archive should be like that :)
<infinity> broder: Pingaling.  I understand you have a lintian lab you might be able to let me play with (or play with on my behalf)?
<infinity> broder: I need a broad grep -r of */debian for armel, so I can go through with a fine-toothed comb and make sure any armel tweaks/etc have been applied to armhf.
<scott-work> cjwatson: well, my offer is not all philanthropical ;) , i'd like to learn whatever i can as well :-)
<ScottK> infinity: One in particular to look for is !armel specifications in debian/control.  I've been doing amd64 i386 powerpc instead for awhile knowing armhf was coming.
<infinity> ScottK: Anything .*armel.* needs looking at, really.
<ScottK> infinity: True, I just know there are !armel incantations around that are buggy.
<infinity> Most of them are probably incorrect for armel too.
<cjwatson> scott-work: it needs testing, but it's probably http://paste.ubuntu.com/880708/ in casper
<cjwatson> or something along those lines
<slangasek> Riddell: any news about soprano testing?
<slangasek> ScottK: when you say that the farsight transition is fixed, that doesn't seem to encompass python-papyon being transitioned to python-farstream... did these packages simply get removed from the Kubuntu dependency stack?
<ScottK> slangasek: The solution for python-papyon was removal.
<ScottK> (from the archive)
<ScottK> There's probably more that could be done to progress farsight/farstream, but the thing that was breaking the image builds is resolved.
<dupondje> Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<slangasek> ScottK: oh, now I see; somehow I thought empathy was being removed rather than upgraded, but apparently no
<scott-work> cjwatson: thank you!
<scott-work> cjwatson: i presume that this will properly configure jack in the liveFS which in turn will yield an installed FS which also is configured correctly, am i misunderstanding this?
<Riddell> slangasek: oh sorry, soprano is all good
<Riddell> did I fail to say that on the bug?
<slangasek> Riddell: ah, apparently :)  no worries, I'll upload now - thanks!
<broder> infinity: i've been stalling on actually setting things up so i can give other people access, but i think it's actually time for me to come up with a real solution. give me a little while to come up with something
<infinity> broder: Sure.  If it's too much hassle, I'm happy with just the output of the above greppination.
<infinity> broder: But being able to give access based on ssh keys from LP or something would be shiny.
<broder> infinity: yeah, i've been meaning to set that up, and as of the last few weeks, i think we've crossed the threshold where it's more work for me to keep ad-hocing it for people than setting it up so i can use ssh keys from LP
 * infinity just got the evil idea to write a launchpad->userdir-ldap import/sync shim.
<infinity> Some days, I don't like myself.
<infinity> This is one of them.
<broder> have to say, it is slightly irritating that i can just grab /+sshkeys but can't get it through the lp api anonymously
<infinity> broder: Well, I suppose it's a potential information leak, since ssh keys are often in the form user@host.
<broder> infinity: yeah, but https://launchpad.net/~broder/+sshkeys is accessible without authenticating
<infinity> broder: Oh, it is?
<infinity> Nevermind, then.
<infinity> It's obviously broken in one direction or the other. :P
<broder> maybe i shouldn't make too much fuss about it or someone might fix it the wrong way :-P
<infinity> I'd probably be inclined to go that way, yeah.
<infinity> Given that you can't see people's email addresses without being logged in, the potential disclosure issue in ssh public key comments is similar.
<ajmitch> ssh-import-id sort of relies on it being publically accessible, doesn't it?
<infinity> ajmitch: It does, yes.
<infinity> ajmitch: Though, it could certainly be rewritten to be a launchpadlib application that requires authentication.
<infinity> I'm not sure I care deeply, mind you.
<infinity> But I don't really care about that level of disclosure in general.
<infinity> People still wonder why I don't obfuscate my whois records and such.
<cjwatson> scott-work: it does both separately, hence the separate casper-bottom and ubiquity-hooks scripts - the installed system starts by copying the squashfs contents, not by copying the live session
<broder> the problem with making it a lplib application is that i now have to put my lp credentials on my server for it to be useful
<infinity> broder: That's where my ud-ldap/launchpad shim idea comes in.
<scott-work> cjwatson: okay, that makes more sense looking at the pastebin, thank you :)
<infinity> broder: Since ud-ldap does central processing, then pushes bits out to machines, you wouldn't need to have credentials anywhere but that one spot.
<broder> infinity: ah, sure. but ewww, ldap
<infinity> broder: Meh.  ud-ldap's ldap part could be repaced by anything, really.
<infinity> broder: It's the ssh triggering or passing around nss-db bits (and keeping machines entirely independant of network failures) that's shiny.
<infinity> s/or/of/
<kirkland> infinity: no, please no....requiring lp authentication would break many (most?) ssh-import-id use cases
<kirkland> broder: I didn't catch your use case, sorry, but would ssh-import-id suffice for what you want to do?
<broder> kirkland: not entirely. i wanted to create separate accounts for each person i was handing out access to
<kirkland> broder: accounts where?  in a cloud instance?
<broder> kirkland: personal server
<kirkland> broder: sudo adduser && ssh-import-id?
<broder> pretty much what i did
<kirkland> broder: ;-)
<gang65> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<ScottK> gang65: What's up?
<gang65> bug #410262
<ubottu> Launchpad bug 410262 in xserver-xorg-video-openchrome (Debian) "[VX800]openchrome hangs when the mouse cursor is inside of a image in gimp" [Unknown,Confirmed] https://launchpad.net/bugs/410262
<gang65> two patches was send instead of one
<gang65> 100_fix_xaa_display_issues.patch is correct
<gang65> 101_xaa_solid.patch is wrong
<gang65> It causing the system hangs
<infinity> Given how long that bug's been open, I'm thinking it doesn't warrant use of the emergency broadcasting system. ;)
<ScottK> infinity: The fix is rather more recent.
<infinity> ScottK: Yes, but it's only in -proposed, is it not?
<ScottK> infinity: No, it's in updates
<infinity> Oh, indeed.
<infinity> I missed that.
<ScottK> It's been there for a week, so there's probably no point in blocking it now, but it should be addressed.
<infinity> Oh, no question that it should be fixed.
<infinity> Just that it doesn't appear world-endingly incident-report-needing.
<ScottK> bryceh: Can you look into this oneiric-proposed regression ^^^
<ScottK> infinity: Usually they aren't unless they affect you.
<infinity> ScottK: Well, it looks like it might just be trading one hang for another. ;)
<ScottK> infinity: Someone will need to start an incident report and all that stuff too.  Can you drive?
<ScottK> Dunno.
<infinity> ScottK: I'd prefer someone closer to the issue (ie: bryceh) do the reporting.
<infinity> He's in a better position to tell if it's actually necessary, and what steps should be taken.
<infinity> (And I was about to head to lunch)
 * ScottK is at EOD.
 * ScottK looks for maybe slangasek.
<ScottK> He should be on that alert too.
<infinity> Normally, I probably should be too.  No idea who to talk to about mangling it.
<slangasek> mangling what?
 * mneptok perks
<infinity> Either way, I'm not sure about the severity of this one, reading through the logs.  It seems the upload solved problems for some, and possibly caused problems for others.  If removing that one patch makes it work for everyone, yay, but I don't think things are "worse" now, just "different".
<infinity> slangasek: The regression-alert thingamajig.
<gang65> The main problem with this bug is that two patches was pushed:
<slangasek> oh, the bot output?  I don't know
<ScottK> slangasek: In any case we need someone to drive this regression alert to ground and I'm EOD and infinity is just about to leave.
<infinity> gang65: I see that.  You also reported that it worked for you, though.  Can you reproduce the hang that the other reporter is seeing?
<ScottK> I think it's mostly hunting down Bryce and making him look at it.
<gang65> yes I could reproduce this
<infinity> gang65: Ahh.  The bug log isn't clear on that point.
<infinity> (hint)
<gang65> And Thomas Schlichter also
<infinity> Anyhow, I have to run out for 30 minutes.
<slangasek> gang65: can you confirm whether or not precise is affected?
<scott-work> cjwatson: is line #17 correct in http://paste.ubuntu.com/880708/ ?
<slangasek> bryceh: around?  Seems to have been a regression in the recent openchrome SRU ^^
<scott-work> should it include a pair of parenthesi ?
<gang65> @slangasek No. Precise is not affected (it has a new openchrome version)
<udevbot> Error: "slangasek" is not a valid command.
<slangasek> gang65: ok, thanks
<Q-FUNK> ev: it appears that whoopsie leaves an obsolete config from early releases.
<broder> Q-FUNK: i'm confused. i added a bluez.maintscript that should be cleaning up the conffile...
<Q-FUNK> broder: apparently, it doesn't work as intended.
<broder> grr
<broder> ok, looking
<bryceh> slangasek, I'm off today.  Does it need solved now or can it wait?
<bryceh> slangasek, probably should just revert both patches to be safe
<slangasek> bryceh: I imagine it can wait until tomorrow; the SRU was published a week ago and the regression is just now coming to light
<bryceh> slangasek, I had sru'd them under the belief that the patches were well tested and safe; since it appears that's not the case, it's not worth having as an sru
<slangasek> bryceh: the second patch is reported to not be upstream at all, the first patch is confirmed by two users to improve things?
<slangasek> (including the user reporting the regression)
<bryceh> slangasek, well the trouble is that VIA hardware for testing openchrome is rather rare (I haven't got any), so validating changes is especially tough
<slangasek> it seems there are at least two users available to test, which meets the SRU criteria
<bryceh> slangasek, well I'm thinking this might be one of those self-selecting cases
<bryceh> i.e. people who have the bug test...  but if the patch breaks people that have different hardware, we won't get those test results until it goes out live
<bryceh> which presumably is what happened here
<slangasek> no, gang65 who tested the SRU was also able to confirm the regression afterwards; so this particular one wasn't an issue with differing hardware
<slangasek> the regression was just a corner case he didn't test initially
<bryceh> hmm, ok.  does the upstream patch alone fix it?  iirc some commenters said only with both patches did the original issue go away
<slangasek> as far as I understand the bug log, yes, the first upstream patch is sufficient
<slangasek> actually, now I'm doubting
<slangasek> since the regression reported by Thomas Schlichter is simply that the original bug was not fixed
<bryceh> slangasek, see last few comments on http://www.openchrome.org/trac/ticket/402
<slangasek> so I can't understand how gang65 both confirmed the regression, *and* correctly verified the fix in the first place
<bryceh> yeah, it's a bit confusing
<slangasek> ok
<slangasek> muddled history, not actually a regression (just a case of the bug not really being fixed); so not urgent at all
<bryceh> slangasek, okie.  shall I still keep it on my todo list to look at tomorrow?
<slangasek> bryceh: that would be appreciated
<bryceh> will do.
<broder> cyphermox: are you still possibly uploading bluez soon? i've spotted the bug in my change
<broder> (just want to check if we're going to step on each others' toes)
<broder> Q-FUNK: spotted the bug - i screwed up the version number when i call dpkg-maintscript-helper
<Q-FUNK> broder: that would explain it. :)
<broder> Q-FUNK: i had the upload prepped, and then discovered that cyphermox had already uploaded bluez, so i had to merge his changes in and forgot to update it
<broder> so if you had upgraded from 4.98-2ubuntu1 instead...:)
<Q-FUNK> broder: do you actually need to specify the last applicable version though?
<broder> Q-FUNK: it's not strictly necessary, but it makes sure that the migration code only runs once
<chilicuil> hi there, I'm trying to test if an app is completly translated in the latest ubuntu release, I do have a chroot environment (pbuilder) with it, how can I make it?, I know that the package is not complety translated, since I've it in ubuntu oneiric, I'd like to translate what's left, I've tried to branch the lp:pkg branch with no sucess, and the lp page https://launchpad.net/ubuntu/+source/klavaro has the "translations" link grayed out
<dupondje> Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it?
<slangasek> kenvandine: hi, are you planning to follow up on the farsight->farstream transition so that we're not left carrying around an obsolete source package in universe for precise?
<slangasek> dupondje: what is it you're trying to accomplish by integrating this into the upstart jobs?  That's a high risk change that I think is clearly not appropriate for a post-FF change
<slangasek> dupondje: all of our filesystem teardown in 12.04 is still being done via sysvinit
<dupondje> slangasek: now we have 4 init scripts for cryptsetup. Would like to only use upstart for it.
<dupondje> and not for FF btw, but for Precise+1 :)
<slangasek> well, we use init scripts for the teardown because we use init scripts for all the fs teardown
<slangasek> so any changes there need to include the big picture
<dupondje> Thats getting changed or ?
<slangasek> there aren't any plans about changing it yet
<Nisstyre> Why hasn't Ubuntu added a "python2" symlink to "python" yet?
<dupondje> Ok, cause its a bit dirty imo to have 4 scripts for 1 'service' :)
<dupondje> I'm thinking for some ways to make it bit cleaner
<slangasek> Nisstyre: because /usr/bin/python is already assured to be python2, so adding that symlink would just encourage creating unportable scripts
<Nisstyre> slangasek: it would make them more portable according to pep 394
<jtaylor> that pep is not accepted yet
<Nisstyre> since "python" will invoke the python 3 interpreter on some systems
<Nisstyre> fair enough
<slangasek> on what systems?  Any system using 'python' to refer to python 3 is horribly broken
<slangasek> and pep 394 offers no clean upgrade path
<Nisstyre> slangasek: Arch Linux as well as Gentoo in the future
<slangasek> really?  broken
<Nisstyre> slangasek: it's not manditory that python should refer to python 2
<Nisstyre> *mandatory
<Nisstyre> It would be nice if there were something that could work across all major distros, such as "python2"
<broder> Nisstyre: it would be nice if distros like Arch and Gentoo didn't arbitrarily go breaking every Python script in existence
<infinity> Until very recently, that thing was 'python'...
<dupondje> slangasek: would it for example be possibel to add 'stop on runlevel [016]' to the upstart? This would emulate the same as the current init script does?
<slangasek> dupondje: definitely not
<jtaylor> oh interesting pep 394 was accepted recently
<dupondje> myea no sequence number :(
<slangasek> dupondje: right.  also, the jobs are tasks, so they're stopped as soon as they finish, so 'stop on' won't help :)
<dupondje> so I guess there is not really a more clean way then the current situation?
<slangasek> dupondje: yep, not really
<slangasek> not without significant changes to the shutdown
<dupondje> 'to the shutdown' as in upstart you mean then?
<slangasek> dupondje: I mean a systematic transition for /etc/rc6.d
<dupondje> now finding a clean way to patch this in debian :) so we can sync in the future
<doko> Nisstyre, slangasek: "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions". so no, it won't point to python3 in Ubuntu
<Nisstyre> doko: Sorry if I wasn't clear. I never said Ubuntu should point python to python3
<dupondje> anyway slangasek thanks for the info :)
<infinity> doko: I think that was already well-established, he was saying that we should also have python2 pointing to python2.7
<jtaylor> which it already does in precise btw
<slangasek> oh, does it really?
<doko> yes
<slangasek> doko: when this was discussed last on debian-python, wasn't it agreed that it was a bad idea to provide this?  Is it there now because the PEP has been approved?
<infinity> Oh, it seems upstream was changed to provide the python->python2->python2.7 link chain.
<jtaylor> I think the opinion was its a bad idea but if the pep gets accepted it will go in
<infinity> Nisstyre: So, there you have it.  It does what you want.
<Nisstyre> infinity: thanks for the information then
<doko> slangasek, I never thought it would be a bad idea, but some people did want to have the pep formally approved
<slangasek> doko: right
<slangasek> doko: fwiw I don't think it was a good idea either, but we might as well go along with it :)
<broder> it's good that, after the python community went through all the trouble of separating out the backwards-incompatible changes, they've decided to open the door for making a backwards-incompatible change
#ubuntu-devel 2012-03-13
<cyphermox> broder: go right ahead.
<pitti> Good morning
<vibhav> pitti: Hi
<pitti> hello vibhav
<pitti> dupondje: NB that the cryptdisks package split patch is missing some things, working on it
<Daviey> #launchpad-redsquad
<Daviey> oops
<dupondje> pitti:  what did I misss?
<pitti> dupondje: just sent updated patch to the bug, and uploaded
<pitti> dupondje: thanks!
<vibhav> DO I need to report a bug for attaching a typo fix patch?
<pitti> vibhav: depends on what package, but usually that's better for coordination, yes
<dupondje> pitti: I see, just tought to keep cryptformat in the cryptsetup package, as this would not be used by people that just want to mount their crypted dev
<pitti> dupondje: with the GUIs available it's indeed largely obsolete these days
<pitti> but still nice on a server
<pitti> dupondje: but yes, the location of that is certainly debatable
<pitti> dupondje: but the cryptsetup manpages were in "cryptsetup" and should be in the same package as the binary, i. e. -bin
<dupondje> you mean ./usr/share/man/man8/cryptsetup.8.gz
<dupondje> ?
<pitti> yes
<dupondje> weird, I builded it yesterday, and that one was in the bin package .. :)
<dupondje> You mean luksformat.8 maby?
<dupondje> pitti: anyway thx for the upload. I'm the first happy user of the -bin package :D
<pitti> dupondje: hah, so I'm the second :)
<pitti> I have it installed now, and tested successfully with palimpsest
<dupondje> thats great. Having laptop here where I sometimes open an external drive that is crypted. No need for the whole cryptsetup package now to just open it :)
<dupondje> anyay bbl
<mealstrom> hi, can you tell me how .ICEauthority is created and management? Ive got a lot of problems with it using nfs server to store home directories.?
<mealstrom> or how system checks that file? when saying "Could not update ICEauthority"
<dholbach> good morning
<vibhav> hi
<brendand> mealstrom, that often tends to mean that the home directory cannot be accessed in some way
<brendand> mealstrom, i've had it in the past when i've used encrypted home and there've been bugs in ecryptfs
<pitti> jibel: bonjour
<pitti> jibel: I believe you still have a workaround in the dist-upgrader for iodbc?
<pitti> jibel: could you please drop this, so that we can check that the fix works now? (it was uploaded yesterday)
<jibel> pitti, guten morgen
<jibel> pitti, yes, I've seen your upload yesterday, I'll reinstall the package
<pitti> jibel: thanks
<jussi01> mvo: We are having a conversation about different meta packages on the kubuntu-devel list, and we want to get several meta packages added to app install data. WHat do you need from me apart from a list of packages?
<jussi01> Riddell: ^^
<jussi01> ;)
<henrix> pitti: hi! me again... i still can't see the latestest version of the oneiric kernel when i run "rmadison --arch=source linux"
<henrix> pitti: i guess there's something wrong with the upload to -proposed
<pitti> henrix: indeed, seems the copy-proposed-kernel command failed somehow
<pitti> re-running
<henrix> pitti: thanks
<pitti> https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<pitti> seems someone deleted it from -proposed
<pitti> henrix: it's pending again, I copied it back
 * pitti fixes overrides
<henrix> pitti: that's odd. anyway, thanks again
<henrix> pitti: are you still looking at this? i just refreshed https://launchpad.net/ubuntu/+source/linux/+publishinghistory and see 'deleted' again
<pitti> not any more, the change-override is done
<pitti> and now that page times out
<henrix> cool
<pitti> well, not cool
<pitti> WTF does it get deleted?
<henrix> i can't imagine
<pitti> henrix: should be ok now, and published in ~ 45 mins
<henrix> pitti: great, thanks
<apw> pitti, that script that copies it to -proposed seems to say its copying to -updates
<pitti> apw: err?
<pitti> apw: you mean in the warning? that seems to be correct
<pitti> Failure to do so may result in uninstallability when it is ultimately copied to
<pitti> -updates/-security.
<apw> ahh ... odd
<tseliot> cjwatson: do you remember how to reproduce bug 929384 inside of an i386 chroot without having to use the nvidia driver?
<ubottu> Launchpad bug 929384 in nvidia-graphics-drivers (Ubuntu) "nvidia drivers broken by the recent libc update on i386 arch" [Medium,Fix committed] https://launchpad.net/bugs/929384
<AzaToth> tkamppeter: have you thought of doing a backport of cups to debian squeeze? I was trying to do one, but gave up when I was down trying to build cairo :(
<cjwatson> tseliot: well, I never actually bothered reproducing it myself IIRC, I just did theoretical work
<tseliot> cjwatson: ah, ok, maybe it was slangasek who did something like that
<cjwatson> tseliot: it was a linker bug on libGL.so though, so just fiddling with the diversions ought to be enough
<tseliot> cjwatson: ok, thanks for the tip
<cjwatson> tseliot: one moment though, there was something in some other BTS
<tseliot> oh
<cjwatson> tseliot: ah yes, IIRC if you get the right libGL in place and do something like 'LD_DEBUG=version glxgears' then it shows symbol lookup errors
<tseliot> cjwatson: excellent, thanks!
<cjwatson> didrocks: your unity upload is never going to come out of dep-wait state - you added a build-dependency on libxfixes rather than libxfixes-dev
<didrocks> cjwatson: oupsss, yeah, sorry
<didrocks> fixing
<didrocks> cjwatson: uploaded, thanks for the notice
<apw> cjwatson, linux-base (synced from debian) is bringing /usr/bin/perf which collides with linux-tools-common in ubuntu.  whats the right annotation to avoid them both being installed
<cjwatson> Conflicts, but really that's the wrong answer, you should make them play nicely together instead
<apw> cjwatson, as in add our different algorithm to linux-based ?
<cjwatson> or else we should have only one of them in the archive, though I'd prefer us to be gravitating towards Debian's layout since linux-base was supposed to be used by other packages too
<cjwatson> (linux-base ships a Perl module which was intended to help other packages do things like sorting kernel versions)
<apw> the perf binary there assumes that perf is version independant, which it actually is not necessarily ... hmm
<apw> cjwatson, ok will have a think about it
<apw> cjwatson, do you happen to have a debian system you can get a uname -r off of?
<cjwatson> not saying it's perfect as it is
<cjwatson> not a current one; my stable system says 2.6.32-5-686
<apw> yeah as i suspected, they look exactly like ours ...
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: mvo
<seb128> mvo, \o/
<apw> cjwatson, as they are indistinguisable, is it reasonable to carry a delta to linux-base ... with a view to extracting the core there into a function for use in other links
<cjwatson> apw: sure, if you're happy with that
<cjwatson> I'd actually been avoiding syncing linux-base on the grounds that it would require coordination with the kernel team; not sure how it got synced, but there you go
<apw> cjwatson, yeah indeed ... well if it is needed going forward its probabally time for us to take ownership of it and fix it up
<pitti> oh, someone binNEWed libical after all -- it's FTBFS on arm* and ppc
<pitti> I was going to wait for fixing that
<cjwatson> pitti: oh, that was me, sorry
<cjwatson> seemed no particular reason not to
<pitti> cjwatson: I initially thought it was a soname bump, but seems it isn't
<pitti> so not much harm
<cjwatson> it was just an added -dbg package
<pitti> I just prefer to wait for all builds for soname bumps
<pitti> right; sorry for the noise
<pitti>  /query mbiebl
<pitti> erk
<mvo> doko: hi, around? I'm piloting today and came accross #953171 - do you have a upload pending or should I got ahead?
 * dholbach hugs mvo
<scott-work> cjwatson: if i have questions about the ubiquity background/text bug (952462), would it be more appropriate to ask them here or in the bug report?
<scott-work> cjwatson: also, did you see my question about line #17 from the pastebin yesterday and the single parenthesis?
<cjwatson> scott-work: #ubuntu-installer, probably
<scott-work> cjwatson: thank you
<cjwatson> scott-work: I did, but you'd left by the time I was ready to respond.  It was correct as it was - shell syntax is like that.  (Actually the opening parenthesis is optional, but conventionally omitted.)
<scott-work> ah, thank you yet again :)
<cjwatson> There were other bugs in my paste though - I committed a working version this morning
<awe> rickspencer3, fyi that chromium menu bug I entered is actually not-specific to chromium...
<Pjotr> Hello
<Pjotr> cjwatson: I have reported a Ubiquity bug that you might want to take a look at: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/953959
<ubottu> Launchpad bug 953959 in ubiquity (Ubuntu) "Ubiquity fails to install Grub in Precise" [Undecided,New]
<cjwatson> Pjotr: thanks
<Pjotr> cjwatson: thank you for wanting to look at it. :-)
<Pjotr> bye
<rickspencer3> awe, can you give me the bug # then?
<awe> rickspencer3, yea... one sec.  just got out of a meeting
<awe> rickspencer3, 948059
<rickspencer3> bug #948059
<ubottu> Launchpad bug 948059 in chromium-browser (Ubuntu) "Right-click text menu ( Cut/Copy/Paste/...) sometimes rendered blank or missing items" [Low,New] https://launchpad.net/bugs/948059
<doko> bug 953171
<ubottu> Launchpad bug 953171 in eglibc (Ubuntu) "Please fix CVE-2012-0864 in precise" [High,New] https://launchpad.net/bugs/953171
<doko> mvo: no, didn't plan another upload
<infinity> Riddell: What's with calligra's weird version number? :P
<Riddell> infinity: uh oh, did I miss off a 1 from the end?
<infinity> Riddell: You might have. ;)
<infinity> Riddell:Given the number of times it's been uploaded this cycle, I assume this won't be the last, so it'll self-solve, I guess. :P
<pitti> calligra still needs at least two RC fixes (missing transitional pacakges and ttf-lyx recommends), so it can't be the last :)
<mhall119> m_3: ping
<m_3> mhall119: yo
<m_3> mhall119: got the hosting account info for linuxplumbers
<mhall119> m_3: cool, I'm working on an apache config file for it
<m_3> hey... awesome
<mhall119> m_3: but I need to know where it's being installed
<mhall119> /srv/summit/?
<m_3> /srv/$service_name/project/ atm... but I can turn any vhost you can give me into a template
<mhall119> ok
<m_3> mhall119: I got the menu and admin account created from the charm
<m_3> so really the apache vhost was next
<m_3> in meetings for another hour or so, so that'd be really helpful man
<mhall119> m_3: can you /join #ubuntu-website?
<m_3> sure
<jussi> mvo: ping?
<jussi> mvo: did you see my message earlier?
<jono> where do I file bugs against the music lens?
<dholbach> jono, "ubuntu-bug unity-lens-music"?
<jono> dholbach, doesnt wortk
<jono> oh it does
<jono> thanks dholbach
<dholbach> :-)
<jono> I was doing ubntu-music-lens
<jono> thanks!
<arges> SpamapS, hello.
<SpamapS> arges: *hello*
<arges> SpamapS, was looking at pad.lv/578536  ... was wondering what is needed to get this accepted into natty-proposed as well
<arges> if you need a debdiff, or bzr branch
<SpamapS> arges: either will be fine
<arges> ok I'll post that then, anything else I need to do to flag it then?
<SpamapS> arges: though it looks like the fixes have sat in maverick/lucid proposed since August... are you certain this one will be verified if its fixed in natty?
<arges> SpamapS, i'll talk to the reporter and make sure it gets verified
<SpamapS> arges: create the debdiff and subscribe ubuntu-sponsors, or do a merge proposal.
<arges> cool
<m_3> mhall119: hey, ok.... so done with hangout meetings for the day
<m_3> mhall119: do you just wanna send me a rough vhost?
<mhall119> m_3: http://paste.ubuntu.com/882217/ is a working apache.conf almost identical to production
<m_3> mhall119: awesome... thanks!
<ha1dfo> hi all. I don't know if this is the right channel, i'll ask anyways. I'm building a .deb for myself. I have a config/template pair, and it works fine when I dpkg-reconfigure my pkg, but won't get configured when i'm installing it. Do you have any idea what am i missing?
<mvo> jussi: no, sorry, I did not
<mvo> jussi: could you paste/msg it to me?
<jussi> [11:14:36] <jussi01> mvo: We are having a conversation about different meta packages on the kubuntu-devel list, and we want to get several meta packages added to app install data. WHat do you need from me apart from a list of packages?
<cjwatson> ha1dfo: you're probably missing a postinst that sources the debconf confmodule - see debconf-devel(7), especially the HACKS section
<ha1dfo> cjwatson, Thanks, now I see it.
<jussi> mvo: background: https://lists.ubuntu.com/archives/kubuntu-devel/2012-March/005919.html and https://lists.ubuntu.com/archives/kubuntu-devel/2012-March/005920.html
<cjwatson> it doesn't have to do anything else - so   #! /bin/sh \n set -e \n . /usr/share/debconf/confmodule \n exit 0   is fine (with " \n " replaced by real newlines)
<mvo> jussi: easiest is to add something app-install-data-ubuntu in menu-data-additional
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<jussi> mvo: right, so I havent done anything for ubuntu in a while, whats required/involved?
<jussi> mvo: need to run (baby needs attention). leave me a message
<mvo> jussi: you could just apt-get source app-install-data-ubuntu and look at the examples in menu-data-additional and create a bunch of desktop files with icons for the stuff you have in mind
<mvo> jussi: sure, see you
<cody-somerville> How do I close a bug in Debian BTS as invalid?
<Laney> with a mail to nnn-done@bugs.debian.org
<cody-somerville> Laney, But is there anything special to mark it invalid?
<Laney> no, just your text
<cody-somerville> Okay.
 * cody-somerville was sort of expecting there to be an 'invalid' tag or something.
<Laney> you can also tag 'wontfix', but there is not much point
<bryceh> slangasek, -openchrome sru fix is in the hopper
<slangasek> bryceh: cheers :)
<michael-vb> Evening.
<michael-vb> slangasek: someone suggested that I draw your attention to <https://bugs.launchpad.net/ubuntu/+source/libxt/+bug/953860>, regarding -dev packages for X11 and multiarch.  It would be lovely if that could be made to work in 12.04, as I use it a lot for developing the VirtualBox Guest Additions.
<ubottu> Launchpad bug 953860 in libxt (Ubuntu) "X11 development packages not multiarch in 12.04" [Undecided,New]
<michael-vb> ubottu: right :)
<slangasek> michael-vb: multiarch -dev packages are not realistically going to be of help right now for building i386 packages on amd64; the recommended method for that is still an i386 chroot.
<michael-vb> slangasek: right, that is my fallback of course (well, I tend to go for VMs for obvious reasons!)
<michael-vb> Shame, it would have been nice to get just the few I needed.  I see e.g. libx11-dev is multiarch.
<slangasek> yes, we'd certainly like to have these all coinstallable
<tumbleweed> chroots are much easier (pbuilder / sbuilder make it trivial)
<slangasek> fwiw, you can cross-install the ones that aren't marked M-A: same, you just can't have both the amd64 and i386 ones installed at the same time
<michael-vb> I need the amd64 ones though.
<slangasek> right; that's not solved for 12.04
<michael-vb> Obviously if there is something I can do to help get this done let me know, though I will quite understand if you are too busy.
<slangasek> michael-vb: well, I just dropped a comment on the bug about what needs to happen - either the html docs need to be split out of the -dev package, or the html generation needs to be made reproducible
<michael-vb> I didn't look to see exactly how they differed, as I was rather busy at the time myself.  I think I will though, I am curious why the docs should differ and the rest not.
<michael-vb> Thanks anyway.
<slangasek> michael-vb: no prob - sorry there's not a better answer here yet
<michael-vb> I'm sure you're hard at work on that.
<michael-vb> Getting a bit late over here - good night all.
<slangasek> pitti, dupondje: it doesn't appear that the latest cryptsetup upload has been committed to the bzr branch - do either of you have that staged somewhere, or should I take care of it?
<SpamapS> Oh ye packaging and archive wise sages.. in 11.10, we shipped the 'ensemble' package in the juju source package to help with the rename to juju. If 12.04, if we remove that, and make sure that juju Breaks: and Replaces: ensemble (<< ${binary:Version} ) .. that should mean that it will be removed on upgrade to 12.04 and never come back, right?
<ScottK> Except you need to have ensemble depend on juju so upgraders get the new package.
<SpamapS> ScottK: it did as of 11.10's release
<SpamapS> ScottK: so they should already have had juju pulled in if they had ensemble early in 11.10's development
<ScottK> OK.
<ScottK> Instead of binary version just make it unversioned then and drop the transitional package.
<SpamapS> ScottK: so in theory, I shouldn't even need the Breaks/Replaces..
<SpamapS> Right, that sounds better actually
<ScottK> You need them to make the old package go away, if that's what you want to do.
<ScottK> That or you could just ask mvo to make the upgrader do it.
<broder> won't the upgrader automatically remove packages that aren't in the archive anymore?
<SpamapS> I don't mind being explicit
<Laney> only Conflicts ensures that it actually gets removed
<Laney> I am not sure you should worry about making it get removed though
<Laney> it has implications if the archive wants to grow another package called ensemble
<SpamapS> Laney: we'd need that new package to have a new epoch (or at least a new version) no matter what, anyway, right?
<Laney> I don't think so if it was removed
<SpamapS> well in theory, 11.10 users may have had it installed...
<SpamapS> It would have depended on juju.. so on upgrade to 12.04 .. we can use clues in juju to signal removal of ensemble
<SpamapS> I was under the impression that Breaks/Replaces was that signal.
<SpamapS> Since nothing ever reverse depended on ensemble.. can we make it a Conflicts, and that would be the end of ensemble?
<SpamapS> Laney: ?^^
<Laney> I am just saying that it might not matter so much if users have an empty package installed. But if you want to do it then you should use Conflicts IIUC
<SpamapS> Laney: I actually want to clean up the namespace.
<Laney> possibly with <= the-last-version-of-the-ensemble-package
<broder> uh, isn't conflicts with <= almost always incorrect?
<Laney> explain
<broder> last paragraph of http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
<broder> i've never been good at keeping all of that straight in my head, so my takeaway has traditionally been "don't use conflicts with < or <="
<broder> but i recognize that i'm oversimplifying the rules and could be wrong :)
<RAOF> IIRC lintian (or some other tool) will throw a warning at you if you're using conflicts with <=
<Laney> maybe Breaks is OK, but I understand that it doesn't guarantee removal (although apt may implement it as such)
<lifeless> its not meant to guarantee removal
<lifeless> it permits concurrent unpacking, but requires all deps to be ok before configuring
<broder> hmm, ok. point taken. i guess the cases you get screwed with conflicts and <= is if you're actually upgrading the package that's conflicted on
<SpamapS> in this case, I want to put out a death warrant on the 'ensemble' binary package
<lifeless> right, classic case of conflict issues is one source two binaries that mutually dpeend on each other
<lifeless> and some lock-step internal change so you need to ensure lock-step upgrades
<slangasek> that sounds like the classic case of Conflicts misuse to me :)
<lifeless> conflicts won't *let* that happen, because you have a symettrical constraint, breaks does, because you can unpack them both then configure
<lifeless> slangasek: exactly
<lifeless> SpamapS: there is no 'kill kill kill' for the package; the best you can do is breaks or conflicts (depending on whether unpacking will work - and consider replaces too) with it and get it removed from the archive
<broder> right. ok, i withdraw my objection to conflicts :)
<lifeless> conflicts+replaces is the stock answer for package renames isn't it ?
<Laney> afaict it is already removed, he just wants to ensure that users don't have the transitional package any more
<slangasek> lifeless: indeed
<SpamapS> Its still being built today, but the next upload of juju will not build the 'ensemble' binary package... and make it NBS ..
<SpamapS> It sounds like Breaks+Replaces on 'ensemble' without a version is the clearest way to inform package managers that this package should be removed.. and if they choose to ignore that, then they'll be left with an annoyed user who will likely remove it.
<lifeless> SpamapS: how will they be annoyed? just get archive admin to remove the NBS package once juju has built
<SpamapS> lifeless: user would be annoyed because on installing 'juju' the package manager would refuse to configure *juju* ;)
<lifeless> SpamapS: htf?
<slangasek> no, it wouldn't
<slangasek> ensemble would be deconfigured, juju would be configured
<SpamapS> exactly, it wouldn't..
<SpamapS> I'm going through the scenarios in my head where a package manager would sanely not remove ensemble at that point.
<SpamapS> One question, why not also include a ( << ${binary:Version} ) to ensure that the namespace is protected if some future package wants to be 'ensemble' and doesn't actually break because it has nothing to do with juju
<SpamapS> (assuming I forget to remove the breaks/replaces in 12.10)
 * SpamapS goes through his daily "delete all the haskell change emails from precise-changes mailing list" routine
<Laney> SpamapS: there is no need for it to be a variable
<Laney> HOW DARE YOU!
 * Laney uploads some more for punishment
<SpamapS> Laney: indeed, I can make it static so its just up to the current version
<dupondje> Now this is odd, updating my precise system, and getting: 'dpkg: error: parsing file '/var/lib/dpkg/available' near line 14'
<bkerensa> micahg: On my merge proposal for the xchat bug you suggested we request Upstream to ship a higher-res icon but is this really a good idea considering we would be asking upstream to accommodate Ubuntu when this problem does not exist elsewhere?
<ajmitch> there'd be nothing stopping other systems from using a high-res icon, would there?
<bryceh> slangasek, bug #953953 looks sort of like that gz bug you mentioned, except all the referenced versions in the log were built today.  We've had two reports today of this error, both amd64 with the i386 libxfixes installed presumably for wine
<ubottu> Launchpad bug 953955 in libxfixes (Ubuntu) "duplicate for #953953 package libxfixes3 1:5.0-4ubuntu3 [modified: usr/share/doc/libxfixes3/changelog.Debian.gz] failed to install/upgrade: libxfixes3:amd64 1" [Undecided,Confirmed] https://launchpad.net/bugs/953955
<slangasek> bryceh: looking
<slangasek> bryceh: bug #953955 (which is marked as the master) is definitely not related to gzip; the upgrade error is from trying to configure the package when the amd64 and i386 packages aren't installed at the same version
<ubottu> Launchpad bug 953955 in libxfixes (Ubuntu) "package libxfixes3 1:5.0-4ubuntu3 [modified: usr/share/doc/libxfixes3/changelog.Debian.gz] failed to install/upgrade: libxfixes3:amd64 1" [Undecided,Confirmed] https://launchpad.net/bugs/953955
<slangasek> bryceh: the reference to a modified changelog in the title is probably just that the bug is being reported against the amd64 package, and the currently unpacked changelog is from the i386 package; since they're at different versions, of course the changelogs don't match
<bryceh> slangasek, ah, weird
<slangasek> bryceh: I've checked the libxfixes3 in the archive, and the changelog files match
<jalcine> Is it me or is Launchpad just failing to build anything?
<slangasek> jalcine: example?
<jalcine> https://launchpadlibrarian.net/96701937/buildlog.txt.gz
<jalcine> I think it's #915505
<jalcine> https://launchpad.net/bugs/915505
<ubottu> Launchpad bug 915505 in launchpad-buildd "bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split'" [Critical,Triaged]
 * jalcine looks for ubottu
<slangasek> ah, that looks like a recipe build?
<slangasek> I think you'd want to ask #launchpad
<jalcine> Yup.
<jalcine> Thanks.
<bryceh> slangasek, ok, so just chalk it up to a transitory failure?
<slangasek> bryceh: well, it could be a bug in whatever package management frontend they were using, or it could be user foot-shooting
<slangasek> it's not the sort of thing that we should be seeing as a matter of course
<bryceh> hmm
#ubuntu-devel 2012-03-14
<tran4> I'm a senior CS undergrad. I applied to a company for co-op and intern positions: http://pastebin.com/LdAH6eaZ  Are they good? Should I respond to the recruiter about this job or wait and see if the company contacts me?  I applied thru both. The recruiter's ad lists $14/hr. I live with my parents and they want me to get some work experience this summer. I havent had many replies.
<micahg> bkerensa: upstream is either actual xchat upstream or Debian in this case, I just don't think it makes sense for us to carry a binary didd
<micahg> *diff
<bkerensa> micahg: I understand that but at the sametime I think actual xchat upstream and Debian would not think it would make sense for them to change their package just to satisfy a bug existing in Ubuntu?
<micahg> bkerensa: upstream could ship both versions as could Debian if they choose
<slangasek> micahg: xchat is already a 3.0 (quilt) package, and there's an existing (and substantial) Ubuntu delta.  Of course this should be upstreamed as far as possible, but why does it hurt to carry a binary diff in the meantime?
<slangasek> bkerensa: fwiw I don't see any reason that a high-res icon would be specific to Ubuntu either
<bkerensa> slangasek: Ok well I can submit a patch to debian and see if it will be accepted.
<micahg> slangasek: well, I guess it wouldn't hurt that much if we ship it in the debian dir and copy it into place, it's just a pain for non-UDD merging :)
<bkerensa> micahg: I will put this on my todo list and update the related bug we have
<slangasek> micahg: echo path/to/other/binary >> debian/source/include-binaries
<micahg> I was personally thinking more along the lines of Debian when I said upstream as xchat upstream for linux seems to have stalled, but I guess the Debian maintainer has as well
<slangasek> micahg: ^^ no copying required, just add that line :)
<micahg> slangasek: I"m not familiar with that option
<micahg> ah, I see now
<infinity> bryceh: Did you mean to aim that mesa upload at a PPA instead of the archive?  That's a rather special version number.
<Sarvatt> infinity: whoops, guaranteed he did
<infinity> Well, here's hoping it doesn't break anything. :P
<Sarvatt> it'll be superseded by 8.0.2 in a few days anyway at least and is a good fix :)
<bryceh> infinity, aw crap
<bryceh> infinity, actually it's the right upload, just wrong version number
<bryceh> I should be able to load the proper one over it
<infinity> bryceh: No harm done, then.
<bryceh> there we go, thanks for catching that
<pitti> slangasek: cryptsetup> oops, sorry; I'll commit it
<pitti> Good morning
<pitti> slangasek: ah, you did already, thanks
<dholbach> good morning
<dupondje> debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable when updating. What could cause this?
<cjwatson> having some other package management program running
<cjwatson> perhaps an automatic update you were unaware of, or something like that
<dupondje> the automatic update should see dpkg is running, and not interfer imo :)
<cjwatson> feel free to debug it locally ... ;-)
<ivoks> cjwatson: have you seen bug 880119?
<ubottu> Launchpad bug 880119 in syslinux-themes-ubuntu (Ubuntu) "live-build expects themes in different folder" [Undecided,Confirmed] https://launchpad.net/bugs/880119
<ivoks> cjwatson: i'm not sure if live-build needs to be fixed or syslinux themes
<cjwatson> syslinux themes - it's not just a matter of moving them though, it may require actually writing new theme content
 * cjwatson isn't sure he has time to look just at the moment
<ivoks> cjwatson: thanks... should i use iso-hybrid instead of usb-hdd to workaround this?
<cjwatson> I expect it's a workaround, yes; whether it meets your needs I can't say :)
<cjwatson> I think my answer is "patches welcome" ;-)
<ivoks> scary, but true
<ivoks> hehe
<ivoks> but it makes live-build unable to create usb images, if i understand this correctly
<ivoks> i see what i can do
<cjwatson> isohybrid images are valid usb images too ...
 * cjwatson eyes desktopcouch and wonders why this didn't completely screw upgrades from maverick
 * nijaba grumbles at nasty bug #954793 biting me since this morning 
<ubottu> Launchpad bug 954793 in unity (Ubuntu) "Unity/Compiz crashes on each right click" [Undecided,Confirmed] https://launchpad.net/bugs/954793
<seb128> nijaba, opening a bug with apport to get a stacktrace would be useful
<nijaba> seb128: would gladly do so, but I do not get a crash report, just the graphical environment that restarts everytime I right click.  Any hint on steps that would help
<nijaba> ?
<seb128> nijaba, can you pastebin your /var/log/apport.log?
<nijaba> sure
<nijaba> seb128: http://paste.ubuntu.com/883055/
<nijaba> smells like compiz.  not sure why it is ignoring it
<seb128> nijaba, because it already have a file in /var/crash with a counter > 2
<seb128> nijaba, it stops collecting then to avoid triggering apport in loop for stuff which keeps hitting the same bug
<nijaba> seb128: k, how can I send what it has?
<seb128> nijaba, ubuntu-bug /var/crash/_usr_bin_compiz....
<seb128> nijaba, or rm /var/crash/* and get the bug
<nijaba> seb128: thanks, doing it now
<seb128> nijaba, it should prompt you to report it if there is no staled .crash already there
<seb128> nijaba, thank you
<nijaba> seb128: it did.  Uploading now.  will come back with new bug# when done
<seb128> nijaba, thanks
<nijaba> seb128: Bug #954888
<ubottu> Error: Launchpad bug 954888 could not be found
<seb128> nijaba, seems your issue is bug #808007
<ubottu> Launchpad bug 808007 in compiz (Ubuntu) "compiz crashed with signal 5 in Glib::exception_handlers_invoke()" [Medium,Confirmed] https://launchpad.net/bugs/808007
 * nijaba looks
<seb128> dbarth_, ^ can we get somebody to look at that? unity exit for nijaba every time he right click
<nijaba> seb128: yep, sounds similar, but with up to date precise and only since today for me.
<seb128> nijaba, right, it started getting dups recently it seems
 * nijaba goes to a meeting.  back in a couple h
<dbarth_> seb128, nijaba: uh, a crasher?
<seb128> dbarth_, yeah, some people have unity going down on right click, seems "fun"
<seb128> dbarth_, well since nijaba has the issue he can probably help somebody in dx to debug it by provinding infos?
<dbarth_> yeah
<dbarth_> it's an exception that goes untrapped
<dbarth_> rather brutal for an exit
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: mdeslaur
 * dholbach hugs mdeslaur
<apw> cjwatson, how is the kernel version which is in the ubuntu-srver images chosed ?
<apw> cjwatson, they seem to have 3.2.0-18.28 in them, but .29 was in the archive since monday
<cjwatson> http://cdimage.ubuntu.com/ubuntu-server/daily/current/precise-server-i386.list disagrees with you
<cjwatson> likewise amd64
<apw> cjwatson, people booting them are pasting me output with -28.28 in them ... i will investigate
<cjwatson> apw: the kernel version that's booted only changes following debian-installer uploads
<cjwatson> apw: I happened to do one of those for other reasons earlier today, although after the daily server build
<apw> cjwatson, right but the image only has 18.29 in it, does that mean there is an older kernel in there separate to the one in the manifest?
<cjwatson> as I said, debian-installer builds deliver a kernel and an initrd (and other stuff), which is what's used to boot the image
<cjwatson> you can't boot an .iso using the kernel in a .deb, it's got to be extracted somewhere
<cjwatson> that's done as part of the debian-installer build process
<apw> ahhh ... ok ... so its entirly possible that the boot kernel is older, which would fit the behaviour the reporter has
<cjwatson> yes
<apw> and ... you did one today so the new images in the AM will be updated
<cjwatson> tomorrow's daily will have -18.29, yes
<nijaba> dbarth_: I am back if can help
<apw> cjwatson, thanks for the explanation, added to my checklist
<cjwatson> FWIW I don't think we need to rebuild d-i after every kernel upload as a rule; only on ABI changes, before milestones, or if there's some particular installer-relevant fix
<dbarth_> nijaba: ok
<Laney> tkamppeter: hey, we got a backport request for hplip preciseâlucid. Should this be possible? bug #838431
<ubottu> Launchpad bug 838431 in Baltix "Please backport HPLIP 3.12.2 or more recent" [Undecided,New] https://launchpad.net/bugs/838431
<dbarth_> nijaba: can you try downgrading glibmm maybe
<apw> jodh, does upstart assume we have pts mounted ?
<dbarth_> nijaba: otherwise, what's the test case: you right click anywhere on the screen (app, dash, panel) and it goes kaboom?
<nijaba> dbarth_: yes, ANY right click does provoke the crash
<nijaba> dbarth_: I can try downgrading now if you want
<jodh> apw: for now, yes. I'll be putting a change in soon that disables logging if pts is not available.
<apw> jodh, and is that the only thing it uses it for ?
<jodh> apw: yes.
<seb128> nijaba, when did the bug start?
<seb128> nijaba, wget https://launchpad.net/ubuntu/+source/glibmm2.4/2.31.18.1-0ubuntu1/+build/3252325/+files/libglibmm-2.4-1c2a_2.31.18.1-0ubuntu1_amd64.deb
<apw> jodh, will our upstart jobs then go ahead and mount it?
<seb128> nijaba, try that, restart compiz (or right click that will do it for you) and try again
<nijaba> seb128: today, but last update of glibmm seems to date back from 9 March
<jodh> apw: currently mountall does that for us if the initramfs hasn't already.
<nijaba> seb128: so I think it won't change much
<seb128> nijaba, do you update daily?
<nijaba> seb128: I do
<seb128> nijaba, do you restart daily?
<dbarth_> seb128: well, he has restarted unity multiple times because of that crash at least
<nijaba> seb128: I did today, and in general yes, but not sure of that over the we
<seb128> dbarth_, nijaba: unity 5.6 and new compiz got uploaded on monday, I would blame those
<jodh> apw: however, we're seeing evidence of users who are already using (custom) initramfs-less kernels which causes problems for jobs that start before mountall gets /dev/pts mounted, hence the upcoming change.
<apw> jodh, so does that mean if i boot --no-log we don't need pts's then ?
<jodh> apw: correct.
<seb128> dbarth_, nijaba: I guess you got the update yesterday but didn't run the new version before today
<nijaba> seb128: very possible.  I was on the road yestday
<jodh> apw: the immediate change is to have upstart degrade the console value from "log" to "none" if /dev/pts isn't available, so your jobs output won't get logged in that instance, but the job will atleast run.
<apw> jodh, yep ... sounds sensible that upstart should always degrade in some sensible way rather than prevent your machine booting
<jodh> apw: the full change would be to have upstart handle mounts of course :)
<apw> jodh, yeah that would be nice of course
<apw> jodh, we could probabally burn in ubuntu specific mounts ourselves in our version
<jodh> apw: right.
<nijaba> seb128: dbarth_: confirming that the downgrade of libglibmm does not solve the issue.
<seb128> nijaba, ok, thanks
<seb128> dbarth_, ^
<nijaba> hmmm...  looks like there is is a new unity version available since this morning.  Trying the update
<nijaba> drat... no luck
 * mpt wonders whether an update removing libiodbc2 is a good or a bad thing
<cjwatson> apw: better not to hack it in in advance of full mountall integration, IMO, because it would need a reasonable amount of mountall's code already just to honour fstab mount options for /dev/pts
<apw> cjwatson, are our /dev/pts options variable at all ?
<cjwatson> we support the user modifying them in /etc/fstab, right no
<cjwatson> w
<pitti> mpt: good, it's obsolete
<apw> cjwatson, could we not let mountall mount -oremount them perhaps
<cjwatson> given that they're currently "noexec,nosuid,gid=tty,mode=0620", they aren't so simple that I'd want to rule out anyone modifying them
<cjwatson> could we perhaps not mess with this at this stage :)
<apw> cjwatson, looking for something to let the 'initramfs less' boot to work, right now it goes pop
<cjwatson> jodh's patch to just drop logging for things that happen at that stage in the initramfsless case is the sensible least-impact workaround for precise
<cjwatson> apw: jodh already has such a thing; no need to look for more
<apw> ok cool
<mpt> thanks pitti :-)
<slangasek> mpt: it's a good thing...
<apw> cjwatson, in better news, devpts does support remount, so you might not need to do it right at inital mount when you get to it
<cjwatson> once mountall is integrated into upstart we shouldn't need to worry about that
<cjwatson> it can just mount it with the right options from the start
<apw> jodh, do you have a bug # for the log changes you are doing, so i can refer to i in my bug ... ta
<cjwatson> apw: bug 936667
<ubottu> Launchpad bug 936667 in upstart (Ubuntu) "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Confirmed] https://launchpad.net/bugs/936667
<ogra_> heh
 * ogra_ duplicates his pandaboard bug to that then
<ogra_> stgraber, hmm, didnt i see you add a fix for the "wait 60sec for the network to come up" issue a while ago ?
<stgraber> ogra_: depends on the issue :)
<ogra_> heh
<ogra_> well, i leave the network unconfigured on my panda during install and it shows the msg (/e/n/i is completely empty post install)
<ogra_> (didnt we use to put loopback in there at least)
<stgraber> ogra_: you should at least have a loopback in there yes
<ogra_> hmm, i dont even have the file
<ogra_> but i have a loopback device ;)
<dbarth_> nijaba: ok, at least we know it's not coming from there
<nijaba> yup
 * ogra_ greins and wonders if dholbach follows the meeting 
<ogra_> *grins even
<ogra_> (i would have done it even without calendar entry ;) )
<roaksoax> Hi guys, I have a quick question. Can I have 2 upstart jobs in 1 binary package?
<pitti> roaksoax: yes; name it debian/binarypackagename.jobname.upstart
<pitti> it'll become /etc/init/jobname.conf
<roaksoax> pitti: cool thanks
<dholbach> ogra_, in a call
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<tkamppeter> slangasek, bdmurray, about bug 911436, it prevents many users from updating CUPS (cupsd simply crashes). Is there a chance that it gets fixed in Precise?
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<slangasek> yes, it's targeted for precise
<slangasek> but that bug certainly shouldn't prevent upgrading
<slangasek> all it does is cause crashes *during* the upgrade
<SpamapS> you know.. if we were really evil.. we would integrate command-not-found and sl together into one big "for-your-worst-days" package..
<pitti> offli
<pitti> -EFOCUS, sorry
<ogra_> now change your password from offline1 to something new :P
<pitti> lol
<pitti> offlineimap FTW!
<chrisccoulson> dang, i got excited there when i saw the subject of ogasawara's mail "[RFC] Drop Non-smp PowerPC Kernel Flavor" -> I glanced at that and thought i saw "[RFC] Drop PowerPC Flavor"
<ogasawara> heh
<mdeslaur> die.powerpc.die.die.die
<chrisccoulson> yes please
<mdeslaur> ogasawara: can't you just push a completely broken powerpc kernel that will get the builders off line permanently? :)
<chrisccoulson> i promise that i'm saving up some money to buy our 3 powerpc users a new computer
<mdeslaur> chrisccoulson: I may contribute to that fund, I've got some empties to bring back to the store
<chrisccoulson> heh :)
<infinity> chrisccoulson: Wait, I missed that mail.  -devel?
 * infinity goes to look.
<chrisccoulson> infinity, yeah, it went to ubuntu-devel
<infinity> ogasawara: Do we know if the powerpc-smp kernel will be happy on non-smp hardware (you know, like mine)?
<infinity> ogasawara: And does it use the same on-the-fly spinlock->noop rewrite tricks when booting non-smp that x86 uses (which was our argument for dropping x86 non-smp years ago)
<cjwatson> infinity: that's related to what I was getting at in my reply, yes ...
<ogasawara> infinity: jk did testing to confirm smp kernel should be ok on non-smp hw
<infinity> ogasawara: For values of "okay" that probably don't measure performance, but at least it'll boot. :/
<ogasawara> infinity: he did mention there could be a small performance degredation
<infinity> ogasawara: The reason we dropped SMP on x86 was because of the cute runtime patching bits that noop spinlocks, AFAIK that patch was x86-only.
<infinity> ogasawara: The degradation isn't particularly small without that trick in play.
<infinity> (And it's nonexistant with the patch, in theory)
<ogasawara> infinity: I can ping him to see if he can provide the actual stats
<infinity> ogasawara: I know it came up years ago, when we first introduced said patch.
<infinity> ogasawara: And given that PPC32UP hardware is kinda slow by default, I'm not sure that making it slower in the name of reducing kernel build time is a pleasant scenario.
<infinity> ogasawara: Though, Colin's point that there's a vanishingly small number of PPC32SMP hardware out there might be worth considering, if the build time is really killing us.
<infinity> (Or, someone could eBay some PPC hardware for the DC that isn't 10 year old Applie iServes...)
<infinity> s/Applie/Apple/
<ogra_> they sell 9 year old ones there ?
<infinity> :P
<ogasawara> infinity: I'd think the number of impacted users would be decreasing.  And selfishly speaking from the teams perspective, powerpc is our bottleneck currently in terms of package preparation.   we can crank out amd64, i386, and arm test builds in under an hour for all flavors
<infinity> ogasawara: ARM in under an hour?
<ogasawara> infinity: cross compiling
<infinity> ogasawara: Cross hardly counts.. You could cross-compile PPC too.
<infinity> ogasawara: I realise the goal is rapid turnaround, but there are plenty of packages that take a lot longer than 6 hours, and some us actually do run this hardware. :P
<infinity> ogasawara: I don't disagree that we need more CPU time for PPC buildds (and that's bein worked on), but I'm not wildly happy about making my PPC machines slower just to reduce the build time of a package.  Build time is supposed to make sacrifices in the name of better runtime, isn't it?  At least, that's what I learned from compiler hackers. :P
<tkamppeter> slangasek, but causing crashes during the upgrade leads to the package installation not concluding and the users reporting bugs.
<slangasek> tkamppeter: "users reporting bugs" is a separate issue from whether it actually breaks their system, which AIUI it doesn't
<slangasek> bdmurray: bug #911436 is still accumulating duplicates; did you make any progress on debugging the bug pattern?
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<mhall119> If I have a package in precise universe already, but I want to bump it to a newer version, do I need to file another FFe?
<bdmurray> slangasek: oh some recent duplicates are ProblemType: Package and the pattern is for a stacktrace
<mhall119> 0.2.1->0.2.2
<slangasek> mhall119: yes, https://wiki.ubuntu.com/FreezeExceptionProcess
<bdmurray> I'll work on a pattern for it
<slangasek> ok, thanks
<tkamppeter> slangasek, I did not modify the bug pattern yet.
<tkamppeter> slangasek, how do I change the bug pattern?
<slangasek> tkamppeter: I think bdmurray has the problem in hand
<bdmurray> slangasek, tkamppeter: yes I'll fix it
<tkamppeter> bdmurray, slangasek, thanks.
<roaksoax> ok :)
<roaksoax> lol
<slangasek> jibel_: the last two days of upgrades are showing disk i/o errors here - known problem?  https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/
<slangasek> jibel_: sorry, not the last two days, just today
<slangasek> jodh: bug #955287> this really shouldn't be handled in acpi-support, which is deprecated
<ubottu> Launchpad bug 955287 in acpi-support (Ubuntu) "Ubuntu should handle "hot" CPUs by taking preemptive action and warning users" [Undecided,New] https://launchpad.net/bugs/955287
<slangasek> jodh: the hot v. critical levels are set in the ACPI tables, so are system specific; the kernel is already supposed to step down the CPU when hitting the threshold - does it not do so for you, or is it not enough?
<happyface> Wooh, 12.04 runs so good on vmware tech preview
<doko> slangasek, for the pycompile error: what did you upgrade? plain CD/DVD installation?
<slangasek> doko: this was an auto upgrade test in jenkins; in this case it was "install all of main, then upgrade" - see the referenced URL
<doko> wonderful ...
<slangasek> doko: so actually, whatever causes it seems to not be included in either the default desktop or server installs - maybe ok to downgrade to 'high' instead of 'critical'
<doko> slangasek, I'll look first to improve the diagnostics for beta2
<slangasek> doko: right - if you can fix it to get a better error message out, there'll be a daily test every day between now and beta-2 :)
<jibel> slangasek, never seen this error before. main amd64 is running, I'll check if it occurs today again.
<slangasek> jibel: sounds good, thanks :)
<SpamapS> slangasek: heh.. after years of nis not working in lucid.. updates are just a verification away.. hopefully just in time for people to stop using NIS. :)
<slangasek> SpamapS: I conclude from the demand for this SRU that people will never stop using NIS
<SpamapS> slangasek: yeah, I'm starting to think the same thing about this "PHP" language people are still refusing to let go of.. ;)
<Daviey> BURN
<Daviey> SpamapS: Maybe we can bump php to universe for 14.04 ?
<Daviey> :)
<SpamapS> Daviey: ohpleaseohpleaseohplease lets do it
<Daviey> Maybe jdstrand would object.. it's keeping them in business
<SpamapS> True.. might have to downsize w/o PHP
<SpamapS> Though that might free up resources for all the rebuilding that golang will bring! :)
<jdstrand> uhh, we have quite a lot keeping us in business. I think not a one of us would shed a tear over not supporting php5 :P
 * slangasek sets a target of php6 for 14.04
<ajmitch> Daviey: careful, you might get certain sites reporting on it being dropped within a few minutes of suggesting it here
 * jdstrand wouldn't shed a tear over php6 either
<jdstrand> I'm here all night! :)
<SpamapS> slangasek: can we also get free mermaid rides at UDS-T then? ;)
<mdeslaur> oh, can we also get the kernel demoted to universe, please?? that one's a bitch
<SpamapS> mdeslaur: we'll have to promote something in its place.. kfreebsd?
<mdeslaur> SpamapS: we'll all be using keyboards hooked up to the cloud soon anyway...who needs a kernel? :)
<Daviey> ajmitch: Good point.. for the avoidance of doubt, i don't think it will be possible...
<micahg> ajmitch: Daviey: as an example of a discussion turning into reality before a decision is made: http://www.phoronix.com/scan.php?page=news_item&px=MTA3MDc
<mdeslaur> lol, that didn't take long :)
<Daviey> heh
<barry> slangasek: hi.  would you have time+interest in debugging an installation problem w/today's 12.04 live cd on a thinkpad x130e?
<broder> ajmitch, Daviey, micahg: for UDS i'm planning to start a (clearly labeled) twitter account that consists entirely of highly controversial decisions that didn't happen and see how long it takes for something to show up on omg or phoronix
<slangasek> barry: I can give it a shot
<Daviey> broder: hah
<ScottK> slangasek: Make him get rid of /usr/bin/python2 first.
 * slangasek chuckles
<barry> slangasek: there's a machine here where the installer eventually just hangs the whole machine.  we think it's a memory starvation problem with ubiquity.  3.02g RES right now and *very* slow response at the virtual console.  any suggestions on how we might debug the problem (we're looking at ps output and nothing relevant shows up in the various logs)
<barry> ScottK: ;)
<barry> yeah, keyboard input is slooooooooooooooooooooooooooooooooooow
<slangasek> 3.02g res> !!
<barry> killing ubiquity restored responsiveness, but of course crashed the installer :)
<tumbleweed> broder: :)
<slangasek> not really meant to do that
<slangasek> hmm
<barry> can we re-run ubiquity with more debugging?
 * barry suspects he'll learn all the tricks next week :)
<slangasek> yes, I think there's a --debug flag
<ajmitch> broder: that twitter account sounds like an excellent idea
<broder> i think the biggest risk is actually reporting something true :-P
<ajmitch> broder: I'll be sure to RT it then
<slangasek> barry: does --debug work?
<barry> slangasek: not so much.  didn't really help get a clue as to what's going on.  it just looks like it's leaking memory.  he's going to ping me next week so maybe we can drill into it some more then.
<slangasek> ok
<slangasek> next week should be a good time for it :)
<barry> slangasek: yep! :)
<jodh> slangasek: I've changed pkg for bug 955287 to linux. For my Thinkpad, the kernel does not DTRT: it forcibly reboots when the CPU temperature reaches 128C! ;)
<ubottu> Launchpad bug 955287 in linux (Ubuntu) "Ubuntu should handle "hot" CPUs by taking preemptive action and warning users" [Undecided,New] https://launchpad.net/bugs/955287
<slangasek> jodh: do you have the same buggy acpi tables that I do (command to check posted to the bug)?
<jodh> slangasek: just posted comment - my tables look sane. I've been running a tool cjking pointed me to (tp-thermstat) to help him track down the problem (bug 751689).
<ubottu> Launchpad bug 751689 in linux (Ubuntu Maverick) "ThinkPads overheat due to slow fans when on 'auto'" [Critical,In progress] https://launchpad.net/bugs/751689
<slangasek> jodh: huh, alrighty then
<slangasek> jodh: do you see any change in behavior when you hit the passive threshold?  fans spinning up, or cpu stepping down?
<slangasek> jodh: fwiw, in the end I've worked around all my problems by changing my performance profile in the BIOS - before that I was overheating nearly every time I compiled anything interesting, now my compiles just take longer instead
<jodh> slangasek: just forwarded you the info. Difficult to say - whenever I hit the problem, I seem to have headphones on :) Will try tests in more controlled environment tomorrow.
<slangasek> ok :)
<jodh> slangasek: a possible solution is apparently for me to upgrade my bios. I may try that. I'd seen 751689 some time (releases) back, but hadn't been affected by it again until trying to compile eglibc with a few kvms running.
<jodh> gotta dash - will get more info tomorrow...
 * slangasek waves
<bdmurray> slangasek: so I've written a package install pattern for bug 911436 but I don't think its very specific
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<slangasek> bdmurray: what's it look like?
<slangasek> oh; the duplicate bugs don't even show why the job failed to start, do they :/
<bdmurray> ah, but dependencies.txt might help
<bdmurray> libp11-kit0 0.10-1 as part of the pattern should do it
<bdmurray> slangasek: thanks for the help ;-)
<slangasek> my pleasure :-)
#ubuntu-devel 2012-03-15
<SpamapS> jdstrand: still here?
<broder> infinity: i looked into multiarching libpcsclite1, fwiw. i don't remember whether or not i concluded that its communication with pcscd was arch-independent, but i think i decided it wasn't
<broder> (re vmware view client)
<infinity> broder: Ahh, that would prove problematic.
<infinity> broder: Perhaps a followup to that bug indicating such, so we don't just look "lazy" for not getting around to it? ;)
<broder> sure
<infinity> broder: Danke.
<broder> infinity: oh, crap. i didn't notice you were still logged into odo, but i just kicked off a full lintian rescan for the new upstream release, which wipes out the old lab
<broder> it, uh, should be back in about 24-48 hours or so
<broder> i bet with more thinking, i could have done that without actually destroying the laboratory. maybe next time
<ScottK> broder: Is something like "what packages have the file debian/pyversions and mention version 3 or higher?" something you can grep for reasonably easily?
<infinity> broder: Oh, no big deal.  I was logged in, but idling.  I'm sure I have what I need in my ~
<infinity> ScottK: That would be trivial had he not just wiped out the lab, yeah. :)
<ScottK> broder: I'd appreciate it if you could generate such a list once the lab is back.  I need to remove some backwards compatibitly support code from dh_python3 before it gets to be "It's always been that way" and I suspect a MBF of some degree will be needed.
<ScottK> debian/pyversions should never be used for python3.
<ScottK> And XS-Python-Version: with Python 3 versions in debian control too.
<ScottK> Soooooo much brain damage already for something so new.
<pitti> Good morning
<broder> ScottK: yeah, that should be easy once the lab is reassembled
<broder> ScottK: i'd strongly encourage you to ping me about it in, say, 3-4 days because i will likely forget
<rickspencer3> hey pitti, almost another beer this morning! silly armhf archive :)
<pitti> well, calligra failed to build on armhf
<pitti> and libreoffice currently doesn't build these three binaries on arm, Sweetshark was looking into bringing them back
<rickspencer3> pitti, yeah, like I say "silly armhf" ;)
<rickspencer3> tbh, I am pretty happy with the state of armhf all things considered
<pitti> yeah, it doesn't actually break LibO, and the calligra FTBFS is just brand new
<pitti> rickspencer3: we got a new release-upgrader-apt into lucid-proposed yesterday; I'm yearning to see today's auto dist-upgrade results :)
<rickspencer3> pitti,  oh boy
<rickspencer3> pitti, so, time to get Lucid ready for upgrades to Precise? I guess mvo has been busy?
<pitti> lots of red on https://jenkins.qa.ubuntu.com/view/Precise/ :/
<pitti> bootspeed and the new openstack tests mostly
<rickspencer3> pitti, yeah, the upgrade testing has been bumming me out, but slangasek assured me that the blockers were being worked on
 * pitti leaves those in the good hands of Daviey/jibel and goes back to untangling pygobject marshalling code
<rickspencer3> pitti, I think the boot speed regressions were addressed by the apparmour engineers yesterday
<rickspencer3> "pygobject marshalling code"
<pitti> rickspencer3: yes, I reviewed all failues last week, and most of them came down to two apt bugs
<rickspencer3> that does not sound found
<pitti> rickspencer3: no, the boot speed tests fail apparenlty
<rickspencer3> pitti, oh, I see, that's new then
<pitti> some SMTP exception in the tests
<pitti> Sending e-mails to: qa-team@lists.canonical.com
<pitti> ERROR: Invalid Addresses
<rickspencer3> pitti, I think your idea of unitverse upgrade testing was as stroke of genius (naturally)
<pitti> rickspencer3: well, it certainly helped to uncover a lot of failure cases
<pitti> rickspencer3: upgrade-lucid-universe is a real masterpiece to get right, of course; once that works, everything else is child's play :)
<rickspencer3> let's do it!
<rickspencer3> (easy for me to say ;) )
<rickspencer3> pitti, but indeed, systematically ensuring those tests before the Precise end game ...
<rickspencer3> this should contribute to a nice smooth release on April 26th
<jibel> pitti, bootspeed test failure is caused by a network error. I'll ask Larry to look into this this afternoon, when he wakes up.
<pitti> merci jibel
<jibel> openstack, the address of the repository https://github.com/openstack/nova.git is wrong
<jibel> jamespage, ^
<pitti> it's https://github.com/openstack/nova/
<pitti> oh, actually.. that page itself says https://github.com/openstack/nova.git
<pitti> and that actually does work
<pitti> $ git clone https://github.com/openstack/nova.git
<pitti> git clone https://github.com/openstack/nova works as well, though
<jibel> well, the error from the job is "ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job."
<dholbach> good morning
<ajmitch> morning dholbach
<dholbach> hi ajmitch
<geser> Hi dholbach and ajmitch
<dholbach> hey geser
<ajmitch> hi geser :)
<jibel_> slangasek, main-all lucid amd64 didn't finish and I can't log in. it could be caused by the corruption you saw yesterday. I'll rebuilt the base image.
<pitti> stgraber: so bug 939450 was a nice puzzle, I couldn't resist hacking on it after all :) it's working well here now
<ubottu> Launchpad bug 939450 in pygobject (Ubuntu Precise) "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [Medium,In progress] https://launchpad.net/bugs/939450
<ScottK> broder: Thanks.
<dpm> hi all, I've got a quick question on a particular package and I was wondering if someone could give me a hand
<dpm> I'm working with translation templates in LP
<dpm> and I need to know which source packages are in universe (so that they are disabled in LP) and which ones in main
<dpm> I'm looking at this one: http://pastebin.ubuntu.com/884504/
<dpm> the question is, why is there output for a universe line and a main line?
<dpm> any ideas?
<tumbleweed> dpm: source in main, binaries in universe
<dpm> tumbleweed, does this mean it needs fixing? I.e. everything needs to be in main?
<tumbleweed> dpm: that's not my area of expertise :) Not sure why that package is like that
<dpm> tumbleweed, no worries, thanks :)
<seb128> nijaba, hey
<geser> dpm: no, there are valid use-cases where the source is in main but the binary packages in main and universe (e.g. a library in main while its utils in universe)
<geser> dpm: in your example, the -common and the -control-center package is in main while activity-log-manager is in universe (perhaps didrocks can tell you the rationale for it)
<dpm> ok, thanks a lot geser!
<didrocks> geser: activity-log-manager is a standalone application
<didrocks> geser: we don't really need, we only want the control panel plugin
 * didrocks logout/login bbiab
<geser> dpm: ^^ a reason for such a main/universe split
<jmelis> Hi guys, I've sent an email requesting for help to maintain and perform a sync request of the opennebula (opennebula.org) package. I've sent it to the ubuntu-devel mailing list, but it's moderated. Should I send it elsewhere?
<dholbach> jmelis, https://wiki.ubuntu.com/SyncRequestProcess#For_people_requiring_sponsorship explains how to do it, so it shows up in the review queue
<dholbach> jmelis, and thanks for your offer of help!
<jmelis> thanks dholbach! although what offer of help??
<jmelis> me being involved in the maintaining process?
<dholbach> you said you'd want to help maintain the package, no? :)
<jmelis> yes :)
<dholbach> well that's excellent :)
<jmelis> dholbach: when I send the sync request, should the package be ready to work in UBuntu, or is it understood that there's still work to do?
<jmelis> Damien Raude-Morvan (package maintainer) and I have built the debian package and we would like to sync that package so the development of the package is centralized...
<dholbach> yes, it should work in Ubuntu
<dholbach> I had a quick look and there seem to be modifications of the package in Ubuntu
<dholbach> can they be dropped?
<jmelis> what for instance?
<dholbach> ah no, it was a change which was reverted again
<dholbach> nevermind
<jmelis> how can I check if my package is ready for a sync request?
<dholbach> it seems to be a major version update, so adding some information as outlined in https://wiki.ubuntu.com/FreezeExceptionProcess will be useful
<dholbach> it'd be good to see if it builds without problems and make sure it works as well - we're just between beta1 and beta2 of the release, so we're cautious about huge changes which go in now
<jmelis> dholbach: so just to confirm what I need to do is 1) try building the package in ubuntu 2) fix compilation errors 3) submit a sync request following the guides you sent me
<dholbach> yes
<jmelis> and, where can I find help for 1 and 2?
<jmelis> I don't mean to delegate all the work, but there are certain technical things that I don't have much experience with, for instance, using packages with different names in debian and ubuntu, etc...
<jmelis> And some help would come in really handy
<dholbach> for 1) and 2), I'd do something along these lines:       sudo apt-get install ubuntu-dev-tools; dget -u http://ftp.de.debian.org/debian/pool/main/o/opennebula/opennebula_3.2.1-1.dsc; pbuilder-dist precise create; pbuilder-dist create build opennebula_3.2.1-1.dsc
<dholbach> this will set up a precise build chroot and run a build for you on the current debian package
<dholbach> our general Ubuntu development guide is up at http://developer.ubuntu.com/packaging/html/
<dholbach> but do feel free to ask more questions in here
<jmelis> what if in the control file, the name of the package opennebula depends in have a different name under debian and ubuntu?
<jmelis> the name of the *packages*
<Riddell> micahg: and special magic needed by xubuntu or other flavours your involved in to the lightdm auto login working?
<dholbach> jmelis, you could just test-install it in a chroot (if you don't run Ubuntu precise) to see if it installs and works
<jmelis> ok, I will
<dholbach> super
<jmelis> one more question, since you're in between beta1 and beta2, how much time do I have before I loose a reasonable chance to get opennebula's package sync'd?
<dholbach> it will be quite hard as it is, after Feature Freeze (https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule) we try very hard to just focus on bug fixing updates
<dholbach> the page about the Freeze Exceptions I mentioned above should have some more details
<jmelis> ok, I'll give it a shot asap. Is there any way to update the package once precise has been released? for instance, syncing for 12.10 and backporting? or once precise is release there's no way it can be updated?
<dholbach> https://wiki.ubuntu.com/UbuntuBackports#Requesting_a_Backport will be your friend after the release :)
<dholbach> so yeah, there will be "precise-backports" where updates can go afterwards
<jmelis> thanks a bunch dholbach!
<dholbach> de nada
<jmelis> haha
<cjwatson> dpm: FWIW you might have found 'rmadison -S activity-log-manager' a bit more informative
<nerochiaro> hey folks, i'm on beta1 of precise and just apt-get upgraded,rebooted and now my keyboard stops working every few seconds for a second or so. is this some known issue ?
<dpm> cjwatson, ah, cool, thanks for the tip
<nerochiaro> i also notice i have a process watchdog/0 that every few seconds gets 60% of CPU
<cjwatson> ah, oops, 'bzr merge lp:debian/debconf' would work better if my current directory were the Ubuntu debconf branch not the Debian one
<stgraber> pitti: cool :)
<ogra_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: ogra_
 * dholbach hugs ogra_
<ogra_> :)
<dholbach> dendrobates, happy birthday! :)
<dendrobates> dholbach: thanks
<addy335> hello tell me procedure for install any software which i have in pendrive
<addy335> please any body tell me procedure of install software offline/not connected to internet
<directhex> ...?
<scott-work> ubuntu studio is experiencing uninstallable images while trying to use the -lowlatency kernel as default, bug #955617
<ubottu> Launchpad bug 955617 in ubiquity (Ubuntu) "ubiquity hangs (no activity forever) at configuring target system" [Undecided,New] https://launchpad.net/bugs/955617
<scott-work> luke commented in IRC yesterday, "livecd-rootfs package needs updating to use the lowlatency kernel for studio"
<pitti> uh, do we really keep this?
<ogra_> yes
<pitti> is it now being maintained by the kernel team?
<ogra_> unlike the name suggests it has all ubuntu specifics for live-build in it
<ogra_> oh, you referred to lowlatency
<ogra_> not to livecd-rootfs
<ogra_> ignore me :)
<ogra_> but yeah, i think there was a discussion about the ll kernel at UDS, as long as it stays in universe and has active maintenance its fine iirc
<mhall119> cjwatson: ping
<scott-work> pitti: if you are referring to the lowlatency kernel, there are a few points i would make:
<scott-work> 1. the lowlatency kernel can at a minimum halve the latencies experienced (even on moderate hardware) for audi work.  in some cases, this is the inflection point for whether a system is usable or not
<scott-work> 2. the kernel will be maintained by community (i.e. ubuntustudio-dev team members)
<scott-work> 3. has been discussed quite a bit with UKT and has their blessings
<cjwatson> mhall119: hi
<scott-work> 4. is based on the ubuntu kernel without any invasive patches (i.e. the -rt patch)
<mhall119> cjwatson: hi, I have a couple of FFes I'd like someone to take a look at, I posted them in #ubuntu-release
<pitti> scott-work: it hadn't been update for quite some time, and keeping up with post-release updates won't be trivial
<cjwatson> mhall119: I don't do very much FFe work ...
<apw> cjwatson, so when one installs from an alternate image, is it reasonable to describe the process, using the CD as a pool to do a dbootstrap into the new disk ?
<apw> cjwatson, and the kernel which is in the image would be installed in the normal manner, dpkg -i *.deb
<apw> s/image/in the resulting install/
<cjwatson> apw: debootstrap is only one part of the process
<cjwatson> http://d-i.alioth.debian.org/doc/internals/ has some more information
<apw> cjwatson, thanks will read ...
<cjwatson> apw: this sounds like a second-order question.  what's the primary thing you're trying to discover? :)
<apw> cjwatson, indeed, i am trying to work out why a module i expected to be in an image is not (i think they are saying) in the kernel as installed by the installer, but i am out of touch at the moment to get clarity on the failure
<cjwatson> apw: can I see the original report, and then I can probably walk through it with you?
<apw> cjwatson, oh right now i literally have 'my storage module is missing in the install' and nothing more
<cjwatson> it is much more likely that they are talking about during installation, not after installation
<cjwatson> in which case looking at debootstrap etc. is looking at the wrong end
<apw> cjwatson, which actually could mean "the d-i CD boot kernel is missing X" or "the installed kernel is missing X" ... will have to wait on them getting back to me
<cjwatson> it should be pretty clear if you look at the udebs that your kernel packaging emits
<apw> cjwatson, well i mostly wanted to know if the kernel in the final install is really just a dpkg -i job, if so i know that is right as i can test that
<cjwatson> debian.master/d-i/ et al
<cjwatson> it is
<cjwatson> nothing much fancy there
<apw> yeah that was my expectation, so he must mean the former, which means i can check the d-i bits in preparation
<apw> thanks :)
<scott-work> pitti: currently, TheMuso is helping with updating the lowlatency kernel and there is a plan to document the kernel rebasing per security updates in the blueprint - https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency
<scott-work> pitti: ideally we would like to have three members of the team who _can_ do the updates, but most likely two who are primarily responsible
<robbiew> slangasek: bug 935585 is causing some pain for us regarding openstack on precise, any chance the version of upstart in https://launchpad.net/~jamesodhunt/+archive/bug-935585/ gets in?
<ubottu> Launchpad bug 935585 in upstart (Ubuntu Precise) "[kernel panic] init: log.c:786: Assertion failed in log_clear_unflushed: log->remote_closed" [High,Confirmed] https://launchpad.net/bugs/935585
<cjohnston> m_3: ping
<cjohnston> jcastro: I'll poke you as well...
<robbiew> cjwatson: ^^^...do you know the status of bug 935585?
<ubottu> Launchpad bug 935585 in upstart (Ubuntu Precise) "[kernel panic] init: log.c:786: Assertion failed in log_clear_unflushed: log->remote_closed" [High,Confirmed] https://launchpad.net/bugs/935585
<micahg> Riddell: not that I'm aware of
<cjwatson> robbiew: best to ask jodh directly; it's not come up in team meetings or discussions I've had with him
<cjwatson> robbiew: we'd be more comfortable if we could figure out how to test for it, I expect
<robbiew> cjwatson: ack...jodh? how many irc nicks does he have? lol
<cjwatson> just one new one :)
<jodh> robbiew: I'm just finishing some tests for the next release so a new version including a fix should be available tomorrow/Monday.
<robbiew> jodh: perfect...thanks!
<jodh> robbiew: there is the ppa build version that includes the fix too of course: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/935585/comments/11
<ubottu> Launchpad bug 935585 in upstart (Ubuntu Precise) "[kernel panic] init: log.c:786: Assertion failed in log_clear_unflushed: log->remote_closed" [High,Confirmed]
<robbiew> yep and folks on the openstack list have used it ;)
<m_3> cjohnston: pong
<cjohnston> jcastro: ^
<cjohnston> mornin m_3
<jcastro> let's have this conversation on #ubuntu-community-team
<slangasek> jibel_: so precise-upgrade-lucid-main/amd64 never returned a result yesterday :(  any idea why?
<ogra_> psusi, after i merged your dmraid fix i was wondering why you are still no uploader ... i mean you are active in this channel since years and definitely have submitted tons of patches in that time :)
<psusi> ogra_: hrm... well I suppose getting a PPU would be my next step...
<ogra_> about time :)
<blackbug> I have some fixes for a bug, but gnome-screenshot doesn't have a bazaar branch. How should i upload my changes on launchpad?
<ogra_> blackbug, just add a diff to the bug (and feel free to point me to it)
<micahg> Riddell: I might have misunderstood your question, Xubuntu and other derivatives use a postinst to set certain lightdm defaults
<MacSlow> mvo, poing
<Riddell> micahg: right that's what I wanted to know
<Riddell> micahg: where is that?
<micahg> Riddell: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/xubuntu-default-settings/precise/view/head:/debian/xubuntu-default-settings.postinst
<Riddell> micahg: mmm
<slangasek> brendand: so do I understand from your response to bug #834731 that no one took an image of the disk before wiping? :/
<ubottu> Launchpad bug 834731 in debian-installer (Ubuntu) "Dell PowerEdge R810 fails to mount file system at /dev/sda1" [Medium,Incomplete] https://launchpad.net/bugs/834731
<brendand> slangasek, probably not
<brendand> slangasek, we did it to get the system working and 834731 wasn't in my mind at the time
<slangasek> ok
<slangasek> I'll leave it open-incomplete for now in case someone else runs into the same problem
<brendand> slangasek, i'll check with the lab tech on the off-chance they did, but i'm not hopeful...
<ogra_> psusi, heh, and if your changelog entry would actually have pointed tzo precise it wouldnt have been rejected :P (i fixed that though)
<debfx> micahg: that seems like a bad idea. what happens if you have multiple *-default-settings packages installed that also change the lightdm config?
<micahg> debfx: well, there is an alternatives system for the config, I haven't tried multiple ones personally
<debfx> micahg: it doesn't use the alternatives system to set the default session and greeter. so it looks like it would be race on which -default-settings package was configured/upgraded last.
<micahg> debfx: yep, I wanted a debconf prompt like *dm packages had, but it wasn't implemented that way
<mvo> MacSlow: hello
<debfx> micahg: it seems like a perfect use case for the alternatives system to me but I have no idea if that can be integrated with the lightdm config.
<micahg> debfx: normally the alternatives system is a mess, but in concert with a debconf prompt, it was quite usable, I think it's too late to rework this for 12.04 though, maybe for 12.10 speak with robert_ancell about it
<cjwatson> scott-work_: do you want linux-lowlatency or linux-lowlatency-pae by default?
<cjwatson> scott-work_: hm, and are you sure that's related to bug 955617?  the only connection I see is that you were talking about both at around the same time on IRC :-)
<ubottu> Launchpad bug 955617 in ubiquity (Ubuntu) "ubiquity hangs (no activity forever) at configuring target system" [Undecided,New] https://launchpad.net/bugs/955617
 * cjwatson will look into that one anyway ...
<jibel> slangasek, I don't know, I can't even log in to investigate. I restarted it again with a fresh base image.
<slangasek> jibel: heh, ok
<ogra_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<jibel> mvo, bug 946113 any idea what it is, never seen this before ?
<ubottu> Launchpad bug 946113 in update-manager (Ubuntu) "upgrade to 12.04 Beta 1 update-manager-core install error because of symlink size change" [Medium,Confirmed] https://launchpad.net/bugs/946113
<mvo> jibel: I have not seen this one yet
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: mterry
<seb128> mterry, hey
<mterry> seb128, hello
<seb128> mterry, happy piloting
<mterry> seb128, :)  gets hard so late in the cycle, have to find things worth piloting
<seb128> mterry, if you upload some of the unity list items waiting on the queue (would be nice) please note them in the desktop etherpad
<seb128> mterry, we will batch an email to translator about those
<seb128> mterry, likely tomorrow
<seb128> mterry, we took notes there on what items got added
<seb128> mterry, I saw there was still rb, brasero, and some others on the list
<mterry> seb128, ah...  I thought people were holding off on the quicklist stuff?  if not, I can chew through some of those
<seb128> mterry, no, they should go in, dunno why all other pilots ignored them, they are easy
<seb128> mterry, what ql stuff? the new spec support landed in indicator, unity and desktop-file-utils, we have a bunch using the new format in precise
<seb128> mterry, well anyway feel free to sponsor those and to note the ones you sponsor on the etherpad so we notify translators tomorrow with a list ;-)
<mterry> seb128, k
<mterry> seb128, ah, new spec.  I have to change Deja Dup to use it...
<seb128> mterry, we still support both, but would be nice
<mterry> yar as an upstream I mean, for other shells
<seb128> mterry, you can drop your X-GNOME-Keywords while you are at it btw, I think deja is in the last 3 to still list those ;-)
<mterry> seb128, I have both Keywords and X-GNOME-Keywords.  I still want trunk to work on 11.10
<seb128> mterry, wfm
<scott-work_> cjwatson:  you are correct about the bug/kernel lacking correlation.  i had misunderstood micahg about updating the meta files.
<cjwatson> I've split it out to a separate bug
<scott-work_> cjwatson:   i understand what a pae compiled kernel is intended to achieve, but i wonder if there are reasons not to choose it in this case
<scott-work_> cjwatson:  my first thought is too keep it as simple as possible and choose linux-lowlatency
<cjwatson> it's your call, I don't really want to be involved beyond applying it :)
<cjwatson> (you plural I guess)
<scott-work_> i understand, how soon do you require a definitive answer?
<cjwatson> before beta 2 freeze, so <1 week
<scott-work_> cjwatson: let's not muddle this more than absolutely required, please use linux-lowlatency
<scott-work_> and thank you again for all your attention and work
<cjwatson> 'k
<scott-work> cjwatson:  after some other discussion, i would like to reverse my decision and use the linux-lowlatency-pae by default
<cjwatson> scott-work: heh, ok, can you log that discussion in bug 956250 and reopen it, please?
<ubottu> Launchpad bug 956250 in livecd-rootfs (Ubuntu) "default to lowlatency kernel for ubuntustudio builds" [Undecided,Fix released] https://launchpad.net/bugs/956250
<scott-work> indeed i shall
<scott-work> cjwatson: unfortunately, i cannot change the status of that bug, although i did add the conservation to the report
<scott-work> astraljava:  don't forget about the ubiquity background/text bug too, if you can.  i would really like to get that one resolved before B2 if possible
<scott-work> err, wrong channel
<Riddell> sladen: does the ubuntu font have the new turkish lira symbol?
<Riddell> sladen: http://en.wikipedia.org/wiki/Turkish_lira#Currency_sign
<micahg> cjwatson: scott-work: bug reopened
<scott-work> thank you
<cjwatson> scott-work: right, done then
<psusi> slangasek: if I understand your patch for the udev/lvm issue correctly, you have udev check to see if there are any pending events that involve the cookie, and delay exiting untill they have been processed ( thus unlocking the semaphore )
<psusi> slangasek: isn't the problem more broad than just cookie events though?  shouldn't udev not be dropping ANY events?
<psusi> slangasek: i.e. when told to exit, it should stop reading from the netlink socket, but complete processing of any events it already has read ( not just ones specifically involving the DM cookie )
<tomreyn> micahg: do you think you might have the time to look into #955383 today (I've been told you were considering to take on it)?
<tomreyn> i don't want to be pressing, this is just meant to be a friendly reminder since you surely have a lot on your list
<tomreyn> (and we're a little worried not knowing the exact deadline)
 * micahg wonders what he forgot to do
 * JackyAlcine_ waits for the day that we have one million bugs reported.
<tomreyn> i don't mean to say you forgot to do it ;)
<micahg> tomreyn: oops, yeah, sorry, I never finished my work last night, so it spilled over into this morning
<tomreyn> cool, as long as it's still on the list and you are aware of the deadlines involved that's perfect. and thanks for offering to take on it.
<Q-FUNK> https://bugs.launchpad.net/xkeyboard-config/+bug/738314/
<ubottu> Launchpad bug 738314 in console-setup (Ubuntu) "xkb-data: incorrect Finnish kotoisuus keymap" [Medium,Triaged]
<Q-FUNK> this was fixed at Debian ages ago but, for some reason, was never merged.
<sladen> Riddell: need to wait for a Unicode codepoint
<Riddell> sladen: ah turkish government a bit slower than the indian government
<sladen> ~,
<bmoez> I have problems with APT system. it happend to me two times errors like this place.
<bmoez>     $ sudo apt-get ( upgrade Or install -f ..)
<bmoez>     Lecture des listes de paquets... ErreurÂ !
<bmoez>     E: Encountered a section with no Package: header
<bmoez>     E: Problem with MergeList /var/lib/apt/lists/tn.archive.ubuntu.com_ubuntu_dists_precise-updates_multiverse_binary-i386_Packages
<bmoez>     E: Les listes de paquets ou le fichier Â«Â statusÂ Â» ne peuvent Ãªtre analysÃ©s ou lus.
<bmoez> synaptic (or gdebi ...) went i open it , it close with error. lubuntu and ubuntu software center don't open
<bmoez> i don't know how to report this bug in launchpad
<bmoez> what is the log file to post?
<JontheEchidna> try running sudo apt-get update
<bmoez> i tried
<JontheEchidna> hmm, try removing that file and then re-updating
<slangasek> psusi: it's a deliberate upstream change; the reason it's ok to drop events when exiting is that we restart udev again from the real rootfs and coldplug all the events seen up to that point, so the only events we have to worry about are those that something else in the initramfs is still waiting for.
<kklimonda> does the fact that Kubuntu is still in main means that Canonical will support it (as in provide support to people who buy it from them)?
<Riddell> kklimonda: ask canonical
<kklimonda> Riddell: who can I ask that?
<Riddell> kklimonda: contact details are on canonical.com
<kklimonda> Riddell: I'm afraid I'll get a standard "fill this form and we'll contact you"
<Riddell> you might be right there
<bmoez> JontheEchidna: ok, i delete the file but i have the same error white other files, so, i delete all, and now every thing is good
<bmoez> but for new user it 's dificult
<JontheEchidna> cool, what happened was that somehow the files got corrupted (during download or otherwise)
<bmoez> JontheEchidna: so, why apt dodn't correct it alone?
 * JontheEchidna shrugs
<jalcine> Wouldn't hurt to try it though.
<bmoez> or in update, system ask user to remove files and re-update in easy way for new user
<bmoez> and i think ubuntu software center don't should close directly
<micahg> cjwatson: any chance merges.u.c can get start updating again?
<mhall119> seb128: ping
<seb128> mhall119, hey
<mhall119> seb128: hey, I'm blogging again ;)
<mhall119> this time to get SVG icons for some apps that only have low-res raster images
<mhall119> would you mind reading it over before I publish?
<ajmitch> because seeing those .xpm icons in the dash isn't great? :)
<seb128> mhall119, can do
<mhall119> ajmitch: let's call it less than ideal
<mhall119> seb128: http://people.ubuntu.com/~mhall119/blog/icons.html
<arand> mhall119: If there are no svg icons, are there any benefit to supplying downsized pngs for x48 if the source is, say x128?
<mhall119> arand: possible, but alt-tab can be > 128px too
<seb128> mhall119, no, no, no
<seb128> mhall119, we will not distro patch icons, no way
<arand> Yeah, well say the source is 512x512 then :) I've been trying to figure out how DEs does this and I can't really find an answer...
<seb128> mhall119, that works has to be done upstream
<seb128> mhall119, that blog post is another receipe for disaster
<mhall119> seb128: why not add icons to the distro package
<mhall119> ?
<seb128> mhall119, random reasons I can think about
<seb128> - most packers are not artists, I wouldn't feel qualified to judge of artwork quality for example
<seb128> - icons patches are a pain to maintain
<seb128> - upstream might be unhappy about us changing their brand
<seb128> - there is no reason those changes should go downstream rather than upstream directly
<seb128> - the work is not worth the win
<mhall119> seb128: I specifically say to not change the branch, and coordinate new image file creation with upstream, is that not enough to soothe those points?
<seb128> no
<seb128> the sponsoring queue is still "spammed" with the unity list call you did
<seb128> we are not set up to deal with that level of distro changes
<seb128> you are just flooding dholbach_, and others with sponsoring requests we have an hard time to deal with
<seb128> it's not helping, it's making our job harder
<mhall119> ok, so what would you like me to do, direct people to just work with upstream to get these fixed for 12.10?
<seb128> mhall119, yes, it's out of 12.04 scope in any case, recommend them opening bugs upstream and a tagged bug in launchpad
<seb128> so we can track those and help getting them upstreamed
<seb128> but please no sponsoring requests
<mhall119> seb128: ok, I'll re-work this to focus on upstream coordination
<seb128> mhall119, thanks
<dobey> arand: fwiw, the standard sizes for icons per tango style guidelines is 16, 22 (24), 32, 48, and 256. these are the sizes upstream gnome provides
<arand> dobey: Yeah, but I think that is based heavily on that the smaller sizes are actually different source images, for clarity.
<arand> In that case it's an obvious choice.
<dobey> arand: they aren't, actually
<dobey> arand: well, they are drawn in the same SVG, and extracted to separate PNG images from there
<chrisccoulson> is there any point in providing nice, big, crisp icons when we make them all blurry in the dash anyway?
<arand> Ah, well, I'm going from the point of the source being a raster (oftentimes the case)
<dobey> chrisccoulson: we can draw them pre-blurred in the exact opposite way that the dash blurs them!
<chrisccoulson> heh
<mdeslaur> lol
<arand> If I have a x256 source image which I could either install two versions of, one reisized down to x48. Or just install as x256 and let the DE do the resizing, which would I choose?
<arand> (and the source is a png)
<dobey> arand: let the system do the scaling
<dobey> arand: or draw the smaller sizes which you should have done anyway
<arand> dobey: I'm a mere packager, not an artist ;)
<arand> dobey: That's good to know though, less packaging work :3
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<seb128> could somebody reject https://code.launchpad.net/~dereknance-413/ubuntu/oneiric/klogshow/fix-for-678153/+merge/96059 ?
#ubuntu-devel 2012-03-16
<cjwatson> micahg: looks like it got stuck on a download; I've killed it and hopefully the next run will work better
<micahg> cjwatson: thanks
<smoser> is there some tool i can use to easily get the payload of a debconf value ?
<smoser> ideally very standard.
<smoser> i'm hoping to
<smoser>  a.) dump all keys matching some string
<smoser>   that can be the same package, or not be, thats fine
<smoser>  b.) iterate over items in 'a', and get the value of each
<smoser> for this situation, they're all strings
<smoser> looks lke maybe i can make debconf do what i want
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: RAOF
<Jack_> Hi, Does Ubuntu development have anything to do with developing Grub 2 or configuring Grub 2 for use on Ubunutu?
<JackyAlcine> Well, Grub's a distro-independent kind of thing.
<JackyAlcine> You could set it up for a Windows-only system (though MS would wipe it out with its own boot manager)
<JackyAlcine> If anything, there's probably a few patches made by the dev team here to make it more homely for Ubuntu.
<Jack_> so a query about grub2 wouldn't be relavant here?
<JackyAlcine> All depends, it's IRC, have to ask if you want to know.
<JackyAlcine> I know that I don't know anything Grub-specific.
<Jack_> I was wondering if there was any particular reason why windows boot menu entries don't get parttool (hdX,Y) +boot applied by default?
<Jack_> I have a tri-boot system with windows 7, windows 8 and Ubuntu installed. Both versions of Windows have their own boot manager. Windows 7 will only hibernate, and Windows 8 will only shut down if it has the boot flag set.
<Jack_> So with the default grub2 install, I could only make one work with setting the boot flag, but by adding parttool +boot to the menu entry it works fine.
<JackyAlcine> Well, again, it might be with how Windows communicates with the boot manager itself. Since it's a bit unpredictable (due to its closed nature), it might not work as expected.
<Jack_> Could anything bad result from having Grub set the windows partitions boot flag?
<JackyAlcine> No background with that, I'm sorry.
<Jack_> That's okay. Do you know anyone I could contact about it?
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<jalcine> o.O
<ScottK> slangasek: Now that doko made python arch:any, someone's going to have to do a bit of bootstrapping on archs !i386 since two of it's dependencies need python.
<ScottK> It won't be me, because I'm going to sleep.
<ScottK> Maybe pitti will be around soon.
<ScottK> I'm very tired, so I'm sure I haven't thought through all the implications of no 'python' package on !i386, but I'm pretty sure it's "not good".
<micahg> :(
<micahg> ScottK: thanks for fixing python3-defaults though
<ScottK> I fixed python-defaults too, it just can't build due to uninstallable build-deps.
<ScottK> It's just moving the python-policy generation to the arch:any part of debian/rules.
<ScottK> Maybe this isn't that hard to fix.
<ScottK> It isn't but I'm more tired than it's not hard.
<ScottK> Image builds failing now too.
<ScottK> skaet: ^^^
<ScottK> Good luck and good night.
<micahg> slangasek: are you around at all?
<micahg> slangasek: unping
<micahg> infinity: around?
<pitti> Good morning
<micahg> hi pitti, there was a broken python-defaults upload which made python uninstallable on !i386, I reverted the change to unbreak the archive (hopefully)
<pitti> micahg: ah, thanks
<micahg> pitti: I just hope nothing else was depending on that change other than multiarch
<micahg> pitti: I wonder if the python3-defaults upload needs to be reverted as well
<micahg> bug 934593
<ubottu> Launchpad bug 934593 in python-defaults (Ubuntu) "python-all-dev, python-dev must be Arch: any for multiarch" [Low,Triaged] https://launchpad.net/bugs/934593
<micahg> python3-defaults is currently depwait on ~i386
<slangasek> sounds like the sort of change that should have gone through the FFe process; I'd say revert it, at least for now
<micahg> slangasek: python3-defaults?
<slangasek> yeah
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> micahg: looks like it
<pitti> micahg: yes, a reversion definitively sounds like the right and quick thing here, as it breaks half the archive right now
<micahg> pitti: python-defaults should fix precise_probs
<pitti> unless you know exactly what to fix
<micahg> I"m flying blind here :)
<pitti> there's a fair amount of python3* stuff there, too
<pitti> micahg: right :) so, our new policy is to revert
<micahg> ah, ok, then I should upload this quick
<pitti> micahg: thanks!
<micahg> pitti: uploaded
<pitti> cheers!
 * micahg hopes the beer reappears soon
 * slangasek waits for beer on https://jenkins.qa.ubuntu.com/view/Precise Upgrade Testing Dashboard :)
<pitti> slangasek: there's still 5 armel packages which are uninstallable; so no beer today :/
<slangasek> phooey
<slangasek> micahg: so did you revert python-defaults entirely?
<micahg> slangasek: yes, is that bad?
<slangasek> oh, well, it's suboptimal from my POV :)
<slangasek> I was only after python-all-dev, python-dev being marked Arch: any; I don't know why python also got marked Arch: any
<micahg> slangasek: with your multiarch hat or your manager hat?
<slangasek> with my multiarch hat only ;)
<slangasek> you're well within your rights to have reverted the whole thing, just wanting to make sure I understand the current status
<micahg> slangasek: I didn't have the expertise to fix it properly, nor the time, I figure you and doko can work out the right thing in a fraction of the time it would take me to do it :)
<micahg> I'm still curious about the binary domination in that case though
<slangasek> yeah, I dunno
<infinity> micahg: Err, around now.  I assume it was about the python mess?
<micahg> infinity: yeah, was going to ask you to bootstrap, but I reverted instead, in the end, it might not be needed at all
<infinity> It wouldn't need to bootstrap, it would just need them all to build in the same publisher cycle (or i386 last).
<micahg> infinity: or that :), I'm wondering why that's the case though
<infinity> micahg: The reason it all went pear-shaped was because doko's first upload was FTBFS on !i386, due to missing build-deps.
<infinity> micahg: And by the time he fixed that, the i386 packages had been uploaded, making python unintallable on all other arches.
<infinity> micahg: So, yeah, if his change had been done properly, and in one publisher cycle, no one would have ever noticed.
<micahg> oh, I think I figured out the answer to my question
<infinity> micahg: So, I stick with my assertion that if we want this change, we just need to revert your revert, and it'll work fine.
<infinity> (After your packages are published)
<infinity> slangasek: ^^
<infinity> micahg: Basically, if you're positice that -9ubuntu5 builds on !i386 with dpkg-buildpackage -B, it would be safe to reupload that as -9ubuntu7
<infinity> positive, too.
<infinity> micahg: But also perfectly valid to leave it as-is and let slangasek and doko argue about it later. ;)
<micahg> infinity: yeah, well, I tested that, but with a slightly behind mirrror
<micahg> infinity: I'd rather let them sort it out as I have other things to do before bed
<infinity> micahg: Sure, the behind mirror bit is fine, since that would simulate the current fixed situation. ;)
<micahg> infinity: that's why I uploaded ubuntu5 as a workaround :)
<micahg> infinity: anyways, slangasek said he didn't expect the whole source to be multiarched anyways
<micahg> err..arch any, not multiarched :)
<micahg> umm, there was no need for me to revert python3 defaults apparently
 * micahg fixes
<dholbach> good morning
<jibel> server images 20120316 failed to install this morning bug 956766
<ubottu> Launchpad bug 956766 in debian-installer (Ubuntu Precise) "Ubuntu Server 20120316 failed to install: dpkg: dependency problems prevent configuration of lsb-release" [Critical,New] https://launchpad.net/bugs/956766
<micahg> jibel: should be fixed already
<jibel> micahg, this is fixed with python-defaults 2.7.2-9ubuntu6 ?
<micahg> jibel: yeah
<jibel> micahg, thanks, updating report.
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: jamespage
<pitti> hallyn, Daviey: did you notice that the latest libvirt upload is in depwait, because of the new numa universe dep?
<pitti> sabdfl: Hey Mark, how are you? found an animal with Q yet? :-)
<pitti> Quarreling Quail!
<dholbach> pitti, there's more https://wiki.ubuntu.com/DevelopmentCodeNames#Q :)
<pitti> "Quetzalcoatl"? Wasn't this an Aztec king or so?
<ochosi> pitti: an aztec god
<pitti> aah, off-by-one in the hierarchy
<yellowduino> dholbach: just finished reading your "Getting Started" :)
<ochosi> pitti: could be that historically he was a king first
<dholbach> pitti, an animal too
<dholbach> yellowduino, nice (although I need to be honest - it's not only my work, but that of a bunch of others too :-))
<ochosi> "quirky quokka" (what a beautiful alliteration)
<yellowduino> dholbach: I bet :) I hope to get some things fixed and get involved
<dholbach> yellowduino, rock and roll - I'm looking forward to seeing you here more often :)
<yellowduino> quit
<pitti> Riddell: do you plan a calligra upload soon to fix the armhf FTBFS? If so, could you please slip in the ttf-lyx recommends drop?
<pitti> and perhaps also the missing transitional packages, to fix upgrde
<Riddell> pitti: good point, I'll try and do that today
<pitti> Riddell: cheers
<dholbach> thanks everyone who helped to get the sponsoring queue from ~50 to ~30
<dholbach> http://reqorts.qa.ubuntu.com/reports/1glance-sponsoring/
<dholbach> it's nice to see how many did more than 20 review pieces
<soren> What's the correct way to set a dynamically computed, default value in debconf? db_set <template> <default value>; db_fset <template> seen false  ?
<dholbach> you all rock
<seb128> dholbach, \o/
 * dholbach hugs seb128
<seb128> dholbach, thanks for keeping the ball rolling and making sure new contributors are well received ;-)
 * seb128 hugs dholbach
<dholbach> I can't take credit for all the good review work :)
<ogra_> no, but for the nagging work :P
<ogra_> without that we wouldnt be there ;)
<dholbach> go back to doing some reviewing work then! *crack whip*
<dholbach> :-P
<ogra_> lolk
<tseliot> cjwatson: do you know if there's a way to prevent grub from using "vt.handoff=7" without disabling the splash in /etc/grub.d/10_linux? Not all drivers play well with it
<MacSlow> mvo, so yesterday evening the result was still the same... update failed due to the libtinfo5 circular dependency-issue.
<ev> anyone particularly good with x86 assembly? I'm running into difficulty trying to build syslinux from 10.10 on precise using precise's nasm, which blows up with "cannot mix real and virtual attributes in nobits section"
<davmor2> ev: man you just hate yourself don't you with this whole how can I make my life harder and uglier attitude ;)
<ev> heh
<dholbach> can https://code.launchpad.net/~dereknance-413/ubuntu/oneiric/klogshow/fix-for-678153/+merge/96059 please be rejected based on the last two comments?
<pitti> dholbach: *zap*
<dholbach> thanks pitti
<jamespage> dholbach, thanks - I'll remember that trick in future :-)
 * jamespage comes up for air (and coffee)
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<jamespage> can https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/distribute/oneiric-updates/+merge/94896 be rejected as well - its not required (see comments)
<jamespage> ta
<pitti> jamespage: done
<jamespage> pitti, thankyou!
<mdeslaur> cyphermox: so, when I create an adhoc WPA2 network, and look at wpa_supplicant's status, it's showing "group_cipher=TKIP", but "pairwise_cipher=NON". This explains why scanning shows it as being protected, but you can still connect without a password.
<cyphermox> mdeslaur: no
<mdeslaur> cyphermox: hehe, no what?
<cyphermox> AFAIK adhoc WPA is supposed to be pairwise none. :)
<cyphermox> WPA adhoc is key-mgmt=wpa-none; pairwise=none ; group=tkip
<cyphermox> mdeslaur: I do think that's correct, as is documented as the proper config
<mdeslaur> cyphermox: that doesn't make sense...why do you say that's the proper config?
<cyphermox> mdeslaur: pairwise=none is the right way to configure adhoc.
<mdeslaur> cyphermox: yes, you've said that already...show me the spec :)
<cyphermox> mdeslaur: not quite spec, but it's documented in multiple places as such; see http://lists.shmoo.com/pipermail/hostap/2011-July/023483.html
<mdeslaur> yes, I agree that people keep pasting the wrong config :)
 * mdeslaur researches further
<cyphermox> no, it's also elsewhere, just a second
<cyphermox> mdeslaur: you can also see the example config for IBSS in wpa_supplicant.conf shipped in the wpasupplicant tarballs; bzr branch ubuntu:wpasupplicant; vi wpassupplicant/wpa_supplicant/wpa_supplicant.conf
<mdeslaur> hrm, yeah, it does say that there
<cyphermox> mdeslaur: even if you use IBSS/RSN, it's still showing as unsecured sometimes
<cyphermox> or android can't connect to it, so I'm thinking it's busted anyway
<cyphermox> mdeslaur: IBSS/RSN (wpa2) is with mgmt=wpa-none, proto=rsn, pairwise=ccmp, group=ccmp
<pgraner> seb128, looks like the gnome-settings-daemon is crashing on my wacom tablet again
<mdeslaur> cyphermox: yeah, let me read the specs...something fishy here
<pgraner> seb128, http://pastebin.ubuntu.com/886295/
<seb128> pgraner, you never replied to my comment on the bug where I asked if the patch we put it last time was working btw...
<seb128> pgraner, they might just have dropped it since you never came back to us
<seb128> pgraner, let me check
<pgraner> seb128, sorry I must have missed it in the bug mail. It was working fine until today
<seb128> pgraner, weird
<seb128> pgraner, can you run dpkg -l | grep gnome-settings-daemon and give me the version listed?
<hrw> where I can report wishlist for http://qa.ubuntuwire.org/ftbfs/ list?
<pgraner> seb128, pgraner@zorak:~$ dpkg -l | grep gnome-settings-daemon
<pgraner> ii  gnome-settings-daemon                  3.3.91-0ubuntu6
<hrw> would be great to have tags from bug number listed there - as most of armhf bugs now are Ada/FreePascal/Haskell/OpenGL related
<davmor2> Is anyone else having difficulties trying to grab the scroll bar overlay buttons
<carif> not sure I'm asking this question in the right place, when I dch -i for some pkgs and change the version in the changelog, the source directory is modifed to match when I exit. This works for some pkgs and not for others (it seems intermittent). Any reason why? I like the behavior and want to see it always happen
<seb128> pgraner, weird, the fix is still there, can you report a bug using apport?
<pgraner> seb128, sure, one thing to note is, when the machine first boot with the tablet connected, g-s-d crashes and for some reason apport never sees it, the only way I noticed was I had the old gnome theme
<pgraner> seb128, then I started g-s-d form the command line and got that output
<seb128> pgraner, can you check /var/log/apport.log?
<pgraner> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/956956
<ubottu> Launchpad bug 956956 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashes when Wacom Tablet is plugged in" [Undecided,New]
<seb128> pgraner, is there any way you could report it through apport so we get a stacktrace? there is not a lot we can do without one
 * dholbach hugs jamespage
<jamespage> dholbach, ta
<dholbach> :)
<pgraner> seb128, got it, new bug https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/956962
<ubottu> Error: launchpad bug 956962 not found
 * jamespage likes a hug!
<pgraner> seb128, I duped the other one to it
<seb128> pgraner, thanks! waiting for retracing and I will deal with it
<pgraner> seb128, cool, I'm here all day if you want to me to do anything
<seb128> pgraner, ok, I might ping you back in a bit for extra infos, thanks ;-)
<dholbach> we're down to 18 items in the queue - I didn't think I'd live to see this happening
<jamespage> dholbach, w00t!
<ajmitch> dholbach: that's great
<cyphermox> mdeslaur: finding anything?
<mdeslaur> cyphermox: finding que c'est compliquÃ© en tabarnak
<cyphermox> lol
<mdeslaur> cyphermox: how have you not gone insane yet? :)
<cyphermox> mdeslaur: redefine sanity.
<mdeslaur> hrm, desktop team, network manager and evolution...yeah...too late :)
<hrw> does someone has any idea of visualvm? bug 935481
<ubottu> Launchpad bug 935481 in visualvm (Ubuntu Precise) "visualvm version 1.3.2-0ubuntu1 FTBFS on i386 in precise" [High,New] https://launchpad.net/bugs/935481
<ockham> pitti: hi, just added a comment to bug #956098
<ubottu> Launchpad bug 956098 in icc-profiles (Ubuntu) "FFe: Sync icc-profiles 2.0.1-1 (multiverse) from Debian sid (non-free)" [Undecided,Incomplete] https://launchpad.net/bugs/956098
<pitti> ockham: ah, splendid! sorry, missed the link to the other bug
<pitti> ockham: I'll sync both now
<ockham> pitti: np
<ockham> pitti: great, thx!
<lamont> is it too much to ask ghc to reap its dead children more frequently?
<ajmitch> lamont: is it causing a few issues on the buildds?
<lamont> it is making them yell at me
<lamont> this is not nice of it
<lamont> PROCS CRITICAL: 25 processes with STATE = Z
<ajmitch> oops
<lamont> specifically washngo and pandoc
<lamont> at least so far
<ajmitch> lamont: there's only another ~100 packages to go :)
<lamont> remind me to hurt you. :-p
<ajmitch> blame Laney, not me!
<lamont> Laney: fwiw, ajmitch just threw you under the bus. :-p
<ajmitch> he's used to it
<lamont> heh
<Laney> :(
<Laney> i'm sure ghc upstream would welcome a bug report â¥
 * Laney fades away
<pitti> slangasek: mono prerm bug> can't this be fixed in precise as well, for people who don't install SRUs before dist-upgrading? prerm failed-install or so?
<pitti> (it should still be an SRU, I figure)
<slangasek> pitti: the root bug isn't in the prerm of the package being removed; and the package being removed doesn't exist in precise
<pitti> ah, that'd spoil it of course
<pitti> thanks
<slangasek> it's a script being called from the prerm of each -cil package that's being removed as part of the upgrade
<G__81> Hi I am interested in contributing to Ubuntu. I am not sure whether this is *the* channel to ask, if not can someone point me to the right channel ?
<slangasek> jibel_: https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/ shows as a "failed" test due to conffiles, but there are no details available about what conffiles are wrong; do you have more information?
<pitti> heh, indeed; the console output says
<pitti> AssertionError: Obsolete config file found. Check log file '/var/log/dist-upgrade/obsolete_conffiles.log'
<pitti> and further down
<pitti> scp: /tmp/obsolete_conffiles.log: No such file or directory
<mr_pouit> pitti: thanks for the indicator-applet fix! (now i've the same issue with lightdm recommending unity-greeter ;D)
<pitti> mr_pouit: ah, lightdm gets installed before resolving the xubuntu-desktop dependencies all over again, argh
<pitti> mr_pouit: can you please file a bug about it as well, and subscribe me? we need to discuss that with a few people
<mr_pouit> pitti: this is because xubuntu-default-settings depends on lightdm (>= 0.9.3-0ubuntu2), x11-common (>= 1:7.6+7ubuntu2), lightdm-gtk-greeter (>= 1.0.0-0ubuntu2)
<mr_pouit> pitti: if I swap them, it should be fine
<mr_pouit> (I'll try, and file a bug later if it doesn't help)
<pitti> mr_pouit: ah, it's x-d-s itself?
<mr_pouit> yeah
<pitti> mr_pouit: in the other bug, i-applet was pulled in much earlier
<pitti> so this seems to be easier then
<pitti> mr_pouit: I'm nto sure whether the order of dependencies matters, though
<pitti> mr_pouit: you might try dropping the lightdm dependency perhaps?
<pitti> it should then resove x-desktop -> gtk-greeter -> lightdm with already fulfilled greeter dep
<mr_pouit> it was required because earlier versions didn't ship lightdm-set-default. But that was for oneiric only, so this should be fine now
<mr_pouit> I'll try that then, thanks.
<ogra_> diwic, yo ... seems your last upload reverted a fix from adam ... could it be that your bzr tree is out of sync ?
<ogra_> diwic, (alsa-lib that is)
<diwic> ogra_, I don't have upload rights, but I have seen fixes from adam earlier which he has not committed to the bzr tree, so that's recipe for failure if you ask me...
<ogra_> diwic, well, would be nice if alsa-lib could just use UDD ... then it would have been automerged
<ogra_> i ran into that issue as well several times before
<diwic> ogra_, TheMuso is the one you want to talk to about that
<ogra_> k, will note that down for a UDS evening :)
<dholbach> what is the best way to replace duplicate files with symlinks?
<ogra_> take your microphone and tell it to the HUD ?
<ogra_> ah, wait, that was 14.04
<dholbach> ogra_, it's not working for you?
<dholbach> :-P
<ogra_> :P
<dholbach> maybe you have too much noise in the background :)
<ogra_> haha, i sure do
<dholbach> shadeslayer, congratulations!
<shadeslayer> thanks!
<shadeslayer> :)
<abeer> hi, is anybody here planning to be a mentor at Google Summer of Code?
<ScottK> Ubuntu isn't in GSoC.
<abeer> There was a thread
<abeer> where one of the developers posted that Ubuntu would be participating GSOC '12
<abeer> there was a search for mentors as it missed out in 11.
<micahg> yeah, we missed the deadline by ~10 minutes apparently
<abeer> oh damn! I was really hoping to work under Ubuntu
<micahg> abeer: you still can, just not under the GSoC banner :)
<abeer> The thing is I am new to world of submitting code
<abeer> GSOC would have been an opportunity where I could have a mentor who would be able to guide me completely towards the completion of a project.
<ScottK> Depending on what you want to do, you can accomplish similar things independent of GSoC, just with a little more team approach.
<abeer> Well, the thing is I have experience with Java to make small applets and am kind of proficient in C++.
<bdmurray> pitti: ubuntu-bug should work with a command name for example do-release-upgrade right?
<abeer> I've been trying to pick Python up so I can contribute using quickly as shown on the dev page,  but I can't figure out what would be the best way of go about learning Python as there are an umpteen number of resources available.
<ScottK> Python is (IME) generally easy enough that the best way is to find some problem and figure out how to solve it.
<ScottK> Careful what you admit about C++ knowledge or apachelogger will try to steal you away to work on Kubuntu (which also uses a lot of Python)
<apachelogger> see plus plus
<apachelogger> best thing since godzilla
<mfisch> Ampelbein: ping
 * Sweetshark is looking for a brave sponsor.
<Sweetshark> kenvandine, cjwatson, bryceh, mdeslaur, mterry: anyone volunteering to sponsor the upload of 3.5.1-1ubuntu1 to be found in /home/bjoern on chinstrap?
<Sweetshark> micahg: ^ (just skimming through timezone data)
<micahg> Sweetshark: sorry, in the middle of too many other things
<bryceh> Sweetshark, yep can do
<Sweetshark> bryceh: great, thanks!
<micahg> Sweetshark: I wonder if Friday EOD is the best time for a new LibreOffice code drop
<bryceh> Sweetshark, upload sponsored
<bryceh> micahg, fair point, sorry didn't see your comment before I pushed the button
<chrisccoulson> Friday EOD is actually the best time for a new LO code drop, because you won't have to worry about it for 2 days if it blows up :-)
<chrisccoulson> j/k ;)
<bryceh> hehe
<bryceh> well, for better or worse the upload got rejected
<micahg> \o/
<chrisccoulson> in any case, doesn't it take pretty much the entire weekend to build?
<micahg> I thought it was down to just over a day on teh pandas
<micahg> yep, ~31 hours
<bryceh> Sweetshark, I've emailed you what LP sent back.  For some reason it didn't pick up the various tar.gz files
<bryceh> (did you run debuild -S -sa ?)
<bryceh> going to run it through pbuilder and maybe a ppa first, for now.
<bryceh> Sweetshark, out of curiousity, how is testing handled with libreoffice uploads for ubuntu?
<Sweetshark> bryceh: gah, yes. I didnt switch back to -sa for the new upstream upload.
<Sweetshark> mom
<ScottK> micahg: If Thursday, way past COB is a good time to break the archive, I think Friday COB is a great time for an LO upload.
<bryceh> Sweetshark, also, even with the -sa added my pbuilder is croaking on it
<bryceh> (which admittedly might be local pbuilder borkage)
 * bryceh chucks it into ppa:bryce/lo-3.5.1
<Sweetshark> bryceh: I am always building on a pbuilder here (one for the source package and one for the binary build). The debs build from that then are smoketested in a VirtualBox (open some document etc.)
<Sweetshark> (the pbuilders are kicked off from a jenkins instance)
<Ampelbein> mfisch: re-ping!
<bryceh> hmm, my pbuilder still operates on X packages ok
<bryceh> libexttextcat-dev (>= 3.1.1) maybe?
<mfisch> Ampelbein: I have an update on a ftbfs that you worked on bug #935385
<ubottu> Launchpad bug 935385 in python-djvulibre (Debian) "python-djvulibre version 0.3.3-1 FTBFS on i386 in precise" [Unknown,Confirmed] https://launchpad.net/bugs/935385
<mfisch> Ampelbein: unfortunately, I don't know how to proceed, I'm not sure I have the ability to pull and then post a new upstream version
<Ampelbein> mfisch: Everyone can pull current packaging and propose a merge via the sponsorship process.
<Ampelbein> mfisch: Let me quickly check that report.
 * Sweetshark watches ppa build
<Sweetshark> bryceh: the ppa seems to build, doesnt it? did it break earlier at your local pbuilder?
<bryceh> Sweetshark, yeah looks like it's doing better in the ppa
<bryceh> Sweetshark, yeah in pbuilder it terminates on unsatisfied deps, even after freshly updating it.  One of the packages is 'uninstallable'
<bryceh>                                  Depends: libexttextcat-dev (>= 3.1.1) but it is not installable
<lborda> Hi guys, I am running precise (upgraded from oneiric) and one of the updates crashed unity. I was able to upgrade the packages again but now every time I press right-click on the mouse unity crashes and restart again... Any idea?
<bryceh> lborda, collect backtrace, file a bug
<Sweetshark> bryceh: strange, I remember having that too, but it was transitional.
<bryceh> libexttextcat-dev  precise  3.2.0-1ubuntu1
<lborda> bryceh, should I use use ubuntu-bug unity ?
<bryceh> lborda, yes
<lborda> alright tks
<Sweetshark> bryceh: libexttextcat was only recently MIRed, maybe your mirror does somehow missed out on that?
<bryceh> ah, could be
<Sweetshark> s/does/did/
<bryceh> yep, showing it in universe
<bryceh> Sweetshark, this is pulling from us.archive.ubuntu.com
<micahg> Sweetshark: it's still in universe
<Sweetshark> micahg: indeed.
<Sweetshark> https://bugs.launchpad.net/ubuntu/+source/libexttextcat/+bug/938582
<ubottu> Launchpad bug 938582 in libexttextcat (Ubuntu) "[MIR] libexttextcat" [Undecided,Fix released]
<micahg> well, nothing is depending on it
<micahg> oh, hmm, there is a recommends
 * micahg wonders why that's not on component-mismatches
 * Sweetshark is a bit confused by the MIR being "Fix Released", although it is not in main yet.
<slangasek> Sweetshark: because pitti promoted it to main before it was seeded, which means the next archive admin to come along demoted it back to universe ;)
<Sweetshark> slangasek: nasty archive admins!
<Sweetshark> slangasek: should I reopen the MIR?
<slangasek> no
<slangasek> is there something that pulls it into main now?
<bryceh> slangasek, libreoffice
<slangasek> i.e., has the LibO that uses it been uploaded?
<bryceh> slangasek, no, it doesn't build in my pbuilder due to the missing dep, so I've hesistated uploading it
<slangasek> ah
<slangasek> bryceh: can you turn universe on for testing in your pbuilder?
<slangasek> although... how long is a build test of this going to take? :)
<bryceh> slangasek, I popped it into a ppa where it appears to be building ok
<slangasek> ok
<Sweetshark> slangasek: I am always building in a pbuilder here fwiw
<slangasek> yeah - component mismatches don't block being able to build with pbuilder
<slangasek> it's just bryce's particular pbuilder config
<slangasek> anyhoo
<slangasek> if someone gets that uploaded to precise, I can take care of the promotion straight away
<bryceh> slangasek, build logs going @ https://launchpad.net/~bryce/+archive/lo-3.5.1/+packages
<bryceh> slangasek, shall I wait until that ppa has finished building, or does it look ok to send it in now?
<Sweetshark> slangasek: 15min for the source, 2:10h for the binary build with ccache (on a quad i7 notebook with 16GB RAM). 3:30h without ccache.
<slangasek> bryceh: I would be inclined to upload it straight away
<bryceh> slangasek, micahg also raised the issue of it being past COB Friday... worth waiting until monday?  since it takes so long to build anyway, perhaps it doesn't matter?
<slangasek> what's the build-time on armel?
<bryceh> slangasek, alright.  I'm comfortable with that given Sweetshark's testing practices
<bryceh> micahg, your thoughts?  still think it being friday is a red flag?
<slangasek> bryceh: if the world explodes after you upload, are you going to be around to help clean it up? ;)
<micahg> slangasek: arm* build time on the pandas is 31 hours
 * slangasek nod
<slangasek> so I think it would be a good idea to get it built over the weekend
<Sweetshark> fyi, the oneiric backport ppa builds took 6:38h on i386 and and 6:40h on amd64.
<micahg> right, that's the questions if bryceh or someone else and Sweetshark are committed to being around to fixing issues, I don't have a problem with it
<bryceh> slangasek, I'll be gone much of the day Saturday but am here for the next 4 hrs at least
<Sweetshark> arm build time is why I would like to have this in before the weekend ;)
<slangasek> I can keep an eye out tomorrow
 * micahg would think with the package's history, it would be more prudent to upload very early monday
<micahg> i386/amd64 hit Monday, everything else tuesday
<micahg> but if there's coverage for breakage, then it doesn't matter when
<Sweetshark> its 2300 local here. I can be around tommorrow till around noon but not later. sunday i could be on guard.
<bryceh> I'd be willing to pop in to do the upload Saturday night my time.  Should only take a few minutes, not a big deal
<bryceh> not sure what plans I have for sunday, but probably will be checking in periodically
<Sweetshark> bryceh: that would be great. I would be around to take the bullets when it finishes then ...
<micahg> Sweetshark: re libexttextcat> sometimes, things get promoted prematurely, but then get demoted since nothing depends on it
<micahg> they
<micahg> * they're supposed to remain Fix Committed until it's seeded or depended on
<micahg> but there is a recommends in this case, so I have no idea
<Sweetshark> micahg: k
<Sweetshark> just leaving stuff as is then for now
<mterry> Is there an easy way to test software under a VPN?  (like a demo VPN test server somewhere?)
<Sweetshark> micahg, bryceh, slangasek: thank you very much.
 * Sweetshark wanders of for the night.
<bryceh> Sweetshark, great sounds like a plan, will pick it up Sat night
#ubuntu-devel 2012-03-17
<bryceh> Sweetshark, build failure https://launchpadlibrarian.net/97075037/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.1-1ubuntu1_FAILEDTOBUILD.txt.gz
<bryceh> maybe...  mkdir: cannot create directory `../../unxlngx6.pro/misc/pcr/': File exists
<bryceh> got to go (dinner)
<jalcine> lol, I thought that said "sweetheart".
<slangasek> bryceh: so has this not been uploaded to precise yet?
<wigs> aptitude 0.6.5 still no support for m-a, many affected users on lp
<wigs> basic m-a support *nearly* complete in git
<wigs> still time to integrate this for precise-beta?
<wigs> (many users on lp complain)
<slangasek> wigs: it may or may not land in time for beta, though we expect it to be resolved for the final release
<wigs> you have people working on it?
<wigs> or just following upstream dev.?
<wigs> libept/exp is an issue atm, bad build-dep causes it to link against libapt-pkg4.10 in Debian
<wigs> but has built ok on Ubuntu buildds (go figure)
<wigs> see bugs.d.o/663201
<slangasek> wigs: no one's working on it, but we know the upstream status and will pull the support in if we can
 * wigs upstream
<wigs> can upload changes as soon as libept build-dep is resolved
<wigs> fixes all big issues with m-a
<scientes> where are the scripts that ubuntu uses to build the liveCDs?
<scientes> (and is their documentation)?
<nigelb> scientes: Are you looking to make a customized Live CD?
<scientes> yes, but i want to be able to customize it in place, i.e. use it as a regular system first
<nigelb> https://help.ubuntu.com/community/LiveCDCustomization might help.
<scientes> like, how does your system differ from a standard debootstrap
<scientes> do you have like two versions of some files for live/installed
<scientes> like /etc/passwd
<nigelb> I don't know the answer to those and asking on the weekend is less likely to yield answers.
<nigelb> If you could probably try back on a weekday, someone who knows tha answers should be around.
<scientes> nigelb, thx
<bmoez_> is it possible to run lubuntu in RAM like puppy?
<apw> cjwatson, i am sure you are not about, but it would be nice to have d-i updated for the -19 kernel to get updated ISOs for monday
<mr_pouit> cjwatson: hey, I think something went wrong with the non-pae change for xubuntu/precise/i386 (there's no daily generated since yesterday)
<mr_pouit> cjwatson: mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/xubuntu/daily-live/tmp/precise-i386/CD1/casper/filesystem.kernel-generic': No such file or directory
<mr_pouit> (not sure why I didn't receive a failure mail for that though)
<yellowduino> phew
<yellowduino> at last
<cjohnston> m_3: ping
<DoctorPepper> hi guys !!!
<DoctorPepper> is any of the maintainers of  mono in here ?
<jtaylor> DoctorPepper: they hang out in #debian-cli on freenode
<jtaylor> irc.debian I mean
<jtaylor> .org
<DoctorPepper> are you talk about the people that manage the mono package for ubuntu
<jtaylor> mono is for the most part maintained in debian and just synced to ubuntu
<DoctorPepper> actually i have issue installing mono dev  pacakges on ubuntu 11.10
<jtaylor> what kind of issue?
<DoctorPepper> see : http://pastebin.com/sLwUJn7V
<jtaylor> do you have symlinks in /usr/lib/mono/4.0/?
<DoctorPepper> yes
<jtaylor> is /usr/lib/mono/4.0 itself a symlink?
<DoctorPepper> no
<jtaylor> can you paste  ls -l /usr/lib/mono/*/* please
<jtaylor> this kind of failure is usually caused by a symlinked directory, but that should not be the case in mono packages
<DoctorPepper> http://pastebin.com/iDKLqUHj
<Darxus> What's the irc channel for talking about running the Beta?
<Darxus> #ubuntu+1
<DoctorPepper> can anyone help me please , i have issue with install libnunit2.5-cil  mono-devel  i get  the following errors  http://pastebin.com/42kczJ8J
<jtaylor> something is weird on your system, try reinstalling mono, apt-get install --reinstall mono
<DoctorPepper> yep i know
<DoctorPepper> thanks now it works
<scientes> <scientes> I used ubuntu's kernel config to compile my own kernel (i did use oldconfig too)
<scientes> <scientes> and not i cant use ptrace, even as root
<scientes> i dont have yama, so what do i do?
<imbrandon> scientes: did you use the info at http://kernel.ubuntu.com and https://wiki.ubuntu.com/Kernel/Dev/KernelBuildScripts ?
<imbrandon> no idea past that
<scientes> nah, i dont think i need any of that
<scientes> the problem is a mismatch between features of the ubuntu kernel and upstream kernel
<scientes> and me not having every config option memorized
#ubuntu-devel 2012-03-18
<Sweetshark> whoever thought it would be a good idea to define enum entries with totally nongeneric names like SETTINGS_MOUSE SETTINGS_LOCALE which will never ever be used anywhere else in any project ...
<Sweetshark> ... and then put that in a _header_ file with very limited visibility: something called "kglobalsettings.h" (the name of the file is actally kind of a hint), needs to be awarded a medal.
<Sweetshark> and then be shot. and flogged, just to be sure.
<Sweetshark> </sarc rant>
<Sweetshark> bryceh: ^^
<jcastro> mhall119, dns for OMG caught up for you yet?
<ScottK> Riddell: ^^^ might be something to discuss with upstream since they're redoing everything now anyway.
<tomreyn> micahg: thanks for having dealt with the MegaGlest dependency bug. :-)
<mhall119> jcastro: still redirecting to the aws hostname
<mhall119> jcastro: looks like it's cache on my end
<jcastro> yeah probably caching the 301
<mhall119> jcastro: checked on another computer, DNS is working
<mhall119> jcastro: good job by you and marco
<On|Off> Hello, I've just installed 12.04 to test the HUD but this one seems to be removed ? Thanks.
<Riddell> ScottK: what is something to discuss with upstream?
<yellowduino> so
<yellowduino> anyone up to solving some FTBFS?
<bryceh> slangasek, no didn't upload it last night.  Can upload it now if you want but was hoping for advice on those build failures
<bryceh> <Sweetshark> bryceh: meh, I saw the build failure in the ppa. It seems to be triggered by the last kdelibs update.
#ubuntu-devel 2013-03-11
<xnox> slangasek: i think robert collins by "except for firefox. And kernels."  could also mean linux-lts-quantal which is a new upstream version bump, just like firefox.
<adrian546864> hi there! trying the SDK preview. I couldnt figure out how to use C++ in the "Ubuntu -> Ubuntu UI - Tabs" type of projects. Anytime I want to add a c++ class i get the message "Failed to add one or more files to project". Isnt that implemented yet? Could somebody help me out. I want to play around with but Im unfortunatly not able to... :(
<adrian546864> somebody who can help me with the Ubuntu SDK preview? I want to use c++ for it. is that already supported???
<_NerdyMe_> hi there! trying the SDK preview. I couldnt figure out how to use C++ in the "Ubuntu -> Ubuntu UI - Tabs" type of projects. Anytime I want to add a c++ class i get the message "Failed to add one or more files to project". Isnt that implemented yet? Could somebody help me out. I want to play around with but Im unfortunatly not able to... :(
<pitti> Good morning
<tkamppeter> RAOF, hi
<RAOF> tkamppeter: Happy public holiday!
<tjaalton> :)
<tkamppeter> RAOF, sorry, did not know that today is a holiday for you, can you on tomorrow's workday fix bug 1126427 as soon as possible so that I can update Ghostscript without formal FFe process? Thanks.
<ubottu> bug 1126427 in lcms2 (Ubuntu) "LCMS2 needs multi-threading fixes to work with the new Ghostscript 9.07" [High,New] https://launchpad.net/bugs/1126427
<dholbach> good morning
<RAOF> tkamppeter: Sure.
<cjwatson> Sweetshark,bdrung: Is libmspub just code split out of libreoffice, or is it genuinely new code?
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Dev' 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
<slangasek> xnox: possible; but the lts backport stacks have even less impact on existing users than the stable kernel tree updates do
<pitti> hey slangasek, how are you?
<pitti> dholbach: happy flying
<dholbach> thanks pitti :)
<slangasek> pitti: hey there!  Sorry, I'm late for bed... any chance we can sync up on logind in the "morning"?
<pitti> slangasek: I need to go AFK at 1700 UTC for Taekwondo, so anything before that
<slangasek> pitti: ok
<pitti> slangasek: I just talked to mbiebl some more, I have some TODO today for making standalone logind really work
<tkamppeter> slangasek, is it OK when I update ghostscript from 9.06 to 9.07 on Tue or Wed? It needs bug 1126427 to be fixed first.
<ubottu> bug 1126427 in lcms2 (Ubuntu) "LCMS2 needs multi-threading fixes to work with the new Ghostscript 9.07" [High,New] https://launchpad.net/bugs/1126427
<Sweetshark> cjwatson: code split out of libreoffice. libreoffice 4.0.0beta2 already contained an internal copy (and its a hard dep anyway).
<cjwatson> Sweetshark: All right, thanks.  Since it's a split-out, I've gone ahead and moved it to main without need for an MIR.
<cjwatson> That should unbreak image builds.
<Sweetshark> cjwatson: huh? bug 1124082
<ubottu> bug 1124082 in libmspub (Ubuntu) "[MIR] libmspub" [Undecided,Fix released] https://launchpad.net/bugs/1124082
<infinity> cjwatson: The libmspub thing was a victim of the overrides bug, it was right in proposed.
<infinity> cjwatson: Or was right and then got demoted again due to libreoffice not migrating before slangasek cleared out c-m.  Pick one. :P
<ev> xnox: ah, lovely
<ev> xnox: may I have a bug for that against whoopsie please?
<ev> the upstream project, not the package
<dholbach> bdrung, do you know somebody who could take a look at https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/1080059?
<ubottu> Launchpad bug 1080059 in audacious-plugins (Ubuntu) "ffaudio plugin is not being built " [Medium,Triaged]
<cjwatson> Sweetshark: Ah, right
<cjwatson> infinity: I think the latter.  I noticed it in c-m the other day.
<cjwatson> slangasek: ^- this is why I didn't consider clearing out c-m *totally* trivial :-)  What I tend to do is to check rmadison and see whether the package was absent/universe in quantal and main in raring - if so it's probably a recent move and needs checking
<Drenriza> Hi all. I was wondering if their is a channel used as the same as the "programming talk" section on ubuntuforums.org. For discussing / asking questions regarding scripting / development under Ubuntu.
<tumbleweed> cyphermox: seen bug 1153085 ?
<ubottu> bug 1153085 in Ubuntu "[FFe] Sync libqmi 1.0-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1153085
<cjwatson> Drenriza: #ubuntu-app-devel more or less
<Drenriza> Thanks cjwatson
<Drenriza> So what is this channel used for? wiki.ubuntu.com/IRC just describes it as follows "Ubuntu development coordination"
<cjwatson> Development of Ubuntu itself, rather than of third-party programs built on Ubuntu
<cjwatson> (Catch-all; there are also channels for specialised aspects of Ubuntu development)
<Drenriza> When you say Ubuntu itself, you mean the stuff that goes on top of the linux-kernel?
<cjwatson> I mean the contents of the Ubuntu archive
<Drenriza> Ty cjwatson.
<cjwatson> There are things below the Linux kernel that are part of Ubuntu and would also be on-topic here, such as boot loaders
<bdrung> dholbach:  quadrispro did the debian upload and the sync. so you could ask him
<xnox> cjwatson: i did ponder to set the topic to "Ubuntu Core Development" instead what is currently in the topic "Dev' of Ubuntu ..."
<diwic> xnox, "Development of Ubuntu itself (not support or app devel)" perhaps?
<xnox> i don't have a strong opinion =)
<xnox> Dev' is hard to understand =)
<cjwatson> It's not just core development though
<cjwatson> The apostrophe is fairly silly
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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
<cjwatson> (if "devel" is comprehensible in "app devel", it's also comprehensible at the start of that item)
<cjwatson> It's truncated because topic space is scarce
<FourDollars> dholbach: hi
<FourDollars> dholbach: Could you help to review https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 ?
<tumbleweed> we could probably use a better description in https://wiki.ubuntu.com/IRC/ChannelList too
<tumbleweed> "Development of Ubuntu (not support or app devel)" ?
 * tumbleweed sees lots of out of date contact peopl there...
<dholbach> FourDollars, I pinged mvo about it :)
<dholbach> FourDollars, but it looks good to me
<ogra_> wikis ... out of date at creation time :)
<FourDollars> dholbach: Is there any thing I missed?
<tumbleweed> ogra_: yeah, the natural state of wikis
<ogra_> :)
<dholbach> FourDollars, no, not that I can see
<FourDollars> dholbach: OK. Thanks.
<mitya57> Does anybody want to test/review quantal pybuild backport? lp:~mitya57/ubuntu/quantal/python3-defaults/pybuild-backport
<ogra_> lool, eek ... more mailing lists ...
 * ogra_ slowly gets why linus loves 3:2 screens .... more vertical height = less scrolling in your mail trees ... 
<lool> ogra_: yeah, it's not great when we're splitting signal in even more places  :-(
<dholbach> Riddell, would you know who could review https://code.launchpad.net/~bkerensa/ubuntu/raring/plasmate/fix-for-1152730/+merge/152538?
<Riddell> dholbach: just discussing now in #k-d
<bkerensa> ;)
<dholbach> ah great! :)
<bkerensa> then sleeps
<dholbach> bdrung, thanks
<dholbach> @pilout out
<udevbot_> Error: "pilout" is not a valid command.
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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> udevbot_, yeah yeah
<udevbot_> Error: "yeah" is not a valid command.
<tumbleweed> pedantic bot
<vibhav> tumbleweed: Computers are supposed to be pedantic :)
<vibhav> s/supposed//
<zyga> lool: thanks for ubuntu-platform that's excellent news!
<ogra_> hmpf
<tumbleweed> wasn't there an existing list called ubuntu-platform@l.u.c?
<xnox> yeap, for entirely different reasons ;-)
<jdstrand> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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
<cyphermox> tumbleweed: I hadn't seen the libqmi bug, no
<cyphermox> there's no harm in syncing it now, but we also won't be using it in raring
<tumbleweed> yeah, that's basically why he wants it
<cyphermox> err
<ScottK> tumbleweed: If it's a sync from Debian, I think a new package is fine.
<tumbleweed> yup, we should do it
<cyphermox> I mean it's totally safe given that there cannot possibly be anything that uses it in raring
<cyphermox> so yeah, it's fine by me
<cyphermox> should I sync?
<tumbleweed> cyphermox: sure, I just acked the FFe
<cyphermox> thanks
<ScottK> Approved.
<cyphermox> tumbleweed: syncpackage: Error: Not permitted to upload directly to raring; try raring-proposed instead.
<cyphermox> is there a magic trick for syncpackage to be happy?
<cjwatson> Use a modern syncpackage
<cyphermox> ah
<pitti> are you trying to use a quantal syncpackage?
<cyphermox> no
<cjwatson> If you don't have one then -r raring-proposed
<tumbleweed> sorry, I think we haven't finished reviewing the SRUs for that
<cjwatson> Well, you aren't using raring, or else you have weird local configuration
<cjwatson> cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-October/000989.html
<cyphermox> well, I think something is weird yeah
<cjwatson> Perhaps an alias?
<cjwatson> tumbleweed: The SRUs have been in -updates for some time
<cyphermox> I'll double check but I never aliased that, and I have the latest ubuntu-dev-tools, and I'm not in the branch's directory either
<tumbleweed> cjwatson: oh, I'm thinking of different ones then
<cjwatson> https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.144  https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.143ubuntu0.1  https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.141ubuntu0.1
<tumbleweed> so, precise's one is still in -proposed
<ScottK> Yes.  One bug unverified.
<cjwatson> Oh, so it is
<ScottK> I've been tempted to release it anyway.
<mdeslaur> tumbleweed: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue?
<cjwatson> I think libreoffice-help-* may be busted with 4.0
<cjwatson> Noticing UbuntuKylin image build failures which seem similar
<mdeslaur> tumbleweed: whoops, sorry, I didn't mean you
<tumbleweed> ScottK: bdrung couldn't verify that bug on the weekend, I haven't dug into it yet
<tumbleweed> mdeslaur: :P
<mdeslaur> Sweetshark: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue?
<ScottK> tumbleweed: Worst case I think is "it works"
<cjwatson> libreoffice-help-en-us libreoffice-help-zh-cn  are not coinstallable
<cjwatson> Blink, there are a load of explicit Conflicts.  What are those for?
<tumbleweed> ScottK: yeah
<cjwatson> "conflict help language packages in both ways"
<Sweetshark> mdeslaur: its a feature, not a bug. libreoffice-help-fr and libreoffice-help-en cant be installed both (otherwise your -fr will be broken anyway)
<cjwatson> Sweetshark,bdrung: Can you fill me in what's going on with libreoffice-help-* coinstallability?  The current situation is rather awkward.
<cjwatson> Sweetshark: This screws over image builds and the installer
<cjwatson> Because there are a number of situations where we install support for multiple languages
<mdeslaur> Sweetshark: that's...less than ideal....I can't have two different languages on the same computer anymore?
<cjwatson> I would definitely categorise this as a bug
 * zyga curses at all-things-perl and gets back to work
<Sweetshark> mdeslaur: bug 957589
<ubottu> bug 957589 in Ubuntu Translations "Localized LibreOffice Help files ignored when help for en-US is installed" [Medium,Triaged] https://launchpad.net/bugs/957589
<Sweetshark> cjwatson: ^^
<cjwatson> Yes.  Please revert.
<cjwatson> This is worse than the previous situation.
<Sweetshark> cjwatson: revert *both* conflicts? upstream (Debian) conflicts one way (from en-US to everything else, but not the other way around).
<cjwatson> Sweetshark: Do you understand the problem here?  If so then the answer should be clear, I think
<Sweetshark> mdeslaur: you can have an many languages as you want as long as none is en-US.
<cjwatson> What's special about en-US?
<cjwatson> We generally assume (and it's true everywhere else) that it's possible to simultaneously install support for multiple languages without restriction.  en-US being a special case is particularly weird, given that English support is in general always installed.
<Sweetshark> cjwatson: Yes, I would remove both conflicts. But when a package build takes a day on ARM it can hurt to be absolutely clear, I guess?
<cjwatson> I think it's probably excessive that it's in ubuntu-desktop; but (a) removing that will only partially help, and (b) wouldn't it have been better to get ubuntu-desktop amended before whacking in Conflicts if you thought that ubuntu-desktop was wrong?
<cjwatson> Both the Conflicts are a problem.  What's the underlying reason that en-US is broken?
<Sweetshark> cjwatson: If I know _why_ I would fix it.
<Sweetshark> s/know/knew/
<cjwatson> BTW, having the conflicts both ways achieves nothing over having them only one way round.
<cjwatson> An unversioned Conflicts is a bidirectional relationship (well, in the absence of a matching Replaces).
<Sweetshark> cjwatson: bdrung insisted on having them both ways when reviewing the package.
<cjwatson> bdrung: Why?
<bdrung> either both way conflicts or no conflict
<cjwatson> bdrung: Why?
<cjwatson> Nothing wrong with one-way conflicts
<bdrung> cjwatson: when updating from 4.0.0beta2 to 4.0.0, en-US would been held back
<cjwatson> bdrung: And Conflicts both ways solves that?  How peculiar.
<cjwatson> But in any case that should have been a sign that the Conflicts was a bad idea in the first place :-(
<bdrung> okay, it's a workaround
<cjwatson> Dealing with run-time problems (and Medium priority ones, at that) by adding Conflicts just stores up trouble for later, and trouble of the kind that permeates the upgrade system
<Sweetshark> cjwatson: indeed the oneway conflict isnt there in beta2 and was introduced at debian inbetween.
<cjwatson> Hm, 'check-language-support -a -l en' doesn't list libreoffice-help-en-us
<Sweetshark> cjwatson: so reverting that is a two-line change. Do you want an upload with just that?
<pitti> cjwatson: s/-a/--show-installed/
<cjwatson> pitti: Oh, yeah, I just figured that out :)
<cjwatson> Sweetshark: When would your next upload be otherwise (roughly)?
<cjwatson> Well; I guess I'm concerned that ultimately we presumably want to be able to keep multiple help packages installed simultaneously, including en-us, and having a Conflicts in raring means that people's configuration is effectively lost in the meantime
<Sweetshark> cjwatson: too long. I havent clear plan beyond 4.0.1 -- so it would be when I fix one important bug. 4.0.2 upstream is on ~April, 1st.
<Sweetshark> cjwatson: preparing a source package ...
<cjwatson> Sweetshark: I think we should have such an upload then - thanks
<cjwatson> I'm going to pull libreoffice-help-en-us out of ubuntu-desktop; I don't think it makes sense there, and it's in the ship and live seeds too so it's not as if it drops off images
<cjwatson> Won't fix everything but I think it will at least unblock UbuntuKylin image builds, and it seems correct regardless
<Sweetshark> cjwatson: k, thanks a lot.
<stgraber> cjwatson: will that still prevent some images from building? I'm kind of worried as we have beta1 coming this week and pretty much everyone signed up for it
<cjwatson> stgraber: I'll check the other seeds too
<stgraber> cjwatson: thanks
<cjwatson> stgraber: I *think* it's just the Ubuntu GNOME remix, but I'll keep an eye on Edubuntu too
<Sweetshark> cjwatson: any wish for the urgency other than 'low'? If so, which?
<cjwatson> Sweetshark: Doesn't matter; at the moment, nothing in Ubuntu cares
<stgraber> Sweetshark: Ubuntu doesn't usually use the urgency field
<cjwatson> Well, except for possibly apt-listchanges
<tumbleweed> and a slight buildd weight IIRC
<cjwatson> Oh yeah
<cjwatson> Anyway, all my Ubuntu uploads are 'low'
<stgraber> cjwatson: I thought LP also uses the urgency field to give a slightly higher build score
<cjwatson> Yeah, tumbleweed said that
<cjwatson> It's pretty negligible though; https://help.launchpad.net/Packaging/BuildScores
<cjwatson> It's the least significant automatic score adjustment and more or less never matters
<cjwatson> Right, since I now get to wait for a load of builds I guess it's lunchtime
<stgraber> Laney: I guess that's what I'm saying, yes ;) technically both daemons can run, but to avoid problems you'd have to make sure they're perfectly in sync
<jbicha> cjwatson: the urgency field is nice for ppas though
<Laney> stgraber: Hm, I have my session registered in both right now
<stgraber> Laney: right, I think I do too. I guess the basic, registering the session, getting the session list, unregistering the session should be fine, as long as we have the right pam modules loaded.
<Laney> Did you actually see problems?
<Laney> if so it would be good to note that in the bug ;-)
<Laney> I think doing a full transition might be a bit too big for raring
<cjwatson> jbicha: Maybe.  The package set adjustment would still dominate.
<stgraber> no, I haven't. I just remember us saying that it'd be a potential source of problem as running both CK and logind isn't a supported setup and that we can't know for sure what all the various piece of software will do when they see both APIs being present
<jbicha> cjwatson: the scoring difference is enough to get a package to almost the head of the universe queue and the queue is often several hours long
<Laney> pitti: we're having a conversation about logind here, fyi ;-)
<pitti> Laney: ah, catching up (me as well, discussing with jdstrand and mbiebl)
<dobey> anyone know why apport would open chrom{e,ium} instead of firefox (which is set as default browser) when reporting a "system problem" on raring?
<stgraber> dobey: my guess is that apport uses x-www-browser (directly or indirectly) and that for some reason points to chrome on your machine
<pitti> oh, dobey left
<pitti> it uses xdg-open
<cjwatson> jbicha: Fair enough; I guess you have more practical experience with waiting for PPA builds than I do :-)
<pitti> dobey: apport calls xdg-open, which does a couple of things (gvfs-open, alternative, sensible-browser, etc.)
<pitti> Laney: session registered in both> that's CK and loginctl? that's how it ought to be, yes
<Laney> yes - stgraber think this will cause problems
<pitti> oh, how?
<Laney> i.e. the transition must be done fully
<jbicha> cjwatson: of course once everyone does it then we all have to wait in queue again so maybe I shouldn't be announcing it to #ubuntu-devel ;)
<stgraber> pitti: I think it "may" be a source of problem, depending on what the various pieces of software do when both API are available. Though I haven't seen anything go wrong yet.
<pitti> Laney, stgraber: we have a code grep of everything that talks to CK, so we could certainly check those?
<cjwatson> jbicha: heh
<pitti> the bits that I looked at either have no clue about logind, or they use #ifdef HAVE_SYSTEMD style
<pitti> or they check /sys/fs/cgroup/systemd at runtime (like gnome-shell) and select between the two
<stgraber> pitti: yep, that'd work. I guess we want to check whether any of those will try to connect to both at the same time and do something silly like aggregating the session list from both
<pitti> right
<stgraber> so long as they choose to use one or the other, we should be fine
<Laney> I'd say that those would be bugs to fix
<pitti> stgraber: btw, I just finished my investigation about programs that check for /sys/fs/cgroup/systemd
<pitti> i. e. do they mean "I want systemd init" or "I want logind" or something else
<pitti> turns out there's only two packages which actually want systemd init or journal, i. e. not logind
<pitti> http://paste.ubuntu.com/5604908/
<pitti> and we don't even ship sysvinit
<pitti> so for ubuntu, only one package to fix
<dobey> pitti: but why didn't it open the default browser? running xdg-open works. clicking on a link in terminal works. apport just suddenly decided to open chromium here. and chromium was running the wrong theme even too.
<dobey> oh well
<pitti> dobey: oh, root report
<pitti> dobey: I figure it somehow failed to suid back to your user, for a system crash?
<stgraber> pitti: that's a lot better than I'd have thought ;)
<dobey> pitti: that would be quite odd, given it was also logged in on LP, and i've never run chromium as root before myself.
<dobey> so it was running as my user. and it was a system crash
<dobey> but the theme was wrong, and it was chromium instead of firefox
<mitya57> Hi pitti, I'm trying to build pygobject on Debian sid (a crazy idea, I know), and I get this: http://paste.ubuntu.com/5604936/plain/
<mitya57> Any idea what may cause that?
<pitti> mitya57: you need py3cairo from experimental
<mitya57> pitti: Thanks! Maybe time to bump build-dependency?
<bdmurray> cjwatson: https://errors.ubuntu.com/bucket/?id=/usr/bin/compiz:8:StaticSwitchScreen::getWindowPosition:StaticSwitchWindow::glPaint:GLWindow::glPaint:FadeWindow::glPaint:GLWindow::glPaint
<mitya57> ignore that, Ubuntu version is older but looks like it includes the fix
<Sweetshark> bdrung, cjwatson: debdiff at http://people.canonical.com/~bjoern/libreoffice4/libreoffice_4.0.1-0ubuntu2.diff and http://people.canonical.com/~bjoern/libreoffice4/libreoffice_4.0.1-0ubuntu2_source.changes file
<Sweetshark> whoops, the diff is reverse
<bdrung> Sweetshark: please don't forget to tag 4.0.1-0ubuntu1 in git
<Sweetshark> bdrung: already done, pushing now
<cjwatson> bdmurray: Thanks, I found it in the end
<bdrung> Sweetshark: i don't see it. have you pushed the tags, too?
<cjwatson> Sweetshark: LGTM
<Sweetshark> bdrung: see the "pushing now" ;)
<Sweetshark> bdrung: pushed (also the change for 0ubuntu2)
<bdrung> Sweetshark: i saw it. probably the web ui lagged. i see it now.
<Sweetshark> debdiff updated to not be reverse fwiw
<Sweetshark> bdrung: will you sponsor?
<bdrung> Sweetshark: yes
<bdrung> Sweetshark: i am doing a test build (which i expect to succeed and to what it's supposed to to) and then i do the upload.
<bdrung> Sweetshark: have you done a test build?
<bdrung> Sweetshark: btw, does it make sense to merge debian-experimental-4.0 or wait until raring+1 to do that?
<shadeslayer> cjwatson: could you update the packageset ? I've added a couple of packages to the kubuntu supported seed
<Sweetshark> bdrung: still running
<pitti> jdstrand: where did you run your recent archive grep? I wanted to start one on lillypilly, but its load is > 20
<cjwatson> shadeslayer: running
<shadeslayer> cjwatson: thanks!
<jdstrand> pitti: locally
<pitti> jdstrand: ah, ok
<pitti> jdstrand: well, I'll look around for another mirror in the DC
<Sweetshark> bdrung: as for merging: we are past feature freeze (assuming that we do not do rolling releases, which is the most likely scenario), so I am very careful with changes there. I would only merge when all changes look low-risk -- otherwise I would revert to only cherry-pick uservisible and painful changes.
<bdrung> Sweetshark: it contains lintian fixes and the VER removal
<bdrung> Sweetshark: i tend to prefer the merge, because we have just passed the feature freeze and have enough time till the release.
<cjwatson> shadeslayer: done
 * shadeslayer tries uploading again
<shadeslayer> cjwatson: works, thanks alot!
<pitti> jdstrand: hm, didn't find a good one; would it be very much effort for you to kick off another archive grep?
<jdstrand> pitti: no. what do you need?
<pitti> jdstrand: grep -r fs/cgroup/systemd
<jdstrand> ok
<pitti> jdstrand: thanks muchly!
<xnox> bdmurray: ev: \o/ thanks for the Bug 1056061
<ubottu> bug 1056061 in Errors ""First seen" version is wrong in release-specific table" [High,Triaged] https://launchpad.net/bugs/1056061
<ev> xnox: sure thing. Should land with the rollout planned for today
<jdstrand> pitti: ok, started. it takes a while so I'll let you know when it's done
<pitti> jdstrand: sweet, thanks!
<jdstrand> heh, it just found the apparmor one :)
<pitti> jdstrand: hm, argh; would it be possible to restart this, with "egrep -r "fs/cgroup/systemd|sd_booted"?
<jdstrand> pitti: sure
<jdstrand> pitti: done
<pitti> cheers!
<jamespage> micahg: what have you found using internal Sun Microsystems Java API's?
<jamespage> micahg: javax.imageio provides a way forward for some bits and pieces
<slangasek> tkamppeter: ghostscript> please coordinate such questions with #ubuntu-release per my mail, not with me personally
<slangasek> infinity, cjwatson: libmspub> noted; would it make sense to keep MIR bugs open until the relevant packages make it to raring rather than raring-proposed?
<slangasek> pitti: hey, so I just dropped a comment on bug #1153224 with some thoughts
<ubottu> bug 1153224 in systemd (Ubuntu) "[FFE] Move to logind for session tracking" [Undecided,New] https://launchpad.net/bugs/1153224
<pitti> slangasek: thanks; in meeting still, will look ASAP
<Sweetshark> bdrung: at packing libreoffice-dbg here btw ....
<pitti> slangasek: FYI, I see no problem with kicking CK out of the standard installation -- I've run without CK since last Thursday
<pitti> slangasek: I was mainly talking about teh odd universe package, or more importantly, Kubuntu
<pitti> slangasek: also, I fully agree that we don't want udev 195 in raring, that's too risky (and I wasn't proposing that)
<pitti> slangasek: I want current logind, so that we get the current libraries
<infinity> slangasek: Possibly, though making c-m union proposed into its output will eliminate the need for more process that people get wrong, and that was being worked on, in theory.
<infinity> slangasek: I'll chase that up this week and see if we can JFDI.
<slangasek> pitti: right, I think my argument applies to Kubuntu as well, not just Ubuntu; I think the Kubuntu folks should have a say in how this impacts them
<slangasek> infinity: ok.  worked on by whom, in theory
<pitti> slangasek: right
<slangasek> pitti: oh.  So we would have current udev, but newer libudev?  Why do we need newer libudev?
<infinity> slangasek: By Ursinha.  I'll see where that's gotten to.
<pitti> slangasek: if we wanted to, we could also skip that, but it has been the official libudev ABI for quite some time now (thinking about backports, third-party packages, etc)
<pitti> slangasek: so the libudev transition is rather harmless, and I could get that done in a day or two at most
<pitti> slangasek: but anyway, I had the impression that both you and seb128 were urging for this; we can certainly postpone the whole thing to raring+1, and sort out the udev migration until then as well
<slangasek> pitti: are backports/third-party packages the only justification for wanting the ABI bump?
<pitti> slangasek: there isn't much difference between the two, so it doesn't matter that much either way
<pitti> as for third-party binary stuff, I have no idea what they might prefer
<slangasek> pitti: well, I certainly want us to get moved from consolekit to logind, but seeing the number of packages affected I'm wary of doing this before 13.04
<pitti> but most of that will target LTSes, I guess
<pitti> slangasek: so, if you want to move to logind without moving to libudev1, we can do that
<pitti> either with the current v44, or by disabling the libudev{1,-dev} and gudev bits from 198
<slangasek> right - I would be more comfortable with that
<slangasek> reduces the scope of the transition
<pitti> in which case I'd prefer the latter, as it's better supported upstream, more useful for building stuff with logind, and also has a cleaner package
<infinity> Do we have a udev linked with kmod yet, or would that also come with this transition?
<pitti> infinity: we don't, and it wouldn't come
<infinity> Oh, shame.
<pitti> infinity: as I said, moving to current udev is a lot of work and not proposed
<infinity> Kay.
<slangasek> pitti: "cleaner package" - except this package seems to still not be anywhere authoritative
<infinity> I didn't read the full backscroll. :P
<pitti> infinity: several people patched udev without forwarding or describing patches etc, and packages like lvm2 also havent' been updated in ages, so this will be quite intrusive
<infinity> pitti: Check.  Sounds like something worth queueing up in a PPA to land first thing in 13.05 so we can shake out the pain.
<pitti> *nod*
<pitti> in the meantime I'm corrdinating with Mithrandir and mbiebl wrt. the systemd-services split, udev, etc.
 * infinity was just looking forward to not forking modprobe 378 times every boot.
<pitti> yeah, so was I
<slangasek> hmm, didn't realize we still needed a udev update to get that
 * zyga wonder why some people choose movie related nicknames as their identity online
<slangasek> I thought now that libkmod was in, we just needed to rebuild udev; apparently not :/
<zyga> and gets back to work...
<infinity> zyga: Movie-related?
<slangasek> pitti: so I think we should take this one piece at a time; first sort out if we can get a transition done based on 44, and if so go ahead with that, then uplift to 195 in coordination w/ Debian; then figure out if we can tackle the newer-udev question
<tseliot> slangasek: do you happen to remember (since I think you suggested it in the first place) why we use something like "alias nouveau off" in addition to "blacklist nouveau" in the nvidia driver?
<cjwatson> slangasek: Not sure what the right answer is.  I also don't want there to have to be too much manual bug paperwork which will get forgotten
<slangasek> tseliot: 'blacklist' has no effect on udev
<zyga> infinity: Mithrandir?
<tseliot> slangasek: ah, right, thanks
<slangasek> cjwatson: infinity thinks this is solvable with c-m report fixes, so that seems a better answer
<slangasek> zyga: infinity is a big toystory fan
<cjwatson> Probably, yes
<infinity> slangasek: "alias off" breaks kmod.  I need to look into that.
<slangasek> infinity: cute
<Laney> Oh god yes, please do
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674110
<ubottu> Debian bug 674110 in kmod "modprobe: ../tools/kmod-modprobe.c:550: print_action: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed." [Normal,Open]
<Laney> nvidia trips over that
<infinity> Md forwarded it upstream, but I think upstream may have forgotten about it.  I'm going to poke him and then JFDI myself if he doesn't respond.
<pitti> slangasek: we can do a logind transition with 44, yes
<pitti> slangasek: the package as it is in raring works fine (modulo adding Conflicts/Replaces: libpam-xdg-support and  changing seeds)
<slangasek> right
<pitti> slangasek: but as one of the main points was that it blocks updates to newer upstream versions like GNOME, 44 isn't sufficient for some of those
<pitti> slangasek: hence my idea to update to 198 in universe, and do the MIR/FFE review based on that
<Sweetshark> bdrung: build finished here.
<pitti> slangasek: we can still disable libudev1 there if we want
<slangasek> I don't think that's a key point for this cycle
<pitti> slangasek: ok
<infinity> zyga: Mithrandir would be a book reference, not a movie reference, but fair enough.  He's been that for so long, I sometimes forget his name's Tollef, and he's a close friend, so that's mildly embarassing. :P
<slangasek> the decision was already taken in Copenhagen not to update GNOME; we shouldn't rush logind in order to reverse that decision
<seb128> slangasek, pitti: logind 44 has some unfixed CVE as well
<pitti> seb128: really, which?
<pitti> seb128: I only know http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174
<ubottu> The rm_rf_children function in util.c in the systemd-logind login manager in systemd before 44, when logging out, allows local users to delete arbitrary files via a symlink attack on unspecified files, related to "particular records related with user session." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174)
<pitti> which is fixed in 44
<slangasek> updating GNOME is NOT a priority for 13.04, and logind is a priority only inasmuch as it helps us a) drop unmaintained code and b) reduce our desktop footprint
<seb128> pitti, http://secunia.com/advisories/48331/
<pitti> slangasek: oh, I was thinking about the ubuntu gnome remix, not ubuntu itself
<seb128> " The weakness is reported in version 44 and prior."
<pitti> slangasek: so anyway, we can cut this anyway we like
<pitti> slangasek: if you want to go with 44 in raring, that's fine and doable
<pitti> slangasek: i. e. we are a MIR and seed change away from this
<pitti> (and the FFE, of course)
<slangasek> hmm, is that all?  I thought you had quite a few package rebuilds to enable logind support
<infinity> seb128: That's the same CVE as pitti pointed out, so clearly one of those databases is wrong.
<pitti> slangasek: yes, of course
<seb128> infinity, pitti: in any case it's a detail, easy to backport a fix if needed at all
 * infinity nods.
<slangasek> pitti: right, to me that counts as more than just "a MIR and seed change" - which is why I think we should tackle the ck->logind migration separately from the rest
<pitti> slangasek: ok; but please keep in mind that if we do this we have to keep consolekit in teh default install
<slangasek> hmm, why?
<pitti> slangasek: as e. g. gnome-session requires >= 183 for the inhibit stuff
<slangasek> ah poo
<pitti> the one in raring, I mean
<mbiebl> seb128: the debian patch already contains that patch
<mbiebl> see the 44-1 changelog
<mbiebl>     - Backport 693ce21: util: never follow symlinks in rm_rf_children()
<mbiebl>       Fixes CVE-2012-1174, closes: #664364
<seb128> mbiebl, oh, great, thanks
<slangasek> pitti: right, in that case I completely reverse my opinion and think we should update systemd first ;)
<ubottu> The rm_rf_children function in util.c in the systemd-logind login manager in systemd before 44, when logging out, allows local users to delete arbitrary files via a symlink attack on unspecified files, related to "particular records related with user session." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174)
<pitti> slangasek: hence my proposal to update to 198 in universe, and do the libudev1 transition first
<mbiebl> seb128: like for a year or so :-)
<pitti> slangasek: as that's rather harmless
<pitti> slangasek: or alternatively disable libudev/gudev from the package
<slangasek> mbiebl: hi there - pitti mentions you have packages for 195, but they're not in the archive or the Vcs-Git repo?
<pitti> slangasek: and then do the migration to logind
<pitti> slangasek: 198, on http://people.debian.org/~biebl/systemd-198/
<pitti> slangasek: I stacked my changes on top of that, and sent them to mbiebl for review
<slangasek> pitti: udev itself links against libudev; how will that work?
<slangasek> I'm wary that udev won't be happy linking against an external libudev
<zyga> infinity: yeah, I was mostly curious as to the motivation, it's not like names are unique anyway
<pitti> slangasek: either we ship the .so in "udev", or just drop the -dev
 * zyga is spolied by having relatively unused name
<slangasek> pitti: i.e., two copies of libudev on the system.  I don't think we want that
<pitti> slangasek: but it'll certainly be cleaner to rebuild the 25ish rdepends of libudev0 IMHO
<slangasek> pitti: so let's omit libudev from systemd 19x for now, until we're ready to change udev too
<pitti> slangasek: but even then we'll still have libudev0 bundled with our old udev package
<infinity> pitti: Is the ABI bump much of an API change (or at all)?
<infinity> pitti: If not, I don't see the harm in a quick library transition.
<pitti> slangasek: so if we want complete migration of the default install, we need current systemd
<pitti> slangasek: if we want that, we need some libudev1 in the archive
<pitti> slangasek: and if we don't want to update udev, we need libudev0 in teh archive
<pitti> slangasek: but we won't have a -dev for libudev0, so it's fairly harmless
<pitti> infinity: some, I did an analysis this morning
<pitti> infinity: it drops some 5 symbols, which requires (easy) fixes to some three packages, the rest are just rebuilds
<infinity> pitti: Yeah, that's approaching zero effort, especially with the analysis already done.
<infinity> cjwatson: You win.  kernels stayed in main.
<slangasek> pitti: so that's the answer to my earlier question, "why do we need newer libudev"
<pitti> slangasek: or I try to build our udev against libudev1, which doesn't actually sound that hard
<slangasek> pitti: it wasn't clear to me that the "newer libraries" you needed included libudev
<pitti> given that udevd and most of its probes are statiaclly linked
<infinity> cjwatson: Do you have a pending seed commit you're waiting to hit <enter> on, or shall I do that now?
<pitti> in fact, I'm not quite sure why udev depends on libudev0 at all
<cjwatson> infinity: I do indeed
<slangasek> pitti: I guess we can cope with libudev0 and libudev1 in the archive together for raring
<infinity> cjwatson: Yay.  Go nuts, then.  And thanks for the override fix. \o/
<pitti> slangasek: I'm fairly sure I can get rid of libudev0
 * xnox catching up on backlog.
<cjwatson> infinity: Win
<cjwatson> (and done)
<xnox> pitti: what do you mean by "and packages like lvm2 also havent' been updated in ages" lvm2 is fairly up to date, not the latest upstream but fairly up to date with useful fixes on  top.
<xnox> ?
<pitti> for f in `dpkg -L udev`; do echo "===== $f ====="; ldd $f; done -> no linkage
<pitti> slangasek: so supposedly udev's libudev0 dependency is just a packaging bug
<slangasek> pitti: right, checking
<cjwatson> infinity: The problems we sometimes have with stable releases are probably something else, unfortunately, as I doubt they'll suffer from the same rapid copy/delete sequence.
<slangasek> pitti: hard-coded dep in debian/control; so yes, we can cleanly transition to libudev1
<pitti> ah, heh
<slangasek> pitti: you needed to go ~now, right?
<pitti> slangasek: yeah, I'm afraid so
<infinity> cjwatson: Stable release problems are ancestry issues.  Depends on where you're copying from/to.
<cjwatson> Ah, yeah, of course
<slangasek> pitti: we can pick this up again on the FFe bug later - thanks for the chat, it's much clearer to me now what needs to happen
<pitti> slangasek: so my proposal would be to update systemd to 198 in universe, get the FFE for that, do the libudev1 transition; we are really safe until then
<infinity> cjwatson: I don't have good notes on where it does and doesn't fail, but we could experiment a bit on staging.
<pitti> slangasek: then do the FFE review for logind, if approved do the transition of that
<cjwatson> No, now that you mention that I understand what it is
<pitti> slangasek: and keep our current udev until after raring
<cjwatson> It's harder to fix though
<slangasek> pitti: updating systemd to 198 seems like it should also get an FFe
<pitti> slangasek: yes; I mentioned it in the same one, but it shoudl probably be split off
<slangasek> pitti: ok
<slangasek> pitti: have fun at taekwondo :)
<pitti> xnox: oh, so it has, thanks
<pitti> slangasek: ok, please let me know; I can work on the transition tomorrrow, and put the sourceful fixes for libudev1 into the PPA
<pitti> slangasek, stgraber: perhaps you can discuss with ScottK and Riddell for Kubuntu? It would mean that they would need to ship logind plus ConsoleKit
<pitti> really need to run now, sorry; TTY tomorrow!
<ScottK> Upstream encouraged us to cherry pick the upstream patches and swtich to logind for libsolid4.  What else would it impact?
<slangasek> ScottK: there's a list of consolekit-affected packages here: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration
<slangasek> at minimum, it seems kdm has consolekit integration
<ScottK> We don't ship that by default anymore though.
<ScottK> Agreed though.
<xnox> slangasek: "whatever lightdm is doing, it should continue to work in kubuntu world" =)
<ScottK> polkit-qt we do ship though.
<ScottK> xnox: afiestas says there are greeter changes too.
<bdmurray> stgraber: is just uncommenting ubuntu in /etc/upstart-xsessions the correct way to ge the xsession running in upstart?
<stgraber> bdmurray: yes but it won't quite work yet as we need to get the gnome-session, dbus and gnome-settings-daemon job into their respective packages for it to work
<Laney> bdmurray: You'll have to add jobs to start ... that
 * Laney literally just did that
<bdmurray> stgraber: oh and the ppa version had those jobs
<stgraber> bdmurray: which reminds me I need to prepare patches for gnome-session, gnome-settings-daemon and dbus.
<stgraber> bdmurray: yeah, the PPA was bundling those but we removed them before landing 1.7 in the archive
<bdrung> Sweetshark: build, tested, and uploaded
<Sweetshark> bdrung: awesome, thanks.
<Sweetshark> cjwatson: ^^
<hallyn> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: hallyn, jdstrand
<jdstrand> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: hallyn
<Sweetshark> jdstrand: copilot ejecting after liftoff?
<sarnold> mid-air pilot hotswap!
<jdstrand> hehe, yes :)
<tkamppeter> slangasek, OdyX, I have solved the Foomatic problem now and committed everything to GIT/uploaded to Raring. I have made foomatic-db-engine returning a decent error message when no database is available. I have done this upstream and rleased it as foomatic-db-engine 4.0.9. There are no other changes compaired to 4.0.8.
 * xnox time to go for a swim \o/
<OdyX> tkamppeter: great; release that as tarballs and I'll upload that to experimental :)
<tkamppeter> OdyX, foomatic-db-engine is the only package changed upstream for that. The upstream version 4.0.9 is already released and contains the fix. Only this fix is the difference between 4.0.8 and 4.0.9, so the new version can get into any distro with 4.0.8 also after Feature Freeze.
<tkamppeter> OdyX, the modified Debian/Ubuntu source packages are foomatic-db-engine and foomatic-db. I have uploaded both to Ubuntu and updated the GIT repos at Debian, so you only need to upload the unchanged GIT snapshots of both to Debian.
<OdyX> okay, I'll see if I can get 4.0.9 and foomatic-db update to experimental soon.
<captainlinux> Guys is it possible that latest updates have messed up some webcams on Laptops?
<captainlinux> After latest updates I'm only getting a black picture.
<captainlinux> On clean 12.10 install without updates my cam works. After updates it only gives me a black picture and flashing led.
<slangasek> captainlinux: bugs in updates are always possible; if you've confirmed that downgrading to stock 12.10 fixes the problem, then that seems fairly definitive.  You should file a bug against the linux package using the command 'ubuntu-bug linux' and mark it as a regression introduced by an update.
<captainlinux> slangasek: Thanks, I will try that.
<slangasek> tkamppeter: I think you need to add Provides: foomatic-db-engine to your foomatic-db-compressed-ppds package
<slangasek> tkamppeter: update-manager doesn't want to upgrade me in raring because I have foomatic-db-engine installed and u-m doesn't want to remove ti
<hallyn> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<slangasek> tkamppeter: unless, foomatic-db-compressed-ppds doesn't provide the functionality of foomatic-db-engine?
<OdyX> slangasek: it doesn't afaik. Provides is sementically wrong afaics.
<slangasek> hmm, ok
<slangasek> OdyX: do you know why the conflicts/replaces were needed?
<slangasek> looks like a wrong use of C/R to me
<OdyX> slangasek: the conflict between foomatic-db-engine and foomatic-db-compressed-ppds was my wrong attempt at fixing Debian's #627770. I'll drop that.
<slangasek> OdyX: ok, cheers
<OdyX> slangasek: it's now fixed correctly on the upstream side by tkamppeter in foomatic-db-engine, thanks him !
<slangasek> tkamppeter: thanks for fixing it before I asked ;)
#ubuntu-devel 2013-03-12
<micahg> jamespage: jai-core, yeah, I figure it could be ported, I was wondering if there were an easier way to move forward that porting the code (and this is a sun library that hasn't been updated in 5 years, so I figure there might not be hope)
<xnox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: xnox
<stgraber> xnox: seriously? :)
<xnox> well... i was pinged to sponsor a few things.... and it's my time to patch pilot..... (my phone buzzed a couple of hours ago)
<stgraber> so you went with the night shift then ;)
<xnox> I bet everything I patch-pilot will end up tied up in the beta1 block.
<xnox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
 * xnox nap time. will be back for some awesome ureadahead patch merging =)
<psusi> xnox, eh?
<psusi> there's some ureadahead love somewhere?
<xnox> *two* merge proposals https://code.launchpad.net/ubuntu/raring/+source/ureadahead
 * psusi needs to dust off his ureadahead love and see if it's still needing updated if possible and merged
<psusi> I had been playing with some ureadahead optimizations in conjuunction with e2defrag to pack the files ureadahead wants to preload all in order at the start of the disk... but have been thinking we might want to replace ureadahead with e4rat.. need to do some evauluation
<ScottK> xnox: You can still upload it.
<ScottK> xnox: Bug 1123186 might be another good one to look into.  Gregor Herman is someone it would nice to have feel good about interacting with Ubuntu.
<ubottu> bug 1123186 in jabref (Ubuntu) "Jabref: flawed dependencies force installation of OpenJDK java" [Undecided,Confirmed] https://launchpad.net/bugs/1123186
<slangasek> xnox: could you please commit your pam changes to the bzr branch?
<slangasek> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: slangasek
<pitti> Good morning
<ion> that
<pitti> ScottK, slangasek: NB that lightdm also doesn't support logind in a particular way, it just uses the PAM module
<ScottK> pitti: OK. That was from one of the upstream KDE developers that's worked on the KDE greeter, so I didn't know.
<pitti> ScottK, slangasek: FYI, I followed up to bug 1153224 with some clarifications
<ubottu> bug 1153224 in systemd (Ubuntu) "[FFE] Move to logind for session tracking" [Undecided,New] https://launchpad.net/bugs/1153224
<pitti> ScottK: well, the PAM module is sufficient for creating sesssions; it's of course very likely that it has knobs for shutdown/reboot, which do need to talk to CK/logind directly
<pitti> ScottK: porting that is easy (it's more or less replacing org.freedesktop.ConsoleKit.Manager.ShutDown() with org.freedstkop.login1.PowerOff()), but also not strictly required if you keep consolekit installed
<pitti> but indeed not zero work, if you also just want to ship one stack
<slangasek> pitti: ack
<slangasek> xnox: I see you commented on bug #1122120 that the patch looked fine, but left it in the sponsorship queue; did you run into a problem with it?
<ubottu> bug 1122120 in tcl8.5 (Ubuntu) "Multiarchify tcl8.5" [Undecided,New] https://launchpad.net/bugs/1122120
<pitti> infinity: would you know, to disable a particular binary from a source package, is it enough to drop it from the binary .changes, or do I actually need to drop it from debian/control?
<pitti> infinity: doing the latter is quite intrusive to debian/rules in the systemd case and also breaks --list-missing/--fail-missing quite badly
<infinity> pitti: Keeping it in debian/control means it ends up in .dsc, but that might not be world-ending.  Were you thinking of just seding changes at the very end of the build?
<infinity> pitti: That should technically work and not upset things too much.  Try it in a PPA.
<pitti> infinity: I thought about -N'ing it from dh_<whatever calls dpkg-distaddfile>
<pitti> dh_builddeb, I figure
<infinity> pitti: Oh, sure.  That could also do the trick.
<infinity> pitti: It's pretty hackish (given the incorrect .dsc), but we have dscs that are incomplete and/or overly-complete in other packages, I suspect it wouldn't be a bit deal.
<infinity> s/bit/big/
<pitti> infinity: it would appear similar to udebs or Arch: <specific> packages I guess
 * infinity nods.
<infinity> If it has a -dbg package, that will contain pointless symbols from the package you're not building.
<infinity> But otherwise, it should more or less behave as expected.
<pitti> no, it doesn't
<pitti> ok, thanks; it would ease shared maintenance with Debian quite a bit, as well as keeping our --fail-missing safeguard
<infinity> It "feels" wrong, but I appreciate the want for a small delta, if it works how you want it to in a PPA test run.
<pitti> I'll do that
<slangasek> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<Quintasan> Good morning
<pitti> slangasek, ScottK, infinity: libudev1 transition is child's play after all; in the end there's only one package which needs a sourceful upload (lvm2), done in the PPA by cherry-picking the upstream fix for that; all others are just rebuilds
<infinity> pitti: Sounds promising.
<infinity> pitti: Please don't let actual children play with it.
<pitti> I have always wanted a lipyuhdev as a child
 * infinity is finding it rather embarassing that he can't seem to find a MicroSD card, despite owning dozens.
<infinity> Maybe it's time to clean my desk.
<sarnold> they _are_ tiny.
<pitti> infinity: maybe it would be easier if they weren't so damn small
<infinity> Yeah, exactly.
<infinity> Maybe I'll just pull one from a phone.
 * pitti wonders if he's the only one who finds "dpkg-deb -z1 -Zxz -Sextreme" rather naughty
<infinity> Of course, then I need to also locade my MicroSD USB reader.
<pitti> how about leaving it in the phone and using mass storage?
<infinity> pitti: Is there even any point to -1e?
<pitti> I meant spelling/reading it, not what it does :)
<infinity> I refuse to admit to reasons why the word "extreme" may seem naughty to me.
<pitti> (apparently these are standard dh 9 udeb options)
<infinity> It certainly has nothing to do with any specific mail order agency I've frequented.
<pitti> ... for purely scientific reasons, of course
<infinity> Obviously.  For science.  I believe in hands-on experimentation.
<infinity> Related to the first conversation, but not the second: I miss 8 inch floppy disks.
<infinity> Hrm, not quite was I was looking for, but I just found a large cache of GBP and EUR.  Time for a vacation?
<pitti> infinity: FYI, I used http://people.canonical.com/~pitti/tmp/systemd-patches/0009-Disable-udev-and-systemd-packages-for-Ubuntu.patch now, which seems to work quite well
<infinity> pitti: You might want to change the dpkg-vendor call.
<infinity> pitti: Use --derives-from instead of --query vendor.
<pitti> can I do a boolean if with make, like if $(shell dpkg-vendor --derives-from ubuntu) ?
<infinity> pitti: Unless we want very surprising results for people rebuilding this.
<infinity> pitti: ifeq (Yes,$(shell dpkg --derives-from Ubuntu && echo Yes))?
 * infinity flails.
<pitti> ah, nice trick
<infinity> Untested.  Pretty sure that doesn't need quoting, though.
 * pitti runs another build
<infinity> Err, with a -query on that.
<infinity> -vendor even.
<infinity> So not awake.
<pitti> yeah, I've translated from adamsh to bash and infinipkg to dpkg
<infinity> http://paste.ubuntu.com/5607107/
<infinity> Hahaha.
<infinity> Yeah, seems to DTRT.
<pitti> http://people.canonical.com/~pitti/tmp/systemd-patches/0008-Disable-udev-and-systemd-packages-for-Ubuntu.patch works fine
<pitti> I'll fix something else and then kick that PPAwards to see what it makes of it
<infinity> Hrm, curious that the manpage doesn't document dpkg-vendor as being case-insensitive, but it sure appears to be.
<dholbach> good morning
<infinity> pitti: Given that vendor and parent in origins/* appear to be all mixed-case, I'd probably stick with Ubuntu over ubuntu since the tool doesn't document its case-insensitivity, but that's probably just me being paranoid.
<infinity> pitti: I imagine if someone broke that at this point, people would scream, so the right thing to do is fix the manpage. :P
<pitti> oh, I used "ubuntu" in many places by now
<infinity> Yeah, see above.  People would scream.  One of them being you.
<infinity> So I should probably just push a manpage fix to Debian to document the current behaviour as canonical.
<dholbach> FourDollars, mvo just uploaded the patch :)
<FourDollars> dholbach: Thanks a lot. :D
<Whoopie> debfx: Hi, any timeframe when you plan to upload a new virtualbox? Or could you point to your fix for the XComposite unresolved symbol issue?
<xnox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: xnox
<xnox> slangasek: simply was something I didn't feel like sponsoring at 3am ;-)
<Whoopie> debfx: btw, for auto-loading, you could use the patch in bug report 1039157 -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039157/+attachment/3295573/+files/vbox.patch
<ubottu> Launchpad bug 1039157 in linux (Debian) "vmware/virtualbox kernel modules not loaded by default" [Unknown,Fix committed]
<ScottK> pitti: OK.  I've no objections to the systemd update/libudev1 transition.  I'm on my way out the door, so I'll leave it for another u-release member to approve in the bug.  Like slangasek or infinity.
<pitti> ScottK: ok, thanks; that'll also require the MIR approval first
<seb128> pitti, need to chase the MIR/security guys to get that review done, I've also an accepted FFe blocked on promotion of systemd-services ;-)
<pitti> I would settle for a partial move to main at first for the udev libraries
<pitti> then we can get the libudev migration out of the way
<pitti> and it's just slightly newer code than what we have already
<pitti> but again this needs a formal FFE first for updating systemd to 198 (that should be easy, though)
<seb128> ev: hey
<ev> seb128: hi
<seb128> ev: seems like your RT59730/r284 didn't work out as it should (or I'm hitting another very similar issue)
<seb128> ev: https://errors.ubuntu.com/?package=telepathy-glib never finish loading... here
<ev> seb128: looking
<seb128> ev: ok, I guess that's my error, unping
<ev> hm? Is it working now?
<seb128> ev: telepathy-glib provides a library so it probably has no report against its component
<seb128> the reports probably go to the packages using the lib
<ev> ah, it wont, yeah
<ev> there's still a javascript error to fix here that's preventing the table from saying "no results"
<seb128> yeah, it's the "loading..." not going away that confused me first ;-)
<ev> :)
<ev> fixed the javascript as lp:errors r297
<ev> I'll try to get that deployed today
<infinity> slangasek: Thanks for packaging heimdall-flash, BTW.  Your version was 98% less sad than the precompiled binaries on the interwebs.  (Googling various failure modes was how I even noticed it was in the archive, probably time to go mass updating a ton of CM wiki pages to say "if you're running Ubuntu, ...")
<seb128> ev: thanks
<ev> sure thing
<pitti> cjwatson: wrt. "Check whether openssh needs to grow logind support, and add it if necessary", what particular magic should happen there?
<pitti> cjwatson: if I ssh into my box, that user gets a sessio in logind, a $XDG_SESSION_ID and $XDG_RUNTIME_DIR through the PAM module
<pitti> cjohnston: I guess that's the important bit? or is there anything else?
<pitti> sorry cjohnston, I mean cjwatson
<om26er> who should i contact to let know that there are quite a large number of download mirrors that are behind the main servers. like a few months behind
<xnox> om26er: is it known? https://launchpad.net/ubuntu/+archivemirrors
<xnox> om26er: hopefully someone in #launchpad can direct you to the right place.
<om26er> xnox, its mentioned there but with "last update unknown"
<om26er> xnox, i'll try  #launchpad Thanks
<xnox> om26er: some of the mirrors listed there, are not under our control. We cannot force push update them. They are maintained by their respective owners.
<smartboyhw> xnox, you're the patch pilot today?
<xnox> smartboyhw: yes.
<smartboyhw> xnox, please review https://code.launchpad.net/~smartboyhw/ubuntu/raring/blender/2.66a-3ubuntu1-merge/+merge/152894 then:P
<xnox> smartboyhw: way too quick =) even the diff is not there yet =))))
<smartboyhw> xnox, yep:P
<smartboyhw> Just notification
<smartboyhw> Hey popey
<xnox> infinity: i'll give that qemu powerpc building a try with blender above ;-)
<smartboyhw> xnox, /me \o/ +1
<StevenK> smartboyhw: O HAI. If you fix the description in your Launchpad MP to include more details, I'll review it.
<smartboyhw> StevenK, OK:)
<infinity> smartboyhw: A 70MB diff for a merge might not always be the most clever idea ever.
<infinity> smartboyhw: Giving people just the Ubuntu diff over the current Debian is much more manageable.
<smartboyhw> infinity, debdiff ok
<StevenK> infinity: "Sure, I'll review that. I'll get back to by April, 2014."
<jpds> om26er: Do you have any particular examples?
<infinity> smartboyhw: debdiffs are great for me, but it's xnox or StevenK you get to ask. :)
<smartboyhw> infinity, :P
<smartboyhw> infinity, there wasn't even a tag for it hmmm
<infinity> In all honesty, given how simple the merge actually is (when you strip away the 70MB patch), I'd be more inclined to just do it myself than try to fuss with sponsoring, if it was me.
<smartboyhw> infinity, I'm not Ubuntu dev or whatever.....
<smartboyhw> infinity, ah you mean you do it
<smartboyhw> ....
<smartboyhw> LOL
 * infinity is still not sure why we think merges are a good way to get people to contribute for sponsorship, since they tend to be either "so trivial that your patch isn't worth the effort" or "so complicated that I need to read it line-by-line and do it myself anyway".
<smartboyhw> infinity, I like it though
<infinity> smartboyhw: Yeah.  There's nothing wrong with you liking merges.  My complaint is with having non-uploading people do them for the sponsorship queue, I guess, because of the above.
<om26er> jpds, here both Pakistan mirrors, https://launchpad.net/ubuntu/+archivemirrors and then tried the Quwait mirror, same problem as well. What worked for me was the main server but its slow
<infinity> They're pretty much the silliest things to "sponsor", since I have to re-do it myself to verify it's correct.
<smartboyhw> ...
<smartboyhw> Anyway I'm not the one to decide
<tumbleweed> infinity: I don't think anyone recommends them for new people. but somehow new people find them
 * smartboyhw hides
<tumbleweed> probably because they are an easy list of things to do
<infinity> tumbleweed: I think there've been various docs that recommend them actually.
<smartboyhw> tumbleweed, and the Packaging Guide teaches them
<infinity> tumbleweed: I'm sure I've seen Colin raise the same complaint. :P
<smartboyhw> That's why I used it
<tumbleweed> it's something you need to know how to do. It doesn't mean you go and do other people's merges
<tumbleweed> (not talking specifically about this case)
<infinity> I don't even mind people merge-sniping occasionally, it really is the sponsorship aspect.  They're almost literally unsponsorable.
<jpds> om26er: Well, click on them for more information.
<Laney> https://wiki.ubuntu.com/MOTU/TODO
<infinity> Byt the time I'm done, I've re-done exactly the same work to verify it's correct, and then I put someone else's name in my changelog.  Which isn't really sponsorship.
 * tumbleweed finds sponsoring merges to be a useful way to encourage a bunch of behavior in new developers. It's a hell of a lot of work, though
<xnox> infinity: smartboyhw: i have no problem with bzr merges with large diffs. Afterall all i need to do is $ bzr diff -rtag:$DEBIAN_VERSION to get the debdiff against debain.
<smartboyhw> xnox, Ok
<infinity> xnox: Whatever works for you.
<om26er> jpds, i am going to try to contact their admins and see what i get out of that
<infinity> tumbleweed: Yeah, sponsoring/reviewing/(re-doing) merges can be a good way to teach people about a ton of other packaging gotchas, and just generally rap them on the knuckles for doing silly things.
<infinity> tumbleweed: But I'm not sure that has much to do with merges as much as it has to do with volume and diversity of packages that need merging.
<infinity> tumbleweed: If you were to ask apw what the best packaging crash course is, he'd probably say a massive library API transition. :P
<apw> infinity, that'd do it ... with some gnarly c++ in it
<infinity> tumbleweed: 17 different patch formats, a few source formats, a ton of weird ways to make that all work together, different VCSes, different upstreams...
 * xnox realised i'm a bit clueless with old-style / verbose dh_* way of packaging stuff.
<tumbleweed> :)
<xnox> infinity: one source package split twice in main & universe is the nail in the coffin though that hardly anyone manages to notice ;-)
<tumbleweed> so, we should send new contributors to the +1 team?
<infinity> xnox: Poor, poor boost.
<infinity> xnox: You should cleverly make them interdepend strongly enough that they can't migrate without being in sync.
<infinity> xnox: Or, y'know, help with ArchiveReorg so we can make boost-mpi go the *&!% away.
<xnox> i think they do.
<infinity> xnox: Oh, do they?  Maybe all the problems were pre-britney, then.  Yay for another solved problem. :P
 * xnox was pondering about 3.0 (custom) which generates two source packages....
<tumbleweed> wat
<infinity> tumbleweed: Actually, I wouldn't mind having some new blood here and there.  The problem is that it needs to be new blood with sufficient programming clue.
<tumbleweed> yeah
<tumbleweed> and, presumably, time
<xnox> infinity: way too picky =))))
<infinity> tumbleweed: I don't need people who understand Debian packaging (I can teach that via pain), but I need people who speak a few programming languages and can adapt.
<apw> yeah that was my supprise, that although packaging is important, most of what one does is not packaging in +1
<infinity> apw: To be fair, I threw specific things at you because I know you're a strong programmer, there's plenty of packaging fixes in +1 too.
<apw> infinity, fair enough indeed, +1 was fun and i do recommend a stint
<infinity> But while I can teach a strong programmer to fix packaging, I'm not particularly good at teaching a strong packager C and Python. :/
<infinity> And understanding WHY something breaks is critical before you go and work around it by breaking a package. :P
<infinity> (And then understanding how to fix it...)
<infinity> tumbleweed: But, in all seriousness, if you have people wandering in who say "I have a really good fundamental knowledge of C/C++, but don't know thing one about Debian packaging", send them my way, I can make use of them.
<infinity> dholbach: ^
<seb128> infinity, you don't especially need strong programming skills to be helpful on +1
<rbasak> infinity: AIUI, having merge experience is essentially a requirement to get upload rights. So getting sponsorship for them becomes a requirement.
<seb128> often the work is "look if Debian/upstrea
<rbasak> (or am I mistaken?)
<tumbleweed> infinity: finding people like that is tough :P
<seb128> often the work is "look if Debian/upstream/other distro have a fix for the issue we can backport"
<infinity> seb128: Sometimes it's just patch hunting, sure.  I can teach that too. ;)
<rbasak> I guess that only applies to people seeking those upload rights though
<seb128> yeah
<infinity> seb128: But even then, while you don't need to be a *good* programmer to backport a patch, you need to understand general programming well enough to know how to massage it and fix it when you break it.
<infinity> seb128: I suspect you take that skill for granted, since you're good at it. :)
<seb128> lol, could be :p
<infinity> (I, for instance, am not a particularly good programmer, but I'm good enough to know why and how I've broken something, rather than throwing my hands in the air and saying "HALP, IT DOESN'T COMPILE")
<dholbach> infinity, errr... do what exactly?
<infinity> dholbach: Just saying that if you have any people with programming experience but no Debian/Ubuntu experience looking for places to contribute, I can probably make use of them in +1... I know I've seen that once or twice.
<infinity> rbasak: I'd suggest that if merges are a prereq for upload rights, we're doing it wrong, but that's something to bring up with the DMB.
<infinity> rbasak: Given that most merges are fairly mechanical, all those ones do is add to your upload volume rather than proving anything interesting about your skills, I'd rather see people fixing packages, submitting lots of useful patches, etc.  But, I don't vote either.
 * rbasak is looking forward to +1 in April
<infinity> April will be a boring month for it, probably. :/
<infinity> But you'll get some inner workings of archive maintenance at least.
<dholbach> infinity, sure sure
<infinity> Since pre-release is when we try to fix the few things we still have time to fix, and then give up and purge all the crap that's still broken.
<cjwatson> It was more exciting than it probably ought to have been last time.
<cjwatson> Speaking of, I *really* ought to get started on +1 work this month ...
<cjwatson> Been too busy fighting fires (some self-started).
<xnox> infinity: gcc-4.8 fixes in april ;-)
<Reezz> Hey guys, could anyone help me out with a linker problem? I've set the LDFLAGS to the lib's location.. But still no help :)
<cjwatson> Not volunteering, but it'll probably work better if you describe the full problem up-front (perhaps with the aid of a pastebin).
<Reezz> Sure, hold on
<xnox> Reezz: please pastebin full build-log with all command-lines verbose (e.g. no silent make rules, V=1, --verbose, etc)
<jdstrand> pitti: hi! fyi, http://people.canonical.com/~jamie/archive-grep/
<pitti> jdstrand: good morning
<jdstrand> http://people.canonical.com/~jamie/archive-grep/pitti-fs_cgroup_systemd_or_sd_booted.log that is
<pitti> jdstrand: splendid, many thanks!
<jdstrand> np
<rtg_> how does one turn off the drum sound at boot when lightdm starts up ?
<highvoltage> rtg_: start up in system recovery mode,
<highvoltage> rtg_: then take a soldering iron and shove it in until the speakers melt
<rtg_> highvoltage, hmm, thats less helpful then you might think.
<rtg_> these mac minis are a drag to take apart.
<henrix> rtg_: renaming /usr/share/sounds/ubuntu/stereo/system-ready.ogg should work :)
<rtg_> ah, thats what I was looking for .
<pitti> I guess there might be a lightdm config option for this
<Reezz> Ok so, here's the pastebin for my linker problems. http://pastebin.com/qYHC3QVS
<Reezz> I saw that it indeed did not go through the directories I specified, but I can't make out why? (directory where the libs are is "/usr/local/lib")
<pitti>       if (UGSettings.get_boolean (UGSettings.KEY_PLAY_READY_SOUND))
<pitti>             canberra_context.play (0,
<pitti> rtg_: ^ that looks promising (in unity-greeter)
<pitti> com.canonical.unity-greeter play-ready-sound true
<cjwatson> That looks like just missing -l options.  What libraries include the symbols (e.g.) skeltrack_joint_list_get_joint and gfreenect_device_new_finish?
<pitti> rtg_: so try sudo -u lightdm gsettings set com.canonical.unity-greeter play-ready-sound false
<rtg_> pitti, ack, will give it a try
<pitti> . o { we used to have a checkbox for this in control-center.. }
<Reezz> cjwatson: libgfreenect-0.1.a and skeltrack-0.1.a (in /usr/local/lib)
<Reezz> I've added the dir to the LDFLAGS .. So I don't know why it won't link properly (although I'm probably missing something here :D)
<rtg_> pitti, hmm, dbus-launch errors.... Think I'll just redirect system-ready.ogg
<infinity> rtg_: I believe that, instead of all this fiddling about with settings, if you just mute the volume in lightdm, it remembers that independently of your user volume.
<infinity> There's a speaker icon there for a reason...
<rtg_> infinity, but I'm too stupid to remember to do it consistently.
<infinity> rtg_: Hence the remembering part.  You only have to do it once.
<rtg_> infinity, except that I often listen to tunes and mumble, etc
<infinity> rtg_: As the lightdm user?
<rtg_> infinity, you mean before I login ?
<infinity> rtg_: Yes.
<rtg_> ah, I'll try that
<rtg_> back in a sec
<infinity> rtg_: Unless we broke that, the lightdm user's volume prefs used to get saved.
<infinity> And you left.
<Reezz> Well he's trying your suggestion :)
<infinity> Yes, but how dare he run off to try something while I was still being pointlessly verbose in his direction.
<cjwatson> Reezz: forget -L; as far as I can see you're not asking the linker to use those libraries
<cjwatson> Reezz: the linker doesn't just look for any relevant library in the directories you provide, or anything like that.  You have to actually state the library name, either using the -l option or by adding libwhatever.a to the link line
<cjwatson> Reezz: So  -lgfreenect-0.1 -lskeltrack-0.1  should help
<Reezz> cjwatson: Ah, that might just be it. Gonna give it a go :D
<cjwatson> Reezz: Basically all that -L does is govern where libraries named in -l options are looked up
<rtg_> infinity, that did the trick, though I had to reboot to get pulseaudio (I think) to behave
<infinity> rtg_: \o/
<infinity> It's nice when there's an almost intuitive solution to a simple problem.  It's a bit sad when our initial reaction to "how do I" is to go rooting around in filesystem mangling and obscure settings trees, though. :P
<rtg_> infinity, I guess its just training from the bad ol days
<infinity> We were dangerously close to someone suggesting locally patching lightdm of g-s-d and rebuilding it.
<infinity> s/of/or/
<rtg_> I _would_ like to figure out why the combination of pulse and mumble consumes 75% of my CPU. that seems kind of high.
<infinity> Yeah, I don't have a simple answer to that one. :)
<rtg_> its eventually drops down to 20-30%. some kind of network profiling ?
<Reezz> cjwatson: Did the trick, with full path names though :) Thanks a lot!
<infinity> Or recalculating echo cancellation or something?
<infinity> But unless your computer is awful, none of those things should take much CPU, so it's still pretty clearly buggy behaviour.
<cjwatson> Reezz: You're welcome
<Reezz> cjwatson: might you know how to add all the known installed libraries to the search list? :x
<pitti> Reezz: you usually don't want that; normally you call pkg-config --libs to find out the linker flags for the libs you want to link with
<cjwatson> Reezz: What pitti said; the linker has no way of its own to do what you're asking, and it's (to say the least) a highly unconventional thing to do
<Reezz> cjwatson: Yea I understand, but there has to be a better way than manually adding each and every linked library? I'm quite new to the uni environment, but as I recall I had to export certain paths in which my used libraries (or includes, can't remember) are stated?
<pitti> Reezz: no, your build system needs to declare which library (or more abstractly, pkg-config module) it needs to link to
<pitti> Reezz: if you are using autotools there are convenient macros for that; if you are writing a plain Makefile it works similarly; just call "pkg-config --libs foo bar baz .." with all the libs you need
<pitti> you usually need it for --cflags more than for --libs, though
<cjwatson> hallyn: Hmm, I think a recent qemu change has broken grub2
<Reezz> pitti: aah, ok! Thanks :)
<cjwatson> hallyn: 'grub-mkrescue -o grub.iso', 'qemu -cdrom grub.iso', then type 'halt' at the GRUB prompt, and it fails to shut down - I think this is what's causing grub2 to fail to build at the moment
<cjwatson> Though I wonder if it's just failing to decode the ACPI table or something ...
<hallyn> trying
 * hallyn installs xorisso...
<cjwatson> 'set debug=acpi' does sort of suggest the latter (get_sleep_type is returning -1), so maybe it's not qemu's problem; I just wonder why it changed
<hallyn> <blink>
 * cjwatson sets up a quantal chroot to investigate
<sconklin> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: xnox, sconklin
<hallyn> cjwatson: a grub.iso created in a precise chroot does the same thing (with raring's qemu)
<hallyn> so sounds like qemu or seabios bug
<cjwatson> I'd have tried quantal's qemu by now if I hadn't created a chroot with the wrong arch by mistake
<cjwatson> Happens with my upstream checkout too (a bit stale but not very)
<cjwatson> Of grub, that is
<hallyn> building upstream checkout of qemu...
<hallyn> (hopefully that doesn't overheat my laptop)
<cjwatson> Will raring's qemu work with quantal's seabios, and vice versa?
<cjwatson> (Er, meaning quantal's qemu with raring's seabios)
<hallyn> not sure.  the versions did change, i'm just not sure how closely tied they need to be
<cjwatson> OK, definitely different debug=acpi output
<hallyn> cjwatson: same thing with uptodate upstream qemu
<hallyn> my money's on a seabios bug though
<cjwatson> http://paste.ubuntu.com/5607839/
<cjwatson> It's far from impossible that the DSDT is just shaped differently and is tickling a bug in GRUB's parser
<cjwatson> Does that live in seabios?
<hallyn> uh....  i think so.
<cjwatson> And indeed, quantal qemu + raring seabios => same problem
<hallyn> yeah, acpi-dsdt in seabios/src
<cjwatson> Guess I'll need to dig out the ACPI spec :-/
<cjwatson> Gotcha
<hallyn> (going by http://smackerelofopinion.blogspot.com/2010/09/hacking-custom-dsdt-into-qemu-bios.html )
<hallyn> thanks cking :)
<cjwatson> hallyn: OK, thanks a lot for the pointers; I'll see what I can make of it from here for a while, and will shout if I get stuck
<hallyn> cjwatson: np (last seabios change affecting dsdt directly was acpi: Use prt_slot() macro to describe irq pins of first PCI device. btw)  ttyl
<xnox> cjwatson: slangasek: can you look at bug 952185 again and see what's available to sponsor next, and if it's wanted or not. openssh is involved and other packages that slangasek looked at before.
<ubottu> bug 952185 in lightdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [High,In progress] https://launchpad.net/bugs/952185
<cjwatson> xnox: I'll have a look, but not today
<xnox> cjwatson: ok, thanks. Not very urgent, as i think slangasek did fix the bulk of it for raring already.
<slangasek> infinity: heimdall-flash> you're welcome :)  as for the CM wiki, there's a surprising amount of bad information in CM wiki pages that are locked :-P
<infinity> slangasek: Well, I'm not sure that pointing to upstream's builds would be generally considered "bad information", except that they currently seem broken, and yours works.
<infinity> slangasek: I also need to hunt down this upstream and figure out WTF they got their compiler.
<infinity> slangasek: It's baking in a PI of /lib/ld-linux-x86-64.so.2 (note the lack of 64 in the directory name...)
<infinity> So, some distro/toolchain is gratuitously incompatible with the world, and I want to find out so I can point and laugh at them.
<slangasek> infinity: heh, cute
<slangasek> infinity: I didn't mean the heimdall-flash stuff specifically; but there was some content on some of the pages giving users bad directions on how to do things on Ubuntu, and I was powerless to fix it
<infinity> slangasek: Isn't NCommander CM upstream still?  Get him to give you teh l33t access.
<slangasek> is he?  I didn't know he ever was
<slangasek> but anyway, now I'd have to remember where the page in question was
<slangasek> xnox: well, there's still an at branch awaiting my review on there; I don't remember seeing if there's an openssh patch ready for sponsoring
<slangasek> xnox: the bug state should in general be correct though
<xnox> slangasek: there are a few patches attached, one of them is for openssh last time i looked at that bug.
<cjwatson> There is an openssh one, but (a) openssh is in sync with Debian and I like to keep it that way now that I've gone to all that effort to get it there, (b) I really want to check quite hard what effect this might have on other bits of openssh
<slangasek> cjwatson: ok, understood
<ev> bdmurray: mind looking this over? http://paste.ubuntu.com/5607992/ mpt and I have been discussing how to fix bug 1077122.
<ubottu> bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122
<bdmurray> ev: I might need some more coffee for that topic, but sure.
<ev> bdmurray: whenever you have time today. I'm going to move on to your MP, then onto the script that rebuilds BucketVersions, since we have the new comparator finally in place on the cluster \o/
<ev> actually, coffee is a grand idea
<ev> oh and if anyone else finds the problem of calculating the average errors per calendar day interesting, do feel free to have a read through as well :)
<bdmurray> ev: is it ErrorsByDate or ErrorsByRelease?
<bdmurray> line 22-33
<ev> by release
<ev> fixing
<mterry> wgrant, heyo!  I have this old merge I'd like you to look at: https://code.launchpad.net/~mterry/launchpad-buildd/prefer-install/+merge/117318
<ev> http://paste.ubuntu.com/5608021/
<xnox> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: sconklin
 * xnox had enough.
<ev> quitter
<smartboyhw> xnox, LOL
<xnox> ev: when is your patch pilot turn?! =)))))
<ev> xnox: never
<ev> for medical reasons I can't touch other people's dirty code
<pitti> hey slangasek, good morning
<pitti> Laney: FYI, I found a workaround for cleaning up sessions now (for logind without systemd)
<pitti> slangasek: quick status update: libudev1 transition prepared in PPA (was trivial after all, just cherrypicking an lvm2 upstream commit, the rest works), logind shutdown/reboot/suspend etc. now works, and sessions are cleaned up properly
<pitti> slangasek: so by and large we are now blocked on the small FFE for updating systemd and at least a partial MIR for moving systemd's libudev* bits into main
<seb128> slangasek, pitti: if you partial MIR please partial MIR systemd-services as well ;-)
<pitti> seb128: well, neither me nor slangasek are in ~ubuntu-mir
<pitti> the udev bits are certainly trivial, as we already ship libudev in main
<pitti> -services might need an actual review
<seb128> right
<seb128> I just wanted to mention it
<seb128> I guess jdstrand/security team will want to review that one
<jdstrand> sarnold is assigned to that
<jdstrand> I think he is actively working on it
<vibhav> jdstrand: Incorrect usage of format strings is a security risk, right?
<pitti> sarnold: are you looking at the raring package (version 44) or the PPA (version 198)?
<jdstrand> vibhav: there is a class of vulnerabilities called format string vulnerabilities, yes. the compiler should pick these up and reduce them to DoS if using gcc
<vibhav> jdstrand: I had fixed a format string vulnerabilites in thoggen, would this qualify as a security update? https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning
<vibhav> And ther merge request for it: https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning/+merge/150969
<jdstrand> vibhav: only if errmsg->str is attacker controlled. even then, in lucid and higher this would result in an application termination and likely only 'low'
<vibhav> jdstrand: How are the incorrect use detected?
<jdstrand> vibhav: you have to go through the code paths and see how the error message is set
<jdstrand> vibhav: if it is just pulling strings from enums or something, then no worries. if you are adding a string that comes from outside your program which an attacker can control, then it would likely qualify as a security vuln
<vibhav> jdstrand: I mean how is the application terminated in lucid and higher? Is there a mechanism for detecting these risks?
<seb128> jdstrand, thanks ;-)
<jdstrand> vibhav: iirc, it is abort
<jdstrand> vibhav: the mechanism is code inspection. eg, going backwards from that point, seeing all the callers of the functions that calls that patched code, etc
<vibhav> jdstrand: ah
<vibhav> jdstrand: thanks
<cjwatson> Is it just me who has to look up which way round dd's seek and skip arguments go every single time?
<pitti> certainly not; clear case of poor naming
<sarnold> pitti: I started with the raring version (44) and moved to your ppa version after seeing your request :)
<sarnold> cjwatson: every. single. time.
<cjwatson> oh good.  what's the word for Schadenfreude when it applies to yourself as well?
<cjwatson> Schadenschade :P
<pitti> cjwatson: "Trost"? :-)
<cjwatson> Heh, maybe
<cjwatson> schwacher Trost
<vibhav> making fun of yourself?
<vibhav> (probably)
<bdmurray> ev: have you noticed the bucket page for most failed buckets appears empty?
<bdmurray> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fgtk-window-decorator%3A11%3Ai686%3A%2Flib%2Fi386-linux-gnu%2Flibglib-2.0.so.0.3400.0%2B35587%3A%2Fusr%2Fbin%2Fgtk-window-decorator%2B14f3e%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B562ce%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B57b0b%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B57bbd%3A%2Flib%2Fi386-linux-gnu%2Fli
<ev> that got cut off
<ev> and causes an exception that I'll fix now
<bdmurray> which exception? I just fixed one regarding bucket ids
<ev> bdmurray: that'd be the one :)  https://errors.ubuntu.com/oops-local/2013-03-12/59978.errors.ubuntu.com1
<ev> bdmurray: https://bugs.launchpad.net/errors/+bug/1154189
<ubottu> Launchpad bug 1154189 in Errors "Short URLs for buckets" [Undecided,New]
<bdmurray> ev: looking at the pastebin again I'm not clear where the system id exists in ErrorsByRelease
<bdmurray> ev: particularly the statement in lines 24-26 regarding 'first time we saw an error from this system'
<ev> bdmurray: I originally has the system id as part of a composite for the column name, but realised it wasn't needed
<cjwatson> hallyn,stgraber: Right.  The problem here is that seabios moved the description of the S5 state out of the DSDT into an SSDT.  GRUB should (I think) gain the ability to parse those, but can't right now
<ev> bdmurray: we could the number of unique systems elsewhere (the denominator), we just need to somehow weight each instance of problems seen over this period (the numerator)
<ev> count*
<ev> and we have the data to do that in the column value, the date of the first time the system which is responsible for this instance reported an error for that Ubuntu version
<bdmurray> so then is the statement regarding the system in lines 50-52 also unnecessary?
<ev> bdmurray: which part of it? Each column name is a uuid.uuid1(), which we create for each error coming in. Each value of that column is the date for the first time we received an error for the release, for the system reporting.
<smoser> stgraber, could you take a read / offer thoughts on https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570
<ubottu> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<bdmurray> ev: I guess I'm not seeing the relationship between ErrorsByRelease and a system e.g. a378 from line 1
<ev> bdmurray: there doesn't need to be. Instead of providing a key, the system identifier in this case, that we use as a link off to another column family where the rest of the data lives, we just include the data we need in the ErrorsByRelease CF
<ev> which duplicates it, but that's a common pattern in nosql
<ev> so we never actually need to know what the system identifier is. We just need to know that for the uuid for the error instance we're recording, the system first reported an error on X date
<blitzkrieg3> would it be possible for someone to sponsor bug 1025508
<blitzkrieg3> ?
<ubottu> bug 1025508 in OEM Priority Project precise "Some keys in keyboard layout show duplicate character labels" [Medium,In progress] https://launchpad.net/bugs/1025508
<ev> bdmurray: we'll then grab the number of unique systems from UniqueUsers90Days and use that as the denominator
<ev> but we don't need system identifiers for the numerator
<psusi> cjwatson: why does grub know or care about the acpi s5 description?
<cjwatson> psusi: It has a 'halt' command
<cjwatson> Which is quite important in its test suite
<cjwatson> (BTW sorry but I really don't have time to get into a design discussion about this right now)
<stgraber> smoser: it's on my todo for when I get to look at bug reports, this week for sure, maybe today, if not, tomorrow
<psusi> ahh... nifty.
<psusi> kind of a strange thing to move to an ssdt
<kaleo> Ubuntu suddenly displaying everything in Chinese, known bug?
<kaleo> maybe related to one of these 2 https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/992263 https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1024800
<ubottu> Launchpad bug 992263 in gnome-session (Ubuntu) "Gnome switches to chinese language " [Undecided,Confirmed]
<ubottu> Launchpad bug 1024800 in gnome-screensaver (Ubuntu) "Ubuntu 12.04 switches to Chinese language" [Undecided,Confirmed]
<cjwatson> psusi: It was something to do with some fancy qemu integration in seabios, apparently
<cjwatson> Looks like it patches the SSDT at run-time
<xnox> blitzkrieg3: it hasn't even make it into the sponsorship queue http://reqorts.qa.ubuntu.com/reports/sponsoring/ ubuntu-sponsors is subscribed, somebody will get around to it soon once it's in the report.
<xnox> (report updates every hour or so)
<blitzkrieg3> xnox: okay, thanks
<blitzkrieg3> xnox: I think I subscribed a while ago, any reason it didn't make it into the report?
<blitzkrieg3> xnox: I just added the libgnomekbd component
<xnox> blitzkrieg3: strange. adding tag patch to it, to see if that will make a difference.
<blitzkrieg3> xnox: thanks
<xnox> blitzkrieg3: right, so none of the open tasks were against ubuntu.
<xnox> blitzkrieg3: the g-c-c is invalid, and the rest are on the upstream projects.
<xnox> blitzkrieg3: now that libgnomekdb (ubuntu) added it will finally appear on the report.
<xnox> (not sure about tag patch, i don't think it's required but added for good luck anyway)
<blitzkrieg3> okay, so it was because I forgot to target libgnomekbd (ubuntu) I guess
<jbicha> kaleo: that's bug 1035219
<ubottu> bug 1035219 in Baltix "In System Settings preference tool/keyboard layouts page automaticaly wrong language selectedGNOME" [High,In progress] https://launchpad.net/bugs/1035219
<psusi> cjwatson: why would s5 be changed at runtime?  weirdness
<xnox> blitzkrieg3: it's up on the report now. should be dealt with soon.
<xnox> (well give it a couple of days)
<blitzkrieg3> xnox: awesome, thanks again for your help
<xnox> no problem.
<blitzkrieg3> xnox: yeah I'll re-ping if no one picks it up
<cjwatson> psusi: http://code.coreboot.org/p/seabios/source/commit/d51c4a0df1ae7bcb20ec3d569e409cf50f3ed760/ is all I know
<mitya57> debfx: hey, what's happening with bug 1081307? Were your packages rejected from -proposed? If yes, do you have any plans to upload the new ones?
<ubottu> bug 1081307 in virtualbox (Ubuntu Quantal) "virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build [merge request]" [High,In progress] https://launchpad.net/bugs/1081307
 * mitya57 can prepare the updated packages (maybe on the weekend), but wants to know if/why debfx's ones were rejected
<infinity> mitya57: slangasek's comment in bug 1031217 explain why the previous upload was rejected.
<ubottu> bug 1031217 in virtualbox (Ubuntu Quantal) "Ubuntu 12.04's use of networkmanager+dnsmasq breaks DNS for virtualbox VMs" [Undecided,Confirmed] https://launchpad.net/bugs/1031217
<infinity> mitya57: If you'd like to fish his out of the rejected queue and add your fix on top, that's cool, but please update the other two bugs with proper SRU justifications and testcases.
<infinity> mitya57: Otherwise, just uploading your own fix and letting him deal with the others later is just fine. :P
<kaleo> jbicha: thanks!
<mitya57> infinity: Thanks! I think it'll be fine to just re-upload his changes with the SRU information added and changelog fixed
 * mitya57 will look at other two bugs and add missing information tomorrow
<hallyn> stgraber: cgroup-lite breakage
<hallyn> stgraber: at least on a server iso, after first reboot, none is mounted on /sys/fs/cgroup
<hallyn> did mountall start doing that?
<hallyn> yeah there it is in /lib/init/fstab
<hallyn> aaaaand.  i see stgraber did it :)
<tkamppeter> OdyX, hi
<tkamppeter> OdyX, a second patch to complete the fix of bug 1069671 is posted by Mike Sweet, CUPS STR 4291.
<ubottu> bug 1069671 in cups (Ubuntu Quantal) "no print queues displayed in pure client mode" [Medium,Triaged] https://launchpad.net/bugs/1069671
<stgraber> hallyn: hehe, yeah. I thought we had a check in cgroup-lite that should have dealt with that properly?
<hallyn> stgraber: yes, it deals with it by saying "if that's mounted dont' do anything'
<hallyn> i can just pull tat check if that's the right thing to do :)
<stgraber> hallyn: ah, I thought it'd still setup the cgroups and just not mount /sys/fs/cgroup itself
<hallyn> it just figures that someone's been mucking with it, so it doesn't want to mess things up
<hallyn> stgraber: should cgroup-lite just be merged into mountall? :)
<NCommander> slangasek, infinity: wow, that's special (re: linker path). I thought heimdall-flash was open source, but if it isn't ....
<stgraber> hallyn: ah, ok. Then we should change that. Either to assume /sys/fs/cgroup is always mounted or to only mount /sys/fs/cgroup if it's not mounted and then always setup the cgroups
<stgraber> hallyn: mountall doesn't create directories and cgroup-lite may at some point do more than create directories and mount stuff
<hallyn> stgraber: really someday soon cgroup-lite may go back into libcgroup
<hallyn> jbernard is working on sysvinit scripts so we can have both upstart+sysvinit scripts there for simple boot stuff
<hallyn> anyway - i'll update cgroup-lite, thanks.
<slangasek> NCommander: it is open source, and a proper build is in Debian and Ubuntu.  That's separate from the question of upstream distributing bustificated binaries.
<stgraber> hallyn: np. Sorry for not noticing that the logic was wrong before I changed mountall. I wrongly assumed it'd do the "right" thing.
<hallyn> stgraber: heck, at this point it may be better to turn cgroup-lite into a mounted-cgroup script
<hallyn> but not right now
<hallyn> stgraber: so i take it i should now not umount /sys/fs/cgroup when it stops?
<stgraber> hallyn: right
<infinity> NCommander: That has nothing to do with heimdall-flash itself, per se, and has to do with whatever distro/toolchain they're using to build their binaries.
<slangasek> xnox: eh, how is bug #1154260 anything but a kernel bug?
<ubottu> bug 1154260 in upstart "FTBFS in test-suite on overlayfs" [Medium,Confirmed] https://launchpad.net/bugs/1154260
<slangasek> xnox: this is the known, "overlayfs lies about inotify support" bug
<infinity> xnox: slangasek is refering to bug 882147, if it's not familiar to you.
<ubottu> bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress] https://launchpad.net/bugs/882147
<infinity> xnox: You could, arguably, "fix" upstart's testsuite to skip that test when it detects that it's running on overlayfs, I suppose.
<infinity> (I was going to do the same for glibc's testsuite, then decided to just use aufs instead and lowered my blood pressure in the process)
<xnox> slangasek: well surely, upstart can detect broken inotify support and surely it can skip those tests?! we already skip all of inotify tests, if there is no inotify support or all inotify watches are taken up.
<infinity> xnox: You can't detect broken inotify support.  That's part of the bug.
<infinity> xnox: You can, however, detect that you're on a filesystem that you don't like.
<xnox> infinity: and you can totally inspect mounts, add one more confsource which is the location of the overlayfs upperdir and totally get complete inotify support, for the purposes that upstart needs ;-)
<infinity> xnox: 0x794c764f being the magic statfs constant for overlayfs, if you feel the urge.
<xnox> afterall we made multiple conf-sources rock for user-sessions, why can we not abuse that for system init. Since well there are _two_ /etc/init dirs when running on top of overlayfs.
<infinity> Three.
<xnox> infinity: sure, but the other two are combined in the same way upstart combines multiple sources.
<xnox> infinity: hence upstart really just needs the upper & lower dirs separately prefferably, we combine the outputs ourself.
<infinity> But sure, you could do something vile like that.  I tend to think that second-guessing your VFS layer is just writing bugs for future programmers to hate you for, but...
<xnox> hardly vile, just willing to bend backwards to get inotify support.
<infinity> I think it's vile to assume you know the structure of something that's meant to be opaque, yes. :P
<infinity> The fact that you *do* know the structure is irrelevant, it could all change tomorrow, and the bug is with you, not the kernel, cause you're only ever supposed to be "talking" to the top layer.
<xnox> infinity: sure we can make the top layer authorative, but we can accept commandline options for something else to tell us where the other layers are, like for example on livecds we can be told by (casper?!) that there are other places to listen for inotify watches.
<slangasek> xnox: I think hacking around overlayfs in upstart's test suite is a losing proposition.  Like infinity says, it's writing bugs for future programmers.
<slangasek> xnox: tests fail when running on overlayfs because *upstart* fails to work correctly when running on overlayfs.  overlayfs at a minimum should be fixed to not lie about supporting inotify
<xnox> ack.
<xnox> slangasek: what about establishing additional watches & rewalk confsource when we get inotify events for other (shadow) directories?
<slangasek> xnox: doesn't that come back to assuming implementation details about overlayfs?
<xnox> no, it's a generic file based API to ask upstart to essentially do `initctl reload-configuration`
<xnox> i'm not proposing for upstart to transverse and try to figure out exactly how many times nested overlayfs there is, simply "by the way please inotifywatch this dir as well"
<infinity> xnox: The livecd use case that everyone cares about (I installed ssh but the job isn't found) could be solved with a dpkg trigger that registers interest in /etc/init and forces a conf reload.
<infinity> slangasek: ^
<slangasek> xnox: sorry, my question is, "what dir"?
<slangasek> is this a matter of passing information from the mounter to upstart?
<xnox> yes.
<slangasek> hmm
<slangasek> infinity: put the trigger in casper?  we don't want to have to rely on a trigger on the installed system.  Also, this doesn't solve user jobs
<xnox> I am prototyping a demo locally, now. I'll post something to upstart-devel once I have it working. But yeah, it's the usecase infinity outlined above.
<infinity> slangasek: No, have the trigger in upstart.
<slangasek> mm
<slangasek> then that means the trigger is active post-install too
<infinity> slangasek: But yeah, it doesn't solve user jobs on a live union.
<slangasek> which is wasteful
<infinity> It's mildly wasteful, but I assume executes quickly.
<infinity> It made more sense when I suggested it six months ago, before user jobs came into the picture.
<infinity> Anyhow, I'm going to take a jetlag-induced afternoon nap, I've been up all night.  Back later this evening.
<infinity> I'm not wildly happy about the idea of assuming overlayfs implementation, but given that casper needs to do that already to mount the filesystem inthe first place, if it then just passes the top layer as an extra argument to upstart, that's probably not world-ending.
<infinity> Any change in how overlayfs works would have needed a casper change regardless, so now it would just need two.
<xnox> infinity: yeap.
<mdeslaur> soren: were you planning a ruby1.8 upload for LP: 1142977?
<ubottu> Launchpad bug 1142977 in ruby1.8 (Ubuntu) "Timeout module segfaults" [Undecided,Confirmed] https://launchpad.net/bugs/1142977
<Sweetshark> cjwatson, bdrung: https://launchpad.net/ubuntu/+source/libreoffice/1:4.0.1-0ubuntu2/+build/4361643 <- should be finished any minute now ...
<yofel> any reason why lp:ubuntu/raring/apport is lagging behind the archive for several versions?
<slangasek> yofel: import failures explained here: http://package-import.ubuntu.com/status/
<soren> mdeslaur: I tried to poke doko about it, but didn't catch him. It was during vUDS, so I guess that's to be expected.
<yofel> slangasek: thanks! Didn't know about that page yet
<mdeslaur> soren: ok, I'll try and poke him about it too...I don't want the doko beatdown either :)
<sconklin> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<stgraber> smoser: finally got around to looking at that isc-dhcp bug. I'm not against carrying patches, it wouldn't exactly be the first one we have and that ISC disagrees on. I'll take a closer look tomorrow.
<wgrant> mterry: Hm, you should probably get infinity's opinion on that. Really someone should just upgrade sbuild.
<mterry> wgrant, apparently we are very divergent at this point, and we didn't want to risk unforking?  (iirc)
<wgrant> mterry: That's completely wrong, we've wanted to unfork for several years. I did most of the work a few years ago, but ddebs and similar bits and pieces ended up problematic.
<wgrant> So it's the preferred approach
<wgrant> Mostly just a lack of time :/
<mterry> wgrant, ah fair OK
#ubuntu-devel 2013-03-13
<cjwatson> hallyn,stgraber: https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00060.html (phew)
<cjwatson> Sweetshark: Thanks
<Sweetshark> cjwatson: np
<hallyn> cjwatson: wow - thanks
<cjwatson> stgraber: Uploading.  If 2.00-13ubuntu2 builds then you probably want to unblock it and retry Edubuntu amd64 image builds with it.  I think I need to go to sleep now and recover some SAN points ...
<stgraber> cjwatson: yep. Will unblock once it's done building. Thanks!
<pitti> Good morning
<pitti> stgraber, infinity: I got an FFE ack for libudev1; could you please place a block on the systemd source, so that I can stage everything in -proposed, and to avoid potentially disrupting beta-1?
<sarnold> pitti: re: logind, udevd, from systemd -- I intended to write the results of my audit tonight, but I'm tired enough now that I'm just going to go to bed.
<pitti> sarnold: ah, thanks; I guess for the libudev part it doesn't matter much, as we already have that code in main, just from another source?
<sarnold> pitti: however, please consider the MIR for logind, udevd, an ACK from me. I'll write it up in the morning (~nine hours from now)
<pitti> sarnold: but for the services and logind etc. it'll be appreciated
<pitti> sarnold: oh, nice! thanks
<sarnold> pitti: jdstrand had asked me to give logind and udevd a look -- and that's as far as I looked. (it _is_ a big code base :)
<sarnold> pitti: but I wanted to unblock you before going to bed, you've got a whole day to work ahead of you :)
<pitti> sarnold: I'll do the libudev1 transition, but keep logind etc. in universe until we got your official ack plus the FFE for logind
<sarnold> pitti: okay :) I can't speak to the FFE
<pitti> sarnold: the logind transition won't happen today, so that won't block me; but I'm happy that the libudev1 transition is unblocked, indeed
<sarnold> pitti: cool. :)
<mbiebl> pitti: as we discussed, I think the important bit is what to do about 3rd party software which currently make use of different systemd subsystems
<pitti> mbiebl: guten Morgen
<mbiebl> but use a simple-all-or-nothing check
<pitti> mbiebl: indeed
<mbiebl> I think we need buy-in from upstream on that matter
<mbiebl> othwerwise we will be distro-patching software for this forever
<pitti> mbiebl: I'll talk to Lennart today what would be an appropriate and simple check for "systemd booted", perhaps testing somethign in /run/systemd/
<mbiebl> pitti: Ideally with some simple to use api like sd_booted()
<mbiebl> sd_logind() maybe, dunno
<mbiebl> sd_journald(), ...
<pitti> sd_booted() is kind of burned now, so indeed, maybe sd_using_logind() and sd_using_systemd()
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<pitti> Laney: good morning; as I didn't reach infinity or stgraber any more, could you please put a block on systemd and udev? I'd like to do the libudev1 migration in -proposed
<bkerensa> pitti: https://launchpad.net/~bkerensa/+archive/logind/  does this look good for a logind transition?
<pitti> bkerensa: https://launchpadlibrarian.net/133702140/xfce4-power-manager_1.2.0-1ubuntu2_1.2.0-1ubuntu3bkerensa1.diff.gz looks good to me indeed, thanks!
<pitti> bkerensa: I updated the status in the bp
<pitti> bkerensa: nice, I wasn't aware that upstream XFCE also already supported logind
<pitti> mbiebl: does "systemd-services" sound like an appropriate name to you, BTW? (I'd like to avoid another rename later if/when that goes into Debian)
<mbiebl> pitti: let's discuss that on #debian-systemd
<pitti> mbiebl: I'm in now
<Laney> pitti: oops, I read this and then forgot
<Laney> doing
<Laney> done
<pitti> Laney: sorry, temporary server/IRC fail; [10:33:51] done was about setting the block?
<Laney> indeed!
<pitti> Laney: cheers!
<pitti> so libudev1, here you come; brace for impact
<Laney> pitti: have you seen this: http://paste.ubuntu.com/5610182/ ? (first install)
<pitti> Laney: uh, no, never; checking
<Laney> I just did 'start systemd-logind' in another terminal and it seems to have worked
<pitti> Laney: hm, I purged and reinstalled
<Laney> laney@iota> sudo more /var/log/upstart/systemd-logind.log                                                                                  ~
<Laney> mkdir: cannot create directory '/sys/fs/cgroup/systemd': No such file or directory
<pitti> ooh
<pitti> Laney: booted with earlier mountall?
<pitti> Laney: it depends on current mountall now
<Laney> if that would have been upgraded in this apt run
<Laney> i.e. since yesterday
<pitti> it was updated last Friday night already, did you upgrade and reboot since then?
<Laney> ah, perhaps I didn't reboot
<pitti> I dropped the mounting of /sys/fs/cgroup again, as mountall is now doing it
<Laney> I did get a cgroup-lite update here which maybe kicked it
<Laney> anyway - would that affect upgraders or is it some transient raring problem?
<pitti> I think its postinst is slightly evil
<pitti> as it unconditionally unmounts it; we need to fix that
<pitti> Laney: I think it will affect upgrades, I'll put back the mount for now
<pitti> Laney: ok, good timing; I was just about to press enter on dput :)
<pitti> Laney: anything else which comes to your mind?
<pitti> well, at this point it's only libudev1
<Laney> yeah - don't think you need to hold off on the transition for this if you want to do both in parallel
<pitti> Laney: oh, I fixed that upgrade issue now
<pitti> $ dput systemd_198-0ubuntu1_source.changes
 * pitti holds breath
<pitti> I let that build and publish, and then upload my stack of 39 packages for the transition
<chrisccoulson> pitti - transition? transition to systemd? ;)
<pitti> chrisccoulson: my secret plot!
<chrisccoulson> heh :)
<pitti> chrisccoulson: not quite -- libudev0 â libudev1 for now, ConsoleKit â logind FFE is still outstanding
<pitti> seb128: can I ask you to binNEW libudev1 (to main), and python-systemd (to universe)?
<pitti> seb128: that'll unblock me from uploading the libudev1 transition to -proposed
<seb128> pitti, looking
<seb128> pitti, done
<pitti> seb128: merci!
<hallyn> lastlog ureadahead
<hallyn> feh
<hallyn> hm.  so i had to set ureadahead to manual to boot
<hallyn> known bug?
<hallyn> it was getting killed and then all boot would hang
<hallyn> i was surprised how fast boot still ran by :)  i thought ureadahead was doing more for me, even on ssd
<hallyn> whelp, guess i'm probably the only one (that or everyone else is still working aorudn broken boot :)
<cjwatson> My boot was fine this morning FWIW
<hallyn> thanks, that is a relief
<hallyn> long as i just did something to hose my own system :)
<cjwatson> Admittedly haven't rebooted since the last round of upgrades, but I don't see that much that could be relevant
<cjwatson> Unless it's your cgroup-lite changes :)
<hallyn> cjwatson: :)  didn't actually have those yet, nor the latest ureadahead
<cjwatson> The latest ureadahead is still in raring-proposed anyway
<cjwatson> So nobody should have it yet
<hallyn> unfortunately while in my 'init=/bin/sh' boot I did echo manual > ureadahead.conf, not ureadahead.conf.override :)
<hallyn> so i'll have to re-extract it manually to test at some point
<cjwatson> dpkg --force-confdef
<hallyn> neat, that's a new one
<hallyn> for me
<cjwatson> actually can't remember if that does it, possibly not.  If it doesn't, remove the conffile entirely and use dpkg --force-confmiss
<cjwatson> --force-confdef might only do anything if you would normally get a conffile prompt, thinking about it
<cjwatson> so, yeah, ignore that part
<cjwatson> But --force-confmiss will work if you remove the file
<hallyn> sound easier to dpkg -x and cp it back :)
<hallyn> but now i know what to look for next time i need it
<Industrial> I have installed git-daemon-run to run a git daemon on this computer. I have a bare repository at /home/tom/Documents/repos/utils.git. If I clone git://127.0.0.1:0418/home/tom/Documents/repos/utils.git then I get an authentication error. Did I miss a step?
<Industrial> I cannot ask this in #git because it involves an ubuntu package and possible configuration. when i check service --status-all I don't see a git-server, but the git-server-run package is installed
<smoser> anyone able to tell me what luser error I'm committing at https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1154599 ?
<ubottu> Launchpad bug 1154599 in python2.7 (Ubuntu) "dns lookup failure raises socket.error not socket.gaierror" [Undecided,New]
<smoser> it seems this would be significant
<ScottK> smoser: Do you have python2.7 installed?
<smoser> ScottK, umm.. yes. i invoked it and showed the dpkg-query info.
<ScottK> OK.  I was wondering because the info in the bug was python2.7-minimal.
 * smoser is really not all here today.
<smoser> ScottK, ah.  i just opened against /usr/bin/python2.7
<ScottK> OK.
<ScottK> smoser: Your script works for me.
<ScottK> (on raring)
<smoser> odd.
<pitti> can anyone make sense of this rejected upload? https://launchpadlibrarian.net/134071024/upload_4366338_log.txt
<cjwatson> Probably a librarian glitch
 * cjwatson checks
<pitti> from https://launchpad.net/ubuntu/+source/xbmc/2:12.0~git20130103.0959-rc3-0ubuntu1b1
<pitti> I can just hit the retry button, but I've never seen this before
<cjwatson> pitti: It happens now and again, but is rare
<cjwatson> https://oops.canonical.com/?oopsid=OOPS-7fdbd9bf041fdd059ad3ed59a31dde9f is all the further info I can find
<pitti> cjwatson: ok, thanks; I'll kindly ask it to try harder
<cjwatson> (And isn't really any more informative)
<cjwatson> Yeah, I'd mash retry
<pitti> also, I may have upset http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html -- I fixed that bug, but it stopped updating since
 * pitti checks
<pitti> uh, seems lillypilly is painfully busy right now, even ssh takes > 1 min (still not logged in)
<pitti> I guess that's the reason
<cjwatson>  14:35:24 up 95 days, 16:53, 10 users,  load average: 9.16, 7.24, 7.23
<pitti> ah, you managed to ssh in? mine's still trying
<GunnarHj> dholbach: ping
<dholbach> GunnarHj, pong
<GunnarHj> dholbach: Hi Daniel! Saw your UbuntuKylin work item and wondering how the im functionality is affected by UnityNext/Mir. To me the xkb and im integration in g-c-c seems to be of great significance. Maybe they are both important... Can you shed some light, or were you just connecting the teams?
<dholbach> GunnarHj, yes, I just connected them - I'll CC you in a reply if you're interested
<GunnarHj> dholbach: Yes, that would be great.
<dholbach> sweet, will do
<SpamapS> something bad happened to Google Chrome in the last 2 months.. it just.. sits there sometimes... not sure if there's a compatiblity problem with raring or what.. but.. its gone from my favorite browser to my favorite thing to kill -9
<jcastro> SpamapS: me too
<jcastro> it's becoming quite unstable for me
<SpamapS> jcastro: you running google-chrome-stable I presume?
<jcastro> yep
<Sarvatt> jcastro, SpamapS: try disabling ppapi flash in about:plugins
<SpamapS> bbuut... I neeeed flash
<Sarvatt> SpamapS: use npapi flash from the distro, the ppapi one thats bundled causes hangs for me too
<micahg> pitti: does dch -R not DTRT for  you for rebuilds?
<SpamapS> Sarvatt: wow thats pretty obscure. Anything we can do to convince Google to do that as the default?
<jcastro> SpamapS: I think their intent is for us to use the built in one, it just happens to be more broken than the other one.
<Sarvatt> well theoretically we want to use that since its the only way flash gets real updates anymore on linux, but they update it pretty aggressively in chrome and it breaks all the time here :(
<micahg> well, the NPAPI flash should continue to get updates for the life of precise
<micahg> *security updates
<SpamapS> jcastro: I think google's intent is to kill flash.. but.. yeah :)
<SpamapS> jcastro: do you get problems where everything except copy/paste works ?
<jcastro> I get this thing where it freezes up and then the tabs get misrendered and the entire thing zombies.
<SpamapS> jcastro: yes thats what I"m getting too
<jcastro> I just turned off the flash as Sarvatt says, I'll let you know how it works for me
<tseliot> cjwatson, infinity: I have a fix for bug #1073062 which I have just sent to Debian. Do you thinkl I should wait for their response before including my fix in Ubuntu?
<ubottu> bug 1073062 in kmod (Ubuntu) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1073062
<pitti> micahg: ah, I wasn't aware of this; I have used a pretty ancient script
<cjwatson> tseliot: I think it'd be OK to go ahead with it in Ubuntu in the meantime, given the number of dups
<tseliot> cjwatson: ok, I'll do it then, thanks
<cjwatson> ta
<lool> gema_: Is there some QA list that would be best to send the links to the notes and video?
<gema_> lool: ubuntu-quality I think
<lool> gema_: sent; NB: I'm not sub-ed
<gema_> lool: ok, I don't see it, I will ask an admin to check
 * gema_ -> EOD
<stokachu> RAOF: i updated bug 1098186, could you finalize it at this point?
<ubottu> bug 1098186 in bamf (Ubuntu Quantal) "Unity groups separate Java webstart app windows" [Medium,Fix committed] https://launchpad.net/bugs/1098186
<stokachu> for precise at least
<dupondje> whoops, booting broken ?
<dupondje> just updated to libudev1, and booting fails: unable to find /dev/by-uuid/*
<melodie> hello
<melodie> would someone have the patience to explain me newbie, what is the difference (if any) between a filesystem.manifest-remove file and a filesystem.manifest-desktop file in the casper directories of Ubuntu ISOS ?
<slangasek> dupondje: libudev1 isn't in raring; why are you pulling from raring-proposed?
<slangasek> pitti: ^^ problems reported with libudev1 :/
<slangasek> melodie: I've never heard of either of these files; they both sound to me like accidental build system cruft
<stgraber> slangasek: aren't they what's used by ubiquity to generate the "not to copy" file list?
<slangasek> stgraber: hmm, I guess that's possible :)
<pitti> dupondje: how did you update to libudev1? what did you install exactly?
<slangasek> yeah, seems that .manifest-remove is used by ubiquity
<stgraber> slangasek: right, ubiquity reads both of those files in install.py and plugininstall.py (according to a quick grep)
<pitti> dupondje: note that our udev doesn't actually use libudev1
<melodie> slangasek no they are used in the isos to list the packages installed, to list the packages which will be removed at the end of the install to hard drive, and the difference  of the two I said is not yet defined for me, so I am asking
<pitti> dupondje: anyway, just driving by here; perhaps you can file a bug with teh details (please attach /var/log/dpkg.log) and subscribe me?
<slangasek> melodie: ah, well then you officially don't get to claim to be a newbie if you already know that ;) but it sounds like stgraber may be able to explain better
<melodie> slangasek I am a newbie learning how to build a spin with a basic version and ubuntu builder, and there is so much to learn it is huge!
<melodie> in several versions I found the *-remove file and in some I found only the *-desktop file, so I am in a wonder
<melodie> I'll try to extract both side to side and do a vimdiff, incase that could help (just got the idea)
<slangasek> melodie: possibly the usage has changed over time?
<melodie> it seems not, I have been told 12.04.2 has the *-remove file
<melodie> I just don't know why it is different in some versions
<stgraber> melodie: from what I see, you need either "filesystem.manifest-remove" + "filesystem.manifest" or "filesystem.manifest-desktop" + "filesystem.manifest"
<stgraber> melodie: you don't need all three of them
<dupondje> slangasek: raring-proposed indeed :)
<slangasek> dupondje: yes, but why... :) raring-proposed is not meant for use by humans
<melodie> it seems two are needed : filesystem.manifest plus one of the two others but what is the difference betweek the two others... this is my question :)
<dupondje> pitti: seems like even /dev/sda* does not exist :s
<melodie> stgraber where did you see it ?
<slangasek> melodie: ubiquity/doc/README seems to explain
<melodie> slangasek thanks! me stumble upon it
<slangasek> dupondje: did udev not start correctly?
<dupondje> slangasek: living on the edge .. :P
<slangasek> dupondje: that's not an edge you're supposed to be living on. *it's not for humans.*
<slangasek> dupondje: though in this case, perhaps we can be grateful that you hit this bug before it reached raring ;P
<dupondje> hehe :P
<stgraber> melodie: my understanding is that filesystem.manifest-remove is a list of package to remove, filesystem.manifest-desktop is the list of packages post-installation and filesystem.manifest is the list of everything (equivalent of filesystem.manifest-desktop + filesystem.manifest-remove)
<stgraber> melodie: or so the code looks like. I haven't looked at ubiquity/doc/README yet :)
<melodie> is that /usr/share/doc/ubiquity/README.gz too ?
<stgraber> possibly. I'm looking at lp:ubiquity and it's in doc/README in there
<dupondje> /dev/sda* seems to be missing in grub2 console, but it exists when it boots in the temp shell :s
<melodie> ok, I'm going there and compare fast
<melodie> to see if the zgrep shows the same
<cjwatson> manifest-desktop was the old additive one, manifest-desktop is subtractive
<cjwatson> er, manifest-remove is subtractive
<cjwatson> the latter turned out to be easier to maintain, so is preferred
<cjwatson> But you shouldn't have both, except perhaps in unofficial builds; our build system only creates one or the other
<melodie> hi cjwatson, so having either or is ok if I understand well ?
<cjwatson> correct.  having both is not harmful as such but is pointless.
<cjwatson> Support for manifest-remove was added in oneiric; there's really no reason to have manifest-desktop these days.
<Laney> hrm, I wonder what happened to my sound device
<melodie> I end with a filesystem.manifest, and a filesystem.manifest-desktop, and I was wondering why instead of "filesystem.manifest-desktop" in the official versions there is "filesystem.manifest-remove" hence my question
<cjwatson> I have no idea what build system you might be using that still creates manifest-desktop
<melodie> this is Ubuntu Builder for the time being.
<psusi> cjwatson: do you happen to know the source package responsible for the d-i script 'list-devices'?  I can't seem to find it
<cjwatson> I have no idea what that is :)
<cjwatson> The discussion that led to its replacement by manifest-remove is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627439
<ubottu> Debian bug 627439 in live-build "support for two-pass manifests" [Wishlist,Fixed]
<cjwatson> psusi: debian-installer-utils
<melodie> thank you very much !
 * psusi looks through that one again
<psusi> lol... that's why I missed it.. there's separate ones for -linux, -hurd, etc that must get renamed
<cjwatson> It's called list-devices-linux in the source package
<melodie> and thanks also to stgraber and slangasek who tried to help me;
<cjwatson> "Ubuntu Builder" sounds like one of those things with a name that makes it sound more official than it is ...
<cjwatson> Which is always unfortunate
<Laney> pitti: I just noticed two problems that went away after I ppa-purged the logind PPA (and manually removed systemd-services and other systemd packages) - brightness adjustment wouldn't do anything and I had no audio devices in PA.
<Laney> manually removed> I guess you deleted those from the PPA?
<dupondje> hmz :( screwed it seems. /dev/sdaX should be available in grub2 console no?
<cjwatson> No, that's a Linux device name.
<cjwatson> 'ls' will tell you what disks GRUB can see.  They won't be called the same thing that Linux calls them.
<dupondje> Ok, finally able to get booted :) seems like /dev/by-uuid is created to late. If I wait some seconds in the busybox, i'm able to boot :)
<dupondje> pitti: slangasek: ^^ could be caused by the libudev update somehow?
<dupondje> ah well, some other things upgraded also today .. so could be some other updates
<slangasek> dupondje: did udev itself get updated on your system?  the by-uuid creation shouldn't depend on anything outside of udev
<slangasek> dupondje: though, are the uuids in question related to cryptsetup/lvm?
<dupondje> nope normal disk
<dupondje> ii  udev                                      175-0ubuntu20                                amd64        rule-based device node and kernel event manager
<slangasek> right, then I'm really not sure why anything would have changed if it's only about a normal disk
<lool> gema_: could you ask for *@ubuntu.com to be whitelisted?
<dupondje> also upgraded grub2 / mountall / upstart / libdevmapper / initramfs-tools / kmod / module-init-tools
<dupondje> alot of potential causes :)
<slangasek> has nothing to do with grub
<slangasek> not if it's gotten you to a kernel
<dupondje> yea it does, just boots into a initramfs busybox
<slangasek> dupondje: so it's certainly possible that libudev1+initramfs-tools-bin are broken somehow
<slangasek> since wait-for-root relies on libudev1
<dupondje> Well I can boot now :) but it may be good to get it fixed ^^
<dupondje> :P
<slangasek> dupondje: can you downgrade initramfs-tools-bin and reboot, see if it still happens?
<dupondje> let me see
<dupondje> brb
<dupondje> slangasek: ok that works
<slangasek> dupondje: ok.  can you please open a bug report against initramfs-tools about this?
<dupondje> downgraded initramfs-tools & initramfs-tools-bin btw
<slangasek> stgraber: ^^ can you please /not/ unblock systemd and friends until further notice?
<stgraber> Laney: ^
<dupondje> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1154813
<ubottu> Launchpad bug 1154813 in initramfs-tools (Ubuntu) "Boot broken with initramfs-tools 0.103ubuntu0.5b1" [Undecided,New]
<Laney> wasn't planning on
<ScottK> pitti: ^^^
<Laney> but merci
<ScottK> It would also, once this is sorted, make sure there's an appropriate test so we don't have to depend on humans running $DEVEL-proposed.
<infinity> pitti: While we're on the topic of your libudev rebuilds, why did you break Ubuntu versioning tradition/policy and go with -NubuntuNb1 instead of -Nubuntu$((N+1)) ?
<dupondje> good i'm that crazy to run raring-proposed :P
<dupondje> bbl, slangasek: thanks for the assistance :)
<melodie> good night
<ScottK> jdstrand: The last chromium-browser upload for raring that you sponsored is having some rather unfortunate side effects.  See Bug #1154218.
<ubottu> bug 1154218 in chromium-browser (Ubuntu) "Recommends on unity-chromium-extension installs a lot of gnome dependencies" [High,Triaged] https://launchpad.net/bugs/1154218
<ScottK> yofel: ^^^
<bdmurray> mterry: you originally worked on bug 848605 it seems to not have been fixed as you can see in bug 1056545
<ubottu> bug 848605 in sessioninstaller (Ubuntu Precise) "session-installer crashed with AlreadyCalledDeferred in callback()" [High,Fix released] https://launchpad.net/bugs/848605
<ubottu> bug 1056545 in sessioninstaller (Ubuntu) "session-installer crashed with AlreadyCalledDeferred in callback()" [High,Triaged] https://launchpad.net/bugs/1056545
<bdmurray> mterry: I've found a testcase now and put it in the new bug if you could have a look
<bdmurray> mterry: according to errors it seems to occur less (if at all) in raring.
#ubuntu-devel 2013-03-14
<psusi> ok, what the hell?  I added my key to ubuntu-keyring as the wiki said  to do for customizing the install cd, yet it isn't there in the installed target... if I chroot into /target and manually install ubuntu-keyring, it's there.. it's like it's got a secret copy of the original package stashed somewhere that it's installing instead of mine
<psusi> but of course, mine is the only one in pool/main/u/ubuntu-keyring
<psusi> oh weird... it seems that d-i does *not* use debootstrap, but has switched to live-install, which copies a pre debootstrapped squashfs image.  hrm...
<psusi> had to slip the updated ubuntu-keyring into the squashfs
<psusi> can probably get back some space on the install cd by eliminating the packages from the pool that are already included in the squashfs... or maybe drop the squashfs if eatmydata can reduce the extra time deboostrap takes over the squashfs method to a minimum
<psusi> wow... 4.5 minutes for an update-initramfs, then it turns around and does it again 10 seconds later.. that's going to have to go...
<StevenK> psusi: It also requires initramfs size*2.5 or so in /boot
<StevenK> Otherwise it gets very cranky
<psusi> it looks like there is a *log* of low hanging fruit for speeding up d-i these days
<psusi> *lot* even
<pitti> Good morning
<pitti> dupondje: did you upgrade initramfs-tools along?
<pitti> dupondje: thanks for the bug, will investigate there
<pitti> infinity: versions> because ubuntuN+1 steals actually used version numbers, and I'd have to commit all these no-change rebuilds to VCSes (some of which I can't even access)
<pitti> infinity: for the unmodified Debian ones I went with the normal -buildN
<pitti> dupondje, slangasek, ScottK: FYI, I followed up to bug 1154813
<ubottu> bug 1154813 in systemd (Ubuntu) "Boot broken with initramfs-tools 0.103ubuntu0.5b1" [Critical,In progress] https://launchpad.net/bugs/1154813
<pitti> will upload the workaround again (argh for papering over unreproducible bugs)
<slangasek> pitti: hmmmm, interestingly when I was looking at logind originally, I also ran into problems with SOCK_NONBLOCK there which I was subsequently unable to reproduce in raring
<pitti> slangasek: I'll look at sbin/wait-for-root in the initramfs, I guess that somehow doesn't get along with a nonblocking socket
<slangasek> (so I never applied that patch to the package)
 * slangasek nods
<pitti> that's the only plausible thing in the initramfs which could cause this
<slangasek> wait-for-root isn't Ubuntu-specific though, is it?
<pitti> I think lool hit this in udev 171
<pitti> so I guess I can poke both dupondje and him to test a possible fix
<slangasek> ah no, it *is* UBuntu-specific
<pitti> ah, that sounds very likely then
<pitti> slangasek: WDYT if I change wait-for-root to set the socket to blocking instead?
<pitti> slangasek: that at least reduces the workaround to the one place which we know is broken, without affecting all the rest of the system
<slangasek> pitti: well, what's the downside of making the sockets blocking everywhere?
<slangasek> if nonblocking is the "right" answer, then we can make wait-for-root set the blocking flag for its own use; but I'm concerned about the same bug recurring in other users of libudev
<pitti> I don't quite like this kind of diversion from upstream ABIs;
<slangasek> if we were actually auditing the revdeps to make sure they all cope with a nonblocking socket, that would be fine with me
<pitti> we can add it back and cement the diversion, but it doesn't happen in any other distro
<slangasek> but having found one user that doesn't cope with nonblocking, I think there are likely to be others
<pitti> well, adding blockign is certainly not a fix, just a reduction of the workaround
<slangasek> "any other distro" - Debian also doesn't have libudev1
<pitti> I'm currently staring at the code to see what it could do wrong there
<pitti> slangasek: SOCK_NONBLOCK was introduced in udev 171, that was years ago
<slangasek> it has libudev0 that's at the same upstream version as ours
<slangasek> oh, you said this was an Ubuntu-specific patch to udev previously, right
<pitti> and enen the documentation says "The monitor socket is by default set to NONBLOCK"
<pitti> ooh, I see
<pitti> main() just does
<pitti>         while ((udev_device = udev_monitor_receive_device (udev_monitor)) != NULL) {
<pitti> but the documentation says " variant of poll() on the file descriptor returned by udev_monitor_get_fd() should to be used to wake up when new devices arrive, or alternatively the file descriptor switched into blocking mode."
<pitti> sorry, missing an "A" at the beginning
<pitti> so switchign to blocking there is actually the right answer, as this program doesn't have to do anything else than waiting for udev events
 * slangasek nods
<pitti> slangasek: I'll walk through http://codesearch.debian.net/search?q=udev_monitor_receive_device
<pitti> just two pages, that's not too hard to audit
<slangasek> fwiw I've just checked that upstart and mountall are ok
<slangasek> lvm seems not to use it
<slangasek> (despite using libudev)
<pitti> usually one would call this function from an event callback, where the blocking doesn't matter, indeed
<slangasek> so, that probably covers us as far as breaks-your-system, unbootable regressions are concerned
<slangasek> oh, should probably check libdevmapper too
<slangasek> ah no, that's from lvm2 source after all
<pitti> xorg also looks good
<pitti> pretty much everything calls that from callback handlers
<pitti> upstart looks good
<pitti> (ah, you already checked it)
<pitti> dupondje: so, sorry for the trouble!
<pitti> we should have debugged this properly back then, such things are lingering disasters
<slangasek> pitti: debian/patches/avoid-exit-deadlock-for-dm_cookie.patch also touches libudev; have you forward-ported this one to the systemd package?
<pitti> no, I didn't
<pitti> *nnng* people, please forward such patches upstream
<slangasek> I thought I remember this one being forwarded upstream at the time, despite not having the info in the patch header
<slangasek> or, it's possible that this wasn't upstreamed because it's only used in conjunction with some difficult-to-unwind lvm2 patches which are also not upstream
 * pitti googles "google site:spinics.net hotplug DM_COOKIE", but cannot find anything
<pitti> ah; we have a much newer lvm2 now, are we still having these patches?
<slangasek> yes
<slangasek> pitti: so, the patch is still needed but despite being exported as part of libudev0, it seems that udev itself is the only consumer
<slangasek> so we can omit that for now
<pitti> ah, good
<slangasek> (lvm2 relies on that functionality, but only in udevd)
<pitti> we still need to port it once we move to current udev then
<slangasek> yep
<pitti> thanks for checking
<pitti> slangasek: http://paste.ubuntu.com/5612832/ , rebooting now for smoketesting
<pitti> still boots fine
<pitti> so, feel entitled to yell "Lennart broke my boot!" :-)
<mlankhorst> "Lennart broke my boot!"
<pitti> dupondje: \o/
<pabs3> infinity: so, who else is in ubuntu-sru that I could ping for reviewing samba for precise-updates?
<dholbach> good morning
<mlankhorst> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: mlankhorst
<gema_> lool: will do
<dupondje> thx pitti  :)
<pitti> bkerensa: is xfce4-session also already ported to logind?
<mlankhorst> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<mlankhorst> bbiab
<mlankhorst> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: mlankhorst
<seb128> ev, hey, https://errors.ubuntu.com/?package=nautilus triggers an error ... known issue?
<mlankhorst> pitti: is it any problem if i upload new versions of packages that use libudev? xorg-server and mesa 9.0.3
<pitti> mlankhorst: no, that's fine; please feel free to stomp over my "no-change rebuild" changelog with -b1 suffixes
<pitti> mlankhorst: I deliberately chose those suffices to not steal the next version numbers and get out of sync with VCSes
 * ev digs
<mlankhorst> I hope mesa 9.0.3 won't bump wayland again
<pitti> mlankhorst: *shrug* the more you upload the fewer TIL remain for me :-P
<ev> seb128: just waiting for webops to roll out the fix
<seb128> ev, thanks
<ev> seb128: mthaddon is on it. RT 60095.
<seb128> excellent
<ev> now to find out why this is happening :)
<ev> seb128: it's working now
 * ev adds a todo item to build out https://errors.ubuntu.com/status to cover some common API calls
<seb128> ev, indeed, works now, thanks a lot!
<ev> seb128: sure thing. Sorry it happened in the first place :)
<captainlinux> Let's say I have Ubuntu installed on my hdd. If I shrink the size of my hdd, create a new partition and install, for example windows 7. Will it mess up grub on that hdd?
<mlankhorst> well if we need to rebuild libdrm anyway, might as well do a new upload
<leex_> Hi, my ubuntu keeps on crashing and this is the relevant part of the syslog http://pastebin.com/CYFp5DKH When reporting this bug, what kind of information should I also include?
<mlankhorst> specifically what crashes..
<cjwatson> leex_: https://wiki.ubuntu.com/DebuggingSoundProblems I suspect
<mlankhorst> cjwatson: you don't know what crashes, could be that nouveau line :P
<melodie> hi
<cjwatson> mlankhorst: True
<leex_> mlankhorst: mplayer crashes, system freezes, can't access tty
<leex_> that's the short story
<leex_> I will paste the whole syslog if you want
<melodie> I am coming with a question related to lxpanel, in a Precise install, if anybody has an idea about this (I wonder if I should post a bug report). while trying to start htop from the lxpanel menus, in an install with mainly Openbox, and Sakura as terminal, I was suprised it would not start. It works fine when started in console. then looking in the ~/.xession-errors file I saw it was searching each time for lxterminal. I just looked at the pac
<melodie> kage page, and nowhere lxterminal is mentioned as a dependency. and I thought lxde components could be used alone and not depend on other main components... http://packages.ubuntu.com/precise/lxpanel
<leex_> here is the whole syslog http://paste.ubuntu.com/5613463/
<leex_> so shall I just run ubuntu-bug -s audio?
<cjwatson> well, htop is a terminal-based program; it doesn't specifically depend on lxterminal, but it needs to be run in *a* terminal.  it's probably just missing some bit of metadata in its menu file to tell the menu system to run it in a terminal
<cjwatson> (I don't know exactly what but maybe this gives you a place to start)
<cjwatson> ah, you say "it" was searching for lxterminal.  You might like to find out what "it" is; I bet it's not htop
<ogra_> the .desktop file defines Terminal+yes
<ogra_> err
<ogra_> Terminal=yes
<cjwatson> perhaps the panel needs a terminal installed in order to be able to start launch-in-terminal applications
<cjwatson> which would seem likely :)
<ogra_> though i would expect it to use the default one from the alternative
<ogra_> does Sakura perhaps not use that ?
<ogra_> or set it ...
<cjohnston> does anyone know why the celt codec isn't avaiable in raring?
<mitya57> xnox: what is dh_links? or is that a typo? https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/python-pip/raring/revision/14/debian/rules
<xnox> mitya57: probably a typo..
<melodie> cjwatson I have done several tests with the htop.desktop file, and I can assure you I don't see the problem elsewhere than in lxpanel : when I start htop from the menus in the openbox applications menu, it starts in the console which is installed.
<xnox> mitya57: s/links/link/
<xnox> *sigh*
<mitya57> xnox: will you fix that yourself or should I file a MP?
<melodie> and the pipe menu which provides the applications right-click menu uses libmenu-cache as lxpanel does
<melodie> so ?
<xnox> mitya57: if you have time, please file a MP, i'll bzr bd & upload it.
<mitya57> xnox: ok, will do now. I also think that /usr/bin/pip3 is a nice thing to have in Debian too.
<melodie> cjwatson i tried to replace "Exec=htop" in the desktop file with :
<mlankhorst> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<melodie> x-terminal-emulator htop
<melodie> x-terminal-emulator -e htop
<melodie> x-terminal-emulator -x htop
<mlankhorst> -ENOTTY
<melodie> and each time in the .xession-errors file I could see:
<melodie> "lxterminal "x-terminal-emulator htop" : lxterminal is not installed
<melodie> and same for the other commands
<melodie> this is how I saw lxterminal was sought for
<melodie> cjwatson does that seem a fair test to you ?
<cjwatson> I don't know, sorry
<melodie> I even tried "Exec=sakura -e 'htop'" and the .xession-errors file returned "lxterminal sakura 'htop'" : lxterminal not installed; :)
<melodie> cjwatson thank you.
<cjwatson> I was just making a passing comment in the hope that it might help; I can't help further
<melodie> I'll ask the person who uploaded the package
<melodie> cjwatson you have helped me : you suggested what I did, and I was hoping to see more but there isn't. :)
<melodie> thank you very much.
<melodie> I will have other questions next, but not all at one time... :)
<mardy> seb128: hi! Raring will not get GNOME 3.8, will it?
<xnox> mardy: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-gnome-plans-review
<xnox> mardy: no, we are sticking with 3.6 and pulling patches and or individual apps as we see fit.
<mardy> xnox: I'd like to see if we can make an exception for some other components; should I start by proposing the change in the blueprint's whiteboard?
<mardy> xnox: FYI, EDS/Evolution (the developer claims he has been developing them on top of GNOME 3.6
<xnox> mardy: we are past feature freeze.
<xnox> mardy: you'd want FFe now.
<xnox> mardy: Thunderbird is our default mail app, why would we want new Evolution?
<mardy> xnox: Online Accounts integration
<xnox> mardy: don't edit whiteboard (that was relevant during raring development up to feature freeze), open FFe bug instead.
<xnox> mardy: well, _which_ online accounts? ubuntu or gnome?
<mardy> xnox: Ubuntu :-)
<mardy> xnox: thanks. Well, first I'll try and see if it's really true that I can build it on raring :-)
<seb128> mardy, hey, yeah we stay on GNOME 3.8
<seb128> mardy, is there some abi changes in e-d-s/soname updates?
<seb128> mardy, does the new evo require gtk 3.8 (we didn't go for it)
<seb128> mardy, in any case it seems like that can wait a month and land after raring...
<mardy> seb128: I'm trying right now to build it on raring, I'll let you know
<seb128> mardy, ok, thanks
<seb128> mardy, did they include uoa support in 3.8? or do they just have work in progress on top of that version?
<mardy> seb128: yes, that's why I'm interested in it
<mardy> seb128: it's in master :-)
<seb128> ok, cool
<mterry> ScottK, hello!  I don't quite understand your question in bug 1155157, could you explain?
<ubottu> bug 1155157 in unity-greeter (Ubuntu Raring) "[FFe] Allow custom indicators" [Undecided,New] https://launchpad.net/bugs/1155157
<ScottK> mterry: I recall some discussion the other day on IRC about session buses needing to be manually enabled.  It may have been irrelevant, but my question was are we already using a greeter session bus by default or does the greeter normally use the system bus?
<mterry> ScottK, the greeter has a session bus already.  I know because it spawns some things that have used it.  But it's never exposed an interface on the bus before.  That's new
<mterry> (things like indicators use it)
<hallyn> smb: hi - kvm module autoloading is causing me a new problem.
<hallyn> what exactly causes it to get loaded?
<smb> hallyn, there is now cpu aliases for the modules
<smb> alias:          x86cpu:vendor:*:family:*:model:*:feature:*0085*
<smb> for example
<hallyn> smb: the problem is that is getting done before qemu-kvm.conf runs.  qemu-kvm.conf optionally loads kvm_intel with thenested=1 parameter
<hallyn> so that isn't getting done
<hallyn> now it's rnning on 'runlevel [2345]', i guess i can move it much earlier than that, but when are the modules being autoloaded?  presumably very very early?
<hallyn> i suppose i can just 'rmmod kvm_intel' always before modprobing it
<hallyn> smb: can i ask what the advantage is of always loading that?
<smb> hallyn, I would suspect that happens with some udev rule. (maybe on --trigger). That could work... I guess creating its own /etc/modprobe.d/ rule was bad for some reason
<smb> hallyn, Suspect its a simplification so you cannot forget... But I would not know the real reason
<hallyn> h, but always rmmod'ing kvm is bad as libvirt may be racing with us, vms already running
<smb> hallyn, yeah probably not the best variant... need to look, is the upstart file doing much more than loading?
<smb> hallyn, Hm, other option, not sure, but maybe it can be changed in /sys/modules...?
<hallyn> smb: bug 1155177
<ubottu> bug 1155177 in qemu (Ubuntu) "nested=1 not taking effect" [High,Confirmed] https://launchpad.net/bugs/1155177
<hallyn> oh, you think it can be done at runtime?
<hallyn> smb: at this point i'm not sure anyone would wnat/need to run without nesting support
<hallyn> so perhaps it's ok to just always turn it on
<hallyn> (with the qemu package, per the bug)
<hallyn> but yes, lemme try andn set it through sysfs
<smb> hallyn, I thought nested=1 also is the modules default...
<hallyn> if it is then it's not working
<hallyn> oh, no, not the kernel module's default
<hallyn> smb: nope, can't change it through sysfs
<hallyn> so what is the dh_* way to install a modprobe.d file?
<smb> hallyn, dh_installmodules (package.modprobe)?
<hallyn> oh, this is a regression.
<hallyn> quantal had that file
<hallyn> smb: but just having package.modprobe is sufficient right?
<hallyn> i don't even need that line then?
<smb> hallyn, you are asking the blind (or the deaf) :)
<hallyn> smb: will test - thanks :)
<smb> Just looked it up but maybe the file only is sufficient
<smb> hallyn, And yeah, seems all the options of the module are unchangable without rmmod/modprobe...
<hallyn> smb: so...  should i assume that thos modules are always loaded,
<hallyn> and remove the modprobe from qemu-kvm upstart altogether?
<smb> hallyn, Right and also now the right ones
<hallyn> are there any cases where that won't happen?
<smb> based on SVN or VMX
<jodh> ev/cjwatson: can you offer any advice on how a python script can dynamically determine the full path to its installed icon file?
<hallyn> smb: cool so only ksm setting will be left.   that and vhost_net
<smb> hallyn, Yes, if a cpu does not support the feature or like in the case of dom0 if someone hides it
<cjwatson> how do you mean, icon file?
<jodh> cjwatson: well, and svg or png file that will be displayed in help->about actually.
<cjwatson> any reason that needs to be dynamic?
<cjwatson> I'd probably just hardcode a path, maybe substitute it in at build time if I were feeling keen
<cjwatson> at least if it was just a script rather than a module
<jodh> cjwatson: I'm using gtk set_icon_from_file(), but the .py isn't going to know where the image file is once it's installed.
<jodh> cjwatson: yeah, this is just a single script - it's currently looking in cwd but that won't work when I install it
<cjwatson> so you're trying to make it depend on autoconf --prefix or similar/
<cjwatson> ?
<jodh> cjwatson: something like that. I wondered about creating file.py.in or similar (not: there is no setup.py atm).
<jodh> cjwatson: s/not:/note:/
<hallyn> smb: testing http://paste.ubuntu.com/5613875/ fwiw
<cjwatson> jodh: that's what I'd do
<cjwatson> and have it test each of installed-path and cwd in some order to see if they exist
<cjwatson> or give it a path override option
<cjwatson> (probably overkill for an icon)
<smb> hallyn, minus the debian packaging magic I am never sure of, that would look good to me
<jodh> cjwatson: ok thanks. I'd wondered if it was possible to query a desktop file and it is using python-xdg. Only problem is finding the path to your .desktop file .... :)
<cjwatson> well exactly, same problem
<jodh> cjwatson: right :)
<cjwatson> I suppose you could try to divine your prefix from __file__ or whatever it is
<cjwatson> Not convinced that would be more robust
<xnox> jodh: if you drop icon into correct location for desktop icons, the gtk_icon thing has a function to give you theme icon for "upstart"
<xnox> jodh: thus you don't need full path in the first place.
<xnox> jodh: see xdg icon spec for reference
<xnox> https://developer.gnome.org/gtk3/3.4/GtkImage.html#gtk-image-get-icon-name
<xnox> jodh: then drop the svg into /usr/share/icons/hicolor/scalable/apps/upstart.svg
<cjwatson> ah, yeah, that might be better if you can manage it
<xnox> run magic stuff to update icon caches.
<xnox> (i usually reinstall one of the packages which already has icons there)
<hallyn> how do i add ttyS0 to the list of things triggering ckit?
<xnox> and use it =)
<hallyn> stgraber: ^ ?
<jodh> xnox: thanks!
<xnox> np
<xnox> I use glade, so i just set icon name there.
<stgraber> hallyn: I don't remember ckit needing any kind of device whitelist. It's typically hooked into pam.
<cjwatson> xnox: dh_icons, but you shouldn't need to do that if installing under /usr/share/icons/hicolor/ since hicolor-icon-theme has a trigger
<cjwatson> Though it wouldn't hurt
<cjwatson> dh should do it for you though
<xnox> cjwatson: i mean when i'm locally just dropping/updating icons there for testing & artistic impression =)
 * xnox notes down to see what hicolor-icon-theme trigger executes.
<cjwatson> right.  update-icon-caches isn't much typing :)
<cjwatson> (hicolor-icon-theme.postinst does it an older but basically equivalent way)
<cjwatson> well, update-icon-caches only handles gtk3
<mterry> pitti, the tests in systemd are disabled because "some tests fail under fakeroot".  Do you happen to know how many we're talking about?  (like, are we skipping 200 tests because 2 fail or because 198 fail?)
<mterry> Not that systemd has 200 tests, that was just an example number
<pitti> mterry: it's got quite a number of tests, but very few of them (only the unit tests) are actually shipped in the package
<pitti> mterry: the integration tests (which build and run VMs) are only in git; I want to talk to upstream to ship them as well, so that we can run them in autopkgtest, etc.
<mterry> pitti, yeah, you mentioned that in the MIR
<pitti> mterry: building, I'll tell you in a bit
<mterry> But it would be neat to run the unit tests too
<pitti> yes, absolutely
<cjwatson> xnox: Hm, do you also have multiarching in progress for tk8.5?
<pitti> mterry: from upstream git I get 6/26 failures, apparently it's making some assumptions about the environment which aren't true on Ubuntu
<xnox> cjwatson: needs to take the patch from 8.4 and apply on top of 8.5, do you need it urgently?
<cjwatson> xnox: Because I'm having trouble getting ruby1.8 to build again when tclConfig.sh and tkConfig.sh are in different directories
<cjwatson> xnox: And the relevant bit of its build system is, well, in ruby, and it's hurting my brain to unpack
<mterry> pitti, hrm.  Is it easy to selectively disable them?
<xnox> cjwatson: hmm... well the _default_ tclConfig.h has not moved, but the 8.4 & 8.5 did move.
<pitti> mterry: yes, it's individual programs
<cjwatson> xnox: err, I beg to differ
<pitti> mterry: but probably it's better to fix them
<cjwatson> $ dpkg -L tcl-dev | grep tclConfig
<cjwatson> /usr/lib/i386-linux-gnu/tclConfig.sh
<pitti> mterry: but I had so much stuff at my hands with that tradition that I didn't get to that yet
<mterry> pitti, yeah
<cjwatson> xnox: And that's necessary AFAICS so that tcl-dev can be M-A: same
<xnox> cjwatson: true, cuase it had too, otherwise tcl-dev would not be m-a:same. *sigh*
<xnox> =)
<xnox> cjwatson: i totally miss-read your question.
<xnox> cjwatson: No, i do not have any progress on tk multiarchification.
<cjwatson> Ah
<cjwatson> OK, maybe I need to do that then
<cjwatson> +1 maintenance -> yak shaving
<cjwatson> I was two levels down from the original problem already :)
<xnox> cjwatson: but if you use tcl8.6 and tk8.6 neither are multi-archified and ruby will build =) i guess you want to continue building ruby against the default tcltk stack....
<cjwatson> That doesn't seem like an unalloyed step forward, really
<cjwatson> And indeed I don't want to get into serious ruby maintenance, I just want to get it building again
<cjwatson> I suspect it's not the only build system that assumes that tclConfig.sh and tkConfig.sh are in the same directory, so I think it'd be best to fix this regardless
<xnox> cjwatson: we can ship "/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh" which will call dpkg-architecture & exec the real Config script from /lib/$(DEB_MULTIARCH/
<xnox> cjwatson: we can ship "/usr/lib/tclConfig.sh and /usr/lib/tkConfig.sh" which will call dpkg-architecture & exec the real Config script from /usr/lib/$(DEB_MULTIARCH/
<pitti> mterry: so the tests seem to run fine on Debian (says mbiebl) without fakeroot, so I'll investigate this
<mterry> pitti, thanks!  it makes me nervous to have 0% coverage  :)
<pitti> mterry: heh, same here :)
<xnox> as long as it has same contents on all arches =)
<cjwatson> xnox: Which is going to involve multiarching tk anyway, and I already have the ruby fix to honour DEB_HOST_MULTIARCH ... I'm not sure it makes sense to try to avoid this work
<cjwatson> Tk should be multiarched for basically the same reasons Tcl was
<cjwatson> So I'll start in on that now, I think
<xnox> cjwatson: well, tkConfig.sh can stay as it is for now. Just ship the "compat" /usr/lib/tclConfig.sh.
<xnox> cjwatson: or that =)
 * xnox did not have fun with getting tcltk-defaults to do the right thing though.
<pitti> mterry: ah, could actually be that it assumes that it's running under systemd
<cjwatson> Anyway I don't really like such compat hacks when not absolutely necessary - they have a habit of complicating an area of packaging that not enough people understand as it is
<xnox> unbroke python =)
<pitti> mterry: ok, got it (assumes having /etc/machine-id)
<pitti> mterry: https://bugs.freedesktop.org/show_bug.cgi?id=62344
<ubottu> Freedesktop bug 62344 in general "tests depend on /etc/machine-id" [Minor,New]
<mterry> pitti, awesome.  if it's not easy to retro-fit machine-id-agnosticism, would you mind enabling the other tests at least until upstream fixes that?
<pitti> mterry: I rather do the former, investigating (but won't finish today, need to leave in 10 mins)
<pitti> All 26 tests passed
<pitti> now, here we go
<mterry> pitti, leave :)
<mterry> (but awesome!)
<jtaylor> will eglibc commit cbc105f8b590f (aarch64: use lib64 as default lib and slib directory) be a problem for use at some point?
<infinity> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: infinity
<infinity> jtaylor: Ugh.  As long as no one also moved the linker.  Let me look.
<infinity> jtaylor: Nope, that *should* be fine.  So far, no one's relocated the linker.  Default libdir and slibdir can be overridden anyway, and we will.
<infinity> jtaylor: doko was involved in a long thread with gcc upstream about all of this, here's hoping no one does anything stupid.
 * infinity goes to future-proof the packaging by preseeding libdir and slibdir so he doesn't get a nasty surprise when he rolls 2.18
<doko> ?
<infinity> doko: Andreas Schwab committed a libdir/slibdir change from lib to lib64 to glibc upstream.  Relates that thread you were involved in last week.
<infinity> doko: (For AArch64)
<infinity> doko: Anyhow, doesn't look like he moved the linker, just the libdirs, so doesn't really affect us.  I just need to change it back to lib for us.
<doko> doesn't affect multiarch
<infinity> Right.
<infinity> Oh, indeed, might not affect as at all, as we install everything (except linkers) to multiarch paths anyway and completely ignore libdir and slibdir.
<infinity> Except for biarch packages.
<infinity> s/affect as/affect us/
<hallyn> so, up through quantal we had /etc/default/qemu-kvm to store some settings, and /etc/init/qemu-kvm.conf to do stuff with them.  it had been claimed the default file should be dropped bc it slows things down.  but that causes trouble when ppl make changes and the iniwupstart script changes.
<hallyn> woudl anyone object if i switch back to /etc/default/qemu-kvm?
<hallyn> all right i'll put that off fornow
<didrocks> infinity: hey, do you know who (or you?) should I ask for some regular ppa scoring (we have a feature ppa when we need a higher score for daily build to have amd64 packages built timely)?
<cjwatson> didrocks: webops
<infinity> didrocks: A one-time scoring of some time-sensitive builds, or a rescoring of the PPA itself?
<didrocks> thanks cjwatson
<cjwatson> https://wiki.canonical.com/Launchpad/PolicyandProcess/PPAPriorityPolicy
<didrocks> infinity: rescoring of the ppa
<infinity> didrocks: As Colin says, webops if it's the latter.
 * didrocks reads
<didrocks> thanks infinity, cjwatson
<stgraber> infinity: we can actually rescore a whole PPA ourselves
<stgraber> infinity: (through API)
<cjwatson> stgraber: we can, but the policy is there to protect us from world+dog asking us to
<cjwatson> stgraber: after a problem of that kind
<cjwatson> (well, in part; it's also useful justification and makes sure that there's a central group tracking what's been scored up, at least in theory)
<stgraber> cjwatson: hmm, yeah, I guess it makes sense for webops to handle all PPA tweaking so they can keep a log of what's going on
<cjwatson> especially if it all goes through RT tickets as requested in that doc
<mterry> bryce, I have an Xorg apport crash file from a jenkins autopilot run that seems to be inspectable.  Do you mind giving it a look see?   http://mterry.name/_usr_bin_Xorg.0.crash
<infinity> kirkland: Can't.  Stop.  Laughing.
<kirkland> infinity: it's good stuff :-)
<bkerensa> =o
<hallyn> jamespage: think i figured out the kvm problem you're having.  it's hillarious really.  i need to create group kvm in preinst not postinst.
<bdmurray> mterry: did you see my ping about bug 1056545?
<ubottu> bug 1056545 in sessioninstaller (Ubuntu Quantal) "session-installer crashed with AlreadyCalledDeferred in callback()" [High,Triaged] https://launchpad.net/bugs/1056545
<mterry> bdmurray, yes, commented in bug, have filed a merge upstream
<bdmurray> mterry: oh, maybe I should have refreshed or subscribed ;-)
<mterry> :)
<slangasek> xnox: hi, perhaps it would be more useful to talk through the file bridge stuff here rather than having our mails cross in the mp :)
<xnox> slangasek: maybe =)
<xnox> slangasek: what were your thoughts?
 * xnox thinks jodh might be end of day by now.
<xnox> slangasek: how come inotifywait -r -m /foo/ handles it fine then?
<slangasek> xnox: well, per my last mail, the stuff you're doing is out of scope for what I believe the desktop team needs
<slangasek> xnox: I don't know anything about inotifywait, but I talked about this with jodh and he made it clear that the corner cases are a giant rathole
<slangasek> one which we don't need to stick our heads into
<xnox> slangasek: well, let me re-read the code, as it looks like if the directory does not exist a watch on one above is established and later moved further down, such that this should be supported.
<xnox> slangasek: I'm just thinking about for example a first login of a brand new account will recursively create many directories. Maybe some of the common onces should be moved into skeleton? Like ~/.cache ~/.config ~/.local at least.
<slangasek> xnox: well, I know that jodh was trying to tackle the "watch parent dir, then move the watch when the next level is created" problem, but I believe the work was incomplete and I explicitly asked him not to block on completing it because I didn't believe it's needed
<xnox> ok.
<slangasek> xnox: the first-login case is an interesting point; I was actually just wondering to myself if we have the same problem on package install
<slangasek> i.e., if dpkg unpacks /var/lib/service/foo and /etc/init/foo-monitor.conf out of order, does the file bridge get wedged?
<xnox> and watching for /var/lib/service/foo/* or foo itself? =)
<slangasek> xnox: sorry, I haven't actually looked at the branch yet so am not sure what the semantic difference between those two is :)  Would watching for "foo" mean watching for its creation?
<slangasek>  /var/lib/service/foo/* seems to be what we want
<slangasek> but I'm not sure what watching '/var/lib/service/foo' would mean, if it already exists and is a directory
<xnox> it seems like one can either for for files or directories. I didn't actually check how the distinction is made though.
<xnox> slangasek: when is runlevel 2 emitted? before or after certain mountall events?
<slangasek> xnox: runlevel 2 is emitted only after the 'filesystem' event
<slangasek> which doesn't actually mean all filesystems are mounted
<slangasek> ;)
<slangasek> however, /var, /usr should be fully mounted
<xnox> cause if the fs is not mounted yet, but upstart-file-bridge has already started we will like miss everything.....
<xnox> slangasek: /home ?
<slangasek> xnox: /home is not guaranteed
<slangasek> well, /home itself may be but subdirs are not
<xnox> oh we don't care about /home actually, since user-jobs and user-upstart and user-file-bridge is not running yet.
 * slangasek nods
<slangasek> xnox: also, users who *need* mountall to wait can override any fstab entry by adding 'bootwait'
<slangasek> ah, but I see the job jodh added has 'start on startup', which is obviously too early
<slangasek> ... unless we fix the recursive watch problem
<slangasek> so, it's arguable that yes, we should fix it so we can add a watch that follows down the tree as parent dirs are created
<slangasek> but if you add, delete, add, I think we don't care about supporting that
<slangasek> xnox: so I conclude that I agree with your use case in https://code.launchpad.net/~jamesodhunt/upstart/file-bridge-MP/+merge/152767/comments/333812 needing to be supported, but not your third example from https://code.launchpad.net/~jamesodhunt/upstart/file-bridge-MP/+merge/152767/comments/333827
<slangasek> xnox: could you summarize this onto the mp?
<xnox> slangasek: ack.
 * xnox does one more test here locally.
<bdmurray> tjaalton: does bug 1104954 need fixing in quantal too?
<ubottu> bug 1104954 in freeipa (Ubuntu Precise) "CVE-2012-5484: ipa-client security vunerability" [Medium,In progress] https://launchpad.net/bugs/1104954
<tjaalton> bdmurray: hmmh, yeah. and it needs a refresh anyway, you can drop it from the queue
<bdmurray> tjaalton: done
<tjaalton> thanks
<jamespage> hallyn: great news!
<tkamppeter> RAOF, hi
<hallyn> jamespage: if you're still around and a bit bored or eager to see the qemu fix in archive, woudl you mind reviewing http://paste.ubuntu.com/5614794/ ?
<slangasek> xnox: do you know anything about glusterfs?
<xnox> slangasek: some. Why?
<slangasek> xnox: bug #1103047
<ubottu> bug 1103047 in mountall (Ubuntu) "mountall causes automatic mounting of gluster shares to fail" [Low,Incomplete] https://launchpad.net/bugs/1103047
<slangasek> xnox: I don't know anything about it, and so far none of the people hitting it have given me the debug info I need
<xnox> slangasek: even like jamespage ? =)
<slangasek> jamespage apparently doesn't use it, since everyone assures me mountall can't mount glusterfs correctly ;)
 * jamespage bemused
<slangasek> jamespage: so I guess you use it and haven't seen this bug, eh? :)
<jamespage> slangasek, nope - never used gluster
<slangasek> ah
<slangasek> xnox: so, right - if you happen to be able to set up a test for this easily and reproduce the bug I'd appreciate the help, but if it's not easy for you don't worry about it
<xnox> slangasek: should be easy =) but I will schedule once I have proper resources (my new machine which doesn't boot with older generation CPU either)
<slangasek> xnox: ok... :)
<infinity> slangasek: I imagine gluster should be added to is_remote, but it does seem odd that _netdev doesn't work around it.
<slangasek> yep
<infinity> Though, mountall makes no attempt to filter _netdev out.
<infinity> So, if mount.filesystem hates the option, that would be problematic.
<roaksoax> slangasek: howdy!! so I uploaded maas-provision (to precise-proposed) and maas (to both precise|quantal-proposed), and I'd like you to review and accept for SRU verification when you have the time. Thanks!
<slangasek> roaksoax: ok - I can look at both tomorrow
<slangasek> infinity: mountall doesn't, but 'mount' should IIRC
<roaksoax> slangasek: awesome thank you!
<xnox> slangasek: surely for the node itself glouster mount is "local"
<xnox> and we don't want to break the glouster mounts themself.....
<dobey> infinity: care to review https://code.launchpad.net/~dobey/ubuntu/raring/twisted/lp1098127/+merge/153470 and get it uploaded? :)
<infinity> dobey: For cupcakes.
<dobey> i'm sure that could possibly be arranged
<stgraber> smoser: isc-dhcp uploaded. I'm not thrilled about the idea of supporting an extra dhcpd.conf option but I can't really think of another way to deal with that bug...
<infinity> dobey: Really?  Sold.  I will review after my next call and get it uploaded (or provide painful feedback, whichever).
<dobey> cool, thanks
#ubuntu-devel 2013-03-15
 * doko curses xnox for multiarching tcl/tk
<doko> xnox, any any reason for not doing tcl & tk at the same time?
<xnox> doko: multi-arch?
 * xnox was sponsoring a patch for tcl, and I accepted the work to make tcltk match for tcl m-a upload.
<xnox> (defaults that is)
<xnox> cjwatson now said he is ok to finish tk m-a for +1.
<doko> xnox, yes m-a
<doko> ok. will need another change for hfsutils
<xnox> doko: hfsutils sounds like a package I should be maintaining =)
<doko> ?
<xnox> file systems =))))
<xnox> although I don't have macs any more.
<mathomastech2> Trying to deploy an app to Ubuntu Touch on my Nexus 7. It's prompting for a password but not accepting the default "phablet" Anyone else run into this?
<xnox> mathomastech2:  see #ubuntu-touch people there should know.
<mathomastech2> xnox: Thanks, I am actually cross posting from there. Not having much luck yet.
<slangasek> xnox: I don't understand what "for the node itself" means here.  Do you mean that the server mounts the filesystem the same way as the clients?
<xnox> slangasek: maybe, my memory is fuzzy.
<xnox> slangasek: I'll get back to you about that.
<slangasek> ok :)
<xnox> mathomastech2: i'm sorry to hear that. Last resort try the ubuntu-phone mailing list. https://launchpad.net/~ubuntu-phone
<xnox> slangasek: new guile-pg uploaded "closing" the guile-1.6 RM task.
<slangasek> xnox: cheers :)
<infinity> Who demoted tcl/tk8.4 to universe?
<micahg> infinity: doko was working with that stuff earlier...
 * StevenK grumbles at SourcePackagePublishingHistory:+publishinghistory
<infinity> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<doko> who promoted tck/tk8.4? demoting again ...
<StevenK> infinity: [15:41] < doko> who promoted tck/tk8.4? demoting again ...
<micahg> doko: it registered on c-m
<doko> I assume I know who did promote it again. there is no reason to promote it for a work in progress, not even for infinity
<micahg> doko: why not just fix what would pop up on c-m before demoting?
<doko> micahg, did *you* see this?
<micahg> I saw it register on c-m...
<micahg> ah, you fixed it, so that should be that then :)
<doko> so you did look up bug reports for tcl8.4, or tk8.4, or blt?
<micahg> I didn't do the demotion/promotion
<micahg> doko: honestly, I figured infinity would chat with you before playing override pong
 * micahg enjoys removing old cruft as much as the next person
 * micahg would love to rm vala-0.14 for raring...
<infinity> doko: Typically, we remove the rdeps, then demote things when c-m whines, specifically to avoid pong.  Having to trawl bug reports to figure this out doesn't scale.
<infinity> doko: (I did look at blt, and there had been no uploads changing build-deps at the time)
<pitti> Good morning
<dholbach> good morning
<pitti> Laney: can you please remove the systemd and udev blocks?
<Laney> hello
<Laney> pitti: sure, if you're sure ;-)
<pitti> Laney: the initramfs-tools bug has been fixed, and otherwise the libudev1 transition is done
<pitti> Laney: so with unblocking we merely get libudev1, logind etc. is still kept in universe
 * Laney nods
<pitti> (as with the current raring package)
<Laney> ok, done
<pitti> Laney: thanks; that should flush quite a bit from excuses
<Laney> hmm, udev didn't go
<pitti> Laney: "go"?
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> oh, I was looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and that says "udev valid candidate"
<pitti> skipped: udev (1 <- 466)
<pitti>     got: 278+0: i-278
<pitti>     * i386: bluedevil, blue...
<pitti> I can't parse that, can you?
<seb128> can't either
<Laney> it thinks that those things are made uninstallable
<seb128> it's a long list
<pitti> perhaps it'll catch it in the next iteration when all the libudev1 stuff is i?
<pitti> s/i/in/
<Laney> I guess the last try is more interesting
<Laney> there are a few trying: udev there
<Laney> chromium might need force hinting due to the armhf ftbfs
<pitti> the previous upload FTBFSed too, was that also manually pushed?
<Laney> think so
<Laney> yes, it was forced
<cjwatson> pitti: parse> if you scroll way to the right you'll see that it thinks udev itself is uninstallable
<cjwatson> pitti: the very long line is just an expression of the fact that udev has lots of reverse-deps
<cjwatson> pitti: note that this means that it thinks (current raring) + (all binaries from udev in raring-proposed) results in uninstallable udev - so it's possible it needs manual hinting together with something else in -proposed
<pitti> hm, udev just dropped the libudev0 dependency and binary
<cjwatson> Which seems likely given that udev is installable in raring-proposed
<pitti> yeah, I dist-upgraded to raring-proposed just fine, I have 175-0ubuntu21 installed
<cjwatson> Bet you'll find that if you take raring and then try to upgrade to just udev/raring-proposed, it adds something else
<Laney> A lot of the ones it's complaining about seem to come down to xorg-server AFAICT
<pitti> libudev1, yes
<pitti> for the initramfs-tools dependency
<cjwatson> Laney: I don't think it's worth looking at anything else when udev itself is listed
<cjwatson> (It might be worth making update_output sort the binaries from the source itself to the start)
<Laney> I was trying to ascertain what to hint together
<cjwatson> Hm, wait, it's not listed in the final entry for udev
<Laney> right
<Laney> that's the one I'm looking at
<cjwatson> pyudev needs to be fixed
<cjwatson> And yeah, in general anything with Depends: libudev0 needs to be fixed
<cjwatson> proposed-migration normally computes installability based on all-NBS-removed
<pitti> oh, hardcoded libudev0 dep, fixing
<cjwatson> So, certainly worth trying 'hint udev/175-0ubuntu21 xorg-server/2:1.13.3-0ubuntu2' - if nothing else you'll get more useful output that way
<Laney> well: skipped: xorg-server (1 <- 498) got: 96+0: i-96 * i386: xserver-xorg-core-udeb, xserver-xorg-input-evdev-udeb, xserver-xorg-video-fbdev-udeb
<cjwatson> And you can see a reflection of that in update_excuses
<pitti> pyudev uploaded
<cjwatson> xserver-xorg-core-udeb/i386 unsatisfiable Depends: udev-gtk-udeb
<Laney> right
<cjwatson> Ah, you'll need  xserver-xorg-input-evdev/1:2.7.3-0ubuntu2b1 xserver-xorg-video-ati/:7.1.0-0ubuntu1b1 xserver-xorg-video-intel/2:2.21.4-0ubuntu1b1 xserver-xorg-video-modesetting/0.6.0-0ubuntu1b1 xserver-xorg-video-nouveau/1:1.0.6-0ubuntu3b1  too
<cjwatson> And more - anything that mentions "Depends: ... systemd' in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<cjwatson> Which implies that this is blocked on chromium-browser/armhf
<Laney> not sure about that - at least nouvaeu went in the last run
<cjwatson> Ah, OK
<cjwatson> Try it a bit at a time and wait for another cycle, I guess
<Laney> I'll just try it with xorg-server
<Laney> it will come down to chromium but as that's a force we should wait until we're certain
<cjwatson> aye
<pitti> I'm not sure about udev-gtk-udeb
<pitti> our udev source package didn't build that, and I didn't drop it
<pitti> systemd builds it now, but I disabled it
<cjwatson> It's built by Debian
<pitti> (because we keep the standalone udeb for now)
<pitti> err, udeV
<cjwatson> Either start building it, or remove the dependencies
<cjwatson> I don't really mind which :)
<pitti> I mean, how did that work before?
<pitti> i. e. how did we get anything depending on udev-gtk-udeb into raring when that package didn't exist?
<cjwatson> Let me look
<cjwatson> The previous version of at least xserver-xorg-core-udeb doesn't depend on udev-gtk-udeb
<cjwatson> It's a new dependency
<pitti> oh, perhaps it was synced, and this was added independently from my libudev transition
<pitti> hm, no
<cjwatson> Well, it's 2:1.13.2-0ubuntu3 to 2:1.13.3-0ubuntu2 - I assume there was a packaging sync in there even if not a verbatim sync
<Laney> yikes
<Laney> why did alt+left/right just start switching me between ttys?
<cjwatson> And yet xserver-xorg-input-evdev-udeb gained it with just a rebuild
<cjwatson> pitti: I suspect udev's shlibs are wrong
<cjwatson> Or rather systemd's
 * cjwatson peers
<cjwatson> ubuntu-archive@lillypilly:/srv/archive.ubuntu.com/ubuntu/pool/main/s/systemd$ dpkg -I libudev1_198-0ubuntu2_i386.deb shlibs
<cjwatson> libudev 1 libudev1
<cjwatson> ^- smoking gun
<cjwatson> udeb: libudev 1 udev-gtk-udeb
<pitti> aah
<pitti> dh_makeshlibs -plibudev1 --add-udeb=udev-gtk-udeb
 * pitti drops
<cjwatson> Can't drop that entirely
<cjwatson> Still needs to have some --add-udeb value
<cjwatson> Hm, is it intentional that systemd doesn't build any udebs at all?
<pitti> libudev0-udeb ?
<pitti> cjwatson: right now yes, I disabled all of them because we want to stay on the separate udev for now
<cjwatson> Um, confused.  Isn't libudev0 meant to go away?
<pitti> yes, it is
<pitti> I guess we need to build a libudev1-udeb
<cjwatson> I guess I don't see how libudev0-udeb can be a legitimate udeb substitution for libudev1 :)
<cjwatson> Sounds like it
<pitti> cjwatson: so having libudev1 only implies that we cannot continue to use libudev0-udeb and udev-udeb built from the udev source?
<pitti> I kept those for now
<pitti> I had assumed keeping libudev0-udeb would be okay, and we could do that as a separate transition
<cjwatson> I'm not sure about the new layout.  In general life will be simpler if you have debs and udebs in sync
<cjwatson> I think trying to avoid that is a false economy
<pitti> libudev1-udeb sounds harmless
<pitti> what I'd like to avoid is building udev-udeb from systemd
<cjwatson> Well, you don't build udev from systemd right now, do you?
<pitti> but just like the real udev, udev-udeb shouldn't depend on the library
<cjwatson> That's what I mean by in-sync
<cjwatson> And indeed it doesn't
<cjwatson> So it's just a matter of getting the linkage sorted for stuff that requires libudev1
<pitti> so, so I'll build a libudev1-udeb from systemd, drop libudev0-udeb from udev, and adjust the shlibs
<cjwatson> That sounds right to me
<pitti> ok, thanks
<pitti> sorry about the mess
<cjwatson> that's ok, catching this is what these tools are meant to do
<cjwatson> so this is a success :)
<pitti> actually, udev-gtk-udeb is supposed to be libudev1-udeb AFAICS, /me asks mbiebl
<seb128> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: seb128
<pitti> cjwatson: systemd with libudev1-udeb installed; so I'll let that build and publish, then rebuild the X.org bits again to pick up the fixed shlibs
<pitti> err, s/installed/uploaded/
<pitti> which would be xorg-server and xserver-xorg-input-evdev
<cjwatson> COol
<cjwatson> With sane capitalisation
<tjaalton> I can handle the xorg rebuilds
<pitti> meh, FTBFS due to enabled "make check"
<pitti> tjaalton: ok thanks, I'll ping you when it's ready?
<tjaalton> sure
<pitti> I guess the chroots don't have an /etc/hostname or so
<pitti> Laney: do you need to adjust your autohints for udev somehow? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt header looks a bit odd
<pitti> Laney: (I don't quite know yet how this works, I'm just curious)
<Laney> pitti: likely, since you uploaded it
<Laney> but it may be that it can figure it out itself now
<cjwatson> You'll need to bump the version
<pitti> but udev and systemd don't appear at all any more
<cjwatson> They won't, because they're out of sync at the excuses level
<cjwatson> Nothing shows up in output (global consistency checks) until it passes the excuses stage (package-by-package checks)
<cjwatson> So don't worry about it, it'll sort itself in time
<pitti> ok, thanks
<infinity> systemd already migrated a couple of versions back anyway, unless it's changed again in a way that needs more hinting.
<Laney> it needs NEWing this time
<cjwatson> Yeah, I'm doing that now
<pitti> yeah, I'm waiting for the arm and ppc builds, and will prod an archive admin when they are ready
<cjwatson> No harm NEWing in advance of that
<cjwatson> (done)
<infinity> shadeslayer: Hey, is there an upstream bump of ktp-contact-applet on the way to match the rest of your uploads?
<infinity> shadeslayer: And ktp-presence-applet too.
<infinity> shadeslayer: Without those two, the rest can't migrate.
<tseliot> cjwatson: I'm afraid upstream won't accept my fix for bug #1073062 . The maintainer says we should patch initramfs-tools instead but I disagree. Shall we keep the patch in Ubuntu?
<ubottu> bug 1073062 in kmod (Debian) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Unknown,New] https://launchpad.net/bugs/1073062
<infinity> tseliot: Err, that has nothing to do with initramfs-tools.
<infinity> tseliot: Which upstream maintainer?  The Debian one, or upstream upstream?
 * infinity goes to look at the Debian bug, hoping for context.
 * cjwatson happily defers to infinity since he's looking
<tseliot> infinity: the Debian one
<tseliot> I thought he was upstream upstream...
<infinity> Lucas is upstream, not Debian, yes.
<infinity> Reading.
<infinity> tseliot: He is right about one thing.  Those aliases were only officially supported in modutils.  So, a decade ago.
<infinity> tseliot: I'm not sure if it was an accident or backward compat that they didn't break in m-i-t, but they weren't documented in m-i-t either.
<infinity> tseliot: I don't see him saying we should patch initramfs-tools instead, unless that's in a private email?
<tseliot> infinity: true but I believe it shouldn't error out like that
<tseliot> infinity: yes, I don't know why that email didn't make it: "Then you should fix the initram update software. I suggest you to try  the blacklist stuff instead of this off/null alias and if it doesn't  work to tell me."
<infinity> tseliot: Either way, breaking upgrades gratuitously seems like a bad idea, and initramfs-tools isn't the place for the fix.  If upstream doesn't want the patch (and that's fine), we should carry it locally, make it also spit out a warning to stderr, and make sure we don't ship anything that creates aliases like that.
<infinity> tseliot: And then, later, we can drop the patch (say, after 14.04).
<tseliot> infinity: ok, it sounds like a plan
<infinity> tseliot: Also, he's missing the point that this isn't about using different config options, it's about smooth upgrades for people who have the old config options.
<infinity> tseliot: You might want to point that out.
<infinity> tseliot: Yes, blacklisting might be the right thing, but we can't magically change people's systems.
<tseliot> infinity: I will, even though I doubt it will change anything
<infinity> tseliot: (And the reason blacklisting probably doesn't currently work with udev for us is that our udev doesn't use libkmod yet, his does)
<infinity> At least, doesn't work the way he thinks it should. :P
<infinity> Our udev just forks modprobe.
<infinity> Probably without -b ... Though that would seem like a bug too.
<infinity> If true.
<infinity> (Are you sure blacklists don't work with our udev?  They really should)
<tseliot> infinity: udev in raring uses libkmod but, apparently, the one in precise doesn't
<pitti> /etc/blacklist.d/ very much does work in raring
<tseliot> I've just found out
<infinity> tseliot: udev in raring doesn't use libkmod.
<pitti> I wish it did, but it doesn't, yes
<infinity> tseliot: Except via modprobe, of course.
<infinity> tseliot: But that's not the codepath he was pointing out.
<infinity> tseliot: And of course it doesn't in precise, we don't have kmod in precise.
<tseliot> infinity: I can see #include <libkmod.h> in src/udev/udev-builtin-kmod.c
<infinity> tseliot: Yes, but we don't build that bit.
<tseliot> oh
<pitti> tseliot: we still use the standalone old udev source
<infinity> ldd /sbin/udevd is pretty conclusive. :P
<tseliot> ok
<tseliot> but does "alias module off" work in our udev?
<pitti> but going back to blacklisting, that's supposed to always work, even with newer udevs
<pitti> oh, I don't know that for sure
<infinity> Anyhow, dumping core is a Bad Thing.  I can see where upstream is coming from too, that supporting config options that haven't been documented as valid for over a decade is probably a complete waste of time.
<infinity> tseliot: It's not up to udev for that to work, it just passes the mess to modprobe (in our case), so it'll fail the same as in initramfs-tools.
<infinity> tseliot: Which is why the fix (for us) belongs in kmod.  But I can see the argument for it not being upstreamable, and that's not world-ending.
<tseliot> infinity: agreed
<infinity> tseliot: I will probably amend your patch to be verbose, so people get some fair warning that they should update their configs.
<infinity> tseliot: And maybe it'll teach nvidia/fglrx people to Stop Doing That.
<tseliot> infinity: that's a leftover from precise (coming from bug #864149)
<ubottu> bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149
<tseliot> infinity: so I'll more than glad to stop doing that ;)
<tseliot> *I'll be
<infinity> tseliot: Yeah, so those should be blacklists, not aliases.  He's right.
<infinity> tseliot: And, ideally, fixed in the next round of precise SRUs you do, so the problem eventually goes away.
<infinity> tseliot: But we'll carry this patch until 14.04 to make sure upgrades don't go sideways.
<infinity> (And I'll do the verbosity change today)
<tseliot> infinity: why Precise? Wouldn't it reopen bug #864149 ?
<ubottu> bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149
<tseliot> I'll change it in Raring for sure
<infinity> tseliot: Erm, why would it reopen that bug?  I didn't read the whole thing...
<tseliot> infinity: Â https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/864149/comments/3
<ubottu> Launchpad bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released]
<infinity>  - set 'alias nouveau off' in the modprobe blacklist file, *not* 'blacklist nouveau'. (udev ignores module blacklisting by design!)
<infinity> Hrm.
<infinity> Now I see where you got that idea from.
<tseliot> yep
<infinity> That seems like it shouldn't be true.  But maybe it is.
<tseliot> I'm not willing to take that risk in Precise ;)
<infinity> You could also do the install foo /bin/true thing.  But this probably needs more investigation.
<infinity> tseliot: Hold off on changing things in raring too, I think we'll need to dig deeper into ACTUAL behaviours, instead of relying on conjecture.
<tseliot> infinity: fine by me. Are you going to deal with it? (I don't see any problems with the change in raring)
<infinity> Well, the change in raring may regress this too.  (I mean, changing nvidia/fglrx, the kmod change is fine).
<infinity> tseliot: I'll have to dig a big into how this all interacts, so I have decent warning text to throw to stderr to tell people how to fix their config files.
<infinity> tseliot: And once I've sorted that a bit, I'll also have a good idea of what things should look like in both precise and raring (if the former should change at all)
<tseliot> infinity: ok, good, I'll leave it in your hands then. Thanks
 * infinity shudders at the idea of turning on the nvidia GPU in his laptop again to test all of this.
<infinity> Bye, bye battery life. :)
<tseliot> :)
<seb128> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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> tjaalton: libudev1-udeb is published now, so we can rebuild xorg-server and -evdev
<pitti> tjaalton: do you have some actual changes, or want you or me to upload no-change rebuilds?
<tjaalton> pitti: hmm, not really, rebuilds are fine..
<infinity> cjwatson: *blink* at 1061909
<cjwatson> odd, isn't it
<infinity> cjwatson: Clearly a Chrome rendering bug, but.  Uhm.  Wha?
<cjwatson> web team have been trying to reproduce it
<infinity> cjwatson: I give 20-to-1 odds that if you move the "32-" to the middle of a line it goes away, but I don't have a machine I can reproduce on.
<cjwatson> if removing line breaks really fixes it, I'll (a) cry (b) sort it out with the Python rewrite
<cjwatson> since the reason the line breaks are there is that it makes the code neater in shell :)
<infinity> Well, you could just move the variable expansion up a line, or whatver.
<infinity> (Or whatever's generating that, I didn't look)
<infinity> If it's just a block text, same story.
<pitti> tjaalton: do you want to upload them (as you mentioned it earlier), or shall I do it now?
<cjwatson> it's cat <<EOF at the moment
<infinity> Maybe I can install Chrome on a Windows VM and reproduce.
<tjaalton> pitti: if you have them ready then go ahead .)
<tjaalton> :)
<infinity> cjwatson: Yup, reproduced on Windows.
<infinity> cjwatson: Gut feeling would be that it's seeing the "^32-" as a multibyte char.
<pitti> tjaalton: done
<cjwatson> infinity: ... wow?
<tjaalton> pitti: thanks
<cjwatson> er, "how"
<cjwatson> but "wow" works too
<cjwatson> I mean, in what encoding is that possibly multibyte?
<infinity> cjwatson: Effed if I know.  But let me move the line break to test the theory.
<infinity> cjwatson: http://lucifer.0c3.net/~adconrad/wtfchrome/
<infinity> cjwatson: Verified that 1.html renders wrong, 2.html renders fine.
<infinity> cjwatson: Could have something to do with the files being \n-only and Chrome on Windows perhaps behaving crappily without \r\n?  I dunno.  That's pretty far-fetched, given all the UNIX-generated content on the interwebs.
<infinity> cjwatson: Either way, not starting a line with 32- fixes it.
<shadeslayer> infinity: those sources have been dropped, I might have missed something, so I'll have a look tonight
<infinity> shadeslayer: If they've been dropped, we need to remove them.
<infinity> shadeslayer: Which I can do for you.  Is there a migration/upgrade path there?
<shadeslayer> infinity: ktp-desktop-applets now replaces those two packages
<shadeslayer> the upgrade path seems clean ( I tested it before uploading )
<infinity> shadeslayer: kde-telepathy-desktop-applets has a Breaks/Replaces for plasma-widget-telepathy-presence but not plasma-widget-telepathy-contac
<infinity> t
<infinity> shadeslayer: Also, is Breaks/Replaces really enough to remove the old package entirely?  You're sure that test worked? :)
<infinity> shadeslayer: Anyhow, once you've confirmed that both those sources can go away, let me know, and I'll remove them so the rest can migrate.
<shadeslayer> infinity: doesn't replace the contact widget because it doesn't overwrite files from that, and I always thought that autoremove will remove packages that nothing depended on ?
<infinity> shadeslayer: Oh, if there's no reason to forcefully remove it, sure, it'll just autoremove on its own iff it wasn't installed manually or a direct dep of a metapackage.
<shadeslayer> yeah, there's no reason to forcefully remove it :)
<infinity> Kay.
<infinity> I'll bounce them both out of the archive for you, then.
<shadeslayer> awesome thanks :)
<infinity> shadeslayer: Before I hit <enter>, this look right?: http://paste.ubuntu.com/5616555/
<mterry> bryce, I have an xorg stack trace I'd like you to look at if you have some time.  It's from a jenkins run
 * infinity takes shadeslayer's silence as a "yes, and I've found better things to do already."
<shadeslayer> no wait
 * shadeslayer is looking
<infinity> ...
<infinity> Too late. :P
<shadeslayer> hahaha
<infinity> ALL GONE.
<shadeslayer> I'm a bit distracted since we have a Kubuntu meeting starting in 2 minutes
<shadeslayer> lol :)
<shadeslayer> okay :)
<pitti> hey mterry
<mterry> pitti, hi!
<pitti> mterry: I bounced the systemd MIR back to you FYI, as I believe I addressed most of the concerns (except not having a py3 package; patches/help appreciated..)
<hallyn> jamespage: ok, just dput the new qemu (was waiting on debian-devel discussion).  *should* fix your issues when it's built.  phew
<mterry> pitti, sure, that's not as urgent
<jamespage> hallyn, great - thanks for letting me know
<shadeslayer> infinity: thanks, looks good to me
<hallyn> i'll have to sru those for sure
<cjwatson> infinity: All right, thanks.  I'll sort it out in a bit
<cjwatson> infinity: Can you try collapsing the whole paragraph onto one line and make sure that works too?
<infinity> cjwatson: It should, but sure.
<cjwatson> (Which should be obviously true, but the whole thing is non-obvious.)
<infinity> cjwatson: All one line works too.
<cjwatson> Good, thanks.
<infinity> cjwatson: I'd be willing to bet that \r\n works too, but too lazy to bother checking.
<infinity> (Cause that's a crap solution for us)
<infinity> Though I'd look into it if I had the energy to file a Chrome bug upstream.
<Laney> Does libudev0-udeb need to be NBS removed for britney to start considering udev?
<cjwatson> No
<infinity> No.
<infinity> Damn my insistence on puctuation.
<cjwatson> proposed-migration does its consideration on the assumption that any to-be-NBSed binaries don't exist
<Laney> what does the excuses entry for udev mean then?
<cjwatson> i.e. it assumes that the new suite looks like (old suite) - (all contents of old source package) + (all contents of new source package)
<infinity> It means there a libudev0-udeb in proposed.
<infinity> I'll remove it.
<cjwatson> Oh, right.  Yeah, maybe it does then :)
<cjwatson> Forgot that it needs NBS removal to pass the excuses stage.
<Laney> :-)
<infinity> Fixed.
<Laney> merci
<infinity> NBS removal in -release isn't required, but it has a bit of a tizzy if there's NBS in -proposed.
<cjwatson> Yeah.  NBS removal in release pre-migration is kind of a bad idea in case the migration fails for a reason you haven't thought of, anyway.
 * Laney nods
<Laney> At least excuses is pretty clear about NBS in proposed
<Laney> pitti: Looks like you missed xwiimote. I'll upload a rebuild there.
<infinity> pitti: xwiimote might need an O_BLOCK change.
<infinity> Laney: ^
<dobey> aww, infinity didn't review my fix for twisted last night. sad cupcakes :(
<infinity> dobey: No, I had a bit of a crisis here.  I'll look now.
<Laney> infinity: Not familiar with the problem. You do it if you like.
<dobey> infinity: oh ok. thanks :)
<infinity> dobey: ... if I can find that browser window again.
<infinity> Ah-ha.
<dobey> heh
<infinity> dobey: Looks plausibly correct.  Uploaded.
<dobey> thanks
<ogasawara> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: ogasawara
<Laney> seb128: amd64 retracers dead again?
<seb128> Laney, yes, for 2 days :-(
 * seb128 removes lock
<seb128> <html><body><h1>504 Gateway Time-out</h1>
<Laney> hmm, I just came across a bug I filed on 2013-02-28
<Laney> which isn't retraced yet
<seb128> Laney, is it tagged need-<arch>-retrace ?
<Laney> yes, and ~apport is subscribed
<seb128> maybe we didn't get any run that managed to clear the backlog since
<seb128> we keep restarting them but they hit launchpad timeouts regularly
<seb128> Laney, what's the bug numbeR?
<Laney> #1134468
<Laney> er, #1135568
<seb128> Laney, it's in the retracing pool
<seb128> last run had a backlog of 350 bugs :-(
<seb128> Laney, I will try to watch for timeouts and keep restarting until we clear the backlog
 * seb128 shakes fist at launchpad
<pitti> Laney: err, I did? that doesn't depend on libudev
<pitti> Laney: not on amd64 at least
<Laney> does here
<Laney> Depends: libc6 (>= 2.14), libudev0 (>= 147)
<Laney> (libxwiimote1)
<pitti> Laney: ah; thank you!
<pitti> not sure how it slipped through
<Laney> np - I didn't upload it because of â's comment
<xnox> infinity: add a new highlight for â
<Laney> that was specifically intended not to highlight
<infinity> pitti: Yeah, at a quick glance, it might need a similar-but-different NOBLOCK fix (in fact, their internal wrapper function already has a "bool blocking" argument, but then they call it with false...)
<infinity> pitti: I'm trying to sort out if that's valid, or if they've misunderstood what they want and it accidentally worked before.
<infinity> pitti: Not having a clue what any of it's meant to do, it's a bit of a crap shoot trying to follow the code and guess their intent. :P
<infinity> pitti: And happy to hand it off to you, since it's your transition.  I got distracted by chromium on ARM anyway.  And Jono's G+...
<infinity> jono_: Grr.
<pitti> yeah, making a note; thanks
<jono_> infinity, the G+ post?
<jono_> lol
<infinity> jono_: Yes.  I wish this wasn't something I felt so passionately about, so I could just sit back and laugh instead of being grumpy.
<lifeless> which one ?
<pitti> Laney, infinity: hm, I did upload chromium -- another hardcoded dep?
 * ogra_ opens G+ in curiosity
<Laney> chromium is armhf out of sync fail
<micahg> I thought someone forced through the last version, so it shouldn't matter
<pitti> kipped: udev (0 <- 451)
<pitti>     got: 108+0: i-108
<pitti>     * i386: chromium-browser, [...]
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt only complains about i386, not amd64 or arm
<ogra_> Laney, the eternal one :/
<infinity> pitti: chromium isn't your problem.  I'll work on the armhf FTBFS and, if it stumps me, force the rest.
<micahg> pitti: that's because i386 still used libudev0, must not have published in time or something
 * pitti likes not owning chromium problems as well at this point and goes back to puzzling together a Frankenudev
<pitti> micahg: hm, I uploaded that yesterday already
<micahg> pitti: if CHromium needs a rebuild, I want to fix an RC bug
<micahg> pitti: see the build log yourself :) https://launchpadlibrarian.net/134067999/buildlog_ubuntu-raring-i386.chromium-browser_25.0.1364.160-0ubuntu1b1_UPLOADING.txt.gz
<micahg> oh, hrm, nevermind, it's in the base system
<infinity> micahg: Want to bounce me the fix?  I'll incorporate it into my armhf-fixing upload, if I manage to sort that today, or just sponsor it if I don't.
<infinity> micahg: To avoid back-to-back builds.
<pitti> micahg: yeah, and those debs use libudev1
<micahg> infinity: it's to drop the recommends here to suggests: bug 1153137
<ubottu> bug 1153137 in chromium-browser (Ubuntu Raring) "Please remove recommends on webaccounts-chromium-extension and unity-chromium-extension" [High,Triaged] https://launchpad.net/bugs/1153137
<infinity> pitti: The chromium-browser output in output.txt is a red herring, just due to britney not updating chromium at all from the armhf out-of-date.  Ignore it.
<infinity> micahg: ^
<pitti> infinity: ack
<infinity> micahg: And yeah, I can do that fix while I'm in there.
<micahg> infinity: thanks
<micahg> pitti: sorry for the noise
<chrisccoulson> infinity, armhf build fix? note, i've got fixes local here which make it build on armhf (12.04 though)
<chrisccoulson> oh, different version though ;)
<chrisccoulson> ha
<infinity> chrisccoulson: Oh, if this is a solved problem, I'll happily let you fix it in raring so I don't have to.
<chrisccoulson> infinity, it looks like the raring issue is a new one, as with every new version ;)
<chrisccoulson> infinity, i suspect that if you fix it, it won't start in any case
<slangasek> jodh: ping
<jodh> slangasek: hi
<infinity> chrisccoulson: That's rather optimistic of you.
<chrisccoulson> infinity, i'm a positive thinking guy
<slangasek> jodh: heya!  apparently I didn't manage to actually submit my review comments on https://code.launchpad.net/~jamesodhunt/upstart/file-bridge-MP/+merge/152767 before it got merged :)  Most of my comments are cosmetic manpage stuff that I can just fix up, but there was one point I wanted to discuss
<slangasek> jodh: why 'FEVENT', 'FPATH' instead of just 'EVENT', 'PATH'?  The latter seems much more idiomatic to me
<jodh> slangasek: because PATH is going to be set in the user session.
<jodh> slangasek: we could change it to 'file FILE=/some/path' maybe.
<slangasek> oh right
<slangasek> jodh: I think I would prefer either 'FILE' or 'FILE_PATH'; I find the 'F' prefixing less than pretty :)
<infinity> chrisccoulson: Oh, wow, I hadn't even looked at the raring FTBFS.  That's a big WTF.
<chrisccoulson> infinity, yeah, i just thought exactly the same thing ;)
<jodh> slangasek: agreed - I vote for FILE then :)
<infinity> chrisccoulson: And not filesystem corruption or something, the previous build was the same.
<infinity> chrisccoulson: These people aren't doing silly -nostdinc things and then constructing an incorrect include path themselves, are they?
<jodh> slangasek: EVENT is a bit generic though too I thought.
<pitti> Laney: ah, so you didn't upload xwiimote yet, right?
<infinity> pitti: Nope, he didn't, because of my concerns.
<infinity> pitti: Which I was tracing through until I handed it off to you.
<infinity> pitti: <3
<pitti> ah, ok
<jodh> slangasek: maybe CHANGE=...?
<pitti> I'll test my franken-udev now, and if that works I'll call it a (long enough) week, so somethign for Monday
<pitti> _sbin_udevd.0.crash
<pitti> meh
<pitti> Monday it is
<slangasek> jodh: I think 'EVENT' is fine, honestly
<slangasek> jodh: it's a bit recursive since upstart events are also events, of course
<jodh> slangasek: :)
<chrisccoulson> infinity, i can take a look at this. i should probably try the latest version to make sure it's still got the same v8 problem that i've been looking at
 * chrisccoulson reluctantly rm's my current build tree to free up space
<slangasek> jodh: maybe it would be better to make it part of the event name itself?  i.e., file_create, file_modify, file_delete?   That makes jobs more cumbersome if you want to watch for all three though
<chrisccoulson> hmmm, i'm sad now. it took me long enough just to get that tree to build on my sad panda ;)
<slangasek> jodh: upstart itself doesn't use $EVENT anywhere, just $UPSTART_EVENTS.  Maybe INOTIFY_EVENT?
<xnox> slangasek: omit FEVENT, and just listen for file FPATH=/foo, that will give you all three. and just test.
<slangasek> xnox: yes, but I'm arguing against 'FEVENT'
<xnox> udev events use these semantics.... and it's nice =)
<slangasek> xnox: thinking out loud about whether it should be part of the actual /upstart/ event name, but that has the mentioned drawback
<infinity> chrisccoulson: Cool, if you're on it, can you also fix the bug micahg pointed out?
<slangasek> actually, 'file-create', 'file-modify' would certainly be closer in spirit to the existing upstart bridge ('net-device-added', 'net-device-removed', ...)
<chrisccoulson> infinity, which one?
<infinity> chrisccoulson: https://launchpad.net/bugs/1153137
<ubottu> Launchpad bug 1153137 in chromium-browser (Ubuntu Raring) "Please remove recommends on webaccounts-chromium-extension and unity-chromium-extension" [High,Triaged]
<infinity> chrisccoulson: Just dropping those to Suggests will do the trick.
<slangasek> jodh, xnox: what do you think about file-create/file-modify/file-delete events, rather than a generic 'file'?
<jodh> slangasek: MP raised for FPATH -> FILE et al.
<jodh> slangasek: We've already got examples of both approaches - the udev bridge follows your proposal but the socket bridge the current file bridge way. I guess by splitting file into 3 separate events we offload the burden of filtering the correct one from the job to the bridge itself. But you can of course already specify individual events using (now) EVENT='...'.
<jodh> slangasek: the current approach does allow a mix of behaviours though - if you care about all the event types, just don't specify EVENT (oddly :). Whereas, if you only care about a single type, specify it explicitly.
<stokachu> hi, could i get someone to approve precise nomination for bug 1155157
<ubottu> bug 1155157 in unity-greeter (Ubuntu Raring) "[FFe] Allow custom indicators" [Undecided,New] https://launchpad.net/bugs/1155157
<stokachu> and Quantal nomination as well
<mitya57> dholbach: pt_BR 74% :)
<dholbach> mitya57, yes - did you see the bug report I added?
<dholbach> it FTBFS
<ScottK> stokachu: We don't generally allow new features in SRUs.  Why precise?
<dholbach> and I was too busy to look into anything at all regarding the packaging guide
<dholbach> still too busy
<mitya57> no, I didn't
<stokachu> ScottK: mind if i pm you?
<ScottK> No
<ScottK> I won't have anything different to say in private, but as you prefer.
 * mitya57 is looking
<mitya57> dholbach: bug 1154087 fixed now
<ubottu> bug 1154087 in Ubuntu Packaging Guide "building pt_BR FTBFS" [Undecided,New] https://launchpad.net/bugs/1154087
<mitya57> re the sphinx versions, that build-dep was needed for debian; I'm going to backport the required versions in my test ppa and then copy to packaging-guide ppa
<dholbach> mitya57, perfect - feel free to merge the other branch then
<dholbach> mitya57, you're a hero
<dholbach> mitya57, once the package built correctly I'll make the necessary changes to developer.u.c
<dholbach> but this day was long enough already and I need to rush out to meet somebody for dinner
<stokachu> seb128: hey do you mind taking a look at bug 1155583
<ubottu> bug 1155583 in gnome-screenshot (Ubuntu Precise) "gnome-screenshot does not display accented characters correctly" [Low,Triaged] https://launchpad.net/bugs/1155583
<dholbach> so let's take care of the other bits via mail :)
<mitya57> developer.u.c uses quantal packages, so this will wait until I backport sphinx
<dholbach> mitya57, are you merging the ptbr branch I did or shall I do it?
<mitya57> dholbach: will do one more test build and merge
<dholbach> ok thanks
 * dholbach hugs mitya57
<dholbach> have a great weekend everyone!
<mitya57> dholbach: you too!
<seb128> stokachu, that patch looks fine to me
<stokachu> seb128: sweet, do you think we could get that in motion?
<stokachu> :)
<seb128> stokachu, you should ask for upload rights at some point ;-)
<stokachu> seb128: hah i did but didn't have enough upstream collateral
<seb128> ok, I will avoid starting a DMB rant today :p
<stokachu> lol
<stokachu> seb128: thanks man
<seb128> stokachu, yw
<ScottK> seb128: I see the fonts-tlwg package you sync'ed two weeks ago is still dep-wait.  Did you have a plan to address that?
<seb128> ScottK, will do now that I know about it, I wish launchpad would email the uploader about those or something
<seb128> ScottK, how/where did you notice that it's depwaiting?
 * seb128 would like a list of depwait packages
<ScottK> Let me find the link
<ScottK> seb128: Found it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<seb128> ScottK, ah, thanks
<ScottK> seb128: It's also on http://qa.ubuntuwire.com/ftbfs/
<stokachu> jamespage: ping
<pitti> there, Frankenudev working, have a nice weekend everyone!
<seb128> pitti, great work systemd/udev/logind this week
<pitti> *phew*
<seb128> pitti, have a nice w.e!
<pitti> seb128: you too!
<micahg> seb128: Debian has a new libgsf and I TIL, I'm happy to merge as it looks like bug fix only, but I wanted to check with you first
<seb128> micahg, would be good, thanks for working on that!
<micahg> sure, thanks
<stokachu> xnox: ping :D
<seb128> stokachu is looking for extra sponsoring/uploads :p
<stokachu> haha
<stokachu> this time im just looking for information on why autofs5 is still being built without dbgsym
<stokachu> or if it is i can't find them on lp
<seb128> stokachu, look at the build log I guess?
<seb128> https://launchpadlibrarian.net/118514564/buildlog_ubuntu-precise-i386.autofs5_5.0.6-0ubuntu5.1_BUILDING.txt.gz has
<seb128> "autofs is already stripped, ignoring
<seb128> autofs-ldap is already stripped, ignoring
<seb128> autofs-hesiod is already stripped, ignoring"
<stokachu> but they get built as far as i can tell
<stokachu> dpkg-deb: building package `autofs5-hesiod-dbgsym' in `../autofs5-hesiod-dbgsym_5.0.6-0ubuntu5.1_amd64.ddeb'.
<seb128> stokachu, they are on http://ddebs.ubuntu.com/pool/main/a/autofs5/
<seb128> it seems?
<stokachu> ah there we go
<seb128> 5.1 seems to be missing for amd64/i386 though
<seb128> maybe the collector job failed to run
<seb128> you should nag infinity about finishing proper ddeb support in soyuz :p
<stokachu> lol maybe ill save that for another day
<pitti> Laney, infinity: xwiimote fix uploaded, FTR; so please feel free to hint away chromium :)
<pitti> and good night for real
<ogra_> pitti, enjoy
<infinity> pitti: Curious.  If you decided that was necessary, why not just s/false/true/ to the call to the wrapper that sets up the monitor?
<hallyn> cjwatson: hey, when talking about how to package openbios-ppc in ubuntu, stgraber suggested (iiuc) that signed kernels are being done by building on the native arch, then having other arches take binaries from the native compiled package.  Is that so?
<hallyn> (I looked at linux-meta, and see it's amd64-only, but don't see any packages for other arches)
<hallyn> (sorry if you're the wrong person to ping, it just seems like your bag of chips :)
<stgraber> hallyn: -signed actually uses binaries for the same arch but generated earlier on
<hallyn> ah
<stgraber> hallyn: (or so is my understanding)
<hallyn> so it can just grab them from debian/tmp ?
 * hallyn checks
<stgraber> hallyn: no, it grabs them from the archive because they are two different sources
<hallyn> stgraber: what source package is this happening in?  the -signed packages seem to source from linux-meta, but i don't see it there
<stgraber> hallyn: basically for the kernel, the "linux" sourcei s uploaded, builds on all architectures. Then the "linux-signed" source is uploaded (containing just a script) which at build time, grabs the binary generated earlier on by the "linux" source, signs it and produces another binary package with it
<stgraber> hallyn: apt-get source linux-signed
<hallyn> d'oh.  i didn't see that in my aptitude query.  sorry.
<hallyn> heh.  so i should be bugging apw if anyone :)  thanks stgraber
<stgraber> hallyn: well, poking cjwatson is still a good idea just to make sure that it'll be allowed to do such a trick in the Ubuntu archive ;)
<hallyn> i assume he's done for the day,
<hallyn> so I'll just stare at this awhile, let it sink in over the weekend, then talk to him/them on monday
<ogra_> he tends to read backlog :)
<hallyn> thanks!
<hallyn> ogra_: I figure
<stgraber> cjwatson: to clarify, we're talking about having openbios build for all supported architectures, then have another source package (qemu or something) grab the binaries from the earlier openbios build and dump them into an arch:all package to be used by qemu-system-*
<hallyn> stgraber: "build for all supported architectures"?  I actually thought we were going to only have openbios-ppc-real build on ppc (we can't have it build on sparc :) and then on other arches grab the binaries (from openbios-ppc)
<hallyn> (from oepnbios-ppc-real, into openbios-ppc, that is)
<stgraber> hallyn: "all supported architectures for openbios-pcc" == powerpc ;) but yeah, I guess I could have said just ppc
<hallyn> oh ok :)
<hallyn> is it possible to get a ppa to build packages for ppc?
<slangasek> hallyn: only a devirtualized ppa
<slangasek> which are a scarce resource and should be used sparingly
<hallyn> slangasek: ok, not sure it's needed - it would be to test the ping-ponging of openbios-ppc pkg as described above ^  will wait to look more into that, thanks.
<arges> bdmurray: slangasek: re bug 1059592, verification was never completed because the test case is fairly undeterministic. I'm not sure a regression was introduced by this issue as you posted, but if you'd like to drop the patch you can because I haven't verified it.
<ubottu> bug 1059592 in rsyslog (Ubuntu Quantal) "Message and memory corruption in rsyslog" [High,Fix committed] https://launchpad.net/bugs/1059592
<slangasek> arges: well, lack of verification means it'll get dropped out anyway at some point, but having reviewed the diff + the new bug report I'm confident in asserting it's not a regression
<arges> slangasek: agreed thanks
<bdmurray> there's also bug 1097920 although that is regarding the quantal-proposed package
<ubottu> bug 1097920 in rsyslog (Ubuntu) "rsyslog SEGFAULT " [Undecided,New] https://launchpad.net/bugs/1097920
<chrisccoulson> infinity, the chromium build system is passing a bogus --sysroot argument to the compiler, pointing to a non-existant path
<bdmurray> oh, that's unlikely related too
<chrisccoulson> removing that fixes the error on the one object i've tried it on ;)
<chrisccoulson> (now to figure out how to fix the build system properly)
<infinity> chrisccoulson: Ugh.  Sounds like some gifted child has decided that ARM == cross-building.
<infinity> chrisccoulson: I can't think of any other reason to pass --sysroot, especially only on one arch.
<chrisccoulson> infinity, that's exactly what they're doing. in common.gypi:
<chrisccoulson> ['OS=="linux" and target_arch=="arm" and chromeos==0', {
<chrisccoulson> 'sysroot%': '<!(cd <(DEPTH) && pwd -P)/arm-sysroot'
<chrisccoulson> yay!
<infinity> Brilliant.
<chrisccoulson> anyway, i'm off to do some exercise for now. will fix it when i get back :)
<ogra_> does that mean chromium 25 in raring on arm ?
<infinity> ogra_: Assuming he's also fixed the old FTBFS too, yes.
<chrisccoulson> ogra_, don't get your hopes up ;)
<infinity> ogra_: This was a new bug on top of the old.
<infinity> (Plus, even if it builds, it may still fail to, like, do browser stuff)
<chrisccoulson> chromium 24 doesn't start on arm, even when it does build
<chrisccoulson> i was still investigating that when i decided i might be better off building the latest version now ;)
<infinity> There needs to be a testcase for that.  do_browser_stuff() || echo "Iz not browzer."
<chrisccoulson> infinity, yeah, we pretty much have that sort of testcase for firefox already https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/ARCH=i386,label=adt/ ;)
<ogra_> well, i'd really like to run something newer than 22
<ogra_> but i wouldnt minf FF either if it would be usably fast
<chrisccoulson> ogra_, it's fine on !arm ;)
<ogra_> i know
<infinity> ogra_: FF is probably fast if you disable recording history.
<ogra_> make gecko use GLES and it will fly on arm too
<infinity> ogra_: The constant read/writes to that sqlite DB are hell on machines with mediocre storage I/O.
<ogra_> infinity, scrolling in websites is unusabley slow
<infinity> Oh.
<infinity> That's a different kettle of fish.
<ogra_> yeah
<ogra_> its definitely the rendering itrelf
<chrisccoulson> if you make me do all of my work on an arm machine, i'd probably end up fixing it ;)
<ogra_> specifically if there is any javascript in the pages it seems
 * ogra_ ponders paying chrisccoulson a crhomebook if he promises to not use anything else until its fixed 
<chrisccoulson> heh
<ogra_> you would even get along with that insane kezboard
 * ogra_ never had a Â£ sign before
<ogra_> its actually the only kbd i ever had that has three currency keys
<infinity> Mine only has one.
<infinity> I feel so underprivileged.
<infinity> And I have no idea how to make GBP or EUR with compose...  If there's a way.
<ogra_> likely ...
<ogra_> never needed it ... so i'm the wrong one to ask :)
<ScottK> infinity: Find a web page with the symbol and copy/paste.
<infinity> The obvious attempt at Compose+EUR did nothing useful.
<ogra_> poor mans compose
<infinity> Oh well.  All I really need is â­
<ogra_> heh
<ScottK> In â­, â­ â­ you.
<JanC> you can always define your own compose combinations (if you work around GNOME's braindead US-only compose)
<infinity> All, L- for Â£
<infinity> And E= for â¬
<infinity> Those are fairly memorable.
 * infinity stores that away.
<pitti> infinity: because AFAICS it's the polling in lib/monitor.c itself which relies on blocking semantics, not the event based loop in ./tools/xwiikeymap.c; ICBW, of course, it's late
<infinity> pitti: Fair enough.  I didn't trace the code very far before I stopped caring because you popped up.
<shadeslayer> can someone update the packageset?
<shadeslayer> s/update/refresh/
<ogasawara> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<xnox> JanC: one can have us keyboard and euro & pound signs? HOW?!
 * xnox is only US keybaord user and constantly copy-pastes those two symbols.....
<sarnold> xnox: compose, e, =  -> â¬  compose, L, -  -> Â£
<xnox> sarnold: wow, also turns out i had compose disabled.
<xnox> today I learned something new =))))
<xnox> however sad it is ;-)
<sarnold> hehe :)
<cjwatson> hallyn: I was thinking that an alternative workaround for that kind of thing might be to have openbios-ppc be Architecture: powerpc and Multi-Arch: foreign; then at least you could use it via multiarch
<robru> sarnold, xnox ... what is "compose"? is that a key?
<hallyn> cjwatson: I think stgraber had suggested that too
<hallyn> cjwatson: then it would build on ppc, and amd64 qemu-system-ppc could recommend it?
<sarnold> robru: yes; under standard unity you can configure it via the configure thingy, keyboard layout, options, "compose key location"
<cjwatson> Or something.  It's all a workaround for an in-principle-fixable Soyuz bug anyway ...
<sarnold> s/location/position/
<cjwatson> So feels a bit weird to introduce new package names as part of the workaround.  Those tend to be stickier than other workarounds.
<hallyn> cjwatson: ok, lemme make sure the debian pkg builds in a chroot, and then ping you if it feels like time to push to the archive
<robru> sarnold, ha, it seems I also have it disabled...
<cjwatson> hallyn: Don't expect me to be around any longer this evening :)
<sarnold> robru: I gave up my right control key for it, which is _sometimes_ annoying when I try to navigate tags in vim with ^]. Apparently 1/3rd the time I try to use right-control. (I never knew that. :)
<robru> â¬ ooooh
<robru> sarnold, I feel that 'Pause' was the obvious choice. I don't think I've ever used that key in my life.
<sarnold> robru: oh yeah, that's a good one. :)
<hallyn> cjwatson: no no, i'm thinking monday :)  thx - good night
<robru> Ã¦ wizardy!
<Sarvatt> xnox: http://cgit.freedesktop.org/xorg/lib/libX11/tree/nls/en_US.UTF-8/Compose.pre
<infinity> cjwatson / hallyn: Enabling an entire new arch via multiarch just to be able to install one package feels a bit icky, though.
<hallyn> ppc isn't multiarch right now?
<micahg> not on x86 (by default)
<slangasek> hallyn: point is it's quite expensive to enable an additional arch on the client for a single package
<hallyn> i see
<hallyn> then maybe i need to look at bug 217427 again after all
<ubottu> bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427
<cjwatson> That's the real proper fix
<cjwatson> And I'd far prefer that :)
<micahg> that'll clear some of the FTBFS list as well that's broken due to missing affinity
<hallyn> all right, i'll try to get a clue about that one later.  gotta run.  thanks all.
<cjwatson> It's I think ~4 packages
<jtaylor> someone know if I need to wrap python socket.send/recv into EINTR loops?
<jtaylor> google is not helpful, some say python handles it, some don't ._.
<jtaylor> oh well trying showed yes
<stgraber> infinity: right, multiarch ppc was my first suggestion when I heard of openbios, but indeed having to add the architecture and have users change the sources.list to support both archive and port, just for a single package seemed a bit more complex and resource hungry than it should be. bug 217427 would definitely be ideal to fix that and until then, some kind of cross/compile of binary copy from ppc to arch:all will have to do.
<ubottu> bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427
<ScottK> Why not just make it arch: powerpc?
<ogra_> because you need to jump through hopps to install it on x86
<ogra_> *hoops
<stgraber> ScottK: it's the rare case where we want a powerpc binary to be shipped on x86 (bios for qemu system emulator). So if it was arch:powerpc, you'd need to enable powerpc multiarch on x86 to be able to get it
<ScottK> Oh.  Right.
<slangasek> option #3 of course is to build a ppc cross-compiler just to build the bios on x86 :)
<stgraber> slangasek: well, we appear to have gcc powerpc on x86 but I have no idea whether it's actually usable to build that bios.
<slangasek> oh, do we?
<infinity> We do.
<slangasek> oh, then we could totally use that
<slangasek> (if we want)
<infinity> I've never looked at the openbios build.
<infinity> If it's just GCC and no fanciness, it should cross trivially.
<slangasek> it's not like it should need anything fancy, it's a bios
<stgraber> so yeah, that was another suggestion I made during the session to try and use that cross compiler to build the openbios binary on x86
<infinity> stgraber: That may well be the least messy path for now, while I work on a proposal and implementation for 217427 (thanks for reminding me).
<infinity> We really need a solid proposal for that for Debian anyway, or we can never, ever, ever have source-only uploads, and I'll be a sad Panda.
 * stgraber tries a cross compile of openbios
<slangasek> stgraber: so I think I just had a really clever idea (upstart-devel); please poke holes in my theory :-)
<infinity> stgraber: If it needs -m64, remember to install the multilib variant of the cross.
<slangasek> seems to only use -m32
<stgraber> slangasek: interesting proposal. Obviously depends on all the jobs on your system being properly designed, but well, we already pretty much depend on that nowadays (you can basically hang everything by making a job "starting" and not returning)
<stgraber> slangasek: hmm, libc6:powerpc doesn't appear to be installable through multiarch
<slangasek> interesting
<stgraber>  libc6:powerpc : Depends: debconf:powerpc (>= 0.5) but it is not installable or
<stgraber>                           debconf-2.0:powerpc
<slangasek> stgraber: mm, debconf is Multi-Arch: foreign
<slangasek> so something else is amiss there
<infinity> Oh, bah.  That's right, our cross-compilers can't be installed on buildds.
<infinity> Cause they need the MA libc.
<stgraber> infinity: they only do if you have any library dependency
<ogra_> rolliing buildds !
<infinity> stgraber: Eh?  Doesn't the compiler itself have the dep?  Oh, maybe it was just cross-build-essential that does.
<stgraber> infinity: nope, I installed the compiler just fine without enabling powerpc multiarch
<infinity> Okay, cool.  It's just cross-build-essential.
<stgraber> infinity: the problems started because of another build-dep of openbios-ppc
<infinity> Which you don't need for this.
<slangasek> what's the other build-dep?
<slangasek> fcode-utils?
<stgraber> yeah
<infinity> Erm, but the other build-deps should be used natively, not cross.
<slangasek> is that ppc-only?
<stgraber> maybe it can just go foreign
<stgraber> nope, I have it on x86 too
<slangasek> yeah, 'utils' is usually a good sign that you want foreign
<infinity> How is any of this about foreign or not?
<infinity> This isn't a dpkg-cross build.
<infinity> You're building *on* i386.
<slangasek> rather, that you want the build arch version, which in this case doesn't require any foreign-ness
<infinity> And build-depending on the cross-compiler explicitly.
<infinity> If you're testing this as an sbuild/dpkg-cross cross-build, you're not testing a scenario that works on buildds anyway.
 * infinity tries this locally.
<stgraber> infinity: hmm, indeed, let me do something closer to what we can do on a buildd :)
 * infinity testbuilds.
<infinity> Oh, bah, these people use kernel scemantics for HOST.
 * infinity inverts his patch.
<infinity> Or, no.  It's just broken in general for cross, maybe.
<infinity> There we go.
<infinity> All fixed.
<infinity> stgraber: I've got it building happily here.
<stgraber> infinity: cool!
<stgraber> hallyn: ^ I guess you can just crossbuild then :)
 * infinity uploads.
<infinity> Or, I will once I diff with Debian and make sure the double-delta didn't make us wonkier than we should be.
<slangasek> That was Easyâ¢
 * micahg hands slangasek some staples...
<slangasek> :-)
 * infinity tests on i386 instead of amd64 to avoid embarrassment later.
<infinity> http://paste.ubuntu.com/5617896/ <-- Our tiny Debian delta to make this work.
<infinity> Who knew that PPC cross compiler would be useful for anyone other than the kernel team? :P
<stgraber> infinity: I suspect you want to change the Architecture field too
<infinity> stgraber: I did.
<infinity> stgraber: That's the diff from Debian, not from raring.
<infinity> (And uploaded(
<infinity> )
<stgraber> infinity: ah, I should have read the changelog, that'd have explained it ;)
<ScottK> I knew that package sounded familiar for a reason.
<infinity> ScottK: Heh.
<infinity> ScottK: Congrats on losing TILM.
<ScottK> \o/
<infinity> hallyn: openbios-ppc is arch:all again, feel free to depend on it all you want.
<infinity> Now, this will have the entertaining side-effect of pulling the powerpc cross-compiler into main, unless we drop qemu-system-ppc to universe by twiddling a bunch of seeds and deps.
<infinity> But we probably want to do that anyway, since stuff like nova-compute-kvm really wants to depend on qemu-system-x86, not qemu-system.
<infinity> (Or maybe promoting cross-compilers that are built from the same sources as our supported toolchain really isn't a bit deal)
<infinity> s/bit/big/
<hallyn> infinity: awesome, thanks!  So, I should wait until qemu-system-ppc is demoted right?
<infinity> hallyn: We should probably sort out a plan to demote all the qemu-system-* bits we don't want in main, yeah.
<hallyn> infinity: drat, i see qemu-system-ppc explicitly added to the server seed, so maybe that's not acceptable.  Daviey ?
<infinity> hallyn: You're the one who added it. ;)
<infinity> hallyn: Anyhow, there's more to fix than just seeds, since things in main depend on qemu-system.
<infinity> hallyn: But maybe we shouldn't fuss over it, and just do an MIR for openbios-ppc.
<infinity> hallyn: *shrugs*
<hallyn> infinity: meanwhile just making it Suggest should be fine right?
<infinity> hallyn: Yeahp, suggests can cross components.
<hallyn> just the mere fact that ppl can install it will be novel :)  thx again
#ubuntu-devel 2013-03-16
<infinity> pitti: The new udev-udeb has a non-udeb dependency (libacl1).
<infinity> pitti: Either need to build it in a way to drop that dep, or we need a libacl-udeb.
<infinity> pitti: unping, re: udev/acl.  Uploaded a fix.
<chrisccoulson> infinity, chromium finished building on arm overnight \o/
<chrisccoulson> (i'll try to run it later)
<infinity> chrisccoulson: Oh, that's good news.  I just finished force-hinting the broken stack into raring, so udev/systemd could migrate, but an upload that actually builds would be FAR better. :P
<ogra_> chrisccoulson, !
<infinity> ogra_: Don't get your hopes up, it still might not run. :P
<ogra_> yeah
<ogra_> but its at least one step forward
<ogra_> i still dont get why though ... given that chromeos/chrome runs just fine so it *must* be possiblle to get it working
<infinity> There seems to be some serious left-hand/right-hand lack of communication there.
<ogra_> yes
<infinity> I don't know if jbailey still works on that, but I should talk to him about WTF is up.
<infinity> Though, that mostly just accounts for failures to build (the right/left thing).
<infinity> The failures to RUN could be v8 having bugs with armhf register usage, etc.
<ogra_> qwell, and there are Keybuk and kees too
<infinity> Unless ChromOS is now armhf too?
<ogra_> it is
<infinity> Ahh, so even fewer excuses now.  Lovely.
<ogra_> i'm using their flash plugin in my ubuntu chromium all day here
<ogra_> and i can run the whhole chromeos desktop in a window under unity too :)
<ogra_> by just firing it up from /opt
<ogra_> not that unity would be very useful (doesnt get along with mali drivers to use HW accel it seem ... everything else does though) or that chromeos in a window would
<ogra_> but for laughs and testing it is fine :)
<jtaylor> slangasek: you m-a'ed tcl recently, will you also do tk for raring?
<infinity> jtaylor: That was xnox, actually.
<infinity> Or maybe wookey, sponsored by xnox, looking at the changelog.
<xnox> that.
<xnox> i guess everyone is pieced off about it, so i should multiarch tk & ship compat shell config script.
<jtaylor> having tk and tcl in the same state would be good
<infinity> There needs to be a compat script?  What broke?
<jtaylor> as they are kind of related
<jtaylor> just a bad configure check in a science package
<xnox> infinity: TkConfig.sh script moved from /usr/lib/ to /usr/lib/$(multiarch)
<xnox> (and tcl)
<jtaylor> my concern is just if I fixx it for tcl now, do I need to revisit it for tk in a few days?
<infinity> Oh.  That's arch-specific? :/
<xnox> infinity: but those config scripts can totally be dpkg-architecture & call the right script.
<xnox> not to break stuff that expects that config script to be there.
<infinity> Yeahp, that would work.
<xnox> jtaylor: well, you can totally test for tk m-a, and try that, if not try normal one, and then bail.
<jtaylor> thats what the bad configure dos
<infinity> I'm not sure there's any value in patching upstream sources to look for the M-A config script at all, if you're going to put the compat one in.
<jtaylor> a enormous list of possible locations it checks :)
<jtaylor> instead of just doing a try link
 * infinity gets the kernels and d-i to migrate and calls it a night.
<jtaylor> the simplest fix for thix package is just add --with-tcl-library=/usr/lib/$(DEB_HOST_ARCH)
<jtaylor> but do I need to do that for tk too in a few days or not?
<infinity> DEB_HOST_MULTIARCH even.
<jtaylor> yes
<infinity> But if xnox adds the compat scripts, you don't need to change anything.
<infinity> And it'll all just work again.
<infinity> Which seems like a whole lot less effort. :P
<jtaylor> the configure does not sue the script
<infinity> Oh.
<infinity> It's looking for the .so?
<jtaylor> yes
<infinity> People who do that should be shot.
<infinity> I'd switch to either the config script or a try link and forward it upstream, instead of adding to the brain damage.
<jtaylor> the funny thing is they do that too
<jtaylor> but only after checking for the so in the hardcoded locations
<jtaylor> very weird :)
<infinity> So, you could just delete the .so checks?
<infinity> Also very valid.
<infinity> The only argument for .so checks is if you're dlopening a hardcoded path.  Which is, in itself, wrong.
<infinity> At least, it's wrong if the library is on the search path, since this isn't 1975, and dlopen() is smart.
<jtaylor> afk 15 min
<cjwatson> jtaylor: I'm in the process of multiarching it - was working on it end of last week
<jtaylor> k so it will be done, thanks thats all I wanted to know
<cjwatson> because it's just madness for one of tcl and tk to be multiarched and the other noe.t
<cjwatson> *not
<jtaylor> yes I though too
<cjwatson> If anyone's really desperate, my current work is http://paste.ubuntu.com/5619256/
<cjwatson> But I plan to get that uploaded early next week once I've prepared corresponding tcltk-defaults changes and done some testing with the ruby1.8 build
<guest16950> hello
<guest16950> question:
<guest16950> ubuntu XX.04 usually gets released at the end of april
<guest16950> but windows xp support will end at 8th of april 2014 (beginning of april)
<guest16950> are you planning to release ubuntu 14.04 prior or on the the 8th of april ;p?
<guest16950> probably would be a good move, wouldn't it ;)?
<guest16950> just saying
<ScottK> guest16950: The release date was set almost half a year ago.  It's a bit late to change it now.
<ogra_> ScottK, really ?ho set it ?
<ogra_> *who even
 * ogra_ wasnt aware we had a 14.04 date 
<ScottK> ogra_: Oh.  Sorry, I misread his comment.
<ogra_> :)
 * ScottK was thinking 13.04.
<ogra_> yeah, me too first, i had to read twice
<ScottK> OTOH, 10.10.10 was so annoying, I'm sure I don't want to release at the start of the month.
<ogra_> well, depends what the TB decides ... if there is actually a six month cycle before yeah ...
<ogra_> in a rolling model two weeks dont really hurt
<guest16950> just imagine how many users still are using windows xp ;)
<guest16950> and on the 8th of april 2014 they have to look for a new os
<guest16950> because ms won't provide any updates to xp any longer from that date on ;)
<guest16950> (according to the current plan)
<guest16950> having 14.04 ready until or on that date sounds like a good idea to me ;)
<guest16950> btw: i really hope the following bug:
<guest16950> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/578045
<ubottu> Launchpad bug 578045 in software-center (Ubuntu) "Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS" [High,In progress]
<guest16950> will be fixed until then ;)
<ScottK> ogra_: I hope the discussion at the TB will coalesce around Mark's latest proposal.  It seemed generally reasonable to me.
<ogra_> well, i dont know how much rick wants to still push his proposal ... so we'll see
<ogra_> but yeah, marks is definitely sensible
<slangasek> jtaylor: no, I didn't :)
<jtaylor> slangasek: found the "culprit" already
<jtaylor> but you are wookey on oftc or?
<ScottK> jtaylor: He's vorlon on oftc.
<jtaylor> oh
<jtaylor> sorry, mixed that up
<slangasek> yes, wookey is wookey everywhere
<penguin42> it's the only name he has
<jcastro> If there's a backport request that deals with a major bug in a package with a fix I need to ping .... ?
<jcastro> can someone fill in the blank for me?
<ScottK> jcastro: With a package that's already been backported?
<jcastro> I don't think it's been backported yet
<ScottK> jcastro: It kind of depends on the specifics.
<jcastro> https://bugs.launchpad.net/precise-backports/+bug/1095056
<ubottu> Launchpad bug 1095056 in Quantal Backports "Please backport rkhunter 1.4.0-2 (universe) from raring" [Undecided,Confirmed]
<jcastro> is the bug in question
<jcastro> someone pinged me about it, seems like there's a fix available, I just need to know what the next step is
<jcastro> getting people to test the backport?
<ScottK> Someone needs to test unhide and unhide.rb with it.
<ScottK> If those work, then it can be backported.  Feel free to ping me and I'll do it if no one else is around.  Laney or micahg could too.
<jcastro> ok, I'll get the guy to post his findings on the bug
<jcastro> thanks!
<ScottK> You're welcome.
#ubuntu-devel 2013-03-17
<geofft> Hm, manpages.ubuntu.com doesn't seem to be doing things with quantal or raring, despite #1073483 saying it should
<melodie> hi
<melodie> what is the package name for pygtk ?
<FlowRiser> melodie, python-gtk2-dev
<melodie> hi FlowRiser thanks.
<melodie> is it for dev and also non dev use ?
<FlowRiser> melodie, whenever you are searching for a package name, use apt-file search <library_name/part_of_package_name>
<FlowRiser> melodie, it's only for dev
<melodie> ie: http://obmenu.sourceforge.net â
<melodie> "Dependecies
<melodie> Python 2.3 or better, pygtk and pyglade."
<melodie> but there is no package having for name just "pygtk"
<melodie> ok, I will install apt-file and reload it
<FlowRiser> it refers to the libraries ... pygtk.h and pyglade.h
<FlowRiser> and to the respective include paths, ofc
<mitya57> there is a non-"-dev" package as well: python-gtk2
<mitya57> looks like it's what your package should depend on
<melodie> thank you mitya57
<mitya57> (by the way I won't recommend new packages to depend on pygtk at all as it's deprecated for ~ two years)
<melodie> the apt-cache show command returns this for the depends "Depends: python, python-support (>= 0.90.0), python-glade2"
<mitya57> python-glade2 depends on python-gtk2, so no need to depend on both
<melodie> I get it. thank you very much.
<FlowRiser> i don't see any pygtk in the apt-cache result ... weird stuff
<melodie> me thinks apt-cache finds only chains when the chain is exactly the same in the package name, not more
<melodie> perhaps apt-file would find more
<melodie> I try now
<FlowRiser> Anybody knows if there's a special PulseAudio Simple library for C++ ? Or is it just libpulse-simple-dev
<FlowRiser> i meant libpulse-dev*
<melodie> FlowRiser their website says about simple api but not library.
<FlowRiser> melodie, aren't apis just libraries ? O.o
<melodie> api stands for application programming interface
<melodie> library " a collection of implementations of behavior, written in terms of a language"
<melodie> so it is not the same thing
<melodie> from wikipedia
<melodie> http://en.wikipedia.org/wiki/Library_%28computing%29
<melodie> http://en.wikipedia.org/wiki/API
<FlowRiser> http://en.wikipedia.org/wiki/Application_programming_interface#API_libraries_and_frameworks
<melodie> FlowRiser did you see that one page ? http://freedesktop.org/software/pulseaudio/doxygen/simple.html
<FlowRiser> I think most software APIs are just frameworks with multiple implementations
<melodie> perhaps it is the one
<FlowRiser> melodie, i'll try it in C++ right now, but the examples are in C
<melodie> you might be right
<melodie> you didn't say what exactly you want, maybe a page such as this would be helpful ? http://ysflight.in.coocan.jp/programming/audio/pulseAudioSample/e.html
<melodie> I have to do something else now...
<melodie> and could not be more helpful anyhow. :)
<FlowRiser> melodie, no worries, thanks for your time :D
<melodie> sorry I can't help more. :)
<FlowRiser> melodie, that download link was just the thing! It turns out there's only one implementation for both C++ and C, thanks :)
<melodie> which one, the first one at freedesktop.org ?
<melodie> FlowRiser I am happy I could help
<melodie> hi
<melodie> when in the description of a package we read "maintainer" on one ligne (ie: Ubuntu Developers) and "original maintainer" under, does it mean the original maintainer does not look after it anymore at all ?
<mitya57> melodie: no, Original-Maintainer field is set for all packages that are modified in Ubuntu
<melodie> mitya57 what should I do then ? I want to submit a desktop file for obmenu, and ask that the icons from the sources be installed to a regular icon directory under /usr/share instead of /usr/share/obmenu/icons where it is presently.
<mitya57> melodie: file a bug or merge proposal
<mitya57> by the way see https://wiki.ubuntu.com/DebianMaintainerField
<melodie> ok, I will file a bug (no merge proposal, there is no desktop file at all in the package)
<melodie> thank you mitya57
<mitya57> you still can file a merge proposal adding it :)
<melodie> is that very different from a bug report ? anything specific to it ?
<melodie> mitya57 sorry for the lag, my machine was lagging with heavy tasks :)
<mitya57> melodie: it'll be looked at quicker
<melodie> great
 * melodie looks for the merge proposal corner
<mitya57> http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<melodie> mitya57 I am not yet enough used to make packages, I have only done one, with a little sweat and lots of help. I'll train next, but for now and for this one I'll just report it as a bug. :)
<mitya57> ok, that is welcomed anyway
<melodie> I find many little bugs, and I try to report them one by one as soon as possible after I found them. I am working on the creation of a Openbox spin, which has to be simple to use and yet flexible to modify
<melodie> doing this brings me many things to discover (bugs but not only, of course)
<melodie> does someone know how to remove dangling links in a chrooted system ?
<xxtjaxx> melodie: What links? Symlinks?
<melodie> I am browsing the help files from fslint (the cli)
<melodie> yes xxtjaxx dangling symlinks
<xxtjaxx> melodie: they are basically files so you could simple remove them.
<melodie> I found how to display them but not how to remove them
<melodie> there are many, really many
<xxtjaxx> rm
<melodie> too slow
<melodie> I'll try with find
<melodie> ^^
<melodie> and exec...
<xxtjaxx> find -lname?
<melodie> xxtjaxx I think I would rather have to try to find a command line using find and fslint (the one which is under /usr/share/fslint/*)
<JanC> melodie: find also has a -delete action which doesn't need -exec
<melodie> hi JanC and then how could I chain that with fslint ? (without distroying a symlink which would not be dangling if the system was alive... )
<maxb> You can't. You have no gurantee that some dangling symlinks are not intentional parts of the system
 * cjwatson tries to work out how this is #ubuntu-devel material ...
<maxb> Hmm, good point
<melodie> cjwatson do you think I might be OT ?
<melodie> while trying to make a particular remix, I found lots of dangling links, so I try to find a way to remove them without breakage
<ClientAlive> what does it mean if a partion's mount point shows up as "/boot/efi"? I know what efi is. What I'm asking is - is that a partition inside a partition? Is it a directory inside the /boot partition? And, at what level of that is the file system formatting at?
<ClientAlive> what I'm getting at is - if I had to manually create /boot/efi on a machine, how would I do it properly?
<ClientAlive> #ubuntu no one seems to know so that's why I came here
<maxb> ClientAlive: That's not *really* a good excuse for violating the channel topic quite so conclusively :-/
<ClientAlive> maxb: what?
<ClientAlive> well do you have a suggestion how to get some information (if I'm in such gross VIOLATION)?
<maxb> #ubuntu-devel is supposed to be for the development of Ubuntu, not a way to escalate support questions that people on other channels don't answer
<ClientAlive> so why would you assume intentional evil on my part by saying "excuse" ??
<ClientAlive> not cool
<maxb> Well, perhaps I'm being a little sensitive, but since OT-ness has already been brought up in the past few hours...
<JanC> melodie: so, I think your real question is if there exists a list of "broken" symlinks that are intentionally there and should not be removed?
<melodie> JanC almost that
<melodie> JanC suppose there are symlinks here and there which might be active only in a system which is booted and not in one which is being built. I am starting a vm to make tests in it, and see what dangling symlinks will be listed for removal
<melodie> then I hope I will be able to compare with what I will find in the chrooted build directory
<JanC> I think 'find -L . -type l' lists dangling symlinks under the current directory--should be easy to compare between both then?
<melodie> JanC thank you, I am going to try it
<JanC> but that would assume dangling symlinks are *always* used on a live system
<melodie> ?
<melodie> ok, I will check both status : installed and live as well. :)
<JanC> I mean: they might be intentionally there, but not always being used
<melodie> I get it
<melodie> that would explain why I found those kinds in several live cd's
<JanC> e.g. they might be dangling if certain devices aren't available
<melodie> yes
<melodie> JanC I just looked at man find to check the -type l, and I found that very tricky and clever. thank you very much
<melodie> once I will have checked all what it returns I can try a :
<melodie> find -L /usr -type l -exec rm {} \;
<melodie> mostly only /etc and /usr have broken symlinks
<melodie> and many more in /usr
<mlankhorst> ermm
 * mlankhorst hands melodie cleanlinks
<melodie> mlankhorst thank you :D
<JanC> as I said before: there is also -delete
<melodie> I stumble upon it and will see what it allows to do
<melodie> JanC is -delete easier, and where do you add it ? at the end ?
<mlankhorst> anyhow you're obsessive if you care about dangling symlinks
<JanC> find -L . -type l -delete
<melodie> mlankhorst it's just annoying to see hundreds of them while seeking for just one file... in a directory
<melodie> that looks unclean
<melodie> JanC thanks !
<melodie> now I will check what I find in a Live vbox
<mlankhorst> for grep? just use -s, find ignores symlinks by default
<melodie> mlankhorst great tip too... thank you very much
<JanC> mlankhorst: hence the -L option
<melodie> o_0 ?
<melodie> -L vs -s ?
<mlankhorst> I mean grep -s
<JanC> to find, I mean  âº
<melodie> find vs grep ? ^_o
<mlankhorst> oh find just pipe 2 to /dev/null
<JanC> cleanlinks does more than removing dangling symlinks BTW
<JanC> it also removes empty directories
<JanC> ... according to its manpage
<melodie> JanC are all empty directories un needed ?
<mlankhorst> JanC: well if you have a new command and dont read its manpage you do so at your own risk :-)
<melodie> this is a small question which have stayd under the carpet since many years now... I see an opportunity to get an answer to such a basic oen
<melodie> one
<mlankhorst> dangling symlinks are harmless so whatever you do it's just to satisfy OCD..
<melodie> ok, just what is "OCD" ?
<melodie> obsessional compulsive disease ? :D
 * mlankhorst kindly refers to google :-)
<JanC> some applications might assume that certain directories are always there
<melodie> don't they use a tiny space ? maybe one inode each ? :)
<melodie> (obessional wish to not spare the slightest space)
<mlankhorst> find /usr -type d -empty ..
<melodie> really I would not want any app to think they need a folder which is not there anymore, but for the poor orphaned links ? don't they use an inode each ?
<mlankhorst> You know what? I'm going to stay out of this.. cleanlinks doesn't do what you want probably
<melodie> (find is a very great tool, btw)
<melodie> I am looking at it now
<melodie> looking for it*
<melodie> now I think I understand : the dangling symlinks could refer to locales not installed, because not yet chosen by a user starting to install to his hard drive ?
<melodie> isn't that so ?
<cjwatson> melodie: if you're inspecting things from outside a chroot then you'll see many allegedly-dangling symlinks that are actually because the symlinks are absolute and you don't have their targets on the system you're using to look at them.  if so then that is an artifact of your approach and not worth worrying about ...
<cjwatson> I find it very surprising that there would be more than a tiny handful of dangling symlinks when inspected properly.  perhaps it would be easier to guess if given some examples?
<cjwatson> certainly if you're trying to do any kind of cleanup on an Ubuntu derivative image that you intend anyone else to use then you need to do things by modifying packages, not by tools like cleanlinks or find/rm pipelines or whatever - which is going to involve understanding why the things you want to clean up are there and where they come from :)
#ubuntu-devel 2014-03-10
<pitti> good morning
<pitti> sarnold_: yes, the i386 retracer crashed, I restarted it yesterday
<pitti> ERROR: Package download error, try again later: Failed to fetch http://ddebs.ubuntu.com/pool/universe/g/gnome-python-extras/python-gtkspell-dbgsym_2.25.3-13_i386.ddeb Size mismatch
 * pitti curses ddebs.u.c.
<pitti> sarnold_: ^ that's why it breaks, I'll have a look
<mlankhor1t> good morning!
<dholbach> good morning
<SpamapS> infinity: just FYI, mysql's tools and daemons static link libmysqlclient because they use private symbols from the library. Upstream is unwilling to compromise on that.
<SpamapS> jamespage: (just reading backscroll) regarding "raise these objections at the beginning of the cycle: sorry. I have a hard time taking vUDS seriously. I will try harder.
<SpamapS> jamespage: had I been privvy to such discussions, I'd have -1'd at that time, because 5.6 didn't even really exist in Debian until very recently. Not LTS material at all.
<darkxst> pitti, bug 1290270? does apt check md5 hashes on index files or just timestamps?
<ubottu> bug 1290270 in apt (Ubuntu) "apt-get uses an unreliable transfer protocol" [Undecided,New] https://launchpad.net/bugs/1290270
<rbasak> darkxst: AIUI, that problem usually happens when there's a bad external http cache. This being a "mobile" Internet connection points to that, but it's not clear.
<rbasak> I believe there's an existing bug that covers /var/lib/apt/lists/* needing manual cleaning when it gets a bad file and subsequent gpg verification failure on downloading a bad file though. This commonly happens on "free wifi" that serves apt-get a bad file in an attempt to redirect the user to a sign-in page.
<ogra_> xnox, could there possibly be some hidden dependency on dbus-x11 in network-manager ? seems we have some random wlan probs in the last images (there was also an lxc change that seems to touch wlan devices but i want to be sure the dropping of dbus-x11 cant cause anything here)
<infinity> SpamapS: You can use private symbols and dynamically link, just need a more exact versioned dep.  Which, when all the packages are produced from the same source, ain't hard.
<pitti> darkxst: the gpg check is the correctness check
<pitti> darkxst: making this better for little-bandwidth connections is quite a task, and it has been discussed several times already; e. g. adopting Debian's pdiff approach
<pitti> darkxst: I think that can't be applied straightforward to Ubuntu as we have so many publisher cycles
<mlankhorst> can't repliate barry's issue >:(
<seb128> dholbach, something weird happened to the sponsoring queue
<seb128> it has 19 items, it was a bit over 30 an hour ago and some of those which dropped should still be listed
<seb128> dholbach, unping, went back to normal by itself on the next refresh
<mlankhorst> barry: ping
<barry> mlankhorst: hi. thanks for responding on that bug.  i am doing a dist-upgrade and can respond in more detail... or we can chat about it now :)
<mlankhorst> I got lucky(?) once, but I really can't reproduce it
<barry> crashes for me every time
<barry> (of course the login hang of LP: #1289410 doesn't help)
<ubottu> Launchpad bug 1289410 in linux (Ubuntu) "Xorg freeze" [Undecided,Confirmed] https://launchpad.net/bugs/1289410
<mlankhorst> I've had a hang when I had apport enabled
<pitti> mlankhorst: of the crashed app?
<mlankhorst> no, apport, but I guess it could be the same xorg freeze bug :p
<mlankhorst> barry: can you install xserver.*dbg xserver-xorg-video-vmware-dbgsym xserver-xorg-input-vmmouse-dbgsym xserver-xorg-input-mouse-dbgsym ?
<mlankhorst> might need to install the ddebs repository from https://wiki.ubuntu.com/DebuggingProgramCrash
<barry> mlankhorst: sure thing
<mlankhorst> and gdb, should be possible to figure out what is going on then
<barry> mlankhorst: yep.  give me a few minutes
<mlankhorst> you can simply attach through ssh to the xorg server as root with 'gdb /usr/bin/Xorg $(pidof X)' 'handle SIGPIPE nostop' 'cont'
<mlankhorst> and then crash the thing, should have a nice backtrace
<barry> mlankhorst: ah, good trick with the ssh.. okay, everything's installed, let's see if i can trigger it
<barry> mlankhorst: is this helpful? http://paste.ubuntu.com/7067823/
<mlankhorst> assert("svga->curr.sampler[i]");
<barry> oh how interesting.  libxatracker is in the bt.  i had a bug a while ago about libxatracker
 * barry looks
<mlankhorst> there is a sampler_view[i], but no sampler[i]
<dholbach> seb128, sorry - no idea what happened
<seb128> dholbach, no worry, launchpad glitch I guess (it was midday where they usually have their short not-available-time)
<seb128> dholbach, down to 32 items in the queue btw ;-)
<cjwatson> there was no fastdowntime today AFAIK
<seb128> ok, so I don't know what was wrong in the sponsoring queue, but it autofixed itself
<mlankhorst> I have no idea what that means here though :P
<mlankhorst> but guessing it's a vmware bug
<barry> mlankhorst: dang.  i can't find that libxatracker bug.  iirc, it caused the graphics to revert to llvmpipe instead of actual 3d
<barry> but that was a while ago
<mlankhorst> different one
<barry> k
<mlankhorst> bug #1271186
<ubottu> bug 1271186 in xserver-xorg-video-vmware (Ubuntu) "No 3D acceleration in Trusty - Gallium3D XA version too new" [Undecided,Fix released] https://launchpad.net/bugs/1271186
<barry> yep, that's it
<barry> mlankhorst: is there any other information i can gather for you here at the gdb prompt?
<mlankhorst> I've pinged prf_jakob in #ubuntu-x
<mlankhorst> barry: from a fresh vm what are the exact steps you do to hit that bug?
<barry> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1284134/comments/13
<ubottu> Launchpad bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [Undecided,Confirmed]
<barry> happens every time
<mlankhorst> ah k
 * barry reboots his vm
<mlankhorst> doesn't work for me :/
<barry> really?  wow.  okay, let me do this.  i'll create a spanking new trusty vm and see if i can reproduce it
<xnox> popey: i'm after calendar r205+ and music r370+ to be released, as it's blocking my python2 removal work. When would those happen or is there anything i can do to make that happen sooner?
<popey> xnox: poke balloons or sergio
<xnox> popey: ack, thanks.
<popey> np
<balloons> a release you say?
<xnox> balloons: sergiusens: can i please get calendar r205+ and music r370+ released.
<xnox> =))))
<balloons> I'll push up the chain ;-)
<sergiusens> balloons, you doing it then?
<balloons> sergiusens, yes I will
<sergiusens> xnox, for what it's worth this can be simpler
<sergiusens> xnox, mock isn't used when running as click as they use it to patch env to return a different home but makes no sense when confined and started with upstart
<balloons> popey, so both are pushed but I need a test review
<balloons> I didn't check them before pushing, so I'll be doing it now alos
<pitti> jamespage, SpamapS: err, all the juju binaries are > 30 MB big? that smells like statically linking the whole Go runtime lib or so; can this be done dynamically somehow?
<pitti> 128 MB installed size is quite large
<xnox> sergiusens: the test should work as non-click on e.g. desktop. thus using python3 compatible mock.
<xnox> sergiusens: and since it's a naked import (even when running under click) it fails with python3.
<xnox> (global, e.g. it's not in the "desktop-only" code branch)
<sergiusens> xnox, yeah; I'm just saying that you can forget about that for click, move to the non click code path and perhaps just dep on python3 for running in desktop/deb mode
<sergiusens> anyways, not blocking; just a suggestion
<xnox> sergiusens: meh, true. I'll do that when dropping python2 code-path everywhere.
<kentb> is it too late to request an upstream version bump for a package?   I.e. update openwsman 2.4.3 to 2.4.4?
<mitya57> kentb: it's not too late provided that that is a bugfix-only release
<pitti> kentb: if the new upstream release only fixes bugs (likely for microrelease updates), there's no problem at all; for new features you need to file a feature freeze exception request
<xnox> pitti: juju binaries are unstripped.
<pitti> xnox: right, stripping gets them down to 20 MB; but that's still a lot of duplication
<xnox> pitti: correct.
<pitti> and it doesn't link to some kind of libgo
<xnox> pitti: per archive policy it should be built with gccgo, however it isn't.
 * xnox ponders if there was a bug open about it.
<jamespage> pitti, unfortunately not
<pitti> xnox: ah, gccgo-go [!amd64 !i386 !armhf], golang-go (>= 2:1.1.1) [amd64 i386 armhf]
<pitti> fun
<mlankhorst> o.O
<arges> @pilot in
<arges> hmm... is the bot down?
<pitti> so it seems gcc-go works in general (as it's used for ports)
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: arges
<xnox> pitti: there is https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1267393 thus i think it's appropriate to request to use same go compiler with shared linking across all arches.
<ubottu> Launchpad bug 1267393 in juju-mongodb (Ubuntu) "[MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang" [High,New]
<xnox> pitti: although as per jamespage's comments there are reasons for prefering golang-go where available.
<pitti> thanks for pointing out
<pitti> jamespage: i. e. golang-go does not have any shared runtime lib? (indeed I don't see any binary package like that)
<pitti> that's ... eww
<jamespage> pitti, yeah - feels odd i know
<jamespage> pitti, the entire golang-go tool chain builds around static linking
<jamespage> pitti, which is why most golang-xxx-dev packages are just a ship of source code
 * pitti now regrets that he even asked; I just noticed the ginormous debs
<jamespage> means that all rbd's need a rebuild every time they change
<jamespage> dh-golang makes some effort to annotate this using Build-Using fields
<pitti> rebuild-o-mania, archive space / download / HD space waste, and a security update nightmare, yay :)
 * jamespage makes no further comments so he does not get himself into trouble
<jamespage> but yeah - I know
<jamespage> pitti, oh - and stripped go built binaries tend to explode in odd ways
 * pitti sheds a tear for the previous implementation in Python..
<jamespage> pitti, you're going to make me cry in a minute
<pitti> jamespage: ok, I better STFU and forget that I even asked :)
<cjwatson> lool,jdstrand: not to be overly are-we-there-yet but if I get reasonably prompt feedback on that click supported-frameworks branch then I might be able to squeeze it in before Qt 5.2 :-)
<cjwatson> (yeah, I know I only just filed it)
<pitti> jamespage: on a different note, I just installed juju-local, and "sudo juju bootstrap" fails, without much to go at: http://paste.ubuntu.com/7068091/
<pitti> jamespage: do you have a hint how to debug what's going on?
<pitti> jamespage: I set root-dir in .juju/environments.yaml to /home/martin-scratch/juju and created that directory
<pitti> jamespage: sudo lxc-ls --fancy tells me that it didn't create any container
<jamespage> pitti, --debug
<pitti> I was following https://juju.ubuntu.com/docs/config-LXC.html
<pitti> jamespage: http://paste.ubuntu.com/7068109/
<jamespage> pitti, ok - drop the sudo
<jamespage> the documentation is for the current stable release - 1.16.x
<pitti> jamespage: hm, I didn't set up my system for lxc-create to work as user
 * pitti cleans up ~/.juju and $JUJU_HOME
<jamespage> pitti, 14.04 has the current dev release which drops the need to explicitly sudo
<jamespage> kinda like py-juju used todo
<pitti> jamespage: ah, thanks!
<pitti> jamespage: that succeeded now
<jamespage> pitti, excellent
<pitti> there's a mongod running now
<pitti> jamespage: thanks!
<pitti> jamespage: sorry, it's been a while since I touched this last (was pyjuju and canonistack before, but with local and LXC that's so much nicer to play with)
<jamespage> np
<jamespage> pitti, next stable should be out this week or next (fingers crossed)
<jamespage> the juju-core team have been sprinting on it
<cjwatson> Laney: I'm looking at converting ubuntu-system-settings to my as-yet-unreleased interface in libclick for getting manifests.  That interface returns a JsonArray *, which of course will need to be turned into a QJsonDocument.  Would you prefer that I serialise/deserialise it via a string, or walk through the members of the JsonArray and recursively translate to QJsonFoo directly?
<Laney> cjwatson: Sorry, DMBing --- I'd probably do the walking way as a matter of taste, but I don't mind really if that's going to be annoying.
<cjwatson> Laney: ok, yeah, it seemed marginal enough for me that I thought I'd ask, so happy to go with your taste
<xnox> sergiusens: balloons: barry: once calendar_app 205+ and music_app 370+ lands we can upload phablet-tools which does python 3 or 2 detection and execution without regressing any results.
<barry> xnox: fantastic!  thanks for pushing this forward while i've been distracted on other things
<sergiusens> xnox, did th unity8 and uitoolkit stuff get resolved already?
<sergiusens> if so, yes
<xnox> sergiusens: yes, it's fully landed in the archive.
<xnox> sergiusens: that also assumes there are no other new/untested apps converted to clicks.
<balloons> popey, it seems music tests don't pass for me, running calendar now
<lool> cjwatson: I looked at the click changes for the framework dir changes, looked good; doing a test build now
<Laney> stgraber: hallyn: Did you see https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1290315 ?
<ubottu> Launchpad bug 1290315 in lxc (Ubuntu) "After 'Switch user', entering password doesn't return to the session" [Undecided,New]
<stgraber> I saw you blame me in #ubuntu-desktop, didn't see the bug report yet though
<Laney> :-)
<cjwatson> lool: it'll be going through CI Train, so that'll catch any build problems that I somehow missed - I mostly wanted to check that it was OK to lock us down to the base name / base version thing
<cjwatson> or double-check I suppose
<lool> cjwatson: I wanted to run the testsuite before approving, and since it requires generated files anyway...
<hallyn> Laney: looking now
<lool> cjwatson: the only thing I noted was that we're exposing functions to get the directory, which is an implementation detail that clients shouldn't poke at
<lool> but I guess they should not use it
<cjwatson> lool: mm, I guess I could hide that; it was by analogy with getting the hooks dir and the db dir which I'd already exposed
<lool> yeah
<cjwatson> lool: tried to hide it but that breaks the tests, hmm
<lool> cjwatson: you could just name it _get_frameworks_dir
<lool> I mean prefix with _
<sergiusens> xnox, will silo and see
<xnox> sergiusens: \o/
<stgraber> Laney: so that's very weird, LXC indeed creates those symlinks but only in the container's rootfs, so unless you have a container without a rootfs (or with your machine's own / as its rootfs), that shouldn't be possible
<cjwatson> lool: mm, I don't really want to have multiple ways to indicate ABI stability
<cjwatson> lool: it might not be worth the effort to hide it - that directory is already a published interface in that other packages install into it
<cjwatson> lool: so we could argue that it's theoretically useful for their build systems ;-)
 * cjwatson handwaves
<cjwatson> I wonder if the linker is assuming that it can non-lazily relocate anything that isn't an exported symbol
<cjwatson> I'm not using -z now though
<Laney> stgraber: http://paste.ubuntu.com/7068381/
<stgraber> Laney: that's your container's fstab?
<Laney> ya
<stgraber> Laney: drop the devtmpfs line, that's your problem
<Laney> did I add that?
<stgraber> yep
<Laney> I don't know why I would have
<stgraber> we never had it in our templates
<stgraber> Laney: you can also shorten all the other lines by using rootfs-relative targets
<Laney> no leading / you mean?
<stgraber> Laney: e.g. "/var/lib/schroot var/lib/schroot none bind 0 0"
<Laney> neat
<Laney> lemme try removing that then
<ScottK> yolanda: Your clamav tests are in Debian now: http://ci.debian.net/#package/clamav
<ScottK> (and work)
<stgraber> Laney: devtmpfs isn't namespaced by default, so that mount was basically the equivalent of a bind-mount of /dev into your container (with the devastating effects you noticed)
<Laney> stgraber: indeed, I figured that this would have come from the template though
<hallyn> I'm pretty sure there was a time where templates did that, but that woudl be probably a year ago
<hallyn> (and probably lasted like a week)
<hallyn> timing is everything :)
<Laney> I think I created this container in Quantal
<stgraber> Laney: odd that you didn't notice this issue earlier, I guess you don
<stgraber> don't use your ttys a lot :)
<Laney> they were broken, so no :-)
<Laney> ah
<yolanda> hi ScottK, cool
<yolanda> and thx
<Laney> it looks like it was in the version of lxc released with Q
<Laney> bad hallyn :P
<hallyn> yeah.  i really don't like the way devtmpfs is single-instance.
<hallyn> it's so non-linux-y
<Laney> can this be cleaned up somehow?
<stgraber> Laney: not easily, we have weird users who actually want to do that kind of stuff on purpose...
<stgraber> Laney: looking in current quantal's source package, I'm not seeing any mention of devtmpfs in templates/ though
<Laney> stgraber: it was removed in a SRU it seems
<Laney> debian/patches/0024-* in the version in quantal-release
<stgraber> yeah, looks like we broke it in ubnutu37 and fixed it in ubuntu38
<stgraber> there was a 20 days window between the two...
<Laney> oh well
<Laney> I guess it's probably quite limited
<hallyn> it *might* be worth spitting out a warning if we see devtmpfs.  i can't think of a legitimate use for that
<hallyn> with lxc-execute, maybe
<stgraber> that and people using lxc.pty = 0 and don't want to run udev in the container but still want all the new nodes to show up
<juliank> pitti: So, is there a chance we'll see 0.9.3.2 in trusty, or will it stay at 0.9.1ubuntu1?
<pitti> juliank: I was going to sync 0.9.3.2 as soon as it gets published in Debian and imported in LP (which will still take a few hours)
<juliank> pitti: Great.
<pitti> juliank: thanks for the fast fix
<juliank> pitti: No problem, git bisect did most of the work.
<pitti> juliank: did you un-archive the debian bug? (I guess so, last time I did that it just took ages to get processed)
<juliank> pitti: Yes, of course. It hope it is visible on all bugs.d.o hosts now, it took some time for all to show an updated bug report.
<Laney> DMB results are awaiting moderation to u-d-a
<GunnarHj> Laney: Me again.
<cjwatson> Laney: clicketyclick
<GunnarHj> Laney: Time to follow up on https://mentors.debian.net/package/mythes-sv ?
<Laney> cjwatson: ta
<Laney> GunnarHj: I'll queue it up this afternoon
<Laney> thanks
<GunnarHj> Laney: TIA
<Logan_> xnox, micahg, bdmurray: congrats! :D
<mitya57> Congratulations! :)
<xnox> Logan_: thanks.
<SpamapS> infinity: IMO there is _zero_ point to such an exact versioned dynamic link. That feels like dogma to me. Also MySQL's engineers, for whatever reason, have never understood how to create shared libraries right.
<SpamapS> pitti: re: juju, I have never run the go version, nor do I expect I ever will. :-P
<infinity> SpamapS: Well, the point would be that if you already have the shared library mapped, you don't need to have a quarter of it statically mapped elsewhere.
<infinity> SpamapS: But yes, it's also not a massively big deal, since the usual security argument doesn't apply when it ships from the same source.
<SpamapS> infinity: you're talking about micro optimizations of /usr/bin/mysql, and /usr/bin/mysqldump
<SpamapS> infinity: EPRIORITIES ;)
<infinity> SpamapS: Every bit helps. :P
<cjwatson> the samba 3 clients shipped that way for ages ... it was a problem for image size but I think not otherwise
<infinity> SpamapS: (But yes, not something I'm passionate about, just something that would really bug me if I was still involved in MySQL maintenance)
<SpamapS> infinity: there are 130 other things to be annoyed about  bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mysql-5.5
<tkamppeter> OdyX, hi
<hallyn> rhythmbox has become a virus?  i keep killing it and it keeps starting back up
<Meerkat> rhythmbox needs a kick in the behind. I installed it yesteryday and its first action on start was to search my entire home folder for music filer, without my consent. Then when I closed it down it kept playing the music and I had to kill the process. Reminds me of Windows apps in that way.
<JanC> Meerkat: closing a window is not the same as closing a process... (it will keep running in the background and you can control it through the sound indicator menu--maybe there should be a better visual indication of that though)
<Meerkat> oh, forgot to mention. There was no icon down where there's usually icons.
<Meerkat> I just tried again and it shuts down as I expected. So that is good.
<justCarakas> I have a question about html 5 apps: what should I use for a date picker ? an option selector ?
<Meerkat> input type=date
<justCarakas> ok
<mitya57-mobile> Also, -> #ubuntu-app-devel
<justCarakas> ive asked it there a couple of times but never got a reply
<Meerkat> so many ubuntu channels. Hard to keep track.
<dobey> justCarakas: this channel isn't really about app dev. i think you want #ubuntu-appdev (or something similar, iirc) for that
<justCarakas> oki
<bdmurray> superm1: have you seen bug 1290460?
<ubottu> bug 1290460 in ubiquity (Ubuntu) "Mythbuntu Installer Crashes" [High,New] https://launchpad.net/bugs/1290460
<arges> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<superm1> bdmurray: no i hadn't
<superm1> i'll add it to the list to look at
<saiarcot895> Would a no-change rebuild of a package go in as a Stable Release Update?
<TheMuso`> saiarcot895: Its been done before afaicr, given a good reason to do so.
<sarnold> what's the deal with all those "TypeError: 'NoneType' object is not callable" messages when apt-get dist-upgrading trusty VMs? Should I be filing bugs for all the ones I spot or is it a known issue that is being addressed elsewhere?
<sarnold> (see e.g. https://bugs.launchpad.net/ubuntu/+source/newt/+bug/1282216 for one example from someone else)
<ubottu> Launchpad bug 1282216 in newt (Ubuntu) "Package install error in python3-newt on trusty" [Undecided,New]
<sarnold> (perhaps part of the python 3.4 conversion?)
<sergiusens> xnox, hey, gallery would be failing as well with the py3 setup
<xnox> sergiusens: .click or app?
<xnox> sergiusens: either don't introduce new clicks, or tell me which ones are ready to go for me to fix.
<xnox> sergiusens: will take a look into gallery now.
<xnox> sarnold: it's a python3.4 bug itself.
<sergiusens> xnox, gallery was changed to click last week (as camera, but that didn't have issues)
<sergiusens> xnox, it's rather simple; need to get the full path to the python module
<xnox> sarnold: known and being worked on .
<sergiusens> xnox, here's the full test run http://q-jenkins:8080/job/andy-smoke-daily-test/3/#showFailuresLink
<sarnold> xnox: great :) thanks
<xnox> sergiusens: right from __future__ absolute_imports, will make merge proposal.
<xnox> sergiusens: somehow on my image today i didn't have them as click, or maybe i'm just blind =)
<xnox> sergiusens: let me reflash it first.
<sergiusens> xnox, no; different than that; the module has payload data that needs to be copied
<sergiusens> xnox, it used relative data, that needs to be made absolute (joining the module path should fix it)
<sergiusens> ie; http://paste.ubuntu.com/7070697/
<xnox> sergiusens: right, yes. cause the $PWD is not /legacy-py2/, or we can just check if they run under python3
<xnox> sergiusens: and declared the "autopilot" direcotry key to make it run under python3.
<xnox> sergiusens: i wonder if $PWD under python2 should be /home/autopilot/legacy-py2 and /home/autopilot simply added to the pythonpath, to be moe compatible.
<xnox> sergiusens: since python2 tests should not need any changes at all.
<sergiusens> xnox, I say just path.join(module_name.__path__, the_rel_path)
<xnox> sergiusens: ok, more explicit.
<sergiusens> so gallery_app.__path__
<xnox> sergiusens: btw, can you click http://s-jenkins.ubuntu-ci:8080/job/notes-app-ci/275/rebuild ? to get jenkins to recheck https://code.launchpad.net/~xnox/notes-app/py32/+merge/210254
<sergiusens> xnox, ok, just did; but with those results you can imply everything is ok given you write the commit message
#ubuntu-devel 2014-03-11
<xnox> sergiusens: did you see bug #1290492 ?
<ubottu> bug 1290492 in Ubuntu Music App "Impossible to update translations" [High,In progress] https://launchpad.net/bugs/1290492
<sergiusens> xnox, I haven't... and qmake :-/
<xnox> =(
<sergiusens> xnox, from what I've been seeing, the sdk hard codes a bunch of stuff all around
<infinity> tvoss: Why does dbus-cpp force g++-4.7 (which doesn't exist on ppc64el)?
<ScottK> cjwatson: Thanks for mentioning git-dpm the other day.  I think I finally found the tool that makes sense to me.
<sarnold> does anyone know off-hand what the deal is with minidlna? upstream renamed the package, I can't find if there is a new debian package, and our trusty minidlna package has been deleted but I can't find a readymedia package..
<rww> "lp #1253071, FTBFS, RC buggy, removed from Debian testing, not ported to libav9" per https://launchpad.net/ubuntu/+source/minidlna/+publishinghistory
<ubottu> Launchpad bug 1253071 in minidlna (Ubuntu) "FTBFS against libav9" [Undecided,Triaged] https://launchpad.net/bugs/1253071
<sarnold> rww: thanks! :)
<pitti> Good morning
<pitti> SpamapS: well, the py version of juju is gone, isn't it? I suppose it could be reactivated (and I really wish it was..), but we certainly shouldn't support *two* versions
<SpamapS> pitti: I should restate. It's unlikely I'll be running juju any time soon. :-P
<pitti> SpamapS: ah :)
<Unit193> Anyone got a link to the bash completion problem in files with spaces?
<sarnold> Unit193: I've seen these two so far: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031  https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1290572
<ubottu> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed]
<ubottu> Launchpad bug 1290572 in bash-completion (Ubuntu) "tab completion skips files when path begins with ~" [Undecided,New]
<Unit193> "file Hogans\ Heroes/Hogans\ Heroes\ Season\ " and it stop there, it's not quite either because if there's more than one one file it'll complete up to the diff, then stop and won't pick back up.
<sarnold> Unit193: is that the behaviour controlled by show-all-if-ambiguous ?
<Unit193> Shouldn't be, defaults used to be fine.
<sarnold> something seems pretty broken anyway
<Unit193> Yeah, I'm holding off the other upgrade, tab complete is too important to me. :P
<sarnold> the amount I've used my trusty vms so far I've only noticed that it doesn't work as I'm used to. heh.
<sarnold> the last time I looked into doing anything with tab completion I got the simple cases done alright but the harder stuff was .. well, harder. I found my head going around in circles while trying to read the more complicated examples.
<sarnold> I'm glad it's not me on the line to fix it :) "everyone downgrade to saucy's bash" wouldn't go over real well. :D
<Unit193> Hah, that's what I did with some python package to fix gcalcli. :P
<pitti> barry: yay, 3.4~rc3 looks much happier now, thanks!
<mitya57> pitti: hi, can you please check what happened to dh-python autopkgtest? update_excuses.html says it's "running" since yesterday, and there is no entry for ubuntu4 upload on public Jenkins.
<pitti> hey mitya57; looking
<pitti> mitya57: the run was started, but yay jenkins hiccup :( /me restarts
<mitya57> Danke!
<pitti> Finished: SUCCESS
<pitti> mitya57: thanks!
<pitti> trusty-adt-dh-python-ppc64el now works, too
<mitya57> Nice :)
<Ademan> For security fixes, is there any hierarchy among LTS releases? (latest LTS gets patch, eventually gets backported to next latest LTS)
<pitti> Ademan: usually all releases get fixed at the same time
<Ademan> pitti: thanks
<Saviq> mardy, hey, there seems to be an issue with signon-ui and google accounts with SSO, it asks me for the google password, which effectively doesn't exist with SSO... I had the account working before, but seems it got unauth-ed for some reason, and I can't reconnect now because of that, any ideas?
<warren> Is anyone familiar with the /etc/init/*.conf files?  I'm trying to exec a command as a non-root user and define a command that runs to stop it.
<RAOF> warren: You're probably looking for the upstart cookbook?
<warren> I see it
<warren> I see post-stop
<warren> but that doesn't seem to be exactly what I want
<RAOF> You want non-root users to be able to start/stop the service?
<warren> no
<warren> I want to exec /path/to/program as a certain non-root user
<warren> and I want to "killall -u nonrootusername" on stop.
<warren> someone suggested "exec sudo -u nonrootusername /path/to/program"
<warren> I suppose that works.
<RAOF> Ah, yeah. That'd be right.
<warren> pre-start and post-stop appears that it would work for the killall
<warren> but there's no command to define stop?
<RAOF> No; stop is SIGTERM
<warren> ok, then I want pre-start and post-stop
<RAOF> (Or whatever you set kill signal to)
<RAOF> You probably want pre-stop, then. Otherwise your thing will already have been sent SIGTERM.
<warren> It's a thing that launches another thing that launches another thing ...
<warren> i didn't write it, I'm just packaging it
<RAOF> So it does its own process supervising? :)
<warren> yeah, and killall -u is good enough ...
<warren> RAOF: thanks
<tsdgeos> what's wrong with bash? i get an error just by tabbing in an empty window :S
<tsdgeos> do you guys get that?
<tsdgeos> bash: words: bad array subscript
<seb128> tsdgeos, bug 1289597
<ubottu> bug 1289597 in bash-completion (Ubuntu) "bash: words: bad array subscript" [Undecided,Confirmed] https://launchpad.net/bugs/1289597
<seb128> it has a sponsoring request as well
<seb128> tsdgeos, you can nag ogra_ or RAOF about sponsoring I guess, they are supposed to be piloting
<seb128> or janimo or rbasak
<tsdgeos> i wonder if that fixes the other billions of regressions i have in tab handling
<tsdgeos> probably not
<tsdgeos> i am half productive since my tab broke
<seb128> tsdgeos, I guess the other ones are https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031
<ubottu> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed]
<tsdgeos> that one and also https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553
<ubottu> Launchpad bug 1290553 in bash (Ubuntu) "tab completion regression in trusty in files that contain ? in name" [Undecided,New]
<seb128> blame doko for uploading the new bash after ff without a ffe and then going on holidays letting stuff buggy
<seb128> he's back next week though, I hope he's going to have a look then
<tsdgeos> wonder if i should add bash-completion to https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553 too
<ubottu> Launchpad bug 1290553 in bash (Ubuntu) "tab completion regression in trusty in files that contain ? in name" [Undecided,New]
 * tsdgeos does
<seb128> I'm pondering reverting the bash update meanwhile, since that's a new version that was uploaded without ffe approval and which introduced regressions
<cjwatson> ScottK: yay
<xnox> seb128: well i presume other people would notice as well. I see a thread on gnu.bash.bug which seems to believe it might be a bug in bash-completion.
<seb128> xnox, "other people would notice as well"? you mean?
<xnox> seb128: as in, it's a bug that i'm expecting to have a hotfix somewhere quick.
<seb128> xnox, let's see, we have the issue for over a week though
<seb128> xnox, it also doesn't change the fact that the new bash was uploaded without a ffe
<cjwatson> There's https://code.launchpad.net/~j/bash-completion/bug1289597/+merge/210089 FWIW
<xnox> seb128: i see a bug filed in launchpad 13h ago, and threads on upstream mailing list very recent, less than a week ago.
<seb128> xnox, I've no doubt it's going to be fixed, I'm not sure what we are arguing about there?
<seb128> cjwatson, yeah, I pointed that to tsdgeos earlier, we just need a patch pilot to do a shift and pick it up for sponsoring ;-)
<xnox> seb128: "I'm pondering reverting the bash update meanwhile" i don't like reverts, especially when people are working to resolve things. Short term it might be quicker to revert, but in the long run it's a waste of resources to not just fix it properly without reuploading revert of the revert.
<seb128> xnox, well, that was a feature update without a ffe
<seb128> which is buggy as well
<xnox> seb128: sure, but uploading reverts is not a solution to the problem - e.g. as to why ffe process was not respected.
<seb128> xnox, just waving hands and saying it's ok to not respect the process is not a solution either
<seb128> but let's not argue about it
<seb128> doko is not even there :p
<xnox> seb128: cjwatson: so executing "complete -r" makes the completion as per bug report work.
<xnox> but i'm not sure what that does, and whether that's suppose to be called from bash postinst?!
<cjwatson>       -r        remove a completion specification for each NAME, or, if no
<cjwatson>         NAMEs are supplied, all completion specifications
<xnox> cjwatson: right, so bash is not broken.
<cjwatson> can't possibly be called from bash postinst, it's a shell builtin
<cjwatson> I mean, can't usefully be called.  it won't magically affect other shells ...
<cjwatson> I would expect that "complete -r" basically just makes the current shell act as if bash-completion weren't installed
<seb128> xnox, btw, are you in the office today? ;-)
<xnox> seb128: are you?
<xnox> seb128: i was in, yesterday but not today. Do you need people in the office poked?
<seb128> xnox, no, but mpt upgraded saucy to trusty and has a non booting machine, just plytmouth and nothing
<seb128> xnox, I was trying to figure out who could help him
<xnox> seb128: =((( he should have upgraded yesterday. cjwatson, jodh and I were in the office.
<seb128> yeah :/
<xnox> seb128: the office support is on holliday today...
<seb128> he started the upgrade yesterday, but has an old laptop with a slow disk, upgrade takes ages
<xnox> cjwatson: seb128: bash-completion appears to fix completion bugs for me. Let me test it more here.
<tkamppeter> OdyX, hi
<pitti> jamespage: is juju-local something which the server team supports and wants bug reports for?
<pitti> jamespage: it falls over quite hard trying to bootstrap containers in current trusty, on bind-mounting the log directory AFAICS (and apparently also on LXC's cgroup warnings, although this could be a red herring)
<pitti> jamespage: or is it deliberately in universe, and a community project?
<jamespage> pitti, it is
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: rbasak
<rbasak> lp:ubuntu/precise/charm-tools appears to have some extra commits on top of the version of charm-helpers that is in precise. I didn't even know this was possible. What's the appropriate action here? Blow it away by uploading the SRU I want, instead? Will that somehow break UDD?
<OdyX> tkamppeter: I fixed the permissions now, should be okay.
<tkamppeter> OdyX, thanks, everything pushed.
<OdyX> tkamppeter: yay, will upload shortly
<rbasak> jdstrand: please could you take a look at: https://code.launchpad.net/~sdeziel/ubuntu/precise/xl2tpd/fix-for-lp1244780/+merge/194247
<rbasak> jdstrand: I'm unhappy to upload because 1) there are three patches, but the bug implies one and the changelog entry describes two; and 2) I'm unfamiliar with the package, and the test case isn't detailed enough for me to follow it. But for my latter objection, I appreciate that this is one of those interop things that needs an affected user to do the SRU verification anyway, and clearly Simon will be able to do it, so it's only a weak objection.
<rbasak> jdstrand: I'd appreciate your opinion. If you think it's good, I can test and upload as-is.
<rbasak> sdeziel: ^^
<jdstrand> rbasak: I agree with your '1'. I think the changelog is too terse and it would be much easier for reviewers if the changelog described everything better
<jdstrand> rbasak: as for '2'-- me too
<jdstrand> rbasak: that said, excepting the changelog being too terse, the other issues I mentioned have all been addressed it seems
<jdstrand> rbasak: tbh, I think that the changelog should be updated and dch -r ran before uploading since the sru team is going to have all the same questions we had when reviewing it
<rbasak> jdstrand: should I JFDI (fix the changelog and upload)? I'm never sure what to do in this kind of case - I don't want to modify Simon's entry yet still leave his signature.
<rbasak> (OTOH, I don't want to use mine and take his credit away)
<rbasak> And I don't want to have to make him go and fix it first, either.
<jdstrand> rbasak: I've fixed changelog entries to make them more clear and adjusted timestamps in these situations. if you understand the patches, then sure, makes sense. just mention it in the MP
<jdstrand> let me rephrase-- if you understand the patches well enough to make the changelog clear for the sru team, then sure
<rbasak> jdstrand: OK. Thank you for your help!
<jdstrand> np
<jdstrand> (seems one of the comments in the MP makes it fairly clear)
<jamespage> rbasak, technically that is possible (branch being used outside of packages) but its unusual
<rbasak> jamespage: OK. I'm planning to just upload over the top, since I don't expect those other changes to land anyway (and there's nobody to drive that now)
<rbasak> Laney: would you mind reviewing Gunnar's response at https://mentors.debian.net/package/mythes-sv please? I don't have a Debian hat, but it seems to me that the issues are the same for Ubuntu.
<rbasak> I'm not sure about there being no licence in the source apart from in debian/copyright, even though I understand the notice can from an external source.
<rbasak> And same for preferred form for modification, and the generated thing in the upstream source.
<ogra_> cjwatson, urgh, susie just upgraded her laptop (14.04) and grub seems to be gone now
<ogra_> i end up in win8
<cjwatson> Check she doesn't have -proposed enabled
<cjwatson> I haven't done a matching grub2-signed for the latest upload yet
<cjwatson> Though it's also in unapproved for amd64, so probably not that
<ogra_> i cant get into ubuntu at all
<ogra_> i cant even intercept the boot anymore
<ogra_> and i'm 100% she doesnt have proposed ... she only does auto updates, all other maintenance is done by me
<cjwatson> I think realistically you'll have to figure out something locally with the aid of a rescue image or something before I have any chance at all of helping
<ogra_> iirc xnox has the same device ....
 * ogra_ cant even get into UEFI anymore ... 
<ogra_> sigh !
<ogra_> worst time for that to  happen
<cjwatson> Sorry.  I don't think it's a systemic problem, though, it's not something I've heard other complaints about so far ...
<cjwatson> And 2.02~beta2 has been in trusty for a while
<ogra_> well, she only accepted the reboot u-m offered her after an auto update
<cjwatson> Is the system strange in any other way?
<cjwatson> I suppose it could be https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1272664
<ubottu> Launchpad bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [High,Confirmed]
<infinity> ogra_: I assume you can boot a live image to investigate further?
<cjwatson> But I can only guess wildly
<Laney> rbasak: I'm on me hols now, so I won't be able to get to that until next week (sorry Gunnar)
<Laney> rbasak: But yes, I think the issues are the same
<ogra_> infinity, i could but need to do some errands before diving into UDS :P
<Laney> debian/copyright can document the state even if it's not in the orig tarball
<ogra_> cjwatson, infinity, so the BIOS was apparently re-set
<Laney> rbasak: He pointed to another package - you could check if that has only the generated files or the inputs too
<Laney> and it doesn't matter if you don't have Debian upload rights; you can still do a review which will be useful for the person who does come to upload it
 * ogra_ finally got into the bios ... the EFI order was re-shuffled for whatever reason
<OdyX> tkamppeter: uploaded 1.0.47-1 now and prepared cups for oldstable and cups-filters for stable. AFAIK cups in lucid is affected through debian/local/filters/pdf-filters/pdftoopvp and cups-filters is affected in all Ubuntu releases.
<rbasak> infinity: would you mind reviewing/uploading dannf's MP in https://code.launchpad.net/~dannf/ubuntu/trusty/flash-kernel/m400/+merge/208705 for flash-kernel please? ltgm, I also trust dannf anyway, and it's yellow in the queue.
<rbasak> (I haven't tested it or anything)
<rbasak> (I presume this is one of the ones that relatively few sponsors will be comfortable uploading)
<dannf> rbasak: thx
 * dannf meant to poke about that today
<infinity> rbasak: Yeah, can look in a sec.
<rbasak> Thanks!
<Logan_> morning, all :)
<jamespage> pitti, juju is still in MIR so its all in universe
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<infinity> tvoss: *poke*
<jcastro> barry, FYI: https://bugs.launchpad.net/charms/+bug/1199052
<ubottu> Launchpad bug 1199052 in Juju Charms Collection "New charm: mailman" [Undecided,Incomplete]
<barry> jcastro: sweet
<pitti> jamespage: ah, seems it's due to me not using /var/lib/lxc, so not affecting the default case; I filed it as bug 1290920 anyway
<ubottu> bug 1290920 in juju (Ubuntu) "fails to start container with local provider with non-default LXC path" [Undecided,New] https://launchpad.net/bugs/1290920
<jamespage> pitti, ack
<bdmurray> jibel: I was looking at bug 1286161 again and tried to restore the clone file and it failed badly
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,New] https://launchpad.net/bugs/1286161
<ogra_> pitti, did anyone talk to you about the ofono-phonesim dbus issues we had while you were away (and the .crash files we get in the dailer-app tests due to that) ?
<pitti> ogra_: no, not so far
<ogra_> oh
<ogra_> pitti, since the switch to py3 we get tracebacks for many of the ofono scripts during testing
<pitti> ogra_: ah, interesting; is there a bug for it?
<ogra_> xnox worked around two of them but there is something more essential broken it seems so we stopped there
<pitti> ogra_: UDS session now, TTYL
<ogra_> pitti, same here :)
<ogra_> just wanted to know if you had been pointed to it already, we can talk tomorrow :)
<xnox> pitti: i did file a bug against apport.
<xnox> pitti: after the double-hangout we can quickly chat about it =)
<ogra_> xnox, tomorrow is enough too ... it will be late already after the double HO :)
<mdeslaur> tkamppeter: do you have an example command line I can use to test pdftoopvp?
<tkamppeter> mdeslaur, no, but I can ask Tim Waugh who has sent me the info about the vulnerabilities.
<mdeslaur> tkamppeter: I just want to make sure it works, not necessarily test the exact security issue
<mdeslaur> tkamppeter: I don't know what to specify as opvpDriver=
<Wellark> hmm.. guys, how do I get this landed? https://code.launchpad.net/~kaijanmaki/connectivity-api/ci-testrun/+merge/202958
<Wellark> the project is not in the archives yet
<Wellark> I just need to get that MR to the trunk
<Wellark> then after that I need the trunk to be included in universe
<Wellark> this is unity8 dependencies so AFAIK there is a top level FFe in place
<juliank> pitti: I'm a bit confused. You wrote in bug 1288171 that python-apt fails on some pyflakes tests. We run those tests during the build, and all builds were successful (and thus, pyflakes ran successfully on the build servers), so I wonder what's happening.
<ubottu> bug 1288171 in python-apt (Ubuntu Trusty) "0.9.3 regression: Setting APT::Architecture now downloads wrong indexes" [High,Fix committed] https://launchpad.net/bugs/1288171
<juliank> It's really strange that our tests run succesfully during the build on both Debian & Ubuntu, and the same tests fail in different ways when running from autopkgtests.
<pitti> juliank: yeah, indeed; I have a closer look tomorrow morning
<pitti> (UDS session ATM)
<pitti> juliank: https://jenkins.qa.ubuntu.com/job/trusty-adt-python-apt/72/ARCH=amd64,label=adt/console
<pitti> juliank: perhaps during build you don't run tests/old/ ?
<pitti> juliank: and in debian http://ci.debian.net/#package/python-apt it's differently broken
<juliank> pitti: They are not run, never. We run exactly the same tests during build and autopkgtest. The test tests/test_pyflakes.py fails, on autopkgtest, but not during the build.
<juliank> But better get back to that UDS session then...
<pitti> juliank: oh, but pyflakes might see tests/old/ and complain about those
<juliank> pitti: Right, and we filter them out in our test_pyflakes.py script, and do not pass them to pyflakes.
<pitti> juliank: ok, no off-hand idea without a closer look; I'll check tomorrow morning
<juliank> OK, thanks.
<molgrum> sorry if this is the wrong channel but it seems like a dev question, is radeon.dpm=1 planned to be enabled by default any time soon or is it too experimental yet?
<pitti> xnox: to resume, you filed a bug against apport for the ofono python3 conversion?
<pitti> xnox: oh, you mean bug 1287628?
<ubottu> bug 1287628 in dialer-app (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,Confirmed] https://launchpad.net/bugs/1287628
<pitti> xnox: I'll have a look at that tomorrow
<pitti> ... or Thursday, given patch pilot/UDS/etc.
 * pitti waves good night
<xnox> pitti: that's a fix to tests in dialer-app, yes.
<xnox> pitti: the "python3-apport not catching python2 crashes bug" is bug #1287659
<ubottu> bug 1287659 in apport (Ubuntu) "python2 crash traceback was not caught, yet python3 one was" [Undecided,Confirmed] https://launchpad.net/bugs/1287659
<xnox> upgraded from bad corsair vengeance memory to corsair beast. Didn't do benchmarks yet, but it appears to be faster and more stable \o/
 * xnox is happy on my desktop again.
#ubuntu-devel 2014-03-12
<teward> infinity: ping
<xnox> balloons: hey!
<xnox> balloons: what's up with releasing music app and calendar app?
<psusi> whoa... just noticed today at the vuds there was a discussion on switching to systemd... when the heck did this come about?  I see nothing on -devel about this and last time it was brought up everyone said we would be sticking with upstart... and debian just decided to go with upstart, so... wtf?
<psusi> ( and I think their decision was based in large part on our viewpoint on the matter )
<sarnold> psusi: http://www.markshuttleworth.com/archives/1316
<rww> debian went with systemd...
<psusi> what?  I swear I read last week on lwn they went with upstart
<rww> good to know if i ever need a contact from an alternate dimension i have one, tho
<rww> psusi: you didn't :P
<sarnold> "weekly world news" rather than "linux world news" perhaps? :)
<psusi> I swear they kept saying upstart was completely expected because we were dead set on it and half the debian tcce was ubuntu developers and that it finally went that way last week
<psusi> I certainly can't find any mention on ubuntu-devel about going this way lately
<rww> the other half of the debian tcce, including the one with the casting vote, didn't go upstart. so, systemd.
<psusi> I'm not opposed to it, I actually have felt for some time that it would probably be better to follow what most other distros are doing in that area, but it feels like a total shocking about face
<rww> i expect there wasn't much external discussion ubuntu-side, seems like sabdfl made an executive decision there (which is better than having another argument on this side of the fence would have been imho)
<psusi> it's giving me a bit of whiplash
<rww> hehe
<RAOF> psusi: Well, looking into switching. Possibly by 16.04 if it looks easy, probably in 16.10. :)
<RAOF> psusi: So, whiplash in ~2 years time or so, perhaps :)
<psusi> well, with two whole years until 16.04, I'd hope we could get it done in that time frame ;)
<psusi> especially with debian going that route
<jrwren> is it really that big a deal?
<psusi> it requires all system service type packages to be fixed to ship systemd config files instead of upstart, which is what we had to do when we moved to upstart from sysvinit
<rww> haven't other distros done most of the hard work there for us?
<jrwren> so its been done once, it will be even easier the second time :)
<psusi> probably, yea
<rww> i know i've been able to boot with systemd on debian testing for quite a while
<Unit193> rww: Part of that is that systemd still works with init scripts.
<psusi> I've been wanting to play with it for a while now but never got around to it... and the way the devs keep trying to strongarm things like udev into it in an inseperable way, and refusing to support !linux was starting to turn me off
<rww> Unit193: yep. iirc i ended up with surprisingly few of those
<psusi> hell, I haven't been paying attention to our initramfs for some time.. did we ever put upstart in there?
<infinity> psusi: No.
<psusi> it's getting a bit confusing with some form of init now possible in the initramfs, system startup, and session startup ;)
<infinity> psusi: And I still think systemd-in-initrd is the wrong thing too, but upstream disagrees. :P
<psusi> I'm not so sure... we do have several serious and long standing bugs that could be solved by that
 * psusi looks at degraded md/lvm/crypt/etc
<rww> infinity: how come?
<infinity> rww: I'm not fond of the "shove everything in initramfs, it's the new /" mentality.
<infinity> Which was the driving force behind the /usr merge.
<psusi> it's a brave, new, plug and play world though, and that has not jived well with shell scripts in initramfs
<infinity> It entirely discounts systems where you don't want an initrd, systems where loading the initrd is incredibly expensive, so you want to keep it small, etc.
<psusi> I thought it handled !initrd systems too
<infinity> psusi: If initramfs is the new /, it only handles non-initrd systems if you use one filesystem.
<infinity> (But, yes, that's the most common configuation today)
<infinity> And, if you run Fedora, it's the only configuration, cause / is dead. :P
<psusi> ohh... yea.. I guess you did used to be able to have enough in / and not /usr to fsck the root fs and *then* initialize the rest of the system... I can't really find a reason to care about that though ;)
<Unit193> Should also make it take longer to compress the initrd, having dropbear and cryptsetup makes it slow enough as it is.  Also, the possibility of breakage...
<infinity> psusi: No, and neither can Lennart, and our new overlords believe that if they don't value a use-case, no one should.
 * infinity isn't bitter.
<psusi> true
<TheMuso> And thats my gripe. We are a little closer to being controlled more by our overlords.
<TheMuso> I can live with the decision though.
<psusi> indeed, that's the one reason why I've been a bit turned off on systemd lately, even though I originally thought his ideas really sounded good
<infinity> I think following suit with Debian here is absolutely the right decision.  I'm less certain that Debian made the right decision.
<psusi> he's a bit too dictatorial
<TheMuso> Yep I feel the same.
<psusi> indeed
<infinity> psusi: Try having a conversation with him.
<infinity> psusi: (don't, if you value your sanity)
<psusi> I have the same problem with David Zuthern and udisks
<infinity> But udisk isn't trying to eat all of early userspace.
<psusi> and all this is making me suspicious of kdbus
<StevenK> kdbus will solve every problem that ever existed.
<StevenK> Apparently.
<infinity> And, while this is meaningless to Ubuntu, I'm really non-plussed about tying the larger GNU/GNOME/KDE/etc userspace to Linux, which it never had been before.
<rww> it starts with k, so it'll probably be good
<TheMuso> I for one, welcome kdbus if it means better performance.
<TheMuso> Yep agreed, just because I'll likely never use BSD, doesn't mean they should get dropped like a sack of potatoes.
<psusi> it sounds great for dbus users... I just don't see why everything has to be done with dbus... the unix way is to run a small, stand alone executable, and the mass push to convert everything to dbus just feels like the way Microsoft puts everything in dlls
<psusi> indeed... especially if there are some bsd users that are willing to write and maintain patches to support it, there's no reason to refuse to accept them
<TheMuso> But afaik it has solved security concerns with IPC, but my understanding may be missing the mark.
<infinity> psusi: We put everything in DLLs too...
<sarnold> to be fair, I've heard the opensolaris 10 stuff described as "sun / oracle put all the functionality in libraries" ...
<infinity> psusi: In fact, if all of the systemd functionality was in libraries, I'd have very, very few complaints.
<RAOF> A lot of it is; just private libraries.
<infinity> psusi: But instead, they do things like the "single cgroup writer" fiasco in the systemd binary itself, and tell us all the get stuffed.
<infinity> RAOF: A library I can't reasonable leverage isn't a library worth discussing.
<RAOF> Absolutely.
<infinity> s/reasonable/reasonably/
<psusi> why use a library when exec works fine?  gparted is still quite happy to run mkfs, fsck, etc instead of running libraries in process
<RAOF> I presume once systemd settles down all those things will end up as real, honest-to-god libraries with actual ABIs and stuff.
<psusi> but gnome-disk-utility has to have everything cross the dbus and be run in a server... I dunno... just seems like a lot of unneeded complexity
<StevenK> RAOF: If history is anything to go by, I doubt it.
<infinity> psusi: I'm not particularly fussed about if your coupling method is exec() or ld.so, but I'm a big fan of sane reuse of small components, somehow.
<sarnold> RAOF: "actual ABIs", I like the optimism...
<psusi> true
<infinity> RAOF: That seems pretty much completely counter to what Lennart and Kai want, so I doubt it.
<RAOF> infinity: init will eventually be boring, and the adults can take over :P
<RAOF> </joke>
<TheMuso> Yep, aka how Lennart left pulseaudio development without saying anything.
<sarnold> it -was- boring, once, when it was just thirty lines long..
<RAOF> Yeah, but it was boring and seriously underpowered. There'll come a time when it'll be boring and feature-complete.
<infinity> RAOF: Ahh, like Emacs, which never sees any new develop-- oh, wait.
 * psusi just hopes he can finally get debian+ubuntu off of parted 2.3
<infinity> RAOF: Anyhow, init will never be boring as long as systemd keeps finding new bits of userspace to absorb.
<lifeless> point him at launchpad
<infinity> RAOF: When you're linking everything against systemd-libc, using systemd-gcc, spinning up systemd-qemu to try something on another arch with systemd-gdb, maybe it'll be feature-complete.
<psusi> lol
<psusi> I still say udisks has no buisiness configuring things like drive standby timers, while at the same time being a demand start service
<infinity> RAOF: On the plus side, I assume that systemd-wayland becoming inextricably linked will put a rest to this pesky Mir thing.
<rww> psusi: don't worry, systemd-udisks will fix that
<psusi> lol
<psusi> one of these days I'm going to fix those broken udisks standby timers, and convert it to use the new kernel runtime pm
<RAOF> Yeah, please do so!
<psusi> probably after I get my kernel patches accepted to avoid spinning up little used disks at all after system resume
 * psusi wonders where lamont has been hiding
<pitti> Good morning
<shadeslayer> hi, whom do I contact regarding updating the libaccounts-qt package?
<shadeslayer> since it seems to be updated by a bot which hasn't updated it in over 4 months
<ogra_> shadeslayer, try mardy
<shadeslayer> mardy: poke poke @ libaccounts-qt package
<shadeslayer> mardy: next KDE SC release that we want in Trusty requires libaccounts-qt 1.11 , current package reports version 1.11 but doesn't have a header that's require to build things
<shadeslayer> since this is a snapshot of the 1.11 tree, I would argue for an update to the final release
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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
<shadeslayer> morning pitti :D
<pitti> hey shadeslayer, how is it going?
<shadeslayer> good, packaging a new KDE SC :)
<shadeslayer> pitti: how about you
<pitti> shadeslayer: quite fine, thanks! enjoying the spring, not enjoying fighting QA infrastructure :)
 * shadeslayer sighs about not being able to enjoy spring from work :(
<shadeslayer> pitti: just get loads of coffee and fix it when you get a sugar rush :P
<shadeslayer> or caffeine rush, or both
<pitti> shadeslayer: I'm not a coffee drinker, but a big enough hammer will do :)
<shadeslayer> hah :D
<pitti> slangasek: I took the liberty of applying the "isolation-machine" autopkgtest fix for systemd-shim in Debian's collab-maint
<pitti> slangasek: so we are back in sync
<pitti> Launchpad, where are thou?
<edward> https://apps.ubuntu.com/cat/applications/precise/kipi-plugins/ <-- formatting on this page looks broken
<edward> Missing newlines.
<bluesabre> greetings ubuntu-sponsors
<bluesabre> I'm seeking sponsorship for the following package:
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291324
<ubottu> Launchpad bug 1291324 in light-locker-settings (Ubuntu) "[needs-packaging] light-locker-settings 1.0.1" [Undecided,Confirmed]
<bluesabre> Please let me know if there are any changes that need to be made
<pitti> bluesabre: I'll have a look
<pitti> bluesabre: the changes look quite a bit more intrusive than a microrelease update suggests..
<bluesabre> thanks pitti
<pitti> bluesabre: but still okayish, I'll look at the diff
<bluesabre> thanks, functionally its the same, it was a cleanup to be sure
<GunnarHj> pitti: Hi Martin!
<pitti> hey GunnarHj, how are you?
<GunnarHj> pitti: Fine thanks, how about you?
<GunnarHj> pitti: See that you are piloting. Any chance that you can take a look at bug #1284701? Laney did a first review at mentors, but he's on holiday this week.
<ubottu> bug 1284701 in Ubuntu "[FFE] Please upload mythes-sv to the archive" [Medium,In progress] https://launchpad.net/bugs/1284701
<pitti> GunnarHj: great, thanks! just sponsoring your locales patch :)
<GunnarHj> pitti: Aha, thanks. :)
<pitti> GunnarHj: yep, it's in the sponsoring queue, I'll get to it
<GunnarHj> pitti: Great!
<pitti> dholbach: can you handle https://code.launchpad.net/~mitya57/ubuntu-sponsoring/bold-fix-for-new-packages/+merge/208961 ? I think you have a much better idea about this than I
<pitti> dholbach: meta-sponsoring FTW!
<mardy> shadeslayer: hi! What header is missing?
<dholbach> pitti, done
<dholbach> thanks
<pitti> dholbach: *hug*, danke
 * dholbach hugs pitti back
 * pitti watches his laptop emitting smoke from all the sbuilding today
<pitti> bluesabre: uploaded, thanks!
<bluesabre> pitti, you're the best! :D
 * bluesabre hopes that doesn't offend the other uploaders
<pitti> bluesabre: *shrug* if it does, and it leads to them sposoring more, so much the better :-)
<pitti> speaking of more, I need more "n"s apparenlty
<pitti> Laney: bug 1290823 should be trivial, mind having a look with your release hat on?
<ubottu> bug 1290823 in Ubuntu "FFe: [needs-packaging] Sync appdata-tools 0.1.7-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1290823
<pitti> Laney: bug 1290291 as well, that looks pretty much "bug fix" to me; but rbasak seems to think it needs release team ack?
<ubottu> bug 1290291 in cmigemo (Ubuntu) "[FFe] Sync cmigemo 1:1.2+gh0.20140306-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/1290291
<rbasak> pitti: ah. I just went with the original subject that said it needed an exception.
<rbasak> pitti: looking at it now, I guess perhaps it doesn't?
<pitti> rbasak: by the description in #5 I would just have synced it
<rbasak> pitti: agreed. Sorry, I should have paid more attention.
<shadeslayer> mardy: moment, let me check
<pitti> rbasak: no worries, it's far from clear in the bug
<shadeslayer> mardy: ../../../../resources/google/../shared/getcredentialsjob.h:27:30: fatal error: SignOn/SessionData: No such file or directory
<shadeslayer>  #include <SignOn/SessionData>
<mardy> shadeslayer: that comes from libsignon-qt5-dev, not libaccounts-qt5-dev
<shadeslayer> uhhhh
<shadeslayer> mardy: http://paste.ubuntu.com/7079296/
<shadeslayer> mardy: so it finds signon but can't find that header, weird, apt-file search says it can find it
<mardy> shadeslayer: weird, the cflags seem to be correct, I see it's using " -I/usr/include/signon-qt5"
<mardy> shadeslayer: possibly unrelated, but I see that that package is mixing qt4 and qt5 libs, which is probably very wrong
<shadeslayer> mardy: how so? it's using  libsignon-qt-dev
<shadeslayer> oh huh
<shadeslayer> /usr/include/signon-qt5 does seem very very wrong
<barry> xnox: are you working on any of the still unported apps?  i want to work on them, but not step on any branches of yours in progress
<pitti> GunnarHj: the licensing of that package is still wrong
<pitti> GunnarHj: doc/Info-en.txt only says MIT and nothing else at all anywhere
<pitti> GunnarHj: so it can't be CC-BY-SA
<pitti> GunnarHj: if it's meant to be, then doc/Info-en.txt needs to be adjusted accordingly
<xnox> barry: i still have a few clicks to convert, i didn't look into deb based ones yet.
<xnox> barry: there is a tweak/hotfix i'm pushing for gallery-app, cause it's blocking landing phablet-tools.
<barry> xnox: cool.  i'll likely pick them off (under FUTURE port/test in the bp) alphabetically.  i already have branches in progress for many of them
<barry> xnox: ack
<xnox> barry: cool! thanks =) add links ;-)
<barry> xnox: of course! :)
<pitti> GunnarHj: replied on mentors
<cjwatson> pitti: the burp sync you sponsored seemed to have incomplete autoreconfage, since it broke ppc64el
<pitti> cjwatson: ah thanks, I'll have a look
<pitti> single-digit sponsoring queue! http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<pitti> cjwatson: odd, I thought --with autoreconf would also update config.*
<pitti> cjwatson: reuploaded the "with autotools_dev", thanks
<pitti> rsalveti: err.. the changelog of https://code.launchpad.net/~boiko/ubuntu/trusty/telepathy-qt5/conf_call_client_side/+merge/210302  is exactly the one in https://launchpad.net/ubuntu/+source/telepathy-qt5/0.9.3-0ubuntu7
<rsalveti> pitti: mind also joining #ubuntu-touch, we discussed that there
<rsalveti> pitti: but basically boiko forgot to update debian/changelog
<rsalveti> he's doing that now
<pitti> rsalveti: ah; so that also needs to be merged with the previous upload then?
<cjwatson> pitti: only if the package is using automake+libtool
<rsalveti> pitti: yeah
<cjwatson> pitti: but there are some cases where the package uses autoconf + AC_CANONICAL_FOO, and in that case config.* is required but isn't updated by autoreconf
<cjwatson> pitti: you might want to combine autoreconf and autotools_dev here
<cjwatson> this is a case when that's sensible
<pitti> cjwatson: yes, that's what I did
<cjwatson> ok, cool
<pitti> -â¦â¦â¦â¦â¦â¦â¦dh $@ --with autoreconf
<pitti> +â¦â¦â¦â¦â¦â¦â¦dh $@ --with autoreconf,autotools_dev
<pitti> buidls fine here on amd64
<pitti> and https://launchpad.net/ubuntu/+source/burp/1.3.48-2ubuntu1/+build/5805268 is at "test", so looks good
<infinity> pitti: Looks more like the autoreconf isn't hitting subdirectories.
<cjwatson> thanks
<cjwatson> yeah, that could be too
<infinity> pitti: The top level configure is rebuilt, relibtoolizes, and config.* updated fine, it's a later subdir that falls over.
<cjwatson> right, so the usual rune for that is something like:
<cjwatson> autoreconf:
<cjwatson>         autoreconf -fi
<cjwatson>         cd subdir && autoreconf -fi
<pitti> infinity: ah, thanks; I relayed that to the Debian maintainer via the sponsoring bug
<cjwatson> override_dh_autoreconf:
<cjwatson>         dh_autoreconf debian/rules -- autoreconf
<PierreF> Hi
<PierreF> I'm trying to sort out the build issue on ppc64el of OpenLAP patch i've submitted on LP #1287730
<ubottu> Launchpad bug 1287730 in openldap (Ubuntu) "openldap segfault on startup with delta-syncrepl MMR" [Undecided,Fix committed] https://launchpad.net/bugs/1287730
<PierreF> (but since I don't have access to ppc64el hardware it's a little complicated :))
<PierreF> pitti: you told in the bug that you can test build on such hardware. Have you some time to look on this issue ?
<pitti> PierreF: I can do test builds, yes; but I know next to nothing about openldap itself
<infinity> PierreF: The openldap/ppc64el build failure is libdb bug, it's in progress.
<pitti> oh, nice
<pitti> the previous version's tests ran fine, and that patch wasn't really intrusive
<pitti> infinity: i. e. we'll just retry the build after a fixed libdb lands?
<infinity> pitti: The previous version went fine because the buildd was running a kernel with 4k pages, this build was on a buildd with 64k pages.
<infinity> pitti: So, yes, once libdb is fixed, a retry will make it happy.
<pitti> infinity: sweet, thanks
<pitti> PierreF: *phew* :)
<PierreF> Good to know :)
<PierreF> thanks
<GunnarHj> pitti: Is the solution to the license issue with mythes-sv to simply state MIT in debian/copyright and disregard what's stated at the web page?
<pitti> dholbach: wow, for the first time ever I actually got "done" with the sponsoring queue -- 4 items left which are non-actionable
<dholbach> holy cow
 * dholbach hugs pitti
<pitti> GunnarHj: that's how it appears to me
<dholbach> you're unstoppable!
<dholbach> great work! :-D
<pitti> thanks :)
<GunnarHj> pitti: Ok, will do that.
<GunnarHj> pitti: And thanks a bunch for your great sponsoring work! :)
<shadeslayer> slangasek: would have been nice to be able to comment on your blog
<shadeslayer> re @ cubox i
<pitti> @pilout out
<udevbot> Error: "pilout" is not a valid command.
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<slangasek> shadeslayer: feedback noted, but I'm not going to install a comment system any time in the foreseeable future :)
<shadeslayer> :(
<shadeslayer> slangasek: anyway, how does it perform?
 * shadeslayer is on the edge of buying one
<slangasek> shadeslayer: I'm still working on the "enablement" aspects and haven't measured its performance at all... I don't even get hdmi out with any kernel except the 3.0 BSP kernel, I don't get USB keyboard with *any* kernel even though other people say that works, and I'm only using the SD card so any conclusions about I/O performance would be invalid
<shadeslayer> slangasek: the enablement aspect is why I want to buy one :P
<slangasek> shadeslayer: I know that it's *supposed* to do HD video out quite well, but right now I'm still tinkering :)
<shadeslayer> :D
 * shadeslayer is very tempted to order one from the March batch
<shadeslayer> s/March/April
<shadeslayer> slangasek: how much did it cost you?
<slangasek> shadeslayer: eh, whatever it says on the website? :)
<shadeslayer> slangasek: just wanted to compare if there was a change in price when compared with the december batch :P
<slangasek> I don't think so
<shadeslayer> hm, ok, might as well order
<shadeslayer> going to use it with owncloud + 4 TB HDD \o/
 * infinity has too many random ARM things littering his desk already.
<mdeslaur> slangasek: does it have drivers for hardware video decoding?
<slangasek> mdeslaur: it's meant to, but I haven't started chasing that side yet - it's possible they're only available for the 3.0 BSP kernel
<slangasek> infinity: ah, but this one's small
<infinity> slangasek: Most of them are.
<infinity> slangasek: Though, small in different directions.
<attente> hi
<attente> i can't boot my machine... i keep getting "The disk drive for /dev/mapper/ubuntu--vg-swap_1 is not ready yet or not present" under plymouth :(
<attente> i installed ubuntu-touch which caused the problem
<attente> on my laptop
<attente> rebooted, causing the problem, removed ubuntu-touch and its dependencies, but still get this error message
<xnox> attente: you shouldn't install ubuntu-touch on your laptop, unity8 / unity8-session* packages are the most you may install.
<xnox> attente: can you boot into recovery? e.g. press shift, get grub menu, select advanced features, select any kernel with (recovery mode).
<attente> xnox: yeah... i'm realizing that now
<seb128> attente, do you have the list of the packages that got included? (e.g /var/log/dpkg.log)
<attente> xnox: i can boot into recovery
<xnox> attente: so you should be able to get root shell, and figure out what's wrong.
<xnox> attente: you may need to mount/remount things rw.
<attente> initctl: Event failed
<attente> /scripts/local-top/cryptroot: line 1: can't open /dev/mapper/ubuntu--vg-root: no such file
<xnox> attente: you don't pass initramfs, so do break=top kernel command line option and figure out why cryptsetup is not mounting your crypt/lvm in the right orders.
<xnox> attente: or boot of a live cd & mount target for easier debug.
<xnox> attente: if it's problem with initramfs, you should be able to boot older kernel/initramfs combo, if you have any around.
<attente> xnox: seb128: ok, works now, i just ended up purging those packages instead of just removing them
<seb128> which ones?
<xnox> attente: lvm2 and cryptsetup?
<xnox> attente: oh, i wonder if you got initramfs-tools-ubuntu-touch installed, which is a borked up initramfs =)
<infinity> If there are packages that break on remove-but-not-purge, that's a bug that needs fixing.
<xnox> (borked up for normal desktops)
<attente> seb128: just all of the ubuntu-touch dependencies
<attente> i'm not sure which package caused in specifically...
<seb128> attente, ok, good that you got it back working in any case
<pitti> awe__: http://git.kernel.org/cgit/network/ofono/ofono.git \o/
<ogra_> pitti, did you fix it first ?
<pitti> ogra_: I don't have any fix at the moment; but of course I'll send patches for stuff that comes up
<awe__> pitti, awesome!  bonus points that we both got added to the AUTHORS list!
<awe__> ;D
<awe__> pitti, much thanks again for your help on this too
<pitti> awe__: no worries
<pitti> I'll look at dialer-app tomorrow morning (UDS/patch pilot today)
 * pitti watches rbasakTV now
<ogra_> haha
<ogra_> does it go "arm ARMARM arm armarmarm ... server" ?
<pitti> ogra_: more like cloudvmcloudvmcloudvmcloudvm ... virt!
<ogra_> heh
<xnox> ..
<xnox> cjwatson: i'd expect each major qt 5.x release to have something major in it ;-) and it did harm us not moving to 5.1 first. We only started fixing 5.1 issues post 5.1 got released, thus those fixes landed in 5.2 only.
<xnox> ditto our 5.2 fixes are landing in 5.3 only.
<xnox> cjwatson: ideally, we'd have touch images with 5.3-trunk available under test.
<ogra_> xnox, ECHAN ?
<ogra_> :)
<xnox> ogra_: yes.
<smoser> slangasek, are we expecting https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079 fix ?
<ubottu> Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed]
<slangasek> xnox: ^^ did you have a chance to smoke-test plymouth yet?
<xnox> slangasek: i didn't test crypt yet. let me do that now.
<dakira> hi. is there any chance on getting updated libimobiledevice packages into trusty? the current ones (1.1.5) don't work with iOS7. I built new packages based on the debian/* files in trusty and the current git master of libimobiledevice. They work nicely. How would one go about getting a new version into Ubuntu? The current version is in main and maintained by Debian maintainers. They won't update until there's a new release of libimobiledevice (which is p
<xnox> slangasek: looks good, still doesn't fix my problem that my boot.log is incomplete.
<tarpman> dakira: you got cut off after "(which is p"
<dakira> (which is probably never).
<slangasek> xnox: oh, what's the issue with your boot.log being incomplete?
<xnox> slangasek: i believe i did attach 10x of my boot.log's basicallly on my SSD laptop, 7 out of 10times it only has like 3-4 of the last jobs in boot sequence that are started and nothing else.
<slangasek> xnox: attached where?  bug #?
<xnox> yeah, trying to find now.
<seb128> dakira, you need a ffe, read https://wiki.ubuntu.com/FreezeExceptionProcess for details
<dakira> seb128: okay. But the question I ask myself is how would one go about the package. Mine is not up to standards, I just did a git clone, copied over and fixed debian/*, updated the changelog and told dpkg-gensymbols to ignore warnings.
<seb128> dakira, do you know if upstream plans to roll a new version or if there are specifics commit we can backport for iOS7 support?
<dakira> seb128: a new version is not on the way, i'm not sure if they are releasing at all anymore (there is only some github activity on iOS updates to support new versions).
<dakira> seb128: The iOS7 support could probably be tracked to a certain commit.
<xnox> slangasek: filed a fresh bug #1291498
<ubottu> bug 1291498 in plymouth (Ubuntu) "only partial boot.log is recorded" [Undecided,New] https://launchpad.net/bugs/1291498
<slangasek> xnox: thanks
<xnox> slangasek: maybe it's expected for one boot.log to be 312 bytes and anothers e.g. 1.5kB
<dakira> seb128: I found the commit: https://github.com/libimobiledevice/libimobiledevice/commit/ec720cc1c30ac3f9b7996575e835565f60ce2b3e
<seb128> dakira, that seems non trivial...
<dakira> seb128: yup. but the current state of libimobiledevice is completely broken (i.e. iOS7 doesn't work at all).
<xnox> seb128: but it is "hardware enablement" iOS users upgrade very aggresively, and thus trusty will not work with iDevices at all without this =/
<xnox> seb128: thus it's even acceptable as an SRU, thus it should be fine for FFe as well.
<seb128> well, I'm going to let somebody who owns an iOS device update
<seb128> xnox, ^
<tarpman> dakira: the news on the homepage figures ios7 should work in 1.1.5 but with some hiccups, which would be resolved in 1.1.6 ... what changed?
<seb128> xnox, sure, I'm not arguing against that, I just can't sanity check that commit from a look and I don't own hardware to test
<seb128> xnox, would be nice if somebody with access to a device could test...
<dakira> tarpman: if your device was ever authenticated and then upgraded to ios7, 1.1.5 does work. If not, you can't get past the "trust this device?" dialog on the phone.
<slangasek> xnox: so, certainly the plymouth-upstart-bridge job will race the rest of the startup
<tarpman> dakira: so no luck for anyone who bought a newer device (ie. ios7 included) then
<dakira> seb128: here's what I built: https://launchpad.net/~mniess/+archive/libimobiledevice/
<dakira> tarpman: exactly. There is no way to get an iOS7 device working on a fresh Ubuntu install
<xnox> slangasek: but plymouth-upstart-bridge should not be "start on (started dbus or runlevel [06])" it should be on "start on startup or runlevel [06]", no?!
<slangasek> xnox: presumably so - I don't know why it's 'on started dbus', maybe it's trying to use the public upstart socket currently and shouldn't?
<xnox> slangasek: i think that's what cjwatson mentioned to me in passing on monday. Let me see if I can fix that up.
<slangasek> xnox: so currently, plymouth-upstart-bridge talks to the system bus, which explains the listed start condition
<slangasek> s/talks to the system bus/talks to upstart over the system bus/
<cjwatson> slangasek: when I wrote plymouth-upstart-bridge, it didn't look as if the private upstart socket was going to be a stable interface, and I felt I shouldn't rely on it
<cjwatson> (arguably I should have put it in upstart rather than plymouth, but that's definitely not worth changing now)
<cjwatson> slangasek: at this point it's probably reasonable to distro-patch to use the private socket, since we're not expecting to have a new interface
<cjwatson> xnox: ^-
<xnox> cjwatson: ack.
<dakira> seb128: is there anything else I can do about the issue?
<slangasek> cjwatson: ah, k.  I wasn't aware that there was ever expected to be a difference between the public and private sockets, other than the root-only / depends-on-dbus-daemon aspects
<cjwatson> it was a private API and I was being a good boy :-)
<seb128> dakira, open a bug on launchpad, add the link to your work/the upstream patch, subscribe ubuntu-sponsors
<dakira> seb128: There is this. https://launchpad.net/bugs/1207812
<ubottu> Launchpad bug 1207812 in libimobiledevice (Ubuntu) "iOS 7, Trust Prompt Looping" [Medium,Triaged]
<dakira> seb128: should I create a new bug?
<seb128> dakira, no, use that one
<dakira> seb128: okay done, thank you.
<xnox> cjwatson: slangasek: 1 file changed, 10 insertions(+), 129 deletions(-) -> and it seems to use upstart private socket now bypassing dbus system bus, but that's with plymouth-x11.
<xnox> let me test this actually works =))))
<xnox> cjwatson: slangasek: please review/test https://code.launchpad.net/~xnox/ubuntu/trusty/plymouth/private-upstart-socket/+merge/210672
<xnox> cjwatson: slangasek: mostly it simply opesn private connection, and kicks off statemachine with listing jobs, without registering any filters/rules/nameowerchanges, since org.freedesktop.dbus interface is not there and none of those are needed.
<xnox> i now get a 6.2kB boot.log starting with "mounting filesystems" =))))
<slangasek> heywow
<slangasek> xnox: I don't have time to test it today; maybe stgraber and smoser can give it a whirl?
<smoser> xnox, interesting. so it turns out that i would never have known i was missing boot.log or data in it.
<smoser> well, we were missing data in it because of bug 1160079
<ubottu> bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079
<smoser> which i REALLY want fixed.
<xnox> smoser: well lp:ubuntu/upstart has a staged fix for bug 1160079
<ubottu> bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079
<xnox> smoser: and now i will be collecting boot.log, even if dbus is not installed.
<xnox> smoser: with my merge proposal.
<xnox> smoser: so, can you test lp:~xnox/ubuntu/trusty/plymouth/private-upstart-socket ? it should fix bug 1160079 _and_ create a useful boot.log.
<ubottu> bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079
<smoser> :)
<smoser> i see what you did there.
<smoser> tricky
<smoser> xnox, yeah, i'll give it a go
<xnox> dholbach: mhall119: sergiusens: running $ webbrowser-app --help; coredumps. Running $ webapp-container -h; also coredumps.
<sergiusens> xnox, interesting
<sergiusens> xnox, but you pinged the wrong people ;) bfiller ^^
<xnox> dbarth: ^ ?!
<bfiller> xnox: I think a fix for that just was proposed
<xnox> bfiller: a manpage would be good, explaining all the options.
<xnox> bfiller: since e.g. http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ is incomplete.
<xnox> bfiller: g+ can use _any_ url hypothetically, due to redirects for 3rd party authentication.
<bfiller> xnox: https://code.launchpad.net/~osomon/webbrowser-app/fix-crash-help/+merge/210655
<sergiusens> xnox, yeah, that's why I mentioned to avoid the containment
<psusi> anyone know how to convince emacs to use hard tabs in sh-mode?  apparently indent-tabs-mode is a C mode thing only
<sergiusens> xnox, only webappUrlPatterns are explained there; not the other one which could potentially allow you to workaround it
<xnox> bfiller: also http://developer.ubuntu.com/publish/webapp/packaging-web-apps/ seems wrong to suggest webbrowser-app instead of webapp-container.
<bfiller> xnox: ack, please file bugs
<slangasek> gah, why is the new bash so terrible?
<ScottK> So it's not "new bash, same as the old bash"?
<slangasek> only if you never use it interactively, I guess
 * ScottK wonders if you're ignoring the pun on purpose or not.
<xnox> slangasek: did you upgrade bash-completion as well?
<jtaylor> xnox: didn't fix it for me
<jtaylor> if the issue is completion not working properly
<slangasek> xnox: yes, but it's not the completion that's messed up
<slangasek> ScottK: I must be missing the pun
<xnox> slangasek: completion is supposed to be fixed with new bash-completion...
<slangasek> xnox: it's not the completion I was complaining about! :)
<ScottK> slangasek: I was trying for a line from the Who, Won't Get Fooled Again. "New boss, same as the old boss".
<slangasek> ScottK: ah :)
<jtaylor> ls ~/Downloads/<tab> just not working for me?
<jtaylor> I have the latest completion update I think
<xnox> slangasek: oh, i see. well, hold that thought about bash and wait for doko to come back from hollidays ;-)
<slangasek> xnox: so the problems I'm seeing are that 'failed reverse-i-search' now doesn't give me sensible feedback that it's failed, but continues to display what I'm typing; and ^C on a wrapped line puts the prompt in the middle of the previous output
<barry> jtaylor: i hit that a few days ago.  it's a bash-completion bug
<jtaylor> oh es that sucks too
<barry> LP: #1288031 probably
<ubottu> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [High,Confirmed] https://launchpad.net/bugs/1288031
<jtaylor> thx
<xnox> slangasek: right, i've noticed both of those.
<xnox> barry: i've fixed completion bug i thought.
<barry> xnox: hey, it looks like you did!  maybe a different bug got closed?
<xnox> barry: hm, though maybe not.
<jtaylor> the changelog bug seems something else
 * barry only tried a simple example
<jtaylor> infinity: do you already have plans how to deal with the glibc miscompile on i386?
<smoser> xnox, hey.
<jtaylor> adding fno-regmove is probably safe and easy, if something else is needed I guess one needs to bisect gcc 4.7-4.8 to figure out where it broke
<smoser> so i'm walking through the same thing i did https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1235231
<ubottu> Launchpad bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed]
<smoser> and i'm seeing (i *think*) duplicate data
<smoser> http://paste.ubuntu.com/7081443/
<infinity> jtaylor: fno-regmove is what I have committed locally.
<jtaylor> oh nice
<infinity> jtaylor: A bit scared that it might be a random fluke that it only manifests on i386, and perhaps it could affect all x86 if enough code shuffles around, but meh.
<infinity> jtaylor: I guess we have a solid test for it, so if it regresses, we'll know.
<jtaylor> its quite possible it has to do with the x87 fpu
<jtaylor> so only i386
<jtaylor> but its probably wise to check what actually broke it
<jtaylor> I can maybe check this weekend which gcc commit it was
<infinity> jtaylor: Well, fixing GCC would be nice.  But since that whole bit has been torn out in 4.9, I'm not massively fussed either.
<infinity> jtaylor: I guess the concern wouldn't be glibc at that point, but the thought that gcc is silently miscompiling other things where we've not been so lucky to catch it. :/
<infinity> (And way too late now, really)
<xnox> smoser: hey.
<smoser> xnox, this is what i'm running right now.
<smoser>  http://paste.ubuntu.com/7081481/
<smoser> you can recreate it if you want
<xnox> smoser: correct, $ echo manual | sudo tee /etc/init/plymouth-upstart-bridge.override
<xnox> smoser: do you want plymouth, or do you not?! =)
<smoser> what ?
<xnox> smoser: also do you happen to _not_ have dbus in the cloudimage?
<smoser> i dont want *two* copies of all messages to the console
<smoser> i dont think anyone does
<smoser> ever
<xnox> smoser: right, so plymouth-upstart-bridge listens to upstart messages (previously over system dbus, now over private socket) and it reprints upstart messages via plymouth.
<xnox> smoser: and also to the console output.
<xnox> smoser: can i see manifest of packages for cloudimages?
<smoser> http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.manifest
<smoser> i have to run. sorry.
<xnox> smoser: no worries, i'll work on it.
<xnox> slangasek: so my "fix" has unwanted consequences on the cloudimages, since plymouth-upstart-bridge prints things to the "console output" it's thus now generating duplicates.
<xnox> slangasek: i wonder if plymouth-upstart-bridge should not run, if there is cloud-init.
<slangasek> hmm, really?
<xnox> slangasek: well, that's my interpretation so far. See the paste from smoser here: http://paste.ubuntu.com/7081443/
<xnox> and steps to repeat: http://paste.ubuntu.com/7081481/
<slangasek> xnox: are you sure the bridge behavior isn't broken for all cases when not using a graphical splash (including Ubuntu Server)?
<xnox> slangasek: good point. let me try to verify that.
<slangasek> oh yuck, we bridge messages about the startpar bridge
<xnox> slangasek: oh, yeah about the startpar bridge, i thought none of that should be printed anywhere _ever_
<slangasek> it really ought not
<jtaylor> hm I'm getting weird segfaults from tk/tcl from python testsuites recently, anyone else seen that?
<jtaylor> maybe bug 1290805
<ubottu> Error: Launchpad bug 1290805 could not be found
<xnox> slangasek: yeah, i'll add further patches to fix this up properly.
<jtaylor> xnox, infinity as you TIL tk8.6, seems we need the fix for this bug in trusty: http://core.tcl.tk/tk/info/f214b8ad5b
<jtaylor> looks like this diff: http://core.tcl.tk/tk/fdiff?v1=35cfb387a8821ec3&v2=039e0a2d49a1ef3c&sbs=1
<jtaylor> else e.g. tk based python-matplotlib apps will crash when you close the plots
<ScottK> jtaylor: Isn't crash on close just a fancier way to get what you wanted anyway?
<ScottK> ;-)
<jtaylor> closing plots != application end
<jtaylor> though some changes in tk8.6 seem to break matplotlib anyway, after the close tk does not autoreinitialize itself :/
<jtaylor> but warnigns are better than  acrash :)
<infinity> jtaylor: http://core.tcl.tk/tk/vpatch?from=8b40f8cacfa04130&to=9fc8df19b1c093ef is slightly more readable (and has a test!)
<jtaylor> let me try that patch
<infinity> jtaylor: Should be the same as what you linked, except for being the full commit.
<jtaylor> yes looks the same
<jtaylor> hm doesn't apply to the package
<infinity> Indeed, 1 hunk fails.  Probably something that moved on in trunk.
 * infinity looks.
<infinity> Yeah, that free got moved out of the brace.
<infinity> s/free/NULL/
 * infinity mangled the patch a bit to account for that.
<infinity> jtaylor: http://paste.ubuntu.com/7081732/ <-- Try that.
<jtaylor> hm still fails for me, I applied this http://paste.ubuntu.com/7081755/
<infinity> Looks a lot like what I was about to apply.  How can I easily test this?
<infinity> jtaylor: Wait, by "fails", do you mean it still crashes, or it still fails to reinit?
<jtaylor> hm python-statsmodels tests fail, I swa it in another package but forgot which one
<infinity> (Like, does this fix anything? :P)
<jtaylor> fails to apply
<jtaylor> the patch fixes the crash
<infinity> Oh.  Doesn't fail to apply here, let me just feed you packages instead.
<jtaylor> your patch has different whitespace, weird it applies for you, but doesn't matter the content is the same as mine
<infinity> jtaylor: Yeah, just going to get you to double-check my binaries before I upload.
<infinity> jtaylor: Because paranoid.
<infinity> jtaylor: amd64?
<jtaylor> yes
<infinity> jtaylor: dget http://lucifer.0c3.net/~adconrad/tk/tk8.6_8.6.1-3ubuntu2_amd64.changes
<jtaylor> infinity: my testcase: sudo apt-get install python-statsmodels; python -c "import statsmodels.graphics; statsmodels.graphics.test()"
<jtaylor> should segfault after about 60 dots
<jtaylor> ~20 sec
<jtaylor> with the fix just a couple warnings and no test failures
<jtaylor> infinity: your packages work, thx
<infinity> Ta.
<infinity> Uploading, then.
<A3D_Damir> kubuntu can make pannel for adds and marketing compannies so when they want to make adds it will be on desktop with option for users to choese branch , section and to remove or show up MARKETING PANNEL
<A3D_Damir> or ubuntu hehehe
<A3D_Damir> ubuntu should have how to  section for users  and most common problems like BLUR  newbeeeeee will throw it when that happen to HIM
<YokoZar> Is apt supposed to interpret "replaces" this way?  I just installed wine1.6 on a system with wine1.7 installed (wine1.7 replaces wine1.6), and apt unpacked wine1.6 before removing wine1.7, resulting in a fake install of wine1.6 without any binaries.
<YokoZar> Or is apt bugging out here and getting the order wrong
<infinity> YokoZar: Replaces refers to file overlaps...
<infinity> YokoZar: So, yes, it's absolutely expected that if you remove the package that Replaces another, you'll lose the files that overlapped, since it now owns them.
<infinity> YokoZar: If you want them to not be coinstallable, you want a Conflicts.
<YokoZar> infinity: they also conflict
<YokoZar> infinity: remove wine 1.7 followed by install wine1.6 results in a different system state than just install wine1.6, but the same package set
<teward> infinity: (1) sorry for pinging you then dying, my internet was being stupid.  (2) NGINX MIR has a debdiff uploaded, sarnold said you're on the MIR team and know the process, care to review my debdiff? (it's based off of the latest stable that we merged in)
<infinity> Hrm, if they conflict too, that's a bit odder.
<teward> (no rush, though :) )
<YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1291668
<ubottu> Launchpad bug 1291668 in wine1.6 (Ubuntu) "Apt installs wine1.6 without its binaries when wine1.7 was on the system" [High,New]
<infinity> YokoZar: Where are these wine1.7 packages?
<YokoZar> infinity: From a PPA (it might matter to apt that the ppa was disabled at the time of the operation)
<infinity> YokoZar: It shouldn't, and this isn't apt at all, it's dpkg.
<YokoZar> oh right
<infinity> YokoZar: Where is this PPA?
<YokoZar> I suspect that apt might be getting its ordering wrong due to multiarch changes or similar weirdness
<YokoZar> https://launchpad.net/~ubuntu-wine/+archive/ppa
<YokoZar> *dpkg
<YokoZar> oh
<YokoZar> maybe wine1.7 doesn't conflict wine1.6
<infinity> That doesn't have the packages from the log.
<infinity> And yes, not conflicting is what I suspect.
<infinity> dpkg interprets Replaces/Conflicts *completely* differently from just Replaces.
<infinity> One is a "tear out package B to install package A" and the other is "overwrite files from B with A".
<infinity>  Conflicts: wine1.0, wine1.2, wine1.3, wine1.4
<infinity> Definitely no 1.6 conflict there.
<YokoZar> Yup, that'd do it
<YokoZar> well, sorta
<YokoZar> They depend on things that conflict
<infinity> YokoZar: Right, which is why the package was eventually removed.
<infinity> YokoZar: But that won't save you from the (correct) interpretation of your relationships. :P
<YokoZar> I think i left out the conflict to make migration to eventual dummy package earlier
<infinity> YokoZar: I'd assume your Replaces and Conflict lines should match.  I don't see a 1.5 conflict either.
<YokoZar> 1.5 was converted to a dummy package
<YokoZar> I have to do dummy packages to do version transitions :/
<infinity> Why?
<infinity> Why not just have a "wine" package that tracks the latest?
<infinity> Which, indeed, you do.
<infinity> So why would you need dummy packages?
<YokoZar> The intended workflow is that wine1.6 and wine1.7 live together as different options, wine gives a default, and packages depend on wine1.7-i386 (or similar) if they need the newer version of wine.
<YokoZar> Then when wine1.8 is out it can provide both of those things
<YokoZar> But if I do conflicts, apt gets confused about the conversion of a former real package into a dummy one and gets in the way of the upgrade
<infinity> wine1.7 Conflicts: wine1.6 << 1.7 ; wine1.8: Conflicts: wine1.8 << 1.9 ; etc?
<infinity> Assuming the dummy package comes from the next wine version.
<infinity> (base)adconrad@cthulhu:~$ apt-cache show wine1.4 | grep Version
<infinity> Version: 1:1.6.1-0ubuntu4
<infinity> Would certainly work there.
<YokoZar> As I understood it, versioning something that then becomes a virtual package eventually is bad too
<infinity> Oh, they move from full to dummy to virtual?
<infinity> Whee.
<infinity> Why the virtual?
<infinity> And is that even true?
<infinity> I don't see anything with a "Provides: wine1.2" (or whatever).
<YokoZar> I'm trying to remember the reasons I ended up setting a lot of this up
<YokoZar> the dummy packages may have just started because the upgrades weren't happening automatically without them actually
<infinity> wine1.6 just Provides: wine
<infinity> No versioned ones.
<YokoZar> wine is also a dummy package in wine1.7 package
<YokoZar> This is an elaborate mess
<infinity> Sure looks like one, yes.
<YokoZar> Built up over several years of workaround installation issues
<infinity> Anyhow, your bug isn't a dpkg bug, it's a packaging bug.  Sorry. :P
<YokoZar> Well, I didn't file it vs dpkg :P
<YokoZar> Sorry my memory about why all this was done is a bit hazy
<YokoZar> But I may get back to you if I run into a catch-22 here
<infinity> teward: Remind me of the bug number?
<infinity> YokoZar: I suspect you might be using the transitional packages because you're trying to force the old ones off the system, and update-manager (or apt in upgrade mode) is pretty grumpy about making sweeping changes that remove a bunch of packages.
<sarnold> infinity: 1262710
<YokoZar> infinity: yes that sounds right
<infinity> YokoZar: But it could take some experimentation to figure out the best path forward.  Still, versioning those conflicts would work fine.
<infinity> YokoZar: Not that that helps people who already have the broken 1.7 installed.
<infinity> (But here's hoping you get them to upgrade before they blow up the world installing 1.6)
<infinity> sarnold: I will say I'm not wildly happy about the "just tear out lua support" option with no real indication of how many people might consider that a useful feature.
<sarnold> infinity: yes, i'm not real thrilled with it either.
<infinity> sarnold: So, this might come back to "why (other than jcastro blogging about it) are we pushing nginx into main in a potentially crippled state?"
<sarnold> infinity: but I'm not particularly keen on supporting two vastly different versions of lua in trusty, and upstream for the nginx_lua module is content to stay on lua 5.1 for eternity...
<sarnold> infinity: if you were to download an nginx tarball from nginx.org, you wouldn't get this module anyhow; they think nginx is useful enough without also trying to turn it into a node.js competitor but with lua :)
<teward> infinity: one moment i have to pull it from my history
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed]
<teward> infinity: i'm not a fan of it either, but the lua module upstream has basically told us they won't port to 5.2
<teward> and the only other alternative would be to try and get luajit-5.1-dev's source package into main alongside nginx
<teward> (that's the only other option that seems to build this, and run it)
<infinity> That's still 5.1 :P
<infinity> And I agree, we don't want two luas in main.
<teward> true statement.
<infinity> I guess the upstream lua dude has chosen his fate.
<teward> infinity: the way to think about this is that the nginx team PPA will always have the Lua module
<teward> until 5.1 is dropped from the archives completely
<infinity> It didn't look *too* hard to port, but I only got about 10% of the way through before realizing I have better ways to waste my time.
<teward> infinity: https://github.com/chaoslawful/lua-nginx-module/issues/343 is the summary of my attempts to get them to try and port it
<infinity> teward: Pointing people at a PPA to get missing options isn't the right answer.
<teward> infinity: nor is stripping modules from the package that we know people use.
<teward> but as i see it we don't *really* have many options.
<sarnold> infinity: cripes, you actually started making that conversion even after reading the changelog between lua 5.1 and 5.2? :)
<infinity> sarnold: The API changes aren't as dire as the nginx-lua people are claiming.
<infinity> sarnold: It's not hard to follow if you've done compiler/VM work before.
<infinity> (Which, to me, should almost be a prereq for writing a mod_lang style embedded language plugin)
<sarnold> infinity: that does seem like a fair enough pre-req :)
<infinity> teward: If we *know* people use the lua modules, the best option is to reject the MIR.
<infinity> teward: The best option is NOT to say "hey, we totally suport a subset of the package that you will NO LONGER USE, but here's a PPA."
<teward> infinity: well, the problem I see is that everyone's expecting the MIR to go through (blame jcastro)
<infinity> That's... Pointless.
<teward> this is a catch-22 here now
<infinity> jcastro: Hey you.  Come have an opinion.
<sarnold> I wish the debian nginx package had never included a bunch of extra crazy crap glued onto the side... sigh.
<infinity> jcastro: Or, come have mine.
<xnox> infinity: i thought nginx lua is about as reliable as Randall's opinion on haskell https://xkcd.com/1312/
<infinity> sarnold: To be fair, the lua module is extra crazy crap that upstream includes.
<teward> infinity: jcastro was the one who jumped-the-gun and said it was probably going to get into main.
<teward> and later updated saying it might not, but it's still likely to
<infinity> sarnold: I'm fine with dropping the third party modules, but it's not really a stretch to say that people probably expect the upstream stuff to be there.
<infinity> sarnold: Imagine if I gave you a "LAMP" server but, well, left out mod_perl, mod_python, and mod_php, and said "well, it's LAM... You don't need the P".
<teward> infinity: TBH the nginx people direct people to the PPAs anyways
<xnox> i think it's totally fine to disable lua, and redirect people nags to upstream "look they don't support lua" and cherry-pick lua module support whenever it gets written.
<teward> heck, even I do that in #Ubuntu-server because people are demanding spdy3
<sarnold> infinity: I asked for the extra binary packages because I didn't want two source packages, but we -could- go that route: one source package for nginx-core and nginx, one source package for all the other crazy crap that stays in universe. it's not an awesome idea but .. sigh.
<teward> and that won't be in here anyways.
<teward> (that's only nginx mainline)
<teward> (and that's not even in Debian yet)
<sarnold> xnox: it's harder because nginx won't dlopen() load modules; they have to built in at compile time.
<infinity> xnox: How is that better than the status quo, which is "it all works just fine, but we don't officially support it"?
<infinity> Seriously, I just see zero point in "supporting" things if we admit we're just going to point people to upstream packages and PPAs.
<xnox> smoser: i can't reproduce your bug. in the script you pasted you prepare "disk.img", boot "disk1.img", pull boot.log from "disk.img".
<sarnold> we'd be pointing three people at it, not everyone :)
<infinity> It's a press release bullet point, but it's otherwise a waste of everyone's time and makes us look pretty crap.
<xnox> smoser: after fixing that up, it's consistent output, without dupes.
<infinity> sarnold: Sounds like more than three people get pointed there.
<teward> (general note: if the MIR *is* rejected I'm going to go to jcastro and basically do the internet equivalent of yelling "I told you this might happen" at him for jumping the gun)
<infinity> sarnold: (see teward's comment about upstream pointing people to PPAs too)
<teward> infinity: um...
<teward> you missed my point
<xnox> infinity: we support lua?! =)
<teward> the reason we point people to the ppas is because of the spdy demand
<sarnold> infinity: oh you know how upstream authors are, they always want people to just run their tarballs. :)
<teward> not the lua
<infinity> teward: Sure, I think you missed my point.
<teward> infinity: i saw it and dismissed it.  at this point i'm on the fence about the MIR
<infinity> teward: This isn't *just* about lua.  This is about "why is it going to be officially supported if people aren't running it?"
<infinity> xnox: Yes, we support lua.
<teward> infinity: true.  honestly, I could care less which way this goes, it's a catch-22 regardless of what we do
<infinity> xnox: Just not 5.1
<teward> people're going to complain regardless.
<teward> infinity: and there-in lies the catch.  waht's the reason for not supporting 5.1, again?
 * teward doesn't follow the entire -devel list, so missed some things
<infinity> teward: Because supporting multiple versions of things becomes exponentially pain-in-the-assicult.
<teward> that doesn't explicitly answer my question
<infinity> teward: We don't tend to have multiple versions of much of anything in main.  Except GCC, cause it's a uniquely annoying snowflake.
<infinity> teward: Sure it does.  We support 5.2.  We don't support multiple versions.  5.1 is another version.
<infinity> teward: The upstream hilarity of "we want people running cutting edge software, so we don't care what crusty LTS distros do" is wonderfully ironic, when they insist on using a many-year-old version of lua.
 * teward sighs
#ubuntu-devel 2014-03-13
<xnox> infinity: i'm confused, the only things in main that pull-in lua are ibus-pinyin, librpm, vim-gnome, libquvi7, if it's purely due to extensions I'd argue strongly for pushing _all_ lua into universe.
<teward> i'm just going to go write up the "jcastro: thanks for making everyone think something way ahead of being able to make a statement to the effect of the one you did" rant now... and let you argue it out, i don't particularly care anymore which way the MIR goes.
<infinity> xnox: You can argue that all you want, but it's not really going to help this conversation.
<sarnold> teward: I don't see much point in pointing figures at jcastro, fwiw..
<xnox> the technical solution here is to port nginx to 5.2 =))))) and no conversations would be needed...
<infinity> Agreed.  Looks like probably about an hour of research, an hour of Googling, a few hours of code and, then, the hard part, validating it.
<infinity> I can't do the latter, cause I don't actually use it.
<infinity> Not have any idea how.
<infinity> s/Not/Nor/
<sarnold> .. and then you'd wind up with a module that can't actually execute the code that the users have written for it, because they wrote their code for lua 5.1, which might as well be known as "lua classic" or something, compared against "new lua"..
<teward> sarnold: i haven't stopped pointing fingers at jcastro since he posted two days after the MIR was filed that nginx was going to be in main
<infinity> It's also nowhere near the top of the list of things I care about doing before release.
<infinity> sarnold: See, people claim that, but the language doesn't appear to have changed THAT much.
<teward> infinity: i can get you a list of examples to test, to see if it interprets Lua.  I can't give you Lua applications to fully test the module though.
<infinity> sarnold: But there is also the third (fourth, fiftfh, I've lost count) option of admitting that lua5.1 is important enough to people to support it for trusty.
<sarnold> infinity: true, without having made the change to naything I care about I can't really judge how much effort it is
<teward> although if I put out a few requests to certain individuals i could probably grab a ton of examples
<teward> s/examples/test code/
<sarnold> infinity: true. lua 5.1 is probably "done" by now anyway, what with being ancient :)
<infinity> sarnold: lua5.1 was in main up until saucy.
 * infinity suspects this was a doko-initiated "bigger versions are better!!" transition...
<sarnold> infinity: *sigh* that just might be the least annoying path forward.
<sarnold> bigger isn't better? :)
<xnox> sarnold: well lua5.1 is supported for another 3 years on precise =)
<sarnold> xnox: <3 :)
<sarnold> that would make it a little less bitter pill to swallow, what's another two years? heh
<xnox> sarnold: and in 3 years time, we can debate about SRUing nginx to compile against 5.2.
<xnox> sarnold: at least we only have 2 pythons in main (2.7 and 3.4).
<infinity> sarnold: Worth noting that we've done exactly zero security or SRU releases for lua.  Ever.
<sarnold> infinity: yay :)
<sarnold> xnox: hoooray for that indeed :)
<infinity> xnox: SRUing it to change the lua version would be Bad.
<infinity> What we ship is what we're stuck with.
<sarnold> but we can debate it all the same, right? :)
<infinity> The language didn't change a lot, but it *did* change.
<infinity> You don't break people's interpreters in a stable release.
<xnox> infinity: sarnold: bug shipping nginx with lua opens up attack surface. Previously it only was things like vim-gnome that used lua in main =)
<xnox> s/bug/but/
<infinity> Shipping daemons opens attack surface.  Let's stop.
<sarnold> xnox: that's the most hilarious part; the actual nginx_lua module will live in a binary package that is in universe.
<xnox> sarnold: oh exelent, that's about as good as we supported libav ;-)
<sarnold> xnox :)
<infinity> sarnold: Honestly, I think re-promoting lua5.1 is probably the least icky option here.
<xnox> it was in main as a build-dep, but not much else.
<infinity> sarnold: I already find the extra binary distasteful, but at least that one is simple, we can direct people to -core for supported, or -full to be like Debian.
<sarnold> infinity: agreed, you talked me into it.
<infinity> Alright.  Let's do that, then.  I'll review teward's current patchset, re-add lua, and we'll go from there.
<infinity> We all agreed?
<infinity> Well, all except xnox, who seems to be on random tangents.
<sarnold> yes, do you want any comment in the bug from me about it?
<teward> infinity: i can revise the debdiff if you'd like, remove the "Drop lua" bits.
<teward> (for nginx)
<teward> i need a copy of that locally anyways
<infinity> teward: I can do that myself faster than you can, don't worry about it.
<teward> infinity: awesome.  :)
<teward> (I had the debdiff on screen though :P)
<infinity> teward: If I find any bugs in your current patches, I'll just fix them and pretend you did.  I'd rather get this behind us than do more back and forth.
<teward> infinity: awesome.
<infinity> sarnold: Sure, if you want to summarize the last thousand lines of pointless drivel in a few grunts and smiley face, that would be great.
<sarnold> infinity: great, will do
<infinity> teward: When you re-did your debdiff, you didn't take into account the new common_configure_flags setup in debian/rules.  Will fix.
<teward> infinity: oops.  i missed that.  thanks.
<teward> infinity: i have to disappear for a bit, but messages are logged so feel free to continue to point out mistakes I made, and I'll see them later.
 * teward disappears
<infinity> teward: You also did a straight copy/paste of the debhelper files without s/full/core/, so you were installing the full binary into the core package. :P
<teward> infinity: eheheh, whoopsies.  serves me right for debdiff-ing late at night
<teward> s/late at night/when tired/
<teward> infinity: i should probably just learn that lesson and be done with it
<teward> infinity: thanks though for pointing out my mistakes.  :)
<jdstrand> infinity, sarnold: re lua updates> sounds like we are due. istr a similar argument made for erlang btw. and that is a pita to update
<jdstrand> I am not weighing in on the argument, sarnold can make the call. just saying I've heard it before
<infinity> jdstrand: Personally, I think the upstream view is purely based on them not having the clue to do the porting, but I don't have the time to JFDI and send them a patch.
<infinity> jdstrand: But given how much security support we've never given lua in the past, I think we can continue with that stellar track record. :)
 * teward laughed too hard at that xD
<sarnold> huzzah! celebratory beers all around :)
<teward> s/beers/shots/
<sarnold> speaking of erlang, 17.0 looks due on 2014-03-26...
<infinity> I refuse to believe anyone uses erlang.
<infinity> Then again, everything I know about Lua, I know from hacking WoW modules.  So, what do I know about languages? :P
 * elmo pulls a rabbitmq out of a hat for infinity 
<sarnold> lol :)
<infinity> elmo: What, no couchdb?
<bluesabre> pitti, others: I missed a minor detail in my package this morning, can we sponsor this updated package?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291699
<ubottu> Launchpad bug 1291699 in light-locker-settings (Ubuntu) "Please add python-psutil to Depends for light-locker-settings" [Undecided,Confirmed]
<YokoZar> Is it too late to fix this sort of thing?  https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1027299   (I'll note we did a similar SRU backport ofgnome-keyring https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600)
<ubottu> Launchpad bug 1027299 in p11-kit (Ubuntu) "Seperate out p11-kit-trust.so into a multiarch package to prevent errors in Wine" [Undecided,Confirmed]
<ubottu> Launchpad bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,Confirmed]
<RAOF> YokoZar: Given that we've SRUd in multiarch support I don't see why it shouldn't be possible to get multiarch support a FFe.
<infinity> sarnold, teward: Alright, for better or worse, it's uploaded and promoted.
<dobey> RAOF, YokoZar: i think the issue isn't whether it's too late, but more about supporting of upgrades
<sarnold> infinity: thank you :)
<sarnold> teward: thank you :)
<dobey> YokoZar: at least if you're talking about getting the keyring backport to precise
<YokoZar> dobey: I'd be happy with trusty honestly
<YokoZar> For p11-kit
<jcastro> sarnold, infinity, teward, hi guys.
<dobey> YokoZar: i don't think it's too late to multiarch something, no
<jcastro> hey so, my blog post pointed out that the MIR was filed, and Ars Technica posted their story that it was a done deal.
<dobey> i don't know that i'd even say you must have an FFE approval for multi-arching a package
<infinity> jcastro: Yeah, no real harm done, just an annoyance.
<jcastro> so I edited my post to make it clear that the MIR had started, I didn't make any promises or anything other than pointing out that a MIR had been filed because hey, someone filed a MIR.
<infinity> jcastro: Though, it might pay to not blog about process, since people always misinterpret "we're considering" as "we're doing".
<dobey> YokoZar: i'd just call it a bug fix
<jcastro> infinity, true that.
<infinity> (This is one of the fundamental issues I've always had with blueprints too, the notion that once someone's written down intent, it's going to happen)
<jcastro> infinity, but hey, all the work is done in the open, and if we come back and say "you know, we looked at all  the issues people had, and here is what blocked it." that's fine
<infinity> YokoZar: If it's done sanely and tested, I'd approve an FFe for that.
<dobey> infinity: the best part about blueprints is you can't delete them or anything, and anyone can create one! :)
<infinity> dobey: ANYONE.  Trust me, I know.
<jcastro> the entire MIR process is public, and if something didn't make it, then fine. We know why it didn't, it's clearly documented, given X resources and X time, that's how the world works
<dobey> jcastro: just disavow all knowledge of everything. it works for the nsa.
<infinity> And Ollie North.
<dobey> exactly!
<infinity> I may have just dated myself with that comment.,
<jcastro> I'd be more than happy to take the blame and say "look, if you care about nginx use the PPA, we tried to get it in, but LOL LUA modules, we'll work on it over time."
<infinity> jcastro: Too late.  It's in main.
<dobey> yeah, ars said so!
<infinity> Well, so does launchpad.
<teward> infinity: sarnold: no, thank you both!
<teward> jcastro: yeah, sorry about once again placing blame.  My point at the time is the one that infinity made, people interpret "we're considering" as "we're doing" if they don't understand the difference
<teward> (which is most people)
<jcastro> yeah I get that
<teward> in any case, it's been promoted, so no harm done.
 * teward yawns
<jcastro> teward, even without lua it's a win to get it in 14.04
 * jcastro raises a beer
<teward> jcastro: truth
<teward> jcastro: although I think we were going to get the Lua module in anyways...
<teward> because AIUI, the agreement was to repromote lua 5.1 to main as a build-dep here?
<teward> s/agreement/decision/
<xnox> slangasek: i'm not reasonably happy with https://code.launchpad.net/~xnox/ubuntu/trusty/plymouth/private-upstart-socket/+merge/210672 in the process of fixing all of my pet-peaves, i've resonably tested your fix in a variety of scenarios and it's all fine =)
<xnox> i hope somebody can review my patch series ;-)
<micahg> dobey: multiarching a package is a major change that needs release team approval as it can impact reverse dependencies (or so I have been told)
<micahg> that's not to comment on how readily it might be approved
<rmk> So, 3 forms of init with trusty?
<xnox> =)))))
<xnox> we have way more than 3 in the archive i believe.
<rmk> 3 forms of init on an lts release..
<infinity> rmk: Just the one.
<rmk> Is everything systemd?
<infinity> No, everything is upstart.
<infinity> There will be no systemd in trusty.
<rmk> OK great.
<slangasek> xnox: does your plymouth branch deal with disconnects by upstart?  (e.g., upstart restarts in the middle of boot... which is a real thing that happens with cloud-init :)
<YokoZar> infinity: regarding our conversation earlier, would it be sufficient for dpkg if wine1.6 conflicted with wine1.7, or is it important that I have the conflicts line in the same package as the replaces line?
<pitti> Good morning
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: Mirv
<pitti> bluesabre: done
<Unit193> sarnold: Heh, FWIW, downgrading wouldn't have been a good answer, didn't work. :P  (bash-completion)
<Mirv> pitti: hi! would you have time to help my piloting a bit, since you already started on some of the XFCE packages? I'd have three ready and checked for upload.
<Mirv> these are fine to upload as is, and I tested them on XFCE from my own PPA: 1. lp:~noskcaj/ubuntu/trusty/xfce4-places-plugin/gtk3-bookmarks 2. lp:~noskcaj/ubuntu/trusty/thunar/1280641 (bzr bd -S -kMYKEY, no changes were needed)
<Mirv> thirdly, there's https://launchpad.net/~timo-jyrinki/+archive/ppa/+files/shimmer-themes_1.7.1-0ubuntu1.dsc I've tested to seemingly work and tested that each orig tarball matches (diff -urN) the git upstream
<pitti> Mirv: ah, you can't upload yourself? sure, I can upload the first two
<Mirv> pitti: yes, that's the thing, I can only prepare everything until the upload part
<Mirv> pitti: thanks!
<Mirv> I was also looking at tumbler and light-locker-settings but then they disappeared :)
<pitti> Mirv: yes, I uploaded them as I got pinged about them
<pitti> Mirv: they were a followup from yesterday
<Mirv> yep, I noticed you answering
<pitti> Mirv: please approve the MPs in LP
<pitti> Mirv: I guess you can't mark an MP as "merged" yourself; I can do that
<Mirv> pitti: done, thanks
<Mirv> I should have done that
<pitti> Mirv: uploaded 1. and 2.
<Mirv> thank you. the 3. can maybe wait for micahg or someone else, but I commented on the bug #1291739 that I've checked it matches upstream and seems to work (I browsed through the themes in XFCE)
<ubottu> bug 1291739 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.1" [Wishlist,Triaged] https://launchpad.net/bugs/1291739
<pitti> Mirv: yep, looking at this
<pitti> Mirv: watching sabdfl's keynote ATM, so I'm a tad slow :)
<Mirv> oh, good point, I was meaning to do that too
<pitti> Mirv: having a checked, dgettable and ready-to-upload .dsc from you is nice, thanks
<pitti> Mirv: uploaded
<Mirv> \o/ thank you
<Unit193> Thank you both.
<zyga> good morning
<pitti> xnox, ogra_: I'm afraid I don't know what's wrong with dial-number; works fine here, I asked some questions in bug 1287628
<ubottu> bug 1287628 in dialer-app (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,Confirmed] https://launchpad.net/bugs/1287628
<pitti> xnox: is there are reason why you didn't upload the ofono python3-dbus fix? I'm happy to upload it (it's an obviously correct and trivial fix, and I tested it on the phone)
<pitti> xnox: and that might be the reason for failing the dialer-app tests in CI?
<Mirv> if anyone is interested in iDevices support and/or has some of them, I've made a git snapshot packaging branch, a test PPA and a call for testing at bug #1207812 (to get test results before making it a FFe request)
<ubottu> bug 1207812 in libimobiledevice (Ubuntu) "iOS 7, Trust Prompt Looping" [Medium,Triaged] https://launchpad.net/bugs/1207812
<bluesabre> thanks pitti!
<ogra_> pitti, i think the issue with the ofono-scripts are not the scripts themselves, but the question of "why did apport not create .crash files for the exceptions before the switch (or why does it now do that)", it simply trashes your test results now
<pitti> ogra_: aah
<pitti> ogra_: so that's the python-apport vs. python3-apport issue? (you need to have the version installed for the python version you want to catch exceptions for)
<ogra_> looking at the ofono-phonesim-autostart it is even designed to cause exceptions by looping until a connection can be made
<pitti> it's indeed a bit unfortunate that dial-number 199 causes an ofono exception
<ogra_> so the behavior is probably fine, the .crash files arent
<pitti> ogra_: ok, so I completely misunderstood this
<pitti> I thought dial-number etc. was now broken with the py3 port
<pitti> as it has always thrown these exceptions, also with py2
<ogra_> if the exceptions arent critical it is fine to hide them
<pitti> ogra_: ok, then xnox' branch makes much more sense to me now
<ogra_> well, but apport never created .crash files for them before
<pitti> ogra_: yes, because we don't install python-apport by default
<ogra_> which is what UTAH collects
<pitti> but we do install python3-apport
<ogra_> right
<pitti> ogra_: thanks, that moved it from "WTH NFC" to "completely clear" to me now, *phew*
<ogra_> :)
<ogra_> sorry that i wasnt clear before :)
<pitti> ogra_: I'll comment on https://code.launchpad.net/~xnox/dialer-app/fix-dial-number-crash/+merge/209677 and approve
<ogra_> good
<pitti> ogra_: no worries, we didn't really talk about it so far; UDS and all
<ogra_> yeah
<ogra_> but i had researched some on the topic already ... i could have told you earlier if i had remembered ... i might just be getting old :)
<pitti> ogra_, xnox: https://code.launchpad.net/~xnox/dialer-app/fix-dial-number-crash/+merge/209677 understood, commented on, and approved; thanks!
<pitti> sorry for the confusion
<jamespage> pitti, any chance you could put your archive-admin hat on and promote the main inclusions blocking package builds for glance, cinder and ceilometer?
<pitti> jamespage: sure, do you have the bug # at hand?
<pitti> jamespage: I don't see those packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<jamespage> pitti, they are all on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<pitti> oh, -proposed
<jamespage> pitti, yup
<pitti> jamespage: all done
<jamespage> pitti, you are a star - thanks very much!
<MacSlow> Is there a simple way to query the type of device an app is running on... via the SDK?
<rbasak> MacSlow: try #ubuntu-app-devel
<MacSlow> rbasak, thx
<bluesabre> ok, this should be my last package for this week...
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1291913
<ubottu> Launchpad bug 1291913 in lightdm-gtk-greeter (Ubuntu) "[needs-packaging] lightdm-gtk-greeter 1.8.3" [Undecided,Confirmed]
<bluesabre> Any interested sponsors?  Please let me know if you have any questions.
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<Mirv> bluesabre: sorry, I was piloting but I think I don't have time today for more since other stuff is needing attention
<Mirv> but on the plus side I got your shimmer-themes in :)
<xnox> Can somebody help me out understanding the jenkins failures, of autopilot tests on mako as reported here https://code.launchpad.net/~xnox/gallery-app/fix-sample-dir/+merge/210517/comments/496524 I have a mako device, but i don't get those failures.
<xnox> How is that executed?
<bluesabre> Mirv: that's fine, thanks for that btw!
<Saviq> seb128, sorry for hitting you again, but you're the closest one I can think will know about this - this user confirms my bugs the whole morning (like 10 already) https://launchpad.net/~eddiedog988/+karma is that expected / encouraged? he's even accepting bugs he definitely should not (like ubuntu-ux) and such...
<seb128> Saviq, can you give an example?
<Saviq> seb128, here's the last one https://bugs.launchpad.net/bugs/1290750
<ubottu> Launchpad bug 1290750 in gstreamer1.0 (Ubuntu) "totem-video-thumbnailer crashed with SIGSEGV in gst_mini_object_unlock()" [Medium,Confirmed]
<Saviq> seb128, but then https://bugs.launchpad.net/bugs/1291458 he confirmed the ubuntu-ux task
<ubottu> Launchpad bug 1291458 in unity8 (Ubuntu) "Volume buttons change ringtone volume when suspended" [Undecided,Confirmed]
<Saviq> TBH looks like bot behaviour, really... especially since the user is registered two weeks ago
<seb128> Saviq, well, confirming bugs is usually ok, if ubuntu-ux is special you should maybe contact him to say that
<Saviq> seb128, yeah, well, I doubt he managed to confirm all those bugs in the short time he accepted them...
<seb128> right, seems like somebody who is going through reports and clicking confirm if he thinks those are real bugs
<seb128> or something
<Saviq> 10s per bug... https://launchpad.net/~eddiedog988/+karma
<seb128> Saviq, I think the standard procedure to ask for an user to be locked is to report the issue through https://answers.launchpad.net/launchpad/+addquestion
<seb128> Saviq, but ask on #launchpad for confirmation
<Saviq> seb128, will do
<xnox> thanks for locking ~eddiedog988, indeed a lot of havoc caused.
<smoser> xnox, around ?
<xnox> smoser: yeah.
<xnox> smoser: so i've pushed further updates, but i was not able to reproduce the problem you reported using your scripts.
<smoser> ok. so you were right. the script was bogus.
<pitti> ah, I just undid some damage from eddiedog988
<smoser> xnox, http://paste.ubuntu.com/7084468/ is 'go-test
<smoser> now, and that works for me. and shows how i prepared the images in comments at the top
<xnox> smoser: as in it's all good / resolves your problem?
<smoser> serial-patched-01.log: http://paste.ubuntu.com/7084469/
<smoser> serial-unpatched-01.log: http://paste.ubuntu.com/7084470/
<xnox> smoser: it's best to view them with "less -r" due to keycodes usage.
<smoser> line 417 and 419 is a dupe, no?
<xnox> smoser: well i've fixed for _no_ startpar-bridge crap to show up, with further updates in the plymouth branch + sysvinit upload.
<xnox> smoser: i'm not sure where the "naked" messages are comming from - e.g. the line: 443 "bootmisc.sh". Let me recreate the VMs using your updated script and all updated plymouth / sysvinit.
<smoser> xnox, ok. you can point me at some debs too if you want, and I can just re-patch them. but the script shows exactly what i did to patch the images.
<elopio> xnox: I've just recently ran all the gallery tests on my phone, and they passed.
<smoser> xnox, and also, i can't really explain this, but: http://paste.ubuntu.com/7084495/
<elopio> are you using any PPA there?
<smoser> xnox, the patched takes like 15% longer every time (32s to 39s)
<xnox> elopio: i've made a merge proposal, and i believe the tests are running with my change in.
<xnox> elopio: but when testing locally with my change in, it all passes, but it doesn't as reported by jenkins.
<xnox> elopio: so i'm wondering exactly _how_ the ps-jenkins is executing AP tests on mako. E.g. full-steps to reproduce, as I don't see that in any of the output.
<xnox> smoser: i would not be expected _such_ big delay =/
<elopio> xnox: it's hard to tell just from the traces without screenshots, but when all the tests fail it's likely that the application could be opened
<xnox> elopio: ... how were the tests started / provisioned to the device.
<xnox> elopio: it recently got converted into a click, is it running the tests like a click?
 * ogra_ humms "run it like a click ... yeah"
<ogra_> sounds like hip hop :)
<elopio> xnox: the package   inflating: package_archive/archive/work/output/gallery-app-autopilot_0.0.67+14.04.20140306bzr925pkg0trusty3452+autopilot0_all.deb is installed
<elopio> that's the one you get from one of the jenkins links.
<elopio> I don't know how the actual app is being installed.
<xnox> elopio: right, so probably not. Right, let me try fetching that and running tests from that package then.
<xnox> elopio: thanks.
<xnox> smoser: so the $ less -r boot-patched-01.log -> looks wonderful
<xnox> smoser: without any dupes.
<xnox> smoser: http://paste.ubuntu.com/7084520/
<smoser> xnox, thats unfiltered through less -r ?
<smoser> and wrt speed difference, if that is real, i can't take a 15% performance regression on boot/shutdown cycle.
<smoser> if its real.
<smoser> i dont 'knwo why my data would be bad, but i'm not 100% convinced its good at the moment.
<xnox> smoser: the serial console does have correct " * Starting Bridge file events into upstart" but has an extra name of the upstart job printed, e.g. "upstart-file-bridge". I don't know where the extra name of the upstart job is printed from.
<xnox> I'll open a separate bug about that.
<xnox> smoser: for me, here locally it's 13s vs 11s. Let me move the original disks to SSD and check, how that's different.
<smoser> $ echo "scale=3; 13/11" | bc
<smoser> 1.181
<smoser> $ echo "scale=3; 39/32" | bc
<smoser> 1.218
<smoser> those are in the same range, both not acceptable really.
<smoser> and making the disks go faster isn't a "fix"
<rbasak> jamespage: I'd appreciate some quick eyes on https://launchpadlibrarian.net/169357857/add-build-tests.debdiff. I don't like: having to add all runtime depends as build-deps to make the test suite run, and having to use override_dh_auto_test.
<xnox> smoser: sure, but it makes the baseline the same. So what's the penalty for these numbers? http://paste.ubuntu.com/7084560/
 * rbasak wonders if there's some kind of nosetests dh sequencer or something
<rbasak> (or anyone else)
<xnox> rbasak: pybuild can do nosetests, grep through python-modules / python-apps debian teams svns?
<xnox> smoser: cause e.g. on those runs, fully in ram, sometimes "patched" was quicker than "unpatched".
<jamespage> rbasak, it would be nice if there was (some kind of nosetests dh sequencer)
<jamespage> rbasak, that generally looks OK
<jamespage> rbasak, I might ping upstream and get them to re-align with 0.17.5
<rbasak> jamespage: I spoke to upstream in #juju. They're ready to release AIUI, but are waiting for a juju-core release first.
<GunnarHj> pitti: ping?
<jamespage> rbasak, ah - OK - makes sense
<jamespage> rbasak, I think for the time being that is generally +1 then
<rbasak> xnox, jamespage: thanks. I'll leave it for now since we're in a hurry, but will see if I can convert the packaging to use pybuild in the future.
<xnox> smoser: so in my run, i have total of 10 runs patched at 108s, unpatched at 101s. which is a 6.9% penalty. But i'm not a stats person to identify error margins here, cause we are measuring at 1s resolution here thus all runs are +/- 0.5s
<xnox> smoser: average patched time is 10.8s, average unpatched 10.1s
<xnox> smoser: i did rearrage events of the plymouth startup & shutdown events earlier in the cycle (possibly whilst cloud images were still affected by plymouth segfaulting) thus the do now may prolong boot/shutdown a little, but we get a more consistent boot & shutdown.
<pitti> hey GunnarHj
<GunnarHj> Hi pitti!
<GunnarHj> pitti: Do you possibly have time to 'push the button' as regards https://mentors.debian.net/package/mythes-sv ?
<mlankhorst> huh?
<mlankhorst> is perl bugged on ppc64el?
<pitti> GunnarHj: yes, can look
<mlankhorst> https://launchpadlibrarian.net/169358009/buildlog_ubuntu-trusty-ppc64el.mesa_10.1.0-1ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
<GunnarHj> pitti: Thanks!
<pitti> GunnarHj: do you mind if I upload it as -1? an initial -2 is ugly
<smoser> xnox, plymouth did not segfault to my knowledge with current lp:ubuntu/plymouth
<GunnarHj> pitti: Not at all, it it's possible it's better.
<GunnarHj> if
<pitti> GunnarHj: uploaded to Debian and Ubuntu NEW
<pitti> GunnarHj: to Ubuntu as 1.3.1-1~fakesync1
<pitti> as it's not a real sync yet, needs to pass Debian NEW first; but I figure you want it in Ubuntu ASAP
<GunnarHj> pitti: Thanks! Well, guess I could have waited for the real sync, but thanks anyway. ;-)
<psusi> say, why does packages.ubuntu.com only show amd64 and i386?  What about the other archs?
<xnox> psusi: there is a contact person on the bottom of the packages.ubuntu.com pages...
<zbenjamin> tedg: hey ted, do you remember me? I'm the guy working on the ubuntu qtcreator integration, i'm currently at a state where i need to run a deployed application on the phone, currently we deploy a exploded directory and run the app from there. However that seems to not work anymore (qmlscene complains about -I is not known as a paramter and the appwindow also does not show up)
<zbenjamin> tedg: i was wondering if there is any way for me to upstart a desktop file directly without it being installed by click
<tedg> zbenjamin, There is, but wouldn't it be better to just install it per-user with click?
<zbenjamin> tedg: well bzoltan said he does not want to do that in the development process because it would take long
<tedg> i.e. my app becomes the dev version for the account
<zbenjamin> i also would need a way to somehow control the running application from cli , so i can start/stop the app and i also need to run gdbserver with it for debugging :)
<tedg> zbenjamin, We should fix it taking too long. :-) We can launch the app but you won't get any of the other things you might want to test, like registering for a URL pattern.
<tedg> I think if you just untar a directory, you'll always get something half functioning.
<xnox> zbenjamin: it doesn't take long =) ask for numbers before you believe it ;-)
<zbenjamin> tedg: ok wait i maybe try to pull in bzoltan here
<xnox> zbenjamin: also gdbserver and QML apps?! is that really the common case debugging?
<zbenjamin> xnox: qml apps + cpp backend
<xnox> zbenjamin: ok.
<tedg> How are you installing gdbserver? To use QtCreator do you have to make your image writable?
<zbenjamin> xnox: i have a few cases:   1) pure QML, 2)pure HTML, 3)QML+Cpp, 4)C++
<zbenjamin> tedg: thats a good question, i didn't come that far, but we have scripts to make the image writeable
<zbenjamin> but if we want on device debugging i guess we need that
<zbenjamin> ok seems zoltan is not here right now
<tedg> We should probably break the requirements down a bit, as I think there's a case where someone would be happy to install a dev version of a package, but wouldn't want to make their device writable.
<zbenjamin> tedg: well as long as you don't want to debug, you don't need gdbserver
<zbenjamin> my idea was to sneek the gdbserver command in , in cases where someone really hits the debug button
 * tedg has a hard time imagining software with bugs, as he's never written any, but has heard about this from other people
<xnox> tedg++
<tedg> The trick there is going to be confinement, you really want to run the app confined to test it.
<zbenjamin> never written bugs or never written software? ;) ;)
<tedg> But I'm guess gdb isn't confinement happy.
<zbenjamin> tedg: ok requirements would be a) start the app from cli, b) stop the app from cli , c) watch the apps state for running
<pitti> jamespage: do you know some web UI to browse files from swift? (I tried ftp-cloud, but it seems to be ridiculously slow and doesn't want to authenticate)
<zbenjamin> tedg: for debugging we need: a) the qml debugger switch to the command for debugging qml, b) somehow get gdbserver into the game
<jamespage> pitti, erm
<tedg> zbenjamin, So "upstart-app-launch" does that, you can take apart the executable to get more info at the various phases.
<tedg> zbenjamin, It registers for the callbacks, etc.
<zbenjamin> tedg: ok
<pitti> jamespage: I mean, I know how to do it with curl, passing  around the auth headers; if that's what it takes for debugging, I use it; but something clickable in the web browser would be nice
<jamespage> pitti, if you set appropriate acl's on the container
<jamespage> you should just be able to browse it
<pitti> jamespage: you mean it has builtin http simple auth?
<jamespage> pitti, http://docs.openstack.org/grizzly/openstack-object-storage/admin/content/swift-acls.html
<jamespage> one second
 * jamespage reads again
<pitti> jamespage: ah, thanks; reading that
<zbenjamin> xnox: also for the taking long part, its not only the installing but also the click package creation and validation vs upload a directory ;)
<pitti> jamespage: yes, I totally don't care about security; this is just a swift running in a local container for testing
<cjwatson> creating a click package isn't much more than tar under the hood
<pitti> jamespage: if I e. g. go to http://10.0.3.134:8080/v1/AUTH_testproj it just greets me with "Unauthorized"
<jamespage> pitti, ".r:*,.rlistings"  read acl makes it browseable
<jamespage> you'll need to access at the container level
<pitti> and doesn't ask me for my super-secret testuser/testpwd creds :)
<jamespage> http://10.0.3.134:8080/v1/AUTH_testproj/<container>
<xnox> zbenjamin: click build + install is near instant...
<jamespage> pitti, this is relevant as well - http://docs.openstack.org/api/openstack-object-storage/1.0/content/Examples_for_static_web-dle4025.html
<xnox> zbenjamin: and due to compression, you'd win time since one would be pushing less bytes over adb.
<zbenjamin> xnox: i'll test it :)
<cjwatson> the main slow bit of click install will be the python interpreter starting on the phone, I suppose; that costs a bit over half a second
<pitti> jamespage: many thanks
<pitti> jamespage: I get a somewhat ugly XML page now, but I can specify file URLs and download them, and at least see the listing
<jamespage> pitti, the web-listings thing might be neater
<arges_> smb: hey do you need help with bug 1248025
<ubottu> bug 1248025 in libvirt (Ubuntu) "libvirt-bin fails to start inside Xen" [Undecided,In progress] https://launchpad.net/bugs/1248025
<smb> arges_, I am just bugging hallyn / jamespage on the server channel :)
<arges_> smb: oh ok. just checking out the queue and saw it. I'll leave it alone then
<smb> arges_, ok, yeah. there seems to be some autotest problem, too anyway
<psusi> say... how is the ppc arch not dead?  wasn't apple the only one using it and they stopped like 10 years ago?
<infinity> psusi: Turns out that not everything in the world is a desktop computer.
<psusi> someone is making ppc servers?
<infinity> psusi: Many someones have been doing so for a very long time.
<psusi> weird
<Pici> AIX runs on PPC
<infinity> psusi: Guessing you've never heard of International Business Machines? :P
<psusi> so given that apple dropped it a long time ago... does it still make sense for us to use the apparently long unmaintained and rotten mac-fdisk over util-linux's fdisk on ppc?
<infinity> psusi: Maybe.  It still supports things that fdisk doesn't.
<psusi> well it apparently doesn't support disks > 500gb ;)
<infinity> psusi: Though, arguably, that support should be rolled into fdisk.  Or people should use parted.
<infinity> psusi: And, frankly, "people should use parted" is an aswer for other reasons, like fdisk not groking GPT.
<psusi> yea.. I think they added support for mac partition tables to util-linux upstream recently
<psusi> fdisk now understands gpt upstream too ;)
<infinity> psusi: Anyhow, it's on my list of things I want to try to sort out.
<infinity> It may well be that the divergence there has outlived its usefulness.
<infinity> Finally.
<psusi> aye
<infinity> YokoZar: That conflict might work by accident, but still probably doesn't mean what you wanted it to mean.
<infinity> YokoZar: Your "replaces" without a "conflict" still means "please overwrite files from the other package and take ownership of them", but the conflict might force a premature removal that prevents that.  Maybe. :P
<psusi> infinity: but replaces does force the other package to be removed right?  unlike dpkg-divert?
<psusi> I thought the difference was that conflict means it won't be installed instead of the other package during an upgrade, but with replaces it will
<infinity> psusi: Erm, what?
<infinity> psusi: Replaces overwrites files.  It does not force package removal.
<infinity> psusi: Conflicts/Replaces forces a package removal.
<psusi> you just contradicted yourself...
<infinity> psusi: This is exactly the bug YokoZar is dealing with, he had a replaces without a conflict, and then when he'd install B after A and remove A, he'd have no files left (completely expected).
<infinity> psusi: I didn't contradict myself if you check context.  He was asking if it would work if the conflict was in another package, instead of having the C/R pair in the same package.
<infinity> (The answer is "maybe, but not by design")
<psusi> why would you ever want to just overwrite the files of another package?  that seems broken
<infinity> psusi: You do it all the time, when files move.
<infinity> psusi: Say, for instance, a file were to move back and forth between procps and util-linux. :P
<psusi> yea.. and you removee or upgrade the old package
<infinity> No, you overwrite the file in the old package.
<infinity> That's what Replaces means.
<infinity> You take ownership, so it's now in your file list, and not the other.
<psusi> that doesn't make sense by itself... if the file moved then you need to upgrade the other package to the new version that does not also contain the file
<dakira> exit
<dakira> exit
<dakira> exit
<psusi> and if you take ownership, then removing the old package shouldn't remove your files
<infinity> psusi: No, removing the NEW package leaves the old one without files, which is unexpected if that's not what you wanted.
<psusi> ohh
<psusi> but why would you ever want to replace files of another package, and keep both installed?  and why wouldn't you use dpkg-divert for that?
<infinity> psusi: You want to do that all the time.  Like I said, when files move between packages.
<infinity> In YokoZar's case, it's expressly what he *didn't* want.  He wanted to force the old package off the system.  But you need C/R for that, and he only had R.
<psusi> when files move between packages though, the old package removes the file in its new version, so you want to upgrade, not keep the old, conflicting version
<psusi> why isn't a conflicts by itself enough to force the old package off the system?
<infinity> psusi: Yes, you want to install a new version of the package, but you still need the overwrite, unless you want to force the unpack/install order.
<psusi> so by using both, you can install the new new package first, *then* upgrade the old one? rather than uninstalling the old one, then installing the new one?
<infinity> psusi: Here.  Let's look at a real life example where it would obviously be broken to require removal before install.  If we broke out libnss-files.deb from libc6.deb and wanted to install that on upgrade.
<psusi> right, so if there are depends, then you *can't* uninstall the old package first... so you have to be able to replace it, then upgrade it?
<infinity> With a hard versioned conflict, I'd have to remove libc6 before installing libnss-files.deb (obviously bad, cause I'd no longer have a libc), or I'd have to install the new libc6 first, which would no longer have libnss-files (wich could break my shell).
<psusi> right... got ya
<infinity> But if I install libnss-files first, and it Replaces libc6 (<< first-version-wihout-libnss-files), then it overwrites, I have my bits, and I keep upgrading.
<infinity> As for why Conflict isn't enough to foce things off a system, it is, but it isn't.
<infinity> If you manually ask for "please install foo, which conflicts with bar, which is installed", you'll get what you asked for.
<psusi> aha!  I see now
<infinity> But upgrade managers like apt, update-manager, etc, won't let you do that because, well, it's far too easy to shoot yourself in the foot.
<psusi> the conflicts by itself would cause the upgrade path to refuse to remove the existing package... but with c+r, the upgrader sees that when it upgrades the old package, it will no longer conflict, so proceeds
<infinity> Conflict/Replace together is a hint that foo is *meant* to replace bar, rather than them just being conflicting implementations (like MTAs... If every time something listed "exim" as its preferred MTA, it tore out your "sendmail" or "postfix", you'd be pretty angry)
<cjwatson> also note the stuff in policy about when you should prefer to use Breaks instead
<cjwatson> that's the result of quite a bit of very pedantic discussion and it's nice to make use of it rather than have to rethink it all from first principles
<infinity> I like the general rule that "if it's a versioned conflict, you probably meant Breaks".
<cjwatson> yep
<sergiusens> xnox, your gallery question is sort of answered now
<psusi> so... replaces+breaks would be the right way to move a file between packages?
<xnox> sergiusens: well, sort off. the full log does not use "phablet-test-run" thus it's really hard to reproduce.
<psusi> I would think that moving a file you would need a versioned conflicts, otherwise even the updated old package wouldn't be coinstallable
<xnox> sergiusens: or is there a new reply i didn't notice somewhere?
<cjwatson> psusi: in general you should use Breaks+Replaces for that, yes, if the old package survives just with fewer files
<psusi> ahh... why? ;)
<cjwatson> versioned conflicts> see "nice not to have to rethink it all from first principles".
<cjwatson> go read the footnote in policy :)
<sergiusens> xnox, like 2 minutes ago; I triggered the rebuild before going to be last night as the error seemed weird
<xnox> sergiusens: ok, i'll try to do the deb thing.
<sergiusens> xnox, in the jenkins build there's a 'deb' key with a link to all thedebs it builds for testing
<infinity> psusi: Well, a versioned conclict, historically, was use with a versioned replace.
<sergiusens> xnox, http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/3452/artifact/work/output/*zip*/output.zip
<infinity> psusi: But that causes awful messes for resolvers.
<cjwatson> the short answer is that Conflicts imposes too strong a constraint and often requires apt to entirely remove the old package temporarily rather than being able to do something more graceful
<cjwatson> Breaks is to Conflicts as Depends is to Pre-Depends, roughly
<infinity> psusi: Basically, a break/replace combo lets you upgrade in any order, but still requires you to upgrade both packages.
<psusi> wait... if you use breaks, then the old package has to be deconfigured first, which you can't do if other packages depend on it
<cjwatson> that makes no sense; conflicts is *stronger* than breaks
<cjwatson> if you think breaks is too strong then logically you must also object to conflicts
<psusi> I though the point was to use both conflicts, and replaces, to allow the new package to be installed *without* first removing the old one?
<cjwatson> anyway, yes you can deconfigure, it just requires deconfiguring the tree above it
<cjwatson> no, use breaks+replaces.
<cjwatson> we have gone over this ad nauseam in -policy and it's the right answer
<cjwatson> policy exists so that we don't have to keep revisiting this stuff :)
<cjwatson> conflicts+replaces *forces* the old one to be removed or upgraded before unpacking the new one
<cjwatson> in cases where the new one also depends on the old one (commonplace in cooperating groups of packages), this can get pretty exciting for the resolver!
<psusi> I thought infinity was just explaining to me that the replaces allows the new one to be installed, and take over the file, before removing or upgrading the old one
<infinity> psusi: It does.
<cjwatson> replaces does; but the conflicts says that both packages cannot exist in >=unpacked state on the system at the same time
<cjwatson> whereas breaks says that both packages cannot exist in configured state on the system at the same time
<psusi> ohh
<cjwatson> the latter turns out to work much better for moving files between packages
<infinity> psusi: But without the breaks (or, in the past, conflicts), you have no hint that the other package should be upgraded.  Which leads to the "when I remove the new one, the old one is missing files" issue.
<psusi> then replaces doesn't really let one package take over a file from another since it forces the other package to be removed first
<cjwatson> no, replaces doesn't force the other package to be removed first
<infinity> Replaces only overwrites files.
<psusi> you just said it prevents both from being >= unpackacked
<cjwatson> no I didn't
<cjwatson> please read again
<cjwatson> 14:58 <cjwatson> whereas breaks says that both packages cannot exist in configured state on the system at the same time
<infinity> (Except when used with conflict, but that's a special and weird case)
<cjwatson> and
<psusi> ohh, right... *conflicts*
<cjwatson> <cjwatson> ... but the conflicts says that both packages cannot exist in >=unpacked state on the system at the same time
<psusi> ok, so you do want replace, just use breaks instead of conflicts since conflicts forces removal of the old package first, which might break things
<cjwatson> exactly
<cjwatson> conflicts+replaces is the hack we used before breaks existed
<psusi> ok... I swear infinity was saying that c+r allowed the smooth replacement without first removing the old one ;)
<cjwatson> it was suboptimal but there wasn't really anything better; so it's still embedded in various packages
<cjwatson> and occasionally people clone-and-hack it
<cjwatson> but breaks+replaces is the new hotness (where new = about 6 years old)
<cjwatson> and actually does what we wanted all along
<cjwatson> c+r allows a replacement that doesn't allow files to magically reappear, but it's an excessively large hammer
<cjwatson> it's still appropriate in cases where the old package name is going away permanently
<cjwatson> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts has a set of rules of thumb for when to use one or the other
<psusi> unless temporarily removing the file could break the system
<psusi> like if you were moving /bin/sh
<cjwatson> right, essential packages must be much more careful
<cjwatson> there's a whole set of mostly unwritten lore for dealing with those, since there are very few of them and their maintainers are mostly experts already :)
<cjwatson> plus the essential set is *mostly* fairly stable
<cjwatson> some of the rules are written down, like essential packages normally need to use Pre-Depends to ensure that dependencies of the essential facilities they provide are always met even while unconfigured
<cjwatson> but policy leaves you to derive some of the rest from first principles of the state machine it describes
<cjwatson> largely when this comes up it's something that's worth thinking through from scratch anyway
<psusi> aye
<cjwatson> Santiago and I have a low-level running disagreement about exactly how base-passwd should be behaving here :)
<psusi> damnit... so... I've reworked my patches to partman-basicfilesystems like you asked, and trying to test it now... but I can't build d-i.. it looks like it is still looking for the previous kernel and acpi-modules versions, which are in testing, but have been removed from unstable
<psusi> any hints there?
<cjwatson> might be worth checking whether build/sources.list.udeb is exactly correct - if it isn't, copy to build/sources.list.udeb.local and adjust
<psusi> looks fine to me: deb http://ftp.us.debian.org/debian unstable main/debian-installer
<cjwatson> you might need to locally bump the kernel version in the appropriate config file under build/config/
<cjwatson> it's not always perfectly up to date
<psusi> hrm.. build/pkg-lists/kernel says to get kernel-image-${kernel:Version}... where's it get that version from?
<cjwatson> build/config/amd64.cfg:5:KERNELVERSION = 3.12-1-amd64
<cjwatson> for instance
<zbenjamin> tedg: i was just checking how android handled the debugging. Looking at the android creator plugin it seems the "am" tool has support for running a app in a debug mode, any chance we could do something similar?
<psusi> ahh, right
<tedg> zbenjamin, We have an API in libual that runs an app in test mode. Mostly for thomi, if he's happy with adding things there, I'm happy to as well.
<tedg> zbenjamin, Today it just sets the testability flag.
 * psusi wishes that all of the partman modules were in one repo
<cjwatson> yeah, it's not ideal
<cjwatson> mr can help
<cjwatson> https://wiki.debian.org/DebianInstaller/CheckOut
<psusi> it feels very goofy to have to do a svn checkout and then use this mr tool to checkout all of the sub git modules
<psusi> ohh that was for d-i though
<cjwatson> partly this is 'cos translators wanted to stick with svn iirc
<cjwatson> yeah, but that gets you partman-*
<psusi> ohh.. I just did a git clone once I realized they were maintained in git... that first round of patches I just downloaded the source package and made a debdiff
<cjwatson> definitely much less work to do it in git
<shadeslayer> ev: can Kubuntu drop gdb in favor of gdb-minimal? Will everything work fine from the daisy POV?
<pitti> shadeslayer: should be fine, yes; it doesn't need the extra pretty-printers and other bells and whistles
<ev> shadeslayer: I honestly have no idea and I'm in full on firefight mode at the moment, sorry
<ev> ah thanks pitti
<pitti> Recommends: update-notifier, gdb | gdb-minimal
<xnox> sergiusens: elopio: barry: i've now emails ubuntu-devel & ubuntu-phone about this gallery-app merge proposal. I've pulled the debs generated in the merge comment, and they fully pass their test-suite when i execute them on my mako.
<pitti> shadeslayer: ^ that's what apport-gtk has
<shadeslayer> aha
<pitti> shadeslayer: (and -kde)
<shadeslayer> so apport will work fine as well
<pitti> shadeslayer: yes
<shadeslayer> now all that's left is Dr Konqi
<shadeslayer> pitti: so, the only difference is "Recommends: libc-dbg, python3" right?
<pitti> shadeslayer: sorry, which difference?
<shadeslayer> gdb vs gdb-minimal
<barry> xnox: so, it passes as a .deb but fails as a .click?
<xnox> barry: it passes whichever way around, always, locally.
<sergiusens> xnox, then fginther should be able to figure it out
<xnox> barry: i'm really struggling to fail it locally at all, or in anyway similar to what ps-jenkins is telling me.
<xnox> sergiusens: just fginther ? =(
<barry> xnox: yay
<xnox> fginther: hopefully you can help shed some light as to why https://code.launchpad.net/~xnox/gallery-app/fix-sample-dir/+merge/210517 is failing by ps-jenkins on mako, yet passes locally against mako.
<dobey> cjwatson: ping
<dobey> cjwatson: you're not making the vala click scope code use libclick, are you?
<fginther> xnox, what image are you using?
<fginther> xnox, the tests use trusty-proposed
<xnox> fginther: i'm testing against trusty-proposed on my local mako...
<fginther> xnox, ok
<xnox> fginther: are there steps that I can do locally, to match what ps-jenkins is doing? cause it's using .deb instead of .clicks.
<xnox> fginther: and phablet-test-run passes here =(
<dobey> cjwatson: if so, please stop wasting your time (the vala code is going away as soon as new scopes lands in the image) :)
<cjwatson> dobey: see my conversation with alecu on #ubuntu-phone earlier
<cjwatson> dobey: I hadn't started on the vala bits yet, as it happens
<sergiusens> xnox, no, not just him; cihelp on that other channel for ci works
<dobey> cjwatson: on irc? i'm not on that channel. is it logged?
<cjwatson> dobey: sorry, I mean #ubuntu-touch
<dobey> ah ok
<cjwatson> dobey: anyway, I'm basically scattergunning my efforts across anything I can find that forks /usr/bin/click, but thank you for decrementing my list :)
<fginther> xnox, yes. the test runner is all in lp:~canonical-ci-engineering/jenkins-launchpad-plugin/autopilot-testrunner-touch-saucy
<cjwatson> dobey: I'll probably just defer submitting anything from the scope until there's something new-scopish I can test conveniently
<dobey> cjwatson: i just now saw your e-mail about it on the list. didn't see the backlog in irc though. :)
<cjwatson> *to the scope
<fginther> xnox, it's a bit of a patch work, some parameters are env vars, some are passed as arguments. But you should be able to reproduce things by just walking through mediumtests-runner-touch.sh
<dobey> cjwatson: yeah, i was going to file a bug about using libclick anyway, and see if it can be done reasonably trivially
<dobey> cjwatson: just don't want you to waste time on code we're going to throw away in a few days
<fginther> xnox, basically do some setup of the phone, install all of the test packages from the build, unlock the screen, then run the tests with ptr.
<cjwatson> dobey: sure; it looks something like http://paste.ubuntu.com/7085258/ but I haven't polished that yet
<xnox> fginther: in the full console log I do not see ptr executed at all =/
<fginther> xnox, ack, the script isn't being echoed, which I admit makes this annoying
<shadeslayer> pitti: poke poke <shadeslayer> gdb vs gdb-minimal
<doanac`> ptr starts in the log around: INFO:unity8.process_helpers:Greeter unlocked, continuing
<pitti> shadeslayer: ah, that
<shadeslayer> that's what I can see atleast : Recommends: libc-dbg, python3
<pitti> shadeslayer: yes, you don't need those for whoopsie or apport
<shadeslayer> cool, thx pitti
<doanac`> xnox: i'm terrible with autopilot log parsing, but this doesn't seem good:
<doanac`> Could not determine application identifier. HUD will not work properly.
<doanac`> Provide your application identifier in $APP_ID environment variable
<barry> doanac`, xnox i've seen that before
<barry> no idea what it means, but it went away when i fixed the bug
<xnox> doanac`: my analysis so far is that gallery-app has been converted to click on the image, yet ps-jenkins is building/installing/testing it as a .deb. That can't be right, as we are doing wrong/unconfined testing.
<barry> http://bazaar.launchpad.net/~barry/address-book-app/py3autopilot/revision/149
<fginther> xnox, it's actually a click in the image now?
<xnox> doanac`: if the app / autopilot driver crashes, it would results in HUD garbage.
<jibel> doanac`, I think it means the app is not launched by upstart-app-launch
<fginther> xnox, in that case, I think the jenkins testing is unpredictable
<xnox> fginther: as per http://people.canonical.com/~ubuntu-archive/click_packages/click_list gallery is a click app on the images.
<xnox> fginther: and that link is the canonical list of preinstalled clicks used during image construction.
<fginther> xnox, thanks
<fginther> xnox, I think your right then, this is incompatible until we can get these converted to pure click testing. I can't do that today, so I recommend dropping the automated touch tests from these click packages for now.
<xnox> fginther: but e.g. it should still work, let me try flashing a fresh image, uninstalling gallery-app click, install debs, try testing them.
<xnox> fginther: maybe e.g. the .deb creation got broken since conversion to click.
<fginther> xnox, indeed. I would expect the deb to rot now
<infinity> bdmurray: *poke*
<infinity> bdmurray: What's the point in ubuntu-release-upgrader failing gracefully if apport isn't installed if you explicitly depend on it?
<infinity> bdmurray: (And do we really want to explicitly depend on apport and pull it into the standard set?)
<bdmurray> infinity: apport and python3-apport are already on most installs?
<infinity> bdmurray: Desktop installs, they weren't in standard until you made that change.
<infinity> bdmurray: And they were recommends of most desktops until you made it a hard dep of... Everything.
<bdmurray> infinity: right, I got that. the release-upgrader uses python3-apport to do its own crash handling. so we won't get crash reports on upgrades of things other than most desktops
<bdmurray> There won't be a .crash file generated at all.
<infinity> bdmurray: Well, I'd say it's by design for us to not get crash reports from people who don't want to send them, or people who don't want apport installed...
<infinity> bdmurray: Just seems weird to put effort into making it gracefully work without apport installed and then require apport.
<bdmurray> infinity: I missed that python3-apport recommends apport. The creation of the .crash file is different than the send of it.
<infinity> bdmurray: As you note, apport will be installed on most desktops anyway, so that bit should Just Work.  I'd argue that the graceful business should allow for py3-apport not being there too, no?
<infinity> So, user has apport, stuff works, user doesn't have apport, no .crash.
<bdmurray> infinity: okay
<infinity> bdmurray: It just pulls a lot of stuff in, hence my complaint.  So, yeah, if we can fix, that would be lovely.
<bdmurray> infinity: right, I'll take care of it
<infinity> Ta.
<jtaylor> hm is the diamond like pattern in the trusty desktop background a graphical glitch or intentional?
<ogra_> intentional
<jtaylor> k
<jtaylor> maybe not the best choice if the first though you get from seeing it is that somethings wrong :/
<infinity> Would have made more sense for quantal. :P
<infinity> But it's grown on me.
 * ogra_ finds it slightly painful that the cross point isnt actually centered 
<infinity> ogra_: Thanks.  Now I can't unsee that.
<cjwatson> It's like the software centre icon
<ogra_> lol
<jtaylor> ^^
<cjwatson> I thought the crossbar on it was a graphical glitch for the longest time
<mdeslaur> hehe
<infinity> cjwatson: I thought it was a masonic symbol.
<mdeslaur> lol
<cjwatson> Particularly since not long before it was introduced I actually did have an occasional graphical glitch on my system that looked a bit like that
<dobey> cjwatson: the progress bar?
<cjwatson> I expect that is what it's supposed to be, yes
<cjwatson> To my hindbrain it's forever an X glitch
<ogra_> it is mpt's expression of anarchy
<dobey> heh
<cjwatson> I also have no idea why it looks like an A
<ogra_> (in a shopping bag)
<infinity> cjwatson: I assume A is for "Appz lolz".
<dobey> cjwatson: because applications don't start with an s
<infinity> Because you if you don't have "apps", you're not hip and cool.
<infinity> Thanks, Apple.
<ogra_> cjwatson, because it brings you "Apps"
<cjwatson> I assumed it was the Amazon icon for ages before I actually checked
<cjwatson> Icon designers and I don't normally get on well. :-)
<dobey> ogra_: you're mistaken. all i've gotten is suffering ;)
<mdeslaur> so it's _not_ an Abercrombie bag?
<ogra_> thats not my fault !
<infinity> mdeslaur: No, even fat kids can use software-centre.
<dobey> mdeslaur: no, it's too thick for that
<mdeslaur> hehe
<dobey> also, it has a color other than grey
 * cjwatson wonders if we localise that icon
<dobey> localize? icons? LOL!
<cjwatson> Or if we just assumed everyone speaks a language where applications starts with A
<cjwatson> Because cultural imperialism lol
<infinity> cjwatson: It's not "applications", it's "apps", and "apps" is probably a universal borrowed word by now.
<infinity> (Again, thanks Apple... *grumble*)
<cjwatson> I was pleased to find last night that the only star map application (:-P) I could find for Ubuntu Phone had an Irish title
<cjwatson> Less pleased to find as a result that the "Recent apps" thing isn't Unicode-safe
<rbasak> This conversation reminds me of save icons not being floppy disks
 * cjwatson checks the century
<rbasak> And everyone getting confused
<xnox> jtaylor: infinity cjwatson: the bit that annoys me is that the origami center fold is not _actually_ in the center of the image, see screenshot on bug #1291735
<ubottu> bug 1291735 in ubuntu-wallpapers (Ubuntu) "Default 14.04 wallpaper does not align well with greeter grid" [High,Confirmed] https://launchpad.net/bugs/1291735
<infinity> rbasak: Floppy for life.
<rbasak> "Daddy, what is that thing in the photo that looks like a save icon?"
<infinity> rbasak: I just like that, way back when, the icon *did* change from a black 8"/5.25" floppy to a colorful 3.5" floppy.  And then we just stopped updating.
<infinity> I assume that, by now, it should be a picture of someone flinging bits over the intertubes at a remote server.
<infinity> But that's hard to represent.
<dobey> infinity: gnome is updated :)
<infinity> dobey: What does GNOME use now?  I haven't looked.
 * infinity looks.
<dobey> infinity: it's a hard drive with an arrow
<infinity> Oh, right.  It's been that for a while.
<infinity> Silly GNOME.  I want my floppy.
<rbasak> Yeah that's what I'm referring to. Users used to know what floppy disks look like. Users have never known what hard drives look like.
<dobey> software-center icon is actually a shoe bag: http://www.gettyicons.com/free-icons/174/the-city/png/256/nike_256.png
<infinity> rbasak: The problem is that there's nothing that users know on sight that also represents "saving stuff" and can fit in a tiny icon.
 * psusi wrote the floppy disk driver for ReactOS... most shitty hardware you can imagine
<rbasak> infinity: indeed. And arguably the whole load/save paradigm for documents is a broken one anyway.
<ogra_> reactos is bound to a certain HW ?
<dobey> rbasak: yet web sites offering downloads of apps or whatever use a metaphorical hard disk and arrow as an icon for it :)
<psusi> ogra_: no, I was refering to floppy disks
<infinity> rbasak: With enough space, an IKEA-style pictogram of a man crying because his essay is lost, and a crossed-out circle around it would totally work. :P
<ogra_> ah
<ogra_> yeah
<rbasak> :)
<infinity> "Have you clicked the sadness-prevention button recently?"
<dobey> infinity: users use google docs, which doesn't have save, anyway. :)
<psusi> I was scratching my head for quite a while trying to figure out why I couldn't get it to even detect the type of drive... the specs say there is a command to do this... then I realized nobody botherd to fscking implement it, which is why every pc bios ever makes you tell it what type you have, if any.. and the OS just has to blindly accept that
<infinity> dobey: Right, creating the file before editing (which is the gdocs paradigm) allows you to just autosave-on-edit and do away with the button.
<infinity> dobey: Which is, arguably, what those poor kids losing essays and dissertations should be doing too.
<dobey> or just get in the habit of pressing Ctrl+S after every Return
<psusi> it was fun though, being able to redo the low level format and squeeze 1920 kb onto a 1440k floppy using mixed sector sizes ;)
<cjwatson> Hah, the author of the star map application I mentioned even filed a bug about it.  https://bugs.launchpad.net/unity8/+bug/1276005
<ubottu> Launchpad bug 1276005 in Unity 8 "Accented characters don't get rendered properly in Recent apps" [High,Triaged]
<cjwatson> bregma: I don't suppose you'd be available in the core-1 session now?  We could use some experience with hidpi
<bregma> be right there
<barry> xnox: https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877
<xnox> barry: if ps-jenkins will O.K. it i'd want to ship it asap =)
<barry> xnox: i guess it would supersede your branch, since lp's mp is ignoring my suggestion.  or just steal my branch and merge it into yours
<xnox> barry: yeah target lp:gallery-app
<xnox> barry: that's fine.
<theqlabs> howdy, running ubuntu on beagle bone black: trying to understand the best way to develop a DMA kernel module that sends its buffer to a host PC over Ethernet (TCP socket, send() system call, etc?)
<barry> xnox: sorry, i don't know whether your going to pull it into your existing mp or mine should supersede?
<sarnold> theqlabs: you may have more success in #kernelnewbies on irc.oftc.net
<xnox> barry: doesn't matter =) i'd rather not touch the proposal, and wait for ps-jenkins to test it and see what the results would be.
<theqlabs> excellent, was looking for kernel room - thanks sarnold
<barry> xnox: okay.  i guess we'll just leave my mp as a separate proposal
<barry> xnox: https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877/comments/497072
<ogra_> xnox, FYI there is also python-apt on the touch images (along with python3-apt ... i just saw your gallery-app mail)
<xnox> barry: *ship it* =)
<xnox> ogra_: i know. i can't port anything else, until these 3 clicks land - music, calendar and now gallery app.
<ogra_> yeah, that might take a bit ...
<ogra_> given the Qt explosion that is just happening :)
<bdmurray> pitti: the retracer logs contain information about what debug symbol packages are outdated. Could we use that to get updated versions?
<jtaylor> nice the new readline is borked too
<jtaylor> am I to dumb to find the FFe or was there none?
<jtaylor> oh well at least theres a patch, lets try
<jtaylor> hm how does one apply this type of patch: http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00031.html
<YokoZar> cjwatson: infinity: Thank you for the extended discussion.  I think the only weirdish not-fully-defined behavior in apt is what happens when you Provide a package that is also a real package (the resolver gets a bit confused)
<sarnold> jtaylor: patch should handle that, that's just an old-style diff or context diff..
<jtaylor> bug 1290287
<ubottu> bug 1290287 in readline6 (Ubuntu) "ipython crashed with SIGSEGV in _rl_dispatch_callback()" [High,Triaged] https://launchpad.net/bugs/1290287
<infinity> YokoZar: Providing a package that's a real package give equal weight for non-versioned dependency resolution if it's already installed, but favours the real one if not, or if a version comes into play.
<infinity> jtaylor: Eww, wow, a non-unified diff?  Ugly.
<infinity> jtaylor: But yes, patch will read it fine.
<achiang> does anyone have a pointer to wiki that explains the technical/support differences between a flavor and a remix?
<achiang> flavor implies official support
<infinity> achiang: No it doesn't.
<achiang> but is there a type of derivative that is less official?
<achiang> https://wiki.ubuntu.com/RecognizedFlavors
<achiang> well, i guess not official support, but some support for the recognized flavors
<achiang> but i'm looking for an explanation of other derivatives that aren't recognized flavors
<infinity> achiang: Sure, archive support, because we run the archive.
<YokoZar> We share one big archive
<infinity> achiang: And security/sru support, when it overlaps with the set we care about.
<infinity> YokoZar: So, a flavour is in-archive and also uses our CD infrastructure.
<infinity> Err.
<infinity> achiang: ^
<achiang> https://wiki.ubuntu.com/DerivativeTeam/Derivatives
<YokoZar> So when derivatives are just packagesets from within the archive, they're implicitly supported.
<infinity> achiang: A remix may or may not be in-archive, but the images aren't built on our infra.
<infinity> achiang: And a derivative is out-of-archive.
<achiang> infinity: ok, then to support community "thingies" of ubuntu touch, the proper term would be remix, i think?
<achiang> infinity: where the thingies might have customized backgrounds, or new click packages, but otherwise share the same core of ubuntu
<infinity> achiang: If you've stopped using PPAs, touch is a flavour.  It's built from the Ubuntu archive, and uses Canonical infrastructure to build.
<infinity> achiang: Oh, a community port or mangling of Touch would be a remix, generally, possibly a derivative.  The line's fuzzy there.
<achiang> infinity: the context for this line of questioning is about what do i write in documentation to describe these "thingies" that communities might make
<achiang> infinity: see first paragraph here - http://people.canonical.com/~achiang/ubuntu_savvy/
<infinity> achiang: I think we might have official rules on what's allowed to call itself a "remix".  But it's definitely not a flavour.
 * infinity looks.
<achiang> infinity: i just want to be sure i'm using the term "remix" properly - so that i can ensure the docs everywhere use that term consistently
<infinity> achiang: I feel like this used to be mentioned in the trademark policy or something, but can't find it.
<achiang> infinity: yeah. google fails me
<infinity> And, in fact, it used to be.  In an older version.
<achiang> infinity: but based on your informal comments above, i think 'remix' is appropriate
<infinity> achiang: See the stale copy on http://www.ubuntu.org.cn/trademark-policy
<infinity> achiang: It has a whole section on remixes.
<infinity> achiang: (Might be worth taking up with legal as to why that policy seems to have died entirely and made this even more confusing)
<infinity> "A remix may not include software from any source other than the standard Ubuntu package archives, nor may it specify software sources / archives other than the standard Ubuntu package archives."
<infinity> So, by that standard, a Touch port that pulls kernels/drivers from AOSP/CM wouldn't be a remix.
<achiang> yeah
<infinity> But a Touch rebuild that tweaks configs or swaps out packages, would be.
<achiang> right - the sentence just prior seems to indicate what Savvy aims to do would produce mostly valid remixes
<achiang> infinity: thanks for this pointer
<infinity> achiang: Yeah, looks like savvy's goal is to produce remixes, pretty much to the letter of the law.
<achiang> infinity: yep. the one sneaky corner case is if a remix pre-installs a click package that is not from archive
<infinity> That would be a derivative, or would need Canonical approval.
<achiang> infinity: but i have a feeling that said click package would not violate the spirit of what a remix is defined as
<infinity> (Note the remix policy has^Whad a provision for blessed software sources)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: TheMuso
<infinity> achiang: Definitely worth taking up internally to revive the remix policy and dust it off and, indeed, start vetting pre-approved click packages that don't violate remixification.
<achiang> i mean, including that click package shouldn't change the spirit of whether your build output would deviate enough from Touch to be considered a !remix
<achiang> infinity: good advice. thanks
<infinity> achiang: Depends on the package.  Think, for instance, what happens to Android when you install that Facebook takeover thingee that pretty much turns your phone into a Facebook phone.
<infinity> achiang: We'd want some control over brand purity there, hence needing to review the clicks we'd approve people use and still call the product Ubuntu.
<achiang> infinity: true, but a click package can't do that in Ubuntu due to confinement, etc.
<achiang> infinity: and they wouldn't be able to produce that output with Savvy
<achiang> infinity: so at that point, the other trademark/derivative naming rules would kick in
<bdmurray> happyaron: is there a bug that fcitx in the saucy proposed queue fixes?
<achiang> infinity: thanks again
<infinity> achiang: True that a click is probably less scary since we don't allow replacing core functionality like Android does.
<infinity> achiang: But I'm sure someone will come up with creative ways to make a package that we don't really want our name attached to. ;)
<achiang> true
<achiang> Ubuntu Touch...ing You
<infinity> Ubuntu Bouncing Boobies Remix, etc.
<TheMuso> marcoceppi: Can https://bugs.launchpad.net/ubuntu/+bug/1292230 be considered the FFE for the package in question? If so, I don't see ubuntu-release as being subscribed...
<ubottu> Launchpad bug 1292230 in Ubuntu "Needs packaging: charmworldlib" [Undecided,In progress]
<infinity> achiang: I assume the intent here is for things like an "Ubuntu Touch T-Mobile Remix" that is basically Touch, but slightly more pink, and includes their VoIP app, that sort of thing?
<infinity> (Wishful thinking on the US Carrier there, I know)
<marcoceppi> TheMuso: sorry, I'm in #ubuntu-motu trying to figure out the process, I've just been following https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU
<achiang> infinity: that's exactly it
<TheMuso> marcoceppi: Ok.
<marcoceppi> TheMuso: I'm a bit lost in the process. I essentially need to get that package and another python package in to universe, then have charm-tools (already in universe) updated to 1.2.10 which is available and packaged already in a ppa
<infinity> achiang: Right, yeah, we definitely want to revive the policy and add some click review addendums, I think.
<achiang> infinity: we want to provide a tool that both commercial OEM engineering teams and our existing community can use to produce remixes
<achiang> infinity: i'll kick off a mail
<infinity> achiang: I don't suppose there's any plans to do the cute things Android used to do with carrier settings keyed off SIM cards?
<TheMuso> marcoceppi: I'll continue this in #ubuntumotu, since thats where you were.
<infinity> achiang: (My old, old Android phone used to actually change some UI colours when you stuck a T-Mobile SIM in, totally threw me the first time I saw it)
<marcoceppi> TheMuso: thanks!
<achiang> infinity: hm, you mean things like provisioning?
<infinity> achiang: No, I mean visually.  Obviously we'd want to do invisible backend things for carriers, if we can.
<achiang> infinity: ah. well... no one has asked for that feature yet
<achiang> infinity: but i'm not philosophically opposed
<infinity> achiang: But allowing them to define their "remix" in the distro, but keyed of SIM insertion is a fun trick.
<infinity> s/of/off/
<infinity> To be fair, I think Android gave that up.  My Kit Kat phone doesn't appear to turn pink when I switch to TMo. :P
<achiang> infinity: it would be a matter of our developer bandwidth and any commercial agreements (which would reallocate said bandwidth ;)
<xnox> infinity: achiang: well on touch images we preinstall clicks _only_ from the click store. Thus it would still be a remix if it preinstalls clicks from the ubuntu store.
<infinity> xnox: I'm not entirely sure I'd agree, depending on what we end up allowing in the store.
<infinity> xnox: But I haven't seen what policies are being applied there.
<infinity> (Note that "it installs a bunch of packages from the archive" wasn't good enough for a remix either, it needed to maintain brand coherence)
<xnox> infinity: well, true, we only preinstall those that come from the blessed account and get listed in the http://people.canonical.com/~ubuntu-archive/click_packages/click_list thus it's a very small subset.
<infinity> xnox: Kay, but what you preinstall and what achiang is letting OEMs do are not the same thing. :P
<infinity> Or, potentially.
<xnox> infinity: sure :P
<achiang> xnox: infinity: i'm not too worried about the OEM case - we will ensure they get their click apps into our store
<infinity> achiang: Right, but even if it's in the store, that doesn't magically make preinstalling it match our previous remix policy.
<achiang> right
<infinity> achiang: For instance, if "only installs stuff from the archive" was the only requirement, Kubuntu would be a remix.  It's clearly not.
<xnox> infinity: the only remix i remember, was a business remix that installed stuff from the partner repository i think, no?!
<infinity> xnox: There are dozens.
<infinity> xnox: Mostly people remixing for localization, but there are others.
<infinity> xnox: And the "business remix" was a special and weird case, since it was produced by Canonical, who owns the Ubuntu brand, so we didn't really have to play by the rules (though we certainly should, so we don't look like jerks).
<xnox> yeah, from the announce "everything in the remix is available from the standard Software Centre" http://www.markshuttleworth.com/archives/1002
#ubuntu-devel 2014-03-14
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<TheMuso> @pilot out
<TheMuso> oh already done. :)
<happyaron> bdmurray: well no, it's a small feature, and the cooperation project is still private.
<pitti> Good morning
<pitti> bdmurray: in principle yes; but that would need more cleverness in sandboxutils/the apt_dpkg to retrieve versions which aren't published in the archive any more (i. e. not in apt) directly from LP
<mitya57> rsalveti: thanks for pyqt5 upload!
<mitya57> In case someone is interested, I pushed a branch to fix qt3d FTBFS, waiting for CI approve.
<Noskcaj> pitti, thanks for the uploads
<Noskcaj> Any chance you could improve the testimonial you gave me? https://wiki.ubuntu.com/Noskcaj#MOTU
<pitti> Noskcaj: ah, looking
<pitti> Noskcaj: done now; http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=Martin+Pitt&sponsor_search=name&sponsoree=Jackson+Doak&sponsoree_search=name now looks fairly impressive :)
<sarnold> ubuntu-dev.alioth.debian.org? :)
<sarnold> wow, that's impressive :)
<Noskcaj> thanks Pici
<Noskcaj> oops, pitti
<pitti> Noskcaj: thanks to you!
<mitya57> sarnold: That webpage uses Ultimate Debian Database, that's why it is there
<sarnold> mitya57: oh man, that's even cooler :)
<dholbach> good morning
<mitya57> Mirv: Should I do anything special with my qt3d MP to trigger CI?
<Mirv> mitya57: I was also wondering why it's not working, I'll ping CI folks at #ubuntu-ci-eng
<mitya57> Mirv: thanks
<mightyiam> Since the trusty updates today I can't type in any other language than English.
<dholbach> seb128, can you reproduce bug 1292382?
<ubottu> bug 1292382 in totem (Ubuntu) "totem: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory" [Undecided,New] https://launchpad.net/bugs/1292382
<seb128> dholbach, uninstall libhybris?
<dholbach> ah ok
<seb128> that diverts the libGL
<dholbach> I wanted to try out the unity8 desktop session - that's probably where I got it from :)
<seb128> well, just guessing from the title, but that's usually the issue when we see that error
<seb128> yeah
<seb128> it's a bit unfortunate that it screws libGL for desktop users this way
<RAOF> seb128, dholbach: You're looking at bug #1291761
<ubottu> bug 1291761 in qtubuntu (Ubuntu) "Depends on libhybris on the desktop" [Critical,Confirmed] https://launchpad.net/bugs/1291761
<seb128> RAOF, well, from the title solving that issue wouldn't solve the problem, that problem keeps happening through different components
<seb128> RAOF, we should just make libhybris less destructive for desktop users
<seb128> like make it not divert your libGL by default
<RAOF> But it kinda has to.
<RAOF> I don't know if it's possible, but the right behaviour would be âdivert if there's an underlying Android stack for hybrisâ.
<dholbach> seb128, confirmed, that's the problem
<seb128> dholbach, great
<seb128> RAOF, right
<dholbach> seb128, shall I mark it as a dup of 1291761?
<seb128> but yeah, not having unity8 pulling it in would already be a good thing
<seb128> dholbach, yes please
<dholbach> done, thanks
<chrisccoulson> hmm, it seems that https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.9.2+14.04.20140305-0ubuntu1 has migrated from proposed, but it built against qt5.2 which hasn't migrated yet (and depends on some symbols introduced in 5.2)
<rbasak> jamespage: python-websocket-client (indirect dependency of juju-quickstart) is behind PyPI. It's an Ubuntu-only package. I don't see any reason to break FF and bump it now, but that isn't good for MIR and maintanence. Do we have any system for tracking outstanding watches in Ubuntu?
<jamespage> rbasak, no and that sucks
 * jamespage tries to remember something
<rbasak> We could quite easily create a report that just looks for -0ubuntu packages and runs uscan
<jamespage> rbasak, is the latest 0.12.0 ?
<rbasak> Yes
<jamespage> right - we've got two packages providing the same version
<jamespage> one is incorrectly named
 * jamespage sighs
<jamespage> rbasak, python-websocket
<rbasak> https://launchpad.net/ubuntu/+source/websocket-client
<rbasak> https://launchpad.net/ubuntu/+source/python-websocket-client
<jamespage> rbasak, can I suggest we switch the dep in jujuclient and drop python-websocket-client
<rbasak> The first is in Debian.
<jamespage> yeah
<rbasak> jamespage: agreed. I'll take care of it.
<jamespage> thanks
 * rbasak wonders if this needs an FFe.
<jamespage> rbasak, I don't think so
<jamespage> its tidying
<jamespage> fundamentally the underlying python is the same
<rbasak> It's a version bump :)
<jamespage> rbasak,  trying to overwrite '/usr/lib/python2.7/dist-packages/websocket.py', which is also in package python-websocket-client 0.11.0-0ubuntu1
<rbasak> (for python-jujuclient)
<rbasak> OK well that's a bug :)
<jamespage> rbasak, lets ask kapil
<jamespage> rbasak, but I don't think it will be an issue
<jamespage> rbasak, this is my bad for never pushing this package back up to debian
 * jamespage either forgot or ran out of time
<geser> rbasak: something like http://qa.ubuntuwire.org/uehs/no_updated.html for tracking watch files?
<jamespage> rbasak, urgh - the package from debian is not really named correctly IMHO
<rbasak> jamespage: why? It matches the upstream tarball name, right? What's the correct way to do it?
<jamespage> rbasak, the name of the python project is websocket-client
<jamespage> the name of the binary from Debian is python-websocket
<jamespage> when dh_python2 does its business it auto-generates a dependency on python-websocket-client
<jamespage> naming convention being python-(project-name)
<rbasak> geser: thanks! Though I don't see this websocket thing in there, and am not sure why.
<jamespage> but I can think of other things that don't follow that
<jamespage> barry, care to give an opinion on the above?
<rbasak> I presume the binary name difference stopped this issue being flagged up before, too.
<rbasak> jamespage: "The binary package for module foo should preferably be named python-foo, if the module name allows..."
<rbasak> jamespage: since it provides websocket.py, I think the right binary package name would be python-websocket.
<rbasak> So "import websocket" -> "apt-get install python-websocket"
<rbasak> jamespage: I've filed https://bugs.launchpad.net/ubuntu/+source/python-jujuclient/+bug/1292502
<ubottu> Launchpad bug 1292502 in python-websocket-client (Ubuntu) "python-websocket-client is a dupe of and conflicts with python-websocket" [Undecided,New]
<jamespage> rbasak, yeah - I guess so
<jamespage> so it aligns to the actual module name, not the upstream project name
<rbasak> The binary does, yes. I'd expect the source to align with the upstream project name, though that's just an assumption I made and I'm not aware of any policy around that.
<jamespage> rbasak, we'll need to insert an appropriate Breaks/Replaces/Conflicts on python-websocket to ensure it gets bumped from installs
<rbasak> jamespage: good point, thanks. I'll add a task for that.
<rbasak> At least we can drop that delta in U I suppose.
<jamespage> rbasak, I can confirm that python-jujuclient appears functional with python-websocket
<rbasak> Thanks
<jamespage> but we'll need to add a pydist-override to map websocket-client -> python-websocket
<rbasak> ack
<rbasak> jamespage: https://github.com/liris/websocket-client/issues/60 'websocket' clashes with other popular python libraries
<jamespage> rbasak, nice
<rbasak> And the test suite is missing from the Python sdist.
<rbasak> This seems to be a really common thing (things missing from the sdist tarball)
 * rbasak files a github issue for that
<xnox> ..
 * xnox IT'S IN!
<xnox> ..
<didrocks> (be scared) ;)
<davmor2> I don't won't to know what xnox is doing
<xnox> davmor2: Qt5.2
<davmor2> \o/
<lamont> The following packages have been kept back:
<lamont>   libdb-dev tk8.5
<lamont> I wonder if I care
<barry> jamespage: did you guys figure it out?
 * lamont manually installs them and watches the package shuffles
<jamespage> barry, I think so yes
<barry> jamespage: cool
<rsalveti> seb128: I'm investigating the hybris issue today
<rsalveti> just need a clean up and split some other pieces (input), then we shouldn't have anyone depending on it at all
<rsalveti> qtubuntu needs the input headers, creating all the mess
<seb128> rsalveti, hey, great, thanks!
<rsalveti> such as powerd
<bdmurray> happyaron: we don't generally SRU new features
<bdmurray> pitti: my thought was more that we could use that to notice ones that are published in the archive but just don't exist on the ddebs for whatever reason.
<hyperair> what's a good test for whether systemd is running as pid1 or not in ubuntu?
<hyperair> or rather, a good cross-distro way that doesn't check /sys/fs/cgroup/systemd, since that exists in ubuntu via systemd-shim
<hyperair> (inside a udev script)
<hyperair> er udev rule
<ScottK> systemd is never running as pid 1 in Ubuntu.
<ScottK> So if you are on Ubuntu (at least now) you know.
<cjwatson> hyperair: The sd_booted library function in systemd tests for whether /run/systemd/system exists and is a directory
<hyperair> cjwatson: oh nice thanks
<cjwatson> hyperair: /usr/bin/deb-systemd-helper does likewise (-d "/run/systemd/system")
<cjwatson> So I think that's the canonical answer
<hyperair> heh
<hyperair> alright
<cjwatson> Yeah, sd_booted(3) agrees
<hyperair> thanks
<pitti> hyperair, cjwatson: correct, that's the official upstream answer now (it used to be the cgroup, but we changed that for our case of running logind without systemd pid 1)
<xnox> cjwatson: i wonder if the $ initctl version; check as advocated by debian policy will start giving false positives, if we start running systemd as pid1 and system-upstart as pid2
<dholbach> asac, I think I have accidentally moved the landing taskforce calls in the calendar - they are at 9:30 utc in the morning, right?
<dholbach> ok, looks like they're fine again
<lamont> resizing windows by grabbing corners has become harder with trusty, and it seems that the upper left corner just doesn't want to recognize the mouse at all.  and then there's the occasional "oh you want full screen, sure" surprise.
<Meerkat> since a few version it seems you only have a 1 pixel thick border to do any resizing on
<Meerkat> lamont, alt+right click should work fine. Try it.
<Meerkat> alt+hold right mouse rather
<lamont> well... for these particular things,  alt-rtmouse gives me a menu, which happens to have 'resize' in it, so it works
<lamont> in times past, I may have smacked the theme into once again having a 10-pixel border....
 * lamont whistles
<Meerkat> 1 pixel dragable border is really silly
<Meerkat> good that you found a way
<ogra_> lamont, are you up to date on your trusty ? for me it is like a 20px area since there are no borders anymore ... way easier to grab
<lamont> I might not have restarted X this morning
<ogra_> ah
<xnox> lamont: in display, i've increased the UI scaling to give me everything just a tad bigger. It seems that grabbing area also increases.
<lamont> but it was currnet 2 days ago when I rebooted...
<xnox> lamont: are you on a better than 98dpi screen?
<ogra_> it might be psychological though ... i simply dont try to hit the 1px border anymore since it is gone :)
<xnox> lamont: (e.g. an HD or FULL-HD one)
<xnox> lamont: my top-left corner grab areas is the size of about half the title-bar height on the left edge of the screen.
<lamont> xnox: and when the window goes to the top of the display area, and bumps up against the bottom of the panel?
<xnox> lamont: oh, one is screwed when that happens =)
<lamont>   resolution:    96x96 dots per inch
<ogra_> thats the resolution X thinks you have :)
<lamont> xnox: the real question is, is that a bug, or is it considered a feature
<xnox> lamont: but, you just grab any portion of the top bar and drag down, it "un-maximizes" the window?!
<lamont> it's the resolution that the display thinks I have, too, I think... inspiron 5010
<lamont> xnox: nope.
<xnox> lamont: i see what you mean now, the grabers are fully gone one the edges meet. that's weird.
<lamont> once I drag it down, then I can grab it and resize it...
<lamont> somehow I suspect that this might be related to my 3x3 workspace topology
<xnox> i just have dual-screen and no workspaces, same problem.
<ogra_> xnox, btw, my GF has a yoga, do you have any script that switches off kbd/touchpad when in tablet mode for yours ?
<xnox> ogra_: something hacked up, yes. not quite reliable.
<xnox> ogra_: disable keyboard -> http://paste.ubuntu.com/7091051/
<xnox> ogra_: rotate screen & touchpad into vertical mode http://paste.ubuntu.com/7091052/
<xnox> ogra_:  i didn't hook that up to the setkeycode, but some gists on github have that fully working with a setkeycode.
<xnox> ogra_: kernel in trusty or 3.14 will have setkeycode mapped for that i think...
<ogra_> well, i would like to disable the touchpad altogether when it is in tablet mode ... but thanks with that i should find my way along
<xnox> ogra_: yeah, i think touchpad is another xinput thing one can disable. just check the args, it should have option to list all devices and thus find the touchpad.
<ogra_> yeah
<ogra_> thanks !!
<ogra_> something to do on the upcoming rainy weekend :)
<smoser> xnox, i realized yesterday that i had (possibly incorrectly) associated performance regression with your changes
<smoser> to plymouth. rather than with the fix that we wanted.
<jtaylor> doko is on vacation or? until when?
<slangasek> jtaylor: doko is currently unavailable; something you need that someone else can help with?
<jtaylor> I would like 1290287 fixed soonish
<jtaylor> but next week is probably ok
<infinity> jtaylor: I can fix that.
<jtaylor> infinity: thanks that would be great, it affects debian too, there is a patch in the bug there
<infinity> jtaylor: Yeah, I won't NMU to Debian unless it's urgent.  Is there an upstream commit for this?
<infinity> jtaylor: It's a bit disconcerting that the patch in the Debian bug is different from the one in the mailing list post you pointed at.
<jtaylor> hm didn't find a upstream VCS, but also didn#t search much
<jtaylor> yes my link is a old upstream reply
<jtaylor> I'll add the latest one which the patch is based of
<jtaylor> 34 instead of 31 in the link
<infinity> Ahh, this has the new one http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00034.html
<Noskcaj> stgraber, Mind if i package the new bugfix release for busybox? "1.21.1 has fixes for ntfs detection (big-endian fix), xz decompression of concatenated streams, mdev acquired a [ENV=regex;] extension instead of undocumented subsystem match hack it used to have prior to 1.21.x."
<infinity> Check.
<stgraber> Noskcaj: I don't mind it, though note that dealing with busybox config and making sure they are correct in all cases is very tricky. So I have the feeling it's one of those merges where the only way to make sure it was done right is to do it again yourself.
<stgraber> so I'm not against it but I doubt I'll have time to review it myself (since it's not a priority target for me at all)
<Noskcaj> Debian went straight to 1.22, so i'd just be merging a minor release from upstream
<stgraber> yeah, the problem is that our busybox build config is pretty different from Debian and upstream has a tendency to add/remove/rename config options all the time...
<infinity> jtaylor: Hrm, doesn't look to be committed upstream yet.  Oh well.
<jtaylor> there is this: http://lists.gnu.org/archive/html/bug-readline/2014-03/msg00040.html
<stgraber> so just swapping the source tarball and assuming that since Debian didn't change their config ours don't need to either, isn't a good plan at all and has been a problem in the past. You actually need to go through the upstream diff and make sure they didn't sneak some config renames in there
<Noskcaj> stgraber, ok. I'll leave that one then. The entire changelog was what i quoted above
<jtaylor> infinity: did you find an upstream source repo? url?
<stgraber> Noskcaj: sure, I just tend not to trust the changelog ;)
<Noskcaj> understandable
<jtaylor> a found it on savannah
<stgraber> and considering that a broken busybox tends to break all Ubuntu systems from booting, I prefer to keep what we have unless we're 100% sure it won't regress us
<stgraber> s/break/prevent/
<infinity> jtaylor: That look like what you tested? http://paste.ubuntu.com/7092227/
<jtaylor> infinity: yes
<infinity> Oh, I guess I should put a bug closure in there.
<infinity> jtaylor: Uploaded.
<jtaylor> infinity: great, thanks
<asac> dholbach: i think so :) ... ogra and didrocks should know for sure
<asac> ogra_: when is the morning landing team call?
<asac> ogra_: dholbach moved it accidentially, can you confirm it was 10:30 our time?
<ogra_> asac, yup ... all fine, i checked the calendar
#ubuntu-devel 2014-03-15
<sarnold> hrm, we still have samba4 source package in trusty/universe .. I thought that was going to be replaced by some small stubs to point to the samba package instead?
<Noskcaj> Can someone please look into syncing widelands? My internet is too bad to even ppa build it. Many packaging fixes, enables parallel build, manpage fixes
<zequence> Hi. I need some help figuring out debian/templates and debconf
<zequence> Not clear about how that works at all right now
<zequence> source lp:ubuntustudio-live
<zequence> I based that package on edubuntu-live
<zequence> stgraber: Perhaps I could ask you for hints on that?
<zequence> I'm reading a tutorial about debconf and templates right now, so hopefully I'll get it right sooner or later on my own :)
<zequence> I get lintian warnings..
<zequence> E: ubuntustudio-live: no-template-description ubiquity/text/ubuntustudio-packages_heading_label
<zequence> E: ubuntustudio-live: unknown-field-in-templates ubiquity/text/ubuntustudio-packages_heading_label _description
<zequence> Seems to me there might be something odd about the templates file in itself. I can't seem to figure out what though
<xnox> zequence: can you pastebin the whole templates file?
<xnox> oh, lp:ubuntustudio-live, let me check.
<zequence> xnox: I think I figured it out, but I'm still puzzled
<zequence> xnox: I changed "_Description:" to "Description", and now it seems to work
<zequence> "Description:"*
<xnox> zequence: sure, but you don't get translations, do you?
<zequence> No
<xnox> _ means that debconf-po will work to translate those fields.
<zequence> Ah
<zequence> xnox: Thanks for that info :)
<zequence> xnox: I'm just about finished with this package now. Just need to test it before I push changes. You think you could help out in getting it uploaded (all though it's really late for that)?
<xnox> zequence: so, i did mkdir debian/po, echo "[type: gettext/rfc822deb] templates] > debian/po/POTFILES.in; then I did debconf-updatepo pot from ./debian/ that generated templates.pot.
<xnox> and hopefully this will now work with translations.
<zequence> xnox: Ok, thanks
<xnox> zequence: https://code.launchpad.net/~xnox/ubuntustudio-live/debconf-updatepo/+merge/211174
<xnox> zequence: not sure if you already removed "_" or not.
<zequence> xnox: only locally
<xnox> zequence: templates.po is generated file, but one typically commits it.
<zequence> xnox: Alright. No bad lintian warning I think. So, you think I could get it uploaded?
<zequence> bug 946591
<ubottu> bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<zequence> I still need to fix our seeds after, and also update our meta - which hasn't been updated at all for trusty yet :P
<cjwatson> Trying to debug the dee-qt build on ppc64el is making me hallucinate
<cjwatson> 62              connect(&model_qt, &QAbstractItemModel::rowsInserted, [&num_insertions] (const QModelIndex &parent, int start, int end) {
<cjwatson> 63                  num_insertions++;
<cjwatson> step into that and I get:
<cjwatson> 64              });
<cjwatson> (gdb) p signal
<cjwatson> $5 = (void (QAbstractItemModel::*)(QAbstractItemModel * const, const QModelIndex &, int, int, QAbstractItemModel::QPrivateSignal)) 0x10016bf0 <QMapDataBase::createData()@plt+64>
<cjwatson> where on earth did it get that function from?
<cjwatson> powerpc has the same test failure; and there's actually not *that* much similar between powerpc and ppc64el, they're different word length and different endianness
<ScottK> Would it be possible for someone who has ppc64el to look at libktorrent installability.  It's been built for sometime, but libktorrent5 is apparently not installable.  It's blocking migration of some packages from proposed.  See https://launchpadlibrarian.net/169618637/buildlog_ubuntu-trusty-ppc64el.kget_4%3A4.12.3-0ubuntu1_FAILEDTOBUILD.txt.gz for an example.
<cjwatson> It's blocked on libgcrypt20 building
<cjwatson> (FWIW)
<ScottK> Thanks.
<ScottK> Is that likely to happen soon?
<ScottK> I'm wondering if we should do something specific to get kget and ktorrent to migrate.
<cjwatson> If the test suite didn't spew its log output to syslog (FFS) then I might be able to see the details
<cjwatson> I might try to look on Monday.
<infinity> cjwatson: Err, it is?
<infinity> (base)adconrad@cthulhu:~$ reverse-depends libgcrypt11 | grep ktorrent
<infinity> * libktorrent5 [amd64 arm64 armhf i386 powerpc]
<infinity> (base)adconrad@cthulhu:~$ reverse-depends libgcrypt20 | grep ktorrent
<infinity> * libktorrent5 [ppc64el]
<infinity> So, that looks like it would be easy to fix. :P
<infinity> I'm very tempted to remove libgcrypt20 from trusty, actually.  Every time a libgcrypt-depending package is rebuilt, it magically switches (which has only happens once so far on all arches, and 3 times on ppc64el).
<infinity> I don't think this is a desirable outcome for SRU/security.
<infinity> cjwatson: ^-- Opinion?
<infinity> slangasek: ^-- Or you?
<cjwatson> infinity: haha seriously
<cjwatson> infinity: there are a few rdeps, but maybe they're not too bad.  I can see your point ...
<infinity> cjwatson: I've just rebuilt all the things that have deps on 20, by forcing build-deps, but I think we're shooting ourselves in the foot post-release if we don't just yank 20 now.
<cjwatson> Yeah, not a terrible argument
<infinity> Right, I'll JFDI as soon as the rdep list is clean.
<infinity> And we can bring it back in U, promote it to main, and do a more coordinated transition instead of an accidental one. :P
<Unit193> When it comes to https://bugs.launchpad.net/bugs/1060543, should I just presume I'm close enough in the desktop file, request a merge, then subscribing someone to that merge request?
<ubottu> Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress]
<juliank> bdmurray: Hey, I'm about to upload the python-apt changes from 0.9.3.2ubuntu{1,2} to Debian as 0.9.3.3. (And I feel bad about forgetting that bug after my comment, but launchpad is far too noisy, so I delete many emails directly, mostly if I can't keep up with other emails)
<juliank> Just wanted to let you know.
 * juliank merges patches / fixing bugs in less than a day currently. No university!
<bdmurray> juliank: thanks
 * juliank should request per-package upload rights
<infinity> Alright, libgcrypt20 completely purged from trusty.
<infinity> ScottK: Your ktorrent woes should be solved.
<ScottK> infinity: Thanks.
<infinity> Hrmph, that lftp Bus Error seems to be back.
<infinity> cjwatson: ^-- Have you noticed that on snakefruit?  Or mailbox seems to be full of it.
<cjwatson> infinity: I read that mailbox *cough* infrequently
<cjwatson> I recently found >8000 cronmail entries in cjwatson@nusakan - possibly should arrange for that to be forwarded somewhere useful
<infinity> cjwatson: Yeah, I only read it when the shell reminds me that new mail just happened.
<ogra_> shoulld probably become an IS default practice to set up mail forwarders for user accoounts they create :=
<ogra_> :)
 * ogra_ has no idea if any machine in the datacenter has any cron mails for him, i honestly *never* checked
#ubuntu-devel 2014-03-16
<ari-tczew> hi. we are already in UserInterfaceFreeze. can I upload a new upstream bug-fix only release without FFe?
<bluesabre> greetings sponsors, would somebody like to upload light-locker-1.2.1 to trusty?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1293100
<ubottu> Launchpad bug 1293100 in light-locker (Ubuntu) "[needs-packaging] light-locker 1.2.1" [Undecided,Confirmed]
<bluesabre> This release addresses a security concern, if light-locker is not currently running when light-locker-command "locks" the screen, the user is sent to vt8 without their session protected
<bluesabre> this does not send to a new VT if light-locker is not running, instead producing a message that it is not running (similar to how xscreensaver behaves)
<bluesabre> please let me know if there are any questions :)
<Riddell> mardy: hopeful sunday ping?
<juliank> bdmurray: python-apt can be synced now again, let us avoid the diff, even if its small (sync request: bug 1293193)
<ubottu> bug 1293193 in python-apt (Ubuntu) "Sync python-apt 0.9.3.3 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1293193
<juliank> There are really no other changes apart from merging the Ubuntu changes.
<juliank> It's not the most useful sync currently, but it should help (if no other changes will be done), to get automatic syncs then after trusty release.
<Laney> juliank: I can do that - or is there some reason you asked bdmurray directly?
<juliank> Laney: Fine with me. I just told him, because he did the last two uploads.
<Laney> fair
<infinity> juliank: Iz done.
<juliank> infinity: thanks, cool.
<Laney> Weird, I just said I was doing it
<Laney> Anyway, good
<infinity> Laney: Oh, I read that how you wrote it "I can do that".  And then went and looked, and you hadn't, so assume you meant that you can, not that you were going to. :P
<Laney> Yeah, I was test building and the making a cup of tea :P
<Laney> No matter
<infinity> Ahh, I didn't test build.  If it's FTBFS, then so would the previous version have been if rebuilt, so buggy either way.
<juliank> Is there a project on launchpad about Ubuntu mirrors where I can reassign bug 1027905 to=
<juliank> ?
<ubottu> bug 1027905 in python-apt (Ubuntu) "Ubuntu Mirror ar.archive.ubuntu.com points to a Brazilian Server" [Undecided,New] https://launchpad.net/bugs/1027905
<highvoltage> ue/win 12
<infinity> juliank: That's not necessarily a bug at all, if the .ar servers have been deemed to not be able to handle the load or something.
<juliank> infinity: Maybe, but it's most definitely not a python-apt bug. So I just reassigned it to Ubuntu (without a package) for now.
<infinity> juliank: But #ubuntu-mirrors is probably the right place to redirect it to.
<infinity> juliank: Not sure if there's an approriate LP project, but they'd know.
<Thedemon007> ubuntu have secuity issues in chromium-browser ?? version ubuntu 32.0.1700.107 debian: 32.0.1700.123 http://metadata.ftp-master.debian.org/changelogs//main/c/chromium-browser/chromium-browser_32.0.1700.123-1~deb7u1_changelog
<Thedemon007> The changelog of ubuntu does not show much information. Chromium.org say linux	stable 33.0.1750.152
<petersaints> hi guys. I'm having a problem with the Network Manager. It gets the correct IPv6 adresses for my /64 prefix (a MAC based one and another through IPv6 privacy extensions). They show up on ifconfig but they do not show up on "nm-tool" output (the information is also missing from the GUI). I have a feeling that this was working ok up until a few days ago, so I'm not sure if there was some update that broke this. Anyone has an idea about
<petersaints> this issue? I was searching for bugs on launchpad and the most similar think I could get was this old and Invalid bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/375088
<ubottu> Launchpad bug 375088 in network-manager (Ubuntu) "IPv6 addresses are hidden" [Low,Invalid]
<petersaints> Also, if I set the address manually it sows up just ok.
<petersaints> I forgot to mention that I'm running Trusty ;)
#ubuntu-devel 2015-03-09
<pitti> Good morning
<pitti> Riddell: we also want to move to systemd on upgrades, yes; I'm uploading the bits now
<pitti> Riddell: stdout for user session programs usually goes to ~/.xsession-errors, unless there's a session upstart job; they they go to ~/.cache/upstart/
<pitti> mardy: no, usually mocks should be in the tests that use them; python-dbusmock has a few for common services, which avoids having to copy them between several packages
<pitti> Saviq: https://wiki.ubuntu.com/Touch/Testing#Running_tests_with_autopkgtest is the TL;DR documentation with pointers to details
<pitti> jamespage: the "TemplatePluginNotRegistered"? some python update got in the way?
<pitti> jamespage: there are still some problems with mongodb and some others; I did a first mongodb fix yesterday, but I'll keep poking too
 * pitti unleashes the madness in bug 1427654
<ubottu> bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,Fix committed] https://launchpad.net/bugs/1427654
<pitti> jamespage: mongodb fix uploaded; I'm looking into the openvswitch failure, I know what the reason is
<pitti> jamespage: that's due to bug 1429734 FYI
<ubottu> bug 1429734 in sysvinit (Ubuntu) "invoke-rc.d ignores dependencies in degraded mode" [High,In progress] https://launchpad.net/bugs/1429734
<dholbach> good morning
<pitti> jamespage: I filed bug 1429739 for neutron, do you have an idea about that exception?
<ubottu> bug 1429739 in neutron (Ubuntu) "neutron-server does not start under systemd: OperationalError: (OperationalError) no such table: ml2_vlan_allocations" [High,New] https://launchpad.net/bugs/1429739
<pitti> jamespage: ah, happens under upstart too, bug updated
 * pitti looks at mysql-5.6 now
<rbasak> pitti: o/
<pitti> hey rbasak, how are you?
<rbasak> I'm just back from a week away, catching up now.
<pitti> rbasak: ah, did you have a good time off?
<rbasak> Yes thank you
<pitti> infinity, Laney: can we please add a force-badtest on current upstart? I just filed bug 1429756, and I'm not lucky enough to hit a time when it manages to succeed on both arches
<ubottu> bug 1429756 in upstart (Ubuntu) "test_job_process fails in majority of cases" [High,New] https://launchpad.net/bugs/1429756
<pitti> rbasak: oh, you have commit on debian's mysql-5.6? I'm currently building a fix for enabling the systemd unit, so that mysql starts on install and its test will succeed again
<rbasak> pitti: yes, though I thought systemd support was added to mysql-5.6, although I didn't work on that directly. Does it not work?
<pitti> rbasak: nope, little detail is missing :)
<rbasak> :-/
<pitti> rbasak: http://paste.ubuntu.com/10567186/
<rbasak> Sorry. Happy to take your patches in Debian :)
<pitti> rbasak: without that, the dh_systemd_enable part never gets run
<pitti> so the unit is disabled, and thus never starts
<rbasak> Ah, OK.
<rbasak> pitti: want me to push that to Debian VCS now?
<pitti> rbasak: it's certainly correct, but I'm not 100% sure yet whether it's sufficient, or something else needs updating too
<rbasak> OK, I'll hold on then.
<pitti> rbasak: once my sbuild finishes and I ran the autopkgtest locally, I'll give you the go
<pitti> rbasak: btw, it still hasn't promoted from -proposed, it makes some percona-*.5.5 stuff uninstallable
<rbasak> Yeah, I need to fix the percona-galera-3 FTBFS
<pitti> rbasak: anyway, you'll stumble over this during your mail catch-up for sure :)
<rbasak> :)
 * pitti doesn't envy yo
<pitti> u
<rbasak> I'm sure your inbox is far worse after a week off :)
<pitti> rbasak: I'm going to find out soon; I'll have 1.5 weeks of holiday from next week on :)
<rbasak> So 50% worse, + the 50% pitti extra workload premium? :-P
<pitti> rbasak: *shrug* I just switched the init system; what can *possibly* go wrong!
<rbasak> Ah. Now I understand the carefully timed planning going on there :-P
<ogra_> pitti, well ...
<ogra_> The following packages have unmet dependencies:
<ogra_>  systemd-sysv : Conflicts: upstart but 1.13.2-0ubuntu9 is to be installed
<ogra_> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
<pitti> ogra_: ah, mind running that with -o debug::PkgProblemResolver=true ?
<LocutusOfBorg1> hi folks!
<pitti> ogra_: I suppose that's apt-get dist-upgrade?
<ogra_> pitti, if i only knew how to do that on the livefs builder :)
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu
<ogra_> thats an image build
<pitti> ah
<ogra_> https://launchpadlibrarian.net/199721670/buildlog_ubuntu_vivid_amd64_ubuntu_BUILDING.txt.gz
<pitti> ogra_: that's ubuntu or touch?
<ogra_> last build log
<ogra_> no, desktop
<ogra_> the normal iso
<davmor2> pitti: dun broked it!
<davmor2> pitti: now I know you heart is in QA :)
<pitti> ogra_: the init-system-helpers package migrated much later, could it be that it didn't yet see that one?
<ogra_> when ?
<pitti> no, that's ok
<ogra_> this build is from 1h ago
<pitti> I: Retrieving init 1.22ubuntu4
<cjwatson> it's a priority mismatch
 * ogra_ remembers he read somethin about changing the order of deps 
<ogra_> yeah
<cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.html
<ogra_> was about to say that :)
<cjwatson> causes upstart to be in debootstrap's result
<pitti> wow, that exploded
<cjwatson> plymouth dropped to standard, was that intentional?
<pitti> I also don't quite understand all the initramfs, iproute2 etc. changes
<cjwatson> upstart probably has a transitive dependency on initramfs-tools
<cjwatson> and it certainly depends on ifupdown
<cjwatson> but those are also explicitly seeded in minimal, hence priority important
<cjwatson> anyway, the required -> important changes are probably just fine; plymouth is the only questionable thing there IMO
<ogra_> they phone wouldnt mind for it to be in standard :)
 * ogra_ could drop a bunch of hacks 
<cjwatson> I guess
<pitti> plymouth is in ubuntu-standard, that sounds ok?
<ogra_> buut i highly doubt it is intentional
<cjwatson> I guess it makes sense actually, yeah
<pitti> i. e. before upstart had a transitional dependency to plymouth?
<ogra_> mountall ...
<cjwatson> so yeah, go ahead and process that bunch and then the livefs build should be happy again
<pitti> ack
<ogra_> it needs it for fsck communication with the user
<Laney> pitti: upstart force> I guess---could you strongarm jodh or someone into looking? :-)
<ogra_> systemd doesnt do that ?
<pitti> ogra_: it does, but only if plymouth is installed
<ogra_> ah, cool
<pitti> otherwise it just gives you the feedback on the text terminal
<pitti> (for servers mostly)
<ogra_> thats quite an innovatiion
<pitti> ogra_: text terminals? yeah, awesome new stuff, try them!
<pitti> :-P
<ogra_> text terminals without having to use a plymouth text theme to interact with them :P
<pitti> rbasak: all good, can you please commit that fix?
<pitti> rbasak: shall I upload it now, or do you have something else queued for mysql-5.6?
<ogra_> (and not needing plymouth (and this nvidia and ati drivers in the initrd) even on non-plymounth systems
<ogra_> s/this/thus/
<ogra_> (or fonts)
<ogra_> it will massively shrink our initrd ;)
 * pitti hears a faint sense of approval from ogra_
 * ogra_ nods wildly
<ricotz> pitti, hello :), did you got reports yet, that some post-installation-trigger causes plymouth boot/shutdown screen to show up (while running systemd)?
<pitti> ricotz: debian bug 779606, I think
<ubottu> Debian bug 779606 in systemd "daemon-reexec starts plymouth-start.service service" [Important,Open] http://bugs.debian.org/779606
<pitti> ricotz: but please file an Ubuntu one if you are unsure
<pitti> ricotz: but post-isntall triggers shouldn't daemon-reexec, just daemon-reload
<ricotz> pitti, i see, will try to reproduce and narrow it down, but it happens when installing updates of some specific packages, iirc it didnt happen with 218
<pitti> ricotz: I think I see this in a VM on daemon-reload; I don't see it on my laptop
<pitti> rbasak: I uploaded the fixed -5.6 now
<pitti> dholbach: hallo, wie gehts?
<pitti> dholbach: there are some broken links on http://packaging.ubuntu.com/html/auto-pkg-test.html , where can this be fixed again?
<pitti> jodh: good morning
<pitti> jodh: your mk-sbuild trouble are the same as the above live build failure; should be resolved with next publisher run
<zyga> pitti: hey, what can I do to synchronize pyotherside to vivid?
<ogra_> use requestsync i guess
<ogra_> (sp ?)
<zyga> thanks. I'll read about that
<pitti> zyga: I can do it; ok to remove ubuntu changes? (I remember our conversation from two weeks ago, but cross-checking)
<zyga> pitti: yes
<zyga> pitti: exactly as we discussed before
<pitti> zyga: what's your LP ID?
<zyga> pitti: quick question: on the debian package index I see pyotherside 1.4 in experimental with (rc-buggy) next to it, what does that mean?
<zyga> pitti: zkrynicki
<pitti> zyga: hm, I don't know; https://tracker.debian.org/pkg/pyotherside has no bugs at all
<pitti> zyga: where do you see this?
<pitti> zyga: (synced)
<zyga> pitti: https://packages.debian.org/search?keywords=pyotherside&searchon=names&suite=all&section=all
<zyga> pitti: in experimental
<zyga> pitti: (thanks!)
<pitti> zyga: hm, no idea about that
<dholbach> pitti, lp:ubuntu-packaging-guide - or just let me know which ones to fix
<pitti> dholbach: README.package-tests (and similar) in git were renamed/reformatted to *.rst a while ago
<pitti> and in /usr/share/doc/ too
<dholbach> pitti, ok
<pitti> jodh, ogra_: http://people.canonical.com/~ubuntu-archive/priority-mismatches.html is once again empty, image/schroot build should work again
<pitti> dholbach: danke! https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/autopkgtest.fix/+merge/252257
 * dholbach hugs pitti
 * pitti hugs dholback
<Laney> is that "dholbach back"? :)
<pitti> Laney: yeah, SCNR :)
<dholbach> :)
<rbasak> pitti: thanks. Pushed to Debian VCS.
<pitti> rbasak: cheers
<pitti> rbasak: I'm looking at apache2 now, specifically the ssl-passphrase test
<pitti> Mar 09 11:40:47 autopkgtest apache2[4384]: No way to ask user for passphrase
<pitti> rbasak: is that supposed to ask on the console?
<rbasak> pitti: I've seen some fixes for that in Debian
<pitti> i. e. an interactive init.d script?
<rbasak> pitti: the Ubuntu delta added plymouth prompting
<pitti> I can teach the unit to grab the TTY, but that's a bit "eww"
<pitti> I mean interactively prompting during boot, not the tty thing
<pitti> doesn't that kind of break on remote servers?
<rbasak> It does, but I think it's fair to assume that if the sysadmin sets an SSL cert that requires a passphrase, he expects to be prompted.
<pitti> ok
<rbasak> Alternatively he can use a cert without a passphrase, and he won't be prompted :)
<jpds> Shouldn't it just do what luks does?
<rbasak> jpds: what do you mean exactly?
<rbasak> My home server uses https://github.com/basak/netkeyscript to unlock LUKS :)
<pitti> rbasak: but there's no plymouth while the autokpgtest runs
<rbasak> jpds: do you mean prompt via plymouth, or something else?
<jpds> rbasak: Yes.
<pitti> so it could at most be on the console
<rbasak> pitti: in that case I think it should fall back to tty?
<pitti> and the test uses an expect script
<rbasak> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773405 seems relevant here
<ubottu> Debian bug 773405 in apache2 "systemd: Systemd cannot restart apache2.service because of SSL certificate with password" [Important,Fixed]
<rbasak> pitti: looks like a merge for Debian may be appropriate - I only see bugfixes
<pitti> rbasak: yes, I'll check the diff and what they did here
<pitti> ah, they added exec /bin/systemd-ask-password, which we don't have
<jpds> rbasak: netkeyscript> Scary.
<rbasak> jpds: I use a crossover cable
<rbasak> Then replug it back onto the LAN.
<pitti> rbasak: they also slightly changed the prompt string, hmm
<rbasak> Easier than carting a keyboard and monitor to the server
<rbasak> pitti: maybe the prompt string didn't work with a \n in it?
<pitti> rbasak: well, I'm happy to do the merge and test it both ways; changes in -9 look fine
<pitti> rbasak: newline works fine, I suppose they just liked their's better; our autopkgtest specifically tests Debian and Ubuntu strings)
<rbasak> pitti: if you don't mind, please go right ahead. I'm going to be a while before I'm caught up :-/
<pitti> rbasak: no, that's fine; thanks for the heads-up
<pitti> rbasak: I meant, yes, I'll merge
<rbasak> ack, thanks
<smb> pitti, Hi, just a quick question: is it expected that doing a dist-upgrade on a server based install does _not_ try to remove upstart?
<pitti> smb: no, not expected, they should be transitioned too
<pitti> smb: do you have ubuntu-standard installed?
<smb> pitti, No, those have server^ as a base
<pitti> smb: ah, and we don't upgrade tasks on servers
<smb> Hm, ok... should probably check whether installing form a server cd would pull in ubuntu-base, too nowadays. (these are kind of special installs going from a debootstrap into a bootable state)
<pitti> smb: there's no ubuntu-base, we have ubuntu-minimal (which depends on "init"), ubuntu-standard (which depends on systemd-sysv), and then things like ubuntu-desktop
<pitti> smb: would you mind filing a bug about the server upgrade? we need to figure out how to do that then, we need some kind of "server" (meta?)package to pull in systemd-sysvinit then
<smb> pitti, I actually tried to type ubuntu-standard... damn fingers
<smb> pitti, Yeah, will do after checking a "proper" cd install
<Tribaal> guys, so I don't know if that's expected, but LXC seems to break since the switch to systemd
<pitti> Tribaal: not expected; I've used it for months under systemd, can you please file a bug with details?
<infinity> pitti: We can work around that in do-release-upgrade, but there's nothing we can do for bare debootstrap+(some packages) installs short of making systemd-sysv essential, which we opted not to do.
<Tribaal> pitti: so, maybe I'm doing something wrong then
<infinity> pitti: (This is why the buildd chroots still have upstart in them until I forcefully rebuild/upgrade them too)
<Tribaal> pitti: so, I killed a vivid container and restarted it and everything seems fine again... scratch that.
<smb> infinity, Ok, so that means if a real server cd install does change correctly, what I see with the special install is no bug but rather expected
<smb> gah, why on earth is grub trying to install into the lvm partition after being told to use the mbr...
<pitti> rbasak: ok, apache2's tests now run fine; expect doesn't work with systemd-ask-passphrase, so I added another little responder to that
<rbasak> Thanks!
<doko> rbasak, you added a block-proposed on a juju-core issue. any reason for that?
<cjwatson> doko: The text of the bug seems to explain it quite adequately
<doko> cjwatson, sorry, a SRU request to block an update to an existing version? what do I misunderstand?
<cjwatson> doko: Well, it's not just an SRU request is it n ow
<cjwatson> *now
<rbasak> doko: we have an SRU exception for Juju, so new releases theoretically should land in Vivid and stable releases concurrently (server users care only for Precise and Trusty really).
<cjwatson> I believe there's something quite subtle about juju major version upgrades where they don't work right until they're registered in upstream simplestream as well
<rbasak> Right - I want packages to land in Vivid and Trusty only after upstream have published the simplestreams data for it for an official release.
<cjwatson> But as a general point it seems unhelpful to say "any reason for that?" when there are reasons given in the bug.  If you don't like the reasons, explain why
<infinity> cjwatson: He doesn't like the reason cause it's blocking his upload. :P
<rbasak> But we want to coordinate testing before that, so they don't release until Ubuntu -proposed has binaries and they can test those too.
<infinity> But it's blocked on ppc being FTBFS anyway.
<infinity> So meh.
<doko> yeah, I saw that too
<rbasak> IIRC, there were issues with the 1.21.1 proposed release, so I was asked to hold - presumably pending a newer upstream proposed release. I need to check with upstream.
<rbasak> What are you blocked by?
<infinity> rbasak: He mangled your build-deps.
<infinity> http://launchpadlibrarian.net/199658027/juju-core_1.20.14-0ubuntu2_1.20.14-0ubuntu3.diff.gz
<rbasak> Ah, OK
<rbasak> Looks like I never actually uploaded 1.21.
<rbasak> So I think that should be OK to push through.]
<mlankhorst> can someone on the ubuntu-release team ack https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1424980 ?
<ubottu> Launchpad bug 1424980 in xorg-server (Ubuntu) "[ffe] xorg-server 1.17" [High,New]
<infinity> mlankhorst: Is fglrx still not ready?
<mlankhorst> no :/
<infinity> mlankhorst: Well, not much to ACK, then.
<pitti> rbasak: https://jenkins.qa.ubuntu.com/job/vivid-adt-mysql-5.6/lastBuild/? \o/
<rbasak> \o/
<rbasak> Thank you!
<mlankhorst> infinity: if lucky it will be there soon, could I get a conditional ack depending on fglrx at least?
<pitti> rbasak: that won't magically fix the perowossname issue of course, but my stack of "Jenkins Failed" mails is slowly getting smaller :)
<infinity> mlankhorst: Not sure what good a conditional ACK does you, you can't half upload it. :P
<mlankhorst> all the paperwork being done mostly..
<infinity> mlankhorst: Yes, I think updating to 1.7 is probably the right thing to do, but there's no point examining it until we know it won't break fglrx.  If fglrx comes too late, we won't risk it.
<pitti> do we still require flgrx?
<pitti> in the sense of, is the free driver still not good enough?
<pitti> (it seemed to be quite nice many years ago, then I stopped buying non-Intel graphics hw)
<mlankhorst> it has some features not in the free driver, and in some cases it works when the free driver doesn't.. but other way around is true too
<infinity> pitti: The free driver is decent for desktop use, fglrx is still better for gaming.  Kinda hoping that's not true in another year or two, as AMD was dumping resources into radeon.
<infinity> They at least have a plan to kill fglrx, which is more than I can say for nvidia.
<mlankhorst> nvidia uses the nouveau stuff for their K1 :P
<rbasak> I've been all-Intel for years, but have been considering buying an AMD/ATI/whatever setup recently.
<mlankhorst> not on desktop yet thoug
<infinity> rbasak: The price/performance ratio for AMD video cards is hard to pass up.  The absolute top end flip-flops every 6mo between AMD and nvidia, but if you're buying middle of the road, AMD's been winning at cheap for years.
<infinity> rbasak: But if you're doing high end 3D in Linux, the drivers matter a lot more than the cards, and fglrx is a flaming heap compared to the nvidia binary driver. :/
<infinity> (For a Win32 gaming box, though, I'd recommend AMD any day of the week, unless you have thousands to burn)
<rbasak> When it's working presumably. I don't want to be beholden to a binary driver though.
<rbasak> Or, if I have to do it, then at least have the choice of a free driver that is reasonable.
<StevenK> I've found Nividia better for the dual boot case, too. Because oh god, fglrx
<infinity> rbasak: So, free driver wise, nouveau and radeon are both pretty decent these days.
<rbasak> Hence AMD. But I also want my setup to drive six heads, and also want it to be quiet when it isn't doing heavy lifting.
<rbasak> And apparently multi-card on Linux is pretty poor/nonexistent with AMD
<StevenK> Six heads? So 3 SLI/whatever the heck AMD call it?
<rbasak> So I haven't done anything yet
<StevenK> Crossfire? I think?
<rbasak> Yeah that thing. Apparently it just doesn't work on Linux
<StevenK> rbasak: Given how fglrx behaves with only one card and one output, I am not at all surprised.
<rbasak> I'm thinking of getting something that drives 4 heads, with a couple of Matrox dualhead2go things
<infinity> Yeah, Crossfire and Linux will make you want to cry, I imagine.
<infinity> They're likely to implement it sanely in the free driver, but they've not done so yet.
<rbasak> Apparently I can mess with libxinerama to make X clients think I have six monitors and so everything should work properly
<rbasak> Expensive though :-/
<rbasak> And I'm still not sure about quiet operation when not doing 3D stuff
<infinity> All the high end cards do variable fan speeds and other such things, but the low-end ones (if you're not a hardcore gamer) are often last year's tech, die-shrunk, and passively cooled.
<infinity> Which is much more pleasant for a businessy system.
<rbasak> infinity: I've been struggling to find a passively cooled one that also does enough heads :-/
<mlankhorst> it's a premium
<mlankhorst> not something they would put on low end cards
<rbasak> Yeah
<rbasak> But then it gets noisy :(
<rbasak> I have a goal of having a silent office
<rbasak> (apart from the noisy keyboard)
<mlankhorst> use watercooling :p
<rbasak> I have considered that :)
<rbasak> Not sure I want the hassle though!
<rbasak> doko: are you working on the powerpc FTBFS for juju-core? We could temporarily drop block-proposed from bug 1416051 to allow 1.20 through when that's fixed.
<ubottu> bug 1416051 in juju-core (Ubuntu Trusty) "juju-core 1.21.1 is not packaged in Ubuntu" [Undecided,New] https://launchpad.net/bugs/1416051
<dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/vivid/intltool/release-0-51-0/+merge/252235 please?
<dobey> rbasak: use a white noise generate to generate a signal that's 180 degrees out of phase with the noise your PC generates :)
<rbasak> dobey: I'd prefer not to have to wear a noise cancelling headset in my office thanks :-P
<cyphermox> good morning!
<dobey> rbasak: don't wear one then. just get a wall plug thing :P
<smb> rbasak, I seem to experience bug 1429849 on my current attempts to install VMs from the current server daily. Is this something that is already known?
<ubottu> bug 1429849 in Ubuntu "server-installer: grub installed to wrong target" [Undecided,New] https://launchpad.net/bugs/1429849
<rbasak> smb: I'm not aware of it. Do you have installer logs handy, please?
<smb> rbasak, I got the VM at the point of fail, so yes... just need to send them over
<smb> rbasak, Ok a tarball of all logs attached to the bug (could not decide which one, so I went for all of /var/log and /target/var/log)
<rbasak> smb: thanks. I wonder if you can see debconf values anywhere?
<rbasak> I'm not sure how to retrieve those
<rbasak> /var/cache/debconf/config.dat maybe
<smb> rbasak, In /target/var/... shall I just attach a copy of that file?
<rbasak> smb: yes please
<smb> rbasak, its there
<rbasak> smb: thanks. Looks like d-i debconf seeds are stored somewhere else :-/
<smb> rbasak, Ok... Not sure this is relevant but at least there is some list in config.dat which has vda5 as first element and vda after that...
<smb> in grub-pc/install_devices
<flexiondotorg_> infinity, An Ubuntu MATE community member has ported Ubuntu MATE 15.04 to the Raspberry Pi 2.
<flexiondotorg_> infinity, What packages should I look at for figuring out how to enable this as an official hardware platform?
<flexiondotorg_> infinity, I'm guessing livecd-rootfs and debian-cd, but want to check this is indeed possible.
<pitti> kirkland: hey Dustin, how are you?
<kirkland> pitti: yo!
<kirkland> pitti: thanks for the pollinate systemd fixes -- I committed those upstream
<pitti> kirkland: I just investigated bug 1429354 -- TL;DR: our installer sets up a /dev/cryptswap1 in crypttab and fstab, but apparently never initializes that device
<ubottu> bug 1429354 in ubiquity (Ubuntu) "ecryptfs install does not initialize cryptswap partition" [High,Triaged] https://launchpad.net/bugs/1429354
<pitti> kirkland: cheers
<kirkland> pitti: oh, sweet
<kirkland> pitti: what did you find?
<pitti> kirkland: would you mind giving a quick overview in the bug how this is supposed to look and  behave?
 * kirkland looks
<pitti> kirkland: i. e. I take it we do want some encrypted swap partition which gets reinitialized on boot or so
<pitti> but that doesn't seem to work (under either upstart or systemd), just under systemd you actually get an error
<kirkland> pitti: right -- mainly that the key to swap should be randomly generated at each boot and never stored
<pitti> kirkland: I'm not sure how the fs structure should look like, and when the outer (luks) and inner (swap) devices are supposed to get initialized?
<kirkland> pitti: I think the core of the problem is that doing this, creates a different uuid of the partition each boot
<pitti> kirkland: right, the UUID in crypttab is certainly weird; but ther's nothing on that partition after installation at all
<pitti> not even a LUKS partition
 * pitti will be back in one hour or so, I need a break
<pitti> I didn't actually expect you to be awake yet :)
<pitti> TTYL!
<pitti> (there might be another installer bug about that already, just with upstart not telling you about it, it's not easy to discover)
<kirkland> pitti: heh, it's 10:30am :-D
<kirkland> pitti: okay, I suspect /usr/bin/ecryptfs-setup-swap might need some new logic
<pitti> kirkland: larsu did an install with utopic btw, that's not a new thing
<kirkland> pitti: right
<pitti> kirkland: so, ATM I'd like to understand how this is supposed to work, and then we can see how we fix that, and how we can fix existing installations
<kirkland> pitti: sure, you want to ping me in an hour when you're back?
<kirkland> pitti: and we can talk through it?
<directhex> hi. what's the best way to set up a gcc5 test environment right now?
<teward> infinity: around for me to bug you about something?
<pitti> kirkland: re
<roaksoax> 3/win 13
<mlankhorst> mvo: I seem to be unable to create a depends list for ubuntu-sdk that allows me to install it with lts-utopic on trusty, and without lts-utopic on trusty.
<mvo> mlankhorst: in a meeting right now, sorry
<mlankhorst> feel free to look at it later :)
<mvo> mlankhorst: more meeting and then hockey today, but can we talk tomorrow morning? I am around from 8am (european time) :)
<mlankhorst> oke
<mvo> thanks!
<bdmurray> pitti: Can you have a look at bug 1419061, particularly comment #20.
<ubottu> bug 1419061 in apport (Ubuntu) "detect all packages as not genuine" [High,Confirmed] https://launchpad.net/bugs/1419061
<flexiondotorg_> Who can I chat with about creating armv7hf images?
<rbasak> flexiondotorg_: try #ubuntu-arm maybe
<flexiondotorg_> Thanks.
<doko> infinity, could you have a look at https://launchpadlibrarian.net/199754193/buildlog_ubuntu-vivid-amd64.google-perftools_2.2.1-0.2_BUILDING.txt.gz (vivid test rebuild)
<tyhicks> pitti: re 953875> Hi - I'm going to be publishing ecryptfs-utils security updates today (if testing goes as planned)
<tyhicks> pitti: I wanted to let you know so that your work on the SRU doesn't collide
<tyhicks> pitti: the packages that I plan on pushing out can be found here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
<mdeslaur> pitti: so I just rebooted, and systemd didn't mount my nfs shares
<mdeslaur> pitti: bug 1429975
<ubottu> bug 1429975 in nfs-utils (Ubuntu) "nfs no longer mounted at boot with systemd" [Undecided,New] https://launchpad.net/bugs/1429975
<mdeslaur> seb128: please tell me how to kill all the retarded gtk deprecation warnings?
<mdeslaur> seb128: is there an environment variable I can set or something?
<doko> Riddell, ScottK: looking at https://launchpadlibrarian.net/196577810/buildlog_ubuntu-vivid-amd64.qtwebkit-source_2.3.2-0ubuntu7_FAILEDTOBUILD.txt.gz
<doko> https://bugs.webkit.org/show_bug.cgi?id=82824
<ubottu> bugs.webkit.org bug 82824 in WebKit Qt "Webkit compilation error in file UnicodeQt4.h" [Major,Resolved: invalid]
<doko> libxml2 is now built using icu, and qtwebkit already has icu enabled ...
<ScottK> Mirv: mitya57 ^^^
<sarnold> pitti: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938
<ubottu> Launchpad bug 1429938 in openssh (Ubuntu) "systemd changes behavior of apt-get remove openssh-server" [Undecided,Confirmed]
<sarnold> pitti: should those be left against their own packages or filed against systemd?
<cjwatson> It may be a bug in the openssh service file
<sarnold> I don't know for certain that systemd isn't supposed to do exactly that... but I figured pitti would be in the best position to report intentional/notintentional or suggest fixes
<cjwatson> Odd though, we're using KillMode=process
<sarnold> .. and this is probably not the last such case, I'm curious where he'd like them aimed :)
<infinity> flexiondotorg_: Well, it would be worth discussing what you mean by "ported", first.  But yes, it's mostly a livecd-rootfs thing.  Or telling users to use the d-i netboot image.
<infinity> teward: I wasn't, but I am now, ish.
<infinity> cjwatson: Isn't the systemd default MO to violently whack the cgroup it started a service in?  I don't speak it fluently enough to know how to intentionally avoid that.
<teward> infinity: i think https://bugs.launchpad.net/bugs/1214352 needs your attention - see the bottom of it, and note the OP emailed into bugcontrol asking for an SRU
<ubottu> Launchpad bug 1214352 in libreoffice (Ubuntu) "[SRU] GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses" [Undecided,New]
<teward> (you're marked as the assignee for the glib2.0 part)
<bluesabre> hey infinity, with the xfce4.12 upload, we have a few packages that will need to be rebuilt (no changes needed) that I do not have upload rights for, not sure if you'd be interested in triggering those rebuilds?
 * bluesabre needs to request a xfce packageset
<infinity> bluesabre: Toss me a list.
<infinity> bluesabre: And yes, a packageset would be helpful.  How do you not have one?
<infinity> bluesabre: Or is it that there's a "xubuntu" one, but we need a generic "xfce" one for studio/xubuntu/etc that all overlap?
<bluesabre> xfce4-eyes-plugin xfce4-hdaps xfce4-mixer
<bluesabre> we have a xubuntu one, but no xfce one
<bluesabre> I'll request its creation... as a xfce contributor I'll also request upload rights for it as a whole
<Unit193> Should be just about everything pkg-xfce has access to, minus lightdm.
<infinity> teward: Well, we're not rebuilding everything in precise that depends on glib2.0.  So, I need to assess what we can do with minimal impact there.
<bluesabre> what Unit193 indicated :)
<teward> infinity: i think it was already mentioned the regression potential is infinite and that it's a bad SRU candidate
<teward> infinity: and that was when Dave Kokandy marked it Fix Released on glibc
<infinity> teward: s/glibc/glib/ :P
<infinity> Don't worry, I can't type "glib" without a backspace either.
<teward> infinity: true
<ochosi> shouldn't that be "infinitely true"?
<cjwatson> infinity: Yeah, but I thought KillMode=process stopped it doing that.
<teward> infinity: i think it just needs someone who knows more to say "We can't, here's why: foo bar baz foo reason foo foo"
<infinity> teward: Yeah, I just haven't had the time to sit down and stare at it.  If the only thing it deeply affects (in a user-facing noticeable way) is LibreOffice, it's still possible we could do a targetted rebuild of some bits there, but I'm not sure it's worth the effort either.  I'll give it some thought.
<teward> infinity: i think that's not what the current case is
<teward> oop my bad
<teward> i have 5 bugs on screen, confusing myself
<teward> infinity: yeah it seems to be a LibreOffice issue, but if fixing it in glib to fix it in libreoffice would cause problems for everything else, you hit the infinite regression potential problem again
<teward> infinity: if I had a say in it (and I don't really) I'd say it's not SRUable because of the regression potential, but I'm not affected by the issue
<teward> (trusty is better than precise :P
<infinity> teward: Yeah, I dropped a comment on the bug to that effect, but am in no mood (took a personal day today) to actually think hard about it.
<teward> infinity: indeed.
<sarnold> honestly how many programs are goin to be doikng byteswaps? how many of those will use the macros with complex arguments?
<teward> infinity: sorry for bugging you on your 'personal day', i just wanted someone who has a familiarity with the bug/issue to take a peek
<teward> since that user is bugging bugcontrol on the SRU i thought i'd poke someone much more familiar with the bug
<infinity> teward: To be fair, I'm not sure that fixing the macro is actually much of a regression potential at all, since most callers will get exactly the same result they always did, except the ones that were already broken.
<teward> mmm
<infinity> teward: But glib's rdep list is impressively long, so some care is required.
<teward> infinity: right.
<teward> infinity: if this is fixable in just LibreOffice that reduces the potential.  But if it ends up needing SRU'd with all the packages on that bug (glib included) then it's poor candidate
<teward> infinity: given Norbert and LocutusOfBorg's comments on the bug though it looks like they were looking at glib updates, which is why i pinged you
<teward> thanks though
<infinity> teward: The correct fix is in glib, yes.  I wasn't arguing otherwise.
<infinity> teward: That said, once glib is fixed, a non-determinate number of rdeps need to be rebuilt to make libreoffice happy.
<infinity> (According to the penultimate comment, fixing glib and rebuilding LibO wasn't enough)
<infinity> Or, someone did it wrong. :P
<infinity> That said, one could fix it just in LibO, if that was all that needed the rebuild, by just redefining that macro after every inclusion of glib.h
<teward> infinity: right
<infinity> Realistically, though, if anything was relying on the broken non-bracketed behaviour, I'd be very surprised.
<infinity> Either you were calling with a single non-complex argument, and it works either way, or you're not, and it was subtly broken and you didn't notice because you don't have a testsuite or users.
<infinity> I can't think that anyone was calling it with complex arguments and thinking "boy, aren't we lucky that this macro misparses the arguments in just the way we were hoping?"
<teward> infinity: do you mind if i quote you here either in paraphrasing or direct quotes in my response to their message to the 'bugcontrol' list?
<teward> (Just so they know *someone* is watching their messages)
<infinity> teward: All the copy-and-waste you want, go for it.  This is a publically logged channel. :P
<teward> infinity: indeed.
<teward> whether the person emailing in knows how to log it, is another story.
<teward> blargh, the page hasn't updated on irclogs
<teward> i'd give a link if it were
<infinity> teward: I think that only updates hourly or something unhelpful.
<teward> mmm
<infinity> sarnold: What's your take on my regression potential analysis above?  Starting around 24m past whatever hour it is for you.
<sarnold> infinity: I suspect you're right, I especially luiked the bit about no tests or no users :)
<sarnold> chances are good very little needs to be rebuilt, but just rebuilding packages that actually used the macros should be safe and not as terrible as building everything with build-dep headers
<infinity> sarnold: Yes, we need a codesearch.ubuntu.com :P
<sarnold> infinity: yes.
<infinity> sarnold: That said, I think finding the exact package(s) that need(s) love to fix the LibreOffice sadness is probably all we really need to do here.  It's not like people are piling on this bug from 37 different "it also breaks $foo" directions.
<infinity> So, checking LibO deps for the macro being used might be less painful and greppable locally without a fully unpacked mirror and a search engine. :P
<sarnold> infinity:  it's a balance of human time to check programs vs build farm time / mirror downloads space and time...
<infinity> sarnold: I'm not actually hugely concerned about machine time, but having to download 280 packages to fix a bug is not ideal (PS: this incident is a great example for the static linking lovers) and, furthermore, impossible for us to test before we release.
<infinity> sarnold: If we just fix glib and, say, 3 LibreOffice deps, we can actually test those, and then future rebuilds of other glib things for other SRUs will get tested when they happen, and people can yell at us if the macro fix broke them (which it won't have, but at least the binaries are legitimately being tested).
<sarnold> infinity: good points
<infinity> teward: Anyhow, today was a day I set aside for not thinking, so that's enough for me.  But if I forget about this, feel free to bug me later in the week. :P
#ubuntu-devel 2015-03-10
<teward> infinity: (late response) I will do so if i see no activity, but I trust it'll be on the radar so long as that norbert guy keeps poking it
<pitti> Good morning
<pitti> tyhicks: ah, thanks; I wasn't working on an SRU yet, mostly on the vivid update; and I was waiting for kirkland to push the two script fixes upstream
<pitti> sarnold: ssh bug> most probably a too eager (default) KillMode= in openssh's .service file; I'll have a look
<pitti> sarnold: IMHO it's best to file them against the affected package with tagging "systemd-boot"
<pitti> cjwatson: ^ FYI
<pitti> tyhicks: ah thanks, so I'll upload my ecryptfs update on top of that
<pitti> tyhicks: but why does the PPA have 104-0ubuntu4 for vivid? current vivid has -0ubuntu1..
<wgrant> pitti: When you're done with, you know, switching init systems and stuff, we're ready from the LP end to switch on ddebs. Are the ddeb-retriever changes reasonably doable in the near future?
<pitti> mdeslaur: ok, that worked for me, so I need more precise information about your setup; I'll answer in the bug
<pitti> hey wgrant
<pitti> wgrant: I need to find a day to do that rewrite
<pitti> I hope I can get to it this week, as I'll be on vac for the following 1.5 weeks
<wgrant> pitti: Let us know if we can help at all.
<pitti> wgrant: if you want, the code is in https://code.launchpad.net/~pitti/%2Bjunk/ddeb-retriever/ ; it has tests and such, although they'll be a lot harder to write for LP
<pitti> wgrant: do you have a suggestion/do we have a project how to mock launchpadlib?
<pitti> i. e. the part that's going to fetch the ddebs
<pitti> although I guess with the standard python mock one should get far enough
<pitti> and just make that return a static list of ddeb URLs
<wgrant> You probably only care about one or two methods, and it's easy enough to wrap those in a function that you can mock out.
<wgrant> pitti: Oh, that code isn't nearly as terrifying as the legends foretold.
<pitti> well, I wrote most of it in 2005; I was young and ...
<pitti> ah, 2006
<wgrant> Yup
<lifeless> there is a launchpadlib mock thingy
<lifeless> several
<lifeless> none really mature IIRC
<mitya57> ScottK: can't we just sync/merge newer qtwebkit from Debian?
<mitya57> Should have been done earlier, I suppose
<pitti> jodh: thanks for looking into the upstart test regression -- tests for the win! so it indeed seems this is a kernel regression?
<dholbach> good morning
<LocutusOfBorg1> hi folks!
<LocutusOfBorg1> dholbach, do you think there's hope for my virtualbox new package here? bug 1424769
<ubottu> bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424769
<LocutusOfBorg1> I don't know how new trusty packages are handled :)
<dholbach> maybe ping one of the archive admins to find out how it's done?
<dholbach> I need to run out to the dentist now :)
<LocutusOfBorg1> oh... good luck!
<dholbach> thanks
<seb128> cjwatson, hey, do you have any opinion on http://bazaar.launchpad.net/~robert-ancell/+junk/sync-blacklist-indic/revision/557 ?
<seb128> cjwatson, to me it looks like you added a bunch of sources to that list cycles ago to get autosync going and nobody looked again at those again, is that correct?
<cjwatson> pitti: well, it's certainly not using the default KillMode= ...
<cjwatson> pitti: lp:ubuntu-cdimage has an approach to mocking launchpadlib which, well, isn't complete or anything but it's quite simple to extend, maybe that could be useful
<pitti> cjwatson: oh right, it's already "process"; anyway, this didn't yet bubble up to the top of my TODO list, but I'll get to it for sure
<pitti> cjwatson: thanks for pointing out
<cjwatson> seb128: well, that one was specifically a problem for a few cycles until Robert tackled the ttf-indic-fonts merge in trusty
<cjwatson> seb128: but I can certainly look at that, it's probably reasonable now
<seb128> cjwatson, I was going to trust robert_ancell and merge the change, it look fine and he said he would deal with issues that could result from the change, but if you want to double check that would be welcome!
<cjwatson> seb128: ok, why don't you go ahead and merge it, and we should see the result in the next auto-sync dry-run well before Robert wakes up again
<cjwatson> seb128: i.e. in a bit over an hour
<seb128> cjwatson, wfm, I just wanted to check with you before doing the change
<seb128> thanks
<cjwatson> yeah, it's provisionally fine
<cjwatson> thanks for checking
<seb128> yw!
<pitti> smoser: did you see my question in bug 450463? each and every cloud image these days boots in degraded mode because we are trying to load a nonexisting module; where is acpiphp added these days?
<ubottu> bug 450463 in vm-builder (Ubuntu) "acpiphp module needs to be loaded on boot" [Medium,Fix released] https://launchpad.net/bugs/450463
<mlankhorst> mvo: ping for apt-get?
<pitti> hallyn_, stgraber: it seems cgmanager's tests don't work under systemd (https://jenkins.qa.ubuntu.com/job/vivid-adt-cgmanager/21/ARCH=i386,label=adt/console); is that a bug? or do the tests just need some adjustments? or should we run the tests under upstart?
<mardy> pitti: hi! So, I wrote my dbusmock template, but now I don't know how to register it: ImportError: No module named 'dbusmock.templates./home/mardy/src/bzr/accounts-sso/online-accounts-api/mock-template/src/daemon/online-accounts'
<pitti> mardy: oh, it's not a template in the "dbusmock.templates.*" sense, Python doesn't allow this kind of namespace mangling (or at least makes it really hard)
<mardy> pitti: any hints on how to have my template loaded?
<pitti> mardy: your online-accounts isn't a  Python module?
<pitti> they need to end in .py
<pitti> and have no dashes in it eitehr
<pitti> mardy: so spawn_server_template('/full/path/to/mocks/online_accounts.py', params) ought to work?
<pitti> mardy: (relative path ought to work, too)
<mardy> pitti: OK, I'll try; I'm using libqtdbusmock, I guess it will have something equivalent
<ScottK> mitya57: I didn't have time to check.
<xnox> pitti: did you switch to systemd by default?
<xnox> pitti: and do i need to do the crazy upstart split we agreed to do on here in a sensible way?
<pitti> xnox: yes, it got switched yesterday
<flexiondotorg_> There are some new MATE packages in Debian unstable that just fix bugs. Do I need to file a FFE to sync these?
<pitti> flexiondotorg_: no, bug fixes only -> no new features -> nothing to except :)
<flexiondotorg_> pitti So, what is the process to request the sync?
<cjwatson> requestsync(1)
<flexiondotorg_> cjwatson, Thanks.
<pitti> xnox: split? would be nice to move the conffiles to upstart-bin indeed
<pitti> but I don't think we need to further split the package; they aren't that big to warrant that IMHO
<xnox> pitti: well, i believe the decission was slightly different. Keep conffiles in upstart, but move all other things that conflic with systemd-sysv from upstart -> upstart-sysv
<pitti> my /etc/init is 452 K, and that includes jobs from a lot of other packages
<pitti> xnox: ah! and adjusting systemd's conflicts accordingly, and init's dependencies? a lot more intrusive, but certainly doable
<pitti> xnox: but then we don't need upstart-bin either any more?
<xnox> pitti: make upstart-sysv depend on upstart. and yeah.
<xnox> pitti: well upstart-bin is kind of the minimal thing one needs to run /user session/ only.
<xnox> pitti: but certantly would be possible to merge that back into upstart.
<xnox> pitti: i still don't know what the upgrade path will look like.
<pitti> I didn't really follow why it's impossible to move a conffile between packages
<xnox> pitti: e.g. should I make this new split with "upstart depends: systemd-sysv" ?
<pitti> xnox: well, I'm not yet convinced that this is the best way; this sounds like crying for more upgrade troubles TBH
<pitti> xnox: err, upstart depends: systemd-sysv? that looks wrong :)
<xnox> pitti: so we obviously do not want upstart to depend on upstart-sysv, and apt can decide to purge old one before unpacking the new one, wiping modified conffiles away
<xnox> pitti: or generating a conffile prompt.
<xnox> pitti: do we have any dist-upgrader hook to install systemd-sysv?
<pitti> this stuff should work with apt-get too
<xnox> pitti: or people who don't have ubuntu-minimal are screwed?
<pitti> xnox: right, people without ubuntu-standard won't get upgraded to systemd (for now, anyway)
<xnox> pitti: having upstart split the same way as systemd is split would be nice.
<pitti> xnox: I agree, splitting it that way makes more sense; I just can't tell you that it will work on upgrades
<pitti> (it should, but needs testing)
<pitti> well, actually it shouldn't be that bad
<pitti> we just split out a new upstart-sysv with /sbin/init, telinit, shutdown, etc.
<xnox> pitti: upstart depends: upstart-sysv | systemd-sysv -> such that people end up with an init?
<pitti> which we wouldn't even install on upgrades
<xnox> or whatever that metapackage thing is to provide init.
<pitti> xnox: no need
<pitti> xnox: init is required now (and in ubuntu-minimal)
<pitti> xnox: well, it could depends: init, to make sure
<xnox> pitti: i don't want to upgrade upstart to a package without /sbin/init and break everyone who doesn't have ubuntu-minimal installed, you see.
<xnox> and without any dependency that provides /sbin/init
<pitti> xnox: yup, understood; so depend: init?
<xnox> yeah.
<xnox> maybe i should introduce "Depends: init" and see how badly this breaks.
<pitti> xnox: ok, that sounds good to me
<xnox> (without any splits)
<xnox> .. changes, that is)
<mdeslaur> pitti: thanks for looking at my nfs issue. I assume you are going to enable NetworkManager-wait-online.service? I have a few other things that also fail to wait for networking, like ntp, etc.
<seb128> mdeslaur, hey, sorry my IRC timeouted yesterday and I think you didn't get my reply, feel free to open a bug about those gtk deprecation warnings, we might try to turn some off for release or something
<mdeslaur> seb128: what whould I file it under, gtk+3.0?
<pitti> mdeslaur: ah, are you *only* using NM, not ifupdown?
<mdeslaur> pitti: only NM
<xnox> mdeslaur: you get to keep both pieces =)
<mdeslaur> xnox: wth are you talking about, this has worked for the past 6 years
<xnox> mdeslaur: or enable network-manager wait online target yourself =)))))
<pitti> nah, I think we should enable it by default
<xnox> mdeslaur: systemd-networkd is the future man! =)
<mdeslaur> xnox: well, I live in the present :)
<pitti> I just wasn't aware that our ntp, nfs etc. jobs waited for NM
<xnox> mdeslaur: NM is so two thousand and late </finished trolling>
<mdeslaur> xnox: who needs ipv6 anyway, right? :)
<mlankhorst> can't we move the networking to the cloud?
<seb128> mdeslaur, yes, describe the warnings and where you see them, Laney&co and probably going to push to fix the apps to not use deprecated apis or properties rather than turning off the deprecations warnings, so we need to see what is impacted and be pragmatic about it
<xnox> mdeslaur: http://dilbert.com/strip/2014-12-04 and ipv4 address
 * xnox <3 BOB
<mdeslaur> xnox: oh, actually looks like systemd-network gained ipv6 support since the last time I asked :P
<mdeslaur> s/asked/looked/
<mdeslaur> seb128: ok, cool thanks.
<xnox> mdeslaur: have you looked at libnss_resolve module in systemd source tree? If you guess that it uses system dbus to call to org.freedesktop.resolve1 service to query dns - you are obsolutely correct!
 * mdeslaur spits coffee at screen
<mdeslaur> xnox: no wonder the push for kdbus :)
<xnox> mdeslaur: also you cannot login without system dbus - as nologin isn't lifted until system login acquires name on the system dbus. And well pam_systemd will also fail as required.
<mdeslaur> hrm
<mdeslaur> seb128: bug 1430307, thanks
<ubottu> bug 1430307 in gtk+3.0 (Ubuntu) "Deprecation warning should be turned off for release" [Undecided,New] https://launchpad.net/bugs/1430307
<flexiondotorg_> I've been reuest some sync from Debian with requestsync. No problem.
<flexiondotorg_> However, one package reports the same version exists in Debian and Ubuntu,
<flexiondotorg_> E: The versions in Debian and Ubuntu are the same already (1.8.1+dfsg1-4). Aborting.
<didrocks> slangasek: hey, mind giving your opinion when you have some time on bug #1428486?
<ubottu> bug 1428486 in nfs-utils (Ubuntu) "Only start rpc.statd if $NEED_STATD" [Low,Triaged] https://launchpad.net/bugs/1428486
<flexiondotorg_> But, as far as I can see Ubuntu has 1.8.1+dfsg1-3
<flexiondotorg_> Ummm. Confused.
<didrocks> flexiondotorg_: would be easier with the package name :)
<flexiondotorg_> didrocks, mate-power-manager
<didrocks> flexiondotorg_: $ rmadison mate-power-manager
<didrocks>  mate-power-manager | 1.8.1+dfsg1-4 | vivid/universe  | source, amd64, arm64, armhf, i386, powerpc, ppc64el
<didrocks> so vivid has 1.8.1+dfsg1-4
<didrocks> requestsync isn't lying :)
<didrocks> you could as well check this one launchpad: https://launchpad.net/ubuntu/+source/mate-power-manager
<flexiondotorg_> http://packages.ubuntu.com/vivid/mate-power-manager
<didrocks> (note that there is a slight publishing cycle difference between launchpad and rmadison)
<didrocks> flexiondotorg_: packages.ubuntu.com mirrors data from launchpad/the archives
<didrocks> use rmadison as the source of trust
<seb128> mdeslaur, thanks
<flexiondotorg_> didrocks, OK. It is great that this newer package has landed. But I am confused.
<didrocks> (or launchpad)
<flexiondotorg_> didrocks, What caused that sync to happen? I thought Debian sync was disabled now?
<flexiondotorg_> That package was only uploaded to Debian unstable 4 days ago.
<seb128> flexiondotorg_, cjwatson did it today apparently
<seb128> not sure why
<flexiondotorg_> cjwatson, Thanks :)
<didrocks> yeah, it's the auto-sync archive being run, not sure why as well
<seb128> it might have been a sponsoring request in the queue
<didrocks> flexiondotorg_: https://launchpad.net/ubuntu/+source/mate-power-manager/+publishinghistory for the publishing infos
<flexiondotorg_> didrocks, Thanks.
<didrocks> https://bugs.launchpad.net/ubuntu/+source/mate-power-manager/+bug/1428131
<ubottu> Launchpad bug 1428131 in ubuntu-mate "mate-power-manager does not handle UP_DEVICE_STATE_UNKNOWN device state" [Undecided,Triaged]
<didrocks> flexiondotorg_: that's why it was synced ^
<flexiondotorg_> didrocks, OK. So linking to an upstream bug will trigger a sync?
<mvo> mlankhorst: hey, sorry for the delay. what commands do I need to run to reproduce the issue you ran into?
<didrocks> flexiondotorg_: surely not, this has been a sponsoring thing I think
<flexiondotorg_> didrocks, OK, thanks for the explanation. All understood.
<flexiondotorg_> cjwatson, Thanks for your sponsoring.
<mlankhorst> mvo: I have a workaround now, but on a 14.02 image try installing ubuntu-sdk
<mlankhorst> workaround is allowing the -dev packages for the unrenamed stack to be installed with the renamed stack
<smoser> pitti, "degrated" ?
<smoser> oh. i see.
<mvo> mlankhorst: aha, let me try that
<mlankhorst> but when I add depends: renamed | unrenamed for all dev packages to ubuntu-sdk-libs-dev to nudge the depends a bit it will work on renamed, but not on unrenamed..
<mlankhorst> so I'm tempted to just sru the fixed mesa package every time I upload a new lts stack
<smoser> pitti, http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/vmbuilder-cloudimg-fixes
<mvo> mlankhorst: thanks, let me check that once my image is downloaded
<mlankhorst> oke
<mlankhorst> apt-get install ubuntu-sdk should be uninstallable
<cjwatson> flexiondotorg_,seb128,didrocks: yeah, I occasionally go through the auto-sync output looking for obvious syncs
<flexiondotorg_> cjwatson, Thanks.
<cjwatson> it wasn't a sponsoring thing
<mardy> pitti: if you have a minute, can you have a look at this? I get an error saying that the request_access method is not part of DBusMockObject
<mardy> pitti: http://bazaar.launchpad.net/~mardy/online-accounts-api/mock-template/view/head:/src/daemon/online_accounts.py#L50
<mardy> pitti: I guess I'm doing something very stupid :-)
<smoser> utlemming, Odd_Bloke : https://bugs.launchpad.net/ubuntu/+bug/1430323
<ubottu> Launchpad bug 1430323 in Ubuntu "cloud-images attempt load of acpiphp, causes failure of systemd-modules-load.service" [Medium,Confirmed]
<Odd_Bloke> smoser: utlemming: I've pushed up a fix to livecd-rootfs, so it should be fixed in the next vivid build (or perhaps the one after that).
<smoser> Odd_Bloke, i would apply the change to trusty and utopic also.
<smoser> its clearly just noise on those systems even if upstarts module-loading job is less complainy
<Odd_Bloke> smoser: Ack, will do.
<pitti> smoser: ah, thanks for the bug; I suppose this can just be dropped, as we don't have the module any more
<pitti> mardy: right, it isn't
<pitti> mardy: it's a toplevel function, not a method of your "self"
<mardy> pitti: I'm calling setattr() on mock, to add these methods, and now it works. Is it OK?
<pitti> mardy: it's a bit of a hack, but sure :)
<Odd_Bloke> smoser: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/revision/655
<pitti> mdeslaur: would you mind trying something?
<mdeslaur> pitti: sure
<pitti> mdeslaur: do you have /var on NFS, or something similar?
<pitti> (/home is fine)
<mdeslaur> I have /mnt/server on NFS, nothing else
<mdeslaur> it's not an important mount
<pitti> mdeslaur: I just updated the bug(s)
<pitti> mdeslaur: so, could you replace $remote_fs with $local_fs in /etc/init.d/console-setup
<pitti> mdeslaur: (that will break with /var on NFS)
<pitti> mdeslaur: and then sudo systemctl enable NetworkManager-wait-online.service
<pitti> mdeslaur: AFAICS console-setup should be the only remaining problem in a default install
<pitti> mdeslaur: this ought to fix NFS for you
<doko> jamespage, rbasak: I was looking at the GCC 5 ftbfs in open-vm-tools. any reason that the package is not merged since trusty?
<mdeslaur> pitti: I do have other $remote_fs in /etc/rcS.d
<mdeslaur> pitti: or do they not matter because they have systemd jobs also?
<pitti> mdeslaur: right
<mdeslaur> pitti: ok, give me a few minutes and I'll try it
<rbasak> utlemming: ^^ can you speak for open-vm-tools, please?
<pitti> mdeslaur: grep -l DefaultDependencies /run/systemd/generator.late/*.service | xargs egrep 'remote-fs|network-online'
<pitti> mdeslaur: for me that only yields console-setup.service
<mdeslaur> pitti: me too
<Odd_Bloke> rcj may also be able to speak on open-vm-tools.
<pitti> mdeslaur: hm, hang on
<pitti> mdeslaur: before you reboot, let me test something
<mdeslaur> ok
<pitti> mdeslaur: OK, it actually works here in my VM
<mdeslaur> pitti: I'll test it in about 30 min
<pitti> mdeslaur: there is a really fishy/broken thing in NM-wait-online.service, so I wanted to check first
<ogra_> pitti, hmmm ... so the touch change seems to kill the i386 buildd
<ogra_> https://pastebin.canonical.com/127272/
<pitti> oh, that seems related to what xnox and I discussed this morning
<pitti> e. g. we need to keep the /etc/init/ scripts in upstart, and split out upstart-sysv instead
<xnox> pitti: i can't see that paste....
<xnox> pitti: don't the i386 touch build wants upstart as init?
<ogra_> pitti, cjwatson suggested that init/conf.c is missing a nih_free
<xnox> pitti: ditto desktop-next
 * xnox can't see that paste
<xnox> (un authenticated)
<ogra_>  in the case where nih_file_read fails
<cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.621603] init: /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild/build/chroot/etc/init/tty1.conf: Unable to reload configuration after override deletion
<cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.642455] init: file.c:110: Unhandled error from nih_file_read: No such file or directory
<cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.754281] init: Caught abort, core dumped
<cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.754375] init: file.c:110: Unhandled error from nih_file_read: No such file or directory
<cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.757830] init: Caught abort, core dumped
<cjwatson> and then the buildd dies
<cjwatson> so regardless of the structure of the packages, this is a bug in the version of upstart running in the host system
<cjwatson> and I'm not sure it's one that's been fixed even upstream; if nih_file_read returns NULL then AFAICS it leaves an outstanding nih_error lying around which must be freed
<pitti> xnox: I sent a summary to bug 1422681, I think that's what we resolved to?
<ubottu> bug 1422681 in upstart (Ubuntu) "split out upstart-sysv" [Undecided,New] https://launchpad.net/bugs/1422681
<cjwatson> (i.e. regardless of the structure of the packages, it should never be possible to crash the host init like this)
<rcj> doko, I'm looking at syncing open-vm-tools with the release in debian.
<cjwatson> anyway, will leave it to you lot, just try to stop taking out my buildds ;-)
<doko> rcj, cool, please can you address https://launchpadlibrarian.net/196777507/buildlog_ubuntu-vivid-amd64.open-vm-tools_2%3A9.4.0-1280544-5ubuntu6_FAILEDTOBUILD.txt.gz as well? GCC 5 ftbfs
<rcj> doko, will do. Thank
<xnox> cjwatson: thanks. That doesn't look good indeed.
<xnox> ogra_: cjwatson: is there a launchpad bug with the full log somewhere against upstart about that?
<xnox> doko: started packaging boost1.57. It's building fine, just -doc package generation fails, this is where i've stopped at yesterday.
<ogra_> xnox, i only noticed it minutes ago ... cjwatson is looking at it a few mins more i think
<cjwatson> xnox: not afaik
<cjwatson> and that's all the log I have
<xnox> ah, ok.
<ogra_> so no, unless Spads filed one
<cjwatson> (well, until the builder was manually rebooted 12 minutes later)
<Spads> I can provide more log, but there's not much more that's interesting there
<Spads> those reboots you see are me manually hitting power
<cjwatson> s/12/22/
<Spads> (well, virtually)
<cjwatson> indeed
<cjwatson> Launchpad doesn't extract the full build log until the end, so I don't have that side of things, although it *might* be lying around in /var/log/launchpad-buildd/
 * Spads checks which default.log might fit
<xnox> cjwatson: it killed the _host_ init?! /o\
<cjwatson> Spads: everything since 13:32:42 on allspice, I guess
<ogra_> xnox, yeah, shiny, aint it ?
<Spads> xnox: charming, innit?
<cjwatson> xnox: right, hi chroot sessions
<xnox> cjwatson: ogra_: infinity disabled usptart chroot sessions on _all_ buildds
<cjwatson> maybe not hard enough?
<xnox> cjwatson: Spads: and that's the default now. Is that not enabled on these buildds?
<cjwatson> how did he do that?
<cjwatson> given that he doesn't have admin access to these buildds afaik
<xnox> cjwatson: so in later upstarts we have them disabled chroot sessions by default.
<ogra_> well, interestingly the armhf build of the same image still runs fine https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch
<xnox> cjwatson: which upstart is running there?
<cjwatson> xnox: allspice/toyol are iirc precise
<ogra_> so it might indeed be machine specific
<cjwatson> armhf will be a later base system, probably
 * cjwatson checks landscape
<xnox> cjwatson: there is no correct cleanup / garbage collections of chroot sessions. They pile up eventually. I had a hairy reorg to monitor and free chroot sessions properly, but instead we decided that nobody uses them, it was a bad idea, and we are moving on to systemd.
<cjwatson> yeah but this is not a GC issue
<cjwatson> it's pretty clear that it's an uncleared error state
<cjwatson> allspice is precise, upstart 1.5-0ubuntu7.2
 * xnox 's mk-sbuild is still running
<cjwatson> toyol likewise
<cjwatson> the armhf build is on kishi02
<cjwatson> which is also precise, upstart 1.5-0ubuntu7.2
<xnox> Spads: cjwatson: you want "--no-sessions" in the kernel cmdline, in trusty and up chroot sessions are disabled by default as we have gained "proper" upstart in the user session.
<xnox> which is much better than the old user/chroot sessions.
<cjwatson> I'm wary of doing significant maintenance on how the devirt buildds boot
<tyhicks> pitti: re the security-proposed ppa having version 104-0ubuntu4> I've iterated on the packages in the PPA a few times while the upstream changes were being reviewed/tested
<cjwatson> given that this year we plan to migrate everything into the virt farm
<cjwatson> this bug looks like it ought to be a one-liner plus tests to fix
<xnox> cjwatson: I'm wary of 3 year old usptart SRU =)
<xnox> true.
<xnox> cjwatson: well migration to virt farm -> is migration to trusty right?
<pitti> tyhicks: ah, ok; so that'll presumably land as ubuntu2? when do you plan on doing that? (I don't want to wait too long with the fix as it causes nasty boot delays, but also don't want to step on your feet)
<xnox> cjwatson: incidentally?
<cjwatson> right
<cjwatson> ok, the armhf build is killing builders now too
<rbasak> alexbligh1: apache2 2.4.7-1ubuntu4.4 is a security update that includes your fix.
<xnox> lovelly.
<cjwatson> it was probably just slower to die
 * xnox =(
<rbasak> alexbligh1: thank you!
<tyhicks> pitti: today (within a few hours, I think)
<pitti> tyhicks: ah, sounds good, thanks; I'll upload mine after that then
<tyhicks> thanks!
<cjwatson> ok, let me try to extract a sanitised combined log from Spads' dump
<xnox> cjwatson: ah, it's a libnih assert
<cjwatson> right, which is because nih is returning an error which upstart is failing to clear
<xnox> because inotify reloads inside session, which is in progress being purged =(
 * xnox pokes it more to have a simple patch for this.
<cjwatson> Hah, it's literally when removing the build tree at the end
<cjwatson> http://paste.ubuntu.com/10574985/
<xnox> cjwatson: can you remove things in order? =) like rm the .overrides first =)
<cjwatson> no, this is not in build-specific code :P
<xnox> cjwatson: i know i know, i'm joking.
<cjwatson> anyway, yeah, finishes the whole build, starts rm -rf, then 11 seconds later the buildd dies
<cjwatson> ogra_,pitti: ^-
<cjwatson> enjoy it while it lasts, we won't be able to extract build logs like this with virtualised builders :P
<pitti> hm, so the host's upstart inotifies the job files in the chroot?
<xnox> cjwatson: but that's what i wanted to do -> when chroot root dir starts disappearing start ignoring config changes and free the conf structures et.al.
<cjwatson> maybe we should sort out a jenkins-like continuous-fetch thing
<cjwatson> pitti: precise's upstart treated the chroot as a session, yeah
<xnox> pitti: yeah, and upstart expected for foo.conf to still exist when inotify handler fires for removal of foo.override.
<cjwatson> so does this actually have anything to do with the migration to systemd-sysv?
<pitti> so how come that this didn't happen before..
<cjwatson> is it perhaps that the directory entries are in a different order?
<pitti> just because that slightly changed the unpack order etc?
<cjwatson> because maybe now upstart is installed after the overrides are
<xnox> cjwatson: no. however init is growing memory with each chroot.
<xnox> cjwatson: and eventually runs out of inotify watches as well.
<cjwatson> this has killed at least three buildds in succession
<cjwatson> it doesn't make sense for it to be just a memory pressure issue like that
<cjwatson> and, as I say, there is a pretty obvious bug in init/conf.c
<xnox> cjwatson: well these builds you are doing have a lot of .override files. touch is the only one that _ships_ /etc/init/*.override files.
<xnox> previously packages never shipped them.
<cjwatson> touch builds weren't failing before today
<xnox> cjwatson: that's the only place where error is not freeed after unsuccesful call to conf_reload_path. lovely.
<cjwatson> so, if removing the .override files first is a workaround, livecd-rootfs could remove those from the chroot after building the image
<cjwatson> but this is still not good because any build cancellation will run into the same thing
<pitti> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1430280/comments/6 has the steps you can try; works here in VM
<ubottu> Launchpad bug 1430280 in network-manager (Ubuntu) "NetworkManager-wait-online.service not enabled after package installation" [Medium,Confirmed]
<cjwatson> (or potentially also build failures, although livecd-rootfs could handle those if it tried hard)
<mdeslaur> pitti: thanks, I'll let you know
<bdmurray> pitti: can you have a look at bug 1419061?
<ubottu> bug 1419061 in apport (Ubuntu) "On Ubuntu Kylin detect all packages as not genuine" [High,Triaged] https://launchpad.net/bugs/1419061
<cjwatson> xnox: Not the only one
<cjwatson> xnox: For instance conf_source_reload_file frees an unrelated error, but not the one from nih_file_read
<cjwatson> (called by conf_reload_path)
<cjwatson> But yeah, I think those are the only two
<pitti> bdmurray: replied to teh bug
<xnox> cjwatson: sure. So i believe i hit this race when adding support for multiple configuration directories. Thus the whole iteration is done consistently now - that is any .override removal triggers full rescan of sources from all dirs, rather then straight to load .conf next to it.
<xnox> cjwatson: since with multiple dirs we don't know exactly where it is.
<xnox> cjwatson: so the place where precise asserts was gone in https://code.launchpad.net/~xnox/upstart/overrides/+merge/141914
<cjwatson> Right
<xnox> cjwatson: but that merge is not suitable for SRU
<cjwatson> Certainly not
<xnox> cjwatson: i think "if (error) nih_free(error);" is a good one-liner for precise SRU though. With a test simulating this behaviour.
<xnox> jodh: are you busy? ^
<xnox> cjwatson: removing .overrides first should also work as a plug....
<cjwatson> I don't think it's if(error)
<xnox> or boot with --no-session
<cjwatson> nih_error_get maybe
 * xnox needs to check if it's system or niherror.
<xnox> plus not sure about that codebase from precise.
<cjwatson> xnox: The pattern near the end of conf_file_visitor would be appropriate, I think
<cjwatson> I don't even know where to start with trying to add a kernel parameter to every devirt buildd, or even every x86 and armhf devirt buildd
<xnox> cjwatson: yes. and we know that one works =)
<cjwatson> most of them aren't in puppet afaics
<bdmurray> pitti: thanks!
<xnox> (pattern that is)
<cjwatson> they get autoinstalled and I've no idea where the code for that is
<xnox> cjwatson: anyway, my jenkins is ready, got to go. I can prepare SRU tonight for this. Unless someone beats me to it.
<cjwatson> and I don't really want to have to get GSA to re-autoinstall several dozen buildds, either
<cjwatson> xnox: appreciated, thanks
<xnox> re-autoinstalltion - will certantly can grave some of them =)
<cjwatson> ogra_,pitti: do you think one of you could work on changing livecd-rootfs to remove .override files from the chroot tree after building the image, as a temporary workaround for this?
<pitti> cjwatson: yes, can do
<cjwatson> thanks!  what a horrible bug
<doko> xnox, any reason that boost1.54 is still in the archive?
<xnox> doko: http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.55.html dc-qt dynare?
<ogra_> cjwatson, hmm, thats tricky, it that the outer chroot or the actual rootfs chroot you refer to ?
<xnox> doko: is it in release or in proposed?
<ogra_> the rootfs ships a ton og override files ... they would need to be backed up and put in place again
<ogra_> s/og/of/
<cjwatson> no you misunderstand
<cjwatson> *after* building the image
<ogra_> oh
<cjwatson> immediately before exiting
<cjwatson> and it's in the actual rootfs chroot
<cjwatson> you can see it in the log, the full path from the host system is /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild/build/chroot/etc/init/tty1.conf
<ogra_> right, that shouldnt be any prob if we can do it after tarball creation
<pitti> ogra_: are you familiar with this? I'm a bit overloaded, can we look at this together?
<cjwatson> livecd-rootfs will be running chrooted into /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild
<xnox> cjwatson: another thing we can do, is stop making chroots trying to talk to host pid 1 - which triggers the chroot session creation in the first place.
<xnox> that would be a change in e.g. vivid.
<cjwatson> I didn't know they got the option to avoid that
<cjwatson> ogra_: doing it right at the end of livecd-rootfs/live-build/auto/build would be a vaguely decent stopgap
<xnox> cjwatson: so something connects to usptart socket, and dbus_connection_get_unix_process_id is fetched and then we do readlink on /proc/%lu/root and then we create chroot session.
<cjwatson> the current working directory will be /build within the chroot, so should be just something like "rm -f chroot/etc/init/*.override"
<xnox> one can mediate upstart's private socket, or e.g. mount proc with hidepid=2
<ogra_> cjwatson, pitti http://paste.ubuntu.com/10575139/
<ogra_> cjwatson, right, thats what i just committed :)
<cjwatson> ogra_: yep, but I'd do it even after those lb calls
<ogra_> oh, ok
<jodh> xnox: cjwatson: looks like the problem of not clearing the error stems from the function doc for nih_file_read() claiming it only returns NULL on insufficient memory :(. So, we need a "if (! buf) { err = nih_error_get(); nih_free(err); .. }" by the looks of it.
<cjwatson> shouldn't matter, but
<cjwatson> jodh: right
<pitti> ogra_: ah, thanks! I was still reading the files to see what they do in teh first place
<xnox> cjwatson: oh, but on precise one cannot reliably remount proc with hidepid option, proc fstab entry is ignored by mountall...
<jodh> xnox: cjwatson: since this still affects the latest version of upstart, should we consider a 1.13.3 release and then cherry pick in the minimal fix as a precise SRU?
 * xnox ponders if initctl in the chroot can be direvert, or all calls to upstart be avoiding.
 * xnox ponders if initctl in the chroot can be direvert, or all calls to upstart be avoided
<ogra_> pitti, cjwatson, uploaded
<cjwatson> I don't object, although it'll basically be an independent fix rather than a cherry-pick
<cjwatson> given that the baseline code in question has gone away
<pitti> ogra_: danke!
<ogra_> i'll trigger a new build once rmadison tells me i can
<stgraber> pitti: not sure if hallyn responded. But my guess is that remove-on-empty doesn't work in that case because systemd is the release_agent, so probably something to fix in the test but I'll let hallyn look at it
<jodh> Spads: please could you raise an upstart bug for this issue?
<pitti> stgraber: ah, that makes sense
<ogra_> oh, FWIW the armhf build also failed in the end
<ogra_> (without producing a lo)
<ogra_> *log
<Spads> jodh: me?
<Spads> jodh: I just schlepped logs from buildds :)
<Spads> I'm not entirely sure what the diagnosis turned out to be
<cjwatson> I'll file one
<alexbligh1> If I do (e.g.) apt-get download libapache2-mod-proxy-html for version 1:2.4.7-1ubuntu4.4, the resultant filename is libapache2-mod-proxy-html_1%3a2.4.7-1ubuntu4.4_amd64.deb - if I'm putting files into a repo, should I really % encode a colon character, or is that apt-get download being funny?
<cjwatson> the epoch is conventionally stripped entirely in a repo
<cjwatson> so it would be libapache2-mod-proxy-html_2.4.7-1ubuntu4.4_amd64.deb
<alexbligh1> cjwatson, thanks
<cjwatson> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1430403
<ubottu> Launchpad bug 1430403 in upstart (Ubuntu) "ubuntu-touch livefs builds kill upstart in host" [Undecided,New]
<jodh> cjwatson: thanks.
<hallyn_> stgraber: pitti: hm.  i wonder whether cgmanager, in the case where a controller was premounted and prune() is called, should fork a thread to manually do the prune
<hallyn_> :(
<hallyn_> i mean yes i just not do that test in the systemd case :)
<tjaalton> huh, upgrade killed my session
<tjaalton> dpkg got stuck at libc postinst
<hallyn_> pitti: well i'll fix it in a vivid-specific update for now
<hallyn_> what's the best way to detect systemd?
<pitti> hallyn_: cheers!
<pitti> hallyn_: the canonical way is [ -d /run/systemd/system ]
<pitti> hallyn_: i. e. if that directory exists, systemd is running
<hallyn_> pitti: and to be sure, the tests will never be run inside an upstart container on a systemd host (in our buildfarm) right?
<hallyn_> (bc otherwise testing for upstart would not suffice)
<xnox> hallyn_: well, if container has it's own /run you are out of luck testing for host's pid 1.
<hallyn_> xnox: of course
<stgraber> hallyn_: grep -q cgm-release-agent /proc/$(pidof cgmanager)/root/run/cgmanager/fs/<controler>/release_agent
<hallyn_> but right now i'm only wanting to avoid the testcase during pkg build, bc we know what's going on.
<hallyn_> stgraber: would you agree that long-term cgmanager should fork a thread and just stick around and wait to remove the directories?
<stgraber> hallyn_: yeah, I'd be fine with that. I don't like us turning useful features off when running on systemd
<hallyn_> i should see how much functionality i can move into systemd during 15.10
<hallyn_> (while adding features to cgmanager as contingency)
<pitti> hallyn_: that could happen, if we run a test for an older release
<tjaalton> hm, systemd/n-m failed to start br0 bridge
<Riddell> pitti: any thoughts on bug 1430428? live cd booting into ubiquity dm now which doesn't transition into live desktop
<ubottu> bug 1430428 in kubuntu-meta (Ubuntu) "kubuntu: fix live cd boot sequence" [Critical,New] https://launchpad.net/bugs/1430428
<hallyn_> pitti: i made the mistake of upgrading my laptop to vivid.  how do i (1) do the equivalient of running upstart user session, and (2) configuring my (*$&%$ network?  (or just disable the network stuff so i can run wpa_suplicant by hand)
<hallyn_> btw, now that i'm temporarily back on the network, pushed the cgmanager with workaround
 * hallyn_ is livid
<hallyn_> of course the update did crash mid-way, so maybe netowrking wont' be effed after reboot after dpkg- --configure -a
<seb128> bdmurray, mvo, could you look at bug #1430436?
<ubottu> bug 1430436 in click (Ubuntu) "15.04 kit creation fails due to create os.remove("%s/sbin/initctl" % mount)" [High,Confirmed] https://launchpad.net/bugs/1430436
<seb128> bdmurray, you added the lines which create the issue so maybe you know why they are needed/if they need to be adapted for systemd?
<seb128>         os.remove("%s/sbin/initctl" % mount)
<seb128>         os.symlink("%s/bin/true" % mount, "%s/sbin/initctl" % mount)
<seb128> replacing initctl by /bin/true
<bdmurray> seb128: I'll have a look, but that was quite some time ago.
<stgraber> mterry: sorry for the very long delay in responding to bug 1413402, just remembered it now...
<ubottu> bug 1413402 in lua-filesystem (Ubuntu) "[MIR] lua-filesystem" [Undecided,New] https://launchpad.net/bugs/1413402
<seb128> bdmurray, I've proposed https://code.launchpad.net/~seb128/click/initctl-not-there/+merge/252479 which is the obvious "don't try if the fail is not there", that should makes the sdk creation not fail but that might not be right/enough (unsure if we want to do something similar with systemctl in the systemd case
<seb128> bdmurray, in fact it seems logic to do the same for systemctl, updated to do that
<mterry> stgraber, ah thanks  :)
<hallyn_> pitti: ok, nm, looks like the failed upgrade was the cause of the trouble;  upstart user jobs under systemd are running now
<mdeslaur> pitti: it worked, my nfs mount mounted at boot
<bdmurray> seb128: I really don't recall why that's there and I'm not in the click hackers group as it stands so I think mvo is a better contact.
<seb128> bdmurray, k, fair enough, mvo is not around though... but I guess the sdk can be buggy until tomorrow in vivid, not the end of the world
<cjwatson> seb128: I commented, I don't think the systemctl case is necessary, better to stay in line with the other tools
<cjwatson> bdmurray,pitti: https://bugs.launchpad.net/launchpad/+bug/1430431 - what is it that likes to dupe crashes even if the dupe target is private, anyway?
<ubottu> Launchpad bug 1430431 in Launchpad itself "automatic reporting fails - Error: Page not found" [Undecided,New]
<cjwatson> it's clearly not a Launchpad bug, we can't just show private bugs because it upsets people when we don't, but I don't know where to reassign that
<bdmurray> cjwatson: its the retracer
<cjwatson> bdmurray: is that the daisy project?
<cjwatson> or apport?
<bdmurray> cjwatson: its apport in this case
<cjwatson> thanks
<bdmurray> cjwatson: bug 675875
<ubottu> bug 675875 in apport (Ubuntu) "apport retracing service tells me to view a private bug report" [Wishlist,Triaged] https://launchpad.net/bugs/675875
<cjwatson> aha
<seb128> cjwatson, ok, thanks
<seb128> cjwatson, I changed it back to just check for initctl and do nothing if not there, if you want to approve I can put that in a silo
<sarnold> pitti: thanks for the systemd-boot hint
<seb128> tyhicks, hey, you marked https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/769595 as invalid for ecryptfs, do you think there is any chance to make home mounts work out of the box/without requiring user edition for ecryptfs users? (that currently makes the sdk fail to create schroots envs in a non obvious way)
<ubottu> Launchpad bug 769595 in schroot (Ubuntu) "Encrypted home not mountable under chroot" [High,Triaged]
<tyhicks> seb128: hey - what do you mean by "requiring user edition"?
<seb128> tyhicks, https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264
<ubottu> Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,New]
<jodh> cjwatson: slangasek: I've attached a minimal patch to bug 1430403 along with a way to recreate. I guess you may want to consider applying this before the official SRU gets out.
<ubottu> bug 1430403 in upstart (Ubuntu) "ubuntu-touch livefs builds kill upstart in host" [High,Confirmed] https://launchpad.net/bugs/1430403
<seb128> tyhicks, basically schroot seems grumpy/can't unmount userdirs it mounts with the default fstab
<seb128> tyhicks, which is what is described in that bug no?
<tyhicks> seb128: I can't see how that could be fixed with a change to eCryptfs
<tyhicks> seb128: but I'll poke at it a bit and update the bug with what I find
<seb128> tyhicks, well, I didn't say it should be fixed in ecryptfs, but you seemed to have an understanding of the problem so I wanted to know if you had any suggestion on how we could get things to work out of the box
<doko> cjwatson, infinity: https://launchpad.net/ubuntu/+source/dynare/4.4.3-1 says that dynare-matlab should be in the archive, but apt-cache show doesn't say so
<seb128> tyhicks, we just had a new designer running into the same "can't unmount" issue making the schroot creating fail for the sdk
<tyhicks> seb128: I think kirkland's suggestion is actually the better fix (if it works): https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/769595/comments/2
<ubottu> Launchpad bug 769595 in schroot (Ubuntu) "Encrypted home not mountable under chroot" [High,Triaged]
<cjwatson> doko:  dynare-matlab | 4.4.3-1        | vivid/multiverse   | all
<cjwatson> fix your sources.list
<doko> argh
<cjwatson> it's in contrib in Debian, so that matches
<doko> sorry
<tyhicks> (oh, kirk land didn't suggest that)
<seb128> tyhicks, https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/791908 suggests that rbind is disabled in our kernel because it creates issues with autofs
<ubottu> Launchpad bug 791908 in schroot (Ubuntu) "Schroot doesn't mount /home submounts in the chroot" [Medium,Confirmed]
<seb128> tyhicks, in fact the default config uses rbind in click, but that seems to not work, I guess due to ^
<tyhicks> seb128: I don't see where anyone says that we've disabled rbind in our kernel
<tyhicks> seb128: sounds like rbind interacts badly with autofs but it is still available to use at the kernel level
<seb128> tyhicks, I misread "Once the kernel is fixed to allow rbind to work safely, we can re-enable this."
<seb128> tyhicks, I don't know why the default config that uses rbind doesn't work then
<tyhicks> seb128: ok, I'll take a look at that by eod
<seb128> tyhicks, thanks a lot
<tyhicks> np!
<tjaalton> hrm, the latest libc upgrade has now killed sessions on two of my desktops while it was setting it up
<tjaalton> xserver crashes: (EE) Cannot establish any listening sockets
<sarnold> anything in dmesg?
<tjaalton> systemd started
<tjaalton> so maybe it's messing things up a bit
<cjwatson> seb128: that's fine thanks, please go ahead
<cjwatson> (click/initctl)
<seb128> cjwatson, thanks
<infinity> mlankhorst: Oh, before I forget and we have the same timing fiasco again, can we make sure the lts-vivid stack is prepped early and kept refreshed, so you can land it pretty much right after vivid's release?
<infinity> tjaalton: Was your system booted with upstart before the upgrade?
<mlankhorst> infinity: I've had utopic stack ready in the ppa before the release, just didn't apply some of the sru's..
<tjaalton> infinity: yes
<infinity> tjaalton: Given that the latest libc upgrade was before the systemd swap, I'm guessing perhaps some bad interaction between updating libc (which tries to restart init) and systemd taking over the world.
<tjaalton> yeah :/
<tjaalton> X gets seriously confused
<infinity> tjaalton: Hrm.  We'll definitely need to fix that one.  But I'm trying to think of how best to go about it.
<tjaalton> pre-depends?
<infinity> No.
<infinity> Also, ew.
<infinity> It's just that the "detect your init system and decide what to do" logic used in a few postinsts (libc isn't alone here) never accounted for the bizarre idea that you might swap the provider of /sbin/init halfway through your upgrade.
<infinity> Or, rather, the provider of telinit, but same end result.
<infinity> I would almost be inclined to suggest it's a systemd bug that "telinit u" execs systemd when the currently running PID 1 *isn't* systemd.
<infinity> pitti: ^-- Thoughts?
<infinity>        u, U
<infinity>            Serialize state, reexecute daemon and deserialize state again. This is equivalent to
<infinity>            systemctl daemon-reexec.
<smoser> barry, so lets just say that i am being a luddite. and i'd like for fh.write(some_bytes_or_string)) to behave just like it did in simpler times of python2.
<infinity> Seems unintuitive that "daemon-reexec" will also just do a frech exec if it has nothing to serialize and re-exec.
<smoser> is there a way to accomplish such a thing?
<lifeless> smoser: you can write a wrapper
<lifeless> smoser: MagicFile(somebyteorientedfile, encoding)
<smoser> right.. but more i'm asking what was the magic decoding that happened in python2.
<lifeless> smoser: and in that create two handles
<barry> smoser: well, a str in py2 is not the same thing as a str in py3, so you're really asking for fh.write(some_bytes_or_string_or_unicode)
<lifeless> smoser: the magic decoding was that any operation between str and unicode triggered a .decode('ascii') on the str side
<barry> which i think is fundamentally flawed ;)
<lifeless> smoser:which is so reidiculously fragile....
<lifeless> smoser: and that mechanism doesn't exist in 3; so you have to actually do type inspection in ones own code
<lifeless> smoser: to emulate it
<barry> smoser: what you might do is before the fh.write() call, do an isinstance test, and if the thing is not a bytes, encode it to utf-8 first.  (you could try ascii, catch the exception, and then try utf-8, and maybe you want/need other encodings too, but mostly utf-8 should do the trick in the common cases)
<lifeless> smoser: see e.g. the cpython implementation of makedirs which does an isinstance check for bytes vs string in its own innards
<smoser> but what did python2 do ?
<lifeless> smoser: whats the thing you're doing where this is attractive?
<smoser> because you never got a encoding exception if it was trying to fit into ascii what didn't fit there.
<lifeless> smoser: I answered that above - the interpreter triggered a .decode('ascii') call
<smoser> lifeless, i already admitted to being a luddite.
<barry> smoser: right, but also, the io system was completely different in py2 so py3 is more strict (properly so) about whether you're trying to e.g. write bytes to a fh open in text mode
<barry> or vice versa, season to taste
<lifeless> smoser: I'm confused
<lifeless> smoser: are you trying to understand what happened, or to reproduce it in Python 3?
<infinity> tjaalton: Can you file a bug against systemd and subscribe pitti and I, so it doesn't get lost in the noise of IRC and brain backscroll?
<lifeless> smoser: since you can't reproduce the entire thing in Python 3, I think barry and I are trying to offer enough support to let you figure out the closest approximation
<infinity> tjaalton: I *think* I want to blame systemd, but if we have to, we can alter a bunch of postinsts to work around it.
<ericsnow> pitti: ping
<smoser> lifeless, in this case i want it to behave like python2. because that worked. and i understand all the reasons that that is bad.
<lifeless> smoser: so we can do that for a single call site at a time.
<infinity> ericsnow: It's late in pitti-land, a contentless ping might not get you much.
<lifeless> smoser: we cannot do that for a whole program with all the things it might call
<ericsnow> infinity: k, thanks
<infinity> ericsnow: Adding some content might get you something useful though. :P
<barry> lifeless: without some homebrew helper he uses everywhere of course :)
<lifeless> smoser: if you have a small number of common objects that are causing you grief (e.g. you're just now porting something with confused string types)
<ericsnow> infinity: I'm just trying to verify that vivid made the systemd switch yesterday
<barry> ericsnow: it did
<lifeless> smoser: then the best thing to do is to add isinstnace code either around or inside those common things
<tjaalton> infinity: sure thing
<ericsnow> barry: that's what it smelled like :)
<barry> ericsnow: it borked one of my vms, but i had a disk snapshot which i reverted to and the second time it upgraded (almost) flawlessly
<barry> ericsnow: one possibility: are you on vivid channel or devel channel?
<barry> smoser: yep, i think `if not isinstance(obj, bytes): obj = obj.encode('utf-8')` is probably as close as you're going to get
<ericsnow> barry: neither (other than ubuntu-devel, if that's what you mean)
<barry> which isn't so much a fix as a tourniquet ;)
<smoser> barry, lifeless thanks.
<ericsnow> barry: ah, unicode porting issue :/
<barry> ericsnow: i use rolling releases and was on 'devel' channel in sources.list but that seemed to cause my problem.  when i restored the disk image and s/devel/vivid/ it seemed to be okay
<lifeless> barry: smoser: and/or .decode as appropriate
<barry> ericsnow: yep.  more fun than any developer should be allowed to have
<lifeless> smoser: what code base is it, and is our guess about porting right?
<barry> lifeless: yep
<ericsnow> barry: oh, that kind of channel (thought you meant IRC)
<barry> ericsnow: yeah :)  other possibility of course is upgrading from utopic to vivid, but i wasn't doing that
<ericsnow> smoser: if you're looking at how to decide the init system, you could check out how we're doing it in juju: https://github.com/juju/juju/blob/master/service/discovery.go
<infinity> barry: devel is literally just a symlink to vivid, I expect your science was flawed there.
<barry> infinity: or i was just unlucky in my timing
<barry> infinity: although i have seen some errors from apt-get upgrade when literally using devel that don't show up w/vivid.  i suppose i should report that somewhere
<smoser> lifeless, well, i'm looking at curtin now. i've had plenty of pain in 2to3 already.
 * barry wishes he really had guido's time machine keys and could go back and kill the automatic coercion grandpa
<infinity> ericsnow: Assuming init system based on OS version is probably not the sanest thing, FWIW.
<tjaalton> infinity: filed, pitti should get all the bugs already
<infinity> ericsnow: Ahh, nevermind, that's a last ditch fallback attempt after trying to do it sanely, I guess.
<ericsnow> infinity: right
<ericsnow> infinity: though we also key off the version in cases where we are working with a remote host (e.g. building a cloud init script)
<lifeless> smoser: personally I never use 2to3
<lifeless> smoser: six + single source is much easier to maintain IME
<smoser> i'm not using 2to3
<lifeless> smoser: oh good :) I was thrown by your comment about pain in it
<smoser> writing code for 2 different interpreters is painful
<lifeless> smoser: right - so this is what I do:
<lifeless>  - write for 2.7 only
<barry> smoser: only when the str/bytes model isn't clean (which unfortunately is the case for a lot of existing py2 code)
<lifeless>  - use the backported io subsystem (which was added in 2.6) instead of the default IO subsystem
<lifeless> this works pretty well
<lifeless> with a very small number of PY2 checks - unittest2, traceback2, linecache2, testtools etc are all like this
<lifeless> oh, and unicode string literals make a huge swath of pain go away
<lifeless> IIRC they are 2.7 only, so I can't use them yet since my projects tend to still support 2.6 and 3.2
<lifeless> so I have u("9~...") everywhere
<jtaylor> why 3.2?
<jtaylor> that should have pretty much 0 users
<barry> precise lts is my guess
<jtaylor> its in precise, but I doubt anybody actually uses it
<lifeless> precise
<jtaylor> if your stuck on precise you are more likely also still using python2
<lifeless> easier to support it than to get bug reports
<lifeless> on every release
<barry> jtaylor: the server code which generates system-image.ubuntu.com :(
<barry> (in my particular case)
<lifeless> e.g. if I broke 3.2 support in unittest2, barry might well get unhappy :)
<lifeless> (or in testtools, or ...)
<hallyn_> except... apparently my custon /etc/acpi scripts were removed
<smoser> is there a way to open sys.stdout in bytes ?
<hallyn_> bastards
<barry> :)
<lifeless> smoser: yes
<lifeless> smoser: python3 -u
<lifeless> smoser: (or reopen at runtime, just fdopen however you want it and assign to sys.stdout
<smoser> k. thanks, lifeless.
<lifeless> smoser: but - I'd worry about doing this - why do you need stdout in binary?
<smoser> because this code is just piping to 2 different places (stdout) and to a log the output of a command.
<smoser> and i'd rather not take overhead of encode() on every byte read.
<smoser> nor do i want to deal with failure to encode
<lifeless> smoser: but AFAICT curtin has one entry point
<lifeless> so you're going to force byte-internals for all of curtin if you do it this way, no ?
<lifeless> smoser: why don't you put the pip in nonblocking mode rather than reading byte at a time
<lifeless> smoser: that would be a lot faster overall - more than enough to offset the encode/decode overheads
<lifeless> smoser: also you can write to sys.stdout.buffer directly if you have bytes to write
<lifeless> smoser: assuming you're talking about http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/commands/install.py#L137
<smoser> lifeless, yes, thats the code. the write there is getting output of a command.
<smoser> ie, the subprocess.PIPE stdout.
<smoser> i'm certain that this is not the best way to do this.
<lifeless> smoser: right so the least change is to change self.write to use stdout.buffer.write rather than stdout.write
<zyga> hey, not sure who to address this to, I'm interested in seeing the Ubuntu SDK components in Debian
<zyga> I'm not sure if this includes unity
<zyga> I'm hoping for the lowest common denominator
<zyga> so that a converged mobile/desktop application which works fine in Ubuntu
<zyga> can be also available in Debian
<zyga> I need hints on who to talk to and if this has been attempted before
<lifeless> smoser: (or make a new io.BufferedWriter(sys.stdout.buffer)
<lifeless> smoser: hmm no need for that, just use sys.stdout.buffer, its a BufferedWriter already
<lifeless> smoser: and open install_log as 'wb' to get a bytes expecting log
<smoser> yeah.
<smoser> did that.
<lifeless> if you have other code thats writing string literals to install log, you could have two objects, one Text and one the BufferedWriter
<smoser> lifeless, in python2, no sys.stdout.buffer.
<lifeless> smoser: ok, so you need single source
<lifeless> smoser: let me dig up a code ref for you
<lifeless> smoser: https://github.com/testing-cabal/subunit/blob/master/python/subunit/run.py#L133
<lifeless> oh, nope thats not the code I was thinking of
<lifeless> smoser: but its generalisable
<smoser> i was just doing the hasattr check on sys.stdout
<lifeless> if you do the io.open(stdout.fileno(), 'wb', 0) thing you'll get a stdout thats in binary mode,
<lifeless> if you open it in 'wt' via io.open you'll get the three stack, IIRC.
<lifeless> in both 2.x and 3.x
<lifeless> smoser: so http://paste.openstack.org/show/191400/
<lifeless> smoser: then you just write good type aware code through the rest of curtin - stdout for text, stdout.buffer for bytes
<smoser> lifeless, but in this case i dont want it in wt
<lifeless> smoser: (that trasnscript is from 2.7)
<smoser> right ? i want it in bytes.
<lifeless> smoser: you're never going to write messages for humans?
<lifeless> smoser: anywhere in curtin ?
<lifeless> e.g. localisation
<smoser> ok. i was just confused.
<smoser> you're saying opening in wt still allows me to write bytes to .buffer
<lifeless> yes
<lifeless> it will give you the same structure as python3 has by default
<lifeless> on python3 open is io.open, on python2 open is a builtin magic thing and io.open is there if you wish to use it
<tjaalton> win 23
<Unit193> /
<tjaalton> indeed
<seb128> could some buildd admin retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-025/+build/7048336 ?
<wgrant> seb128: Done.
<seb128> wgrant, thanks
<bluesabre> Is anybody available to force a rebuild of three packages? https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887/comments/12
<ubottu> Launchpad bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<roaksoax> pitti: are we keeping service commands for systemd or should we also adapt our code to do systemctl ?
<cjwatson> bluesabre: doesn't need an archive admin, just any uploader - Ubuntu doesn't have special binNMUs like Debian, we just do new source uploads
<cjwatson> roaksoax: service still exists and works
<bluesabre> cjwatson: It's outside of the xubuntu packageset, so was hoping to grab somebody in here
<roaksoax> cjwatson: but in vivid it will start systemd units
<cjwatson> roaksoax: yes, that's worked for ages.  grep systemctl /usr/sbin/service
<cjwatson> bluesabre: sure, I'm just saying that if you're looking for core-devs rather than archive admins then that's a much wider pool of people
<roaksoax> cjwatson: cool thanks
<bluesabre> cjwatson: agreed, thanks :)
#ubuntu-devel 2015-03-11
<sarnold> xnox: is 1430569 supposed to be private security?
<tyhicks> pitti: I published the ecryptfs-utils security updates to our stable releases and kirkland is going to cut a new release and upload it to vivid
<pitti> hallyn_: user sesssion is still upstart, that didn't change; network config also didn't change, ifupdown and NM continue to work as they ever did
<pitti> hallyn_: so apparently something failed on your system, can you please file a bug with "journalctl" output and some details?
<pitti> hallyn_: note that you can also boot with upstart once or permanently, see https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems
<Unit193> pitti: Speaking of that, you tried systemd user sessions?  Going to be easier to setup for WollyWombat?
<pitti> hallyn_: bug report for the upgrade failure also highly appreciated
<pitti> hallyn_: ah ok, do you still have the logs from the failed upgrade?
<pitti> mdeslaur: cool, thanks for confirming! so it doesn't actually seem to be that hard, we mostly just need a .service for console-setup
<pitti> Riddell: there's not much information in that bug, need to look myself; I'll respond there
<pitti> Riddell: tagged for now, so that it stays on my radar
<infinity> pitti: Riddell's bug may have to do with the bug I fixed in live-build today.  Livefses were being created without /sbin/initctl
<infinity> pitti: So, it might be magically fixed in the next daily.
<infinity> Maybe.  Then again, maybe unrelated.
<hallyn_> pitti: i probably do, but i'll look for them in the morning.  screen just went blank during do-release-upgrade...
<pitti> hallyn_: ah, you should still have logs in /var/log/dist-upgrade/ then
<infinity> pitti: LP: #1430479 is disconcerting.  I haven't had a change to reproduce or debug myself, but based on Timo's statement that the libc upgrade is starting systemd (despite it being an upgrade while booted with upstart), I'm assuming "telinit u" is starting systemd, despite the manpage clearly stating it should *re*exec, not start fresh even if systemd isn't PID1.
<ubottu> Launchpad bug 1430479 in systemd (Ubuntu) "switching init systems together with a libc upgrade kills X and disrupts the upgrade" [Undecided,New] https://launchpad.net/bugs/1430479
<hallyn_> pitti: yup, i see them
<hallyn_> oh hey that sounds lik ewhat may have happened to me
<hallyn_> except ctrl-alt-fN also didn't work, so wasn't just x
<pitti> cjwatson: right, not a Launchpad bug, duped to bug 764414; it's essentially a "pick your poison" decision, we can't just make crash reports public by default
<ubottu> bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Wishlist,Triaged] https://launchpad.net/bugs/764414
<pitti> cjwatson: it's apport (as the new master bug now)
<infinity> hallyn_: Well, killing upstart would kill its children, including the gettys on tty[1-6]... It's a miracle any of the system survives when you forcefully replace pid1 at runtime.
<infinity> (Assuming that's what's happening)
<pitti> infinity: telinit u> right, I figure we need to teach it to check if upstart is currently running, and redirect the request to upstart; we already do that in "reboot" etc., so it should be relatively simple to fix
<hallyn_> infinity: guess so.  (was just looking at the 'kills X' part of bug subject)
<pitti> tjaalton, infinity: is there a bug report to track this? (sorry, I can't track IRC properly these days)
<tjaalton> #1430479
<pitti> ericsnow: pong
<infinity> pitti: Yeah, I saw the upstart_communicate patch in the systemd source, figured you'd have a good idea on how to make telinit behave too.
<pitti> tjaalton: ah, thanks
<tjaalton> pitti: you're subscribed to systemd bugs?
<infinity> pitti: Bug report was pasted 10 lines up. :P
<pitti> roaksoax: no, please use "service"; that works with any init system, we still need to support upstart too
<pitti> tyhicks: ah thanks, then I'll upload the new ecryptfs on top of it today
<pitti> Unit193: no, I didn't try user sessions at all yet; I mean, we do start systemd --user, but nothing uses that yet
<tjaalton> pitti: I have another machine in a "pre-upgrade" state so I can test a proposed fix with it
<pitti> Unit193: so in that sense that'll be an easier transition as you can have upstart and sytsemd run side by side; http://people.canonical.com/~jhunt/systemd/packages-to-convert/2015-03-11.txt is the TODO list for that
<pitti> infinity: right, that's the patch
<pitti> tjaalton: yes, I am
<pitti> *phew*, that's what I call scrollback... and that was just the first channel
<infinity> Heh.
<infinity> pitti: Welcome to doing disruptive things? :P
<pitti> infinity, tjaalton: so, obviously we can't really restart upstart
<pitti> ah well, we can; upstart-bin ought to suffice
<infinity> pitti: You could ask upstart to restart via its socket, I assume.
<pitti> anyway, this sounds reasonably easy to reproduce in a VM
<infinity> pitti: Which is all 'telinit u' does.
<pitti> right, shouldn't be fundamentaly different from reboot and such
<infinity> pitti: Not that it's my place to determine your priorities, but it would probably be good to get this nailed before it bites too many more people.
<pitti> infinity: agreed
<Unit193> pitti: Great, thanks for the link.
<infinity> Although, loving the segfaults and assertion bugs too.
<infinity> Who thinks it's sane to *ever* put an assert() in a daemon whose failure mode is a kernel panic?
<infinity> Oh, that's in systemctl, slightly less evil.
<infinity> pitti: If my hunch is correct, you shouldn't need to fabricate a particularly complex test case.  Just upgrading an upstart system to systemd and running "telinit u" should be enough.
<pitti> infinity: right, installing systemd-sysv shoudl suffice
<infinity> pitti: Probably hasn't bitten Debian people because people there have been upgrading by hand and, of course, the by-hand upgrade is "install systemd-sysv && reboot", so no chance for the complex "wait, what is something tried to reexec init?" case to happen.
<infinity> s/is/if/
<pitti> infinity: upgrades to wheezy should now also upgrade to systemd-sysv, so this probably will hit them, too; but they weren't upgrading from upstart, perhaps telinit u behaves differently under sysvinit?
<infinity> pitti: There's some fallback code in systemctl that seems like it wants to try to do the right thing, so maybe it gets "the right thing" right for sysvinit, but not upstart.  Unsure.
<infinity> pitti: Like I said, I only briefly looked at it, it was a busy day. :/
<pitti> tyhicks: hm, nothing new in https://launchpad.net/ubuntu/+source/ecryptfs-utils ?
<pitti> tyhicks: I mean for vivid
<infinity> pitti: Oh, nice, I also missed that we reached concensus on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779559 ... I'll whip up a patch for that after I get my late-to-the-party glibc upload done.
<ubottu> Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Wishlist,Open]
<pitti> infinity: yeah, I think it's looking nicely now
<pitti> hm, so telinit u under upstart with systemd-sysv installed is a no-op
<infinity> pitti: No start message in dmesg?
<infinity> pitti: Then I really wonder what caused Timo's issue...
<pitti> ah, upstart-{udev,file}-bridge restarts
<pitti> strace shows that it connects to upstart's socket
<infinity> pitti: But restaring upstart things is fine, he claims it showed systemd starting in dmesg.
 * infinity scratches his head.
<pitti> I'll set up a trusty VM and check an upgrade from there
<infinity> pitti: I'm heading to bed, please do post findings on that bug, since it technically appears to be my postinst causing the problem, and I want to get to the bottom of it.
<pitti> yes, of course
<pitti> sleep well!
<infinity> pitti: If you can't find anything weird going on, I'll test myself later and see if I can force the failure.
<pitti> infinity: do you still know what tjaalton was upgrading from?
<pitti> earlier vivid/utopic/trusty?
<infinity> pitti: vivid to vivid.  But an old enough vivid that he got a new libc6 and systemd-sysv in the same run.
<pitti> so somehow trying to connect to upstart failed
<infinity> pitti: That's possible, yes.  I'd still argue that "telinit u" (or systemctl reexec, really) should only *re*exec, and if it can't determine that systemd is PID1, it should not try starting a fresh one.
<infinity> pitti: After it attempts fallbacks to sysvinit and upstart, etc.
<pitti> agreed; we might need an additional check for "is systemd running" there
<pitti> although daemon-reexec just immediately fails too
<pitti> infinity: hm, when does the postinst actually run telinit? "sudo sh -ex /var/lib/dpkg/info/libc6:amd64.postinst configure 2.19-15ubuntu1" doesn't
<pitti> oh, on pre-2.19?
<infinity> pitti: On every upgrade.  Unless you're running systemd, because the systemd maintainers claimed it's not needed (which I think is BS, but whatever).
<pitti> with "2.18-1" it reconfigures locales and checks for things to restart, but doesn't do anything
<infinity> pitti: Oh, also not in chroots.
<pitti> hm, it doesn't even get near that code
<pitti> http://paste.ubuntu.com/10578634/
<pitti> stops at debconf
<pitti> oh, wait
 * pitti adds a set -x, it reexecs itself
<pitti> right, I see it now
<pitti> ok, off to utopic
<pitti> hah!
<pitti> infinity: ok, got it
<pitti> smoser, utlemming, Odd_Bloke: can we drop the init= from cloud-images now? with it, installing "upstart" and uninstalling systemd-sysv doesn't actually work
<tjaalton> pitti: yes, earlier vivid from ~2 weeks ago to current
<pitti> tjaalton: good morning
<tjaalton> hey
<pitti> tjaalton: right, so curiously I can't reproduce this on current vivid, but I can now from utopic, see bug
<pitti> tjaalton: thanks for the report, sorry for the trouble
<tjaalton> pitti: no worries, it's easy to work around now that I know how :)
<tjaalton> pitti: another thing.. looks like nfs mounts aren't getting mounted on boot on my systems :)
<tjaalton> non-kerberized
<pitti> tjaalton: are you using only NM, or ifupdown?
<tjaalton> only nm
<pitti> tjaalton: that's bug 1430280; it has instructions how to fix it locally
<ubottu> bug 1430280 in network-manager (Ubuntu) "NetworkManager-wait-online.service not enabled after package installation" [Medium,Triaged] https://launchpad.net/bugs/1430280
<tjaalton> though on my main desktop/server it has a bridge set up in network/interfacese
<tjaalton> -e
<tjaalton> ok
<pitti> tjaalton: I'm working on the telinit bug first, though
<tjaalton> sure thing
<tjaalton> mount -a -t nfs is easy
<tjaalton> so there's another bug for static networks not getting set up?
<pitti> tjaalton: I thought you were using NM?
<pitti> tjaalton: oh, for your bridge? I tested that with a simple bridge and that worked; so I'll need another bug report with your particular configuration
<tjaalton> pitti: yeah the bridge one
<tjaalton> will file it
<tjaalton> against..?
<pitti> tjaalton: systemd is fine for now, I'll reassign it to ifupdown if appropriate
<tjaalton> k
<pitti> (most probably in ifupdown, but not that important)
<pitti> tjaalton: would be nice if you could check if that reproduces in a VM
<pitti> so that I can reproduce it
<tjaalton> okay
<tjaalton> I should have one ready..
<Mirv> pitti: I wonder if you'd be interested in looking at calibre FTBFS against Qt 5.4.1? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+sourcepub/4827668/+listing-archive-extra (calibre uses private symbols so it needs a rebuild)
<Mirv> pitti: Debian experimental has all of 5.4.1 already
<pitti> Mirv: in general yes, just this week is a really bad time
<pitti> Mirv: oh, just a rebuild? that's very simple then
<pitti> Mirv: at some point I should upload a newer upstraem version to Debian anyway and sync, that'll deal with it
<Mirv> pitti: just a rebuild, but since it fails to rebuild against 5.4.1 I guess something else is needed too
<Mirv> pitti: ok, regarding bad time. I can't publish 5.4.1 without the rebuild or it would be stuck in proposed, but I can forward with all the other testing since I suspect it'll take a couple of days before QA signs off 5.4.1 touch wise
<pitti> oh, that needs some actual work then
<Mirv> pitti: pyqt5 itself built fine and it's at 5.4.1 in Debian + that PPA (landing-012)
<Mirv> probably so, "TypeError: getattr(): attribute name must be string"
<pitti> Mirv: does debian and vivid have the same pyqt?
<Mirv> pitti: debian experimental plus that landing PPA have the same pyqt5 - which was required to be updated for the new Qt
<Mirv> no Ubuntu changes in pyqt5
<pitti> Mirv: ah, calibre isn't in debian experimental, so it will likely fail to build with that in Debian, too?
<Mirv> pitti: I'd say it's likely
<pitti> tjaalton, infinity: ok, I understand bug 1430479 now
<ubottu> bug 1430479 in systemd (Ubuntu) ""telinit u" under upstart (upstart's Restart command) with systemd-sysv installed runs systemd" [Critical,In progress] https://launchpad.net/bugs/1430479
<Mirv> pitti: it's notable though that 2.19.0 rebuilt fine against Ubuntu's Qt 5.4.0, so it's probably something relatively small in pyqt5 5.4.0 -> pyqt5 5.4.1
 * pitti invokes jodh
<Mirv> pitti: last bit of calibre noise that there's now a bug #1430663 about it
<ubottu> bug 1430663 in calibre (Ubuntu) "Fails to rebuild against Qt 5.4.1" [Undecided,New] https://launchpad.net/bugs/1430663
<pitti> Mirv: thanks (easier to track that way)
<dholbach> good morning
<infinity> pitti: Massive *headdesk* on the argv[0] find.
<pitti> infinity: weren't you supposed to sleep?
<infinity> pitti: As I said on the bug, we can't go back in time and fix that, so we'll need to just work around it.
<infinity> pitti: Yes, I'm typing in my sleep.
<pitti> infinity: well, it's not conceptually wrong as long as you don't take /sbin/init changes into account, but it indeed gets in the way
<infinity> pitti: It's been conceptually wrong for as long as /sbin/init has been a symlink.
<pitti> infinity: oh right, we'd need to fix that in trusty's/utopic's upstart too, so perhaps just work around it in systemd's telinit and not forward "u" to upstart at all?
<infinity> pitti: But maybe the reexec code was written before that was true, and no one caught that it should have been fixed.
<infinity> pitti: Anyhow, yeah, I think not forwarding the reexec request is probably about the best we're going to manage.  I fear this could lead to unclean shutdowns post-upgrade, but I don't know if there's much we can do about that.
<pitti> infinity: oh, we still need to forward reboot/shutdown etc, just not telinit
<pitti> "u"
<infinity> pitti: No, I mean unclean shutdowns because we didn't reexec, and we still have open deleted files and the world is confused and can't umount / sanely.
<infinity> pitti: Which is one of the two reasons (the other being security updates) that we reexec init when its deps change.
<pitti> ah, that
<infinity> pitti: In practice, this probably isn't a big deal, and $deity knows that immediately after a long apt/dpkg run, we've sure run sync(2) a whole lot, so even if the remount-ro fails, the odds of catastrophic loss are are close to zero.
<infinity> pitti: Anyhow, for now, I agree the quick bandaid is to not forward 'u' requests to upstart at all.
<infinity> pitti: We can see if it appears to cause any legitimate upgrade/shutdown issues later, or have an idle think about if there's a better way, but this seems the lesser of two weavils.
<infinity> weevils?  weevils.  I can't spell when I'm asleep.
<pitti> infinity, smoser: hm, wolfe-02 and wolfe-03 didn't come back from a reboot; do you have a serial console or something such to check what is going on?
<pitti> rebooting the others will probably lead to the same error, so I'm trying not to
<pitti> I tried to clean up after lxc-start hung forever and caused lots of woes
<infinity> pitti: Lemme see if I remember how to get at wolfe.
<pitti> infinity: ah, now I regret having pinged you as well.., addign to your sleep deprivation
<infinity> pitti: wolfe-03 is running, I suspect it has no network.
<infinity> Although, cloud-init claims it does...
<pitti> infinity: before I rebooted wolfe-03, I installed upstart (just to see whether that was it)
<infinity> ci-info: |  eth0  | True |       10.245.66.195        | 255.255.248.0 |   .   | 52:54:00:00:42:c3 |
<infinity> ci-info: |   0   |   0.0.0.0   | 10.245.64.1 |    0.0.0.0    |    eth0   |   UG  |
<infinity> pitti: Is that the right IP?
<pitti> but I rebooted teh other wolfes with full vivid upgrade (kernel+systemd) yesterday, and that worked just fine
<infinity> pitti: The NIC is up, it pings from batuan.
<pitti> 10.245.66.195, yes
<infinity> pitti: And I get an SSH banner on 22.
<infinity> pitti: So, define "not up".
<pitti> infinity: oh, so it is, sorry
<pitti> apparently it just took very long
<pitti> hah, and now wolfe-02 is back too
<pitti> odd, I've waited like 5 mins
<pitti> smoser, infinity: sorry for false alarm then!
<infinity> pitti: In wolfe-02's console backscroll, I see a network up at ~4s, and a getty at ~5.5s
<infinity> pitti: Unless it hung in grub for 5 minutes...
<pitti> and now LXC works well again, too
<pitti> ok, I'll reboot the other ones then and hope for the best :)
<infinity> pitti: wolfe-02 was broken pre-reboot because of:
<infinity> [14505.059372] INFO: rcu_sched self-detected stall on CPU { 0}  (t=11314 jiffies g=61144 c=61143 q=1
 * infinity raises an eyebrow at:
<infinity> Mem:      65903680   65835456      68224          0     161408   25564032
<infinity> I wonder if smoser overcommitted this machine again...
<infinity> Oh, I can't read, half of that is fs cache.
<pitti> ok, all of them rebooted again
<infinity> pitti: All good?
<pitti> still waiting to come back, only wolfe-03 came back so far
<pitti> but I'll be more patient this time and wait for 10 mins until I yell again :)
<infinity> There does seem to be an unusually long grub timeout.
<pitti> infinity: all back now
<infinity> Also, are we ever going to fix this kmsg spam?
<infinity> [    9.707830] systemd-logind[1244]: Failed to start user service: Unknown unit: user@1001.service
<infinity> Either that's expected behaviour and it should shut up, or we should fix the thing it's complaining about.
<pitti> infinity: we have a workaround now, just not uploaded yet
<pitti> $ sudo telinit u
<pitti> Ignoring telinit u request, systemd is not running
<pitti> ok, that's better
<infinity> pitti: \o/
<Odd_Bloke> pitti: init= should be dropped in a daily build today.
<pitti> Odd_Bloke: yay, thanks
<pitti> tjaalton: bug 1430675> did you actually install bridge-utils into the VM? THe "not found" is odd
<ubottu> bug 1430675 in systemd (Ubuntu) "fails to set up a bridged network interface" [Undecided,New] https://launchpad.net/bugs/1430675
<tjaalton> pitti: nope
<tjaalton> ah, I'll try with that installed..
<tjaalton> hm, works fine on the vm
<tjaalton> but I also see eth0 on ifconfig
<tjaalton> and nm-applet says not managed, on my workstation eth0 is not shown and n-m applet somehow manages the connections (lxcbr0 and virbr0 too)
<pitti> tjaalton: do you maybe have eth0 in /e/n/i on one but not the other?
<darkxst> cjwatson, remember our discussion about webkit2gtk? its still struggly by the looks of it, https://launchpad.net/~darkxst/+archive/ubuntu/gnome315/+build/7050436/+files/buildlog_ubuntu-vivid-i386.webkit2gtk_2.7.91-0ubuntu1%7Evivid1_BUILDING.txt.gz
<Laney> tjaalton: I reported something like this https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1422096
<ubottu> Launchpad bug 1422096 in network-manager (Ubuntu) "Occasionally no network on resume" [Undecided,New]
<cjwatson> darkxst: not really ...
<tjaalton> pitti: nope, neither of them has eth0 set up
<tjaalton> in /e/n/i
<darkxst> cjwatson, basically you said the new shiny ppa builders could handle it, yet those build failures look weird
<darkxst> aka hitting resource limits I guess
<cjwatson> well I think I probably said they ought to improve matters
<tjaalton> Laney: I've seen something similar-ish on my laptop, it doesn't have any bridges though
<Laney> same
<cjwatson> they have 4GiB of RAM; you're not going to be able to map more than that in a single process on i386 anyway!
<tjaalton> doesn't connect to wifi
<tjaalton> *reconnect
<pitti> Laney: probably a dupe of bug 1270257 ?
<ubottu> bug 1270257 in network-manager (Ubuntu) "NetworkManager failed to function after suspend and resume" [Undecided,Confirmed] https://launchpad.net/bugs/1270257
<Laney> pitti: I think that's a different old one
<Laney> the nm-applet state he describes there is different and I used to see that one from time to time too
<pitti> Laney: your syslog looks exactly like in #1270257
<infinity> darkxst: Didn't we used to work around that with -Wl,--no-keep-memory ?
<darkxst> cjwatson, mmap: failed to allocate 2291966196 bytes
<pitti> Laney: i. e. NM thinking activated -> unmanaged (reason 'sleeping') after waking up
<cjwatson> darkxst: can you even do that on i386?
<infinity> darkxst: Also, ld.gold is probably more RAM-hungry than bfd (and also known to be error-prone on some arches), why is it using it?
<darkxst> infinity, --no-keep-memory is still there I think
<infinity> cjwatson: I think our i386 kernels are 1/3 splits, not 2/2, so you should be able to map (close to) 3ish...
<cjwatson> well, this is an amd64 kernel, technically
<infinity>        --no-keep-memory
<infinity>               Use less memory and more disk I/O (included only for compatibility with GNU ld)
<cjwatson> I don't know what happens in the compat layer
<infinity> darkxst: ^-- I read that as "this is a no-op with gold".
<Laney> pitti: I suppose maybe something else might have changed to cause the different output
<infinity> darkxst: So, that would be the change.  We used to use bfd with -Wl,--no-keep-memory, using gold is probably eating all our RAM for lunch.
<Laney> I did only start seeing this very recently though, whereas that other bug is from 2014-01-17
<pitti> Laney: it's a race condition; switching init system certainly influences that, but we have reports from upstart too
<pitti> this is much more logind/inhibitor territory, though
<pitti> or changing timing because pm-utils isn't running in between
<darkxst> infinity, right, I don't know why they are using ld.gold
<Laney> There was also a n-m new upstream release around the correct time
<infinity> darkxst: Because they hate !x86 people, and they prefer fast builds over correct builds.
<infinity> darkxst: I think it's telling that, for instance, mozilla uses gold for quick iteration, but always uses bfd for release builds.
<Laney> pitti: ah! I'm on upstart atm and I have still been seeing it, forgot about that. :)
<infinity> (gold really is much faster)
 * Laney comments
<pitti> Laney: well, it's still a bug :)
<Laney> sure is
<Laney> I'm basically trying to accuse n-m and not systemd though. :P
<darkxst> infinity, maybe they are just trying to overcome the bloat factor, 3hrs to build on my dev machine
<Laney> (of making it way more frequent, even if it did happen for others before)
<infinity> darkxst: I'm sure their concern is speed, but ours shouldn't be.
<infinity> darkxst: Slapping a -fuse-ld=bfd into CFLAGS will probably solve your issue.  Probably.
<darkxst> is there an easy way to switch back via packaging?
<infinity> Or CXXFLAGS, or whatever.
<darkxst> ok
<infinity> Whatever webkit is. :P
<infinity> darkxst: Alternately, find where it's setting -fuse-ld=gold and patch it out (or maybe it's influenced by a --with-not-stupid configure option)
<darkxst> infinity, ok, easy enough, will give that try
<pitti> tjaalton: replied to bug 1430675
<ubottu> bug 1430675 in systemd (Ubuntu) "fails to set up a bridged network interface" [Undecided,Incomplete] https://launchpad.net/bugs/1430675
<tjaalton> pitti: got it, I'll try to reboot this still today
<pitti> tjaalton: is your bridge still broken, or did you ifup it manually?
<pitti> tjaalton: if it's still down, seeing the info from these commands on your currently running system should be by and large the same
<tjaalton> manual ifup
<pitti> ok
<pitti> tjaalton: so I guess you have a workaround for now, so this isn't uber-urgent now?
<tjaalton> nah
<tjaalton> do something else ;)
<pitti> tjaalton: alright; at least we got the upgrade fix in -proposed now :)
<tjaalton> yeah that's great
<LocutusOfBorg1> hi does anybody know how to contact Dave Morris?
<Odd_Bloke> pitti: How are you testing the switch back to upstart?  Just kvm on the local machine?
<pitti> Odd_Bloke: I just take a VM (with -snapshot), apt-get install upstart, reboot, and check that upstart is running
<pitti> installing upstart will remove systemd-sysv
<pitti> but that doesn't work if you explicitly specify init= of course
<Mirv> aha, someone disabled kishi arm builders and just when I was about to ask about it, I see they're back. thanks! :)
<wgrant> Mirv: That buildd network needed a bit of hardware maintenance. Should all be back now.
<matsubara> pitti, hey there. I just tried to create a new vivid testbed for adt with adt-buildvm-ubuntu-cloud and it gets stuck during the init scripts. Are you aware of bugs there?
<pitti> matsubara: are you using -v?
<matsubara> pitti, yes
<pitti> matsubara: I noticed that it sometimes gets stuck with -v
<matsubara> pitti, interesting. let me try without it
<pitti> matsubara: dropping that seems to work; investigating this is on my TODO, but not at the very top right now
<matsubara> pitti, fair enough. I'll file a bug if I gather further info.
<pitti> matsubara: thanks
<doko> mitya57, python-markdown autopkg test failure ...
<darkxst> pitti, this retracer fail make any sense to you? http://pastebin.com/DCsS2UxY
<pitti> tar: ./usr/share/doc/nettle-dbg: Cannot create symlink to 'libnettle4': File exists
<pitti> darkxst: hm, I'm afraid not
<pitti> I've never seen this
<darkxst> I've seen it a few times now
<darkxst> but I don't see how it could be caused by our ppa
<pitti> smells like a corner case bug in dpkg
<darkxst> pitti, probably, but kind of odd its such a low level package?
<infinity> That doesn't look like a dpkg bug to me, it looks like two things are trying to ship the same symlink?
<infinity> So, I'd blame whatever's creating the doc symlinks, and look at all the involved binaries closely.
<darkxst> infinity, expect the only thing different my retracer does is add in the gnome3-team ppa's, in which case its odd the lp bot tracer hasnt hit this
<darkxst> but I will check that
<infinity> darkxst: Then I would suggest the broken packages are in your PPA. ;)
<darkxst> infinity, there is nothing in our ppa that directly depends on libnettle afaik
<infinity> darkxst: Oh, so nettle-dbg_2.7.1-5_amd64.deb is coming from the archive?
<darkxst> yes
<infinity> darkxst: Huh.  Okay, in that case, I'm stumped.  And also can't reproduce...
<darkxst> infinity, yeh seems to only happen within apport-retrace
<zyga> pitti: hey, where do I report bugs on adt-run?
<pitti> zyga: against autopkgtest, please
<zyga> on launchpad?
<pitti> zyga: I read both Debian and LP bugs, so your pick (LP is magnitudes easier :) )
<zyga> hmmm, not set up for bugs
<zyga> (on lp)
<zyga> (I hate debian bugs)
<zyga> pitti: http://pastebin.ubuntu.com/10579823/
<pitti> neither Launchpad nor Debian?
<zyga> pitti: (while you set up https://bugs.launchpad.net/autopkgtest)
<zyga> pitti: I'd rather eat dirt than report bugs in debian
<cjwatson> what's wrong with https://bugs.launchpad.net/ubuntu/+source/autopkgtest?
<zyga> oh, on the source package
<cjwatson> and don't you think that's a bit childish?
<pitti> zyga: please try a non-ancient version first
<zyga> I rarely use those, not used to that concept
<zyga> pitti: do you want a bug on the package then?
<pitti> zyga: yes, that's what I meant; but please try with vivid's version first
<zyga> pitti: well, this is utopic, vivid isn't out yet :) where can I get a better version
<pitti> zyga: http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.11.1_all.deb
<pitti> zyga: installs on >= precise
<zyga> let's see
 * zyga tries the build again
<zyga> pitti: crashes the same exact way
<pitti> zyga: ack, can you please file a bug then?
<zyga> pitti: that's what I'm here for, on the source package?
<pitti> yes, as usual; "ubuntu-bug adt-run" will DTRT
<pitti> err, ubuntu-bug autopkgtest
<Bluefoxicy> why can I read acronyms I've never seen?
<Bluefoxicy> Apparently my brain will DTRT too
<zyga> pitti: nope, cannot do, I've updated the pacakge
 * zyga goes to file the bug the old way 
<zyga> pitti: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1430773 thanks!
<ubottu> Launchpad bug 1430773 in autopkgtest (Ubuntu) "crash on unicode decode error" [Undecided,New]
<zyga> pitti: I rely on adt a lot so if you need any extra bits to debug this or you want me to test a prototype branch, I'm glad to help
<pitti> zyga: hm, do you run this under a non-UTF8 locale?
<pitti> zyga: looks like "dpkg-deb --info -- twine*.deb control" would have some non-ascii characters (which is perfectly legit)
<zyga> pitti: I'm using pl_PL.UTF-8
<zyga> pitti: hmm, I ran your command on ../build-area
<zyga> pitti: and I see why it failed
<pitti> non-UTF8 data?
<pitti> zyga: either way, it's simple enough to fix
<pitti> as long as the package name isn't something funky, we can ignore errors in the rest of it
<pitti> +        if (asprintf(&(c->device_id), "fd %d", c->fsck_fd) < 0) {
<pitti> sorry, -ECHAN
<zyga> pitti: http://pastebin.ubuntu.com/10579908/
<zyga> pitti: look at the last line
<zyga> pitti: is the command I ran correct?
<zyga> twine*.deb expands to more than one file in that place
<zyga> pitti: if I just run it on the newest deb I get this http://pastebin.ubuntu.com/10579915/
<zyga> nothing non-ascii as far as I can see (though I didn't check this)
<pitti> zyga: is that anything secret? if not, perhaps you could just attach the .debs to the bug (or give a pointer to them)
<zyga> pitti: no, nothing secret at all, just work-in-progress
<zyga> pitti: oh and that package doesn't have autopkgtests either, it's just a part of my standard .sbuildrc run
<zyga> pitti: attached
<smoser> infinity, i dont really know what you'd consider overcommit.  wolfe has 9 vms, that probably are 90% idle .  each as 4G memory, system has 64G memory.  that doesn't sound terribly overcommitted.
<infinity> smoser: It's not overcommitted, I can't read.
<infinity> smoser: It's been a long day. :P
<ricotz> doko, hi :), thanks for the gcc5 builds, jfyi, something seems wrong regarding libcc1-0 in "gcc-5 - 5-20150309-1ubuntu12"
<doko> ricotz, why?
<ricotz> doko, gcc-5 hard-version-depends on libcc1-0 which is not available
<doko> ricotz, yeah, dumb packaging mistake
<ricotz> doko, alright, thanks for confirming
<rasmus_> Hi! I submitted my app to Ubuntu about half a year ago and still have not heard anything. Does anyone know how long the pending process takes?
<stgraber> bjf: Hi, so I've been talking with pitti. What you're hitting shouldn't be possible at this time as sysvinit has been fixed for that very issue a while back.
<stgraber> so it may be some upgrade mis-ordering of some kind
<pitti> well, it is possible
<stgraber> how long had it been since you last upgraded that system?
<pitti> if you run utopic with systemd and then try to install/upgrade LXC
<pitti> utopic's invoke-rc.d didn't get get along with packages which didn't have an init.d script
<bjf> stgraber, this is a fresh install of vivid on mare metal using a daily MAAS vivid image
<bjf> stgraber, i can repo it on 5 systems
<pitti> I just started utopic, installed lxc, then installed first systemd-sysv from vivid and then lxc
<pitti> that worked now
<pitti> bjf: ah, so this is not an upgrade?
<bjf> pitti, no
<bjf> pitti, it's in my testing lab ... and i've replicated it here at home as well
<ericsnow> pitti: hey, I got everything sorted out yesterday, thanks
<mdeslaur> doko: I am stealing your python-django merge
<doko> mdeslaur, steal whatever you want, but don't give it back ;p
<pitti> sticky thing, such a merge :)
<mdeslaur> doko: don't worry, you usually get it all back when you upload your next toolchain :)
<pitti> rbasak: I saw your question in bug 1409639, is that something that needs more discussion about anything?
<ubottu> bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] https://launchpad.net/bugs/1409639
<pitti> rbasak: i. e. I don't think it's a pressing matter that the tests are failing -- they'll just remind us that something needs to be fixed
<tyhicks> pitti: We'll need to check with kirkland on when he plans to cut the upstream ecryptfs-utils release and upload it to vivid
<pitti> rbasak: i. e. either making it work with systemd, or installing upstart on the instances (and the test)
<pitti> tyhicks: ah; would it hurt if I uploaded my fixes then? it causes a nasty 1.5 minute boot delay at  the moment, many people will hard-boot before that
<pitti> tyhicks: I thought you already had a vivid update prepared, and I wanted to avoid breaking that
<ogra_> Preparing to unpack .../base-passwd_3.5.37_armhf.deb ...
<ogra_> dpkg: symbol lookup error: dpkg: undefined symbol: setexecfilecon
<ogra_> dpkg: error processing archive /var/cache/apt/archives/base-passwd_3.5.37_armhf.deb (--install):
<ogra_> cjwatson, ^^^ do you have any idea what i can do there ? thats a debootstrap run of the initramfs-tools-ubuntu-touch package
<ogra_> (or anyone else familiar with debootstrap)
<ogra_> pitti, ?
<pitti> erk, never saw that
<ogra_> i wonder if it could be anyhow related to systemd (on the buildd it is actually init that fails like this)
<pitti> $ nm -D /usr/bin/dpkg|grep setexecfilecon
<pitti>                  U setexecfilecon
<pitti> so what provides that
<pitti> /lib/x86_64-linux-gnu/libselinux.so.1.
<ogra_> oh
<pitti> do we have that installed?
<pitti> dpkg depends on it, so it would be strange not to
<ogra_> not from debootstrap i think
<ogra_> note that this is a fakechroot env
<pitti> oh
<pitti> ogra_: can you strace this and see whether it actually finds the lib?
<pitti> fakechroot tends to fail a lot with newer libc versions
<ogra_> pitti, hard to do on the buildd ... and i'm not sure it is the same error
<ogra_> (i.e. what i see locally might be totally different)
<ogra_> let me re-upload the package with added verbosity :)
<tyhicks> pitti: please sync with kirkland but I think it'd be fine if you uploaded
<pitti> tyhicks: ack
<pitti> kirkland: ^ would I step on your toes if I uploaded the ecryptfs swap fixes we talked about now?
<pitti> kirkland: I see the two script fixes aren't upstream yet, but I can just add them as an Ubuntu patch for now; but I'd like to land the postinst fix for vivid users, as that's hurting quite a lot
<kirkland> pitti: hiyea
<cjwatson> ogra_: debootstrap's supposed to dpkg -x everything that's Priority: required before it tries to execute any code in the chroot, and it seems to be doing so there ...
<kirkland> pitti: let me merge them
<kirkland> pitti: and I'll release
<kirkland> pitti: do you have a merge request to lp:ecryptfs?
<pitti> kirkland: ah no, but I can do one (sorry for the misunderstanding, I thought you were just committing those)
<kirkland> pitti: that's fine, I can do that
<ogra_> cjwatson, right, i uploaded a change that cats debootstrap.log now and did set the script to -x so we get more loggign
<kirkland> pitti: I'm committing the tested changes I have to ecryptfs-setup-swap now
<cjwatson> yeah, catting debootstrap.log on failure is smart
<pitti> kirkland: as you wish; let me know if you like an MP
<pitti> kirkland: that's the offset= and the updated cipher=?
<kirkland> pitti: yeah, and one other fix to a grep/whitespace bug
<kirkland> pitti: that would affect you too
<kirkland> pitti: http://paste.ubuntu.com/10580515/
<pitti> kirkland: right, thanks
<kirkland> pitti: tyhicks: I just want to track down all of the cryptfs swap bugs that might be affected/duped here
<tyhicks> ack
<seb128> tyhicks, hey
<seb128> tyhicks, did you end up having slots to look at the schroot/ecryptfs issue?
<tyhicks> seb128: hey - I was able to reproduce the rbind issue but I haven't yet figured out the cause
<seb128> tyhicks, k, I guess it's a good start to be able to confirm that there is an issue :-)
<tyhicks> seb128: I need some more time today to look at it
<seb128> tyhicks, thanks for looking at it
<seb128> no hurry
<tyhicks> np
<bdmurray> pitti: have you seen bug 1430557?
<ubottu> bug 1430557 in schroot (Ubuntu) "sbuild unmounted encrypted home directory" [Undecided,New] https://launchpad.net/bugs/1430557
<seb128> bdmurray, pitti, I think it's the same issue I was discussing with tyhicks yesterday/now
<seb128> bdmurray, bug 1427264 / bug #769595
<ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,New] https://launchpad.net/bugs/1427264
<ubottu> bug 769595 in schroot (Ubuntu) "Encrypted home not mountable under chroot" [High,Triaged] https://launchpad.net/bugs/769595
<seb128> if it's like the click case, it tries to force unmount the bind mount and that leads to the ecryptfs userdir to be unmounted during the session
<rbasak> pitti: so I've just caught up with sinzui in #juju, and believe I have a full understanding of the situation now.
<ogra_> cjwatson, pitti https://launchpadlibrarian.net/199937417/buildlog_ubuntu-vivid-armhf.initramfs-tools-ubuntu-touch_0.85_BUILDING.txt.gz
<rbasak> It's a bit complicated because juju is both a client as well as something that deploys some release of Ubuntu.
<ogra_> so on the buildd it looks a lot worse than in my local build
<rbasak> And finally, it has juju-local which deploys LXC or KVM to what it's already running on.
<rbasak> But that's really just a special case of deploying some release of Ubuntu.
<rbasak> So as a client, no issues. No dependency on init.
<ogra_> chfn: PAM: System error
<ogra_> adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting.
<ogra_> grrr
<ogra_> i guess it is this one
<rbasak> If the client deploys to something, then right now only upstart is supported. systemd support will only arrive in 1.23.
<rbasak> 1.23 is scheduled for very close to the release of Vivid.
<pitti> rbasak: as a clietn> well, it would still need at least an init.d script or a systemd unit to start the local client, right?
<rbasak> No, the client isn't a daemon.
<rbasak> It speaks to a daemon running on deployed instances
<pitti> rbasak: oh, I was fairly sure it starts some juju service on boot
<rbasak> If the client deploys something, then what it deploys runs a daemon, and that has to run the daemon via init on boot
<rbasak> In the juju-local case, that's on localhost.
<cjwatson> ogra_: + sed -i s/raring/saucy/ ./build/etc/apt/sources.list
<rbasak> (I think that might be inside a container though, not on host itself)
<cjwatson> probably wants cleaning up too :)
<rbasak> So, Vivid is only half broken.
<rbasak> juju-local is useless right now, and will be until 1.23.
<rbasak> As a client (eg. to manage a production deployment), it's fine.
<rbasak> To deploy Vivid, it's broken, and will be until 1.23.
<ogra_> cjwatson, yeah, but it fails earlier (just doesnt exit bcause i added an: "|| cat debootstrap.log" to the script)
<rbasak> But in production use, most users will be deploying Trusty or even Precise, which is fine.
<pitti> rbasak: ah, good; I was fairly sure that lxc-local under systemd wasn't working as it doesn't start that autogenerated "local manager something" job
<cjwatson> rbasak: wgrant told me last night that juju-local was broken for him on vivid when deploying trusty, because it tries to write upstart jobs to the host and those never start
<rbasak> Yeah I'd expect that to be broken.
<pitti> rbasak: right, and landing that late seems fine; we basically land new juju releases to stables all the time anyway
<rbasak> cjwatson: OK, that makes sense, thanks.
<pitti> right, I mean those
<rbasak> pitti: right. So I think we might as well ignore the failures for now, and it'll all get fixed when 1.23 is released and uploaded.
<cjwatson> I don't know whether it works if you start those manually
<kirkland> pitti: tyhicks: the big red button has been pushed :-)
<rbasak> I could disable or remove juju-local somehow right now, but there seems to be little point if we're expecting to fix for Vivid's release.
<rbasak> (with 1.23)
<cjwatson> (I'm just sticking with upstart for now, I need juju-local and I have a bit too much state to reboot right now in any case)
<rbasak> If 1.23 is delayed (it is very close to Vivid release), we could update in an SRU to fix it, as we have the exception anyway.
<ogra_> oh !
 * ogra_ thinks he found the issue 
<rbasak> cjwatson: I'm told 1.23-beta1 will be out in the next week or two, and that'll have systemd support. So you could use that, though if you're pushed for time maybe you don't want to be a beta tester :)
<pitti> rbasak: seems fine; we've traditionally developed upstream releases alongside with ubuntu releases (betas, rcs, etc.)
<pitti> kirkland: cool, thanks! do you or tyhicks want to package that for vivid now, or should I do an upload with the postinst and offset= fix now, to take the pressure off for the new upstream release? (which might need a FFE)
<kirkland> pitti: oh -- can you send me the postinst patch?
<kirkland> pitti: I've already uploaded to vivid
<kirkland> pitti: without the postinst patch (but with the offset one)
<kirkland> pitti: we keep the debian/* dir in the upstream lp:ecryptfs
<rbasak> pitti: I'll discuss with upstream tomorrow. Right now we're still in the position that upstream separately consider what they want to land in Ubuntu post-release.
<kirkland> pitti: this shouldn't need an FFE
<pitti> kirkland: ah nice, I'll handle the postinst then
<kirkland> pitti: this is a clear bug fix
<rbasak> I'd like them not to release if they're not happy that Ubuntu would take it, and they agree, but we're not quite there yet.
<rbasak> Everyone is being very cautious about what they're prepared to push to Ubuntu (and eg. Trusty). Which is a good thing I figure.
<pitti> kirkland: there was other bits that seemed more intrusive (like https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/839)
<cjwatson> rbasak: Right, when it actually appears in a PPA somewhere I might
<tyhicks> pitti: that was a security bug fix
<kirkland> pitti: right, but that's a security critical fix;  in fact, tyhicks is handling this as a security upload for precise, trusty, utopic
<tyhicks> kirkland: the security uploads happened yesterday
<pitti> kirkland: aaand failed tests :/
<cjwatson> rbasak: Though I do have fairly pressing work to do using it :)
<pitti> kirkland: ah right, it was that one
<zyga> did anyone running vivid observe that default network inteface, given ethernet and wifi, was wifi?
<kirkland> pitti: where's the failed tests?
<zyga> I just got that, (I only realized because my wifi is terrible)
<rbasak> zyga: using network manager? I was under the impression that you end up with two default routes but with metrics that prefer the ethernet. Can you check your routing table?
<zyga> rbasak: yep, looking
<pitti> kirkland: I mean, it FTBFSed on failed "make check"
<rbasak> It's not ideal though. Stuff bound to the old IP will continue using it. And I'd like to roam between wired and wifi with the same IP (due to a public IP shortage) and that triggers IPv6 DAD and breaks things.
<kirkland> pitti: I'm looking into it
<zyga> rbasak: I cannot reproduce it just by fiddling with connections now, I see eth0 has metric=1024 while wlan0 has metric=1000 (for 169.254.0.0), both have metric=0 for 0/8
<zyga> rbasak: I can reboot to see if this happens again
<zyga> rbasak: what should the correct values be?
<rbasak> zyga: OK. I'm not sure if I can help any more though, sorry. That's as far as I know.
<zyga> rbasak: thanks!
<rbasak> zyga: hmm. According to route(8), the metric is no longer used by recent kernels. So I have no idea how it makes a routing decision now. I wonder when it changed.
<rbasak> The metric should be lower for wired though in order to prefer it. At least in the past.
<zyga> rbasak: lower? oh then it is not lower for me here
 * zyga reboots
<zyga> (in the background)
<zyga> after reboot, eth0 has metric=1024 and is the default gateway
<zyga> pinging google is unreliable though
<ogra_> pitti, cjwatson, so i think the bug i see lies within debootstrap ... systemd creates users and calls chfn, upstart didnt do that ... in the later used fakechroot-config in our build script we use we explicitly substitute chfn with /bin/true, but that doesnt help during chroot creation with debootstrap
<zyga> is route just lying to me?
<ogra_> i suspect we need to do the same thing with chfn that --vartiant=fakechroot does with ldconfig there, if i read the code right
<cjwatson> ogra_: please remove me from cc on this, I'm not going to have time at the moment
<ogra_> cjwatson, ok
<cjwatson> ogra_: I would expect Debian to have the same issue with fakechroot, so perhaps reproduce there, and maybe then debian-boot@ can help you
<ogra_> well, i dont even have a debian install :)
<cjwatson> oh come on you're using debootstrap
<cjwatson> you can debootstrap debian
<cjwatson> this is mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745082
<ubottu> Debian bug 745082 in debootstrap "fakechroot: chfn in a fakechroot environment" [Normal,Open]
<ogra_> i cant even reproduce the exact error on ubuntu :)
<ogra_> oh, thanks !
<zyga> cjwatson: truth be told I had issues with debootstrap on ubuntu, some defaults were wrong not long ago and it would misbehave or have some ubuntuisms inside
<cjwatson> zyga: and you think that's related to this?  note that Ubuntu's debootstrap is a literal copy of Debian's
<cjwatson> anyway debootstrap is used by everything, so shrug
<zyga> cjwatson: yes but it depends on some tools that are patched, from the top of my head archive signing keys were wrong and there were at least two other issues
<cjwatson> this is so vague I'm going to ignore it, bye
<zyga> cjwatson: I painfully found that trying to build a sid sbuild chroot for my debian work
<cjwatson> file bugs
<cjwatson> with actual details
<zyga> cjwatson: that was last year, I think those bugs are gone now
<zyga> cjwatson: my point was that there might be a weird difference hiding somewhere still
<ogra_> well, this particular issue simply never showed up with upstart, systemd introduced it ... cant really blame deboostrap
<cjwatson> zyga: I don't think anything this hopelessly vague is going to help anything, sorry.
<cjwatson> anyway I was trying to do entirely unrelated stuff, that's why I wanted people to stop talking to me about this :)
 * rbasak is dealing with a bug that turns out to be an uninitalised value gcc warning in a random number generator
<pitti> rbasak: "oh no, not again"? :-)
<pitti> "what can possibly go wrong"
<rbasak> pitti: this ones a bit different, but I'm being very cautious :)
<rbasak> https://bugs.launchpad.net/ubuntu/+source/percona-galera-3/+bug/1430874 if you're interested
<ubottu> Launchpad bug 1430874 in percona-galera-3 (Ubuntu) "FTBFS on powerpc and armhf due to uninitialized struct" [High,Triaged]
<pitti> rbasak: ah, not openssl then :)
<rbasak> No :)
<bdmurray> jodh: bug 1430374 is about chromium-browser just like bug 1300235
<jodh> bdmurray: wow, intriguing. What *is* chromium doing? :-)
<bjf> pitti, stgraber was anything decided about the lxc install issue i am seeing on vivid?
<pitti> bjf: I don't see it on vivid installs or upgrades; I'm afraid I need detailled logs or a reproduction recipe
<bjf> pitti, ok, i'll get that for you
<pitti> bjf: cheers!
<ogra_> pitti, do you have any idea wrt the fakechroot thing ? this is realyl blocking us on the phone
<ogra_> the only idea i would have would be to hack up debootstrap
<pitti> bjf: this morning it sounded like an upgrade failure, so I tested those; but apparently that was the wrong direction?
<bjf> pitti, yes. it's a fresh install on bare metal
<pitti> ogra_: sorry, confused: what's the issue with adduser and chfn? that doesn't work during deboostrap with fakechroot?
<ogra_> pitti, right
<ogra_> pitti, and our initramfs gets built inside a deboostrapped chroot that runs under fakechroot
<ogra_> upstart didnt create any users so we didnt hit that before ...
<ogra_> systemd wants to create a user for the timesyncd service it seems
<stgraber> bjf: I just tried to install lxc on a clean vivid install here and it worked fine
<pitti> yeah, I do that all the time, it's not that simple
<stgraber> so it's not nearly as simple as installing it on current vivid
<pitti> there must be something special in bjf's setup
<pitti> ogra_: how do you invoke debootstrap with fakechroot?
<bjf> stgraber, pitti, i'll get exact commands and a log together
<pitti> ogra_: --variant=fakechroot?
<ogra_> pitti, http://paste.ubuntu.com/10580842/
<ogra_> thats the build script
<ogra_> pitti, the -c fakechroot-config is indeed moot ... i added that out of desparation ...
<ogra_> (the one in the debootstrap call)
<ogra_> FAKECHROOT_CMD_SUBST="$FAKECHROOT_CMD_SUBST:/usr/bin/chfn=/bin/true"
<ogra_> that is what we have in that config ... just for completion
 * pitti runs $ fakeroot fakechroot debootstrap --variant=fakechroot vivid /tmp/vividfc http://archive.ubuntu.com/ubuntu/
<ogra_> pitti, i dont get the error at home ... i tried to run the whole package build ... note that this runs inside a buildd chroot usually
<ogra_> so you would have to run it inside a chroot i guess
<pitti> chfn: PAM: System error
<pitti> adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting.
<pitti> I get this
<ogra_> oh, nice
<ogra_> i didnt :P
<ogra_> pitti, colin pointed me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745082
<ubottu> Debian bug 745082 in debootstrap "fakechroot: chfn in a fakechroot environment" [Normal,Open]
<ogra_> someone there claims its a quoting issue ... but i slightly doubt that
<pitti> ogra_: filed as bug 1430891 now
<ubottu> bug 1430891 in fakechroot (Ubuntu) "debootstrapping vivid under fakechroot fails" [High,New] https://launchpad.net/bugs/1430891
<pitti> I'll look into it tomorrow morning; perhaps we can replace chfn, or use adduser instead of chfn
<ogra_> pitti, for this specific use case i wouldnt mind to just link chfn to /bin/ture ...
<pitti> ogra_: oh right, we don't really need that on the touch images
<ogra_> but i guess that would break for other cases
<ogra_> right, my prob is that it has to happen *inside* deboostrap
<pitti> libfakechroot should be used by everything there too, unless it's suid/sgid?
<ogra_> i think chfn is suid
<ogra_> which is why we override it in the fhkechroot env for all subsequent calls in that script
<ogra_> but that override doesnt do anything durin the debootstrap run
<bdmurray> mvo: with bug 1429041 - would the wrong packages also be suggested for removal?
<ubottu> bug 1429041 in apt (Ubuntu Precise) "Autoremoval not working reliably" [Undecided,In progress] https://launchpad.net/bugs/1429041
<mitya57> doko: looks like a bug in lava-server's testsuite (tries to compare unsorted arrays)
<mitya57> And also it's not a regression caused by python-markdown, it fails since March 4th
<pitti> ogra_: oh, it probably calls chfn in the generated chroot, not from the host?
<ogra_> pitti, exactly
<pitti> (was just running with -c and also tried a modified /etc/fakechroot/debootstrap.env
<ogra_> thats why i claim it has to be in debootstrap
<pitti> ogra_: oh, wait
<pitti> ogra_: I added it to /etc/fakechroot/debootstrap.env and that works
<pitti> so apparenlty -c doesn't work somehow
<ogra_> . /etc/fakechroot/chroot.env
<ogra_> FAKECHROOT_CMD_SUBST="$FAKECHROOT_CMD_SUBST:/usr/bin/chfn=/bin/true"
<mitya57> pitti: why lava-server failure is considered a regression and blocks python-markdown migration? (sorry for disturbing you)
<ogra_> pitti, thats our .env in fackeshroot-confi
<ogra_> g
<ogra_> i wonder if i coudl somehow force that var on the actual command call
<ogra_> pitti, i have some doubt that infinity will be happy if i put files into /etc on the builder :)
<pitti> ogra_: no, that was just to determine whether it works at all, or is just a problem with my -c
<mvo> bdmurray: I don't think the wrong package would be suggested, just that some are missing. but I'm not 100% confident in this I need to think this through if there might be a case where the wrong one is selected
<ogra_> riht, it works in general ...
<ogra_> *right even
<pitti> ogra_: ooh!
<pitti> ogra_: not chroot.env, debootstrap.env
<ogra_> oh ?
<ogra_> oh, so we need a second file here !
 * ogra_ tries that ... version numbers are cheap :)
<pitti> I don't know if you need another one
<pitti> ogra_: wait, still debootstrapping with that
<ogra_> well, we need the chroot.env for the actual chroot calls later
<pitti> meh
<ogra_> didnt work ?
<pitti> so why does it work in /etc/fakechroot/debootstrap.env but not in ~/fakechroot-touch/debootstrap.env
<pitti> ah, it then doesn't read /etc/fakechroot/debootstrap.env any more
<ogra_> The configuration file name is type.env and is searched at $HOME/.fakechroot and /etc/fakechroot directories.
<pitti> . o O { what would we do without strace }
<ogra_> says the manpage
<ogra_> oh, that was for -e
<pitti> ok, next try
<ogra_> not -c
<ogra_> but let me try adding that deboostrap file to the package ...
<pitti> \o/
<ogra_> tell me :)
<pitti> 5 Mark! :-)
<ogra_> lol
<ogra_> hier haste zehn :)
 * ogra_ notes down for the sprint
<pitti> ogra_: added to bug fakeroot fakechroot -c ~/fakechroot-touch/ debootstrap --variant=fakechroot vivid /tmp/vividfc http://archive.ubuntu.com/ubuntu/
<pitti> no, my dear X paste buffer
<pitti> bug 1430891
<ubottu> bug 1430891 in fakechroot (Ubuntu) "debootstrapping vivid under fakechroot fails" [Medium,New] https://launchpad.net/bugs/1430891
<pitti> ogra_: so apparently if you use -c, it *only* uses debootstrap.conf from that directory; it doesn't *also* read from /etc/fakechroot
<pitti> so I just source the original file
<pitti> ogra_: btw, I don't need another chroot.env, but probably because I don't run anything extra after that
<ogra_> right
<ogra_> we call chroot a few times later on
<ogra_> pitti, i'm wondering if we shouldnt add chfn to the file in etc though
<ogra_> seems valid
<pitti> ogra_: not having proper long user names isn't the end of the world, yeah
<ogra_> well, it will fail everywhere now
<ogra_> with systemd
<pitti> yeah, I didn't close the bug, it's just less urgent now
<ogra_> yep
<pitti> and, 12 hours already, hungry, need dinner, then basketball and stuff
<pitti> so I guess I'll call it a day before I get caught yet again :)
<pitti> mitya57: will override
<ogra_> haha, sorry for that
<pitti> ogra_: no, that's alright; image builds -> blocker -> super-urgent
 * ogra_ uploads and crosses fingers 
 * pitti hugs ogra
 * ogra_ hus pitti 
<ogra_> bah
<ogra_> i really need a new kbd
<mitya57> pitti: thanks
<pitti> stop typing on your phone :)
 * ogra_ puts some g's into the channel in advance 
<ogra_> gggg g g g g g g g
<ogra_> this keyboard isnt even a year old :/
<ogra_> and wasnt cheap either
<zul> is there a way to login to the autopkgtest after the failures?
<dobey> zul: adt-run -s iirc
<dobey> zul: ie, add -s to your adt-run clal that ran the tests; if you mean the ones in jenkins, the answer is no
<zul> dobey:  thanks
<patod> is anybody their to help me
<patod> i am novice in open source
<dobey> !ask | patod
<patod> i want to contribute in open source
<ubottu> patod: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<patod> I am biginner in open source , how can i contribute here?
<patod> can anybode suggest?
<strikov> patod: https://wiki.ubuntu.com/ContributeToUbuntu
<patod> Strikov:Thanks.
<Riddell> who's our ubiquity fixer-uper these days? https://launchpadlibrarian.net/199954530/buildlog_ubuntu-vivid-amd64.ubiquity_2.21.14_BUILDING.txt.gz
<seb128> Riddell, we don't really have one afaik
<infinity> Riddell: cyphermox
<Riddell> of course it coule be a problem in the d-i component that's causing the failure
<infinity> I suspect ubiquity needs some munging to deal with the new console-setup.
<mlankhorst> infinity: we have fglrx now, can you ack 1424980 ?
<infinity> mlankhorst: Yeahp, go for it.  Please don't break the world.  Kthx.
<mlankhorst> sure np
<kirkland> pitti: I'm going to do another release of ecryptfs that tyhicks has to fix the ftbfs
<kirkland> pitti: can you send me your postinst changes?
<kirkland> pitti: I'll test and merge and release those as part of this, if you like
<kirkland> pitti: ah, I found https://launchpadlibrarian.net/199754367/fix-invalid-cryptswap.sh
<cyphermox> Riddell: indeed, that file no longer exists, it's now named without the "My"
<bjf> stgraber, it's looking like MAAS install of vivid was/is leaving me in a totally bizarro state. i'm continuing to investigate but for now i think the problem is not lxc
<stgraber> bjf: ok
<bjf> stgraber, when you tested, you didn't use MAAS to install on bare-metal did you?
<Pwnna> does ubuntu keep a source tree of their kernels?
<stgraber> bjf: indeed I didn't. I tried on an up to date vivid bare metal system and in a fresh lxc vivid lxc container.
<bjf> stgraber, just checking. thanks
<bjf> Pwnna, yes
<Pwnna> where is it?
<Pwnna> i'm looking at for builds such as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/
<Pwnna> i think i found a regression
<bjf> Pwnna, one sec ... that's not the kernel i was expecting you to ask about
<Pwnna> alright thanks
<Pwnna> yeah. i'm fairly certain that this is an issue..
<bjf> Pwnna, if you look in the SOURCES file: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/SOURCES you will see the git location
<Pwnna> going from linux-headers-3.18.6-031806_3.18.6-031806.201502061036 => linux-image-3.18.8-031808-generic_3.18.8-031808.201502271935 disables the memory cgroup controller
<Pwnna> bjf: does that include those patches?
<bjf> Pwnna, don't know, i've never looked
<smoser> hm.. stupid question.
<smoser> my cloud-image has init=/lib/systemd/systemd
<smoser> pitti, ^ thats a temporary thing, right ?
<Pwnna> hasn't ubuntu switched over to systemd
<infinity> Pwnna: Out of interest, why are you running the untested/unsupported mainline builds instead of the distro kernels?
<Pwnna> features needed, i think
<smoser> utlemming, is build process doing that ? ^
<infinity> Pwnna: That seems unlikely, as the distro kernels tend to have more features, not fewer.
<infinity> Pwnna: Unless you mean you need newer versions on old releases, which is what the HWE kernels are for.
<Pwnna> infinity: wait. but the trusty kernel is not 3.18.x
<Pwnna> right?
<infinity> Pwnna: No, but the linux-lts-utopic kernel in trusty is 3.16, and the linux-lts-vivid kernel will be 3.19 (and is in the kernel team's PPA).  Both of those are much saner options than random mainline debugging builds.
<Pwnna> so i'm not sure why we're running on mainline kernel
<Pwnna> i think it may have something to do with some btrfs bug fixes
<Pwnna> so the regression happened somewhere between .7 and .8
<Pwnna> now i just need a diff
<Pwnna> where does ubuntu develop these patch sets?
<smoser> xnox, are you going to fix bug 1424509 ? or have you done all you're planning there..
<ubottu> bug 1424509 in postgresql-common (Ubuntu) "lsclusters claims clusters are not running, when they are under systemd" [Undecided,New] https://launchpad.net/bugs/1424509
<Pwnna> doesn't look like an upstream bug
<infinity> Pwnna: The mainline builds *are* upstream kernels, with the exception of the few tiny patches applied to make it build for Ubuntu.
<Pwnna> yeah but those patches change
<Pwnna> don't they?
<infinity> Pwnna: We neither "develop" nor support them.
<infinity> Pwnna: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.8-vivid/SOURCES shows you all the patches applied.  It's all packaging stuff.
<Pwnna> but the patches, 000*, are they changing?
<Pwnna> it might be a configuration
<infinity> Pwnna: The configs might change from time to time.  All you need to do to see that is 'diff -u /boot/config-$(old_verision) /boot/config-$(new_version)'
<Pwnna> yeah i'm tryin to do that now
<Pwnna> infinity: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.7-vivid/ doesn't have the patches?
<infinity> Pwnna: I tihnk that was before apw fixed how he published them.
<rbasak> pitti: cloud-utils is stuck in vivid-proposed because of the juju-core dep8 failure. I don't understand why though.
<rbasak> As in: why does cloud-utils require a juju-core dep8 pass?
<rbasak> Oh
<rbasak> It's backwards
<rbasak> Of course
<rbasak> pitti: in that case, would it be reasonable to have an exception for the juju-core failure, as we know it's broken but we don't want it to hold everything else up?
<Pwnna> infinity: http://pastebin.ubuntu.com/10582239/
<Pwnna> do you know where i can find the reason why this is changed?
<infinity> Pwnna: You could ask apw nicely.
<Pwnna> thanks :)
<Pwnna> apw: do you have any idea on why the memcg is disabled in 3.18.8 from the kernel options?
<Pwnna> for ubuntu's mainline build
<infinity> Pwnna: (Note that it's 9pm for him, I wouldn't expect a quick response)
<Pwnna> alright
<dobey> Pwnna: btw, you're aware of #ubuntu-kernel yes? :)
<Pwnna> i am not :P
<Pwnna> i need to signoff for the moment though. I'll be back
<dobey> the kernel hackers hang in there
<Pwnna> cool. thanks
<dobey> might be a better place to ask kernel-specific questions
<apw> Pwnna, if it is enabled for the common case, then it is because it was disabled at the time it was built
<apw> Pwnna, though sometimes they change the names of configuration options so they are off by default, and we generate those electronically
#ubuntu-devel 2015-03-12
<Pwnna> apw: i think it's also turned off for 3.18.9, i'm not sure if the name has changed (it might have, but i think start from 3.16)
<Unit193> pitti: Heh, well if it matters it popped up the volume again, either right after unpacking systemd or libpam-systemd. :P
<pitti> kirkland: right, fix-invalid-cryptswap.sh is what needs to go into postinst, protected with the usual "run this on upgrades to this version" dpkg --compare-version
<pitti> smoser: yes, the init= on cloud images is hopefully temporary; I don't know exactly where this is done, but someone (Odd_Bloke or utlemming, don't remember) told me it's going away now
<pitti> rbasak: yes, of course; it needs the release team to add a permanent "I know the test of this version is broken" exception, but I can wave through this particular one
<pitti> Unit193: oh, can you reproduce this with apt-get install --reinstall systemd? If so, can you reproduce it with "sudo systemctl daemon-reload"?
<pitti> ... and Good morning!
<darkxst> hey pitti
<Unit193> Howdy.
<pitti> hey darkxst!
<darkxst> so that retracer failure was from nettle changing nettle-dbg from a folder to a symlink
<darkxst> I guess dpkg has no idea about those changes
<darkxst> do you purge your sandboxes regularly?
<pitti> darkxst: ah, you have a permanent sandbox!
<Unit193> pitti: Yes, yes.
<pitti> darkxst: no, I use temporary sandboxes on the Launchpad retracers
<pitti> darkxst: errors.u.c. uses permanent ones, though
<pitti> I haven't gotten a report about that yet
<pitti> but yes, symlinked directories are handled specially by dpkg
<pitti> and packages need to be super careful when doing this change
<darkxst> pitti, mainscript was added in Jan
<darkxst> +dir_to_symlink /usr/share/doc/nettle-dbg libnettle4 2.7.1-5~ nettle-dbg
<darkxst> but I have only seen the error a handful of times
<pitti> right, but dpkg-deb -x obviously doesn't run them
<darkxst> yes clearly
<darkxst> pitti, I suppose you have the sandboxes in tmpfs?
<darkxst> (on the launchpad retracer)
<pitti> darkxst: no, I don't, as I don't have any root privs on the retracer box so I can't set that up
<pitti> it's a plain fs
<darkxst> does it make much difference to speed?
<pitti> it has never been a measurable bottleneck TBH
<pitti> tmpfs would certainly be a lot faster
<darkxst> ok, may try it with temporary sandboxes for a bit see how it goes
<darkxst> btw sent through a patch to make apport-retracer look in the sandbox for python scripts (pretty printers etc)
<darkxst> s/for gdb to look in the sandbox/
<pitti> darkxst: I saw, thanks!
<Unit193> pitti: Any specific reason why it'd do that?
<pitti> Unit193: I don't know, that's what I'm trying to find out :) but daemon-reload restarts generators and also does a few things, we need to zero in what causes it
<Unit193> OK, sure.  No problem.
<Unit193> I just found out I have to turn the music off before certain upgrades, or I'm in for a jump. :D
<pitti> haha
<pitti> Unit193: if you can reproduce it with reinstall/daemon-reload, can you please file a bug, so that we have a place for logs and tracking?
<Unit193> Alright..
<Unit193> Meh, looked at the journel, started to suspect something.  It was in alsa-restore/alsa-store.
<Unit193> Seems to be only triggering the former.
<pitti> Unit193: right, that makes sense, I suspected the ALSA script; but I wonder why it's being re-run
<Unit193> At least stored it at a lower volume.
<pitti> Unit193: ok, please file a bug, this shouldn't be too hard to at least track down and understand why it happens
<Unit193> pitti: Sure.  Not really sure what else to add, so 1431200.
<pitti> err, daemon-reload surely?
<Unit193> Right, that.  4am brings typos to bugs.  Sorry.
<pitti> Unit193: no worries, it most likely happens with daemon-reexec too
<pitti> (that kind of implies reloading)
<pitti> thanks!
<Unit193> Sure.
<pitti> Odd_Bloke: do you know why the current link on http://cloud-images.ubuntu.com/vivid/  is so far behind?
<pitti> it actually seems it went backwards, it now points to a rather old version which doesn't have systemd at all, not even the init= bit
<dholbach> good morning
<seb128> tyhicks, kirkland, there are several reports from users having issues with ecryptfs mounts recently in vivid, not sure if that's due to systemd or coincidence
<seb128> things like bug #1430557 or bug #1420236
<ubottu> bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [Undecided,New] https://launchpad.net/bugs/1430557
<ubottu> bug 1420236 in ecryptfs-utils (Ubuntu) "Encrypted home directory randomly unmounts" [Undecided,New] https://launchpad.net/bugs/1420236
<seb128> sil2100 just hit a case where his userdir was not mounted after logging
<seb128> qtcreator unmounts it when setting up the click schroots for me
<sil2100> Yeah, first time that happened, trying to browse my syslog for some info but so far nothing interesting
<seb128> sil2100, ^ that channel is probably better for ecryptfs issues
<pitti> I've had random cases like that for a fair while, but this sudden increase in report frequency sounds significant
<seb128> pitti, well, I've filed bug #1427264
<ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,New] https://launchpad.net/bugs/1427264
<seb128> pitti, for sure trying to use our sdk leads to issue, so maybe the sdk leads more people to use schroot
<seb128> pitti, qtcreator force unmount the schroot which unmounts your userdir in session
<seb128> *fun*
<seb128> you wonder why everything start acting
<pitti> yeah, I'm always quite confused as well
<seb128> until you open a command line or a filebrowser and see that your userdir is a README and a script
<pitti> until I do an "ls" and see the the unmounted README
<seb128> indeed
<rbasak> pitti: thank you!
<pitti> I use schroot dozens of times every day, but it only happens sometimes (not even sure it happens after schroot, or if somethign else triggers it, but it's a likely candidate)
<seb128> pitti, what fstab config do you have in your schroot?
<seb128> pitti, for me in fails 100% of the time to unmount with the default config
<pitti> /home/martin    /home/martin    none    rw,bind        0       0
<seb128> k
<seb128> same as me
<pitti> err, WTH
<seb128> you hacked it locally
<pitti> oh, leading / :)
<pitti>  /home           /home           none    rw,bind        0       0
<pitti>  /home/martin    /home/martin    none    rw,bind        0       0
<pitti> yeah, I added /home/martin as otherwise in a schroot I would only get the encrypted one; I also need the unencrypted /home/martin mount
<pitti> but I want my $HOME in schroots
<seb128> weird
<pitti> seb128: weird what?
<seb128> with the default config I do get the unencrypted userdir
<Odd_Bloke> pitti: We only update the current link once we've published to EC2, and we're currently tracking down a wrinkle in EC2 publishing.
<seb128> but that's maybe because I run those from under my session
<seb128> where the dir is unencrypted already
<pitti> Odd_Bloke: ah, ok, thanks; I was just surprised that the image I built today seemed older than yesterday's
<seb128> in any case without the /home/<user> entry I hit the issue that the bind mount can't be unmounted
<Odd_Bloke> pitti: Having read through more of the backlog, we have a cpc branch of livecd-rootfs which we build in to a PPA that we point the buildds at; we just copied the 03-boot_with_systemd.chroot hook from ubuntu-core.
<Odd_Bloke> (As you said you didn't know how we were doing it at some point)
<pitti> Odd_Bloke: ah, ok; apparently that was taken out again, /current image boots with upstart again
<pitti> as its ubuntu-meta is 6 uploads behind
<pitti> err 5; it has 1.227 but 1.332 is current
<pitti> Odd_Bloke: anyway, it'll sort itself out, thanks for the heads-up!
<pitti> Odd_Bloke: argh -- I was booting my utopic VM, sorry about the noise!
<Odd_Bloke> pitti: No worries; I was assuming it was all broken because we hadn't updated current in a while anyway. ;)
<pitti> darkxst: question in bug https://code.launchpad.net/~darkxst/apport/sandbox-autoload/+merge/252686
<infinity> pitti: So, was your assertion about weird version numbers on update_excuses that adt was returning the right data, and it's a britney bug?
<infinity> cjwatson: Could this perhaps relate to you enabling britney for multiple suites?  It's pretty suspicious that vivid's excuses is showing utopic's linux version, for instance.
<infinity> Err.  Wait.  I wonder if this relates to:
<infinity> ubuntu-archive@snakefruit:~/proposed-migration/data$ ls -l testing unstable
<infinity> lrwxrwxrwx 1 ubuntu-archive ubuntu-archive  6 Jun  6  2014 testing -> utopic
<infinity> lrwxrwxrwx 1 ubuntu-archive ubuntu-archive 15 Jun  6  2014 unstable -> utopic-proposed
<infinity> That seems not right.
<cjwatson> That probably just means it ran most recently.  I don't think those symlinks are actually used though
<cjwatson> We should probably stop creating those symlinks (in britney1) and remove them, to make sure there are no stealth dependencies
<infinity> cjwatson: The dates on the symlinks suggest they've not changed since after we opened utopic.  Maybe we forgot to move them.
<infinity> cjwatson: Or delete them entirely and see what breaks, sure.
<infinity> cjwatson: But the excuses version oddities are confusing the crap out of me.
<cjwatson> Probably.  Yeah, just drop them.
<cjwatson> Doesn't look like anything still creates them.
<infinity> Deleted.
<cjwatson> The quoted versions there come almost directly from the results file.
<cjwatson> Hmm.  Looking.
<infinity> cjwatson: Well, data/adt/vivid-proposed/amd64/vivid-proposed_amd64_linux shows 3.19.0-9.9 running.
<cjwatson> They're actually the causes.  At least sometimes.  Dubious variable use there.
<cjwatson> I: [Thu Mar 12 10:47:11 2015] - Collected autopkgtest status for linux_3.16.0-23.31/slang2_2.3.0-2ubuntu1: PASS
<cjwatson> possibly related?
<cjwatson> cjwatson@snakefruit:/home/ubuntu-archive/proposed-migration/autopkgtest/work$ fgrep 3.16.0-23.31 *vivid*
<cjwatson> adt.result.vivid:linux 3.16.0-23.31 PASS slang2 2.3.0-2ubuntu1
<xnox> doko_: boost1.57 is in experimental new queue... and in https://launchpad.net/~xnox/+archive/ubuntu/scratch/+packages
<infinity> http://paste.ubuntu.com/10584838/
<xnox> doko_: it's "unsplit", however 1.58 rc was posted this morning. =(
<cjwatson> infinity: Could you try http://paste.ubuntu.com/10584839/ ?
<infinity> cjwatson: lver being lastversion or something?
<cjwatson> as in coming from pkglist rather than pkgcauses
<cjwatson> pick a better name if you like, the important bit was to be different from ver in the outer loop
<infinity> Ahh, didn't noticed the outer loop had the same var.
<cjwatson> Looks like a very plausible cause for version confusion to me.
<cjwatson> Anyway, apply that live, run, see if you get more sensible output
<cjwatson> (or wait for the next run)
<infinity> cjwatson: cowboyed, waiting for next run.
<infinity> And ubuntu-archive's INBOX is being spammed with:
<infinity> W: Unknown Multi-Arch type 'no' for package 'compiz-core'
<infinity> W: Unknown Multi-Arch type 'no' for package 'compiz-gnome'
<infinity> lolz.
<cjwatson> from chdist apt-get update I guess?
<infinity> cjwatson: Yeah.
<infinity> cjwatson: It's not wrong about the bug, just an entertaining place for me to find out. :P
<cjwatson> Will be fixed when snakefruit has a newer apt.
<infinity> Hrm?  Newer apt actually likes that value?
<cjwatson> http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=8f617600aeb931574baf0b53617e7759baa3f370
<infinity> Oh, the spec defines it.  I've never seen it used.
<cjwatson> Maybe it's worth SRUing that apt change to shut things up, otherwise we have to put up with cron spam for the next several years until those chdists run on trusty+4
<cjwatson> (But if we're SRUing anything to trusty's apt, I should include the source caching change ...)
<infinity> cjwatson: Well, there's an SRU in progress right now for an AutoRemove bug.
<infinity> cjwatson: But tossing this commit in with the source caching thing as an "archive support SRU" seems reasonable.
<cjwatson> infinity: The source caching stuff is in ppa:~launchpad/ubuntu/ppa if you feel like chasing it up
<infinity> cjwatson: Output from the cowboy seems more reasonable, if you'd like to commit that.
<cjwatson> infinity: can't
<infinity> cjwatson: Oh.  Hahaha.
<infinity> cjwatson: I'll commit, then. :)
<cjwatson> Thanks :)
<cjwatson> Good, that's been a long-running itch
<rbasak> Do we know why monitoring-plugins didn't autosync? I don't see it in http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<infinity> rbasak: autosync is off.
<rbasak> infinity: I mean back when it was on.
<rbasak> There may be some conflict with nagios-plugins that needs resolving
<rbasak> BUt I'd expect to deal with that in vivid-proposed?
<rbasak> Probably too late for Vivid now, but I'm wondering why it hadn't come up before.
<infinity> cjwatson: Reminds me, you might want to train someone else in the joys of autosync (or, the manual bits).
<infinity> rbasak: There's some manual stuff involved when autosyncing NEW sources, I believe.  Nothing stopping you from just syncing it now.
<cjwatson> infinity: not any more
<Laney> rbasak: http://people.canonical.com/~ubuntu-archive/auto-sync/current.log is enlightening
<cjwatson> Yeah, I was about to link to that
<cjwatson> We auto-sync NEW packages unless there are problems preventing it
<infinity> Ahh.
<cjwatson> So, yeah, it's the overwrite of modified nagios-plugins
<rbasak> Ah, OK.
<cjwatson> Unmodified stuff would get autosynced
<rbasak> I was aware of it but assumed it would be automatic and was too busy with other things to pay attention.
<cjwatson> But in this case you need to check the Ubuntu delta and see if it needs to be ported
<cjwatson> Automation here would risk losing Ubuntu changes
<rbasak> I see
<cjwatson> Until about three months ago the only way to know about this was to run auto-sync manually or have access to my inbox
<rbasak> That makes sense. I hadn't considered the interaction of the delta with the autosync before. Thanks
<cjwatson> So at least now there is a log *somewhere*, even if it's slightly under a rock
<mlankhorst> meh..
<mlankhorst> do I get outb on qxl?
<mlankhorst> does arm64 have outb?
<infinity> mlankhorst: Given the total lack of sys/io.h, I'm going to go with no.
<mlankhorst> meh..
<mlankhorst> https://launchpadlibrarian.net/200012400/buildlog_ubuntu-vivid-arm64.xserver-xorg-video-qxl_0.1.1-0ubuntu4build1_BUILDING.txt.gz
<mlankhorst> seems outb is no longer defined for arm64..
<mlankhorst> maybe convert to libpciaccess?
<mlankhorst> it won't work either, but at least it will build..
<infinity> mlankhorst: "no longer" implies that it was, at one point, defined.
<infinity> mlankhorst: I assure you that I didn't drop io.h between glibc 2.19 and glibc 2.19. :P
<mlankhorst> probably xorg-server changes..
<pitti> didrocks: nice, I just fixed pgbouncer, that was my last "Jenkins Failure" email in my inbox
<pitti> our > 1000 package tests were rather helpful for this transition
<mlankhorst> anyway all packages build in the ppa now..
<mlankhorst> can someone sponsor http://paste.debian.net/plain/160914 ?
<mlankhorst> and http://paste.debian.net/160915/ please, looks like freedreno's not part of the xorg packageset yet
<tjaalton> i can do those
<tyhicks> seb128: I've been prioritizing a (minor) apparmor feature over the eCryptfs schroot/unmounting issue(s)
<tyhicks> seb128: but I'll bump it up and focus on it before everything else today
<tjaalton> mlankhorst: hum, aren't the debs copied from the ppa? so no need to sponsor these
<tjaalton> oh the rest got uploaded already
<popey> hmm, my laptop has been sat doing a dist-upgrade "Setting up systemd (219-4ubuntu5) ..." for some time.
<popey> [Thu Mar 12 13:02:42 2015] Watchdog[1507]: segfault at 0 ip 00007f64e92f083e sp 00007f64d9fbd250 error 6 in libcef.so[7f64e89e5000+46b8000]
<popey> related?
<popey> hah, now it carries on...
<popey> blimey, that took a loooong time.
<rbasak> Google suggests that libcef.so is related to Spotify
<cyphermox> good morning!
<seb128> tyhicks, thanks
<caribou> Laney: can pull-lp-source pull from PPAs ?
<Laney> caribou: Nope
<caribou> Laney: thanks :)
<infinity> caribou: It's perhaps poorly named, and should be pull-ubuntu-source
<Laney> I could imagine it getting a parameter to change the archive it uses though
<infinity> But yes, adding a --archive feature would make it work.
<caribou> Laney: infinity: I'll look into that if I have a minute
<infinity> caribou: Cargo-cult the archive parameter from 'copy-package {--from,--to}'
<caribou> infinity: k
<cjwatson> Except that IIRC ubuntu-dev-tools has its own caching LP abstraction layers for everything, so you may have to argue with those.
<rbasak> I usually find the .dsc and then use dget. It'd be nice to have it integrated though. Together with pull-debian-source. How about "pull-source" that just DTRT?
<infinity> rbasak: Well, "pull-source" would still need a --debian switch, so having the other name also works.
<infinity> rbasak: On the off chance that we accidentally have the same version but different contents.
<rbasak> It'd be nice to be able to do "pull-source debian:hello"
<rbasak> Or "pull-source ppa:racb/mystuff/hello", or "pull-source hello" to default to ubuntu: or something.
<infinity> rbasak: Not sure how that's much different from pull-debian-source hello.  And the latter tab-completes more easily with less typing. :)
<cjwatson> We should use LP's archive reference syntax rather than inventing a new slash-separated thing, for consistency among tools.
<infinity> We should.
<infinity> Of course, I still need to train my fingers to use it.
<rbasak> I was thinking of add-apt-repository. Does that do its own thing already though?
<cjwatson> It does sort of, it predates archive references.
<cjwatson> Also predates derived distributions, so it had to be changed.
<cjwatson> But it's close.
<infinity> add-apt-repo and old-style dput are just missing the distro bit, aren't they?
<caribou> infinity: don't start to train yet, not sure I can dive into it that easily
<cjwatson> In the archive reference syntax, "debian" means the Debian primary archive, so it shouldn't be that hard to use.
<infinity> ie: user/ubuntu/archive instead of user/archive
<cjwatson> infinity: Yes, and they have an extra leading ppa:
<cjwatson> Oh and the ~ stripped off
<infinity> Right.
<infinity> ppa: == ~ more or less.
<infinity> That's the bit my fingers are retraining for.
<cjwatson> Yeah, there's an argument for keeping that as syntactic sugar because it saves on escaping ~
<cjwatson> I wonder if we should change ArchiveSet.getByReference to accept that.
<cjwatson> Or maybe it should just be at the command-line tools level.
<infinity> Wouldn't hurt my feelings if it Just Worked at the API level.
<infinity> Given that most people who've done archive reference at the CLI level are used to ppa:foo/bar, why force a pointless syntax change when they go to abuse it at the API level?
<cjwatson> wgrant: ^- WDYT?
<wgrant> I'd really prefer not...
<infinity> I figured that would be his answer. ;)
<wgrant> ppa:user/archive is an abomination. It's ambiguous.
<cjwatson> Oh, we should keep the distribution.
<cjwatson> add-apt-repository already accepts that.
<infinity> wgrant: ppa:user/distro/archive
<cjwatson> But I mean ppa:user/distro/archive as an alias for ~user/distro/archive that doesn't require protection from shells, so is easier to use on command lines.
<infinity> wgrant: Colin was talking specifically about making ppa: and ~ synonymous, not about using the old form with one missing component.
<wgrant> Oh, if you require ppa:, sure.
<wgrant> I thought you were saying that an archive reference 'wgrant/ubuntu/ppa' would work, which is insane.
<wgrant> I clearly didn't read back far enough.
<wgrant> (but to avoid escaping I usually just use --from=~wgrant/ubuntu/ppa)
<cjwatson> Yeah, me too, but it's a slightly annoying gotcha.
<infinity> Is that a fragile and scary bash feature, or POSIX?
<infinity> (base)adconrad@cthulhu:~$ echo --foo=~adconrad/foo/bar/whee
<infinity> --foo=~adconrad/foo/bar/whee
<infinity> (base)adconrad@cthulhu:~$ echo foo=~adconrad/foo/bar/whee
<infinity> foo=/home/adconrad/foo/bar/whee
<infinity> That kinda freaks me out.
<cjwatson> I think that's POSIX.
<cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
<cjwatson> Though I'm not sure, that shouldn't count as the beginning of a word and isn't an assignment.
<rbasak> I was just going to say - using ~ in a CLI to mean something else might mean some escaping pain. I didn't realise it was that...surprising.
<rbasak> And of course it only applies if it gets a hit from NSS.
<rbasak> $ echo foo=~robie/bar
<rbasak> foo=/home/robie/bar
<rbasak> $ echo foo=~rbasak/bar
<rbasak> foo=~rbasak/bar
<wgrant> It's odd in this case because it's part of a URL, except everything up to the first slash in the path is implied.
<cjwatson> This disagrees with bash's documentation, AFAICS.
<wgrant> eg. the branch lp:~foo/bar/baz syntax isn't a problem, because it has another token before it.
<cjwatson> I wonder if it's misfiring and considering it an assignment.
<wgrant> But infinity's behaviour is very surprising.
<cjwatson> And dash doesn't do this.
<wgrant> I hadn't realised it did that.
<mlankhorst> tjaalton: nah the ppa was for testing, after that was done I uploaded the same _source.changes to the archive
<cjwatson> http://wiki.bash-hackers.org/syntax/expansion/tilde notes this as questionable
<wgrant> Isn't it more of a POSIX violation than a questionable feature? :)
<cjwatson> Probably, yeah
<tjaalton> mlankhorst: guess I'm living in the past, where packages were copied from the ppa
<mlankhorst> yeah
<wgrant> How very odd.
<infinity> cjwatson: It might be for post-assignment in make.
<infinity> cjwatson: ie: make foo=~person/stuff
<infinity> And the lazy approach was just to evaluate everything that looks like an assignment rather than special-case ever name for "make".
<infinity> s/ever/every/
<cjwatson> Well, if that's true it should at minimum be documented
<infinity> Yeah, just a shot in the dark.  It really just looks like a bug.
<wgrant> Hopefully it won't start magically interpreting it as code this time.
<infinity> $ echo foo=~adconrad/foo
<infinity> foo=~adconrad/foo
<infinity> $ echo --foo=~adconrad/foo
<infinity> --foo=~adconrad/foo
<infinity> $
<infinity> dash appears to do what POSIX says.
<infinity> Oh, you noted that.
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/ppa-archive-reference-alias/+merge/252753
<mlankhorst> oops siliconmotion fails without outb too, meh
<infinity> mlankhorst: Curious.  Did something change in a macro or header exposed by xorg?
<infinity> mlankhorst: Cause glibc hasn't changed in any meaningful way since trusty.
<tjaalton> mlankhorst: did you check upstream git?
<ricotz> doko_, hi, regarding "gcc-5 - 5-20150311-1ubuntu12", now lib32mpx0 is missing
<mlankhorst> tjaalton: no I doubt upstream has outb support
<mlankhorst> infinity: the headers for xorg-server changed, that probably unmasked those build errors..
<happyaron> what's the approperiate way to enable partner repository by default? (Ubuntu Kylin wants it) I'm seeing apt-setup of ubiquity, is it?
<tjaalton> oh fedora got rid of it already
<tjaalton> why can't we? :)
<mlankhorst> ooh reading the driver reminds me of the vga days
<mlankhorst> ton of vga programming in there
<mlankhorst> tjaalton: unfortunately pstream still puts in bild fixes to siliconmotion :/
<tjaalton> ajax, who dropped the drivers from fedora
<tjaalton> let's just drop all the non-kms drivers in v+1 :)
<mlankhorst> last codechurn commit appears to be in 2010
<tjaalton> minus blobs..
<mlankhorst>     Fix lack of precision in video resizing. #26443
<rbasak> doko_: do you think you could provide transitional packages for http://launchpadlibrarian.net/199658027/juju-core_1.20.14-0ubuntu2_1.20.14-0ubuntu3.diff.gz ? Then Juju upstream wouldn't need to maintain separate branches with different build-depends lines for their backports.
<rbasak> I don't know if that is sensible or not, but I thought I'd ask.
<doko_> rbasak, what do you mean?
<rbasak> doko_: have the new source package provide libgo5 and gccgo-go binaries
<rbasak> That are empty and just depend on gccgo.
<mlankhorst> meh, I'll just replace outb and inb with some macros
<rbasak> mlankhorst: on a Build-Depends? Is that possible?
<Pwnna> does this channel have logs?
<doko_> rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo
<Pwnna> my buffer only goes back so far..
<rbasak> Pwnna: http://irclogs.ubuntu.com/
<rbasak> doko_: so the libgo5 b-d was never needed? Then we might be able to drop that for all releases so that wouldn't be a problem.
<doko_> rbasak, well, you build-depend on gccgo anyway, do you?
<rbasak> doko_: in Vivid we can. But in older releases that doesn't exist so is no good for backports.
<rbasak> And currently we don't have backport branches - they all share the same packaging, which is convenient.
<rbasak> But we do depend on gccgo-go everywhere, so if that pulls in libgo5 we don't need it explicitly, so could drop it.
<rbasak> 15:08 <doko_> rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo
<rbasak> Would you be OK with having this package until Trusty EOLs?
<rbasak> I guess that's a bit unusual for a transitional package maybe, but unless we keep it that long there's no point in doing it, so I thought I'd check.
<rbasak> An empty gccgo-go binary I mean.
<rbasak> mlankhorst: oh, sorry, you were talking about something else :)
<mlankhorst> yeah
<doko> rbasak, an empty gccgo-go binary package should be good enough, depending on gccgo. no need to build-depend on libgo5
<rbasak> doko: ack. Thanks. I'll check it does what we need and upload.
<mlankhorst> well looks like the outb are easy to convert
<mlankhorst> meh..
<doko> rbasak, jamespage: fyi, I verified that docker.io builds with golang 1.4.2 (in the doko/toolchain PPA)
<rbasak> Thanks! kickinz1: ^^
<jamespage> doko, ok - so I think we're also planning to bump docker version to the one in experimental (1.5.0) but that needs to go via the release team as yet
<jamespage> 1.3.3 + 1.4.x of go has some problems with sqlite stuff
<jamespage> which is already impacting on the ppc64el version but not the x86
<jamespage> having the golang version aligned makes alotta sense imho
<doko> jamespage, like https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1431032
<ubottu> Launchpad bug 1431032 in gccgo-5 (Ubuntu) "powerpc: cgo appears disabled somehow" [Undecided,New]
<jamespage> doko, not that one
<mlankhorst> does anyone even have a siliconmotion device here?
<doko> jamespage, I would prefer 1.4.2, and backport this fix to GCC 5 too
<didrocks> mvo_: hey, stupid question about conffile prompt. So, I removed from whoopsie the "enabled" line (as we are going to handle it via override/systemctl). However, there is another value report_metrics which isn't in /etc/default/whoopsie by default, but that people may enable via a gnome-control-center capplet. I think we don't want them to be prompted by a conffile change (the change being removing the
<didrocks> "enable") line and my sedding in preinst won't prevent that, how do you handle that generally?
<didrocks> mvo_: as there is only a second value, I can of course cache it in preinst, do the changes I need in the conffile (which is empty it), and reset the value of report_metrics then, but it sounds hackish
<mvo_> didrocks: in a meeting, easiest is probably to have ".d" directory
<infinity> didrocks: If it's a dpkg conffile, and it's being edited by gnome-control-center, that's your bug.
<infinity> didrocks: That's a massive policy violation.
<didrocks> infinity: well, I guess it's ev's one in that case, but I doubt he will work on it (anyone in fundation working on whoopsie?)
<mlankhorst> ok fixed up siliconmotion
<ev> policy smolishy
<didrocks> I don't plan to work on whoopsie for the record, was just here to help on the migration
<ev> didrocks: bdmurray is your guy
<mlankhorst> i probably broke it in the process on supported platforms, but at least that might show if someone's using it..
<didrocks> ev: ok, giving the hot potato to him then! thanks ;)
<ev> sure thing
<didrocks> bdmurray: I guess we can have a debconf prompt on upgrade due to whoopsie, I'm happy to discuss it with you
<didrocks> (to give you details)
<mlankhorst> infinity: oh can xserver-xorg-video-modesetting be deleted?
<mlankhorst> moved to xorg-server
<infinity> mlankhorst: The source package, you mean?  Or both source and binary?
<didrocks> bdmurray: as infinity told, whoopsie shouldn't edit those values using the conffile, I think we should get the report_metrics value migrated
<mlankhorst> infinity: source and binary
<mlankhorst> all the packages recommending modesetting have been fixed
<infinity> mlankhorst: Does the new xorg-server P/C/R xserver-xorg-video-modesetting in an attempt to smoothly transition?
<mlankhorst> yes, except p
<infinity> C/R is fine for forced removal, yeah, as long as nothing depdends on it anymore.
<didrocks> mvo_: maybe you would have some opinions once your metting is done ^ (and no .d directory, it's already existing code)
<didrocks> meeting*
<mlankhorst> only some of the ddx packages were recommending it, but I fixed those in the transition
<infinity> mlankhorst: Which package has the conflict/replace?
<mlankhorst> xserver-xorg-core
<infinity> didrocks: The only way to avoid a conffile prompt is to never change the conffile.  But you can fudge it in pre/post by caching values, restoring to pristine, and then reinjecting values in post.
<bdmurray> didrocks: does anything really modify report_metrics?
<infinity> didrocks: Really, though, that file should not be a conffile at all if it's being edited at runtime.
<infinity> mlankhorst: Yeah, no.  It's not. :P
<infinity> mlankhorst: That has a versioned Breaks/Replaces on xserver-xorg-video-modesetting, that's not what you want if you want to force the package off.
<didrocks> infinity: agreed, I discovered that was the way it worked when doing the systemd transition though :)
<infinity> mlankhorst: You want an unversioned Conflicts/Replaces.
<didrocks> bdmurray: yeah, gnome-control-center privacy capplet
<mlankhorst> infinity: ah, but the version in vivid is only 0.9..
<didrocks> bdmurray: part of whoopsie-preferences
<mlankhorst> so << 0.10 will kill it
<infinity> mlankhorst: Doesn't matter.  Breaks/Replaces is for overwriting files, not packages.
<mlankhorst> oke..
<infinity> mlankhorst: Trust me, you want C/R, and unversioned.
<mlankhorst> oke
<mlankhorst> sec then
<infinity> mlankhorst: I mean, sure, versioned if the package is going to show up again later and not conflict, but then you wouldn't be asking me to remove it.
<mlankhorst> it might, x has split out all its drivers before
<didrocks> bdmurray: I suggest that you changes whoopsie-preferences to read/write to another file, and we remove the conffile on whoopsie upgrade + create the other file with the cached value if report_metrics was true
<mlankhorst> irony is that they're getting back..
<mlankhorst> infinity: ok I've added C/R unversioned
<rbasak> doko: does http://paste.ubuntu.com/10586133/ look OK to you please? I had to add the dh_gencontrol line so I tacked it on to the gccgo package build. Also the final deb produces /usr/share/doc/gccgo-go -> cpp - is this correct?
<pitti> smoser, infinity: hm, all of wolfe-0X give me "Permission denied (publickey)" on ssh now..
<smoser> pitti, looking
<smoser> pitti, seems batuan is denying me
<smoser> and if i dont hop through there.
<pitti> ah, confirmed
<pitti> is that IS? or CI?
<infinity> IS.
<doko> rbasak, urgh, adding it to gcc-defaults?
<infinity> Didn't they send a warning that they were cutting everyone off the jumphosts and it was VPN or die?
<rbasak> doko: well that's where gccgo is. Where do you want it instead?
<pitti> infinity: ooh! it indeed works without the ProxyCommand now, nice!
<doko> rbasak, well, then maybe just providing gccgo-go should be good enough
<pitti> smoser: so, all good, thanks (and you should probably update your ssh config too :)
<cjwatson> Yeah, the batuan VPN has gone bye-bye.
<mvo_> didrocks: well, not too much that can be done really, you could do crazy preinst magic or try ucf, do you have some more details or a open bugreport?
<cjwatson> And indeed probably the jumphost too.
<rbasak> doko: good point. I'll just add the Provides to gcc-defaults then. Thanks.
<pitti> die, ProxyCommands, die!
<smoser> so.. given that, and the fact that i used ProxyCommand to do shell hostname hack-resolution... as desscribed here:
<smoser>  http://bazaar.launchpad.net/~smoser/+junk/ppc64el-kvmhelpers/view/head:/ip4ppc64el
<smoser> is there a way other than using:
<smoser>  ProxyCommand nc -q0 $(ip4ppc64el %h) %p
<smoser> to get the hostname translation done ?
<didrocks> mvo_: tried to express that on bug #1431432
<ubottu> bug 1431432 in whoopsie (Ubuntu) "conffiles prompt on vivid upgrade if report_metrics is enabled" [Undecided,New] https://launchpad.net/bugs/1431432
<caribou> Is there a way to have sbuild take locally built packages into account to fulfill BuildDeps ?
<rbasak> caribou: I have a hack that I use, but I'd love to know if there's an easier way
<rbasak> I set $external_commands in ~/.sbuildrc to add an extra local repository and apt-get update
<caribou> rbasak: that's what I tried first
<cjwatson> smoser: I don't think so, unless you switch to generating .ssh/config sshebang-style.
<rbasak> It's a bit painful. I have scripted most of it, but it involves adding the key the Releases file is signed with with apt-key add
<rbasak> (and of course generating Release and Packages and signing Release)
<caribou> rbasak: I was hoping to do "dpkg -i {}.deb" but the chroot is amd64 and it builds armhf
<infinity> mlankhorst: That looks better, thanks.
<tarpman> caribou, rbasak: sbuild 0.65 has some improvements wrt. that use case: --extra-repository and --extra-package
<rbasak> caribou: you should be able to do that in $external_commands I think. In that environment, apt-get has to be able to install build dependencies anyway so presumably it works.
<cjwatson> caribou,rbasak: sbuild >= 0.65.0-1 in unstable has --extra-repository and --extra-package options, but that hasn't been ... that
<cjwatson> too slow
<cjwatson> Oh, in fact, that's in vivid too
<rbasak> Oooh, nice!
<caribou> cjwatson: tarpman: thanks I'll look into that
<tarpman> rbasak: also 'deb [trusted=yes] file:/...' in sources.list lets you skip the signing dance. hat tip to geofft for that one
<smoser> cjwatson, thanks. i didn't think so either. i'll just leave the 'nc' proxycommand in place :)
<rbasak> Thanks - I think I learned about that later but never put it together with my hack.
<rbasak> I usually have a ~/repo/ directory that contains scripts "add" and "rebuild".
<rbasak> And ~/repo/key
<rbasak> "add" runs apt-key add against key
<rbasak> and adds to sources.list
<rbasak> And "rebuild" runs apt-ftparchive and gpg appropriately
<rbasak> So then my .sbuildrc just needs to run "add"
<rbasak> It's handy when testing inside containers and PPAs too.
<rbasak> uh, KVM machines. Not PPAs. That makes no sense.
<didrocks> infinity: ok, conffile now killed on upgrade, I need to work on the g-c-c capplet side though as nobody seems to own it
<infinity> mlankhorst: Remind me about the removal when the world is ready to migrate.  Can't do it now without breaking things.
<didrocks> bdmurray: can you make core-dev ables to push to lp:whoopsie (same for whoopsie-preferences if it's not the case), please?
<bdmurray> didrocks: do you know which part of LP is the right place to do that?
<infinity> bdmurray: Add core-dev to the team that owns the branch.
<infinity> Assuming that's the canonical packaging branch.
<didrocks> https://launchpad.net/~daisy-pluckers
<infinity> If there's a clear upstream/packaging split, tell didrocks to join daisy-pluckers to do upstream work? :P
<didrocks> infinity: no split :p
<bdmurray> there isn't but I'm not sure of everything daisy-pluckers can do
<didrocks> I'm doing that's patch, because I won't let you down, but to be clear, I'm not a whoopsie maintainer :)
<infinity> Looking at some of these branches, yeah, I'm not sure you want all of core-dev there.
<didrocks> bdmurray: look at all branches it has access: https://code.launchpad.net/~daisy-pluckers
<didrocks> bdmurray: I'm fine with pushing packages if you merge the content back
<infinity> didrocks: Just send an MP?  Or just upload and make bdmurray commit the debdiff. :P
<didrocks> I will go with the second :)
<didrocks> btw, bdmurray, seems latest upload isn't in lp:whoopsie
<didrocks> from rsalveti
<doko> seb128, didrocks: please fix the component-mismatch mess which robert_ancell just introduced by promoting indic-fonts
<mlankhorst> hmm
<mlankhorst> oh forgot to set a build-depends on qxl
<didrocks> doko: want to trade with whoopsie? It's coming from your team afterall :)
<mlankhorst> and ati it seems
<doko> didrocks, whoopsie ie evil
<ev> breaking my heart, doko
<doko> ... oops, evand even
<doko> heh
<ev> :-P
<doko> didrocks, so nothing to trade ;-P
<ricotz_> doko, did you notice my complaint about the recent gcc-5 build ;P
<didrocks> doing things in my priority order then ;)
<doko> ricotz_, it's fixed
<seb128> doko, didrocks, robert_ancell can fix it
<doko> seb128, yeah, can't see him neither here nor on #distro
<ricotz_> doko, i mean: regarding "gcc-5 - 5-20150311-1ubuntu12", now lib32mpx0 is missing
<seb128> doko, he's living in .nz
<seb128> so sleeping
<Laney> Pretty sure he's aware and will work on fixing it
<mlankhorst> infinity: so new xorg-server built, can you delete modesetting now?
<infinity> mlankhorst: That doesn't seem to be the only thing preventing migration.
<mlankhorst> infinity: it will be soon, I rebuild bumped the missing bits
<mlankhorst> infinity: how about now? radeon seems to be missing from the autohinter, but it's built in -proposed correctly now..
<mlankhorst> yeah just modesetting blocking now
<infinity> mlankhorst: Yeah, looks good now.
<mlankhorst> \o/
<infinity> mlankhorst: Removal done.  Should migrate soon.
<asac> anyone knows what KERNEL vs KERNELS is in udev land?
<asac> like first entry in this has KERNEL== ... the rest has KERNELS== https://pastebin.canonical.com/127488/
<asac> opops bad pastebin :)
<asac> http://paste.ubuntu.com/10587178/
<asac> ok i think i found it kinda here: https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html
<flexiondotorg_> Are there any sponsors here who could help expedite some Ubuntu MATE stuff?
<flexiondotorg_> cyphermox, Are you available for some sponsoring?
<cyphermox> flexiondotorg_: maybe later, but you can point things out or subscribe ubuntu-sponsors, so it shows up in the sponsoring overview.
<cyphermox> bbl
<knome> hey infinity, did you get bluesabre's ping about the ubiquity slideshow earlier? do you have time to upload it, or should we ask somebody else?
<infinity> knome: Oh, you might be better off finding another sponsor.  I finished off that xfce4util transition for you, though.
<knome> infinity, ok, cheers
<knome> ^ all that being said, anybody can sponsor the ubiquity slidehow upload?
<Unit193> infinity: Noticed, thanks very much!
<seb128> tyhicks, thanks for investigating those mount issues!
<tyhicks> seb128: no problem
<knome> Riddell, since you've done it before, would you mind doing a release for the ubiquity slideshow again? we've prepped the xubuntu slideshow and updated translation templates in main
<Riddell> knome: I'm working on it right now, however did you know?
<knome> Riddell, oh, thanks! :D
<knome> Riddell, i guess it's some kind of UIF day black magic
<Riddell> knome: your stuff is commited and ready to update?
<knome> Riddell, yes! :)
 * knome bows very deeply
<Riddell> knome: groovy, I'll upload when kubuntu stuff is done
<knome> cheers!
<knome> Riddell, i see the upload - thanks - are the translations templates updated automatically to LP or do we need to take actions?
<Riddell> knome: launchpad should extract them out of the .deb I think
<knome> ok, we'll wait until tomorrow or sth
#ubuntu-devel 2015-03-13
<Unit193> pitti: Good morning.
<darkxst> Unit193, hey, can you make a branch against lp:ppa-versions with your changes, I couldnt download the paste
<darkxst> (will merge everything except the change of debian tracker, kind of like the new better)
<Unit193> darkxst: Uhh, sure.  I wouldn't recommend it though, I don't know python so it's all hacks. :P
<darkxst> Unit193, it looked ok to me
<pitti> Good morning
<pitti> FTR, I lost overnight scrollback; thanks to unity crashing 30 seconds after I started my session (during dist-upgrade)
<darkxst> hey pitti
<darkxst> pitti, anyidea how to change the location of /tmp in python? I tried to set TMPDIR, but retracer is failing
<darkxst> dpkg-deb: error: unable to create temporary directory: No such file or directory
<pitti> darkxst: hm, did you create $TMPDIR actually?
<darkxst> pitti, yes, its in my home folder
<pitti> darkxst: AFAIK the tempfile module ought to respect $TMPDIR
<darkxst> thats what I though
<darkxst> thought
<Unit193> darkxst: Try that?  And don't say I didn't warn you. :P
<pitti> $ mkdir /tmp/x; TMPDIR=/tmp/x python3 -c 'import tempfile; print(tempfile.NamedTemporaryFile().name)'
<pitti> /tmp/x/tmpfkpdqt0l
<pitti> seems fine to me, I also tried with mkstemp()
<pitti> darkxst: hm, no idea then; can you run strace on it and see what it tries to do?
<darkxst> pitti, nm, was just a typo
<darkxst> Unit193, are you using some script that messes with whitespaces?
<Unit193> No.
<darkxst> Unit193, why are there unrelated whitespace changes in your commits then? http://bazaar.launchpad.net/~unit193/ppa-versions/xfce-changes/revision/45 for example
<Unit193> darkxst: 'commit file.py -m' vs 'commit -m', noticed I missed them too late in rev 41.
<darkxst> Unit193, can you generalise this, so the list comes from the profiles (http://bazaar.launchpad.net/~unit193/ppa-versions/xfce-changes/revision/40)
<darkxst> and make it get_upstream_extra
<darkxst> will use it in gnome for freedesktop modules
<Unit193> Uhh.
<Unit193> Had to filter out the veeery old (not in Debian, don't actually have releases, etc.) packages, so it's a bit specific.
<darkxst> err, right misread that
<darkxst> was only glancing though looked like you were adding a list of extra packages to pull in
<Unit193> No, but thought about that next as there's a few more I'd like to track.
<Unit193> But, not sure that'd actually work.
<darkxst> Unit193, add a dictionary to the profiles, something: upsteam_extra = {upstream:package, ... }
<darkxst> may need a path in there as well though I suppose
<Unit193> Yeah, and upstreams tend to be a bit different.
<darkxst> Unit193, maybe upstream:path would be better
<darkxst> or you can do a list of tuples
<darkxst> [(upstream, package, path)]
<darkxst> I think the ubuntu-desktop script does something like that
<darkxst> Unit193, http://bazaar.launchpad.net/~ubuntu-desktop/ubuntu-desktop-versions/trunk/view/head:/packages.py
<darkxst> pitti, the symlink hackery ok with you or should it perhaps live in sandboxutils?
<pitti> darkxst: haven't looked in detail yet, but probably okay
<darkxst> pitti, its all a little horid, but the auto-load framework way pre-dates the introduction of python scripts
<darkxst> and solib-absolute-path gets stuff in the middle of the file names
<darkxst> I've not seen anything in the scripts I have worked on (mainly glib and mozjs) that would require deadlock versioning, but then I also haven't seen any of the old .gdb scripts
<AndrewMock> I would like to know why the trusty/nginx-light package includes so many extras...
<jamespage> pitti, Daviey: morning - I have a conditional release team ack for https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1423601
<ubottu> Launchpad bug 1423601 in ceph (Ubuntu) "[FFe] ceph 0.93 -> hammer release" [High,Triaged]
<jamespage> but I need a willing archive admin for the minor python-* package split that I'm tracking from upstream packaging - would one of you be OK with doing the binary NEW's for that?
<pitti> jamespage: yes, can do if it happens today (will be on vac next week)
<jamespage> pitti, will upload shortly - thanks!
<jamespage> pitti, ok - uploading now - it will take a few hours to complete the builds
<dholbach> good morning
<Unit193> darkxst: Hah, whoops.  When re-importing the changes, I spelled 'utcnow' as 'uctnow', FYI.
<ogra_> cjwatson, i got an oops fo you :) https://launchpadlibrarian.net/200087368/upload_22505_log.txt
<ogra_> *for
<pitti> Unit193: question for you in bug 1431200
<ubottu> bug 1431200 in systemd (Ubuntu) "daemon-reload runs alsa-restore.service and others" [High,In progress] https://launchpad.net/bugs/1431200
<cjwatson> ogra_: Apparently livecd.ubuntu-touch.system-i386+generic_x86.img was zero-sized.  Do you know why?
<Unit193> pitti: Answer for you.
<ogra_> cjwatson, no, i got a build log by mail where it seems to finish fine
<ogra_> hmm
<pitti> Unit193: thanks; I wanted to see if it was ConditionFailed=, such as in a VM; daemon-reload would retry those
<ogra_> Unmounting chroot for build LIVEFSBUILD-22505...
<ogra_> RUN: /usr/share/launchpad-buildd/slavebin/remove-build ['remove-build', 'LIVEFSBUILD-22505']
<ogra_> Removing build LIVEFSBUILD-22505
<ogra_> cjwatson, thats the last three lines
<cjwatson> ogra_: Right, so did I, the build clearly succeeded but appears to have resulted in one of the output files being zero-length
<cjwatson> Where the previous version was 105.4 MiB
<cjwatson> ogra_: I'm afraid I don't have an explanation for you, other than that the zero-sized file is what caused this OOPS (perhaps we could make that more obvious, but it still ought to fail because it's broken).  There's no sign of a cause of this in the livefs build log nor in the buildd-manager logs, and livecd-rootfs is just copying that file out of the android binary package where it isn't zero-sized.  The only suggestion I have is to ...
<cjwatson> ... dispatch a new build.
<ogra_> cjwatson, yeah, will do that and see
<pitti> Unit193: can you actually reproduce this with just daemon-reload?
<pitti> Unit193: I can't, I need apt-get install --reinstall systemd
<Unit193> pitti: Yes, I can.  I just did in fact.
<pitti> zyga: ah, you and your C locale.. :-)
<pitti> this really doesn't belong on a desktop..
<zyga> pitti: hmm? what :)
<pitti> folks, at least use C.UTF-8 for $deity's sake :)
<zyga> pitti: where?
<zyga> pitti: :D
<pitti> zyga: bug 1431421
<ubottu> bug 1431421 in autopkgtest (Ubuntu) "adt-run could export the SUDO_ASKPASS variable to the testbed" [Undecided,New] https://launchpad.net/bugs/1431421
<pitti> zyga: sorry, bug 1430773
<ubottu> bug 1430773 in autopkgtest (Ubuntu) "crash on unicode decode error" [Low,Triaged] https://launchpad.net/bugs/1430773
<pitti> zyga: (fixed now)
<zyga> pitti: I don't set the C locale anywhere
<zyga> pitti: (thanks)
<zyga> pitti: I don't know why that happened
<zyga> pitti: could it be because my pl_PL.UTF-8 locale was unavailable in my sid sbuild chroot?
<pitti> zyga: you call this as part of some sbuild command, right? perhaps that removes the locale at the time whne you call adt-run
<zyga> yes
<zyga> pitti: http://paste.ubuntu.com/10590142/
<zyga> this is my .sbuildrc
<pitti> zyga: ah, you call adt-run *inside* the schroot? and then let this start  another chroot?
<zyga> not sure, this is from sbuild debian wiki page
<pitti> ah ok, I blame sbuild then :)
<zyga> looks like it yeah
<zyga> those run inside the chroot AFAIK
<zyga> pitti: though I totally agree about C being evil
<pitti> apw, jodh: \o/ on #1429756, nice work!
<apw> pitti, jodh gets a prize for a reproducer i could fit in a VM
<pitti> apw: ah, and then git bisect run FTW? :-)
<apw> pitti, no i read the 600M strace log to find the symptoms, and from there i could find the commit that changed that area, and then ...
<jodh> pitti: right, apw really deserves the prize for finding the needle in the 600M haystack! :-)
<pitti> ok, I'm afraid you guys have to share the prize then..
 * apw gets a cookie out of the jar
<pitti> especially since it's already so small -- it's a silly green bullet in jenkins! :-)
<zyga> pitti: wow, I nice catch with "you've"
<zyga> pitti: I pasted that from twine docs
<pitti> zyga: well, it's legit -- debian control files are UTF-8
<pitti> (and changelogs, etc.)
<zyga> pitti: yeah though mainly for names
<zyga> pitti: sbuild should have better defaults IMHO
<ogra_> cjwatson, same error on rebuild, i uploaded a livecd-rootfs with more verbosity for the copying of the android bits ...
<cjwatson> and did it reveal anything?
<cjwatson> oh, the rebuild wasn't with that upload
<ogra_> hasnt migrated yet
<ogra_> right
<ogra_> it looks to me like it never even hits the copy code on i386
<cjwatson> that wouldn't explain a zero-length file
<ogra_> right
<cjwatson> if it never hit the copy code the file in question would be missing instead
<Riddell> mvo: what is stopping packagekit being updated to 0.9 ?
<cjwatson> Riddell: needs https://code.launchpad.net/~mvo/click/native-dbus
<cjwatson> well, that might be for 1.0.0
<cjwatson> yeah, plugin support went away in 1.0.0 not 0.9
<doko> didrocks, please could you fix the recommends for grilo-plugins? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<darkxst> doko, grilo-plugins-extra was never meant to be main'ed, but no one knows who promoted it
<didrocks> doko: not sure why this is directed to me, seems the guy who promoted it didn't read the MIR (nor changed the bug report status)
<didrocks> doko: so, we need to discuss it first once the people acting on the bug are around
<doko> didrocks, afaicr you were the person requesting that in the past. anyway, demoted the extra package
<didrocks> doko: I never requested promoting grilo, only review the MIR. I wouldn't request btw as I can promote it myself
<didrocks> doko: I get you are mixing with darkxst (but we all start with a d :p)
<Odd_Bloke> Does the 7 day SRU timer start from it hitting -proposed, or from verification-done?
<infinity> Odd_Bloke: The former.
<Odd_Bloke> \o/
<Odd_Bloke> infinity: Thanks. :)
<didrocks> infinity: oh btw, you will be pleased to know that I nuked this morning the whoopsie conffiles
<didrocks> bdmurray: mind merging my 2 uploads to whoopsie and whoopsie-preferences?
<infinity> didrocks: \o/
<infinity> didrocks: Swapped from conffile to config file?
<infinity> didrocks: Or did away with the need for it entirely?
<didrocks> infinity: unfortunately, couldn't go away completely, so config file for one remaining option, but basing the enabled checkbox based on service status (being under upstart or systemd)
<jamespage> pitti, ceph is built on some archs - I'm working on ppc* and armhf right now
<ogra_> cjwatson, LOL
<ogra_> cjwatson, so i replaced all cp with "cp -v" to get more info ... and now the build just succeeds
<cjwatson> Heh
<mvo> Riddell: if plugins are still supported, then nothing
<Riddell> mvo: is packagekit(-qt) a reasonable choice for e.g. dolphin file manager installing samba so it can share files?
<mvo> Riddell: is that something that you would add? that should be fine, the session installer api supports "install_packages" which you can just feed the samba names
<Riddell> mvo: I'm thinking of a gsoc project to add that sort of feature in various places
<Riddell> mvo: and the samba name could be hardcoded or could use appstream? except appstream has limited support in ubuntu
<mvo> Riddell: yeah, the limited support is a issue as is that the packagename is different in different distros :/
<Riddell> mvo: if DEP-11 gets implemented by debian does that help ubuntu at all?
<mvo> Riddell: a bit maybe, but because debian uses dak and ubuntu LP for the archive I doubt it will help that much, maybe, depends how deeply this is entangled into dak I guess
<Riddell> mvo: right
<caribou> Is there a specific method to add a patch to a dkms package that doesn't use quilt or just add the file in ./patches & edit dkms.conf ?
<infinity> caribou: dkms.conf:PATCHES[#]= is the correct way.
<caribou> infinity: thanks
<seb128> pitti, bdmurray, btw bug #1427264 has details about the schroot/ecryptfs/userdir mount issue, not specific to ecryptfs but to configs where /home is a separate mount
<ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264
<tyhicks> seb128: you mean where /home/USER is a separate mount
<tyhicks> seb128: /home being a separate mount is no problem
<seb128> tyhicks, right
<seb128> sorry ;-)
<tyhicks> no prob :)
<tyhicks> seb128: after we have a chance to better test the fstab change, do you think we should change the fstab file in the click package to do the rprivate /home?
<seb128> tyhicks, I don't understand enough about the implications to have an opinion on whether that's the right solution I think :-/
<seb128> but if it works +1 from me
<tyhicks> (after I get to test it some more, I plan on updating https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648459 to suggest that the default profile be changed)
<ubottu> Debian bug 648459 in schroot "schroot doesn't mount /home submount into the chroot" [Normal,Open]
<tyhicks> seb128: ok, I know someone that can review the change and tell me about the implications
<seb128> tyhicks, great, let me know how it goes, I'm happy to help testing
<stokachu> @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: stokachu
<doko> jamespage, rbasak: I think even updating golang to 1.4 will break building some of the ubuntu-touch apps. thanks due to embedded outdated go packages not packaged for ubuntu :-/
<jamespage> doko, ohno
<doko> jamespage, plus will break golong-log4go. there exist some patches in the upstream package, but this project seems to be dead
<doko> should be updated by somebody having go coding experience
<doko> jamespage, subscribed you to 1431872
<flexiondotorg_> didrocks, Please would you be able to take another look at - https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487 ?
<didrocks> flexiondotorg_: I guess better to ask that to the patch pilot
<didrocks> flexiondotorg_: or wait for my shift
<flexiondotorg_> didrocks, Tanks.
<flexiondotorg_> Or Thanks, you choose.
<didrocks> ;)
<flexiondotorg_> stokachu, While you're piloting, please could you take a look at https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487
<stokachu> flexiondotorg_: sure!
<flexiondotorg_> stokachu, Yo.
<flexiondotorg_> stokachu, Thanks for looking at my merge proposal.
<flexiondotorg_> I am very sick right now, so my initial comment in there is not friendly.
<flexiondotorg_> stokachu, I apologise for that.
<flexiondotorg_> stokachu, Regarding https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487
<stokachu> yea i got that...
<flexiondotorg_> I am not sure how to resolve the source-is-missing lintian errors.
<stokachu> dunno dude im off duty now
<stokachu> @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:
<flexiondotorg_> Please can you spare some wisdom.
<Unit193> flexiondotorg_: https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubuntu-mate-update/+merge/251487/comments/628312 seems to say he'll take care of the other lintian warnings.
<flexiondotorg_> Unit193, Thanks for bring y attention to that comment. Just refreshed and see it now :)
<flexiondotorg_> I can fix the warning at least :)
<doko> stgraber, please file MIRs for new lua-filesystem b-d's: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<stgraber> doko: done
<stgraber> not sure how I missed the build-depends when I did the lua-filesystem MIR...
<doko> meh, the nth text to html converter
<doko> stgraber, bug subscribers missing ...
<stgraber> doko: ah yeah, I'll subscribe to both
<stgraber> doko: done
<doko> stgraber, not lxc-team like lua-filesystem?
<stgraber> doko: well, if lua-filesystem is broken, that affects lxc, if the b-d of lua-filesystem are broken for something other than lua-filesystem, the lxc team won't care
<doko> then subscribe foundations, but not a single person
<stgraber> I'd have subscribed foundations if I could have, you need to be team admin to subscribe a team...
<doko> bdmurray, ^^^
<stgraber> oh, actually, looks like I can use ubuntu-foundations-team
<stgraber> because canonical-foundations-team admins it
<stgraber> doko: done, moved to foundations
<bdmurray> it should be foundations-bugs subscribed
<bdmurray> to lua-filesystems is it?
<doko> no, markdown and dh-lua
<bdmurray> okay, done
<doko> stgraber, please unsubscribe ubuntu-foundations-team
<stgraber> done
#ubuntu-devel 2015-03-14
<doko> ScottK, Riddell: please fix the kdepim-runtime b-d's. they apparently need a more restricted version of something. now given back
<doko> same for kdepim
<Unit193> darkxst: Hello, we don't seem to share any better channel for this, so.  I think there's something lost in communication, it reads like you believe I'm trying to get the changes in, I'm not, they're hacky but they function well enough for what I need.  It's great that you did merge some of them, heck that could even get us cleaner methods. :)
<darkxst> Unit193, its ok there is no point diverging the code
<Unit193> Only thing to do next is fix the 'goodies' section, it's of course close but not quite right.  Doesn't do the upstream <=> debian comparison.
<darkxst> Unit193, the version comparison won't be able to distinguish between what was added as goodies, unless the pkg names are incorrect
<Unit193> Sure, that's fine.
<darkxst> and its working for your core apps?
<Unit193> Yeah.
<darkxst> so the entries you put in the packages dict must not be quite right
<Unit193> darkxst: PM?
<darkxst> ok
#ubuntu-devel 2015-03-15
<ahoneybun> hey guys and gals I'm having a problem logging into the wiki: http://pastebin.ubuntu.com/10601070/
<dobey> ahoneybun: was a little slow for me, but worked fine here just now. i think you also want #canonical-isd for help with that sort of issue
<Nikhil> Heya everyone
<Nikhil> can anyone tell me in which programming language should I learn to develop software for ubuntu
<sarnold> Nikhil: depends what you want to do..
<Nikhil> I want to develop GUI stuff in ubuntu
<Nikhil> any idea of programming language, I know C++ presently
<ScottK> Nikhil: Learning Qt5 (which is built on C++ would be a good start then).
<Nikhil> ok, ScottK. What are the libraries that include ubuntu os
<ScottK> If you're on an Ubuntu system, you can try the command "apt-cache show unity8" and that will show you the different libraries that the Ubuntu GUI depends on (in the Depends section).
<Nikhil> ScottK: Are they already installed in the system?
<ScottK> Not all the headers are.  If you do "sudo apt-get build-dep unity8" that will install the headers and anything else needed to build the package.
<Nikhil> ok thank you ScottK
<ginggs> Hi, do I need a FFe to fix a FTBFS that will bring a new version out of proposed? https://launchpad.net/ubuntu/+source/abyss
<darkxst> ginggs, that seems a bit extreme, why not just cherry-pick the patch that fixes the FTBS?
<ginggs> darkxst: the new version has been sitting in proposed for some time. it couldn't migrate because of the FTBFS
<infinity> ginggs: Nothing wrong with fixing the version in proposed, no.
<infinity> ginggs: If there were too many negatives in that sentence, go for it.  Fix that FTBFS.  Woo!
<ginggs> infinity: thanks
<darkxst> infinity I having way to much fun trying to inject import hooks into gdb for the auto-load scripts, probably mis-read the original question!
<darkxst> it aint working though, guess I might need to patch gdb
<zyga> xnox: hey, ubuntu-drivers looks pretty neat!
<zyga> xnox: I have a question about intel microcode
<zyga> xnox: what are the consequences of enabling that?
<kunal21> hiii everyone .... please help me.... I just want to know how to package a phython app developed using QUICKLY toolkit on Ubuntu 14.04LTS
<kunal21> #debian-python     hiii everyone .... please help me.... I just want to know how to package a phython app developed using QUICKLY toolkit on Ubuntu 14.04LTS
<melodie> hi
<infinity> zyga: The consequence of installing intel (or amd) microcode is that your CPU's microcode is hotpatched at boot to the latest upstream version.  This is all scary black box binary blob nonsense, but so is your CPU to start with, so it's not really making the situation worse. :P
<infinity> zyga: Intel and AMD regularly update said black boxes for bugs, security issues, etc.  Sadly, they rarely tell us WHY they're updating them, so you don't get to make much of an informed decision, just "update" or "don't update".
<infinity> zyga: All that negativity aside, if you own such a CPU, it's probably saner to use the updates than not, even given all the caveats.
<infinity> zyga: Be warned, though, that because it's a black box, we can't in any way guarantee it does sane thing.  Like the Intel update last year that disabled an entire instruction due to it being buggy, which led to us having to SRU glibc so it wouldn't crash trying to use it.
<infinity> s/sane thing/sane things/
<melodie> infinity what means "to SRU" please?
<infinity> melodie: SRU == stable release update.  As in, we had to push a new glibc to old stable releases to cope with intel-microcode breaking the world.
<zyga> infinity: thanks for explaining that, I was hoping there would be more transparency but I guess this is as good as it gets
<zyga> infinity: TXT fiasco, yeah I remember that
<zyga> melodie: stable release update
<melodie> infinity ok thank you
<zyga> melodie: it's a process where we release something to all the supported releases
<melodie> zyga thanks
<zyga> melodie: https://wiki.ubuntu.com/StableReleaseUpdates
<melodie> reading
<melodie> infinity so it was not possible to do it reverse side, as downgrading the intel microcode firmware (is it a version available in the repositories?)
<infinity> melodie: We could have downgraded it in the distro (and did until the glibc updates happened), but that doesn't prevent people from using the upstream microcode directly.
<melodie> infinity this is what I feared, always the same problem with non free code. :-(
<infinity> zyga: TSX, not TXT, but yes.
<infinity> melodie: To be (sort of) fair, Intel doesn't make a habit of breaking ABI in their own CPUs.  But this was the exceptional case that goes to demonstrate how scary microcode updates can be.
<melodie> infinity has anyone from the Ubuntu/Canonical teams got in touch with them when this happened?
<melodie> even non free codes could get a bug report once a while, especially when microcodes for the most currently used cpus are involved
<zyga> infinity: transactional memory? IIRC that was TXT (or was that trusted execution again)
<melodie> where exactly is setup the method allowing to get the default configuration files in the home's new user created? It's not in /etc/skel although this is what is written in /etc/adduser.conf, is it possible that it's in the sources of each desktop's session manager? (such as lxsession, gnome-session and so on?)
<melodie> diving in all the configuration files didn't help, and neither did googling
#ubuntu-devel 2016-03-14
<cpaelzer> good morning
<pitti> Good morning
<pitti> cjwatson: looking
<pitti> cjwatson: fix pushed, I'll watch the next wily run
<infinity> xnox: okular/s390x is holding up a fairly large transition due to its autopkgtest regression.  None of our kubuntu folks have s390x hardware access, would it be possible for you to look into what's failing?
<pitti> do we even care?
<pitti> (we could just ignore the s390x failure)
<pitti> infinity, cjwatson: ok, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is back
<ricotz> pitti, good morning :)
<ricotz> pitti, do you have a moment to take a look at https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1556651
<ubottu> Launchpad bug 1556651 in plank (Ubuntu) "FFe: Update plank to 0.11.0" [Undecided,Confirmed]
<pitti> smoser, rbasak: nova-lxd wants to go from main to universe, is that intended?
<dholbach> good morning
<pitti> ricotz: what about it?
<pitti> it's already approved
<ricotz> pitti, ah, flexiondotorg's comment is already sufficient
<yofel> pitti: from the kubuntu side: feel free to ignore s390x
<yofel> and I don't understand autopkgtest yet again
<yofel> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libkdegames
<yofel> is kept back because yet another build for an outdated version (tmp)failed
<yofel> where did the libkdegames trigger even come from?!?
<yofel> there was no change for that
<pitti> I reran these failures earlier today
<pitti> yofel: err --     Depends: kpimtextedit kio (not considered)
<pitti> sorry, wrong paste
<pitti> libkdegames (4:15.08.2-0ubuntu1 to 4:15.12.1-0ubuntu1)
<pitti> there sure is an update of libkdegames
<yofel> yes, but I uploaded rebuilds of the games for the lib transition. It even shows those builds in the autopackagetest logs. But after that it went and build another test set for the previous versions
<yofel> why?
<pitti> sorry, I don't understand the question
<pitti> that s390x test should either succeed on the retry, or we ignore it (if something is broken on s390x, and we don't care)
<pitti> either way, once this knetwalk 390x test goes green or yellow, libkdegames will become a valid candidate
<yofel> take e.g. http://autopkgtest.ubuntu.com/packages/k/knetwalk/xenial/s390x/
<yofel> it did a build because of knetwalk 4:15.12.1-1ubuntu2 using 4:15.12.1-1ubuntu2 -> OK
<yofel> then, *after* that, it went and build the test again using 4:15.12.1-1ubuntu1 -> why?!?
<pitti> well, it was tested once for the new knetwalk and once for the new libkdegames
<pitti> and since the latter is a transition, it had to use the knetwalk from -proposed as well
 * pitti is still confused what your question is
<yofel> I don't get why it built an older version after a newer one. After all ubuntu2 should've been in proposed at that time, until the publisher delayed things
<yofel> *unless
<pitti> we test packages in -proposed in isolation (as much as possible)
<pitti> https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/038985.html
<yofel> well, then maybe I just don't get why britney is showing what it does.
<yofel> libkdegames cannot migrate with knetwalk ubuntu1, it requires ubuntu2. The autopkgtest for ubuntu2 was OK, but then the one for ubuntu1 failed.
<yofel> So while britney should be able to migrate libkdegames just fine, it's now not considering it because a test for a version that's superseded and doesn't help failed.
<yofel> guess I'll read the docs linked from there later, thanks
<pitti> yofel: knetwalk ubuntu2  wasn't in proposed yet when that test ran for libkdegames
<pitti> yofel: the queued retry will use ubuntu2 of course
<yofel> ok, thanks
<pitti> stgraber, smoser: hmm, having lxd preinstalled on cloud images isn't helpful -- the default ubuntu user can't actually use it as it's not in the lxd group; will cloud-init get changed for that too?
<rbasak> pitti: that's one for zul or jamespage I think.
<rbasak> jamespage: see 07:30 above.
<doko> argh, tcl/tk 8.5 in main again?
<doko> hmm, never demoted
<doko> xnox, pitti: any opinion on the cmake update?
<pitti> doko: I'm not opposed per se, but we'd need a test rebuild of the rdepends, and there are ~ 1500 of them..
<pitti> doko: and there's an ubuntu delta "Revert back to 3.2.2, build issues on armhf, arm64 and powerpc." which does not have much further details; bug 1534263 has open questions about that
<ubottu> bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.4 series to Ubuntu Xenial 16.04LTS" [High,Incomplete] https://launchpad.net/bugs/1534263
<doko> yeah, I can't remember ...
<LocutusOfBorg> pitti, s/3.4/3.5? :(
<LocutusOfBorg> :)
<pitti> LocutusOfBorg: I don't know, the bug says 3.4
<LocutusOfBorg> 3.5 uploaded some hours ago in debian
<caribou> When loading a new package to stable releases (Universe), is there a specific process or it just a normal SRU ?
<caribou> I'm loading a new mstflint4 package for the mstflint source pkg which has the Xenial version
<pitti> l
<doko> Pharaoh_Atem, any idea about the remctl ftbfs?
<juliank> mvo_: I disabled SHA1 support in APT yesterday, and want to get this into xenial; as that's going to be supported until 2021, and who knows how secure SHA1 is by then.
<LocutusOfBorg> Hi, can anybody please explain to me "ImplicitPointerConversions" issues?
<LocutusOfBorg> https://launchpadlibrarian.net/247604891/buildlog_ubuntu-xenial-amd64.ipmitool_1.8.16-1_BUILDING.txt.gz
<juliank> This does not yet require GPG signatures to use stronger hashes, though.
<LocutusOfBorg> "Function `getpass' implicitly converted to pointer at ipmi_user.c:486"
<LocutusOfBorg> I see the header file included
<juliank> that seems broken
<LocutusOfBorg> Adding the prototypes inside the .c files works, but seems obviously wrong to me
<pitti> stgraber: http://autopkgtest.ubuntu.com/packages/l/lxc/trusty/ppc64el/ â it seems we lost the ppc64el images on https://images.linuxcontainers.org/images/ubuntu/trusty/ ?
<juliank> LocutusOfBorg: That seems somewhat crazy :/
<LocutusOfBorg> indeed
<juliank> Same for the strtok_r things
<LocutusOfBorg> "index" is a misssing strings.h include
<LocutusOfBorg> but the others... are something worrying
<juliank> LocutusOfBorg: Even with the missing include, it should not convert the *function* to a pointer. The return type would be considered int, and thus trigger an implicit conversion (int->ptr) warning
<juliank> Unless the 'Function `index' implicitly converted to pointer at ipmi_sel.c:2397' is misleading and means function result
<doko> pitti, I assume the ruby-defaults triggered autopkgtest failures need a walk through, and maybe rebuilds against the -proposed pocket ...
<pitti> doko: yes, I already requeued some tests this morning
<doko> ahh, fine
<pitti> doko: I'm waiting for the current backlog to settle down, then do my usual walk through excuses
<pitti> doko: there's also some s390 fallout to sort out and stuff
<pitti> but queues were quite full, and I just pushed a workaroudn for bug 1556175, so it'll still take a bit
<ubottu> bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged] https://launchpad.net/bugs/1556175
<doko> pitti, s390x should be fixed now with the new ruby2.3 upload (-4ubuntu1)
<pitti> doko: oh, my retry from last night worked alredy
<doko> lamont wanted to work on the dhclient issue (re-introducing the second set of bind9 libs)
<pitti> ah no, it didn't; /me kills the hanging s390 build of ubuntu1, indeed
<pitti> doko: yes, I talked to him on Friday; seems it's a known problem/known solution, just SMP
<pitti> "Rests not run on $(DEB_HOST_ARCH)" :)
<doko> mehh
<infinity> LocutusOfBorg: The log makes it pretty clear that it's an implicit declaration.  So "the header is included" can't be the whole story.
<pitti> doko: resting is always good!
<smb> pitti, kinda both related to the combined bind9 lib which moved to use threads
<pitti> smb: yes, I know now; just took me a while on Friday to track down
<smb> pitti, Sorry you had to spend time there again. I try to get people aware of this (and the complete failure to run as a daemon) for a while now
<LocutusOfBorg> infinity, I hthink I got it
<LocutusOfBorg> damn old Makefile.am
<infinity> LocutusOfBorg: s/std=c99/std=gnu99/?
<LocutusOfBorg> they used INCLUDES instead of AM_CPPFLAGS
<infinity> LocutusOfBorg: std=c99 skips get _USE_MISC-wrapped getpass in unistd.h
<LocutusOfBorg> ok indeed
<LocutusOfBorg> I tried c89, but yes, gnu99 is the good one
<infinity> Not sure if that's true for the other implicit declarations, but easy enough to check.
<LocutusOfBorg> I did put some #error in string.h to see where and when they were used
<infinity> LocutusOfBorg: Looks like just s/std=c99/std=gnu99/ in configure.ac and configure (or just .ac if the package autoreconfs) will DTRT.
<infinity> But I'm looking at this blind. :P
 * infinity goes middle of the night hamburger hunting.
<LocutusOfBorg> :)
<LocutusOfBorg> infinity, if it works, I'll give credits to you ;)
<LocutusOfBorg> your "don't know" is order of magnitude better of my "i'm sure"
<LocutusOfBorg> infinity, strange enough, running autoreconf might be also a fix
<LocutusOfBorg> I'll do some more testing
<pitti> hm, new ruby2.3 and new perl in about half an hour, the test queues won't get any shorter today :)
<ogra_> and new kde (or is that through already ?)
<doko> and php7 not yet migrated ...
<pitti> doko: ah, they found some actual crashes like ruby-awesome-print (looksl like debian bug 816161)
<ubottu> Debian bug 816161 in src:ruby-awesome-print "ruby-awesome-print: FTBFS: Aborted (core dumped)" [Serious,Open] http://bugs.debian.org/816161
<pitti> hm, two reverse build deps
<pitti> ogra_: it didn't land yet, but testing for it is mostly through (some regressions, though)
<cjwatson> pitti: wily autopkgtest> thanks
 * pitti goes through the KDE and some older ruby failures
<Laney> pitti: thinking about skipping okular/s390x
<pitti> Laney: yep, that was one I was about to add too
<pitti> Laney: it was briefly discussed this morning here
<Laney> cool
<Laney> pitti: is it package/arch/version?
<pitti> Laney: yes, something like okular/all/s390x
<Laney> pitti: so package/version/arch? :)
<pitti> Laney: err, sorry for confusion; yes, there's some precedent in current hints
<Laney> pitti: yeah, I was confused a bit
<Laney> you have a diffoscope hint which is p/a/v but I guess just a braino :)
<pitti> Laney: thanks, fixed locally
<Laney> nice
<pitti> Laney: I'm queueing a few hints ATM, I'll add okular too
<Laney> already done oular
 * Laney wants poppler to go through
<pitti> Laney: poppler still has some issues: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti>     * amd64: libokular-perl, libsmokekde-dev, libsmokeokular3, okular-backend-odp
<pitti> ^ and okular too
<Laney> ok
<Laney> I needed okular to be a candidate to see that
<Laney> something suspicious is going on with my desktop
<Laney> schroot -x xenial-amd64 ...
<Laney> this shouldn't take 20 seconds
<ogra_> it is monday though
<Laney> s/-x/-c/
<Laney> ogra_: you mean if I pour coffee through this here vent..?
<ogra_> yeah, definitely ... for me that always helps :)
<LocutusOfBorg> infinity, it fixes the issue, but not on s390x, and I don't have access to porterboxes on ubuntu
<infinity> LocutusOfBorg: That s/INCLUES/AM_CPPFLAGS/ change makes literally no difference, FWIW.
<LocutusOfBorg> true
<LocutusOfBorg> actually to check that change I had to autoreconf, and that was the fix :)
<Laney> pitti: uploaded smokekde - that should be it
<pitti> Laney: yay, thanks
<infinity> LocutusOfBorg: I don't see autoreconf having fixed anything either (except for it propagating the std=gnu99 from configure.ac, which you could have done manually by patching configure)
<infinity> LocutusOfBorg: Not that autoreconf is necessarily a bad idea anyway.
<infinity> LocutusOfBorg: Less sure of the continued s390x breakage.  That's weird.  I see 26 implicit declarations in that build log, most of which I wouldn't think should be.
<infinity> LocutusOfBorg: Oh.  Same on powerpc, though.  It just doesn't fail because we only fail pointer conversions on 64-bit.
<infinity> LocutusOfBorg: So, could be some endian oops somewhere.
<infinity> Or.  No.
 * infinity scratches his head.
<infinity> This source is a mess.
<LocutusOfBorg> powerpc is fine to me
<infinity> Actually, it's all busted on every arch still.
<infinity> LocutusOfBorg: Testing something here.
<LocutusOfBorg> thanks infinity :)
<juliank> I'm planning to release APT 1.2.7 today without SHA1 support. This might break some third-party repositories, for example, Google Chrome is definitely broken (only MD5Sum and SHA1 fields; also signed with a 1024 bit DSA key...). Can we agree on having that in xenial?
<juliank> I'm not sure how much this tightens up security with gpg still accepting SHA1-based signatures, but it still seems like a good idea to do it.
<zequence> pitti: Ok, we're dropping dvdstyler, and replacing it with devede
<rbasak> For mvo_ or someone from the security team perhaps? mdeslaur? ^^
<juliank> For Google, I have informed both the Chrome and Security teams about the issue with their repository
<mdeslaur> juliank: will it still work with 1024 bit keys?
<mdeslaur> juliank: or is it just md5/sha1?
<mdeslaur> (that is being dropped)
<cjwatson> juliank: Re bug 1556666, can I confirm that it is your belief that the digests on the primary Ubuntu archive are OK?  (I believe this to be the case, but it's worth checking in this context)
<ubottu> bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [Undecided,New] https://launchpad.net/bugs/1556666
<juliank> mdeslaur: GPG signatures are entirely unaffected. This affects only the fields within the Release/Packages/Sources files
<juliank> cjwatson: I believe so, yes
<cjwatson> Good.  It's probably just a matter of passing --digest-algo SHA512 then, as we do there
<juliank> mdeslaur: We can easily switch off SHA1 for GPG signatures in an SRU if a stronger threat exists.
<juliank> (That would also practically turn of DSA keys)
<cjwatson> Oh, except I bet we do this with gpgme, ugh
<cjwatson> hatred
<juliank> cjwatson: Just as a note, the PPAs also would not be affected by APT 1.2.7
<juliank> As that's the GPG signature, and we're not rejecting weak stuff there yet (GPG rejects md5 itself).
<cjwatson> juliank: That was my understanding from what you said, but thanks for confirming
<juliank> The point is: Disabling our side of the SHA1 support was a *small* bit of work, and it's safer to do that now than in the next 5 years.
<cjwatson> The main difficulty with this sort of thing around PPAs is upgrading keys (https://bugs.launchpad.net/launchpad/+bug/1331914 etc.), but I think we can upgrade the digests without having to get into that.
<ubottu> Launchpad bug 1331914 in Launchpad itself "Allow users to re-generate a PPA signing key" [High,Triaged]
<juliank> If a strong threat pops up, disabling SHA1 for our gpgv use would be just adding two lines in a config file.
<doko> Mirv, could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (libqt5xcbqpa5)?
<cjwatson> uh.  as far as I can tell, the only way to pass --digest-algo SHA512 through gpgme is to give it a wrapper gpg program
<cjwatson> I hate software
<juliank> cjwatson: Or create a gpg.conf with the option and set home_dir accordingly
<cjwatson> Yeah, also ridiculously cumbersome
<cjwatson> It really ought to have library-level control of this
<juliank> GPG is a total clusterfuck
<juliank> It should just default to sane values already
<juliank> and warn about SHA1 signatures
<juliank> cjwatson: Also: No idea whether the self-sigs of the keys use SHA1
<juliank> then again, nobody sees the UIDs anyway, so I don't think it's much of a problem.
<cjwatson> They probably do at the moment.  A fix in the proper place in lp.services.gpg.handler would take care of both.
<cjwatson> Oh look, we already use a custom gpg.conf
<smoser> pitti, ubuntu that commit is in trunk now (ubuntu in lxd group)
<smoser> will upload that today.
<smoser> rcj took care of that for us.  thanks!
<pitti> smoser: cool, thanks
<CustosL1men> does ubuntu have something like rhel scl ? https://www.softwarecollections.org/en/about/
<Mirv> doko: thanks for reminding about it, I will take care of those
<Mirv> I had a note about it but it got buried
<rbasak> CustosL1men: yes, see Ubuntu Snappy. But this is a conversation for #ubuntu really, not #ubuntu-devel.
<rbasak> smoser: I just imported open-iscsi into lpusdp for matsubara, but then realised that loses the broken down delta.
<rbasak> Do you want to replace it with a broken down delta if you have it?
<smb> lamont, Not sure how much time you had for looking into bind9. Not sure of how much help I could be but at least I'd try. I had a bit of looking into it this morning and it feels like reverting could rather be modifying the udeb build done now. Though the details feel erm complicated.
<lamont> smb: agreed
<lamont> I have much of it done, but need to smack the build around a bit to fix the current ftbfs
<lamont> and so, when lunch, or a test run comes, I'll have 40 min or so to fight with it
<lamont> the test run will come first, and fairly soon
<smoser> rbasak, i have my commits
<smoser> but not sure what i'm supposed to do with them.
<smb> lamont, ok, so I think the best was to help would be to take the resulting libs and try isc-dhcp builds and the resulting binaries.
<lamont> smb: I would love that
<smoser> rbasak, pushed my most recent workign delta to https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi
<rbasak> Looking
<lamont> Once I get it to build, I'll toss it at my ppa and let you know
<lamont> smb: ^^
<smoser> 'working' there is the working-2.0.873+git0.3b4b4500-13ubuntu1
<smb> lamont, Ok, cool. Thanks
<smoser> and working-<long> is 14ubuntu1
<Odd_Bloke> I'm talking to someone who wants to install from ISO and end up with the original trusty kernel; I've found http://old-releases.ubuntu.com/releases/14.04.0/, but I'm not wild about pointing them at something with old-releases in the URL.
<rbasak> smoser: first let's settle the debian/sid branch. I just pushed that to lpusdp with the full history, so let's just use that.
<Odd_Bloke> Is there another option?  (We support the 14.04.0 kernel until trusty EOL, right?)
<rbasak> smoser: otherwise you could have created it by using git-dsc-commit on top of the existing debian/sid branch, and then pushing that to lpusdp with the import/<version> tag.
<rbasak> smoser: next, can you rebase working-<long> on top of that new debian/sid branch that is now in lpusdp?
<rbasak> When done, you can tag that as upload/<version> to donate that that is the tree that you uploaded, and (force) push that as ubuntu/devel.
<rbasak> smoser: does that make sense? In lpusdp, debian/sid just gets imports added as commits to the end, each tagged as import/<version> and the branch just moves along.
<rbasak> smoser: and ubuntu/devel is always based on debian/sid + commits, either import/<version> or the uploaders commits with a final upload/<version>
<rbasak> smoser: ubuntu/devel currently gets force pushed after an Ubuntu "merge". cjwatson convinced me to do something a little different there but we've not implemented that yet.
<pitti> mvo_: please rename the "snap" binary in the test too: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snap
<pitti> yofel: a lot of KDE updates landed now, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kopete is one of the few remaining actual issues
<pitti> and kwin
<smoser> Odd_Bloke, i dont know that there is a answer to your question.
<smoser> other than old-releases. :-(
<Odd_Bloke> It does mean that I can make the "really really make sure you're upgrading" point more forcefully, at least. :p
<yofel> pitti: thanks!
<xnox> Odd_Bloke, use d-i installer, it offers a choice of kernels to install, but you need .0 d-i image for trusty original kernel.
<xnox> Odd_Bloke, also at cdimage we have original stack images files.
<yofel> Mirv: were there any qtopengl dep changes that would cause https://launchpad.net/ubuntu/+source/kalgebra/4:15.12.1-0ubuntu2/+build/9344094 ? (No-change rebuild that previously built fine)
<yofel> or do I need to look somewhere else?
<xnox> Odd_Bloke, i believe ...1 release are also still on original stacks (.2 is the first one to get later stack)
<smoser> xnox, i dont think it offers a selection of kernel
<xnox> Odd_Bloke, http://cdimage.ubuntu.com/ubuntu/releases/ there is
<xnox> 14.04.1, 14.04.2, 14.04.3, 14.04.4 -> original, +1, +2, +3 stacks.
<xnox> smoser, it does, at lower debconf priority.
<Odd_Bloke> xnox: If you follow the cdimage links through, you can't get the .{1,2} images; you still end up with only .3 and .4 files listed.
<xnox> http://cdimage.ubuntu.com/ubuntu/releases/14.04.1/release/ is supposed to be .1 images archive.
<xnox> if not, it's a bug.
<Odd_Bloke> xnox: Cool, I think it's a bug then; where shall I file it?
<xnox> indeed it is.
<xnox> Odd_Bloke, ubuntu-cdimage project, assign to infinity.
<Odd_Bloke> xnox: Cool, thanks.
<xnox> Odd_Bloke, however, they may have been moved intentionally due to disk space constraints.
<xnox> Odd_Bloke, i do see .0, .1, .2 at http://old-releases.ubuntu.com/releases/14.04.1/
<Odd_Bloke> Yeah, that's what I was going to use; just didn't like it being at "old-releases" (which suggests "may disappear at any time without notice" to me :p).
<xnox> Odd_Bloke, old-releases is long term for-ever archive of ubuntu. that one does not disapear ever.
<Odd_Bloke> OK, cool.
<xnox> it has Warty Warthog =)
<xnox> and e.g. the title page says it right:
<xnox> http://old-releases.ubuntu.com/releases/
<xnox> The following old releases of Ubuntu are available:
<xnox> <old stuff>
<xnox> The following releases are also available which have been superseded by later point releases (the current point release is available on releases.ubuntu.com as usual):
<xnox> Ubuntu 12.04.4 LTS (Precise Pangolin)
<Mirv> yofel: nothing I know of. no recent mesa uploads, the only qtbase change was enabling ALSA support (http://launchpadlibrarian.net/247469048/qtbase-opensource-src_5.5.1+dfsg-15ubuntu1_5.5.1+dfsg-16ubuntu1.diff.gz)
<xnox> Ubuntu 14.04.2 LTS (Trusty Tahr)
<yofel> Mirv: ok thanks, then maybe it's a build ordering issue on our side
<mvo_> pitwill do, sorry for the trouble
<pitti> mvo_: thanks
<pitti> mvo_: no trouble, just playing relay :)
<smoser> rbasak, ok. i think i'm good now.
<smoser>  http://paste.ubuntu.com/15384413/
<smoser> my local 'ubuntu/devel' branch is ahead of lpusdp/ubuntu/devel by my logical delta changes
<smoser> and upload/2.0.873+git0.3b4b4500-14ubuntu1 is tagged
<smoser> and upload/2.0.873+git0.3b4b4500-14ubuntu1 is tagged
<smoser> so i think i just need to git push --force lpusdp ubuntu/devel
<pitti> doko: argh, soooo close! http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-defaults
<smoser> rbasak, ^ please let me know if that isnt right.
<pitti> nacc: hmm, do you know why php 7 in xenial-proposed is in this big sorryness of uninstallability?
<nacc> pitti: yeah
<nacc> pitti: so the issue is we bumped php-defaults, but we need to dump php7.0 too ... but i spent last week just getting the split done. So I can post debdiffs for the newer merge
<nacc> s/dump/bump/
<nacc> pitti: as the new php-defaults requires a newere php7.0 than we have
<pitti> nacc: ah, so you're on it, thanks
<doko> pitti, but +100 ruby packages migrated
<pitti> doko: yeah, and poppler, most of kde and some others too
<pitti> doko: hopefully ruby-defaults in the next round, armhf queue is back at 0
<nacc> slangasek: my last two debdiffs for php-imagick & imagemagick should allow all the tests on i386 & s390x to pass (LP: #1549942)
<ubottu> Launchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/1549942
<pitti> doko: I stand corrected, it's miggrating right now
<pitti> nacc: yay, I'll look at/sponsor them, thanks
<pitti> nacc: I was just adding ignores for php-imagick, as slangasek already dropped them (I thought prematurely, but I guess not then)
<doko> nacc, pitti: is this the same issue? https://launchpadlibrarian.net/247846239/buildlog_ubuntu-xenial-amd64.ruby-riddle_1.5.12-3_BUILDING.txt.gz
<pitti> doko: very likely
<nacc> pitti: yeah, we had decided it was safe to ignore both (the upstream maintainer says that test is unreliable). But I think the proper fix to imagemagick is included now
<nacc> doko: yep
<nacc> ok, will get those debdiffs done ASAP
<pitti> nacc, slangasek: imagick and php-imagick sponsored, thanks!
<nacc> pitti: thanks, i'll keep an eye on the tests!
<doko> nacc, yare you working on the php7.0 merge, or do you need help?
<nacc> doko: i had two questions for you, actually, on merges the server team would like to get done: 1) is it worth merging ldb to 1.1.26? 2) I think we can sync pep8? I can file that bug, just wanted to check with you first. Debian has some more updated tests in 1.7.0-1, but otherwise the biggest diff is debian doesn't have build/lib/pep8.py ?
<nacc> doko: working on it now
<doko> nacc, ldb: have it on your radar; the python3 bindings patch is not yet merged
<doko> if it is, you can sync it. but maybe it's worth having the subminor version
<doko> now synced talloc and tdb
<doko> nacc, synced pep8 too
<nacc> doko: thanks!
<barry> doko: hahaha!  thanks for syncing pep8.  i was just working on a -2 and fixing up the repo. was gonna sync also, but will do that after i upload -2 to unstable
<barry> doko: flake8 is next on my list
<nacc> slangasek: sorry, didn't look at your diff until just now, but why did the stuff in debian/control move around? also, it doesn't match the changelog anymore, as -imap, -interbase, etc aren't in d/control?
<rbasak> smoser: what's the parent of c5109da36b887b39840ab5e60022a92b38c163ca?
<smoser> rbasak, http://paste.ubuntu.com/15384903/
<rbasak> smoser: yes that looks right. I would use git push --no-tags though, since otherwise you'll end up pushing your "working" tag etc.
<rbasak> You can push the import/upload tags explicitly.
<smoser> how do i do that ?
<rbasak> git remote add lpusdp lpusdp:open-scsi; git push lpusdp --no-tags +ubuntu/devel upload/2.0.873+git0.3b4b4500-14ubuntu1
<pitti> nacc: ah, I figure php-imagick needs to wait for that php7.0 merge too? (FTBFS  due to uninstallability as well)
<nacc> pitti: yep
<nacc> pitti: pretty much all of php will :/
<smoser> rbasak, done. thanks.
<rbasak> smoser: thanks!
<rbasak> matsubara: ^^
<matsubara> thanks rbasak and smoser!
<stgraber> pitti: not sure if smoser replied, but I think the plan was to have cloud-init add the user to the lxd group when it makes sense (when the user is an admin or whatever similar logic exists in there)
<pitti> stgraber: heh did; he said the fix is in git now, and will be uploaded soon; thanks
<smoser> stgraber, i just uploaded earlier.
<pitti> cheers
<stgraber> pitti: and yeah, we haven't built ppc64el images in quite a while so I cleaned up all the seriously oudated, full of security issues images on Friday
<smoser> pitti, ^ . its in -proposed now.
<smoser> b asically the default user is in 'lxd'
<smoser> so lxd group gets added for him if nto there.
<stgraber> pitti: we have new ppc64el, powerpc and s390x VMs that we can use now, I just need to set them up to talk to our Jenkins
<pitti> stgraber: ah, nice! apw complained about the regressing tests again, as on ppc64el there are no images any more (for any release)
<pitti> stgraber: awesome, s390x too
<stgraber> pitti: yeah, I just noticed. I'll try to setup those jenkins runners today. In theory we can also build Debian images on those 3 arches then which may be useful to some
<apw> stgraber, yeah we seem to have regressed in terms of images for all series there ... i filed you a shiney bug against lxc
<apw> stgraber, though we have assumed it is a lack of images not functional regressions
<stgraber> apw: yeah, so long as the only errors you're getting is "no image found", that's all fine
<stgraber> I should really make our image publisher wipe images that are outdated rather than do it manually every so often, I really didn't like seeing images that still contained vulnerable libssl :)
<apw> no image found indeed
<pitti> stgraber: would it make sense to treat "no image found" as "skip"?
<stgraber> pitti: yeah, that would make sense
<balloons> mpt, ping
<nacc> slangasek: so i think what happened is that you ended up editing the d/control files for both src:php7.0 and src:php-universe-source7.0 to not include binary targets that aren't built for those packages. Do you want to keep that delta? I will document it in the new merge, if so
<Logan> Laney: wanted to apologize for uploading this: https://launchpad.net/ubuntu/+source/banshee/2.9.0+really2.6.2-3ubuntu2 - didn't realize until after the fact that you were working on a fix in Debian's VCS in an Ubuntu branch
<Logan> Laney: I usually just assume that the VCS in debian/control is just for Debian :/
<Laney> Logan: no worries, but it would be good if you could pick up those fixes
<Laney> thanks for fixing it!
<sladen> anyone know what the heck these  'PlusServer GmbH' empty mailings are
<sladen> being sent to ubuntu-security-announce@lists.ubuntu.com
<sladen> sbeattie: are they generated bounces/misconfiguration in response to your mailings?
<sbeattie> sladen: yes, I accidentally moderated them through. Sorry for the noise.
<ogra_> just charge them for the free ads they got ;)
<sbeattie> heh, well, maybe having them spammed everywhere will get them to stop it.
<sbeattie> (we get them for every single USN we publish)
<ginggs> Anyone from ubuntu-release please look at LP: #1555586 ?
<ubottu> Launchpad bug 1555586 in lazarus (Ubuntu) "FFe: Sync lazarus 1.6+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1555586
<doko> nacc, do you have updated packages, or do you want to wait for slangasek to sponsor these?
<Chipaca> popey: wrt the kswap thing (on twitter :) ) does anything show up in iotop?
<nacc> doko: i'm just building & testing them now
<nacc> doko: sorry, had to make sure i understood slangasek's changes
<nacc> doko: and we had introdcued a bug i was hoping to fix easily (testing that too)
<juliank> cjwatson: mdeslaur: WRT APT, 1024 bit keys and SHA1 for GPG signatures: I landed a patch in APT git that allows us to reject signatures in APT made with specific algorithms. I plan to turn that on in Summer, so it's part of the 16.10 release, and then would want a xenial SRU in January 2017 to turn that off for Xenial as well (changing two lines: incrementing array length + uncommenting new array member) - this hopefully gives the third
<juliank> party repositories enough time to catch up.
<juliank> (At least Spotify and Google repos are affected by this)
<nacc> doko: i *think*, in the interest of getting these issues fixed, you or anyone cna sponsor them, the functional differnce is nil from what we had before (the main/universe split), it's just a normal merge. And our delta is pretty well contained at this point
<nacc> doko: but i'd like to run the autopkgtests against php7.0 here just to be sure, so it'll take another 15-20 minutes, I think
<juliank> Basically scheduling the SRU around a 16.04.2 release
<juliank> best reasonably-possible security for everyone!
<juliank> (I'd like to reject weak key lengths too, but key length is not exposed by gpg)
<mdeslaur> juliank: sounds good
<popey> Chipaca: ended up having to reboot, was completely unusable
<popey> Chipaca: seems a known issue, if you have no swap defined, and do something which fills the cache (dding a 16GB IMG to SD card) it will spin kswapd forever
<mterry> cjwatson: I'm experiencing a problem with a silo ppa, where we accidentally built a package with a version number that was too high.  We (tried to?) deleted it from the ppa and rebuilt.  But now the upload of built packages fails because it still sees the old packages (but only for i386 and amd64, not for armhf).  Do you know what might be going on?
<mterry> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/9349898 for example
<nacc> slangasek: doko: for a package that's only in ubuntu (php-universe-source), but which is essential a fork for php7.0 ... should i provide the .dsc, debian.tar.gz and orig.tar.xz files for sponsorship? or shoudl i provide a debdiff between the ubuntu versions (and a note indicating the orig.tar.gz is the same as for src:php7.0, but renamed)?
<doko> nacc, I'd say yes, maybe omitting the .orig.tar if it's exactly the very same file
<nacc> doko: yeah, it's identical, we do all the manipulation in the rules and with control file changes
<nacc> doko: thanks! i'll provide that all shortly, are you ok if just subscribe you the bug once it's ready?
<nacc> doko: LP: #1553419
<ubottu> Launchpad bug 1553419 in php7.0 (Ubuntu) "php7.0: update to latest version of packages from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1553419
<Pharaoh_Atem> doko: ?
<slangasek> nacc: I didn't get a chance to answer your question the other day before you dropped off IRC... you're talking about pulling a new upstream version of php7 now, are there changes that constitute new features and should go through the FFe process?
<slangasek> nacc: and we're talking about pulling a new upstream version, when the actual bug we care about fixing is a packaging incompatibility issue - seems risky to me
<nacc> slangasek: afaict, 7.0.3 -> 7.0.4 is all bugfixes
<nacc> slangasek: looking at their changelog, that is
<slangasek> nacc: so you don't see any risk in pulling forward to that latest version from unstable, as opposed to just pulling the last Debian packaging for 7.0.3?
<slangasek> I ask because it was a sync from Debian that gave us the current set of Breaks: issues :)
<nacc> slangasek: that's a fair question; before i answer, can i ask something? if we stay on 7.0.3-13, will we, in the future, have to backport bugfixes to 7.0.3-13? Or will we at some point in the future merge to 7.0.4 from debian (or whatever is current)?
<slangasek> nacc: if "Some point in the future" means "next release cycle"...
<slangasek> nacc: if you think 7.0.4 is the target for 16.04, let's do that now
<nacc> slangasek: well, that's what i'm, maybe, struggling to understand ... if we take 7.0.3, let's say, 7.0.3-13 (which i think will be the last debian release of 7.0.3), does that mean we'll just be backporting to 7.0.3-13 for the next 5-ish years?
<slangasek> nacc: "backporting" what?
<nacc> slangasek: bugfixes, future bugfixes, etc
<slangasek> we wouldn't make packaging changes to php7.0 in 16.04 post-release
<nacc> slangasek: so, presuming that php7.0 upstream continues to fix bugs, would we proactively be backporting those bugfixes to our level? or will we rely on users reporting issues and selectively backporting the fixes?
<nacc> slangasek: this is maybe my general ignorance on ubuntu maintainership/policies/etc
<slangasek> nacc: I'd say that's a prioritization question you should discuss with jgrimm-afk :)
<nacc> slangasek: :)
<nacc> slangasek: ok, i can easily rebase my chagnes to 7.0.3-13 instead, that's trivial for me to do & test
<nacc> Pharaoh_Atem: do you have an opinion here?
<slangasek> nacc: a look at the versions of php5 in the various LTS pockets may offer some historical insight - there are no new upstream versions in -security or -updates, but 21 SRUs to precise since release and 14 SRUs to trusty since release
<Pharaoh_Atem> nacc: I'm in favor of pushing to new minor releases in 7.0.x
<Pharaoh_Atem> I'd prefer to keep the backport delta as low as possible until the release
<Pharaoh_Atem> at which point, the version freeze can kick in and we can do backports on an as-needed basis
<slangasek> nacc: so I would use that as the guide for now, and assume we are not going to take newer upstream point releases post-release
<Pharaoh_Atem> one of the things that the php community has gotten better at with php7 is ensuring that bugfix releases are really only bugfix releases
<slangasek> that would be grounds for a conversation about php getting a micro release exception for SRUs; but that should definitely be sorted out later and not block the current updating
<nacc> slangasek: yep, understood -- i think in this particular care, it does seem like 7.0.4 has some pretty large bugfixes (segfaults, crashes, overflows) based upon the upstream chagnelog. I think it is worth us moving to that version now, to minimize the need to backport (already) 10-15 fixes
<nacc> s/care/case/
<slangasek> nacc: copy. I can have a look at this today then
<nacc> slangasek: and i will look into the micro release exception, as well as be more cautious in teh future about our versioning and stability
<nacc> slangasek: thank you very much! it should allow a lot of excuses to clear out again, as php-defaults is currently broken
<slangasek> nacc: btw regarding the debian/control delta - yes, I ran the debian/rules debian/control target against both source packages, which I think is the correct thing to do.  That target certainly existed before we split the source, and I assume it should always be run before generating the source package
<slangasek> if that resulted in deltas vs Debian, umm <shrug>
<nacc> slangasek: yeah, it ended up just moving a bunch of stuff around
<nacc> and i was told to minimize our delta :)
<nacc> slangasek: but i will look at that too
<nacc> slangasek: coudl be that whatever level we were on hadn't run it recently
<nacc> so it was out of date
<slangasek> right, so if it moved stuff around that either implies the Debian debian/control was not up to date, or the target is not reproducible
<slangasek> for merging, I would suggest ignoring debian/control diffs / conflicts and just regenerating that file after merging up debian/control.in
<nacc> slangasek: ah, i think the debian/control is not uptodate
<nacc> slangasek: wrt. debian/control.in & debian/rules
 * slangasek nods
<nacc> slangasek: want me to update the debdiffs? i'd like to document that in the changelog too, just so it's clear to me in the future :)
<slangasek> nacc: yes, feel free to update the debdiffs now, it'll be about an hour before I'm pulling
<nacc> slangasek: ok, will do that now, thanks!
<doko> tumbleweed, https://launchpad.net/ubuntu/+source/pyzmq/15.1.0-1ubuntu1 any idea? you don't see that in unstable because of #818187
<tumbleweed> doko: urgh
<tumbleweed> I didn't know what was wrong the last time around, with pyzmq
<tumbleweed> thankfully the latest upstream fixed it, at the time
<Pharaoh_Atem> nacc: I think we'll likely use 7.0.5 as the final release before Ubuntu Xenial freeze
<doko> nacc, Pharaoh_Atem, slangasek: sorry, didn't see the discussion until now. had it already uploaded
<nacc> doko: slangasek: i can provide 7.0.4-5ubuntu1->ubuntu2 debdiff if you'd like that will clean up the changelog and include the stuff discussed above?
<nacc> doko: also, i do see the uploads in excuses, but it seems to be unhappy that we skipped 7.0.3-9ubuntu2?
<doko> <fk for today
<infinity> nacc: That'll clear up once britney sees the new binaries.
<nacc> infinity: ah ok, thanks!
<nacc> slangasek: let me know how you want to proceed ... i have my cleaned up tree locally; i expect it to just be d/control & d/changelog changes
<nacc> infinity: does someone have to go in and manually delete "old binaries"? (e.g., php 7.0.3-9ubuntu2 binaries on armhf)
<infinity> nacc: No.
<infinity> nacc: That just means the armhf build wasn't done/published yet when britney ran.
<nacc> infinity: oh i see
<nacc> infinity: thanks!
<nacc> infinity: one last question, sorry, now that php7.0 is updated, will all the autopkgtest regressions from the php-defaults issue (which is now fixed, it was an unsatisfiable dependency) be automatically resubmitted?
<infinity> nacc: No idea.  Depends on what depends on what and ends up triggering things as a result.
<nacc> infinity: ok, i'll try and follow the depends, thanks!
<doko> nacc, https://launchpadlibrarian.net/248138216/buildlog_ubuntu-xenial-amd64.remctl_3.10-1build2_BUILDING.txt.gz
<nacc> doko: hrm, probably needs updating to be php7.0 compatible, let me look
<nacc> doko: yeah, it's on my list of automatically updateable ones (basically needs to be sed'd). Want me to provide a debdiff?
<doko> please do
<slangasek> nacc: I'll take a debdiff for debian/control + debian/changelog, sure
<nacc> slangasek: ok, i'll try and get that going once i've figured out remctl
<nacc> doko: i *think* remctl might not be php7 compatible ... meaning we'd need to disable the php bindings
<nacc> let me look upsream
<nacc> doko: yeah, it's not. I can take a swing at updating it, but those are lower on my priority list to look at. Do you want a debdiff that just disables php5-remctl for now?
<nacc> slangasek: can you do that sync of php-xdebug? php-common has a breaks on it
<nacc> slangasek: that'll fix the php-imagick and phpunit, afaict
<slangasek> nacc: yes, I saw that was still pending and will get to it in about an hour.  It's a sync that overwrites an Ubuntu delta for your upstream cherry-pick, that's something that's included in the 2.4.0 release?
<nacc> slangasek: yep
<nacc> slangasek: i put that in the description of LP: #1553419
<ubottu> Launchpad bug 1553419 in php7.0 (Ubuntu) "php7.0: update to latest version of packages from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1553419
<nacc> slangasek: i should have made that clearer, sorry
<nacc> slangasek: we could hav sync'd sooner, actually, i was just waiting for the final release, as upstream told me they weren't going to do another RC
<slangasek> nacc: oh then maybe I'll just hit the button now
<slangasek> nacc: synced.  but the bug won't autoclose, because the bug task was on php-xdebug but the current source package name is xdebug
<nacc> slangasek: np, i can close the task
<nacc> slangasek: i think i confused myself on that
<metaf5_> What are the practical differences between Xenial Beta and Daily?  I'm looking to update an application that is distributed as a modified Ubuntu install CD, and wondering where to start.
<nacc> metaf5_: i'm not sure what you mean? it seems like Beta is a snapshot at a specific point in time, while Daily is ... well, daily?
<slangasek> well, one difference is that we have not released a beta of Ubuntu yet for Xenial; that's only available for community flavors
<metaf5_> Oh, I was looking at Ubuntu-Gnome, my bad.  I think I probably want the daily then.  Thanks!
<nacc> doko: ok, i think i got a build working, let me see how the tests go :)
<nacc> slangasek: will the php-imagick build that failed earlier (https://launchpad.net/ubuntu/+source/php-imagick/3.4.0~rc6-1ubuntu3) automatically kick off again now that php-defaults has been fixed?
<slangasek> nacc: no, but I can kick it now
<nacc> slangasek: thanks, i wasn't sure about that one as it never made it into proposed
<slangasek> if launchpad detects that a failure is because of a missing build-dependency, it'll put it into "dep-wait" state and automatically retry it.  otherwise, needs a manual poke
<nacc> doko: i'm trying to figure out how to run the tests :) i don't think we really run them normally, but there is a php testsuite
<nacc> slangasek: right, i remember that from before, figured this might be a different case
<nacc> doko: hrm, i'd need to actually ocnfigure kerberos to test it :)
<nacc> doko: so i can provide you my patch, which does let it build, or i can work with upstream to see if they can test?
<nacc> doko: and in the meanwhile, disable php5-remctl
<nacc> doko: I just sent the upstream/debian maintainer a note with my patch
<ari-tczew> flexiondotorg: ping
<flexiondotorg> ari-tczew, Yo
<ari-tczew> flexiondotorg: about bug 1556506, does mate-menu 5.6.9 contain any new features?
<ubottu> bug 1556506 in mate-menu (Ubuntu) "Sync mate-menu 5.6.9-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1556506
<flexiondotorg> ari-tczew, Just fixes and translations.
<cjwatson> mterry: I think your deletion raced with builds that were in progress.  Repeat the deletion using "remove-package -A ppa:ci-train-ppa-service/ubuntu/landing-041 -s vivid -m 'wrong version' -e 8.13+15.04.20160314.3-0ubuntu1 unity8", wait for it to vanish from http://ppa.launchpad.net/ci-train-ppa-service/landing-041/ubuntu/dists/vivid/main/binary-i386/Packages.gz, then retry the builds
<ari-tczew> flexiondotorg: ok, I'll process it for you.
<flexiondotorg> ari-tczew, Perfect. Thank you very much!
<mterry> cjwatson: heyo!  OK will try, thanks
<ari-tczew> flexiondotorg: did you already consider to get PPU for any mate related package?
<flexiondotorg> ari-tczew, If you're able a have a few others too ;-)
<nacc> is there a standard place for me to see if a build is in dep-wait?
<flexiondotorg> ari-tczew, I have applied but the DMB didn't meet last time and are now in limbo :-(
<ari-tczew> flexiondotorg: ah, right, I see your application now
<ari-tczew> DMB is broken this time :P
<flexiondotorg> ari-tczew, I saw.
<cjwatson> nacc: The +build page will say "Dependency wait" if it is.
<cjwatson> And it will name the unsatisfied dependency.
<flexiondotorg> ari-tczew, This is another fixes only sync request - https://bugs.launchpad.net/ubuntu/+source/mate-dock-applet/+bug/1557207
<ubottu> Launchpad bug 1557207 in mate-dock-applet (Ubuntu) "Sync mate-dock-applet 0.69-1 (universe) from Debian unstable (main)" [Undecided,New]
<nacc> cjwatson: ah!
<flexiondotorg> ari-tczew, And another - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1556711
<ubottu> Launchpad bug 1556711 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 16.04.4 release [debdiff attached]" [Low,New]
<ari-tczew> flexiondotorg: how do you fill sync requests on LP?
<ari-tczew> manually?
<flexiondotorg> I use requestsync
<ari-tczew> flexiondotorg: hmmm... I asked due to missing importance on your bugs
<ari-tczew> normally should be set to Wishlist
<flexiondotorg> OK, I can make sure that happens in the fture.
<flexiondotorg> First time I've been told, but I can do that.
<flexiondotorg> Are sync requests that fixes bugs Wishlist?
<ari-tczew> flexiondotorg: it's not a key requirement or something. just requestsync should do this automatically, so I thought you just fill syncs requests on LP manually
<flexiondotorg> ari-tczew, This is how I do it - requestsync -d unstable -s mate-menu
#ubuntu-devel 2016-03-15
<ari-tczew> flexiondotorg: hmmm, maybe I'm wrong... nevermind. sorry for offtopic.
<flexiondotorg> np
<nacc> slangasek: so i think, unfortunately,we might also need to sync php-memcached for it to be installable. Woudl it make more sense for us to remove php-defualts from proposed?
<slangasek> nacc: didn't we need some fixes from that version of php-defaults?
<slangasek> I thought there were changes we cared about; and having reviewed the diff before syncing it, I certainly got the impression that upgrading to 35 now would save us pain later in terms of upgrade paths
<ari-tczew> flexiondotorg: done. the fresh plank release uploaded, as well.
<flexiondotorg> ari-tczew, Fantastic! Many thanks for your help :-)
<ari-tczew> flexiondotorg: You're welcome. Thanks for contributing.
<nacc> slangasek: it will, you're right, let me look at what is causing hte version to change on php-memcache & others
<nacc> slangasek: but it's going to break a bunch of versioned deps (php-imagick, php-memache, php-memcached, etc)
<cjwatson> slangasek: oh hai, I need an adult^W^Wa techboard member
<slangasek> cjwatson: I may be one of those today
<cjwatson> slangasek: we've fixed the apt bug that meant xz was broken on ftpmaster.  could you please "lp-shell production devel" and then https://paste.ubuntu.com/15388428/ to add xz support?
<slangasek> cjwatson: done
<cjwatson> slangasek: Great, thanks.  I'll watch the next publisher run to make sure it works this time.
<slangasek> nacc: php-memcache> syncing; this could also be handled by adjusting the Breaks: version from php-defaults, but the php-memcache sync is safe and takes an item off the todo list for later
<slangasek> nacc: you also opened a task against php-memcached, but I don't see any details about it in the bug
<infinity> cjwatson: I assume we plan to kill bzip2 with fire before release?
<infinity> cjwatson: (if the xz bugs shake out)
<infinity> cjwatson: s/I assume we plan to/Oh god, please let's/
<slangasek> nacc: nah, nevermind, found the breaks: for php-memcached
<cjwatson> infinity: Yes, certainly.
<cjwatson> infinity: Where "before release" probably = "later this week".  No obvious reason to keep it around as long as xz works and updates are working for people.
<cjwatson> infinity: But I want to check that assumption first ...
<nacc> slangasek: yeah, sorry, i created the task, and then saw how many i might need to file
<nacc> so was checking them all out before going further
<nacc> slangasek: so i think what's happening is that php-defaults-35 is going to require having roughly the same snapshot of the php7.0 packages as ondrej did when he made it
<nacc> slangasek: i'm still checking
<slangasek> nacc: ah. ok, I've uploaded a 35ubuntu1 with the php-memcached I knew about, and if you want to give me a debdiff of other version changes for php-defaults I'm happy to upload that
<slangasek> nacc: meanwhile, I am resubmitting several of the failed autopkgtests just to confirm that they're fixed with the new xdebug
<mwhudson> there is a DMB again! as of today
<mwhudson> oops, was scrolled back
<mwhudson> i love it when i look into ftbfs's and find upstream bugs that i filed 9 months ago https://github.com/matttproud/golang_protobuf_extensions/issues/9
<nacc> slangasek: ok, yeah, it looks like there's several, let me do that real quick
<nacc> slangasek: i'll check with ondrej on if they are real breaks or not -- as the debian git tree doens't have that version, even though it's in unstable
<nacc> slangasek: i *think* he's done it this way, because those are the version in debian that have been rebuilt for php7 w/ dh_php
<nacc> slangasek: but we get that from our rebuilds too
<nacc> slangasek: debdiff posted, your ubuntu1 hadn't hit the repo yet, so it's my own, but i think you can make the change up for ubuntu2 easily enough
<nacc> slangasek: i'll probably be afk for a while now, but will do my best to check proposed/excuses again before bed
<cjwatson> xz files are there for xenial now and the publisher seems happy.
<stgraber> pitti: we now have image and CI runners for powerpc, ppc64el and s390x online in the upstream jenkins. The first round of powerpc, ppc64el and s390x images for Ubuntu are building now so you'll be able to use them with adt when you wake up.
<Bluefoxicy> this is hilarious.
<Bluefoxicy> trying to print a PDF from chrome and it breaks cups (have to remove /var/spool/cups and restart)
<Bluefoxicy> tried printing it from evince and teh printer spit out "PCL XL error subsystem: Kernel error:  IllegalTag"
<Bluefoxicy> tried printing it to another PDF or a PS file, no luck
<Bluefoxicy> CRASHED EVINCE trying to print the resulting .ps file
<Bluefoxicy> http://www.zeroglide.com/electric-guitars/ printing the sizing chart, if anyone wants to try breaking 15.10 or 16.04
<TJ-> Bluefoxicy: printing fine here; must be your printer drivers
<Bluefoxicy> k
<Bluefoxicy> fortunately 16.04 will be ready soon.
<slangasek> nacc: php-defaults ubuntu2 uploaded.  fwiw as far as "hasn't hit the archive" is concerned, there's pull-lp-source for that
<nacc> slangasek: hrm, at the time, p-l-s didn't find it either, sorry!
<cpaelzer> good morning
<pitti> stgraber: you rock, thanks!
 * pitti re-runs the lxc/ppc64el/xenial test for linux-meta
<pitti> apw: ^
<pitti> nacc, slangasek: I mass-retried php-defaults tests last night, now that looks muuuuch better :)
<hallyn> hi, q regarding FFE, if a package introduces one new symbol to .symbols:
<hallyn> + usbredirhost_set_buffered_output_size_cb@Base 0.7.1
<hallyn> does that qualify as 'new api' ?
<pitti> hallyn: formally yes, but if it's just that it's still fairly harmless
<hallyn> (this is for nacc's usbredir sync request :)
<pitti> hallyn: it's more about "what impact and potential regression does that new version have"
<pitti> stgraber, apw: very good, http://autopkgtest.ubuntu.com/packages/l/lxc/xenial/ppc64el/ is green again
<hallyn> pitti: ok....  https://wiki.ubuntu.com/FeatureFreeze suggests some leeway also in decidding waht is an 'api break'
<hallyn> so i guess i'll sync.
<pitti> hallyn: that's not an ABI break, just new ABI
<pitti> hallyn: ABI  break would be a soname change, i. e. changing or removing existing ABI
<hallyn> ok
<pitti> hallyn: so that reverse dependencies must be ported
<hallyn> right
<pitti> merely adding a new function doesn't break existing users
<hallyn> right, i'm just trying to parse the ffe page :0
<pitti> hallyn: thanks for being thorough!
<hallyn> maybe best to test in a vm
<pitti> apw: I was about to restart lxc for other triggers too, but it's not marked as regression on http://people.canonical.com/~kernel/status/adt-matrix/ ?
<dholbach> good morning
<pitti> slangasek, nacc: so I think the only regression that's left is php-sabre-http-3, I'll deal with/retry/hint the other spurious ones
<doko> sil2100, fyi: https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.3+16.04.20160209-0ubuntu2
<doko> pitti, demoted tcl8.5 and tk8.5. there still seem to be references in main
<sil2100> doko: thanks
<doko> sil2100, it might be good to update zmqpp as well (now at version 4.1.2)
<pitti> doko: nothing on c-m about them yet?
<doko> not yet
<doko> pitti, could you merge again puppet? but it's universe ...
<pitti> doko: sure, merging
<doko> fyi, I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818259 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818261
<ubottu> Debian bug 818259 in src:ruby-fog-atmos "git usage in gemspec" [Serious,Open]
<ubottu> Debian bug 818261 in src:ruby-github-markdown "git usage in gemspec" [Serious,Open]
<doko> resulting in packages without a gemspec. maybe worth failing the build for those
<apw> pitti, right it has been hinted skip to allow me to release the kernels with that regression
<apw> pitti, would you like me to top the hints so the red comes back ?
<pitti> apw: I think we do want ppc64el to succeed again from now on, yes
<apw> pitti, its only for those kernel versions, not in perpetuity
<apw> pitti, but let me rip them then the retry commands will come out
<pitti> xnox, wgrant: just out of interest, where is "scalingstack support for s390x images" on a scale from "bwahahahaLOLgoodone" to "sure, will work next week"?
<wgrant> pitti: scalingstack bos02 will happen at some point Soonâ¢, and is likely to be xenial/mitaka, so we should have software support for s390x in the next scalingstack.
<wgrant> Then it's a simple matter (famous last words) of turning the buildd LPARs into Ubuntu KVM hosts.
<wgrant> Since AIUI xnox has made OpenStack work.
<pitti> wgrant: I was just about to ask, the LPAR stuff to create zVMs seems radically differerent from invoking QEMU, so teaching all that to a nova compute node seems no small task
<wgrant> pitti: That's a) OpenStack's problem and b) not a problem, since we'll run normal KVM instances on an Ubuntu LPAR.
<wgrant> It'll look very similar to POWER in that respect.
<pitti> ah, so it's qemu *within* LPAR, not LPAR *being* an openstack instance
<wgrant> Right.
<wgrant> I don't know if OpenStack LPAR support is a thing.
<wgrant> Not at the moment, at least.
<wgrant> OpenStack on z is exclusively various KVM distributions, I believe.
<pitti> wgrant: thanks for the heads-up
<wgrant> pitti: So from your perspective it should just be like normal, except with bootloaders that are less amusingly broken.
<pitti> doko: oh, universe now, so we can drop some delta
<wgrant> pitti: There are a few autopkgtests that have been running for more than 45 minutes, stuck on creating nova instances. Is that likely to be scalingstack flakiness?
<wgrant> lcy01's not working at all for LP atm, so I guess autopkgtest might be similar.
<pitti> wgrant: yeah, I also got a few timeout emails from died workers; looking in a bit
<pitti> doko: puppet uploaded, debdiff sent to debian, tests succeed locally
<pitti> wgrant: my lcy01 also has tons of "ERROR" instances indeed
<pitti> and several instances are  hanging in"BUILD"
<doko> xnox, gunradio tests hang on s390x. do you care, or should I disable these?
<pitti> wgrant: lgw and bos look okay to me
<wgrant> pitti: Yeah, it's just lcy01 as usual.
 * wgrant requests stabbery.
<pitti> nacc: seems php-imagick is still unhappy on the 32 bit arches (i386 and armhf); should I ignore these or do you want to look?
<wgrant> pitti: lcy01 is fixed.
<pitti> wgrant: cool, thanks
<doko> tumbleweed, https://launchpad.net/ubuntu/+source/pyzmq/15.2.0-0ubuntu1 updated, but now seems to fail everywhere
<doko> however a local amd64 build and test did succeed
<doko> pitti, for some reason tk8.5-dev was seeded. now removed
<pitti> stgraber: I uploded lxd for the wrong pyflakes test dep (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20160315_001840@/log.gz)
<pitti> zequence: many thanks for sorting out dvdstyler â devede; removed dvdstyler and wxsvg now
<slangasek> nacc: I see php-imagick autopkgtest is still failing on armhf with the strange timeout
<juliank> mdeslaur: cjwatson: WRT SHA1 hashes, I just invented a way for apt methods to print a warning in that case, so we are going to warn about them.
<cjwatson> juliank: Thanks; I imagine that will make the transition a bit softer.
<juliank> cjwatson: Yeah, I think so. Example:
<juliank> W: gpgv:/var/lib/apt/lists/repository.spotify.com_dists_stable_InRelease: The repository is insufficiently signed by BBEBDCB318AD50EC6865090613B00F1FD2C19886 (weak digest)
<juliank> cjwatson: Theoretically we need a freeze exception for the new string we add; but in practice language pack support is broken anyway AFAICT, so it's not going to help much...
<juliank> The first part may be translated though, but the "weak digest" part not
<juliank> reason being that users might want to forward this to their repository providers, and they need something they can understand
<juliank> German: Das Repository ist unzureichend signiert von BBEBDCB318AD50EC6865090613B00F1FD2C19886 (weak digest)
<juliank> Maybe I should add a reason: to the translate part
<slangasek> nacc: just reproduced the armhf test failure on porter-armhf.c.c.  The test is definitely buggy - at minimum the error message - because it didn't hit a timeout at all, it failed immediately
<slangasek> nacc: http://paste.ubuntu.com/15391035/
<slangasek> nacc: strace of a test run shows the timer is being delivered early by the kernel, but I have no idea why that would be.  I wouldn't think php is the only thing using setitimer() on armhf...
<mdeslaur> \pilot in
<mdeslaur> whoops
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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: mdeslaur
 * dholbach huds mdeslaur 
<smoser> is it intended that linux-image-generic-lts-vivid is in the wily archive ?
<smoser> (and -wily)
<pitti> smoser: it ought to be a trasnitional package to linux-image-generic (up until xenial)
<smoser> pitti, yeah, you're right
<smoser> Unpacking linux-image-generic-lts-wily (4.4.0.12.13) ...
<smoser> duh
<nacc> slangasek: ugh, we might also need to update php-defaults version check on php-redis
<nacc> doko: fyi, upstream remctl (debian/upstream) is going to try and integrate my patch with ifdefs. Let me know how you'd like to proceed
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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:
<stgraber> pitti: hmm, wll, that pyflakes dependency wasn't wrong until a day ago when barry synced the new pyflakes from Debian which splits pyflakes3 out of pyflakes...
<pitti> stgraber: right; sorry, that wasn't meant as a blame, just a FYI in case I made some packaging git out of date
<stgraber> not sure why that change was made without carrying a recommends or something for a while so that folks that were using pyflakes3 from pyflakes aren't left with it missing...
<pitti> stgraber: (it was blocking lxcfs)
<barry> stgraber: i think that's just a bug.  it should have included a recommends
<barry> i'll fix that when i get a chance
<stgraber> barry: thanks
<nacc> slangasek: just filed a bug to fix php-sabre* in proposed (LP: #1557599) and I think we should ignore failure on the php-imagick armhf one for now (same timeout as before)
<ubottu> Launchpad bug 1557599 in php-sabre-http (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,New] https://launchpad.net/bugs/1557599
<slangasek> nacc: agreed, overriding that hint since it's not a regression from what we've already let through; but based on what I'm seeing in debugging that test, it looks like there's a real problem with php-imagick on armhf, which warrants figuring out
<nacc> slangasek: yeah, I am happy to do look into it today. What's the best way for me to debug an armhf failure? This would be my first exposure to it.
<slangasek> nacc: did someone get you added to the 'porters' team, so you have access to porter-armhf.c.c?
<nacc> slangasek: probably not? :)
<barry> stgraber: ah, it was a Suggests.  bumping to Recommends
<mdeslaur> why is lynx-cur gone from the archive?
<nacc> mdeslaur: https://launchpad.net/ubuntu/+source/lynx-cur/+publishinghistory
<nacc> mdeslaur: "ROM; renamed to and replaced by lynx"
<mdeslaur> but lynx isn't there to replace it yet
<mdeslaur> grr
<mdeslaur> guess I just need to sync it
<mdeslaur> thanks nacc
 * mdeslaur looks in queue
<nacc> mdeslaur: oh i see what you're saying ... hrm, yeah, that seems like it's likely what is missed, but not sure
<cjwatson> pitti: Do you think you could teach ddeb-retriever about Packages.xz etc. in xenial (but not in older series)?  I'd like to be able to drop Packages.bz2 soon.
<nacc> hallyn: would you be able to review/sponsor LP: #1318317 for me?
<ubottu> Launchpad bug 1318317 in openipmi (Ubuntu) "openipmi startup script removes kernel modules" [High,In progress] https://launchpad.net/bugs/1318317
<nacc> hallyn: we'd like to merge (or consider for merging), but i'd like to get that fix in, so I can file the SRU
<pitti> cjwatson: yeah, that shouldn't be too hard; on a (virtual) sprint this week, but making a note
<hallyn> nacc: you're just talking about the short debdiff?  (not an upstream merge)
<hallyn> bug is kinda long - is the need to unload modules at all justified in any of the comments?
<nacc> hallyn: yeah, just the short debdiff, tested by the bug reporter @ IBM w/ 16.04
<nacc> hallyn: i looked for a while, and the ipmi.init script upstream hasn't been touched since ... 2010 :)
<infinity> doko: Is there any intent to drop openjdk6/openjdk7 before xenial release?
<infinity> doko: (Asking because we dropped tzdata-java in sid, and I can either reinstate it just for xenial, or you need to fix openjdk{6,7}
<infinity> tdaitx: ^
<nacc> hallyn: and it's not well documented. The unload has been present since 2005.
<hallyn> nacc: looks good, will push, thx
<nacc> hallyn: i did send an inquiry & the same patch upstream
<nacc> hallyn: thank you very much!
<hallyn> except your debdiff is out of date?  hm
<nacc> hallyn: i can refresh, let me check
<hallyn> :)  s'ok i'll do it
<nacc> hallyn: ah yes, looks like a minor release happened in-between, sorry!
<hallyn> nacc: apparently that one was just published today
<tdaitx> infinity: openjdk 6 will be dropped, not sure about 7 (but I believe we will keep it)
<nacc> hallyn: yep, i see it now; shouldn't conflict with my changes at all, afaict
<cjwatson> pitti: thanks
<Son_Goku> tdaitx: why keep around openjdk 7?
<Son_Goku> isnât it eol?
<tdaitx> Son_Goku: only Oracle Java 7 is EOL, OpenJDK 7 is still being supported
<infinity> tdaitx: Kay, if we're keeping 7, I'll reinstate tzdata-java for it.  Though, if you want to have a talk with Steve and Matthias and confirm that before I do, that would be nice. ;)
<tdaitx> infinity: sure, we need to check that with doko
<slangasek> tdaitx: if we will have openjdk-8 as the default, I see no reason we would keep -7 for 16.04
<slangasek> however, there's surely work yet to be done to get it removed
<slangasek> pitti, infinity, stgraber, mdeslaur, kees: tb meeting?
<slangasek> (or is my calendar wrong?)
<mdeslaur> no, it's right
<infinity> slangasek: Your calendar is right, my brain is wrong.
<infinity> slangasek: http://paste.ubuntu.com/15393373/ <-- That's the work needed.  If you can commit doko/tdaitx to that before release, yay, if not, I might just assume we're keeping it.
<infinity> stgraber: *poke*
<sil2100> seb128: hey! I was told you were looking into the issue of the ubuntu-system-settings translations being reverted - did you manage to find the cause?
<slangasek> infinity: right, so these packages are all stupid and buggy and hard-code a specific version of java instead of using the metapackages, check ;)
<seb128> sil2100, hey, sorry got busy on other things but now is actually an ok time to look at it, let me do that
<sil2100> seb128: since I wanted to look into it but didn't know if you didn't already :)
<infinity> slangasek: Or they use hardcoded paths to the jars and may actually be incompatible with new versions.
<infinity> slangasek: Likely a mix of both.
<slangasek> infinity: still stupid and buggy ;)
<seb128> sil2100, I've an idea where to poke, let me have a look
<sil2100> seb128: ok, thanks o/
<seb128> yw!
<infinity> slangasek: I feel that way about all things Java.
<pitti> slangasek: argh, sorry; forgot over the sprint
<slangasek> pitti: it's ok, we gave you all the action items
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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: seb128
<nacc> slangasek: sorry, made a dumb typo in php-sabre-http, follow-on debdiff posted in LP: #1557599
<ubottu> Launchpad bug 1557599 in php-sabre-http (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,Fix committed] https://launchpad.net/bugs/1557599
<nacc> slangasek: php-sabre-dav-2.1's failure might be real, i'm going to look at the older build samples
<Laney> doko: https://paste.ubuntu.com/15393693/
<slangasek> nacc: php-sabre-http reuploaded
<nacc> slangasek: thanks! and apologies
<slangasek> nacc: well I was the reviewer, clearly not doing my job either ;)
<slangasek> nacc: oh. also just noticed that the failing package in p-m is php-sabre-http-3, not the php-sabre-http we just uploaded
<nacc> slangasek: i'm thinking the sabre-dav is possibly an issue for php7 on s390 ... i'm tempted for us to turn on the tests during build
<slangasek> not sure why a separate php-sabre-http-3 is needed, it has no revdeps
<slangasek> rationale from changelog is   * Rename as php-sabre-http-3 so that php-sabre-dav-2.1 will be
<slangasek>     co-installable with more recent versions of php-sabre-dav.
<slangasek> but the php-sabre-dav-2.1 we have in the archive depends on php-sabre-http, not php-sabre-http-3
<slangasek> nacc: there's a newer php-sabre-dav-2.1 in unstable, looks like we need that and to apply test fixes for php-sabre-http-3
<nacc> slangasek: i'l investigate that nnow
<nacc> slangasek: ok, looks like php-sabre-dav-2.1 from debian has the same chagnes we do, but needs the d/test/control still, will send a debdiff for that, looking at the others now
<slangasek> nacc: was there still an outstanding debdiff for php-imagick? I see that the tests for -1ubuntu3 in -proposed are still failing on amd64/ppc64el, with the rounding problem
<nacc> slangasek: uhhh! That's super weird, they passed here! Let me reconfirm after i figure out this sabre stuff
<slangasek> ok
<seb128> pitti, you set https://bugs.launchpad.net/ubuntu/+source/php-doctrine-data-fixtures/+bug/1544318 to "fix commited" but didn't upload, was that an overlook?
<ubottu> Launchpad bug 1544318 in php-doctrine-data-fixtures (Ubuntu) "php-doctrine-data-fixtures: update to PHP7.0 dependencies" [Wishlist,Fix committed]
<pitti> seb128: hm, I don't remember that, probably pilot error
<seb128> pitti, k
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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:
<teward> seb128: ping, if you don't mind me picking your brain for a moment
<teward> (see PMs0
<coreycb> mterry, cinder appears to be stuck in proposed because of python-googleapi, but we've since abandoned that MIR and moved the dependency to Suggests in the control file.  have any tips on how to move that along?
<nacc> slangasek: ok, i think sabre fixes are done, and make sense. Might still trip the s390 failure, as it might be real, as mentioned
<nacc> slangasek: i'll look at php-imagick right after lunch, that result makes no sense to me
<mterry> coreycb: you mean migration-proposed says it's blocking on python-googleapi, but it shouldn't be?
<infinity> Odd_Bloke: When linux_4.4.0-14.30 migrates, your powerpc cloud images should be bootable.
<infinity> stgraber: ^
<infinity> cjwatson: ^
<Odd_Bloke> infinity: \o/
<infinity> Odd_Bloke: Really oddly subtle bug.  Thankfully, IBM had already fixed it in linux-next, so it just needed a cherrypick.  Finding it was less fun.
<coreycb> mterry, well I'm looking at update-excuses and component-mismatches
<mterry> coreycb: I'm not sure why that would happen, honestly
<coreycb> mterry, ok yeah it seems like it's gating on old status
<stgraber> infinity: yay, looking forward to finally having a kernel with proper seccomp support :)
<coreycb> infinity, would you happen to have any tips on how to move cinder along? (re: question above to mterry)
<infinity> coreycb: Yes.  Upload a fixed package.
<infinity> coreycb: Turns out that britney isn't smart enough to act on intentions, only actions. :)
<infinity> coreycb: (Hint, the package still depends on python-googleapi)
<infinity> coreycb: I assume being auto-filled by ${python:Depends}
<coreycb> infinity, ok that may be it, although I thought dh_python didn't guess deps anymore
<coreycb> infinity, I'll patch it out nonetheless and see how that goes
<infinity> coreycb: Also, is cinder/opts.py meant to work?
<infinity> coreycb: Cause without the dep, it sure won't.
<coreycb> infinity, it's an optional backup option
<coreycb> infinity, so we should be ok
<slangasek> nacc: some thinking-out-loud about php-sabre-dav-2.1 on the bug report now
<infinity> coreycb: Well, what I meant is that without the Suggest installed, opts.py won't work AT ALL.  Which seems subopt(hah!)imal.
<infinity> coreycb: You might want to make the google import and usage optional.
<coreycb> infinity, yeah I see your point, I'll see about opening a bug upstream about that
<slangasek> nacc: namely, php-mbstring *should* have been picked up from composer.json as a runtime dependency for the package, which would have let us sync from Debian.  But it's not, so there's a bug somewhere beneath pkg-php-tools
<coreycb> infinity, and fixing the package
<infinity> coreycb: If upstream wants to make the whole thing modular, all the better.  Google isn't special there, I assume.
<infinity> coreycb: Importing every possible binding for every possible backup backend seems mad anyway.
<coreycb> infinity, I agree, I need to dig into this file a bit more
<slangasek> nacc: same issue for php-sabre-http
<coreycb> infinity, fyi, we're not using that file yet. it's used for config file generation. we'll be moving to that eventually.
<infinity> coreycb: Fair enough.  If you never actually run it, not shipping it would seem the best option to fix the python autodepends issue.
<coreycb> infinity, ok
<infinity> coreycb: (Stab in the dark, I don't do much python packaging, but if it's generating the dep based on that import, it stands to reason that if there's no import, there's no dep :P)
<infinity> coreycb: Alternately, you could just patch out the two references to google entirely, and drop the Suggests too.  Not much point suggesting a module that never gets used.
<coreycb> infinity, well it is used in cinder/backup/drivers/google.py so I think it should be an option for users.  also I think that if dh_python generates the dep it's based on requirements files not imports.
<infinity> coreycb: Oh, probably indeed.
<coreycb> infinity, appreciate the discussion!  off I go..
<slangasek> pitti: where's the right place to file bugs about update_excuses output?
<pitti> slangasek: https://bugs.launchpad.net/britney I think
<slangasek> ok
<slangasek> I tried to find 'proposed-migration', because ISTR 'britney' is deprecated as a name ;)
<pitti> slangasek: https://bugs.launchpad.net/auto-package-testing/ works too
<pitti> that's the umbrella project
<infinity> pitti: Yo.
<infinity> https://launchpadlibrarian.net/248258284/buildlog_ubuntu-xenial-armhf.nginx_1.9.12-0ubuntu1_BUILDING.txt.gz
<infinity> pitti: pkg-create-dbgsym bug, or would you rather blame debian/rules?
<infinity> pitti: teward says this is racy and nondeterministic, and retries generally succeed.
 * teward was pinged :)
<pitti> infinity: looks like dh_strip is being called in parallel four times, so I guess some missing locking indeed
<infinity> override_dh_strip:          $(foreach flavour,$(FLAVOURS),strip.arch.$(flavour))
<infinity> strip.arch.%:
<infinity>         dh_strip --package=nginx-$(*) --dbg-package=nginx-$(*)-dbg
<infinity> So, yeah.  They could force that to be serial to work around it.  But I'd say it's our bug that it doesn't work.
<infinity> Though, I'm still wary of anyone setting MAKEFLAGS=-j in debian/rules.
<infinity> teward: Tearing out that and switching to dh --parallel would likely clear it up at the expense of slowing down the non-build parts a bit.
<infinity> Maybe.
<pitti> infinity: at first sight I don't see anything which would write into shared files (i. e. write things other than to the per-binary package dir)
<pitti> unless it calls pkg_create_dbgsym *twice* for the same binary package somehow
<infinity> Wait...
<infinity> pitti: This almost looks like strip and gencontrol are running in parallel, which doesn't seem possible.
<infinity> pitti: Or does pkg-create-dbgsym's dh_strip call dpkg-gencontrol?
<pitti> infinity: no, but it diverts dpkg-gencontrol
<pitti> err, dh_gencontrol
<slangasek> nacc: confirmed that php-sabre-dav-2.1 still failing on s390x
<infinity> pitti: No, it totally calls dpkg-gencontrol.
<pitti> for the -dbgsym, yes
<nacc> slangasek: ah, i wondered, let me investigate what isn't generating the right dep
<infinity> pitti: So, yeah, that's the race, I think.  dpkg-gencontrol locks, but you rm -f dhstrip-dummy-debian-files outside the lock, which could whack it at exactly the wrong time.
<infinity> pitti: I wonder if -f/dev/null works.  That would be less sketchy, perhaps.
<infinity> Nope, /dev/null wouldn't work, since it would try to write to /dev/null.new
<infinity> Brilliant.
<infinity> Perhaps I need to fix dpkg first, then pkg-create.
 * infinity makes a note for later and abandons this for today.
<pitti> infinity: -fdhstrip-dummy-debian-files.${pkgname} ?
<infinity> pitti: Oh, or indeed, using per-package files would also work.
<nacc> slangasek: i think i found it
<nacc> slangasek: in my build logs, i see:
<infinity> pitti: Probably quicker than me fixing dpkg. :)
<nacc> slangasek: Override: require:pear-pecl.php.net/mbstring -> require:__override__/builtin.
<nacc> slangasek: but in debian, that does not happen
<infinity> pitti: (Though, I think having a "none" option for -f would be sane as well)
<pitti> infinity: sorry, diverted (vsprint going on), but that seems easiest?
<nacc> slangasek: trying to figure out why
<infinity> pitti: Yup, concur.  I'll upload that (and drop -is -ip while I'm there to cut down on log noise)
<pitti> infinity: cheers
<infinity> teward: Fixed.  If the problem recurrs, let us know so we can see if we missed another race. :P
<infinity> pitti: http://launchpadlibrarian.net/248264461/pkg-create-dbgsym_0.70_0.71.diff.gz
<pitti> yay
<infinity> pitti: And fixed just in time for us to switch to Debian's dh-based solution, I guess. :P
<infinity> pitti: (Is that on your roadmap for 16.10?)
<nacc> slangasek: ok, i see what's happened
<nacc> slangasek: debian has made more changes to pkg-php-tools under 1.32
<pitti> infinity: that requires some Launchpad changes at least, as debian uses .deb as extension at least (not sure if there's some other subtleties)
<infinity> pitti: We can just patch debhelper to use ddeb for us, surely.
<pitti> yeah, I guess
<infinity> pitti: I'm not keen on changing the extension to match Debian, personally, I think their choice was wrong.  ddebs aren't policy-compliant debs.
<slangasek> nacc: uhhm? we have 1.32ubuntu1; was that not based on a 1.32 package that was uploaded to Debian?
<nacc> slangasek: want me to provide  debdiff to get us merged up?
<nacc> slangasek: no, it was versioned as 1.32 in debian but it was a WIP, apparently
<slangasek> nacc: IOW this was a merge from git but it wasn't in the archive?
<nacc> slangasek: yeah
<slangasek> nacc: ok; in the future please avoid using a version number like 1.32ubuntu1 for something not yet in Debian unstable, to avoid this problem of invisible Debian deltas :)
<nacc> slangasek: yep, my fault cmpletely
<slangasek> nacc: and yes please I'll take a debdiff for pkg-php-tools
<slangasek> 1.32ubuntu1->1.32ubuntu2
<nacc> yep
<nacc> slangasek: and the delta we have is in the git tree (debian's) but after 1.32, so i'll continue to carry it as a delta, and eventually (16.10), we'd be able to sync easily
<infinity> pitti: Oh, lolz.  Testsuite fails due to the deprecation of DH_COMPAT << 5
<infinity> pitti: La la la.
<infinity> pitti: Does dhtest.compat1 make sense at all given debhelper will fail, or should I just remove it?
 * infinity leans toward the latter.
<pitti> infinity: we still had compat 1 packages at the time when I wrote that
<pitti> infinity: if those are now FTBFS, I'm all for killing that code and these tests
<infinity> pitti: Right, and we may still have some, but they'll FTBFS regardless.
 * infinity nods.
<infinity> pitti: Killing the test then.
<infinity> And test building before I upload this time.  Grr.
<nacc> slangasek: testing the updated build and will post in just a sec
<nacc> slangasek: debdiff posted in LP: #1557599
<ubottu> Launchpad bug 1557599 in pkg-php-tools (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,New] https://launchpad.net/bugs/1557599
<slangasek> nacc: pulling. any thoughts on the mb_stripos() empty delimiter issue on s390x?
<nacc> slangasek: i'm trying to figure out how that could happen only on one architecture ... it feesl like it must be a utf8 bug on s390, but i have no experience debugging it. Is it possible for me to spin up an instance that I can reproduce the failure on?
<nacc> slangasek: pointing me to a wiki page would be fine :)
<slangasek> nacc: I think the server team should have access to some s390x resources that you should be able to get onto
<nacc> slangasek: you're right, i'll ask around
<infinity> pitti: http://paste.ubuntu.com/15396968/ <-- Bigger, badder diff that now passes the testsuite.  Look sane to you?
<pitti> infinity: yay, I'm glad to see that old junk go, thanks
<infinity> pitti: I'll read that as a +1
<nacc> slangasek: as to php-pear's excuses, i just subscribed you to a bug to fix php-cache-lite and i believe php-html-safe just needs to be kicked back off now that we've fixed php-xml-htmlsax3]
<jtaylor> infinity: I guess a glibc update is not going to be done anymore?
<sarnold> jtaylor: infinity said earlier today that he's working on glibc updates to address 1529486 (among others)
<teward> infinity: good to hear, thanks for the heads up
<doko> infinity, tdaitx: openjdk-6 should be removed; we can prepare security updates in ppa's as well. ideally 7 should be removed as well, but it's in universe, and we still have b-d's. having certified versions in main is more important than removing 7 from my point of view
<infinity> jtaylor: it's on the way.
<infinity> doko: Alright, I'll operate on the assumption that 7 is surviving and fix tzdata to accomodate.
<infinity> doko: (FWIW, 6 and 7 are both uninstallable in sid)
<doko> infinity, I would appreciate a tzdata-java for experimental; it's way easier to prepare packages in experimental, and then backport
<doko> or I'll have to add a variant to use the internal tzdata
<infinity> doko: Not sure how experimental relates.  I can just reintroduce tzdata-java in sid if openjdk-7 is sticking around for a while.
<infinity> doko: aurel32 dropped it because we were using default-jre, that's all, I'll just switch to using 7 explicitly.
<doko> would like to get it out of testing first; but then,  you can't build tzdata-java anymore in testing
<infinity> doko: I'm a bit lost.  Why would we remove it from testing?
<doko> because there should be one version only
<doko> and you can't use 8 to build it; 8 using a different format again
<infinity> doko: I guess I'm very confused by what you're asking for.  The tzdata-java in testing and xenial was built with openjdk-7.  I'm just proposing reintroducing that same thing so your deps don't break.
<infinity> (Because openjdk-6-jre-headless and openjdk-7-jre-headless depend on tzdata-java)
<nacc> slangasek: ok, super weird about php-imagick; it's pretty clear that s390x is giving 32768 (as it failed with ubuntu2 for that reason) ... so why didn't teh change work for amd64 & ppc64el? setting up an env to debug in
<nacc> slangasek: ok, but i did reproduce this here, so let me debug. I swear i got this test to pass on my system when i submitted the debdiffs before...sigh
<teward> infinity: which package(s) got updated to include the fix for that race condition, if I may ask?  *is curious what the core cause was, and lost all his scrollback*
<infinity> teward: pkg-create-dbgsym
<infinity> teward: http://launchpadlibrarian.net/248274500/pkg-create-dbgsym_0.70_0.72.diff.gz
<teward> thanks
<slangasek> nacc: what's the prognosis on php-sabre-dav-2.1/s390x?  I'm wondering if I should bypass that failure to unblock that stack
<slangasek> nacc: actually, scratch that - I am going to bypass the failure to unblock the stack
<nacc> slangasek: i'm unable to access our s390x machines, was hoping to sync with cpaelzer on it in the am and will debug it on a real system
<nacc> slangasek: so that sounds good
<slangasek> ok
<nacc> slangasek: i've added it to my list to make sure to figure out
<nacc> slangasek: i'm still trying to figure out this imagick thing right now
<slangasek> nacc: it may point to a real bug in php-mbstring, so as long as it's tracked, that's what matters
 * slangasek nods
<nacc> slangasek: yep
<slangasek> nacc: ok, so I think that test override, plus a couple of iterations of re-testing, should get us a clean attempt at promoting php7.0+pear+defaults
<nacc> slangasek: great, i'll keep my eyes on it
<slangasek> you mentioned php-redis Breaks possibly needing adjustment still?
<nacc> slangasek: yeah, i'll submit that debdiff now
<nacc> i have it here somewhere :)
<nacc> slangasek: posted just now to LP: #1554319
<ubottu> Launchpad bug 1554319 in Fuel for OpenStack "test_deletion_during_deployment randomly fails due to database deadlock " [Critical,Fix committed] https://launchpad.net/bugs/1554319
<slangasek> nacc: is that the right bug?
<nacc> bah
<nacc> LP: #1553419
<ubottu> Launchpad bug 1553419 in php7.0 (Ubuntu) "php7.0: update to latest version of packages from Debian unstable" [Undecided,Fix committed] https://launchpad.net/bugs/1553419
<nacc> :)
<slangasek> nacc: ok. I'm inclined to hold off on uploading until I get a chance to see the update_output for the existing packages
<nacc> slangasek: yep, that's fine
<nacc> slangasek: it should only be needed if something is trying to install php-redis, i suppose
<slangasek> nacc: well, proposed-migration expects all packages to be installable; so php-redis being uninstallable due to breaks means it will be held up. but I want to make sure that's the *only* thing holding us up on php-defaults, so I don't have to do multiple uploads and wait again for multiple test runs
<nacc> slangasek: ah i see what you mean, fair enough
#ubuntu-devel 2016-03-16
<nacc> slangasek: *super* confusingly ... it seems like debian's php-imagick only shows the one failure from before that the imagemagick backports should be resolving ... so possibly the backports introduce a regression? I'm debugging using upstream ImageMagick , but am also tempted to just skip this test as it seems inconsistent
<nacc> slangasek: and i have a really difficult time undersatnding how s390 gets a different (successful) result then the two failing archs
<slangasek> nacc: well, for that matter, I don't see why it should be different between the failing archs and the succeeding 32-bit archs; this shouldn't be wordsize-sensitive math
<nacc> slangasek: right, it's really odd
<nacc> unless some double rounding is off in php
<nacc> slangasek: let me also say the upstream ImageMagick coding standards are ... poor :)
<nacc> so many empty commits
<nacc> empty commit messages, i mean
<slangasek> yeah, I noticed that
<nacc> slangasek: ok, i just confirmed (agin) that upstream imagemagick works fine with the version of php-imagick we have in ubuntu, at least for that one test -- bisecting again
<nacc> slangasek: ok, so i need to look at php-proxy-manager (that's already on my list); i'm still learning to understand/pase the update_output.txt file, let me konw if there are more action items you want to extract from it
<nacc> slangasek: also, i'm not sure i understand fully why php-defaults has regrssions for php-sabre-http and php-sabre-http-3 where those versions are superseded in proposed? is that just an ordering issue? or does it only retrigger as those propogate to the release pocket?
<slangasek> nacc: the latter
<slangasek> actually, it doesn't automatically retrigger at all, but I'm retriggering them manually
<nacc> slangasek: ah, well, thank you very much!
<nacc> slangasek: i suppose it would be a lot of potential churn if it was automatic
<slangasek> well, I believe there's an outstanding bug report about making that automatic
<GunnarHj> robert_ancell: Hi Robert, Do you plan to fix the u-c-c task at bug #1554878 (or possibly remove the rest of the XDG_CURRENT_DESKTOP queries)?
<ubottu> bug 1554878 in unity-control-center (Ubuntu) "fix up usage of XDG_CURRENT_DESKTOP" [Medium,Triaged] https://launchpad.net/bugs/1554878
<robert_ancell> GunnarHj, I'm not working on it right now, if you want to make MPs for the remaining issues please do
<GunnarHj> robert_ancell: I'm afraid it's above my head to decide if any non-Unity options need to be kept.
<cpaelzer> good morning
<Mirv> pitti: morning! trying to retry i386 from https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-006/excuses.html , I get "A server error occurred." after clicking the login button
<dholbach> good morning
<pitti> Good morning
<pitti> Mirv: "no space left on device", argh
<khfeng> Hi all.
<khfeng> Can anyone help me setting "Also affects distribution/package" for Trusty in LP:1557893
<Mirv> pitti: thank you, seems working now
<pitti> Mirv: yes, but not for long, I'm working on avoiding running out of inodes more permanently
<Mirv> ok
<pitti> Mirv: ok, should survive longer now :)
<Mirv> pitti: great!
<Laney> doko: did you see the pyzmq problems?
<doko> Laney, yes
<Laney> ok
<lamont> doko: smb cyphermox I am now all over bind9
<cyphermox> yay
<smb> awesomeness
<lamont> it's mixed awesomenes, since it became a hardblocker for my team last night. :/
<cyphermox> oops
<cyphermox> not much response from the other guy?
<smoser> pitti, xnox so my cloud-init units (specifically cloud-init-local) is not guaranteed to run before ifup@.service units, as those are run via hotplug events.
<xnox> and i guess running before udev cold-plug is too early, as disk and things might not exist then yet.
<xnox> smoser, run -local in the initramfs?! =)
<smoser> the result (observed) is that cloud image with 'dhcp eth0' will dhcp before cloud-init woudl write other configuration for eth0. meaning i'd have to take the interface down to actually apply it. and worse, with ifdown insistening that the interfaces file is in the state it was in when ifup was run, i have to deal with that.
<smoser> xnox, yeah, but / isn't even mounted rw at that point
<smoser> initramfs
<smoser> but yes, generally that is kind of the path that others have taken
<xnox> and e.g. in the systemd-networkd (if and when we switch to that) it also does everything via udev events. And there it's worse, one cannot really remove config at all.
<pitti> smoser: but ifconfig  wouldn't even have a configuration if c-i-local didn't run yet, so wouldn't that event be a no-op?
<smoser> it seemed to me that possibly i could make the cloud-init-local RequiredBy ifup@.service
<xnox> horum.
<pitti> well,l ifup@ is already After=network-pre.target
<pitti> but that doesn't matter for things which are started explicitly
<pitti> (which is done by /lib/udev/ifupdown-hotplug)
<pitti> so RequiredBy=ifup@.service in c-i-local should work indeed
<pitti> although it's a bit of a crowbar really
<smoser> yeah.
<pitti> smoser: so I'm confused -- if that hotplug event already does *anything*, it means that there already is a config for that interface, and thus c-i-local must have run already?
<smoser> well, i guess
<smoser> a.) in a stock image, we still have 'auto eth0' and 'dhcp' in ENI
<pitti> smoser: the RequiredBy= probably blows up in your face if you disable cloud-init on the command line?
<Odd_Bloke> Ooh, exciting, running sbuild on my desktop unmounts my ecryptfs home directory.
<smoser> b.) in a stopped and snapshotted image, you'd have the 'old' data in ENI
<pitti> smoser: ah -- well, that we need to get rid of, but I thought that was the whole point of that exercise
<pitti> "auto eth0" is EBW
<pitti> b) is an interesting point
<smoser> c.) if there was *not* anything there, then ifup would not do anything. but the cloud-init would have to ifup the interface itself.  i guess that is possible, but it seeemed more than ideal cloud-init just let the system bring up the networking.
<smoser> in the future, the intent woudl be to be able to apply networking chagnes after boot, so cluod-init woudl then need to know how to re-set the running system (ideally with minimal change)
<smoser> but i was kind of hopign to just avoid dealing with that.
<smoser> EBW ?
 * pitti pushes away the thought that we are reinventing NetworkManager here
<ogra_> just seed it and use nmcli :P
<pitti> smoser: not tested (and distracted), but does it work better if you add Requires=network-pre.target to ifup@.service?
<pitti> then any ifup@ should not only run after n-pre but also actually start it if it hasn't already, and thus also run c-i-local
<pitti> smoser: I have a gut feeling that nothign is actually starting network-pre.target right now, this should rectify this
<smoser> :)
<pitti> oh, and adding Requires=network-pre.target to networking.service too
<pitti> I think that was an oversight when we wrote those units
<smoser> pitti, my journalctl on a system right now does not seem to have any occurance of 'target.*network.*pre'
<smoser>  journalctl | grep -i 'target.*network.*pre'
<smoser> i'll try your suggestion
<pitti> smoser: http://paste.ubuntu.com/15401586/ â not entirely sure that this is the right way to put them (as the intention is that things that want to run before pull it in, not things that run after it), but if that fixes it we at least know what to look for
<Odd_Bloke> pitti: tyhicks: I'm seeing bug 1430557 (or something very similar) when running sbuild even with schroot 1.6.10-1ubuntu3 installed. (I don't really know enough about how s(build|chroot) work to know if I should be doing something in addition to just installing the updated package)
<ubottu> bug 1430557 in schroot (Debian) "sbuild / schroot unmounted encrypted home directory" [Unknown,Confirmed] https://launchpad.net/bugs/1430557
<smoser> pitti, that seems to have worked.
<smoser> the one other hting that i want/need is to be able to rename interfaces
<tyhicks> Odd_Bloke: hi - can you paste the corresponding schroot fstab file (/etc/schroot/<PROFILE>/fstab) and /proc/self/mountinfo ?
<smoser> maybe cloud-init will just have to do that, but could do fairly freely knowing that the interfaces would not be ifup'ing at that point.
<smoser> cloud-init is writing udev rules, but the rule to rename might have already been written.
<smoser> oh shoot.
<Odd_Bloke> tyhicks: o/ /etc/schroot/sbuild/fstab -> http://paste.ubuntu.com/15401660/, /proc/self/mountinfo -> http://paste.ubuntu.com/15401663/
<smoser> seems like bridges might be too late also.
<smoser> hm.. so my reaading is that bridges and device renames are going to cause me some pain. as udev would have already invoked /lib/udev/ifupdown-hotplug
<smoser> and actually that would have already decided (based on the /etc/network/itnerfaces at the time) if the interface was 'auto' or not.
<tyhicks> Odd_Bloke: nothing odd in there
<tyhicks> Odd_Bloke: what about ubuntu release was in the chroot that you were using?
<tyhicks> bah
<tyhicks> typo
<tyhicks> Odd_Bloke: what ubuntu release was in the chroot that you were using?
<tyhicks> Odd_Bloke: I see the problem. You're hitting bug 1438942
<ubottu> bug 1438942 in schroot (Ubuntu) "Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots" [High,In progress] https://launchpad.net/bugs/1438942
<tyhicks> Odd_Bloke: I was really wanting to get feedback from schroot maintainers on that fix before uploading it but it is dragging on for too long
<tyhicks> Odd_Bloke: I'll poke the Debian bug and then go ahead and upload the fix in Ubuntu
<Odd_Bloke> tyhicks: Great, thanks!
<Odd_Bloke> (It was trusty in the chroot :)
<tyhicks> yep :)
<tyhicks> Odd_Bloke: schroot is mounting a new tmpfs over /dev/shm in your *host*
<tyhicks> Odd_Bloke: ecryptfs-utils keeps some state in /dev/shm so it causes problems when an entirely new tmpfs is mounted over /dev/shm
<tyhicks> Odd_Bloke: I think a workaround in the meantime would be to unmount the extra tmpfs at /dev/shm after you've created the schroot session but before you destroy it
<awe> anybody know who controls the ACL lists for the wiki?  One of my test plan pages has become imumutable, and I can't update it anymore
<rbasak> awe: are you accidentally logged out?
<awe> nope
<awe> I tried logging out and back in again
<awe> and they didn't do it
<awe> s/they/that/
<seb128> rbasak, https://launchpad.net/ubuntu/+source/software-properties/0.96.19 btw, just for info
<rbasak> seb128: ?
<seb128> rbasak, it was not you who were asking about unattended-upgrades/software-properties depends? sorry, need to check my IRC logs
<rbasak> seb128: ah yes, I was.
<seb128> k
<seb128> well, fix uploaded ^
<seb128> just I was just letting you know
<rbasak> Ah. Thanks!
<seb128> yw!
<bdmurray> seb128: will that software-properties upload fix bug 1554099?
<ubottu> bug 1554099 in software-properties (Ubuntu Xenial) "Changing what action for security updates unusable" [High,Confirmed] https://launchpad.net/bugs/1554099
<pitti> smoser: worked> nice!
<seb128> bdmurray, yes, sorry forgot about that bug/to list it in the changelog
<bdmurray> seb128: no problem
<smoser> pitti, i think i've convinced myself that bridge and vlan (which run at 40-* in /lib/udev/rules.d) wont be a problem for me
<pitti> smoser: so apparently the intention is "This passive target unit may be pulled in by services that want to run before any network is set up", i. e. which declare the Before=
<smoser> butrenaming devices seems like it still will.
<smoser> ^ is for network-pre ?
<seb128> bdmurray, we discussed it with m_vo on IRC, unattended-upgrade does autodownload so that option isn't needed to be set to 1
<pitti> smoser: yes, that was a quote from the manpage
<pitti> smoser: renaming happens in 80-net-setup-link.rules
<pitti> smoser: so if you want to rename something, the udev rule ought to exist before the device is processed by udev, otherwise you might already start things which depend on the old name
<smoser> right.
<smoser> pitti, cloud-init writes /etc/udev/rules.d/70-persistent-net.rules . which would work on next reboot
<pitti> smoser: right (don't forget to call update-initramfs -u too)
<pitti> smoser: what's that for, OOI? can you define interface names in user-data?
<smoser> update-initramfs -u : yuck.
<pitti> smoser: it's not strictly necessary if you have a controlled environment, but safer
<pitti> smoser: there's things like open-iscsi and friends which talk to network interfaces in the initrd already
<pitti> if you can rule these out, then they can be renamed after initrd
<smoser> the goal woudl be to define the interface name in the 'network-config'. right now that network config would only come from the cloud provider. but thats no different really than coming from the user. same end result. something outside declares what they want.
<doko> Mirv, pitti: is xvfb currently not working properly? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/i/ipython/20160316_133657@/log.gz
<smoser> the initramfs only comes into play if 'ip=' on the command line. i think i might have to accept that any interface already configured is nto goign to be changed.
<smoser> right now maas can declare the interface name when it installs a system.
<smoser> as it runs in the install environment and the peristent-rule are written before reboot
<smoser> so thats fine.
<ogra_> (you could add something like "override.name= ..." to your kernel cmdline instead and have a script in the initrd that reads it ... that saves you from regenerating and you just need to change the cmdline
<ogra_> )
<smoser> so at this point the network-config allows you to declare "the device with MAC=XX:XX:XX is to be named foobar0"
<smoser> i'd like to support that if at all possible in the scenario where the network-yaml is consumed during boot.
<ogra_> well, so you use that name pre-mount ... and post-mount you write it into the udev rule file
<ogra_> (from your initrd)
<ogra_> assuming your yaml can be pulled from some server via network
<smoser> ogra_, i think its ok if you have "dirty" persistent rules are fine as long as network is not left up after exiting initramfs.  ie, i think the *root*'s persistent-rules would still be consumed, right?
<ogra_> yeah
<ogra_> i thought you wanted a persistent name from start to end though
<smoser> that'd be ideal, but i'mi ok at this point to say that booting iscsi root with 'ip=' on the command line you can't declarel the name of the nic.
<smoser> or if you did, you need to declare it to the intiramfs, and then cloud-init would need to respect that.
<smoser> the way ii'm looking at that is that 'ip=' on the command line is actually definitive over a network-config.
<smoser> similar to the way that command line flag would override environment variable or config file
<ogra_> yeah
<smoser> pitti you said 80-net-setup-link.rules sets naming ?
<smoser> if thats true, then i'd have thought it woudl run *after* 80-ifupdown.rules
<smoser> which would have tried to ifup the nic with the old value of $INTEFACE
<pitti> smoser: no, RUN is executed after all rules for a device are processed
<smoser> ah. ok. that makes more sense then.
<pitti> it should probably have been 85-ifupdown.rules or so to avoid confusion, but it won't make a practical difference
<nacc> slangasek: fyi, got access to a s390x system, so will debug that issue today
<smoser> pitti, so do i have a chance at this ?
<smoser> is there any way something run on ADD can dynamically determine the name and set it ?
<smoser> IMPORT would seem possible, but i think setting NAME= in via import would only affect the env{NAME} not the NAME
<pitti> smoser: yes, you can run something with IMPORT
<pitti> smoser: ah, you can do PROGRAM="echo-my-name", NAME="$result"
<pitti> smoser: or rever to any $env{VARNAME} or similar
<pitti> IMPORT and PROGRAM are synchronous in one rule, RUN+= gets queued after rule processing
<Son_Goku> nacc: what do I need to do to request php7.0-fpm to be in main?
<pitti> Son_Goku: nothing
<pitti> it already is :)
<Son_Goku> it is?
<Son_Goku> wooo!
<pitti> it was on component-mismatches a few days ago, so I promoted it
<Son_Goku> awesomeness
<pitti> things were horribly uninstallble before
<Son_Goku> pitti: thanks
<nacc> Son_Goku: for reference, this is the MIR process for php5-fpm: LP: #1267255
<smoser> pitti, NAME="$result" ?
<ubottu> Launchpad bug 1267255 in php5 (Ubuntu) "[MIR] php5 (php5-fpm binary)" [Wishlist,Confirmed] https://launchpad.net/bugs/1267255
<smoser> oh. all in one rule you coudl do that ?
<pitti> smoser: this question no verb
<pitti> smoser: yes, see man 7 udev
<pitti> smoser: you can use various substitutions in ENV, NAME, etc. assignments
<smoser> right.
<smoser> ok, then. tell me how horrible you think this is.
<smoser> the plan would be to add a rule with: IMPORT=<some-program>, NAME=env{NEWNAME}
<pitti> smoser: so roughly, PROGRAM/IMPORT are for *detecting* devices and determining their properties (but these programs can't do much with that new device), while RUN is about doing *something with* the newly found device and can use it fully
<doko> pitti, so the pyzmq triggered ipython autopkg test failure looks unrelated to pyzmq. please override it for this migration
<pitti> smoser: well, with some additional ACTION==, SUBSYSTEM=="net", etc. :)
<smoser> and IMPORT would block until cloud-init-nonet had found the data it was looking for.
<Son_Goku> when is the next time xenial-proposed gets merged into xenial?
<pitti> Son_Goku: that happens automatically as soon as the thing in -proposed is ready (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<cjwatson> and that process runs multiple times an hour, typically
<pitti> smoser: just make sure that it's really fast
<pitti> smoser: i. e. milliseconds
<smoser> well, it might not be on first boot.
<pitti> doko: done
<smoser> and even
<smoser>  time python3 -c 'pass'
<pitti> erk, python?
<ogra_> uuh
<smoser> is itself on the order of milliseconds (~ 0.04)
<pitti> this runs on every add or change of a network device
<pitti> well, at least add NAME=="" so that it doesn't re-run after it ran successfully once
<smoser> right. but i need it to block until cloud-init-nonet has determined what the new name should be.
<pitti> no, you can't do that
<Son_Goku> nacc: is there a way to set conflicts or dependencies for enabling confs through a2enconf?
<smoser> hm.. why not ?
<pitti> you can run for a second or so and figure out the name, but you can't block indefinititely on some external async service to run
<smoser> udev will just kill it if it thinks it is taking too long
<smoser> is that right ?
<pitti> right, that too
<pitti> smoser: but the attributes -> name map should be in some easy to parse format somewhere on disk
<pitti> and if it's not there, just don't assign a name
<pitti> if it's not configured, nothing should use the device
<smoser> so the goal is for cloud-init-nonet to find a network configuration that says "the nic with mac XX:YY should be named pittinet0"
<smoser> but this event may come in before cloud-init-nonet has run
<smoser> (or run to completion)
<Son_Goku> nacc: I canât seem to find anything that indicates itâs possible, but I was hoping itâd be possible to make it so that when a2enconf php7.0-fpm is activated, it can switch on dependent modules, or indicate that it wonât run if php7.0 is enabled
<smoser> so my plan would be for that IMPORT program to simply parse a file liek you suggest , but one written by cloud-init-nonet.
<smoser> if the file (/run/cloud-init/simple-parse-file) is not present, it would block and wait for it to appear.
<nacc> Son_Goku: shouldn't that be something php7 upstream does? i dont' think it'd be uatomatic, it'd need soemthing we'd have to write, i guess
<pitti> smoser: cloud-init-nonet could trigger change events for network cards if it actually has any assignments
<pitti> then they'll re-run
<Son_Goku> nacc: they donât care, and I wrote the php7.0-fpm a2enconf stuff
<Son_Goku> technically, nothing will blow up if you do it with mine, as it just wonât do anything if php7.0 is active
 * Son_Goku gets really confused with mod/conf system
<doko> nacc, slangasek: the zeromq3 and php-defaults transitions are coupled. what's the status of the failing autopkgtest for php-imagick?
<nacc> doko: debugging it as we speak
<doko> ta
<smoser> pitti, but the 'RUN+' that does the ifup has to have the new name, and ideally not run until /etc/network/interfaces has been populated with the provided data.
<smoser> and the CHANGE woudln't rename the interfaces i dont think. at least in the past via 70-persistent-net.rules, those were done only on ACTION=="add".
<smoser> but i admit to not understanding 80-net-setup-link.rules
<smoser> oh. now that i read it i undderstand more.
<tjaalton> why does running 'systemctl start dbus' fail like it does on xenial, but not on debian?
<tjaalton> "Failed to start dbus.service: Operation refused, unit dbus.service may be requested by dependency only."
<nacc> slangasek: ugh, at least on s390, we've got a string with a zero length, but pointing to a valid string
<pitti> tjaalton: that (RefuseManualStart=yes) is an ubuntu speficic change
<tjaalton> pitti: okay
<pitti> tjaalton: that particular change was from bug 1540282
<ubottu> bug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Low,Fix released] https://launchpad.net/bugs/1540282
<tjaalton> need to work around it in freeipa then
<pitti> tjaalton: and the whole "don't stop on shutdown" is still from bug 1438612
<tjaalton> or just not run start, seems silly anyway
<ubottu> bug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Fix released] https://launchpad.net/bugs/1438612
<pitti> once we fix all consumers of d-bus interfaces on shutdown to DTRT we can drop it again
<pitti> but things getting stuck on trying to talk to dbus on shutdown have caused tons of shutdown hangs
<tjaalton> right, ok
<pitti> so this was a dirty, but remarkably effective way of fixing those
<pitti> tjaalton: I was hoping that by 16.04 we would have kdbus and none of this would be relevant any more :/
<tjaalton> heh :)
<Son_Goku> pitti: wellâ¦ thereâs bus1, maybe someday possibly?
<Son_Goku> who the hell knows anymore...
<slangasek> doko: zeromq3 and php-defaults should not be coupled; I've uploaded php-defaults to not require a newer version of php-zmq
<rbasak> xnox: please could you explain your upload of juju-mongodb 2.4.10-0ubuntu6? I'm reviewing updated juju-mongodb packaging for upload and want to know whether I need to carry that forward or not. It would help to know why.
<xnox> rbasak, juju-mongodb should be built on all ubuntu architectures, there is no reason not to.
<xnox> as juju works on all arches (and go, and mongodb)
<xnox> rbasak, you should carry "Architecture: any".
<rbasak> xnox: OK, so please could you explain this in the changelog at time of upload?
<xnox> I did =) "Drop architecture restrictions." i'm not sure how else to phrase it, there is nothing arch-specific in the package.
<rbasak> No, that tells me _what_, not _why_. I can see _what_ by looking at a diff.
<ogra_> "build with "Architecture: all""
<ogra_> way easier for quick-parsing
<xnox> rbasak, horum, ok. Are you updating to new major upstream release or some such?
<ogra_> (or "any" in this case)
<rbasak> "Drop architecutre restrictions since there is nothing arch-specific in the package" would be better, for example. Or whatever other reasoning you want to give. Otherwise I don't know if there's some hidden reason I'm missing and have to investigate.
<rbasak> xnox: yeah - 2.6 and 3.2 as new source packages.
<rbasak> There may be porting issues. We'll see.
<xnox> rbasak, you will probably need to cherrypick 2.6 & 3.2 branches from e.g. IBM for ppc64el and s390x ports....
<xnox> (aka update/refresh the port patches that we include there)
<xnox> and probably pick up linaro trees for arm64.
<xnox> unless it's all upstream, but i don't think all has made it into 3.2.
<sinzui> hi rbasak
<rbasak> sinzui: xnox was talking above about porting suggestions for s390x, ppc64el and arm64.
<rbasak> I noticed that your juju-mongodb 2.6 packaging was based on ubuntu4, and ubuntu5 adds some porting stuff.
<rbasak> Do you know the current status of your 2.6 packaging wrt. those architectures please?
<sinzui> rbasak: oops. I didn't realise how stale that package had become. I can and will use xenial's current package as the base
<rbasak> sinzui: it's only a couple of minor changes, don't bother.
<rbasak> sinzui: just apply those changes to the top of your tree or something.
<xnox> rbasak, sinzui - yeah we should not regress arch support, if there are troubles with ppc64el/s390x/arm64 do open a bug and let me know. there shouldn't be any porting required, just finding the right vendor repos on github and integrating them.
<sinzui> rbasak: the 2,6 package was fine on ppc64el and arm64.
<xnox> sinzui, s390x is brand new, and powerpc was added too.
<sinzui> rbasak: I got access to s390x yesterday and need to solve hoe to build and test on it...it looks lile a fedora derivative
<rbasak> sinzui: or if you prefer, I can leave it for now and wait for an update from you?
<xnox> sinzui, you got access to the wrong thing =)
<sinzui> xnox: Juju doesn't support powerpc but s390x is what we are adding
<xnox> sinzui, you got access to a z/KVM, which should have libvirt running which can be used to launch ubuntu cloud image.
<xnox> sinzui, for development and building things, you probably want an ubuntu lpar and/or ubuntu zvm. I have those available and can co-share access to that. It has like sbuild.
<xnox> sinzui, note that some of juju ppas have s390x enabled now, thus you can just use a launchpad ppa to be honest.
<sinzui> xnox: yes, vish is there but was expecting ubuntu xenial
<slangasek> doko: ah I see, it's a one-way dep where php-defaults needs to happen first and then zeromq can go.  Yeah, I'm forcing php-defaults through
<xnox> sinzui, hence i said wrong thing. very little people actually need acess to z/KVM (rhel + virsh)
<slangasek> nacc: zero length> another rounding bug? ;)
<sinzui> xnox: The juju ppas are s390x enabled. and we have built
<xnox> sinzui, do update your rt request to get normal ubuntu lpar / zvm
<sinzui> thank you very much xnox
<rbasak> sinzui: please run update-maintainer also, and check the architecture list.
<rbasak> sinzui: Architecture: any might be more appropriate. It's fine to have unsupported architectures fail to build. Makes future porting easier.
<nacc> slangasek: i think it might be an upstream php bug ... they do some extra init routines in mb_strpos that they don't do in mb_stripos
<nacc> slangasek: looking into it
 * slangasek nods
<nacc> slangasek: doko: also i think i figured out the php-imagick issue
<nacc> slangasek: missing some parentheses :/
<nacc> testing that now too
<slangasek> nice :)
<nacc> slangasek: ah ok, i think php7.0 upstream has a fix for the s390x bug
<nacc> "fix incompatible pointers on 64-bit" :)
<nacc> or, it might, at least
<nacc> slangasek: going to try and build php7.0 from source on s390x to test
<tjaalton> jamespage: hi, libcommon-lang-java is broken because of the diff to debian (not using bnd). freeipa server fails because of that (more accurately pkispawn fails because of java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils)
<tjaalton> and also the jar is three times bigger than on debian
<nacc> tjaalton: i'd like to help debug that ... can you provide me a configuration that i can use to reproduce? that is, where could/should i point pkispawn?
<tjaalton> nacc: what do you mean? install pki-ca, run pkispawn
<tjaalton> it'll fail while trying to connect to the daemon, since it fails to start
<nacc> tjaalton: which release?
<smoser> pitti, is a generator guaranteed to run before udev events ? i'd guess it must be.
<nacc> tjaalton: in xenial, i get: http://paste.ubuntu.com/15402793/
<tjaalton> xenial
<xnox> smoser, well there is udev running in the initramfs, generators are run before udev-coldplug service at which point all events are retriggered if i understand things right.
<smoser> right.
<smoser> that sounds sane.
<tjaalton> nacc: hostname foo.bar
<nacc> tjaalton: doing that and updated /etc/hosts in my schroot, it started up and is asking me for a "Subsystem"
<tjaalton> and it should only have [CA]?
<tjaalton> hit enter
<nacc> tjaalton: ok, Directory server is localhost?
<tjaalton> oh right, you need that set up first
<tjaalton> install 389-ds-base
<nacc> tjaalton: ok
<tjaalton> run setup-ds
<tjaalton> express
<nacc> tjaalton: ok, one sec
<pitti> smoser: not before the initrd's udev, but certainly before we re-start udev adn do the big udevtrigger
<pitti> right, what xnox said
<smoser> yeah. so woudl there be an easy way to say "am i shooting for the cloud-inti target" in udev ?
<smoser> i can check for the .target file taht the generator would have written
<nacc> tjaalton: might need more config to make it work in a sbuild :/
<pitti> smoser: udev rules can't wait for anything; the only thing you can do is to start a .service asynchronously from a rule (SYSTEMD_WANTS)
<tjaalton> nacc: no you need a real machine
<tjaalton> aiui
<nacc> tjaalton: :/ ok
<nacc> tjaalton: not as easy for me to easily reproduce then :)
<tjaalton> real as in proper install, virtual or otherwise
<tjaalton> not chroot
<rbasak> sinzui: I'm done reviewing bug 1557830. Most items are related to architecture support and patches. It may be easiest to resolve this with xnox. When done I'm happy to upload, or xnox can if he wants.
<ubottu> bug 1557830 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb2.6 in xenial, wily, and trusty" [Undecided,New] https://launchpad.net/bugs/1557830
<tjaalton> nacc: this seems related https://bugs.launchpad.net/ubuntu/+source/axis/+bug/894302
<ubottu> Launchpad bug 894302 in axis (Ubuntu Trusty) "jar files do not include OSGi metadata" [High,Triaged]
<sinzui> thank you rbasak
<nacc> tjaalton: ok, i can try and look into it if jamespage can't
<tjaalton> heh, and https://bugs.launchpad.net/ubuntu/+source/libcommons-lang-java/+bug/1556647
<ubottu> Launchpad bug 1556647 in libcommons-lang-java (Ubuntu) "/usr/share/java/commons-lang.jar contains documentation" [Undecided,Confirmed]
<tjaalton> explains why it's so big
<tjaalton> and why it's broken
<nacc> tjaalton: ok, one sec
<nacc> tjaalton: i'll try and reproduce & debug
<nacc> tjaalton: you're right, that's almost certainly the underlying cause
<nlsthzn> quick comment/concern - I have been unable to get changes in alsamixer in the ammount of channels to stick (defaults to two, I change it to 6 for 5.1) When  reboot it is back to two again :/
<nlsthzn> with all of the 16.04 images I have tried
<nlsthzn> ubuntu / mate / xubuntu etc.
<tjaalton> nacc: here's the diff, if you plan on fixing it, should make it easier https://launchpadlibrarian.net/247122600/libcommons-lang-java_2.6-5ubuntu1_2.6-6ubuntu1.diff.gz
<tjaalton> or maybe not
<xnox> sinzui, rbasak, awww... we need 2.6 to in-place upgrade to 3.2 *sigh*. I would have thought we would be serialising juju and re-deploying for migration. E.g. because juju2 has different format for stuff anyway.
<xnox> pitti, now i see what you meant by all mongos everywhere.
<pitti> xnox: it's astounding. time is fleeting! Maaaaadness takes its toll.
<sinzui> xnox: yeah, it is very disapointing. there was discussion in Juju about creating their own format to inport/export to. that might be the long term solution
<pitti> leeeet's dooo the moooongoooo agaaaain âª
<xnox> sinzui, e.g. like sqlite or something =)
<sinzui> :)
<pitti> if we could serialize juju's db, why bother and not just always use that serialization format *cough* :)
<xnox> sinzui, as far as i can tell, we don't actually use anything mongo-ish in juju.
<sinzui> xnox: it is both a document stoe and a file store which cloud be done both other things. Mongo offers some encapulation.
<nacc> slangasek: great, s390x failures fixed, sending a debdiff for that and the twig failures (as it's a real bugfix too)
<nacc> slangasek: LP: #1558201
<ubottu> Launchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/1558201
<nacc> tjaalton: weird, the build produces a good jar, but something but be messing it up, reproduced and debugging now
<slangasek> nacc: is LP: #1558201 the only patch needed for php7.0 right now?  I'll probably let the current round of packages migrate and then pick up that diff
<ubottu> Launchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/1558201
<slangasek> (now that I've got the imagick hints the right way 'round)
<nacc> slangasek: yes, i think so -- that will fix the two known issues we've hit in testing with php7.0
<slangasek> nacc: which are the two? I only saw the sabre-dav/s390x one
<nacc> slangasek: sorry, the debdiff has two patches added
<slangasek> ok
<nacc> slangasek: i wasn't sure how to do that with the two bugs
<slangasek> like that is fine :)
<nacc> ok :)
<nacc> tjaalton: i think i found it
<nacc> tjaalton: but would need jamespage to review it
<slangasek> nacc: ok, looks like we're going to need one more p-m run but this should really be the one now - unfortunately p-m made a wrong guess about the packages to hint together and pulled in php-zmq, but a manual hint should get past that
<slangasek> then the php gallstone will be cleared and we can tie up loose ends
<nacc> slangasek: great, thanks
<[reed]> Could I get somebody to add precise to https://bugs.launchpad.net/ubuntu/+source/git/+bug/1557787 to get that fixed?
<ubottu> Launchpad bug 1557787 in git (Debian) "client/server RCEs in path_name()" [Unknown,Confirmed]
<slangasek> nacc: debian/patches, please include Bug-Ubuntu references for clarity; do you want to fix those up or shall I?
<slangasek> nacc: btw, provided proper Bug-Ubuntu headers, I favor generating the debian/changelog entries using dep3changelog
<nacc> slangasek: ah sorry, i can fix that up, i didn't have one of the bugs opened yet. Let me do that and run that command
<slangasek> (though the authorship of dep3changelog may imply some bias)
<slangasek> nacc: love the fix for the s390x mbstring problem. my only question is, why are we not building php7.0 with -Werror= flags that make this a build-time failure
<nacc> slangasek: good question
<slangasek> nacc: also, when I say I "love the fix", what I actually mean is "why the heck did they not just fix the type of mbfl_string in the embedded libmbfl"
<slangasek> I suppose because somebody could be building php against a stand-alone built of this library and it's ABI-changing
<slangasek> nacc: oh look, php migrated
<nacc> slangasek: awesome; and updated debdiff posted in that same bug
<slangasek> nacc: ok, so reason #1 not to build with -Wall -Werror, the phpdbg build fails to configure when using those flags ;)
<nacc> heh
<nacc> slangasek: i wondered about that
<nacc> slangasek: there are a ton of warnings already emitted
<nacc> slangasek: so that's probably why
<nacc> but they could possible turn on some flags
<nacc> slangasek: upstream is finally fixing all the semicolon issues, but even that's not done yet, afaict
<slangasek> and if I ignore that, I get http://paste.ubuntu.com/15404033/
<nacc> hrm
<nacc> Pharaoh_Atem: do you know --^ ?
<nacc> slangasek: in theory, could do -Werror -Wincompatible-pointer-types, right?
<slangasek> the problem is the configure script is wrong about strtok_r not being defined, so it goes a bit off
<nacc> oh i see
<slangasek> nacc: yeah possibly
<slangasek> I think there are probably a lot of other warnings you'd want turned on :)
<nacc> slangasek: yeah, i can take that as another todo
<nacc> slangasek: to at least look into
<slangasek> nacc: yeah; it's not urgent, but chances are it'd turn up other latent bugs like the mbstring one
<nacc> slangasek: yep
<slangasek> nacc: -Wincompatible-pointer-types doesn't catch it, fwiw
<slangasek> not sure what the right -W flag is, I guess doko might know
<nacc> slangasek: so i got e-mails from lp about the bugs being fixed for php-defaults/php7.0/php-universe-source7.0. But excuses still lists them all?
<slangasek> nacc: excuses shows you what's currently under consideration; update_output shows you whether it's actually being promoted; they'll be gone from update_excuses as of the /next/ p-m run
<nacc> slangasek: ah! i see, more timing nuance :)
<slangasek> nacc: I haven't seen a new debdiff for php-imagick. you still working on that one?
<nacc> slangasek: yeah, having issues with my adt-lxc at home
<nacc> slangasek: let me try to resync my base image and start the tests up again
<slangasek> nacc: ok no hurry, just trying to make sure I'm not dropping any balls
<nacc> slangasek: the only thing i've submitted right now is the two patches to php7.0. I'm hoping to have php-proxy-manager and php-zend* fixed today
<slangasek> ok
<slangasek> nacc: do you know anything about this warning?: W: php-mongodb source: pear-package-without-pkg-php-tools-builddep
<nacc> slangasek: i think it's this: https://lintian.debian.org/tags/pear-package-without-pkg-php-tools-builddep.html
<nacc> slangasek: it's part of the debian php7.0 transition, iiuc
<Son_Goku> yeah, as part of the update to php7, most distros are yanking pear specific requirements
<Son_Goku> mainly to kill a couple of circular dependencies that are a pain to resolve when doing a bootstrap upgrade
<Son_Goku> err, a bootstrap of a new php version for an upgrade
<Son_Goku> not for bootstrap the js thingy
<Unit193> Hello.  Is there any specific reason adobe-flashplugin is stuck in partner-proposed?  I don't see it on the update excuses page.
<lamont> cyphermox: smb doko any of you around?
<cyphermox> lamont: yeah
<lamont> wanna play with bind9 / isc-dhcp for me?
<lamont> I'll be uploading to a couple of ppas momentarily
<doko> lamont, where?
<lamont> my ppa, and the maas ppa
<lamont> once it gets any exposure, xenial
<lamont> but zomfg
<lamont> I had to get out a hammer and smash -export back into the code... and I went with "let's not perturb the cleanup work that doko did, because I like that better than the old wya"
<lamont> ISC dropped the --enable-exportlib configure code
 * doko thought that URL were common knowledge ;-P
<lamont> dpkg-shlibdeps: error: couldn't find library libisccc-export.so.140 needed by debian/libisccfg-export140/lib/x86_64-linux-gnu/libisccfg-export.so.140.3.0 (ELF format: 'elf64-x86-64'; RPATH: '')
<lamont> bah and bother
<lamont> oh haha
<lamont> and then, this weekend maybe (hahaha), I plan to roll to 9.10.3.dfsg.P4, because it's out
<dasjoe> xnox: hey, come join us in #zfsonlinux ;) Never seen somebody with a s390x use it
<xnox> dasjoe, well... ssssh
<xnox> =)
<slangasek> nacc: well, lintian locally gives me all the same information as that webpage about the message, was wondering if you knew that the message was a false-positive and why
<tjaalton> nacc: I can sponsor libcommons-lang-java
<nacc> tjaalton: ok, it looks like an obvious tweak to me and the generated jar seems correct now
<tjaalton> nacc: yep
<lamont> cyphermox: https://launchpad.net/~lamont/+archive/ubuntu/ppa/+build/9360619
<lamont> still building, and once it finishes, I'll upload isc-dhcp
<nacc> slangasek: ok, so the php-zeta-console-tools failure is ... not quite clear to me as being a real issue. That is, what is failing is the test is doing a variable assignment like: $table[][0]->format = "test", where $table is of type ezcConsoleTable, which inherits from ArrayAccess
<nacc> that, in turn, implicitly calls getOffset() for the $table variable
<nacc> getOffset is declared as getOffset($offset)
<nacc> but, it seems like when [] is used, $offset is empty
<nacc> so it can't be accessed and throws an error
<slangasek> nacc: I can help you bludgeon C compilers to get php to build, and dredge a path through p-m to get it into the archive; but I have remained blissfully ignorant of all changes to the PHP language's semantics for the past decade
<nacc> slangasek: yeah, i'm just not sure it's a "new" failure, as we weren't running the tests at build-time before the version we just picked up
<nacc> slangasek: is it possible for me to see the autopkgtst results for 1.7-1?
<tjaalton> nacc: uploaded
<slangasek> nacc: http://autopkgtest.ubuntu.com/packages/p/php-zeta-console-tools/ ?
<slangasek> nacc: seems it passed with php5 5.6.17+dfsg-3ubuntu1, and fails before and after
<nacc> slangasek: indeed
<nacc> i wish i knew what "bug #10710" is referring to
<ubottu> bug 10710 in Ubuntu "linux86: FTBFS on amd64: elksemu's file format not recognized." [High,Fix released] https://launchpad.net/bugs/10710
<nacc> err, sorry, it's definitely *not* referring to that :)
<nacc> slangasek: asking on their IRC channel
<nacc> slangasek: would you be able to review LP: #1543803? to fix my AWS error
<ubottu> Launchpad bug 1543803 in aws-sdk-for-php (Ubuntu) "Sync aws-sdk-for-php 3.14.2-1 (universe) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1543803
<nacc> slangasek: that's one of the two holdups for php-monolog
<Logan> hey pitti - chef 12.3.0-3 fixes the FTBFS on rebuild, but I'm not sure if it's safe to sync over your delta (or whether it should be merged)
<slangasek> nacc: yeah, still on my todo list
<lamont> doko cyphermox smb blake_r bind9 built, and isc-dhcp uploaded to https://launchpad.net/~lamont/+archive/ubuntu/ppa/+packages ( blake_r also to experimental3).  pls to test
<pitti> Logan: see debian bug 798618, looks like it wasn't applied in Debian yet, so it needs merging
<ubottu> Debian bug 798618 in chef "chef-client: autopkgtest race condition" [Normal,Open] http://bugs.debian.org/798618
<Logan> pitti: ok, mind if I grab the merge in that case?
<pitti> Logan: of course I don't mind, thank you!
<Logan> of course :)
<Logan> hmm, spoke too soon. the package needs to reduce its dependency on the plist gem as well :|
<smb> lamont, Right now I only see bind9 there. But since yesterday's tomorrow just became today, I will have a look in a few hours
<nacc> slangasek: fyi, the php-zeta-console-tools is a bug in php, fixed upstream, narrowing it down now
<lamont> heh
<lamont> smb: /me typoed the upload url :(
<lamont> _now_ it's uploaded
<lamont> and building
#ubuntu-devel 2016-03-17
<nacc> slangasek: ugh, upstream php7.0.4 does not show the problem. very confused right now, will debug it tmrw
<nacc> slangasek: could be a configure option we're passing
<slangasek> nacc: because of course a language should behave differently depending on the configure options you pass at build time ;)
<nacc> slangasek: i'm hopeful that's not it, but then i'm not sure what it is
<slangasek> nacc: slight adjustment to the versioning, it should actually be 3.15.1.is.really.2.8.27-0ubuntu1 (you had 3.15.1-1.is.really.2.8.27-1ubuntu1)
<slangasek> nacc: actually I'm going to make this 3.15.1.is.really.2.8.27-1~build1 to declare that there is no delta and it's ok to autosync later from Debian
<slangasek> nacc: php-monolog will need an upload to adjust its versioned build-dep; the new package is compatible but will have a version that sorts >> 3, since version numbers in the archive only go up
<slangasek> nacc: I'll go ahead and upload that change onw
<slangasek> now
<nacc> slangasek: ah thanks! yep, that makes sense
<nacc> slangasek: sorry, first time i'd encountered that, appreciate your uhelp
<nacc> slangasek: and i think it is a configure-time bug in our php :/ ... i just ran ./configure w/o any options and it didn't show the bug
<slangasek> hahahaha
<nacc> slangasek: it *could* theoretically point at something in a library, i guess, but upstream php-zeta-console-tools dev tested with 7.0.3/7.0.4 and 7.1.0-dev and they all passed
<nacc> slangasek: so i'm 99% sure it's the configure
<nacc> slangasek: ah maybe not as bad, running `./debian/rules dh_auto_configure; make install` also did not show the error. So maybe it's some compile time option we're passing in debian/rules ... will pick it up tmrw
<slangasek> nacc: php-common also breaks: the version of php-mongodb we have
<slangasek> not sure why that is when there's no php-mongodb package yet anywhere in Debian; ohwell
<nacc> slangasek: that is odd; do you want me to spin up a debdiff?
<slangasek> nacc: nah I'll sort it out, just giving you a headsup
<nacc> slangasek: thanks, i appreciate it
<slangasek> nacc: stupid dependency boolean tricks: https://launchpad.net/ubuntu/+source/php-monolog/1.17.2-1ubuntu2
<nacc> slangasek: ah ok, thanks!
<nacc> slangasek: i think the issue for symfony (at least the first one) is that it needs to not run the same tests (online,network,tty,benchmark,intl-data) that the build avoids
<nacc> slangasek: that will resolve the two failures i see in the logs, i think
<nacc> slangasek: nm, i was looking at an old log! :/
<Son_Goku> nacc: oh, the monster...
<nacc> slangasek: i *think* we'll want to bump or cherry-pick from 2.7.10
<nacc> slangasek: but i will need to look at the diff, etc
<nacc> alternatively, like you suggested before, we could look to sync from experimental
<nacc> that would need a FFe, of course
<nacc> but based upon upstream changelog, all of 2.7.10 is bugfixes
<nacc> so that might be the safest course
<Son_Goku> nacc: why not just save yourself the trouble and sync to 2.7.10?
<sarnold> Latest Upstreams are _always_ the Best Available And Has No Bugs[tm] :)
<nacc> Son_Goku: it's not a sync, it's a merge, so it's a bit more work; and because i have to do a ffe and verify all the changes are not going to break something :)
<Unit193> â¢
<nacc> heh
<Son_Goku> ugh
<Son_Goku> okay
<Son_Goku> well, using 2.7.10 means that itâll be easier to cherrypick from 2.8 later on, when you have to
<nacc> Son_Goku: agreed, and i think that's probably our best course of action, as it will unstick symfony's dependencies in the archive ... but would rather consider that at the beginnign of my day rather than the end :)
<Son_Goku> the only reason Iâm not advocating for symfony 2.8 is because it breaks too many peopleâs projects simply because of the version number bump
<Son_Goku> I spent way too much time fixing composer files and direct file require references trying to use 2.8 than I ever should have
<Son_Goku> just because the company I work for practically depends on it, doesnât mean I like mucking around in it
<Son_Goku> Iâve learned way too many terrible things in my quest to figure out how much stuff breaks with php7
<sarnold> find . -type f -exec sed -i 's/2.7/2.8/g' {}\; #YOLO
<Son_Goku> sarnold: the saddest part about it is that it didnât work :(
<Son_Goku> at the end of it all, the application was busted
<Son_Goku> damn people and their lack of foresight
<sarnold> Son_Goku: aww :( that's frustrating
<Son_Goku> one of the terrible, terrible downsides to every language having their own package manager is that now people are coding strictly to specific versions or git commits
<Son_Goku> because no tolerance in your software A Good Thing(TM)
<Son_Goku> the situation got bad enough in Fedora land that we had to walk back from our policy of blocking bundling by default
<sarnold> ow :/
<Son_Goku> patches to improve system integration or work with newer versions of software were rejected by upstreams repeatedly, simply because they âdonât careâ and that new versions are âFedoraâs problemâ
<Son_Goku> Iâm lucky enough to work on packages where I donât have upstreams like that
<Son_Goku> but man, the worst examples of this are chromium and owncloud
<sarnold> vendorizing all the things is probably going to be on some visionary genius's slidedeck in five years when the future realizes that the amount of technical debt that has been built into every service ever is too large to overcome
<Son_Goku> the biggest irony of owncloud is that theyâre run by former SUSE/openSUSE engineers
<Son_Goku> and SUSE themselves donât allow ownCloud into their core repos
<Son_Goku> every time the system integration issue is brought up, they want people to spin up OBS appliances and interconnect to manage their flavorâs packaging
<Son_Goku> Iâm all for using a nice build system and all, but their attitude is terrible
<Son_Goku> this is one of the big reasons I donât like Docker
<Son_Goku> note that Docker != containers
<Son_Goku> maybe Iâm an old fogie, but I remember when all the distros were burned because of zlib
<sarnold> that one was -painful-
<Son_Goku> youâre telling me
<Son_Goku> to this day, Iâm *still* not sure if all of that is gone
<Son_Goku> Iâm only 24, but I remember when it happened
<Son_Goku> and holy crap the fallout was horrible
<sarnold> heh I bet you're right..
<sarnold> heartbleed made front page of newspapers and yet something like 1/3 of the docker images in the world still don't have that one fixed
<Son_Goku> the bullshit about Alpine Linux only encourages it
<Son_Goku> because guess what you have to do when thereâs nothing in your container rootfs?
<sarnold> vendorize!
 * Son_Goku sighs
<Son_Goku> itâs not helping that all the enterprise distros are gunning for this weird space
<Son_Goku> Red Hat with Atomic, Canonical with Ubuntu Snappy, SUSE with JeOS, Docker with Alpine Linux, etc
<Son_Goku> and yes, Iâm counting Docker as a distro vendor now
<Son_Goku> because they effectively took over stewardship of Alpine
<Son_Goku> oh joy
<Son_Goku> netsplit hell
<Son_Goku> sarnold: I think that like OpenStack, people are going to hit the gas pedal too hard
<Son_Goku> and then when they realize they landed in some disgusting stuff, the pendulum will swing again
<Son_Goku> I barely give a pass on Chromium for the bundling thing because they have some semi-legit reasons for it
<Son_Goku> but holy hell, look at how many bundled() Provides it has: https://spot.fedorapeople.org/chromium.spec
<sarnold> yeah.. I just recently bought a decent machine that I intend to use for vms (among other things), and I just can't bring myself to contemplate installing openstack on the thing. I'd rather have a dozen small shell scripts than a dozen privileged daemons with gross apis and on and on..
<Son_Goku> likeâ¦ WHY do you need your own GTK+3?!
<Son_Goku> and thenâ¦ zlib
<Son_Goku> sarnold: I have spent two months trying to properly set up OpenStack
<Son_Goku> not only can I not get it working (and I like to think Iâm reasonably competent as a Linux user/admin/developer/etc)
<sarnold> # Bundled bits (I'm sure I've missed some)
<Son_Goku> but every time I try, more of me dies inside because of the sheer overengineered complexity thatâs in it
<Son_Goku> I just use oVirt now
<Son_Goku> my own personal sandbox where I do all my crazy stuff is an oVirt system
<Son_Goku> itâs ~15 minutes to set up, and It Just Works(TM)
<Son_Goku> something that the world likes to forget about, these days
<Son_Goku> most of my php7.0 package dev work and testing has been on the oVirt system
<Son_Goku> I have Ubuntu 16.04-dev, Fedora 23 (with remi php70 scl), and CentOS 7 (with remi php70 scl) for testing and development
<Son_Goku> Iâll probably throw in openSUSE Tumbleweed and Mageia Cauldron to round out my testing
<Son_Goku> sarnold: but yeah, if youâre looking to make a nice little ESXi-like VM environment, I highly recommend oVirt
<Son_Goku> it works great, itâs FOSS, and itâs not complicated!
<Son_Goku> actually, does Ubuntu have an equivalent to Fedoraâs bundled() Provides?
<sarnold> not that I know of
<Son_Goku> hmm
<Son_Goku> it comes in handy for my automated auditing with a shitty shell script
<sarnold> the debian security team has a bundled listing somewhere, but it's not particularly easy to updae
<Son_Goku> eck
<Son_Goku> I once tried to make virtual Provides like the ones Iâm used to when I make RPMs for Fedora/Mageia
<Son_Goku> on Ubuntu
<Son_Goku> Iâve never seen apt blow up in such strange ways
<Son_Goku> apparently, itâs a really stupid idea to load up on virtual Provides
<sarnold> oh my :) yeah, I think the easiest way out of that is to start over..
<Son_Goku> I always wondered why there werenât things like âlibgcc_s.so.1()(64bit)â as Provides and Requires (names independent of package names)
<Son_Goku> then I tried it and found out why
<Son_Goku> sarnold: also, apparently you can break the apt db and the repo metadata by doing stuff like that
<Son_Goku> it doesnât handle it very well :P
<sarnold> hehe yeah, apt assumes everyone doing packaging has learned the debian secret handshakes
<Son_Goku> I donât think Iâll ever learn those
<Son_Goku> Iâve been doing packaging for almost 8 years
<Son_Goku> when I first started using Ubuntu back in 2005, I was surprised to see that it chose a Debian base
<Son_Goku> I found out that Mark Shuttleworth was a former Debian maintainer a few years later, and the pieces fell into place :)
<Son_Goku> sarnold: I feel old when I think about stuff like this
<Son_Goku> Iâve witnessed the rise of Linux
<Son_Goku> and I had a (very) small hand in some of that
<sarnold> Son_Goku: heh, I was around for the very end of the a.out -> ELF transition..
<Son_Goku> I came in just after that, I think
<Son_Goku> I was there for the transition from LinuxThreads to NPTL, though
<sarnold> woot :) not bad for 24, hehe
<Son_Goku> the COFF->ELF transition was one I was glad to miss though
<Son_Goku> but yeah
<Son_Goku> I think in some ways the biggest disappointment was that the Linux communities never made it so have common tools across all distributions
<Son_Goku> the LSB attempted it, but with how little distros followed it, it didnât matter
<Son_Goku> today, the closest weâre getting is with systemd, which is forcing distros to stop being special snowflakes in some respects
<Son_Goku> making it easier to make portable applications that donât require vendoring
<slangasek> the LSB never understood that double-dipping by charging both OSVs and distro vendors for certification was a failed funding model
<sarnold> and there's just no denying that insserv was annoying :)
<slangasek> insserv was never a required LSB interface
<sarnold> that was -optional- and people opted into it? oof :)
<slangasek> applications were required to support the various LSB pseudoheaders in their init scripts in order to be compliant; OS implementors could freely ignore that
<sarnold> interesting
<Son_Goku> ironically, it might be easier for me now to come up with a baseline for compatibility than it would have been for the LSB a decade ago
<slangasek> nacc: alright, php-aws-sdk is still uninstallable, because php-guzzle was removed (LP: #1543808)
<ubottu> Launchpad bug 1543808 in php-guzzle (Ubuntu) "Please consider dropping php-guzzle from Ubuntu Xenial" [Wishlist,Fix released] https://launchpad.net/bugs/1543808
<Son_Goku> sarnold: if I were to sit down for a month (or rather, be allowed to do that and not work), I could probably put together a basic definition of what a Linux system is supposed to have to be compatible
<Son_Goku> but really, what actually has to happen is that the distros themselves need to stop making âspecial snowflakeâ decisions and actually do some unifying on their own
<sarnold> didn't lennart already do that? :)
<hallyn> pitti: so on http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.41-1.dsc the testcases fail in debian bc they rely on the memory cgroup which is not enabled there by default;  is there
<Son_Goku> sarnold: he capitulated way too much early on
<hallyn> pitti: a link showing the proper way to ask 'please reboot with the 'cgroup_enable=memory' boot argument' ?
<Son_Goku> systemd actually has a lot of things to deal with debianisms, suseisms, etc.
<Son_Goku> the only distros I know of that got rid of their âismsâ to adopt it was Fedora, Mageia, Arch, and a few ânewbieâ distros
<Son_Goku> the Upstart->systemd move was quite painful in Fedora 15
<Son_Goku> of course, you guys got all the benefit of that pain, many years later :)
 * hallyn does the dance of joy
 * hallyn brushes away some of the copious sarcasm
<Son_Goku> sarnold: I donât know if you know this, but there was actually an attempt to make a package manager that supported both rpms and debs on a single system
<Son_Goku> single database, handling all the package types, repos, etc.
<sarnold> yikes that sounds terrible
<Son_Goku> well, itâs the rpm5 project
<Son_Goku> the guy is of the firm belief that having a division in packaging systems only hurts the community
<Son_Goku> so he made it his goal to introduce support for both packaging systems in RPM5
<Son_Goku> which he did
<Son_Goku> heâs employed by the Yocto Project, who uses his fork of rpm for their stuff
<sarnold> I'm reminded of https://xkcd.com/927/
<Son_Goku> yep
<Son_Goku> I canât say I disagree with Jeff on his belief
<Son_Goku> but I think his approach was wrong
 * hallyn didn't even have to load that xkcd to know what it was gonna be
<Son_Goku> because he managed to alienate everyone in the process of that
<Son_Goku> there was even LWN articles about his project :P
<sarnold> hallyn :)
<Son_Goku> the most annoying part is that he took over the project page for RPM on launchpad
<Son_Goku> so now itâs chock full of bugs and discussions that are completely non-relevant to the project that actually controls that page
<hallyn> rpm5 webpage tells me it's ~relaunched~
<Son_Goku> I know
<Son_Goku> he did that on purpose
<Son_Goku> when Red Hat let him go, he did that
<Son_Goku> but itâs aggravating because rpm5 controls https://launchpad.net/rpm despite everything
<Son_Goku> people file bugs about the rpm in ubuntu, but no one deals with it, because the rpm5 people donât give a damn
<Son_Goku> hallyn: the rpm5 project is geared towards merging the capabilities of apt/yum, rpm, and dpkg into a unified rpm
<Son_Goku> it can even replace reprepro, createrepo, etc.
<hallyn> what about ebuild :)
<Son_Goku> it has rudimentary capabilities for that too
<Umeaboy> Hi!
<Son_Goku> it can download sources and compile them automatically in chroots and stuff like that
<Son_Goku> itâs got a lot more capabilities than the main rpm
<Umeaboy> I've just installed Xenial in my laptop and besides having no Swedish keyboard activated in the keyboard settings (both in the installation and in the booted system) everything runs just fine. No crash so far.
<Son_Goku> hallyn: of course, now it has mongodb integration, so I donât know what to think anymore
<Umeaboy> Only thing I want to ask about is a translation that I'm doing for Xenial.
<Umeaboy> I can use #launchpad if that's preferred, but I just want to hear what you guys think.
<Umeaboy> <strong>Pidgin</strong> <span>Internet messenger</span>
<Umeaboy> The part of Internet Messenger, should that be translated into my language?
<Umeaboy> It's a bit tricky to get it accurate.
<Son_Goku> isnât it an âInstant messengerâ?
<Umeaboy> Yeah, but in Swedish that's a bit hard to translate.
<Umeaboy> That's why I'm asking.
<Umeaboy> And YES, I'm Swedish.
<Son_Goku> Umeaboy: I think Iâve met you before
<Umeaboy> Yeah.
<Umeaboy> You have.
<Son_Goku> in #Mageia, right?
<Umeaboy> Yeah.
<Son_Goku> you probably shouldnât translate the âinternet messengerâ bit
<Son_Goku> because itâs part of Pidginâs title
<Umeaboy> Right.
<Umeaboy> My thought as well.
<Umeaboy> I was thinking about translating into "Meddelandeklienten"
<rlaager> Son_Goku: The name of the application (upstream) is just Pidgin. I believe it's Ubuntu that's adding "Internet messenger". I don't think we use that name upstream at all. I assume Ubuntu used "Internet" instead of "instant" for legal reasons.
<rlaager> Likewise, on my system, the menu icon says "Firefox Web Browser", but the name of the application upstream is just Firefox.
<Umeaboy> rlaager: Yeah, that's just plain irritating.
<rlaager> Umeaboy: What's irritating? The extra words in the Ubuntu menus?
<Umeaboy> rlaager: Yeah.
<Umeaboy> I know WHY, but............
<Umeaboy> It's like I in Swedish say That brown ball of meat to a Meatball.
<Umeaboy> It's like you're talking to a 2 year old.
<Umeaboy> Simple can be TO simple as well.
<Umeaboy> I wish we had a choice during the installation how we want our menus.
<Umeaboy> Just like you can do in Android
<Umeaboy> Regular touch desktop or Simple Touchwiz.
<Umeaboy> Simplified Touchwiz that is.
<Umeaboy> I'll just leave it then I guess.
<Umeaboy> rlaager and Son_Goku: What about the part for ubiquity-slideshow-ubuntu: Bienvenue!
<Umeaboy> ?
<Umeaboy> I know it's in French, but am I supposed to translate thoose sentances or words?
<Umeaboy> I have a feeling as to what they are used for, but I want to be sure.
<rlaager> Umeaboy: I don't have any guidance there. I'm not an Ubuntu developer and I'm not familiar with that application.
<Umeaboy> OK.
<sarnold> i have a vague memory of the slideshow saying 'welcome' in many languages
<rlaager> sarnold: Everyone loves copying Apple, don't they? ;)
<sarnold> rlaager: it's entirely possible that that's what I'm remembering :)
<Umeaboy> sarnold: Are you sure you didn't copy the thought of that from someone else?
<Umeaboy> ;)
<bipul> Can anyone help me to get the output: for ((;;)); do tail -f /var/log/kern.log | a=$(grep -E "wlan0: authenticated" | tail -c21) | echo $a  ; done
<cpaelzer> good morning
<dholbach> good morning
<pitti> Good morning
<pitti> hallyn: sorry, I'm missing context here -- buliding the .dsc fails because debian's buildds don't enable the memory cgroup? this would be either the arch specific porter lists (https://lists.debian.org/ports.html) or perhaps https://lists.debian.org/debian-dak/
<pitti> hallyn: or is that for autopkgtests? in Debian they currently run in a container, but at least enabling some kernel option there is much simpler/less contentious
<pitti> wgrant: meh, since yesterday our scalingstack instances are one big "timed out waiting for ssh" sorryness
<pitti> and "INFO: task sshd:659 blocked for more than 120 seconds."
<pitti> known?
<cjwatson> pitti: lgw01 is undergoing maintenance; lcy01 doesn't seem too awful
<pitti> this affects all three clouds
<cjwatson> pitti: though there was an incident yesterday that took it down
<cjwatson> (lcy01 that is)
<cjwatson> pitti: I think you'll need to check directly with IS then; LP builders are not broken across the board
<pitti> cjwatson: ack, thanks
<cjwatson> (I think)
<pitti> just wanted to check before as there's no vanguard ATM
<pitti> right, lgw doesn't respond, so if that's known, I won't report that again
<cjwatson> it's having surgery done on its mysql
 * pitti blames the vivid backported 3.19.0-57-generic kernel
<pitti> apw: the vivid 3.19.0-57.63 kernel update is completely broken :(
<pitti> apw: http://paste.ubuntu.com/15406752/
<lamont> doko: smb ppa:lamont/ppa for your isc-dhcp testing fun, if you would be so kind.  Once I wake up, I'll bump versions and upload to xenial
<doko> ta, thanks
<smb> lamont, I just copied your bind over to a ppa of mine to add isc-dhcp later
<lamont> kewl
 * lamont had some things come up that kept him from sleeping tonight, so he fought the battle to the conclusion.
<lamont> otoh, too sleepy to be confident in my testing, nor do I have a trivially easy test setup for dhcp
<doko> Mirv, libinput needs a merge, xserver-xorg-input-libinput is dep-wait
<smb> Does not sound that good
<wgrant> pitti: lgw01 is back.
<wgrant> After some mysql hackery.
<smb> lamont, Oh I saw you actually just uploaded a new version of isc-dhcp of yours. I was not sure you would be awake to do so
<lamont> I did
<lamont> that one built locally (needed a new lib for 9.10)
<smb> I see (just reading the changelog)
<lamont> smb: thanks for that work, btw
<lamont> n.b., all I did was make it not ftbfs.
<lamont> but Ihave every reason to believe that it by damn well better fix the bugs
<smb> lamont, yw. Heh, yeah, unfortunately that was not obvious before :)
<Mirv> doko: you might mean that to tjaalton?
<lamont> smb: do not, if you value your keyboard or sanity, read debian/apply-export-patch in the bind9 tree.. you have been warned
<doko> Mirv, ohh, crap, I do ... :-/
<pitti> wgrant: yay, thanks for notifying; reenabling
<wgrant> pitti: I misread LP logs, it may not actually be working yet.
<wgrant> But if it's not working then you may be able to get more details as to why.
<pitti> wgrant: well, I can talk to it; absolute-limits is still as wrong as before, but at least it's back alive somehow
<wgrant> (we don't have logs from lgw01 because lgw01 is entertaining)
<smb> lamont, Bah, thats the kind of "warning" to lure people of just doing that... :-P I try to don a tin foil hat before doing so ...
<wgrant> Right.
<tjaalton> doko: oh right
<wgrant> Let me know if you can/can't start instancecs.
<lamont> smb: :D
<doko> tjaalton, and a 1.2.2 seems to be out
<lamont> smb: I took a really really big hammer and just beat the living hell out of that square peg until it fit.
<tjaalton> doko: yes updating it atm
<pitti> wgrant: right, "server building" is hanging, it's stuck in scheduling/NOSTATE
<smb> lamont, ugh... Looking forward to see what I avoided to do... Also sounds a bit like you should forward a bill to isc for fixing what they wanted to be paid a year ago...
<pitti> apw: I purged all linux-meta test requests from  the vivid queues FYI, so they'll stay in "MISS" forever on your side
<apw> pitti, ahh did we lose the vivid hosts ... damn
<lamont> smb it's a configure run, followed by a pair of for looped sed commands with a patch run in between...
<lamont> tbf, I could have moved the patch run, but ... HAMMER
<smb> lamont, yay! (half-hearted) :) At least good you did not use grep
<lamont> smb: it didn't make it into the script. :p
<smb> So we do not need  a Claymore on top of the hammer
<lamont> heh
<lamont> smb: not as long as the dhcp bugs are fixe
<lamont> d
<lamont> also, thanks isc for dropping the --enable-exportlib code
<lamont> and yes, I'll be grumbling at my isc contacts
<lamont> but not until next week
<lamont> smb: doko isc-dhcp is built, waiting for publication
<smb> lamont, ack
<lamont> and sleep for me.!!
<smb> Heh, I think that you better do on your own for yourself
<seb128> dholbach, just curious, that u-m-w update, how did you reconstruct the update package? patched the old version and renamed the dir? or unpackaged the new tarball and moved the debian dir over?
<smb> Hm... to my testing 1 of 2 problems solved
<seb128> dholbach, also I would have guided flexiondotorg to do it the proper way so next requests can be more easily handled :p
<flexiondotorg> seb128, I have been so guided :-)
<seb128> flexiondotorg, sorry but those diff + tarball sponsoring requests are just not easy to reconstruct/sponsor
<seb128> you should better add the dsc/diff|debian.tar.gz/orig
<flexiondotorg> seb128, Understodd and future sponsoring requests will be more sponsor friendly.
<seb128> thanks
<smb> doko, So it looks like dhcp lease renewal works now, but I think the signal handling still is an issue. I see the normal kill being noticed (strace attached) but looks like it still refuses to do something ...
<dholbach> seb128, very easy: downloaded old package and debdiff, applied it
<dholbach> seb128, but I said to flexiondotorg that a link to a .dsc file in a ppa would maybe be more straight-forward
<seb128> dholbach, right, I did that, but then you can't really review the packaging diff and there is no garanty there is no cruft over what a proper tarball unpack + diff would have done
<seb128> oh well, I guess they can fix fallover from that workflow if there are some
<dholbach> next time, ppa upload :)
<seb128> or dsc/diff.gz to the bug
<seb128> that works as well
<cjwatson> flexiondotorg: when you're reassigning bugs to ubiquity, please could you reassign them to the ubiquity package in Ubuntu, not to the ubiquity project in Launchpad (which we use for code hosting, but not for bug tracking)?  I've been reassigning them on but it gets tedious
<flexiondotorg> cjwatson, Sure, what is the correct project name?
<cjwatson> flexiondotorg: the ubiquity package in Ubuntu, as I said
<cjwatson> flexiondotorg: as in, "also affects distribution/package", not "also affects project", etc.
<flexiondotorg> Thanks, that's the clue I needed.
<cjwatson> cheers
<lamont> smb: as for delving deeper into the crazy, I suspect that y'all are as familiar with the relevant code as I am...   I'd prefer to let foundations go crazy with it :(
<lamont> smb: anyway, I'll be back to waking status in about 5 hours, will upload the non ~foo versions then, hopefully with whatever fixes you come up with in the mean time...
<lamont> ta
<smb> lamont, Hm, we will see how much that is but have a good night (had hoped you may already have)
<lamont> there was driving involved.
<lamont> and the "huh, let me try to punt this to foundations" thought brought me back.. now I'm off to actual sleep.
<smb> heh
<wgrant> pitti: Should be fixed for real now.
<pitti> wgrant: yay, works indeed, thanks
<pitti> queues will appreciate the horsepower
<juliank> The test failure of apt on i386 was flakyness again, and should be ignored. I just made the test a bit less flaky, we'll see how well that works in the next upload.
<xnox> pitti, autopackagetest ENOQUOTA
<pitti> xnox: it should be much better now that lgw01 is  back, queues are catching up fast
<pitti> they were broken since last night for various reasons
<xnox> right, but i see adt logs having errors "30 out of 30 cpus used" and thus failing everything.
<pitti> xnox: that's mostly harmless, they'll auto-retry
<xnox> ok
<pitti> xnox: that happens if there are several "big" tests running which use an m1.large instead of the normal small
<pitti> thus they  block more cores
<pitti> (linux, binutils)
<pitti> plus, lcy01's db is off again and claiming that I use more resources than I actually do
<roaksoax>  /win 13
<smoser> pitti, i have (at least) one more question.
<smoser> i suspect that if i'm running on an add event, that even in an import i cannot update rules that would be executed later.
<smoser> heres what i'm interested in doing.
<infinity> juliank: iz migrated now.
<cjwatson> infinity: oh dear
<cjwatson> we haven't had time to re-sign PPAs yet
<smoser>  a.) add event fires a rule in place by cloud-init that runs cloud-init-name-device via import
<cjwatson> I guess we're about to get a support firestorm
<smoser>    that blocks until i've found information on what devices should be named
<smoser>  b.) i want to allow nic device name assignment based on something other than MAC (for example 'ID_NET_NAME_PATH' might be something)
<smoser> so i'm going to end up with some language for saying "ID_NET_NAME_PATH=enp0s25 NAME=foo0"
<smoser> which looks a lot like udev rules. so rather than using writing another parser, i'd like to re-use udev rules. but in order to do that i'd have to create or update a rules file that [possibly] did not exist when this event started.
<smoser> ie, i'd like for cloud-init-local to write /etc/udev/rules.d/70-persistent-net.rules
<infinity> cjwatson: Oh.  A blocking bug might have been nice.  If only the guy who wrote that feature was an LP dev.
<cjwatson> infinity: I didn't realise it was going to start happening quite so soon :P
<cjwatson> juliank: bug 1558331 - looks like synaptic's handling of warnings causes confusion
<ubottu> bug 1558331 in apt (Ubuntu) "After upgrading to apt 1.2.7 in Xenial, PPAs and most other third-party repositories become unusable with "The repository is insufficiently signed by key (weak digest)"" [Undecided,Confirmed] https://launchpad.net/bugs/1558331
<cjwatson> (if you read the bug log closely, it looks as though PPAs aren't actually unusable, but synaptic displays warnings as errors and makes it look as though they will be)
<infinity> cjwatson: I've noticed sbuild's temp repo is also goofycakes with the new apt.  Should we just switch that to [trusted=yes] for apt >> XX and be done with it?
<infinity> (Thankfully, sbuild's just noisy, it doesn't fail)
<cjwatson> infinity: there was some debate about that in a bug somewhere, I forget the details
<juliank> cjwatson: Yeah, the warning system is somewhat confusing.
<juliank> With 1.2.8 it gets better
<juliank> As it then shows the actual errors as E:
<infinity> cjwatson: Well, signing on the same system that turns around and reads the archive is snakeoil at best.  trusted=yes is obviously smarter in that case, but needs to be branched based on the version of apt in the target chroot until we no longer care about old apt.
<cjwatson> infinity: sure, I get that, but signing with --digest-algo SHA512 might be an easier temporary fix
<infinity> cjwatson: Oh, true.
<cjwatson> that should work even with prettyarchaic gpg
<juliank> cjwatson: Could a rebuild of all PPAs be triggered after your digest algo change is in? Is that possible?
<infinity> Anything's possible, but I bet republishing all active PPAs would take a few days.
<cjwatson> juliank: still need to work that out, a full rerun of everything would be extremely slow but it may be possible to have a job that just re-signs everything
<infinity> (rough order of magnitude guess)
<juliank> It won't hurt not to do it, though, then users might notice some inactive PPAs
<cjwatson> this is a pretty strict definition of "inactive"
<infinity> juliank: "inactive" doesn't imply "bad".
<juliank> Well, if they add a xenial repo after the patch is done, they won't have an issue.
<cjwatson> it should be possible to just go through and run the Release step on everything
<juliank> they = the PPA owners
<cjwatson> but I need to work out the details
<juliank> I don't think there's a huge amount of xenial PPAs for end users yet
<infinity> You underestimate how popular PPAs are. :)
<juliank> I even have PPAs on my Debian system!
<juliank> works OKish
<cjwatson> if my query isn't completely wrong there are at least 1440 PPAs with xenial publications
<cjwatson> we definitely want to do something in bulk
<juliank> Oh, and the Chrome repository generator is fixed on Google's side now; so that should start working with the next Chrome (pre-)release
<juliank> I also think now that we have warnings for the SHA1 signed release files, there's no need to turn them into errors for 16.10, we can just turn them into errors everywhere on January 1.
<juliank> Which is the same time frame the web browsers have.
<juliank> (one stable update for xenial, one for xenial+1; and an upload to xenial + 2)
<juliank> On the other hand, I could also make the code a time bomb that automatically knocks it off on Jan 1
<cjwatson> timebombs are terrible, you then get to deal with mis-set clocks etc.
<rbasak> Also a package bump with a changelog entry is less surprising as an explanation of changed behaviour.
<juliank> Yeah. It's also declarative now, a timebomb wouldn't...
 * juliank has a table digest id => (trust state, name)
<juliank> APT does not trust any digest in the private/implementation-defined range
<juliank> only the SHA2 ones and the reserved ones in the official range
<juliank> starting with 1.2.8
<juliank> (1.2.7 would have also accepted digest algorithms in the private range)
<xnox> pitti, is it possible to ignore spl-linux "regressions"? as far as I can see linux package builtin module is loaded, instead of the dkms module and then test fails.
<xnox> it's an automatic dkms test or some such.
<pitti> xnox: ah, we had this case with another package already indeed
<pitti> yeah, http://autopkgtest.ubuntu.com/packages/s/spl-linux/xenial/amd64 doesn't look very good
<pitti> xnox: will hint
<pitti> xnox: in fact we already have a hint, it just needs its version bumped :)
<xnox> pitti, thank you. And were is the test comming from? i guess we should be able to force use the dkms module, over the built-in one to make the tests test the dkms....
<pitti> xnox: from /usr/lib/dkms/dkms-autopkgtest
<xnox> pitti, tah.
<xnox> pitti, so dkms-autopkgtest can setup a wrapper script around dkms to call `dkms --force "$@"`, or e.g. dkms script could be modified to accept environment variable DKMS_FORCE= or some such. what would you prefer?
<xnox> (then modules will be "force" installed by dkms, and we can test that they actually succeed)
<pitti> xnox: maybe
<pitti> xnox: but maybe the better thing would be to remove the dkms packages for which we already ship the modules in our kernel?
<xnox> pitti, we will not.
<xnox> =)
<xnox> pitti, e.g. dkms package is arch:all, and in case of spl we pre-compile it only for some arches, not all.
<pitti> ok
<pitti> xnox: env variable sounds a bit difficult as that's called via apt -> dpkg -> postinst
<pitti> xnox: so I guess dkms-autopkgtest would need to drop a config file somewhere?
<pitti> wrapping sounds ok too, but then we don't really test dkms
<pitti> we want to see what these packages actually *do* on installation
<pitti> smoser: this language (map some properties to a name) is pretty much what .link files are, no?
<pitti> smoser: /lib/systemd/network/99-default.link is the default if there are no more specific rules, but anything earlier than that can define its own name based on properties, and will then be handled by 80-net-setup-link.rules
<xnox> pitti, yeah i'm not sure what should happen when a person does an active choice to install spl-dkms, e.g. whether or not it should or shouldn't shadow kernel built-in spl.ko.
<smoser> pitti, yeah. that might work.
<smoser> pitti, i like it. the only thing i dont like is that it ties me even more to systemd
<pitti> smoser: this is udev stuff, so it'll work under upstart or sysv all the same
<pitti> but it does tie you to >= vivid (or so)
<pitti> smoser: anyway, you can equally well use udev rules for that, it's not a big difference
<pitti> in both cases you need to have the rules in place before the network device gets detected
<smoser> are you sure ?
<pitti> well, once a network device appears you need to name it somehow, and once the event is processed that name i s set
<pitti> you can change it on the next boot of course, but one must not start using the name in any configuration by then
<smoser> pitti, right. but i think with systemd.link via /lib/udev/rules.d/80-net-setup-link.rules i can probably manage to populate that directory *during* the event, just prior to 80
<smoser> as it uses IMPORT. as long as 'builtin' reads the directory when the rule is processed (the same way it seems to for IMPORT{program}
<pitti> yeah, that could work
<pitti> adding rules while a rule is being processed most probably doesn't
<smoser> yeah, i'm pretty sure it doesnt.
<smoser> pitti, not a huge deal i dont think, but i'm almost certain that 'wait_for_interface' in /lib/udev/ifupdown-hotplug is completely bogus.
<smoser>  read state /sys/class/net/$interface/operstate
<smoser> does not populate 'state' variable from the contents of read state /sys/class/net/$interface/operstate
<smoser> that *should* say
<smoser>  read state < /sys/class/net/$interface/operstate
<smoser> the former just does a read from stdin and returns error, never setting 'state'
<pitti> smoser: maybe; this isn't being used for anything except lo under !systemd, so I doubt it's being tested
<smoser> yeah, i dont think its a big deal in reality
<smoser> but its completely broken if anyone ever expected it to work
<pitti> right
<pitti> smoser: actually, the only reason to even have this wrapper is the systemd-escape --template for ifnames with funny chars
<pitti> otherwise the udev rule could just directly say ENV{SYSTEMD_WANTS}+=ifup%<something>.service
<smoser> well, you said the wrapper would be needed to avoid dead ifup@non-auto-interface
<pitti> right, that too
<smoser> what funny names are there ?
<pitti> well, someone might decide that they want an interface with / or @ or a space in the name
<pitti> (which arguably is just making your life hard, but we at least shoudln't crash on it)
<xnox> it will get systemd-encoded no?
<xnox> ah right, mentioned above.
<xnox> one can name interface names using UTF-8 characters and it totally works.
<xnox> kernel is totally happy with network interface called å¥½
<xnox> very good name
<nacc> slangasek: right, i'll work on that next -- i remember that now
<blake_r> lamont: isc-dhcp is doing something wierd it keeps losing connection to its failover peer
<blake_r> lamont: it didnt use to do this
<nacc> tjaalton: did that fix to commons-lang-java also unbreak pki?
<tjaalton> nacc: yes
<nacc> tjaalton: great!
<tjaalton> thanks
<nacc> slangasek: it looks like, possibly, the zeta-console-tools is because we've disabled some normally built-in extension in the debian/ubuntu builds. I've got the list from ondrej and am now debugging
<blake_r> lamont: also stop using SIGTERM is still broken
<blake_r> lamont: I have to do SIGKILL which is nasty for the failover
<infinity> blake_r: This is known.
<infinity> blake_r: And being worked on.
<blake_r> infinity: yeah lamont was working on it and wanted me to test
<blake_r> infinity: is someone else working on it
<infinity> blake_r: Ahh, you're testing a PPA or something?  Nevermind, then.
<slangasek> xnox: do you name your interfaces å¥½ and ä¸å¥½?
<lamont> infinity: ppa in prep for xenial upload... it's less broken, but I was hoping smb or doko or cyphermox would have more info for us
<smb> lamont, if you wait a little maybe I have
<infinity> lamont: "Less broken" instills such amazing confidence.
<xnox> slangasek, i have had a double decoding bug, renaming my interfaces like that. And i was like "it can't be, and it totally is working"
<smb> lamont, I am currently doing local test builds
<xnox> slangasek,  å¥½ and ä¸å¥½ are awesome names for e.g. veth pair for a container =)
<smb> infinity, at least it did do some work while only still not stop doing it when you wanted to
<lamont> infinity: the first report was that 1 of 2 bugs appeared fixed. :/
<infinity> lamont: The bug I care about is the kill/term one.  Though, if there are others, I'm all for them all being fixed. :P
<lamont> infinity: the other one had to do with not handing out leases, iirc
<smb> infinity, unfortunately that was the one not fixed
 * smb wonders whether he talks to a different room
<infinity> If we fail to fix that one, we're going to have to hack around it with a late shutdown job that does killall dhclient.  Which is vile.  So let's not.
<infinity> smb: I'm seeing you. :P
<smb> infinity, thank deity! :-P
<lamont> smb: and we're getting into the area where I'm not fully up to speed on the code that dhcp is using, so I'm kinda leaning on y'all here...
<lamont> not just because I'm a touch sleep deprived atm
<smb> lamont, I am suspecting some code in bind lib/isc/unix/app.c
<lamont> smb: this would not surprise me
<smb> lamont, but let me finish the test builds and then I could ask you to confirm I am not completely crazy (only half)
<lamont> ta
<lamont> poke me if I can help with any of it
 * lamont goes to his meeting
<infinity> smb: Given your size, is your half crazy the same volume as my full crazy?
<blake_r> lamont: the failover connection also seems to be going in and out, something that I saw before these issues occurred
<smb> infinity, guess it depends on the square of distance or so
<infinity> smb: Well, the question is if relative crazy or absolute crazy is the more interesting measure.
<lamont> blake_r: I suspect that's related to the signals, but yeah
<smb> infinity, that kindo of gets us into half-a-bee territory :-P
<infinity> Bzzzzzzz!
<maswan> smb: but half infinity is still infinity
<infinity> maswan: I think you've just solved all my time management issues.  Fetch me a saw.
<smb> but then on the other hand there is no more crazy than inifinite crazy... So half of mine never can not be anywhere near (no matter of size)
<nacc> slangasek: ugh, i'm super frustrated by this, but the maze of dependencies (and really old versions of various components) means i think the simplest answer is to put php-guzzle back in. is that feasible?
<nacc> slangasek: i think the only reason we will need it is for this runtime dependency for aws-sdk-for-php
<nacc> slangasek: as php-opencloud 2.0 uses php-guzzlehttp
<nacc> slangasek: LP: #1543807
<ubottu> Launchpad bug 1543807 in php-opencloud (Ubuntu) "[FFe] upgrade to php-opencloud 2.0.0" [Wishlist,New] https://launchpad.net/bugs/1543807
<nacc> slangasek: then again, we could *not* move php-opencloud up, if php-guzzle is around
<nacc> i hate carrying around a fully deprecated and unmaintained package, but these packages are a nightmare to untangle
<smb> infinity, do you happen do remember to number of the dhclient is ignoring me part of the problem
<infinity> smb: That sentence no English.
<smb> infinity, at least those are English words. :-P
<infinity> smb: There were many English words, yes.
<smb> infinity, what I meant there is the dhclient does not terminate problem
<infinity> smb: They just didn't sentence correctly.
<smb> infinity, the one you are interested in getting fixed. I just cannot remember which bug number that was
<infinity> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1556175
<ubottu> Launchpad bug 1556175 in isc-dhcp (Ubuntu) "networking.service hangs on shutdown -- killing dhclient has no effect any more" [High,Triaged]
<smb> infinity, coold thanks
<smb> So I can add the correct closing codes to the changelog
<infinity> smb: Does that mean you've fixed it?
<slangasek> nacc: do you have a php7-compatible php-guzzle? the lack of compatibility was why it was removed
<slangasek> nacc: my handwavy guess was that it was going to be better to port php-aws-sdk to php-guzzlehttp
<smb> infinity, I think I have. Though I will let lamont have double check the change
<nacc> slangasek: well ... we *could* port. that's why we were updating php-aws-sdk :)
<nacc> slangasek: and it's almost impossilbe to figure out what to backport
<infinity> smb: \o/
<nacc> slangasek: as i think we'd be backporting basically all of v3 of the SDK (lots of changes upstream)
<smb> infinity, seems slightly crazy to fix signal processing not working by removing parts that install signal handlers
<nacc> slangasek: but let me keep digging
<infinity> smb: That does sound potentially sketchy.
<smb> infinity, though effectively that is exactly how things where before upstream tried magics with the lib.
<infinity> smb: Right, sounds sketchy on both counts.  Removing a signal handler is often a sign your doing something wrong, but I'd argue that adding one to a client library is also a sign you've done something wrong. :P
<infinity> smb: (Unless you've taught all the applications that link to it how to deal with the new world order)
<smb> infinity, Right, which seems to be the little detail upstream did not care (enough)...
<infinity> smb: The question is if removing the handler for dhcp's sake then breaks bind.
<infinity> smb: Unless you're doing this in a dhcp-only build of the library.
<smb> infinity, Oh I basically added a if (!isc_bind9) -> don't care about that
<smb> right
<infinity> smb: Right, that seems potentially reasonable then.
<nacc> slangasek: as to symfony, i do think we'll want to update to 2.7.10, that will pick up several bugfixes, and allow for compat with php-proxy-manager 2.0
<lamont> smb: looking now
<smb> lamont, I need 1 more minutes , sorry
<lamont> np
<hallyn> pitti: for autopkgtests, yes.
<flexiondotorg> Is there something "wrong" with the xenial archive?
<flexiondotorg> I can see new version of packages actually in the directory structure.
<flexiondotorg> But apt-get update and apt-cache show is not finding these newer versions.
<mitya57> flexiondotorg, be more precise? which package?
<flexiondotorg> ubuntu-mate-welcome was one I was interested in.
<flexiondotorg> 16.04.4 is in published, but only 16.04.3 is discoverable.
<flexiondotorg> gstreamer-plugins-1.0-bad is uninstallable as weel.
<mitya57> flexiondotorg, ubuntu-mate-welcome was published today, maybe your mirror is not yet updatedâ¦
<infinity> flexiondotorg: ubuntu-mate-welcome looks there to... What mitya57 said.
<infinity> flexiondotorg: Are you using a Canonical mirror, or a downstream, or a proxy?
<flexiondotorg> OK, I'll check what mirror I'm using.
<mitya57> And gst-plugins-bad1.0 was published *only* 25 minutes ago, and not even migrated to release yet.
<nacc> slangasek: ok, i can confirm that, based upon my testing, php-guzzle really is incompatible with php7 (curl issues, minimally)
<nacc> slangasek: i'm going to ask the monolog maintainer about their dep
<slangasek> nacc: ok. fwiw I'm context switching out the php stuff at this point since I don't see anything for me to do on it without diving into upstream code; but as soon as you have anything that wants sponsoring (or just review), just poke me
<nacc> slangasek: yep, will do, thanks!
<nacc> slangasek: have a (relatively) quick question for you, if you're available
<nacc> slangasek: I *think* I have a way forward for php-monolog, but would like to understand if it's acceptable. It sounds like the only reason there is a build-dep on php-aws-sdk is to run the tests. So we *could* skip the tests, or intentionally fail those tests (the runtime throws an error) and catch that error appropriately.
<slangasek> nacc: shoot
<nacc> slangasek: if we could keep the previously sync'd version of php-aws-sdk :/
<nacc> slangasek: so much churn, i'm really sorry
<slangasek> nacc: ok, we can certainly restore it (with a funky version number now), but that version was also not viable - you have fixes now for it?
<nacc> slangasek: ok, so my understadning of why php-aws-sdk didn't work was strictly this php-monolog issue
<nacc> as it's the only dependency in the archive on it
<slangasek> nacc: do you believe php-monolog will be compatible with the new php-aws-sdk package?
<nacc> slangasek: oh i see what you're asking
<nacc> slangasek: so no, php-monolog is not compatible (afaict) with v3 of the API. But an upstream contributor basically says that "versioned dependency" in the composer.json is only there so the tests run. The runtime will leverage AWS if you want it to, but it's no a key part of the functionality, if that makes sense?
<nacc> slangasek: i'm asking upstream for more clarity on what they'd recommend here
<nacc> slangasek: v2 of the SDK is explicitly not PHP7 compatible (due to php-guzzle not being PHP7 compatible)
<slangasek> nacc: right. so before we re-uplift php-aws-sdk, I want to make sure we have a solution for php-monolog, whatever it is - because downgrading aws-sdk a second time would be exceptionally painful :)
<nacc> slangasek: yep, understood, i just wanted to clarify what is possible or not
<nacc> slangasek: i'm not going to suggest antyhing until i get clarity from upstream
<slangasek> ok
<superm1> cyphermox: slangasek, any intentions on moving to mokutil 0.3 instead of 0.2?  it looked like it's changed now to use system efivar rather than an old embedded library along with tons of fixing on issues
<nacc> slangasek: can you explain to my why php-mongodb hasn't proceeded to release?
<slangasek> nacc: because of the php-defaults breaks, I think
<slangasek> nacc: so new php-defaults needs to go in first
<slangasek> superm1: hadn't made any plans around it; are there specific issues that are fixed that you're concerned about?
<nacc> slangasek: ok, my current tentative suggestion is: re-uplift php-aws-sdk; remove build-dep in php-monolog which will skip tests. Not ideal, but from interacting with upstream, the AWS usecase is quite small (for monolog)
<nacc> slangasek: hrm, i can chdist install both?
<slangasek> nacc: the php-common from xenial, plus the php-mongodb from xenial-proposed?
<cyphermox> superm1: does 0.3 better handle non-interactiveness
<superm1> slangasek: there's been a variety of odd issues that got fixed directly in efivar the past few months related to how it built up and parsed efi variables.  they've affected both fwupdate and efibootmgr directly.  i haven't directly seen any issues with mokutil myself that mirrored the type of stuff that happened in efivar
<nacc> slangasek: ah ha! that's it, sorry, i was using the php-common from proposed as well, which is waiting right now
<cyphermox> superm1: sounds worth checking out, I've noticed some issues with setting validation
<superm1> cyphermox: it does have some different import mechanisms
<teward> is anyone else having issues editing things on the wiki?
 * teward can't even edit his own page
<teward> nevermind, i just had to logout and login again :)
<sarnold> teward: the details are that you were added to the new group that is required for editing privilegs, but the wiki doesn't notice until you logout and in again
<teward> sarnold: indeed.
<teward> weird that this didn't present yesterday
<teward> and only today
 * teward shrugs
<sarnold> odd indeed, I needed tio be added to the group several days ago
<superm1> cyphermox: https://launchpad.net/~superm1/+archive/ubuntu/uefi/+build/9364737 mokutil 0.3.0 if you want to see if it helps your validation issues.  if you decide to go with it, there are some compile warnings that cause FTBFS on i386 with current toolchain, so might need to be more closely investigated
<cyphermox> superm1: cool, thanks
<teward> I had a poke from someone wondering if the 'unified ping' (ping / ping6) changes from Debian were incorporated into Ubuntu for Xenial, does anyone know offhand?
 * teward isn't sure how to answer it
<teward> ooo, I see, Debian made that change in iputils to unify the ping and ping6 items, and uploaded after featurefreeze
<teward> makes sense :P
<superm1> cyphermox: pretty sure this will fix the FTBFS on i386 too: https://github.com/lcp/mokutil/commit/cdb4b6f3bfd6ada6558ddfb889e27150f0841b28
<nacc> slangasek: i don't have much experience with importing new upstrema versions, and am ahving some trouble with symfony 2.7.10 and importing it. I'm following the instructions in debian/README.source but I'm not sure how I regenerate the license information for the images; and then I'm getting a dh_php failure afterwards; would you be able to help me understand what is needed?
<slangasek> nacc: you want 2.7.10 specifically? I see 2.8.3 is available
<slangasek> nacc: if you were going to 2.8.3, you would just run 'uscan && uupdate'
<slangasek> nacc: for 2.7.10, you want to download the tarball manually, and then use uupdate
<slangasek> oh, but the watch file doesn't handle source mangling for us?
<slangasek> haaaaate
<nacc> slangasek: i *think* 2.7.10 is a safer upgrade ... 2.8.3 introduces some functional changes, afaict, and 2.7.10 will get us proxy-manager 2.0 compliance
<nacc> slangasek: not only that, the watch file is syntactically wrong
<nacc> it uses \d
<nacc> rather than \d+ :)
<nacc> so it doesn't even see 2.7.10
<slangasek> ah, heh
<slangasek> nacc: escape hatch, because Debian already has 2.8.2 in experimental we probably will never have a 2.7.10 tarball in Debian so we don't have to worry about checksum mismatches. So we assume that we can create our own orig.tar.gz with impunity. as for licensing, I only know what I read in that same debian/README.source
<slangasek> nacc: I would try the script that they provide, and cross-reference with licensecheck
<nacc> slangasek: ok, good to know, let me try with uupdate
<nacc> slangasek: Pharaoh_Atem also indicate the version chagne for symfony breaks lots of tools (2.7 -> 2.8), so i think we'd rather avoid it if we can
 * slangasek nods
<lamont> doko: http://bugs.debian.org/818541 :p
<ubottu> Debian bug 818541 in libbind-dev "libbind-dev: arch-dependent files in "Multi-Arch: same" package" [Important,Open]
<nacc> slangasek: can you confirm something for me? does symfony fail to build for you with dh-php in the archive?
<slangasek> nacc: the current symfony and dh-php packages in the archive?
<nacc> slangasek: yeah -- i have a log locally of it working with dh-php 0.5, but with dh-php 0.10, i'm getting an error
<sarnold> pitti: can you please take a look at 1558823? thanks ;)
<nacc> slangasek: so i think 0.10 removed "auto-configuration" and ... so symfony won't build
<slangasek> nacc: I see it failing to build with test failures
<slangasek> nacc: http://paste.ubuntu.com/15410975/
<slangasek> not sure if that's related to the auto-configuration you mention
<nacc> slangasek: hrm, with dh_php 0.10? I get: "dh_php: .php configuration file is needed for dh_php"
<slangasek> yes
<slangasek> it is, however, building without xenial-proposed enabled
<slangasek> should I try that?
<nacc> slangasek: ah ambye that's the differnce
<nacc> yeah i'm using proposed
<slangasek> ok, checking
<nacc> slangasek: hrm, I got a failure without proposed too
<nacc> weird!
<slangasek> nacc: ah, interesting.  And this is symfony 2.7.9+dfsg-1ubuntu2 ?
<slangasek> nacc: I see the same failure with either xenial or xenial-proposed
<nacc> slangasek: the testcase failure you pasted above?
<slangasek> nacc: yes
<nacc> slangasek: i'm pulling down the source again to be sure i'm not carrying osme bad state somehow
<nacc> slangasek: ugh, i apologize, it must have been something stale in my repository ... will debug it
<nacc> s/repository/system
<slangasek> ok :)
<nacc> slangasek: ah ha! i see why now
<nacc> slangasek: ok, so in my case, i'm still trying to figure out how to update the licenses
<nacc> so i passed DEB_BUILD_OPTIONS=nocheck to skip the license check for now
<nacc> slangasek: but that also skips the tests :)
<slangasek> ah ;)
<nacc> slangasek: ah, but symfony 2.8.2 in experimental does have the fix for your testcase failure
<nacc> slangasek: ok,i'll need to spend more time on this to figure out wehther we hsould just go to symfony 2.8.2 like you said earlier; but that adds a new source & binary requiremeint, php-symfony-polyfill (although I think our version can be trimmed down significantly since we aren't going to support php5)
<slangasek> I think php-symfony-polyfill is already in Ubuntu, but stuck in -proposed?
<nacc> slangasek: ah i see, probably needs some updates to use the right deps
<Logan> doko: looks like gmp-gcc4 is failing to rebuild due to the new inclusion of -Wdate-time in dpkg-buildflags (which GCC 4.7 doesn't support, apparently)
<slangasek> Logan: adjust the package to filter it out of the buildflags?
<slangasek> (or drop the package, because gcc4?)
<Logan> I didn't want to touch it without doko's approval since he created the split for Xenial
<Logan> I guess it has some legacy rdeps
<slangasek> the worst that can happen is that you're permanently TIL ;)
<Logan> the horror!
<nacc> slangasek: ok, debdiff posted in LP: #1558848 for polyfill
<ubottu> Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/1558848
<nacc> builds & passes test here
<nacc> with that in, i'll look at testing the debian version of symfony, i think
<nacc> slangasek: could you possibly kick php-symfony-security-acl's build? I think it should build now
#ubuntu-devel 2016-03-18
<slangasek> nacc: it's already built, htree days ago
<slangasek> but the autopkgtests failed
<nacc> slangasek: nm, php-symfony-security & php-symfony-security-acl are going to conflict unless we move up to a 2.8 level of symfony
<nacc> slangasek: yeah, the failure is the conflict
<slangasek> ok
<nacc> so that's another reason to move up to 2.8.2
<nacc> slangasek: sigh, it's another bootstrap case, i think
<nacc> slangasek: symfony 2.8.2 needs phpy-symfony-security-acl to build, which needs php-symfony-security to build
<nacc> specifically php-symfony-security >= 2.8
<smoser> hey.
<smoser> so curtin depends on pyflakes (for make check)
<smoser> it runs pyflakes both in python2 and python3
<smoser> but theres a new 'python3-pyflakes'
<smoser> where as before there was just pyflakes that worked for both
<smoser> what should i write as build depends ?
<smoser> slangasek, ^ i'm sure you can just answer this in 30 seconds.
<smoser> ie, it runs:
<smoser>  python2 -m pyflakes curtin/ tests/unittests/
<smoser> and
<smoser>  python3 -m pyflakes curtin/ tests/unittests/ tests/vmtests/
<smoser> which now results in
<smoser>  /usr/bin/python3: No module named pyflakes
<slangasek> smoser: well, I can guess that you want to build-depend on pyflakes + pyflakes3
<smoser> which previously was satisifed by a depends on pyflakes.
<smoser> but then i can't build on trusty
<smoser> which ENOPYFLAKES3
<slangasek> ok, then you want to build-depend on pyflakes + pyflakes3 | pyflakes (<< 1.1.0-2)
<smoser> ok. the << is what i was missing.
<slangasek> the version should technically be the first version that split the package; but 1.1.0-2 is the current version in xenial which is the first release that has it, so it'll DTRT in all Ubuntu releases
<slangasek> nacc: so how did Debian break this bootstrap loop?
<smoser> slangasek, http://paste.ubuntu.com/15411741/
<smoser> that one fails on trusty
<smoser> in sbuild: http://paste.ubuntu.com/15411746/
<slangasek> smoser: fails how?
<slangasek> ok
<smoser> and when i flipped the order (pyflakes < .. | python3-pyflakes) it failed on xenia.
<slangasek> right
<slangasek> smoser: are you using the same build-dep resolver setting in sbuild that launchpad uses?
<smoser> i do not know
<slangasek> I don't remember which one this is; and you might already have it right yet sbuild is still being unhelpful
<slangasek> I would say that your intent is correct there, and you should throw it at lp and see if LP DTRT
<smoser> well, i've not changed sbuild locally to my knowledge
<smoser> and looking at a random other laucnhpad build lo
<smoser> log
<smoser> https://launchpadlibrarian.net/248521085/buildlog_ubuntu-xenial-amd64.cloud-init_0.7.7~bzr1182+1186+444~ubuntu16.04.1_BUILDING.txt.gz
<smoser> i see: Install core build dependencies (apt-based resolver)
<smoser> (and sbuild says the default resolver is 'apt').
<smoser> so, it would seem that i should be using the same.
<smoser> that said, its past time when i should be looking at this.
<smoser> thank you for your time, slangasek
<smoser> tommorrow maybe. ideally it'd work both on my system *and* launchpad :)
<smoser> hm.. wonder if the fact that there is 'pyflakes3' helps or not. probably not.
<slangasek> nope
<infinity> smoser: sbuild in LP uses --resolve-alternatives, which isn't the default.
<infinity> smoser: slangasek's suggestion should work if you pass that switch.
<nacc> slangasek: no idea (yet)
<hallyn> how can i build a debian sid autopkgtest vm for adt-run to use?
<hallyn> is there a tool like adt-buildvm-ubuntu-cloud to do it?
<nacc> hallyn: do you specifically need a vm rather than lxc?
<hallyn> yes
<nacc> hallyn: hrm, i'm not finding anything, but buildvm-ubuntu-cloud can take an arbitrary url; does debian host cloud images similarly?
<hallyn> need to run the cgmanager autopkgtests , and they requir rebooting the host to enable memory cgroup whic his disabled by default in debian
<nacc> ah
<hallyn> i think they do...  not sure whether similar enough though
<hallyn> i haven't seen any google results suggesting anyone has done this...
<nacc> yeah me either :/
<hallyn> leme ping the debian lxc maintainer
<nacc> hallyn: one hit i found mentioned using vmdebootstrap to setup a debian vm
<hallyn> nacc: url?  (for full argument list).
<hallyn> sounds all right, i assume it just creates the qcow2 and runs debootstrap in there
<nacc> hallyn: yeah looks like it; sadly they didnt' give the command they ran, just that they used it, afaict (https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1400466.html)
<hallyn> maybe /usr/share/autopkgtest/setup-commands/setup-testbed
<hallyn> d'oh
<hallyn> the adt-virt-qemu manpage tells me what i need :)
<hallyn> thanks nacc
<nacc> hallyn: np, that probably should have been more obvious :)
<nacc> slangasek: is it just me or does symphony's autopkgtests not dtrt? that is, there is a debian/tests/phpunit script that I *think* they meant to be running? rather than the system phpunit?
<slangasek> nacc: which version of symfony should I be looking at?
<nacc> slangasek: seems to be the case in all of them
<nacc> slangasek: i guess i'm not sure what that script is supposed to be for, but d/test/control specifycing 'phpunit' won't run the script in d/tests/ afaict
<slangasek> nacc: IIRC it will; debian/tests/control's "Tests" list typically points to scripts under debian/tests
<nacc> slangasek: hrm, ok, i got differing behavior between running that script manually and what autopkgtest said ... but will keep digging
<nacc> slangasek: fwiw, w/ 2.7.10, i'm down to one runtime failure
<nacc> slangasek: i'm wondering, though, if it's a side effect of relatime and/or overlayfs
<nacc> heh, there are bugfixes to this problem (possibly) that went into the kernel today
<nacc> sigh
<nacc> yep, the tests pass with aufs :)
<nacc> slangasek: but then the build fails w/ the message i mentioned earlier ... will need to dig into it to see if it's a regression with dh-php or not
<nacc> slangasek: figured it out! ok, so think if i get the images licenses figured out, i will have a package update for symfony for you tmrw, with FFe
<nacc> slangasek: a bug i introduced, of course :/
<sladen> ~
<Pharaoh_Atem> I really wish that going from symfony 2.7 -> 2.8 didn't break so much crap
<Pharaoh_Atem> but people do versioning in their packages too strictly and depend on internal behaviors just because php lets them easily do so
<Mirv> pitti: good morning. there would be one vivid regression at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-036/excuses.html that can't be retried due to the known bug
<cpaelzer> good morning
<dholbach> good morning
<ginggs> why is it taking so long for launchpad to pick up uploads from debian? it seems to be getting worse and worse
<Odd_Bloke> xnox: apw: This looks like a bug we've already seen come past, but I can't remember the details; could one of you remind me (perhaps by adding a comment to the bug) where we are with all that initrd weirdness?  https://bugs.launchpad.net/cloud-images/+bug/1558260
<ubottu> Launchpad bug 1558260 in cloud-images "unable to boot arm64 cloud images due to initrd" [Undecided,New]
<apw> Odd_Bloke, there is a bug i the cloud image creater process (source unknown at this itme) which drops a bad file in there instead of a link, the kernel though when installed into the image is meant to cope and let us continue in the latest images
<apw> Odd_Bloke, and does not the last comment imply exactly that that it has been resolved in later images ?
<apw> Odd_Bloke, i thought smoser or someone was on the hook for determining when in the process this file cames into existance
<apw> Odd_Bloke, or are you saying it is you, and now :)
<flexiondotorg> I noticed the gstreamer 0.10 plugins -bad and -ugly are no longer in the Xenial archive. Is this a permanent change?
<Odd_Bloke> apw: Yeah, that last comment does imply that, but the bug was only filed yesterday so I was checking that we expected it to be fixed or if the last commentor got lucky. :p
<Odd_Bloke> I'll assign it back to Jeff and ask him to confirm that he still sees it with the latest.
<apw> Odd_Bloke, i am expecting it to have been fixed some time ago, like a week maybe a little more, so it depends how old the previous test was, i didi not look
<Odd_Bloke> Yeah, he didn't specify exactly which image he was using.
<apw> Odd_Bloke, but even when the fixed kernel is in the image, one which has postinst which copes with the bad file and just moved it out, you can tell whether the cloud image is broken still as initrd.old would be a file not a link
<apw> Odd_Bloke, and we do need to find out where that is coming from and why
<apw> Odd_Bloke, it is definaly not right, and *puts finger in air* it feels like it is coming from a curtain-y level of the build
<cjwatson> ginggs: Because Debian just changed a bunch of stuff and we're trying to keep up
<cjwatson> ginggs: https://lists.debian.org/debian-devel-announce/2016/03/msg00006.html
<ginggs> cjwatson: ah, thanks
<doko> smb, "Revert back to bind against bind9 export libraries". did you do that for other rdeps too?
<smb> doko, no only isc-dhcp
<doko> lamont, why does libbind-export-dev ship a libbind9.so (without -export)?
<infinity> doko: Because he oopsed.  Already under investigation.
<doko> infinity, let me do that, so you'll have time for glibc ...
<infinity> doko: Go nuts.  Whatever he did (broken .so at least) led to isc-dhcp being statically linked, so that'll need a rebuild when fixed.
<infinity> doko: Also, the udeb deps are wrong.
<infinity> doko: Enjoy.
<doko> infinity, udeb's are already fixed
<infinity> Yay.
<doko> ok, testing a fix for the symlink issue
<infinity> doko: Make sure shlibs/etc are all sane enough that the dhcp debs (and udebs) actually get correct deps on foo-export.{deb,udeb}
<doko> sure
<infinity> doko: (Which may already be true, but I'm not holding my breath after seeing the result of the current upload)
<lamont> doko: because of bug.
<lamont> doko: ta
<lamont> doko: holler when you have something, and I'll add it to some other cleanup and upload it
<lamont> (git tree is forward from P4-1 because of some patch cleanup and submmission upstream)
<lamont> and I guess I'll be merging
<smoser> hey. i'll ask again, see if anyone has a solution.  python3-pyflakes recently came into existance and that is breaking build of my cloud-init and curtin, which previously Build-Depend on pyflakes.  They'd run pyflakes in both python2 and python3 mode to test validity of both.
<smoser> clearly for xenial i can just add a build-depend on python3-pyflakes, but that will mean i can no longer build on anything earlier than xenial.
<smoser> slangasek suggested depending on 'python3-pyflakes | pyflakes (<< 1.1.0-2)' and on pyflakes. (full debian/control http://paste.ubuntu.com/15411741/).
<smoser> but that fails with http://paste.ubuntu.com/15411746/
<smoser> any thoughts ? do i just have to make two control files now or disable checks.
<rbasak> smoser: you want sbuild --resolve-alternatives
<rbasak> (I think)
<smoser> rbasak, well, maybe. but i'd like for it to work on launchpad too
<rbasak> smoser: it should Just Work on the buildds I believe.
<rbasak> src:php5 had the same need and the buildds were fine.
<smoser> alright. i'll give it a shot.
<cjwatson> Yes, Launchpad uses --resolve-alternatives.
<cjwatson> (as Adam said yesterday)
<smoser> cjwatson, bah. well, i missed that.
<smoser> thank you, rbasak it seems to work.
<mterry> cjwatson: do I recall correctly that we added dbgsym packages to PPAs?
<mterry> aha.   main/debug
<mterry> Thanks!
 * mterry should update some askubuntu questions
<doko> smb, lamont: -1ubuntu2 should fix the known issues. please re-upload isc-dhcp once this is built everywhere
<tjaalton> does apt use repos that don't have the new DEP-11 metadata?
<smb> lamont, Can I leave that ^ to you as I cannot upload much (not isc-dhcp anyways)
<tjaalton> silly question really..
<tjaalton> of course it does, like ppas.. just that apt-mirror seems somewhat broken and doesn't sync/clean stuff like before
<lamont> doko: ok
<lamont> smb: will do
<smb> ok cheers
<lamont> doko: and thanks, I'll get that together and create -2 for e'ryone
<cjwatson> mterry: the bit you may not have found out for yourself is that it depends on PPA settings: "Build debug symbols" and "Publish debug symbols" on "Change details"
<mterry> cjwatson: oh nice ok, thanks
<cjwatson> (this is because debug symbols can be (a) slow to generate and (b) pretty large and would eat into quota on large archives)
<tjaalton> ok so there's an apt-mirror bug 1550852, with patches from my ex-coworker :) (having to maintain the mirror I set up..)
<ubottu> bug 1550852 in apt-mirror (Ubuntu) "apt-mirror does not reflect dep11/Components-* and dep11/icons-*" [Medium,Confirmed] https://launchpad.net/bugs/1550852
<tjaalton> best way to solve issues is to think out loud, publicly..
<jtaylor> doko: interesting approach with pyzmq ... I'd rather see the broken zmq update reverted than tests disabled
<doko> jtaylor, the tests succeed locally (as written in the changelog=. if you can show me how to fail these locally ...  and they were already disabled for mips*
<jtaylor> on amd64 and i386
<jtaylor> they succeed there on buildds too
<jtaylor> its the others that are the problem
<doko> no, they failed on the buildds
<jtaylor> on debian they work
<doko> ... just on x86
<doko> feel free to revert
<jtaylor> exactly
<jtaylor> zmq is somehow broken on all other arches
<jtaylor> zmqs own testsuite just sucks
<jtaylor> how did zmq even get into xenial?
<jtaylor> it went into unstable post feature freeze
<doko> during the ruby2.2 removal
<sinzui> xnox: rbasak : the rebase of the sl90x patch for juju-mongodb2.6 is going to take a lot of effort. I don't think this is worth the effort because this package is to support upgrades from 1.25/mongo-juju, but the Juju team is only supporting juju2 and juju-mongodb3.2 on s390x
<infinity> sinzui: I concur that's probably a reasonable direction to go.  I assume that would also drop powerpc support for 2.6 (which is also fine).
<xnox> sinzui, right. by the way you shouldn't need to rebase s390x patch, just pick the right one from github linux-on-z repositories.
<infinity> sinzui: I lost context long ago on this.  Is juju-mongodb/2.4 going away, or will that *also* be in xenial?
<xnox> sinzui, note that e.g. juju2 is not in ubuntu yet, and juju-core 1.2* in ubuntu xenial is currently using the old mongo.
<sinzui> xnox: I did and it didn't apply cleanly because the package has our ppc64el and arm64 patches on it
<xnox> right
<xnox> sinzui, imho we should try to get mongodb3.2 in, sooner rather than later, at least on s390x, to make sure juju-core 1.25 doesn't use the old mongo.
<infinity> xnox: juju-core has to use the old mongo.
<xnox> bummer
<infinity> xnox: That's the point of the crazy transitional packages.
<xnox> sigh....
<sinzui> infinity: juju-mongodb (2.4) will ne demoted to universe. people upgrading to xenial will still have a juju-core (1.25) to maintain existing deployments
<infinity> But if juju2 absolutely will land for xenial, we should drop s390x/powerpc from juju-core and juju-mongodb.
 * xnox wants juju2 in the archive asap then =) at least on s390x
<xnox> infinity, i have customers using juju-core today =) so we can't drop it, before juju2 lands =)
<sinzui> xnox: me too. The juju release team want juju2 beta3 in xenial.
<infinity> sinzui: See above.  Probbaly after juju2/mongo3.2 are in, but we should drop powerpc (not ppc64el) and s390x from juju-core and juju-mongo in xenial to avoid people being confused and trying to use the old bits.
<sinzui> infinity: understood
<xnox> =/
<xnox> ack
<infinity> sinzui: Has anyone actually talked to the release team about juju2?
<xnox> sinzui, so don't care about s390x on mongodb2.6. Any little people who have been using old juju on s390x, can rebootstrap.
<infinity> sinzui: I've had various CDO people talk to me about things that depend *on* juju2, but I've heard nothing about juju2 timelines.
<xnox> it's all technically non-supported stuff.
<xnox> infinity, is pitti release team at all?
<seb128> xnox, https://launchpad.net/~ubuntu-release/+members
<sinzui> that membership is surprising
<xnox> infinity, so pitti did talk to a few people about all the mongos and jujus
 * xnox ponder mongi / juji ?
<infinity> xnox: Yes, but not specific timelines.  Just the packaging bits.
<infinity> sinzui: Some of those members need to be culled.
<sinzui> infinity: I beleive alexisb has talked to people. in my meetings I have been clear that there is a juju2 package that is co-installable with juju-core
<sinzui> infinity: xnox the Juju team do want to propose the juju2 beta3 next week.
<xnox> sinzui, usually people file FFe bug way ahead of time of landing the thing. Not like "we are ready, file bug and expect it to be reviewed instantly" =)
<sinzui> xnox: I see cherylj did https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913
<ubottu> Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,New]
<cjwatson> Does the lxc failure in http://paste.ubuntu.com/15414988/ ring a bell for anyone?  I just upgraded to lxc 2.0.0~rc11-0ubuntu1 and lxcfs 2.0.0~rc6-0ubuntu1 in xenial
<sinzui> cjwatson: hey, thats my bug from this morning. I didn't get answer. I assumed my two wily hosts had incompatbile packages from the lxd ppa. I downgraded to wily-updates to get back to work
<rbasak> xnox, infinity: I emailed the release team about new versions of Juju during feature freeze once. I didn't think we needed an FFe because that makes no sense given that we do major version bumps after release.
<rbasak> (assuming that we take an appropriate amount of care, etc)
<cjwatson> sinzui: filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1559169
<ubottu> Launchpad bug 1559169 in lxc (Ubuntu) "containers no longer start after upgrade to 2.0.0~rc11-0ubuntu1" [Undecided,New]
<infinity> rbasak: Less about freezes and more about making sure what we ship isn't crap, migration plans (or lack thereof) are not just sane but well tested, blah blah.  Landing everything 2 days before release doesn't instill confidence.
<sinzui> thank you cjwatson
<xnox> rbasak, hm, it is new package.
<rbasak> infinity: sure. Given that Juju releases outside Ubuntu's cycle, and then updates Ubuntu's updates pockets, I sort of see it as independent of Ubuntu's cycle. But that goes both ways, so I think I agree. Because that also means that there shouldn't be any rushing or compromise of quality to make an Ubuntu release.
<infinity> rbasak: Quite.
<infinity> rbasak: The only reason to rush if for marketing fanfare and, honestly, releasing 2.0 a few weeks after 16.04 gets you a less noisy channel to the press.
<infinity> rbasak: So, people should think hard about what they'll actually be landing and when and if it's something they want their name on. :P
<infinity> s/rush if/rush is/
<jamespage> doko, hey - can I steal your last-touched unison merge? current version is causing segfaults and is blocking some HA testing we're doing?
<rbasak> If releasing at the same time as 16.04 is really important, then the deadline should be considered feature freeze.
<infinity> rbasak: Don't disagree.
<rbasak> If feature freeze is missed, then releasing at 16.04 time is at risk.
 * infinity gets back to breaking the freeze.
<ogra_> its spring time anyway ! stop these freeze talks !
<doko> jamespage, please steal everything you like ...
<doko> jamespage, ohh, that even was an unmerged packages by you for two years ... I had just a no-change upload
<jamespage> doko, nope not me
<jamespage> but I'll merge it anyways as it unblocks stuff...
<doko> ahh, jtaylor ... misread
<jtaylor> unison is a mess, it should probably just be removed
<jtaylor> they don't seem to have an compatiblity so whatever is in the archvie stops working on the next upstream version
<rbasak> sinzui: can you add dep3 headers to all the quilt patches you're adding for juju-mongodb 3.2 please? We normally want them anyway, but here there are so many patches we really need them to keep track.
<rbasak> sinzui: http://dep.debian.net/deps/dep3/
<rbasak> sinzui: also, please update the headers for any patch you modify (that isn't just a refresh to unfuzz)
<rbasak> infinity: how do you feel about a juju-mongodb3.2 where Ubuntu's mongodb is still on 2.6?
<rbasak> (Debian is on 2.4 AFAICT)
<infinity> rbasak: I don't care if juju's ahead or behind of the mongodb game, so long as they have a plan to support it.
<rbasak> OK
<rbasak> Reviewing this is fun. I don't have anything to base a diff from :-/
<rbasak> (well, 2.6)
<infinity> rbasak: (And if that plan involves "make the security team deal with it", they should be asked too)
<rbasak> That's an open question at the moment. Juju management are looking into it.
<doko> apw, infinity: autopkgtest for linux 4.4.0-14.30: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression â» , s390x: Pass
<doko>  (triggered by gcc-5). is this a real issue, or can we ignore it?
<rbasak> sinzui: have you checked to see if there are any updates needed to debian/copyright (for both juju-mongodbs)?
<sinzui> rbasak: oh, have I...I removed an entry form the 3.2 because the package was removed from 3rd party
<sinzui> rbasak: I hestitantly offer to go the full dep-5
<rbasak> sinzui: I want to step out of the loop on this one. I'm confident you understand what is required and how to do it, so I think it's best to leave it between you and the archive admin.
<rbasak> That means pitti in this case I think?
<infinity> doko: Gonna give it a kick to retry.  But it looks like it was busted tests (since fixed), not GCC's fault.
<sinzui> understood rbasak
<rbasak> sinzui: dep3 headers I do want though. It's difficult to understand what I'm reviewing without them.
<sinzui> rbasak: yeah, I have that open now
<rbasak> sinzui: basically I want to know where each patch came from and where I can find upstreaming status.
<sinzui> rbasak: okay, understood
<rbasak> (because if we don't track that, packaging inevitably becomes an unmaintainable mess)
<rbasak> Thanks :)
<smb> lamont, ugh that bind9 saga isn't a happy one
<doko> smb, what's still wrong?
<smb> lamont, now its afaict named-checkzone which went into bind9 and bind9utils
<doko> smb, lamont: so I think the best thing would be to install into debian/tmp, not debian/bind9, and have a bind9.install file to exactly say what should be included in bind9
<lamont> smb: gar
<lamont> doko: likely so
 * lamont stares at the build-deps in -1ubuntu2, and wonders if that was really necessary
<lamont> deps actually
<doko> lamont, I was checked for missing libs, because I found one export lib missing in the dh_makeshlibs call in debian/rules
<lamont> makes sense
<lamont> I decided I didn't care enough to change it back
<apw> doko, that looks more like test failure to my eye you might just hit retry and see if it changes, if not i'll ask peeps to look closer
<doko> apw, in fi ni ty already gave it back
<apw> doko, ahh good enough, we shall see when it completes there
<lamont> doko: hoping you have time to do that switch to debian/tmp?  +1 from me on the concept
<xnox> pitti, can i trick you into reviewing https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551952 or are you off already?
<ubottu> Launchpad bug 1551952 in multipath-tools (Ubuntu) "FFE: Please merge multipath-tools 0.5.0+git1.656f8865 from Debian unstable " [Undecided,New]
<doko> lamont, not today; I'll look at it tomorrow
<lamont> ok
<lamont> smb: feedback from isc is that we likely just broke signals for all of the bind tools when we fixed dhcp...
<lamont> so I'll be reworking that diff a bit
<smb> lamont, Hm ok. To me it looked like only bind itself would enter things via isc_app_start (not sure that is the exact name) and everythning else would only have isc_app_ctxstart
<lamont> ah, could be
<nacc> slangasek: filed LP: #1558848, to get symfony through, let me know what you think
 * lamont was just parroting the reply to the patch from isc
<ubottu> Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New] https://launchpad.net/bugs/1558848
<smb> lamont, Yeah, well I cannot be 100% sure. The whole thing is a bit obscure with the two sets of methods in the ctx struct.
<smb> lamont, So not that this is tested or even tried as code but if we need to change it then maybe by adding some #ifdef around that only includes the return if compiled without thread support...
<lamont> smb: likely the way I'll go
<lamont> but it'll be post-sunday
<xnox> doko, can we drop gcc-3.3 and hence libstdc++-5.0 from xenial? =)
<smb> lamont, Yeah, would you think it would be better to hold back with any bind9 upload? Not completely ideal but with a working though statically linked dhclient out this might allow less rushing
 * lamont plans to upload iscdhcp shortly, just waiting on the publisher
<lamont> the other stuff is just "bind9 bugs"
<lamont> I mean, we already have the potential defect there in P4-1
<smb> lamont, yeah but that never went out
<lamont> it's more one of "if someone files a bug about signals being broken in some random bind9 utility, we know root cause already..."
<lamont> hrm
<lamont> this is sad making
<lamont> it may be my today thing after all
<smb> lamont, none of the recent bind9 uploads I mean. The first one because of dependencies and the other becuase of the adt failures
<lamont> smb: ack
<lamont> which is actually cool, beacuse I don't need Replaces. :D
<doko> xnox, can you convince Debian first to drop it?
<doko> it just builds one lib
<smb> lamont, Also you kinda do not have to wait to upload isc-dhcp because there is no reason to
<lamont> smb: it was more of "waiting for 1ubuntu2 to really really be in the archive, but taht was 2 hours ago..
<infinity> smb: "no reason to"?
<smb> lamont, ERm yes, that s what I try to say
<smb> lamont, It wont go there because it annoys britney (I mean ikiwiki-hosting test regression)
<lamont> infinity: no longer a reason to wait
<smb> infinity, Right that was what I meant
<infinity> lamont: Right, I misread as "we don't need to wait" not "the wait is over".
 * lamont got distracted
<lamont> and then went "why do I even have this window open"
<smb> Heh yeah... I just happened to go back there and refresh and then decided that red is not my favourite colour in there
<smb> lamont, Or rather I think I did not mean what you thought I meant...
<lamont> right
<smb> lamont, I meant there is no reason to do the upload...
<nacc> slangasek: and just tested in parallel w/ and w/o the imagemagick ubuntu4 i just posted to LP: #1549942; without the patch it fails the tests on amd64 and with the patch it succeeds.
<ubottu> Launchpad bug 1549942 in ImageMagick "php-imagick failing autopkgtests" [Unknown,New] https://launchpad.net/bugs/1549942
<nacc> slangasek: apologies, I don't know what I had messed up before in my test setup
<smb> lamont, Though it probably does not matter if isc-dhcp now links dynamically it will remains stuck in proposed together with the bind9
<lamont> ack
<nacc> slangasek: i believe we need a rebuild of php-zend-code so that it pulls in php-common rather than php5-common
<nacc> slangasek: but i believe why it's not migrating is symfony
<nacc> slangasek: (via php-proxy-manager)
<nacc> slangasek: i believe the rebuild of php-zend-code isn't strictly required right now (as it will just pull in php5 for now), but will be needed eventually
<nacc> slangasek: ugh, so i buitl php7.0 again from source in s chroot, the test passed; installed php7.0 and it failed, with either the php7.0 or from-source php binaries. So ... maybe a module load issue? continuing to investigate :/
<nacc> slangasek: hrm, it's a php.ini issue, possibly
<Pharaoh_Atem> nacc: what do I need to do to stop being moderated on ubuntu-devel?
<slangasek> nacc: pile of replies for you on bug #1558848; the one that needs action from you is https://bugs.launchpad.net/ubuntu/+source/php-symfony-polyfill/+bug/1558848/comments/12
<ubottu> Launchpad bug 1558848 in symfony (Ubuntu) "symfony: failing autopkgtests" [Undecided,New]
<slangasek> Pharaoh_Atem: become an Ubuntu Developer ;)
<nacc> slangasek: yep, working through them now, thanks!
<Pharaoh_Atem> slangasek: is it anywhere near as hard as becoming a Debian one?
<slangasek> nacc: fwiw we'll want to adjust the symfony upstream version number to 2.7.10+dfsg (Ã  la the existing 2.7.9+dfsg) to make clear this is a modified upstream tarball.  I can address that here
<nacc> slangasek: ah ok, i wasn't sure, since i hadn't run their script to mangle the name.
<nacc> slangasek: also, i just realized i still need to fix the licenses!
<nacc> slangasek: sorry, let me try to get that done now too
<slangasek> Pharaoh_Atem: it's somewhat less process-heavy but involves a fair bit of demonstrating active involvement in the project, plus waiting in queues
 * Pharaoh_Atem sighs
<slangasek> Pharaoh_Atem: being unmoderated on ubuntu-devel is probably not a good argument for becoming an Ubuntu Developer :-)
<nacc> Pharaoh_Atem: would you be able to test something for me on php7.0 in non-ubuntu installations?
<Pharaoh_Atem> nacc: yes
<slangasek> nacc: ok shelving symfony until you re-ping me
 * Pharaoh_Atem is actually updating his testing atm
<Pharaoh_Atem> *test stuff
<nacc> Pharaoh_Atem: http://paste.ubuntu.com/15416746/
<nacc> slangasek: yep, thanks
<nacc> slangasek: php-monolog v2 debdiff posted, thanks
<slangasek> nacc: you tested that autopkgtest works?
<nacc> slangasek: yep
<slangasek> nacc: ok, uploading
<Pharaoh_Atem> nacc: you'd like me to run this as a CLI app or web script?
<nacc> Pharaoh_Atem: cli, please
<flexiondotorg> I missed the details, but am I right in saying syncing with Debian is not currently possible?
<Pharaoh_Atem> okay
<nacc> slangasek: oh, fwiw, i didn't alter upstream in this case, as i made an archive from github
<nacc> slangasek: for symfony, so would we still +dfsg? or would you rather I use uscan to grab the tarball (if I can convince it to get th eright version)
<Pharaoh_Atem> afaik, it wouldn't be dfsg because you're not using the debian one, you've made your own
<slangasek> flexiondotorg: we are past the Debian Import Freeze, so no packages are being automatically synced from Debian; an Ubuntu developer can still manually request a sync ('syncpackage' command); if the new version of the package includes new features, this should be discussed with the release team first per FeatureFreeze
<slangasek> nacc: I would still say +dfsg, if you're deleting things that are part of the upstream tarball
<flexiondotorg> slangasek, Yep, I understand that. My question was not clear enough.
<nacc> slangasek: the orig.tar.gz has no deletions; it was a `git clone`, then `git archive ... v2.7.10` from upstream symfony
<flexiondotorg> slangasek, I do the vast majority of the Ubuntu MATE work in the Debian community as part of the pkg-mate team.
<slangasek> nacc: ok, fine with me then
<flexiondotorg> I have several syncrequests filed, bug fixes.
<flexiondotorg> Those packages are not available in LP.
<flexiondotorg> slangasek, For example - https://launchpad.net/debian/+source/mate-dock-applet
<flexiondotorg> 0.69 in LP and 0.70 in Debian. The Ubuntu dev who looked at my syncerequests was unable to process them.
<slangasek> flexiondotorg: oh, you're asking if syncing is currently broken.  Yes, lp is having import troubles due to the Debian ftp team dropping checksums on experimental; the LP team is working on fixing this
 * Pharaoh_Atem listens to Legend of Zelda music while system updates complete
<slangasek> packages that were in Debian prior to Wednesday-ish are syncable, but new uploads are currently not visible
<flexiondotorg> slangasek, Thanks. That was the deatil I was missing.
<flexiondotorg> Thanks for explaining. I heard something had changed but wasn't aware what exactly.
<nacc> slangasek: ok, updated symfony in teh same bug, passes tests and has licensing information updated (upstream moved from a base64 icon to SVG, so it changed the checksums)
<nacc> slangasek: i believe php-psr-log requires the php-opencloud update, afaict
<Pharaoh_Atem> nacc: http://fpaste.org/342352/83283271/
<nacc> Pharaoh_Atem: sigh, those are bugs too :)
<Pharaoh_Atem> damn it
<nacc> Pharaoh_Atem: so the thing is, if you build upstream PHP 7.0.4
<nacc> Pharaoh_Atem: if you wouldn't mind trying that
<nacc> Pharaoh_Atem: it works fine
<Pharaoh_Atem> I'll give it a go, one sec
<nacc> Pharaoh_Atem: or just passing ./configure w/o any options
<Pharaoh_Atem> that's... bizarre
<nacc> agreed.
<Pharaoh_Atem> nacc: did you get the upstream php 7.0.4 from GitHub or php.net?
<nacc> Pharaoh_Atem: github
<nacc> Pharaoh_Atem: is there a specific difference?
<Pharaoh_Atem> I hope not
 * Pharaoh_Atem is about to check
<nacc> :)
<Pharaoh_Atem> but... knowing them...
<Pharaoh_Atem> I hate people so much
<nacc> Pharaoh_Atem: did you find a difference?
<Pharaoh_Atem> nacc: http://paste.fedoraproject.org/342361/83287411/
<nacc> Pharaoh_Atem: i asked the xdebug maintainer to test the same script and he ran it with upstream 7.0.3, 7.0.4 and 7.1.0-dev and it didnt' throw an error ... so i'm pretty sure it's a bug in the distro buildds, just not surew hat yet
<Pharaoh_Atem> I'm not if these are really diffs or not
<nacc> yeah the textual diff is just lexer output, iiuc
<nacc> the difference in some files being present in Zend/ is a bit worrisome
<nacc> but those might be generated files? (i see configure is also only in 7.0.4)
<Pharaoh_Atem> nacc: yeah, I don't know
<Pharaoh_Atem> nacc: I'm going to compile php 7.0.4 from php.net sources
<nacc> Pharaoh_Atem: thanks, that would be a good check; i'm bisecting through our disable parameters :/
<Pharaoh_Atem> for reference, this is what remi sets it up to be: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L1115
<Pharaoh_Atem> and here's what %configure expands to: https://github.com/remicollet/remirepo/blob/master/scl-php70/php/php.spec#L1115
<Pharaoh_Atem> err
<Pharaoh_Atem> http://paste.fedoraproject.org/342373/45832942/
<Pharaoh_Atem> nacc: so I'm building php now
<nacc> Pharaoh_Atem: right, a big difference is we pass --disable-all on Debian/Ubuntu ... but it seems like it might be in the intersection of the two (debug, rpath? ... neither seem likely)
<Pharaoh_Atem> running make test atm
<Pharaoh_Atem> nacc: welp
<Pharaoh_Atem> nacc: http://paste.fedoraproject.org/342382/14583307/ and http://paste.fedoraproject.org/342381/33065414/
<Pharaoh_Atem> nacc: I don't know what to make of this
<cjwatson> slangasek,flexiondotorg: maybe I should send mail explaining this, since it'll take another few days to sort out
<lamont> infinity: and P4-3 uploaded to really work this time.
<infinity> lamont: Do we need yet another dhcp upload after this bind, or was the last one correct?
<infinity> lamont: Hrm, deps on the previous upload look plausible at least.
 * lamont checked amd64, and it definitely built with -1ubuntu2
<lamont> the only issue with -1ubuntu2 was that it delivered, uh, everything not in bind9 as part of bind9.
<lamont> or at least enough so to make it unusable
<infinity> Oops. :)
<lamont> I didn't do that
<lamont> but I fixed it in -3, by switching to install into debian/tmp and sort things from there
<lamont> complete with --fail-missing on dh_install
<lamont> a bit to hectic in the day for me to care enough to confirm that all the isc-dhcps built with -1ubuntu2, though that should be done to set security at ease (though the deps would likely show that easier...hrm
<lamont> infinity: as long as all the isc-dhcp-servers Depend on multiple -export libs, they're shiny
<infinity> lamont: Right, that's what I confirmed on amd64.
<infinity> lamont: I might poke the other 6 quickly out of paranoia.
<lamont> infinity: I would lovethat
<flexiondotorg> cjwatson, Do you think it likely 16.04 final beta will be delayed due to the Debian archive changes?
<flexiondotorg> I see that 3rd party repositories are not updating on 16.04 daily due to weak digests etc too.
<cjwatson> flexiondotorg: No
<flexiondotorg> OK
<flexiondotorg> Thanks.
<cjwatson> flexiondotorg: syncpackage being broken really just means that perhaps there might have to be a few manual uploads masquerading as syncs (or indeed fakesyncs), which is annoying but not fatal
<cjwatson> flexiondotorg: And there's no reason to expect any particular timeline for third-party repositories to stop sucking, other than PPAs
<cjwatson> flexiondotorg: If it's just a matter of a SHA-1 digest on the signature but the key is otherwise strong enough, then it actually is still accepted, there's just a warning which looks a bit error-like
<flexiondotorg> So it will be required that 3rd party repositories need to adapt to thi new structure.
<cjwatson> flexiondotorg: They need to upgrade their signatures, yes
<cjwatson> flexiondotorg: I wouldn't call it a structural change
<cjwatson> flexiondotorg: In some cases they may have to add stronger checksums to their index files
<flexiondotorg> So, no one using the google-chrome repostiory will get upgrades until Google update their sigs?
<cjwatson> flexiondotorg: Right, but we're told that will happen soon
<cjwatson> flexiondotorg: Also I think it only affects upgrades *from that repository*, as long as you don't mind apt-get update exiting non-zero
<cjwatson> So that seems annoying but not very fatal, and there's every incentive for third-party repository maintainers to sort stuff out
<juliank> flexiondotorg: Chrome was fixed today
<juliank> So, it only warns about the weak signature now, but the files themselves contain the SHA256 values needed to still allow it.
<juliank> I'd expect the warning to be fixed in the next weeks or months as well
<cjwatson> The Google talkplugin repository has the same problem
<cjwatson> Hopefully they have common repository generation code
<flexiondotorg> Well, the non-zero exit code breaks aptdaemon.
<dax> while Google's fixing stuff, adding arch=amd64 to their repository-adding script would be helpful
<dax> (if that didn't happen already, I didn't look recently)
<flexiondotorg> cjwatson, I will contact some 3rd party repo maintainers and make them aware.
<flexiondotorg> cjwatson, So, will all repos need to adopt SHA256 and xz compression? Is that enough?
<flexiondotorg> juliank, Chrome has not been update. Nor Steam.
<flexiondotorg> lso affected, Spotify, Opera, Vivaldi, Insync.
<Unit193> And apt 1.2.8 makes the warnings look less like errors, too.
<Pharaoh_Atem> crap
<Pharaoh_Atem> what the heck happened?
<Pharaoh_Atem> did this sha256 and xz only stuff just take effect?
<juliank> flexiondotorg: Seriously. It has been updated. about 10 hours ago
<juliank> It now only prints one warning instead of 2
<juliank> and this warning is really a warning now, not an error.
<juliank> They actually fixed this yesterday already, but only regenerated their archive today.
<juliank> Unit193: APT 1.2.8 will make errors look like errors to distinguish them from warnings (both were listed as warnings previously)
<Unit193> juliank: Ah, OK.  Noticed you fixed it anyway.  Nice job!
<juliank> cjwatson: I see. I suspect it's done by the same code as the Chrome repo, but given that the plugin was not updated since April, it has no SHA256 yet
<juliank> flexiondotorg: Steam and Opera work just fine
<juliank> They just print a warning, but continue
<juliank> Vivaldi, Insync I don't know about, but I think you also only see the "The repository is insufficiently signed by key" message which means it works
<juliank> With the talkplugin, I think somebody at google would have to run an update manually, as that's practically dead.
<juliank> Vivaldi is OK
<juliank> Insync is OK too
<juliank> They have until January to fix these warnings, I think that's fair.
<juliank> They literally just have to add two arguments to their gpg invocation
<juliank> --digest-algo SHA512 to be precise
<juliank> flexiondotorg: If you experience any other issue, please let me know. With the google repo now half-fixed, aptdaemon should also work correctly again.
<Unit193> juliank: You were looking for people to report broken repos, did you have a page listing them already?
<juliank> Apart from the temporary breakage at Google, there is no real hard breakage, only the soft warnings.
<juliank> I think I'll start a wiki page for tracking this
<flexiondotorg> juliank, Confirm Chrome works. Google Music Manager cause aptdaemon to fail.
<flexiondotorg> juliank, Google Talk plugin causes aptdaemon to fail.
<juliank> Unit193: flexiondotorg: Listed on https://wiki.debian.org/Teams/Apt/Sha1Removal
<cjwatson> flexiondotorg: It's not necessary to adopt xz compression.
<flexiondotorg> cjwatson, So just SHA256 then?
<cjwatson> flexiondotorg: Debian experimental switched to xz only, which meant a bunch of stuff that assumed that there'd always be gz-compressed files broke, but that's unrelated to apt's requirements.
<juliank> I think almost everyone expect Google only has to pass --digest-algo SHA512
<juliank> to gpg
<cjwatson> flexiondotorg: Something stronger than the broken SHA-1, yes.
<juliank> (or 256)
<cjwatson> Or 384, which was the suggestion in one of the LP bugs/MPs
<juliank> Google was incredibly beyond things
<juliank> cjwatson: APT only support 256 and 512
<cjwatson> juliank: Even for digests on signatures?  That's a curious limitation
<juliank> Ah, no, not on signatures
<juliank> I allowed them on signatures :D
<juliank> cjwatson: The gz removal was sort of my fault too...
<cjwatson> There was a suggestion that SHA512 might run into length extension attacks, which AIUI doesn't quite apply to signatures as stated, but 384 should still be plenty strong enough and avoids possible analogues of that
<cjwatson> We haven't quite decided
<cjwatson> juliank: How so?
<juliank> cjwatson: I asked Ganneff if we could try removing MD5 and SHA1, and he did that and .gz :)
<cjwatson> Heh
<cjwatson> Well, like I say, it's been a bit of a hassle but I don't actually think it's wrong
<juliank> But it's limited to experimental, so it should not be that much of a deal unless you just error out completely if exp. does not work
<cjwatson> The code we've run into does :)
<cjwatson> At least some of it
<cjwatson> Yeah, debmirror and gina both want all suites they're operating on to work
<cjwatson> It's possible we might not have noticed the breakage otherwise, so whatever
<juliank> cjwatson: How exactly does aptdaemon fail? aptd is a huge issue, as it (actually python-apt) silently discards all warnings if there's no error.
<juliank> oops
<juliank> flexiondotorg: ^
<juliank> I don't expect that to be a problem, AFAIUI third party repositories get disabled on an update; and a new install would not have any.
<juliank> flexiondotorg: I'll try to get ahold of someone who can fix the repos for Google Talk Plugin and Music Manager next week; maybe some of the chromium guys involved in fixing the Chrome repo know what to do
<Unit193> vbox's repo should likely also be on that page.
<juliank> Unit193: I just added more details, feel free to add vbox
<juliank> I think it's a bit rough now, but it should quickly get better.
<flexiondotorg> juliank, I have a list of 3rd party repos. I'll add them to the Sha1Removal in an hour or two.
<juliank> great :)
<flexiondotorg> I'm using the aptdaemon.gtk3widget
<flexiondotorg> I'll get details of what it causing the exact issue.
<flexiondotorg> Essentially, the install fail because the package can be found. Which suggest the repo update didn't complete.
<flexiondotorg> juliank, This is what I know of.
<flexiondotorg> http://paste.ubuntu.com/15419170/
<flexiondotorg> Some of those are in the OBS.
<flexiondotorg> juliank, I'll test all those via aptdaemon.gtk and document what works and work down. If there is a failure, I'll capture the log.
 * lamont scratches his head at the isc-dhcp apt failure
<nacc> slangasek: can you tell why php-imagick (per autopkgtest) is skipping all the tests on amd64, but not on i386 (e.g.)
<slangasek> nacc: url?
<nacc> slangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php-imagick/20160317_113406@/log.gz
<nacc> slangasek: it seems to ahve started with that one, which was triggered by PHP 7.0.4-5ubuntu2
<nacc> http://autopkgtest.ubuntu.com/packages/p/php-imagick/xenial/amd64/
<slangasek> 251 skipped tests> lol
<slangasek> no, no idea
<nacc> slangasek: running it on my machine, it runs them all
<nacc> slangasek: so i'm not sure what's happening?
<nacc> and it's weird that it ran them on i386
<slangasek> nacc: when you test are you using an adt test runner that gives you a clean env?
<nacc> slangasek: yeah, i am using adt-virt-lxc
<nacc> with a freshly made adt-xenial from earlier today
<slangasek> nacc: well, imagick-3.4.0RC6/tests/skipif.inc tells it to skip all tests if the imagick extension isn't loaded
<slangasek> e.g.
<slangasek> WARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available
<slangasek> and that's listed at install time
<nacc> slangasek: but the d/t/control says to depend on php-imagick
<slangasek> so there you go
<nacc> hrm
<slangasek> seems to be a misbuilt package, php-imagick (3.4.0~rc6-1ubuntu2)
<slangasek> was there a race between the upload of this package and the upload of some of the package helper fixes
<slangasek> ?
<slangasek> nacc: well, also, those are all tests of the old version of php-imagick in xenial; not of the version in xenial-proposed
<nacc> slangasek: yeah, could be ... except for the same package version (only using release pocket), i don't get that error?
<nacc> so i guess it could be race, but that run was from a few hours ago when imagemagick went in
<slangasek> yes, but those tests are all still testing the released version of php-imagick, not the one in -proposed
<nacc> slangasek: right, so am I
<slangasek> so whatever that -1ubuntu2 binary was built with, maybe it's broken
<flexiondotorg> juliank, SpiderOakOne fails.
<nacc> slangasek: my adt runs say both release and proposed are working right now :)
<nacc> "working" => passing tests
<slangasek> nacc: I can definitely reproduce that message here:
<slangasek> Setting up php-imagick (3.4.0~rc6-1ubuntu2) ...
<slangasek> WARNING: Module imagick ini file doesn't exist under /etc/php/7.0/mods-available
<slangasek> nacc: btw, can you tell me how to reproduce the orig.tar.gz you created for symfony, step-by-step?  want to be able to verify its contents
<slangasek> (against upstream)
<slangasek> (one of those sponsorship nit-picky things)
<slangasek> and I definitely get that warning with php-imagick from release, and definitely don't get it with php-imagick from -proposed
<slangasek> so I'll solve this problem by getting the one in -proposed unblocked ;)
<nacc> slangasek: how weird, i got it in my schroot, but not in my lxc
<nacc> slangasek: ok, yeah, that sounds like a plan :)
<nacc> slangasek: yes, one moment
<nacc> slangasek: from a fresh clone of the github tree, `git archive --format=tar.gz -o ../symfony_2.7.10.orig.tar.gz v2.7.10`
<nacc> should do it, I believe
<nacc> slangasek: ah! I see what it is as to why i'm getting different results :) i told adt to build a fresh .deb on accident, so it wasn't using the archive version
<nacc> slangasek: yep, reproduced the skips here now
<slangasek> right :)
<nacc> that's something :)
<juliank> flexiondotorg: OK.
<flexiondotorg> juliank, The irony of SpiderOakOne not working is not lost on me.
<juliank> I've got no idea what that is
<flexiondotorg> But I have good contacts there, so I'll reach out to them.
<flexiondotorg> Zero Knowledge cloud sync.
<flexiondotorg> So, Dropbox but with encryption. Ahem.
<nacc> slangasek: so as far as php-defaults going (which will unstick php-mongodb as well), we've got php-imagick working, php-monolog already migrated (so it passed its test with that version too), php-proxy-manager 2.0.0 works, but won't be migrateable until we bump symfony. php-zeta-base is hung up on php-zeta-console-tools, which is failing that test which I think is a php build bug, but am going to need
<nacc> some time to debug (and is not a key functionality -- and unsure why it's triggering only here if it was something more serious).
<nacc> Pharaoh_Atem: did you reproduce that php upstream does work w/ that test script, then?
<slangasek> nacc: symfony debian/licensing/image-checksums.dcf shows some painful duplication of stanzas, src/Symfony/Bundle/WebProfilerBundle/Resources/views/Collector/twig.html.twig listed about a dozen times.  Seems like we should just delete the trailing duplicates?
<Pharaoh_Atem> nacc: http://fpaste.org/342498/43363145/
<Pharaoh_Atem> yep
<Pharaoh_Atem> looks fine
<slangasek> nacc: oh; except it's with 11 different checksums, what's that about?
<nacc> slangasek: they are actually multiple images
<nacc> slangasek: all in one file
<nacc> slangasek: so each image has its own checksum
<nacc> it used to be two images
<slangasek> ok then
<nacc> and now it's up to 8 or whatever
<nacc> agreed it's ugly, but if you try to break their syntax, the build fails right away :)
<nacc> Pharaoh_Atem: any ideas? :) would you be able to help figure out what's going with this? i'm really trying to focus on the packaging stuff and getting as much migrated as possible
<slangasek> ok, juju deploy fingers, juju deploy ears, juju add-relation la-la-la
<Pharaoh_Atem> nacc: at the moment, I've got no clue, but I'm starting to poke at it
<nacc> ondrej said he'd take a look this weekend too, maybe, but i'm not sure of his availability
<Pharaoh_Atem> I'm going to try to do some looking into it as well
<Pharaoh_Atem> it's super weird
<nacc> Pharaoh_Atem: just to be sure, your local ./php invocation is using an .ini that specifies to report errors, right?
<slangasek> nacc: you've dropped the use of dh-php in debian/rules, but the build-dep is still listed in debian/control; should be purged, I think? also, your debian/rules drops the delta for implementing stage1/nocheck?
<Pharaoh_Atem> nacc: that's... a good question
<nacc> slangasek: you're right on the first, for sure
<nacc> slangasek: and you're right, i should have merged fully, sorry, wnat me to update?
<slangasek> nacc: yes please
<nacc> slangasek: ok, give me a few minutes
<Pharaoh_Atem> nacc: how can I tell
<Pharaoh_Atem> nacc: the default value for displaying errors is "On"
<nacc> Pharaoh_Atem: ok, i noticed an odd behavior that if i didn't have anything in /etc/php/7.0/cli/php.ini (e.g. renamed to php.ini.bak), no error was reported
<nacc> with my system-installed php
<Pharaoh_Atem> ah
<Pharaoh_Atem> maybe it's not reading my php.ini
<nacc> slangasek: new tarball and dsc uploaded
<slangasek> nacc: got it, thanks.  I also see that composer.json lists a require for symfony/polyfill-apcu, which was the bootstrapping question from earlier.  The 'requires' here isn't going to break the image build, or leave us with a package that builds but doesn't dtrt at runtime?
<slangasek> maybe one or more of the 800+ skipped tests
<slangasek> nacc: ah, and I'm dropping debian/patches/Embed-paragonie-random_compat-into-the-security-comp.patch and debian/patches/cherrypick_5d433cab.patch from the source, in addition to dropping from debian/patches/series
<slangasek> nacc: and I guess there are no refs to polyfill in the source, so ok
<nacc> slangasek: i did not see any such issue, but let me check again
<nacc> slangasek: polyfill is supposed to be for dealing with backporting php features to old version of php by symfony
<slangasek> nacc: PS I hate symfony's testsuite, it leaves my /tmp full of junk
<nacc> which we shouldn't need regardless
<nacc> slangasek: ah sorry, i thought i had done that d/patches, yes, absolutely fine to remote them
<nacc> slangasek: so the only reference in the source that i could find to polyfill-apcu was src/Symfony/Component/ClassLoader/composer.json, and those tests passed (although it did skip 30 of them, i'll look)
<nacc> slangasek: but you're right about that, it will not be installable (php-symfony-class-loader)
<nacc> let me investigate a bit
<flexiondotorg> juliank, Everything tested. Only hard fails are from Google Talk, Google Music and SpiderOakOne.
<flexiondotorg> juliank, I'll contact SpiderOak and you contact Google?
<flexiondotorg> That is of course, just back on the 3rd party repositories I make use of in Software Boutique.
<nacc> slangasek: ok, so i *think* that we can remove that for our case
<nacc> slangasek: it's purely there to support symfony on php5
<nacc> slangasek: but we have the apcu fucntions from php7 itself, so there's no need to rely on the backported versions
<juliank> flexiondotorg: Google is contacted
<juliank> Contact your SpiderOak contacts :)
<nacc> slangasek: at runtime, the ClassLoader/ApcUniversalClassLoader function dtrt and simply checks if acpu_fetch is defined and throws an error if it's not
<flexiondotorg> juliank, Wilco.
<nacc> it will be in our case
<nacc> slangasek: i wonder if we should tranlate that to just php-apcu, though
#ubuntu-devel 2016-03-19
<slangasek> nacc: ack.  I don't think the composer.json needs changing given that nothing complained during the build; we'll see how it gets on with p-m, https://launchpad.net/ubuntu/+source/symfony/2.7.10-0ubuntu1
<slangasek> nacc: oh, now, turns out the php-symfony-class-loader package does end up with a binary dep on php-symfony-polyfill-apcu - so that does need fixed
<slangasek> nacc: sorry, didn't notice that before upload; you can throw me a debdiff or I can fix it here
<nacc> slangasek: let me work up a debdiff
<nacc> slangasek: would we simply do a pkg-php-tools.override that trnaslates polyfill/apcu to php-apcu?
<slangasek> nacc: don't know, everything I know about php packaging conventions in Debian you also know
<nacc> slangasek: kicking off a build to test it now
<nacc> slangasek: that almost worked, except it keeps the version strings. So let me just hardcode it in the control file for that one binary target
<nacc> slangasek: debdiff posted
<nacc> slangasek: i couldn't find a cleaner way quickly, and i've seen other packages do similar things when we don't like the results of the dh substituions
<nacc> slangasek: fwiw, i installed php-apcu and enabled it, all the classloader tests passed
<slangasek> excellent
<nacc> slangasek: we might want to add php-apcu to d/t/control ?
<nacc> slangasek: i realized just now my debdiff didn't do that
<slangasek> nacc: already pulled in as a transitive dependency of the binary packages
<nacc> slangasek: ah right, i always forget that
<nacc> hrm, i wonder why it didn't in my env already?
<nacc> that is i did a sbuild -pnever
<nacc> schroot'd in, and had to install php-apcu
<nacc> i will look at it on monday, and see if we can maybe enable more of the symfony tests somehow (dig into why so many are skipped)
<nacc> slangasek: thanks for all your help as usual, have a nice weekend!
<slangasek> nacc: you too!
<Pharaoh_Atem> slangasek: kill the python2 with fire!
<Pharaoh_Atem> nacc: the issue with that test script is normal
<Pharaoh_Atem> nacc: see this: http://fpaste.org/342586/14583675/
<Pharaoh_Atem> nacc: Remi pointed this out to me, and I was able to see that it's more of php just being silent by default :/
<Pharaoh_Atem> nacc: the code is essentially bad code
<alkisg> Hi, update-initramfs in 16.04 *calls* the /usr/share/initramfs-tools/scripts/* (not just the hooks, but the scripts themselves), that's a bug, isn't it?
<alkisg> Hmm sorry it appears that the scripts need the prereqs template as well, not just the hooks
<k_alam> @charles can you please look into https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1527848 thanks
<udevbot> Error: "charles" is not a valid command.
<ubottu> Launchpad bug 1527848 in indicator-datetime (Ubuntu) "Indicator-Datetime always shows UTC time for any online calendar added to evolution (Unity7, Xenial)" [Undecided,New]
<nacc> Pharaoh_Atem: ok, good to know, i'll ask the upstream testsuite to fix it, then
<Logan> kyrofa: got sbcl building again
<Logan> I'll ask cjwatson to bootstrap on arm64 when he's back
#ubuntu-devel 2016-03-20
<infinity> Logan: Bootstrapping.
<slangasek> pitti: hi, so we're seeing some test failures on the amd64 and i386 autopkgtest runners for glibc revdeps where gtk is failing consistently; it's not a problem on other archs, I can't reproduce it locally, and the error points to a problem related to selecting a mir backend instead of an X backend.  Have there been any testbed config changes recently that could be to blame?
<stgraber> could be a side effect of the pocket pinning logic in adt
<stgraber> which would explain why a plain adt-run using the whole proposed pocket would succeed but the autopkgtest.ubuntu.com wouldn't as it's only pulling some packages from proposed
<slangasek> stgraber: I didn't do an adt-run using the whole proposed pocket.
<infinity> Logan: Well, sbcl bootstrap attempted, anyway.  It failed.
 * infinity tries it on a newer kernel.
<Unit193> infinity: bitlbee had a new release, not entirely bugfix (https://www.bitlbee.org/main.php/changelog.html) but mainly.  It's had a good amount of testing I'm told, I take it an FFe is still needed?
<infinity> Unit193: Assuming the release is somewhat featureful, yeah.
<Unit193> Bummer.  Thanks.
<infinity> Unit193: Oh, but it's not seeded anywhere, so meh.
<infinity> Unit193: JFDI, IMO.
<infinity> Unit193: Here's your verbal FFe.
<Unit193> Woohoo!  If you feel specifically like uploading: https://launchpad.net/~unit193/+archive/ubuntu/staging/+files/bitlbee_3.4.2-0ubuntu1.dsc, otherwise I'll go find someone.
<infinity> Unit193: It is just a straight uupdate with a new orig, basically?
 * infinity looks.
<Unit193> It needs more updating, but on Debian's side.
<infinity> Looks like a uupdate job to me.  No changes in debian/ except for the changelog.
<Unit193> Mhmm.
<infinity> Kay.  Source tarball looks sane, etc.
<infinity> Want a slightly more verbose changelog? :P
 * infinity shrugs and uploads.
<Unit193> Oh dear, I'm too concise again. :3
<infinity> Unit193: Too late, it's uploaded.
<Unit193> Yey!  Thank you very much, infinity!
<Unit193> I'll pass it along to who poked me.
<dx> â¥
<slangasek> doko: why did libnih need a rebuild for the new libc?  the versioned dep seems to have been resolved some time ago
<cjwatson> pitti: Could we generate a stronger key for ddebs.u.c?
<infinity> slangasek: It doesn't, I assume he was just working from an old list.
<cjwatson> pitti: Also needs --digest-algo SHA384 or similar, but probably not much point until we have something better than 1024-bit DSA
<slangasek> doko: do you know anything about valgrind compatibility with glibc 2.23? http://autopkgtest.ubuntu.com/packages/c/colord/xenial/amd64/ (or is this a toolchain regression somehow?)
<mwhudson> infinity: did i ask you to look at https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1555856 at all yet?
<ubottu> Launchpad bug 1555856 in golang (Ubuntu) "move to per-Go-major version coinstallable packages" [Undecided,New]
<mwhudson> (i asked stgraber to look at it and he asked if you'd seen it...)
<doko> slangasek, just looked at the debian transition issue. the armhf build issue is not caused by the libc update. also seen in the test rebuilds
<nacc> slangasek: will update my automated file, as i was using apt-cache redepends, which includes breaks and others, while reverse-depends does not. will provide an updated list first thing tmrw
#ubuntu-devel 2017-03-13
<cpaelzer> good morning
<Mez_> Hi all, I've found an issue in the Ubuntu Installer (where it shows the map screen) - anyone know which package that is ?
<Mez_> (I may be able to "fix" the issue myself)
<cjwatson> Mez_: ubiquity
<Mez_> cjwatson: where does it pull city names from ?
<Mez_> (I vaguely remember that you work on the installer)
<cjwatson> Mez_: I can't remember whether it's tzdata or tzsetup (both exist, the latter is a d-i component) - one of those two
<cjwatson> Mez_: I used to, moved to working on Launchpad a couple of years ago
<Mez_> Ah, fair enough.  I just don't like the installer mocking the local accent :)
<cjwatson> huh?
<cjwatson> nobody is mocking anything.
<Mez_> one sec :)
<Mez_> (and that is said jokingly, btw)
<Mez_> http://imgur.com/Wxfk2jQ
<cjwatson> I think the autocompletion stuff comes from a web service ...
<cjwatson> geoname-lookup.ubuntu.com
<cjwatson> which is https://launchpad.net/ubuntu-geonames
<Mez_> And the question is, where is that maintained?
<cjwatson> did you type that before or after I pasted the Launchpad link?
<Mez_> before :)
<cjwatson> so the string "Birmin'gxam" does appear in current geonames data (I grabbed http://download.geonames.org/export/dump/GB.zip) - I think that this may be a matter of choosing incorrect localisation
<cjwatson> because e.g. https://ug.wikipedia.org/wiki/Birmin%27gxam
<cjwatson> curl 'http://geoname-lookup.ubuntu.com/?query=Birmin&release=16.04' | jq   reproduces without having to go through the installer
<cjwatson> somebody gets to work out how the geonames importer works and whether this is just a matter of refreshing from upstream data or whether it needs a fix to the importer
<cjwatson> anyway, this is definitely all in the ubuntu-geonames project
<cpaelzer> usually SRU policy implies a change to be upstream in the latest release before SRUing - what if latest release has way more complex changes in other packages to no more trigger it?
<cpaelzer> it makes no sense to add a fix to zesty it doesn't need, but it certainly does to fix it in Xenial
<cjwatson> that would be an exception to discuss with the SRU team, probably in the context of a patch
<cpaelzer> reasonable, I'll add details to the SRU template
<cpaelzer> thanks cjwatson
<caribou> hmm, not a good day for the dev release on my laptop : systemd-resolvd is going haywire on me, I'm loosing some keybindings
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<sil2100> (re-pinging)
<mitya57> Mirv, hi, do you have any pending changes for qtbase 16.04 / 16.10 SRUs? Or a branch in Git or Bzr or somewhere?
<mitya57> (I want to SRU LP: #1380702)
<ubottu> Launchpad bug 1380702 in Canonical System Image "No keyboards shortcuts in QT apps" [High,In progress] https://launchpad.net/bugs/1380702
<nacc> mitya57: there are tasks open, and someone needs to follow: https://wiki.ubuntu.com/StableReleaseUpdates
<slangasek> ogra_: the TB meeting is on the UES team calendar... I don't know why this event always gets hit, but it seems to be magical from the phone's POV because people always wind up editing it via phone sync
<ogra_> slangasek, is it still happening ? or did my wiping fix it ?
<slangasek> ogra_: I haven't seen any overwrite from you lately, but I've seen several more overwrites from other users
<ogra_> slangasek, i just remembered that i got an invite notification once ... and was actually wondering about why the TB invites me ...
<slangasek> ogra_: it wasn't the TB, it was somebody editing the event and inviting eeeeeverybody :)
 * ogra_ goes to check evolution, i might still have it somewhere
<ogra_> ah
<ogra_> :)
<mterry> jdstrand: I'm looking at the guest session apparmor profile -- it's denying connect/w access to /run/snapd.socket -- I tried adding a "/run/snapd.socket rw," rule to the lightdm guest profile, but that didn't help -- I thought rw would be enough?
<mterry> I can share the apparmor denial message if that would help
<sarnold> mterry: jdstrand is out for the week
<mterry> sarnold: ah!  thx
<sarnold> mterry: do we -want- the guest session to be talking to snapd? to what end? I certainly wouldn't want the guest account to be starting up dhcp servers or web servers or bgp daemons or whtaever it is that is snapped
<mterry> sarnold: my goal was to let it get a list of installed snaps and run them
<mterry> sarnold: web servers would be snap daemons, not user-run snaps right?
<mterry> sarnold: my head space was letting guest run Calculator and such
<sarnold> mterry: hrm. even calculator seems like a bit much, unless snapd grows knowledge how to stack apparmor profiles when launching, based on the confinement of the calling process.
<mterry> sarnold: hmm, OK.  I won't bother continuing this then  :P
<dobey> that does seem like a problem we need to solve, but doesn't seem like it should be prioritized at the moment
<sarnold> mterry: well, if we ever face the day of only having browsers via snaps, we'll probably need answers to this :/
<dobey> but i don't think we want the genral ability to read/write to snapd.socket
<dobey> should be ok for unity8 and a couple other system things to do that perhaps, but general access seems bad
<mterry> sarnold: agreed that was my thinking
<mterry> sarnold: but if we have a technical block on stacking profiles, no need for it now
<mitya57> Mirv, FWIW I am building the packages in silo 2569, and am going to copy to archive tomorrow if they build fine (unless you have any objections).
<nacc> slangasek: i've been bothered by an annoying ubuntu-component consequence for a long time; `apt-get changelog qemu` fails, because src:qemu is in main and the binary qemu is in universe, so it tries to download a changelog from the universe component, but they are stored by src packages. I started looking at the apt source (very rusty at C++, I admit), and I see how it could be fixed (at least in terms
<nacc> of what code needs to change), but it also seems like apt doesn't store enough information to easily solve it. Is this just something everyone else doesn't care about?
<slangasek> nacc: if I had hit this problem, I had not realized it was a component issue.  I would argue that it shouldn't be necessary to know the component to get the changelog; what do you think about flattening it (with backwards-compatibility)?
<nacc> slangasek: yeah, it feels like it shouldn't be necessary to me too -- since a source can only live in one component. So we'd change, e.g., http://changelogs.ubuntu.com/changelogs/pool/universe/q/qemu/qemu_2.8+dfsg-3ubuntu2/changelog to http://changelogs.ubuntu.com/changelogs/pool/q/qemu/qemu_2.8+dfsg-3ubuntu2/changelog with appropriate linking for BC? And then update the tooling to drop using the
<nacc> component
<slangasek> nacc: that's my thought, yeah
<nacc> slangasek: sure that makes sense to me. I assume changelogs.ubuntu.com is deployed somewhere? Do you know if there is 'source' for it? or maybe it's just a matter of the deployed configuration
<slangasek> bdmurray: ^^ you might know the answers here re: changelogs.u.c?
<nacc> slangasek: ah, we might also just be able to use http://changelogs.ubuntu.com/changelogs/binary/q/qemu/1:2.8+dfsg-3ubuntu2/changelog (sub. appropriate binary pkg name)
<juliank> nacc: slangasek: Interesting stuff. Flattening requires defining a new template like @CHANGEPATH@ without the component. Of course, if you flatten, you can just symlink all sections
<nacc> slangasek: so it might just be because we are using pool/ as the prefix
<nacc> juliank: yep, that's what i was looking at (after staring at the code for a while :)
<slangasek> juliank: symlink> which would require no client-side code changes, convenient
<juliank> Yep. That would be 100% backward compatible
<nacc> i'll file a bug regardless, because it feels like something we can/should fix.
<juliank> I think it would make a ton of sense to define more variables
<juliank> @CHANGEPATH@ is not really the best abstraction layer
<udevbot> Error: "CHANGEPATH@" is not a valid command.
<nacc> lol
<juliank> lol
<nacc> juliank: yeah, it feels like it happens to work for what is defined now, but if something was to change, it's hard to tweak
<juliank> I'd say do the flatten and symlink change now-ish, and then we have some time to figure out a better clean solution to the problem for 17.10 :)
<nacc> juliank: ack, once i know how it's setup :)
<juliank> nacc: That should even work without changing the server side code if it's just files (the software would write through main/, etc., but symlinking those to .. means it just works in practice)
<nacc> juliank: right, that makes sense
<bdmurray> slangasek/nacc: https://code.launchpad.net/extract-changelogs
<nacc> bdmurray: thanks!
<nacc> juliank: hrm, is this comment self-contradictory?
<nacc> "// the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/1.1 or contrib/liba/libapt/2.0 " ?
<nacc> oh is SRCNAME_SRCVER a variable?
<nacc> path.append(Src).append("_").append(StripEpoch(SrcVersion))
<juliank> You are right, the examples are wrong
<juliank> / the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/apt_1.1 or contrib/liba/libapt/libapt_2.0
<nacc> juliank: ack, np, i just wanted a sanity check :)
<nacc> bdmurray: interestingly --^ the binary/ subdirectory for c.u.c does not do that, it has it as binary/SRC/SRCNAME/SRCVER/changelog
<nacc> and it seems that the epoch is being kept in the binary/ SRCVER
<juliank> nacc: Comment fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e6dddfe
<nacc> juliank: thanks! :)
<nacc> juliank: ok, with some fiddling, (without having to change c.u.c yet) i was able to get binary/ to work (rather than pool/) for c.u.c -- but i think we'd need to tweak how binary/ is setup to match what the changelog subcommand does. Given that it seems like binary/ exists for exactly this reason (i'm still readling/learning) and is doing all this symlinking, it seems like it might be sensible to use
<nacc> (rather than changing how c.u.c/c/pool works?
<juliank> nacc: Switching the URI would require changes to apt and possibly other clients (who knows?). I'd rather have a backwards compatible change.
<nacc> juliank: ack, makes sense
<nacc> juliank: my first foray into apt's code, so just learning a bit :)
<juliank> nacc: Well, you'll probably regret that day then!  :D
<nacc> juliank: :)
<juliank> nacc: Don't look into it too much though, if you become an expert, you'll get all sort of questions.
<juliank> ;)
<nacc> heh
<nacc> bdmurray: am i reading lp:extract-changelogs::lp-extract-changelogs.py wrong, or does it log the symlinks in binary/ backwards (e.g., '%s' -> '%s' % (dest, lnk)) ?
<bdmurray> nacc: I haven't looked at the code in about a year, can you be more specific?
<nacc> bdmurray: it eventually calls (sort of), os.symlink(os.path.abspath(dest), lnk)
<nacc> which to me means lnk -> dest
<nacc> but it logs "dest -> lnk"
<bdmurray> nacc: around line 323?
<nacc> bdmurray: err, yeah, sorry!
<bdmurray> nacc: yes, it does look backwards
<nacc> bdmurray: ack, i'll stage a fixlet for that along with my suggestion then -- as i'm copying that code a bit :)
<bdmurray> nacc: well don't copy any of that author's mistakes!
<nacc> bdmurray: :)
<nacc> bdmurray: i think i found another error, I think the binary/ symlinks are only created when the changelog already exists. But if we are extracting it for the first time, we don't create the symlinks until we see it again. r45 changed this (before that chagne, if i'm reading it right), we only created the symlinks when the changelog is extracted the first time. I think the intention of the change was to
<nacc> 'fix-up' already extracted versions? not entirely sure yet :)
<bdmurray> nacc: yes, re "fix-up"
<nacc> bdmurray: ack, thanks
#ubuntu-devel 2017-03-14
<nacc> slangasek: is powerpc only deleted from the ISOs? will it stay in the archive for 17.04? but not maintained?
<nacc> slangasek: trying to advise someone in #ubuntu+1 on it
<slangasek> nacc: it's to be removed from the archive for 17.04, but this hasn't happenedy et
<Mirv> mitya57: those are just great, thanks.
<Mirv> mitya57: 5.6.1 amd64 build though failed in some mimetype test failure, could be flaky so retrying
<mitya57> Mirv, looks like retrying did not help
<mitya57> It seems to wget a file from cgit.freedesktop.org (how is that even possible during build??), maybe that changed and it broke the tests?
<mitya57> I will land the Xenial one for the time being, it is more important than Yakkety.
<Mirv> mitya57: nothing brewing, and no the only git branches available are zesty, xenial+overlay (and zesty+1 eventually)
<Mirv> mitya57: probably it changed, and yes I thought network connection wasn't possible anyway but I also remember some recent discussion about that
<Mirv> I agree xenial is more important
<cjwatson> network connection remains impossible in anything other than snap builds
<cjwatson> I suspect your wget is illusory in some way :)
<mitya57> cjwatson, OK, that's what I thought :)
<ginggs> mitya57: do you have any idea about the recent sphinx test failures? http://autopkgtest.ubuntu.com/packages/s/sphinx/zesty/amd64 the tests run fine locally
<Laney> ginggs: it reproduces for me (autopkgtest --shell-fail -U --apt-pocket=proposed=src:texlive-base sphinx  -- lxd autopkgtest/ubuntu/zesty/amd64)
<Laney> does look tex related too
<ginggs> Laney: ok thanks for checking, i installed the new texlive-base packages and ran debian/tests/python-sphinx and debian/tests/python3-sphinx
<ginggs> Laney: does it fail for you with texlive-base 2016.20170123-3 in zesty?
<Laney> ginggs: I gave you the command so that you could try it yourself :P
<Laney> but ok... let me see
<mitya57> ginggs, Laney: I donât know anything about this yet. Is the error âCommand \strong already defined.â, or do I read the log incorrectly?
<Laney> mitya57: yeah I think so
<mitya57> I will try to look later then.
<Laney> ginggs: python-sphinx        PASS
<Laney> python3-sphinx       PASS
<Laney> sphinx-doc           PASS
<ginggs> Laney: thanks
<xnox> juliank, hey about bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1672710
<ubottu> Launchpad bug 1672710 in apt (Ubuntu) "apt fails to verify keys when Dir has space, and set via cmdline" [High,Confirmed]
<xnox> it's actually triggered by python-apt, as used by apport, and can be seen in the autopkgtests.
<xnox> what apport does is use python-apt's apt.Cache with rootdir and this bug ends up being triggered.
<juliank> How awful, but yes, I can believe that.
<xnox> how does python-apt pass rootdir to apt?
<juliank> It directly sets the setting in the configuration object.
<juliank> The broken part is dumping that into a file for apt-key
<xnox> well, and apt-key calls apt-config which fails to load, what was dumped....
<xnox> maybe apt-config can ignore garbage at the end of file, if it found the key we want?
<juliank> Actually, I'm not sure why this affects python-apt usage at all, unless there is a quote in the rootdir name itself.
<juliank> or you are parsing commandline with python-apt and there are spaces there.
<xnox> or for apt-key can we dump just a subset of keys? It really only wants just a few keys.
<xnox> in the ADT test the rootdir is something like this:
<xnox> /tmp/tmpepmqlz89/cache/Foonux 1.2/apt/
<xnox> let me try to extract the generated apt_config as passed to apt-key whilst these tests are executed.
<xnox> the call that fails for us is update() call on the apt_cache object
<xnox> rootdir = os.path.abspath(aptroot)
<xnox> self._sandbox_apt_cache = apt.Cache(rootdir=rootdir)
<xnox> self._sandbox_apt_cache.update(fetchProgress)
<xnox> and we bomb out there.
<juliank> Still, unless some part is parsing a commandline with spaces in options, or sets another option with quotes in it, that should not fail.
<xnox> ack.
<xnox> can i somehow dump apt.Cache object config?
<xnox> to see at point of failure what is wrong?
<juliank> xnox: You can print apt_pkg.config.dump()
<juliank> xnox: Since when does this problem occur? I have not seen it, and we have the code to pass config files to apt-key since 1.3 (in yakkety)
<xnox> since yakkety =)
<xnox> but apport adt tests have been failing for other reasons too, hence this issue was masked.
 * xnox has fixed most things now; but this one test case is still failing.
<juliank> xnox: And I basically added the whole thing to fix apport test failures in https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1607283
<ubottu> Launchpad bug 1607283 in apt (Ubuntu) "1.3~pre2ubuntu2 regression: trusted.gpg.d not read any more from apt root" [Medium,Fix released]
<xnox> yeah.
<xnox> i will come back to this after the next phone call.
<juliank> It's in the IRC log from Jul 28
<nacc_> slangasek: ack, thanks
<happyaron> stgraber: do you think running `modprobe zfs` in d/tests/excersie is a sufficient fix for bug #1672749 ?
<ubottu> bug 1672749 in lxd (Ubuntu) "Please don't assume zfs module is always loaded" [Undecided,New] https://launchpad.net/bugs/1672749
<slangasek> mdeslaur, infinity, kees, stgraber: TB meeting in 9 min
<mdeslaur> ack
<slangasek> I'm considering going forward just always following https://wiki.ubuntu.com/TechnicalBoardAgenda for who's the chair, so that if the previous chair doesn't update it, I'm never chairing ;)
<mdeslaur> oh whoops
<robru> Laney: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/319726 please review this quick 3 line diff, thanks
<Laney> robru: want to add some tests? https://paste.debian.net/919899/ as a starting point, maybe
<robru> Laney: could do
<robru> Laney: ok, expanded and updated, please merge
<Laney> okey smokes, lemme look
<Laney> robru: done, thanks!
<robru> Laney: thank you!
<cjwatson> powersj: FYI I'm probably going to include a cherry-picked fix for https://bugs.launchpad.net/debian/+source/openssh/+bug/1670745 in my next Debian upload at which point zesty can be fixed by a sync - just waiting for Debian release team approval since it interacts with the stretch freeze
<ubottu> Launchpad bug 1670745 in openssh (Ubuntu) "ssh-keyscan : bad host signature when using port option" [High,In progress]
<powersj> cjwatson: awesome, thanks for the heads up
<cjwatson> (you're more than welcome to deal with SRUs though ;-) )
<powersj> :)
<arari> Hi all, any developer from http://packages.ubuntu.com/source/trusty/mountall available for a question ?
<nacc> arari: better to just ask the question
<arari> gettting hit by this: The disk drive for /mydisk is not ready yet or not present however without pressing anything the disk is mounted ok... got one VM with that problem and one without... same ubuntu version, same packages, same fstab and same crypttab... killing my head on this one
<nacc> arari: is the fs at /mydisk remote?
<arari> nacc: no
<arari> its an LVM over LUKS over LVM
<nacc> arari: when it fails, do you see anything in syslog indicating what fails?
<arari> nacc: no
<nacc> arari: and you say that if you do nothing when it says it's not ready ... meaning it has dropped you to a shell?
<arari> nacc: no, the boot proceeds as normal and the disk is there after login
<nacc> arari: so ... what's the error?
<nacc> arari: just that you get that message?
<arari> nacc: i had two machines (on client sides) that experienced that in the past two weeks, one of them became unbootable since that problem was showing on / the second one you had to press S to skip the /mydata and then mount it manually afterwards
<arari> nacc: so even though this one is booting... i imagine the other two were somehow related
<arari> hence need to fix this before delivering this new VM
<nacc> arari: is it failing to get the encryption passphrase or something?
<arari> dont think so, i just think that it is doing stuff before it should because the (mydata) running... message shows up a bit after that error message... so for me... it looks like it is tryign fstab stuff before completing the crypttab stuff
<arari> nacc: that above
<arari> as if it was somehow "forked" on the background the "crypttab" stuff and didnt finish before the "fstab" stuff is applied
<nacc> arari: related maybe to LP: #1092853 ?
<ubottu> Launchpad bug 1092853 in mountall (Ubuntu) "mountall fails to handle "noearly" crypt disk correctly and displays error" [Undecided,Confirmed] https://launchpad.net/bugs/1092853
<nacc> arari: given LVM, noearly seems rather important (based upon crypttab)
<nacc> *`man crypttab`
<arari> nacc: i tried with and without noearly... but i dont see the errors as described on that bug
<nacc> arari: ok
<nacc> arari: and i assume you rebuild the initramfs after changing fstab?
<nacc> or crypttab, i think
<arari> no :S
<nacc> arari: then i don't think any changes you make have any affect to the problem you are seeing (which i think is still initramfs time)
<arari> nacc: will try to update... "update-initramfs -u" right?
<nacc> arari: yes, after making any configuration changes
<arari> but as mentioned, i have one (multiple) VM with exactly the same setup and working fine, whilst others not
<nacc> arari: could be timing related -- i genuinely don't know :/
<arari> nacc: https://ibb.co/jUga0a
<nacc> arari: right, so it's started quite early but not read until later -- is it multipathd?
<arari> nacc: no idea what that is, gonna google
<nacc> arari: it's ok, you probably aren't using it then, i was just trying to figure out why /data showed up then
<nacc> arari: this is with 'noearly'? or iwthout
<nacc> *without
<nacc> arari: and is this 14.04 or 16.04?
<arari> 14.04
<nacc> arari: ok -- yeah, i know a lot less about this, and it seems like there have been (at least lately) fewer bugs with the ordering in 16.04 -- but i'm not a subject-matter-expert
<arari> nacc: that is without noearly...  with noearly it shows like this https://ibb.co/kHOoLa
<arari> as can be seen it is "ignored" but still all this happens after the error
<nacc> arari: iiuc, then, as long asyou interact in some way with that message, it works?
<arari> nacc: i dont even need to interact... everything works ok , i dont need to press anything or do anything
<nacc> arari: so the only issue is the one time it happend to / ?
<arari> and once it happend to /data but that time it also required me to press S
<arari> to skip
<arari> didnt continue as normal
<nacc> arari: i genuinly don't know
<nacc> arari: it seems very likely to be something with crypt and the tming with upstart
<arari> nacc: i appreciate the help, i feel at a loss here also... leaning towards some sort of race condition
<nacc> arari: you could file a bug, but if it's not easily reproducible...
<arari> yeah well i find alot of them but all seem to be related to swap and /tmp and people seem to provide workarounds or reinstall rather than fix the actual problem
<cjwatson> to some extent I think that's just the result of it having been superseded by a totally different technology stack in later releases
 * nacc agrees with cjwatson
<nacc> and there's not much investment on 'fixing' upstart issues at this point
<arari> yeah i can imagine but 14.04 is still a LTS
<cjwatson> I'm not disagreeing, just talking practical effects
<cjwatson> (this is no longer my area so I get to be disinterested peanut gallery ;-) )
<nacc> arari: completely empathize -- but also am very aware that what little i do know about init systems is systemd-ish now
<nacc> arari: and what little i did at some point know about upstart has been pushed off the LRU
<cjwatson> if it *can* be reproduced in a VM even if only sometimes, then the way to give a bug report the best chance would be to include directions on building a VM from scratch that demonstrates the bug
<cjwatson> just on general principles
<nacc> yep
<arari> yeah i would like to provide some VMS unfortunately they have too much sensitive data :(
<sarnold> it doesn't have to be provided
<sarnold> it's in fact better if it isn't; instuctions like "start from cloud image yyyymmdd; install foo, bar, baz; set blort to reticulate splines; reboot. notice that the waves are harmonic rather than anharmonic."
<nacc> yeah, it's more about reproducibility, arari
<nacc> arari: LP: #610869 has some interesting backstory too
<ubottu> Launchpad bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [Medium,Triaged] https://launchpad.net/bugs/610869
<nacc> juliank: fyi, https://code.launchpad.net/~nacc/extract-changelogs/changelog-components/+merge/319761 -- but i'm a bit worried about the case I mentioned in the last comment to deal with B-C for a newer apt (yet to be changed of course)
<nacc> bdmurray: thanks for the quick response on that!
<juliank> nacc: I guess explaining what you mean with B-C wouldn't hurt. AFAICT, you chose to symlink the files itself, instead of just merging the {main,...} directories?
<nacc> juliank: oh i see what you mean, i could just make main --> ../ ?
<nacc> duh :)
<juliank> Yeah
<nacc> yes that would seem way better than what i suggested :)
<juliank> just have to do an initial "manual" merge of the existing trees
<nacc> right
<nacc> bdmurray: that's why i didn't want a merge immediately ;)
<nacc> bdmurray: i'll rework my changes -- and i guess maybe we'd have a tool in the repository do the initial flattening? (merging pool/$component/* down into pool/* and then symlinking pool/$component -> pool for B-C)
<juliank> I imagine you can also use mod_rewrite in the apache server if you want to go crazy
<juliank> I played a lot with that today
<nacc> juliank: yeah i imagine so, but i'm not sure where the apache configuration itself lives
<nacc> i can ask about that too, though, that's a goodp oint
<juliank> I imagine the rewrite rules to be ugly, though
<juliank> RewriteCond %{REQUEST_URI} ^/universe/(.*)$
<juliank> RewriteRule (.*) /main/%1 [R=301,L]
<juliank> Something like that but just with more paths adjusted
<juliank> and a RewriteCond ../main/%1 -f
<juliank> or something
 * juliank thinks mod_rewrite is a bit helpful, but would like something more powerful
<juliank> My task today was to normalize multiple slashes to single slashes, as otherwise, relative looksup in my html failed.
<juliank> That works now, but it redirects one /+ at the time
<nacc> juliank: fun! :)
<stgraber> happyaron: we will modify LXD proper to fix that in our next release (next week or so). Now for Ubuntu itself, I consider your change to be a regression which will affect everyone who uses scripts to setup zpools or other tooling which does the same.
<stgraber> happyaron: I've added a priority high, regression task against zfs-linux. My preference here would be to have "zpool" automatically load the kernel module if not present. If that's not possible, I'd recommend we revert this change since it's post feature freeze and consider doing it again very early next cycle.
<nacc> bdmurray: given it's a one-time operation, are you ok with there being an additional script that just flattens the existing c.u.c/pool and leaves behind symlinks so everything will look similar? I guess the risk there is that pool/main will contain src packages that are not in main (and same for other components)
<nacc> i don't know if anyone depends on the URI telling you the component
<sarnold> that's a heck of a lot of symlinks
<sarnold> 512B each? 4KB each?
<nacc> sarnold: it will be ~4 symlinks
<nacc> sarnold: i may have described it poorly above
<sarnold> ah :D
<nacc> but the idea is pool/main/ -> ../; pool/universe -> ../
<nacc> same for multiverse, partner
<nacc> then you can find a given changelog via either pool/component/src/src_version/changelog or pool/src/src_version/changelog and we'd change apt to use the latter to fix the bug :)
<sarnold> nacc: how about packages that move from main to universe or the other way around? are those happy?
<nacc> sarnold: so what i'd expect is w/o any changes
<nacc> you'd see
<nacc> pool/main/src/src_oldversion/changelog
<nacc> and
<nacc> pool/main/src/src_newversion/changelog
<nacc> bah
<nacc> pool/universe/src/src_newversion/changelog
<nacc> for a main -> universe transition
<nacc> with the change, we'd only extract pool/src/src_oldversion/changelog and pool/src/src_newversion/changelog
<nacc> *but* there'd be a symlink from pool/main to pool/
<nacc> the confusing bit is you'd also see (potentially) pool/main/src/src_newversion/changelog and pool/universe/src/src_oldversion/changelog
<nacc> that's the part I can't decide if it would break something
#ubuntu-devel 2017-03-15
<nacc> sarnold: does that make sense?
<sarnold> nacc: it sure makes more sense than my pile of forty thousand symlinks :)
<nacc> presuming the above seems reasonable to anyone else, then we can do a one-time merge pool/component/* to pool/* and symlink before the changelog parser runs next and it should be very little change from then on -- it's actually *really* easy, except for the case you just mentioned, where we might have some src package in multiple components
<nacc> sarnold: yeah that was my initial changes too, don't worry
<nacc> luckily juliank is cleverer than us!
<sarnold> yes :D
<juliank> :D
<juliank> nacc: IMO it would be awkward if anything relied on main/ not containing stuff from universe/ and similar. That basically means somebody crawling things.
<juliank> Hmm, not thought about internal scripts
<juliank> On the http level, you could hide the symlinks, by doing a 301 redirect for the symlink
<juliank> this way you get a canonical url
<nacc> juliank: yep, true
<juliank> nacc: As a counter point, it doubles the number of requests on the changelogs server :D
<nacc> slangasek: do you have an opinion on the above? specifically, woudl it break B-C in your opinion if c.u.c/pool/universe/ contained publications from main (or v.v.)?
<juliank> Arguably, if you find out the correct rewrite rules, rewriting things in apache would be the cleanest solution, and one that allows you to rollback easily at any point.
<juliank> Every solution has its pros and cons. The symlink one is technically the easiest one, and the most resource efficient one.
<juliank> Just rewriting in apache would make things fairly invisible (you can't find the "wrong" links by querying), but you need like 4 redirect rules (one for each component). It also doubles the number of requests (because it needs to follow the redirect) [although, you can probably just do an internal redirect and directly serve a 200]
<slangasek> nacc: I don't see any reason to care that there is extra stuff published under c.u.c/pool/$component
<juliank> I almost have working generic rewrite rules.
<nacc> slangasek: ack, thanks for the response
<juliank> nacc: I just added these rules to my /changelogs dir in .htaccess, that deals with everything https://jak-linux.org/changelogs/htaccess.txt
<nacc> juliank: thanks
<juliank> That was a bit funny, as I tried to really simplify things.
<juliank> Hence stuff like RewriteCond $1 !^main$
<juliank> otherwise, I'd have to repeat the relevant sections for every component that would be boring
<juliank> nacc: So JFTR: Given that these rewrite rules look fairly easy now, that is my recommendation, as it is completely undangerous :)
<juliank> The clue in the solution was to figure out that I can use $1 back references to the rewriterule pattern in rewritecond.
<juliank> nacc: I now added a slightly different take in the htaccess file: Start the section with RewriteCond "%{REQUEST_FILENAME}" !-f instead of the RewriteCond $1 !^main$ thing
<juliank> So basically: If the requested file does not exist, and the file exists within <other component>, redirect to <other component>
<juliank> that's also more robust against double slashes and stuff
<juliank> Cleaned up in https://gist.github.com/julian-klode/600237d0b61cf92b01748b25cf5921d7
<seb128> barry, hey, did you see that your aptdaemon upload from january is still blocked in zesty-proposed? do you plan to sort that out?
<seb128> wgrant, hey, is there any news of that zesty translation export? https://translations.launchpad.net/ubuntu/zesty/+language-packs is still empty
<happyaron> stgraber: I've uploaded a fix for that, will see what to do for zesty+1
<cpaelzer> cjwatson: on bug 1668093 will there be another release in Debian and sync into Zesty or should I create a fix for Zesty as well just as for the SURs?
<ubottu> bug 1668093 in openssh (Ubuntu Yakkety) "ssh-keygen -H corrupts already hashed entries" [High,Triaged] https://launchpad.net/bugs/1668093
<cjwatson> cpaelzer: I'm going to upload to unstable today
<cpaelzer> cjwatson: thanks, to confirm will that still be synced despite being late in zesty cycle?
<cjwatson> yes
<cpaelzer> thanks
<cpaelzer> 'll prepare the related SRUs then
<ginggs> mitya57: sphinx 1.5.3 fixes the two failing tests with the latest texlive-base packages, and i see you've just uploaded that to experimental
<barry> seb128: i'll look at that today
<mitya57> ginggs, thanks for the info, it is https://github.com/sphinx-doc/sphinx/issues/3428 then.
<mitya57> I will sync 1.5.3-1 when LP picks it up.
<jackpot51> Anybody know how to preseed language selection in the installer?
<mdeslaur> jackpot51: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1980
<jackpot51> sweet
<ginggs> mitya57: yes, that looks to be same issue. great :)
<jackpot51> mdeslaur: Does the same apply to OEM config?
<mdeslaur> jackpot51: sorry, I don't know
<jackpot51> I will test
<jackpot51> Looks like it does
<Saviq> happyaron, hey, I'm afraid the new zfs causes bug #1673197
<ubottu> bug 1673197 in zfs-linux (Ubuntu) "Upgrading zfs-initramfs breaks booting from a zfs root" [Critical,New] https://launchpad.net/bugs/1673197
<Saviq> willcooke, I know not really your area, but FYI ââ
<willcooke> Saviq, related to this perhaps?  https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1672749
<ubottu> Launchpad bug 1672749 in lxd (Ubuntu) "Please don't assume zfs module is always loaded" [Undecided,Triaged]
<Saviq> possibly
<willcooke> Saviq, have you got version 0.6.5.9-4ubuntu1 installed?
<Saviq> willcooke, of everything else zfs, yes, downgraded just zfs-initramfs to make it work again
<willcooke> Saviq, ack
<willcooke> Saviq, happyaron is EOD now, but I will pick it up with him first thing
<Saviq> willcooke, ack, tx
<jbicha> barry: did you run gnome-software without aptdaemon installed? I thought it was needed for the apt backend we're using (but I could be wrong)
<lamont> should I be concerned that the "Display" icon is missing from System Settings?
<lamont> tbf, new video card, but wut?
<jbicha> I was going to propose when 17.10 opened to try to switch Software to the packagekit backend used by Debian (LP: #1643134)
<ubottu> Launchpad bug 1643134 in gnome-software (Ubuntu) "Switch gnome-software to use PackageKit backend" [Wishlist,Triaged] https://launchpad.net/bugs/1643134
<Pharaoh_Atem> jbicha: afaik, gnome-software has been using PK backend since it was introduced in Xenial
<Pharaoh_Atem> that's all gnome-software upstream supports, as far as I know
<jbicha> Pharaoh_Atem: we have been patching Software to use apt instead: https://git.gnome.org/browse/gnome-software/log/?h=wip%2Fubuntu-3-22
<Pharaoh_Atem> eww
<jbicha> xenial didn't have packagekit 1.0 for one thing
<Pharaoh_Atem> well, I'm going to feel real stupid if my email to ubuntu-devel gets approved
<Pharaoh_Atem> oh gross
<Pharaoh_Atem> pk 0.8.x!?
<Pharaoh_Atem> why did you guys let it get this bad? :(
<dobey> why did pk 1.0 have to remove pluggable back-end support?
<barry> jbicha: oh, i probably didn't uninstall aptdaemon.  i'll do that test in a bit.  i just installed gnome-software from my ppa
<barry> jbicha: i grepped teh g-s src pkg and couldn't find a reference to aptdaemon
<Pharaoh_Atem> dobey: you'd have to ask hughsie
<Pharaoh_Atem> though if I had to guess, people writing bad, terrible, evil backends
<Pharaoh_Atem> but all backends in PackageKit are libraries
<Pharaoh_Atem> I've hacked on the dnf backend in PackageKit
<Unit193> So some people did bad things, remove all the support?  Makes sense..
<Pharaoh_Atem> so from that perspective, they are pluggable
<Pharaoh_Atem> you can swap backends at runtime, as well
<Pharaoh_Atem> (I did during the hif->dnf backend transition)
<dobey> you mean in gnome-software or in packagekit?
<Pharaoh_Atem> dobey: you said PackageKit
<Pharaoh_Atem> PackageKit has multiple backends
<dobey> yes, but part of the reason why we delayed the move from 0.8 was because we could no longer build a click back-end for it
<Pharaoh_Atem> that seems more your fault than anything
<dobey> because support for having back-ends built outside the source tree was killed
<Pharaoh_Atem> ah, out of source backends
<Pharaoh_Atem> that's different
<Pharaoh_Atem> I'm not sure why, though I'm not sure why you didn't just contribute the backend
<dobey> well building back-ends as dso in-tree, and not allowing anyone out of tree to build back-ends as dso, is kind of an oxymoron
<Pharaoh_Atem> you'd have to ask hughsie, but I suspect he would rather be able to freely refactor the API between PK and backends
<dobey> re: not contributing the back-end into upstream source tree: i'd say it doesn't make sense. packagekit isn't a packaging system. having every packaging system maintain back-ends in packagekit source tree is bad practice. better to maintain the back-end in the tree for the packaging system it's for, so it stays properly in sync
<Pharaoh_Atem> dobey: that seems quite backwards
<dobey> but anyway. it's done now
<Pharaoh_Atem> meh
<barry> jbicha: yeah, it looks like just removing the dep from gnome-software doesn't help; aptdaemon still gets pulled in
<jbicha> barry: oh, gnome-software > software-properties-gtk > aptdaemon
<barry> jbicha: yeah ;/
<barry> jbicha: i think i will still ask to have the aptdaemon in proposed just removed.  we should continue to purge aptdaemon in zesty+1
<jbicha> barry: software-properties was already ported from aptdaemon to pk in Debian, we didn't push it into zesty since I don't think anyone checked if the driver code worked
<jbicha> https://anonscm.debian.org/git/collab-maint/software-properties.git/tree/debian/patches/0004-Implement-PackageKit-support.patch
<barry> jbicha: that's interesting.  thanks.  i'll file some bugs.  i think next cycle i'll have other fun things to work on so i'm not sure i want to take it as *my* mission to get rid of aptdaemon ;)
<jbicha> one reason we killed software-center was because it depended on aptdaemon so the intent has been to drop aptdaemon eventually
<barry> +1
<tumbleweed> ./win 35
<Unit193> Bingo!
<omajid> hi! is anyone working on packaging (or related) work for .NET Core here?
<omajid> please feel free to chime in here: https://github.com/dotnet/core-setup/issues/1599
<foli> This it to announce that we will be beginning maintenance on Canonical data centre firewalls in 8 minutes.
<RAOF1> omajid: You'd likely be looking for #debian-cli on OFTC.
<omajid> thanks.. weird channel name, but looks like the right place!
<tsimonq2> foli: Ok, so what does this mean?
<tsimonq2> foli: i.e., what will be down?
<RAOF1> omajid: We've got all the packaging infrastructure in place to be able to have .NET Core and Mono installed in parallel and such. I think someone has started trying to package?
<popey> sounds like a directhex_ type question
<popey> he did a ton of work packaging mono bits
<omajid> oh, cool!
<directhex_> moo?
<foli> tsimonq2: maintenance on multiple firewalls, each should only be a brief outage
<popey> moo indeed.
<popey> directhex_: long thread (linked above) about packaging *waves hands* dotnet things
* ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 00:00 UTC | Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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:
<tsimonq2> foli: Ok
<foli> tsimonq2: main thing effected that might interest you is launchpad
<tsimonq2> foli: Then you might want to find someone to tweet on behalf of @launchpadstatus or whatever the handle is.
<tsimonq2> (just a suggestion)
<wgrant> It's next on my list :)
<tsimonq2> wgrant: \o/ :)
 * tsimonq2 goes back to doing other things, thanks for letting us know foli :)
<foli> This it to notify the we are beginning maintenance on Canonical data centre firewalls now, lasting up to 1 hour.
<nacc> jgrimm: can you do the sru paperwork for LP: #1668813 ?
<ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress] https://launchpad.net/bugs/1668813
<nacc> jgrimm: should be fairly fast/trivial
<jgrimm> nacc, yep, i will
<nacc> jgrimm: your d/changelog entries don't close the bug anymore. Ok if i manually edit?
<jgrimm> nacc, yes certainly
<nacc> jgrimm: oh i see why
<nacc> jgrimm: dep3changelog does it normally
<nacc> but you used the long-form
<nacc> jgrimm: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1668813 rather than https://bugs.launchpad.net/bugs/1668813
<ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress]
<nacc> jgrimm: may be worth its own bug against dep3changelog :)
<jgrimm> hrmm
<nacc> jgrimm: note that the latter is the default template when you run `dpkg-source --commit` as well (b.l.n/bugs/<bugnumber>)
<jgrimm> ack, yeah i hadn't realized that at all, subtle
<nacc> jgrimm: http://paste.ubuntu.com/24185552/ is the regex ... it seems like it should have caught your case (i'm assuming it's greedy)
<nacc> jgrimm: hrm, weird, even changing it locally it still didn't pick it up
<jgrimm> nacc, meaning it didn't close?
<nacc> jgrimm: it didn't insert into the changelog, i must be missing something obvious
<jgrimm> or meaning you were testing that regex
<jgrimm> ah
<jgrimm> i shouldn't have blindly trusted dep3changelog
<nacc> jgrimm: i just tested in a different src package and it worked fine
<nacc> jgrimm: ok, figured it out
<nacc> i *think* the patch is not being viewed as dep3
<nacc> dep3-compliant
<nacc> it seeing the second blank line and quitting
<nacc> http://dep.debian.net/deps/dep3/
<nacc> slangasek: is that right?
<nacc> slangasek: dep3changelog is not putting the LP bug # in the changelog for https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1668813/+attachment/4835669/+files/iproute2_4.3.0-1ubuntu3.16.04.1.debdiff
<ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress]
<nacc> jgrimm: my understanding is there are two blocks of headers at most and a block ends at the first empty line (after stripping whitespace))
<nacc> so the second block here is 'Just a typo there...'
<jgrimm> nacc,  ok that could certainly explain it then
<slangasek> nacc: dep3changelog only likes https://bugs.launchpad.net/bugs/NNNNNNN
<nacc> slangasek: afaict, it handles both (i'm messing with my local version) -- it's the whitespace it's not liking in this case
<nacc> the blank lines, specifically
<slangasek> oh
<nacc> but the example from http://dep.debian.net/deps/dep3/ has blank lines (afaict on a website)
<slangasek> dep3changelog bug, then
<nacc> i *think* it might be a bug in the dep3 spec too
<nacc> it's hard to say
<nacc> oh i see what it is
<nacc> slangasek: yeah, dep3changelog bug
<nacc> subject and description are meant to be handled differently, i think
<slangasek> well, I don't love the dep3 spec's laxity when it comes to blank lines, but I can't assert that it's a bug :)
<nacc> i'm not sure how you'd solve this properly ...
<nacc> "When Subject is used, it is expected that the long description is outside of the structured fields."
<nacc> but it can be immediately after the Subject line and separated by whitespace
<nacc> but you don't know when the 'long description' ends
<jgrimm> nacc, FYI description updated with an SRU template filled in
<nacc> jgrimm: thanks
<jgrimm> np, thank you
<nacc> jgrimm: eitehr way i'll fix up the changelog on sponsoring this
<nacc> jgrimm: i'm assumign this was a straight wget of the upstream patch?
 * jgrimm will be wary of trusting dep3changelog going forward (or less trusting that i know how to interact with it)
<jgrimm> nacc, git forma-patch of upstream cherry pick
<jgrimm> format-patch
<nacc> jgrimm: ack
#ubuntu-devel 2017-03-16
* ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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:
<foli> Canonical data centre firewall maintenance is now complete.
<sarnold> \o/
<nacc> juliank: technically, i think, we could use rewrite rules w/o changing the extraction algorithm at all (would need more rewrite rules to look in other component directories)?
<sarnold> has anyone looked at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1673247 yet? I'm curious if this one is worth yanking from the archive until it's sorted out. Breaking LTS installers doesn't seem fun.
<ubottu> Launchpad bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Undecided,Confirmed]
<sarnold> infinity,slangasek,stgraber,xnox,cyphermox,mvo, sorry for the mass highlight but https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1673247 sounds like our xenial and yakkety installers are broken at the moment
<ubottu> Launchpad bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Undecided,Confirmed]
<infinity> sarnold: Our installers?  You mean snapd is broken.
<infinity> sarnold: It's only a problem for people who previously installed from proposed.  The breaks/replaces are << 2.23 instead of << 2.23.1
<sarnold> infinity: except the reporters claim that the "download new packages" step explodes :(
<infinity> sarnold: Not an installer bug, but yes, people who are internet-connected during install will see the bug, as we download and install updates during the install.
<infinity> So, I should probably revert snapd in all stables.  Whee.  Fun.
<Unit193> Sounds like you'll have a fun evening.
<sarnold> infinity: sorry :( thanks <3
<infinity> Oddly, my zesty upgrade Just Worked.
<sarnold> hrm. Obviously it worked well enough in britney to move past -proposed, but .. I'm confused, since those folks didn't just decide to file bugs for the fun of it ;)
<infinity> britney has no concept of package contents.
<Unit193> sarnold: In fact, I saw something like that in #xubuntu earlier.
<sarnold> infinity: oh? I thought it tested upgrades?
<infinity> The file overlap is obviously real.  The reason my zesty upgrade worked is that it removed snap-confine on upgrade, it looks like.
<infinity> sarnold: No, we don't do anything like piuparts.  It tests package relationships, but not actually installing them.
<sarnold> ahh
<jgrimm> nacc, fyi I reset bug 1668940 to 'new'.. otherwise release team will never notice its FFe (according to FFe protocol).  so sayeth the wiki.
<ubottu> bug 1668940 in samba (Ubuntu) "[FFe] samba-vfs-modules misses ceph vfs module" [Medium,New] https://launchpad.net/bugs/1668940
<Unit193> infinity: Got a sec for me to bother you?
<juliank> nacc: The rewrite rules I posted in https://gist.github.com/julian-klode/600237d0b61cf92b01748b25cf5921d7 do exactly this. If you request a file for main in universe, it would redirect to main and so on
<Saviq> happyaron, hey, let me know if you need anything re: bug #1673197
<ubottu> bug 1673197 in zfs-linux (Ubuntu) "Upgrading zfs-initramfs breaks booting from a zfs root" [Critical,In progress] https://launchpad.net/bugs/1673197
<tjaalton> uh, how come a freshly-installed zesty system reminds me to update 12.04 LTS before EOL?
<tjaalton> on motd
<xnox> sarnold, infinity: yeah I cannot have fresh cloud-images now. and I am sad.
<xnox> http://paste.ubuntu.com/24187744/
<raphink> Hello
<xnox> apw, can i have meta kernels respun for xenial-security and xenial-updates that are compatible with snapd in xenial-updates?
<raphink> My ubuntu-core-dev membership expired recently and I did not see the warning emails. Would it be possible to renew it please?
<apw> xnox, we'rw working on that right now
<apw> xnox, we did not see that train wreck coming
<xnox> apw, ack. thank you.
<xnox> Tribaal, josvaz__ ^^^^
<Tribaal> xnox: ack, thanks
<xnox> apw, infinity: snapd pulled because upgrades broke; which now breaks installs/bootstraps in -updates|-security *sigh*
<apw> xnox, yes we are aware, we are scrambling to unf*ck the world now
<raphink> cjwatson, ajmitch do you happen to know who could do that?
<ginggs> mitya57: i sync'd sphinx and texlive-base migrated.  http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sphinx beets amd64  is the only failure (murano amd64 and i386 passed on retry)
<ginggs> tumbleweed: any ideas, re: beets ^
<cjwatson> raphink: somebody in ~developer-membership-board
<raphink> ok, so BenC, rbasak for example
<rbasak> raphink: if it's only just happened then I don't see a problem with that. Can you email devel-permissions@ though please, so there's a public record? Note that I'm out until Monday though so I might not see your reply.
<raphink> rbasak, I emailed developer-membership-board@ but it's awaiting moderator approval
<rbasak> raphink: that's the private list. Use devel-permissions@ please.
<raphink> ok, np :-)
<raphink> done
<rbasak> raphink: I looked to check the expiry date and it was longer than I was expecting. If nobody objects them I'll JFDI, I just thought I'd ask the others to make sure they don't disagree, as I don't think it's quite as obvious as "just".
<rbasak> IOW, I think I should act on what I think the DMB as a whole would do, and though I'm fine with it in this case, I'm not confident I understand the others' opinions, so I want to check first.
<juliank> I hope this does not happen to me. Launchpad simply seems to drop a lot of emails, as explained in https://answers.launchpad.net/launchpad/+question/458337
<juliank> I often wonder what stuff I'm missing. For example, I got xnox's initial bug 1672710 report, but not any comments on that.
<ubottu> bug 1672710 in apt (Ubuntu) "apt fails to verify keys when Dir has space, and set via cmdline" [High,Confirmed] https://launchpad.net/bugs/1672710
<xnox> juliank, i have timed out on that =( sorry
<xnox> i need to fine more time to come back to it.
<juliank> xnox: Oh, I was not criticizing you, but launchpad. it only ever sent me the initial bug report you wrote, and none of your or my comments.
<juliank> So, launchpad sent 20% of the messages in that bug
<xnox> juliank, depend son your subscription type no? one can subscribe with or without comments.
<xnox> juliank, under subscriptions
<xnox> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657440/+subscriptions
<ubottu> Launchpad bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,In progress]
<xnox> e.g. there should be stuff about comments, and whether one wants them or not.
<juliank> xnox: Oh, you're right
<juliank> How odd
<xnox> juliank, it's like bug #1 people wanted to know when it will be closed; but not receive all the comments....
<ubottu> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<juliank> xnox: Odd because I sometimes receive more stuff, like adding a remote bug tracker, or my comment in (for example bug 1657440
<ubottu> bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,In progress] https://launchpad.net/bugs/1657440
<juliank> Not that I received any other message from that bug
<xnox> juliank, it's weird some things count as "status updates" and if in advance notifications a status update happened and a comment; and launchpad mailshot is delayed and colates the two into a single email then people who receive "only comments" and "only status updates" receive it.
<xnox> juliank, i generally try to subscribe with all the things: send me all status updates and comments.
<xnox> and then filter mail on my end.
<xnox> seems to work for me.
<juliank> I changed it now: "You will receive an email when any change is made or a comment is added."
<raphink> rbasak, thanks for your answer. I replied to your email.
<mitya57> ginggs, thanks for syncing (you were faster than me)! Sphinx migrated now.
<ginggs> mitya57: yw!  it took a long time for launchpad to pick it up
<brendand> does anyone know if there's a way of suggesting to autopkgtest to prompt debhelper *not* to run dh_auto_test for an unbuilt-tree?
<cjwatson> brendand: --env=DEB_BUILD_OPTIONS=nocheck should do it
<brendand> cjwatson, brilliant! thanks
<brendand> although i guess that will probably apply across all --unbuilt-trees. let's see anyway
<nacc> jgrimm: thanks!
<nacc> juliank: ah ok, i was just reviewing mod_rewrite, thanks!
<xnox> smb, hey, are you still having troubles with isms raid? aka https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1608495
<ubottu> Launchpad bug 1608495 in mdadm (Ubuntu Zesty) "IMSM fakeraid handled by mdadm: unclean mounted volumes on shutdown/reboot" [Critical,Confirmed]
<xnox> i am working on a fix; but my shutdowns result in rebuilding the array still =(
<xnox> https://launchpadlibrarian.net/311133987/mdadm_3.3-2ubuntu7_3.3-2ubuntu7.3.diff.gz
<xnox> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2596/+packages
<smb> xnox, mainly not since I got fed up with the re-syncs and stopped mounting it
<xnox> would you be able to test above & get me a shutdown console log.... somehow...?
<xnox> smb, it all works on fedora; with dracut; which pivots back into initramfs
<xnox> smb, ok.
<xnox> smb, i'll have to rebuild my desktop then to test that myself then.
<xnox> smb, at the moment this issue affects a bare metal cloud and they have root on isms raid =(
<smb> xnox, mind it has been a long time but I think I had tried to copy the shutdown thing from yakkety and still had the sync
<xnox> rebuilds take too long, and thus one fails to boot (as one hits timeout before 60min of resync is done)
<smb> xnox, and console log is somewhat difficult with real hw
<xnox> smb, but in addition to shutdown script one needs to patch mdmon to use @ to prevent being killed
<xnox> yeap.
<xnox> smb, any ideas on getting shutdown console log? i guess i will have to video record it =)
<smb> xnox, also having re-syncs exhibits another issue with raid in xenial which is it seems to take away much more bandwidth than it should do. Which makes the whole system mostly unresponsive until its done
<xnox> it takes about 1h on about 1TB drive, which is reasonable, no?
<smb> xnox, not really. usually netconsole would come to mind but I never was very lucky with it
<xnox> (raid1, two drives, i think actual container here is 800GB)
<xnox> smb, i think i can arrange netconsole on my local network
<smb> xnox, the time is reasonable. it just should not prevent the (different) disk with rootfs on from getting any slices
<xnox> ah
<smb> not sure why this is happening
<smb> xnox, so could do certain testing if you add info to the bug but probably be not much more helpful with a log and I cannot promise how quickly turnaround will be
<xnox> smb, i am better off rebuilding my desktop with isms raid i think indeed.
<smb> xnox, yeah, sorry
<nacc> smoser: rharper: "ystemd-remount-fs[55]: mount: can't find LABEL=cloudimg-rootfs" which is the only entry in /etc/fstab
<nacc> *systemd-remount-fs
<smoser> nacc, so i guess one path to solving that would be to have the squashfs image (or 'lxd' image) not have that in it.
<smoser> but i'd say it woudl seem odd to not have an entry in /etc/fstab for /
<nacc> smoser: yeah that would be weird, but also it's an unusable entry
<smoser> i kind of think systemd-remount-fs should realize its talking about / and / is already  mounted rw, so "done".
<nacc> smoser: yeah, that might be the solution
<nacc> smoser: i'll update the bug and ask pitti to take a look
<nacc> pitti: --^ fyi
<nacc> in the context of LP: #1576341 and getting LXD images to be not in systemd-degraded
<ubottu> Launchpad bug 1576341 in systemd (Ubuntu) "fails in lxd container" [High,Confirmed] https://launchpad.net/bugs/1576341
<nacc> smoser: are you ok if i retitle that bug? :)
<smoser> nacc, sure
<nacc> smoser: thanks
<nacc> bdmurray: where does c.u.c actually run? based upon feedback from juliank I have a potential change to the apache configuration for it, but I'm not sure if the configuration is stored in a SCM
<nacc> bdmurray: given that change, no changes are needed to extract-changelogs
<bdmurray> nacc: I'd check with the webops team about where it actually runs
<nacc> bdmurray: ok, thanks!
<bdmurray> robru: where emails sent about proposed migration for stable releases?
<bdmurray> s/where/were/
<robru> bdmurray: my original branch did but Laney disabled that when he merged
<robru> bdmurray: i guess because it would email everybody for every SRU
<doko> why isn't also the owner of packages with failing autopkg tests notified?
<bdmurray> robru: okay, I was looking at a stuck SRU of mine and was wondering
<bdmurray> maybe Laney'll tell us why
<robru> doko: owners aren't notified because we don't want to spam debian people with Ubuntu failures they likely don't care about
<doko> robru: I mean: the canonical bug subscriber for a package
<robru> doko: nobody told me to inspect bug subscribers. I only send emails for the uploader+creator
<doko> robru: and who told you to send emails to the uploader+creator? ;)
<robru> doko: that would be slangasek
<doko> aha
<nacc> rharper: urgh, ugly -- both iscsid.service and open-iscsi.service would need the !container change, because with just changing iscsid.service,  'ExecStartPre=/bin/systemctl --quiet is-active iscsid.service' in open-iscsi.service makes it go to failed state ... since it doesn't distinguish that iscsid is not started due to 'condition failed' rather than an error
<nacc> smoser: interestingly, manually starting lvm2-lvmetad.socket succeeds, so maybe it's an ordering issue?
<smoser> thats odd
<nacc> smoser: systemd-journald-audit.socket failing seems to be some conflict between it and systemd-journald.service
<nacc> stgraber: pitti: did this ever get followed upon? https://lists.freedesktop.org/archives/systemd-devel/2015-May/032126.html
<rharper> nacc: hrm, that' seems fixable; there are other ways to only activate if another unit is active;  I think the ExecStartPre isn't best practice w.r.t dependencies;
<rharper> it would seem like instead they'd want to run After=iscsid.service;  and Wants=iscsid.service;  that way , if iscsid wasn't going to run then the dependent service wouldn't run either;
<smoser> aaaaaaaa vim stop touching my mouse!
<smoser> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1661691
<ubottu> Launchpad bug 1661691 in vim (Ubuntu Zesty) "TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse" [High,Confirmed]
<sarnold> argh that looks terrible
<infinity> smoser: I can middle-paste fine under TERM=xterm?
<infinity> smoser: Which vim are you using?
<smoser> did you try the recreate ?
<smoser> lxc launch ubuntu-daily:zesty z1 && lxc exec z1 vi foo.txt
<infinity> Trying.  It's downloading.
<infinity> smoser: Weird.  So, it works fine on my base system, and only breaks in lxc?  That's suspect.
<infinity> Oh, cause the base system is likely doing some X jiggery, and there's no X forwarding socket into the container.
<smoser> yeah, i dont know. but yes. thats my experience too. i can paste into 'vi' on the desktop.
<infinity> Curious.
<nacc> rharper: both are already specified
<rharper> nacc: hrm; there's certainly a way to chain units; I may not have it quite right in my head right now
<nacc> rharper: yeah, i've been reading documentation -- i'll keep looking
<nacc> agreed that hte ExecStartPre is ... a kludge i think
<nacc> rharper: open-iscsi specifically says we don't want to use Requires (which would also be an issue anyways), which i think would be the hard-dependency, because then restarting iscsid woudl restart open-iscsi which would end up dropping disk sessions
<nacc> I think
<rharper> Requires means it needs to run successfully
<cyphermox> robru: hey, you still looking for things to do in +1 maintenance?
<nacc> rharper: right, which is tehcnically what we want -- only if iscsid succesfully started should we start open-iscsi
<robru> cyphermox: sure, what you got?
<nacc> rharper: but requires has other implications, it seems, including how services restart
<cyphermox> robru: curl looks like it needs help to transition from proposed
<rharper> yes; there are some strange dependent units;  you may find the postgresql units interesting; they've something dynamic like this IIRC
 * rharper will bbiab
<nacc> rharper: thanks, i will look
<robru> cyphermox: thanks I'll take a look
<smoser> infinity, random bit of information, the vim paste thing happen also for me if i ssh in
<cyphermox> robru: let me know if you're stuck
<infinity> smoser: You mean if you ssh in to the container, right?  Cause if I ssh to localhost, it works fine.
<infinity> smoser: If the consistent variable here is "in the container", then that narrows down the search for what vim's detecting wrong about the environment.
<infinity> (reproducing in a simple chroot would help narrow that too)
<smoser> infinity, yes, when i ssh into container
<smoser> and yeah, when i ssh to localhost i also paste fine
<jackpot51> Using a preseed, ubuntu server sits at an empty virtual terminal after GRUB
<jackpot51> has this been experienced by anyone else?
<infinity> jackpot51: qemu or real hardware?
<jackpot51> QEMU
<infinity> Yeah.  '-vga qxl' works, I think.
<infinity> One of the non-default vga options. :P
<infinity> Or boot without splash bits.
<jackpot51> No splash, and already using -vga qxl
<jackpot51> My preseed looks like this: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1880
<infinity> You sure there's no splash?  Interrupt the boot and check what grub says.
<infinity> vt.handoff=7 might also be an issue.  But again, all of the above when using a VGA driver that sucks.
<infinity> Maybe qxl is the one that sucks and vmware is the one I use that works.  I always forget.
 * infinity tests.
<jackpot51> I will try it again
<infinity> Of course, testing with a quick xenial install, I don't get any of the splash/vt_handoff stuff in the first place, which also entirely avoids the problem.
<infinity> I guess I'll grab a zesty ISO while I actually do go for lunch finally.
<jackpot51> Do you want my preseed file?
<nacc> rharper: if you do recall which postgres systemd file contains the deps, i'd appreciate it -- not seeing it yet
<rharper> lemme see
<rharper> nacc: postgresql-common:systemd/postgresql@.service ; which uses the 'PartOf'  unit directive
<rharper> Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency â changes to this unit do not affect the listed units.
<rharper> the fancy thing there is that they have a generator which finds out the version of postgres and the cluster name, and then they use a generic 'postgresql.service' which will start or stop any of the postgresql@.service; so if you had 9.5-main , 9.5-backup, 9.6-test;  you could use one service to start/stop them all
<rharper> that felt like the relationship in iscsid/open-iscsi but you'll know better
<nacc> rharper: ack thanks
<rharper> np
<infinity> jackpot51: It might just be that you need "d-i debian-installer/quiet boolean false" to go with the splash in your preseed.
<infinity> jackpot51: At least, to match what the server ISOs do.
<jackpot51> Ok, I will try that
<jackpot51> No dice :/
<jackpot51> infinity: I will look into https://github.com/gc3-uzh-ch/openstack-tools/blob/master/etc/ubuntu-preseed.cfg
<jackpot51> infinity: here is another one: https://github.com/joyent/mi-debian/blob/master/config/debian-installer/preseed.cfg
<nacc> rharper: also i just double-check and privileged containers, as expected, are able to run iscsid, so we do want to (i think) adjust open-iscsi.service no matter waht
<rharper> nacc: w.r.t removing the !VirtContainer check ?
<rharper> and switching to the username space check ?
<nacc> rharper: yeah, or something along those lines (implementation TBD)
<nacc> rharper: PartOf does seem more correct
<nacc> rharper: thanks for that pointer
<rharper> nacc: then yeah; I think we shouldn't be overly restrictive to all containers since they're not the same
<rharper> nacc: cool!
<rharper> hopefully that switch can go upstream to debian as well
<rharper> possibly to project
<nacc> yep, i'll work on changes locally to test and then ask hallyn to review them
<nacc> yep
<rharper> awesome!
<nacc> i've asked upstream too about mlockall
<rharper> hehe
<nacc> just curious if they even know :)
<rharper> indeed
<nacc> rharper: although, the more i think about it, what is the use-case to have iscsid.service running but not open-iscsi.service?
<nacc> rharper: that is why isn't it one service really
<nacc> rharper: PartOf doesn't solve this problem as it's not different enough from Requires, afaict. What it does is ties the two together (one way), so if we put in open-iscsi.service, PartOf=iscsid.service, then when systemd stops or restarts iscsid.service, it will stop or restart open-iscsi.service. It does not cover 'start' (afaict) and doesn't prevent the propogation when iscsid.service is not loaded.
<nacc> pitti: maybe you're the best to just ask :) is it possible to have a systemd service defined in such a way that it only runs when another service is successfully running (and stops when that one stops), etc.
<nacc> rharper: ah i see why -- maybe -- iscsid.service is forking, but open-iscsi.service is a onehsot
<nacc> rharper: i might have a fix, it feels really hacky, though
<nacc> http://paste.ubuntu.com/24192018/
<nacc> and then i need to work ont he right fix for iscsid.service
<nacc> as terrible as that is, i think it's 'no worse' than we are now
<nacc> becasue in theory, if `/bin/systemctl --quiet is-active iscsid.service` were to return 15 or 21 (rather than 3), it seems like we would not have any problems ...
<nacc> i mean it's wrong i think to assume 3 means anything
<nacc> rharper: ooh fedora's systemd unit is way better :)
<nacc> I will look into that
#ubuntu-devel 2017-03-17
<mwhudson> are there any archive admins about? maybe wgrant?
<wgrant> mwhudson: Hi
<mwhudson> wgrant: there is a ridiculous circular dependency mess with some golang packages in zesty-proposed
<mwhudson> wgrant: i have a plan, but it requires deleting two packages from -proposed
<wgrant> mwhudson: I can do it as long as it requires no manual britney fiddling.
<mwhudson> (my plan is fairly ridiculous too but i've tested it locally as much as i can)
<mwhudson> wgrant: just the package deletions is all i need
<mwhudson> wgrant: golang-goolge-x-oauth2 and golang-google-grpc
<wgrant> Can you explain the problem and your crazy plan?
<wgrant> mwhudson: Neither of those packages exist, even with the typo fixded.
<mwhudson> wgrant: they are source packages
<wgrant> Oh the second one does if I don't typo it.
<wgrant> What's the proper name of the first one?
<mwhudson> and it's golang-golang-x-oauth2 sorry
<wgrant> Aha
<mwhudson> g-g-x-oauth2 is not migrating because it depends on a newer version of golang-google-cloud-compute-metadata-dev
<wgrant> golang-google-grpc hasn't built
<cyphermox> why remove though, can't you upload/copy/whatever what's missing?
<mwhudson> which is in depwait because it depends on a newer golang-google-api-dev
<mwhudson> which ftbfs because it tries to install g-g-x-oauth2-dev which is uninstallable in -proposed
<mwhudson> cyphermox: because i want to build some packages against the g-g-x-oauth2-dev in the relase pocket
<mwhudson> my plan is this: remove the two mentioned packages
<cyphermox> yeah I see
<cyphermox> you want to bootstrap things
<mwhudson> upload a patched version of golang-google-grpc with a lower version than debian that will build against g-g-x-oauth2-dev in the relase pocket
<mwhudson> upload a no-change rebuild of golang-goole-genproto
<mwhudson> retry the builds of golang-google-api
<mwhudson> sync  g-g-x-oauth2-dev from debian which should now build and migrate
<mwhudson> sync golang-google-grpc from debian, ditto
<cyphermox> correct me if I'm wrong but even if you remove I think LP will still have seen the upload.
<wgrant> The plan will work, assuming that you know the correct sequence of builds.
<wgrant> Removing them even temporarily is not a problem.
<cyphermox> ok
<mwhudson> wgrant: i've tried it locally with a schroot that has had some packages hacked out of the _Packages file
<mwhudson> heh doing this with the archive publishing delays is going to require more than average levels of concentration
<wgrant> One other possibility is to stage this in a PPA, but there aren't too many levels here.
<wgrant> Why does golang-google-genproto need a rebuild?
<wgrant> mwhudson: For the last two steps, can we just resurrect the existing golang-golang-x-oauth2 and golang-google-grpc that we're about to delete, the former of which has already built and the latter should now be buildable, or do we need new versions from Debian for some reason?
<mwhudson> wgrant: er yeah resurrection would be fine
<mwhudson> wgrant: i was assuming the versions currently in debian are the same as in z-p but i guess that's not necessarily the case
<mwhudson> <wgrant> Why does golang-google-genproto need a rebuild?
<mwhudson> because everything is terrible
<mwhudson> as far as i can tell
<wgrant> I can go with that, though I wouldn't say no to more details.
<mwhudson> it contains files generated with an old version of the protobuf compiler, which now don't work when building with the version of golang-google-grpc in the archive
<wgrant> Oh that is terrible.
<mwhudson> (i think even the version in release, although i haven't checked that)
<mwhudson> yeah
<mwhudson> wgrant: so you're ok to do the deletion?
<wgrant> mwhudson: Alright, sounds sane to me.
<mwhudson> thanks
<wgrant> Should I proceed?
<mwhudson> wgrant: please do
<wgrant> mwhudson: Done, and the publisher is just finishing up its previous run
<mwhudson> wgrant: thanks
<elfgoh> Quick check, for deb packages, eg for those with weekly or daily builds, is there a trail/log of the build so that it is possible for one to reproduce the build?
<sarnold> there's a lot of questions in that one sentence :)
<elfgoh> lol sorry
<sarnold> elfgoh: debian has a reproducible builds project https://wiki.debian.org/ReproducibleBuilds
<sarnold> they're working on reducing sources of unneeded churn from build to build
<elfgoh> Ok thanks. What about for images?
<sarnold> afaik no debian or ubuntu packages are just blindly rebuilt every week or something; people decide when to push new packages to the archives.. but PPAs have some 'recipes' that can do builds on some set of schedules or checkins or something, I've not investigated those
<wgrant> mwhudson: Publisher done.
<mwhudson> wgrant: thanks, that was quick
<sarnold> for ubuntu, there's extensive logging of builds,consider e.g. https://launchpad.net/ubuntu/+source/bash/4.4-2ubuntu1 -- there's a few links under Builds to information on each of the builds on the different architectures
<wgrant> mwhudson: No changes in zesty proper, so no big suites to republish.
<wgrant> mwhudson: If you're lucky, that will hold for this whole process and we'll be done within an hour!
<elfgoh> Ok. So assuming that I wish to do a reproducible build for debian manually, where do I look to see which source went to building a package?
<wgrant> elfgoh: If it was built on Launchpad, you can find the log on Launchpad which contains a (not easily machine readable) list of all the dependency versions that were used for the build.
<wgrant> We don't currently do reproducible builds in the sense of that Debian wiki page, though, so the results are not going to be byte-for-byte identical.
<elfgoh> wgrant: I see. So the checksums could possibly differ?
<wgrant> elfgoh: They will, yes.
<wgrant> The goal of the reproducible builds project is to eliminate that, but it's not there yet.
<elfgoh> Enlighten me please. Assuming the same build tools, what are the differences that could cause the resulting package checksums to differ?
<wgrant> elfgoh: Timestamps, race conditions in parallel build processes, that sort of thing.
<sarnold> \date{} tags in latex docs or similar in nroff for manpages..
<wgrant> IIRC the Debian wiki page lists common sources of non-determinism
<sarnold> random uuids in build blobs..
<elfgoh> wgrant: thanks I will check that out
<wgrant> elfgoh: What is your goal?
<mwhudson> wgrant: as a core dev, can i use copy-package to copy into the primary archive?
<mwhudson> (mostly just curious here)
<wgrant> mwhudson: You can, but doing that with binaries can be difficult to get right.
<mwhudson> yeah, i definitely don't want to do that :)
<wgrant> (self-service Debian syncs are just a sourceful copyPackage nowadays)
<mwhudson> i guess syncpackage boils down to copy-package underneath?
<mwhudson> right
<elfgoh> wgrant: my goal is to verify/audit the build process of a debian snapshot image for the beaglebone black
<mwhudson> ok golang-google-grpc-dev built
<mwhudson> pls be slow britney
<wgrant> It's not published yet
<wgrant> mwhudson: Why do you want it to be slow?
<mwhudson> wgrant: so that zesty release stays unmodified
<elfgoh> wgrant: so am trying to find out existing practices in other projects, and also get familiar with the terminology so that I can communicate clearly to the Beaglebone communituy
<mwhudson> and the publisher is fast
<wgrant> mwhudson: Ah right, heh.
<wgrant> mwhudson: It just published, anyway.
<mwhudson> wgrant: hm, rmadison isn't showing it yet
<wgrant> mwhudson: That'll take some time to update, probably.
<mwhudson> and i want to wait for that before i rebuild, right?
<wgrant> No
<wgrant> Buildds use ftpmaster.internal, so as soon as the publisher is done the changes are visible.
<wgrant> 2017-03-17 01:41:53 DEBUG   publish-ftpmaster ran in 222.350393s (excl. load & lock)
<wgrant> 2017-03-17 01:46:46 DEBUG   publish-ftpmaster ran in 215.29642s (excl. load & lock)
<wgrant> 2017-03-17 01:51:45 DEBUG   publish-ftpmaster ran in 215.015479s (excl. load & lock)
<wgrant> 2017-03-17 01:56:51 DEBUG   publish-ftpmaster ran in 220.509879s (excl. load & lock)
<wgrant> 2017-03-17 02:02:33 DEBUG   publish-ftpmaster ran in 262.711479s (excl. load & lock)
<wgrant> last few runs
<wgrant> If the Published timestamp on the binary pub is before the most recent of those, it's visible to buildds.
<wgrant> https://launchpad.net/ubuntu/zesty/amd64/golang-google-grpc-dev
<wgrant> Published 02:03:15
<wgrant> Ah, the publisher hadn't finished germinating, so it didn't show up as done in the log
<wgrant> 2017-03-17 02:07:01 DEBUG   publish-ftpmaster ran in 229.814887s (excl. load & lock)
<wgrant> mwhudson: So upload genproto so we can beat britney :)
<mwhudson> wgrant: just doing so
<wgrant> britney is, sadly, victorious.
<wgrant> Still, should only take about 20 minutes.
<mwhudson> cool
<wgrant> mwhudson: Publisher finishing up with genproto. Retrying g-g-api next?
<wgrant> Publisher done.
<mwhudson> yeah
 * mwhudson retries
<wgrant> Might just make it in before the next publisher starts.
<wgrant> Success.
<wgrant> mwhudson: Does the order of oauth2 resurrection vs grpc retry matter?
<mwhudson> yeah, need oauth2 published to build grpc i think
<wgrant> Should I resurrect oauth2 before the publisher starts?
<mwhudson> um i guess
<mwhudson> worst that happens would be a build failure i guess
<mwhudson> same for oauth2 vs grpc come to that
<mwhudson> wgrant: afaict it would be fine to resurrect oauth2 and grpc now
<wgrant> mwhudson: Yeah, just grpc doesn't save us any time, since it has no binaries and is the final piece anyway.
<mwhudson> wgrant: oauth2 might ftbfs or depwait but in any case i think i need to bounce on retry for a whole bunch of stuff after this is done anway
<wgrant> mwhudson: oauth2 has already built, remember.
<lfaraone> I've had a merge proposal waiting for review into initramfs-tools since October 2016 that will resolve bug #798414. Are merge proposals no longer used, or is there some other way I can ensure this gets attention? (Fixing the underlying issue that results in users getting full `/boot` is, amusingly, out of scope for that bug.)
<ubottu> bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,In progress] https://launchpad.net/bugs/798414
<wgrant> The old binaries are resurrected and are currently publishing.
<mwhudson> oh right
<mwhudson> binaryful resurrection, didn't think about that
<mwhudson> ok
<lfaraone> ( sorry, MP link: https://code.launchpad.net/~lfaraone/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/309191 )
<wgrant> mwhudson: It's not possible to rebuild the same source into new binaries, so we'd need either a no-change rebuild or binaryful resurrection.
<mwhudson> wgrant: ah ok
<mwhudson> wgrant: are you ok to sync grpc after the next publisher run? i need to disappear for a bit
<mwhudson> not a problem if not, i can do it myself later
<wgrant> mwhudson: Sync from Debian, or resurrect and retry?
 * wgrant checks for version differences.
<mwhudson> wgrant: i don't think there would be a difference
<wgrant> mwhudson: They are in fact the same version.
<mwhudson> but i guess resurrection would be more appropriate
<wgrant> I'll resurrect and retry.
<mwhudson> wgrant: yeah, debian is in freeze so not much happening there
<mwhudson> (i know people _can_ upload to unstable but they're not doing much)
<mwhudson> wgrant: thanks for your help!
 * mwhudson runs away
<wgrant> mwhudson: np
<wgrant> mwhudson: Your plan has failed. There's a very tight loop between golang-golang-x-oauth2 and golang-google-cloud
<mwhudson> wgrant: argh wtf
<wgrant> One wonders why an oauth library depends on a cloud compute client library.
<wgrant> But it's not possible to resolve without some manual relaxation one at least one side.
<mwhudson> wgrant: why is g-g-x-oauth2-dev uninstallable now?
<mwhudson> (am on 3g now)
<wgrant> mwhudson: Because it needs the new golang-google-cloud-compute-metadata-dev
<wgrant> golang-golang-x-oauth2 (0.0~git20161103.0.36bc617-1) unstable; urgency=medium
<mwhudson> oh wait, i think i forgot some steps :(
<wgrant>   * Depend on latest golang-google-cloud-compute-metadata-dev.
<mwhudson> a i think if you delete oauth2 from proposed again, golang-google-cloud will build
<wgrant> It shouldn't
<wgrant> golang-google-cloud needs a pretty new one
<mwhudson> oh ffs
<mwhudson> i'll need to look at this on monday
<wgrant>                golang-golang-x-oauth2-google-dev (>= 0.0~git20161103.0.36bc617-3~),
<wgrant>          golang-google-cloud-compute-metadata-dev (>= 0.0~git20160615-5~),
<mwhudson> how the heck did this build on debian
<wgrant> So we might have to bootstrap golang-golang-x-oauth2 against an older golang-google-cloud, which is probably best done in a PPA
<wgrant> (a PPA configured not to see -proposed)
<wgrant> This is a pretty ridiculous looo
<wgrant> p
<mwhudson> oh right
<wgrant> But indeed the dep is real.
<mwhudson> it really is
<wgrant>   * Depend on latest version of x/oauth2/google to avoid more circular dep
 * mwhudson puts laptop away again
<wgrant>     problems.
<wgrant> ... I see
<wgrant> Redefining the term "avoid"
<wgrant> mwhudson: I think we need exactly golang-google-cloud 0.0~git20160615-5, which should build against the release golang-golang-x-oauth2. That golang-google-cloud will enable the -proposed golang-golang-x-oauth2 to be installed, allowing the -proposed golang-google-cloud to build.
<wgrant> Oh great, and that golang-google-cloud won't build against the new golang-google-grpc.
<pitti> nacc: I don't remember the details any more, but in Debian/Ubuntu at least we still have a patch to not enable auditing
<pitti> it's still horribly noisy
<pitti> infinity: or perhaps your ~/.vimrc has "set mouse="? (I did that too after I saw the newly enabled madness)
<infinity> pitti: Nope.
<mwhudson> wgrant: aaargh
<mwhudson> wgrant: i'll look again on monday
<wgrant> mwhudson: No you won't.
<wgrant> mwhudson: It should migrate next britney run.
<mwhudson> wgrant: oh you fixed it?
<wgrant> mwhudson: Yeah, broke the loop in a PPA
<mwhudson> ah ok
<mwhudson> lots of build retrying on monday then
<mwhudson> wgrant: thanks again
<mwhudson> you're even worse than me for getting stuck on problems :)
<wgrant> mwhudson: np
<smoser> infinity, around ?
<smoser> bug 1661691 . it wasnt clear to me, where you suggesting we pick up delta to disable mouse ?
<ubottu> bug 1661691 in vim (Ubuntu Zesty) "TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse" [High,In progress] https://launchpad.net/bugs/1661691
<smoser> commented in bug.
<infinity> smoser: Fix already uploaded.
<smoser> you think that is the right decision? we will now differ from debian and from upstream because you and I were bothered by it.
<infinity> smoser: Frankly, I think upstream is wrong.  I'll push this back to Debian.
<smoser> if you push it back to debian, then i'm not so bothered. but i really dont think its worth ubuntu delta.
<infinity> smoser: Despite what some people think, it's the job of distros to improve on upstream, not just package the upstream gospel.
<infinity> (We carry other deltas to vim, it's not the end of the world even if we do differ)
<smoser> infinity, once you learn about 'shift' i suspect the end result is actually better.
<infinity> Yeah, I'm not inclined to agree it's better.  But maybe I'm old?
<smoser> all delta is pain. most painful is behavior delta that is exposed to users.
<smoser> you are old for sure.
 * smoser is in the same boaat
<smoser> so, i'm fine with whatever, but ubuntu delta that changes behavior from debian, that we can never back out because we don't want to cause pain for a user is permanent pain.
<infinity> Plus, the "learn about shit" thing isn't exactly discoverable, so I'm not sure "users just need to learn it's broken" is valid.
<infinity> It's my permanent pain, not yours. :P
<smoser> i agree its not discoverable.
<infinity> s/shit/shift/, though appropriate typo.
<smoser> :)
<smoser> if the error message said "did you mean shift+middle-mouse?" then it'd be fine.
<smoser> i'll open an upstream bug suggesting that.
<infinity> Well, "fine".
<infinity> I don't think that's fine either.
<smoser> well, i'd have probably never opened the bug and just accepted the change.
<infinity> Having exactly one application that doesn't paste on middle-click is gratuitously broken.
<smoser> that would have meant that christian would not have dug on it
<smoser> which would mean it probably wouldnt be fixed or changed.
<smoser> infinity, that is a good point.
<smoser> shell paste work, vi paste fail. i'll take it.
<smoser> thanks.
<infinity> If upstream makes middle click actually DTRT, I can probably accept that the rest of "mouse mode" is better for people who aren't me.
<infinity> (Though, I find placing a cursor in a terminal with a mouse to be the height of wrongness, I'm sure that's just me being a fuddy and/or duddy)
<infinity> smoser: Also note that it *is* just broken in chroots.  In my base system, if I move .vimrc out of the way, it works correctly without the shift.
<smoser> ?
<infinity> So, yeah.  Removing it seems the correct thing for now, and I'll reevaluate.
<smoser> its not "just in chroots"
<infinity> Yeah, it is.
<smoser> its anywhere where you have a new user.
<infinity> No.
<smoser> it reproduces in lxc and in vms
<infinity> I literally just moved my .vimrc out of the way.
<smoser> and i suspect install from scratch
<infinity> And middle-click works.
<smoser> i literally launched a new ubuntu vm with no user-data and ssh'd in and it fails
<infinity> Okay, chroots and ssh?  Anything without X forwarding, probably.
<infinity> So, even worse. :P
<infinity> But locally, when in "mouse mode" (ie: cursor placement with mouse, etc), middle-click doesn't need the shift to paste.
<smoser> no
<smoser> just tried ssh -X.
<smoser> fails there.
<smoser> (fails == uses mouse mode)
<infinity> "use mouse mode" isn't the failure mode, it's "needs shift to paste" that is.
<infinity> Like i said, locally without a vimrc, it uses mouse mode.  But paste works.
<infinity> It might not be X forwarding, it might be some local mouse library magic, I dunno.  My point was that the local and chroot(/ssh) behaviour is different.  Which is wrong.
<smoser> well, ssh -X  without a .vimrc uses mouse mode and paste fails with the error message.
<infinity> It has nothing to do with fresh user versus not, that just papers over it in the cases where it's extra broken.
<infinity> A fresh local user behaves differently from a fresh chroot/remote user.
<smoser> i can verify as you said that locally paste does work.
<smoser> without .vimrc
<smoser> but ssh -X to remote system it does not work.
<smoser> so i'm not sure what the difference is there.
<smoser> anyway, enough time spent for now.
<infinity> Yeah, "anything without X forwarding, probably", the key word was "probably".  I'm not digging into the code to find out what the actual mechanism that's failing is. :P
<doko> infinity: is there a real chance for the glibc update at the weekend? asking because else I would start the test rebuilds today
<infinity> cjwatson: I'm going to assume, because it makes sense that it should be possible, that one can create a copy archive of a copy archive? :)
<infinity> cjwatson: (Or whatever one calls doko's rebuild archive things)
<infinity> doko: Assuming Colin's answer to the above is what I think it should be, I'd say start a rebuild now, because I'll want to do another (main-only, probably) with the new glibc if it's going to make it so we can compare results.  Comparing to a few months ago doesn't really tell me if glibc broke things.
<doko> ok
<cjwatson> infinity: I've never tried it, but from the code I believe that it is possible.
<nacc> pitti: hrm, then why does the service try to start in the container?
<nacc> pitti: i'll try and communicate what i foudn in the bug, hopefully you can reply there
<pitti> nacc: oh, I missed your question; I just responded to the vim mouse one
<pitti> nacc: sure, if you want to have b.service start and stop with a.service, use BindsTo (see systemd.unit(5))
<nacc> pitti: it's ok
<nacc> pitti: ah ok thanks!
<nacc> pitti: i'll see if that works :)
<nacc> pitti: i also foudn fedora's open-iscsi.service equiv. is a lot cleaner than ours/Debian's -- so maybe will go down that path
<jbicha> LP: #1673817 looks bad, I wonder if anyone else experienced it
<ubottu> Launchpad bug 1673817 in unattended-upgrades (Ubuntu) "update-secure-boot-policy behaving badly with unattended-upgrades" [Undecided,New] https://launchpad.net/bugs/1673817
<nacc> pitti: hrm, BindsTo still doesn't work exactly as I am looking
<infinity> cyphermox: ^-- You behave badly with noninteractive debconf frontends.  Infinite loop on your password prompt instead of just defaulting to not changing the policy.
<infinity> cyphermox: Though, this is also only triggered because of the other bug (incorrectly detecting that he's already in insecure mode), I bet.
<nacc> pitti: in this case, we have {iscsid,open-iscsi}.service -- iscsid is a necessary service for open-iscsi.service to start. If you try to start open-iscsi.service w/o iscsid.service running successfully, it will fail
<cyphermox> infinity: err, I don't know what the password prompt is really infinite, I had tested that a lot
<nacc> pitti: so the use of ExecStartPre check for iscsid.service running in open-iscsi.service unfortunately, leaves open-iscsi in a failed state
<infinity> cyphermox: Sure looks infinite in his bug report.
<infinity> """
<infinity> This message was repeated a very large number of times (but I only included it once in the attachment:
<infinity> "Invalid password
<infinity> The Secure Boot key you've entered is not valid. The password used must be
<infinity> between 8 and 16 characters."
<infinity> """
<cyphermox> oh, unattended, right
<cyphermox> heh
<infinity> Which looks like exactly what would happen if you assume you have a frontend when you don't and ask for input you'll never get.
<pitti> nacc: so you could say open-iscsi.service Requires=iscsid.service, why wouldn't that work?
<pitti> nacc: oh, and After= of course too
<nacc> pitti: because then open-iscsi.service will restart when iscsid.service restarts and it will logout of all iscsi disks and log back into them, which might drop your root disk :)
 * infinity naps now.
<cyphermox> infinity: yes
<nacc> pitti: this is what fedora does: http://paste.ubuntu.com/24195791/ (in the unit)
<pitti> well, that's not starting when you don't need it, not dependencies or ordering
<nacc> pitti: which i think is a more accurate description -- are thereare iscsi definitions to login too? and can we use sessions?
<nacc> pitti: i think open-iscsi.service is just written poorly tbh :)
<pitti> sorry, what? login? sessions?
<nacc> iscsi :)
<nacc> pitti: http://paste.ubuntu.com/24195808/
<nacc> pitti: that's the current open-iscsi.service (with the BindsTo change)
<nacc> pitti: i think the distinction to be made here is that open-iscsi not starting because iscsid.service didn't start is not a failure in open-iscsi.service (it's a failure in iscsid.service)
<nacc> pitti: if it would help, i can more clearly restate the issue -- or via e-mail or so
<pitti> yeah, might be better; I'm quite distracted right now
<nacc> pitti: totally fine, thanks for your time! i'll update the bug and then e-mail you directly as well
<pitti> nacc: just sub me to the bug
<pitti> same email folder, and everything in one place then :)
<nacc> pitti: ack, will do
<nacc> smoser: why does the non-empty fstab by default work in KVM? ah .. there is a disk with that label, but not in lxd
<cyphermox> infinity: this is craptastic, there is no way this can work unattended (you do need to enter a password to do changes), and not doing it means you might have a broken system. Fortunately most likely one that boots, but still.
<jbicha> cyphermox: is it VirtualBox that triggered the shim prompt?
<cyphermox> probably, yes
<jbicha> because we can blacklist individual packages in unattended-upgrades as a workaroundâ¦
<cyphermox> no, that won't really help you
<jbicha> also, I get that prompt every time I update VirtualBox; is there a way that it can know that I've already disabled Secure Boot
<cyphermox> the "right" fix is to skip doing the work on unattended in this case, but it comes with risks
<cyphermox> jbicha: yes, working on that.
<cyphermox> it should already detect it properly but there are other broken things
<slangasek> cyphermox: I remember we did discuss the noninteractive frontend case when this was implemented, and ISTR there were TODOs; do you recall what the plan was?
<cyphermox> slangasek: I don't remember the noninteractive part, except that "it needs to work" was implied, and clearly I screwed up
<cyphermox> but when you think of it hard, non-interactively it just *can't* work. it needs to be set aside for applying Mok changes later, interactively, or simply skipped.
<cyphermox> OTOH, this will be a moot point once we really do self-signing.
<slangasek> cyphermox: "it can't work" - the *package* needs to work
<cyphermox> well, the package needs to work -- I'm saying you can't do the changes for Mok non-interactively.
<slangasek> yes
<slangasek> cyphermox: my logs say there was a db_input without || true, which should fail if we're noninteractive
<slangasek> maybe that didn't stick?
<cyphermox> all the db_inputs are followed by trues.
<cyphermox> (at least AFAICS here)
<slangasek> this was in our discussion dated 2016-07-07
<slangasek> cyphermox: anyway, a full fix might want to be detecting that the question was not shown and gracefully resetting some state and exiting 0 with a message, instead of exploding the script
<cyphermox> I think the issue is probably that we should reset not only db_fset shim/${action}_secureboot seen false but also shim/disable_secureboot value.
<cyphermox> yes
<cyphermox> I'll fix it in a bit
<slangasek> I don't see that db_fset shim/disable_secureboot false is going to matter
<slangasek> or do you mean setting the value rather than the flag?
<slangasek> (in that case, also no, because when the question *is* displayed it should default to 'true')
<nacc> smoser: interesting
<smoser> ?
<nacc> smoser: http://paste.ubuntu.com/24195977/
<nacc> smoser: as to why lvm2-lvmetad failed to start a boot
<slangasek> cyphermox: I think the most robust is to handle this at line 83 when checking the secureboot_key values: if [ -z "$key" ] && [ -z "$again" ] && ! db_fget shim/${action}_secureboot seen && ! db_fget shim/secureboot_key seen ; then exit 0 # non-interactive, skipping; fi
<nacc> smoser: i think i have 'fixes' (will put in the bug and ask for some general review) for iscsid
<nacc> smoser: also i do think it makes sense in the lxd cloud-images to not put anyting in fstab (or maybe comment it out?)
<nacc> smoser: interestingly, as well, lvm2-lvmetad.socket fails to start in privileged containers too
<slangasek> cyphermox: followed up on bug
<slangasek> cyphermox: wondering if it 'exit 1' is better since we didn't do what was asked and it could leave the system unbootable
<chiluk> slangasek: if your new guy needs something to do https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166 has been neglected..
<ubottu> Launchpad bug 1626166 in lvm2 (Ubuntu Xenial) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,Triaged]
<chiluk> slangasek: afaik it's a systemd init scripts dependency issue.
<chiluk> slangasek: but I haven't looked too far into it other than confirming it.
<rbasak> chrisccoulson: seen bug 1671273?
<ubottu> bug 1671273 in firefox (Ubuntu) " PulseAudio requirement breaks Firefox on ALSA-only systems" [High,Confirmed] https://launchpad.net/bugs/1671273
<bdmurray> slangasek: Do you recall the plan for aptdaemon and bug 1623856? I thought barry said something about it in his remove aptdaemon email.
<ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
<bdmurray> slangasek: I've confirmed both changes work and improved the description / test case a bit.
<barry> bdmurray: aptdaemon's autopkgtests won't not fail
<barry> so it can't clear -proposed
<bdmurray> barry: so we need to waive it through?
<barry> bdmurray: either that or let it languish ;)
<bdmurray> well I think we should at least fix this bug
<drab> hi, not sure where else to ask this, but how am I supposed to get a terminal during a ubiquity install?
<drab> it fails and I can't figure out why
<drab> if I go back to tty1 I just fine a "a start job is running for Ubuntu Live CD Installer"...
<drab> and I can't get a shell
<drab> so there's no way for me to look at logs or anything really
<drab> I'm looking at https://wiki.ubuntu.com/DebuggingUbiquity
<drab> I've even tried to start the session with debug-ubiquity, but I still can't get any shell of sort
<drab> cjwatson: hi, you around by any chance? I think your name is listed on some of those pages for the ubiquity installer, would love some input
<Unit193> While cjwatson pretty much knows everything, cyphermox is in charge of Ubiquity these days.
<drab> Unit193: ok, thanks
<drab> cyphermox: ^^ any input would be greatly appreciated
<drab> this is Lubuntu xenial install btw
<drab> I'm trying to do some automated installation with preseeding and I'm having 2 problems: 1) partman doesn't want to just wipe my disk and insists on asking me what to do about it 2) the hostname is not picked up by dhcp and it's set to whatever is in the preseed (this works with the ubuntu-server installed btw, same kernel options etc)
<drab> actually, about 1), to be more precise, I get a "no root filesystem defined" error can't install at all
<drab> and this happens because the disk already has some stuff on it, but the d-i options should work to the extent of just wiping everything and continuing
<nacc> drab: both 1) and 2) work with the serrver iso?
<drab> 2) works. 1) still seems to fail with raid1 if other disks in the machine (ie 3rd or 4th) had previously raid on it
<drab> I'm retesting everything from fresh stuff to make sure I have correct error reports
<drab> and I just repro'ed on a clean desktop the ubiquity issue
<drab> with a disk that used to have windows on it
<drab> (well it still has, installation aborted so nothing got written to it)
<slangasek> bdmurray: the plan> certainly, any autopkgtest failures that aren't regressions should get ignored
<drab> so I figured out the problem with getting a shell...
<drab> it's a lubuntu bug
<drab> lxterminal to be precise, manifesting in the installer :(
#ubuntu-devel 2017-03-18
<drab> so the problem isn't partman, it's the raid detection
<drab> I got hold of the logs and partman doesn't even see sda
<drab> the kernel must be flagging sda as invalid or something because it think it has a screwed up raid
<drab> how that's the case I don't other other than and old windows install on that disk with fakeraid or something
<xnox> drab, can you change settings in the bios from "raid" to "ahci" ?
<xnox> but note that if you want to keep the windows dual boot
<drab> xnox: it was another box, the new box I moved the drive to is ahci, only linux
<drab> the thing is, we have a bunch of these old drives with win on it
<drab> and I can't use them without prevoisly zero'ing them
<drab> which I guess I can do
<drab> I wasted more time trying to find this bug than doing that at this point
<xnox> you should first boot to windows; configure it to always boot in safe mode; boot into safe mode; shut down; change from raid to ahci; boot into safe mode again; configure to boot windows normally; boot windows normally
<xnox> now you can boot into ubuntu installer and everything will be fine; and both ubuntu and windows will boot.
<xnox> there is no "update-initramfs -u"
<drab> I want ubiquity to wipe the thing, but it won't
<xnox> in windows; it only reconsiders which modules/subsystems to load in safe mode.
<drab> because it kicks off dmraid, it says there's mismatches on sda, drive is no go, and installation fails
<sarnold> xnox: I don't think drab cares about the windows bits :)
<drab> xnox: dude I'm not dualbooting, I don't care about windows :)
<xnox> drab, you must use the bios to disable raid controller detection.....
<drab> ...
<xnox> because thanks intel
<sarnold> lol
<sarnold> drab: you probably don't have to zero the whole drives either, I bet the first megabyte would be enough.
<drab> sarnold: yess, and I tried to call ubiquity/early_command and run dd, but it doesn't seem to be running at all
<drab> and I found posts saying that early command is pretty much ignored...
<sarnold> drab: do you have eno7ugh of these drives that you have to do it via the installer rather than e.g. rescue media or something?
<xnox> sarnold, i have seen intel uefi putting zeroed out drives into "damaged, making read-only"
<drab> eeer
<xnox> if one is still booting with raid on.
<sarnold> xnox: eww.
<drab> sarnold: the thing is my "boss" every now and then finds one of these disk,tries to automated install, it fails and that makes my life harder because, to his own credit, "automatic installs don't work"
<drab> I'm trying to bring in some more decent process and it's hard when process doesn't work
<drab> I guess I could add a dd step in the wiki for ppl to do, but it kinda sucks
<drab> here it's a world of copy/paste and manual repetition which is causing a lot of troubles, but I can't get it out of the system if automation indeed is broken... this is just playing against me atm
<sarnold> especially since they may blow away a drive they care about
<drab> nah, that they get, it's ok, it comes with a warning sticker on the box :)
<sarnold> it'll be a Fun Opporunity to test restore procedures? :)
<drab> sure :)
<drab> sarnold: any thought about that early command prob? does it work in your exp?
<sarnold> drab: sorry, no idea, I generall use the installer once every few years..
<Unit193> sarnold: Not even in VMs?
<sarnold> Unit193: the VMs are either crated by the security team's uvt which drives the installer, or cloud images, with no installer necessary
<jtaylor> can you use /run/initramfs/shutdown on ubuntu?
<jtaylor> trying to get my root dm devices properly detached on shutdown, this looks like the correct systemd interfacfe
<jtaylor> using dracut seems to work
<drab> so netcfg is definitely doing the wrong thing, I'm trying to look at the sources, but I can't quite figure out what's going on
<drab> anybody around that can give me some pointers?
<infinity> jtaylor: dracut puts systems in the initramfs, initramfs-tools does not.  initrfams-tools is correct, IMO. :P
<infinity> s/systems/systemd/
<jtaylor> infinity: is there a way to get initramfs on shutdown with initramfs-tools?
<infinity> jtaylor: So, there is no "correct systemd interface to use the initrd on shutdown" because pivoting into the initrd on shutdown isn't correct to start with (and completely ignores the fact that there are systems without an initrd)
<jtaylor> I haven't found another way to get dm-cache to shutdown properly
<jtaylor> dm-cache on root
<infinity> It can't be done after / goes readonly?
<jtaylor> I assume no, atleast it doesn't work out of the box
<jtaylor> you end up with an unclean shutdown and then it needs to consider the whole cache dirty and in need of flushing on reboot
<jtaylor> which takes forever
<Unit193> jtaylor: dracut isn't exactly the most supported, until recently you couldn't even install it without major haggling.  I wouldn't recommend it on a production system (as a person that's been using it for months), but if you do you'll likely need to turn /usr/sbin/update-initramfs into a wrapper.
<jtaylor> its just for me desktop which I break regularly anyway ;)
<jtaylor> Unit193: I assume you mean just make update-initramfs call dracut instead? the postinst is already setup, what else would try calling it directly?
<Unit193> jtaylor: There's a few things that try every so often, http://paste.openstack.org/show/McSGZjX8Sbzdxf3yLUF9/ does it for me.
<Unit193> Well, I think that's it.
<jtaylor> Unit193: thanks, I'll keep that in mind when something starts breaking
<jtaylor> up to now everything seems to work nicely, which is much better than the full disk corruption I had last time I tried dm-cache ;)
<drab> who/what can I email about netcfg? can't find a contact/place. also ubuntu seems to be tracking netcfg bugs on debian, so should I open stuff there? thanks
<drab> before reporting a bug tho I'd love to talk to someone... I've just looked at the netcfg code for the very first time and might be completely off
#ubuntu-devel 2017-03-19
<mwhudson> argh lp why do you hate me
<mwhudson> (nominating a bug for a series is timing out)
<mwhudson> (works now)
#ubuntu-devel 2018-03-12
<tsimonq2> kees: Since you're chairing the TB meeting later, you're welcome to skip my agenda item (well, a review of an action item I had); I didn't quite get the time to follow through with that but I will have something before the next TB meeting.
<tsimonq2> kees: Oh, and I totally misread the calendar, so unless I ping you after doing it tonight (which is possible, heh) then skip it...
<_Marek_> hi
<_Marek_> id like to ask about mdadm and ubuntu live install - i had 4 disks as raid5 starting with sda
<_Marek_> sda sdb sdc sdd
<_Marek_> during installation ubuntu accidentally picked sda instead of sdf
<_Marek_> does ubuntu automatically recognize its a raid disk or did it just wipe one disk?
<doko> LocutusOfBorg: any update on the llvm sanitizer issues?
<juliank> LocutusOfBorg: gnutls28 merged
<LocutusOfBorg> thanks juliank!
<doko> xnox: could you have a look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/c/cmake-extras/20180312_104032_b3956@/log.gz ?
<juliank> mvo: If I run command-not-found petname, it shows me "snap petname" (OK) and "deb petname ()" - the () are confusing, should there be something in there?
<mvo> juliank: its a bug, sorry for that
<mvo> juliank: let me upload a fixed version right now. I was holding the upload back because there is some further output discussion
<xnox> doko, thanks....
<juliank> mvo: not a big deal, I was just wondering
<mvo> juliank: its uploaded now
<mvo> juliank: most likely the output will be tweaked but at least the most glaring bugs are fixed now (and tests are much much better too)
<tsimonq2> mvo: If snapd isn't installed (like with Lubuntu), the snap output for command-not-found isn't shown, correct?
<tsimonq2> If not, I consider that a regression which I'll happily submit a patch for.
<mvo> tsimonq2: without snapd it should simply skip snaps - if that that is a bug
<tsimonq2> mvo: ack
<mvo> tsimonq2: if you notice any issues, please do let me know and I will fix
<xnox> infinity, back to our conversation about "auto-bumping d-i netinst size". Imho to catch the "crazy, d-i should not have grown by 2x" it should be an autopkgtest that compares sizes of new d-i, versus previous upload and/or versus release pocket of the last LTS.
<xnox> infinity, such that it would be an autopkgtest force-bad test, to say "nah, this is all good we really want to ship 10 MiB of network cards firmwares" vs "no this is dumb, somebody upload a fixed d-i"
<xnox> infinity, because the current feedback loop of FTBFS, re-upload to bump d-i by 10 KiB is not fun at all.
<xnox> and our current d-i sizings are not as tight as they could be.
<xnox> infinity, thoughts?
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<infinity> xnox: I think you're spending way to much time thinking about overengineering a solution for something you've had to commit *once* for in two years.
#ubuntu-devel 2018-03-13
<mwhudson> tsimonq2: congrats
<darkxst> bdmurray infinity, re bug 1751546, what generates the tasks in the archive, is it related to the germinate cron job that was disable last year?
<ubottu> bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Triaged] https://launchpad.net/bugs/1751546
<infinity> darkxst: See my follow up.
<cpaelzer> when I run the same gcc command on Debian and Ubuntu where does the collect2 gets its args from
<cpaelzer> They differ in my case between Debian and Ubuntu causing an issue (for Debian) that I want to resolve/understand
<cpaelzer> I moved to the gcc-7 in our proposed so both are 7.3.0-11 based
<infinity> cpaelzer: From the gcc spec and/or build options.
<cpaelzer> I thought I compared the gcc -v and other parts of a verbose build
<infinity> cpaelzer: gcc -dumpspecs will give you a (messy) view of that world.
<cpaelzer> infinity: can I let gcc list the build in defaults?
<cpaelzer> let me check that infinity
 * cpaelzer goes messy
<infinity> cpaelzer: But it's probably easier to tear open debian/rules* in the source package and see how the build differs between Ubuntu and Debian.
<cpaelzer> infinity: I
<cpaelzer> I'm already down toa simple commandline gcc call
<cpaelzer> behaving differently
<cpaelzer> and the dumpspec seems to prove that
<cpaelzer> I found what I assume to be the difference
<cpaelzer> Ubuntu has in the *link step "... --hash-style=gnu   --as-needed   %{shared:-shared} ..." while debian lacks the --as-needed in the same
<infinity> cpaelzer: Oh, yes.  We've been using as-needed for ages.
<infinity> cpaelzer: Have you really never tripped on that before today? :)
<cpaelzer> I tripped over it about 5 times I think
<cpaelzer> but not that Debian started to differ, because it didn't a while ago
<infinity> cpaelzer: If that's causing you issues, the answer is almost always not "the compiler is doing something silly" but "the build system is doing something silly".
<infinity> cpaelzer: command-line order matters with as-needed because deps are searched left to right.
<infinity> cpaelzer: And no, Debian didn't "start to differ" here, we've been diverged on as-needed for half a decade or so.  Since before you joined Canonical.
<cpaelzer> interesting
<cpaelzer> infinity: I actually fixed it in the build system of the package a year or so ago
<cpaelzer> but our dep8 test needs all that fixed up as well now
<cpaelzer> infinity: thanks for the right pointers
 * cpaelzer need to check old debian test logs ...
<cpaelzer> yep, you are right (as always) the difference was there in the past as well
<cpaelzer> it just now became an issue due to other changes
<cpaelzer> perfect, I think I can work this out now
<infinity> cpaelzer: Assuming you didn't fix it in an obscurely hackish way, you should forward those changes upstream.   as-needed fixes are always technically correct, and we're not the only distro that uses it as a default.
<infinity> We should probably reopen that discussion with Debian too, so we don't trip on the bugs first. :/
<cpaelzer> infinity: as I said upstream is good (in a non hacky fashion), I just want to fix the dep8 tests now so they work on Debian and Ubuntu without tripping over this
<cpaelzer> I think I can plug into the upstream build system on the test, which is actually more correct than a direct gcc call for the test anyway
<cpaelzer> needs some checks if it works as I plan it atm
<mwhudson> wait --as-needed isn't the default always and forever?
<infinity> cpaelzer: Well, fixing the gcc call is likely trivial too.
<mwhudson> til
<infinity> cpaelzer: You're likely doing something like "gcc -o foo.o -lbar -lfoo bar.o baz.o", just moving the libraries to the end will fix it.
<infinity> cpaelzer: The linker evaluates from left to right, and when it sees a library, checks if anything already linked references the library.  If not, it discards it.  Putting the libs at the end makes sure the earlier object references are already in play.
<darkxst> infinity, I guess vanilla-gnome-desktop was our attempt to keep the predicted 50% of ubuntu-gnome population that still want a un-modified upstream GNOME package
<darkxst> keep them happy
<infinity> darkxst: I suspect that 50% is rather high.  Most people don't actually care that deeply about such details.
<infinity> darkxst: (See the fuss that nerds make about a vanilla AOSP experience, while 99% of Android users really don't care at all and use whatever came on their phone).
<cpaelzer> infinity: it essentially is "gcc test.c -o testl.bin `pkg-config ...` and pkg-config brings in the stuff that then gets a bunch of "-l.." in (at the end which is correct per your comment above)
<infinity> darkxst: And I'm not saying the metapackage shouldn't exist.  We have metas for upstream KDE and XFCE (and other) experiences too.  But we don't have them in tasksel.
<cpaelzer> infinity: it works to build on both, but it increases the things linked and we checked on some of that
<cpaelzer> that is why I mean I want to fix mostly the test
<darkxst> infinity, its a hard thing to predict though! how many people used ubuntu-gnome just to get gnome-shell and how many still dislike the ubuntu themes!
<darkxst> infinity, if its made into just another generic task, how do we avoid it getting lost in the sea of generic tasks?
<infinity> darkxst: s/task/package/?
<infinity> darkxst: And we don't avoid it getting lost.  I mean, this is a super nitpicky "power user" thing.  We have no official flavour supporting this.
<darkxst> also it still has upload rights attached to the packageset, which the DMB are proposing to expand in order to get rid of desktop-extra
<infinity> darkxst: From my POV, it's better to have it difficult enough to find that the picky people have to know where to look.
<darkxst> infinity, it didnt really make sense to spin ISO's anymore, with Ubuntu moving to gnome-shell, but we fully intended to maintain the vanilla-desktop session
<infinity> darkxst: I mean, sure.  Maybe that's true.  But on the flipside, the supported upgrade path for Ubuntu GNOME is to Ubuntu.
<infinity> darkxst: ubuntu-gnome-desktop depends on ubuntu-desktop, and the release-upgrader makes that same assumption.
<infinity> darkxst: So vanilla-gnome-desktop is very much a "weird power user" thing, just like any other vanilla DE experience.
<infinity> darkxst: xubuntu more or less supports the vanilla xfce experience too (since it happens to land in their packageset), but there's no installer support for it, and it's very much a grey area of "supported, but not recommended, and not the product they focus on".
<darkxst> infinity, ok I will change tasksel to use package instead
<juliank> I don't understnad the vanilla-gnome stuff. It seems to override stuff in gsettings that's handled by per-session defaults, and work just fine by using the gnome session.
<darkxst> juliank, there might still be some overrides in there that are now redundant, with Ubuntu switching to gnome-shell
<juliank> Did USB audio break recently? I see my DAC just fine in alsa, but PulseAudio does not detect any sink on it...
<juliank> external mic is broken too
<cpaelzer> is there a best practise what set of ruby triggers to add on autopkgtests that fail due to the ongoing transition?
 * cpaelzer goes lazy and tries locally with all proposed
<cpaelzer> bdrung: any time to updates on bug 1753938?
<ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
<cpaelzer> how is upstreaming the changes going atm?
<doko> gcc-6 demoted \o/
<cpaelzer> gz doko!
<tsimonq2> mwhudson: thanks
<enyc> Somebody being assigned to  1601997 1365874  for 18.04 ?
<rbasak> bug 1601997
<ubottu> bug 1601997 in e2fsprogs (Ubuntu) "Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs" [High,Triaged] https://launchpad.net/bugs/1601997
<enyc> rbasak: thats the killer,  1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too...  tytso himself encourages!
<enyc> Secondarially, backporting e2fsprogs and grub2 in 16.04 and 14.04 would be helpful,  but less urgent if 18.04 (sensibly) rolls back the needless extra filesystem-flags.
<rbasak> To save others reading the bug, it's that Debian has enabled metadata checksumming by default, so filesystems created by the installer can no longer be fscked (possibly also not be mounted? Unclear from the report) by older LTS releases.
<rbasak> cyphermox perhaps? ^
<enyc> some verison can't even mount
<enyc> in any case its' a very annoying needless compatibility problem
<rbasak> But it looks like Debian have no intention of putting that into stable.
<rbasak> Seems like a relatively trivial FFe to undo.
<rbasak> (some theoretical risk of installer regression but seems unlikely to me)
<enyc> rbasak: undo the extra feature?
<enyc> [put back mke2fs.conf from older e2fsprogs, specifically]
<rbasak> Yep
<rbasak> Seems reasonable to me, but someone closer to the installer packages should decide
<rbasak> Or the release team.
<enyc> however, on the FFE front, tytso also reccomends we strongly consider e2fsprogs upgrade to 1.44  (though this is separate matter)
<enyc> would like support for some (non-default, but useful for some) flags  included from the outset in LTS
<rbasak> enyc: do you have references for that recommendation specifically please?
<enyc> rbasak: "1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too..."
<rbasak> Bug 1365874 seems unrelated to bumping to 1.44 to me.
<ubottu> bug 1365874 in e2fsprogs (Ubuntu) "Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming" [Medium,Triaged] https://launchpad.net/bugs/1365874
<enyc> rbasak: read comemnts, i check
<enyc> See comment #17 onwards
<enyc> i can see now there maybe should be many different bugs ;p
<rbasak> I see thanks.
<rbasak> slangasek, gaughen: ^ worth taking a look IMHO (not recommending we do it, just that it's worth considering).
<enyc> NB:   In MY view there are 4 actions in decreasing priority :   (1): revert mke2fs.conf in 18.04   (2): Upgrade e2fsprogs to 1.44.0 while keeping change 1   (3): Backport E2fsprogs [1.44.0 to Xenial] [1.43.9 to Trusty]    (4) Backport Grub2 (at least 2.02beta3) to Xenial and Trusty.
<enyc> I have not yet found/created a bug about 4
<rbasak> slangasek, gaughen: I tagged 1365874 for you. We don't have a bug specifically on syncing 1.44.0-1 right now, but that's mentioned in https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/comments/17
<ubottu> Launchpad bug 1365874 in e2fsprogs (Ubuntu) "Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming" [Medium,Triaged]
<rbasak> enyc: thank you for drawing attention to this.
<rbasak> enyc: backporting is much harder process-wise because of the risk of regressing users of stable releases.
<rbasak> enyc: but that can be quite separate as it doesn't have a deadline like Bionic does.
<enyc> rbasak: its going to cause all sorts of multi-booting and datacentre lvm/ext4 crap and weird things if not attended to.
<enyc> (1) is most important, risk-averse, imho =).
<rbasak> IMHO it's inconvenient, but acceptable, if an older release can't read a filesystem created by a newer release. That's the only way to move forwards sometimes. But if we can avoid the inconvenience at little cost, then it can be worth doing. It's a judgement call that needs to be made, and it's not my call.
<enyc> rbasak: nodsnods
<enyc> so far as I can see  its not really losing anything to revert...  we don't need >16TB support on ALL fs, and the extra csum is nonly if you have bad disk already sort of thing...
<enyc> thankyou for understanding and being interested to make "informed choices"[!]
<jbicha> juliank: I think it would be useful to drop the gsettings overrides from ubuntu-gnome-default-settings (moving some of them to ubuntu-settings)
<jbicha> ran out of time this cycle
<cyphermox> rbasak: if you're talking about an e2fsprogs FFe, up to you
<cyphermox> I'm fine with a backport of e2fsprogs, but this sounds like it has nothing to do with an "installer bug"
<enyc> I Guess a Single FFE could be used, import e2fsprogs AND revert (just for 18.04) the 64bit,metadata_csum change.  I note this makes a 'udeb' for the installer TOO, need to check.
<cyphermox> no, that's not the point.
<cyphermox> there are two options: either add metadata_csum to old releases by backporting, or reverting everywhere
<cyphermox> it's orthogonal to having a newer e2fsprogs in 18.04.
<enyc> I noted in bug, canonical partners may have views, onther non-ubunut-systems they support/interoperate w too.
<enyc> cyphermox: sure inded, but both (1) (2) go in same package/change/FFE
<enyc> backports complex SRU process apparently
<rbasak> cyphermox: that's not exactly the reason for my ping. I'm more bothered about whether we want metadata_csum on by default in Bionic, leading to installed filesystems that can't be handled by older releases. Is that something we can avoid by turning it off by default?
<cyphermox> enyc: my point is, you're mising up different processes
<rbasak> cyphermox: and separately, should we sync e2fsprogs to get the newer upstream release (which is a mostly unrelated question)?
<cyphermox> rbasak: I value filesystem integrity. My opinion is that we should keep it on if possible, especially looking forward
<enyc> tytso had views on both, he's ONLY JUST introduced metadata_csum by default in e2fsprogs,  he only put it on in debian a while ago to get  "testing exposure"  amongst more-technically-able-community
<cyphermox> rbasak: re: newer upstream, I'd say it missed the mark?
<rbasak> cyphermox: another way would be to wait an LTS cycle so that it can be brought in but while maintaining the ability of the previous LTS being able to handle the following LTS' filesystems.
<cyphermox> rbasak: tbh, I'd backport it, if the kernel in xenial-release supports it.
<rbasak> Since my ping, it occurred to me that perhaps messing with filesystems across different releases is a more server-y use case.
<rbasak> I'll see what my team thinks.
<enyc> think about dual-booters users...
<enyc> i've had many cases of older relase, wanting to rewrite/upgrade grub
<enyc> which then BREAKS the newer release booting
<rbasak> cyphermox: I appreciate your comments. I understand it's a trade-off. IMHO, I'd like us to make some decision and document it, eg. by closing the bug and release noting it.
<enyc> unless you go out of your way to  dpkg-reconfigure grub2  and tell it NOT to install grub any more
<cyphermox> rbasak: sure
<cyphermox> enyc: have you filed bugs about it?
<enyc> rbasak: I also don't think its an "either-or" case... its difficult either way.  "-backports" are not installed by default, I thought, too...  My "risk-managed" appreach would be to revert (only) for 18.04 and also start arranging backports afterwards.
<cyphermox> rbasak: well, this would be a question for not just the server team, perhaps to bring up on ubuntu-devel@
<enyc> cyphermox: its all in those 2 bugs above, but its important to see the history.  if a "please backport grub2 as well" is wanted, i can create another bug there too.
<cyphermox> rbasak: arguably you're just making sure e2fsprogs supports the feature, it could be "off by default" in the backport.
<enyc> cyphermox: YES thats a godo risk-managed approach
<rbasak> Agreed (to both)
<enyc> not everybody will install/have the backports, etc etc.  theres' little-adavantage to the feature, so.
<cyphermox> enyc: if you're written about a grub issue in the e2fsprogs bug, it's been missed
<enyc> cyphermox: menitoned in there
<rbasak> There's the separate question of whether the older kernel will mount it. Do we know?
<enyc> rbasak: from what i can see, trusty requires HWE kernel, xenial doesn't (i.e. 4.4 is ok)
<cyphermox> enyc: please file a separate bug about the issue, then we can decide if it warrants a backport or not (I think most likely not, but I can fix the bugs)
<enyc> rbasak: but don't forget about other distros people use about,  its not an ubuntu-only world
<rbasak> enyc: that doesn't sound too bad. Thanks.
<cyphermox> rbasak: not sure
<cyphermox> tbh, I wouldn't backport to trusty?
<cyphermox> hrm
<enyc> cyphermox: ok it may be this evening i do it, but i'll try to grub2 backport separately, link to the other 2 related bugs.
<cyphermox> otoh you "could", and depends on the hwe kernel then
<enyc> cyphermox: tytso had comments on that to..  I must stress reading ALL commends on both bugs.
<enyc> will do
<enyc> thankyou for starting to think, i know its complex
<cjwatson> If there's a grub change required in older releases, it should be a small cherry-pick, not a full backport
<rbasak> Imagine if we had a policy on this (just hypothetical; I'm not suggesting that we should). That policy might say "mounting/fscking a filesystem created by a future release is not supported", or "we maintain backwards compatibility for filesystem fsck and mount but no further than one LTS" or "we maintain compatilbity to all supported releases".
<cjwatson> We normally use the term "backport" for backporting full new releases, rather than cherry-picking individual commits
<rbasak> If we were to pick the middle option, then not backporting to Trusty would be reasonable.
<enyc> cjwatson: nods!  and it would be easier if that wasn't needed (for now) by 18.04 not using the controversial-to-enable extra-feature.
<enyc> rbasak: agreed
<cyphermox> rbasak: there's prior art saying it's "supported", at least to some degree
<rbasak> OK.
<cyphermox> that said, now I think we should backport to trusty too if we do it at all
<cyphermox> the metadata_csum change looks to have been made in yakkety
<enyc> IMHO if my (1) (2) can be done now, (3) (4) applying to trusty can be decided after-18.04-release if that helps.
<rbasak> And to clarify, that means I think there a few ways of getting to "supported" - by disabling metadata_csum by default on Bionic, by having the installer override it to not use it by default, or by backporting the necessary support to older releases.
<cjwatson> enyc: However, are you actually sure a GRUB cherry-pick is required?  Your comment is very vague.  64-bit support was added to GRUB's ext2 driver before trusty.
<rbasak> (my middle option is technically possible but seems too surprising to users to me to want it)
<cyphermox> rbasak: scratch the installer out of that, it's not the issue -- it will just use whatever is default
<enyc> cjwatson: im not sure, it would best need testing.  it could be the metadata_csum thats confusing it.   There is a lot of confusion about if  its' 64bit or metadata_csum that causes particular issues or not.
<rbasak> Yep
<enyc> cjwatson: there is some other grub devel messages about realizing they can just ignore metadata_csum entirely, and not sure when that was commited.
<cjwatson> enyc: I think you are mistaken.
<cjwatson> Or possibly confusing something.
<cjwatson> There's the metadata_csum thread which I started; I don't think anything has been committed for that yet
<cjwatson> But that's metadata_csum_seed
<enyc> cjwatson: thats what im saying ,there is confusion about between the 2 changes (which tended to come in together).  I'm saying, IMPORTANTLY that its ONLY JUST been turned on in  e2fsprogs by default within DAYS,  tytso also turned in on in debian "to get extra testing amongst more technically skilled".
<cjwatson> Which I don't think is what you're talking about here.
<enyc> cjwatson: indeed not, csum_seed is another matter
<cjwatson> There were no other relevant changes since 2.02~beta2.
<cjwatson> (regarding either of the features you mention)
<enyc> cjwatson: I am 100% aware facts would need to be double-checked over 64bit vs metadata_csum.  defenitely found anecdotes that 64bit compatibility required 2.02~beta3 ... would need test or investigate.
<enyc> which is in part why not posted bug baout that (4) aspect yet
<cjwatson> Your anecdotes, my checking the git history ... hmm, I wonder which is more accurate :)
<enyc> and what change is marked properly in git
<enyc> has some other change, fixed a bug that stopped that case working?
<enyc> i don't know
<cjwatson> The number of changes to the ext2 driver in GRUB is very small
<enyc> https://www.linuxquestions.org/questions/slackware-14/install-grub2-on-current-failed-4175580346/
<enyc> I'm well aware that area is uncertain and would need cecking/testing for bug to be raised w/ clear facts.
<enyc> Given that upstream e2fsprogs has ONLY JUST turned on 64bit,metadata_csum by default i'm not suprised if there are many issues and confusion lurking.
<cjwatson> All I'm saying is that it's unlikely that randomly updating the GRUB source will do anything here, because there are no changes that appear relevant.  (There are changes related to the meta_bg and mmp features, and one or two other bug-fixes.)  That linuxquestions thread is really too vague to be meaningful ...
<cyphermox> enyc: have you opened that separate bug report for the grub issues you're seeing?
<cjwatson> Filesystem drivers in GRUB are quite well-isolated; for this kind of thing it would be unusual for any change to any file other than grub-core/fs/ext2.c to be relevant.
<bigon> https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1683761 https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1754896 << Is anything missing for these bugs?
<ubottu> Launchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress]
<ubottu> Launchpad bug 1754896 in libnative-platform-java (Ubuntu) "Sync libnative-platform-java 0.14-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<cyphermox> bigon: I don't think so, looks all bugfixy
<cyphermox> tdaitx_: opinions? ^
<tdaitx_> cyphermox: bigon: seem all clear, maybe we should bump LP: #1754896 from whishlist to high as it would fix LP: #1683761 for bionic
<ubottu> Launchpad bug 1754896 in libnative-platform-java (Ubuntu) "Sync libnative-platform-java 0.14-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1754896
<ubottu> Launchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress] https://launchpad.net/bugs/1683761
<enyc> cyphermox: as above comments, i've said 2 things -- one would need to fact check to put in a decent grub report, two might be able to do that this evening.
<cyphermox> enyc: ok
<enyc> cjwatson: noted!  your investigations, suspect that grub2 back to xenial (only?)  what about trusty,  ought to be compatible with 64bit,metadata_csum ?
<enyc> one big risk is that a dual-boot installer goes ahead, then  older system (when booted-into, and updated) re-installs its own grub and breaks booting new-system.
<cyphermox> bigon: tdaitx_: cool. I will sponsor that then
<tdaitx_> tks ;-)
<cjwatson> enyc: Your guess about my investigations is wrong; I checked back to 2.02~beta2, which is in trusty.
<enyc> cjwatson: i asked you "what about" and a (?) in there, i did not 'guess'
<enyc> cjwatson: so, your investigahions suspect both should be ok
<enyc> acid-test is to bios-mode install a 14.04, and a 18.04-test dual-boot, then update-grub on the 14.04
<cjwatson> enyc: "suspect" = "guess" :-)
<cjwatson> enyc: I currently see no reason why trusty's GRUB would be incompatible with 64bit,metadata_csum
<cjwatson> enyc: You can also just use grub-fstest from 14.04's GRUB packages (would probably even be doable in a chroot)
<cjwatson> enyc: Or indeed grub-probe
<enyc> cjwatson: right yes sure,  though given upstream have ONLY JUST turend on the flag-by-default (in days!!!) theres every possibility of not-well-tested/bugs in that regard too,  worthy of some test.
<cjwatson> enyc: Basically all GRUB's filesystem code can be run from userspace
<cjwatson> enyc: Sure, but in that case 16.04 would be incompatible too.
<enyc> cjwatson: yes, assuming any other "seemingly unrelated" chainge doesn't affect it.  acid-test should prefer the older-version.
<enyc> noted
<enyc> cjwatson: thankyou for the pointer abou grub-probe grub-fstest ...
<cjwatson> Bet you a tenner such a seemingly unrelated change doesn't exist. :-)
<enyc> haha
<cjwatson> (I understand the caution in general; my confidence is based on experience with how GRUB's filesystem code is laid out.)
<enyc> sure !
<cjwatson> I think it's much more likely that confusion is caused by *different ext[234] features*.
<enyc> howso? e.g. the _csum or something else?
<cjwatson> That linuxquestions thread you posted had a bunch of changes in mke2fs.conf.
<enyc> right yes
<cjwatson> So I'm suggesting it's more likely that one of those relates to one of the *known* changes since 2.02~beta2.
<enyc> useful feedback, still worthy of test hopefguly this evening,  so I can then post grub2 backport bug as relevant
<cjwatson> And that this is probably entirely unrelated to proposed changes in Ubuntu 18.04.
<cjwatson> Not backport, please.
<cjwatson> Cherry-pick, *if anything*.
<enyc> right i see
<cjwatson> Saying "backport" invokes quite the wrong set of processes.
<enyc> yes i mean  "grub2 needs fixing for compatibility, heres why, heres where it goes wrong"
<enyc> agreed
<enyc> whereas, e2fsprogs-wise,  tytso reccomends backport  interestingly.
<cjwatson> Upstreams nearly always do.
<cjwatson> We don't always agree :)
<enyc> nodsnods
<enyc> yes i was wondering something along those lines
<enyc> cjwatson: nonetheless... what do you make of this aspect...  tytso has "only just" turned on  64bit,metadata_csum upstream, 'for everyone',  --  he only turned it on in debian  for extra testing,  talks about " the average technical sophistication of a Debian vs. a Ubuntu user, compatibility constraints with Ubuntu LTS, etc."
<enyc> we've ended up with 'decision by default' sofar
<enyc> i guess he's also being conservative...   i don't know about  generalizitions  about debian-users vs ubuntu-users...
<cjwatson> enyc: I make nothing in particular of that.
<cjwatson> enyc: I'm not going to be drawn into the discussion in general beyond GRUB.
<enyc> ok =)
<doko> jbicha: brotli test failures on armhf, probably alignment issues
<jbicha> doko: fascinating that it works on Debian https://buildd.debian.org/status/package.php?p=brotli
<Laney> we're stricter on alignment
<doko> jbicha: they run 32bit kernels, we 64bit ones
<jbicha> I'm no good on endian/other arch issues so feel free to help out there
<bdmurray> xnox: Is the u-r-u task in bug 1749199 still valid?
<ubottu> bug 1749199 in ubuntu-release-upgrader (Ubuntu Bionic) "purge conf files on removal of upstart (was session fails to start after an upgrade from xenial to bionic)" [Critical,Triaged] https://launchpad.net/bugs/1749199
<enyc> cjwatson: [have saved image files to setup a test/vm later...]
<enyc> cjwatson: from what you say,  does update-grub  detecting other distros/multiboot-entries,  work entirely from userspace reading,  no actual "mounting" of other-filesystems to check?
<cjwatson> enyc: a lot of that is done by os-prober, which is an external tool
<cjwatson> enyc: os-prober tries to use grub-mount where it can, which uses GRUB's filesystem parsing code rather than doing a normal mount, but it does depend a bit on the version of os-prober and on various other details
<slangasek> rbasak: when you say you "tagged" 1365874 for us, what do you mean?
<rbasak> slangasek: rls-bb-incoming
<rbasak> slangasek: sorry, I might have mentioned the wrong one
<rbasak> slangasek: it was bug 1601997 I tagged.
<ubottu> bug 1601997 in e2fsprogs (Ubuntu) "Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs" [High,Triaged] https://launchpad.net/bugs/1601997
<rbasak> slangasek: the other is not really in a triaged state.
<rbasak> Though there's a separate request that needs a separate bug that nobody's filed asking for a sync for e2fsprogs.
<rbasak> slangasek: following the subsequent discussion with cyphermox above, he suggested that an ubuntu-devel@ thread might be appropriate, so I was going to write one up.
<rbasak> slangasek: though if you want to drop the default change by adding a delta, then there's no specific question for the list I think. Really it's just that like enyc said if we don't do anything we'd be making an implicit decision to break compatibility, and that's the part I don't like and would prefer such a decision to be explicit on the ML, bug, release note, etc.
<xnox> bdmurray, yes! there is merge proposal too.
<xnox> unless merged....
<xnox> if i find it
<xnox> if i committed it
<xnox> if i pushed it
<slangasek> rbasak: ok; from my POV, I don't see any reason to be concerned about filesystems created with 18.04 being incompatible with e2fsprogs from older releases by default
<xnox> bdmurray, https://code.launchpad.net/~xnox/ubuntu-release-upgrader/lp1749199/+merge/341342
<bdmurray> xnox: That should probably go in DistUpgrade.cfg.xenial too
<xnox> bdmurray, well... test in bionic first?
<xnox> bdmurray, i think i traced this to the right option....
<bdmurray> xnox: How do you propose testing it? And the upgrade path from A->B carries the same risk X->B.
<xnox> bdmurray, publish bionic-proposed, test upgrade from X->bionic-proposed; if good migrate that to bionic-release.
<xnox> bdmurray, rince & repeat same for xenial SRU.
<xnox> bdmurray, but i'm not sure how much we care about changing this in upgrades to xenial.
<bdmurray> xnox: The release upgrader downloads a tarball for the release to which you are upgrading so no SRU is necessary. Additionally, the upgrade from X->B will read the DistUpgrade.cfg.xenial file.
<xnox> and if this goes pear-shaped, i only want to revert/fix-up bionic only; rather than both.
<xnox> bdmurray, ok, then i missunderstood the code.
<xnox> bdmurray, i thought .xenial file is read in upgrades to xenial (e.g. by trusty)
<xnox> i am aware that the target tarball is downloaded. so at the moment i want to change the bionic+ tarball / behaviour only.
<coreycb> bdmurray: hi, can you reject horizon 1:2014.1.5-0ubuntu2.2 from the trusty unapproved queue and horizon 2:9.1.2-0ubuntu6 from the xenial unapproved queue?
<coreycb> bdmurray: sorry, really need to get in the habit of seeing what's already in the queue before uploading
<bdmurray> xnox: The extension is the "from_release" see DistUpgradeConfigParser.py
<bdmurray> coreycb: so reject the newer one not the older one?
<coreycb> bdmurray: just those specific versions
<coreycb> bdmurray: well actually you can also reject horizon 2:9.1.2-0ubuntu5 from xenial as i'll combine that with the new one
<coreycb> bdmurray: sorry this one too for trusty: 1:2015.1.4-0ubuntu4
<enyc> cjwatson: fwiw, is 32-bit vs 64-bit  OSes likely to make any difference at all  to my  14.04/16.04/18.04  Bios-based multi-boot / ext4-compatibility test I'm going to test-out in a VM later  ??.
<cjwatson> enyc: I wouldn't expect so
<slangasek> infinity, stgraber: TB meeting?
 * hallyn tries to recall....  is feature freeze applicable to universe?
<enyc> cjwatson: confirmed, Grub2 14.04 16.04  all happy with 18.04,  but e2fsprogs and kernels still give issues [checking issues there].  TJ- on the case r.e. iscsi host and guest OS..  i'll update bugs when I can, but essentially it doesn't require a grub2/os-prober/etc bug, now actually checked/confirmed!
<enyc> cjwatson: thankyou for looking-in/feedback earlier
<mwhudson> hallyn: yes
<hallyn> k
<hallyn> thx
<hallyn> wouldve been nice to get tpm-tools up to 3.0.x
<xnox> hallyn, hm.... where is that coming from?
<xnox> i guess you do not mean https://sourceforge.net/projects/trousers/files/tpm-tools/
<xnox> ah https://github.com/tpm2-software/tpm2-tools/releases
<hallyn> xnox: yeah - i have it built for artful in ppa:serge-hallyn/tpm
<hallyn> (trousers doesn't work with tpm 2.0)
<mwhudson> hallyn: FFe's do exist though :)
<mwhudson> and are pretty easy to get for universe packages a week after feature freeze begins
<hallyn> yeah i'd just do it except i would have to find time for a cleaner fix for the .pc file in tpm2-tss :)
<hallyn> if i figure that out i'll pursue ffe.
<hallyn> thx
#ubuntu-devel 2018-03-14
<xcyclist> I have been using https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, and for instance it says I should see 3 .deb files instead of dozens of files.
<xcyclist> Ubuntu kernel builds appear to put out a bunch of stuff, .deb files, .udeb files, and a .tar.gz file, that I don't see specified in a document accurately.  Is there a document I SHOULD  be reading, or can I help updating one that is old?
<xcyclist> Please advise how I can be most helpful in either asking a question, reading other documents, or updating inaccuracies.
<tsimonq2> xcyclist: Your question's good enough to me, you're just asking in the wrong place. ;)
<tsimonq2> xcyclist: Try #ubuntu or #ubuntu-kernel.
<xcyclist> Ok.
<xcyclist> Thank you.
<tsimonq2> You're welcome. Have a good day.
<cjwatson> enyc: thanks
<juliank> mvo: command-not-found feedback: it is not particularly helpful if I accidentally type lsa. It tells me there are 17 similar ones and to try apt install <deb name>, but not which packages. http://paste.ubuntu.com/p/v5zsTgyYpP/
<juliank> with lsx I get a list of commands and packages
<mvo> juliank: oh, that is a bug
<mvo> juliank: will fix
<mvo> juliank: thank you!
<cpaelzer> doko: I already had retriggered the ruby-libvirt test for libvirt with the right triggers (needs all proposed for the ruby things to work)
<cpaelzer> doko: I see you later on triggerd one as-is (which will fail)
<cpaelzer> doko: is there a way to cancel your test request from the queue?
<cpaelzer> good: ruby-libvirt {"all-proposed": "1", "requester": "paelzer", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
<cpaelzer> bad: ruby-libvirt {"requester": "doko", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
<cpaelzer> the second being about 7 pages below the former entry on http://autopkgtest.ubuntu.com/running
<cpaelzer> anyone else knowing if/how one can cancel test retires?
<cpaelzer> pitti: ^^ ping for being a subject matter expert
<pitti> cpaelzer: https://git.launchpad.net/autopkgtest-cloud/tree/tools/filter-amqp
<pitti> cpaelzer: but it needs to be run on the infra, i. e. only Laney, infinity, and a few others have access (not me any more)
<pitti> there's no public API for it
<cpaelzer> ok thanks pitti
<pitti> it's usually not a biggie, just some wasted electrons
<pitti> this makes more sense when one needs to remove a hundred wrong test requests
<cpaelzer> I thought I've had cases where the second (bad) test will again make it not migrate
<pitti> cpaelzer: I thought it wrote it so that "any pass wins", not "the latest result counts"
<cpaelzer> ok, if that is true I feel better
<pitti> but this is becoming a bit blurry, I'm afraid
<cpaelzer> in the current case it is the last missing bit, so I assume it will be migrated before it gets to the second test anyway
<Laney> I think that's right
<pitti> on second look at https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/autopkgtest.py#n165 , maybe I'm wrong
<pitti> but in the worst case, just re-trigger your's again
<pitti> uh, the queue is quite long right now
<pitti> kde update ho
<Laney> I'll just kill it out to be safe
<rbasak> enyc: metadata_csum is enabled in Debian stretch I think?
<doko> xnox: does xe-guest-utilities need a MIR?
<doko> in supported-cloud seed
<xnox> doko, it does
<xnox> doko, i've started to fill one out, but it is incomplete.
<ricotz> mdeslaur, hi, why is clamav depending on llvm3.9 while it ships an internal copy?
<mdeslaur> ricotz: which release?
<mdeslaur> debian typically strips out the internal llvm and uses the system one
<ricotz> 0.99.4+addedllvm-*
<mdeslaur> but when we backport for our earlier releases, the system llvm is sometimes too old, so we use the internal one
<ricotz> mdeslaur, afaics this is a special ubuntu repack?
<mdeslaur> yes, it's a special repack for our old stable releaes
<ricotz> it used llvm3.9 on bionic which seems odd
<mdeslaur> and I used it for bionic because debian is currently using a pre-release version
<ricotz> is uses *
<mdeslaur> only trusty actually uses the built-in llvm
<mdeslaur> xenial and later use the system llvm
<ricotz> I see, the version somehow suggested this is not conditional
<mdeslaur> when we released 0.99.4, debian didn't have a tarball yet
<mdeslaur> so I just used the same one I prepared for trusty, even though later releases didn't need the internal llvm
<mdeslaur> looks like debian has a 0.99.4 tarball in stretch, would could use that for bionic, but meh
<ricotz> ok, I also assumed this is a step to get rid of libllvm3.9 which is only used by libclamav7 in bionic
<mdeslaur> I hadn't considered that
<geofft> cyphermox: are there netplan packages for Debian? (or would you expect the dsc to build on Debian?)
<cyphermox> geofft: I expect it would build on Debian fine, the only issue might be version numbers for Depends
<cyphermox> I have yet to file a ITP for netplan.io in Debian.
<nacc> Odd_Bloke: are you working on any ruby packages right now?
<Odd_Bloke> nacc: Other than keeping an eye on autopkgtests to request retries, no.
<nacc> Odd_Bloke: ok, i'll start trawling
<nacc> slangasek: not urgent by any means, but samba 2:3.6.5-2ubuntu1 is unable to be extracted (dpkg-source -x) in modern Ubuntu, which means we can't get to a patches-applied state (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850843). Do you have any ideas of what we might do there? We could simply not import that patches-applied version, and I think it would have no impact to our new algorithm.
<ubottu> Debian bug 850843 in dpkg-dev "dpkg-source in stretch cannot extract samba_3.6.5-2.dsc" [Important,Fixed]
<nacc> But it would mean this one publishing event (or anything like it) isn't in our Git repo
<slangasek> nacc: my empty stomach is suggesting options to me that may not be constructive ;)
<nacc> slangasek: :)
<nacc> slangasek: like i said not urgent, just something to mull over when/if you have time
<nacc> slangasek: it doesn't *really* affect us, because we don't treat patches-applied imports as full failures (we figure it's a tooling thing and will get fixed by future fixes to dpkg/etc). However, in this case, there hasn't been much movement (possibly won't ever be) and it might make sense to provide some mechanism to deal with it. I think I'd be "ok" with a blacklist of source package, version tuples
<nacc> that we know don't work
<slangasek> nacc: yeah, that's probably reasonable in this case
<slangasek> it's sort of like, yes this version number exists, but it's associated with a thing that's not actually a source package :P
<nacc> slangasek: right
<nacc> i'll file a bug to document the idea, at least
<nacc> slangasek: and, since the patches-unapplied import does exist, it's possible to at least get the source package in Git and probably munge the patch so that it applies by hand
<slangasek> yep, the main problem is that it doesn't tell you which way to munge it is the correct way
<nacc> slangasek: yeah, in my mind the 'right' way would be to spin up precise, i guess and do it there :)
<nacc> mdeslaur: fyi, LP: #1744148 updated, i've assigned the two security tasks to you and uploaded the php7.2 update to bionic
<ubottu> Launchpad bug 1744148 in php7.0 (Ubuntu Xenial) "[MRE] Please update to latest upstream release 7.0.28 / 7.1.15 / 7.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1744148
<nacc> xnox: have you already fixed rails? Odd_Bloke mentioned you were working on it
<xnox> nacc, rails is fixed; but fixed rails showed that ruby-spring is broke; just now fixed ruby-spring https://launchpad.net/ubuntu/+source/ruby-spring/1.3.6-2ubuntu1
<xnox> nacc, then need to rerun rails (and rails-like) with all-proposed, to see if this ruby-spring fixes everything
<nacc> xnox: ack, i was just leafing through ruby-defaults and there are a few *rails* pacakges with failures; i assume you'll retry?
<nacc> xnox: ruby-turbolinks is agreat one, calls ruby2.3 explicitly  in it's dep8 test :)
<nacc> xnox: ah Odd_Bloke already fixed that one, just nees a retrigger
<nacc> it's a bit annoying that before the fixes were all in place, another ruby-defaults was uploaded
<xnox> yeah, but oh well, doko didn't know we were actively looking and manually re-triggering half of the things with the right triggers.
<nacc> yeah, it happens :)
<xnox> and were hoping to migrate current ruby-defaults; before merging in a bug fix.
<nacc> fun, ruby-turbolinks looks to just have raced (it's migrated already now acc'g to rmadison) the test rerun, so i'd let that settle and it can be retriggered without any extra flags
<nacc> ruby-sexp-processor looks ugly... "[BUG] Stack consistency error"
<nacc> ah fixed in debian, will sync
<nacc> already synced, nm
<mdeslaur> nacc: thanks! I'll work on them tomorrow
<nacc> mdeslaur: thank you, let me know if you need anything
#ubuntu-devel 2018-03-15
<xnox> nacc, retriggered all current regressions with all-proposed=1 which have ruby in the name, this should do it to clear up obvious things that are fixed.
<nacc> xnox: thanks!
<nacc> xnox: i'll pick it up in the morning
<doko> nacc, xnox: sorry. there were some unfullfillable b-d's needing >= 2.5.0
<doko> tjaalton: xorg-lts-transitional has an invalid dependency. see excuses
<tjaalton> doko: ok
<tjaalton> ah
<cpaelzer> bdrung: hi, any news to bug 1753938 and the related upstreaming?
<ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
<cpaelzer> hmm I should have read the bug updates before asking :-)
 * cpaelzer ponders why this missed the important flag in his inbox
<cpaelzer> ok, so for now V3 is on its way
<cpaelzer> keep me in the loop bdrung
<cpaelzer> I made sure also the upstream thread shows up at the top of my inbox
<cpaelzer> lets see what the V3 review brings
<cpaelzer> I'm lokking for hint on side effects of adding a debian/<pkg>.install file
<cpaelzer> my d/rules alwas had an override_dh_install that did dh_install and then some additional "install -m" calls
<cpaelzer> it did not have a debian/<pkg>.install
<cpaelzer> I added the latter
<cpaelzer> and since then the "install -m" seem to fail on target dirs not being available
<cpaelzer> I wondere if adding a debian/<pkg>.install did somehow stop it from creating those directories
<cpaelzer> (no .dirs file btw)
<cpaelzer> it is reproducible, I can take the debian/<pkg>.install out and it works again
<cpaelzer> I can add a .dirs file to fix it, but I'd prefer to understand how the addition of the .install file affetcs the directory creation
<cpaelzer> for those interested to help, reproducible with: "pull-lp-source chrony; cd chrony-3.2/; echo "debian/README.Debian /usr" > debian/chrony.install; dpkg-buildpackage -S -nc -d; cd ..; DEB_BUILD_OPTIONS=3 sbuild -Adbionic-LP-amd64 chrony_3.2-4ubuntu1.dsc"
<cpaelzer> or whatever your usual build setup is for the last step
<cpaelzer> the path I'm missing in the bad case is not mentioned at all in the good case, so it is hard to spot what creates it in the good case
<cpaelzer> ah found it
<cpaelzer> it is a single binary package package, so it has a install file and the <pkg>.install obviously overrules that
<juliank> So, I see that we have support for additional module signing keys in the kernel, but do we have support for signing dkms stuff automatically?
<sasluc_> I assume that the reason for the package Ganeti not being part of the bionic/18.04 release is, that not all archs on http://autopkgtest.ubuntu.com/packages/ganeti pass the test?
<doko> coreycb, rbasak: is it correct that tomcat8 is getting demoted?
<rbasak> dpb1: ^
<smoser> xnox: could you take a look at bug 1751797 ?
<ubottu> bug 1751797 in systemd (Ubuntu) "dns resolution only works for domains in 'search'." [Critical,Confirmed] https://launchpad.net/bugs/1751797
<smoser> It sure seems to me that this bug affects close to 100% of desktop users. I'm really surprised there isnt more screaming.
<xnox> smoser, i am surprised too.
<xnox> smoser, what's your $ systemd-resolve --status <broken device> ?
<xnox> do you have ~ in the search domain field?
<xnox> smoser, is your router "normal" ISP provided thing, or some crazy custom firmware WRT?
<xnox> smoser, and i guess i should move my desktop to use NM and check if i can reproduce this.
<xnox> doko, your export DH_RUBY_IGNORE_TESTS=ruby2.3 ruby2.5 in debian/rules do not appear to affect the autopkgtest which are autodetected and autorun by gem2deb autodep8
<xnox> doko, do you know how to make the packages ignore autopkgtest results too, not just build-time failures?
<xnox> hm, looks like
<xnox> test -f debian/ruby-tests.rake -o -f debian/ruby-tests.rb -o -f debian/ruby-test-files.yaml
<xnox> is what generates it
<smoser> xnox: posted to bug.
<xnox> smoser, THANKS!
<xnox> smoser, mine is similar http://paste.ubuntu.com/p/xS2vP87TGb/ and I do not have same problem =/ i use different domain and 192. addresses instead of 10. ; and I do not have extra route to 169.
<doko> xnox: sorry, no. ask #debian-ruby?
<xnox> smoser, can i please get $ nmcli c show 72c7fac3-c017-4b76-9954-b4fb08262376
<xnox> 181    /* If this link is never the default (e.g. only used for resources on this
<xnox> 182     * network) add a routing domain. */
<xnox> 183    route_only =   addr_family == AF_INET
<xnox> 184                 ? !nm_ip4_config_best_default_route_get (config)
<xnox> 185                 : !nm_ip6_config_best_default_route_get (config);
<xnox> hmmmm.....
<xnox> i smell that your routes might be causing something of above to fail.
<xnox> smoser, it smells like NetworkManager knows better and claims it is not the best route....
<doko> tumbleweed: do you have an idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/sphinxcontrib-doxylink/20180314_234233_02148@/log.gz ?
<smoser> xnox: added.
<xnox> smoser, can you explain your routes to me? e.g. what is this:
<xnox> IP4.ROUTE[3]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
<juliank> hmm, /dev/urandom on my T480s does 160 MB/s, my X230 had 260. hmm.
<smoser> xnox: "crazy" openwrt
<smoser> xnox: i'm not sure where that 169 route came from
<smoser> 169.254 is ipv4 link local
<xnox> smoser, reading network-manager code, instead of asserting that one ticked "only use this interface for resources on this network" it goes into guessing mode "how insane does this route look like"
<smoser> xnox: if you're suggesting i clicked some b utton for "only use this interface for resources on this network", then I' have to say that that *could* have happened. i'm quite incompetent with user interfaces.
<smoser> although the fact that i have a route to the interwebs *on* that network device would seem contradictory
<smoser> ie, i'm using it to type this message to you.
<smoser> so if network manager tried to only give me routes to local resources on that device then it failed.
<smoser> and looking at network config, i do *not* have a check in 'Use this connection only for resources on its network'
<xnox> smoser, yeah, and network-manager->dns->resolved-plugin doesn't seem to check for that checkbox, and instead tries to make an "educated" guess if this is a best route dns server, or not.
<nacc> doko: np
<nacc> mdeslaur: fyi, i think php5 might also be affected by (some of) those CVEs ?
<mdeslaur> nacc: yes, I'm doing updates for php5 too
<nacc> mdeslaur: thanks
<tsimonq2> stgraber: Hey, mind looking at my queuebot MP I proposed a few weeks back?
<tsimonq2> stgraber: Specifically: https://code.launchpad.net/~tsimonq2/queuebot/add-ubuntu-qt/+merge/33675
<tsimonq2> Er...
<tsimonq2> https://code.launchpad.net/~tsimonq2/queuebot/add-ubuntu-qt/+merge/336753
<stgraber> lets see if I still know how to use bzr
<tsimonq2> stgraber: Or you could just use https://github.com/mnauw/git-remote-bz
<tsimonq2> ...
<tsimonq2> https://github.com/mnauw/git-remote-bzr
<tsimonq2> I never use Bazaar directly these days. ;)
<dpb1> doko: yes, that was the intent
<doko> dpb1: the source as well?
<dpb1> doko: I feel like there is another question or concern behind that question? :)
<bdmurray> bigon: Could you add SRU information to bug 1683761?
<ubottu> bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [High,In progress] https://launchpad.net/bugs/1683761
<bdmurray> coreycb: does bug 1755027 need to be private? If so I'll reject the SRU upload.
<ubottu> Error: Launchpad bug 1755027 could not be found
<coreycb> bdmurray: it probably should be until all the updates are queued up
<coreycb> bdmurray: i'll add you to it
<bdmurray> coreycb: Its not about me but SRU bugs need to be public.
<coreycb> bdmurray: i think we can make it public when the updates are queued up. it's a security vulnerability.
<coreycb> bdmurray: does that work?
<bdmurray> coreycb: Sure are all these -dashboard packages in artful related to it?
<coreycb> bdmurray: yes but the vulnerability is in ocata and before. we might as well make it public now.
<coreycb> i should have updates by eod
<bdmurray> coreycb: okay, feel free to ping me when you want them reviewed.
<coreycb> bdmurray: ok thanks
<bigon> bdmurray: I don't think I still have the package here
<bdmurray> bigon: This is about update the bug report with a test case, regression potential etc.
<doko> dpb1: looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, a few binary packages are kept in main. I assume you should talk to the desktop team (libreoffice), if you want to demote tomcat8 altogether
<dpb1> doko: ah, I see, because of the servlet library
<dpb1> doko: ok, just the binary packages then
<tumbleweed> doko: I did notice some ply related test failures before, because they weren't using dh_python-ply to have tight enough dependencies. Been meaning to look at those
<dpb1> tomcat8 and tomcat8-admin
<tumbleweed> but this one is not that
<doko> dpb1: so still demote these binary package, even if we have to keep the source in main?
<coreycb> bdmurray: everything's uploaded into the corresponding unapproved queues for 1755027
<coreycb> bdmurray: there's a version of horizon in xenial-proposed atm that failed testing and needs to be rejected - 1725421
<bdmurray> coreycb: if its already in -proposed there isn't really a way to "reject" it. just upload a better one.
<coreycb> bdmurray: ok then the new version should be able to replace it
<coreycb> bdmurray: for some reason i can't target some releases in launchpad, for example trove-dashboard doesn't have xenial or artful series available
<bdmurray> coreycb: wow, that's weird.
<bdmurray> coreycb: The API let me add one...
<coreycb> bdmurray: that's promising
<bdmurray> coreycb: should this have been included in the sahara upload? d/p/fix-neutron-related-openstack_dashboard-imports.patch:
<coreycb> bdmurray: yes. unfortunately 7.0.0 is the correct version for artful but it was released too late so we have 6.0.0 in artful.
<bdmurray> coreycb: I ask as that patch has no bug reference or anything.
<coreycb> bdmurray: i understand. i could add one if you want. it hit a build failure running tests and that fixed it.
<bdmurray> coreycb: I think it'd be best.
<coreycb> bdmurray: ok. i need to step away for a little  but will do that and let you know when it's done.
<coreycb> bdmurray: uploaded a new sahara-dashboard to artful with bug #
<bdmurray> coreycb: Hate to be a pain but it didn't need a new version number since it hasn't been released anywhere yet.
<bdmurray> coreycb: You could just reuse ubuntu1.1
<coreycb> bdmurray: ok need a new upload? its just easier that way in our source repo rather than force pushing tags.
<bdmurray> coreycb: If its extra work for you its fine then
<coreycb> bdmurray: ok lets go with 1.2. thanks.
#ubuntu-devel 2018-03-16
<rbasak> popey: please could you add Skuggen to ~ubuntu-wiki-editors? His LP ID is lars-tangvald.
<rbasak> popey: also while you're there please also add ~nryeng.
<doko> coreycb, jamespage, rbasak: could I have feedback on https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/1735372 ?
<ubottu> Launchpad bug 1735372 in mailman3-core (Ubuntu) "mailman/mailman3: Please drop dependency on Python2 (demoting mailman)" [Undecided,New]
<gQuigs> seems to be going more towards a NAK for my Ubuntu Monthly Update Cadence Proposal but more comments always welcome!  https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2018-February/thread.html#17875
<gQuigs> To me, this is also the perfect couple of months to make proposals like this. So if you want to make a different proposal, please do :)
<popey> rbasak: sorry only just saw this. Will do.
<rbasak> popey: np, thanks!
<popey> rbasak: done
<phibs> Anyone know if launchpad is having issues? I'm trying to upload my GPG key and getting timeout errors.
<cjwatson> That's an isolated problem, though a known one
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/1753019
<ubottu> Launchpad bug 1753019 in Launchpad itself "Cannot import gpg key - Timeout" [Undecided,New]
<phibs> oh man
<phibs> 2 weeks ????
<cjwatson> wgrant: Do you think you could review https://code.launchpad.net/~cjwatson/launchpad/gpg-timeline/+merge/340554, please?  I'd like to have some hope of being able to debug this
<cjwatson> Yeah, I mean it's probably not going to go away by itself and the current instrumentation isn't enough to debug it (or I'm missing something).
<cjwatson> Though somewhat mysterious why it appeared in the first place.
<phibs> cjwatson: thanks for the info
<ahasenack> hi, who maintains gvfs in ubuntu? I'm tempted to bump this timeout[1] to see if the gvfs tests[2] become less flaky
<ahasenack> (hm, just a sec, I should have had the urls ready)
<ahasenack> 2. http://autopkgtest.ubuntu.com/packages/g/gvfs/bionic/ppc64el
<ahasenack> 1. https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1713098/comments/4
<ubottu> Launchpad bug 1713098 in gvfs (Ubuntu) "Frequent DEP8 test failures related to ftp" [Undecided,New]
<ahasenack> and https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1713098/comments/5
<ahasenack> https://git.gnome.org/browse/gvfs/tree/test/gvfs-test#n264 for the code
<ahasenack> alternatively, I was wondering about using Gio.MountUnmountFlags.FORCE instead of NONE
<ahasenack> but if there is a real bug there, FORCE might hide it
<jbicha> ahasenack: I know that Laney has a gvfs upload in progress :)
<ahasenack> reason I'm interested in fixing this is because my samba uploads always have a hard time with this flaky gvfs test :)
<ahasenack> jbicha: is it in excuses already, do you know?
<ahasenack> doesn't look like it
<ahasenack> also not in lp yet
<jbicha> there is a 1.36.0 upstream release, he hasn't uploaded his work to bionic yet
<ahasenack> I checked git and that particular test hasn't changed
<jbicha> right, I only mentioned it because you wanted to know who to talk to ;)
<ahasenack> nor has unmount_api(), which is what times out
<ahasenack> right
<jbicha> I think upstream was a bit surprised we used their tests, lol
<ahasenack> seb128 seems to have done a lot of uploads
<ahasenack> jbicha: I'm actually hovering over "submit bug" on https://bugzilla.gnome.org/enter_bug.cgi?product=gvfs, I have it filled out alreayd
<ahasenack> Laney: if you see this later/tomorrow/monday, would you be willing to "sneak in" a timeout change in https://git.gnome.org/browse/gvfs/tree/test/gvfs-test#n264 from 5 to, say, 10s, to see if the gvfs tests pass more frequently? (bug #1713098)
<ubottu> bug 1713098 in gvfs (Ubuntu) "Frequent DEP8 test failures related to ftp" [Undecided,New] https://launchpad.net/bugs/1713098
<ahasenack> or perhaps use Gio.MountUnmountFlags.FORCE instead of NONE in that unmount_api() call
<ahasenack> ok, have a great weekend everyone :)
#ubuntu-devel 2018-03-17
<King_InuYasha> hey, is there anyone here who can help me figure out how to request the rpm package to be sync'd from sid to bionic?
<ginggs> King_InuYasha: man requestsync
<King_InuYasha> ginggs: does that work for people who aren't ubuntu developers?
<tarzeau> rpm?
<tarzeau> ubuntu bionic is frozen, you need to request an exception, it's documented somewhere: https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
<tarzeau> King_InuYasha: works for anyone who can read, understand and follow instructions.
 * tarzeau wonders which package that is to be wanted sync'd
<King_InuYasha> tarzeau: https://bugs.launchpad.net/ubuntu/+source/rpm/+bug/1756566
<ubottu> Launchpad bug 1756566 in rpm (Ubuntu) "FFe: Sync rpm 4.14.1+dfsg1-2 (universe) from Debian sid (main)" [Undecided,New]
<Unit193> I think requestsync is in ubuntu-dev-tools which is in Debian, though doubt anyone would want to for a one off. :P
<King_InuYasha> Unit193: I spun an Ubuntu container for this, blech
<King_InuYasha> that was a lot of crap for one tool
<Unit193> King_InuYasha: Heh, and I thought installing a package might be a bit much for such a feat. :P
<King_InuYasha> Unit193: my machine runs Fedora
<King_InuYasha> and we don't have ubuntu-dev-tools in the distribution
<King_InuYasha> so I spun an nspawn container of bionic for this...
<Unit193> Right, of course not.
<rbasak> King_InuYasha: all the tool does is file a bug with the appropriate information. You can just file a bug by hand following the same pattern as some other sync request if you prefer. Bit late now I suppose.
<rbasak> (also I suspect that ~ubuntu-sponsors automatially gets subscribed to the bug; you'd need to do that by hand as well)
<juliank> it's also documented in the wiki: https://wiki.ubuntu.com/SyncRequestProcess
#ubuntu-devel 2018-03-18
<enyc> rbasak: i'm not sure when to apply SRU process or backport process  (compared to bionic-release) r.e.  1365874  xenial and trusty..  Obviously this will need much testing/QA for SRU.
 * enyc suspects "around or shortly after 18.04 actually released) ?  backports can start now?
<melodie> hello
<melodie> I come with a little question. After updating to the next ubuntu edition, I still get the message "trusty0403 clean" at the start of the boot. Which file might contain this version name and number?
<melodie> I have grepped around in the system and could not find a clue.
<TJ-> melodie: that looks the LABEL assigned to a file-system. Try "blkid /dev/sd*"  -- really a question for #ubuntu
<melodie> hi TJ-
<melodie> i look, and thanks, and I doubt this is a question for #ubuntu : who there could possibly know? It seems to me devel knowledge. :)
<melodie> but, you know what?
<melodie> you might be right about the fs label!
<TJ-> melodie: #ubuntu is the support channel. This channel is for Ubuntu developers to discuss software development
<melodie> that's probably it!
<melodie> I think you gave me the right answer! :D
<melodie> thanks a lot
<melodie> have a nice day
#ubuntu-devel 2019-03-11
<acheronuk> doko: why did you do 'Explicitly build using clang 7' for clazy? was that to do with kdevelop using 7?
<doko> acheronuk: build issues? I can't remember. Did you you for build failures?
<doko> in the publishing history
<acheronuk> doko: yeah, 1st thing I looked at. no fails that I could see.
<acheronuk> perhaps just as clang/llvm 8 was not officially released at that time?
 * acheronuk shrugs
<LocutusOfBorg> tjaalton, vulkan-loader sync?
 * LocutusOfBorg wants to see if vkQuake can run with it
<lag> cyphermox: waveform: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1819443
<ubottu> Launchpad bug 1819443 in debian-installer (Ubuntu) "Cannot boot installer on platforms requiring Device Tree" [Undecided,New]
<lag> dannf: xnox: -^
<xnox> lag, commented
<doko> LocutusOfBorg: virtualbox ping for openjdk-11
<tjaalton> LocutusOfBorg: i'd rather get them all first to the se version
<tjaalton> *same
<tjaalton> though i don't think it'd matter much if -validationlayers is synced later
<cascardo> LocutusOfBorg: can you take a look at https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1819352 ? patch attached
<ubottu> Launchpad bug 1819352 in virtualbox (Ubuntu) "virtualbox 6.0.4-dfsg-5 ADT test failure with linux 5.0.0-7.8" [Undecided,Fix released]
<lag> xnox: LP won't let me reply to you: "Timeout error, please try again in a few minutes."
<xnox> lag, i know, we must be running postgres triggers again, which stalls commenting for "a while"
<xnox> lag, i am sitting on two tabs with bug comments myself.
<lag> xnox: Nightmare
<xnox> wgrant, what version of postgres does launchpad run? I am told, newish postgres can do parallel/out-of-bound rebuilds of indexes and stuff, atomically, without blocking writes to tables.... And same helpful people do sell consultancy to upgrade people to newer postgresis.
<xnox> lag, ok managed to post two bug updates just now!
<wgrant> xnox: We're on 9.3, but the upgrade to 10 is pretty much prepped.
<xnox> wgrant, shiny!
<lag> xnox: Sweet, thanks!  \o/
<LocutusOfBorg> doko, I finished the work yestterday
<LocutusOfBorg> cascardo, ???
<LocutusOfBorg> cascardo, please check release archive :)
<LocutusOfBorg> tjaalton, thanks!
<Laney> xnox: yo, so I was just looking at systemd/arm64
<Laney> the boot-and-services seems flaky wrt gdm3 and test_no_options
<Laney> test_no_options looks for the kernel commandline in the journal but I think that's hidden by "Missed 50 kernel messages"
<Laney> which is "journal can't keep up with messages", not normal journald rate limiting afaics
<Laney> not sure about gdm3; guess: much slower to start up than the other things being tested, and the test is run "too early"?
<cascardo> LocutusOfBorg: awesome! thanks!
<xnox> Laney, i can test the "too early" condition.
<xnox> Laney, re: missed kernel messages -> i have no idea how to fix it, or why it happens. I wonder if kmsg kernel round robin buffer is too small?
<xnox> Laney, at one point I had both of those tests blacklisted. But possibly in Ubuntu packaging only, not in Debian/upstream.
<Laney> if we can't rely on actually seeing the kernel messages, maybe stop testing for them?
<Laney> I was looking in disco, so I guess the blacklisting got lost at some point :>
 * Laney goes to eat a sandwich and fail at the cryptic crossword
<xnox> Laney, well. it's bad that we loose boot time dmesg on arm64 and nowhere else.
<kstenerud> Does anyone know how debian/control is generated from debian/control.in? When I run debian/rules in php7.2, it generates a php7.2-intl package entry in the generated debian/control, but there's no such thing in control.in
<kstenerud> so where is php7.2-intl coming from?
<cjwatson> There isn't a general answer; generation of debian/control from debian/control.in is package-specific and you'll find it somewhere under debian/
<cjwatson> (It's also largely a deprecated procedure because there are so many pitfalls)
<cjwatson> I suspect that debian/rules.d/ext-intl.mk has something to do with it
<cjwatson> Looks as though each extension that gets added to ext_PACKAGES is substituted into debian/php-module.control.in and concatenated
<kstenerud> hmm ok
<kstenerud> I'm feeling a bit lost actually
<kstenerud> php7.2-intl is supposed to depend on libicu, but it doesn't, and that causes problems for php packages that use internationalization
<kstenerud> but when I look at php7.3, there's also no mention of libicu, and it just works
<kstenerud> so maybe it's just coincidence that libicu just happened to be somewhere in the dependency tree and it worked by chance?
<cjwatson> In general terms, that sort of thing should normally be handled by build-depending on libicu-dev, having the upstream build system detect its presence and link to it, and then the runtime dependency should automatically be substituted into ${shlibs:Depends}
<cjwatson> Hardcoding the runtime dependency would normally be a mistake
<juliank> Oh well, the new gbome-shell seems to be a fail
<juliank> ooh my Cursor is moving
<juliank> Ah it just took half a second to start
<kstenerud> hmm... it does depend on libicu-dev, and yet packages that depend on php-intl fail with an unknown symbol that is in libicu...
<juliank> [   51.971819] Freezing of tasks failed after 20.008 seconds (5 tasks refusing to freeze, wq_busy=0):
<juliank> this is odd
<juliank> It was trying to freeze user space processes at 51:29, 51:49, 52:11, and 52:32
<tsimonq2> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
 * juliank upgrades and tries a reboot again
<Laney> xnox: maybe, but as long as this dropped messages thing can happen it seems like there's no guarantee there
<xnox> Laney, true.
<juliank> OK, so it was topicons plus (installed from gnome.org) that was delaying the start
<juliank> Now I'm on a "GNOME" wayland session and can't get back to X
<seb128> juliank, what's the issue with the X session?
<juliank> seb128: oh I don't have a GNOME X session, only (I guess) an Ubuntu one
<juliank> oh, I think GNOME classic uses X, but it's stuck in classic mode obviously
<seb128> hum, I though we had both for GNOME, wayland/X
<juliank> seb128: Today's disco offers "GNOME", "GNOME Classic", "Ubuntu", and "Ubuntu on Wayland"
<juliank> seb128: Deleted /usr/share/wayland-sessions/gnome.desktop, and now I got GNOME on Xorg
<juliank> odd
<seb128> hum, I don't remember the details on why/how we did that
<seb128> didrocks maybe does
<seb128> but it sounds buggy to me, unless we did change that for a reason
<didrocks> I think default should only show Ubuntu/Ubuntu on Wayland
<didrocks> gnome-session which provides GNOME/GNOME Classic isn't installed by default AFAIK
<didrocks> (should be checked in the manifest though if something isn't pulling it by error)
<juliank> didrocks: I do have that installed
<juliank> didrocks: manually
<didrocks> juliank: so, you asked for it, you got it :)
<Laney> he's saying "gnome on xorg" is missing
<juliank> didrocks: The problem is not that I'm in a GNOME session, but that there is no "GNOME on Xorg" appearing
<juliank> Unless I deleted gnome.desktop in wayland-sessions, then it popped up
<juliank> s/Unless/Until/
<didrocks> yeah, I guess the decision for GNOME vanilla was to use wayland by default
<didrocks> and let the fallback to Xorg
<didrocks> as upstream desired vanilla experience
<didrocks> that was discussed a long time ago, with Jeremy or in meeting
<juliank> so, if gnome failed, it would fallback to gnome-xorg?
<didrocks> yeah
<juliank> Oh well
<juliank> Gotta fix gnome-terminal on Wayland
<didrocks> (to be more precise, this is done when GDM is loaded, so if GDM can't load gnome-shell on wayland, it will fallback)
<didrocks> I'm sure seb128 will be happy if you fix it on Wayland :)
<juliank> I have a custom gnome-terminal window with --class and --name, and it just shows up as "gnome-terminal-server" in wayland in the dock
<juliank> Which is not particularly helpful :)
<didrocks> we already did a lot of maintainance/fix for that on Xorg
<didrocks> I'm sure it's equally broken for different reasons on Wayland
<juliank> Last login, normal gnome-terminal also showed up as gnome-terminal-server with "?" icon
<juliank> until I closed all terminal windows and started terminal again :D
<seb128> didrocks, thx, I didn't remember if not showing "GNOME on xorg" was a decision or a bug
<seb128> sounds like decision
<seb128> good :)
<juliank> Aside from gnome-terminal application mapping, wayland has been fairly stable when I used it
<seb128> good to know :)
<juliank> and now it has fractional scaling I suppose
<bdmurray> has anybody looked at this failing test? http://autopkgtest.ubuntu.com/packages/s/sbuild/bionic/i386
<ahasenack> bdmurray: that rings a bell
<ahasenack>   * d/t/build-procenv: only install the built package if the chroot it was
<ahasenack>     built in matches the release of the host system (LP: #1806388)
<ubottu> Launchpad bug 1806388 in sbuild (Ubuntu) "DEP8 test builds uninstallable package most of the time" [Undecided,Fix released] https://launchpad.net/bugs/1806388
<bdmurray> ahasenack: okay, I'll hint it for now then
<bdmurray> ahasenack: Do you have any plans to SRU it?
<ahasenack> wasn't going to, but I could
<ahasenack> on its own, or is there some other sbuild sru that's imminent?
<ahasenack> if we hit this frequently enough, might be worth on its own
<bdmurray> How could we sort out what packages have autopkgtest relations with sbuild?
<LocutusOfBorg> klebers, can you please test https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1818049 ?
<ubottu> Launchpad bug 1818049 in virtualbox-hwe (Ubuntu Xenial) "virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function âget_user_pagesâ]" [High,Fix committed]
<klebers> LocutusOfBorg, I triggered autopkgtests with the kernels in proposed, I'll report the results back on the bug
<ahasenack> bdmurray: don't know, I'm not sure how it's decided which dependent autopkgtests are run, if it comes straight out of reverse depends or not
<Laney> and Testsuite-Triggers
<paride> xnox, vorlon, just a ping on https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1819438 tl;dr disco d-i fails on ppc64, the system is uninstallable
<ubottu> Launchpad bug 1819438 in debian-installer (Ubuntu) "Install fails on ppc64: partman: *** stack smashing detected ***" [High,New]
<ahasenack> even exim4 triggered an sbuild run
<LocutusOfBorg> klebers, see release channel
<vorlon> paride: thanks. do you know about the rls-dd-incoming tag to flag bugs to us for evaluation as RC?
<paride> vorlon, I don't.
<vorlon> now you do ;)
<paride> vorlon, so I just tag it rls-dd-incoming if I believe it to be RC?
<vorlon> yes
<paride> vorlon, done :)
<vorlon> paride: glibc published to the release pocket on March 5.  Perhaps this is fixed by the rebuild of d-i that just made it to the release pocket https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu566 do you want me to respin images so you can retest?
<paride> vorlon, that would be great, yes
<vorlon> paride: partman-base was *also* updated on March 5 so that's the next stop if the d-i rebuild didn't fix it
<vorlon> paride: running now at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server/+build/158934
<vorlon> (also: lame that nothing in the build log lists the version of d-i used)
<vorlon> oh, I guess that'd have to be in the debian-cd log and not the livefs log
<paride> vorlon, seems to be working now :)
<vorlon> paride: excellent
<paride> vorlon, I'll let the test run finish and then close the bug
<mwhudson> does anyone have a grab bag of reasons a package might fail to build on launchpad bug succeed locally
<mwhudson> network access is the obvious one i guess but i don't think it's that
<doko> fresh or tainted local chroot?
<rbasak> In main but universe dependencies required
<rbasak> --resolve-alternatives or simliar needed but not used
<Unit193> ddstreet: Howdy, looks like you put some effort into ubuntu-dev-tools (https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537), any chance you're going to merge that in to upstream and release to the archive?
<ubottu> Launchpad bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,In progress]
<CarlFK> mwhudson: on lp there is a log that should tell you
<CarlFK> mwhudson: er, for ppa anyway.  which is all I'm familiar with.
<mwhudson> doko: i make a fresh chroot for the test
<mwhudson> CarlFK: yeah, i'm well up with reading logs :)
<mwhudson> rbasak: yeah --resolve-alternatives is a good one but i don't think it applies here (and usually causes problems the other way around)
<Unit193> CarlFK: FWIW, yes official builds also have logs.
#ubuntu-devel 2019-03-12
<sil2100> xnox: hey! I was wondering about the SRU for LP: #1740894 - the bug mentions some systemd changes needed to be cherry-picked for everything to work nicely
<ubottu> Launchpad bug 1740894 in xkeyboard-config (Ubuntu Bionic) "KEY_RFKILL is not passed to userspace" [Low,Fix committed] https://launchpad.net/bugs/1740894
<sil2100> xnox: do you know if those changes landed in bionic already?
<acheronuk> doko: oh. re clazy, looks like autotests failed with new llvm defaults and clang 8. that explains that!
<acheronuk> should have thought to look at that yesterday
<kstenerud> Is there a way to download specific versions of a package from command line? For example, download bash .deb file from xenial-security and bionic-updates to compare the two
<ddstreet> Unit193 yeah, as soon as buster is released i'll start pushing into the git repo.  I also want to create new unit tests before i push all my changes.
<rbasak> kstenerud: you can use chdist with apt-get -s
<rbasak> kstenerud: what I usually do though is grab the dsc URL using Launchpad's web UI and then use dget
<juliank> poa4/trusty is switching back and forth between <manref section=\"8\" name=\"apt-get\"> and <manref name=\"apt-get\" section=\"8\"> when parsing apt's guide.sgml into apt-doc.pot - fun
<juliank> :)
<ddstreet> kstenerud re: getting specific pkg version debs, use pull-lp-debs (from ppa:ddstreet/ubuntu-dev-tools)
<kstenerud> oh cool!
<ddstreet> for unreleased xenial-security, use pull-ppa-debs
<ahasenack> doko: are we good on the samba py3 stuff? I have some lintian warnings to fix, and of course update to the final release if that comes out in time
<doko> ahasenack: I didn't see any issues yet. thanks for these updates
<ahasenack> ok
<juliank> seb128, Laney can you change sound output/input in gnome-control-center? Does not seem to do anything for me
<juliank> in disco
<seb128> juliank, bug #1817338 ?
<ubottu> bug 1817338 in gnome-control-center (Ubuntu) "HDMI sound output not selectable in 19.04 (but works in 18.10)" [High,Confirmed] https://launchpad.net/bugs/1817338
<juliank> It changes the device to control volume on, but it does not reroute devices
<juliank> possibly
<juliank> sounds like it, yeah
<juliank> I'm using paprefs as a workaround
<juliank> um pavu
<juliank> pavucontrol
<juliank> ...
<Laney> we should assign that one to robert_ancell
<juliank> In my case, I have multiple devices and output configurations; a DAC, HDMI, Speakers
<juliank> it is, Laney
<Laney> then it should be in hand
<Laney> but thanks for raising
<juliank> good, I just did not find the bug myself :)
<Laney> :>
<Wafficus> Hello, question regarding AutoPiloy. i was told this was the automation qa tool used upstream by the ubuntu dev team. I help out with the Lubuntu team and am wondering what would be the process of actually using rhis same tool for regreasion testing alongside automating tbe lrkcess?
<Wafficus> *process
<Wafficus> *Autopilot
<Wafficus> *regression
<sarnold> don't forget *this   :)
 * sarnold runs
<Wafficus> haha you got me there. its hsrd etiting this in a small window
<Wafficus> hard*
<sarnold> you don't need to bother unless the typo would make it too difficult for someone to understand
<Wafficus> right
<Wafficus> so does anyone know anything regarding AutoPilot?
<juliank> dbus libraries in / on their way to main, is there anything usable for low-level tools like apt?
<juliank> There is libdbus but from what I heard it's rather complicated to use
<juliank> systemd's library is nice and might be an option depending on the scope of the use
<juliank> I'm considering two parts: (1) Having apt set systemd shutdown inhibitors (2) having apt provide a daemon for apt clients
<juliank> (1) can be using systemd's library, duh
<seb128> juliank, use gdbus from glib?
<sarnold> I think I like 1, but why 2?
<juliank> (2) might be d-bus or json-rpc over socket, reusing the same protocol as we (want to ) have for hooks
<juliank> sarnold: Sketching out the post-PackageKit-society
<juliank> seb128:  hmm, gdbus is probably a good choice
<seb128> juliank, it's probably the best dbus library around and it's well maintained
<seb128> bdmurray_, hey, do you have any idea why most of nautilus reports on the e.u.c/disco weekly view have no symbols? e.g https://errors.ubuntu.com/problem/d434a8139dce4cd6e987c0a1c124a1bc77ddc2fe
#ubuntu-devel 2019-03-13
<vorlon> cyphermox: can you tell me why zita-ajbridge is not showing up in the output of http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio despite having Task: ubuntustudio-desktop-core, ubuntustudio-desktop ?
<Unit193> mwhudson: Hrm, something weird in golang?  https://buildd.debian.org/status/package.php?p=gocryptfs&suite=unstable built fine a couple days ago, but in Ubuntu it failed https://launchpad.net/ubuntu/+source/gocryptfs/1.6.1-1, while retrying it now it's gotten even worse: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/9970424/+listing-archive-extra
<Unit193> Though backporting a couple libs and trying on cosmic was fine: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/9583688/+listing-archive-extra
<Unit193> I did find https://github.com/golang/go/issues/26832
<mwhudson> is our golang-golang-x-sys out of date?
<mwhudson> our default _go_ is somewhat behind debian's
<Unit193> It's older than Debian's.
<Unit193> Stuck in proposed, it seems.
<mwhudson> Unit193: does your ppa have proposed enabled?
<mwhudson> the arm64/armhf failures are timeouts?
<Unit193> It has backports, which may well exclude proposed.. :/
<mwhudson> golang-go.crypto tests fail
<mwhudson> TestInvalidTerminalMode
<mwhudson> dunno what's up with that
<Unit193> Based on Debian, autopkgtest will fail.
<mwhudson> sounds like time for a hint
<sarnold> I thought that said "sounds like time for a pint"
<mwhudson> that said TestInvalidTerminalMode has been there since 2012
<mwhudson> maybe openssh-server ignores rather than failing invalid terminal modes now?
<mwhudson> orrr maybe the packaging changed so this test is actually run now
<mwhudson> no, no idea
<Unit193> \o/
<mwhudson> ban i386: https://paste.ubuntu.com/p/vcpN3kDJfb/
<sarnold> wow. how'd that happen.
<sarnold> I mean I know floating point means you get the usual "lolwtf" output.. but still. that's not even close. :)
<mwhudson> only happens with rustc 1.32 too
<mwhudson> at least i think, i haven't absolutely checked that
<mwhudson> um no it happens with 1.31.0 too
<mwhudson> wtf
<mwhudson> https://github.com/paholg/typenum/pull/115
<sarnold> paholg?
<sarnold> hmm looks like he's upstream for typenum. TIL. :)
<Unit193> mwhudson: That one sitting in -prop, can you retry arm*?
<Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+build/16490024 suggests it should build fine.
<rbasak> tjaalton: why aren't you following the SRU verification instructions?
<rbasak> Please comment explaining what testing you performed and what versions you tested before you change the tag to done.
<rbasak> I can't be bothered to go through all your bugs where you haven't done this. Please go over them, tell me when they're all done, and then I'll take a look.
<tjaalton> rbasak: so if the description already says the test case, I'd need to again say what was tested?
<tjaalton> and how
<tjaalton> assuming this is mesa
<rbasak> tjaalton: "I followed the test case described in the bug description and the results were X" would be sufficient then (together with confirmation of the package versions tested)
<rbasak> I don't understand why you think just changing the tag is sufficient. If it were, why do you think we manually review instead of having a bot that just autoreleases on the tag change?
<rbasak> What do you expect me to manually review if you say nothing?
<tjaalton> rbasak: which bug are you talking about?
<rbasak> I was triggered by https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1789924
<ubottu> Launchpad bug 1789924 in mesa (Ubuntu Cosmic) "Missing Intel GPU pci-id's" [Undecided,Fix committed]
<tjaalton> it adds pci-id strings
<rbasak> Then I looked at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1815172 and you haven't confirmed the package version tested (as requested in the long standing template, and something I've brought up on ubuntu-devel@ before)
<ubottu> Launchpad bug 1815172 in linux (Ubuntu Cosmic) "Black screen on skylake after 18.0 => 18.2 update" [Medium,New]
<rbasak> And?
<tjaalton> I can grep the dri driver for the strings if that's enough. I don't have the hw
<tjaalton> yes the test case probably is overly optimistic in this case
<rbasak> OK, so say what you can and cannot do, what you consider to be sufficient testing, etc.
<rbasak> This is a perfect example. You didn't actually test, and in the bug you're implying you did.
<rbasak> The SRU team is supposed to make a judgement call.
<rbasak> You are preventing the SRU team from being able to do so by saying nothing.
<tjaalton> I don't know what you're asking for 1815172
<tjaalton> the change in 18.2.2+ was already verified, bug reopened because the new .changes file in 18.2.8 referenced the same bug (again)
<tjaalton> (because 18.2.2+ never got in cosmic, then bionic got the new 18.2.8 backport)
<rbasak> I don't think that's at all clear from your comment.
<rbasak> "bionic was already tested earlier": when? What package version?
<tjaalton> can't bother to go back to #13?
<rbasak> It wasn't obvious to me that this was relevant, because you apparently can't be bothered to actually explain and seem to expect me to mindread.
<rbasak> And given that you just admitted you tried to slip one past the SRU team in 1789924, I think my position is justified.
<seb128> you guys should perhaps step back and calm down a bit and assume people have good intend...
<seb128> tjaalton, it's standard practice to comment while change the tag to specify the version you tested (that was added due to the fact that we had regular cases of users testing and commenting that the fix worked/didn't work but sometime they still had the old version or a wrong one installed, stating the version used helps to give confidence the right one was used)
<seb128> it also doesn't hurt to state how/what you tested, again we had users who just changed tags
<seb128> so saying "I went through the testcase with version <v> installed, all worked as expected" isn't much
<seb128> tjaalton, seems reasonable?
<tjaalton> I should've said something in this bug yes. but upstream adding 10 pci-id's is impossible to verify along the sru rules
<tjaalton> same is true for any bug that requires certain hw
<tjaalton> err
<seb128> it's fine, sometime we can't test, then just add a comment "I didn't test by lack of access to the hardware, but the fix is right on principle and we didn't get report of regressions so ti makes sense to validate the SRU"
<tjaalton> no, of course isn't impossible, but adding pci-id's is *trivial*
<seb128> yeah, it's fine
<seb128> just add the reason
<seb128> the SRU team usually agrees when the rational makes sense
<seb128> I've no been annoyed by e.g libmtp updates which add a stack of new device ids and where we can't test them all
<seb128> not*
<seb128> just state that there is little potential for regression by adding those and that we tested and nothing is obvious broken on other systems
<tjaalton> did my best
<tjaalton> this time
<doko> tjaalton: could you have a look at the resteasy3.0 autopkg test regression in cosmic-proposed? All archs. http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/cosmic/amd64
<doko> succeeded in bionic-proposed
<tjaalton> doko: ok
<tjaalton> doko: well, that's odd, seems as if certutil failed.. anyway, that's while setting up pki-tps which likely no-one uses, so I think you can just ignore it. I don't have time to test it myself now
<doko> tjaalton: ok, thanks for checking
<seb128> unsure who unblocked curl if it's a side effect of other changes, but thx :)
<vorlon> cyphermox: I guess you missed my question about zita-ajbridge showing up in the ubuntustudio tasks but not in the packageset
<cyphermox> indeed
<cyphermox> vorlon: currently on a ho with rbasak to try and clarify our disagreement on packageset matters
<cyphermox> (or our lack of disagreement and figure out a good way forward, and then propose that to the DMB as a whole)
<cyphermox> it's been quite useful to make use of higher bandwidth
<Laney> that package ends up in desktop-core
<cyphermox> Laney: you saying it should?
<Laney> not necessarily
<cyphermox> afaict it does not right now
<Laney> but that's why you don't get it in ubuntustudio
<Laney> sure it does, grep your germinate-output
<cyphermox> I was looking at http://people.canonical.com/~ubuntu-archive/packagesets/disco/desktop-core
<Laney> not that, the germinate generated thing
<cyphermox> I know
<Laney> ok, well they're not the same thing
<cyphermox> no, I know; I'm just saying it's neither in that, generated this morning, nor in ubuntustudio
<cyphermox> so clearly there is still a subtle bug in the packageset update script
<Laney> I'd think you would want to investigate why germinate is putting it in 'desktop-core'(*not* the packageset)
<cyphermox> it looks to me to be entirely because it's only transitively referred to by desktop-core.
<Laney> that's what I'm saying
<Laney> +    'ubuntustudio/desktop-core': ['ubuntustudio'],
<cyphermox> yes, I'm looking at that
<Laney> k
<sarnold> bdmurray: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1819162
<ubottu> Launchpad bug 1819162 in openssh (Ubuntu) "package openssh-server 1:7.2p2-4ubuntu2.8 [modified: usr/lib/tmpfiles.d/sshd.conf] failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete]
<sarnold> bdmurray: https://pagure.io/SSSD/sssd/issue/3901
<Eickmeyer> vorlon: I'm looking at the logs from the latest build failure for ubuntustudio. Are we any closer to a solution? An idea I had was to remove the update-grub command from the postinst just to get it building again, but I know that would interfere with your investigation.
<mwhudson> Unit193: sure
<vorlon> Eickmeyer: if you want to drop the update-grub call, feel free; I don't think it significantly blocks my investigation.  The consequence is that new installs of Ubuntu Studio will have the bootloader unthemed in the meantime, but that seems to be status quo
<Eickmeyer> vorlon: Doesn't update-grub have to run at the end of the installl anyhow?
<vorlon> Eickmeyer: yes, I suppose it does at that
<Eickmeyer> vorlon: Okay. I'm going to go ahead and make the modifications in  the ubuntustudio-look package.
<Eickmeyer> vorlon: Quick question: since this will require a re-upload, should I bump the version number completely or just tack a "-1" on the end (e.g. 0.57-1)?
<vorlon> Eickmeyer: since this is a native package, you would normally bump the version number
<Eickmeyer> vorlon: Thanks.
<vorlon> a -1 would suggest you're switching it to non-native
<Eickmeyer> Good to know
<Eickmeyer> vorlon: I pushed the commit for the fix, and since it's under my PPU list, I'm learning how to upload it now, or at least looking for the wiki. :/
<vorlon> Eickmeyer: I don't know that the actual acl has been edited yet in order to let you upload
<Eickmeyer> vorlon: Oh, okay. In that case, it's ready, have at it?
<Eickmeyer> I did push the tag this time. :)
<cyphermox> Eickmeyer: in progress
<Eickmeyer> cyphermox: Awesome, thanks.
<cyphermox> actually, if vorlon wants to apply commands I'll send them in a bit
<cyphermox> vorlon: https://bugs.launchpad.net/ubuntu-community/+bug/1819970
<ubottu> Launchpad bug 1819970 in ubuntu-community "[TB/DMB] PPU rights for eeickmeyer" [Undecided,New]
<vorlon> yeah, let me run the commands and then Eickmeyer can do the upload himself
<vorlon> cyphermox: grub2-theme-ubuntustudio sees to not be the correct source package name
<Eickmeyer> vorlon: That's because I made an error when creating the project on launchpad. It's grub2-themes-ubuntustudio. Themes plural.
<Eickmeyer> Only reason for that was because it's forked from grub2-themes-ubuntu-mate. Themes plural again.
<vorlon> Eickmeyer: got it
<vorlon> Eickmeyer: acls added
<Eickmeyer> vorlon: Much appreciated.
<vorlon> and I'm confused that the acl for 'carla' worked
<Eickmeyer> Yeah, that shouldn't have considering it's not even there yet.
<cyphermox> I think LP knows about it because it's been uploaded to a PPA before.
 * Eickmeyer is currently uploading ubuntustudio-look directly for the first time
<cyphermox> yay!
<Eickmeyer> TIL my upload speeds stink.
<Eickmeyer> bbl, leaving to get my son from school
<Unit193> mwhudson: Thanks!
#ubuntu-devel 2019-03-14
<jibel> vorlon, thanks for your reviews and merging ubuntu-cdimage and debian-cd :)
<kstenerud> Question regarding modifying a patchfile in debian/patches: If it's our patch (and not debian's), is it better to squash the commit into the older ubuntu commit, or to leave it as 2 commits?
<doko> RAOF: please could you subscribe the mir team, or another team to yaml-cpp? still needed for the MIR
<cjwatson> kstenerud: I'd normally squash it in that case
<cjwatson> Assuming it's actually part of the same logical change
<tjaalton> hum, https://wiki.ubuntu.com/ReleaseSchedule is out of date
<tjaalton> I'll fix it
<juliank> ddstreet: So, the thing that comes to my mind when add-apt-repository private ppa, is that I want it to look like a normal ppa with a sources.list.d file, but an additional auth.conf.d file with the username and password.
<ddstreet> that would be great
<juliank> Optimally, it would like talk to launchpad so you can do add-apt-repository ppa:<blah> and it fetches the auth data itself, but that might be a bit involved
<ddstreet> yeah, it of course will need to switch from anon lp access to logged in, and actually getting the private ppa key and pw i haven't looked at how to do yet
<ddstreet> but *should* be possible
<juliank> ddstreet: The easier alternative is to go with     apt-add-repository 'https://<authorized launchpad url> <components>' and then extract the data from the url, and generate the filename based on it
<juliank> since they follow the form private-ppa.launchpad.net/USER/PPA
<ddstreet> yeah, that will still require the user to go into their lp private repo area and get the info tho, which is a pain
<juliank> Right
<juliank> but at least it avoids people having the auth data in sources.list :)
<juliank> (and getting warnings for that stuff)
<ddstreet> exactly, that is annoying since it's what users are told to do
<juliank> In general, add-apt-repository should ask for a repository name
<juliank> so if you add another repository where we cannot detect a name with auth data
<juliank> it should ask you to give it a name
<juliank> and then create sources.list.d/<name>.list and auth.conf.d/<name>.conf
<ddstreet> well if we keep the format of 'user/repo' we can just use that for the name, same as a public ppa
<juliank> yes
<ddstreet> just more work on the back-end to authenticate and gather the pw and ppa key
<juliank> I meant, outside of launchpad, where we don't have a name schema, we can ask users
<ddstreet> ah right
<juliank> I'd like add-apt-repository to show you a URL to launchpad.net
<juliank> it connects to another url
<juliank> then you click the first one
<juliank> and then launchpad authorizes the add-apt-repository process / sends it the auth data
<juliank> that'd avoid any logging in on the client side, which might be a good idea or a bad one, depending on the use case :)
<ddstreet> so you want to avoid using the normal non-anon lp login from python?
<juliank> I think if you use the non-anon login, it basically works in a similar way?
<juliank> But I'm not sure
<ddstreet> right it gives you a url to create oauth to lp
<juliank> It would be nice to have a page though that tells you "you requested access to this ppa, grant it?"
<ddstreet> once you authorize the oauth for some time period, then the lp login succeeds
<cjwatson> There doesn't seem like much point trying to avoid logging in if your proposal is to construct a special-case thing that requires you to go to the browser anyway
<ddstreet> hmm that probably would require changes to lp itself i think
<ddstreet> i think if we just make the user do the normal lp oauth login, then we dont need additional approval to add a ppa - i mean that's what they are doing with the add-apt-repo cmd anyway
<cjwatson> And if you just use the normal oauth token login process, then add-apt-repository on multiple private PPAs in succession would cache the token and just work
<ddstreet> we should leave the existing 'here's the repo description, press enter to keep adding it' prompt
<juliank> cjwatson: I think there are two use cases: End-user machines, where you want to cache the token; and shared cloud servers, where you don't
<ddstreet> i think the minimum oauth time is 1 hr, is that right?
<juliank> I think in the latter case, you'd like to have something like one login per repository, with the token scoped to the ppa you are adding
<cjwatson> I'd like to have more narrowly-scoped tokens for LP, but it's a big project
<cjwatson> (I made a start on that in early 2016, but it was hugely complicated and we put it on indefinite hold)
<cjwatson> https://code.launchpad.net/~cjwatson/lazr.restful/caveats/+merge/286796 was the start of it
<ddstreet> for the cloud server use case and/or lots of machines use case, there should be a param/option to add-apt-repo like you said before, to just pass the ppa and pw without needing to authorize to lp
<cjwatson> Or have a way to run add-apt-repository on a client system and push the authorisation to a remote system
<ddstreet> and probably a param to do the oauth to get the pw, but not actually install on the local system - then they can take that ppa and pw and deploy in cloud servers without needing oauth on those servers
<cjwatson> That way you don't have to worry about giving your credentials to a remote cloud machine, and you can benefit from local cred caching
<ddstreet> well, that gets into add-ap-repo starting to do cloud management stuff
<cjwatson> A bit like debsign -r
<ddstreet> hmm yeah
<cjwatson> It does, but it might still be overall simpler
<juliank> that's a good idea
<ddstreet> yep
<ddstreet> is there an existing bug to track adding this?
<juliank> We can combine that so that add-apt-repository -r remote ppa:something
<cjwatson> I don't know how it fits with existing cloud automation, but I guess if you're looking at prompting anyway then automation isn't so much of a thing
<juliank> basically resolves to ssh remote add-apt-repository 'https://foo:bar@private... blah blah'
<cjwatson> Passing secrets on stdin rather than on the ps-visible command line, I hope
<juliank> oh that's true
<ddstreet> i suspect anyone with large numbers of instances would want to get the ppa/pw once, then drop that into whatever orchestration tool they are using, chef, puppet, juju, etc
<juliank> add-apt-repository --stdin
<juliank> and then you can even have support for multiple repositories being passed on stdin
<cjwatson> person.getArchiveSubscriptionURL is probably the webservice method you want, BTW
<ddstreet> let's use this existing old bug to track adding this https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/645404
<ubottu> Launchpad bug 645404 in software-properties (Ubuntu) "Support Private PPAs" [Wishlist,Confirmed]
<juliank> I increased importance to low, as that's actually causing apt warnings with the auth data in sources.list, so it's more a bug than a feature these days :)
<ddstreet> juliank cjwatson thnx and i'll make sure to update the bug if i find time to start working on it (and will check first to make sure you haven't already started on it)
<juliank> ddstreet: I'm adding a comment with the summary of what we discussed
<ddstreet> awesome
<cyphermox> morning
<seb128> SRU team question, if a package got MIR approved and promoted in disco, can it be used for cosmic/bionic SRUs? is there a special process/consideration in that case? (we want to use libnfs to enable the gvfs/nautilus backend)
<rbasak> seb128: what do you mean be "can it be used" exactly?
<rbasak> Do you want to promote it in bionic/cosmic? Add it as a dependency of something else?
<rbasak> AIUI (though this is more AA territory) we can move something to main as an new publication in the updates pocket.
<rbasak> The rest is SRU exceptional with no policy, but I don't see any fundamental technical problem - as long as it's reasonable from an SRU perspective, which depends on the specifics.
<rbasak> So many typos. Sorry.
<seb128> rbasak, yeah, basically it's bug #1637988 and gvfs is in the queue
<ubottu> bug 1637988 in gvfs (Ubuntu) "Enable the nfs backend" [Wishlist,Fix released] https://launchpad.net/bugs/1637988
<seb128> but libnfs is still in universe in bionic/cosmic
<seb128> so basically it means I also need a no change upload for libnfs to have it promoted?
<rbasak> I'm not confident enough in the specifics - please check with an AA.
<rbasak> But yeah, that sounds about right to me.
<rbasak> I was going to ask if it would be easier to make it a Recommends instead for the SRUs, and keep libnfs in universe for users to opt-in perhaps. But it looks like it's compiled in so perhaps that's non-trivial (even if we did want it).
<seb128> rbasak, yeah, it's a lib the backend is using
<seb128> we can't make it optional
<ahasenack> doko: hi, does this ring a bell:
<ahasenack> x86_64-linux-gnu-gcc: error trying to exec 'go1': execvp: No such file or directory
<doko> ahasenack: apt install gccgo?
<ahasenack> I have it
<ahasenack> it pulled in gccgo-9
<ahasenack> a previous build log in lp pulled in gccgo-8
<doko> ahh, wait, I made 9 the default for gccgo, so yes, then you have to pull in gccgo-8 explicitly
<doko> gccgo-9 and golang-1.12 are both 1.12
<ahasenack> $ dpkg -L gccgo-8|grep go1
<ahasenack>  /usr/lib/gcc/x86_64-linux-gnu/8/go1
<ahasenack> ok
<rbasak> Oh, a Recommends would be insufficient, it'd have to be a Suggests, or a reverse Enhances. Anyway, not possible.
<doko> ahasenack: which package is this? just wondering why gccgo is used explicitly
<juliank> rbasak: the log for the u-u test case with the error messages has python3-apt 1.4.0~something, which is the stable versuin
<juliank> um
<juliank> rbalint: ^
<rbalint> juliank, rbasak it is upgrading to snapshot.debian.org/archive/debian/20171210T000000Z sid
<juliank> don't highlight him just because I accidentally did :)
<juliank> rbalint: ah ok
<juliank> rbalint: that explains a lot
<juliank> :)
<rbalint> juliank, i'll move to a later snapshot upgrade delta
<vorlon> jibel: sure thing - thanks for seeing this through!
<alkisg> Hi, (lib)parted in bionic has a serious issue that corrupts fat file systems (debian #840710). It's been fixed in cosmic+. The newer parted versions only contain bug fixes.
<alkisg> Should I ask for an SRU just for the one serious issue, or it can be considered a "microrelease" and backported as is, after proper testing of course?
<ubottu> Debian bug 840710 in parted "parted: Fix recognition of FAT file system after resizing" [Wishlist,Fixed] http://bugs.debian.org/840710
<teward> alkisg: I'd ask for an SRU for that specific fix
<alkisg> Thank you teward
<teward> since that's a nitpicked upstream commit to solve the issue, SRU team can review it once it's submitted for consideration
<teward> (this is also how I got the LVM2 resizing fix into Bionic before the last ISO point release)
<teward> (because gparted coldn't resize LVM2 PVs)
<alkisg> Gotcha
<teward> alkisg: but we'll still need an Ubuntu bug touching upon the issue
<teward> LO
<teward> :P *
<cjwatson> Agreed; that patch should be trivially cherry-pickable onto older series.  The microrelease path would be inappropriate here.
<rbalint> juliank, u-u test fails in cosmic, which is really bad, it seems it needs a fix
<juliank> rbalint: they do?
<juliank> You mean, the disco one is failing to upgrade cosmic?
<rbalint> juliank, yes, failing to upgrade systemd when there is a higher version in -updates
<ahasenack> doko: uwsgi
<alkisg> Do I need to prepare a debdiff or something, or can the patch file from cosmic be used?  https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1820090
<ubottu> Launchpad bug 1820090 in parted (Ubuntu) "SRU: fix FAT recognition after resizing" [Undecided,New]
<teward> alkisg: if you'd like I can prep the debdiff.
<teward> i'm not busy :p
<teward> alkisg: this is for Bionic?
<teward> and is this already 'fixed' in Cosmic+?  (wasn't clear on the bug)
<alkisg> teward: I'd very much appreciate it
<alkisg> Yes, and yes
<teward> alkisg: confirm for me, it's *any* FAT system yes?  FAT16, FAT32, etc.?
<teward> s/system/filesystem/
<alkisg> teward: I only tested with fat32, but afaik it's for any file system
<alkisg> *fat
<bdmurray> Did the output of 'date -u' switch from 24hr to AM/PM or is my desktop crazy?
<sarnold> o_O
<teward> alkisg: bug confirmed, i've picked up the bug and assigned it to myself, building a patched version in a PPA now, will test BEFORE I provide the debdiff to sponsors (I don't have coredev or Main upload rights but I'll at least generate the diff and get it to the point for sponsoring ASSUMING everything works as we expect)
<ahasenack> is there a draft for the disco release notes somewhere? https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes is not created yet
<vorlon> jibel: No such live filesystem with this owner/distroseries: 'ubuntu-canary'.
<vorlon> jibel: were you wanting us to set that up? :)
<jibel> vorlon, Yes please, that was our next request.
<alkisg> teward: I used "copy packages from primary archive to ubuntu" to copy/recompile the cosmic version for bionic, in my ppa, and I verified that it works. Not the same thing of course, just an indicator.
<teward> alkisg: right, but part of my 'testing' process for any SRU debdiffs I have is to PPA build-test (right now my local builders are busted :| ) and then use that in a test environment to make sure it works
<teward> at the MOMENT, apparently, there's some keyserver problems behind the scenes affecting my upload to the PPA at the moment
<teward> (and they're looking into it)
<Eickmeyer> Okay, question: Is there any place I can monitor the progress of an ISO build? Our last 8 builds for Ubuntu Studio have failed, but the ISO tracker at iso.qa.ubuntu.com says it's re-building, but I'm not sure if that's the one that I triggered yesterday or not.
 * Eickmeyer feels like a noob
<vorlon> jibel: done and rebuilding
<vorlon> Eickmeyer: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntustudio/
<Eickmeyer> vorlon: That's what I thought, so that doesn't show any current image buillding. Should I mauallly trigger one?
<vorlon> Eickmeyer: why?
<Eickmeyer> vorlon: I think the last build attempt had the version of ubuntustudio-look before I uploaded the fix removing update-grub from the plymouth theme install.
<vorlon> Eickmeyer: ok - sure, you can manually trigger
<Eickmeyer> vorlon: Thanks.
<vorlon> jibel: Subject: LiveFS ubuntu-canary/disco/amd64 failed to build on 20190314
#ubuntu-devel 2019-03-15
<jibel> vorlon, thanks, chroot: cannot change root directory to 'chroot': No such file or directory
<jibel> I'll have a look
<alkisg> teward: good morning, are there any parted builds available for me to test? Incidentally, I'm doing a seminar in half an hour, where 15 teachers will need fat resizing..
<doko> xnox: see https://bugs.python.org/issue35998 for the SSL TLS1.3 issue. for freebsd they run it with:
<doko>        if sys.platform.startswith('freebsd'):
<doko>             # bpo-35031: Some FreeBSD buildbots fail to run this test
<doko>             # as the eof was not being received by the server if the payload
<doko>             # size is not big enough. This behaviour only appears if the
<doko>             # client is using TLS1.3.
<doko>             client_context.options |= ssl.OP_NO_TLSv1_3
<doko> so not sure why it succeeds on some arm platforms
<doko> xnox: the bug report says, that this is seen with both 1.1.1a and 1.1.1b
<cpaelzer> kstenerud: php7.2 might have hit autopkgtest failures after your rebuild (succeeded?)
<cpaelzer> doko: ^^
<cpaelzer> please make sure to sort them out
<cpaelzer> doko: let kstenerud know if there is extra info to pass
<kstenerud> I've kicked off a new build and am waiting for it
<theBeliever> Hello, I am new to this IRC
<theBeliever> Hello.. I am wondering how software standalone installation packages are made.  I have a open-source repository on github, primarily written in python and cython. To build/run the repo, first user has to install C compiler and make a python environment with all the required dependencies and then issue the commands like "make", which can be lengthy and troublesome depending upon the OS for inexperienced users.  I am looking 
<theBeliever> installation workflow
<kstenerud> cpaelzer @doko Re-running the build failed in the tests:
<kstenerud> TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt]
<kstenerud> E: Caught signal âTerminatedâ: terminating immediately
<kstenerud> Only the amd64 build fails. All other succeed
<kstenerud> https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages
<doko> kstenerud: I was looking at the autopkg test failures
<doko> LocutusOfBorg, ahasenack: see you in the sbuild changelogs ... sbuild-update --keygen isn't anymore. is this by intent and is there a replacement?
<ahasenack> I didn't touch that, I fixed a tet
<ahasenack> test*
<kstenerud> I'm running sbuild manually to see what's going on
<doko> ahh, removed in 0.77
<ahasenack> kstenerud: the last test that it ran in that build is
<ahasenack> TEST 3443/14261 [ext/curl/tests/bug48203_multi.phpt]^ME: Caught signal âTerminatedâ: terminating immediately
<ahasenack> still 11000 tests to go?
<ahasenack> what happened in the other builds, which worked?
<kstenerud> Not sure. I remember it getting a lot farther when I ran locally, so Im doing another run
<xnox> doko, right. the last time when we passed all tests, things were racy under load, and didn't excercise any/much of tls1.3 stuff. fun
<ahasenack> kstenerud: you can check in https://launchpad.net/~kstenerud/+archive/ubuntu/disco-php7.2-fix-0050/+packages
<ahasenack> the other builds are there, no?
<kstenerud> There's only one build of that partiular PPA
<kstenerud> But I remember doing a local build before
<ahasenack> kstenerud: i386, arm64, armhf, ppc, s390, all passed
<kstenerud> yes
<ahasenack> so check them, see if they ran past that test
<ahasenack> you are looking at changes in behavior now: set "A" worked, set "B" failed, both built the same package
<kstenerud> Yup, the others ran through all the tests without problems
<theBeliever> Hello, new member here
<kstenerud> It's an odd test to be crashing on...
<kstenerud> PASS Variation of bug #48203 with curl_multi_exec (Crash when file pointers passed to curl are closed before calling curl_multi_exec) [ext/curl/tests/bug48203_multi.phpt]
<ubottu> bug 48203 in EasyUbuntu "Installed packages not deselected" [Wishlist,Fix committed] https://launchpad.net/bugs/48203
<ahasenack> kstenerud: do the others crash? IT's not clear to me if the test is expecting a crash (odd) or not
<ahasenack> probably not
<kstenerud> This is the only case in all of the different builds where it crashes
<ahasenack> might be a real issue then? :)
<alkisg> theBeliever: hi, this channel is about the development of ubuntu itself, not about development in ubuntu in general.
<alkisg> You might want to search for some other channel for questions for personal repositories etc; I don't know which one, have a look at https://wiki.ubuntu.com/IRC/ChannelList
<ahasenack> conversation should continue in #ubuntu-server
<theBeliever> thanks alkisg and ahasenack
<alkisg> theBeliever: you're welcome, although I don't think ahasenack was talking to you, so don't continue your question in ubuntu-server, it's not related :)
<ahasenack> right, I was talking to kstenerud, sorry :)
<theBeliever> thanks, haha
<LocutusOfBorg> oSoMoN, thanks for helping poppler, I did upload my package instead of your, just by mistake
<LocutusOfBorg> It was meant to go on ppa, not the archive...
<LocutusOfBorg> anyway, news wrt dropping llvm-4.0 from thunderbird and firefox?
<oSoMoN> LocutusOfBorg, wrt llvm-4.0, it's done for firefox
<oSoMoN> thunderbird is next
<oSoMoN> LocutusOfBorg, I'm lacking context, what package did you upload to the archive instead of  a PPA?
<LocutusOfBorg> oSoMoN, gdcm or I don't recall now
<oSoMoN> ah, no worries
<oSoMoN> we were both working on it at the same time, so not very efficient, but no harm done
<LocutusOfBorg> thanks!
<vorlon> jibel: I may have regressed livecd-rootfs for the layered case when trying to fix the ubuntustudio image build failures; look for the divert_grub stuff, and probably just revert that
<Eickmeyer> vorlon: Speaking of which, my removing the update-grub line from the plymoth theme postinst seems to have worked. Our images are building again.
<Eickmeyer>  I moved it to a metapackage that is used if someone wishes to rebrand their install for whatever reason.
<Eickmeyer> Not installed by default.
<vorlon> Eickmeyer: ok
<teward> alkisg: I'm not normally awake at 3:47AM.  I got a message this morning that it was finally 'accepted' but there was a keyserver issue that delayed it.  Let me check.
<teward> alkisg: there are packages at https://launchpad.net/~teward/+archive/ubuntu/build-tests for testing, I was going to test as well.
<alkisg> teward: thanks; sorry I didn't know your timezone :)
<alkisg> The seminar went fine with the package from cosmic
<teward> alkisg: Eastern US timezone, UTC-4 during DST
<teward> alkisg: indeed.  You can still test though :p
<teward> if it works I'll put the debdiff up :P
<alkisg> Sure
<seb128> I looked at the firewalld autopkgtest issues in disco that are blocking quite some other things
<seb128> there were a bunch of fallover from linux 5 in the test and ipset that needed to be updated, which I think I got resolved now
<seb128> but there is also an issue that looks like an iptables one that is fixing upstream but sort of new feature and require new things in libnftnl
<seb128> I put the details on bug #1820317
<ubottu> bug 1820317 in iptables (Ubuntu) "The firewalld autopackage tests fail due to iptables" [High,New] https://launchpad.net/bugs/1820317
<seb128> unsure who would feel like picking up the issue?
<seb128> jdstrand, ^ security team owns iptables it looks like?
<seb128> otherwise I would recommend we skip the firewalld tests failures for now
<jdstrand> seb128: we were discussing iptables yesterday. we need to work with joe and amurray on who will work on this
<jdstrand> joemcmanus: fyi, I gave you a paste of seb128's and my conversation
<jdstrand> seb128: joemcmanus and I discussed. I'll take a look at it next week
<jdstrand> Odd_Bloke: you might be interested in ^
<seb128> jdstrand, thx (sorry dropped offline when communiting back from where I was working in the afternoon)
<jdstrand> seb128: oh heh, we discussed it elsewhere, you didn't miss anything
<Laney> seb128: jdstrand: so I could badtest the version of firewalld that's in disco-release?
<Laney> less sure about the one in proposed though
<Laney> actually I'm confused as to why e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/firewalld/20190313_204532_a9818@/log.gz failed (this used iptables 1.6, and I thought you were saying it's an issue introduced by 1.8)
<jdstrand> Laney: please do not. I believe it is exposing a bug in the iptables new netfilter backend (it is supposed to be 100% replacement for iptables 1/6)
<jdstrand> 1.6
<Laney> vorlon: ^- I've got to go --- could you maybe work with those two to figure out the right set of hints for firewalld please?
<Laney> (if there is one)
<jdstrand> vorlon: nothing to see here :)
<Laney> jdstrand: right, but iptables 1.8 is only in proposed, so that wouldn't normally be present for test runs
<Laney> unless added explicitly
<jdstrand> I may change my tune next week, but for now, I believe it is legitimate regression
<jdstrand> Laney: oh, in *release*. I have no comment
<jdstrand> I just assume let me have a closer look which I'll do next week
<jdstrand> maybe we want to add a hint. don't know yet
<Laney> Bugs in 1.8 make sense to me and certainly shouldn't be hinted over, but what's going on in release with 1.6 - less sure
<Laney> At least one of the test failures seems to be because the kernel dropped a module that it was grepping for in lsmod
<Laney> not trivial enough for me to figure out right now, sorry seb128 :(
<seb128> Laney, yeah, that can wait for monday
<seb128> it's probably not a good idea to unblock things just on w.e anyway
<seb128> speaking of which, need to go, have a good one!
<teward|drone> alkisg: let me know when you've tested, my bouncer is offline at the moment but I'm still here ;p
<Laney> (I'll skiptest gtk+3.0, it's clearly nothing to do with that at any rate)
<jdstrand> Laney: re 1.6> sure. to be clear, I'm only tasked with fixing iptables, not firewalld in general so if you see stuff, do what you will
<sarnold> is our zfs installer in a state that would benefit from testing? how can I try it out? :) thanks
<vorlon> jdstrand, Laney: the log shows that the dependencies couldn't be resolved pulling only firewalld from -proposed, so the test was retried using all available packages from -proposed.  And firewalld blocks on the new version of iptables in -proposed due to library dependencies, so there's no point in trying to test against the release version of iptables
<alkisg> teward|drone: probably tomorrow, it's late in the evening here :) thanks!
<teward|drone> yep
<alkisg> teward|drone: late evening testing results: all good, fat32 works fine after the resize
<teward|drone> I'd test but I don't keep Windows computers here at home :P
<alkisg> teward|drone: the second test is good enough even without windows
<alkisg> I.e. file -s /dev/loop0p1
<ahasenack> hi, I'm debugging a build error in launchpad (ppa, but algo blocking a migration from disco-proposed). It's a test that only fails there (not dep8), locally it works. I'm zeroing in on the failed test, and noticed that it usees supplementary groups,
<ahasenack> and the lp user has a nameless supplementary group:
<ahasenack> uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild)
<ahasenack> 110
<ahasenack> I'm just wondering if that is expected, or indicative of some other problem in the builder, that doesn't affect anybody else
<teward|drone> alkisg: i got it to show more similar output to the same as initially... but different
<teward|drone> says its unlabeled and recognizes it as MSWIN4.1 and different sector sizes
<teward|drone> can't *test* to see whether it worked on Windows though
<alkisg> teward|drone: I think it's good enough to get uploaded for the bionic-verification-needed step
<alkisg> I'll do a lot more tests and report then
<teward|drone> ack
<teward|drone> i'll put the debdiff up
<alkisg> thanks!
<teward|drone> but i will have to wait for the sponsors and SRU team :P
<alkisg> Sure
<alkisg> There's no hurry; it's just good to have that in an lts release
<teward|drone> yep
<cjwatson> ahasenack: Which architecture(s)?
<ahasenack> cjwatson: the test fails in all, but atm I'm testing in amd64 and i386, and I inspect the logs in which ever finishes first, so both show that
<ahasenack> s/testing/troubleshooting/
<cjwatson> ahasenack: Odd - no sign of this mysterious supplementary group in the disco amd64 base chroot
<ahasenack> cjwatson: https://launchpadlibrarian.net/415286483/buildlog_ubuntu-disco-amd64.zeromq3_4.3.1-3ubuntu1~ppa11_BUILDING.txt.gz search for "DEBUG:"
<cjwatson> I believe you, just trying to work out what the source could possibly be
<ahasenack> maybe a build-dep adds that user/group
<cjwatson> Or could be sbuild itself?
<ahasenack> no, sbuild is 117
<ahasenack> uid=2001(buildd) gid=2501(buildd) groups=2501(buildd),110,117(sbuild)
<cjwatson> Sure, but the buildd user isn't in the sbuild group in the chroot, so sbuild is doing something
<ahasenack> ah
<cjwatson> Also there's a stray bit in /etc/group in the chroot which could be relevant
<cjwatson> buildd:x:2501:lamont
<cjwatson> Maybe something sees the nonexistent user and makes up a UID?
<cjwatson> If it's that, then it'll be fixed by the new clean chroots that we'll hopefully be switching to in not very long (oh hi infinity)
<cjwatson> But it's Friday evening and I have other things to do - could you file a bug against launchpad-buildd?
<ahasenack> about lamont being a member of buildd?
<cjwatson> Just about the problem in general
<cjwatson> We don't yet know for sure exactly where it is
<cjwatson> I'm just speculating that the stray user might be a problem
<ahasenack> and I also don't know for sure the test is failing because of this nameless group
<ahasenack> it's just a hint
<ahasenack> running test_filter_with_supplemental_process_owner_gid
<ahasenack> bounce: rc=-1, errno=11, attempt=0: Resource temporarily unavailable
<cjwatson> Well, what I really want is not to be looking into it on Friday night.  I don't mind exactly how you leave a note to look into it later :)
<ahasenack> sure
<teward|drone> alkisg: debdiff attached to the bug, and sponsors subscribed; once it's uploaded it needs to go through SRU processes :P
<alkisg> Great, thanks again teward|drone
<ilmaisin> hello
<ilmaisin> i can't find any recent info about the wayland plans, is it soon going to be the default?
<ilmaisin> gnome 3.32 will have fractional scaling, but it needs wayland to do it...
<wxl> ilmaisin: https://discourse.ubuntu.com/t/the-road-to-disco-what-features-might-go-in-what-features-actually-hit-the-repos/9347/41
<ilmaisin> wxl: so probably not in 19.04, but maybe after that? i'm wondering whether it will make it into the next lts
<wxl> ilmaisin: probably best to ask the desktop team, which is who's chatting there. you can also try #ubuntu-desktop
<jibel> vorlon, I see what the problem is with layered images. I'll propose a patch.
<jibel> there is no chroot/ after calling lb chroot_layered, the original chroot should be restored
<Laney> vorlon: don't see that in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/f/firewalld/20190313_204532_a9818@/log.gz sorry, what's the string to search for? (I'd have thought I'd see iptables getting upgraded, in that case)
<Laney> jdstrand: yeah, seb128's fixing the rest of it :>
<Laney> anyway, not really here, feel free to ignore me until next week
 * teward ignores Laney per request.  :P
<seb128> Laney, stop working, it's w.e time!
#ubuntu-devel 2019-03-16
<Fudge> lol
<dabbill> Starting 2 days ago, my 19.04 install stopped turning off my monitors when sitting idle.
<dabbill> I am running fully up-to-date install as of 2 hours ago, with Nvidia card.
<blahdeblah> cyphermox: Am I correct in reading web search results that netplan doesn't support ethtool settings on boot a-la ifupdown's "hardware-dma-ring-rx 2047" & such?
<ginggs> 'do-release-upgrade -d' tells me 'Can not upgrade - Your python install is corrupted. Please fix the '/usr/bin/python' symlink.' - my /usr/bin/python -> python2 - what should it be?
<Faux> Wrong channel, ginggs.
<Laney> juliank: jdstrand: you shall have your "gnome on xorg" option back with the new gdm :>
<juliank> Laney: :)
<dabbill> Any one have any ideas on how to track down why monitors are no longer going to sleep?
<dabbill> I am on Ubuntu 19.04 with nVidia card
<rbasak> dabbill: try #ubuntu for user support
<alkisg> What does "it's now in bionic UNAPPROVED" mean? Can I test or something?  https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1820090
<ubottu> Launchpad bug 1820090 in parted (Ubuntu) "SRU: fix FAT recognition after resizing" [High,Confirmed]
<dabbill> rbasak: thought I would need to ask here cause I am running beta release of Ubuntu.
<rbasak> dabbill: ah, #ubuntu+1 then
<dabbill> rbasak: thanks :)
<rbasak> alkisg: it's awaiting review. Once reviewed and if approved, it'll then be available to test.
<alkisg> Thank you rbasak
<tsimonq2> mwhudson: When you're online could you take a look at bug 1819936? Seems to be something you'd know more about, and I don't want to blindly sponsor.
<ubottu> bug 1819936 in golang-google-grpc (Ubuntu) "intermittent panic in 1.6.0-3 due to race in WriteStatus" [Medium,New] https://launchpad.net/bugs/1819936
#ubuntu-devel 2019-03-17
<Fudge> is anyone running the accessibility team anymore since Luke's departure?
<mwhudson> tsimonq2: looks like an upstream backport so seems like a good idea to get in i gues
<mwhudson> s
<mwhudson> ideally via debian but i guess that's harder rn
#ubuntu-devel 2020-03-09
<ahasenack> tjaalton: hi, any objections to sync sssd? The only meaningful change for ubuntu is the automounter one
<ahasenack> or is that something we shouldn't have yet?
<tjaalton> ahasenack: no it's fine, should be safe to sync
<ahasenack> xnox: hi, I saw you proposed my glibc branch for #1864864
<ahasenack> I added review slots, one for infinity specifically, and updated the MP description
<ahasenack> tjaalton: thanks
<xnox> ahasenack:  i reviewed it, just upload it.
<xnox> ahasenack:  it's ok.
<ahasenack> "just upload glibc, no biggie"? :)
<xnox> ahasenack:  yes.
<xnox> ahasenack:  we will be hunting thousands of autopkgtest regressions for weeks anyway
<ahasenack> xnox: could you please +1 in the mp then?
<xnox> ahasenack:  so it will take months to release it.
<xnox> ahasenack:  there isn't a single review that i can claim on that merge proposal.....
<ahasenack> oh, because you filed it
<ahasenack> xnox: try now
<xnox> ahasenack:  no, because you requested it from the three identical ~server team only teams
 * ahasenack cheating
<xnox> ahasenack:  none of which include core-devs =)
<ahasenack> the default review slot sucks
<xnox> ahasenack:  please dput into bionic unapproved.
<ahasenack> ok
<cpaelzer> ahasenack: your glibc MP is mostly for infinity to review than for us I guess
<cpaelzer> ahasenack: never the less the patch has no dep3 header making it harder to compare if it matches what got upstream
<cpaelzer> ahasenack: a) do you want to add that and b) do you also want a review from me or do you just wait for infinity to comment and probably sponsor it?
<ahasenack> I can add (a), sure
<ahasenack> and extra reviews won't hurt
<cpaelzer> ok
<cpaelzer> I'll revisit after ldap and bind then
<AsciiWolf> Wimpress, hi, your last steam package update has bad AppData and Steam (Steam Installer) is not available anymore in the GUI Software center on Ubuntu 20.04... is there any way I could help with resolving this issue?
<AsciiWolf> here is a Launchpad ticket: https://bugs.launchpad.net/hundredpapercuts/+bug/1864635
<ubottu> Launchpad bug 1864635 in steam (Ubuntu) ""Steam Installer" not available in Software app since latest Steam update" [Undecided,New]
<AsciiWolf> (btw. I wonder if appstream-generator is also available for proposed repo)
<seb128> AsciiWolf, he tried to fix it with https://launchpad.net/ubuntu/+source/steam/1:1.0.0.61-2ubuntu2 but if that's not enough and you know what is needed patch would be welcome
<seb128> Wimpress, the bug has this comment
<seb128> 'The problem seems to be with "<launchable type="desktop-id">steam.desktop</launchable>" that points to a desktop file not present in the package. I would try removing this line.'
<seb128> could be worth trying if that could be the issue
<rbasak> Is there any documentation on what to do about autopkgtest failures blocking proposed migration due to the i386 reduction work?
<rbasak> inspircd for example
<cpaelzer> rbasak: I don't know of documentation but when working on those there are certain categories of badtests - you'll see them when looking into the britney files
<cpaelzer> if it belongs any of the "known cases" add a unversioned badtest
<AsciiWolf> seb128, oops, I didn't notice the new build :)
<cpaelzer> if not it usually comes down to anlyzing the case and then considering if it is a new kind
<cpaelzer> if it is, discuss (with vorlon probably) if this should be a force-badtest or a fix (depends too mcuh on the cae to predict)
<cpaelzer> rbasak: but I agree having a recommended procedure dumped into some place as doc ould be nice
<cpaelzer> as everyone seems to know a few different bits of the whole thing
<AsciiWolf> seb128, Wimpress, I would try removing the launchable + re-adding "<icon type="stock">steam</icon>"
<AsciiWolf> that could help :)
<seb128> AsciiWolf, we discussed that with W_impress and he mentioned that the validator tool was complaining about the icon which is why he removed it
<cpaelzer> ahasenack: glibc MP wasn't refreshed yet, will take a look once I see it in my inbox
<ahasenack> cpaelzer: I'm just about to push
<AsciiWolf> seb128, yeah, I mentioned it in the ticket as well... the .desktop suffix in <id> is also not recommended to be used anymore, but these things somehow made appstream-generator used in Ubuntu happy :)
<seb128> AsciiWolf, the generator maybe needs an update to not bug on entries compatible with the standards?
<AsciiWolf> seb128, yeah, maybe :)
<AsciiWolf> anyway, try removing the launchlable without re-adding the icon tag... GNOME Software does not have issues with apps without icon anymore so these changes could be sufficient
<seb128> Wimpress, ^
<AsciiWolf> I just checked the AppData file from steam 1:1.0.0.61-2ubuntu2 and it looks fine except the launchable tag
<seb128> AsciiWolf, do you know if there is any other way to test those changes than going through an archive upload?
<AsciiWolf> seb128, I don't :(
<rbasak> !dmb-ping
<ubottu> ddstreet, rafaeldtinoco, rbasak, sil2100, slashd, teward, tsimonq2: DMB ping
<Wimpress> AsciiWolf: I made some changes at the weekend. No joy. Will revent the metadata.
<AsciiWolf> Wimpress, yeah, reverting the metadata changes will probably be best idea :) feel free to let me know if you need any testing after you upload the changes
<teward> rbasak: OK so I'm going to need first-timer guidance to edit-acl for giving rights to rcj.
<teward> but as for the announce email that's easy :)
<teward> Again no rush so i may bug you in the next 2 days - work is work after all and stuff just hit the fan
<rbasak> teward: the DMB doesn't actually have the ACL bits to change PPU rights specifically, so we have to ask the TB
<teward> ok
<rbasak> So this falls under that bit of part 2 of https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_application
<teward> so, ask the TB to create the ppu packageset for rcj, with upload rights to the package they were approved for then.
<rbasak> edit-acl does have some --help text
<rbasak> teward: here's an example: https://lists.ubuntu.com/archives/technical-board/2018-August/002403.html
<rbasak> So if you file a similar bug first, then write to the TB like that email, that should be all that's required.
<rbasak> I usually sign my email to the TB
<teward> yep, will do.  going through the email response to cascardo's application right now (as that's the easiest)
<teward> rbasak: DMB replies to unsuccessful applications to yes?  (the "What to do when unsuccessful" piece)?
<rbasak> teward: I'm not sure I follow your question
<teward> nevermind
<teward> rbasak: do you mind if I run my email through you for a glance before I send it?
<teward> since i'm new to DMB :)
<rbasak> Sure
<ahasenack> bryce: I believe the problem with uwsgi-plugin-php is the lack of a default python. strace shows it calling just "python" when building a plugin, and not findin it
<ahasenack> I'm investigating that now
<ahasenack> bryce: got it, this is "a" fix: https://pastebin.ubuntu.com/p/gjKr4wcy3Y/
<ahasenack> I'll file a bug and get started on it
<teward> rbasak: thanks for the guidance :)  I'll remember it all eventually but for now i have no more questions :)
<ahasenack> bryce: https://code.launchpad.net/~ahasenack/ubuntu/+source/uwsgi-plugin-php/+git/uwsgi-plugin-php/+merge/380440
<bryce> ahasenack, excellent thanks
<cmars> gnome-shell is crashing on lock screen in focal, where can i open a bug?
<sarnold> cmars: ubuntu-bug gnome-shell should be a good first start
<cmars> sarnold: ty
#ubuntu-devel 2020-03-10
<LocutusOfBorg> xnox, can you please consider merging gnupg2?
<ackk> juliank, hi, around?
<AsciiWolf> Wimpress, thanks for releasing the new steam package build! here is an appstream-generator page for the package in proposed repo: https://appstream.ubuntu.com/focal-proposed/multiverse/issues/steam-installer.html (it looks like the page wasn't generated yet, hopefully will be after some time)
<LocutusOfBorg> xnox, gpgme1.0 is broken by it
<LocutusOfBorg> I have it ready to upload
<AsciiWolf> Wimpress, or maybe this page will be generated instead if there are no issues: https://appstream.ubuntu.com/focal-proposed/multiverse/metainfo/steam-installer.html
<ackk> hi, could anyone please sponsor this upload for the maas package to focal https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/380426 ?
<rbasak> xnox: I think bug 1861304 has emerged as a valid regression-update caused by the move to openssl 1.1. Am I right that there's nothing we can do in this case either?
<ubottu> bug 1861304 in mysql-5.7 (Ubuntu Bionic) "libmysqlclient-dev will not install with libssl1.0-dev" [High,Won't fix] https://launchpad.net/bugs/1861304
<xnox> rbasak:  i'm failing to parse your comment there.
<xnox> rbasak:  libssl1.0-dev always existed in bionic. Both release pocket, and in the -updates pocket, as that's what src:openssh uses in bionic
<rbasak> xnox: AIUI, this user used libmysqlclient-dev and libssl1.0-dev from the release pocket originally
<rbasak> In a build that requires 1.0 and doesn't work with 1.1
<xnox> rbasak:  let me look at libmysqlclient-dev
<rbasak> And then we broke them by moving libmysqlclient-dev to 1.1
<rbasak> There's no easy way out for this user without patching our packages.
<xnox> rbasak:  libmysqlclient-dev in bionic-release pocket always required libssl-dev https://packages.ubuntu.com/bionic/libmysqlclient-dev
<rbasak> Therefore I think it's a regression we introduced
<rbasak> Oh, right.
<rbasak> And libssl1.0-dev has always conflicted with libssl-dev?
<xnox> rbasak:  but let me be sure with version numbers
<juliank> ackk: looking
<xnox> rbasak:  that is security version, not release.
<rbasak> Oh
<rbasak> At some point MySQL moved from embedded yassl to system openssl
<rbasak> That's perhaps an additional interaction here
<xnox> rbasak:  so i do see that bionic-release version 5.7.21 did not declare any libssl-dev deps
<rbasak> I think that hit stable releases too
<rbasak> xnox: thanks. That explains it
<mdeslaur> libssl got introduced as a security update because upstream removed yassl
<rbasak> I'll update the bug
<xnox> rbasak:  but 5.7.20 uses system libssl-dev
<xnox> rbasak:  now, the question i have if one can build and link things against mysqlclient-dev _without_ libssl-dev installed.
<xnox> and i think for shared-library builds the answer is that one doesn't have to
<juliank> ackk: Could you please fix your lintian warnings beforep ushing changes?
<juliank> W: maas source: newer-debconf-templates
<mdeslaur> xnox: I added libssl-dev to mysqlclient-dev because a bunch of things in the archive started FTBFS
<xnox> rbasak:  https://paste.ubuntu.com/p/Dh8fYtQtcT/ this is pkg-config file for mysqlclient. It does declare Requires.private: openssl => but that's for static linking
<xnox> mdeslaur:  hm, that is odd. Given that pkg-config file does not declare it =(
<xnox> mdeslaur:  well i care about bionic
<xnox> rbasak:  mdeslaur: it would be interesting to see if we can drop libssl-dev dep from libmysqlclient-dev _or_ if linking against ssl should be added in both Libs and Libs.private in the pkgconfig. It seems odd that pkg-config requires openssl, yet doesn't link against it..... as if libmysqlclient-dev includes openssl headers for like constants definitions.
<ackk> juliank, thanks, done
<xnox> rbasak:  it does seem like a regression. libmysqlclient-dev gained libssl-dev dependency, and we know that libssl-dev has conflicts in the archive.
<rbasak> xnox: thank you for confirming
<juliank> ackk: Uploaded
<ackk> juliank, thanks!
<xnox> rbasak:  but it is triggered by libmysqlclient-dev gaining that dep, I do wonder if libmysqlclient-dev is usable for example with libssl-dev | libss1.0-dev => that might be our escape hatch, if that doesn't affect api/abi of things that build against libmysqlclient-dev.
<rbasak> Yeah maybe
<rbasak> I'm not sure how to reliably test that for all cases, rather than just getting success with a lucy case
<rbasak> lucky
<AsciiWolf> Wimpress, it seems that the metadata are now correct: https://appstream.ubuntu.com/focal-proposed/multiverse/metainfo/steam-installer.html :-)
<AsciiWolf> thanks!
<AsciiWolf> it still does not show in gnome-software though (on a system with focal-proposed repo enabled), but I think that it just needs some time to sync the metadata
<ahasenack> what's going on with libcrypt1? I'm getting dep8 errors because it cannot be installed
<ahasenack>  slapd : Depends: libcrypt1 (>= 1:4.1.0) but it is not going to be installed
<ahasenack> I know there was something around this being fixed yesterday
<ahasenack> this test ran in the middle of the night
 * ahasenack retries s390x, whch is faster
<juliank> doko: ^
<juliank> ahasenack: I'm afraid stuff might go wrong until libcrypt1 and libc6 have migrated
<juliank> doko: I wonder if we should hack around libcrypt1 shlibs so linking to it continues to produce libc6 dependencies
<juliank> then stuff in proposed would not get drawn into this mess
<doko> juliank: won't work, libxcrypt is compatible with glibc's crypt, but not the other way around
<doko> ahasenack: where dod you see that?
<juliank> doko: yikes
<ahasenack> doko: in my  openldap dep8 results, check the recent two fails: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/amd64
<juliank> ahasenack: you can retry with glibc trigger, it should work - aka produce neutral
<ahasenack> I just retried s390x, no results yet: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/s390x
<doko> ahasenack: please add glibc/2.31-0ubuntu3 to the trigger
<ahasenack> I see
<ahasenack> ok, new s390x run triggered with that trigger
<juliank> hmm
<juliank> libxcrypt does not even use symbol versioing
<xnox> doko:  ahasenack:  libcrypt1 dep, imho should also generate libc6 (>= 2.31) too
<xnox> doko:  in libcrypt1.shlibs
<juliank> AFAICT libxcrypt has a superset of libc6's libcrypt symbols
<doko> xnox: how would that help?
<juliank> so if code does not use the new symbols, shouldn't it be possible to use it against old libcrypt?
<doko> ohh, I see, it would help for the autopkg tests
<juliank> ah I guess it requires the XCRYPT_* symbol(s)
<ahasenack> rbasak: hi, git master, I'm troubleshooting git signed tags and as far as I can see, it's a problem with pinentry, do you have any suggestions? https://pastebin.ubuntu.com/p/y7cZpr4QDg/
<ahasenack> this is in a container
<ahasenack> doko: the glibc trigger made it neutral indeed: http://autopkgtest.ubuntu.com/packages/o/openldap/focal/s390x
<ahasenack> or rather, made it run
<ahasenack> it was neutral already (the good case)
<ahasenack> I'll do it for the rest
<doko> mvo: could you have a look at https://bugs.launchpad.net/ubuntu/+source/piston-mini-client/+bug/1865960 ?
<ubottu> Launchpad bug 1865960 in piston-mini-client (Ubuntu) "failed to import piston-mini-client" [Undecided,New]
<mvo> doko: yes, in a meeting right now but will have a look
<ahasenack> rbasak: n/m, plain gpg isn't working
<ahasenack> and I found an odd workaround: export GPG_TTY=$(tty)
<AsciiWolf> https://bugs.launchpad.net/hundredpapercuts/+bug/1866841 - I think Ubuntu devs should consider adding this dependency to the ubuntu-desktop meta package
<ubottu> Launchpad bug 1866841 in ubuntu-meta (Ubuntu) "Add chrome-gnome-shell to ubuntu-desktop recommends" [Undecided,New]
<Eickmeyer[m]> Can I get a quick merge on an update to the Ubiquity Slideshow for Ubuntu Studo? https://code.launchpad.net/~eeickmeyer/ubiquity-slideshow-ubuntu/ubuntustudio/+merge/380461
<seb128> LocutusOfBorg, hey, your snowball upload is buggy, it doesn't fail to build but
<seb128> Checking output of danish stemmer with ISO_8859_1
<seb128> /bin/sh: 1: python: not found
<seb128> /bin/sh: 1: python: not found
<seb128> etc etc etc
<seb128> unsure if that impacts any of the generated file/the package or just fail tests which fail to fail the build :)
<ricotz> mwhudson, hi, please copy the packages from ubuntu-mozilla-security/rust-updates to rust-next
<xnox> LocutusOfBorg:  so my gnupg2 upload is now rejected
<xnox> LocutusOfBorg:  i'm slightly confused why you do duplicate work and ask me to do duplicate work too =)
<LocutusOfBorg> xnox, I thought you were not interested sorry, I didn't get an answer, but I have no bnc, so meh
<LocutusOfBorg> seb128, so, no regression lol
<LocutusOfBorg> tumbleweed, ^^ will fix
<tumbleweed> LocutusOfBorg: ta. I assumed you'd tested :)
<LocutusOfBorg> tumbleweed, I just applied the Ubuntu delta
<LocutusOfBorg> tumbleweed, I'm going to upload the current salsa.d.o master/debian branch
<LocutusOfBorg> your changes are cosmetic but better take them, right?
<LocutusOfBorg> seb128, can you please ack this? https://launchpad.net/ubuntu/+source/snowball/0+svn585-2~build1
<LocutusOfBorg> in any case seb128 a package that fails tests and doesn't fail build is sad, always sad
<xnox> LocutusOfBorg:  i was making d-i migrate without glibc, then had a gnupg2 upload staged
<LocutusOfBorg> oh... I thought you didn't care about the package, I see a lot of uploaders that did the last merge, so looks like everybody does it but not caring enough to do it many times
<seb128> LocutusOfBorg, the changes look fine to me, note that upstream fixed it by switching to call iconv instead of using python there, ideally Debian would get a non outdated version of that package
<LocutusOfBorg> seb128, mitya57 is working already on the new release
<mitya57> probably not for focal anyway
<mwhudson> ricotz: olivier ususally does that i think...
<ricotz> mwhudson, he isn't around, I asked him yesterday but I assume he missed it
<mwhudson> ricotz: ok, i'm sure i can figure it out :)
<mwhudson> ricotz: i presume it's usually copy with binaries?
<ricotz> mwhudson, yes, no rebuild is needed
<ricotz> mwhudson, ?
<mwhudson> ricotz: sorry, calls
<mwhudson> afk for 5 now but will try not to forget when i get back
<ricotz> mwhudson, alright
<mwhudson> the next step is remembering how copy-package works, of course
<mwhudson> ricotz: ok done i think
<mwhudson> (well publishing still needs to happen)
<ricotz> mwhudson, thanks!
#ubuntu-devel 2020-03-11
 * mwhudson pokes at glibc's build system, fails
<cpaelzer> rbasak: any idea why "git ubuntu tag --upload" would complain about "ERROR:Working tree must be clean to continue." while "git status --ignored" is empty?
<cpaelzer> ah, could it be that it has an empty dir issue?
<cpaelzer> I just checked out my current branch and got the "WARNING: empty directories exist but are not tracked by git:" ...
<cpaelzer> rbasak: by that the upload won't be matched anyway, would that also trigger the "must be clean" issue
<rbasak> I'm not sure, sorry. That behaviour always seemed a little buggy to me.
<cpaelzer> what confuses me is that it depends on the type of tag
<cpaelzer> --split almost always works whiel --logical almost never works (for me)
<rbasak> doko: would you mind reviewing bug 1864766 please? It looks like the right thing to do to me, but I'd appreciate your eyes.
<ubottu> bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress] https://launchpad.net/bugs/1864766
<heliocastro> Morning/afternoon
<heliocastro> After update from eoan to focal, ina XPS 13, X11 simply stop to proper work:
<heliocastro> Here's what is happening https://photos.app.goo.gl/MPv8Ef7BnUYA7VXb9
<heliocastro> Right now i'm using wayland
<heliocastro> Is there any report open against intel graphic drivers ?
<AsciiWolf> hmm, the snap version of gnome-software on latest Ubuntu Focal does not uninstall unused dependencies when uninstalling a deb application?
<AsciiWolf> or is there something wrong on my system?
<AsciiWolf> also, I was able to uninstall the Snap Store snap itself from the Snap Store app... this should not be possible at all
<AsciiWolf> I am not sure if I should report these as issues on Launchpad since they happen only in the snap version of gnome-software
<AsciiWolf> oh and another small thing: the "Open in Software" button from Applications tab in GNOME Settings does nothing when there is only a Snap version of gnome-software installed
<rbasak> AsciiWolf: https://snapcraft.io/snap-store says to use https://bugs.launchpad.net/snap-store/
<AsciiWolf> rbasak, thanks!
<kanashiro> hi, I am investigating the gem2deb/1.0.5 autopkgtest failure on armhf and it is complaining (reprotest actually) about the kernel version: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/g/gem2deb/20200311_020802_c6e4e@/log.gz
<kanashiro> if you check the log you will find: autopkgtest [01:38:52]: testbed running kernel: Linux 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:21:09 UTC 2019
<kanashiro> is linux 4.15.0 expected in an ubuntu focal testbed?
<ahasenack> vorlon: hi, for when you are online, when you have a moment, this is a seed change for a geoip library. I added a review slot for you at the request of the MIR team, because you were the one who added the geoip1 version to this seed way back: https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547
<ahasenack> teward: hi, I'm in the process of trying to bring libmaxminddb (for GeoIP2 access) from universe to main, and demote geoip1. There are only two rdeps in main, and nginx is one of them. I believe I just need to reshuffle the meta packages to require the geoip2 subpackage instead of the geoip1, and I'll put an MP up shortly and add a review slot for you
<ahasenack> teward: when you are around, for the moment the diff is in https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/8 as I can't push to a new git repo in lp (it's being worked on)
<ubottu> Launchpad bug 1861101 in nginx (Ubuntu) "[MIR]: dependency of bind9" [Undecided,In progress]
<rbasak> rafaeldtinoco: will your fix for bug 1866458 definitely also work on the release pocket Bionic kernel? Because we'll build with NLA_F_NESTED defined to non-zero, right?
<ubottu> bug 1866458 in drbd-utils (Ubuntu Bionic) "drbd not working after kernel upgrade 5.0.x -> 5.3.x" [Medium,In progress] https://launchpad.net/bugs/1866458
<rafaeldtinoco> yep
<rafaeldtinoco> without that flag set command rets error
<rbasak> rafaeldtinoco: I don't follow
<rbasak> I thought this worked without the fix on the original kernel?
<rafaeldtinoco> rbasak: new kernels containing a specific commit need that fix
<rafaeldtinoco> so if user is using HWE and upgrades to new kernel.. might have to have it
<rafaeldtinoco> ah I see what you mean
<rafaeldtinoco> sorry rbasak I was doing 3 simult things
<rafaeldtinoco> you are afraid of the flag
<rafaeldtinoco> being added to a kernel that does not need it
<rafaeldtinoco> +#ifndef NLA_F_NESTED
<rafaeldtinoco> +#define NLA_F_NESTED 0
<rafaeldtinoco> +#endif
<rafaeldtinoco> that part will make it ok
<rafaeldtinoco> or maybe I didnt understand what u meant
<rbasak> rafaeldtinoco: sort of
<rbasak> And yes, that ifndef would nearly make me happy
<rbasak> However that's a build time thing
<rbasak> In our case, presumably NLA_F_NESTED is always available at build time and is non-zero
<rafaeldtinoco> I see what u mean
<rafaeldtinoco> i was checking that
<rbasak> So how does something compiled with that work with an old kernel being given a flag value it doesn't recognize?
<rafaeldtinoco> linux/netlink.h:#define NLA_F_NESTED            (1 << 15)
 * rafaeldtinoco checks
<rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/drbd-utils/+bug/1866458/comments/11
<ubottu> Launchpad bug 1866458 in drbd-utils (Ubuntu Bionic) "drbd not working after kernel upgrade 5.0.x -> 5.3.x" [Medium,In progress]
<rbasak> rafaeldtinoco: thank you for checking!
<rafaeldtinoco> of course. im sorry for not having checked it before
<rafaeldtinoco> ill pay more attention to compile-time only variables being added
<rbasak> It's fine. That's the point of reviews :)
<rafaeldtinoco> yep
<rafaeldtinoco> =)
<seb128> vorlon, hey, could you get wpebackend-fdo to build on i386? it's a build-depends of webkit2gtk now
<Laney> we need mozjs68 for gjs now as well
<Laney> https://code.launchpad.net/~laney/ubuntu-archive-tools/mozjs68/+merge/380562
<vorlon> seb128: wpebackend-fdo added to the whitelist. so webkit2gtk got uploaded while there was a version entangled in the icu transition, and there were autopkgtest failures on webkit2gtk's revdeps in particular that were blocking.  are we going to get this through?
<seb128> vorlon, I noticed those but I didn't want to investage on an rc version when a new stable is out which might fix it, I will look at those failure if there are still there with 2.28.0
<vorlon> ok, as long as there's follow-through, thanks
<seb128> np!
<teward> ahasenack: NACK unless your rejiggered the NGINX code.  the inbuilt GeoIP doesnt work with geoip2
<teward> we had to pull in a third party plugin for it so unless libmaxmind is going to Main I have to disable some components on NGINX builds
<teward> I have no issues doing that but that removes the geoip functions from nginx-core
<teward> had this discussion with upstream when GeoIP Legacy went the way of the dinosaur and we pulled in geoip2 as another third party module
<teward> ah wait I misread.  bringing libmaxmind to main.
<teward> error:deadbrain
<teward> ahasenack: sec team needs to review geoip2 then
<teward> because that's a third party module
<teward> (the geoip2 in the package for nginx) - if Security OKs that third party module going to main then I can apply it
<ahasenack> teward: you mean review nginx's geoip2 core, not libmaxminddb
<teward> ahasenack: ehhhhhhhhhhhh
<teward> no
<ahasenack> is that a separate source tarball? Or a contrib/?
<teward> hang on a moment IRC from phone is inefficient
<teward> let me get to my PC
<ahasenack> teward: I'm on a call too :)
<ahasenack> teward: we can talk in 1h or later
<teward> lol i"m not heh
<cjwatson> FWIW I switched Launchpad to geoip2 in production a while back
<teward> just not out of bed :)
<cjwatson> (because geoip legacy is (a) legacy and (b) doesn't support ipv6)
<teward> cjwatson: right, that's why i pushed to get geoip2 added to the package as a third party dep
<teward> but here's the problem
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1825895 is the inclusion of geoip2 module
<ubottu> Launchpad bug 1825895 in nginx (Ubuntu) "Please include GeoIP2 module." [Wishlist,Fix released]
<teward> which is not from nginx.org upstream
<teward> it's in debian/modules/
<teward> which is where we load 3rd party modules (Debian's to blame here)
<teward> now, we had a strict thing with nginx-core to not have any third party modules back in the nginx MIR
<ahasenack> teward: I have to leave for about 1h, will be back later to read history
<teward> geoip is from upstream, geoip2 is *not* from upstream nginx and is third party
<teward> so if we're going to add that as a dep in nginx-core we need the SEcurity team to vet that module's code more thoroughly
<teward> (cc sarnold because I'm about to give you more work_)
<teward> now, if the Security team ACK's the geoip2 module that is third party for Main, then I can support this and push the diffs in
<cjwatson> I presume this is only an issue due to the desire to only have one or the other of the core geoip{1,2} libraries in main
<cjwatson> since I don't think nginx uses the python geoip bindings either way
<cjwatson> anyway, not my problem, I just wanted to mention the Launchpad change
<teward> cjwatson: the only reason it's an issue is because ahasenack wants to change nginx-core to pull in libnginx-mod-http-geoip2 instead of libnginx-mod-http-geoip
<cjwatson> Presumably ultimately for the reason I gave
<teward> ahasenack: this said, the two can work at the same time, they're designed to be coinstallable and work with slightly different commands
<teward> yep
<teward> cjwatson: yep.
<teward> regardless, because of the nature of -geoip2 being a third party module that was NOT ACK'd in the original NGINX MIR (and was not given an ACK for main because libmaxminddb is not in Main) it needs a Security Team review of that code before it can be ACK'd and included in Main (the -geoip2 module).
<teward> s/that code/the third party module's code/
<teward> (it also required libmaxminddb0 to be installed at runtime so... hence why it couldn't be in Main directly)
<teward> ahasenack: also, I would suggest that we keep -geoip in as well as -geoip2 because -geoip2 isn't AIUI reverse compatible with GeoLite or GeoIP1 which some older deployments may still be using.
<teward> (because they target different geoip datasets and there's a LOT of legacy apps I can think of in the Universe that use the legacy geoip data)
<teward> ah i just read the bug data.  ACK for dropping -geoip as a dep in core IF security team ACKs -geoip2 for Main
<teward> cpaelzer: ^ pulling you in since you pointed ahasenack my way
<teward> cpaelzer: needs security team reivew of -geoip2 for Main inclusion before it can move anywhere
<teward> (because -geoip2 is NOT from nginx upstream, it's a third party contrib.)
<cjwatson> I feel like you've said this a lot and maybe it would be better to just write it down once in a bug or MP or whatever's appropriate?
<teward> already made a note in the bug
<teward> *yawn* now where the heck is my coffee...
<vorlon> Laney: well, mozjs68 ftbfs on i386 :P
<vorlon> Laney: (and on amd64 apparently)
<Laney> WHAT
<vorlon> all I did was a no-change rebuild to pick up i386
<vorlon> so I dunno
<Laney> dunno about amd64, no log?
<Laney> i386... yeah... ok that looks plausibly real
<ahasenack> teward: I commented in the bug also. What if we demoted the geoip(1) nginx module?
<teward> ahasenack: doable.  would require a few tweaks to the build rules too I believe because it references the dynamic modules there.  give me a bit, doing some net maintenance at home atm so stuck on my phone's crap signal.  Release Notes will need a blurb then though
<ahasenack> sure
<teward> so upgraders know the functionality changed
<ahasenack> I added some reasons to my comment
<ahasenack> which we could use to justify this
<teward> *disappears to finish the net changes to bring wifi back up*
<ahasenack> good luck!
<teward> ahasenack: given the MIR backlog currently at the Sec Team's level (per sarnold) I'd say just drop geoip from core.  I'll have to tweak the build rules give me a bit to poke some things and I'll have a debdiff
<ahasenack> thanks teward. This also doesn't prevent the review of geoip2 from happening
<teward> correct.
<teward> but it removes NGINX from the equation
<teward> for now
<ahasenack> agreed
<teward> we can MIR geoip2 in nginx later
<ahasenack> if you want I can file that bug and start the analysis, like I did for bind9 (see the long description)
<teward> yep, feel free, but let me get this diff first and let you once-over it to see if I missed stuff
<ahasenack> right, let's see how it works
<ahasenack> and if it works
<sarnold> woo, thanks teward, ahasenack :)
<ahasenack> teamwork++
<teward> ahasenack: https://paste.ubuntu.com/p/4q3Bv9Sy53/ <-- the debdiff I've got that would make these changes.
<teward> there's an extra change in there for consistency sake on indentation from the 'dynamic module' section defining what is/isn't a dynamic module but the core_configure_flags in debian/rules is the core change that needed to be made
<teward> otherwise it'd explode at compile :P
 * ahasenack doesn't like explosions outside of cinema
<ahasenack> teward: I'll give that a whirl in a ppa together with the rest, and MP afterwards
<ahasenack> unless you are doing that right now
<teward> nah i need foods.  feel free to do the PPA testing, if it works i can upload this direct :P
<ahasenack> ok
<ahasenack> thanks a lot
<teward> wow LAG.  my debdiff post JUST went throug bleh
<teward> *shoots computer*
<teward> ahasenack: i just uploaded the debdiff as well
<teward> to the bug in case paste.u.c drops
<ahasenack> teward: my only change is a whitespace at the and of the changelog message, and adding the bug number
<teward> cool cook
<ahasenack> +  * Drop GeoIP from nginx-core due to demotion of libgeoip (LP: #1861101):
<ubottu> Launchpad bug 1861101 in nginx (Ubuntu) "[MIR]: dependency of bind9" [Undecided,In progress] https://launchpad.net/bugs/1861101
<teward> cool cool*
<ahasenack> it's building in a ppa
<teward> awesome let me know how it goes
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/bind9-geoip
<teward> ahasenack: I'll run tests after it builds and publishes
<ahasenack> it's published, I'm about to install it
<ahasenack> tw^
<ahasenack> teward: ^
<teward> ok.  i need to check some config bits tho on it too
<teward> make sure its disabled too - because default it's off :P
<teward> in a few once my Focal container starts
<ahasenack> teward: note I enabled proposed in the ppa, to mimic what will happen once it's uploaded to focal
<teward> awesome
<ahasenack> there is a new libcrypt1 dep
<ahasenack> you might have to enable proposed in your container as well
<teward> (I already do heh)
<ahasenack> yay
<ahasenack>  nginx-core : Depends: libcrypt1 (>= 1:4.1.0) but it is not installable
<ahasenack> I didn't :P
<ahasenack> I see it there, it has the so, linked to the expected libraries
<ahasenack> teward: modules-available/ is empty after installs?
<ahasenack> in /etc, I mean
<teward> yes
<teward> ahasenack: mine's enabled too but it won't install until i specify `-t focal-proposed` to apt :P
<teward> installing now
<ahasenack> safer
<teward> (I pinned it at 400 per https://wiki.ubuntu.com/Testing/EnableProposed)
<ahasenack> I always forget about -t
<teward> ahasenack: modules-enabled is where the system installed ones are
<teward> geoip isn't in there which is a good sign
<teward> but let me do some tests
<teward> nginx: [emerg] unknown directive "geoip_country" in /etc/nginx/conf.d/geoip.conf:1  <-- this is *good*
<teward> means geoip isn't available which is what our proposal does to nginx-core - removes 'geoip' from the available command set
<teward> so from my perspective LGTM with those changes in, as geoip isn't available
<teward> that said, we'll start getting [emerg] level log warnings for people still using legacy GeoIP in nginx-core and upgrading
<teward> but that's something we'll have to justify
<ahasenack> is this something that prevents nginx from starting after an upgrade?
<ahasenack> I guess no, because we are not removing the geoip package
<ahasenack> it will just be upgraded as usual, but from universe
<ahasenack> this was a fresh install case?
<teward> yes
<teward> but the upgrade case will cause errors as well
<ahasenack> how so?
<ahasenack> if someone doesn't have universe enabled, you mean?
<teward> well if the upgrade process does an autoremove it'll remove the geoip module
<teward> and its modules-enabled reference
<teward> and restart nginx and get an 'unknown directive' error
<teward> this'll require a release notes notice about it
<ahasenack> will it fail to restart?
<teward> yes
<ahasenack> I think it prompts for autoremove
<ahasenack> but still, if there are many packages in that list, it might be missed
<teward> yep
<teward> if it autoremoves libnginx-mod-http-geoip it'll error with the error I indicated
<ahasenack> replacing geoip with geoip2 would have caused the same thing, no?
<teward> correct
<teward> because it's a separate set of config arguments
<teward> this is ExpectedIssues with any major change like this
<ahasenack> I mean, even the original plan would have caused this
<teward> correct
<ahasenack> ok, document and proceed. I'll add a release notes task to the bug
<ahasenack> if I remember what the release notes project is
<teward> heh
<teward> ahasenack: i'll tweak my debdiff, do you want me to upload direct to proposed then?
<ahasenack> teward: that /etc/nginx/conf.d/geoip.conf you had, was that you who created it, or the package?
<teward> i created it
<ahasenack> ok
<teward> no package makes anything in conf.d
<ahasenack> so even purging would leave it there, and the error
<teward> but it beats the heck out of editing nginx.conf directly (it has an `include /etc/nginx/conf.d/*.conf`)
<teward> correct, which is another example of how this upgrade can break things
<ahasenack> yeah, isn't that one of the reasons to have .d? To have packages place stuff there?
<teward> ahasenack: indeed, but nginx doesn't enable geoip by default
<teward> upstream indicates as much
<ahasenack> but if you install it, it loads it by default
<teward> http://nginx.org/en/docs/http/ngx_http_geoip_module.html
<ahasenack> just not uses it?
<teward> correct
<teward> but loads vs. uses is the point here
<ahasenack> ok, several layers
<teward> the module is default off unless you configure things
<teward> once you add the configuration (a-la that link's example at the top of its docs) it tries to use the module
<teward> by 'default off' i mean enabled anda vailable but not used.
<teward> s/enabled/loaded/
<teward> just like a2enmod {INSERTMODULE} that doesn't necessarily *activate* any configurations for some modules just makes it available for conf to use.
<teward> (in some edge cases)
<ahasenack> ok
<ahasenack> I added a comment about release notes
<ahasenack> wrt uploading now, I don't know, cpaelzer isn't aware of our new plan
<ahasenack> maybe wait until tomorrow?
<teward> ack
<teward> i'll prep the changes on my side though
<teward> just in case ;)
<ahasenack> ok, thanks
<ahasenack> I can't create an MP, launchpad is timing out when I git push
<ahasenack> known issue, I raised a support ticket
<teward> right.
<teward> i don't push to the Git with nginx, though, I usually upload direct.
<teward> (old school package - I haven't gotten a git workflow for it worked yet)
<teward> s/package/packaging/
<ahasenack> it's fine
<teward> unlike my GBP workflow in Debian for vmfs6-tools and xca :P
<ahasenack> teward: what tz are you in?
<ahasenack> it's 16h46 for me now
<ahasenack> (19h46 UTC)
<teward> Eastern US (15:46 local, 19:46 UTC)
<teward> +- 1m30s for typing resulting in timeoffset
<ahasenack> oh, look, same utc
<ahasenack> :D
<ahasenack> close enough
<teward> yep xD
<kanashiro> LocutusOfBorg, I mistakenly sync'ed a new version of src:puma on top of your delta and now I am trying to introduce the changes again to fix a regression. However, some questions arose during the review process, could you check this bug and try to give us some insight? https://bugs.launchpad.net/ubuntu/+source/puma/+bug/1866881
<ubottu> Launchpad bug 1866881 in puma (Ubuntu) "Autopkgtest regression triggered by Ruby 2.7" [Undecided,New]
<ahasenack> teward: thanks for your assistance on this today
<teward> ahasenack: you're welcome.  do me a solid though and prep the MIR for -geoip2 module as well?
<teward> we'll throw that stuff onto Security's backlog ;)
<teward> if not in time for release here, for G-series
<ahasenack> already created the card: https://trello.com/c/ySFJNH0x
<teward> nice
<ahasenack> you can subscribe to it, it will have the mir bug shortly
<teward> yep watching the card now :)
<teward> and i'm subbed to all nginx bugs so when that MIR is filed I'll get a ping :)
<teward> sorry I made things complex but :)
<teward> best we're all in the loop :)
<ahasenack> you did not make it comple
<ahasenack> complex
<ahasenack> I missed the libmaxminddb requirement in my bind9 9.16 update, I thought I could still use the old geoip1
<bdmurray> vorlon: I ran across this MP the other day - do you have an opinion on the new sizes? https://code.launchpad.net/~xnox/ubuntu-release-upgrader/eoan-kernel-sizes/+merge/374125
<LocutusOfBorg> kanashiro, will have a look
<vorlon> bdmurray: seems reasonable to me, particularly as these are fallbacks
<LocutusOfBorg> kanashiro, I did sponsor the patch thanks
<kanashiro> LocutusOfBorg, thank you
<LocutusOfBorg> kanashiro, I added also the previous changelog entries
<LocutusOfBorg> so we don't loose the history
<mwhudson> vorlon: bah ubuntu-dev-tools in focal is not compatible with python2 any more
<vorlon> heh
<vorlon> sil2100: pleeease
<mwhudson> i'll poke a bit to see how non-trivially
<mwhudson> bluuurgh python2 sucks
#ubuntu-devel 2020-03-12
<Esokrates> Did anybody here use apport-retrace recently in sandbox mode and it worked?
<Esokrates> bdmurray: could you have a look at https://bugs.launchpad.net/apport/+bug/1866996 ?
<ubottu> Launchpad bug 1866996 in Apport "Apport-retrace sandbox has multiple issues" [Undecided,New]
<tjaalton> juliank: hi, is the focal kernel i915 stable now for you?
<juliank> tjaalton: yes both 17 and 18 are stable
<juliank> I crashed it yesterday but that was me running out of memory :)
<tjaalton> cool, I'll close the bug then
<seb128> hum, is libc6/i386 known to have issues in focal(-proposed)
<seb128> some autopkgtest started failing with symbols errors, e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/p/pulseaudio/20200312_060342_3f30a@/log.gz
<seb128>  /usr/lib/gcc-cross/i686-linux-gnu/9/../../../../i686-linux-gnu/bin/ld: /lib/i386-linux-gnu/librt.so.1: undefined reference to `__clock_nanosleep@GLIBC_PRIVATE'
<seb128> etc
<seb128> doko, xnox, juliank, ^ do you know?
<seb128> hum, also just did an upload and got an armhf failure from the builds
<juliank> there was omething about gcc is using private symbols and needs rebuilds
<seb128> E: This installation run will require temporarily removing the essential package libc6:armhf due to a Conflicts/Pre-Depends loop.
<juliank> this should be fixed soon
<juliank> (the E: error)
<seb128> k
<juliank> The gcc one I think was uploaded too
<seb128> the archive is not having a great week with the libc changes!
<juliank> yup
<seb128> also shouldn't disruptive changes like that go through a ffe before landing?
<seb128> the idea is that we should be focussing on bugfixing after ff...
<juliank> heh
<juliank> that would make sense
<juliank> but then it would not change anything, anyway
<doko> juliank, seb128: glibc mismatch for native and cross compilers, please retrigger with the glibc in -proposed
<seb128> doko, thanks
<seb128> doko, bdmurray, apport migrated without glibc so now the autopkgtest are failing unless retried with a trigger :-/
<ahasenack> teward: hi, good morning. MIR team is ok with the nginx plan. Do we need a FFe for it do you think?
<ahasenack> given it will warrant a release notes entry, I'm inclined to think it does
<teward> yes it needs an FFe
<ahasenack> I don't think I can overload the same bug with it
<ahasenack> let me file a new one and do the paper work, you good with that?
<teward> yep, if Release Team acks it I'll upload it :)
<ahasenack> ok
<AsciiWolf> kenvandine, would it be possible to set a high priority on https://bugs.launchpad.net/snap-store/+bug/1866998 ? this is a quite serious issue that will lead to many users unintentionally uninstalling the Snap Store
<ubottu> Launchpad bug 1866998 in snap-store "Snap Store snap can be uninstalled using Snap Store" [Undecided,New]
<AsciiWolf> thanks
<rafaeldtinoco> cpaelzer: quick question.. i had issues with kmod in ppa and not locally
<rafaeldtinoco> MY_DEB_BUILD_PROFILES="nocheck nodoc noudeb"
<rafaeldtinoco> having "noudeb" in the DEB_BUILD_PROFILES makes the build ok.. but ppa probably does not use that build profile
<rafaeldtinoco> you know what is special about kmod and the libkmod-udeb pkg ?
<ogra> sil2100, gentle poke about https://github.com/snapcore/pi-gadget/pull/33 ...
<kenvandine> AsciiWolf: thanks, i'll look into that
<cpaelzer> rafaeldtinoco: no I don't know its special bells and whistles :-/
<rafaeldtinoco> yep, I wonder if its something the builders have and ppas dont
<rafaeldtinoco> xnox: would u know ? kmod pkg ^
<xnox> one second, brb.
<xnox> rafaeldtinoco:  what is your failure?
<rafaeldtinoco> xnox: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1864992/+build/18828616
<rafaeldtinoco> it complains about udeb and a debian helper param
<rafaeldtinoco> dh_makeshlibs: The udeb libkmod2-udeb does not contain any shared libraries but --add-udeb=libkmod2-udeb was passed!?
<rafaeldtinoco> i have this locally as well if not using "noudeb"
<sil2100> ogra: eeek, ok, I'll try to look in a bit
<xnox> rafaeldtinoco:  if you read the log, it does create two builds build-udeb & build-deb thus it must build a full-fat libkmod2-udeb and it must contain a shared library
<xnox> rafaeldtinoco:  possibly some regression somewhere, i.e. changed paths or debhelper, thus something is not building/installing libkmod shared libraries from the build-udeb/* into debian/libkmod2-udeb/*
<rafaeldtinoco> yep that is what I was afraid
<xnox> rafaeldtinoco:  and we still need the udeb
<rafaeldtinoco> ok.. ill verify it
<rafaeldtinoco> thanks!
<rafaeldtinoco> i wanted to discard something builders wise
<xnox> rafaeldtinoco:  does 27 rebuild fine? it has this https://salsa.debian.org/md/kmod/-/commit/e5ab645e12ba8a23275d4a0e352febc7bea101ca
<rafaeldtinoco> havent tried, will do
<AsciiWolf> kenvandine, thanks! btw. there's another smaller issue that would be also good to fix and should be easy to fix: https://bugs.launchpad.net/snap-store/+bug/1866997 - should be fixed by setting a packagekit_autoremove meson build option to true :)
<ubottu> Launchpad bug 1866997 in snap-store "Snap Store does not uninstall unused dependencies when uninstalling a deb application" [Undecided,New]
<ahasenack> teward: hi, can you add your debdiff to https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150 ? Or branch
<ubottu> Launchpad bug 1867150 in nginx (Ubuntu) "FFe: nginx: demote bin:libnginx-mod-http-geoip" [Undecided,New]
<ahasenack> teward: I'll link to the pastebin from yesterday, but I think you updated it already
<ahasenack> ah, it's in the other bug?
 * ahasenack checks
<ahasenack> yep
<bdmurray> seb128: Is there anything I can do to fix it?
<seb128> bdmurray, I've no idea, maybe the code could check what glibc version is in use and test one string or the other according?
<seb128> bdmurray, or maybe now it's done and we just need glibc to migrate to fix it...
<teward> ahasenack: yeah i already uploaded the debdiff to that first bug ;)
<ahasenack> teward: ok, I attached it to the ffe one as well
<cpaelzer> doko: (and FYI ahasenack) the postgresql-12 build issue is indeed llvm
<cpaelzer> a segfault
<cpaelzer> doko: the install log has a few details https://paste.ubuntu.com/p/3hKrfH3sJJ/
<cpaelzer> eventually it crashes with
<cpaelzer> #0 0x000003ff7faab14a (/usr/lib/s390x-linux-gnu/libLLVM-10.so.1+0x9ab14a)
<cpaelzer> Segmentation fault
<cpaelzer> it is reproducible by re-issugin that looong command to /usr/lib/llvm-10/bin/llvm-lto
<cpaelzer> doko: I'll install dbgsyms and try to get you a backtrace
<cpaelzer> doko: can you look if that is any kind of known issue from there?
<xnox> cpaelzer:  is there a bug report? we can escalate it to IBM llvm maintainers
<xnox> cpaelzer:  is it reproducible if one builds with '-march=z13' set in all the build flags?
<xnox> cpaelzer:  i wonder if you should build with llvm-9 for now, to get postgresql migrating, whilst this is investigated
<cpaelzer> xnox: PGsql is fine, this is triggered by the llvm-10 rebuild that dodko did
<xnox> ah, ok
<cpaelzer> I'm filing a bug with details right now
<cpaelzer> doko can then decide if he wants to pass that to IBM or anything else
<doko> xnox: that's already done
<doko> cpaelzer: yes, a stacktrace would be nice
<cpaelzer> hmm the stack tarce isn't super useful
<cpaelzer> do we have a gdb issue in focal or is llvm hard to debug?
<cpaelzer> Python Exception <class 'gdb.error'> PC not saved:
<cpaelzer> http://paste.ubuntu.com/p/8ffXqvmGWN/
<cpaelzer> doko: ^^ this isn't enough to help you I guess right?
 * cpaelzer installs more dbgsyms
<cpaelzer> ah better now
<cpaelzer> doko: xnox: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1867173 has all the data including the backtrace
<ubottu> Launchpad bug 1867173 in postgresql-12 (Ubuntu) "FTBFS with llvm-10" [Undecided,New]
<cpaelzer> doko: anything I should check immediately ?
<doko> cpaelzer: forwarded
<cpaelzer> doko: I attached a core file I saved with gdb
<cpaelzer> let me know if you ever need more on it
<mwhudson> xnox: have you looked at the casper bug yet?
<ahasenack> teward: hi, debian doesn't have this geoip2 module?
<teward> nope
<teward> debian doesn't have nginx-core either
<ahasenack> k
<ahasenack> I mean, the geoip2 .so isn't shipped in any other package, right?
<teward> the nginx geoip2 .so?  nope.
<ahasenack> ok
<ahasenack> teward: mir on geoip2 filed
<Laney> https://launchpadlibrarian.net/468839824/buildlog_ubuntu-focal-s390x.gobject-introspection_1.64.0-1_BUILDING.txt.gz
<Laney> what does that mean
<Laney> :/ :/ :/ :\ :\ :\
<sarnold> "The use of â#include_nextâ can lead to great confusion" https://gcc.gnu.org/onlinedocs/gcc-7.5.0/cpp/Wrapper-Headers.html
<Laney> dunno right now how limits.h from glibc is meant to find the one from the compiler
<Laney> any hints welcome, will have to come back to this tomorrow
#ubuntu-devel 2020-03-13
<xnox> mwhudson:  which one of the casper bugs?
<mwhudson> xnox: i meant https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1867065 but i've tried to reproduce now
<ubottu> Launchpad bug 1867065 in casper (Ubuntu) "Installer hangs at boot on machine" [Critical,Confirmed]
<mwhudson> xnox: i do think that checking md5sums by default maybe be a bad experience over usb2...
<xnox> mwhudson:  it actually is this https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1867130
<ubottu> Launchpad bug 1867130 in plymouth (Ubuntu) "spinner theme doesn't support fckd progress messages" [High,Confirmed]
<xnox> mwhudson:  it was beautiful with ubuntu-logo theme, but it is not with spinner, because regressions.
<mwhudson> xnox: ah
<xnox> mwhudson:  i have action to look at all other regressions too
<mwhudson> xnox: cool!
<xnox> mwhudson:  the top 4 bugs on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bugs?orderby=-id&start=0
<alkisg> Hi, running pam-auth-update regenerates /var/cache/debconf/templates.{dat,dat-old} with NO changes and this wastes 34 MB RAM in live boots like LTSP or casper
<alkisg> This was reported in LP bug #43706, but it was never resolved properly, only worked-around
<alkisg> Should I report a bug in debconf and/or pam, or is it by design and I should just apply a workaround in LTSP?
<ubottu> Launchpad bug 43706 in casper (Ubuntu) "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706
<rbasak> alkisg: sounds to me that you're reporting something different from what was fixed in bug 43706.
<ubottu> bug 43706 in casper (Ubuntu) "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706
<alkisg> rbasak: "we're also storing two copies of them (templates.dat and templates.dat-old). "
<alkisg> That bug has 3 subissues, I'm talking about that one
<rbasak> alkisg: the bug says that was fixed by removing dat-old?
<rbasak> alkisg: I suggest that you start by filing a new bug that covers only one issue
<rbasak> alkisg: but also, please suggest a patch!
<alkisg> rbasak: right, while cjwatson was planning to see why the template was being written in the first place, that plan got aborted and a simple workaround "rm" was implemented, to save half the space (the copy, not the original .dat which also takes tmpfs space)
<alkisg> rbasak: but is it considered a bug? If debconf is supposed to rewrite the database even when there are no changes, then... it's not a bug, it's a "feature", and I only need to do a similar workaround in ltsp
<rbasak> It sounds like a valid unfortunate interaction in your use case
<rbasak> In general, people are willing to consider changing design when these things happen
<rbasak> Depending on the implications involved
<rbasak> The only way to find out is to file a bug with an explanation and a concrete proposal to change it, and see what happens, IMHO.
<rbasak> This is just speaking from experience in working in our ecosystem. I can't speak for casper/pam-auth-update/debconf.
<alkisg> To phrase is at a small question/issue: "Running pam-auth-update regenerates /var/cache/debconf/templates.dat with no changed content. Should I report this as a bug, and where?"
<alkisg> If this will be accepted as a valid issue, then sure I could spend a few days and try to pin point it
<alkisg> But spending a few days to get "nah it's by design" isn't a good investment of time; so I was just looking for an initial yes/no answer from someone with more debconf knowledge than me
<rbasak> I think it's a perfectly valid question.
<rbasak> Without knowing the internals it sounds like a reasonable thing to be changed.
<alkisg> Thank you, I'll start by reporting it to launchpad/debconf
<rbasak> I wouldn't know if it's pam-auth-update or debconf without reminding myself of the debconf shell API again.
<alkisg> From what I see, pam-auth-update just opens/closes debconf, it doesn't have much control over it
<alkisg> So just by a tiny first look, I think it's debconf, not pam
<rbasak> Then I agree that debconf would be a good place to start. It can always be changed.
<alkisg> Reported LP bug #1867315
<ubottu> Launchpad bug 1867315 in debconf (Ubuntu) "templates.dat is regenerated even without changes" [Undecided,New] https://launchpad.net/bugs/1867315
<rbasak> Thanks!
<alkisg> Thank you too, as always :)
<rbasak> alkisg: looks like https://git.launchpad.net/ubuntu/+source/debconf/tree/Debconf/DbDriver/File.pm might be the right place to fix this maybe?
<alkisg> rbasak: yes, editing that file bypasses the issue
<alkisg> I think somehow the dirty flag is set while it shouldn't
<rbasak> That looks like a valid bug then
<alkisg> I'm not even sure if templates.dat should be "Readonly" by debconf or not... are postinst programs supposed to write there, or is it extracted by some external script...
<alkisg> If I set it to Readonly, again problem solved, but I've no idea if it's a valid approach
<alkisg> In /etc/debconf.conf
<rbasak> New templates would get added as new packages are installed, I guess?
<rbasak> So speaking system-wide, having it read-only would be wrong I think.
<alkisg> Yes, but does debconf handle that as part of opening/closing it, or an external tool (like update-initramfs) is supposed to regenerate everything? Dunno
 * rbasak isn't sure
<alkisg> It feels weird if any program that calls debconf open templates in write mode
<rbasak> Now you appear to have two bugs :-)
<xnox> cjwatson:  we have some broken XB-Cnf-* metadata on a few binary packages across a few releases, and the packages in question are expensive to SRU (python2.7 python-defaults python3.6 python3-defaults python3.7 python3.8) and some of them have no outstanding plans to SRU. Are there any archive publishing side that I could fix? I.e. something like priority-override, but arbitrary header override? Or for
<xnox> example could I do some custom cases in the command-not-found-extractor?
<xnox> mvo is not in the channel. Can't remember who else touched cnf-extractor, maybe Laney?
<Laney> well I do have access to the thing
<Laney> but it's probably more of an mvo question
<cjwatson> xnox: If they're wrong in the release pocket, then we pretty much just have to deal with that anyway, since we aren't going to republish release pockets for reasons short of legal threats
<cjwatson> xnox: The extractor supplies Commands-* files on the side, but I don't believe it does other fields (ICBW).  There's no arbitrary field override mechanism
<xnox> Thank you! this is very useful.
<xnox> Yeah, i need to drop headers & add headers, i guess SRU it is.
<ahasenack> cpaelzer: rbasak rafaeldtinoco: ok to sync postfix.3.4.10-1? diff: https://paste.ubuntu.com/p/43Cw8dNth9/
<ahasenack> upstream release notes: http://www.postfix.org/announcements/postfix-3.4.10.html
<rafaeldtinoco> ahasenack: /me checks
<cpaelzer> damn you beat me by a minute rafaeldtinoco :-)
<rafaeldtinoco> hihi
<cpaelzer> ok 2
<rafaeldtinoco> ahasenack: +1
<ahasenack> thx
<ahasenack> well, you both can look
<ahasenack> I don't mind
<ahasenack> any concerns cpaelzer ?
<ahasenack> other than the current breakage in focal I assume?
<ahasenack> debian ci hasn't run it yet
<cpaelzer> ahasenack: I haven't looked at it since rafaeldtinoco did
<cpaelzer> if you want me to I can ...
<ahasenack> thanks, synced
<coreycb> jamespage: I'd like to bump pyroute2 from 0.5.7 to 0.5.9. there are a lot of updates in 0.5.9, and while it's not specifically an openstack dep it is mostly an openstack dep. hard to tell if it is just a bug-fix release.
<coreycb> anyway that is what openstack ussuri currently has for upper-constraints
<mpt> Anyone know where I could find a browsable list of all Universe packages in 16.10 LTS? <https://packages.ubuntu.com/xenial/> lists them by pocket and by Section, but not by repo
<marcoagpinto> mpt: 16.10 isn't LTS
<marcoagpinto> only 16.04
<marcoagpinto> only .04 versions are LTS
<mpt> Sorry, 16.04 LTS, youâre quite right
<mpt> I donât see a list of them at <https://launchpad.net/ubuntu/xenial> either
<coreycb> hello release team, I've uploaded a new point release for python-pyroute2. it's mostly an openstack dependency (dhcpcanon and pathspider are not openstack) and gets us up to the desired upper-constraint version that neutron etc need.
<pyusr> hmm... maybe python should define an /usr/bin/python2_or_3 so  scripts that do "#!/usr/bin/env python" like poetry, can work on systems that don't have python 2 by default (like new ubuntu versions) ?
<cjwatson> pyusr: https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040918.html
<pyusr> can anybody move along this SRU ? https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
<ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
<pyusr> nice, but I'm ont sure what happens, if today in focal I run something with "#!/usr/bin/env python" what will happen by default ?
<cjwatson> my understanding is that focal deliberately doesn't have /usr/bin/python for a while in order to shake out issues
<cjwatson> but this is only second-hand.  you can try it yourself
<pyusr> don't have it, but I'm wondering what about thousands of scripts like this that will stop working: https://python-poetry.org/docs/
<pyusr> tons of workflows will be broken
<pyusr> (stuff outside the apt echo system)
<cjwatson> OK, I'm out of here, have told you everything I can
<smoser> pyusr: python2or3
<smoser>  https://gist.github.com/smoser/8904199bb8f00a90dd04
<pyusr> that script exists in ubuntu 20.4?
<smoser> no. but it could.
<smoser> but as you can see... referenced is 14.04
<smoser> the right answer, imho, in 2020 is to not have /usr/bin/python
<pyusr> and what about the thounsands of workflows outside of the apt ecosystem which will stop working?
<smoser> and it seems honestly wrong to me, and just silly to have /usr/bin/python be python3
<pyusr> I tried following this today, and ofcourse it borked... https://python-poetry.org/docs/
<pyusr> everyscript that has #!/usr/bin/env python will stop working
<smoser> well, imo those things asked to be interpreted by python2
<pyusr> poetry as you can see in that page supports both 2 and 3
<smoser> and trying to execute them through python3 is not right.
<pyusr> you are wrong
<pyusr> tons of stuff support both
<pyusr> and #!/usr/bin/env isn't expressive enough for that
<pyusr> again, check that, one of the biggest packages
<smoser> pyusr the biggest argument i have for breaking 'python' is to avoid the same problem in 6 years with python4
<smoser> the python community learned nothing from the same thing that happend to perl between perl4 and perl5
<pyusr> yeah, so didn't ubuntu, it's already 2 month that ubuntu 16.04 (which is still LTS supported) doesn't work with virtualenv and python2 ... and nobody is in a hurry to fix it
<smoser> but, anyway... somethign like python2or3 i think would be a nice way to say "this works in python2 or 3"
<pyusr> tons of people CI broke over night
<rbasak> pyusr: you'll be able to install the python-pointing-to-python2 package
<rbasak> pyusr: oh, sorry, it'll be called python-is-python2-but-deprecated
<rbasak> If you install that, your legacy scripts will work
<pyusr> rbasak: will it inform me that when I try to run a script with #!/usr/bin/env python ?
<rbasak> No.
<rbasak> See https://www.python.org/dev/peps/pep-0394/ for more background on this
<pyusr> so again, tons of workflow will be broken
<rbasak> There's distro-wide consensus that python should eventually point to python3
<rbasak> This is not an Ubuntu-only choice.
<pyusr> yeah, but lots of noobs use ubuntu
<pyusr> they will be confused
<rbasak> People learning Python also get confused when "python" doesn't work or gives them some old version.
<rbasak> Unfortunately there's no solution that will work for everyone.
<pyusr> windows 10 opens the windows store with python installation when you type python in command promopet
<pyusr> rbasak: I think ther eis, the OS should provide /usr/bin/python2or3
<pyusr> and scripts should rely on it if they support both
<rbasak> pyusr: great - I suggest you follow the upstream process of getting PEP 394 amended with that suggestion.
<pyusr> PEP does not enforce OS but Python itself
<pyusr> ok, better solution, "/usr/bin/env" in ubuntu should check if /usr/bin/python does not exist (and someone wants /usr/bin/env python) it should bring up a warning about what to do ?
<pyusr> how does one go about offering that ?
<tumbleweed> It's hard to imagine /usr/bin/env changing, to help Python users
<pyusr> tumbleweed: there are gonna be tons of noobs that will start crying with 20.4 LTS
<pyusr> why not improve their experience ?
<tumbleweed> it's not /usr/bin/env's job to do that
<pyusr> you understand that https://github.com/python-poetry/poetry/issues/2183 <-- this is a tip of the iceberg ?
<pyusr> and thats a very popular package, think about all the abandond scripts people use daily that will stop working, and they will get a criptic message they will need to google ?
<tumbleweed> yeah, the end of python 2 is a lot of pain for everyone
<tumbleweed> I'm saying that this specific solution sounds like a non-starter
<rbasak> The problem is that unless you put in a python2or3 command into every existing distro and release that people use, it's of little use.
<pyusr> rbasak: I'm offering a different solution now
<rbasak> I don't think it's appropriate to patch or redirect /usr/bin/env.
<pyusr> the main issue is #!/usr/bin/env python gives a criptic error /usr/bin/env: 'python': No such file or directory
<pyusr> it does not say "Python 2 is not installed on the system":
<rbasak> And in any case it won't help scripts that don't /usr/bin/env.
<rbasak> pyusr: in any case, I don't think somebody with no credentials and no prior track record is going to be able to appear on this channel and convince us to do anything this major.
<pyusr> most scripts do, and those who don't maybe the error will be better "/usr/bin/python" no such file or directory
<rbasak> That's why I said you should focus on getting consensus upstream.
<pyusr> I don't even know how I can find someone to fix ubuntu 16.04 virtualenv to work...
<rbasak> Or at least a mailing list
<rbasak> pyusr: have you proposed a patch?
 * rbasak needs to go
<rbasak> I appreciate that you care
<rbasak> But the way to get things done in this ecosystem is to present working solutions and build consensus to use them
<pyusr> there is an SRU patch waiting for a month
<rbasak> IRC doesn't really work for that.
<rbasak> pyusr: link please?
<pyusr> https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
<ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
<tumbleweed> pyusr: and I field that SRU, and rbasak has commented on it
<rbasak> Ah
<pyusr> tumbleweed: ahh, cool
<rbasak> I reviewed that the other day, yes
<rbasak> (well, I didn't, since I don't think I'm sufficiently qualified)
<tumbleweed> :P
<tumbleweed> yeah, was hoping to get doko's attention
<rbasak> I pinged doko about that earlier ^
<rbasak> :)
<pyusr> rbasak: that bug is ongoing for 2 month already :(  It makes me wonder how has it not surfesed enough
<pyusr> surfaced
<rbasak> pyusr: right - only one person marked affected
<rbasak> Trust me - when it affects a large number of people, the noise is noticeable :)
<pyusr> I discovered the bug, told my friend about it, he linked me to his buildbots of pypy stoped working
<pyusr> so he formated the machine to 18.04
<pyusr> rbasak: maybe people stoped using system python with CI with stuff like pyenv, asdf
 * rbasak does really need to go now
<pyusr> laters
<pyusr> tumbleweed: you don't think a better error msg on /usr/bin/env is a good idea ?
<tumbleweed> I'd talk to the coreutils upstream - this is a common use for /usr/bin/env, and the error message could be improved to help users
<tumbleweed> I don't think the best approach is to be Python-specific, though
<pyusr> maybe like ubuntu has that autofigure out which package to recommend on error
<pyusr> and link that into /usr/bin/env errors
<tumbleweed> using /usr/bin/env to find a program on PATH is a total abuse of the purpose of it... but it's probably 90% of what it's used for, these days
<pyusr> also, shouldn't nvidia-drivers for ubuntu (16.04) check that HWE is neabled ?
<pyusr> instead of borkign the system
<vorlon> objection, assumes facts not in evidence
#ubuntu-devel 2020-03-14
<alkisg> Hi, /var/lib/snapd/snaps somehow ends up getting copied-up in overlayfs in live CDs, wasting as much RAM as there are snaps installed
<alkisg> https://bugs.launchpad.net/snapd/+bug/1867415
<ubottu> Launchpad bug 1867415 in snapd "/var/lib/snapd/snaps needs 400 MB tmpfs RAM on live CDs" [Undecided,New]
<alkisg> Installed snaps shouldn't consume tmpfs RAM space, they should only use squashfs disk space; if this continues then live CDs won't be usable in the future as snaps will need GB  of tmpfs space
<alkisg> And of course that means that if LTSP users install 5 GB snaps, they'll need netbooted PCs to have 5 GB more RAM, which of course doesn't happen with .debs; I guess this will force them to uninstall snapd...
<alkisg> I suspect they're hard linked from /var/lib/snapd/seed/snaps/*.snap to /var/lib/snapd/snaps/, and this causes overlayfs copy-ups for all snaps
<brlin> Related Snapcraft forum topic: https://forum.snapcraft.io/t/var-lib-snapd-seed-snaps-needs-400-mb-tmpfs-ram-on-live-cds/15980
<brlin> alkisg: FYI, there's a #snappy channel here
<alkisg> brlin: thanks; regarding the forum topic, yeah I opened that after opening the launchpad bug
<alkisg> brlin: do you think I should put casper in affected packages, in case it cannot be fixed in snapd in time for 20.04, but it can be worked-around in casper?
<brlin> alkisg: If it's related (in any way) I suppose it's reasonable.
<alkisg> I believe it can be considered a bug in snap/squashfs/squashfs.go, function Install, but it can also be worked around by symlinking all the files in casper's initrd-bottom
<alkisg> Maybe it's best to wait a few days, and if there's no feedback from snap, then put casper too
<sabdfl> hi folks
<sabdfl> do we have a libc6 issue in focal today?
<Unit193> Bug 1867423 (and other duplicates)
<ubottu> bug 1867431 in glibc (Ubuntu) "duplicate for #1867423 ERROR got an error from dpkg for pkg: 'libc6'" [Critical,Incomplete] https://launchpad.net/bugs/1867431
<nicolas17> https://packages.ubuntu.com/source/xenial-updates/git is there a git repo for the ubuntu packaging of git?
<valorie> ha
<valorie> it would be funny if it was in bzr
<nicolas17> I found the git repo Debian uses, but that doesn't have Ubuntu-specific changes (such as security backports) or the changes done for the PPA https://launchpad.net/~git-core/+archive/ubuntu/ppa
<valorie> nicolas17: you could ask in #ubuntu-devel maybe
 * Unit193 looks at the channel.
<valorie> err, we're here
<valorie> sheesh
<valorie> I saw that in the ohnosecond
<Logan> /join #ubuntu+1
<Unit193> /join #ubuntu+2
#ubuntu-devel 2020-03-15
<Logan> :(
<Logan> joining channels on Matrix is hard
<Unit193> Yeah matrix...isn't really a good client.  Also, somehow I ended up with the libcrypt.so.1 -> libcrypt.so.1.1.0 symlink, seems nothing is broken for me.
<Logan> lucky you
<Unit193> No idea how I managed that..
<nicolas17> this git package has been building for more than an hour... might be the slowest tests I have seen
<tarzeau> no xpdf for focal???
<tarzeau> what's my chances after the freeze to get meshlab fixed for 20.04?
<mitya57> "unmaintained, not compatible with the new poppler", also debian #848631
<ubottu> Debian bug 848631 in wnpp "O: xpdf -- Portable Document Format (PDF) reader" [Normal,Open] http://bugs.debian.org/848631
<tarzeau> mitya57: thanks for the summary!
