#ubuntu-devel 2005-03-07
<jbailey> Mithrandir, ogra: Are you guys setting policy on what to do if a package in Universe is unrelated to the package in Debian?  We may have some Jav aones that fall into that category, since our Java policy is slightly different.
<Mithrandir> jbailey: yes, basically.  And also whether we want that at all to happen
<ogra> jbailey: i think in case of java its slightly different (based on the policy difference), but similar....
<jbailey> It's not hard to imagine a case where an MOTU isn't involved with Debian at all and uploads a package to universe and someone independantly packages it for Debian later, though.
<Mithrandir> true enough
<YokoZar> jbailey: this is actually highly likely, since it is really hard to get into Debian compared with Ubuntu
<ogra> YokoZar: but DDs could pick your ubuntu package for a base of their packages....
<ogra> s/for/as
<jbailey> ogra: But there's no requirement on that side that they do so.  They might not even be aware that the package is in Ubuntu.
<YokoZar> Not just on a user level but a developer level as well.  There's a very long process for getting a package into Debian, and it's impossible to do if there's an obstinate maintainer blocking your work for some unexplained reason.
<ogra> jbailey: yup
<jbailey> Yeah.  More than one name pops into mind of someone who's packages I would love to redo sanely. =)
* lamont notices that not only is it not snowing nor raining out side, it's clear up > 10 deg C.  back in about 20 minutes
<YokoZar> Going through the Debian Intent to package, social contract, security signing, peer review, community application and such (provided there's no maintainer controlling your package already) is much harder than making a simple working package and forwarding it to Ogra :)
<YokoZar> lamont: it was raining in Mojave yesterday.
<lamont> which means it'll possibly rain here tomorrow. ok
<ogra> YokoZar: true :)
<jbailey> YokoZar: The current process does put alot more onus on the sponsors, but I'm already really strict for people whsoe packages I sponsor.  Not a big deal. =)
<YokoZar> It does illustrate that the system heavily depends on the Debian maintainers still.  And when they're not updating packages, or there are significant usability problems with the ones they have (Wine), people like me are put in a bit of a bind.
<daniels> lamont: you want to claim 6841? :)
<ogra> YokoZar: no, your ptroblem isnt that you provide newer or up to date packages, but you step away from a given scheme where users, devs and apps may rely on....
<YokoZar> ogra: True.  But it is backwards compatible
<ogra> YokoZar: does it provide libwine-jack, -alsa, -capi, -print, -nas, -arts etc. ?
<YokoZar> Yeah.  Wine automagically detects all that stuff now, and seperating it out just created confusion.  This was the consensus among the wine devs too - we were having way too many problems with Debian users with incomplete packages asking for support
<YokoZar> It only saved like 20k of space by not having some of those drivers included (sometimes it wasn't even a savings of space, due to the changelog files)
<ogra> YokoZar: so what about a package we eagerly want in ubuntu that was written for debian and that heavily depends on libwine-capi ?
<ogra> (a hypothetic one)
<YokoZar> There are no packages like that though.  libwine-capi is included in wine now anyway.  There are also no current packages which depend on libwine, and due to all the changes we're going through with Wine (like removing the configuration file) there's a need to upgrade wine anyway
<YokoZar> All the libwine-capi file is is Ove seperating out the 20k or so Capi driver into a seperate package, so that Wine will fail mysteriously when a program calls for it and a user doesn't have it.
<mdz> Kamion: still here?
<bob2> so, netapplet is actually an applet now
<bob2> how novel!
<dholbach> i'm off to bed - bye
* lamont runs into town for a little bit
<lupusBE> my system hangs in gnome when using the new 10-4 kernel
<lupusBE> 10-3 works fine
<lupusBE> any reports about this?
<hawke> lupusBE: yes
<lupusBE> is it been taking care off?
<hawke> lupusBE: yes; temp. workaround: add "noinotify" to the kernel commandline
<YokoZar> http://www.osnews.com/story.php?news_id=9793
<lupusBE> I just booted the 10-3 kernel so :)
<hawke> lupusBE: that works too
<zenrox_> lupusBE,  the 10-4 kernel frezzes my sys after a random amount of time
<lupusBE> :)
<zenrox> its weird
<hawke> zenrox: have you tried adding 'noinotify' to your kernel commandline?
<hawke> assuming you're all about using 10-4
<zenrox> hawke,  naw ill wate till it gets fixed
<zul> hey
<zul> ummmm...what is minipatch.diff doing in the main kernel directory when i do apt-get source?
<pvh> I just installed my new DVD drive, and it didn't create an entry in fstab. Is that a bug?
<HrdwrBoB> no
<pvh> (Is that nor, or enh?)
<HrdwrBoB> ubuntu does not use fstab for removeable devices
<HrdwrBoB> stick a CD in it
<HrdwrBoB> and it should use pmount to automount it
<pvh> Hmm. Well, totem carps at me about not being able to mount /dev/hdc when I "Play Disc"
<pvh> "Failed to find mountpoint for device /dev/hdc in /etc/fstab"
<HrdwrBoB> that's a totem bug I think
<pvh> Oh, yeah, my computer freezes hard whenever a USB device gets unmounted. That's the other one -- is that a known hoary problem?
<pvh> (Regardless of whether I 'umount' or just unplug it.)
<HrdwrBoB> pvh: what hardware
<HrdwrBoB> ?
<pvh> So far, three kinds of USB storage devices on both my laptop and desktop.
<HrdwrBoB> pvh: also good to search on bugzilla.ubuntulinux.org
<pvh> HrdwrBoB: I appreciate that, but I've never found any bug I've tried to report there. Either I stress things in strange ways, or I don't have the right vocabulary for searching.
<zul> lamont: ping me when you get back
<geppy> gstreamer0.8-jack is broken.
<geppy> Is there anything I can do to help?
<zul> yes you can open a bug report
<geppy> There have been bug reports opened, but they were closed "so that gstreamer-plugins wouldn't be held up."
<zul> geppy: you can check on #ubuntu-motu
<geppy> What does the motu refer to?
<ajmitch> masters of the universe
<geppy> hahahahaha
<geppy> Thanks. =)
<ajmitch> aka the people who look after universe packages :)
<geppy> hahaha =)
<wasabi> I'm having some interesting pbuilder trouble I can't figure out.
<wasabi> trying to build a package in it, and it's coming back saying a few dependencies are not authenticated
<wasabi> apt-secure stuff... these deps are all in main. I'm not sure why they aren't authenticated
<ajmitch> wasabi: perhaps gpg isn't in the pbuilder chroot
<wasabi> oh, perhaps.
<wasabi> seems like it should be!
<ajmitch> I think that was fixed, but I'm not sure
<wasabi> hahah
<wasabi> gnupg can't be installed in the chroot
<wasabi> because gnupg can't be authenticated. =)
<ajmitch> I had that problem as well :)
* wasabi trise to recreate it
<wasabi> gnupg should be part of hte base system
<wasabi> okay that doesn't even work
* lamont returns, grumpy
* lamont also learned today that he gets to attend 7th grade tomorrow. :-( grumble
<wasabi> okay so what does one do in apt.conf to disable authentication
<lamont> jdub awake yet?
<schweeb> hehe, xdesktopwaves with compmgr + opacity is pretty sweet
<zul> hey
<zul> lamont: ping
<lamont> evening zul
<calc> fabbione: any chance linux-image could get an updated ipw2200 (1.0.1) driver soon?
<calc> the current one doesn't seem to work with 2915
<zul> fabbione isnt here
<calc> he may see the message when he comes back :)
<calc> the one currently in the image is 0.19 from dec :\
<zul> i can look into it but i cant guarantee anything though
<calc> ok
<calc> ah i didn't realize you worked on the ubuntu kernel as well :)
<zul> im one of them
<tseng> calc: he's just the fall guy
<calc> heh
<zul> tseng: today i am 
<tseng> zul: so, inotify. fix
<tseng> :D
<zul> tseng: shut it :)
<Amaranth> What's wrong with inotify?
<zul> it sucks
<Amaranth> Worse then dnotify? :)
<zul> check bugzilla...night night
<jdub> lamont: pong
<lamont> jdub: so this inotify crack
<lamont> for -24 we're kinda thinking of just disabling it by default, while the inotify crackheads work on it for -25... thoughts?
<lamont> we _think_ we can do that without an abi event, while changing the driver almost certainly generates one.
<lamont> that is, we're hoping to make it so you can boot with 'inotify' as a kernel parm and have inotify back in it's broken state.  Failing that, we'll just make it so that the default is 'noinotify' (although you can specify it to be sure...)
<da_bon_bon> HEL!PP! update-manager cant download any files from archive.ubuntu.com.... nor can apt-get
<da_bon_bon> Err http://archive.ubuntu.com hoary/main python-glade2 2.5.4-0ubuntu2
<da_bon_bon>   Got a single header line over 360 chars
<da_bon_bon> Err http://archive.ubuntu.com hoary/main python2.4-gtk2 2.5.4-0ubuntu2
<da_bon_bon>   Bad header line
<da_bon_bon> please help
* lamont pokes at jdub, hoping for some response...
<jdub> lamont: agree
<jdub> lamont: sorry, phone calls and so on
<da_bon_bon> http://rafb.net/paste/results/e6dA0D46.html - someone pelase help - its urgent...
<jba> da_bon_bon, word of adivice dude, no matter how urgent your support request is, asking for support in the devel channel will not elicite many helpful responses
<jba> in the mean time, could be overloaded servers, bad proxy, or so on
<da_bon_bon> jba: i thought that some developer might now whether the mirrors down or something
<jba> da_bon_bon, I'm not actually a developer, so I can't help you in that respect
<jba> just try it again sometime
<da_bon_bon> ok. can u tri it out, so that i can confirm ?
<lamont> jdub: np.
<da_bon_bon> jba: also, everytime i try to dist-upgrade, it says some packages cudnt be authenticated, do u wanna continue ?
<jba> da_bon_bon, I don't have my ubuntu system here with me
<jba> I'm on windows dude sorry
<jba> try getting someone in #ubuntu to help out
<da_bon_bon> jba: ok, but can u give some ponters ?
<jba> when i get those errors dude, I simply assume it's heavy network load and try it again another day
<jba> can't do much more else than that dude, sorry
<da_bon_bon> well, this happens 90% of the time i try updating
<da_bon_bon> jba: worked!  just did apt-get clean headers
<jba> da_bon_bon, some times it's the proxy caching the headers (if you have a poxying, nating firewall like ipcop or smoothwall)
<da_bon_bon> jba: no proxy.. but apt-get clean headers doesnt remove the downloaded packages ?
<da_bon_bon> or does it ?
<jba> no i don't think it does
<da_bon_bon> ok
* lamont falls into bed.
<lamont> jdub, mdz: if anyone's looking for me tomorrow, I'm stuck with .au-ish hours. (briefly around 1300UTC, then back on at 2300UTC-ish for the workday.)
<jdub> night :)
<jba> .au hours are the best in the world dude
<AndyFitz> jba,  not wrong mate
<AndyFitz> aside from when you have to work with people in .us
<jba> aah thats what I like to see, an oss IRC channel with aussies in it
<jba> AndyFitz, no, no. it's them that have to work with us ;)
<AndyFitz> jba,  only because we are cheaper than chips
<jba> mmm chips
<jba> haha there's some guy in #ubuntu called woodywarty
* AndyFitz thinks about a run down to the fish cafe
<jba> which suburb you in AndyFitz
<jba> ?
<AndyFitz> fortitude valley, brisbane
<jba> aah.
* jba frenchs forest sydney
<jba> "the northern beaches"
<jba> my outlaws are from brissy
<Amaranth> damn aussies making me stay up late just to talk to you :P
<AndyFitz> Amaranth,  its worth it tho isnt it ?
* aj wonders who andyfitz is
<Amaranth> AndyFitz: Not at all, you guys just talk about fish and chips.
<AndyFitz> jba,  lots of sydney guys here ive noticed 
<Amaranth> :D
<jba> i haven't, but then again I'm not in -devel too often
<AndyFitz> aj,  im AndyFitz obviously :-P
<AndyFitz> Amaranth,  I have to stay up late to talk to the scribus guys, its only fair someone has to do the reverse
<pitti> Morning
<pitti> elmo: squid sync, please (throwing away Ubuntu changes is alright)
<da_bon_bon> is kde 3.4 in the repos ? of hoary ?
<Riddell> da_bon_bon: no
<da_bon_bon> Riddell: but on the kubuntu page, someone has written some guy has updated some 3.4 packages...
<sid77> ciao
<dholbach> good morning
<pitti> hi dholbach 
<dholbach> hai pitti!
<d3vic3> lo dholbach 
<dholbach> hi d3vic3 
<ajmitch> evenign d3vic3, dholbach, pitti :)
<dholbach> hai mvo!
<dholbach> i'm looking at a hoary box of a friend; selecting gnome in gdm and logging in freezes her box completely, while kde is fine
<dholbach> what do i have to disable to make it work?
<Treenaks> dholbach: boot with noinotify
<dholbach> that'd be all?
<Treenaks> uh, afaik
<mvo> hai dholbach, morning all
<Treenaks> hey mvo
<mvo> hi Treenaks 
* mvo yawns
* dholbach caffeinates mvo a bit.
* mvo is already preparing his morning tea
<thom> aaaargh! someone filed a bug about firefox not being session aware
<thom> that one is so "UPSTREAM! RUN AWAY SCREAMING"
<pitti> Hi mvo 
<mvo> hi pitti 
<ogra> moin
<dholbach> hai ogra!
<ogra> brrrr.....
<Treenaks> hey ogra 
* ogra freezes....hhhhheating seems off
<Treenaks> ogra: on purpose?
<ogra> nope
<ogra> ad the landlord inst here.... s i doubt it will get switsched on soon....
<ogra> and....isnt
<ogra> so
<Treenaks> type a LOT..
<ogra> gah....i need more letters....
<Treenaks> oh and turn on some number-crunching CPU-time-eating stuff
<ogra> heh
<thom> nah, just buy an ia64
<thom> much easier
<dholbach> yeah, like python-transitioning vtk - compiling took me more than half an hour :-)
<thom> morning pitti
<pitti> Hi thom 
<pitti> thom: actually I'm up for 3 hours now already :-)
* pitti just tested smurfix keyboard selector
<pitti> smurfix: ping
<smurfix> pong
<smurfix> , even
<ogra> thats pong ?
<smurfix> Yep
<ogra> you see me impressed :)
<dholbach> cool
<pitti> smurfix: is there any way to display the selected keyboard layout after your guesstimator has finished?
<pitti> smurfix: so far I verified the choice only by typing some keys in a dialog box
<smurfix> Yeah, go back and go to keyboard selection again
<smurfix> The currently-chosen keyboard is on top
<pitti> ah, ok
<pitti> I actually tried that :-)
<pitti> but I wasn't sure whether this was adapted, since German was my default choice anyway
<pitti> smurfix: cool, thanks
<smurfix> It is. It doesn't work if you change your language in the meantime, but that's an old bug in kbd-chooser.
* smurfix should learn better English. s/the meantime/between.
<sivang> Morning all!
<pitti> Hi sivang 
<pitti> Kamion: mdz asked me to remove raidtools2 from heartbeat, to allow raidtools2 demotion to universe
<pitti> Kamion: however, raidtools2 is in the installer seed as well. Will you handle this?
<sivang> Hey pitti :)
<dholbach> hi dredg 
<dholbach> hi sivan
<mvo> hi sivang 
<sivang> hi dholbach 
<sivang> hi mvo 
<ajmitch_> hi sivang 
<sivang> ajmitch_: Hello 
<dholbach> elmo: ping
<pitti> sivang: do you want to start hacking on gcm today?
<sivang> pitti: yes :)
<Kamion> mako: back now
<Kamion> pitti: let me do some grepping
<aj> Kamion: mako's asleep :)
<pitti> Kamion: I looked at http://people.ubuntu.com/~cjwatson/germinate-hoary-output/all
<Kamion> aj: I figure even with a 12-hour time lag we can probably manage to have a conversation eventually
<pitti> Kamion: I uploaded a new heartbeat, so the only thing that holds raidtools2 is the installer seed
<aj> Kamion: pretty robust protocol you've got there
<Kamion> pitti: yeah, just trying to work out if and where it's actually used
<pitti> ah, ok
<Kamion> is raidtools2 older/newer than mdadm?
<Mithrandir> older
<Kamion> ok
<pitti> Kamion: I think mdadm is the way to the future
<pitti> Kamion: personally I like it much better than the raidtools
<Kamion> no references to it in d-i, I'll kill it
<pitti> yay
<pitti> Kamion: do you already use mdadm to configure raid parititons?
<pitti> partitions, even
<Kamion> pitti: yes
<Kamion> mdcfg does so
<pitti> cool
<Kamion> pitti: done
<pitti> thanks
<thom> mjg59: any ideas on how to handle 6447; i think just caching what the previous state was (in power.sh) and if it's not changed exit early should be fine...
<pitti> elmo: here?
<Kamion> oh god, the release notes are wrong in so many places :(
<Kamion> "Hoary introduces a supported AMD64 port, ..."
* thom shakes his fist at pitti
<pitti> thom: what's wrong?
<pitti> thom: the bug assignment?
<thom> mozilla guru indeed
<pitti> hehe
<pitti> thom: I just remembered the other CAN issue which you missed because I didn't reassign the bug to you
<thom> i was so tempted to reassign it back with some snide comment about how the security team were more suitable for doing the work
<pitti> thom: this does not imply that you should fix it for Warty right now :-)
<mjg59> thom: Sounds reasonable
<Mithrandir> Treenaks: have you seen http://www.navsys.org/ngpsd/ ?
<Mithrandir> lamont: I guess it doesn't make much sense to set up a buildd on the sparc box I have?
<Treenaks> Mithrandir: yeah, and it looks dead
<Mithrandir> Treenaks: drop the admin a mail and ask what's up?
<Treenaks> Mithrandir: good point
<Mithrandir> Treenaks: they're going to present at FOSDEM
<Mithrandir> lightning talk
<Treenaks> oh? cool
<Mithrandir> sunday 15:15-15:30
<Treenaks> has the keysigining-time been set?
<Mithrandir> no idea
<Treenaks> bunch of amateurs :)
<pitti> ogra: ping
<ogra> pitti: pong :)
<thom> mjg59: also, we need to find a way of getting the X user which doesn't suck
<pitti> ogra: instead of wrapping the uuencoded pngs into a debian patch, why don't you just ship them in debian/ and install them from there?
<ogra> diff doesnt like binary files
<pitti> ogra: no, I mean keep them uuencoded
<thom> ogra: still uuencoded
<pitti> ogra: but just add the files to debian/
<ogra> ah, ok
<pitti> ogra: and just uudecode -o build-tree/foo < debian/foo.png.uuencoded
<pitti> ogra: this makes the patch much smaller and nicer
<ogra> okiedokie....
<pitti> ogra: and pleeease s/os.system/os.spawnl/
* dholbach makes anote to himself
<mjg59> thom: Mm.
<pitti> ogra: this avoids an intermediate shell
<ogra> ok
<seb128> tseng: here ?
<thom> mjg59: bring back pam_console, all is forgiven? ;-)
* thom ducks
<pitti> ogra: also, you should Suggest: hwdb-client
<ogra> yup
<pitti> ogra: btw, will hwdb-client be fully functional with Hoary?
<ogra> i hope so :)
<pitti> ogra: I just tried it, does it already send data to us?
<pitti> ogra: I mean, we should not add this patch to hal if the client is not ready
<ogra> but at least it will collct and send until horay...
<ogra> which was the main goal....
<pitti> ogra: fadein and fadeout are certainly the most critical functions :-)
<pitti> Morning carlos
<ogra> hehe.... hwdb-gui was the first thing i wrote.... i was still playing at this time ....
<mjg59> thom: Something like that. It's a bit of a pain.
<carlos> morning
<ogra> pitti: but -gui shall become a generic xml viewer with some easy scripting functions in hoary+1, so it can be used by other projects to provide a constant look and feel
<pitti> ogra: oh, cool
<pitti> ogra: but sending will definitively work for hoary, so we can apply the hal patch (and commit to the functionality)
<thom> mjg59: indeed
<ogra> yup....http://www.grawert.net/hwdb_schema.png (hwdb-send will just be a 10 liner doing a http-post)
<pitti> ogra: nice pic :-)
<ogra> pitti: -qa is the big part thats still missing....but it should work without it anyway...
<ogra> pitti: so i can guarantee the collection at least, which is the most important thing to do
<pitti> ogra: will hwdb go into main?
<pitti> ogra: if so, you should recommend it instead of suggest
<pitti> ogra: or even better, it should be in ship seed
<ogra> okay...i think its planned to get it into main
<pitti> ogra: erm...
<ogra> ?
<pitti> ogra: analoguous to your gtk.TRUE -> True changes, you should do the same for FALSE
<pitti> ogra: /usr/bin/hwdb-gui:26: GtkDeprecationWarning: gtk.FALSE is deprecated, use False instead
<ogra> yup...
<ogra> i know...
<pitti> ogra: just tested the crack, looks very nice!
<ogra> pitti: thanks :)
<pitti> ogra: the last two letters of "database" can't be seen with the default column width
<pitti> ogra: does that happen for you as well?
<ogra> in the button ? or in hwdb-gui ?
<pitti> ogra: in the h-d-m button
<pitti> ogra: maybe you should just enlarge the default width of the row a bit
<ogra> hrm...looksok here, but i'll adjust that
<pitti> ogra: maybe because I have a different screen size and thus a different DPI
<pitti> dunno
* ogra wonders if DB would be sufficient for the users....
<pitti> ogra: rather drop the "contribute"
<ogra> yup, its redundant, youre right
<pitti> ogra: "Submit data ... to the Ubuntu Device Database" is clear as well IMHO
<lamont> Mithrandir: if you're a glutton for punishment, and have hoary installed on the sparc box, and want to give me root, I could set up a buildd.  Or we could wait for fabbione to get back and reboot his - he wasn't that concerned if it went down while he was gone
<lamont> although i think he expected it to stay up more than 48 hours after he left..
* ogra looks up glutton
<ogra> lol
* Mithrandir goes for the "wolverine" interpretation of glutton
<ogra> hehe
<Mithrandir> lamont: I'll bring it home tonight then, since I'm not allowed to hand out root accounts to people on the university network..
<lamont> bah - I had one at stanford :)
<Mithrandir> I'm also part of our computer club CERT, so I should probably be a good example. :)
<lamont> mind you, it was a surprise to the owner after two handsoffs..
<Mithrandir> heh :)
<lamont> stanford CERT owned the box
<Mithrandir> *chuckle*.  I'm sure they were happy about that, then.
* Mithrandir kicks libtool
<lamont> their rep left, and the recipient left the department within 6 months.  about 6 month's after _that_, I had login problems (kerberos update missed that box)... Was news to the new rep that she even _owned_ the box, let alone that I had a root account on it
<Mithrandir> yay for good security :)
<lamont> the machine was a mail forwarder outside their firewall
<Mithrandir> Keybuk: what's a good way to go about debugging the multiarched libtool?
<Keybuk> libtool --debug ...
<Keybuk> (which is really cunningly implemented, _oh_yes_)
<lamont> Mithrandir: the best way I've found is to beg/plead/trick someone who knows libtool into doing it for you. :-)  Chocolate sometimes works.
<Mithrandir> Keybuk: the test suite fails, and I want to look at exact what fails about it.
<Keybuk> which tests fail?
<Mithrandir> Keybuk: demo-make.test (multiple times), depdemo-make.test (multiple times), pdemo-make.test, mdemo2-make.test
<Keybuk> then you've quite majorly broken it :)
<Mithrandir> I haven't touched it, I've just recompiled it in a multiarch environment
<Keybuk> probably needs to support it
<Mithrandir> it already has support for a search path -- why can't just that be used?
<Keybuk> it does
<Mithrandir> where do I even start debugging this?
<Keybuk> run the tests in verbose mode, read the logs, see what fails
<Keybuk> create your own test bits of code, run libtool over them, see what it does and make sure it's right
<Keybuk> run libtool in debug mode to trace where things go wrong
<Keybuk> fix it
<Keybuk> (basically the usual way)
<Mithrandir> ok
<HcE> anybody knows of a website with good documentation for developing usb kernel modules for Linux 2.6.x?
<Gagatan> HcE :)
<Mithrandir> HcE: might be better to ask on #kernelnewbies?
<HcE> ok
<Mithrandir> just a thought
<HcE> any thoughts are good
<HcE> I'm finding out that 2.4-driver isn't much use at all for 2.6
<pitti> Hi elmo 
<pitti> elmo: derooting mdadm -F is nontrivial
<elmo> pitti: squid sync would violate UVF
<elmo> pitti: boggle - why?
<pitti> elmo: because it automatically activates hot spares if they are present
<pitti> elmo: and you need some high-privilege ioctls() for this
<elmo> ah, bugger
<pitti> elmo: also, mdadm -F tries to open() devices
<pitti> elmo: thus it needs to be at least in the disk group, which is equivalent to root
<pitti> elmo: a pity...
<pitti> elmo: squid> oh sorry, I just read the top changelog entry...
<pitti> elmo: it's not much more than a microrelease which integrates all the security bug fixes
<pitti> elmo: I go the official way and ask mdz about it
<elmo> thanks
<dholbach> elmo: i sponsored an eyed3 upload to aaron lake, but it doesnt seem to be build
<Mithrandir> Keybuk: seems like ld needs some kicking too, which should fix it.
<dholbach> elmo: i didnt get a mail, so i dont know what went wrong
<elmo> eyed3_0.6.4-0ubuntu1_source.changes
<elmo> REJECT
<elmo> Rejected: Unknown distribution `unstable'.
<ogra> heh
<dholbach> oh damn
<dholbach> :-)
<dholbach> metalikop: ^--
<elmo> dholbach: you should either use your email in the Changed-By field, or ask me to add the email of the person your sponsoring to the whitelist
<elmo> as I think we can whitelist MOTU candidates independently of their approval
<dholbach> elmo: yeah... that 'd be good
<Kamion> I'd prefer the latter approach, since then we can scan hoary-changes more easily to look for things that a MOTU candidate has done
<elmo> dholbach: but please do it via upload@ubuntu.com or whatever the address is so we have an audit trail
<dholbach> elmo: i'll tell the guys
<elmo> k
<elmo> (bah, I can't say 'k', without wanting to add 'thanks' but knowing someone'll mock me for it :P)
<Mithrandir> as long as you don't add "bye". :P
<ogra> thanksbye ?
<Mithrandir> kthxbye
<lamont-away> elmo: lol
* lamont-away heads off for a good long while
<Kamion> lamont-away: have fun
<Mithrandir> elmo: would it make you to go nuts to just have the whitelist on the wiki so people could add themselves?
<Treenaks> Mithrandir: wikispam
<elmo> Kamion: are you likely to need d-i/live buildds particularly over the next 48 hours?
<dholbach> i think signed mails to whitelist@u.c are WAY better
<elmo> Mithrandir: I'm not thrilled about the idea - I don't think having me manually add people is particularly problematic
<Mithrandir> elmo: 'k
<elmo> if it becomes so, we can de-bottleneck it in other ways that aren't quite so vulnerable to abuse
<lamont-away> Kamion: btw, still no exclusions for striptranslations - I'll get that in when I get back
<lamont-away> with apologies to base-config or whichever
<AndyFitz> jdub, ping
<Kamion> elmo: I need to do a d-i build soon, once network-kickseed is through NEW; I assume that goes through the normal mechanisms rather than the special buildds though
<elmo> hmm, yeah, I think these are only used for triggered builds
<Kamion> elmo: and we probably want a d-i build once the kernel's fixed, but I can do that by hand if need be
<Kamion> (the inotify stuff)
<tseng> seb128: yes
<seb128> tseng: muine crashing but that's fixed after moving ~/.gnome2/muine out of the way
<tseng> seb128: hm are you using esdsink
<seb128> correct
<tseng> how recent is your polypaudio
<seb128> current version
<seb128> but the crash was before updating
<tseng> ok perfect
<tseng> http://bugzilla.gnome.org/show_bug.cgi?id=165143
<tseng> pretty sure thats your issue.
<tseng> see if it doesnt go away with this latest polypaudio update
<dholbach> bbl
<tseng> seb128: ive been talking with ondrej directly now and he is interested in sponsoring me on f-spot, so you are out of the loop now (unless you want to be :)
<seb128> tseng: nice :)
<seb128> tseng: hum, probably for the issue
<tseng> sounds that way
<tseng> seb128: hoping we've already got it licked by dropping MAX_CONNECTIONS
<seb128> yep
<sivang> anybody seen random total corruption of reiserfs root under lvm on a dell laptop? I think my whole root fs there just went down the drain..
<zul> hey
<tseng> morn zul 
<zul> how is it going tseng?
<tseng> good
<tseng> running low on obvious issues in mono* :)
<zul> heh...go fix inotify then ;)
<tseng> thats your job!
* tseng hides
* zul smacks tseng
<seb128> is there any plan to upload a package without inotify or with it fixed ?
<zul> seb128: we might have a solution turns inotify when only asked at boot
<zul> if we upload a package without inotify then we would have to bump the abi again
<seb128> just asking because that's annoying users for sure
<zul> seb128: oh i know it is
<tseng> yeah I refrained from advising someone to move to hoary for new mono stuff on account of inotify
<tseng> silly rml
<zul> heh..i didnt say it
<seb128> we should not keep a crashing kernel for days
<zul> i realize that lamont will be working on it tonight
<seb128> k
<seb128> but nobody tried to boot this one before uploading it ?
<seb128> the crash seems to happen for everybody
<zul> i think lamont tested it, it was working with my patches but i didnt have inotify enabled
<seb128> k
<pitti> zul: why not just upload a new kernel with "noinotify" as default?
<pitti> zul: then you could keep the ABI
<seb128> so lamont doesn't use GNOME/gamin I guess :p
<zul> pitti: thats what we are going to do in the next upload
<pitti> ah, cool
* seb128 kicks lamont-away 
<zul> he's on australian time right now
<seb128> you should try a kernel in standard usecase before uploading it :p
<Arphaway> Ey
<tritium> tseng, the latest polypaudio seems great.  Not a single error in /var/log/messages.
<tseng> tritium: wonderful, thanks for testing that!
<tritium> :)
<Arphaway> Damn now i see all those ubunti users I dont feel special anymroe ^^
<Arphaway> anymore 
<mvo> hey Mitario 
<mvo> around?
<Mitario> mvo, jup!
<Mitario> whats up
<mvo> Mitario: ah, great :)
<zul> seb128: how do use gamin?
<seb128> GNOME use it
<zul> k
<seb128> you have nothing to do
<tseng> zul: its a dropin for fam
<tseng> as far as gnome is concerned
<zul> ah i see
<elmo> Kamion: ?
<zul> tseng: building now
<tseng> zul: rock on.
<Mithrandir> daniels: ping?
<daniels> pong
<Mithrandir> you had nstx set up to give out addresses with dhcp?
<daniels> err
<daniels> nope
<Mithrandir> do you know if it's possible?
<[Clint] > shouldn't be; you're not tunneling ethernet
<Kamion> elmo: ?
<Mithrandir> bah, defiency in nstx, then
<elmo> Kamion: nm, sorry
<kagou> hi
* Mithrandir kicks libtool in the head and goes home
<kagou> arglll, with the last kernel under hoary (10-4) my gnome freeze 
<Kamion> kagou: boot with noinotify
<pitti> this should become a FAQ
<elmo> or it should get fixed... :p
<pitti> ez ibreakify boog
<zul> yes yes..
<Kamion> hmm, X breaks on my Via-chipset test laptop again
<zul> elmo: we are trying to fix it
* daniels sobs.
<daniels> Kamion: no it doesn't
<elmo> zul: I'm not having a go dude; but given how badly it breaks stuff, I'm wondering why the problematic patch wasn't just reverted - for now-  yesterday?
<Kamion> elmo: the patch was an ABI change, which makes it fun
<Kamion> daniels: ?
<zul> elmo: because im in the middle of testing it right now and it would have to bump abi again
<elmo> oh, the ABI change was due to inotify? ok, sorry, wasn't aware of that
<Alessio> hi, can i announce www.ubuntuitalia.org? :)
<daniels> Kamion: any idea what the matter is?  it might just be that I need to do the new unichrome.sf.net pull ...
<zul> elmo: besides im building a new kernel right now which turns it off by default keep your fingers crossed 
<kagou> kamion i test ....
<Kamion> daniels: hard to tell; when configuring xserver-xorg, it hangs with some kind of stripey pattern all over the screen, and switching to tty2 the video mode is screwed (i.e. huge characters)
<kagou> what's this "noinotify" ?
<daniels> Kamion: frig.  yeah, I'd say I need to update to r30.  could you please file a major-severity bug on xserver-xorg to update the unichrome.sf.net patch to r30?
<Kamion> turns off inotify :)
<Kamion> daniels: ok
<Kamion> daniels: unfortunately it's hard for me to say when this was introduced; I haven't booted that machine for a while
<daniels> Kamion: sure
<mantiena> daniels, on some systems I get only 640x480 when starting ubuntu hoary liveCD, but xresprobe detect monitor parameters correctly
<bluefoxicy> pitti: ping
<daniels> mantiena: ok
<daniels> it's probably fixed in xorg 6.8.2-0.1
<pitti> bluefoxicy: pong
<daniels> which i hope to upload on tuesday
<bluefoxicy> pitti:  are the hardened kernels going to make hoary universe?
<bluefoxicy> pitti:  or do you not have the manpower to support them for all archs?
<mantiena> daniels, maybe, I think problem is, that in /etc/X11/xorg.conf there are no Monitor parameters (HorizSync and Vrefresh), only basic info:
<mantiena> Section "Monitor"
<mantiena>         Identifier      "Generic Monitor"
<mantiena>         Option          "DPMS"
<mantiena> EndSection
<pitti> bluefoxicy: we can upload them to universe when the outstanding issues are fixed
<pitti> bluefoxicy: however, I really don't have the time to care for them very well
<pitti> bluefoxicy: if you want to help there, I'd appreciate :-)
<bluefoxicy> pitti:  such as?  I noticed there's no restricted (nvidia) modules (I got nvidia glx working by building my own amd64 kernel and module)
<pitti> bluefoxicy: yes, for example. also, the vesa framebuffer is broken on i386 and there are no firmware images
<bluefoxicy> pitti:  i tried repetedly to build kernel debs but they came out broken or something.  No initrd, version numbers were i.e. 2.6.10_custom10.00 instead of 2.6.10-4-hardened-amd64-generic, etc
<pitti> bluefoxicy: the firmware images must somehow be built (the standard kernel debs ship them), but I did not deal with that
<bluefoxicy> mmm
<pitti> bluefoxicy: please use my already existing package as basis
<pitti> bluefoxicy: that get's the basic things right
<bluefoxicy> pitti:  all good points :)
<trulux> I'm trying to help tritium with a python-dependent package issue regarding the python-matplotlib from http://matplotlib.sourceforge.net/installing.html
<bluefoxicy> pitti:  I tried assimilating your grsecurity related configuration into the configuration for amd64 generic 2.6.10 ubuntu kernels
<kagou> thnx Kamion for "noinotify" parameters
<bluefoxicy> I just can't build kernel packages :o
<bluefoxicy> I keep screwing up
<trulux> the problem is that it seems not happy with python 2.4
<mantiena> daniels, and when xorg starts it doesn't detect monitor properly, while xresprobe detect monitor properly.
<trulux> it says << 2.4
<pitti> bluefoxicy: just use the existing linux-hardened package and use debuild :-)
<bluefoxicy> debuild?
* pitti pats his shiny new http://people.ubuntu.com/~pitti/ubuntu-cve.html
<trulux> and no depends. refer to that, at leats tritium points this out
<pitti> bluefoxicy: a nice wrapper around dpkg-buildpackage :-)
<bluefoxicy> pitti:  you supply 32 bit kernels though, I tried apt-get source -B and stuff but it was like "hi what no source archives for your architecture"
<pitti> bluefoxicy: so far I only build powerpc and i386 kernels
<pitti> bluefoxicy: because I don't have any other hardware for testing
<pitti> bluefoxicy: but adding new platforms is trivial
<daniels> mantiena: please file a bug, severity normal, with /var/log/Xorg.0.log, /etc/X11/xorg.conf, and the output of lspci, xresprobe dummy, and ddcprobe
<bluefoxicy> pitti:  I have amd64 but i'm using nvidia too; I can always test, though I do like to avoid rebooting whenever i can :)
<Nafallo> pitti: nice! *bookmarks*
* bluefoxicy ponder
<bluefoxicy> I wonder if I could run xen on amd64
<pitti> bluefoxicy: cool, then let's add the amd64 images
<pitti> bluefoxicy: then you can test the grsec/pax stuff first
<bluefoxicy> pitti:  do you have restricted/nvidia kernel modules too that you could add for me?
<pitti> bluefoxicy: later we can add restricted modules, but that has to happen for all arches
<mantiena> daniels, ok, but I think I should test this with new xorg if it's could be fixed in xorg 6.8.2-0.1. Todays liveCD (http://archive.ubuntu.com/cdimage/daily-live/20050224/ ) has xorg 6.8.2-0.1 ?
<pitti> bluefoxicy: no, I think that requires a separate source package
<bluefoxicy> k
* bluefoxicy alters his xorg.conf then and uses nv instead of nvidia; I don't use 3d anyway
<Kamion> mantiena: no, because 6.8.2-0.1 is not in the archive yet
<mantiena> Kamion, where I can get thsi version or when this will be in archive ?
<Kamion> 16:04 < daniels> it's probably fixed in xorg 6.8.2-0.1
<Kamion> 16:04 < daniels> which i hope to upload on tuesday
<pitti> fuck the UVF :-)
<mantiena> Kamion, sorry, I don't notice second line ;)
<bluefoxicy> it's thursday
<bluefoxicy> is tuesday in relation to the negative or positive relative temporal offset?
<bluefoxicy> weekly time is cyclical.
<mantiena> Kamion, btw, I already filled debian developer application ;)
<mantiena> bluefoxicy, ;)
<daniels> pitti: already got an exemption
<bluefoxicy> oh god
<mantiena> daniels, you what is your localtime ?
<bluefoxicy> does anyone else here read the kernel changelogs?
<bluefoxicy> I was reading the -bk incriments and saw some memset changes
<daniels> mantiena: 0321
<bluefoxicy> and now in the changelog
<bluefoxicy> <joe.korty@ccur.com>
<bluefoxicy> 	[PATCH]  memset argument order misuses
<bluefoxicy> 	A simple 'grep memset.*\<0);' shows argument order errors in several
<bluefoxicy> 	uses of memset.
<bluefoxicy> Yes, we're all programmers.  No, none of us know how to use memset()
<Kamion> hands up the programmer here who's never made a mistake ...
<bluefoxicy> anyway.  I shouldn't bother this channel with useless programming trivia
* zul raises his hand..hah!
<bluefoxicy> Kamion:  hands up the programmer here who still repetedly uses strcpy(src, dest) and then doesn't catch it until years later :)
<mantiena> daniels, it's time to go to bed ?
<daniels> mantiena: not yet
<mantiena> daniels, ok, then I wanna talk with you about including nvidia and fireglx drivers into xorg.conf ;)
<daniels> mantiena: hold up
<mantiena> daniels, I told you one time about this - I think that automatic xserver-xorg configuration could write Driver "nvidia" or Driver "frglx" in some cases, for example if these binary drivers are already installed on system
<tseng> mantiena: why would they already be installed unless you are doing a reconfigure
<daniels> mantiena: yes, and I think this would be a support nightmare
<mantiena> daniels, because of proprietary binary-only drivers ?
<zul> brb
<mantiena> daniels, then we can make using these drivers only if some environment variable, for example "USECLOSEDSOURCEDRIVERS" is set
<daniels> mantiena: ... what would the point be, then?
<mantiena> daniels, point is in liveCD - if you want to make working 3D software (games, education applications like celestia, etc.) then you need to use nvidia and fireglx drivers, because majority of systems with 3D video hardware uses nvidia or radeon
<Kamion> how would you set an environment variable before xorg configuration in the live CD, then? :P
<mantiena> Kamion, simply, in isolinux.cfg
<Kamion> well, I guess if you're customising the live CD then you could customise casper too
<tseng> Kamion: right. most of his arguments are based on a user already jumping through one or more hoops to get the driver in the first place
<tseng> then saying its too much work to edit one line in xorg.conf
<daniels> that would require installing nvidia-glx or fglrx on the fly, which is a pain in the arse
<mantiena> Kamion, yea, but I don't wan't to change all the packages, so it would be better if my patch to xserver-xorg debconf scripts will be included into upstream
<mantiena> daniels, don't worry about installing nvidia-glx or fglrx on the fly ;)
<daniels> you're creating a with-binary-drivers derivative distribution?
<daniels> mantiena: errr ... how not?
<Kamion> if he's creating a derivative then he could make those packages be installed by default
<mantiena> daniels, It's simply not your responsibility
<mantiena> Kamion, yea
<daniels> you do realise that you'd need an nvidia livecd, an fglrx livecd, and a stock-dri livecd?
<Kamion> mantiena: you do know that installing nvidia-glx breaks non-nvidia systems?
<daniels> because both nvidia-glx and xorg-driver-fglrx divert libGL.so.1.2
<daniels> Kamion: ditto fglrx/ati
<Kamion> indeed
<sivang> Kamion: do you know if the warty livecd supports Macintosh (G4/G5) machines?
<Kamion> sivang: no, it doesn't
<Kamion> there was no powerpc live CD for warty
<sivang> Kamion: ok, thanks.
<Kamion> sivang: the hoary powerpc live CD should work fine
<sivang> Kamion: the hoary one does support it right?
<sivang> Kamion: :)
<pitti> Riddell: ping
<sivang> pitti: where would you say would be a good place to have the checkbox for browsing support? (I had gnome-cups-add in mind)
<pitti> sivang: yeah, g-c-add in any case
<pitti> sivang: probably also a menu option in g-c-manager
<sivang> pitti: sure, that was my original plan, but I thought that maybe in gnome-cups-add where you choose use a detected printer maybe? (not sure if it refers to IPP)
<pitti> sivang: printers discovered with browsing don't need to be added any more
<pitti> sivang: they are already active
<pitti> sivang: so actually it would make more sense in g-c-m alone
<sivang> pitti: ah so that list underneath that option is just for smb?
<pitti> sivang: maybe you can make this a bit more obvious
<pitti> sivang: but I think a menu option is fine for a start
<pitti> sivang: or put a checkbox somewhere into the main window
<dholbach> re
<bluefoxicy> wtf installing mythtv is scary
<sivang> pitti: but we have "[*]  Use a detected printer" would it be wise to pop out a window when the user chooses this option and ask if he want to enable browsing support, becase otherwise that list region would always stay empty without any detected printer, am I right?
<pitti> sivang: what do you mean?
<pitti> sivang: oh no
<pitti> sivang: the list in g-c-add is for locally detected printers
<pitti> sivang: like usb, samba, or whatever
<pitti> sivang: not IPP
<sivang> pitti: ahhh oops sorry!
<pitti> sivang: I think a menu option in the manager, or a checkbox in the main window are fine
<ficusplanet> Could someone really quickly explain what the "Usage: /usr/sbin/pmi query|action <event>" from the recently-added-to-hoary powermanagement-interface means?  I've been trying to get my laptop to suspend, but can't figure it out.
<pitti> elmo: some universe security syncs, please: konversation [Ubuntu override ok] , chbg, zope-zwiki, queue
* Kamion finally disentangles #2591
* pitti goes to do some Taekwondo, see you later
<zul> wohoo...gamin no crash
<mvo> zul: you mean ... inotify is working now? 
<zul> next upload which hopefully will be tonight
<mvo> *rock*
<tseng> mvo: not working. just disabled by default
<zul> which is still better than crashing every time
<sivang> anybody knows what goes on with kernel -4 , it seems to want to take down my desktop also..:-(
<Kamion> sivang: boot with noinotify
<zul> sivang: add noinotify
<ogra> sivang: iz gtk bug, remove libgtk2 *grin* (i guess that would actually solve it too)
<dholbach> elmo: could you please sync  wesnoth  and  liferea  from sid? (both contain bugfixes)
<dholbach> elmo: thanks
<shaya> is something in hoary fscked up right now?
<shaya> gamin seems to be panic'ing my kernel
<shaya> as soon as I log into gnome it goes boom
<azeem> amu: ping
<tseng> shaya: boot with noinotify
<shaya> thanks
<Nafallo> hehe, maybe set that as topic? ;-)
<shaya> or maybe boot with -4 kernel
<tseng> no
<tseng> -4 is the broken one
<shaya> forgot that I upgraded kernel yesterday
* ..[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 | If your system hangs at login, try booting with 'noinotify'
<sivang> Kamion: ahh, already fsck.reiserfs the hd there, and now it says the someone has tried killing init :)
<sivang> Kamion: I guess I just whacked my partition..
<sivang> ogra: EZ GTK BOOG? 
<sivang> ogra: how can GTK BOOG destroy my partitions? :)
<sivang> I now have on the laptop "pivot_root: Permission denied" and "chroot: cannon run command '/sbin/init': Permission denied"
* sivang will try reboot now on the desktop.
<sivang> (with noinotify)
<mooch> some icons are missing... namely the "clean desktop" at the left bottom and the trash can on the right onw
<mooch> even one
<sivang> Kamion: thank you, I just revivied my desktop :)
<sivang> I wonder how long has this been on the topic...:)
<Kamion> kinda surprised that caused errors like that though
<Kamion> not long
<sivang> Kamion: I wish I just tried that before killing my reiserfs on the laptop..:-/
<sivang> Kamion: do you know if it's ok to fsck.reiserfs against an lvm volume which contains one reiserfs partition?
<Kamion> um, no idea, sounds risky
<sivang> Kamion: sorry, it contains two partitions, home and /
<Kamion> surely you'd want to run fsck against the actual logical volume
<sivang> Kamion: ok, that probably explaines to problems I have now..
<sivang> Kamion: yes, but I couldn't do it while it's mounted.
<Kamion> er, if you mean "against an lvm logical volume", then that's fine, if you mean the physical volume then that's not fine
<Kamion> but an LV cannot contain two partitions so I assume you mean a PV
<sivang> Kamion: err, yes 
<sivang> Kamion: never mind, I'll reinstall worst case :)
<shaya> here's a question.  If the idea is to make boot times as short as possible.  Why is LVM and EVMS and device mapper in the default install
<shaya> can't one argue that plain joe users dont use it
<Kamion> those scripts exit early if they're not being used, and making boot times as short as possible is not the *only* criterion
<Kamion> not having to install random packages to use useful filesystem-level facilities was also a design issue
<shaya> another thought, why is gdm after bringing network up.
<shaya> takes a good amount of time for network to come up here at Columbia
<shaya> laptop just sitting around while we wait
<Kamion> things like NFS home probably; make your network come up faster :-)
<Kamion> networking does have to come up very early, it's a major sequence point
<shaya> hmm
<abelli> smurfix: ping. smile u have mail.
<smurfix> abelli: should be OK
<abelli> smurfix: thank you so muc
<abelli> h
<sivang> Hey sabdfl 
<sabdfl> hey all, seems https://bugzilla.ubuntu.com/show_bug.cgi?id=1440 lives on
<Kamion> sigh, a drive-by
<sivang> yeah , probably
<sabdfl> sorry, dropped the connection
<sabdfl> did anyone respond to my comment on #1440?
<zul> i was about to
<sabdfl> i think i'm seeing something related on a machine with hoary installed
<zul> #undef ATA_ENABLE_ATAPI  /* define to enable ATAPI support */
<sabdfl> i don't see the cdrom drive at all, the SATA drives are working fine
<Kamion> sabdfl: just noted in #1440 that I asked jbailey to have a look at that bug
<Kamion> (a couple of days ago) - since he was working on #1763 which is apparently related
<sabdfl> Kamion, jbailey: this is one that has reared its head on every high-end machine i've tried to install on
<zul> Kamion: and then he asked me to have a look at it and ihavent had a chance to yet
<sabdfl> we really need to stomp on it
<sabdfl> ok
<Kamion> zul: ah, right, feel free to catch up on the reassign :)
<sabdfl> at boot time I saw some ide0 and ide1 messages, along the lines of the resource being busy
<zul> Kamion: if you change #undef ATA_ENABLE_ATAPI to a #define that might do it
<zul> in libata.h
<Kamion> that in the kernel?
<zul> yep
<Kamion> that sounds like something with wide-ranging repercussions
<zul> line 40 in include/libata.h 
<zul> yeah im not sure about it though
<sabdfl> anybody else also found recent kernels very unstable?
<Kamion> that appears to delegate ATAPI control to the scsi drivers?
<Mitario> hi guys
<Mithrandir> sabdfl: inotify problems, it seems
<zul> sabdfl, yeah it should be fixed in the next upload
<Kamion> sabdfl: everyone needs to boot with noinotify; zul's looking at making that the default until we know what's up
<tseng> i tested zul's patch here already
<tseng> it seems to disable inotify, at least
<Kamion> sounds good
<sivang> sabdfl: inotify problem , same here
<sabdfl> ok
<sivang> also on dell laptop , one fs down presumably due to inotify problem
<zul> Kamion: in  the 2.6.11 bitkeeper for sata finished ATAPI support and turns it on 
<Kamion> zul: would that be a big deal to pull in?
<Kamion> the thing is that affects nearly every system on the planet, whereas at the moment it's only some systems that are affected
<Kamion> so it's an interesting risk assessment
<winkle> tseng: nice to see muine 0.8.2, it crashes on play here though... :-/
<tseng> winkle: are you using esdsink?
<zul> Kamion i was going to try this weekend...make a test kernel and get someone to test it with sata and atapi cd-rom
<tseng> winkle: update to the latest polypaudio and let me know if you still have the bug please.
<winkle> tseng: will do, thanks
<Kamion> zul: would it be possible to get the scsi subsystem not to claim that bus? (which seems to be part of the issue)
<zul> it could be possible
<Kamion> I still have no idea why my SATA system has never suffered from this issue
<zul> il check lkml
<zul> yeah its the first time seeing this for me
<Kamion> it has an ATAPI CD-RW, I believe
<zul> it could be dependent on what kind of sata they are using as well though
<Kamion> yeah, sata_via here
<zul> sabdfl, what kind of sata do you have?
<zul> brb
<robertj^> I think ;)
<robertj^> doh wrong channel
<Nafallo> hehe
* robertj^ takes the opportunity to note the he am as well
<robertj^> Are there any plans for a GUI Grub config tool?
<mdz> morning
<dholbach> hi mdz
<ogra> hi
<robertj^> mdz: morning, do you know of any plans for a grub gui config tool?
<sivang> morning mdz
<ogra> robertj^: do you really think thats necessary ?
<robertj^> ogra: I do just for setting the default OS and the timeout period
<ogra> robertj^, something like that ? (not written for or tested on hoary) http://www.grawert.net/software/startup-settings/index.html
<Nafallo> mdz: hi there.
<robertj^> I really didn't and then my wife complained, and that's kinda the standard I use to measuer things
<robertj^> ogra: yeah, like that
<mdz> robertj^: I think gnome-system-tools has one
<ogra> robertj^: unfortunately i currently dont have the time to make it ready for universe/hoary....
<robertj^> ogra: yeah, file it as a blocker for grumpy?
<robertj^> mdz: yeah, I knew about that, It might even be on my system somewhere, I was just wondering if something better existed and ogra's is just what I was thinking
<ogra> robertj^: mdz is right, but i think its disabled (i guess because of bugs) 
<dholbach> ogra: yes... it put my menu.lst completely on crack some months ago
<robertj^> ogra: that looks to be a much nicer solution if it works
<zul> bbl
<robertj^> ogra: btw, what do you think about a grub submenu for older kernels?
<robertj^> again, grumpy timeframe
<ogra> robertj^: what do you mean by grub submenu for older kernels ?
<robertj^> ogra: currently every old-revision kernel piles up on the grub menu
<AndyR> evenin' all
<robertj^> so instead it would say "Older kernels..."
<ogra> robertj^: ah, you mean the description....
<robertj^> ogra: I don't think so (could be wrong)
<robertj^> You would have Ubuntu, Windows, Older Ubuntu kernel on your menu
<robertj^> and if you select the Older Ubuntu kernel you would get a list of all the old stuff
<ogra> robertj^: in my menu.lst i currently have Default and Previous
<mdz> daniels: ping, re: xserver-xorg keyboard configuration
<ogra> and the respective recovery modes
<robertj^> yeah
<doko> jdub, mdz: any reason why libcairo1/libcairo1-dev are in main? there are no packages depending on it, which are in main as well. rationale: gcj-4.0 requires version 0.3.0, which I would like to get synced from unstable.
<mdz> smurfix: ping, re: keyboard selector
<ogra> robertj^: so why keep all the old stuff additionally ?
<mdz> doko: check germinate output, it will explain why it is in main
<robertj^> Dunno, it just stays so I assume it was ment to
<ogra> robertj^: i would just uninstall the old kernels
<smurfix> mdz: The console stuff is uploaded, the main problem I see right now is that it has a few new strings which need to get localized
<robertj^> are stable kernels marked as conflicting?
<elmo> doko: build-depend of dia
<elmo> but given it's not listed as a depends, I guess it's unused
<smurfix> mdz: wrt X keyboards, I'm still fiddling with code that finds the "best" X keymap to use. Should be ready weekendish.
<doko> elmo: ok, I'll check
<smurfix> mdz: Haven't seen any bug reports about the installer part yet, other than "it doesn't yet solve the X problem".
<robertj^> ogra: there's currently no facility to automatically uninstall the kernel is there? A metapackage shouldn't satisfy itself by taking the highest version dep
<robertj^> so I guess it's not just a matter of setting up a linux-kernel and last-linux-kernel
<ogra> robertj^: i think the metapackage always depends on the last stable one.... 
<robertj^> anyway, thats a teensy issue really I guess
<robertj^> Now that I think about it, it's probably not needed. The rationale is that NTLDR only shows multiple booting options if multiple installs are available
<robertj^> My wife knows that, but she's probably a-typical, although that does seem to be the most logical assumption...
<mdz> smurfix: yeah, console stuff is looking good. dvorak is a single keystroke :-)
<mdz> smurfix: glad to hear that X is coming along.  any unexpected issues?
<smurfix> mdz: as I said, I'm still fiddling with the analyzing code. I expect there not to be major problems.
<smurfix> mdz: The main problem is that the X keymaps list many symbols in more locations than the console map has them.
<mdz> Kamion,lamont: what shall we do about this inotify mess?  is a fix inbound, or do we need to back out to the old inotify patch?
<tseng> mdz: zul created a patch (ive tested) to default inotify to off
<smurfix> mdz: for instance, a German X keymap has </> on the pc-105 key, but also on shift+alt+y/x where nobody would expect them
<mdz> smurfix: american english seems to take very many keystrokes to determine
<mdz> tseng: should we just go back to dnotify?  gamin supports both, rigth?
<mdz> smurfix: hmm, I see
<tseng> mdz: gamin seems to happily fall back on dnotify when inotify is missing
<smurfix> mdz: The problem is that lots of keyboards do have querty, and mostly-identical layouts, so the easy stuff (like Dvorak ;-) is gone first
<smurfix> mdz: German layout needs between 4 and 8 keypresses, depending on which path you take.
<tseng> mdz: http://zulinux.homelinux.net/ubuntu/kernel/enable-inotify.patch < worksforme.. he is looking to push an upload sometime tonight with this, and hopefully "fix" inotify later
<mdz> tseng: he == zul?
<tseng> via lamont
<tseng> yes.
<mdz> ok
<smurfix> mdz: Shortening the paths isn't easy because I need to allow for lookalike characters. Writing a global optimizer that attempts to shorten the median path is probably a post-Hoary exercise.
<mdz> smurfix: agreed
<mdz> smurfix: the paths for Hoary will determine whether we can use the selector as the default method in the installer, though
<Kamion> mdz: in any case I think having the guessed option right there up front, the way it is at the moment, is good
<Kamion> it makes the most likely case easiest
<mdz> indeed
<mdz> dvorak is the same number of keystrokes either way (down-down-enter vs. down-enter-q)
* Kamion goes away again
<elmo> fwiw, detecting the (I think) British keyboard at the DC takes 6 or 7 keyws
<smurfix> mdz: *Your* dvorak takes only one key, but there are others. :-/  Integrating X keyboards into that selector is very difficult though and requires a lot of testing because the X keymaps have too many symbols in locations where no user would know how to find them.
* mvo goes to bed now
<doko> elmo: please sync dia from unstable, the libcairo build-dep was disabled in unstable, the python fix isn't necessary anymore. then libcairo1-dev can be synced from unstable and be kept in main because libgcj6-awt starts to depend on it.
<smurfix> The console keymaps are comparatively sane and have (mostly) exactly those keys assigned which are actually printed on the keyboard.
<elmo> doko: ok to override ubuntu modifications to dia?
<tseng> elmo: while youre at it, could you please sync f-spot from unstable?
<geppy> If you try to mount the logical partition holding the virtual partitions, it kills the system.
<geppy> Sorry if my terminology is a bit off.  Basically, 'mount /dev/hda4 /mnt/point' completely kills the system.
<mdz> geppy: what do you mean, completely kills the system?  do you get a kernel panic?
<elmo> tseng: same question
<tseng> elmo: overwriting local is fine
<geppy> mdz:  Not a kernel panic, but it literally kills the system.  Nothing responds.  CTRL-ALT-BACKSPACE and CTRL-ALT-DEL do nothing;  it just stops completely.
<bluefoxicy> Can anyone confirm if there's actually a stable release of Qemu at this time that should run on amd64, and should I throw a bug at bugzilla?
<tseng> bluefoxicy: you can throw a request at MOTU once you find yourself a working qemu package
<bluefoxicy> tseng:  I'd be happy to build one if I hadn't failed repetedly at building kernel packages and had any clue what I was doing :)  I don't want to break ubuntu (like whoever's maintaining gtk-gnutella did, with much help from whoever's coding gtk-gnutella's busted ass build system)
<doko> elmo: yes, that's the python fix, which was corrected in unstable by depending on python-dev.
<tseng> bluefoxicy: most of the universe team is directed on fixing up python packages, im trying to beat mono * into shape
<tseng> bluefoxicy: no one free to fix your pet bugs for you atm, youll have to do the footwork or wait, sorry
<tseng> you have a few weeks to get it sorted out :)
<Kamion> geppy: do you mean "extended partition containing the logical partitions"?
<geppy> Kamion:  Yes, sorry.
<Kamion> geppy: it's quite confusing when you talk about logical partitions because a logical partition is in fact something else, which people mount every day; I suspect that's why people haven't been paying much attention :-)
<geppy> =)
<Kamion> geppy: I'll give it a try when I'm back home tomorrow
<geppy> Kamion:  Alright;  just don't have anything important running. =P
<mdz> perhaps it's the usual inotify bug
<tseng> elmo: urgh, that sync grabbed f-spot 0.0.9-2. im seeing -3 here from ftp.debian.org
<wasabi_> /j #anhksvn
<wasabi_> oops
<bluefoxicy> tseng:  I can wait
<bluefoxicy> tseng:  you've seen me write and fix ebuilds, i'd do the work if I knew wtf I was doing
<shaya> hmm
<shaya> heh, didn't realize I had a package in Universe
<dholbach> shaya: which one?
<shaya> I wonder if any other ubuntu user uses but me
<shaya> hebcal
<shaya> where's popularity contest results for ubuntu?
<Evaso> hi guys, what about pmount and udf writing in ubuntu?
<Evaso> is this actually working on hoary?
#ubuntu-devel 2005-03-08
<Evaso> anybody here?
<sivang> hi Evaso , what do you mean udf printing?
<Evaso> sivang: packet cd wrting
<Evaso> sivang: is in the upstream kernel 2.6.10
<sivang> Evaso: join #ubuntu-kernel and ask there, they may know better :)
<Evaso> sivang: but i think we have problem in debian/unstable ubuntu about autmatically mount this type of cd/dvd with writing support available
<Evaso> sivang: i had in debian already available, so is also in hoary, the problem is about user space tools
<sivang> Evaso: aren't they also in universe?
<Evaso> sivang: do u know that the packet writing is created as a virtual device /dev/pktcdvd/0 ?
<sivang> Evaso: sorry, I have no idea :-(
<sivang> Evaso: If you're question is regarding when/how/if to add support for this in ubuntu, you could email the devel list with your suggestion to it and I'm sure somebody would comment and respond you.
<ogra> Evaso, CONFIG_CDROM_PKTCDVD=m 
<ogra> Evaso, so the module should be there
<sivang> ogra: what about the user  space tools? if they're not in universe we should get them there :)
<ogra> Evaso, (from /boot/config-2.6.10-3-amd64-k8)
<Evaso> ogra: i tink that the module is compiled already in the kernel
<ogra> sivang: then someone should put them on UniverseCandidates
<Evaso> but how pmount/fstab handle the /dev/pktcdvd/0 device?
<ogra> Evaso: that was what i meant with the baove
<sivang> Evaso: that's intersting question, you can ask pitti here tommorow morning if you like, or have the module loaded and expriment :). (he wrote pmount)
<ogra> Evaso: sorry, i never used packetcd, so i cant tell
<sivang> Evaso: can this be tested on CDRWs as well? (as opposed to DVDs)
<Evaso> ogra/sivang: mounting manually on debian unstable works perfectly
<sivang> Evaso: and you can add remove files as much as you want?
<Evaso> for example mount /dev/pktcdvd/0 /mymedia/cdrom
<ogra> Evaso: does it work manually on ubuntu ?
<Evaso> i had not ubuntu installed but i tink that (as debian) it mount udf on /dev/hdx so is only readable
<ogra> Evaso: but i think the above way would work in ubuntu too
<Evaso> yes can u install udftools in ubuntu?
<ogra> Evaso: even if the cdrom defaults to hdX you should be able to mount it manually like above
<sivang> Evaso: udftools installed fine here :0
<sivang> Evaso: sorry, I meant = :-)
<Evaso> well, so "the console" way is the ubuntu choiche?
<Evaso> sivang: can u format a cdrw with udf?
<sivang> Evaso: I can try, but I use stock kernels.
<ogra> sivang: it should work with the stock kernel
<sivang> Evaso: I am not sure if I have udf support in stock kernel, and I am not going to recompile one now - sorry am too busy for that :-(
<sivang> ogra: ah ok
<sivang> Evaso: then I can give it a try for you :)
<sivang> ogra: how do I enable it? modprobe pktcdvd ?
<ogra> sivang: btw: cat /proc/filesystems should show you udf
<sivang> nodev   binfmt_misc
<sivang>         udf
<sivang>         iso9660
<sivang> yes, so I have it :)
<ogra> sivang: you, you load the pktcdvd
<ogra> module
<dholbach> anyone familiar with gnome-cdbs--packaging?
<dholbach> and yes... i know that seb128 isnt here :-)
<ogra> dholbach: he just left
<sivang> dholbach: to what degree? ;-) (I know really tincy bits if it)
<Evaso> sivang: do u not need to modprobe pktcdvd udftools load it on boot
<dholbach> sivang: gconf installation stuff throws an error
<sivang> Evaso: I didn't do that, and I pasted you the output of my fs modueles :)
<sivang> ogra: I surely don't need pktcdvd for CDRW right?
<jbailey> dholbach: I'm about as familiar with cdbs as you can get.  =) What do you need?
<sivang> dholbach: you'd better he help you :)
<Evaso> sivang: no u must to format a cd for udf with mkudffs
<sivang> jbailey: Hey Jeff :)
<ogra> sivang: with pktcdvd you can use a cd like a harddisk...you must format it before
<jbailey> sivang: Heya!
<sivang> Evaso: ah ok, then when my CDRW is freed (used currently to install ubutnu on a crashed laptop) I will give it a couple of tests.
<daniels> mdz: pong
<Nafallo> jbailey: I love your suggestion about iptables.d, any work being done? :-)
<jbailey> Nafallo: Nope.  ServerTeam stuff is all post-Hoary.
<Nafallo> jbailey: ahh, oki :-).
<seb128> jdub: around ?
* sivang wonders if anybody know if the inotify fix is already updated/uploaded etc?
* lamont returns from a fun day at school
<Evaso> seb128: how gnome-volume-manger/pmount handle /dev/packetcdvd devices?
<seb128> that would be a question for pitti
<sivang> Evaso: as I said, mail the devel list or talk to pitti tommorow morning :)
<dholbach> seb128: do you know if gnome/help-installation would break, if upstream stored it in   help/<app>/<lang> instead of  help/<app> ?
<jdub> seb128: yo
<seb128> dholbach: no idea, why ?
<seb128> jdub: hey :) About the theme, pmi has sleep/hibernate actions, dunno if you want 2 actions in gdm
<dholbach> seb128: i'm busy with coaster and the installation of the gnome-help always fails
<seb128> how ?
<dholbach> right now i patched the tarball to use help/<lang>
<dholbach> but it's still wrong
<jdub> seb128: yeah, will have to sort that out
<jdub> seb128: all mixed up with potential theme changes, etc. ;)
<dholbach> i dont understand the gnome-help-*omf*-stuff yet
<seb128> let me know if I need to add an hibernate mode to gdm 
<seb128> atm there is a suspend action
<seb128> if we want both suspend/hibernate we need to hack it :)
<seb128> dholbach: I don't get your issue, yelp doesn't list it ?
<dholbach> seb128: no, the package isnt built :-)
<jdub> seb128: i think it's worth doing that anyway, for future use
<dholbach> seb128: just wanted to know if you knew about any issues regarding help/* in the wrong directories
<seb128> the make install should do that correctly, the package doesn't change anythin here
<dholbach> seb128: ok, will try again
<seb128> jdub: right
* lamont looks around for a ppc person with a little time on his hands
<Evaso> i must to go, bye guys
<doko_> elmo: dia built ok on all archs, please sync libcairo
<lapoman> hi
<lapoman> any one here can give me some advice on how to set up powernowd to lower down the cpufreq if the temperature is higher than some critical val?
<lapoman> I am testing hoary on laptop...
<tuxdisciple> lapoman, As am I... sound is very broken for me so far :/
<lapoman> for me all is good except two little things, well one is actually not so little, it gets my machine stuck!
<lapoman> each time I unplug the external harddisk...
<tuxdisciple> Anyone have wisdom as it relates to getting hoary to play nice on a thinkpad? cs46xx is loading fine, but alsa just barfs on and on about not having a sound card
<lapoman> I come from suse, and I do miss Yast!!! Ubuntu should have something like it...
* lamont looks around for some ppc user who's willing to test somethign for him
<tuxdisciple> hehe
<tuxdisciple> I think I may be looking at a kernel recompile... 
* tuxdisciple sighs
<sladen> and makes it appear to have 'intelligence'
<lamont> tuxdisciple: nah.. much simpler.
<lamont> 1) make sure you have linux-image-2.6.10-4_2.6.10-23 installed
<lamont> then wait for me to finish building the -24 candidate
<tuxdisciple> lol
<lamont> of course, -23 needs to be booted with 'noinotify' unless you like pain
<lamont> then install the -24 candidate
<tuxdisciple> I'll update to it right now... 
<lamont> but don't reboot into -24, and see if modprobe will install modules, or if it bitches
<lamont> (that is, we need to verify that modules from -24 can load on a -23 kernel)
<tuxdisciple> so... update to -23, alter menu.lst to make sure it does noinotify as a kernel option I assume...
<tuxdisciple> then update to -24 and try to modprobe will install modules
<sivang> tseng: how do I install build deps of a package? (it saves alot awful build env installs by hand ) 
<tuxdisciple> I'll need to modprobe with a full path to the -24 modules won't I?
<ogra> sivang: sudo apt-get build-dep <packagename>
<sivang> ogra: thanks, I did "build-deps" didn't work :)
<dholbach> sivang: let pbuilder do it for you :-)
<sivang> dholbach: ah, you're right, I should set it up but not now :) maybe tommorow
<tuxdisciple> lamont, That sound right ?
<dholbach> sivang: the instruction on wiki/PbuilderHowto is very straight-forward
<lamont> won't need full path - the -24 candidate overwrites the -23 modules...
<lamont> hence the need to test
<sivang> dholbach: I Kniw, been thinking of doing it for quite some time now
<tuxdisciple> Okay, I'm updated to -23, rebooting now, and I'll be back in a minute
* lamont begins to wonder if he should feel guilty... 
<lamont> ah, there he is
<tuxdisciple> hehe
<tuxdisciple> Had to get a piece of pizza
<lamont> ah, ok
<dholbach> oh... pizza
<dholbach> yum
<tuxdisciple> Eww... fedora
* lamont fixes the ftbfs, launches a build
<tuxdisciple> lamont, just let me know when I can apt
<lamont> yeah - could take it a little bit...
<dholbach> tuxdisciple: i was just in a state of absolute delight, thanks for spoiling it
<lamont> which kernel flavor are you using?
<tuxdisciple> ubuntu one
<lamont> (power3, power4, or powerpc?)
<tuxdisciple> me?
<tuxdisciple> x86
<lamont> tuxdisciple: I need ppc testing - already did i386 testing...
<mdz> daniels: did we change the way that we guess the keyboard layout in X anytime recently?
<mdz> daniels: I'm ending up with qwerty
<lamont> I don't _have_ a ppc box that's happy...
<tuxdisciple> lamont, Yeah.. but I need a working cs46xx / alsa config :)
<tuxdisciple> dholbach, Sorry .. yum brings back bad memories of a fedora attempt
<daniels> mdz: i haven't uploaded x in ages, but i know why it's broken now
<dholbach> tuxdisciple: i can imagine :-)
<daniels> mdz: realised the other day that we were testing for en_AU, en_US, de_DE, et al
<daniels> mdz: working out how that interacts with utf-8 is left as an exercise to the reader
<tuxdisciple> hoary is great except alsa refuses to see my sound card
<ogra> night all
<daniels> mdz: (this is why we were *always* getting us on the live cd)
<dholbach> sleep tight ogra 
<lamont> mdz have a ppc box?
<daniels> mdz: as for dvorak, i honestly don't know how you ever ended up getting a dvorak layout, since we test $LANG
<tuxdisciple> this is the first distro I actually want to help with testing... I would've with slack earlier on but patrick seems so... beyond me
<tuxdisciple> lamont, I do have a nice testbed for some stuff....
* tuxdisciple glances at the duallie opteron workstation
* lamont makes another note to finish neatening up the workspace, so he can put a pic up on the web
<tuxdisciple> It will be fun to try Hoary on that thing
<lamont> hrm.. really need a new monitor
<bluefoxicy> the i386 2.6.10-4 kernel in hoary is VERIFIABLY BROKEN somewhere.
<bluefoxicy> I know because i just installed 32 bit ubuntu
<bluefoxicy> tried to log into gnome
<tuxdisciple> Did you use the noinotify option?
<bluefoxicy> and over several trials it HARD FROZE while loading gnome
<bluefoxicy> numlock key did nothing; alt+sysrq+O didn't turn the machine off
<bluefoxicy> needed a hard reset (cold boot)
* dholbach points towards the topic
<tuxdisciple> bluefoxicy, Try giving it the kernel option 'noinotify' on boot
<bluefoxicy> tuxdisciple:  ok
<bluefoxicy> tuxdisciple:  it's working on the 64 bit kernel, different / and same /home
<bluefoxicy> i'll get to that later though.  It doesn't much matter; I installed a 32 bit system so I can play with xen
<tuxdisciple> bluefoxicy, I have the 10-4 running fine, but had the exact same issue
* bluefoxicy nods
<bluefoxicy> i didn't read the topic :) thought it might be a (potentially major) issue you may have missed, looks like you found it though.
* bluefoxicy goes to shower, because he needs one.
<dholbach> i'm off to bed, bye everyone
<tuxdisciple> lamont, I'm going to build a .10 kernel tree with ALSA and the driver hardcoded in to see if its a module problem, or an alsa related problem (init scripts maybe?)
<tuxdisciple> dholbach, Night!
<dholbach> bye tuxdisciple 
<sivang> jdub: working on #2251, do you know what's the "Edit" subitems are for in gnome-cups-manager? I edited the glad inteface file of gnome-cups-manager and it seems it fscked bit the other itesm. Do you happen to know where is the gnome-cups-manager menubar and items are in code?
<sivang> jdub: oops, I Know what the edit are now, just can't figure where the code for the menubar to add options there.
<zul> hey
<tseng> sivang: yep, you definately want pbuilder
<tseng> sivang: saves you pain later when you dont realize you missed a build-dep (you already had it installed as a dep of something else)
<tseng> not that ive ever done this
<zul> of course not
<lamont> zul: any ppc boxen there?
<zul> lamont: nope just x86 and sparc
<lamont> mjg59: *$^(%)^_&+_)(%^$&)*^_(&+)*_)%^(_+*+^_*%^(&)
<zul> svenl around get him to try...
<lamont>   AS      arch/ppc/kernel/swsusp.o
<lamont> arch/ppc/kernel/swsusp.S: Assembler messages:
<lamont> arch/ppc/kernel/swsusp.S:139: Error: Unrecognized opcode: `dssall'
<lamont> first it has to actually build
<tuxdisciple> lamont, :/
<lamont> Kamion: you around?
<zul> oh well thats a problem
<lamont> zul: on the bright side, i386 is a non-abievent
<zul> sweet...so the patched work
<lamont> yes
<lamont> hrm... I could just disable SWSUSP on power3...
* zul does the happy dance
* lamont tries that
<zul> is this with the altivec stuff?
<lamont> this is mjg59's hibernate patch
<elmo_> lamont: that's the power3 haiving POWERPC_PMAC enabled that you and kamion were talking about yesterday?
<zul> ah...ok..
<lamont> elmo_: different source file
<lamont> (specifically, the swsuspend file)
* tuxdisciple whishes he could read C code 
<mjg59> lamont: Ah, sorry - I thought I only asked for it on powerpc?
<mjg59> (rather than power3)
<lamont> ah - power4 shouldn't have it either?
<mjg59> No - the comments say it doesn't work on G5 yet
<lamont>  The only config change is that the powerpc kernel (not power3
<lamont> or power4, and probably not powerpc-smp) should have...
<lamont> DOH!
<mjg59> Yay I win
* lamont ediits a bit more
<mjg59> Haha
* tuxdisciple cheers on lamont
<zul> http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/swsusp-use-list-resume-v4.patch
<zul> er..
<lamont> mjg59: you wanna do the happy-test for me?
<mjg59> lamont: Which happy test?
<lamont> install -23, boot with 'nonotify' (so that you live), install -24 (once it finishes building...), no reboot, make sure that modprobe is still happy
<mjg59> lamont: Sure, just let me find another box
<bob2> thom: are you using netapplet regularily?
<tuxdisciple> lamont, you still need me to try that?
<lamont> tuxdisciple: only on ppc
<tuxdisciple> lamont, architecturist!
* tuxdisciple pouts
<bob2> thom: it seems really damn crashy nowadays.  also, you didn't tell mjg59 that you appletified it.
<lamont> tuxdisciple: you're welcome to try it on x86, but I know it works there...
* tuxdisciple chuckles
* lamont is painfully reminded that killing dpkg-buildpackage in mid-patch is a bad idea
<tseng> lamont: only if you arent up for loosing all your changes and grabbing a fresh archive
<lamont> tseng: yeah.  rm -rf, dpkg-source -x, baz get, rsync -av
<lamont> piece of cake.
* tseng feels poorly for lamont 
<lamont> heh
<lamont> I've had wors
<lamont> e
<schweeb> tseng: hey, how much patching and stuff is involved in packaging mono for debian/ubuntu? been considering making some highly unofficial 1.1.4 debs
<tseng> schweeb: well. the build system for 1.1.4 is completely different
<tseng> which is a good and bad thing
<schweeb> that's what I gathered
<tseng> bad in that the old package probably isnt a very useful base
<schweeb> yea
<tseng> good in that the days of bootstrapping mcs are over
<schweeb> heh
<tseng> dont say mcs too loud around lamont 
<schweeb> hah, why?
<tseng> he was the sucker that got stuck building it
<schweeb> lol
<tseng> http://wiki.debian.net/?MonoDebianPlan
<schweeb> yea, they include mono-lite or something to bootstrap mcs now, don't they
<tseng> youll want to read that, to understand why the current debian mono project is in a state of flux for now
<tseng> no, its all one source package now
<lamont> is there a ghc6 package for amd64 lying around anywhere?
<schweeb> tseng: heh, well, I'll look into packaging 1.1.4, but maybe I'll just mock up some dummy packages to solve dependencies (I'm a bit lazy)
<daniels> lamont: EMM CEE ESS
<tseng> schweeb: ok. probably want to start from scratch
<lamont> daniels: remind me to steal a couple of geforce cards from you while I'm in the neighborhood.
<lamont> or stop saying that word
<schweeb> I've done lots of packages, but all of them have been single package binaries... this'll be a big leap for me hehe
<daniels> lamont: sure ... i'll buy you the drink of your choice while you're here :) i don't want 'em
<lamont> woot
<daniels> lamont: i just got the fastest card known to man (an ati card) today
<daniels> so i have no idea what i would want with pci geforces
<HrdwrBoB> daniels: we could summon chthulu
<daniels> HrdwrBoB: good plan
<tuxdisciple> pci Geforces... so many monitors...
<mjg59> lamont: Ok, I've got a machine running -23
<lamont> I have one building the first of 6 kernels. :-(
<jdub> Mithrandir: why doesn't ssl-cert depend on openssl?
<lamont> mjg59: which, depending on your sleep cycle, could mean that you could catch a nights sleep :-)
<mjg59> Ha
<mjg59> lamont: I'm leaving for Brussels in 8 hours
<mjg59> I guess I /could/ take the scratch laptop as well...
<mjg59> Actually, I'll leave it up and then test it from there
<lamont> pretty sure we'll be done before then
<lamont> any chance you have both power3 and powerpc kicking around?
<tuxdisciple> mjg59, flying? Or you live nearby?
<lamont> s/power3/power[34] 
<lamont> tuxdisciple: england, brussels, practically on top of each other
<mjg59> tuxdisciple: Train
<lamont> sere
<Clint> it's true
<lamont> see, even
* tuxdisciple nods
<Clint> every time I go to brussels I end up in england
<Clint> literally every time
<zul> i almost went to boarding school in england
<mjg59> tuxdisciple: even better, underwater train
<tuxdisciple> Didn't realize you were in england
<lamont> we need to get Clint a better train guide.
<tuxdisciple> CHUNNEL!
<AndyR> hi all
<Clint> no, those were airplanes
<mjg59> lamont: Heh. I was sort of planning on fitting sleep into that 8 hours.
<mjg59> And packing. And washing.
<lamont> mjg59: pack now.  sleep now. :-)
<mjg59> Ha
<schweeb> tseng: sounds like they like the 1.1.x series a lot better at least... more FHS friendly
<mjg59> lamont: Ok, we'll see. I have one PPC box, but can't reboot it at the moment (sorry)
<lamont> np
<mjg59> Need to convince Mark to get me a Mac, obviously...
* lamont has a power3, but it wasn't happy last he played with it.
<lamont> at least, I expect that a collored G3 is power3...
<mjg59> lamont: Mm? G3 is powerpc, not power3
<mjg59> power3 is an IBM workstation and supercomputer CPU
<mjg59> G5 is power4 because of the move to ppc64
<lamont> ah, nm then.
<mjg59> I'd be surprised if there are many people using Ubuntu with power3s...
* lamont got confused by the
<lamont> '3' in the name
<lamont> damn keyboard
<lamont> someone distract elmo - I'm gonna go bootstrap ghc6
<tuxdisciple> elmo_: Look! An elephant!
* tuxdisciple points behind elmo_ 
<aj> isn't elmo asleep?
<aj> just do it verrrry verrry quietly
<daniels> it is 0123, of course
* daniels waves his hand in front of elmo; there is no dodgy lamont hack.
<jdub> aj: haw haw re: linux-aus
<aj> jdub: ?
<aj> oh, AFUC?
<aj> i thought you were mocking my mad budgeting prowess
<AndyFitz> #linux-aus
<AndyFitz> is that a channel ?
<aj> it's also a list
<AndyFitz> hey what do ya know it is 
<AndyFitz> met an ubuntu user out skating last night. picked him easily since he was wearing a tux t-shirt
<AndyFitz> also lansmash.com  now use ubuntu for their ut2004 & quake 3 servers
<tuxdisciple> ubuntu is such a wonderfully concieved distro... I am so glad to be out of gentoo hell
<lamont> hrmpf.  ghc6 gets to wait for tomorrow, it appears
<tuxdisciple> my poor laptop is hurting compiling this kernel...
<helix> AndyFitz: skating?
<helix> skateboarding?
<AndyFitz> nah rec skating  ( rollerblading )
<helix> oh
<helix> oh well
<AndyFitz> big groups meet up on tues wed and thursdays for a 3 hour skate around brisbane at night
<helix> any skateboarders?
<tuxdisciple> I tried once.... I still feel the bruises..
<AndyFitz> yeah skateboarders around the bottom of the good will bridge most wednesdays from 5-8
<helix> heh, cool
<mjg59> There's a mad Australian conspiracy on debian-vote
<jdub> :-)
<jdub> uh huh :-)
<jdub> flumotion in action: http://70.85.31.216:8800/
<zul> australians are mad :)
<lamont> we're voting again?
<aj> lamont: of course, it's been weeks
<lamont> heh
* mjg59 finishes off his platform
<sivang> hey jdub ! I can see you 
<sivang> jdub: man, how do you get that audio quality?
<mjg59> jdub: What's that stream in?
<daniels> mjg59: theora/vorbis
<jdub> theora/vorbis
<mjg59> Ah. I wonder what I'm missing, then.
<jdub> sivang: that's via the shitty microphone too; it is better when i source it directly from the stream
<mjg59> jdub: Oh, or were you streaming the visualisation?
<jdub> no, it's just webcam/mic
<sivang> jdub: very cool :)
<mjg59> Right, in which case my totem got the audio stream and not the video stream
<jdub> so you can't see me sticking my fingers up at you
<zul> alright i have to go pay the mortgage bbl
<sivang> anyway I'm out for tonight
<sivang> night all!
<tuxdisciple> night!
<mjg59> jdub: Indeed not
<sivang> night tuxdisciple 
<lamont> night sivang 
<tuxdisciple> heh... kernel finally built... now the modules...
* tuxdisciple rubs laptop
<tuxdisciple> brb
<YokoZar> hah, I just got a spam sent to a debian bug mail address
<YokoZar> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=112555
<tseng> schweeb: yes
<Mithrandir> jdub: because it's buggy.
<lamont> daniels: is 6869 likely to be the inotify issue?
<zul> hola
<lamont> evening zul
<jdub> Mithrandir: without it installed, ssl-cert just breaks
<jdub> Mithrandir: or are there other options?
<jdub> Mithrandir: regardless, it means the package that depends on ssl-cert also needs to depend on openssl
* lamont grumbles at Kamion, makes a note to pester him tomorrow
<Mithrandir> jdub: I know; I think it's fixed in Debian
<jdub> ahar
<jdub> oh
<jdub> stupid english
<jdub> i thought you were saying "it doesn't depend on openssl because openssl is buggy" :)
<Mithrandir> jdub: just sync -11 and it should fix it.
<Mithrandir> jdub: ah, sorry.
<jdub> elmo_: ping!
<Mithrandir> jdub: http://packages.qa.debian.org/s/ssl-cert/news/1.html
<lamont> mdz/jdub: could we have a BoF on bastard-children architectures UDU?
<jdub> hell yeah
<lamont>  /usr/sbin/livecd.sh: line 65: sudo: command not found
<lamont> oops
<lamont> jdub: there are a few things that do things that are guaranteed to be broken on the poor unloved bastards, instead of generally working.
<jdub> due to our changes, or...?
<jdub> dmidecode ;)
<lamont> our changes.
<lamont> ubuntu-meta, debootstrap
<lamont> xresprobe
<lamont> console-data
<jdub> yeah
* lamont has no clue where he got that list from
<lamont> actually, daniels has the fix for xresprobe, and I think was going to just include it
<lamont> then there's the whole cluster surrounding bastard archs without oo.o available, and what that really means to ubuntu-*
<Mithrandir> lamont: I forgot to bring the ultra home last night :(  sorry.  Going to fosdem today, so it's probably not really worth bothering as fabio gets back soonish.
<lamont> Mithrandir: yeah
<lamont> Mithrandir: I should really fetch some bits and install the SS20 that I have
<jdub> Mithrandir: ooh, rock! say hello to everyone for us :)
<Mithrandir> jdub: bringing a small bunch of Ubuntu CDs too, so I can spread the love.
<lamont> my kids school is dumping windoze in favor of linux in march.  Somehow I doubt they've picked ubuntu, but the IT specialist has a copy of the CD as of today
<jdub> s/spread the love/pick up girls/
<lamont> had heard of ubuntu, too
<lamont> jdub: but no picking up love and such, ehy?
<Mithrandir> jdub: dude, I have a girlfriend already. :)
<jdub> Mithrandir: but we know the real reason why you're taking ubuntu cds to fosdem ;)
<Mithrandir> jdub: oh?
<HrdwrBoB> lol pick up girls with ubuntu CDs
<zul> Mithrandir: convert those gentoo users while you are there mmm..kay/
<Mithrandir> zul: I'm not sure I dare venture into the gentoo room.  They might recompile me or something. :)
<zul> Mithrandir: even "optomize" you?
<Mithrandir> that too
* tseng slaps some -ffast-math on Mithrandir's makefile
<Mithrandir> tseng: I was compiled long time ago, my source is buried within me and is non-free. (:
<HrdwrBoB> haha
<HrdwrBoB> actually the EULA you sign when you give samples says otherwise
<Mithrandir> HrdwrBoB: I haven't given any samples.
<HrdwrBoB> lucky you :)
<Mithrandir> jdub: somebody should implement an rsync backend for gnomevfs.
<HrdwrBoB> never a blood test?
<Mithrandir> HrdwrBoB: had those, but never signed anything.
<HrdwrBoB> ahh
<jdub> Mithrandir: what would it rsync against?
<daniels> lamont: yeah
<Mithrandir> jdub: rsync is faster than ssh copying and it means I don't lose stuff when it breaks.
<HrdwrBoB> sorry, actually the problem was after it's removed frin your body you have no logal right to it (in australia)
<jdub> Mithrandir: what would it rsync against? :)
* lamont giggles that gdb is part of desktop, but gcc isn't
<Mithrandir> jdub: whatever you tried to connect to. :)
<Mithrandir> jdub: I tend to rsync against, say golem.intern.err.no and shonap.err.no, over ssh.
<jdub> Mithrandir: and locally?
<lamont> daniels: woot
<Mithrandir> jdub: it'd probably need some way to say "resume this transfer" and "sync those trees".
<Mithrandir> but, breakfast.
<jdub> this is why i ask... it ends up being a lot more than just a gnome-vfs backend :)
* robertj adds to the list of stuff for https://www.ubuntulinux.org/wiki/GrumpyGroundhog
<Mithrandir> jdub: nautilus backend, whatever. :)  ssh copying through nautilus is currently fairly useless since it's so slow
<Mithrandir> and it causes nautilus to crash
<robertj> Mith: my experience with gnomevfs is that it is totally unusable for anything
<jdub> hrm, works ok here
<Mithrandir> jdub: it's about 1/3 to 1/5 of the speed I get with rsync or tar + ssh
<Mithrandir> haven't tried with plain sftp, since the cli sftp client suck. :)
<robertj> Mith: is there something in specific that has caused vfs handlers to break? I'm pretty sure everything is installed and that I have had similar problems with fresh installs from array
<Mithrandir> robertj: unsure, I haven't started debugging it.  It takes a bit of courage to work myself up to work on this kind of stuff. :)
<robertj> Yeah
<robertj> I don't think all the session handlers are even registered
<lamont> jdub: finally sent you mail wrt kernel-team
<lamont> doh
<jdub> haha
<robertj> does anyone know if krb5kdc can be significantly slimmed down?
<robertj> in terms of memory footprint
<jdub> yo ogra 
<zul> hey ogra bye ogra
<jdub> lamont: still around?
<jdub> yo drbyte 
<drbyte> hi jdub 
<drbyte> no, i haven't strayed away from ubuntu. i will definitely be building the UN cd using the livecd system; after i update the end user material first
<jdub> :-)
<jdub> with hoary or warty?
<drbyte> i'm still bad in the sense that i want to do ubuntu kernel work, but haven't popped ubuntu/ppc on yet. i will when i get back to melb next week
<drbyte> hoary
<jdub> you should *totally* use the hoary livecd
<drbyte> when is the release date?
* drbyte shall try to coincide it before release date
<lamont> yeah
<lamont> jdub^^
<jdub> april 6 man
<jdub> lamont: will kernel-team be an open list?
<lamont> I don't see why not...
<drbyte> hmm. i should release a beta next week. with current hoary
<drbyte> oh, there's a kernel-team list ?
<jdub> yeah, preview is march 9, same day as gnome release
<lamont> jdub: although, is there an address that just goes to all the moderators?
* drbyte is backward on reading ubuntu-devel
<jdub> lamont: yeah, want to point a few people at it
<lamont> it's already public
<lamont> intention is to use that to coordiate/plan kernel stuff
<jdub> lamont: kernel-team-owner goes to the admins
<lamont> subscription preseeded with the kernel team
<jdub> no, that's just you
<jdub> kernel-team-admin goes to the admins
<lamont> right - didn't want to make the other guys owner until they wanted it...
<jdub> i forget if there's a similar one for just the moderators
<jdub> lamont: ok, thanks
<jdub> drbyte: dude, you should sign up to the kernel-team mailing list! :)
<lamont> and kernel-team@ubuntu.com works? (depricated, of course), or doesn't?
<drbyte> ok, i shall do that now.
<jdub> kernel-team@lists.ubuntu.com
<jdub> i don't control @ubuntu.com
<jdub> that'd be an elmo_ task
<lamont> because k-t@u.c is in the baz archive name...
<jdub> aha
<lamont> of course, we could just branch it... :-)
<jdub> :-)
<drbyte> done. am on the list
<jdub> lamont: by jove i think you've got it! :)
<lamont> woo hoo... 91 hours to go on my hoary-live download that I'm supposed to send to school with my daughter tomorrow...
<lamont> hrm...
<lamont> doh - can't send that livecd to school with her - it has the inotify issue... sigh
<drbyte> lamont: do you have to manually add me? i subscribed but got no mail from the list (i.e. saying a confirmation or anthing)
<lamont> shouldn't have to....
* lamont checks before grumbling at jdub
<jdub> hey man, i didn't put the inordinately-easy-to-reproduce locking bug patch into the kernel package! :)
<lamont> jdub: shush
<lamont> drbyte: I can't see any reason it shouldn't have sent you a confirmation message
<lamont> jdub: about to upload -24 to fix that too.
<jdub> rad :)
<jdub> fix or "fix"? :)
<lamont> sledge hammer
<jdub> oh well
<jdub> rml is working on a lockless version atm
<magnon> morning, jeff
<jdub> yo magnon 
<lamont> jdub: once there's a working version, I'd love to include it
<jdub> so either we get that, or stick with dnotify
<lamont> yep
<lamont> in -24, you can add 'inotify' to the boot options, if you want to crash your machine...
<drbyte> lamont: weird. byte@bytebot.net was the address i used
* lamont uploads -24, hoping that Kamion will kick a fresh livecd collection off after they finish building and he's awake
<lamont> jdub: wanna see if you can subscribe to kernel-team in one of your lowly personas, or if it just has something against drbyte?
<lamont> jdub: and you can say 'no' and I'll do check it myself...
<drbyte> it doesn't like fedora people ;-)
<jdub> ok
<jdub> i got a confirm email
<lamont> so it's drbyte...
<drbyte> ok, i'll try again
<drbyte> with another addy this time
<drbyte> lamont: do manually unsubscribe byte@bytebot.net if it got subscribed 
<drbyte> whadya know, current address works.
<lamont> only one of you there
<drbyte> yah, byte@aeon.com.my just been added. oh well. ubuntu-devel works with the bytebot one. weird
<drbyte> lamont: just got two subscription requests for bytebot.net now :P i'll just not respond. weird weird.
<lamont> maybe something is greylisting in there somewhere?
* lamont sleeps
<YokoZar> If I uploaded my public key to sourceforge and had it sign my uploads, would that be useful for the Ubuntu trust network?
<doko> good morning, all
<d3vic3> morning 
<pitti> Morning
<doko> moin pitti
<pitti> Hi doko
<sivang> morning all
<pitti> Hi Sivan
<sivang> Hi Martin! 
<azeem> so, who will come to FOSDEM?
<mdz> morning
<pitti> Hi mdz
<abelli> pitti: ding
<pitti> abelli: dong (but phone)
<pitti> Hi dholbach 
<abelli> pitti: tu tu tu
<abelli> ...
<dholbach> hellas pitti!
<dholbach> hai everyone
<abelli> dholbach: bon jour
<dholbach> guten morgen, abelli  :-)
<abelli> pitti: could you briefly describe what you will be implementing in your kernel
<abelli> and what is already implemented... i need to study
<abelli> dholbach: at university ive been told 
<abelli> that us italian student can get a parallel french degree only by working for a brief amount of time
<abelli> in france
<abelli> can you tell me where is the trick?
<dholbach> abelli: you already worked in france? :-)
<abelli> mmm no... im still studying
<abelli> but they say, there's this agreement between france and italy..
<dholbach> maybe you should just try it
<dholbach> :-)
<abelli> and since italian universities are getting worse and worse..
<abelli> i was wondering what's going on in france..
* dholbach is from Germany and his french is really bad
<abelli> why did they sign this agreement
<dholbach> althought I'd love to live in Paris... for a while
<abelli> ...doh..
<abelli> statistically, how long german phone  calls last?
<dholbach> wow... good question
<dholbach> i guess my calls varied between 1m and 6h30m ;-)
* pitti is back
<abelli> mmm..
<pitti> abelli: Hi, how were your exams?
<abelli> dholbach: see.. pitti is much faster..
<abelli> pitti: well... 3 hours for 2 exercises..
<abelli> but i finished it all 
<pitti> abelli: right now I ported the grsecurity patch to the Ubuntu kernel and built it for all i386 and ppc arches
<pitti> abelli: cool, congrats
<abelli> pitti: thank you
<pitti> abelli: TODO: vesafb breakage, build firmware images, build and test for amd64 and other platforms
* dholbach congratulates abelli too, when will you know?
<abelli> dholbach: dunno?
<abelli> pitti: ok.
<pitti> abelli: oh, and we need restricted modules
<abelli> ..about arches.. i can provide only sparc, arm, 
<abelli> and a retrocomputing friend.. is giving me a vax.. but i dont know it can stand your work
<abelli> :)
<abelli> pitti: i was also thinking about an testing ubuntu base installs.. for open ports et similia
<abelli> what do you think
<abelli> did you receive my email?
<pitti> I?
<abelli> yes
<pitti> Hi mvo
<mvo> hi pitti 
<dholbach> hai mvo!
<jordi> hmm
<jordi> does anyone know if any of the gettext utilities lets you fill in msgstrs with whatever is in msgid?
<mvo> hey dholbach 
<jordi> mu!
<jordi> mvo: dude, more string changes
<mvo> jordi: yeah, sorry for that. small fixes, you probably only need to remove the fuzzy and you are done. but string-freeze is coming today
<jordi> mvo: yeah, I see that. Not so bad then :)
<mvo> jordi: you will get a mail today (about the freeze) :)
<jordi> too late :)
<jordi> hmm, 5 new strings
<mvo> probably strings that where forgoten before. the italian translator did a great job going over all strings and checking spelling and context
<jordi> cool
<jordi> oh great  I just finished downloading a ia64 hoary iso
<jordi> instead of i386
<mvo> heh
<dholbach> can anybody tell me, why this   >  http://people.ubuntu.com/~lamont/buildLogs/r/ruby-gnome2/0.11.0-1/ruby-gnome2_0.11.0-1_20041209-0932-amd64-successful  <   is considered to be "sucessful"?
<dholbach> just search for "error:"
<dholbach> this is the reason, why  alexandria  fails (as seen on ubuntu-users@ ) - debians ruby-gnome-0.11.0-3 doesn't do better ... unfortunately
<pitti> ogra: here?
<ogra> pitti: morning
<dholbach> hi ogra!
<ogra> hi
<pitti> ogra: I currently prepare a new hal with your patch. Anything still open or can I upload it if it works?
<ogra> you can upload it....
<Kamion> lamont: still up?
<Kamion> probably not
<Treenaks> 06:31  * lamont sleeps
<Kamion> ah yes
<dholbach> hai seb128 
<seb128> morning
<pitti> Morning seb128 
<pitti> elmo_: konversation and squid syncs, please (Ubuntu overrides ok)
<seb128> hi pitti
* seb128 slaps pitti (kword)
<seb128> ups :p
<seb128> thom: around ?
<pitti> seb128: kword? what did I do with this?
* pitti dislikes KDE and never touched it
<seb128> konversation = k* (word with a k)
<seb128> :p
<dholbach> so pitti is still pristine
<doko> elmo: ping?
* Riddell adds pitti to his list of people to convert
* dholbach already is besmirched
<pitti> seb128: ah, you mean a "K" word. I see :-)
<seb128> :)
* pitti actually likes fvwm
<seb128> rooooh
<seb128> that's not corporate :p
<seb128> (bah, if people use it perhaps I'll get less GNOME bugs :p)
<Treenaks> seb128: korporate?
<dholbach> hehe
<dholbach> Treenaks: don't upset him!
<dholbach> :-p
<pitti> seb128: that's why I use Gnome now :-)
<pitti> seb128: to bug you with something :-)
<seb128> ah ah
* pitti never found a bug in fvwm, though
<Treenaks> pitti: everyone knows fvwm is BugFree
<davyd> quick ubuntu bug dudes... kernel packages, like say sl-modem-daemon, can you make them depend on linux-image or kernel-image
<abelli> ive got problems with the wiki, who should i speak to?
<pitti> Treenaks: well, there is not much what could contain bugs :-)
<dholbach> abelli: #ubuntu-doc
<davyd> so that when I dist-upgrade, it doesn't suck in a Ubuntu kernel that, while great, is missing symbols I need (stupid Linux's fault) and break my system
<Treenaks> pitti: no new features = no new bugs, too
<davyd> please
<abelli> ..i mean.. whos the technical administrator
<Kamion> davyd: is that a kernel module?
<Kamion> sl-modem-daemon, I mean
<davyd> Kamion: it depends on a kernel module
<davyd> I thought it was a bit of a nutty dependancy myself
<Kamion> davyd: if it's not a kernel module itself, it should not depend on kernel modules or kernel packages
<Kamion> for the exact reason you cite
<davyd> ok then
<davyd> it's a new thing... I assumed there was a reason for it
<davyd> that said, I should try out the latest nVidia drivers, see if they run on my machine, then I could switch back to Ubuntu kernels
* davyd mumbles about Linux removing symbols from the STABLE KERNEL
<pitti> elmo_: a2ps sync, please
<Kamion> haha he said "stable kernel"
<Kamion> the kernel's module ABI has *never* been stable
<davyd> "Hello vague possiblility of use of closed drivers through a compilable wrapper, we don't like you, so prepare to be fucked up the arse"
<davyd> Kamion: yes, but it vaguely worked
<davyd> if you had a nice wrapper
<Kamion> the stability, if any, is in the interaction with userspace, not in the interaction with modules
<davyd> now they don't seem to care for any out of tree drivers
<davyd> hell, last time I checked, even three in-tree drivers were uncompilable due to symbols removed in 2.6.10
<thom> seb128: sup?
<seb128> thom: hey
<seb128> the pmi logic seems to be wrong somewhere
<seb128> $ /usr/sbin/pmi query foo && echo "OK"
<seb128> OK
<seb128> dunno, foo is not a known action, but it should not work :)
<seb128> s/dunno//
<thom> hrm
<thom> yes, that's probably a bug
<seb128> BTW I've hacked gdm
<seb128> I'll upload a new version now with gdmflexiserver suspend/hibernate action
<thom> rocking
<ogra> yeah
<arboretumas> seb128, ji
<seb128> ?
<mantiena> seb128, I wanna told hi ;) it seems you forgot one thing, which you promised - look at bug http://bugs.debian.org/255232
<seb128> after discussion with upstream the consensus seems to be that the current category is the right one
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=139912
<pitti> Riddell: is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1145 fixed in Hoary's kdelibs?
<mantiena> seb128, most users and developers of other archiving tools, for example ark frok kdeutils don't think so ;)
<mantiena> s/frok/from/
<seb128> right, you are "most users and developers"
<seb128> and kde is a reference
<mantiena> seb128, I'm not most users and developers
<seb128> feel free to argue in bugzilla.gnome.org
<seb128> so you have your point of view
<mantiena> seb128, ok, you will change file-roller to system tools category in ubuntu or leave Accessories ?
<seb128> I'll let it here
<Riddell> pitti: " in Konqueror in KDE 3.3.1" hoary has KDE 3.3.2
<seb128> mantiena: why ?
<pitti> Riddell: okay, can you please add it to the changelog
<pitti> Riddell: thanks
<Riddell> pitti: why?  it was never an issue in KDE 3.3.2
<pitti> Riddell: the "new upstream version" changelog should say that this version fixes this CAN
<mantiena> seb128, in Ubuntu file-roller is in Accessories, while in Debian - in System Tools, it's not good from my point of view
<pitti> Riddell: this makes it easier to track bugs
<seb128> mantiena: why ?
<pitti> Riddell: I add it to the manual override for now, but for later it is always nice to have the CANs in the changelog
<pitti> Riddell: this enables automatic health checking (see http://people.ubuntu.com/~pitti/ubuntu-cve.html
<seb128> mantiena: take debian and ubuntu, they don't even have the same top menus
<seb128> mantiena: applications/actions in debian, applications/places/system in ubuntu
<Riddell> pitti: but the problem was discovered long after 3.3.2 was released.  do I have to make a new upload just to note the CAN doesn't apply in the changelog?
<pitti> Riddell: no, no new upload
<pitti> Riddell: it's not urgent
<pitti> Riddell: just add it to the next upload
<Riddell> pitti: ok, I'll try to remember
<pitti> Riddell: now it's in my override file anyway
<pitti> Riddell: do you use arch/cvs/whatever to manage these packages?
<mantiena> seb128, both have same Applications menu and same categories (submenus) in this menu. so, you leave file-roller in one category in ubuntu and in other category in debian ?
<seb128> mantiena: I stop trolling here, you are not happy argue upstream
<ogra> seb128: if i want a icon in a .desktop file, is the current way to give it the complete path ? or is there a saner way ?
<seb128> mantiena: I'm following upstream decision in debian that's all
<seb128> mantiena: we make choice in ubuntu
<Kamion> pitti: CAN-2004-0969 was fixed in Debian groff 1.18.1.1-2
<seb128> ogra: just the icon name without an extension
<pitti> Kamion: right, I just added that to my override :-)
<Riddell> pitti: no we don't, sounds like a good idea for our KDE 3.4 packages though
<pitti> Kamion: I currently walk down the list of open issues and override/patch it
<ogra> seb128: and the icon in /usr/share/pixmaps....but its not found then....
<seb128> ogra: ?
<pitti> Riddell: having a Debian and Ubuntu branch sounds appropriate :-)
<Kamion> pitti: *nod*
<Riddell> pitti: how easy is arch to learn and setup?  or could we have a repository set up for us?
<pitti> Riddell: I have all kinds of branches for PostgreSQL, this works fine
<pitti> Riddell: baz is relatively easy, if you already know cvs
<ogra> seb128: that is how i did it since a long time, but now the icons are not shown if i dont give the path....
<Kamion> you don't need to have someone else set up your arch repository
<pitti> Riddell: setting up an archive is a matter of one command
<seb128> ogra: no way
<Kamion> unless you explicitly want a shared one; note you can merge changes among different archives
<seb128> Icon=media-player-48.png for totem.desktop
<seb128> ogra: do you have an icon for totem ?
<ogra> sure
<Riddell> Kamion: we do want one shared with all the kde ubuntu packagers
<ogra> seb128: hah, sorry....my fault....
<ogra> seb128: /usr/share/pixmaps/graveman.png , Icon=graveman48.png
<pitti> Riddell: I use a shared archive for the Debian branch of PostgreSQL, that works fine
<ogra> heh
<pitti> Riddell: as long as all participants use a group-writeable umask :-)
<Riddell> amu: fancy setting one up for us on amu.debian?
<mantiena> seb128, ok, I just wanna understand  yours oppinion
<seb128> mantiena: really, if you think the categorie is wrong the place to fix it is upstream
<seb128> mvo: here ?
<seb128> mvo: just curious, how have you fixed the fullscreen issue ?
<mvo> seb128: I already have {save,restore}State and I just added a "gdk_window_get_state()" and a (possible) "gtk_window_maximize()"
<seb128> k, so that was an app bug, not a metacity issue that you have workarounded ?
<mvo> yes
<seb128> nice, thanks
<mvo> np :)
<sivang> rehi all
<dholbach> hi sivan!
<amu> Riddell: baz or svn ? ;) 
<sivang> hi daniel, what's up?
<Riddell> amu: I don't mind, whichever is easiest for you
<amu> Riddell: svn would be my choose *ducks*
<abelli> amu: ciao
<pitti> amu: baz!
<pitti> amu: baz is lovely, especially if it comes to branching around a lot
<pitti> amu: which you will likely do if you have ubuntu and Debian branches
<pitti> amu: each of them for several releases
<haggai> amu: svn doesn't do distributed development as well as baz
<amu> abelli: *waves*
<amu> okok :) than it will baz 
<rburton> mvo: g-a-i with your patch didn't work properly, when synaptic finished it wasn't terminated correctly
<mvo> rburton: oh, bad. I can have a look later
<amu> Riddell: haggai: sounds good for me, i'll setup it local and distribute it also over p.u.c
<pitti> amu: usually we shall keep our at-work archives on chinstrap:/home/warthogs/archives
<pitti> amu: I have a mirror on people which is updated every hour
<pitti> amu: that's what most other people do
<Kamion> or you can mirror on commit
<pitti> Kamion: how do you do this?
<Kamion> though that doesn't work so well for shared archives
<Kamion> pitti: ~/.arch-params/hook
<pitti> Kamion: I know commit mirrors
<pitti> Kamion: you ssh to rookery on every commit?
<Kamion> sure
<pitti> Kamion: that requires the ssh password
<pitti> Kamion: okay, that would work
<Kamion> no it doesn't :)
<Kamion> ssh-agent
<pitti> Kamion: ah :-)
<pitti> Kamion: hmm, still, Riddel cannot do this
* haggai neither
<Kamion> I find it easier to do it on every commit (so that it can use the ssh-agent in my session) than to try to figure out how to securely mirror to chinstrap/rookery from a cron job
<Kamion> true
<pitti> Kamion: maybe we should setup an alioth analogon for Ubuntu
<pitti> Kamion: where everybody interested can get an account
<pitti> at least all MOTUs
<T-Bone> hey Kamion, pitti !
<pitti> Hi T-Bone, how are you
<pitti> Kamion: TB issue?
<T-Bone> fine and hungry :)
<amu> pitti: that's the reason why i'll setup it also on my localnet 
* Kamion feels rookery should be that machine, but I don't know what elmo thinks
<pitti> amu: well, other people can branch off people.u.c :-)
<thom> pitti: um, a PQM somewhere would obviate the need for logins, really
<haggai> there was talk of webdav access, is that enough for baz?
<pitti> Kamion: hmm, rookery should not be accessible to the world...
<pitti> thom: what's PQM?
<Kamion> patch queue manager
<pitti> sounds interesting
<pitti> anyway, TB topic?
<pitti> or even CC?
<Kamion> seems like an admin issue *shrug*
<thom> jdub/mdz: PLEASE can i break UVF for firefox 1.0.1?
<pitti> jdub, mdz: seconded 
<thom> (more security fixes than you can shake a *very* big stick at)
<ogra> pitti ?
<pitti> ogra: ?
<ogra> ftbfs ?
<ogra> hal that is
* pitti looks
<abelli> ogra sup you
<ogra> i dont see uudecode anywhere
<Kamion> build-dep on sharutils
<abelli> pitti: can i try applying linux console project patches to your kernel?
<pitti> Kamion: it already does
<pitti> abelli: sure
<abelli> pitti: ok thank you
<ogra> Kamion: i did....it works here for me...pitti had a prob on his test machine and changed the patch ....
<pitti> ogra: make[4] : *** No rule to make target `hal-cpu.png', needed by `all-am'.  Stop.
<pitti> ogra: that's the same as I encountered on my box
* pitti kicks cdbs
<pitti> Kamion: this error occured on my box with ogra's patch, so I changed it to work for me
<ogra> Kamion: configure/hal-device-manager:: , uudecode -o build-tree/$(DEB_TAR_SRCDIR)/tools/device-manager/hal-cpu.png < debian/hal-cpu.png.uuencode
<ogra> Kamion, works for me....
<pitti> ogra: I changed this to configure/hal::, that worked for me
<ogra> Kamion, pitti had to change it
* pitti reads cdbs sources
<ogra> to make it work for him....
<ogra> pitti: arch issue ? amd64 here
<pitti> ogra: no, more like a race or a different building on buildds
<dholbach> hmmm, it worked for me with gparted on all archs
<ogra> ogra@honk:~/halstuff/hal-0.4.7 $ dpkg -l |grep cdbs
<ogra> ii  cdbs           0.4.26-1       common build system for Debian packages
<ogra> pitti: same version ?
<pitti> ogra: what about using post-patches:: 
<pitti> ?
<ogra> hmm
<ogra> but it works fine here....also just tried it on my i386 .....
<dholbach> what about uudecoding it to   .../tmp/usr/share/pixmaps/   ?
<ogra> nah
<dholbach> don't know if this is considered to be bad style
<pitti> ogra: post-patches:: works for me
<pitti> ogra: for you too?
<ogra> me neither, but i want to know why  configure/hal-device-manager:: isnt read ....
<pitti> ogra: it makes more sense, too
<pitti> ogra: it's probably read later
<ogra> pitti: just exchange hal-device-manager ?
<ogra> ::
<pitti> ogra: the buildds might build the arch-any targets first, then arch-all
<pitti> ogra: while you do it the other way round
<pitti> ogra: s!configure/hal::!post-patches::!
<ogra> ah, thanks
<ogra> pitti: works :)
<pitti> ogra: for me too, I upload
<ogra> great, thanks :)
<elmo> pitti: konversation is up-to-date; and mdz only just sent the approval mail for squid
<thom> elmo: does powermanagement-interface need poking to move to main? i seeded it a while ago...
<pitti> elmo: oh, sorry. konversation was still listed as old in my CAN overview; thanks
<elmo> thom: seeds are FUBAR due to kde-in-main
<thom> oh, right
<elmo> the problem with konvesation is we are newer than sid
<elmo> [Nothing to update (Modified)]  konversation_0.15.1-0ubuntu1 (vs 0.15-3)
<thom> it would be KDE's fault
<pitti> elmo: argh, yes
<pitti> elmo: okay, I override the CANs manually
<maswan> elmo: btw, just as a proof that the ftp cluster here can take more traffic: http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
* maswan needed a quick mirror of a known dataset for some stresstesting at work, turned out to be a nice stresstest for the ftp server too. :)
<elmo> maswan: nice
<T-Bone> maswan: impressive indeed :)
* Kamion wonders at what point debconf is going to turn round and go "no, the way you're trying to use me is too weird. go away."
<Kamion> I think I almost have kickseed able to pull stuff like CD-ROM detection and network configuration back a few steps to run before the language question now
<Kamion> which will get rid of the separate file-kickseed and network-kickseed packages
<torkel> maswan: does that mean I have to get the other servers up and running too? :-)
<maswan> torkel: Well, it would be a fun cluster to build an ftp server from. :)
<torkel> maswan: hehe
<pitti> ogra: new hal built successfully
* sivang senses the backend part of hwdb is getting close :)
<ogra> pitti: yay, just saw it....
* sivang yays for ogra 
<ogra> argh
<ogra> <ogra> photoguy151: did you do some chown command to change any rights of system files like /etc/sudoers ?
<ogra> <photoguy151> "chown -R mike /"
<ogra> AAAARRRGH !!!!
<sivang> bah
<Treenaks> ogra: *shudder*
<dredg> ogra: yes... big stick, car park?
<sivang> ogra: does it boot?
<ogra> .... #ubuntu is a bit orphanded with all people working on their projects...
<ogra> sivang: the guy just asked why sudo always complains about uid 1000.....
<sivang> ogra: ouch
<ogra> yup
* ogra makes a note to do more #ubuntu work after the release
* HiddenWolf thinks that ogra should make ubuntu great first. :)
<ogra> thats why i said after_ ;)
<HiddenWolf> ogra: there is always the next release to make great. :)
* Mithrandir waves from Brussels
<sivang> hey Mithrandir !
<ogra> Mithrandir: yay, already
<Mithrandir> hiya Sivan
<thom> Mithrandir: have fun, git
<HiddenWolf> Muscles from Brussels, eeks
<Mithrandir> thom: I will. :)  Free wireless and everything here. :)
<ogra> woot....
<Mithrandir> (In the hotel)
<ogra> hm :(
<Mithrandir> ogra: you're already in Brussels?
<ogra> nope....i live 100km away from the belgian border.....i'll drive from here and only come for one day (have to finish hwdb-client)
<Mithrandir> oh, ok.
<Mithrandir> what day?
<HiddenWolf> ogra: where do you live? 
<ogra> Mithrandir,  i thought sunday, but will study the schedule a bit more ....
<Mithrandir> ok
<ogra> HiddenWolf: germany/eifel....
<Treenaks> ogra: you'll be there sat or sun?
<elmo> Kamion: ?
<HiddenWolf> ogra: key
<elmo> Kamion: is grub-install known to be broken in recent-ish install in 'server' mode?
<Treenaks> Mithrandir: I'll arrive around ten-ish tomorrow morning on Bruxelles Midi train station
<ogra> Treenaks:  as i said above....sun is more likely.....but i will study the schedule again.....
<Treenaks> ogra: cool, OK
<Mithrandir> Treenaks: ok, I guess I'll see you at FOSDEM proper, then
<ogra> no maddog this year ..... his keynotes are sooo cool
<Treenaks> Mithrandir: I have to leave at 5am because there's maintenance at schiphol airport train station :(
<Kamion> elmo: no, not that I know of. How so?
<Mithrandir> Treenaks: did the same this morning.  Got up at four.
<HiddenWolf> Treenaks: you're going to brussels, get on the train, oaf. :-P
<ogra> Treenaks: nobody to give you a lift with a car ?
<Treenaks> ogra: not close enough, and I'm not comfortable driving myself in Belgium..
* ogra assumes there are more .nl people coming
* HiddenWolf thinks a team should be formed to promote ubuntu / do ubuntu newsletter etc
<Riddell> Treenaks: if you make it to utrecht in the next couple of hours we can take you :)
<ogra> HiddenWolf: talk to mako
<Treenaks> ogra: 2 or 3 ubuntu-nl people from .nl, 3-4 ubuntu-nl people from .be :)
<ogra> heh
<Treenaks> Riddell: well, I'd have to pack etc...
* thom hugs seb!
<HiddenWolf> I'd love to have a look, but I've got exams coming up.
<Riddell> maybe I should put on my kilt so people will recognise me, that way I don't have to go hunting people
<thom> seb128 is my hero for the day
<elmo> doko: ?
<ogra> Riddell: yes, pleas do :)
<seb128> thom: works fine ? :)
<thom> yeah
<Simira> Riddell: yay, kilt is the best garment ever!
<jdub> thom: ff 1.0.1?
<thom> jdub: yes
<Treenaks> Simira: what's it with women and guys wearing skirts? :P
<jdub> thom: is it going to involve scary breakage, or amazing unbackportable fixage? :)
<thom> jdub: security and other crashes fixed
<HiddenWolf> Treenaks: It's called gay pride :)
<Simira> hm... is  kilt correct gala outfit?
<thom> the latter
<Simira> Treenaks: I didn't mention anything about guys. I love wearing kilt myself ;p
<thom> jdub: it is basically what we have in ff1.0, plus a much more features, minus pango
<thom> uh, s/features/fixes
<jdub> thom: bonus :)
<elmo> giggle
<thom> and s/much/bunch
<Treenaks> Simira: no, I mean.. it's my observation that women tend to like guys that wear skirts/kilts
<HiddenWolf> thom: is anything being done about FF behaving like a memory leak?
<thom> trying to type on two keyboards at once considered harmful
<thom> HiddenWolf: no, patches accepted
* Riddell glares at Treenaks for using the s word next to kilt
<ogra> hehe
<Treenaks> Riddell: s./.||. then
<HiddenWolf> thom: learn me to program, and I will :)
<Simira> Treenaks: I like Tollef, with or withour skirt.
<Simira> without, even
<Mithrandir> Simira: kilt is not correct gala, no.  Unless perhaps if you're scottish.
<thom> jdub: soooo? http://www.squarefree.com/burningedge/releases/1.0.1.html
<Treenaks> thom: sounds like an act of god
<Simira> Mithrandir: well, my conclusion is I have to sew a gala dress this weekend, then.
<Mithrandir> Simira: oh, why not the black one?
<jdub> thom: any idea of the size of diff between them?
<Simira> Mithrandir: it's not proper
<Mithrandir> Simira: oh, why not?
<Simira> Mithrandir: I'm tired of it, my corset doesn't look well with it, and then I have to buy some black gloves as well
<jdub> thom: anyway, if you're comfortable enough with it to demand the upgrade for your own sanity, then i approve :)
<Mithrandir> Simira: whatever makes you happy, my love.
<jdub> thom: if, however, it makes you cry later on... no sympathy whatsoever ;-)
<elmo> thom: you're just trying to outdo jdub in the hoary breakage stakes aren't you?
<Simira> Mithrandir: you know what would ;)
<elmo> it won't work, he's got too big a lead on you! :-P
<jdub> yeah man
<jdub> i own the b0rk
<thom> heh
<thom> jdub: firefox makes me cry anyway
<thom> but i suspect the size of the diff is probably smaller than the current debian diff
<seb128> jdub: hey
<jdub> pants off seb128 
<seb128> jdub: is that of to update gaim ? 1.1.3 is in debian an fix 2 security issues 
<seb128> s/of/ok/
<jdub> seb128: so tonight i had to explain how ubuntu has all the latest gnome developer stuff in it
<jdub> seb128: yes, approved
<seb128> nice, thanks
<seb128> jdub: how, where did you explain that ? I'm curious to know how too :p
<sivang> jdub: did you tell them about seb "chainsaw" bacher? ;-)
<jdub> seb128: so i said that we had a team of french developers working for us, and strangely enough, all of them are called sebastien
<thom> jdub: 410 files changed, 5215 insertions(+), 3053 deletions(-)
<sivang> ROTFL
<jdub> seb128: so then the person asked how many sebastiens there were
<jdub> seb128: and i thought for a moment
<jdub> seb128: and said, "well, i generally only talk to the 128th sebastien, so i guess there's at least 128"
<sivang> hehehe
<mvo> haha
<sivang> jdub: where was it? lugradio or some other media?
<jdub> sivang: no, at my local lug meeting
<jdub> i'm sorely tempted to use that explanation elsewhere though
<mvo> go seb128 go :)
<thom> jdub: as against 65 files changed, 6434 insertions(+), 181 deletions(-) for the current debian patch (and a lot of the upstream are changing 1.0 to 1.0.1
<pitti> jdub: for ((i=0; i <= 128; ++i)) seb.fork();
<sivang> jdub: ah
<seb128> jdub: ah ah :)
<jdub> thom: cool
<sjoerd> pitti: that makes 129 sebs then :)
<pitti> sjoerd: right, that's why jdub talked about "at least" 128 :-)
<jdub> sebzero sounds dangerous, too :-)
<d3vic3> heh
<opi> sebzero, a temperature that makes your deb frozen?
<jdub> jdubtv! -> http://70.85.31.216:8800/
<Kamion> smurfix: hm, I have a suspicion that this kbd-chooser change of yours broke preseeding:
<Kamion>   * Killed translated_keyboard_get() -- cdebconf already does the
<Kamion>     translating for us.
<smurfix> What broke?
<doko_> elmo: pong
<Simira> jdub: got yourself a webcam or something?
<dholbach> hello jdub *wave*
<sjoerd> jdub: this is live with fluendo stuff right ?
<jdub> got myself a linode flumotion worker!
<jdub> sjoerd: yes
<Kamion> smurfix: was that a necessary change for some other reason, or can it be restored? when preseeding, you do things like setting console-keymaps-at/keymap to 'uk'
<dholbach> smile into the camera please :-)
<elmo> doko: what did you want synced again?
* Simira can't see jdub
<Kamion> i.e. to the untranslated name
<jordi> hola jdub :)
<dholbach> YES! :-)
<sjoerd> jdub: nope that wasn't right
<jdub> shyoard?
<doko_> elmo: libcairo
<sivang> jdub: your stream still on?
<jdub> back on now
<dholbach> seb128: now you say "pants off" to jdub!
<jdub> i did over a gig of traffic in two hours earlier
<sivang> jdub: could you toss the ip adress again?
<jdub> jdubtv! -> http://70.85.31.216:8800/
<sivang> jdub: tnx
<tseng> hm jdub is bearded
<Kamion> beardub
<jdub> Kamion: sorry, did you say baredub?
<Kamion> nonononono
<Simira> jdub: yay! I also got my new webcam today. Wanna have cybersex? Uhm...
<sivang> hehehe
<jdub> :-)
<Treenaks> jdub: whoa! it has sound!
<jdub> Simira: A/S/L?!!??!?!!
<Kamion> get a room :)
<jdub> probably entirely out of sync
<Mithrandir> jdub: Simira is mine! :P
<smurfix> Kamion: That function (the ask-for-translated-strings part, anyway) was basically a no-op, so I can't see offhand how it would have hurt.
<Treenaks> jdub: now all you need is sync :)
<Simira> jdub: old enough, yes please, at my webcam?
<jdub> oh man, now we're up to 10 clients
* sivang thinks he saw the word cybersex here. wonders what that means in ubuntu crowde
<Kamion> smurfix: the point is that I don't think cdebconf does do the translation for you if you've preseeded the answer
<Mithrandir> Simira: have you played with the IR part of it?
<Simira> sivang: it's the depht of UbuntuLove
<Treenaks> jdub: great framerate though
<HiddenWolf> sivang: just people getting exited without girlfriends, but looking at sexy code. 
<Kamion> smurfix: but ICBW I guess, I'll try stuff out
<Simira> Mithrandir: ok, I haven't even opened it yet
<Kamion> smurfix: I do know that something broke though :)
<jdub> Treenaks: yeah, and the quality doesn't suck to hard at this bitrate
<jdub> 'too'
<smurfix> Kamion: non-keyboard-related preseeds still work?
<Kamion> smurfix: yeah
* smurfix grumbles
<Simira> jdub: but I do have trouble connecting you
<Treenaks> mplayer works fine here on SUSE
<Kamion> smurfix: I'm trying to make kickstarting off cdrom work better at the moment, so I hit it fairly quickly :)
<dholbach> Treenaks: totem does too
<dredg> oh man. jdub's a camgirl
<Treenaks> dholbach: not on my thoroughly ubuntized suse ;)
<dholbach> Treenaks: you make me cry
<Treenaks> dholbach: my employer made me do it!
<dholbach> Treenaks: hmm
<Treenaks> jdub: AAAGH
<Treenaks> jdub: don't do that!
<jdub> :)
<smurfix> Kamion: Which values are you preseeding?
* smurfix 'd like to examine that here
<dholbach> and i always told people, i didnt have a TV
<Kamion> smurfix: 'd-i console-keymaps-at/keymap select uk'
<Kamion> smurfix: booting with console-keymaps-at/keymap=uk is probably the easiest way to reproduce it at the moment
<Kamion> since preseeding stuff that early is awkward
<smurfix> Kamion: ah. I'll have a look ASAP.
<Kamion> smurfix: (assuming an AT keyboard, anyway)
<jordi> Mithrandir: what temperatures can I expect in Telemark at the end of March?
<jordi> Mithrandir: I keep thinking about that.
<Kamion> smurfix: hm, crap, that doesn't entirely work, investigating
<sivang> jdub: did you just wave?
<doko> pitti: ping
<Mithrandir> jordi: hmm.. Where in Telemark?  Telemark goes from the sea up to at least 1000 m.a.s.
<Simira> jordi: going to TG? You could expect anything from -10 to +15 celsius
<jordi> Mithrandir: hmm. let me see.
<Kamion> smurfix: ok, boot with DEBCONF_PRIORITY=critical console-keymaps-at/keymap=uk
<Mithrandir> Simira: TG is _not_ in Telemark. :)
<pitti> doko: bong
* Simira unpacks her new PSU
<Kamion> the first screen you see should be a failure from kbd-chooser
<Simira> Mithrandir: true, I forgot
<jordi> Rjukan
<Simira> Mithrandir: I SHOULD know
<jordi> or something like this.
<Simira> Rjukan is cold
<jordi> oh dear dear dear
<Mithrandir> jordi: I'm not sure if you'll see the sun.  It'll probably be in the range from -25 to 0, I'd guess.
<Mithrandir> probably around -10-ish
<jordi> Mithrandir: omfg
<jdub> jane is watching now too :-)
<jdub> on her laptop which is running hoary :-)
<Simira> jordi: if you're lucky, we're having an early spring, and getting close to 0. ;)
<thom> ah, she found a use for it then? ;-)
<jordi> jdub: jane runs ubuntu now?
<jordi> cool :)
* sivang is also on a laptop, running hoary and watching jdub in mozilla-mplayer
<Kamion> jordi: she dual-boots
<jordi> nod
<jdub> jordi: totally dude
<Mithrandir> jordi: -2 and sunny now, actually.
<Treenaks> jdub: you should set up a credit-card payment portal thing to get to jdub-tv
<jordi> Simira: ok, I'm going to miss my toes
<elmo> Kamion: hmm, I can definitely reproduce this problem on both i386 and amd64 with 2005-02-23 image, only in 'server'.
<Mithrandir> jordi: pft, wear socks.
<Simira> jordi: tihi. What are you doing there? Easter holidays?
<jdub> Treenaks: dude, earlier today, i couldn't even get 20 people to watch it
<sivang> say people, isn't right that jdub looks like an austrelian pirate ? :)
* mvo likes jdub tv
<Kamion> elmo: anything interesting in syslog?
<Treenaks> jdub: if you had asked their credit card numbers, you could now run out & buy new servers to support your growth
* sivang LIKES jdub tv
<elmo> Kamion: well, a) I get apt-cdrom garbage  on the primary console just before the "Use internet repositories" question, b) in syslog it's whining about not being able to find grub on /cdrom
<elmo> Kamion: it's hard to test tho, 'cos I'm doing it on a machine with .5TB and the partitioner is dog slow for that
<Treenaks> sivang: #jdub-tv is empty :(
<Kamion> elmo: think it might be easier if you could get /var/log/syslog somewhere I can see 
<elmo> I'm going to rip all but one of the drives out and get you some details, I just wanted to make sure it wasn't a known problem
<sivang> jdub: you should set this up for other ubutnu people, so we'd have Kamion|tv , elmo|tv , sabdfl|tv would be awesome :)
<Kamion> elmo: I'm running through a test install on amd64 now
<Kamion> you do not want Kamion|tv </jedi-mind-trick>
<sivang> jdub: what's the open machine over there at the back? 
<sivang> jdub: (has a kbd on it(
<jdub> sivang: dude, kamion has red hair in places you don't want to see.
<jdub> that's my fileserver
<ogra> hehe
<jdub> with no lid on it
<sivang> jdub: ROTFL
<jdub> it's actually the nfs server for /home on my desktop too :)
<elmo> boggle
<Treenaks> jdub: how about Canonical Radio then?
<Kamion> and how jdub knows that exactly, I'm not going to ask
<sivang> jdub: cool
<sivang> Kamion: hehe
<elmo> I rip out all the drives, so it only has one 72Gb drive, and the RAID card still presents a "212GB" array to Linux
<sivang> Kamion: you seem close :)
<tseng> jdub looked at me!
* tseng swoons
<Kamion> tseng: it's like the Mona Lisa, only much beardier
<jordi> simira, yes
* thom throws peanuts at jdub
<rburton> ewwww
<sivang> hehe
<lamont> dholbach: it's "successful" because dpkg-buildpackage didn't fail
<Kamion> lamont: re your wondering last night if I could kick off live builds, elmo told me that those buildds would be down for a while
<jdub> Treenaks: so a few people have asked if i'm going to do a tv show
<jdub> Treenaks: and it's getting tempting
<sivang> robtaylor_: are you also watching jdub|tv ? it's cool :)
<Kamion> elmo: the apt-cdrom garbage I know about, will fix
<lamont> Kamion: well, unless he has them down today, the livecd buildd's were all up last night when I said that.... :-)
<sivang> jdub: seriously?
<lamont> but I know that the ia64 boxen are on his list for today
<Kamion> lamont: hm, ok; I assume you can do it now though :)
<lamont> true enough
* smurfix needs a new power supply :-/
<ogra> jdub: GO GO GO !!
<mvo> Kamion: what kind of garbage is it?
<Kamion> whoa, though, that's way more apt-cdrom garbage then there used to be
<ogra> jdub: but get some more sleep before ;)
<Kamion> mvo: it's just apt-cdrom's normal output, apt-setup isn't redirecting it properly
<mvo> all right
* sivang is a bit disturbed that since he started watching jdub|tv laptop fan _doesn't_ stop . hrm
<rburton> jdub|tv?
<ogra> sivang: stick something thugh the slits...a needle or so....then it stops ;)
<Kamion> elmo: hmm. ok. I see it too. trying to figure out what on earth to do about it now; I think it's fallout from my changes for #6390.
<jdub> rburton: jdubtv! -> http://70.85.31.216:8800/
<ogra> s/thugh/through
<rburton> oh god
* sivang has to drop net connection, going to miss the "Tonight show with jdub" :-(
<ogra> hehe
<sivang> ogra: lol
* sivang --> away
<Treenaks> sivang: I think it's more "Breakfast Bits with jdub" for him :)
<rburton> oh dear god
<sivang> rburton: join the fun :)
<Kamion> elmo: or maybe not. anyway, the issue is that base-installer leaves /cdrom bind-mounted for the benefit of later udebs trying to apt-install stuff, but the process of running apt-setup - and hence apt-cdrom - in the first stage unmounts it
<rburton> am i the only person who talks to himself continually when working alone then?
<Treenaks> rburton: no
<Kamion> I could possibly use apt-cdrom --no-mount if /cdrom is already mounted
<Kamion> oh, hey, it does use --no-mount, but apt-setup EXPLICITLY UNMOUNTS /cdrom. fuckeurs.
<elmo> Kamion: why's it only doing it in 'server' tho?
<rburton> hey jdub!
<lamont> elmo: just kicked livecd rootfs builds on all 4 arch
* rburton thinks jdub is slowly looking like a dodgy gangster
<T-Bone> hey lamont!
<elmo> lamont: ok
<lamont> so 45 min or so for adare and weddell, if you'd be so kind
<Kamion> elmo: because server mode doesn't use archive-copier, and archive-copier plays all sorts of games with /cdrom
<elmo> ahic
<lamont> morning T-Bone 
<Kamion> including running apt-cdrom itself
<T-Bone> lamont: i'll give a shot at ia64 OOo in a fwe hours...
<lamont> woot
<zul> hey
<T-Bone> lamont: and hope this will make ia64 look a bit better :P
<robtaylor_> sivang: i'm starting to find jdub TV slightlu disturbing for some reason =)
<rburton> the noise of jdub typing is strangely hypnotic
<robtaylor_> rburton: i think i'm glad i dont have sound here =)
<rburton> jdub: i presume this is flumotion
<tseng> robtaylor_: he does little skits every so often
<jdub> rburton: totally
<tseng> robtaylor_: youre missing the fun.
<robtaylor_> tseng: ah, dammit =)
<zul> flumotion?
<rburton> jdub: oddly your stream is better than the fluendo one, despite travelling far further
<HiddenWolf> rburton: do i sense love in the air?
<rburton> haha
<robtaylor_> *jdub i love you, jdub i doooo* 
<robtaylor_> heh
<ogra> jdub: usic, what is that ?
* robtaylor_ stops being distracted and go does some work =)
<jdub> amelie soundtrack
<jdub> rburton: it's in the USA :-)
<ogra> s/usic/nice misic
<ogra> ah
<rburton> jdub: ah, that's not too bad
<thom> jdub: linode abuse?
<jdub> thom: linode is *rad*
<tseng> do they have an ubuntu image yet?
<jdub> only, i have found that udev doesn't even install on 2.4 systems now
<jdub> tseng: yes, for a couple of weeks now
<tseng> rad.
<jdub> tseng: talking to caker about promotion stuff :-)
<jdub> tseng: (see sounder, btw)
<tseng> caker is the man
<tseng> (made of cake)
<trulux> hi
<trulux> pitti: ping
<pitti> Hi trulux
<trulux> pitti: howya!?
<pitti> trulux: good'n'you? :-)
<trulux> pitti: great, busy but fine
<trulux> :)
<trulux> pitti: we have done the libssp
<trulux> pitti: toolchain ready
<pitti> new version?
<pitti> ah
<trulux> yeah
<trulux> the definitive one
<ogra> jdub ?
<trulux> pitti: kernel based support for entropy gathering, I'm going to submit a patch for kernel mainline inclusion
<ogra> jdub: missed your pills today ?
<trulux> so
<trulux> users relying in chrooted ubuntu installations wouldn't have trouble for getting /dev/urandom entropy
<trulux> a new syscall is made available
<trulux> http://pearls.tuxedo-es.org/patches/propolice-2.6.11-rc2.patch
<trulux> the stack_smash_handler needs fixing, the other one *works neatly*
<trulux> pitti: lemme cvs the latest libssp code
<trulux> pitti: then I will try to upload a new package
<trulux> pitti: is that possible ?
<pitti> trulux: if you mean that you need a new libssp package, that's fine
<pitti> trulux: libssp 0.2 is already in Debian experimental
<trulux> ok
<pitti> trulux: I did not yet upload it to Ubuntu since we can quickly sync it if we actually need it
<trulux> ok
<trulux> pitti: we are at 1.2.0 and 1.3.0 now
<trulux> some asm magic needed for some things
<pitti> trulux: do you have updated gcc packages ready? which could be included into Hoary universe?
<pitti> trulux: i. e. gcc-ssp
<elmo> T-Bone: ?
<T-Bone> elmo: hi!
<elmo> T-Bone: have you netbooted ia64 before?
<trulux> pitti: I've talked it and we thought it was better to have gcc-hardened
<trulux> pitti: for later improvement in userland gcc profiling
<trulux> using porfiles and such
<T-Bone> elmo: no. That's an issue i've been trying to avoid banging my head on :)
<trulux> pitti: this weekend it will be done
* pitti curses heavily at cvs
<pitti> trulux: cool
<pitti> trulux: however, we already agreed to -ssp ...
<T-Bone> elmo: i have a rough idea of what it takes to do it tho
<elmo> T-Bone: well I know how to netboot, it's just not working on ia64 ;)
<elmo> in.tftpd[24476] : tftp: client does not accept options
<elmo> I just get that in syslog
* rburton stops jdub|tv to watch A Scanner Darkly trailer
<Kamion> elmo: I think that's normal, I saw that on a successful i386 netboot
<T-Bone> elmo: arg :P
<T-Bone> ah!
<trulux> pitti: yeah, but the problem is that both PIE and SSP will be used in a near future depending on which profile the user wants, much like Gentoo does
<elmo> Kamion: hmm, ok, well then I must be doing something else wrong
<Kamion> elmo: I've got a fix for the server grub install issue; need to check how it interacts with archive-copier though
<trulux> pitti: it will  help us when maintaining it
<elmo> Kamion: cool
<trulux> pitti: so, no more headaches with wrappers or such
<pitti> hm, ok
<trulux> a global wrapper
<trulux> profiled
<Kamion> elmo: also got rid of the apt-cdrom spew at the same time, as a welcome side-effect
<trulux> ssp? then gcc-hardened
<elmo> Kamion: btw, I dunno if it's related, but when I forcibly (re)mounted /cdrom in the chroot, and continued the install, 'server' still tried to install all the normal desktop stuff
<trulux> pie? then gcc-hardened / gcc with -fPIE/-fpie
<trulux> etc
<trulux> pitti: going also to improve selinux support
<trulux> pitti: this weekend I will finish a meta package for selinux support installation
<trulux> pitti: ok?
<pitti> trulux: fine :-)
<trulux> pitti: just finished the exams week, two remaining, but those are easy
<trulux> :)
<T-Bone> elmo: you're installing on a Fusion-featured box, right?
<Kamion> elmo: didn't do that for me just now, I guess that was a side-effect although I can't think how exactly
<Kamion> elmo: what arch?
<Kamion> oh, you said i386/amd64
<elmo> Kamion: yeah
<elmo> T-Bone: yeah, rx1600
<T-Bone> elmo: cool, hadn't time to try it on my zx6000, glad to hear successful report :)
<smurfix> Gaah. One powersupplyectomy later.
* T-Bone is just finishing test install on zx2000 with today's CD.
<T-Bone> Kamion: all went fine except i've been asked for the X resolution (ugly 60Hz :P), and i've been prompted twice for unauthenticated packages installation
<T-Bone> i also seen some openoffice errors (how surprising), but it didn't prevent X from starting, afaict
<Kamion> T-Bone: the unauthenticated stuff is bug #6865; mvo's working on it
<elmo> in.tftpd[26339] : RRQ from 82.211.81.240 filename /elilo.efi
<elmo> PXE-E18: Timeout.  Server did not respond.
<elmo> Load of Netboot failed: Not Found
<elmo> meh
<Kamion> elmo: have you told that tftpd to consider /tftpboot or whatever the root directory?
<T-Bone> Kamion: ok. Will have to run in ~15', then I'll squash the ooffice stuff
<elmo> Kamion: yes, I've used this tftpd setup for i386/amd64 successfully
<elmo> and had it break with apple, but we knew about that problem already
* T-Bone notices he never tried to netboot any of his macs
<ogra> jdub: hi pipka
<Kamion> the default i386/amd64 pxe configuration looks at /tftpboot/pxelinux.0, I thought, so it doesn't need to have the root directory set
<T-Bone> elmo: there's no such trick with ia64 as those we have on mips WRT netbooting ? (port range, packet size and all the like...)
<Kamion> (as in I tried using -s with tftpd-hpa and it broke, but I think other arches need -s)
<Kamion> but hm, you're getting server did not respond, not no such file, I guess
<elmo> Kamion: oh, well, okay, what I'm actually doing is, using /var/lib/tftproot - the default inetd.conf entrie uses '-s /var/lib/tftproot' and I unpacked the netboot.tar.gz into there
<Kamion> elmo: ah, ok
<T-Bone> Kamion: very ouch indeed: the ooffice shit actually prevents any further package installation with apt-get install :P
<Kamion> T-Bone: some more details than "ooffice shit" would be nice ;) the current CD infrastructure is meant to work around that problem, and if it doesn't manage to then I'd like to know why
<T-Bone> Kamion: sure. lemme mail you a dump
<Kamion> ok, thanks
<Kamion> /var/log/base-config.log would be useful
<lamont> Kamion: livecd rootfs built on all 3 places it's expected to work.
<T-Bone> Kamion: sent
<lamont> T-Bone: the other piece of ia64 pain right now (that's breaking livecd images, etc) is libbonobo's FTBFS
<T-Bone> errr...
<lamont> FTBFS in debian as well, if that helps aswage the pain.
<T-Bone> heh
<T-Bone> lamont: it drastically decreases the investigation priority :)
<elmo> meh, tftpd-hpa is sending the file, it just breaks at some point
<elmo> sends 120, acked 120, sends 121 ... acked 120, acked 120, acked 120 etc.
* T-Bone bbiab
<doko> elmo: sorry. forgot to ask for sync of libpixman. library is in main, no used dependencies in main (libcairo is the only one). libcairo depends on a newer version.
<dholbach> bbl
<sabdfl> hey happy campers, is fglrx testable at this point?
<jdub> sabdfl: in totem, jdubtv! -> http://70.85.31.216:8800/
<Mithrandir> sabdfl: ought to be
<jdub> http://people.ubuntu.com/~jdub/screenshots/flumotion-admin-20050226.png
<jdub> ^ and that's how much the streamer's being hammered
<Treenaks> jdub: only 1.78 mbit/s??
<Treenaks> :P
<jdub> so the fluendo guys have a host doing 80mbit/s atm
<rburton> more clients needed!
<jdub> 15% cpu, 20% mem
<Treenaks> jdub: nice
<jdub> definitely
<jordi> OMG it's jdub
<jdub> the more clients the better
<jordi> I just joined
<jdub> peak was 20
<jordi> hellooooo jduuub
<jordi> hahaha
<jdub> :)
<Simira> miss me, Mithrandir? http://129.241.136.146:8080/
<rburton> i've got serious a/v sync issues here
<jordi> yeah
<jdub> rburton: yeah, work is being done on that
<Mithrandir> Simira: I'll take a look after I've updated my hoary here.  Right now, the network is icky enough as it is
<jdub> i'm updating my hoary mirror atm ;)
<jordi> so, what in Fluemotion is free and what isn't?
<Simira> Mithrandir: it's ok, I'll have my cybersex with jdub as we're waiting
<jdub> jordi: currently, it's all free
<jdub> jordi: flumotion will be selling proprietary licensed plugins for like, windows media
<Mithrandir> Simira: eyh!
<jdub> jordi: and probably management tools and so on
<jordi> jdub: oh, sounds cool
<jdub> flumotion is very rad
<jdub> not only because it's built on Beautiful Technology
<jdub> but the architecture is so sensible
<jdub> think... distributed gstreamer piplines
<jdub> with smart components as well as gstreamer elements
<jdub> all built on gstreamer, python and twisted :-)
<jdub> much love!
<sabdfl> Mithrandir: seems to work very well on x86
<rburton> jdub: i presume you have a local flumotion which grabs fottage and encoder, and sends it to the server for sharing
<rburton> footage even
<jdub> rburton: yep
<Mithrandir> sabdfl: should work just as well on amd64.
<jdub> rburton: see the admin sshot
<jdub> rburton: capture and encoding is all done on my laptop
<Kamion> T-Gone: oh, I see, it's the language-support stuff
<jdub> rburton: it's shunted to lazarus, my desktop, which the firewall has DNAT rules to
<Kamion> blah
<jdub> rburton: the worker on node (in the USA) connects to the desktop
<jordi> there must be something wrong with me: I have an ephy window in the background, with jdub's screenshot of Fluemotion Admin. And I can't help thinking every two minutes "damn, that's probably not translated at all, where can I get a .pot"
<jdub> so one 180kbit/s upstream from here
<jdub> jordi: ha ha ha :-)
<Mithrandir> jdub: how do you do that?
<jdub> Mithrandir: which?
<rburton> jdub: sweet
<Mithrandir> jdub: push to another machine.
<jordi> lol
<jordi> haha
<Kamion> T-Gone: ok, I've told the ia64 CDs not to install language-support-* either for now, which ought to work around that issue
<jordi> well, funny thing is that "cercant" is the Catalan way
<jdub> Mithrandir: just by setting up the flow
<Kamion> T-Gone: looks like mozilla-firefox badly needs fixing on ia64 too
<jordi> not the Valencian way
<jordi> but I'm used to the Catalan way for translations
<jordi> Go Amlie
<jdub> Mithrandir: flumotion adds a flexible network configuration layer on top of gstreamer, basically
<jordi> some days I listen to that disk nonstop. I get up with that every day, too :)
<jdub> Mithrandir: for fully distributed production, conversion and streaming :-)
<jdub> jordi: cool :)
<jdub> it's great working music
<dredg> hmmm, multicats jdub|tv
<dredg> er, multicast
<jdub> yeah, no multicast yet
<jordi> jdub|tv is cool
<jdub> plus basically no network supports it usefully ;)
<Mithrandir> jdub: dude, I've used flumotion, but only in a very basic way.  No need to give me the full marketing speech. ;)
<dredg> jdub: yes yes. let me live in my dreamland of multicast, ipv6 and an end to NAT :)
<jdub> Mithrandir: yeah, the wizard doesn't really expose all the love ;-)
<Treenaks> dredg: that land is in MY dream world!
<jdub> Mithrandir: my flow is actually a series of raw gstreamer pipelines, rather than flumotion components
<dredg> Treenaks: woo :)
<jdub> i really should switch to some of the default components
<sjoerd> dredg: get on a nice university lan and you can have it :)
<Mithrandir> jdub: oh, ok.
<dredg> sjoerd: hey, i've got 2 out 3 here :)
<jordi> so who was this dude who said he know it was me?
<Treenaks> jdub: what kind of camera are you using?
<jdub> logitech quickcam 4000
<jordi> a quickcam? wow
<jdub> jordi: random badopi lug dude ;)
<jordi> oh, I see :)
<jordi> I missed t he first part, volume too low
<jdub> it's interesting watching my eye movements
<jdub> across the screen
<jdub> when i look down and to the right (from your perspective), i'm looking at my stream window
<elmo> totem's unbelivably fragile on powerpc
<jdub> when i'm looking down and to the left, i'm looking at my irc entry line
<Treenaks> jdub: you're watching yourself fullscreen using XGL and transparent xterms? :P
<jdub> top right is the flumotion admin window and incoming email
<Mithrandir> elmo: it's fragile on  i386 as well.
<jdub> elmo: should be better with the gst-plugins update coming this week
<dredg> hmm, tomboy++
<Treenaks> Skip World!
<mvo> rburton: what do I have to do to reproduce the problem with gnome-app-install and my patch? it seems to work here on my inital test?
<jordi> jdub: how's polypaudio doing these days? Have the problems it had a few months ago been resolved?
<jordi> Stopping rb just because I want totem sounds a bit 1998 to me :)
<jdub> jordi: from d-d-l? yeah, massively - alan gave it the thumbs up :)
<jdub> jordi: still having some problems with it in hoary
<jordi> jdub: what kind of problems?
<jdub> you're on ppc right?
<jordi> yeah
<jordi> at times ppc, at times intel
<jdub> for one, the alsa plugin doesn't work on ppc, so use the oss plugin ;)
<jordi> yay. :)
<jordi> has it been uploaded to Debian? if not, need help with that?
<jordi> and, is anyone DDoS'ing your stream? :)
<jdub> 12 clients atm, pushing 1.57mbit/s
<jordi> it came to a stop here
<jdub> i think i'd be pretty happy with the current version hitting debian unstable
<jdub> ds was going to do it, but i haven't heard from him in a while
<jordi> *nod*. My offer stands, jfyi :)
<jordi> hmm, connection refused now
<rburton> jdub: say hello to vicky for me, cheers
<rburton> waa the stream is well bust
<smurfix> Kamion: found it. Not a translation problem.
<carlos> jdub: is normal that since more than a week ago I have problems with the icons? many of them are missing
<jdub> ouch
<jdub> the streamer's having a bit of a spew atm
<jdub> carlos: on ppc?
<carlos> jdub: yes
<pitti> daniels: ping
<jdub> hrm, international bandwidth hurting
<jordi> jdub: if it's the same bug as in debian, your icon caches are fucked
<jordi> err
<jdub> carlos: so the icon cache stuff landed, and is broken on ppc :-)
<jordi> carlos
<jdub> carlos: seb is tracking it
<seb128> carlos: rm -f /usr/share/icons*/icon-theme.cache
<carlos> jdub: ok
<jordi> seb to rescue
<seb128> carlos: sudo rm -f /usr/share/icons/*/icon-theme.cache
<carlos> seb128: :-D
* seb128 kicks the gtk guys
<seb128> the icon cache is bong by spec
<carlos> seb128: so you broke my icons???
<seb128> sure, broking panel is boring, I've changed 
* Mithrandir chuckles
<carlos> seb128: :-D
<carlos> it works, thank you
<thom> it's gdm borkage next, right?
<thom> (the other good thing about FF1.0.1 is i can call it firefox from the start)
<jordi> thom: what's that?
<Kamion> smurfix: what was it?
<Kamion> oh my god, I wonder how many layering violations I can commit in one script
<Kamion> this one is going to have to fiddle with not only /var/lib/anna-install/queue, but, if I'm not mistaken, /var/lib/dpkg/status as well
<Mithrandir> Kamion: wtf are you up to?
<thom> jordi: Moz Foundation want us not to call firefox mozilla-firefox due to trademarks
<jdub> carlos: this one iz gtk boog :)
<jordi> thom: renaming the package to "firefox" is enough?
<jordi> the moz TM stuff is sad
<thom> jordi: well, and the binaries and so on, but yes
<Kamion> Mithrandir: trying to forcibly install and configure a couple of packages before anna runs
<Mithrandir> Kamion: why not just dpkg -i them?
<jdub> yeah
<jdub> they've adopted a pretty silly policy unfortunately
<Kamion> Mithrandir: specifically, trying to bring the CD-ROM or the network up so that I can read a Kickstart file from it before language selection happens
<Kamion> Mithrandir: udpkg -i ... but I might have to wget them. I want to use the existing retriever/anna infrastructure.
<Kamion> Mithrandir: and the /var/lib/dpkg/status thing is because I want the retriever to run again later. I might be able to avoid that one, though.
<smurfix> Kamion: The selector which first runs is kbd-chooser/method, which needs its default selection passed to it, which didn't happen when it was preset.
<smurfix> Kamion: Testing now.
<Kamion> smurfix: oh, ok
<Kamion> smurfix: I was actually thinking of preseeding that too, but it would probably be good if kbd-chooser behaved gracefully when the priority is too high for that question to be shown
<thom> jdub: nod
<smurfix> Kamion: I'll check that too while I'm at it. Anyway that one is something kbd-chooser-internal and thus never should need to be preseeded.
<Kamion> smurfix: thanks :)
<T-Bone> Kamion: firefox needing fixing? How so?
<T-Bone> Kamion: what's the preferred way to get my system back to a known state btw, so that I can go on with ooffice? apt-get remove --purge 'language-support-*' ?
<pitti> carlos: did you read Mark's latest reply to the rosetta import discussion?
<carlos> pitti: doing it atm
<pitti> carlos: it seems that there is now a consensus to put the mo files into the tarballs
<pitti> carlos: and do the mapping externally
<pitti> carlos: can you please tell me when I shall upload a new pkgstriptranslations with the new domains.txt format?
<pitti> carlos: i. e. which maps translation domains to their deb files?
<carlos> pitti: sure, as soon as I implement it and it's moved into dogfood
<carlos> pitti: could you add a note to the spec talking about the domains.txt file format?
<pitti> carlos: okay, you should implement it first, then I do the modification
<pitti> carlos: just ping me
<pitti> carlos: yes, I'll do
<carlos> pitti: thanks
<pitti> carlos: to which spec
<pitti> ?
<carlos> the POAttach one
<pitti> ah, ok
* pitti changes computer, brb
<Kamion> T-Bone: well, it segfaults, judging from your log?
<Kamion> T-Bone: yeah, remove whatever's broken
<Kamion> T-Bone: or 'apt-get -f install' might do it
<smurfix> Kamion: now drops back to main-menu: "Priority changed externally, setting main-menu default to 'medium' (CRITICAL)"
<smurfix> Kamion: any idea why that'd happen?
<Kamion> smurfix: some postinst returned non-zero, usually
<smurfix> Kamion: Ah, happily it didn't log which one. :-/
* dredg bahs at new gaim
* dredg shakes his fist at it
<Kamion> smurfix: should've done ...
<pitti> carlos: can you please review my changes to PoAttach?
<carlos> sure
<elmo> Kamion/T-Bone: FYI, the problem was a firmware bug - the EFI client only works once, any subsequent attempts fail.  it worked flawlessly after a cold-reset.
<T-Bone> Kamion: damn you were right. NFC what's wrong with firefox :(
<T-Bone> elmo: doh. that's a nice thing to write down somewhere :P
<elmo> s/client/TFTP client/
<Kamion> T-Bone: the same thing's been happening in live CD rootfs builds
<Kamion> T-Bone: probably another reason mdz thinks the port needs work :)
<T-Bone> Kamion: this is whole new bug. How comes such a bug could enter the 'freezing' release???
<Kamion> T-Bone: it's been happening for at least a week or two; how come it didn't get noticed by the ia64 people sooner? :)
<Kamion> actually, that's unfair, I think Remi noticed it
<Kamion> but it needs somebody with an ia64 to debug it
<Kamion> since it seems to be ia64-specific
<T-Bone> lamont: thinks it happens on hppa as well
<Kamion> ok
<T-Bone> what scares me is that i see no trace of that bug in Debian BTS
<thom> hrm, i'll have to try on mine; i'm pretty sure it didn't happen during install
<Kamion> thom: yeah, you said that before I remember
<T-Bone> Kamion: no correlation between -4 ABI bump and that bug?
<Kamion> T-Bone: no, it was before -4
<T-Bone> ok
<T-Bone> it's the first time i've seen this
* thom dist upgrades the itanium
<T-Bone> last ISO i've been trying was array5...
<T-Bone> kinda surprising
<lamont> T-Bone: I haven't tried it on debian/hppa - dunno if it happens there or not
* T-Bone will try on debian ia64 once the zx6000 will be up
<Kamion> I thought it happened with array5 too
<T-Bone> this is really annoying. We were almost there... :P
<Kamion> I'm sure I remember there being problems generating the live CD
<lamont> Kamion: the current livecd issue is that libbonobo is ftbfs -> ubuntu-desktop fails to install
<lamont> and that bug is in both debian and ubuntu
<lamont> Kamion: speaking of livecd's....
<lamont> did you kick a set since I built new rootfs's for you?
* lamont needs a good livecd with -24 sometime within a couple hours from now
* thom blinks
<lamont> since the one I have (from 10 Feb) kinda sucks rocks
<thom> ok, i just did a purge and reinstall of firefox on ia64, no problems
<lamont> thom: current ia64?
* thom upgrades kernel and reboots just to check
<thom> um
<thom> or not
<thom> Setting up linux-image-2.6.10-4-mckinley-smp (2.6.10-24) ...
<thom> /usr/bin/ldd: line 153: /lib/ld-linux-x86-64.so.2: No such file or directory
<thom> ldd: /lib/ld-linux-x86-64.so.2 exited with unknown exit code (127)
<T-Bone> lamont: no bug on debian
<thom> Failed to create initrd image.
<lamont> thom: WTH?!?!?
<T-Bone> thom: 'x86-64'???
<Kamion> lamont: not yet, just kicked
<thom> please explain why initrd-tools on ia64 is trying to get at /lib/ld-linux-x86-64.so.2 ?
<thom> *please*?
<T-Bone> doh
<T-Bone> it's not firefox at fault
<T-Bone> the error happens when setting up mozilla-firefox-locale-en-gb
<Kamion> yes but it's firefox segfaulting
* T-Bone casts eternal curse spell on language support
<Kamion> Updating mozilla-firefox chrome registry.../usr/sbin/update-mozilla-firefox-chrome: line 95: 24544 Segmentation fault      firefox-bin -register >/dev/null 2>&1
<T-Bone> Kamion: yeah I see that. If it wasn't devnull'd maybe we'd have more info :P
* T-Bone tries to run it by hand
<trulux> pitti: libssp cvs done
<trulux> pitti: packages now being worked
<trulux> 10 minutes
<pitti> trulux: you mean you release a new upstream tarball?
<trulux> yeah
<trulux> pitti: one moment
<pitti> trulux: if that's ready, I can build new debs
<trulux> great
<mdz> morning
<trulux> mdz: hey!
<trulux> pitti: http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/libssp.tar.gz?view=tar
<pitti> Hi mdz
<trulux> pitti: going to work out the selinux-support meta package now
<trulux> pitti: one moment
<trulux> pitti: I need to fix the Makefile for make you able to compile without a ssp-enabled gcc
<T-Bone> fascinating
<Kamion> lamont: live CD up
<thom> hey mdz
<lamont> yep.  definitely time to go to a place where bandwidth is available.
<T-Bone> so on one hand you have update registry failing because of missing files (langpacks), and otoh, firefox-bin -register segfaults in a munmap call :P
<mdz> thom: have some time for a voice call today?
<thom> mdz: sure
<thom> when is good?
<dholbach> re
<lamont> T-Bone: heh.
* T-Bone notes that he tested dfsg.1-2 on debian (testing) :P
<T-Bone> and ubuntu has 1-6
<thom> T-Bone: unstable also
<lamont> T-Bone: what's with this testing crap, eh?
<T-Bone> thom: of course
* lamont back in a few
<T-Bone> lamont: heh
<thom> and i'm pretty damn confident we have no local patches on the javascript stuff, which is where it looks to be blowing up
* T-Bone installs in his sid chroot
<T-Bone> yes
<T-Bone> at least that's what i could figure out of strace
<thom> 0x2000000000136001 in js_strlen () from /usr/lib/mozilla-firefox/libmozjs.so
<thom> (gdb) bt
<thom> #0  0x2000000000136001 in js_strlen ()
<thom>    from /usr/lib/mozilla-firefox/libmozjs.so
<thom> #1  0x2000000000135100 in js_NewStringCopyZ ()
<thom> i'm going to warm my house up and get a debug build built
<T-Bone> heh
<T-Bone> i wish you good luck :)
<mdz> thom: more than 1 hour from now would be best, give me some time to get started on my day
<thom> mdz: sure; i have no plans for the evening bar getting firefox 1.0.1 packaged
<T-Bone> thom: i'll focus on the ooffice stuff then. Thx for having a look at this anyway :)
<thom> T-Bone: want to work out initrd-tools, too? :P
<HiddenWolf> thom: yay :)
<T-Bone> thom: that's a jbailey thing :)
<thom> T-Bone: coward :-)
<T-Bone> thom: that's my second name :^)
<thom> heh
<HiddenWolf> Hey Thom: when do I get my icon for 'history' in FF? :)
* T-Bone forgot how painful it was to debootstrap sid on ia64 :P
<mdz> thom: maybe a mozilla-firefox-dbg package would be useful?  it's trivial these days
<mdz> thom: I bet it would be about 200M though
<Kamion> elmo would love that
<T-Bone> heh
* tseng was thinking of mono-debug yesterday
<thom> mdz: i was thinking about that
<thom> mdz: but it would be gargantuan :/
<doko> lamont: please could you reschedule gcc-snapshot?
<Kamion> debugging stuff that happens before d-i main-menu starts up is hard :-/
<Kamion> boot with init=/bin/sh, edit /etc/inittab, exec /sbin/init, step through /sbin/debian-installer by hand ...
<lamont> doko: debian/{hppa,ia64}?
<lamont> doko: or where?
<doko> lamont: all archs, updated build-deps are now in the archive.
<pitti> trulux: can you please put the new libssp to http://sourceforge.net/project/showfiles.php?group_id=118309
<lamont> doko: on debian though? or does ubuntu even have gcc-snapshot?
* thom snickers at the last response on 6347
<lamont> ah, universe
<doko> lamont: ubuntu
* mdz weeps at the size of his ubuntu-bugs mailbox
<lamont> doko: done
<thom> mdz: a vacation's worth of joy?
<lamont> thom: you heartless bastard you
<thom> lamont: me?
<lamont> heh
<trulux> pitti: now it's maintained at tuxedo-es.org
<Kamion> mdz: and all totally unthreaded, yay
<trulux> let me update the new tree
<trulux> pitti: committing to cvs
<Kamion> thom: what happened to that bugzilla threading patch?
<seb128> lamont: any idea of why gnome-session 2.9.4-0ubuntu3 is not in the archive/built ?
<thom> Kamion: i was just thinking that; i wonder where we can steal it from
<seb128> hum
<seb128> it's built
<seb128> just not on archive
<Kamion> hello, debconf answer, where did you disappear to?
<mdz> Kamion: what do you think about adding a check to debian-cd to bail out if the kernel doesn't match between the CD and the cloop image?
<lamont> Feb 25 16:44:02 buildd-uploader: Setting to Uploaded(hoary): gnome-session 
<lamont> NEW maybe?
<Kamion> that would require debian-cd being able to look inside the cloop image
<mdz> Kamion: filesystem.manifest should be sufficient
<Kamion> I suppose it could check the manifest
<lamont> seb128: were it not new, it should have arrived in the archive 20 minutes ago
<Kamion> mdz: do you want exact version check, or just ABI?
<Kamion> (I'd expect the latter)
<mdz> Kamion: ABI would be most appropriate for the daily builds, I suppose
<lamont> seb128: you mean these:
<lamont> <img src="/icons/unknown.gif" alt="[   ] "> <a href="gnome-session_2.9.4-0ubuntu3_amd64.deb">gnome-session_2.9.4-..&gt;</a> 25-Feb-2005 16:50  303K
<lamont> <img src="/icons/unknown.gif" alt="[   ] "> <a href="gnome-session_2.9.4-0ubuntu3_i386.deb">gnome-session_2.9.4-..&gt;</a> 25-Feb-2005 16:45  280K
<lamont> <img src="/icons/unknown.gif" alt="[   ] "> <a href="gnome-session_2.9.4-0ubuntu3_ia64.deb">gnome-session_2.9.4-..&gt;</a> 25-Feb-2005 16:50  346K
<lamont> <img src="/icons/unknown.gif" alt="[   ] "> <a href="gnome-session_2.9.4-0ubuntu3_powerpc.deb">gnome-session_2.9.4-..&gt;</a> 25-Feb-2005 16:50  293K
<Kamion> mdz: ok, will do
<mdz> I'd rather have those builds fail, than produce CDs without a chance of working
<mdz> thanks
<lamont> seb128: --> slow mirror
<seb128> lamont: http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-session/ 
<seb128> lamont: k
<lamont> seb128: my cut is from the master machine, not the 'master-mirror'
<seb128> k
<lamont> mdz: that's the one thing that wiki/BuildDaemons is missing (time to mirror to archive.u.c is sometimes non-zero)
* lamont brb
<seb128> thom: this version of gnome-session has the powermanagement stuff in the session dialog if you can try it
<Kamion> lamont: I take it you haven't been seeing #4940 of late either?
<trulux> anybody here has the OLS LaTeX class?
* trulux needs it urgently :(
<smurfix> Kamion: kbd-chooser should be OK now.
<thom> seb128: 0ubuntu2?
<thom> k, will test in a few
<seb128> thom: no, 0ubuntu3
<Kamion> smurfix: thanks a lot
<seb128> thom: read some line before, mirror slowness
<smurfix> Kamion: He, it's my bug, I fix it. ;-)
<mdz> lamont: -24 is the one which includes noinotify-by-default, right?
<thom> oh, right
<pitti> bye everybody
<mdz> Kamion: would apt-cdrom -m be simpler than what you did in base-config (2.62ubuntu6) ?
<lamont> mdz: yes
<mdz> lamont: ok, thanks
<mdz> so it's on the current daily-live
<lamont> mdz: and identical (broken) behavior to -23 if you enable it
<mdz> inotify looks like a bust
<mdz> should we even keep it in the tree for hoary?
<lamont> yeah - that's why I had Kamion build them again
<lamont> removal is an abi-event
<lamont> new patch is quite likely an abi event
<lamont> (that's not checked yet though)
<lamont> rml is apparently working on a better patch - I'd like to include that in the hoary tree, although probably not enabled at this late date
<T-Bone> lamont: so once i've built openoffice.org-amd64 on ia64, what's the next step? :)
<lamont> T-Bone: figure out what it takes to make it run..
<T-Bone> lamont: loads of scary unmet deps :P
<lamont> mrf
<T-Bone> (ia32-libs*)
<Kamion> mdz: base-config already does apt-cdrom -m
<lamont> those should be built already on ia64 - if not, apt-get source, vi debian/control; uch -i; build
<Kamion> mdz: the point was more that apt-setup (not apt-cdrom) tries to handle /cdrom mounting/unmounting
<T-Bone> uch heh? :)
<Kamion> T-Bone: um ...
<Kamion>  ia32-libs | 0.5ubuntu2 |    hoary/main | source, amd64, ia64
<mdz> Kamion: ah, I misunderstood then
<Kamion> ia32-libs-dev | 0.5ubuntu2 |    hoary/main | amd64, ia64
<thom> hrm, lets see if that gets us threading
<T-Bone>  openoffice.org-bin: Depends: ia32-libs-openoffice.org (>= 1ubuntu4) but it is not going to be installed
<T-Bone>   openoffice.org-gtk-gnome: Depends: ia32-libs-gtk (>= 2) but it is not going to be installed
<Kamion> ia32-libs-openoffice.org |   1ubuntu4 |    hoary/main | source, amd64, ia64
<Kamion> ia32-libs-gtk |          2 |    hoary/main | source, amd64, ia64
<T-Bone> o_O
<Kamion> apt-get install ia32-libs-gtk and see what that says
<T-Bone>  ia32-libs-gtk: Depends: ia32-libs (>= 0.5ubuntu2) but it is not going to be installed
<T-Bone> happy circular deps
<Kamion> and now apt-get install ia32-libs
* T-Bone grumbls
<Kamion> I see no circular deps so far
<T-Bone> same as before
<Kamion> which was?
<T-Bone> hmm
<T-Bone> i'm an idiot
<Kamion> ia32-libs has no dependencies
<T-Bone> that was the issue
<T-Bone> ;)
<lamont> lol
<Kamion> probably your broken apt database from the earlier problems
<T-Bone> actually that *is* the issue, It's not likely it's gonna be fixed soon ;)
<T-Bone> Kamion: nah. Missed the 'apt-get -f install' step :)
<Kamion> install stuff with dpkg -i to get you going
<lamont> anybody need anything before I disappear for 30-60 minutes on my way into town?
<mdz> Kamion: do you have a milestone release checklist?
<HiddenWolf> lamont: I'll give you my bankaccount number. fill it up. ;)
<Kamion> mdz: not really :(
<T-Bone>   ia32-libs-openoffice.org: Depends: lib32gcc1 (>= 3.4.2-2ubuntu3) but it is not installable
<lamont> HiddenWolf: withdrawls work as well as deposits.  fire awawy
<Kamion> mdz: well, there's general stuff I've mailed around before
<T-Bone> here were are
<T-Bone> down to the real issue
<mdz> Kamion: if you have some notes or a starting point, please put it into the wiki, and I'll expand on it
<Kamion> mdz: ok, will find later, I'm buried right now
<lamont> T-Bone: so we'll need one of those...  there's a 32-bit environment for ia64 lying around somewhere.....
<lamont> pester dannf et al
<mdz> Kamion: right, not urgent
<T-Bone> lamont: humpf :}
<mdz> Kamion: what's at the top of your list atm?
<Kamion> mdz: making kickseed work smoothly with kickstart files on cdrom/network
<elmo> Kamion: do you know how to make a usb stick bootable?
<mdz> Kamion: is there anything specific which would help move things along?
<Kamion> mdz: not really, I'm just plugging away, I'm half-way through at the moment and trying to concentrate on getting the bulk done today
* lamont heads to town to forage bandwidth, burn livecd for the schools IT guy
<Kamion> elmo: for the installer or otherwise?
<mdz> Kamion: ok, good luck
<elmo> Kamion: otherwise - I need to firmware upgrade a cd-less machine, but don't worry I found a howto, I'll try that first
<Kamion> wow, udev just created /dev/discs/disc-1/part
<Kamion> stupid fucking script
<elmo> oh crap, or not - as syslinux so doesn't exist for powerpc
<thom> yay, threaded bugs
<Kamion> elmo: the sum total of my knowledge of powerpc USB booting is in the d-i manual
<thom> Kamion: enjoy
<Kamion> (pretty much)
<remi`> T-Bone, lamont, what's stopping OOo to build natively on ia64 ?
<elmo> Kamion: it's an i386 box I need to upgrade - the powerpc bit is my laptop IYSWIM
<Kamion> elmo: http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-powerpc/current/doc/manual/en/ch05s01.html#usb-boot
<Kamion> elmo: oh, er, ok
<lamont> remi`: lack of 64-bit support in oo.o
<lamont> remi`: that is, the same thing that's keeping it from building natively on amd64
* lamont hugs thom
* lamont heads to town - back online in 30-60 min
<T-Bone> lamont: iterashai ;)
<mdz> thom: omg-threaded-bugzilla
<lamont-away> T-Bone: itteirasshai, but yeah
<lamont-away> itte kimasu
<mdz> thom: you rock
<T-Bone> lamont-away: heh, sorry for the spelling :)
<Kamion> thom: threading> hooray!
* Kamion uses dpkg --force-architecture in anger
<lamont-away> Kamion: anger is bad you know... :-0)
* lamont-away really leaves
<Kamion> thom: hm, the first message in each bug shouldn't have an in-reply-to: header
<thom> amusingly, it's 30 minutes of tracking horrible perl, and then a one line change
<thom> Kamion: probably, but i suspect that's serious rewrite territory
<Kamion> no, I doubt it
<Kamion> make the first message have message-id: <bugzilla-$bugno@bugzilla.ubuntu.com>?
<remi`> T-Bone, Kamion, sent you both an email about our tests on today's ia64 iso
<Kamion> thom: if you want to give me a temporary macquarie account I'll look at it when I emerge from kickseed
<thom> Kamion: you're assuming that the bug mail is actually a useful template; it appears not be the case but i'll look further
<remi`> T-Bone, does firefox segfault on your box ?
<T-Bone> yes
<T-Bone> thom is working on it
<thom> hrm, i think i see how to do it
<remi`> ok
<Kamion> remi`: did I get round to saying to you that you can work around the GNOME freeze by booting with 'noinotify'?
<Kamion> remi`: the live CD I built earlier this afternoon should fix that though
<Kamion> although I have not tested it myself yet
<remi`> I don't recall you telling me that
<Kamion> ok, have now :)
* remi` makes note
<Kamion> it was broken on all architectures in kernel -23
<Kamion> well, -20 through to -23, but only -23 actually built everywhere
<remi`> that's what I understood from ubuntu-devel
<remi`> Kamion, is there anything specific to ia64 that we can further test?
<thom> meh, lets see if this work
<thom> s
<Kamion> remi`: the stuff T-Bone was mentioning above about OOo/ia32-libs/etc. is currently the highest priority; anything that thom can pass on about the firefox segfault would also be useful
* mvo goes and plays hockey
<remi`> thom, is there anything I could help you with for the firefox segfault ?
<thom> Kamion: #6921 just for you
<thom> remi`: i'll upload a firefox in a bit for ia64 with debugging and unstripped
<thom> if you can test with that and try and get a reasonable backtrace and so on, that'd be great
<remi`> thom, ok
<thom> remi`: it's building now, but this is a single processor 900mhz box, so it may take a while
<remi`> thom, sounds like my gentoo box :)
<thom> remi`: heh
<thom> (it's also completely unccached on this box)
* tuxdisciple shudders
<tuxdisciple> Gentoo...
<tuxdisciple> so many bad memories on my poor laptop
<mdz> seb128: is there an upstream bug about g-v-m exiting when dbus is restarted?
<seb128> mdz: crash or exit ?
<HiddenWolf> tuxdisciple: are you masochistic? ;)
<seb128> mdz: we have a debian/ubuntu patch to handle dbus restarts IIRC, but it seems to crash sometime
<mdz> seb128: I'm not sure if it is crashing or exiting; I just get the restart/close/inform dialog
<mdz> jbailey: ping, re: bug-buddy, bugzilla, etc.
<mdz> thom: have a moment while you are compiling?
<thom> mdz: sure
<mdz> thom: I don't have access to my key at the moment due to the hardware failure.  could you add gnome-app-install to the desktop seed and update ubuntu-meta?
<Kamion> thom: heh :)
<seb128> mdz: so that's a crash
<mdz> thom: then, let's do that call
<thom> mdz: ok, will do
<Kamion> thom: looks great now, thanks!
<thom> Kamion: np :-)
<seb128> mdz: ping sjoerd/pitti about it, the patch is .deb specific
<thom> even if i hate people who use ? : syntax in perl :-)
<Kamion> heh
<mdz> s/in perl//
* T-Bone tries to dpkg-buildpackage gcc-4.0, for the fun of it
<thom> mdz: yes, but especially in perl :-)
<remi`> thom, could the firefox segfault be related to moz-ff-locale-en-gb not installing properly ?
<thom> remi`: the segfault is the cause of -en-gb not installing properly
<dasenjo> Hi, how are you ? I'm trying to use jigit to download hoary and got: Unable to find a file to match dists/hoary/main/daily-installer-i386/20041227ubuntu15.0.20050224/doc/manual/en/apa.html
<dasenjo> How can I solve it ?
<thom> remi`: it segfaults in update-mozilla-firefox-chrome
<Kamion> dasenjo: wouldn't surprise me at all if jigdo were broken
<remi`> thom, ok
<T-Bone> doko: you around?
<doko> yes
<remi`> thom, so that would explain why firefox segfaults and not epiphany (no xul)
<Kamion> dasenjo: that said, that file is still in the archive
<dasenjo> Kamion, Is it not working ? I found a Manual Page in the wiki .. 
<Kamion> dasenjo: yeah, last touched by me ages ago :)
<Kamion> dasenjo: I'll have a look, but probably not today; noted it in my todo list
<T-Bone> doko: looks like we need lib32gcc1 on ia64 for ooo to work. AFAICS, it's part of gcc-4 package, of which only gcc-4.0-base seems available on hoary/ia64...
<T-Bone> doko: any clue how to work around that?
<dasenjo> Kamion, the file exists, I can open it with a browser, what is the problem ?
<thom> remi`: yeah
<Kamion> dasenjo: you'll have to look at where jigit is trying to fetch it from
<dasenjo> how can I do that ? I was trying to edit the .jidgo file .. but it didn't work
<thom> remi`: in segfaults in the javascript library
<Kamion> dasenjo: running it as 'bash -x /usr/bin/jigit ...' rather than just 'jigit ...' may help
<dasenjo> thanks a lot. Im gonna try
<Kamion> dasenjo: might just be wrong archive location or something
<remi`> thom, i read on a report in mozilla's bugzilla that the js lib was not 64bit safe when manipulating doubles and floats
<dasenjo_> yes, I think so .. maybe a mirror hardcoded in the jidgo files .. 
<thom> remi`: i'm pretty sure we've fixed that - certainly we don't have that problem on amd64
<Kamion> dasenjo: yeah, that's kind of necessary with the way it works at the moment :(
<Kamion> also kind of reduces half the point of jigdo, but hey ...
<T-Bone> doko: ?
<doko> T-Bone: yes, ia32-libs, or build it with a cross compiler
<T-Bone> doko: ia32-libs are installed
<T-Bone> doko: the issue is with ia32-libs-openoffice.org:
<T-Bone>  ia32-libs-openoffice.org: Depends: lib32gcc1 (>= 3.4.2-2ubuntu3) but it is not installable
<doko> yes, but they don't have libgcc32, because on amd64 it's built as part of the biarch compiler.
<T-Bone> yumm
<T-Bone> doko: ok, so what would be the best thing to do, bearing in mind we want something suitable for the release...
<thom> mdz: seeds and ubuntu-meta done
<thom> mdz: home phone # on the wiki best for me...
<remi`> thom, let me know when your build is done if you'd like extra testing
<doko> both ways should work (re-adding gcc-4.0 to ia32-libs), or try to build with a cross compiler). The latter should work, but wasn't tested very well.
<thom> it's building the debs now
<mdz> thom: ok, thanks
<T-Bone> doko: build what with a XC?
<mdz> Kamion: any reason not to add rescue mode to the casper seed?
<remi`> thom, ok
<T-Bone> otoh an XC is a no go on the autobuilders...
<doko> T-Bone: build gcc as a cross-gcc, you actually don't need a cross compiler installed
<T-Bone> ah
<T-Bone> ic
<doko> look at debian/rules.defs and debian/README.cross
<T-Bone> doko: i don't understand what do you mean by 'adding gcc-4.0' to ia32-libs...
<doko> the ia32-libs package contains all source and binary packages, and has to be built on an ia32 architecture. that's the way to include the source with binaries.
<Kamion> mdz: up to you, it'll pull in a few more filesystem modules and such is about all
<lamont_r> T-Bone: the ia32-libs package is a boatload of i386 binaries, packaged as source.  it's almost the most evil thing I've seen this year.
* T-Bone is currently looking at ia32-libs source to figure out how that works and what it'd take to 'add gcc-4.0'
<T-Bone> lamont_r: ah ok. No wonder why i don't catch a damn thing then :)
<T-Bone> lamont_r: what would you recommend as the best way to fix that issue?
<lamont_r> add gcc-4.0
<lamont_r> :-)
<T-Bone> lamont_r: care to tell me how? :)
<lamont_r> somewhere in there it has a list of packages that it snarfs up to build the source
* lamont_r has nfc
* lamont_r points at Mithrandir 
<T-Bone> 'fetch-and-build' ?
<lamont_r> evening sabdfl 
<T-Bone> but may i innocently ask how building gcc on a 32bit arch will yields a lib32gcc1 package, since it's natively 32bit?
* T-Bone pings Mithrandir 
<doko> T-Bone: add a patch to name the package lib32gcc1 instead of libgcc1
* T-Bone tries to figure out where such a patch would go
* T-Bone would really enjoy some help from someone with more insight about that system :P
<doko> T-Bone: well, let me know, where and which files in the lib32gcc should go ...
<T-Bone> err
<T-Bone> why would it go in a different place than amd64?
<T-Bone> (not to mention i have NFC how to find that out off hand...)
<ogra> :-D
<mdz> Kamion: that's fine with me
<dredg> question: is it possible to build a package with one or more empty directories?
<mdz> Mithrandir: ping, re: utf8-migration-tool ftbfs
<Gagatan> I think mith is traveling down to fosdem
<Kamion> dredg: yes, people do it by accident all the time because dh_make sticks usr/sbin in debian/dirs or thereabouts
<dredg> Kamion: ah, excellent
* dredg RsTFM
<lamont_r> watched rsync's never finish
<thom> ooook
<thom> /usr/bin/ldd: line 153: /lib/ld-linux-x86-64.so.2: No such file or directory
<thom> ldd: /lib/ld-linux-x86-64.so.2 exited with unknown exit code (127)
<thom> dpkg-shlibdeps: failure: ldd on `debian/mozilla-firefox/usr/lib/mozilla-firefox/libgkgfx.so' gave error exit status 1
<thom> dh_shlibdeps: command returned error code 256
<thom> make: *** [binary-arch]  Error 1
<thom> ia64 very screwy
<T-Bone> thom: ia64 again?
<T-Bone> holly shit
<lamont_r> thom: we saw that earlier - this somethign new?
<lamont_r> or did you reproduce it in debian?
<T-Bone> thom: that's a clean environment you have, of course? :}
<thom> T-Bone: clean install about a week ago, yes
<T-Bone> damn
<T-Bone> that's scary
<thom> lamont_r: i was prepared to just blame mkinitrd before :-)
<lamont_r> ah, ok.
<T-Bone> thom: testcase to reproduce that?
<Kamion> looks like ldd is broken?
<lamont_r> could it be that libgkgfx.so is getting built wrong?
<Kamion> what happens if you do ldd /bin/ls?
<thom> T-Bone: ldd debian/mozilla-firefox/usr/lib/mozilla-firefox/libgkgfx.so
<thom> /usr/bin/ldd: line 153: /lib/ld-linux-x86-64.so.2: No such file or directory
<T-Bone>  ls /usr/bin/ldd*
<T-Bone> /usr/bin/ldd  /usr/bin/ldd.amd64  /usr/bin/lddlibc4
<T-Bone> ldd.amd64???
<T-Bone> wtf?
<Kamion> although actually yeah, it does kind of look as if the wrong interpreter is built into that binary or something
<lamont_r> interesting.  current livecd is 15+MB smaller than the one from Feb 10
<Kamion> thom: grep ^RTLDLIST /usr/bin/ldd?
<T-Bone> Kamion: seen that?
<thom> RTLDLIST=" /lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2"
<Kamion> ook
<Kamion> own up, who broke glibc
<lamont_r> that's just sick.
<elmo> haha
<elmo> I bet it was that "really safe" multiarch change
<zul> i just break kernels not glibc
<T-Bone> how comes i have ldd.amd64 installed?
<Kamion> multiarch would certainly appear to be the prime candidate
<T-Bone> definitely
<lamont_r> T-Bone: remember how you were looking for Mithrandir before???  well, now you're really looking for him...
<T-Bone> hell yes
<T-Bone> lamont_r: though that's kinda nice: it means we're all fixing non issues
<lamont_r> T-Bone: well, lib32gcc1 is probably still needed
<Kamion> I fail to understand how that patch could have caused this though, unless glibc's build system is way sicker than even I expected
<T-Bone> so we can just give them up untill Mithrandir fixes glibc, and work around that ooffice mess int the meantime :)
<Kamion> ++ifndef extra_libdir
<Kamion> ++extra_libdir := $(exec_prefix)/lib/$(shell gcc -dumpmachine):/lib/$(shell gcc -dumpmachine)
<Kamion> ++endif
<Kamion> ++ifdef extra_libdir
<Kamion> ++default-rpath += :$(extra_libdir)
<Kamion> ++endif
<Kamion> that's about all it does
<T-Bone> Kamion: "sicker" ain't a proper word for glibc builds...
<lamont_r> Kamion: any chance that something is leftover in the source?
<Kamion> hang on
<Kamion> exactly where are you guys getting your /usr/bin/ldd?
<Kamion> dpkg -S /usr/bin/ldd
<lamont_r> sure enough -I quit watching the rsync, and it finished...
<Kamion> $ dpkg --fsys-tarfile ~/ubuntu/pool/main/g/glibc/libc6.1_2.3.2.ds1-20ubuntu8_ia64.deb | tar xO ./usr/bin/ldd | grep ^RTLDLIST
<Kamion> RTLDLIST="/lib/ld-linux-ia64.so.2 /lib/ld-linux.so.2"
<Kamion> glibc itself is just fine ...
<T-Bone>  dpkg -S /usr/bin/ldd
<T-Bone> diversion by ia32-libs from: /usr/bin/ldd
<T-Bone> diversion by ia32-libs to: /usr/bin/ldd.amd64
<T-Bone> ia32-libs, libc6.1: /usr/bin/ldd
<Kamion> bingo
<T-Bone> yep
<lamont_r> oh, great evil.
<T-Bone> utter 3v1l indeed
<lamont_r> ia32-libs needs to have a better diversion logic...
<T-Bone> now i'm really sick
<Kamion> so ia32-libs diverts it and replaces it with something that has hardcoded amd64 stuff in
<lamont_r> T-Bone: not on the keyboard!
<T-Bone> lamont_r: ;)
<thom> Kamion: genius
<elmo> aww
<lamont_r> Kamion: and yet has had ia64 in the arch list since time immemorial
<thom> that's so cool
<lamont_r> ldd - does that mean we can blame elmo?
<Kamion> ./debian/rules: sed < debian/ia32-libs/usr/bin/ldd 's%RTLDLIST=.*%RTLDLIST=" /lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2"%' | sed 's%verify_out=`$${rtld} --verify "$$file"`%verify_out=`$${rtld} --verify "$$file" 2>\&1`%' > debian/ia32-libs/ldd
<Kamion> this is the best bug I've seen all week
<thom> ewwww!
<T-Bone> i should fortune it ;P
<T-Bone> who's gonna take care of uploading the fix?
* lamont_r prepares to reboot to test the new livecd
<thom> it's bug 6923 when you do
<T-Bone> :P
<lamont_r> bbiab
* T-Bone is actually trying to figure out what a fix would look like
<T-Bone> given how clueless i am about ia32-libs i may not be the best candidate :P
<thom> right, lets try building firefox with ia32-libs uninstalled
<thom> it didn't fix -register, sadly ;-)
<T-Bone> heh
<thom> 0  5584 2368 1552 R 99.3  0.1   0:50.80 dpkg-deb
<thom> ber, this could take a while
<T-Bone> eek
<thom> 22554 thom      25   0  5584 2368 1552 R 99.3  0.1   3:14.16 dpkg-deb
<thom> (411M    debian/mozilla-firefox/)
<T-Bone> thom: yuck. Wonder what will be left after compression :P
<T-Bone> gonna be quite a big package
<thom> not so bad: -rw-r--r--  1 thom thom 115M 2005-02-25 19:49 mozilla-firefox_1.0+dfsg.1-6ubuntu1_ia64.deb
<T-Bone> indeed. You'd better have a decent link when downloading such a beast anyway :)
<thom> AAAARGH
<thom> lietmotif% sudo dpkg --configure -a
<thom> Setting up mozilla-firefox-locale-en-gb (1.0lang20041216-2ubuntu1) ...
<thom> Updating mozilla-firefox chrome registry...done.
<Kamion> BEST. THING. EVER.
<Kamion> I boot with 'linux ks=http://riva/~cjwatson/tmp/test.ks'
<lamont_r> well... that was a little painful
<lamont_r> anyone bootted the latest i386 livecd?
<T-Bone> thom: you gotta be kidding :P
<thom> Kamion: does it all work?
<thom> T-Bone: i wish
<lamont_r> thom: but can you do that on hppa?
<Kamion> kickseed detects the CD-ROM, scans it, loads installer components from it, detects network hardware, brings up the network using DHCP, downloads the kickstart file, translates it into a preseed file, and preseeds debconf with it
<T-Bone> lamont_r: it's not fixed
<Kamion> *then* it goes into the language question
<T-Bone> lamont_r: the dbg package worked out of the box
<lamont_r> Kamion: woot!
<Kamion> the only remaining buglet is that there's a bit of DHCP spew on the screen, but that's easy to fix
<thom> Kamion: that is so totally AWESOME
<lamont_r> Kamion: have a chance to see if the livecd boots for you?
<lamont_r> mine hangs with the panel on the screen
<thom> oh, for fucks sake
<lamont_r> but unpopulated
<Kamion> I'm not quite sure yet how much I have confused d-i in the process, given that I've perverted its sequence quite drastically
<thom> unreproducible with unstripped/debug enabled firefox
<T-Bone> thom: lemme guess: failed on the second run?
<T-Bone> sigh
<thom> T-Bone: that'd be a good thing
<thom> this'll be fun to debug, then
<Kamion> lamont_r: burning
<T-Bone> thom: this is madness :P
<lamont_r> thanks - I freely admit that my laptop sucks
<lamont_r> although it does actually have 256MB
<thom> T-Bone: s/madness/mozilla firefox/ and you're pretty close to the truth
<lamont_r> of ram
<T-Bone> thom: heh. That could be said of quite some packages (ooo, glibc... :)
<thom> Kamion: so what does a kickstart file look like?
<T-Bone> lamont_r: if that's quantic ram, where each bit can be 0 and 1 at the same time, no wonder why it fails :)
<Kamion> lamont_r: damn, it was using the old vmlinuz
<Kamion> lamont_r: i.e. -23 ... sorry
<Kamion> lamont_r: the daily d-i build must have predated -24 making it into the archive
<lamont_r> and what's with this 3 minutes from the language questions to gnome splash, eh?
<Kamion> thom: my current test one is:
<Kamion> lang en_GB
<Kamion> langsupport --default=en_GB de_DE
<Kamion> keyboard uk
<Kamion> timezone --utc Europe/London
<lamont_r> Kamion: certainly did.
<lamont_r> feh
<T-Bone> lamont_r: that's genlocale, at your se(r)vice
<lamont_r> Kamion: let me go kick a set of daily-di's
<Kamion> lamont_r: smurfix uploaded a proper d-i today, checking to see if it's in the archive now
<Kamion> lamont_r: should be no need
<lamont_r> oh, even better
<Kamion> T-Bone: sevice?
<thom> Kamion: that's all? sweet
<Kamion> thom: well, that only preseeds part of the install, it's not complete
<thom> sure
<T-Bone> Kamion: "abuse" in french
<thom> i was expecting some xml monstrosity
<Kamion> there aren't actually appropriate kickstart variables for all of the questions we ask (e.g. initial username/password)
<Kamion> so I need to extend the format a bit
<Kamion> elmo: could you byhand d-i ubuntu17?
<elmo> done
<Kamion> ta
<Kamion> wow, that was quick
* lamont_r twiddles
<thom> i think we should blame elmo for the ldd madness on ia64
<lamont_r> thom: remember - he knows where you live
<T-Bone> lol
<thom> lamont_r: this is true, but given his usual performance when driving round london, i'm pretty safe
* T-Bone giggles
<Kamion> ha, bye-bye dhcp spew
* lamont_r needs to hack on dhcp it appears
<lamont_r> it seems to not do anything with interface-mtu when specified
<thom> threaded bugs are such sex
<thom> why did no-one harass me about this before?!
<lamont_r> thom: because we thought you had tried and failed? :-)
* T-Bone thinks thom is giving a whole new meaning to the word 'sex', wonders... :}
<thom> lamont_r: really? if i had i would've whined loudly and got colin to fix it :P
<Kamion> why me? :P
<T-Bone> Kamion: because you *can*? :)
<thom> it's perl and a bug tracking system
<Kamion> oh, that sort of threading
<thom> in the end, it must be your fault somewhere
<T-Bone> lol
<trulux> ajmitch: we may need a new mailing list at Ubuntu for SELinux discussion
<trulux> ajmitch: is that possible?
<Kamion> I keep thinking you mean firefox
<thom> Kamion: if you want to fix firefox, you're more than welcome to
<thom> i really won't complain ;-)
<lamont_r> Kamion: so how fast do livecd's create?
<Kamion> lamont_r: about five minutes for the lot
<trulux> mdz: hi?
<lamont_r> does that mean I can hit return?
<thom> hrm, firefox is not fast with debugging symbols
<Kamion> lamont_r: on what?
<lamont_r> rsync'ing yet another one.
<Kamion> lamont_r: no, the d-i byhand hasn't hit the archive yet
<jbailey> Kamion: I just got back - do you still have questions about glibc's build system?
<lamont_r> or are we still waiting for the d-i upload to publsih?
<Kamion> or at least not the mirror on little
<Kamion> jbailey: nah, after a bit more investigation we redirected our ire in the direction of the monstrosity known as ia32-libs
<lamont_r> elmo: is it time for another mid-day day end? :-)
<elmo> it's on the other mirrors
<elmo> you should be able to pull it into little
* lamont_r berates little
<jbailey> Kamion: Lovely, if you need anything else from it, lemme know.  I wrote what's there now.  if you think it's bad now, you should've seen it before I touched it the first time. =)
<jbailey> Kamion: It's due for a post {hoary,sarge} simplification pass, though.
<lamont_r> jbailey: it was pretty then? :)
<Kamion> elmo: hm, maybe I synced too early
<jbailey> lamont_r: Well, it didn't use debhelper, and all the arch stuff was spread throughout with nested if statements.
<T-Bone> lamont_r: you should have seen that: nice shapes all around :)
<lamont_r> jbailey: ew!
<jbailey> lamont_r: And there was about 3 times as much perl to get it all glued together.
<mdz> trulux: hi
* lamont_r decides to use a cd-rw for this livecd burntest
<Kamion> no, apparently auckland is just slow
<Kamion> hm, but no "update in progress" file
<elmo> are you still mirroring off auckland?
<elmo> I should move you over to syowa
<elmo> when, err, I finished reinstalling it
<trulux> mdz: hey mdz, I've asked ajmith for a new mailing list, ubuntu-selinux
<trulux> mdz: is that possible?
<elmo> trulux: why are you asking ajmitch?
<Kamion> elmo: yeah, auckland is the one I have the private rsync access to
<trulux> elmo: just because he is an ubuntu dev and he is also in the selinux work team
<trulux> :)
<mdz> trulux: can we make it a bit more general, perhaps a mailing list about ubuntu and proactive security?
<Kamion> mirnyy doesn't have it either though
<elmo> Kamion: eh
<trulux> mdz: sure
<trulux> mdz: good idea :)
<mdz> trulux: if so, I have no problem with it; jdub would be the person to nag about creating the list
<trulux> mdz: ok
<elmo> GAR
<elmo> syowa being down has broken the mirroring
<lamont_r> hrm.. that was the wrong button
<mdz> trulux: are you sure there is enough to discuss that we can't do it on ubuntu-devel instead?
<trulux> mdz: I'm also going to make the basic selinux-support metapackage (writing it now) and then hack dpkg layout to remove the dirty post-insttricks for files labeling
<trulux> mdz: the list will start getting *lots* of issues
<trulux> mdz: look at fedora-selinux
<trulux> traffic
<trulux> :)
<mdz> good point; I wasn't thinking of support issues
<trulux> among the development discussion
<trulux> mdz: separation is good for this, -devel and support ones
<trulux> so
<trulux> we keep our devs organized
<trulux> and clean
<trulux> as we do here
<trulux> if someone asks, we say "#ubuntu, not here"
<elmo> Kamion: fixed really now, sorry
<Kamion> elmo: looks good, thanks
<Kamion> elmo: so, er, sorry for making a package obsolete a day after introducing it :)
<Kamion> didn't quite expect that
<lamont_r> you go Kamion ! :-)
* lamont_r notes that it has been 5 minutes...
<Kamion> it's publishing
<Kamion> nearly there
<Kamion> lamont_r: it's up
<trulux> mdz: also, is there any chance on introducing the gcc-hardened packages in Hoary?
<lamont_r> wow - that was a fast rsync
<lamont_r>    503156736 100%    3.11MB/s    0:02:34  (1, 100.0% of 1)
<T-Bone> heh
<lamont_r> it's actually going to take longer to burn
<lamont_r> (<10MB actually transferred)
<Kamion> well, the rootfs didn't change
<mdz> trulux: in universe, sure
<lamont_r> exactly
<mdz> trulux: assuming it doesn't involve replacing libgcc
<mdz> (or anything else in main)
<trulux> it does not
<trulux> :)
<trulux> will not :)
<trulux> mdz: oops, here there's a woman that calls me for dinner
<trulux> she can get angry, and the food, cold
<thom> so, the cure to get firefox-locale-* to work on ia64 is to ship firefox with debug symbols and unstripped. everyone happy with this? great
<trulux> so
<trulux> bbl
<trulux> :)
* thom uploads
<T-Bone> doko: so as far as i understand, i'd have to add gcc-4.0 source to the srcs in ia32-libs, a modified source that will build lib32gcc1 on a 32bit system, right?
* T-Bone gets back to his point
<Kamion> thom: er, yuck :)
<lamont_r> thom: only on ia64, right? :-)
<lamont_r> fixating
<lamont_r> thom: so what you're saying is that it appears to be an uninitialized variable or something?
* lamont_r reboots to test _this_ livecd image.
* thom may not have been entirely serious
<T-Bone> mdz: re your mail on d-devel, it actually took 8h to make it. That's why i sent you the mail, though you had already answered
<mdz> T-Bone: I was travelling, and it was queued on my laptop
<thom> lamont-away: guess so
<T-Bone> mdz: i'd be interested to know what are the issues you consider as troublesome WRT hoary (pending OOo fixup, and recent firefox b0rkage...)
<mdz> T-Bone: preview is in less than three weeks, it still has major breakage and has seen very little testing
<ubuntu> well - 4 minutes + to boot, and pcmcia didn't seem to start itself
<T-Bone> mdz: define major breakage please
<T-Bone> mdz: it won't see anymore testing if we don't advertise it either...
* ubuntu reboots back to the other system
<mdz> T-Bone: ia64 is at about the point now where it needed to be at feature freeze
<mdz> we will not cobble it together at the last minute and then call it an officially supported product
<doko> T-Bone: yes, exactly
<mdz> T-Bone: is there some reason you have not advertised it?
<T-Bone> mdz: i don't see what's the problem. Put aside that firefox bug that has recently come up, and the OOo issue i'm fixing, there ain't such "major borkage"
<T-Bone> mdz: your mail was reading as if ia64 was on the same level as sparc, which is definitely not the case
<T-Bone> doko: ok. Special areas I should be extra carefull (when repackaging the modified gcc source maybe?)
<Simira> do anyone here have some time to help me with a system/warty issue? I'm moving a system from one disc to another.
<T-Bone> mdz: i haven't advertise because that's Not My Job (tm)
<T-Bone> +d
<mdz> T-Bone: that's exactly the problem with ia64; no one is owning the problems
<Kamion> T-Bone: why isn't it your job?
<T-Bone> mdz: i beg your pardon. I'm asked to put up, I do
<mdz> T-Bone: you won't take responsibility for leading the porting effort, but you want me to take responsibility for it as an officially supported architecture?
<T-Bone> Kamion: because I'm not dealing with 'press releases' of any kind. I've posted around requesting testing already, some noise has been made... I can't summon the community toward that work if it's not willing to look at it
<T-Bone> mdz: Since when should I take responsibility for the architecture?
<T-Bone> who is officially responsible for x86, ppc and amd64?
<Kamion> in fairness http://www.ubuntulinux.org/community/teams/ia64 says Thierry Simonnet is leading the port team; I haven't really seen much from him
<T-Bone> mdz: bear in mind that i'm a 24-year-old student, and that I do opensource as a hobby.
<Kamion> Mithrandir leads the amd64 team
<mdz> T-Bone said that he would lead ia64, but then he withdrew and said he was leaving town, and Thierry Simonnet was supposed to take over.  Thierry Simonnet didn't answer my emails about ia64
<T-Bone> Mithrandir works for Canonical, doesn't he?
<mdz> no
<T-Bone> mdz: i *never* said i would lead ia64
<T-Bone> mdz: because I *always* knew I couldn't do it
<T-Bone> because I have a life aside Ubuntu
<mdz> I'll have to dig up the email exchange
<Kamion> i386, powerpc, and amd64 are all architectures with enough of an install base among all of the initial Ubuntu developers that there wasn't so much of a need for a port lead, though
<T-Bone> a MS (and next year a PhD) can't be prepared out of a few hours of work you see...
<mdz> you are not making any sense
<T-Bone> i'm sorry that you can't understand me
<T-Bone> let me recap: i started that work on a student project which was expected to have a beginning and an end.
<Kamion> the point is not that we expect you in particular to have time to lead the port; it's fine that you only have a certain amount of time to contribute, and we're glad you're contributing that time
<T-Bone> I decided to pursue my work on my freetime, as I often do on Open Source projects I involve myself in
<Kamion> the issue is that somebody, or some group of people, does need to have enough time to take fairly consistent responsibility for driving the port forward
<T-Bone> Kamion: that's definitely a sure thing. But I can't be that group
<Kamion> and if the leader is spending most of his/her time delegating and making sure the minions :-) get the actual bulk of the work done, that's also fine
<T-Bone> Kamion: and (as a freelance/studant), I don't hold the wires in the background, if you see what I mean
<Kamion> ok, we're not saying *you* have to be
<mdz> T-Bone: neither you nor anyone else is willing to take responsibility for it.  this is why it is not ready.
<T-Bone> mdz: maybe. But in no way I can be held responsible for this.
<Kamion> this isn't a question of apportioning guilt
<T-Bone> I fulfilled all the commitment I involved myself in, so far
<T-Bone> +s
<T-Bone> even those I knew it'd be very hard for me to cope with given some extraneous very troublesome events that happened to me
<T-Bone> Kamion: that's ok. It feels like i'm being blamed for things I haven't done.
<T-Bone> nobody seemed to have noticed that the burden is on *my* shoulders, if nobody else hack on ia64, btw :P
<Kamion> I don't think anyone's blaming, and I don't think it's productive to think of it in terms of blame; it will only get everyone upset
<T-Bone> to that extent i'm very thankful to you (kamion) and lamont for your valuable help
<Kamion> including yourself :)
<T-Bone> heh
<Kamion> actually, if nobody else hacks on ia64, the buck has a habit of stopping at Canonical by default; and there's only so much effort we can afford to put in
<Einzelganger> Are there any tests (subscribed,spam) on sending mails to ubuntu-devel@lists.ubuntu.com. I tried to send a (long) mail 2 days ago, but it didn't arrive.
<Kamion> Einzelganger: it's moderated for non-subscribers
<T-Bone> Kamion: 'the buck'?
<Kamion> T-Bone: responsibility
<remi`> if I may add my grain of salt to the ia64 conversation, i'm part of the students team working for/with thierry simonnet
<T-Bone> Kamion: err, then I don't get what you said :P
<mdz> T-Bone: I'm not blaming you; I'm trying to explain to you that official support for an architecture requires more than having things compile
<Kamion> T-Bone: one of the things that was brought up in Mataro as a means of reducing the "but *you* get paid for it" resentment was to point out that people who're paid to hack also get told what to hack on, and thus basically end up doing the boring stuff that nobody else wants to do
<Kamion> T-Bone: which tends to include picking up the pieces from things nobody else is actively supporting
<Kamion> T-Bone: but we do have limited resources and we need to limit our exposure to that
<T-Bone> roger that
<Kamion> T-Bone: ("the buck stops here" is an English idiom, BTW, meaning roughly "the responsibility ends up here if nobody else assumes it")
<T-Bone> but then if ia64 isn't part of Canonical's priority, maybe it shouldn't be ever considered for "support". Unless you're willing to rely on community support only, which can vary alot, as one can see...
<Einzelganger> How often is it moderated, and do you get a message if/why something is refused ? (send 24 hours ago actually) ?
<T-Bone> Kamion: ah ok :)
<Kamion> Einzelganger: I think it's on a "when mako/jdub get around to it" basis ...
<Kamion> T-Bone: the original intent was that it should be a largely community-supported port, certainly
<T-Bone> Kamion: seems that the ia64 community is a rather peculiar one
<lamont_r> moo
<lamont_r> Kamion: much happier livecd
<lamont_r> just placed one with someone I met in the coffee shop
<Einzelganger> I'll try to send it again then with a reply-to which is the same as my subscribed email-adres. This moderation is that fairly new, I send this month and it seemed to be immediatly send ?
<mdz> yes.  Canonical contributed the necessary hardware, with the expectation of support from the community to drive the port
<Kamion> with support from Canonical people where necessary (e.g. lamont's basically the only person with access to munge the buildds, I'm basically the only person with access to munge CD images, etc.)
<mako> Einzelganger: i'll look at it
<Einzelganger> mako, ah, ok
<Kamion> Einzelganger: it's been moderated from day one AFAIK
<Kamion> lamont_r: cool
<elmo> Kamion: [and launchpad's meant to fix that] 
<Kamion> elmo: right
<T-Bone> Kamion: yeah. As I understand it, if canonical has bought machines, I fail to see why Canonical's people (which are the only ones to access them) wouldn't have ia64 listed on their tasks...
<Kamion> T-Bone: hence "where necessary"; most of the porting effort should not be resting on the shoulders of those with direct access to the buildds
<T-Bone> as to the community support, it looks (to me) that the 'community' is waiting to have a "released" product to draw a "verdict" on it...
<mdz> T-Bone: if the community is waiting for someone else to deliver a port, that is backwards
<T-Bone> Kamion: sure. That's where I (tried to) do my part of the job
<T-Bone> mdz: alas
<Kamion> T-Bone: right
<Kamion> anyway, gotta go, night all
<T-Bone> see ya
<mdz> in large part, the viability of a port will be determined by the willingness of the community to develop it
<mdz> just as with other open source projects
<T-Bone> sure
<mdz> Kamion: night
<T-Bone> the fact is that it looks like ia64 is more a 'market community' than a 'developers community', if i may say so
<lamont_r> T-Bone: for the most part, canonical employees don't have access to the machines
<lamont_r> for example, I'm the only one with logins on the buildd's. (well, modulo elmo-the-admin)
<T-Bone> lamont_r: heh. So what are these machines for?
<lamont_r> T-Bone: they're for building bits
<dredg> so wht happens if both you and elmo get hit by busses?
<mdz> they build packages.
<lamont_r> dredg: then we get repalced
<mdz> dredg: this is why we keep them in separate countries :-)
<dredg> mdz: cunning :)
<mdz> it would require a very large bus
<lamont_r> dredg: I already got hit by one large truck. that's enough
<mdz> or a far-reaching conspirace of buses
<lamont_r> the truck that hit me outweighed my full-size bronco by 10x
<dredg> eep
<lamont_r> mdz: you don't subscribe to the one-bus theory, eh?
<dredg> well, i did specify busses
<lamont_r> dredg: it was, um, an experience.  and I don't care to repeat it
<T-Bone> lamont_r: how many machines does it take to 'build bits'? Or else, what kind of bits are you building? :}
<lamont_r> there are 3 for redundancy
<T-Bone> err
<lamont_r> which is good for times when elmo is rebuilding the datacenter :-)
<lamont_r> (right now I have 2 ia64 buildds...)
<T-Bone> we're talking about redundancy for a yet unsupported arch? :}
<T-Bone> ain't that backwards? :)
<dredg> need any more admins? :)
<elmo> t-bone: 3 buildds is our standard config
<elmo> and non-$$$$ ia64 machines are not fast, 3 isn't excessive
<elmo> (heck, the non-fast machines are $$$$, the fast ones are $$$$$$$$$$$$$$$$$$$$$$)
<ogra> heh
<lamont_r> T-Bone: near as I can figure, mark was given to understand that there was a community out there, and that if we built it they would come.
<lamont_r> in that respect, ia64 is going at it completely backwards
<T-Bone> elmo: how's Debian ia64 buildd doing? :}
<lamont_r> T-Bone: I don't think debian has purchased a single ia64 machine
<elmo> T-Bone: the Debian ia64 buildd is a) one of 3 ia64 d.o machines, b) faster than ours, c) has less to do than ours
<lamont_r> hell - _I_ have better ia64 machines at home than the data center has
<T-Bone> elmo: less to do?
<lamont_r> elmo: d) donated hardware
<elmo> lamont_r: well, that's a prerequiste for "d.o machine",but yeah 
* lamont_r must leave to get kids in about 5 minutes
<lamont_r> elmo: yeah
<T-Bone> anyway. I'm not making up the community. You (ex-)Debian folks know how it goes with Debian ia64 better than I do, I suppose?
<elmo> T-Bone: debian doesn't do daily installer builds, debian doesn't do live cd builds, debian doesn't have all our uploads, we have (modulo freezes) almost all of Debian's uploads
<ogra> lamont_r: wow, other ppl need 9 months for only one
<lamont_r> ogra: yeah, I know I'm good.
<T-Bone> elmo: fair enough
<lamont_r> :-)
<ogra> heh
<elmo> T-Bone: debian doesn't do random crack like "rebuild the archive to test it builds" or "build with gcc $v+1", etc.
<ogra> lamont_r: we all know that ;)
<lamont_r> elmo: speaking of which.... We really need to do that before preview
<T-Bone> in the end, what do you guys suggest?
<T-Bone> am I to continue that work as a loner?
<T-Bone> with no forseable release coming on the way?
<elmo> lamont: dude, I'm in the data centre on a friday night, I'm going to be here until the transport goes away.  I'm doing what I can
<mdz> T-Bone: as i have said from the beginning, the port needs a lead to take responsibility for getting it into shape
<mdz> T-Bone: no one said that you need to be that person, but someone does
<lamont_r> elmo: I know - I was just giving you ammo for help with prioritization... :-)
<mdz> we cannot "release first, find support resources later"
<mdz> if no one cares enough about the port to lead it, then that is a strong indicator that it may not be viable as an official port
<T-Bone> mdz: still, there's one thing I fail to understand: in your scheme, what happens if the community decides to drop support?
<mdz> T-Bone: if no one is willing to support it, then obviously it would need to be dropped
<T-Bone> ok
<T-Bone> well, as I see it, there's certainly a market place for a rock solid ia64 linux distribution
<T-Bone> now,
<elmo> Kamion: is there a daily for i386 with the 'server' stuff fixed, by any chance?
<T-Bone> one would have to bear in mind that the ia64 market is rather specific (a niche market, most likely), and that its users are also specific (universities, computing farms, massive calculations etc),
<T-Bone> now, if neither the manufacturers of the hardware, nor the makers of the distribution, nor the community at large are willing to take the bet and get involved,
<T-Bone> well, everything is rather pointless...
<mdz> the current 'makers of the distribution" have too much work to do already.  of course, there is always a place for someone new to become an Ubuntu maintainer and lead a new port
<mdz> but in this case, no one is willing
<T-Bone> i don't have much insight in the debian ia64 community, but I wonder who's putting up there, and why they aren't interested in Ubuntu...
<mdz> interest in Debian does not automatically imply interest in Ubuntu
<mdz> perhaps they are happy working on Debian/ia64
<T-Bone> mdz: to state things a bit clearly, it boils down to "get the users involved or get the manufacturers to pay people to get involved", as I see it?
* T-Bone feels a little bit like having been thrown under the fire front with promise for backup that never arrived ;-P
<EvaSDK> 'lo guys
<Gagatan> you're a development kit?
<EvaSDK> maybe :)
<Gagatan> ;)
<Gagatan> evolve with age perhaps.. like a good bottle of vintage port ;)
<T-Bone> mdz: anyway, if you haven't already, it'd probably be a good thing that you get in touch with Thierry at some point...
<mdz> T-Bone: I have sent email on several occasions, with no response
<T-Bone> mdz: at tsimonnet@yahoo.com ?
<mdz> T-Bone: is there something in particular I should speak with him about?
<T-Bone> mdz: well, he's supposedly the team leader you're looking for?
<mdz> I will check which address I used
<mdz> T Simonnet <tsimonnet@yahoo.com>
<T-Bone> strange
<mdz> I emailed 30th Nov asking about the status of various ia64 bugs
<mdz> I then emailed 24th Dec to follow up
<mdz> because all of the same bugs were still present
<T-Bone> mdz: may i suggest that you mail him again stating what are your expectations WRT team leading?
<mdz> On Tue, Nov 30, 2004 at 06:49:19AM -0800, T Simonnet wrote:
<mdz> > I'm ok with your proposal and would be glad to handle the IA64 port. 
<mdz> (I told him what my expectations were, and he said that he would take on the role)
<T-Bone> then if you think he's not living up to these expectations, maybe it's time to tell him directly
<jordi> Who is T Simonnet?
<T-Bone> i don't particularly like the idea of playing the 'man-in-the-middle'
<T-Bone> jordi: ia64 team leader
<mdz> T-Bone: I thought I was clear.  all of this happened over two months ago
<mdz> I did email him with my expectations, he did say that he would accept the role, I did email saying that my expectations were not met
<T-Bone> mdz: yeah, but if you don't have news in two months, maybe it's time to ring a bell? Or else what, are we waiting for the situation to rot?
<mdz> it was at that point that the ia64 port entered its current situations
<mdz> ia64 is not one of my priorities; I cannot be responsible for reminding the port leader of his responsibilities
<Simira> mdz: isn't Tollef handling the AMD64 part?
<Simira> port
<mdz> that is the idea of having a port leader, for them to keep track of issues and make sure that progress is made
<mdz> Simira: yes.  ia64 is a different port
<Simira> oh, ok
<HcE> Simira: ia64 is a totally different instruction set than x86-64
<T-Bone> mdz: your responsibilities doesn't involved keeping an eye on team leaders? They're supposed to auto-watch themselves? So basically if one leader fails at his task, nobody takes action?
<HcE> ia64 is a pure 64-bit processor
<mdz> amd64 is a good example of how this _should_ work
<Simira> hey, I'm just a clueless girl, you know. Never mind me sticking my nose into everything.
* T-Bone is typing very poor english lately :P
<Simira> :p
<HcE> T-Bone: correct with beer ;)
<sabdfl> T-Bone: mdz sets goals and strategy for the distro, the team either keeps up or their work doesn't make the cut
<T-Bone> hi sabdfl 
<mdz> T-Bone: I'm responsible for tracking the release goals; ia64 was not made a release goal because there was no one to lead the port
<sabdfl> hi all
<T-Bone> mdz: but maybe you should have complained about that on the mailing lists?
<T-Bone> because why would someone else stands up if noone's aware of the problem?
<tseng> T-Bone: if no one was aware, doesnt that sort of prove a point?
<dredg> T-Bone: so what's stopping you or someone else raising the same point on the mailing lists?
<tseng> that no one is taking any intiative to care for the port
<mdz> T-Bone: I truly appreciate the work that you have done on ia64, but I simply don't have the bandwidth to drive it in addition to my other work
<T-Bone> dredg: maybe because there's some kind of hierarchical relationship between me and the team leader (and not only in the community)?
<mdz> T-Bone: that includes searching for a new team leader
<T-Bone> mdz: heh. Glad to learn that at least I did something useful :}
<sabdfl> so what's the status on ia64?
<T-Bone> s/useful/valuable/ - The usefulness remains to be proven
<dredg> T-Bone: sorry, i'm not trying to step on toes or pick an argument, i was merely making a suggestion.
<T-Bone> sabdfl: well, kamion and I seem to thikn that, put aside the openoffice and firefox bugs, the port is in rather good shape
<sabdfl> ok
<mdz> it seems to be installable now, and the live CD recently became functional
<T-Bone> the openoffice issue is a matter of recompiling a package
<sabdfl> those are both good news
<sabdfl> is oo.o2 better?
<T-Bone> the firefox one just came out last week and seem a bit trickier
<mdz> my opinion is that ia64 could probably be made ready for hoary if someone with the necessary skills were able to devote a significant chunk of time per week to it
<T-Bone> oo.o2 isn't available yet on ia64, afaict
<mdz> as Tollef did for Warty/amd64
<T-Bone> mdz: that would certainly speed up things by several orders of magnitude
<mdz> but it is by no means a sure thing
<mdz> preview is less than three weeks away, and ia64 is still significantly behind the big three architectures
<T-Bone> i do not agree on the "significantly' there
<T-Bone> but it's only my opinion
<sabdfl> T-Bone: can you quantify that - do we have a per-architecture ftbfs list?
<T-Bone> afaict, everything works in Ubuntu-desktop except oo.o and firefox
<mdz> there are bugs in bugzilla for FTBFS on ia64
<T-Bone> sabdfl: the only ftbfs i'm aware for ia64 is libbonobo, and that's a bug existing in debian as well
<mdz> there are uninstallable packages on ia64; language-support-en was uninstallable the last time I looked, but that may have changed
<mdz> that would have been a side effect of oo.o being completely missing
<T-Bone> it is
<seb128> T-Bone: hum ?
<seb128> T-Bone: libbonobo is fine in debian afaik
<mdz> T-Bone: oo.o and firefox are two of the cornerstones of ubuntu-desktop :-)
<elmo> ia64 has 4 main packages in failed, 4 in building
* dredg snarfs an array-5 install iso for his laptop
<T-Bone> seb128: maybe i'm mistaking. You'd have to ask lamont-away about that
<seb128> elmo: libbonobo sync please
<elmo> one in dep-wait
<seb128> I've fixed the FTBFS in deb
<seb128> we just need to sync
<elmo> seb128: done
<seb128> thanks
<T-Bone> mdz: yeah i know, hence the efforts on them. oo.o should be trivial. Firefox looks a lot more tricky
<mdz> http://people.ubuntulinux.org/~cjwatson/testing/hoary_outdate.txt says 7 binaries are out of date, including libbonobo
<seb128> T-Bone: this one is fixed now :p
<T-Bone> seb128: heh thanks :)
<mdz> T-Bone: I think it is overly optimistic to say that it is trivial
<T-Bone> mdz: ooffice works with ia32 libs
<mdz> it is unlikely that anyone has started oo.o even once on ubuntu/ia64
<mdz> T-Bone: you have tested it?
<T-Bone> mdz: said otherwise: if you install ia32-libs and use the x86 installer it works
<T-Bone> mdz: i'm doing that (had to dl the big installer)
<mdz> T-Bone: what installer?
<T-Bone> mdz: that's what i've been told by debian folks
<mdz> the one from upstream?
<T-Bone> mdz: the official one
<T-Bone> yeah
<mdz> that is not the same thing as the Ubuntu package working
<T-Bone> mdz: sure. At least it means no need for code tweaking in oo.o
<T-Bone> and it means it can be done
<mdz> it has not even been built yet; in theory it could work, but the work has not even begun, much less testing
<T-Bone> mdz: the work has begun. See my questions about lib32gcc1 earlier today
<T-Bone> i need help in the ia32-libs package, but I'm trying to put up on my own
<mdz> Mithrandir worked with that package; he may be able to help you
<T-Bone> that'd be cool
<mdz> but the fact that you need help means that it is not trivial
<T-Bone> no 
<T-Bone> it means the package isn't trivial (the ia32-libs one)
<T-Bone> i have a grasp of what needs to be done. I don't know how to do it. That's fairly different :}
<mdz> if you don't know how to do it, it isn't trivial, by definition
<T-Bone> basically we just want ia32-libs to build a lib32gcc1 package.
<T-Bone> mdz: it can be trivial for somebody with knowledge in the mechanics of that package
<T-Bone> as it is trivial for me to write a new basic kernel driver, but it's not for everyone else :}
<mdz> T-Bone: I do not think that word means what you think it means
* ..[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 the latest kernel
<Simira> mdz: hm, does this mean I shouldn't upgrade hoary in a little while, when it still works?
* ..[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
<mdz> Simira: hopefully that answers your question :-)
<Simira> :p
<Simira> I've no idea of what kernel I have, but I'll check it tomorrow
<T-Bone> mdz: what i mean is that it *should hopefully* be a matter of adding the proper parameters to a package (ia32-libs) and put tarballs wherever needed, to get oo.o working on ia64. That's what I call trivial, by comparing to "fixing the firefox segfault" which is everything but simple and requires much more work.
<mdz>   trivial adj. 1. Too simple to bother detailing. 2. Not worth the
<mdz>      speaker's time. 3. Complex, but solvable by methods so well known that
<mdz>      anyone not utterly {cretinous} would have thought of them already. 4.
<mdz>      Any problem one has already solved
<T-Bone> :/
<T-Bone> it's my bad for having been used to relativise triviality of problems
<mdz> I'm sorry, but I need to work on some other things now
<mdz> if you would like to continue the discussion about ia64, I think it would be best to do it on ubuntu-devel where others can participate
<T-Bone> i've said pretty much everything i had to say
<T-Bone> and I won't post on u-devel claiming that Thierry isn't doing his work
<T-Bone> i just can't do that.
<elmo> anyone familiar with the installer over serial console?
* T-Bone did a few hppa serial installs but bets that won't help
<elmo> I'm just wondering if there's anyway to break out to menu, or otherwise get a shell
<T-Bone> 'get back' should bring you to menu iirc
<T-Bone> at least it did last time i checked that
<elmo> yeah, I'm stuck in a loop which doesn't have that
<T-Bone> ouch
<sabdfl> T-Bone: rather than pointing fingers, it would be great to summarise the work to be done
<elmo> oh, no, I'm not, I just needed to do it a ocuple of times - thanks
<T-Bone> elmo: heh :)
<sabdfl> i read that as "an occult of times"
<sabdfl> ths porting business is serious... voodoo.
<aj> "I'm caught in a loop... I can't break out... Because I'm installing Ubuntu, baby" ?
<sabdfl> schweet jaysus...
<T-Bone> sabdfl: i can do that, but I can only speak about my point of view. To me it seems that the only issues left are oo.o and firefox. mdz seems to think otherwise...
<sabdfl> "we can't go on together, with pernicious lines"
<mdz> I think that you haven't done a comprehensive investigation of the issues yet
<sabdfl> mdz: did i miss you laying out your concerns?
<aj> "and we can't run our system... with pernicious lines"
<T-Bone> i guess i'll mail a ia64 status as lamont did for hppa
<mdz> T-Bone: that would be good
<sabdfl> aj: how about some duelling elvis down under?
<mdz> sabdfl: I stopped paying attention to it in December when T Simonnet vanished.  Since then I have closed/deprioritized ia64-specific bugs, and excluded it from my radar
<T-Bone> mdz: certainly. Because: 1) i don't know how to perform such an investigation; 2) i don't have time for it and maybe 3) I don't have an incentive to do it :>
<aj> "i saw an old friend i know; whose system's running slow; is it because of pernicioun in the lines?"
<mdz> sabdfl: honestly, the fact that it has no leadership eclipses the technical issues
<T-Bone> mdz: that's something only you can tell on a mailing-list, imho
<T-Bone> that's a message that has to come from Canonical, who's the "authority" in such matters...
<mdz> that is a misconception
<ogra> T-Bone: canonical isnt ubuntu
<ogra> T-Bone: the community is ubuntu
<ogra> T-Bone: canonical only backs it
<T-Bone> who decides what has the "supported" stamp?
<T-Bone> that person should be the one complaining why it won't be giving such stamp to ia64
<sabdfl> T-Bone: mdz
<T-Bone> and that person is not me
<T-Bone> end of reasonning
<mdz> I don't understand your position.  You still seem to be saying that ia64 should be blessed first, then fixed
<tseng> sorry to jump into this, but you seem to be the one most miffed about it
<T-Bone> sabdfl: so i'm rephrasing my previous sentence: "that's a message that has to come from mdz"
<mdz> that is exactly the opposite of how the other ports work
<T-Bone> mdz: not at all. What I'm saying is that you're noticing a lack of leadership, and I'm just asking you to *state* it on the m-l
<T-Bone> (if you don't want to state it to Thierry directly)
<ogra> T-Bone: who should support it ? if it has this stamp if there is no team to do so
<mdz> T-Bone: I already told you that I _did_ state this to Thierry directly
<T-Bone> I'm saying that I can't be the one making such a claim, and one of the reasons i can't do that is that I have *no authority* to do so, while *you* have
<T-Bone> mdz: two months ago. Maybe it's time to let the community know about that?
<tseng> why cant anyone on the team acknowledge a lack a leadership?
<Simira> do one need authority to request work on a part of Ubuntu?
<mdz> T-Bone: you, as someone working on the ia64 port, surely know first-hand whether the port leader is effective
<T-Bone> tseng: maybe because all people involved in the (very small at that point) team have some external relationships with the leader?
<T-Bone> tseng: you know, that human factor...
<tseng> oh, so its a personal issue?
<mdz> T-Bone: at the time that the discussion was happening in November/December, you were unavailable, and now you have reappeared and are demanding an official ia64 port
<T-Bone> mdz: for christ sake, can't you understand?
<tseng> you hadnt mentioned that before that I've seen
<T-Bone> mdz: thierry is 40, i'm 24. That's a point. I owe him everything I know about quite a lot of things. I can't shoot him back
<T-Bone> is that clear enough?
<sabdfl> aj: "is your memory tight, are they blinken, de lights, are you sorry... we failed... to port?"
<sabdfl> guys, calm down
<T-Bone> mdz: i'm not demanding anything, please stop making me say things I don't
<sabdfl> T-Bone: is thierry at his desk these days?
<T-Bone> i'm demanding for an overview
<sabdfl> T-Bone: do you think you have the skills to get the final bits done, if you had an incentive?
<T-Bone> sabdfl: from 8 to 16 CET he should be yes
<sabdfl> T-Bone: is he a full time teacher?
<T-Bone> sabdfl: not within a reasonable timeframe if i have to acquire some extranous knowledge i don't have off-hand
<sabdfl> i suspect the issue is that Thierry was not expecting to be as hands-on as our other porting leads have been
<sabdfl> T-Bone: do you know someone with the necessary skills?
<T-Bone> sabdfl: he's not a teacher. He should be reachable from 8 to 11:30 and then from 12 to 16, I suspect
<mdz> sabdfl: I was very clear about my expectations in email, and he acknowledged them
<mdz> #1 on the list was to respond to ia64 bugs
<mdz> and as far as I can tell, no one other than lamont and I have responded to a single such bug
<T-Bone> sabdfl: the oo.o issue is a packaging one Mithrandir seems to know about. The firefox bug I could probably try to track down, but then it's not skills again, it's a matter of time
<sabdfl> firefox-on-64-bit is not trivial
<sabdfl> it's hard code
<T-Bone> true
<sabdfl> is everything else building fine?
<T-Bone> sabdfl: it seems so. Lamont wasn't complaining about any particular FTBFS
<T-Bone> (except the libbonobo seb128 just fixed)
<T-Bone> sabdfl: i'm working on ubuntu at nights from 19 to 01 and on weekends from friday noon to sunday night almost fulltime (except when I take a break with my GF, who has proved to be rather comprehensive lately :})
<T-Bone> still, i'm not very inclined to screw up all my free time just for the fun of it :->
<sabdfl> T-Bone: is there anything you can think that i can do to help ia64 happen?
* T-Bone brb, fetching chinese food from the microwave oven
<T-Bone> sabdfl: well, any progress on the cloning machine? :)
<sabdfl> waht what what?
<sabdfl> aj... shtoom?
<T-Bone> sabdfl: afaict (but it's always difficult to predict how long a bug will take to be fixed),
<T-Bone> oo.o might be fixed by the end of this week end if i can get some input from mithrandir in that time frame.
<T-Bone> fixed == packaged/built/tested/uploaded (assuming no undercover bug)
<sabdfl> Mithrandir: if oo.o2 can be made to build on amd64, it should build nicely on ia64 too, right?
<T-Bone> the firefox issue, i cna't tell yet
<sabdfl> firefox is just not designed for 64bit architectures
<ogra> T-Bone: Mithrandir is at FOSDEM this weekend.....
<sabdfl> it's a deep deep problem apparently
<T-Bone> sabdfl: i think so. How would you cope with that?
<T-Bone> sabdfl: mozilla works fine OTOH
<sabdfl> oh...
<sabdfl> seriously/
<sabdfl> ?
<T-Bone> seriously
<sabdfl> maybe i'm mistaken then
<T-Bone> epiphany seems to as well
<T-Bone> afaict, firefox was working fairly well until last week
<jordi> sabdfl: I'm sorry I haven't been able to reply to your request yet. It's hard to get an OK from the People At The Top
<Simira> ogra: yes, please tell him I miss him already, when you see him :)
<jordi> sabdfl: dunno if you spoke to carlos. I will know on Monday morning
<ogra> Simira: i'll do :)
<sabdfl> jordi: that's ok, i really appreciate your being willing to trek to london to help us make rosetta rock
<AndyR> are many of you going to fosdem?
<T-Bone> sabdfl: given i'm single-threaded so to speak, I can focus on one problem at a time. Depending on what you'd like i can investigate either oo.o or firefox this weekend
<ogra> i'll go only on sunday...
<sabdfl> T-Bone: ok, i have the wrong end of the stick w.r.t. firefox then
<sabdfl> i thought it was not doable at all
<jordi> sabdfl: nod. hopefully. I'd be glad.
<T-Bone> it should be
<jordi> And now, it's pub time.
<sabdfl> T-Bone: go for firefox, if it's a recent regression
<jordi> laters
<T-Bone> comparing between working and non working releases should help
<sabdfl> cheers jordi
<AndyR> quite a few from my local LUG going
<T-Bone> sabdfl: will do. Luckily I hadn't planned to sleep tonight :}
#ubuntu-devel 2005-03-09
<sabdfl> sleep does help
<T-Bone> heh
<dredg> AndyR: sadly not. i lack necessary funds atm :)
<AndyR> dredg, same here
<tseng> mxpxpod: hey
* dredg will instead be spending the weekend beating apps that depend on python with a Big Stick (tm)
<mxpxpod> thom: when did you start working on the pmi?
<mxpxpod> tseng: hey
<tseng> mxpxpod: did you by chance try my muine package in hoary?
<tseng> mxpxpod: i got a bug that says its b0rk on ppc, but only one report
<mxpxpod> tseng: yeah, but since polypaudio is being freaky, I can't listen to music right now
<tseng> you cant kill it and use alsasink?
<mxpxpod> hold on
<tseng> id hate to be out of music :P
<AndyR> polypaudio fixes sound in skype :)
<mxpxpod> tseng: ok, using alsasink, it works
<T-Bone> holly shit
<tseng> mxpxpod: hm so you didnt install anything extra?
<mxpxpod> tseng: no, not that I know of
<ogra> dredg: yeah MOTU power :)
<T-Bone> i just installed debian's mozilla-firefox package on my ubuntu box
<T-Bone> guess what
<T-Bone> it works
<T-Bone> looks like tracking the bug will be much easier
<tseng> mxpxpod: https://bugzilla.ubuntu.com/show_bug.cgi?id=6805 < this sounded fishy from the start
<tseng> mxpxpod: seeing as it works for you.. very fishy indeed.
<mxpxpod> ok, I gotta get going
<mxpxpod> what's thom's email addy?
<tseng> cya, thanks
<tseng> ill check the ml
<T-Bone> sabdfl: sounds promising
<tseng> thom@ubuntu.com works mxpxpod 
* T-Bone looks at ubuntu changelog
<dredg> ogra: well, for now catching up with the ones i sent to dh for review. i'm learning that caffeine + no sleep is not really conducive to working packages :)
<dredg> man i don't sleep enough
<ogra> yeah, thats a sideeffect....you get used to it ;)
<mxpxpod> thanks tseng 
<dredg> ogra: :)
<dredg> oh, and muine++
<dredg> especially if, like me, you like to listen to albums. damn nice.
<mxpxpod> tseng: yeah, I don't like how the alsa sink sounds... it can be very jerky
<mdz> haggai: ping, re: oo.o2
<mxpxpod> tseng: so I'm waiting for the polypaudio stuff to be fixed
<tseng> mxpxpod: k. thanks for testing though
<dredg> mxpxpod: really? i haven't used a sound daemon in a few years
<mxpxpod> dredg: ppc?
<aj> oh my, i didn't even know suspicous minds was an elvis song
<dredg> mxpxpod: ah, no :)
<mxpxpod> strange... gnome-volume-control is segfaulting
<jdub> tseng, mxpxpod: disable the alsa sink
<mxpxpod> jdub: huh?
<tseng> jdub: hm?
<tseng> oh in polypaudio
<tseng> not gst
<jdub> on ppc, disable the polypaudio alsa sink
<T-Bone> so it's either Pango or IDN at fault, afaics
<mxpxpod> jdub: I still get an assertion... it says something about the sink disconnecting
<mdz> jdub: what's the status of that bug which causes the login sound not to play?  is there a bug open in bugzilla?
<mxpxpod> I have to get going
<mxpxpod> jdub: I'll talk to you more about this tomorrow
<jdub> mdz: lennart is looking at it; don't think there is actually - i'll add one if not
<T-Bone> mdz: would it be possible that if the compiler blurped when building firefox, the package generated would have lived 2 weeks? ie, there's no "auto-rebuild-everything' yet, right?
<mxpxpod> tseng: btw, muine works great
<mxpxpod> no problems here
<tseng> mxpxpod: thanks dude
<tseng> ill quote you on that :P
* T-Bone will try to demonstrate that rebuilding the pristine mozilla 1-6ubuntu1 package will yield a working executable
<mdz> T-Bone: the most recent build was successful; successful builds are not retried
<T-Bone> ok
<T-Bone> mdz: i hope that's something like that
<T-Bone> mdz: that would explain why thom's build worked too
<haggai> mdz: pong, half completed message re oo2 in Draft folder
<T-Bone> maybe there's hope to fix these two issues during this weekend, after all...
* T-Bone is having high hopes while firefox is building
<haggai> mdz: mail completed and sent.  I had been looking at the gcj status
* T-Bone is having a message "this certificate belongs to bugzilla.ubuntu.com" when connecting to launchpad.ubuntu.com...
<remi`> night everyone
<sabdfl> night all
<dredg> night sabdfl 
<zul> hey
<zul> mdz: is it ok if we close those inotify related bugs?
<mdz> zul: if we still plan to move to inotify eventually, they should be downgraded but not closed
<zul> ok..
<mdz> zul: are there other bugs which should be reopened due to disabling inotify?
<zul> i can check
<zul> 7 i know of plus the one i have and the duplicates
<mdz> jdub,zul: was it dnotify->inotify which fixed the problems with being unable to unmount removable devices sometimes?  or was that fam->gamin?
<zul> i was able to reproduce the problems with fam->gamin
<zul> i didnt have a usb key with me to test the unmounting removable drives since i was at work at the time
<mdz> zul: I've done a little testing with noinotify, and I don't seem to have the old problems of being unable to unmount
<zul> mdz: 2.6.10.4-23?
<ajmitch> hm, no elmo around to request sync
<mdz> zul: yes
<mdz> ajmitch: email works
<ajmitch> mdz: yes, there is that
<zul> mdz: ok ill put it on my todo list this weekend
<seb128> mdz: gamin is less bugged than fam in this area but inotify really fixes the issue
<zul> seb128: by keeping inotify off?
<seb128> <mdz> jdub,zul: was it dnotify->inotify which fixed the problems with being unable to unmount removable devices sometimes?  or was that fam->gamin?
<zul> k
<mdz> :-(
<seb128> about this
<mdz> so now we will encounter those problems again, since we have disabled inotify
<seb128> inotify doesn't need to open a fd on the device
<ajmitch> mdz: upload@u.o?
<seb128> probably ..
<T-Bone> hmm
<T-Bone> so here it is:
<T-Bone> mozilla-firefox works fine as long as you don't install any locale packe
<T-Bone> -e
* T-Bone wonders if that could be related to the fact that language support is missing
* T-Bone is highly tempted to think so
<T-Bone> confirmed
<T-Bone> firefox 1.0+dfsg.1-2 segfaults the same way while it works just fine on my debian system
<mdz> zul: do you have a master bug for the hang-on-unmount issue with inotify?
<mdz> zul: 6877 is a duplicate of it
<T-Bone> mdz: just fyi, seems that oo.o is also somehow the culprit for the mozilla bug...
<zul> mdz: no i dont ill create one right now
<zul> mdz: #6929.
<jdub> seb128: inotify fixes that
<lamont> T-Bone: interesting
<jdub> seb128: when it's not hanging your kernel ;)
<seb128> jdub: <seb128> mdz: gamin is less bugged than fam in this area but inotify really fixes the issue
<seb128> jdub: yeah :)
<jdub> yeah :)
<jdub> heh
<jdub> so, i think we should pull in inotify updates
<T-Bone> lamont: a good way to check that would be to try removing language packs on a known working hoary box (x86/ppc/whatever) and see if installing a mozilla locale kills it the same way
<jdub> but i'm not too worried if we disable it for the release
<T-Bone> lamont: if it does then we're all setup -ENOTIA64BUG, if it doesn't then it's ia64-specific but not mozilla specific, probably something weird in the language support system
<T-Bone> my bet is on the first case
<seb128> jdub: is there a working inotify ?
<jdub> seb128: rml's doing lockless work that will arrive as 0.20 most likely
<seb128> jdub: the gnome-control-center's maintainer in debian works as a kernel guy for mandrake and according to him they don't have such issues with new versions
<seb128> jdub: I'll poke him again
<jdub> seb128: 0.19?
<zul> jdub: got an idea when 0.20 when?
<jdub> zul: i'll ping rml for info
<zul> k great
<seb128> jdub: I spoke with him like 1 week ago and according to him they have fixed their issues with inotify
<jdub> seb128: hrm, rml may have folded it in to 0.19 updates
<jdub> hmm.
<jdub> seb128: cooker kernel?
<seb128> I think he's working for 10.2 
<seb128> dunno how they handle the different branches
<jdub> cooker is their devel branch
<mdz> zul: thanks
<jdub> zul: perhaps check what mdk are doing in cooker
<seb128> yeah, but they are probably already frozen for 10.2 ?
<jdub> seb128: no idea ;-)
<jdub> hopefully they have public srpms though
<jdub> rml isn't around atm
<mdz> jdub: who should own gnome-app-install bugs in Bugzilla?
<jdub> mdz: me, might switch owner/qa to me and ross later
<jdub> zul: email?
<zul> jdub: zulcss@gmail.com
<jdub> zul: mailed rml, cc'ed you :)
<zul> thanks
<zul> mdz: is it possible to add the kernel-team so when there is a bug report for the kernel that they get notified as well?
<jdub> we can add kernel-team to the qa contact for the kernel packages
<jdub> can do now if you want
<zul> sure
<mdz> zul: sure, what is the email address for the kernel team?
<jdub> mdz: doing atm
<mdz> ok
<jdub> (kernel-team@lists.ubuntu.com btw, which you should probably join :)
<zul> heh..alrady on
<lamont> thanks jdub/mdz
<jdub> do you want l-r-m too?
<zul> lamont: ^^^
<lamont> jdub: I thought that was daniels...
<jdub> should it be kernel team?
<lamont> those tend to mostly be X borkage, although some firmware stuff finds its way in there
<lamont> if daniels thinks so, I agree
<lamont> I don't want to steal it from him and all that. :-P
<lamont> bbiam
<jdub> ok, only changing qa contact for now anyway
<jdub> ahar!
<jdub> time to go to codefest
<jdub> where tehre will be lots of ubuntu usres
<lamont> time to feed horses
<jdub> and ubuntu a11y hacking :)
<zul> bbl
<elmo_> $ su - 
<elmo_> Sorry.
<elmo_> hmm.
<mdz> elmo_: context?
<jdub> mdz: would we regard udev not even installing or upgrading on 2.4 systems as NOTUBUNTU?
<elmo_> mdz: sarge  -> hoary; it's the usual libc6 upgrade fux0rs libnss-db
<mdz> jdub: I think we would need to fix that in order to support upgrades from 2.4 systems
<mdz> elmo_: I thought that typically only fux0red running processes
<elmo_> mdz: until make is rerun, libnss-db stuff isn't recognised, for new or running processes
<elmo_> heh, libc6.1 is 'optional' in our overrides
<elmo_> mdz: it's not disastrous, as long as you have a privleged non-libnss-db account or a cron'ed regeneration.. 
<jdub> mdz: yeah, i now have a linode (uml), and stuck without ubuntu-base due to udev
<jdub> (though after that, i removed most of ubuntu-base for space reasons)
<dredg> reminds me, must build a ubuntu fs for uml
<mako> someone want to take a look at this before i send it out? http://www.ubuntulinux.org/wiki/UbuntuDownUnder
<mako> go ahead and makes changes to ti
<jdub> mako: when do you want to send it?
<mako> i'm writing up the announcement now
<mako> i'll be ready in like 15-20 minutes max
<jdub> hrm
<mako> want to wait?
* lamont is back 
<jdub> nah, not worth it
* ajmitch reads 
<mako> what would we wait for?
<ajmitch> where in Sydney will it be?
<jdub> ajmitch: rushcutters bay
<ajmitch> joy, ANZAC day in .au
<jdub> ajmitch: south of the harbour, near potts point
<ajmitch> alright
<jdub> so we can perve on celebs
<mako> jdub: we want to set a deadline for sponsorship that's mid-march
<ajmitch> mako: ah, there will be sponsorship?
<jdub> mako: just thinking about missing info, but we can fill that in later, not important right now
<mako> ajmitch: yes
<mako> ajmitch: it's in the page :)
* ajmitch must have an old page in the cache :)
* dredg will not be attending (unless someone wants to donate heavily to the dredg fund) ;)
* ajmitch is hoping to attend
<dredg> ajmitch: you're in the right hemisphere at least :)
<ajmitch> dredg: just a quick hop across the tasman..
<ajmitch> pity about the steep sydney airport taxes though
<ajmitch> jdub: how far from there to lewisham? :)
<jdub> not far really
<jdub> 20min drive?
<ajmitch> great, there's some people there I want to meet up with
<jdub> without traffic
<jdub> but being sydney... :)
<mako> so many australians...
<jdub> sydney's a country town compared to LA
<jdub> NY
* mako has one at his house already
<ajmitch> well I got used to a 1hr+ commute into the CBD from where I was staying in melbourne
<mako> it's like the frog in hot water technique
<mako> jdub: think i should send this announce?
<mako> jdub: to -announce even
<mako> jdub: or -news
<jdub> announce
<mako> cool
<jdub> silbs asked you to?
<mako> it was implied
<jdub> heh
<mako> but it seems sensible
<jdub> worth announcing "conference will be here, on these dates, more info to come" anyway
<mako> and "if you want sponsorship, this is the place to sign up"
<jdub> AEROBUCKS HERE --->
<mako> we'l have a list of interested people to mail with new information in the future
<ajmitch> hm, should I consider applying?
<mako> ajmitch: yes
<jdub> ajmitch: priority goes to people in the region, so yeah, hell yeah
* ajmitch adds his name
<mako> last time, *most* people who applied got funding
<HrdwrBoB> daniels is not allowed to go >:|
<HrdwrBoB> our wedding is on the 30th
<jdub> our being you and daniels? :)
<HrdwrBoB> <3
<mako> does daniels know about this?
<mako> his imminent matrimonial state
* T-Bone fortunes
<jdub> imminent? dude, he's married to ME
<HrdwrBoB> :o
<HrdwrBoB> he never told me that
<jdub> he didn't want to < 3 your <3
* ajmitch grovels for $
<jdub> wifi is slow
<mako> daniels: fscking bigamist
* mako just read "wifi" as "wife"
<ajmitch> jdub: yes, I just rsynced a few hundred MB of ubuntu packages via 11b
<ajmitch> painful
* jdub is doing i386 install/live cds atm
<jdub> thought i'd be out of here already
<mako> ok.. i'm gonnna announce this shindig
<zul> back
<ajmitch> wb zul 
<mdz> 1306 kept, 463 moved, 490 deleted.
<mdz> ubuntu-bugs is winning
<T-Bone> gah, my eyes are closing :P
* T-Bone calls it a night
* lamont heads off to class for a while
<cleaverAlf> i just received a STACK of Ubuntu in the mail but neither the LiveCD or Install CD will run on my little test system.  Gigabyte MB GA5-AX, Adaptec 2940UW scsi controller, 18gb scsi 3 disk, 6x scsi CDRW, vodoo3 video card and Viewsonic 17GL monitor, and AMD800Mhz Athalon cpu.
<mdz> cleaverAlf: file a bug report at bugzilla.ubuntu.com with exact details about what you tried, and how it failed
<cleaverAlf> np..  thanx..
<zul> i 2.4 actually supported?
<zul> gah...stupid keyboard 
<davyd> zul: no, since you need /sys to use HAL
<whiprush> too late in the freeze for mutt-ng?
<jdub> whiprush: ha ha
<whiprush> hey no laughing, I've fixed 2 lintian errors on it already. :p
<jdub> whiprush: certainly a universe candidate candidate :)
<whiprush> yeah, obviously
<whiprush> I didn't mean in main
<whiprush> heh
<ajmitch> jdub: got any word on freeze dates for universe?
<ajmitch> like how much slack we have to get new packages in, python pkgs transitioned to 2.4 :)
<dholbach> ok pals... i'm off to bed
<dholbach> it's 4:44 already
<dholbach> *yawn*
<ajmitch> night dholbach 
<dholbach> sleep tight
<dholbach> *wave*
<zulzzz> hey ogra 
<mdz> jdub: they're using 2.4 UML?
<jdub> mdz: yeah, they have an experimental 2.6, but mostly 2.4
* lamont heads to sleep.  busy day tomorrow, for at least the first several hours.
<Kamion> morning
<daniels> g'morning
<sid77> hi
<dholbach> hai
<dholbach> now this is funny: just for the fun of it, i started using arabic locale in gnome, but seems like loads of apps didnt understand to switch back the orientation, when i switched back to german (some still have arabic captions)
<dholbach> wow
<_d4vid> http://www.francesfarmersrevenge.com/stuff/archive/news/archive/parishiltonaddressbook.htm
<tritium> ajmitch, you around?
<ajmitch> yes, I am
<dholbach> hi tritium!
<dholbach> hi ajmitch!
<tritium> hi dholbach
<tritium> :)
<ajmitch> hey dholbach 
<dholbach> woohoo! MOTU power! :-)
<tritium> I'm really close here.  I switched to cdbs, and I can't seem to exclude the package's files from the -doc package.
<ajmitch> ok..
<ajmitch> tritium: are the same files being installed into both packages?
<tritium> ajmitch, yes, except for those I designated with DEB_INSTALL_DOCS_package-doc
<tritium> those are only placed in the -doc package
<ajmitch> right
<ajmitch> take a look at dh_install manpage
<tritium> ok
<ajmitch> time for me to go & sleep, sorry :)
<tritium> me too.  It's 6 a.m.  I need a little nap before I start my day.  Thanks for your help :)
<ajmitch> heh
<ajmitch> night
<tritium> night
<dholbach> sleep tight you two
<dholbach> tritium: you uploaded the last package?
<dholbach> can somebody confirm march 3rd as previewFreeze date, if i didnt get the schedule wrong?
<T-None> dholbach: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<abelli> ciao a tuti
<abelli> enrico: xiao ming
<abelli> could you please tell me if k3b will be removed from hoary?
<dholbach> T-None: how do you read it?
<T-None> seems preview freeze is scheduled for feb 28
<T-None> ie next monday
<dholbach> T-None: actually all dates are due to wednesdays
<dholbach> hi dredg 
<dredg> lo dholbach 
<T-None> that would make sense then, I've been told PF is scheduled for march 2
<dholbach> oh yes.. the 2nd
<T-None> (kamion told me so)
<dholbach> thanks
<T-None> np
<dholbach> need to set up MOTUTodo for it
<dholbach> jdub: ping
<sivang> hi all
<dholbach> hi sivan
<dholbach> brb
<sivang> just came to see what's news, be back later also
<svenl> hi Kamion ...
<svenl> anyway, hi guys.
<svenl> I am asked by my management how support for hoary officially stands in ubuntu for the pegasos.
<svenl> Regarding an announcement that we will be making on monday or something such for which i can't really give any detail.
<svenl> Now, as far as my understanding goes, current ubuntu/hoary fully supports the pegasos provided i fix the OF implementation to work with yaboot.
<svenl> And then only two minor details need fixing : the marvell gigabit ethernet driver in the ubuntu kernel, and some X issue i mentioned DanielS.
<svenl> So, i am wondering what the official ubuntu position is on this matter ?
<svenl> (or who i could write about this).
<abelli> ogra: ciao
<svenl> oh well, will ask again later.
<abelli> sivang: hey
<trukulo> hi ppl
<sladen> svenl: ping Kamion
<sladen> svenl: alot of people are currently at FOSDEM so things maybe a little laggy
<abelli> sladen: are you going there?
<svenl> sladen: ah, ok.
<T-None> morning elmo_ 
<abelli> who is in belgium right now?
<elmo_> T-Bone: hi
<T-Bone> elmo_: i've posted some status update about ia64 on the m-l, feel free to comment it as you see fit. I have notably not said anything about the livecd, since i haven't tested it in a while...
<elmo_> T-Bone: ok
<T-Bone> thx
<elmo_> *.ubuntu.com's going down for kernel upgrade, bb in a few minutes
<abelli> ogra: are you here?
<abelli> ogra: problems with graveman for warty.
<ogra> abelli, sorry, that package is very outdated, i will build a new one after preview release (before i'm very busy with hwdb)
<abelli> ogra: no worries..
<abelli> ogra: we can do it for you..
<abelli> ogra: you will need just to check for it to work
<abelli> btw how's hailie?
<abelli> hal?
<ogra> missing the last patch....(dmidecode/bios data) 
<ogra> will hopefully get included on monday
<abelli> is there any documentation about it?
<ogra> not yet
<abelli> where did you study?
<ogra> hal ?
<ogra> i looked at the code and patches of other ppl
<abelli> nice
<abelli> ...wonderful
<abelli> ...dont hate me for this..
<ogra> ?
<abelli> what is hailie meant to do?
<ogra> http://www.grawert.net/hwdb_schema.png
<abelli> hooray
<tseng> ogra: hm
<abelli> ogra: thanks
<ogra> it collects the hwdata on your system....asks some questions and submits the data online
<ogra> ...oh, and performs sometests....
<abelli> ogra: what kind of tests?
<ogra> the hoary variant will be rather trivial.....but the base for a much greater system in hoary+1
<ogra> something like: "do you hear this sound ?" (to test the sound hw).....or a ping to the first gateway to test the network config
<zulzzz> ogra: i think #6934 is for you :)
<ogra> zul: hey, thanks :)
<dholbach> abelli: when you finished graveman, i can review it too
<dholbach> abelli: hope you mean hoary :-)
<jdub> elmo_: ping
<abelli> dholbach: no ElephantHog
<abelli> dholbach: hoary+5
<sladen> abelli: looking around, I think sladen, mjg59, Kinnison, daf, Treenaks, Riddell, Mithrandir are in Brussels.  Along with about 10,000 Ubuntu CDs...
<abelli> sladen: can you buy me a tshirt from the gnu project?: )
<elmo_> jdub: ?
<dholbach> jdub: i'm sure you're quite busy, but do you think there's a way to put the ubuntu-love crowd to something like  http://www.ubuntulinux.org/wiki/MOTUTodo  more explicitly?
<jdub> elmo_: just checking if you're around - please watch the new queue ;)
<jdub> dholbach: feel free to modify the UbuntuLove page :-)
<jdub> dholbach: there's a line about MOTU there
<ogra> dholbach: btw, could you reparent it to MOTU ?
<dholbach> jdub: could you add it to the channel's topic?
<dholbach> ogra: erm... if you told me how? *blush*
<dholbach> jdub: thanks :-)
<ogra> hmm, never did it, but it should be possible....
<dholbach> i'll ask the MOTU gang
<ogra> done
<ogra> dholbach: you can do it at the bottom of the page.....enter the new parent and click reparent
<dholbach> oh... i'll have a look - thanks
<dholbach> seb128: ping
<seb128> pong
<dholbach> seb128: shall i take care of the ruby-issue?
<seb128> if you want
<dholbach> seb128: ok... will do later, after i reviewed dredg's packages
<dholbach> seb128: thanks for pointing out - you're awesome
<seb128> you're welcome :)
<trulux> default python for hoary is 2.4
<trulux> right?
<tseng> right.
<trulux> ok
<dredg> dholbach, nautilus-python too :)
<trulux> any recommendation on python dependencies fullfilling?
<trulux> seems that python does not come with libselinux bindings
* dredg would like to thank everyone who uses dh_python and ${python:Depends}... you've been wonderful. truly, truly wonderful.
<dholbach> dredg: you're so funny :-)))
<dredg> dholbach, there's still so much to do on the python transition :-/
<dholbach> dredg: we'll manage... really, don't exhaust yourself 
<dholbach> dredg: you're doing fabulous work
<dredg> dholbach, just did a test build of zapping here. it appears to use python2.4
<dholbach> dredg: i'm on amd64, so i ran into trouble
<dredg> aha
<dholbach> dredg: but can do another test tonight
<karim> hi
<karim> I use ubuntu powerpc
<karim> the kernel udpate tries to use quik to configure the boot bloc, however I prefer yaboot
<karim> is that a deliberate choice ?
<trulux> err
<trulux> I wonder if upgrading from warty to hoary right now is realiable
<zul> trulux: why do you say that?
<dredg> trulux, yes. for certain values of reliable.
<trulux> zul: I want to do it :)
<zul> then do it :)
<HiddenWolf> go girl! :)
<zul> right...ill be back later this afternoon
<trulux> elmo_: ping
<trulux> zul: just I want to know if minimal desktop applications work
<trulux> I mean
<elmo_> trulux: ?
<trulux> elmo_: I've talked with mdz on creating an ubuntu-selinux and ubuntu-selinux-devel mailing lists
<trulux> elmo_: he commented you're the man to ask, if so, are you proud?
<elmo_> trulux: err, no he didn't, he said jdub was the person to ask
<trulux> arr
<trulux> yeah
<trulux> sorry
<trulux> jdub: ping
<trulux> ajmitch. ping
<trulux> any rep. with python2.4 for Warty?
<HiddenWolf> trulux: no
<trulux> ok
<trulux> anyways, now works for both
<dholbach> hi sabdfl 
<Mithrandir> sabdfl: yes, I would imagine if ooo works on amd64, it should work on ia64 as well
<dholbach> catch up with you later... need to get an hour of sleep
<dredg> just looking over the buildd log for blender.. has anyone seen this one:
<dredg> ccache: failed to create (null)/.ccache (No such file or directory)
<dredg> ah, google to the rescue
<SuperL4g> On a whim I decided to download the latest Hoary install CD.  I have to say... you guys ROCK. :)
* dredg kills scons, ccache in the face
<dholbach> dredg: give it some nice kicks like thom did on firefox too :-)
<trulux> anybody here can tell me how to install python bindings within a package? even dh_python if it's what needs to be used
<trulux> ?
<elmo_> heh
<elmo_>  /dev/sda2 has gone 2613 days without being checked, check forced.
<mdz> thom: around?
<trulux> dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
<trulux> hah
<dredg> trulux: man dh_python
<doko_> trulux: what do you mean with "within a package"?
<trulux> nah, done
<trulux> dredg: ?
<trulux> dredg: referring to the unk. subs. message?
<dredg> trulux, yeah
<trulux> dredg: ah, ok
<trulux> :)
<gnii> could someone recommend a high spec laptop that is most compatible with ubuntu. I'm after something semi-portable but not a desktop replacement.
<mdz> gnii: check the HardwareSupport page in the wiki, or ask on #ubuntu or ubuntu-users
<gnii> mdz: thanks, I have looked at a lot of support pages, it seems ibm is a good bet but. I am on ubuntu now and getting some feedback, many thanks
<Nigelenki> is magical free root access a #ubuntu or #ubuntu-devel issue?
<azeem> it might be an FAQ issue, if it involves sudo and typing your password
<Nigelenki> azeem:  gksudo running ethereal
<Nigelenki> if I gksudo in a terminal, it asks for my password
<Nigelenki> if I then click cancel and hit applications->internet->ethereal (as root), it runs ethereal, as root, without asking me.
<sabdfl> hi dholbach
<Nigelenki> and i'm liek
<Nigelenki> "Wait wtf it doesn't want my password?!!!!"
<sabdfl> Mithrandir: ok, thanks.. that solves one issue, we need oo.o2 building on amd64 anyhow
<sabdfl> Nigelenki: please file a bug, assign to pitti
<sabdfl> hey mdz
<Nigelenki> sabdfl:  will do
<Nigelenki> sabdfl:  at connonical right?
<Nigelenki> cannonical
<dredg> Nigelenki: bugzilla.ubuntulinux.org
<sabdfl> i hope we aren't connonical ;-)
<sabdfl> so does everyone else on this adventure
<Nigelenki> dredg:  yes I mean to assign to martin.pitt
<T-None> hey sabdfl!
* T-None is not really here, just waving around
<sabdfl> hey T-None
<mdz> sabdfl: morning
<sabdfl> somewhere, yes
<T-None> sabdfl: i sent a report on the m-l, as we discussed yesterday. I hope this helps having a clearer view
<mdz> Nigelenki: that is not a bug; it's a feature
<mdz> please don't file in bugzilla
<Nigelenki> mdz:  a feature that continuously gives root without password when it's apparently no longer cached?
<dredg> does it actually give root?
<Nigelenki> mdz:  Should I be able to gksudo in a terminal without being prompted for my password?
<mdz> Nigelenki: yes, if you successfully used gksudo or sudo in the past 15 minutes
<Nigelenki> dredg:  Yes, I believe.  As root i can see net adapters in ethereal; as non-root, I don't see any.
<Nigelenki> mdz:  MY symptoms are that in the terminal, gksudo asks for a password (which I don't give; I click cancel); and at the same time, I can click the ethereal menu entry and it gives the process root without asknig me for my password
<mdz> Nigelenki: the timeout is per-terminal
<Nigelenki> hmm.
<mdz> if you run "sudo -k", you'll find that it starts prompting you again
<Nigelenki> but the last place I actually entered my password was text terminal
<Nigelenki> bluefox@icebox:~$ sudo -k
<Nigelenki> App -> internet -> ethereal (as root)
<Nigelenki> doesn't prompt me.
<mdz> it certainly does prompt me
<Nigelenki> well it doesn't ask me shit o.o
<mdz> hmm, sudo -k doesn't seem to clear the timestamp for other terminals
<mdz> at any rate, it's just normal credential caching; it isn't magic root
<sabdfl> T-None: did you get my mail cc to Thierry?
<Nigelenki> mdz:  I'll leave it for 15 mins
<mdz> Nigelenki: or sudo rm -rf /var/run/sudo/bluefox
<T-None> sabdfl: yeah i swa that
<T-None> sabdfl: let me know if it remains un-answered, but I doubt it will
<cartman> is archive.ubuntu.com not working?
<cartman> can't connect to it
<Nigelenki> mdz:  indeed, you're right, false alarm.  Apparently sudo updates the timestamp every time it's run
<Nigelenki> so I could continue using it to "keep my root access alive"
<Nigelenki> (`sudo true` every 10 minutes say)
<Nigelenki> which is what happened with me running ethereal every 10 minutes to see if it'd prompt me yet  guess
<dredg> is anyone aware of any packages in ubuntu (apart from blender) that use scons to build?
<Allen> can some here help me out with this small prob
<Allen> i got ubuntu runnin
<Allen> but then i dont have any loop devices
<Allen> do i have to use mkdnod
<Allen> or is there a way i can get the loop devices made
<trulux> I need pitti now
<trulux> :)
<trulux> gcc-hardened may be ready for tomorrow
<kent> Allen, have you loaded the module for loop-devices?
<Nigelenki> hey
<Nigelenki> when will firefox 1.0.1 be available
<Allen> i dont think so
<Allen> i am not sure
<Nigelenki> ubuntu seems to use some 1.0dfsg thing which i assume is 1.0 plus backported fixes
<Allen> but then Mr Kent......is the module available...i am sure it is
<Allen> if u can let me knw...it did be great
<trulux> head: `-1' option is obsolete; use `-n 1'
<Nigelenki> there appear to be several security vulns in 1.0;; I haven't read the USNs lately to see if they've been patched for ubuntu
<kent> Allen, i think you can load the module with the command modprobe.  So, try with "modprobe lo" (make sure modprobe is in $PATH or run it with /sbin/modprobe or whatever the place is
<kent> Allen, that is, im not 100% that the module's name is "lo" but i think so. 
<Allen> ya
<Allen> i shall try that
<kent> Allen, then i think you can mount a loop-device with "mount -o loop  file.dat /media/mountplace" or something like that. 
<Allen> i have a crampfs image
<Allen> i am trying to mount it using this command
<dredg> Nigelenki: 1.0.1 will be ready when it's ready
<Nigelenki> yeah usn 85-1 covers the gaim vulns but not the firefox "firescrolling" :)
<Nigelenki> dredg:  packagers busy, or having problems making it work?
<Allen> mount /path/ofthe/imagwe /mount/point -t ext2 -o loop=/dev/loop1
<kent> Allen, ok. But first, make sure the "lo" module is loaded. Then, mount it with "mount -o loop /where-crampfs-file /media/mountdir"
<Allen> bingo
<dredg> Nigelenki: or maybe he's working on other things. i dunno
<kent> Allen, did it work?
<Allen> yes
<Allen> thanks
<kent> Allen, great :)
<Nigelenki> dredg:  As long as you're aware of the issues.  I'm just now looking at the past few days' bugtraq on several vulns
<Allen> now i ubuntu feels much better
<Allen> thanks a lot Mr kent
<kent> Allen, your welcome! :)
<kent> Allen, by the way. I missed that you was talking in #ubuntu-devel,  please ask things in #ubuntu instead. This channes is for actuall talks about Ubuntu development.
<Allen> well i am sorry for bein here
<Allen> but then there i cud not find any help for long hours
<Allen> so i just tried my luck here
<Allen> next time i shall make sure of this
<Nigelenki> dredg:  in particular http://www.securityfocus.com/bid/11474?ref=rss and http://www.securityfocus.com/bid/10832?ref=rss (which seems to be http://www.securityfocus.com/archive/1/391559?ref=rss which requires flash and works on fedora core)
<kent> Allen, its ok. But we should respect this as a devel-channel, and not disturb those who make Ubuntu as good as it is. :)
<Nigelenki> I think there may have been a fix as well for the new dns spoofing  thing or whatever it was, that affected all browsers *except* internet explorer (which didn't support the feature that was being exploited)
<Allen> i am sorry 
<Allen> i shall note that
<Nigelenki> anyway
<Nigelenki> I'm done.
<mxpxpod> hey guys
<Gorth> Are anyone able to download this file: http://cdimage.ubuntu.com/weekly-dvd/current/hoary-install-i386.iso
<abelli> how can i change the root partition when booting warty live cd?
<amu> root=/dev/xxxx
<amu> or you want change on a running livesys your rootfs? 
<abelli> mmm a friend has a badly broken kernel
<abelli> i need to reinstall it
<abelli> amu: and i ... ... im sorry, i dont know how to use your cd
<amu> abelli: boot it mount your partion, chroot in it, fix your kernel, go out from the chroot and run lilo -r /mountpoint ; reboot   
<abelli> amu: we use grub:)
<amu> than forget lilo, if you edit menu.lst that's enough
<mxpxpod> jdub: ping
<mxpxpod> jbailey: ping
<dredg> hmm, is this occuring for anyone else using muine? time elapsed is fine but when playing an ogg the total time for that track is 0:00
<dredg> for an mp3 the total time displays fine
<dredg> bah. works fine now that i've nuked ~/.gnome2/muine
<trulux> jdub: there?
<trulux> mdz: we are working on the new package, just did a hack for the rename-pkgs.sh script in gcc sources, maybe I should submit it
<trulux> mdz: also, what are your final thoughts on the mailing lists?
<jbailey> mxpxpod: Here, but hanging out with a friend.  What's up?
<mxpxpod> jbailey: what was the solution for the icon caching thing?
<jbailey> Dunno..  sb said it was fixed in upstream CVS.  Some padding issue.
<mxpxpod> ah, ok
<trulux> tritium: hey
<tritium> trulux, hi
<trulux> tritium: how are you doing!?
<tritium> trulux, I'm fine, thanks.  You?  (I'm in Chicago today)
<trulux> tritium: sounds great :) I'm fine, i was (and currently too) working on gcc-hardened, the paper, the selinux-support package, etc
<tritium> trulux, nice.  I hope the paper goes well.  You plan to finish it today?
<trulux> tritium: dunno, I need to work hard at it, many things remaining unfinished :(
<trulux> tritium: unexpected need of History studying :)
<tritium> trulux, I won't be around much today.  I'm taking my wife out tonight.
<trulux> tritium: that's good :) I will try to have something more done before you go
<tritium> trulux, I'm here already actually.  Mind if I get back in touch with you tomorrow night?
<trulux> tritium: sure, NP
<trulux> I will be for sure
<tritium> Great.  Talk to you later!
<trulux> tritium: take care!
<tritium> trulux, You too.  Bye.
* tritium is away: I'm busy
<zul> hey
<trulux> zul: hey hey
<trulux> zul: cable for dcc there?
<trulux> capable
<zul> so did you upgrade turlux
<zul> sure
<mdz> trulux: one mailing list for selinux/mac/proactive security stuff should be sufficient
<trulux> mdz:ok
<trulux> zul: not yet
<zul> k
<cybrjackle> what version off gcc is array-5 spun with?
<cybrjackle> i was looking for some release notes but didn't see any
<cybrjackle> nvm, distrowatch shows 3.4.3 anyway
<trulux> http://pearls.tuxedo-es.org/selinux/debian/selinux-support/
<trulux> zul: http://pearls.tuxedo-es.org/selinux/debian/selinux-support/
<zul> cybrjackle: you can find out by doing gcc -v on the livecd
* cybrjackle downloading it now :D
<zul> trulux: ill try it out on a chroot later ok?
<trulux> zul: ok
<cybrjackle> trulux, what is that package for?
<cybrjackle> is ubuntu going to have like a targeted-policy like fedora by any chance?
<trulux> cybrjackle: I don't think on a targeted policy like FC
<zul> but now i must have dinner
<cybrjackle> trulux, what does the selinux-support package you linked up there for?
<cybrjackle> nvm, read the .changes file
<trulux> cybrjackle: installs all the needed packages for userland support of SELinux
<cybrjackle> i tried to install selinux packages when ubuntu first came out and there were dep problems with some and it ended up being a bug somewere down the line that someone wasn't fixing from debian
<cybrjackle> if i remember correctly, that was awhile back
<sid77> hi
#ubuntu-devel 2005-03-10
<zul> hey mjg59
<dholbach> re
<mjg59> Argh. The wireless here is dreadful.
<mjg59> zul: Hi - sorry, I haven't had a chance to get back to you about those patch e
<mjg59> es yet
<zul> mjg59: its ok...im going to be added some of the asus ones in my next upload
<mjg59> zul: Do you have a link?
<zul> yeah gimme a sec.
<dholbach> anyone feels like testing hula-server package?
<dholbach> herzi made them and hosted them on http://www.blaubeermuffin.de/packages/hoary/source/
<zul> mjg59: http://linux.bkbits.net:8080/linux-2.5/anno/arch/i386/kernel/dmi_scan.c@1.76?nav=index.html|src/|src/arch|src/arch/i386|src/arch/i386/kernel
<zul> hey elmo
<elmo> hi zul
<mjg59> zul: Hmm. That doesn't seem to have been touched in weeks.
<zul> mjg59: i was looking at the toshiba bits and we might want that
<mjg59> zul: Oh, ok
<zul> mjg59: i dont think it will make a big difference.
<zul> but it would be good to have anyways
<netdur> hey, this is Arabic translation of Ubuntu guide http://ubuntu.arabdevs.com but seems firefox 1.0 in hoary can't read Arabic UTF-8 while downloaded version from mozilla.org doesn't have this problem, I don't know why so!!!
<abelli> dholbach: ping
<dholbach> abelli: pong
<abelli> dholbach: join 
<abelli> #viper please
<dholbach> sounds interesting ;-)
<moyogo> netdur: the page charset is charset=iso-8859-1, you should use charset=utf-8
<netdur> oh! just noticed :p
<netdur> but still there problem of Arabic, fot example here http://www.netdur.info/planet I use charset=utf-8, but can't read Arabic
<abelli> ppl ive got a big problem
<zul> mjg59: never mind about the toshiba stuff its already been aded
<abelli> a user in #ubuntu had a initrd.img not found
<abelli> so i made him chroot with ubuntu live cd and installed a new kernel..
<abelli> now the new kernel says
<abelli> kernel panic isnot syncing: VFS: unable to mount root fs on unknown-block(0,0)
<abelli> menu.lst is correct
<abelli> the kernel has support for that filesystem..
<abelli> what could it be?
<zul> new install?
<abelli> no.. he just messed up the system with dpkg
<zul> the root filesystem exists?
<abelli> yes
<abelli> it can be mounted
<zul> hmm..thats weird unknown block his rootfs thinks its an unknown block size or something
<abelli> yes it is..
<abelli> ok good night everybody
<dholbach> sleep tight abelli 
<zul> c ya abelli 
<abelli> dholbach: thank you 
<ogra> ciao abelli
<abelli> zul: thank you too...
<abelli> ogra: buona notte
<abelli> have a great life until we catch up again..c
<abelli> iao
<netdur> seems everyone loves Ubuntu, thank you guys
<netdur> I'm thinking to use Ubuntu instead of RH to teach Linux!
<dholbach> netdur: sounds cool!
<dholbach> netdur: where you use it to teach?
<netdur> I'm in Morocco, Rabat
<dholbach> oh nice
<dholbach> what type of school is it?
<netdur> I don't know in English, we use French
<netdur> http://www.smcomputerschool.net.ma
<dholbach> my french is pretty bad, but i'll have a look :-)
<netdur> crapy site
<dholbach> well, be sure to make photos of the students on ubuntu computers :-)
<netdur> he he, well, I will do when I replaced RH
<dholbach> cool! :-)
<dholbach> jdub will post it in his blog for sure :-)
<mdz> seb128: the problem with icons on powerpc is known, yes?
<seb128> yep
<seb128> icon cache breakage
<mdz> need any information?
<seb128> no, that's pending upload
<mdz> ok, thanks
<netdur> jdub is Jeff? I did code planetplanet like php script, it's still 0.6.1 and I had two press interviews about it!!!
<crimsun> yes, Jeff Waugh
<netdur> I like that guy
<jani> azeem, here?
<azeem> yes
<jani> azeem, I worked on transitioning pymol to python2.4
<jani> and the MOTUs tell me I should ping you about it so you know since you maintain the package
<azeem> did you fix the futurewarning I think there was? :)
<jani> I also wanted to correct some lintian warnings 
<jani> what futurewarning? :)
<azeem> like, wrote a manpage? :)
<jani> no no nothing like that :)
<jani> nor did I make a new 32x32 icon :)
<jani> those which said that the gnome and kde desktop files 
<jani> went to deprecated paths
<jani> instead of fd.o mandated one /usr/share/applications
<jani> I actually deleted the kde one, I thought /usr/share/applnk is deprecated too
<zul> Kamion: you around?
<zul> Kamion: mandrake's ata paches for 2.6.10 enables ATA_ENABLE_ATAPI
<lamont> mdz about?
<mdz> yes
<lamont> 6954 - is deleteing /etc/resolv.conf enough to get the boot up stuff to realize that it really does need to actually generate it as part of the dhcp/network config?
<lamont> (resolv.conf was on the original list of 'things that the bootup stuff needs to fix' for the root fs...)
<mdz> it will be overwritten by netcfg, yes (this should already be the case)
<mdz> I suppose that if d-i doesn't find a network, that won't happen
<mdz> but at any rate, we shouldn't ship the one that's there
<lamont> so we should remove it.  got it.
<mdz> I think no resolv.conf is probably appropriate, yeah
* lamont will fix it
<lamont> I should be able to push a new script to the machines monday sometime
<mdz> thanks
<ogra> night
* lamont files a few FTBFS bugs
<dholbach> sleep tight everyone
<lamont> mdz: python-apt ftbfs, fyi
<lamont> make: /usr/bin/python2.3: Command not found
* lamont wanders off for a bit
<mdz> lamont: 0.5.36 should fix, thanks
<zul> grrr...inotify
* lamont ^5s zul
<zul> new inotify doesnt compile
<lamont> well then, we definitely don't want to upload that patch in that state.. :-)
<zul> you think? :)
<lamont> nah - I've tried that before.  it's bad.
<zul> yeah i know you have :)
<lamont> not that one - that one compiled and worked on my (admittedly headless) test machine./
<zul> ah
* lamont idly wonders when mdz will notice the other window
<mdz> I was on the phone
<mdz> and it is saturday :-P
<lamont> np
<lamont> yeah - I'm about to wander off myself for the rest of tonight/tomorrow
<zul> liar
<zul> :)
<lamont> zul: well...
<lamont> gonna go watch a movie with the wife, and I tend to not be online sundays
<zul> ok see you monday then
* lamont wanders off, figuring he'll poke his head in again in a couple hours before actually sleeping
<AndyFitz> so ,, whos excited about ubuntu downunder ? :)
* ajmitch .
<ajmitch> AndyFitz: I'll hopefully be there, anyway
<bob2> hah
<bob2> you know it means hard work, right? :)
<ajmitch> slavery & selling of my soul?
<ajmitch> sign me up
<bob2> hahahaha
<ajmitch> bob2: I'm sure it can't be too bad :)
<bob2> bwahahaha, famous last words :-)
<ajmitch> bob2: btw, we're looking for willing volunteers for the universe python transition if you want to help ;)
<cartman> anyone knows if archive.ubuntu.com blocks some ip addresses?
<cartman> like 85.97.*.*
<MyNameIsChris> May I suggest that future releases of ubuntu come with an smp kernel
<MyNameIsChris> And the installer can decide if you need it
<dholbach> gooood morning
<sabdfl> morning all
<dholbach> morning sabdfl 
<daniels> sabdfl: 'morning
<dholbach> wow... seems to be a cracked-up ppc-party on the buildd going on
<sabdfl> hey daniels
<abelli> dholbach, sabdfl : ciao
<dholbach> hai abelli!
<sabdfl> ciao andrea
<abelli> dholbach: the thing that i had to package.. was it graveman?
<dholbach> abelli: i didn't tell you to... you said you wanted to do it :-)
<dholbach> abelli: but i'll have a look at it, once you're finished
<abelli> dholbach: ..mm  yes.. but graveman?
<abelli> :)
* daniels reinstalls his i386, so he can get at the CD burner to burn an amd64 ISO so he can recover the data on his / and then reinstall that.
<Mithrandir> daniels: aka bootstrapping?
<abelli> dholbach: the kernel panic blowed my mind..
<abelli> :(
<daniels> Mithrandir: well, I have my laptop working, but that's it; the amd64's other drive has XP on it for HL2 (video card arrived Friday), and a trashed root partition thanks to XP's installer being reckless; the other i386 had a half-installed system on it, and thus wouldn't boot.
<dholbach> abelli: i have a look in the logs ... don't worry, it was nice of you to help that guy... really
<dholbach> abelli: yes... graveman
<abelli> :))
<abelli> ok for warty right.
<dholbach> abelli: warty?
<abelli> im going to do it as i finish with the hardened kernel..
<dholbach> abelli: there will be no changes to warty any more
<abelli> dholbach: yep, ogra's one doesnt work properly, or
<abelli> at least seems so..
<dholbach> abelli: unless it's a really hard security issue
<abelli> dholbach: yeah i know
<abelli> dholbach: ogra's repos..
<abelli> dholbach: mmm... am i saying "stupid crappy" things.. let's have a log-look
<dholbach> abelli: ok... here's what i propose: you package a nice version of graveman, we put it into hoary and in ogra's repository
<dholbach> abelli: so everyone's happy
<abelli> :)), ok 
<dholbach> abelli: cool, ping me back once you're finished, and we'll go through it together
<bob2> daniels: oh, btw, if you load ibm_acpi then fn-f5 actually toggles the wireless card
<bob2> instead of bluetooth
<daniels> bob2: yeah, noticed that
<dholbach> are there any issues known about the applications menu?
<dholbach> at my place, it opens just for a quarter of a second and closes again :-/
<abelli> dholbach: your place seems to be badly broken ;)
<dholbach> abelli: ah nice... slaying the panel worked
<dholbach> wow doko_: impressive list of uploads - nice work :-)
<dholbach> doko_: https://www.ubuntulinux.org/wiki/UniversePythonTransitionTODO will soon be done
<bob2> mjg59: is there some acpi hook I can use to suspend-to-disk when the battery gets really low?
<doko_> dholbach: yes, I need to finish my packages ...
<dholbach> doko_: dont worry, we'll manage :-)
<mjg59> bob2: No
<mjg59> The OS is supposed to deal with that
<bob2> hm
<bob2> apparently windows XP will wake up out of s-t-r when the battery goes below 3% and drop to s-t-d
<mjg59> Yes. I'm not sure how it does that.
<mjg59> There's no obvious wakeup event for that situation.
<jdub> mjg59: acpi is working beautifully on my X300, thank you :-)
<daniels> jdub: took a while ;)
<mjg59> jdub: Hurrah
<mjg59> I'm like Father Christmas, except I spread ACPI rather than toys
<jdub> daniels: been working for ages, just bears repeating
<bob2> HOT ACPIT LOVE FOR ALL.
<daniels> OH, FRIG I'M AN IDIOT
<mjg59> ACPI ALL OVER YOUR FACE
<daniels> so I figured I'd test this weird strip problem (works on ext3, fails on xfs) by building xorg in /
<daniels> so I built it in /tmp on my amd64
<daniels> and made a fair few changes to it
<daniels> guess what's just happened to those changes, now that I've rebooted
<jdub> boh
<sivang> hey all
<smurfix> daniels: That scrapes
<sivang> is it acpi sunday love? ;-)
* sivang has just now reattached
<bob2> there's a disturbing number of uploads today
<sivang> bob2: for acpi?
<sivang> bob2: do we have desktop integration for acpi already?
<bob2> there's no ui, afaik
<jdub> yeah we do
<jdub> logout dialogue
<bob2> oh
<sivang> jdub: woooo
<Mithrandir> mjg59: I had a peculiar problem with my x40 this morning.  It came out of suspend (to ram), then went back in immediately.  Rinse, repeat.
<jdub> though it will hopefully change
<bob2> for configuring, I mean
<jdub> ah, yeah
<jdub> that's the hard one ;)
<sivang> so for config we still don't ?
<Mithrandir> we should have a pretty progress thing when going into sleep.
<jdub> the winxp one is nice
<jdub> i like the character mode winxp resume bar too
<sivang> we should certainly have something quick for enabling and configuration of options.
<bob2> Mithrandir: did it eventually wake up?
<Mithrandir> bob2: I got bored after ten-ish iterations and rebooted.
<bob2> oh, suck
<bob2> I've had mine do that once or twice, but closing and opening the lid worked in the end
<sivang> jdub: I think we should have something in fb that does even more nice progress indicator, come to think of it, I wonder why wnxp don't do that instead of the text mode progress bar.
<jdub> because its Hard
<sivang> jdub: ah
<sivang> jdub: are you still running the tv show? :)
<jdub> it's not on all the time
<sivang> sure, it's probably a massive bandwidth eater.
<jdub> mdz: gdm drum sound - do we really want to lose this?
<mooch> jdub: hi, dude :)
<jdub> baby jesus!
<jdub> dude
<jdub> i have a funny story for you
<jdub> i saw an ad at the cinema about the phone you had at mataro
<mooch> :)
<jdub> and i said, slightly too loudly (read: shrieked), "hey! jesus has that phone!"
<mooch> JAJAJAJA
<jdub> got some funny looks ;)
<mooch> no wonder... ;)
<sabdfl> baby jesus is very 21st century
<mooch> sabdfl: too much, sometimes ;)
<daniels> mooch: itym XAXAXAXA
<mooch> XAXAXAXA?
<mooch> itym?
<mooch> i have been too disconnected for too long time ;)
<daniels> itym -> i think you mean
<daniels> xaxaxa was from some weird russian cartoon of hitler vs stalin
<daniels> http://www.comics.aha.ru/rus/stalin/
<mooch> !!
<mooch> JA = HE in spanish, for laughter...
<daniels> yeah
<daniels> xaxa is haha in russian
<daniels> as in page 6 of that comic
<bob2> haha
<bob2> er, xaxa
<jdub> "ah ah" is french for "ha ha"
<mooch> in spain we have also a guy who, from a tv program, introduced "jurl jurl"
<mooch> well, has anyone repaired the icons problem? I still cannot see the clean the desktop icon, but an X
<jdub> mooch: on ppc?
<mooch> on x86
<jdub> oh. haven't seen a problem there.
<mooch> on ppc you can just erase the icon cache, as someone reported
<mooch> jdub: well, i can screenshot my desktop to show what is wrong...
<Kamion> hm. timezone preseeding not working so well. I wonder why not.
<Kamion> root password kickstart-preseeding working even less well, but I know why that is
<sivang> Kamion: do you do timezone preseeding based on smurfixes new locale/kbd/region chooser?
<Kamion> no
<Kamion> smurfix' program is *only* a keyboard chooser, not the other things you mention
<sivang> Kamion: ah ok , so you preseed it based on the country chooser?
<Kamion> and you can't seed timezone purely by locale in all cases (though sometimes you can present a much smaller menu)
<Kamion> consider language=English, country=United States
<Kamion> you preseed it by means of the user writing the timezone into their preseed file or kickstart file
<sivang> Kamion: ah right, I had only one time zone in mind. (like where I am(
<Kamion> selecting a single time zone for Israel isn't preseeding, that's just standard installer behaviour
<Kamion> ah, it would help if I got the preseeding syntax right
<sivang> Kamion: So you probably have a mapping table that maps locations --> possible timezones list and for israel there is only one in it? 
<Kamion> sivang: right, try 'grep ^IL /usr/share/zoneinfo/zone.tab'
<sivang> Kamion: tnx :)
<Kamion> it's maintained in glibc
<sivang> coool
<Kamion> sivang: if there's only one applicable timezone, it just gives you the chance to confirm it
<Kamion> Template: tzconfig/choose_country_zone_single
<Kamion> Type: boolean
<Kamion> Default: true
<Kamion> _Description: Are you in the ${zone} time zone?
<Kamion>  Based on your country, your time zone is probably ${zone}.
<sivang> I don't reckon it would be wise to spare this question from a user? given he has only one timezone to choose/confirm. (hmm, but then again he may want to configure his machine to a different one)
<Kamion> people seem to get upset if their clock is configured wrongly
<Kamion> it would be possible to drop the priority a bit if there's only one possible answer, but I haven't really thought about it much; it does tend to interact in complicated ways with people who're travelling
<Kamion> since the country you select feeds into your locale and thus the place where you actually are may not make a lot of sense (e.g. en_RU isn't really a useful locale)
<sivang> right
<Kamion> ach, damn X Via bug again, oh well that install was toast anyway
* jinty waves to sivang
* sivang waves back to jinty :)
<jdub> elmo: fiordland doesn't have a reverse name
* Kamion goes off to do family stuff
<jdub> hrm, luckily emails go through my secmx though
<Simira> jdub: how long does it take to get the ubuntu-no mailing list?
<jdub> Simira: once the LoCo team has been approved, mail me and it will be done almost instantly - has it been done?
<Simira> jdub: ok. No, it's just some formalities through smurfix left, I believe.
<jdub> ok, rad
<HiddenWolf> where is mvo if you need him?
<dholbach> HiddenWolf: why do you need him?
<HiddenWolf> dholbach: update-manager messed up gksu, best I can figure. 
<daniels> seb128: what's the full command line for that file?
<dholbach> HiddenWolf: sounds rather unlikely, what went wrong exactly?
<HiddenWolf> dholbach: I tried to open update-manager when it was already open on another vt, gave a few rather messy errors, required a hard-reboot, and I think it ruined the lock file.
<seb128> daniels: http://rafb.net/paste/results/vczgod80.html
<seb128> daniels: http://rafb.net/paste/results/n4UURt91.html too
<HiddenWolf> dholbach: https://bugzilla.ubuntu.com/show_bug.cgi?id=6878
<seb128> jdub: around ?
<dholbach> HiddenWolf: whats up with the lock file? can you use apt-get, synaptic at all?
<jdub> seb128: yo
<seb128> jdub: hey
<seb128> jdub: so, for the session dialog
<dholbach> HiddenWolf: hmmm, i'll copy the conversation anyway and will inform him, alright?
<seb128> jdub: you want some icons like the winXP stuff and shift-click ?
<HiddenWolf> dholbach: I can use sudo apt-get / synaptic. If I run it from the menu, nothing happens
<HiddenWolf> dholbach: it's ok.
<dholbach> from the menu it doesnt work?
<jdub> seb128: i'm pretty sure that's the right way to go, yeah
<daniels> seb128: that's totally bong -- it should be trying Xss rather than Xext
<dholbach> HiddenWolf: try to run   gksudo synaptic   from the console
<daniels> seb128: libXss_pic hasn't been patched in anywhere, ahs it?
<HiddenWolf> dholbach: lock found, exiting
<dholbach> HiddenWolf: dunno where gksu(do) keeps its locks, maybe you try moving it to another place, or maybe ask the rest of they guys or in #ubuntu *shrug*
<HiddenWolf> dholbach: *shrug* it's ok. As long as that bug gets fixed. :)
<abelli> i was wondering if in hoary every package will be "compatible" with the gnome-menu
<abelli> is it?
<seb128> grrr, dsl hangup
<seb128> daniels: 
<seb128> <seb128> AC_CHECK_LIB(Xext, XScreenSaverRegister,[XSS_LIBS="-L$x_libraries"] ,[] ,[-lX11 -lXext -lm] )
<seb128> <seb128> AC_CHECK_LIB(Xss, XScreenSaverRegister,[XSS_LIBS="-L$x_libraries -lXss"] ,[] ,[-lX11 -lXext -lm] )
<seb128> <seb128> in the configure.in
<seb128> jdub: k, I'll have a look on this, that's k to change that now with all the freezes ?
<seb128> what do you mean ?
<seb128> if a package provides a correct .desktop file the menu handles it
<Mithrandir> mjg59: Magni is tired of fedora on her laptop (said x200); do you think we could get ubuntu onto it?
<daniels> seb128: the other one is really weird, because it looks like it's never trying to link with -lXss
<daniels> seb128: try adding -lXss to the last section of the bottom line?
<abelli> seb128: ok thank you. but will MOTUs allowed to change universe package's .desktop ?
<jdub> seb128: depending on the scariness of the patch, yeah
<seb128> daniels: not better
<seb128> abelli: sure
<daniels> seb128: and you regenerated the configure?
<abelli> seb128: ok thank you
<seb128> jdub: k
<seb128> daniels: sure
<dholbach> abelli: yes... if you make a note in the changelog
<daniels> seb128: ... no idea, sorry, that's bizzare
<seb128> daniels: that's easy to get, apt-get source -b gossip
<seb128> daniels: k, thanks anyway
<daniels> seb128: heh
<daniels> seb128: no worries -- maybe Keybuk would know as he's Mr Autotools?
<seb128> right
<trulux> doko: ping
<trulux> doko: can you join #debian-hardened?
<abelli> dholbach: actually im not a MOTU, i was thinking about ogra's exploitation :))
<dholbach> abelli: exploit him in which way?
<abelli> dholbach: correcting packages' .desktop.
<dholbach> abelli: i think he's busy enough atm :-)
<abelli> dholbach: :)
<doko> trulux: not long ...
<Goshawk> hi to all
<Goshawk> is there a way to read rc scripts output?
<buga> Goshawk: use bootlogd. simply put BOOTLOGD_ENABLE=Yes to /etc/default/bootlogd
<Mithrandir> Treenaks: ping?
<zul> daniels: did you try that xfs stuff?
<dholbach> bbl
<T-Bone> Mithrandir: hi, would you have some time to help me with ia32-libs stuff?
<Simira> T-Bone: Mithrandir is on FOSDEM
<T-Bone> Simira: ah ok thx
<Simira> (he's online, though, but not much working)
<T-Bone> roger that
<Mithrandir> T-Bone: what help do you need?
<T-Bone> Mithrandir: need to get ia32-libs package generate lib32gcc1 on ia64
<T-Bone> Mithrandir: and need to fix the ugly bug in a proper way too
<Mithrandir> why can't gcc make it?
<T-Bone> (amd64 hardcoded values in rules leading to ldd.amd64 being installed)
<Mithrandir> I know
<Mithrandir> get me an ia64. :P
<T-Bone> Mithrandir: i can get you access to an ia64 very easily
<T-Bone> send me a login and a sshv2 key and consider it done already :)
<Mithrandir> can you remind me on Tuesday?  I'm at FOSDEM with a terrible network connection ATM.
<T-Bone> re gcc: it can't make it because it would need to be cross-built
<T-Bone> Mithrandir: sure np
<Mithrandir> oh, true, that'll be.. interesting. :P
<T-Bone> Mithrandir: doko seemed to think that having ia32-libs to provide lib32gcc1 on ia64 was the good thing to do
<T-Bone> heh
<Mithrandir> probably so
<T-Bone> Mithrandir: i tried to sort that out by myself but ia32-libs is a bit obfuscated for me ;) And besides, that amd64 bug doesn't ease up things :P
<T-Bone> Mithrandir: so i'd really need your help whenever you have time for it :)
<Mithrandir> ia32-libs is a wart.
<T-Bone> Mithrandir: glad i'm not the only one thinking so ;)
<Mithrandir> it's not only a wart, it's very ugly wart with evil stuff inside it.
<T-Bone> lol
<T-Bone> Mithrandir: since you say so, I'll certainly not deny it ;^)
<Mithrandir> :)
<Mithrandir> we'll get rid of it, but it takes a bit of time.
<T-Bone> heh
<abelli> jdub: u there?
* lamont wonders if he can convince mutt to thread bugs from bz, because they're not.
<sabdfl> Mithrandir: is ia32-libs used for more than oo.o and mozilla?
<zul> bbl...curling
<mdz> jdub: yes, we want to lose the gdm drum sound (though if cliff/bobby replace it with something less obnoxious, maybe we can re-enable it)
<jdub> mdz: it's had a lot of good feedback
<doko> sabdfl: mozilla doesn't depend on ia32-libs, it's built by gcc-3.4, but native on amd64
<abelli> jdub: ding
<smurfix> mdz: I've uploaded my keymap analyzer tool (part of keymapper)
<smurfix> mdz: need to integrate its results into X setup next
<sabdfl> mdz: hey, i like the drum sound
<sabdfl> it's very "welcome and sign in here"
<sabdfl> smurfix: great work on the tool, btw!
<smurfix> sabdfl: Thanks, but it's far from finished :-/
<sabdfl> yes, i understand... and there's a bit of polish required. nonetheless this is much better than "select from this long list of arbitrarily named keyboards"
<smurfix> Yeah, the first "here's what I think your default is" selection is very helpful.
<smurfix> On the other han, I've taken an Irish keyboard (i.e., key mapping taken from X) and depending on which keys the user would press they get six different results. :-/
<smurfix> The fact that the console keymaps don't ship with an Irish keyboard might have something to do with that, but still ...
<dredg> yeah the irish keymap is fun...
<dredg> i'm irish though and i can help you test it
<zul> sabdfl: im going to be enabling ATA_ENABLE_ATAPI in the next kernel uploads it should fix your sata and atapi cd-rom problem
<sabdfl> zul: awesome , thanks
<smurfix> You can start by writing an Irish keymap for the console. In fact if you can hack a bit of Python, getting keymapper to do a rudimentary X->console keymap translation is possible.
<sabdfl> zul: any idea why this isn't enabled by default upstream?
<zul> sabdfl: no idea
<zul> sabdfl: but mandrake has it enabled in their kernel i think it depends on the chipset though
<zul> bbl...lunch and curling
<dredg> smurfix: there should in fact be only on difference between an irish and a uk layout: different currency
<dredg> one*
<dredg> but the layout itself should be the same
<smurfix> dredg: Hmm, that makes sense. I'll have to check what happens with the Irish keymap from X then.
<dredg> smurfix: and as i think about it, currency is a locale thing, not a keymap thing
<jdub> lamont: around?
<smurfix> dredg: That's a nice thought but it maps very poorly to what console and X do with the keymap.
<dredg> ah, i see
<dredg> well, fwiw, i use uk keymaps in X and console just fine
<dredg> i haven't used an irish X keymap in a couple of years
<abelli> jdub: ping
<jdub> abelli: yeah?
<abelli> jdub: is it possible to have another mailing list for server-related questions?
<abelli> because normal user get a little lost when sysadmins start threads
<jdub> not sure we're ready to split the focus just yet
<abelli> on how to implement ipsec and blah blah blah
<abelli> i mean just for the italian one
<jdub> abelli: yeah, that's what i'm talking about too
<abelli> ahh...
<jdub> abelli: i think we're very close to ready for an 'ubuntu-server' list
<abelli> is it worth 2 kilos of Parmigiano reggiano?
<jdub> but splitting up LoCo lists seems premature
<abelli> jdub: some users asked for it..
<abelli> because "they're not interested in big things"
<abelli> and this is true because sometimes it happens.. that ppl start making questions about IPSEC.. when they dont even know how to use an usb modem.. and..
<abelli> this make other ppl angry.. its like playing domino.
<abelli> :)
<jdub> abelli: sure, if we create a ubuntu-server list, it will be less of a problem
<abelli> jdub: ok. got it.
<abelli> thanks
<jdub> but i don't think we're ready to create ubuntu-it-* sublists just yet
<abelli> mm.
<abelli> .
<abelli> i dont want to ruin your plans.
<abelli> so, ill make them wait in silence :).
<jdub> huh?
<abelli> ..just saying. that you know better than me what to do.
<abelli> :)
<abelli> yeah "i dont want to ruin your plans" has been a particularly badly chosen sentence.. sorry.
<zul> mjg59: can you have a look at #6977
<pitti> Hi
<zul> hey pitti  how is it going?
<pitti> zul: hey! grat skiing today
<pitti> s/grat/great/
<zul> good good
<zul> bbl
<abelli> sladen: where can i get ubuntu colors' codes?
<trulux> hi folks
<trulux> pitti: hey hey!
<trulux> :)
<pitti> Hi trulux
<trulux> pitti: we were fixing the last things of libssp
<trulux> now it's maybe the most complete implementation of SSP ;)
<pitti> cool
<dholbach> re
<pitti> Hi dholbach 
<dholbach> hai pitti
<trulux> pitti: going to build the final gcc-ssp package if all works as it's supposed :)
<trulux> gotcha good testing machine yesterday :D
<trulux> k1
<trulux> oops
<trulux> :)
<mdz> ALSA: underrun, at least 0ms.
<mdz> I should certainly hope so
<pitti> Hi mdz 
<pitti> sounds critical :-)
<mdz> I would be very concerned if it were less than 0ms
<zul> mdz: i think #1669 is fixed already in the latest d-i
<srbaker> edd, around?
<edd> hello srbaker 
<srbaker> edd, hey. did you ever decide on an issue tracker?
<srbaker> edd, the last update i see just has an "updated master list"
<edd> srbaker: i chose Roundup for the purpose I had internally. If I were going to use one for open source, I'd likely go for Trac right now.
<srbaker> okay, thanks
<fgubuntu> ho devs
<fgubuntu> hi
<fgubuntu> do you think ndiswrapper will belong to hoary cd?
<Kamion> fgubuntu: ndiswrapper-utils will be on the DVD along with the rest of supported, but there are no plans at the moment to include it on the CD as far as I'm aware
<Kamion> fgubuntu: the kernel module is there by default on i386, mind you
<mdz> Kamion: as I recall, we had a consensus to put it in the ship seed
<mdz> though it apparently wasn't added
<fgubuntu> Kamion, i can see kernel module, but after a fresh install sometimes you need ndiswrapper-utils as the only way to go out on the net
<mdz> Kamion: http://lists.ubuntu.com/archives/ubuntu-devel/2004-December/002766.html
<fgubuntu> Kamion, i can read on wiki about ship:  Utilities which might be necessary in some cases in order to connect to a network
<zul> Kamion: #1974 prism card does that work for you now?
<Kamion> mdz: so we did
* Kamion has no objections
<Kamion> zul: I can have a look tomorrow
<zul> Kamion: great thanks
<fgubuntu> Kamion, thx. bye
<zul> brb...new kernel
<zul> heylo
<dholbach> hi zul 
<dholbach> zul: long time no see :-)
<mdz> Kamion: you decided that things in ship should not also be in supported, yes?
<zul> dholbach: yeah what is it 5 minutes ago
#ubuntu-devel 2005-03-11
<Kamion> mdz: yeah
<mdz> ok, seeds updated
<fgubuntu> mdz, you mean updated with ndiswrapper-utils?
<mdz> fgubuntu: yes
<mdz> tomorrow's daily install CD will have ndiswrapper-utils on it
<fgubuntu> you guys are the best!
<mdz> we decided to do that a long time ago, but apparently I forgot to actually make the change
<mdz> that would have been embarrassing, considering I was the one who proposed it
<zul> heh..you are allowed to make mistakes sometimes
<mdz> nonsense
<Kamion> ok, with kickseed 0.9 it should be possible to do a complete Kickstart install of Ubuntu
<zul> nice!
<Kamion> although with, uh, somewhat carefully-chosen arguments
<mdz> Kamion: do you have some notes that could be put into the wiki as a starting point for a howto?
<mdz> I'd like to give that a try sometime soon
<Kamion> mdz: not yet, but one-line instructions:
<mdz> I'm pretty much convinced that casper should cause shells (running as the live user) to be spawned on the console, rather than letting getty prompt for a username/password
<Kamion> mdz: install system-config-kickstart, run it, put the output on an HTTP server accessible from your install machine, boot with ks=http://... as a kernel argument
<mdz> but I'm not sure of the best means to launch them
<Kamion> openvt?
<mdz> does that take care of setting up the process group leadership, etc.?
<mdz> ideally it would be something which would update utmp as well
<mdz> and ensure that the shell is launched as a login shell
<Kamion> hm, busybox doesn't have open(1) or openvt(1) so I can't check on the convenient machine
<mdz> I think I might just want to spawn /bin/login -f $user or such
<mdz> yes, that seems to dtrt
<mdz> need to arrange for it to be attached to the right vt, though. maybe openvt there
<mdz> openvt complains that the vt is in use, odd
<mdz> init seems to use a shell anyway, so I can just use redirections instead
<Kamion> hmm, nice of the anaconda guys to document ks=ftp://. not.
<Kamion> so I guess that'll work too as of kickseed 0.10
<mdz> Kamion: can you confirm that TERM=serial is the proper test for a serial console in d-i?
<mdz> if so, I'll make that change at the same time
<Kamion> TERM_TYPE=serial
<mdz> er, yeah, that
<Kamion> hm, one sec
<mdz> I wonder if I should skip configuring X entirely, or only stop gdm from starting
<mdz> I suppose I should skip it, since elmo pointed out that it asks questions
<Kamion> $TERM_TYPE doesn't show up while executing a shell from d-i's main menu, which is odd
<Kamion> oh, I guess that shell gets its env cleared
<Kamion> yes, TERM_TYPE=serial should indeed be fine
<mdz> ok, thanks
<Kamion> set via /lib/debian-installer/detect-console-linux
<mdz> is there an easy way I can test it?
<Kamion> s/-linux//
<Kamion> test it?
<Kamion> oh
<Kamion> that :)
<mdz> do I just boot with console=ttyS... ?
<Kamion> boot with init=/bin/sh and frob /lib/debian-installer/detect-console to lie? dunno what other effects that would have
<mdz> or does d-i have a magic console mode?
<Kamion> no, the test is a readlink on /proc/self/fd/0
<mdz> what file does that belong to?
<mdz> s/file/package/
<Kamion> rootskel
<mdz> "what package does that file belong to"
<mdz> thanks
<Kamion> booting with console=ttyS... would do it
<mdz> ok
<HrdwrBoB> you have to specify the rate etc too though
<mdz> yes, hence ...
<mdz> Kamion: I just noticed that the user-password configuration stuff could be done in a nicer way; passwd.config automagically skips the password comparison stuff if I don't preseed user-password-again
<mdz> Kamion: however, user-password-again is asked at priority high
<mdz> (pointing again to the fact that casper should probably use priority=critical)
<mdz> what I would really like to do would be to set the user password to empty, but passwd.config explicitly disallows that
<mdz> I suppose I could just set it afterward
<dholbach> seb128: ping
<seb128> pong
<dholbach> seb128: do you have an idea, what i could have done in packaging, to have 6 warnings like "** (process:28997): CRITICAL **: egg_desktop_entries_add_group: assertion `egg_desktop_entries_lookup_group (entries, group_name) == NULL' failed" and just 3?
<dholbach> seb128: i'm still working on coaster
<dholbach> seb128: the warnings refer to the installation
<hennin1> hy, i just managed to install ubuntu with FAI - fully automatic install from a sarge install server. as i saw, the ubuntu packages for FAI, at least as they are in warty, are preconfigured only to install sarge - is there any need for patches to install ubuntu with fai? 
<seb128> dholbach: seems to be a update-desktop-database output, probably from a .desktop on the system, dunno which one
<tseng> hennin1: ubuntu hoary is implementing kickstart support in the installer. stay tuned
<dholbach> ah ok... thought it was my fault 
<tseng> other automated install methods probably wont be supported
<dholbach> seb128: another problem is that clicking on a file edited with coaster fires up coaster nicely, but doesnt show the contents stored in the file - i can only guess from the lack of bugreports on it, that it's my problem and not upstreams :-)
<hennin1> tseng: does that mean there won't even be a FAI package in ubuntu at all?
<seb128> dholbach: is the .desktop correctly installed ?
<tseng> hennin1: its probably a universe package, no?
<dholbach> seb128: /usr/share/applications/coaster.desktop
<tseng> hennin1: which currently means, YMMV. you are certainly free to offer us a fixed package, but it wont be a priority to fix with kickstart support coming in the installer
<tseng> hennin1: visit us here or debian-devel list if you procure a fix, please
<seb128> dholbach: so it should work
<mdz> Kamion: where did we leave off with getting the opencd content onto the hoary live CDs?  waiting for a permanent URL?
<Kamion> mdz: sorry, maybe it's too late at night for me to understand that user-password-again query
<seb128> dholbach: "coaster /path/to/file" works ?
<dholbach> seb128: well i hope, mxpxpod drops in then... i'm pretty clueless what's going on
<Kamion> I'm not convinced that casper should use priority=critical
<mdz> Kamion: the user-password-again thingy was, I think, a "we could clean this up when moving casper to priority critical after hoary" sort of musing
<mdz> oh?
<Kamion> priority=critical has semantics that proved to be too much trouble
<Kamion> I'm uncomfortable with supporting the installer and casper at two different priorities; I think it will just make excessive work
<Kamion> 23:38 < tseng> other automated install methods probably wont be supported
<dholbach> seb128: no :-/
<Kamion> tseng: that's not true; preseed will be supported
<dholbach> seb128: ah... ok... maybe i found something
<seb128> what ?
<tseng> Kamion: he is looking at some universe package targetted at sarge
<dholbach> seb128: a warning about a dtd
<mdz> we already test them separately anyway
<Kamion> tseng: kickstart is primarily for compatibility purposes; it is less flexible than other methods
<Kamion> mdz: I'm just speaking from experience of the pain of diverging semantics there
<mdz> ok
<mdz> you expect priority=critical would be more fragile than the existing preseeding stuff?
<Kamion> casper's situation would be less problematic than the installer's, but priority=critical is still really meant for fully automated installs where you have tuned the installer to your system by preseeding it
<Kamion> yes, I do
<mdz> Kamion: how guilty would you feel about adding another udevstart invocation to work around #5732 ?
<hennin1> tseng: yes, it is a universe package. where can i read about in which form i'll have to provide that patch? (i never produced a patch for a debian package until now, and know even less about the ubuntu development process).  for the debian package, the FAI maintainer already knows about it and will put the necessary fix into FAi.  
<tseng> hm are you talking about a real bug that prevents you from using it with ubuntu, or a branding issue?
<tseng> im not familiar with this package
<Kamion> mdz: probably not at all
<Kamion> ... not at all guilty
<hennin1> as long as my install server isn't running ubuntu, it is no problem for me at all, but the available ubuntu package simply won't install ubuntu but sarge.
<tseng> that sounds like a branding issue
<tseng> you are asking for the default configuration of the ubuntu package to support ubuntu, not sarge
<mdz> Kamion: sounds good
<mdz> seb128: still here?
<seb128> yep
<mdz> seb128: I am trying to think of a good way to fix #6667
<mdz> currently, the live CD uses automaticlogin
<mdz> which is perfect for the first login, but after that, leaves the user at a login prompt
<mdz> maybe I should enable both automaticlogin and timedlogin?  would that work?
<hennin1> i don't know much about kickstart, but as i see, kamion is right, i don't see the possibility to have custom scripts like FAI supports them, at the first glance there's no information about how different system types can be managed with kickstart. anyway, i use fai since some time and don't plan to switch, as i already have a lot of work put into FAI
<tseng> you can set a 10 second relogin timer or so
<tseng> and it gives visual feedback
<mdz> ok, I'll test that
<tseng> "10 seconds to login" above the username prompt
<seb128> mdz: I've not tried, perhaps
<tseng> i do that on my mythtv box
<mdz> seems to work perfectly, thanks
<hennin1> tseng: i don't know what you consider "branding" issue. 
<tseng> hennin1: branding = customizing a package for ubuntu
<tseng> which is what you are looking to do as I understand it.
<tseng> which makes me wonder what you think the upstream maintainer is doing for you, its not a bug perse
<mdz> tseng: I'm going to do that on my mythtv box as well
<tseng> hennin1: really to be perfectly honest this FAI stuff doesnt look like something I can/am willing to support, and its in universe. youll have to explain your issues with the package to ubuntu-devel mailing list or find someone else in #ubuntu-motu to take up your cause. or better, read the debian new maintainer guide and learn packaging, and roll us a fix.
<seb128> time to sleep, night
<tseng> hennin1: I'd rather not bother every one here anymore about it today, sorry
<tseng> i hope one of those courses of action is successful for you :)
<Kamion> wow, hostile much? :) it's a bug ...
<tseng> hm I didnt mean to be hostile at all.. it seems like a branding thing to me, like apt-proxy
<Kamion> lack of technically-required branding is a bug
<Kamion> as I understand hennin1's issue, it is not merely cosmetic
<hennin1> tseng: oh, sorry, i just wanted to offer help, nor bother anybody nor less request any action,  my personal needs are fulfilled as my ubuntu is running and installed automatically with FAI. but i'll go for the hint with the new maintainers guide...
<hennin1> no problem, tseng. :)
<tseng> no I didnt mean to be an ass, there is just a stigma that people like to keep this channel low traffic
<tseng> i probably take it too seriously
<dholbach> hennin1: yes, get rocking in the MOTU crew! :-)
<tseng> hennin1: #ubuntu-motu can help you with packaging issues.. it sounds like you basically need to patch the default config or provide your own
<tseng> hennin1: if you write it.. I can help you start packaging it
<hennin1> kamion: i think you're right. simply put, if i somebody will have an ubuntu server runnung FAI, he probably don't want it to install sarge, which is what would happen right now :) that a bit more grave than just a  wrong logo or something...
<tseng> does that make sense?
* dholbach drags tseng and hennin1 over into the other tab ;-)
<zul> hey mjg59 
<jdub> argh. pain. so. tempting. to. ship. evince. must. have. discipline.
<zul> hmmm...?
<calc> evince isn't integrated with cups yet is it?
<jdub> how do you mean?
<calc> the last time i looked at its printer options it looked different
<jdub> it uses gnomeprint
<jdub> which uses cups
<calc> ah ok
<calc> maybe i was confused with something else
* jdub is just trying to print now
* calc goes back to his desk to see
<mjg59> Hello
<jdub> hrm. two-to-a-page didn't work. d'oh. ;)
<jdub> ah, i recall seeing something about this.
<calc> hmm yea it looks fine to me, i don't know what i was on
<calc> though it did seem to consistently crash trying to load the iso c++ doc
* calc bbiab trying to get new ipw2200 driver working under ubuntu
* robertj offers jdub the outlet of going to put evince on the GrumpyGroundhog wiki page right now
<daniels> mjg59: any luck with that drm patch? :)
<jbailey> wasabi: There?  I can't seem to get to your package page right now.
<dholbach> jdub: ping
<jdub> dholbach: pong
<dholbach> jdub: do you know the irc nick of George Farris (the author of gfax)? he said he got in contact with you
<dholbach> s/contact/touch
<jdub> hrm, don't think i've ever met him on irc
<dholbach> ok
<jdub> yeah, he's been working on the new mono version of gfax
<dholbach> just wanted to know, to get him more into the MOTU boat :-)
<jdub> that'd be rad
<dholbach> i'll drop him a mail
<bob2> jdub: would it be possible to beg a patch into the ubuntu kernel at this point?
<jdub> bob2: somewhat unlikely, but if it could possibly be seen as a bugfix, it's worth asking
<bob2> jdub: it just adds pci ids for the x40 irda controller
<jdub> dude
<jdub> that's totally a bugfix
<bob2> that's what I thought!
<dholbach> someone should take care of a sync of the mozilla-thunderbird-locale-* packages, at least with the current german one, thunderbird crashes immediately
<dholbach> i'll tell Mithrandir once he returned from fosdem
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<dholbach> jdub: mailed him, be sure to push the next universe guys to #ubuntu-motu as soon as they hit you :-)
<jdub> rockin' :)
<zul> jdub: thats just plain scary :)
<dholbach> jdub: turn up the music, i can't hear anything
<dholbach> and it is in sync... can't believe it
<zul> night
* tseng tunes in to jdub|tv
<dholbach> sleep tight everyone *yawn*
<tseng> bye dholbach 
<dholbach> bye tseng
<dholbach> totem doesn't seem to be able to bookmark yet :-)
<tseng> no, just recent files
<tseng> which dont include http it seems
<daniels> jdub's diggin' tha music
<pitti> Morning
<doko> morning all
<doko> d3vic3: did you get some feedback from #kubuntu about the kde bindings?
<pitti> Hi doko
<d3vic3> doko, no
<opi> d3vic3: what this KDE bindings was about?
<opi> d3vic3: I'm currently using Ubuntu + KDE
<d3vic3> python-kde3
<opi> d3vic3: I didn't play with QT Bindings 
<opi> d3vic3: you want to test it, or?
<d3vic3> well, no, it wont build
<opi> oh, I can try to build it after 1 PM
<seb128> jdub: what do you think about #6989 ?
<dholbach> gooooooooood morning
<jdub> seb128: while we're not willing to support SA, and we don't write a new spam filtering plugin...
<jdub> seb128: it would be nice if the UI disappeared if SA wasn't around
<Kamion> morning
<seb128> right
<jdub> yo Kamion 
<dholbach> hi Kamion 
<seb128> according to #evolution guys evolution should depends on sa
<jdub> so not much interest in fixing that then ;)
<seb128> but right, let's that for the moment
<Kamion> ... and gone again, giving K a lift to work. that was a short morning. :)
<drbyte> hah, kernel-team is being bugzilla spammed. clever. 
<drbyte> can someone just add arch tags to bugzilla mail instead?
<d3vic3> http://img95.exs.cx/img95/272/mozillaadware4vs.png <-- issint this anti-trust
<dholbach> hi drbyte 
<dholbach> hi dredg 
<drbyte> d3vic3: its supposed to be a fake iirc
<drbyte> hi dholbach 
<dredg> howdy
<dholbach> Mithrandir: still/already there?
<d3vic3> drbyte, I figure that much 
<Kamion> drbyte: well, the kernel team *does* need to take responsibility for kernel bugs ... at least bugzilla mail is threaded now
<drbyte> Kamion: yeah. i was looking for a way to just get the arch specific stuff, because i don't care about the other archs (tbh, i don't even have access to something like x86_64; so its not a matter of not caring)
<Kamion> some clever procmail could possibly filter threads on the Architecture: tag in the first message, I suppose ...
<drbyte> thanks. i'll look into it. get Evo to pipe outside or something
<Kamion> would be easier if bugzilla would put the current value of Architecture: in a mail header, though
<drbyte> actually, evolution can do magic too, i think. i'll play with it later...
<amu> moin all 
<AndyFitz> g'day amu
<amu> hey AndyFitz
<pitti> Hi amu
<pitti> Hi carlos
<carlos> hi *
<amu> huh pitti & carlos  
<mvo> seb128: do you know when gtk2.6 entered sarge?
<seb128> 2 days ago
<seb128> why ?
<Treenaks> mvo: isn't that on packages.qa.debian.org somewhere?
<mvo> Treenaks: I had a quick look, but didn't find it. but IIRC it is
<seb128> ?
<seb128> mvo: any issue with it ?
<mvo> it breaks synaptic
<seb128> mvo: speak nooooow :p
<seb128> oh great :/
<seb128> how so ?
<mvo> it's a synaptic problem, so don't worry. 
<seb128> k
<mvo> and it's fixed in unstable
<seb128> just curious but how does it break ?
<mvo> (and ubuntu of course)
<seb128> it should be compatible ...
<mvo> incorrect quiting a GtkDialog with "gtk_main() and gtk_quit()" IIRC (and not using gtk_dialog_run())
<mvo> I'll just push the unstable synaptic into testing and hope for the best :)
<seb128> k
<haggai> doko: Am I right in thinking that the gcc/amd64 ABI changed from 3.3 -> 3.4/4.0?
<doko> haggai: the C++ ABI? AFAIK there are no platform specific changes between these versions
<lifeless> I thought 3.4 introd a new C++ ABI
<lifeless> for all playforms
<doko> lifeless: correct, but we needed mozilla and firefox on amd64 to be built with g++-3.4, so the g++-3.4 for amd64 is configured with -fabi-version=1.
<haggai> doko: sorry, I meant upstream gcc.  OOo2-amd64 is segfaulting in the bridges module and I wonder if it is because it has been written for a different ABI
<doko> the C++ ABI in 3.4 and 4.0 is the same, but differs from the one in 3.3
<haggai> doko: hmm, that's probably the cause of the problem then, thanks
<jordi> hola hola hola
<jordi> carlos: ping
<seb128> hey jordi 
<jdub> hordi!
<carlos> jordi: pong
<jordi> OMG THE TV DUDE
<jordi> hey
<daniels> yo hordi
<seb128> hey carlos 
<jordi> carlos: ok, so it's good :)
<jordi> carlos: I don't have access to my mail right now. I forgot to switch my computer on this morning. :)
<seb128> jordi: you suck
<jordi> I'm going to London this WE
<carlos> seb128: hi
<jordi> it's going to be cool
<jordi> seb128: yeah, I suck, because my signed epiphany upload is sitting in my powered off computer. :)
<carlos> jordi: Don't worry, I asked already the plane tickets for you
* seb128 slaps jordi 
<Treenaks> jordi: get on your bicycle, get it powered! :)
<jordi> Treenaks: dude, I'm so unfit
<jordi> I haven't trained in months
<jordi> that makes me suck more than seb imagines
<carlos> jordi: you are sooo weak...
<seb128> carlos: why a plane ticket ? The lazy boy can run and swim :p
<carlos> seb128: right!
<carlos> seb128: good idea
<carlos> jordi: see you in London
<carlos> :-D
<jordi> seb128: if you arrange a 2 month vacation for me, I surely can do it
<Treenaks> LOL
<seb128> :)
<carlos> jordi: sorry you only have one day
<jordi> heh
<Treenaks> jordi: oh, and no more complaining about not being fit after that then :)
<HiddenWolf> guys, there is a guy in #ubuntu with a fatal kernel error, and I can't help him, can anyone of you try?
<HiddenWolf> some guy in #ubuntu running into hotplug/modprobe weirdness. I'm out of my depth here, please assist
<pitti> daniels: pin
<pitti> g
<jbailey> Do problems with the wiki go into bugzilla under 'websites'?
<jdub> yeah, or the WikiWishlist page
<AndyFitz> jdub, my t-shirts got rejected :-/
<AndyFitz> ill be more conservative next time
<jbailey> Yeah, this is another 'thinks I've registered under this email address when I really haven't' bug.
<haggai> jbailey: is there a javadoc replacement in gcj somewhere?
<jbailey> haggai: gjdoc is in classpath-tools.
<haggai> jbailey: cool thank you
<jbailey> haggai: It's in our list of things to upload and get in, but we're stuck behind java on ppc issues.  Hopefully resolved RSN.
<haggai> jbailey: ah, I see
<daniels> great, bug in discover1 preventing installation in some cases.  hooray!!
<Treenaks> 3 cheers for $uploader!
<daniels> i wonder if i should just piss discover1 off and move us to my 100-line python script that reads the same format
<daniels> and *doesn't* break crap
<jordi> discover[12]  is annoying.
<jordi> daniels: so Hoary does discover? warty didn't, right?
<jbailey> daniels: What cases does your script cover that hotplug on its own doesn't?
<daniels> jordi: yes, complete shit
<daniels> jordi: hoary uses discover in xserver-xorg postinst, just like xserver-xfree86 in warty and debian
<daniels> jbailey: there's no way to go to hotplug and say 'hey, so y'know my video cards, right, what driver should I use for those?'
<daniels> jbailey: that's the only reason discover1 is in main right now
<Treenaks> daniels: shouldn't hotplug say "Hey! There's a videocard here.. *do magic*"
<haggai> jbailey: is there any plan to get ant in main?
<jbailey> daniels: You mean for touching the X config?
<daniels> jbailey: yeah
<daniels> Treenaks: no, because we don't ever want to find it out except when we want to (i.e. the user wants us to build a configuration)
<daniels> even so, it's a biiiig database.
<jbailey> haggai: Yes, Java wants to crawl towards main including development environment.  
<jbailey> haggai: We're trying to get eclipse in, so it and all of its dependancies.
<haggai> jbailey: but I guess not for hoary, right?
<jbailey> daniels: I would love to see a discover that didn't insmod things and only touched other configs (sane, X, etc..)
<daniels> jbailey: right now we're specifically telling it to not do that
<jbailey> haggai: Not realistically, no.  At this point we're still sorting out the last of the gcc4 issues.  The most recent seems to be libtool breakage.
<daniels> jbailey: all it does is walks the PCI bus and lets us know which cards are video cards, and which driver we should use for those
<jbailey> Nice!  
<daniels> jbailey: that's how we use discover1 right now, and that's what the Python bit does
<jbailey> I remember someone asking me how ugly it would be to change their video card out.  Cool to know that's handled.
<daniels> http://people.ubuntu.com/~daniels/discover.py
<haggai> jbailey: ok, thanks.  OOo needs ant for some parts so that make the job harder for hoary
<jbailey> haggai: Ah, bugger.
<daniels> bear in mind that I've not really given this a clean-up, it was just sort of incrementally written in a hurry
<daniels> jbailey: 'badly'.  the idea is for the XKeepsCrashing handler in gdm to re-run discover(.py), compare the results to a cache and say 'shit dude, your hardware's changed, I'm going to try to automatically reconfigure it'; if *that* fails, start up in VESA or something.
<daniels> jbailey: this shouldn't actually be very hard to write at all.
<daniels> word.
* daniels fixes a massive tangled mess of Debconfiscation, with the end result that upgrades now work fine also.
<Evaso> hi pitti any news about pktcdvd and pmount?
<pitti> Evaso: Hi again
<pitti> Evaso: just missed you in #d-devel :-)
<pitti> Evaso: sorry, I did not yet have time to try it out
<Evaso> i had found what is probably the issue
<daniels> mdz: aha!  worked out that bastard problem where we weren't prompting for the keyboard layout if we were totally stuck and just had a random guess at us
<daniels> mdz: if it wasn't for this, most everyone would've seen a keyboard layout prompt
<dredg> does this mean that next time i install ubuntu X won't default to 'us'? :)
<Evaso> pitti: the problem is that for cd inserted in a cd/dvd burining device that are udf fromatted there must be mount the /dev/pktcdvd/x unity instead of /dev/hdx 
<sivang> hi all
<Treenaks> hey siv
<daniels> dredg: depends on when you install it ;) but yes
<dredg> daniels: good good :)
<daniels>   * Ensure that we prompt at priority critical if we can't properly guess the
<Evaso> pitti: pmount try to mount only the hdx device.. is it possible to make a selective mount with pmount?
<daniels>     keyboard layout, although we shouldn't have to guess.
<sivang> hey Treenaks 
<pitti> Evaso: you can try to mount the pktdvd device with pmount
<pitti> Evaso: however, hal probably only recognizes the /dev/hdX device
<pitti> Evaso: and gnome-volume-manager only listens to hal
<daniels> jbailey: note in particular the little-to-no error handling :)
<Evaso> pitti: but: 1) we mount every time only the /dev/pktcdvd/x devices for buring unity also if the cd/dvd inserted is not udf formatted or we must to do a selective mount and control the fs type of the media inserted
<Evaso> pitti: the pktcdvd device are mapped on a real /dev/hdx device
<pitti> Evaso: per-filesystem mount should be reasonably easy, pmount already does this partially
<Evaso> pitti: this could be the best solution, if u had udftools installed u can see the mapping configuration from here: /etc/default/udftools
<jbailey> daniels: ;)
<Evaso> pitti: udftools already use udev for devices
<pitti> Evaso: it does? that's cool, then it should already be integrated with sysfs
<brainZzZ> when i select that it says that it should already be correctly installed
<Evaso> pitti: yes is integrated in sysfs
<pitti> cool
<Evaso> pitti: /sys/block/pktcdvd0 /sys/module/pktcdvd
<pitti> Evaso: what does /sys/block/pktcdvd0/removable contain?
<zul> hey
<pitti> Hi zul
<Evaso> pitti: 1
<zul> hey pitti 
<Kamion> elmo: could you promote system-config-kickstart's dependencies (hwdata, localechooser-data) to main, please?
<pitti> Evaso: yay
<pitti> Evaso: then it should actually be possible to pmount /dev/pktcdvd0/x
<pitti> Evaso: is it?
<Evaso> pitti: do u mean /dev/pktcdvd/x in my case /dev/pktcdvd/0?
<pitti> Evaso: err, yes
<Evaso> pitti: yes pmount manually work
<pitti> cool
<Evaso> pitti: the problem is only that automatically pmount mount /dev/hdx also when the cd inserted in the burning unity is and udf formatted cd/dvd
<pitti> Evaso: yes, i'm aware of that. So either this requires hal support, or an ugly hack in pmount-hal
<Evaso> pitti: so this is becoming only an hal upstream improvments?
<seb128> jdub: here .
<seb128> ?
<pitti> Evaso: do you want to help me with this?
<Evaso> pitti: yes, sure
<pitti> Evaso: if you find an algorithm/a C code snippet which tells me if a /dev/hdx has an associated /dev/pktcdvd/y?
<pitti> Evaso: then I can integrate it into pmount-hal
<pitti> Evaso: I can also do this myself, but I'm swamped currently and this might take a while
<pitti> Evaso: if I have this, then pmount-hal can take the pkt device instead of the normal CD-ROM device
<pitti> Evaso: as a workaround until hal supports this properly
<sladen> abelli: there's a wiki page called Ubuntu Artwork with the colour palette in it
<jdub> seb128: yo
<Evaso> pitti: actually the pktcdvd module is drived by the mapping in /etc/default/udftools
<pitti> Evaso: how does this file look like?
<Evaso> pitti: for example DEVICES="/dev/hdc"
<seb128> jdub: about gnome-app-install ... is there an update planned to get all the deskop files ?
<jdub> seb128: yes, data package will hit in the next couple of days
<seb128> k
<jdub> which will result in some bugs to fix ;)
<seb128> should I update the menu now to include it ?
<Evaso> pitti: so for example DEVICES="/dev/hdc /dev/hdd" is mapped as /dev/pktcdvd/0 /dev/pktcdvd/1 etc. etc.
<pitti> Evaso: that's everything?
<pitti> Evaso: okay, so I check whether the corresponding pktcdvd device exists and just use it if present
<jdub> seb128: yeah, please
<Evaso> pitti: no there is only an exception: the directive NEWINTNAMES=
<seb128> k
<jdub> seb128: hrm, actualaly
<jdub> seb128: let's not do that until we have the data package
<jdub> seb128: at least it's already in system tools for now
<seb128> k
<seb128> BTW I'm reluctant for the session changes
<seb128> we don't have good icons
<seb128> we don't have translations
<jdub> langpack updates :-)
<jdub> icons we can do
<seb128> yeah, we have the language packs, but the really is that we don't include custom translations for the moment
<Evaso> pitti: as default if not specified is NEWINTNAMES="0 1 2 3" so for example DEVICES="/dev/hdc /dev/hdd /dev/hde" become /dev/pktcdvd/0 /dev/pktcdvd/1 /dev/pktcdvd/2 /dev/pktcdvd/3
<jdub> as soon as it goes in, we can make that happen though
<seb128> I'll do the french one, but I'm sure that's going to bit us for a lot of languages
<pitti> Evaso: what can NEWINTNAMES contain?
<brainZzZ> or else soon as it goes over like 35c it will run full blast
<jdub> seb128: only slightly joking -> it'll be a good demonstration of langpack updates :-)
<seb128> yeah, I don't doubt of the langpack updates
<tseng> hm hope we get a f-spot release before then. it has a .desktop file now
<seb128> I just doubt than we will get a good level of translation for that in rosetta
<Evaso> pitti: but i could set NEWINTNAMES for example like this DEVICE="/dev/hdd /dev/sr0" NEWINTNAMES="cdwriter dvdwriter", then /dev/hdd will correspond to /dev/pktcdvd/cdwriter, and /dev/sr0 will correspond to /dev/pktcdvd/dvdwriter 
<pitti> Evaso: what if NEWINTNAMES only specifies two devices, but DEVICE specifies more?
<pitti> Evaso: is there already a helper program which evaluates the conffile?
<Evaso> pitti: that the other devices are mapped as default
<pitti> Evaso: which then starts with e. g. 2 or 0?
<seb128> jdub: k, if you want to get the changes in the session dialog please try to get us some nice icons :)
<Kamion> where's the documentation of the .desktop file format, and how categories work, that sort of thing?
<Evaso> pitti: pktsetup -s show alway the device mapping
<pitti> Evaso: ah, cool
<Evaso> pitti: for example pktsetup -s as output i coudl have: 0 : 254:0 -> 22:0
<jdub> Kamion: freedesktop.org
<seb128> jdub: have you read the mail about the nautilus' patch for the drag and drop from the folder list ?
<mx|gone> seb128: thanks for applying my patch for gstreamer :)
<jdub> Kamion: the desktop spec and the menu spec
<jdub> seb128: no
<seb128> mx|gone: np, thanks for noticing the issue :)
<Kamion> ah, it's on fd.o, yeah, just found it
<Kamion> thanks
<mx|gone> seb128: I didn't notice it until I started working on audio stuff for coaster :)
<Evaso> pitti: it think we could reuse this output for pmount-hal
<mx|gone> seb128: anyway, np about the patch... it was pretty straightforward :)
<seb128> jdub:http://mail.gnome.org/archives/nautilus-list/2005-February/msg00030.html
<pitti> Evaso: patches appreciated :-)
<mx|gone> gotta get to work :)
<Evaso> pitti: sorry but i doesn't know c
<pitti> Evaso: okay, I'll try to look into this soon
<seb128> jdub: "looks good" according to alex, I'm tempted to include it to the nautilus package ...
<pitti> Evaso: in the meantime, can you please open a bug report about this and include soem info (like your mapping and the steps to make it work)
<Evaso> pitti: could i open in debian?
<pitti> Evaso: yes, for my sake
<pitti> Evaso: I don't mind if it's ubuntu or debian
<Evaso> pitti: ok actually ubuntu/debian had the same problem :)
<jdub> seb128: urgh, seems really strange.
<seb128> why ?
<jdub> oh no
<jdub> that's going to guarantee that it never become an option menu
<seb128> an option menu ?
<jdub> you currently have to click to get the menu
<jdub> not just mouse down
<jdub> if it becomes draggable, it definitely couldn't be mousedown only
<seb128> you want an auto-open on focus thing ?
<jdub> no
<jdub> mousedown on the button
<jdub> no menu
<seb128> oh
<Kamion> hm, I can't think of good categories for system-config-kickstart
<Kamion> I had GNOME;Development, but that puts it in a Programming menu
<jdub> Kamion: GNOME;Application;System;Utility;
<jdub> that's a start
<wasabi> http://www.gnome-look.org/content/preview.php?preview=2&id=19506&file1=19506-1.png&file2=19506-2.png&file3=19506-3.png&name=Pinux%27s+Tux+Cursors+Theme&PHPSESSID=9e7da778d0f682b9f20c4a5f1c3da80e
<wasabi> Those bottom ones should be ours. =)
* Kamion doesn't see Application in http://standards.freedesktop.org/menu-spec/latest/apa.html
<Kamion> but ok
<Kamion> ok, seems to end up in System Tools now, which is probably better, thanks
<kent> wasabi, im using those right now. They are nice!
<tseng> hey, what does the "preview freeze" mean to universe? I dont seem to see a -devel post mentioning it from a search on freeze
<Evaso> pitti: i had found in /etc/udev/permissions.d/udev.permissions pktcdvd/*:root:cdrom:0660 pktcdvd/control:root:root:0644
<jdub> tseng: universe continues to be quite relaxed. these final freezes are worth using, however.
<Evaso> pitti: this devices is already managed by hal?
<pitti> Evaso: hal != udev
<tseng> jdub: ok good, i have a few things id like to fix myself, and python updates are still progressing
<Evaso> pitti: i know
<Evaso> pitti: but if there are already in udev is possible there there is somthing in hal cvs
<pitti> Evaso: I'm not aware of anything like that
<jbailey> doko: ping?
<doko> jbailey: pong
<jbailey> doko: http://gcc.gnu.org/ml/gcc-cvs/2005-02/msg01061.html claims to fix libjava bug, committed about 20 minutes ago.
<doko> ohh, ok, I'll update the snapshot first ...
<jbailey> doko: Thanks!
<Keybuk> . o O { why does g-v-m _always_ segfault when I do an update? }
* pitti hides
<trulux> any difference between Warty kernel tree patches and such and Hoary's one?
<zul> trulux: yes alot
<jdub> Keybuk: mail for you on u-d, forgot to cc
<tritium> What's up trulux?  How's the paper?
<Keybuk> jdub: cc would've been /dev/null'd anyway :p
* sivang hi fives jinty 
* jinty gives a low one back
<daniels> rburton: hey captain :)
<rburton> hi daniels 
<seb128> pitti: around ?
<pitti> seb128: always to your service :)
<seb128> :)
<seb128> not sure on how to get useful details for the hal/gvm issue
<pitti> seb128: I just meant, is the bug still reproducible for you with the latest kernel?
<seb128> I've killed gvm and started it from the command line some days ago
<pitti> seb128: without ibreakify?
<seb128> it displays like 1 line every few second
<pitti> seb128: g-v-m ^ ?
<seb128> yep
<pitti> seb128: which line?
<Goshawk> booting the system i read: "entering runlevel 2" does anybody know something about the script/program that generates it? . The problem is that if i chvt 8 while booting this line (and others above) are written on vt8 and not in tty1 as all the others line are (this is a issue needed by usplash)
<pitti> thom: ping
<thom> pitti: hello
<pitti> thom: Hi, howdy
<pitti> thom: just evaluated #6002 with seb128 again
<pitti> thom: he and ogra had similar problems
<pitti> thom: but they seem to be gone with the latest kernel inotify fix
<thom> i'll test it when i reboot again, then
<pitti> thom: okay, cool. Thanks
<pitti> thom: please watch out for dmesg thinks like "hal.hotplug[5759] : timout(10000 ms) waiting for /bus/pci/slots"
<sivang> seb128: could you tell me why the resulting menu interface of gnome-cups-manager differs in it's "Edit" menu drop drastically then the one that's available when editing the glade file in the designer? it has 1 additional "Properties". 
<seb128> sivang: probably because the code does some changes 
<sivang> seb128: argh, ok, I'll check the code again. 
<brainZzZ> cool. i'll check the map
<sivang> seb128: I also tried adding one item through the designer, bu then the whole item list for "Edit" changed. weird stuff
<mdz> daniels: nearly everyone seeing a second keyboard layout prompt isn't very nice...it seems like we're not guessing as well as we were in Warty
<jbailey> Goshawk: Best guess is that it's init writing it to /dev/console
<Goshawk> jbailey, yes.. but the strange thing is that init writes its, why not all the messages are writtend in tty8?
<Goshawk> there are some lines in tty1 and some in tty8
<Goshawk> and in tty1 there are not only kernel messages, but also rc scripts output (managed by init)
<jbailey> Goshawk: I don't know when tty1 is created, I'd have to look at the code.  rc scripts would probably be spawned against /dev/tty1
<Goshawk> yes, it calls something as: log_begin_msg "Starting $DESC: $NAME"
<Goshawk> usplash is going to be ready... (i've now implemented bar) so if we need to ad it in ubuntu we should fix this error
<jbailey> Runlevel information isn't terribly useful.  'quiet' should probably silence sysvinit messages too then.
<Goshawk> jbailey, no.. i need them in tty1
<Goshawk> since usplash reads from it
<jbailey> Oh, I see.
<Goshawk> but all in tty1
<Goshawk> ^__^
<daniels> mdz: not really.  there were two bugs: one was that we were testing for LANG="en_AU" f.e. (guess how well that works with UTF-8), the other was that if we couldn't guess, the prompt wouldn't get shown.
<Goshawk> usplash reads from dev/vcs1 to upgrade bars
<daniels> mdz: the former has been solved by stripping out all qualifiers (@euro, .UTF-8) prior to testing $LANG; the latter has been solved also.
<jbailey> Goshawk: Bars, like progress bars?
<Goshawk> it is capable of paste any kind of image
<Goshawk> jbailey, sure
<daniels> mdz: but I 'solved' the latter (only not, in some cases) first, so everyone would see it.  but now with solving both, we're back to exactly where we were with warty.  huzzah.
<Goshawk> jbailey, excuse my bad english
<Goshawk> if(text.find("Starting hotplug") != string::npos)
<Goshawk>         {
<Goshawk> 	  hotplug = true;
<Goshawk> 	  background.draw(DrawableRectangle(device.xbar_min,30, device.xbar_min+30,50));
<Goshawk> 	    background.write("/dev/fb0");
<daniels> mdz: there's a discussion with myself and smurfix about making this less completely shit in your inbox
<mdz> daniels: yes, I see it
<mdz> daniels: can you upload xorg today?
<daniels> mdz: no, I'm about to go to sleep
<daniels> mdz: my target is tuesday, which I expect to be able to hold to
<mdz> daniels: array 6 is wednesday
<mdz> and you have ~25 days worth of xorg changes queued up
<daniels> mdz: (tuesday night being my dropdead; i'm confident enough that everything works, modulo having tested builds on all the different architectures, to upload it then.)
<daniels> mdz: agh
<daniels> mdz: understood -- obviously about 14 days of those were lost to multiseat, however (tracking down bugs in binary drivers with no spec sheets is not my idea of fun)
<mdz> did I mention preview freeze?
<daniels> tell me that's not wednesday ...
<mdz> yes
<daniels> frig.
<daniels> well, domestic duties are keeping me up late (it's already >3pm) anyway, so I might as well kick off test builds on davis and halley (builds and works ok on amd64 and i386)
<zul> mdz: so no new features allowed after wednesday?
<sivang> zul: bew features are already not allowed AFAIK ;-)
<sivang> s/bew/new/
<zul> ok thats what i thought
<sivang> zul: we are past UVF , that is.
<jbailey> Goshawk: Does it say precisely "entering runlevel 2"? 
<daniels> oh, ugh, need to upload a new .orig.tar.gz
<mdz> zul: http://www.ubuntulinux.org/wiki/PreviewFreeze
<Goshawk> yes!
<mdz> zul: confirmed changes only
<Goshawk> jbailey, yep
<Goshawk> wait
<pitti> Hi mdz
<mdz> sivang: FeatureFreeze is the relevant state here
<mdz> pitti: morning
<Goshawk> then: "Saving VESA state"
<sivang> mdz: hrm, right :)
<jbailey> Goshawk: Bah.  The E is capital. ;)  Added -i to my grep. =)
<Goshawk> then : "Starting system log daemon"
<Goshawk> :-)
<Goshawk> just switch to tty1 and all the lines above "runlevel 2" are written in /dev/cosole instead of tty1
<Goshawk> (it seems)
<jbailey> Goshawk: I'm not sure the right way to do this.  I'm guessing we'd have to 1) Create tty1 in the initrd, 2) Make sure that there was noone watching on anything other than the screen, so that serial console doesn't lose data.
<brainZzZ> if cbs showed anything other than the kennedy funeral in the sixties theyd be off the air now
<enrico> hello.  I'm trying to put scrollkeeper .omf files in a multi-binary source package: how do I tell dh_scrollkeeper to install only some omf files in the package?
<daniels> mdz: new orig uploading, which scp seems to think will take nigh on an hour; i'll run test builds around as soon as I can, and if they all pass, I'll upload on the grounds that it fixes enough important stuff that any regressions I haven't caught are likely to be minor in comparison
<Kamion> zul: speaking of freezes, any idea when I can expect the next kernel upload?
<Goshawk> jbailey, i dont' think that creating tty1 by initrd will solve the problem... 
<daniels> mdz: sorry it's taken so long, but multiseat totally threw my schedule in every way (not just work)
<Goshawk> btw.. i'm gonna continue developing usplash...
<mdz> I know
<zul> Kamion: have to talk to lamont, did you have a look at that sata atapi cd-rom bug? 
<jbailey> Goshawk: It would have to be before init was started if you wanted all of init's messages to go to a particular console.
<zul> Kamion: probably thursday will be the upload data
<brainZzZ> take a look at that
<Goshawk> jbailey, they are already there
<Kamion> zul: I would much rather have it before preview freeze
<Goshawk> jbailey, all the mesages remains in tty1
<zul> Kamion: talk to lamont though he is the one who does the uploads
<mdz> daniels: please send me a copy of your xorg changelog
<Goshawk> only those that are belove "runlevel 2" are in /dev/console
<mdz> maybe we should just delay it until after preview
<jbailey> Goshawk: Oh, really?  Hmm.
<Goshawk> jbailey, it could be a configuration problem
<Goshawk> nothing important
<Kamion> mdz: I don't think we can preview with that keyboard misconfig bug
<Goshawk> but we have to change it
<jbailey> zul: do you need me to track down whether the hotplug event is every actually sent?  I don't see how we could be ignoring it.  The code's pretty simple.
<jbailey> zul: Or... hmmm.
<Kamion> zul: you mean #1440?
<zul> jbailey: yes please
<zul> Kamion: yep
<jbailey> zul: It's the root driver.  There would have to be some further magic probably.
<Goshawk> jbailey, try to put a simple script S01chvt with "chvt 8 " command into /etc/rcS.d/ and you will see more about that problem
<mdz> Kamion: I'm inclined to agree, but we are limited by daniels' physical stamina as well
<jbailey> zul: We probably load the SATA stuff in the initrd, and the harddisk driver.  No cdrom driver available at that point, and probably no coldplugging events for the scsi bus later.
<Kamion> mdz: there's always the option of having *just* that change, which would be much smaller and pretty easily tested
<zul> jbailiey: hmm...do what you ahve to do ;)
<mdz> daniels: how much work would that be?
* mdz watches pages of changelog scroll by
<Kamion> mdz: re #5732, do you mean that just a udevstart after each time we run the hotplug scripts would fix it?
<daniels> mdz: keyboard misconfig is hopefully solved
<daniels> kami	xorg 6.8.1
<daniels> er
<mdz> Kamion: in this case, one udevstart after cdrom-detect would fix it
<daniels> Kamion: xorg 6.8.2 is in all the custom cds we made; it may solve the livecd keyboard misdetection bug
<Kamion> udevstart is generally safe to run, isn't it?
<mdz> Kamion: well, after the hoptlug bits and before the actually-using-the-device-bits of cdrom-detect
<daniels> Kamion: aiui, the only real keyboard problems we had were with the live cd; is there anything wrong with the install system?
<mdz> Kamion: yes
<mdz> I could imagine that it might get confused if you hotplug certain types of devices while udevstart is running, but mostly it's idempotent, and hotplugging devices while the installer is detecting hardware is pathological
<Kamion> daniels: well, people generally get the wrong keyboard on installation as well due to $LANG containing .UTF-8, AIUI
<daniels> Kamion: right -- we prune .UTF-8 now
<Kamion> daniels: that's what I meant
<daniels> (specifically: MYLANG=${LANG%%@euro}\nMYLANG=${MYLANG%%.UTF-8}
<mdz> array 6 is our best chance to get this fix tested for preview
<mdz> so it needs to be on there, one way or another
<daniels> yeah, which is why my uplink is saturated with the .orig.tar.gz
<Kamion> (the double % is redundant-though-harmless, by the way)
<daniels> Kamion: is it still posh-or-whatever-cracked-out-crap-we-have-in-the-installer compliant?
<Kamion> yes
<daniels> actually, nevermind, doesn't get hit until the installed system
<mdz> daniels: why  isn't the .orig.tar.gz identical to upstream's?
<Kamion> the installer uses busybox, not posh
<daniels> mdz: non-free fonts and shit.  also, thanks to dbs, the .orig.tar.gz contains a copy of the upstream tarball./
<daniels> mdz: so xorg_6.8.2.orig.tar.gz contains xorg-6.8.2/xorg-6.8.2.tar.gz, which is a pruned copy of X11R6.8.2-src.tar.gz
<mdz> gah, right
<daniels> it'll apparently be done in 34min now, anyway
<daniels> which time I will finish cleaning
<Kamion> zul: re #1974, I don't get the error messages in syslog any more (nor the status messages, come to that), and it seems to be trying to work, but the card can't associate to my AP
<zul> thats the wirelesss one correct?
<brainZzZ> it seems to be more deadly
<Kamion> zul: yeah
<Kamion> brainZzZ: are you a bot?
<brainZzZ> hey mule... are you a bot?
<Kamion> can somebody kick the bot, please?
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*stirps@*.client.comcast.net]  by daniels
* brainZzZ was kicked off #ubuntu-devel by daniels (daniels)
<Kamion> thanks
* mode/#ubuntu-devel [-o daniels]  by daniels
<bradb> can anyone give me an example of one named binary package that is built from a different named source packages for different arches? i'm trying to include a non-contrived example of such a case in a document i'm writing.
<mdz> amu: ping?
<mdz> amu: are those KDE issues fixed so that the Kubuntu packages can move into main?
<mdz> pitti: your at changes seem to have worked well; I had an at job queued before the upgrade, which ran after the upgrade with no problems
<pitti> mdz: cool
<pitti> mdz: I extensively tested it at my machine, worked fine for me too
<pitti> mdz: however, I did not check the inter-version at jobs that you did; thanks for testing
<mdz> pitti: let's leave the rest for hoary+1, though, ok? ;-)
<pitti> mdz: "rest" -> derooting targets?
<mdz> pitti: yes
<pitti> mdz: ack
<pitti> mdz: there aren't any easy ones left anyway
<mdz> I agree
<pitti> mdz: btw, what do you think about Sivan's g-cups-manager UI mods? Are they still appropriate for Hoary if I scrutinize the patch?
<pitti> mdz: and given that sivang manages to get it ready before preview freeze?
<pitti> mdz: (adding a checkbox to enable CUPS browsing)
<mdz> pitti: URL?
<pitti> sivang: ^ which bug was it? you reassigned it to you
<pitti> mdz: #2251
<mdz> pitti: it seems too complex to push in at this late hour
<pitti> mdz: it's only UI, the backend part is already in
<mdz> pitti: if you are confident that it cannot break any existing functionality, and it can be in for array 6...
<pitti> mdz: but okay, your call. sivan can prepare the patch nevertheless for hoary+1
<zul> bbl...lunch
<mdz> well, I was thinking post-preview actually
<pitti> mdz: ah, even better :-)
<mdz> since this is not strictly a feature, but partly a bug
<pitti> mdz: okay, then I can review and test the patch extensively and upload it after preview
<mdz> pitti: have you and sivang discussed how it should work in the UI?
<pitti> mdz: in any case it is now much easier to get browsing
<mdz> I suppose if the user requests to enable browsing, it will ask for the sudo password and restart CUPS?
<pitti> mdz: yes, pretty extensively
<mdz> doesn't restarting CUPS crash gnome-cups-manager?
<pitti> mdz: if it crashes it, then it's probably nothing for Hoary
<pitti> mdz: it will basically call "gksudo /usr/share/cups/enable_browsing 1"
<pitti> mdz: (or 0, if disabling)
<mdz> pitti: I have seen it crash several times when I restart cups; it is easy enough to test
<pitti> mdz: hmm, never occurred to me
<pitti> mdz: any special activities in g-c-m to make it crash on cupsys restart?
<mdz> I can't reproduce it now; maybe it was fixed, or possibly it doesn't happen every time
<seb128> pitti: double click on a printer
<seb128> keep the dialog open
<seb128> restart
<seb128> it crashes pretty often
<rburton> pitti: if you are playing with g-c-m i don't suppose you want to take it over in sid too? :)
<pitti> rburton: is it orphaned?
<rburton> pitti: well, not really. but i'm a bad maintainer
<rburton> i need to take a day and run through the bugs and patches from upstream and ubunut
<seb128> this stuff needs some real work
<pitti> seb128: I can't reproduce the crash (of course, because I want to see it happen...)
<seb128> I've got it like 5 times it 10 cupsys restart 
<seb128> just run g-c-m
<seb128> double click on a printer
<seb128> restart cupsys
<seb128> pitti: http://rafb.net/paste/results/2qkAV085.html
<pitti> seb128: worked in 5/5 cases :-(
<seb128> lucky you
<pitti> oh, cool backtrace
<seb128> :)
<seb128> I can get one with debug stuff
<pitti> seb128: could you please attach this to a bug?
<seb128> will do
<pitti> seb128: I'm currently patching cupsys
<seb128> rburton: perhaps robtaylor_ wants to maintain g-c-m ? 
<rburton> robtaylor_: you do?
<robtaylor_> seb128: did i hear my name taken in vain? ;)
<rburton> yay rob
<seb128> libgnomeprint* maintainer
<seb128> and h's supposed to get some hal work from redhat in the packages 
<seb128> I've read that somewhere :)
<robtaylor_> *sigh* ok, let me look at qa before i say yes ;)
<seb128> rburton: see, you have a winner :)
<robtaylor_> hmm, what the hell is *that* doing as  RC?
<robtaylor_> rburton: hmm, i'm a bad maintainer too tho ;)
<seb128> the current maintainer kind of sucks
* seb128 hides
<rburton> yeah, he is crap
<rburton> i'd go as far as pointing out there is a bug with a patch which has been sitting in his inbox for a month
* robtaylor_ spanks rburton 
<rburton> oooooh
<robtaylor_> rburton: well i'm pretty loaded at the moment really (got my new farsight project taking up quite a bit of time) but if i get mo, i'll go though some of the bugs for you ;)
<rburton> that would be great
<rburton> i'll try to at some point too
<robtaylor_> i know the codebase a little, at least ;)
<robtaylor_> though not enough to help poor sivang... mabye *he* wants to be the new maintainer ;) ;)
<robtaylor_> brb
<thom> whiprush: nice article dude; it's good to see *someone* not whining about the firefox theme :-)
<thom> elmo: please sync apache from unstable
<daniels> mdz: test builds on davis and halley whirring now; feel free to inquire (if there are no processes running from me and there are debs in ~daniels/xorg, it worked) into it while I'm asleep if you like
<robtaylor_> back
<elmo> thom: apache 1?
<dredg> thom: what's wrong with the firefox theme?
<thom> elmo: yeah
<mdz> daniels: thanks
<thom> dredg: nothing IMO, but people seem to like whining about it
<elmo> thom: we are going to be able to kick that thing out pre-hoary, right?
<thom> yeah
<dredg> thom: oh, the 'firefox-now-uses-the-gnome-theme' theme?
<dredg> i like that.
<dredg> it bugs me when my apps don't look similar
<thom> dredg: exactly
<daniels> mdz: smses if ftbfs kicks up would probably work well -- i might be uncontactable until about 0500 UTC (totally unavoidably) tomorrow
<lamont> moo
<robtaylor_> rburton, seb128 : talking of cups, does anyone fancy making the cups package put printers.conf in /var/lib? ;)
<mdz> lamont: please monitor daniels' test builds; if they fail, daniels should be SMSed, and if they succeed, they should be published for testing
<daniels> published in p.u.c, preferably
<daniels> actually, hold on a sec
<lamont> daniels: any particular package?
<lamont> or just everything you upload?
<whiprush> thom: heh, we've waited like four years for better support from mozilla apps and the first thing people whine about is the home icon in the skin. Heh.
<daniels> lamont: xorg, yo
<daniels> lamont: seems fine on amd64 and i386 locally, but test builds are running around on davis and halley
<daniels> lamont: should they succeed, if you could dput xorg_6.8.2-1_source.changes from rookery:~daniels, it would be much appreciated
<Kamion> bradb: that's been the case for libgcc1 in Debian in the past, I think, although it doesn't seem to be at the moment
<Kamion> can some kernel folks have a look at http://svn.debian.org/wsvn/kernel/tags/kernel/powerpc/2.6.8-10/debian/post-install?op=file&rev=0&sc=0 ?
<Kamion> it'll need to be hacked a little to take effect only on powerpc
<lamont> daniels: are the builds going to a file, or are we keying off the existance of .debs in ~daniels/xorg?
<mdz> elmo: is something weird going on with python2.3-apt?  for some reason it's at 0.5.32ubuntu6 in the archive, though a python2.3-apt version 0.5.36 was produced by the most recent build
<mdz> lamont: <daniels> mdz: test builds on davis and halley whirring now; feel free to inquire (if there are no processes running from me and there are debs in ~daniels/xorg, it worked) into it while I'm asleep if you like
<elmo> python2.3-apt |     0.5.36 | hoary/universe | amd64, i386, ia64, powerpc
<elmo> mdz: ?
<lamont> mdz: roger
<lamont> grumble. davis has 2 dpkg-buildpackage processes running
<elmo> this is why we give porting boxes two CPUs :P
* lamont wakes up and realizes that one of those 2 is not daniels's.
<lamont> elmo: I was trying to tell which was which.  :-)
<pitti> seb128: where are the translations of the panel main menu?
<mdz> mizar:[~]  grep-dctrl -FPackage python2.3-apt /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_binary-i386_Packages
<mdz> zsh: exit 1     grep-dctrl -FPackage python2.3-apt
<mdz> elmo: ^^
<elmo>  < elmo> python2.3-apt |     0.5.36 | hoary/universe | amd64, i386, ia64, powerpc
<mdz> elmo: the 0.5.32ubuntu6 is 'actually the version I have installed
<elmo>                                       ^^^^^^^^^^^^^
* mdz shoots himself
<pitti> mdz: don't
<mdz> elmo: apparently it hasn't made it to the US mirror, which is where my universe points
<elmo> oh, right, yeah - the mirrors got a bit beat up by the install testing
<tseng> the US mirror seemed to fall behind by a good many hours a few times
<elmo> as in, syncproxy, err, went away.  I'll make it come back tonight
<elmo> it wasn't meant to be down for this wrong, a kernel local root got in the way
<mdz> ok
<elmo> s/wrong/long/ blah
<dredg> this wrong? very engrish :)
<T-Bone> hi
<thom> elmo: thanks
<elmo> argh.  iproute added an 'ss' command.  the bastards.
<Kamion> what were you using ss for?
<T-Bone> yum :P
<T-Bone> Kamion: i suppose elmo refers to WWII
<elmo> Kamion: 'ss' in MSM Mumps is the equivalent of 'ps aux' and it's like ENTIRELY ingrained into me - I type that command while idling
* T-Bone was wrong ;)
<thom> what the heck is MSM Mumps?
<Kamion> well done for finding an environment I'd never managed to hear of before
<elmo> okay, syncproxy.u.c is back - us.a.u.c will catch up shortly
<elmo> thom: Mumps or 'M' is a obscure weird database environment/language mostly used in financial and medical sectors
<thom> elmo: ah
<seb128> elmo: glib2.0 sync from debian incoming please
<lamont> elmo: neat.  they've reinvented netstat -an
<daniels> right, goodnight
<daniels> lamont: mobile number's in Offices/DanielStone
<lamont> daniels: right
<lamont> davis should finish around 
<lamont> 30 min from now, give or take
<lamont> modulo the other build
<lamont> haley needs about another hour, assuming it's otherwise idle.
<mdz> lamont: are there enough bits in that directory that we can do an upload without daniels if everything checks out?
<daniels> mdz: yeah, there's a signed -1_source.changes and -1.d{iff.gz,sc}
<daniels> mdz: extra testing would be hugely appreciated though, I've only done testing on my setups
<lamont> mdz: if it works, yes.  If not, well, I'm not sure we'll have error logs
<lamont> daniels: I assume that the dpkg-buildpackage output is just going to your terminal?
<mdz> daniels: I plan to download and test powerpc and amd64
<mdz> daniels: and you're supposed to be asleep
<tseng> daniels: you have a .deb I can test?
<daniels> lamont: yeah, albeit screen(1)ed, so if you can, you're more than welcome to hijack my screen session
<daniels> mdz: note you'll have to build amd64 yourself either from source or on concordia as I was just working off local builds
<daniels> mdz: and yes, good point
<mdz> which architectures are building?
<mdz> lamont: can you kick off a build on concordia?
<lamont> halley==ia64, davis==powerpc
<lamont> sure
<zul> hey again
<lamont> mdz: launched
<lamont> concordia:~lamont/xorg.out is the log
<mdz> lamont: thanks
<mdz> an i386 build would be a good idea as well
<lamont> ot
<mdz> I assumed the two were either amd64+powerpc or i386+<x>
<lamont> it'll slow down the amd64 build
<lamont> i386 build chroot is on concordia as well
<lamont> given that daniels already did local builds of them, I'm inclined to believe them
<lamont> since the buildd's are going to rebuild it from scratch anyway
<lamont> back in a few
<srbaker> anyone know of a half-decent gui for mysql?
<zul> mysqlclient
<T-Bone> phpmyadmin
* T-Bone ducks :)
<srbaker> i can't seem to get phpmyadmin to work on my laptop running hoary
<srbaker> although, i ahvent' tried that hard
<thom> srbaker: that's a security feature :P
<infinity> <smirk>
<srbaker> thom, hehe
<thom> infinity: why are you awake you loony? :-)
<infinity> thom : Because everything I'm currently stressing about involves people in other timezones. ;)
<thom> heh
<infinity> Some day, I'll sleep at night again, and my girlfriend will stop hating me.
* mvo mvo|away
<Treenaks> infinity: well, sometimes it's better than having a gf who won't LET you sleep at night, even if you want to
<lamont> mdz: it built on ppc and amd64, given that daniels built it on i386, any objection if I upload now?
* lamont needs to run away for about 20 minutes, by which time ia64 should be done building, too.
<mdz> lamont: I had planned to actually test it on amd64 and powerpc
<mdz> lamont: if you can tell me where to start downloading it, I will
<lamont> mdz: ah
<lamont> people.ubuntu.com/~lamont/xorg has a Packages file
<mdz> wow, does that work? (multiple architectures in one Packages file)
<infinity> Yup.
<infinity> Has since woody or so.
<elmo> it's always worked
<elmo> experimental use to be that way
<infinity> Ahh, then it's the tools to generate things that changed to make it possible, not the tools that parse them. :)
<infinity> At least, I think something changed.  Or maybe I'm just on crack.  Potato seems so long ago now.
<lamont> mdz: i386 build running, will holler when it's done
<mdz> downloading amd64 and powerpc
<mdz> need to run out, back in a couple of hours
<lamont> infinity: potato _was_ that long ago.
<lamont> what, 6 years or something? :-)
* lamont leaves for a bit
<sivang> anybody noticed all the gnome menus are duplicated?
<sivang> this is in effect since about two last upgrades.
<lu_the_extermina> wfm
<zul> sivang: i didnt do it
* thom just *boggles* at the concept of a dual ultrasparc laptop
<pitti> sivang: iz gtk bug :-)
<pitti> sivang: no, really, doesn't happen for me
<elmo> thom: I think a two CPU laptop's pretty whack, but maybe that's just me
<sivang> pitti: heheh :)
<pitti> sivang: any luck with gcm?
<Treenaks> thom: that must have HURT to design
<sivang> pitti: ok, I rebooted and it got back to normal, weird.
<pitti> sivang: you have only very little time for this
<thom> elmo: indeed
<sivang> pitti: bah, until when?
<thom> a dual ultrasparc seems even more whacky than that
<pitti> sivang: preview freeze
<pitti> sivang: although maybe we skip that feature in the preview and add it after the preview
<sivang> pitti: I though it's on 2nd of march no?
<pitti> sivang: but it should be ready nevertheless so we can test it
<pitti> sivang: right, that's wed
<sivang> pitti: ok, that gives about the next 48 hours to work on it approx. 
<pitti> sivang: AFAIUI the single major blocker is the weird behaviour if you modify the glade file?
<sivang> pitti: yup, other stuff should actually work, I am with some upstream people on this, still trying.
<sivang> pitti: I mean, I do a glib sync spawn, wait for the return values etc
<sivang> pitti: but as long as the whole menu screws when I add some stuff to it using the glade designer, I'm lost.
<tritium> mjg59, If I choose "Suspend the computer" from the logout menu, it doesn't require 2 pushes of the power button to resume (which Fn-Esc still does).
<pitti> sivang: what about adding the checkbox not to the menu, but into a toolbar?
<pitti> sivang: this would be more obious anyway
<sivang> pitti: where does g-c-m have a toolbar?
<sivang> pitti: AFAIK there's only a menubar
<pitti> sivang: it doesn't so far :-)
<sivang> pitti: oh :)
<pitti> sivang: add it :-)
<pitti> sivang: although, if adding to the menu is easy and nonintrusive, then do that 
<pitti> sivang: but if you add a toolbar, then we can test the other functionality already
<sivang> pitti: right, seb also told me that the gui gets fiddled in runtime by the g-c-m code :-/
<pitti> mdz: was there any reason why you wanted a review of "boost"?
<pitti> mdz: amu just noticed that it is unnecessary for the kubuntu stuff
<sivang> pitti: which might mean the patch need be *intrusive* if it's to be nicely put with the other menu items etc.
<pitti> sivang: a toolbar is certainly more independent and less prone to interference with the runtime modification
<elmo> pitti: if it was in that list, germinate wants to pull it in 
<pitti> elmo: but amu did not find any build-dependencies or binary dependencies
<pitti> elmo: how can we find out which package wants it?
<sivang> pitti: ok, I'll see about using a toolbar now
<pitti> elmo: it's not in http://people.ubuntu.com/~cjwatson/germinate-output/kubuntu-hoary/rdepends/
<elmo> pitti: okay, it's not there any more
<pitti> oh, brb
<trulux> oh no
<trulux> 1148 upgraded, 147 newly installed, 27 to remove and 2 not upgraded.
<trulux> Need to get 794MB of archives.
<trulux> After unpacking 217MB of additional disk space will be used.
<trulux> Do you want to continue? [Y/n] 
<trulux> jesus
<trulux> what's this? :O
<trulux> going to upgrade to Hoary
<trulux> any major bug around to make feeling like a rat and not doing it?
<T-Bone> this is Moore's law applied to dist upgrades ;)
* T-Bone ducks
<trulux> T-Bone: not kidding, I haven't used Hoary as desktop, only for development ;P
<T-Bone> heh. Well then, you know how Hoary looks like :)
<sivang> T-Bone: what is moore's law about? :)
<T-Bone> sivang: google, "Moore's law" -> I'm feeling lucky ;)
<sivang> T-Bone: eh I think I learned about this in deisgn and architecture of digital system, didn't recall the name though :)
<T-Bone> heh
<T-Bone> in my suggestion i was suggesting that distributions tend to follow the same growth pattern accross upgrades ;)
<T-Bone> (doh that sentence was awkward)
<sivang> T-Bone: so you probably know Amdhal's law? (this one I remember ;-)
<T-Bone> that's an SMP thing iirc?
* T-Bone googles
<sivang> T-Bone: am not sure, could be 
* sivang --> food
<jbailey> Anyone here have a SCSI cdrom?  I'm curious how consistant /proc/scsi/scsi is for using in hotplug.
* T-Bone raises a hand
<jbailey> T-Bone: Can you /msg me your /proc/scsi/scsi file, stp?
<T-Bone> sure
<dholbach> Mithrand1r: could you please (if you find the time) upload a new version (or even sync) mozilla-thunderbird-locale-de?
<dholbach> Mithrand1r: it still crashes with the german language
<dholbach> wb mvo 
<zul> hey mvo
<mvo> hey dholbach, hey zul 
<Kyaneos> hola
<Kyaneos> hi sorry
<lamont> elmo: current xorg build-deps in concordia/hoary-i386 chroot, please
<zul> bbl
* lamont bbiab
<thom> <@kmaraas> Tybstar, new vte tarball is at http://www.gnome.org/~kmaraas/testing/vte-0.11.12.tar.gz
<thom> seb128: get to it!
<lu|away> haha
<seb128> thom: I'm pondering uploading in hoary in fact :)
<seb128> I think I'll
<lu|away> you should, unless it looks spectacularly broken somehow
<Amaranth> thom: Is that to fix the gnome-terminal redraw problem?
<seb128> bah, even
<seb128> vte is not used
<seb128> all the devels have runned away for performance/issues with screen/... reasons
<seb128> let's get it back :)
* lu|away still uses it
* lu|away still believes in dogfood
<seb128> me too
<lu|away> even if in this case dogfood mostly means 'letting the dog bite your balls repeatedly'
<seb128> but lot of people complain about it
<seb128> :)
<thom> i still find it mostly usable, and screen only breaks once a month or so
<Amaranth> seb128: Is that supposed to fix bug 122150?
<seb128> I don't use screen and I don't care about it beeing slow :)
<pitti> seb128: screen rocks
<seb128> Amaranth: is #122150? closed ?
<seb128> pitti: yeah, if you use a ssh connection on a box, I work on my box, no need of it
<seb128> Amaranth: read the comments
<pitti> seb128: I use it for long running processes, so I can restart my gnome session in the meantime
<HrdwrBoB> screen is very widely used
<seb128> I don't restart my session a lot
<seb128> if I restart it that's to reboot
<seb128> and screen doesn't handle reboot :)
<HrdwrBoB> it does if it's remote :p
<seb128> <seb128> pitti: yeah, if you use a ssh connection on a box, I work on my box, no need of it
<HrdwrBoB> yeah
<thom> seb128: my irssi session is running in a 180x60 gnome-terminal btw ;-)
<seb128> :)
<sivang> seb128: do you know anything about g-c-m ?
<dredg> enrico: ping?
<sivang> seb128: I mean, inner code wise? ;-)
<seb128> sivang: that's to manage printers ?
<seb128> written in C/GTK ?
<sivang> seb128: sort of, there also bits of bonobo there
<seb128> that doesn't excluse C/GTK :)
<sivang> seb128: I am trying to find where the code munges the glade interface, and where it handles some menubar tweaks. It's like no where. and right, that doesn't exclude C/GTK (it's in C) ;-)
<seb128> bah
<seb128> what menu entry ?
<sivang> seb128: yepper ;-/
<enrico> dredg: pong
<dredg> enrico: hi. you maintain libbuffy, yes?
<enrico> dredg: yes
<dredg> enrico: ok, i've made some changes to the source package for the universe python transition to 2.4. would you mind looking over it?
<enrico> sure: I'd love to!
<dredg> enrico: ok, http://niall.frogstomp.com/wip/libbuffy/
<dredg> i _think_ it's ok, but i'd prefer if you cast your eye over it
<sivang> seb128: when I am done with the menu entry and see it integrates nicely, I can continue with the rest of the work. (we should not have any apparent blockages)
<enrico> dredg: bbiab
<dredg> enrico: no worries.
<seb128> sivang: "yepper" is the name of the menu entry ?
<seb128> sivang: waiting for a reply :p
<sivang> seb128: no :)
<sivang> seb128: oh sorry dude,
<sivang> seb128: yeppr == yes.
<sivang> seb128: (at least for me, I
<sivang> seb128: probably should look out when I use such terms)
<seb128> <seb128> what menu entry ?
<sivang> seb128: I want to _add_ one
<seb128> <sivang> seb128: I am trying to find where the code munges the glade interface, and where it handles some menubar tweaks. 
<sivang> seb128: eh
<seb128> describe a "menubar tweak"
<seb128> and find it in the code
<seb128> should be easy
<sivang> seb128: ok, for the "Edit" one, if you open the glade file it shows there is no properties, when you run g-c-m, you see "Properties" under the "Edit" dropdown
<mdz> hah, searching google for "array 4" gives you an ebay sponsored ad
<thom> oh, holy moley
<sivang> mdz: did you see mad penguin's logo tweak?
<thom> i wish people would stop opening "make firefox work in gnome properly" bugs
<sivang> thom: I thought it worked properly :)
<thom> sivang: mime type handling and a bunch of other stuff
<thom> there are some big differences still
<thom> session management is the major suck
<sivang> eh
<sivang> mime type handling is somewhat weird , yeah
<sivang> or, "misbehaving" ;-)
<enrico> dredg: back
<seb128> sivang: properties is in the glade file here
<sivang> seb128: open the printer_window
<sivang> seb128: (in the designer) then check out what's under "Edit". then open g-c-m from your install, and see "Properties" under "Edit"
<seb128> yeah
<seb128> both avec the properties
<enrico> dredg: it seems perfectly ok to me!
<dredg> enrico: excellent :)
<enrico> dredg: have you tested if it works?
<dredg> enrico: briefly
<sivang> seb128: hmmm
<enrico> dredg: (btw, we're about to release a new version of it: just minor fixes, and buffy builds using the library)
<sivang> seb128: where is the glade file you've opened?
<dredg> enrico: nice
<sivang> seb128: is it under gnome-cups-manager-0.28/gnome-cups-manager ?
<seb128> correct
<sivang> seb128: hrm, I wonder what's wrong with my glade file. 
<seb128> gnome-cups-manager-0.28/gnome-cups-manager/gnome-cups-manager.glade
<seb128> it has 5 entries
<dredg> enrico: so you're ok for someone to upload this to universe?
<mdz> lamont: the upgrade went smoothly on amd64 and powerpc using the builds you/daniel provided
<dholbach> good night
<mdz> lamont: the only issue is that a set -x seems to have been left in a .config
<enrico> dredg: sure!  Please go on!
<enrico> dredg: I'm actually honored
<sivang> seb128: when I open the "Edit" dropdown from the printer_window in glade-2, I don't have "Properties". only when running g-c-m installed on my system i get to see it there. (that open a property window per printer)
<enrico> mdz: did you have a look at the docteam packages?
<mdz> lamont: looks like xserver-xorg.config
<dredg> enrico: great, thanks for your time
<seb128> sivang: do you use glade-gnome-2 ?
<mdz> enrico: no, I have not
<seb128> sivang: the package has a gnome version
<enrico> mdz: ok. Me and Sean did some more fixing today, and it seems there are yelp issues.  Sean'll look more into it tomorrow
<mdz> enrico: are you waiting for something before you upload them?
<enrico> mdz: and we do need help with writing good OMF files, as none of us has experience with them
<mdz> enrico: thom knows about that
<sivang> seb128: Merd! was there anything that would have implied to my non smart self about it? ;-)
<enrico> mdz: I've never uploaded a package into Ubuntu before, so I was waiting for a bit more peer review before uploading
<thom> i knew hacking doc-base would come back to bite me
<sivang> thom: run!
#ubuntu-devel 2005-03-12
<mdz> enrico: please don't wait any further, we are under release pressure
<enrico> thom: nothing too bad, I'll probably ask you to have a look at them just to see if we got the categories right.  Plus, the docs don't actually show up in Yelp's TOC
<mdz> it is much easier to make progress once it is in the archive
<enrico> mdz: ok, I can upload now.  Is there a wiki page with the procedure?  (like, a dput snippet?)
<thom> enrico: you're runnign scrollkeeper-update in postinst?
<mdz> enrico: yes, on DeveloperResources
<enrico> thom: I'm calling dh_scrollkeeper and hoping it does the right thing
<enrico> mdz: thanks!
<Kamion> mdz: do I remember correctly that you asked Mithrandir about the utf8-migration-tool build failure?
<Kamion> mdz: it's trivial to fix, I have a patch
<seb128> sivang: better with the gnome version ?
<seb128> sivang: the standard one should display something about gnome components
<mdz> Kamion: yes, I did.  is he away or something?  he has not been around much
<mdz> Kamion: feel free to fix it
<sivang> seb128: une minute, checking with a fresh source
<enrico> should I use ubuntu in the version number even if the package is not in Debian?
<mdz> enrico: no
<mdz> I updated the instructions on the wiki to reflect that, about 10 seconds after I mentioned the page
<enrico> mdz: :)
<enrico> mdz: uploading now
<mdz> enrico: if you give me the names of the binary packages, I'll add them to the supported seed
<enrico> mdz: ubuntu-docs, ubuntu-quickguide, ubuntu-faqguide
<enrico> ubuntu-docs contains the about ubuntu and release notes
<enrico> ubuntu-quickguide is cool and reviewed for Hoary
<sivang> seb128: Merci beaucoup! That was it! How can I be aware of this nex time?
<enrico> I'm waiting for plovs to tell us something about the up-to-dateness of the faqguide (bugzilla #6789)
<thom> mdz: do you have any problem with removing apm from everyting that's not i386?
<seb128> dunno, the gtk version should display some messages about it
<sivang> seb128: well, it didn't. what are the differences?
<mdz> thom: does apm not work at all on amd64?
<seb128> sivang: you are asking the difference between gtk and gnome ?
<mdz> or is it irrelevant because amd64 systems are all new enough to use ACPI?
<enrico> the quickguide is like 95%  finished and reviewed
<sivang> seb128: hrm I'll msg you for clarity
<seb128> sivang: the gtk version has the gtk widgets, the gnome the gtk and gnome ones
<thom> mdz: everything i've seen suggests the latter
<sivang> seb128: ah ok :)
<mdz> thom: go for it
<enrico> Worst case, we release with ubuntu-docs and ubuntu-quickguide only
<sivang> seb128: thanks again, really.
<seb128> np
<mdz> thom: hmm, though
<mdz> thom: has ubuntu-meta been fixed to recognize that syntax?
<Kamion> mdz: I think I did so
<enrico> mdz: uploaded.
<thom> well, that's just [i386]  right; certainly there are other examples but i'll suck it and see
<Kamion> ubuntu-meta (0.18) hoary; urgency=low
<Kamion>   * Improve update to handle architecture-specific seed entries.
<mdz> yep, looks like you did
<mdz> thom: should be fine, then
<Kamion> mdz: utf8-migration-tool> dunno. fixed.
<thom>  > > > Umm, I dont think so.  apm does not exist on amd64, cannot exist and
<thom> > > > > never will exist.  Please back this out.
<thom> someone seems pretty sure
<thom> (interestingly, inotify never caused me any problems on amd64)
<schweeb> that gnome-app-installer thing is a pretty neat idea guys
<schweeb> I commend thee
<daniels> mdz: yeah, -0.2 has -x in .config.in and .postinst.in; -1 doesn't
<mdz> daniels: -1 should be good to upload, then.  my upgrades were fine
<daniels> mdz: ok
<daniels> mdz: uploaded, I'm gone for about 6 hours now
<pitti> night everybody
<sivang> pitti: night!
<thom> Kamion: desktop/powerpc: Skipping package apmd (not for this architecture) (you rock, as usual)
<trulux>  blt-common fam gnome gnome-core-devel gnome-cpufreq-applet gnome-desktop-environment gnome-devel libbonoboui2-dev
<trulux>   libeel2-dev libfam0c102 libgnome-desktop-dev libgnome2-dev libgnomeui-dev libgnomevfs2-dev libgtop2-4 libnautilus2-2
<trulux>   libnautilus2-dev libopenh323-1.13.2 libpanel-applet2-dev libpt-1.6.3 libsoup2.0-dev libxslt1-dev nautilus-media
<trulux>   python-fixedpoint python-gtkextra python-mpz trashapplet
<trulux> being removed
<trulux> in dist-upgrade to Hoary
<trulux> this is suspicious
<trulux> also, libgtksourceview couldn't get installed  because it was trying to overwrite a file from other pkg
<trulux> anyone knows about this?
<kent> schweeb, i was thinking the opposite earlier today. gnome-app-installar is in Program->system tools  and does nothing that synaptic doesn't, and synaptic is in another place in the menu. It seems weird to have a small synaptic substitute in another place in the menu. Its just confusing to have two places to install programs from. 
<mvo> kent: we got a lot of report that people find synaptic confusing. all this libraries and strange applications all over the place. 
<schweeb> kent: what mvo said.  gnome-app-installer provides users with a view of how GNOME would think of the apps, rather than how apt sorts the apps.  plus it doesn't show you all the bazillion deps that most people don't need to know about to install an app
<schweeb> it's kinda similar to windows' add/remove programs thinger... but more useful, and with apt tied in
* mvo needs sleep
<tseng> anyone working on packaging clearlooks?
<jdub> tseng: it's already in universe
<tseng> jdub: man, you rock.
<jdub> tseng: i uploaded 0.3 the other day
<jdub> hrm
<Kamion> thom: glad to hear it ;)
<jdub> but it is not
<jdub> elmo: ping
<tseng> maybe in NEW
<Kamion> thom: at the moment I mostly just sway, hard training this week
<jdub> maybe elmo hasn't processed NEW yet
* mdz gives the buildds kdelibs to chew on
<thom> Kamion: heh, learning how to do high kicks on slippery floors?
<Kamion> fortunately the dojo floor is quite non-slippery
<thom> but how will you then learn to cope with hotels?
<thom> your life may depend on it!
<Kamion> better balance :-)
<thom> *g*
<thom> seb128: btw, metacity changing windows when something pops up is really freaking weird
<lamont> mdz: you want me to fix the -x in the config and then upload that?
<mdz> lamont: daniels already did
<seb128> thom: "changing windows" ?
<thom> seb128: desktops, i mean
<lamont> woot
<mdz> lamont: do you have some convenient way that you can be notified when kdelibs has been built?  once it's done, kdepim needs to be retried
<thom> if something becomes active on another desktop
<seb128> thom: is that new with today's upload ?
<lamont> mdz: kinda sorta
<mdz> lamont: can you do a manual dep-wait or something?
<lamont> I'll kick it
<lamont> yeah - manual dep is what it'll get
<thom> seb128:     - when receiving a _NET_ACTIVE_WINDOW message, switch to the desktop
<thom>       where the window is located before activating instead of moving the
<thom>       window to the current desktop.
<thom> in .21
<seb128> oh
<seb128> when does that happen ?
<seb128> I've not noticed :)
<mdz> Kamion: how much work remains on your end to build Kubuntu CDs, once all of the packages are in main (should happen tomorrow)
<thom> seb128: open a Netwrok Servers window, change desktop, open it again
<lamont> seb128: bug-buddy ftbfs
<seb128> lamont: k, thanks
<lamont> pitti: curl same thing
<seb128> thom: network server like in network:/// ?
<mdz> pitti isn't here
<thom> seb128: Places/Network Server
<seb128> right
<seb128> doesn't change the desktop here
<thom> does here
<thom> it's totally freaky
<thom> anyway, sleep
* thom &|
* sivang fixes a dreamcatcher for thom to protect him from moz nightmares.
<lamont> mdz: depwaiterd
<seb128> 'night thom 
<jdub> mdz: (all of kde is going in main, or just libs and friends?)
* lamont drives a couple miles to visit bandwidth-boy
<mjg59> Anyone here on PPC?
<mdz> jdub: everything used in kubuntu
<mdz> lamont-away: thanks
<jdub> mdz: hrm.
<mdz> jdub: which has already been ANDed with a security/supportability review conducted by the Kubuntu team, Martin Pitt, myself and others from ubuntu-devel over the past few weeks
<jbailey> mjg59: I am.
<tritium> mjg59, I have a PPC I can ssh into if you need...
<mdz> amu, Riddell, haggai: will Kubuntu use polypaudio?
<jdub> kubuntu has to use arts atm
<Kamion> mdz: basically a matter of checking over all uses of $DIST and replacing some of them with $PROJECT-$DIST, I think
<mdz> Kamion: does it make sense at all for kubuntu to have a supported seed at this point?
<seb128> jdub: you big freak, stop flooding my log files with audio stuff
<jdub> seb128: ;)
<seb128> :)
<mjg59> jbailey: Running ubuntu?
<Kamion> mdz: they might want some stuff in supported that isn't there already from Ubuntu, but I certainly don't think it makes any sense for them to duplicate our supported seed
<jbailey> mjg59: Yeah.  It's my primary box.  Pegasos2.
<Kamion> s/in supported/in main/
<tritium> Does anybody have a multi-binary python package that uses cdbs?  If so, I'd like to see how you setup your debian/rules file.
<mdz> Kamion: right, at this point, anything they want in main should be added to desktop, live or ship
<mjg59> jbailey: Hoary?
<jbailey> mjg59: Yes, dear.
<mjg59> And if so, latest kernel?
<mdz> Kamion: I suppose germinate would get unhappy if I just deleted supported from the kubuntu archive, though, yes?
<Kamion> mdz: correct. I haven't made the seed structure distro/suite-specific yet.
<mjg59> jbailey: Any chance that you could test suspend-to-disk? :)
<jbailey> mjg59: ii  linux-image-2. 2.6.10-24      Linux kernel image for version 2.6.10 on Pow
<Kamion> (similarly I suspect current germinate won't work too well with warty seeds, oops)
<tseng> mjg59: i tested it via the gnome logout screen
<tseng> mjg59: i get some hd activity, then a blank screen
<tseng> power never goes to off or standby
<mjg59> jbailey: Yeah, that one should have it
<jbailey> mjg59: I've never tried it.  Lemme save everything. =)
<mjg59> tseng: Could you disable USE_DPMS in /etc/default/acpi-support ?
<tseng> mjg59: sure
<mjg59> jbailey: Heh. Yes, you probably want to sync as well
<mjg59> tseng: This was on x86, right?
<tseng> yeah
<mdz> Kamion: currently, kubuntu has a supported seed which doesn't make much sense for kubuntu-in-ubuntu-main (it removes the gnome stuff and adds kde stuff)
<seb128> 'night
<mjg59> jbailey: You'll need to have RESUME set in your initrd
<tseng> i edieted acpi-support in the past, should i purge and reinstall?
<schweeb> tseng: what laptop you got?
<tseng> dell 600m
<schweeb> tseng: I'll be workin on gettin my i8200 workin later
<tseng> trying again, brb
<amu> mdz: no, the kdeguys told me at weekend it will come with kde 4
<jbailey> mjg59: Yeah, the auto-detection of the resume is still on my TODO list.  Although I did have the evil idea of instead of auto detecting it at install time, that it might be fun to autodetect the swap partition at bootup time.
<jbailey> mjg59: Install time is probably better for Hoary.
<mdz> amu: ok, I was just merging the seed changes for kubuntu
<mjg59> jbailey: Yeah
<mjg59> tseng: Might be an idea, yeah
<jbailey> Never thought the first time I did suspend-to-disk would be on a desktop machine. =)
<Kamion> mdz: *nod*
<amu> mdz: it will be gstreamer in feature
<tseng> mjg59: yeah I believe you are right.
<sivang> jbailey: it's working on a desktop machine? wooha I need try this here with my -smp kernel :)
<jbailey> mjg59: So for now, do I just poke the major:minor into /sys/power/resume ?
<tseng> mjg59: i think i was just not waiting long enough, it seems to take a few minutes to completely shut down
<jbailey> sivang: I have not yet tested it.
<sivang> jbailey: ah
<tseng> mjg59: hard to judge if something is happening when the screen is off. thanks for the tip
<mjg59> jbailey: Yeah, but make sure that the initrd has it set as well, otherwise it won't resume
<schweeb> mjg59: couldn't you also set it on the kernel command line?
<mjg59> schweeb: Yeah, but that's a pain on the pegasos (well, on the pegasos I, at least)
<schweeb> ah
<lamont_r> moof
<jbailey> mjg59: Appears to work from a text console, trying from X.
<Kamion> lamont_r: when's the next kernel upload planned?
<Kamion> lamont_r: was kinda wondering if I could squish nfs-modules udebs into it ...
<jbailey> mjg59: Works just ducky from X, too.
<lamont_r> Kamion: I think it's planned for thursday, give or take
<lamont_r> when is preview freeze, I wonder...
<jbailey> mjg59: I had to do it twice in X, though.  The first time it didn't power off.  I think because I touched a key.
<mjg59> jbailey: Oh, fucing rock
<Kamion> lamont_r: Wednesday
<lamont_r> because it should be before that
<lamont_r> could be tomorrow
<jbailey> mjg59: The box cheerfully turned off and everything.
<mjg59> Kamion: It'd be cool if you could test suspend-to-disk on PPC too
<mjg59> jbailey: That's excellent
<Kamion> mjg59: will do tonight, just burning a CD now
<mjg59> jbailey: So we can support suspend to disk and ram on most Apple laptops, and to disk on the rest of PPC
<mjg59> Well, except G5s
<lamont_r> Kamion: I think t-bone is working on merging everything together, and then I'll do the commit tomorrow evening/wed AM ish
<jbailey> I'll get install time post inst to do put the swap partition in first thing tomorrow then.
<mjg59> jbailey: Is that done before the kernel is installed?
<mjg59> s/installed/configured/
<jbailey> I'm guessing it would have to be.
<Kamion> lamont_r: I'll get you a baz branch with the changes I'd like to have
<mjg59> jbailey: Ok, cool
<lamont_r> awesome - actually, poke t-bone with the branch name
<lamont_r> --pre25--2.6.10 is there to start from
<Kamion> lamont_r: oh, t-bone is merging and then you're merging from him?
<lamont_r> yeah - he's going to put it all together, and then I'm going to do the actual commit and build of test images
<lamont_r> something to do with write access to the tree... :-(
<lamont_r> and he may or may not still need some baz tutorial help
* jbailey hopes for a remedial baz workshop at UDU.
<jbailey> mjg59: Hmm.  This might be imperfect, can I /msg you a flood?
<Kamion> lamont_r: you'll want to install kernel-wedge 1.25.1ubuntu4 when it appears
<lamont_r> Kamion: ok. hopefully it'll be in the archive before 02:00 london time??
<lamont_r> then it's automatic on the buildd's, you see..
<Kamion> lamont_r: I just uploaded it, so should be
<lamont_r> cool
<mdz> anyone know about aspell?
<mjg59> jbailey: Sure
<mdz> there are a bunch of RC bugs imported from Debian regarding the aspell 0.60 transition
<Kamion> mdz: ah, Mithrandir was at FOSDEM, that would explain it
<mdz> I intend to close them all unless we are going to be forced to update to 0.60 at some point in the future (i.e., by GNOME)
<mdz> Kamion: aha
<jbailey> mjg59: 'kay, lemme just reboot first so it doesn't fill up my logs.  Basically the scanner keeps disconencting and reconnecting.
<jbailey> (usb)
<zul> lamont_r: that build with include the atapi cd-rom stuff
<zul> oh sata
<mjg59> jbailey: Yeah, you probably want to rmmod the USB stuff before suspend and modprobe it afterwards
<jbailey> mjg59: Oy, really?
<mjg59> Yeah, the USB suspend support is still crack
<jbailey> rmmod'ing usb means losing my keyboard.
<mjg59> Check out the stuff in acpi-support on x86. We'll need to do something similar for ppc.
<jbailey> mjg59: Hmm.  Is there a bug on that I can cc: myself on?  I don't imagine that I'd look at that in the next couple of days.
<mjg59> Not that I know of - we've just worked around it on x86
* sivang --> g_get_sleep(G_SOME_SLEEP);
<tseng> its valid to tell people to report bugs upstream if it doesnt seem to be a packaging issue, correct?
<tseng> gentoo was a little crackful about keeping bugs because so many upstreams hate on gentoo users
<zul> heh and how
<Kamion> eek, synaptic's sources.list editor doesn't let me add arbitrary repositories any more?
<Kamion> that sucks
<jdub_> Kamion: you're probably capable of adding them yourself though :)
<mjg59> Is the list of changes between the preview release and Hoary final going to be kept and made publically available?
<Kamion> sure, I am, but it's a retrograde step
<mjg59> (solves all sorts of I tried this but it sucked/ate my cat/molested my wife issues)
<Kamion> mjg59: hoary-changes is archived
<jdub_> Kamion: (btw, just hit custom)
<jdub_> why is pulling anal retentive stuff out that users don't understand a retrograde step?
<mjg59> Kamion: It'd be nice if there was a summary page for the final release
<Kamion> 'cos users add custom repositories for third-party applications all the time
<Kamion> we want to encourage third-party vendors to set up apt repositories, right?
<jdub_> sure, but we won't be encouraging users to enter them manually
<Kamion> ah, custom, ok, I didn't see that
<Kamion> I stand corrected :)
<jdub_> and one look at that dialogue shows you it shouldn't be there
<Kamion> (it's in a kind of strange place in the dialog ...)
<Kamion> I guess I should resign myself to it getting harder and harder to use my nice local mirror
<jdub_> Kamion: vi /etc/apt/sources.list is as hard as it has ever been
<tseng> wb luis_ 
<Kamion> there was a period when it was relatively easy with synaptic :)
<tseng> luis_: for your next livecd run, muine is now in hoary universe. have fun
<tseng> luis_: please drop anything you got from my webspace
<jdub> raw tseng power!
<tseng> :)
<zul> mdz: missing proc_name for 3w-9xx will go in the uplaod after this one
<mdz> zul: thanks
<luis_> tseng: will do, thanks
<tseng> np luis_, will have to try your cd one of these days
<Kamion> hmm, one miiillion deprecation warnings in system-config-kickstart. better fix those.
* Kamion wonders if it would be possible for pygtk to warn only about the first use of gtk.TRUE and gtk.FALSE ...
<Kamion> update-manager is really sweet
* mjg59 -> bed
<Kamion> mjg59: if you wait five minutes I'll be able to tell you whether s-t-d on my powerbook works
<Kamion> OTOH you may be able to wait until tomorrow :)
<mdz> lamont_r: kdelibs built an hour ago, but kdepim hasn't yet
* lamont_r goes to stare at things
<lamont_r> mdz: it's building on terranova (i386) and others
<mdz> lamont_r: thanks
<Kamion> mjg59: hmm. even after a certain amount of hacking to make all the power scripts exit zero, pbbuttonsd doesn't seem to be sending the machine to s-t-d.
<lamont_r> mdz: was already building, that is
<mdz> lamont_r: interesting; has it really been building that long?
<Kamion> hm, except maybe it isn't pbbuttonsd's responsibility
<Kamion> what actually does the final step of making a system suspend?
<lamont_r> kdelibs is a 80 minute build, and kdepim is about the same
<mdz> Kamion: on i386, /etc/acpi/sleep.sh
<mdz> Kamion: in theory I think powermanagement-interface is supposed to abstract this, but at the moment it seems to be acpi-specific
<mdz> Kamion: if you find out, please update powermanagement-interface :-)
<Kamion> mdz: see the source; powermanagement-interface does have pmu support
<Kamion> hm, suspended but didn't come back up; perhaps if I were intelligent I'd make the hibernate script finish off by calling resume
<Kamion> mdz: however, pbbuttonsd doesn't seem to have a triggerable action for "suspend to disk", only TAG_GOTOSLEEP which == suspend-to-ram
<Kamion> pmi works fine for suspend-to-ram, though
<mdz> Kamion: oh, I see.  I didn't notice it was arch: any
<mdz> Kamion: maybe pmi should trigger the swsusp itself, then?
* lamont_r heads back home
<Kamion> mdz: no, it needs to be in pbbuttonsd so that it can work if you change the coveraction or keyaction to suspend-to-disk
<Kamion> or in some package that installs scripts into /etc/power/
<zul> mdz: you know that vfat synchronous support mandrake has a patch that we could use
<mdz> zul: oh, interesting
<jdub> ooh
<zul> ill test it out 
<zul> and they use the same inotify we use in -23
<mdz> the one that broke GNOME?
<zul> good point
<tseng> have you diffed them?
<zul> not yet
<tseng> or just looked at version string
<zul> version string
<jdub> seb was saying their inotify issues are resolved
<jdub> i might check up on their gamin package
<zul> mandrake's inotify is different from ours
* tseng looks for cooker srpms
<Kamion> lamont-away: where's that --pre25--2.6.10 branch you mentioned?
* Kamion can't find it on chinstrap or rookery
<tseng> huh..
<tseng> i can only find rpms
<zul> ftp://fr2.rpmfind.net/linux/MandrakeCooker/10.2/SRPMS/main/
<tseng> hm of course
<Kamion> lamont-away: oh, never mind, I'm stupid
<zul> the inotify patch is the same from kernel.org though
<tseng> jdub: http://getsweaaa.com/~tseng/gamin-0.0.24-inotify017.patch is in the srpm
* tseng grabs ubuntu source to stare and compare
<lamont> Kamion: glad you found it.\
<jdub> wow, they're shipping 0.17?
<tseng> zul can speak for whats in the kernel
<tseng> ive not looked
<zul> jdub: this is what they have in the kernel http://zulinux.homelinux.net/ubuntu/kernel/FS18_inotify-0.18-rml-2.6.10-16.patch
<jdub> hrm
<tseng> zul: ill apply their patch to gamin and try to boot with inotify
<tseng> hows that
<zul> that would be good
<Kamion> lamont: so if I mail a merge request to kernel-team@lists.ubuntu.com, will that reach the right people?
<tseng> sending to pbuilder now
<zul> Kamion: yes
<lamont> yes
<tseng> errored out, win
<tseng> In file included from gam_inotify.c:38:
<tseng> local_inotify.h:23: error: `INOTIFY_FILENAME_MAX' undeclared here (not in a function)
<zul> Kamion: eventually all three of us will be able to do an upload
<tseng> but thats the only patch they apply to 0.0.24
<zul> gimme a sec.
<zul> lets try google
<tseng> Patch0: interface with inotify 0.17 (not 0.18 yet)
<Kamion> zul: ok, sent
<zul> great..
<wasabi> so how's nfsv4 coming?
<zul> uhhhh...
<zul> its not really going anywhere
<wasabi> =(
<zul> there is alot on the plate right now as it is
<tseng> 'server/gam_poll.c: try to avoid the /media/ mount problem in 0.0.24'
<tseng> this is one of our issues I believe
<tseng> hm inotify 0.19 support was added on Feb 10
<tseng> which was before .24.. looks like the mandrake patch actually is reverting to .17
<tseng> that makes sense now
<tseng> zul: know anything about 0.19?
<tseng> zul: im feeling brave
<Kamion> jdub: moderation of my message to kernel-team@ would be handy
<Kamion> if you could
<lamont> mdz/jdub around?
<jdub> yeah
<lamont> so inotify...
<lamont> if we drop that back to .17 to match gamin, that's almost certainly a kernel abi event.
<lamont> thoughts on that front?
<tseng> lamont: im going to test .19 here
<tseng> if no one has yet
<lamont> tseng: that'd be way cool
<tseng> fetching linux-source atm
<jdub> lamont: i don't think it's worth falling back
<tseng> gamin looks to support .19 in 0.24
<lamont> ok.  we know that 17->18 was an abi bump.  18->19 may be as well.
<tseng> ill remove .18 and zuls no-default patch and drop in .19
<lamont> jdub: so the question is, if it is an abi bump to go to .19, do we want to do that the day before preview freeze?
<lamont> also, I need mdz/jdub to tell me to go ahead and cause an rsyncability-event for amd64's livecd (since it doesn't have garbage collection, and therefore grows over time...)
<Kamion> lamont: that last can be after preview freeze, can't it?
<lamont> Kamion: anytime people want
<tseng> oh jeez
<lamont> it's literally simply the case of me removing the previous day's image
<tseng> there are a bunch of inotify patches
<jdub> lamont: i'm coming around to the idea that we should ship without inotify turned on by default, but we should endeavour to have a working version.
<tseng> mind if i just patch my sources by hand?
<lamont> tseng: given a working inotify, it'd be nice if it matched some combination of upstream patches... but working is even better... :-)
<zul> tseng: i couldnt get 0.19 to compile
<tseng> I dont understand the split up patches, but i rm *inotify* and dropped mine in
<zul> well the latest 0.19 
<tseng> we'll see
<tseng> im guessing it compiles for at least rml and whoever wrote the code for gamin
<jdub> john mccutcheon
<drbyte> tseng: daniel veillard. it seems to work for fedora/rawhide (compiles, runs). though we're seeing regression with usb thumb drives being locked
<jdub> drbyte: fedora isn't shipping inotify
<tseng> locked on unmount?
<drbyte> jdub: no, but gamin has inotify support. even though the abi might change, dv's gotten some steam from arjanv
<tseng> or just not catching the file alteratioin on mount
<jdub> tseng: fedora uses dnotify, so gets the file usage on removable drives problem
<tseng> I see, right
<jdub> drbyte: i think you missed a bit of the conversation or something :)
<drbyte> jdub: possibly. reading scrollup now 
<tseng> drbyte: we've been having issues with inotify .18 and gamin .24 causing a hardlock on startup
<mdz> lamont: kernel ABI change should probably be OK before preview if we stage the update elsewhere first, and synchronize things so that we don't build broken CDs
<tseng> is the crux of the issue
<tseng> looking to fix one of the components and happily move forward
<jdub> we should just jump to 0.19 and leave it off by default
<tseng> zul just said it didnt compile on last trial
<lamont> mdz: so you're saying before preview freeze, or before preview?
* jdub molests rml.
<jdub> can anyone else process NEW?
<tseng> jdub: im doing my own test atm
<mdz> lamont: after array 6, before preview (during preview freeze)
<mdz> jdub: no
<jdub> d'oh
* lamont realizes that this is the last day of a short month, burns bandwidth quota
<mdz> lamont: but in the specific case of inotify, re-enabling it at that point doesn't seem very wise
<lamont> mdz: so don't bump ABI with tomorrow's upload, but OK to include a new inotify patch post preview-freeze (after array 6), but leave inotify disabled by default.
<lamont> right?
<mdz> without serious hoary-external testing
<lamont> yeah - it's default state wants to stay off until after hoary ships
<mdz> lamont: that sounds reasonable, yes.  we just shouldn't create kernel churn right now, when we'll be preparing Array 6 tomorrow
<lamont> very true
* lamont points T-None at this area of his scrollback
<lamont> zul: sound good to you on the inotify front?
<zul> yep..sounds good to me
<tseng> whats this crack about having 30 00list's?
* lamont adds "buy plane tickets to UDU" to his todo list
<zul> welcome to the world of ubuntu kernel
* tseng takes a hit
<tseng> does it actually read all these?
<lamont> tseng: for reasons unknown, yes.
<lamont> but it unapplies all of the ones older than the last one, too.
<zul> then there are directories like linux-source-2.6.10-2.6.10-1 etc
<lamont> it's to warm up the heads on the disk for serious compile work
<tseng> oh the -X is the revisions
<tseng> so i want -24
<lamont> actually, it'll wind up being linux-source-2.6.10-2.6.10 when unpacked, or are you talking about inside the unpacked source/
<lamont> "?
<zul> inside the unpacked source 
<tseng> linux-source-2.6.10-2.6.10/debian/patches
<tseng> is where im currently hitting the crack pipe
<lamont> find  debian/patches/ -type d
<lamont> debian/patches/
<lamont> debian/patches/.arch-ids
<lamont> must be in the building source.
<jdub> tseng: coming to UDU?
<lamont> and what really matters there is the debian/build directory
<tseng> jdub: nope, sorry
<zul> tseng: if you just want to compile for 686 you have to modify the flavours in the debian/rules to say 686
<tseng> i dont have a fulltime job atm, no chance for that sort of plane ticket
<tseng> zul: eh, ok
<tseng> it failed anyway
<zul> you should come to ols then :)
<jdub> tseng: what's your day job atm?
<zul> did you turn the patch into dpatch?
<wasabi> damn this wiki
<tseng> jdub: only working part time atm for my uncle.. hoping to scare up some employment interest with my talk at a linux security conference on Saturday.
<tseng> zul: ya
<jdub> tseng: rawk
<tseng> im still farked in some 00list
<jdub> sa-learn is slow
<tseng> sa is overdue for a rewrite in C
<tseng> 00list proper must be generated on each pass
<lamont> 00list proper is generated each loop, yes
<tseng> from 00list-X where X = revision?
<lamont> yes
<dholbach> morning
<lamont> and, if present, from 00list-X.${ARCH}
<tseng> because i removed references to inotify .17 in -24
<tseng> and they are sitll reappearing in 00list
<tseng> which is causing the entire process to go nowhere fast
<wasabi> archive question. I am working on Java packaging. I have a TON of cyclic dependencies.
<wasabi> many layers deep. Luckily, they are arch-indep.
<wasabi> what can be done?
<zul> you could not use java :)
<wasabi> okay, no java for ubuntu.
<wasabi> i can live with that!
<zul> i dont like java
<tseng> obviously :)
<zul> well if you had to modiy a crappy groupware written in java you would too
<zul> night
<tseng> cya zul 
<lamont> wasabi: if you get it down to a list of 'take these debs from here, use them to build all these, and then rebuild everything, I can make that happen
<lamont> but it needs to happen soonish...
<wasabi> it's not for hoary.;
<wasabi> not a chance. =)
<lamont> that is, to get it into the archive (eventually), I'll want the minimum set of packages to break the circular dependency.  Then we build everything twice (for my sanity), and the second round is what goes in the archive
<wasabi> k.
<wasabi> http://www.ubuntulinux.org/wiki/EclipsePackaging
<wasabi> =(
<lamont> which reminds me. time to go do mass give-backs on i386 and amd64
<dholbach> daniels: thanks for fixing xvfb-run :-)
<tseng> ah I'm stupid
<tseng> seems to go happily along if I make a new -25
<ogra> night
<dholbach> night ogra
<jdub> uh oh
<jdub> beagle 0.0.7
* schweeb watches whiprush soil his pants
<darkfusion> I would like to report a problem with my compact flash reader, where should I start?
<schweeb> bugzilla
<dholbach> or the mailing list: ubuntu-users@lists.ubuntu.com
<darkfusion> the problem is that I don't know to file against the kernel/hal/gnome-volume-manager 
<darkfusion> there is alot of stuff going on but I am not sure what is broken.
<dholbach> this is more a  #ubuntu -question
<darkfusion> I asked but no one responded, I guess I will try again
<dholbach> the mailing list then is maybe a better place
<dholbach> darkfusion: good luck with it 
<dholbach> bye
<ficusplanet> Hey everyone.  Is there a reason that dbus-0.23.1 isn't being uploaded to hoary?  Would it break feature freeze?  I ask because it is required for the two most recent versions of beagle.
* lamont grumbles at gtk-doc
<jdub> ficusplanet: daniels was going to do it; not sure where it's at.
<ficusplanet> jdub: Thanks.  I was just making sure it hadn't slipped through the cracks.
<jdub> he may have decided not to do it, mind
<crimsun> dbus-0.23.2 in sid corrects the api & abi breakage between .1 and .2
<ficusplanet> jdub: I trust your/other ubuntu devs judgment on that stuff.  Just had the itch to play with beagle and noticed the discrepancy.
<jdub> crimsun: probably worth the sync and merge.
* lamont sleeps
<trulux> dpkg: error al procesar /var/cache/apt/archives/libgtksourceview-common_1.1.92-0ubuntu1_all.deb (--unpack):
<trulux>  intentando sobreescribir `/usr/share/gtksourceview-1.0/language-specs/nemerle.lang', que est tambin en el paquete libgtksourceview-cil
<trulux> the upgrade is broken
<trulux> bye
<daniels> dhnp
<kagou> hi
<pitti> Morning
<mdz> morning
<jdub> hello, derooter! :)
<pitti> well, no derooting tasks for Hoary any more :-)
<jdub> Ubuntu 5.04: Not Rooted Anymore
<ajmitch> pitti: hoary is 100% secure, then? ;)
<pitti> ajmitch, jdub: no :-( we don't want to mess anything up for Hoary any more
<ajmitch> ah..
<bob2> mmm, setting up ubuntu servers is a pleasure
<Treenaks> bob2: how so?
<bob2> all the apt love of a Debian server plus recent packages lovingly security fixed by our own mr pitt.
<jdub> i'm running hoary on my linode ;)
<bob2> hah
<Treenaks> jdub: did you see the photoshop contest links I sent? :)
<jdub> hrm, no?
<bob2> jdub: it's a 6 month release cycle, dude
<bob2> control your hand-on-the-cvs-up-button urge
<jdub> and someone needs to test server stuff
<jdub> i am someone
<jdub> i test server stuff
<bob2> hm
<bob2> aptitude wants to slurp tons of random stuff in every time I run on
<jdub> elmo: ping
<seb128> pitti: morning
<pitti> Hi seb128 
<seb128> pitti: 
<seb128> Mar  1 09:31:45 localhost hal.hotplug[5156] : timout(10000 ms) waiting for /bus/pci/slots
<seb128> Mar  1 09:31:45 localhost pci.agent[7484] : Bad PCI agent invocation
<pitti> bah, the current live CD still has a broken keyboard setup
<seb128> :(
<pitti> hmm
<pitti> daniels: is it known that the live CD still sets up a pc104/us layout even for de_DE.UTF-8?
<daniels> pitti: using xorg 6.8.2-1?
<pitti> daniels: the powerpc live CD as of yesterday night
<pitti> daniels: i. e. old version
<daniels> pitti: anything older than 6.8.2-1 will be broken; the next livecd to get built (20050301, maybe 20050302) will have it
<pitti> daniels: ah, cool. Then I test this again
<pitti> then hopefully the icons will work again, too
<seb128> pitti: the icons are fixed with the new gtk
<pitti> seb128: yes, I saw that
<pitti> great
<pitti> seb128: although I still don't understand why a cache is put below /usr
<daniels> pitti: cool.  20050301 shound do it
<daniels> should, even
<mvo> seb128: mind if I upload a new gksu with different locking?
<seb128> mvo: not at all, you are welcome to fix any GNOME bug :)
<mvo> seb128: I guess there are enough of them for everyone :)
<daniels> seb128: every bug is a GNOME bug!
<seb128> daniels: so you are welcome to fix any bug you want :)
<jdub> as long as it's black
<jdub> black as my heart
<seb128> oh jdub is here
<seb128> so I can say that again
<seb128> STOP FLOODING :p
<jdub> heh
<seb128> jdub: BTW about the debugging stuff, is that better than making -dbg packages ?
<seb128> I've not read the whole thread yet
<jdub> lamont: heh, i've had soft_bounce = yes on my linode for the last few days. oops.
<jdub> seb128: we'll have to do both
<jdub> seb128: well, no, we want to do -dbg regardless; the other stuff is a new idea, and would be a cool bonus if we feel it's worth it.
<seb128> k
<seb128> BTW I'm really happy to have a nautilus-dbg
<jdub> yeah?
<seb128> we get some nice backtrace upstream now
<jdub> been useful? :)
<jdub> rockign
<seb128> when we get a nautilus crash from hoary I ask for the bt with nautilus-dbg
<seb128> and apparently that works better for users than asking to build a debug version :)
<seb128> we should really do a full -dbg archive aside
<jdub> ywah
<jdub> btw, are our -dbg packages separate dbg data, or full dbg builds?
<seb128> dbg datas
<seb128> thanks to dh_strip
<seb128> (it uses objcopy)
<jdub> rad
<Treenaks> seb128: hm, can I get a debug-version of gst-plugins that way as well?
<seb128> no
<Treenaks> hm
<Treenaks> then I'll recompile :)
<seb128> speak about extra -dbg in the archive and elmo will track you down :p
<jdub> ;-)
<seb128> I would like to have -dbg for evolution too
<seb128> bah
<torkel> daniels: I will try to find some time to verify that #4343 is really fixed this time, later today 
<seb128> we really wants to set this -dbg tree
<jdub> seb128: we'll make it happen at UDU :)
<seb128> ROCK
<seb128> the other jeff really wants it too
<seb128> so if we need some cdbs magic ... :)
<jdub> heh
* jdub will remember to tell jbailey he's "the other jeff" ;)
<seb128> but that's probably some buildd magic in this case
<seb128> ah ah
<jdub> so dontreply@ubuntulinux.org is not a valid sender address
<jdub> so i no longer get forum-posted mails to the lists
<jdub> ;-)
<jdub> net win or net loss?
<jdub> you be the judge ;)
<jdub> 'course it might just get me booted off the list, too
<thom> i think the forums should be banned from the devel list in fact, tbh
<jdub> readonly?
<thom> yes
<Treenaks> jdub: readonly shouldn't be a problem.. then it's Just Another Archive
<Treenaks> (with some fancy forum features)
<thom> if people want to post they can damn well subscribe
<jdub> also, fiordland doesn't have rdns
<thom> nope
<thom> http://guilinux.com/reviews.php?op=showcontent&id=20
<jdub> thom: firefox has some "pass download requests to external manager" thing now, doesn't it?
<daniels> agreed wrt forums->ubuntu-devel gate
<daniels> torkel: word, thanks
<pitti> daniels: is https://bugs.freedesktop.org/show_bug.cgi?id=1920 fixed in the latest Hoary packages?
<daniels> oh my god
<daniels> pitti: no.  sigh.
<pitti> daniels: this also needs new warty packages, I'm afraid
<daniels> FRIG
<pitti> damn xpm bugs
<pitti> and needs a whole lot of other package updates :-(
<daniels> at this point, it would just be easier to surgically remove xpm support from every single package we have
<daniels> and kick xpm the hell out of the archive
<jdub> mdz: i told dbcw about omshell; he's cautiously interested
<daniels> that's, what, the 11th patch now?
<jdub> dcbw
<pitti> daniels: can you do the warty update for x? I'll do all other packages
<daniels> pitti: what sort of timeframe?  i'm exhausted tonight (been sleeping on and off all day), so it probably won't happen for 24h or so
<pitti> daniels: no worries
<daniels> cool
<pitti> daniels: let's say hoary should be fixed by the preview release
<pitti> daniels: and warty within a week?
<bob2> lamont: what's with the control characters in /usr/share/doc/postfix/VIRTUAL_README.gz?
<daniels> pitti: ok, i'll try
<pitti> daniels: at least this time the patch is easy
<pitti> daniels: I still remember the mess with the previous xpm patch
<daniels> yeah
<daniels> where we got up to the 7th or 8th version
<daniels> As I mentioned before along with my first review. This is just the tip of the
<daniels> iceberg... unfortunately. There are more values from untrusted sources (image
<daniels> files) which are used carelessly in loops and asignments.
<daniels> :\
<pitti> daniels: would it make sense for hoary to remove xpm library support from X at all?
<pitti> daniels: oh no, half a gazillion packages depend on it
<pitti> daniels: so this waits for the massive X split then
<daniels> pitti: unfortunately gtk and stuff depends on it
<daniels> i think gecko as well
<daniels> but if we could easily remove xpm support from those apps, then it is SERIOUSLY worth considering
<daniels> pitti: you know what -- I think it's doable
<pitti> daniels: you mean to package libxpm separately?
<daniels> pitti: i mean to put libxpm in universe for hoary
<pitti> daniels: hm, that would already be a step forward
<pitti> and it should be hoaryable
<daniels> yes
<daniels> it touches -- groff, xpdf, and a couple of others
<jdub> hah
<jdub> woops
<jdub> february is rather short, isn't it? ;)
* jdub breaks out the pr0n
<Treenaks> LOL
<rburton> haha
<Treenaks> jdub: maybe you should break out the cron too :P
<jdub> :)
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<maswan> jdubpr0n?
<Mithrandir> maswan: we'll GRAB his bandwith. :)
<Mithrandir> I should probably add some sound as well
<Treenaks> Mithrandir: to MithrandirTV?
<Mithrandir> Treenaks: no, just so I can hear what he's saying and stuff
<Mithrandir> I don't broadcast myself.
<Treenaks> Mithrandir: ah on the receiving end
<Mithrandir> yup
<Mithrandir> jdub: the buffering seems to be a bit tight -- never above 12-ish percent in totem
<rburton> whoa, zoomed in jdub
<Treenaks> with fadey edges!
<Mithrandir> indeed
<Treenaks> Guest Stars!
<Mithrandir> and the sound is a bit low
<Mithrandir> I want a decent way to mix multiple streams so I can tune their volumes since right now, jdub isn't noisy enough.
<sivang> jdub: is this you?
<sivang> morning all!
<rburton> man jdub is nuts
<Treenaks> rburton: what else is new
<pitti> Hi sivang
<rburton> Treenaks: erm. yeah, sorry for the useless statement
<rburton> :)
<Treenaks> rburton: :P
<sabdfl> anybody else finding the 6.8.2 Xorg packages cause problems?
<Mithrandir> sabdfl: sorry I didn't answer you about the amd64 and ooo2 stuff, but my network connection at FOSDEM was spotty at the best.
<Mithrandir> sabdfl: I don't know what the current state of ooo2 and amd64 is, but if it builds and works, it should work fine on ia64 as well, I'd imagine.
<sabdfl> Mithrandir: it's not building on either
<sabdfl> if you can get it to build on amd64 it will probably go straight through on ia64 and t-bone will love you
<sivang> pitti: Hi Martin! :)
<Mithrandir> sabdfl: I can take a look, but no promises.
<sabdfl> so the new X packages work for everyone else but me? *grumble*
<sabdfl> Mithrandir: np
<sivang> sabdfl: I havn't upgraded since yesterday, doing now and will test also on the dell lappie, what machiens have you tried?
<sabdfl> desktop box, fglrx driver
<sabdfl> was working very nicely with previous packages
<sivang> sabdfl: eh, then I have Nvidia, sorry :-/
<Treenaks> sabdfl: did the fglrx drivers get updated along with X?
<smurfix> sabdfl: I vahe a laptop with fglrx, will try asap
* pitti never got any box running with fglrx
<smurfix> s/vah/hav
<smurfix> pitti: It gets worse. My desktop has an ati 700 with nonstandard wiring, neither fglrx nor radeonfb work with it
<smurfix> 9700
<sabdfl> ati laptops are often customised beyond the point that the public drivers will work
* smurfix is really annoyed about that
<smurfix> sabdfl: true -- radeonfb doesn't work on the laptop :-/
<daniels> smurfix: hmm, does the standard radeon driver for X work with it?
<sabdfl> ah... comes up fine with open source ati driver, but not with fglrx
<daniels> sabdfl: hmm, fglrx's broken with yours
<mjg59> smurfix: Hm. Radeonfb is no great loss.
<daniels> ah shit.  i really hope we don't have to update fglrx mid-freeze; can't think of anything that's changed there.
<smurfix> daniels: "it" == desktop or laptop?
<sabdfl> daniels: fglrx was working perfectly yesterday, i was going to mail you and say "wow"
<daniels> smurfix: the one you were complaining was broken
<sabdfl> very fast
<daniels> sabdfl: heh :) well, if it doesn't work with 6.8.2, i'll roll packages with the new version
<sabdfl> daniels: good work onthe opengl front, btw, was that you?
<martink> Mithrandir, upstream has patches to make ooo2 build on amd64 <http://blog.janik.cz/archives/2005-02-27T11_12_36.html> but it's not usable. And a successful amd64 port != ia64 port. There are assembler parts that need to be hand written for each c++ compiler abi
<smurfix> daniels: The standard driver is broken on the laptop, no display
<daniels> sabdfl: which opengl stuff?
<mjg59> sabdfl: Suspend to disk on Apple seems to work
<daniels> sabdfl: i've done a lot of stuff recently
<sabdfl> seems to auto-detect whether or not the ATI opengl will work, and use that, otherwise uses Mesa
<daniels> smurfix: oh wow, that's pretty impressive.  could you please send along an Xorg.0.log and xorg.conf?
<daniels> sabdfl: sadly I can't take the credit; that was ATI
<smurfix> daniels: on the desktop, both drivers give me really funky display artefacts which unfortunately are not conducive to doing actual work :-/
<Mithrandir> martink: why does OOO have hand-written assembler?  That's just _wrong_
<daniels> smurfix: ack
<smurfix> daniels: I'll 
<sabdfl> Mithrandir: yowser
<smurfix> ... do that
<mjg59> sabdfl: So we've got some degree of suspend support on all Apple laptops, and suspend to RAM on most of them
<martink> Mithrandir, somewhere deep inside its component system it does weird stuff with C++ virtual function tables
<Mithrandir> martink: it's wrong, I'm sure. :)
<daniels> holy shit, major bugzilla bustage
<daniels> jdub: check out the submitter name in https://bugzilla.ubuntu.com/show_bug.cgi?id=7019
<Treenaks> nice one
<jdub> ouch :)
<jdub> justdave: https://bugzilla.ubuntu.com/show_bug.cgi?id=7019
<d3vic3> heh
<lu|cookie> are you sure the submitter didn't actually put that as their name?
<jdub> jdubtv is back up
<d3vic3> jdubtv ?
<seb128> jdub: we should move evince in ship 
<Treenaks> jdub: hoary should have a "jdubtv" bookmark of some kind by default.. or a default "recently used" entry
<smurfix> sabdfl, daniels: the new X with fglrx works fine on my laptop.
<jdub> seb128: ship?
<jdub> d3vic3: http://node.waugh.id.au:8800/
<seb128> jdub: ship seed ?
<jdub> seb128: ship implies supported :)
* ajmitch watches the jdub tv
<seb128> jdub: you don't want to support evince ?
<seb128> jdub: dude
<jdub> seb128: from my pov, we should either ship it in desktop or not support it :)
<seb128> if you want to take me here, desktop and default viewer :p
<jdub> it's very tempting
<seb128> xpdf is ugly
<seb128> c'mon
* lu|cookie was boggled to see that xpdf was your default
<daniels> isn't gpdf the default in hoary?
<seb128> type3 fonts/gpdf, bong
<seb128> daniels: nop
<luis_> yeah
<luis_> I assume you've tested that in evince?
* luis_ has not
<daniels> wack
<seb128> yep
<seb128> evince rocks
<Astharot> 'morning
<daniels> xpdf is pretty hideous, really
<daniels> and doesn't it use lpr for printing?
<Treenaks> daniels: it uses "please enter a command here" for printing
<pitti> does evince support fullscreen?
<daniels> luis_: when i got the original bug report, that certainly wasn't the name, so either bz mangled it, or they did (badly)
<seb128> pitti: yep
<daniels> Treenaks: whoohoo!
<pitti> cool
<seb128> pitti: F11
<smurfix> Gaah
<jdub> seb128: hrrrrrrrrmrmrmrmr
<seb128> jdub: bah, starts evince and xpdf and look
<smurfix> daniels: "startx -- -layout test :1" starts an X server on :1 but then runs the Gnome session stuff on :0
<seb128> jdub: how can we ship _that_ :p
<smurfix> daniels: The good part is that the ati driver now works on the laptop
<seb128> libtool: link: cannot find the library `/usr/lib/libhowl.la'
<seb128> graaaah
* Mithrandir gives seb128 some libtool love
<luis_> daniels: query for other bugs where that user has commented, see if they are busted too
<seb128> removing libhowl from libgnomevfs2 breaks other stuffs
<seb128> is there something to do to fix that out of rebuilding the differents lib with the new gnomevfs ?
<Mithrandir> seb128: sounds like said other stuff is built with old, broken libtools.
<jdub> seb128: -Wl,--as-needed :-)
<jdub> seb128: nothing else you can do, given the depends
<Mithrandir> seb128: so probably not, no.
<seb128> jdub: I'm tempted to do that
<daniels> smurfix: cool.  as for the gnome stuff, yeah, that's wack.  you just can't run two gnome sessions as the same user on the same machine.
<mvo> pitti: do you know of any compatibility issues of the langpacks with python-gettext? I have some strange issues here that some strings are not translated when they are in the locale-langpack directory (but work fine in the normal locale-directory)
<pitti> mvo: are they present in both directories?
<smurfix> daniels: is that related to the multihead stuff? 'Cause it worked before
<pitti> mvo: does python-gettext use libintl from glibc or its own implementation?
<mvo> pitti: no idea 
<jdub> seb128: will we have the switched Preferences and Administration in the next panel?
<daniels> smurfix: nope, totally unrelated -- I've never been able to start two GNOME sessions as the same user on the same machine.  ask jdub :)
<mvo> pitti: I'll check. 
<pitti> mvo: strace
<pitti> mvo: that'll display you the files it looks for
<seb128> jdub: today or tomorrow yep, today is a busy day
<seb128> jdub: I've these howl issues
<seb128> jdub: and they just changed the libwnck soname ... nice :/
<seb128> jdub: so probably tomorrow
<seb128> time to package the new tarballs, fix howl depends and migrate to the new wnck
<mvo> pitti: looks in both dirs and find the mo file in the langpack dir
<jdub> seb128: boh!
<mvo> pitti: it still makes a differences, some strings in locale-langpack are not translated even if the mo file is exactly the same. any idea what could cause that?
<pitti> mvo: hmm, odd. It can correctly open the mo file?
<mvo> pitti: strace looks fine and a lot of the messages are translated it seems
<pitti> mvo: hmm, hard to tell without the code and mo files
<pitti> Kamion: just wanted to update the seeds
<pitti> Kamion: baz update -> "trouble reading checksum file for ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-155"
<pitti> Kamion: any idea?
<pitti> Kamion: sorted it out, nevermind
<pitti> elmo_: I updated the language packs. There are three new languages requiring NEW love, I already seeded them. (not urgent, though)
<mvo> pitti: just checked the python source, the gettext module is implemented independently from the libc gettext implementation 
<pitti> mvo: so python-gettext needs the same patch
<mvo> pitti: yes, where is your original patch archived? I would like to use the same logic
<pitti> mvo: p.u.c/~pitti/ubuntu-altlocaledir.dpatch
<pitti> mvo: I extracted this dpatch from the glibc sources
<mvo> pitti: thanks
<pitti> seb128: evince is b0rken. Whenever I open the menu, cpu goes to 100% and the program hangs
<seb128> bt please
<seb128> no such bug in the BTS or bugzilla
<pitti> seb128: shall I file it in gnome's? it's universe, so ours is not appropriate
<seb128> should be main
<seb128> can you get a backtrace on http://rafb.net/paste/ ?
<pitti> seb128: it's universe
<jdub> pitti: seb has wishful thinking
<seb128> pitti: yeah, but I want it as the default viewer
<seb128> pitti: so I care about the bugs, universe or not
<pitti> seb128: hmm, I know what's wrong. A few seconds after startup, it begins to generate preview images
<Kamion> pitti: what was it?
<pitti> Kamion: a missing public key in my keyring. The message could be a little less misleading though...
<seb128> pitti: you start it on a document ?
<pitti> seb128: yes
<seb128> oh
<seb128> so different issue :)
<seb128> pdf file ?
<seb128> xpdf handles it fine ?
<pitti> seb128: yes, the preview generation was started a little later after displaying the first page
<pitti> seb128: but that's awful
<pitti> seb128: with a 153 page diploma thesis, previews take a minute
<pitti> seb128: yes, xpdf does it fine
<seb128> you don't need to use the preview pane
<pitti> seb128: even if I switch to "contents" (from preview) immediately, it still generates previews
<seb128> and you can switch the pane to "index"
<seb128> close it :p
<seb128> BTW can you put the pdf somewhere ?
* pitti tries to click and sees no reaction
<seb128> I want to try here
<Kamion> pitti: hah
<pitti> seb128: bah, it is totally unresponsive
<pitti> seb128: I put it on p.u.c
<seb128> thanks
* thom continues on his apache 1.3 killing spree
<pitti> seb128: p.u.c./~pitti/diplom.pdf
<seb128> just tried on a 110 pages pdf here
<seb128> takes ~2s to make the thumbnailing
<seb128> "You don't have permission to access /~pitti/diplom.pdf on this server."
<pitti> seb128: if I just start "evince" without a document, and then open it from the menubar, then I don't have a preview pane,but still the CPU rattles
<pitti> seb128: fixed
<seb128> ~4s to make the whole thumbnailing here
<seb128> for the 134 pages
<seb128> there is an issue on your box, can you get a bt ?
<pitti> seb128: no, I deactivated the preview pane, now it does not appear any more, but it still takes ages
<seb128> do you have message in the logs ?
<pitti> seb128: nothing on stdout
<seb128> have you just installed it ?
<pitti> seb128: I'm on a Duron 1.3, not the fastest thing out ther
<pitti> seb128: yes, installed 5 minutes ago
<seb128> killall gconfd-2 ?
<seb128> perhaps that's a config issue
<pitti> seb128: tried that. preview generation still lasts over 1 minute
<seb128> and it eats CPU without opening a document ?
<pitti> seb128: it opens the document
<seb128> when you launch "evince" it opens a document ? 
<pitti> seb128: but clicks, scrolls, etc. are delayed by several seconds (unresponsive)
<pitti> seb128: no, I launched "evince diplom.pdf"
<seb128> k
<seb128> and I you close the preview pane
<seb128> and restart it 
<Kamion> mjg59: so you said that suspend-to-disk works on Apples; how did whoever it was get the userspace support set up?
<seb128> is it slow ?
<pitti> seb128: however, same thing if I just start "evince" and open the file from the menu
<mjg59> Kamion: In what way?
<pitti> seb128: as I said, even if the pane is disabled, it still genreates the previews (it shouldn't)
<mjg59> Kamion: At the moment, you need to do it by hand
<pitti> seb128: -> it is still slow and unresponsive
<seb128> pitti: right, please fill a bug upstream :)
<pitti> seb128: okay, I do
<seb128> thanks
<pitti> seb128: already there: #165413, and even more #166825
<seb128> k, right
<seb128> so I guess we will stick with xpdf for hoary :/
<pitti> seb128: well, other than that it's quite nice, and even more, it's translatable (which xpdf isn't)
<seb128> yeah :)
<pitti> seb128: so if we could just disable thumbnails, it would be a nice thing
<seb128> and it uses the gnome-pritting system
<seb128> printing
<Kamion> mjg59: that's what I meant; any hints? :)
<Kamion> mjg59: I tried echoing disk to /sys/power/state from a power script, and my machine certainly suspended, but didn't resume
<mjg59> Kamion: You need the resume argument set in /etc/mkinitrd/mkinitrd.conf and to regenerate your initrd
<Kamion> ok
<mjg59> If you've got any USB devices, you'll also want to unload the USB modules before suspend and reload them on resume
<zul> morning
<seb128> elmo_: here ?
<rburton> hm, the hoary gmime-cil packages don't want to work
<Keybuk> thom: fix firefox
<Mithrandir> Keybuk: libtool makes me want to stab myself.
<Keybuk> Mithrandir: want to maintain it?
<Keybuk> that's how I felt when I started
<Mithrandir> do I look totally crazy, insane and out of my mind?
<Mithrandir> it's convoluted three times within itself.
<Mithrandir> it's just wrong and evil
<Keybuk> actually, yes
<Keybuk> you do
<Mithrandir> *sigh* :)
<Mithrandir> I'm not taking it.
<Mithrandir> I'm making you a multiarch patch, though
<Keybuk> aww
<Keybuk> I'll have to sweet-talk vorlon then I guess
<Mithrandir> it doesn't need to go into sarge
<Mithrandir> (or hoary)
<Keybuk> NMU it in :P
<Mithrandir> anything using multiarched libtoolised libs will have to be relibtoolised anyhow.
<Mithrandir> sys_lib_dlsearch_path_spec=" /lib/i386-linux /usr/lib/i386-linux /usr/X11R6/lib/i386-linux /lib64/i386-linux /usr/lib64/i386-linux /usr/X11R6/lib64/i386-linux"
<Mithrandir> muhahahahah
* Mithrandir kicks himself.
<Mithrandir> Thou shall not work outside version controlled directories.
<daniels> hear hear
<Mithrandir> (especially not when getting dirty with libtool)
<Simira> hey! The only you're allowed to get dirty with is me!
* Treenaks ponders starting his very own Ubuntu-quotefile
<thom> Keybuk: there's nothing wrong with firefox
<daniels> thom: is that why you use epiphany?
<thom> daniels: not true any more
<daniels> wow-ee
<Mithrandir> Simira: not that kind of dirty.  Just my hands, dear.
<dholbach> hi
<jdub> thom: ...?
<Simira> Mithrandir: dirty hands, eh?
* Mithrandir ruffles Simira 
<thom> jdub: ?
<Keybuk> thom: I'm getting pop-unders!
<Keybuk> fix it! fix it! fix it!
<thom> Keybuk: IZ GTK BOOG
<sivang> thom: for sure :)
<zul> Keybuk i can see thom postal 
<thom> well, metacity probably
<daniels> thom: totally
<Keybuk> is firefox bug for not blocking them in the first place :)
<thom> pfft
<daniels> i wish seb would fix gtk's input method so it would get the keymap out of the d-i selection also
<thom> i get no popup
<thom> s
<Keybuk> itv-f1.com is the most annoying example
<daniels> having all these bugs assigned to xorg for xkb is totally lame
<Keybuk> thom: read the news, someone figured out a way round the pop-up blocker and suddenly everyone's doing it :-/
<daniels> Keybuk: wfm hth hand kthxbye
<thom> Keybuk: sorry, no popups here
<daniels> 'Firefox prevented this site from opening a popup window.  Click here for options...'
<mvo> ping doko
<Keybuk> hmm, ok; ignore that one :)  that one was in my allowed list
<Keybuk> but there was other sites that do it now :(
<thom> rofl
<thom> lamer :P
<doko> mvo: pong
<Keybuk> thom: fix rpm :p
<daniels> Keybuk: fix hct :P
<thom> Keybuk: clear it with mdz
<Keybuk> daniels: is fixed :)  will be a new release in a couple of weeks
<daniels> Keybuk: where's the couple of weeks come from if it's already fixed, eh?
<Keybuk> daniels: sourcerer
<Keybuk> want that to be finished this week, so source package imports can happen
* Mithrandir chuckles
<Keybuk> From: 	Debian Installer <installer@ftp-master.debian.org>
<Keybuk> torkel: 	Rob Weir <rob@ertius.org>, Rob Weir <keybuk-sponsoring-rweir@debian.org>
<Keybuk> Subject: 	bazaar_1.1.1-1_i386.changes ACCEPTED
<Keybuk> awwh
<Keybuk> bob2's first package
<pitti> woot
<pitti> bob2: congrats
<daniels> keybuk-sponsoring-rweir@? :P
<Kamion> Keybuk: yeeees, including the extra-special "let's use a version number already used in Ubuntu but for a non-identical package"
<Keybuk> daniels: actually, in reality, bob2 had /nothing/ to do with it -- I just didn't want to maintain another Debian package so did it in his name :p
<Keybuk> Kamion: it's an identical package :p  and you should've uploaded the ubuntu one as 0ubuntu1 /technically/
<Kamion> Keybuk: dude, can you imagine the grief I'd've got if I uploaded Canonical software as 0ubuntu1?
<daniels> Kamion: whoohoo!  (he says, having just uploaded xorg_6.8.2-1)
<torkel> Keybuk: autocompletion in xchat? :-)
<Keybuk> torkel: I guess
<Keybuk> Kamion: yeah :)
<Treenaks> daniels: to sid? :P
<daniels> Kamion: oh and btw, it's Canonical Ltd, not Canonical Software ;)
<Kamion> daniels: screw you hippy :)
<Keybuk> bob2 got to be maintainer because he wasn't around to ask
<Micksa> woo, hoary knows how to handle the grub config for a separate /boot
<Keybuk> (and thus say no)
<Micksa> awesome
<bob2> haha
<daniels> Treenaks: nope, I don't have a key in the keyring these days
<Keybuk> daniels: That's Canonical, spelt F. I. E. L. D. W. A. V. E.
<daniels> (need to find a friendly local DD to sponsor me)
<daniels> Keybuk: no, I work for Canonical
<bob2> Keybuk: only for your UK hacks
<Micksa> Keybuk: 123NOTIT
<bob2> the rest of us work for a real company
<Keybuk> we work for the same company as Mark and Jane :p
<bob2> hahaha
<Kamion> woot, that's NFS support in kickseed, I think
<Kamion> well, half of it. and missing the minor detail of kernel udeb support just yet, but ...
<Keybuk> Kamion: details, details *mere* details
<Micksa> *sigh* if only KVM switches weren't evil
<zul> Kamion: ill bug t-bone about the nfs udeb wehn he is on
<lamont> bob2: nroff formatting, I expect - they all have overstrikes in them
<zul> hey lamont i didnt think you would be up
<lamont> morning email strafing run
<zul> ah
<lamont> then I disappear for an hour
<lamont> speaking of which...
<lamont> anything before I run away?
<zul> nah we just have to bug t-bone today
<Kamion> lamont: nroff> GROFF_NO_SGR=1 and a pipe to col -b might be a plan, if you want just plain text
<lamont> Kamion: I'm just delivering upstreams files.  He's the one formatting them... :-)
<bob2> lamont: ah
<lamont> been that way forever
<lamont> speaking of disappearing... bbiab
<zul> same here
<tseng> woo i think my kernel package is finally building
<tseng> fell asleep last night staring at it applying and reverting patches a few dozen times
<tseng> zul: your enable-inotify will need updating. havent looked at it yet
<zul> ok ill look at it this afternoon when i get back
<tseng> fs/read_write.c: In function `vfs_read':
<tseng> fs/read_write.c:234: error: `inode' undeclared (first use in this function)
<tseng> huh wow
<zul> tseng: yeah thats what i got
<tseng> =/
<Micksa> xorg can't seem to use my mouse through the KVM :(
<zul> tseng: i have to go shovel :(
<tseng> ok
<trulux> my upgrade is broken (
<tseng> inotify.c defines
<tseng> +       struct inode            *inode; /* associated inode */
<seb128> lamont: here ?
<Mithrandir> seb128: 15:02 < lamont> speaking of disappearing... bbiab
<trulux> tseng: that smells something from fs kernel code :)
<seb128> arg
<seb128> Mithrandir: thanks
<tseng> trulux: its inotify. it wont build atm
<trulux> umm
<trulux> lemme check
<tseng> 0.19-2
<trulux> vfs_read... just an advice, since 7 weeks ago, many API has changed
<trulux> among the networking structures
<trulux> and such
<trulux> contact upstream
<Keybuk> tseng: that's got to be an entrant for the "most useless comment" award
<Keybuk> YES, HE KNOWS IT'S A MULTIPASS^WINODE
<tseng> heh yeah..
<trulux> it seems to be that inode structure is not initialized (or might be used not initialized, passed as argument to function)
<Keybuk> i++;  /* increment i *.
<Keybuk> ...no, really?
<tseng> what I dont see yet in the patch is read_write.c referencing inode
<Kamion> er gcc is saying "undeclared", dude, not "uninitialized"
<tseng> guess I need to dig up the full file
<Keybuk> probably a , instead of a .
<Keybuk> ptr,inode not ptr.inode
<trulux> Kamion: yes, but some structures need to be used as simple argument-passed pointers &
<tseng> oh, ill look for that
<tseng> (my C isnt that amazing)
<trulux> Keybuk: anyways, without having the thingy here I can't check further
<trulux> and
<trulux> Keybuk: undeclared is definitily that *node is missing either in args or initialized within the function
<tseng> actually, read_write.c declares inode locally
<trulux> *inode
<trulux> tseng: what context?
<tseng> hm but wrong function
* trulux nees to drink, he has walked for hour and a half 
<Kamion> again, please don't say "initialized" when you mean "declared"
<Kamion> they are DIFFERENT THINGS
<trulux> sure, I think I have worked a bit with the fs api, among JFFS3 which I'm working for xattr support ;P
<trulux> and noter the either, n
<trulux> btw
<tseng> vfs_{read,write} call fsnotify_modify(dentry, inode, dentry->d_name.name);
<trulux> pitti: there?
<tseng> which does look inotify-related
<trulux> tseng: btw, this is the last error:
<trulux> dpkg: error al procesar /var/cache/apt/archives/mozilla-firefox_1.0+dfsg.1-6ubuntu1_i386.deb (--unpack):
<trulux>  intentando sobreescribir `/usr/lib/mozilla-firefox/defaults/profile', que est tambin en el paquete mozilla-firefox-locale-es
<pitti> trulux: yes
<trulux> pitti: we have worked on the gcc-3.4-ssp, but it won't compile (yet)  and we are lacking of testing machines again
<smurfix> daniels: mail with the keymap translation table sent to you
<daniels> smurfix: cool, thanks
<tseng> hm this must already be fixed in our kernel package somewhere
<tseng> a diff between .18-16 and .19-2 yields only
<tseng> -+	spin_unlock(&dev->lock);
<tseng> ++	//spin_unlock(&dev->lock);
<trulux> fixed upgrade
<trulux> this is going fast now :)
<pitti> seb128: indeed I found the same patch as in upstream cvs for gnome-cups-manager
<pitti> seb128: however, there is even another bug, it crashes with a SIGPIPE when I use cups browsing
<seb128> pitti: ups, forgotten to try that yesterday
<pitti> seb128: I'm debugging this ATM
<pitti> seb128: I just did
<seb128> k
<seb128> thanks
<pitti> seb128: this thing tries to use an existing http connection, but when you restart cups, you get a SIGPIPE
<Kamion> lamont,elmo_: any idea why I haven't been getting daily d-i builds on powerpc for a while?
<seb128> gcm uses an http connection ?
<lu|away> seb128: yes
<lu|away> IIRC
<lu|away> you'd want to ask jody
<pitti> seb128: do you know of any glib wrapper around signal(2)?
<sivang> pitti: what does it use the http connection for?
<pitti> seb128: currently I cheat this away with "signal (13, SIG_IGN)"
<pitti> seb128: but this is not a portable solution for upstream
<pitti> seb128: libgnomecups uses libcups, which provides a C API to cups
<pitti> seb128: but all communication with cups always happens through http
<pitti> seb128: it basically uses http://localhost:631
<pitti> seb128: that's the very reason why we cannot disable the web interface :-)
<seb128> but the interface doesn't work IIRC
<pitti> seb128: we only disabled the administrative functions with http authentication
<seb128> oh right
<pitti> seb128: the unauthorized functions work well
<pitti> and have to, because it is CUPS' only interface
<seb128> pitti: for network stuff you can look on g_io_channel_*
<seb128> oh, you are looking for signals handler, not network stuff
<seb128> hum, dunno
<Mithrandir> thom: is there some way to turn off "web pages can set hotkeys" in m-f?
<thom> Mithrandir: no clue
<Mithrandir> thom: it bites me each time I'm on the wiki and press alt-d to go to the address field.
<Mithrandir> Keybuk: http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/libtool--multiarch--0--patch-1?cmd=cs_mod&file=libtool.m4
<trulux> who maintains firefox packages?
<Mithrandir> trulux: thom
<thom> it's a lie!
<trulux> Mithrandir: ok, danke sehn
<trulux> thom: hah, I'm having trouble with them :)
<thom> trulux: itanium?
<trulux> thom: nop, just a simple x86
<thom> ok, what's the problem?
<trulux> thom: Updating mozilla-firefox chrome registry...E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
<trulux> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
<trulux> dpkg: error processing mozilla-firefox-locale-es (--remove):
<trulux>  subprocess post-removal script returned error exit status 1
<trulux> Removing mozilla-firefox-locale-es-es ...
<trulux> Updating mozilla-firefox chrome registry...E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
<trulux> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
<trulux> dpkg: error processing mozilla-firefox-locale-es-es (--remove):
<trulux>  subprocess post-removal script returned error exit status 1
<trulux> Errors were encountered while processing:
<thom> woah
<trulux>  mozilla-firefox-locale-es
<trulux>  mozilla-firefox-locale-es-es
<thom> stop!
<trulux> flood
<trulux> sorry
* trulux overlapped windows while trying to paste at rafvb
<trulux> rafvb
<trulux> rafb
<trulux> :)
<thom> there's nothing higher up?
<trulux> I think these packages are unofficial ones that I installed first boot after warty was installed
<trulux> I don't think so
<thom> trulux: um, you lose then; i've enough to do without supporting unofficial broken packages
<trulux> thom: err, one moment
<trulux> I'm not sure if these are unofficial
<trulux> just lemme check
<trulux> thom: Version: 0.9.3-1ubuntu1
<trulux> official
<trulux> AFAIK
<trulux> :)
<Kamion> mvo: #6865 seems to be fixed now; anything more before closing it?
* mvo looks
<thom> trulux: official, but not something that shipped with warty
<mvo> Kamion: no, think it's fine. I'll close it now
<Kamion> ok, cool
<Kamion> it works for me anyhow
<trulux> thom: err, fixed
<trulux> thom: just that my teddy bear was not around :)
<mvo> Kamion: the current apt contains a patch that scores pathes without symlinks on a cdrom high. that means that it will add "deb cdrom:[]  hoary main" to the sources.list. it will also do this with debian cds (deb cdrom:[]  sarge main). could this be a problem for debian (and it's d-i)?
<pitti> seb128: I think I've found a workaround
<pitti> seb128: gnome #168881
<Kamion> mvo: you'd have to ask joeyh, I can never remember exactly what assumptions are made; it might be a problem
<jdub> thom: you're using firefox now?
<thom> jdub: yeah
<HcE> when compiling a kernel with initrd, should I have cramfs as a module or built-in?
<HcE> whops, wrong #
<mvo> Kamion: I send a mail to joeyh describing the changes and asking for his opinion
<doko> elmo: please could you import drdsl from unstable/non-free ?
<jdub> thom: http://christopher.aillon.org/blog/dev/mozilla/20050228-pango.html
<zul> jdub: tseng and i did a diff of inotify 0.18 and inotify 0.19 and we are going to see what it does
<thom> jdub: ...
<thom> we enabled it by default ages ago
<tseng> jdub: if you want a full error message to pass to rml I can dig it out again
<tseng> its starting to look quite odd considering the .19 patch is a one line change from ours
* Mithrandir kicks libtool
<Keybuk> Mithrandir: *shrug*  you're the maintainer :p
<Mithrandir> Keybuk: I'm not
<Keybuk> are too, I just uploaded changing tha Maintainer field *cackle*
<Mithrandir> Keybuk: I adopted pkg-config, that's a _nice_ thing in comparison
<Keybuk> (* note: possible lie)
<Mithrandir> *chuckle*
<Mithrandir> you're too kind for that
<Mithrandir> (and no, that was not a challenge)
<Gagatan> hynfhynf
<Keybuk> I'm _so_ not
<Keybuk> I am seriously considering RFAing it though
<Kamion> mvo: ok
<jdub> thom: mmm, i thought you said you were going to disable it, as it was the source of our font rendering problems
<jdub> zul, tseng: thanks
<Mithrandir> Keybuk: releasing pkg-config is just make dist and put the tarball somewhere sensible?
<Keybuk> Mithrandir: no idea, never did it :p
<Keybuk> ask daniels
<thom> jdub: no, i fixed the rendering problems
<Mithrandir> daniels: ^^^
<thom> or, caillon did and i stole it
<jdub> thom: i still have bollocky font foo in textareas
<thom> jdub: even seb is happy
<Mithrandir> oh, multiarch will be soooo much fun.
<torkel> daniels: re #4343, it finnaly works. Thanks!
<ogra> pitti:
<ogra> ping
<pitti> ogra: Hey, how are you
<ogra> nearly ready with the fixes ;)
<ogra> pitti: do you think its ok to have hal-dmiwrapper in /usr/bin ? or should it be in /usr/sbin in any case, since its a suid executable....
<pitti> ogra: I'd rather have it in /usr/lib/hal
* Mithrandir kicks Keybuk too.
<Mithrandir> -e 's:^\(sys_lib_search_path_spec\)=.*:\1="/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib
<Mithrandir> that's evil.
<pitti> ogra: because normal users aren't supposed to execute it
<pitti> ogra: remember, every program in /usr/bin or /usr/sbin/ requires a manpage
<ogra> ah, ok.....
<Keybuk> Mithrandir: there's more evil things in debian/rules than that
<Mithrandir> Keybuk: dude, I've tried to work out why my change didn't propagate to the package. :P
<Keybuk> Mithrandir: libtool uses gcc -print-search-dirs to seed that
<Keybuk> and it means you get totally the wrong things in there
<Keybuk> like no X11R6
<Keybuk> and gcc-specific version information
<Keybuk> so I just hard-code it on Debian, where the search path is known and well-documented :p
<Mithrandir> Keybuk: I know, I know, but still.
<Keybuk> it only affects /usr/bin/libtool
<Keybuk> not source packages made on Debian
<Mithrandir> it seems it creeps in; at least just changing the libtool.m4 wasn't enough.
<Keybuk> how did you change libtool.m4?
<Mithrandir> emacs
<Mithrandir> :P
<Keybuk> remembering that on Debian's libtool, sys_lib_dlsearch_path_spec is built by parsing ld.so.conf
<Mithrandir> yes, and I append evilness to that
<Mithrandir> http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/libtool--multiarch--0--patch-1?cmd=cs_mod&file=libtool.m4 is the patch
<Keybuk> mmm, patchy
<Mithrandir> (it's wrong, but it's not totally wrong :)
<lamont> Kamion: ENOROSS
<rburton> i'm a ross! use me!
<Kamion> lamont: long-term?
<lamont> gah.  ELAMONTBRAINDEAD
<lamont> Kamion: ross is alive, but disabled.  I need to double check with elmo and make sure he's really done with it, then I can turn things back on (and do a d-i build for you)
<sabdfl> :-)
<sabdfl> you guys are nuts. fortunately our partners don't mind.
<Kamion> lamont: ok, cool; of course new upload coming today anyway ...
<lamont> of course
<Kamion> lamont: but I'll need the daily d-i build tomorrow to pick up the new kernel upload, probably
<lamont> right
<Kamion> well, failing that I can always do an upload ...
<lamont> given that ross has been up for 3 days, I think elmo might be done with it... :-)
<lamont> nah - worst case I'll  move it to another machine
<lamont> but I think we're golden
<thom> dholbach: nice report!
<lamont> ah, that's what happened
<ogra> pitti: how do i convince automake that hal-dmiwrapper actually gets installed in /usr/lib/hal ? i cant manage it to go anywhere else then /usr/bin :(
<lamont> elmo_: you around?
<dholbach> thom: thanks!
<dholbach> thom: felt it was time for it
<pitti> ogra: dunno, sorry
<ogra> hrm....
<pitti> ogra: if anything helps, don't install it in the Makefile.am at all
<pitti> ogra: and instead install it in debian/hal.install
<ogra> i did
<ogra> but it still must get build from the Makefile..... obvoiusly i use the wrong variables, since it gets installed with lshal and friends.... :(
<mvo> ogra: you could use (in Makefile.am): helperdir=$(libdir)/hal \n helper_SCRIPTS=hal-dmiwrapper
<lamont> Kamion: new daily running, just to grease the skids, so to speak
<ogra> mvo: wow, thanks :)
<mvo> ogra: see if it works first ;)
<ogra> heh, trying....
* ogra thinks this is so typical....fixing the patch takes 2hrs ..... finding the right automake vars then takes the whole day....grr
<lamont> ogra: you forgot to sacrifice the chicken
<Keybuk> lamont: that's scsi
<Keybuk> it's goats for autotools
<ogra> ahh, thats the prob.....
<Kamion> lamont: ta
* ogra goes to the farmer next door....
<Keybuk> the autotools book even clearly shows a goat about to be sacrificed on the cover
* lamont is reminded just how sick some of his cow-orkers are.  (self included)
<zul> what the plague?
<lamont> bazaar finally made it out of NEW on debian
<paul> hi, possibly a dumb question (i couldnt find anything on the website), but are there any plans for an AXP port?
<Keybuk> lamont: it wasn't in NEW for long
<Keybuk> I only uploaded it just over a week ago
<lamont> ah, ok.
<lamont> someone told me they'd uploaded it a while ago...  must be they were doing the upload by proxy or fantasy, eh?
<Keybuk> they lied, I expect
<Keybuk> bob2 was supposed to it eons ago
<Keybuk> lifeless tempted me with gin, and I did it in London
<Keybuk> (in bob2's name, of course; I don't want _bugs_)
<eruin> anyone here tracking junkie ?
<tseng> man is binding keys to commands in metacity ever a pain
<paul> i guess not so.
<dholbach> Kamion, lamont: you fixed all the  -lX -universe bugs? or shall i give them another try?
<Kamion> dholbach: I'm certain that my qt-x11-free change didn't get them all, but I don't know if lamont has done the give-back yet
<lamont> dholbach: I didn't fix any of them with my mail last night...  Just sent mail to let people know of the wonderful opportunity
<Kamion> dholbach: imms at least needs -L/usr/X11R6/lib added to linker flags somewhere
<Kamion> and there may be others
* ogra just found out that a libexec-PROGRAM is not a bin-PROGRAM heh.... how silly...
<Keybuk> gconftool --set --type=string apps/metacity/keybinding_commands/command_N "commmand args..."
<dholbach> Kamion, lamont: I'll put them on   wiki/MOTUTodo
<Kamion> like I say, I only bothered looking 'cos I want libqt-perl in main at some point. :)
<Keybuk> gconftool --set --type=string apps/metacity/global_keybindings/run_command_N "F99"
<dholbach> Kamion, lamont: or   wiki/UniverseMissingXinerama   even
<lamont> ever hear a cat walk down a piano keyboard?
<Kamion> dholbach: make it more general: UniverseXorgBuildProblems or something
<dredg> paul: nobody cares about your crazy notions :)
<dholbach> Kamion: i like many small lists :-)
<Kamion> mkay
<dholbach> Kamion: but will do
<paul> dredg: oh you get to annoy me on two channels now... dredg in stereo ;)
<dredg> :)
<paul> i'd donate cycles to a ubuntu alpha port, but i fear qemu/alpha on a modern machine would be faster than my 21164A/433MHz..
<tseng> i dunno about that, qemu is pretty slow
<paul> (if qemu had an alpha target)
<paul> tseng: nah, it's pretty quick.
<tseng> i tried running a livecd in it with gnome, it was dog slow
<paul> least x86 target hosted on x86-64..
<tseng> anyways..
<HiddenWolf> tseng: livecd's are always slow, imho
<luis_> <nod>
<luis_> unless you are on a fast drive,you aren't going to get decent performance on any liveCD
<mdz> morning
* lamont curses apt, fixes trusted.gpg yet again
<thom> hey mdz
<luis_> though clearly gnome could use help in the # of disc hits, etc.
<HiddenWolf> My roommate has an old laptop. 133mhz, che thinks it's quite snappy. I just purchased a slab of ram that's worth more than that thing
<dholbach> Kamion, lamont: done
<paul> tseng: qemu is far far faster than, eg, bochs.
<tseng> so rc5-mm1 has:
<paul> its quite tolerable.
<tseng> +inotify-locking-fix.patch
<tseng> lets look at that.
<paul> anyway.
<HiddenWolf> luis_: Yeah. Gnome is slow where winxp was quite snappy, all due to and old hdd
<tseng> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/inotify-locking-fix.patch
<tseng> hm I believe that is the same or similar change in .19
<HiddenWolf> tseng: tell me you didn't type out that url by hand.. 
<lamont> bbiab
<tseng> no, I know how to paste
* HiddenWolf relaxes
<tseng> go to his announce and then go up a dir, then back down into broken-out
<tseng> not too hard :P
<tseng> ill diff his inotify with ours as well
<tseng> but I think its .18-X
<tseng> hm hardly
* HiddenWolf would like to see an app to monitor disc health
<tseng> but diffs possibly between -mm and vanilla patches
<tseng> HiddenWolf: smartd or smartmon or so
<HiddenWolf> tseng: will any of those tell me "your disc is going to fail soon" in time?
<luis_> HiddenWolf: yeah, XP has done a lot of work to minimize disc hits
<tseng> thats their aim, but its not a foolproof magic bullet
* HiddenWolf wonders why the timestap on the .flac files he just ripped is jan 1st 1970
<thom> huh. why does bugzilla change me about dependency changes for a closed bug?
* thom closes another 5 bugs and whistles
* HiddenWolf thinks thom should make sure he saves some for the rest of us
<thom> HiddenWolf: you're welcome to the other 90 i have assigned to me
<trulux> language-pack-es seems broken :(
* HiddenWolf can't program his way out of a wet paper bag, but likes to hang out
<zul> HiddenWolf: your welcome to 145 to the kernel team
* HiddenWolf pionts to his previous statement. 
* lamont wanders off for a little bit
<thom> HiddenWolf: please don't message me stuff; but "my" packages include firefox, the laptop support stuff; apache2/php/mod_python etc and whatever else i get assigned
<HiddenWolf> thom: fix that silly missing icon in firefox. :)
<thom> HiddenWolf: every time you mention it, i'm ignoring firefox for an extra day :P
* HiddenWolf starts porting IE to gnome ;)
* zul smacks HiddenWolf 
* HiddenWolf hugs zul
<zul> hey jbailey 
* dholbach searches the big red button for the trapdoor beneath HiddenWolf 
<jbailey> Heya Chuck.
<zul> how is it going?
<jbailey> zul: w00t the power outages.  Have any up your way?
<zul> jbailey: nope...have you guys called the army yet? :)
<jbailey> Nah.  mayor mel retired.
<zul> oh yes..what an ass
<jbailey> The new one can read weather forecasts. =)
<zul> hehe
<jbailey> He was jus ton his way out when I moved here, but really.  That whole thing was the only thing I ever heard about him out west.
<zul> or when he went to kenya and made some racist comment
<jbailey> Yeah, that was afterI moved here.
<jbailey> *sigh*
<zul> anyways
<HiddenWolf> dholbach: I'll behave myself
<dholbach> HiddenWolf: you're lucky... didnt find the button :-)
<sabdfl> doko: what's with the -dfsg in the python2.4 packages?
<mirak> how does ubuntu update manager detects if there is new updates ?
<mirak> is there a cron task or something ?
<dholbach> mirak: yes
<mirak> hum, I can't see it i the list
<mirak> in
<ogra> pitti: you got mail :)
<doko> sabdfl: that's the upstream package with the python-profiler files removed. they have a non-free license.
<sabdfl> non-free how?
<sabdfl> dfsg is not a constraint on us
<doko> you are not allowed to re-use the code in a non-python context.
<ogra> doko: there is always multiverse....
<sabdfl> erg
<doko> see http://python.org/doc/2.4/lib/node829.html
<Kamion> ogra: python2.4-profiler | 2.4-3ubuntu1 | hoary/multiverse | all
<ogra> ah
<doko> it's addressed upstream, but maybe gets difficult to have the license changed.
<sabdfl> why on earth would guido want to retain that
<sabdfl> do you know if anyone has contact infoseek to get them to release the code under a more generally free licence?
<doko> yes, working on it, the answer from the author already is at http://mail.python.org/pipermail/python-dev/2005-February/051549.html
<sabdfl> doko: thanks for the clarification
<Kamion> mirak: /etc/cron.daily/apt
<doko> mdz, jdub: need to get libcairo1-dev from universe to support to build gcc-4.0. ok to change the seed?
<mirak> Kamion: thanks
<JanC> the author has no problem with releasing the python profiler, it's just that nobody knows who owns the code now IIRC?
<mdz> doko: you don't need to seed build-deps explicitly; germinate walks the tree
<mdz> at this point, since the Java stuff has not materialized, I'm not sure that we should be shipping gcc-4.0 in main at all
<mdz> that was its only purpose
<doko> well, yes, still hoping that jbailey will get eclipse in, and then the python plugin.
<wasabi> no chance
<wasabi> wait whens the deadline?
<Evaso> hi pitti
<doko> hi wasabi!
<wasabi> hi!
<wasabi> when would eclipse have to be in by?
<Evaso> pitti: i had send a mail to Devid Zeuthen the hal developer to find a common solution about pktcdvd
<wasabi> http://www.ubuntulinux.org/wiki/JavaPackagingProgress
<doko> wasabi: tonight, I'm unsure if it can/should go in after the preview release
<wasabi> oh, no chance.
<wasabi> java in ubuntu is so far from completion it's not funny. =)
<JanC> what's the best way to get a new translation in ubuntu when it's available in CVS upstream (as a .po file)?
<JanC> bugzilla, rosetta, ... ?
<Evaso> guys what about encrypted home directory in ubuntu with libpam-mount, are officially supported?
<ogra> doko, wasabi: its universe....if you take responsibility for the packages and think that four weeks are enough for bugfixing i think we still could get it in after preview.... (but only if you feel really safe with that)
<wasabi> i don't.
<ogra> ok
<ogra> heh
<T-Bone> Mithrandir: ping?
<wasabi> I do think however having gcj in might be nice.
<wasabi> Even without Eclipse, it is a useful development tool.
<wasabi> It would be the only way to run java programs in main for free.
<wasabi> right?
<ogra> at least it will ease getting eclipse in....
<wasabi> depends what drives inclusion: end user applications or development tools.
<ogra> ...but as i said, someone has to take responsibility (there are no updates after release)
<wasabi> gcj isn't my choice to make. =)
<wasabi> i can only say that eclipse will not make it
<mdz> doko: eclipse is not going to happen
<HiddenWolf> mdz: you just broke someone's heart
<wasabi> dude. if you don't like it, get working. ;)
<wasabi> http://www.ubuntulinux.org/wiki/JavaPackagingProgress
<mdz> (for Hoary)
<wasabi> eclipse packages are done, and have been done for months. But they have a massive dependency tree which isn't.
<mdz> right
<mdz> I have followed the frenetic pace of your wiki updates :-)
<wasabi> =)
<T-Bone> Kamion: ping?
<wasabi> i hacked that thing together last night because I kept forgetting what package i was working on . =(
<Kamion> T-Bone: pong
<T-Bone> Kamion: all bits needed for the kernel are in the baz archive i suppose? Anything I should be aware of before preparing the package?
<Kamion> T-Bone: you mean just my kernel change?
<Kamion> the nfs-modules thing?
<T-Bone> Kamion: yeah, whatever should go in the linux-image package
<T-Bone> for which you sent mail ;)
<Kamion> T-Bone: 'baz merge colin.watson@canonical.com--2005/kernel-debian--nfs-modules--2.6.10' should get you everything
<Kamion> T-Bone: it increments the kernel-wedge dependency, but nothing else special; not a large change
<T-Bone> Kamion: ok
<trulux> who handles language-pack-es?
<Kamion> trulux: pitti handles language-pack-*
<trulux> Kaloz: ok
<trulux> ERR
<trulux> Kamion :)
<seb128_> lamont: here ?
<trulux> Kamion: mine is broken or seems to:
<jani> I need advice on cross toolchain packaging,anybody?
<trulux> E: Couldn't configure pre-depend language-pack-es for language-pack-es-update, probably a dependency cycle.
<zul> seb128: he wondered out i think
<seb128> k
<seb128> elmo_: here ?
<Mithrandir> T-Bone: pong
<T-Bone> Mithrandir: still willing to have access to ia64? :)
<Mithrandir> yes, please.
<T-Bone> Mithrandir: mail me a login and a ssh v2 key at varenet@debian.org please (gpg-signed message)
<Mithrandir> will do
<jbailey> wasabi: Because of a power outage and stuff this morning, I'm not caught up, but I'm hoping to look more on why gij isn't building today.  I just have some other stuff to nail first.
<Mithrandir> T-Bone: sent
<elmo_> seb128: ?
<seb128> elmo_: have you sync glib 2.6.3 yesterday ?
<T-Bone> Mithrandir: got it. Give me five minutes
<elmo_> seb128: no, sorry, I didn't see you ask for it
<seb128> k, could you do it now ? :)
<elmo_> [NOT Updating - Modified]  glib2.0_2.6.2-0ubuntu1 (vs 2.6.3-1)
<seb128> and are you around for an hour or so ? I need to upgrade a new libwnck with a soname change and to get out of NEW quick to not break gnome-panel and a bunch of other desktop stuff
<elmo_> ok to override?
<seb128> yep
<elmo_> seb128: yeah, I'll be around the rest of the evening
<seb128> k, thanks
<sivang> eh, a new gnome
<Kamion> oh, hm, I should seed nfs-modules in advance
* Treenaks LOLs at Mako's www.unhappybirthday.com
<elmo_> I assume the "prompts me for a keyboard layout on upgrade" thing is fairly universal?
<elmo_> s/"/"X /
<mdz> doesn't sound familiar
<seb128> elmo_: do you have the power to kick eel2's build or do we need lamont for that ?
<elmo_> mdz: ah - well it prompted me on both i386 and ppc - to add insult to injury it prompted me twice on ppc
<elmo_> I'll file a bug...
<lamont> seb128: kicking
<seb128> thanks lamont 
<seb128> please kick all the builds having issues with libhowl.la
<seb128> I've kicked the depends out of libgnomevfs2 
<seb128> but a bunch of .la list it
<Mithrandir> T-Bone: no hurry; I have plenty other stuff to fix before preview. :)
<T-Bone> Mithrandir: heh ok...
<elmo_> [oh twice too on i386; it was just slower to upgrade] 
<mako> Treenaks: that just put on boingboing.net.. it's doing TONS of traffic right now :)
<Treenaks> mako: cool :)
<sm-tests> nice site
<doko> kamion: when adding the plone-site to the supported list, then running germinate, I don't see all dependencies from zope-cmfplone. I'm missing something ...
<Kamion> doko: if they're not yet in main, you need to use -c main,restricted,universe,multiverse
<doko> Kamion: ok, thanks
<wasabi> jbailey, that's cool. Did you get my wiki page?
<jbailey> wasabi: Which one?
<wasabi> JavaPackagingProgress
<jbailey> wasabi: Nope, this is a different one than you gave me yesterday.  Let me subscribe to it too.
<wasabi> Yeah i whipped it up quickly
<Nafallo> mako: is it time to register for hoarycds yet?
<Kamion> what's with all the ia64 given-back build logs at the moment?
<Kamion> pitti: it would be useful if your baz mirror on people.u.c/~pitti/arch/ had .listing files (i.e. baz make-archive -l)
<Kamion> pitti: oh, sorry, forget it, I'm just wrong
<jbailey> mdz: ping re: 5204
<mako> Nafallo: not yet.. we're going to try to coordinate with the preview release
<Nafallo> mako: oki :-)
<elmo_> Kamion/smurfix: console-keymaps-tree wants to be demoted - ok?
<Kamion> it does? looking
<Kamion> elmo_: oh, NAK - it needs to be explicitly seeded because it's in debian-installer/build/pkg-lists/, doing now
<Kamion> seeds fixed
<elmo_> thanks
<Kamion> pitti: strange that this pre-depends stuff in current langpacks isn't reflected in the langpack-o-matic archive
<tseng> hey beagle works w/o inotify now
<ogra> wow
<tseng> think it still needs a newer dbus still
<tseng> so we cant do it for hoary
<tseng> dbus 0.23.2
<trulux> language-pack-* broken
<trulux> :(
<crimsun> jdub mentioned that it might be worth looking into syncing/merging 0.23.2 from sid
<tseng> it might be. or it might break all apps built against dbus
<tseng> i might try it here, im a brave sort of guy
<Kamion> trulux: we know, you've mentioned it a couple of times and filed a bug, which I've assigned to pitti
<trulux> Kamion: heh, desperado!
<trulux> :D
<zul> tseng: still building
<tseng> hm
<tseng> good deal
* lamont works through a slow and torturous give-back process for amd64 and gnome
<elmo_> lamont: slower than your usual "GIVE BACK THE WORLD"? :p
<thully> hi - is array 6 still on track?  I just installed an array 5 CD and I'm going to rsync and re-install (to test some things in the installer, as well as some other things) when array 6 comes
<mdz> amu: ping
<lamont> elmo_: actually, I was going to do it one package at a time, then said 'hell, life is short' and gave back all 13
<mdz> thully: array 6 is scheduled for tomorrow
<amu> mdz: pong
<mdz> amu: when did kdelibs start using fam?
<lamont> elmo_: the trick to mass-givebacks is to make sure that nothing is building or in transition
<thully> oh - I thought it was today
<mdz> amu: we don't want that in main, or in kubuntu-desktop
<mdz> amu: can it be switched to gamin?
<amu> mdz: ages .... i think ganim was the fam replacement 
<amu> mdz: sure, that no problem
<Kamion> thully: releases are always scheduled for Wednesday at the moment (whether they happen then or not :-))
<thully> OK - I thought I saw somewhere that array 6 was today
<seb128> if you want a broken desktop on array 6 do that :p
<seb128> wednesday is nice :)
<thully> btw - does an ubuntu install done from an array 5 CD automatically use polypaudio?
<jon1012> hi everybody
<Kamion> thully: yes, polypaudio was in desktop in array 5, although pretty new then IIRC
<mdz> polypaudio is about as broken today as it was on array 5, iirc
<jon1012> yes, polypaudio have problems...
<Kamion> mdz: I checked the l-p-en/l-p-en-update dependency loop out on archive.ubuntu.com, and it exists
<Kamion> new in the 20050301 update, I think
<Mithrandir> Kamion: any ideas how utf8migrationtool should handle the case where the current locale is C?
<lunitik> Keybuk: says you uploaded choose-mirror, but I don't see it, any idea why?  (just update'd like 2 mins ago)
<Keybuk> buildd
* mjg59 fixes the FUCKING RADEON THING
<elmo> mjg59: btw -24 sleep works for me, thanks
<zul> hey mjg59 
<mjg59> elmo: To disk, or to RAM?
<mjg59> zul: Hi
<elmo> mjg59: to RAM
<elmo> I've never tried disk before, at all
<mvo> Mithrandir: maybe just a little dialog with a message like: "get a serious locale dude"?
<Mithrandir> heh :)
<mjg59> elmo: Excellent
<mdz> Mithrandir: cry();
<Kamion> Mithrandir: C's compatible with UTF-8, so just ignore it IMHO?
<Kamion> lunitik: /me != Keybuk.
<Mithrandir> Kamion: so with C I can just close my eyes and don't care?
<Kamion> lunitik: and choose-mirror is a udeb so it's not something you can install on your normal system anyway
<Keybuk> Kamion: heh, I just assumed it was a merge-o-matic result :p
<Kamion> Mithrandir: I think you have to :)
<Mithrandir> Kamion: why does d-i have a C.UTF8 locale then?
<Kamion> Mithrandir: I mean compatible in the "subset of" sense
<Kamion> UTF-8 strings aren't valid in C, but anything that's valid in C is also valid in UTF-8
<Mithrandir> true, but I want to migrate a person using C to a UTF8 locale
<Mithrandir> what locale should they end up with?
<Kamion> and if they've deliberately set LANG=C they probably don't want you to migrate them
<Mithrandir> they're running the utf8migrationtool -- they want to be migrated. :)
<Kamion> oh, god knows, you have to ask
<Kamion> it could easily be en_<something>.UTF-8, but the currency and date handling are different in those
<Keybuk> Kamion: you better not be trying to defend C.UTF-8 again you SICK MAN :p
<Kamion> Keybuk: I'm not :)
<mdz> amu: please don't remove kubuntu-desktop from the kubuntu desktop seed; that's how it gets into main
<ogra> lamont: does "done" mean nothing is left ? 
<lamont> ogra: means I gave everything back
<ogra> lamont: ah, ok
<lamont> 75 packages spread across 4 architectures
<amu> mdz: all right
<mdz> I've added it back
<amu> I didnt changed something? 
<Kamion> mdz: a while ago I suggested to amu that he take it out during the early heavy seed development so that he could see what was going on, since the presence of an old-and-busted kubuntu-desktop was confusing things
<Kamion> but I didn't intend for it to be left out permanently
<mdz> ah, ok
<mdz> I fixed kubuntu-meta recently
<T-Bone> mdz: you're expected on #u-meeting...
* lunitik wonders if it would be out of the question to have ClearlooksHuman as default theme rather than indubstrial?
* Nafallo accidently mixed hot laptop with cold jolt *
<amu> mdz: it disappeared? as i remember you added it yesterday?  
<Mithrandir> lunitik: I would be interested; have you made it and have a screenshot?
<Kamion> lunitik: it would appear to be under discussion for GNOME 2.12, so it would be a possibility for hoary+1
<lunitik> Mithrandir: I've made it... but not during this install... I could real fast though if it would help convince?  :)
<Mithrandir> lunitik: I guess not default, but universe at least?
<lunitik> Kamion: yes... RH devels (namely Havoc) seem to be pushing for it... and pushing out Industrial apparently
<lunitik> Mithrandir: would make life easier if it were packages, yes  :)
<lunitik> packaged*
<Kamion> lunitik: as I understand from Ross Burton's blog, it isn't final yet, though some news sites are reporting it as if it were
<tseng> jdub made a package already
<tseng> its in NEW
<tseng> and ross's blog would be correct if it says so
<lunitik> tseng: oh, cool... wasn't there when I decided to try it  :(
<tseng> http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00011.html
<lunitik> I think my
<lunitik> message can be legitimately read as "we're doing Clearlooks as the
<lunitik> default for 2.12 for sure"
<lunitik> gah... Konversation pasting sucks... sorry
<elmo> tseng: nothing's in NEW - what package do you think is?
<tseng> you dont need to paste anything, people intersted in it can read the posting
<tseng> elmo: jdub said he recently uploaded gtk2-engines-clearlooks or so
<lunitik> tseng: how long you think it would take to actually show up?
<lunitik> tseng: cuz I just apt-cache search'd 'clearlooks' and get nothing  :(
<tseng> well if its not showing up in NEW, the its not going anywhere fast
<elmo> it's not in NEW, can't even see it in REJECT
* mako brings together mepis, debian, and ubuntu into a single news item: http://dotmepis.org/modules/news/
<trulux> pitti: ping
<pitti> trulux: I'm here, but in a meeting
<amu> mako: any news cases mepis offer also source to their gpl programs?
<trulux> pitti: oh, ok
<trulux> pitti: language-pack-es still not working as the other ones :(
<pitti> trulux: odd, it worked for me, and Keybuk suggested the Pre-dependency to work around a dpkg bug
<pitti> trulux: I'll look into it ASAP
<Keybuk> what's not working?
<Kamion> Keybuk: l-p-en depends: l-p-en-update, l-p-en-update pre-depends: l-p-en
<Kamion> Keybuk: BAD
<Keybuk> meh; yeah, that won't work
<Kamion> so l-p-en must be unpacked and configured (or previously configured) before l-p-en-update can be unpacked, but l-p-en-update must be configured before l-p-en can be configured
<Keybuk> l-p-en shouldn't depend l-p-en-update
<Kamion> if this is the dpkg Replaces bug, I think it should be ignored :P
<Keybuk> at most, it's a recommends
<trulux> pitti: ok, many thanks
<Kamion> Keybuk: (a) that requires installer changes, (b) that makes it harder for users surely?
<Keybuk> otherwise you have to ensure installer installs l-p-en first and l-p-en-update afterwards
<pitti> Keybuk: before they just depended on each other, but that breaks due to the dpkg Replaces: bug
<pitti> Keybuk: but normally folks should just install l-p-foo and be done with it
<Kamion> what actually broke?
<mako> amu: we had a conversation with mepis's publisher and author at linuxworld about this
<pitti> Kamion: #184635
<pitti> Kamion: this is exactly the use case for a base package and l-p-update packages which partially replace the base pkg
<amu> mako: means finally we get the source? At least a easy thing, they distribute under GPL, and it says if someone request the source, you've to give it to him.   
<pitti> Kamion: you cannot install update first, then the base package
<pitti> Kamion: that's why Keybuk suggested Pre-Depends: to force installation order
<Kamion> I'm inclined to say "so?" :)
<Kamion> but ok; I still think we should just fix dpkg rather than endlessly working around this bug
<Keybuk> yes, we should
<Mithrandir> Kamion: sorry, I was away for a long phone call -- you think just popping up a selection of en_* locales is sensible if the current locale is C?
<pitti> Keybuk: I thouhgt you said that this won't happen for Hoary/Sarge?
<Keybuk> pitti: it won't.
<Kamion> Mithrandir: it seems sort of a reasonable approach, I think
<Keybuk> I do not have the time to fix both #164595 and #170825 before then
<pitti> Kamion: "so" -> it can break installations and upgrades if you don't manually force installation order
<Mithrandir> Kamion: we could just do C.UTF8 and everybody should be happy though.. ;)
<pitti> *cough*
* Mithrandir hides
<Kamion> pitti: yeah, I know
<pitti> "Hey elmo, I have to build all base packages again, kthxbye"
<pitti> He will _love_ me for that...
<pitti> any idea for a working solution?
<Kamion> Keybuk: wow, #170825 is actually a really old bug isn't it? looks like it's related to the "dpkg doesn't check Depends: on downgrade" thing that's on iwj's ancient todo list for dpkg
<Kamion> pitti: l-p-en-update depends l-p-en, l-p-en recommends l-p-en-update, and we make the installer install both?
<Keybuk> Kamion: dpkg doesn't check Depends both on downgrade, and on installation of a different package
<Keybuk> foo; Conflicts: bar
<Keybuk> install foo
<Keybuk> fine
<Keybuk> now install bar
<Keybuk> dpkg will let you, because you're not installing foo at the same time
<Keybuk> etc.
<Kamion> pitti: I realise it makes it less easy to install just one package and get both, but we were planning on having an application to install language packs eventually anyway, and it looks like this scheme is doomed
<pitti> Kamion: I think we can work around this in the installer pretty easy, we can even force the order there
<pitti> Kamion: I'm more concerned about user installation
<pitti> Kamion: Hoary+1 will have a separate gui for this, though
<Kamion> pitti: sure, I'm happy to make the installer install l-p-* and l-p-*-update in separate dpkg runs
<pitti> hmm, a Recommends: then?
<pitti> but will this really work with the pre-dependency if you install both packages?
<pitti> hmm, it sould
<pitti> should, even
<Keybuk> recommends is a depends that doesn't affect order
<Keybuk> (basically)
<Kamion> does it have to be a pre-dep?
<Kamion> oh, I suppose you need a pre-dep in order to work around broken replaces technically
<pitti> Kamion: right, that was the reason
<pitti> mvo: if l-p-foo recommends l-p-foo-update, will synaptic default to install it, too?
<mvo> pitti: depends. it can do it if it is configured to do so (not by default right now, see #2171)
<pitti> hmm, ok
<pitti> I guess there is no perfect solution then
<pitti> Keybuk, Kamion: okay, I go with the Recommends: approach if there is consensus about it
<Kamion> I can't say I really like it, but I like all the other options less
<Kamion> dunno about Keybuk
<pitti> Kamion: same for me :-)
<Keybuk> the other option would be to name the packages differently
<Keybuk> so l-p-en-update becomes l-p-en
<Keybuk> and l-p-en becomes l-p-en-base
<Keybuk> or something, so users install the right one :p
<pitti> how should that help?
<pitti> ah
<Keybuk> social rather than physical engineering
<Kamion> that seems reasonable
<Kamion> although getting rid of l-p-*-update that people have already installed would be interesting
<Kamion> wonder what a dist-upgrade would pick out of A conflicts,provides,replaces B and B pre-depends,replaces A  :)
<pitti> So l-p-en would Replace and Provide l-p-en-update
<pitti> but what about the l-p-en-base?
<Kamion> I think it would have to Conflict too
<pitti> it can't provide and replace l-p-en
<pitti> what a mess...
<Kamion> doesn't need to
<pitti> versioned conflicts, probably
<Kamion> l-p-en C,R,P l-p-en-update, l-p-en Pre-Depends,Replaces l-p-en-base, l-p-en-base Recommends l-p-en and Replaces old versions of l-p-en
<Kamion> ?
<pitti> Kamion: I'm not _really_ fond of renaming all the packages, but if it is really required...
<Kamion> needs a fair bit of testing with a private archive, I suspect, to make sure it actually does the right thing
<Kamion> pitti: this sounds like it might take more than a day to get right. Could I have a temporary solution so that I can release Array 6 tomorrow, maybe just reverting the Depends->Pre-Depends change?
<Kamion> unless you're confident it can happen by tomorrow
<pitti> Kamion: just changing s/Depends/Recommends/ is relatively easy
<pitti> Kamion: I just have to reupload all base packages
<pitti> Kamion: doing the rename and dependency changes can be done tomorrow as well
<pitti> Kamion: it's not much more work compared to just s/Depends/Recommends/
<pitti> Kamion: when is array 6 due? I. e. what exactly would be my deadline?
<Kamion> sometime tomorrow, no specific time
<Kamion> ok, whatever you think's best
<Kamion> if you could be contactable for a few hours after you make the change so that we can pick up on any problems, though, that would be good
<pitti> sure
<Kamion> thanks
<pitti> Kamion: let's say I do this as very first thing tomorrow (too tired today)
<Kamion> pitti: ok, sounds good
<pitti> Kamion: then it can be ready, tested and uploaded by 1000 UTC
<Kamion> pitti: where are the langpacks generated? I assume it's some machine in the DC
<pitti> Kamion: I put some example packages onto p.u.c for testing before
<pitti> Kamion: maybe you can test the packages as well
<pitti> Kamion: yes, that is rookery:/srv/langpack...
<Kamion> yep, can do
<Kamion> ah, of course
<pitti> Kamion: I think your dependency scheme looks right
<Kamion> pitti: it was kind of off the top of my head, and I'm not sure I know all the constraints on language packs, so ...
<pitti> Kamion: so far the only integration is with the installer
<dredg> question: would it be worth having a page on the wiki with locations and names of people prepared to sign keys (on seeing valid ID of course)?
<Kamion> pitti: well, I was thinking more of requirements; the various meetings mentioning it made my head spin
<ogra> dredg: sure
<dholbach> we should have jdub's world map for ubuntu as well
<ogra> dredg: jdub madesomething and i think mako could have some data for it
<pitti> Kamion: well, I won't change the structure and contents of the packaging, the mere name should just be obvious
<Kamion> pitti: -update is just a bandwidth-saver, right?
<pitti> Kamion: yes, this is the one we regenereate daily
<Kamion> ok
<pitti> Kamion: relative to the most recent base
<Kamion> oh, I don't expect changes here for hoary, but any reason why -update doesn't just install files in a different location?
<pitti> Kamion: because then we needed a third gettext path and a complicated three-way comparison in glibc
<Kamion> fair enough
<pitti> Kamion: and to save space
<pitti> Kamion: otherwise you would have most of the files twice
<dredg> ogra: ok, i might poke jdub with it next time he's about
<ogra> dredg: yup, do that, and ask mako for keyholder data, he might have a list
<mako> dredg: well.. we don't require signatures from people who are ubuntu developers (yet)
<mako> ogra, dredg: we are mostly concerned with anybody in the strongly connected set
<mako> the best site i know of for doing that sort of coordination is biglumber
* dredg nods
<dredg> mako: what i was getting at is hypothetically, i get my key into a strongly connected set associated with ubuntu by ubuntu people, and prospective members/maintainers could for example, contact me to have their key signed.
<dredg> mako: this is ireland. not a big place :)
<pitti> good night everybody
<ogra> night pitti, and thanks forthe work
<ogra> hrm
<sivang> ogra: yep, he's quick :)
<ogra> heh
<Kamion> dredg: I'll probably be over there in August, but I think keysigning on one's honeymoon is deprecated ;)
* dredg grins
<dredg> Kamion: no, it's the new cool thing.. ors.. 
<dredg> plus i'm more likely to be in the UK before then :)
<mdz> lamont: ping?
<lamont> ack
<lamont> Kamion: deprecated, possibly.  But should still be doable, yes?
<Kamion> lamont: hypothetically, but it ain't gonna happen :)
<lamont> heh
<lamont> hrm.. mdz ping and run?
<Kamion> hm, is auckland not syncing at the moment?
* Kamion wonders where his choose-mirror upload of nearly three hours ago has got to
<lamont> Kamion: 1.06ubuntu5?
<mdz> lamont: name of the powerpc porting box?
<lamont> davis
<Kamion> lamont: yes
<lamont> it's installed according to my information
<lamont> (although the file dumps are from 6 min ago)
<lamont> haven't looked further back for when it really transitioned to installed
<mjg59> Kamion: Someone's just posted hotplug patches for macio
<Kamion> mjg59: mdz sent me some of those a while back, I never had time to review them :(
<Kamion> having those would rock, though
<Kamion> lamont: if I uploaded debian-installer now, would it be built against choose-mirror 1.06ubuntu5?
<lamont> yes
<mdz> mjg59: Jeff Mahoney?
<seb128> lamont: can you kick bug-buddy build please ?
<lamont> seb128: and it'll now magically find xmllint and xsltproc?
<lamont> kicked
<mdz> Kamion: do you have an array 6 todo list?
<seb128> lamont: I've fixed gnome-doc-utils so it should
<mdz> Kamion: I' m ready to do a full round of live+install testing
<Amaranth> beagle doesn't need inotify anymore?
<zul> Amaranth, apparently not
<lamont> doko: aspell-sl is ftbfs, as reported in debian
<mako> dredg: big enough
<Kamion> mdz: I've been hoping to get a new kernel first, primarily, and there's these langpack changes
<mdz> who are we waiting on for the kernel?
<Kamion> lamont: do you know what's happening there?
<mdz> if there isn't any particular reason to believe that we'll be able to use inotify for Hoary, there isn't any point in that bit
<lamont> Kamion: t-bone is having screaming fits at baz, that much is known 
<Kamion> I'd like to have nfs-modules-*.udeb, it's fairly important for kickstart
<mdz> is there any way that I can set up a powerpc system to boot from CD by default?
<jon1012> good night all ^^
<sivang> night jon1012 
<mdz> lamont: what do t-bone and baz have to do with the hoary kernel update?
<Kamion> mdz: nvsetenv boot-device <something> ought to do it
<T-Bone> mdz: maybe the fact that i'll be uploading next release
<Kamion> mdz: possibly nvsetenv boot-device cd:
<zul> mdz: about inotify tseng and i are testing something that we found
<rubenv> mjg59: fabbione: what's the basic difference between booting in recovery and normal?
<lamont> mdz: t-bone was doing the prepwork for this upload
<rubenv> mjg59: fabbione: basically it boots with the recovery kernel and runs well, with the normal kernel, it just flunks out after a while
<lamont> I have a diff of his tree, worst case I'll wind up reimporting it into baz here.
<rubenv> for no specific reason
<lunitik> rubenv: I think these are more topics for #ubuntu
<Kamion> mdz: however the big change in the kernel is enabling ATAPI support in libata, which is a sabdfl item
<Kamion> well I say "big", I think it's an #ifdef change :)
<rubenv> lunitik: i know what's the difference, but this is a crashing kernel
<rubenv> not a user issue
<mdz> an #ifdef change which effects detecting the disks in all SATA systems, yes :-)
<mdz> lamont: the kernel packages are in baz?
<lunitik> rubenv: umm... its more a usage issue than a devel issue
<Kamion> yeah ... I don't think I'm going to get away with not at least trying it, though
<Kamion> rubenv: the "normal kernel" and the "recovery kernel" are the same kernel
<rubenv> lunitik: a kernel that crashes after about 2 minutes for no specific reason is well, crap
<rubenv> Kamion: yeah, i figured so too, reading from the grub conf
<zul> Kamion: its been tested though
<rubenv> hmmm
<Kamion> recovery mode is just single-user, it's doing rather less work
<Kamion> zul: *nod*
<zul> and it was glemmed from mandrake
<rubenv> yeah, but after booting on from single, it shouldn't start anything that can cause the kernel to hang?
<Kamion> zul: don't get me wrong, I think it's a good idea, we'll just have to be quick about testing it and if necessary reverting
<jbailey> rubenv: In general you can't promise that.  You need hotplug to get you usb keyboards and such.
<rubenv> jbailey: it's a laptop :(
<zul> Kamion:yep
<rubenv> it's strange shit man
<lamont> mdz: we imported the debian portion into baz
<lamont> er, debian/ directory
<lamont> seb128: same failure
<seb128> graaa
<lamont> seb128: which version of which package did you assert fixed it, and I'll verify that we actaully got that version
<seb128> lamont: don't bother there is a build-depends issue too, I'll fix it right now :)
<seb128> Uploading via ftp evolution_2.1.6.orig.tar.gz: Error '(32, 'Broken pipe')' during ftp transfer of evolution_2.1.6.orig.tar.gz
<lamont> heh
<seb128> GRRRRRRRAAAAA
<seb128> hate this bug
<lamont> seb128: you need smaller packages. :-)
<seb128> that's an option
<seb128> somebody willing to maintain gtk and evolution here ? :p
<zul> uh....no..
<ogra> seb128: what do you pay ?
<seb128> that's for free
<ogra> lol
<seb128> you will have a lot of fun with them
<seb128> that's better than money :)
* T-Bone learns that fun is a new synonym for 'pain' ;)
<ogra> yup, i already have....every day ;)
<zul> T-Bone: you masochist you
<T-Bone> zul: i must be. Baz's my bitch :P
<zul> heh
<ogra> T-Bone: you should talk to fabbione about that ;)
<zul> when is he suppose to be back anyway?
<ogra> zul: i thought you should know that
<ogra> s/should/would
<zul> yeah but i forget things easily :)
<lamont> Kamion: you around?
* lamont lets workrave win for a minute or 2
<jdub> elmo: ping
<Kamion> mdz: re testing, I'm actually more or less in sync with live CDs now
<seb128> jdub: new gamin :p
<zul> Arrogance: are you in ontario?
* lamont bbiab
<Arrogance> zul, yes
<Arrogance> Toronto
<zul> i c
<jdub> seb128: yeah, saw
<zul> lamont: check out #ubuntu-kernel for a sec
<Kamion> night all
<dholbach> bye Kamion 
* T-Bone goes get some caffeine. Likely to be in for a few more hours :(
<dholbach> sleep tight :-)
<ogra> Kamion: night
<zul> night kamion
<lunitik> modconf in warty, dropped in hoary?
<sivang> lunitik: was dropped upstream IIRC
<sivang> lunitik: ah oops,
<sivang> lunitik: I thought you were talking about alsaconf
<lunitik> sivang: heh... nah... someone is asking about it... its listed in the archive though, and I don't see it, so I'm guessing it was dropped for hoary
<lunitik> sivang: personally, I don't see why someone would use it... but whatever
<gma> I'm using glade on warty to create a UI with a GtkFileChooserDialog in it.
<gma> but libglade doesn't know about the widget
<sivang> lunitik: probably 
<gma> is there a known version number mismatch on warty?
<sivang> lunitik: I wonder if you can install it from universe he he
<lunitik> sivang: nope... I have that enabled
<sivang> lunitik: I see, then probably not.
<sivang> lunitik: I actually used it when I dind't know the exact name of the module i was requiring once
* lunitik uses google in such situations
<sivang> lunitik: right, google know
<sivang> (s)
<lunitik> Why oh why isn't Evince in main, and replacing GGV and XPDF yet?  *cries*
<lunitik> Plus... why isn't eog going bye bye due to gthumb?
<lunitik> Only complaints I have with Ubuntu right now  *still_crying*
<jdub> they do different things
<Mithrandir> gthumb also eats _loads_ of ram.
<lunitik> jdub: what does eog do that gthumb can't?
<jdub> lunitik: it's a simple, no-nonsense image viewer.
<lunitik> jdub: gthumb is fast here... and is pretty basic while still doing what I need... I can't remember the last time I actually used eog on purpose
<mxpxpod> also, what does eog do that nautilus can't do?
<lunitik> I don't think I ever have actually
<Mithrandir> gthumb uses 250MB of RAM for rotating a picture her.
<lunitik> mxpxpod: actually... I think nautilus uses eog... should be using gthumb though  ^_^
<jdub> mxpxpod: it's a simple no-nonsense image viewer.
<lunitik> jdub: gdi... but it sucks  :(
<lunitik> plus... thats trivial compared to other complaint
<lunitik> So long as eog doesn't try to do anything, I'm happy... but XPDF is annoying, and ugly.
<sivang> jdub: we should have a FAQ entry for the evince over xpdf issue :)
<HrdwrBoB> if eog had a 'next' button'
<HrdwrBoB> which progressed to the next picture in the directory
<HrdwrBoB> .. it would be fine
<lunitik> sivang: when evince is ready, I believe it will replace ggv and xpdf... but ever since wart preview, I have complained about xpdf being around, its even in kubuntu-base... I dislike it a great deal
<lunitik> kubuntu-desktop
<Mithrandir> HrdwrBoB: just click the first picture in the directory index and use the left and right buttons
<sivang> lunitik: it does lack some nice gui frontending, but jdub noted to me sometime ago about some stuff evince is missing at the moment, the last time I asked him about it :)
<lunitik> I even keep going over to Fedora simply because I don't want to ever see/use xpdf
<jdub> ...
<lunitik> The choice alone is just bad
<HrdwrBoB> Mithrandir: I can see the preview in nautilus
<jdub> it's difficult to take your input seriously with that kind of commentary
<sivang> lunitik: that's hardly an applicable argument, I must admit.
<Mithrandir> though, to be honest, eog uses loads of memory too.
#ubuntu-devel 2005-03-13
<lunitik> jdub: voicing how strongly I dislike it... I would need to go back a few levels of meta-packages to get rid of it and eog... which makes managing packages that much harder  :(
<jdub> lunitik: you don't need to make your point over and over, and with unnecessary hyperbole.
<lunitik> (which goes back to a previous issue, having some flexability in the ubuntu-desktop depends... 
<Mithrandir> lunitik: you could just divert it and make the xpdf binary a symlink to gpdf; ditto for eog.
<Mithrandir> it's not like it's hard.
<lunitik> Mithrandir: if I did it myself, I garentee I'd forget for one upgrade, and have to fix it...
<Mithrandir> lunitik: which is why you divert it.  dpkg remembers for you
<Mithrandir> man dpkg-divert
<lunitik> Mithrandir: hmm, thanks
<lunitik> Mithrandir: ahh... I don't understand... --package seems to be what I want... but how would I say "install gpdf and ignore xpdf* and eog"
<Mithrandir> lunitik: cd /usr/bin/ ; dpkg-divert --local /usr/bin/gpdf && ln -s gpdf xpdf ; apt-get install gpdf ought to work.
<lifeless> signed aot repositories - what files do I need to sign ?
<mvo> lifeless: the Release file will do
<lifeless> mvo: clear signed ?
<mvo> lifeless: detached and armored as Release.gpg
<jdub> argh
<jdub> the gaim guys still haven't fixed the 'disconnected from notification area kills me' bug
<Mithrandir> sure it's not fixed in 1.1.4 either?
<jdub> running 1.1.4 now
<Mithrandir> ok
<jdub> oh, hold on
<jdub> :-)
<jdub> i must've been running the earlier version before ;)
<jdub> yaaaay!
<Mithrandir> is 1.1.4 in hoary now?
<jdub> yeash
<dredg> yes. gaim-encryption was rebuilt to play nice with it a couple of days ago
<sivang> somehting strange
<sivang> just upgraded
<sivang> desktop as a whole suddenly got a lot less responsive
<sivang> hrm
* mvo goes to bed now
<sivang> even switching windows in irssi is _slow_
<sivang> (and I am using irssi locally, not through screen)
* sivang thinks of doing a reboot
<mvo> sivang: have had very slow redrawing as well some days ago. killing metacity helped me
<ogra> mvo: night
<mvo> night ogra 
<dholbach> night everyone, i'm off as well
<ogra> me too
<ogra> night
<dholbach> *wave*
<zul> everybody is dropping like flies
<sivang> hmm, still the same
<sivang> :-/
<marcin_ant> hi - could someone help me with ppp connection?
<marcin_ant> my problem is related with this bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23127786
<lunitik> Mithrandir: ahh... sorry, had to handle something... but its not letting me remove xpdf without removing ubuntu-desktop still... any idea why?
<marcin_ant> and there is a kind of solution but I don't know how to use this solution... 
<sivang> seb128: do you know anything about redraw slowness problem?
<seb128> ?
<seb128> context ?
<seb128> what app ?
<sivang> seb128: all of the desktop
<seb128> nop
<T-Bone> sivang: that's called 'low mem'
<T-Bone> ;)
<sivang> T-Bone: ha! I'm hurt :) I have .5Gig here :)
<T-Bone> aka "swapping like hell"
<T-Bone> heh
<T-Bone> not enough :)
<sivang> T-Bone: I know you told me already, but I cannot afford more then that at the moment
<sivang> T-Bone: my nvidia card fan may be failing or either my swap partitoin has gone bonkers as it did on the lappie
<T-Bone> (actually it's a shame that 512M isn't enough, I have machines running other OSes with 24M of RAM :P)
<lamont> Kamion: ??
<T-Bone> elmo: around?
<T-Bone> lamont: seen #u-kernel?
<jdub> seb128: go go go! :)
<seb128> ;)
<sivang> seb128: that's so odd, all of my desktop is like through a vnc console over a modem line since last upgrade. what can I do it track this down? :-)
<T-Bone> ok, -25 uploaded, food for the buildds
<sivang> seb128: (with regarad to redraw slow performance, that is)
<seb128> top
<seb128> what's the system load ?
<sivang> load average: 0.21, 0.35, 0.24
<seb128> not that high
<sivang> yeah, I don't get it
<seb128> do you have something eating CPU ?
<zul> sivang: you are running 2.6.10-3 right?
<sivang> zul: now I am , yes :)
<sivang> zul: so it's not a kernel problem
<zul> still the same problem?
<sivang> zul: yep
<zul> ok
<seb128> nothing in ~/.xsession-errors ?
<sivang> seb128: looking
<sivang> seb128: protocol-esound.c: read() failed: EOF
<seb128> probably not slowing your system
<sivang> seb128: probably not
* lamont grumbles at the number of ftbfs logs in main
<T-Bone> lamont: let's add the hppa ones to that list ;^)
* T-Bone runs away screaming mad after all that kernel work :)
<lamont> T-Bone: actually, I already branched most of those. :-)
<T-Bone> hehe
<lamont> T-Bone: you gonna tell mdz that -25 is uploaded?
<T-Bone> i told it to the world a few line above but i guess i can do:
<T-Bone> mdz: -25 is uploaded (i'm not receiving any confirmation mail, fwiw) :)
<T-Bone> lamont: is that fine? :^)
<lamont> anyway, off to hear the cello played by my 12 year-old.
<lamont> T-Bone: works here
<T-Bone> lamont: off to bed, on my side :)
<lamont> elmo is like asleep, yes?
<sivang> T-Bone: you mean the slowness problem?
<T-Bone> see ya tomorrow for more bugging ;)
<T-Bone> gnight all
<sivang> seb128: one of the "cpu(s)" (it's an -smp system) goes up to 55% load when switching between windows, normal?
<sivang> seb128: s/-smp/HT/
<seb128> no
<sivang> seb128: hyper threading
<seb128> do you use the composite or something ?
<sivang> seb128: composite?
<seb128> xorg transparency stuff
* lamont back in about 2-3 hours
<sivang> seb128: no AFAIK. how can I check if xorg transperancy is on by mistake maybe?
<jbailey> Hmm.  This is probably too ugly...  tail -n $(($(wc -l /proc/swaps | awk ' { print $1 } ') - 1)) /proc/swaps | sort -rk3 | head -n 1 | awk ' { print $1 } '
<seb128> sivang: search for composite in the config file ? but if you have not changed it there is no reason
<sivang> seb128: then I havn't :-/
<jbailey> Oh - I don't have those options in busybox sort, do I.
* jbailey grumbles.
<Loevborg> jbailey, and you don't have perl?
<schweeb> jbailey: you're doing this for the installer CD?
<jbailey> It's for initrd-tools at installation time to set the resume partition for suspend to disk.
<schweeb> yea, even perl would be prettier
<jbailey> I need to pull out the partition that's the largest.
<jbailey> I don't remember if perl is available at that point or not.
<jbailey> Nope. No perl udeb.
* jbailey makes sure that d-i bb actually has awk available
<schweeb> hrm
<schweeb> are dist-upgrades from warty going to be supported?
<jdub> of course
<schweeb> it'd be nice to have that resume partition stuff set on dist-upgrade too
<schweeb> rather than just in the udeb on the cd
<wasabi> Okay, so I'm looking for somebody from Ubuntu to sign my gpg key, in the Texas area. ;)
<jbailey> schweeb: I can't risk changing a config file that might have been unset intentionally.  The resume partition magic is in the new version, though.  You just have to set it by hand in one config file and then update to a newer kernel.
<wasabi> There a wiki page for key signing meetings or similar?
<schweeb> jbailey: ah
<schweeb> gotta mess around w/ suspend on the lappy a bit... had it working a while back in Sid, hasn't worked since
<jbailey> schweeb: I've had good luck with recent hoary kernels.
<Loevborg> on my box, it doesn't seem to work. where do i look to see what's wrong?
<schweeb> jbailey: well, tried it yesterday, but the screen didn't come back on... my guess is it's either DPMS or the Video Post stuff
<jbailey> schweeb: See Zack Weinberg's recent message on ubuntu-devel@.  Matt made some suggestions in there that might be worth trying.
<schweeb> jbailey: thx
<schweeb> hrm
<schweeb> wonder if gmane has ubuntu-devel archives
* schweeb checks
<schweeb> oh joy!
<tseng> hey dudes
<jbailey> No, awk, no head, no sort.
<jbailey> Well, crippled sort.
* jbailey contemplated writing qsort in pure shell.
<schweeb> jbailey: Zack's Array 5 post?
<jbailey> schweeb: Yeah.
<jbailey> mjg59: There?
<mjg59> jbailey: Yo
<mdz> T-None: if you aren't receiving confirmation email, it'll be because the email address you're using isn't on the whitelist
<jbailey> mjg59: Do you know off hand if initrd-tools is done installed from a chroot on the new drive, or if it's still in busybox with basically no tools available?
<mjg59> jbailey: No idea, I'm afraid
<jbailey> mjg59: 'kay.  If it's from busybox, do you think it's safe to just pick the first partition?
<mjg59> I'd expect it to be in the chroot, though
<sivang> when is preview freeze in effect?
<jbailey> mjg59: I had planned to pick the biggest one, but I might not have enough text processing tools to sort that out.
<mjg59> It's always safe to choose the first partition, it just won't necessarily work :)
<jbailey> mjg59: What happens if the swap partition is inadequate for some reason?  (Full, too small, not initialised, etc..)
<sivang> hey tseng 
<mjg59> jbailey: The system will bounce
<jbailey> mjg59: Bounce like reboot, or bounce like refuse to suspend?
<mjg59> Uh. Rather, the suspend call will fail and the machine will run the resume script.
<helix> ooh, bouncing systems
<mjg59> It won't reboot
<jbailey> G'd evening Erinn ;)
<helix> hello! :)
<jbailey> mjg59: 'kay, so if I get it wrong then I'm not risking crippling the system.  I can cope with that.
<sivang> jbailey: from what I saw mjg59's pm stuff is really cool and uncrippeling
<tritium> I agree :)
<sivang> seb128: it's definitely only to redraw stuff that got b0rked, I can even type into a terminal while it's get redrawn
<mjg59> FEEL THE LOVE
<jbailey> mjg59: And one last fuzzy-love question.  If someone points it at something that's not a swap partition, it'll puke right? =)
<sivang> jbailey: hmm, interesting question
<mdz> jbailey: initrd-tools is installed in a chroot
<jbailey> mdz: Nice, thanks!
* jbailey does a happy dance.
<mdz> jbailey: where do we stand on #1080?
<mjg59> jbailey: Yeah, it checks for a swap sig first
<mjg59> Uh, I think. Let me just make sure of that...
<jbailey> mdz: The bugzilla mods aren't finished.  I'm going to hack on them more later today.  I have bug-buddy code to talk to xml-rpc.  reportbug isn't trivial to modify since it has all the debbugs bits hardcoded (severities, etc.) and I'd recommend replacing it with bugzuki which is mostly ready, just needs to be unhardwired from RH's bugzilla.
<jbailey> mdz: I wanted to get the SATA bug and the initrd pieces in before tomorrow, though.
<jbailey> mdz: bugzuki is more more like bts than reportbug, though.
<tritium> It even works for me, and my swap is 498 MB, while my ram iw 512 MB.
<mdz> jbailey: I'm much less concerned about reportbug than I am about bug-buddy, to be honest
<sivang> mdz : reportbug is text mode the last time I checked, or is it being used as a backend for some more intelligent bug reporting tools?
<jbailey> mdz: Yes, textmode.  I'd imagine that most devs are probably just as happy using bugzilla for now.
<jbailey> err.
<jbailey> sivang: ^^
<sivang> jbailey: k, cool.
<mjg59> jbailey: Y'know, the worrying thing is that I can't actually find anything that checks whether it's swapspace until after it's written all over the partition...
<jbailey> mjg59: But it does it after?  That's comforting.
<tritium> mjg59, is there any checking to see if swap size < memory ?
<jbailey> mjg59:  We can hack out some of the xscreensaver code to post a big "Game Over" message in the middle of the screen. =)
<mjg59> tritium: Yeah
<tritium> Okay, thanks.
<mdz> jbailey: reportbug doesn't even work unless the (Debian-savvy) admin configures an MTA anyway, and if they do, the reports at least go someplace useful
<mdz> whereas the bug-buddy reports basically get queued indefinitely
<jbailey> mdz: Hmm, so this code should be ported over to malone eventually anyway.
<schweeb> bugger, all I get is blank screen on reboot with suspend
<sivang> gas anyone changed dch to use mc's text editor instead of vi ?
<sivang> s/gas/has/
<sivang> that's rather rude :)
<sivang> that's probably specific to the package though..
<crimsun> shouldn't be... just export $EDITOR
<crimsun> well, set and export it
<schweeb> it probably just uses the editor from your alternatives
<schweeb> update-alternative --config editor
<sivang> schweeb: right. thanks.
<schweeb> er update-alternatives
<sivang> schweeb: thanks , ny dch is sane again
<schweeb> yw
<sivang> schweeb: seems the default now is mceditor
<tseng> vim++
* tseng hides.
<sivang> tseng: for sure :)
<mjg59> Hmm. So, I have code that makes Thinkpads suspend properly and not draw lots of power.
<mjg59> It's likely to do bad things to non-Thinkpads.
<mjg59> Hoary? Or leave in the wiki and defer?
* schweeb tries to reverse engineer the hibernate process
<jbailey> mdz: re: 6898, yes, I think dropping sablevm down to universe makes sense 
<mdz> jbailey: db4.2 seems to build-depend on sablevm and libgcj4-dev
<Clint> you can switch it to kaffe
<mdz> I guess we should stick with it for hoary, and fix this stuff up for +1
* jbailey checks.
<Clint> you could also disable the java tests
<jbailey> Oh, build-dep.  That's why it didn't show up with apt-cache rdepends.
<mdz> daniels: here?
<mjg59> daniels: http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/106746.html - CRACK
<daniels> mdz: pong
<daniels> mjg59: oh man
<mjg59> daniels: It's still in the kernel
<daniels> mjg59: oh man
<mjg59> /usr/src/linux/arch/ppc/boot/lib/vreset.c
<mjg59> daniels: On the bright side, it means that we know how to reinit some cards from scratch...
<mjg59> Hmm. I'm sure Jon Smirl doesn't want to be poking 0x46e8 in the way he is. Its behaviour seems to vary from card to card.
<Riddell> daniels: dbus packages have a duplicate qt header file in both dbus-1-dev and dbus-qt-1-dev, can I commit a fix?
<Riddell> debdiff:  http://muse.19inch.net/~jr/tmp/dbus-deb.diff
<daniels> Riddell: sure -- i thought amu had already fixed that one up
<Riddell> daniels: he mentioned it but doesn't seem to have uploaded the fix
* Riddell uploads
<jdub> daniels: 0.23.1?
<Riddell> hmm, my upload of dbus was rejected, is that because my key doesn't work for packages in main?
<mdz> Riddell: yes
<daniels> jdub: not sure if it has API changes
<Riddell> mdz: it's supposed to, at least the technical board approved me for it, is it elmo I moan to?
<mdz> Riddell: well, what did it say in the reject message?
<mdz> that your key is no good, or something else?
<Riddell> mdz: "not in the Maintainer keyring"
<mdz> Riddell: yeah, that'd mean that the keyring hasn't been updated
<mdz> (elmo)
<Riddell> ok
<schweeb> urgh, no suspend for schweeb
<sivang> night all!
<daniels> guys, could you all please fetch http://people.ubuntu.com/~daniels/detect-keyboard.sh, and run it?  (needs to be run as root due to debconfage).  please send me a /msg if you use it and let me know whether it's right or wrong.
<daniels> (this is going to be the xkb detection stuff for array 6, so as wide testing as it can get is appreciated.)
<calc> is it ok to run it under x?
<daniels> yeah, it won't touch any running configuration
<daniels> the only debconf stuff it needs to do is find out what the d-i keymap is
<Burgundavia> hmm
<Burgundavia> seems to work correctly here
<lunitik> Burgundavia: way to follow instructions  ;)
<schweeb> daniels: ah, that perl error must have been something from debconf
<Burgundavia> yes, I just read the last para
<mdz> daniels: (wrongly) gives me us here, but I don't think I installed this system with the installer
<daniels> mdz: ah, ok
<mdz> daniels: does the right thing on my laptop, which was installed by the installer
<mdz> I'll try on the test boxen as well
<Burgundavia> daniels: if it matters, my warty--> upgrade box works correctly too
<daniels> cool
<jdub> # ./detect-keyboard.sh
<jdub> failed to infer keyboard layout from layout/lang '--'
<jdub> layout is us
<jdub> rules are xorg
<jdub> model is pc104
<jdub> options are
<jdub> 
<mdz> daniels: yes, yes and yes
<mdz> (i386, powerpc, amd64)
<daniels> smurfix: ping
<mdz> daniels: you might be able to get a wider variety of layouts in #ubuntu
<daniels> mdz: phat
<daniels> jdub: don't use sudo su -, you bongmeister
<crimsun> daniels: works correctly here.
<jdub> :-)
<crimsun> (sid->hoary)
<calc> btw why isn't LANG getting set when you sudo su -?
<mdz> jdub: did you not install using d-i?
<mdz> oh, nm
<jdub> $ sudo ./detect-keyboard.sh
<jdub> layout is us
<jdub> rules are xorg
<jdub> model is pc104
<jdub> options are
<jdub> pants
<jdub> 
<daniels> calc: su - clears the environment
<calc> yea it resets it to root's env
<calc> or something similar
<calc> hmm so sudo su - isn't causing /etc/pam.d/login to be used otherwise pam_env would cause /etc/environment to be loaded
<mdz> sudo su - is silly
<mdz> sudo -i
<calc> does the same thing no LANG
<calc> which appears to be due to pam_env not being run?
<mdz> yeah, looks that way
<mdz> sudo login -f root :-)
<calc> heh that works
<calc> so why doesn't the other methods of getting a login shell actually cause pam.d/login to run, interesting issue
<mdz> I don't think they start a pam session
<lunitik> calc: 'sudo su -' results in same as 'su -' ... sudo -i still specifies SUDO_USER and SUDO_UID... 
<calc> lunitik: yea
<mdz> I wonder why sudo -i doesn't just use login
<mdz> that's what it's for
<lunitik> Only diff's I see... heh... I just went through comparing...
<lunitik> mdz: man sudo -i says it parses shell as specified in /etc/passwd, then /etc/sudoers ... 'login' doesn't ever look at /etc/sudoers... might be related  ;)
<mdz> lunitik: for the "sudo -i" case, the shell will always be the same
<mdz> not that it's any of sudo's business :-)
<lunitik>  -i  The -i (simulate initial login) option runs the shell specified in the passwd(5) entry of the user that the command is being run as.
<lunitik> So yes  :P
* lunitik just read it wrong... cuz he's an idiot
<lamont> hrmpf.
<lamont> no elmo, I assume>?
* lunitik wonders why he can't find something like --force-ignoremissing ... to ignore files that dont exist when removing?
<lunitik> Or am I just blind?
<lunitik> mdz: *cough*
<lunitik> uhh... Keybuk, sorry
<lunitik> cept he's not here  :(
<daniels> lunitik: it's not actually an error, just a warning
<lunitik> daniels: ohhh... could be why there is no option for it...  :P
<calc> --force-all is your friend
<lunitik> calc: I don't like doing that enless I'm sure  :(
<calc> heh, i was joking btw ;)
<lunitik> calc: ahh... k  :)   
<calc> doing things without understanding why will lead to a broken box
* lunitik remembers installing almost every day due to breaking things when he first started playing with Debian...   :P
<lunitik> 'playing' was definatly the operative word for it  :)
<calc> thats a good way to learn how to use dselect :)
<lunitik> calc: gah... you know, I still haven't actually installed anything with dselect or aptitude's ncurses interface...
<lunitik> *blush*
<calc> oh you used tasksel with debian?
<calc> or just a huge number of apt-gets?
<lunitik> calc: nah... I think the option was "bypass package selection" in b-f, and in d-i 'manually select packages' > q  ;)
<lunitik> calc: the latter... meta-packages are my friends  :)
* lamont wonders if germany is awake yet
<AndyFitz> gah,  gam_server   hates me 
<AndyFitz> well i hate gamin
<lunitik> AndyFitz: yeah, uhh... its generally a bad idea to IRC as root...
<AndyFitz> lunitik,  if this machine gets compromised there is no loss to me or the current network
<lunitik> But its a pain in the neck either way  :/
<calc> i'm sure some people that would get spam from that box would have something to say to you though ;)
<AndyFitz> this is really sudo anyway  i cant login as a normal user without it hanging in 20 seconds
<AndyFitz> calc,  postfix, sendmail etc arent on here
<AndyFitz> im watching the network monitor either way
<daniels> AndyFitz: boot with 'noinotify'
<AndyFitz> really ive got to figure out why   .ICEauthority and .Xauthority's perms are always changing   and why i get these atomic: gam_server errors
<lamont> AndyFitz: -23 kernel?
<daniels> AndyFitz: if you run apps under sudo, root will end up owning ICEauthority and Xauthority
<daniels> the answer being don't run X apps directly under sudo
<daniels> gksudo if you must
<AndyFitz> daniels  okay yeah i can appreciate that,  so that problem is solved.    now why the constant hangs and gam_server errors
<daniels> AndyFitz: boot with 'noinotify', or get a newer kernel
<AndyFitz> thanks btw daniels.   its logical that thats what is happening.   how do i boot with noinotify ?
<daniels> when you boot, press escape for the grub menu as it flies by in the three-second window; press e to edit the first entry, go down to the kernel line, and press e again
<daniels> add 'noinotify' to the end of that line, press enter, then hit b
<AndyFitz> too easy, thanks.   and what will noinotify do ?
<daniels> disable inotify, which is the part of the kernel that lets gamin know when stuff's changed
<daniels> that's the crashy bit
<AndyFitz> sweet.  okay thanks
<daniels> np
<lunitik> daniels: what use is gamin if its not realizing things change?  I thought that was the whole point of it?  *blush*
<daniels> lunitik: sure, but right now there are kernel bugs that make it unusable because your system just locks up
<lunitik> daniels: ohh... yeah, that would be bad
* lunitik shuts up
<jdub> gamin falls back to dnotify anyway
<lamont> hoary will ship with inotify disabled by default
<lamont> although we'll try to have it work right when you force it on
<tseng> rml says .20 is due out any time now
<lamont> once hoary ships, we'll turn it back on if it's semi-sane
<tseng> with more fixing
<tseng> zul and I are testing a partial fix
<jdub> rml is my bitch, btw.
<tseng> hm
<schweeb> jdub: lol, I'd love to hear his take on that
<lamont> jdub: you and mdz duke it out - I'm uncomfortable with enabling it by default given the date on my calendar and the current state of the code
<jdub> lamont: does mdz want it on by default?
* lunitik wonders what is refered to by 'rml says .20 is due'... (.20 of what?)
<jdub> schweeb: quoting...
<lamont> don't believe so
<jdub> You tell me what you want and need and I'll do it--I totally am at your
<jdub> mercy, as I infinitely appreciate you guys shipping inotify.
<jdub> 
<lamont> jdub: I think all 3 of us are in agreement
<jdub> lamont: then we're one
<tseng> lunitik: ... context clues are cool
<lamont> jdub: woot
<jdub> lamont: we are the holy trinity of inotify!
<schweeb> jdub: hah, awesome
<tseng> to quote rml for lunitik .. "Inotify, bitches!"
<lamont> jdub: but if you are silly enough to say 'inotify' as a kernel param, we'll try to have it not crash on you.
<lunitik> gamin is at .24... inotify is not a package apparently... I tried to check out contect clues  :(
<lunitik> context*
<schweeb> lunitik: heh, inotify is a kernel patch
<jdub> lamont: yep
<lamont> jdub: so what time does preview freeze hit?
<lunitik> schweeb: sooo not the point  :P
* lunitik feels dumber and dumber every time he comes here  :(
<jdub> lamont: "by end of wednesday", even in one of your laggy timezones :)
<lamont> heh
<schweeb> lunitik: only way to learn is by making mistakes. I'm no genius
<jdub> what i really need
<lamont> was wondering if tomorrow was still maverik-day, or if I had to behave, was all... :-)
<jdub> is NEW queue processing
<lamont> jdub: and for that, you need your other bitch
<tseng> jdub: dude. elmo said earlier that cleanlooks or whatever wasnt in there
<jdub> lamont: my special bitch :)
<jdub> tseng: eh?
<tseng> jdub: in fact, he said nothing was in there
<jdub> and now i say "wtf"!
<lamont> jdub: so now he's thpethial?
* jdub deletes his upload file and reuploads
<lunitik> jdub: care to link me to clearlooks .debs... pretty please?  :)
<jdub> http://people.ubuntu.com/~jdub/hoary/
<jdub> i386 and source
<lunitik> jdub: thank you  :)
<crimsun> how 'bout dem pants.
<tseng> perky pants indeed
<lunitik> Uhh... will /usr/lib/mime/debian-view install via the new Add/Remove Packages tool? ...if not, any plans for this?  :P
<tseng> lunitik: try it and see.. general queries go to #ubuntu please.
<jdub> andrewski: 		5
<jdub> meh
<lunitik> tseng: ahh... sorry
<lamont> hrm.. I seem to be missing jdub's font
<tseng> lunitik: other than a bit of random silliness (usually relating to jdub) we reserve this channel for development issues. thanks for understanding
<jdub> tseng: *cough*
<tseng> heh :)
<tseng> i want my jdub|tv
<lunitik> tseng: it kind of was a development issue, although perhaps better suited to bugzilla enhancement...
<tseng> you didnt even look to see if there was such an issue, actually.
<tseng> or at least thats how you came off
<schweeb> heh, jdubtv... that blog pic was...frightening
<tseng> schweeb: imagine it with silly background music and full motion
<tseng> I cant say there's anything quite like it
<daniels> mdz: anything else for 6.8.2-2?
<daniels> jdub: get an amd64, you fascist
<jdub> ah
<jdub> sure
<jdub> will await the delivery
<jdub> thank you for your donation
<lamont> jdub: he promised that I was ahead of you on the list..
<daniels> jdub: remember to hold your breath
* lamont turns blue
<jdub> we made rml sad
<AndyFitz> yay ,  daniels:  thankyou so much mate
<AndyFitz> I would never have guessed to add noinotify
<lamont> jdub??
<lamont> inotify disablage?
* lamont scratches his head, repeatedly
<lamont> -25 kernel source will enter the archive in 7 minutes.
<lamont> and then not be there in binary form 12 minutes later when the daily di and livecd builds happen
<lamont> oops
<tseng> lamont: is that with the inotify spinlock love?
<tseng> oh theres the log
<lamont> no inotify changes from -24
<lamont> and unless there's a RC bug for the preview release, I don't think we'll see another kernel upload until after the preview comes out
<jdub> lamont: yeah
<whiprush> jdub: is that vte in your repo the one with that performance patch?
<jdub> ah
<jdub> yeah
<jdub> some of them
<whiprush> woo.
<jdub> not all of the latest
<jdub> that'll hopefully be released as 0.11.12
<jdub> soonish
<lamont> Kamion: somewhere around 0903 you should have the -25 kernel in the archive for i386,ppc,amd64
<daniels> Kamion: xorg 6.8.2-2 is on its way
<lamont> daniels: oh, good.  I'm not last then. :-)
<zenrox> sweet
<zenrox> good improvments i hope
<mdz> daniels: I don't think so (the keyboard stuff and the duplicate questions were the only things which needed to be addressed for array 6)
<daniels> mdz: kay
<mdz> jdub: surely there is some way to address the unmounting problems, other than switching to inotify
<mdz> because kernel panics are far worse
<tseng> mdz: the diff between .18 and .19 is one line, comments out a spinlock operation
<tseng> also applied in -mm, it looks like quite possibly the culprit
<mdz> tseng: hmmm
<tseng> zul was building with the change
<mdz> I think we should leave it off by default for array 6
<tseng> i havent heard back from him with a .deb yet
<tseng> mdz: definately
<mdz> unless we can somehow confirm that it fixes all the bugs by morning
<tseng> its not in -25 anyway, it will have to wait
<mdz> ok
<tseng> I'll be sure to test it as soon as I get zuls package
* lamont sleeps
<tseng> mdz: 
<tseng> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/inotify-locking-fix.patch
<mdz> I think I'll do the same shortly
<tseng> has some commentation on the issue
<mdz> certainly a bug
<mdz> but it doesn't feel like it explains all of the crashes
<jdub> mdz: 0.0.25 may work around it
<tseng> "bugs on smp and preempt"
<jdub> mdz: the problem is dnotify
<jdub> (0.0.25 of gamin may work around it successfully)
<tseng> thatd be cool. id test your theory but i dont see .25 in the archive yet
<tseng> which is odd seeing as it built some hours ago
<tseng> if you throw one up in ~/jdub ill try it
<tseng> or tommorow.
<jdub> tseng: i uploaded it earlier
<mdz> tseng: the Packages files, for i386 at least, haven't changed in several hours; I think something might be wrong
<tseng> yep =/
<YokoZar> Could someone please explain why I need to make a .desktop file if I have a .mime and .menu file in my package?
<daniels> because .desktop supersedes .menu
<daniels> .menu was only a debian thing; .desktop is common between all distributions and all desktop environments
<YokoZar> I suspected it did.  Is there a way to have this done for me automatically, or do I need to do it by hand?
<YokoZar> Where do I put the .desktop file to have it installed in the right place?  I'm gonna put this thing upstream too
<daniels> you'll need to do it by hand
<daniels> under /usr/share/applications I think, but jdub can correct me
<YokoZar> Ok.  Would I be breaking any standard by creating a whole new Wine submenu?
<YokoZar> We're gonna put the Wine start menu in there.
<daniels> er, I think so
<daniels> jdub: the top-level menus are defined, yeah?
<pitti> Morning
<jdub> daniels: hrm?
<jdub> oh
<jdub> um
<jdub> you'd have to ship an xdg menu file or something
<jdub> it's kinda hard to get around this for wine
<YokoZar> Hmm.  Wine also will create its own .desktop files to point to this as you install windows programs
<jdub> yes
<jdub> they would use categories to fit in the wine top level menu
<jdub> probably best to talk to Mike Hearn about the new xdg spec
<jdub> and how to fit wine in
<daniels> doesn't mike work for code weavers?  or am I way off the mark there
<jdub> he does
<YokoZar> Crossover does this already, albeit in its own ways
<YokoZar> I should email Mike
<daniels> is anyone with an amd64 around?
<pitti> Kamion: ping
<dholbach> good morning
<pitti> Hi dholbach 
<pitti> mdz: still here?
<dholbach> hai pitti
<YokoZar> In a .desktop file, is the line Path=%d proper?
<YokoZar> or is %d only good for the Exec line?
* dholbach is off into the city
<smurfix> daniels: replied to your email
<daniels> smurfix: thanks
<daniels> smurfix: cool, thanks.  we don't have any three-letter language codes, only two.
<smurfix> daniels: Sure we do. tig_ER, sid_ET, gez_{ER,ET}, byn_ER.
<smurfix> daniels: guj => gu, which we have also. Dunno why X uses three-letter codes here.
<smurfix> daniels: ben => bn
<smurfix> daniels: kan => kn
<smurfix> daniels: tel => te
<smurfix> daniels: ... and "tml" is actually "tam" => ta, which we have also
<smurfix> daniels: That's even more stupid, that should be renamed / aliased in X.
<smurfix> daniels: Anyway, that's all it seems.
* smurfix needs to go shopping now, bb eveningish
<Brutis> hello
<Brutis> ?
<Brutis> i need some ubunto install help...
<Brutis> has anyone got a sec to help?
<Brutis> no guess not
<Treenaks> Why does everyone insist on calling it "Ubunto"
<lifeless> Treenaks: probably heard it pronounced
<HrdwrBoB> well you know
<HrdwrBoB> the channel name being 'ubuntu' is pretty obscure
<Treenaks> HrdwrBoB: hm, how about #ubunto and #ubunto-devel?
<Mithrandir> lunitik: don't remove xpdf, just ignore the package.  Or make a new empty package with the xpdf name.
<Mithrandir> daniels: ping?
<Kamion> daniels: you still up? that detect-keyboard thing doesn't look quite right ...
<pitti> Hi Kamion 
<Kamion> daniels: I'd recommend saying:
<Kamion>   REALLANG=${LANG%%@*}
<Kamion>   REALLANG=${REALLANG%%.*}
<Kamion> daniels: instead of @euro and .UTF-8, because euro and UTF-8 are not the only possible suffixes there (notably, .ISO-8859-1 etc.)
<Kamion> pitti: morning
<pitti> Kamion: deb http://people.ubuntu.com/~pitti/lptest/  /
<pitti> Kamion: ^ only -de language pack for now
<daniels> Kamion: ok
<daniels> Mithrandir: pong
<Mithrandir> daniels: what's the procedure for releasing fd.o software?  I want to roll a new release of pkg-config?
<Mithrandir> (like, where do I put the tarball and announce it?)
<lunitik> Mithrandir: ahh... alright, thanks  :)
<daniels> do you have pkgconfig.fd.o or pkg-config.fd.o?
<Mithrandir> daniels: unsure.  pkgconfig, I think.
<pitti> Kamion: http://people.ubuntu.com/~pitti/langpack-deps.txt shows the new scheme
<Kamion> daniels: not fatal for array 6, but if you can get it past preview freeze I think it'd be nice
<Mithrandir> it's just the binary which is called pkg-config
<Kamion> pitti: ok, thanks
<daniels> Mithrandir: just dump it somewhere there (/srv/pkgconfig.freedesktop.org/www)
<daniels> Kamion: need to do -2 for a6 anyway
<Kamion> daniels: I thought you'd already done -2?
<daniels> Kamion: not uploaded
<jordi> when is a6 due?
<pitti> Kamion: upgrade and installation from scratch work; however, manually upgrading just with dpkg -i is impossible (without --force flags)
<Kamion> jordi: today sometime
<pitti> Kamion: works fine with apt, though
<jordi> I've instructed the Catalan GNOME people to download it to test the stuff.
<Mithrandir> daniels: ok, and is there some common way of announcing, or just do it on fm and any other random places?
<pitti> Kamion: the only cosmetical flaw is now that an apt-get remove language-pack-foo won't automatically remove the base package
<Kamion> upgrading with dpkg -i without the stuff you need to handle pre-depends falls in the "unlucky" category
<pitti> Kamion: but I guess there is no solution for that now
<Kamion> pitti: that's just the inverse of the problem, though
<jordi> Kamion: I guess all the Ubuntu-desktop specific translatable strings are in rosetta?
<pitti> Kamion: yes, but better easy install than easy removal, I think
<Kamion> geez, why does w3m pop up file-roller (which hangs) rather than automatically gunzipping Packages.gz and displaying it inline?
<Kamion> pitti: *nod*
<Kamion> jordi: dunno, you'd have to ask the rosetta guys
<jordi> k
<daniels> Mithrandir: not really, just random places
<Mithrandir> daniels: ook
<Mithrandir> thanks
<Kamion> elmo: any idea when archive.ubuntu.com will start being up-to-date again?
<lifeless> mvo: I don't have  Release file at all at the moment, just Packages.gz and Sources.gz
<lifeless> mvo: this is for bazaar.canonical.com/packages/debs/
<Kamion> lifeless: 'apt-ftparchive release' can fix that
<lifeless> Kamion: does it work over sftp ?
<Kamion> uh ... it works on a local directory tree
<Kamion> why would it work over sftp? apt-ftparchive doesn't in general
<lifeless> uh, because at the moment I just use scanpackages on the new debs I've built.
<lifeless> I don't use apt-ftparchive at all.
<Kamion> so use apt-ftparchive at the same time that you do dpkg-scanpackages
<Kamion> or immediately afterwards, rather
<lifeless> ok, I'll have a fiddle.
<pitti> Kamion: if you are fine with the changes (I am now), I tell elmo about the package name changes (pre-add for NEW)
<pitti> Kamion: langpack-o-matic is ready to go and I updated the seeds
<pitti> Kamion: so as soon as elmo adds the packages, I can upload the stuff
<Kamion> I'm just trying an update
<Kamion> s/update/upgrade/
<mvo> lifeless: sorry for my slow reply. kamion said it all :)
<Kamion> pitti: ok, seems to behave correctly here on various kinds of upgrades, go for it ...
<pitti> Kamion: okay, I mailed elmo the necessary changes. As soon as the packages are pre-added, I pull the trigger
<doko> hmm, packages are entering the archives by hand approval from today on?
<Kamion> doko: probably tomorrow on in practice
<Kamion> ok, what's happened to the wiki?
<lifeless> ?
<Kamion> hm, not getting anything from www.ubuntulinux.org in general
<lifeless> cool, fall down go boom.
<ari> the ubuntu website is down a lot :/
<ari> or various parts of it
<doko> kamion: all packages, which add a new binary package from yesterday are built by the buildd's but not yet in the archives
<Kamion> doko: 09:31 < Kamion> elmo: any idea when archive.ubuntu.com will start being up-to-date again?
<doko> kamion: ok, thanks
<sabdfl> elmo: around?
<sabdfl> thom: around?
<thom> sabdfl: yes
<sabdfl> any status on the website?
<thom> just about to phone elmo and see if it's supposed to be off
<sabdfl> elmo's phone is off
<thom> gentoo is down entirely
<thom> hrm
<Kamion> that's presumably entirely unconnected with the archive mirroring issues ...
<thom> Kamion: yes
<Kamion> I guess it's release day, according to Debian tradition :)
<sladen> jdub: regarding LiveCD/coLinux.  the other thing to investigate come the time is xgl running on WGL which would get hardware-acceleration too
<pitti> ogra: ping
<sladen> thom: can you get Elmo's landline from Directory Enquires?
<thom> sladen: meh; i'll just go to the DC
<sabdfl> is elmo not back from vancouver yet?
<pitti> sabdfl: argh, elmo is travelling today?
<Kamion> that's next weekend not this
<pitti> uh, ok. We urgently need him today :-/
<seb128> is there a mirror updated ?
<sabdfl> hmm... he told me the weekend + one day's leave
<Kamion> sabdfl: last I heard, the schedule was 5th+6th March plus travel around that
<sabdfl> anybody have a cached copy of StaffCalendar, with his travel plans?
<Kamion> that's also what my diary says
<Kamion> seb128: I think all the mirrors are backed up to yesterday evening, including archive.u.c
* Kamion gets up to date on CD images in the meantime
<seb128> Kamion: k, thanks
<sabdfl> james is en route to heathrow, his flight is at 1:30pm GMT
<ogra> pitti, pong
<sabdfl> he believes it's a single-machine failure, gentoo
<ogra> morning
<sabdfl> the machine, not the distro
<sabdfl> james is back tuesday
<sabdfl> thom should have everything he needs to recover gentoo, but should look out for signs of a crack
<pitti> ogra: Hi!
<pitti> ogra: I made minor change to your patch
<ogra> pitti, ok
<pitti> ogra: tokens = g_strsplit (str, ":", 0); -> tokens = g_strsplit (str, ":", 2);
<pitti> ogra: otherwise it looks very good
<ogra> :)
<pitti> ogra: building the package now
<ogra> yay
<ogra> pitti, i will probably give you a little fix later, that collapses the tree of the bios device by efault in hal-device-manager....
<pitti> ogra: hmm, good idea
<ogra> pitti, i think this would look a bit better....
<pitti> ogra: how much later is "later"?
<ogra> pitti, dunno, its not high priority on my list....
<pitti> "preview freeze"
<ogra> pitti, its a fix :)
<pitti> okay :-)
<ogra> but only a cosmetic one.....
<ogra> hmm, sad..... http://bazaar.canonical.com is down ....
<pitti> ogra: 1.1.1 is in hoary, too :-)
<ogra> pitti: i know....i'm just replying to a thread in -users about website design...that turned to a thread about versioning systems....and nobody mentioned bazaar....
<ogra> so i wanted to point there....
<Kamion> thom: if elmo's away, can you act as deputy archive admin?
<daniels> GODDAMNIT
<daniels> Kamion: finally worked out my last bug and man was it stupid
* daniels wonders whether to assume his change worked and upload -2 as the day is already getting on in UTC, or to build and test (+1h).
<daniels> (in case anyone's interested: debian-installer/keymap and xserver-xorg/config/inputdevice/keyboard/layout, not xserver-xorg/config/inputdevice/keymboard/keymap)
<pitti> hey, linux 2.6.11
<Treenaks> pitti: -final?
<pitti> yep
<Treenaks> *leech*
<daniels> Kamion: oh, and fwiw, for your announcementy thingy -- 6.8.2-2 infers the x keymap from the d-i keymap, if that's worth putting in
<Kamion> daniels: definitely
<Kamion> thanks for that
<daniels> and the fact that it's 6.8.2
<daniels> np
<daniels> i'm going to disappear for a while until the build's finished, but if you need to upload xorg itmt (it *should* be ok), chinstrap:~daniels
<Kamion> I'm unsure as to what I can do at the moment release-wise without an archive admin anyway, since I'm going to need a d-i byhand for release
<pitti> ogra: uploaded
<ogra> YAY !
<ogra> :-D
<ogra> mjg59: ping
<Cym> Hi..
<Cym> I would like to report a problem with libapache2-mod-auth-mysql
<Cym> I have been going through the source code and comparing it to the previous version
<lunitik> Cym: bugzilla.ubuntu.com
<Cym> 4.3.8-1 doesnt display the problem but 4.3.9-1 gives me an internal error when I attempt to browse a directory that does not belong to the users group
<Cym> well I talked to the main package maintainer for it but he cant seem to reproduce the problem
<Kamion> Cym: our resident Apache guru is travelling to/from our datacentre at the moment, so as lunitik says filing a bug is probably the best approach
<Cym> and I noticed that ubuntu has repackaged it
<Kamion> it's not a repackaging
<Kamion> we've modified it to disable apache 1.3 support, since we don't want to support that
<Cym> right
<Cym> i saw that
<Cym> yah and that appears to be the only difference
<Kamion> the change in 4.3.9-1 sounds like it might easily affect permissions handling ...
<Cym> yes, the change has to do with multiple "require" statements
<Cym> with 4.3.8-1, it gives me a 401 which is what i want
<Cym> but with 4.3.9-1 it gives me an internal error with a 500
<Kamion> sabdfl: do you happen to know if thom can act as deputy archive admin in elmo's absence?
<Cym> most of the changes look like simple code cleanups
<Kamion> if not, I will have to do some strange workarounds for array 6
<Cym> well, thanks guys, ill start with another bug report
<Cym> i couldnt get anywhere with debian
<Kamion> Cym: (the Debian maintainer is also the upstream maintainer in this case)
<mjg59> ogra: Hi
<ogra> hi
<Cym> Matthew Palmer
<ogra> mjg59: i hav hibernate working on my acer 1520 (amd64) recently....
<mjg59> ogra: Rock
<ogra> mjg59: but if i choose a higher console resolution then 80x24 the console is totally broken after wakeup
<ogra> is this related to a missing vbetool in amd64 ? or should i look somewhere else....
<mjg59> Using framebuffer or just vgacon?
<ogra> hmm, just vga=771 i think thats framebuffer ?
<mjg59> Yes
<mjg59> vbetool may help, but framebuffers (especially vesafb) don't have decent suspend/resume support yet
<dholbach> there's no vbetool on amd64 yet
<ogra> ah, ok....so i will live with 80x24 then....at least its great i hav "any" supend now....thanks for the good work :)
<mjg59> dholbach: Indeed. I need to port it to x86emu at some stage.
<mjg59> I'm not especially looking forward to doing so.
<dholbach> mjg59: i can really imagine
* dholbach comforts mjg59 
<mjg59> Actually, I'm tempted to just write an lrmi->x86emu layer
<mjg59> Might as well make it generalisable
<mjg59> And vm86 is preferable on x86
<dholbach> i'll be back later
<dholbach> mjg59: good luck with it :-)
<daniels> mjg59: word
<mjg59> daniels: That radeon stuff seems to work now - we've got Thinkpads suspending without excessive battery use
<daniels> mjg59: phat :)
<Cym> darn, this bugzilla page has been trying to load for 10 min now
<Kamion> it'll be the component selector :(
<Cym> yah
<Cym> doesnt seem to work :(
<Cym> is there a good time to come back and talk with the resident apache guru?
<Kamion> Cym: not sure when thom'll be back. if you wait until Canadian daytime, infinity might be around too ...
<Cym> sure, its not a problem. I can wait
<Cym> I never know what timezone i need to be in :)
<Cym> I am getting by with downgrading, but I would just like to straighten this one package out.. its the only one Ive had to hold back for a few months now
<Cym> its taunting me
<Cym> thanks for your help Kamion
<Kamion> Cym: I solve the timezone issue by accepting half-day lags in conversations :)
<Cym> hehe yah im used to that :)
<Cym> this is just one of those things that would be better worked out over irc I think.. 
<thom> meh
<thom> Kamion: archive should be syncing now, www.* is back 
<Cym> oh hi thom
<seb128> thom: you rocl :)
<seb128> rock even
<thom> Cym: hi; i'm in the datacenter right now, not best time for questions :-)
<zul> hey
<thom> i'll  be home in an hour or so
<Cym> ok
<thom> Kamion: (infinity is in .au)
<zul> 2.6.11 was tagged in bitkeeper 5 hours a go
<Kamion> thom: oh, oops. when did he move?
<Kamion> thom: archive> woot
<thom> Kamion: a year ago? maybe more
<Cym> ill be back in a few hours
<sivang> morning all
<Kamion> thom: obviously I'm just way behind the times
<zul> gotta go to work
<daniels> Kamion: yeah, Cambridge can do that to you
<Kamion> daniels: when did it become 1700 AD, anyhow?
* thom -> home
<thom> Kamion: *giggle*
<daniels> heh
<thom> Kamion: when the sun rose over the edge of the world
<daniels> thom: and totally missed England
<daniels> thom: lucky you guys are all going to Canberra for a week beforehand -- you'll feel totally at home
<daniels> dull, boring, and overcast ;)
<Kamion> daniels: dude, England is like the French Riviera compared to Belfast
<thom> blah at 2 hours travel for 30 mins in the data center
<thom> Kamion: also, if you log into syowa from little you'll need to ensure your host key is up to date
<Kamion> thom: done, thanks
<daniels> Kamion: fair point
<pitti> doko: thanks for fixing curl
<ogra> smurfix: ping
<sivang> ogra: yo :)
<ogra> yo ?
<sivang> ogra: like "Hi" :)
<sivang> ogra: not Jaw
<ogra> yeah, i know ;)
<ogra> hi sivang :)
<sivang> hi ogra , how have you been?
<ogra> fine...
<ogra> thanks
<sivang> pitti: how can I mount a usb key manually?
<pitti> sivang: pmount /dev/sda1
<sivang> pitti: ok, I need to check why this is not working automatically on this laptop
<pitti> sivang: lshal, killall gnome-volume-manager && gnome-volume-manager
<sivang> pitti: /me attempts
<tseng> jdub: so, gamin .25 doesnt work around the lock
<seb128> lamont: here ?
<jdub> elmo: hooray, thank you! :)
<seb128> elmo: cool, clearlooks :)
<seb128> oups
<seb128> s/elmo/jdub/
<ogra> yeah....and it 0.3 :)
<dholbach> re
<pitti> thom: do you think that you will package mozilla 1.7.6 for Hoary?
<daniels> uvf!
<pitti> thom: because of http://www.mozilla.org/security/announce/mfsa2005-15.html
<pitti> thom: (this also needs a Warty update for ffox and moz, happy happy joy joy)
<pitti> thom: fortunately, it's a trivial patch
<pitti> daniels: security fix!
<daniels> oh man
<jdub> jdubtv! -> now in DV! -> http://node.waugh.id.au:8800/
<jdub> seb128: :-)
<jdub> seb128: more to come about that too :-)
<da_bon_bon> i want to translate ubuntu to hindi. can i be of any help ?
<tseng> good morning jdub lovers
<da_bon_bon> anyone from the l10n team here ?
<ogra> jdub: do you have david hamilton there (looks like butter on the lens)
<seb128> jdub: ah ah :)
<mvo> go jdub !
<da_bon_bon> i want to help translate ubuntu to hindi. can i be of any help ?
<dholbach> rad!
<dholbach> jdub: you could give live classes online for new MOTUs for example :-)
<Treenaks> Elmo-TV?
<daniels> kamion tv!
<ogra> yay, colin watson tv
<daniels> mdz is already on tv
<daniels> tune into mtv
<daniels> he goes under the alias 'moby'
<dholbach> wonder, if he heard it :-)
<ogra> lol
<Kamion> I don't really get this <foo>tv thing, watching somebody hack is not that exciting :)
<mvo> Kamion: but jdub does not only hack, he also makes funny faces all the time :p
<daniels> Kamion: but everyone would totally watch kamion tv
<jdub> Kamion: you're totally in demand for MOTU|TV
<helix> ah, you guys need to watch mako hack
<dholbach> yes! kamion!
<ogra> helix: url ? ;)
<Treenaks> jdub: we need OgraTV or MithrandirTV really
<helix> I don't think I have a url for this
* dholbach would record every show of kamion tv
<daniels> rhythmbox has locked up again.  this means it's time for bed.
<helix> I have only seen it LIVE
<ogra> heh
<daniels> Kamion: i'm crashing now, and will be unreachable for around the next 24 hours by stupid co-incidences.  if there are any xorg issues i'll need to look at before then, call or sms and i'll see if I can't get myself access
<Kamion> daniels: ok, thanks. if I can fix them easily myself, I will; I expect most of today to be waiting for stuff
<daniels> Kamion: ok cool, thanks.  cheers :)
* Kamion -> lunch while a million svn tags are renamed
<Treenaks> wb jdub 
<Treenaks> jdub: any idea when you'll be able to put flumotion & friends in Debian (experimental/sid/anything) ?
<dholbach> hoary!
<jdub> the next package set i upload to hoary, i'll be uploading to debian too
<Treenaks> jdub: cool :)
<jdub> it's newly split out
<Treenaks> dholbach: my server is not running ubuntu (yet?)
<dholbach> good excuse to re-install it :-)
<Treenaks> dholbach: nah, I'm one of the few people who thinks sarge will eventually release
<jdub> i run sarge on my mipsel machine.
<jdub> mipsel.ubuntu.com doesn't resolve yet.
<jdub> join the dots. ;-)
<jon1012> hi :)
<Astharot> ciao
<pitti> Hi Astharot 
<jon1012> hi
<Astharot> hi pitti 
<seb128> lamont: kick evolution to build please :)
<koke> shouldn't gaim build-deps on libhowl-dev?
<koke> first, hi all! :D
<seb128> no, we are kicking howl out, it's non-free
<jbailey> seb128: *lol*, serious?
<Keybuk> seb128: it is?  which bit?
* Keybuk thought howl was 3-clause BSD
<Treenaks> seb128: since when?
<rburton> Keybuk: howl contains apple APSL2 code
<seb128> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295775
<seb128> #295775: Build-depends on libhowl-dev, which will become non-free or removed
<seb128> 
<seb128> you can read about it here
<seb128> BTW I'm away for ~1 hour, bbl :)
* Keybuk watches another jdub recommendation bite the dust <g>
<koke> seb128: I don't know why, but gaim fails compiling if I don't have libhowl-dev
* sivang --> back after network outage
<zul> hey
<koke> I mean, apt-get source gaim; cd gaim-*; debuild -b
<pitti> sivang: any luck with g-c-m?
<Treenaks> koke: maybe it's built with --with-something ?
<Treenaks> koke: (where something is howl-related)?
<dholbach> Keybuk: that's not nice
<rburton> koke: probably one of the other gnome libs .la file still refers to howl
<sivang> pitti: do you have any idea why gksudo doesn't know it;s should run with the current user rather then root?
<sivang> pitti: maybe it's becasue I am sending it a null env ?
<Keybuk> dholbach: he knows I love him, raelly :p
<pitti> sivang: hmm, it should get the current user from getuid(), not from env's $LOGIN
<koke> hmmm, I see, it crahsed at plugins/gevolution
<dholbach> YEAH! P0RN!
<pitti> sivang: erm, $USER
<zul> tseng: ping i should have it real soon now
<pitti> sivang: however, if it doesn't work, just use NULL as environment, this should inherit the env to gksudo
<dholbach> jdub: did you know, Keybuk loves you?
<tseng> zul: rock
<pitti> sivang: I think gksudo cleans its env anyway
<tseng> zul: ill be here
<thom> mjg59: 7079 is all you :-)
<zul> tseng: ok ill be in a meeting at 10 but its building right now
<jdub> dholbach: he humps my leg regularly.
<pitti> sivang: erm, with an emtpy environment you don't even get $DISPLAY
<jdub> dholbach: so i kinda get the message/
<pitti> sivang: i. e. gksudo shouldn't even start
<dholbach> LOL :-)
<ogra> hehe
<sivang> pitti: hrm right, NULL means to inherit the caller env
<Treenaks> pitti: well, at least you won't have a security hole there 8)
<pitti> sivang: does it work?
<pitti> Treenaks: class-1 firewall :-) -> pull the A/C plug
<Treenaks> pitti: exactly! :)
<ogra> pitti: nah, thats to harsh....network plug is sufficient
<sivang> pitti: but I tested running gksudo from bash - it works fine, from the g_spawn_sync it asks for the root password. I will see how I can pass it the uid from getuid()
<mjg59> thom: Oh, FFS
<sivang> pitti: so I assumed this has something to do with an empty env, wrong again I was :-/
<Treenaks> sivang: Like Yoda, you sound!
<pitti> sivang: you cannot "pass" it a getuid()
<sivang> Treenaks: hehe
<elmo> Kamion: ubuntu20 went through on this cron.daily
<mjg59> thom: hibernate.sh is actually coredumping, which is impressive. I'm not sure if the other errors are related to that or not.
<thom> mjg59: that's pretty rad
<Treenaks> jdub: Ooohh!
<sivang> pitti: hmm
<dholbach> yeah :-)
<mjg59> thom: It ought to just be a whine, so I'm not sure why it crashes
<Treenaks> jdub: you shuold start #jdub-tv, to limit offtopic stuff
<jdub> ah, go to #ubuntu-love ;)
<mjg59> Hrm. I wonder if swsusp ought to be disabling preemption during resume.
<mjg59> thom: I /think/ we might be able to get around this with a preempt_disable()/preempt_enable pair
<mjg59> Oh, no, I might have this utterly wrong. Argh.
<jdub> http://people.ubuntu.com/~jdub/screenshots/fear-wine.png
<jdub> wine is very special
<sivang> jdub: this is crossover free wine?
<sivang> jdub: cool :)
<jdub> just wine
<trulux> jdub: heya
<jdub> yo yo
<Treenaks> jdub: the only question I have is: WHY?
<trulux> jdub: :) coulod we talk on a new mailing list creation?
<jdub> sure
<jdub> Treenaks: default font chosen
<trulux> jdub: ok, many thanks in advance, mdz and I have talked about the creation of a list on ubuntu proactive security implementation
<trulux> jdub: it means to have both support and development lists
<trulux> mdz: there?
<Kamion> elmo: rock, thanks
<Kamion> bloody hell, my laptop is *still* busy renaming svn tags, I set it going on that before lunch
<Kamion> admittedly the full checkout is nearly 1GB
<Riddell> elmo: could you add my key to be accepted for uploads to main?
<zul> i just found this: http://people.redhat.com/davej/hardware-problems.txt
* thom spanks benh
<Kamion> what's he done?
<thom> AC Power               : 0
<thom> Battery count          : 0
<thom> desktop macs apparently run without power :P
<Kamion> heh
<Kamion> they're just that cool
<Treenaks> thom: hey, I want a few of those :)
* thom adds workarounds
<thom> Treenaks: heh; it neatly balances the heat being spewed from the itanium and alpha next to it
<jon1012> hmm... just asking, do you think that it could be possible to add my app to universe ? (appliworks, http://appliworks.jondesign.net )
<jon1012> (the 0.4 will be out in just 1 week or something like that)
<metalikop> jon1012: it looks possible
<jon1012> I'm resolving some little issues, but 98% of the features are done
<metalikop> I'll check it out
<metalikop> have you already made a .deb?
<jon1012> nope
<jon1012> never :(
<metalikop> no problem
<jon1012> I use ubuntu as my daily development environment but I'm coming from fedora...
<metalikop> no problem, I'll put one together
<jon1012> wow thx :)
<metalikop> this seems a lot like f-spot
<jon1012> oh, in a lot of ways maybe, but the context is not the same
<metalikop> it's good to have a few to choose from
<jon1012> where f-spot tend to be big and with a lot of features, appliworks want to be really simple to use
<rburton> it's also good to pool the effort to make a better program
<jon1012> (90% of the things are done via DND)
<metalikop> indeed
<jon1012> and it's written in C
<jon1012> so it doesn't need all the mono environment
<sabdfl> daniels: any idea why installing Xnest doesn't give me the "Login in a New Window" option in the menu?
<sabdfl> is there a command line way to fire up gdm in a nested session?
<jon1012> gdm-Xnest no ?
<rburton> sabdfl: gdm should provide that menu item
<jon1012> GdmXnest escuse me
<jdub> sabdfl: gdmflexiserver -n
<Kamion> thom: on being told about www.u.c being down this morning, my fiancee asked whether it ran Windows ;-)
<jdub> sabdfl: the menu should appear, might be a menu update problem
<jdub> rburton: TryExec=Xnest
<jdub> :-)
<rburton> aaaah genius
<jdub> so i'm thinking of adding a TryExec=.../samba to the shares-admin thingy
<jdub> but it also does nfs
* jdub is not convinced that shares-admin is the right way to go about it
<sabdfl> jdub: ok, it appeared after a logout/login
<sabdfl> rburton: jon1012: thanks
<jdub> sabdfl: killall gnome-panel is a bit easier in future :)
<jdub> now that you've re-logged-in, you've probably got a new version of gam_server running, which will help
<sabdfl> jdub: am lookin for *minimal* changes to gdm human login
<jdub> sabdfl: will most likely just be colour.
<sabdfl> q: should we indicate the version of ubuntu on the gdm login?
<jdub> sabdfl: the gradient is a problem though
<jdub> no
<sabdfl> if we are only making tiny tweaks, it's nice to be able to see it
<sabdfl> current play is 5.04 // slinky // Wed Mar 02, 3:02 PM
<Treenaks> slinky
<Treenaks> wasn't that a debian release once?
<sabdfl> my laptop
<Treenaks> ah ok :)
<dredg> nah, that was slink
<dredg> close though
<Treenaks> dredg: oh yeah
<jdub> sabdfl: cliff is pretty clear on the recognition power of the current gdm; so far we're just going to change colour, and do something about the gradient.
<sabdfl> ok
<sabdfl> something subtle... colours on that one are pretty good
<jdub> if we put a version number in, it ought to be "Ubuntu 5.04"
<sabdfl> the thing i'd like to have seen there are some of the eye-candy fadeover effects for colour transitions
<sabdfl> mousover is a little SUDDEN at the moment
<jdub> that requires quite a bit more work
<sabdfl> also, the colour transition should affect the icons as well as the text
<sabdfl> bendy
<jdub> yes
<sivang> are we having some problems with the archive?
<sivang> it won't let me download a source pkg
<jdub> sivang: there were update issues earlier
<sivang> jdub: hrm
<sivang> jdub: ok
<dredg> yeah, the area around 'username' is very obviously not part of the gradient
<Kamion> should be fine now though
* jdub is up to 'e' on a bit mirror run
<sivang> Err http://archive.ubuntu.com hoary/main libgnomecups 0.1.14-0ubuntu2 (dsc)
<sivang>   Temporary failure resolving archive.ubuntu.comE
<sivang> 0% [Connecting to archive.ubuntu.com] 
<Kamion> that's a DNS problem
<Kamion> probably at your end ...
<thom> Kamion: *grumble* :P
<jdub> oh well, at least 2.6.11 didn't come out closer to final release date :)
<Kamion> I'm still confused about the way our linux-source-2.6.11.orig.tar.gz isn't
<Kamion> next time, I think we should do linux-source-2.6.12~1.orig.tar.gz or whatever
<doko> kamion: ~ is already allowed in ubuntu?
<Mithrandir> yes
<Kamion> doko: depends if we care about upgrades from woody any more; I guess since sarge isn't released, that's still a consideration
<Kamion> oh, hang on, linux-source-2.6.11.orig.tar.gz never got uploaded
<Kamion> must've just been fabbione talking about that
<thom> Kamion: thought it was in universe
<pitti> Kamion: http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-source-2.6.11/linux-source-2.6.11_2.6.11.orig.tar.gz
<Mithrandir> Kamion: we do have ~ versions in already
<Kamion> pitti: ah yes
<pitti> Kamion: probably he wants to maintain the changes to final as a patch, or so
<Kamion> Mithrandir: yeah, but IIRC not in anything required for the upgrade?
<Kamion> pitti: yes, I think it's better not to take that approach though
<pitti> agree :-), it's a bit ugly
<Mithrandir> Kamion: well, true
<Kamion> although sarge base is now changing little enough that it's probably safe to upgrade via that if you're careful
<dholbach>  brb
<sivang> seb128: how come there is a libgnomecups package downloaded on it's own in source form, and there is also one the same name in the gnome-cups-manager src pkg? (they have different files)
<pitti> sivang: the one in g-c-m is libgnomecups-ui
<pitti> sivang: or, rather libgnomecupsui
<lamont> good morning
<pitti> Hey lamont
<lamont> Kamion: ubuntu19 was ftbfs on all but powerpc, fwiw
<pitti> lamont: can you please ping me when you have a couple of minutes for discussing something?
<sivang> hiya lamont 
<Kamion> lamont: yeah, fixed in ubuntu20
<lamont> Kamion: woot
<sivang> pitti: but the name of the direcotry is identical : gnome-cups-manager-0.28/libgnomecups
<seb128> sivang: I don't understand the question
<pitti> seb128: nevermind
<sivang> seb128: pitti already helps me , thanks :)
<seb128> k
<seb128> thanks pitti :)
<pitti> sivang: yes, but it's just the directory name that is misleading
<Kamion> lamont: and byhanded by elmo before he left, and now hopefully just waiting for xorg_6.8.2-2_ia64 ...
<pitti> seb128: look in libgnomecups/.libs/
<sivang> pitti: should be probably changed
<Kamion> seb128: any more desktop stuff to come before array 6?
<sivang> pitti: this stuff makes you loose valuable time :)
<jdub> Kamion: new ubuntu-artwork coming
<lamont> Kamion: don't bother waiting - most of gnome is in eternal dep-wait hell because of gnome
<lamont> (ia64)
<seb128> Kamion: yep
<seb128> Kamion: depending if lamont has kicked stuff than need a kick or not
<jdub> seb128: you want a gnome upstream comparison done?
<seb128> Kamion: ie: evolution 2.1.6
<sivang> pitti: ok, g-c-m has it's own gksudo enabled spawning function, I am going to use it, would you like to review it for security implications?
<seb128> jdub: please
<lamont>      1350 Log for failed build of bug-buddy_2.9.92-0ubuntu1 (dist=hoary)
<lamont>       968 Log for failed build of curl_7.12.3-2ubuntu1 (dist=hoary)
<lamont>      1729 Log for failed build of gnome-system-tools_1.1.92-0ubuntu1 (dist=hoary
<lamont>       252 Log for failed build of gtk-doc_1.3-0ubuntu1 (dist=hoary)
<lamont>      1736 Log for failed build of ximian-connector_2.1.6-0ubuntu1 (dist=hoary)
<pitti> sivang: I take a look at it. file and function?
<lamont> that's my i386 list
<pitti> lamont: curl is already sorted out
<lamont> pitti: once I get done with bitching about gnome, I'll ping you
<pitti> lamont: thanks to doko
<seb128> lamont: quick x-c please
<seb128> lamont: bug-buddy has a new version in
<sivang> pitti: gnome-cups-manager-0.28/libgnomecups/gnome-cups-permission.c::gnome_cups_spawn
<lamont> seb128: x-c says: e2k-autoconfig.c:58:42: libedataserverui/e-passwords.h: No such file or
<lamont> +directory
<seb128> lamont: yeah, need to picks the new eds I guess
<Kamion> lamont: mm, what's the bottom of the ia64 dep-wait chain?
<Kamion> seb128: give me a shout when you're done, I'll test stuff in the meantime
<lamont> Kamion: gonna figure that out in a few seconds, but I have 23 ia64 failure logs in my mailbox, almost all of them because of uninstallable depends
* Kamion kicks cron.daily
<seb128> Kamion: we don't really need these new versions for array 6, if you want to roll it without them that's ok
<pitti> sivang: yeah, use it if it helps
<jdub> are dependency migrations into main automated?
<Kamion> jdub: no
<pitti> sivang: should have an easier interface
<Kamion> seb128: there isn't a vast hurry, some hours would be fine
<jdub> Kamion: do they require elmo and latex gloves?
<seb128> Kamion: k
<Kamion> jdub: elmo unless thom knows how to do it; latex gloves are optional
<sivang> pitti: might also make the patch less intrusive
<jdub> hrm
<thom> don't know dependency migration magic, no
<Kamion> jdub: not requiring any such stuff for array 6 would be good
<jdub> Kamion: ok.
<thom> jdub: if you're gonna inflict clearlooks on the masses, please can you work out why i no longer have a mist metacity theme
<thom> KTHX
<jdub> thom: ubuntu-artwork update is going to include cursors and stuff, but i'm not going to mass-fix upstream bugs directly in hoary
<jdub> s/bugs/regressions/
<thom> hrmph
<sivang> morning mdz
<mdz> morning
<mdz> Kamion: what's the latest on array 6?
<Kamion> mdz: test version building, but would prefer to wait for a few more desktop things from seb128 to sync up; new kernel, xorg 6.8.2-2, and updated d-i all in
<Kamion> and new language packs in I think, but need to check
<mirak> hi
<mirak> I try to run ubuntu using colinux on windows
<mirak> however there is a problem
<mdz> Kamion: ok
<mdz> Kamion: ~mdz/bin/awty :-)
<mirak> something tries to acces to the pci port, and of course it doesn't work.
<mirak> I was wondering if there is any particular service that ubuntu run that would try to probe pci ports at begining of run level 2
<mirak> I should ask that in other channel probably
<Kamion> mdz: heh
<Kamion> useful, that
<mdz> a bit heavy-handed
<pitti> Hi mdz 
<Kamion> mdz: it should look for newest of installer-$arch and daily-installer-$arch
<mdz> yes, it should
<mdz> pitti: morning
<Kamion> noticeable at the moment since daily-installer-powerpc wasn't working for a while
<zul> tseng: go get it ill be back later
<zul> tseng: http://zulinux.homelinux.net/ubuntu/kernel
<lamont> seb128: which version of which package is it that fixes the whole 'libhowl.la is missing' failure thang?
<seb128> for x-c ?
<mdz> Kamion: which package could I use as a test case to fix the daily-installer/installer thing?
<Kamion> mdz: rootskel
<lamont> seb128: looking at a diff package on either ia64 or hppa, truth be told, as I wander through my email.
<lamont> getting tired of doing the 
<lamont> give-everything-back-and-pray trick
<seb128> lamont: basically dropping libhowl-dev out of libgnomevfs2-dev 
<lamont> ok
<seb128> lamont: but libgnome libgnomeui evolution-data-server libbonoboui etc have it in their .la file
<seb128> and thanks libtool
<lamont> so things that are failing because of that want to d-w the current (source) version of libgnomevfs2-dev
<lamont> ?
<seb128> we get that mess
<seb128> no
<seb128> we want to rebuilt all these libs to get rid of libhowl in all the la files
* lamont will continue the hail-mary approach, then
<seb128> grep howl /usr/lib/*.la
<seb128> yeah, keep smatching the retries ...
<seb128> if you give me a failure I can say which one is faulty
<mdz> Kamion: ok, fixed
<lamont> seb128: ia64 is still failing eel2 with howl bitchiness
<lamont> but 20+ other packages are in the blender, we'll see what the next round says
<Kamion> mdz: cool, yeah. BTW I think your set import logic at the top is wrong
<Kamion> (purely on a technicality)
<Kamion> firstly 1.5 won't meet that condition but 1.3 will (if you care), and secondly set looks like it'll be undefined with python 2.4
<seb128> lamont: Setting up libgnome-desktop-dev (2.9.92-0ubuntu1) ...
<seb128> lamont: that's the issue for eel2, need 2.9.92-0ubuntu2
<Kamion> hm, except set() is a builtin in 2.4, silly me
<mvo> Kamion: is it too late to move libgnome2-perl to desktop? we discussed it a while ago on ubuntu-devel ML 
<Kamion> mvo: not from my point of view, but talk to mdz/jdub about that
<Kamion> I don't have jurisdiction over desktop
<jdub> i think it was heading towards a yes
* mvo hugs jdub 
<ogra> jdub: lets rewrite it in python for hoary+1 ;)
<sivang> ogra: let's rewrite everything in python for hoary+1 ! ;-) could be like python desktop
* sivang waves to jinty 
<ogra> sivang: so get more MOTUs in ;) 
<lamont> seb128: cool
<dholbach> ogra: and someone to review their packages ;-)
<sivang> pitti: halfway there, the gui is now responsive to weather browsing is enabled/disabled/custom. now make a callback for enabling/disabling.
<lamont> seb128: so, like we said, given the speed of the buildd's, hail-mary approach is probably simplest/fastest
<ogra> sivang: then lets start with the kernel ;) 
<mvo> jdub: I assume I can't to the seed change myself?
<sivang> ogra: hehe
<sivang> ogra: that was a very good one :)
<mdz> mvo: not right now, please
<pitti> sivang: cool
<seb128> lamont: out of the bases libs that should go fine
<sivang> pitti: hope to finish this soon, so it would get in
<pitti> sivang: please note that there is still a bug in g-c-m
<mdz> mvo: we are preparing array 6
<lamont> seb128: although g-s-t on amd64 concerns me...
<mvo> mdz: ok
<pitti> sivang: if you enable browsing, you don't immediately see new printers
<jdub> mvo: post-preview would be better, i think
<pitti> sivang: you have to restart g-c-m to see them there
<pitti> sivang: however, they will work
<mvo> jdub: ok
<sivang> pitti: unfourtunately I don't have my lan here, I am not at home, you would have to check it for me :-)
<pitti> sivang: sure, I'll do
<seb128> lamont: Setting up libnautilus-extension1 (2.9.91-0ubuntu2) ...
<seb128> lamont: need 2.9.92
<lamont> woot
<sivang> pitti: but you are restarting g-c-m with you backend scripts
<sivang> pitti: when we go enable/disable
<pitti> sivang: however, you can check yourself with "/usr/share/cups/browsing_status; echo $?"
<pitti> sivang: no, I restart cupsys, not g-c-m
<pitti> sivang: if you w
<pitti> sivang: if you can work around this bug by restarting g-c-m, this would be nice
<pitti> sivang: however, the bug should just be fixed
<pitti> sivang: I'll look into this tomorrow, though
<lamont> seb128: any word on gtk-doc?
<seb128> lamont: a sec, I look on it
<lamont> there's a bug in bz about it
<lamont> (build-conflicts openjade, but build-depends something that depends openjade...
<lamont> back in a few
<seb128> oh yeah, I've read that mail
<sivang> pitti: do we have till tommorow?
<pitti> sivang: for bugfixing, yes
<pitti> sivang: we can always fix bugs
<sivang> pitti: if we have till tommorow our UTC time, then I will also try tackle restarting g-c-m :)
<pitti> sivang: however, your stuff is partly a new feature
<pitti> sivang: so this is urgent
<sivang> pitti: right 
<sivang> pitti: ok, if we have until tommorow I'll see about restarting g-c-m after finishing this work
<pitti> sivang: don't worry, we can restart it if fixing the actual bug is too complicated/invasive
<pitti> sivang: for now, just do the required stuff to call enable_browsing
<sivang> pitti: ok, till _when_ do we have time?
<pitti> sivang: would be nice if you finished it today
<pitti> sivang: otherwise we do that after the preview
<sivang> pitti: which means for hoary+1 ?
<pitti> sivang: and can test the stuff in between
<pitti> sivang: no, after the hoary preview
<pitti> sivang: i. e. in the last month before the release
<pitti> sivang: but the sooner, the better
<sivang> pitti: right, ok, back to work :)
<mdz> seb128: which bits do you need to upload yet for array 6?
<seb128> mdz: all is uploaded, wait to get the builds all right
<mdz> ok
<seb128> mdz: i386 seems to be fine, gnome-themes 2.9.94 to build that's all but we don't need it for the array
<mdz> seb128: is the powerpc icons bug fixed?
<seb128> mdz: yep, with gtk 2.6.3
<seb128> jdub: around ?
<mdz> great
<mdz> mvo: update-notifier seems to still detect live CDs as upgradeable
<seb128> mdz: do you know if somebody will update the desktop files for gnome-app-install ?
<Kamion> mdz: mmm, I thought I fixed that
<dholbach> seb128: yeah! games! :-)
<mdz> Kamion: I saw the Packages files disappear at one point
<mvo> mdz: I was under the impression that Kamion fixed that?
<Kamion> the Packages files appear to be gone
<Kamion> apart from the ones under debian-installer/, obviously
* mvo downloads a live cd from today to test
<mdz> yep
<mdz> confirmed that a) non-d-i Packages files are gone, but b) update-notifier still wants to upgrade from it
* mvo kicks update-notifier
<jdub> seb128: yo
<mdz> hmm, stand by
<seb128> jdub: about gnome-app-install / desktop files ?
<mdz> perhaps that was actually from the previous CD
<mdz> sometimes g-v-m wakes up when I burn a CD, and notices the previous volume in the drive
<mdz> jdub: if you aren't going to get that done before preview, the time to hand it off is right now
<jdub> seb128: busy preparing talk for tomorrow; will most likely do it tomorrow afternoon
<jdub> mdz: data just needs tweakage, and then we'll need some g-a-i work
<seb128> jdub: I can do it if you want ... do you have any tool to get the desktop files ?
<mvo> jdub: what kind of g-a-i work is needed?
<jdub> seb128: 'sok, will sort out with ross tomorrow
<seb128> k
<seb128> mvo: s/gtk.TRUE/True/g :)
<mvo> seb128: heh
<seb128> /usr/lib/gnome-app-install/AppInstall.py:99: GtkDeprecationWarning: gtk.TRUE is deprecated, use True instead
<seb128> that's ugly :p
<mdz> mvo: yes, I just tested properly and the live CD is still recognized by update-notifier
<jdub> mvo: just some bugfixing for weird .desktop files
<mdz> I also noticed a bug in gnome-app-install yesterday, where if it can't find a certain package, it throws a stack trace and gets into a bad state
<jdub> bum. we really ought to ship gimp-svg.
<rburton> mdz: eek. can you replicate?
<mdz> rburton: let me boot the machine in question, and I can get you the trace from ~/.xsession-errors
<mdz> it looked trivial to fix
<rburton> mdz: excellent. mail it to ross@burtonini.com, thanks
<rburton> mvo: i get lots of (synaptic:1058): Gdk-CRITICAL **: gdk_window_set_cursor: assertion `window != NULL' failed when g-a-i spawns synaptic
<jdub> file and cc ross@burtonini.com please
<jdub> ugh, mirroring really hammers my network
<rburton> mvo: right, and synaptic has hung again
<rburton>  1062 ?        Zs     0:00 [synaptic]  <defunct>
<mvo> mdz: I'm downloading a current cd now and will fix it then
<mvo> rburton: I'll take care of the warnings
<mdz> rburton: mailed
<mdz> rburton: looks like it needs "self.cache[name]  and ..." or similar
<mdz> or name in self.cache
<mdz> building new live images with xorg 6.8.2-2 now
<mvo> mdz: do you want me to upload a fixed update-notifer (once it's fixed)? or should I wait until array-6 is finished?
<rburton> right, if "foo" is in baz control but i want the pristine file, i did mv foo foo.newer and now baz update won't give me the original
<rburton> why won't it do what cvs does!
<mdz> mvo: trivial fix?
<mdz> rburton: you want "baz undo"
<mvo> mdz: no idea yet, still downloading a testcd :/
<mdz> which I find more intuitive than what cvs does
<rburton> ah yes
<mdz> mvo: then let's wait :-)
<rburton> so i cp the file and baz undo it
<Kamion> (baz undo -n to throw away the change rather than leaving ,,undo-*)
<mdz> rburton: or just baz undo it; it saves your changes so you can redo them later, etc.
<mvo> mdz: ok :)
<rburton> aaah ok
<lamont> mdz: where does it save them?
<lamont> ,,changes<mumble>
<lamont> ?
<rburton> mdz: my arch tree has fixed your bug now i hope
<rburton> ,,undo<blurb>
<Keybuk> lamont: those are debris left by a bug in "baz update"
<lamont> Keybuk: ah, ok
<mdz> jdub: is the new ubuntu-artwork Cliff's stuff?
<jdub> mdz: no
<mdz> jdub: where does that stand?  he told me you guys had a meeting scheduled last night, but didn't say when
<jdub> mdz: we've had rolling meetings now that he's grokked the timezones
<jdub> mdz: goals are set, we're tracking daily drops, etc.
<mdz> jdub: are we on track to get a drop into hoary for preview?
<jdub> mdz: yep
<mdz> jbailey: ping, re: scsi.agent
<tseng> jdub: 
<tseng> crw-rw-rw-  1 root root 10, 63 2005-03-02 12:57 /dev/inotify
<tseng> rock.
<Kamion> is scsi.agent not done?
<jdub> tseng: 0.20?
<tseng> .18 + one liner
<mdz> Kamion: jbailey's intended changes are done; I want to discuss an additional change
<Kamion> ah, ok
<jdub> tseng: ahr!
<mdz> specifically, that sg should be loaded for cdrom devices
<mdz> in order to support writers
<jbailey> mdz: HEre.  What's up?
<mdz> jbailey: see above
* tseng tests the media/mnt issue
<mdz> jbailey: I emailed you a (substandard) diff
<jbailey> mdz: md and I were chatting by email about that - I don't get any information telling me that it's a burner AFAIK.  I can simply always load sg when there's a SCSI device easily enough.
<mdz> jbailey: yeah, that's what I've been doing
<mdz> daniels: xserver-xorg is asking me the video mode question on every upgrade
<tseng> jdub: hm, so still no hotplug usb showing up in drivemount-applet / desktop
<mdz> daniels: (this is my usual system, behind a KVM which doesn't do DDC)
<mdz> daniels: it's also wiping out my manually-specified sync ranges
<tseng> jdub: was rumored to be fixed in latest gamin
<Kamion> mdz: I'm off for dinner now; test images are syncing/burning in my absence
<mdz> Kamion: the cloop builds aren't quite finished yet, at least not for all arches
<Kamion> no problem
<jbailey> mdz: Oh, I see.  Do it only when it's a cd drive at all, that makes sense.  Is there nothing else that might want sg too?
<mdz> weddell and king are finished
<mdz> jbailey: the only examples I know of are CD writers and tape changers
<mdz> I don't have one of the latter to test with
* mvo is away for ~1h
<jbailey> mdz: I can do it easily enough with st then too.
<mdz> jbailey: if I'm not mistaken, this applies to USB writers, too
<mdz> it doesn't typically matter for me because I use growisofs and DVD media (which doesn't require the sg madness)
<jbailey> Do those show up as SCSI?
<tseng> hm, unmounting said usb hotplug device = hardlock
<mdz> jbailey: yes
<mdz> tseng: welcome to inotify hell
<jbailey> mdz: Then it should be covered by this.  I make sure that SCSI is run after both pci and usb.
<mdz> s/welcome/& back/
<tseng> thanks.
<tseng> at least it doesnt hardlock at login
<mdz> at least it doesn't eviscerate you and leave you to bleed to death
<tseng> that would be an interesting trick
<tseng> context switch from kernelspace to meatspace
<thom> mdz: you've been using tla again?
<mdz> thom: did you and enrico straighten out the OMF stuff for ubuntu-docs?  they still don't seem to be showing up in yelp
<thom> i don't appear to have anything from enrico; i'll grab and take a look
<froud> thom: we are stuck on the OMF scrollkeeper stuf
<froud> I have requested help from the devel group there
<froud> no answer yet
<sivang> froud: see the "writing scrollkeeper OMF files" intro on d.g.o
<froud> we are not sure if its a scrollkeeper problem or an XML catalog problem
<froud> sivang: its notthe OMF that is valid to the DTD
<froud> the problem is at registereation
<froud> registration
<sivang> froud: is enrico calling update-scrollkeeper post install?
<froud> we get an error that the dtd cannot be loaded from the network
<sivang> froud: argh
<mdz> it should point to the local copy, not the network copy
<froud> it does
<froud> but the DocType Decl uses Docbook 4.3
<mdz> froud: neither ubuntu-faqguide nor ubuntu-quickguide installs an omf file; is that intended?
<froud> mdz: yes
<froud> we have notpackaged it as it does not work yet
<froud> we cant register the OMF without errors
<froud> but we also have problems with Yelp
<froud> it doe snot support many things
<froud> I would preffer to only use the HTML we derived from the XML
<froud> Open directly in FireFox from System > 
<froud> menu
<mdz> can't yelp read the XML directly?
<froud> It can but does not support the full docbook tag set
<froud> also cant handle certain attributes
<rburton> froud: shaun has said he'll expand the xslt on demand
<froud> makes a mess ofthe output result
<froud> yes I sope to him
<froud> spoke
<froud> he does not hav ethe time
<froud> I was gonna patch the XSL
<froud> but have not had the time for it
<froud> so it is a bug in GNOME bugzilla
<froud> mdz: the scrollkeeper/OMF problem should not stop the release
<justinc> does hoary have multilib support for amd64 like the way fedora does it or do/will you need to create a 32bit chroot?
<froud> providing people will agree to use the HTML version
<rburton> froud: whats the bug#?
<mdz> froud: ok. when is the next documentation meeting?  i would like to discuss all of the issues which are relevant to the release
<jdub> froud: wow, what kind of weird stuff are you using?
<froud> mdz: I will ask enrico     to post a metting
<froud> meeting
<rburton> jdub: that is what i'm thinking. most tags would be trivial to add
<mdz> thanks
<froud> jdub: docbook 4.3 but for    example we use the endterm of xref
<froud> yelp does not know what to do in the XSL
<mjg59> Gah damned network card reference counting
<jdub> froud: you should talk to shaunm on irc.gnome.org, #gnome-hackers
<froud> jdub: I have had numerous conversations
<froud> personally I dont think Yelp is production ready
<jdub> ...!
<seb128> it works great here
<sivang> it works great for me also :)
<froud> jdub: we can get far better results with just XHTML/HTML
<seb128> ?
<jdub> froud: yelp renders all the gnome documentation, which is not exactly insignificant.
<sivang> seb128: it also _so_ pretty , I should tell shaunm about how much I like it 
<rburton> froud: did you file the missing elements in gnome bugzilla?
<jdub> froud: yes, there are some unsupported elements, but shaunm can very quickly outline those
<froud> well guys why dont you go at it
<jdub> froud: i would be very surprised if we required much outside the scope of the gnome documentation requirements
<seb128> jdub: not only the GNOME one, it displays the API and other debian stuff fine too :)
<sivang> froud: work with shaunm, he would help us make the XML integrate nicely
<froud> I am saying yelp does not support what we are doing in the Ubuntu Docs
<sivang> froud: did he get an account for the docteam svn server eventually?
<froud> sivang he did not want one
<froud> he cant commit to the project no point giving him an account
<rburton> froud: is there a list of tags which are problematic?
<sivang> froud: eh, talked with him before mataro and he was interested, well, guess he changed his mind.
<froud> two are tops of the list: trademark
<jdub> sivang: he's keen to help, but he's very busy. becoming a documentation maintainer is not going to be useful for him.
<froud> and the endterm attribute on the xref
<rburton> froud: ok
<sivang> jdub: ah good to know he didn't change his mind then ;) and yes, I know he's very busy 
<froud> The GNOME docs are made to strict templates
<froud> these templates do not meet our requirements
<mxpxpod> quick question: is anyone working on the 2.6.11 kernel for ubuntu?
<jdub> froud: why's that?
<froud> their template is great if you want to write a single apps doc
<thom> froud: i'm still trying to work out what specific problem you guys were having with scrollkeeper/omf? is there a mailing list post or something to describe it? (also, are the omf files for faqguide/quickguide available anywhere?)
<tseng> mxpxpod: the kernel team has been hacking on it since rcX
<mxpxpod> tseng: awesome
<froud> we are writing for across mutiple apps in different context
<tseng> mxpxpod: maybe after preview freeze..
<mxpxpod> tseng: preview freeze?
<ogra> tseng: oh, tomorrow ?
<froud> thom: do checkout of our svn trunk
<thom> froud: which is where?
<froud> thom: https://docteam.ubuntu.com/repos
<froud> thom: https://docteam.ubuntu.com/repos/trunk
<froud> We have one omf at present for testing see in debian/
<mdz> ubuntu-docs installs release-notes.omf and about-ubuntu.omf
<mdz> those don't seem to cause problems, as far as I see
<thom> they appear to register without problems
<froud> mdz: can you find the docs in yelp
<mdz> froud: no
<froud> we have only been testing on about-ubuntu.omf
<sivang> froud: have you specificed which under seciton you want to have the file registered?
<sivang> froud: this is important so yelp knows where to display your doc 
<mdz> I don't know where te look, either
<sivang> froud: (that is, under which catagory)
<froud> i did not realize enrico had added the omfs already
<mdz>     <subject category="Core|Distributions|General|Introductory"/>
<mdz> is that the relevant bit?
<sivang> mdz: there's also something for the other ones, like "Desktop | Developemtn | ..."
<sivang> mdz: IIRC
<rburton> froud: trademark works for me with yelp 2.10
<froud> we have 2.9.3
<mdz> sivang: install ubuntu-docs, look at /usr/share/omf/{about-ubuntu,release-notes}.omf
<mdz> 2.9.3cvs20050222-0ubuntu2
<mdz> is current in Hoary
<froud> at leastthat what I got in the last hoary update
<seb128> you need the CVS snapshots
<rburton> the important package is gnome-doc-utils
<seb128> of gdu/yelp
<froud> shaumn may have fixed some things in 2.10
<seb128> you should try the current versions ...
<sivang> mdz: ok, looking there in a minute.
<rburton> <trademark> was added on 2004-05-24
<froud> mdz: can you do scrollkeeper-install -v -p about-ubuntu_db_dir about-ubuntu.omf to see the error we get 
<froud> seb128: why if hoary is shipping 2.9.3
<froud> mdz: the permission error is normal
<seb128> ii  gnome-doc-utils  0.1.2cvs20050221 a collection of documentation utilities for the
<seb128> ii  yelp             2.9.3cvs20050222 Help browser for GNOME 2
<froud> its the network entity that is the prblem
<seb128> froud: we have some CVS snapshots
<froud> yes of 2.9.3
<mdz> I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd
<seb128> sure, that's the current version in the CVS
<froud> mdz: that's th eproblem we want solved
<mdz> froud: you need to fix that in your XML
<froud> seb128: 2.9.3 is problem
<seb128> why ?
<mdz> mizar:[/usr/share/ubuntu-docs/C]  grep -r 'http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd' .
<seb128> that's the current upstream code
<mdz> [lots of matches] 
<froud> why cant we use Docbook 4.3
<mdz> froud: you can
<seb128> mdz: the catalog should take care of this, shouldn't it ?
<mdz> but it's in /usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd
<mdz> don't use an http:// URL
<mdz> seb128: should it?
<froud> mdz: that's my point hoary xml catalog resolver etc is messed
<rburton> froud: what system id were you using?
<froud> mako: logged bugs on this
<froud> Hoary
<seb128> mdz: we have stopped to sed the oasis dtd in the debian/rules since we have a catalog
<mdz> seb128: it should detect the URL and substitute the local file?
<seb128> correct
<thom> your OMF doesn't match your docbook, either
<mdz> ah, I didn't know that
<mdz> seb128: which package handles that?
<froud> thom only the releae enotes one
<froud> thom: only the release notes one
<jdub> mdz: libxml2 does the resolving, if there's a valid (and useful) catalog
<thom> froud: about-ubuntu too
<froud> we are trying to get the about-ubuntu.omf working
<sivang> froud: what about <relation seriesid=""></> tag? I don't see you created one for about-ubuntu.omg
<sivang> froud: omf, even
<dholbach> isnt it libxml2-utils?
<seb128> mdz: the catalog stuff are in /etc/xml/ and the packages shipping a dtd are supposed to use update-catalog, but I don't really know the details on how that works
<sivang> froud: or did you find out it's not neccessary?
<froud> <format mime="text/xml" dtd="-//OASIS//DTD DocBook XML V4.3//EN"/>
<froud> <relation seriesid="7fb11226-8a1d-11d9-9fcf-ff970c259736"/>
<froud> do you see that in about-ubuntu.omf
<sivang> froud: I don't
<froud> svn up
<sivang> froud: eh, I installed from source
<froud> no the build is behind the src
<froud> I think enrico did the build before we discovered this problem
<mdz> seb128: what is the URL used in the documents which work properly with the catalog?
<mdz> ./docbook-xml.xml:<delegatePublic publicIdStartString="-//OASIS//DTD DocBook XML V4.3//EN" catalog="file:///usr/share/xml/docbook/schema/dtd/4.3/catalog.xml"/>
<mdz> there seems to be an entry in the catalog
<seb128>  xmlcatalog --shell 
<seb128> > public "-//OASIS//DTD DocBook XML V4.3//EN"
<seb128> file:///usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd
<seb128> mdz: that
<mdz> yes, that seems to work as it should
<seb128> yep
<mdz> isn't the problem that the files refer to the system id (URL) rather than the public id (-//OASIS...)
<seb128> I think so
<froud> seb128: we also have a problem with catalogs when we run xsltproc in our make
<froud> seb128: it always wants to go to the network when the dtd is installed local
<seb128> is your catalog working ?
<seb128> ie
<seb128> <seb128>  xmlcatalog --shell 
<seb128> <seb128> > public "-//OASIS//DTD DocBook XML V4.3//EN"
<seb128> <seb128> file:///usr/share/xml/docbook/schema/dtd/4.3/docbookx.dtd
<froud> hold must reboot my hoary host I just crash ed it
<froud> ok new machine
<mako> this series of bugs has been showing up repeatedly in debian xml packages
<mako> i've fixed it at least three times in different places in debian
<froud> seb128: no
<mako> in one packages (the slides stuff) it has been reintroduced at least twcie
<seb128> froud: so your system is broken somewhere ...
<froud> and everyone else on the docteam?
<mdz> yes, the catalog lookup certainly seems to work from the shell
<mdz> but it clearly isn't using it for processing the xml for some reason
<froud> to get xslt proc working we hav eto export the xmlcatalog
<mdz> if I change the URL to a local one, it works of course
<froud> mdz: sure
<mdz> shouldn't we do that as a workaround, since these documents are intended to be used primarily on Hoary?
<sivang> froud: when you have your OMF registering, take a look at /usr/share/scrollkeeper/Templates/C/scrollkeeper_cl.xml - make the omf falls into one of the catagories specified there, if you havn't done so already.
<seb128> BTW time for dinner, bbl
<froud> sivang: OK. I saw this part in the scollkeeper docs 1.0
<froud> I dont think the problem is scroollkeep I think it is the xml catalog on hoary
<froud> mdz: yes we can, but that means we work around a bug without solving the problem
<sivang> froud: ah ok, just noting it to you since I managed to register some dummy docs of mine into yelp long ago, and the one thing preventing me from succeding was that I used the wrong catagories.
<froud> mdz: it also assumes the location of the dtd will not change in the furture
<froud> sivang: thank
<trulux> tritium: ping
<tritium> trulux, hello
<froud> mdz: btw on my suse boxes the dtd and xsl's are indifferent places. The same place you will find them on most distros
<trulux> tritium: going to finish as most sections as I can, the JFFS3 work could get some time before I really start coding, among the currently cailable patch, Intell will approve the work in 2 months or so :D
<froud> I dont know why debian still has them in the old locations
<trulux> tritium: howya?
<mdz> froud: as far as I can tell, the catalog is correct
<mdz> apparently scrollkeeper isn't using it properly
<tritium> trulux, I'm fine, thanks.  You?
<froud> at this point it gets beyond me
<mdz> aha
<froud> mdz: I am       opefully going to get a response soon from the scrollkeep devel team
<mdz> it works if I use DocBook 4.0
<mdz> but not 4.3
<trulux> tritium: I'm ok, happy 'cos exams finished :D
<froud> you tried it and it worked or you asking
<mdz> I tried it
<mdz> it works for the 4.0 example document, but not for the 4.3 example document
<mdz> /usr/share/doc/docbook-xml/examples/test-4.0.xml
<mdz> /usr/share/doc/docbook-xml/examples/test-4.3.xml
<tritium> trulux, good
<froud> Hmm ... I'm not immediately sure where the problem lies either. Would
<froud> you be able to attach an example OMF file that fails, please? This
<froud> shouldn't be too hard to diagnose.
<froud> mdz: here is the initial response from one devel of scrollkeeper ""
<froud> so I sent him the file.
<froud> mdz: I will role back to dtd 4.1.2
<froud> until we fix this
<froud> or they do
<mdz> that works as well
<froud> ok that is what I will do
<froud> mdz: thanks
* lamont grumbles about kde-in-main's effect on his local mirror, heads down to a friends house to finish babysitting gnome
<mdz> lamont: have you considered that perhaps you don't have enough bandwidth for a local mirror?
<lamont> mdz: I don't have enough money to _not_ have one
<mdz> lamont: I don't understand; a local mirror surely uses more bandwidth, not less
<lamont> I have all the data transfer I want, at 56kbps or less.
<lamont> the local mirror lets me spread the download cost over the entire day
<lamont> rather than downloading at speed (or not) as needed
<lamont> and it's a partial mirror, although I do have it pretty much grabbing all of main (minus some langpack stuff, and -dbg packages)
<thom> seb128: btw, OMF file [/usr/share/omf/gnome-utils/gfloppy-ja.omf]  does not validate against ScrollKeeper-OMF DTD: /usr/share/xml/scrollkeeper/dtds/scrollkeeper-omf.dtd
<lamont> I have ~300kbps worth of bandwidth, but only ~100MB  of over-56kbps traffic per day
<lamont> and hopefully DSL availability sometime this year.
* lamont crosses fingers
<lamont> anyway, back on in a few.
<froud> mdz: ok roleback is done will test the situation
<mdz> froud: great, thanks
<mdz> froud: please file a bug in bugzilla about this issue, so that we remember to fix it
<froud> about the catalog or scrollkeeper :-)
<mdz> froud: about the issue we just discussed
<froud> mdz: yes, but is the bug in scrollkeeper or the catalog system. or you mean just log the whole lot
<mdz> froud: the location of the bug is our problem
<froud> ok
<Kamion> mdz: this "xserver-xorg asks questions multiple times" thing isn't a blocker for array 6, is it? I'm assuming it doesn't affect initial installations
<mdz> Kamion: I thought that was supposed to be fixed with 6.8.2-2
<thom> froud: changing the category to  General|Linux|Distributions|Othe gets about-ubuntu into yelp
<thom> um, Other
<thom> froud: `scrollkeeper-get-content-list C` is a very useful tool
<thom> (and I think that category is more correct, anyway)
<jdub> dudes
<jdub> check out distrowatch
<jdub> last three months
<jdub> we're number two, below a falling mandrake :)
<Kamion> mdz: oh, I thought you reported it just recently
<froud> thom can you post your patch to the docteam list
<jdub> for one month, we're 200 points ahead
<mdz> Kamion: that's a different issue, and no, not a blocker for array 6
<Kamion> mdz: ok
<mdz> jdub: we've been ahead on 1-month for some time now, but haven't broken the 3-month list
<thom> froud: ubuntu-doc@ or what?
<froud> thom: ubuntu-doc@lists.ubuntu.com
<mdz> I think we need to do a lot of work on the yelp hierarchy in general
<mdz> things like the faq guide and quick guide should be out in front
<mdz> and we should bury some of the more esoteric stuff, especially developer-oriented docs
<jdub> yes
<lamont_r> jdub: and #4 on the 6 month list.
<sabdfl> yelp's *looking* fantastic, just a question of organising the content better
<froud> mdz: then there are those of us who what to bury Yelp altogether
<mdz> froud: :-)
<sivang> mdz: right, it's a bit blurry to know where to find stuff for the average user
<mdz> the interface is clean and simple; I understand your concerns that it is lacking in some features on the backend though
<jdub> froud: yelp itself is excellent. the infrastructure below is wobbly.
<froud> KDE HelpCenter here we come
<mdz> we should be able to correct those working with upstream in the future
<mdz> speaking of KDE
<jdub> mdz: we've already done quite a bit, working with upstream :)
<sabdfl> is there a good local search engine?
<mdz> lamont_r: we need to start building Kubuntu cloop images
<mdz> lamont_r: as of today, the metapackages and their deps are in main
<Treenaks> I have a few small issues with yelp -- report bugs (minor) ?
<jdub> sabdfl: not really, but we'll get it via medusa and/or beagle
<thom> sabdfl: waaaah, bouncing cow is my favourite screensaver
<sabdfl> sorry dude
<Kamion> mdz: I'll look at Kubuntu ISO images tomorrow
<mdz> bouncing cow is a wonder of wonders
<jdub> thom: now that pia is trying vegetarianism, she has that on all the time
<mdz> Kamion: right, after array 6 is in the bag
<thom> sabdfl: but yes, agreed
<sabdfl> mabe we can get a high quality penguin modeled?
<froud> jdub: the day sof help viewer tools has gone. Plain firefox is all that is required
<jdub> sabdfl: bouncing soyuz?
<Kamion> good, I was hoping there was no requirement to have a Kubuntu Array 6 :)
<sabdfl> hmm... bouncing cosmonaut
<mdz> Kamion: I think we can shoot for having a kubuntu preview, though
<thom> sabdfl: we could get a different model for each release
<Treenaks> sabdfl: get yourself modeled :P
<mdz> at least a live CD
<Kamion> mdz: yeah
<thom> bouncing hedgehog, etc
<lamont_r> jdub: 1 month stat is way cool
<Kamion> sabdfl: oh, my five-year-old stepson-to-be asks if you saw the Great Wall of China from space; I couldn't remember
<jdub> lamont_r: 250 clicks!
<froud> thom: did you send that patch?
<froud> I want to build
<froud> and test
<mdz> lamont_r: can you have a set of kubuntu cloop images ready tomorrow?
<thom> froud: not yet dude, chill out
* froud put behind on ice
<lamont_r> mdz: just need to know what to include in them
<thom> froud: i think you need to review all your category choices, anyway
<Kamion> mdz: (various chunks of KDE haven't built yet judging from britney output)
* lamont_r assumes kubuntu-{base,desktop,live}
<mdz> lamont_r: standard base, kubuntu-desktop and kubuntu-live
<thom> froud: and fix how you're installing omf files
<thom> all coming in the mail
<lamont_r> mdz: assuming they're installable, no problem
<mdz> lamont_r: ubuntu-base (there is not / will not be a separate kubuntu-base)
<Kamion> well blast, mount -t nfs riva:/kickstart doesn't want to work
<froud> thom: actually I don't know how we're doing it, enrico di dthat stuff . thanks for the headsup will take a look
<froud> thom: will get this done in the morning. I am bleeding from my eyes now and my finger tips hurt
* froud off to bed
<mjg59> Argh christing swsusp PAIN
<lamont_r> mdz: awesome
<mdz> Kamion: are the published kubuntu seeds not refreshed with the same frequency as the ubuntu ones?
<thom> froud: sent
<mdz> never mind, caching
<Kamion> mdz: identical frequency, same cron job
* thom goes to hunt down food
<mdz> Kamion: the desktop seed in both ubuntu and kubuntu contains openoffice.org-thesaurus, which doesn't seem to have ever existed
<mdz> (it's pure virtual)
<mdz> I think we should just remove it
<Kamion> isn't there -thesaurus-en and stuff?
<Kamion> we probably want at least some of those
<thom> mdz: it appears that evolution builds against mozilla, still
<mdz> language-support-* should handle oo.o thesauruses
<Kamion> true
<Kamion> sure, works for me
<mdz> but I don't think they do currently
<mdz> at any rate, it isn't doing anything in the seed
<mdz> thom,seb128: is that fixable?
<thom> i only just noticed, i'll try building it with firefox after dinner
<mdz> lamont_r: kubuntu-live isn't there yet, but don't let that block you
<zul> hey
<Kamion> mdz: certainly germinate spits out a warning for it
<mdz> lamont_r; just use ubuntu-live in the meantime
<mdz> until elmo processes the new kubuntu-meta with live love
<mdz> Kamion: as does *-meta/update
<lamont_r> mdz: do we have kubuntu-destop, then? or is it in NEW to?
<lamont_r> too, even
<mdz> lamont_r: kubuntu-desktop is large and in charge
<seb128> mdz: just back from dinner, reading
<lamont_r> woot
<mdz> lamont_r: in main and installable
* lamont_r plans to just build both on the same machine, back to back
<mdz> lamont_r: it would be nice to be able to build them separately when needed, since we're likely to revise the kubuntu stuff a lot over the next week
<mdz> (i.e., with the ssh-able trigger you set up)
<lamont_r> yeah - it'll be args to the same script, I expect.  ubuntu or kubuntu, defaulting to ubuntu
<mdz> perfect
<lamont_r> well, ubuntu, kubuntu, all - choose one or more :-)
<thom> mdz: either way, can we remove the mozilla locale packs from the language-packs?
<mdz> thom: hmm
<Loevborg> mjg59, I'm conversing with you about [Bug 7079]  hibernate report: hibernate.sh crashes
<thom> oh, my bad. they appear to be gone
<Loevborg> mjg59, that is, you can also talk to me directly.
<sivang> can anybody tell me how can I use gksudo to call a root needing program from bash?
<wasabi> gksudo program
<wasabi> ?
<seb128> mdz: <mdz> thom,seb128: is that fixable? <- what ? the dtd issue ?
<thom> sivang: gksudo echo foo
<sivang> wasabi: doesn't work. doesn't pop up, nothing
<mdz> seb128: evolution using mozilla, rather than firefox
<sivang> thom: uh-ha
<seb128> oh
<seb128> mdz: when does it uses mozilla ?
<thom> seb128: no, evol b-d's on libnss-dev
<seb128> ah
<thom> which is mozilla
<mdz> oh
<seb128> any issue to use libnss-dev ?
<seb128> I think that's fine ...
<thom> seb128: it keeps mozilla in main
<Cyym> hello
<mdz> lamont_r: hmm, looks like elmo handled kubuntu-live ahead of time, so it'll be there shortly
<seb128> thom: is there any firefox equivalent libs ?
<lamont_r> cool
<mdz> lamont_r: oh, never mind, that was the source getting accepted. the binary will still end up in NEW
<lamont_r> unless he seeded it
<thom> seb128: sure, libnss3.so ;-)
<seb128> s/libs/package libs/
<sivang> thom: doesn't work for me, I wonder what I am doing wrong.
<Cym> thom may I pm you?
<seb128> or you want to build-dep on mozilla-firefox-dev for that ?
<thom> Cym: prefer you don't
<thom> Cym: if you have questions, just ask
<Cym> yah ok
<thom> seb128: m-f-dev
<seb128> mdz, thom: syou want to change that for hoary ?
<seb128> thom: I'll have a lot, but you should split firefox :)
<Cym> just trying to get this libapache2-mod-auth-mysql issue straightend out
<thom> Cym: what's the issue?
<thom> seb128: yah
<Kamion> ok, NFS kickstarting extremely slow for no obvious reason, but does in fact work
<Kamion> lamont_r: elmo said earlier that he doesn't preseed new
<Cym> well, with the latest version, apache returns a 500 with an internal error message if I try to access a directory that the user does not belong to (when using "groups")
<zul> anyone seen tseng?
<Cym> the "
<Cym> err
<Cym> the "user" directive works fine
<thom> nice bug
<tseng> zul: here
<zul> ah good
<Cym> if I go back to the previous, it works as expected, so the only difference I can see is that the latest version is supposed to support multiple "require" statements
<lamont_r> Kamion: ok
<Cym> most of the changes are simple code cleanups
<Treenaks> thom: is it Known that there's novell branding in Firefox help?
<thom> Treenaks: in our firefox help?
<tseng> Treenaks: are you using garett's theme?
<Treenaks> tseng: oh wait that might be it
<tseng> it is
<thom> heh
<Treenaks> thom: sorry for the scare
<thom> Treenaks: np
<thom> i really am getting food now
<thom> Cym: hrm, i'll look once i stop starving to death
<Cym> I spent some time back trying to explain it to Matthew but he could never duplicate it.. so i suppose the first thing is to reproduce it.  Although, I can reproduce this bug with both apache1.3 and apache2
<Treenaks> thom: indeed, it's gone now :)
<mjg59> Loevborg: Oh, right, cool
<mjg59> Loevborg: The trace is very odd, so I'm not sure whether the patch I'm suggesting will have any effect
<Cym> thanks thom
<Loevborg> mjg59, we'll see.
<tseng> jdub: 
<tseng> dpkg: error processing /var/cache/apt/archives/ubuntu-artwork_0.2.18-1_all.deb (--unpack):
<tseng>  trying to overwrite `/usr/share/gnome-background-properties', which is also in package gnome-backgrounds
<tseng> which one of you wants the bug
<jdub> ah crap
<jdub> me
<Kamion> yay, completed a kickstart install apart from the fact that the desktop doesn't install
<Kamion> and keyboard preseeding was fucked, fixing
<rburton> jdub: would you like me to knock up a new g-a-i package tonight or are you planning on dropping a pile of changes on me tomorrow?
* dholbach congratulates Kamion 
<zul> jdub: if you are feeling daring http://zulinux.homelinux.net/ubuntu/kernel (inotify)
<jdub> rburton: wait until tomorrow, you'll have data bugs then
<Kamion> anything I should be waiting for before I fire off the cron.daily that will hopefully construct Array CD 6?
<thom> Kamion: #6902, do you feel strongly about adding !fqdn to the sudoers we write on install?
<tseng> zul: lets try .20 before we push anything?
<tseng> zul: see if it solves more bugs
<zul> tseng: yep no problem..
<thom> Kamion: not 6902, 2772
<tseng> cool
<thom> Kamion: with a suitable warning comment it doesn't break the default and ensures sudo still works in the face of no dns
<lamont_r> mdz: just to make sure we're on the same page: the first livecd download for amd64 (and ia64) after the preview will be a fullimage (not rsync friendly) based on how much smaller that gets, we can decide on whether or not to do it again for the actual release...
<lamont_r> thoughts?
<Kamion> thom: yes, fine by me, shadow writes the default file nowadays
<thom> shadow does? righto
<_d4vid> hi all
<Kamion> sabdfl: the current daily doesn't install the second stage successfully, but I'd appreciate feedback on whether or not it really fixes (a) the rf kill switch detection bug, (b) the SATA/PATA CD-ROM issue
<Kamion> actually, if everyone who can could give the current daily a go to make sure it detects all their hardware (you don't have to go past partitioning, so you don't need a scratch partition to install in or anything), I'd greatly appreciate it
<mdz> lamont_r: I was musing on this today; it would be nice for folks to be able to sync from the preview forward
<mdz> lamont_r: so maybe we should flush for the preview
<lamont_r> your call
<lamont_r> it's litterally just an rm on two hosts in the data center. :-)
<lamont_r> (if the previous image is there, then we use it, you see...)
<mdz> Kamion: whoa, what's up with the ordering change in d-i startup?
<Kamion> mdz: the what?
<mdz> Kamion: I saw what looked like cdrom-detect before localechooser
<Kamion> did you boot with ks=anything?
<mdz> nope
<mdz> live
<Kamion> fuck, I screwed up kickseed then
<lamont_r> Kamion: OK to change the name of the livecd rootfs image?
<mdz> live CD seems to work fine
<Kamion> will fix
<mdz> just looks weird, in this case
<lamont_r> adding {ubuntu,kubuntu} in there somewhere
<Kamion> mdz: you're seeing the cleverness that kickseed does to get certain kinds of things done early; it's just being a little overenthusiastic :)
<Kamion> damnit, I'll need a new d-i byhand
<Kamion> thom: you up for that?
<thom> Kamion: i can see shadow adding the admin group to sudoers, but i can't see where the default sudoers is created
<thom> Kamion: timescale? (yes, but i now really need foor)
<mdz> isn't the default sudoers created by sudo?
<Kamion> thom: ... oh, actually it must just use the default file created by the sudo package, sorry
<Kamion> thom: about +1.5 hours
<thom> Kamion: ok, cool
<Treenaks> did gaim/gnutls switch to a new entropy source?
* thom beats kamion gently
<thom> mdz: it didn't used to be; guess it is now
<Kamion> yes, that was one of the things that (intentionally) changed when we switched to the default admin group thing
<thom> okie
* Kamion confirms that his kickseed fix works
<ogra> WOW....
<ogra> since when has ping the -a option
<zul> ogra: cool...now i can annoy people at work :)
<tseng> that must be an "accessibility" feature
<ogra> but you never have to look at your display to know your server is running g*
<thom> ogra: port it to alsa!
<ogra> thom: ok, hoary+1
<thom> aping would be l337
<thom> and get a recording of jdub shouting "bong" for the sample
<ogra> hehe
<Treenaks> we need that for traceroute as well!
<zul> Kamion: im just catching up did -25 go on today's cd?
<Kamion> zul: yes
<Kamion> on 20050302.1
<zul> ok thanks
<thully> so - what's the status of array 6 - is there any blockers?
<Kamion> I knew you were going to ask that
<Kamion> yes, I'm just releasing kickseed 0.13 to fix one blocked
<Kamion> blocker
<Kamion> and then I am working on it solidly and won't go to sleep until it's out, so please don't repeatedly ask about it
<thully> OK - I just was curious - I didn't think I had asked that many times - just once yesterday and once the day before
<Kamion> yes, but you always ask while I'm in the middle of preparing a release, before it's even late
<Kamion> and it does have a certain "are we nearly there yet" feel about it :)
<tseng>  /topic ARE WE THERE YET?
<Kamion> please feel free to ask if the release is late, but before then it's best to assume that we (particularly I) are working on it fairly solidly
<thully> OK - sorry I asked at all the wrong times...
<Kamion> mdz gets to ask me, but he's my boss ;)
<mdz> thully: when it is released, it will be announced on the mailing lists and on IRC as usual
<Kamion> (and sabdfl, fairly obviously ...)
<mdz> so in general, all you need to do is wait
<Kamion> we're down to pretty solid release times for Array milestones now, unlike the early days of Hoary where I do concede that they were frequently much delayed
<Kamion> but as the final release approaches we have a much better chance of being able to get them out on time
<thully> OK - sorry for barging in..
<Kamion> np :)
<Kamion> T-Bone: http://lists.ubuntu.com/archives/ubuntu-users/2005-March/024574.html <-- told you so ;-)
<thully> I'm just anxious for a new array release to test some things that may be specific to new installs... i could grab a daily, but I'm on a semi-slow connection and I've had problems getting dailies installed in the past
<T-Bone> Kamion: blame it on jbailey ;)
<Kamion> rightly so, the current daily's second stage breaks
<Kamion> jbailey: ^-
<Kamion> jbailey: (the same complaint was raised in Debian when they turned the hard disk LED on for powerpc, and it was quickly turned off again)
* T-Bone has no clue what it does
* T-Bone doesn't have a laptop
<jbailey> Kamion: Ah weird.  I had a guy here complaining that it went away when it used to do it.
<thully> I wonder, is there a chance that comeone else could test a Hoary install without any networking before release - I do all my installs without networking installed and this tends to present some unique issues for me
<jbailey> Kamion: Apparently otherwise there's no hdd light at all on those beasts.
<Kamion> I'll try to do so
<Kamion> jbailey: yes, but I have such a beast; the hdd light is pretty annoying :)
<Kamion> if we turn it on it would be nice to expose a sysctl to turn it off again
<thully> no networking - meaning I don't use ethernet and intermittently use wi-fi, and use a modem-like device for all my net traffic
<jbailey> I'll lart James Morrison on behalf of all of you, then. =)
<Kamion> I have some difficulty constructing a machine with no network devices at all, but I may be able to do so; I can certainly disconnect wireless
<Kamion> but I cannot promise changes before array 6 now, only before the preview
<sivang> Good night all
<thully> OK - I install w/no ethernet or wi-fi installed, and I can get through the install, but I've had a few quirks...
<Kamion> since the network configurator's in the d-i initrd which has an extra build delay and a human interaction component at the archive end
* Kamion sighs and works around the kickseed bug again
<thully> like a network icon in the system tray for the loopback interface, and a network configurator in d-i that isn't exactly friendly to a non-networked setup
* Kamion tests with the wireless card pulled out
<Kamion> wait for DHCP -> DHCP error -> "Do not configure the network at this time" -> select hostname
<Kamion> which is probably fair enough for a device with disconnected ethernet
<Kamion> let's try removing the ethernet kernel module
<thully> I'm mostly talking with no ethernet or wireless networks available - on my laptop I have an ethernet and wireless card, but often install with neither ethernet or wireless available
<Kamion> yes I know
<thully> the cards are available, but not the networks
<Kamion> if the card's plugged in then you get the sequence I just described
<thully> It may be a good idea at some point (not array 6 and maybe not even the preview) to clean up the d-i network configuration to be easier for non-network users
<Kamion> I don't honestly think the sequence I described is that bad
<thully> For example, if I pick wireless on that screen (since I want wi-fi to be configured for later use) i'm stuck in an infinite loop
<Kamion> that certainly sounds like a bug, will see if I can reproduce
<thully> and the only way to get out is backing out to the installer menu and manually skipping steps, which doesn't configure the loopback interface (already reported as a bug)
<Kamion> I thought I fixed that one recently though
<Kamion> the wireless loop
<thully> Well, my experience is if you pick wireless, it will scan for networks, and prompt you for essid if it doesn't find one.  If you don't specify an essid, it will repeat the process.  Hence, there is no way to configure the wi-fi for later use
<Kamion> yes that's the bug I thought I'd fixed
<Kamion> no network interfaces at all -> red screen telling me that -> hit Continue -> select hostname -> install continues
<thully> what is the new behavior at this stage of an install-to-HD (not a live CD, that works differently)
<thully> if you pick wireless w/no WAPs available
<Kamion> one moment, I have to engineer such a setup, which will doubtless annoy my housemates
<Loevborg> different problem here, when i installed I didn't get an opportunity to _not_ configure my networking.
<Kamion> Loevborg: good
<Kamion> that's a feature, not a bug :)
<Loevborg> Kamion, but with wireless, it keeps asking me questions about it.
<thully> Also, it may be a good idea to add a "No network" option to the menu which gives you a choice of network cards to configure
<Kamion> Loevborg: see what I just said to thully!
<Loevborg> Kamion, sure.
<Loevborg> still, being able to skip the dhcp run would be an improvement imho.
<Kamion> Loevborg: doubt that'll happen, sorry
<Loevborg> I'm sure this has been discusses a lot though :)
<Kamion> thully: there are already several options on the netcfg "stuff went wrong" menu, one of which I'm sure did that
<Kamion> Loevborg: yes, we have a hard requirement not to add more questions to the install
<Kamion> so "try DHCP, if it fails then go away" is about the best we can do given that many network cards don't support ethtool/MII properly or lie in the results
<thully> well, I'm just saying - if a dial-up user (yes, they still exist) wants to install Ubuntu, it should be easy to just pick "No network" right when they're prompted to configure network cards and skip over the whole process (just list it in addition to the available network cards)
<Loevborg> but when it asks me which interface to configure, it could just aswell admit "none" as a third option.
<Kamion> Loevborg: that's only useful if you have >1 interface though, with 1 interface we want it to just try
<Kamion> thully: hm, ok, that wireless loop bug is still there, evidently I only fixed the live CD case
<Kamion> sorry about that, I thought I'd got both
<Loevborg> Kamion, and when it asks me for an ESSID, there could also be an option to skip it. but don't think I'm complaining, only suggesting.
<Kamion> Loevborg: see the last two lines. :-)
<Loevborg> "proposing"
<Kamion> I'm having two independent conversations about the exact same thing with two people here, it's very confusing
<Loevborg> to add some spice, /etc/init.d/networking sometimes takes ages to configure wireless, and then - sometimes - when I ctrl-c it, Xorg doesn't start (no loopback device).
<Loevborg> but I see that this is not #ubuntu-bugs :)
<thully> So, should I report any new bugs on bugzilla about this?
<Kamion> thully: sure, it's much better that than to report them *just* before a release which is the exact time when I have no hope of fixing them before the next milestone release :)
<Kamion> stuff in bugzilla about d-i will be assigned to me (either automatically or, probably, manually)
<Kamion> and I will try to do what I can about no-network configuration
<sabdfl> Kamion: should the new cdrom/sata stuff mean that it should work on a normal installed desktop too?
<Kamion> sabdfl: given unified hardware detection, I'd hope so, but I'm not certain
<sabdfl> Kamion: doesn't seem to be
<Kamion> sabdfl: jbailey would probably be the best one to debug with ...
<Kamion> thully: oh, I think I see why the repeated wireless ESSID question bug happens
<Kamion> fixing it properly is a string change, though, hmm
<abelli> sivang: ping
<jbailey> sabdfl: Did the fix not do it for you?
<Loevborg> much appreciated. btw always implicitly read "kudos for your excellent work".
<sabdfl> jbailey: am on 2.6.10-25, and no, i don't see the cdrom
<sabdfl> not as /dev/hd* anyhow
<jbailey> sabdfl: Do you have /dev/sr0 ?
<thully> Bug #7098 is now in the database, with info on the wi-fi/ESSID issue
<sabdfl> jbailey: yes
<jbailey> sabdfl: It's showing up as a SCSI cdrom then.  I see that on my SATA system, too.
<sabdfl> hm...
<sabdfl> so that should work?
<mdz> should be /dev/scd*
<Kamion> thully: right, replied
<jbailey> sabdfl: It seems like the unified drivers just do the whole thing as SCSI now, even the PATA drives.
<sabdfl> ok
<jbailey> mdz: I had /dev/scd0 too.
<sabdfl> i see /dev/scd0 too
<mdz> well yay
<jbailey> sabdfl: If you could test that it actually reads, that would be lovely.  My SATA system is in a data centre, 3 times zones from here. 
<thully> Kamion: should I file a lower-priority bug requesting a "None" option on the screen prompting for a network card to configure?
<Kamion> thully: sure
<Kamion> thully: I doubt it will happen for systems with one interface, but it could happen for systems with more than one
<thully> well, systems w/one interface will automatically try that and prompt if it can't find a network to connect to, so it isn't necessary
<Kamion> the same argument applies to systems with one interface
<Kamion> it's just that changing it for systems with one interface would involve an extra question that previously wasn't asked
<Kamion> jbailey: all-IDE systems are still /dev/hdc or whatever, at least
<jbailey> Kamion: Yes.  It's only where the sata driver is providing the pata interface too.
<thully> OK - this "none" option issue is bug #7101
<thully> Also, you were saying a red screen appeared when there is no network - shouldn't this just be a normal screen, since systems with no network isn't necessarily an error...
<Kamion> perhaps, yes
<Kamion> go ahead and file about that too, component netcfg
<thully> One last issue with non-networked setups - After install, there is always a network status icon for loopback in the system tray - any way this can be taken care of?
<thom> thully: that'll go away in hoary+1
<Kamion> didn't you say that was because you went back rather than continuing?
<Kamion> due to the loop
<zul> jbailey, whats up with the sata stuff?
<jbailey> zul: Nothing, works exactly as predicted.
<zul> sweet
<Kamion> hm, I should make my ubuntu-build-di script connect to the buildds in parallel rather than serially
<Loevborg> mjg59, I just tried your ad-hoc patch, it doesn't change a thing AFAICT.
<mdz> Kamion: what would be involved in arranging for English to be supported in addition to the language selected in the installer, per default (as far as language-{pack,support}-en)?
<Kamion> mdz: trivial change to base-config/lib/menu/pkgsel
<mdz> Kamion: blitted you my script for same
<Kamion> (to always add en to get_language_packs output
<Kamion> )
<mdz> Kamion: can you remember to do that after array 6 (or before, if you prefer), or should I file a bug?
<Kamion> mdz: probably best to file a bug on base-config for me, but I'll try to do it tomorrow
<mdz> done
<seb128> jdub: naten doing some rocking work on smb://, he has just fixed smb to browser and use winXP shares correctly (anonymous without asking for a password and privates working great)
<thully> as far as the network interface icons, I'd just say revert this to the Warty behavior (don't have status icons by default except for wi-fi signal) but that's just my opinion
<Kamion> "revert to Warty" is usually a much harder thing to do than it sounds
<Kamion> many other things will have changed in the same component
<jdub> seb128: yeah, that's way cool
<jbailey> seb128: krb support yet? =)
* jbailey hides.
<seb128> jdub: nautilus working fine on a winXP network is nice :)
<seb128> jbailey: that's supposed to work for a while, alex has worked on this for redhat
<seb128> jbailey: no ?
<seb128> hum, perhaps some patches are needed for that
<jbailey> seb128: Ah, okay.  It always prompted me for a password while I was still at FundSERV.  
<jbailey> seb128: I didn't know it was in yet.  It could've been anything including heimdal/mit mismatch.
<Kamion> mdz: oh, to be able to override it with preseeding I guess I want to change it in localechooser instead
<Kamion> anyway, I'll look at it
<seb128> jbailey: http://mail.gnome.org/archives/nautilus-list/2004-July/msg00154.html
* thom gets firefox into an infinite "what app should i open this with" loop
<thom> that's awesome
<thom> my screen is now full of firefox windows
<herve> hi
<herve> in a setup.py install script of a Python package
<herve> does any distutils guru can confirm me the "data_files" argument in setup() lists the location of source files and not destination files?
<thom> *sigh* at xscreensaver "censorship"
<sabdfl> suck it in
<sabdfl> ;-)
<thom> sabdfl: this is all your fault ;-)
<thom> seb128:  8318 thom      15   0  152m  22m  12m S 98.2  2.3   9:25.06 nautilus
<thom> wth?
<sabdfl> thom: punishment from the sacred cows
<thom> the cows should love me; i stopped them bouncing
<thom> maybe the campaign for freely bouncing cows is DoSing me
<mpt_newjersey> "We are free-bouncing bovines. We bounce free ... today."
<zul> ack...we already discussed cows in #-kernel
<thully_> hi - has there been any progress on getting icons to appear on the desktop for CD-ROMs, USB keys, etc etc?  This stop working for me some time back in hoary
<seb128> thom: bah
<seb128> thom: 16596 seb128    16   0 17068  14m 1776 S 22.5  1.4  33:52.68 polypaudio
<seb128> in the same style :p
<thom> seb128: i'm taking no blame for polypaudio :-)
<seb128> 15925 seb128    15   0 43908  23m  11m S  0.0  2.3   0:01.91 nautilus
<seb128> for nautilus here
<thom> yeah, it just screamed up when i deleted an svg file
<thom> s/deleted/dragged to wastebasket/
<Kamion> thom: there should be four d-i byhands on jackass; could you process them, or shout if there aren't amd64/i386/ia64/powerpc all there?
<seb128> what version are you running ? for how long ? do you have a way to get eating like that ?
<Kamion> with recent timestamps
<seb128> thom: oh, interesting, is that reproducible ?
<thom> seb128: current; dunno; will try
<thom> Kamion: k
<Kamion> instead of bouncing cow, I propose that we play "Cows With Guns" at login time
<thom> ok; elmo's "only try if super necessary" comment doesn't fill me with joy, but lets see
<Kamion> in pursuit of bovine liberation
<thom> Kamion: gotta be better than those damn bongoes
<herve> Kamion, what about pacifists cows? ;-)
<Kamion> "we will fight for bovine freedom and hold our large heads high; we will run free with the buffalo or die ... cows with guns"
<Kamion> http://www.danalyons.com/lyrics/lyrics_for_public/cows_with_guns_lyrics.html
<aboe> can somebody help me with my linux partitioning
<aboe> want to merge to partitions
<thom> Kamion: should be done
<Kamion> thom: awesome, thanks
<lamont_r> Kamion: user trying to install got an error about not finding a kernel on his x86 box...  with a recent daily, i believe
<Kamion> lamont_r: would need to see logs
<Kamion> /var/log/*
<Mithrandir> Kamion: in PC World Norway Express (which is a biweekly thingy), our installer is described as "quick and boring".  I think that's a good thing. :)
<lamont_r> ah, I have proc/cpuinfo - will get the rest for you
<Kamion> Mithrandir: excellent. :)
<mdz> Kamion: let me know when I should test a new set of images
<Kamion> lamont_r: could just be a bad burn
<Kamion> mdz: waiting for next cron.daily to kick them off
<HcE> Mithrandir: why should an installer be "fun" ?
<Mithrandir> they complain about that they couldn't find any graphical way to download updates, so probably haven't found synaptic.
<HcE> maybe implement tetris support ;)
<Mithrandir> HcE: as I said, I think it's a good thing that it's boring.  Not interesting or anything. :)
<mdz> Kamion: are we finished with package uploads for array 6 (assuming no new problems are discovered)?  do we need to build a new cloop image to get in sync?
<HcE> plain, straith forware is excellent
<lamont_r> Kamion: requested, we'll see how quick a turn around we get...
<HcE> allways liked the debian/ubuntu approach
<HcE> s/forware/forward/
<Mithrandir> HcE: written by Mohammed, former barbara.no guy.
<HcE> Mithrandir: heh, I have shown him both apt-get, aptitude and synaptics...
<Mithrandir> synaptic. :)
<Mithrandir> not synaptics.
<HcE> ;P
<HcE> I don't use that tool
<Mithrandir> me neither.
<mvo> tsss
<seb128> lamont_r: howl/build sorted ?
<thom> synaptics is something utterly different :-)
<Mithrandir> mvo: I like text-based tools.  X is a nice tool for multiplexing terminal windows. ;)
<Kamion> lamont_r: requested of whom?
<Kamion> mdz: yeah, I think so; please do
<mvo> Mithrandir: yeah, I know :)
<mdz> ok
<Kamion> Mithrandir: or the update manager
<jbailey> Kamion: So that I know, what's the matching rootskel update that was needed to go along with #1440, the SATA fix?
<HcE> hehe, you got credits in the article Mithrandir :DD
<HcE> -D
<Kamion> jbailey: src/lib/debian-installer-startup.d/S03hotplug runs init scripts
<Kamion> rc scripts, rather
<Kamion> hmm, I suppose I should update ddetect as well ...
<Kamion> I'll do that after array 6
<mdz> Kamion: are there good reasons why it can't use init.d/hotplug?
<Kamion> mdz: I do not particularly want to delegate critical parts of d-i startup to other packages, particularly not when merging this back to Debian
<Kamion> using init scripts from the real system has been a good way to break things in the past
<Mithrandir> Kamion: was the update manager in warty?
<mdz> due to busybox?
<Kamion> and the change I made is much simpler
<mdz> Mithrandir: no
<Mithrandir> HcE: I know :)
<Kamion> mdz: due to crap like LSB init scripts :(
<Kamion> but busybox also
<Kamion> I really think it's much clearer what's going on the way it is
<jbailey> Kamion: What's the best way for me to make sure that anything I fiddle with in hotplug gets into d-i?  I've got mdz's sg patch done here and tested, so it's ready to go in.
<HcE> Mithrandir: all my support over MSN are not mentioned :P
<Kamion> jbailey: d-i uses everything else in hotplug as normal, it's just rc script ordering
<mdz> a <1k /lib/lsb/init-functions would solve that problem once and for all, but I'll take your word that overall it's not the right thing
<Kamion> mdz: I do have such an init-functions, it's an ugly hack IMHO and I wish it could go away
<jbailey> Kamion: 'k
<Kamion> I've been meaning to fix pcmcia-cs for a while ...
<mdz> jbailey: you're not planning to upload it until after array 6, though, right?
* jbailey hands a large flamethrower to kamion to help with the pcmcia-cs fixing.
<mdz> is there anyone who is working on moving pcmcia to hotplug so that pcmcia-cs can go away?
<jbailey> mdz: I was planning on checking with you in a moment now that it's ready to make sure I wouldn't run over array 6 in any way.
<Kamion> jbailey: BTW, have a look at the way I did the init script ordering in rootskel; I think it's much simpler and I'm not sure how the very complex version in hotplug is better?
<mdz> seb128: gah, I thought you were finished
<Mithrandir> HcE: *chuckle* :)
<mdz> we need to stop uploading at some point here so that we can build consistent CD images
<seb128> mdz: the gnome-vfs2 upload interfers with the array 6 build ?
<mdz> seb128: it goes on the CDs, yes
<mdz> our goal is to have the same versions on the live CD and the install CD
<mvo> hi doko 
<seb128> mdz: sorry for that, just pushing a samba fix for nautilus, trying to get smb:// working fine for 2.10
<jbailey> Kamion: What's the best way to pull the source for rootskel?  I usually use my Debian d-i checkouts for looking at that code.
<jdub> mdz: do we have any download stats?
<Kamion> jbailey: no revision control yet, just 'apt-get source rootskel' with Ubuntu deb-src lines, sorry
<mdz> jdub: for what?
<jdub> mdz: warty
<mdz> jdub: yes
<thom> Kamion: is it too early to ask whether i cocked up those by hands? (/me is panicing about them somewhat)
<jdub> do i have to go through elmo?
<Kamion> lamont_r: "requested of whom" -> oh, sorry, I got confused by interleaving conversations
<mdz> jdub: depending on what you want, yes
<Kamion> thom: can't quite tell yet :( I assume you unpacked them into dists/hoary/main/daily-installer-*/ and updated the current symlinks?
<doko> mvo: hi, still awake?
<jdub> mdz: hrm, just want some user-understandable figure
<thom> Kamion: yeah
<Kamion> thom: if you can push a cron.daily then I can check, but never mind if you can't
<mdz> jdub: if you want "how many warty CDs did people download from us", we don't have that
<jdub> what do we have?
<mvo> doko: barely :)
<mdz> access logs starting at some point after the release, I think.  ftp logs starting at an unknown time.  no bittorrent records since the last restart
<mdz> /var/log/shrug
<jdub> heh
<jdub> nothing digestable to hand?
<zul> mdz: davej wrote a document for suggestions for troubleshoting hardware http://people.redhat.com/davej/hardware-problems.txt when you got a sec can you have a look before i add it to the wiki
<jbailey> Kamion: My version evolved out of me starting with tsort and slowly eliminating tools that I realised I didn't have until I was basically in shell.
<jbailey> Kamion: This is far simpler. =)
<mdz> Kamion: I guess I'm willing to let go of the ideal of having consistent live vs. install in the name of not waiting another hour; let's just use the cloop build which is in progress
<mdz> next time, we'll harness elmo and lock down uploads
#ubuntu-devel 2006-03-06
<elmo> what is galeon doing when I click on a link? it's certainly not opening it anymore.  was it broken by the firefox change?
<Burgwork> elmo, likely the same was as epiphany
<Kamion> mjg59: are you sure about a separate CD image? I think it should just be an ISO9660/HFS+ hybrid like we do for powerpc
<Kamion> anyway, bedtime
<mjg59> Kamion: If that's practical for the dapper timeframe, sure
<jvw> sabdfl: Just curious, is every DPL also an Ubuntu Project Leader? ;-)
<ogra> haha
<tseng> jvw: indirectly depending on your perspective
<LaserJock> maybe we should have a DPL LP team ;-)
<Burgwork> jvw, in so much as decisions that affect Debian affect Ubuntu, yes
<Seveas> Burgwork, regarding the keycodes: if you map the flag to a command you can no longer map flag+$key to anything and vice versa...
<Burgwork> Seveas, ugh
<dholbach> good night guys
<Burgwork> Seveas, I consider that a bug
<Seveas> me too
* sivang notices the shift sticky keys pop ups hoola
<sivang> (pressed it accidently more then 8 seconds)
<Burgwork> sabdfl, where the shuttleworth foundation at with releasing the specs to the freedom toaster?
<sabdfl> Burgwork: i believe it's all public
<sabdfl> check with jason@shuttleworthfoundation.org
<Burgwork> sabdfl, ok, cheers
<Pygi> anyone know when will multiple mount points  be fixed? I mean, it only requires a little patch, nothing else :)
<Burgwork> Pygi, have you filed a bug with the patch?
<Pygi> Burgwork: Not really :-/ But that is known bug I think...
<Burgwork> Pygi, if it isn't, please file. This is a channel for discussing your patch to the bug, not the bug itself
<Pygi> ok, ok, sorry :)
<Burgwork> Pygi, np
<sabdfl> night freedom lovers
<tseng> g'night mark
<ajmitch_> night
<sistpoty> gn8 sabdfl
<sivang> night sabdfl !
<Mez> mdz: ping
<mdz> yes?
<infinity> mdz: Can I get a UVF exception to sync mod_perl2?  It's a bugfix release, has been cooking in sid for a month with no new bugs, and looks safe to me.
<Mez> ah sorry mdz: didnt see you reply there.
<Mez> mdz: wanted to talk about now the new structure stuff is in place whether we can get access (or i can) get access to upload to the backports pocket
<Mez> so we can backport stuff like scim
<Mez> I've spoken to mark breifly about it (asking whether it was a CC or TB thing) and he said that all it really needed was to convince you that backports people (aka me) were sane and sensible
<infinity> Mez: So, are you? :)
<mdz> Mez: what's the issue with scim?
<Mez> mdz: the control hack doesnt work
<mdz> why not?
<Mez> it just wont register the changes to the control file and still builds the dapper packages
<Mez> I mean - it'd only be on rare occasions that things were uploaded manually ... but it'd be useful to have it there
<Mez> infinity, depends on who you ask (the sane bit anyway)
<infinity> Mez: Surely, if the control hack isn't working, it was implemented incorrectly...
<infinity> Mez: Do you have a source package somewhere I can look at for you?
<Mez> infinity lemme just go and check if I deleted it or not
<infinity> (Of course, I'm still morally opposed to swapping control files mid-build, but I doubt my opposition counts for much these days, when we have a bunch of packages doing it)
<Mez> infinity - gimme one sec and I'll upload to revu
<Mez> infinity, as am i - which is why I'd prefer a manual upload for it
<infinity> Mez: Good work on dealing with Eugene as an upstream, BTW.  He's not always the easiest man to work with.
<Mez> infinity: really? he seems to like me :D
<Mez> he's even provided me with a free Rar licence :D
<tenmon> how much difficult is to get a package on official repos ?
<infinity> Mez: Lovely.  Time to use that newfound influence to ask him if we can build rar on multiple architectures for him. ;)
<Mez> infinity, lol - he seems to be quite responsive and stuff - what problems have we had working with him before?
<sistpoty> Mez: btw. can you add a comment stating that it's for backports after you've uploaded to revu? thx.
<Mez> sistpoty, no probs
<sistpoty> thx
<Mez> I'll archive it straight away :D
<infinity> Mez: Oh, just general problems with arrogance and stubbornness.  In other words: He's a programmer.
<sistpoty> Mez: even better ;)
<ajmitch_> infinity: sounds like many people I know
<sistpoty> tenmon: depends on the packaging... for dapper we're in feature-freeze right now, meaning that we can accept new packages only for dapper+1
<Mez> infinity, I've not really come across that - I guess users he might be weird with - but I think he believes I know what I'm doing :D
<Mez> though making it build on multi-arches ... I dunno...
<tenmon> sistpoty: I should submit to debian first then?
<Mez> I dont think he'll release the source code
<Arrogance> infinity, and thank you for noticing
<Arrogance> although I don't know stubbornness
<infinity> Mez: He might release it under and NDA (so we still can only distribute binaries, but we could BIULD for all arches and provide those binaries to him)
<infinity> Mez: If you asked really, really nicely. :P
<sistpoty> tenmon: that's always an option... that way the package will get autosynced for dapper+1
<tenmon> sistpoty: ok, thanks
<Mez> infinity, cool - would you be willing to provide the hardware to build on ?
<infinity> Mez: s/and NDA/an NDA/
<infinity> Mez: It could be worked out, if he was into the idea.
<Mez> infinity: I'll chat with him and see what he thinks
<Mez> sistpoty: ping
<sistpoty> Mez: pong
<infinity> Mez: Although, you could already cleverly package his binaries for amd64 (and have the package depend on libc6-i386), if you wanted to cover two arches...
<Mez> sistpoty, where on tiber is the FTP incoming dir - I need something deleted them
<Mez> infinity, lol
<sistpoty> Mez: /home/ftp/incoming... I'll take a look
<sistpoty> Mez: what package?
<Mez> scim
<sistpoty> Mez: deleted
<Mez> cheers
<Mez> infinity - I'll CC: you
<Mez> still adconrad@0c3.net
<infinity> Mez: Yup.
<Mez> infinity, sent :D
<Mez> It's worth a try
<Mez> mdz: but what do you think about the possibility of it?
<ogra> argl argl argl 
<Mez> oy oy oy ?
<Mez> hola ogra
<ogra> xine-ui actually includes the complete xscreensaver-command source to send a fake event all 30 seconds ... 
<Mez> lol
<ogra> *sigh*
<Mez> infinity, http://revu.tauware.de/details.py?upid=2081
<ajmitch_> ogra: that is quite an impressive waste of code
<ogra> ajmitch_, yup
<ogra> you can write a fake event function for X in about 30 lines ... (including declarations and comments)
<ogra> xscreensaver-command is 650 lines .... and not much of it will be used ...
<mjg59> Programs that directly interface with xscreensaver deserve to lose
<elmo> argh, are you kidding me
<elmo> we don't migrate preferences from xscreensaver to gnome-screensaver?
<ogra> elmo, working on it 
<ogra> currently i'm hitting all the media players to recpect g-s-s ...
<elmo> ogra: ah, ok, great
<elmo> ogra: actually, I mean user preferences
<ogra> its very intresting, verey player has its own solution ...
<mdz> Mez: I don't like the idea of backports being a branch
<mdz> Mez: the problem with scim just sounds like a bug
<ogra> elmo, https://launchpad.net/malone/bugs/31511
<Ubugtu> malone bug 31511 in gnome-screensaver "Settings lost during an upgrade" [Normal,Unconfirmed]  
<Mez> mdz: surely it already is ?
<elmo> ogra: ok, cool
<mdz> Mez: it isn't; it's a build system
<infinity> Mez: Well, right now it's a binary branch, but not a source branch, which makes it more manageable (generally)
<elmo> ogra: also gnome-screensaver's config doesn't seem to list some hacks, have I got some reduced subset installed?
<elmo> lost
<Mez> ah: ok...
<Mez> but mdz: surely you can see my POV to get rid of dirty hacks like this ?
<ogra> elmo, do you have xscreensaver-data-extra and xscreensaver-gl-extra installed ? 
<Mez> and also means we might be able to backport more things
<mdz> Mez: why do you even need a control file hack with scim? it looks like it should build unmodified on breezy
<Mez> mdz: it'll build - yes
<Mez> but - thngs depend on libscim8 in breezy
<Mez> and libscim8c2a in dapper
<elmo> ogra: no.  meh.
<ogra> elmo, xscreensaver-data and -gl only contain the selection we enabled by default since warty ... the rest went into the -extra packages
<ogra> so we save 5MB on the Cd :)
<mdz> ah, right
<Mez> and well - we dont wanna go and backport the 20 packages that depend on it :D
<Mez> s/20/18
<mdz> Mez: that's a problem specific to breezy, which will disappear with Dapper and hopefully not happen for a long time after, but I see your point
<Mez> (which includes libstdc++6)
<mdz> Mez: still, it seems better to keep all of the code in one place; when it's updated in dapper, you don't need to do a merge
<mdz> it's less error-prone once it's working
* infinity looks at this upload right now to see why it's not working.
<Mez> mdz: true - but well - theres stuff thats been backported thats now a newer version in dapper...
<Mez> lol - and thats stayed the same without a merge :D
<mdz> Mez: what do you mean?
<Mez> mdz: for example
<mdz> either you modify the source relative to dapper, or you don't
<mdz> if you modify it, you need to do a merge when it's updated
<Mez> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=k3b
<infinity> I think his point is that updates in dapper aren't automatically backported, which I assume is a feature, not a bug.
<Mez> in bacports it 0.12.7
<Mez> infinity - yes that was my point
<mdz> ok, then you're misunderstanding what I'm saying
<Mez> mdz: asI said - this is only going to be for a couple of one off things like scim
<mdz> a merge is where you need to reconcile two branches of code
<infinity> Mez: Feh.  You didn't do this upload relative to the current source in dapper. :)
<mdz> whereas what we have today is copying the source (not even) from one place to another
<Mez> infinity - has it been updated in dapper?
<Mez> grr
<Mez> mdz: I agree...
<Mez> but as I said - for the most part, other than the odd occasion - it'll stay the same...
<mdz> there were quality problems with the old backports where they diverged
<Mez> mdz: I know :D
<Mez> lol
<Mez> however: none of them were caused by me
* infinity watches ia64 slowly catch up...
<Mez> infinity: I'll grab the latest copy of scim and make the chanegs - didnt realise it had been changed in dapper recently
<Mez> infiity: wait - wtf you on about - it is relative to the current source in dapper
<infinity> Mez: Current scim in dapper is -1ubuntu1... Which is also what you gave me.
<Mez> infinity, yeah ...
<Mez> er. ..
<Mez> but mine has changes
<Mez> oh
<Mez> I see what you mean :D
<Mez> lol
<Mez> I didnt realise there'd been a scim hack for ubuntu 
<infinity> Mez: Also, you don't need to build-depend on "base-files"... It's an essential package.
<infinity> (A system would be pretty broken without it)
<mdz> Mez: how about this: I'm happy for ubuntu-core-dev to be able to upload to -backports, so if the changes are reviewed and uploaded by a core dev, the source can diverge
<Mez> mdz: that sounds cool to me
<infinity> mdz: That would work for me.
<mdz> done
<Mez> and gives me a reason to go for my core-dev :D
<Mez> (which I've been holding off as I dont need it atm)
<infinity> mdz: It would also mean that for those of us who handle backportability in our own packages (thinking of me and pitti here, at least), we can remove some dirty hacks and do direct backports uploads.
<mdz> infinity: yep
<Mez> mdz: sounds good to me if you're willing for it - just lemme know what needs to be done on my side - if anything
<mdz> Mez: I'll take it from here
<infinity> (Although, there's a certin point of perverse pride in knowing that everything I maintain can build, in some hackish way or other, on sarge, etch, hoary, breezy, and dapper)
<Mez> mdz: cool - expect a core-dev application from me within the next few months then
<mdz> Mez: expect some hard questions from the board ;-)
<ajmitch_> Mez: you think you're ready for it?
* infinity might want so show up for that once, since he's been sponsoring Mez in Debian.
<Mez> ajmitch_, hence why I said in the next few months
<infinity> s/once/one/
<LaserJock> hmm, so would LP be good for any distro to use?
<infinity> LaserJock: Not yet, but that's certainly the plan.
<Mez> ajmitch: I dont really need it to be honest - I've had no problem getting stuff sponsored anyways
<infinity> LaserJock: For now, it's getting to the point where any Debian/Ubuntu derivative could use it end-to-end, but we don't have (for instance) buildd support for RPM-based systems.
<LaserJock> infinity: I'm talking with some Fink devs right now.
<infinity> Ahh, fink is dpkg-based, yes?
<LaserJock> yes
<LaserJock> I just wonder if there is anything that LP could offer them
<infinity> Then, in theory, LP could be made to support fink reasonably easily, with a bit of hacking and some prayer.
<infinity> LaserJock: You'd really need to talk to the LP team (and include Mark) to get an idea of A) how much work it would be, and B) how much priority/manpower we could throw at the problem.
<infinity> LaserJock: So, #launchpad would be a good start.
<LaserJock> infinity: yeah, thanks
<Mez> infinity - I'll er - do a merge :D
<infinity> Mez: Thanks.
* infinity grabs some lunch.
<Mez> infinity, though the B-D on base-files is neccesary - as well - when we were backporting KDE - that caused problems with the control hack in that
<infinity> Mez: It's impossoble for a buildd chroot to NOT have base-files installed.
<infinity> impossible, too.
<infinity> Mez: If you've found one that somehow claims not to, yell at me.
<infinity> Mez: Cause it'd be VERY broken.
<Mez> infinity: lol - well er - I'm working with pbuilds :D
<Mez> and it doesnt seem to grab the Essential stuff there
<infinity> Mez: Same deal.  pbuilder shouldn't be able to make a chroot that's missing "Essential: yes" packages.
<Mez> infinity, weird: because it screwed up a KDE backport cause of that
<ajmitch_> mdz: are TB meetings going to remain at 2000UTC?
<Mez> sistpoty, ping
<sistpoty> Mez: pong
<Mez> sistpoty, I cant get nuke_upload.py to work
<sistpoty> Mez: basically you shouldn't ;)
<Mez> sistpoty, why not?
<sistpoty> Mez: you can do it with the web-interface ;)
<Mez> can I?
<Mez> where?
<sistpoty> Mez: just a second, I'll check if you are set to admin, otherwise you can't nuke uploads
<aal2000> Howdy, is there a ppc specific development channel ?
<Mez> ah thts prob y then
<Mez> I'm not
<mdz> ajmitch_: until someone proposes a different scheme and the board agrees...otherwise inertia wins
<sistpoty> Mez: now you should be able to do it ;)
<Mez> sistpoty, lol - I just updated myself aswell
<Mez> lol
<sistpoty> hehe
<sistpoty> Mez: problem with nuke_uploads is, that I simply don't know if it's still current/what hacks reside in it (if any) and you might need sudo-rights for it
<Mez> sistpoty, I cant see a nuke button
<sistpoty> Mez: you'll need to archive an upload first. then you'll have a nuke link in the list right next to unarchive
<Mez> archive then nuke
<sistpoty> hehe... your faster than I write ;)
<Mez> ;)
<aal2000> Who can I speak to in relation to adding a piece of software to the ubuntu distribution?
<aal2000> It's for imac G5 SMU control.  
<Mez> sistpoty, surely there should be a "are you sure" for nuking stuff?
<sistpoty> Mez: bah... the solution is to give admin-rights only to ppl. who know what they're doing... ;)
<freeflying> aal2000: add your software to wiki/MOTU/Candidates
<Mez> sistpoty, true - but it's kinda disconcerting
<sistpoty> Mez: revu1 is basically a crude hack... I guess we can add this to revu2
<ajmitch_> Mez: just use it with caution then
<Mez> ajmitch_, I will dont worry - lol - but all it takes is an accidental click
<aal2000> freeflying: thanks.
<sistpoty> Mez: you'll need to archive an upload first... so you'll need two accidents ;)
<Mez> sistpoty, can I hack in a javascript yes no?
<Mez> sistpoty - not if you accidentally nuke an archived upload instead of unarchiving
<sistpoty> Mez: javascript in the comment fields? yes, that's possible, since it doesn't check for anything... though you'll need at least a revu-account to post comments
<Mez> sistpoty, no I mean - add in a hack for the nuke link
<Mez> so it doesnt nuke it unless you click a javascript box saying yes
<sistpoty> Mez: hm... might be worth a try, though I generally dislike javasript
<Mez> or even another "confirm" page
<sistpoty> Mez: imo a confirm-page would be better... thus you can use revu full-featured with js disabled as well
<infinity> Or instead of another page (which is another round-trip), just a checkbox under the "nuke" button that says "yes, I know what I'm doing"
<Mez> infinity, or even better "no, I'm not an idiot"
<sistpoty> hehe
<Mez> though I wouldnt be able to use it then
<Mez> hey seth
<seth> hey Mez 
<sistpoty> however as stated before... revu1 is nothing but a crude hack, and changing it is *erm* hacking even more hacks to a screwed up design... I'd rather work on revu2 than change revu1 ;)
<elmo> gnome-screensaver is still horribly horribly slow to bring the unlock dialog up
<sladen> elmo: please sync hotkey-setup 0.1-14 from sid.  This has been outstanding for about a fortnight
<sistpoty> good night everyone
<Mez> infinity - did you see my latest upload to revu?
<fabbione> morning
<ajmitch_> morning fabbione 
<infinity> Mez: Err, no.  I'm revu illiterate.  URL?
<sladen> infinity: probably http://revu.tauware.de/details.py?upid=2082
<infinity> sladen: That does seem likely, yes.
<jdub> whiprush: what are all these photos in your flickr feed?
<whiprush> jdub: blogging now.
<whiprush> gimme 5
<jdub> whiprush: heh
<ajmitch_> whiprush: so we have to sit at your blog hitting refresh to find out?
<Burglaptop> jdub: I need your help in #edubuntu
<Burglaptop> ok, general irc question. If i have ops with one nick and I link my other nicks, do all have ops?
<Burglaptop> and I seriously need help in #edubuntu
<ajmitch_> Burglaptop: they should
<Burglaptop> ok
<whiprush> jdub: http://www.whiprush.org/2006/03/tegnologiedetro.html
<ajmitch_> whiprush: nicely done
<Burglaptop> very cool
* whiprush fixes grammar post haste
<ajmitch_> hm, f-spot 0.1.20, I'm glad I'm not basing this version on upstream'
<ajmitch_> s sleep-deprived typos
<Treenaks> whiprush: heh.. I always have to do that after posting on my blog :)
<Treenaks> whiprush: *post* *re-read* *last-second-fixes* *planet comes by*
<Burglaptop> whiprush: that networking bug should be fixed in dapper
<Burglaptop> Treenaks: indeed
<jdub> whiprush: eh, sweet :)
<whiprush> the trick is to know when to publish. You want to miss a planet feed by a minute, so you have 9 minutes to fix.
<jdub> whiprush: btw, you should look for 'mark of cain' music
<whiprush> mark of cain?
<whiprush> like, the guy that killed abel?
<jdub> turns out they have an official website
<jdub> http://www.tmoc.com.au/
<jdub> i think you'd dig it
* whiprush looks.
<whiprush> this looks like metal.
<Treenaks> btw, the moviegotchis are popular again (because of the new additions)
<ealden> whiprush, hi. does the fridge have an rss feed?
<Treenaks> so popular that I exceeded my bandwidth quota for February with 2GB
<Treenaks> ealden: it does
<whiprush> jdub: it would be nice if the fridge lit up that RSS icon in firefox, the one that shows up in the corner.
<jdub> hrm, wonder why it doesn't
<jdub> it has useful link bits
<whiprush> ealden: http://fridge.ubuntu.com/atom/feed should work for you
<ealden> whiprush, ah. there. thanks
<sladen> jdub: do you have  <link href="..." rel="alternate" type="application/rss+xml" title="..." />  ?
<sladen> ...appears to work for me(tm)
<robitaille> same here...the fridge lit up that rss icon in my firefox
<Lathiat> works in konqueror here too
<jdub> whiprush: you using firefox 1.5 on windows, perchance?
<whiprush> yep
<whiprush> at the moment
<jdub> aha
<jdub> interesting
<jdub> i thought it worked because i was previously looking at ff1.5 in dapper
<jdub> but just then, was looking at it in windows
<whiprush> odd that something like that is platform specific
<Lathiat> could be a bug
<Lathiat> like in the windowing stuff
<Lathiat> or something
<jdub> odd like iz gtk boog
<Lathiat> or actually
<Lathiat> what does firefox's rss icon do
<Lathiat> launches what?
<whiprush> nothing
<whiprush> just lets you bookmark it as a feed
<Lathiat> oh ok
<whiprush> within the application
<Lathiat> (in konq, here, it lets me add it to akregator, so i was thinking a little different)
<jdub> Kamion: ping
<Mez> mdz or Kamion ping
<Mez> Kamion: can I request an UVF exception for katapult
<Mez> so as to sync from debian ... and fix a couple of minor bugs
<sivang> morning all
<Burglaptop> morning sivang
<pitti> Good morning
<zakame> hello sivang Burglaptop
* sivang hugs pitti 
* sivang hugs zakame 
<sivang> and ofcourse, Burglaptop 
* zakame hugs sivang
<seb128> mdz: around?
<seb128> mdz: we had a consensus to not ship xchat-gnome for dapper?
<pitti> hi sivang 
<pitti> hi mvo
<sivang> moins mvo 
<mvo> hello pitti, sivang!
<Kamion> jdub: pong
<Kamion> Mez: send us mail with the upstream changelog or NEWS file snippet or whatever, please
<Mez> Kamion .... er
<Mez> *thinks*
<Mez> the changelog isnt complete
<Mez> because of the baz-> bzr changes
<Kamion> you're really persuading me here ;-)
<Kamion> a description of the upstream changes
* sivang hugs mvo
<Mez> Kamion: the main reason I want to request it is because I'd rather just sync with debian
<Mez> atm - theres no new usptream version in debian 
<Mez> but there will be soon
<Mez> and I dont believe elmo has got round to syncing it...
<Mez> so - I'll need an UVF exception if it gets to that after the neew version goes into debian
<jdub> Kamion: bah, will have to remember to put payloads in my pings again
<seb128> Kamion: I've changed a couple of GNOME packages to get -dbg binary, should I ping you when I do so? Or so you notice them from NEW? Should I update the supported list to mention them?
<jdub> Kamion: that's right -> what's up with ubuntu-artwork?
<ccharles> so, should i assume that all dapper cd images created are installable without issue? 
<Keybuk> Happy Mailman Day, everyone!
<zakame> yay, HMD
<simira> good morning, Keybuk?
* mvo grumbles aobut launchpad timing out all the time when trying to search for a source package
<Keybuk> simira: overslept
<simira> Keybuk: oh, so you didn't have to shovel yourself out of the hotel today?
<pitti> Hi Keybuk 
<Keybuk> hey berpitt
<Keybuk> +i
<slomo_> lamont, infinity: please give-back tomboy (amd64) and gaim (ppc, ia64, amd64)... thanks
<sivang> morning Keybuk , slomo, jdub , simira 
<dholbach> hello!
<slomo_> hi dholbach and sivang :)
<dholbach> hey slomo_ :)
<jdub> yo
<sivang> dholbach: hi
<dholbach> hi sivang
<sivang> dholbach: is it still cold for you there? (getting too hot in here) :)
<dholbach> it's 1C - that's fine
<Mithrandir> dholbach: I'd argue that 29658 shouldn't be rejected since C-u works that way in gdm.
<dholbach> Mithrandir: i see, I'll tell upstream.
<jamesh> seb128: that second bug you asked me to import falls under the same category as the first.  I plan to handle them all in one go, so you shouldn't have to ask again.
<seb128> jamesh: yeah, I've read your mail and planned to reply but got a bit busy with GNOME 2.13.92, thank you :)
<arp> How can I speak to about HAL?
<pitti> arp: by typing questions and comments here :)
<arp> It segfaults on ppc64, if I could get the proper configure options I could build it here and debug it.
<pitti> arp: let's take this to /msg
<slomo_> infinity, lamont: please give-back libgnomeui on ppc
<pitti> seb128: just trying beagle for main inclusion status; is beagled started automatically somehow? I had to start it by hand
<seb128> should be started by apps needing it
<seb128> other way start it by hand
<slomo_> pitti: when you try to search something when beagled is not running it asks you whether you want to start it (at least in beagle-search)
<seb128> ie: if nautilus is built with libbeagle it should start it when you try using it
<pitti> there shouldn't be an autostart .desktop or so?
<seb128> would be nice probably yep
<pitti> since it takes ages to get the first index
<seb128> FC5 has a .desktop for autostart
<ccharles> pitti: hello :) and thanks for the email. i guess this is where we can talk more, when required. i presume the rest are here as well, right?
<pitti> ccharles: welcome here :) Right
<pitti> ccharles: just /msg me if you have some specific packaging and development tools questions
<pitti> ccharles: discussing new features is fine in this channel
<ccharles> pitti: will do. thanks. i've got the latest dapper ISO which i'll pop on soon. better than working in emulators, imho
<Kamion> jdub: failed to build again, see https://launchpad.net/distros/ubuntu/+source/ubuntu-artwork/2
<WaterSevenUb> Kamion, not sure what happened but if you choose. F2 Language, "Portuguese", then "F5" , appears an empty box instead of the english strings. Hope nothing important after I provide the translations. Just to let you know.
<pitti> slomo_: yay, dbus built everywhere, thanks :)
<netstar> I'm curious will there be checks for beagle to see whether the user is upgrading from an old machine, and thus asked whether they want to populate the beagle database quickly on first boot?
<netstar> s/boot/login
<netstar> With large existing home directories it becomes pretty useless.  Especially if that directory is very active.
<netstar> unless you populate beagles db.
<netstar> pitti, wait!
* pitti freezes
<netstar> 2 seconds, I need to double check...
<netstar> I might have just borked the last package...but I tried to reload hal via dbus and it crashed again...just running the original options again and will try that (sorry)
<netstar> very sorry
<pitti> netstar: right, you killed the local patch in the build tree
<pitti> netstar: -> /msg again
<Kamion> WaterSevenUb: please file a bug so I remember to look into that
<WaterSevenUb> Kamion, gfxboot-theme-ubuntu/+bug/33244... u probably want this one too cdrom-checker/+bug/31753 ;-))
<pitti> Keybuk: hmm, network-manager doesn't work any more with l-wlan-ng, and it became crashy
<pitti> Keybuk: I'll check if my l-w-n patches are still ok in the current package, ok?
<Mithrandir> dholbach: any idea how well separated the UI in ekiga is from the rest of the functionality?
<Kamion> WaterSevenUb: there's no point telling me about random other bugs right now - you see I *urgently* have to get espresso done and anything else has to take a back seat until then
<Kamion> I'll go through my bug list later in the cycle
<dholbach> Mithrandir: what do you want to know exactly?
<WaterSevenUb> Kamion, ok, sorry.
* Kinnison bounces
<seb128> Kamion: did you read what I said this morning?
<seb128> Kinnison: around?
<Kamion> hence "file a bug and I'll get to it later" :-)
<Mithrandir> dholbach: how hard would it be to rip out the UI and replace it with, say, a web interface.
<Kinnison> g-p-m upstream are making my life even easier
<Kamion> seb128: yes
<Kinnison> seb128: yes?
<Kamion> seb128: I'll process stuff from NEW in a second
<Kinnison> ogra: richard is taking even more from our patch upstream :-)
<Kamion> seb128: you should add them to supported, yes
<seb128> Kamion: should I ping you (ie: does it make your job easier) to list changes I do? and should I updated supported list?
<dholbach> Mithrandir: no idea, sorry
<seb128> k, thank you
<Kamion> seb128: no need to ping me, it makes my job harder
<Mithrandir> dholbach: 'k, thanks anyway
<seb128> Kinnison: so gnome-session upstream has changed code to match the spec
<seb128> Kamion: noted
<dholbach> Mithrandir: i suppose it'd mean *quite* a bit of new code
<Kinnison> seb128: how do you mean?
<Kamion> seb128: (unless it's really urgent)
<Diziet> Scary.  I just booted a kernel without a correct corresponding modules.dep and the of messages from modprobe are ... copious.
<Diziet> No wonder booting is so slow nowadays.
<seb128> Kinnison: autostart is either /etc/xdg/autostart or /usr/share/gnome/autostart now
<Kinnison> right
<seb128> Kinnison: spec says it's etc and some distro use that, so they list both
<Kinnison> so g-p-m should use /usr/share/gnome/autostart since it's gnomeish?
<seb128> and they changed /usr/share/autostart to /usr/share/gnome/autostart to not conflict with KDE
<seb128> Kinnison: I'm wondering it should not use /etc, it would allow a sysadmin to delete the .desktop if he wants to
<Kinnison> seb128: Okay, I'll let it go back to /etc
<seb128> Kinnison: I was mentionning it for discussion 
<seb128> so your opinion on /etc or /usr is welcome :)
<Kinnison> seb128: I think /etc sounds good for the sysadmin PoV providing we can tell the .desktop only to load on gnome
<Kinnison> is that possible?
<pitti> Mithrandir: gksudo doesn't do anything on the current live cd; known, or want a bug report?
<ogra> Kinnison, wow, cool, even he ranted a lot in the other bug ...
<Kinnison> ogra: yeah, we've sorted that out off-launchpad
<Kinnison> ogra: He was just a bit miffed that I hadn't punted a bunch of this upstream but after I explained about the FF crunch he agreed to just try and take them himself
<seb128> Kinnison: OnlyShowIn=GNOME;
<Kinnison> seb128: thanks
<seb128> np
<Seveas> Keybuk, you evil fiendish overlord
<Seveas> now i have Grease song in my head....
<ogra> Kinnison, yup :)
<simira> Seveas: what's wrong with Grease?
<Treenaks> simira: I think it's the quoting Grease in changelogs thing :)
<Seveas> simira, it's 12:28 and I woke up 30 minutes ago, grease is too much right now
<Seveas> and yet, Keybuks changelogs.....
<Mithrandir> pitti: "doesn't do anything" is not a very useful bug report..
<Mithrandir> pitti: I'll look at it
<Keybuk>  You're the one that I want
<Keybuk>  Ooh-Ooh-Ooh
<simira> Hopelessly devoted....?
<pitti> Mithrandir: i. e. 'gksudo command' just returns to the shell without printing or asking anything (nor executing that command)
<Mithrandir> pitti: does sudo work?
<seb128> where sudo works fine
<pitti> Mithrandir: yes
<Mithrandir> pitti: sounds like a gksudo bug, then.
<netstar> working here...
<pitti> netstar: on the latest live CD?
<Mithrandir> pitti: let me check now that vmware finally decided it like the current cd.
<seb128> pitti: I had the issue friday already
<netstar> pitti, on last night's snapshot
<Mithrandir> pitti: WFM
<pitti> hmm
<pitti> amd64?
<Mithrandir> vmware, so i386
<netstar> ppc G5
<Mithrandir> the closest amd64 is decapitated ATM due to Scott wanting a piece of desk. :-P
<pitti> ok, I'll debug it the next time I load the live CD
<Mithrandir> thanks
<dholbach> Kamion: if you find the time at some stage, you might want to demote gossip to universe (i removed it from the seeds already)
<Kamion> dholbach: done
<dholbach> Kamion: You ROCK! :-)
<Kamion> pitti: I've had a similar issue, yes
<Kamion> in my case it printed a few bytes of garbage
<sladen> win 9
* pitti files an espresso crasher bug
* Kamion looks unsurprised
<Toma-> is there a part of launchpad where you can request features? obviously not for dapper tho
<Treenaks> Toma-: file wishlist bugs?
<dholbach> Toma-: the best way to do this is write a specification
<Toma-> thats it
* pitti hugs Kamion for having to fight all these bugs in no time
<dholbach> Toma-: the clearer the specification is, the more likely it is to get it implemented and people rallied around it
<Toma-> dholbach, ok. ill write a big blog on it :D thanks
<dholbach> the wiki is the better place for this
<dholbach> so people can change it
<sivang> Toma-: Make sure you're idea hasn't already been implemented or already being worked on
<Toma-> oh, its not.
<dholbach> this is what I'd answer on a bug report, if it's just a "hey guys, do this: ...":     'Thanks for your report. Your idea might get more attention and have the possibility of being implemented if you would submit a specification for this. You should first check whether it already exists at the Ubuntu specs page (https://launchpad.net/distros/ubuntu/+specs) in Launchpad. If that is the case, feel free to contact the drafter of that spec abou
<dholbach> t your comments/suggestions. Otherwise you can start writing a spec following the steps described in https://wiki.ubuntu.com/FeatureSpecifications.'
<Toma-> that FeatureSpecifications page doesnt exist yet...
<dholbach> errrrm
<dholbach> it does
<dholbach> https://wiki.ubuntu.com/FeatureSpecifications
<dholbach> you just have to remove the ".'" from the url
<Toma-> oh yeh :D silly me
<jono_> hey all
<tseng> hi jono_ 
<jono_> hey tseng
<jono_> do we have any idea yet if the live cd will be the only CD shipped?
<Toma-> gosh, launchpad sux for creating an account :|
<Kamion> jono_: no.
<sivang> Toma-: what seems to be the problem?
<Kamion> I doubt we'll decide that for sure until quite a bit further down the line.
<jono_> Kamion, no worries
<pitti> Kinnison: Hey Mr. g-p-m guru, do you have a mintue for me?
<Kamion> seb128: -dbg stuff all done I think
<Toma-> "passwords dont match" and theres only 1 password box on this launchpad wiki page
<seb128> Kamion: thank you, I'll updated the supported list
<jono_> Kamion, just expect me to pop in here every so often and ask the same question - feel free to beat me with a stick if at all neccessary
<jono_> :)
<seb128> update
<Toma-> forget about it...
<sivang> Toma-: join #launchpad, there are people there that can help you.
<Toma-> ok
<Kamion> seb128: (in general, you can/should do that before NEW processing happens)
<seb128> (noted)
<Kinnison> pitti: umm, can do
<Kinnison> pitti: what's up?
<pitti> Kinnison: on powerpc, we have a daemon 'pbbuttonsd' which does PM, apple function key handling, etc.
<pitti> Kinnison: which has the effect that both pbbuttonsd and g-p-m want to do PM
<pitti> Kinnison: this e. g. leads to the effect that after resuming from sleep, the computer immediately sleeps again
<pitti> Kinnison: I hoped to be able to drop pbbuttonsd from desktop entirely (i. e. I made pmi independent of pbbuttonsd)
<Kinnison> so what's left that pbbuttonsd does that we can't do otherwise?
<pitti> Kinnison: however, pbbuttonsd does other important things, like controlling the mousepad and function keys, etc.
<Kinnison> Right
<torkel> pitti: happens on my thinkpad T40p too, I have to press the Fn button an extra time to resume
<Kinnison> can we just disable the bits of pbbuttonsd we don't want?
<pitti> Kinnison: in addition, pbbuttonsd even works if no user is logged in
<Kinnison> pitti: yeah, we still lack a policy for noone-logged-in stuff
<pitti> Kinnison: we already disabled brigthness and volume control, i. e. crippled it already
<pitti> crippling it further would make it almost useless for people who don't run gnome
<Kinnison> pitti: can it look for gnome-power-manager and if running, defer to that?
<pitti> Kinnison: it doesn't work well in that direction, pbbuttonsd is a system daemon
<pitti> started earlier than g-p-m, and so on
<pitti> but I'm not sure whether g-p-m should disable PM if it sees pbbuttonsd running
<pitti> it's just pretty messy right now
<Kinnison> pitti: I'm still stuck in patch-hell getting integrated with what upstream have done
<Kinnison> pitti: once I actually have my new g-p-m uploaded we can chat more about this kind of policy, perhaps with mjg59 in on the discussion?
<pitti> Kinnison: yes, would be nice
* Kinnison goes back to patch-hell /away urgh
<pitti> I'll think about it in the meantime
<jono_> any here able to post to the fridge?
<dholbach> jono_: fridge-devel@lists.ubuntu.com
<freeflying> pitti: hi
<pitti> hi freeflying 
<jono_> dholbach, ok, will send it there :)
<dholbach> jono_: ROCK! :)
<freeflying> pitti: which language package depend on im-switch now ?
<pitti> freeflying: I didn't yet change anything about this
<pitti> freeflying: for which languages is it necessary?
<pitti> freeflying: for all that provide a scim module?
<Toma-> dholbach, heres my idea :) https://launchpad.net/distros/ubuntu/dapper/+bug/31775 ill make a wiki for it as soon as i figure out wiki.ubuntu :/
<Ubugtu> malone bug 31775 in Ubuntu "Ubuntu should have better links to support options" [Wishlist,Unconfirmed]  
<Toma-> errr woops
<freeflying> pitti: each cjk language packge shall provide a scim module
<Toma-> https://launchpad.net/distros/ubuntu/+spec/tomhaste
<jono_> dholbach, sent. :)
<Toma-> bbl.
<dholbach> Toma-: cool
<pitti_laptop> freeflying: ok, I'll add it to all support pacakges with a scim module then, alright?
<Toma-> sound like a feasible idea?
<freeflying> pitti_laptop: ya, language package depend on im-switch 
<freeflying> pitti_laptop: I'll add a postinst to each scim module package to add the IM varianle 
<pitti_laptop> freeflying: hm, shouldn't that belong to im-switch rather?
<freeflying> then other language user will not have scim start
<pitti_laptop> freeflying: i. e. isn't im-switch the part that looks at your locale and figures out which module you want?
<Kamion> Toma-'s spec is automated-problem-reports in disguise; sadly I don't have permissions to mark it as such
<freeflying> pitti_laptop: let the scim module register to im-switch , and if user wanna use another input method , it will be easier 
<pitti_laptop> Kinnison: g-p-m doesn't offer me suspend although pmi capabilities has suspend
<pitti_laptop> Kinnison: instead it offers me hibernate, which pmi doesn't claim to support
<pitti_laptop> Kinnison: want a bug report? or already known?
<Kinnison> try enabling suspend in g-p-p
<pitti_laptop> I did
<pitti_laptop> that also seemed to have worked
<pitti_laptop> but it's still confusing, given that suspend is the only thing that works on ppc (hibernate doesn't)
<Kinnison> hmm
<Kinnison> I'm half tempted to disable everything by default
<pitti_laptop> Kinnison: oh, g-p-m cannot even ask pmi capabilities, right? It would need root for that
<pitti_laptop> so the false enabling of hibernate is a hal bug and thus for me
<pitti_laptop> but
<pitti_laptop>   power_management.can_suspend_to_ram = true  (bool)
<freeflying> pitti_laptop: how about that ? 
<pitti_laptop> freeflying: about what?
<freeflying> pitti_laptop: let the scim module register to im-switch , and if user wanna use another input method , it will be easier 
<Kinnison> pitti_laptop: when you enable it in g-p-p it should show up in g-p-m
<freeflying> pitti_laptop: if user choose other input method , they just need register to im-switch 
<pitti_laptop> Kinnison: right, that works
<pitti_laptop> Kinnison: so, this is specifically intended to work like that?
<Kinnison> pitti_laptop: yes
<Kinnison> pitti_laptop: so hal needs to not claim hibernate support if you want g-p-m not to offer it
<pitti_laptop> Kinnison: ah, I see; sorry then
<pitti_laptop> yep, will fix that
<Kinnison> cool
<mjg59> Uh.
<mjg59> No.
<Kinnison> mjg59: ?
<mjg59> Hal is supposed to claim hibernate if there's kernel support for it, regardless of whether or not it'll work
<Kinnison> pitti_laptop: always listen to mjg59 for policy, he's da man
<pitti_laptop> ok
<pitti_laptop> well, the user will figure out fast enough if hibernate doesn't work, and can change it to suspend
<mjg59> pitti_laptop: When you say "hibernate doesn't work on ppc", you mean "hibernate doesn't work on my ppc", right?
<pitti_laptop> mjg59: I heard about other ppcs where it doesn't, but I'd be fine with leaving it enabled by default
<pitti_laptop> so, I can't claim that there aren't any ppcs out there where it works
<mjg59> pitti_laptop: Can we attempt to fix the actual bug rather than just disabling hibernate?
<pitti_laptop> mjg59: preferably :)
<pitti_laptop> it works as soon as I unload half a dozen modules and stop X
<pitti_laptop> (moudles for oops, X for display blackness)
<pitti_laptop> unfortunately I could not pinpoint a particular module
* pitti_laptop needs to test new pbbuttonsd resume here, talk to pitti
<sladen> *blink*  python-psyco is not in the default seed of python stuff...
<sladen> and *jeez* does that make a difference to execution time
<koke> mvo: I have a little patch for g-a-i
<koke> http://people.warp.es/~koke/bzr/gai--koke/
* Kinnison ponders lunch before tackling these last four (largest) patches
<mvo> koke: http://paste.ubuntu-nl.org/9594
<mvo> koke: thanks
<sivang> mvo: what about that UI sprint you metnioned yesterday, when / where is it going to take place?
<sladen> sivang: London, next week
<mvo> koke: any idea about the error?
<mvo> sivang: what sladen said
<mdeboer> hi.
<mdeboer> i am trying to build a custom dapper kernel (with ingo molnars rt-preempt patch), using make-kpkg. but at the end, it bails out complaining that "kernel-headers-[....]   is not in control info". any idea?
<mdeboer> i've done this before, but did not get this error...
<Chipzz> mdeboer: you should be able to work around that at least by just doing make-kpkg kernel_image modules_image
<Chipzz> (I think :P)
<mdeboer> Chipzz: that's what i do
<sivang> mvo: ah nice. Shame I'm on in EU as well... :-/
<sivang> s/on/not/
<Chipzz> hrrrm, worked last time I checked I think
* sivang looks for the announcment
<mdeboer> yes, that's what i thought...
<Chipzz> mdeboer: but I don't think you should be getting an error about kernel-headers when that package is not on the list you specify to make-kpkg, as is the case with "make-kpkg kernel_image modules_image"
<Kinnison> pitti: ping?
<pitti> Hi Kinnison 
<Kinnison> bloody translations
<Kinnison> dpkg-source is ranting about unrepresentable changes
<Kinnison> because something has altered a gmo file
<Kinnison> any idea how to fix?
<seb128> don't alter the .gmo? :)
<seb128> changing the .po is usually enough
<seb128> the .gmo are updated during the build
<Kinnison> seb128: right, so the fact that I did a build in this tree has fucked it?
<mvo> Kinnison: probably, yes
<seb128> might be
<Kinnison> arsepint
<mvo> you could just remove them 
<seb128> if a .po has changed since the .gmo have been generated or if the source code has changed
<Kinnison> mvo: good point
<Keybuk> pitti: do you have a handy bit of shell to do your kick nm into refreshing devices thing?
<pitti> Kinnison: just rm po/*.gmo in debian/rules clean
<pitti> Keybuk: no, I don't
<Keybuk> bah
<pitti> Keybuk: 'refresh'?
<Keybuk> the thing you wrote for linux-wlan-ng, to say "this device has changed, look at it again"
<pitti> Keybuk: aaah, I see; yes, that's a dbus-send invocation, lemme look
<zakame> evening devs
<pitti> Keybuk: dbus-send --system /org/gnome/NetworkManager org.gnome.NetworkManager.RefreshDevice string:wlan0
<pitti> Keybuk: (or whatever device you want to refresh)
<Keybuk> how did you get the org.gnome.NetworkManager thing?
<pitti> Keybuk: that's the name I defined in the n-m patch
<pitti> or, rather, this was already defined
<pitti> I just defined the new function RefreshDevice(string)
<Keybuk> oh right
<Keybuk> am trying to work out how to do a "getDevices" call and get the results
<pitti> Keybuk: hm, it seems it's just my patch that defines this namespace
<pitti> Keybuk: i. e. I added a dbus signal handler that watches out for org.gnome.NetworkManager signals
<Keybuk> ok, but in nm-dbus-nm.c there's oodles of events defined
<Keybuk> methods
<tepsipakki> how does the server-install know to get the correct kernel (linux-image-server) ? or does it?
<Treenaks> mjg59: any news on the wacom-tools4?
* lamont heads off to a day of medical training
<theine>  Hi, will the newest stable version of the ipw2100 driver (1.2.0) make it into Dapper's kernel?
<mjg59> Treenaks: Other than that it's a complete arse to build, no
<mjg59> theine: What bugs does it fix?
<pitti> Keybuk: so, shall I use a different namespace?
<theine> mjg59, 1) Fix debug option cannot enable problem, 2) Add support for WEXT-18 enc_capa v3
<Keybuk> pitti: ah, ok, I see confusion.  you used org.gnome.NetworkManager they use org.freedesktop.NetworkManager ;)
<Treenaks> theine: I think the 2200 version of this patch has already been applied, as I got a 'fix commited' message for that (WEXT-18)
<pitti> Keybuk: oops, my fault; sorry for that
<pitti> Keybuk: someone blew an embargo, so I need to switch to security fix mode now and postpone n-m debugging
<mjg59> theine: Please file a wishlist bug against the kernel
<theine> also, 1.2.0 is marked stable by the ipw2100 devs (as opposed to 1.1.4 which is in Dapper's kernel right now)
<pitti> Keybuk: but if you want, I can change the name along with the l-wlan-ng fixes
<theine> mjg59, alright, i'll do that
<freeflying> pitti: I'm waiting for your decision  :)
<Keybuk> whenever's convenient I guess
<Keybuk> hmm,  (dbus-monitor too dumb to decipher arg type 'o')
<Keybuk> I hate dbus
<pitti> freeflying: oh, I wasn't aware of you waiting
<freeflying> pitti: hehe
<pitti> freeflying: I'm not sure whether the input modules should add variables to the X session
<pitti> freeflying: rather, im-switch should look at the locale and select a scim module, or not?
<freeflying> pitti: now we let im-switch do that for us 
<pitti> freeflying: ritght, that's what I though
<pitti> t
<freeflying> pitti: and let scim's module register to im-switch
<freeflying> pitti: so I'd add them in postinst to scim module's package
<pitti> sounds good
<freeflying> need we comunicate that with scim module package's maintainer 
<pitti> freeflying: not in Ubuntu at least, but if it makes sense, it would be nice to cooperate with Debian
<pitti> freeflying: so that Debian benefits from it as well, and we don't need to carry the patch forever
<freeflying> pitti: ya, and upload to REVU?
<pitti> freeflying: I'm not experienced with Revu, but that should be fine
<freeflying> pitti: ok
* mvo goes to have lunch
<zakame> hi mgalvin giftnudel sabdfl
<mgalvin> hi zakame
<Pygi> matt, have you read the lists? some people want revival of the -instant project...
<sabdfl> hey zakame
<mgalvin> Pygi: i follow it a bit but have been to busy to read them all... which thread(s) are you referring to?
<Pygi> mgalvin: huh, I would have to find it....sec please
<Pygi> matt: roadmap for ubuntu server
<mgalvin> Pygi: link? if you have it?
<ogra> dholbach, ping ... whats up with python-gnome on powerpc ? 
<seb128> ogra: you want to get the reply from dholbach only? :)
<ogra> seb128, nope 
* seb128 looks so
<ogra> i dont care who replies as long as the info contained is right :)
<ogra> but it seems the last upload made all ppc CDs explode 
<Kamion> it's uninstallable, see http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<seb128> hum?
<ogra> so something is wrong
<Kamion> it's not gnome-python at fault though, e.g. gnome-session's uninstallable too
<seb128> looks like the gnome-vfs2 issue
<ogra> due to a dependency on gnome-python ?
<Kamion> I'm not sure picking a random package of the 100+ uninstallable and blaming it is entirely useful
<ogra> heh true 
<ogra> but thats what my chroot gives me ...
<seb128> <fabbione>      the libgnome-vfs2-common changed from arch: any
<seb128> to arch: all
<seb128> <fabbione>      if the chroots are not updated
<seb128> <fabbione>      some -dev are not installable
<seb128> <fabbione>      that's why you see these DepWait
<seb128> that might be that issue
<Kamion> I think infinity might *just* have gone to bed ...
<doko> Kamion: please promote libxmlsec1 libxmlsec1-nss libxmlsec1-openssl linxmlsec-dev, reviewed by pitti, needed by OOo in NEW
<ogra> my chroot says libgnomeui-common (= 2.13.3-0ubuntu1) doesnt exist ... if it build depends on -vfs that might be right
<seb128> it does depends on it
<ogra> ah, k
<ogra> (got no sources in my chroot sources.list to check)
<Kamion> doko: not libxmlsec1-gnutls?
<Kamion> or the xmlsec1 binary itself?
<Kamion> doko: rest promoted
* Kinnison hurrahs as two days of work finally lands in dapper
* Keybuk blinks at bogofilters ... HOW is the word "PayPal" not automatically making it spam? :p
<zakame> HUH?
<doko> Kamion: don't know yet, if OOo needs them ;-) but maybe we should promote all binaries
<sladen> elmo: us.archive.com is out of step
<sladen> elmo: Release vs. Release.gpg so the archive is useless for users
* Lathiat wonders why he has cdrom[0-10]  in /media
<ogra> sladen, longstanding problem 
<sladen> elmo: wget http://mirror.mcs.anl.gov/pub/ubuntu/dists/dapper/Release{,.gpg}
<Pygi> Lathiat: known bug in dapper...worry do not :) 
<Lathiat> Pygi: ok :)
<ogra> sladen, us.u.c is on and off since ages ...
<sladen> ogra: why on earth is it still in the rotation
<Pygi> Lathiat: if you can find out which package in installer causes that, I'll be glad to fix it :)
<Kamion> doko: ok, I've promoted the rest for now, although be aware that they'll drop back to universe if the new openoffice.org doesn't make dapper
<ogra> sladen, dunno why its in *again* it was dropped several times afaik
<Kamion> Pygi: partman-target is a good place to start
<Pygi> Kamion: thanks, I'll look into the matter...
<ogra> Kinnison, wow, thats a impressive changelog 
<Kinnison> ogra: it has taken me two days to do
<ogra> looks rather like the work from a week or two :)
<ogra> (in fact it looks like youv'e nearly rewritten g-p-m :) )
<Kinnison> hell no, richard did a hell of a lot
<Lathiat> haha
<Kinnison> I was just integrating and fiddling
<ogra> heh :)
<elmo> SEGFWG#$HG"
<elmo> gnome-screensaver is locking the screen WHILE I'M TYPING
<Treenaks> elmo: kick the ogra !
<koke> mvo: the error 500 seems to be realted to mod_security on that server, trying to fix it...
<Diziet> AAARGH DBS HATE HATE HATE
<ogra> elmo, since when do you use gnome-screensaver ? i added several patches to adjust the defaults months ago
<ogra> if you used it before there might be wrong defaults in your gconf setup ...
<sivang> mvo: do you have any idea how to overcome this:
<sivang> mvo: Traceback (most recent call last):
<sivang>   File "./upbackup.py", line 294, in on_button7_clicked
<sivang>     gobject.idle_add(self.pushGUIBackup().next())
<sivang> TypeError: first argument not callable
<sivang> it works for the first iteration I think
<elmo> ogra: I just upgraded to dapper yesterday - don't think this particular machine ever had gnome-screensaver installed before
<elmo> it wasn't doing this last night too, it's only after a hibernate, AFAICT
<Diziet> Just discovered the most amazing bug in tcpd.  If you ssh into a machine and your ident lookup is dropped by a firewall (rather than being rejected) and times out, you end up with a session with SIGALRM blocked.
<ogra> elmo, thanks, i'll investigate where my change disappeared 
<ogra> oh
<Kinnison> might be a gnome-screensaver bug
<Kinnison> might be a gnome-power-manager bug
<ogra> that sounds rather like something for Kinnison 
<Kinnison> elmo: try killing and restarting gnome-power-manager
<seb128> my bet is that something has been upgraded and running server and client are not in sync
<elmo> seb128: I haven't upgraded since last reboot
<elmo> I'll try what kinnison said
<Kinnison> elmo: if it continues to happen (without a new suspend) then it's a g-ss bug, otherwise it's a g-p-m bug and you should upgrade once 2.13.92-0ubuntu1 has compiled#
<seb128> so wrong bet, is a bog somewhere
<Mithrandir> ogra: gnome-screensaver occasionally seems to stop detecting activity.  Do you have any idea what it might be?
<ogra> Mithrandir, havent seen that yet 
<jono> hia ll
<jono> hi all
<ogra> Mithrandir, there was a bug with the dpms settings being set to 2minutes or something for all gconf keys (the bug i mentioned to elmo) can you check with gconf-editor thats not the case for you ? 
<Mithrandir> jono, now with echo. :-)
<jono> another quick q - do we know if the dapper CDs will still include The Open CD?
<jono> Mithrandir, heh
<Mithrandir> ogra: it goes away if I kill and restart gnome-screensaver.
<Mithrandir> ogra: and it seems related to suspend and resume.
<ogra> hmm...
<elmo> GRR
<Mithrandir> ogra: xset says dpms is enabled, but the timeouts are 0.
<ogra> Kinnison, how do you call g-s-s ? via g-s-s-command ? 
<elmo> it's still happening after cycling g-p-m
<elmo> which I guess makes it a g-s-s bug
<jono> sabdfl, do you plan on having the open cd on the dapper release cds?
<Kinnison> ogra: no, I use the dbus methods
<ogra> Mithrandir, i'm only intrested in gconf :)
<sabdfl> jono: space will be very tight
<Mithrandir> ogra: why on _earth_ are dpms setting duplicated in gconf?
<ogra> Mithrandir, to be accessible from g-p-m 
<jono> sabdfl, thats what I figured, is it a case of suck it and see closer to the time?
<doko> pitti: language pack ping
<sabdfl> jono: yes, i'm afraid
<pitti> doko: pong
<jono> sabdfl, no worries! :)
<pitti> doko: what's up?
<jono> cheers
* jono slopes off...
<Mithrandir> Kinnison: also, any idea where my g-p-m icon has gone? :-P
* sivang fights with gobject.idle_add
<ogra> Mithrandir, new default :) check the preferences
<ploum> hmmm... abiword files are previewed as txt files. Bug in some MIME type. Against wich package must I report the bug ?
<Mithrandir> ogra: "always display icon" is set in my prefs.
<doko> pitti: ronne:~doko/ooo/2.0.2/l10ntst: these are the new OOo related packages, which will enter the archive soon, please could you prepare an lang update?
<Mithrandir> it returned when I twiddled that setting.
<ogra> Mithrandir, oh
<Mithrandir> Kinnison: ^^
<ogra> Mithrandir, then i think g-p-m crashed for you 
<Mithrandir> 14476 ?        Ss     0:09 /usr/bin/gnome-power-manager
<ogra> it gets started by the prefs window
<Mithrandir> same pid as before I opened the prefs.
<Mithrandir> also, there's no way to suspend from the menu any more.
<ogra> hmm, intresting
<ogra> heh, for me hibernate is gone ... didnt recognize that until now
<Mithrandir> well, there's no hibernate option either.
<torkel> Mithrandir: a reboot fixed the same thing for me so I suspected dbus or hal...
<ogra> missing a reboot ?
<ogra> yes, hall should handle suspend/hibernate capabilitys now
<Mithrandir> ogra: no, not missing a reboot.  Nothing telling me a reboot of any kind is required and there shouldn't be any needed given that I haven't upgraded my kernel.
<pitti> doko: permission denied, the dir is 700
<pitti> doko: what do you mean with a 'lang update'?
<ogra> Mithrandir, upgrading dbus, hal, g-p-m, udev etc all require reboots nowadays
<Mithrandir> torkel: that is so not the right way to fix the problem.
<Mithrandir> ogra: uh?  say again?
* ogra ususally has to reboot once a day since we have that little notifier that annoys me all the time ...
<Diziet> Applying patch debian/patches/./siglongjmp~ failed!
<ogra> Mithrandir, all apps using dbus ... 
<Diziet> HATE HATE HATE
<torkel> Mithrandir: I know, and I agree
<ogra> Mithrandir, plus udev 
<ogra> Mithrandir, dont you get the little violet reboot sign Keybuk wrote if you upgrade any dbus related app ?
<Mithrandir> ogra: no idea.
<Mithrandir> haven't seen it on the laptop.
<Mithrandir> and that's so broken it's not funny.
<doko> pitti: fixed, dependencies of the language packs
<ogra> Mithrandir, normally you get a notification, look if your notification daemon is running at all ...
<Mithrandir>  5172 ?        S      0:19 /usr/lib/notification-daemon/notification-daemon
<ogra> strange 
<Mithrandir> and I have a notification-area-applet
<pitti> doko: I still don't understand, sorry; you mean that OO.o's locale packages have some dependencies now?
<ogra> dunno then, ask Keybuk 
<pitti> doko: or that I should update the language-support packages to depend on new OO.o language debs now?
<doko> pitti: sure, the latter
<pitti> doko: ah; yep, will do it as soon as they are in the archive (to maintain installability)
<Keybuk> ogra: you meant update-notifier
<Keybuk> and he didn't have that running
<ogra> ah
<ogra> i didnt know which piece exactly ...
<Keybuk> why doesn't dbus just get restarted after it's upgraded?
<ogra> Keybuk, upstream decided it will need a reboot there was even a spec at ubz ...
<Mithrandir> ogra: that's _broken_
<Keybuk> but this means if you don't upgrade, gnome-screensaver will end up locking your screen, and then be unable to start its own unlock dialog
<Keybuk> no?
<ogra> but that was on daniels list and got dropped afaik
<Mithrandir> ogra: it would be ok if we were shipping windows.  But we aren't.  So it's not.
<ogra> Mithrandir, that is how it currently is 
<ogra> i dont say i like it
<ogra> Keybuk, no, but thats because the apps all use gnome-screensaver-command yet ... apart from g-p-m which uses dbus ... 
<ogra> Keybuk, so you have a prob if you upgrade g-p-m but dont reboot ... or vice versa for g-s-s
<Mithrandir> ogra: except when they don't.  I've had that happen on occasion when upgrading, then suspending, then resuming.
<ogra> Mithrandir, normally the popup window tells you to reboot as soon as you can 
<ogra> (from the packages postinst)
<Mithrandir> except there's no popup.
<ogra> yes, but then your session is broken ...
<Mithrandir> no, it's not.
<Mithrandir> if gss requires update-notifier to be running, it should make sure it is.
<ogra> phew, but that applies to all the apps using dbus then
<Mithrandir> except that not having g-p-m doesn't break your system.
<Mithrandir> not being able to unlock your screen does.
<ogra> but that must not be caused by a g-s-s upgrade ...
<ogra> it can as well be only a dbus upgrade 
<Mithrandir> doesn't matter.  Is still a g-s-s bug.
<ogra> nope, its a conceptional bug 
<Mithrandir> if gnome-screensaver locks my screen and then fails to unlock it, that's a gss bug.
<ogra> if you dont regard the warning the app sends (reboot notification) you cant blame the app 
<Mithrandir> I didn't get any notification. :-)
<mjg59> ogra: No, anything that leaves a system in an unusable state after upgrade is unacceptable
<ogra> yes, thats a conceptional bug
<ogra> mjg59, what i mean is that we have a bug in the process if we cant guarantee that the notifier is running for *any* dbus driven app
<mjg59> ogra: If an upgrade renders an application unusable without rebooting, then we have a far bigger problem
<Mithrandir> ogra: notifications are not an excuse for actually fixing the problem.
<ogra> mjg59, then we have it ... it renders several apps unusable that rely on dbus 
<Mithrandir> "you need to reboot because I don't know how to reexec myself" is really, really silly.
<Keybuk> ogra: you can't just say "reboot required" and then leave the user in a bad state
<mjg59> ogra: Yes. So we need to figure out how to fix this, not figure out how to tell people to reboot.
<Kamion> ogra: ("conceptual")
<ogra> Kamion, thanks :)
<ogra> mjg59, exactly ... but that requires the whole process to be touched, not only one app ...
<mjg59> ogra: Yes
<Mithrandir> ogra: except that there's one app which intentionally blocks access to the screen.  The others that break don't.  They don't break the system.
<mjg59> But the bug is not "update-notifier is not running"
<Mithrandir> ogra: so while it might be a bug in g-p-m too, it's a far, far more severe bug in gss
<ogra> https://launchpad.net/distros/ubuntu/+spec/dbus-restarts
<koke> mvo: try to merge gai again
<koke> it should be fixed
<Mithrandir> ogra: yes, there's a spec which has never gotten off the ground.
<mjg59> The screensaver is something that must never be broken
<mjg59> People depend on it for security
<sivang> omg , my 2 layered generator methods with a spawned process underneath (dar) works as a charm in reporting progress up to the gui...end of first ver of HUB is appraoching , yay
<Keybuk> aye, gss can't just quit and wait for a reboot because it means people's computers are UNLOCKED
<Keybuk> and it can't just wait for a reboot and happily lock the screen with no chance of unlock either
<mjg59> If it's going to fail, it's better for it to fail locked (but that's not acceptable either)
<mvo> koke: thanks, merged
<koke> great
<Keybuk> random thought ... how does update-notifier get that notification popup to come up?
<Mithrandir> it uses notification-daemon, I presume.
<ogra> Keybuk, didnt you write it ? 
<Keybuk> right, which uses what IPC protocol? :p
<Mithrandir> iz gnome, so dbus? :-P
<ogra> heh, yes :)
<Keybuk> so ...
<Keybuk> if you've just killed dbus by upgrading it
<ogra> the concept is broken :)
<Keybuk> how do you expect update-notifier to popup the "you need to restart now" popup?
<ogra> lets not restart dbus at all
<Keybuk> this explains why I've never seen that popup work recently
<ogra> i see it once a day here 
* Kamion is so glad he decided against making espresso use d-bus internally
<Keybuk> Malone needs an OH MY FUCKING GOD! severity ;)
<Mithrandir> one thing is having to reboot when dbus itself is upgraded, but why would you have to reboot when you upgrade an app?
<Mithrandir> that looks so much like an app problem and doesn't have anything to do with dbus itself.
<Keybuk> why does dbus get restarted?
<ogra> the prob is to start the frontend part again ... it only runs in the users session with user permissions, dpkg doesnt know about which user is using a frontend
<ogra> it can only restart the system backend
<Keybuk> I assume it's something to do with newly upgraded apps using a newer dbus protocol than the running daemon?
<Keybuk> if it restarts the system backend, wouldn'
<ogra> Keybuk, yup
<Keybuk> t all frontends need to be restarted?
<ogra> yup
<ogra> and thats the prob Mithrandir has with g-s-s 
<Keybuk> so couldn't we do that?  restart the system daemon, and all the session daemons
<Keybuk> and then the apps can just reconnect
<Keybuk> after all, they don't drop support for older dbus protocols
<ogra> but that reqiores knowledge of every session
<Keybuk> that's easy
<Keybuk> ps aux | grep dbus ;)
<ogra> nope
<Keybuk> are you saying the system bus doesn't know the list of sessions connected to it?
<ogra> you also need: ps aux |grep g-p-m
<ogra> g-s-s 
<ogra> hal
<Keybuk> why?  those things will notice their session bus going away
<Keybuk> and can reconnect
<ogra> will they ? 
<Keybuk> "oh, my socket closed"
<ogra> i know g-p-m has such a function in CVS, dunno if Kinnison added it yet
<Keybuk> hell, if you shut down the system bus, surely the session daemons will get their sockets closed
<torkel> so there need to be a restart dbus event that all daemons (and apps) should listen to and restart upon
<Keybuk> so they could reexec themselves
<ogra> torkel, thats normally covered by /etc/dbus-1/event.d/
<ogra> but still 
<ogra> you need to execute the frontends 
<ogra> with user permissions ...
<Mithrandir> no, you don't.
<Mithrandir> kill -USR1 $pid
<Mithrandir> and have them trap that
<ogra> unless they can do  it themselves
<Mithrandir> trivial
<torkel> yeah, but if the apps are listen to the "restart" event they should be able to restart, shouldn't they?
<ogra> yes
<ogra> but no app does a kill -USR1 $pid yet, we'll need to add that 
<ogra> i'll do some testing with g-s-s 
<ogra> Mithrandir, can you file a bug with an exact description so i can reproduce it for tests ?
<ogra> i'm pretty sure g-s-s will unlick if i send kill -USR...
<ogra> *unlock
<torkel> ogra: it does
<ogra> yup, suspected that 
<torkel> and it dies :-(
<sivang> mvo: ping, around?
<ogra> dholbach, has ekiga screensaver handling code ? (i.e. did it (or gnomeeting) prevent locking with xscreensaver) ?
<dholbach> ogra: it has dbus code which doesn't built
<dholbach> ogra: build
<dholbach> ogra: I'll try with the next release again
<dholbach> ogra: (maybe in two weeks)
<ogra> dholbach, do you know if it had xss code as well ? 
<dholbach> ogra: no idea, sorry.
<ogra> ok
<ogra> just trying to determine all apps that handled xss to get all gss regressions done ...
<dholbach> Nice. :)
<ogra> (since Mithrandir wants such weird things like no screen locking if a call is in progress ;) )
<sabdfl> elmo: are you still seeing the "Killed by signal 1." problem with rsync / ssh / sftp? i just started getting that
<Kamion> sabdfl: I fixed that in Debian's openssh a week or two ago; will port the change to dapper
<sabdfl> Kamion: thanks muchly
<Kamion> I'd meant to do that but forgot
<sabdfl> stub: am playing with pg8.1
<jsgotangco> hey sabdfl nice to see you back online again
<sabdfl> jsgotangco: *great* to be home
<sabdfl> glad we met up, thanks for your help btw
<jsgotangco> aye must be tough
<jsgotangco> cheers
<desrt> sabdfl; 'sup
<sabdfl> desrt: specs, dude, specs
<desrt> sabdfl; about the logout dialog....
<sabdfl> am working on the spec system
<desrt> ah.  more than just a wiki?
<desrt> sabdfl; the new logout dialog is quite bad and a lot of people do not like it
<HiddenWolf> specifically, it offers less functionality, uses colors and layout unique to the dialogue, and feels bulkier than the gnome default dialogue. 
<HiddenWolf> desrt: that about it?
<pitti> ... and doesn't allow you to save your session
<desrt> HiddenWolf; it also violates the HIG in ways that are bound to suprise and confuse the user
* ogra likes the split approach the two menu dialogs have now
<pitti> ogra: not any more
<HiddenWolf> ogra: amen
<ogra> pitti, ?
<seb128> pitti: upstream doesn't allow that neither
<desrt> seb128; freenode is preventing me from replying to your /msg
<seb128> upstream one
<pitti> ogra: you mean the separate 'log out'/'shut down'?
<ogra> pitti, oohh
<seb128> desrt: reply on gimpnet :)
<desrt> ogra; ya.  the split approach is really nice
<pitti> ogra: that's gone
<ogra> pitti, i just discovered its gone :(
<desrt> seb128; good idea :)
<seb128> HiddenWolf: less functionality is not true, and colors ... icon should be changed
<desrt> pfah.  it's not about the icons.
<desrt> they're ugly as sin but that's a superficial problem
<seb128> desrt: just replying on some non accurate points listed
<pitti> seb128: no 'save session' check box any more is certainly less functionality than in breezy?
<giftnudel> desrt: you need to register to be able to send privmsgs
<desrt> giftnudel; i refuse to register
<desrt> giftnudel; i'm anti-freenode
<seb128> pitti: right, but the 2 dialogs from upstream we had from the system menu for some time have the same issue
<giftnudel> desrt: ;)
* jsgotangco finds it rather huge for a logout dialog but likes the look
<pitti> seb128: ah, you mean *those*. right
<seb128> pitti: the chose is either "those" or the new one
<seb128> nobody is willing to go back with the old one
<ogra> seb128, what about a merge of these two approaches ?
<pitti> seb128: what's upstream's idea of session saving hten?
<seb128> pitti: "those"
<seb128> ah
<seb128> that
<seb128> that nobody uses it :)
* pitti does
<desrt> ya.  sessions are evil :p
<ogra> having two menu items and two dialogs abut with the icon approach the 6-icon-dialog has
<ogra> so one with three icons (restart, shut down, suspend)
<ogra> and one with the user actions 
<giftnudel> I still find "logout"  a funny place to look for user switching ... since you don't actually logout
<ogra> so you have a 3 item and a 2 item dialog instead of a 6 item dialog ...
<ogra> it will look less cluttered 
<tepsipakki> "switch user" to the menu, and a "save session" checkbox to the logout-confirmation dialog
<ogra> but still, the six icon dialog looks not good yet ...
<ogra> it needs reduction 
<giftnudel> I don't think suspend should be in therer
<seb128> ogra: 7 icons actually now
<ogra> *shudder*
<giftnudel> since it's actually only temporarily
<ogra> i only have 6 and a cancel button 
<Pygi> ogra: same here
<ogra> seb128, so we add both suspend actions now ? 
<ogra> gnome-session should look up whats selected in g-p-m as suspend action 
<mjg59> ?
<mjg59> Ah, yes
<Kinnison> Umm, everything else ought to send the dbus signal to g-p-m
<Kinnison> really
<mjg59> Yeah, we shouldn't be suspending via gdm now
<ogra> Kinnison, its just about which icons are shown on logout
<Kinnison> aah
<ogra> and g-p-m already forces you to select one as default
<Kinnison> ogra: how do you mean?
<ogra> so we should pick the one thats selected there and only display this one in the logout dialog
<pitti> ogra: hm? g-p-m allows both for me
<giftnudel> I would only put suspend to disk in the logout dialog and let suspend to ram be handled by g-p-m
<ogra> i.e. if i select suspend in g-p-m, hibernate shouldnt show up
<mjg59> ogra: No, that's no longer the case
<Kinnison> ogra: I have a g-p-m build failure on ia64 which looks like broken deps, any clues?
<ogra> pitti, look at g-p-m "sleep type if inactive" selects the default action
<ogra> Kinnison, looking
<pitti> ogra: well, but that doesn't mean that the user shouldn't get both offered; right-click gpm offers it too
<ogra> mjg59, according to seb128 there are 7 buttons now, i cant confirm since my lappie has no hibernate
<giftnudel> ogra: there are only 6
<seb128> http://www.manucornet.net/GNOME/logout_dialog/with-lock.png
<seb128> 7
<desrt> i count 8
<ogra> ARGH
<giftnudel> seb128: that one doesn't look good ;(
<desrt> well, really i count 1, by any reasonable logic
<ogra> desrt, leave the cancel button ... thats obligatory :)
<desrt> but someone told me that those other weird entities floating in space are actually buttons too
<desrt> so i guess 8
<mjg59> As I keep saying, sleep should not be there by default
<ogra> seb128, that looks horrible 
<seb128> graaa
<giftnudel> mjg59: yes, I can only second that
<giftnudel> sleep is in g-p-m
<mjg59> Because it /doesn't work/
<ogra> mjg59, i would say the preferred default action from g-p-m should be shown there
<mjg59> (In many cases)
<seb128> ogra: I don't take the decisions for that, I'm just implementing, you are complaining to the wrong person
<mjg59> ogra: There is no preferred default action for g-p-m
<jsgotangco> that's a lot of buttons
<desrt> it is
<ogra> mjg59, "sleep type if inactive" was formerly called "default suspend action" in g-p-m
<mjg59> ogra: Yes. And now it isn't.
<ogra> mjg59, did it change functionallity as well ? 
<mjg59> ogra: Before it was not clear what that option /was/
<desrt> seb128; if you do allow the upstream logout dialogs to be gconf'd back into existence, you should probably also deal with the death clocks
* desrt goes to get ready
<mjg59> The upstream logout dialogs are still available
<seb128> no
<mjg59> As far as I can tell, at least. It's what I get if I select actions/logout
<mjg59> Uh, system/logout
<ogra> i really liked the two dialog approach 
<ogra> even the dialogs could have been more pretty
* mjg59 wonders why he still has these dialogs
<ogra> missed upgrade ? 
<mjg59> Possibly
<ogra> running sparc or ia64 ?
<ogra> :)
<ogra> or hppa
<ogra> Kinnison, that ia64 ftbfs might be the same prob powerpc has today ... seems gnome-vfs had probs on some arches, and libgnomeui has broken deps through this
<ogra> Kinnison, just wait until thats fixed and trigger a new build...
<Kinnison> ogra: right
<Kamion> sabdfl: fixed in openssh 1:4.2p1-7ubuntu1
<sabdfl> Kamion: thanks. anything else upstream we can easily pull into dapper?
<Kamion> sabdfl: that's a full merge of current Debian unstable
<Kamion> sabdfl: there's a new upstream release (4.3p2), but I haven't looked at all at it yet
<sabdfl> bonzaiii
<sabdfl> Kamion: doubt there's anything dapper-essential in a new upstream
<Kamion> my feeling is that it will probably fix three things we care about and break five more in fun and interesting ways, based on previous experience
<Kamion> although upstream are getting better about that
<Kamion> sabdfl: I tend to agree; http://www.mindrot.org/pipermail/openssh-unix-announce/2006-February/000084.html is the 4.3 announce
<Kamion> hmm, I wonder though, they mention one thing ...
<Kamion>  * Set SO_REUSEADDR on X11 listeners to avoid problems caused by
<Kamion>    lingering sockets from previous session (X11 applications can
<Kamion>    sometimes not connect to 127.0.0.1:60xx) (Bugzilla #1076)
<Kamion> ogra: I wonder if that's the problem you were having
<Kamion> http://bugzilla.mindrot.org/show_bug.cgi?id=1076
<wftl> Is there any hope that some kind of simple persistence system (a la Knoppix) will be available for the live CD when Dapper becomes official?
<wftl> The persistence document is fine, but it's hardly easy for a newbie.
<Kamion> ogra: yeah, looks the same as https://launchpad.net/distros/ubuntu/+source/openssh/+bug/25528; remind me to backport that
<Ubugtu> malone bug 25528 in openssh openssh-server "X11 forwarding via ssh not releasing ports in timely manner with IPv4 and IPv6 enabled" [Normal,Needs info]  
<Kamion> wftl: talk to Mithrandir about what you need; he implemented current persistence in about a day, so it should be pretty easy to implement something different
<Kamion> or file a bug against casper about it
<Kamion> (since Mithrandir's fairly busy this week)
<elmo> Mithrandir: remind me if it's possible to have folders in thunderbird setup to use a certain From address?
<HiddenWolf> elmo: yes it is
<elmo> how?
<HiddenWolf> elmo: message filter to make it put email from a person/list in a folder
<elmo> eh, no, I'm talking about composing/replying to email
<elmo> i.e. when you're in a certain folder, and you reply to the email, it should use a specific From line
<HiddenWolf> Oh, sorry, misunderstood.
<sladen> elmo: please could you sync hotkey-setup from debian, or let me know what further needs doing first
<koke> elmo: I don't think so, but this may help https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&category=Miscellaneous&numpg=10&id=1203
<elmo> sladen: syncs are queueing, I'll get to them as soon as I can
<sladen> elmo: many thanks
<ogra> Kamion, yes, that looks suspicious like #25528 :)
<ogra> great catch :)
<doko> pitti: so which parsers are affected by the recent flex bug fix and must be rebuilt? ;-P
<doko> and in which packages ...
<pitti> doko: that's what I'm finding out for 2 hours already now
<pitti> tedious and long job :/
<pitti> doko: thankfully few packages seem to be actually affected by it, but it takes ages to find them
<Treenaks> omg, I'm on a  channel with idiots!
* pitti cheers Treenaks 
<Treenaks> People who don't want to reboot *because the reboot icon is so pretty*
<Treenaks> pitti: seriously..
<pitti> are they afraid of losing it, or what?
<slomo_> lol
<Treenaks> pitti: yeah
<Treenaks> Digital hoarders... *ooh shiny thing*
* mvo knows the secret ritual to summon it
* mvo waits patiently for his baz2bzr convert
<doko> pitti: yeah, and to make sure, that the lexer actually is rebuilt ...
<pitti> doko: once I know the actually vulnerable packages, that'll be easy
<pitti> doko: the patch is trivial, and it's even easier with packages which b-dep and use flex
<ogra> Treenaks, just put "sudo apt-get install --reinstall udev" into their session ;)
<ogra> (probably dpkg-reconfigure is enough :) )
<Treenaks> mvo: yeah, but you're cheating
<mvo> Treenaks: correct :-D
<ploum> our new cheerleader : http://ploum.frimouvy.org/images/cheerleader.png
<Treenaks> ROTFL
<Treenaks> ploum: though he usually says 'Rock & roll!'
<ploum> Treenaks: that's what I tought
<ogra> ploum, did you fall in love with gimp recently ? 
<LaserJock> yikes, that is scary
<ploum> but during FOSDEM, he always said "awesome"
<ogra> Treenaks, nah... "GOOD MORNING FREEDOM LOVERS"
<Treenaks> ploum: Please stop my eyes hurt!
<ploum> ogra: not in love. It's just that I can do what I want to do
<Burgwork> ploum, I am scared for life
<Treenaks> Burgwork: scared or scarred? :)
<Burgwork> both
* ogra wonders what pia will say :)
<LaserJock> lol
<ploum> :-D
<Treenaks> ploum: this is for your hackergotchi-and-hands-holding-signs-themed site?
<ploum> Treenaks: not really ;-)  It's just a stupid idea with kikidonk
<ploum> (He told me that jdub is our new cheerleader)
<kikidonk> hehe
<Treenaks> ploum: You're the Belgian twin of jdub then?
<ploum> Treenaks: I wish I can be
<ploum> I'm jealous !
<ploum> Treenaks: you will give a talk about Ubuntu at LugRadio Live ?
<Treenaks> ploum: well, keybuk is probably going to do the best one :)
<Treenaks> ploum: but I'm scheduled to do one, yes (it'll probably be about ubuntu-nl)
<ploum> keybuk ?
<Treenaks> ploum: keybuk.#
<Treenaks> -.#
<sivang> hmm, what do I do when a user cannot connect to the X server? do I need to add him to an Xauthority file or something?
<Treenaks> sivang: why can't he connect? :)
<Treenaks> sivang: what are you trying, and why?
<sivang> Treenaks: just su - dummy_user to check my backup program on 
<ploum> sivang: look if the user is in the video group
<Treenaks> sivang: don't su -
<sivang> Treenaks: but gtk won't start, (users-admin:9903): Gtk-WARNING **: cannot open display:
<Treenaks> sivang: just su
* sivang tries
<sivang>   File "/usr/lib/python2.4/site-packages/gtk-2.0/gtk/__init__.py", line 38, in ?
<sivang>     from _gtk import *
<sivang> RuntimeError: could not open display
* sivang checks the video group
<ploum> Well, it will not help you a lot but when su refuses to display, I ssh -X on localhost as a workaround
<ploum> it's just a bit slower
<ploum> hm, I think the video group is in fact only for 3D acceleration or something like that
<sivang> err, the same
<sivang> ploum: probably
<ogra> sivang, echo $DISPLAY ?
<seb128> try with xhost rather
<sivang> xhost is what I'm looking for, /me hugs seb128 
<sivang> thanks
<seb128> heh, stay cool, np :)
<ploum> pff... it's always the same with seb128
<seb128> hey ploum :)
<sivang> seb128: :-)
<ploum> he's always right ! ;-)
<ploum> hello :-)
<ogra> ploum, yes, thats very sad, you cant argue with him and expect to win
<ogra> :)+
<ploum> in fact, my IRC client is called : "ask seb128"
<ogra> lol
<ploum> seb128: question for you. There's a problem with abiword mime type. It's recognized as a plain text file. Against wich package must I report the bug ?
<dotwaffle> Good evening, all. Any chance Daniel Silverstone is around?
<seb128> ploum: what file? right click with nautilus, properties and look the exact mimetype
<Treenaks> dotwaffle: --> Kinnison 
<dotwaffle> Treenaks: thanks, I'll query him.
<ploum> seb128: it's an abw file. That was working fine yesterday. Today it's "Text/plain" in the Mime type
<ogra> ploum, so did you update abiword today ? 
<seb128> ploum: does other stuff still work?
<seb128> ploum: like a .zip or a .png?
<ploum> seb128: yes. ogg, mp3, png, pdf and even exe with wine
<ploum> ogra: no
<seb128> ploum: nothing changed for that
<seb128> ploum: that would be a gnome-vfs2 bug so
<seb128> ploum: feel free to open a bug and attach an example
<ploum> I indeed upgraded it yesterday
<ploum> Hm, there's a non-upgraded libgnome-vfs
<ploum> I upgrade and then I report the bug
<ploum> thanks :-)
<ploum> (ogra : you see ! It works !)
<ogra> ploum, i'm tempted to rename my xchat as well ;)
<zyga> hey guys
<ogra> "ask doctor seb" :)
<seb128> I'm not a doctor, that's mdz :p
<ogra> lol 
<ogra> yeah
<sivang> heh
<ploum> seb128: must I report it upstream or in launchpad ?
<seb128> ploum: put it to launchpad, I'll forward it
<seb128> I want to play with it first
<ploum> perfect
<seb128> thank you
<ploum> seb128: https://launchpad.net/distros/ubuntu/+source/gnome-vfs2/+bug/33301
<Ubugtu> malone bug 33301 in gnome-vfs2 "Abiword files have wrong MIME/Type" [Normal,Unconfirmed]  
<ploum> do you want a sample file ?
<seb128> ploum: no that's fine, thank you
<seb128> happens with a simple file stored on the disk
<seb128> dinner time, bbl
<ploum> bon appetit
<seb128> 'ci
<dholbach> seb128: you really say "'ci"?
* dholbach is amazed by the french's obvious lack of time :)
<Treenaks> dholbach: nah, the words are just FAR too long ;)
<G0SUB> pitti there?
<ogra> dholbach, he already had his mouth full ;)
<Treenaks> dholbach: how's Dutch Harry Potter going? :)
<pitti> G0SUB: about to leave to training, sorry
<dholbach> Treenaks: veeeeryyyy slooooowlyyyyy
<mantiena> Hi all
* Burgwork hugs seb128 
<G0SUB> pitti just 5 mins?
<pitti> G0SUB: please email martin.pitt@ubuntu.com, or catch me tomorrow morning
<dholbach> pitti: have fun!
<pitti> G0SUB: no, sorry, bus is coming in 8 minuts
<G0SUB> pitti okay, I will
<G0SUB> pitti see you
<pitti> cu guys
<G0SUB> how many hours to ``tomorrow morning''? which TZ is he in?
<Treenaks> G0SUB: He's in CET
<G0SUB> Treenaks what's the offset?
<Treenaks> G0SUB: 'Western Europe', GMT+1 afaik
<G0SUB> oh. okay
<G0SUB> a lot of people in GMT+1
<Treenaks> all of Europe, except the UK, basically
<Treenaks> oh and SA of course
<mantiena> doko, hi, are you online ? I almost backported OOo 2.0.2 from your sources - all stuff was compiled properly, just got few errors when creating deb packages (install section in debian/rules)
<G0SUB> heh
<ogra> which is, uhm, central europe :)
<mantiena> Treenaks, Lithuania is in +02 ;)
<Treenaks> ogra: sure.. SA is central europe. Go tell sabdfl :P
<ogra> hehe
<G0SUB> lol
<Mithrandir> elmo: there exists a plugin to do it, IIRC
<mantiena> doko, please, tell me if you can build deb packages from 2.0.1oob680m4-0ubuntu3.1 source
<mantiena> without errors
<jbailey> Lintian bitches about hardlinks without actually saying why.  Can someone explain this to me?
<dholbach> what does    lintian -i    say about the case?
<jbailey> Ah, recent lintian actually has a better message.
<jbailey> it used to say "Hardlinks are bad, mmkay?"
<sivang> G0SUB: there's also people on GMT+2 :-)
<G0SUB> sivang heh :)
<G0SUB> I am on +0530
<sivang> wow, where is that?
<G0SUB> sivang dude, India!
<G0SUB> sivang you know, your nick is very close to being an Indian name
<sivang> G0SUB: why thank you, I didn't realize that :)
<G0SUB> we may write it as Shivang ... the body of the God Shiva
<sivang> funny, my name get's strange sounds all over, for example, japneese call me "Sheeban-San"
<G0SUB> sivang the JP guys just have weird pronounciations for simple names
<G0SUB> Sheeban is okay, but the extra San?
<sivang> that is sort of a "mr." or so I'm told
<Treenaks> G0SUB: that's just tacked onto every Japanese name
<sivang> yes, inded.
<Treenaks> G0SUB: it's a politeness form
<G0SUB> oh, I see
<Treenaks> or something
<G0SUB> my name is Baishampayan Ghose ... I guess they'd pronounce it as Bison-Py-Yum GNU-Sh
<G0SUB> a perfect Free & Open Source Software name
<Treenaks> G0SUB: LOL :) cool
<G0SUB> hehe
<G0SUB> [no offense to any JP guy. you guys rock!] 
<Treenaks> my nick is just a semi-pronounceable word that had 0 google hits when I chose it :)
<G0SUB> why semi- ?
<G0SUB> Treenaks I'd write it as  in my lang
<trappist> I measure my value as a human being in google hits on my name
<G0SUB> trappist lol
<Treenaks> G0SUB: hmm.. shouldn't that be a single line connecting all the characters near the top? it breaks now(?)
<G0SUB> Treenaks yeah, it shouldn't break ... your client needs the fonts and pango
<Treenaks> G0SUB: I have fonts, and pango (gnome-terminal)
<Treenaks> G0SUB: guess it's the font
<Treenaks> (monospaced)
<G0SUB> Treenaks broken free-fonts 
<trappist> it's all accented a's, upsidedown question marks, subscripted 4's and control characters here
<G0SUB> Treenaks btw, do you know which lang it is?
<G0SUB> all hits on GOOG for my name are just _mine_ ... there is none in the whole world with my name & a web presence
<Treenaks> G0SUB: well, I know the alphabet is called Devangar
<G0SUB> Treenaks no, it's not Hindi
<G0SUB> Treenaks India has 18 officially recognised languages
<Treenaks> G0SUB: isn't the alphabet shared?
<G0SUB> with distinct scripts
<Treenaks> (at least by a few of those)
<G0SUB> and thus, fonts
<Treenaks> oh wow
<Treenaks> must be a support disaster ;)
<Treenaks> G0SUB: so what is it then?
<G0SUB> Treenaks Bengali (bn) (ben)
<G0SUB> it uses a script which is derived from the Brahmi Script
<LaserJock> that's why I see all those fonts roll by when I install Ubuntu ;-)
<Treenaks> G0SUB: *looks on omniglot.com*
<G0SUB> the fonts included in freefonts is badly broken
<G0SUB> LaserJock heh
<Treenaks> G0SUB: Omniglot reports both Hindi and Bengali as derived from Brahmi
<Mez> infinity: ping
<G0SUB> Treenaks well, it's not accurate
<G0SUB> Treenaks the Hindi script is Devnagari
<Treenaks> G0SUB: I know that
<Treenaks> G0SUB: it's the languages vs scripts thing I have mixed up I think
<G0SUB> Treenaks brahmi is a script ... both hindi & bengali are derived from Sanskrit
<Treenaks> ah
<G0SUB> Sanskrit (sa) is the / of almost all Indic languages
<Treenaks> G0SUB: Bengali almost looks like musical notes to me (if the renderings on http://www.omniglot.com/writing/bengali.htm are correct)
<G0SUB> Treenaks heh, it's correct and what you said is funny
<G0SUB> all indic languages are extremely complex for a computer to parse/understand btw :(
<Treenaks> G0SUB: yeah, I've heard unicode rules for some Indic languages have been changed quite a few times to just make them _work_
<G0SUB> yep
<G0SUB> and we are facing some issues with the debian G-I ... although most of them have been solved now thanks to the community
* Treenaks -> beer :)
<Treenaks> see you later
<sivang> Treenaks: you start sounding like garnacho ;p
<sivang> (gnome-system-tools maintainer :)
<Treenaks> sivang: is that a good thing?
<sivang> Treenaks: ofcourse !
<enz0_> I'm trying to extract the contents of dapper's install/initrd.gz file (which uses initramfs, right?) using 'cat initrd | (cpio -i -d -m ; cpio -i -d -m)' but get "cpio: premature end of archive" after it extracts 17Mb worth of data.  the md5 matches up so what am I doing wrong?
<enz0_> hrm, I just did a 'cat ../initrd | cpio -i -d -m' and it seemed cool
<enz0_> so what is the typical way of modifying/updating the initrd file if that's not it?
<dooglus> is there a channel for security bugs?
<Pygi> well, if security bugs exist, they should be filled as bugs if not extremly critical I think...
<dooglus> I did that already.
* sivang wonders what gentoo.ubuntu.com is for
<dooglus> I was hoping to find someone to discuss it with.
<Pygi> dooglus: well, what's the issue? :)
<dooglus> for instance, what are "our embargo terms"?
<sivang> dooglus: Chris ?
<dooglus> yes, dooglus == Chris :)
<Pygi> sivang: bazaar at gentoo.ubuntu.com ?? :-/
<dooglus> I'm looking at the last comment attached to bug 30940 and wondering what it means about "breaking our embargo terms"
<sivang> dooglus: Hey Chris, did you find the xplenation I put on the bug report how you can do patches and upload yourself satisfactory ?
<Ubugtu> malone bug 30940 in flex "buffer overflow vulnerability in code generated by flex" [Critical,Confirmed]  http://launchpad.net/bugs/30940
<dooglus> sivang: I did, thanks.
<Pygi> dooglus: sec pls, lemme take a look
<dooglus> sivang: so it looks like my first step is to find someone willing to sign my key?
<sivang> dooglus: well, it can be, but in the background you can upload packages to REVU for univers so people will be able to evaluate your work, or let MOTUs grab your packages form somwhere else if you can't upload to REVU
<dooglus> sivang: what's the situation with that?  I guess each package is owned by somebody.  Won't they get annoyed if I fix bugs in 'their' packages?
<jbailey> sivang: I don't remember off hand what the machine is for, but manyof them are named after penguins.
<Pygi> dooglus: might mean that the patch doesn't conform to ubuntu policy? :-/
<dooglus> Pygi: I was wondering if it meant that pitti had asked the flex guys not to go public with it yet, but they did.
<dooglus> Pygi: but it's not clear, is it.
<Pygi> dooglus: true, can be interpreted almost in any way :-/
<dooglus> Pygi: either way, it doesn't look to me like the patch fixes the bug...  I'm looking into it.
<Burgwork> sivang, gentoo is one of the canonical servers
<Pygi> dooglus: really? link to patch perphaps if I may look?
<sivang> dooglus: mostly, if you have a change for the good, the original "maintianer" or the person who touched it last won't mind IIRC. In general you can contact the last uploader if in doubt (evident by the Changed-By field in the source) and aks for guidance
<dooglus> Pygi: I've not seen the patch.  But the new binary is as bad as the old one, I think.
<sivang> dooglus: also, make sure you contact dholbach or other people in #ubuntu-motu to start with the whole process. 
<enz0_> is there a site where I can get more information about casper and how it's used in dapper's live cd?
<sivang> dooglus: https://wiki.ubuntu.com/MOTU is a good read
<dooglus> sivang: thanks
<sivang> dooglus: my pleasure.
<doko> Kamion: please promote lib64asound2-dev and lib32asound2-dev to main, b-d's of gcj-4.1
<Mithrandir> grr
<Mithrandir> networkmanager doesn't handle latin1 ESSIDs
<Treenaks> ESSIDs should be UTF-8!
<Mithrandir> NetworkManager shouldn't segfault. :-P
<Treenaks> that too
#ubuntu-devel 2006-03-07
<jdub> hrm, every time i open a terminal, i get the sudo reminder
<doko> jdub: did you touch gdm? I get an infinite loop on boot, gdm crashing with a graphical message: "The greeter application appears to be crashing. Attempting to use a different one" but there is no different one ...
<jdub> doko: hmm, might be a weird interaction with the u-a update?
<jdub> doko: it works for me, so i'll have to look into it
<jdub> doko: got any log action?
<doko> jdub: just in syslog: gdm: failsafe dialog failed
<jdub> interesting
<jdub> so not only did the greeter fail
<jdub> but failsafe failed too
<doko> hmm, seb128 did the last upload
<jdub> can you paste me the output of dpkg -L ubuntu-artwork | grep gdm ?
<olemke> doko, maybe it has to do with the latest libgtk? it crashes for me in _gtk_get_libdir with every app
<doko> olemke: ouch, that would be my upload :-/
<olemke> doko, right :)
<jdub> keybuk is using grease lyrics in his changelogs...
<dotwaffle> I use foreign swearwords in my comments - "Credo di essermi sporcato i pantaloni" appears quite a lot ;)
<sdquinn> i heard a rumor that in the future ubuntu may rid itself of ndiswrapper.
<sdquinn> is that plausible?
<dotwaffle> plausible, yes, likely, no.
<Burgwork> sdquinn, if and only if all cards work ootb
<Burgwork> sdquinn, so getting rid of ndiswrapper would be a good thing for users, not a bad one
<dotwaffle> I think the great thing about Ubuntu is the fact that it sticks to its principles when it comes to binary drivers - will not ship with them. It's basically a middle finger up approach to the issue. And by god, it works!
<Burgwork> dotwaffle, binary drivers are also a major nightmare to debug
<dotwaffle> not just a nightmare to debug, it also lessens the core message that they're trying to get across. Bug #1 and all that ;)
<Ubugtu> malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Normal,Unconfirmed]  http://launchpad.net/bugs/1
<jdub> dotwaffle: we do ship binary linux drivers, in addition to ndiswrapper.
<dotwaffle> jdub: However, they are not activated by deafult, you have to explicitly turn on the restricted repo.
<jdub> dotwaffle: restricted is on by default, and lrm is installed by default.
<dotwaffle> which is not exactly noob-friendly. It's only people who have ither technical knowledge and/or debian experience that are likely to play with that.
<dotwaffle> jdub: Is it? I swear mine wasn't...
<mez> has anyone done an apt-get upgrade within the last 10 mins?
<mez> all my gnome apps are segfaulting
<jdub> yeah, mine too
<jdub> uh oh :-)
* mez is lucky he has KDE
<mez> KDE apps are fine
<mez> who cocked up ?
<Unfrgiven> mez: yeah and gdm doesn't even start
<Unfrgiven> mez: did you get a post-install script seg fault when upgrading libpango?
<jdub> seems everything gets into a massive uname lookup loop
* ..[topic/#ubuntu-devel:mez] : 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 | dapper severly broken for anything but KDE apps
<_rich> using kubuntu breezy. noticed that /dev is mounted with ramfs (using udev). why using ramfs and not tmpfs like other distros?
<jdub> Unfrgiven: that's probably a result of whatever has happened, not a cause
<Unfrgiven> jdub: fair point.
<jdub> so what's at the bottom of the stack here
<jdub> we've got pango
<_rich> is there an advantage to using ramfs for /dev over tmpfs for /dev?
<dholbach> olemke doko, maybe it has to do with the latest libgtk? it crashes for me in _gtk_get_libdir with every app
<dholbach> doko olemke: ouch, that would be my upload :-/
<dholbach> olemke doko, right :)
<dholbach> half an hour ago
<jdub> libgtk
<jdub> dholbach: norty
<jdub> dholbach: what did you change
<jdub> ?
<dholbach> jdub: <doko> olemke: ouch, that would be my upload :-/
<jdub> what did you change?
<dholbach> jdub: doko took over maintenance
<dholbach> :-)
<dholbach> all GTK bugs are his
<dholbach> I think it was related to some ia32 stuff
<jdub> the ia32 stuff?
<jdub> yeah
<jdub> boh
<mez> doko: ping
<mez> lol
<mez> aha we have a gtk+ upload
* mez goes and watches the buildds
<doko> dholbach: it did work on amd64 :-)
<Seveas> !lart doko
<mez> lol
<dholbach> doko: ah that's why I was happy on amd64
<dholbach> 2.8.13-1ubuntu3 might make the world happy again
<Seveas> hmm
<Seveas> xterm is such a pain compared to gnome-terminal...
<mez> dholbach: I hope so - now to wait for the buildds to pick it up
<dholbach> hey seb128! :)
<seb128> dholbach: re
<dholbach> welcome back, seb
<Seveas> woah endless recursion
<ajmitch_> morning
<doko> mez, dholbach: updated packages at http://people.ubuntu.com/~doko/gtk/
<mez> doko: did you not upload to ubuntu ?
<doko> mez: uploads are source only
<mez> doko: true - but wont the buildds pick them up any moment now ?
<seb128> doko: having fun with gtk? :)
<seb128> doko: you touched them you are maintainer now :p
<doko> seb128: wanno upload GCC? ;-P
<seb128> no, thank you :p
<doko> seb128: btw, I know of packages which *end* on g ...
<mez> nice
<mez> liblaunchpad-integration-dev is remove with the new gtk package
<seb128> what about lpi?
<jdub> seb128: doko made iz gtk boog
<mvo> doko: you started to maintain gtk?
* seb128 reassigns bugs to doko
<jdub> this is why i only trust sebuild!
<Seveas> woohoo, gtk works again 
* doko reassigns bug ending with *g to seb127
<seb128> Seveas: it was broken!?
<Seveas> seb128, segfauts all over
<Seveas> no gtk apps would start
<seb128> is that a joke?
<Seveas> no
<TerminX> no
<TerminX> it's not a joke
<Mez> Seveas, lol - yeah but is that using dokos stuff ?
<seb128> doko: stop touching GTK
<Mez> or the stuff in ubuntu ?
<TerminX> that's what those debs in doko's link are for, to fix it
<Seveas> mez yes
<Mez> lol
<seb128> grumpf
<Mez> it's still broken in ubuntu :D
* Seveas hands seb128 a big bo of valium
<Seveas> box*
<Mez> waiting for buildds to pick up new build (which works)
<Mez> It was interesting only being able to use kde apps :D
<Mez> lol
<Mez> not somethign I wanna do again though
<seb128> doko: next time please send me a patch instead of breaking it, thank you
* Mez hugs doko
<Mez> dont be mean ...
<doko> seb128 never 'ugs me ...
<seb128> Mez: breaking GTK is not really funny :p
<seb128> doko: if you don't try stuff before upload I would really appreciate you sending a patch instead of uploading next time
<seb128> <gjc> seb128!
<seb128> <gjc> seb128: did you know, I was getting segfaults in every gtk application..
<seb128> great, upstream going to like us now :p
<mvo> three cheers to gtk
<Mez> seb128, it may not be funny... but at least it's fixed and well... everyone makes mistakes
<seb128> Mez: I usually run a new GTK for a day or so before uploading
<Mez> seb128, he may have done so - but the changes worked on amd64 I believe
<seb128> Mez: some packages should be tried before beeing randomly uploaded
<seb128> Mez: when you do a such change you try on i386 too
<doko> seb128: yep, tried, on amd64
<seb128> grumpf
<doko> even the i386 packages on amd64
<seb128> you managed to broke it anyway, next time please send a patch for comment
<seb128> doesn't hurt to have 2 people looking on a change before breaking gtk :)
<Mez> seb128, yeah - cause then both people can be to blame ;)
<doko> seb128: you should install kde as a fallback ;-)
<seb128> doko: I didnt upgrade to your version of GTK :p
<seb128> which is a better way to not break my box :)
<dholbach> Xubuntu!
<ajmitch_> dholbach: uses gtk+ as well, I fear
<dholbach> oh yes, right
<dholbach> damn
<ajmitch_> which is why we need a desktop based on fltk
<Mez> dholbach, yeah it does - I tried that to see if it was just a KDE problem
<seb128> doko: what do you need to patch GTK for BTW?
<dholbach> ajmitch_: wXubuntu :)
<ajmitch_> dholbach: let's drop this now :)
<doko> seb128: I told you ... ia32-libs-gtk. do you want to take that over?
<seb128> doko: no, just trying to figure why we need those
<seb128> openoffice?
<doko> no, the one *ending* with g
<doko> openoffice.orG
<seb128> pong?
<seb128> ah :)
<mvo> doko: everyone knows that seb128 uses windowmaker at his box
<doko> :)
<seb128> mvo: shushhh
<seb128> (it's a secret)
<mvo> seb128: nothing you want your gnome friends to know ;) ?
<doko> mvo: 'e is a *G*nustep fan ;)
<seb128> mvo: exactly ;)
<mvo> lol
<ajmitch_> doko: btw are zope3 deps still waiting on some NEW processing?
<doko> ajmitch_: just pending syncs
<ajmitch_> maybe notok
<ajmitch_> s/maybe not//
<ajmitch_> :)
<nictuku> mvo hi. Do you remember the NetworkWideUpdates spec?
<mvo> nictuku: sure
<mvo> nictuku: you intended to look at it, right :) ?
<mvo> we talked about it a while ago?
<nictuku> nice, I'm glad you remembered
<nictuku> I'm working really hard on it
<nictuku> You know, I didn't know anything about python then.
<nictuku> it's working, by the way
<mvo> have you setup a repository yet? or is that too early?
<nictuku> A subversion repository is available, yes
<nictuku> https://opensvn.csie.org/traccgi/nwu/wiki/
<nictuku> But as I notice in the wiki, it's a pain to test it before we make deb packages for it
<nictuku> *note
<mvo> nice! I will checkout the code when I'm a bit more awake and have a look, it's really cool to see someone working on this :)
<nictuku> It already "update", "upgrade", "install" and shows some interesting information about the clients: installed packages, pending upgrades, current repositories
<Lathiat> i was jsut thinking about implementing such a thing yesterday
<nictuku> I will be happy to hear from you then.
<Burgwork> nictuku, a nice pygtk frontend would be nice too
<Lathiat> need to convine the boss its good use of work time
<Lathiat> :)
<nictuku> Lathiat, you could help me out :-)
<Burgwork> nictuku, but otherwise, very cool
<nictuku> Burgwork, yes, that is a most! but it's not the time to it, yet. But I did consider it when developing the architecture
<nictuku> I mean, web services-based administration tools
<Burgwork> nictuku, ideally the pygtk interface would be on an admin workstation, not the server
<nictuku> sure
<nictuku> currently the administration tool talks to the database directly, but that is only a ugly but needed hack. Milestone1 is a prototype, actually
* mvo goes to make some tea
<Burgwork> nictuku, very cool indeed
<nictuku> really? :-)
<Burgwork> nictuku, network wide stuff is sadly lacking in free tools currently
<desrt> er
<desrt> i just upgraded on dapper and firefox now segfaults on startup
<desrt> anyone else?
<Burgwork> desrt, gtk issue
<desrt> k.  good to know it's known :)
<Burgwork> desrt, been fixed, waiting for buildds
<Lathiat> its always a gtk bug, poor seb128 :)
<desrt> this one appears to be doko's fault :)
<Burgwork> actually, this was doko
<desrt> oh shit
<desrt> everything segfaults on startup
<desrt> hah
<infinity> Oh, is that why gnome-screensaver just refused to let me back in and I had to kill it?
<seb128> desrt: I would not break GTK that way
<desrt> seb128; i did not blame you.  i know it's doko :)
<Burgwork> desrt, nah, seb128 would find a more creative way to break it ;)
<seb128> :p
<jbailey> elmo, Znarl: ping?
<desrt> Burgwork; he'd probably patch a new and intrusive dialog box with 8 buttons that pops up when you try to exit the application
<desrt> [exit]  [suspend]  [^z]  [dump core]  [switch application]  [restart application]  etc
<Burgwork> [piss off users] 
<desrt> :)
<seb128> ah ah
* desrt uses konq instead
<desrt> i knew this would come in handy some day :)
<nictuku> mvo, when I needed a way to read the repositories information I saw your update-manager/python/aptsources.py, and then wrote https://opensvn.csie.org/traccgi/nwu/browser/nwu-agent/agent/misc.py "read_sources_list()". I think you'll like it too :-)
<mvo> nictuku: I would like to get something like this in python-apt at some point
<nictuku> btw, do you know if python-apt behaves well in other apt-able distros like Fedora and (?)Mandriva?
<mvo> nictuku: it should, but I'm not sure if someone actually made packages for those distros
<nictuku> hmm I see.
<nictuku> If so, nwu is almost ready for them too hehe.
<pitti> hello
<ajmitch_> hey pitti 
<Kamion> doko: done
<doko> Kamion: ?
<JaneW> ping: dholbach, doko,  infinity, hno73,   keybuk, lathiat, Mithrandir, ogra,  sivan ,Riddell -> #ubuntu-meeting
<dholbach> here here!
<Kamion> doko: 21:05 < doko> Kamion: please promote lib64asound2-dev and lib32asound2-dev to main, b-d's of gcj-4.1
<doko> Kamion: thanks
<JaneW> ping:  Mithrandir,  ogra,  sivan  - > meeting
<carl_fk> currenty something passes -a to xchat-gnome when folloing an irc:// link -a is good for xchat, but not xchat-nome.
<carl_fk> its logged: https://launchpad.net/products/firefox/+bug/31226
<Ubugtu> malone bug 31226 in firefox "FF doesn't do irc:// correctly" [Normal,Confirmed]  
<carl_fk> wondering who else should be told given that it isnt a FF problme
<Kinnison> sladen: F24, says who?
<JaneW> ogra: ping
<Kinnison> sladen: hotkey-setup?
<sladen> Kinnison: yes
<Kinnison> sladen: that wasn't a questioning of your honesty, it was an enquiry as to what that is
<sladen> Kinnison: the script on boot that detects the laptop type and remaps the vendor-specific crack keys to the standard ones in the kernel.  KEY_PRESENTATION, KEY_BATTERY, KEY_VIDEOOUT, KEY_ROTATESCREEN, KEY_VIDEOMODECYCLE are currently aliased to high Fkeys as they appropriate assignments available <255 
<Kinnison> sladen: who chose the value for the battery key and how long ago?
<sladen> Kinnison: either mjg59 or me.  it is a bit backed up as it's been waiting on a sync from debian for 3weeks
<Kinnison> I see
<Kinnison> okay, thanks
* Kinnison will investigate that tomorroew
<sladen> Kinnison: if you fancy getting upstream to assign the above 5 keys that are needed, that's be cool;  in case that doesn't happen, I guess go with standard ubuntu-aliases
<Kinnison> well, userlevel apps just use the symbolic name (battery) so I guess it won't hurt to go with the ubuntu names. mjg59 was supposed to be looking at upstream but I don't know the timeframe on that
<Burgundavia> Kinnison: the timeout for gpm dimming the screen is about 5 times too short
<Kinnison> Burgundavia: please file a bug, it's 02:51 and I'll have forgotten you said that in the next 5 minutes
<Burgundavia> Kinnison: ok
<Kinnison> Burgundavia: also, suggesting a reasonable time would be good
<Burgundavia> Kinnison: ok, will do
<Kinnison> Burgundavia: thanks babe
<Burgundavia> Kinnison: kisses
* Kinnison falls asleep on his keyboard
<dholbach> night guys
<Kinnison> night all
<nictuku> dholbach, Kinnison, night
<esac_> Hi, I am wondering how I can get traction on the following bug https://launchpad.net/distros/ubuntu/+source/pcsc-lite/+bug/32911 .. I really need it in order to even use linux and am willing to provide whatever information, debug, etc... 
<Ubugtu> malone bug 32911 in pcsc-lite pcscd "Gemplus Smart Card Reader no longer works" [Normal,Unconfirmed]  
<Kamion> mdz: is there anything in the list of Xubuntu promotions that you have a problem with? I'm about to start having a look through those with approved main inclusion reports
<mdz> Kamion: I don't see them in the list anymore
<Kamion> mdz: they're still in http://people.ubuntu.com/~cjwatson/anastacia.txt
<jbailey> mdz: I don't think we've done the support review for any of the Xubuntu stuff yet.
<jbailey> I'm not sure what it will mean for the commercial side.
<Kyral> Uhh...is there a problem with the latest Updates to Dapper?
<_lemsx1_> i was just going to say that artwiz-cursor is still broken (even though this is a well known issue and there is a patch for in in malone)
<Kyral> I meant something stopping X from loading
<Kyral> The updates to GTK?
<Amaranth> Kyral: bad gtk
<Amaranth> Kyral: very latest update fixes it
* Kyral winces
<Kyral> why is your name blinking!
<Kyral> lol
<Amaranth> should be available already
<Amaranth> i said your name
<_lemsx1_> Amaranth: do you know what version fixes it?
<Kyral> Amaranth: download in progress
<_lemsx1_> 2.8.13-1ubuntu3 ?
<Amaranth> _lemsx1_: yes
<_lemsx1_> Amaranth: thanks ;-) i just upgraded ;-)
<Kyral> Ahh thats better :D
<Kyral> ty Amaranth
<freeflying> Mithrandir: ping
<Mithrandir> freeflying: pong
<freeflying> Mithrandir: how can I set locale for dapper livecd 
<freeflying> Mithrandir: use debian-installer/locale ?
<Mithrandir> set it from the bootloader
<freeflying> thx
<siretart> infinity: re: gnome-screensaver: A workaround for that bug is to press  'alt-a' and move the mouse again
<Burgundavia> siretart: is that hte bug that causes the screensaver to come on every 2 minutes?
<siretart> Burgundavia: it is the bug that g-s-s looses focus so that the login screen doesn't appear
<Burgundavia> siretart: oh, fun. that is a different one
<siretart> Burgundavia: but very annoying and still in .92 :/
<tepsipakki> siretart: I can't reproduce it :)
<siretart> tepsipakki: here about 20% of every activation
<tepsipakki> siretart: the bug that I reported lost focus so that the dialog opened but you couldn't type in it. that is fixed now
<siretart> tepsipakki: in which version?
<tepsipakki> since .91 I think
<siretart> tepsipakki: I have 2.13.92-0ubuntu1 installed, and I say you the bug is NOT fixed yet
<tepsipakki> but you say that the dialog doesn't appear ;)
<siretart> right. the bug is that the dialog box doesn't appear. did I miss something?
<tepsipakki> I mean.. is it the same bug? does upstream know?
<siretart> tepsipakki: this is bug #29178
<Ubugtu> malone bug 29178 in gnome-screensaver "password dialog doesn't have focus" [Normal,Needs info]  http://launchpad.net/bugs/29178
<tepsipakki> which I reported
<tepsipakki> I think it is not the same
<siretart> ah, your bug was about the dialog appears, bug you cannot type anything in it
<tepsipakki> yes
<siretart> good point. in this case, I'll open another bug
<tepsipakki> upstream is _very_ active, you should contact them
<tepsipakki> (or him)
<siretart> tepsipakki: do you think #28202 fits the discription better?
<siretart> tepsipakki: who is upstream?
<tepsipakki> for starters, you can recompile g-s with debug-options, and send the errorlog to upstream
<sivang> mornign all!
<tepsipakki> siretart: William Jon McCann. File it on gnome bugzilla and he'll respond ;)
<tepsipakki> and link to launchpad
<tepsipakki> siretart: that bug might be it..
<siretart> tepsipakki: okay, I closed #29178 now, and changed title for #28202. This should make it more clear
<tepsipakki> siretart: yeah :)
<pitti> Good morning
<freeflying> hi pitti 
<sivang> pitti: Morning martin!
<sivang> hey freeflying 
<sivang> pitti: what do you do when you want to singnal that a file in a package needs to be removed? you upload a new source ?
<freeflying> sivang: hi
<sivang> (in a source package, that is)
<pitti> sivang: I don't understand - 'signal'?
<pitti> hi freeflying 
<sabdfl> elmo: still up?
<dholbach> good morning
<freeflying> dholbach: morning
<sivang> pitti: err, sorry, when creating a debdiff, how can I make it such it will , when applied remove a file I desire to be removed?
<pitti> sivang: ah
<pitti> sivang: apply it with patch -E
<pitti> hi dholbach 
<dholbach> hey freeflying, hey pitti
<sivang> pitti: but in the debdiff, it will still be there? I tried to create a debdiff for Chris Moore's fix  for flex (you are CC'd on the bug). He said we just need to drop skel.c from the source package, in order for it to be generated at build time.
<freeflying> dholbach: may I request UVF now ?
<dholbach> for something in main? universe?
<freeflying> in main 
<freeflying> scim-pinyin is 0.5.0 now , upstream is already 0.5.91 ,also has new feature 
<dholbach> then you have to write a mail to mdz and Kamion and justify your case - it might help to attach a changelog diff and diffstat (like we do in Universe)
<sivang> pitti: I created a debdiff for that and attached ot the bug report. not sure it's okay though.
<freeflying> dholbach: got it,thx
<pitti> sivang: that won't work, since the file is in the orig.tar.gz; don't worry, I'll fix it ASAP
<pitti> sivang: (you have to remove the file in debian/rules, before building)
<pitti> hey carlos 
<sivang> pitti: ah okay, thanks. That's what I wanted to actually know - how to handle this situation.
<sivang> pitti: I got the wrong impression you need to remove it from orig, but then figured it doesn't make sense since this has to represent the prestine copy right?
<pitti> right
<sivang> k, thanks.
<carlos> pitti: morning
<Kamion> scim-pinyin is in universe, not main (for the moment)
<Kamion> although it's on anastacia's promotion list
<dholbach> Kamion: does that mean you want the uvf exception to go through the motu uvf process?
<freeflying> Kamion: dholbach that's mean scim-pinyin just go though motu VF process?
<dholbach> freeflying: that's what I just asked. :)
<freeflying> dholbach: :)
<Zomb> I though Ubuntu porter would rebuild every package but it seems that nowadays the version is no longer changed so the filenames are identical with Debian's with different checksum... is that correct?
<dholbach> Zomb: the file name of the package and the rebuilding are separate things. we get *source* packages and build them - some filenames are the same.
<Zomb> dholbach: that is not what I asked. Do you _always_ change the version number or not? Because: different number, different filename, you know...
<dholbach> no we don't
<dholbach> Zomb: as i said: we import source packages
<dholbach> Zomb: if we do changes over debian's source packages, we change the version
<Zomb> so AFAICS your answer is: yes, we are creating Debian packages with identical filenames but different contents
<Zomb> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354925
<dholbach> Zomb: you have to distinguish between source packages and binary packages
<Zomb> dholbach: I have to, I do
<dholbach> Zomb: but yeah, that sometimes happens.
<Zomb> I am going to check the Packages files and file bugs
<dholbach> Zomb: bugs on what?
<Zomb> the incorrectly built packages?
<dholbach> Zomb: they are not incorrectly built
<dholbach> you just can't rely on filenames
<dholbach> hello mvo
<mvo> hey dholbach
<dholbach> mvo: this might be a nice case for you to talk about: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354925 - Zomb wants to file bugs for packages that have the same file name in debian and ubuntu but have different contents
<Zomb> dholbach: I can, I did and this has been working for years now
<fabbione> hmmmm
<dholbach> because people were using binary packages and didn't rebuild the source
<mvo> we shouldn't have those IMHO
<mvo> oh
<mvo> sorry
<mvo> nor awake yet
<dholbach> i have an interesting case: fabbione and I looked into a change in imake: this would result in hundreds of changed packages ,because of changed paths etc
<fabbione> Zomb: no i think the problem is different...
<dholbach> it's simply not a but in the package you're going to file a bug about
<dholbach> s/but/bug
<fabbione> Zomb: i am not sure how much you know ubuntu so you might excuse me if of some of the stuff i say is repetition
<fabbione> Zomb: we do not import binary packages from Debian. Only sources.
<fabbione> Zomb: now.. if we need to modify something in the source, this gets of course a different version
<fabbione> Zomb: if the source is unchanged, it gets rebuilded and hit our archive.
<fabbione> now
<Zomb> fabbione: I do not know much about the internal workflow beyond of the usual things we see on conferences
<fabbione> Zomb: ok.. i will try to explain, if it is unclear just ask me
<fabbione> once the package is rebuilt *without* changes
<Zomb> I guess I know what you do but I am not happy with it
<fabbione> the md5sum of the binaries cannot match
<Zomb> it is rebuilt and it changes the checksums of the package files
<Zomb> yes
<fabbione> exactly
<fabbione> but the content is the same...
<fabbione> if there are no source changes..
<HrdwrBoB> effectively
<fabbione> i am sure you get the point
<Zomb> but AFAICS there were no conflicts untill dapper
<HrdwrBoB> it's not "the same"
<Zomb> sure. And I don't like it, I would need to rewrite some parts of apt-cacher
<fabbione> Zomb: impossible.. because we did always rebuild from sources...
<fabbione> there is no way a binary can have the same md5sum
<Zomb> fabbione: but with changed version number, so different filenames
<fabbione> Zomb: let's step back a bit
<Zomb> I know, I know, even the slightes change (eg. other filesystem -> different space calc) will change the result
<fabbione> if we do change the sources, we do change the version
<fabbione> otherwise it stays as in Debian
<fabbione> yeps.. as you say..
<fabbione> but this has been always happening
<Zomb> fabbione: that was my complaint - apparently the version is sometimes not changed
<fabbione> from the first moment that we did open warty
<fabbione> Zomb: do you have an example package that i can verify?
<fabbione> if the package is synced from Debian automatically that error cannot happen
<fabbione> if it is human error.. well..
<fabbione> we can fix it
<fabbione> somehow
<Zomb> let me see
<Zomb> ah, the first one: http://packages.ubuntu.com/dapper/net/apt-cacher
<Zomb> not sure it has been rebuilt
<Zomb> well, let me run a uniq check on Packages file and I will come back RSN
<fabbione> sure
<fabbione> (just ping me when you are done)
<Kamion> freeflying: hmm, no, just run it past mdz and me
<Kamion> Zomb: FWIW this isn't new, it's been like this since warty
<Kamion> oh, fabbione already said that
* Kamion .insert(coffee)
<fabbione> Kamion: ehehe
<fabbione> Kamion: i have almost ready the first patch for partman for you to test
<fabbione> Kamion: s/test/& and look/
<Kamion> cool
<fabbione> Kamion: it is still rough, but if we agree on the implementation, than i can move faster to give you the schema and we can workout eyecandy later on
<fabbione> Kamion: do you have a netbootable i386 that you can use for it?
<fabbione> (or vmware)
<fabbione> or whatever
<Kamion> I have a suitable test system, yes
<fabbione> ok perfect
<fabbione> just testing one thing and i will prepare a test image for you
<Kamion> I can do the test image myself
* Zomb inserts coffee to
<Kamion> in fact it's easier for me if I do
<Kamion> just a diff is fine
<fabbione> Kamion: sure
<fabbione> you will need to have a custom build of partman-auto only for the template
<fabbione> otherwise you are good to go
<Kamion> I'm used to working around that particular cdebconf deficiency
<fabbione> yeps
<Kamion> if you don't mind editing random postinsts on the fly it's possible to deal with that without building a custom image
<fabbione> works.. 
* fabbione makes the diff
<fabbione> oh i also added multiline support :)
<Kamion> i.e. edit /var/lib/dpkg/info/load-cdrom.postinst and make it udpkg -i /tmp/*.udeb at the end
<Kamion> in what?
<fabbione> surprise ;)
<Kamion> fabbione: do you mean you're sending multi-line debconf commands?
<fabbione> no
<fabbione> still single line
<fabbione> but we can show more info on multiline
<Treenaks> multi-line text entry widgets in debconf?
<Kamion> erm
<Kamion> I hope not, that will royally confuse espresso
<Kamion> fabbione: I thought we agreed on a different approach
<Kamion> well, I'll look at what you have
<fabbione> Kamion: we can make that espresso/d-i specific
<fabbione> Kamion: i am still playng around to explore all the possibilities
<fabbione> http://people.ubuntu.com/~fabbione/pa.diff
<fabbione> have fun
<fabbione> it is hacked to show menus even with one disk only
<fabbione> i need that for testing
<Zomb> fabbione, Kamion: okay, forget it, there are hundreds of such packages
<fabbione> Zomb: no problem..
<Kamion> Zomb: every package that is source-unmodified from Debian will be like that
<Zomb> Kamion: sure
<Zomb> I just assumed this version-renaming has been one of the key strategies to make the difference clear in the filename
<Kamion> no, the addition of "ubuntuX" to versions denotes source changes
<Kamion> we discussed the situation with binaries way back in the day, and concluded that changing the filenames for even unmodified packages would be a grossly excessive amount of work given that apt doesn't care
<fabbione> Kamion: the only 2 things that work there are "Use biggest free space" and "custom". The menu when you select one specific device is the next step.
<Kamion> fabbione: $(($num_devices + 1)) is cheaper than $(expr $num_devices + 1)
<fabbione> oh that was it..
<fabbione> i couldn't rememberit
<Zomb> ok, Now it has hit me and I need a workaround. Of course the appearence of this problem was just a question of time, since people are free to push different debs with the same names into the world
<Kamion> indentation of the 'while [ -z "$targetdevice" ] ; do' loop is confusing
<fabbione> Kamion: i know.. i just hacked that up..
<fabbione> as i said it's rought.. tell me if you like the output
<fabbione> i will cleanup later..
<Kamion> ugh - are you going to keep the automatically_partition/... scripts in the long run?
<Kamion> please say yes
<fabbione> yes
<fabbione> there is only one we need from there
<fabbione> iirc
* fabbione checks
<fabbione> yes
<Kamion> I don't see why the others cannot be kept with a slightly different interface
<fabbione> i don't think we have any use of them, but yes i can slam them back
<fabbione> that's the less of the pain
<Kamion> we certainly do
<Kamion> the "Erase entire disk" option still makes sense, for example
<fabbione> i am not sure that having 3 scripts to do autopatiton $dev is worth, but yes sure..
<Kamion> I would like initial_auto to still use those scripts if at all possible, rather than merging their content into initial_auto
<fabbione> it's not really possible...
<Kamion> simply to minimise the complexity of the diff we have to carry forward
<fabbione> some of them have different meaning now
<fabbione> i know what you mean
<Kamion> I don't believe that some_device's meaning has changed drastically
<fabbione> no, but big_free yes for example
<Kamion> and custom is surely still custom
<Kamion> biggest_free should mean "biggest free space on this disk"
<fabbione> yes but it is not the same as when you show it from the main menu
<Kamion> that's the obvious meaning and it's still useful
<fabbione> we didn't have it before..
<Kamion> I realise that
<fabbione> we only had one biggest_free
<fabbione> yeah sure
<fabbione> let me get to the menu per hd
<fabbione> and i am pretty sure some stuff will come back
<Kamion> but going with this mpt-style disk selector, it makes sense for those operations to be disk-specific
<fabbione> right now i need to move one step at a time to avoid mass nuclear reactors detonation
<fabbione> this stuff.. is hmmm.. delicate? :)
<Keybuk> yes, please don't make it rain fabbione-kibbles down on us
<Kamion> aside from that, the general structure looks ok
<Kamion> I assume you only took /var/lib/partman/initial_auto out temporarily
<fabbione> Kamion: fire it up with a device that has some free space
<Kamion> my test machine is a bit occupied with other stuff right now
<fabbione> Kamion: not really.. i still need to see the point of it with the new menu interface
<Kamion> the point is that when you back out to the installer main menu and go back to partman, it's supposed to take you straight back to the advanced partitioner
<Kamion> on the basis that you already declined the automatic partitioning
<fabbione> than you have a problem when you go advanced and select "Guided partitioner" again
<fabbione> but that perhaps just how the code is arranged now
<Kamion> I don't see why? IIRC that bypasses initial_auto
<fabbione> and could be fixed
<fabbione> yes calling directly the debconf quesion
<Kamion> initial being, well, initial
<fabbione> but that doesn't have the code to understand the answer
<netstar> Does Dapper include a GUI installer?
<Kamion> fabbione: yes, you'd need to adapt partman-auto/choose_partition/auto/do_option too
<netstar> ppc does not I noticed, but heard some talk about it
<Kamion> netstar: it includes a GUI live CD-based installer
<Kamion> netstar: powerpc certainly does
<Kamion> on the live CD
<netstar> Ah ok
<Kamion> it doesn't quite work right for powerpc yet, but that's fairly easily soluble
<fabbione> Kamion: yes.. that's why i mentioned "core arrangement"
<netstar> You on ppc kamion?
<Kamion> netstar: typing on one
<netstar> :)
<fabbione> meh  make that code
<netstar> okay thanks, was the wrong channel window to ask...
<tepsipakki> Kamion: is "kbd-chooser/method" valid anymore? Can't find it from the sources, nor has it worked for me
<Kamion> tepsipakki: should be
<Kamion> there's a bug about kbd-chooser preseeding being b0rken though
<Kamion> ./debian/kbd-chooser.templates-in:42:Template: kbd-chooser/method
<tepsipakki> ok, will check
<Kamion> is certainly in there
<tepsipakki> hmm, not upstream
<Kamion> no, that one's never been upstream
<tepsipakki> ok.. the ubuntu version is not publicly available?
<Kamion> eh?
<Kamion> it's in the Ubuntu archive like everything else?
<tepsipakki> svn
<Kamion> apt-get source kbd-chooser
<Kamion> there's no revision control for it
<tepsipakki> yes yes ;)
<tepsipakki> ok
<Kamion> kbd-chooser/method was part of Matthias Urlichs' work on the keymap guess widget
<Kamion> upstream, you need to know your keymap architecture and use console-keymaps-at/keymap etc.
<tepsipakki> yes, that works
<Kamion> some of the kbd-chooser/method code is a bit problematic though, which is why it hasn't yet gone upstream - we've been gradually merging bits and pieces to make the diff less painful
<tepsipakki> I'll try to read it..
<netstar> Kamion what machine you running?
<fabbione> Kamion: testing all the changes you asked for :)
<netstar> It's just I found a semi-bug in the kernel for ppc
<Mithrandir> Kamion: I'm somewhat tempted to rewrite significant parts of kbd-chooser.
<Kamion> netstar: 15" albook, a couple of years old
<Kamion> Mithrandir: post-dapper? :)
<netstar> windfarm as modules have NO effect on this imac G5.  I haven't modularised another kernel but with 2.6.16-rc5 built in, the code works and fan control also works
<Mithrandir> Kamion: yes. :-)
<Mithrandir> Kamion: etch-ish, I think.
<Kamion> netstar: I'm not a kernel hacker, sorry; best talk to BenC (who has a G5, I believe)
<Kamion> or just file a bug on linux-source-2.6.15
<netstar> BenC, you around?
<tepsipakki> there's no "mydebconf_get" or similar in kbd-chooser
<Kamion> kbd-chooser (1.20ubuntu3) dapper; urgency=low
<Kamion>   * Get rid of mydebconf_get, since it's very insecure (uses strcpy onto a
<Kamion>     buffer of unknown size).  This should also cut our memory requirements
<Kamion>     a tiny bit.
<Kamion> why are you looking for it?
<Mithrandir> tepsipakki: mydebconf_ask is slightly less insane.
<tepsipakki> I'm just trying to figure out why it ignores a preseeded setting ;)
<Mithrandir> tepsipakki: oh, you're trying to preseed kbd-chooser?  That's tricky. :-)
<tepsipakki> but documented ;)
<Mithrandir> tepsipakki: I'm slightly scared of fixing it further, because it's so extremely brittle
<tepsipakki> if so, maybe the installation-guide should be fixed?-)
<Kamion> no, we have to fix kbd-chooser/method preseeding
<Kamion> there's no way around that
<Kamion> (or replace it with a different preseedable question if for some reason fixing kbd-chooser/method is impossible)
<Kamion> python's set type is great
<Kamion>         difference = live_packages - desktop_packages - apt_installed
<fabbione> Kamion: yeps.. new pa.diff for you with all the changes you asked...
<Kamion> +partman_newworld
<Kamion> there's a package called partman-newworld ;-)
<Kamion> could you make that newlayout instead of newworld?
<fabbione> Kamion: sure...
<fabbione> i called it newlayout.. in the beginning.. but i didn't like it :P
<Kamion> that looks nicer
<Kamion> you should just be able to call /lib/partman/automatically_partition/biggest_free/do_option $bigfree instead of replicating it
<Kamion> +       custom:)
<Kamion> that looks like a typo, stray colon?
<fabbione> nope.. that is correct
<Kamion> really? ok
<Kamion> could do with a comment then
<fabbione> it's the way the RET is parted 
<fabbione> parsed
<fabbione> yeah i can fix it easily...
<fabbione> right now i am trying to get stuff to work
<fabbione> and autosustain themself :)
<Kamion> otherwise looking pretty good, modulo my not having tested it
<fabbione> that's what i care the most..
<fabbione> (look at the UI)
<Kamion> ok, will do so once I finish off my current piece of work
<dholbach> hey seb128!
<seb128> hi
* Kinnison clearly didn't do very well after his first late night meeting
<fabbione> Kamion: sure.. new cleaned up patch as you requested Espresso All Mighty
<freeflying> Kamion: the d-i of flight-4 still can not display chinese fonts correctly
<Kamion> fabbione: :-)
<Kamion> freeflying: is there a bug filed about that?
<freeflying> Kamion: ya
<Kamion> freeflying: bug number?
<freeflying> Kamion: just a moment
<freeflying> Kamion: https://launchpad.net/distros/ubuntu/+source/bterm-unifont/+bug/31722
<Ubugtu> malone bug 31722 in bterm-unifont "some Chinese fonts can not be displayed  when I insdtalled dapper-install-powerpc using 20060213's iso" [Normal,Unconfirmed]  
<Kamion> freeflying: ok, I'll have a look
<Kamion> freeflying: ah, I see the reason, will fix
<freeflying> Kamion: cool  :)
<freeflying> Kamion: will ttf-arphic-uming and ttf-arphic-ukai be in ubuntu's install cd
<Kamion> I have no idea; I have not been involved in those discussions
<Kamion> if they're included in the desktop seed, they'll be on the CD
<doko> Kamion: I think we can unleash the new OOo binaries
<freeflying> Kamion: they are in kubuntu-desktop's seed now
<freeflying> doko: dose new OOo  fix #5981
<Kamion> freeflying: then they will be on Kubuntu CD images
<freeflying> Kamion: I know , how about ubuntu ? 
<Kamion> freeflying: they're not in the Ubuntu seeds
<Kamion> freeflying: this is not really anything to do with me - I just arrange for CD images to be built out of whatever the seeds say to put in them
<freeflying> Kamion:  :)
<freeflying> Kamion: then whom shall I poke 
<Kamion> freeflying: weren't you talking with pitti about it before?
<freeflying> Kamion: y, he told me that need cd space for them 
<Kamion> what's the size diff?
<pitti> Kamion: in the order of 10 MB IIRC
<Kamion> ouch
<Kamion> is there anything that can be done about that? that seems like an awful lot for fonts
<Kamion> freeflying: we could have avoided some confusion if you'd told me more from the start rather than parachuting me into the middle of the discussion and assuming I knew all about it
<Keybuk> seb128: weird...
<Keybuk> (totem:11982): GStreamer-CRITICAL **: gst_segment_clip: assertion `segment->format == format' failed
<Keybuk> seen that before?
<seb128> no
<seb128> when does that happen?
<arp> yep
<arp> I've been it
<arp> *seen it
<Keybuk> seb128: trying to play an mp3 file
<seb128> arp: did you file a bug?
<arp> You're missing libmad
<Kamion> pitti: do I understand correctly that these supersede the existing ttf-arphic-*?
<dholbach> gnome bug 331323
<pitti> Kamion: AFAIK yes
<Keybuk> arp: ? /usr/lib/libmad.so.0.2.1
<Ubugtu> gnome bug 331323 in gst-ffmpeg "[ffdec_mp3]  crashing while playing mp3" [Critical,New]  http://bugs.gnome.org/show_bug.cgi?id=331323
<pitti> freeflying: see Kamion's question ^ ?
<Kamion> bkkai00mp, bsmi00lp, gbsn00lp, gkai00mp
<arp> gstreamer plugins built against libmad
<freeflying> Kamion: we wnana use ttf-arphic-uming ttf-arphic-ukai replace those chinese fonts in main now 
<freeflying> pitti: y
<arp> It's a gstreamer/libmad issue.
<dholbach> gst-ffmpeg
<seb128> Keybuk: do you have gst-plugins-ugly0.10 ?
<arp> ty
<Kamion> I make the size difference 6.8MB
<seb128> Keybuk: gstreamer0.10-plugins-ugly rather
<Kamion> freeflying: do they have much better coverage, or do they look better, or what?
<Kamion> "wanna" isn't *traditionally* justification ;-)
<freeflying> Kamion: because look better
<Keybuk> seb128: ah, no
<Kamion> doko: not ignoring you BTW, just takes a while to process these
* mvo is back after replacing his router. networking should be much better now
<freeflying> Kamion: also coverage more 
<Keybuk> whatever happened to "You don't have the plugin to decode this" ? :)
<seb128> Keybuk: and you do have gstreamer0.10-ffmpeg?
<Keybuk> I know nothing says "I love you" like a core file ... but still
<arp> Keybuk, good question.
<seb128> Keybuk: it tries using the ffmpeg decoder which is bugged I think
<arp> plugins-bad (built with libmad support) will work
<seb128> arp: no need of that, -ugly does mp3 just fine
<Kamion> I think we can probably afford 6.8MB as things stand, given the number of Chinese speakers in the world
<Kamion> pitti: could you make that seed change?
<doko> Kamion: the openoffice.org-qatesttool is a source NEW, unrelated, but would be nice anyway
<Kamion> I'm busy trying to figure out why on earth gcj-4.1/i386 landed in NEW
<seb128> Keybuk: does installing it fixes the issue? Did you have gstreamer0.10-ffmpeg before?
<sivang> mvo: hi
<pitti> Kamion: sure
<Kamion> pitti: you could do it by merging r258 from the kubuntu seeds
<doko> Kamion: libgcj-doc
<Keybuk> seb128: dunno, apt is running now
<Keybuk> will tell you in ~2 mins
<freeflying> Kamion: and also edubuntu seed 
<seb128> Keybuk: k
<ogra> freeflying, how big is that ? 
<ogra> edubuntu olny has some kilobyte CD space left
<Kamion> freeflying: edubuntu is under much worse space pressure than the others
<freeflying> ogra: about 5M extra space 
<ogra> no way :(
<Kamion> doko: oh, of course, thanks
<Kamion> freeflying: 6.8M
<freeflying> ogra: Kamion :)
<freeflying> ogra: you'd help us for see native fonts better
<Kamion> freeflying: there are physical limits here
<ogra> if i'm really good, i can make 1-2M room, but that has very likely to be filled with docs 
<Kamion> native fonts are no good if you physically can't burn the CD
<Keybuk> seb128: what does -ffmpeg do that -bad/-bad-multiverse/-ugly/-ugly-multiverse don't do?
<Keybuk> (something must have needed me to install it)
<ogra> freeflying, note that edubuntu already defaults to 700MB isos
<seb128> Keybuk: gst-inspect ffmpeg
<freeflying> Kamion: anyway we'd solve that issue
<ogra> there is simply no space 
<Kamion> ogra: (so do the others now)
<Kamion> freeflying: how?
<ogra> oh, wow
<seb128> Keybuk: it makes easier to watch your p0rn with totem-gstreamer probably :)
<freeflying> Kamion: or we give you another font ? 
<Kamion> freeflying: I don't understand
<Keybuk> seb128: heh, most of my porn needs wmv v9
<Keybuk> which is frustratingly difficult to decode without win64 dlls
<dholbach> Keybuk: mine too :/
<seb128> right
<Kamion> freeflying: you say "we'd solve that issue". How? You say the issue is that we need these fonts, which are bigger, and won't fit on the Edubuntu CD images
<freeflying> Kamion: we are working on new font , maybe new one will be small than thpse two 
<freeflying> s/thpse/those
<Kamion> freeflying: that would certainly be nice
<Kamion> what kind of time are we talking about?
<Kamion> we're past feature freeze already
<freeflying> no more 2 weeks
<sivang> mvo: are you doing any process spawning in g-a-i ? I'm interested to know how you keep the gui responsive, is checking if there are pending gtk events, and then gtk.main_iteration()'ing until no more events are waiting is enough?
<Kamion> sivang: better to use gobject.io_add_watch()
<Kamion> doing events_pending/main_iteration is no good if the process that's running the GUI is blocking while trying to read/write stuff from/to its subprocess
<mvo> sivang: I create a worker thread that runs in the background and spawns the child. when it finishs it signals the gui
<mvo> sivang: Kamion has a valid point, watch out for blocking read/write
<sivang> Kamion: yes, I was already told about that, but I tried to keep the backend GUI agnostic, and glib/gtk free so it will be usable as a plain sell tool, but I guess there will ne no wait out of it. (pexcept does a really good job, but now I'm trying to solve a problem with a timeout expection when dar stays to long at adding a big file (for example, and avi file) and exceeds the timeout)
<sivang> mvo , Kamion : thanks.
<Kamion> sivang: add a frontend method that says "watch this fd in your main loop, whatever it may be"
<Kamion> or use a thread as mvo suggests
<sivang> the former acutally sounds very good , and is easily doable :)
<Kamion> doko: all done
<Kamion> doko: there's no openoffice.org-qatesttool in NEW
<Kamion> doko: http://librarian.launchpad.net/1598452/zqv1jZFFOdlUOGa51KLGsunebkD.txt
<Kamion> doko: please make any necessary adjustments to the seeds, if you haven't done so already
<doko> Kamion: didn't get a reject
* mvo goes to get some food
<Kamion> doko: indeed not, soyuz bug
<Kamion> well, launchpad-upload-and-queue
<sivang> Kamion: will it work correctly with a child's pty fd?
<sivang> (and not a "plain" fd)
<Kamion> sivang: gobject only cares whether it becomes readable/writable/whatever
<Soul_keeper> #linuxsociety  if you want ops jump in  
<Soul_keeper> #linuxsociety  if you want ops jump in  
<Soul_keeper> #linuxsociety  if you want ops jump in  
<Soul_keeper> #linuxsociety  if you want ops jump in  
<fabbione> Kamion: new pa.diff
<Soul_keeper> #linuxsociety  if you want ops jump in  
<Soul_keeper> #linuxsociety  if you want ops jump in  
<sivang> Kamion: cool, thank you.
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+b *!*@wsip-*.sd.sd.cox.net]  by fabbione
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<fabbione> Kamion: it should start to look more or less like mpt asked...
<freeflying> Kamion: I just mail u the diffstat of scim ?
<Kamion> freeflying: no, you don't
<Kamion> freeflying: you tell me what you're asking for first
<freeflying> s/scim/scim-pinyin
<Kamion> freeflying: upstream changelog, not diffstat; and mail it to both me and mdz
<freeflying> right
<Kamion> fabbione: I suspect those assignments inside the while read_line loop won't work; doesn't it create a subshell and then you lose your variable assignments?
<Kamion> fabbione: see resize_use_free which works around this by echoing out from inside the while loop and then parsing the output of the while loop
<fabbione> Kamion: what part of the patch?
<Kamion> +           while { read_line num id size type fs path name; [ "$id" ] ; }; do
<Kamion> +               if [ "$fs" = free ]  && ! longint_le $size $mysize; then
<Kamion> +                   mysize=$size
<Kamion> +                   mypart=$dev//$id
<Kamion> +               fi
<fabbione> yes i pass them out later
<Kamion> +           done
<Kamion> you've already lost them by that point
<Kamion> I suspect that the values of mysize and mypart will revert to their original values at the 'done'
<fabbione> what file is that?
<Kamion> because I believe that the inside of the while loop is executed in a subshell
<Kamion> partman_newlayout
<Kamion> also, about ten lines below that you have these printfs:
<fabbione> it uses the same technique as the others
<Kamion> +           printf "biggest_free: $mypart\t$RET\n"
<Kamion> +       printf "custom: fakeoption\t$RET"
<fabbione> they are all inside the loop
<fabbione> already hitted my head there
<Kamion> (a) when using printf you should use %s instead of variable interpolation to make sure that metacharacters in the variables aren't interpreted as format strings
<Kamion> (b) the second printf is missing a \n
<fabbione> (a) ok
<fabbione> (b) no. it is the last print we do
<Kamion> why not terminate with a \n anyway?
<Kamion> less confusing in case somebody comes along later and adds something else
<freeflying> Kamion: sent it 
<fabbione> Kamion: done both..
<Kamion> fabbione: all inside the loop> they aren't, the entire body of the relevant loop is as I pasted above, and then you use mysize/mypart outside that loop
<fabbione> Kamion: they are in the same subshell
<fabbione> it works :)
<fabbione>     choices=$(
<fabbione> [lot of code includeing mypart/myid] 
<fabbione>     )
<Kamion> it is common for while ...; do ... done to create a subshell for the second ...
<Kamion> it certainly does for while read; not sure about { read_line ...; }
<Kamion> anyway, just warning you that it's a possible issue to try to save you time in case that does turn out to be a problem
<fabbione> well that's the same code i did steal from a similar thing...
<fabbione> it was working there.. it's working here...
<Kamion> ok, fair enough
<fabbione> (a) and (b) updated
<Kamion> ta
<fabbione> i need some sleep now
<Kamion> you need to do the same %s thing with $RET
<fabbione> oh right
<Kamion> printf "biggest_free: %s\t%s\n" "$mypart" "$RET"
<fabbione> sec...
<sivang> sabdfl: hey mark
<fabbione> Kamion: updated.. 
* fabbione -> sleep
<fabbione> later
<Kamion> fabbione: thanks
<fabbione> Kamion: no problem. thanks to you
<StevenK> So, when is moin (the binary package) going to be punted out of dapper? doko uploaded a version of moin that replaces the monolithic package
<pitti> freeflying, Kamion: all seeds updated for new arphic fonts
<freeflying> pitti: thx
<Kamion> StevenK: package removal is broken at the moment, see https://launchpad.net/products/soyuz/+bug/32314
<Ubugtu> malone bug 32314 in soyuz "remove-package.py pretends to work and then does nothing" [Normal,Unconfirmed]  
<StevenK> Heh
<StevenK> "I would very much like the Ubuntu archive not to be in Hotel California mode. :-)"
<StevenK> Muahahaha
<Seveas>  You can remove any package you like, but they never leave  
<spiekey> hello!
<spiekey> can i use the http://www.debian.org/doc/maint-guide/ as well if i want to build packages for ubuntu?
<spiekey> is there a difference?
<spiekey> do you have a own paper?
<infinity> spiekey: We follow Debian policy (with perhaps a few very minor exceptions), so yes, the Debian New Maintainer Guide and Debian Maintainer's Guide are both good reading.
<arp> Is /usplash_fifo necessary?
<infinity> arp: Is it actually in / on your machine?
<arp> yes
<infinity> arp: If so, something very buggy and odd is going on.
<arp> interesting
<infinity> arp: Please file a bug, and I'll look at it later.
<arp> Okay will do
<infinity> arp: The file should be in /dev/.initramfs/
<arp> it's there too
<arp> well another one
<infinity> Rephrase: It should ONLY be there. :)
<arp> :) filing bug report now
<infinity> I can't imagine how it's also ending up in /
<infinity> Can you delete it and reboot and see if it comes back?
<arp> sure
<infinity> It may have been some weird transient bug long ago that created it...
<infinity> (timestamps on the file would be nice if you haven't already deleted it..)
<arp> lmao
<arp> rebooting...
<sladen> infinity: what's  ls -l /usplash_fifo give for the date (if you haven't deleted it)
<infinity> sladen: s/infinity/arp/ and I assume he deleted it before I asked that.
<infinity> sladen: (Are you lagged, or just confused?) :)
<sladen> infinity: nah, just stupid :)
* mvo does the switch to bzr for apt/python-apt finally
<StevenK> infinity: Is it a feature that the progress bar for usplash_down goes backward?
<infinity> StevenK: yes.
<StevenK> Just seemed strange to me.
<infinity> StevenK: That's very intentional, so you know that it's shutting down.
<arp> she's gone
<Mithrandir> I think it's very shiny.
<infinity> StevenK: Try hitting Ctrl-Alt-Del halfway through booting.
<infinity> StevenK: It's actually rather cool that it works.
<StevenK> Heh
<arp> infinity, no sign of that nasty pipe.
<sladen> StevenK: I think sabdfl wants it normal-way, but with inverted colours
<Keybuk> pitti: bug 33354, what do you think?
<Ubugtu> malone bug 33354 in udev "no permission to use joystick" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/33354
<infinity> arp: Right.  If it comes back, then by all means, file the bug.  If it never does, I'll assume it was a one-time oddity and blindly ignore it. :)
<arp> sounds good.
* ogra remembers his promise to Keybuk to test his joystick ...
<StevenK> Actually, the messages for booting are good, but they seem to be the usual message for the way down.
<infinity> sladen: He asked for inverted colours, he didn't tell me anything about inverting the direction.
<Mez> infinity, did you get Eugenes reply ?/
<infinity> Mez: Yeah.  Sucks, but whatever.  It was a long shot.
<pitti> Keybuk: hm, I don't have any experience with joysticks, but if the reporter noticed it, then some app probably reads from the device instead of from X
<Mez> indeed it was
<Keybuk> pitti: yeah, I thought they were supposed to go through X too
<Keybuk> is there a group for the "user at the console" that isn't just "plugdev" ?
<pitti> Keybuk: hm, depends whether we consider it a security risk to spy on or forge joystick events
<infinity> sladen: Anyhow, both direction and colours are easy enough to play around with, so we can fiddle without wasting too much time to find the "sweet spot".
<pitti> Keybuk: we don't have a group for 'at console', that doesn't work
<ogra> cant we add users to "games" ?
<ogra> and make that one own js0 ?
<pitti> Keybuk: plugdev would work for me
<ogra> i imagine there are quite some games using the device 
<pitti> ogra: no
<infinity> I don't see how joysticks are any more special than a USB mouse, eg.
<pitti> ogra: doesn't games already exist?
<ogra> pitti, yes
<pitti> it's for sgid programs to write highscores
<ogra> but no user is added to it 
<infinity> They're essentially the same sort of device, with a different interface.
<pitti> users shouldn't be in that group
<pitti> infinity: but spying mouse events can be more security relevant than spying joystick events imho
<pitti> at least if you assume that joysticks are only used for games
<infinity> Unless you use a joystick as your mouse device (which I've seen done)
<pitti> ok, that falsifies my assumption then :)
<dholbach> pitti: you should patch adduser to insult the user as "cheater" if they add add users to the games group ;)
<ogra> hehe
<pitti> Keybuk: so, in the end, the games should just be fixed to read from X?
<infinity> Almost certainly but how many games are we talking about here?
<pitti> no idea
<Keybuk> pitti: no idea
<arp> things like zsnes and snes9x
<infinity> For reference, in the static /dev world (on my woody machine, with a ./MAKEDEV-created /dev), /dev/input/js* are root:root, 660 as well.
<infinity> So this isn't a new udev bug or anything.
<pitti> Keybuk: btw, do you have any idea why some modules are not loaded any more with the latest kernel? (e. g. my pcspkr, or the 'floppy' module in a bug of mine)
<Keybuk> pitti: because there's nothing to load them
<pitti> Keybuk: hm, but that worked with the earlier kernel version
<Keybuk> $ modinfo pcspkr | grep alias
<Keybuk> $ modinfo floppy | grep alias
<Keybuk> no mapping to hardware
<Treenaks> Keybuk: isapnp floppies? 
<Keybuk> pitti: random ... what's in /sys/bus/pnp/devices for you?
<Keybuk> cat /sys/bus/pnp/devices/*/id
<pitti>   /sys/bus/pnp/devices/ is empty
<Keybuk> heh
<Keybuk> I only get two devices in there
<Keybuk> when I used to get dozens
<pitti> but pnp, isn't that ISAish?
<ogra> nope
<Keybuk> pitti: yes
<Keybuk> pnp == isa
<ogra> err, what ? 
<infinity> I've never seen a PCI floppy controller.
<ogra> but i've seen pnp PCI cards 
<infinity> Most machines with a floppy controller have a legacy ISA bus just for that.
<Keybuk> ogra: no, you haven't
<pitti> I banned ISA as well as floppies from my machines :)
<infinity> ogra: No, PCI is plug and play by design, but not PnP.
<Keybuk> infinity: and the serial interface :)
<ogra> Keybuk, i have a PCI pnp isdn card here ...
<Keybuk> pitti: then I hope you ripped out the ISA bridge <g.
<Keybuk> ogra: no, you don't
<zakame> evening all
<ogra> Keybuk, yes i do :) its very old though ...
<Robot101> ogra: PCI includes the autoconfiguration behaviour
<Keybuk> ogra: no, you don't
<pitti> Keybuk: no, it's still there, but I don't have any isa slots on the MB
<Keybuk> ogra: trust me :)
<infinity> ogra: PnP is a hack protocol used to make ISA behave sort of (but not entirely) like PCI.
<Robot101> ogra: PnP is a hack to autoconfigure on ISA
<pitti> Keybuk: probably really just for an optional floppy
<infinity> ogra: PCI autoconfigures by design, so doesn't need said hack.
<ogra> Keybuk, then its intresting that i need pnpdump/isapnp to get it working :)
<pitti> that's probably just marketing speech :)
<Treenaks> a PCI-to-ISA bridge on a PCI card?
<Treenaks> OMG
<ogra> i also have a PCI soundcard that needs isapnp ...
<pitti> scary
<infinity> Treenaks: Well, PCI-to-16-bit-PCMCIA (which was an ISA extension) is common, so why not PCI-to-ISA (though, ew)
<ogra> they might be cornercases, but both exists...
<Treenaks> ogra: german hardware... ;)
<infinity> ogra: Both are ISA devices, regardless of the interface.  They have bridges on them.
<mjg59> ogra: What sort of card?
<infinity> (And, as mentioned: Eww)
<ogra> mjg59, a taiwanese audio card, once been fully proprietary i need to dig it up for the name ...
<ogra> and an old fritz PCI isdn card
<sabdfl> StevenK, sladen: yup, just to be difficult :-)
<sabdfl> normal way, inverted colours
<sabdfl> can we put a one-pixel border around the usplash progress bar?
<freeflying> pitti: is scim in ubuntu's seed
<ogra> infinity, i agree but they both have PCI interfaces :) 
<Keybuk> ogra: as infinity says, that means you have an ISA isdn card that just happens to be on a PCI-to-ISA bridge PCI card
<Keybuk> it's not a "PCI pnp card"
<Treenaks> \o/ More moviegotchi-fodder (my Ubuntu-using colleagues just 'volunteered'
<spiekey> from the manual: http://pastebin.com/580031
<Keybuk> I've hard of those
<Keybuk> they're pretty rare though
* StevenK hands Keybuk an 'e'
<Keybuk> most hardware companies prefer to put a PCMCIA card on a PCI-to-PCMCIA bridge
<Mithrandir> sabdfl: just extend the background of the progress bar one pixel in all directions without expanding the filler?
<Keybuk> which is just as evil
<ogra> Keybuk, they are from the time when ISA dies and PCI was very young
<ogra> *died
<spiekey> in my case i havent got a source file. i only have a self written script.
<spiekey> do i still tar it and follow the documentation?
<Keybuk> ogra: indeed, I had a pnp sound card that fitted in a PCI socket
<Keybuk> in fact, I still probably do in a box
<Keybuk> but it's not a PCI sound card
<infinity> sabdfl: We can border it, I'm not sure if I agree that it would look better at that point.
<pitti> freeflying: no, just in supported for now
<sabdfl> infinity: will ask artist to look at this during UI sprint, i just want to know if it's quick and easy to do if that's a yes
<ogra> Keybuk, for the user who bought it as one and who plugged it into his mainboard it is ;) 
<Mithrandir> sabdfl: it's easy to do.
<infinity> sabdfl: Most of these changes are trivial, though, and I'd like to see some dapper splash artwork (AndyFitz promised me a full set for {X,K,Ed,}ubuntu) before we fiddle too much.
<freeflying> pitti: it will be before releae ?
<infinity> sabdfl: The border would just be part of the artwork.  Inverting colours and direction are trivial packaging/code changes.
<pitti> freeflying: does it make sense without any modules?
<Mithrandir> infinity: can we have small, marching penguins too? :-)
<sabdfl> infinity: i'd lke to see the andyfitz stuff, we have a professional guy due to be around to help too, so the more we have up to date for him to look at the better
<infinity> Mithrandir: Die.
<dholbach> yay!
<sabdfl> Mithrandir: lemmings-while-you-boot?
<dholbach> sabdfl: oh yes, please!
<Treenaks> sabdfl: ooh! with the wavy green hair!
<Mithrandir> sabdfl: you haven't seen the SUSE boot screen? :-)
<freeflying> pitti: it needn't module in install cd
<infinity> sabdfl: Can you make that same request <points above> to my INBOX, and I'll bug Andy tomorrow after I've rested?
<Keybuk> ogra: but we're above those users, and when we're talking about bus protocols and card types, we use the *right* terms :
<Keybuk> :)
<pitti> freeflying: I mean, does it do anything interesting without any module?
<Keybuk> anyway
<Keybuk> that was an entertaining tangent
<freeflying> pitti: nothing
<Keybuk> back to the more interesting problem that pnp support is broken
<ogra> yeah
<Keybuk> does anybody have anything much in /sys/bus/pnp/devices today?
<infinity> sabdfl: Andy and I being (more or less) in the same timezone should make the bugging reasonably easy.
<pitti> freeflying: hm, so what would be the benefit of having it in desktop?
<zakame> hmm
<infinity> On that note..
* infinity heads off to bed for real this time.
<Mithrandir> Keybuk: 12 entries on vawad
<Mithrandir> (but that's a hoary kernel, no idea if that's important)
<ogra> mjg59, the card was from a company called aureal
<Treenaks> ogra: Aureal Vortex?
<Keybuk> Mithrandir: current kernel
<ogra> yes, a very early one  ... vortex150 or so was the correct name
<freeflying> pitti: just need langiage-pack(depend on scim module) installed it can works , or you can make langauge-pack depend on scim/skim
<Mithrandir> Keybuk: empty on golem (which has the same mobo, etc)
<Keybuk> ok, good
<freeflying> pitti: it seems not only CJK user need scim ,but also others
<pitti> freeflying: ah, right, we need it for the scim | skim selection, i. e. ubuntu-desktop -> scim, kubuntu-desktop -> skim
<freeflying> pitti: ya
<Keybuk> pitti: please file a kernel bug, probably describe it something like "/sys/bus/pnp/devices is empty" and explain that this is very silly, and older kernels show a dozen or so devices, and this is why pcspkr, floppy, etc. aren't loaded for you
<sladen> ogra: sweet card;  proper hardware 3d card onboard
<pitti> Keybuk: ah, thanks
<ogra> sladen, it took almost a year to get it going back then, they offered no driver at all when i got it ..
<ogra> later there was a proprietary one ...
<freeflying> Kamion: how about the UVF of scim-pinyin , i've sent u the changelog
<Kamion> freeflying: look, it's only been less than an hour since you sent the mail and I am very busy with other work. Please be a bit more patient.
<Keybuk> pitti: what bug# did you file?
<freeflying> Kamion: hehe , I just expect a better CJK suport dapper 
<pitti> Keybuk: none so far, I'll add the comments to bug 33359
<Ubugtu> malone bug 33359 in linux-source-2.6.15 floppy-modules-2.6.15-16-amd64-generic-di "Floppy module not loaded on boot; no /dev/fd0 created" [Major,Unconfirmed]  http://launchpad.net/bugs/33359
<desrt> do people still have floppy drives and expect to use them?
<Kamion> freeflying: just please let me do other things, I can't be doing UVF exceptions and archive maintenance all day long because I have my own goals and they're very substantial
<desrt> crikey
<irvin> desrt, unfortunately yes
* desrt dons his trusty usb key
<freeflying> Kamion: :)
<pitti> Keybuk: sub'ed you and added comment
<desrt> my sister's teacher actually told her class to use floppy disks because usb keys are unreliable
<pitti> lol
<Treenaks> desrt: uh... maybe because you need a different driver for every USB key in windows?
<desrt> Treenaks; surely this isn't true
<Treenaks> desrt: it isn't?
<desrt> Treenaks; i'm pretty sure it's not
<Treenaks> desrt: last 3 keys asked for a driver disk on XP for me
<desrt> Treenaks; i've never experienced this when plugging my key into windows
<Treenaks> desrt: but that might be HP OEM windows brokenness
<desrt> Treenaks; who knows
<Keybuk> there are several digital camera drivers which break the windows usb storage driver
<Treenaks> Keybuk: great, more good advocacy points 
<slomo_> infinity, lamont: please give-back tomboy on amd64... thanks :)
<desrt> mjg59; oh man that's a bad picture
<desrt> mjg59; when that was taken, were you a communist yet?
<torkel> slomo_: wouldn't it be easier to do a new upload of tomboy and enable the evolution (and galago) plugins. That Should give you free rebuild on amd64, shouldn't it? :-))
<desrt> torkel; only if he enabled the fixed width font plugin at the same time, natch.
<slomo_> torkel: you write a main inclusion report for galago-sharp and get pitti to approve the one for gmime2.1, get both promoted to main and i enable the plugins... what do you think? ;)
<torkel> slomo_: ah, that's the issue...
<slomo_> torkel: yes... but maybe the evolution plugin will be enabled for dapper... we'll see
<slomo_> Kamion: please promote mono-tools, nunit and nant to main... main inclusion reports were approved by pitti some days ago
<infinity> slomo: Done.
<slomo> infinity: thanks
<AlinuxOS> pitti, around ?
<pitti> AlinuxOS: yes, but veeery busy
<AlinuxOS> pitti, ;)
<AlinuxOS> ok
<Keybuk> bah, I so need to change debian-changelog-mode to not default to "unstable"
<Mithrandir> Keybuk: that'd be useful
<Keybuk> otherwise my uploads keep escaping from the main loop, and need a Tommy Lee Jones sound-a-like to chase them across open ground
<Kamion> Mithrandir: could you merge http://people.ubuntu.com/~cjwatson/bzr/casper/mountpoints/ please? (or do you want a mail?)
<Mithrandir> Kamion: do you want an upload too?
<Kamion> Mithrandir: would be nice
<Kamion> then once infinity does his magic and I mirror it in cdimage we'll have espresso installing a plain desktop without live-only junk
<Mithrandir> Kamion: merged, pushed, uploaded.
<Kamion> cheers
<Mithrandir> tripleverb!
<Mithrandir> :-p
<jsgotangco> lol
<Mithrandir> it should probably be something like: bzr -- merge, push, upload!
<ploum> Hello.
<ploum> OOo 1.1 will not be in Dapper anymore ?
<Kamion> ploum: no
<ploum> Hmmm.. That's annoying because some bugs prevent some people to use OOo 2
<Treenaks> ploum: like?
<Kamion> perhaps it's time to move on - we can't support two enormous software stacks forever
<ploum> like the printing dialog bug
<ploum> I'll try to find it
<zakame> hm yet another Roman innovation
<ploum> Kamion: https://launchpad.net/distros/ubuntu/+source/openoffice.org2-amd64/+bug/26567
<Ubugtu> malone bug 26567 in Debian "Cannot use "brochure" printing options as intended" [Normal,Unconfirmed]  
<ploum> http://librarian.launchpad.net/1512708/ooo.png : screenshot
<Kamion> hey, I'm not the oo.o maintainer
<ploum> It's just to tell you I'm not kidding ;-)
<ploum> Maybe it can be possible to still have some openoffice.org1.1 packages availables
<Kamion> you should be able to install them from breezy
<fabbione> re
<ploum> Kamion: no because the name conflict
<Kamion> ah
<Kamion> still, I'd really rather we moved on and just fixed the top oo.o2 issues by dapper if possible
<Kamion> a pile of separate packages would end up being effectively unmaintained
<ploum> Kamion: I understand
<Kamion> and breezy will still be supported for some time
<Kamion> (if need be)
<ploum> What about putting OOo 1.1 in universe ?
<seb128> ploum: that's like saying "we should ship GNOME 1.n because GNOME 2 has some bugs atm" :)
<Kamion> I mean obviously doko might disagree with me on all of this
<Kamion> ploum: that's a given anyway, it wouldn't be in main
<Kamion> my replies above assumed universe
<ploum> ok
<ploum> seb128: the main difference is that ATM, OOo 2 is not usable at all for some people
<seb128> ploum: seems a strong assumption, is that known by upstream?
<ploum> seb128: I talked about it upstream
<ploum> it seems that it's not an upstream bug
<ploum> but just a bug from the compilation/package
<Kamion> well in that case it should be amenable to being fixed
<zakame> ploum: openoffice.org (1) is already in universe
<ploum> I talked with a developper who doesn't have this bug and was astonished by the screenshot
<Kamion> zakame: not any more it's not
<ploum> zakame: my bad ;-)
<seb128> ploum: what you are saying is that we have a distro bug
<seb128> ploum: and instead of fixing it you recommand to ship OO1?
<Kamion> zakame: as of today, openoffice.org is version 2 and supersedes it
<ploum> seb128: "I think" that's a distro bug
<seb128> is http://librarian.launchpad.net/1512708/ooo.png tour issue?
<zakame> Kamion: grrr, /me has to apt-get update again
<seb128> from the bug
<seb128> "  The printer-properties-disable patch that is applied during the build process removes the Orientation property from the options."
<AlinuxOS> eh
<AlinuxOS> :(
<seb128> so that's just a patch to drop
<AlinuxOS> mjg59, ping
<Lathiat> mjg59: ping too, need to fix this synaptics issue.. any chane to test those settings?
<Lathiat> has anyone else here got a real synaptics touchpad?
<Kamion> Keybuk: um, you do too have type in busybox
<Lathiat> (not an alps)
<AlinuxOS> I'm talking with people on #gtk+ nad #freedesktop, but noone knows howto fix this problem...
<Kamion> Keybuk: it's built unconditionally in ash
<AlinuxOS> every person tells me that I must file the bug for my distribution :(
<AlinuxOS> I don't know howto solve this problem.
<Keybuk> Kamion: well, it wasn't working :)
<Treenaks> hmm.. why did Gimp lose its Print dialog? (i.e. is this intended?)
<Keybuk> changing to just -x /sbin/usplash_write fixed the problem
<fabbione> AlinuxOS: you are 1) talking about a known bug 2) it's upstream and it's written in the upstream changelog
<Kamion> Keybuk: bizarre, since the installer uses it liberally
<Keybuk> oddness
<Kamion> Keybuk: could be your $PATH is wrong?
<Keybuk> syndicate scott% /usr/lib/initramfs-tools/bin/busybox type
<Keybuk> type: applet not found
<AlinuxOS> fabbione, is it known bug ? 
<AlinuxOS> I don't really know this :)
<Kamion> Keybuk: busybox sh, then use type
<Kamion> Keybuk: it's a builtin
<Keybuk> Kamion: weird
<Keybuk> *shrug*
<fabbione> AlinuxOS: aren't you talking about synaptic speed being "too slow"=
<fabbione> ?
<Kamion> kind of has to be a builtin
<AlinuxOS> fabbione, ;) No
<Kamion> "how would the shell interpret this command?" "er, dunno"
<fabbione> AlinuxOS: ok. open a bug than
<AlinuxOS> fabbione, I'll do it :)
<AlinuxOS> If it helps I'll do it :)
<fabbione> AlinuxOS: it only depends if i will get to look at it end of next week or not
<AlinuxOS> fabbione, are you a fontconfig master ?
<Keybuk> Kamion: either way, the "type usplash_write" was returning false
<AlinuxOS> if yes I hope that you can fix it...
<fabbione> AlinuxOS: no
<Keybuk> (at least, an echo in that block didn't get printed)
<fabbione> AlinuxOS: font -> desktop team
<AlinuxOS> fabbione, ok :)
<AlinuxOS> fabbione, Grazie!
<Kamion> Keybuk: right, hence my suspicion of $PATH
<AlinuxOS> fabbione, do you speak Italian too ? :)
<Keybuk> no idea what $PATH is in initramfs
<fabbione> AlinuxOS: yes you already asked, but i don't do it in a public english chan for respect to other readers
<Kamion> it doesn't set it, so it's probably the kernel's default for new processes, which IIRC is /usr/bin:/bin
<AlinuxOS> fabbione, right :)
<AlinuxOS> I understood this :) And now I'm trying to speak english everytime (even bad english)
<seb128> fabbione: "font -> desktop team", hum ...
<fabbione> ain't X bug
<dholbach> fabbione: it's a kubuntu bug as well if you discuss like this ;)
<seb128> fabbione: no, right, is fontconfig stuff, but do we have any fontconfig dude?
<fabbione> sure :)
<fabbione> seb128: no
<fabbione> that's why you win
<ploum> it seems I've found a xchat-gnome crasher
<seb128> I don't know enough about it to do changes happely
<fabbione> neither do I
<fabbione> but you are cooler than me on desktop :P
<seb128> best way is to try the list imho
<dholbach> ploum: http://wiki.ubuntu.com/DebuggingProgramCrash
<seb128> it's likely nobody will take over the bug on launchpad
<seb128> fabbione: that's right :)
<fabbione> seb128: see.. so you win :)
<seb128> :p
<pitti> smurf: ping
<Keybuk> was xchat-gnome deliberately de-seeded?
<fabbione> yes
<Keybuk> but xchat hasn't been seeded?
<fabbione> it has been
<fabbione> no?
<Keybuk> not here it hasn't
<fabbione> ah no it was from universe
<pitti> Keybuk: it was decided that we don't need  an IRC client in desktop
<Keybuk> *blink*
<pitti> well, IRC is for power users anyway
<Keybuk> most of our users are still power users, no?
<Keybuk> can we de-seed openoffices too? :p
<Mithrandir> tetex should be enough for everybody
<ogra_> pfft, who needs formatting ...
<ogra_> .txt should suffice
<Keybuk> Terminal is for power-users, can we drop gnome-terminal? :)
<Treenaks> ogra_: then we can dump the shiny of gnome too
<ogra_> Treenaks, as long as we keep vim :)
<Treenaks> ogra_: nvi
<Mithrandir> ogra_: you have gedit.
<ogra_> Mithrandir, ah, true ...
<Kamion> fabbione: well, that seems to work (partman-auto)
<Kamion> fabbione: going back from the per-disk menu doesn't do the right thing
<Mez> hmm
<Mithrandir> infinity: couldn't the initramfs set a useful PATH?  It's less silly than hardcoding paths all over the place.
<Mez> I cant reply to emails in thunderbird
<Kamion> fabbione: and I do think the multi-line thing is confusing - unless we put blank lines between each block, and make sure that pressing Enter when the cursor is on the device info line(s) selects the corresponding disk
<Kamion> fabbione: but I've got a feeling that's going to chomp a bit too much vertical space
<fabbione> Kamion: no i don't handle go back yet..
<fabbione> Kamion: so.. ok we kill the "device info thing"
<fabbione> Kamion: it's just a static printf now.. but the code can stay.. it's harmless
<Kamion> yeah
<fabbione> just in case they change their mind
<Kamion> I think sticking the extra info into the description at the top of the next screen will work well, looking at this
<fabbione> ok..
<Kamion> you know partman-auto-lvm needs to be adjusted too, I imagine
<fabbione> yes i do
<Kamion> I guess you can cope with that one ;-)
<fabbione> yeps
<fabbione> that's dead easy
<Kamion> haven't tried any of this in espresso yet, this is just looking at it in d-i
<fabbione> did you notice that i did change very little choices?
<Kamion> I think it makes the main menu rather more comprehensible in the multiple-disk case, actually
<Kamion> yeah
<fabbione> they don't lose compatibility
<Kamion> very few string changes => good
<fabbione> i am trying to reuse as much as i can
<Kamion> might want to check that the preseeded recipe path still works
<Kamion> iirc that preseeds partman-auto/disk
<fabbione> i doubt
<fabbione> oh
<fabbione> that one does
<fabbione> i didn't change that part of the code
<Kamion> hey, why don't you use partman-auto/disk rather than partman-auto/newlayout/select_dis
<Kamion> k
<Kamion> it's more idiomatic and would make preseeding work in the really obvious way
<fabbione> yes that's ok..
<fabbione> i wanted to keep the changes as obvious as possible for your approval
<fabbione> ok anyway we agree.
* fabbione gets to work
<Kamion> I think it might actually be even simpler if you worked it into the existing code that db_gets partman-auto/disk
<Kamion> but anyway, yeah - I have to go to take the child to a music lesson
<Kamion> I'll take my laptop with me and do some work there
<Keybuk> dpkg: dependency problems prevent configuration of ia32-libs-openoffice.org:
<Keybuk>  ia32-libs-openoffice.org depends on ia32-libs (>= 1.4ubuntu10); however:
<Keybuk>   Version of ia32-libs on system is 1.4ubuntu7.
<Keybuk> hmm
<Keybuk> (ia32-libs was scheduled in the same run, and configure --any after made everything happy)
<marcin`> hi developers
<marcin`> do you know that gksu package in dapper is currently broken?
<marcin`> is that known issue or need to file bug to malone?
<ogra_> seb128, ping
<seb128> ogra_: pong
<seb128> reply to my eog comment? :)
<ogra_> seb128, i'm sitting in front of the gthumb source currently
<seb128> ah
<ogra_> nah, already moved on :)
<ogra_> it cpoies the totem-scrsaver.c file directly from totem
<ogra_> ito its own source
<ogra_> *copies
<ogra_> i want to add gss handling, it would be tempting to simply use the new totem-scrsaver.c from totem, but that would add a dbus dependency to gthumb ... which doesnt seem right
<ogra_> an alternative would be to use a similar approach the eog patch uses ...
<ogra_> seb128, any opinion ?
<seb128> eog approch sounds better
<seb128> it's much simplier
<ogra_> i think so as well
<seb128> using dbus seems overwork
<seb128> and bug proof
<ogra_> i tried to avoid adding other approaches than already used for all apps i touched this week ...
<ogra_> but here it seems feasable to leave that path
<ogra_> thanks then ...
<ogra_> s/touched/touched for gss compatibility/
<seb128> np
<ogra_> Kinnison, my g-p-m suddenly tells me every 10sec that my battery is full, looks suspicious like bug 32650 just with another message
<Ubugtu> malone bug 32650 in gnome-power-manager "g-p-m notifies me every second that my battery is running out" [Normal,Confirmed]  http://launchpad.net/bugs/32650
* Keybuk giggles at the ipw3945 driver daemon
<Keybuk> ogra_: it could be worse ... my phone not only alerts me the battery is running low every few minutes, but to do so it turns on the display, plays an animation and plays a sound ...
<Keybuk> "if your battery wasn't low, it is now!"
<ogra_> nomeata, its fully charged 
<ogra_> it alerts me about having a fully charged battery :)
<Kinnison> ogra_: Hmm, can you please get a gpm trace and attach it to that bug showing it repeatedly re-notifying?
<ogra_> s/nometa/no/
<ogra_> Kinnison, trying
<ogra_> .. i fear it will go away if i try to re-run g-p-m
<Keybuk> strace -p
<Kinnison> Keybuk: not useful
<Kinnison> ogra_: yeah, that's the issue I've been having recently
<Keybuk> gdm -p ?
<Keybuk> uh, gdb!
<ogra_> lol
<Kinnison> ogra_: I've taken to running g-p-m in --no-daemon --verbose mode all the time writing to disk
<Kinnison> Keybuk: again not useful
<Kinnison> Keybuk: if it's not in verbose mode, it won't be generating the trace messages
<ogra_> Kinnison, will do that for the future 
<doko_> Mithrandir, jbailey: can you remember why to include the gtk1.2/glib1 libs in ia32-libs?
<Mithrandir> doko_: hysterical raisins
<Mithrandir> doko_: ia32-libs is pre-gtk2. :-P
<ogra_> Kinnison, hmm, gdb -p <pid> has stopped it ... intresting
<Kinnison> ogra_: urgh
<Kinnison> ogra_: I remember commenting a week or so ago that g-p-m was by far and away the most delicate system I'd ever seen wrt. debugging
<doko_> Mithrandir: ok, then I'd like to take them out, so they don't land on the CD. if somebody cries, then we can make a ia32-libs-gtk1 package
<Kinnison> the moment it gets enough of an observer, the bugs go away
<ogra_> yeah 
<ogra_> seems it hangs completely now 
<Kinnison> heh
<ogra_> hmm
<ogra_> unattaching gdb and it reappears
<Kinnison> you did let gdb continue didn't you?
<ogra_> with c ?
<ogra_> yes
<Kinnison> how odd
<ogra_> yup
* Kinnison is off for some lunch/tea
<Kinnison> I'll be back in an hour or so
<lemsx1> hello all
<lemsx1> error opening security policy file /etc/xserver/SecurityPolicy
<seb128> hi
<seb128> launchpad.ubuntu.com
<lemsx1> this is the second box that i get that message when trying to use any X app
<lemsx1> seb128: malone?
<seb128> yep, send a bug if there is none about it yet
* lemsx1 searching...
<dholbach> lemsx1: file a bug in malone (http://launchpad.net/malone/distros/ubuntu) 
<sivang> lemsx1: if there is a bug already, see what new light you can shed on this problem that hasn't yet already, to assit in tracking it etc..
<lemsx1> sivang: there is one
<lemsx1> bug #33400
<Ubugtu> malone bug 33400 in xorg "/etc/xserver/SecurityPolicy" [Normal,Unconfirmed]  http://launchpad.net/bugs/33400
<lemsx1> sivang: i usually just do a symlink to /usr/lib...SecurityPolicy... hold. i'll add notes
<sivang> lemsx1: cool, thanks.
* lemsx1 added
<lemsx1> sivang: i'm guessing the "right" location for this should be /etc/X11/xserver/SecurityPolicy, as done by xserver-common: /etc/X11/xserver/SecurityPolicy
<Diablo-D3> I can't seem to find this documented anywhere...
<Diablo-D3> but if "apt-ftparchive packages directory | gzip > Packages.gz" has Packages.gz for the packages command, is Source.gz the valid filename for the source command?
<Diablo-D3> apparently, it is 
<lemsx1> people loves asking first, researching later uh... 
<lemsx1> (me included of course. lol)
<Diablo-D3> does anyone have any webspace that isnt on sf.net that I could temporarly upload a bunch of debs for ubuntu?
<mjr> What's temporary, and "yes", if by uploading you mean "arrange for me to get them via some means" (can't dish out ftp access or anything). Plus if it's in the hundreds of megs max.
<Diablo-D3> mjr: until ubuntu universe gets them (which may be awhile)
<Diablo-D3> and I think the whole bunch is less than 20 megs
<mementor> is gksu package broken?
<Diablo-D3> mementor: not quite
<Diablo-D3> mementor: it randomly wants to upgrade correctly
<mjr> Diablo-D3, well, I can host it at mjr.iki.fi then, as said, if you can send them to me somehow, via dcc possibly
<mementor> i just tryied to upgrade gksu but it gives me bunch of errors..
<Diablo-D3> mementor: try doing it while gdm is running
<Diablo-D3> that seemed to fix it for no obvious reason for me
<mementor> ok, ill try that
<Riddell> Kamion: can you tell me what the gconf stuff in mountpoints_to_summary does?
<jsgotangco> hmm that ubuntu mcdonalds story at digg is strange
<Diablo-D3> mjr: go go gadget tar zcvf!
<Diablo-D3> jsgotangco: url?
<jsgotangco> http://blog.thetechgurus.net/?p=69
<jsgotangco> and it originated from the forums doh!
<Diablo-D3> mjr: okay, its about 30 megs.
<mjr> yep, no problem with things that size
<mjr> seems it'll take a while
<mjr> I'll put it under http://mjr.iki.fi/ubuntu/ when I get it
<Diablo-D3> mjr: you may wanna rename the produced dir to just synfig then
<mjr> 'k
<Diablo-D3> and the neat part is, its apt-get repo ready <3
<Diablo-D3> I dont know what I'd do without apt-get
<mjr> yep, I assumed as much
<Diablo-D3> probably curse alot and start running fbsd more =/
<sladen> ogra_: would you be able to modify hwdb to show the DMI manufacturer, system-{manufacturer,product-name,version}  If might be easier way of getting the dmi data out of people
<ogra_> sladen, not before ui freeze, but i'll put it on my todo
<Diablo-D3> mjr: its done
<sladen> ogra_: were/are there any edubuntu-like setups for Cybercafes, I have someone asking for something with centrally managed power-on/off and accounting
<ogra_> sladen, not yet ... i'm working on a kiosk mode on ltsp level for such institutions ... edubuntu might be the best choice to have an out of the box setup directly after install, but you have to set up everything manually for things like kiosk mode 
<Diablo-D3> kiobuntu?
<Diablo-D3> ubutosk.
<fabbione> lstsk
* Diablo-D3 gives up.
<sladen> cafebuntu
<ogra_> lstsk ?
<Diablo-D3> sladen: that works
<Diablo-D3> actually, it shouldnt be that hard
<ogra_> sladen, cool, i'll make that an edubuntu installmode in dapper+1 ;)
<Diablo-D3> copy live cd to harddrive
<Diablo-D3> live cds are pretty kiosky to begin with
<fabbione> mdz: ping?
<Riddell> Kamion, Mithrandir: where can I find kbd_chooser.py?
<sladen> Diablo-D3: netboot and run the whole setup out of RAM;  reboot when they leave (which is what easyeverything did)
<Diablo-D3> sladen: that sounds about right
<mdz> fabbione: pong
<fabbione>  /usr/lib/mozilla-thunderbird/run-mozilla.sh: line 131:  1454 Segmentation fault      "$prog" ${1+"$@"}
<fabbione> nice :)
* mvo goes out of a bit, bb ~2h
<fangorious> i'm having trouble with the flight-4 livecd on my laptop, after selecting to either boot hte live system or check the cd, i get the kernel loading progress bar, and then an error message "i/o error: could not find ramdisk image: /install"
<fangorious> i've downloaded the iso multiple times, confirmed it has the right md5sum, burned the image about 7 times at different speeds on 3 machines with multiple blank cds, nothing helps
<fangorious> i can't seem to run 'md5sum /dev/cdrom' on the laptop, it gives me an i/o error. and I don't know how to md5sum a cd on windows 
<Tm_T> fangorious: how about installin "md5sum" program in windows?
<Tm_T> +g
<fangorious> Tm_T: but what argument do I give it? I have md5sum under cygwin
<Tm_T> ach
<Tm_T> you can't use any native windows programs?
<Tm_T> btw there's been lot of reports about flight 4 cd's having major problems
<fangorious> i'm sure I could, I just don't have any handy
<Tm_T> so there's possibility you can't get it woeking
<fangorious> man. i need a livecd with a good partitioning program, wanted to use gparted
<Tm_T> knoppix has qtparted or something
<Tm_T> ;)
<fangorious> ugh. think i'll try a breezy livecd
<mjg59> Woo!
<mjg59> Installer running
<Diablo-D3> what box?
<mjg59> Intel imac
<Diablo-D3> ooh sounds like fun
<Diablo-D3> but its not suprising
<Diablo-D3> its not like macintels are ZOMG NEW HARDWARE THAT SHALL NEVER RUN LINUX!!!!!!1 or anything.
<Diablo-D3> mjg59: but did you see what I did?
<Diablo-D3> Synfig on Ubuntu: http://shadowconflict.blogspot.com/2006/03/synfig-ubuntu-debs.html
<Diziet> Wahey, I have a virtual machine.
<Diziet> Wow, this xen is soooo funky!
<lemsx1> i gotta congrats you guys
<lemsx1> i'm using rythmbox for the first time without crashing every 5 min ;-)
<lemsx1> (i'm on Dapper)
<mjr> Diablo-D3, oh yeah, by the way, it's there (renamed as you suggested)
<Diablo-D3> mjr: I noticed =P
<Burgwork> hmm, CNR for Ubuntu
<Diablo-D3> mjr: and Im betting no one will download it =(
<G0SUB> sivang 
<poningru> so will dapper+1 be all 686?
<poningru> or is that decision defered for now?
<Diablo-D3> poningru: defered because it doesnt make sense
<Diablo-D3> there are too many modern x86 processors that arent 686 compatible
<poningru> well isnt that what mubuntu was meant for?
<Diablo-D3> yeah, but no one wants mubuntu
<Diablo-D3> they want to use the fully bloated gnome desktop on their Via C3s
<poningru> hehe
<poningru> what about the upstream prob?
<Diablo-D3> which one?
<poningru> lots of upstream are just doing 686
<Diablo-D3> said upstream smokes crack.
<poningru> but the patches duke the patches !!
<Diablo-D3> besides, they cant really "do 686"
<Diablo-D3> any hardwired cflags are always patched out for sanity reasons
<poningru> hmm ic
<Mithrandir> dholbach: btw, no need to prod admins about the popcon RT case.  I have access to the machine now.
<Diablo-D3> and I doubt anyone is going to bother writting ASM that uses 686 ops
<Diablo-D3> because they'd still have to write the same code in C, which means thats what we'd end up using
<poningru> oh true
<dholbach> Mithrandir: mdz asked me to
<Mithrandir> dholbach: well, mdz didn't know I had my access already.
<dholbach> Mithrandir: me neither
<Mithrandir> dholbach: anyway, no need to prod them further or anything.  Prod me about what you want, rather. :-)
<dholbach> Mithrandir: I didn't mean to push anybody to anything
<Mithrandir> dholbach: no, I didn't mean to imply so.  Just a small fyi.
<dholbach> Mithrandir: I'm not going to prod and I didn't consider "hey, how's <X> going as prodding" :-)))
<dholbach> yeah :)
<Mithrandir> dholbach: anyway, what is it that you want me to do on popcon?  Make stats for universe too=
<Mithrandir> s/=/?/
<dholbach> Mithrandir: no, I just said in the "important stuff, I can see"-section, that it'd be nice to have popcon going, to prioritize the motu fixing
<Mithrandir> dholbach: ah, true.
<Mithrandir> dholbach: I'll see if I can get to it next week, then?
<dholbach> Mithrandir: but I understand if you have other stuff to do, so I don't mean to push you
<dholbach> Mithrandir: take your time - that'd be brilliant
<dholbach> Mithrandir: thanks a lot :)
* dholbach hugs Mithrandir
<zAo^> does anyone know how I can make dapper boot like this (gentoo) http://shots.osdir.com/slideshows/460/4.gif
<zAo^> thanks
<Mithrandir> change usplash-artwork.so to something which provides that artwork
<G0SUB> Mithrandir that artwork is just crappy
<G0SUB> zAo^ use splashy or Upower
<zAo^> thanks G0SUB
<G0SUB> :)
<Mithrandir> G0SUB: if you think so, just replace it with something else.
<G0SUB> Mithrandir that's the issue ... you need to compile stuff for that ... not easy for everybody
<dholbach> G0SUB: don't think that other solutions were not pondered.
<dholbach> G0SUB: and "crappy" is not exactly friendly towards people who worked on this.
<G0SUB> dholbach I am aware of that ... sorry
<Mithrandir> G0SUB: patches for changing that are accepted, I'm sure.
<dholbach> G0SUB: I didn't work on it, but I think it's much nicer than before. :-)
<tseng> G0SUB: usplash is written with very wide device compatibility in mind
<G0SUB> dholbach no doubt, but changing the image is a real PITA
<tseng> G0SUB: not being the best graphically
<mjg59> Hm. Arse. No DMI tables on the Mac.
<G0SUB> guys, thanks for being so understanding ... I accept my fault and lack of knowledge
<G0SUB> where is the usplash mailing list or bug tracker?
<G0SUB> can't find it on lauchpad
<doko_> Kamion: gcc-4.0-hppa64 isn't seeded anymore, is hppa currently not included in the anastacia check?
<Seveas> Kamion, ping
<sladen> g0sub: https://launchpad.net/distros/ubuntu/+source/usplash/+bugs
<dholbach> Good Night guys!
<Pygi> night dholbach
<tseng> infinity: please give back muine on ppc
<mantiena> hello all
<mantiena> anyone knows why at archive.ubuntu.com there are OOo2.0.2rc4 binaries, but no sources ?
<mdz> seb128: is it possible to disable sound events by default, while still having the login and logout sounds play?
<mdz> mantiena: the source is there, it just isn't where it should be (it's in universe)
<seb128> mdz: my unassigning all the other events by default probably
<mdz> Kamion: and it doesn't show up in anastacia, oddly enough
<seb128> mdz: making a patch to have them played in any case would probably be easy too
<mantiena> mdz, hehe, it's pretty strange :)
<mdz> seb128: whichever implementation you feel is best, please make that change
<seb128> mdz: k, I'll have a look tomorrow, should be easy. Good decision imho, sound events on click, etc tends to be annoying
<doko_> Source only promotions to main 
<doko_>  ------------------------------ 
<doko_>  o openoffice.org
<doko_>  o openoffice.org-amd64
<doko_>  o openoffice.org-l10n
<doko_> mdz: ^^^
<mdz> oh, my bookmark still points to my anastacia.txt, not Colin's
<mdz> I thought I fixed it
<mantiena> mdz, doko_: this is sort of bug when binaries are in main, but  source in universe, right ?
<doko_> mdz: replace the file by a symlink please ;)
<mdz> doko_: yep, done
<mdz> mantiena: no, it is normal for it to be out of sync when packages move between components
<mdz> it is a temporary situation
<mantiena> ok
<mantiena> doko_,  openoffice.org_2.0.1oob680m5-1ubuntu2 is the newest version or somewhere I can find newer ?
<doko_> mantiena: sure, upstream CVS ;-)
<mantiena> doko_, :) I got error during making packages of older version, error was because ooqstart binary was not in ooo-core, but in ooo-common package (I can paste build error if you want)
<mvo> mdz: zyga implemented the cmd-no-found spec (a app that suggests the binary package based on a command that was not found). can this still go into universe? or this it too late for this already?
<mantiena> I just wanna report a bug to you :)
<mantiena> packaging bug
<mdz> mvo: I don't see why it couldn't go into universe, no
<CarlFK> seb128: did purple_cow talk to about xchat-gnome -a? https://launchpad.net/products/firefox/+bug/31226 
<Ubugtu> malone bug 31226 in firefox "FF doesn't do irc:// correctly" [Normal,Confirmed]  
<mdz> seb128: yes, we agreed it was annoying some months ago but forgot to implement the change ;-)
<mvo> mdz: great, thanks
<seb128> CarlFK: I don't understand your question
<seb128> CarlFK: didn't read about that bug before
<CarlFK> seb128: Ill take that as "no" ;)
<CarlFK> skip to the bottem
<mdz> Kamion: my bookmark foolery is the same reason I was confused about the Xubuntu bits the other day
<seb128> CarlFK: seems to be a bug, but dunno if it's fixed yet
<CarlFK> purple_cow couldn't figure out why it broke, and said he would talk to you about it
<mdz> Kamion: regarding Xubuntu, the only one that gives me pause is gqview
<CarlFK> seb128: given that irc://chat.freenode.com/ubuntu is now on the opening FF page, I figured it would be nice if the link worked 
<seb128> CarlFK: right
* mvo goes to bed now
* neuralis might only be around for a few minutes of this meeting
<neuralis> er. wrong channel, sorry.
<iBalo> Wouldn't it be a good idea/measure to include the necessary firmware for all the new fancy DVB-drivers in 2.6.15 either in the kernel package, or in a seperated firmware .deb. There's not much use in having drivers in /lib/modules which don't work because the required firmware is missing in /lib/firmware.
<Diablo-D3> iBalo: no, it'd be a good idea to make hardware that isnt utter shit and requires external firmware loaded by drivers.
<iBalo> Ok, but lets be pragmatic. My Cinergy 1200 is supported by 2.6.15, and all it takes to make it work out of the box is throwing the firmware file in place... I went through a hard time figuring this out, and think that would be nice to avoid this for people not able to read dmesg
<mjg59> iBalo: Yes. Do we have permission to redistribute the firmware?
<ogra_> iBalo, should be no problem with sanely licensed firmware 
#ubuntu-devel 2006-03-08
<iBalo> Hmm... so i finally took a firmware .deb from Kanotix, so i think it must be at least beer-free
<Kamion> Riddell: the gconf stuff attempts to stop gnome-volume-manager from popping up "helpful" nautilus windows when the installer is busy mounting partitions
<Kamion> Riddell: kbd_chooser.py is in espresso-keyboard-setup, in the archive. espresso depends on it ...
<Kamion> doko_: I took hppa and sparc out of my anastacia run because the fact that neither had built anything for weeks was rendering anastacia output difficult to deal with. I'll put them back in once they've caught up.
<Kamion> Seveas: pings are better with content :)
<Seveas> hehe
<Seveas> would https://launchpad.net/distros/ubuntu/+bug/33438 be something I should subscribe you to?
<Ubugtu> malone bug 33438 in Ubuntu "use sha1sum instead of md5sum" [Wishlist,Unconfirmed]  
<Seveas> (still trying to improve the triaging)
<iBalo> BTW, if the firmware is downloadable at linuxtv.org, could there be a problem in adding it to the repos?
<Burgwork> iBalo, yes, possible
<Burgwork> iBalo, just because somebody can distribute it doesn't mean Ubuntu can
<Burgwork> observe Skype and Java
<Diablo-D3> just because somebody can distribute it doesnt mean anyone cares.
<Diablo-D3> observe bittorrent
<Burgwork> Diablo-D3, bittorrent is a very useful tool for saving bandwidth
<Diablo-D3> hrm, wouldnt that be interesting: illegal driver warez.
<ohoel> is not distributing dapper flights to mirrors intentional?
<iBalo> ok, i see... then this would be a case for uni-/multiverse... Maybe  i should just write up a Howto to make it easier for people to tackle the problem 
<Burgwork> ohoel, dapper is not stable, so some mirrors may choose not to carry it
<Burgwork> iBalo, multiverse means we can distribute it. If it is a hardware driver, there is a case for restricted
<Kamion> Seveas: in some universe in which I believe that the md5sums.txt on the CD images has any cryptographical significance whatsoever
<Seveas> Kamion, right, thought so already 
<Kamion> I'll close it, there's a good reason why it's md5sum
<Kamion> oh, hang on, he's not talking about md5sums.txt, he's talking about MD5SUMS
<Kamion> ok, that's a not entirely illegitimate comment and should be assigned to me; I'll do that
<iBalo> i just spent the last couple of minutes searching tfw for the firmware licensing policy of the Terratec/KNC-one DVB-cards. Can't find nothing... would it be helpful if I email them (I'm one of their customers, huh?) if there' s a problem in redistributing the firmware?  
<iBalo> i just spent the last couple of minutes searching tfw for the firmware licensing policy of the Terratec/KNC-one DVB-cards. Can't find nothing... would it be helpful if I email them (I'm one of their customers, huh?) if there' s a problem in redistributing the firmware?  
<Burgwork> iBalo, please don't double post
<Burgwork> iBalo, I would try. Mention what you want to do. You might not end up speaking to someone with enough authority, however
<Burgwork> iBalo, in any case, file a bug about it
<iBalo> Ooops, sorry, had over 10 seconds dalay, wasn't aware i posted already
<Burgwork> iBalo, ok, np
<doko_> Mithrandir: how could a missing /etc/environment be regenerated?
<Seveas> touch /etc/environment
<Seveas> (doesn't dpkg-reconfigure locales create it?)
<_lemsx1_> anybody knows why in gnome-terminal every character you type, the cursor seems to go from the beginning of the line up to the char that you are typing?
<_lemsx1_> if i ssh into a remote box it doesn't happen
<_lemsx1_> and with the same .inputrc .bash* files in different computers, some do that and others don't
<jdub> BUENOS DIAS, AMANTES DE LA LIBERTAD!
<_lemsx1_> lol
<tenco> anyone here who knows python-gst?
<sladen> tenco: try #farsight
<tenco> farsight? ok.
<tenco> sladen: no answer... :-(
<tseng> tenco: patience can get you far, sometimes
<tenco> tseng: perhaps i should wait a few and sleep in between. its already damn late here...
<tenco> ... a few hours...
<sladen> tenco: that's a good idea, somebody will have replied by the morning
<sladen> tenco: and rather than asking ''does any know...'', actually ask the question.  ''I'm trying to do XXX, YYY but I get the error ZZZ.  Here's my code so far  http://....''
<Kyral> uhhh
<Kyral> why is OpenOffice getting yoinked?
<jdub> Kyral: don't dist-upgrade
* Kyral quickly CTRL-C's
<Kyral> Not like I need OO, was just wondering lol
<jdub> it's a temporary package conflict 
<Kyral> ah
<Kyral> thats what I thought
<jdub> if you avoid dist-upgrading, you'll miss most of that kind of mess
<Kyral> actually I have been meaning to remove OpenOffice1....
<Kyral> jdub: Why would I want to avoid it? I'm testing Dapper for a reason :D
<Kyral> with everything that breaks, a new lesson is learned :D
<jdub> because upgrade gets you where you want to go without the temporary package relationship glitches
<jdub> it's worth looking at dist-upgrade output, but tracking with upgrade
<Kyral> ahh
* infinity watches with a certain satisfaction as the first sparc buildd grinds out builds...
<Burgundavia> infinity: does this mean we are going to be offiicially supporting sparc for dapper+1?
<Mez> whats up with thunderbird atm
<infinity> Mez: That's next on my list after sorting sparc.
<infinity> Mez: Though, "what's up", in what sense?
<Mez> so you know about not being able to reply to anything ?
<infinity> Burgundavia: Not sure, that's up to sabdfl and others.  I just make it go.
<infinity> Mez: Err, no?  It works great for me...
<Burgundavia> infinity: ah, ok
<Mez> er well it says it cant reply for me
<infinity> Mez: What's it do?
<Mez> "an error occured while creating a message composition window - please try again later"
<infinity> Mez: Do you have doko's broken GTK installed, by any chance?
<Mez> infinity - i have the one from his website
<Mez> but it was working before that
<Mez> though a new gtk+ is being downloaded now
<infinity> Mez: Well, tbird hasn't changed, so if it's suddenly started hating you, I'd blame a library.
<infinity> Mez: A full update, then quitting and restarting tbird (or even rebooting) might make it like you again.
<Mez> "downloaded size: 1 Mb - installed size - 56k"
<Mez> o_O
<Mez> infinity - doingnfull upgrade now
<Mez> tried rebooting too
* Mez does a re-install of TB
<Mez> nope
<Mez> still broked
<Mez> stat64("/home/mez/.mozilla-thunderbird/init.d/S*", 0x7fbc4484) = -1 ENOENT (No such file or directory)
<Mez> moving my .mozilla-thunderbird folder works though
<Mez> hmmles
<Mez> I cant be arsed
<Mez> I'm going to bed
<Mez> night all
<OgMaciel> Seveas: u around
<Mithrandir> doko_: you can't.  It's not a conffile
<carlk> today there is no xchat-gnome or xchat in dapper.
<carlk> indended or should I bug it?
<Burgundavia> carlk: xchat-gnome was removed, but xchat was not added back
<jdub> Burgundavia: unlikely we'll ship a gui irc client in the desktop seed
<Burgundavia> jdub: hmm, that is interesting
<Burgundavia> shall we debate that on ubuntu-desktop? (I disagree with the decision)
<whiprush> jdub: hey, have you had a chance to look at the ff1.5/css thing on fridge at all?
<jdub> whiprush: not yet, will check it this arvo or monday
<whiprush> cooh
<whiprush> jdub: also, know if anyone got a better vid of your talk at fosdem? the one linked from lwn has horrible sound. :-/
<jdub> Burgundavia: there's already a basic irc client in gaim, and xchat doesn't fit the GCF goal of the desktop seed (very small audience that cares about irc)
<jdub> whiprush: no, that was pretty much it i think
<Lathiat> i dunno.. irc is pretty popular
<Lathiat> especially to get help with linux...
<Lathiat> #ubuntu is a riot?
<Lathiat> and my non geek friends use irc
<Lathiat> whats GCF?
<jdub> greatest common factor
<jdub> Lathiat: compare irc to im - not even remotely favourable to irc :)
<Lathiat> jdub: irc and im fill different voids
<Burgundavia> jdub: hmm, forgot about gaim doing irc
<jdub> Lathiat: sure, and irc is a very very niche player
<Lathiat> gaims irc is very.. unfitting
<jdub> i'd support this even if gaim didn't do irc
<whiprush> people who want irc get irrsi anyway. :p
<carlk> I think #ubuntu does quite a bit for support, which IM does not
<Burgundavia> jdub: anyway we can get gaim to be able to be able get into #ubuntu quickly?
<jdub> hold on
<jdub> you guys are looking at this in a very odd way
<jdub> why do we want to push more people towards #ubuntu?
<ajmitch> jdub: why do we want to discourage users from it?
<jdub> ajmitch: we're not
<whiprush> ximian tried the irc help thing a few years back, that so didn't work.
<carlk> i think it is good to have the kind of support that #ubuntu provides avalible 
<jdub> carlk: it is still available
<ajmitch> jdub: if you do remove an irc client, make sure the firefox start page doesn't point there
<jdub> ajmitch: unrelated bug
* Lathiat thinks removing xchat is silly, gaim really doesn't make a good irc client
<jdub> definitely not a rationale for shipping an irc client
<jdub> Lathiat: even if gaim didn't have an irc module, i'd support removing xchat
<ajmitch> Lathiat: the argument is that no irc client should be shipped (gaim doesn't count)
<Lathiat> jdub: why?
<jdub> Lathiat: because irc isn't a high priority at all for the 99%
<carlk> jdub: i think it is a good rational for shipping an IRC client - but what you or I probably isn;t as importatnt as some figures
<Lathiat> jdub: got any actual evidence on that?
<ajmitch> jdub: you could argue that python-* packages aren't important to the 99% either
<jdub> Lathiat: absolutely - compare usage of im and irc
<jdub> ajmitch: sure, but we're shipping them for other reasons
* Lathiat knows all sorts of people that use irc, geek or not, its hardly uncommon ?
<Lathiat> sure, i guess im is used more
<jdub> Lathiat: it is wildly uncommon
<carlk> I think more important than just usage is the support - xchat will provide more support than IM (but this doens' t mean we should drop IM)
<Lathiat> just because its "not as common as im" != "wildly uncommon" ?
<jdub> Lathiat: i'm not putting those ideas in opposition
<Lathiat> jdub: i asked why its uncommon, you said compare usage to im
<jdub> carlk: i don't believe that irc support is the most useful thing for the vast majority of our users
<Lathiat> s/why/figures
<Lathiat> jdub: have you ever sat in #ubuntu ?
<jdub> Lathiat: to think about it, yes.
<Burgundavia> jdub: I am also mildly concerned about the way this is being done
<Burgundavia> jdub: this strikes me as the kind of thing you ask about or spec and then do
<jdub> Lathiat: think about the greatest common factor, think about where irc fits in - really, it doesn't.
<Lathiat> what exactly is the
<Lathiat> "greatest common factor
<jdub> what we ship in the desktop seed is stuff that will most likely be of use to the broadest cross-section of user profiles
<Lathiat> jdub:  is it going to be on the cd?
<Lathiat> or not shipped at all?
<jdub> in main, probably not shipped at all (given the way the CD works now)
<Burgundavia> Lathiat: in this case, software that the majority of the users that install Ubuntu are going to use or need
<Lathiat> well, i think its a bad idea, its not like the software is in the way, and its not largely uncommon in my experience, perhaps thats different to yours
<jdub> Lathiat: i don't think we can posit that irc is of interest to the greatest common factor of our potential users (or necessarily something we want to push to them)
<jdub> everything we put in the desktop seed is inherently 'in the way'
<jdub> so we need to think very carefully about it
* Lathiat sighs, this whole simplifcation thing is starting to drive me up the wall
<jdub> dude, this is not about simplification
<jdub> it's about appropriateness
<Lathiat> jdub: its related
<jdub> xchat is right there waiting for you
<jdub> ok, i'll be blunt
<jdub> if we're going to unfuck the world
<jdub> and take software freedom to real people
<jdub> we have to make Hard Choices
<jdub> many of which are related to realising that we do not define our most important end user profile
<fangorious> anyone know the difference between the regular install and the server install kernel boot options on the flight4 install cd?
<jdub> irc is so amazingly irrelevant even within the general IT community
<Burgundavia> jdub: I think I agree with you, but the concern about how the decision was made is still there
<Lathiat> fangorious: regular install installs gnome, server install is very cut down, basic packages
<fangorious> Lathiat: more basic than that. when you boot the cd, and select one or the other, what differences are there in the kernel options to boot the installer?
<Lathiat> fangorious: oh kernel options.. i suspcet it just passes "server" or something that d-i picks up and acts on appropriately?
<fangorious> Lathiat: If I boot the server install, I get the installer. If I boot the regular install, I get an I/O error that the ramdisk image couldn't be found
<Lathiat> fangorious: interesting
<LaserJock> jdub: how is the most important end user profile defined for you?
<fangorious> I have the same error on the live cd, but there's no server install option there
<Lathiat> known bug? bad cd?
<fangorious> definitely not a bad cd. I've downloaded the image like 4 times, burned it at different speeds on 3 machines, used different cds ...
<fangorious> only has trouble on this one laptop
<Lathiat> best course of action would be to file a bug?
<jdub> LaserJock: "not IT expert or interested" (i'm being facetious - there are a lot)
<fangorious> yeah, just wanted to check
<whiprush> or the ubuntu kernel list.
<fangorious> whiprush: i'll check that out too
<LaserJock> jdub: I'm interested in how these things are defined or quantified
<LaserJock> jdub: I haven't been around the open source or linux development community very long so I'm interested in how a distro's target audience, etc. are defined/chosen/evaluated
<Burgundavia> LaserJock: did you read the piece by jwilliams in the latest gnome journal about identifying target audiences?
<LaserJock> Burgundavia: no, I'll check it out
<Burgundavia> LaserJock: currently, they pretty much aren't
<Burgundavia> it is very adhoc, with no real market analysis
<jdub> Burgundavia: that's not true
<Burgundavia> jdub: there is a prety stark dividing line between community and "corporate backed" distros at that point
<fangorious> what package would I use in malone to file a bug against the install/live CDs?
<infinity> fangorious: Depends on the bug.
<fangorious> infinity: the default kernel gives an I/O error that the ramdisk can't be found, the server install kernel boots
<infinity> fangorious: Probably a bad burn, if I had to guess.
<fangorious> infinity: i'm just generically saying kernel, I'm not sure if that's right
<fangorious> infinity: definitely not, i've downloaded and burned it 8-10 times on 3 machines, at different speeds, with different cds
<fangorious> infinity: so any idea what package to file against?
<infinity> fangorious: Is this with a daily build, a flight release, or a stable release?
<fangorious> flight 4
<infinity> Oh, then I'm pretty sure the image is just fine.
<infinity> You can file the bug on "linux-source-2.6.15", there may be something particularly goofy about your hardware, but it's a bit suspsicious that the server kernel works.
<fangorious> cool, bug 33513 filed.
<Ubugtu> malone bug 33513 in linux-source-2.6.15 "Default install CD kernel won't boot on HP nw8240" [Normal,Unconfirmed]  http://launchpad.net/bugs/33513
<fangorious> hey, that's really neat
<LaserJock> jdub: so will there be any app in main that will handle a irc:// URL? does gaim, do you know off hand?
<viviersf> erm, can any1 explain why openoffice2 wants to be removed, by doing a dist-upgrade on dapper ?
<carlk> is there some way that FF can apt-get install xchat the first time an irc:// link is clicked?
<pitti> Good morning
<viviersf> lo pitti 
<corey_> salut marilize
<marilize> corey_ :  hello mr Burger :)
<carlk> I got a stat:  !ubotu seen = there are 18383 seen entries
<carlk> I wonder how many of those wouldn't have joined if they had to install a client 
<viviersf> doko_, PING
<dholbach> good morning
<corey_> morning
<Kagou> hi
<pitti> infinity: we don't have http://sourceforge.net/projects/phplib/ packaged anywhere, right? at least I couldn't find it
<hunger> Would it be possible to run symlinks -dr /usr/share/man occassionally?
<hunger> Uninstalling debs leaves lots of symlinks there at times. Would be nice to clean up occassionally.
<pitti> right, that's responsible for all these cron.daily emails 
<pitti> hunger: however, eventually the packages themselves should get fixes
<pitti> s/s$/d/
<hunger> pitti: Currently that is openoffice.org. leaves ooimpress.1.gz et al.
<hunger> pitti: It would be cool if there was a test facility for uploaded script that checks that they leave the system with the same set of files after an install/purge cycle.
<hunger> s/script/debs/
<pitti> hunger: that's indeed what Diziet is working on ATM :)
<pitti> AutomatedTesting
<hunger> IIRC. debian has something like that...
<pitti> hunger: yes, piuparts
<hunger> pitti: That's why I like ubuntu:-)
<zakame> hi all
<pitti> hi zakame 
<zakame> hello pitti :)
<hunger> pitti: Whenever I get an idea somebody of you great guys is already working on it:-)
* hunger thanks all the ubuntu developers for their work.
<Kagou> hi seb128 
<seb128> lu Kagou
<pitti> infinity: can you please give-back gnome-netstatus gnome-pilot gnopernicus gok gnome-python-extras rhythmbox vino xchat-gnome (temporary libgnomevfs-common breakage, fixed now)
<seb128> hu
<seb128> you uploaded all that stuff in the hour where it was broken? :)
<pitti> seb128: apparently, that's what I meant with 'good timing' :)
<pitti> seb128: first the .desktop changes, now gnutls transition, I silently became the 0wner of all gnome packages :-P
<seb128> pitti: yeah :)
<seb128> pitti: want some thousand bugs going with it? :p
* pitti runs away screaming
<pitti> seb128: I don't want to spoil your Karma
<seb128> pitti: is http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt updated?
* pitti notices that ctrl+click on an URL is broken
<seb128> works fine with xchat-gnome :)
<pitti> seb128: should, its generated daily at 0600 UTC
<seb128> pitti: 
<seb128> alacarte (0.8-0ubuntu4) dapper; urgency=low
<seb128>   * debian/rules: Build a .pot
<seb128>  -- Sebastien Bacher <seb128@canonical.com>  Wed,  1 Mar 2006 16:53:55 +0100
<seb128> 2 days ago
<seb128> it has built
<seb128> and the log has still:
<seb128> ===== Processing /home/lamont/public_html/translations/20060223/alacarte_0.8-0ubuntu3_i386_translations.tar.gz =====
<seb128> wftl: alacarte_0.8-0ubuntu3: 1 domains, but 0 pot files
<seb128> 
<seb128> one example
* pitti looks
<seb128> there is no change on all the stuff we fixed with dholbach
<pitti> seb128: hm, no buildd tarball any more in ~lamont
<pitti> ENOTHINGTOIMPORT
<pitti> carlos, infinity: did the sbuild hack for exporting translation tarballs go away?
<seb128> iz lamont bog
<pitti> seb128: when was this uploaded?
<pitti> yesterday?
<seb128> 2 days ago
<seb128> "Wed,  1 Mar 2006 16:53:55 +0100"
<pitti> ok, so built on vernadsky
<seb128> alacarte is a small package, I'm probably uploaded like a few minutes after that
<carlos> pitti: ?
<carlos> pitti: I don't know any details about sbuild
<pitti> infinity: so, the latest ~buildd/translations directory on buildds (checked ross and vernadsky) is 20060225
<pitti> after that, no tarballs are available any more
<seb128> I blame infinity
<pitti> so it seems that the switch to direct rosetta import made that sbuild hack become ineffective
<pitti> or it was deliberately removed
<pitti> so, iz not lamont bug
<carlos> pitti: anyway, the files should be available from librarian....
<carlos> pitti: just like any other upload
<pitti> carlos: how do I get this? https://launchpad.net/+builds/+build/172016 -> .changes file shows the .changes, but no symlinks
<pitti> and 'resulting binaries' just shows the .deb, not the translation tarball
<Mithrandir> ogra_: the "gnome-screensaver locks every five minutes after you resume from suspend" bug is getting _really_ annoying.
<carlos> pitti: I think that should be a question for celso
<carlos> pitti: the files are stored and available so I guess it's a matter of setting that as links
<mvo> ping ogra_
<fabbione> seb128: ping?
<seb128> fabbione: pong
<fabbione> seb128: thanks for adding xauth as Depends for xvfb, but it's not enough
<fabbione> i am going to upload another package now
<fabbione> it needs xfonts-base too
<fabbione> or it will fail to run later
<seb128> ah, ups, thank you
<fabbione> no problem dude :)
<seb128> I just noticed the xauth because it was breaking pygtk build
<fabbione> yeah
<seb128> but since buildd retry and logs are a mess atm
<fabbione> or if you want you can upload.. i am in holidays :)
<seb128> I didn't notice if it was building after that
<seb128> fabbione: I'll upload
<fabbione> ok :)
<fabbione> xfonts-base <-
<seb128> xfonts-base is enough or I should look if it chockes on something else after that?
<fabbione> thanks
<seb128> np
<fabbione> you need to be 100% sure to build on a machine that is not running X and in a clean chroot
<fabbione> s/is/has
<fabbione> and yes.. checking if it chokes is a good idea
* mvo grumbles about ctrl-w
<Kinnison> Can I assume the gnome breakages are fixed now?
<Kinnison> I.E. the ones which cause gnome programs to ftbfs
<dholbach> Kinnison: if you refer to gconf* in various postinst scripts, then yes
<Kinnison> cool
<Kinnison> infinity: are you around?
* Kinnison assumes not
<Kinnison> If anyone needs builds resetting because of that breakage then please /msg me the url to the source release
<MikeS> BenC: Are you around? I'm told you're the person to talk to about ubuntu kernels. I've been having some Weird Problems with valgrind, they turn out to be because of some part of the ubuntu kernel configuration, wanted to ask some questions about it...
<ogra_> Mithrandir, please file it then
<ogra_> mvo, pong
<Mithrandir> ogra_: uh, it was discussed here two days ago, I assumed you knew about it.
<ogra_> Mithrandir, i asked you to file it two days ago ;)
<ogra_> i cant reproduce it at all here
<Mithrandir> is there any particular piece of information you want?
<ogra_> just a plain description for now would be fine 
<Mithrandir> https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/33539 ; enjo
<Ubugtu> malone bug 33539 in gnome-screensaver "doesn't seem to detect activity after resuming from suspend" [Normal,Unconfirmed]  
<Mithrandir> +y
<ogra_> Mithrandir, thanks :)
<Mithrandir> it's an utterly useless description if you can't reproduce it, though
<segfault> man, this new gnome-power-manager notification is really annoying
<Treenaks> segfault: uh.. it only notifies if you battery is about to go empty -- or if your AC state changes, right?
<pitti> segfault: which, that it tells you that you plugged in an AC adapter?
<StevenK> Or unplugged it
<pitti> (which is fairly pointless, right)
<segfault> i'm using it plugged in, and it keeps notifying me that my battery is now charged
<segfault> and repeats over and over
<Kinnison> segfault: yeah, known bug
<janimo> pitti, any difference between binary-predeb and post-install as the rule which adds gettext domain to .desktop files?
<segfault> oh, sorry then
<janimo> and hi :)
<Kinnison> segfault: if I could get it to manifest on my laptop I'd stand a chance of fixing it
<pitti> hi janimo 
<Kinnison> segfault: can you please make a gpm trace?
<Kinnison> segfault: Do you know how?
<pitti> janimo: yes, it caught a few corner cases (some packages don't work with install/::
<janimo> pitti, so you recommend using that since it is more robust?
<segfault> kinnison: strace gnome-power-manager?
<pitti> janimo: yes
<janimo> I have helpers who package some xfce plugins and would like to tell them if that's the case
<janimo> ok, thanks
<pitti> janimo: IIRC the problem was that some package installed debian/mycustom.desktop over an upstream installed one
<Kinnison> segfault: no
<pitti> janimo: so that our cdbs rule didn't catch that
<janimo> pitti, but if it is not done as part of a cdbs rule but on a per package base and is tested then it's ok?
<janimo> s/base/basis/
<pitti> janimo: oh, of course
<janimo> ok, I'll let it the way they changed than
<janimo> I was afraid to not be something related to dpkg voodoo and cornercases
<pitti> janimo: btw, for such stuff it would really be nice to have a xfce.mk
<janimo> as opposed to packaging problems
<pitti> janimo: or just use gnome.mk for the time being
<janimo> pitti, yes it is the first compelling reason to have an xfce class
<janimo> pitti, and the most important are .desktop files for apps that show up in the menu right?
<janimo> since there are desktop files for panel plugins too
<pitti> janimo: right
<janimo> but those are only read by xfce panel
<pitti> janimo: and building a POT file, almost even more important
<janimo> having the apps transtalted (thunar, xfce4-terminal, mousepad) actually helps gnome as well
<janimo> pitti, you mean add to the per package POT file if it does not contain the strings in .desktop?
<Kamion> BenC: linux-source-2.6.15 binaries accepted
<Treenaks> \o/
<janimo> do those strings in .desktop have _ in front just as in C code?
<hunger> What? New kernel binaries again?
<hunger> Damn, I just actually rebooted my server to have the last update finally take effect;-)
<pitti> janimo: generally, update the POT file so that it's always current (even if you change strings in patches, etc)
<pitti> janimo: an up to date POT is crucial for translations
<pitti> janimo: and many packages don't build a pot at all, which is even worse
<janimo> pitti, right. So actually just adding the line to .desktop is not enough if somehting is missing from .pot ?
<pitti> janimo: yes, potentially
<janimo> and some .desktop files have some strings translations embedded, how does that come in to the picture
<pitti> janimo: but these two don't have much in common
<janimo> are those fallbacks?
<pitti> janimo: yes, gnome upstream doesn't use gettext for translating .desktop
<janimo> xfce uses intltool
<pitti> no, I mean at runtime
<pitti> intltool is for merging .po translations into .desktop files
<pitti> at build time
<janimo> aha
<janimo> ok, I have to read more gettext docs to be able to ask smarter questions
<janimo> will get back with the progress
<pitti> http://wiki.ubuntu.com/LangpacksDesktopfiles might help a bit
<janimo> read that
<janimo> but I am reading through info gettext for all the details
<sabdfl> mjg59: how's that mactel box looking?
<Treenaks> sabdfl: ( http://mjg59.livejournal.com/58934.html ? :))
<mjg59> sabdfl: A little bit of kernel work to do
<Kamion> oh, speaking of, I wanted to prod the seeds for mactel
<mjg59> I've got some problems with interrupt routing, but other than that things are good. Small amount of installer work needed (elilo needs to be added), and then we're good.
<Kamion> mjg59: could you send me /proc/cpuinfo from that box?
<sabdfl> so good for dapper?
<Kamion> I'd like to teach the installer that i386/Mac is a different subarchitecture
<mjg59> Kamion: cpuinfo is, uh, not "interesting"
<mjg59> Also, no dmi data
<Kamion> mjg59: any other way to tell?
<mjg59> Kamion: Not that I've worked out yet
<Kamion> mjg59: that's going to be nasty
<Kamion> mjg59: the installer needs to not offer elilo on normal i386 systems
<StevenK> lspci doesn't show a stack full of Apple stuff?
<mjg59> Kamion: Well, /sys/firmware/efi exists
<Kamion> that'll do
* Kamion goes to prod libdebian-installer
<Kamion> sabdfl: CD images will be "interesting"
<Treenaks> Kamion: more & more non-apple will have EFI after Vista releases
<Kamion> oh, fair point I guess
<Treenaks> + machines
<mjg59> Treenaks: And they'll quite possibly want elilo as well...
<Treenaks> mjg59: true, but they won't be macs :)
<mjg59> Yeah, it's the elilo thing that's the distinction
<Kamion> yeah, makes it not a subarchitecture but gives me a valid isinstallable test for elilo
<mjg59> Though they're more likely to ship with BIOS compatibility
<Treenaks> mjg59: for a while at least
<Kamion> sabdfl: the Mactel doesn't boot normal ISO9660 images; but I have a strong hypothesis that they'll boot the ISO9660/HFS+ hybrid images that we currently use on powerpc
<Kamion> sabdfl: my current plan is to create separate -i386-mac.iso images for dapper, and merge that back into -i386.iso after dapper when I'm not so worried about breaking shit
<mjg59> Kamion: Yeah, it'll boot HFS stuff with a blessed efi binary
<Kamion> mjg59: I'm trying to figure out how to do this test without breaking ia64 2.4 installs in Debian
<mjg59> Kamion: Ah. Heh.
<Kamion> mjg59: does /sys/firmware/efi require any kernel modules to be loaded before it exists?
<mjg59> Kamion: No
<Kamion> mjg59: and is there any /proc equivalent?
<mjg59> I'd guess so, but I'm not enthused about trying to boot a 2.4 kernel on this
<Kamion> I'll trawl kernel source
<Kamion> possibly /proc/efi
<sladen> Kamion: presumbly the HFS+ view onto the system only needs to extend to elilo, the kernel and initramfs; after that point Linux running and can see the iso9660
<Kamion> sladen: true, but I think from the debian-cd point of view it's easier to just hybridise the whole thing
<Kamion> since mkisofs supports that
<sladen> Kamion: I was worrying about space;  just adding elilo and a small HFS+ view should add <1MB to the CD
<segfault> :)
<Kamion> sladen: I can always use -hide-hfs to hide pool/ from the HFS view, I guess
<Kamion> I imagine that would get rid of most of whatever extra space is taken by HFS metadata (although surely that isn't all *that* much anyway)
<BenC> Kamion: re -17, thanks
<Kamion> BenC: will you do l-r-m and linux-meta?
<BenC> yeah, doing it now
<doko_> infinity: could you have a look at #32869, nvidia-drivers?
<Kinnison> Kamion: see you in 45
<Kamion> Kinnison: ok
<Mez> aw great 
<Mez> I seem to have lost all my f**king email
<freeflying> Kamion: hi
<Mez> thats not good
<Mez> not goodat all
<pitti> Mez: how did you manage that?
<pitti> some evo bug or sth?
<Mez> pitti: thunderbird was playing up - so i moved my .mozilla-thunderbirdfolder
<Mez> i tried movingit back and it deleted everything in it
<pitti> with rm -r ?
<Mez> when i next ran thunderbird
<Mez> mez@lethargy % mv ~/.moz-tb-bak ~/.mozilla-thunderbird
<pitti> Mez: and you are sure that it's not in ~/.mozilla-thunderbird/.moz-tb-bak now? :)
<Mez> mez@lethargy % ls ~/.mozilla-thunderbird                       /home/mez 12:59
<Mez> appreg  lavoky4t.default  profiles.ini
<Mez> pitti: whats annoyed me most is that all my mail filters have gone so I've got to set them all up again for all the mailing lists
<torkel> Mez: it's a dot-file so you will have to do ls -a 
<Mez> torkel thankyou
<torkel> Mez: found it?
<Mez> yes
<Mez> now lets see if I can write mail
<Mez> ok
<Mez> now it just wont select the right profile
<Mez> nope
<Mez> I still cant write email
<Mez> argh
<Mez> wtf is going on
<BenC> Kamion: ping!
<Mez> IT's something in my profile
<mjg59> Kamion: Oh - something I've only just noticed. I picked "British English" for my keyboard, which is obviously wrong (since it's a Mac)
<mjg59> How we work that out, I'm not sure
<Kamion> BenC: yo
<Kamion> mjg59: keyboard architecture handling is a mess
<freeflying> Kamion: how about scim-pinyin's UVF
<mjg59> Hngh!
<Kamion> freeflying: I'll look at it later today
<mjg59>                     If (_OSI ("Linux"))
<mjg59>                     {
<mjg59>                         Store (0x03E8, OSYS)
<mjg59>                     }
<mjg59> That's from the imac's ACPi tables
<mjg59> Oh wow
<mjg59> There's a reference to XP in here too
<jdub> heh
<jdub> mjg59: so, nice taste in wine. another reason for me to stop avoiding the desireable mac mini?
<mjg59> jdub: Kernel isn't quite happy yet
<BenC> Kamion: nm
<Mez> argh
<infinity> doko_: I'll try to reproduce that on my girlfriend's machine on Monday.  I've subscribed to the bug.
<infinity> pitti: Still around?
<pitti> infinity: yes
<infinity> pitti: A) Those packages were just given-back, B) Not sure what's up with the translations publishing, can you ping me via email (it's really late Friday night and I'm a bit tipsy), C) I wouldn't be surprised if phplib shows up bundled in some larger PHP applications.. Pick some telltale filenames from phplib upstream and grep Contents-*.gz
<sabdfl> ogra: what's the status on the hardware database?
<ogra> not much improvement there, we have >200000 datasets but i still havent gotten around to write a proper SQL backend
<doko> seb128: do you call the new copy/paste behaviour in gnome-terminal fixed? now, copy/paste *only* works using the menu, no x selection anymore :-(
<ogra> i thought about approaching the LP team for it at some point so we can have it prepared to be integrated later 
<dholbach> seb128: which version do you use?
<seb128> doko: what do you mean?
<infinity> doko: X primary works for me.
<seb128> dholbach: uptodate
<infinity> doko: With both middle-mouse and Shift-Insert.
<dholbach> seb128: oops
<seb128> dholbach: but you want to speak to doko:)
<dholbach> doko: which version do you use?
<dholbach> seb128: yeah, i do
* dholbach hugs seb128 :)
* seb128 hugs dholbach
<doko> 2.13.91-0ubuntu1
<dholbach> doko: and which vte?
<doko> can you stop hugging and start working? ;-P
<seb128> libvte4 is the package
<doko> 1:0.11.20-0ubuntu1
<ogra> sabdfl, its not off my list, but i have prioritized ltsp, edubuntu and gnome-screensaver currently, want me to change that ?
<dholbach> doko: and you restarted gnome-terminal since one of the last updates? ;)
<sabdfl> ogra: no
<sabdfl> besides, prio's should be cleared by mdz
<setuid> I need to build the _exact_ same kernel that I'm running on Breezy, from source, because /lib/modules/2.6.12-10-686/ doesn't have a full build tree of modules required for building third-party modules. How can I do this without breaking my running kernel (which includes modules in /lib/modules/volatile, like fglrx) 
<Treenaks> setuid: uh.. install linux-headers-`uname -r`
<infinity> setuid: Erm, for building third party modules, you want linux-headers-`uname -r`
<doko> dholbach: hmm ... why should this affect the running process?
<Treenaks> setuid: you _should_ be able to build modules
<setuid> I did, that doesn't fix it 
<Treenaks> setuid: then your module is broken
<setuid> That's why I'm here asking ;)( 
<dholbach> doko: i just wanted to be sure the new libvte is used
<setuid> hrm, weird... just a mom. 
<dholbach> doko: the fix was in 0.11.19
<doko> dholbach: ok, will restart soon ...
<infinity> setuid: Unless you have some bizarre module that wants to statically link another (which is just plain WRONG), you don't need modules to build modules, just headers to build against.
* Treenaks is waiting for new l-r-m and l-meta
<setuid> infinity: Nope, its just a replacement for ibm_acpi with the newer verison
<infinity> setuid: And is it a complete build dir meant to build out-of-tree, or just something you're meant to dump in the kernel source tree?
<setuid> Ah, the default kernel changed the acpi path
<setuid> So third party modules will not work 
<infinity> setuid: If the latter, either make it the former, or build a whole kernel (yay)
<setuid> I can't build a whole new kernel, as much as I'd like to... (I *HATE* running distro kernels, they never work right), but I need fglrx, and that doesn't build agaisnt anything
<setuid> root@angst:/lib/modules/2.6.12-10-686 # ls -l acpi/ibm_acpi.ko kernel/drivers/acpi/ibm_acpi.ko 
<setuid> -rw-r--r--  1 root root 40740 Mar  3 09:20 acpi/ibm_acpi.ko
<setuid> -rw-r--r--  1 root root 24084 Feb 13 07:46 kernel/drivers/acpi/ibm_acpi.ko
<setuid> where the heck does kernel/drivers/acpi/ibm_acpi.ko come from? That's not right. 
<infinity> That's perectly right.
<setuid> I've inserted ibm_acpi into no less than 30 kernels on other machines, without any issues, now Breezy changes the path? 
<infinity> Out-of-tree modules own the top-level namespace, everything distributed with a kernel is under kernel/
<setuid> Then that differs from the upstream kernel.org source 
<setuid> So Breezy changed it 
<infinity> No, really, it's in sync with upstream.
<setuid> If I build a clean kernel from kernel.org, unpatched, and build the ibm_acpi module externally agaisnt that kernel, it goes into where it should, /lib/modules/`uname -r`/acpi/
<setuid> Nope, definitely not in sync with upstream
<infinity> Yes, you just said the magic word "externally"
<infinity> If built internally, it's kernel/*
<setuid> Right, _externally_, with upstream kernel sources, it does into ./acpi, and there *IS* no other one 
<setuid> sigh
<setuid> Ok, let me try this a different way... 
<infinity> setuid: Also, please take this to #ubuntu-kernel (yes, I should have shunted it there earlier)
<setuid> I need to build a kernel, I need that kernel to include the fglrx driver (or else I can't run X, X will immediately hard-lock any Thinkpad released in the last 3-4 years if you let it load gdm or X with Breezy or Dapper)
<setuid> Ok, I'll trundle over there. I know how to build kernels, I wrote the HOWTO on it... just not when things are changed under the hood with distros requiring third-party modules. 
<infinity> setuid: I'm running a Thinkpad T43 (7 months old?) with dapper (and previously breezy) and no fglrx.
<infinity> setuid: Please don't make such sweeping statements.
<infinity> setuid: Heck, half of Canonical owns Thinkpads. :)
<setuid> infinity: I have a T42p here, and if I load dapper with the radeon/ati driver, it immediately hard-locks. 
<setuid> There are about 200 users on dri-users who have repeatedly reported this 
<setuid> I am one of them
<setuid> Its been an issue since the r300 cutover on 7/24 of 2005
<setuid> That's the last version of r300/X/Xorg that works without lockups
<infinity> One some machines, at any rate.
<infinity> But I digress.
<infinity> So you need fglrx.  Right.
<setuid> Anything with a Radeon/ATI chip, yes. 
<infinity> (Mine has an ATI X300)
<setuid> Well, here's the problem... fglrx locks the machine up when you resume from suspend, but it doesn't lock the machine when you need to run X
<infinity> (Making breezy/dapper both stable on my laptop has always been a personal release goal, and was always met)
<setuid> So I either have to shut down, instead of suspend, or I don't run X
<infinity> Yes, fglrx has always had resume issues.
<setuid> There are some binary patches that have come out in the last 2 days that I haven't tried yet. 
<torkel> setuid: the radeon driver works for me on my T40p
<setuid> With 3D? 
<setuid> 2D works great, at 67fps
<setuid> (on my T42p
<setuid> ) 
<infinity> "Need to run X" != 3D.
<setuid> infinity: Right, but there is no other way, including commenting out the DRI section of xorg.conf
<torkel> setuid: I usually don't do 3D
<setuid> Unless I rename the module in the tree 
<setuid> dri, glx, radeon, etc. 
<infinity> Or remove libgl-mesa-dri
<setuid> Which removes about 80 other basic packages
<infinity> Or don't load the glx module in xorg.conf
<setuid> Nope, even with commenting out glx, it hard-locks
<janimo> infinity, so you X300 works fine just no DRI with radeon driver?
<setuid> You have to comment that out, the DRI section, and remove the physical module from disk
<infinity> (I'm also pretty sure there's a driver option like "DisableDRI", but don't recall what it is)
<infinity> janimo: I have DRI, works fine with it on.
<setuid> Trust me, I've been through this... for 8+ months now
<infinity> janimo: I'm clearly the only one in the world.
<janimo> infinity: even resuming from hibernate?
<setuid> You're one of a minority, yes. 
<infinity> janimo: Yes.
<janimo> it works here to just act funny on resume
<janimo> that's promising anyway
<setuid> janimo: Are you using vbetool? 
<janimo> seyuid, dunno, default dapper
<setuid> In your hibernate script, do you call vbetool on suspend and resume? 
<janimo> lemme check
<janimo> but I did not touch any script so if it's there it's the default
<setuid> infinity: lspci -v -v | grep ATI 
<setuid> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2]  (rev 80) (prog-if 00 [VGA] )
<setuid> ^ that's what I have
<pitti> carlos: could you please do me a quick favor? can you connect your iPod with firewire and pastebin me the lshal output?
<setuid> pitti: ipods do firewire? When did that happen? My 4G and 5G are both usb-only
<mjg59> infinity: Suspend fails for DanielS with DRI enabled
<janimo> setuid, yes vbetool is called because POST_VIDEO is set to true
<mjg59> On a T43
<pitti> setuid: carlos' has :)
<setuid> pitti: ah, hacked on, gotcha
<mjg59> So there seems to be some unhappiness
<janimo> mjg59, any idea what happens if the harddrive of laptop spins down after a few secs of inactivity
<janimo> or as I work it looks like it spins up down every 20 sec or so
<mjg59> No
<janimo> after unplugiing and repluggind the cable
<infinity> mjg59: Oh, I don't doubt it... But he also doesn't hardlock when X starts.
<janimo> before that is fine
<mjg59> infinity: Indeed
<mjg59> setuid: ibm_acpi has been upstream since 2.6.10 or so. If built in an upstream kernel (rather than externally), it will end up in precisely the same location as Ubuntu puts it.
<setuid> mjg59: 2.6.12-10 ships with 0.8, 0.11 has been current for many moons now... 
<setuid> And 0.11 + my full-speed patch allows me to keep my T42 cool enough to use
<mjg59> setuid: You're missing the point.
<setuid> ...and allows me to use all of the keys
<mjg59> setuid: We have not changed the install location of the driver. 
<mjg59> It is installed precisely where the kernel build system puts i
<mjg59> t
<setuid> mjg59: The point is, if I build a kernel from source, with ibm_acpi as a module (internal to the kernel tree), then _replace_ that kernel module with an externally-built one, it _replaces_ the one in the kernel tree, it does not add a second one in a different location. Never has. 
<mjg59> setuid: No, really, it does.
<mjg59> Drivers that are built in the kernel source end up in /lib/modules/foo/kernel/whatever
<mjg59> Drivers that are built outside do not
<setuid> I guess these 30 systems are running on pixie dust then, because none of them exhibit the behavior you're describing
<mjg59> If you build the ibm_acpi that is in the kernel source, it will install to kernel/drivers/acpi/
<mjg59> That's what kbuild *does*
<setuid> Right
<mjg59> And we build ibm_acpi in the kernel source, which is why it ends up in kernel/drivers/acpi
<mjg59> If you build it externally, the external build system has no idea to put it there. So it doesn't.
<mjg59> So it gets installed in a different location.
<mjg59> That's perfectly normal
<setuid> If that's true, why does an in-kernel module take precendence over a third-party module in the kernel module tree when both are present? That behavior (if valid) should be reversed. 
<mjg59> I've no idea. That's a module-init-tools issue.
<mjg59> As far as I know, it's upstream behaviour
<setuid> True
<mjg59> keybuk would know for sure
<setuid> T'would be nice to build these kernels with /proc/kconfig support, instead of /boot/config-x.y.z
<mjg59> Why? One takes up memory, the other takes up disk space...
<setuid> You're already wasting a truckload of memory by building support for every module in the kernel into the kernel's namespace
<setuid> What's another 1k 
<mjg59> What's the use case?
<setuid> embedded systems
<mjg59> If you're building your own kernels, it's a simple switch. If you're using the distro kernels, the config file is guaranteed to match
<mjg59> Our kernels are not suited for embedded systems, really
<setuid> Actually, the config file does _not_ match (and the kernel source package stamped with the same version as the running kernel also does not match) 
<mjg59> No, really, it does
<mjg59> It's copied into the package during the build
<setuid> Example: 2.6.12-10-686, which I'm running, has a config file which builds as SMP (its UP), and the kernel source has a Makefile which specifies 2.6.12-386
<setuid> So I have to change the config, change the Makefile, and rebuild 
<mjg59> Which kernel source package? What you get with apt-get source?
<setuid> I only point to official breezy repos, and yes, it was fetched with apt-get source foo
<mjg59> What you get with apt-get source foo is the unconfigured source
<setuid> apt-get source linux-headers-2.6.12-10-686 linux-image-2.6.12-10-686 linux-restricted-modules-2.6.12-10-686
<mjg59> The configs are in debian/configs/
<mjg59> The extraversion stuff is passed in as a makefile variable from the build scripts
<setuid> So the config for my running kernel, which is in /boot/config-x.y.z, is not the same as that which built the running kernel? 
<setuid> That's odd. 
<mjg59> It is the same
<setuid> No, that's my point, is it NOT the same. 
<setuid> The config, found in /boot/ for my _running_ kernel, specifies SMP
<setuid> The kernel which is running, is NOT SMP
<setuid> The kernel source also does not add the proper stamp when the config from /boot/ is copied into the kernel tree
<mjg59> This does not match any reality I can currently test
<mjg59> setuid: It does if you build it with the package build system
<setuid> debuild? 
<setuid> Nope
<mjg59> Yes
<setuid> sigh
<mjg59> No, really, it does.
<setuid> I went through this the other night, after waiting about 6 hours for dozens of unnecessary kernels to build first
<mjg59> I can't tell what's going wrong for you, but I have a sufficiently large number of kernels built here to know that that's how it happens.
<mjg59> But if you're not interested in actually discussing it with someone who knows significantly more about our kernel build system than you, then I'm afraid I have better things to be doing right now.
<setuid> I'm interested to hear what you changed from the standard kernel build process, so I can undo that when I build kernels
<setuid> I need to build a kernel that matches the _exact_ kernel I'm running, with a current compiler. 
<mjg59> Very little. The EXTRAVERSION field is populated by the rules file, based on the versions in the control file (which is autogenerated from the changelog version, IIRC)
<mjg59> Other than that, it's all made as normal and then copied into a package (including the config file that was just used for the build)
<setuid> Ok, so why is EXTRAVERSION set to 386 when I build with a config that comes from my -686 version? 
<mjg59> How did you trigger the make?
<setuid> debuild
<mjg59> That will generate around 5 different kernel packages
<mjg59> One for each in debian/configs/i386/
<setuid> Right
<setuid> And the top-level Makefile is set to -386, not -686
<mjg59> The EXTRAVERSION will be set based on the ABI version and the string in debian/configs/
<mjg59> No, the top-level Makefile is not set
<setuid> and include/linux/versions.h also correlates with that
<setuid> ..for my arch
<mjg59> The only place where EXTRAVERSION is set is as a variable passed in from the rules
<mjg59> When it reads debian/configs/i386/686, it will be set to -10-686 (or whatever)
<setuid> Ok, what package/packages am I supposed to install, that will give me the _exact tree_ of source that build the kernel I'm _currently_ running? 
<setuid> s/that build/that built/
<mjg59> The source you get from apt-get source is identical
<mjg59> If you then debuild in there, it'll build 5 or so kernels, one of which will be identical to your running one
<setuid> So linux-source-2.6.12-2.6.12 then? 
<mjg59> Yes
<setuid> And that knows I'm at a -10? 
<mjg59> If it's the -10 version, yes
<mjg59> (you can see in the changelog)
<setuid> linux-source-2.6.12 (2.6.12-10.28) breezy-security; urgency=low
<mjg59> Yup
<setuid> Ok, so I just copied /boot/config-2.6.12-10-686 into there, and debuild will build me a package that matches my currently-running kernel? 
<mjg59> No
<mjg59> Because it'll be overwritten by debian/configs/i386/whatever for each build
<mjg59> But the 686 one in there should be identical to your config-2.6.12
<setuid> Ok, so I should copy debian/config/i386/686 to .config? 
<mjg59> Not if you're going to use debuild, no
<mjg59> But if you just use make bzImage, then yes
<setuid> If I have no top-level .config, and run debuild, I get a 2.6.10-386 SMP kernel
<setuid> er, 2.6.12
<setuid> Not a 2.6.12-10-686 UP kernel
<mjg59> It should build more than one kernel
<setuid> It does, 1 for each arch
<mjg59> Uh. What do you mean by each arch?
<setuid> AMD, K7, i386, etc. 
<mjg59> Right
<mjg59> There should be a 386 and a 686 one
<setuid> I'll let it complete and see what happens... the other night (on dapper) when I tried this, it _only_ built the 386 ones, 686 wasn't even an option. 
<setuid> Unless I hacked the Makefile and .config to force it, and built it myself
<setuid> mjg59: How would I take this same process (and maybe I should be in #ubuntu-kernel) and build a non-supplied kernel (like 2.6.16-rc6) as a package with all of the same deps and tangles? 
<mjg59> setuid: Grab the 2.6.15 git tree, copy the debian directory into your 2.6.16 tree, edit the changelog so the version is sensible, build
<setuid> So debian/changelog is parsed at build time? 
<mjg59> Yup
<mjg59> It's pretty standard to have one canonical source of version numbers
<setuid> You mean the external git tree, not the debian one? 
<mjg59> setuid: The one on kernel.org
<setuid> Right, ok
<mjg59> Or grab a 2.6.15 source package from dapper
<setuid> And copy the ./debian from the kernel source provided by the dapper/breezy package into that tree, gotcha. 
<setuid> Makes it nice and self-contained
<Riddell> Kamion: espresso-frontend-kde ready for merge, new bzr archive to get round the deleted gtkui.py thing http://kubuntu.org/~jriddell/espresso/ubuntu/
<Riddell> Kamion: can I upload that to the archives?
<carlos> pitti: I cannot do that as the computer with the firewire has MacOSX instead of Linux
<Kamion> Riddell: I'd rather merge it first
<Kamion> Riddell: but cool, thanks!
<Kamion> (I'm working on espresso pretty much permanently, and often have changes beyond the current release)
<Riddell> Kamion: are you likely to upload it today?  I'd like to send out an e-mail to interested people that it's available before I go away for the weekend
<trappist> dist-upgrade wants to remove openoffice.org and kubuntu-desktop and not replace them?
<Kamion> Riddell: yeah, should do
<Kamion> Riddell: I'll change a couple of things - you won't be able to import espresso.emap in the KDE frontend because it actually lives in espresso-frontend-gtk
<Kamion> Riddell: but I can handle that
<Kamion> Riddell: spacing in customize_installer is b0rken
<trappist> oh, openoffice.org2-* depends on pyhon-uno, which depends on openoffice.org-core which conflicts with openoffice.org2-core.  so openoffice.org2 appears to be uninstallable.
<mdke> trappist, only if you dist-upgrade
<mdke> i think
<trappist> mdke: yes
<doko> seb128: isn't glitz part of gnome? wondering, why it's not yet in main ...
<seb128> doko: no
<seb128> it's a freedesktop stuff I think
<seb128> and nothing from GNOME has a Depends on it
<doko> seb128: are there any known problems which would hinder inclusion in main?
<seb128> no
<seb128> not by my
<seb128> do we need it to main?
<doko> o libglitz-glx1 libglitz-glx1-dev                                     {glitz}
<doko>    [Reverse-Depends: libglitz-glx1-dev] 
<doko>    [Reverse-Build-Depends: openoffice.org] 
<ogra> thats XGL 
<trappist> Xgl is also in universe, isn't it?
<ogra> and very very young ... 
<stockh0lm> do you guys ship the madwifi driver on the cd?
<stockh0lm> i have a wlan card that is supposed to work with madwifi but it tires to use the acx_pci module
<bag> Anyone knows where to find spezific ubuntu patches? Such as the new logout menu?
<stockh0lm> (it == the installer)
<trappist> stockh0lm: apt-cache says it's part of linux-restricted-modules
<kent> stockh0lm: you know about #ubuntu.se right?
<stockh0lm> kent: no, never heared of it. 
<stockh0lm> do they speak german there?
<mdke> swedish, one hopes
<kent> stockh0lm: swedish,   it looked like you are  swede..  :)
<stockh0lm> kent: i only live in sweden (c:
<kent> stockh0lm: oh, sorry then.  :)
<stockh0lm> where is jeff, this is a support question (c:
<mdke> stockholm, you can try #ubuntu
<stockholm> yes, will do
<stockholm> no good.
<siretart> 17:33:00 < nobse> http://www.braincells.com/debian/images/future_of_gnome.png
<Kamion> Riddell: ok, uploading
<stockholm> so how can i install a package (linux-restricted-modules) before the network autodetection of the d-i run?
<pitti> Kamion: can you please demote libpng3 sources to universe?
* dholbach hugs pitti, the master of demotion :)
<pitti> must ... clean .. up ... archive :)
<trappist> pitti: how can I get involved in the firewall spec (I saw your name on it), or does the guy who got the bounty have exclusive access?
<pitti> hey JaneW 
<pitti> trappist: Carsten has the bounty
<pitti> trappist: if you want to help him, he'll certainly appreciate :)
<pitti> trappist: you should contact him via email
<trappist> pitti: that's what I was looking for, thanks
<trappist> any room for input on the spec itself?
<pitti> I have to leave for supermarket for a bit, but feel free to mail carsten and me about it :)
<trappist> will do, thanks
<mdke> mako, ping?
<mdke> mako, when you get this, can you moderate my post to -news just now? grazie mille
<Diziet> OK, I give up.  What's normally responsible for running ifup on eth0 ?
<Diziet> Oh, I see, I don't have netbase installed.
<Diziet> Thank you for being a cardboard IRC channel.
<mdke> haha
<seb128> Diziet: udev I would say
<seb128> Diziet: /etc/udev/rules.d/85-ifupdown.rules
<Kamion> pitti: done, although it'll be a while before it takes effect since we have archive problems at the moment
<pitti> Kamion: thanks
<mjg59> W00t.
<mjg59> Now I just need to get the CD drive working again.
<pitti> hi zyga, how are you?
<zyga> pitti: hi, fine :)
<zyga> thanks :)
<zyga> I got wifi working yesterday and now I'm enjoying the weekend on my bed
<pitti> heh
* pitti is grateful for having wifi in his bed for the 3am meetings, too :)
<zyga> ndiswrapper unfortunatly but it'll get better over the years
<dholbach> have a nice evening
<mdz> ogra: is the hwdb server still running on your personal machine, or is it at the DC now?
<ogra> mdz, still on my machine 
<ogra> but its a brandnew server and i have backups up to 180000 datasets 
<ogra> (we have ~200000 currently)
<mako> mdke: it's away :)
<theCore> Is it normal, that I feel Dapper UI take me for an incomptent, while the installer take me for an expert?
<theCore> is it a reason why the System menu is locked?
<theCore> (btw, sorry if my question seem like "trolling" )
<trappist> theCore: the installer is mostly inherited from debian, which imho suffers from the attitude that a good barrier to entry will keep out the unwanted noobs
<Kamion> that's simply a false description of d-i's development approach
<Kamion> I'm sorry but as a d-i developer I think I'm qualified to say that that has never been an attitude taken by d-i developers
<Kamion> and looking at the massive improvement of d-i over boot-floppies that's borne out by evidence
<theCore> I saw I few thing in the installer, that could be abstracted easily
<trappist> Kamion: I'm basing my opinion on what you'll hear from the debian community when you mention making something more user-friendly, and I suspect their desires tend to percolate up to the developers
<theCore> like in the network config, why bother people with the network devices names, like eth0 or ath0 ? 
<mjg59> trappist: Oddly enough, no...
<Kamion> trappist: *shrug* I'm afraid you're wrong here as far as the developers who are actually doing the work; many of the more vocal members of the Debian community are entirely unrepresentative
<Kamion> theCore: it's basically noise (read as "blah") by people who don't know what they are, but if you *do* know then it's invaluable
<trappist> Kamion: that's entirely believable.  it's those vocal members who drove me into the arms of ubuntu.
<trappist> at any rate I always got the impression that the debian installer is just the way they like it.
<Kamion> trappist: some of the vocal members of the Ubuntu community are just as bad, to be honest
<Kamion> we've just had less time to pick up the more eccentric folks here ;-)
<Kamion> trappist: nah, look at the graphical installer development for example
<Kamion> there's loads still to do on d-i
<trappist> Kamion: every community has its trolls and idiots and zealots, but I haven't seen so much of that here.
<trappist> haven't seen the graphical one.  but having come (almost) originally from mandrake, I know installers can be a LOT more user friendly.
<Kamion> d-i is just operating under some constraints (many self-imposed of course, but they are well-thought-out for the most part) that mean it's taken a while to get there
<theCore> what is the UI freeze deadline ?
<Kamion> and remember that espresso is a derivative work of d-i
<Kamion> theCore: http://wiki.ubuntu.com/DapperReleaseSchedule
<trappist> well they don't have the same target audience as ubuntu I guess, so that's reasonable.
<theCore> thanks Kamion
<Kamion> it's also been important to make the code maintainable by a relatively large and fluid developer community and to make it easy to port to all the architectures Debian supports
<Kamion> which has been a godsend in Ubuntu, as we haven't had to do much porting work
<Kamion> and it's not that hard for developers to come in and fix just one piece, once they've got an idea of the general design - that's not the case of the other more monolithic installers I've looked at
<Kamion> installers that are primarily maintained by just a couple of people in a company obviously don't have to deal with the large-development-community aspect
<trappist> I dunno if you've looked at mandrake's installer (I haven't in a while) but it fits that description nicely.  The pieces are tools written in perl available in the installed OS that have a gui wrapper but fall back nicely to ncurses or even cli if necessary.
<Kamion> no, I haven't looked at Mandrake, that's true
<trappist> don't get me wrong, I left mandrake for a reason, but I sure did like the installer.
<Kamion> sounds like a not dissimilar design, we'll probably get there or thereabouts
<Kamion> we have the capability to add frontend-specific plugins now, which will help a lot once people get the hang of writing them
<mdz> ogra: is there a sysadmin ticket open for moving it to the DC?
<ogra> mdz, nope 
<Treenaks> pitti: if /dev/sdx1 mounts as /media/-1/ -- would a reboot help? :)
<theCore> oh yeah I almost forgot, why do I have 8 floppy drives?
<^ap^> hi mans
<^ap^> need help
<Kamion> theCore: installer bug, need to track that one down ..
<Treenaks> theCore: because you do? :P
<Kamion> in fact, I'll have a look now, it's like the most frequently reported installer bug at the moment I think
<theCore> Treenaks: I don't even have one
<LaserJock> "OMG, when I installed Ubuntu it gave me new floppy drives! I wonder if they could give me some more RAM next time" ;-)
<Cyorxamp> Lo, is anyone here a fundamental part of the ubuntu project - got a cosmic idea for ya (anyone who says !anyone will be severely insulted)
<Cyorxamp> WHAT do people think of this suggestion??? http://paste.ubuntu-nl.org/9684
<Treenaks> Cyorxamp: I just post my working Monitor sections on my blog :)
<CarlFK> Cyorxamp: wiki isn't a good database server for that 
<CarlFK> Cyorxamp: there is allready someting like it, but it just collects data. someone needs to build a UI to get the data back out
<Cyorxamp> but does this idea have merit?
<CarlFK> "yes"
<Cyorxamp> hmm, why the quotes?
<CarlFK>  the impmemtaion you describe is poor
<Cyorxamp> so what do you think would be a better way?
<Kamion> people have mentioned the hwdb to you a few times already
<CarlFK> build a UI to the existing database 
<Cyorxamp> but the wiki idea is so easy
<Cyorxamp> if a UI is such a good idea why hasn't someone done it yet
<CarlFK> Cyorxamp: not once it gets big enough to be useful
<Cyorxamp> if the wiki idea got superseeded by something later, fine
<CarlFK> Cyorxamp: are you volunteering to built the UI?
<trappist> you're talking about using a wiki as a database.  storing things like this in something designed to hold it isn't a bad idea, and can be made pretty useful with a ui.
<Cyorxamp> which doesn't exist
<Cyorxamp> people keep saying there is a script, and something called hwdb etc... but at the end of the day a newb can't understand that
<CarlFK> Cyorxamp: are you volunteering to built the UI?
<Kamion> theCore: oh, heh, the installer lists 8 floppy drives in /etc/fstab because udev helpfully creates 8 device nodes in /dev/floppy/
<Kamion> Cyorxamp: that's why it's on the menus for them, "Hardware Database" or something along those lines
<Cyorxamp> CarlFK, hey I only know a bit of Java, VB and I am only now learning C, C++, GTK+   - i wouldn't know where to begin
<theCore> Kamion: so it is easy to fix
<CarlFK> "that's why" ;)
<Kamion> theCore: well, not sure, still investigating
<Cyorxamp> CarlFK - your saying theres a lack of developers with the knowledge needed to make a UI?
<Kamion> theCore: it's always a mistake to declare that something is easy to fix before investigating it :)
<Kamion> Cyorxamp: s/knowledge/time/
<CarlFK> Cyorxamp: correct
<Kamion> no, not correct
<Cyorxamp> well the whole reaosn I am jumping on the C,C++,GTK+ band wagon is to get away from the very Vista,C# friendly atmosphere at my uni
<Kamion> there's a lack of developers with time
<ogra> Kamion, thanks foe -docs !
<ogra> *for
<Kamion> ogra: no problem
<Cyorxamp> so yeah - when I have the knowledge I will contrib as much as I can
<theCore> Kamion: at least, I can fix it manually
<Cyorxamp> but this idea is EASY and needs NO programming skill!
<Cyorxamp> and could help looooads of people
<CarlFK> Cyorxamp: no, a wiki page will turn into a big mess
<Cyorxamp> not ONE page lol
<Cyorxamp> a page per model of 'thing' (whether monitor/card)
<CarlFK> Cyorxamp: a bunch of wiki page will turn into a big mess
<Kamion> theCore: fixing it manually is trivial, rip the stray lines out of /etc/fstab
<theCore> Kamion: already done
<Kamion> the thing is, nobody will actually ever look at these wiki pages, because it's too painful
<Cyorxamp> CarlFK - whats that 'Hardware Database' thing thats supposed to be in my menu then?
<Cyorxamp> is that a GUI to a database?
<Kamion> so it lures people into believing that something is being done when it isn't
<bag> Anyone knows where to find spezific ubuntu patches? Such as the new logout menu?
<CarlFK> Cyorxamp: start here: https://wiki.ubuntu.com/HardwareDatabase  
<ogra> Cyorxamp, in fact there is no database yet, there is a collection of 200000 datasets on http://hwdb.ubuntu.com/
<ogra> the app you start from the menu is the data collection tool ...
<theCore> Wouldn't be a better to make a GUI editor for xorg.conf?
<CarlFK> orga - that "is" a database ;)  
<Cyorxamp> how on earth is 3770236f086536d10237452f01b9cabc supposed to help?
<Cyorxamp> this is a nightmare
<Kamion> theCore: not really, much better to have it go away
<ogra> whats missing is a SQL backend that makes the adta searchable ... and a web frontend or gui app 
<Burgwork> theCore, why play with system-config X in RH
<ogra> Cyorxamp, that will disappear once there is a DB 
<Cyorxamp> ok CarlFK - how about an SQL database for someone to access using a program on ubuntu
<Cyorxamp> look up your settings for a device
<Cyorxamp> maybe it will even give you the code you need for certain config files
<ogra> Cyorxamp, currently it helps if you can give that ID in a bug report, the developer can download the adtaset and look at the HW data
<CarlFK> Cyorxamp:  that would be the "front end' that needs to be built
<Cyorxamp> CarlFK - so your saying the 'thing to connect to' already exists? if so where?
<CarlFK> anyone know how the data behind http://hwdb.ubuntu.com is stored?
<ogra> Cyorxamp, nope, the *data* exists 
<ogra> CarlFK, xml files bz2 compressed
<CarlFK> pretty sure it is in a MySql db unless my memory is failing 
<CarlFK> oh...
<Cyorxamp> CarlFK - is each 'entry' in that database a different piece of hardware?
<ogra> nope
<LaserJock> Cyorxamp: click on a few ;-)
<Cyorxamp> but they are whole computers
<CarlFK> orga - has anyone proposed a db schema? (table structures)
<ogra> Cyorxamp, each dataset is a uniqe PC out there, yes
<Cyorxamp> that doesn't help in the slightest
<ogra> CarlFK, feel free to design one ;)
<Cyorxamp> i'm on about storing the kinds of settings that you would find in a manual
<CarlFK> ogra: i just might... was hoping someone had started
<Cyorxamp> I don't see what that hwdb is going to achieve
<theCore> ogra, are you sure there is no duplicate entries ?
<Kamion> Cyorxamp: we don't want to have a big repository of settings
<Kamion> Cyorxamp: we want the OS to do it automatically
<Cyorxamp> Kamion - why on earth not
<Kamion> the point of the hwdb is to let us collect information in order to incorporate it into the OS
<CarlFK> Cyorxamp: come back in a few days...I may have what you want ;)
<ogra> Cyorxamp, a complete collection of hardware ubuntu runs on.... the settings used to drive that hardware ... a ressource for bugtracking ... etc
<Cyorxamp> that makes sense but the initial data the OS needs to be stored some place
<Kamion> xorg already automatically deals with a wide range of hardware; bugs linked to the hwdb allow us to track the cases where it doesn't, and hopefully fix them
<Cyorxamp> ogra - yeah it makes sense in terms of 'scenarios' for bug help
<Cyorxamp> not really same thing
<Kamion> a big repository of settings will just mean that everyone relies on that and nobody submits bugs
<Kamion> because the repository of settings is the place to go
<Cyorxamp> it makes a whole lot more sense
<Kamion> "just work" > "look it up"
<Cyorxamp> yes it is and the OS should 'just work'  -  damn right!
<Cyorxamp> but it can't know everything
<Kamion> why not? :-)
<ogra> but "look it up" can be a way of making something "just work" ;)
<Cyorxamp> yeah
<ogra> so we'll probably once aggregate a DB file we shipp for determining settings we cant detect ....
<trappist> Kamion: it can, but it doesn't, and "it *should* just work" < "let's find a solution"
<ogra> and base for such data shall be hwdb
<Cyorxamp> Kamion not to mention I don't see how the data from hwnd can be intergrated to do something useful on a new build of ubuntu to get it to 'just work'
<Cyorxamp> *hwdb
<Cyorxamp> lol you can tell I have used hwnd in VB alot  :P
<CarlFK> ogra: can I get a full entry?
<ogra> from the hdwb ? 
<Kamion> Cyorxamp: it has to come along with bug reports, of course
<Kamion> trappist: sure, but bug reports are a whole lot more helpful in terms of making it work *permanently* rather than enshrining a hack
<CarlFK> ogra: "does not show more then some basic data"
<ogra> CarlFK, just wget one ;)
<Cyorxamp> Kamion - sure but in terms of getting ubuntu to understand that is inside the pc - it's not easily mergable... you'd have to find manufacturer settings anyway
<ogra> CarlFK, wget http://hwdb.ubuntu.com/40d275ec209d70a7576b569ab17e9999.xml.bz2
<CarlFK> bingo - thanks
<ogra> CarlFK, gives you the dataset of my ibook :)
<Cyorxamp> thats the whole database?
<Cyorxamp> or just one entry?
<ogra> just replace the id with what you need
<CarlFK> Cyorxamp: just one
<ogra> thats one entry
<Cyorxamp> CarlFK - i'm getting a few people in other channels asking me if I am doing a project on this and they want to help
<Cyorxamp> I certainly do if your up to something here :P
<trappist> Kamion: there will always be hardware that doesn't work out of the box that someone has gotten to work, whose fix shouldn't require patching and repackaging software, if it's just a settings issue.
<trappist> someone will file a bug, and it will eventually get fixed, but as a user it's nice to not have to wait, potentially for another release of the distro
<Cyorxamp> every 6 months :(
<Cyorxamp> which granted is much better than some.... but still
<LaserJock> trappist: yeah, but it is much less likely to *ever* get fixed if people don't file bugs, etc.
<CarlFK> Cyorxamp: watch ... somewhere.... um... im looking at this... i need some time... hours?  um... yeah.
<Cyorxamp> CarlFK - well anything you need a hand with just say... want contact details or u think ur ok?
<trappist> LaserJock: I can see where you're coming from, but surely you don't want to stick people with non-working hardware unnecessarily, to coax bug reports out of them
<CarlFK> Cyorxamp: 
<CarlFK> Cyorxamp: email?
<Cyorxamp> pm...
<Kamion> trappist: I'd be happy to see the information in a database somewhere, provided that it's in a form helpful to those who are responsible for fixing the bugs
<Kamion> if it's not in a helpful form, those responsible for fixing the bugs are less likely to look at it, but since "something" exists there'll be little impetus to set up something that really works
<Kamion> so I think setting up the first thing that comes to mind without checking with the people responsible for fixing the bugs is actually going to be a net negative
<trappist> I for one would file a bug if something failed to work out of the box, but worked after using some other solution.  I'd feel *better* about filing the bug because I could include a solution.
<LaserJock> trappist: sure, but a lot of people (most I think) are going to be "Hmm, well that fixed it" and not do anything about it.
<mdke> mako, thanks very much
<trappist> LaserJock: maybe I'm just a karma whore.  but I think plenty of users are into the whole community thing and are happy for such an easy way to make a real contribution.
<LaserJock> I mean from my own personal experience, most people just search the forums for the setting they need and move on
<LaserJock> trappist: sure, that is what they get to do with the hwdb
<theCore> why XScreensaver has been changed for the GMOME one?
<trappist> hrm.  seems there IS a front-end.  tab-completion shows hwdb-gui and hwdb-send.
<trappist> theCore: there's a massive thread on the ml that I keep trying to ignore on that subject
<theCore> trappist: thanks for the info
<Burgwork> Kamion, was the guadelinex UbuntuExpress funded by SoC>
<Kamion> trappist: hwdb-gui is the client
<trappist> yeah
<Kamion> Burgwork: don't think so
<Kamion> I might be wrong of course
<Burgwork> Kamion, nope is wasn't
<theCore> trappist: you are right, that thread is MASSIVE 
<Kamion> ogra: -rw-r--r-- root/root     72574 2006-02-23 13:11:33 ./usr/share/edubuntu-docs/software/software/EdubuntuSoftwareBook.html
<ogra> oops
<Kamion> ogra: that looks like a mistake (software/software, likewise tech/tech)
<ogra> thanks 
<CarlFK> ogra: do you have any xslt files for the xml?  like to make it all attribute 
<ogra> nope
<CarlFK> to save me from asking.. have anything that might help me with anything? ;)
<ogra> there is a bzr branch of hwdb-client under http://people.ubuntu.com/~ogra/bzr-archive/hwdb-client/
<ogra> but apart from that there is only the data and two cgi scripts for the web interface
<mdz> ogra: please open a ticket about it; that should be a production service
<ogra> ok
<CarlFK> the cgi scripts probably have what I need - have them handy?
<Cyorxamp> If I don't want to use the bog standard 'ati' driver - and use something better... what can I use given i have a Rage 128 Pro Ultra !?
<ogra> CarlFK, the cgi scripts are a handfull of bzgrep wrappers in python, spitting out html
<CarlFK> k - I think i follow ;)
<MrFaber> hi all
<Treenaks> hmm.. NetworkManager 0.6 -- and no way to get it into dapper? (it has wpa support with the latest kernel; might need a newer wpasupplicant too)
<MrFaber> Sorry that I ask this way but I and some others have problems with the module-assistant in dapper and it seems quite serious
<MrFaber> loop-aes and other modules can't be build and it hasn't been fixed for a long time so I am afraid that the final has still the problem
<MrFaber> I have made a bug report some time ago https://launchpad.net/distros/ubuntu/+source/loop-aes-source/+bug/30230
<Ubugtu> malone bug 30230 in loop-aes-source "loop-aes module can't be created in Dapper Drake" [Normal,Unconfirmed]  
<Treenaks> MrFaber: loop-aes? why not use LUKS and/or other dm-crypt methods?
<MrFaber> but it is still unconfirmed
<MrFaber> Treenaks, because security but other modules can't be build too
<MrFaber> that's why I post it here
<MrFaber> loop-aes in Breezy works fine
<Treenaks> uh... dm-crypt is more secure than loop afaik.. because loop can destroy your FS afaik
<MrFaber> they have the same error with nvidia or fglrx
<MrFaber> Treenaks, loop-aes is older than dm-crypt and I haven'T any problems with it until now
<MrFaber> I use it for more than one year
<Treenaks> MrFaber: dm-crypt reads cryptoloop (older) disks fine
<Treenaks> MrFaber: but LUKS is really an improvement
<MrFaber> And I like it to change key without repartitionate
<Treenaks> MrFaber: that's what LUKS provides for you
<MrFaber> Treenaks, loop-aes=cryptoloop
<MrFaber> sorry !=
<mjr> afaik dm-crypt does not read loop-aes multi-key disks fine
<mjr> indeed
<MrFaber> mjr, you are right
<Treenaks> sounds idiotic.. multiple approaches for 1 thing
<MrFaber> Anyone knows something about the module assistant bug?
<mjr> and, it seems to me that luks doesn't quite have the paranoia that loop-aes does
<MrFaber> mjr, if you are so paranoia to use disk encryption you shouldn't use dm-crypt imho :)
<mjr> (the race conditions notwithstanding)
<Treenaks> mjr: the race conditions can be quite annoying if they eat your files
<mjr> Treenaks, that is not under disbute
<MrFaber> Treenaks, I have five partitions in use with loop-aes
<mjr> pute
<MrFaber> Treenaks, and never lost a file even on shutdown after useing ext3
<Treenaks> MrFaber: that still does not prove that there are no races :)
<MrFaber> Treenaks, if you use XFS you can't blame loop-aes on real shutdown
<MrFaber> Treenaks, loop-aes is much older than dm-crypt so it should be more stable
<mjr> what is under dispute is that dm-crypt provides the same level of confidentiality as loop-aes
<MrFaber> mjr, if you don't use ECB
<MrFaber> dm-crypt at first has only supported ECB
<MrFaber> but this is not the problem
<MrFaber> the problem is the module assistant imho :)
<MrFaber> Can anyone confirm this bug in dapper?
* Treenaks stops arguing. Good luck with your bug-hunt MrFaber.
<trappist> I can't build it either, but I don't have a full kernel source tree to build against
<MrFaber> Treenaks, it is not my bug
<Treenaks> MrFaber: stop whining here then
<MrFaber> Treenaks, it is dappers bug
<MrFaber> Treenaks, and most of my points for loop-aes are facts
<MrFaber> Treenaks, do you feel powerful?
<MrFaber> I am just here to reporting a bug and you come me with dm-crypt
<MrFaber> use what you want
<Treenaks> MrFaber: Please go & reed the Ubuntu Code of Conduct. kthxbye.
<MrFaber> Other people has the same problem with module assistant while building nvidia and fglrx
<MrFaber> which has nothing to do with encryption
<MrFaber> *have
<trappist> Treenaks: please consider doing that yourself.  he's asking about a bug and you're calling it idiotic that there's more than one way to do something.
<MrFaber> I think that this is a serious bug otherwise I haven't point it out here
<Treenaks> trappist: I'm suggesting the better supported alternative (in dapper), which doesn't require module building, which avoids the bug. i.e. a workaround.
<mjr> Treenaks, ...and forces the old loop-aes users to re-encrypt their filesystems
<Treenaks> *headdesk*
<trappist> I think that's at best a semi-constructive response to a bug report
* Treenaks goes away
<MrFaber> Please check the module assistant.
<MrFaber> Thanks
<MrFaber> Goodbye
<Pygi> dholbach: ping
<Mez> mdz: ping
#ubuntu-devel 2006-03-09
<aquarius> Has the bcm43xx Broadcom driver been removed from Dapper?
<Mez> aquarius, did you actually get that working ?
<aquarius> I did indeed
<aquarius> yeterday
<aquarius> and now it's gone!
<Mez> lol - yeah it seems to have
<Mez> but I never managed to get it working
* aquarius cries piteously. 
<Mez> and now I have a light on my wirelss thing that I havent seen in ages
<aquarius> I could only get it working with static IP, not DHCP, but that's OK
<aquarius> Yeah, I have a light too, which has puzzled me a bit because I don't know what's lit it up
<aquarius> since I don't have a bcm43xx driver any more :)
<Mez> aquarius, nor do i - but i'm listing a wireless device
<aquarius> I'm not, now, although I'm just rebooting that machine to see if it stull lights up
<aquarius> is lit up from boot! weird
<Mez> my wireless is still showing it as not woking
* Mez sees if kwifimanager woks
<Mez> apparently wep is enabled on my network
<Mez> weird
<aquarius> arse!
<aquarius> no wireless device
<aquarius> Now I'll have to use ndiswrapper. That's rubbish :(
<Mez> *gets his PSP out to check if it does have wep)
<torkel> from the latest kernel (2.6.15-17.24) changelog: * Update bcm43xx from daily git snapshots
<Mez> aq: and uses propietary :D
<Mez> mez@lethargy % modprobe bcm4xx                                                                         /scratch/katapult/dev/debian 11:12
<Mez> FATAL: Module bcm4xx not found.
<aquarius> bcm43xx, not bcm4xx
<Mez> it's there
<aquarius> but bcm43xx isn't found either for me :(
<aquarius> I'm bang on up to date with dapper
<Mez> hmmles... weirdness
<torkel> aquarius: try #ubuntu-kernel or file a bug against the kernel
<aquarius> torkel, ah, didn't know there was an #ubuntu-kernel :)
<Mez>    * Update bcm43xx from daily git snapshots (wow, I initially typed snapshits,
<Mez>      hope that's not an omen).
<sobersabre> hi.
<sobersabre> is here anybody who interfaced with jetdirect ?
<mdz> Mez: ?
<Mez> mdz: any news on the backports stuff yet ?
<mdz> Mez: yes, it's on the launchpad mailing list
<Mez> ah ok :D good to hear :D
<Mez> (sorry to disturb you - standard procedure when people moan at me about stuff like this is "I dont know - I'll check the status of it")
<Kamion> aquarius: wow, Ben screwed up ;-)
<Kamion> I noticed some bcm43xx stuff in the debian/config/ diff but it looked normal enough
<aquarius> Kamion, ahaha! Wasn't just me, then. :
<Kamion> no, the module's definitely disappeared
<Kamion> let me just pull up the diff again quickly
<Kamion> insofar as the word "quickly" can be applied to diffing kernel trees
<Kamion> +CONFIG_BCM43XX=m
<Kamion> +# CONFIG_BCM43XX_DEBUG is not set
<Kamion> -CONFIG_NET_BCM43XX=m
<Kamion> -# CONFIG_NET_BCM43XX_DEBUG is not set
<Kamion> that's the only obvious thing, but surely that wouldn't matter ...
<Kamion> (presuming that the config option really was renamed)
<aquarius> cor, no idea
<Mez> ARGH
<Mez> It's very annoying not being able to read email
<Mez> write *
<Kamion> aquarius: aha:
<Kamion> obj-$(CONFIG_NET_BCM43XX)       += bcm43xx/
<Kamion> from drivers/net/wireless/Makefile
<Kamion> that needs to be CONFIG_BCM43XX now
<aquarius> BCM43XX isn't in the kernel.org kernels, is it? Can't confirm there that it was renamed.
<aquarius> aha.
<Kamion> feel free to pass the above on to #ubuntu-kernel or whatever
<aquarius> I don't suppose that there's any way I can fix this that doesn't involve me building my own kernel?
<Mez> Kamion, you should fix it ;)
<Kamion> no, it's a separate tree that BenC pulls in
<Kamion> aquarius: nope
<aquarius> pants
<Kamion> Mez: better things to do on a Friday night
<Mez> Kamion, lol - really? why are we all here chatting on this channel then ? :P
* BenC alreayd knows
<BenC> already fixed in git too :)
<aquarius> oh, sorry :)
<dAndy> anyone know much about the kickstart support in ubuntu? 
<dAndy> it seems to be ignoring the url --url line if I specify ftp rather than http
<Kamion> dAndy: that would be me, although I don't see anything wrong with the code
<dAndy> Kamion: ok, i just have url --url ftp://mirrors.cat.pdx.edu/ubuntu, and after it dhcp's the second time, it pops up a thing asking where the mirror is
<Kamion> dAndy: I'm about to go to bed; can you file a bug at https://launchpad.net/distros/ubuntu/+source/kickseed/+filebug, and attach (a) your kickstart file (with any passwords stripped or whatever) and (b) /var/log/syslog from the installer (if you complete the installation, it's saved in /var/log/installer/syslog)?
<Kamion> I'll have a look at it later
<dAndy> alright thanks
<Kamion> thanks
<Kamion> it could be a choose-mirror bug
<dAndy> kamion = colin? (I think i emailed you with kickstart issues before :)
<Kamion> oh, heck, ftp support in choose-mirror is disabled
<Kamion> dAndy: yes
<Kamion> choose-mirror (1.16) unstable; urgency=low
<Kamion>   [ Joey Hess ] 
<Kamion>   * Split input templates files into separate files for http, ftp, and both,
<Kamion>     modify build process so only the relevant templates get included based on
<Kamion>     the protocol support that is built in to the binary. Allows saving
<Kamion>     hundreds of K by disabling ftp support.
<Kamion> hundreds of K is not entirely to be sneezed at
<dAndy> ah well that would probably be why it doesnt work, my web server is having issues with ubuntu packages so I figured I would try ftp
<dAndy> is that the same reason nfs isnt supported either?
<Kamion> no, NFS isn't supported because the code just doesn't exist yet
<Kamion> damn, I'll have to make a decision on FTP I guess, or maybe come up with some workaround that isn't so space-expensive
<Kamion> could you just file a bug on choose-mirror (rather than kickseed) to remind me
<Kamion> ?
<dAndy> sure
<Kamion> ta
<Kamion> one of these days I have been meaning to write an nfs-retriever, but it's not exactly high up the growing to-do list :-/
<dAndy> i know the feeling
<aquarius> cheers for the help, Kam
<aquarius> shall wait until tomorrow for wireless :)
<dAndy> btw kamion, amazing progress from breezy to dapper, thanks alot, it has gone from possibly workable for us, to exactly what we need
<Kamion> dAndy: oh, good to hear; what improvements were particularly good?
<Kamion> oh, on ftp, what I might do is arrange to include ftp support but without any translations of the associated templates
<dAndy> well, in breezy it seemed that the post-install was running before the first reboot, before any packages in the % packages section were being installed
<Kamion> that should make it work minimally for preseeding without too much in the way of a size hit
<dAndy> which cause issues when setting up conf files for packages being installed later
<Kamion> dAndy: oh, yeah, that was a big change I spent a lot of time on with other Debian folks
<dAndy> also, i could never get it to even properly install the packages in the %packages section
<dAndy> I really like the no-mid install reboot now
<Kamion> it simplifies a lot of things; I closed a huge pile of my bugs with that
<Kamion> although there is some evil black magic in there to make it go
<dAndy> sometimes it takes that
<Kamion> anyhow, midnight => bedtime, night all
<dAndy> night
<dAndy> thanks again
<Burgwork> dAndy, you work for portland U?
<slomo> infinity, lamont: please give-back f-spot on ppc
<dAndy> Burgwork: yep
<dAndy> well Portland State Univ
<Burgwork> dAndy, that is what I meant. What do you guys run?
<infinity> slomo: On it.
<dAndy> Burgwork: our mirror is linux, we have a lot of solaris servers too, and a windows ad 
<slomo> infinity: thanks
<Burgwork> dAndy, any particular distro, or do you mix and match?
<dAndy> well, we are running centos right now, working on getting ubuntu going in our environment, probably will switch to that over spring break if we are ready
<doko> Kamion, mdz: please could you approve and promote glitz to main? not yet reviewed by pitti, needed as a OOo build dependency
<Kamion> doko: I already promoted the two relevant binaries; the glitz source was already in main.
<Kamion> no further action should be required other than a give-back of any sources that failed to build due to that
<doko> Kamion: thanks
<Seveas> doko, is that why OOo is not upgradabla atm?
<ajmitch> morning
<doko> Seveas: no, what's your problem?
<Mez> infinity:did you look at that scim package ? and see what was wrong with the control hack
<Seveas> doko, https://launchpad.net/malone/bugs/33533
<Ubugtu> malone bug 33533 in openoffice.org2 "Some packages can't be updated with update-system" [Normal,Confirmed]  
<infinity> Mez: Nope!  Can you ping me really hard about it on Monday>
<infinity> s,>,?,
<Mez> infinity, I'll try and remember 
<Mez> and ...
<Mez> o_O
<doko> Seveas: do you have -l10n and -help packages other than en-us installed?
<Seveas> yes
<Xoritor> anyone here work on gnutls?
<Seveas> openoffice.org2-l10n-nl
<Mez> who's the thunderbird expert here ?
<doko> could you remove them and retry the upgrade?
<Seveas> trying
<Seveas> nope, still holding back
<doko> The following packages have been kept back:
<doko>   openoffice.org2 openoffice.org2-evolution openoffice.org2-gnome python-uno
<doko> are these marked as "keep"?
<Seveas> marked where?
<doko> you can mark packages as "keep", so they are not upgraded on a dist-upgrade
<Seveas> I did nothing special to them (note: this is a fresh dapper 4 install dist-upgraded today apart from these packages)
<Seveas> in the bugreport i added an -o "Debug::PkgProblemResolver=True" output of dist-upgrade
<Seveas> doko, ooo2-evolution Depends ooo-evolution wich depends on ooo-core/base - that looks weird to me
<doko> Seveas: amd64?
<Seveas> no, i386
<doko> ooo2-evolution is just a dependency package
<Seveas> but it looks ike you switched names again to ooo instead of ooo2 so what I said was probably rubbish
<Seveas> hmm - apt-get install openoffice.org2 does want to install things
<Seveas> ok, this almost looks like an apt bug
<psusi> ?
<doko> Seveas: what about apt-get install openoffice.org ?
<Seveas> works too
<Seveas> http://paste.ubuntu-nl.org/9695
<Seveas> (that's for ooo2)
<Seveas> practically the same when using ooo instead of ooo2
<doko> yes, that looks ok
<Seveas> indeed, so why does distupgrade fail?
<dAndy> is there a way to specify apt config options in a kickstart?
<dAndy> some utterance of preseed maybe?
<CarlFK> dAndy: yes
<dAndy> CarlFK: do I get a hint? :)
<CarlFK> https://wiki.ubuntu.com/Installation/LocalNet
<CarlFK> that isn't exaclty what you are asking for, but close enough
<CarlFK> any Q's about it should be in #ubuntu... I keep forgetting what channel im in ;)
<Seveas> doko, seems somehow apt really wants to keep the l10n-en-us package...
<dAndy> CarlFK: I was asking in here, because when I say kickstart in #ubuntu I get no response and blank stares, I have been chatting with kamion in here about ks stuff
<dAndy> anyway, that page doesnt seem to have what i want (I didnt see any preseed lines to change apt options)
<doko> Seveas: which one, the 2, or the one without the 2
<Seveas> the 2
<Burgwork> dAndy, you are also a slightly bigger and more savvy "customer" than most
<doko> apt-cache rdepends openoffice.org2-l10n-en-us ?
<Seveas> ah crap - i'm still reading it wrong
<Seveas> it's definitely in the l10n though, at some point it even considers l10n-zu 
<doko> Seveas: yes, we need to update the language packs ...
<Seveas> but howcome it works with apt-get install then?
<Seveas> I really have to go to bed now (2am), if you need to know more just add a comment to the bug or /msg me - I'll keep my system in the 'broken' state for now
<wasabi> There a way to get grub to pop up even if default is set and timeout is set to 0?
<zul> check your menu.lst
<wasabi> can't. ;)
<dAndy> boot off a livecd and mount the drive
<dAndy> edit away, then reboot
<joelbryan> Is there any plan to include Ruby into the main Ubuntu CD?
<wasabi_> So I was thinking. Is there a pam module that can process some sort of file at login to add members of one group to another group. Recursive groups, etc. If not, I might make one. ;0
<dieman> mjg59: its fun to watch the people on digg say you faked your photo of the intel mac ;)
<desrt> i reconk its a fake the i sight looks off center and there is a conveintly place glass of red wine
<Burgundavia> desrt: absolutely. In fact, Ubuntu is a giant fake!
<desrt> obviously we gimped up all of our screenshots
<desrt> and nobody has ever actually installed it to find out if it's true or not
<desrt> in fact.. i'm totally not using it right now
<Burgundavia> even if they, the installation cd is actually a brainwashing machine to think they are using Ubuntu
<Burgundavia> huh? http://wolfgang.lonien.de/?p=34
<Mez> infinity: ping
<infinity> Mez: ?
<Mez> infinity - I seem to be having problems with thunderbird that are only in the ubuntu version
<infinity> Mez: Still having that "unable to reply" thing?
<Mez> well
<Mez> not now I've did a manual install
<Mez> but yeah
<Mez> with the ubuntu version
<Mez> new profile
<Mez> add an account
<Mez> not able to write mail
<infinity> WHat happens when you try?
<Mez> I get a popup saying "An error occured while creating a message compose window. please try again"
<infinity> Any output to the terminal when that happens?
<Mez> nope
<Mez> nor in an strace
<infinity> And it doesn't actually crash or anything?
<infinity> I might need to ask you for access to your box to debug this at some point, since it's pretty obviously a local thing.. :/
<Mez> infinity: er no problem other than being able to set up the firewall
<Mez> though I'm currently running the downloadable version of TB and it works
<infinity> What architecture do you run on?
<Mez> -686
<Mez> Linux lethargy 2.6.15-16-686 #1 SMP PREEMPT Mon Feb 20 17:26:04 UTC 2006 i686 GNU/Linux
<God> hey all
<infinity> Mez: Kay, exactly the environment I run in (where tbird obviously works fine), so we'll have to dig a bit deeper at another time (like when I'm not relaxing on the weekend)
<infinity> Mez: File a bug with any information you CAN gather, please... Package versions, strace when the bad behaviour happens, screenshots of the error, any console output while it's running (any, don't care if it seems relevant), etc.
<Mez> infinity
<Mez> poke me on monday and remind me ?
<zakame> hello all
<infinity> Mez: I vaguely recall saying exactly the same thing to you yesterday. :P
<infinity> Mez: (though on a different topic)
<Mez> ;)
<Mez> yeah
<floam> mjg59: so I'm reading some random non-tech site and see a post about some random guy being the first to supposedly run linux on an intel mac
<floam> turns out it's you
<floam> that was sort of weird
<infinity> And it's a lie.  He's not the first.
<floam> yeah, I sort of figured
<infinity> Though possibly the first to boot a full distribution and run it.
<infinity> (And we may well be the first to ship with installation and livecd support for them...)
<infinity> (Maybe)
<floam> that'd be a nice marketing ploy. :)
<zakame> whoa
<floam> I don't know if there would be that many people actually willing to give up cozy OS X, but it'd be nice to be the first shipping distribution to claim support, if it's not too difficult
<infinity> It depends on how many UVF and FeatureFreeze rules we have to break in the process.  If it can be done without destabilising anything (and without eating too much room on the CDs), it may happen, if not, then no installer support until 6.10...
<floam> I can see a lot of people wanting to run Linux on their Apple PPC hardware, but who'd really pony up all the cash for an intel mac when they could just get some small form factor PC that'd likely be three times as cheap and work better with Linux?
<infinity> floam: People do strange things.
<floam> oh, yeah.
<floam> I just don't see it being the next big thing
<floam> like people were predicting when Linux started running on Xbox's
<floam> "Lets buy fifty and CLUSTER THEM!"
* infinity laughs.
<floam> so what's 6.10 being called?
<Amaranth> I want an intel mini
<Amaranth> and i'd run ubuntu on it
<zyga> Amaranth: we all do
<mackiliaf> hi
<mackiliaf> i have installed breezy badger and want to build Xorg R7.0 from source so that I can debug a crash on my VIA ProSavage card 
<Mithrandir> infinity: Kamion seemed to want to produce a second cd for the mactel box
<mackiliaf> i tried pulling down the modular build manually but that fails to build 
<mackiliaf> does ubuntu have something like src.rpm for developers?
<mackiliaf> something that could setup the build env for Xorg R7.0 and do the build for me
<Mithrandir> you have source packages, yes.
<Mithrandir> however, xorg modular is not a single source package
<mackiliaf> yup, i noticed that the Xorg build has something like 15 other Xorg packages needed for the build
<Mithrandir> correct
<Mithrandir> you might be better off upgrading to dapper and just rebuilding the part you need
<mackiliaf> that sounds good. i was thinking about that
<mackiliaf> i just need to rebuild the savage driver
<tepsipakki> infinity: if you look at the patches for elilo and kernel, you realize that it's not going to happen for dapper ;)
<tepsipakki> the kernel diff is 2MB
<mackiliaf> although it'd be beneficial to build Xorg proper too since I'd need to debug it
<Mithrandir> yeah, in which case it'd be something like "upgrade to dapper; apt-get source xorg-driver-savage ; hack ; dpkg-buildpackage ; dpkg -i"
<mackiliaf> thanks, will give this a shot
<mvo> hi doko
<mvo> doko: does the reporter of bug 33533 has both oo1 and oo2 installed?
<Ubugtu> malone bug 33533 in openoffice.org2 "Some packages can't be updated with update-system" [Normal,Confirmed]  http://launchpad.net/bugs/33533
<mvo> doko: ignore my last question
<mvo> doko: all of the OO2 names are replaced with oo.o names?
<Seveas> mvo, no I have only oo.o2 installed (fresh flight 4 fully upgraded except for oo.o2)  
<mvo> Seveas: thanks, the update-manager tool is not designed to do dist-upgrade stuff
<_lemsx1_> hello all, the new fglrx-kernel-source package didn't solve  Bug #32576 and apparently introduced a new one. see comments
<Ubugtu> malone bug 32576 in linux-restricted-modules-2.6.15 fglrx-kernel-source "missing separator when using debian/rules" [Normal,Unconfirmed]  http://launchpad.net/bugs/32576
<_lemsx1_> bb
<_lemsx1_> bbl
<Kamion> fabbione: how come libc6-sparcv9b has /lib/ultra3/ but libc6-sparc64b has /lib64/v9b/ ?
<fabbione> hmmm
<fabbione> strange
<fabbione> i will have to check with jbailey
<fabbione> i did trash already the local debs so i have no comparison
<fabbione> but afaik jeff did change a few bits from the original patch we have to him
<Kamion> fabbione: accepted, so you can have a look once the publisher works again
<fabbione> thanks
<fabbione> it is not a big drama
<fabbione> in the worst case people using libc6-sparcv9b optimization will have a 2% performance hit...
<fabbione> and will give them reasons to install gentoo
<fabbione> ;)
<Kamion> it's in universe anyway at the moment, watch me not care much ;-)
<freeflying> Kamion: hi
<fabbione> Kamion: yes i know :) we will move them later on back in main
<Kamion> freeflying: oh, ok, I'll go look right now
<fabbione> Kamion: but thanks for noticing
<freeflying> Kamion:  :) thx
<Kamion> freeflying: it would have helped if you sent the changelog since the last release we have, rather than the whole thing
<Kamion> freeflying: and, as mdz said, included some context
<freeflying> Kamion: sorry, I'd send u again 
<Kamion> never mind now
<Kamion> in future you need to say at minimum what you are requesting, and what version you want to update to (given that the upstream changelog is stunningly unhelpful in this particular respect)
<freeflying> Kamion: got it , and the package has been uploaded to REVU 
<Kamion> freeflying: why's your .orig.tar.gz different from that produced by upstream?
<freeflying> Kamion: I've remove the CVS dir from skim/admin
<Kamion> freeflying: please tell your reviewer that I said that that's not a sufficient reason to rebuild an .orig.tar.gz
<Kamion> poking upstream to remove those directories is fine, but we should strive to keep pristine .orig.tar.gz files if at all possible
<freeflying> Kamion: hmm
<freeflying> Kamion: ok
<freeflying> Kamion: I'd poke the author 
<Kamion> wow, upstream changelog diff is a total mess; 0.5.0 must have been a divergent branch or something
<freeflying> hehe
<Kamion> freeflying: also, could you please not remove scim-chinese? breezy had scim-chinese so it will still be required for smooth upgrades.
<Kamion> (and breezy did not have scim-pinyin)
<freeflying> Kamion: sorry, I forget upgrade from breezy 
<Kamion> +XIM_ARGS=-d
<Kamion> are Unicode quotes (as opposed to "") really allowed there?
<freeflying> Kamion: let me check it 
<mdke> bug #33533
<Ubugtu> malone bug 33533 in openoffice.org2 "Some packages can't be updated with update-system" [Normal,Confirmed]  http://launchpad.net/bugs/33533
<freeflying> Kamion: it's error , correct it now 
<freeflying> Kamion: then i keep CVS dir in source tarball ?
<Kamion> freeflying: for now, that would be my recommendation, yes
<Kamion> it's pretty harmless; lintian reports it because it should be fixed eventually, not because it should be fixed *now*
<Kamion> indeed, that lintian warning is somewhat controversial
<freeflying> Kamion: got it , anyone say about it , i'd tell hime that kamion let me keep them ,  :)
<Kamion> fine by me
<ploum> Hm, just a question. Why do we not have an IRC client anymore ?
<ploum> it seems that xchat-gnome was dropped
<Lathiat> Indeed, it is currently being debated that we should ship an irc client at all
<Lathiat> that said there is irssi :)
<ploum> Lathiat, indeed. I suggest that we also drop firefox in favor of links ;-)
<cassidy> and evolution for mutt ;)
<mdke> ploum, apt-get install xchat-gnome
<ploum> but that's strange to drop it now as irc:// url are finally working
<ploum> mdke, I'm talking about the default install
<mdke> i quite like the idea of shipping without it myself
<mdke> those who want it know how to install it, and its confusing to have two IM clients
<cassidy> and we were proud to say in flight announce and UDN than we ship x-g and now we remove it. It's no sense
<ploum> mdke, as long as we can call gaim an "IM client". I would prefer the word "thing" ;-)
* ploum is joking of course
<ploum> gaim, the openoffice of IM client :-D
<ploum> that said, it's perhaps understandable to drop the IRC client by default. I don't know, I was just surpized
<mdke> it's a bold decision
<MagnusR> oobar
<MagnusR> oups, sorry wrong window.
<zakame> hi all
<giftnudel> who can I contact about the bug in the rss2 xml file in planet.ubuntu.org? (or is it known and worked on)
<ploum> giftnudel, which bug ?
<giftnudel> it's not valid xml
<ploum> giftnudel, it's jdub 
<ploum> but I suggest that you post here : http://lists.planetplanet.org/mailman/listinfo/devel
<giftnudel> funny that no one realised that so far, it doesn't even load in firefox/liferea
<ploum> giftnudel, I think it's not related to the planet itself
<ploum> but it depends of posts currently on the planet
<giftnudel> it's about the hackergotchis isn't it?
<giftnudel> yes it is, that's the reason why it complains ...
<Lathiat> ploum: :)
<Cyorxamp> where does ubuntu associations between mime types and programs?
<froud> what package provides glibc-devel, I search for it but can't find it, yet it is a dependancy for the egalax touchkit?
<azeem> froud: this is a question for #ubuntu
<azeem> packages.ubuntu.com has a search facility, libc6-dev is what you are looking for
<froud> azeem: asking there is like speaking to nobody
<froud> thx
<azeem> froud: that doesn't mean you should escalate to this channel
<froud> if no support from #ubuntu what should I do?
<azeem> ask again later or tomorrow, ask on the forums or the list
<azeem> but not here.  End of discussion, as far as I'm concerned
<froud> hmmm, oh dear :-(
<shadeofgrey> Hi guys
<shadeofgrey> anybody awake here?
<xhaker> you need support or something else?
<shadeofgrey> no i dont need support
<xhaker> just shoot the.. somebody will pick it up
<xhaker> s/the/then
<shadeofgrey> but i would like some information as to who i need to talk to about accessibility issues with the foillowing programs that ship with ubuntu: openoffice.org, abiword
<xhaker> atleast openoffice is packaged by doko
<shadeofgrey> see the thing is.... as it turns out my disability itself is getting worse -- and as it turns out i also have glaucoma
<shadeofgrey> and i dont have too comparatively long before i go blind
<shadeofgrey> and it would REALLY help if both abiword and openoffice.org had an option to make the cursor a full sized block/rectangle
<shadeofgrey> so its easier to see/follow
<xhaker> true! so, you might want to drop by #ubuntu-accessibility
<shadeofgrey> i inquired here about this a few weeks ago, and a few people that were here got all upset and askled me to leave
<xhaker> and harass those guys
<shadeofgrey> well
<shadeofgrey> i try really hard not to harass others
<shadeofgrey> and i really appreciate everything you gutys do to make ubuntu available to people like me
<xhaker> i was just trowing a joke :P
<shadeofgrey> ive said this many times... i try to stop by at least once a month to say thanks for all your hard work, because im sure very few peopple take the time to actual;ly stop by here and say thanks
<shadeofgrey> =)
<shadeofgrey> im a very thoughtful person when it comes to that sort of thing
* shadeofgrey embraces xhanker warmly
<shadeofgrey> thanks for everything you do.
<shadeofgrey> oh i do have one question
<shadeofgrey> i just installed flight3 of dapper on my third harddrive and wrote grub to the master boot record
<shadeofgrey> but i just realized that flight4 is out so i grabbed that
<shadeofgrey> do i need to fdisk /mbr before i install flight4 or will it ovverrite the old grub by itswelf?
<xhaker> it will do it's thing
<shadeofgrey> so i dont need to fdisk. thats good.
<shadeofgrey> because i cant find my windows boot disk anywhere
<xhaker> though, unless something wrong happened during the instalation of flight3 you might be better of just dist-upgrading.. 
<shadeofgrey> nah
<shadeofgrey> i already made the CD
<xhaker> :P
<xhaker> i'm saying this but i just reinstalled 2 days ago
* xhaker joyful 
<Amaranth> you can dist-upgrade from the CD
<Amaranth> shadeofgrey: ^^
<Huahua> hello, there
<Huahua> can I relicense MIT program  under GPL ? 
<Huahua> I want the GPL fork of some MIT font
<Huahua> is sublicense ==  relicense ?
<mjr> it's a different thing
<Huahua> thanks , and ?
<mjr> and at least you can take a MIT program and make a derivative that's under the GPL
<Huahua> I can make a derivative that's under the GPL ?
<Huahua> can I ?
<JanC> Huahua: if you're not sure, ask a lawyer...
<Huahua> hum
<Huahua> thanks
<JanC> but AFAIK it's nu problem
<JanC> no problem
<Huahua> en
<mjr> Huahua, yes, that's what I said, that you can. But IANAL either, so if you want to be sure...
<Huahua> mjr: thank you , I'll ask a lawyer later
<Kamion> Huahua: you can distribute MIT-licensed programs under the terms of the GPL, but the programs will still be MIT-licensed
<Kamion> you're not allowed to change the licence
<Huahua> oh
<Kamion> distributing under the terms of the GPL is all you normally need
<Kamion> so you'd have your portion of the program, or somebody else's portion or whatever, that's GPLed; and this portion that's MITed
<Huahua> hum
<Kamion> this is OK as long as the licences are compatible, which the GPL and MIT licences are
<Amaranth> Huahua: The running app is GPL, the code is a mix and people can use the MIT bits freely
<Amaranth> just in case you run into a problem like gstreamer
<Huahua> well
<Huahua> thanks a lot of
<zyga> hey
<robertj> Will Launchpad do openID via MoinMoin at a later date?
<Seveas> robertj, ask in #launchpad 
<robertj> Seveas, thx
#ubuntu-devel 2006-03-10
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<ogra> doko, ping ?
<doko> ogra: got some work?
<ogra> :P
<ogra> i dont understand what you mean with bug 33753
<Ubugtu> malone bug 33753 in gnome-screensaver "no 2D screensavers available" [Major,Unconfirmed]  http://launchpad.net/bugs/33753
<ogra> xscreensaver-data is installed by ubuntu-desktop
<ogra> it contains all 2D screensavers from the selection we had enabled by default in warty/hoary/breezy
<doko> the thing is, if I do configure a random screensaver, I do not have a choice to disable the 3D screensavers
<ogra> apt-get remove xscreensaver-{gl,gl-extra}
<doko> ok, if these are installed, it's no regression, but it's still annoying
<ogra> i'll think of a better system for dapper +1 
<maswan> speaking of screensavers, I love linux-fsck, just for the pure evil of it. :)
<ogra> i.e. a virtual package so we can replace the screensavers underneath ...
<desrt> hmm
<desrt> is there a reason that bcm43xx.ko disappeared or was it an accident?
<Burgundavia> desrt: apparently BenC messed up
<BenC> desrt: accident, and will be back in next upload
<desrt> BenC; awesome.  sbp2 stuff is working great, btw.  thanks.
<mjg59> BenC: Pile o' patches for you
<mjg59> Still needs two more to work well (sound and PATA), but other than that things look good
<BenC> mjg59: saw them, thanks...but now you have to send me an x86 mac so I can test it all out :)
<mjg59> Haha
<mjg59> They're not all hugely clean, but with them a kernel boots with no extra hacky options
<LaserJock> BenC: wish I could send you mine but my boss might not like it :(
<Burgundavia> LaserJock: you are both continental US. It could be a one day thing
<LaserJock> Burgundavia: well, since it is technically owned by the University I really doubt they would be ok with me shipping it off somewhere
* Fade wonders why there's no sbcl candidate in dapper
<Burgundavia> Fade: sbcl?
<Fade> steel bank common lisp
<Fade> there are a bunch of stub packages for sbcl in dapper, but the main sbcl environment isn't there.
<Fade> clisp is in the pool, so sbcl has a bootstrap vector..
<Burgundavia> Fade: can you help with packaging it?
<Fade> I guess so. there's a well regarded package in debian, stable and devel.
<Fade> shouldn't be much problem to 'port' that src package.
<Burgundavia> Fade: #ubuntu-motu should be able to direct you in helping them
<Fade> what is that chanel?
<Burgundavia> motu is the Masters of the Universe. They maintain universe and multiverse
* Fade chuckles
<Fade> 'k. I'll ask there.
* lamont decides that he doesn't like dapper not booting on his amd64 machine.
* milli would find that an issue as well
<lamont> pci_mmcfg_read+239 --> some trap leading to panic
<desrt> so what's the story
<desrt> xscreensaver or gnome-screensaver?
<desrt> oh.  nevermind.  debfoster is being useless
<sivang> morning all!
<pitti> doko: ping
<zakame> hi all
<pitti> hi freeflying 
<freeflying> hi pitti 
* sivang hugs pitti 
<freeflying> pitti: any good news for CJK stuff,  :)
<pitti> freeflying: I'm uploading new language-support pakcages with im-switch now
<freeflying> pitti: also with scim module?
<pitti> freeflying: no, that needs seeding
<pitti> scim or skim should be in desktop, not language-support dependencies
<freeflying> pitti: I mean the module of scim .not scim and skim 
<minghua> freeflying, pitti: would either of you enlighten me why with language-support depending on im-switch, scim modules should drop their im-switch dependency completely?
<pitti> not necessarily
<pitti> freeflying: oh, the modules were already dependencies before
<freeflying> pitti: hehe
* pitti will go for some skiing
<pitti> have a nice Sunday everyone
<calc> mjg59: i think vista might use the new video brightness acpi extension
<calc> if so perhaps laptops will suck a bit less after its released later this year
<minghua> freeflying: I hope you are just busy instead of ignoreing my question
<minghua> freeflying: As I've said I am insterested in the actually changes on scim packages
<freeflying> minghua: just out , 
<minghua> freeflying: oh good
<minghua> freeflying: then can you explain?  oh at least point me the irc log that you discussed about this?
<freeflying> minghua: may I speak in chinese in #ubuntu-cn ?
<minghua> ok, if you prefer that way
<freeflying> minghua: for my poor English 
<minghua> freeflying: I am there now
<lifeless> hmm
<lifeless> is 24bit and 32bit equivalent for xorg purposes
<lifeless> ?
<doko> pitti:pong
<zakame> hmm referring to video resolution?
<lifeless> zakame: bit depth
<fabbione> lifeless: yes
<lifeless> zakame: I have a i815 dell with a fucked bios
<lifeless> erm
<lifeless> i915
<fabbione> lifeless: once you use 24 is like using 32
<fabbione> the 8 bit alpha is always initialized
<lifeless> but after the latest update its coming up in 1024x768 rather than 1280x768, like 915resolution is not kicking in properly
<lifeless> running 915resolution -l shows that the mode has been overwritten correctly though
<fabbione> well you asked for depth, not resolution :)
<lifeless> yes
<lifeless> but the i915 api is via the bios
<lifeless> X searched for a matching vidmode for the XxYxZ 
<lifeless> so I wanted to know if the internal mode matching logic will match 24 against 32
<fabbione> did you force Depth 32 in xorg.conf?
<lifeless> its set to 24 at the moment, which was working last week ;)
<fabbione> and still should
<lifeless> ok
<fabbione> afaik there have been no X upgrades
<lifeless> gdm or 915resolution ?
<fabbione> and basically the 8 bits are only alpha channels
<fabbione> dunno about 915.. gdm yes
<fabbione> but gdm shouldn't interfere with X in that regard
<fabbione> lifeless: check the 9115 changelog
<fabbione> and see if somebody screwed it
<fabbione> if so... blame him :P
<lifeless> fabbione: thank ;)
<lifeless> s
<lifeless> erm, you know what I mean :)
<fabbione> yeah
<fabbione> don't worry.. i got used to read aussie :)
<lifeless> just cause its upside down
<fabbione> eheh
<lifeless> ahha
<lifeless> someone moved gdm to S13
<lifeless> without moving 915resolution
<lifeless> fabbione: can I just tell you ? :)
<lifeless> bug 33774
<Ubugtu> malone bug 33774 in 915resolution "startup level is too high" [Normal,Unconfirmed]  http://launchpad.net/bugs/33774
<lifeless> is there an upgrader for gossips settins?
<lifeless> mjg59: hibernate is working
<lifeless> mjg59: all fixed, thanks. But it takes 8-10 minutes to go down.
<fabbione> lifeless: assign it to the same person that did change gdm :)
<lifeless> fabbione: ...
<lifeless> fabbione: will do
<lifeless> fabbione: its not in the changelog
<lifeless> fabbione: so I don't know who did it. Wish I could annotate :)
* fabbione -> food
<tepsipakki> mjg59: you didn't put those mactel-patches on launchpad?
<koke> hi! why is xchat-gnome being removed from ubuntu-desktop?
<cassidy> koke: i would like to know too. I asked question on desktop ML but received no response :\
<mdke> koke, i think the reason is that there is already one comprehensive IM client in Ubuntu, and having more than one can be confusing
<mdke> but I don't know for sure that was the reason it was removed
<cassidy> mdke: i hope you're not talking about gaim ;)
<mdke> sure I am
<koke> :D
<cassidy> imho x-g is *really* better for irc than gaim
<mdke> i agree, but that's not the point
<mdke> gaim does most other more common IM protocols too
<Kamion> the argument was that IRC is a relative minority interest and doesn't fit into the greatest-common-denominator goals of the Ubuntu desktop
<mdke> i think that is right. Although against that, it means that irc based support is cut out
<Kamion> (I'm not saying I agree - I haven't really thought enough about it to decide - but that's the argument)
<cassidy> Kamion: but we could try to avoid that by integrate loco team channel automatically for exemple (i wrote about this too)
<Kamion> OTOH, relying on IRC-based support is what gets us complaints from new users that people abused them on #ubuntu
<Kamion> cassidy: TBH I don't care much, I'm just reporting the argument
<mdke> sure, relying on irc based support is a bad idea, with launchpad and the forum doing good support, but irc is pretty useful because it's the only real-time one
<cassidy> yeah i know :)  Just i strongly disagree with this decision :)
<mdke> cassidy, you're biased :)
<cassidy> mdke: of course i am ;)
<wasabi> I think ya'll should have a Jabber conference server for support.
<wasabi> =)
<Pygi> liboil 0.3.7  broken on SSE enabled CPU's
<sivang> Pygi: please remind me what SSE enabled CPUs are ? ;-)
<Pygi> sivang: heh :-P
<sivang> Pygi: is this POWER cpus?
<Pygi> huh :-/ http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions :-/
<Pygi> that? :-/
<sivang> Pygi: ah I see
<Riddell> pradeepto: hi
<Riddell> tsk
<Gloubiboulga> could anyone have a look at http://revu.tauware.de/details.py?upid=2059 ?
<Gloubiboulga> UVF has been accepted for this package
<Gloubiboulga> sorry, wrong window
<Gloubiboulga> :/
<flint> fabbione, ciao Don Fabio!
<flint> mdz, you asleep?
<flint> it is late in london...
<flint> anybody out here got any ubuntu breezy audio chops?
<flint>   I need an assist on an interesting problem....
<CarlFK> whats a chop?
<flint> CarlFK, it is, in a word skill.  the deal here is that I think my sound went away when this particular machine was "upgraded" from "Linux ubuntu 2.6.12-9-386
<flint> " to "2.6.14.2-baseline-4.2baseline"
<flint> so what I am trying to figure out is what are the consequences to going back a kernel version....
<flint> maybe I should go bother the kernel folks....
<CarlFK> then not me - I don't do much with debugging audio
<tepsipakki> that's not an ubuntu kernel
<flint> tepsipakki, that is an interesting thing to say. which is not an ubuntu kernel?
<tepsipakki> 2.6.14.2-baseline-4.2baseline
<flint> tepsipakki, indeed and a good point.  More specifically it is:  vmlinuz-2.6.14.2-baseline-4.2
<tepsipakki> so it's not ubuntu anymore ;)
<flint> tepsipakki, is that closer to the fact?
<tepsipakki> breezy had 2.6.12, dapper has 2.6.15
<flint> tepsipakki, oh I wonder how this kernel got on this machine...
<Kamion> I'm pretty certain that no kernel by that name has ever been in Ubuntu
<flint> tepsipakki, thanks!!! maybe I will remap the kernel
<flint> Kamion, could it be the dreaded automatix script that did this thing?
<flint> I was doing a whole buncha mondo mindi work on this box.  you do not think that the kernel "leaked" into the boot?
<flint> tepsipakki, Kamion thanks and I mean it.  let me go and fool around with this one... you folks think i can manuall remap the kernel and maybe not have to boot off a cd to get the machine back?
<mdke> flint, you have no other kernels in there?
<siretart> flint: this automatix script is known to break systems in serious ways
<mdke> haven't heard about it removing the kernel though
<flint> mdke, vmlinuz-2.6.12-9-386
<flint>  is just sitting there ready to go.
<mdke> flint, that sounds a bit more positive
<mdke> use that one
<flint> vmlinuz-2.6.12-9-386
<flint>  is just sitting there ready to go...
<mdke> iirc, -10 is the latest one for breezy
<flint> gotcha, well gott go reboot, this is just like NT :^)
<tepsipakki> there should be 2.6.12-10
<Kamion> flint: never looked at automatix myself
<tepsipakki> echo
<flint> Kamion, tepsipakki it is like, if you do not go down any dark ally's you never get mugged...
<tepsipakki> now something OT, if you allow me: http://www.mathcaddy.com/windowsxpbootsonamac!!!!1/
<flint> I really wanted to play with multimedia...I am a bad man...
<flint> tepsipakki, that is really scary....
<flint> tepsipakki, nice art tho...
<flint> tepsipakki, thanks for the art and the idea.  gotta reboot. sksk
<Seveas> tepsipakki, you evil bastard
<Seveas> very funny though 
<tepsipakki> :)
<tepsipakki> those boots could easily be GIMPed..
<tepsipakki> but I'm sure our beloved installer/kernel dudes are faster ;)
<shaya> tseng: want me to do anything?
<shaya> you can have my attention for a bit
<shaya> hmm, he's not here
<shaya> oh well
<tseng> shaya: eh?
<shaya> mono bug
<shaya> want any more info frm me?
<tseng> what mono bug
<shaya> not able to run mono programs
<tseng> oh
<tseng> i asked you for specific info
<tseng> platform, versions of apps in question
#ubuntu-devel 2006-03-11
<shaya> I said, dapper
<shaya> platform I guess I missed
<shaya> x86
<cavediver> Hi guys, First off, you rock ! All of you. Then I have a question regarding cryptsetup-luks. Is there some plan on getting those volumes to interact with gnome-volume-manager so i don't have to mount through console ?
<cavediver> I know some guy on Red-hat is working on a solution that seems nice. But I'm not sure that are planned to go into Ubuntu in the future.
<desrt> are we going to have a new circle of friends for dapper?
<jdub> yeah
<HiddenWolf> way cool
<theCore> does I'm the only one who experience problems with xbsh ?
<desrt> http://www.fuplayer.org/
* desrt wonders how many of these are needed....
<floam> heh
<floam> why maintain a patchset when you can fork?!
<desrt> why get your patches accepted upstream when you can maintain a patchset?
<floam> well, not everyone's crazy idea is suitable
<desrt> is it a rb fork?
* lamont wonders why he has two spots under preferences labeled 'screensaver'... and why his screen doesn't lock anymore
<lamont> (hoary->breezy->dapper machine)
<desrt> lamont; apt-get remove xscreensaver
<lamont> well, that gets me down to one screensaver, albeit with none of the old preferences.
<lamont> mind you, it still doesn't lock...
<desrt> the lack of preferences in the new dialog is a bit annoyin
<joelbryan>  Hi!, what's wrong with my code? -- > http://pastebin.com/585160 I'm trying to switch views using a notebooks, but I get segmentation faults. Could someone help me?
<jdub> zul: eh
<jdub> zul: grub quietness patch!
<joelbryan> jdub: How do I get my software to be in mainstream with Ubuntu?
<mrd`> Write software that users want.
<joelbryan> Is it still open?
<jdub> joelbryan: that's a very big question. what's your software?
<mrd`> Dapper might not be, but in general I'm sure they'll add anything that users have an interest in and fits Ubuntu's goals.
<joelbryan> it's not yet released, I'm still doing it
<jdub> joelbryan: highly unlikely anything new would get into the 'main' repository at this stage
<joelbryan> yeah, should it be mature enough.
<Lathiat> Is it possible to demote binary packages to universe from a main source package?
<Lathiat> and have that count as 'unsupported' ?
<jdub> Lathiat: in some cases, we have
<Lathiat> (in this case, the avahi howl/bonjour compat packages, it seems silly to create a whole new avahi package just to put those in universe, as slomo seems to suggest the way around this)
<Lathiat> where as i thought you could just demote thingws
<infinity> Lathiat: Binary packages can only be demoted if the source is still fully self-contained in main.
<Lathiat> infinity: it is
<infinity> Lathiat: So, if avahi has to build-dep on stuff in universe to build those packages, the source needs to be in universe.
<Lathiat> they dont bring in any extra deps
<infinity> If not, then it should be fine to pop the packages in universe, but you'll still need to get some FeatureFreeze forgiveness to mangle a source package in main to produce new binaries.
<joelbryan> jdub: supposed a user just installed ubuntu, and he tries to click on an mp3, and there's a dialog that appears, "you are trying to play a media with proprietary codec, however we can convert those to OGG theora", should this be have legal problems too?
<joelbryan> s/theora/vorbis/g
<mrd`> You still need a proprietary codec to decode the mp3.
<ajmitch> Lathiat: it's still crack if apps in main need the avahi compat libs
<jdub> mrd`: you wouldn't need a proprietary codec
<Lathiat> ajmitch: sure, but it means people can use them themselves
<mrd`> jdub: To decode an mp3?
<Lathiat> ajmitch: and doign that otherwise is difficult 
<jdub> joelbryan: that would mean shipping an mp3 decoder, simply to do that conversion, which is the same thing as shipping an mp3 decoder to do the playing you're trying to avoid :-)
<joelbryan> mrd`: what if the user be prompted to enable his universe repos and automatically download ffmpeg2theora, should it have problems too, the package is available in universe, but not in the main cd
<mrd`> jdub: Sorry, I should say ``patented'', not proprietary.
<Lathiat> they either have to rebuild avahi or compile there own copy which is undesirable either way
<joelbryan> everything should be prompted to the user to enable his universe repos and auto download and install that packges
<joelbryan> should it have legal problems too?
<infinity> If we are seen to be encouraging users to install software they need a patent license to use, we may be in hot water, yes.
<joelbryan> ok
<mjg59> If we're /supplying/ software they need a patent license to use, we may be in hot water
<infinity> Having it passively reside in an archive that people can find if they look around is a grey area, but having something that says "you'll need this to play this, click here now" is no better than installing it by default.
<joelbryan> how about on the case of windows emulators?
<slomo_> Lathiat: i answered to your comment in the avahi-compat bug... could you please mail Kamion/mdz for a FF exception? and verify that packages demoted to universe are really unsupported?
<infinity> mjg59: Our repositories are filled with stuff you /may/ need a patent license to use.  Trick is that we don't install it by default, tell the users to install it, or any such thing, so users (in theory) can download it or not, depending on their own legal situation.  The whole thing, I admit, is twelve kinds of sketchy anyway.
<zul> jdub: yep..
<Lathiat> slomo_: i just asked that here
<mrd`> joelbryan: wine doesn't infringe any known patents.
<zul> jdub: it works ok for me right now..
<jdub> zul: that's one of my favourite bugs. thank you. :-)
<slomo_> Lathiat: ok... you write the FF exception mail?
<zul> jdub: no probs
<Lathiat> yep
<slomo_> Lathiat: thanks
<joelbryan> so should it be OK to ship an interface that when a user tries to open an exe file, software repos properties appears, and automatically download wine?
<mrd`> Or just install wine by default.
<infinity> Maybe I'm a cynic, but I figure we have enough of our own trojans and viruses to worry about, without helpfully giving users a gateway in the default install to run all the virsues for another OS on their system too.
<infinity> (No qualms about helpfully telling users how to execute windows binaries should they want to, though)
<mrd`> Right.
<joelbryan> jdub: I'm doing  simple dialog that has an option that says "speed up internet" and a dialog to install squid will appear, and have an option to "speed up system", and a dialog to install prelink appears. do you think a software like this could make it in Ubuntu?
<infinity> joelbryan: prelink appears to do Very Bad Things to initramfs right now..
<infinity> (as in, systems become unbootable)
<joelbryan> infinity: how about squid?
<infinity> I need to look into it, but I wouldn't want to recommend it to non-technical users until we know it works right.
<infinity> squid?  <shrug>... Should be fine, but how much do you really gain in proxying a single user?
<infinity> Users who want proxies should use their ISP, generally (or proxy the home network, or, or)
<joelbryan> infinity: it speeds up their browsing experience.
<mrd`> joelbryan: How?
<infinity> Only if they A) hit the same page over and over again, and B) aren't doing so explicitly to look for new content (in which case, they'll do a hard refresh, invalidate the cache, and round-trip to the remote system anyway)
<mrd`> joelbryan: For a single user.
<slomo_> and browser have caches too...
<joelbryan> squid caches the webpages you visited, so you don't have to download it again.
<infinity> joelbryan: Which your web browser also does.
<mrd`> I don't think that anyone's contesting squid can speed up a whole network, but on a single machine it's not as useful.
<joelbryan> I have a dsl, and my gf only has a dialup, I installed squid in her pc, and I can say, it's speed up everything, responces, and low bandwidth consumption.
<joelbryan> comparable to my connection, when I browse, everything is re downloaded again
<joelbryan> but for her using a dialup, the speed and response time and bandwidth consumption are dramatically lower.
<joelbryan> it' loads up instantly!
<joelbryan> mrd`: not only just a single user can use it,.
<joelbryan> should it be a good idea for the Ubuntu Marketing team to ask the record album artist to ship Ubuntu CD's in their album, other possibilites is they included the OGG video or audio in 
<robertj> does totem run regionset in dapper if needed?
<desrt> robertj; i seriously doubt it
<robertj> https://launchpad.net/distros/ubuntu/+source/libdvdread/+bug/16722
<Ubugtu> malone bug 16722 in libdvdread "Unable to read DVD (video) on brand new laptop (with possible solution)" [Normal,Unconfirmed]  
<robertj> someone want to confirm that?
<infinity> robertj: Yes, it's a valid bug, but I'm not sure where the fix belongs... (blindly calling regionset and setting the region to something the user doesn't want is definitely a no-no, so players need to have some GUI popups or something to trigger the change themselves if they suspect it's needed)
<joelbryan> I have a desktop proposal, because I believe that in the future, everything should be treated as objects, like when I click a directory, they don't see other things that concerns them, they see their files. I believe in spatial, but the previous spatial proves to be uneffective to some. So here's my proposal, should I say this is an evolution of spatial. there' are two commands to make this happen, the first is, gconftool-2 -t string -s /deskt
<joelbryan> op/gnome/interface/toolbar_style "icons" this set's the default "Both" into "Icons, and the second is "gconftool-2 -t boolean -s /apps/nautilus/preferences/start_with_sidebar "0" ", this does not start the sidebar at start. It affects, alot of applications, like gthumb and eog, and it makes everything feels like an object.
<joelbryan> :-( seems like I'm +i (ignored) here... :-(
<robertj> infinity, what about setting it according to their locale if it's unset?
<robertj> they would still have several more tries
<robertj> infinity, thoughts?
<infinity> robertj: Until some manufacturer decides to make a "one-try-and-that's-it" drive, and users hunt you down and hurt you because you just locked their firmware on a region they don't own any discs in.
<robertj> infinity, that's not standardized?
<infinity> (And if you think that's far-fetched, realise that it's exactly what the MPAA wants, and they are very pursuasive...)
<infinity> I don't think setting a region without first asking the user is EVER a good idea.
<infinity> Windows doesn't do it either (but all the windows players, and the underlying subsystem, have GUIs to ask you about it)
<lamont> infinity++
<infinity> lamont: Care to look at the glib2.0 FTBFS on ia64 and sort out why it hates you?
<robertj> infinity, what about hooking it into the gstreamer plugin?
<stub> Launchpad will be going down in 15 minutes. Estimated down time is 'up to 3 hours', as we are migrating the backend PostgreSQL instance to a new and improved server. Wikis will be in read only mode during this time.
<infinity> lamont: That's the only thing (afaict) blocking rebuilding the GTK/GNOME stack on ia64 and getting it installable again.
<lamont> infinity: ok
<jdub> glib loves lamont
<jdub> it just hates ia64!
* lamont looks for his urban broadsoard
<lamont> sword even
<jdub> elmo: taking sync requests here?
<elmo> jdub: sure
<elmo> (they won't get actioned till I win my fight with LP tho - which is unlikely to be tonight)
<jdub> ahr
<jdub> elmo: please sync lighttpd 1.4.10-4 from unstable :-)
<mjg59> Hurrah.
* mjg59 gets the kernel into a state where it'll install a Mac without breaking anything else
<jdub> mjg59: ooh
<mjg59> Just sound to get working now, really
<Lathiat> on the intelmac or a ppc mac?
<mjg59> Intel
<Lathiat> cool
<Lathiat> what was it breaking before?
<mjg59> Well, a variety of stuff was broken
<ajmitch> what sound chip does the intel mac use?
<mjg59> HDA
<mjg59> Need to poke that a little
<ajmitch> there's been some recent work done with that in alsa 
* ajmitch finally got laptop sound yesterday
<mjg59> Cool
* psusi is growing concerend that the intellimouse regression has not been fixed yet and dapper is only 10 days away
<psusi> err
* psusi shouldn't try to do math while drinking
<psusi> hrm... why was I thinking I saw earlier release was on the 15th?  oh well, still have over a month
* Kyral is away: Shower!
<robertj> infinity, would it be acceptable to allow a non-admin user to set the DVD region assuming there would be at least one change remaining after that user set it?
<carlk> robertj: why would you want that?
<infinity> robertj: So, a non-admin user gets into a "region war" with the actual administrator(s) of the machine, until you run out of changes and get locked in? :)
* infinity is thinking of university labs, for instance, where a user may decide that the region should really be whizz-bang region foo so he can watch his cool import DVD, then the admin has to set it back to the correct region for the machine and gets locked in.
<infinity> In short, given that region setting is something that actually affects the hardware (well, the firmware) of the machine in a permanent way, I don't see that non-admin users should ever get to touch it.
<psusi> don't use regions at all and you don't have to worry about it ;)
<psusi> can you even do that in linux?  I thought you just allways used libdecss which bypasses the region coding anyhow
<infinity> No, it won't bypass correctly on a machine that doesn't have an initial region set at all.
<infinity> To play region 4 DVDs on my new laptop with libdvdcss, I still had to set the region (which I set to 1) the first time.
<psusi> eh?  I thought the region code was checked during decryption, which is bypassed by libdecss?
<infinity> Whether this is a libdvdcss bug, a strange behaviour of most DVD drive firmware or what, I don't know.
<psusi> I'm sure I remember reading that whatever ripping software I used back in windows also bypassed the region check
<infinity> Trust me on this, you need *A* region set, even if it's the incorrect one.
<carlk> robertj: seems you are sugesting that threre would the case be where the admin would want to leave it up to the user
<infinity> Which seems unlikely.  As an admin, I'd never say "here, have your way with my firmware"... If I trusted them that much, they'd be in the "admin" group.
<carlk> right.
<jdub> mjg59: ping
<jdub> mjg59: never mind
<desrt> pfah.  psusi troublemaker :p
* jdub growls at consumer electronics stupidity
<jdub> how would a normal human being understand that a miniplug socket might actually be 'digital optical' compatible if you have the right cable adapter?
<desrt> jdub; if you know enough to be angry at the consumer-grade product then they've got a good chance of making you buy the expensive one
<desrt> like, spdif style?
<jdub> you can get an adapter from miniplug (3.5" jack) to toslink (spdif)
<desrt> the miniplug is spdif too
<jdub> and various hardware have miniplug sockets that do analogue and digital
<desrt> spdif also comes in an RCA jack flavour
<desrt> it's all the same thing
<jdub> yet normal human beings would never actually know any of the above
<desrt> true story
<jdub> because it's stupid consumer electronics insanity
<jdub> so apple can say that the mac mini has digital optical and analogue miniplug socket
<desrt> i wouldn't be suprised of the 'adaptor' was an LED
<desrt> *if
<jdub> but it took even me a while to figure out how that worked
<desrt> http://www.cablesnmor.com/index.asp?PageAction=VIEWPROD&ProdID=213
<desrt> seriously.  i bet it's just an LED :)
<desrt> ....alternatively
<desrt> i wonder if they do the conversion for you... like if inside the minijack there's a little laser
<desrt> if you put in a normal plug, nothing happens... but you can put in a fibre optic plug that is open to the laser light
<desrt> in that case they may be able to legitimately claim optical support
<carlk> or just flash the led all the time
<carlk> not like it is going to wear out anytime soon
<desrt> right... this is what i mean by "nothing happens"
<desrt> it flashes and nobody notices
<carlk> how sad
<desrt> k.  this appears to be true.
<desrt> it's called 'minijack optical'
<jdub> so the minijack->toslink converter is a correctly moulded HOLE?
<carlk> ;p;
<desrt> well.. there's probably some clear plastic in there
<carlk> er...
<carlk> wow
<ajmitch> don't underestimate the power of marketing
<carlk> is there a gold plated version?
<carlk> cuz the rep was in here last week and showed us the results of tests done with o-scopes and sound proof rooms.  the numbers don't lie
<G0SUB> jdub there?
<pitti> Good morning
<freeflying> pitti: morning
<ajmitch> hi pitti 
<pitti> hi guys
<sivang> morning all
<sivang> hi pitti 
<pitti> hi sivang 
* pitti waves to janimo 
<janimo> pitti, morgen
<sivang> jo janimo 
<janimo> hey sivang
<janimo> how's the backup tool going?
<sivang> janimo: very good :-) Starting to see the end, I'v overcame all of the process and generator funcions problem, and even made the progress not block and the GUI not block when the underlying processing is heavy. All left now is to add CD burning, and propogate the slice change messages from the BackupEngine.py backend to the PyGTK frontend.
<janimo> what will you use for cd burning?
<Triskelios> I'm trying to make a breezy-based live cd set netcfg settings based on the ethernet card's mac address; it seems that a preseed/include_command is way too early for this (the drivers haven't been loaded yet). what would be a good solution for this?
<sivang> as it seems now I have two options, libnautilus-cd-burn, or cdrecord. What do you think would be best?
<janimo> sivang, don;t know honestly
<janimo> going via cdrecord will allow you backup to be easier used with kubuntu though
<sivang> however, if I use libnautilus-cd-burn, this may incur yet another dependency that other desktops might not want  to ship by default.
<sivang> yes, exactly :)
<sivang> also, I need to probably think about Xubuntu 
<janimo> that is not as far from gnome as kde
<janimo> but using nautilus would cause the same effect there
<sivang> I see. In any event, I am keeping the backend agnostic of desktop software, so that means that it's going to be cdrecord :-)
<janimo> have you looked around to see if there's already cdrecord pythn frontends?
<janimo> I remember seeing one that starts with an e but don;t know th erest of the name
<sivang> (already went through great deal of trouble to keep it that way, for instance I did not use gobject stuff for process monitoring and io watching in the backend)
<sivang> janimo: oo, that would be very useful for me instead of re-inventing the wheel, you say it starts with an e?
<janimo> sivang, well python is high level enough to notneed gobject and other libs C apps frequently use
<dooglus> http://sourceforge.net/projects/eroaster/ is a graphical frontend for cdrecord, mkisofs written in gnome-python
<janimo> sivang, yes
<janimo> hmm could be eroaster, but I somehow remembered a more exotic name
<sivang> dooglus: Heh, thanks Chris!
<dooglus> hi.  sorry I fell asleep on you last night.  I could have helped with your signal problem if I was awake
<sivang> dooglus: I'm sure :-) However, in python as in python it usually only means you need to include the right module, so un-surprisingly, it was named "signal" ;-)
<sivang> (comes with batteris already included and all that good stuff etc)
<dooglus> sivang: you've discovered http://docs.python.org/lib/modindex.html I guess?
<sivang> dooglus: yes, I know that location, however I got the bad habit of firing ipython and importing a guessed module name, that's how I experiment with signal last night , need to ditch this :-)
* sivang dist-upgrades
<saads> does anyone know what the development status of kraal is?
<sivang> oh bad, eroaster is not even oprational :)
<sivang> even creating an iso image file doesn't really work 
<sivang> no errors messages, no explenation why..
<sivang> oh well, "use the source luke" maybe there will be some insighs there to use cdrecord more then I have already thought of.
<dholbach> good morning!
<sivang> morning :)
<janimo> hey dholbach
<Mithrandir> dholbach: I've merged your example-content bzr stuff now, going to upload a new casper in a few minutes.
<freeflying> Mithrandir: any docs for casper now ?
<dholbach> Mithrandir: woohoo - did that really work?
<Mithrandir> dholbach: no. :-)  I just move the symlink after adding the user instead.
<dholbach> Mithrandir: ah right - cool, thanks!
<Mithrandir> freeflying: no, because none of the ten people who have offered to write howtos after I've told them how to customise the image has actually done what they promised they would. :-(
<freeflying> Mithrandir: then would you mind tell me how to do like that ?  hmm
<Mithrandir> dholbach: uploaded.
<Mithrandir> freeflying: not now, sorry.
* dholbach hugs Mithrandir
<freeflying> Mithrandir: if it possible , plz mail me ,thx, I'm customising kubuntu dapper livecd for chinese support
<Mithrandir> freeflying: email address?
<freeflying> Mithrandir: zhengpeng-hou@ubuntu.com
<Mithrandir> freeflying: actually, can you send me an email about it (tfheen@ubuntu.com) and I'll get to it.
<freeflying> Mithrandir: sent it .
<Mithrandir> thanks
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity | dapper severly broken for anything but KDE apps | LP moved to new DB, may have hiccoughs, please report any *NEW
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity | dapper severly broken for anything but KDE apps | LP moved to new DB, report *NEW* oddness on #launchpad
<mdke> what's this "dapper severely broken for anything by KDE apps" business? works ok here
<mdke> must be some kind of plot
<Kinnison> must be
* Kinnison didn't add that
<mdke> Kinnison, delete it and you can have more space for your *NEW* oddness :)
<Kinnison> hehe
<Kinnison> Kamion: I have a new upstream of g-p-m which richard strongly recommends I take. I'll do that and then get on with gparted
<Kinnison> Kamion: okay?
<ploum> http://www.sunsilk.fr/main_product/Home_Range_Eusunsilk/1,,10-1-1,00.html : the first Ubuntu Shampoo
<mdke> ploum, damn people love copying that logo
<ploum> mdke: so it must be a good one ;-)
<mdke> mm
<ploum> Do you want Ubuntu hair ?
* ploum find that "Ubuntu Shampoo" is a really good name for a release or a project or anything
<mdke> sabdfl, morning. ploum just posted this before you came in: http://www.sunsilk.fr/main_product/Home_Range_Eusunsilk/1,,10-1-1,00.html
<Treenaks> OMG?
<ploum> hello Treenaks :-)
<Treenaks> ploum: hi
<Treenaks> My 'moviegotchi' videos are quite popular since last week :)
<Treenaks> It was on Planeta Ubuntu Brasil and on ubuntu.wordpress.com :)
<ploum> Treenaks: a friend found this screenshot on a forum : http://gaspar.celeonet.fr/roidelapluie/lexpage/Screenshot-12.png
<Treenaks> ploum: cool
* ploum will now be called "big nose"
<sabdfl> hi all
<ploum> hello sabdfl
<freeflying> hey sabdfl 
<sabdfl> mdke: i'm really struggling with the options there
* ..[topic/#ubuntu-devel:sabdfl] : 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 | dapper severly broken for anything but KDE apps | LP moved to new DB, report *NEW* oddness on #launchpad | UI 
<mdke> sabdfl, red
* lifeless lols @ the *NEW*
* ..[topic/#ubuntu-devel:sabdfl] : 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
<azeem> what UI exactly is the sprint about?
<ploum> shiny blond i a cool option too ;-)
<mdke> azeem, the Ubuntu one
<azeem> ok
<ogra> dholbach, ping ?
<dholbach> ogra: pong
<ogra> dholbach, no trace of my g-s-s -> eog fullscreen patch ?
<dholbach> ogra: hm?
<ogra> i thought they included it 
<dholbach> ogra: oh, letme check
<dholbach> ogra: it's part of it
<ogra> bug #5587
<Ubugtu> malone bug 5587 in gnome-screensaver "Strange behaviour when Image Viewer is on full screen(F5)" [Normal,Confirmed]  http://launchpad.net/bugs/5587
<ogra> ah, k
<dholbach> ogra: just didn't show up in the NEWS file, I suppose
<ploum> just a question : will gthumb still be the default image viewer in Dapper ?
<ogra> then i can close the bug, thats all i needed, thanks 
<ploum> sorry, wrong chan ( will ask on #u-desktop)
<Treenaks> ogra: totem-gstreamer disables the screensaver nicely here (screensaver 'hack' programs don't start), but the screen still goes blank (DPMS settings?) when watching a movie... is this a known bug?
<Treenaks> ogra: or doesn't it disable g-s at all and are my g-s settings bugged?
<ogra> Treenaks, oh, no... and thats handled by gnome-power-manager ... i'll have to check where and how we have to fix it ...
<ogra> g-s-s does the action, but g-p-m is responsible for the setting
<Treenaks> ah
<Treenaks> and it's known, so I won't file it then
<cjwatson> grr @ home machine choosing this particular time to fall off the network
<ogra> Treenaks, nope, its not known ...
<ogra> Keybuk, !
<ogra> ogra@edubuntu:/mnt/devel/bazaar/LtspManager/bzr$ sudo rm -rf /opt/ltsp/powerpc
<ogra> rm: cannot remove directory `/opt/ltsp/powerpc/var/lock': Device or resource busy
<ogra> rm: cannot remove directory `/opt/ltsp/powerpc/var/run': Device or resource busy
<ogra> Keybuk, anything i can do to get rid of them to get the directory clean ? 
<Keybuk> do you need to unmount them?
<StevenK> ogra: They're both tmpfs', umount them?
<StevenK> s/'//
<ogra> Keybuk, there is no mtab in my chroot ...
<ogra> and no mounted /proc ...
<Keybuk> ogra: just unmount the directory, mtab is pointless :)
<Keybuk> you end up with a mounted /var/lock and /var/run if you debootstrap in a chroot
<ogra> yes
<Keybuk> umount /opt/ltsp/powerpc/var/lock should just work
<ogra> ah, it does ...
<ogra> i never tried it outside the chroot :P
<Keybuk> I guess you installed that > 2 weeks ago, and haven't rebooted since?
* StevenK sighs as MJ Ray some more.
<ogra> ah, no, but i'm boostrapping from flight4 
<Keybuk> ah :)
<ogra> ok, thanks :)+
<ploum> Treenaks: does totem-gstreamer work for you ?
<ploum> nothing works here
<Treenaks> ploum: yeah, it works great
<ploum> but only for totem
<Treenaks> ploum: you need gstreamer0.10-plugins* and maybe gstreamer0.10-ffmpeg
<ploum> since an upgrade, a few days ago, totem is broken
<Treenaks> at least, for me
<ploum> Treenaks: I have it
<Treenaks> hmm
<Treenaks> --> seb/dholbach
<dholbach> "broken"?
<ploum> dholbach: yes. Totem start and doesn't play anything. The screen is black, the slider will not move
<ploum> he, I see this error at start (in a cli) :
<ploum> OIL: ERROR liboiltest.c 368: oil_test_check_impl(): function fbCompositeSolid_nx8888mmx in class composite_over_argb_const_src failed check (1,67772e+07 > 100) outside=0
<Treenaks> ploum: ah, that's why it works for me: I use it on powerpc -- which has no mmx
<ploum> (I don(t use Xgl, I swear ;-) )
<dholbach> ploum: you have the newest version of liboil?
<dholbach> ploum: i'm quite sure i fixed that bug in liboil
<ploum> dholbach: I look... no
<crimsun> ploum: test case online?
<ploum> indeed
<cjwatson> Kinnison: paste me that stuff about the g-p-m update again?
<ploum> dholbach: fixed, sorry for the noise !
<ploum> Thank you
<dholbach> ploum: cool
<pitti> hi slomo
<slomo> hi pitti 
<Kinnison> cjwatson: sorry, 'net connection went phut
<cjwatson> Kinnison: likewise ... try /msg maybe
<Kinnison> cjwatson: Basically it's 2.13.93 of gnome-power-manager
<Kinnison> cjwatson: http://ftp.gnome.org/pub/GNOME/sources/gnome-power-manager/2.13/gnome-power-manager-2.13.93.news
<cjwatson> Kinnison: OK
<Kinnison> cjwatson: thanks
<Kinnison> cjwatson: did the archive cycle okay?
<cjwatson> Kinnison: on Saturday? yeah, worked great
<Kinnison> I meant just now
<Kinnison> Looks like the log was fine
<Kinnison> (new DB server)
<Kinnison> my 'net went phut just before the cycle
<cjwatson> Kinnison: oh, haven't been looking, I'm at the UI sprint
<Kinnison> :-)
<sivang> cjwatson: new nick? :)
<ploum> Ubuntu "Shampoo Snake" release. That's a cool name
<cjwatson> sivang: home box randomly off the network, I'm elsewhere
* ploum just found it when looking at the shampoo logo
<irvin> ploum, you there?
<ploum> irvin: yep
<mdke> I remember in this release cycle, there was no backports repository until Dapper opened, which meant that people activating backports earlier (but after Breezy was stable) received errors. Is the same thing going to happen again when Dapper goes stable? Or is an empty repository going to be set up? Either way I'd like to know so we can document it.
<infinity> Kinnison: Hrm, that new g-p-m doesn't seem to fix my bug (at least, not according to upstream's changelog)
<infinity> Kinnison: Any hopes of reverting it for Ubuntu only, while you argue with upstream?
<Kinnison> infinity: upstream are still pondering
<Kinnison> infinity: I can look into reverting it for now
<Kinnison> cjwatson: I have had a look at gparted 0.2.2 -- lots of fixes which might interest us -- the installer-mode patch stands almost no chance of applying straight-off
<Kinnison> cjwatson: I think four of about twenty hunks apply
<infinity> Kinnison: Pretty please? :)
<dholbach> Kinnison: that's what i saw too :/
<Kinnison> cjwatson: I'll get the outward functionality into 0.1 and then look at porting the patch to 0.2.2
<Kinnison> cjwatson: so that I'm not blocking the installer
<Kinnison> cjwatson: sound okay?
<cjwatson> Kinnison: sounds fine - as long as it keeps working for us in dapper
<Kinnison> cjwatson: cool. Hopefully I'll have this package for g-p-m finished soon, currently a bit blocked on my laptop's hard drive having some spare IO bandwidth :-)
* Kinnison ponders lunch
<mdke> anyone on my backports question?
<cjwatson> mdke: /dists/dapper-backports/ already exists ...
<mdke> cjwatson, well that solves my problem entirely, thanks
<mvo> Kinnison: do you got a bugreport already about g-p-m going to suspend when the power is unplugged?
<Kinnison> mvo: is your lid closed?
<mvo> Kinnison: no, I just unplugged the power from the laptop
<mjg59> Kinnison: I've actually seen that (open lid)
<mjg59> Only once, though
<mvo> it seems to be happening all the time here
<mjg59> Ah. I closed, unplugged, plugged back in, opened, unplugged
<Kinnison> there was a bug in one version where it wouldn't notice a lid opening
<mjg59> And then it suspended
<Kinnison> that should have been fixed last upload
<mvo> lid is open, I work on it. then I want to move a couple of meters to show what I do to someone else and unplug it to move it
<mvo> it goes to sleep then
<Kinnison> sounds like it's confused about lid state
<Kinnison> are you running 2.13.92+CVS.... ?
<mvo> 2.13.92+CVS20060302-0ubuntu1
<Kinnison> arse, shouldn't happen
<mvo> my seting is to go to suspend when the lid is closed
<Kinnison> I have a new version currently undergoing testing
<Kinnison> temporary fix is to change that to "nothing" or similar
<mvo> right
<mvo> I'm happy to test a new version
<Kinnison> once I have it building I'll let you know :-)
<mvo> .9
<mvo> :)
<mojo_1> i am trying to work out here why turning on GOOM Visual will render playing MP3 not work. Maybe some1 here has know issues can give me some technical discussion or advice?
<zul> heylo
<doko> cjwatson, elmo: please remove the following sources from dapper: openoffice.org2-helpcontent openoffice.org2-amd64 openoffice.org2-l10n openoffice.org2 openoffice.org-debian-files
<cjwatson> doko: can't, see https://launchpad.net/products/soyuz/+bug/32314
<Ubugtu> malone bug 32314 in soyuz "remove-package.py pretends to work and then does nothing" [Normal,Unconfirmed]  
<seb128> doko: FC has the "orientation" option for openoffice printing
<Mithrandir> Diziet: why doesn't firefox handle button 8 and 9 as forward/back any more?
<doko> seb128: ok, I'll enable it for the next upload ...
<seb128> thank you
<doko> seb128: but please check that it works!
<seb128> I'll do after UI sprint
<cjwatson> Mithrandir: readahead is still making the live CD take eons to boot
<cjwatson> in vmware
<cjwatson> can we disable that?
<cjwatson> or does it work on normal hardware?
<Mithrandir> cjwatson: I can test on this system in a bit.
<cjwatson> ta
<Mithrandir> but yeah, I think we should have a disable-readahead option
<Mithrandir> speaking of which, why do we care to sort the blocks?  The I/O scheduler should be able to do that by itself?
<cjwatson> no idea :)
<janimo> cjwatson, is libswitch and gnetswitch in NEW source?
<janimo> or very similarly named packages anyway
<Mithrandir> Keybuk: prod?
<cjwatson> janimo: yeah, I had some concerns about at least one of those and sent mail to the uploader
<janimo> cjwatson: thanks, what about evince-gtk?
<janimo> cjwatson: who uploaded netswitch btw?
<freeflying> cjwatson: how about the scim-pinyin stuff
<cjwatson> janimo: all still there, I'm busy today, dunno
<janimo> cjwatson: no hurry then
<cjwatson> freeflying: you got an approval, and I don't see anything in NEW - what about it?
<Kinnison> cjwatson: moving onto gparted now
<freeflying> cjwatson: I've corrected the issue you point out , and reupload it to REVU
<cjwatson> freeflying: REVU and universe are not my responsibility unless they happen to land in NEW
<freeflying> cjwatson: sorry, then what shall I do ?
<Mithrandir> cjwatson: I'm rewriting the kbd-chooser widget to use kbd-chooser instead of console-data again.  Less hassle.
<cjwatson> freeflying: ask #ubuntu-motu
<janimo> freeflying: can you upload to universe?
<Mithrandir> cjwatson: jfyi
<cjwatson> Mithrandir: ok
<freeflying> janimo: can not
<janimo> freeflying: and you are trying to get a NEW package into universe or main?
<freeflying> janimo: not a NEW
<janimo> freeflying: so you just need a motu to sponsor you upload right?
<freeflying> jamesh: an UVF
<cjwatson> freeflying did try to upload something himself but it was rejected
<janimo> you need to mail the motu list with req for exception as is done for the rest of packages
<cjwatson> I've given the exception already, since it's targeted at main
<cjwatson> or at least will eventually be moved to main
<cjwatson> although it's in universe right now
<freeflying> cjwatson: that's a wrong upload , I forget add revu 
<cjwatson> he needs a review and sponsorship
<janimo> freeflying: point me to the package on revu 
<freeflying> jamesh: http://revu.tauware.de/details.py?upid=2102
<janimo> and indeed ubuntu-motu is the place to request reviewers/sponsors
<ogra> doko, dod you request the syncs for python2.4-pullparser and python2.4-clientform as well ? zope3 is still not installable and i see no trace of these two
<joelbryan> Isn't X-Chat duplicated with GAIM IRC?
<Robot101> except that gaim makes a horrific IRC client
<mdke> joelbryan, no, xchat doesn't come with Ubuntu by default now
<joelbryan> I'm using GAIM IRC right now, and it looks great.
<mdke> joelbryan, but otherwise, both programs do IRC. But in the open source world, it is common to have lots of programs that do the same thing
<joelbryan> I'm pertaining to x-chat-gnome
<mdke> for example, firefox, epiphany, etc all do web browsing
<mdke> joelbryan, xchat-gnome doesn't come with Ubuntu by default now either
<joelbryan> yeah, but it's in the scope regarding duplication
<joelbryan> mdke: thanks for telling me
<mdke> np
<joelbryan> mdke: in flight-cd 4, x-chat gnome comes default, you mean, the main release will not include it?
<Mithrandir> joelbryan: that has been changed already.
<cjwatson> joelbryan: changed since Flight CD 4, although up for debate
<cjwatson> because now irc:// URLs don't work
<ogra> yeah
<mdke> can't GAIM handle them?
<cjwatson> maybe it can, but it doesn't at the moment :-)
<mdke> right
<joelbryan> I think gaim irc looks great
<mdke> let's hope it can do those urls
<joelbryan> not for spamming you with gaim, but IMO, it's nice, well I like x-chat gnome too, coz it's simple.
<doko_> seb128: re-reading http://qa.openoffice.org/issues/show_bug.cgi?id=14036, why do you want to have it enabled?
<linuxdev> hi all, is there a html render library in linux??
<ogra> doko_, did you see my message above ? 
<seb128> doko_: that bug is marked as winXP, it's not clear it happens under linux to me
<jdub> linuxdev: you could use firefox/mozilla's engine, but it can be tough to use :)
<seb128> doko_: and FC activate the option, that's probably for a reason
<joelbryan> linuxdev: gtkmozembed, gtkhtml3
<doko_> ogra: ?
<joelbryan> my firefox keeps crashing when I visit flash sites.
<ogra> doko_, dod you request the syncs for python2.4-pullparser and python2.4-clientform as well ? zope3 is still not installable and i see no trace of these two
<doko_> hmm, ok, I will "sync" them myself
<ogra> :)
<Treenaks> Keybuk: ping?
<joelbryan> are the metacity deb packages (2.13.144) are maintainer builds?
<seb128> no, they are buildd builds, like every other package
<seb128> we do sources uploads for Ubuntu
<joelbryan> I have tried to enable startup notification, session management and hmmp (composite extension)
<seb128> startup notification?
<seb128> what do you mean?
<joelbryan> startup notification looks cool
<seb128> what does it do?
<zul> anyone seen jbailey around?
<janimo> seb128, the turning mouse cursor while loading the app I assume
<joelbryan> it's when you drag an icon, you can see the icon while dragging, check out.  http://www.gnome.org/~clarkbw/blog/GNOME/fun_startup_stuff
<linuxdev> jdub, joelbryan: is it possible to have a html render without the support of Xwindows???
<janimo> libstartup-notification
<seb128> janimo: it's already doing that, no?
<joelbryan> linuxdev: framebuffer? I don't know... :-(
<janimo> seb128, I did not catch the beginning of the discussion, he said he enabled that on some package
<janimo> Iassumed he links to that libs whereas it did not before
<seb128> janimo: he said he built the package with that
<seb128> no
<janimo> what package?
<joelbryan> yes, I'm trying to include (hmmp!!) compositor
<Lathiat> kde does something like that when it adds applets to the panel
<linuxdev> joelbryan: I don't know how to make use of framebuffer .....
<Lathiat> it animates into the panel
<janimo> joelbryan: is that a new package?
<joelbryan> I get it using apt-get source
<seb128> change debian/rules for it
<joelbryan> I installed alot of libs, libcm7 libcm-dev libxrender-dev libxdamage-dev libxcursor-dev xfixes-dev libstartup-notification0-dev xcomposite-dev libxtst-dev mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev libglitz1-dev libglitz-glx1-dev
<seb128> that's a build option
<janimo> joelbryan: what's the package name?
<joelbryan> yes
<joelbryan> metacity 2.13.144
<joelbryan> sudo apt-get source metacity
<janimo> joelbryan: in that case seb is right you already have startup notification in
<joelbryan> this will include startup-notification, session management in metacity -- configure --enable-maintainer-mode --enable-compile-warnings --prefix=/usr
<seb128> that will not activate any fancy option no
<joelbryan> I can't build the compositor, tried fixing it.
<doko_> huh? pydev upload? who is Vladimir Lapacek?
<joelbryan> use --enable-compositor to compile metacity with compositor
<doko_> dholbach: ^^^ ?
<dholbach> doko_: no idea
<dholbach> doko_: I have no idea what you are talking about
<torkel> joelbryan: check out spiftacity
<Treenaks> Keybuk: (does the initramfs honor the )
<ogra> dholbach, http://tiber.tauware.de/details.py?upid=1770
<ogra> doko_, ^^^
<Treenaks> Keybuk: (does the initramfs honor the md= command line arguments, like md would if it wasn't built as a module?)
<dholbach> ogra: it's not approved by anyone
<dholbach> ogra, doko_: what's the problem atm?
<ogra> dholbach, Betreff: 	Accepted pydev 0.9.8.3-1 (source)
<ogra> Datum: 	Mon, 06 Mar 2006 12:43:44 -0000  (13:43 CET)
<ogra> see -changes
<joelbryan> torkel: is spiftacity also metacity?
<ogra> dholbach, someone uploaded it
<janimo> freeflying: the package looks nice, I'd vote for it but looks I cannot do that on revu
<dholbach> ogra: who signed the mail?
<freeflying> jamesh: thx
<torkel> joelbryan: http://packages.ubuntu.com/dapper/x11/spiftacity
<janimo> for getting rid of that last lintian warning look at dh_makeshlibdeps -X
<joelbryan> cool, it's a devel version of metacity.
<ogra> dholbach,  Vladimir Lapacek <vladimir.lapacek@gmail.com>
<dholbach> ogra: signed it?
<janimo> also if you do not dislike it try cdbs it would make you rules file a lot smaller, you do not seem to use anything fancy
<ogra> dholbach, i cant see any other signatures on -changes
<doko_> dholbach, ogra: forget it ... ./org.python.pydev/retroweaver-rt.jar  <-- ships binaries = jars, doesn't build from source ...
<ogra> ah, k
<Robot101> argggh
<dholbach> doko_: I still have no idea what the problem is and what I can/should do about it
<Robot101> is there any chance of newer fixed dbus in dapper?
<Robot101> 0.60 has gaping holes in the glib bindings and deadlocks and stuff
<doko_> dholbach: Mr, MOTUmaster, I just wanted to have an idea who did approve that thing
<ogra> dholbach, i guess doko_ just wanted to ask why MOTU uploaded it ..
<dholbach> right
<dholbach> well... sorry: no idea
<joelbryan> torkel: how do I use composite? shall I restart my x session?
<ogra> hey mdz_ 
<ogra> welcome in europe again :)
<Robot101> sjoerd: who's in charge of dapper's d-bus?
<sivang> pitti I think
<sjoerd> Robot101: dunno 
<sivang> torkel: is spiftacity has anything to do with aiglx ?
<Mithrandir> joelbryan: please, this channel is for discussion of Ubuntu development, not user questions.  Please ask in #ubuntu.
<pitti> Robot101: I'm the person who is closest to the idea of 'dbus maintainer', I think
<torkel> sivang: no idea
<joelbryan> Mithrandir: I'm refering to metacity composite
<Robot101> pitti: what's the current status wrt patches or new upstream versions?
<Mithrandir> joelbryan: yes, and you're getting offtopic for this channel.
<pitti> Robot101: we won't upgrade to 0.61 any more, but we happily accept and apply bug fixes
<Robot101> pitti: some nice stuff like crashing on sending/receiving empty arrays, 25-second deadlocks when making concurrent method calls (try hal-device-manager for fun)...
<pitti> Robot101: I already fixed the 25-second timeout
<pitti> Robot101: the crash fix sounds interesting
<Robot101> there are about three... :P
<pitti> Robot101: I'm hesitant to upgrade to 0.61, I already have more than enough to do to fix hal 0.5.7 regressions...
<Robot101> there are no regressions I'm aware of
<pitti> Robot101: I would hug you for webcvs links, otherwise I'll peel them out myself
<sivang> ogra: are you also in the GUI sprint?
<ogra> nope
<Robot101> pitti: Nokia had a delta of 20 patches which they reduced to about 4 by upgrading to 0.61
<Robot101> pitti: it would take me a few hours to sift them all out for you
<pitti> Robot101: are there any new features in 0.61?
<pitti> or API breakages, and the like?
<Robot101> pitti: there are API additions, and only one subtle API breakage I'm aware of in the glib bindings (I've only heard about 1 thing being effected, gnome-power-manager I think?)
<pitti> well, additions don't hurt
<sjoerd> gnome-power-manager was affected and fixed in the latest release (will need a recompile though)
<Lathiat> Kamion: hrm just installed with the latest kubuntu daily installer (i386) and it asked me the time question again, despite having windows installed
<Robot101> sjoerd: rock
<Kinnison> that version is in dapper
<joelbryan> will sabayon and pessulus be included in dapper?
<Kinnison> so recompiling it will be easy
<ogra> sabayon is in since breezy
<mdke> pessulus is in too
* jdub hugs sjoerd 
<mdke> joelbryan, have a look at http://packages.ubuntu.com
<joelbryan> how about gnome-backgrounds?
<ogra> unlikely that this fits on the CD
<mdke> joelbryan, use the website, rather than the irc channel
<Robot101> pitti: 0.62 will include the 25-sec fix upstream, and a few more marshallers in glib which I'd like to see around. also massively fixed qt bindings...
<Robot101> pitti: should I ping you again when 0.62 is out? should be within a week or so
<pitti> Robot101: would certainly be interesting (0.61, too), but I'm just very afraid of regressions when we upgrade to even 0.61
<pitti> I'm not aware of any major dbus breakage in our current packages
<sivang> Robot101: 25-sec fix for fixing the terrible delay when querying hal devices through the bus for example?
<pitti> sivang: <pitti> Robot101: I already fixed the 25-second timeout
<sivang> pitti: ah, I see. then I guess it's something within my code :-/
<pitti> sivang: that just affected hal-device-manager, not other clients
<sivang> pitti: k, thx
<Robot101> pitti: hm, did you apply J5's recent fix for that?
<pitti> hm, probably not, I just pulled his original cvs commit
<joelbryan> dbus testing framework just released.
* sivang .oO(Probably could be worthwhile to check if this testing framework can be included in AutomatedTesting of the dbus package)
<joelbryan> and hannah wallach looks gorgeous!
<Keybuk> Treenaks: no idea, I've never particularly touched the md or lvm stuff
<Treenaks> Keybuk: hm.. ok..
<Treenaks> Keybuk: I've followed the shellscripts (mdrun in particular) and it seems to create /dev/md[x]  devices based on disk order -- or are they auto-created as the dm-* modules are loaded?
<Treenaks> (udev stuff)
<Keybuk> no idea
<lemsx1> hello all, does anybody knows why the default path for the dhclient leases file is NOT in /var/lib but in /var/run ??
<Keybuk> I don't even think I'm sure what md is *for*
<Keybuk> let alone lvm
<hunger> Keybuk: md is for software raid and lvm is the best thing since sliced bread.
<hunger> lemsx1: I can guess.
<lemsx1> hunger: because the debian package was originally done like that? 
<lemsx1> hunger: that path should be changed in Ubuntu. it doesn't make sense because /var/run gets cleaned on every boot
<hunger> lemsx1: Report it as a bug.
<lemsx1> hunger: that was my next step ;-)
<Keybuk> lemsx1: it's a very very very trivial bug
<Keybuk> given that everything that calls dhclient changes the leases file path anyway
<Treenaks> Keybuk: I'll just try it in an hour.. if the machine doesn't boot, I'll blame keybuk and file kilotons of bugs
<Treenaks> s/keybuk/you/ :P
<lemsx1> well, there is a bug reported for it
<Keybuk> Treenaks: nothing to do with me
<lemsx1>  Bug #24292
<Ubugtu> malone bug 24292 in ifupdown "dhcp3 server "forgets" leases (new lease at each reboot)" [Normal,Fix released]  http://launchpad.net/bugs/24292
<lemsx1> Keybuk: very trivial indeed
<Treenaks> Keybuk: Well, /dev/md0 and /dev/md1 swapped on hoary->breezy; I hope they didn't swap again on breezy -> dapper, that's all :)
<Keybuk> Treenaks: like I said, I know nothing about md
<Keybuk> I've no idea what those devices are for
<Keybuk> if you know about it and use it, perhaps you could investigate for us?
<Treenaks> Keybuk: /dev/md1 (my root device) is software-RAID
<Keybuk> that doesn't tell me anything, I'm afraid
<Treenaks> Keybuk: so if it doesn't boot, I'll file bugs on the parts that don't work, after I boot my machine again :)
<Keybuk> I'm not able to triage, or even think about fixing those bugs though
<Keybuk> I don't even know what creates those devices, I assume mdadm or something
<zAo^> more people getting segmetation fault in FF?
<mdke> zAo^, best to check the bug tracker
<zAo^> cant find the right one though
<zAo^> seems a flash problem: not supported :(
<mdke> no, but flash is important enough that someone would probably investigate the problem before dapper is released
<zAo^> what player do you use? flashplayer-mozilla?
<kent> zAo^:   which one do you use? I can test it with my firefox+flash.  
<zAo^> well, go random banners @ http://gathering.tweakers.net > "random" seg faults
<kent> zAo^:   That page worked for me..  I have refreshed a few times. I use dapper  with firefox and flashplugin-nonfree flashplayer-mozilla  installed. 
<zAo^> ok, thanks. Will try the non-free
<ploum> Does someone know the birthday date of jdub ?  A friend is creating his fr.wikipedia entry
<Treenaks> ploum: look on en.wikipedia? :)
<mdke> 1957
<ploum> Treenaks: http://en.wikipedia.org/wiki/Jeff_Waugh ! Shame ! Shame !
<ploum> mdke: I suppose he's born on the planet Mars or something like that ?
<ploum> (1957, it's a good year ! It's sputnik date !)
<doko> infinity: you're right, the breezy ia32-libs-gtk has a typo in the postrm ...
<Treenaks> Keybuk: it worked, I worry too much :)
<infinity> doko: So the diversion is obsolete?
<infinity> doko: If so, we still have a problem, cause when I un-divert the binaries, I get a segv on startup.
<ogra> Keybuk, infinity, could one of you have a look at #33732 ?
<infinity> doko: (No, I didn't have a chance to hunt and backtrace the segv, it's nearly 3am)
<infinity> ogra: I agree with the bug, that postinst should do some more anal "test if the link is in an old location, if so, update it" ... That's how I always do init script migration.
<infinity> ogra: Feel free to quote me.
<infinity> ogra: Assign the bug to Keybuk, though.  It's his.
<ogra> infinity, oki
<Keybuk> I'll reject the bug though
<Keybuk> because we had too many bugs filed because of people's silly custom changes to rcS
<Keybuk> and things ended up in the wrong order
<Keybuk> the only sane thing to do was to force the issue
<ogra> will you revert it in later versions of the package? 
<ogra> it kills my fast ltsp boot due to useless scripts like mountnfs chkfs or chkroot
<infinity> Keybuk: People's "silly custom changes to rcS" have to be respected, even if they are silly.  If they broke their boot, that's their problem.
<Keybuk> ogra: tbh, that's the way initscripts does it in Debian too
<ogra> Keybuk, then the manpage of update-rc.d is utterly wrong
<ogra> it even gives an example how to reliably disable a system service
<Keybuk> *shrug*
<Keybuk> I so don't care :)
<doko> infinity: quick check please: ldd /usr/lib/openoffice/program/* 2>&1 | egrep '^/|found' |less
<ogra> Keybuk, but i do ... and users willl as well...
<doko> and see, if any libraries are not found
<infinity> doko: Making is booted into WinXP right now, no can do.
<infinity> doko: Followup to the bug with that request, and I can look at it in the morning, if someone else doesn't beat me to it.
<ogra> also i dont see why we should repeat mistakes debian does if we can avoid them 
<infinity> doko: I can also dump a core and backtrace it tomorrow for you.
<pitti> Kamion: can you please demote gnutls11 to universe? AFAICS the transition should be complete now
<dholbach> pitti: woohoo
* pitti does the dapper dance
<desrt> pitti; does this mean you're wearing a suit?
<pitti> desrt: occasionally :)
<desrt> pitti; very dapper of you.
<pitti> desrt: only when I finished a spec
<desrt> :)
<infinity> pitti: Can I hear a "woohoo"?
<desrt> that's a time for a suit -and- champaigne, i suppose
<pitti> infinity: WOOHOOOOOO!
<infinity> pitti: Was that the last thing on our ReducingDuplicatoin hitlist for dapper?
<infinity> (I hope to refill that list for dapper+1 and be even more anal about it)
<pitti> infinity: I think so, the rest is out of range, and also not that important (libsqlite etc.)
<infinity> pitti: Oh, wait, we still have gd1, don't we?
<desrt> infinity; we need to reduce the number of germans to 1
<desrt> pitti; tough luck, buddy.
* pitti sniffs
<infinity> pitti: I'd like to see that last gd1 rdep head to universe, if you can clear unseeding it with mdz.
<infinity> pitti: libgd1 is very old, very unmaintained, and very unsupportable.
<pitti> ok, grep-dctrl shows no rdeps but *-desktop
<pitti> should be easy to drop then
<pitti> infinity: I'll reorder the wiki items to group the fixed and outstanding things together; should be easier that way
<pitti> infinity: page updated
<doko> mvo: any hint for #33533 ?
<pitti> hi mdz_ 
<AlinuxOS> pitti, hello :)
<pitti> Hi AlinuxOS 
<mdke> hi mdz_: i was wondering if you have any news on how the flash thing is going? is any more work needed on the wiki page?
<AlinuxOS> mdz, I saw your funny video in my dapper's fresh test install :)
* mdke looks
<AlinuxOS> windows xp style, template directory :) with samples :)
<AlinuxOS> there is an ogg video :D
<AlinuxOS> pitti, I still can't find any fontconfig maestro
<AlinuxOS> keithp don't responds me...
<AlinuxOS> via mail or IRC ..
<AlinuxOS> :(
<mjg59> infinity: So there's hardware out there that can be driven by Madwifi NG, but not by Madwifi
<mjg59> infinity: But I don't think we can tell from PCI IDs alone
<Mithrandir> hmm, my cupsd seems to eat 100% cpu
<pitti> Riddell: ping
<AlinuxOS> pitti, maybe I can modify mjg59 .deb file and create georgian optimal fonts.dir fonts.scale?
<pitti> these two files are alright
<pitti> AlinuxOS: /etc/fonts/fonts.conf needs to be adapted
<AlinuxOS> ah
<AlinuxOS> ok if I modify fonts.conf in a better way
<AlinuxOS> and after test everything works
<AlinuxOS> what must I do then ?
<AlinuxOS> communicate to mdz ? or mjg59 ?
<AlinuxOS> or keithp (who don't respond, via mail or IRC )
<AlinuxOS> ?
<mjg59> AlinuxOS: Let me know
<AlinuxOS> mjg59,  ok :)
<mjg59> infinity: Actually, there's three devices supported by madwifi-ng that aren't supported by madwifi. Can we package it just for those (and cut out the other PCI IDs from it)?
<mjg59> Needed for new Thinkpads and Macbooks
<AlinuxOS> http://alinuxos.no-ip.org/fonts.conf mjg59 , sorry bro, but this files header comment tells that I don't modify this... and it's only updated when fontconfig is updated
<mjg59> AlinuxOS: That's fine. If you can find settings that work, we can deal with that.
<AlinuxOS> mjg59, ok thank you a lot.
<AlinuxOS> mjg59, there is a line like:  LOCAL CHANGES BELONG IN 'local.conf'.
<AlinuxOS> it tells that I must modify mu local.conf
<AlinuxOS> or don't mind ? :)
* lamont prepares to upload glib2.0_2.10.0-0ubuntu2 for ia64 love
<mdz_> mdke: it's going slowly; the first iteration can't be played with swfdec
<mdz-sprint> Kamion: if I get disconnected shortly, what you want is gdm-signal --reboot
<mdz-sprint> Kamion: looks like what you do is gdm-signal --reboot, then the session leader needs to exit
<mdke> mdz-sprint, alrighty. Give me a bell if you need anything done on the wiki page or anything else I can help with. It occurred to me that if it works, we might be able to use it as About-Ubuntu, as well as on espresso
<mdke> i guess that might be a fairly weighty "if" though
<Riddell> pitti: hi
<slomo> lamont: thanks for fixing glib on ia64
<lamont> slomo: "fix" is a rather generous term for what I did to ist...
<lamont> it, even
<seb128> doko broke gtk
<seb128> and now lamont breaks glib?
<seb128> bah :p
<ogra> fun :)
<lamont> seb128: I just turned off assembly atomic ops on ia64
<seb128> why?
<lamont> ftbfs
<seb128> I pointed you the patch doing the FTBFS  like 2 months ago
<seb128> that was a change from Suse
<seb128> I would rather have a comment on it than a hack like that ...
<lamont> sigh... I don't remember seeing that... you still have it?
<lamont> amusingly, including <ia64intrin.h> might get it there too - the builtins exist, but there are _si and _di versions, but not the neutral one
<jono> jdub, ping
<mdke> jono, i think he is asleep
<jono> sleep is for the weak
<jono> jdub is clearly letting the side down :P
* jono mails him a turd
<jono> :P
<mdke> harsh
<jono> possibly
<jono> :P
<jono> has anyone here go the mighty power of fridge editorial permissions?
<mdke> jono, whiprush is the other chap who does.
* ogra points jono at whiprush
<mdke> jono, but you can email fridge-devel@lists.u.c
<jono> whiprush, ahhh, I thought your nick was jorge :P
<jono> I mailed fridge-devel but its not been picked up and its quite urgent
<jono> I need the official book contributions deadline extending
* lamont wonders if seb128 wandered off, or is busily looking for that patch I can't find
<mdke> jono, just amend it on the wiki page, someone will get to the fridge email eventually, I'm sure
<seb128> lamont: sorry, speaking with some other people (UI sprint)
<seb128> lamont: if you have the build error it would make easier to search bugzilla for the change :p
<lamont> .libs/gatomic.o: In function `IA__g_atomic_int_exchange_and_add':/home/lamont/dapper/glib2.0-2.10.0/build-tree/glib-2.10.0-deb/glib/gatomic.c:417: undefined reference to `__sync_fetch_and_add'
<lamont> .libs/gatomic.o: In function `IA__g_atomic_int_add':/home/lamont/dapper/glib2.0-2.10.0/build-tree/glib-2.10.0-deb/glib/gatomic.c:424: undefined reference to `__sync_fetch_and_add'
<lamont> .libs/gatomic.o: In function `IA__g_atomic_int_compare_and_exchange':/home/lamont/dapper/glib2.0-2.10.0/build-tree/glib-2.10.0-deb/glib/gatomic.c:432: undefined reference to `__sync_bool_compare_and_swap'
<lamont> .libs/gatomic.o: In function `IA__g_atomic_pointer_compare_and_exchange':/home/lamont/dapper/glib2.0-2.10.0/build-tree/glib-2.10.0-deb/glib/gatomic.c:440: undefined reference to `__sync_bool_compare_and_swap'
<lamont> collect2: ld returned 1 exit status
* lamont goes to search
<lamont> no glib2.0 bugs in bz... off to malone
<lamont> seb128: nothing jumps out at me from malone either
<seb128> lamont: I was thinking to a bugzilla.gnome bug but I'm not sure that's that one
<seb128> I pointed it to you on that chan when you pinged me with the build issue
<lamont> seb128: any chance that was infinity that pinged you?
<seb128> no, I'm pretty sure it was you
<seb128> but it was some months ago
* lamont can't seem to find it
<desrt> seb128; do you grant wishes? :)
<tepsipakki> pitti: what's the idea behind ~/.sudo_as_admin_successful ?-)
<seb128> lamont: http://bugzilla.gnome.org/show_bug.cgi?id=321229
<Ubugtu> gnome2 bug 321229 in general "fixes for GCC4.1 warnings" [Normal,Resolved: fixed]  
<seb128> desrt: what? 
<jono> later all
<desrt> seb128; i'm not sure i've decided yet.. if i only get one wish i want to make sure it's a good one :)
<desrt> seb128; in any case it would be along the lines of 'secret gconf key with no UI visibility triggers strange behaviour' type stuff :)
<desrt> seb128; and i'd provide the patch, of course :)
<pitti> tepsipakki: to suppress the help text after successfully executing sudo the first time
<pitti> Riddell: do you plan an upload of qt-x11-free in the near future?
<pitti> Riddell: I noticed that it builds fine with libsqlite3 instead of 0
<desrt> seb128; who things i am thinking is (1) way to get upstream logout dialog behaviour back and (2) way to make sound-juicer use lowercase for album info
<pitti> Riddell: it's one of the few packages which keeps libsqlite0 in main
<desrt> *two
<lamont> seb128: is that gatomic patch there applied from upstream, or is it a patch -R version of what they want?
<lamont> (we seem to have the patch if it's a forward patch...)
<lamont> seb128: it's quite possible that we need to either (1) reverse that patch, or (2) have doko backport the builtin from 4.1 to 4.0
<tepsipakki> pitti: could it be somewhere else and not in $HOME?
* lamont tests
<pitti> tepsipakki: /var/lib etc. would work, too, but the semantics are less desirable (for remote /home, new installs, etc.)
<Surak> doko: there?
<tepsipakki> pitti: imho it should be configurable.. 
<pitti> tepsipakki: that would make it three times more complicated
<tepsipakki> pitti: it's not nice to find yet-another dotfile on your homedir
<seb128> desrt: having a gconf key for upstream behaviour would be trivial, but I'm not sure we want to add a gconf key for every change we do
<tepsipakki> pitti: what message should it suppress, I can't see any?
<pitti> tepsipakki: remove the stamp and open a new terminal
<desrt> seb128; maybe for the really controversial ones
<seb128> lamont: that's the change who broke glib build
<lamont> seb128: right. testing the actual fix then.
<desrt> seb128; cf. ubuntu spatial
<tepsipakki> pitti: doesn't show anything on a ssh-session
<lamont> seb128: it wouldn't surprise me to see that we need that patch completely when we switch to 4.1
<Riddell> pitti: no uploads planned, go ahead if you want to upload, I probably can't look at it this week (ui sprint)
<pitti> tepsipakki: are you in group admin?
<tepsipakki> pitti: yes
<seb128> desrt: we don't have any really controversial atm
<desrt> seb128; you've set a precedent for not *completely* alienating your users.  may as well stick to it :)
<lamont> seb128: if the build now works, I'll upload -0ubuntu3
<desrt> seb128; the logout dialog seems to be controversial to me.
<seb128> desrt: you are the only one to make a really mess about it
* milli is away: Lunch
<desrt> seb128; and the others who commented on the bug and in irc
<seb128> lamont: k
<desrt> seb128; including many who are themselves ubuntu developers
<seb128> desrt: that's minor detail, you don't stop the computer every min anyway
<seb128> desrt: not really or they didn't tell me
<Kinnison> oh gods
<Kinnison> gtkmm is so evil
<desrt> right. this is why it's nowhere near as bad as ubuntu spatial :)
<lamont> Kinnison: you're just now discovering that?
<seb128> desrt: we agree there is some issues but you are the only one saying we should revert to upstream behaviour, it's anti-HIG and no change will make it fine, etc
<Kinnison> lamont: never before have I attempted to work on this sort of code
<desrt> seb128; fair enough.
<desrt> seb128; but a gconf key is so much easier to maintain than my own version of the package :p
<seb128> desrt: yeah, but as said, if we do have to add a gconf key for every change we make ...
<seb128> and I'm pretty sure you would get used to the new dialog if you had not decided to complain until getting changed for the upstream one :)
<Triskelios> does someone familiar with the ubuntu live cd or debian-installer know if I can use preseed/late_command to change netcfg settings?
<desrt> seb128; i like the upstream one because it's good
<desrt> seb128; it's not good because i like it :p
<seb128> I like the distro one because it's good too :)
<desrt> btw: fast user switching often causes my computer to crash.  is there some way to completely disable it?
<desrt> fglrx doesn't like running two X servers at once on my hardware, it would seem
<seb128> remove fast-user-switching-applet?
<desrt> i still have 'switch user' in the logout dialog
<desrt> (both upstream and the ubuntu one -- equally guilty) :)
<seb128> the solution would be to drop gdmflexiserver
<seb128> but the guilty is rather xorg
<desrt> or maybe ATI... who knows
<seb128> does it happen with the ati drivers too?
<desrt> i don't know
<lamont> seb128: we now get these warnings (which I don't care about, and gcc-4.1 will let us drop the patch, and thereby get rid of the warnings)
<lamont> gatomic.c:417: warning: passing argument 1 of '__sync_fetch_and_add_si' discards qualifiers from pointer target type
<lamont> gatomic.c:424: warning: passing argument 1 of '__sync_fetch_and_add_si' discards qualifiers from pointer target type
<lamont> ...
* lamont uploadds -3
<seb128> k
<siretart> can anyone please point me where initramfs-tool initialise network interfaces?
<siretart> I'm evaluating if and how to integrate it into early userspace, but it is quite, well, undocumented :/
<lemsx1> siretart: look under /usr/share/initramfs-tools/scripts/
<siretart> lemsx1: where exactly?
<lemsx1> siretart: i'm guessing that you need the module for your eth loaded and then use ifconfig or similar to set it up
<siretart> lemsx1: I'm searching the file which brings the interface up, and how configuration of that is handled
<lemsx1> siretart: use hooks to add your modules and scripts to run what you need at init-top or something
<siretart> err, great, thats what I expected. in which file does this happen?
<lemsx1> siretart: i'm guessing in hooks/foo you would do: manual_add_modules foo
<lemsx1> siretart: to load your module to the initramfs
<lemsx1> siretart: and in scripts/init-top/foo you would do: ifconfig eth0 .... whatever ifconfig commands to get it up
<lemsx1> siretart: of course, in the hook file you might want to copy_exec /sbin/ifconfig to your ${DESTDIR}/sbin/
<lemsx1> siretart: just in case is missing ;-)
<ogra> siretart, i'd guess you have to look at udev ...
<ogra> since that handles the interfaces iirc ...
<siretart> As I understand, the initramfs does already bring up the interface in early userspace
<siretart> I fail to find the place where it happens currently
<siretart> ogra: that what Keybuk mentioned some time, lets dig further
<Mez> mdz/kamio: ping
<Mez> s/kamio/kamion *
<ogra> siretart, i think there are some udev scripts in the scripts dir 
<Mithrandir> siretart: what are you trying to do?
<siretart> Mithrandir: I want to learn how interface management in early userspace works today. 
<siretart> Mithrandir: I want to understand why Keybuk and crimsum decided that wpasupplicant should be started through /etc/network/ifup.d/wpasupplicant rather than through the old init script
<Mithrandir> siretart: generally it doesn't, because it's not needed in early userspace.
<Mithrandir> siretart: because it should work for hotplugged interfaces?
<siretart> the reason was that udev handles network interfaces are handled via udev in early userspace. now I want do understand how this works actually
<siretart> Mithrandir: well, wpasupplicant daemon can wait for the interface to come up. 
<Mithrandir> they're modprobed, but not ifup-ed.
<siretart> and this repsects scripts in /etc/network/ifup.d/*?
<Mithrandir> I'm not sure why you seem to be so interested in early userspace.  Networking is not brought up there unless you need it to find /
<siretart> aha. this piece of information is useful to me
<Mithrandir> the point of the initramfs is "find /, mount it, start init"
<Mithrandir> not random other crap. :-)
<siretart> hm
<siretart> Mithrandir: does modprobing an interface cause any scripts in /etc/network/ifup.d to be executed?
<Mithrandir> siretart: that depends. :-)
<Mithrandir> siretart: look at /etc/udev/rules.d/85-ifupdown.rules
<Mithrandir> it doesn't exist in the initramfs, so won't be called there
<Mez> are mdz/Kamion the only ones allowed to allow UVF requests?
<siretart> ok. I think I begin to understand
<siretart> thanks for the pointer, Tollef
<siretart> ok, so I would only need fiddling with early userspace if I want to mount / from an wpa secured network.
<Mithrandir> yes.
<mdz-sprint> Mez: for main, yes
<mdz-sprint> but we do both read our email quite frequently
<Mithrandir> siretart: so unless you're running thin clients over wireless with WPA you don't need it that early.
<Mez> mdz-sprint, ah cool - well should I email you or do you just wanna quick run through on here first ?
<siretart> Mithrandir: you can use wpasupplicant over wire as well
<Mithrandir> siretart: oh, true.
<Mez> oh, and infinity ping
<Mez> actually
* Mez pings infinity REALLY hard
<Mithrandir> Mez: dude, it's 0600 or thereabouts for him.
<Mez> Mithrandir, I thought it was like - midday/mid afternoon
<Mez> he's in America right?
<Mithrandir> no, .au
<xhaker> #dapper-look
<xhaker> wrong clipboard
<Mez> Mithrandir, whoops :D
<Mez> didnt know
<mdz-sprint> Mez: email, as documented
<Mez> mdz-sprint, you, kamion, or both?
<mdz-sprint> Mez: https://wiki.ubuntu.com/DeveloperResources
<Mez> mdz-sprint, cheers :D will email in a few moments after I've made the package 
<Kinnison> g'night all
<Mez> night Kinnison 
<desrt> mdz-sprint; how does one apply for UVF break?
<desrt> pfah.
<Mithrandir> Kamion: I don't think the live cd boot significantly differently for me now with readahead.
<Surak> Did someone noticed that some breezy gtk themes on amd64 makes 32-bit apps (namely openoffice) having no widgets? The widgets are grand canyon and smokey-blue...
<Mithrandir> Surak: I can tell you the reason.  I don't think we'll end up fixing it, though.
<Mithrandir> the problem is the themes use plugins/pixmap engines which then won't work on a non-native arch
<Surak> It seems that gtk-libs 32 cannot open png files, isn't it?
<Surak> ooh i see.
<Mithrandir> I'd argue that it should fall back to another theme, or something along those lines.
<Surak> Mithrandir: where exactly is the problem located?
<Mithrandir> in gtk somewhere, I think.
<Mithrandir> I haven't actually looked at the code, but it makes sense.
<Surak> I don't know why, but I cannot access launchpad from here. This could be posted to https://launchpad.net/malone/bugs/33629
<Ubugtu> malone bug 33629 in ia32-libs-openoffice.org "openoffice2 not showing widgets in breezy amd64" [Normal,Needs info]  
<Mithrandir> I'm currently testing the live cd a bit, so I'm slightly handicapped wrt launchpad, but yes, it should absolutely go there.
<Mithrandir> now, if rsvg-convert could please speed up a bit, I'd be happy.
<Mithrandir> it has so far used about 4 CPU minutes on a decent AMD64.
<Surak> Mithrandir: Doko replied me, but I did not have more information. I just knew that there was something wrong :-) The bug is posted against the wrong lib, anyway.
<Mithrandir> Surak: it should probably be either libgtk or ia32-libs-gtk, yes.
<Surak> Mithrandir: If you could log in launchpad and provide more info on this bug, I'd be thankful :-)
* Mithrandir grrs at the boot speed.  We've lost almost 30 seconds over what we had mid-December.
<Mithrandir> I need to try again without readahead.
<Surak> Mithrandir: weird thig is, the window bars handle pixmaps correctly - but widgets doesn't. How can be that?
<Surak> hm.. window borders are handled by the 64-bit window manager. duh
<Mithrandir> so, readahead on the live cd adds 5s to bootup time.
<ogra> and whats does it gain us ? 
<Surak> Mithrandir: not only pixmaps, 32-bit apps on breezy amd64 cannot load vector widgets also. Trying with a svg-theme.
<Tm_T> Ubugtu is needed in #kubuntu-devel
<Tm_T> bug #33917
<Ubugtu> malone bug 33917 in kubuntu-default-settings "lastest updates brought a new error on konqueror's system:/ sidepane" [Normal,Unconfirmed]  http://launchpad.net/bugs/33917
<Tm_T> :)
<ogra> Tm_T, ask Seveas 
<Mithrandir> ogra: slows us down on the live cd.  I guess it might be better if we optimise it a bit
<Tm_T> thanks
<ogra> Mithrandir, no, i mean is it worth having it at all on the live CD ?
<Mithrandir> ogra: it's part of the desktop seed
<ogra> meh
* smile is away: I'm busy
* smile is back (gone 00:00:05)
<Burgwork> smile, please turn your away/back messages off
<smile> Burgwork: Just did ;D Sorry
* Tm_T hates public aways
* Treenaks hates the public
<Treenaks> oh wait
<Burgwork> Treenaks, that is not true
<Treenaks> Burgwork: ;)
<ogra> Burgwork, thats a side effect of the green supplements you get with your coffee in his country ;)
<Treenaks> ogra: duuude! :)
<ogra> heh
<Burgwork> ogra, cheaper and better where I live
* ogra likes cheap coffee ;)
<Burgwork> no, the green stuff
<ogra> i know ;)
<lemsx1> can somebody look into  Bug #32576? I know you guys were working on it (Kamion?) but this is such a simple bug to fix... I just noticed that the Makefile is missing in this package, making it completely useless
<Ubugtu> malone bug 32576 in linux-restricted-modules-2.6.15 fglrx-kernel-source "missing separator when using debian/rules" [Normal,Unconfirmed]  http://launchpad.net/bugs/32576
<Treenaks> Burgwork: Ours was determined to be the best green stuff in the world by the WHO
<dAndy> Kamion: any thoughts on the FTP support?
<sivang> Treenaks: does WHO claim that green stuff is good fro your health?
<Treenaks> sivang: no. just that the Dutch variety has the most THC in it ;)
<Surak> what lib is responsible for drawing pixmaps on gtk widgets?
<sivang> Treenaks: ah, pity, I was hoping it is healthy for you :)
#ubuntu-devel 2006-03-12
<BenC> "No packages matching 'linux-source-2.6.15' are published in Ubuntu."
<BenC> I find that hard to believe
<BenC> that's when searching for Source Packages
<Mez> lol
<Seveas> BenC, "There is no kernel"
<CarlFK> Ok, now that I have my data in OOCalc, anyone know how to rotate it?
<CarlFK> I want rows to be columns
<jono> anyone know if the cairo-fied OOo will make it into dapper?
<tseng> jono: not likely, its past feature freeze
<tseng> jono: but its doko's baby
<CarlFK> whops, wrong chan
<jono> tseng, ahhh
<jono> woo! http://www.amazon.co.uk/exec/obidos/ASIN/0132435942/qid=1141688252/sr=1-2/ref=sr_1_2_2/203-0360572-5579116
<tseng> jono++
<jono> :)
<tseng> http://www.amazon.co.uk/exec/obidos/search-handle-url/index=books-uk&field-author=Bacon%2C%20Jono/203-4537622-1113542
<lifeless> LarstiQ: /win 11
<lifeless> bah
<zul> heylo
<Arrogance> jono, did you notice the amazon recommendations on your book?
<jono> Arrogance, no?
<Arrogance> all Windows XP stuff.  :)
<jono> hehe
<Triskelios> Kamion: happen to be awake?
<Burgwork> Arrogance, which book?
<Arrogance> http://www.amazon.co.uk/exec/obidos/ASIN/0132435942/qid=1141688252/sr=1-2/ref=sr_1_2_2/203-0360572-5579116
<arp> Anyone lose gedit?
<arp> Please may we have a gedit-2.13.93 for ppc?
<infinity> arp: If the build-deps get fixed... 'Sec.
<arp> ty infinity 
<mjg59> Ooh, wireless /almost/ works
<Amaranth> on what?
<infinity> mactel?
<mjg59> Yeah
<ajmitch> impressive
<arp> mactel, i.e. the new x86 macs?
<mjg59> Yup
<arp> nice
<mjg59> I've got it associated with the AP
<infinity> Close enough.  Ship it.
<mjg59> No DHCP leases yet, though
<infinity> Once a driver's getting that far, you can just claim the rest is user error and sit back and chuckle.
<mjg59> Probably because the MAC address has come up as ff:ff:ff:ff:ff:ff
<infinity> (Is this why I don't do kernel maintenance?... Maybe)
<doko> infinity: the OOo segfaults look like nvidia related crap ...
<jdub> ok, no one send mjg59 any more hardware
<infinity> doko: Yeah, I'm going to test some theories and upload a new LRM (if I find an obvious fix) today.
<jdub> it's just like feeding him crack
<Amaranth> jdub: I'm thinking about sending him a broadcom wireless card so he can make that rock too. ;)
<mjg59> jdub: Just think of the PR, dude
<mjg59> Amaranth: I've got a couple...
<mjg59> Including this Mac
<doko> jdub: you're missing feedback on #30482
<mjg59> The issue with the Mac is that it's a PCIE Broadcom, and we currently have no driver support for that
<ajmitch> I'd send him my acer laptop but I think he'd just return it 
<mjg59> So I'm just pretending that it's a PCI one, which seems to mostly work
<doko> jdub: or just assign it to seb128 ...
<infinity> mjg59: I see no reason why you'd need to address it as PCIE, unless you desperately need the extensions.
<mjg59> infinity: No, but it's a different core
<infinity> mjg59: The kernel's happy to provide a base-level PCI API for all PCI/AGP/PCI-X/PCI-E interfaces, afterall.
<infinity> mjg59: Ahh, yes, that's more problematic. :)
<mjg59> So I need to teach the driver that the PCIE core is much the same as a PCI one
<mjg59> (Which seems to be mostly true)
<doko> jdub: thanks
<jdub> doko: sorry 8)
<mjg59> You people would not believe just how hard I rock
<mjg59-mac> Victory is mine
<jdub> over wifi?
<mjg59-mac> Yup
<StevenK> mjg59-mac: Ouch. How many new scars did you manage to inflicit upon yourself?
<jdub> sick fuck! (well done!)
<mjg59-mac> Should only be a couple of lines of diff
<mjg59-mac> Still no MAC address, but that's probably easier to fix
<jdub> mac addresses are for hippies
<zakame> hi devs
<joelbryan> I have a temporary fix regarding tulip-based ethernet card that disconnects every 1 minute in dapper.
<joelbryan> I have a davicom ethernet, my university uses those (more than 1000 pcs), I use mii-diag -r to reset the link, and I made a * * * * * cron job for it, if it isn't fix yet in release, I'll just populate mii-diag in 1000 pcs and copy the cron to those pcs.
<dbernar1> What package are manual entries for system calls in? I do not have a man exec.
<StevenK> manpages-dev
<dbernar1> much appreciated.
<joelbryan> my lovebug culprit university assigned me to install ubuntu to those pcs, (1000+) and waiting for dapper.
<joelbryan> kernel 2.6.17 fixed the sis pci 900 ethernet card, which hangs before when detected.
<joelbryan> DAMN!! the OpenOffice is fuckin' wicked!
<joelbryan> oops, sorry, the new OpenOffice.org supports gtk2 file selector, and has an new splash screen. so Cool!!
<joelbryan> it's not yet fully GNOME-ish, some are still javaish, you can easily tell the difference, but the save as and the open selector is Gtk+2 cool!
<Amaranth> joelbryan: you already said all that in #ubuntu
<HiddenWolf> I'd rather see OOo slimmed down and usability-fied than gnome-inised, but that's just me. :P
<Amaranth> i'd rather see it removed from ubuntu
<Amaranth> and replaced with KOffice and GNOME Office
<Amaranth> but one of those isn't done yet
<HiddenWolf> True
<HiddenWolf> and abiword isn't up to scratch
<joelbryan> Well I like GNOME-Office from the fact that it has Abiword, because it's fast.
<HiddenWolf> it's fast, but it doesn't use odt, has issues with large documents, and it's interoperability with msoffice isn't as good as OOo's
<wasabi> I really love Abiword. I'm starting to use it for some internal projects.... I'd like odt support though obviously.
<wasabi> OOo is SO hard to program against it's not even worth it.
<HiddenWolf> I'm in the unfortunate situation that I can't use it, since everyone in my world uses .doc :/
<wasabi> UNO my ass.
<HiddenWolf> Someone get me a decent replacement for impress and I'd be sold tho. :)
<joelbryan> I just hope OpenOffice get GTK+ize.
<joelbryan> OOo uses jar files, w/c has it's own VM, just like any java apps.
<minghua> doesn't abiword CVS head already support ODT?
* minghua remember reading something about that
<HiddenWolf> minghua: does, but not fully, and not by default
<HiddenWolf> minghua: and they've stated they won't, because it doesn't fit their internal structure.
<minghua> HiddenWolf: oh okay, thanks
<mjg59> Hurrah!
<mjg59> Working MAC address as well
<jdub> mjg59: is this crazy workaround-apple stuff, or fairly normal hardware version stuff?
<mjg59> jdub: It's just a newer Broadcom chipset than we've seen before
<johanbr> Hi. I'm looking at the gnome-volume-manager source right now, with the aim of possibly offering a few minor patches. I noticed that the commands to run are stored as gconf keys. Is there any way to store optional commands in the gconf keys, i.e. say I want the gnome-volume-manager drop-down menu to give me a choice between running either sound-juicer or gnome-cd ?
<tiefox> module bcm43xx is not present anymore as of 2.6.15-17 kernel
<infinity> tiefox: A mistake, it's back in the next upload (which is just finishing up on the buildds, and should hit mirror later today)
<tiefox> thx a lot infinity
<tiefox> :)
<infinity> s/mirror/mirrors/
<arp> infinity: any news on gedit, or should I just shut up and wait?
<infinity> arp: https://launchpad.net/+builds/+build/174002/
<johanbr> infinity: Are you sure it's a good idea to ship bcm43xx in its current state? It was really unstable for me and my computer locked hard when I ran ifdown with the module loaded.
<infinity> I think that translates to "shut up and wait for the binaries to be published" :)
<arp> :)
<infinity> johanbr: It works for enough people that we'd rather ship it, yes.
<infinity> johanbr: Doubly-important for PowerPC users, many of whom have BCM wireless (apple notebooks), and none of whom can use ndiswrapper, which is i386-specific.
<johanbr> infinity: Good point. I
<johanbr> infinity: Sorry about that. What I meant to say is that you have a good point and I'm at least in the situation where I can use ndiswrapper.
<mjg59> johanbr: It works fine on a lot of hardware
<mjg59> (I'm using it here right now)
<johanbr> mjg59: I don't doubt that, but on my HP nx6125 it's basically unusable.
<mjg59> Really? Hm.
<mjg59> Works on my nx6125 :)
<infinity> (Note that, given its imaturity, there's a fair chance BenC will bump it to newer upstream snapshots a couple of more times before dapper releases)
<infinity> So, here's hoping it'll work on 75~80 per cent of the bcm hardware out there by release, at least.
<johanbr> mjg59: For me, with kernel 2.6.15-16-amd64-k8, it often dropped connections, spewed lots of errors into syslog and hard locked the kernel when I ran ifdown.
<Mez> infinity, HARD PING
<HiddenWolf> johanbr: did you file bugs?
<johanbr> HiddenWolf: No. I figured with the driver being in such a rapid state of development there wouldn't be much point.
<infinity> Mez: Half-hearted pong.
<HiddenWolf> johanbr: there is always a point in making sure your issues are known, through the proper channels.
<Mez> infinity, you asked me to ping you hard on monday
<Mez> well
<Mez> er
<Mez> it's tuesday now ;)
<infinity> So it is. :)
<Mez> well - wanna work out why my control hack isnt working ?
<infinity> Mez: /msg me with those URLs and stuff again, and I'll poke at it right after I'm done with LRM and PHP (which are top priorities right now, it seems)
<johanbr> HiddenWolf: If you say so. I figured reporting bcm43xx bugs to ubuntu would mostly be considered noise, when the upstream driver already has changed by a large amount by the time Ben gets around to looking at the bugs, but if you think reports would still be useful I'll give the newest kernel a try with bcm43xx and file a report if it doesn't work.
<HiddenWolf> johanbr: perhaps it's noise, but at least it'll draw more notice than the noise here in this channel when most devs are asleep.
<mjg59> johanbr: That would be good
<mjg59> It's not actually too hard to fix most of these bugs, as long as we get to see them
<johanbr> Alright, thanks for the encouragement. Since apparently the latest kernel version had the bcm43xx module go awol, I'll watch the archive for a new version and give it a spin when I see it.
<mjg59> Should be available in a couple of hours
<pitti> Good morning
<Mez> morning pitti
* Mez looks at clock
<Mez> wtf?
<Mez> It's morning!
<Mez> eep
<Mez> now: beer or no beer before I go to sleep
<sivang> Good morning
<pitti> hi sivang 
<sivang> hey pitti , how's it going?
<pitti> fine, thanks; and you?
<sivang> pitti: pretty good, starting to see the finish of HUB :)
<HiddenWolf> sivang: will that still be in dapper?
<pitti> I don't see why it shouldn't be in universe
<pitti> probably just too late for main
<HiddenWolf> Good stuff. Time to migrate my mom then. :)
<HiddenWolf> she wants to backup, doesn't know how, and calls me to do it once in a while
<HiddenWolf> Then I have to figure out how windows works, etc. :)
<sivang> HiddenWolf: The chances are dropping as we speak :) maybe if it will proove to be not full of bug as I release it and mdz will be happy to let it through realtively late in the process, it'll get included in main. But as I said, chances are low.
<sivang> HiddenWolf: so I see I have a first tester ? :-)
<HiddenWolf> Once I get around to ridding her of XP, and poking wine so it runs 2 little apps, hell yeah. :)
<HiddenWolf> fixing a pc over ssh is so much easier than getting on the train for 2 hours each way. ;)
<sivang> wow!
<HiddenWolf> sivang: and personally, yeah. my current .tar.gz to somewhere option isn't ideal either. :)
<sivang> has anyone seen the new Python website??
<sivang> It went a redesign
<sivang> HiddenWolf: hehe
<HiddenWolf> wow
<sivang> HiddenWolf: Hopefully, my application will be up to the expectations
<HiddenWolf> that's a step forward to presentability.
<HiddenWolf> sivang: I'm sure I can think of some things to nag about, no worries. :)
<dAndy> sivang: got a link to this HUB thing so I can learn more?
* dAndy doesnt know what it is
<sivang> dAndy: https://wiki.ubuntu.com/HomeUserBackup
<dAndy> cool thanks, will look into it
<sivang> np :) anyways, the python web site feels quicker , I wonder if they are using a trimmed version of zope or a new system.
<HiddenWolf> I'm not convinced the new page is more usable tho.
<HiddenWolf> News just shouldn't be at the bottom of a page.
<freeflying> pitti: ping
<pitti> hi freeflying 
<freeflying> pitti: two bugs about language-support-ja
<freeflying> pitti: https://launchpad.net/malone/bugs/31733
<Ubugtu> malone bug 31733 in gtkhtml3.8 "Evolution mail composer crashes with SCIM" [Normal,Unconfirmed]  
<freeflying> pitti: https://launchpad.net/malone/bugs/30905
<Ubugtu> malone bug 30905 in language-support-ja "depends on scim-tables-ja, but not required for normal users" [Normal,Unconfirmed]  
<pitti> well, that's a scim bug, not a l-s-ja one
<pitti> (the first one)
<pitti> freeflying: hm, what is scim-tables-ja good for then? It sounds useful for Japanese writers?
<freeflying> pitti: they prefer to use scim-anthy then scim-tables-ja
<freeflying> s/then/than
<pitti> alright, no problem to fix that
<pitti> freeflying: I fixed the s-t-ja bug
<freeflying> pitti: nice 
<freeflying> pitti: how about the scim-gtk2-immodule
<mdke_> trappist, ping
<Mez> eep
* Mez needs a lil s++help
<Mez> c++ *
<Mez> anyone willing to help ?
<pitti> Mez: maybe just ask the question?
<Mez> for the line
<Mez> _result = new Program(s, _useExecName)
<Mez> how do i define it in the header file
<Mez> I'm probs gonna cock it up anyways ;)
<pitti> Mez: define 'it'?
<Mez> _result
<Mithrandir> Program *_result ?
<pitti> ah, yes
<Mez> aha :d
<Mez> couldnt remember the * bit
<pitti> new delivers a pointer
<sivang> hmmm
<sivang> I'm fighting with something stupid here, could use a py guru's help:
<sivang> I have two funcitons installed on the gtk_main_iteration loop
<sivang> one is a timeout function, to ProgressBar.pulse() ,
<pitti> Good morning mdz_ 
<sivang> the other monitors a pty fd , and updates the status of current file being worked on when the sub process's output has new output on the pty.
<mdz_> morning
<sivang> this function is installed with gobject.io_add_watch
<sivang> now, the io watching func maintains a self.running boolean flag , so when there is no more processing to do there, it sets it to False.
<sivang> the gui progress timeout func monitors that flag, and shoudl return false (thus stopping and automatically removed from the main loop by gtk) when self.running is false.
<sivang> however: the timeout func only see it's value as True...:-/ am I doing anything wrong?
<sivang> (even when the io_add_watch callback sets it to false, and stops on account of it.
<lifeless> are you looking at the same variable?
<sivang> it feels like the timeout func can only see the value that was current when it was installed on the gtk main loop, rather then getting it's real value everytime it's changed.
<lifeless> which means its looking at a differnt instance
<lifeless> I'd bet on a closure rather than an object tripping you up
<sivang> lifeless: I made sure this is not the situation, but it is certainly worth double check :)
* sivang re-checks
<sivang> lifeless: okay, I made sure code wise this is the same variable I'm looking at. still, same issue... How can I make sure this is the same instance? if both of the callbacks produce different instances of 'self' then I'm in troulbe.
<lifeless> past the code somewhere
<simira> good morning, sabdfl 
<lifeless> cannot comment in a vacuum
<sabdfl> hey simira
<pitti> hey sabdfl
<sivang> lifeless: indeed, but I warn you, it's somewhat large now :)
* pitti hugs seb128
* sivang hugs seb128 
* seb128 hugs pitti
<seb128> pitti: thanks for the rhythmbox upload
<sivang> hey sabdfl 
<sivang> lifeless: muse.19inch.net/~sivan/upbackup.py
<lifeless> whats the line I should look at
<sivang> lifeless: 237, pushGUIBackup
<lifeless> the variable in question ?
<sivang> lifeless: self.running
<sivang> lifeless: it get's updated in watch_Backup_pty_callback
<sivang> (the function beneath)
<lifeless> ok
<lifeless> add
<lifeless>           self.running = self.curBkp.next()
<lifeless> +        if DEBUG_MODE: print "pushGUIBackup:: self.running = %s" % self.running
<lifeless>          while gtk.events_pending():
<lifeless> there aare two basic possibilities
<doko> Kamion, mdz: please could you process python-pullparser and python-clientform in NEW?
<lifeless> one is that you never run out of events
<lifeless> another is that its never set in the first place
<lifeless> I suggest not doing main_iteration and instead writing this as event driven
<lifeless> but thats a suggestion ;)
<sivang> lifeless: isn't this already event driven? that is, I already attend to the worker using io_add_watch :) do you aso suggest that when I never run out of events, then it's just stuck in there and that's why the self.running is never set?
<sivang> lifeless: (weird thing this used to work, when the pre_build_kick was part of the .build method. I splite them since I had to propogate the child's pty up)
<sivang> lifeless: about it never being set in the first place, I am sure it get's set. otherwise the io_add_watch would have never been removed and stopped at end of operation.
<lifeless> you are manually iterating the event loop
<lifeless> this means that you will have reentrancy issues that you are much less likely to have if you dont
<lifeless> and reentrancy races are tricky enough anyway ;)
<sivang> lifeless: I see, well, I added them such that the GUI won't freeze in the callbacks, as it did before adding those.
<lifeless> that means your callbacks were taking too long
<lifeless> rather than just doing whats available and returning
<lifeless> which is what they should do in event based programs
<sivang> mvo is also using this method to make GUI not block while doing long work in the background, so I acutally borrowed it from his code, and it seems to work so nicely so far. I wish I knew what had regressed.
<pitti> ogra: ping
<doko> Kamion, mdz, mdz_: please could you process python-pullparser and python-clientform in NEW?
<sivang> lifeless: is there a real reason why the boolean falg doesn't get updated for the timeout function? 
<sivang> lifeless: s/real/explainable/ ;)
<lifeless> sivang: sorry. not sure on that, try one of the gnome dev channels 
<sivang> lifeless: okay, thank anyway rob :)
<Kinnison> is openssh-server in ship in breezy?
<mdke> i'm fairly sure it isn't
<Kinnison> :-(
<mdz_> Kinnison: you know where the seed archive is, right?
<Kinnison> mdz_: umm, if I said "no" would you fire me?
<mdz_> Kinnison: ssh (server and client) have been on the CD since warty
<Kinnison> mdz_: thanks
* Kinnison never knows because he has kept a local mirror since warty
<mdz_> Kinnison: I'd suggest a thorough investigation of https://wiki.ubuntu.com/DeveloperResources
<Kinnison> good plan
<Kamion> Lathiat: note how that clock-setup bug is only "Fix Committed", not "Fix Released"
<MikeS> Hi. I've got an ubuntu kernel question: valgrind-SVN doesn't run on ubuntu kernels out of the box at the moment. It turns out that this seems to be because the ubuntu kernels have an unusual 2/2 user/kernel split, rather than the normal 3/1 (or 4/0), so the valgrind binary can't be loaded where it wants to be loaded. 
<MikeS> Now, this can be worked around by using a different load address, but that limits processes running under valgrind to less total address space (unless we only do this for ubuntu, not generally, which seems like a nasty hack).
<MikeS> Can anyone explain WHY the ubuntu kernels work this way?
<Kamion> wasn't that changed recently?
<Lathiat> Kamion: oh, ok
<Lathiat> Kamion: cheers
<MikeS> I don't know; I'm running dapper here
<Lathiat> yeh it was
<Lathiat> i saw something in the kernel changelogs about it
<MikeS> Where would I find those?
<Kamion> dapper-changes mail archives on lists.ubuntu.com
<Lathiat> or /usr/share/doc/linux-image-`uname-r`/changelog.Debian.gz
<MikeS> Lathiat: thanks
<MikeS> "Incorrectly set memory split to 3/1 instead of the default 1/3. Revert to correct 2/2 mapping. Fixes problems with UML and Wine." - so I guess it's still 2/2, but I still don't know why :)
<MikeS> Anyway, since that change was from BenC, I guess I'll ask him...
<wm_eddie> doh.  The X server seems to be broken today >.<
<Xof> oh good, I'm not the only one who noticed that kernel change
<Xof> (well, apart from all my users too)
<elkbuntu> is SANE going to be upgraded to the current in dapper?
<pitti> ogra: I just uploaded a new alsa-utils which should fix sound on ppc; testing appreciated :)
<minghua> Micksa: you may be interested in bug #30962, there is a lot of discussions about this split in that bug, although I understand none of them
<Ubugtu> malone bug 30962 in linux-source-2.6.15 "Running wine applications instantly outputs "Killed." in the terminal" [Normal,Fix released]  http://launchpad.net/bugs/30962
<MikeS> minghua: I assume that was aimed at me? Thanks; that looks like what the current ubuntu kernels do to valgrind...
<pitti> Kinnison: g-p-m is not running on the current (ppc) live CD, but the package is installed; known problem?
<Kamion> doko: done. there seems to be cruft in the source packages; please check that out
<minghua> MikeS: ah yes.  wrong tab completion for nicks.
<MikeS> minghua: but yes, that's exactly the same problem: apparently wine, like valgrind, wants 3/1, not 2/2.
<wm_eddie> Man, filing a bug report with only lynx will be pretty hard...
<doko> Kamion: just the build subdirs?
<Kamion> doko: that and a stray changelog
<Kamion> I noticed it in (iirc) python2.3-psycopg as well
<Xof> regarding the 3/1 split: I have reports of the current 2/2 split breaking sbcl, cmucl and clisp on dapper.  (Whether you care about exotic programming languages I don't know)
<mdke> wm_eddie, you can do it by email, if you have email, i think
<crimsun> if they work in Breezy, that's a regression.
<Xof> they work in Breezy
<wm_eddie> :( I use gmail.
<minghua> Xof, MikeS: sounds like we need an umbrella bug for this memory split thing in kernel :-)
<wm_eddie> grr I can't remember how to redirect STDErr to a file so I can find out why X is bailing out after GDM.
<MikeS> 2> foo
<wm_eddie> thanks
<MikeS> Xof: not surprising, it appears to be hitting most applications that have unusual memory-management- and lisps are pretty likely to do that sort of thing.
<wm_eddie> there's an undefined symbol in libGLcore.so?
<Lathiat> https://lists.ubuntu.com/archives/kernel-team/2006-February/000678.html
<Kamion> pitti: not seeing gnutls11 in anastacia output yet
<pitti> Kamion: hm, grep-dctrl does not show any deps/b-deps any more...
* pitti misses melanie
<Kamion> probably on other architectures
<pitti> I only checked openldap and rhythmbox (the two latest uploads), they built everywhere
<Kamion> all_ubuntu_dapper_powerpc:libgnutls11                                       | gnutls11                        | gnome-control-center                         | Matthias Urlichs <smurf@debian.org>                                                   |          304474 |             712
<pitti> but entirely possible that some package didn't built
<Kamion> plus a bunch of stuff on hppa, ia64, sparc
<Kamion> hppa's unsurprising since it hasn't been building recently
<Kamion> all_ubuntu_dapper_ia64:libgnutls11                                     | gnutls11                          | libegroupwise1.2-9                             | Matthias Urlichs <smurf@debian.org>                                                   |          407344 |            1204
<Kamion> all_ubuntu_dapper_sparc:libgnutls11                                    | gnutls11                          | evolution                                    | Matthias Urlichs <smurf@debian.org>                                                   |          291958 |             692
<Kamion> all_ubuntu_dapper_ia64:libgnutls11-dev                                 | gnutls11                          | libedataserver1.2-dev                          | Matthias Urlichs <smurf@debian.org>                                                   |          552646 |            2104
<Kamion> those are the others
<Kamion> sparc seems only fractionally more out-of-date than the big three arches now; I'll put it back into anastacia
<pitti> ah, thank you
<Kamion> ia64 is probably still catching up from its glib2.0 breakage
<pitti> Kamion: is that some output of a program I can access, too?
<Kamion> pitti: not that exact output easily, but it's just germinate, you can run it yourself
<Kamion> 'germinate --no-rdepends -s dapper -d dapper -c main,restricted,universe -a ia64' or similar
<Kamion> should only take a few minutes
<pitti> Kamion: ah, I see; on amd64, g-control-center depends on gnutls12, only on powerpc on 11
* pitti fixes
<mdke> Riddell, around?
<Kamion> hmm, the /etc/skel/Examples symlink means that we now run into Debian #152206 for every user
<pitti> debian bug 152206
<ogra> pitti, thanks, will test :)
* pitti looks at Ubugtu
<pitti> Seveas: -Ubugtu- Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<Seveas> pitti, gracias - will look at it after the meeting
<pitti> thank you
<highvoltage> hi.
<highvoltage> many of the new intel server boards map the memory from 3-4GB as 5-6GB, so with an ubuntu kernel that supports 4GB, it only sees 3.
<highvoltage> should this be marked as a bug in ubuntu (that it should perhaps support up to 64GB RAM?)
<Riddell> mdke: hi
<mdke> Riddell, hiya. I've built some html with nice shiny blue kde things using xsltproc
<wm_eddie> Doh, There isn't a bug in xorg, my hard drive just has no free space >.<
<mdke> Riddell, see http://doc.ubuntu.com/test/kde.png
<mdke> Riddell, I'd like to think about moving back to xsltproc now that I know how to do this, are there any other technical things that need sorting before this is possible?
<infinity> highvoltage: You don't want the desktop kernel for those server boards.
<highvoltage> infinity: where could i get a 'server-kernel'?
<infinity> highvoltage: linux-image-server for 99% of server machines, and linux-image-server-bigiron for the really heavy equipment.
<infinity> highvoltage: If neither of those seems to suit your needs, or they seem s abit wonky/goofy, please file bugs.
<infinity> highvoltage: We need more testing of the server kernels.
<Riddell> mdke: for website that's fine, for kubuntu-docs package we need to use meinproc for the index.cache
<highvoltage> infinity: ok. this will be installed on 200 LTSP servers in South Africa, should be quite useful for testing then :)
<Treenaks> infinity: I installed linux-image-server yesterday, but it didn't boot
<mdke> Riddell, but meinproc doesn't support xincludes right? How do you do it for the server and packaging guides (which use xincludes)
<infinity> Treenaks: Not at all?
<ogra> infinity, talk to the industry to make bigger standard CDrom media and i'll ship the server kernel with edubuntu :)
<Treenaks> infinity: missing initramfs
<infinity> Treenaks: Erm..
<infinity> Treenaks: Hardly seems to be the kernel's fault...
<infinity> Treenaks: Are you using lilo, by any chance?
<Treenaks> infinity: no, grub
<mdke> Riddell, afaics normal HTML (without index.cache) opens fine in khelpcenter
<infinity> Treenaks: Alright, bugs would be nice, then.
<Treenaks> infinity: but if I install linux-image-server, it should install everything correctly, imho
<Riddell> mdke: yes, for server and packaging guides I think it currently uses normal HTML
<Treenaks> infinity: I didn't see the machine not boot :(
<Treenaks> infinity: it's in a datacenter and I had to instruct the datacenter reboot monkey to do grub magic
<doko> mvo: OOo upgrade ping
<infinity> Treenaks: Yes, just like any other linux-image-* package, it should do everything for you, so I'm not sure what may have gone wrong for you.
<Treenaks> infinity: it might be that /boot is too small..?
<Treenaks> (but then it should complain about that)
<mdke> Riddell, I'd really like to use normal HTML for them all, it has the advantage that we can use xincludes for them all and translation is therefore easier. If the html builds look right, I don't see a problem. But that's why I ask: I don't know khelpcenter very well
<infinity> Treenaks: update-initramfs is lacking is some decent error conditions (that's a bug I need to fix before release), so it's possible that you could have hit an -ENOSPC condition or something...
<infinity> Treenaks: I really couldn't tell you while grasping at straws.
<Treenaks> infinity: I'll try again, and check before reboot this time
<infinity> Treenaks: Was there an initrd at all?
<Treenaks> infinity: when I dpkg --purged the package, it said there was no /boot/initrd.img-2.6.15-17-server
<infinity> But you never actually checked after installation?
<infinity> If you could reinstall that kernel and have a look, that'd be nice. :)
<Treenaks> infinity: ok, doing it now [slow, slow /boot disk] 
<Treenaks> hm, crap, I've freed up a lot of space on /boot after fixing it, so it might just work now
<infinity> Well, if it does look like a no space issue, I know that's a bug that needs to be fixed in initramfs-tools, so no big stress...
<Treenaks> initrd.img-2.6.15-17-server -- it's generated now
<mdke> Riddell, I'll email
<mvo> doko: hello
<doko> mvo: hi
<mdke> Riddell, emailed
<Kinnison> Kamion: I now have bandwidth :-) (for a bit) currently branching espresso so I have a copy in case it goes out again. Will upload gparted once I've finished testing that my changes haven't broken it in non-installer mode
<Kamion> Mithrandir: readahead is definitely still very slow when booting today's live CD in vmware
<Mithrandir> Kamion: what's "very slow" for you?
<Kamion> it's been sitting there for at least a minute, dunno yet
<Kamion> it is proportionally much much slower than the rest of the system under vmware
<Mithrandir> can't duplicate that.
<Kamion> in vmware or not?
<Kamion> we duplicated it in vmware at the UI sprint yesterday, so it's not just my installation
<Mithrandir> both
<Mithrandir> or at least with a live image as of friday or so
<Kamion> ah, it's oopsed
<Kamion> unfortunately the stack trace is huge and of course I don't have scrollback; the visible portion is all do_page_fault and error_code
<Micksa> uhm
<Micksa> where is the bug tracking system?
<Kamion> https://launchpad.net/distros/ubuntu/+bugs
<Kamion> Mithrandir: also, I get no worthwhile output if I select a mode other than VGA in the bootloader
<Mithrandir> Kamion: yeah, that oops is something I see too
<Mithrandir> it boots every third time or so
<Kamion> mm, yeah, I also got it to boot by trying a few times
<Kamion> is readahead a huge benefit on the live CD?
<Mithrandir> no, it costs us about five seconds.
<Mithrandir> but I suspect that's because it's not optimised for what we load
<Kamion> can we just make casper turn it off for now then?
<Kamion> I know it's a workaround but I'm worried by the bugs I'm seeing
<Mithrandir> sure
<Mithrandir> I haven't seen the oopses outside of vmware, so I suspect it's a bug in the scsi driver or vmware
<Micksa> okay, so certain applications, including wine, valgrind and UML are getting SIGKILL'd starting with kernel 2.6.15-15, because of the different kernel/user address space split.
<Micksa> is this because of bugs in the programs?  Are they able to not assume where the split is?
<trappist> mdke_: pong
<trappist> does it strike anyone else as ironic that the distro launched by mark shuttleworth doesn't have a valid ssl cert for its website?  I wonder if maybe mark has some pull over at thawte and could get us one.
<Kinnison> which website?
<trappist> https://*.ubuntu.com
<trappist> the wiki, for example
<Keybuk> the wiki has a valid cert
<Kinnison> Yep, certified by Starfield
<ogra> Kamion, could it be that the new world order in he installer (dropped base-config) changed something that prevents sshd from starting before reboot ? 
<trappist> oh, it does now.  I quite paying attention since I said 'accept forever'.  it came to my attention again because an svn co from docteam.ubuntu.com complained about the cert.  I wonder why we don't just get a wildcard cert for ubuntu.com.
<ogra> Kamion, d-i	preseed/late_command	string chroot /target /usr/sbin/ltsp-update-sshkeys
<trappist> *quit
<ogra> doesnt produce anything anymore on install 
<ogra> any hint (from your experience) where specifically i could look
<Kamion> ogra: /var/log/syslog would be a start
<ogra> oki
<Kamion> sshd certainly should *not* be started before reboot though
<Kamion> what does ltsp-update-sshkeys do?
<ogra> copying the ssh keys to the thin client chroot
<ogra> but if sshd was never started it has no keys 
<ogra> so my assumption was right ...
<Kamion> that's not to do with starting sshd
<Kamion> that's based on whether openssh-server has been configured
<ogra> postinst doe it normally
<Kamion> be careful of the distinction
<ogra> hmm ...
<Kamion> /var/log/syslog should have the entire output from pkgsel, including whether openssh-server has been configured
<ogra> i wonder if its appropriate to call the ssh-keygen from ltsp-update-sshkeys ... but then i would have a new key every time ...
<Kamion> to generate a host key? no, inappropriate
<Kamion> you should already have a host key by that point
<ogra> hmm
<ogra> ok
<ogra> i'll dig for it, i just wanted to check my assumptions before looking at it ...
<Kamion> ok, you're using ssh-keyscan to get the host keys
<Kamion> why?
<Kamion> that relies on an actual running sshd
<ogra> hmm, i didnt touch that code yet 
<ogra> mdz, ?
<Kamion> because it connects to the sshd to get its public host keys
<ogra> mdz, is there a specific reason for using ssh-keyscan in ltsp-update-sshkeys ?
<Kamion> I would think just copying them out of /etc/ssh/*.pub would be easier
<ogra> yup
<ogra> but before making such a change i'd like to hear mdz and his intention to use -keyscan :)
<ogra> he must have had a reason for it ... (i suspect)
<Kamion> probably to avoid having to hardcode host key file names
<Kamion> which is a valid concern, but I think it's probably outweighed in this case
<ogra> thats easily turned into a commandline option if you want to override it :)
<Kamion> or parse sshd_config if you really want to be exact there
<ogra> hmm, sounds reasonable ...
* ogra .oO(holbach invasion)
<Kinnison> Kamion: I'm ready to land this gparted version
<Seveas> ogra, "Attack of the holbachs"
<Kinnison> Kamion: when I do, espresso will stop working with gparted until I fix it up
<Kinnison> Kamion: will that bugger up your workflow for now?
<MikeS> Micksa: The case I'm familiar with is valgrind: in that case, valgrind HAS to have a fixed load address compiled in (it's not like a 'normal' application for obvious reasons). The maximum amount of memory available to an application running under valgrind is limited by where this load address is, so it's desirable to have it as high as possible
<Kamion> Kinnison: do you have a branch of espresso already that works with it?
<Kinnison> not yet
<Kinnison> working on it
* Kinnison needs a testbed
<Kamion> Kinnison: it will kind of bugger it up a bit, yeah :(
* Kinnison doesn't want to run espresso on his laptop plain
<Kamion> I'd rather we waited until we can do coordinated uploads
<Kinnison> okay
<Kinnison> I'll hang onto it until I get a branch of espresso sorted
<Kamion> 'cos I know the UI sprint folks want working espresso at the moment
<Kinnison> right
<Kinnison> best not break them then
<Kinnison> I've branched espresso from your ubuntu repo into http://people.ubuntu.com/~dsilvers/bzr/espresso/gparted-updates
<Kinnison> I'll tell you when I've pushed the updates there
<Kamion> thanks
<Micksa> mikes: do you know why dapper's kernel has had its split moved? do you know if valgrind or other progs can be made to not depend on the split being in a certain location?
<MikeS> Micksa: I don't know when or if dapper's kernel had this moved (I thought I saw this on breezy too, but I might be wrong, I didn't investigate it at all at the time)
<Micksa> my laptop constantly runs a uml.
<Micksa> (naturally)
<Micksa> when I upgraded to dapper it broke. then downgrading to kernel -14 fixed it
<MikeS> Micksa: at least for valgrind, it HAS to depend on the split being at-or-above some location, and it makes valgrind more useful if you make that address higher.
<Micksa> no kernels since -15 have worked with this uml binary
<Micksa> mikes: so there is absolutely no way to make valgrind able to work regardless of where the split is?
<Micksa> I can only guess since I have NFI how valgrind works under the hood but generally anything can be configured one way or another
<MikeS> Micksa: note that dapper changed from a 2/2 split (abnormal) to a 1/3 split (extremely abnormal) temporarily, I think this was an accident. The latest .15 package has it returned to 2/2 (which isn't enough for valgrind, but is apparently enough for SOME but not all wine things to work)
<Micksa> maybe this is one of those Hard Problems
<Micksa> hmm.
<Micksa> which latest package?...
<MikeS> Micksa: you have to make this decision at compile time, not at runtime, so it Really Sucks if can't rely on the split being in the normal place
<Micksa> htm.
<Micksa> hrm, even
<Micksa> that does blow.
<MikeS> 2.6.15-16.22 or later
<mjg59> It'll be back to 3:1 in the next kernel upload
<Micksa> aw geez. I've got -17.24 and uml breaks with that :/
<Micksa> I think
<Micksa> mjg: oh good!
<Micksa> mjg: also, MY LAPTOP DOESN'T S3 ANYMORE
<Micksa> you know you love it
<mjg59> The change was because there were some problems with suspend to disk and highmem, but we'll work on that
<mjg59> Micksa: "Doesn't S3" isn't very descriptive
<Micksa> I know
<Micksa> I was just playing
<mjg59> I'll kill you next time I see you
<MikeS> mjg59: ok; thanks.
<Micksa> that's quotable
<Micksa> I gotta crash
<Micksa> later
<Amaranth> someone explain what a split is?
<Kyral> Netsplit?
<ogra> Bananasplit ? 
<MikeS> Amaranth: in  this context: a linux process has part of its address space available to the application, and part mapped for the kernel. You can split the two parts at various places.
<Amaranth> ah
<mjg59> You've only got 4GB of address space available on x86, which is where the problem comes from
<MikeS> oh yeah, I forgot to add that bit: this stuff only really matters on 32 bit architectures.
<Xof> I don't know about that, actually.  The use of bits expands to fill the bits available
<MikeS> Yes, but nobody has enough bits to fill the address space on a 64 bit host :-)
<mdz_> doko: yes?
<ogra> mdz_, due to the new order in the installer, sshd isnt started before ltsp-update-sshkeys is run in late command, is there any particular reason you coose ssh-keyscan instead of just cp to move the keys to the client chroot ? 
<ogra> GAH !
<doko> mdz_: could I have feedback on the mdbtools UVF exception?
<ogra> mdz_, due to the new order in the installer, sshd isnt started before ltsp-update-sshkeys is run in late command, is there any particular reason you coose ssh-keyscan instead of just cp to move the keys to the client chroot ? 
<ogra> (-keyscan requires a running sshd)
<mdz_> doko: you emailed me twice about this already
<mdz_> ogra: only that it was simpler to deal with multiple key types
<ogra> mdz_, ok, then i can change it, thanks, just wanted to know the rationale behind it before i touch it
<doko> mdz_: ? on Friday, and mentioned it today in the postscriptum of another mail
<Kamion> mvo: progress bars don't seem to be shimmering at all for me in anything - it's not just espresso
<Kamion> mvo: for example, as far as I can tell, synaptic's aren't either
<Kinnison> I thought we turned the shimmering off
* Kinnison wills this download to go faster damnit
<Kamion> I'll have to come up with some other way to indicate that espresso's still doing something during slow bits then
<Kinnison> a throbber, mozilla-style?
<Kinnison> an ubuntu logo, slowly spinning
<Kinnison> :-)
<Kinnison> or saturating/desaturating in a loop?
<Kamion> dunno
<seb128> Keybuk: nm-applet doesn't list any connection on my laptop :
<seb128> :/
<Kamion> TBH I suspect better text in the progress bar would do it
<ogra> seb128, silbs had the same prob today iirc
<seb128> Keybuk: it was working yesterday (versions from distro sprint), and since the update it only has a "Wired Network"
<seb128> Keybuk: using an ipw2200 card
<Kamion> anyone know where I can get a good magnifying-glass cursor?
<ogra> Kinnison, after using these PM icons for a day, i must admit i liked the old ones better
<ogra> Kamion, define good ? 
<Kinnison> ogra: Hmm, because jdub really prefers the new jimmac ones
<Kamion> ogra: s/good // if you like
<Kamion> I was hoping not to have to kludge one together from an icon at run-time
<Keybuk> seb128: what's in /etc/network/interfaces?
<pitti> hey Keybuk 
<ogra> Kamion, its sad that art.gnome.org dropped the icon tarballs with 1000 custom icons they once had ... give me a minut
<ogra> e
<seb128> Keybuk: http://pastebin.com/589065
<seb128> Keybuk: it has the essid listed since I played with network-admin after having it broken yesterday
<Keybuk> having wireless-mode and wireless-essid in there will prevent it being listed by Network Manager
<ogra> Kamion, http://people.ubuntu.com/~ogra/search.png would that suffice ? 
<seb128> Keybuk: hum, k, is working now
<seb128> Keybuk: I probably already had a essid before but version before update was not skipping it
<Kamion> ogra: hmm, looks a little weird somehow, but I think it'll do, thanks
<seb128> thank you
<Kamion> ogra: where's that from?
<ogra> Kamion, try search2.png
<Kamion> ogra: that's better, the longer handle helps
<ogra> Kamion, both stolen from tango 
<Kamion> I'll see how that looks, thans
<ogra> locate search|grep png
<Kamion> ah, I was trying zoom
<ogra> ^^ helps :)
<ogra> yeah, search returns more of the document-search icons though ...
<Kamion> the semantics are actually zoom-in
<Kamion> as in on a map
<ogra> ah
<Kamion> hmm, how about /usr/share/icons/gnome/24x24/stock/navigation/stock_zoom-in.png ?
<jbailey> Looking at https://wiki.ubuntu.com/SeedManagement - IIRC, we have a separate CD for server now, but I don't see it mentioned.
<jbailey> Is there a canonical place I can look for the information of what goes into the CDs?
<Kamion> the cdimage code, probably
<Kamion> colin.watson@canonical.com--2005/cdimage--mainline--0
<jbailey> Kamion: Cool, thanks.
<Kamion> I don't think anything else has been reliably kept up to date with *all* the weirdnesses
<jbailey> Mmm.  Is that still a baz archive?
<Kamion> yeah, I'll convert it at some point but haven't had time
<ogra> Kamion, stock_zoom-in.png seems better for that purpose ...
<jbailey> Is now the point where I admit that I've never learned to work baz? =)
<jbailey> Kamion: Can I ask you to tar it up at some point?  Hande's asking me questions as to what we're shipping.
<Kamion> baz register-archive http://people.ubuntu.com/~cjwatson/colin.watson@canonical.com--2005
<Kamion> baz get colin.watson@canonical.com--2005/cdimage--mainline--0
<Kamion> look in bin/list-seeds, compare with the seeds in http://people.ubuntu.com/~cjwatson/seeds/
<jbailey> Kamion: Nice, thanks.
<jbailey> If this works, I'll save this to a text file.  That's the best explanation I've gotten so far from people on how to check something out. =)
* jbailey waits while bazaar installs.
<jbailey> Kamion: Ah, ~cjwatson/archives/colin.watson..., but seems to be working.
<jbailey> Kamion: Thanks!
<highvoltage> jbailey: you know that irritating sugababes song, push the button?
<highvoltage> something i said? :P
<jbailey> Meh, have to sort of the X crashes soonish.
<jbailey> sort out, rather.
<Kamion> jbailey: right, sorry for the bogus URL
<jbailey> All good.  I can troubleshoot 404 errors. =)
<mdke> Riddell: http://doc.ubuntu.com/kubuntu/desktopguide-web/C/ <-- new bling. I'd really really like to do that for the kubuntu-docs package too
<mdke> having multiple build systems is a pain
<jdub> Kinnison: that was totally based on seeing them outside the UI though, so take that POV with a grain of salt :-)
<ogra> jdub, i really cant accociate the icon with a battery 
<Kinnison> jdub: fair enough
<ogra> at least not as it is in the panel currently
<ogra> if we could get the svgs the current icons are based on, it would be very easy to change the colors to something more tame
<ogra> (i.e. a 10 min job)
<ogra> and i dont think people complain about the shape ...
<Kyral> uuh...stupid question. Will Dapper have NTFS Write abilities?
<highvoltage> Kyral: very unlikely
<Kyral> highvoltage: Thats what I thought
<Kyral> someone in #ubuntu had the idea that it would. I said no, but I just wanted to doublecheck :D
<mkrufky> Kyral: i dont even think the stock kernel has ntfs write yet
<mkrufky> it does, but AFAIK, it will only write to a file of equal or smaller file size, and files of smaller sized get padded with null's
<Kyral> mkrufky: I know, I just didn't wanna wind up with proverbial egg on my face
<mkrufky> hehe
<highvoltage> mkrufky: i think it has partial write, but that's only changing existing files
<mkrufky> highvoltage: yes, exactly
<mkrufky> highvoltage: and the file sizes must remain the same, as well
<mkrufky> highvoltage: OR get smaller (with padded nulls)  but not bigger
<mkrufky> I have TDS functionality working correctly using php5 on my ubuntu server, communication with mssql on a windows server..... unfortunately, Breezy's php5 doesnt seem to include support for stored procedures, "mssql_init(), mssql_bind(), mssql_execute()" although all online documentation says that the functionality should be present in php4.1 and later....  anybody know what i'm missing, here?
<Riddell> mdke_: do what?
<desrt> mjg59; are you going to be putting all of this evil in dapper?
<mjg59> Yes
<Seveas> evil is mjg59's last name ;)
<desrt> do you know if your work works on macbooks?
<mjg59> desrt: Ought to
<ogra> Seveas, since xgl i actually tend to belive you :)
<mjg59> Though they have atheros wireless, not Broadcom
<desrt> that's a weird twist
<desrt> i guess the ibooks would probably be atheros too
<desrt> the 'conspiracy theorist' in me wonders if this is a nod to linux users
<highvoltage> a nod?
<mjg59> desrt: On the one hand, wireless that works with an entirely open driver (after an hour or so of hacking), on the other hand something with a binary blob and the entire FreeBSD 802.11 stack in it?
<Kamion> mjg59: do you think that dmidecode is reliable?
<mjg59> Kamion: In what respect?
<Kamion> can I rely on it in the installer as a way to tell that this is an Apple i386?
<mjg59> Yes, that much should be reliable
<mjg59> (As of the version I uploaded at the weekend)
<Kamion> of course, I don't have dmidecode-udeb in the base installer system, and I'm not sure I want to
<Kamion> although it's only 22KB I guess
<mjg59> It's pretty tiny
<mjg59> Now, if we could just get elilo to work...
<Kamion> unfortunately I wouldn't get Debian to take it in the base
<Kamion> since the base applies to e.g. floppies too
<mjg59> Ah
<desrt> mjg59; but at the time when apple was making hardware decisions about what to put in the new mac laptops the open source broadcom driver didn't exist
<mjg59> desrt: Hm. Possible.
<Kamion> mjg59: oh, can I dig it out of /sys/firmware/efi/systab instead?
<mjg59> Kamion: Nope
<mjg59> That just gives you the SMBIOS entry point
<Kamion> bugger
<mjg59> What is irritating is that the kernel /knows/ this stuff, it's just never provided to userspace
<mjg59> I guess we could add a small amount of sysfs code to export it
<Kamion> that would be ideal
<Keybuk> that's what the kernel is supposed to do, indeed
<Keybuk> sysfs attributes are trivial, as they're just kobject attributes
<Keybuk> there's no excuse for *not* providing them
<Kamion> what would it be an attribute on?
<Kamion> /sys/class/misc/ somewhere?
<mjg59> Ok. I'm not likely to have time, but basically it needs to export the dmi_ident array
<Keybuk> /sys/devices/system I'd've said
<Keybuk> or /sys/devices/plat
<Keybuk> +form
<mjg59> Mm? I'd have thought /sys/firmware
<Keybuk> /sys/firmware is the firmware subsystem
<mjg59> This is firmware information
<Keybuk> that's just used for firmware requests and loading
<mjg59> Keybuk: Uh, no
<mjg59> /sys/firmware is the /system/ firmware
<Keybuk> oh, sorry
<Keybuk> yes
<mjg59> Hence /sys/firmware/acpi and /sys/firmware/efi
<Keybuk> which != /sys/class/firmware <g>
<Keybuk> yay kernel guys
<mjg59> /sys/firmware/dmi would seem to make sense
<mjg59> Ok, yeah. Take a look at arch/i386/kernel/dmi_scan.c, then just export each member of dmi_ident[]  
<Kamion> as a bonus, you wouldn't have to be root any more to run dmidecode if all the DMI information were exposed there
<mjg59> Would require adding ascii names to each of them, since that information isn't kept
<mjg59> (include/linux/dmi.h)
<gusaweb> hi !
<gusaweb> I have a problem with floppy disk in dapper
<janimo> gusaweb, try #ubuntu-users
<gusaweb> janimo I think it is a bug
<janimo> gusaweb: the report it in LP
<gusaweb> there is no /dev/fd0
<gusaweb> ok
<mkrufky> modprobe floppy ?
<gusaweb> mkrufky it is ok now thanks
<mkrufky> heehe im glad i could help
<gusaweb> mkrufky do you know the reason of that problem?
<mkrufky> gusaweb: floppy is a kernel module ... apparantly it is not being loaded automatically on your system .. you can get it to load automatically by using /etc/modprobe.conf ... but that is off-topic for this room
<mkrufky> gusaweb: janimo was right when he pointed you to #ubuntu-users ....
<gusaweb> mkrufky ok i am sorry. thanks a lot
<mkrufky> gusaweb: dont be sorry ...  ;-)  
<pitti> doko: I approved your two new python packages
<doko> pitti: thanks
<ogra> pitti, thanks 
<ogra> (unbreaks the edubuntu CD)
<mdz-sprint> Kinnison: my thinkpad's hibernate and suspend keys stopped working in Dapper; is this related to g-p-m changes?
<Kinnison> mdz-sprint: have you checked in gnome-power-preferences to ensure they're enabled?
<mdz-sprint> Kinnison: there is only one option, for 'sleep button'
<Kinnison> is that set to suspend?
<mdz-sprint> Kinnison: i have a suspend button and a hibernate button, both of which did just the right thing in breezy
<Kinnison> the hibernate button support may be waiting on a kernel fix
<Kinnison> the suspend button should work if it's enabled in g-p-p
<mdz-sprint> sleep button action was set to 'do nothing'
<Kinnison> set it to suspend and it should start working
<Kinnison> mjg59 asked me to set it to 'do nothing' by default because many people's laptops break with suspend
<mdz-sprint> unfortunately the net result is that laptops where suspend had been enabled in Breezy stop working
<Kinnison> yes
<mdz-sprint> that's worse
<Kinnison> talk with mjg59, ultimately I'll take on whatever you two decide
<mdz-sprint> mjg59: ?
<Kinnison> I don't quite see how I can migrate the breezy choice though
<Kinnison> unless I do something odd the first time g-p-m is started or something
<mdz-sprint> Kinnison: we created a whitelist in breezy so that suspend was automatically enabled on models where it was known to work
<Kinnison> again, it'd have to be a 'first boot' kinda action
<Kinnison> because it's a gconf setting
<mdz-sprint> if that policy has moved to g-p-m, the logic for choosing the default should migrate too
<mdz-sprint> the most correct behaviour would be to use the whitelist unless the user explicitly sets the preference
<Kinnison> right. that whitelist is where?
* Kinnison notices the time
<Kinnison> I've gotta go pretty soon, can you mail me to remind me to look into this
<Kinnison> ?
<mdz-sprint> Kinnison: in acpi-support
<mdz-sprint> see /usr/share/acpi-support
<mjg59> mdz-sprint: There's no good way of setting a gconf default based on acpi-support settings
* Kinnison heads out. mjg59: If you end up at the free press tonight I might see you there
<mjg59> The default is supposed to come from the schema
<mdz-sprint> mjg59: having suspend no longer work out of the box is a serious regression; surely there is something we can do
<ogra> mjg59, you could set a systmwide default gconf key from postinst 
<Burgwork> http://www.usa4id.com/ciwc/SawedOff.htm <-- mark looks entirely too smug there
<mjg59> mdz-sprint: Hmm. I guess.
<tseng> Burgwork: is that meant to shoot aliens?
<tseng> Burgwork: or insane cosmonauts
<Burgwork> tseng, no wolves in the backwoods of russia
<tseng> 'survival kits on board all spacecraft'
<tseng> oh
<tseng> rtfa
<tseng> Burgwork: http://en.wikipedia.org/wiki/Voskhod_2
<spiekey> hello!
<slomo> infinity, lamont: please give-back liboil on ppc
<spiekey> has the  Bug #24468 in linux-source-2.6.15 (Ubuntu): "Breezy install kernel panics"  been fixed yet?
<Ubugtu> malone bug 24468 in linux-source-2.6.15 "Breezy install kernel panics" [Major,Needs info]  http://launchpad.net/bugs/24468
<spiekey> or is there a workaround?
<ogra> mdz-sprint, did you get my PM ?
<mdz-sprint> ogra: no
<ogra> mdz-sprint, got it now ? 
<Keybuk> *sigh* ... I'm so putting  "explaining to people why NM 0.6 isn't going to dapper" in my activity report, and assigning three or more hours to it
<Mithrandir> Keybuk: write up a wiki page. :-P
<Keybuk> NoYouCantHaveAPony? :)
<Surak> Hello
<Surak> Doko: there?
<Surak> About https://launchpad.net/malone/bugs/33629 - the tip "GTK_IM_MODULE_FILE=/etc/gtk-2.0/gtk.immodules.32" does not work 
<Ubugtu> malone bug 33629 in ia32-libs-openoffice.org "openoffice2 not showing widgets in breezy amd64" [Normal,Needs info]  
<pitti> Keybuk: hi
<pitti> Keybuk: do you have a minute?
<Keybuk> pitti: for you, Martin, I have five! :D
<pitti> Keybuk: I figured out why n-mgr doesn't work any more with l-wlan-ng
<Keybuk> oh right?
<Keybuk> what did I break?
<pitti> Keybuk: 60-dispatch-more-events.patch now causes if-post-down scripts to be run
<pitti> which is fine by itself
<pitti> it just causes a bad series of events
<pitti> I plug in the device, then n-m sees that it cannot control it (since it's not yet activated with wlanctl-ng)
<pitti> so it actively disables the device, which causes the module to get unloaded
<pitti> and thus the dbus-send for refreshing the device fails because the kernel device is gone
<Keybuk> why does the module get unloaded?
<Keybuk> does linux-wlan-ng have a post-down script to do that?
<pitti> Keybuk: because l-wlan-ng has a if-post-down script that does it
<Keybuk> ahh
<pitti> yes :)
<Keybuk> that's not "new world order compliant"
<Keybuk> send the boys around in their black helicopters and make it "disappear"
<pitti> Keybuk: ah
<Keybuk> modules should be loaded by udev/modprobe and never unloaded, unless by hand by the user
<pitti> Keybuk: I wondered whether it was a good idea in the first place to fiddle with a device which n-m can't manage anyway
<Keybuk> how does n-m decide "it can't control it" ?
<pitti> Keybuk: 
<pitti> NetworkManager: <information>   wlan0: Device is fully-supported using driver 'prism2_usb'.
<pitti> NetworkManager: <information>   nm_device_new(): waiting for device's worker thread to start
<pitti> NetworkManager: <information>   nm_device_new(): device's worker thread started, continuing.
<pitti> NetworkManager: <information>   Now managing wired device 'wlan0'.
<pitti> NetworkManager: <information>   Deactivating device wlan0.
<Keybuk> it could be a bug in the post-down stuff I guess
<pitti> Keybuk: at that time it sees wlan0 as a wired interface
<Keybuk> ahh
<Keybuk> ok, so it thinks it can control it, just as a wired interface
<Keybuk> so waits for link/no-link ?
<pitti> i. e. it becomes a wireless one after wlanctl-ng
<Keybuk> right
<Keybuk> one way to fix this
<pitti> Keybuk: probably something like this
<pitti> Keybuk: if I deactivate the post-down script, it works fine, btw
<pitti> so if that's what the new world order wants, then I'll just do that
<Keybuk> look at debian/patches/30-blacklist-devices.patch
<Keybuk> you could add similar code to "refuse to control" a not-yet-ready wlan-ng device
<Keybuk> or, alternatively, you could just drop that "rmmod" script
<Keybuk> removing drivers tends to be more problem than its worth
* Keybuk wonders what happens if you had two of those cards in, for example
<lamont> pitti: if I wanted to have pmounter do it's thing even when no one is logged in, how painful would that be for me?
<pitti> meh, sorry
<pitti> don't kill your foreground network-manager when talking to Keybuk 
<Keybuk> did you get my last?
<Keybuk> <Keybuk> look at debian/patches/30-blacklist-devices.patch
<Keybuk> <Keybuk> you could add similar code to "refuse to control" a not-yet-ready wlan-ng device
<Keybuk> <Keybuk> or, alternatively, you could just drop that "rmmod" script
<Keybuk> <Keybuk> removing drivers tends to be more problem than its worth
<pitti> Keybuk: sorry, the last thing I got was <Keybuk> look at debian/patches/30-blacklist-devices.patch
<Keybuk> -- 
<pitti> Keybuk: alright, I'll do that then
<pitti> Keybuk: however, I think rmmod'ing the drivers is necessary for suspend/resume support
<pitti> Keybuk: since the module doesn't support suspend
<pitti> I fixed that for devices in /etc/network/interfaces
<pitti> but it should be easy to make it work for n-m, too
<pitti> Keybuk: ok, thanks for your wisdom :)
<Keybuk> right, but that's better done at suspend/resume
<Keybuk> rather than whenever anyone goes to change the interface
<Keybuk> ifdown && ifup should always work :)
<pitti> Keybuk: hmm, that post-down script also disables the interface (to conserve power and "to make sure it is not trying to generate interrupts"
<pitti> Keybuk: that seems sensible to me, but would create a race condition
<lamont> pitti: if I wanted to have pmounter do it's thing even when no one is logged in, how painful would that be for me?
<lamont> (since you probably missed that one...)
<pitti> lamont: Hi! yes, I missed it
<pitti> lamont: to whom the device should belong then?
<lamont> well, if it's ext2, root
<pitti> ah, I see
<lamont> etc, etc.  it's more a question of "how does pmount get bolted into the udev event fabric" 
<pitti> lamont: the easiest might be a little udev script that checks if nobody is logged in and calls pmount if not
<pitti> lamont: usually, it's kernel -> udev -> hal -> gnome-volume-manager -> pmount
* lamont hangs his head and mumbles something about being udev-illiterate
<Seveas> pitti, do you happen to recall the bugnumber that made ubugtu barf?
<Seveas> my laptop crashed before I saved the log
<lamont> mako: afternoon
<pitti> Seveas: oh, it was a specific one?
<Seveas> yes
<pitti> Seveas: lemme try to find it again
<pitti> lamont: sth. like /etc/udev/rules.d/80-root-automount.rules: SUBSYSTEM="block", BUS=="usb", RUN += "pmount-root.sh"
<pitti> lamont: then, /lib/udev/pmount-root.sh will be called
<Seveas> debbugs sucks quite hard for these purposes - the html is inconsistent and the mbox does not contain all information I need
<pitti> lamont: this script could do 'pidof gnome-volume-manager', and if that's empty, call 'pmount-hal $DEVPATH
<lamont> pitti: and /lib/udev/pmount-root.sh would be my script that DTRT
<lamont> niceness
<pitti> lamont: oh, wait, not DEVPATH
<pitti> lamont: $DEVNAME is what you want
<pitti> debian bug 355708
<Ubugtu> Error: I tried to send you an empty message.
<pitti> Seveas: this doesn't look right as well: <Ubugtu> Error: I tried to send you an empty message.
<Seveas> gracias (these bogus errors it spits out now are bacause I'm working on it)
<pitti> Seveas: ah, I see; I think I had a different bug some hours ago
<Seveas> correct
<Seveas> something about unpacking
<Seveas> as I'm rewriting the debbugs part now, the exact error is irrelevant
<pitti> Seveas: ah, I found the bug again: 152206
<Seveas> urgh, how do you page up/page down in screen?!
<pitti> I think you can't
<Treenaks> Seveas: Ctrl+A, ESCAPE
<pitti> enabling logging is your friend :)
<Treenaks> Seveas: then use the arrow keys
* pitti hugs Treenaks, thanks
* Seveas hugs Treenaks 
* Treenaks even changed the config to not switch to alternate screens, so shift-pageup works properly
<Treenaks> termcapinfo xterm ti@:te@
<Treenaks> in .screenrd
<Treenaks> in .screenrc even
<trappist> Treenaks: with that you don't have to ctrl-a esc?
<Treenaks> trappist: only if normal scroll-up doesn't work
<mdke> Riddell, use the same build scripts for both web and distribution. I emailed about it
<Seveas> pitti: debian bug 152206
<Ubugtu> debian bug 152206 in adduser ""deluser --remove-all-files" doesn't remove the complete home of the user" [Normal,Open]  http://bugs.debian.org/152206
<pitti> Seveas: \o/
<Seveas> and I take back what I said about debbugs - it sucks less hard than I thought ;)
<pitti> thank you!
<Seveas> np, thanks for reporting
<mako> lamont: hey there
<mdke> nice one Seveas 
<pitti> lamont: oh, btw, your udev rule should also have ACTION=="add"
<shaya> is gdm borked?
<slomo> infinity, lamont: please give-back liboil on ppc
<lamont> slomo: at this time, that's an infinity request. :-(  I hope to become schooled in LP buildd admin sometime "real soon now"?
<lamont> s/?//
<slomo> oh ok :/
<lamont> mind you, that doesn't mean "quit bothering me", just "don't expect me to fix it..."
<lamont> reminding infinity that I'd do it if I could doesn't hurt... but LP changes are needed, AFAIK
<tepsipakki> lamont: I'm still waiting to get more info about the nfs-user-server issue with nfs4.. hopefully it will be resolved this week..
<tepsipakki> lamont: from the nfs-team, that is
<lamont> neato
<fantasai> Can't seem to search in Malone, it keeps giving me an error. Is that reported already?
<Burgwork> fantasai, ask in #launchpad
#ubuntu-devel 2007-03-05
<pochu> snoogie: amule is in feisty, and it's written in c++ and wxwidgets ;)
<nrdb> Hi, I am not sure if this is the correct place to ask, but here goes, I am using ubuntu 6.06 LTS with the 2.6.15-28-686 kernel, I am wondering why there hasn't been a vmware-player-kernel-meodules package yet for this kernel ? :( its been some time since the kernel was updated.
<snoogie> Yes but I read on launchpad that ubuntu need a soft and in specification I read that they want it in pyGTK+glade
<snoogie> nrdb, You need to compile it nope ?
<nrdb> snoogie: there are packages for older kernels
<snoogie> Ok :) but can't you try to compile them using vmware-installer.pl script ?
<nrdb> snoogie: yes!  but I am still wondering why the long delay in getting out an apropiate module for this kernel, is it coming at all ?
<snoogie> ohhh :D
<snoogie> sorry :)
<pochu> nrdb: I think it won't hit Dapper
<nrdb> pochu: ok, that does rather break the whole vmware package :(
<pochu> snoogie: about your question, if you want that app included in the ubuntu installation by default, I don't know, but if you want it included in the repositories, I think there is no problem
<pochu> nrdb: btw, I'm not an Ubuntu dev ;)
<LaserJock> snoogie: is this a bounty?
<nrdb> pochu: just is the repositories, so that vmware keeps working as the kernel gets upgraded.
<LaserJock> a bounty is the only reason I can think of where the language would be specified really
* nrdb bye
<snoogie> LaserJock, not a bounty
<snoogie> wait I ll find link
<snoogie> https://blueprints.launchpad.net/ubuntu/+spec/make-free-space-wizard
<snoogie> and specifications : https://wiki.ubuntu.com/SystemCleanUpTool
<snoogie> I am new in ubuntu developper community
<snoogie> but I want to help, I am a C++ coder and I ll have 4 days this week to do this :)
<snoogie> So I think I can start this tool since I already done one on PDA before
<LaserJock> that's cool
<snoogie> I see that there is someone already assigned for this soft
<snoogie> I lose my time by starting it ?
<LaserJock> you should talk to sivan (sivang on IRC)
<snoogie> Ok I will 
<LaserJock> generally though it's up to the person doing the project to decide what language they will use
<LaserJock> I looks like sivan wants to do python and gtk/glade
<illovae> yo
<snoogie> it's sivan the person assigned to this project .
<snoogie> ?
<LaserJock> yep
<snoogie> Oh yes 
<snoogie> ouch 
<snoogie> he will kill me 
<LaserJock> why?
<snoogie> don't know :D
<snoogie> I am a bit nervous since I register myself on launchpad 
<LaserJock> sivan is a cool dude, I'm sure he'd love help
<snoogie> and take conscience that after signing ubuntero 
<snoogie> coool 
<snoogie> I hope I can help :)
<snoogie> did I need to send a CV :D ?
<LaserJock> heh, no
<snoogie> or something like this :)
<snoogie> lol
<snoogie> nice :)
<snoogie> sorry for my broken english 
<pochu> snoogie: your english is really fine :)
<pochu> snoogie: mine isn't, though ;)
<snoogie> Thanks to my society who ask me to wrote manual and comments in english :D
<snoogie> LaserJock, did you know when I can speak with sivang ?
<LaserJock> I think he lives in Israel
<snoogie> I leave in France and I ll be free for coding wednesday evening and maybe work on it 2 nights during this week
<snoogie> I lived
<snoogie> ouch :)
<LaserJock> snoogie: you can always email him
<snoogie> yes
<LaserJock> hi jono 
<jono> hey dude :)
<snoogie> LaserJock, I mail him directly ?
<LaserJock> yeah
<snoogie> sent
<snoogie> thanks LaserJock for your help
<snoogie> If you see him tell him to don't erase my mail as junk :)
<snoogie> need to sleep now :)
<snoogie> have a nice night/day
<snoogie> see you later 
<theCore> mjg59: ping, can I ask you a question about the desktop-effects program, as you packaged it ?
<tepsipakki> [ANNOUNCE]  xf86-video-intel 1.9.91 (2.0 RC1)
<Fujitsu> ... xf86?
<tepsipakki> that's the -modesetting-branch merged in
<tepsipakki> upstream naming
<fabbione> Fujitsu: it's just the name of the source.. irrelevant
<Fujitsu> 2.0 will replace i810 and have modesetting in a stable release?
<fabbione> tepsipakki: i am getting a bunch of c->xlib locking errors in feisty.. did you look on google? i saw a couple of patches in xorg bugzilla to fix them but i am on vacation and not really motivated to test them
<fabbione> (given that's only a torrent client that triggers them)
<tepsipakki> fabbione: generally they are bugs in the applications that crash
<fabbione> yes i know.. but there are patches to avoid a total crash of the app
<tepsipakki> ok, maybe we could look at them
<tepsipakki> link?
<fabbione> google also explains what to look for.. doublefree, doublealloc.. etc.
<tepsipakki> Fujitsu: yes
<fabbione> not handy.. i looked at it saturday
<tepsipakki> maybe I'll search the bugzilla for them
<tepsipakki> https://bugs.freedesktop.org/show_bug.cgi?id=9336
<Ubugtu> Freedesktop bug 9336 in Lib/Xlib "Assert in Java application WW2D" [Normal,Assigned]  
<tepsipakki> that one?
<tepsipakki> novell has applied that one
<dholbach> good morning
<_ion> Hi\
<dholbach> hi _ion
<doko> dholbach, seb128: care to have a look at the evince-gtk build failure?
* Starting logfile irclogs/ubuntu-devel.log
<tepsipakki> damn, the new -video-intel -driver (2.0rc1) needs server-1.3
<[StingRay] > Hi all, dappers gs-esp is broken. I made a source install of 8.54-gpl and now all is fine. I want to make a deb package out of the source with pbuilder. I have it installed. I have a question: In the howto it says - sudo pbuilder build *.dsc Where do I get the dsc from (apt-get source gs-esp???)
<[StingRay] > I will be much obliged if someone helps a newbie, willing to help other ubuntuers.
<Mithrandir> [StingRay] : if you want to help out with development, #ubuntu-motu is a better starting point.  https://wiki.ubuntu.com/UbuntuDevelopment also has a bunch of pointers
<[StingRay] > Thanks Mithrandir. I will check it.
<Mithrandir> doko: I'm not aware of any uvf exception for python-tz?  In the future, please get aoone before uploading.
<doko> Mithrandir: ohh, sorry. was the sync with tzdata, didn't think of it.
<Mithrandir> doko: np
<dholbach> doko: gpocentek or Janimo know the evince-gtk patch better
<seb128> what about it?
<dholbach> <doko> dholbach, seb128: care to have a look at the evince-gtk build failure?
<doko> bug 89825
<Ubugtu> Malone bug 89825 in evince-gtk "Ftbfs on feisty" [High,Confirmed]  https://launchpad.net/bugs/89825
<Grunf> can you help me :)
<seb128> doko: let xubuntu guys handle it
* pitti looks at feisty-changes and wonders whether this is the current 'archive rebuild test'
<Grunf> Im on Ubuntu 6.06 how to install Dc++?
<pitti> Grunf: #ubuntu, please (see topic)
<doko> seb128: ohh, ok
<Grunf> ok
<mdke> seb128: hiya - a small patch on yelp is on the usual bug; can you take a look at it at some stage? I'd like to get that uploaded and then do another short one before string freeze so everything is more or less up to date
<seb128> doko: that's the package fork they did to have evince without GNOME libs and they said they would do the work on it so it's not extra load
<doko> seb128: didn't see the `x` in the name ;-p
* pitti hugs doko for python-tz
<seb128> mdke: it's on my list of things to look at, will do that next
<mdke> seb128: great, thanks.
<seb128> np
<seb128> hi cjwatson
<doko> fabbione: could you have a look at the heartbeat ftbfs on ia64 (IPv6?)
<cjwatson> morning
<mantiena> cjwatson: Hi, could you access http://people.ubuntulinux.org/~cjwatson/ ?
<cjwatson> mantiena: ubuntulinux.org is hideously obsolete. Use ubuntu.com. If that doesn't work, I don't run people.ubuntu.com so it's not really my problem
<cjwatson> that machine gets rather busy at times
<Keybuk> people is down, no?
<Keybuk> it was over the weekend, anyway
<pitti> Keybuk: right, since Sat
<Keybuk> rookery go bye-bye
<pitti> carlos: ^ no langpack building for now :/
<mantiena>  http://people.ubuntu.com/~cjwatson/ also not accessible
<mantiena> :(
<mantiena> cjwatson: I need people.ubuntu.com because I need to know what mkisofs options needs to be used for building Ubuntu DVD images
<mantiena> I've build several customized DVD images according to https://help.ubuntu.com/community/LiveCDCustomization/6%2e06 but my CD's doesn't boot on lots of computers (isolinux doesn't start at all), while official Ubuntu DVD images does
<mantiena> but when I burn  not on DVD, but on CD, then this CD starts fine on all computers
<mantiena> I don't know if this is mkisofs bug or for bootable DVD another mkisofs options are needed, than for CD
<carlos> pitti: oh, so that's the reason why my scripts got stalled with the rsync....
<carlos> pitti: anyway, the initial import is taking longer than planned
<Mithrandir> mantiena: uh, the same .iso image works on CDs but not DVDs?
<cjwatson> mantiena: last I checked the instructions on the wiki were accurate
<mantiena> cjwatson: is different mkisofs options needed for bootable DVD, than for CD ?
<cjwatson> no
<mantiena> cjwatson: sorry for bothering, but could you tell me what Ubuntu version is running on ubuntu server, which builds ubuntu edgy DVD ?
<cjwatson> 6.06 IIRC
<mantiena> cjwatson: thanks, so, I guess this is Edgy's mkisofs bug
<cjwatson> I have no idea
<mantiena> I will try with genisofs from Debian
<Mithrandir> doko: the ecj bug list, is that the list of outstanding bugs, the list of fixed bugs or what?
<doko> Mithrandir: fixed (and read only those with the compiler keyword)
<Mithrandir> doko: do you have a list of changes from the current version in ubuntu?  The release notes seems to contain a whole lot of irrelevant stuff.
<doko> Mithrandir: nothing but a diff, if that helps you.
<doko> pitti: the bad news was that did discover two new packages with time zone data
<Mithrandir> doko: no, that doesn't help me.
<mantiena> btw, who is responsible for discover1 and discover-data packages ? There is an important bug , when  discover1 assings vesa driver for lots of video cards - look at bug #89356
<Ubugtu> Malone bug 89356 in Baltix "Lines with string "unknown" in second and/or third column should be removed from /lib/discover/pci.lst " [Undecided,Unconfirmed]  https://launchpad.net/bugs/89356
<Mithrandir> doko: I need a list of changes, though.
<Riddell> mvo: no change on dist-upgrader upload?
<mvo> Riddell: last time I checked, 0.57.8 was in the archive
<mvo> Riddell: http://archive.ubuntu.com/ubuntu/dists/feisty/main/dist-upgrader-all/ lists it (since 2.mar)
<doko> Mithrandir: there is none, same situation as in any eclipse release
<Riddell> mvo: ah, it's just current isn't updated
<mvo> urgh
<mvo> Riddell: I will raise that with cprov, once he is available in #soyuz
<Riddell> thanks
<mvo> Riddell: thank you for verifiing!
<mvo> Riddell: got my /msg about something unreleated?
<Riddell> replied
<mvo> thanks
<mantiena> mjg59: hi, are you online ?
<Keybuk> "The project is an attempt to deliver a complete Linux-based operating system supplemented by Islam study software (in Arabic and English) and by an innovative system tray utility that alerts the user to prayer times and automatically plays the appropriate prayer (the prayers are in the free Ogg-Vorbis format)."
<Keybuk> that is so cool
<pitti> lol, apt-get install priest
<Keybuk> prayrave?
<pitti> yay rookery!
<seb128> pitti: rock on ;)
<pitti> seb128: I'll upload a new apport with the fakechroot support now, so that it is easy to install in fakechroots
<gpocentek> pitti: could you promote thunar-volman-plugin to main? you've approved the MIR
* seb128 hugs pitti
<pitti> gpocentek: in a bit
<gpocentek> pitti: thanks
<gpocentek> pitti: oh, and the i386 binary is missing in the archive, no idea why (it didn't FTBFS)
<pitti> simply not built yet?
<gpocentek> it's built
<gpocentek> (checking)
<gpocentek> pitti: https://launchpad.net/+builds/+build/301985 << it's built
<stgraber> some packages built yesterday evening (~22:00 utc) are still not on archive.u.c
<gpocentek> stgraber: this one built weeks ago
<stgraber> really weird then :)
<pitti> gpocentek: this needs to be settled out before main promotion
<gpocentek> pitti: can I just do a non-change upload?
<pitti> gpocentek: let me look
<gpocentek> ok
<pitti> thunar-volman-plugin | 0.1.2-0ubuntu1 | feisty/universe | source, amd64, ia64, powerpc, sparc
<pitti> hm
<cjwatson> it's probably in failed-to-move; let me check
<pitti> it's not in binary NEW at least
<cjwatson> 13:06:43 INFO    Rejected:
<cjwatson> 13:06:43 INFO    thunar-volman-plugin_0.1.2-0ubuntu1_i386.deb: Version older than that in the archive. 0.1.2-0ubuntu1 <= 0.1.2-0ubuntu1
<cjwatson> blink
<cjwatson> how about I just retry it
<iwj> lfittl, zul: bug 89133> Let me know if you're around.
<Ubugtu> Malone bug 89133 in xen-source "Problem with blktap and LVM (device numbers)" [Undecided,Needs info]  https://launchpad.net/bugs/89133
<cjwatson> it's quite insistent that it's in the archive
<cjwatson> definitely not in the db though ...
<cjwatson> whoa
<cjwatson> 10:46:43 DEBUG   Checking for thunar-volman-plugin/0.1.2-0ubuntu1/i386 binary ancestry
<cjwatson> 10:46:43 DEBUG   thunar-volman-plugin: (binary) exists in amd64/RELEASE
* cjwatson sounds the soyuz bug klaxon
<fabbione> doko: i am on vacation till next monday. we have halley (ia64) at the datacenter for porting
<cjwatson> gpocentek: a new upload will probably not help (or if it does, will only help by accident) and will make it harder for the Soyuz guys to reproduce this bug, so please don't
<doko> fabbione: halley is still down. I'm submitting a bug report; may I subscribe you?
<fabbione> doko: my ia64 is turned off and hasn't been updated in ages, but i can for sure look at it once i am back
<fabbione> doko: best if you mail me the bug number
<doko> ok
* fabbione gets tons of bugs
* fabbione &
<gpocentek> cjwatson: ok
<cjwatson> gpocentek,pitti: bug 89846
<Ubugtu> Malone bug 89846 in soyuz "binary ancestry calculation broken for new binary packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89846
<geser> Mithrandir, cjwatson: do you if someone is working on an uvf exception for fuse 2.6.3?
<ogra> cjwatson, is there any equivalent to the old loadkeys command in the new console-setup implementation ? 
<Mithrandir> geser: I haven't heard of any.
<ogra> i tried setupcon, but it needs a full config file
<cjwatson> ogra: you can still use ckbcomp and loadkeys in combination
<cjwatson> ogra: I'm afraid there's nothing quite as simple as the old loadkeys invocation yet, though
<ogra> ok
<cjwatson> (loadkeys is used by setupcon)
<ogra> oh, if i call it directly its missing something ...
<cjwatson> you can't just use 'loadkeys uk' or whatever, no
<cjwatson> more like ckbcomp -model pc105 gb | loadkeys
<ogra> ah, k
<ogra> yeah, works, thanks :)
<ogra> btw, your ldm code had a slight typo ... "while [ "$(fgconsole)" = "$orig_console" ] ; then" ...
<ogra> err s/ldm/usplash/
<cjwatson> ogra: where's the typo?
<ogra> then vs do
<cjwatson> ah
<ogra> :)
<cjwatson> yes, fair point
<ogra> geser, not yet ... feel free to use me as upload bitch if you want ...
<ogra> i tink the upstream comments justify an UVF exception
<ogra> *think
<mneptok> omegabeta: export PS1="[%n@%m]  %{$fg_bold[blue] %}%B%1/%b%} :: "
<mneptok> [user@host]  pwd ::
<mneptok> ;)
<mneptok> oops ww
* Hobbsee waves
* mneptok gets seasick
* Mithrandir tickles Hobbsee 
* Hobbsee stomps on Mithrandir's feet
<pitti> seb128: can you please binary-NEW apport-retrace? I don't want to NEW my own stuff
<pitti> seb128: please put it into main, I'll seed it
<seb128> pitti: looking
<pitti> seb128: if you manage in the next 10 minutes, I can set up the fakechroots soon :)
* pitti hugs seb128
* seb128 hugs pitti
* mneptok gets FIRED UP!
<pitti> seb128: (seeded)
<seb128> pitti: and binary accepted to main
<pitti> seb128: let's get ready to rumble then :-P
<seb128> ;)
* mneptok hugsn apport-retrace as if he hasn't seen it in 2 Herd releases
<pitti> mneptok: don't squeeze the important bits out of it :)
<mneptok> pitti: it has important bits?
<pitti> mneptok: yes, the '1' ones
<StevenK> pitti: You approved cryus-imapd-2.2 into edgy-proposed. Whyfor are the only .deb's appearing in the Packages list for edgy-propsed on this machine only arch all?
<mneptok> don't tell me there's not one bit of difference between null and zero, because that's exactly how much  difference there is.
<pitti> StevenK: maybe it hasn't built yet on the other arches? or it's yet another failed-to-move fallout?
<StevenK> pitti: It certainly built.
<StevenK> ... or did it.
<Fujitsu> pitti: What does this fakechroot support achieve?
<pitti> Fujitsu: complicated answer: you can generate, update, and retrace in chroots entirely with user privileges
<pitti> Fujitsu: easy answer: automatic crash retracing in the DC
<Fujitsu> I do like the latter of those two. Is there an ETA for it all being automatic?
<pitti> Fujitsu: the level of automatism will raise over time
<pitti> Fujitsu: first stage is manual invocation in the DC until I wrote the bits for interacting with Malone
<pitti> Fujitsu: I need to work around some limitations of Malone, like the lack of an interface to add new attachments, and search for bugs starting with a certain number
<Fujitsu> pitti: Surely such requests would have high priority with the LP guys?
<pitti> Fujitsu: well, except that there is other stuff with even higher prio :)
<pitti> Fujitsu: and if we can cope with the currrent functionality, so much the better
<StevenK> pitti:  edgy amd64   Successfully built
<Fujitsu> How are you going to manage adding attachments without a non-HTML interface?
<StevenK> pitti: Will you look, or should I bug somebody else?
<pitti> Fujitsu: either I use the HTML interface and need to sort out the authentication bits, or I attach the retraced stack traces inline with an email
<pitti> StevenK: look for what? buildd -> infinity or Mithrandir; Soyuz screwage -> cprov or cjwatson 
<sladen> mjg59: should apmd/libapmd be being installed on an ugrade?
<mjg59> Doubt it.
<mjg59> They probably ought to be part of base, though
<mjg59> s/base/ship/
<mjg59> (whatever)
<Mithrandir> StevenK: checking
<cjwatson> desktop: * apmd [i386] 
<iwj> Riddell: re bug 89489> In Kubuntu, what controls how dpkg is run when you `right [click]  the mouse to install a .deb package' ?
<Ubugtu> Malone bug 89489 in initramfs-tools "initramfs-tools hangs on modprobe --show-depends thermal" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89489
<cjwatson> so that should be installed on upgrade
<sladen> cjwatson: nod
<StevenK> Mithrandir: Thanks
<StevenK> pitti: Fair enough, okay.
<Riddell> iwj: it's just a script that launches a console with dpkg --install, pretty primitive
<mjg59> cjwatson: No negative feedback from the parted people, so that patch ought to be good to go
<cjwatson> which one?
<mjg59> The gpt/mbr syncing one
<cjwatson> mjg59: I haven't seen the patch yet - did you throw it at a bug?
<mjg59> Yup
<mjg59> Oh, Malone is making me cry
<cjwatson> ah, bug 84815
<Ubugtu> Malone bug 84815 in partman-efi "Fails to correctly set up partitions on Intel Macs" [Undecided,Needs info]  https://launchpad.net/bugs/84815
<cjwatson> or not
<mjg59> No, it was an earlier one
<mjg59> How do I get a list of bugs I'm subscribed to?
<cjwatson> launchpad.net/~mjg59/+subscribedbugs
<Riddell> iwj: Exec=xterm -title "%c" -e 'sudo dpkg -i %U; echo "Press <enter> to exit..."; read;'
<mjg59> cjwatson: Ah - https://launchpad.net/ubuntu/+source/ubiquity/+bug/46853
<Ubugtu> Malone bug 46853 in ubiquity "grub install fails on EFI Intel Macs" [Medium,In progress]  
<cjwatson> ok, thanks, I'll look after lunch then
<Mithrandir> StevenK: soyuz ate them, I'm looking at recovering them.
<fabbione> doko: heartbeat failed on sparc too
<fabbione> hmmm
<fabbione> Mithrandir: could you be so kind to check outdate to see if something has been stalling on sparc to cause   libcurl3-dev: Depends: libcurl3-openssl-dev (= 7.15.5-1ubuntu2) but it is not going to be installed ?
* fabbione shouldn't even be here
<Mithrandir> fabbione: curl is needs-build on sparc
<Mithrandir> I've bumped the priority of it, so it should be in soonish
<fabbione> doko: the heartbeat problem might be a missing kernel header..
<fabbione> ia64: checking for linux/icmpv6.h... no
<fabbione> i386: checking for linux/icmpv6.h... yes
<fabbione> doko: ^^ this one is the problem for sure.. you can see in the i386 build log that it then builds IPv6addr
<fabbione> Mithrandir: thanks a lot.
<Mithrandir> fabbione: sparc seems busy with guile and new gcc ATM, but guile is just about finished so I'll give back heartbeat once it's in.
<fabbione> Mithrandir: that's great. thanks
<Mithrandir> (which should be in an hour or so)
<doko> Mithrandir: how does giving back heartbeat help?
<Mithrandir> doko: wasn't the heartbeat failure on sparc due to the curl skew?
<StevenK> Mithrandir: Aye, thanks.
<StevenK> Mithrandir: So Soyuz ate all of the arch dependant .debs and let through the two arch indep ones. Neat.
<Mithrandir> StevenK: yes, something like that.  We need code changes to recover it, but cprov is working on that.
<doko> Mithrandir: ohh, sorry
<StevenK> Mithrandir: Okay, cool.
<Mithrandir> doko: it might not be, I wasn't following the discussion 100%.
<doko> Mithrandir: no I checked now, please requeue
<Mithrandir> doko: do you know when ooo 2.2 is scheduled for?
<fabbione> Mithrandir: yes.. heartbeat on sparc is due to curl
<fabbione> doko: did you read above about ia64?
<doko> Mithrandir: it was scheduled for Wednesday, but probably will be delayed  by a few days. (rc3 was unexpected). there's a release meeting today, so expect some news
<Mithrandir> doko: thanks; keep me posted.
<StevenK> Feisty with Oo.o 2.2 would be awesome.
<StevenK> If I can put my $0.0002 in.
<Mithrandir> it would.  But I'd much rather have 2.2 than 2.2rc3
* StevenK nods.
<iwj> Riddell: Ah.  Because that's obviously not robust against spaces in filenames.  (I meant bug 57102, not 89489.)  Can I assign the bug to you, if you know where this script is ?
<Ubugtu> Malone bug 57102 in dpkg "Kubuntu 6.06 locale problem: package doesn't get installed when it is in a directory with spaces on its name" [Undecided,Confirmed]  https://launchpad.net/bugs/57102
<Keybuk> heh
<Mirv> Mithrandir: have you had time to check if the two patches for importance "High" bugs in xserver-xorg-video-ati could be put to feisty? (22985 with 19 duplicates, 63503 with 6 duplicates). or should I ask someone else to check&include those?
<Keybuk> you can't even build most software in directories with spaces in their name
<iwj> Keybuk: Yes, but these are err naive users who expect pointyclicky things to work.
<Mithrandir> Mirv: it might be better to ask tepsipakki, since he's been doing X work lately.
<iwj> Not people trying to build software.
<Riddell> iwj: sure
<iwj> Riddell: Done, thanks.
<Mirv> Mithrandir: ok, then
<Keybuk> iwj: good point
<doko> hmm, after I upgraded all machines to feisty, I see a long delay (4sec) ssh'ing between the machines
<torkel> doko: #84899 ???
<doko> bug 84899
<Ubugtu> Malone bug 84899 in openssh "SSH with GSSAPIAuthentication option on SSH servers are very slow" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84899
* Hobbsee gets afraid when there are bugs like these....
<Hobbsee> https://beta.launchpad.net/ubuntu/+bug/89856
<Ubugtu> Malone bug 89856 in Ubuntu "Protection at what cost? " [Undecided,Unconfirmed]  
<Hobbsee> thanks mjg59 
<Hobbsee> mjg59: i was trying to think of what to reply in a diplomatic way...
<Keybuk> iwj: hmm, so what kind of tests would one run once the package is installed?
<iwj> Keybuk: Well, that would depend on the package.  For something like upstart you'd probably have some test events, or check that some events you had anyway were properly processed.
<iwj> Some of those kind of tests would be rather intrusive on a system you were trying to use for something else which would make autopkgtest's xenlvm stuff come in handy.
<Keybuk> iwj: can the tests destroy the running system?
<iwj> Keybuk: Yes, they're allowed to.  You're supposed to declare this in the metadata.
<iwj> (So that it won't run them if your virtualisation isn't sufficiently good.)
<iwj> Although I suppose if you destroy the system enough it might be too broken for adt-run to retreive the results :-).
<Keybuk> the obvious upstart tests would be to create a new job, make sure it's parsed and loaded, try starting it, querying the status, killing the process, see if it respawns, stopping the job again; then emitting an event to see if the job gets started, and another to see whether it gets stopped
<iwj> Right.
<cjwatson> doko: if GSSAPIAuthentication=no doesn't fix it then it's surely not the same problem and shouldn't be conflated in the same bug
<cjwatson> doko: anyway, ssh -vvv and possibly some indication of the point in the verbose trace where it seems to hang would help
<Mithrandir> cjwatson: maybe ssh with a sufficient number of -v-s should print timing information, like you can get strace to do?
<Mithrandir> just a thought.
<cjwatson> => upstream ;-)
<cjwatson> wouldn't hurt, it's true
<Mithrandir> does upstream have a useful bug tracker, or can you take it there?
<cjwatson> there should be a command to do that for arbitrary subsidiary commands
<cjwatson> bug tracker> bugzilla.mindrot.org
<cjwatson> addtimings ssh -vvv blah
<Mithrandir> hmm, true.  That'd be useful.
<cjwatson> just grab its stdout and stderr, select on them, and stick gettimeofday in front every time you get a completed line
<Mithrandir> indeed.
<tkamppeter> Mithrandir, pitti, as you have probably seen in my e-mail I have made new cupsys and gnome-cups-manager packages for network printer auto-detection.
<Mithrandir> tkamppeter: yes, I just haven't gotten around to answering yet.
<tkamppeter> There I have a problem with the debian/*.templates and dpkg-reconfigure mechanism.
<tkamppeter> I have modified the debian/cupsys.templates file to change the defaults (activate snmp backend).
<tepsipakki> I have a new version of ati-driver to test.. it has three patches included which fix bugs
<tkamppeter> If I do a fresh install of cupsys the snmp backend is active immediately, but if I update cupsys, the old configuration is conserved and so snmp is inactive,
<pitti> tkamppeter: but that sounds about right
<tepsipakki> it's here: http://users.tkk.fi/~tjaalton/xorg72/new
<tkamppeter> How can I let the update of the cupsys package activate the snmp backend?
<tepsipakki> i386 deb included, built in pbuilder
<pitti> tkamppeter: if you want to enable it by default on upgrades, you need to add the symlink in the postinst
<tkamppeter> pitti, only disadvantage of this approach is that if someone changes the configuration manually, these changes get lost with every update.
<pitti> tkamppeter: how do you mean? adding the symlink in the postinst should work with a reconfigured package as well?
<tkamppeter> Is there nothing with which one can tell whether the settings of the previous config are defaults or changed by the user?
<pitti> tkamppeter: why do you want to know that?
<pitti> (no, you have to check the symlink structure manually)
<tkamppeter> I mean, if in postinst a symlink is set, this symlink is set everytime when the package is updated, If the user configures the symlink away (because he does not his 1000 network printers being listed) the symlink gets set again when he updates cupsys the next time.
<pitti> tkamppeter: no, you must use dpkg --compare-versions on $2 to only do it once
<tkamppeter> I want to know whether a setting is default or set by hand, so that I apply new defaults only to settings which were on default before.
<pitti> tkamppeter: there's no way to find out
<pitti> tkamppeter: users might meddle with the symlinks manually, or switch a backend on and off again, etc.
<pitti> tkamppeter: in a situation where you aren't sure whether it's a good idea to change a default configuration, then it's most likely *not* a good idea to do it
<tkamppeter> So perhaps the dpkg --compare-versions approach is the best, so I do the change of the default via postinst only if the package to be replaced is cupsys 1.2.8-0ubuntu2 or older.
<pitti> tkamppeter: sth. like dpkg --compare-versions "$2" lt-nl <version that has the default change>
<tkamppeter> This introduces the new functionality for every user who never cared about changing these setting (99% of the users) and the 1 % (and these users know about how CUPS works) who wants the newly activated backends turned off turn them back off once and then they stay off on future updates.
<seb128> tkamppeter: hi
<seb128> tkamppeter: do you know if there is a standard user,password to use when trying to add a smb printer from a windows XP box?
<Mithrandir> tkamppeter: also note that changing configuration outside of debconf must be supported and the configuration scripts must pick up the changes from the file system.
<tkamppeter> seb128: AFAIR you can make shared printers available for guests under windows and then they work with user name GUEST and without password. In the smb://... URI of CUPS you simply omit user and password. You supply at least hostname or IP and share name and optionally the workgroup name in the URI.
<seb128> tkamppeter: let me try again, with no user,pwd or guest it was going to next step with gnome-cups-manager but the printer is not added and there is an IPP code error on the command line
<xerxas> Hi all
<seb128> tkamppeter: "** (gnome-cups-add:18083): WARNING **: IPP request failed with status 1028"
<tkamppeter> seb128, this is another bug, which I have already fixed, see bug 81787. Download and install the foomatic-db-engine referenced there, then try again.
<Ubugtu> Malone bug 81787 in foomatic-db-engine "Can't add printer with the Postscript Driver" [Medium,Fix committed]  https://launchpad.net/bugs/81787
<seb128> tkamppeter: trying
<did447> Hi, as there's some works done on casper is it possible to fix : 79064, 66585,  62868 and 68054? Each of them are a one or two lines change.
<bddebian> heya
<pitti> seb128: please say hello to bug 88999, the very first apport retrace generated on ronne :)
<Ubugtu> Malone bug 88999 in gnome-system-tools "[apport]  network-admin crashed with SIGSEGV in gst_network_locations_get_current()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88999
<seb128> pitti: waouh, ROCK ON
* seb128 hugs pitti
<seb128> pitti: it's a dup, but nice ;)
<pitti> seb128: no problem, you can run it yourself now if you want
<seb128> pitti: I'll try just after restarting to look if the printer works from windows on that box
<tkamppeter> pitti, I have found out now that the settings of the cupsys.template file are in the sections with owner cupsys in the /var/cache/debconf/config.dat file and the postinst deletes all links and then loads the settings and sets the links according to these settings. So the one-time setting of the symlink would get lost on the next update.
<seb128> tkamppeter: no, that update doesn't fix it, with windows it works without asking any information though, the printer is an HP Deskjet
<tkamppeter> I suggest a one-time modification of the cupsys/backend line in the /var/cache/debconf/config.dat file. This should work correctly.
<cjwatson> wah
<tkamppeter> Is there a special command to be used in the postinst script to modify this line?
<cjwatson> don't change config.dat directly whatever you do
<cjwatson> you can source the debconf confmodule and use db_set if you're very very careful. See debconf-devel(7) in the debconf-doc package
<cjwatson> debconf-using code is supposed to honour settings in the filesystem before those in the database, though, so that is unnecessary with correctly-written code
<tkamppeter> seb128, so the IPP error is probably not caused by not being able to build the PPD (that problem happened only with PostScript printers) but because of a bad URI.
<seb128> tkamppeter: I don't type any URI, I pick the computer and printer from the dropdown boxes on the dialog
<tkamppeter> seb128, you DeskJet can be installed on a local USB or parallel port without any problem?
<seb128> yep
<tkamppeter> seb128, then gnome-cups-manager builds a bad URI.
<tkamppeter> What exactly do you select on the first page of the wizard (printer connection)?
<seb128> Network Printer
<seb128> then Windows Printer (SMB)
<seb128> I cancel the "authentification required" for the different network boxes which have no printer
<tkamppeter> cjwatso, then this code is not correct:
<tkamppeter> 	db_get cupsys/backend && SELECTED=$RET
<tkamppeter> 	list=`echo $SELECTED | sed -e 's/, /,/g'`
<tkamppeter> 	save_IFS=$IFS
<tkamppeter> 	IFS=,
<tkamppeter> 	(cd /usr/lib/cups/backend && rm -f http ipp lpd parallel scsi serial socket usb snmp)
<tkamppeter> 	for module in $list; do
<tkamppeter> 	  ln /usr/lib/cups/backend-available/$module /usr/lib/cups/backend/$module
<tkamppeter> 	  if [ "$module" = "ipp" ] ; then
<tkamppeter>             ln /usr/lib/cups/backend/ipp /usr/lib/cups/backend/http
<tkamppeter> 	  fi
<Mithrandir> tkamppeter: use a pastebin, please.
<tkamppeter> 	done
<tkamppeter> 	IFS=$save_IFS
<tkamppeter> It reads out from the db, then deletes all symlinks and applies the result of the db query.
<seb128> then I pick the host from the first dropdown, use GUEST no pwd for the identification, then pick the printer from the other dropdown and click on forward
<cjwatson> tkamppeter: indeed, it's wrong.
<cjwatson> tkamppeter: not to mention the dire shell quoting.
<tkamppeter> seb128, can you also try not filling in both username and password and then see in /etc/printers.conf which URI you get and also filling in both username and password with arbitrary values and see what URI you get?
<cjwatson> tkamppeter: although such wrongness is not quite so bad when it's in /usr, I guess
<cjwatson> it would be a LARTing offence in /etc.
<tkamppeter> seb128, for me it looks like that gnome-cups-manager has a bug and does not handle correctly if you enter only a user name and no password.
<tkamppeter> To test whether CUPS is OK, set up your print queue in gnome-cups-manager with GUEST as user name and xxx as password, then edit /etc/cups/printers.conf removing @xxx from the URI and restart CUPS. Then try to print into this queue.
<seb128> tkamppeter: there is no printer added, none listed to /etc/cups/printers.conf
<tkamppeter> cjwatson, for the raw printing the code in the cupsys.postinst looks better. It starts with "db_fget cupsys/raw-print changed" and then does only things if the result is true. Is this a check whether the user has manually changed something?
<tkamppeter> seb129, even if you fill in both user name and password?
<seb128> yep
<seb128> with GUEST and random password
<seb128> or random user and random password
<seb128> or nothing
<pirast> could anyone please activate the nominations in bug 89863?
<Ubugtu> Malone bug 89863 in asterisk "Asterisk 1.2.16 fixes a recently discovered security vulnerability" [Undecided,Confirmed]  https://launchpad.net/bugs/89863
<keescook> pirast: sure, done.
<seb128> hi keescook
<keescook> hiya seb128.  I'm not really here yet.  ;)
<seb128> keescook: I'm just saying hello, I've no work for you, don't worry ;)
<pirast> keescook, thanks ;-)
<keescook> hehe, cool.  :)  I'm already looking forward to May.
<tkamppeter> seb128, can you try once using another connection type than smb and the same PPD file and see whether you get a queue then?
<tkamppeter> And also try to stay with smb but use another PPD. Do you get a queue with that?
<seb128> tkamppeter: other PPD with smb does the same, trying without smb now
<seb128> tkamppeter: with ipp and the same ppd the printer is added correctly
<tkamppeter> So there is a bug in the gnome-cups-manager. It builds broken URIs for the SMB backend.
<tkamppeter> seb128, can you run gnome-cups-add through strace, try to set up an SMB printer again and then search the strace output for a URI beginning with smb://...? Can you post the URI here, and also try to set up a queue with the lpadmin command using this URI?
<seb128> tkamppeter: I'll have a look at debugging that, strace -f doesn't list any uri or anything with "smb" when trying to add it
<pirast> kesscook, am i allowed to change the maintainer field in a security update (https://wiki.ubuntu.com/DebianMaintainerField)?
<pitti> pirast: doesn't make much of a differencee, but I'd prefer not to
<cjwatson> tkamppeter: db_fget checks whether the question has been "seen" (i.e. presented to the user) by debconf. This is a slight improvement but still wrong. See the "Config file handling" section of debconf-devel(7) in the debconf-doc package.
<pitti> pirast: you should use the dpkg tools from the stable chroot you're building the update in
<pirast> pitti, .... okay...
* iwj resorts to taking photos of the BIOS splash screen with a digicam.
<neighborlee> by chance is nvidia isntall via synatpic working in hurd 5 ?
<gnomefreak> pitti: when you get a minute, what package holds apport-retrace command? (apport)? there doesnt seem to be a command apport-retrace in feisty anymore.
<gnomefreak> neighborlee: yes works here
<gnomefreak> neighborlee: try #ubuntu+1
<pitti> gnomefreak: it's in the new 'apport-retrace' package now
<pitti> gnomefreak: I'll write an announcement soon
<gnomefreak> oh ok ty :)
<neighborlee> wow thatsg a nice surprise given that I had no luck with  it in edgy
<doko> Mithrandir: please requeue scim-hangul on all archs but sparc
<neighborlee> gnomefreak, what is this +1 all about
<gnomefreak> neighborlee: #uubntu+1 is the feisty support channel
<neighborlee> ahok ic thsx
<pitti> gnomefreak: I just sent some details to ubuntu-devel@
<gnomefreak> pitti: ty working on it to see if it is causing my issues
<asac> keescook: ping
<keescook> asac: pong
<asac> keescook: you got my pm ?
<keescook> yup, replying now...
<keescook> hi pitti.
<pitti> moin keescook 
<keescook> ack: so I can't run apport-retrace as a result user without fakechroot?
<shawarma> Who reviews Summer of Code applications for Ubuntu?
<pitti> keescook: you can, you can just not install packages
<pitti> keescook: or you have to change /var/lib/apt etc. to belong to you in the chroot
<cjwatson> shawarma: doko and Keybuk are doing it this year
<pitti> keescook: however, the general idea is right now to call retrace on ronne, and get fully automatic retracing in Malone soon
<keescook> pitti: yup.  well, I'll deal with it.  :)
<keescook> Mithrandir: just wanted to double-check, I'm about to sponsor/upload asac's thunderbird security update for feisty.  I'm assuming this is okay since it's effectively a regular security upload.
<pochu> pitti: are feisty crash reports supposed to have a coredump?
<pochu> I have a bug without it, so I can't use apport-retrace
<lemsx1> guys is nice to see that everything just works on Feisty
<lemsx1> i just wanted to point that out
<seb128> lemsx1: nice to know ;)
<lemsx1> seb128: i'm loving that Gray theme... minimalist and slick
<madmax> hey there... i filed a bug about freetype some days ago and nobody even noticed it... i even included a link to the solution (the patch that fixes it in CVS)... is there any more i can do?
<bluefoxicy> should compress be packaged with the standard system?
<bluefoxicy> it looks like it's needed for XSI compliance (SUSv3 streams interface etc), for some weird reason; IIRC it used LZ77 compression, which sucked BUT now is no longer patented ... wasn't that the gif patent?
<bluefoxicy> http://www.unix.org/version3/apis/cu.html is where I'm looking.
<pitti> pochu: you can submit 'reduced reports' without a core dump
<pochu> oh, the second option :)
<pochu> pitti: ty
<pitti> pochu: however, this needs to be redesigned a bit, see bug 87430
<Ubugtu> Malone bug 87430 in apport "do not accept short crash reports for firefox" [Low,In progress]  https://launchpad.net/bugs/87430
<pochu> looking
<pirast> keescook, i can do the asterisk feisty task because i'd like not to have an ancient version in feisty :-)
<pirast> keescook, i am going to get a sync request then..
<keescook> pirast: cool, sure.
<keescook> feel free to update the assignment; I'm doing Dapper while I'm in here.  :)
<pirast> okay, great :)
<pochu> pitti: maybe apport can download the debugsymbols, and retrace it before upload :)
<pitti> no way :/
<pitti> pochu: well, if you have apport-retrace installed, the GUI could offer the possiblity
<pitti> but that's strictly for developers
<pitti> ddebs are huge
<pitti> pochu: bug 75901, btw
<Ubugtu> Malone bug 75901 in apport "Integrate apport-retrace into GUI" [Wishlist,Confirmed]  https://launchpad.net/bugs/75901
<pochu> pitti: when you click on "do not ask again" for an app crash, can that be changed to report it?
<pochu> it seems the reported clicked on that...: "after a few covers it crashes (now even apport does not startup...)."
<pitti> pochu: covers?
<pitti> pochu: you mean, change it to always report crashes for a particular app?
<pitti> that doesn't make too much sense IMHO
<pochu> pitti: when apport pops up, it has the option of "do not pop up again for this application" (or something like this), hasn't it?
<pitti> pochu: right
<pochu> pitti: so my reporter can't see apport anymore, if he pressed that
<doko> Mithrandir: please requeue efibootmgr on i386, amd64, ia64
<pitti> pochu: right, that's what it says
<pochu> pitti: but I need another report, with the coredump, or with a full backtrace
<pitti> pochu: ah, I see
<pitti> pochu: touch /var/crash/* should do the trick
<pitti> pochu: to recover the previous crash dump
<pitti> pochu: alternatively, if it's longer than 7 days ago and the report has been deleted by cron.daily, he can purge the blacklist with rm ~/.apport-ignore.xml
<pitti> or reinstall the affected package (untested)
<pochu> pitti: ok, gonna try
<pochu> ty :)
* Starting logfile irclogs/ubuntu-devel.log
(elmo/#ubuntu-devel) doko: sigh - what is this for?
<asufaskjfaskjf> hello, i have a centrino duo laptop and the volume that comes out of the speakers is too low, even with the system sound at maximum
<asufaskjfaskjf> in herd-5
<asufaskjfaskjf> is this a bug?
<asufaskjfaskjf> using the headphones jack the sound is louder but there is a lot of static
<masuran> Hello everyone. Can anyone tell me if the new Gnome Control Center will be in Feisty? Or will the Preferences and System menu still be there? 
<LaserJock> masuran: they are both there, but I belive Gnome has set Control Center to not be default
<masuran> I saw in Herd 5 that the new control center is in the menu's but it's hidden. Any idea what Ubuntu will do? Default to the new control center? Which is better IMHO :)
<LaserJock> I believe it will be as it whatever Gnome decides, which sounds like it'll be having the control center hidden by default
<masuran> Any idea where I can lobby for the control center? Think it's a shame just following gnome's default. The preferences and system menu are very long and finding an item it them takes to long. 
<LaserJock> well, this channel really isn't the best place to lobby. I suppose the forums, ubuntu-deve-disccus or ubuntu-sounder mailing lists might be the place
<finalbeta> The control center is not standard because it has several bugs yet to be fixed. I'm pretty much quoting sebastian from a previous session. I would be reconsidered later. 
<pochu> I think Control Center will be default in Feisty+1, but it isn't now because it has too much bugs
<pochu> finalbeta: :)
<masuran> Thanks for the info guys :) 
<eXistenZ> What is the bugs filing system for kubuntu?
<Riddell> eXistenZ: launchpad.net
<eXistenZ> Riddell, Is it the same one for Ubuntu?
<Riddell> yes
<Sp4rKy> hi, does someone can explain me why casper only set $LANG variable and not $LANGUAGE ?
<eXistenZ> I cannot seem to find KDE packages among the supported packages.
<Riddell> eXistenZ: use the kde module name
<eXistenZ> Riddell, KDE Module name?
<Mithrandir> keescook: sure, that should be fine.
<keescook> Mithrandir: great, thanks.
<Riddell> eXistenZ: apt-cache showsrc <packagename> will show it
<Mithrandir> doko: given-back.
<eXistenZ> Riddell, What do I need from that information?
<Riddell> eXistenZ: the package
<eXistenZ> Riddell, I'm talking about the bugs list for a specific KDE package.
<doko> Mithrandir: both libscim-hangul and pciutils?
<Mithrandir> doko: you asked for efibootmgr and scim-hangul, not pciutils.
<Mithrandir> but I'll be happy to give back pciutils too
<doko> Mithrandir: no, I needed to upload pciutils, then rebuild efibootmgr ... should stop for today ...
<eXistenZ> Riddell, Where can I search for bugs in Kubuntu KDE specific packages?
<Mithrandir> apart from it being successfully built, that is.
<torkel> eXistenZ: launchpad.net
<eXistenZ> torkel, There is no: https://launchpad.net/ubuntu/+source/akregator/+bugs , for example.
<torkel> eXistenZ: it is built from kdepim
<torkel> eXistenZ: so check https://launchpad.net/ubuntu/+source/kdepim/+bugs
<eXistenZ> torkel, All KDE packages are in kdepim?
<torkel> eXistenZ: no. You have to find out what source package the the binary package was built from and look for that in launchpad.net
<eXistenZ> torkel, Okay, thanks a million!
<eXistenZ> torkel, one source package can make more than one binary package?
<pochu> eXistenZ: sure
<LaserJock> eXistenZ: if you go to launchpad.net/ubuntu/ you can use the package search
<eXistenZ> Thank you so much guys
<Sp4rKy> why casper only set $LANG and not $LANGUAGE ?
<pochu> heno: ^^
<pochu> hey heno :)
<lamont> grumble.  ENOPITTI
<heno> pochu: what, the casper question? I don't know :)
<pochu> heno: do you know how to include a python code in a webpage?
<heno> pochu: not in the same was as you would include php, if that's what you mean
<heno> it doesn't work the same way
<pochu> heno: yes
<keescook> lamont: anything I can help with?
<heno> pochu: I don't think you can do it
<pochu> heno: ok, ty anyway :)
<lamont> keescook: translations backend processing questions.  --> not that pitti hat
<keescook> lamont: heh, yup.  Okay, just wanted to be sure.  :)
<lamont> keescook: np.  I know when to retarget for you in response to missing pitti. :-)
<lamont> today, you're safe.
<keescook> hehe
<lamont> and I'm told pitti probably isn't the best target either.  so I'll hit the right two folks once I see them online
<tepsipakki> what, we still have libxft?
<tepsipakki> the source-package
<j00bar> howdy -- jdong referred me here to ask this question -- i've got a bunch of server breezy installs and i was wondering if there was to be a release of libc6 for breezy that includes tzdata that is post 2006p before breezy is EOL'ed?
<jdong> from what I could tell, timezones in Breezy are not updated for the new DST. Is that correct?
<\sh> does anyone have problems creating a pbuilder or debootstrap chroot? (on feisty)
<zul> nope just did one but I havent updated in a while
<\sh> zul, hmmm..I get the message, that W: http://archive.ubuntu.com/ubuntu/dists/feisty/main/binary-i386/Packages.gz wa
<\sh> s corrupt
<\sh> but I wonder if it's my umts provider or is it just me or debootstrap or a.u.c. apt-get update works 
<lemsx1> \sh: i got the same message today
<zul> it went hunky dory for me
<lemsx1> \sh: eventually it worked... but i'm using the us.a.u.c mirror ...
<\sh> hmm...lemme check with another mirror
<\sh> elmo / Znarl : archive.ubuntu.com looks like broken...de.archive.ubuntu.com works createing debootstrap
<\sh> bah wrong channel ;)
<elmo> \sh: since de.archive.u.c is a mirror of archive.u.c, that seems unlikely
<elmo> \sh: but I'd need some real info, if you actually want me to look at it
<\sh> elmo, what do you need?
<elmo> \sh: what's actually wrong?  'looks like broken' isn't helpful?
<\sh> elmo, .I get the message, that W: http://archive.ubuntu.com/ubuntu/dists/feisty/main/binary-i386/Packages.gz was corrupt
<\sh> (debootstrap message that is)
<elmo> it's not corrupt
<elmo> download the file with wget and tell me what your md5sum is?
<\sh> elmo, kk one moment
<\sh> shermann@LT420:~/test$ md5sum Packages.gz 
<\sh> b25942a121187286e874698ddad3a658  Packages.gz
<\sh> from de.a.u.c it is:
<\sh> http://archive.ubuntu.com/ubuntu/dists/feisty/main/binary-i386/Packages.gz
<\sh> grmp
<\sh> shermann@LT420:~/test/de$ md5sum Packages.gz 
<\sh> 8275515937ec97cf4330490ee25d0fb2  Packages.gz
<\sh> elmo, different sizes, a.u.c.: 1312263 , de.a.u.c: 1311148
<\sh> elmo, thx btw for looking into it :)
<spitty> could someone point me towards the .iso for feisty?
<\sh> spitty, cdimages.ubuntu.com
<spitty> thanks
<\sh> mjg59, t43 with ati mobility radeon m22 (M300 card) does not work with 3d accel with latest 8.33.x and 8.34.x ati native drivers, and it does not work with the drivers in linux-restricted. the M300 card is not even in the list of supported cards anymore.. last driver which is working 8.28.x
<mjg59> \sh: That's why I said r300, not fglrx
<\sh> mjg59, the radeon driver from xorg 7.2 don't have 3d accel, (radeon dri module loaded, and Module "GLcore" loaded as well)
<\sh> s/don't/doesn't/ 
<mjg59> \sh: It should. If it doesn't, please file a bug.
<\sh> mjg59, k :) 
<\sh> mjg59, should I file a bug against linux-kernel, too, just because radeon dri is not loaded automagically, as it was on edgy
<mjg59> ?
<mjg59> Do you mean drm?
<tepsipakki> \sh: you need to purge fglrx before you can get the acceleration
<\sh> mjg59, yepp
<mjg59> \sh: Then no, X will request it
<\sh> tepsipakki, fglrx is long time gone from my system :) clean install this morning :)
<tepsipakki> oke
<tepsipakki> y
<\sh> mjg59, so it's a bug in Xorg, when I have radeon driver in Xorg and no radeon drm loaded...
<snoogie> LaserJock you are here ?
<LaserJock> yeah
<snoogie> Is it possible to speak with you in private ? (in order to don't wrote unuseful stuff here) 
<snoogie> make
<snoogie> oups
<snoogie> :D
<LaserJock> snoogie: see my pm?
<snoogie> yup sorry writting
<snoogie> you see ?
<LaserJock> snoogie: nope, is your nick registered?
<snoogie> ouch
<snoogie> I forget to read that :)
<snoogie> a clue ? 
<snoogie> :D
<snoogie> ok found 
<snoogie> give me a second
<\sh> mjg59, if you are interessted: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/89961 :)
<Ubugtu> Malone bug 89961 in xorg "Xorg 7.2 radeon driver doesn't support ATI Technologies Inc M22 [Radeon Mobility M300] " [Undecided,Unconfirmed]  
<rbrunhuber> I'd like to ask you as the developers if it does make sense to attach a debdiff between a debian package (does work) and an ubuntu package (does not work) to a bugreport.
<LaserJock> seems logical
<rbrunhuber> LaserJock: How can I make this most readable to the developers? The debdiff contains incredible amount of arch things ubuntu does not provide?
<LaserJock> rbrunhuber: like what?
<rbrunhuber> LaserJock: All those exceptions for other architectures not supported in ubuntu like arm
<geser> rbrunhuber: who has the more recent package? Debian or Ubuntu?
<rbrunhuber> LaserJock: Funny enough they are both the same version
<LaserJock> rbrunhuber: what package is this?
<rbrunhuber> LaserJock: kdebluetooth
<rbrunhuber> LaserJock: There must be a difference though. Because I installed kdebluetooth from debian and it overwrites a file that is also in bluez-utils. Which the ubuntu package does not.
<rbrunhuber> LaserJock: But for me (I'm not familiar to debdiff format) finding the difference is like searching the needle in a haystack.
<concept10> Does Launchpad track kernel bugs?  I see some listed but it also says Malone does not track Linux
<rbrunhuber> geser: They are both the same version
<LaserJock> concept10: Launpad tracks kernel bugs in Ubuntu
<concept10> LaserJock, would you happen to know the _specific_ package to report under?  This would be for 2.6.20-9
<geser> concept10: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
<concept10> geser, thanks
<rbrunhuber> LaserJock: Do you have more info for me on the debdiff issue?
<LaserJock> hmm
<concept10> I don't see how you guys track this.  Theres way too many categories
<LaserJock> that debdiff is huge
<LaserJock> concept10: categories?
<rbrunhuber> LaserJock: Oh did you create one yourself for this?
<LaserJock> yeah
<LaserJock> it's like a whole different package
<rbrunhuber> LaserJock: I wondered too. I thought Ubuntu does not repackage, only rebuild things?
<LaserJock> rbrunhuber: no, that's not true
<geser> rbrunhuber: Ubuntu adds patches to packages if needed
<LaserJock> rbrunhuber: anything with an ubuntu in the version 0.99+1.0beta2-1ubuntu4 for instance has been changed by Ubuntu
<rbrunhuber> LaserJock: Sorry, if i was mistaken here
<LaserJock> rbrunhuber: you might ask #kubuntu-devel, especially Riddell or Tonio
<rbrunhuber> LaserJock: I'll try thank you for your help
<jdong> Mithrandir / cjwatson: when's the next time backports will get processed? I have the feeling that unless I'm not persistent in nagging you, it would be sometime off in my next afterlife.
<mjg59> \sh: Turn off xinerama
<\sh> mjg59, I did this morning..no change
<mjg59> \sh: Log with xinerama turned off?
<Mithrandir> jdong: I was looking at some of them today, but had too much other stuff to do.
<\sh> I can change it to "non xinerama" no problem give me a min or two
<Mithrandir> jdong: it would help if you and your team identified whether something should be done as an UVF or a backport a bit more aggressively.
<jdong> Mithrandir: any UVF-like backports I approve is because after talking in -motu it does not appear like anyone will do a SRU.
<jdong> (or a SRU is not feasible)
<jdong> this system of everything preempting backports is simply not working out for me... I understand you guys are very very busy, but there has to be a more efficient solution.
<\sh> mjg59, rebooting :)
<tepsipakki> Mithrandir: are you maintaining casper?
<Mithrandir> jdong: whether somebody wants to do an SRU or not is not really something I take into consideration; I'm not going to let a backport through where an SRU is the right way to fix the problem.
<Mithrandir> tepsipakki: I wrote a fair bit of the current version at least.
<Mithrandir> jdong: however, do you have any suggestions on how to fix the problem?
<jdong> Mithrandir: ok, if that is your policy, that is fine with me, I will reject bugfix backports in the future citing that policy.
<tepsipakki> Mithrandir: there seems to be something wrong with the livecd's and X. There are a number of bugs where it doesn't get a correct resolution or driver, but a dpkg-reconfigure xserver-xorg (on an installed system) makes it right
<jdong> Mithrandir: as far as fixes, it would be nice if a backports team administrator can directly effect backports thru launchpad... but I bet that would not fly with TB as well now as it once did.
<Mithrandir> jdong: as I've written in a few bug reports now, "backports are for shiny new features, SRUs are for bugfixes".  Examples such as dosemu-freedos are exceptions to that rule, though.
<\sh> re
<jdong> Mithrandir: ok, that is fine, I will operate by that policy from now on.
<\sh> mjg59, hmmm....
<jdong> and Mithrandir, you realize that it simply means people will start finding random "features" and dodging the requirement that way, right?
<Mithrandir> jdong: thanks.  Maybe we should investigate some way you can pass off bugs you think should be fixed in an SRU so they don't just get lost?
<jdong> Mithrandir: that would be great too
<mjg59> \sh: ?
<jdong> Mithrandir: I've followed up on some bugs in Dapper's timeframe I've deferred to Ubuntu, and most of the case nothing has happened.
<Mithrandir> jdong: therefore "shiny".  I'd like people to follow policies not because "policy says so", but because the policy makes sense.  It should be (relativetly) easy to do the right thing.
<jdong> Mithrandir: it makes me feel really bad because I know when I say defer to SRU, the fix will never happen.
<\sh> mjg59, now it works half the way...I can scale (window picker) but the emerald theme manager doesn't show me any themes...this morning I couldn't get it running even without xinerama
<Mithrandir> jdong: hm, so we need to fix that somehow.
<mjg59> \sh: Beryl bugs go to beryl people right now
<\sh> mjg59, yeah
<mjg59> REJECTED, NOTABUG :)
<jdong> \sh: you have ARGBGLXVISUALS?
<Mithrandir> tepsipakki: might be that it breaks when run under usplash?  Can you ask a couple of the people to see if it works if they remove "splash" from the command line?
<tepsipakki> Mithrandir: I might
<ajmitch> Mithrandir: I think that's more a case of finding people willing to do the SRU & spend the time on it
<\sh> jdong, nope I have xgl/aixgl noob mode 
<jdong> \sh: add to screen section of xorg.conf:
<Mithrandir> ajmitch: and making at least the universe SRU process simple enough that fixes don't get bogged down.
<jdong> Option         "AddARGBGLXVisuals" "True"
<jdong> Option         "DisableGLXRootClipping" "True" 
<jdong> \sh: ^^
<Mithrandir> tepsipakki: if you could, that'd be great.
<jdong> \sh: that should resolve most of your emerald glitching
<tepsipakki> Mithrandir: but on bug #31830 someone said that casper-bottom/20xconfig "calls dpkg-reconfigure in a chroot but it only mounts /proc and /sys"
<Ubugtu> Malone bug 31830 in casper "Incorrect screen resolution in Dapper LiveCD" [Medium,Confirmed]  https://launchpad.net/bugs/31830
<ajmitch> Mithrandir: it seems that we get a lot of stuff stuck in -proposed, needing testing
<jdong> \sh: btw, beryl 0.1.99* has been quite glitchy for everyone; is compiz behaving any better for you?
<tepsipakki> Mithrandir: and ddcprobe seems to need /dev/mem
<Mithrandir> tepsipakki: I could make it bind-mount /dev as well, sure.
<tepsipakki> I'll try with herd5 myself, since that's something I've not done in a loong time
<\sh> jdong, this option "true or false"?
<Mithrandir> ajmitch: since universe shouldn't contain stuff which is critical to your computer functioning, maybe we should make the policy what it was before the X breakage and not use -proposed.
<Mithrandir> (for universe)
<jdong> \sh: yeah, both are True
<\sh> ok moment
<Mithrandir> ajmitch: I'm not saying this is the right solution, but maybe that's an option we need to evaluate.  I'm a strong believer of "make doing the right thing the easiest" as a way of guiding people.
<jdong> Mithrandir: one example is bug 42269... a trivial fix has been available and in "testing mode" for 20 days short of a year.
<Ubugtu> Malone bug 42269 in azureus "[SRU]  Does not create a tray icon" [Undecided,Fix committed]  https://launchpad.net/bugs/42269
<ajmitch> I'd really like to see these fixes get into universe rather that sitting & rotting
<jdong> Mithrandir: this is kind of typical behavior for Universe SRU's....
<jdong> heck it's lucky enough it got an edgy-propose upload 10 months later.
<jdong> usually that stage never happens
<Mithrandir> jdong: indeed, and I think we should fix the problem there rather than work around it "because -backports are easier to do".  Make it just as easy to fixes in -updates instead.
<jdong> Mithrandir: yeah, agreed, making the -updates procedure easier on developers would be the ideal solution.
<jdong> Mithrandir: in the words of one developer, "I'd rather fix a Feisty bug than spend 2 months on a SRU"....
<jdong> Mithrandir: that kind of attitude towards fixing released bugs is... concerning... to hear
<Mithrandir> jdong: agreed.
<Mithrandir> jdong: I'm trying to think which bit of our council/board machinery would be appropriate to discuss this problem.  Maybe just revive the discussion about how universe SRUs should be handled, on -devel.
<LaserJock> jdong: I think everybody is agreed on that
<LaserJock> Mithrandir: we are adding it to the agenda of the MOTU Meeting this week
<jdong> LaserJock: I'd just like to see something move forward regarding this :)
<Mithrandir> that's in about 21 hours' time.  I believe it can wait until then?
<jdong> I support rigorous QA to prevent update breakage mishaps, but the profound prohibitive effect it has had on getting updates out needs addressing :)
<LaserJock> jdong: so would everybody else. I just feel like complaining without participating in the discussion/work is not so helpful
<jdong> Mithrandir: lol, yeah, it can wait that long :D
<jdong> LaserJock: I don't mean just to complain about it....
<Mithrandir> LaserJock: the agenda for that meeting looks kinda empty?
<LaserJock> Mithrandir: that'll get fixed in a minute ;-)
<ajmitch> Mithrandir: oh, another f-spot bugfix release came out this morning, you want the information in a bug?
<Mithrandir> LaserJock: great.
<Mithrandir> ajmitch: yes, please.
<jdong> Mithrandir: do you think -archive can provide consistent/timely processing of Backports, or should that go on some agenda for a TB meeting too?
<jdong> the original TB meeting regarding Backports had us under the impression that Backports team administrators would have the authority to do backports....
<jdong> initially when -archive had <1.5wk turnaround time, it worked really well this way
<jdong> but as this time drags on, I more and more wish for the permission to directly effect backports
<Mithrandir> hmm
<Mithrandir> I'll discuss it with the rest of the archive team and see if we can do something to make it happen faster?
<jdong> Mithrandir: that sounds good
<jdong> Mithrandir: thanks so much for your time on this :)
<Mithrandir> jdong: I'm hoping we can get this fixed to everybody's satisfaction.
<superted> does herd 5 include Kbabel ?
<mjg59> superted: What do you mean by include?
<Lure> superted: it is in main repo, but not on desktop CD
<superted1> sorry
<LaserJock> Mithrandir: https://wiki.ubuntu.com/MOTU/Meetings if you have anything you'd like to change/add
<jdong> I think it's "inKlude", too
<delire> will the Composite extension be enabled by default in Feisty? i see that it breaks direct rendering with cards using the non-free fglrx driver.
<delire> eg for a large proportion of recent laptops.
<pochu> delire: no, it will be installed by default, though it won't be enabled by default
<delire> cool, this is wise.
#ubuntu-devel 2007-03-06
<tkamppeter_> Mithrandir, cjwatson, thanks for the help on the cupsys package, I have put up an improved version on my web space now, biff
<nrdb> I just heard that "update-modules" is depreciated, to reduce confusion, couldn't it be make a link or script that just runs depmod ? maybe with a message to use depmod instead.
<sladen> nrdb: asdf
<pitti> Good morning
<ajmitch> hi pitti 
<fabbione> so who is our compiz expert? :)
<mneptok> fabbione: sudo aptitude remove ...
<fabbione> mneptok: it's part of ubuntu-desktop now
* ajmitch wonders if anyone will own up to being a 'compiz expert'
<fabbione> well it starts and it works somehow
<fabbione> but i get no win decorations
<fabbione> like the manager is not there
<mneptok> please god let that not be in Main
<ajmitch> mneptok: even better, it's on the cd
<mneptok> i know.
<fabbione> Filename: pool/main/c/compiz/compiz_0.3.6-1ubuntu7_all.deb
<fabbione> mneptok: sorry :)
<mneptok> no reason to apologize.
<mneptok> if it's not removed from supported packages i'll just quit.
<Hobbsee> mneptok: "you poor bastard"
<fabbione> mneptok: people *NEED* bling
<fabbione> mneptok: my son just made some strange noises when you started writing on IRC
* fabbione lets him play with a USB snd card
<mneptok> hehehhe
<mneptok> he can detect the presence of an intellectual peer.
<fabbione> mneptok: you bet  :)
<Hobbsee> Mithrandir: finally some sense!
<Hobbsee> jdong: you misquoted.  :P
<jdong> Hobbsee: effin close enough
<jdong> got the point across :)
<Hobbsee> "i'd rather spend 5 minutes fixing a bug in feisty than two months fixing a bug in edgy"
<Hobbsee> but yeah :)
<jdong> :)
<Hobbsee> you got it close enough that i recognised it :P
<jdong> so I made it sound less severe :D
<jdong> but the general gist is concerning nonehteless ;-)
<Hobbsee> true
<Hobbsee> in my opinion, stable releases are pretty much dead releases - no changing them :P
* Hobbsee wonders how many devs now have that mindset
<jdong> Hobbsee: I think it is true in practice but should not be that way :(
<dholbach> good morning
<_ion> ditto
<dholbach> hi _ion
<pitti> dholbach: yay, gthumb photo import mystery solved
<dholbach> pitti: what was it?
<pitti> dholbach: see bug 78756
<Ubugtu> Malone bug 78756 in libgphoto2 "photo import does not work any more" [High,In progress]  https://launchpad.net/bugs/78756
* pitti hugs the community
<dholbach> URG
<dholbach> that wasn't really obvious
<ajmitch> hm
* ajmitch should have known that
<ajmitch> since f-spot uses the same libs for importing
<pitti> ajmitch: so it has the same problem?
<ajmitch> no, I added libusb-dev to f-spot's build-deps :)
<dholbach> pfffft :)
<ajmitch> must have been awhile ago
<dholbach> yay for photo import
<dholbach> now if inserting my SD card doesn't crash the kernel anymore, I'll be real happy :)
<pitti> carlos: hi
<pitti> carlos: how are the imports?
<carlos> we are still handling entries imported at the end of January...
<carlos> danilo is profiling the process to see what's going on 
<carlos> because it's being slow
<pitti> doko: your rebuild-o-mania is finished now or shall I still wait with the Maintainer: stuff?
<cjwatson> gpocentek,pitti: thunar-volman-plugin reprocessed now, thanks to cprov for fixing the code
<cjwatson> should be in the archive shortly
<cjwatson> StevenK: remaining cyrus-imapd-2.2 binaries should similarly be in the archive shortly
<StevenK> cjwatson: Right, thanks very much.
<Sp4rKy> please, must i update_initramfs when i change the casper scripts ?
<lifeless> yes
<Sp4rKy> ok
<gpocentek> cjwatson, cprov-afk: thanks
<seb128> Mithrandir: hi, could you give a retry to compiz-extra build?
<Mithrandir> seb128: given-back
<seb128> Mithrandir: thank you
<ogra> cjwatson, i cant get console-setup to work on thin clients ... both init scripts are run, the configuration is correct (done with dpkg-reconfigure) but i dont get the right font or keymap on the console ... any tips ?
<ogra> it works if i log in and run the initscript manually 
<ogra> but not through init it seems
<seb128> Mithrandir: compiz upstream is working on a 0.4 bug fixing version, gandalfn who works on the Ubuntu compiz made a pre-version package with a no-tfp patch which makes it work with fglrx for example, what do you think about updating? 
<cjwatson> ogra: update-initramfs might fix it
<cjwatson> ogra: (setupcon has to run before usplash starts)
<seb128> Mithrandir: do you want an UVF request for it?
<ogra> well, i see it getting set 
<ogra> but its gone after usplash
<ogra> directly after: Loading please wait ... the font switches ... then usplash kicks in
<cjwatson> ok, I'm not sure then, sorry
<ogra> hmm
<ogra> does it need any writeable tings i have to aded to the tmpfs mounted files ?
<ogra> *things
<ogra> *add
<ogra> (does it rewrite anything ?)
* ogra looks up what setupcon --save does
<cjwatson> it's not meant to
<cjwatson> setupcon --save will, but that's not run during the boot sequence
<cjwatson> it does need to write to /etc/ while console-setup is being configured, of course
<cjwatson> if you're seeing a font change during the initramfs, though, it's probably not thatt
<cjwatson> almost sounds like it's changing the font back after usplash
<ogra> yeah
<cjwatson> compare /etc/default/console-setup and the various files in /etc/console-setup/ in and out of the initramfs, I guess
<ogra> yup, wiul do
<ogra> *will
<cjwatson> I guess I should upload the console-setup work in progress I have - it doesn't really fix the problem I was trying to fix but it would make it easier to get somewhere with it
<poningru> can someone help with a bug report?
<poningru> https://bugs.launchpad.net/gnome-applets
<poningru> http://bugzilla.gnome.org/show_bug.cgi?id=415242
<Ubugtu> Gnome bug 415242 in gweather "Hazardous weather alerts" [Enhancement,Unconfirmed]  
<poningru> want to file that bug in lp
<dholbach> poningru: why?
<poningru> dholbach: I shouldnt?... I was thinking just to keep a bug in lp.net as well
<ogra> cjwatson, hmm, booting without splash fixes it ... 
<dholbach> I didn't say you shouldn't. I just asked wanted to know if there's a special reason
<ogra> its not changing back
<poningru> dholbach: just because... /me likes lp.net > bgo
<dholbach> poningru: well - there are 412k upstream bugs - we usually link bugs that 1) were reported in LP and then forwarded upstream or 2) were filed upstream and are really important to track for us
<poningru> eek ok
<dholbach> poningru: as it's "just" an enhancement bug, I personally wouldn't file it in LP - but you're free to do it of course
<dholbach> poningru: http://launchpad.net/ubuntu/+source/gnome-applets/+filebug would be the appropriate URL
<poningru> meh I will just work with the gnome people
<poningru> thanks
<dholbach> poningru: Why that?
<poningru> http://bugzilla.gnome.org/attachment.cgi?id=84045&action=view btw
<poningru> why what? just work with the gnome people?
<dholbach> poningru: yes
<poningru> I mean if they accept the code upstream it will trickle down to ubuntu so might as well contribute to gnome in general
<giftnudel> I need a german translator for bug 60527, please
<Ubugtu> Malone bug 60527 in language-pack-gnome-de "xchat-gnome /me misbehaviour" [Undecided,Confirmed]  https://launchpad.net/bugs/60527
<dholbach> poningru: Yeah, it will - I just wasn't sure if you felt 'turned down' by my answer - I like the idea the bug suggests and appreciate work going on there, it's just that it doesn't make sense to track every upstream bug in LP -- if you want to have it in LP, I won't stop you though :)
<poningru> hehe naah didnt feel turned down or anything
<poningru> you just made sense
* poningru shakes fist at dholbach
<cjwatson> ogra: right, could well be the same thing I was trying to attack following a Turkish user's report; not finished yet
<poningru> how dare you make sense
<dholbach> poningru: I'll try to avoid it from now on ;-)
<cjwatson> Kagou: do you have a reference (URL) to the list/blog/etc. discussion about fr-oss?
<poningru> dholbach: good cause we have too much of that around here ;)
<crimsun> mjg59: macbook/pro stuff pushed
<Kagou> cjwatson: yes but in french ;)
<Kagou> cjwatson: http://www.kagou.fr/post/2007/02/21/Clavier-sous-Ubuntu
<Kagou> cjwatson: and https://lists.ubuntu.com/archives/ubuntu-fr-l10n/2007-February/001114.html
<pitti> Mithrandir, seb128: could one of you please NEW restricted-manager? I don't want to approve my own pacakge
<pitti> Mithrandir, seb128: doesn't need to happen immediately, but would be nice in the next two days or so
<cjwatson> Kagou: ok, thanks; I'll take care of it
<_ion> What is restricted-manager, btw?
<Kagou> cjwatson: feel free to ask me more informations. I will try to answer you. Thanks
<Mirv> _ion: I can guess it has something to do with easier selection of what non-free drivers or perhaps codecs to use/install
<Mirv> _ion: https://launchpad.net/restricted-manager/
<Mirv> just the restricted-component's drivers, that is
<pitti> right
<_ion> Ok. I take it it allows you e.g. to install and configure the proprietary nvidia/ati driver for use with xorg easily?
<pitti> right
<Mirv> pitti: just tested it, looks great. is "disable all" in plans, and would it basically give you a clean (as in freedom :) ) installation as far as main(+universe) in ubuntu is clean? currently I've restricted disabled on my desktop computer.
<_ion> Nice
<pitti> Mithrandir: if you don't have lrm installed, it should not list anything
<pitti> erm, Mirv ^
<pitti> Mithrandir: sorry, wrong nick completion
<Mirv> pitti: yes, but on my laptop, and on any default installation? ie. is it somewhat similar to disable all there than what is it to disable the restricted component. does disabling everything there mean none of the restricted packages contents are used?
<pitti> Mirv: yes, if you untick 'Allow' for everything, none will be used
<pitti> however, they are still lurking on your disk, which might still be regarded as infestation :)
<_ion> Someone who cares about that probably knows enough to purge the lrm package etc. :-)
<Mirv> pitti: ok, just checking. but anyway, the tool looks great, and is educating the user in a right (and needed) manner.
<Mirv> _ion: yes, indeed :)
<Mirv> I do know this is not the really correct way to go :) - http://users.tkk.fi/~tajyrink/nouveau/
<pitti> Mirv: why, what's wrong with nouveau?
<Mirv> pitti: I mean, the message on the page
<pitti> ah, heh :)
<pitti> just opened it
<pitti> sudo modprobe kitt ;)
<_ion> /usr/bin/restricted-manager:44: DeprecationWarning: the module egg.trayicon is deprecated; equivalent functionality can now be found in pygtk 2.10
<_ion> pitti: There's an "image not found" icon instead of the restricted-manager tray icon. I'm using the tangerine icon theme.
<pitti> _ion: right, I know
<pitti> _ion: do you use the current bzr head or where do you have the package from?
<_ion> Yeah, bzr.
<pitti> _ion: if you are interested in helping out with fixing some things or developing this further, I'd be really glad
<doko> pitti: you're dreaming ;-) still 100, which I will do tomorrow and Thursday (ronne:~doko/libscan)
<pitti> doko: alright
<Mithrandir> seb128: new compiz> UVF request would be good.
<seb128> Mithrandir: ok
<Mithrandir> pitti: restricted-manager> I'll get to it, if seb doesn't beat me to it.
<seb128> pitti: I'm busy with other things atm, feel free
<pitti> seb128: ?
<seb128> pitti: that was for Mithrandir
* ogra kicks gnome_sound_play() in the guts ...
<pitti> ogra: please kick hard enough to make esound fall out
<ogra> heh, i'D love to
<ogra> i wonder how it defines a smaple size ... i cant get the login/logound sound to play on ltsp ... 
<mjg59> crimsun: Thanks!
<ogra> esdplay and a click in the gui after login play them fine ... but on login pulse moans on the client "sample too large"
<seb128> ogra: there is a new esound version to package, want to do the update?
<ogra> not really
<ogra> but if you need a hand i'll do it indeed
<ogra> since i'm into pulse anyway
* ogra recompiles pulse with a higher samplesize value for esd emu ...
<Mithrandir> pitti,seb128: did either of you source NEW compiz-extra and if so, why is it in main?
<Mithrandir> I can't see an inclusion report for it
<pitti> hm, can't remember NEWing it
<pitti> but it's entirely possible that I did
<seb128> Mithrandir: that was me and that looks like a mistake
<seb128> sorry about that
<Mithrandir> seb128: ok, thanks.  Just wondering.
<asac> dholbach: if you have time, can you please look at http://pastebin.mozilla.org/4501 and tell me if the comment in line 19 is still valid?
<asac> oh
<asac> seb128: totem was yours, right? 
<Mithrandir> pitti: r-m accepted.
<bhale> seb128: you pinged?
<pitti> Mithrandir: cheers
<seb128> asac: yep
<asac> can you look then?
<asac> http://pastebin.mozilla.org/4501
<asac> line 19
<asac> NPPVpluginKeepLibraryInMemory is broken in mozilla :/ and contributes to lots of crashers we have
<pitti> erk, why we still have tk8.3 in main?
<StevenK> pitti: blt
<Mithrandir> pitti: build-depends for blt.
<pitti> erk, the binary has an |'ed dep to 8.4 | 8.3
<StevenK> And BLT is just an extension library for TK, so why is it in main? :-)
<pitti> StevenK: python-tk and python2.5-dbg rdepends
<asac> seb128: afaik totem is run in a separate process ... so the question is if GObject is used at all by totem plugin in mozilla process.
<StevenK> Ah
* pitti wonders whether we can build blt with 8.4 only
<seb128> asac: I'm not sure, I don't really know a lot about the plugin, if you want to join #epiphany on irc.gnome.org chpe is upstream for epiphany and working on the totem plugin, he probably knows about that better
<Mithrandir> and python2.[45] -dbg depends on blt.
<asac> seb128: good
<pitti> Mithrandir: right, but as I said, binary deps are not an issue, they are alternatives
<pitti> doko: do you happen to know about blt? (You NMUed it in the past); can we easily drop the tk8.3 build dep?
<doko> pitti: I used it for python-tk only, not using tk8.3 at all.
<pitti> doko: it seems easy to do at first sight
<doko> pitti: but we will have tcl8.3 still there (expect-tcl8.3 needs it on hppa)
<pitti> argh
<pitti> and we can't get rid of that?
<pitti> hppa isn't even built any more
<doko> probably not for feisty, but glibc starts looking better on hppa now
<pitti> doko: hm, binutils and gcc-* depen on expect-tcl8.3 on all arches
<pitti> so we could at least get rid of tk8.3
<doko> pitti: yes, we can change that if you want
<pitti> well, I don't want to start a new wave of significant work, it just looked like an easy target
<mooey> bug 90093 is a duplicate of a bug somebody (seb128 i think) fixed recently, but i can't find the original report to mark it a duplicate of
<Ubugtu> Malone bug 90093 in libxcb "GTK apps crashing via drag and drop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90093
<seb128> mooey: it has not been fixed
<seb128> mooey: bug #88608
<Ubugtu> Malone bug 88608 in gtk+2.0 "[apport]  xchat crashed with SIGABRT in xcb_xlib_lock" [High,Confirmed]  https://launchpad.net/bugs/88608
<mooey> thats the one, thanks seb128 
<seb128> mooey: np
<seb128> mooey: do you mark it dup now?
<mooey> seb128, done
<seb128> cool
<doko> Mithrandir: could you reject my upload to dapper-backlports? wrong archive :-/
<Mithrandir> doko: which upload?
<doko> Mithrandir: java-gcj-compat
<doko> ohh, it already was auto-rejected
<Mithrandir> doko: ah, ok, good.  I got worried since I couldn't find it.
<pitti> doko: is there a 'set -x' equivalent for Python?
<Mithrandir> pitti: is it ok to promote thunar-volman-plugin now?  The binaries have been recovered.
<pitti> Mithrandir: yes, it is
<pitti> Mithrandir: I'll move the MIR to 'promoted' then
<Mithrandir> pitti: I'll do it.
<pitti> ah, you locked already
<gpocentek> Mithrandir: thanks
<pitti> seb128: did you happen to permanently install some packages into the retracer chroots? a lot of files are seb128:warthogs 755, so I cannot change them
<seb128> pitti: no, I just used retrace-i386
<seb128> pitti: I did ctrl-C one run though
<pitti> seb128: ok, thanks; then there's another place that clobbers the umask
<seb128> pitti: do you want me to fix those files?
<pitti> seb128: well, either that (chmod -R g+w) or I just trash the entire chroot and rebuild it
<pitti> seb128: I just don't understand why the files are there in the first place -- these packages are supposed to be unpacked and purged afterwards
<seb128> pitti: as said before " pitti: I did ctrl-C one run though"
<pitti> aah
<pitti> this explains it
<pitti> sorry, didn't see that
<seb128> np
<mooey> pitti, was the patch attached to bug ever uploaded (i dont know how to check)? i got the same bug when updating asterisk this morning
<pitti> maybe I should just switch to tarballs and unpack them; shouldn't take too long
<mooey> erk, bug 55374 * 
<Ubugtu> Malone bug 55374 in asterisk "upgrade issue with configured asterisk" [Undecided,Fix released]  https://launchpad.net/bugs/55374
<seb128> sould I just clean apport-retracer-i386/chroots/feisty/var/cache/apt/archives ?
<pitti> mooey: I don't know, I didn't touch asterisk
<pitti> seb128: no, please just chmod -R g+w the entire chroot
<mooey> pitti, the last comment was by yourself. thanks anyway.
<pitti> mooey: oh, I see; let me look; but as I said, I never uploaded asterisk
<seb128> pitti: done
<pitti> seb128: cheers
<pitti> mooey: no, it wasn't uploaded; complain to Fujitsu about wrongly closing the bug
<pitti> mooey: please reopen again
<mooey> pitti, will do, thanks
<jdong> pitti: it would be great if restricted-manager can AddARGBGLXVisuals too for nvidia cards
<jdong> (non-legacy, that is)
<pitti> seb128: I know the reason for the 404's during retracing -- I need to setup a cronjob that apt-get update/dist-upgrades the chroots daily
<jdong> otherwise 3D effects would not work out of the box.
<seb128> pitti: ah ok
<jdong> pitti: it's just 'Option "AddARGBFlxVisuals" "True"' in the Screen section of xorg.conf
<pitti> jdong: indeed; ubuntu-bug -p restricted-manager ?
<jdong> okie :)
<pitti> seb128: ok, chroot cleaned from the ^Ced run
<jdong> pitti: that is sweet, I didn't know ubuntu-bug existed :D
<seb128> pitti: cool, sorry again for the extra work
<pitti> seb128: no problem
<pitti> seb128: 'k, chroot update cronjobs set up
* seb128 hugs pitti
<pitti> seb128: voila, bug 88508 retraces nicely now; unfortunately I didn't save the output
<Ubugtu> Malone bug 88508 in gnome-utils "System Log Viewer copies the wrong line when filter is applied (dup-of: 47134)" [Low,Rejected]  https://launchpad.net/bugs/88508
<Ubugtu> Malone bug 47134 in gnome-utils "log text copy fails while filter engages" [Medium,Confirmed]  https://launchpad.net/bugs/47134
<pitti> seb128: erm, sorry, bug 88058
<Ubugtu> Malone bug 88058 in rhythmbox "[apport]  rhythmbox crash in metadata_cb" [Medium,Confirmed]  https://launchpad.net/bugs/88058
<seb128> pitti: no need, I retrace it on my desktop this morning ;)
<gnomefreak> pitti: via bug 89916 the -u stops the 2 errors/warnings from apport but i get a non useful Stack. im gonna try in chroot after i update it and report back on bug. Thank you :)
<Ubugtu> Malone bug 89916 in apport "[Feisty] apport-retrace fails to retrace bugs." [Low,In progress]  https://launchpad.net/bugs/89916
<pitti> seb128: I think I leave the exception as it is then, since it indicates problems better than just a warning
<seb128> pitti: do you know what lib or program prints the "** (gnome-cups-add:18745): WARNING **: IPP request failed with status 1028"?
<seb128> pitti: ok
<pitti> seb128: gnome-cups-icon, I'd say
<seb128> pitti: no, I'm trying to add a printer with gnome-cups-manager and it doesn't work, I'm trying to figure on what to put a breakpoint
<seb128> I would like to have a look on the URI it gives to cups
<seb128> looks like libgnomecups
<pitti> gnomefreak: hm, useless stackis usually (a) missing ddeb packages (check the warnings), or (b) outdated package versions (also check the warnings)
<gnomefreak> pitti: im going to, but for some reason they were working fine for a while than they stopped working so i will fiddle around with it until i can come up with something useful. 
<pitti> gnomefreak: right, as I said, feisty's package versions might be newer now, so that the libs don't match any more
<gnomefreak> yeah i agree with that but it also seems im missing .so files (assuming they are the  -dev packages as normal)
<pitti> the .so files in -dev are usually just symlinks
<gnomefreak> s/are the/ are in the
<gnomefreak> ah
<Mithrandir> Riddell: re digikam> is upstream aware that jpeg 2k is patent encumbered and therefore problematic?
<Riddell> Mithrandir: I expect not
<Riddell> Mithrandir: but libjasper is already in main and depended upon by various things
<Mithrandir> Riddell: ugh.
<Mithrandir> pitti: ^^ ; any thoughts about this?
<pitti> Mithrandir: off the top of my head just 'OMG'
<pitti> Mithrandir: the question is whether it's an enforced patent or not, really
<Mithrandir> pitti: that's a good initial thought. :-)
<pitti> Riddell: is it on the Kubuntu CDs?
<doko> heno, dholbach: were the impress template documents updated for feisty?
<Mithrandir> pitti: it's on both kubuntu and ubuntu cds, it seems.
<Mithrandir> http://en.wikipedia.org/wiki/JPEG2000 has a section about the legal issues.
<Riddell> pitti: libmagick and kdelibs seem to rdepend on it so yes
<dholbach> doko: no
<heno> doko: no, do they need to be?
<doko> heno, dholbach: no, just asking before an OOo upload
<heno> ok
<Sp4rKy> some gfxboot specialit here ?
<Sp4rKy> i don't understand how change the font color in the menu 
<cjwatson> Sp4rKy: GFXBOOT-BACKGROUND keyword in isolinux.cfg (and GFXBOOT-FOREGROUND for the highlighted text colour)
<Mithrandir> Riddell: libjasper-support is possible to turn off?  If so, I don't see a problem with keeping it for now and we'll have to work out the legal implications a bit later (since we're already shipping it..)
<Sp4rKy> cjwatson: ohhh, great !
<cjwatson> Sp4rKy: e.g. 'GFXBOOT-BACKGROUND 0xB6875A' for Ubuntu
<Riddell> Mithrandir: sure, it's just a compile time option
<Sp4rKy> i'd seen that but i didn't think it is whati'm looking for :)
<Mithrandir> Riddell: ok, thanks
<cjwatson> the naming's not the best, sorry about that
<doko> Mithrandir, pitti, seb128: I will uploads ooo-l10n first, which will land in binary NEW (please keep it there), then upload ooo, which will land in binary NEW (please keep it there until i386, amd64 and powerpc are built)
<pitti> doko: ack
<cjwatson> mvo: I fixed up the dist-upgrader-all stuff by hand (e.g. the current symlink); it'll be in the next archive push
<cjwatson> 12:04 <cjwatson> the lack of a current symlink is because the versioning changed - he used an epoch
<cjwatson> 12:04 <cjwatson> but the epoch isn't in the directory name because that breaks stuff
<cjwatson> 12:04 <cjwatson> so the sorting code in dist_upgrader.py doesn't know where to put the current symlink
<cjwatson> 12:05 <cjwatson> TBH I'd be inclined to just remove the dist-upgrader directories that used the old versioning scheme, do a one-time fix of the current symlink, and then it'll work fine from then on
<cjwatson> so I did that
<mvo> cjwatson: I suspected that the versioning change caused the trouble. thanks a lot for resolving it!
<bddebian> Heya
<Sp4rKy> heya bddebian 
<bddebian> Hi Sp4rKy
<Sp4rKy> so, i've a last issue with casper. in the 14locales file, when i do 
<Sp4rKy> chroot /root /usr/bin/touch foo
<Sp4rKy> the file foo is created
<Sp4rKy> but if i do 
<Sp4rKy> chroot /root /bin/echo "abcd" > foo
<Sp4rKy> nothing is printed in the file foo
<Sp4rKy> is there some special syntax ?
<lemsx1> Sp4rKy: redirecting output happens at the terminal
<lemsx1> Sp4rKy: try: chroot /root "echo 'hello' > foo "
<lemsx1> brb
<cjwatson> or chroot /root /bin/echo "abcd" > /root/foo
<doko> Mithrandir: could you move the openoffice.org-l10n build to palmer, if I upload it?
<cjwatson> Riddell: there are a bunch of bugs being filed on debconf which seem to be crashes in the KDE frontend - libqt-perl or libsmokeqt1
<cjwatson> Riddell: I've been reassigning them to libqt-perl so far
<Riddell> cjwatson: mm, ok
<dholbach> ogra: new dia
<_ion> https://code.launchpad.net/~ion/+branch/restricted-manager/ion in case anyone's interested.
<dholbach> gpocentek: new gnumeric/goffice :)
<siretart> is http://people.ubuntu.com/~pitti/ddebs/ still the source of choice for ddebs?
<dholbach> siretart: yes
<iwj> Dammit, now we've lost Rodrigo there's even less chance that anyone will be able to fix bug 68440 for me.
<Ubugtu> Malone bug 68440 in xorg "X does not work in Xen, causes crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68440
<siretart> dholbach: too bad that it doesn't contain ddebs 'old' / superseeded packages :(
<dholbach> siretart: it's (n+1)G big already
<dholbach> but yeah, it'd be nice to have - or to have them auto-retraced - where works are underway
<seb128> siretart: https://beta.launchpad.net/ubuntu/+source/apport/+bug/90135 doesn't look like a bug
<Ubugtu> Malone bug 90135 in apport "unusable backtraces for xine-lib" [Undecided,Unconfirmed]  
<seb128> siretart: did you install a libxine-extracodecs debug package and retraced on edgy with totem-xine installed?
<seb128> siretart: 
<seb128> #0  0xb16a41b5 in ifilter_bank () from /usr/lib/xine/plugins/1.1.2/xineplug_decode_faad.so
<seb128> No symbol table info available.
<seb128> #1  0x000003ff in ?? ()
<seb128> 
<seb128> that's retracing without the debug package for libxine-extracodecs
<siretart> seb128: I think that the xine packaging is just borked, I'd rather like to know how to fix it
<siretart> seb128: hm. let's try that in a edgy chroot
<seb128> siretart: how borked?
<seb128> siretart: non debug packages are useless you mean?
<seb128> I pinged you about that some months ago IIRC
<siretart> oh, so much time? damn :(
<siretart> seb128: do you think it would help if we stop generating the -dbg package?
<siretart> oh. some other point: retracing i386 crashes on  amd64 doesn't seem to be a too bright idea, no?
<seb128> no it's not
<seb128> you need to retrace on the same arch with the same package versions
<seb128> if you try on an another arch gdb should complain about the dump format
<siretart> hm. apport should at least warn on that
<siretart> at least, it would be nice
<seb128> apport feisty got a lot of love, it probably does already ;)
<siretart> this was on feisty :/
<seb128> open a wishlist then, pitti is amazingly fast to fix bugs ;)
<dholbach> heno: do you know why a wiki change mail (DebuggingMemoryLeaks) was sent to ubuntu-bugsquad@lists.ubuntu.com?
<heno> dholbach: no, was it meant to go elsewhere? Has someone signed up as a wiki user with that email and subscribed to the page?
<heno> I guess you've noticed that I'm refactoring a bunch of pages :)
<dholbach> heno: yes I did :-))))
<dholbach> heno: no idea about why the list got that mail - I'll reject it from the queue
<heno> as you seem to have subscribed to the entire wiki ...
<doko> cjwatson, fabbione: the sched_setaffinity stuff seems to work on sparc, currenly no ildc hang on faure with the smp kernel
<cjwatson> doko: neat
<iwj> tepsipakki: Ah, nice to see you taking an interest in my Xen X bug, thanks.  Indeed, the logs are very similar.  ISTR someone speculating about memory layout.
<alex-weej> trying to troubleshoot this bug
<alex-weej> 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-5 doesn't boot with sata-hd" [Medium,Confirmed]  
<alex-weej> what's the safest way for me to test a vanilla kernel in ubuntu
<alex-weej> rather than installing fedora, like Martin suggested
<seb128> siretart: http://bugzilla.gnome.org/show_bug.cgi?id=415326
<Ubugtu> Gnome bug 415326 in general "Totem crash in LIRC code" [Normal,Resolved: fixed]  
<seb128> siretart: https://beta.launchpad.net/ubuntu/+source/xine-lib/+bug/76566 rather
<Ubugtu> Malone bug 76566 in xine-lib "Totem crash" [Undecided,Unconfirmed]  
<seb128> siretart: retrace on edgy with dbg package, worked fine
<siretart> seb128: k. will try. I have problems with accessing my chroots due to bug #38409
<Ubugtu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
<seb128> siretart: I've updated the bug with the debug retrace
<siretart> still no debug symbols in /usr/lib/xine/plugins/1.1.2/xineplug_decode_faad.so :/
<siretart> hm. which filtbank.c:309 is this?
<siretart> seb128: oaky, this is more like homework for me
<siretart> seb128: thanks for digging this out, I'll continue later on this
<siretart> seb128: btw, is it recommended to join the launchpad beta group? i notice you throw around these 'beta' urls ;)
<seb128> siretart: 309                 time_out[nflat_ls+nshort+i]  = overlap[nflat_ls+nshort+i]  + transf_buf[nflat_ls+nshort+i] ;
<siretart> however, there is no filtbank.c in xine sources
<siretart> I *think* it is in the faad sources
<seb128> it's libxine-extracodec
<siretart> argl, right. in edgy it was split
* iwj reports bug 90161.  I feel like I'm going backwards today.
<Ubugtu> Malone bug 90161 in xen-source-2.6.17 "dom0 oops crash on xm restore when memory is short" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90161
<siretart> iwj: is the lvm/mdadm/udev integration still on your radar?
<iwj> siretart: Err, yes, although I'm not wholly clear on what everyone's symptoms are.
<_ion> summon pitti
<iwj> siretart: Do you have any symptoms or stuff you wanted to particularly get my input on or wanted me to do something about ?
<siretart> iwj: I've now disabled boot and enabled verbose output, and now the boot succeeds in 2/3 of my attempts :/
<siretart> and it always succeeds when I try to gain some debug info :/
<siretart> iwj: wouldn't be offering some way to disable this 'full async udev boot' feature an acceptable workaround for such setups in feisty?
<iwj> siretart: disable option> Yes, that would be good but unfortunately it's not exactly clear what that would mean.  Our previous arrangements had races that affected some random other set of people.
<iwj> Have you got a failed boot when you got verbose output ?
<iwj> siretart: If you have something failing 1/3 of the time then I'm definitely keen on using you as a test case.
<iwj> WDYM `try to gain some debug info' ?
<iwj> Sorry to bombard you with questions :-).
<siretart> iwj: you told me to start udev 'by hand' with --debug info and redirecting it to a file, in order to see what udev does
<siretart> iwj: each time when I do that, the system boots perfectly
<siretart> k, need to go home -cu
<Riddell> pitti: are you able to process my edgy-proposed dist-upgrade packages sometime?
<iwj> siretart: Thanks.  Hmm.  Oh, damn.
<pitti> Riddell: oh, did you upload them now?
<pitti> Riddell: sure, I can process them
<geser> pitti: is php4 still scheduled for removal?
<pitti> geser: yes, of course, I just wanted to give our MOTUs some time to change some packages
<nutmeg> Could somebody point me to the cause of "libksba (1.0.0-1build1) feisty; urgency=low   * Rebuild for changes in the amd64 toolchain."? At least the complete gnutls toolchain has been rebuilt and I just wonder why.
<pitti> wow, codebrowse.launchpad.net - something new every day
<jdong> hey cool tubgirl.launchpad.net!
<jdong> (kidding)
<kylem> very cool
<jdong> doens't do anything for me...
<pitti> jdong: tubgirl? hardly :)
<jdong> pitti: LOL that's not what I meant :P
<pitti> jdong: e. g. http://codebrowse.launchpad.net/~ubuntu-core-dev/apport/ubuntu
<jdong> OH
<jdong> OH WOW
<jdong> it's loggerhead!
<jdong> sweet
<pitti> bzr - the WOW effect!!!
<jdong> the WOW starts here!
* jdong sees MS lawyers enter his lecture hall
<pitti> right, I didn't quite remember the slogan
<jdong> it's kind of good that you don't :)
<jdong> I envy you.
* Mithrandir discovered that bzr is a norwegian clothesbrand today.
<jdong> well... brings whole new meaning to distributed weaves and knits.
<jdong> ok wow that was awful :D
<psusi> is there someone who can finally backport this important breakage fix that has been waiting for months?  https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/68294
<Ubugtu> Malone bug 68294 in dmraid "Please backport dmraid to edgy - works in feisty" [Medium,Confirmed]  
<geser> keescook: are you working on new packages for gnupg (new version 1.4.7) and gnupg2 (new version 2.0.3)?
<Mithrandir> psusi: that should be done as an SRU, not a backport.  We're going to discuss changes in the backport policy for universe in about an hour.
<psusi> Kronuz: and this is the file: ohh....
<keescook> geser: I wasn't planning to yet; the "security vulnerability" described as fixed is a debatable issue.
<pitti> hey keescook 
<psusi> bah... just ohh ;)
<keescook> hiya pitti!  :)
<geser> keescook: so it isn't worth fixing? I haven't read the announcement yet completely
<keescook> pitti: I haven't been following too closely, but did you prep an update to tzdata for the upcoming US DST change?
<pitti> keescook: that has been done one or two months ago already
<pitti> keescook: the currently pending SRU is for 2007b which also changes some DST rules, but only in very small places (not US)
<keescook> geser: the issue is that on-terminal --verify's can be tricked, but this is always true due to embedded terminal emulation, etc.
<jdong> pitti: is that going to be done for Breezy too?
<jdong> pitti: had a person ask me about that yesterday
<pitti> jdong: breezy is really really tricky, because it requires a new glibc
<jdong> pitti: what a luckily timed EOL then :)
<jdong> but surely there's a way to do it, right?
<geser> Mithrandir: please give-back xulrunner on powerpc, ia64 and i386. thanks
<pitti> jdong: there is, sure
<pitti> mvo, seb128_: I'd be eternally thankful to you if you could write some hints how to GUI-install a package to bug 90205
<Ubugtu> Malone bug 90205 in restricted-manager "enabling nvidia needs to check for nvidia-glx" [Undecided,In progress]  https://launchpad.net/bugs/90205
<seb128_> pitti: we really need a lib for that
<pitti> I just thought that codec-install etc. use the same functionality
<pitti> seb128_: ah, it's more than just calling synaptics with a few command line args?
<Mithrandir> geser: given-back
<seb128_> pitti: it's pretty much calling synaptic, every app do the wrapping, UI dialogs needed for it, etc though
<seb128_> pitti: would be nice to have a lib rather than copying the code
<pitti> seb128_: ugh, special UI code needed? indeed
<seb128_> well, would be nice to have a dialog saying what it's going to do and why
<seb128_> same for codec installation
<ajmitch> morning
<seb128_> hi ajmitch
<mvo> pitti: is r-m written in python?
<pitti> mvo: yes
* pitti hugs ajmitch 
<mvo> pitti: I updated the bug with the commandline options
<pitti> mvo: thank you!
<doko> its done
<mdke> pitti: any news on how binary drivers will be installable in feisty? String freeze is in two days so I'd like to get something into the documentation
<pitti> mdke: apt-get install restricted-manager
<pitti> mdke: I think this has a good chance of becoming part of the default install
<mdke> pitti: when will we know?
<pitti> mdke: and it should more or less look like the final version
<pitti> mdke: that's something that Keybuk and mdz have to decide, but I'm quite positive
<mdke> did it go into the archive already? haven't got it here
<pitti> yes, today
<mdke> ah, i'll update
<pitti> pro'ly not yet on the mirrors
<pitti> but on archive.u.c.
<mdke> I use that one
<mdke> mdz: any idea on timescale for knowing whether restricted-extras will be shipped by default?
<mdz> mdke: I don't follow.  by definition, it's not installed by default, and it's been available in the repositories for ages now
<mdke> mdz: I beg your pardon
<mdz> mdke: oh, you're talking about restricted-manager, not -extras
<mdke> mdz: restricted-manager
<mdke> :)
<mdz> it's intended that it be installed by default, yes
<mdke> great, that's perfect
<mdke> we'll try and document it asap
<pitti> mdke: great, thanks
<mdke> pitti: does it do ati?
<pitti> mdke: enabling and disabling the module, but I think it doesn't modify x.org yet
<pitti> mdke: xorg.conf, that is
<mdke> pitti: ok. I don't see ati in the list...
<pitti> mdke: it's certainly supposed to, I just need to find someone to give me the instructions what to change in a bug report
<pitti> mdke: odd, I have it
<pitti> 'ATI Fire GL'
<mdke> oh, I have ATI Fire GL, is that all ATI cards?
<pitti> yes, the driver is called fglrx (fire gl)
<mdke> oh, right
<mdke> is it intended to continue to distinguish between legacy and non-legacy nvidia cards?
<mdke> or will it do that for the user automatically?
<pitti> mdke: hm, not sure actually
<mdke> ok, we can proceed on the basis that it won't, and remove things as relevant if that feature is added
<pitti> mdke: ah, no, because nvidia-glx and n-g-legacy Conflict: to each other
<pitti> mdke: so you can only have one package installed
<mdke> yes
<mdke> but that doesn't stop you magically telling the user which one they need
<mdke> most users are familiar with the difference
<mdke> *not
<mdke_> pitti: sorry, may have missed any response; pinged out
<pitti> mdke_: I didn't answer yet (I'm not actually here any more, sorry)
<mdke_> ok, thanks for your help
<pitti> mdke_: right, I'll chat about this with people who know
<siretart> Mithrandir: I just notice that you unsubscribed bug #64501 from ubuntu-archive
<Ubugtu> Malone bug 64501 in openhackware "FTBFS" [Critical,Confirmed]  https://launchpad.net/bugs/64501
<siretart> Mithrandir: the problem seems to be that the package only builds on ppc
<siretart> Mithrandir: and binary:all packages are built on i386 only in ubuntu
<Mithrandir> siretart: how is that something ubuntu-archive can change?
<siretart> Mithrandir: I'm seeking for input on how to solve this issue
<Mithrandir> siretart: fix CFLAGS to not include -mregnames?
<siretart> which breaks compilation
<Mithrandir> uh?
<siretart> it needs an ppc assembler
<siretart> cross compilation would be an option, but nobody is working on that. in debian, the problem doesn't exist
<siretart> since binary uploads are possible there
<Mithrandir> at least for now, yes.  *shrug*; it needs to be fixed to cross-compile in Ubuntu or something then.
<siretart> err, we are talking about firmware, which qemu needs to boot emulated ppc systems
<siretart> requiring the firmware to be cross compiled seems a bit awkward to me :/
<siretart> hm. I could perhaps compile it on ppc, include it uuencoded, and just unpack it in the package
<siretart> but *that's* really nasty :/
<sistpoty> siretart: yep, that's nasty, but I guess it's the best option... have been doing this for mit-scheme
<Mithrandir> hm, indeed.
<Mithrandir> siretart: you could talk to Adam about it and see if he can do a manual build on a ppc box.
<siretart> Mithrandir: we could indeed upload ppc binaries to the archive?
<siretart> hm. okay, I'll subscribe him then
<alex-weej> is bug buddy supposed to work in Feisty?
<seb128_> alex-weej: we use apport
<alex-weej> seb128_: i.e. bug buddy is disabled?
<seb128_> alex-weej: it's working if you use it, we don't call it though
<alex-weej> only i've been having some gnome-panel crashes, and lots of random apps will just crash occasionally without me even noticing
<alex-weej> it seems apport isn't always working :(
<seb128_> alex-weej: you can activate the gconf key /apps/bug-buddy/run_on_crash
<alex-weej> seb128_: is apport still supposed to catch all crashes? it even used to catch segfaults in CLI tools once upon a time
<seb128_> alex-weej: maybe they don't crash, apport don't catch abort for example
<seb128_> alex-weej: it crashes every SIGSEGV and that works fine on my desktop
<alex-weej> seb128_: if i kill -SEGV `pidof gnome-panel`
<seb128_> kill -11 application
<alex-weej> panel crashes
<alex-weej> but nothing happens
<seb128_> what linux version are you running?
<alex-weej> feisty
<seb128_> no, linux
<alex-weej> 2.6.20-something
<alex-weej> sec :P
<seb128_> official feisty package?
<alex-weej> 9-generic
<alex-weej> yep
<seb128_> do you have anything to /var/log/apport.log ?
<alex-weej> plenty in there
<seb128_> anything about your panel crash?
<alex-weej> seb128_: yep
<alex-weej> it even says it's being called etc.
<alex-weej> it just doesn't pop up
<seb128_> does calling "ubuntu-bug gnome-panel" works fine?
<alex-weej> seb128_: yes
<seb128_> you want to ping pitti or open a bug then :p
<seb128_> does it write reports on crash?
<alex-weej> seb128_: yes it does
<alex-weej> seb128_: i've tested this with gedit and it seems to work
<alex-weej> do you have any idea where the data for "don't report this crash again" or whatever the tickbox reads is?
<seb128_> .apport-ignore.xml
<seb128_> to your user directory
<alex-weej> seb128_: no file = no ticks?
<seb128_> correct
<alex-weej> ok
<seb128_> there is also a 3 crashes limit
<alex-weej> ah
<alex-weej> maybe that's it, it has crashed naturally a lot
<alex-weej> or would that be in .apport-ignore.xml, too?
<seb128_> remove the crash file from /var/crash then
<seb128_> no
<seb128_> it's to the crash file itself
<alex-weej> should i just clear out /var/crash?
<seb128_> correct
<seb128_> and try again then
<alex-weej> seb128_: ok ta
<seb128_> np
<alex-weej> seb128_: works now
<seb128_> cool
<alex-weej> however, i wasn't signalling it artificially before
<alex-weej> and the reports just stopped happening
<alex-weej> i take it it's 3 crashes per app
<seb128_> what do you mean?
<alex-weej> and not per... crash
<alex-weej> basically it has been crashing lots lately
<seb128_> right
<alex-weej> and sometimes i don't have the time to go in and report stuff right away
<seb128_> that 3 crashes in a day or something
<alex-weej> i just need to get on with my work or whatever
<seb128_> otherwise people send 10 times the same crash :p
<seb128_> it's not often that the app crashes 3 times in different ways the same day usually
<Sp4rKy> why all the "echo ..."  command doesn't work in casper ?
<Sp4rKy> ie : chroot /root echo ... > foo doesn't work
<_ion> What's the error message?
<Sp4rKy> nothinf
<Sp4rKy> just no output
<_ion> In that case, it probably works.
<_ion> cat foo
<Sp4rKy> the file isn't created
<impl> Any PHP maints around?
* impl looks at pitti 
* Wombert pokes pitti 
#ubuntu-devel 2007-03-07
<sistpoty> hm... should the original maintainer mangling be done for SRU's as well?
<jdong_> that's what she said.
<rbrunhuber> Mithrandir: Is there any possibility to get in touch with the ubuntu bluetooth team by irc?
<Sp4rKy> i think there is no casper expert ?
<jdong_> Sp4rKy: there certainly is a casper god here :)
<Sp4rKy> ;)
<Sp4rKy> ok, so
<Sp4rKy> in the 10adduser script, i add this line
<jdong_> no no, not me
<jdong_> I meant c-j-w-a-t-s-o-n :)
<jdong_> but I'm very flattered :D
<Sp4rKy> :D
<Sp4rKy> printf "foobar" >> "/root/home/$USERNAME/file"
<jdong_> I'm just an annoying prick here who whines about bugs :)
<Sp4rKy> and this command doesn't produce any result
<Sp4rKy> any idea ?
<jdong_> I wouldn't know
<jdong_> sorry
<jdong_> I haven't messed with that aspect of ubuntu (casper) at all
<Sp4rKy> k
<Sp4rKy> cjwatson is sleeping ?
<Sp4rKy> so, i'll come back tomorrow
<jdong_> just busy in general :)
<jdong_> don't worry, he hasn't talked to me in weeks either :)
<impl> Does anyone here feel like fixing the PHP package, since it's both broken and CVE-2007-0906 isn't actually resolved?
<Sp4rKy> jdong_: pl
<Sp4rKy> ok*
<Wombert> could someone listen to impl?
<Wombert> I mean, you guys messed up not only your own PHP packages, but also debian's
<mooey> Wombert, hm?
<Wombert> impl has the details
<Wombert> you forgot a changeset when porting back a fix
<Wombert> or, rather, you ported a fix for an issue that wasn't there
<Wombert> now stream_get_wrappers() returns a list of stream wrappers, but with the last character missing
<Wombert> affects all php versions
<Wombert> and sends someone crying for help to our channel or mailing list every five minutes
<mooey> Wombert, is there a bug open on this issue?
<sistpoty> keescook: any idea about the php security upload Wombert is talking?
<impl> http://www.ubuntu.com/usn/usn-424-1
<impl> http://changelogs.ubuntu.com/changelogs/pool/main/p/php5/php5_5.1.2-1ubuntu3.5/changelog
<keescook> Wombert, impl: thanks for the heads up, I'll take a look at it.
<sistpoty> great, thanks keescook
<impl> keescook: http://cvs.php.net/viewvc.cgi/php-src/main/streams/streams.c?r1=1.82.2.6.2.9&r2=1.82.2.6.2.10&pathrev=php_5_2_1
<impl> That's the missing changeset
<impl> I believe, anyway.
<keescook> impl: and I can test for the breakage/fix just by looking at stream_get_wrappers()'s output?
<impl> Yep
<keescook> okay, cool.  Thanks!
<impl> In a broken state, every item in the array will be truncated
<keescook> ahha, yup, found a bug on it, I'll track it here:
<keescook> https://bugs.launchpad.net/ubuntu/+source/php5/+bug/87481
<Ubugtu> Malone bug 87481 in php5 "stream_get_wrappers broken in php5 5.1.6-1ubuntu2.2" [Undecided,Unconfirmed]  
<impl> Good good
<keescook> impl, Wombert: feel free to email security@ubuntu.com if you see these kinds of things in the future.  or say "regression" on this IRC channel -- i'll get pinged.  :)
<Wombert> REGRESSION!
<Wombert> :)
<keescook> hehehe
<keescook> biiig ping
<Wombert> did you fix it?
<Wombert> REGRESSION
<Wombert> xD
<Wombert> I'll keep saying that :D
<impl> Wombert: Don't be an arse now :P
<j1mc> howdy somerville32_
<j1mc> you around?
<geser> keescook: any opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413269 ?
<Ubugtu> Debian bug 413269 in wordpress "wordpress: Should not ship with Etch" [Serious,Open]  
<Wombert> it's a pile of shit
<Wombert> throw it out
<Wombert> :p
<keescook> geser: I use wordpress, and I think they're responsive, so I personally don't think it should be dropped, but it's not my call.
<geser> thanks for your opinion
<noahslater> Does anyone here know anything about bash completion?
<sistpoty> we cannot drop wordpress from an already released distribution easily... 
<geser> sistpoty: but it can be done for feisty if someone (who exactly? MC?) decides it
<sistpoty> geser: sure
<noahslater> Why would you drop wordpress?
<sistpoty> noahslater: a history of security issues
<Kronuz_> hello
<Kronuz_> HELP!!
<Kronuz_> :P
<sistpoty> Kronuz_: please see the topic :P
<Kronuz_> my Ubuntu box froze and I want to trace where the problem is
<keescook> geser: I don't see the point; they're responsive to fixes, so I don't see how wordpress is different from any other application with a lot of holes.  we don't drop firefox or php5.  :)
<noahslater> Really... that surprises me that there would be enought to justify that decision. Am I assuming you are dropping it from default or completely from the repos?
<Kronuz_> so I figured this has to do with the development
<noahslater> keescook, +1
<keescook> and as I see it, the Debian debate is about dropping it from Etch, not sid.
<keescook> but I could be wrong, I've sort of been covering my ears.  :)
<Kronuz_> is it a known bug? 'cause I'm sure it's a bug, I found someone else this morning with the same problem. I'm using Ubuntu Edgy and in X everything froze, the only thing I can do is the mouse pointer (not even the keyboard is responding as to switch the console)
<Kronuz_> still, the music was playing and is still playing okay
<Kronuz_> and I can connect via ssh
<mjg59> Kronuz_: Sadly, it's pretty much impossible to diagnose from that
<noahslater> One of your applications hung your X server.
<Kronuz_> but I have connection (ssh)
<noahslater> You need to figure out which one.
<noahslater> Yes, expected.
<Kronuz_> and it's frozen right now
<mjg59> Kronuz_: Ok. Attach /var/log/Xorg.0.log and dmesg to a bug report on launchpad.net, please?
<noahslater> Issue /etc/init.d/gdm restart to fix the problem.
<Kronuz_> ok 
<sistpoty> keescook: sure, I didn't state that it *will* get dropped, but only that we could in theory decide to drop it. 
<mjg59> Kronuz_: No, don't do gdm restart yet
<mjg59> Otherwise it'll destroy the log data
<noahslater> Good point.
<Kronuz_> ok
<geser> keescook: they are dropping it from the next release which is etch for Debian and feisty for Ubuntu. But if you say it won't be much problem to do security support for it I will believe you
<keescook> sistpoty: yeah, for sure.  And I'd understand; it's needed a lot of attention.  :)
<Kronuz_> 'm a programmer, so maybe I can help to nail this once and for all
<Kronuz_> (only I'm very new to Linux)
<sistpoty> geser: personally my opinion is to not drop it, as long as we've got upstream support on patches
<noahslater> Kronuz_, what you are describing is a very common problem with all kinds of applications.
<keescook> geser: well, if they drop it from etch, it won't automatically drop from feisty.
<sistpoty> geser: however the real problem is that we need more manpower in motu-swat. once my thesis is finished... *dreaming*
<Kronuz_> noahslater, what do you mean? this has happened to me three times already in two days
<noahslater> Kronuz_, all that means is that you have a specific application that is causing problems.
<Kronuz_> I'm using X, and suddenly everything freezes (but the mouse pointer)
<mjg59> No, it's an X bug
<Kronuz_> so maybe I could go killing applications until I get to the one with the problem?
<noahslater> Really... that happens to me sometimes - but it's usualy a misbehaving application.
<geser> sistpoty: and we can't use the security updates from Debian as there won't be any. we have to do it on our own.
<sistpoty> geser: yep. however from the few updates I've done testing is really what consumes most of the time, as long as the patches are somewhere/the description is good enough
<Kronuz_> I don't see anything wrong in dmesg or Xorg.log
<Kronuz_> no errors nor anything
<Kronuz_> mjg59, what would you do next?
<Kronuz_> top shows the player only (~5% of CPU)
<mjg59> Kronuz_: Which X driver are you using?
<Kronuz_> I'm using NVIDIA
<geser> sistpoty: afaik WP has no changelog, so one needs to dig in the bugs and svn :(
<mjg59> Heh. Not a great start.
<mjg59> Kronuz_: It's likely to be an X driver bug, and we don't have the source code to the nvidia one available
<Kronuz_> but this morning someone else was using ATI and had the exact same symptoms
<keescook> geser: at least it's svn and not cvs.  :)
<Kronuz_> really a driver's bug? this morning the other guy I was talking with said he even got the frozen box once in the DesktopCD
<Kronuz_> (also using Edgy)
<Kronuz_> maybe it's a coincidence, tho' (the symptoms)
<Kronuz_> can't I just go killing stuff? to see if it suddenly responds?
<Kronuz_> but I wouldn't know what to kill :S
<Kronuz_> (the audio player is working)
<Kronuz_> mjg59, what do you think?
<mjg59> Kronuz_: It's a possibility
<Kronuz_> I think I'll start killing Beryl
<Kronuz_> I suppose it's 'beryl --skip-gl-yield'
<mjg59> Oh.
<mjg59> You're using Beryl?
<Kronuz_> yes
<mjg59> I blame Beryl.
<Kronuz_> NVIDIA and Beryl
<Kronuz_> maybe
<Kronuz_> but the keyboard?
<mjg59> Entirely possible
<Kronuz_> not even caps lock or num lock is doing anything (not even the leds in the kbd change)
<Kronuz_> I'm killing Beryl now... or what was the other command to restore the other windows manager?
<Kronuz_> I might try that first
<mjg59> metacity --replace
<Kronuz_> let me try that, ok?
<mjg59> You'll need to export DISPLAY=:0 first
<Kronuz_> hmm
<Kronuz_> ok
<sistpoty> gn8 everyone
<Kronuz_> mjg59, nope, that command froze
<Kronuz_> (had to ctrl+c it)
<Kronuz_> and it did nothing on the other box
<Kronuz_> mjg59, what would you do next?
<mjg59> I'd attempt to reproduce the bug without beryl and without using the nvidia drivers
<Kronuz_> :P
<Kronuz_> let me kill beryl-manager
<johanbr> Kronuz_: I'm seeing the same problem as you with an ATI card when running Beryl, so it's probably either a Beryl bug or an Xorg bug triggered by something that Beryl does.
<Kronuz_> I see... it would be good to know tho'
<Kronuz_> this guy I told you about this morning wasn't using Beryl tho'
<Kronuz_> (he had an ATI card)
<johanbr> I never see the bug under metacity.
<Kronuz_> but I have NVIDIA, so I suppose that if it is the same bug it would leave Beryl and the card drivers out
<mjg59> There's no indication that it's the same bug
<Kronuz_> yeah, it could be a different one :(
<Kronuz_> (the exact same symptoms tho')
<Kronuz_> maybe if this is happening there should be some logging when that happens
<Kronuz_> mjg59, okay I killed Beryl and it started working again
<Kronuz_> (no titlebars tho')
<Kronuz_> so definitely is must be a Beryl issue
<johanbr> It first happened for me when the Xorg 7.2 updates started rolling in.
<mjg59> Ok. We don't ship Beryl, so you get to keep the pieces.
<Kronuz_> :P
<Kronuz_> okay, thanks anyway... I guess I'll just have to wait and see if they fix this issue in Beryl
<Kronuz_> but, hey, do you know if I can get a coredump or something from that process?
<Kronuz_> probably not anymore :(
<Kronuz_> I should have done so before killing it, right?
<mjg59> Yes
<Kronuz_> (I don't know how coredumps work, exactly... I'm comming from the Windows world)
<Kronuz_> how should I do the dump next time?
<mjg59> Never mind. It'll probably happen again
<Kronuz_> so maybe I can help debugging it
<mjg59> kill -SEGV pid
<mjg59> Oh, sig -QUIT pid ought to be better
<Kronuz_> but what if it doesn't quit?
<Kronuz_> I always use -9 :P
<Kronuz_> hehe
<Kronuz_> <.<
<Kronuz_> >.>
<mjg59> -QUIT should force a core dump
<Kronuz_> I see... that's what I should always use then...
<Kronuz_> and where's the core put?
<Kronuz_> is there a way to know if more than one threads were running in the process?
<Kronuz_> or if it had any children
<Kronuz_> mjg59, next time I'll get them the coredump (to the Beryl guys)
<Kronuz_> be back in my other box in a sec
<ajmitch> and people wonder why we don't ship beryl
<bddebian> heh
<mjg59> Well, we don't ship beryl because it's non-free
<mjg59> But should that be recitified, I'm sure we can find other reasons
<ajmitch> I've heard they're meant to fix those bits in 0.2.0
<ajmitch> whenever that may come out
<Kronuz> back
<Kronuz> mjg59, okay I got metacity working again
<johanbr> Beryl is non-free?
<pax> non-sense.
<blanky> is there a channel for packagers?
<Kronuz> in what package is the glxtokens.h, does anybody know?
<tepsipakki> I've patched libxcb to allow a workaround for the 'c->xlib.lock' crashers
<tepsipakki> by setting an environment variable LIBXCB_ALLOW_SLOPPY_LOCK to any value the check will be ignored
<tepsipakki> the new version is at http://users.tkk.fi/~tjaalton/xorg72/new/libxcb
<tepsipakki> and the patch is originally from Novell
<tepsipakki> please test
<tepsipakki> or upload, which suits best ;)
<pitti> Good morning
<tepsipakki> good morning pitti
<tepsipakki> I just wrote about a patch to libxcb
<pitti> hey tepsipakki 
<tepsipakki> pitti: if you have time, take a look at http://users.tkk.fi/~tjaalton/xorg72/new/libxcb
<pitti> tepsipakki: ah, you need a sponsor?
<tepsipakki> yes
<tepsipakki> it's a patch from Novell which fixes the locking bugs we've seen
<pitti> tepsipakki: can you please put hte source debdiff there?
<tepsipakki> sure
<tepsipakki> there
<tepsipakki> it needs an environment variable to be set, then the check will be ignored
<tepsipakki> so it's not an out-of-the-box solution
<tepsipakki> bbl ->
* fabbione would prefer the workaround enabled by default and we switch to a more anal locking in feisty+1
<fabbione> i am not sure we will have time to fix all apps to the new behavious
<fabbione> behaviour
<pitti> fabbione: hm, I can reverse the logic and use LIBXCB_NO_SLOPPY_LOCK for using the strict method
<fabbione> pitti: nobody is going to set that env var to test... hounestly..
<fabbione> IMHO either we change that assert in something that will tell us: OMG THE WORLD IS FALLING but we disabled the crash for you
<pitti> fabbione: you mean developers not setting it to test the strict method?
<fabbione> or just skip it for feisty and re-enable it very early in feisty+1
<fabbione> pitti: nobody will set it.. but yeah you get it
<pitti> fabbione: ok, so we forget the env var and just use sloppy locking; can do
<fabbione> the message from assert is scary too...
<fabbione> pitti: that's my suggestion
<fabbione> and that's what i would do
<fabbione> for a matter of our own and MOTU's sanity
<pitti> oooooorrlright
* pitti bows to Fabio's X skillz
<fabbione> hahaha that's nothing to do with X 31337 sk1ll0rz
<fabbione> we just need to remember (absolutely) to disable it as soon as feisty+1 opens up
<fabbione> and go with what upstream has
* pitti uses LIBXCB_NO_SLOPPY_LOCK, it can't hurt to have it, after all
<tepsipakki> yeah, maybe that's better :)
<tepsipakki> fedora still has libx11-1.0.3, so they were better informed :/
<tepsipakki> pitti: while you're at it, there are other packages in the parent of that webfolder
<tepsipakki> xorg and video-ati
<tepsipakki> debdiffs also
<pitti> tepsipakki: 'k, checking
<pitti> tepsipakki: the ati fixes come from upstream svn?
<tepsipakki> one of them is applied atm
<pitti> tepsipakki: (it would be nice to mention their source in the changelog)
<tepsipakki> oh
<tepsipakki> right
<tepsipakki> the bugs have more info, but it could be mentioned yes
<pitti> tepsipakki: ah, ok; if they refer to the source, it's at least possible to track them; nevermind then for this ati upload
<pitti> Hi Riddell 
<pitti> tepsipakki: ok, both uploaded
<tepsipakki> pitti: thanks!
<pitti> thanks to you :)
<tepsipakki> np :)
<tepsipakki> maybe I'll debug casper next
<pitti> tepsipakki: after I'm finished with that one mailbox, I'll restart X to test the libxcb change, then I'll upload that as well
<tepsipakki> pitti: cool
<tepsipakki> that should make a lot of people less angry :)
<fabbione> pitti: you don't need to restart X.. it's a shared lib :)
<fabbione> pitti: just run something like azureus (or whatever is called) that's known to trigger the lock error
<pitti> fabbione: yes, but only that way I can make sure that all the gnome stuff is restarted
<pitti> fabbione: ah, cool, I didn't see it so far
<fabbione> pitti: yeah but just starting something else will do... trust me here :)
<pitti> ok
* pitti downgrades again to check for the assert
<fabbione> otherwise the simplest test case is to LockDisplay(); UnlockDisplay(dpy); UnlockDisplay(dpy);
<fabbione> using libx11 calls
<fabbione> pretty simple
<mdke> is anyone taking care of bug 82335 - it seems to affect a significant number of people and makes a lot of applications unhappy
<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
<mdke> for example, my eth1 doesn't seem to be detected by network manager so lots of my GNOME applications are broken
<mdke> quite apart from network-manager itself being totally useless
* fabbione takes off
<Mithrandir> mdke: that's a good point.
<mdke> Mithrandir: :)
<Mithrandir> I'll see if I can get that fixed.
<ajmitch> morning Mithrandir 
<Mithrandir> hiya Andrew
<mdke> Mithrandir: thanks very much
<dholbach> good morning
<ajmitch> hi daniel
<dholbach> hey andrew
<seb128> morning
<pitti> hey seb128 
<seb128> pitti: hi
<seb128> pitti: do we really need to use the sloppy lock things now?
<seb128> pitti: I was thinking about doing that for feisty, using it now hide breakages we could fix for 7.04 though
<dholbach> hi seb128
<seb128> hey dholbach
<tepsipakki> we can fix those we have time for
<pitti> seb128: *shrug*, I just listened to tepsipakki and fabbione, and it seemed sane; if you are sure that we can fix all the broken apps, then that's certainly better
<seb128> well, the dust is under the carpet now :p
<seb128> pitti: not sure, I would keep trying to fix breakages now and consider it for feisty then
<tepsipakki> given that fedora ships xorg-server-1.2.99.901 with libx11 from 7.1 :)
<pitti> \sh_away: re your php4 uploads> you know about https://lists.ubuntu.com/archives/ubuntu-devel/2007-February/023296.html ?
<seb128> pitti: ok, let keep it that way, less work and we don't have an xorg maintainer to work on those anyway. Thanks for the upload, I was supposed to do them yesterday but I've been busy with other things
* seb128 hugs pitti
* pitti hugs seb128 back
<seb128> ogra: do you plan to use that gnome-screensaver patch that fixes xnest?
<asac> seb128: if you have a minute, please take a look at bug 90333
<Ubugtu> Malone bug 90333 in totem "totem plugin causes frequent gecko crashes because NPPVpluginKeepLibraryInMemory is broken" [High,Confirmed]  https://launchpad.net/bugs/90333
<seb128> asac: the discussion with chpe has been useful then? ;)
<asac> yes
<asac> we could eliminate that
<asac> so we don't have to fix gecko code
<seb128> asac: I'll patch totem now
<asac> which is really broken
<seb128> patch looks fine
<asac> thank you so much
<seb128> and I'm all to stop crashers flood
<asac> i guess almost all firefox crashes are gone by then :)
<seb128> np, thank you for working on the patch ;)
<asac> yeah ... i tried multiple ways to fix this in firefox ... but no real clean solution possible
<asac> so i gave up :)
<asac> and went totem ;)
* finalbeta is happy to hear, maybe Firfox will stop crashing every half hour. (except for flash pages)
<asac> seb128: will you push this to debian too?
<seb128> asac: will do
<seb128> asac: you worked with the edgy version?
<seb128> because the patch doesn't apply to the feisty package
<seb128> the feisty version does:
<seb128> 	CallNPN_SetValueProc (sNPN.setvalue,
<seb128> 			      mInstance,
<seb128> 			      NPPVpluginKeepLibraryInMemory,
<seb128> 			      NS_INT32_TO_PTR (PR_TRUE));
<asac> oh
<asac> yes tested with edgy ... but is probably the same
<asac> its about removing the NPPVpluginKeepLibraryInMemory optino
<seb128> ok
<asac> and taking care that so
<asac> is loaded
<asac> with _NOREMOVE
<asac> is pretty simple
<seb128> yeah, I see, easy to adapt
<asac> seb128: you can easily reproduce 
<asac> and verify
<seb128> doing that right now
<seb128> how?
<asac> just open a video
<asac> hit reload
<asac> then go 
<asac> gnome theme 
<asac> and switch it
<asac> -> crash
<Sp4rKy> does someone can explain me why "echo 'foo' > /root/home/$UTILISATEUR/.bar" in casper-bottom/10adduser doesn't work ?
<asac> seb128: should crash epiphany as well as firefox
<cjwatson> doko_: looks like you left a set -x in python2.5-minimal's maintainer scripts?
<cjwatson> Sp4rKy: (a) depends on where you put it (b) I hope that isn't actually $UTILISATEUR since that doesn't exist
<Sp4rKy>  chroot /root install -D -o $USERNAME -g $USERNAME $file /home/$USERNAME$
<Sp4rKy>        what's this if $USERNAME doesn't exist ?
<doko_> cjwatson: hrm ..., fixing
<Sp4rKy> cjwatson: and for a), i put my line just after the line i print over 
<Mithrandir> Sp4rKy: that line creates the directory if it doesn't exist.
<geser> Mithrandir, cjwatson: have you had time to look at the UVF exception for fuse 2.6.3?
<Mithrandir> geser: no, sorry.
<Mithrandir> I'll do so once my email client wants to talk with me again
<Sp4rKy> Mithrandir: so $USERNAME exists
<ogra> seb128, indeed i do
<seb128> ogra: k
<Sp4rKy> so i don't understand why  echo 'ubiquity-gtkui.desktop' >> /root/home/$USERNAME/bar doesn't work
<ogra> seb128, did you prefer no to ?
<Mithrandir> Sp4rKy: add set -x to the top of the script, read /var/log/casper.log when you've booted the live image.
<seb128> ogra: no, quite the opposite, I though you were going to apply it after herd freeze and it's still not uploaded so I was wondering
<ogra> i wasnt working on screensaver stuff yet
<seb128> k
<Sp4rKy> Mithrandir: thx
<Sp4rKy> Mithrandir: is there some good doc about casper, or testing is the best way ?
<Mithrandir> Sp4rKy: there aren't any docs but what you can find on the wiki
<pitti> tepsipakki: Configuring x11-common ... Incorrect nice value; Please enter an integer between -20 and 19.
<pitti> tepsipakki: does that relate to your recent xorg upload?
<mrevell> heno: Hey
<heno> mrevell: hi
<Sp4rKy> Mithrandir: ok
<seb128> pitti: 
<seb128>  xorg (1:7.2-0ubuntu4) feisty; urgency=low
<seb128>  .
<seb128>    * debian/x11-common.config.in:
<seb128>      - fix validate_nice_value() not to fail when using adept
<seb128>        (Closes: LP #68267)
<pitti> seb128: ah, ok, so that was the fix, not the source of the bug
<gnomefreak> ok Lp is down. x11-common wont install now matter what ive tried
<mrevell> heno: Just a reminder that the Launchpad users meeting is at 17:00 UTC in #launchpad today. If anyone from the distro team or other Ubuntu devs have complaints, suggestions, praise or questions :)
<Sp4rKy> Mithrandir: building initramfss :)
<gnomefreak> it gets stuck in ncurses (asks you to choose a nice value"-20 to 19") it fails to let you choose
<seb128> gnomefreak: lp is not down
<heno> mrevell: cool, who from LP will be there (besides yourself)?
<gnomefreak> seb128: i cant file a bug
<gnomefreak> error ID  OOPS-431C732  in your message
<Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/431C732
<mrevell> heno: So far, quite a few of the developers have said they'll be there. Carlos, Elliot M, Brad, David Allouche, Francis, spring to mind
<heno> ok, cool
<heno> mrevell: I'll post to the distro list, do you have a URL, an agenda?
<carlos> mrevell: I'm not sure whether I will be there for the whole meeting. Danilo will, though
<tepsipakki> gnomefreak: what version are you upgrading?
<mrevell> carlos: Cool, thanks.
<gnomefreak> upgrading to 1:7.2-0ubuntu4
<tepsipakki> from?
<mrevell> heno: Agenda is at https://wiki.ubuntu.com/LaunchpadUserMeeting/2007-03-07
<mrevell> heno: thanks, you're a pal :)
<gnomefreak> 0ubuntu3
<tepsipakki> hm
<gnomefreak> Installed: 1:7.2-0ubuntu3 Candidate: 1:7.2-0ubuntu4
<tepsipakki> what frontend?
<tepsipakki> i guess it's not adept ;)
<gnomefreak> tepsipakki: apt-get
<tepsipakki> ok, I'll look into it
<gnomefreak> ty
<heno> or, rather I would post if thunderbird wasn't broken atm :(
<gnomefreak> heno: 1.5.0.10?
<mrevell> heno: Thanks for trying :)
<heno> gnomefreak: yes
<heno> gnomefreak: I assume it's a known problem
<gnomefreak> heno: depends what the problem is. i use it with none
<heno> (having seen a bunch of apport bugs about it this morning)
<tepsipakki> gnomefreak: correct..
<tepsipakki> that "fix" needs to be reverted
<gnomefreak> ok i havetn gotten that far in my monrning yet but i will look into the bugs on .10 and see what we can do with them. i am gonna assume asac knows about this already
<gnomefreak> tepsipakki: ah ty
<seb128> asac: fix verified and patched package uploaded to feisty, thank you
<gnomefreak> seb128: totem?
<asac> seb128: thanks
<seb128> gnomefreak: bug #90333
<Ubugtu> Malone bug 90333 in totem "totem plugin causes frequent gecko crashes because NPPVpluginKeepLibraryInMemory is broken" [High,Fix released]  https://launchpad.net/bugs/90333
<gnomefreak> yes
<heno> asac: ^ I assume you've seen this -- thunderbird crash bugs
<gnomefreak> cool ty
<seb128> asac: np, thank you for the patch ;)
<asac> heno: which?
<heno> several apport ones in a row this morning. was there an update?
<Mithrandir> doko_: how much, if any testing of the new ecj release have you seen?
<asac> heno: i don't see
* gnomefreak goes to start iv of coffee. asac when i get back can you give me the thunderbird bug that heno is talking about ill take a look at it.
<heno> asac: https://bugs.beta.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bugs?start=100
<heno> the last 7-8 on that list
<heno> I'm getting it myself, but assume these are the same thing
<asac> you can reproduce?
<asac> i saw those ... but the list did not grew overnight
<doko_> Mithrandir: a rebuild of OOo and the direct OOo build dependencies; at this point there's one reason for me to have it: vil is working on eclipse-3.2.2 packages (universe), and if he can get these in, it's not nice to have two different ecj versions. So maybe I write him and CC you if he can make it? und just if eclipse-3.2.2 is ready, include ecj as well.
<heno> asac: sorry, not as many as I assumed. I'll reproduce and upload the report
<asac> are there -dbgsym packages for thunderbird? if so, please retrace before upload :)
<Mithrandir> doko_: oh well, there was a fairly large amount of bugs fixed, so let's hope it's good.  Approved.
<doko_> ok
<heno> asac: sorry no -dbg files
<heno> pitti: how do you reset apport to take a new crash report? touch some file as I recall?
<pitti> heno: 'take a new report'?
<pitti> heno: touch /var/crash/* will bring up all the recent reports again
<heno> pitti: bring them up how?
<pitti> heno: same as if they had just happened
<pitti> heno: i. e. 'App foo has just crashed blabla'
<heno> basically when I launch TB now I get a crash, but now apport
<heno> pitti: ok, thanks
<pitti> heno: aaah, I see what you mean
<pitti> heno: rm /var/crash/* should do
<pitti> heno: apport doesn't report more than three crashes per application on a day
<heno> right, makes sense
<asac> heno: no -dbgsym either?
<heno> asac: nope. It would literally be 'mozilla-thunderbird-dbgsym' in main right?
<pitti> right
<pitti> I wonder why it's not there
<pitti> for feisty/1.5.0.10?
<pitti> http://people.ubuntu.com/~pitti/ddebs/pool/main/m/mozilla-thunderbird/ -> it is
<pitti> hey, even for edgy, nice
<heno> asac: here is the bug 90346
<Ubugtu> Malone bug 90346 in mozilla-thunderbird "[apport]  mozilla-thunderbird-bin crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90346
<heno> pitti: oic, so it's not in the standard repos, just in ~pitti ?
<pitti> heno: always; soyuz doesn't support ddebs yet
* pitti needs to run for some errands, bbl
<heno> right, ok
<asac> pitti: cool
<heno> asac: that works, doing one with dbgsym now
<cjwatson> whoops, I broke the daily-live builds
* cjwatson fixes
<asac> heno: maybe try retrace you report
<asac> heno: does running in -safe-mode help?
<heno> asac: is there a command line option to do that?
<asac> yes ... you are on feisty?
<heno> yes
<asac> aeh ... for safe mode or for auto retrace?
<heno> for safe mode
<asac> # thunderbird -safe-mode
<heno> I'm doing a retrace now
<heno> ok, it's not listed in --help
<heno> sec.
<asac> yeah ... probably a bug; but --help is not really helpful for any mozilla apps ... so :/
<heno> asac: still crashes in safe mode
<asac> ah ... then retrace
<seb128> ogra: do you know about https://launchpad.net/ubuntu/+source/gdm/+bug/82894 ?
<Ubugtu> Malone bug 82894 in gdm "Logging out of Gnome from XDMCP session does not return to login screen" [Undecided,Unconfirmed]  
<carlos> hmm
<carlos> latest X.org update in Feisty is broken
<carlos> xorg-common keeps asking me for a 'nice' value between -20 and 19
<seb128> carlos: it's already fixed
<seb128> wait for update to build
<carlos> oh, ok, so I just got the broken one...
<carlos> I'm sooo lucky :-P
<carlos> seb128: thanks
<seb128> np
<ogra> seb128, looks like something makes the session hang
<ogra> dbus is a good candidate
<joumetal> there is problem with x11-common upgrade. Incorrect nice value.
<Mithrandir> joumetal: it's already fixed.
<seb128> joumetal: that's not a bug chan, that's already known and fixed
<joumetal> ok thanks
* Mithrandir would really, really, really like LP to generate useful RSS feeds in various contexts.
<highvoltage> Hi. Who at Canonical can I ask about Click'n'Run (CNR)?
<Hobbsee> highvoltage: want to make your quesiton a little less broad?
<highvoltage> Hobbsee: to be more specific, I work on an Ubuntu derivative that would like to include CNR, and I can't find anything CNR related in Feisty yet
<Hobbsee> highvoltage: likely because it's not there.
* Hobbsee guesses you'd have to ask the CNR guys what they're doing to get it into ubuntu.
<Hobbsee> as opposed to the other way around.
<highvoltage> Hobbsee: I think it's because the current version is non-free, and the final version will be free software
<highvoltage> Hobbsee: ok cool, I'll give them a shout
<doko> mvo: ping
<doko> Built successfully
<doko> Purging chroot-autobuild/build/buildd/openoffice.org-2.2.0~rc3~oof680m10
<Hobbsee> hooray!
<Treenaks> \o/ dholbach (libbtctl)
<pitti> meh, I want devhelp back
<pitti> Mithrandir: could you please give-back devhelp on amd64 and sparc?
<Mithrandir> pitti: I'm currently trying to rescue the xorg upload and want to get that in before I give back anything, really.
<Mithrandir> pitti: but yes, I'll do that afterwards.
<pitti> Mithrandir: oh, sure, not terribly urgent; just queueing
<pitti> thanks
<Mithrandir> ok, publisher running, we should have working buildds, etc in about 30 minutes.
<Mithrandir> pitti: is G and K in the langpacksize script output gnome and kde or something else?
<Mithrandir> pitti: and can I have it give me the number on a per-arch basis?
<doko> Mithrandir, pitti, seb128: the openoffice.org and openoffice.org-l10n binaries can be processed now
<seb128> doko: doing that
* mooey shouts
<mooey> patching packages is too difficult :(
<seb128> mooey: what package do you try to patch?
<Mithrandir> pitti: devhelp-given-back.
<mooey> seb128, any, heh. i always give up. do you know any decent documentation? or some list of commands to apt-get source a package, make change, test and make a patch thats acceptable for developers? i read pittis open week page on the wiki, but it doesn't cover actually building and testing a package
<seb128> mooey: apt-get source package name, cd package-dir, make change, debuild
<seb128> mooey: use dch to add a changelog entry and debdiff previous current version
<mooey> seb128, debuild usually works the first time, but the second time it complains that it cant reverse the patches
<seb128> that's a package bug then
<seb128> or your change conflicts with a patch
<mooey> so for suck packages that fail even if i haven't made any changes, i should report it in launchpad?
<mooey> or at debian bts?
<seb128> mooey: launchpad
<pitti> Mithrandir: Right, G = Gnome+base (Ubuntu), K=KDE+base (Kubuntu), G+K=Gnome+KDE+base (Edubuntu)
<pitti> Mithrandir: per-arch? langpacks are arch:all
<pitti> Mithrandir: and the large bits of scim as well
<Mithrandir> pitti: hm, ok.
<mooey> alright. now it complains that i dont have an @ubuntu.com address, is there a flag i can pass to debuild to tell it to ignore such error?
<Hobbsee> no
<mooey> Hobbsee, so what should i do?
<pochu> mooey: you should put ubuntu-motu@l.u.c or ubuntu-devel-discuss@l.u.c
<cjwatson> mooey: upgrade devscripts and you won't get that
<pochu> cjwatson: that's not a requirement anymore?
<cjwatson> pochu: not unless DEBEMAIL includes @ubuntu.com
<cjwatson> (in other words, only Ubuntu developers need to worry about it
<cjwatson> )
<cjwatson> Riddell: is https://launchpad.net/ubuntu/+source/ubiquity/+bug/89458 what you fixed in ubiquity 1.3.24?
<Ubugtu> Malone bug 89458 in ubiquity "Crashed when trying to put in mountpoint in partitioner" [Undecided,Unconfirmed]  
<pochu> ok, ty
<Mithrandir> doko: why isn't there any libuno-cil for sparc?
<doko> Mithrandir: read the changelog ;) it doesn't build according to debian, I didn't have the time to check
<mooey> thanks pochu, cjwatson that seems to have sorted it. have i missed some documentation that has this sort of thing in it?
<Mithrandir> doko: ok.  (Looking at changelogs is slightly hard on drescher)
<cjwatson> mooey: no, you're apparently running the development branch which is often light on documentation and definitely expects you to keep up to date
<cjwatson> any documentation that does exist generally assumes you are up to date
<mooey> cjwatson, so there is documentation about modifying packages for edgy?
<cjwatson> mooey: however the change in question is described at http://wiki.ubuntu.com/DebianMaintainerField if you're interested (but you probably don't need to be)
<Mithrandir> doko: ooo{,-l10n} accepted.
<cjwatson> start at https://wiki.ubuntu.com/UbuntuDevelopment
<cjwatson> mooey: ^-
<mooey> thanks, cjwatson 
<Mithrandir> Riddell: libkexiv is just split out from digikam source in main (and should go to main)?
<khermans_> i think i would like to make the Mirror Choosing algorithm more efficient, but i wonder if you made it slower on purpose
<khermans_> in Synaptic
<khermans_> It tried to pick from 100-200 servers
<mvo_> khermans_: the speed test in software-properties?
<khermans_> mvo_, yes
<mvo_> khermans_: what do you have in mind for it? if you want to hack on it, you are more than welcome :)
<khermans_> the test could be done in less than 3 seconds instead of 1 minute
<mvo_> khermans_: I'm all ears 
<khermans_> just open x number of connections simultaneously
<khermans_> in parallel
<khermans_> take first one that wins
<mvo_> khermans_: interessting! could you please open a whishlist bug against software-propoerties with this conversation? this way the idea will not get lost and glatzor will have a chance to see it as well
<khermans_> mvo_, sure
<khermans_> is launchpad broken?
<Hobbsee> define "broken"
<khermans_> im getting a timeout error
<khermans_> OOPS-431C1190
<Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/431C1190
<mvo_> khermans_: thanks!
<khermans_> hrmm, seems to be OK now, but it failed for a minute or two
<mvo_> khermans_: let me know the bugnumber once its added
<khermans_> mvo_, https://launchpad.net/ubuntu/+source/software-properties/+bug/90379
<Ubugtu> Malone bug 90379 in software-properties "Select Best Server can be more efficient by pinging in parallel" [Undecided,Unconfirmed]  
<mvo_> khermans_: thanks
<mvo_> iwj: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstbaseutilsinstallplugins.html (under (4)) has new and different return code requirements for the codec installer. did you had any contact with upstream about this?
<mvo_> iwj: they seem to be not compatible with the ones we speced earlier
<khermans_> mvo_, btw i didnt see how to set 'wishlist'
<mvo_> khermans_: I set it to confirmed/wishlist now
<khermans_> mvo_, how do i do it in future?
<khermans_> i see how to set confirmed
<cjwatson> khermans_: setting importance is restricted to members of the ubuntu-qa team
<khermans_> cjwatson, thx
<cjwatson> doko: any idea why https://launchpad.net/ubuntu/+source/ubiquity/+bug/89526 might happen? it's not the first time I've seen it
<Ubugtu> Malone bug 89526 in ubiquity "livecd installer crashes upon loading" [Undecided,Unconfirmed]  
<cjwatson> File "/usr/lib/ubiquity/ubiquity/tz.py", line 168, in __init__ today=datetime.datetime.today()
<cjwatson> ValueError: microsecond must be in 0..999999
<doko> looking
<cjwatson> I'm almost tempted to catch ValueError and run it in a loop a few times ;-)
<doko> only powerpc, or other archs?
<cjwatson> not sure offhand
<cjwatson> I'll do a bughelper search
<cjwatson> you think it might be the powerpc epoch-before-1970 thing?
<doko> cjwatson: http://python.org/sf/1646728 in the update I prepared, just waiting for mvo to comment on bug 88512
<Ubugtu> Malone bug 88512 in python2.5 "python2.5-minimal breaks update from Edgy to Feisty" [High,Confirmed]  https://launchpad.net/bugs/88512
<cjwatson> datetime.datetime.fromtimestamp(-1000000) seems to work fine, so I assume negative timestamps are OK in general
<cjwatson> oho, maybe not
<cjwatson> >>> datetime.datetime.fromtimestamp(-1000000.1)
<cjwatson> Traceback (most recent call last): File "<stdin>", line 1, in ?
<cjwatson> ValueError: microsecond must be in 0..999999
<cjwatson> doko: ah, thanks for the upstream bug link
<cjwatson> doko: I think I'll work around it somehow for now
<tfheen> hi scott
<Keybuk> heyhey
<iwj> mvo_: No, I hadn't heard anything about this.
<iwj> How annoying.  I bet the ones in their document are insufficient, too.
<mvo_> iwj: I changed the return codes in g-a-i now to the new world order
<iwj> Hmm.  OK.
<mvo_> iwj: but I agree, very anoying
<iwj> Does that need changes to nautilus too ?
<iwj> I would have been tempted to make a sh wrapper.
<mvo_> iwj: I don't think so, it affects only the codec installs
<iwj> Also, I note that g-a-i is written in Python and Python programs can't reliably avoid exiting 1.
<iwj> So you need a sh wrapper anyway.
<iwj> (Any untrapped exception in a python program causes an exit status of 1 and this might happen before your script gets to fix up an error handler.)
<iwj> That's why I didn't use 1 in my list of exit statuses.
<iwj> I think the gstreamer spec should have been changed, personally.
<iwj> And why oh why oh why do people think they can just go and change an already-specified and -implemented interface to be randomly different ??
<iwj> And now we are put in the position of fixing the less-broken program because the more-broken program is surrounded by more-broken institutions and processes.  Bah.  Rant cont pp99 etc.
<iwj> mvo_: Sorry btw for not seeing your query earlier.
<iwj> I just noticed it when I came to this virtual desktop to collect a web browser ..
<mvo_> iwj: no problem. I have no idea why they changed the spec, sorry
<iwj> Yes, don't apologise.  Not your fault.
<iwj> Sorry for grumping at you.
<iwj> Anyway, what will you do about the exit status 1 problem ?
<mvo_> iwj: I'm pretty grumpy about this as well
<iwj> Feel free to c&p my rant and email it to someone ...
<mvo_> iwj: about the exit status 1 problem, we could install a execption hook hanlder for this
<iwj> mvo_: But python might exit 1 anyway eg because it can't read your script or some core bit of python is broken.
<iwj> Or your attempts to report the error in your own exception hook handler might throw another exception.
<iwj> Python is just fundamentally broken in this respect.
<iwj> The workaround is make exit status 1 mean `this program failed catastrophically'.
<mvo_> iwj: right, the execption hook thing would not cover all cases :/
<mvo_> iwj: right
<cyberix> Feisty dist-upgrade tells me that some nice values are wrong, but doesn't allow me to fix it in any way.
<tfheen> cyberix: your mirror is out of date.
<tfheen> upgrade to the latest version
<bddebian> Heya
<Keybuk> Err http://archive.ubuntu.com dapper/main Packages
<Keybuk>   Could not resolve archive.ubuntu.com
<Keybuk> *blink*
<bddebian> nice
<Keybuk> this is weird
<Keybuk> applications (apt, telnet) can't resolve
<Keybuk> but ping, host, nslookup, dig, etc. can
<cyberix> tfheen: Thanks.
<cyberix> tfheen: But why doesn't the mirror pull the latest version on request?
<asac> heno: can you redo your crash report with -dbgsym packages available from http://people.ubuntu.com/~asac/mt-feisty/ ?
<heno> asac: yep
<asac> heno: ty
<lemsx1> in feisty i'm having problems with x11-common looping with the question "nice value must be a value between -19 and 19"  that happened on a clean Feisty installation while updating today
<tepsipakki> lemsx1: fixed already
<cjwatson> Riddell: in future please sift through debdiff output when uploading ubiquity. It's annoying to have to read huge slews of diffs to various revision control files
<Keybuk> pitti: help!
<lemsx1> tepsipakki: good to know
<Riddell> tfheen: yes, libkexiv was previously in digikam and s needed in main
<lemsx1> tepsipakki: is the package uploaded?
<dholbach> lemsx1: yes
<lemsx1> dholbach: ok. i'll switch to the main archive then
<cjwatson> cyberix: most mirrors operate on the basis of pulling in a cron job, not pulling on request
<cjwatson> cyberix: since the bulk of mirrors are voluntary, we have no means to tell them to pull faster
<cyberix> :-/
* cyberix feels that a distributed data store would be better than mirrors.
<cyberix> But ofcourse not very easy to switch
* cjwatson feels that options that are practical today are always superior to options that don't exist ;-)
<cyberix> I created a summer of code proposal for creating GNUnet support for apt.
<cyberix> last summer
<cyberix> But I did not get funding.
<elmo> oh my god.  who could I pay to make dontzap the default?
<Sp4rKy_> cjwatson: my issue with casper s resolved, thx
<mjg59> elmo: Oh, easily fixed
<elmo> mjg59: ?
<mjg59> elmo: It's a one line change in Xorg
<mjg59> So, how much are you willing to pay me?
<mjg59> Damn, I've still not got this negotiating thing right
<elmo> 2 fruit flies?
<mjg59> ...
<kylem> elmo, hehe.
<cyberix> Here is a reference http://www.cs.helsinki.fi/u/twruottu/aptgn/aptgn.en.html.utf8
<cyberix> Maybe I'll still start the project one day
<cyberix> With a funding or without one. ;-)
<Riddell> cjwatson: ok, what did I do wrong?
<heno> asac: so is it good news or bad news that I can't get it to crash anymore now? :)
<dholbach> can somebody please give back gksu on amd64? and take a look where the devhelp binaries of amd64 went?
<heno> I've since done another system update
<cjwatson> Riddell: well, if you run debdiff between old and new .dsc before uploading then you'll notice enormous diffs and be able to do something about them
<pax> Keybuk: I experience(d) the same when firestarter is running.
<asac> heno: hmmm you remember if crash happened on 1.5.0.10 or 1.5.0.9 ?
<cjwatson> Riddell: in this case, passing -I.svn -I.bzr -I.bzrignore to debuild would sort it out
<cjwatson> Riddell: I have this in .devscripts so I don't need to worry:
<cjwatson> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\{arch\}|\.arch-ids|\.arch-inventory|\.bzr|\.bzrignore|\.shelf)(?:$|/)' -ICVS -I.svn -I\{arch\} -I.arch-ids -I.arch-inventory -I.bzr -I.bzrignore -I.shelf -uc -us"
<cjwatson> (most of the first is backward compat - just -i is generally enough I think)
<heno> asac: definitely, 1.5.0.10, I checked with --version
<Keybuk> pax: this was being caused by mdns, afaict
<asac> heno: then i don't know ... if you ever can reproduce let me know ... if you don't see for two days, please close current bug :)
<lemsx1> dholbach: tepsipakki: it worked. x11-common from archive.u.o (not the mirrors. us.a.u.o still has the old (broken) package)
<heno> asac: sure, will do
<doko> bdmurray: how could you reproduce bug 90004 ?
<Ubugtu> Malone bug 90004 in glibc "issuing ldconfig causes Bus error and core dump, inhibits execution of postinst script for libgcc1" [Undecided,Confirmed]  https://launchpad.net/bugs/90004
<lemsx1> does anybody use Synergy? synergy is broken in Feisty. it works fine on previous versions of Ubuntu
<bdmurray> doko: Can't do reproduce it today.
<bddebian> lemsx1: Filed a boog?
<lemsx1> the mouse/keyboard (input) pauses (is broken) for a while when you use it
<lemsx1> bddebian: i'm not sure where the problem might lie... perhaps xorg input package?
<lemsx1> bddebian: i'll check the bugs for synergy (the package) to see if somebody already reported that
<bddebian> OK, thanks
<bdmurray> doko: earlier I had used 'sudo ldconfig -v' per the first report
<doko> bdmurray: does work for me
<iwj> mvo_: I just had a case where DscSrcPackage(...).checkDeb returned False.  How am I supposed to find an error message ?
<iwj> (As it is I found out what was causing the problem but I want to improve my script's error reporting.)
<mvo_> iwj: there should be a "_failureString" in DscSrcPackage
<mvo_> iwj: I guess that should be made to something more formal (even if this just means removing the "_")
<iwj> Can I assume that DebPackage has a _failureString too ?
<iwj> Eg, if I say satisfyDependsStr ?
<iwj> d = DebPackage(cache);  res = d.satisfyDependsStr("some thing");
<iwj> and then res is false so print d._failureString
<iwj> mvo_: It's not clear to me why it doesn't just throw an exception ...
<mvo_> iwj: it should do that, sloppy programmer
<iwj> Right :-).
<iwj> OK, well, I'll use _failureString for now and if you make it throw an exception then my code will stay correct :-).
<mvo_> iwj: thanks
<iwj> /dev/mem: mmap: Bad address
<iwj> I wonder what that's from.
<iwj> debconf ?  Some crazy thing doogie put in dpkg ?
<mjg59> Only things that need to mmap /dev/mem that spring to mind are X and libx86-using things
<iwj> mjg59: This is in an apt transcript where it's trying to install the build-deps for acpi-support, on a Xen guest.
<iwj> In amidst lots of complaints from debconf which is grumbling excessively about lack of a controlling tty.
<mjg59> Hm. There's unlikely to be any point having acpi-support on a Xen guest.
<iwj> mjg59: Yes, but I just want to build it.
<mjg59> Ok. And this is just /installing/ the build-deps? In that case, I have no idea.
<iwj> Yes.
<pitti> Keybuk: what's up?
<tfheen> I wonder why you get debconf installed, given that none of the build-deps would have a reason to need debconf.
<pitti> heno, asac: you know that you can use the retracing service on ronne now, right?
<Keybuk> pitti: s'ok, think I solved it on my own
<asac> pitti: yes ... but proper dbgsym not available for tbird :)
<heno> pitti: yes I did see your mail about that
<heno> pitti: I tried running it locally. How long should I expect it to take?
<iwj> umovestr: Input/output error
<pitti> heno: a few minutes probably
<heno> I left if for about 30 minutes on an amd64 4000+
<pitti> asac: how so, they are available for both edgy and feisty?
<pitti> heno: urgh, that the heck does it do? what does top say?
<pitti> heno: you can use -v for some verbosity in package install/removal etc.
<asac> pitti: DEB_BUILD_OPTIONS=noopt does not work
<heno> pitti: no, was mostly just idling actually
<asac> thats what i tried to fix in laast upload, but failed miserably ... as you might know :)
<pitti> heno: any processes running which look like the culprit
<asac> pitti: you read pm about gnupg security update?
<pitti> asac: doing now
<heno> pitti: it ran fine now, taking about 1 minute
<pitti> heno: if it was feisty, then it was perhaps the broken xorg upload?
<heno> warned me about some missing unrelated -dbgsym packages
<pitti> heno: that one just spun my chroots this morning
<heno> pitti: could well be
<heno> it seemed to cause IMAP sync in TB to fail for some reason
<asac> heno: you managed to do a retrace with my hand-crafted -dbgsym packages for tbird?
<heno> asac: no, after installing your -dbgsym it didn't crash
<heno> but then I had also updated xorg in the meantime
<asac> yeah ... but maybe you can now run apport-retrace on the crash dump?
<asac> ok ... if not, lets keep this filed under the xorg broke it category :)
<heno> asac: I have done. I'll attach the output to the bug
<asac> heno: thank you
<Sp4rKy> if i want start something at the session start of the Live user, what's the best way ?
<cjwatson> mjg59: there's an = vs. == typo in your parted gptsync patch
<cjwatson> -+              if (raw_part->OSType = 0x0b) {
<cjwatson> ++              if (raw_part->OSType == 0x0b) {
<mjg59> Oops!
<mjg59> Well, easy to fix...
<mjg59> Only triggers if you have any DOS partitions
<delire> i notice that leading whitespace is considered when parsing usernames in the Ubuntu login dialog. is this a bug? people often hit the spacebar to awaken the monitor and so the space character is passed to the username field if present (like if they'd logged out before going to lunch).
<delire> <-- 6.10
<cjwatson> mjg59: right, just in case you'd sent it upstream
<mjg59> Oh, yeah. I doubt they'll merge it as is.
<cjwatson> fix uploading now
<mjg59> Thanks!
<dholbach> how will the archive test rebuild work? will we get mails about packages that ftbfs? bugs? lists somewhere? (it'd be nice to have a list for universe packages, so we can work on fixing them)
<lucas> dholbach: where is that test rebuild announced ?
<dholbach> lucas: https://wiki.ubuntu.com/FeistyReleaseSchedule
<lucas> ok, thx
<dholbach> tfheen: ^ do you know anything about that? (test rebuild ftbfs lists?)
<jcole> a little bird told me that the debian installer will support encrypted filesystems... will fiesty (using the debian installer mini.iso) allow for this feature?
<cjwatson> not yet, no, sorry
<cjwatson> jcole: ^--
<cjwatson> at the relevant time cryptsetup wasn't ready for main (couldn't deal with usplash) - that may have changed lately, I haven't checked
<jcole> cjwatson: ok, thanks for the info
* cjwatson fails to make tune2fs(8) and df(1) output line up
<cjwatson> how the heck do I get accurate information? block-size*block-count/1024 (tune2fs) != 1K-blocks (df)
<cjwatson> a 505MB disparity on this 31GB filesystem seems a bit over the top - reserved blocks only make up ~160MB so that doesn't account for it
<broonie> cjwatson: df doesn't report the space reserved for root as free.
<cjwatson> broonie: as I said above, reserved blocks don't account for it
<broonie> Yeah, very laggy.
<cjwatson> in any case reserved is included in the 1K-blocks column, just not in Available
<cjwatson> (FWIW, this is part of an attempt to teach partman how to resize ext2/ext3 without using parted, since parted can't handle the common resize_inode feature)
<jcole> We are listening to what customers are saying about Linux and taking it into consideration," said Dell spokesman David Lord. "We are going forward. Let's say, 'Certainly stay tuned." - http://today.reuters.co.uk/news/articlenews.aspx?storyID=2007-03-06T235238Z_01_N06441608_RTRIDST_0_TECH-DELL-LINUX-DC.XML
<jcole> i'm guessing suse has contacted them recently...
<jcole> dell's interest in linux is definitely an ubuntu support opportunity...
* dholbach hugs heno - your mail made me laugh :))))
* heno hugs dholbach for releasing bughelper 
* dholbach hugs sfllaw and Riddell for coming up with the release name scheme :)
<Riddell> I did?
<dholbach> Riddell: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2007-01-11.html - 05:16
<Riddell> oh aye, http://en.wikipedia.org/wiki/Magical_objects_in_Harry_Potter#Pensieve was what your description reminded me of
<dholbach> yeah, I thought so :)
<pitti> fabbione: still here?
<dholbach> can somebody please give back gksu on amd64? and take a look where the devhelp binaries of amd64 went?
<elian_m> hi there, how does ubiquity translation work? Rosetta?
<elian_m> I'm the d-i translator for Albanian, I'd like to see the rest of the front-end translated too
<pochu> elian_m: I think everything in Main uses rosetta
<pochu> elian_m: but Feisty translations aren't open yet, though you can translate it in dapper and edgy
<elian_m> pochu: I was looking at rosetta right now :-)
<pochu> :)
<elian_m> pochu: I downloaded the latest package I found there (from feisty pages), hope it's OK for now
<doko> pitti: isdnutils depends on tcl8.3 as well
<cjwatson> elian_m: Rosetta, yes, but it's only updated semi-automatically
<cjwatson> elian_m: i.e. by me running a set of scripts on my laptop
<Riddell> pitti: did you approve the packages for dist-upgrade in edgy-proposed NEW?
<cjwatson> elian_m: the installer is a little confusing in Rosetta, but the whole thing is aggregated under "debian-installer", including ubiquity, to ease the work of handling shared translations
<sfllaw> dholbach: Wow!  Uhm, OK.
* sfllaw hugs dholbach.
<sfllaw> I should get ready to help with Jeff's baby.
<sfllaw> Baby!!!
<sfllaw> :)
<cjwatson> elian_m: the translations under the ubiquity source package *are* used, but they're just for the .desktop files
<elian_m> cjwatson: in fact I see there are 2 template.pot files under debian/ reguarding the front-end
<cjwatson> elian_m: right, ignore the one under imported-po
<elian_m> cjwatson: can I translate these using my po editor and send them to you?
<cjwatson> elian_m: please translate them in Rosetta
<cjwatson> that's the easiest for me because I can handle lots of languages in bulk
<cjwatson> (translate in Rosetta, or translate in your po editor and upload to Rosetta, whatever)
<cjwatson> elian_m: https://launchpad.net/ubuntu/feisty/+source/debian-installer/+translations
<cjwatson> if that's out of date, let me know
<cjwatson> hmm, it does appear to be out of date
<cjwatson> carlos: did the debian-installer import fail? I know you said it would take a couple of days ...
<alex-weej> can somebody take a quick look at this bug please and set its importance? 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-5 doesn't boot with sata-hd" [Medium,Confirmed]  
<alex-weej> it's a regression from 2.6.19
<cjwatson> please can people stop nominating bugs for feisty. kthxbye.
<cjwatson> (it's meaningless)
<alex-weej> and is likely related to https://launchpad.net/bugs/71040
<Ubugtu> Malone bug 71040 in linux-source-2.6.20 "rebooting instead of shutting down" [Medium,Confirmed]  
<alex-weej> as the hardware specs that people keep coming out with are asus P4P/C800 motherboards and acer laptops
<pochu> alex-weej: have you tried 2.6.20-9?
<alex-weej> pochu: that's what i'm running
<pochu> alex-weej: it's because the report says -5 :)
<alex-weej> actually... is that a new package?
<alex-weej> hmm
<alex-weej> when did it go in? cause the rebooting problem isn't fixed and i've just been used to editing my kernel options every boot to include "irqpoll"
<alex-weej> i will test in a minute and update the bug
<pochu> heno: http://ubuntuforums.org/showthread.php?p=2259307#post2259307 :-P
<heno> pochu: right, will do (will just have dinner first)
<pochu> bon apetit ;)
<alex-weej> exactly the same with -9
<alex-weej> 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-9 doesn't boot with sata-hd" [Medium,Confirmed]  
<alex-weej> updated title
<alex-weej> worth upgrading the importance?
<alex-weej> *hint hint* 
<tsmithe> seb128, sorry to bug. (/me feels bad). are you on archive duty?
<seb128> tsmithe: hi, sort of, it's my archive day, I'm not doing that right now though, anything urgent?
<tsmithe> well... urgent only in the sense that we'd like the packages in for ubuntustudio; but enblend and wired would like to get in :)
<delire> will vim7 allow for :syn on in Feisty?
<delire> (out of the box)
<seb128> tsmithe: I think I looked at wired already, it's not trivial though and it's after FF and UVF
<tsmithe> hmm
<tsmithe> it was uploaded before FF. i had thought that that was what mattered
* netjoined: irc.freenode.net -> anthony.freenode.net
<seb128> maybe, it's just not trivial and I would prefer having somebody else accepting it
<seb128> or having an another look
<tsmithe> oh ok. it would be great, thanks, if that could happen
<zyga> hello
<zyga> I recently enabled popularity contest
<zyga> but my mails got bounced for some reason
<zyga> popcon@ubuntu.com is not responding
<dsas> zyga: popularity-contest works using HTTP rather than mail in ubuntu
<dsas> /etc/popularity-contest.conf should have "usehttp="yes"
<bhale> tfheen: i am not sure what the right process these days is, but i subscribed you to uvf bug #88751
<Ubugtu> Malone bug 88751 in beagle "UVF - Beagle 0.2.16.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88751
<zyga> dsas: I see, thanks
<bhale> tfheen: let me know if it belongs somewhere else please
<carlos> cjwatson: well, it's taking more time due the huge list of pending imports for Feisty and a performance problem we introduced recently
<cjwatson> carlos: fair enough
<tfheen> bhale: thanks, that's fine.
<bhale> tfheen: cool, thanks dude
<tepsipakki> please beta.launchpad.net, work for awhile or I'll go to bed ;)
<ajmitch> tepsipakki: or disable the redirection
<tepsipakki> ajmitch: hmm, indeed
<cjwatson> Riddell: judging from bug reports, I think the Kubuntu autopartitioning frontend in ubiquity is deeply wedgied in the event you have more than one disk (I've had several reports of it selecting the wrong disk). I'm going to check this out in detail tomorrow in vmware once the image syncs down
<cjwatson> s/Kubuntu/KDE/
<ajmitch> tfheen: had a chance to look at bug 90058?
<Ubugtu> Malone bug 90058 in f-spot "UVF Exception for F-Spot 0.3.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90058
<tfheen> ajmitch: no, sorry.  If you want me to look at stuff you file, write me a proper mail about it, don't just mail me about it.  I'm subscribed to about half the bugs in LP, one way or another..
<ajmitch> sorry, I thought subscribing the release team was enough
<tfheen> that's going to be the new process, yes, but I need to either whip myself into checking that list a bit more often or get an RSS feed of it or something
<tfheen> anyway, it's bedtime for me now, I'll look at it tomorrow.
<ajmitch> ok, thanks
#ubuntu-devel 2007-03-08
<boiton1> When is OTRS 2.1 planed to be included in ubuntu?
<j1mc_work> in regards to reporting ISO testing sucesses and bugs, are we still using the instructions found here (https://wiki.ubuntu.com/Testing/ReportingResults) for now? 
<j1mc_work> somerville32_: are you around?
<j1mc_work> i think that test reports get submitted here: https://bugs.launchpad.net/ubuntu-iso-tests/ but i just want to make sure before communicating that with other xubuntu testers.
<boiton1> any ideas guys? gals?
<pochu> j1mc_work: yes, there
<j1mc_work> pochu: thanks.
<boiton1> in reference to my question about OTRS version 2, does anyone have any idea how I can find this out?
<cjwatson> boiton1: #ubuntu-motu might be a better place to ask
<j1mc_work> pochu: should i create a new "bug" at https://bugs.launchpad.net/ubuntu-iso-tests/ for each of the different daily images that are tested, or will we only create a new "bug" after each release (e.g. herd 5, beta 1, etc. . . )
<cjwatson> I think otrs 2 might be in Debian experimental
<cjwatson> j1mc_work: no, see https://wiki.ubuntu.com/Testing/ReportingResults
<cjwatson> boiton1: ah, try the otrs2 package
<cjwatson> boiton1: apparently they're sufficiently incompatible that the package was renamed
<cjwatson> that's 2.0.4 rather than 2.1, but hopefully that's enough for you ...
<boiton1> cjwatson, thank you for the help and yes it is in debian unstable
<boiton1> cjwatson, would you happen to know the policy used to bring in packages to ubuntu?
<j1mc_work> cjwatson: thanks.  i'll double-check the build date of the nightly images i've been using.  
<cjwatson> boiton1: https://wiki.ubuntu.com/SyncRequestProcess, but you don't want that directly - ask #ubuntu-motu for help
* cjwatson -> bed
<nrdb> I have what looks like a bug with the 'update-manager' I was upgrading from 6.06 -> 6.10 with vmware-player installed, once the download was done it the download manager displayed a terminal widget with a question in it, but I can't activate the widget to answer the question.
<bluefoxicy> at an estimate, can anyone give me a rough idea how big gatech's pool should be
<bluefoxicy> looks to me like they.. archive.. everything :(
<bluefoxicy> (I want a local edgy repo)
<bluefoxicy> other mirrors only have cd images of the last 2, but their dists/ contain ALL
<kylem> what part of that is relevant to the Development of Ubuntu
<kylem> hint: none.
<bluefoxicy> hmm.  Good point.
<bluefoxicy> (although who else is going to know how big every deb ever released by the ubuntu project combined is?)
<Lathiat> bluefoxicy: hint: debmirror
<bluefoxicy> o_o holy crap
* bluefoxicy leans over and kisses Lathiat on the cheek; then runs off to grab squid, squid rules, and nessus, and try to figure out what else he needs by friday morning
<bluefoxicy> Lathiat:  just a note, debmirror seems to download to .temp/ in the target directory, then try to verify i.e. Release in ./ instead of .temp/, then bail.  I'll file a bug; work-around is to not verify those files.
<Lathiat> your doing somethign wrong because it works fine for me
<Lathiat> what version?
<bluefoxicy> whatever's in feisty today.
<bluefoxicy> Malone 90546 has output
<Ubugtu> Malone bug 90546 in debmirror "debmirror fails to properly check Release(.gpg)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90546
<Lathiat> oh
<bluefoxicy> apt says 20060907.1
<Lathiat> gpg: Can't check signature: public key not found
<Lathiat> ^^^ thats not going to help
<Lathiat> gpg --recv-keys 437D05B5
<bluefoxicy> isn't that what it's downloading with Release/Release.gpg?
<Lathiat> no
<Lathiat> the .gpg is the detached signature
<bluefoxicy> ok I'll try that; if it works I'll revise the bug report to say this should probably automagically happen or something.
<bluefoxicy> ... which won't work either because gpg just says "oh.   ..... what?"
<bluefoxicy> this is dumb, I'm moving to #-bugs or #-offtopic with this
<kdean06> I'm trying to get in touch with an Ubuntu developer, anyone responcible for generating the alternative and server install discs specifically. Can anyone recommend where I might look to contact this person/people?
<Chipzz> I don't recall who exactly is responsable for generating these images, but he does hang around here
<Chipzz> just not at this hour
<kdean06> So it is one person specifically?
<Chipzz> not sure, but I think yes
<Chipzz> but these images get generated automagically
<Chipzz> except when doing beta-releases
<Chipzz> like herd etc
<Chipzz> Burgundavia: do you know who's resonsible for generating the cd images? live etc
<kdean06> I'm not concerned with any specific release, I really need to pique his/her brain about the process. I need to generate an image, but every process I've seen to date says to start with a current install disk and modify it, and that won't work, since I'm not sure of exactly what I'd be redistributing.
<Burgundavia> Chipzz: afaik, tollef is
<Chipzz> so that would be Mithrandir here
<Burgundavia> kdean06: what is your specific need?
<kdean06> I'd like to create an alternative/server install disc for the gNewSense project.
<Chipzz> 05:46 < kdean06> I'm trying to get in touch with an Ubuntu developer, anyone responcible for generating the alternative and server install discs  specifically. Can anyone recommend where I might look to contact this person/people?
<Hobbsee> it's Mithrandir, yes.
<Hobbsee> kdean06: seen germinate?
<Burgundavia> right
<Hobbsee> (and various other tools, which i dont remember)
<kdean06> I need to generate if from scratch, as I'll be distributing it, and need to also know which sources need to go with.
<kdean06> Germinate... I believe so, let me look at that again.
* Hobbsee notes there is a derivative team.
<Chipzz> but I do think gnewsense is not an official ubuntu release
<Chipzz>  /flavour
<Hobbsee> Chipzz: that's correct
<kdean06> Correct, it is not. And I don't expect support, simply hoping that I can get some expert advice. :D
<Chipzz> I'm guessing asking the gnewsense developers makes more sense
<Chipzz> since you also want to know which set of packages etc
<kdean06> They've got the LiveCD down pat, but they seem clueless to the d-i system (though it seems easier in theory).
<Chipzz> well if they have alternate/server images, someone is creating them, and it sure isn't tollef
<kdean06> They do not.
<Chipzz> ah and you also want to create alternate/server images
<Chipzz> well
<Chipzz> I'm not sure if that's the answer you're going to get, but someone was asking for the script to create live images here a couple of days ago, and he got told ubuntu doesn't open-source these
<Chipzz> they're not meant to be public. not sure about the alternate/server scripts though
<kdean06> That's sad. But I don't really need a script, just understanding. I'm figuring I'll be piecing together parts gleaned from Google, and the Debian Developers and perhaps tollef, if he's willing to help.
<Hobbsee> maybe cjwatson too
<Chipzz> well, there are instructions on the wiki on how to create a live cd, it's just that the official scripts aren't public
<Chipzz> but if you know enough you should be able to put 1 and 1 together and create such a script yourself
<Lathiat> a potentially easier option is to rebuilding an existing livecd
<Chipzz> but that was actually not his question anyway ;)
<Chipzz> (that was just meant as an aside :))
<kdean06> Well thank you all point the time of day. Have a good night/day. 
<kdean06> s/point/for
<srbaker> hey folks
<srbaker> is ubuntu's installer still based on debian-installer?
<srbaker> the livecd version?  or is this a new project all together?
<Hobbsee> srbaker: it's called ubiquity.  new project, iirc.
<srbaker> thx
<Fujitsu> It is a debian-installer frontend, basically. Most of the components are the same.
<Fujitsu> I think.
* Fujitsu checks.
<Fujitsu> Wait, no, it can't be.
<Fujitsu> Forget what I've said.
<Toadstool> er... afaik ubiquity actually is based on a deeply modified version of a d-i but the best person to ask is cjwatson :)
<Toadstool> s/a d-i/d-i/
<pitti> Good morning
<pitti> fabbione: right, yesterday I wanted to ask you whether there was any trick to add additional driver Options to xorg.conf (in restricted-manager) while remaining dexconf-compatible
<pitti> fabbione: but it seems not, so I started to implement support for it in dexconf itself instead of starting to do nasty hacks
<fabbione> pitti: i saw restricted-manager around as package, but no idea what it does... best is to use dexconf and look at nvidia-glx-config on how to preseed dexconf and run it
<pitti> fabbione: no, nvidia-glx-config doesn't do it eitehr
<pitti> fabbione: I think I answered my questions myself so far, but thanks anyway
<fabbione> pitti: ok :) i didn't get a royal clue but i am good.. and i am not sure i want to know
<tfheen> doko_: could we make ooo not depend on -binfilter to save heaps of space on the CD?
<tepsipakki> pitti: I'm interested in the result ;)
<pitti> tepsipakki: well, as I said, I'm going to implement 'extra driver options' support in dexconf
<tepsipakki> using debconf-templates?
<tepsipakki> so they are preseedable
<pitti> right
<pitti> I'm not going to ask this question interactively, but restricted-manager can set the debconf option and call dexconf to properly configure nvidia cards and such
<pitti> Option "AddARGBGLXVisuals" "True" and such
<tepsipakki> sounds about right
* pitti looks forward to doing two broken xorg uploads in a row :-p
<tfheen> pitti: just don't make it uninstallable. :-)
<tfheen> that was yesterday's problem
<pitti> *blush*
<dholbach> good morning
<tfheen> good morning, Daniel
<dholbach> hey Tollef
<Riddell> pitti: you didn't let through the edgy-proposed dist-upgrader packages?
<mdke> dholbach: can you do an upload of ubuntu-docs again today? Just to update all our strings for string freeze
<dholbach> mdke: ok
<mdke> thanks!
<dholbach> mdke: now? later?
<mdke> dholbach: whenever you have time
<dholbach> ok, doing it now
<mdke> :)
<tfheen> mvo: good morning.  Have you gotten any response to 69051 from upstream?
<tfheen> mdke: hiya, good to see you around.  You're still doing docteam stuff, right?
<dholbach> mdke: can you set DEBEMAIL=<something> on your machine?
<dholbach> mdke: Matthew East <matt@kalliope> is in the changelog
<dholbach> mdke: i'll change it locally and upload it - just fyi
<mdke> dholbach: whoops, thanks
<mdke> tfheen: sure
<dholbach> np
<mdke> tfheen: why do you ask?
<mvo> tfheen: no, but I added the patch to our package in the meantime, I will do another test and then close the bug
<tfheen> mdke: II'm wondering whom I should assing https://bugs.beta.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/89156 to.
<Ubugtu> Malone bug 89156 in ubuntu-docs "There is no mac-os-x.xml " [High,Confirmed]  
<dholbach> hey mvo
<tfheen> mdke: given that stringfreeze is today, it's kinda urgent.
<mdke> tfheen: i'll do that now
<tfheen> mdke: excellent, thanks.
<mdke> dholbach: don't upload!
<dholbach> mdke: ok
<mvo> hey dholbach
<mdke> tfheen: thanks for reminding me, even though I filed the bug myself, I still forgot
<pitti> Riddell: doing now
<mdke> dholbach: alright, go ahead (sorry!)
<dholbach> mdke: np
<pitti> Riddell: the kdebase upload has a change in kubuntu_76_ksmserver_suspend.diff which is not part of the approved patches
<pitti> Riddell: oh, oops, wrong debdiff (I compared to edgy, not edgy-updates)
<tfheen> doko_: about 59537; did you get this fixed or did you just work around it so the ooo build no longer triggers it?
<dholbach> mdke: uploading
<mdke> thanks dholbach
<dholbach> de rien
<pitti> carlos: how are the imports flowing?
<Lure> tepsipakki: latest ati upload caused regression on my laptop: bug 90571
<Ubugtu> Malone bug 90571 in xserver-xorg-video-ati "regression: blank screen on hp nw8240 after last xorg driver update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90571
<Treenaks> Lure: We were discussing it in #ubuntu-x :)
<carlos> pitti: slow :-(
<Lure> Treenaks: thanks, will join
<tfheen> cjwatson: did you end up having any luck with 59620?
<carlos> doko_: hi, around?
<dholbach> hey seb128
<seb128> hi dholbach
<seb128> hey carlos
<seb128> carlos: is the feisty .po import done?
<carlos> seb128: hi
<carlos> not yet, 19000 entries to go (from 70000...). We are going to deploy a small change to speed it a bit
<seb128> carlos: ok
<dholbach> tfheen: do you know what happened to the newest devhelp binaries on amd64?
<dholbach> tfheen: also could you give back gksu on amd64?
<Riddell> seb128: you didn't process NEW yesterday? :(
<siretart> will feisty ship bzr 0.15?
<tfheen> dholbach: I gave back gksu earlier today.
<tfheen> dholbach: devhelp> not sure, I'll look
<dholbach> tfheen: thanks a lot!
* dholbach hugs tfheen
<cbx33> sorry if this is the wrong place, but are Ubuntu doing GSoC this year?
<cbx33> If so who can I talk to about it
<seb128> Riddell: will do today, I did syncs, backports, and binary new
<cbx33> I have someone who wants to do a project, and I'm willing to mentor him
<tfheen> dholbach: gksu was waiting for libgksu which I just gave back.
<dholbach> ahhh ok
<tfheen> dholbach: devhelp binaries got lost in failed-to-move; rescuing.
<dholbach> yoohoo
<Riddell> seb128: you must be too thourough :)
<cjwatson> tfheen: still in progress, I'm trying to work out how to get the resize range using tune2fs - can't make the numbers agree with df
<cjwatson> tfheen: I'm not going to do it in parted; going to work around it in partman-partitioning roughly the same way it does for ntfs instead
<tfheen> cjwatson: ok, so you think it's doable for feisty?
<seb128> pitti: 
<seb128> dpkg: dependency problems prevent removal of python2.5-minimal:
<seb128>  python-minimal depends on python2.5-minimal (>= 2.5).
<seb128> dpkg: error processing python2.5-minimal (--purge):
<seb128>  dependency problems - not removing
<cjwatson> tfheen: hoping so, yes
<tfheen> mvo: why is 84612 fix commmitted and not fix released?
<seb128> pitti: that might have create problems on ~pitti/bin/retrace-i386
<cjwatson> tfheen: BTW there was a change in partman-base recently to fix NTFS resizing (previously, it sometimes tried to move the start of the partition and caused data corruption in some cases)
<mvo> tfheen: fixed, sorry
<cjwatson> I think I'll grab that, though I haven't decided whether I should just take all the changes in partman-base or whether I should backport instead
<tfheen> cjwatson: I trust your judgement on that. :-)
<cjwatson> this will also allow re-enabling resizing of Vista NTFS partitions
<tfheen> pitti: I'm looking at 81670 ; what, if anything, would break if we moved hal to 12?  (It seems to be that on some systems, like my laptop, which started out with warty)
<tfheen> mvo: https://bugs.beta.launchpad.net/ubuntu/+source/update-manager/+bug/69532 ; what's up with this?  It's old and looks more like a feature than a bug?
<Ubugtu> Malone bug 69532 in update-manager "CD dist-upgrade needs to be able to update itself from the net" [High,Confirmed]  
<mvo> tfheen: let me check
<tfheen> mvo: same with #68247, really.
<mvo> tfheen: updated #69532 (fixed in feisty)
<tfheen> great. :-)
<tfheen> doko_: about #85884 ; are you going to work on it for feisty?
<tfheen> pitti: why is ubuntu-release subscribed to 67925?
<seb128> bug #67925
<Ubugtu> Malone bug 67925 in Ubuntu "Do not ship translations without matching input support" [High,In progress]  https://launchpad.net/bugs/67925
<tfheen> mvo: what about 68247?  I don't see it as critical for feisty? (And it's a feature, not a bug)
<mvo> tfheen: that one is not yet fixed, but I agree its not critical for 7.04
<mvo> tfheen: I remove the target
<tfheen> mvo: cheers.  Got a few more minutes?
<tfheen> mvo: #70058 seems easy enough to fix
<tfheen> mvo: #74190 should be fairly easy too -- if the user has changed his umask so u-m can't read the file, just throw up an error dialog?
<pitti> seb128: I'll look at it
<pitti> tfheen: 81670> right, I was going to fix that soon; moving dbus to 12 should do fine, we had that in the past
<pitti> tfheen: it's just cupsys, hplip, and apport in between
<tfheen> pitti: ok, thanks.
<pitti> tfheen: 67925> because it affects CD layout; feel free to unsubscribe u-release, mdz forwarded the request to the bizdev team
<tfheen> pitti: I'm mainly trying to fix a bunch of the milestoned bugs.. beta freeze is only a week away.
<pitti> right, I got drawn off bugfixing for this restricted-manager stuff
<tfheen> pitti: how does it affect cd layout?  Doesn't it only affect the packages on there?
<pitti> tfheen: right, just the set of packages
<doko_> tfheen: I should, but probably lacking time
<tfheen> pitti: is there a spec to go along with this, or is it more a case of "this makes sense, let's just do it that way"?
<pitti> seb128: that was in the retracing chroots? weird, p2.5-minimal should have been part of the default debootstrap
<tfheen> doko_: ok, no point in having it milestoned for release, then.
<seb128> pitti: bug #90570
<Ubugtu> Malone bug 90570 in gnome-media "gnome-volume-control crashed with SIGSEGV after removal of creative audigy 2 zs notebook pcmcia soundcard" [Medium,Confirmed]  https://launchpad.net/bugs/90570
<seb128> pitti: retracing worked, it crashed after (on cleanup likely)
<pitti> tfheen: the latter rather; installing Chinese support with only translations, but without input support makes little sense
<pitti> seb128: ok, thanks
<seb128> pitti: np
<tfheen> pitti: I say we just go for it now rather than later
<pitti> tfheen: 'it'?
<tfheen> pitti: as in, fix the bug.
<pitti> tfheen: if I spend today and half of tomorrow on r-m, and monday to wednesday on milestone bug fixing, would that be ok?
<tfheen> pitti: that'd be great.
<pitti> tfheen: since r-m is feature-ish, it should go earlier
<tfheen> pitti: or are you waiting for feedback from bizdev on the input support bit?
<pitti> tfheen: input> right, the question is how to fix it
<pitti> tfheen: yes, I'm waiting for that
<tfheen> ok, any ETA?
<pitti> I didn't get one
<tfheen> ok
<tfheen> seb128: bug #86271 is going to be fixed with the GNOME release?
<Ubugtu> Malone bug 86271 in totem "needs to be updated for libtotem-plparser API change" [High,Fix committed]  https://launchpad.net/bugs/86271
<seb128> tfheen: yes, or I'll backport the patch which has been commited upstream otherwise, it's milestoned 7.04 so on my list of things to do
<tfheen> seb128: great, thanks.
<seb128> np
<tfheen> seb128: I won't nag you about it, then. :-)
<seb128> tfheen: k, if I've milestoned a desktop-bugs for 7.04 you probably don't need to not me about it, those are on my list of things to work on for feisty ;)
<shawarma> I'm confused. The new pbuilder still has the debian team listed as the maintainer in debian/control, so dpkg-source refuses to handle it... How did it make its way to the archive then?
<tfheen> seb128: thanks a lot.
<seb128> np
<cjwatson> shawarma: because that dpkg-source change is recent. If you upgrade dpkg-dev then it won't throw that error any more unless you have @ubuntu.com in DEBEMAIL.
<shawarma> cjwatson: Er... ok.
<shawarma> cjwatson: ...no, still don't get it. :-)
<shawarma> cjwatson: You're saying this is behaviour by design?
<cjwatson> shawarma: I'm saying that it got into the archive because when it was uploaded dpkg-source didn't emit that error
<cjwatson> shawarma: for further information, see http://wiki.ubuntu.com/DebianMaintainerField
<shawarma> cjwatson: It doesn't mention this new DEBEMAIL exception?
<pitti> indeed not, I'll add it
<shawarma> Just to be sure: It shouldn't have made it to the archive, should it?
<cjwatson> yes, it should have made it to the archive.
<pitti> shawarma: it should
<shawarma> Ok.. 
<pitti> shawarma: this policy is recent, it hasn't been enforced for a long time
<cjwatson> in any case 'apt-cache show pbuilder' shows an Ubuntu maintainer address here
<cjwatson> oh, that may not be in the source, ok
<cjwatson> (sorry, red herring)
<pitti> right, binary packages' Maintainer fields have been mangled for longer
<shawarma> Yes, but fetching the souce and looking says otherwise.
<cjwatson> shawarma: like I say, red herring, sorry
<pitti> wiki updated
<cjwatson> shawarma: it made it to the archive because it was constructed with a version of dpkg-source that did not enforce this check. That's just fine.
<shawarma> Ok. So Debian is fine with our source packages listing them as the maintainer?
<cjwatson> No.
<pitti> shawarma: no, you must change it
<cjwatson> we are progressively going through and fixing packages, but it is not complete yet.
<pitti> shawarma: guess what the dpkg check is for :)
<shawarma> pitti: Precisely.
* shawarma looks at his confus-o-meter. It's off the scale..
<cjwatson> shawarma: it is *simultaneously* OK that it made it to the archive (before the check was enforced) and a bug that it's still that way.
<shawarma> cjwatson: Oh!
<cjwatson> shawarma: if you'd asked "should it be like that" rather than "it shouldn't have made it to the archive, should it?", you'd have got a different answer
<pitti> cjwatson: is there a trick how to store multi-line string values in debconf?
<shawarma> cjwatson: Right, now I get it. mvo just mentioned it on the m-l today, so I thought it was just uploaded. I didn't notice the upload was a week old.
<tepsipakki> is there a systematic way to get updates for discover-data?
<tfheen> tepsipakki: "sync from debian"?
<pitti> cjwatson: I tried with 'foo\\nbar', with that, config.dat has 'foo\bar', but it only returns 'foo' when querying it
<tepsipakki> tfheen: ah.. I was looking at discover1-data, which is ancient :)
<tepsipakki> discover-data is much newer
<tepsipakki> tfheen: could it be synced?
<mvo> shawarma: I mentioned it late because I wanted to give it some testing before announcing it :)
<tfheen> tepsipakki: I can never remember which one of those we use, but I believe it's discover1-data
<tepsipakki> tfheen: looking at the version numbers it's discover-data
<tepsipakki> which builds discover1-dataa
<tepsipakki> -a
<tepsipakki> the current version lacks information about intel vga-controllers, they all seem to use vesa atm
<shawarma> mvo: Makes sense. :-)
<tfheen> tepsipakki: request a sync, subscribe ubuntu-release.
<tepsipakki> tfheen: will do
<tfheen> tepsipakki: include information as per https://wiki.ubuntu.com/FreezeExceptionProcess
<tepsipakki> yes, it has a vast number of fixes for various graphics controllers
<tepsipakki> nv, intel, via..
<cjwatson> pitti: man debconf-devel and search for escape
<cjwatson> pitti: needs debconf (>= 1.4.72)
<pitti> cjwatson: ah, I found that, but I couldn't make sense of it
<tepsipakki> *.bugs.launchpad.net hates me obviously..
<pitti> cjwatson: I have to *set* CAPB, it's not something that debconf returns?
<cjwatson> pitti: correct
<pitti> ah, great
<pitti> cjwatson: thanks
<cjwatson> the client needs to be prepared for this
<cjwatson> note that db_capb *replaces* the current capability set, so if you also want backup you need to say 'db_capb backup escape'
<cjwatson> generally best to turn off escape when you don't need it any more
<tfheen> sladen: why is Bug #14908 just marked as fix committed and not fix released?
<Ubugtu> Malone bug 14908 in powermanagement-interface "use 'do-not-hibernate' NOT 'do-not-suspend' to prevent hibernate following kernel upgrade" [Medium,Fix committed]  https://launchpad.net/bugs/14908
<seb128> tfheen: could you look at bug #90594?
<Ubugtu> Malone bug 90594 in libxklavier "UVF exception 3.0 to 3.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90594
<tfheen> seb128: looking
<seb128> tfheen: refresh if you want, I've attached a new diff with the code changes only (without the documentation and autotools update)
<seb128> tfheen: the function which changed are private API, there is no public API change
<tfheen> seb128: approved.
<seb128> tfheen: thank you
<pitti> tfheen: I need this new feature for the restricted-manager stuff (particularly for bug 90109, but I wanted to keep it generic); http://people.ubuntu.com/~pitti/patches/xorg.extra_options.diff
<Ubugtu> Malone bug 90109 in xorg "Add Alpha RGB GLX Visuals to xorg.conf for nVidia cards" [Medium,In progress]  https://launchpad.net/bugs/90109
<pitti> tfheen: ok to upload? (eyeballing appreciated as well, of course)
<doko> tfheen: do we have results for rebuild tests
<dholbach> doko: I asked on the mailing list too - seems that elmo and infinity know more about it, since mdz CCed them
<dholbach> doko: let's see what comes out of the discussion
<tfheen> doko: no, I haven't received them.  I've nagged repeatedly, but will do so again.
<tfheen> pitti: yes, looks decent enough.
<tfheen> pitti: (approved)
<pitti> thanks
<doko> tfheen: well, I had my own live rebuild for 500 packages ;)
<tfheen> doko: I noticed.
<tepsipakki> pitti: the howto's I've seen put the settings in "Screen"
<pitti> tepsipakki: that would be weird
<heno> ogra: do you have any test cases in mind for the add-on CD (CD integrity and Winfoss testing I have). Just 'install extra packages'?
<tepsipakki> pitti: nvidia-config does that
<pitti> tepsipakki: I put it in Device, and that seems to work fine for my nvidia card
<pitti> hm
<tepsipakki> maybe it work
<tepsipakki> 's
<pitti> tepsipakki: I don't get window decorations without the option, and with the option in Device it works
<pitti> hm
<tepsipakki> maybe it's a weird driver ;)
<tepsipakki> http://www.go-compiz.org/index.php?title=NVidia
<tepsipakki> it's cleaner if it works under Device
<pitti> right, maybe its propagated somehow
<pitti> it just seems more logical to put it in Driver since it seems to be nvidia specific?
<pitti> and it's an undocumented option in xorg.conf
<tepsipakki> just put it there, i810 seems to use the Driver
<pitti> tepsipakki: oh, that nvidia page lists two more options that are needed
<Treenaks> pitti: they're not needed here..
<tepsipakki> yeah, maybe that page is a bit outdated
<pitti> Treenaks: neither here, but 'RenderAccel' sounds more like 'nice to have'
<pitti> Treenaks: "AllowGLXWithComposite" -> does OpenGL work for you with compiz enabled?
<Treenaks> pitti: yes.. hmm.. but I have that one in my config file
<Treenaks> Why is that a config option anyway..
<Treenaks> _of course_ you want that
* pitti breaks his wm again by enabling compiz to test this
<tfheen> mvo: can I nag you about #75882 as well?
<Hobbsee> heya tfheen 
<tfheen> hiya Sarah.
<mvo> tfheen: let me check
<pitti> gosh, I know I complained loudly about lack of 'snapping' when moving/resizing windows - but now it is so snappy that I cannot move it *at all* any more
<pitti> Treenaks: hm, glx works for me without this option
<Treenaks> pitti: ok..
<pitti> Treenaks: btw, is there any way I could continue to use ctrl+alt+left/right to switch desktops?
<Treenaks> pitti: I do so.. so yes
<Treenaks> pitti: enable the cube, then it works automatically for me
<pitti> Treenaks: doesn't make a difference
<tepsipakki> cube doesn't work at all for me
<pitti> I get no cube with this either on or off, enabling compiz collapses all my windows to the first desktop, so I move them back, and I can't switch them with the keyboard
* pitti wonders how people don't get crazy with these jumping and fading menus
<tfheen> pitti: they take drugs against craziness.
<seb128> the fading is quite nice
<Treenaks> pitti: maybe you should reset /apps/compiz in gconf?
* pitti imagines how vim-composite would like, with every letter bouncing
<Hobbsee> pitti: they get over it, then disable it.
<Hobbsee> hhaa
<seb128> pitti: it doesn't bounce much, maybe you have some gconf weird values?
<seb128> pitti: gconf --recursive-unset /apps/gconf
<seb128> ups
<seb128> /apps/compiz
<seb128> graaa
<seb128> gconftool --recursive-unset /apps/compiz
<seb128> I mean
<doko> tfheen: OOo had a disagreement with pkgstriptranslations, resulting in an empty translation tarball; have to upload again. could you hint the i386 build to palmer?
<pitti> seb128: ah, thanks; manually unsetting them is a pain
<seb128> np
<pitti> seb128: I take it I have to restart the session now?
<tfheen> doko: ugh, yes, I could.  Tell me when you upload?
<doko> tfheen: will do
<tfheen> doko: that is, when it's uploaded.
<pitti> brb
<pitti> seb128: ah, now I can switch desktops again, thanks; edge resistance is gone, too, though
<pitti> well, with xchat at least (I think it didn't work with it before either)
<seb128> pitti: just restart compiz should be enough
<pitti> seb128: menus are still bouncy and slowly fading
<seb128> pitti: you need to activate wobbly to get edge resistance, there is a bug about that
<pitti> seb128: I do have that enabled
<seb128> k, dunno then, that's a bug
<seb128> pitti: https://launchpad.net/bugs/73700
<Ubugtu> Malone bug 73700 in compiz "Lacks edge resistence" [Low,Confirmed]  
<pitti> seb128: hm, gaim <-> gnome-terminal window snapping works, but not xchat <-> xchat
<ogra> heno, popping it in and checking that g-a-i does the right thing ois enough for the add-on Cd ... 
<ogra> for4 winfoss the regulart winfoss testing procedures (if you have any) should apply
<heno> ogra: ok, thanks
<doko> tfheen: OOo uploaded
<tfheen> doko: cheers.
<Keybuk> interesting GPG vulnerability there
<Keybuk> afaict, Evolution is unaffected as it already takes care to separate parts?
<mooey> seb128, is the sebastien mentioned at the end of bug 90439 yourself? if so, do you want it assigned to you?
<Ubugtu> Malone bug 90439 in gnome-launch-box "gnome-launch-box 0.2 is out" [Undecided,Needs info]  https://launchpad.net/bugs/90439
<Hobbsee> mooey: that'd violate freeze, to put it in
<mooey> Hobbsee, i mentioned that in the ticket
<mooey> erk, bug report *
<Hobbsee> ah
<ogra> mvo, somehow your gdebi pbuilder script doesnt work over here ...
<cbx33> ogra: you there?
<cbx33> quick question
<cjwatson> tfheen: present for you, dropping gparted/qtparted from the live CDs
<mvo> ogra: oh? you have the latest gdebi/pbuilder/python-apt
<Ixan> hmm.. need some tips on debugging here. Booting herd 5 iso, but the installer exits to busybox almost immediatly. reporting "udevd-event[2004] : run_program: '/sbin/modprobe' abnormal exit". 
<tfheen> cjwatson: \o/
<mvo> ogra: do you get any error message?
<tfheen> cjwatson: you rock.
<ogra> mvo, hmm. python-apt wasnt updaed ... but the others were ...
<ogra> let me do that ...
<ogra> cjwatson, sad, its a helpful system recovery/maintenance tool ...
<mvo> ogra: what arch?
<cjwatson> ogra: easy enough to install from applications -> add/remove...
<ogra> mvo, i386
<ogra> cjwatson, indeed ... 
<cjwatson> ogra: at any rate, if somebody really wants it back, it can be seeded - just that ubiquity no longer requires it
<ogra> i agree with its exclusion ...
<ogra> its just that many people will be unhappy .... one of knoppix' biggest advantages was always the inclusion of such stuff ...
<ogra> but hey, you cant have everything :)
<cjwatson> seriously, feel free to put it back. I'm not responsible for it any more that's all
<seb128> mooey: no, not me, probably slomo
<mooey> seb128, hokay, ty
<seb128> np
<slomo> mooey: yes, herzi meant me... i'll look at it later today but if you want to update the package feel free to do it :)
<mooey> slomo, packaging is beyond me :-) i'll move the bug over to yourself
<heno> gparted can help mildly experienced people fix stuff, but can also help very inexperienced people break everything
<pitti> tfheen: ok, dbus with new runlevels fixed/tested/uploaded
<pitti> slomo: I'll commit your avahi upload to the LP bzr now; can you please use the bzr branch in the future?
<slomo> pitti: sure
<tfheen> pitti: yay you. :-)
<heno> doko: the new OOo looks lovely :)
<Treenaks> it's lots faster too
<heno> it does feel snappy, yes
<Treenaks> and for some reason it lists /dev/.static/dev in the file -> open menu
<doko> thanks
<Treenaks> instead of /
<Treenaks> uhr.. file open dialog, not menu
<geser> tfheen: have you looked already at the fuse UVF?
<Treenaks> doko: is there a 'short changelog' from upstream? with notable fixes/features?
<doko> heno: there are some crashes reported in libgail, didn't look at it yet
<doko> Treenaks: yes, the release notes in my mail to -devel (or -devel-discuss)
<Treenaks> doko: hmm.. *checks mailinglist subscriptions*
<heno> ok, I guess that's expected. updates of almost any package tends to break a11y support a bit
<seb128> tfheen: could you give a build retry to totem?
<seb128> ogra: I'll update gnome-screensaver with that patch for mouse change
<_ion> The Ubuntu Weekly News feed at http://fridge.ubuntu.com/uwn/feed seems to be outdated. It lists issue #28 as the newest one. Where should i report this?
<jsgotangco> try #ubuntu-doc there might be a fridge editor online
<jwendell> dholbach_, i need your help. are you around?
<_ion> Ok, thanks
<saispo> hi, anyone know if it's possible to have a repository with alphabetical order such as ubuntu with mini-dinstall ? or i must use other programs ? thks
<mvo> seb128:  I'm looking into verifying bug #73021 what steps are required to make it crash?
<Ubugtu> Malone bug 73021 in nautilus "fm_tree_model_unref_node fails ref_count > 0 assert" [High,Fix committed]  https://launchpad.net/bugs/73021
<seb128> mvo: no idea
<seb128> mvo: there is just some hundred dups upstream
<mvo> seb128: hm, that is a problem with the current verification process. when "crashes-randomly" bugs get fixed :)
<Treenaks> mvo: well, the fix must hint at where the problem is, and make it easier to reproduce that?
<seb128> mvo: feel free to reject it, upstream asked for it because they got hundred of dups
<seb128> Treenaks: race condition are not always easy to trigger
<Treenaks> seb128: good point
<mvo> seb128 rejecting seems a bit much
<seb128> mvo: well, I've no way to trigger the crash and if that's required we are stucked
<seb128> mvo: either you accept or reject it, your call ;)
<dholbach_> jwendell: I can try
<seb128> dholbach: do what?
<dholbach> seb128: <jwendell> dholbach_, i need your help. are you around?
<ivoks> seb128: what are you doing on 31st of march? :)
<jwendell> dholbach, i've got a package with no patches dir, wich doesn't use cdbs. How can i patch that package? How can i proceed?
<seb128> ivoks: enjoying a saturday far from computers after a week of Ubuntu work, why? ;)
<dholbach> jwendell: you can use dpatch
<ivoks> doh... :)
<ivoks> seb128: we are planing a conference in croatia, so if you are interested..
<jwendell> dholbach, will dpatch create a new patches dir and files like 01_patch_something.patch like cdbs does?
<dholbach> jwendell: install dpatch and check out /usr/share/doc/dpatch/examples/rules/rules.new.dh.gz for an example
<dholbach> jwendell: yes
<seb128> ivoks: thanks, but no thank you, I feel like doing computer break during the WE atm, and we already some Ubuntu confs coming, GUADEC, etc
<ivoks> ok :/
<ivoks> these gnome guys... :)
<cjwatson> tfheen: bug 89461 milestoned for beta; I have a fix in hand, just need to test it
<Ubugtu> Malone bug 89461 in ubiquity "system-partitions-formatted validation missing from new partitioner" [High,Confirmed]  https://launchpad.net/bugs/89461
* mvo wants bigger fonts in beta.lp.net
* seb128 want fast beta.lp.net
* mvo wants that too ... and icecream!
* tepsipakki joins the crowd
<Treenaks> and a pony!
<mvo> we have a pony!
<torkel> and sun instead of snow
<seb128> OOPS-432BC619
<seb128> mvo: it used to work on that chan, bot is probably not happy or something :p
<seb128> I got a OOPS-432D1433
<Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/432D1433
<mvo> seb128: thanks, looks like it is not happy with my oops 
<seb128> mvo: yeah, it doesn't like the number
<ogra> seb128, you mean the xnest one ? 
<seb128> ogra: yep, I've the package ready to upload
<ogra> great ! :)
<seb128> and I tested it fixes xnest and an another bug we had open about a game being broken
<mooey> pochu, you were right about that mozilla bug
<mooey> somebody from the mozilla team unrejected it and set it to needsinfo =)
<pochu> hehe
<pochu> mooey: I'm always right :-P
* mooey bows
<mooey> i am not worth
<mooey> +y
* pochu searches 'bows' in the dictionary :)
<pochu> hehe :)
<bddebian> Heya
<tfheen> geser: no, sorry, I haven't
<tfheen> seb128: given-back.
<seb128> tfheen: thank you
* tbf wonders why the gtk+ package on edgy is called libgtk2.0-0, but not libgtk2.0
<tbf> seb128: why that name?
<seb128> 0 is the soname version
<seb128> we do that so we can ship different packages which don't conflict when the soname change
<ogra_> there is a recent thread on the debian-gtk-gnome list about it
<seb128> all the libs have that version to the package (or should have)
<tbf> ok.
<jwendell> dholbach, will dpatch create a new patches dir and files like 01_patch_something.patch like cdbs does?
<pitti> jwendell: yes, it will
<dholbach> jwendell: I answered that question with yes already :-)))
<jwendell> dholbach, sorry
<dholbach> jwendell: install dpatch and check out /usr/share/doc/dpatch/examples/rules/rules.new.dh.gz for an example
<pitti> jwendell: just make sure to add new patches to debian/patches/00list
<jwendell> dholbach, pitti it was supposed to be /clear :)
<pitti> jwendell: https://wiki.ubuntu.com/MOTU/School/PatchingSources
<j1mc> greets, somerville32
<pitti> kylem: would you be fine with doing the i386/alternate test cases instead of amd64 on https://wiki.ubuntu.com/Testing/Matrix?
<kylem> yeah, that's not a problem.
<pitti> kylem: my quota limits the number of architectures I can download
<pitti> kylem: thanks; I'll swap that on the wiki page then
<somerville32> Hi j1mc :)
<kylem> pitti, ok. np.
<j1mc> somerville32 how are you doing lately?  i hope you're getting better.
<somerville32> j1mc: I'm doing better. Still in the hospital but doing better :)
<j1mc> somerville32 good to hear
<pitti> dholbach, mdz: I'd like to swap your alternate/rescue test on amd64 with the i386 one assigned to me
<dholbach> pitti: fine with me
<pitti> thanks
<kylem> pitti, i can test whatever, it's not a big deal for me to grab stuff.
<seb128> urg
<seb128> why do I get all the DVD installations?
<seb128> I don't have the bandwith for syncing those
<tfheen_> seb128: I'll swap you those for whatever I have
<tfheen_> my DSL needs exercise.
<seb128> tfheen_: you have nothing
<seb128> how come?
<tfheen_> I only have DVD live session, it seems
<seb128> only DVD live session on amd64
<seb128> yeah
<seb128> slacker :p
<tfheen_> indeed. :-)
<tfheen_> but feel free to give me the DVD cases
<seb128> tfheen_: if you want to take the amd64 DVD that would be nice
<seb128> I can do i386
<tfheen_> sure
<seb128> thank you
<pitti> mvo, ogra_, seb128: so, as proud ATI card owners, could you please send me some recipes how to turn a virgin Ubuntu installation (with the free ati driver configured) into an fglrx one? (packages, special xorg.conf options, other changes)
<ogra> pitti, binaryDriverHowto ? 
<pitti> ogra: that is still fully valid for feisty?
<ogra> thats what i would follow :)
<ogra> dunno ...
<mvo> pitti: sure, but my machine does not work with the free ati driver, vesa is the only altenative
<seb128> pitti: install xorg-driver-fglrx and change use fglrx instead of ati to xorg.conf
<pitti> well, I'd rather have a tested recipe
<ogra> my card runs with fglrx if i want to, but i never really wanted ;)
<pitti> seb128: that's it? no special driver options and such?
<seb128> no
<pitti> great
<pitti> that should be easy enough then
<seb128> I don't use fglrx, dunno about tweaking options for speedup, etc
<seb128> doing that works fine to run fglrx
<mvo> AFAIK there are special options reqiured
<mvo> at least it was the case for edgy
<mvo> I will recheck for feisty
<pitti> mvo: thank you
<seb128> works without option for me
<ogra> you had to switch off AIXGL
<ogra> err AIGLX
<seb128> ok, I'm away for ~1 hour for sport, bbl
<pitti> I'll implement seb128's basic steps for now, they are necessary in any case
* mvo knows all aobut the flglrx pain as its his only option
<mvo> have fun seb128
<seb128> I'll reply when I'm back if you need anything
<seb128> mvo: thank you
<Seveas> pitti, don't forget to switch of composite...
<tbf> seb128: just 1hour?
<pitti> Seveas: how does that translate into an xorg.conf Option?
<tbf> not quite much
<Seveas> Section "Extensions"
<Seveas>     Option  "Composite" "0"
<Seveas> EndSection
<seb128> tbf: enough for some exercice ;)
<mdz> pitti: that's fine
<pitti> Seveas: ugh, is that part of a default xorg.conf? it's not in mine (I have nvidia, though)
<mvo> pitti: no, its not part of the default config
<pitti> Seveas: ah, you have to add the entire section yourself? that's painful, dexconf-wise
<pitti> mvo: can it be specified in the Driver section as well?
<Seveas> fglrx is painful
<mvo> pitti: AFAIK not
<pitti> urgh, that cries for more dexconf work
<mvo> pitti: we could use the guidance backend for xorg.conf manipulation
<mjg59> It would make more sense to fix X
<mjg59> Can you confirm that it's necessary for current fglrx?
<mvo> no, I need to test that
<mvo> it used to be, but I set it up with edgy, haven't tried with latest feisty yet
<Seveas> there was no indication in ATI changelogs that it's no longer necessary
<mjg59> Adding extra options to xorg.conf in the installer is almost always the wrong answer
<Seveas> fglrx needs to be fixed
<mjg59> Well, fundamentally, yes
<mjg59> But we can't do that
<Seveas> let's test if it's still neccessary, brb
<ogra> mjg59, while youre around, any do you have idea about bug 81227 ?
<Ubugtu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,Confirmed]  https://launchpad.net/bugs/81227
<ogra> i'm sure one of the events has to vanish, i'm just not sure which one
<Seveas> (II) fglrx(0): Composite extension enabled, disabling direct rendering
<Seveas> (WW) fglrx(0): ***********************************************
<Seveas> (WW) fglrx(0): * DRI initialization failed!                  *
<Seveas> (WW) fglrx(0): * (maybe driver kernel module missing or bad) *
<Seveas> (WW) fglrx(0): * 2D acceleraton available (MMIO)             *
<Seveas> (WW) fglrx(0): * no 3D acceleration available                *
<Seveas> (WW) fglrx(0): ********************************************* *
<Seveas> so yeah, still neccessary
<pitti> bah, this is ugly
<pitti> Seveas: thanks for testing, though
<pitti> Keybuk: oh, I just saw that there's no r-m infrastructure yet to detect whether a driver can be loaded in the first place, right?
<Keybuk> right
<pitti> Keybuk: like, disabling nvidia stuff on ATI cards and vice versa
<mjg59> pitti: They won't be loaded unless something asks for them to be loaded
<pitti> mjg59: well, but if we install nvidia-glx and set driver to nvidia in xorg.conf, although the user has ATI, that would be pretty bad
<pitti> and is in fact what happened to me on my laptop
<mjg59> Why are conffiles being edited on package installation?
<pitti> mjg59: they are not
<mjg59> Oh. 
<pitti> mjg59: restricted-manager changes them when the user enables/disables a driver
<pitti> also, xorg.conf is not a conffile
* pitti -> back in 20 minutes
<delire_> i have a couple of pretty basic questions regarding modding for ioquake3 on Linux. i'm changing cvars - even removing them altogether - manipulating weapons, yet i never see the effects in game. the cvars are there and the weapons are unaltered. i've run a make clean and copied the entire baseq3 directory from the build directory into my fs_game path (ie ~/.q3a/modname/baseq3) and am running it with ioquake3 +set fs_game +devmap 
<delire_> oops
<delire_> sorry about that all.
<kaktuspalme> Hi
<kaktuspalme> a new cups package or a lib cups package, has disabled lpr in feisty fawn
<kaktuspalme> oh sorry
<Riddell> pitti: adept in edgy-proposed failed to compile :(
<Riddell> pitti: it's just autotools breaking, I think I ran the autoconf buildprep on feisty
<Riddell> pitti: this patch fixes it http://kubuntu.org/~jriddell/tmp/adept.debdiff
<pitti> Riddell: ok
<Riddell> pitti: I'll upload
<pitti> I'll look in the queue in 10 minutes
<pitti> Seveas, mvo, seb128: can you send me a mail or pastebin with your lspci output?
<Seveas> pitti, http://paste.ubuntu-nl.org/9266/
<mvo> pitti: the full one? or just the VGA line?
<mvo> pitti: nevermind, http://paste.ubuntu-nl.org/9267/
<pitti> Seveas, mvo: thanks
<j1mc> i'm having a hard time finding the bug pertaining to kubuntu amd64 partitioning problems.  it was present right up prior to herd 5.  has that been fixed?
<Riddell> j1mc: "the bug" is a bit unspecific, there was a bug in the new manual partitioner that stopped most edit and create operations which I fixed
<j1mc> Riddell: thanks . . . 
<j1mc> Riddell: that is what i was referring to, manual partitioning problems in kubuntu on AMD 64.
<Riddell> pitti: don't forget adept :)
<pitti> Riddell: done
<kaktuspalme> in the new cups hasn't got lpd
<kaktuspalme> the new cups package
<kaktuspalme> isn't this channel for such problems?
<Athensman> has anyone here had any problems installing XuBuntu???
<pitti> kaktuspalme: no, please file a bug against cupsys ('ubuntu-bug -p cupsys' preferably)
<kaktuspalme> pitti, ok thx
<pitti> ogra_: would you have some minutes to test my first cut at ATi support in restricted-maanager?
<Athensman> has anyone here had any problems installing XuBuntu???
<Riddell> Athensman: -> #xubuntu
<pitti> anyone else with an ATI card and some minutes to test restricted-manager?
<johanbr> pitti: yes. What do you want tested, specifically?
<Lure> pitti: I can (using ati now)
<pitti> johanbr, Lure: bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/restricted-manager/trunk/
<pitti> johanbr, Lure: I would like to test whether, starting from a virgin situation (i. e. free ati driver configured and no custom changes in xorg.conf), restricted-manager can correctly configure the restricted fglrx driver
<Lure> pitti: I just have three additional lines in Monitor (needed due to recent regression)
<pitti> Lure: ok; r-m backs up your xorg.conf
* Lure is pulling depends of - is running on kubuntu and no pygtk ;-)
<pitti> Lure: if you added them manually, it'll clobber them; if you used dpkg-reconfigure xserver-xorg, it should be fine
<pitti> Lure: oh, sorry :)
<Lure> pitti: no problem
<pitti> Lure: apt-get install restricted-manager is probably the easiest way to do that
<Lure> pitti: that is what I am doing...
<Lure> pitti: does it install fglrx packages or just change xorg.conf?
<pitti> Lure: both
<pitti> Lure: and if you disable the driver, it removes the fglrx package again
<Lure> pitti: installing might not work ok kubuntu - what do you use to install package
<pitti> Lure: ah, right, synaptic
* pitti adds a dependency
<Lure> pitti: you need to fix depends - "import gnome"
<johanbr> pitti: First problem: "Must be run as member of admin group". My user *is* a member of the admin group. Same result when running as root.
<Lure> pitti: which package am I missing?
<pitti> Lure: ah, /me adds python-gnome2 as well, thanks
<pitti> johanbr: ah, right; please apt-get install restricted-manager
<pitti> johanbr: that will take care of creating the /var directory, as well as give you the icons
* Lure is getting bunch of gnome packages on his clean Kubuntu ;-(
* Lure has another reason to try Beta from fresh install ;-)
<pitti> Lure: I guess apt-get remove --purge libglib2.0-0 should clean up pretty much everything afterwards
<Lure> pitti: no problem, I am just joking...
<Lure> pitti: but thanks for the tip ;-)
<Lure> pitti: it will take some more minutes - main archive is slow for me (10-20K/s)
<Lure> pitti: another depends missing: import egg.trayicon
<pitti> Lure: python-gnome2-extras, thanks
* Lure gets even more gnome stuff...
* Lure is expecting lots of fancy stuff in r-m with all this dependancies ;-)
<pitti> Lure: it's all part of the s3kr3t gnome world domination plan
<Lure> pitti: lol
<johanbr> pitti: Alright, have to restart X. Just a minute.
<Lure> pitti: 
<Lure> ./restricted-manager:45: DeprecationWarning: the module egg.trayicon is deprecated; equivalent functionality can now be found in pygtk 2.10
<Lure>   import egg.trayicon
<Lure> pitti: do I need gtksu or is sudo or kdesu ok?
<pitti> Lure: sudo is okay
<pitti> Lure: I get that warning as well, ignore for now
<pochu> heya mbiebl :)
<Lure> pitti: I have bunch of Fritz cards marked as Enabled. Is this OK?
<pitti> Lure: yes
<pitti> Lure: 'Enabled' means 'allow', not 'in use'
<Lure> pitti: crash on Enable ATI: http://paste.tonio.homelinux.org/69
<mbiebl> pochu: hi
<pitti> Lure: oh, that called synaptic
<pochu> mbiebl: I've closed some tracker bugs - 0.5.4-4 has been successfuly uploaded
<pitti> Lure: bzr head has the dependency now
* Lure installing synaptic
<pochu> pitti: does r-m installs the intel propietary drivers? :-P
<pitti> Lure: sorry :/
<pitti> pochu: the WHAT?
<pochu> hehehe
<mbiebl> pochu: cool, thanks
<pitti> *phew*
* pochu would like to test :(
<pitti> pochu: don't scare me like this
<Lure> pitti: nopb, btw is this written to be able to add PyQt4 backend easily?
* pochu laughs
<pitti> pochu: really? if you have an Intel card, then you can rest in piece and be happy with free software ;)
<pochu> pitti: or I can develop my own drivers, and release them as closed source :)
<pitti> Lure: the backend stuff is UI agnostic, but the GUI itself needs to be rewritten
<pochu> pitti: then you could add them to r-m ;)
<Treenaks> pitti: well... you could consider the ipw39xx things restricted :)
<tepsipakki> intel works OOTB with compiz
<tepsipakki> in feisty
<Lure> Treenaks: they are listes in r-m
<Lure> s/listes/listed/
* Treenaks tries
<pitti> Lure: right, the wifi ones
<pitti> Lure: so, at least you saw the fglrx driver in the list, and you didn't see the nvidia ones?
<khermans_> isn't /tmp supposed to be cleaned up on reboot automatically?
<Lure> pitti: synaptic is downloading something...
<pitti> khermans_yes
<khermans_> i think it is a bug that files get deleted, but not directories
<pitti> Lure: if the ATI/nvidia check worked correctly, that's already progress :)
<Lure> pitti: suprise: it is fglrx package ;-)
<khermans_> pitti, do you see the same thing?
<pitti> khermans_: actually not
<khermans_> pitti, why not?
<khermans_> pitti, it used to be that way
<Lure> pitti: main window is blocked when synpatic runs, but you probably already know that
<johanbr> pitti: No luck. Tried enabling fglrx twice, there's a trace at http://nullinfinity.org/tmp/log . The second enabling attempt begins at the line starting "debconf:".
<pitti> Lure: right, UI detail
<pitti> johanbr: ah, that's helpful
<pochu> Treenaks: http://ipw3945.sourceforge.net/ <--- isn't it open source?
<kylem> pochu, needs a binary userspace daemon.
<ivoks> right
<khermans_> pitti, can you explain why /tmp cleanup is not a bug in new kernel?
<khermans_> in feisty ... 
<pitti> khermans_: it should be cleaned up; if not, please file a bug against sysvinit
<pitti> johanbr, Lure: I fixed johanbr's exception, please do 'bzr pull' (in trunk/)
<khermans_> pitti, you said not removing directories was not a bug
<khermans_> ok i will file it
<pitti> khermans_: no, I meant that it is a bug
<pitti> khermans_: <pitti> khermans_: actually not -> that was for 'do you see the same thing?'
<pitti> johanbr: it seems you have a stale debconf process somewhere? 'DbDriver "config": /var/cache/debconf/config.dat is locked by another process'
<johanbr> pitti: I think that's 'cause I already clicked on "Enable" once.
<pitti> right, I was just about to say that
<johanbr> pitti: With the bug fix, fglrx is already listed as "Enabled" but not "In use". I can click under "Enabled" to disable the driver, but clicking under "In use" does nothing. Is that the way it's supposed to be?
<pochu> luckily I have ipw2200 :)
<pitti> johanbr: yes; 'in use' would be on after you restarted X with fglrx being, well, 'in use'
<pitti> johanbr: can you check your xorg.conf?
<johanbr> pitti: Okay. But r-m doesn't seem to have done anything to xorg.conf.
<pitti> johanbr: enabling installs the fglrx package, disabling uninstalls it again, and xorg.conf has the correct driver (ati/fglrx) in both cases?
<Lure> pitti: after download, I got this: http://paste.tonio.homelinux.org/70
<pitti> Lure: right, johanbr had this as well; please 'bzr pull' for the fix
<johanbr> pitti: Enabling/disabling doesn't seem to install/uninstall anything. Also, xorg.conf stays the way I configured it, with the "ati" driver.
* Lure is lagging ;-)
<pitti> johanbr: hmm
<Lure> pitti: now is enabled, but not in use - will restart X to see if I get back
<johanbr> pitti: Now it uninstalls fglrx, when I restarted r-m. Weird! 
<pitti> johanbr: if you start r-m, is it shown as enabled or disabled? and which driver do you use in xrog.conf ATM?
* Lure restarting -> brb
<pitti> johanbr: you mean it uninstalled fglrx right after starting, without clicking anything??
<johanbr> pitti: No, it was listed as "Enabled" and I clicked. :)
<pitti> johanbr: ah *phew*
<pitti> Lure: wb :)
<Lure> pitti: running fglrx
<pitti> \o/
<pitti> Lure: glxgears work? compiz doesn't, I assume?
<johanbr> pitti: I just saw I got this: dexconf: error: cannot generate configuration file; 
<johanbr> xserver-xorg/config/monitor/identifier not set.  Aborting.  Reconfigure the X 
<johanbr> server with "dpkg-reconfigure xserver-xorg" to correct this problem.
<pitti> uh
<pitti> johanbr: was this a customized xorg.conf?
<johanbr> pitti: yes
<pitti> johanbr: ah, can you please back it up and do the dpkg-reconfigure?
<pitti> I guess there's no way to automatically handle customized configs
<johanbr> pitti: Sure, just a sec.
<pitti> I should check for this and don't touch it in this case, though
<Lure> pitti: 300fps and high cpu load - I suspect 3d is not working properly
* pitti files a bug for himself
<pitti> Lure: glxinfo should tell you
<johanbr> Lure: Check "glxinfo |grep direct"
<Lure> pitti: no :-(
<Lure> pitti: Mesa GLX Indirect
<pitti> Lure: is the glx module enabled?
<Lure> pitti: it is in xorg.conf
<pitti> Lure: or, asked differently, I currently enable the glx module and don't touch the other ones. What else do I need to do?
<pitti> Lure: e. g. for nvidia we have to disable the GLcore and dri modules
<Lure> pitti: not sure, I did not use fglrx for a year or more 
<pitti> Lure: /var/log/Xorg.0.log might also have interesting things
<pitti> Lure: well, 300 fps you say? that doesn't sound *that* bad, does it?
<Lure> pitti: (EE) AIGLX: Screen 0 is not DRI capable
<Lure> pitti: it might be my laptop (hp nw8240 with x700)
<pitti> Lure: on amd64/3000 with nvidia radeon 5200 I get 280 fps fullscreen
<johanbr> pitti: Okay, did the reconfigure, selected "ati" driver, then let r-m modify xorg.conf to use fglrx. Will restart X now to check that it worked...
<pitti> Lure: well, at least it didn't completely screw up your system then?
<Lure> pitti: it did not
<pitti> Lure: if you disable it again, it should uninstall the package and reset xorg.conf to ati, and make X work again with the free driver
<Lure> trying
<pitti> johanbr: wb
<Lure> pitti: in use is off...
<pitti> Lure: oh, second
<johanbr> pitti: Yep, that worked, I'm now running fglrx. DRI doesn't work though, but I guess that might be a kernel module conflict that requires a reboot.
<pitti> Lure: hm, you are using the fglrx driver ATM and it says 'not in use'?
<Lure> pitti: yes
<pitti> Lure: lsmod | grep fglrx
<Lure> pitti: now I have disabled it already
<Lure> pitti: nothing
<pitti> Lure: right, but if you disable it while X still runs with fglrx, it should still be 'in use'
<pitti> Lure: the lsmod | grep is basically what r-m uses to decide 'in use'
<pitti> Lure: could you please observe this behaviour in different cases and file a bug?
<pitti> Lure: (ubuntu-bug -p restricted-manager)
<Lure> pitti: will do 
* Lure has to play chess now with daughter
<pitti> johanbr: the fglrx driver might just require to disable the X.org dri module
<pitti> Lure: a thousand thanks for your help!
<wasabi_> So. Um. What the hell is with the idiotic settings pdflush has? When I put my system under heavy load it hits 12 processes.
<johanbr> pitti: No, I had the dri module loaded before, with working direct rendering under fglrx.
<pitti> johanbr: ah, ok; then I leave it enabled
<wasabi_> 12 processes get WAAAY to much CPU and starve the rest of the system.
<johanbr> pitti: I'll reboot to check if it works then. Just a minute...
<pitti> johanbr: ok, I think this will do as the next version; not yet optimal, but at least working somewhat
<johanbr> pitti: No, it wasn't stray kernel modules. My old xorg.conf gives me direct rendering, but the one written by r-m doesn't. I'll have a look at the files...
<pitti> johanbr: could you file this as a bug report? I'm sorry, but I have to run now
<pitti> johanbr: your help was awesome, thank you!!
<johanbr> pitti: Found it! The r-m xorg.conf doesn't disable Composite.
<pitti> johanbr: ah, that's the issue that mvo mentioned above
<johanbr> pitti: Okay. Still want a bug?
<pitti> <Seveas> Section "Extensions"
<pitti> <Seveas>     Option  "Composite" "0"
<pitti> <Seveas> EndSection
<pitti> johanbr: ^ this one, right?
<johanbr> pitti: Yes
<pitti> johanbr: does composite actually work when you don't disable it?
<Seveas> no
<johanbr> pitti: no
<pitti> ah, so it's not 'you want this or that', but a pure 'unbreak my config' option
<Seveas> yup
<pitti> johanbr: alright, I can file it myself then; thanks again!
<johanbr> You're welcome. Happy to help.
* Lure lost the chess game :-(
<Lure> pitti: can confirm DRI errors due to Composite here
<pitti> Lure, johanbr: alright, I filed this as bug 90688 to remind myself
<Ubugtu> Malone bug 90688 in Ubuntu "disable composite in fglrx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90688
<Lure> pitti: could we patch xorg instead? I think Composite on by default is Ubuntu specific change, so we could potentially blacklist fglrx
<Lure> pitti: this would help also for people not using r-m
<pitti> Lure: you mean the actual server binary?
<pitti> tepsipakki: ^ any idea? did this come up in the merge?
<Lure> pitti: probably - I think we have patch to enable by default comosite - maybe we can make it with blacklist
<pitti> 019_ubuntu_enable_composite.diff
<pitti> indeed
<pitti> yes, I agree that this would be much cleaner
<Lure> pitti: the only concern might be if ATI fixes xglrx for composte support
<tepsipakki> whoa, let me read the backlog
<Lure> pitti: but then we will probably be on feisty+3 already ;-)
<pitti> tepsipakki: just look at but 90588
<pitti> tepsipakki: sorry, bug 90688
<Ubugtu> Malone bug 90688 in xorg "disable composite in fglrx" [Undecided,Confirmed]  https://launchpad.net/bugs/90688
<pitti> Lure: sure, but then we can still unblacklist it easily
<Lure> pitti: right
<pitti> tepsipakki: I definitively prefer not to add completely new sections to xorg.conf which only have one valid setting anyway :/
<tepsipakki> enabling Composite has been discussed in debian-x-list recently
<tepsipakki> and they prefer doing it via the config
<tepsipakki> we have patched xorg-server like fedora
<tepsipakki> bbl ->
<pitti> tepsipakki: hmmkay
<pitti> good night everyone!
<johanbr> Lure: There are rumours that the April fglrx release will support Composite.
<_StefanS_> whats the channel for feisty related stuff?
<_StefanS_> ubuntu+1 :)
<khermans_> is there an easier way to debug an nvidia driver issue in a certain call rather than kprobing that address ?
<pirast> could anyone please advocate the nomination for dapper in bug 38210?
<Ubugtu> Malone bug 38210 in asterisk "AGI is broken" [Undecided,Unconfirmed]  https://launchpad.net/bugs/38210
<exobuzz> there was a guy i spoke to on here before, who was reponsible for the mac mini support.. anyone know who it might have been ?
<exobuzz> could it have been mdz.. i forget
<exobuzz> im sure it was a short "nick"
<exobuzz> oh wait. i should check my logs
<mdz> exobuzz: you are probably thinking of mjg59
<exobuzz> yeh sorry
<exobuzz> mjg59
<exobuzz> mjg59: i just read about Chris Lightfoot. F*ck :( i thought he was on holiday or something. i cant believe it :(
<jwendell> seb128, around?
<pochu> pirast: just curiosity, who can do that? the release team?
<jwendell> seb128, hi, have a minute (i promess, just a minute)
<jwendell> seb128_, hi, have a minute (i promess, just a minute)
<seb128_> jwendell: Hi, sure
<seb128_> jwendell: I've uploaded your gnome-screensaver update, thank you for the work on that, nice to have xnest mouse events working correctly :p
<jwendell> just a doubt: about bug 84662, you uploaded the new package with a changelog entry wendell@ubuntu?
<Ubugtu> Malone bug 84662 in gnome-screensaver "Xnest: ghost mouse" [Medium,Fix released]  https://launchpad.net/bugs/84662
<jwendell> seb128_, is this possible?
<seb128_> yep
<seb128_> I signed the changes file with my gpg key
<jwendell> seb128_, ah... good to know this is possible :)
<jwendell> seb128_, thanks and good night
<seb128_> np, 'night
<pirast> pochu, I saw pitt i and keescoo k being able to do that
<pochu> pirast: security team then?
<pirast> pochu, probably all other core-devs can do that
<keescook> pirast: strangely, my hilighter still went off, even with a space in my name.  :)
<pochu> pirast: hehe, I said that because they two are in the security team
<pochu> keescook: heya :) do you know my answer? ^
<keescook> pochu: unfortunately, I don't know why I have the perms to do it.  :)
<pirast> keescook, hehe, hi
<keescook> pirast: hi :)  I approved the dapper nomination, btw.  feel free to ping me on those things.
<pochu> hehe
<pirast> thanks :-)
<pirast> night
<pochu> keescook: ping :-P can you approve my nomination for x.org 7.2 and xserver 1.3 for breezy? :)
<keescook> pochu: hah.  I think that might not work.  :)
<tepsipakki> bwahaha
<pochu> tepsipakki: you are everywhere!
<pochu> tepsipakki: do you have a highlight for xserver? :P
<tepsipakki> I try to
<tepsipakki> heh, just happened to be here
<pochu> tepsipakki is everywhere less in fdo ;)
<pochu> s/less/except/
<tepsipakki> does #xorg-devel qualify?
<alperyilmaz> hi, does anybody here know how to run ubuntu from 2GB usb flash drive? I'm not talking about copying contents of liveCD to a Fat32 partition and making a casper-rw ext2 partition
<alperyilmaz> if this question is not relevant here, where can i ask 
<alperyilmaz> i used #ubuntu room, nobody helped 
<alperyilmaz> everybody is suggesting the fat/ext2 configuration
<alperyilmaz> i was aiming for a proper installation
<alperyilmaz> with ext2/swap partitions
<alperyilmaz> is that possible
<alperyilmaz> who might know this?
<mooey> alperyilmaz, if you don't get a reply in #ubuntu best to post on the forums, this isn't a support channel
<alperyilmaz> i see, i thought development people might now which files to copy and details like that
<tepsipakki> alperyilmaz: or try #ubuntu-install
<alperyilmaz> other poeple's knowledge is superfacial.. 
<tepsipakki> I guess there are docs for that somewhere
<alperyilmaz> oh, i didn't notice that room
<alperyilmaz> thanks
<GNu_Joe> where can I go to look at / understand the roadmap for ubuntu-server?
<mooey> GNu_Joe, i guess you should look into the specs in launchpad, https://launchpad.net/ubuntu/+specs
<Fujitsu> pochu: Any member of the Driver team for a product or distribution can approve release nominations (ubuntu-core-dev in this case).
<pochu> Fujitsu: oh, ty :)
<superted> just tried to install herd 5 and got this message before it froze: udevd-even[xxx] : udev_db_add_device: unable to create db file '/dev/.udev/db/class@input@mice': No such file or dir
<superted> sorry, noticed the "not support" in topic now
<Ng> superted: #ubuntu+1 :)
<superted> Ng: ty
<mooey> does anybody here have two cd drives in their system? if so, when you have no cds inserted, do you see both drives in 'Places' -> 'Computer'?
<sorinn> anyone here ?
<sorinn> I need to know hoe to make a log with valgrind for openoffice 2.2 ( on feisty )
<pochu> doko: ^
<Fujitsu> infinity: Do you do givebacks these days?
<Riddell> lifeless: do you know what's happened to kdebase 4:3.5.5-0ubuntu3.3 on i386 and amd64?  they don't seem to be entering the archives
<Riddell> er, wait
<Riddell> I'm getting my abstract nicks mixed up again!
<lifeless> Riddell: totally
<lifeless> Riddell: also, you might like to look in the conflict checker for kdebase
<lifeless> there are upgrade bugs
<Riddell> the conflict checker?
<lifeless> someone on my LUG ran into one using the edgy kde4 reop
<lifeless> people.ubuntu.com/~robertc/find-conflicts/
<Riddell> oh, that's a different package, it's fixed in feisty
<lifeless> erm
<Seveas> lifeless, 404
<lifeless> http://people.ubuntu.com/~robertc/possible-conflicts/
<lifeless> yeah, messed up the branch name with output in my head
<Riddell> lifeless: that looks interesting, when did that appear?
<lifeless> stockholm
<lifeless> sorry, oslo
<Riddell> I'll make a note to look at it closer 
<Riddell> anyway
<Riddell> infinity: do you know what's happened to kdebase 4:3.5.5-0ubuntu3.3 on i386 and amd64?  they don't seem to be entering the archives
<infinity> Fujitsu: Aye.
<infinity> Riddell: I'll look into it.
<Fujitsu> infinity: Can you please give-back the amd64 drscheme?
<lifeless> no, its mine! mine I tells ya!
#ubuntu-devel 2007-03-09
<infinity> Riddell: Fixed.
<Riddell> infinity: what was up?
<infinity> Riddell: A bit of a hiccup on drescher, s'all.
<geser> infinity: Hi. Any progress on the HASH bug in the buildds?
<geser> keescook: gnupg2 2.0.3 was released today (primarly including a patch for the gnupg security problem). I've already new packages ready.
<geser> Should I try to get an UVF exception for it?
<keescook> geser: yeah, go for it.
<keescook> I need to do the gnupg2 backports still, but it's currently a lower priority than other stuff
<geser> the security announcement also provides a patch for gpgme 1.1.3
<geser> but we still have gpgme 0.3.16 (first uploaded to warty) :(
<keescook> geser: there's also gpgme1.0
<geser> that would explain why it's so old :)
<sistpoty> tfheen: How many packages would fall under 
<sistpoty> tfheen: sorry, wrong question... copy/paste error... just wanted to ping you about binary only removals, thx
<sistpoty> tfheen: as in if ubuntu-archive came to a decision already
<alex-weej> elkbuntu: have you considered openid for ubuntucounter? :P
<AnAnt> Hello, anyone knows what has changed from Edgy to Feisty regarding virtual console (keymap,translations,...) ?
<jdong> anyone have experience with the Python bugtracker?
<jdong> I found a typo in Python....
<jdong> >>> (1-24j)**34324324
<jdong> OverflowError: complex exponentiaion
<jdong> it seems to have survived from python2.3 to 2.5, at least
<Chipzz> what's wrong with that?
<PuMpErNiCkLe> "exponentiaion"
<jdong> Chipzz: are you a Python developer by any chance? ;-)
<Chipzz> jdong: no, not at all :)
<Chipzz> jdong: I was looking at the code instead of the line below ;)
<jdong> hehe
<Chipzz> silly me :P
<jdong> found it while... err... traversing a polynomial for a real solution
<jdong> (and of course it didn't have any)
<Chipzz> brute-force attack? :)
<jdong> of course :)
<jdong> we got an e-mail a week and a half ago stating that spawning mathematica/matlab is not an acceptable algorithm anymore
<jdong> the "anymore" part concerned me :D
<Chipzz> heh
<Chipzz> you really don't want to program in matlab anyway :P
<jdong> I know, but when your assignment is to write an arbitrary matrix inverter, it's tempting.
<jdong> especially since you know the validator has mathematica and matlab installed....
<Chipzz> from the little experience I have with matlab, it looks impossible to create a clean solution to certain problems
<jdong> it's ok but not fantastic
<jdong> simulink is cool though
<jdong> realtime workshop.... click button and C code comes out
<Chipzz> the lack of any kind of references sucks monkey balls
<jdong> it's not that kind of programming language, lol
<Chipzz> the problem I once had was a large matrix, and I needed to call a function which changed it quite a lot of times
<jdong> ah
<jdong> yeah then performance will blow
<Chipzz> the solution to that is to give the matrix as a parameter, and return a copy of the modified version
<Chipzz> yeah
<Chipzz> it copies it every time
<Chipzz> so
<Chipzz> it was either that
<Chipzz> or use a global variable
<Chipzz> both solutions suck :P
<jdong> well you're supposed to cave into global variable peer pressure
<Chipzz> a reference type would have helped there
<jdong> no. bad compiz. do that again and beryl's going back on.
* jdong hates it when windows get stuck in infinite wobble-snap
<Fujitsu> jdong: I've only ever had that issue with Beryl.
<jdong> Fujitsu: really?
<jdong> compiz is doing that to me like every 1 of 10 times I maximize a terminal
<jdong> with other maximized apps in the background
<jdong> it simply wiggles forever
<jdong> it's very annoying when trying to type into it
<Fujitsu> Hah.
<jdong> it's like giving a directional derivatives lecture to a room of people with ADD.
<Fujitsu> A couple of weeks back, I made the mistake of shrinking a window slightly vertically.
<Fujitsu> It proceeded to bounce between the two ends for eternity.
<jdong> "now you... you take the gradient.... the grad.. HEY SIT DOWN. STOP JUMPING"
<jdong> ha, we should have a silly beryl tricks contest :)
<jdong> submission #1: Compiz:
<jdong> http://web.mit.edu/~jdong/www/wobble.ogg
<jdong> got 3 windows to wobble indefinitely
<jdong> and for some reason firefox started bouncing a bit too
<Fujitsu> Nice, jdong.
<jdong> :)
* jdong gets bored, and contemplates between sleeping or filing more wisecrack bugs
* Chipzz goes to sleep
<jdong> bug 54776 was pretty good.... despite it was a dupe :(
<Ubugtu> Malone bug 54776 in openoffice.org "font hinting does not work with libfreetype6 v. 2.2.1" [Low,Confirmed]  https://launchpad.net/bugs/54776
<jdong> umm
<jdong> bug 90636
<jdong>  rather :)
<Ubugtu> Malone bug 90636 in openoffice.org "Openoffice fonts aren't blurry enough (dup-of: 54776)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90636
<Ubugtu> Malone bug 54776 in openoffice.org "font hinting does not work with libfreetype6 v. 2.2.1" [Low,Confirmed]  https://launchpad.net/bugs/54776
<jdong> oh for the love of libpthread, come up you stupid mailserver :(
<jdong> Hobbsee: waah, make it work... poke my mailserver with your long pointy stick
* Hobbsee pokes the mailserver with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<jdong> yay!
<Hobbsee> jdong: what's it doing?
<jdong> Hobbsee: well apparently it's been fscking for the past 30 hours
<Hobbsee> fun
<Fujitsu> That's NOTHING.
<Fujitsu> snapshot.debian.net was fscking for a couple of months, I believe.
<jdong> well... I was supposed to be getting 2 homework assignemnts thru e-mail
<jdong> due tomorrow
<jdong> and it's 1AM :(
* jdong brews more coffee
<jdong> Fujitsu: well, I shall see how long the mailserver takes.... apparently they've given up on fsck and are mounting it ro and copying everything onto a new RAID
<pitti> Good morning
<tepsipakki> Morgen pitti :)
<ajmitch> hi pitti 
* pitti hugs tepsipakki and ajmitch 
<tepsipakki> pitti: seems that I forgot to create the series-file for quilt in libxcb, crimsun fixed it
<pitti> tepsipakki: ah, toss me a debdiff, then I'll upload
<tepsipakki> it's uploaded already, -1ubuntu2
* Hobbsee hugs pitti 
* fabbione wonders who did pull in libglade2/3 in main
<fabbione> glide even
<fabbione> installing those libraries is a moot point without a bunch of other stuff includeing the 3dfx kernel module
<fabbione> and they ask questions at install time that needs to be preseeded with sane defaults to be of any use
<fabbione> otherwise default install will suck
<fabbione> they were left out for a veeeeery good reason
<fabbione> tepsipakki: anyway you are doing a really good job up till now.. i am impressed
<tepsipakki> fabbione: thanks ;)
<tepsipakki> fabbione: libglide2/3 are in main? Seem to be in universe here..
<pitti> fabbione: how do you mean? glide source and binaries are in universe
<fabbione> pitti: they have been pulled in by this morning update... might be a depends: change..
<fabbione> tepsipakki: ^^
<fabbione> this damn developers that needs stuff from universe..
<_ion> Hi pitti
<_ion> Did you get my email?
<pitti> fabbione: right, but there's no MIR, thus noone promotes it; it's just a broken Dependency then, I guess
<pitti> _ion: yup, saw it, thank you! will merge and answer you
<fabbione> pitti: ok :)
<_ion> pitti: If you use bzr merge --pull, it will probably just pull the change, unless the branches have diverged, btw.
<pitti> _ion: right, or just 'bzr pull' :)
<_ion> Yeah, that works if one already knows they haven't diverged. :-)
<pitti> argh, no LP
* pitti throws the archive admin hat back into the corner then
* mdke puts it on, just for fun
* bluefoxicy puts on the hat; the White Spy subsequently drops a piano on his head.
<_ion> Hey, that's offensive! You must surely mean the Caucasian Intelligence Officer.
<slomo_> tepsipakki: just curious but won't the xcb patch lead to apps deadlocking instead of aborting them?
<tepsipakki> no, it will ignore the locking check altogether
<slomo_> tepsipakki: hmm... but isn't this assertion done just before locking (or unlocking) to prevent a deadlock? i don't see how that patch could do something good ;)
<tepsipakki> the links are there for reference, pitti just reversed the logic ;)
<slomo_> tepsipakki: ok... do we have the mesa patch btw? and the locking issue in gtk was fixed some hours ago fortunately :)
<tepsipakki> oh, do you have the link to the gtk-fix?
<tepsipakki> what was that mesa patch again?
<slomo_> tepsipakki: http://svn.gnome.org/viewcvs/gtk%2B/trunk/gdk/x11/gdkasync.c?r1=17436&r2=17435&pathrev=17436
<slomo_> tepsipakki: i wanted to ask seb128 if he can include it with his next upload later
<pitti> mvo: do you know a bit about python-notify? pynotify.defs has attach_to_status_icon(), but the .so doesn't
<pitti> mvo: and I actually need this for restricted-manager
<slomo_> tepsipakki: https://bugs.freedesktop.org/show_bug.cgi?id=8521
<Ubugtu> Freedesktop bug 8521 in GLX "AllocAndFetchScreenConfigs unlocks twice" [Normal,Resolved: fixed]  
<tepsipakki> slomo_: you wanted that for dapper/edgy?
<slomo_> tepsipakki: hm? no
<slomo_> tepsipakki: i only wanted to know if we have this patch in feisty ;;)
<tepsipakki> that's in mesa-6.5.2
<tepsipakki> which is in feisty
<slomo_> perfect
<mvo> pitti: I haven't used that yet, but what about attach_to_widget?
<pitti> mvo: a gtk.StatusIcon is not a widget
<mvo> pitti: righ, you could just pack it into a eventbox to get a widget 
<pitti> mvo: yup, but how do I add the statusicon into it?
<pitti> mvo: I think for precisely this problem libnotify has an attach_to_status_icon() :)
<pitti> just the Python binding seems to be missing
<cjwatson> pitti: some of the language-pack bits in http://people.ubuntu.com/~robertc/possible-conflicts/feisty/main.txt look like they just need extra Replaces
<doko_> pitti: I'm done with the uploads
<pitti> doko_: yay, thanks
<pitti> cjwatson: ah, thanks; those are probably the ones that have never been updated since I added the misssing replaces
<cjwatson> ok
<dholbach> good morning
<seb128> morning
<seb128> pitti: I've started to look at the KDE packages waiting to NEW yesterday and I've questions about them
<pitti> urgh, NEW?
<seb128> does debian/copyright needs to list the copyright holders?
<pitti> seb128: yes, it does
<seb128> pitti: yeah, you know, where new source packages go
<pitti> seb128: ah, you mean for feisty, not for the edgy-proposed thing
<pitti> seb128: sorry, wrong mental context :)
<seb128> np ;)
<seb128> k, because they don't
<seb128> another weird thing is
<pitti> mvo: ah, simple bug, pynotify.c is not regenerated properly
<mvo> aha
<seb128> k, can't get it from NEW, will look later
<pitti> wow, Riddell grew another 'l' :)
<pitti> tepsipakki, mvo: so, can you please have a look at http://pastebin.ca/387387 if it looks sane for fglrx?
<mpt> pitti, http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/9d42950d1147e8ed
<mpt> (don't know whether you're interested)
<pitti> mpt: indeed I am, and I saw it this morning; unfortunately I'm at a concert tonight, but I'll join the next meeting
<tepsipakki> pitti: looks good
<cjwatson> mpt: are you going to be listening in?
<cjwatson> if nobody else can, I might, although the timing isn't good for me either
<mvo> pitti: looks good
<pitti> tepsipakki, mvo: thanks
<mpt> cjwatson, sorry, I'll be busy being a weekend tourist guide
<mpt> (and I probably couldn't contribute/understand much anyway, I iz just a UI designah)
<dholbach> Riddell: I just uploaded a new example-content and did some small changes - if you want to update Kubuntu related changes, I added the branch URL in XS-Vcs-Bzr
<dholbach> Riddell: or if you know somebody who'd like to do that (maybe kwwii?)
<mpt> cjwatson, if you attend, be aware that Benjamin Smedberg's PT-to-UTC conversion isn't accurate
<kwwii> dholbach: did a lot change?
<dholbach> kwwii: no, I merely changed some occurences of 6.06 and 6.10
<dholbach> kwwii: I just saw that the Kubuntu presentation has "Add Image Here" in it and still mentions powerpc
<dholbach> kwwii: and it's 3 times as big as the ubuntu one :)
<kwwii> dholbach: I'll look into that
<dholbach> kwwii: super
<Seveas> beta.lp sure is oopsing a LOT
<Fujitsu> Seveas: every 3rd HTTP request or so, it seems.
<mpt> beta's working again?
<pitti> hm, I had two 'oops -- no css -- looks normal' cycles now
<mpt> ah, thanks for the notification Seveas :-)
<mpt> pitti, the technical term for that is FOUC
<mpt> Flash Of Unstyled Content
<pitti> mpt: but certainly not for the oopses :)
<mpt> The non-technical term is "Style sheet, I've waited too long for you to arrive, so I'm going to draw the page anyway"
<mpt> True, not for the oopses
<Fujitsu> mpt: No, it's style-sheet, I got an OOPS page in return, so it's not valid, so I'm not going to render you.
<mpt> Top Men are working on those
<mpt> Fujitsu, I find it very difficult to believe that the style sheet would return an OOPS
<mpt> we don't do any database queries for the style sheet :-)
<Fujitsu> It did.
<Fujitsu> Try it.
<Fujitsu> Refresh a few times.
<Fujitsu> You'll get one (/+icing/style.css, for example)
<cjwatson> mpt: heh, good point
<Fujitsu> You get a nice beta-styled oops.
<mpt> WOW
<Fujitsu> Or I've somehow managed to insert OOPS-433BD703 into the magical database.
<Hobbsee> haha
<mpt> I was going to say "Loaded it ten times, no oopses"
<Fujitsu> mpt: Hah.
<Hobbsee> even mpt is suprised about LP - scary!
<mpt> but then it oopsed at the bottom of the ninth
<mpt> with bases loaded
<Fujitsu> mpt: Any idea what's happening!?
<Seveas> all your launchpad are belong to OOPS
<Fujitsu> Surely there's no DB-foo behind it...
<mpt> Fujitsu, I said Top Men are working on it
<pitti> "Launchpad will be going offline for maintenance very very soon."
<mpt> Honestly, do I look like a Top Man?
<pitti> hmm, I thought it just came back?
<Seveas> mpt, yes
<mpt> I don't even have any muscles.
<Fujitsu> mpt: Ah, didn't see that.
<Hobbsee> pitti: it did.  it decided it didnt like life, so is in hiding again.
<Seveas> Hobbsee, lp has a marvin attitude?
<Hobbsee> Seveas: seems so...
<TheMuso> Lp. DOn't talk to me about lp.
<Hobbsee> haha
<Seveas> I think you ought to know, I'm feeling very OOPS'ed
<TheMuso> lol
<imbrandon> OOPS has taken the BSOD top spot ;)
<Riddell> pitti: I screwed up again, the python-kde package is missing the necessary new function and a symlink
<Riddell> pitti: which is all very annoying, it's not like I didn't test this stuff three times
<Riddell> pitti: http://kubuntu.org/~jriddell/tmp/pykde.debdiff
<Riddell> pitti: and http://kubuntu.org/~jriddell/tmp/adept.debdiff
<pitti> Riddell: looks fine
<pitti> Riddell: not sure whether uploads will work, though, but just try :)
<Riddell> mm, but it looked fine last time.  grump
<Riddell> thanks
* pitti waves to Keybuk 
<Keybuk> heyhey
<Fujitsu> Hi Keybuk.
* Hobbsee waves to Keybuk too, and drops an anvil on pitti's head
<pitti> ouch
<pitti> Hobbsee: how did I earn that?
<Hobbsee> pitti: the lack of greeting from earlier :P
<seb128> Riddell: your new KDE4 packages have no copyright holders listed to debian/copyright
<pitti> Hobbsee: *big hug*
<Hobbsee> pitti: :D *big hug back*
* Fujitsu runs off with the anvil.
<seb128> kde4multimedia has files under the LGPL, it doesn't ship a copy of the text though
<seb128> that is weird
<seb128> " *  This program is free software; you can redistribute it and/or
<seb128>  *  modify it under the terms of the GNU General Public
<seb128>  *  License version 2 as published by the Free Software Foundation.
<seb128> ...
<seb128>  *  You should have received a copy of the GNU Library General Public License
<seb128>  *  along with this library; see the file COPYING.LIB.  If not, write to
<seb128>  *  the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,"
<seb128> 
<seb128> is that normal to have file under the GPL with an indication of where to get the LGPL?
<Riddell> seb128: it's the same copying file as in the KDE 3 package
<Riddell> which probably hasn't changed much since KDE 0.1
<pitti> seb128: the 'a little bit more than lesser GPL'?
<seb128> pitti: no, just wondering why it says the file is "under the terms of the GNU General Public" and mentions the "GNU Library General Public License" then
<pitti> seb128: right, I noticed
<seb128> that's from kdeadmin
<Riddell> oh joy I think I've deleted all the kde4* packages from my local hard disk
<Riddell> seb128: if you reject them can you put the sources somewhere I can get at them?
<seb128> Riddell: I'm not going to reject them, I'm not comfortable enough on source NEW yet, I'll let tfheen or pitti do them
<seb128> Riddell: I think you have to ship at least the LGPL text with the package
<pitti> seb128: if debian/copyright does not have copyright holders, and the upstream license is wrong, then they need to be rejected
<seb128> dunno if debian/copyright has to list the copyright holders, they don't
<Riddell> or point to it in common licences
<pitti> Riddell: no
<Riddell> but it's no worse than what's in the current KDE 3 packages in debian and ubuntu
<pitti> Riddell: pointer is good for debian/copyright, but *not* for orig.tar.gz's
<Riddell> pitti: why not?
<seb128> and dunno if source mentionning the GPL and then the LGPL is a problem to fix
<Riddell> oh, I see
<Riddell> seb128: can you put the sources somewhere I can get at them?
<pitti> seb128: it's ok to license some parts as lgpl and some as gpl, but upstream's files have to tell which license applies in the file headers, and debian/copyright needs to list the various parts
<seb128> pitti: could you have a look to kdeadmin, kuser/ku_usermodel.cpp for example?
* pitti gives up doing SRUs and syncs due to LP being too broken
<seb128> and let me know if you think it's correct
<pitti> seb128: fetching
<seb128> Riddell: will do
<Hobbsee> pitti: was supposed to be more fixed, too
<pitti> seb128: looks fine to me, what's wrong wit it?
<seb128> pitti: k, I was not sure about the file being GPL and then pointing to LGPL and COPYING.LIB (which is not shipped with the tarball)
<pitti> Riddell: d/copyright also needs to point out which parts are under the docbook license
<pitti> seb128: it's certainly weird that it's COPYING.LIB, and not COPYING; so if COPYING.LIB is the GPL, that's fine
<pitti> seb128: oh, indeed that doesn't exist. that's wrong then
<seb128> pitti: well, it's written "You should have received a copy of the GNU Library General Public License"
<pitti> seb128: ah, you are right
<pitti> this is completely screwed up then
<pitti> seb128: sorry, I didn't read hard enough
<seb128> np
<seb128> pitti: since it's your archive day I'll let you reject the uploads if that's ok with you. Could you also copy them on chinstrap or somewhere for Riddell?
<pitti> seb128: sure
<seb128> thank you
<Riddell> pitti, seb128: by the way I care less about KDE 4 today than about libkexiv getting through NEW
<pitti> Riddell: trying, depends on how much lp loves me
<seb128> Riddell: ah, I though tfheen was going to do it since he said it was ok during the meeting
<pitti> Riddell: I guess you want it in main; is there a MIR or is it a code splitout?
<Riddell> pitti: it's code that has been split out of the previous version of digikam
<pitti> Riddell: ah, so main
<Riddell> yes please
* Hobbsee wonders what the point of KDE4 is if MOTU is wanting to veto it going into universe, without uvfe's
<pitti> Riddell: libkexiv2 source-NEWed
<Riddell> pitti: thanks
<pitti> Riddell: http://people.ubuntu.com/~pitti/tmp/kde4/
<pitti> Riddell: I'll reject kde4network then, do you need another mail or is above IRC discussion enough?
<pitti> Riddell: erm, s/network/admin/
<pitti> seb128: did you already check the other kde packages, too?
<seb128> pitti: admin and multimedia
<seb128> not the others
<pitti> seb128: mm had the same problem or was ok?
<seb128> is has problems
<seb128> at least not shipping the LGPL text and no copyright holder
<Riddell> seb128: no copyright holder where?
<Riddell> pitti: irc is fine
<pitti> Riddell: debian/copyright has no copyrights
<StevenK> seb128: Have you seen an issue with Edgy where icons for the Games don't show up in the menu and the update-notifier icon doesn't display either?
<Riddell> hmm, right
<seb128> StevenK: no, looks like an outdated cache
<seb128> brb
<pitti> Riddell: kde4edu is hte same problem: missing COPYING.LIB and no copyright in debian/copyright;
<Riddell> pitti: ok
<Riddell> I'll need to fix this all upstream
<Riddell> which is not a-typical of KDE
<pitti> right, probably the other sources have a similar problem
<Riddell> pitti: adept and pykde seem to be accepted into edgy-proposed ready for approval
<pitti> Riddell: done
<StevenK> seb128: Your cache answer was spot-on, thanks.
<seb128> StevenK: np
<pitti> Riddell: which package provides kde-config? I need to rebuild skim for the Maintainer: change
<supervillain> hello, is apt-proxy secure? can I trust an apt-proxy server?
<Riddell> pitti: kdelibs4c2a
<pitti> urgh, 20 MB deps  just to rebuild a source package :/
<seb128> pitti: don't build it, just debuild -S and upload ;)
<pitti> seb128: right, but even that needs kde-config, scons, and everything
<seb128> ah
<Riddell> debuild -S shouldn't, only scons and cdbs
<pitti> Riddell: scons -c is called in clean, that needs all the stuff
<Riddell> ah well, I guess there's a reason KDE dropped scons :)
<pitti> Checking for the qt library       :  qt was not found
<pitti> grr
<pitti> I have libqt3-mt-dev
<Hobbsee> supervillain: ask the guys that wrote it?
<tepsipakki> tfheen: did you see that sync-request about discover-data?
<pitti> cjwatson: I just noticed that libgucharmap is NBS in feisty (gucharmap builds soname 6 now); do these packages need to be removed manually, or will you do it in a big wave at some point?
<cjwatson> pitti: archive-cruft-check scans for that; feel free to remove stuff in there after a cursory check
<cjwatson> (remove-package.py -m '(pitti) NBS' -b foo bar baz)
<pitti> cjwatson: right, I checked rdepends in this case, I just wondered whether there was some automagic script for it
<cjwatson> pitti: I generally give things at least a few days before removing them to make transitions less painful
<cjwatson> pitti: archive-cruft-check for finding them, but nothing automatic for removing them
<pitti> cjwatson: I think this one has been around for at least two weeks
<cjwatson> erm, archive-cruft-check -n too, IIRC
<pitti> cjwatson: ah, I see; alright, I'll clean up a little
<cjwatson> I usually do archive-cruft-check -n | sed 's/,//g' to make it easier to paste bits of the output
<pitti> cjwatson: is there anything we need to do about the ASBA lines?
<Riddell> mvo: is update-manager the only place which prompts you to download and run the dist-upgrade tool in ubuntu?
<mvo> Riddell: yes
<mvo> Riddell: well, and update-notifier if a CD is inserted
<mvo> Riddell: with a update image
<Riddell> mvo: how do you run dist-upgrade if there's no packages in the stable release to update and pop up the update-notifier icon?
<mvo> Riddell: currently there is only update-manager. it could be made part of update-notifier I think, but that makes matters more complicated
<pitti> Riddell: could you please fix kdemultimedia and juk to not b-dep on libtunepimp-bin any more? it's not built any more
<Riddell> pitti: ok
<Riddell> mvo: so if there's no stable release updates you can't run the dist-upgrade tool?
<pitti> Riddell: (and rebuild kid3 if you like to keep it installable)
<pitti> Riddell: thank you
<mvo> Riddell: no, just just need to run it manually
<Riddell> mvo: from the command line?
<mvo> Riddell: there is no notification in the tray
<mvo> Riddell: from the menu 
<Riddell> ah, right
<Riddell> thanks mvo 
<pitti> cjwatson: is it generally safe to remove all the older kernel ABI debs now?
<mvo> Riddell: so far this was not a limitation
<kagou> mvo, i'v looked at displayconfig-gtk. My screen is missing from your MonitorsDB
<kagou> mvo, where this file come from ? 
<Fujitsu> pitti: can you nuke the asterisk upload to Feisty before publisher runs, or not?
<pitti> Fujitsu: I think I can
<pitti> Fujitsu: but it's not in accepted
<mvo> kagou: its part of the source right now, displayconfig/ldetect-lst/MonitorsDB
<Fujitsu> It was uploaded about 10 minutes ago, I believe.
* Hobbsee hasnt gotten an accepted mail for it yet either
<kagou> mvo, yes but how did you have generated it ?
<cjwatson> pitti: ignore ASBA, not much you can do about it
<cjwatson> pitti: normally yes, though check that all the bits that need to be rebuilt for a new kernel ABI have been rebuilt
<pitti> cjwatson: that is, d-i and ubiquity?
<cjwatson> pitti: not ubiquity; linux-restricted-modules, linux-meta, linux-backports-modules, d-i
<kagou> mvo, i'v an belinea.inf from windows driver, i will try to parse it and try to make a diff with your file 
<pitti> cjwatson: ah, ok; thanks
<mvo> kagou: its taken from kde-guidance and they have it from Xconfigrator
<pitti> kwwii_: just a warning, various artwork packages depend on usplash-dev; this needs to be fixed to libusplash-dev
<kagou> mvo, oh ! so may be  i should make a diff for Xconfigurator. It's a better choice no ?
<mvo> kagou: I'm not sure how active Xconfigrator is actually :) so a diff against the one in displayconfig-gtk is a saver choice for now. it should also go to the kde-guidance people
<pitti> cjwatson: how do I check d-i?
<kagou> ok mvo  thanks
<kwwii_> pitti: where does one change that?
<pitti> kwwii_: debian/control, 'Build-Depends:'
<kwwii_> pitti: cool, thanks...dholbach will help me on that, I am sure :-)
<ogra> pitti, hmm, restricted manager doesnt do the right thing for me it seems ... intrestingly lsmod|grep fglrx doesnt show the module anymore now ...
<pitti> ogra: --verbose, please
<ogra> lsmod --verbose ? 
<pitti> ogra: you are using 0.4?
<pitti> ogra: no, your explanation :)
<ogra> ah
<ogra> yes, i upgraded the whole system, removed the fglrx driver and reinstalled it with r-m to test the functionallity
<ogra> since thne my lsmod 
<ogra> doesnt show the module anymore
<ogra> apart from that 
<ogra> ogra@edubuntu:~$ glxgears 
<ogra> Xlib:  extension "XFree86-DRI" missing on display ":0.0".
<pitti> ogra: xorg.conf has ati or fglrx?
<ogra> fglrx 
<ogra> apparently its also using it ...
<pitti> le huh?
<ogra> (there are massive font differences between ati and fglrx ... according to the font i'm using the fglrx driver)
<ogra> (and according to xorg.conf)
<ogra> its just the module i dont see 
<pitti> that works without the kernel module?
<ogra> nor any traces in dmesg
<pitti> ogra: ah, wait, that might just be the module for DRI
<ogra> right
<ogra> still
<pitti> ogra: can you please ugprade x11-common to 7.2-0ubuntu7?
<pitti> ogra: this dexconf fixed DRI handling
<pitti> for fglrx
<ogra> it just silently fails ... i'd at least expect anything in dmesg
<ogra> my system is up to date and rebooted
<pitti> ogra: what's your version? might not yet have been built
<cjwatson> pitti: /srv/launchpad.net/ubuntu-archive/ubuntu/dists/feisty/main/installer-i386/current/images/MANIFEST.udebs
<ogra> ah, right
<ogra> ubuntu7
<pitti> cjwatson: thanks
<pitti> ogra: ah, so you hhave the Extensions section with composite disabing?
<pitti> in xorg.conf
<ogra> there is:
<ogra> Section "Extensions"
<ogra>     Option "Composite" "Enable"
<ogra> EndSection
<ogra> hmm
<ogra> dunno where that comes from though ... it wasnt there before 
<pitti> ogra: hm, current dexconf should set it to '0' for driver == fglrx
<pitti> and dexconf doesn't write Extensions otherwise
<pitti> ogra: sudo dexconf -o /tmp/conf produces a different one?
<ogra> ogra@edubuntu:~$ diff -ruN /etc/X11/xorg.conf /tmp/conf
<ogra> --- /etc/X11/xorg.conf  2007-03-09 14:16:05.000000000 +0100
<ogra> +++ /tmp/conf   2007-03-09 14:30:46.000000000 +0100
<ogra> @@ -153,7 +153,3 @@
<ogra>  Section "DRI"
<ogra>         Mode    0666
<ogra>  EndSection
<ogra> -
<ogra> -Section "Extensions"
<ogra> -    Option "Composite" "Enable"
<ogra> -EndSection
<ogra> yep
<pitti> ogra: that's still wrong; can you double-check that driver is fglrx?
<ogra> ogra@edubuntu:~$ grep fglrx /etc/X11/xorg.conf
<ogra>         Driver          "fglrx"
<pitti> dpkg -l x11-common | grep -q 0ubuntu7 || echo OUTOFDATE
<ogra> ogra@edubuntu:~$ dpkg -l x11-common | grep -q 0ubuntu7 || echo OUTOFDATE
<ogra> OUTOFDATE
<pitti> ogra: if that doesn't do anything, can you please get me a sh -ex output of dexconf?
<pitti> aaah
<pitti> ogra: as I said, 0ubuntu7 is necessary
<ogra> didnt i say i have ubuntu6 only ? 
<pitti> <ogra> ah, right
<pitti> <ogra> ubuntu7
<pitti> ogra: just a misunderstanding then, sorry :)
<ogra> oh, crap
<pitti> ogra: amd64? http://people.ubuntu.com/~pitti/tmp/x11-common_7.2-0ubuntu7_amd64.deb
<ogra> i shouldnt have six conversations simultaneously, sorry
<ogra> i386
<pitti> ogra: it's not yet on archive
<ogra> yep, i can wait, just wanted to notify you that it doesnt work yet for me 
<pitti> ogra: http://people.ubuntu.com/~pitti/tmp/dexconf, please put into /usr/bin
<ogra> but more weird is the module thing
<pitti> ogra: oh, it's just the script that's wrong
<pitti> ogra: right, that module thing is the bit I'd like to find out
<pitti> ogra: if it's not loaded automatically by the fglrx X driver, we might need to stuff it into /etc/modules or so
<tepsipakki> it should load automatically
<allee> Mhh, why does autobuilder complain about already existing Orig-maintainer field?  it's a 0ubuntu1 pkgs.  so I thought I have to add it. pkgmaintainermangler: Error: /build/buildd/libkexiv2-0.1.1/debian/libkexiv2-0-dbgsym/DEBIAN/control already contains an Original-Maintainer field; 
<ogra> well, usually the Xserver wouldnt start or at least complain if it werent loaded 
<allee> https://launchpad.net/+builds/+build/308754
<pitti> allee: it's XSBC-Original-Maintainer
<allee> pitti: that's what I added
<ogra> so it *mus* be loaded ... i wnder if the kernel has a bug in listing it somehow
<pitti> ogra: in this case it seems to go on without DRI
<ogra> hmm
<pitti> ogra: sudo modprobe fglrx?
<pitti> allee: looking
<allee>  $ grep Maintainer libkexiv2-0.1.1/debian/control
<allee> Maintainer: Achim Bohnet <allee@kubuntu.org>
<allee> XSBC-Original-Maintainer: Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
<ogra> pitti, done 1000 times today
<ogra> its not showing up
<tepsipakki> ogra: dmesg?
<pitti> ogra: hm, that seems to be outside of r-m's domain then
<pitti> allee: can you please put that debian/control somewhere?
<ogra> tepsipakki, just to repeat myself, nothing in dmesg, no commandline output etc ... no trace of the module, but its in /lib/modules where it belongs
<mooey> is it wrong that a package won't install in a chroot?
<pitti> allee: nevermind, I'll try it myself here
<mvo> mooey: depens on the package, which one is it?
<tepsipakki> ogra: ok, strange..
<mooey> mvo, sun-java6-jre from edgy backports, it installs out of a chroot fine but it fails consistantly in a chroot
<pitti> mooey: /proc, /sys, and /dev not mounted perhaps?
<tepsipakki> mooey: does it ask you about the license?
<pitti> mooey: we need the output of the postinst, preferably as sh -ex /var/lib/dpkg/info/<package>.postinst configure
<ogra> tepsipakki, 
<ogra> Mar  9 11:26:57 edubuntu kernel: [663600.348000]  [fglrx]  total      TIM  = 0
<ogra> ogra@edubuntu:~$ date
<ogra> Fr 9. Mr 14:46:36 CET 2007
<mooey> tepsipakki, it does yea
<mooey> pitti, one moment
<ogra> tepsipakki, last trace of fglrx is 11:26 ... its now 14:46, i upgraded inbetween and had more than 60 reboots during that time (two fsck's)
<tepsipakki> ogra: try reinstalling l-r-m
<mooey> oops, mounting /proc fixed it
<tepsipakki> ogra: just guessing here..
<pitti> allee: alright, reproduced locally; I'll fix this in pkgmaintainermangler and ask for a rebuild
<pitti> allee: fixed pkgbinarymangler uploaded; sorry for the hassle
<allee> pitti: okay, thx a lot!
* Keybuk hates gcov
<Keybuk> every time I modify the file, I have to "make clean all" otherwise it complains about "Merge mismatch for summaries"
<ogra> tepsipakki, 
<ogra> ogra@edubuntu:~$ sudo apt-get install --reinstall linux-restricted-modules-2.6.20-9-generic
<ogra> ogra@edubuntu:~$ sudo modprobe fglrx
<ogra> ogra@edubuntu:~$ dmesg|grep fgl
<ogra> ogra@edubuntu:~$ lsmod|grep fgl
<ogra> nothing ...
<tepsipakki> weird
<Treenaks> ogra: rmmod radeon ?
<ogra> ogra@edubuntu:~$ lsmod|grep radeon
<ogra> ogra@edubuntu:~$
<ogra> :)
<ogra> nothing to rmmod
<zul> elmo: ping I should have xen-2.6.20 this weekend hopefully
<elmo> zul: wow - with what version hypervisor?
<seb128> ogra: xorg-driver-fglrx
<zul> 3.0.3
<ogra> seb128, what about it ? 
<zul> elmo: Im actually building the x86 version right now
<seb128> ogra: it looked like you were trying to get fglrx from linux-restricted-modules-2.6.20-9-generic
<elmo> zul: hmm, how come 3.0.3 and not 3.0.4?
<ogra> seb128, yes ... and even everything is installed, the module doesnt show up anywhere 
<ogra> even if i modprobe ...
<ogra> not even in dmesg ...
<ogra> no error, no success ....
<zul> elmo: because redhat didnt have a kernel for 3.0.3 at the time and 3.0.4 was giving users grief with timing issues
<seb128> ogra: tried to modprobe it from a VT?
<elmo> zul: hmm, ok
<zul> 3.0.5 for feisty+1 though
<ogra> seb128, good idea ... but same symptoms
<seb128> ogra: you should get errors on the command line from a VT
<pitti> seb128: but those errors should appear in kern.log/dmesg, too, no?
<ogra> seb128, nope, absolute silence 
<seb128> pitti: right
<ogra> seb128, are you using fglrx anywhere atm ? 
<seb128> ogra: no, but I can try it quickly on my desktop
<ogra> i wonder if the l-r-m package is broken
<seb128> I tried a week ago and it was working fine
<ogra> well, yesterday it was working fine for me :)
<ogra> until i upgraded and tried out restricted-manager 
<pitti> seb128: use r-m :)
<ogra> r-m- is cool btw ... kudos pitti 
<pitti> seb128: and, before that, please install http://people.ubuntu.com/~pitti/tmp/dexconf
<pitti> ogra: Keybuk did most of the work so far :)
<ogra> the "in use" column doesnt show anything yet ...
<pitti> seb128: to /usr/bin/dexconf; it's uploaded, but not yet on the archive, it fixes the composite setting
<pitti> ogra: the 'in use' column basically does lsmod|grep module
<ogra> ah
<pitti> ogra: but for fglrx we probably need some additional magic, like grepping the X.org log or hacky stuff
<pitti> ogra: unless you happen to know a command or call how to determine the *currently running* X driver?
<torkel> pitti: does r-m magically makes fglrx work with older cards (Mobility FireGL 9000) too? :-)
<pitti> torkel: I don't have an ATI card, I don't know; feedback and bug reports appreciated
<ogra> pitti, usually the lsmod should work as well 
<pitti> ogra: it does for nvidia at least, it won't start up without the module
<pitti> but apparently the fglrx driver can do without DRI
<bddebian> Heya
<ogra> pitti, hmm, right ...
<seb128> pitti: ok, what should I do to try fglrx?
<pitti> seb128: download above dexconf, stick it into /usr/bin
<pitti> seb128: (that will happen once x11-common reaches the archive)
<pitti> seb128: and then just start restricted-manager (make sure to have 0.4) and enable the driver
<torkel> pitti: they have dropped a lot of older cards in later versions of fglrx (see also #83958)
<tepsipakki> torkel: it doesn't magically fix that, no
<torkel> tepsipakki: I know, it was an attempt to a joke
<tepsipakki> torkel: this is serious :)
<Riddell> pitti: I just got both a reject and accept e-mail for xdg-utils, do you know what that's about?
<pitti> Riddell: yes, sorry; first I rejected it because of the wrong .changes
<pitti> Riddell: then I noticed that it was universe in edgy, and accepted it
<pitti> Riddell: for main I'm stricter about following the policy
<Riddell> pitti: ok, thanks
<seb128> pitti: works fine (activating fglrx)
<pitti> seb128: yay!
<pitti> seb128: you have the composite disabling in xorg.conf, too?
<seb128> yep
<seb128> dunno if that's required though
<seb128> I tried without that option and xorg was working fine
<seb128> ogra: there is no fglrx kernel module, that's a video driver BTW, what do you try to modprobe?
<ogra> seb128, ls /lib/modules/2.6.20-9-generic/volatile/
<ogra> do you see fglrx.ko ?
<jdong> BenC: can we have fglrx 8.34.8, pretty please? Fixes suspend and resume.
<seb128> $ ls /lib/modules/2.6.20-9-generic/volatile/
<seb128> ls: /lib/modules/2.6.20-9-generic/volatile/: No such file or directory
<jdong> and oh yeah. xv on amd64 doesn't segfault anymore
<ogra> seb128, hmm, intresting 
<BenC> jdong: Sure
<mjg59> seb128: Uh, there really is an fglrx module
<seb128> mjg59: I'm using fglrx without it
<jdong> BenC: thanks!
<ogra> ogra@edubuntu:~/devel$ dpkg -S /lib/modules/2.6.20-9-generic/volatile/fglrx.ko 
<ogra> dpkg: /lib/modules/2.6.20-9-generic/volatile/fglrx.ko nicht gefunden.
<mjg59> seb128: Can you put xorg.conf somewhere, please?
<ogra> hmm, dpkg disagrees with mjg59 
<BenC> seb128: Then you aren't using the Xorg fglrx in xorg.conf
<mjg59> ogra: Yes, that's because it's a generated file
<ogra> ah
<mjg59> seb128: Also Xorg.0.log
<ogra> mjg59, same goes for me, i'm using fglrx without th ekernel module ... which doesnt show up anywhere or doesnt show any output to modprobe
<seb128> mjg59, BenC: http://people.ubuntu.com/~seb128/xorg.conf
<ogra> i start to suspect l-r-m is borked
<seb128> http://people.ubuntu.com/~seb128/Xorg.0.log
<BenC> the xorg fglrx driver should choke if it can't load the fglrx kernel module
<jdong> ogra: dpkg installs fglrx.o in /lib/l-r-m
<jdong> BenC: actually it doesn't...
<jdong> BenC: it falls back to 2D
<ogra> jdong, yes, i see it 
* jdong eyes nvidia to follow suit....
<ogra> its there, but modprobe remains silent ...
<kylem> ogra, run depmod -a
<kylem> and try again
<mjg59> seb128: You have a /dev/dri/foo. That means there's a kernel driver there.
* lamont grumbles at openoffice
<mjg59> Oh, on the other hand, (WW) fglrx(0): Failed to open DRM connection
<seb128> mjg59: 
<seb128> $ sudo lsmod | grep fglrx
<seb128> $
<mjg59> (WW) fglrx(0): * DRI initialization failed!                  *
<mjg59> (WW) fglrx(0): * (maybe driver kernel module missing or bad) *
<BenC> seb128, ogra: See what "sudo modprobe fglrx" says
<ogra> kylem, did that already  ... but for you ....
<ogra> ogra@edubuntu:~/devel$ sudo depmod -a && sudo modprobe fglrx && lsmod |grep fgl
<ogra> Password:
<ogra> ogra@edubuntu:~/devel$
<kylem> ogra, special.
<ogra> BenC, nothing, not eve in kern.log or anywhere 
<seb128> $ sudo modprobe fglrx
<seb128> FATAL: Error running install command for fglrx
<ogra> oh, you have a modprobe.d file ?
<BenC> sudo /etc/init.d/linux-restricted-modules start
<BenC> there are modprobe.d files
<BenC> calls an lrm tool
<ogra> ogra@edubuntu:~/devel$ sudo /etc/init.d/linux-restricted-modules start
<ogra> sudo: /etc/init.d/linux-restricted-modules: command not found
<jdong> BenC: l-r-m-common
<seb128> $ sudo /etc/init.d/linux-restricted-modules start
<seb128> sudo: /etc/init.d/linux-restricted-modules: command not found
<ogra> hmm
<jdong> lol
<seb128> it's -common
<seb128> make no difference
<BenC> seb128: s/modules/modules-common/
<seb128> $ sudo /etc/init.d/linux-restricted-modules-common start
<seb128>  * Preparing restricted drivers...  
<seb128> $ sudo modprobe fglrx
<seb128> FATAL: Error running install command for fglrx
<jdong> seb128: have cat xorg.conf | grep fglrx?
<ogra> ogra@edubuntu:~/devel$ sudo /etc/init.d/linux-restricted-modules-common start
<ogra>  * Preparing restricted drivers...                                                                                                      [ OK ]  
<ogra> ogra@edubuntu:~/devel$ 
<mjg59> jdong: xorg.conf is fine
<BenC> seb128: Do you even have lrm-commone installed?
<jdong> mjg59: mmm ok
<jdong> they both seem to
<ogra> ogra@edubuntu:~/devel$ sudo modprobe fglrx && lsmod|grep fgl
<ogra> ogra@edubuntu:~/devel$ 
<BenC> or lrm for that matter
<jdong> it's the post-install command that apparently borks out
<jdong> that big ugly sed thing :)
<seb128> ii  linux-restricted-modules 2.6.20.2-9.8             Non-free Linux 2.6.20 modules helper script
<ogra> BenC, until 11:26 am today i had fglrx :) it vanished with an upgrade ... (16:00 now here)
<_ion> '/sbin/modinfo -F alias nvidia' lists a bunch of 'pci:' aliases, but '/sbin/modinfo -F alias fglrx' lists none. Could that be related to the problem at all?
<ogra> BenC, i really think something in l-r-m is broken 
* seb128 installs linux-restricted-modules-2.6.20-9-generic
<BenC> sudo apt-get install linux-generic
<BenC> make sure you have all the meta packages installed
<ogra> ogra@edubuntu:~/devel$ LANG=C sudo apt-get install linux-generic
<ogra> Reading package lists... Done
<ogra> Building dependency tree       
<ogra> Reading state information... Done
<ogra> linux-generic is already the newest version.
<seb128> BenC: I don't have linux-restricted-modules-2.6.20-9-generic installed
<ogra> nope ...
<seb128> installing ...
<BenC> seb128: installing linux-generic should pull it in
<_ion> Even easier: apt-get install linux :-) It depends on linux-generic.
<seb128> BenC: yeah, it does
<seb128>   linux-generic linux-image-generic linux-restricted-modules-2.6.20-9-generic linux-restricted-modules-generic
<BenC> seb128: Ok, so yours we can chalk up to a meta-package desync local to your system
<BenC> ogra: I'm concerned about why yours isn't working. What ATI chip do you have?
<ogra> radeon mobility r200m
<ogra> 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)
<ogra> to be precise
<mjr> xpress 200m is notorious
<ogra> fglrx worked with it at some point ...
<mjg59> If by "notorious" you mean "shit", then yes
<mjr> the DRI developers don't know how to initialize memory for it, dunno about fglrx
<mjg59> But that's not really the point
<BenC> I wonder if the newer driver doesn't support it anymore
<mjr> mjg59, yes I do mean "shit", but true, beside the point. I was just setting up my further comment.
<BenC> anyone know how to get to the latest ATI beta drivers?
<ogra> i havent tried 3D stuff for a while, but it worked before todays upgrade ... which must have been the ats 2.6.20-9 package 
<ogra> *last
<BenC> normal support link goes to 8.32.5
<mjg59> The 200M is supposed to be supported
<ogra> yes
<ogra> the silence of modprobe is very suspicious /me thinks
<jdong> xpress 200m works nowaays
<seb128> BenC: 
<BenC> the feed shows 8.34.8, but doesn't link to the download
<seb128> $ sudo modprobe fglrx
<seb128> FATAL: Error running install command for fglrx
<jdong> I've helped many people get fglrx+xgl to dthat
<mjg59> ogra: What does modinfo fglrx give you?
<seb128> after package install and  sudo /etc/init.d/linux-restricted-modules-common start
<jdong> BenC: go to ATI.com, download Linux drivers for the highest radeon model
<jdong> BenC: their stupid release notes don't link to drivers
<ogra> ogra@edubuntu:~/devel$ modinfo fglrx
<ogra> filename:       /lib/modules/2.6.20-9-generic/volatile/fglrx.ko
<ogra> depends:        agpgart
<ogra> vermagic:       2.6.20-9-generic SMP mod_unload 586 
<ogra> license:        Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY
<ogra> ...
<ogra> seems fine
<seb128>  kernel: [19204.817528]  [fglrx]  Maximum main memory to use for locked dma buffers: 929 MBytes.
<seb128> kernel: [19204.817731]  [fglrx:firegl_init_module]  *ERROR* firegl_stub_register failed
<BenC> seb128: cool, I saw that at dell
<mjg59> Seb loses.
<tepsipakki> :)
<BenC> err, on a dell
<jdong> seb128: are you running amd64 or something?
<ogra> seb128, thats kern.log ? 
<seb128> jdong: i386 distro on an amd64 box
<seb128> ogra: yep
<mjg59> ogra: ls /sys/module/*fgl* ?
<jdong> that shouldn't do it then :(
<seb128> ogra: my computer has no brand ;)
<seb128> ups
<mjg59> jdong: Drivers shouldn't bail out with cryptic errors on load? Shock!
<ogra> ogra@edubuntu:~/devel$ ls /sys/module/*fgl*
<ogra> ls: /sys/module/*fgl*: No such file or directory
<ogra> mjg59, ^^
<seb128> BenC: my computer has no brand ;)
<BenC> seb128: poor thing, you need to help it find an identify :)
<ogra> ogra@edubuntu:~/devel$ grep fglrx /var/log/kern.log
<ogra> ...
<ogra> Mar  9 11:26:57 edubuntu kernel: [663600.348000]  [fglrx]  max single Inv  = 0
<ogra> Mar  9 11:26:57 edubuntu kernel: [663600.348000]  [fglrx]  total      TIM  = 0
<ogra> ogra@edubuntu:~/devel$ date
<ogra> Fr 9. Mr 16:08:33 CET 2007
<mjg59> ogra: In that case, the modprobe.d fragment is under the impression that you don't need fglrx, and so is refusing to load it
<seb128> BenC: :)
<jdong> mjg59: usplash shouldn't destory all my vt's? *shock* (kidding!)
<ogra> mjg59, hmm ... l-r-m common intalls these snippets ? 
<mjg59> Yes
<BenC> the modprobe.d just calls a script in lrm-common
<BenC> install fglrx /sbin/lrm-video fglrx $CMDLINE_OPTS
<ogra> ogra@edubuntu:~/devel$ LANG=C dpkg -S  /etc/modprobe.d/fglrx
<ogra> dpkg: /etc/modprobe.d/fglrx not found.
<ogra> intresting
<lamont> doko_: you around?
<BenC> so you can actually do: sudo lrm-video fglrx
<lamont> doko_: how come oopenoffice.org says it built successfully on ia64, but didn't deliver openoffice.org-writer?
<BenC> ogra: /etc/modprobe.d/lrm-video
<ogra> right 
<ogra> i wonder if that fglrx file pverrides it
<ogra> *overrides
<ogra> and where that comes from ... i surely didnt create it
<mjg59> ogra: They're shell scripts. It's easy to have a play.
<BenC> ogra: $ dpkg -S /etc/modprobe.d/lrm-video  linux-restricted-modules-common: /etc/modprobe.d/lrm-video
<BenC> missing \n, but it's lrm-common
<ogra> BenC, i meant /etc/modprobe.d/fglrx in my dir ...
<BenC> ogra: Oh, that sounds like just you :)
<ogra> i didnt create it
<BenC> the lrm-video has been in use since I started in ubuntu, IIRC
<ogra> and fglrx worked until last upgrade ... 
<BenC> ogra: Try removing that file
<BenC> see if things work after that
<doko_> lamont: libmythes-dev only; you didn't port ooo, did you?
<ogra> ogra@edubuntu:~/devel$ sudo mv /etc/modprobe.d/fglrx .
<ogra> ogra@edubuntu:~/devel$ sudo modprobe fglrx
<ogra> ogra@edubuntu:~/devel$ lsmod |grep fgl
<ogra> nope
<tepsipakki> ogra: check /var/log/dpkg.log for changes after you had it working
<doko_> lamont: but I can make it ftbfs for you ;-p
<torkel> ankpelle:~# dpkg -S /etc/modprobe.d/fglrx
<torkel> xorg-driver-fglrx: /etc/modprobe.d/fglrx
<BenC> interesting that there's an override on that
<BenC> torkel: What does the file contain?
<ogra> install fglrx if cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \\t] *section[ \\t] *"device"/I,/^[ \\t] *endsection/I{/^[ \\t] *driver[ \\t] */I{s/^[ \\t] *driver[ \\t] *"*//I;s/"*[ \\t] *$//;p}}' | grep -q -w fglrx; then modprobe --ignore-install -Qb $CMDLINE_OPTS fglrx; else echo "Not loading fglrx module; not used in /etc/X11/xorg.conf" 1>&2; fi
<ogra> only one line 
<BenC> that is so ugly
<ogra> yeah
<BenC> generally, it's the xorg driver that loads it, so I suspect that snippet is overkill
<BenC> except to save people who manually add fglrx to /etc/modules or something
<BenC> I wonder if that's from ati's driver...maybe I could just leave it out
<BenC> The /sbin/lrm-video script has a similar snippet
<BenC> so it is overkill
<BenC> cat /etc/X11/xorg.conf | sed -n -e '/^[ \t] *section[ \\t] *"device"/I,/^[ \t] *endsection/I{/^[ \t] *driver[ \t] */I{s/^[ \t] *driver[ \t] *"*//I;s/"*[ \t] *$//;p}}'
<BenC> ogra: What does that command output for you?
<ogra> AHA !!!!
<ogra> ogra@edubuntu:~/devel$ sudo insmod /lib/modules/2.6.20-9-generic/volatile/fglrx.ko 
<ogra> ogra@edubuntu:~/devel$ lsmod |grep fglrx
<ogra> fglrx                 527192  0 
<ogra> agpgart                33480  2 fglrx,ati_agp
<ogra> ogra@edubuntu:~/devel$ sudo modprobe fglrx
<ogra> ogra@edubuntu:~/devel$ lsmod |grep fglrx
<ogra> ogra@edubuntu:~/devel$
<kylem> oh.
<ogra> modprobe is broken !
<jdong> BenC: no, the xorg driver makes no attempt at loadking fglrx.ko....
<jdong> (that's nvidia you're thinking of)
<jdong> most people do put fglrx in /etc/modules
<BenC> ogra: Most likely the lrm-video and fglrx modprobe.d snippet isn't liking your xorg.conf...what does that cat/sed command above shows for you?
<ogra> ogra@edubuntu:~/devel$ cat /etc/X11/xorg.conf 2>/dev/null | sed -n -e '/^[ \\t] *section[ \\t] *"device"/I,/^[ \\t] *endsection/I{/^[ \\t] *driver[ \\t] */I{s/^[ \\t] *driver[ \\t] *"*//I;s/"*[ \\t] *$//;p}}' | grep -q -w fglrx
<ogra> ogra@edubuntu:~/devel$ 
<BenC> jdong: Ah, I thought fglrx tried to load it like nvidia
<ogra> niente ....
<BenC> ogra: Minus the final grep, what does it actually output
<ogra> nothing either
<pitti> jdong: btw, sorry for so many needsinfo sync bugs; the backports process was more or less dead for quite a while, but it's settled now
<BenC> ogra: And use the one I pasted, since that's the one lrm-video uses
<jdong> pitti: no sweat, thanks archive team for all the backports processed :)
<BenC> ogra: Uploading your xorg.conf somewhere would be nice too
<ogra> BenC, fglrx
<kylem> i don't think you can have the kernel agp drivers loaded along with fglrx... i think you need to blacklist them...
<BenC> ogra: So the fglrx modprobe.d file is broken
<ogra> BenC, but removing it doesnt fix it
<jdong> kylem: no, that's fine....
<jdong> I've had a few bad runins with the insmod sedjob thingie
<ogra> BenC, http://people.ubuntu.com/~ogra/xorg.conf
<ogra> its freshly generated 
<jdong> where it would not believe at times fglrx is needed
<ogra> two hours ago or so
<ogra> BenC, what bothers me is that insmod works but modprobe doesnt 
<lamont> doko_: ooffice was using ia32-libs-openoffice.org on ia64 and amd64 - did that change?
<doko_> lamont: we don't have the ia32 package anymore (builds native on amd64), already in edgy
<lamont> figures
* lamont wonders if maybe lying to oo.o and pretending it's amd64  will do the trick... how much asm is there?
<BenC> ogra: modprobe --ignore-install -Qb fglrx
<BenC> oops
<BenC> ogra: modprobe --ignore-install -Qb fglrx
<BenC> that'll probably work
<ogra> wait ...
<ogra> ogra@edubuntu:~$ modprobe --ignore-install -Qb fglrx
<ogra> ogra@edubuntu:~$ lsmod |grep fgl
<ogra> nop
<BenC> ogra: Run depmod -a
* lamont ponders where in the cube to stick his zx2000 for actual use.
<ogra> did that several times ... but will do again
<kylem> lamont, duct taped to the ceiling.
<BenC> ogra: Does "modinfo fglrx" show it?
<ogra> ogra@edubuntu:~$ sudo depmod -a
<ogra> ogra@edubuntu:~$ modprobe --ignore-install -Qb fglrx
<ogra> ogra@edubuntu:~$ lsmod |grep fgl
<ogra> ogra@edubuntu:~$
<lamont> kylem: iz t-bar ceiling --> won't hold it
<ogra> ogra@edubuntu:~$ modinfo fglrx
<ogra> filename:       /lib/modules/2.6.20-9-generic/volatile/fglrx.ko
<ogra> depends:        agpgart
<ogra> ...
<ogra> all fine
<BenC> ogra: does "rgrep fglrx /etc/modprobe.d/" show any other references?
<BenC> ogra: and did you remove /etc/modprobe.d/fglrx?
<ogra> /etc/modprobe.d/blacklist-restricted:blacklist fglrx
<ogra> ugh
<BenC> feh
<ogra> where does that come from ? 
<jdong> lol
<BenC> I don't have that file
<jdong> ogra: can I buy you a legal nonalcoholic beverage next time I see you?
<jdong> :D
<BenC> ogra: Did you get OSS anal one day and add that file? :)
<ogra> BenC, me neither
<ogra> ogra@edubuntu:~$ LANG=C dpkg -S /etc/modprobe.d/blacklist-restricted
<ogra> dpkg: /etc/modprobe.d/blacklist-restricted not found.
<ogra> ogra@edubuntu:~$ cat /etc/modprobe.d/blacklist-restricted
<ogra> # This file is used to disable restricted drivers
<ogra> blacklist fglrx
<BenC> sudo apt-get --purge remove rms
<ogra> ogra@edubuntu:~$ ls -lh /etc/modprobe.d/blacklist-restricted
<ogra> -rw-r--r-- 1 root root 66 2007-03-09 12:53 /etc/modprobe.d/blacklist-restricted
<jdong> BenC: RMS found his ssh key....
<ogra> and its brandnew
<ogra> pitti, ??? ^^^
<ogra> does r-m create it ? 
<jdong> oh wtf BenC you already made an RMS joke :D
<BenC> ogra: I just did a dist-upgrade and don't have that file
<BenC> and I have lrm+lrm-common installed
<BenC> brb
<ogra> BenC, did you use restricted-manager to switch it on and off ? 
<Keybuk> ogra: you fired up r-m and disabled it then <g>
<Keybuk> restricted-manager --enable fglrx
<ogra> Keybuk, i disabled and enabled it through the gui as that was my testcase for pitti :)
<Keybuk> you didn't enable it hard enough <g>
<ogra> but i cant enable it again ...
<ogra> heh
<Keybuk> what does that command say?
<jdong> "FreeSoftwareError: RMS is going to murder you"
<ogra> Must be run as root :P
<Keybuk> jdong: I did originally name it "Restricted Module Setup"
<ogra> Keybuk, "fglrx is already enabled"
<Keybuk> ogra: I assume you know what to do next
<ogra> :)
<jdong> Keybuk: HA! that's priceless
<ogra> Keybuk, but still
<ogra> ogra@edubuntu:~$ cat /etc/modprobe.d/blacklist-restricted
<ogra> # This file is used to disable restricted drivers
<ogra> blacklist fglrx
<jdong> can anyone reproduce?
<pitti> tfheen: could you please throw a look at bug 85403? both elmo and seb128 think that's a good idea
<Ubugtu> Malone bug 85403 in vnc4 "ship xvnc4viewer by default (in main)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85403
<Keybuk> ogra: you must have disabled it with an earlier version of restricted-manager
<jdong> (not biologically, that bug)
<Keybuk> just remove that file
<Keybuk> (pitti has added an fglrx module handler to it)
<ogra> Keybuk, indeed, that might be
<pitti> ogra: ah, it was still blacklisted? now that explains a lot :)
<Keybuk> r-m uses the blacklist to enable/disable modules when there's no specific handler for it
<ogra> yeah
<seb128> jdong: hi
<ogra> works fine now :)
<Keybuk> but when there's a specific handler, it doesn't use the blacklist since the specific handler overrides the enable() function :p
<pitti> ogra: however, this transition should be handled more cleanly; can you please file a bug for me to remember?
<ogra> will do
<pitti> ogra: in this case the enabling/disabling should *also* handle module blacklisting
<seb128> jdong:is somebody else authorized to approve backport requests?
<pitti> ogra: thanks a lot!
<ogra> tanks for the help :)
<ogra> *thanks as well :)
<BenC> ogra: No, haven't touched that. Maybe that's it
<jdong> seb128: imbrandon, slomo_, anyone on the Backports team I fully trust to approve them
<cjwatson> seb128: ubuntu-backporters team, or at least that's who I've been trusting
<ogra> BenC, yes, its the r-m 0.3 version i used ... 
<seb128> jdong: ok, because I did a round of edgy backports approval yesterday, I was not sure who else than you is authorized to do that, do you use a special status like "In Progress" when the backport has been accepted? 
<seb128> random people do +1 on bugs
<jdong> seb128: In Progress == accepted
<seb128> it's not clear if they are accepted or not though
<seb128> cjwatson: ok
<jdong> seb128: +1 people are my testing drones... only In Progress counts :)
<seb128> jdong: ok
<jdong> well, off to lecture
<jdong> will see everyone later :)
<seb128> pitti: did you process the backports today?
<pitti> seb128: yes, all of them
<seb128> pitti: utch :/
<pitti> seb128: well, except those which aren't confirmed, of course
<seb128> pitti: you did backport a lot of things not accepted I think
<seb128> pitti: "confirmed" is not to backport
<seb128> "in progress" are those to backport
<pitti> seb128: right
<pitti> seb128: I meant 'I looked at all the backport bugs, did the ones with jdong's approval, and triaged the rest'
<pitti> seb128: I set back some to needsinfo which were out of sync, for example
<pitti> and which had been inprogress before
<seb128> weird, there was like backports 30 bugs open yesterday and ubuntu-archive list of subscribed bug is 18 bugs today
<seb128> did you close all the "SRU should be consider first"?
<seb128> there was a bunch of them
<pitti> seb128: right, I did my best to clean up u-archive/+subedbugs
<seb128> ah ok
<pitti> seb128: I unsub'ed u-archive from the SRUs
<pitti> seb128: since they cannot be fixed immediately, and ubuntu-sru/+subscribedbugs is much better for this
<pitti> they just clutter up the archive team bug list
<seb128> pitti: I don't do sru, I just looked at backport yesterday
<pitti> tfheen: can you please give-back libkexiv2? fixed pkgbinarymangler is in the archive now
<seb128> I'm just surprised that you manager to reduce the backport list so much
<seb128> managed
<seb128> I had the impression than many of them were waiting on approval yesterday
<pitti> seb128: *shrug*, there were some approved dapper-backports requests where you only did the edgy one
<pitti> seb128: feel free to check the list, but I'm fairly sure I checked them correctly
<seb128> I did backports for the first time yesterday, just wondering if I'm too cautious
<pitti> seb128: maybe the confusion comes from the bug status
<seb128> not questioning what you did
<pitti> seb128: it's likely that there were approved bugs with 'confirmed' status
<pitti> seb128: I looked at the actual bug comments and 'approved' mails from jdong
<seb128> pitti: ok, in fact I got confused because you changed to Needs Info the things that need to be confirmed
<seb128> that's all fine ;)
* pitti hugs seb128, great
* seb128 hugs pitti back
* pitti is happy that fglrx now works for both seb128 and ogra, thanks for testing
<seb128> np
<ogra> :)
<seb128> I'll be back to ati to next xorg restart though :p
<seb128> I prefer composite to 3d ;)
<ogra> i whish comosite would work for me
<ogra> *composite
<pitti> seb128: right, if the free driver works, so much the better
<seb128> yeah
<seb128> pitti: I'm confused by https://launchpad.net/~ubuntu-archive/+subscribedbugs now :/
* ogra wants sockets for graphics boards in laptops 
<pitti> seb128: however, compiz gets better - I managed to work with it yesterday for a whole 30 minutes! that's absolute record so far
<seb128> pitti: it used to list all the edgy-backport tasks, no?
<pitti> seb128: right
<pitti> seb128: it still lists some which are needsinfo and such
<seb128> k, that's why the list changed so much
<seb128> there is still lot of bugs open on https://bugs.launchpad.net/edgy-backports/+bugs
<seb128> ubuntu-archive is just not subscribed to them
<pitti> oh, indeed
<pitti> I never looked at the edgy-backports/+bugs page
<seb128> yesterday there was like 40 bugs I did close
<seb128> I didn't get how you manager to close them
<elmo> oh
<seb128> well, lp must have changed
<seb128> or teams
<elmo> there are a bunch of backport bugs assigned to me
<seb128> because yesterday they were listed on ubuntu-archive subscribed
<pitti> seb128: no, probably those bugs have never been subscribed to u-archive
<elmo> could someone redirect them somewhere appropriate?  they may also be entirely obsolete
<seb128> they were yesterday
<pitti> seb128: are you sure?
<seb128> hum, no
<pitti> elmo: those all belong to {dapper,edgy}-backports product? if so, we'll get them
<seb128> pitti: k, maybe I switching from ubuntu-archive/+bugs to edgy-backport/+bugs yesterday while working
<elmo> pitti: breezy-backports actually :)
<seb128> switched
<pitti> elmo: *cough* not worth bothering about those, I guess
<pitti> seb128: I'll walk though those lists again
<seb128> pitti: I did read almost all the edgy backports bugs yesterday, not real need to bother with them
<seb128> feel free to do the dapper ones if you want ;)
<pitti> alright
<elmo> The Ubuntu list servers are going down for 30 mins or so for a hardware upgrade.  
<seb128> pitti: good work on the ubuntu-archive list of bugs BTW, nice to have it so short again ;)
* seb128 hugs pitti
<pitti> seb128: then let's formalize this by unsub'ing u-archive from the rest of the backports bugs and I'll change the wiki page
<seb128> pitti: ok, thank you
<seb128> only backports that need to processed should have ubuntu-archive subscribed
<pitti> seb128: why, filtering the products for confirmed+inprogress does this more reliably, right?
<seb128> alright, that works as well
<pitti> seb128: but as you wish, I can leave them subscribed
<seb128> "in progress" only
<pitti> but personally I prefer canned searches over manual subscribing
<seb128> jdong said those are the ones approved
<pitti> ok, if we can rely on that, sure
<pitti> seb128: yay, https://launchpad.net/~ubuntu-archive/+subscribedbugs is even shorter now :)
* seb128 hugs the great pitti
<seb128> awesome work ;)
<geser> keescook: I've prepared debdiffs for gpgme1.0 at bug #90864
<Ubugtu> Malone bug 90864 in gpgme1.0 "Debdiff to fix CVE-2007-1263 in feisty and edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90864
<keescook> geser: you rule!  thank you!  :)
<siretart> keescook: thanks for your patch in debbugs! did you see the additional hunk A Menucc posted?
<keescook> siretart: I just started checking email.  what's the url?
<siretart> keescook: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414072;msg=12
<Ubugtu> Debian bug 414072 in xine-lib "Bug#414072: CVE-2007-1246: DMO decoder heap allocation overflow" [Grave,Closed]  
<keescook> siretart: cool, thanks.
<j1mc> hey all, per the instructions near the bottom of this page (https://wiki.ubuntu.com/Testing/ReportingResults), shouldn't new "bugs" be created for each nightly release for ISO testers to report their results (see here:  https://bugs.launchpad.net/ubuntu-iso-tests/+bugs)?  it looks like we're a bit behind.
<j1mc> should individual testers just create a new "reporting bug" if one doesn't already exist for their most recent nightly image?
<ogra> KMAP=$(echo "get xserver-xorg/config/inputdevice/keyboard/layout"|debconf-communicate 2>/dev/null|cut -d ' ' -f 2)
<pochu> j1mc: no, individual testers shouldn't create bugs, just comment existing ones
<pochu> j1mc: looking the wiki
<ogra> ^^ does anybody have a hint how to make that return noting if the debconf value doesnt exist ? 
<ogra> *nothing
<ogra> seems denconf communicate just reached the path through if xserver-xorg/config/inputdevice/keyboard/layout isnt existing
<ogra> *reaches
<j1mc> pochu: are the last set of images created really from 20070302, or are people just behind in creating new reporting bugs?
<pochu> j1mc: the last images are of today,
<pochu> j1mc: people shouldn't create them
<j1mc> pochu: sorry for any confusion, but ( https://bugs.launchpad.net/ubuntu-iso-tests/+bugs ) only shows xubuntu builds as of March 1st.
<j1mc> of course, you can download nightlies that are more recent than that.
<pochu> j1mc: the reports are for testing the release candidates (herd candidates, beta candidates...) but not for testing daily builds
<pochu> j1mc: so all the reports are all
<pochu> tfheen: am I right? (not sure hehe)
<pochu> j1mc: the reports are done by a script, so you shouldn't create new reports
<j1mc> pochu: thanks . . .   do you know where should testers be reporting results off of nightly images?  
<pochu> j1mc: I think there is no need to report results of daily builds, ATM
<pochu> j1mc: just reports bug against the right packages :)
<angasule> is there a #ubuntu-games-devel channel? or anyone who cares about games on ubuntu? the current status isn't very good
<j1mc> pochu: thanks.  :)  i'll relay this to the xubuntu testers.  i take it that nightly tests will pick back up as we approach the first beta?
<pochu> j1mc: but we are going to test the images for the beta this weekend, so we should create reports for that
<j1mc> :-)
<pochu> j1mc: sure :)
<j1mc> pochu: thanks . . .  talk to you later.
<pochu> j1mc: when you want :)
<pochu> j1mc: and thanks for you work ;)
<j1mc> pochu: you're welcome!  
<jdong> ha. Ubuntu. gaming
<jdong> the only game is let's see if Xgl can break even more.
<seb128> jdong: are some people still using Xgl?
<angasule> anyone? I was thinking ubuntu could include an updated OpenAL (the current version is years old) as well as some other libraries that are good for games
<angasule> seb128: quite a few, I hear a few mentions of xgl on #beryl every now and then
<jdong> seb128: fglrx people have no choice
<jdong> seb128: and nvidia-legacy people
<seb128> jdong: why?
<jdong> seb128: no AIGLX
<seb128> ?
<seb128> no composite you mean?
<jdong> the drivers do not support AIGLX
<jdong> no composite, too
<jdong> glx_ext_texture_from_pixmap
<mjg59> The drivers do support aiglx
<mjg59> They don't support glx_ext_texture_from_pixmap
<jdong> seb128: and for most desktop effects, Xgl is actually faster/smoother. Many nvidia MX440 users I know choose Xgl
<jdong> because effects are markedly smoother.
<jdong> especially full screen video textures
<mjg59> It's still not trivially supportable
<angasule> of course, MX440 and the like should die as soon as possible...
<jdong> mjg59: at least it should not be totally borken in feisty
<jdong> :(
<jdong> mjg59: please?
<seb128> fglrx and aiglx work fine on my desktop
<jdong> I'm on my knees and begging about this
<jdong> seb128: WHAT?
<seb128> there is no composite, out of that it works fine
<jdong> seb128: how do you have AIGLX???
<seb128> install feisty
<jdong> seb128: I am on feisty.
<mjg59> jdong: aiglx isn't difficult. It's just not what you want.
<seb128> use restricted-manager and click ati
<jdong> seb128: you cannot start beryl/compiz
<seb128> no, there is no composite
<jdong> seb128: no glx_ext_texture_from_pixmap
<jdong> that's what matters at the end of the day.
<seb128> I'll patch compiz with the no-tfp patch
<mjg59> jdong: AIGLX does not mean what you think it means
<jdong> mjg59: hmm ok
<jdong> seb128: cool, analogous to Beryl's "Copy" mode?
<mjg59> seb128: Is that useful without composite?
<jdong> seb128: it still needs Composite, no?
<seb128> mjg59: it makes it work when glx_ext_texture_from_pixmap is not available
<mjg59> If not, I wouldn't bother
<jdong> seb128: that still requires composite to work right?
<mjg59> seb128: glx_ext_texture_from_pixmap is available on all the systems we support
<seb128> jdong: I don't know much about beryl
<seb128> mjg59: it's not with fglrx
<mjg59> seb128: But fglrx doesn't support composite when 3D is enabled
<jdong> seb128: and compiz works on fglrx with that patch?
<mjg59> So you can't run compiz
<seb128> hum
<jdong> seb128: DRI acceleration and Composite are mutually exclusive in fglrx
<jdong> turn on one and the other is forced off
<seb128> Nicolas who works on compiz and sent me the patch told me it makes compiz work with fglrx
<seb128> I need to try
<jdong> seb128: hum, I'd love to hear if that works
<Skorgu|Work> Is this the right place to ask a packaging question (about my own package, not an ubuntu one)?
<jdong> nope....
<jdong> -motu at best
<Skorgu|Work> thanks
<keescook> geser: have you got any time to snag gnupg2's 2.0.3 release?  I need to backport that to edgy too, but it seems they only released patches for gpg and gpgme.  I suspect it'll be close to the gpg patch.
<geser> keescook: I've packages ready for 2.0.3 but not a separated patch for it
<geser> the diff between 2.0.2 and 2.0.3 isn't that large
<keescook> geser: cool, I can do the edgy patch.  do you have a UVFe open for 2.0.3?  That should be pretty easy to get approved, and then I can upload it for you.
<geser> I've send a mail to tfheen and cjwatson but not opened a bug for it
<geser> keescook: but you can find it on http://members.ping.de/~mb/gnupg2/
<keescook> geser: great, thanks!
<sistpoty> tfheen: did ubuntu-archive come to a decision about removing binary packages of unsupportable software yet?
<jdong> wait, before Xgl goes, can I make a eulogy?
<jdong> meh I still need to write one up
<cjwatson> ogra: the first bit of the output from debconf-communicate will be something other than "0" if the question doesn't exist
<ogra> yeah
<ogra> i got it fixed 
<cjwatson> ogra: is there a reason you can't just . /usr/share/debconf/confmodule and do if db_get xserver-xorg/config/inputdevice/keyboard/layout; then KMAP="$RET"; else KMAP=; fi ?
<cjwatson> (there might be such a reason - just wondering)
<ogra> no, there is none ...
<ogra> i was just lazy copying the other preseed code we use in the initscript for setting preseed values 
<cjwatson> hmm, I don't think it's a good idea for an initscript to load debconf
<angasule> is this the place to discuss versions of included libraries and general game support or not?
<cjwatson> better to do that in a maintainer script
<ogra> well, the ltsp-client initscript needs to preseed the X values if they are set in lts.conf ...
<ogra> we use it like that since the first release
<ogra> the current code i'm working on is rather to preseed the chroot values from the server during chroot build ...
<jdong_> noooooooo my ghost died
<ogra> your code looks a lot better than mine, so i'll use it ;)
<cjwatson> ok
<mmax> hi, I'm running edgy with edgy-backports actived and there is a problem with a package from backports, is it the good place to speak about that and to expose the problem?
<pochu> mmax: from what repository?
<mmax> http://archive.ubuntu.com edgy-updates/main
<jdong_> mmax, that's not backports, that's edgy-updates
<jdong_> but yeah, this can be a good place to discuss issues
<mmax> sorry
<mmax> http://archive.ubuntu.com edgy-backports/main
<jdong_> ok, that's me.
<mmax> past/copy error ;)
<jdong_> what's up?
<mmax> I have done an upgrade and libgphoto2-2 version 2.3 has been installed from backports
<mmax> there is a problem (not critical) with the udev rules generated by the postinstall script of this package
<mmax> the rules are created for udev >=0.98 but edgy provides 0.93, so at booting I saw lots of these two error messages repeated many times:
<mmax> add_to_rules: unknown key 'ATTRS{idVendor}'
<mmax> add_to_rules: unknown key 'ATTRS{idProduct}'
<jdong_> lovely...
<mmax> so I manually replace ATTRS by former SYSFS in this rules file
<jdong_> that wasn't an issue when the backport was initially approved
* jdong_ stifles some grumbles
<mmax> the line in the post-install script is:
<jdong_> but yeah, I will after class prepare an upload that fixes the issue
<jdong_> cjwatson, you ok with sponsoring a fix to mmax's bug?
<mmax> print-camera-list udev-rules-0.98 mode 0660 group plugdev etc.
<cjwatson> jdong_: sure
<jdong_> (s/ATTRS/SYSFS/)
<cjwatson> mail me a debdiff
<mmax> and should replace udev-rules-0.98 argument by udev-rules in order to generate rules for udev < 0.98
<jdong_> cjwatson, should I prepare a debdiff or is it trivial enough that you can handle it?
<cjwatson> jdong_: I'd rather you did it and tested it and such, I'm kinda swamped
<mmax> or another solution would be to get udev version with udevinfo, and the script woulb be compatible with any version of udev
<jdong_> cjwatson, yeah sure
<jdong_> mmax, well fixing the package is an easier way
<jdong_> mmax, I've filed bug 90905 against gphoto, I will prepare a fix in about 1:30h
<Ubugtu> Malone bug 90905 in libgphoto2 "Should depend on newer udev" [Undecided,Unconfirmed]  https://launchpad.net/bugs/90905
<jdong_> mmax, thanks for letting me know
<sistpoty> can we sync from debian/testing as well?
<mmax> ok
<cjwatson> sistpoty: yes
<sistpoty> greate!
<sistpoty> -e
<mmax> thanks to have listening to me
<dadi> besoin d'info sur la construction de paquets de lib et lib-dev
<pochu> dadi: tu veux #ubuntu-fr :)
<dadi> scuze merci
<pochu> de rien
<jdong_> pochu, you hablo jamaican?
<jdong_> didnt' know that!
<pochu> jdong_: jajaja
<pochu> :)
<jdong_> pochu, ey manne!
<keescook> geser: if you make a bug for UVFe on gnupg2, I can upload it when it's been +1'd.  I've got it built and ready for upload.  :)
<geser> is it bug + mail or only mail to get an UVF exception in main?
<keescook> geser: I've always just done bugs, but I haven't done that many...
<keescook> I figure a bug is better in case other people want the same UVFe.  :)
* geser files bugs to be on the safe side
<EtienneG> hey guys
<EtienneG> I would need a sponsor for bzr/bzrtools
<EtienneG> I also have bzr-gtk, but I can ask a MOTU for that one
<lamont> sigh.  ENODOKO
<dholbach> have a nice evening everybody! see you next week!
<kylem> take care, dholbach 
<dholbach> kylem: you too :-)
<bddebian> Later dholbach
<dholbach> bye bddebian
* dholbach packs his record bag
<jdong> cjwatson: I've attached the debdiff onto bug 90724
<Ubugtu> Malone bug 90724 in libgphoto2 "March 8 2007 updates caused EPSOn CX6400 to not be recognised" [High,Confirmed]  https://launchpad.net/bugs/90724
<wick2o> evening
<cjwatson> jdong: please do mail me a note at least, otherwise I'm guaranteed to forget
<jdong> cjwatson: ok, sure
<tepsipakki> uh, lp doesn't allow to close old bugs which are marked for xserver-xorg-driver-* if xorg is already marked for that bug
<tepsipakki> since it would rename the component to xorg which it can't do
<greff> Hello. If any package maintainer / developer here has enough free time to manage a few new packages, then can he/she please look into adding pam_cups and pam_script into the Ubuntu repositories?
<jdong> greff: -motu, better luck there
<LaserJock> we're also a fair ways past NewPackageFreeze (or whateve we're calling it)
<Fujitsu> LaserJock: NewPackagesFreezeUnivere, in fact.
<Fujitsu> greff: You'll likely have to wait until after April.
<jdong> ha, the new package police is out in full patrol!
<jdong> testing alarm system.... fglrx. x264. mencoder. xgl. beryl.
* Fujitsu screams.
<jdong> lol
<Fujitsu> Beryl! Attack!
<jdong> Do a beryl roll!
<jdong> wow, that was a bad pun.
<bhale> ugh beryl
<mdke> elmo: any progress on the screencasts.u.c request?
<cjwatson> jdong: still around?
<cjwatson> jdong: I don't think that fix is right - there are other keys to change
<jdong> cjwatson: oh, there are?
<mdke> does anyone's ipods work? Or is it just me?
<cjwatson> jdong: can I suggest instead changing udev-rules-0.98 to udev-rules in debian/libgphoto2-2.postinst?
<jdong> mdke: mine works fine.
<cjwatson> that seems to be the "approved" method
<mdke> jdong: aha. I'll go to lp then
<mdke> ty
<jdong> cjwatson: hmm, I'm really a clueless one when it comes to udev and friends
<cjwatson> jdong: would be nice to try it out on an edgy-backports system ...
<cjwatson> sudo sh -c '/usr/lib/libgphoto2/print-camera-list udev-rules mode 0660 group plugdev > /etc/udev/rules.d/45-libgphoto2.rules'
<jdong> cjwatson: yeah; I was under the impression that line caused the problems
<cjwatson> jdong: right, but before it was "udev-rules-0.98" not "udev-rules"
<jdong> and I grepped for ATTRS and that was all that came up code-wise
<cjwatson> if you read the source for print-camera-list, it has switchability built in
<cjwatson> you just need to call it with a different argument and you'll get SYSFS instead of ATTRS and BUS instead of SUBSYSTEM
<jdong> cjwatson: oh, oops, how embarrasing :)
<jdong> cjwatson: one general concern regarding this kind of situation.... if on a backports request I approve a particular version, will archive be able to process that version?
<jdong> cjwatson: this situation only happened because the backport was processed some month after it was approved
<cjwatson> sorry, what do you mean?
<cjwatson> ah
<cjwatson> um, can be difficult, the tool can only backport from whatever's current in a suite
<cjwatson> s/suite/distrorelease/
<jdong> hmm
<cjwatson> best fix is really just for us to be better about processing them quickly
<jdong> the unpredictable archive turnaround time is a plaguing issue :(
<cjwatson> or possibly to add intelligence to the tool to let us specify a version so that it will fail if there's a mismatch
<crimsun> elmo: is the affected laptop in LP #88332 running the latest BIOS revision?
<cjwatson> jdong: how about http://people.ubuntu.com/~cjwatson/tmp/90724.diff ?
<jdong> cjwatson: yeah, a quick test-run on my feisty box does confirm that command generates SYSFS{} rules
<cjwatson> jdong: I've diffed the rules output and it looks sensible
<cjwatson> righto, I'll go with that then
<jdong> cjwatson: yeah, awesome :)
<cjwatson> ok, should build RSN
<cjwatson> jdong: off to bed now, if it breaks shout and either I'll look at it at some point tomorrow or somebody will beat me to it
<jdong> cjwatson: haha, ok, hopefully that closes off This Month in Backports :D
<greff> Can dh_make handle zip source archives?
#ubuntu-devel 2007-03-10
<blanky> anyone here know about packaging?
<blanky> er, I made a debian package but my friend said to "Drop dependency on libc6 >= 2.4-1 down to something more reasonable", he has 2.3.6, how can I change this?
<Fujitsu> You would need to rebuild it on a system with an older version of glibc.
<blanky> Fujitsu: seriously?! I can't do it on my system in any way?
<blanky> Fujitsu: I can't install an older version and build it with that
<Fujitsu> YOu could create a chroot of a previous Ubuntu release that uses glibc 2.3.
<Fujitsu> But having multiple libc6s is unlikely to be a good idea at all.
<Fujitsu> So a chroot is the best idea.
<blanky> Fujitsu: So, my package (It's a tiny C program that just does basic network stuff) won't run on his older version at all?
<blanky> I MUST rebuild?
<cjwatson> it depends, but it's certainly entirely possible that *when built with the new libc6* it requires the new libc6
<Fujitsu> libc6 isn't backward-compatible, as far as I know, hence the dependency.
<Fujitsu> What cjwatson said.
<cjwatson> that's the reason that automated dependency is there - because binaries built with the newer library can require it
<cjwatson> it actually depends on the exact versioned symbols they use, but our dependency generation isn't fine-grained enough to detect that at the moment
<blanky> oh okay
<blanky> okay thanks guys, so what do you suggest I do (If you don't mind giving in input)
<cjwatson> it's generally a very, very bad idea for source packages to override it, even so
<cjwatson> blanky: I entirely agree with Fujitsu; build it in a chroot
<cjwatson> it shouldn't take long to set one up using debootstrap
<blanky> cjwatson: thanks. I'm new to package building (This one's my first) and so I'm not really sure what that means, so just read up on chroot right? Or something in specific
<blanky> oh okay, debootstrap
<cjwatson> sudo apt-get install debootstrap; man debootstrap; man chroot
<blanky> thanks cjwatson 
<cjwatson> you're welcome
<wick2o> this may be the wrong place to ask, but anyone know where i might get some help rebuilding an install cd?
<wick2o> i have apt-get download source and modifed the packages in the ubuntu-meta-standard
<cjwatson> wick2o: https://help.ubuntu.com/community/InstallCDCustomization
<wick2o> repackaged it, created my own keyring
<wick2o> and then fixed the md5sum
<wick2o> but when i try and install from my new cd debconf tells me the keyring and other package i modified was corrupt
<wick2o> cjwatson: been there and done that
<cjwatson> sounds like you didn't modify the Packages and Release and Release.gpg files correctly
<cjwatson> though I cannot be any more accurate without an exact (not paraphrased) error message
<wick2o> ummm, my impression was that was only needed when adding an "extras" repos
<wick2o> but now that i think of it you could be right
<wick2o> if Packages references a MD5 or a file size
<cjwatson> if you're modifying any packages, you must change the index files to reflect that
<cjwatson> Packages does
<cjwatson> (both)
<wick2o> ahh
<jdub> cjwatson: intersting changes to desktop depends/recommends
<cjwatson> most of which were mdz's
<cjwatson> I agree though, and it's in response to consistent review feedback
<jdub> mmm, something written up about those, or...?
<cjwatson> bzr log says:
<cjwatson>   Mark more desktop entries as recommended.  Our guiding philosophy should be
<cjwatson>   that the user should be able to remove/replace default applications and
<cjwatson>   documentation as they wish without disturbing the metapackage, while ensuring
<cjwatson>   that essential infrastructure is implied by the metapackage
<jdub> mmm
<jdub> golden rule stuff
<cjwatson> yeah
<jdub> though still have the upgrade problem
<cjwatson> fortunately we have update-manager now which should be able to deal with most of that for us
<cjwatson> probably worth checking that it DTRT here
<mdz> jdub: which upgrade problem?
<cjwatson> mdz: installing new recommends, I'm guessing
<jdub> mdz: recommends being installed on metapackage upgrade
<cjwatson> apt-get defaults to installing recommends nowadays
<jdub> but if update-manager handles it, that's pretty sweet
<cjwatson> has done for some time
<mdz> jdub: yes, even apt does that now
<nrdb> I have a Matrox G400 graphics card, using the mga driver, Medion 19" MD1998LM monitor, and ubuntu 6.10 wont work with it.  It insists on try to drive it with a HF:23.55 and a VF:21.99 which is way out of range, I tried to change this in the xorg.conf file but no matter what I did it didn't change the frequencies, I tried the LiveCD, a upgrade from 6.06 (a copy), and a freash alternate CD install.
<mdz> since edgy
<mdz> jdub: it's selectively enabled for each section of the archive known to have sane recommends
<jdub> mdz: point being that if i remove landscape and upgrade ubuntu-desktop, i get landscape
<mdz> jdub: oh, you do?  if so, that's a bug
<tepsipakki> nrdb: file a bug on xserver-xorg-video-mga
<jdub> unless that's been fixed recently
<jdong> oh speaking of update manager, it should keep on attempting upgrade/ --configure -a /-f install
<jdong> until num_to_upgrade[pass]  == num[pass-1] 
<nrdb> tepsipakki: ok
<jdong> I've helped several people fix broken upgrades where all that was needed was 2 more dist-upgrade passes
<tepsipakki> nrdb: look for duplicates first ;)
<mdz> jdong: I'm sure mvo would be interested to see a bug report with the logs
<mdz> that's not supposed to happen
<tepsipakki> nrdb: you could also try Feisty Herd5 if it works
<mdz> it does try to complete the upgrade even if something fails now, iirc
<jdong> mdz: :( it happend on both my edgy->feisty upgrades. Subprocess returned error code 1 on first run, no error on 2nd run
<LaserJock> cjwatson: hmm, reading enabling-additional-components, does Herd5 have Universe/Multiverse enabled by default then?
<jdong> and the borkage happened on different packages too
<mdz> update-manager now uses apport so it can automagically report bugs with logs if the upgrade fails
<jdong> mdz: wow! that's nice, didn't know that
<mdz> jdong: the real errors are earlier in the logs
<jdong> mdz: I know that, but I couldn't find any
<mdz> jdong: "subprocess returned error code 1" means "something went wrong earlier, look back"
<jdong> mdz: I scrolled back a good page for any relevante errors
<jdong> mdz: but it seems like whatever command failed did so silently
<mdz> jdong: we can probably figure it out given the logs; please don't treat it as a lost cause
<jdong> mdz: if I can find time to restore an edgy backup and send it thru an upgrade, I definitely will
<cjwatson> LaserJock: it's meant to have, although the live CD's sources.list may not have been updated
<cjwatson> LaserJock: (if so, that deserves a milestoned-for-beta bug ...)
<mdz> jdong: thanks. that certainly doesn't happen when upgrading a default install or for everyone
<mdz> cjwatson: is it correct for the installed system?
<nrdb> tepsipakki: how stable is the herd5 CD ? 
<jdong> mdz: right... I can bet my systems are fairly prolific in terms of installed packages compared to others
<mdz> mvo is working on a test which tries to upgrade even with most of universe installed
<tepsipakki> nrdb: stable enough for you to try if it works or not :)
<mdz> though it's been tricky since many packages in universe don't install correctly
<jdong> cool
<nrdb> tepsipakki: I will down load and see.
<cjwatson> mdz: I do need to [have someone]  check, but I'm reasonably sure it should be; ubiquity runs apt-setup to do that job
<tepsipakki> nrdb: live-session is enough, no need to install
<nrdb> tepsipakki: ok, if it doesn't work I will see about filling a bug.  maybe I can help in getting it worked out.  tests etc.
<tepsipakki> nrdb: sure
<nrdb> I have another thing on my wish list, could the update-manager be setup so I can limit the bandwidth it uses, so it doesn't slow my internet connection down to a crawl when updating ?
<runixd> hello, why is there non-executable stack in ubuntu 7 and how do I turn it off ?
<macd> runixd, are you familiar with stackguard?
<runixd> macd, the canary value ?
<macd> well the ubuntu kernel is compiled with --enable-stackguard-randomization
<macd> so to "turn" it off, you need to build a kernel without it
<runixd> I see, my only option is recompile then
<macd> yes, but its fairly straightforward and easy
<runixd> thanks macd, I was looking all over proc
<macd> use apt to download the sources, then compile as usual with those, I say use apt b/c you get the upstream kernel source + ubuntu patches.
<runixd> macd, if you know, what is the overhead of something like stack guard ?
<macd> its well worth having it lets put it that way.
<macd> its basic operation is to randomize allocations rather than the ole tired and true "stack" em up.
<runixd> well, in my case I actually really have to not have it, but I assume it would be much faster than alternatives
<macd> its believed to be the better of its kind, I also don't see the need on a box that might never see the internet or offer any internet facing services
<macd> I think its better than something like propolice 
<runixd> well, both can still be broken, imo either should be an option
<nrdb> tepsipakki: downloading herd5 now 10 1/2 hours to go 
<macd> indeed, stackgaurd does offer all 3 whereas propolice does not do random xor (to my knowledge)
<macd> but imho, nothing can cure sloppy code ;)
<macd> Im not sure how you would defeat random xor btw, so if you know a secret you should let someone know :D
<runixd> hehehe :)
<runixd> you try again again and again
<runixd> :D
<blanky> Hey what package do I need for X11/Xlib.h
<runixd> are you going to amsterdam macd ?
<runixd> for bh europe
<macd> its a possibility, Id love to put some faces with the names
<macd> I usually do bh/toor in the US
<macd> youd know who I was if I told you ;)
<runixd> hmm :)
<runixd> so you are in us
<macd> atm, yes
<runixd> hmm, didn't expect someone who'd be interested in this in #ubuntu-devel
<LaserJock> blanky: usually packages.ubuntu.com is helpful for those questions
<macd> people play both sides of the field
<blanky> LaserJock: thanks
<runixd> :)
<macd> bh dc-2007 day2 1500-till should help you ;)
<macd> anywho you cant wear your greyhat proudly without once wearing a black one, you know they fade in the sun :)
<runixd> :D
<Chipzz> hrrrrm
<Chipzz> is there a way to install a package without installing its recommends?
<crimsun> using...?
<crimsun> (e.g., you'd use aptitude -R  )
<Chipzz> apt-get
<crimsun> -o APT::Install-Recommends=false
<crimsun> or I suppose --no-install-recommends
<blanky> hey you guys know, where in /proc/acpi it has the file with the temperature?
<Chipzz> will try in a sec, apt is busy atm :)
<jdong> blanky: some where in thermal_zone
<jdong> blanky: acpi -V will display that too
<blanky> thanks
<Chipzz> crimsun: trying to use that, doesn't appear to work
<crimsun> Chipzz: hmm, that's what the changelog mentions, at least.
<Chipzz> "apt-get install --no-install-recommends ubuntu-desktop" insists on installing openoffice
<Chipzz> but I just do not want that piece of **** installed
<crimsun> tried placing apt-get --no-install-recommends install ?
<Chipzz> same thing
<crimsun> tried the config string syntax, then?
<Chipzz> jups
<Chipzz> but not the config string before the install
<Chipzz> same thing
<Chipzz> crimsun: whatever, I can live without it :)
<Chipzz> crimsun: thx for the help anyway :)
<greff> What does Build-Depends: debhelper (>> 3.0.0) mean?
<greff> I understand >=, but what does >> mean?
<blanky> greff: http://www.debian.org/doc/maint-guide/ch-dreq.en.html
<bddebian> mjg59: ping (laptop-mode) ?
<jdong_> bddebian, try contentless ping, it defeats their defense mechanism :D
<jdong_> j/k
<bddebian> I think I just need Hobbsee's pointy stick :)
<jdong> try this ping phrase:
<mjg59> bddebian: It's 2AM - I'm going to bed now
<jdong> bddebian, I'm going to upload beryl into universe if it's ok kthxbye
<jdong> mjg59, nighty night (btw that's ideal calc homework hour!)
<mjg59> Dude, I really do not have homework nowadays
* mjg59 sleeps
<bddebian> Gnight mjg59
<jdong_> bhale_: ping (Beagle tends to create gigantic logfiles... just cleared 600MB of logs after first using beagle two days ago)
<giangy> 'morning
<clust> Hi, I work on a Ubuntu based USB distro for servers with web interface for network settings. What is your suggestion: Use the web interface to set the ubuntu network config files or build independent scripts for system configuration and make the web interface distribution independent?
<poningru> waah?
<poningru> have you looked into puppet?
<mdke> poningru: saw your message in -doc overnight - please check for bugs and file them if none are there!
<poningru> mdke: yes sir
<mdke> :)
<poningru> :)
<_ion> I guess pitti won't be around until next week. :-( pe194808 -!- pitti [n=pitti@ubuntu/member/pitti]  has quit ["have a nice weekend"] 
<_ion> I have a patch for restricted-manager.
<afflux> is there any special reason why adept now offers the upgrade to feisty?
<afflux> (as in bug 91065)
<Ubugtu> Malone bug 91065 in adept "Adept wants to upgrade to feisty 7.04" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91065
<clust> poningru: I am not sure, that puppet is exactly what I need,  install 8MB on the USB key to set the network preferences is not acceptable for me. I m trying to mimize the distros size to fit in 128MB.
<clust> But it is a nice project ;)
<_ion> Hi pitti
<pitti> hey all
<pitti> morning _ion 
<_ion> pitti: I changed restricted-manager to look at hardware identification patterns modinfo already provides and compare them to what sysfs says about connected hardware.
<_ion> No need to execute lspci anymore, or list PCI IDs inside code.
<pitti> _ion: that sounds awesome!
<Fujitsu> Somebody might urgently want to take a look at why Adept is wanting to upgrade to 7.04...
<pitti> Riddell: ^ that's due to your adept edgy-proposed upload, I figure
<Fujitsu> Ahah.
<Fujitsu> Might be advisable to fix that (although people shouldn't really be installing everything from edgy-proposed without testing).
<pitti> still, that's wrong
<Fujitsu> Isn't it meant to check a file on archive.ubuntu.com?
<crimsun> pitti: apologies for pinging when you're off the clock, but I was wondering if you would take a look sometime next week at the vlc FTBFSes (on all arches, e.g., https://beta.launchpad.net/+builds/+build/309060 ) for pkgmaintainermangler
<pitti> crimsun: that looks familiar; which maintainer address did you use?
<crimsun> Fujitsu and I were discussing it in -motu, and it's likely due to the fact that vlc uses Maintainer: MOTU Media Team <motumedia@tauware.de>
<Fujitsu> s/likely/almost definite/
<pitti> crimsun: yesterday I taught pkgbinarymangler not to choke on @kubuntu.org addresses
<pitti> hmm
<Fujitsu> pitti: How about not choking if Original-Maintainer exists?
<pitti> it requires an ubuntuish address ATM
<Fujitsu> pitti: That's not an option in this case.
<pitti> Fujitsu: I have to look at this; could one of you please file a bug against pkgbinarymangler?
<crimsun> I can do that, thanks
<Fujitsu> Removing line 64 would solve the issue.
<Fujitsu> Oops.
<Fujitsu> No.
<Fujitsu> Changing it to return 0.
<_ion> Btw, perhaps http://people.ubuntu.com/~pitti/scripts/bzrdc and http://people.ubuntu.com/~scott/software/bzr-commit should be merged to a single script. :-)
<pitti> _ion: yestrerday I discovered debcommit in devscripts
<pitti> _ion: that should be the eventual thing to use :)
<_ion> Ah, debcommit looks nice
<crimsun> pitti: wishlisted #91086; if it's suitable for feisty to simply just use @ubuntu.com / @kubuntu.org Maintainer email addresses, I'm happy to do that
<pitti> crimsun: oh, I'm all for making pkgmaintainermangler more liberal
<pitti> but it's certainly a valid workaround to use an ubuntu address for now
<crimsun> in the interest of getting that CVE fixed, I'm going to work around it presently
<Fujitsu> crimsun: It might be nice to get an official list for motumedia.
<discord> I'm having trouble setting an environment variable using /etc/environment does anybody have any suggestions on how i can perminantly set a java classpath environment variable in ubuntu?
<pitti> _ion: btw, could you please register your r-m branch in LP? makes it much easier to find and follow
<ajmitch> hi pitti 
<pitti> hey ajmitch 
<_ion> pitti: Actually it's registered, but after you merged my first change, i changed its status to 'Merged' and forgot to change it back to 'Development' when i did new commits.
<pitti> ah
<pitti> thanks
<_ion> Now it's visible again at https://code.launchpad.net/restricted-manager
<pitti> argh, yay for descriptive names on https://code.beta.launchpad.net/bughelper
<_ion> pitti: I added identification patterns for ipw3945 and ath_hal to my branch.
<pitti> _ion: nothing can stop you now :)
<nrd1> hi I have just downloaded and run the fiesty version 5 livecd, I am using a matrox video card, the livecd decided to use the 'vesa' driver not the 'mga' driver is it should, this limit the max resolution to 800x600 :(
<nrd1> at least fiesty works ubuntu 6.10 doesn't at all.
<pitti> *nnng* feisty, not fiesty! *nng* :)
<mc44> fisty!
* nrd1 hmmm ok
<pitti> nrd1: could you please file a bug against 'xorg' with some hardware data? (output of 'lspci' and 'dmidecode'
<nrd1> pitti: ok
<Fujitsu> pitti: How do I go about getting a universe security update uploaded?
<pitti> Fujitsu: open a security bug for it and attach a debdiff
<pitti> the security flag will make it appear on keescook's and my radar
<Fujitsu> Ah, both of those are already done.
<Fujitsu> Thanks.
<AlinuxOS> pitti, hello ! ;)
<pitti> hi AlinuxOS 
<AlinuxOS> pitti, is there some feisty testing packs ? Mozilla locales-packs ?
<AlinuxOS> some your experimental repositories ? :)
<pitti> not yet for 2.0.0.2
<AlinuxOS> ;)
<AlinuxOS> hehe ok...just asked ! :P
<nrd1> pitti: I have sent in a bug report.
<_ion> pitti: I scraped the lists of specific cards supported by nvidia and nvidia_legacy from the nvidia website and overrode the patterns reported by the modules (basically "all graphics adapters by nVidia") with them. Now nvidia_legacy isn't listed anymore because my card is only supported by the nvidia driver. :-) I didn't commit the change yet, but will push soon.
<pitti> _ion: cool! I was looking for such a list, but didn't find one, and instead I found out that it in fact changes from release to release
<pitti> _ion: thus, how can you make sure that your overriding of the modules' lists will be correct for future releases?
<_ion> pitti: Yeah, the scrape script is included. It needs to be run whenever the driver version(s) in l-r-m change.
<pitti> _ion: can this be integrated to happen dynamically?
<pitti> or does it need manual intervention?
* pitti gets apport-retrace to automatically attach symbolic stack traces back to bug reports \o/
<_ion> pitti: I wasn't able to pull the listing from the drivers themselves. There's some kind of a list in the README, but it says "For the most complete and accurate listing of supported GPUs, please see the Supported Products List, available from the NVIDIA Linux x86 Graphics Driver download page" above the list. What i've implemented so far needs manual intervention, unfortunately.
<pitti> I see
<pitti> _ion: that should be fine, though
<pitti> _ion: ideally the kernel modules themselves would know which product IDs they support :(
<_ion> Yeah.
<mjg59> I thought the nvidia ones did?
<mjg59> Or are they overly generous?
<_ion> They basically match all graphics adapters by nVidia.
<_ion> pitti: I pushed the change.
<pitti> thank you
<_ion> pitti: A more accurate list should be created for the ATI driver, too.
<mjg59> http://librarian.launchpad.net/6724669/buildlog_ubuntu-feisty-amd64.acpid_1.0.4-5ubuntu6_FAILEDTOBUILD.txt.gz make sense to anyone?
<kylem> ew.
<imbrandon> anyone know what the sru policy is on "just needs a rebuild" ?
<nixternal> haha
<Riddell> Fujitsu: it's deliberate to upgrade o feisty with adept
<geser> mjg59: you have a non-ubuntu email address as Maintainer
<mjg59> Yes. Yes, I do.
<mjg59> (Since I have a non-ubuntu email address)
<geser> pkgbinarymangler tries to store it as Original-Maintainer but there is already a O-M field and errors out
<Seveas> someone should slap pitti to add mjg59s address to the whitelist (or better: do some launchpad magic)
<bddebian> mjg59: Oh, since you are here, do you have any plans for laptop-mode?
<jdong_> ok, how is this gnome-main-menu slab thing supposed to work?
<jdong_> I think it's misnamed.....
<jdong_> "slap" - slaps your gnome-panel with a SIGSEGV
<Seveas> jdong_, :D
<jdong_> I'm almost sure it's PEBKAC but I'd love to get this thing running :D
<bddebian> do be do be doo
<Seveas> bddobedobedoobian
<bddebian> heh
<Treenaks> Seveas: doobian? that explains a lot ;)
<Seveas> no comment
<bddebian> Hmm
<jdong_> Users should realize that less(1) provides more(1) emulation and extensive enhancements.
<jdong_> I'm using less, but I'm not getting any "extensive enhancements"
<jdong_> I'm beginning to think it's false advertising... my surgeon says only cartilage grafting works for extensive enhancements :(
* pitti waves to Keybuk 
<Keybuk> hey pitti
<aigarius> jdong: in 'more' terms, scrolling back one line is a very extensive enhancement
<okaratas> Seveas, hello
<Seveas> hi okaratas 
<_ion> Btw, "okaratas" in Finnish translates to a "thorn cogwheel". :-)
<okaratas> _ion, i dont understand you ?
<_ion> Your nick just happens to be a valid Finnish compound word, where oka means a thorn and ratas means a cogwheel.
<jdong> And this concludes this week's episode of _ion points out useless random things and offends a random person!
<_ion> Offends?
<jdong> Stay tuned for jdong finds sexual innuendos in random manpages!
<jdong> _ion: "confuses"?
<bhale> jdong: there is a patch to be applied around beta time that lessens beagles logging
<bhale> jdong: that said, my Log dir is 14mb after months and months of use
<jdong> bhale: ah, ok, that makes me happier then :)
<okaratas> _ion, hm okey
<jdong> bhale: well I rm -rf'ed 2.0GB wroth of kmail on day 2 of beagle
<jdong> bhale: so I think I might've upset it into logging more than usual :D
<bhale> hm :)
<bhale> there are ocassional reports of Really Big Logs
* jdong snickers immaturely
<jdong> are they *natural* logs?
<okaratas> _ion, what is fin cogwheel ?
<jdong> _ion: are you Finnish, btw?
<_ion> okaratas: http://images.google.fi/images?q=cogwheel
<_ion> jdong: Yes.
<jdong> _ion: ok, cool :)
<okaratas> _ion, my name is Ozgur Karatas, my nickname "okaratas" :)
<okaratas> http://blog.ozgurkaratas.com
<_ion> okaratas: Yeah, i realize that. :-) Is that a Turkish name?
<sabdfl> evening all
<okaratas> yes _ion i am from Turkey..
<sabdfl> do we really not want openoffice in feisty?
<okaratas> sabdfl, hello..
<jdong> sabdfl: maybe if I can read the fonts without squinting :)
<Keybuk> sabdfl: ?
<sabdfl> Keybuk: just updated, and aptitude wants to remove a ton of useful stuff
<sabdfl> ubuntu-desktop appears to have lost some dependencies
<Amaranth> they got changed to Recommends
<jdong> ha, subliminal anti-OOo marketing :)
<sabdfl> out of curiousity, why?
<Keybuk> sabdfl: you don't use synaptic? :p
<sabdfl> nup, aptitude, oldskool etc
<Keybuk> most of ubuntu-desktop is moving to recommends to allow people to uninstall bits without suddenly losing their entire system
<sabdfl> *some* people I know use dselect
<sabdfl> ok
<Keybuk> F10 - Options - Dependency handling - Install Recommended packages automatically
<Keybuk> make sure that's selected
<jdong> why isn't aptitude an emacs mode yet?
<jdong> it seems to fit right in.
<okaratas> which packages do i need to install for .exe files to be run? i have a .exe file for windows which i can't run..
<Fujitsu> Riddell: It's by design that edgy-proposed has now been equated with Feisty? Interesting, I would have thought that somewhat inappropriate.
<pirast> okaratas, wine, please ask in #ubuntu next time
<okaratas> pirast, thank you
<Qwell> How do I find out the maintainer of a package?
<crimsun> apt-cache show package
<Fujitsu> Qwell: Which package? Most packages have no maintainer as such any more.
<Qwell> I don't use ubuntu..
<Qwell> the package is asterisk
<crimsun> MOTU maintains asterisk
<Qwell> Somebody very urgently needs to upgrade to 1.2.16
<Fujitsu> Qwell: Why do you want to know? It's more of a team effort, as crimsun says.
<Qwell> or at least backport some stuff
<crimsun> we know about it already, Qwell 
<Fujitsu> Qwell: That's being done.
<Qwell> zaptel too :D
<Qwell> ...and libpri, for good measure
<crimsun> we know about zaptel, too.
<crimsun> and libpri
<Qwell> great
<Fujitsu> Qwell: bug #89863 is the Asterisk one, for reference.
<Qwell> any ETA?
<Ubugtu> Malone bug 89863 in asterisk "Asterisk 1.2.16 fixes a recently discovered security vulnerability" [Undecided,Fix released]  https://launchpad.net/bugs/89863
<crimsun> note that they're fix released, which means fixes are already available.
<Fujitsu> Dapper and Edgy were fixed 4 days ago, Feisty was fixed yesterday.
<Qwell> is Feisty still gonna use 1.2?
<crimsun> yes
<Qwell> okay
#ubuntu-devel 2007-03-11
<crimsun> maswan: since you use systemtap, does feisty need an updated package?
<jdong> cjwatson: whee, more -archive-latency fun, bug 91180.... I'm gonna see if I can figure out how to undo that one :(
<Ubugtu> Malone bug 91180 in dapper-backports "dvd+rw-tools depends on genisoimage, but it does not exist." [Medium,Confirmed]  https://launchpad.net/bugs/91180
<jdong> cjwatson: attached debdiff to bug report, please look when you get a chance, thanks
<bluefoxicy> Is it alright if I write a spec that culminates findings in live fire research and gives a direction to take to better deploy critical tools?
<bluefoxicy> It'll be fairly wordy for a spec but very brief for a white paper; I don't feel like doing deeper research to write a paper.
<carson> Can someone tell me why G++ isn't seeing my #include here?
<carson> http://pastebot.nd.edu/2086
<bhale> what do you mean, its there
<bhale> there is no directory named perl in the listing you gave
<carson> the file is in the path.
<carson> -I/usr/lib/perl/5.8/CORE
<carson> and then within that directory is my EXTERN.H
<carson> sorry, i don't understand.
<carson> aaaaaaaaaah! i had a capital H
<carson> not a lowercase one.
<crimsun> I'm surprised #ubuntu didn't assist
<carson> yeah, there went two hours of my life.
<imbrandon> moins all
<jdong> imbrandon: moins? it's 3:30 AM :)
<jdong> imbrandon: and I stayed up solely to watch DST switch
<LaserJock> lol
<Fujitsu> Oh yes, I forgot it about it changing really early over there.
* Fujitsu thanks US Congress.
<Fujitsu> *forgot about it
<somian> Where does "Monospace.ttf" in Ubuntu "Fiesty Fawn" (or maybe installed later via APT/Synaptic), come from?
<tsmithe> dpkg -S it
<somian> I shall try that.
<somian> Ahh. These new (to me, wrt any prior Debian experience) "George Williams" fonts. I am concerned that specifying "Monospace" in CSS will merely pull up the default rather than the specific font I intended. That's what sparked my curiosity.
<Hobbsee> somian:  or see packages.ubuntu.com - there's a search for which package a file belongs to
<somian> Thanks for the help.
<TheMuso> Or apt-file.
<tsmithe> hehe
<tsmithe> so many means for one task
<clust> Hi, how can I dissable autologin in livecd Casper? 
<clust> Where can I find the documentation of casper?
<imbrandon> any arcive admins arround? have a quick question, can i request a rebuild of a universe source package for edgy ( no changes ) or does it have to go though the sru process ?
<tepsipakki> jdong: ping?
<tepsipakki> wonded why aptitude decided to remove ubuntu-desktop because of broken dvd+rw-tools dependancy
<tepsipakki> and now we have ~200 machines without X :)
<tepsipakki> no, make that 236
<tepsipakki> s/wonded/wonder/
<tepsipakki> is there anyone who could fix bug 91092 ASAP?
<Ubugtu> Malone bug 91092 in dapper-backports "dvd+rw-tools doesn't update in dapper  (dup-of: 91180)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91092
<Ubugtu> Malone bug 91180 in dapper-backports "dvd+rw-tools depends on genisoimage, but it does not exist." [Medium,Confirmed]  https://launchpad.net/bugs/91180
<tepsipakki> oh, right.. 91180 is the correct one
<jdong> tepsipakki: any core-dev can upload that debdiff to edgy-backports; then -archive just needs to approve it
<tepsipakki> dapper-backports, but yes
<tepsipakki> I guess it's not going to happen today, so I need to disable -backports and reinstall the packages..
<jdong> tepsipakki: I pinged cjwatson about it last night... I'm not gonna be around for a lot of the day but feel free to bug the crap outta archive about it :D
<jdong> tepsipakki: you can always just debuild that debdiff
<tepsipakki> easier to disable -backports for now..
<jdong> yeah
<jdong> cjwatson / tfheen : ping; please help upload debdiff bug 91180 to dapper-backports
<Ubugtu> Malone bug 91180 in dapper-backports "dvd+rw-tools depends on genisoimage, but it does not exist." [Medium,Confirmed]  https://launchpad.net/bugs/91180
<tepsipakki> bah, it would be best to just reinstall the workstations.. but that's difficult (=impossible) to do remotely
<jdong> a broken dvd+rw-tools dep can't lead to that much damage, can it?
<jdong> at most an uninstallable package or two
<tepsipakki> pkgsync (=aptitude) removed {k,}ubuntu-desktop
<tepsipakki> 488 packages ;)
<tfheen> which can cause ubuntu-desktop to be uninstallable and aptitude to go tits-up
<jdong> you're kidding.....
<tepsipakki> yes, pkgsync should have some sort of a panic button
<tepsipakki> aptitude, that is
<tfheen> tepsipakki: it's really an aptitude bug.  It should hold instead of uninstalling half the world, especially when the uninstalled package is a metapackage
<tepsipakki> tfheen: indeed..
<tepsipakki> test reinstall went fine, now the same on ~230 machines.. keep the network (and the local mirror) hot :)
<tfheen> tepsipakki: IME, pkgsync recovers quite well from such temporary problems as what you're seeing.
<tfheen> jdong: uploaded and accepted.
<jdong> tfheen: thanks :)
<tepsipakki> tfheen: maybe a newer version does
<tfheen> tepsipakki: your experience tells otherwise?
<tepsipakki> actually, it works fine after I disabled backports, so yes it does fix things
<tepsipakki> thanks for the upload!
<geser> tfheen: could you please give-back libkexiv2 on all archs. thanks
<tepsipakki> tfheen: the newer pkgsync (edgy->) is better that it operates in fewer iterations
<tfheen> geser: done
<Ng> tfheen: is it way too late for stuff like #76435?
<geser> Lure: libkexiv2 was given-back
<Lure> geser, tfheen: thanks
* ..[topic/#ubuntu-devel:foxxxy1] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting invlved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 5 released
<tfheen> Ng: hard to say without a diff, but I suspect it's fine to get it in.
<Ng> tfheen: there's a diff at http://ftp.gnome.org/pub/GNOME/sources/librsvg/2.16/ - it's not exactly what I'd call small though
<tfheen> Ng: I suspect the crasher is easy enough to fix, though
<tfheen> apart from that, the diff is small enough to review easily; most of it is auto* output.
<Ng> tfheen: coolio, thanks
<Ng> not that I wish to encourage e17 use ;)
<kylem> Ng, hah.
<tfheen> heh
<Ng> hey kylem 
<kylem> morning.
<kylem> either i just passed out, or the machine i'm ircing from just ran ntp. ;o)
<Ng> hehe
* kylem wonders where the last ten minutes wen.t
<imbrandon> tfheen, have a quick question, can i request a rebuild of a universe source package for edgy ( no changes ) or does it have to go though the sru process ?
<imbrandon> tfheen, atm its not installable , but a rebuild fixes it ( it == mod_mono )
<tfheen> imbrandon: it's an SRU, but those should be more lightweight now.
<imbrandon> k
<geser> pratically this would introduce a new version of mod-mono as the last FTBFS
<tepsipakki> tfheen: dvd+rw-tools isn't built yet, shouldn't it have started by now?
<tfheen> tepsipakki: sources should have been published around now
<tepsipakki> not on a.u.c
<tepsipakki> yet
<jdong> tepsipakki: join in, I do this all the time, watch for debs to hit the archives :)
<jdong> tepsipakki: it's like watching washers and dryers
<tepsipakki> heh
<tepsipakki> well, I'd like to get that on our mirror and fix the machines with backports enabled. thank god it's Sunday ;)
<tepsipakki> not to sound too impatient..
<tfheen> hmm, it ought to have been on a.u.c now
<jdong> No Builds Recorded on LP
<jdong> https://launchpad.net/ubuntu/+source/dvd+rw-tools/7.0-6~dapper2
<tfheen> dvd+rw-tools | 7.0-6~dapper2 | dapper-backports | source
<tfheen> it should be there in a few minutes, I believe
<tfheen> there, published.
<tfheen> binaries should be around in an hour or so
* Starting logfile irclogs/ubuntu-devel.log
<geser> visik7: there's only the Launchpad web interface to report bugs
<visik7> :(
<shawarma> geser: Not true.
<shawarma> visik7: https://help.launchpad.net/UsingMaloneEmail#head-5ea87d70dba160e5903ca01b9eedd8d8476aa2a1
<dsas> or there's the malone email interface
<geser> shawarma: ah I forgot about that, but you have to write the right commands by hand or is there a frontend for it?
<shawarma> geser: Not sure.
<shawarma> geser: reportbug should really be fixed to use it.
<geser> that would require that the reporter has his gpg key made known to LP
<shawarma> geser: Yes, I know. That's probably why noone has done it yet. :-)
<hikenboot> greetings all! I am wondering if in the next version of ubuntu they have made remastering ubuntu easier and separated components out of the cd like openoffice out of ubuntu-desktop?
<tfheen> hikenboot: no, there has been no changes along those lines.
<hikenboot> I was just told that it is now a recommened package instead of a requirement
<hikenboot> tfheen, is this wrong information?
<tfheen> hikenboot: no, that is correct.
<hikenboot> so i can safely remove open office and have no upgrade drawbacks?
<Maor> asd
<hikenboot> tfheen, can I safely remove open office off the cd and still have no problems with things such as upgrading?
<Riddell> Fujitsu: of course, we need people to test it
<tfheen> hikenboot: I don't know, just test it?
<keyes> hello
<keyes> I would code something for Ubuntu with Google Summer Of Code
<keyes> i'm thinking about a "security center" for Ubuntu
<keyes> with some features like crypt /home just by checking a box, someting like "clear my tracks" in firefox (clear temporaries files, logs, Trash, ...), an antivirus system (for samba / mails using clam) ...
<keyes> is it interesting (for end users), would someone be my mentor ^^
<tfheen> not trying to shoot down your idea, but it's important to not be too ambitious for the initial work.
<keyes> yes i know
<keyes> my main objective is easy partition cryting
<tfheen> I've toyed with the idea of that; similar to what I've heard Apple's FileVault (iirc) described as.
<keyes> i've some ubuntu experience (member of ubuntu-fr team and "creator" of easy ubuntu script)
<keyes> hum
<keyes> my tool will be mainly designed for laptop users
<keyes> like the pass on an USB key
<keyes> put the key in the computer and u can acces u'r patition
<tfheen> have you watched Jacob Applebaum's presentation of his disassembly of the filevault software?
<tfheen> (from the CCC this winter)
<keyes> no i'll look that
<keyes> (and sorry for my bad english)
<keyes> (i'm reading the doc)
<tfheen> I'm not saying that is the approach one wants to take, but it's certainly worth at least looking at what other people have done before.
<keyes> i agreee
<_ion> Btw, it would be nice if the Empty Trash function in Gnome/Xfce/KDE shred(1)ded the files.
<Treenaks> _ion: useless without encrypted swap..
<keyes> Treenaks, yes i want crypt swap
<Treenaks> (random-key-generated-on-boot encrypted swap, even)
<tfheen> _ion: it doesn't make any difference with journaled file systems.
<tfheen> Treenaks: that plays hell with hibernate.
<Treenaks> tfheen: yeah, I can imagine :)
<keyes> yes hibernatise seems to be a problem
<_ion> bzr doesn't say how many revisions it pulled anymore. :-(
<keyes> i'm reading about fuse dm-crypt
<neighborlee> curious..why was new gnome menu removed,,I googled and found it was in HURD2, so im just curious what happened ;))
<tfheen> herd 2, I hope. :-P
<_ion> All the cool guys are already running their Ubuntu on Hurd. ;-)
<wick2o> hello
<hunger> wick2o: ho.
<wick2o> hows it going hunger?
<hunger> fine.
<wick2o> I've made a "remaster", well pretting much just a preseeded custom ubuntu install cd....but i seem to be having problems with the mkisofs...it keeps assuming UTF-8 and "Using LINUX_HEADERS_2_6_15_26_SER000.;1 for ;opt/cd-image/pool/main/l/linux-source-2.6.15/linux-headers-2.6.15-26-server-bigiron_2.5.15-26.46_i386.deb
<wick2o> I'm tring to find the correct ubuntu channel to perhaps get some help...  even the standard install on the cd no longer works
<wick2o> I've been folling the  installCDCustomization wiki page
<tfheen> what is the error you get?
<wick2o>  one moment, my qemu just crashed....pretty much it doesnt do the install, it just brings me right into the debconf after i pick my keyboard and location
<ajmitch> morning
<wick2o> well not right after, it does the detecting hardware to fin dthe cdrom
<wick2o> choose language, choose location,choose keyboard, detecting hardware to find the cd-rom drives, scanning cd-rom, loading additional items, then POW
<wick2o> i get the Change debconf priority
<wick2o> packages that use debconf for configuration prioritize the questions they might ask you...
<tfheen> look in the logs?
<neighborlee> why was new gnome menu removed,,I googled and found it was in HURD2 so im curious whats the status is ? ;)
<wick2o> tfheen im doing a man qemu...ca use i dont see where it outputs its logging
<tfheen> wick2o: tty3 and 4
<wick2o> tfheen qemu doesnt seem to want to let me switch to those, im on tty3 and its blank
<tfheen> also, /var/log/syslog
<wick2o> o wait, nm
<wick2o> it does resolver (di-utils-reboot): mark and then menu item 'cdebconf-priority' selected
<wick2o> nothing with a huge "error" or "this didnt work" message
<wick2o> just a bunch of DEBUG: resolver (option): mark or mark,dependecy from file-preseed
<wick2o> i guess ill just have to start over, add a preseed and build iso....then add my extras and rebuild the iso to try and find the obvious mistake
<wick2o> ill bbiaf, moving laptop
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 5 released
<cjwatson> wick2o: it's just tty4 these days; tty3 is another spare shell
<siretart> huhu pygi :)
<pygi> siretart, what? :P
<ajmitch> hi siretart 
<siretart> huhu ajmitch 
#ubuntu-devel 2008-03-03
<exneo__> sup
 * Hobbsee waves
<jdong> Hobbsee: hey you want to sponsor in Transmission before the freeze?
 * jdong adds a pretty please or two to that
<Hobbsee> not from here, no :)
<Hobbsee> remind me in ~10 hours
<TheMuso> jdong: What is being changed?
<jdong> TheMuso: new upstream release, FFe granted
<jdong> bug INSERTNUMBERHERE (lemme actually find it)
<jdong> that's bug 196138, dgettable dsc provided
<ubotu> Launchpad bug 196138 in transmission "Please update to 1.06" [Undecided,Confirmed] https://launchpad.net/bugs/196138
<TheMuso> jdong: Its building now, will upload after lunch.
<jdong> TheMuso: sweet, thanks :)
<TheMuso> jdong: uploaded.
<jdong> TheMuso: whee :) thanks
<RAOF> jdong: You're trying to make me able to use mythtv:// urls in totem, right?
<jdong> RAOF: -EREALLYCONFUSED
 * RAOF has experienced ECONFLATE error, and will now shut up.
<RAOF> It's actually superm1 I'm thinking of.
 * superm1 says hi
<RAOF> superm1: _You_ are the one trying to make mythtv:// urls work in totem?
<jdong> hehe
<superm1> uh oh
<superm1> whatd i do
<RAOF> Nothing?  I'd just quite like it to work, and it doesn't.
<superm1> well that's not exactly how the plugin works..
<superm1> there is a second piece to it still to make it "user friendly"
<superm1> via upnp
<superm1> but for now do this
<superm1> open gconf-editor
<superm1> and find the gmyth key
<superm1> and set your DB
<superm1> and user name and pass and stuff
<superm1> then activate the plugin in totem, and it should be a drop down option on the side bar
<RAOF> Ah.  Right.
<superm1> that reminds me i should send another email to gmyth-devel to straighten the licensing on gmyth-upnp
<superm1> i sent one almost a week ago now
<RAOF> I suggest infiltrating upstream and dumping license headers into VCS.
<superm1> i should.
<superm1> the weird thing is they were responsive within like 30 minutes before
<superm1> so i'm not sure if they just fell off the side of the earth or what
<RAOF> superm1: I don't suppose gmyth is going to stream DVB over the network anytime soon?
<superm1> well it can, the only thing missing is the interface
<superm1> it can do livetv urls
<RAOF> Right.  So it should be possible to do livetv://2 or something?
<superm1> i dont know the exact syntax for it
<superm1> but it is quite possible to do
<Kano> hi, why not adding bash-completion and enabling this by default? the new bash package does not have /etc/bash_completition included anymore, it is external
<Kano> hi laga , did you update aufs for lum?
<warp10> Good morning
<pitti> Good morning
<Kano> hi pitti, could you add bash-completion by default?
<pitti> Kano: technically yes, but this should be discussed on u-devel@ first; IIRC there were reasons for dropping it
<Kano> well it was "dropped" because bash package was updated and now it is split. before it was just in bash itself
<torkel> Kano: it wasn't turned on by default before, was it?
<Kano> well it should be turned on, as it is very nice to have
<tjaalton> hum, cron.daily/apt tries to run gconftool, but apt does not depend on it, so maybe it should check for it's existence before running it?
<Amaranth> tjaalton: wow that was fast
<Amaranth> 3 minutes after i marked that dupe you corrected it :P
<tjaalton> Amaranth: hehe :)
<mdke> pitti: just read your comment on bug 123963 - I don't know how to debdiff could have been broken
<ubotu> Launchpad bug 123963 in ubuntu-docs "Ubuntu 7.04 and 7.10 documentation updates have not been done" [High,In progress] https://launchpad.net/bugs/123963
<pitti> mdke: doesn't matter much anyway
<pitti> mdke: just tell me how to build a source package, or build it and put it somewhere, and I'll sponsor it
<mdke> pitti: anyway you can grab the branch at https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/gutsy
<mdke> from that you can just build it with debuild
<pitti> ah, nice
<mdke> nothing else to do
<pitti> carlos: do you know how bug 196106 could have happened?
<ubotu> Launchpad bug 196106 in language-pack-kde-de "context menu entry "Paste File" [and other dialogs] not translated into German (anymore)" [Undecided,Confirmed] https://launchpad.net/bugs/196106
<mdke> i'm slightly worried the debdiff broke though
<carlos> pitti: let me check....
<RAOF> tjaalton: How's nouveau-in-experimental going?  (Man nouveau is so much faster than the blob at scrolling firefox)
<RAOF> tjaalton: (That was you, right? I've not had a good time of names recently)
<carlos> pitti: without checking anything, I can only 'blame' a bad translator
<pitti> carlos: like actively deleting a translation?
<carlos> kind of, yes. Let me do some checking to confirm/reject that idea
<pitti> ok, thanks
<pitti> since I have no real idea about it,the POTs certainly didn't change?
<carlos> pitti: we got an updated at the end of January
<carlos> pitti: although I don't know whether it included a change or not
 * carlos is still looking into this problem
<tjaalton> RAOF: sorry, I bumped into issues that prevented that
<tjaalton> RAOF: but experimental will soon get new mesa&drm, so it should be easier then
<carlos> pitti: I found the problem, but I need to talk with danilo and jtv before I can provide you with a solution...
<pitti> carlos: ah, great; shall I create a rosetta task for the bug for tracking?
<carlos> pitti: it's related with some data migration when we added native kde plural forms support
<carlos> pitti: yes, please
<carlos> pitti: it affects all KDE language packs, though, not just German ones
<carlos> but only messages with plural forms that are not manually fixed/retranslated
<pitti> carlos: done
<carlos> thanks
<james_w> doko: hi. We have a new result of bzr still not being installable, even after yesterday's rebuild. It's a different error though. https://bugs.launchpad.net/bzr/+bug/197841
<ubotu> Launchpad bug 197841 in bzr "ppa bzr package 1.2~rc1-1build2 for Ubuntu Hardy fails to install" [Undecided,New]
<james_w> doko: would you take a look? I'll investigate tonight if not. Thanks.
<doko> james_w: looking ...
<james_w> doko: thanks.
<doko> james_w: please could you email me the /var/cache/apt/archives/bzr_1.2-1~bazaar1~hardy4_i386.deb package, or tell me where I can find it?
<james_w> doko: ah, it is the ppa, sorry, I got confused.
<james_w> doko: I'll fix it tonight then. Sorry to trouble you.
<pitti> mvo: good morning
<mvo> good morning pitti
<pitti> mvo: seems the new compiz session management doesn't fix all things for us :(
<pitti> mvo: does it actually work for you?
<pitti> mvo: it seems to remember the correct workspace now, but placement and size of gnome terminals (and maybe other apps) is still not working
<mvo> pitti: is it not working at all for you? or just not as good as metacity?
<pitti> in fact that got worse
<pitti> mvo: let's say it's by far not as good as gutsy's metacity
 * mvo nods
<pitti> hardy's metacity's session management regressed as well
<pitti> seems it's converging in the wrong direction :/
<mvo> yeah :/
<mvo> I will check and talk to upstream about it - does it get all windows wrong or specific ones?
<pitti> mvo: the gnome-terminal with mutt inside was quite alright
<pitti> mvo: the 'plain' (shell) gnome-terminals were totally wrong
<pitti> seb128: bonjour
<seb128> guten tag pitti
<pitti> seb128: hm, seems that my deskbar applet forgot about all plugins but the internet searches (e. g. devhelp or dictionary); do you have the same?
<seb128> pitti: seems to be the case yes
<cjwatson> laga: right now, there's no good way to exclude items from seeds like that
<cjwatson> laga: "!" is the blacklist syntax, which is much stronger (it means "don't include this package in this seed, and prevent it being included in any of the seeds that inherit from me either"), and may not do a good job of dependencies
<cjwatson> james_w: for the record I reassigned that CD menu bug you talked about to gfxboot-theme-ubuntu, which implements our CD boot menu
<cjwatson> pecisk: no, they aren't incorporated automatically, but semi-automatically (i.e. I have some scripts to update them that I run occasionally); I'm pulling in your Latvian translation now
<pecisk> oh, nice to hear that
<pecisk> when I can expect it in daily live cd?
<cjwatson> pecisk: tomorrow
<pecisk> nice, thanks :)
<seb128> cjwatson, evand: is there any bug about translations not being used on the desktop daily images?
<cjwatson> pecisk: though I do need to change a few strings (for bug 66881), so a few parts will still end up untranslated, I'm afraid
<ubotu> Launchpad bug 66881 in debian-installer "Help text is misleading or inaccurate for boot methods" [Medium,Confirmed] https://launchpad.net/bugs/66881
<cjwatson> seb128: in what context?
<seb128> cjwatson: when selecting french and using the desktop testing option I get an english desktop, french language packs are installed but the environment is set to C and there is no /etc/default/locale
<cjwatson> seb128: so you mean in the live session, pre-install?
<seb128> right, not the ubiquity option but the desktop one
<seb128> cjwatson: sorry if I'm not clear, I use virt-manager
<seb128> boot a daily iso
<seb128> pick french
<seb128> "Try Ubuntu without any change to your computer"
<seb128> the desktop I get is an english one, environment is set to C and there is no /etc/default/locale configuration
<cjwatson> seb128: I can't find a bug about that, though of course it could be misfiled; it should go on casper
<soren> doko: Java is failing in firefox for me on amd64. While reading through some of the bug comments about this on Launchpad, someone suggested that rebuilding it yourself fixed it. I was skeptical, but tried it, and it actually does fix it. Maybe there's a build dependency missing that is commonly installed on people's systems?
<seb128> cjwatson: ok, will open one on casper then, thanks
<soren> doko: Unfortunately I wasn't clever enough to keep build logs around :(
<fabbione> soren: you too?
<cjwatson> seb128: I suspect it's because there's no /etc/default/locale in the live squashfs so it decides to write it to /etc/environment instead
<soren> fabbione: What? Not being clever? :)
<cjwatson> seb128: or do you mean it's not set in /etc/environment either?
<cjwatson> seb128: please attach /var/log/casper.log to the bug
<fabbione> soren: java crashing.. dude.. :P
<seb128> cjwatson: there is an environment where LANG is set, but you made me modify gdm to use /etc/default/locale ;-)
<soren> fabbione: :p  Yeah, it segfaults consistently.
<fabbione> soren: indeed
<soren> fabbione: Rebuilt it locally (in my regular system, not in an sbuild of course), and it works.
<soren> fabbione: I'll rebuild it again, saving the build logs. Maybe I'll be able to spot the difference between the build logs from LP and my local one.
<cjwatson> seb128: indeed :-)
<pecisk> cjwatson: about those installer help strings - but it will be possible to translate them till release?
<fabbione> soren: sounds like a good plan (that you do it...)
<cjwatson> pecisk: up to NonLanguagePackTranslationDeadline on https://wiki.ubuntu.com/HardyReleaseSchedule
<soren> fabbione: It's already running..
<cjwatson> seb128: or I can just fix it now if you haven't filed the bug yet ...
<seb128> cjwatson: I didn't, I was trying to figure how to copy the caspoer log out of the virtual machine which has no network set
<seb128> cjwatson: thanks ;-)
<pitti> seb128: FYI, I fixed the amd64 retracer chroot, retracer restarted now
<seb128> pitti: what was wrong? I fixed the i386 ones on saturday, they were crasher on out of ressources and I had to update it manually it had issue with the fontconfig update
<pitti> seb128: chroot was out of date due to some postinst failure
<seb128> pitti: ok, might have been the same issue than the i386 one, but that was saturday and I didn't want to work too much so I didn't look at the amd64 one
<pitti> seb128: hey, that wasn't meant as a blame in any way :) just keeping ourselves up to date
 * pitti hugs seb128
 * seb128 hugs pitti
<seb128> thanks ;-)
<cjwatson> seb128: casper fixed (I think), thanks
<seb128> cjwatson: thank you ;-)
<pitti> mvo: which package does the 'enable visual effects' tab come from? (for adding a bug task to bug 193978)
<ubotu> Launchpad bug 193978 in jockey "Jockey isn't used from Visual Effects tab" [Undecided,New] https://launchpad.net/bugs/193978
<pitti> mvo: does this selector still want/need to call jockey for --check-composite?
<emgent> pitti heya
<pitti> mvo: is that gnome-control-center?
<pitti> hi emgent
<emgent> pitti, have you time for main upload in hardy?
<emgent> security fix for openldap
<emgent> malone #197077
<ubotu> Launchpad bug 197077 in openldap2.2 "6.06 LTS: CVE-2007-6698, CVE-2008-0658" [Medium,In progress] https://launchpad.net/bugs/197077
<seb128> pitti: gnome-control-center
<seb128> pitti: I'll likely do an upload today, I'll fix that too
<doko> soren: known, I did want to delay that until I have icedtea6 working; it can be a build dependency, or the kernel running on the buildd. I don't know (promised elmo to do a build on ronne and see if a package built on that machine works or nor, but didn't do yet)
<pitti> seb128: on the g-c-c side this should just be s/r-m/jockey-gtk/
<seb128> pitti: ok
<pitti> ok, bug task added with a description
<emgent> pitti, have you time for upload this ? :)
<pitti> emgent: I'd rather leave this to the security team (jdstrand, keescook) TBH
<emgent> nope it's for hardy
<pitti> emgent: can you please send the debdiff to security@ubuntu.com? it's highly appreciated
<emgent> there isnt hardy-security now
<pitti> emgent: ah, for hardy; yes, can do
<emgent> pitti, thanks :P
<emgent> i'm in motu-swat, know procedures eheheh, Thanks
<mvo> pitti: yes, g-c-c
<mvo> seb128: thanks for looking into this, fix should be straightforward
<seb128> mvo: no problem, that's just changing the command in the desktop effects patch
 * mvo hugs seb128
 * seb128 hugs mvo
<emgent> pitti, please open task too, i can only nominate ubuntu version affected. Thanks :P
<pitti> emgent: already done
<emgent> pitti, cool
<soren> doko: Ok, cool. I've got plenty of cpu cycles to spare right now, so I'll just let the build finish that I have running on my local system, and after that, I'll try in an up-to-date sbuild on my local system as well and see if that works.
<doko> soren: thanks, currently spending my cpu's for the v6 packages
<pitti> emgent: uploaded, thanks
<emgent> pitti, cool :P
<soren> doko: No worries. :)
<\sh> asac: if you have an usb headset, set your soundconfig in gnome to default to the headset and try to get some sound from flashplayer (adobe) on the headset...I tried that on different systems (amd64/i386) and I don't succeed...I tested it with gutsy and it works as expected...
<\sh> asac: I wonder if it's a regression using pulseaudio now or what...strangly I get the login sound of gnome when using newly connected headset also very late
 * \sh is going to reboot...
<ion_> sigh, away nicks
<\sh> asac: bug #144356
<ubotu> Launchpad bug 144356 in flashplugin-nonfree "Audio from Flash in Firefox does not go to correct sound device" [Medium,Confirmed] https://launchpad.net/bugs/144356
<\sh> asac: but I think you are the wrong guy to bother...
<\sh> who is responsible for pulseaudio? :)
<asac> ok ;)
<\sh> asac: but, one question, there was the possibility to set another soundcard for usage in FF somehow...I wonder if that works
<asac> soundcard? not that i know of ... you could set FIREFOX_DSP
<\sh> asac: which defaults to "none" regarding /etc/firefox-3.0/firefoxrc
<\sh> ah..crimsun is the one to bug ;)
<crimsun_> err
<\sh> crimsun_: hehe :)
<\sh> crimsun_: please read the bugreport I mentioned a few lines above..
<crimsun_> just did
<\sh> crimsun_: fun part: mic of headset works...soundoutput via headset -> no way, but built-in card sound's there
<crimsun_> so with libflashsupport (and pulseaudio-esound-compat) installed, for GNOME, the configured "default" card via alsa-lib (using an asoundrc, e.g., with asoundconf set-default-card) does not function correctly or as anticipated?
<\sh> crimsun_: right...headset is now default device (asoundconf set-default-card ...) restarted gnome, sound from gnome comes via headset...but flashplugin (nonfree) uses still the built-in card...
<crimsun_> pulseaudio is configured to ignore a user's asoundrc, so that symptom is expected.
<\sh> crimsun_: even gnome-sound-settings is set to the default (headset)
<crimsun_> you can verify that it's pulseaudio<->libflashsupport by removing pulseaudio and libflashsupport
<crimsun_> ("it's"->"it's pulseaudio's/libflashsupport's fault")
<asac_> 12:26 < asac> \sh: i am not even sure that this is used anymore
<asac_> 12:28 < asac> \sh: it just started ffox with the given sound wrapper
<asac_> 12:28 < asac> so maybe try that by hand to see if it helps
<\sh> crimsun_: apt-get remove pulseaudio libflashsupport ?
<\sh> argl...apt-get remove libflashsupport wants to remove flashplugin-nonfree
<crimsun_> \sh: ah, right, it's now a dependency
<ogra_cmpc> crimsun_, are you sure its needed on non networked pules ?
<crimsun_> well, dpkg --force-depends -P libflashsupport
<ogra_cmpc> *pulse
<crimsun_> ogra_cmpc: where "it" refers to libflashsupport?
<ogra_cmpc> crimsun_, right
<ogra_cmpc> i know my ltsp users never had probs locally, only with the networked connection
<crimsun_> ogra_cmpc: I didn't make the change that makes flashplugin-nonfree Depend on libflashsupport, and no, I don't believe it's necessary
<ogra_cmpc> right
 * ogra_cmpc didnt make that either
<\sh> crimsun_: I removed pulseaudio...let me restart gnome...one min
<\sh> crimsun_: removing and stopping pulseaudio helped
<crimsun_> Keybuk: is your 96_uinput_device_support.patch in Ubuntu's hal bzr intended for hardy?  (I'm unsure whether to number an intended patch 96 or 97, so I chose the latter for a proposed fix for 194052
<crimsun_> Keybuk: ..and 194719)
<crimsun_> \sh: post-removing libflashsupport?
<\sh> crimsun_: nope...only killall -9 pulseaudio :)
<crimsun_> \sh: with libflashsupport still installed?
<\sh> crimsun_: jepp
<Keybuk> crimsun_: yes
<crimsun_> \sh: ok, thanks
<crimsun_> Keybuk: thanks.
<\sh> crimsun_: any theory? :)
<crimsun_> seb128: several people have reported positive feedback that fixes the battery-reporting regressions by using the 97_fix_power_info_via_sysfs.patch I've added to my hal bzr branch, but I'm waiting for additional feedback
<crimsun_> seb128: do you feel it's safer to revert the 01_proc_sys_batteries.patch or to merge 97_fix_power_info_via_sysfs?
<seb128> crimsun_: question for pitti
<ogra> \sh, try without libflashsupport but with pulse running
<seb128> crimsun_: I think we need to address the dual battery issue in hardy anyway so might make sense to patch rather than revert
<crimsun_> seb128: thanks.
<ogra> \sh, i think the dependency is wrong here, that should be a recommends or suggests
<crimsun_> (will read scrollback tonight.)
<seb128> crimsun_: where are your changes btw?
<Hobbsee> mvo: it's all your fault.  iv'e filed you a bug.
<Hobbsee> :)
<\sh> crimsun_: gimme a sec...
<hunger> libicu36-dev and libicu36 are marked as obsolete in aptitude here. That has been so for a while... Will libboost-regex get updated soon, so that those debs can get dropped for good?
<hunger> Oh, it is already fixed;-) aptitude just has not noticed that libicu-dev can replace libicu36-dev:-)
<\sh> ogra: give me again your magic dpkg call?
<\sh> ah..--force-all helps
 * \sh relogins
<\sh> crimsun_: dpkg -r --force-all libflashsupport -> sound works (after relogin, pulseaudio running)
<\sh> crimsun_: and flash doesn't use PA anymore...
<\sh> crimsun_: according to padevchooser/manager
<pitti> seb128, crimsun_: hal> seems that Debian works on a git head checkout with loads of bug fixes, which includes this problem; seems upstream isn't too interested in releasing a 0.5.11, despite several requests
<\sh> crimsun_: updated bug #144356
<ubotu> Launchpad bug 144356 in flashplugin-nonfree "Audio from Flash in Firefox does not go to correct sound device" [Medium,Confirmed] https://launchpad.net/bugs/144356
<pitti> crimsun_: 97_fix_power_info_via_sysfs sounds interesting, where is that?
<seb128> crimsun_: look on his code.launchpad.net maybe?
<seb128> ups
<seb128> pitti: ^
<pitti> seb128: ok
<pitti> seb128, crimsun_: found it
<pitti> crimsun_: that's missing http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=85390b2b5b45253f64867895204d95bf2e1dc357, I'll add that as well, ok?
<pitti> seb128: yep, that fixes it instantly \o/
 * Hobbsee hugs pitti
 * pitti hugs Hobbsee back
<Hobbsee> guten tag.  Wie gehts?
<pitti> Hobbsee: prima, danke!
<Hobbsee> :)
<laga> if i was granted a free wish, i'd ask that an archive admin looks at mythbuntu-diskless-client-builder in the NEW queue so we can get our Mythbuntu alternate disks built.
<laga> too bad there are no fairies :/
<Spads> laga: I'd wish for more wishes.
<Spads> (Just saying)
<laga> Spads: true. just gotta avoid recursion
<Hobbsee> laga: hint:  offer beer.
<laga> Hobbsee: to the fairy?
<Hobbsee> laga: to the archive admin.  would you trust a drunk fairy?
<laga> Hobbsee: would i trust a drunk archive admin? well, he'd be more likely to miss problems in the package
<Hobbsee> laga: the archive admins take a fair few beers to get them drunk.
<Mithrandir> we could also first review the package, then drink the beer
<laga> yes, that'd makes sense.
 * laga offers virtual beer
 * soren once again has a process in Running state, using all of one of his cores, that won't be kill -9'ed :(
<Hobbsee> laga: it's usually future-beer, payable at the next FOSS event you see them at
<superm1> mmm future beer.  much better than old past beer.
<superm1> everything tastes better in the future.
<Hobbsee> heh
<emgent> Hobbsee, please can you open task to malone #195949
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949
<emgent> i can only nominate :(
<Hobbsee> emgent: open task?
<emgent> Nominate for release
<seb128> pitti: excellent, do you plan to upload that to hardy?
<emgent> i'm not motu and i cant open task.
<emgent> please open for my nominate release :P
<pitti> seb128: today, yes
<Hobbsee> emgent: for which release?
 * seb128 hugs pitti
<seb128> pitti: thanks
<emgent> Hobbsee,
<emgent>  Nominated  for Dapper  by Emanuele Gentili
<emgent> Nominated for Edgy by Emanuele Gentili
<emgent> Nominated for Feisty by Emanuele Gentili
<emgent> Nominated for Gutsy by Emanuele Gentili
<emgent> please open task for this
<Hobbsee> there you are
<kagou> Hi
<seb128> hey kagou
<emgent> thanks Hobbsee
<Hobbsee> you're welcome
<ogra> sigh, does anyone else have probs rsyncing from cdimage.u.c ?
<thegodfather> ogra: yes
<soren> ogra: Nope. Works fine.
<soren> hardy-desktop-amd64.iso 20.67M   2%    1.53MB/s    0:07:36
<thegodfather> ogra: it's berillium that hangs from time to time
<soren> wroom.
<thegodfather> soren: depends which one you get
<soren> Ah. I'm using chromium.
<fabbione> didn't have time to ping #is for that
<fabbione> i noticed this night because i found hanging sessions for weeks
<soren> beryllium works for me, too.
<fabbione> soren: it hangs from time to time.. probably it depends from the load
<soren> $ rsync beryllium.canonical.com::
<soren> cdimage        	Ubuntu CD Images
<soren> Ah, yes. That might be.
<fabbione> soren: download from it a big fat image
<fabbione> not just the index
<Mithrandir> fabbione: fwiw, I can confirm it
<fabbione> soren: for me it was bailing out at 75% of transfer
<fabbione> Spads, Ng: ^^^ ping rsync
<fabbione> :)
<Spads> fabbione: hmm, want to discuss it in #canonical-sysadmin?
<fabbione> Spads: sure.. one sec
<jdstrand> emgent: I am working on fixes for openldap for stable releases
<jdstrand> emgent: hi btw :)
<emgent> heya jdstrand :P
<emgent> jdstrand, please see malone #197077
<ubotu> Launchpad bug 197077 in openldap2.2 "6.06 LTS: CVE-2007-6698, CVE-2008-0658" [Medium,In progress] https://launchpad.net/bugs/197077
<emgent> gutsy and feisty debdiff ready.
<emgent> hardy uploaded.
<emgent> there is a little problem in dapper
<emgent> i saw your changelog post, but is wrong
<emgent> you wrote debian/patches/CVE_* in changelog, but in dapper there isnt debian/patches directory
<jdstrand> emgent: yeah-- it's inline
<emgent> yep, i saw that later, only changelog is wrong :P
<emgent> anyway when you have time please consider my debdiff for openldap2.2 on #197077
<emgent> see also malone #195949
<ubotu> Launchpad bug 195949 in vlc "VLC Arbitrary memory overwrite in the MP4 demuxer" [Medium,Fix released] https://launchpad.net/bugs/195949
<emgent> and malone #191196
<jdstrand> emgent: I shall.  thanks!
<ubotu> Launchpad bug 191196 in gnatsweb "[gnatsweb] [CVE-2007-2808] cross-site scripting vulnerability" [Low,In progress] https://launchpad.net/bugs/191196
<emgent> all debdiff ready :)
<emgent> jdstrand, thanks to you :P
<emgent> oh jdstrand some hour ago one user join to ubuntu-hardened, seems to security@ubuntu.com reject mail
<emgent> keescook mail too.
<emgent> user sent to me this mail, i will send to you now
 * jdstrand nods
<emgent> jdstrand, done. sent to jamie@ubuntu.com
<ScottK> emgent: FYI, since these channels are logged, email addresses posted here tend to get scraped by spammers.
<emgent> ScottK, right, sorry.
 * ScottK isn't who might need the apology.  None of those addresses are mine ...
<emgent> Addresses are also in wiki but it is your right is a way of thinking
<emgent> sorry people.
 * Treenaks gave up, and just installed spam filters
<emgent> :)
<pitti> seb128: hal uploaded, it works for me; feedback from you appreciated, since you had a range of problems
<seb128> pitti: thanks
<seb128> pitti: I'll try ask soon as the update is available
<soren> pitti: Power management related changes, by any chance?
<pitti> soren: yes, fixes reading battery info
<seb128> soren: fix the battery charge being wrong, icon displayed on ac, etc
<pitti> i. e. THE battery bugs du jour
<soren> Sounds great.
<seb128> I guess I'll still have the timeout when changing backlight thing though
<pitti> hm, didn't try that one
<seb128> I should try git and bug upstream if the bug is there too
<pitti> sjoerd: ^ btw, I saw that you gave up on 0.5.11 and started packaging 0.5.10+git head; great! I was this --><-- close to doing the same, and I'd still like to do it to clean up the package, get rid of so many more bugs, etc.
<seb128> soren: do you have a bug about virt-manager breaking the network configuration?
<seb128> soren: when using it my network switch from wireless to some wired network but I've no wired network
<pitti> sjoerd: do you have a release plan already? I'd like to share the orig.tar.gz with Debian
<emgent> jdstrand, i go to my office, if you have some question about my debdiff please use query, Thanks :)
<emgent> bye pople
<soren> seb128: There's some funny business going on. It's a bit involved.
<sjoerd> pitti: Yeah, getting the sysfs stuff to work required like 16 patches from git.. Which was insane
<soren> kees changed hal to also report virtual interfaces, such as vlan's and bridges.
<pitti> sjoerd: right, and even the current stack of patches is insane enough :)
<sjoerd> pitti: Several people tested it (i don't have an acpi laptop), everyone reported it was ok, so i'm planning to do an upload later today
<soren> network-manager knows nothing about these, so assumes they're wired interfaces, and IIRC it prefers those over wireless ones.
<pitti> sjoerd: oh, awesome! my primary concern is the shared orig.tar.gz, since I have to merge anyway
<sjoerd> http://beast.luon.net/~sjoerd/hal/ has the orig.tar.gz
<pitti> sjoerd: oh, thanks
<pitti> seb128: I'll do that merge and put it in a PPA
 * pitti hugs sjoerd
<sjoerd> heh
<sjoerd> np :)
<pitti> sjoerd: boggle, only four patches left? :)
<cody-somerville> Wow. Who ever made changes to batteries in hardy, thanks. You've expanded my battery life to to 52 hours and 15 minutes :P
 * seb128 hugs pitti
<sjoerd> pitti: Yeah, most of the stack came from git anyways and i pushed most of what we had into upstream git too :)
<sjoerd> I should probably push 55_nonpolkit-mount-policy.patch too, the others are a bit debian specific
<pitti> sjoerd: ^ I already did that ages ago
<sjoerd> hrm
 * seb128 curses avahi
<pitti> but a little later they reverted it for some reason
<sjoerd> pitti: hrm, oh
<sjoerd> pitti: i thought we did indeed, but didn't see it in git
<sjoerd> Guess, finding out the reason for the revertion needs to be added to my todo list then :)
<soc> hi
<soc> some time ago there was a blueprint about integarting/upgrading to grub2 ...
<soc> i think it was for feisty ... did anything happen in the mean time or was it just a lack of time/problems/etc?
<\sh> ScottK: when I knew which wine version will work in the future before hardy release, I would be  happy
<\sh> grmpf..wrong channel
<soc> there is a grub2 package in the repos ... bt i don't know how integrated it is ...
<soc> will it be recognized on kernel updates when writing the automagic kernel lists?
<soc> mhh
<soc> maybe i better ask in +1
<Mithrandir> soc: it never received much attention
<pitti> sjoerd: it was committed in http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=9d607e21cac65dddaf0c8cb2443865d9ae509393 and reverted in http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=42174283c756d377d2f1f2f346d32aec502d4769 without an explanation
<\sh> ScottK: 4.2.3.x doesn't work (rebuild it today)
<\sh> ScottK: and 3.4 I'll try now
<\sh> grmpf
<superm1> soc, i added a few things to it to make upgrades a little nicer, but it needs more attention yet
<soc> superm1: a thanks
<soc> so just installing grub-pc isn't enough?
<superm1> soc, well you'll get them if you do
<soc> or should it be in most cases enough?
<superm1> it still chainloads from grub  to grub2
<soc> ah ok
<superm1> you'll have to manuall grub-install to a hard drive if you want to go right into grub2
<soc> superm1: how long will it take to abandon grub1?
<soc> ah ok
<superm1> soc, there was a discussion about it at the last UDS
<soc> sorry, i wasn't there,,,,
<superm1> soc, and it was deferred
<superm1> soc, I forget the exact basis for the decision
<soc> ah ok...
<superm1> soc, but it will do your basic stuff for you, add new kernels, use a UUID, turn on a bootsplash etc
<robertj> what is the package name for Bryce Harrington's xrandr gui?
<soc> ah ok
<soc> so install grub-pc and run grub-install manualy?
<seb128> robertj: there is no such guy?
<seb128> robertj: we decided to modify the existant capplet using the redhat changes
<superm1> soc, yeah go ahead and give it a go.  at very least you can file some bugs about what doesn't work for you
<soc> ok ...
<robertj> seb128: is that in hardy or only in launchpad?
<soc> i only have gutsy around atm ...
<seb128> robertj: what is your issue or question exactly?
<soc> any fixes between 1.95 and 196 which are critical?
<superm1> soc, you won't see any of the customizations in gutsy.  when you upgrade to hardy you will.
<soc> ah ok
<soc> then i wait until my notebook comes homes again :-)
<robertj> seb128: so is https://code.launchpad.net/~bryceharrington/gnome-control-center/ssp-xrandr the most current branch?
<seb128> robertj: depending what you want, is that to write news, take screenshot, do you have a bug?
<robertj> just poke at it
<lool> seb128, pitti: pitti probably knows about this all already, but sjoerd prepared a new git snapshot of hal in pkg-utopia which would fix the double batteries problem; I'm happy to report back when it reaches me; ATM I don't have double batteries, but I've had GPM eat 125% CPU upon resume
<seb128> robertj: likely then
<pitti> lool: yes, I know
<pitti> lool: I already uploaded a new hal with those particular fixes
<seb128> lool: read the log between pitti and sjoerd
<seb128> lool: that was being discussed not too long ago ;-)
<pitti> lool: and I'm currently merging hal to that git checkout, and I'll put it in a PPA
<seb128> lool: ah, dunno about the 125% cpu issue, seems to be a fun one ;-)
<seb128> pitti, lool, sjoerd: any idea about this avahi one?
<seb128> $ ps ax | grep avahi
<seb128>  5527 ?        Ss     0:00 avahi-daemon: registering [seb128-desktop.local]
<seb128> it doesn't move from registering
<lool> seb128: Right, unfortunately I can't read the whole of the ubuntu-* chans; I could have checked before bringing this up though
<seb128> avahi-browse works correctly and rhythmbox too
<pitti> lool: don't worry, thanks for bringing this up; better twice than never :)
<seb128> but that breaks gvfs dns-sd
<seb128> lool: that's alright, that was just in case you were interested in the discussion it was on the chan not too long ago, thanks for pointing it there ;-)
 * lool is interested in the fix!  :)
<sjoerd> seb128: as i said in #nautilus, that's a new one for me
<pitti> seb128: hm, seems that nautilus+gvfs doesn't provide any option any more to change mount options, or even disable automounting
<seb128> sjoerd: any hint on how to debug it or what information would be useful?
<seb128> pitti: no, gnome-mount likely needs to be ported to gvfs
<sjoerd> seb128: a tcpdump capturing multicast traffic might help
<sjoerd> seb128: and information about your network (very busy  or...)
<pitti> seb128: oh, disabling automount works, ok
<seb128> sjoerd: what is weird is that restarting avahi make it work correctly
<sjoerd> Yeah
<seb128> no, network is not busy
<seb128> I've almost no local activity
<seb128> and a dsl line where I'm mostly doing IRC at the moment
<pitti> seb128: argh, no, it doesn't; it just disables opening a nautilus for the new media
<seb128> pitti: is that an issue?
<pitti> seb128: well, I wanted to set different mount options
<seb128> sjoerd: https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/116984
<ubotu> Launchpad bug 116984 in avahi "Applications can't connect to avahi-daemon until avahi is restarted once." [Undecided,New]
<seb128> sjoerd: maybe something similar to https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/111834?
<ubotu> Launchpad bug 111834 in avahi "Race between avahi-daemon startup by dbus and .local check in if-up.d" [Undecided,New]
<pitti> ah, seems we can drop the vfat 'usefree' option with current kernel
<seb128> sjoerd: https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/124319
<seb128> bah
<sjoerd> seb128: neh, avahi-daemon itself doesn't care about the tags
<ubotu> Launchpad bug 124319 in avahi "zeroconf browsing broken" [Undecided,New]
<seb128> there is lot of people having a similar issue
<sjoerd> Hrmm, didn't get any reports in debian about it
<seb128> sjoerd: doesn't mean it doesn't happen, debian get a lot less desktop bugs actually
<sjoerd> That's true
<sjoerd> Which version of avahi does ubuntu have currently?
<seb128> current debian one
<seb128> with a change to start cups before
<pitti> 0.6.22-2ubuntu1
<seb128> rather the other way around
<seb128>     - debian/rules, debian/avahi-daemon.postinst: Sta    - debian/rules, debian/avahi-daemon.postinst: Start the avahi-daemon before
<seb128>       CUPS so that CUPS-shared printers appears in mDNS. (LP #173470)
<seb128> rt the avahi-daemon before
<seb128>       CUPS so that CUPS-shared printers appears in mDNS. (LP #173470)
<ubotu> Launchpad bug 173470 in avahi "[Gutsy SRU Request] Bad interaction with avahi" [Undecided,Fix committed] https://launchpad.net/bugs/173470
<seb128> ups, xorg bug
<emgent> back
<sjoerd> seb128: Are any of those bugs forwarded to avahi.org ?
<seb128> sjoerd: doesn't seems to be, looking at the bug list avahi has no maintainer in ubuntu
<sjoerd> hrm
<seb128> sjoerd: and I just noticed the issue today while looking at gvfs
<seb128> I can do it
<sjoerd> please do
<seb128> I get no "Server startup complete" in syslog
<sjoerd> Lennart is really the best person to look at that kinda stuff
<seb128> I do that when restarting avahi after boot though
<seb128> ok
<seb128> is he on IRC?
<sjoerd> He doesn't have network at his new place
<sjoerd> So not so much
<seb128> ok
<seb128> but he reads bug at work? ;-)
<sjoerd> Yeah from time to time
<sjoerd> And tends to reply on mails on wednesday :)
<sjoerd> So probably filing a bug and maybe dropping a mail might work :)
<pitti> mjg59: in hal's 88_change_pm_quirk_policy.patch you changed = "true" to != "false"; that isn't upstream, what is the difference?
<\sh> pitti: what does the valgrind output of --3348-- Reading debug info from /lib32/libpthread-2.7.so...
<\sh> --3348-- ... CRC mismatch (computed 74fb5800 wanted fdd5fd94)
<\sh> tell us?
<pitti> \sh: hm, no idea TBH
<ogra> hrm
<ogra> d-i doesnt like me on todays alternate
<cjwatson> correct, this morning's upload fixed that
<ogra> ah, thanks
<pitti> sjoerd: do you have an idea why Debian's hal still disables MacBook/Pro support?
<sjoerd> Because i don't trust it in opening /dev/mem and poking bits directly
<sjoerd> Somebody really should write a kernel driver for that
<pitti> sjoerd: ah, right, I remember now; thanks
<sjoerd> I'm honestly surprised that people prefer hacks like these instead of going to the little bit of extra effort to write a proper driver
<cjwatson> sjoerd: people get scared of the kernel :-/
<pitti> seb128: I still get the brightness popup corruption with hal git head; that looks like a real g-p-m/compiz bug, not a hal one?
<seb128> pitti: does the dbus-send command I gave you the other day create a dbus error on the hald side?
<pitti> didn't check yet
<pitti> seb128: still busy with sth else, can check later
<pitti> or, let me just upload to my PPA, for more testing
<seb128> pitti: the corrupted popup is due to the GetBrightness not working
<lool> Hi folks, I pushed a couple of ubuntu.hardy seeds changes; anyone need something before the next meta upload?
<jdstrand> soren: have you had a change to look at vmware2libvirt?  if not, I was thinking I'd branch libvirt and have you pull from there
<jdstrand> s/change/chance/
<soren> jdstrand: Don't bother. It's slowly bubbling towards the top of my todo fifo.
<jdstrand> soren: ok cool
<jdstrand> soren: once I have some time, I'll check on the vmmouse stuff we talked about
<jdstrand> then update the wiki
<soren> jdstrand: Cool!
 * jdstrand thinks it may be worthwhile to put the xorg.conf stuff in the manpage too-- but again, once I have some time :)
 * jdstrand seems to often mess up his pronouns when referring to himself in the 3rd person...
<lool> Cool, you can now simply use Bug:1234 in the wiki, and it links to a LP bug
<cjwatson> slangasek: is bug 187883 in a language you can translate?
<ubotu> Launchpad bug 187883 in debian-installer "NepotvrzenÃ© pÅeklady v debian-installer pro HH" [Undecided,New] https://launchpad.net/bugs/187883
<slangasek> cjwatson: <sigh> yes :)
<cjwatson> ta :-)
<cjwatson> I suspect it's "please update translations kthxbye" but wanted a double-check
<slangasek> yeah, that's what it is
<slangasek> I'll fire off a quick translation to the bug
<slangasek> there you go
<cjwatson> cheers
<emgent> heya people
<mvo> thekorn: heyho, is there a way to ask bughelper to show progress information?
<thekorn> mvo, short answer: no, sorry
<cbx33> hey all
<cbx33> whos handling GSoC
<pochu> mdke: I've just mailed ubuntu-doc for a UI change, but I'm moderated there. could you approve my post? thanks
<slangasek> Tonio_: you have the skim build failure in hand?
<Tonio_> slangasek: yep ;)
<slangasek> Tonio_: ok, cheers
<crimsun_> pitti: thanks for merging!
<TheMuso> lool: Did you know that mousetweaks was already in the desktop seed?
<lool> TheMuso: I did not
<lool> TheMuso: pushed a reverted mousetweaks addition
<TheMuso> lool: Ok no problem, thanks.
<seb128> hey TheMuso
<seb128> TheMuso: could you move onboard not in a submenu?
<crimsun_> seb128: Is http://launchpadlibrarian.net/12371481/gnome-power-manager_2.21.92-0ubuntu2.debdiff ok to apply & upload?
<seb128> crimsun_: sure, thanks
<crimsun_> seb128: done, thank you!
<TheMuso> seb128: I'll have a look at it today, probably do the same thing as what we do with orca, i.e don't show it.
<theunixgeek> Anyone have any experience with gtkmm? How does it compare to regular gtk+?
<cjwatson> theunixgeek: I found it very difficult to work with (even allowing for the language), largely because it's so different from the C interface; when I later learnt the Python GTK bindings, I was struck by how much better they were as a translation of the C interface
<theunixgeek> cjwatson: with python!? :O
<cjwatson> theunixgeek: I don't understand?
<theunixgeek> cjwatson: isn't GTK, like, originally made for C?
<cjwatson> err, I think you must have misunderstood me
<theunixgeek> cjwatson: I probably did.
<cjwatson> of course GTK is natively C
<theunixgeek> yes
<cjwatson> my point is that, even allowing for the language differences, the Python GTK interface is a very faithful rendering of the C interface into Python, with mostly just a few regular changes (in fact, I've used the PyGTK documentation as a reference when working on C GTK programs, just because I had it handy and there wasn't a whole lot of difference)
<cjwatson> whereas the C++ bindings are completely different
<cjwatson> and the changes, from what I remember, are quite irregular and hard to remember
<seb128> jamiemcc_: are the tracker status count supposed to indicate how many things it has indexed and how much it has to do?
<seb128> jamiemcc_: because the progressbar were always to 100% in the previous version and the new version counts are the same, that's not really useful
<jamiemcc_> seb128: for files it shows folerds indexed/ folders total
<jamiemcc_> for emails we cant reeally get a progress easily
<seb128> jamiemcc_: the folder count is always to 100% too
<seb128> jamiemcc_: maybe it would be better to not indicate a count if that's always 100% anyway?
<jamiemcc_> seb128: well if your files are indexed it will show equal numbers for total and indexed
<jamiemcc_> seb128: they have most meaning when you index from scratch
<seb128> well, it's strange because it's indexing
<seb128> but count is 100%
<seb128> alright
<jamiemcc_> seb128: if you reindex you will see the progress. If you are adding new files we dont know in advance how many folders there are
<mathiaz> slangasek: what do you think about the patch for bug 180493 ?
<ubotu> Launchpad bug 180493 in samba "nmbd shuts down when network disconnected" [Unknown,Confirmed] https://launchpad.net/bugs/180493
<seb128_> sjoerd: around you working on hal too? ;-)
<seb128_> s/around/are
<sjoerd> seb128_: from time to time
<seb128_> sjoerd: any idea on https://bugs.freedesktop.org/show_bug.cgi?id=14797?
<ubotu> Freedesktop bug 14797 in hald "GetBrightness broken on dell latitude since sysfs battery change" [Normal,New]
<sjoerd> seb128_: brightness level and batteries are totally unrelated
<sjoerd> Probably something else changed in his setup with the new kernel
<seb128_> sjoerd: the setup is mine and no, build the package has the bug, reverting the git change mentionned, make and running hald works correctly, applying the patch, make it's broken again
<sjoerd> hrmm
<seb128_> that is not clear
<seb128_> but with and without the patch in the same build directory make it work or not
<sjoerd> which specific patch is this ?
<seb128_> http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=4541abd23fd02118a1a7f8b825aed338d2a5d638
<seb128_> the one to remove the duplicate battery
<seb128_> that was the first one commited I think
<sjoerd> Yeah
<sjoerd> all others were fixes for reading out the sysfs interface
<seb128_> I guess it has a side effect somewhere
<seb128_> I tried to diff hald logs with and without the patch
<seb128_> but there is nothing obvious
<seb128_> and logs are not really short
<seb128_> pitti get the same issue on his dell laptop
<seb128_> the dbus-send comment timeout
<sjoerd> Could you put your lshal with and without this patch somewhere ?
<seb128_> sure
<sjoerd> Or just the diff ofcourse :)
<seb128_> sjoerd: http://people.ubuntu.com/~seb128/lshalchange
<seb128_> sjoerd: that's diff buggy not-buggy
<seb128_> buggy being the patched version
<sjoerd> Ok
<sjoerd> So only the procfs batteries disappeared, like they should
<sjoerd> that's really strange
<seb128_> indeed
<sjoerd> hrm.. the assertions fails because of the &err that is passed
<sjoerd> ooh
<seb128_> ooh? ;-)
<sjoerd> Yeah, found it
<sjoerd> the dell addon backend tries to check /org/freedesktop/Hal/devices/acpi_AC
<sjoerd> and uses the same error var for it, without actually checking if it was an error
<slangasek> mathiaz: 180493> wouldn't it be better to fix this with an if-up.d hook?
<sjoerd> with sysfs the UDI name has changed
<seb128_> sjoerd: ah, good catch
<seb128_> sjoerd: you rock ;-)
<sjoerd> thanks :)
<sjoerd> Strange hardware that needs different backlight values to be read when on AC vs. when on battery
<seb128_> sjoerd: will you comment on the bug upstream bug to say that or should I do it?
<sjoerd> I was just on my way to bed, so if you could :)
<sjoerd> It's really bad for the addon to rely on other devices udi's
<sjoerd> As there are no guarantees about the naming whatsoever
<seb128_> right
<seb128_> thanks for figuring what is wrong
<seb128_> will comment on the bug
<sjoerd> np
<sjoerd> night!
<keescook> crimsun_: any chance you've had time to document how to add hardening-wrapper to pbuilder?  I just added the sbuild details to Security/HardeningWrapper
<sjoerd> seb128_: Thanks for preemptively finding a bug that will hit us in Debian too :p
<seb128_> sjoerd: ;-)
<slangasek> mathiaz: that's how I had always intended to fix that bug, at least, barring an upstream fix
<mathiaz> slangasek: right. How would this work with multiple interfaces ?
<slangasek> mathiaz: idempotently; if nmbd is already running it does nothing, otherwise it starts it, and no corresponding if-down.d script
<soren> network-manager runs if-up.d scripts?
<slangasek> hrm, good question
<Keybuk> yes
<slangasek> good, 'cause otherwise things would be quite a mess :)
<mathiaz> slangasek: you wouldn't put a ifdown.d script ?
<slangasek> mathiaz: nope
<soren> Oh. I didn't know.
<Keybuk> soren: that's what NetworkManagerDispatcher does
<soren> mathiaz: It shuts down itself when the last interface disappears.
<mathiaz> soren: ya
<soren> Keybuk: Ah. I didnt' realise.
<mathiaz> slangasek: ok - that an ifup.d script makes sense.
<jmg> hi all
<jmg> can someone riddle me why pulseaudio is useful? isnt everything it does handled by alsa now?
<RAOF> jmg: Not transparent streaming to my server plugged into my stereo?
<RAOF> jmg: Not sample-caching, for sound-servner usage.
<awalton__> jmg, alsa's just a raw wire into the sound system. pulse-audio is like a giant mixer panel.
<jmg> didnt people learn from esd/arts that sound servers are not wanted?
<awalton__> actually, they learned people don't want bad sound servers.
<awalton__> pulse audio fixes quite a bit of what's wrong with all of the others, while retaining support for others.
<jmg> shrug
<jmg> give it another year
<jmg> and people will be frazzing over it the same way they did arts
<mathiaz> zul: could update your samba merge taking into account my comment on bug 180493 ?
<ubotu> Launchpad bug 180493 in samba "nmbd shuts down when network disconnected" [Unknown,Confirmed] https://launchpad.net/bugs/180493
<jmg> so does it block the sound device?
<jmg> ie can i play quake 4 at the same time as listen or whatever?
<TheMuso> jmg: What ssound output does quake use?
<jmg> alsa
<RAOF> As long as quake 4 doesn't use alsa in a broken way, yes.
<jmg> q4 uses openal
<RAOF> It probably works then, with the pulseaudio alsa plugin.
<jmg> the whole idea of sound servers just makes my skin crawl
<jmg> its like im back in 1998
 * RAOF doesn't see why.
 * awalton__ doesn't either.
<TheMuso> openal seems to use OSS from looking at what it depends on.
<jmg> developers never do.
<jmg> why do something in software that can be done in hardware
<awalton__> because nobody does sound in hardware anymore.
<jmg> sure, because the emu10k1 isnt widespread at all
<RAOF> And the hardware doesn't do the same thing anyway.
<awalton__> it's simple. if you don't like it, turn it off.
<TheMuso> Hrm ok, looks like openal must dynamically open the lib it needs, as for some weird reason it build-depends on libesd, libasound2, and libarts.
<awalton__> and it doesn't depend on alsalib? that is weird.
<TheMuso> It only depends on libc6.
<TheMuso> But yes it does build-depend on the above.
<awalton__> must do all kinds of fun run-time checks.
<TheMuso> Wow. You can even build it to either link at build time, or dynamically link at runtime.
 * TheMuso thinks about digging upstream to see if there is a pulseaudio plugin.
<jmg> wont matter
<awalton__> if it does ESD it does pulse at least.
<TheMuso> Yeah, but native pulse is better.
<jmg> dont most apps that use openal ship with their own openal library
<jmg> ut, q4, et etc
<TheMuso> The only real problem I see with esd, is that if sample caching is used, there is only a maximum sample size of 2048000, as opposed to the original esound's dynamically allocated sample size.
<TheMuso> jmg: I don't know.
<jmg> 23:24 < awalton__> it's simple. if you don't like it, turn it off.
<jmg> ^ i really am back in 1998
<jmg> ok, well ill give it a  go ( just got hardy), and report back
<awalton__> yes, bash it to pieces before you even try it.
<awalton__> that makes all kinds of sense.
<jmg> i was attacking the soundserver idea, not the implementation
<jmg> it's caused more problems than its fixed in the past
<jmg> i remain open to the possiblity that pulse might have learned something from arts/esd/jack/coreaudio
<TheMuso> Hrm, I think I just might make openal default to esd, and fall back to alsa.
<jmg> heh
#ubuntu-devel 2008-03-04
<cubias8719> hello. can anyone help me with compiz
<slangasek> this is not a help channel; see #ubuntu for help with Ubuntu 7.10, or #ubuntu+1 for hardy
<awalton__> or #compiz-fusion for compiz support.
<cubias8719> thank you
<nosrednaekim> is ubuntu doing the summer of code?
<keescook> hunh, I am unable to branch the casper bzr repo...
<Caesar> So where's a good place to discuss hardy installation failures?
<jmg> ubuntu+1?
<Caesar> So I can go there and see if someone'll sponsor a bugfix? or #ubuntu-bugs?
<cody-somerville> Caesar, You'd file a bug and attach your bug fix and subscribe either ubuntu-universe-sponsors or ubuntu-main-sponsors depending on what part of the archive the package resides in.
<crimsun_> keescook: I've documented it, yes, but it needs to be approved by $work.
<keescook> crimsun_: ah! okay, thanks.  :)
<TheMuso> keescook: What error do you get?
* slangasek changed the topic of #ubuntu-devel to: Archive: Feature freeze | soft freeze for alpha 6 | 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
<Hobbsee> hm.  hope there was nothing in main i wanted to add.
<jmg> so
<jmg> why are the alphas just called alpha?
<slangasek> because "why are the alphas called alphas?" is an easier question to answer than "what's a 'tribe'?"
<[reed]> slangasek: "bearing in mind that the Feature Freeze is also now in effect[3]" <-- except you don't have a [3] at the bottom of your mail ;)
<slangasek> \o/
<slangasek> it's always something, isn't it
<slangasek> :)
<[reed]> rly
<[reed]> ;)
<slangasek> I could send a followup entitled '[3]'
<slangasek> Caesar: ah, bug #198110 was your installer bug?
<ubotu> Launchpad bug 198110 in ubuntu-keyring "ubuntu-keyring doesn't install" [High,Triaged] https://launchpad.net/bugs/198110
<inkynoo1> Anyone else's icons all disappear today? I'm getting  "Cannot open pixbuf loader module file '/usr/local/etc/gtk-2.0/gdk-pixbuf.loaders'" when I try to run most GTK programs too
<somerville32> no
<inkynoo1> hmmm
<slangasek> Caesar: upload sponsored, cheers
<mneptok> cmpc, eh?
<mneptok> ogra: does that mean i get sane installtion methods in Hardy? ;)
<Caesar> slangasek: thanks
<TheMuso> 5~/c
<LaserJock> hi TheMuso ;-)
<TheMuso> Hey LaserJock.
<ScottK> slangasek: Apparently soyuz has grown the ability to make sure that Main backports only get built from Main sources.  So my Postfix backports for Dapper/Edgy are depwait.
<ScottK> slangasek: Any idea if there's a solution?
<ScottK> Note for the record that the existing Postfix 2.4.5 backport in Dapper couldn't be there if this had always been the case.
<slangasek> ScottK: hmm, we could move the postfix backport to the universe section? :)
<ScottK> slangasek: I've really no idea.  I'm sure this is another "Feature".
<ScottK> Because we wouldn't want to mix the unsupported backports from Main with unsupported backports from Universe.
<slangasek> is there any reason /not/ to just move the postfix backport to universe?
<lamont> slangasek: can different pockets have packages in different components?
<slangasek> lamont: sure
<lamont> what are they dep-wait on, I wonder?
<ScottK> slangasek: I guess not.
 * lamont is tired after a workout
<ScottK> tinycbd
 * lamont pukes
<lamont> wasn't that main in dapper/edgy?
<ScottK> Nope
<ScottK> slangasek: If you can do that, please do.
<lamont> yeah.  make it universe
 * ScottK has quit thinking about these sorts of things as problems in launchpad.  They're just encouragement to work harder on NM.
<slangasek> well, it looks like change-override.py, at least, is not accomodating
<lamont> slangasek: alternatively, we could pull the semi-decent tinycdb back to dapper-backports/main... :=)
 * lamont sleeps before he gets shot.
<ScottK> lamont: If we did that we could probably avoid the FTBFS on Dapper AMD64, so that wouldn't be bad.
 * milli wonders if lamont will clean up the puke
<milli> ScottK: rails fix should make it good
<GhotiPhud> hello
<GhotiPhud> I'm looking for the latest version of the "screens and graphics" program
<GhotiPhud> how would I get ahold of that?
<ScottK> milli: I'll fix up rails tomorrow.  I need to get to bed.
<pitti> Good morning
<ScottK> Good morning pitti.
<LaserJock> hi pitti
<highvoltage> ahoy LaserJock
<LaserJock> hi highvoltage
<Fujitsu> It's a LaserJock!
<LaserJock> hiya Fujitsu
<GhotiPhud> hi
<GhotiPhud> I want to get involved with ubuntu
<GhotiPhud> don't really know where to start though
<LaserJock> GhotiPhud: depends on what you're interested in. Have you read http://www.ubuntu.com/community/participate ?
<GhotiPhud> yeah
<GhotiPhud> I've just read that and a bunch of the links
<GhotiPhud> I was just trying to get the "Screens and Graphics" program code
<GhotiPhud> so I could see if I could get my tv-out to work with it
<GhotiPhud> I've got it working with the cli
<GhotiPhud> just can't make it work with that program
<GhotiPhud> so I figured I'd take a look
<stgraber> moin
<jmg>  /part
<jmg> :)
<pitti> seb128: bonjour
<pitti> seb128: good job with figuring out the brightness issue! I saw the patch on the upstream ML
<pitti> seb128: I'll apply it to bzr head soon and upload a new version to my PPA
<seb128> pitti: hello, thanks, credits goes to sjoerd who helped me too ;-)
<seb128> pitti: thanks
<pitti> seb128: ~ppa2 reverted some FDI changes which I thought weren't necessary any more with gvfs
<seb128> pitti: we should have gpm mostly back to normal once we have this change
<pitti> but now my internal partitions are back on the desktop
<pitti> so I think gvfs didn't do any fixes at all, it was still hal
 * pitti hugs sjoerd
<seb128> pitti: what change was that?
<pitti> seb128: setting volume.ignore for non-/media partitions
<seb128> pitti: weird
<seb128> pitti: http://paste.ubuntu.com/5250/
<seb128> pitti: it should only display mounts under the user directory or media
<pitti> hm
<pitti> ah, right
<seb128> pitti: ?
<pitti> /dev/hdc4 on /mm type xfs (rw)
<pitti> I get an icon for this one
<seb128> your partitions are under media?
<seb128> hum
<pitti> seb128: yes, the other two are under /media, they are (invalidly) automounted
<pitti> seb128: seems that gvfs/nautilus doesn't honor storage.automount_enabled_hint ?
<pitti> since /etc/hal/fdi/policy/preferences.fdi disables automounting for those
<pitti> seb128: /mm is in my fstab and mounted at boot; it's an internal partition
<pitti> seb128: so, if it's supposed to work like that in gvfs, I'd rather fix it there than working around it in hal, WDYT?
<pitti> seb128: is there an ubuntu bug # for the brightness issue?
<seb128> pitti: I didn't look to the flood of new gpm bugs since we did the battery change, let me look
<seb128> pitti: yes, agreed that was should rather fix gvfs than workaround
<pitti> seb128: ok, nevermind, I can look myself
<pitti> seb128: brightness patch works perfectly for me; I reported back to upstream, will commit it now
<seb128> pitti: bug #191725
<ubotu> Launchpad bug 191725 in gnome-power-manager "[Hardy] LCD Brightness Applet doesn't work properly" [Undecided,Confirmed] https://launchpad.net/bugs/191725
<seb128> hum, maybe not
<seb128> pitti: thanks, if you upload to your ppa I'll give it a try too
<pitti> bug mangled
<pitti> seb128: uploaded to ppa
 * seb128 hugs pitti, you rock ;-)
 * pitti hugs seb128
 * Fujitsu was going to file a bug on that, and is glad he doesn't have to.
<seb128> DOH
<seb128> did ctrl alt backspace again by error
<seb128> I blame ctrl-alt also being for workspace switching ;-)
<Fujitsu> That always used to hit me too, several times a day, because I didn't release Ctrl+Alt quickly enough after workspace switching. DontZap works well.
<pitti> mvo: hm, compiz doesn't save my session, instead I get a crash report on next login :(
<zdzichuBG> heh, winkey+number works better for workspace switching
<mvo> pitti: were does it crash? inside the session plugin?
<pitti> mvo: just ??
<pitti> mvo: I'll report it and let the retracers figure it out, ok?
 * Amaranth hides
<mvo> pitti: yeah, that is cool. thanks
 * Fujitsu shoots Amaranth for something Compizy.
<seb128> mvo: cool, the border issue is fixed in your new compiz as expected ;-)
 * mvo spots Amaranth hidding in a corner
<mvo> seb128: great
<pitti> seb128: bug 198295, I'd appreciate if you could put your feedback there, too
<ubotu> Launchpad bug 198295 in hal "FF exception request: update hal to git head" [Undecided,New] https://launchpad.net/bugs/198295
<pitti> anyone else, if you fancy trying out my new hal version and giving feedback here ^, I'll appreciate
<Fujitsu> pitti: Is it ~ppa3?
<pitti> Fujitsu: yes
<pitti> ah, still needs to be published
<Fujitsu> pitti: I wgot that a couple of minutes back to test the brightness fix, but is there anything else to look out for?
<Fujitsu> No, it was published 3 minutes ago on all archs.
<seb128> Fujitsu: do you have a dell laptop?
<pitti> Fujitsu: just whether it generally works for you and shows any regression
<Fujitsu> seb128: Yes.
<seb128> ok
<seb128> because the change is dell specific
<pitti> Fujitsu: wifi, suspend, removable drives, etc.
<pitti> mvo: ah, seems mine was just a dup of bug 131679
<ubotu> Launchpad bug 131679 in compiz "compiz.real crashed with SIGSEGV when attempting to unlock screen" [High,Confirmed] https://launchpad.net/bugs/131679
<mvo> pitti: can you reproduce this crash or did this just happend out-of-the-blue?
<mvo> pitti: its a nasty one, but we have currently no idea were it might come from and I was not able to reproduce it yet
<seb128> brb, testing changes
<Fujitsu> Yay, brightness works.
<Fujitsu> Wireless power, however, still does not :(
<pitti> Fujitsu: heh
<pitti> next version
<pitti> mvo: yes, I got it twice, I think
<Fujitsu> pitti: dellWirelessCtl seems to not like my wireless :(
<tjaalton> Fujitsu: the button doesn't turn the wireless on/off?
<Fujitsu> tjaalton: The BIOS-provided hotkey does it, but hal complains every five seconds that dellWirelessCtl failed.
<tjaalton> Fujitsu: oh, ok
<Fujitsu> I presume it tries to switch the radio off or on depending on if I've disabled it in NM.
<seb128> pitti:
<seb128> <garnacho> seb128: just a hunch, is there any way to disable what you do in ubuntu to have the process info just readable by root? maybe policykit is still not prepared to work fine with that. As far as I traced, the first time everything policykit works fine, for subsequent requests it doesn't
<seb128> pitti: any idea about that?
<pitti> seb128: we can disable it as a last resort, but maybe it'd be more helpful to fix this bug?
<pitti> seb128: no idea off-hand, no; I guess something tries to read argv[0] twice, the second time after disabling ptrace()
<pitti> and the result should be cached
<pitti> but that's just a random blue sky idea
<pitti> seb128: what's the recipe for reproducing?
<seb128> pitti: the question was rather how to disable this process info thing
<pitti> ah
<seb128> pitti: the bug is that gst tools work only once
<seb128> when you run them again they don't do any change
<seb128> you can try users-admin, add an user, close
<seb128> run it again and try to remove the user for example
<pitti> removing debian/patches/02_noptrace.patch
<seb128> it'll do nothing
<pitti> hm, then it's not that patch
<pitti> seb128: is there a bug # for it for assinging to me?
<pitti> I'd like to do it a little later
<seb128> pitti: don't bother for now, garnacho said he will have a look
<pitti> ok :)
<seb128> pitti: bug #188349 is about the issue
<ubotu> Launchpad bug 188349 in gnome-system-tools "[Hardy] Unable to save manual network configurations using network-admin" [High,Confirmed] https://launchpad.net/bugs/188349
<Amaranth> phew, pitti's compiz crash was not in the session plugin :)
<Amaranth> of course i have no idea where it is actually happening...
<pitti> Amaranth: no, indeed
<pitti> but I got it first with the new compiz
<pitti> and session saving doesn't work still, so I thought that at first
<Amaranth> when it dies in the eventLoop that means something most likely went wrong some time ago and just got hit
<Amaranth> PITA to debug
<sjoerd> pitti: ugh ofcourse davidz is contemplating a release a few days after doing the git snapshot package :/
<pitti> sjoerd: just read it, yes :)
<pitti> sjoerd: but it won't cause a lot of additional work AFAICS
<pitti> and who knows how long it'll take still
<sjoerd> neh, we did all the work already
<sjoerd> hopefully the dell laptop fix gets in
<pitti> I tested that on mine, works great
<pitti> I applied it to the git snapshot and uploaded to PPA
<\sh> I wonder what is the difference while compiling code...wine compiled on the host works like a charm, but building via sbuild doesn't
 * Fujitsu has no problems with pitti's ~ppa3.
<ion_> Huh. I wonder how the âwebâ got in there. deb http://archive.ubuntu.com/ubuntu hardy main restricted universe multiverse web
<ion_> Could we get rsync 3.0.0 to hardy? (sid has it already)
 * cjwatson mentions this thing called feature freeze
 * \sh needs a buildd admin :)
<ion_> cjwatson: To rephrase my question, does anyone think itâs worth a freeze exception? :-)
<\sh> we have really a big problem right now with wine...
<Fujitsu> \sh: Does normal sbuild give a working binary?
<\sh> Fujitsu: that's my problem ...
<Fujitsu> Is it just LP sbuild, or any sbuild at all?
<\sh> Fujitsu: sbuild doesn't pbuilder does (according to scott ritchie)
<\sh> Fujitsu: building wine on the host system..gives a running wine...and sbuild doesn't
<\sh> Fujitsu: my sbuild gives no running wine package, as ubuntus sbuild, too
<Fujitsu> That's not a buildd admin problem, then.
<\sh> Fujitsu: well, we need to find the differences of a local source build and a build via sbuild
<\sh> Fujitsu: what I'm doing now, I'm using a snapshot sbuild chroot and interactive build wine...let's see what's the outcome is..
<\sh> Fujitsu: so now, any sbuild gives a crashing wine...
<Mithrandir> \sh: yeah, blame poor sbuild.
<\sh> Mithrandir: I don't blame sbuild...we need to find out what's the difference ... what does sbuild do what a normal source build doesn't do ;)
<\sh> Mithrandir: and you agree with me, that pbuilder -> works , sbuild -> doesn't work is really a strange thing, yes? :)
<Mithrandir> it's a bug in the package which picks up something from the build environment, then.
<\sh> Mithrandir: and this we need to find out :)
<ogra> yay
 * ogra dances ... edubuntu addon works fine on non networked installs :) 
<\sh> ogra: congrats :)
<laga> nice :)
<ogra> bah, i suck at kturtle :)
<Riddell> pitti: could you give back kdeartwork-kde4, kdenetwork-kde4, kdeutils-kde4 ?
<pitti> Riddell: done
<Riddell> thanks
<\sh> Mithrandir: FYI, manually build wine in snapshot schroot (the very same chroot which is used by sbuild) gives working binaries of wine...
<Hobbsee> pitti: brightness issue?
<pitti> Hobbsee: changing screen brightness on dell laptops
<Hobbsee> pitti: oh, every few mins, back to the set brightness?  yeah, i was meaning to report that.
<Hobbsee> pitti: did they manage to fix the "brightness thing comes up every few minutes, and sometimes corrupts the display, and won't go away again" too?
<pitti> Hobbsee: no, actually it was about a broken g-p-m status icon when trying to change it
<Hobbsee> oh.  damn.
<pitti> Hobbsee: but maybe your problem is fixed now as well; please try my PPA version
<Hobbsee> pitti: where is it?
<pitti> it has literally ~ 100 bug fixes, I don't remember all of them
<pitti> https://edge.launchpad.net/~pitti/+archive
<Fujitsu> Hobbsee: It fixed the randomly corrupt brightness indicator for me too.
<Hobbsee> Fujitsu: oh goody
<Hobbsee> Fujitsu: do i have to do anything else after it installs and restarts hal?
<Hobbsee> pitti: thanks
<Fujitsu> Hobbsee: Nope.
<Hobbsee> good
<Fujitsu> Just press the brightness keys and watch it work magically.
<Hobbsee> oh wow.  it even shows the correct things now
<Fujitsu> Yep.
<Hobbsee> way cool.  earth is supposedly going to blow up.
<Fujitsu> Is there any reason that it doesn't use the nice translucent window that the volume control does?
<zdzichuBG> noone coded it
<Fujitsu> I would have thought that they would have used the same method to display it...
<slytherin> asac: gnash plugin is not detected on hardy. The problem is there is no link in /usr/lib/firefox-addons/plugins to /etc/alternatives/firefox-flashplugin. But I don't think this is gnash specific.
<ogra> slytherin, that should rather be xulrunner-addons, no ?
<Hobbsee> pitti: wow, it really does seem to fix it
<slytherin> ogra: I think so. But for some reason the link present /usr/lib/firefox/plugins is not working
<zdzichuBG> Fujitsu: yeah, it simply needs copying code from gnome-settings-daemon into gnome-power-manager
<slytherin> ogra: And /usr/lib/firefox-3.0b3/plugins is a symlink to /usr/lib/firefox-addons/plugins
<ogra> ogra@ceron:~$ ls /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so
<ogra> /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so
<ogra> its there for me and works fine
<ogra> and it properly points to /etc/alternatives/xulrunner-addons-flashplugin
<Fujitsu> zdzichuBG: Ah, right, forgot they were generated by different apps.
<ogra> which in turn points to /usr/lib/flashplugin-nonfree/libflashplayer.so
<slytherin> ogra: Ok. So there is no /usr/lib/xulrunner-addons/plugins/flashplugin-alternative.so in case of gnash which is causing problem.
<ogra> slytherin, aha
<slytherin> ogra: I will file a bug against gnash
<ogra> slytherin, that should be set by the postinst of gnash
<ogra> i bet there are already update-alternative lines for the old location
<slytherin> ogra: A bug is there already it also includes a patch (but no debdiff). bug #194379
<ubotu> Launchpad bug 194379 in gnash "enable xulrunner 1.9/firefox 3.0" [High,Confirmed] https://launchpad.net/bugs/194379
<asac> slytherin: yes flash upload will happen within a few days
<slytherin> asac: Ok. SO will you also fix the bug I just mentioned in 0.8.2 packaging?
<asac> yes
 * asac lunch time
<slytherin> asac: ok, thanks
<StevenK> pitti: libmiracle0.2.4, libmlt0.2.4 and libvalerie0.2.4 only look to depend amongst themselves, so can all be NBS'd.
<pitti> StevenK: great, thank you! removed
 * Hobbsee removes yada, and kmos, too
 * ScottK cheers
<slytherin> pitti: Please tell me if I should log a bug for this. I am using b43 driver with appropriate firmware on my ibook. It works fine but jockey shows that the driver is 'Not Enabled' but it says it is 'In Use'.
<pitti> slytherin: please do file a bug, yes; do 'jockey-gtk --list --debug 2>&1 | tee /tmp/jockey-debug.txt' and attach the log
<slytherin> pitti: I will file a bug right now and will provide additional info tomorrow.
<pitti> slytherin: there is already a bug about it, btw
<pitti> slytherin: ah, nevermind, that was a different case (enabled, but not in use)
<tjaalton> pitti: now that we have libxcb-enabled libx11 again should we default to sloppy locks like it was for a brief time during feisty? old java's fail currently (bug 87947)
<ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Unknown,Fix released] https://launchpad.net/bugs/87947
<pitti> not really my field of expertise, I'm afraid
<pitti> tjaalton, bryce: ^ ?
<tjaalton> yep, it's me ;)
 * pitti hugs tjaalton
<tjaalton> pitti: I'll ask bryce about it later, it should be safe to use sloppy locks by default
 * tjaalton hugs pitti back for adding cmdline-options to jockey
<pitti> :)
<pitti> I'm currently at adding --check-composite
<pitti> and next upload will enable it for fglrx, too
<tjaalton> I can finally fix bug 54335 :)
<ubotu> Launchpad bug 54335 in linux-restricted-modules-2.6.24 "fglrx should contain install instructions" [Low,Confirmed] https://launchpad.net/bugs/54335
<ScottK> slangasek: Apparently republishing the postfix backport for Dapper into Universe wasn't enough to convince soyuz that tinycdb exists.
<lamont> ScottK: does the log show it fetching  universe in the apt-get update?
 * ScottK looks
<ScottK> lamont: It shows that it does not.
<lamont> then it didn't really go into universe. :(
<ScottK> Launchpad says it is, but we all know Launchpad lies.
<lamont> ScottK: you could always just re-upload postfix to dapper-backports with tinycdb-crack turned off..
<cjwatson> 05:51 <slangasek> well, it looks like change-override.py, at least, is not accomodating
<cjwatson> which sounds like there was a problem
<lamont> yeha
<lamont> yeah, even
<ScottK> lamont: If there isn't a soyuz solution I'll do that, but I'd like to get this worked out.  Stuff moved from Universe to Main all the time and if this new 'feature' stays with us it will be a substantial complication for backports.
<BenC> Ok, my two new packages got rejected with "None"
<BenC> how am I supposed to know why if no one puts in a decent comment?
<BenC> "If you don't understand why your files were rejected..."
<BenC> I think that would be the case for everyone if that is the most common rejection reason ("None")
<BenC> Riddell: ping
<BenC> Riddell: is the XubuntuY convention supposed to be used for packages that are only in Ubuntu as well?
<Riddell> BenC: yes unless it's certain that it won't ever be in debian (e.g. the linux packaging)
<BenC> hmm, never had that enforced for new packages before...ok
<ogra> but then you'd package native anyway
<BenC> ogra: it has an upstream, it's just not a Debian sync
<ogra> ah
<BenC> Riddell: ok, is there anything else wrong? I don't want to reupload just to hit another reject
<Riddell> BenC: everything else is fine
<BenC> Riddell: ok, 2 minutes and they will be back in the queue
<BenC> Riddell: upload completed for both with 0ubuntu1 revisions
<miguillo> hello everybody
<Riddell> BenC: groovy, accepted
<BenC> Riddell: thanks!
<Riddell> calc: new openoffice binary packages, main or universe?
<miguillo> I'm trying to package tomcat6, is there a wnpp list for ubuntu? or i should apply to debian's one?
<ScottK> miguillo: For Ubuntu you file a bug against Ubuntu and tag it 'needs-packaging' and then assign it to yourself.  Filing a Debian wnpp bug too is also good.
<Bashtoni> Are the issues with the hardy installer and software RAID known?
<cjwatson> Bashtoni: --verbose
<Bashtoni> cjwatson: Gives me an error about being unable to remove files from the target
<cjwatson> which CD exactly?
<cjwatson> "hardy installer" is very vague
<Bashtoni> cjwatson: Netinstall (PXE)
<cjwatson> Bashtoni: bug 198106
<ubotu> Launchpad bug 198106 in partman-target "Configure partitions for RAID1, received: The installer needs to remove operating system files from the install target, but was unable to do so." [Critical,Fix released] https://launchpad.net/bugs/198106
<Bashtoni> Thanks :)
<cjwatson> Bashtoni: I'd appreciate verification of that fix once it hits your mirror
<Bashtoni> cjwatson: No problem, will do
<zul> we are going to be doing a merge from debian that has a couple of bugfixes for samba do we need a ffe?
<sabdfl> Riddell: is there a guide to moving to KDE from KDE3 on Hardy?
<sabdfl> KDE4, sorry
<Riddell> sabdfl: in gutsy or hardy?
<sabdfl> hardy
<sabdfl> i have a KDE3 desktop, want to try out KDE4 again
<Riddell> sabdfl: just install kde4-core
<sabdfl> ok, thanks
<sabdfl> does that drop all the kde3 stuff?
<Riddell> or kde4 for unadulterated full thing
<Riddell> sabdfl: no, they install alongside
<Riddell> just log out and select kde4 from the display manager
<sabdfl> how do i make sure i get kde4 desktop environment on login?
<sabdfl> ok
<robertj> sabdfl get's pretty good tech-support ;)
<laga> yeah. i wonder why.
<propagandist> Should dpkg-reconfigure setup DPKG_MAINTSCRIPT_PACKAGE (so that dpkg-trigger calls work correctly)?
<cjwatson> hmm
<cjwatson> interesting question
 * cjwatson asks the dpkg-trigger author elsewhere
<cjwatson> propagandist: we think it should but it'll be a bit fiddly to do. Could you file a bug on debconf about it, please, to make sure it doesn't get forgotten?
<ScottK> glatzor: I'm currently going through kdeguidance bugs and I see in Bug #93749 you said you had some displayconfig-gtk changes you were going to move to the backend.  I was wondering if you had done that (I don't have an easy way to test for this bug) or could point me at the right place to check for it in the backend?
<ubotu> Launchpad bug 93749 in kde-guidance "[apport] GUI tools don't handle a missing xorg.conf file correctly" [Medium,In progress] https://launchpad.net/bugs/93749
<propagandist> cjwatson: sure thing :o) already halfway there
<Xteven> hi, I'm wondering what criterium is used to decide which packages are shown in gnome-app-install, and which aren't ?
<glatzor> Xteven: the availability of a desktop file (menu entry)
<Xteven> hmm
<Xteven> is that information encoded in the Packages file of the repository somehow ?
<glatzor> ScottK: one moment
<ScottK> glatzor: Thanks.
<glatzor> Xteven: what do you want to do?
<glatzor> Xteven: /usr/share/app-install
<Xteven> glatzor: I'm trying to get one of my packages to show up in the gnome-app-install interface :)
<glatzor> Xteven: do you have got a custom distribution?
<glatzor> Xteven: otherwise contact Canonical in the case of a proprietary software or try to get it into Universe if it is free
<Xteven> no, the package I'm building contains a postinst script that configures a bunch of office printers in the building
<calc> Riddell: main
<Xteven> contacting canonical might be a bit overkill
<glatzor> Xteven: take a look at the packages: app-install-data und app-install-data-partner
<Xteven> ok, will do
<Xteven> thx :)
<glatzor> Xteven: basically you have to drop a desktop file to /usr/share/app-install and then run update-app-install in the postinst
<glatzor> Xteven: but this discussion belongs to ubuntu-users
 * Chipzz waves at Xteven :)
<Xteven> hi Chipzz
<Xteven> glatzor: running postinst is done at package installation, it doesn't put the package in the app-install listing before it is installed
<Xteven> kindof odd :)
<Chipzz> Xteven: you need a seperate package with the .desktop file in it
<Chipzz> which I guess creates a circular loop :P
<Xteven> if I understand correctly, the X-AppInstall-Package tag in a desktop file is somehow encoded into the repository information
<Chipzz> Xteven: afaui, it's not
<Chipzz> Xteven: gnome-app-install just looks at the files on the local system, nothing to do with a repository
<Chipzz> Xteven: dpkg -L app-install-data
<Xteven> so the list with installable applications (from gnome-app-install) is fixed ?
<Chipzz> not exactly
<Chipzz> it's just not determined from the repo, but from local information
<Chipzz> do dpkg -L app-install-data
<Chipzz> that has a lot of the desktop files that show up in gnome-app-install
<Xteven> hm
<Chipzz> Xteven: in your concrete case, I would make a kul-app-install package with some .desktop files in it
<Xteven> so there is no way to get my package in there, unless I hijack app-install-data or app-install-data-commercial
<Xteven> ok
<Chipzz> like I said, they don't have to be in *that* package
<Chipzz> Xteven: cfr /query ;)
<glatzor> Xteven: doing system configuring by using packages is not the best approach at all
<Xteven> what is the best approach ?
<glatzor> Xteven: depends on your environment
<Xteven> 100 computers spread out across the planet
<Chipzz> glatzor: pretty big university (> 20.000 students, probably > 30.000 by now)
<Chipzz> Xteven: I don't suppose you can force your users to install using a modified CD?
<Xteven> no
<slangasek> cjwatson: well, the output from change-override.py made me fearful that I'd kicked postfix to universe in dapper itself; I tried to set things back and now postfix in dapper-backports shows as being in universe, so I guess that's progress
<Chipzz> glatzor: so custom cd is not really a solution
<Xteven> no custom cd, no global policy stuff
<Chipzz> thinking more about this, I have another idea
<Chipzz> but I doubt if that's really feasable at all
<glatzor> Xteven: have you already thought about landscape?
<Xteven> nope, never even heard of it :)
<Xteven> I see
<Xteven> a central config system
<Chipzz> I was thinking more along the lines of ubuntu providing some infrastructure for extra packages which only show up on certain mirrors
<Chipzz> but that would be opening up a whole new can of worms
<Xteven> I don't want to maintain other people's desktops, I just want to make it easier for them to install 15 printers on their system
<Xteven> anyway, I have to go to class
<Xteven> thx for the help and cya later
<Chipzz> elmo: ping?
<glatzor> ScottK: the basic idea is to ship a fallback xorg.conf which does not contain any configured devices
<glatzor> ScottK: but that is in the end an evil hack.
<glatzor> ScottK: it is a pity, but xorg does not provide a way to get a configuration file from the currently used devices/settings
<ScottK> glatzor: Since displayconfig is pretty unmaintained at the moment, I'll take working evil hack over the theory of a pretty solution.
<Chipzz> glatzor: btw, there's another use-case for what Xteven just mentioned
<glatzor> ScottK: you should think about replacing it at all.
<ScottK> glatzor: Above my pay grade.  I just volunteer here.
<Chipzz> I know the situation a bit, since I went to the same college as Xteven is working at (was even a class-mate of Xteven ;))
<glatzor> ScottK: me too
<glatzor> :)
<Chipzz> glatzor: for example, at that college, you have to login to the network to be able to reach the internet at all (except for a few local sites, among which a debian/ubuntu mirror)
<tseliot> glatzor: did I miss something? Problems with Xorg?
<glatzor> ScottK: is there any work on a randr configuration tool for kde?
<ScottK> glatzor: I don't know.  Riddell would be the one to ask.
<Chipzz> people have already written scripts to do that login, but it would be really easy if someone made that into a package, and that package could be included on the local mirror, and in some *-app-install package, so users just have to click it to install
<Riddell> I don't know of any
<Riddell> glatzor: what's the gtk tool?
<ScottK> glatzor: I just hit a diplayconfig bug where it's crashing for me so I'm trying to round up any other easy fixes to go with that patch for after the alpha
<tseliot> glatzor: Gustavo Boiko (Mandriva) wrote a GUI to RandR in C++
<glatzor> Riddell: perhaps it would make sense to talk the fedora guys
<tseliot> glatzor: a GUI in QT
<ogra_cmpc> cjwatson: can you give me a hint ? i see the modes menu contents are defined in gfxboot.cfg, where does that come from ?
<glatzor> Riddell: they store monitor specific data in a xml file in the users home folder
<glatzor> tseliot: I left the xorg land, since I could not spend enough time to get the work done
<ogra_cmpc> i dont see it in gfxboot-themes-ubuntu and there is no trace for anything relating to it in the cd buildscripts
<cjwatson> ogra_cmpc: it's written by debian-cd
<cjwatson> tools/boot/hardy/boot-*
<ogra_cmpc> ah
<ogra_cmpc> thanks
<cjwatson> it was basically to avoid defining even more extensions in isolinux.cfg, which I realised caused errors to be spat out by isolinux itself
<ScottK> lamont (or any buildd admin) Would you please do a giveback on postfix in dapper-backports and edgy-backports?
<tseliot> glatzor: oh, sorry to read that :/
<cjwatson> though it so happened that you mostly never saw them
<ogra_cmpc> that whole gfxboot setup could need a diagram how the things play together
<cjwatson> yeah, sorry :-/
<ogra_cmpc> nah
<ogra_cmpc> that was not what i meant :)
<tseliot> Riddell: did you check KRandR?
<ogra_cmpc> looks like a good intrepid project, i want to get more familiar with all that stuff anyway :)
<Riddell> tseliot: I havn't looked into the issue at all
<tseliot> Riddell: here's the git repository (if you're interested):
<tseliot> http://git.mandriva.com/?p=projects/krandr.git
<cjwatson> ogra_cmpc: somebody other than me certainly should
<ogra_cmpc> yeah
<Riddell> tseliot: interesting but I've no idea how to actually get at the code :)
<Riddell> glatzor: what's the gtk xrandr tool?
<glatzor> Riddell: sorry, bryce blogged about it recently. It is developed by RedHat's SÃ¸ren Sandman
<glatzor> Riddell: it will integrate into gnome-settings-daemon
<twb> Is there an equivalent to qa.debian.org/developer.php for Ubuntu?
<glatzor> Riddell: But since libxrandr is very very low level it would make a lot of sense to share some code
<glatzor> Riddell: there is also some discussion about it on the gnome-cc list
<Riddell> twb: launchpad.net/people (much broader of course)
<bryce> Riddell: go to Screen Resolution in System > Preferences, or run gnome-display-settings from the command line
<bryce> Riddell: most of the interesting bits are in gnome-desktop
<twb> Riddell: well, I'm using it to compare the "health" of a bunch of packages.
<bryce> Riddell: xrandrwrap.c in particular.  I see it uses some gtkisms but think it could be generalized for kde
<Riddell> bryce: what needs apt-get installed?
<twb> It's more useful than packages.d.o / packages.u.c because it also shows the uscan results
<twb> And also because it tabulates a bunch of packages rather than just one at a time.
<bryce> Riddell: gnome-desktop, gnome-control-center, and gnome-settings-daemon
<Riddell> E: Couldn't find package gnome-desktop
<bryce> hmm, the binary is libgnome-desktop[-2|-dev]
<bryce> probably need gnome-desktop-data, although that may get pulled in automatically
<keescook> allo
<geser> Hi keescook
<Riddell> bryce: I have gnome-control-center gnome-settings-daemon and libgnome-desktop-2 installed but no signs of gnome-display-settings
<Riddell> bryce: ah, gnome-display-properties ?
<Riddell> ScottK, glatzor, tselio1: looks like there is a kde 4 randr tool "kcmshell4 randr"
<bryce> Riddell: ah sorry that's right
<Riddell> it doesn't work, but then neither does gnome-display-properties :)
<bryce> Riddell: got a screenshot?
<ScottK> Riddell: Interesting.  Did we happen to package that already?
<bryce> Riddell: you may want to doublecheck that gnome-settings-daemon is running
<tselio1> Riddell: thanks, I'll have a look at it
<tselio1> it looks like my URandR is the only one that works ;)
<Riddell> bryce: http://kubuntu.org/~jriddell/tmp/kde-randr.png
<Riddell> ScottK: yes, it's in kdebase-workspace-bin
<Riddell> bryce: yerk, starting that had some interesting delayed effects.  can't gnome start its own daemons?
<tselio1> Riddell: URandR -  http://albertomilone.com/wordpress/wp-content/uploads/2007/12/urandr1.png
<bryce> Riddell: I'm not the gnome guru.  ;-)  But I did notice the daemon doesn't start up at install time, but it does on reboot.
<Riddell> I spot potential for windows 95 jokes :)
<tselio1> bryce: did you have a look at EnvyNG? mvo won't approve it unless he hears your opinion on this
<tselio1> bryce: my bzr branch is http://bazaar.launchpad.net/~albertomilone/envy/envyng
<bryce> tselio1: ok I'll take a look
<tselio1> thanks
<jdstrand> hi slangasek!
<slangasek> jdstrand: moo
<jdstrand> slangasek: do you remember that odd libtool issue with the gutsy openldp testing suite?
<jdstrand> slangasek: did anything come of that?
<jdstrand> I have in my notes:
<jdstrand>  < slangasek> jdstrand: ok, from what I see, openldap is assuming a
<jdstrand> libltdl that uses RTLD_GLOBAL; that's a bug in libltdl upstream that's fixed in
<jdstrand> the Debian/Ubuntu package (using RTLD_GLOBAL causes namespace collisions in the
<jdstrand> general case), so openldap's modules need to be fixed to not rely on this
<slangasek> jdstrand: yes, upstream is fixing it; I think it's supposed to be fixed in 2.4.8 which I'm having a look at in the next couple of days
<slangasek> basically, back_meta was relying on back_ldap in ways that it wasn't supposed to according to upstream's own policies
<slangasek> so that's good, for once I needn't argue with them :)
<jdstrand> slangasek: ok-- no rush, just curious.  (I hit this with a security update)
<jdstrand> heheh-- that is good news indeed
<jdstrand> slangasek: I might mention that test030-relay was also failing (the other two were test035-meta and test036-meta-concurrency)
<jdstrand> I haven't looked into test030-relay to see if it uses back_meta...
<slangasek> deos test030-relay use back_meta?
<slangasek> ok :)
<jdstrand> :)
<jdstrand> slangasek: looks like it does, so no problems
<slangasek> lamont: eew, since when is nsis i386/amd64 only? :P
<slangasek> lamont: that's not right at all - mingw32 is built on all archs, so nsis should be as well
<lamont> slangasek: maintainer requested
<lamont> no maintainer support for anything other than i386/amd64.  including no support on kfreebsd-* :)
<slangasek> lamont: but the maintainer's off his nut :-P
<lamont> slangasek: well, that may well be.
<lamont> just look at the package. :)
<lamont> if it's a bad thing, we could just leave it blowing up on all the architectures...
 * lamont is happy to revert it if that will make slangasek happier.
<slangasek> lamont: well, it /doesn't/ blow up - the most recent version built on mipsel at the very least
<lamont> <pabs> I'd rather not have to deal with any other arches, since this isn't very portable software
<slangasek> it was portable enough before
<slangasek> and at least in Debian, the maintainer doesn't have veto there... :)
<ogra_cmpc> and in ubuntu we dont have maintainers :P
<ogra_cmpc> only teams
<nixternal> slangasek: can I get a give back on kpovmodeler-kde4 and rsibreak-kde4 please? they were uploaded with the kde4 packages earlier prior to libplasma being ready for their deps..thanks
<slangasek> nixternal: I'm not a buildd admin
<nixternal> hrmm, Riddell next? :p
<Riddell> hmm, for some reason I thought you were
<Riddell> nixternal: this lot https://edge.launchpad.net/~launchpad-buildd-admins/+members
<nixternal> groovy, hey pitti ol' buddy ol' pal :)  Can I get a give back on kpovmodeler-kde4 and rsibreak-kde4 please?
<nixternal> no rush, as kdebase-workspace is still pending on sparc anyways
<cjwatson> ogra_cmpc: however, we share Packages-arch-specific with Debian
<pitti> nixternal: hi! given-back
<ogra_cmpc> pitti: how about making apport submit system language info as well ... for non english bug reports that could be quite helpful i imagine
<ogra_cmpc> (not for hardy, just a general idea)
<pitti> ogra_cmpc: how do you define 'system language'?
<ogra_cmpc> $LANG
<ogra_cmpc> or something similar
<ogra_cmpc> $LANGUAGE
<ogra_cmpc> would make guessing the right translation variant easier ...
<pitti> ogra_cmpc: but it's already doing that?
<pitti> ogra_cmpc: ProcEnviron: field
<nixternal> pitti: thanks!
<ogra_cmpc> pitti: well, look at bug #181462
<ubotu> Launchpad bug 181462 in ubuntu "scheda video trident" [Undecided,Incomplete] https://launchpad.net/bugs/181462
<pitti> ogra_cmpc: oh, I see; right, recent regression, I don't add the Proc* stuff for bug reports by default any more, just for crashes
<ogra_cmpc> ah
<pitti> ogra_cmpc: the idea was to filter out the fields with more personal data
<ogra_cmpc> understood
<pitti> but the latest version has a much better approach for that
<pitti> ogra_cmpc: can yuo please file a bug for me?
<ogra_cmpc> but i think that info makes perfect sense
<pitti> ogra_cmpc: no problem to re-add it
<ogra_cmpc> will do
<pitti> agreed
<pitti> removing ProcEnviron: wasn't really intended
<pitti> for bugs I'm more concerned about exposing the command line, etc.
<ogra_cmpc> (we could integrate google translate automatin via LP with that ;) )
<pitti> ogra_cmpc: danke
<ogra_cmpc> "click here to get the english version of the bug" :)
<laga> .oO(.. "kein weltraum links vom gerÃ¤t" -> "no space to the left of the device" -> "no space left on the device" ..)
<ogra_cmpc> heh
<ogra_cmpc> i think google improved a lot such translation errors are rather rare
<laga> ogra_cmpc: they've recently switched to a new translation engine based on statistics
<ogra_cmpc> ah
<pitti> laga: *chuckle*
<laga> i'm not sure how well that works, but i think there's a link now to tell them if something's broken
<ogra_cmpc> the occurences where i needed google trans. it worked impressinlgy well
 * laga wonders how to tell from /sys/block/ whether a device is a hard disk or a CD-ROM drive
<mjg59> laga: Check whether bit 3 of capability is set
<mjg59> laga: See include/linux/genhd.h
<laga> thanks
<ogra_cmpc> laga: the ltspfs cdpinger script has a good python implementation of the capability check
<laga> python. exactly what i need.
<ogra_cmpc> pitti: bug #198514 for you ...
<ubotu> Launchpad bug 198514 in apport "please enable  ProcEnviron in apport reports" [Undecided,New] https://launchpad.net/bugs/198514
<seb128> StevenK: could you have a look at the sponsor request for the new gimp version today?
<pitti> ogra_cmpc: thanks, assigned
<james_w> bryce: hi. I suspect https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/193560 is another xrandr/g-s-d bug. It has the helpful error "parse error".
<ubotu> Launchpad bug 193560 in gnome-settings-daemon "[Hardy] gnome-settings-daemon not logged in when started" [Undecided,Confirmed]
<ScottK> doko: I would appreciate your input on what we can/should do to resolved Bug 185418.
<ubotu> Launchpad bug 185418 in zope3 "reports its version number in .egg-info as 0.0.0" [Undecided,New] https://launchpad.net/bugs/185418
<mario_limonciell> bdmurray, ping
<hunger> Is it no longer possible to do a CLI only install in hardy?
<cjwatson> it certainly should be
<cjwatson> should be on the F4 menu on the alternate install CD
<bdmurray> mario_limonciell: howdy
<cjwatson> hunger: ^--
<mario_limonciell> hiya bdmurray.  in some debugging endeavors, i didn't find a lot of valuable prefabbed information on kdump.  I threw together a script that you guys might find useful to provide for triaging if you're interested
<mario_limonciell> bdmurray, http://paste.ubuntu.com/5285/
<hunger> cjwatson: Yeap, but I have real trouble installing a system without libx11.
<tjaalton> james_w: can't be a dupe, since the changes were uploaded later than the bug was reported
<cjwatson> hunger: libx11-6 is not in the console-only install in Hardy
<hunger> cjwatson: And I have only ubuntu-minimal and a couple of console apps.
<cjwatson> hunger: perhaps you are confusing it with x11-common, which is present due to console-setup
<cjwatson> and, frankly, isn't something I'm concerned about
<james_w> tjaalton: sorry, can't be a dupe of what?
<cjwatson> sorry, I mean xkb-data, not x11-common - x11-common isn't needed in minimal any more
<hunger> cjwatson: I'm upgrading from gutsy and that insists on libx11 due to console-kit due to dbus due to hal AFAICT.
<tjaalton> james_w: of the gsd/xrandr bug
<hunger> Dunno whether I can get rid of hal later on.
<cjwatson> hunger: it's not part of a from-scratch hardy console install, that's all I can say. Be precise in your complaints!
<cjwatson> and libx11 does not imply an X server, anyway, which is the real heavyweight thing
<james_w> tjaalton: I realise that, I was just trying to give a heads up that it is another issue in the same area, as it may still be being worked on.
<hunger> cjwatson: I'm updating a gutsy without libx11 and aptitude insists that libx11 is now required.
<cjwatson> ah, hmm, perhaps there is something wrong with my apt cache
<cjwatson> it's hardly a big deal, anyway. Like I say, libx11 doesn't pull in an X server.
<hunger> cjwatson: Maybe some of my used-to-be-console only picked up some depends on X11 or something. I'll investigate after the upgrade.
<bdmurray> mario_limonciell: thanks, I'm a bit swamped but will look at it later today
<mario_limonciell> bdmurray, great.  hopefully it turns out to be helpful, it's been working great for me to catch some stuff :)
<slangasek> cjwatson: <cough> nope, it just pulls in /usr/bin/X...
<slangasek> which isn't an X server, just an suid-root wrapper
<cjwatson> libx11-6 doesn't appear in seed expansions until you get as far out as desktop-common
<Chipzz> there is ofcourse the pull-10-instead-of-one-brown-paperbags-over-my-head bug in libxpm
<Chipzz> where the -nox version, despite its name, does depend on x11
<Chipzz> :P
 * ScottK head desk.
<ScottK> slangasek: My apologies for messing up the freeze.  I just uploaded to the main repo instead of my PPA.
<ScottK> slangasek: It's kdeguidance.
 * ScottK goes to make a revision that reverts all that.
<slangasek> heh
<Chipzz> cjwatson: I wouldn't call it "hardly an issue" though
<Chipzz> the presence of that library on a shell-server enables users to upload binaries linked against it, and run them
<Chipzz> (which I guess could also be done if statically compile the app in question)
<Amaranth> Jyaku: Are you a bot?
<Jyaku> Amaranth: You are the sun shine we4ll shine together told you i4ll always be your friend.
<Amaranth> *cough*
<Amaranth> Just to warn you guys, Jyaku is a log bot from this annoying website we're trying to get rid of
<Amaranth> But I don't have access in here :)
<laga> who's "we"? i thought someone approved them for the ubuntu namespace
<mneptok> that will be quite enough of that
<ScottK> slangasek: New kdeguidance uploaded that except for an embarrasing debian/changelog entry is the same as the old one.
<Amaranth> laga: Not those ones
<Amaranth> laga: This is a new one who is hostile in emails about the situation, evading bans, and locking out the status of where the bots are on their website
<laga> Amaranth: ah, even worse than the old one
<Amaranth> it grabs links and reports who said then and when
<laga> ah. quite close to spammers then
<TheMuso> ScottK: woops. :p
<ScottK> TheMuso: Yep.
<crimsun_> \sh_away: RE 144356, someone needs to chase libflashsupport
<cjwatson> Chipzz: for that last reason, I think "hardly an issue" is entirely fair. The presence of libx11-6 doesn't give any extra privileges anyway.
<Chipzz> cjwatson: I tend to disagree. newbies can RTFM and type ./configure ; make ; make install and scp, but to link something statically requires more intimate knowledge
<cjwatson> Chipzz: if it doesn't grant extra privileges, it's not a problem
<cjwatson> I stand by my claim
<Chipzz> I have seen this on servers, so it's a real problem. But lets agree to disagree :)
<cjwatson> I have seen people typing 'cat' on servers too, but that's not a problem either
<cjwatson> no extra privilege
<Chipzz> the problem is the resources x apps tend to consume
<cjwatson> use resource limiting if that bothers you
<wasabi> latest update today has caused gnome-settings daemon to not start, and then gnome-session to close. just in the problem is more than me. :0
<wasabi> don't suppose one of you broke it? eh eh eh?
<Chipzz> ok, you got a point there I guess
<wasabi> SIGSEGV in rw_screen_list_outputs().  fun!
<james_w> wasabi: the latest upload of gnome-desktop may fix this. If not then a new upload of g-s will hopefully do so. (or was it g-settings-daemon?)
<wasabi> ahh well, as long as it's well known
<wasabi> how'd it happen in a feature freeze?
<cjwatson> bryce's xrandr gui work was granted an explicit exception
<wasabi> "oops!"
<cjwatson> exceptions always come with risks
<cjwatson> I don't regard it as an oops
<wasabi> Me neither. I am just being sarcastic.
<wasabi> I have no problems or complaints.
<wasabi> Oh hey. Kick ass. This GUI thing is *awesome*
<wasabi> This crash has made me aware of it.
<wasabi> bryce: crazy suggestion. You draw boxes for each screen. Within the box you put the name of the display device. Within each box put the name of all display devices which receive a copy of the screen. Including clones. </random feature request>
<wasabi> and allow dnd of the device outside of the screen either onto the surface itself to create another screen, or within an existing screen.
<wasabi> Maybe use icons within the boxes instead of the device names themselves. So you can drag a projector from one screen to another to duplicate it's output.
<wasabi> Or maybe an icon view of devices lined up, and you acn drag those onto the surface
<doko> ScottK: a separate package should work, yes
#ubuntu-devel 2008-03-05
<Hobbsee> slangasek: what do you want with bugs that are a "please test if this is fixed in the next alpha"?
 * Hobbsee milestones, assigns to her, etc
<TheMuso> c
<superm1> if any archive admins are about, can you see why https://edge.launchpad.net/ubuntu/+source/mythtv/0.21.0~fixes16338-0ubuntu3/+build/530056 hasn't hit the archive yet?  It built like 8 hours ago.
<superm1> and its not in NEW
<nosredna_ekim> jcastro: ping.
<slangasek> Hobbsee: hmm, not sure what you mean; is the bug a serious one that needs milestoned in the first place, is the bug marked as 'fix released'...?
<Hobbsee> slangasek: it's a "i could reproduce this originally, and it's not good for the final release if it's reproducable - it needs testing during our testing for t6
 * Hobbsee can't seem to reproduce it now
<slangasek> ok; probably nominating/targetting it for hardy would be best I think
<Hobbsee> mhmm.  with the rest of them, that people say "affects hardy.  we hope it gets fixed sometime, but we have no fix in sight" ones
<Hobbsee> (that's why i don't use affecting hardy
<Hobbsee> )
<superm1> slangasek, would you mind checking why a build from about 8 hours didn't publish yet?
<Hobbsee> superm1: is probably soyuz bug :)
<slangasek> Hobbsee: well, I mean for the bugs that are targetted for hardy to actually be fixed for hardy in accordance with their severities :)
<slangasek> superm1: sure, what do you have?
<superm1> https://edge.launchpad.net/ubuntu/+source/mythtv/0.21.0~fixes16338-0ubuntu3/+build/530056
<Hobbsee> slangasek: that's not what the others tend to use it for, but yeah
<superm1> Hobbsee, now lets not be pessimistic or anything...
<Hobbsee> oh damn, i didn't bring my laptop
 * Hobbsee could have rsynced.
<Hobbsee> superm1: of course not.  just aware of the way soyuz likes to work.
<Hobbsee> superm1: it's either in the new queue, or its' a bug, and soyuz has gotten hungry again.
<superm1> its not in the new queue
<superm1> nothing has changed with it that would have put it there, and i looked there a little bit ago to make sure
<superm1> see and i dont even talk bad about soyuz, why would it want to eat my builds?
<superm1> if anything it should eat yours :)
<Hobbsee> hah
 * Hobbsee looks, blinks
<Hobbsee> superm1: erm.  what makes you think it's not published?
<slangasek> superm1: https://edge.launchpad.net/ubuntu/hardy/+source/mythtv/0.21.0~fixes16338-0ubuntu3/ shows it as 'done', yeah
<superm1> Hobbsee, it hasn't shown up on archive.ubuntu.com or packages.ubuntu.com
<slangasek> and drescher agrees that it's there...
<Hobbsee> http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/
 * Hobbsee points at mythtv-backends
<superm1> look at mythtv-common
<Hobbsee> http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/mythtv-backend_0.21.0~fixes16338-0ubuntu3_amd64.deb
<superm1> in archive.ubuntu.com
<superm1> its missing
<Hobbsee> oh, hmm
<Hobbsee> so, some of the binaries are there
<superm1> along with the rest of i386
<Hobbsee> superm1: mythtv-common is arch: all?
<superm1> yeah
<Hobbsee> i thought it might be
<Hobbsee> superm1: it' ssitting on launchpad i fyou awnt to grab it from there
<Hobbsee> but, uh, i suspect that's a soyuz bug :)
<superm1> Hobbsee, its not a big deal for myself, but when the alternate disks go to build in 3 or 4 hours, they aren't going to like it
<slangasek> the CD builds pull directly from drescher, though
<slangasek> so if there's an issue preventing it from being visible for archive.ubuntu.com, that won't affect the CD builds anyway
<Hobbsee> superm1: i think you'll need to poke cprov over that, and he doesnt' appear to be around.
<slangasek> mythtv-common | 0.21.0~fixes16338-0ubuntu3 | hardy/multiverse | all
<slangasek> that's the one you're looking for?
<Hobbsee> yes
<superm1> well if the cd builds right from drescher not a big deal
<superm1> that's the only thing that really matters to  get it in "tonight"
<superm1> i'll wait for cprov tomorrow then for fixing it on a.u.c and p.u.c
<superm1> yup
<Hobbsee> hmm.  i need noise cancelling earphones, or to kick these giggling girls out of the lab.
<StevenK> Heh
<Hobbsee> and then people complain about not that many females in IT.  Well, if they act like that, then no...
<Hobbsee> There's a shopping centre ~10 mins away.  go there!
<TheMuso> Aw
<StevenK> Aw?
<TheMuso> StevenK: supposed to be /aw
<TheMuso> _MIf you have the ubuntustudio splah installed, you may also have to remove that.
<TheMuso> gah wrong channel
<bryce> wasabi: glad you like the gui - were my bug fix updates from today enough to get things sorted?
<slangasek> superm1: yah, it doesn't build "right" from drescher, but the CD build servers all mirror directly from drescher
<bryce> wasabi: thanks, I've noted the feature requests.  Perhaps a hardy+1/+2 type thing
<bryce> wasabi: if you're ever interested in doing some cairo/gtk hacking, I'd be happy to point you at the code (it's not terribly complex) and explain it
 * Hobbsee smashes wget against a brick wall
<pitti> Good morning
 * slangasek waves
<cody-somerville> Heya pitti
<slangasek> ogra_: artwork> which package does this refer to, precisely?
<ogra_> ogra@ceron:~/devel/packages/gfxboot-theme-ubuntu-0.5.3$ dpkg -S /usr/share/backgrounds/simple-ubuntu.png
<ogra_> ubuntu-wallpapers: /usr/share/backgrounds/simple-ubuntu.png
<ogra_> wallpapers ...
<ogra_> but i suspect other artwork packages might have grown as well ...
<TheMuso> slangasek: I would need to check, but all the sounds for the sound scheme are at 44100Hz, 16 bit Stereo. At the least, I could resample them to 22050, and for a sound scheme, that wouldn't impact on their quality much for general use anyway.
<TheMuso> slangasek: So, ubuntu-sounds being 2.3 currently, could be taken down to about 1.5/1.6 probably...
<slangasek> ogra_: yes, could be.  ubuntu-wallpapers hasn't changed since alpha-5, so it doesn't account for the size increase - but of course if we can slim it back down again, that would be welcome all the same
<ogra_> TheMuso, do we still use .wav files ?
<TheMuso> ogra_: We do indeed, and thats all we can use, due to the audiofile library being used.
<TheMuso> afaik
<ogra_> slangasek, well, 3.5M is quite heavy for a wallpaper imho
<ogra_> TheMuso, hrm ... we should really look into switching to ogg
<TheMuso> ogra_: files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun, BICS, and raw data).
<ogra_> to gain some compression
<TheMuso> ogra_: Willing to massively edit either the audiofile library, or GNOME code proper?
<ogra_> TheMuso, lest talk about that after hardy is out :) i cant oredict my workload for interpid yet since so much changed in edubuntu land
<TheMuso> ogra_: Something like that needs doing upstrea.
<asac> TheMuso: how do i test the scim thing?
<TheMuso> ogra_: I'm just saying its a lot of work.
<ogra_> right, i'm aware :)
<TheMuso> asac: I can't remember without looking it up./
<slangasek> rather unfortunate that GNOME has this lovely gstreamer framework, but system sounds can only be .wav files :-P
<ogra_> asac, open the scim gui, select de nodeadkeys, re-login is what i did
<TheMuso> slangasek: Indeed.
<TheMuso> slangasek: But it is an option, and I can do it if 1.3 or so MB is that critical.
<ogra_> slangasek, there was a patch floating around that made the systeem sounds use gstreamer as well i think it was abandoned :(
<slangasek> TheMuso: let me see what happens after the latest round of liveCD builds, and after I try to fix python2.5+db4.6 so we can kick db4.2 back off, and I'll see where we are; making changes to the fundamentals of GNOME sound handling is not a useful fix for alpha-6, and I'd rather not have to short us on sound quality either
 * cjwatson trims 50KB off the CD boot menu; every little helps
<TheMuso> slangasek: Ok fair enough.
 * TheMuso should really do a new scheme one day...
<slangasek> one place where I know we ought to be trimming for sure is the fact that we now have two distinct gtk2 engines being pulled in by human-theme on the Ubuntu CD
<slangasek> but I'm not sure which one needs to be gotten rid of yet
<cjwatson> slangasek: Ken didn't reply last night, I take it?
<Amaranth> slangasek: Wasn't clearlooks already on the CD?
<ogra__> it should be dropped if that is the case
<ogra__> we default to murrine now
<slangasek> cjwatson: nope, hoping he's a fairly early riser :)
<slangasek> Amaranth: this is gtk2-engines-murrine vs. gtk2-engines-ubuntulooks
<Amaranth> slangasek: oh, in that case i thought ubuntulooks was being dropped
<slangasek> ogra__: so -ubuntulooks isn't used and can be dropped without ill effect?
<Amaranth> that was the point of redoing the themes using clearlooks and murrine
<slangasek> Amaranth: makes sense, I just have no clue whether we're at the point where -ubuntulooks is ready to be dropped, do you?
<cjwatson> -ubuntulooks is only 40KB though?
<ogra__> slangasek, well, my installs all use murrine by default here, not sure kwwii wants to ship a fallback with Human, that would require clearlooks indeed
<cjwatson> pulls in a bunch of libraries, but I assume most of those are used by something else
<Amaranth> slangasek: Well, I'd say no, the other two themes...need some work
<slangasek> cjwatson: ah, argh
<slangasek> cjwatson: alright, moving that to the "every little bit counts" pile
<ogra__> heh
<slangasek> cjwatson: yes, all the libs it pulls in are already there
<slangasek> Amaranth: umm... are they "not happening for hardy" need some work, or "needs to get done by hardy" need some work?
<Amaranth> I suspect the latter
<Amaranth> Probably just need someone to spend a day with them polishing
<slangasek> whichever side they fall on, we should cut the other end off as long as it still leaves us with a functional desktop :-)
<Amaranth> they work fine, they just need some tweaking (tooltips aren't themed properly, etc)
<ogra__> hmm, using pngcrush on the wallpaper actually gains zero ... thats really strange
<Amaranth> ogra__: someone crushed it already?
<ogra__> Amaranth, but its stil 3.5M
<Amaranth> well, pngcrush just removes metadata
<ogra__> it makes my classmate desktop unresponsive while it loads
<Amaranth> it doesn't compress the image more or anything
<ogra__> oh, i thought it does
<Amaranth> oh, i guess it does
<slangasek> 703M	daily-live/20080305/hardy-desktop-amd64.iso
<slangasek> 705M	daily-live/20080305/hardy-desktop-i386.iso
<slangasek> hnngh
<Amaranth> i was thinking of another tool
<Amaranth> slangasek: drop gthumb ;)
<slangasek> Amaranth: in favor of?
<ogra__> slangasek, amd64 alternate is fine ... lets just resort to that one :P
<Amaranth> slangasek: well, we have fspot already
<ogra__> slangasek, we have f-spot in the default install
<Amaranth> but this debate has gone on for like 3 releases now
<superm1> slangasek, unfortunately it still used the wrong packages for this build.  guess we'll have to wait until tomorrow for more luck :(
<ogra__> but people will complain if you drom gthumb
<ogra__> *drop
<pitti> didn't we already drop gthumb?
<cjwatson> can we not have the applications debate *again*
<pitti> yes, we did; it even wants to go to universe, needs seeding
<slangasek> pitti: yes
<Amaranth> oh, yay
<Amaranth> but oh, still need rom
<Amaranth> room*
 * Amaranth uninstalls gthumb
<slangasek> superm1: mmm, odd
 * pitti wonders what used up some 80 MB since alpha-4
<Amaranth> yeah, i thought alpha 4 was way under the limit
<Amaranth> i can't think of anything that got added though
<pitti> some 650 MB including some langpacks, yes
<slangasek> the manifest diff between alpha-5 and alpha-6 is short enough, but looking through for which packages have grown would take some doing
<Amaranth> are those langpacks still on the disc?
<pitti> slangasek: for the alternates we could flip some large packages to lzma
<slangasek> and none of the alpha-4 metadata is still around, sigh
<Amaranth> maybe just drop them again for now?
<pitti> Amaranth: we did
<Amaranth> oh, i missed that bit
<pitti> Amaranth: that's where the other ~ 30 MB from my estimation (80 MB) come from
<Amaranth> stupid splits :P
<slangasek> pitti: alternates don't concern me nearly as much; as soon as OOo-l10n lands, I understand we'll already have more space there
<pitti> ah, right, lzma FTW
<ogra__> is there a howto anywhere for switching packages to lzma ?
 * ogra__ would like to see how gcompris would behave with that
<cjwatson> it ought to be possible to take the manifest diff and feed it to something that downloads all the old packages from the librarian and compares sizes
<cjwatson> might want to do that inside the DC, of course
<slangasek> ogra__: dh_builddeb -- -Zlzma; but calc already did the archive analysis on which packages benefit most, I think
<ogra__> slangasek, ah, thanks
<cjwatson> ogra__: dh_builddeb -- -Zlzma, pre-depends: dpkg (>= 1.14.12ubuntu3)
<ogra__> well, gcompris is 60M source :)
<ogra__> it should gain *something*
<slangasek> ogra__: there's a space/performance trade-off with lzma; the focus is (and IMHO should be) on deploying it first in the packages with the largest footprint
<slangasek> hrm
<ogra__> gcompris is my largest package in edu land ...
<slangasek> bloody hell, I was looking at the ship seed before, not the live CD; live still has a number of langpacks that can be unseeded if necessary :/
<ogra__> the binaries take about 80M or so ... i dont have space constraints on the addon CD atm though
<cjwatson> slangasek: it may be that calc only looked at the Ubuntu CDs
<slangasek> cjwatson: oh, possible, yes
<fabbione> Spads, Ng: ping?
<fabbione> oh wrong channel
<tjaalton> where's openoffice.org-common for 2.4.0rc2?
<tjaalton> slangasek: mind if I upload oo.org-voikko for a rebuild?
<slangasek> tjaalton: go ahead, please
<tjaalton> slangasek: thanks
<slangasek> openoffice.org-common> what do you mean? I see it in the archive where it should be?
<tjaalton> slangasek: ok, maybe archive problems again? it's not on a.u.c
<slangasek> yes, superm1 was mentioning mythtv wasn't making it to a.u.c either
<pitti> OO.o not installable on amd64 for me either
<emgent> morning
<tjaalton> slangasek: hmm, there's also voikko 2.2-1 in unstable, which seems to add some additional support for OO.o 2.4. maybe sync that?
<tjaalton> not too many changes
<slangasek> are you asking me to sync it, or are you asking my opinion on whether a sync is appropriate?: )
<tjaalton> well, both :)
<tjaalton> slangasek: I'll try a pbuilder run first
<slangasek> "Sorry, Gestor de actualizaciones closed unexpectedly"
 * slangasek twitch
<cjwatson> slangasek: BTW, while live filesystems do build straight from drescher, the archive mirror on antimony comes from syncproxy
<cjwatson> slangasek: and it looks like that's out of date
<tjaalton> "Cannot install 'openoffice.org-dev'E: pbuilder-satisfydepends failed."
<tjaalton> so much for trying pbuilder
<cjwatson> I was expecting partman-ext3 49ubuntu2 to be there, which is timestamped 22:05 last night on drescher, but it isn't
<cjwatson> slangasek: have you poked IS about it yet?
<slangasek> cjwatson: ah, I hadn't poked, no
<seb128> pitti, slangasek: any opinion if we should switch evolution-data-server to use gnome-keyring in hardy? Currently passwords are stored in the user directory, keyring would be better but there is no migration which means users would have to re-enter their password on upgrade
<stgraber> Riddell: around ?
<pitti> seb128: I'm all for consolidating to gnome-keyring
<pitti> seb128: it's much easier to do backups, put keys on USB stick, etc.
<seb128> pitti: do you think having to re-enter the passwords is an issue we need to fix though?
<pitti> seb128: hm, wrt. bug 196962, do you remember the decision about rb vs. sj for audio CDs?
<ubotu> Launchpad bug 196962 in gnome-volume-manager "Audio CD launches both Rhythmbox and Sound Juicer" [Undecided,New] https://launchpad.net/bugs/196962
<seb128> pitti: launch rhythmbox
<pitti> seb128: if we could fix that, the evo keyring would be badly protected :)
<pitti> seb128: but it's just entering your password once for the hardy upgrade, right? that seems bearable to me
<pitti> seb128: rb> ok, fixing in gvm then
<seb128> pitti: well, evolution passwords are not protected right now, evolution could read those and store them in the keyring if they are not there
<seb128> pitti: yes
<pitti> oh, one more reason to do that switch
<pitti> seb128: so, IMHO it's  worth an upstream bug report to do that transition, but if it won't happen, I don't think that it bites too much
<seb128> pitti: I though we stopped using gvm for mounting?
<pitti> seb128: I'd like to see the evo keyring cleaned on upgrade, though
<seb128> pitti: I talked to upstream about it, they will likely do something but maybe not before hardy
<seb128> pitti: right
<pitti> seb128: gvm> it still handles scanners, printers, and the like
<pitti> and cameras
<seb128> pitti: right, but audio CD should be nautilus
<pitti> I agree
<pitti> just wanted to confirm with you
 * pitti hugs seb128
 * seb128 hugs pitti
<pitti> seb128: btw, we already have the first complaints about that :)
<slangasek> seb128: I'm never happy when users (particularly those named Steve) have to reenter information after upgrades.  Is gnome-keyring already supported by e-d-s upstream as an option, and is there any prospect of migration support in the future?
<seb128> pitti: I'm not sure what you are fixing in gvm for rb then?
<seb128> pitti: about what?
<pitti> seb128: complaint> bug 198505
<ubotu> Launchpad bug 198505 in gnome-volume-manager "gnome-volume-manager does not mount devices any more in hardy" [Undecided,Won't fix] https://launchpad.net/bugs/198505
<pitti> seb128: apparently gvm still launches sj
<pitti> so I'll make it not do that
<seb128> alright
<seb128> thanks
<seb128> slangasek: what I wrote to pitti before, keyring is supported and other distros use it now, there is no migration code but upstream agree that would be nice to do, somebody needs to write this code though
<slangasek> mm right
<slangasek> well, I take the view that if it wasn't hurting users before now to have the passwords outside of gnome-keyring, leaving them there until a migration path is available is not a big deal and I'd rather have the user experience right
<seb128> I tend to agree with that
<slangasek> what's the likelihood the upstream bits would be ready in time for the hardy point release?
<seb128> I would like to use the keyring though, I'll try to get somebody upstream helping getting that migration code before hardy beta
<seb128> are daily cd images mirrored? cdimage.ubuntu.com is slow today
<slangasek> there are no mirrors of dailies, no
<seb128> ok, thanks
<seb128> slangasek: and for milestones?
<slangasek> alphas, also no
<seb128> ok
<cjwatson> I have a really impressive metacity bug here; the window switcher (i.e. the pop-up when you use C-A-<cursor> to move between workspaces) has got stuck on, and won't (a) go away or (b) let me move out of the first row of workspaces
<cjwatson> I'm going to have to kill my X session once various stuff has finished running, but is there anything I can do in the meantime to diagnose this?
<cjwatson> it started while some pretty heavy disk I/O was going on
<seb128> are other window manager things, moving, switching between tasks, etc still working?
<seb128> cjwatson: why do you need to restart the session? restarting the wm should be enough no?
<cjwatson> I can move between workspaces, but not Alt-Tab, and the window switcher has keyboard focus so I can't do anything useful
<cjwatson> restarting the window manager would probably be enough, true
<seb128> no idea on what debug information would be useful
<seb128> it doesn't seem to be stucked so a backtrace would likely be of no use
<seb128> the most useful information would be a way to trigger the bug
<seb128> I would say you can just restart it
<cjwatson> yeah, I've never seen it before - if I see it again I'll try to find common features
<ogra_cmpc> cjwatson, i had some similar things with my alt key the last days ... not actually metacity i guess but similar
<huats> moring seb128
<ogra_cmpc> like if i click on a window i can only move it (like with a stuck altkey)
<seb128> hi huats
<seb128> ogra_cmpc: there is a linux or xorg bug about key events being continuously generated sometimes
<cjwatson> ogra_cmpc: I don't think it's that; setxkbmap normally clears that kind of thing for me and doesn't help in this case
<ogra_cmpc> it didnt for me
<ogra_cmpc> and given that it happened on the classmate it verz likely happened under heavy disk IO
<ogra_cmpc> *very
<cjwatson> stracing metacity from a console says it's very busy, constantly reading/writing
<cjwatson> it could well be a stuck key event
<ogra_cmpc> thats what i mean
<seb128> cjwatson: xev?
<ogra_cmpc> i had that happening before always related to the alt key
<cjwatson> seb128: how do I get metacity's windowid from a console?
<cjwatson> ah, xwininfo
<seb128> I was going to suggest xprop but that should do it too
<cjwatson> hm, xev isn't saying anything
<Amaranth> cjwatson: there are some bugs reported against xorg about keys getting stuck
<Amaranth> mostly page down and such but i suppose alt could get stuck too
<Amaranth> bug 194214
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Medium,Confirmed] https://launchpad.net/bugs/194214
<Fujitsu> I often get Tab, and something that doesn't seem to be real, stuck.
<ogra_cmpc> i've had that in feisty and gutsy happening as well at least once every release cycle
<Fujitsu> Amaranth: There's another very similar to that.
<ogra_cmpc> and it always seemed related to IO
<Amaranth> ogra_cmpc: i believe the original reporter was scrolling in firefox when it happened, dunno if that'd hit the disk or not
<Amaranth> certainly spikes your CPU
<ogra_cmpc> indeed
<Fujitsu> That fits with my tab key getting stuck, it was during 100% load.
<ogra_cmpc> i only have it happening on special key combos (alt+tab etc) and if there is actually lots of disk IO
<Fujitsu> (CPU load)
<ogra_cmpc> havent seen it in normal browser operation or so
<RAOF> ogra_cmpc: I'm not sure that it's related to CPU load; it also seems to correlate with mouse activity.
<ogra_cmpc> might be
<ogra_cmpc> it usually went away with the next kernel upgrade for me ...
<Fujitsu> RAOF: Not for me.
<cjwatson> disk I/O> I was doing 'dd if=/dev/zero of=alt.img bs=1024 count=$((3*1024*1024))' and simultaneously rsyncing a CD image
<cjwatson> probably not massive CPU load involved
<ogra_cmpc> the prob its that it occurs so randomly that you cant even reliably reproduce it
<RAOF> ogra_cmpc: *I* can.  It's nice and easy to reproduce.
<ogra_cmpc> ah
<RAOF> Hold down a key, scroll madly in firefox.
<RAOF> Tada!  Key is stuck down.
<pwnguin> ive been having problems where enter gets stuck for a moment
<cjwatson> pwnguin: yes, also that
<pwnguin> esp if i run something like apt-get upgrade
<RAOF> Also works in WoW, but you don't need to scroll madly.
<cjwatson> iwj conjectured that it might have something to do with the fact that my CPU is hyperthreaded
<cjwatson> or at least might be easier to reproduce given that
<pwnguin> mine's dual core
<pwnguin> all mine are
<ogra_cmpc> well, mine isnt,  neither here on the classmate nor on the laptop where i saw the issue in other releases
<RAOF> *Definitely* not firefox related.  Hold down 'a', scroll madly in gedit.  'a' is no stuck down.
<RAOF> s/no/now/
<RAOF> Also probably not CPU load related, my laptop's not doing _too_ much.  One core is ~50%, the other is idle.
<ogra_cmpc> whats the load average at ?
<dbmoodb> hi is there a social contract for ubuntu like debians ?
<cjwatson> bug 124406 has a massive pile of key repeat reports
<ogra_cmpc> dbmoodb, search for "code of conduct"
<ubotu> Launchpad bug 124406 in ubuntu "Keyboard keys get stuck and repeat (Feisty, Gutsy) (dup-of: 194214)" [Undecided,Confirmed] https://launchpad.net/bugs/124406
<ubotu> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [Medium,Confirmed] https://launchpad.net/bugs/194214
<dbmoodb> but that is not a contract is it ?
<pwnguin> dbmoodb: there's a code of conduct, and a set of core beliefs, but not i dont think theres anything quite like debian's dfsg
<RAOF> 1.63.  Hm, tracker must be indexing.
<ogra_cmpc> ubuntu members have to sign it
<cjwatson> ogra_cmpc: it's not the same thing
<ogra_cmpc> right, but similar
<dbmoodb> --- not dfsg -- social contract - 'debian will remain free' kind of thing
<pwnguin> there's the Ubuntu Promise
<dbmoodb> is there a contract
<dbmoodb> a legally binding document
<pwnguin> dfsg is part of the social contract of debian
<pwnguin> it defines what Free means
<cjwatson> the Debian Social Contract is NOT legally binding
<ogra_cmpc> heh
<dbmoodb> it is
<cjwatson> there is no consideration involved and therefore it cannot be
<pwnguin> its more like a constitution
<cjwatson> in order for a contract to be binding it must involve consideration in both directions
<slangasek> dbmoodb: no, it is not
<cjwatson> dbmoodb: there isn't a single document that's like the Debian Social Contract, but there are a number of things that address different bits of it; the licensing policy, the code of conduct, the Ubuntu Promise
<dbmoodb> it does
<cjwatson> dbmoodb: slangasek and I are both Debian developers
<dbmoodb> ok so is ubuntu promised to remain "free"
<cjwatson> dbmoodb: yes, it's right there on www.ubuntu.com
<dbmoodb> -where
<cjwatson> front page
<pwnguin> if you're looking for guiding philosophies
<pwnguin> http://www.ubuntu.com/community/ubuntustory/philosophy
<dbmoodb>  the promise ?
<cjwatson> "Ubuntu will always remain free of charge" and "Ubuntu CDs contain only free software applications"
<cjwatson> and, as pwnguin says, the philosophy link for more detail
<ogra_cmpc> heh, googling ubuntu promise brings up an intresting pile of scsi howtos :)
<dbmoodb> ok ... so how is it different to the dfsg ?
<cjwatson> we are not going to compromise Ubuntu's freedom as stated on the philosophy and licensing pages
<dbmoodb> sure
<cjwatson> the differences between Ubuntu's licensing policy and the DFSG are quite small; in essence they amount to more liberal treatment of non-code works
<pwnguin> well number one, developers can't vote to change the policy as far as i can tell
<cjwatson> see "Documentation, Firmware, and Drivers" on the licensing page
<dbmoodb> ok...
<cjwatson> other than that, the Ubuntu licensing policy is largely just a rephrasing of the DFSG
<cjwatson> and that should be pretty obvious from reading them side-by-side
<dbmoodb> - yes i  got that that is why i was wondering
<dbmoodb> if there was a social contract ")
<pwnguin> its probably better off without one
<pwnguin> lest an argument break out whether "a comma is a typo widely held belief"
<\sh> guys I'm really lost...and at the end of my knowledge somehow
<\sh> Building wine in pbuilder and on a clean chroot (which is used for sbuild, too) wine works like a charm...
<seb128> carlos, pitti: any language pack update planned then?
<seb128> carlos, pitti: would be nice to have a reflect of the GNOME current translations on current dailies
<pitti> can do, but it'll block the buildds quite a bit
<pitti> slangasek: ^ ok?
<\sh> building wine as package, the binaries in the package are borked...and I don't see anything in my buildlogs what triggers it...(this is the cause why wine is not running in the moment...building it on our buildds or in any plain sbuild chroot bring us broken binaries)
<slangasek> pitti: are the packages going to get bigger? :/
<pitti> slangasek: smaller, since it's a -base refreshment
<seb128> carlos: btw did you get the list of packages not building a template?
<slangasek> ok, go ahead please
<carlos> seb128: still working on that..
<pitti> oh, argh
<pitti> no, nevermind; unargh
<seb128> carlos: any estimation on how long it'll take? I would like to start fixing those issues, just to know if I should wait or try building a list by some other way
 * seb128 hugs pitti
<pitti> carlos: btw, we got new KDE l10n packages yesterday, so I guess next week we should do another -base refreshment?
<cjwatson> holy crap, I didn't expect to get that partman-auto change right first time
<soren> cjwatson: Which one is that?
<cjwatson> the first part of fixing bug 134950
<ubotu> Launchpad bug 134950 in partman-auto "auto-resize primary partition constraints are too strong" [High,Triaged] https://launchpad.net/bugs/134950
<Riddell> pitti: those are kde 4, they're not in rosetta
<pitti> Riddell: ok, not necessary then
<lool> doko: Around?
<doko> lool: yes
<lool> doko: Someone uploaded a new python-twill a while ago which depends on python-mechanize (>= 0.1.7b-2)
<doko> and that one doesn't exist, correct?
<lool> doko: Do you think it would be possible to solve this by updating python-mechanize?
<lool> doko: It does, but is too old
<lool> I mailed the uploader some 10 days ago to no luck
<lool> Michele Angrisano
<doko> I would have to look, maybe email jinti (Brian Sutherland) if that version is ok for other packages (schooltool, zope)?
<lool> slangasek: (Is it ok to push this to solve an uninstallability issue?)
<lool> doko: Could you do it?  I don't know this guy and haven't played with zope things for a while
<slangasek> lool: "this one" being python-twill?
<lool> slangasek: Yes
<slangasek> lool: it's in universe so not subject to alpha freeze, and it's a bugfix so not subject to feature freeze
<lool> doko: python-twill is a dep of elisa, the media center
<lool> Ah right, for some reason I thought it was in main
<lool> slangasek: Thanks
<slangasek> n/p
<lool> doko: But if you're busy, I'll do it naturally
 * ogra_cmpc mumbles about -o ControlPath= not working in sftp
<ogra_cmpc> grrrr
<soren> pitti: In https://bugs.edge.launchpad.net/ubuntu/+source/dnsmasq/+bug/190905/comments/3 you ask me to LSBify the dnsmasq init script.. I'm curious what that means? There's already the Provides:, Required-start:, etc. headers at the top. What else does LSBification entail?
<ubotu> Launchpad bug 190905 in dnsmasq "Main inclusion report." [High,Incomplete]
<tjaalton> slangasek: oo.o-voikko 2.2-1 build fine on a current pbuilder and works too
<pitti> soren: using log_daemon_msg, log_end_msg, etc. instead of echo
<soren> pitti: Ah, of course.
<soren> pitti: Got it.
<pitti> so that usplash, logging, etc. works
<soren> Right, right. Got it :)
<seb128> mvo, slangasek: hum, usershare is not working correctly, smbclient gets a NT_STATUS_ACCESS_DENIED when trying to browse the share in anonymous or NT_STATUS_LOGON_FAILURE when using my login and the samba log has a stat permission error
<slangasek> seb128: hrm, strange :/
<slangasek> seb128: oh, do you have smbpasswd set up?  There's no PAM integration there yet
<slangasek> (was jdstrand taking care of that with auth-client-config??)
<slangasek> s/\?//
<pwnguin> well that was cute
<pwnguin> i was playing a game and w decided to stick on
<seb128> slangasek: no, I though that one thing netshare was going to bring us what to avoid the need to use smbpasswd
<slangasek> seb128: er, no
<seb128> slangasek: I'm using "guest_ok=y" in this share
<slangasek> net usershare gets you easy setup of fileshares
<seb128> shouldn't anonymous work?
<slangasek> but modern Windows clients will *not* negotiate authentication with servers that require cleartext passwords
<slangasek> one would think anonymous would work then, yes; let me see
<soren> Using log_*_msg, what's the canonical why to give additional info about why a daemon is failing to start?
<slangasek> $ smbclient //localhost/moo -N
<slangasek> Anonymous login successful
<slangasek> Domain=[MSHOME] OS=[Unix] Server=[Samba 3.0.28]
<slangasek> tree connect failed: NT_STATUS_ACCESS_DENIED
<seb128> slangasek: that's what I get too
<soren> log_warning_msg perhaps?
<seb128> slangasek: the /var/log/samba has a stat permission error on the corresponding usershares configuration
 * ogra_cmpc doesnt get why ssh -S /tmp/ssh_socket <ip> works, but sshfs -o ControlPath=/tmp/ssh_socket <IP>:<dir> ./mnt/ doesnt ... :(
<slangasek> seb128: yes; so either there's an upstream samba bug, or there's a bug in how we've set up the /var/lib/samba/usershares dir in the samba package
<seb128> slangasek: ok, I'll open a bug then, thanks
<soren> ogra_cmpc: Maybe sshfs only passes a certain set of options on to ssh.
<soren> ogra_cmpc: You could make an alias in $HOME/.ssh/config with the proper configuration?
<ogra_cmpc> soren, well, according to a lot of docs out there it should respect ControlPath from the confiog file
<soren> ogra_cmpc: Yes, but you're not setting it from the config file, are you?
<ogra_cmpc> but i want the socket to be created dynamically and want to be able to connect to it on the fly
<ogra_cmpc> right
<ogra_cmpc> my original connection is manually with -M and -S
<soren> ogra_cmpc: I found the bug :)
<ogra_cmpc> there is a bug ?
 * ogra_cmpc thought he only uses it wrongly
<soren> sshfs-fuse-1.7/sshfs.c has a ssh_opts array.
<ogra_cmpc> heh
<ogra_cmpc> mean
<soren> It doesn't mention ControlPath.
<soren> Er..
<soren> No, forget that "er..".
<soren> It's accurate.
<soren> You just want to add that options and rebuild. Ok, go.
<soren> :)
<ogra_cmpc> weird, it seems to have nearly every other possible option
<soren> I suppose it's a symptom of something when you've gotten to the point where you tend to just skip by the documentation and read the code. :/
<soren> Not sure exactly of what it's a symptom.. I hope it's good!
<ogra_cmpc> soren, thanks i owe you a beer, i wouldnt have thought of looking at a parser inside sshfs
<ogra_cmpc> (i wouldnt even expected such a thing exists, ssh should cover security here anyway)
<soren> ogra_cmpc: Well, it needs to divide the stuff it gets passed as -o options into a few groups.. Stuff that is for sshfs itself, stuff that's for mount, stuff that's for fuse, stuff that's for ssh, and everything else. I suppose it's debatable if the last to groups should be joined (and just expect that unknown options are for ssh). *shrug*
<ogra_cmpc> well, i'd just add an extra option for ssh specific stuff
<ogra_cmpc> it currently uses -o for eveything
<soren> ogra_cmpc: I'm not sure if you can.
<soren> ogra_cmpc: Unless you circumvent fuse's option parser thingie.
<Hobbsee> Fujitsu: btw, have you had the dodgy key events since the hal upgrade?
<ogra_cmpc> soren, hmm, recompileed works but i get no file listing in the mount ... seems they had reasons to disable it
<soren> *shrug* :)
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<Fujitsu> Hobbsee: Yes.
<Hobbsee> Fujitsu: pity
<Fujitsu> Three times tonight, but not in a while before that.
<Hobbsee> ah
<Hobbsee> cjwatson: what dbmoodb was attempting to ask (and apologies for sending him here), is how his broadcom card worked after no internet connection, on a clean install
<cjwatson> a most circumlocutory way to ask that question
<cjwatson> and I don't know either since we don't ship Broadcom firmware
<Hobbsee> cjwatson: well, exactly.
<mjg59> Wireless or wired?
<Hobbsee> wireless, i think.  he's not around to ask now
<mjg59> Because Debian strip the firmware from the tg3 driver
<mjg59> And we don't, because that would be ridiculous
<Hobbsee> hardly any wired ports at uni, so very likely wireless
<mjg59> The only way it could is if he's talking about wired
<Amaranth> So he was asking about the dfsg because he thought we were doing something non-free?
<Hobbsee> i'll bug him tomorrow about it.  or, if it's like normal, he'll bug *me* about it again.
<Hobbsee> Amaranth: yeah, pretty much
<Amaranth> make sure he doesn't look in restricted then :P
<Hobbsee> wanted to see if ubuntu was actually free, and then never appeared to get to the second question
<Hobbsee> heh
<Hobbsee> yeah, well.  becaues making non-free hardware work at all is bad.
<pwnguin> Hobbsee: you could just point him to gnewsense / gobuntu
<Hobbsee> pwnguin: he's a debian user, so i don't know why he cares
<pwnguin> heh
<pwnguin> ah
 * Hobbsee would say more, but won't, due to the logged nature of the channel
<pwnguin> so thats why he was confused about the legal nature of the social contract
<Hobbsee> i suspect so
 * Mithrand1r tickles Hobbsee.
 * Hobbsee tickles Mithrand1r with a pile of 1's
<cjwatson> the reason people get confused about the legal nature of the social contract is because it is misnamed
<ogra_cmpc> do you have to sign it in the NM process ?
<mjg59> You have to state you agree to abide by it
 * ogra_cmpc stil didnt invest time in that ...
<mjg59> There's no formal signature
<ogra_cmpc> ah
<ogra_cmpc> well, then "contract" is indeed a bit much for it ...
<cjwatson> ogra_cmpc: that wouldn't make it binding anyway; the contract is between Debian and the free software community, and the free software community never does anything to it
<cjwatson> legal contracts are two-way
<ogra_cmpc> yeah
<ogra_cmpc> even though every DD is part of that community
<ogra_cmpc> sigh ... jockey is so evil on the classmate
<ogra_cmpc> if we really want to start doing stuff for the subnotebook market some day i guess we need to rework our "python for everything" directive
<mvo> ogra_cmpc: what is the issue? speed? memory?
<ogra_cmpc> mvo, both
<ogra_cmpc> the first caused by the latter
<\sh> grmpf...
<jdong> how much RAM does the Classmate have?
<ogra_cmpc> jdong, 256
<\sh> wine will work again...when you reset LDFLAGS= and the bugreport was closed upstream as invalid...
<jdong> hmm and it runs that badly?
<ogra_cmpc> i recently wrote a little screenswitcher app that enables panning by cqalling xranrd -s 800x600 or 800x480 ... a simple switcher
<ogra_cmpc> implemented in python with egg trayicon as a 10-15 line script that thing eats about 30M with all interpreter stuff loaded etc
<ogra_cmpc> the same thing in C takes 5M
<mjg59> ogra_cmpc: Is that really 30MB per-application?
<mjg59> Or 30MB mostly shared with the rest of the python stack?
<ogra_cmpc> mjg59, does that matter if you only run that one app ?
<mjg59> ogra_cmpc: Is it really the only python app you're running?
<ogra_cmpc> the thing is that with the printer applet, update-notifier and jockey running the desktop takes around 20min to start
<mjg59> The printer applet is python
<ogra_cmpc> eliminating all the python applets makes it slightly usable
<mjg59> Eh. If "slightly usable" is what you get without python, then we've already lost
<jdong> that's ridiculous... I've ran Ubuntu on 256MB RAM in VM's and it wasn't that bad
<mjg59> jdong: UMA systems
<jdong> mjg59: what's the difference? slower CPU right?
<ogra_cmpc> mjg59, well, i suspect there will be more subnotebook HW like this one in the future
<mjg59> So if 3D is enabled, you've already lost 20MB or so
<ogra_cmpc> jdong, the classmate has no L2 chache
<mjg59> jdong: RAM used for video
<ogra_cmpc> so IO sucks by design already
<jdong> ugh
<jdong> lovely
<ogra_cmpc> then you have no swap (would kill the flash)
<jdong> and why should such things be expected to run GNOME?
<mjg59> jdong: It shouldn't
<ogra_cmpc> so 256M are already extremely tight for a gnome desktop
<mjg59> Given the current state of gnome, anyway
<ogra_cmpc> mjg59, :p tell that to our CTO
<mjg59> Resource usage needs to be improved everywhere, rather than just worrying about python
<jdong> indeed
<mjg59> ogra_cmpc: Eh. Ubuntu is only marginally usable on a 256MB machine.
<ogra_cmpc> i have order to use gnome here
<mvo> ogra_cmpc: update-notifier is C
<ogra_cmpc> so i cut down what i can ... its actually usable but crippled indeed
<jdong> how the heck is that thing ever going to run a web browser?
<mjg59> If you have no swap, it's not going to be usable
<ogra_cmpc> jdong, starting slowly ... but with all caches disabled it workws fine once its up
<jdong> ogra_cmpc: have you blacklisted all the restricted modules yet?
<jdong> ogra_cmpc: the 3 nvidia ones will chew up 30MB RAM fast
<ogra_cmpc> mjg59, i agree that we need a dedicated subnotebook desktop but thats not the problem i can attack atm :)
<mjg59> Oh, yeah, if l-r-m is installed then you lose instantly
<jdong> indeed :)
<mjg59> jdong: It's not a matter of blacklisting - they won't be autoloaded. It's the fact that they get linked in a tmpfs.
<mjg59> That's fine if you've got swap, failure if you haven't
<laga> why are they linked in a tmpfs?
<ogra_cmpc> jdong, ah, thanks i had that ripped out in my image build script originally, seems its back ...
<jdong> mjg59: blacklisted modules don't get loaded into tmpfs for me
<jdong> lrm                   505M  1.3M  504M   1% /lib/modules/2.6.22-14-generic/volatile
<jdong> that's just with the 3 nvidia's and ath_hal
<ogra_cmpc> thanks for the pointer, now i know why tadays image is slower than last weeks :p
<jdong> blacklisted, that is
<ogra_cmpc> *TODAYS
<ogra_cmpc> oops
 * mvo hands ogra_cmpc a new CAPSLOCK key
<jdong> ogra_cmpc: shift and caps lock too scrunched? ;-)
<ogra_cmpc> heh
<ogra_cmpc> yeah, they are close together
<hunger> OOo depends on OOo-writer2latex. Could somebody please add the later to the archive?
 * jdong writes ogra_cmpc a python daemon to detect simultaneous shift/capslock presses, then sets it for bootup
<ogra_cmpc> i can usually cope with the keyboard if i dont switch all the time
<sladen> the lrm could be culled if the PCI IDs aren't there
<mjg59> jdong: Uh. Do you mean disabled in /etc/default/linux-restricted-modules-common ?
<ogra_cmpc> sladen++
<jdong> mjg59: yes
<jdong> mjg59: sorry if blacklisting's not the correct term for doing that :)
<mjg59> jdong: Right. blacklisting generally refers to the udev blacklisting.
<mjg59> s/udev/module-init-tools/
<jdong> yeah, realized that in hindsight :)
<hunger> jdong: Just use xmodmap to map capslock to something more useful;-)
<jdong> hunger: I take it you're an emacs user. ;-)
<ogra_cmpc> hmm, unmounting lrm on the fly doesnt free any ram ... intresting ... df reported 38M usage
<hunger> jdong: Nope, but I have a thinkpad (no win key).
<jdong> hunger: ah
<hunger> ogra_cmpc: tmpfs tends to get pushed into swap really soon and usually stays there.
<mjg59> hunger: There is no swap
<jdong> hunger: no swap
<jdong> that's half the problem :)
<ogra_cmpc> hunger, no swap
<hunger> Oh, sorry.
<jdong> LRM is less of a problem when there is swap
<ogra_cmpc> well, thats not really a problem if you dont hit the edge
<ogra_cmpc> if i run my cusomized devel desktop with pcmanfm, cairo-dock, devilspie and metacity it never hits the edge actually
 * hunger got swap mostly because of lrm.
<jdong> you sure you can't swap out the GNOME with XFCE or something....
<cjwatson> we already disable the nvidia modules (and others) on the live CD for exactly the memory reasons mentioned above
<jdong> the default GNOME desktop is quite RAM hungry
<ogra_cmpc> jdong, not for this image
<jdong> cjwatson: would it be out of the question to use lrm-video to decide whether or not the nvidia modules should be loaded?
<ogra_cmpc> i plan to start a subnotebook desktop project in intrepid ...
<jdong> ogra_cmpc: I have a feeling even non-subnotebook users would be interested in a lightweight too :). That'll really take off
<ogra_cmpc> seems bryce already started working on a lighter and better to use inkscape ...
<cjwatson> jdong: not if somebody submits a patch for that to casper, no
<mjg59> jdong: Though the situation is unlikely, it's valid to hotplug PCI cards
<cjwatson> jdong: though I doubt it would be useful; surely xorg autoconfiguration will never pick the restricted drivers
<jdong> mjg59: hmm sounds like it's time for a less static structure to lrm in that case
<ogra_cmpc> jdong, well i thought about dedicated software that runs at the cut down resolution etc
<jdong> cjwatson: yeah on the livecd it'd be less than useful
<cjwatson> jdong: so lrm-video will never select any of those drivers during live CD boot
<cjwatson> jdong: exactly, that's why :)
<ogra_cmpc> not only performance but also UI improvements
<cjwatson> jdong: oh, do you mean using lrm-video to decide whether they should be loaded on other systems?
<jdong> cjwatson: jockey would also need some sort of ability to load
<jdong> cjwatson: yeah my initial thought was for already installed systems
<jdong> cjwatson: ogra_cmpc isn't the first time I've helped someone dramatically improve RAM problems by disalbing LRM
<cjwatson> jdong: sounds reasonable, though I'm not volunteering :)
<jdong> :)
<mjg59> jdong: If you've got swap, l-r-m isn't really a problem. If you don't have swap, you're already running outside the standard setup :)
<ogra_cmpc> jdong, well, i know about the issue (i think i was the first one to discover it in dapper with ltsp back then) ... i just didnt bother to look if the removal part of my image builder worked right :)
<ogra_cmpc> since it worked last time (a week ago) and didnt install lrm first place
<jdong> ogra_cmpc: yes, I trust that you'd know about the issue, but average new Ubuntu user with lightweight PC probably has no idea
<ogra_cmpc> jdong, well, its our job to fix it for them ;)
<ogra_cmpc> what would really be helpful for the low spec devices would be a module profiling mechanism that generates proper module lists for initramfs ...
<ogra_cmpc> the onews we have atm are still loading a ton of extra stuff i actuall dont need
<ogra_cmpc> if i only load the 10 modules i actually need for booting, the classmate boots in about 20% of the time it uses for probing the whole module list
 * ogra_cmpc reboots
<ogra_cmpc> hmm, intresting ... according to htop i didnt earn a byte with removing lrm ...
<ogra_cmpc> but the system feels ten times more responsive
<mvo> Riddell: do you happen to know if we have kde-guidance on the super-mirror as a svn import?
<Riddell> mvo: I don't think we do
<mvo> Riddell: do you know if someone is working on it to make it crash less with our current xorg.conf ?
<Riddell> mvo: ScottK has patches
<mvo> aha, nice
<Riddell> mvo: he even uploaded to the archive I think but reverted because of freeze
<ScottK> mvo and Riddell: But I don't know how much help it'll be with the no xorg problems
<ScottK> Yes I did (urgh).  Thanks for reminding me
<Riddell> mvo: here https://edge.launchpad.net/~kitterman/+archive
<ScottK> If someone could suggest a strategy for dealing with the no Xorg, I can probably implement it.
<ScottK> So far I've just patched stuff that I can reproduce locally or that I can see in the code how to catch with no regression risk.
<ScottK> mvo: Point me in the right direction and I'll give it a shot.
<mvo> ScottK: its a while since I touched it last. I was thinking of a) making it more robust b) making it return stuff like "unknown" or "auto-detect" when there is no section in the xorg.conf file so that the GUI can deal with it. but I'm currently looking at the bugreport first to see what the most common problems are
<ScottK> mvo: OK.  My python is reasonably robust, but my xorg knowledge is very shallow, so I'll need some hand holding, but can get it done with some guidance (pun intended).
<mjg59> bryce: Uh. Why did you remoe the entries for wacom tablets in the default xorg.conf? Now people need to edit text files to get their hardware to work.
<mvo> ScottK: heh :) I come back to you when I have a slightly better idea, ok? do you have commit access to the upstream repository? I imagine we will want to put the changes upstream too
<ScottK> mvo: No.  I've no involvement with upstream.  I figured to get some things sorted and then send patches.
 * mvo nods
<ScottK> mvo: One of the bugs I was looking at seems to have a guidance component and a maybe hal/policykit component.  It's Bug #183656.  Is that something you could take a look at?
<ubotu> Launchpad bug 183656 in kde-guidance "Cancel button in kde-guidance-powermanager doesn't do anything" [Medium,In progress] https://launchpad.net/bugs/183656
<Riddell> ScottK: that's not really ScottK's area
<Riddell> ScottK: that's not really mvo's area
<tjaalton> mjg59: that was done already in gutsy
<tjaalton> mjg59: there were some issues with it too
<ScottK> Riddell: OK.  Thanks.  WHo should I talk to about that?
<Riddell> ooh tjaalton, X has started working again on my r40e!
<tjaalton> Riddell: what happened?-)
<mjg59> tjaalton: Yeah, but the bug only mentions an issue with gok that's never debugged
<Riddell> ScottK: possibly see if Lure has some time?
<ScottK> Riddell: Thanks.  Will do.
<ScottK> Guidance shouldn't crash in any case (which I can fix), but that won't make it work.
<tjaalton> mjg59: also kde-apps bug about missing input devices, although that's mostly cosmetic
<mjg59> tjaalton: Yeah, that's easily fixable
<tjaalton> mjg59: and tbh, by now we should've had input-hotplug with wacom support, but the world doesn't like us :P
<mjg59> tjaalton: It's an unfortunate regression over pre-gutsy releases
<tjaalton> mjg59: it is.. but could it be done in jockey or similar?
<mjg59> tjaalton: Unf. Conceivably.
<mvo> ScottK: I'm mostly interessted in the guidance-backend issues currently because they make both the kde and gnome frontends crash (stuff like #173762)
<mvo> scottK, Riddell: how should I feed patches for guidance, should we have a shared bzr packaging repository so that we can easily work on it together?
 * ogra_cmpc dances around mvo ...
<ogra_cmpc> i got g-a-i working on the classmate in a usable speed :)
<mvo> ogra_cmpc: woah! how did you manage that :P ?
<Riddell> mvo: can do
<ogra_cmpc> moving /var off the unionfs ;)
<saispo> soren: ping ?
<mvo> Riddell: do you currently use bzr for packaging?
<laga> ogra_cmpc: does unionfs make things slower?
<ogra_cmpc> laga, well, at least it makes db access slow it seems
<laga> ogra_cmpc: i wonder if aufs would be faster
<Riddell> mvo: not for guidance, some kde packages are in ~kubuntu-members
<ogra_cmpc> which means apt, dpkg, g-a-i get extremly slow
<laga> given that it's in lum, maybe you could try it :)
<ogra_cmpc> laga, in intrepid
<laga> ogra_cmpc: heh
<ogra_cmpc> i dont have time to waste on the classmate atm
<ogra_cmpc> hmm, i somehow trashed gdebi-gtk
<ogra_cmpc> FATAL -> Failed to fork.
 * ogra_cmpc wonders what it forks ... gdebi, synaptic, apt and dpkg work fine ...
<mvo> ogra_cmpc: might be a memory issue
<soren> saispo: Wazzup?
<ogra_cmpc> mvo, hmm, all the others work
<saispo> soren: an error on xen gutsy kernel when i create lvm volume, have you seen this ?
<saispo> (2.6.22-14-xen) have you seen this ?
<soren> saispo: No, but I've not tried either, so that's hardly surprising :)
<saispo> :)
<saispo> i create a lot of lvm volume with a python script and after some, the kernels oops
<soren> saispo: You could try over in #ubuntu-xen
<zul> or you could try hardy
<saispo> ok thanks
<saispo> zul: not possible
<saispo> but thanks for your advice ;)
<ogra_cmpc> mvo, it doesnt hit the edge, i just monitored it. it eats a *lot* of ram though
<mvo> ogra_cmpc: it is (or should be) mostly mmaped stuff from the apt cache
<ogra_cmpc> mvo, gdebi in a terminal seems to eat the same amount of ram and works, so i rule out ram here
<_r1_> hi
<_r1_> Is it known that gutsy alternate install CD make a kernel MD5SUM mismatch during an install ?
<_r1_> (and I have a second issue few time after force this step...)
<jdong> I've installed at least 5 gutsy systems from the alternate CD and none of them have any sort of mismatch
<jdong> I suspect a bad download or burn
<_r1_> I test 2 differents images (kubuntu/xubuntu) with exactly same error
<_r1_> and It's my first gutsy error
<_r1_> I'm now trying to install without any network connection
<kagou> hi
<TomaszD> hi, an easy fix if some has a moment https://bugs.launchpad.net/ubuntu/+source/wine/+bug/198761
<ubotu> Launchpad bug 198761 in wine "Please include Polish translation for .desktop files (diffs included)" [Undecided,New]
<cjwatson> _r1_: if you're seeing it with multiple images, then consider cleaning your CD drive; that's a common culprit
<cjwatson> _r1_: drive cleaning kits are fairly cheap, and can save a lot of annoyance
<tjaalton> still no new oo.o-l10n packages in the archive, needs a push?
<\sh> bryce: bug #183922 ... shouldn't the status  "Triaged" until someone can debug X and send us the report?
<ubotu> Launchpad bug 183922 in wine "Xorg crashes after using Microsoft Word 2003 in Wine." [Undecided,New] https://launchpad.net/bugs/183922
<_r1_> cjwatson: It's appear it's actually a hardware problem you're right (iso and cd MD5 are both good)
<_r1_> sorry for that...
<tjaalton> mjg59: care to reply to bug 155937, I've given up ;)
<ubotu> Launchpad bug 155937 in xserver-xorg-input-synaptics "SHMConfig should be enabled by default, and gsynaptics should be installed by default on laptops" [Undecided,New] https://launchpad.net/bugs/155937
<mjg59> tjaalton: Not really. SHMConfig can't be enabled by default. Ever.
<tjaalton> mjg59: I already closed it once as won'tfix
<mjg59> tjaalton: Most of the features of gsynaptics aren't supported by the interface I added.
<mjg59> tjaalton: I can't comment myself (don't have a launchpad account)
<tjaalton> mjg59: oh
<TomaszD> pitti, hi, I'm one of ubuntu-l10n-pl admins. I've heard there's a ppa for daily langpacks for hardy, could you share the url (in private, if need be)
<TomaszD> ?
<pitti> TomaszD: sure, it's not secret at all, to the contrary
<ogra_cmpc> mjg59, you removed your LP account ?
<pitti> TomaszD: https://launchpad.net/~ubuntu-langpack/+archive
<TomaszD> ok, thanks, I was googling "pitti ppa"
<TomaszD> pitti, no hardy?
<pitti> TomaszD: no, we upload updates straight to hardy (automatically twice a week)
<\sh> TomaszD: thx for the translation :)
<TomaszD> pitti, oh ok :]
<TomaszD> \sh, no problem, btw could someone look here https://bugs.launchpad.net/ubuntu/+source/paprefs/+bug/191854 ? :]
<ubotu> Launchpad bug 191854 in paprefs "Please include Polish translation for paprefs (translation attached)" [Undecided,New]
<TomaszD> it's a universe package, upstream vendor doesn't respond
<\sh> TomaszD: taking care of it
<TomaszD> \sh, awesome, thank you!
<jdong> what's the commandline way of starting up the "partial upgrader" thing?
<\sh> TomaszD: done
<TomaszD> \sh, you rule!
 * TomaszD hugs \sh
<\sh> TomaszD: na you rule...thanks for making ubuntu rock even harder :)
<TomaszD> :D
<ScottK> pitti: Thank you for your comments on my DM application.
<pitti> ScottK: my pleasure
<LaserJock> yeah, ScottK seems to be getting all the love ;-)
<ScottK> You just got a nice reply.
<LaserJock> oh heah, I did!
 * LaserJock hugs azeem 
<keescook> heya
<keescook> pitti: say, the virtual interface patch you applied from me -- I think it's causing a bigger headache than it solves.  can you pull it out after the alpha?
<pitti> keescook: hi
<pitti> keescook: hm, can do; can you reply to the upstream bug with improvements/ask to close the bug?
<keescook> pitti: well, I think it _is_ correct -- the problem is that the client applications suddenly need additional logic and fixing all of those before release seems like a bad idea.
<keescook> pitti: but I will comment on the bug about the behavior it creates
<pitti> keescook: ah, ok
<pitti> keescook: done in bzr head
<pitti> keescook: I'm still waiting for slangasek's ack for uploading it
<keescook> pitti: okay, thanks.
<EtienneG> wondering about something, guys
<EtienneG> I set a default boot option on an ext3 volume using tune2fs (as in, tune2fs -o acl /dev/...)
<EtienneG> yet, the boot option is not used when mounting the volume
<EtienneG> so either the tune2fs man page is incorrect in stating that it should, or the feature have been deprecated, or I am missing something
<EtienneG> anybody have a clue on the subject?
<EtienneG> forget above question, it just needs a reboot, and the option will not show up in the output of mount
<wasabi> bryce: Yup. Latest upload fixed it.
<slangase`> pitti: sorry, waiting for my ack before uploading which?
<Tonio_> am I the only one having problem with his @ubuntu.com email redirection today ?
<Tonio_> not any email arrives to my mailbox.... the mailbox itself works
<Tonio_> I can see that the mail is correctly sent to mx.canonical.com
<Tonio_> then nothing...
<Amaranth> that'd be bad, all of my mailing list mail goes through my @ubuntu.com mail
<mario_limonciell> well "bad" is a misnomer.  It may grant you a forced break from this stuff :)
<bryce> \sh: no, I set to Incomplete for bugs where more info is needed from the reporter in order to troubleshoot it
<\sh> bryce: ok...I just wanted to make sure, that we don't forget about this bug
<bryce> \sh: since it's a crash when running a commercial app (MS Word 2003), we need someone with that app to gather an error message, backtrace, or etc.  Just knowing it crashes isn't enough to go on in this case.
<bryce> mjg59: the wacom entries were causing breakage for certain accessibility applications; I removed them at heno's direction.
<\sh> bryce: agreed..good that I don't run commercial apps.
<bryce> ogra_: the inkscape-lite stuff I did was really just a demo to stimulate thinking in that direction, but it's inspired a few people to do a more "proper" implementation for inkscape 0.47 or later
<bryce> \sh: yeah we do re-review incomplete bugs periodically and reprioritize as info becomes available
<Kopfgeldjaeger> n8
<slangasek> heh
<slangasek> stgraber: You are here : QA Tracker -> ^Ubuntu \w* \w*$
<slangasek> ? :)
<stgraber> slangasek: argh ... :)
<stgraber> slangasek: it's the result of using some more regexp, will ask for a code sync tomorrow :)
<slangasek> ok :)
<slangasek> mr_pouit: well, the OOo size fixes have brought xubuntu alternate down to size on amd64, but i386 is still oversized: 729M    xubuntu/daily/20080305.1/hardy-alternate-i386.iso
<slangasek> mr_pouit: do you want to look at this so we can include xubuntu alternates in alpha-6?
<stgraber> slangasek: btw, the tracker was updated so you now have Kubuntu-KDE4, the right Edubuntu images, Wubi and a now completely working download info window (I have entirely rewritten my cdimage.u.c parser)
<slangasek> stgraber: saw that, thanks
<slangasek> well, the image fix-ups; didn't notice the download info window changes :)
<ScottK> slangasek: It looks like the fix for the postfix backport (depwait due to dep in Universe) fix only took on i386.  The other archs are still depwait ...
<slangasek> ScottK: how... odd
<lamont> ScottK: iirc, I gave back i386
<slangasek> oh, there's your answer :)
<ScottK> Ah
<ScottK> lamont: Would you please give back all the other archs and all archs on Edgy?
<slangasek> for edgy-backports, I hadn't moved the package to universe; that's a prereq, right?
<ScottK> Ah.  Yes
<ScottK> Sorry.  I thought you'd done them both.
<slangasek> nah, the output after I did the dapper one scared me enough that I stopped there to see what happened after the next publishing run
<ScottK> OK.  Well it seems to have worked out fine for Dapper i386.
<lamont> Content-Type: text/plain; charset=ISO-8859-1
<lamont> Message-ID:
<lamont> Date: Wed, 05 Mar 2008 15:50:30 -0500
<slangasek> right, edgy done now as well; I suppose it probably needs to wait a cycle before give-backs will work
<lamont> what is wrong with that picture...???
<ScottK> slangasek: I think this is something that ought to be fixed as it's just going to get more painful.
<lamont> slangasek: what we want is --pretend-avail launchpad-style
<ScottK> Slight bit of message ID missing there.
<slangasek> lamont: --pretend-avail wouldn't fix the chroot's sources.list, though?
<lamont> no
<slangasek> lamont: wrong with that picture> the legacy charset!!
<lamont> but the package build-depends: libcdb-dev | tinycdb
<lamont> null msgid == all of their mail is a duplicate
<slangasek> lamont: and which of those is in dapper/main?
<lamont> uh... the dapper/i386 build worked....
<slangasek> lamont: yes, because I moved the dapper backport to universe
<lamont> right
<slangasek> so maybe I'm confused about what you're saying should be fixed
<lamont> so that just leaves the issue that the dapper package is dep-wait on a package that won't exist until edgy-backport
<slangasek> oh
<lamont> the dapper-backport is d-w the wrong package...  yeah ored deps
<slangasek> surely the d-w was only set because *neither* package was available the first time it tried to build?
<slangasek> so if it were given back now it should pick up tinycdb ok?
<ScottK> That's what the i386 one appears to have done.
<lamont> right
<lamont> the d-w got set on the first package, since neither was available.
<lamont> and the first package is the "right one for sid" :-)
<ScottK> All I know is the 2.4.5 backport was painless.  I don't think anything has changed in the package to make it harder since then.
<lamont> ScottK: it was painless because I did it, maybe?
 * lamont goes looking
<lamont> ... libcdb-dev | tinycdb
<lamont> hrm
<lamont> amusingly true for 2.4.5-3build1~dapper1 as well
<ScottK> Without any data to prove it, I suspect it's easier because Launchapd has been 'improved' since.
<emgent> good night people
<ScottK> Of course that theory aligns well with my internal biases, so I may well be full of it.
<mjg59> bryce: I'd rather have worked out what was causing the issues
<slangasek> tjaalton: you milestoned bug #178292, is this something you're working on?
<ubotu> Launchpad bug 178292 in mesa "3D-Accelerated Games cause X to crash with Intel Driver" [Unknown,Fix released] https://launchpad.net/bugs/178292
<tjaalton> slangasek: oh yeah, assigning to myself
<mdke> tkamppeter_: around?
<slangasek> tjaalton: but I'm not thinking that you're still aiming to get it fixed for alpha-6? :)
<tjaalton> slangasek: no, I noticed that you pushed it for beta, which is fine :)
<\sh> bah..why are the virtualbox kernel modules not upgraded by default ? (for use with latest kernel?)
<\sh> something for tomorrow...
<\sh> good night folks
<Tonio_> Amaranth: do you also have that mail redirection failure ?
<Amaranth> Tonio_: i don't think so
<Amaranth> No, I'm definitely getting emails from mailing lists still
<Tonio_> Amaranth: any idea who to contact for this problem ?
<Amaranth> Nope
<Tonio_> Amaranth: the strange thing is that I deleted my standard email from launchpad and added it again, and received the launchpad email confrmation in my mailbox
<Tonio_> but still no redirection...... that's crazy
<Tonio_> another option is that my isp rejects redirected emails, which is another option....
<Tonio_> hard to know what happens in fact......
<Amaranth> the redirection is not automatic
<Tonio_> Amaranth: you mean ?
<Amaranth> although perhaps you've broken it
<Amaranth> it doesn't get turned on automatically
<Tonio_> Amaranth: didn't touch anithing for month
<Amaranth> someone goes and does it
<Amaranth> although i think it's a script
<Amaranth> no clue then
<Tonio_> Amaranth: so it was broken on the ubuntu side....
<Tonio_> Amaranth: I'll try to ping a few people at canonical....
<jdong> infinity: looks like backports is no longer ignoring the main-universe split like it's supposed to....
<ScottK> See recent postfix depwaits in Dapper/Edgy and the soyuz foo slangesek had to use use make it work for an example.
<jdong> ScottK: I poked infinity, who was the last person who helped way back then
<jdong> ScottK: if that doesnt' work then I guess soyuz bug?
<ScottK> jdong: I'd suggest file it.  I've given up on filing LP bugs.
#ubuntu-devel 2008-03-06
<nixternal> evand: isn't adding Jockey to Gobuntu going against its purpose?
<TheMuso> nixternal: I think its due to the seed inherritance. Let me check the seeds to be sure.
<ion_> AFAIU, itâs suitable for free third-party drivers as well.
<nixternal> ya, that could lead to very bad publicity
<TheMuso> Well, I think its in the gobuntu seeds proper, as its not in the platform seeds. Pulling gobuntu seeds to have a better look.
<slangasek> jockey is also supposed to be a general-purpose driver manager now
<slangasek> but unseeding it shouldn't hurt either
<nixternal> slangasek: ahhhh, general-purpose is cool...I thought it was just going to be the new 'restricted-manager'
<slangasek> nixternal: nah, it got renamed because the scope has expanded to include management of free drivers
<nixternal> groovy
<slangasek> OTOH, I'm not sure there currently are any free drivers that it would suitably manage for gobuntu
<mgunes> hi all
<mgunes> slangasek, how much time do I have to add to the alpha 6 release notes?
<slangasek> mgunes: around 12 hours, if everything else goes according to plan
<mgunes> slangasek, thanks, I'll see what I can do
<mathiaz> slangasek: can I add a section about windows integration (likewise-open) even if the package is in universe ?
<mathiaz> slangasek: to do the Alpha6 release notes
<slangasek> mathiaz: sure; you're looking to get more testing feedback, I suppose?
<mathiaz> slangasek: yes !
<slangasek> we've pointed people at packages while they were still in universe before; e.g., ufw, ff-3
<mathiaz> slangasek: ok - I'll update the Release Notes then
<mathiaz> slangasek: oh - and also a section about iscsi
 * Hobbsee waves
<ScottK> It's be cool if zul could upload ebox in time to make the release notes too.
 * Hobbsee gives irc +1
<Kano> hi, is it possible to add a script to the image which is outside the compressed part and execute it on startup?
<Kano> for the live cds
<Kano> i would like to execute something before X starts
<TheMuso> Kano: Have you looked at the way casper works?
<Kano> well i looked but did not see it
<Kano> do you know more about casper
<TheMuso> Kano: For a start, there are the several scripts in scripts/casper-bottom that do a lot of stuff.
<Kano> thats too early for me
<Kano> i need internet access
<mathiaz> slangasek: I've updated the ReleaseNotes for Alpha6
<TheMuso> Kano: Then you probably have to modify the squashfs image.
<Kano> best would be after networking/network-manager and before x
<Kano> also i see no option to stop network-manager from running
<Kano> you could maybe delete the startup links for network-manager(-dispatcher) if a nodhcp option is used
<slangasek> mathiaz: cheers
<TheMuso> Perhaps, but it would need discussion, probably at the next UDS for example.
<Kano> uds?
<TheMuso> Ubuntu Developer's Summit.
<Kano> when is that
<TheMuso> Kano: I thought you had been around this community for long enough by now to know what that means.
<Kano> i am no ubuntu developer, i only use parts currently
<TheMuso> It is in May.
<Kano> what are ubiquity-hooks?
 * Hobbsee suggests RTFMing
<Hobbsee> or looking at the source
<Kano> which manual for casper?
 * Hobbsee thought there only was one...
<Kano> do you call your installer ubiquity?
<Kano> a really logical name...
<Kano> could somebody remove patch 03* from syslinux? because of that the menu.c32 countdown is always 0
<Kano> http://kanotix.com/files/fix/casper-terminalserver/casper-terminalserver-kubuntu.jpg
<Kano> usally 0 is never shown, 1 would be the last
<Kano> in that test i boot kubuntu via pxe with a modified pxelinux.cfg/default derived from isolinux.cfg
<Kano> if you drop patch 03 it counts down the 10 timeout i set
 * Hobbsee suggests bugs work better than irc, particularly during au day.
<TheMuso> Hobbsee: Not just particularly during au day, but any time.
<_MMA_> Kano: After watching you over various Ubuntu IRC channels I wish you would start working *with* this community and its processes and not just take. You've been asked many times to file bugs on issues, on various channels. If you cant be bothered to do it, I wouldn't expect people to bother with you.
<Kano> _MMA_: i filed already too many bugs
<slangasek> "too many bugs"?
<Kano> most of em are against the kernel
 * cody-somerville pokes asac in the tummy.
<_MMA_> I would also say being a part of various mailing lists are a good thing. -kernel, -devel, -devel-discuss, -motu
<Kano> mailing lists are something what i absolutely hate
<crimsun> cody-somerville: if it's WRT n-m, it's fixed in -0ubuntu3.
<cody-somerville> :)
<_MMA_> Kano: A sometimes unfortunate necessity. Patches with bugs also go a long way. And in the end, people might not agree with the patch and it doesn't go in. Just the way it goes sometimes.
<Kano> i have got already a fixed version. just a i do not create live cds based on ubuntu yet it is a bit difficult to change what i want
<slangasek> crimsun: um?  what's broken with n-m?
<crimsun> slangasek: uninitialized priv struct in nm-supplicant.c
<Kano> to explain how that works with kanotix -> identify bug -> fix bug -> package updated
<slangasek> crimsun: should I be stopping this CD build I'm running specifically to pull in the n-m update, then?
<Kano> no launchpad or something needed
<crimsun> slangasek: very much so.  You want -0ubuntu3 on the CD build.
<slangasek> grmbl
 * cody-somerville nods.
<crimsun> slangasek: the effect being that all wireless broke
<slangasek> and when will -0ubuntu3 be available?  I currently only see -0ubuntu1 in the archive
<slangasek> heh, "published 38 seconds ago"
<slangasek> ok then
<TheMuso> I was going to say, I saw it hit hardy-changes a few minutes ago.
 * ScottK would have avoided that bug by virtue of having lost the wireless card for his Hardy laptop.
 * cody-somerville is sitting on the floor by his router with a 15" ethernet cable :(
<TheMuso> cody-somerville: lol
<Kano> cody-somerville: did you ever think of using a router with dd-wrt or similar in client bridge mode?
 * cody-somerville did not think of that, no.
<Kano> works beautifully, no drivers needed for wlan cards, you can connect as many clients as you like to
<Kano> for 2-3 pc in the same room even cheaper than wlan cards
<cody-somerville> cool.
<Kano> i have got wlan cards, but use em only for driver testing
 * cody-somerville really hates the changes to the theme.
<Hobbsee> ah yes, the new theme
<Hobbsee> black text on dark shiny windeco really isn't a good combination
<slangasek> cody-somerville: that reminds me; do you want to have a look at what needs to be done to get xubuntu i386 alternate down to size for alpha-6?
<cody-somerville> slangasek, Sure
<slangasek> cody-somerville: a metapackage update would probably help some, I removed from fonts from the platform seed that ArneGoetje says aren't needed; but i386 is currently 29MB oversize, so more is needed
 * cody-somerville nods.
<slangasek> s/from/some/ # need some rum
<cody-somerville> slangasek, I noticed in the manifest for the live cd, there are duplication applications
<cody-somerville> slangasek, I think xubuntu-meta needs to be regenerated and uploaded
<slangasek> cody-somerville: hrrm, you're not MOTU?
<ScottK> Hobbsee: Would you please ack Bug #198160?
<ubotu> Launchpad bug 198160 in rails "Please sync package 'rails' 2.0.2-1 from debian sid" [Undecided,New] https://launchpad.net/bugs/198160
<cody-somerville> slangasek, Not yet.
<ScottK> Note that despite the title. it's a merge.
<Hobbsee> hah
<ScottK> The reporter thought it would be a sync, but we got that worked out.
<slangasek> cody-somerville: right; well, do you want to have a look at whether any other seed changes are needed?  then I can upload xubuntu-meta for you
<Hobbsee> ScottK2: looks fine
<ScottK> OK.  Are you going to mark it in LP or do you want me to?
<ScottK> Hobbsee: ^^
<slangasek> Hobbsee, ScottK: knetworkmanager seems to still need a rebuild against libnl1, now that n-m is (theoretically) working with it, do either of you want to check that a no-change rebuild will DTRT?
<slangasek> Tonio_: or you, if you're around ^^
<ScottK> slangasek: Well see my earlier comment about lost the wireless card for the laptop I have Hardy on.
<cody-somerville> slangasek, I just got a phone call and I gotta jet now but off the top of my head, example-content can be removed.
<ScottK> I can check for wired use, but I dunno if that'll help or not.
<Tonio_> slangasek: I can do that on friday
<Tonio_> slangasek: no time for this now...
<slangasek> ScottK: ah, right; as we've seen, wired-only testing of n-m does not give us good coverage ;)
<Hobbsee> slangasek: not easily from here.  will probably be tomorrow as well
<Hobbsee> enolaptophere
<slangasek> Tonio_: ok - I'll just leave the package alone for alpha-6 then
<Tonio_> slangasek: no problem :)
<Tonio_> 3:30 am and I have to wake up at 7...... and I'm still not done with the job :/
 * Hobbsee ponders actually doing some work
<Hobbsee> dear 'doze, please stop munging the formatting.  if you have to do so, at least be consistent!
<ScottK> slangasek: Due to the universe/main backport problem (db 4.6 this time) postfix backport in Gutsy also dep waits.  For that one I can trivially do a source backport to switch back to db4.3 (what the released postfix uses).  How about I do that instead of you messing with republishing it in Universe?
<Neon_lights> uhm, hi y'all. =] I'd just like to say thanks for all your work. <3
<TheMuso> 1/aw
<Hobbsee> wow, quiet
<TheMuso> //c
<TheMuso> Hrm. I just got some weird keyboard behavior, after updating, restarting, and logging back into GNOME.
<TheMuso> Using gedit, after a while when typing text, I started typing characters that appeared to be for another language...
<Hobbsee> it's the start of text-input-via-brainwaves.  Stop thinking in other languages.
<TheMuso> Hrm something appears to be broken, even on a fresh hardy install, using en_AU.UTF-8 locale, with a US layout.
 * TheMuso updates from a.u.c to be sure.
<RAOF> TheMuso: Have you been accidentally hitting shift-space?  That brings up some scim dialog which then eats a keypress & switches languages.
<StevenK> One of my ex-workmates used to run SCIM on his machine so he could type Japanese, and the amount of times I'd accidently hit shift-space suprised me a lot.
<RAOF> Go _away_, scim-bridge!
<ScottK> Good night all.
<slangasek> ScottK: sounds fine to me... :)
<slangasek> Riddell: hummm, you verified network-manager-kde still works before uploading it, right?  It's been rebuilt against the new upstream version of libnl now, and I'm in the midst of rerolling alpha-6 images
<asac> slangasek: all fine now for nm?
<asac> -gnome didn't need an update to still work ... why does -kde need it?
<slangasek> asac: ah, I assume it's fine now, because no one's told me about (or milestoned) any bugs saying it's broken
<slangasek> asac: -kde didn't need an update to work, it /got/ an update for something else and as a result picked up libnl1
<asac> slangasek: yeah. we shouldn't need it
<slangasek> so I have no idea if the old -kde works ok with the new libnl
<asac> slangasek: it should. i don't think it uses libnl on its own (at least i cannot see it in Depends: of my apt-cache)
<asac> anyway, theoretical questions ;)
<slangasek> it does depend on libnl
<slangasek> Package: network-manager-kde
<slangasek> Depends: [...] libnl1-pre6
<asac> oh really. what a messy thing. it should interact with nm and not libnl
<asac> if its fixed. fine
<warp10> Good morning
<slangasek> "theoretical questions" - these kind of questions are part of why you freeze before milestones...
<dholbach> good morning
<asac> i ment theoretical because you said that it works now.
<slangasek> er?
<slangasek> I have no idea if network-manager-kde works
<slangasek> I have no idea if it's been tested at all
<asac> slangasek: wfm
<slangasek> ok
<slangasek> well, images are posted then - now we just need to get people testing them... :)
<asac> slangasek: where? its likely that i get a new notebook any minute. could use that to test ;)
<StevenK> asac: Ooh. What's due?
<asac> standard lenovo thing 12''
<tjaalton> asac: X300?-)
<asac> not yet :(
<tjaalton> dang :)
<stgraber> moin
<slangasek> asac: http://iso.qa.ubuntu.com/qatracker/build/all
<pitti> Good morning
<asac> hi pitti
<pitti> slangasek: waiting for ack> the hal FF
<pitti> ah, I think I know why my keyboard is all broken for a few days
 * pitti blames scim
<pitti> martin   11958  0.0  0.0      0     0 ?        Z    08:40   0:00 [scim] <defunct>
<pitti> bah
<stgraber> pitti: any idea why gnome-power-manager always show 100% (Current rate and Design rate stay at 0 :( ) ? I tried with the new hal, reseted my gnome-power-manager settings and gconf, ...
<stgraber> my next try will be to test with alpha-6's livecd (downloading now)
<pitti> why do we install scim by default now for European languages?
<pitti> seb128: ^ that might be one reason why the keyboard switch applet doesn't work any more?
<seb128> pitti: I've no clue about scim so not sure
<slangasek> stgraber: what kernel version?
<pitti> ArneGoetje: why do we install scim by default now for European languages?
<stgraber> slangasek: 2.6.24-11-generic on amd64 (HP Compaq nx7400)
<slangasek> stgraber: ok, no idea then :)
<slangasek> I was having g-p-m issues before the last time I restarted; don't know if those were kernel or hal though
<stgraber> that's weird because it correctly detects manufacturer, technology and the charge rate but is unable to give me the charge status (stuck at 100% all time)
<ArneGoetje> pitti: this is because of update-alternatives... it is called by scim to set the preferred modules.. and that one automatically enables scim for all_ALL
<ArneGoetje> pitti: we need to call 'sudo im-switch -z all_ALL -s none' explicitely to disable it.
<slytherin> Hi all. I was wondering if we are planning to take advantage of the network manager's GSM capabilities (http://blogs.gnome.org/dcbw/2008/03/02/networkmanager-your-gsm-mobile-and-you/) by adding appropriate information to .fdi files.
<cjwatson> ArneGoetje: or we should change the alternative priorities in scim.postinst - update-alternatives is just doing what it's told :-)
 * seb128_ kicks network-manager dropping network on upgrade
<stgraber> hehe, mine did that while I was connected to the net over VPN :)
<ArneGoetje> cjwatson: exactly. but if we change the priority to none, scim will never work for non-cjk locales.
<ArneGoetje> cjwatson: the way it should interact with language-selector is: to disable scim, call 'sudo im-switch -z all_ALL -s none', to enable scim call: 'sudo im-switch -z all_ALL -a' (this sets it to automatic, which will use the priorities as they have been defined.
<ArneGoetje> cjwatson: if we want to disable scim by default for all_ALL, we need to call 'sudo im-switch -z all_ALL -s none' *after* scim _and_ im-switch have been installed.
<ArneGoetje> the reason why this behaviour has not been triggered before is simple: im-switch was not installed by default (which disabled scim altogether, not only for non-cjk locales).
<ArneGoetje> so, suggestion is: add im-switch to Pre-Depends in scim and call im-switch to disable it for all_ALL by default in scim.postinst after the priorities have been set.
<ArneGoetje> if this solution is acceptable, then I will change the scim package right away.
<cjwatson> ArneGoetje: is it desirable for scim to work for non-CJK locales?
<cjwatson> I suppose if you are in a German locale and writing Chinese
<ArneGoetje> cjwatson: yes.
<davmor2> is anyone else having issues with rsyncing the iso's from cdimages.ubuntu.com?  I keeps dying on me :(
<cjwatson> it just seems like a bit of an edge case, and caused confusion on #ubuntu-devel within hours of being activated
<cjwatson> I think it should be off by default
<cjwatson> and perhaps enableable in some GUI way
<ArneGoetje> cjwatson: basically any overseas CJK speakers and CJK language learners would want it to work for their locale.
<ArneGoetje> cjwatson: that's what language-selector is supposed to do.
<ArneGoetje> but this feature has not been properly implemented before. It was just not triggered, because im-switch only got installed when adding a CJK language pack.
<cjwatson> ok
<ArneGoetje> so, if my proposed solution is OK, I will change the scim package that way.
<ArneGoetje> so, comments please... I'm waiting :)
<mvo> ArneGoetje: I think the defaul for all_ALL should be to point to "none" in im-switch
<mvo> ArneGoetje: I think that is how it was back in ~dapper :)
<mvo> ArneGoetje: we then can use language-selector to turn it on. what do you think?
<ArneGoetje> mvo: but this would be overwritten by scim.postinst, won't it?
<mvo> ArneGoetje: hm, wouldn't it be enough to remove the "ua_inst all_ALL scim 0" from the scim postinst ? or modify it to point to "none" instead of scim?
<ArneGoetje> mvo: no. that would disable scim permanently for all_ALL. it would never work until you set another module with a higher priority for all_ALL
 * ogra doesnt understand, cant you start it on a per desktop/user base ? if so, why not use an /etc/xdg/autostart/ with a scrit wrapper that checks for a gconf key or so so the system wide stuff to globally enble the setup comes from postinst, but the .desktop file does the user related rest
<mvo> ArneGoetje: hm, my impression was that "im-switch -z all_ALL -s scim" overwrites that - we would use that in language-selector then to activate scim for all_ALL if the user wants it
<ArneGoetje> mvo: no. wrong.
<ArneGoetje> mvo: the command called by language-selector should be 'im-switch -z all_ALL -a'!
<ArneGoetje> mvo: this switches it into 'auto' mode, means it uses that module with the highest priority in u-a.
<mvo> ArneGoetje: but that would mean that we have to leave scim enabled otherwise -a will not pick it up
<mvo> (for all users, even those who are not interessted in it)
<ArneGoetje> mvo: the priorities are set by scim.postinst (scim-bridge 60, scim 50, scim-immodule 0). and this is used when set to 'auto' mode.
<ogra> mvo, see my comment above .... let scim be started by an xdg file and check the lang selector value during login if there is nothing requiring scim it wont be started
<ArneGoetje> mvo: to disable scim, use '-s none'. this forces scim to use 'none' instead of 'auto'
<mvo> ArneGoetje: if we do not want to have scim enabled for all_ALL  (that is what colin mentioned earlier), then were do we call '-s none'?
<ArneGoetje> mvo: if you use '-s scim' to enable scim, you will force the 'scim' module instead of 'auto'. means if the user prefers to use scim-bridge for example, it will be overwritten by language-selector... and we don't want that.
<ArneGoetje> mvo: if you uncheck the checkbox in language-selector, '-s none' should be called.
<mvo> ArneGoetje: I think we are talking past each other, the problem we want to solve is how to make all_ALL not enabled by default for everybody, right?
<mvo> (even with im-switch installed by default)
<ArneGoetje> mvo: I have proposed a solution a couple of pages up...
<mvo> ArneGoetje: "let language-selector" do it?
<ArneGoetje> 16:54 < ArneGoetje> so, suggestion is: add im-switch to Pre-Depends in scim and call im-switch to disable it for all_ALL by default in scim.postinst after the priorities have been set.
<mvo> aha, I think your wrote that before I logged in, sorry
<ArneGoetje> this way the default for all_ALL would be '-s none'. if the user want's scim, he can enable the checkbox in language-selector, which would call '-a' to set it to 'auto', which in turn uses the module with the highest priority...
<ArneGoetje> I have uploaded a new scim package to rookery (~arne/scim/), with these changes. So, if anyone wants to take a look, please go ahead.
<ArneGoetje> mvo: I have updated my l-s/arne branch last night. did you take a look already?
<mvo> making im-switch a pre-depend (its currently a recommends) sounds a bit drastic to me - I would prefer to make it the other way around (default none and explicitely enable it). but its your packages
<mvo> ArneGoetje: no, sorry. haven't looked at it yet
<ArneGoetje> mvo: the im-switch package does not set any defaults.
<mvo> right, I was thinking about changing them in scim
<ArneGoetje> mvo: but to set any defaults in sim.postinst, im-switch must have been installed already, otherwise the 'none' file doesn't exist and the symlink would fail!
<mvo> we also need to be sure that no tool runs "im-switch -a", otherwise we would get the (possible) unwanted side-effect of suddently having scim enabled for all users
<ArneGoetje> mvo: currently no package call '-a'
<mvo> ther eis currently a line:        ua_inst all_ALL scim  0
<mvo> in the scim.postinst
<mvo> it dosn't need im-switch, it just sets up alternative in /etc/X11/xinit/xinput.d/
<ArneGoetje> mvo: I suggest you do 'dpkg -L im-switch' and 'dpkg -L scim' and see which files get installed into /etc/X11/xinit/xinput.d/ by which package. I hope this makes it clear once and for all. :)
<ArneGoetje> mvo: further more, im-switch install /etc/X11/Xsession.d/80im-switch , which is needed to eanable the locale specific im-switch settings. Without it scim won't work at all, no matter what is set in u-a.
<cjwatson> ArneGoetje: (pre-depends is only needed if you're doing something in the preinst, or need something to be in place before the package is unpacked; it isn't needed for use in the postinst)
<cjwatson> ArneGoetje: (for the latter, plain depends is just fine)
<ArneGoetje> cjwatson: ok, will change that... hang on.
<cjwatson> ArneGoetje: it just seems weird to call im-switch explicitly when setting appropriate alternative priorities would have the same effect
<cjwatson> the default should be identical to what you get when everything is in auto mode
<xhaker> cjwatson: scim doesn't ship the profile 'none'. if it did, he could just u-a on the .postinst
<pitti> mvo: does compiz session management work for you? how do you save your session?
<xhaker> if i'm looking into this correctly. a solution would be to ship 'none' in scim, and remove it from im-switch
<mvo> pitti: yes, I had to modify gnome-session-properties to set it to "save session on logout"
<ArneGoetje> cjwatson: the user can decide which moule he wants to use by default by adjusting the priorities in u-a. The priorities set by scim.postinst is just a suggestion (and in our case the default setting). if we hardcode a specific module as default by givig it a higher priority when enabling the checkbox in l-s, we will setup those users which have tweaked the settings to their liking.
<pitti> mvo: ah, using 'gnome-session-save' or the button 'save now' in g-s-props doesn't work?
<pitti> mvo: (usually I just want to save it once)
<mvo> pitti: that should work too
<mvo> pitti: is it not for you?
<pitti> hm, I used the button last time
<pitti> with no effect
<mvo> pitti: you saved it when the new compiz (with session plugin) was on the system already
<mvo> ?
<pitti> yes, of course
<mvo> hmmm
<ArneGoetje> cjwatson: that's why I suggest we don't touch the priorities for 'auto' mode and just toggle scim on/off by setting im-switch to -a (== on) or -s none (== off)
<pitti> mvo:how do I tell if the plugin is enabled?
<mvo> pitti: ccsm will tell you, I set it to enabled by default so if you haven't modified your plugins then it should be on
<mvo> pitti: its called "session" (surprise :) in ccsm
 * pitti boots laptop and installs ccsm
<cjwatson> ArneGoetje: "the user can decide which moule he wants to use by default by adjusting the priorities in u-a." that's not the way update-alternatives works
<ArneGoetje> cjwatson: then how should it work?
<cjwatson> ArneGoetje: the package sets priorities, the highest of which is the default; the user may override by picking a single one manually, not by changing the priorities
<cjwatson> ArneGoetje: the priorities should always be set by us to represent what we think should be the default
<mvo> ogra: about your suggestion, currently langauge-selector runs as root (yes :( and this is why we can't set per-user settings. something we should fix for hardy+1
<cjwatson> ArneGoetje: it doesn't make sense to have this complicated system of priorities and then have the package override it at the end
<ogra> mvo, i'm planning a spec to get rid of all unused background porcesses for prague
<ogra> we waste a ton of ressources with crap we start but the user will never need, that should be fixed imho
<ArneGoetje> cjwatson: then how would we enable scim by checking the checkbox in l-s? which module should be used by default? and why should we force to run 'im-switch -s $his_preferred_module' every time after he enabled the checkbox in l-s?
<ArneGoetje> force the user...
<cjwatson> ArneGoetje: checking the checkbox in l-s could select the next one down in priority order that isn't 'none' or 'default', I guess
<cjwatson> certainly the user should not have to run some other command by hand as well as using l-s
<mvo> ogra: what are those?
<ArneGoetje> cjwatson: that's the same bastardized usage of im-switch as I proposed just the other way round.
<cjwatson> ArneGoetje: in a multi-user environment where multiple users may have different locales, we simply can't use im-switch in the postinst sanely
<pitti> mvo: ccsm> is that the simple-ccsm package?
<cjwatson> im-switch has to be a per-user thing
<mvo> pitti: if you install simple-ccsm it will get pulled in (as a dependency)
<ogra> mvo, example: enabling bluetooth even if we dont have the HW etc ... its jut silly, we have udev that can detect hotplugged bluetooth HW so we can switch it on the fly if needed and dont need to start a system service for it all the time
<ogra> (if there is no such HW on boot)
<ogra> many things could benefit from better automation here
<mvo> ogra: yeah, same for some hplip stuff I guess (not sure if this is still running)
<ArneGoetje> cjwatson: in that case we wouldn'e be able to use l-s either, because that one changes the settings system wide.
<cjwatson> although I guess that using the -z switch to im-switch makes that less of a problem
<ogra> if i see the classmate dektop where i actually can get a workable gnome then i also see that 80% og the stuff i have runniong by default is useless in this HW
<ogra> and the wasted ram is not in a kilobyte range rather tens of MB
<ArneGoetje> cjwatson: if im-switch is called in a user environment it will overwrite the system settings anyways.
<cjwatson> which is how it should be
<ArneGoetje> cjwatson: we are talking about running im-switch as root
<cjwatson> I understand that, yes
<cjwatson> certainly, language-selector is conflating system-wide configuration (installing packages) and user configuration (enabling input method support)
<cjwatson> so eventually it probably ought to use policykit to escalate privileges just for the system-wide bit
<mvo> cjwatson: yes, absolutely
<cjwatson> but I doubt that'll happen for hardy now, unless mvo has a trick up his sleeve
<ArneGoetje> cjwatson: yes. and that enabling input method support uses im-switch as root to set sane defaults.
<pitti> mvo: installed, called ccsm, it immediately crashes on me :/
<cjwatson> which is a mistake, because it means that me playing around with input methods forces them on my wife using the same computer
<mvo> cjwatson: its not too much work to port it so that it runs as the user, but there is little time :/
<mvo> pitti: what is the backtrace?
<pitti> mvo: "import ccm" -> 'No module named ccm'
<pitti> mvo: simple-ccsm, line 31
<ogra> ArneGoetje, btw, do you have any insight how the new hal input methods will influence the scim stuff ? with intrepid we're likely to switch over to that
<mvo> pitti: *sigh* I thought that got fixed a couple of days ago, let me check. please install compizconfig-settings-manager
<pitti> ok
<ArneGoetje> ogra: I have no idea about hal and I doubt that sci will support it.
<pitti> mvo: it's supposed to be 'import ccsm' by chance?
<ogra> ArneGoetje, its likely that xorg will need it
<pitti> mvo: hm, no
<mvo> pitti: no, the library is provided by compizconfig-settings-manager, simple-ccsm makes use of it, its a missing dependency
<ogra> ArneGoetje, it will switch to no config by default and rely on hal for everything (mice keyboards and layouts)
<pitti> mvo: ah, that did it
<cjwatson> ogra: scim is at a higher level
<ogra> ArneGoetje, so its likely to massively influence scim
<ogra> cjwatson, right
<pitti> mvo: I don't see anythign session-like there?
<cjwatson> ogra: switching to hal shouldn't affect scim
<ArneGoetje> ogra: then it will probably not be possible anymore to use scim.
<cjwatson> ArneGoetje: I don't think that's true - it just changes how xkb is configured
<ogra> i think it changes other stuff as well
 * cjwatson puts up a big "DON'T PANIC" sign
<ArneGoetje> cjwatson: ok, then it should not be an issue indeed
<ogra> anyway, nothing for hardy
<ogra> i just dont want us to have somjething in the LTS thats probably not supportable later anymore ... would be good to have an idea about it in advance
<cjwatson> ArneGoetje: anyway, don't let the debate about u-a priorities vs. calling im-switch stop you fixing the basic problem - if you feel it has to be by calling im-switch then your call
<mvo> pitti: checking
<mvo> pitti: I have it here in 0.6.99+git20080228-0ubuntu1 (plugins-main) as libsession.so, is that available in your package too?
<ArneGoetje> cjwatson: the point is that the priorities are set and modified by any IM package which supports im-switch, not only scim. For example, nabi and gcin also set priorities in u-a. So, IMHO the best way would be to leave the priorities alone and use 'none' as explicit default and 'auto' when the user enables the checkbox in l-s (which is a system wide setting by design). if the user runs im-switch in a console he will overwrite the whole thing 
<ArneGoetje> cjwatson: so, on a multi-user system the best way would be to leave scim disabled in l-s and use the im-switch command on a per user base to set the preferred module or 'auto' if the defaults sound sane to the user.
<pitti> mvo: I mean, in simple-ccsm I only see  "info", animations, effects, workspaces, and a11y
<pitti> mvo: I do have libsession.so, yes
<mvo> pitti: aha, sorry. please run "ccsm" instead of "simple-ccsm"
<ArneGoetje> I re-uploaded the scim package to rookery BTW.
<pitti> mvo: ah, it's there and enabled
<pitti> mvo: 'save legacy apps' is off, but the plugin is on
<pitti> mvo: but gnome-terminal is hardly a legacy app?
<mvo> pitti: no, g-t is saved just fine for me
<pitti> mvo: trying with the 'save on quit' checkbox now
<mvo> pitti: thanks
<pitti> erk, WTH was that; the login sound was dramatically bouncing
<pitti> mvo: it looks differnetly disturbed, but still not correct
<pitti> mvo: the multi-tab terminal had the wrong size, and all terminals have wrong position
<mvo> pitti: so the apps are not restored at the right place?
<pitti> at least the workspace is correct
<mvo> pitti: totally random or just a couple of pixels off?
<pitti> couple of pixels
<pitti> maybe 30 or 50
<pitti> my terminal with mutt on 3rd workspace was sticking on the screen bottom instead of being at the top
<mvo> ArneGoetje: I think this discussion made it clear that language-selector should run as per-user, this would solve most of the problems as I understand it. I will have a look into the code now to see how much work it is
 * mvo considers the current behavior a bug
<ArneGoetje> mvo: yes
<pitti> mvo: how do you install langpacks then?
<Nafallo> make apt-get suexec *hides*
<mvo> pitti: hm, I wonder if it somehow confuses the decoration when it calculates the sizes
<ArneGoetje> mvo: at least for the 'default system locale' and 'enable/disbale complex character input'. language packs and -support need to be instaled by root anyways
<mvo> pitti: it will run synaptic as backend with gksu, that should be fine
<pitti> mvo: the size of the 'no tabs' terminals was correct; the terminal size with two tabs was totally off
<ArneGoetje> mvo: maybe two modes for these two settings. User and Admin... Admin sets system defaults.
<\sh> bah
<\sh> how can I disable this damn scim module which is running now by default
<Sebastian> \sh: Hey Stephan :)
<ogra> \sh, apt-get remove scim
<mvo> ArneGoetje: not for hardy, if I port it, it will look exactly the same (UI freeze), it will just setup stuff like input methods per-user instead of system-wide
<ogra> or so
<ArneGoetje> \sh: sudo im-switch -z all_ALL -s none
<ogra> better :)
<mvo> ArneGoetje: sorry for that, we can do better for hardy+1
<ArneGoetje> mvo: yeah
<\sh> Sebastian: hey...what a surprise :) What gives us the pleasure of your Visit? Not zend-framework, right? :)
<Sebastian> \sh: No :) Just started lurking here after I have been lurking for a couple of months in #ubuntu+1.
<Sebastian> \sh: Maybe I should create eZ Components packages at some point.
<\sh> Sebastian: That would be great :) Cool that you joined the Ubuntu Force :)
<Sebastian> \sh: I'm still just a user. Although a very happy one.
<\sh> ArneGoetje: thx :)
<\sh> ArneGoetje: na that didn't work
<Sebastian> \sh: It did for me.
<ArneGoetje> \sh: need to re-login
<\sh> ArneGoetje: ah that's the magic
<\sh> Sebastian: still in siegburg area? :)
<Sebastian> \sh: Yes. And today I am actually at home.
<Sebastian> \sh: Been in Zurich and Munich the last week and leaving for Montreal tomorrow.
<Sebastian> \sh: And after Montreal I will be near Berlin for a week.
<davmor2> \sh: Wine works great thanks :)  I can do my course stuff now :)
<\sh> davmor2: good to hear :)
<Sebastian> \sh: You're with Webzooms now? I had a coaching/training gig there last year.
<\sh> Sebastian: I heard about that :) And the people here were surprised, that I already knew you :)
<Sebastian> \sh: hehe
<Sebastian> Uh, the PHPUnit package is outdated. Maybe I should start by fixing that before getting into new packages.
<\sh> Sebastian: I'm happy to sponsor :)
<Sebastian> Ah, cool.
<\sh> Sebastian: just join #ubuntu-motu :) the coolest crew in the world :)
<emgent> heya
<PecisDarbs_> Where is hidden messages in gksu dialogs? I can't find which module I should translate
<xivulon> mjg59, do you remember the suspend to ram issues in loopinstallations (fuse)? Well have 2 users reporting they can now suspend!
<xivulon> not sure what happened there but, I am very pleased
<xivulon> I won't be able to test that myself until tonight though
<ogra_cmpc> xivulon, whats the base device under the loop mount ?
<ogra_cmpc> the normal windows HD ?
<xivulon> guess so, ntfs in both cases, will ask about disk specs
 * ogra_cmpc wonders if amitk already added the usb presistent patch 
<ogra_cmpc> xivulon, ah, thats something different than what i am waiting for
<ogra_cmpc> i thought i missed a change
<xivulon> what is your issue?
<ogra_cmpc> i have an usb jey as  bottom device ...
<ogra_cmpc> *key
<ogra_cmpc> they get automatically powered down by the kernel on suspend
<xivulon> in my case it was problems suspending when root was in a loopfile on top of an ntfs host (i.e. the host device was mounted using fuse)
<ogra_cmpc> if you resume your device is gone
<xivulon> looks nasty
<ogra_cmpc> it is
<xivulon> by the way, I'd assume that hibernation does not work with swap on file, correct?
<ogra_cmpc> but the function is in the kernel, we just dont enable it ... i'm waiting for a commandlne option to be added to switch it on dynamically
<xivulon> Also did anyone follow up this story about loopdevice performance: http://lkml.org/lkml/2008/1/9/50 ?
<xivulon> Any hope to see any of that in the kernel?
<amitk> ogra_cmpc: no patch, only configuration. But no, I haven't finished that task yet. SOON (tm) :)
<Bashtoni> cjwatson: That issue with installation on RAID still happens even with the new 'fixed' installer BTW (#198106)
<ogra_cmpc> amitk, yeah, i'm monitoring the changelogs, was just wondering if i missed it whn i saw xivulon's comment
<cjwatson> Bashtoni: please file a new bug with /var/log/syslog and /var/log/partman attached
<Bashtoni> cjwatson: Will do
<cjwatson> Bashtoni: I'll fix the non-executable thing mentioned in the bug
<cjwatson> that's probably a side-effect of a subversion import bug we fixed YEARS ago
<cjwatson> aggravating
<Bashtoni> cjwatson: https://bugs.launchpad.net/ubuntu/+source/partman-target/+bug/199095
<ubotu> Launchpad bug 199095 in partman-target "RAID1 installation fails" [Undecided,New]
<cjwatson> Bashtoni: thanks; would you be able to do some interactive debugging with me?
<cjwatson> Bashtoni: (give me a few minutes to prepare, though
<cjwatson> )
<Bashtoni> cjwatson: Can do in a bit, say 2pm GMT?
<cjwatson> Bashtoni: ok
<cjwatson> Bashtoni: hop onto #ubuntu-installer when you're ready
<Bashtoni> cjwatson: OK, see you then
<slytherin> Hi all. Does anyone know why the CD images for 'ports' (powerpc, sparc etc) have not been built today?
<cjwatson> slytherin: all CD builds are disabled in preparation for alpha 6
<pitti> slytherin: they are currently triggered manually; just hasn't been triggered for ports, I assume
<slytherin> pitti: So whom should I bug for this? Because ports images are one day older than the officially supported architectures. And IMHO, latest GVFS and nautilus checkins call for latest CD.
<cjwatson> slytherin: Ubuntu ports building now
<cjwatson> though they might be a bit broken due to partman pain
<slytherin> cjwatson: Thanks. :-) What partman pain by the way?
<cjwatson> non-executable files due to an ancient svn->bzr import bug
<cjwatson> (fixed years ago, but its effects linger)
<slytherin> cjwatson: Ok. by the way partman doesn't support HFS+ resizing. Is it know and is there any work going on for this?
<cjwatson> slytherin: should work if you disable the journal
<cjwatson> slytherin: just lack of support in parted, IIRC; I don't know if anyone's working on it
<slytherin> cjwatson: Not sure what that means exactly. But if I try to resize when using Alternative CD it simply says 'HFS+ resizing is not supported'
<slytherin> I am assuming that the partition manager is 'partman' in alternate CD.
<cjwatson> slytherin: yes. partman uses parted.
<cjwatson> slytherin: google for 'hfs+ resize parted', first hit relevant
<slytherin> Ok. thanks.
<dholbach> can somebody moderate my mail to ubuntu-devel-announce?
<cjwatson> dholbach: done
<dholbach> cjwatson: gracias
 * ogra_ waits for the next iteration from dholbach ... really_fix_five_a_day :P
 * dholbach waits for ogra_ to join 5-a-day :)
<cjwatson> Bashtoni: I think I've got it, actually
<Bashtoni> cjwatson: Just in time for me to return from lunch :)
<Bashtoni> cjwatson: Let me know if you want me to test
<cjwatson> Bashtoni: sure, wouldn't hurt
<cjwatson> Bashtoni: #ubuntu-installer?
<slytherin> How can I add upstream bug watch for vunagre?
<slytherin> vinagre?
<TomaszD> seb128, hi, I've assigned you to a gvfs bug as I've noticed you do the heavylifting for gvfs in Ubuntu. This bug has been fixed in svn trunk and it would be really nice to have it synced https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/196770/
<ubotu> Launchpad bug 196770 in gvfs "Nautilus with gvfs-obexftp breaks on colons" [Low,Confirmed]
<seb128> TomaszD: please don't assign bugs, I'm subscribed to gvfs and look at those without that
<seb128> TomaszD: I'll do a new svn snapshot when the freeze is over
<TomaszD> seb128, ok, didn't know that.
<TomaszD> seb128, thanks
<seb128> you are welcome
<sivang> hi all
<sivang> I'm trying to figure how to set up usplash on a debian box, where would be the right channel to ask abou this?
<sivang> (I'm using the debian etch package)
<lamont> dear apt.  please accept 'udpate' as valid.  kthx.
 * ScottK has often needed dkpg
<soren> dear apt. please provide and apt-ge alias for yourself and accept tinstall. kthx
<soren> dear soren. please spell properly. kthx
<ion_> % apt-ge tinstall
<ion_> zsh: correct 'apt-ge' to 'apt-get' [nyae]? y
<ion_> Unfortunately, it doesnât correct tinstall.
<ogra_cmpc> soren, just remove the spacebar from your keyboard and improve tab completion
<ion_> The tab completion already manages to do apt-get install without hitting the space bar.
<ogra_cmpc> right, but you would surely waqnt other apps to do that as well without spacebar ;)
<sivang> is there anyone here who knows a thing or two about usplash ? (hi again to all :) )
<sivang> feel free to privmsg me if you will, I would appreciate for some pinpointed help re using it without ramfs (it seems to be hard coded to use certain directories under the ramfs)
<pitti> sivang: no, you can run it under the normal system just fine
 * sivang hugs pitti
<sivang> pitti: are you sure?
<sivang> pitti: I'm getting chdir errors when executing usplash
<pitti> usplash -c &
<sivang> pitti: and the directories listed in usplash.h are not existent
<pitti> usplash_write "TEXT-URGENT hello"; sleep 2; usplash_write QUIT
<pitti> weird
 * sivang tries
<pitti> WFM
<sivang> pitti: I'm not using a ramfs so I don't have the .initramfs entry under dev
<pitti> ah
<pitti> that might be it
<sivang> I think so :)
<pitti> it uses /dev/.initramfs/usplash_outfifo for communication
<sivang> right, can I just use any other dirs I like in the usplash.h file and rebuild with my setup ?
<pitti> but you at least need usplash_fifo for usplash_write to work
<pitti> sivang: yes, as long as you also use the rebuilt usplash_write, that should work
<sivang> pitti: okay, cool, I will try this dude, then is there something comprehensive that automatically sends all regular boot scripts output from stdout to the usplash fifo ?
<sivang> pitti: or do I need to write something to do that myself if I want to get the init scripts output directed to the usplash screen ?
<pitti> sivang: yes, that's done in the usplash implementation of /lib/lsb/init-functions
<pitti> (in /etc/lsb-base-logging.sh to be precise)
<pitti> that turns lsb_daemon_msg et al into usplash_write
<sivang> very cool
<sivang> so that's supposed to work out of the box once recompiled with the correct and existing directory entries
<sivang> cool
<slytherin> how can I add upstream bug watch for vinagre?
<seb128> slytherin: add on the also affects project under the table
<seb128> click
<slytherin> seb128: It gives this message -  Please select the appropriate upstream project. This step can be avoided by updating the packaging information for vinagre (Ubuntu).
<seb128> slytherin: you need to register a vinagre product if there is none in launchpad yet
<slytherin> seb128: vinagre is hosted on gnome project. do I still have to add vinagre product on launchpad?
<seb128> slytherin: yes
<slytherin> ok
<seb128> slytherin: that is annoying I agree, but launchpad needs to know what bug tracker, svn etc to use
<ScottK> seb128: Which it used to be able to figure out from simply asking for a url.
<slytherin> I thought It was possible to simply give the upstream bug url and it will fetch information
<ScottK> It used to be.
<ScottK> It's been improved.
<slytherin> ScottK: So how does it work now?
 * ScottK is not the guy to answer launchpad how to questions.
 * ScottK is unable to answer them without excessive editorialization that isn't always fully consistent with the CoC.
 * slytherin joins #launchpad
<davmor2> cjwatson: ping
<cjwatson> davmor2: yes?
<davmor2> cjwatson: on the wiki for alpha 6 Printing from Firefox 3 is now fixed.
<cjwatson> davmor2: how come the bug's only fix-committed?
<davmor2> cjwatson: No idea I've been able to for a few days after the last big set of updates.
<cjwatson> asac: ^-- could you comment?
<davmor2> cjwatson: all the images are being displayed properly too so I think that got fix at the same time :)
<xivulon> Riddell: is there a different logo for Kubuntu-KDE4 vs KDE3.5?
<Riddell> Kubuntu-KDE4 and Kubuntu normal have the same logo
<xivulon> was asking in the umenu/wubi context, nothing to change then I assume
<tseliot> Riddell: is there a way to detect whether a user is running kde4 or kde3 (with "ps" maybe)?
<Riddell> xivulon: no just the one logo is fine thanks
<Riddell> tseliot: you can check for plasma (KDE 4) against kdesktop (KDE 3) I guess
<Riddell> tseliot: why?
<tseliot> Riddell: I'm writing a pyQT4 interface for EnvyNG and I would like to launch it either with kdesudo or kdesudo-kde4
<tseliot> according to the environment
<tseliot> Riddell: does my need make any sense to you?
<tseliot> Riddell: or should I just use kdesudo (also on KDE 4)?
<Riddell> tseliot: a kde 4 session will have $PATH set so it should just find the right kdesudo
<tseliot> Riddell: ok, thanks. Things are a bit clearer now
<Riddell> tseliot: remind me again what envyng is?
<tseliot> Riddell: EnvyNG is a program which builds and installs the latest ATI and/or NVIDIA driver
<Chipzz> Riddell: envy is a way of installing nvidia drivers
<Riddell> right
<ogra_cmpc> Riddell, you clearly dont have enough spare time ...
<Chipzz> totally broken idea IMO
<ogra_cmpc> Riddell, info about envyng is hidden on planet.ubuntu.com ;)
<tseliot> Chipzz: it's no longer such
<Riddell> ogra_cmpc: can I have some of yours?
<ogra_cmpc> haha
<seb128> pitti: bug #116984 seems to be one of the avahi bug example
<ubotu> Launchpad bug 116984 in avahi "Applications can't connect to avahi-daemon until avahi is restarted once." [Undecided,New] https://launchpad.net/bugs/116984
<Chipzz> tseliot: nvidia drivers should be installed using your package manager, not through some gross hack
<Chipzz> but that's just my opinion
<seb128> pitti: the process is stucked on registering until avahi is restarted
<tseliot> Chipzz: have a look at this page: https://wiki.ubuntu.com/EnvyNG
<Amaranth> yeah, envyng seems pretty sane now
<Amaranth> well, as sane as installing a new binary blob can be, they're always breaking something
<tseliot> Amaranth: yes, I prefer free drivers too...
<Amaranth> tseliot: I wouldn't mind these drivers if new versions didn't drop support for an older card or break something basically every release
<tseliot> Amaranth: if the vendor decides to drop the support for your card there's nothing you can do (if the driver i proprietary)
<Amaranth> right
<tseliot> Amaranth: this is why I chose an Intel card for my laptop ;)
<Amaranth> I am not complaining, I'm just saying EnvyNG can't be any safer than the driver it is installing
<asac> cjwatson: davmor2: its fixed upstream; beta 4 will ship the fix
<cjwatson> davmor2: perhaps it worked for you by accident?
<tseliot> Amaranth: you're right
<Amaranth> Which is why it can still be dangerous
<emgent> heya
<davmor2> cjwatson: Ah okay.
<asac> davmor2: we have beta4pre builds in PPA if you want to test
<tseliot> Amaranth: Ubuntu's l-r-m are always available
<davmor2> asac: maybe latter try to get through the iso's at the moment :)
<pitti> seb128: re
<seb128> pitti: wb ;-)
<pitti> seb128: hm, as a first thing I'd attach grep avahi /var/log/daemon.log after this happens
<pitti> seb128: and the ps aux|grep avahi output, too, I think (it mentions its state there)
<seb128> pitti: that's where I get the registering
<seb128> $ ps ax | grep avahi
<seb128>  5587 ?        Ss     0:00 avahi-daemon: registering [seb128-desktop.local]
<pitti> mvo: tzdata is built everywhere, FYI (for bug 198129)
<ubotu> Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129
<pitti> seb128: ah
<seb128> pitti: what is the prefered media to file bugs for avahi? their tracker? or rather the mailing list?
<pitti> seb128: not sure, but the tracker worked for me in the past
<pitti> seb128: I pinged Lennart, he's not online yet, though
<seb128> pitti: ok, let me know what he replies so I can file the bug with useful informations
<pitti> seb128: I think you should add ps and daemon.log for now
<pitti> then I'll hand him the URL
<seb128> pitti: ok, will open a bug for those if I figure how the weird bug tracker is working
<pitti> seb128: ah, talking to Lennart now
<pitti> (with some troubles, pidgin otr makes his pidgin segfault)
<sivang> pitti: hey again, it worked, ths time usplash is working as expected, however, now I get a theme related error "no usable theme for 1024x768"
<sivang> pitti: any idea how I fix that?
<sivang> pitti: (it was really a path problem and changing stuff in usplash.h solved it)
<pitti> seb128: can you gdb attach to it and get a bt?
<pitti> seb128: possibly with -dbgsym?
 * sivang hugs dholbach
<pitti> seb128: hm, do you have ubuntu-artwork installed?
<pitti> seb128: also, can you change the init script to start the daemon with --debug? this would get it to the syslog
<seb128> pitti: sure, doing that in a minute
<pitti> seb128: can you /j #avahi?
<seb128> pitti: sure
<seb128> pitti: http://people.ubuntu.com/~seb128/avahi/ has a debug bt and the syslog not debug
<ogra_> hrm
<ogra_> is my DNS setup wonky or did google just drop off the face of the earth ?
<afflux> ogra_: it's the deutsche telekom
<jeromeg> ogra_: the second option is unlikely to be the good one ;)
<ogra_> afflux, merci :)
<afflux> ogra_: and it doesn't seem to be only the dns, since connecting to the IP directly doesn't work either
<ogra_> ah
 * ogra_ is on a business line, i would have thought thats handled through different routes
<ogra_> silly telecom :)
 * dholbach hugs sivang back
<lamont> " Hmm.. this change is not backwardly compatible for 0.0001% of agetty users :-) Applied with small changes.:"
<seb128> pitti: do you co maintain avahi somewhere or can I just do some changes to it?
<pitti> seb128: I'm not a Debian uploader
<pitti> seb128: so I can do the change in Ubuntu, or you do it now if you want
<seb128> pitti: ok, will do the change then, thanks for pinging upstream etc ;-)
<pitti> you're welcome
<crevette> hey
<Keybuk> so, err
<Keybuk> I have a laptop
<Keybuk> it won't let the external display use more than 1024x768 because that's all it knows
<Keybuk> if I add a 1600x1200 mode, it lists it in xrandr
<Keybuk> but won't set it because the virtual screen size is too small
<Keybuk> xrandr -s 1600x1200 doesn't work, it says that the mode doesn't exist (?)
<Amaranth> Keybuk: did you set your VirtualSize in xorg.conf?
<Amaranth> You need to preset the maximize size you'll need, X can't resize the framebuffer
<pitti> seb128: re automount_enabled_hint, I do have that to 'false' on my internal hard disks; you don't?
<seb128> pitti: I've it for the disks but not the partitions
<pitti> seb128: that's correct
<seb128> pitti: why?
<pitti> seb128: ok, I'll look after fixing this, shall I?
<pitti> seb128: well, that's how it is defined
<seb128> pitti: are you looking at the gvfs issue?
<pitti> http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-storage
<pitti> seb128: yes, just checked the code
<pitti> it does check volume.ignore, but not storage.automount_enabled_hint
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=520736 btw
<ubotu> Gnome bug 520736 in hal volume monitor "should not automount system partitions" [Normal,Unconfirmed]
<pitti> seb128: ah, merci
<seb128> de rien ;-)
<pitti> ah, it's because I once agreed to keep org.freedesktop.hal.storage.mount-fixed forever
<pitti> that's why it doesn't ask me for my password any more
<Keybuk> Amaranth: can I do that live?
<Keybuk> my own laptop has a different 1280x1280 max size
<Amaranth> Keybuk: nope, have to restart X
<Amaranth> If you could do it live you wouldn't have to worry about it at all, it would just do it
<Keybuk> Amaranth: so where does what go?
<Amaranth> in your Screen section, iirc
<Amaranth> VirtualSize width height
<Keybuk> width height not widthxheight?
<Amaranth> Keybuk: right
<Amaranth> oh, wait
<Amaranth> Keybuk: Section "Screen", Subsection "Display", the option is Virtual width height
<Keybuk> Amaranth: in hardy, without anything in xorg.conf ... it still seems to maximum limit to 1024x768
<Keybuk> (one assumes the limit is panel size)
<Keybuk> that's a bit silly
<Keybuk> since we don't even have mode lines there
<Amaranth> right, the default Virtual size is the starting resolution
<Amaranth> to be able to get a larger resolution than the starting one you need to predefine it
<Keybuk> why?
<Keybuk> why can't it just pick the biggest possible size?
<Amaranth> Keybuk: because X can't resize the framebuffer
<Amaranth> you think it should just make a 4096x4096 framebuffer for everyone whether you need it or not?
<Keybuk> sure
<Keybuk> otherwise when they plug in to their big TV, monitor or projector ... they're limited to 1024x768
<Keybuk> without xorg.conf surgery
<Amaranth> talk to bryce and/or tjaalton then :P
<Keybuk> tjaalton, bryce ^ :-)
<Amaranth> I want no part in that hackery :P
<keescook> mornin'
<Keybuk> Amaranth: do you know think that limiting the external monitor size to the panel size, when the primary reason for *having* an external monitor is more resolution, is a bit ... wrong? :p
<Amaranth> Keybuk: Oh, I agree it should be fixed
<Amaranth> I just don't want Xorg people to come stab me
<Keybuk> well, if they'd designed X right 40 years ago ... <g>
<tjaalton> Keybuk: there are hardware limitations too.. some intel chips can only do 2048x2048
<tjaalton> but I'm not sure what would be needed to make the max size default
<tjaalton> bryce is more uptodate with this stuff :)
<Keybuk> tjaalton: mine seems to only do 2048x2048
<Keybuk> and even when plugged into a projector capable of 1600x1200 doesn't recognise that (even with Virtual 2048 2048)
<Keybuk> and has to have the modeline manually added with --newmode and --addmode before I can use it
<jdstrand> hi pitti!
<tjaalton> Keybuk: yes, TTM et al should help getting past the limitations
<jdstrand> pitti, keescook: is there a way to easily find what packages use a shared orig.tar.gz?
 * keescook ponders
<keescook> jdstrand: I don't think so -- all my thoughts end up processing the Packages files with grep-dctrl and the like
<jdstrand> keescook: ok, np
<Keybuk> jdstrand: yeah, I hear that Apache 3.0 is blocked on TTM now too :-/
<Amaranth> tjaalton: but TTM will just make it possible to have a framebuffer per output, still can't have my wall-sized monitor :)
<jdstrand> hmm... TTM...
 * jdstrand scratches his head
<tjaalton> Amaranth: hmm, ok could be that I'm just confused.. not the first time
<Amaranth> tjaalton: it'll make it possible to have larger multi monitor setups
<Amaranth> one framebuffer per monitor
<zdzichu_1> intel i945 and lower have *3D* limitation to 2k x 2k
<Amaranth> i was being funny :)
<tjaalton> Amaranth: oh right, that's what it was :)
<zdzichu_1> i965 has 8k x 8x
<Amaranth> zdzichu_1: I'm pretty sure the 965 is 4096x4096
<Amaranth> zdzichu_1: and that is framebuffer size too
<zdzichu_1> sorry, I may be wrong, I have i945
<zdzichu_1> but still, it's 3D limitation only. 2D will work with appropiate sized "Virtual" in xorg.conf
<Keybuk> is there any sane reason why you'd never use the maximum size possible there?
<zdzichu_1> memory constrain. buffer is preallocated
<zdzichu_1> (still, if I understand correctly)
<Keybuk> yes, but any reason you wouldn't use the maximum size possible for your video memory?
 * Keybuk heads for the train
<tjaalton> gah, shift-space seems to toggle scim
<\sh> tjaalton: sudo im-switch -z all_ALL -s none and relogin
<Amaranth> I was typing in Amharic earlier thanks to that
<\sh> grmpf...fighting with virtualbox and gutsy...somehow it stops at nic-firmware udeb
<\sh> hmm..acpi=off helped
<\sh> or didn't
<tjaalton> \sh: hmm, thanks.. I'll see if I can live with it for awhile first :)
<tjaalton> Amaranth: yeah, nice default :)
<zul> slangasek: ping does samba need a ffe when its a merge from debian?
<stgraber> _MMA_: ping
<\sh> ogra_cmpc: can you take care about bug #197261 ?:)
<ubotu> Launchpad bug 197261 in xaos "please merge xaos 3.2-7 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/197261
<slangasek> TheMuso, persia, joejaxx: looks like there are no ISO tests for Ubuntu Studio yet?
<slangasek> zul: it needs a FFe whenever it includes significant changes that aren't bugfixes; I don't recall off-hand whether this is the case for the most recent Debian Samba upload
<zul> slangasek: ok thanks
<stgraber> ogra_cmpc: I plan to install edubuntu-desktop and some other educational stuff from the add-on CD with internet turned off, anything else to be tested for Edubuntu add-on ?
<ogra_cmpc> \sh, is the .desktop fix in debian ?
<ogra_cmpc> stgraber, make sure you get a notification that you need to re-login for the new artwork defaults to take effect
<stgraber> ok
<ogra_cmpc> beyond that i dont see anything special that needs testing
<\sh> ogra_cmpc: I'll check
<ogra_cmpc> i think tormod would have noted that down on the bug
<\sh> ogra_cmpc: reading the debian changelog, no
<ogra_cmpc> right
<ogra_cmpc> thats what i'm waiting for (or a "no" from joey)
<ogra_cmpc> as long as there are chances that we get it with all our changes merged into hardy i will wait
<\sh> ogra_cmpc: but other fixes of tormod are in
<ogra_cmpc> right
<ogra_cmpc> but he's talking to joey afaik
<ogra_cmpc> so chances are there that he gets that in as well before hardy
<\sh> ogra_cmpc: just going up dholbachs list of bugs ;)
<ogra_cmpc> its open in a tab on my desktop, i wont forget about it
<stgraber> ogra_cmpc: it tried to download ttf-sil-gentium from the net
<stgraber> ogra_cmpc: IIRC I saw that package removed from ubuntu-desktop seed
<ogra_cmpc> hrm
<ogra_cmpc> when ?
<stgraber> ogra_cmpc: Steve Langasek <steve.langasek@ubuntu.com>  Wed, 05 Mar 2008 11:37:53 -0800
<ogra_cmpc> argh
<ogra_cmpc> crap, that has to move over then i guee that was due to space issues
<ogra_cmpc> *guess
<ogra_cmpc> thanks for looking it up (no working browser here atm)
<stgraber> ogra_cmpc: how critical is that ? the font is probably small, but that means our add-on CD curently requires internet to install
<stgraber> slangasek: ^
<ogra_cmpc> i wonder if that justifies a rebuild ...
<stgraber> yes, me too ...
<keescook> slangasek: IIUC, if I look at http://people.ubuntu.com/~ubuntu-archive/germinate-output/*.hardy/all+extra.sources and don't see a given pkg listed, I'm safe to upload it, correct?
<keescook> (I have a FFe already)
<stgraber> ogra: btw why do we have install/, doc/, isolinux/ and preseed/ on the CD ?
<_MMA_> stgraber: Im here. (kinda)
<stgraber> _MMA_: Ubuntu Studio isos need testing (no result on the tracker last time I checked)
<_MMA_> stgraber: Alpha6?
<slangasek> stgraber: what is looking for ttf-sil-gentium still?
<stgraber> _MMA_: yes
<stgraber> slangasek: edubuntu-desktop I guess
<slangasek> ok, then I think edubuntu-meta needs a reupload
<slangasek> and yes, add-on CDs are cheap to rebuild, so I think we should go ahead with doing so in this case
<stgraber> hmm, looking at its deps, it's not the one who's depending on ttf-sil-gentium :(
<_MMA_> stgraber: 20080306 is to be Alpha6?
<slangasek> keescook: well,  http://people.ubuntu.com/~ubuntu-archive/germinate-output/*.hardy/all+extra.sources doesn't show what's seeded for the derivatives that build out of universe I think?
<ogra_> slangasek, ok, adding it
<keescook> slangasek: I meant the "*" to mean I'd check each file... are there others affected by the alpha6 freeze that are in the germinate output?
<slangasek> ogra_: adding what?
<ogra_> slangasek, the font to the seed
<keescook> slangasek: really I want to get an answer to theq uestion "is libsemanage in any of the CD images?"
<slangasek> ogra_: is that really what's wanted here?
<stgraber> ogra_cmpc: tuxtype is depending on ttf-gentium
<slangasek> ah
<ogra_> hmm, that should have pulled them in
<slangasek> so why does it need added anywhere, tuxtype should pull it in - right
<ogra_> s/them/it/
<stgraber> ogra_cmpc: I just played a bit with apt-cache rdepends
<\sh> if anyone has time to review bug #155543, it's appreciated :)
<ubotu> Launchpad bug 155543 in xchat-gnome "Does not send IRC color escape codes properly" [Low,Triaged] https://launchpad.net/bugs/155543
<ogra_> stgraber, your download is outdated
<ogra_> http://cdimage.ubuntu.com/edubuntu/daily/20080305.2/hardy-addon-i386.list has it
<slangasek> OMG how I hate the new gnome panel clock
<stgraber> ogra_: hang on a sec, I'm trying to find exactly what the issue is
<slangasek> give me back my timezone you rat bastard
<stgraber> ogra_: ttf-gentium is on my CD (I just noticed)
<stgraber> ogra_: ok, the error is : ttf-gentium: Depends: ttf-sil-gentium which is a virtual package.
<slangasek> ttf-sil-gentium isn't virtual
<ogra_> righ
<slangasek> it's a real package, and it's in main
<ogra_> t
<_MMA_> stgraber: Just let me know what one is supposed to be pushed as Alpha6 and Ill test. 20080306 or 20080305.2?
<slangasek> so that's just the "I don't know where this package is" error from apt
<ogra_> hmm
<ogra_> Replaces: ttf-gentium
<ogra_> hmm
<slangasek> _MMA_: this is always documented on http://iso.qa.ubuntu.com/qatracker/build/all
<stgraber> slangasek: well, current Ubuntu-Studio on cdimage is 20080306 and 20080305.2 on the tracker
<slangasek> ogra_: let me just try rebuilding and see if it fixes itself
<ogra_> yeah
<slangasek> _MMA_: the one listed on the tracker is the one we mean to release.  There's been another rebuild since then because I fat-fingered; there were no changes relevant to UbuntuStudio
<slangasek> stgraber, ogra_: fixed in edubuntu 20080306; please re-test
<slangasek> I understand on a high-level what happened with 20080305.2, but I'll spare you the horrible details :)
<_MMA_> slangasek: Ok. Im on it. Ill report ASAP.
<slangasek> ogra_: btw, ttf-gentium is a dummy transitional package; does the current tuxtype depend on ttf-sil-gentium instead?
<ogra_> no
<ogra_> the prob is that we dont have the curent tuxtype ... its pending a MIR approval for pango-sdl
<slangasek> actually, "yes" - the current tuxtype does drop the dependency on ttf-gentium, one way or another
<slangasek> tuxtype is just o-o-d, for the mentioned reason :)
<ogra_> i culd just quickly drop it but that requires a fresh meta
<ogra_> tuxtype i mean
<slangasek> doesn't matter, a simple respin of the CD was enough to fix the gentium problem in the short term
<slangasek> so once tuxtype is fixed (MIR or otherwise), the rest shakes out
<ogra_> thanks
<ogra_> sorry for missing that i didnt follow hardy-changes or some days
<ogra_> *for
<slangasek> hmm?  not sure what you're apologizing for, so... that's ok :)
<ogra_> well, i maintain the addon CD ...
<ogra_> so i could have noticed it earlier
 * ogra_ feels like a slacker since he doesnt have to test three CDs in six install variants
<ogra_> (which i did until last release)
<slangasek> are you subscribed on http://iso.qa.ubuntu.com/ so you get emails when edubuntu CDs are published for testing?
<ogra_> i used to
<ogra_> apparently i dont atm
<bdmurray> \sh: wouldn't fixed released me more appropriate for bug 180474?
<ubotu> Launchpad bug 180474 in wammu "[hardy] wammu unable to connect with Nokia 6086" [Unknown,Fix released] https://launchpad.net/bugs/180474
<bdmurray> be even?
<slangasek> bdmurray: you mean like the "Fix released" that ubotu just quoted at you? :)
<bdmurray> slangasek: that's the upstream task not the ubuntu one
<slangasek> ah :)
<stgraber> ogra_: you now are subscribed to all edubuntu testcases :)
<ogra_> stgraber, tx
<ogra_> looks good so far here, its already configuring the packages
<_MMA_> stgraber: Ahh... Cool. I dint know about the notifications.
<stgraber> _MMA_: you have to subscribe to the testcases you want and turn on e-mail notifications in your profile
<_MMA_> stgraber: I updated my profile. I think should get 'em now.
<_MMA_> I think I did it correctly.
<stgraber> you don't seem to be subscribed to Ubuntu Studio's testcases
<_MMA_> Isnt that "Preferred Ubuntu flavour(s)"?
<daba> http://tipovidaba.bloger.hr/
<daba> http://tipovidaba.bloger.hr/
<daba> http://tipovidaba.bloger.hr/
<daba> http://tipovidaba.bloger.hr/
<daba> http://tipovidaba.bloger.hr/
<\sh> bdmurray: actually it's invalid for hardy...and the bug reporter was at least < hardy;)
<stgraber> _MMA_: nope, this one is just something that'll appear in your public profile (as soon as we actually have public profile)
<stgraber> _MMA_: http://iso.qa.ubuntu.com/qatracker/test/1365
<stgraber> and http://iso.qa.ubuntu.com/qatracker/test/1366
<stgraber> then tick the one you want and click subscribe
<_MMA_> Ok. I did. Should there be some kinda confirmation?
<\sh> bdmurray: I would like to see the possibility to know the version of the package the reporter is using...or at least the ubuntu release when the bug was filed...
<_MMA_> stgraber: nm. got it
<bdmurray> \sh: I'm the reporter and I was using Hardy
<\sh> bdmurray: sry :)
<\sh> bdmurray: now
<bdmurray> \sh: thanks, it just seemed liked Fix Released was the best state for that bug.
<\sh> bdmurray: well, the right thing(tm) would be: wammu -> invalid , gammu fix released ;)
<\sh> doko: are you updating vnc4 somehow? it ftfbs somehow (amd64)
<doko> \sh: no
<\sh> doko: any advise for make it building? it looks really weired with that xserver-xorg deb pkg inside ;)
<bdmurray> \sh: because wammu is just a frontend for gammu right?
<\sh> bdmurray: jepp...
<TheMuso> slangasek: Cory was supposed to get them sorted, but the fact is that we don't have many testers. Theres pretty much myself, Cory, and one or two others from the dev team.
<TheMuso> Which is rather disheartening.
 * _MMA_ is installing i386 now.
<stgraber> ogra_: edubuntu add-on looks good but my virtual HDD wasn't large enough and ran out of space, I'm doing an alternate install on a bigger hdd and will try again
<stgraber> Please, could someone test auto-resize with debian-installer, according to http://iso.qa.ubuntu.com/qatracker/testcases (which will need to be reworked) it hasn't been tested on any ISO
<slangasek> TheMuso: well, it sounds like _MMA_ is subscribed to the ISO tracker now for UbuntuStudio, so perhaps that will help for the future :)
<_MMA_> \m/
<slangasek> superm1: fwiw, since we don't have it set up for inclusion in the ISO testing, I'm not planning to include it in the release announcement; but if you want to do some testing and announce your own mythbuntu alpha-6, I'm happy to take care of the publishing side of things
<slangasek> superm1: eh, "it" -> "mythbuntu"
<mario_limonciell> slangasek, it's not entirely functional yet after testing the ISO.  the main thing that we wanted to use it for (diskless) isn't spawning properly.  we'll probably hold off until beta to make an announce (assuming that part gets straightened out)
<slangasek> mario_limonciell: ok, sounds good
<slangasek> _MMA_: how goes the UbuntuStudio testing?
 * TheMuso has just synced ubuntustudio and is burning now.
<ion_> Ouch. Better not sync ubuntustudio then.
<ion_> Should we call the fire department?
<TheMuso> har har har
<_MMA_> slangasek: 97% (cleaning up) Manual partitioning test.
<slangasek> great, thanks
<_MMA_> slangasek: I do get a lang pack error but Im US_en. Install has completed.
<slangasek> mm, what is the langpack error?
<_MMA_> Language pack.
<slangasek> I know what a langpack is, what's the *error*?
<_MMA_> hehe
<_MMA_> One I never seen. Forgot to take a pick. :(
<slangasek> hrm
<slangasek> i386, or amd64?
<_MMA_> Something about them being missing.
<_MMA_> i386
<slangasek> there are updated language pack packages on the image from 20080306; should we check to see if that one's better?
<_MMA_> slangasek: If you have time to wait, sure.
<_MMA_> Will take about 90mins.
<_MMA_> slangasek: It installed. I doubt anyone but the team will really care 'till release. Then we will get a ear full for whatever people find.
<_MMA_> Id just push this.
<slangasek> ok
<_MMA_> 20080305.2
<_MMA_> Im still gonna do the other tests and report later.
 * ogra_cmpc scratches his head about the ping sound gnome-power-manager makes on lid close/open 
<ogra_cmpc> i really wonder why someone thinks i need notification about an action i'm actually just doing ...
<slangasek> ah, is that g-p-m's fault?
<ogra_cmpc> yeah
<ogra_cmpc> you can switch on/off sounds completely in the power settings ...
<ogra_cmpc> but then you wont get alarm sounds etc
<ogra_cmpc> the feature in general is good ...
<ogra_cmpc> its just silly for this action ...
<amitk> slangasek: is openoffice broken-ness known?
<Amaranth> ogra_cmpc: It makes me feel like I have a Thinkpad :P
<slangasek> amitk: not to me
<Amaranth> I just saw someone else complaining about OOo
<Amaranth> Maybe they caught a bad update
<amitk> slangasek: https://pastebin.canonical.com/3070/ - I am running amd64.
<slangasek> erm, that appears to be a password-protected pastebin and I don't know the l/p off the top of my head - can you push it somewhere public?
<amitk> I am off now, good night
<StevenK> "openoffice.org: Depends: openoffice.org-writer2latex but it is not installable" is the error
<amitk> slangasek: http://pastebin.com/d38af47d1
<slangasek> ok, thanks
<slangasek> yeah, I haven't seen that error before now; the OOo metapackage hasn't been seeded for quite some time, between dependency and size issues
<slangasek> that should go into a bug report on openoffice.org in LP though, if it hasn't already; I can have a look once I'm done pushing alpha-6 out the door
#ubuntu-devel 2008-03-07
<sivang> could somebody remind me the nick of Dennis that wrote the theme code in usplash ?
<sivang> (please ;))
<_MMA_> Seveas (I believe)
<sivang> _MMA_: thanks
<YokoZar> Is there any hope for getting a newer (or older) fontforge?  The version in Hardy has a regression that's breaking Wine
<_MMA_> YokoZar: Please file a bug in Launchpad.
<pwnguin> well that was a fun exchange
<pwnguin> <nameWithheld> pwnguin: just remember when ever you feel the need say ubuntu is working on, its mostly a lie :)
<YokoZar> _MMA_: https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/199331
<ubotu> Launchpad bug 199331 in wine "Changes in fontforge cause Wine's marlett.ttf to have incorrect available character sets" [Undecided,New]
<YokoZar> pwnguin: explain?  Does he mean we work on nothing, or that we work on completely different things than we say we do?
<pwnguin> i think he means no ubuntu developers dont write code
<pwnguin> and, at the risk of exposing the author, fedora does
<pwnguin> err
<pwnguin> wow, my grammar fails today
<pwnguin> no ubuntu developers write code for upstream apparently
<YokoZar> It wouldn't surprise me if, proportionately, the ratio of "ubuntu developers" writing code for upstream was less since we had more "upstream developers" essentially writing for Ubuntu
<Chipzz> YokoZar: heh. 1) ubuntu doesn't have much developers writing code 2) most of the code being written by ubuntu developers is not for upstream, but for ubuntu itself
<YokoZar> There's a few projects for which Ubuntu a majority of the user base, and the upstream developers run Ubuntu.  They're not technically Ubuntu devs, but it's not a terribly meaningful distinction.
<Chipzz> and even then there's the question what "writing code" consists of
<jcastro> YokoZar: next step is to get someone using wine in ubuntu to confirm the bug.
<Chipzz> YokoZar: in a lot of cases, writing code actually boils down to testing/incorporating existing patches
<jcastro> YokoZar: that should be easy to do
<jcastro> that will get the bug on someone's radar
<YokoZar> jcastro: There's one already in the wine bug list actually
<Chipzz> but such is the case in other distro's too I guess
<jcastro> I  mean in launchpad
<jcastro> pwnguin: there are plenty of upstream projects that ubuntu contributes to. See LTSP5, upstart, jockey, etc. etc.
<YokoZar> jcastro: By the way, I wanted to share with you something.  When I was at Fosscamp I came up with an idea that never would have occured to me without the interactions and suggestions of some of the other projects there (namely, a case-insensitive FUSE filesystem for Wine to put it's virtual drive in).  It's beyond my own abilities, so after getting back, I posted the idea in our wiki, and hoped someone else would take up the pr
<Chipzz> jcastro: is jockey something that is used outside of ubuntu?
<jcastro> Chipzz: it's shown interest by other distros
<Chipzz> YokoZar: sounds like a bad idea
<YokoZar> jcastro: This week we were talking about Google summer of code proposals on our devel list, so I mentioned the idea, and now someone is writing an application to do it.  There's a very good chance it'll happen by Hardy+1
<Chipzz> YokoZar: looks like you're trying to hide one problem with another
<YokoZar> Chipzz: You can see it here: http://wiki.winehq.org/CaseInsensitiveFilenames
<Chipzz> s/looks/sounds/
<Chipzz> YokoZar: I actively read the wine-dev ml. I still think it's a bad idea
<YokoZar> There are a few problems really.  One is speed.  The other is that when a user extracts a zip file (say, a patch for a windows program) into his .wine folder, sometimes it doesn't overwrite everything it's supposed to due to case differences.  Wine can't tell which file to use then.
<Chipzz> YokoZar: if wine wants case-insensitivity, they can do so in their codebase (perfectly possible)
<YokoZar> Chipzz: That's exactly the point of a FUSE filesystem driver.  Wine would really be the only user of it.
<Chipzz> YokoZar: also, sounds like a recipe to overcomplicate stuff, and make debugging much harder than it needs to be
<Chipzz> also: *unnneeded* overhead
<jcastro> YokoZar: has someone looked at how this fuse thing works out with the new gvfs thing in gnome?
<YokoZar> Chipzz: Wine already does a bunch of software workarounds to get case insensitivity, and many of them are necessarily slow since they run in user space and we can't assume the folder is case-insensitive.  It's even why a bunch of applications don't work (see link) due to speed
<Chipzz> YokoZar: can you explain to me why you would want a fuse file-system that 1) incurs overhead, 2) complicates debugging, 3) needs to be mounted, 4) requires the fuse kernel module when you can do all of this in the fopen calls wine implements?
<YokoZar> Chipzz: You can read this bug to get an idea of what's going on: http://bugs.winehq.org/show_bug.cgi?id=3817
<ubotu> Wine bug 3817 in -unknown "InstallShield very slow when copying many small files" [Normal,New]
<jcastro> YokoZar: btw, if you run into things like this where you think I should know, just spam the bugs to me, jorge@ubuntu.com
<YokoZar> jcastro: I just wanted to share that Fosscamp was useful, heh
<YokoZar> Even if it takes months
<jcastro> yeah
<jcastro> I am kinf of swamped with upstreams right now, but you know what they say about the squeakey wheel.
<jcastro> YokoZar: that last team report really rocked btw, keep that up please!
<Chipzz> YokoZar: and how exactly would a fuse fs make that *faster*
<Chipzz> it's still a bad idea
<Chipzz> YokoZar: and you haven't addressed even one of my arguments
<Chipzz> YokoZar: let alone the fact that 5) we probably won't use a fuse fs by default, or we would need to patch our version of wine, and the user would have the application fail at first, and then have to retry with a fuse fs?
<YokoZar> Chipzz: Imagine Installshield is asking Wine to copy/overwrite FileFoo.bar to a folder.  In order to properly keep things in order, Wine has to make sure that FileFoo.bar, FileFOO.bar, FileFOo.bar, etc. don't exist - or if they do, that they be overwritten.  If Wine is in a case-insensitive FUSE filesystem, then it only has to do one check.
<Chipzz> but the fuse fs would have to do 3 checks
<Chipzz> now you have shifted 3 checks from wine to the fuse fs
<Chipzz> and made the process more complicated
<Chipzz> so you have gained nil, and made things more complex
<Chipzz> that derinately sounds like an improvement, yes :P
<Chipzz> additionally, like I said, the fuse layer will actually cause things to slow down
<YokoZar> Chipzz: I'm not sure you understand the idea.  With the FUSE filesystem in control over the entirety of .wine, that's not an issue.  Imagine if it just put everything in upper case, then stored a text file next to it of what it translates to.  That doesn't require extra checks.
<Chipzz> so you actually *lost*
<Chipzz> and that's merely considering the case where it actually *matters*
<YokoZar> Regarding compatilbilty: the developer is working with Wine upstream.  The likely migration path is for the FUSE folder to be created at wineprefixcreate time, and then stamp .wine somehow so Wine knows if it can assume case-insensitivity or if it has to use it's current workarounds.
<Chipzz> it still doesn't matter IMO; wine can prevent the creation of overlapping filenames itself
<Chipzz> the only thing you gain from having a fuse fs is that other external processes can't careate such files
<Chipzz> which is a very small gain compared to the disadvantages I just listed
<Chipzz> which, as I may point out, you still haven't bother to counter even one of
<Chipzz> *bothered
<Chipzz> ...
<YokoZar> Chipzz: No, Wine can't.  The user might install overlapping filenames (such as by extracting a zip file, which is how many windows patches are distributed)
<Chipzz> YokoZar: IMO wine should just error out then if it encounters 2 possible files for a file requested
<Chipzz> and IMO, you aleady have lost anyway in that case
<YokoZar> Regarding points: 1) Less overhead with FUSE than with Wine's constant filesystem checks.  2) The two systems are separate and it's not hard to have the debugger know what file it's operating on and when FUSE is being called. 3) wineserver itself can mount them, stuff like that is what it's for.  4) Wine's fopen calls are too slow (see bug)
<Chipzz> can you actually prove 1)? I seriously doubt that
<Chipzz> you have wine -> kernel -> fuse -> kernel -> wine
<YokoZar> Chipzz: How do you propose getting those applications to work, then?  Asking the user to manually rename every individual file and cross check that it matches the name already in .wine?  I've done this myself, and it's a huge pain even when you know what to do.
<Chipzz> that is *4* context switches
<YokoZar> Chipzz: The overhead is not in software calls, it's in disk I/O
<Chipzz> in which case you are assuming that fuse doesn't get interrupted by another process
<Chipzz> that's 4, and I must add, VERY costly content switches
<Chipzz> and we're talking *best* case scenario
<Chipzz> s/content/context/
<Chipzz> also
<Chipzz> wine also runs on macosx and solaris
<Chipzz> do you even have fuse there?
<TheMuso> Yes, there is fuse for OS X. Can't exactly remember the name however.
<YokoZar> Chipzz: maybe, maybe not.  This doesn't make Wine any worse since the old methods will still be there.
<Chipzz> given alexandres attitude to patches, I have *very* serious doubts this will get accepted upstream
<YokoZar> Chipzz: Alexandre is one of our approvers of summer of code projects.  None get started if they won't eventually get in.
<YokoZar> Chipzz: The problem is we read from the disk too much to prove that a case insensitive file isn't there (or to find it if it is).  We do this many many times more often than once - in fact the number of times we need to do it grows with the length of a filename.
<Chipzz> then you're doing it wrong
<YokoZar> You should comment on that bug I linked earlier
<Chipzz> YokoZar: a simple implementation would be a readdir and then subsequently comparing all filenames
<Chipzz> 1) in most cases directory indexes are in subsequent sectors on the disk, so I have serious doubts about IO overhead
<YokoZar> Check out that wiki page and that bug link, seriously.
<Chipzz> 2) after the first readdir, the contents of that dir end up in the fs cache
<Chipzz> I was reading the bug report
<Chipzz> YokoZar: btw, please read: http://www.winehq.org/pipermail/wine-devel/2008-February/062249.html
<Chipzz> 3rd rule
<Chipzz> "* Comparing a 'windows string' with a unix one is out altogether (whether case insensitive or not) because they may not even be in the same encoding."
<Chipzz> though that may be up for debate
<Chipzz> YokoZar: also, lets say this does get implemented. Imagine the following use case: user starts wine, fuse fs gets mounted. user reboots, fuse fs not mounted yet. user says like you say he does, for example extract a zip file.
<YokoZar> No we'd need to keep the fuse system mounted when the user logs in
<Chipzz> I'm not sure about the semantics about fuse filesystems
<Chipzz> ie wether they can be mounted automagically
<YokoZar> By the way, I'm not sure I believe you that kernel->FUSE->kernel is an expensive context switch.
<Chipzz> but if they can't, you have to modify the login scripts
<Chipzz> I think it is
<YokoZar> Especially that it's more expensive than having to do many many string comparisons for a given file
<pwnguin> note that cache misses are killer
<pwnguin> and the context switch usually forces a lot of cache and such out
<Chipzz> pwnguin: you mean invalidate cache lines and such?
<pwnguin> sure
<Chipzz> yeah I was getting to that
<pwnguin> i think i need to read the backlog
<Chipzz> YokoZar: if I'm not mistaken kernel space and user space see two different address spaces. iirc this requires tlb trickery and such...
<YokoZar> We don't have kernel support for keeping a coherent userspace cache anyway
<Chipzz> YokoZar: for stuff like sshfs the fuse overhead is much less, since the slowness is in ssh anyway
<Chipzz> I think it's an entirely different story with something local
<YokoZar> Chipzz: reading the whole directory index is more expensive regarding disk I/O than we should need to just write one file
<Chipzz> the one advantage fuse does have is indeed that you can keep the directory in some kind of cache, and you don't have to deal with inotify and such
<Chipzz> OTOH
<Chipzz> you have the same overhead that you have with loop-mounted devices
<slangasek> YokoZar: what does this hypothetical case-insensitive fuse fs backend onto?
<Chipzz> slangasek: use case is wine, which expects a case-insensitive fs
<slangasek> I'm asking about the backend
<Chipzz> ah k
<Chipzz> EPARSE in that case
<slangasek> what's your storage medium - you're writing some sort of loopback filesystem that can only be accessed through fuse?
<slangasek> or you're writing a shim that sits on top of a POSIX directory?
<Chipzz> YokoZar: anyway, why not just loopback mount a FAT system on top of wine?
<slangasek> right, that's part of what I was getting at :)
<YokoZar> slangasek: Good question.  That's yet to be determined, I think.  The shim sounds like it would be simpler, though we would have to worry about something other than FUSE writing to the folder.
<Chipzz> in case the fuse fs is comparable with a loop mount
<YokoZar> Chipzz: I've done that actually.  It's still slow and we lose some things (unix permissions)
<Chipzz> YokoZar: which wine does not expect anyway?
<YokoZar> At UDS we talked about not launching executables unless with WINE unless they had execute bit set, for instance.
<YokoZar> On, say, double click
<pwnguin> ive been wondering about that
<pwnguin> why bother registering wine as a handler if you're not going to let me actually run stuff with it?
<YokoZar> *not launching executables with Wine upon double click unless execute bit (and without it prompting)
<Chipzz> YokoZar: also, like I pointed out, wine currently does not have any dependency on any special kernel interface. While this may happen in the future anyway, I'm guessing Alexandres reaction would be later rather than sooner
<YokoZar> So, if you click a shortcut to run an application in Wine's start menu, that's an obvious "I want this application to run" command and we'll respect that.  If you double click a .exe file with execute bit, we'll run that too.  If you double click a .exe file without execute bit, we'll tell you it's an executable and ask you once (and only once) if you'd like to actually run it.
<YokoZar> Chipzz: that's why it's a summer of code project ;)
<StevenK> What about .exe's that aren't for Wine, like mono applications?
<YokoZar> StevenK: There's a way to tell them apart (mono .exe that don't need Wine are ELF)
<Chipzz> YokoZar: anyway, in my opinion a) you loose anyway since you can not, like I demonstrated earlier, actually prevent this from happening anyway, b) significant overhead
<Chipzz> and one might argue that wine is not for newbies anyway
<YokoZar> Prevent what?
<YokoZar> The whole point of people like me is to make Wine usable ;)
<Chipzz> prevent something writing to that dir while your fuse fs is not mounted
<StevenK> /usr/lib/tomboy/Tomboy.exe: MS-DOS executable PE  for MS Windows
<StevenK> .wine/drive_c/Program Files/World of Warcraft/Wow.exe: MS-DOS executable PE  for MS Windows
<StevenK> YokoZar: ^
<YokoZar> StevenK: hmm....  Wine's already registered in binutils as the handler...
<Chipzz> YokoZar: I'm not sure you can make wine as perfect as being able to run 100% out-of-the-box anyway ;)
<YokoZar> StevenK: You don't execute tomboy by calling /usr/lib/Tomboy.exe though
<YokoZar> StevenK: You execute it by calling /usr/bin/tomboy which then calls mono and points to the exe
<RAOF> But you can.  And people building other mono apps may run their executables directly.
 * pwnguin wonders where paint.net would fall
<RAOF> pwnguin: In all the windows-specific dllmaps, I'd expect :P
<YokoZar> RAOF: That may be a bad idea.  The trouble is that we have no way to tell apart a mono app that requires Wine and one that can just run on Mono.  There are a bunch of mono apps that also use Win API stuff out there.  Getting (windows) mono working in Wine and gluing the two together is another project to tackle
 * Chipzz gazes in disbelief at YokoZar 
<Chipzz> dude, seriously
<YokoZar> wait a second
<YokoZar> Let me rephrase that
<Chipzz> if you have been following wine, you should know wine and mono cooperating was discussed in the past and dismissed
<Chipzz> or was that what you were going to rephrase? ;)
<YokoZar> So right now Wine has trouble running .net apps.  Some of these are apps that use win32 apis that can't run in linux mono
<YokoZar> One avenue for solving this is to install the windows version of mono into Wine.
<Chipzz> YokoZar: btw, the .net installer (or one version of it) was recently gotten to install under wine ;)
<YokoZar> Yeah, I read about that :)  But that's Microsoft, and we can't ship it.
<Chipzz> are you sure of that actually?
<Chipzz> anyway I think shipping a windows version of mono would be silly and not solve all the problems anyway
<YokoZar> Chipzz: I'm pretty sure the MS .net runtime requires a windows license
<Chipzz> in which case you loose for wine 100% working anyway
<Chipzz> since for example the ie components are implemented with mozilla
<YokoZar> Chipzz: The idea is if you can run the application on Windows XP with mono installed you should be able to run it in Wine (with mono installed)
<Chipzz> yes
<Chipzz> but I was pointing out something else
<Chipzz> I was pointing out that since the wine guys are shipping mozilla, and some users expect html rendering to be done like IE does, you loose in these cases anyway
<Chipzz> so if you're trying to get wine to be 100% bugfree, I'm saying you lost aleady
<YokoZar> Yeah, we do.  An application like, say, steam might have its store render as though it were in firefox.  If they were relying on IE quirks it'd look weird.
<Chipzz> worse
<Chipzz> a use case for wine is something like IES4linux
<Chipzz> (webdevelopers testing their webpages under wine)
<YokoZar> You can replace Wine's builtin shdocvw with a microsoft one (which is what IES4linux does)
<Chipzz> yeah
<YokoZar> In which case then it behaves like IE again
<Chipzz> but you just said you couldn't do such a thing with MS .Net
<Chipzz> so if the point is 100% compat with windows, you loose anyway
<YokoZar> All IE is is a wrapper around a rendering engine and a bunch of other calls.  We implement those calls, and provide the rendering engine using Gecko.  Ideally we'd use a Gecko in "IE quirks" mode, but no one's written that yet.
<Chipzz> and that would be pretty much impossible too...
<YokoZar> It'd be pretty boring to do, really.  What mozilla developer would want to replicate IE bugs?  Still, the kind of bugs this would cause would be limited to displays in the rendering engine, and would be fixable by installing native IE.
<Chipzz> but displays in the rendering engine is *exactly* the whole point of IES4linux ;)
<Chipzz> and you're correct in pointing out that no-one is interested in reproducing IE bugs ;)
<YokoZar> Chipzz: Well, yeah.  If you need to test IE, you should install IE.  If you need to run steam, gecko will be fine.
<Chipzz> indeed
<Chipzz> the point I'm trying to make is you can't cater to 100% of the users
<Chipzz> and quite frankly, I think someone extracting a zip file under linux on top of the fuse fs is someone who is not a total newbie anyway ;)
<Chipzz> so I would argue if they can do that, they can possibly spot the duplicate files too ;)
<YokoZar> As it stands it's a virtually impossible task for even me to do
<YokoZar> Because you have to manually open all the subfolders and so on
<Chipzz> so
<Chipzz> why do you worry then? ;)
<YokoZar> Because I can't install a patch that way without a huge headache, as easy as I can on Windows
 * Chipzz notes this discussion is getting a bit... erm... well :P
<Chipzz> wait
<Chipzz> please explain the word task?
<Chipzz> are you referring to navigating to the correct folder under .wine, and extracting a .zip file?
<YokoZar> Chipzz: yes, but the zip file contains subfolders, and each of those had to be checked, and so on
<YokoZar> Our current implementation in Wine is too slow (stuff like System Shock 2 takes literally hours to load a level).  I don't see how that can get any worse.
<Chipzz> an alternative approach would be to have wine bail out in case it sees 2 conflicting filenames
<YokoZar> You'd still have to detect them both then
<YokoZar> And that's the problem we were trying to solve in the first place
<Chipzz> actually, the problem you were trying to avoid was creating them in the first place ;)
<Chipzz> but yeaj
<Chipzz> *yeah
<Chipzz> I'll just point out one last thing and go to bed then
<Chipzz> if a newbie user was to extract said .zip file, a newbie would probably install winzip and use that ;)
<Chipzz> much easier anyway
<Chipzz> btw
<Chipzz> I just thought of a really easy solution (not sure if that's mentioned in the bugreport)
<Chipzz> just have wine lowercase all filenames it opens in .wine/<drive>
<Chipzz> possibly maintaining it's own mapping on-disk (much like, was it joliet?)
<YokoZar> Chipzz: that's sort of how I imagined the FUSE system working
<YokoZar> Chipzz: the advantage of having FUSE do this rather than Wine is then we guarantee that something outside Wine's control isn't happening (say, zip file) and then don't still need to check for non lowercase files
<YokoZar> oh btw the free-est .net MS provides is not free software (shared source, commercial use prohibited)
<bddebian> Can we ask for a give-back just for a failed build?  I don't understand why testresources failed on i386.  It worked on the other archs and it builds fine for me in an i386 hardy pbuilder?
<dbmoodb> colin watson + steve langasek  sorry if i was proving a pain a few days back
<dbmoodb> please don't eat me - cannot sleep brain will eat me
<TheMuso> c/
<pitti> Good morning
<Fujitsu> doko: Should you change to the ignore unknown -W* options in gcc-4.2 4.2.3-2ubuntu2 have caused anything to FTBFS? I've got a really strange one caused by it.
<Fujitsu> *Should your
<Fujitsu> s/the //, also. I can't think tonight, appparently.
<emgent> morning
<warp10> Good morning
<pitti> TheMuso: hi
<LaserJock> morning pitti
<LaserJock> et al
<pitti> TheMuso: can you please have a look at bug 177382? Do you think it's something that we shuold fix for hardy? (it's marked as qa-hardy-list)
<ubotu> Launchpad bug 177382 in postgresql-8.3 "pg_dump produces invalid SQL" [Undecided,Fix released] https://launchpad.net/bugs/177382
<pitti> hi LaserJock
<pitti> TheMuso: if so, is this something you're interested in working on?
<pitti> TheMuso: erk, EWRONGBUG, sorry; I mean bug 127705
<ubotu> Launchpad bug 127705 in compiz "compiz doesn't "talk" when switching windows" [High,Confirmed] https://launchpad.net/bugs/127705
<pitti> mvo: can I nag you about verifying bug 198129?
<ubotu> Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129
<dholbach> good morning
<Fujitsu> Hey dholbach.
<dholbach> hiya Fujitsu
<mvo> pitti: yes
<\sh> moins
<\sh> testing alpha6 in vbox :)
<mvo> pitti: I'm starting my VMs now
<soren> Can any one member of ubuntu-release acknowledge an FFe?
<TheMuso> pitti: I've worked around it for the speech/braille profiles on the live CD at least, by turning compiz off.
<TheMuso> But long term, it needs fixing yes. I'm just looking at the upstream bug to see where things stand.
<tjaalton> pitti: how does the jockey cmdline-interface work? I can't find a way to enable a driver, "jockey-gtk -e kmod:nvidia_new" segfaults
<asac> pitti: soren: ok, i unmilestone the NM bug about virtual interfaces for now.
<encompass> hi guys, I know your all really busy with alpha 6 but just wondering if we have a list for GSoC ideas yet?
<encompass> I am interested in doing another application this year. :D
<dholbach> encompass:  http://brainstorm.ubuntu.com/ ? :)
<soren> asac: Ok. We'll revisit for intrepid.
<encompass> dholbach: oh yeah, got piles of idea from there
<encompass> dholbach: but they are required to have one for the application as an organization, so... were she be :)
<encompass> dholbach: thanks for the pointer... it is great for people looking for something to do in linux that people like
<asac> soren: fine. just let me know.
<dholbach> encompass: no problem :)
<slytherin> Hi all.
<slytherin> Network manager applet is not updated to 6.6rc2 but network-manager is. Was this intentional?
<\sh> grmpf...hardy-server kernel doesn't like vbox
<soren> \sh: I'm guessing it's really the other way around, but ok.. :)
<\sh> soren: yeah :)
<\sh> oh vmwares patched via vmware-any-any-update vmmon.tar needs a another patch...asm/bitopts.h is wrong in vcpuset.h
<\sh> but I have to say...hardy looks real cool...the language selection directly in the cd boot screen is awesome
<Tonio__> slangasek: hey ;)
<Tonio__> slangasek: just rebuilt knetworkmanager, but still unable to connect to any wireless network
<Tonio__> slangasek: wired connection works
<Tonio__> slangasek: what is the status of nm-applet ?
<TomaszD> hello friendly devs! :] a bite-size bug for anyone who has two minutes to spare https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/199413
<ubotu> Launchpad bug 199413 in vlc "Please include Polish translation for .desktop file (diff included)" [Undecided,New]
<slytherin> TomaszD: vlc is in universe. you should ask on #ubuntu-motu
<pitti> hm, I thought scim was disabled again by default with the latest updates?
<pitti> martin   11799  0.0  0.0      0     0 ?        Z    09:13   0:00 [scim] <defunct>
<\sh> dholbach: would you like to share your "really fix it now" bug fetching script? :)
<pitti> and some scim-{launcher,helper-manager,panel-gtk} processes
<dholbach> \sh: it's in a really hacked-up state right now - let me fix up a few problems first :)
<\sh> dholbach: ok :) I just wondered how many times you let it run (once per day?) :)
<dholbach> \sh: it was broken that's why it did not run overnight - I think it runs every 4 hours right now
<\sh> dholbach: cool :)
<tjaalton> pitti: did you notice my question about jockey? the bug was about adding a real cmndline tool to enable the drivers, not just starting the gui with some options :)
<Tonio_> hi sabdfl, \sh, pitti, dholbach !
<pitti> tjaalton: no, I missed it; on IRC?
<tjaalton> pitti: yes
<tjaalton> pitti: how does the jockey cmdline-interface work? I can't find a way to enable a driver, "jockey-gtk -e kmod:nvidia_new" segfaults
<pitti> tjaalton: ah, you mean --enable and --disable should not ask for confirmation? right, that's true
<tjaalton> pitti: hehe, so that's what it's trying to do
<pitti> tjaalton: segfaults??
<dholbach> hey Tonio_
<pitti> tjaalton: I didn't implement package installation with out synaptic and $DISPLAY yet, that's still on TODO.txt
<pitti> tjaalton: i. e. it shuold fall back to apt-get install
<pitti> tjaalton: so that, and not asking for confirmation should do what you want, right?
<\sh> hoi Tonio_
<Tonio_> \sh: were our pykdeextensions changes commited upstream ?
<tjaalton> pitti: yes, something like that
<\sh> Tonio_: it doesn't look like it :(
<Tonio_> \sh: :'(
<tjaalton> pitti: preferably so that it works on the d-i chroot (which shouldn't be a problem)
<pitti> tjaalton: hm, no xorg.conf there yet, right? another bug in jockey (doesn't support creating xorg.conf from scratch, also on TODO)
<tjaalton> pitti: I'm thinking of running jockey at some stage after the packages are installed, so xorg.conf is definately there
<pitti> ah, ok
<pitti> tjaalton: can you elaborate about the segfault a bit?
<tjaalton> pitti: a bunch of pango errors and then boom.. the box is reinstalling atm so I can give the output in 30min
<sabdfl> hey Tonio_
<TomaszD> slytherin, ok
<TomaszD> slytherin, but \sh does vlc uploads from what I've noticed, and he's no motu :]
<lool> pitti: Heya
<lool> pitti: I'd like to discuss #186647
<lool> pitti: I need testers and I also wonder whether I should go for an UVF and then talk to you for the promotion or rather whether you should test and promote it because it's related anyway?
<dholbach> looking at http://daniel.holba.ch/really-fix-it there are myriads of acpi-support and acpid patches
<lool> dholbach: indeed, but this package is hairy
<lool> Lots of hardware quirks
<dholbach> yeah
<pwnguin> some people dont even bother with ubuntu
<cjwatson> there seems to be no way to reject a patch such that it will no longer appear on really-fix-it
<pwnguin> they just push upstream and let ubuntu grab it back
<lool> I tried maintaining it in Debian for some time, but it was too much work and I left it to buxy and a NM
<pwnguin> i know a guy's working on toshiba stuff that way
<lool> cjwatson: Even removing the patch flag?
<cjwatson> what, editing the attachment?
<lool> Yes
<dholbach> cjwatson: I know it's know ideal - deleting the attachment or the patch flag are the only ways right now :/
<cjwatson> ah, if you can do that ...
<lool> That's what I've been doing at least; I know it's the improper thing to do, but it is an approximation
<cjwatson> mkay, no problem
<lool> We should have patch statuses like bugzilla
<dholbach> or having everything in bzr ;-)
<pitti> lool: UVF doesn't exist any more
<lool> pitti: Whatever it's called that I talk to MOTU to get a new feature in universe
<pitti> lool: since the current packages are completely broken, we need to sync them anyway, I guess )
<pitti> lool: ah, right, for universe you need a bug for new upstream version
<lool> pitti: Ok; I'll push them then
<pitti> I keep forgetting
<pitti> lool: so please get their formal ack and then turn it into a sync request?
<lool> Since they don't work at all at the moment, it's best to push them and that's all
<lool> pitti: Ok
<pitti> right
<pitti> Hobbsee will glady give her ack, I'm sure :)
 * Hobbsee looks in
<Hobbsee> dholbach: fixed the 5-a-day problem, btw
<soren> Can any release team member ack an FFe?
<dholbach> Hobbsee: yeah, got the email about it :-)))
<dholbach> Hobbsee: doko had the same problem: you both weren't part of the team
<Hobbsee> soren: which release team?
<soren> ubuntu-release
<soren> Or is it all slangasek these days?
<Hobbsee> soren: technically, yes.  i don't think tehy would though
<Hobbsee> soren: oh.  well, i've done the odd bit, and not been shot by slangasek
<Hobbsee> bug #186647
<ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New] https://launchpad.net/bugs/186647
<Ng> dholbach: some of the acpi-support patches are definitely not right ;)
<Hobbsee> lool, pitti:  ack given in -motu
<pitti> thanks
<lool> Hobbsee: thanksely
* pitti 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
<pitti> (topic diff: remove alpha-6 freeze)
<seb128> pitti: thanks
<tjaalton> pitti: huh, now it didn't segfault, but the first run gave me an BadAlloc error, second time works
<pitti> tjaalton: hm; jockey is 100% python...
<soren> Yeah. Don't you just love it when scripting languages segfault?
<soren> Well, interpreters for scripting languages, that is.
<tjaalton> pitti: it's the gtk stack that failed
<mvo> pitti: a debdiff would be nice for the verification so that I get a better idea what changed and what tzdump commands will give me a clue if the changes are there
<mvo> pitti: unless you are happy with regression testing only
<pitti> mvo: ah, indeed; I just applied the patch in http://article.gmane.org/gmane.comp.time.tz/2094
<mvo> ok, thanks
<pitti> mvo: regression testing appreciated, too (I did some light testing already)
<slytherin> pitti: I suppose you handle hal-info package, right? I have a question related to same.
<pitti> slytherin: yes, I do
<slytherin> pitti: I noticed a blog on planet GNOME recently which says network-manager should also work with GSM phone connections over usb provided appropriate information is available in fdi files. Do you think we should make a 'call for phone informations (tried and tested)'. Or do you think users should send such information directly to upstream?
<mvo> pitti: dapper is good, going for the other ones now
<pitti> slytherin: it's fine to send them to the ubuntu bug tracker; I usually collect them, clean them up a bit, and forward them to upstream
<pitti> they're welcome to send them to upstream themselves in addition, of course
<Hobbsee> superm1: oh, did soyuz give back your binaries btw?
<slytherin> The reason I am asking is that it will reduce the headache for configuring internet through mobile (over usb at least).
<slytherin> provided we have information about enough handsets
<zdzichu_1> I believe using phone as modem ove BT is waaaaay more popular than by USB
<zdzichu_1> in fact, I haven't seen anyone with cable to his phone
<seb128> cjwatson: bug #198759 is not likely a xkeyboard-config one since it happens in a VT too, where should it be reassigned?
<ubotu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759
<slytherin> zdzichu_1: Right, but BT configuration still needs many file changes I think. So if we can automate at least one way (USB) with help of NM it is better than nothing.
<zdzichu_1> slytherin: it just need "hcitool cc <mac_of_phone>" to have phone appear as serial port. further configuration is the same as when connecting by USB
<slytherin> zdzichu_1: No that is what I am saying. As per this blog - http://blogs.gnome.org/dcbw/2008/03/02/networkmanager-your-gsm-mobile-and-you/ - the step to create a chatscript is eliminated. And the connection is managed with NM.
<cjwatson> seb128: it is xkeyboard-config
<cjwatson> seb128: the VT keymap is generated from the exact same data
<seb128> cjwatson: ah ok
<cjwatson> seb128: I was looking at it this morning; it seems intentional to some extent, rctrl is set to be a level5 shift in that keymap
<seb128> cjwatson: I though xkeyboard-config was used by xorg only
<cjwatson> but I couldn't see how to get to level4, so I haven't commented on the bug yet
<cjwatson> seb128: not since console-setup in edgy
<seb128> alright, thanks
<seb128> I asked on IRC because you are not subscribed to the bug
<mvo> pitti: verification is done
<seb128> so I'm not sure if you were reading comments there
 * pitti hugs mvo, thank you!
<mvo> cheers
<cjwatson> seb128: oops, subscribed to it now
<seb128> thanks
<pitti> doko: did you get any feedback about the new sun-java5 in dapper-proposed?
<doko> pitti: no, I have to ping people again
<tjaalton> there are new security releases of sun-java*
<PecisDarbs> nm 0.6.6 will be in hardy?
<pitti> PecisDarbs: already uploaded
<PecisDarbs> great
<PecisDarbs> thanks for info :)
<slytherin> So does the new version of nm-applet also include so called 'configuration UI'?
<dholbach> MOTU Q&A Session in 7 minutes in #ubuntu-classroom
<dholbach> keescook, doko: does the patch at bug 196274 make sense?
<ubotu> Launchpad bug 196274 in gdb "gdb 6.7 can SIGSEGV when printing state" [Undecided,New] https://launchpad.net/bugs/196274
<doko> dholbach: 6.8 would be nicer =)
<dholbach> right :)
<bbg1> hei
<bbg1> nobody say something ?
<ogra_cmpc> pitti, i have re-uploaded classmate-tools (now with copyright files :) ) ... if you find a spare minute
<Riddell> evand: where is progress_cancel_button hidden in the ubiquity gtk_ui?
<Riddell> debconf_progress_cancellable() never seems to get called
<pitti> ogra_cmpc: oh, sure
<ogra_cmpc> thanks
<ogra_cmpc> pitti, the current package still has the dep on classmate-settings (sorry, missed that) , i have fixed that locally already ...
<ogra_cmpc> (i can upload ubuntu2 if you need)
<pitti> ogra_cmpc: that's fine (upload it anyway)
<pitti> ogra_cmpc: btw, no XSBC-O-M necessary for ubuntu specific packages (just FYI, it's not actually a problem)
<pitti> ogra_cmpc: and you might want to remove the double dependency on ubuntu-desktop
<ogra_cmpc> who knows probably debian pulls it some day :)
<pitti> Recommends: xserver-xorg-video-i810
<pitti> that's really intended?
<pitti> (not -intel?)
<ogra_cmpc> well
<ogra_cmpc> it actually depends on it
<ogra_cmpc> but i didnt want to make it a hard dep since you could use it o non classmate (eeepc)
<ogra_cmpc> with other non xrandr drivers
<pitti> ok, so -i810 instead of -intel is deliberate
<ogra_cmpc> -intel doesnt allow panning
<ogra_cmpc> if you set the Virtual directive in intel it expects a second monitor
<ogra_cmpc> if you do the same in i810 you get a panning screen
<pitti> Encoding=UTF-8
<pitti> ogra_cmpc: ^ please remove that from the .desktop files
<ogra_cmpc> i'd prefer intel but he two functions are mutually exclusive
<ogra_cmpc> oh, why ?
<pitti> that's fine; if you say "yes, that's correct and wanted", I'm good
<pitti> Encoding: is obsolete; lintian should complain
<ogra_cmpc> ok
<pitti> accepted
<ogra_cmpc> (it didnt when i created the package)
<pitti> ogra_cmpc: feel free to upload your fix now
<ogra_cmpc> oki, thanks for that :)
<evand> Riddell: it's called in components/install.py and the button is defined in gui/glade/ubiquity.glade
<Riddell> evand: but if I add a debug line to debconf_progress_cancellable() it never gets called
<evand> hrm
<Riddell> evand: so it gets hidden in the gtk frontend, but I don't know how.  it doesn't get hidden in the qt frontend and we do implement debconf_progress_cancellable()
<evand> Riddell: I'm taking a look now
<amitk> ogra_cmpc: you plan to use i386-generic kernels for classmate, correct?
<ogra_cmpc> `i use -generic atm
<ogra_cmpc> not i386
<amitk> ogra_cmpc: the arch is 1386 though
<ogra_cmpc> it proved to not be slower anymore with 2.6.24 unlike gutsys kernel
<ogra_cmpc> yeah
<amitk> ogra_cmpc: splendid, just enabling USB_PERSIST for you, you can try it with the beta release
<ogra_cmpc> yay
 * ogra_cmpc dances
<amitk> ogra_cmpc: :)
 * ogra_cmpc makes a tag on the "beer for amit" list
<ogra_cmpc> :)
<evand> Riddell: Fixed and committed.  setCancelButton causes the cancelButton to be shown again, so I just moved the call to hide after that.
<Keybuk> random question of the day -- anyone know of a syscall to find out the name of a core file? :)
<Riddell> evand: ah hah, thanks
<pitti> Keybuk: syscall? you mean /proc/sys/kernel/core_pattern ?
<Keybuk> pitti: that won't tell me the name of a core dump
<evand> Riddell: you're welcome
<pitti> Keybuk: well, that's what the kernel uses as core file name (plus .$pid)
<Keybuk> ie. wait() returns CLD_DUMPED for a child process; how do I find the dump?
<Keybuk> pitti: right, but because of %t, it's impossible to expand that to figure out what the core file is actually called
<pitti> ah; for that you'd need to know the cwd of the crashed process, and with apport core_pattern is a pipe, etc.
<pitti> so in summary I don't think that there's a 100% robust method
<Keybuk> exactly
 * Keybuk was kinda hoping there was a prctl() or something
<pitti> Keybuk: last time I read that kernel code there wasn't :(
<Amaranth> ogra_: can you take a look at bug 192882?
<ubotu> Launchpad bug 192882 in xaos "Xaos display problem with compiz" [Low,Confirmed] https://launchpad.net/bugs/192882
<Amaranth> ogra_cmpc: ^
<ogra_cmpc> Amaranth, there is some work going on in debian i hope to get in, i have to check, might be the fix is included
<ogra_cmpc> Amaranth, bug 197261 there are some changes in xlib.c and ui_x11.c ... i suspect thats related
<ubotu> Launchpad bug 197261 in xaos "please merge xaos 3.2-7 from Debian unstable main" [Undecided,New] https://launchpad.net/bugs/197261
<Amaranth> ogra_cmpc: Nope, that doesn't appear to be related
<ogra_cmpc> ok
<ogra_cmpc> i'll include it in the merge then
<Amaranth> ogra_cmpc: thanks
<Amaranth> now i just have to figure out a way to do the same thing to eagle
<Riddell> evand: you might want to look at my last ubiquity commit and see if it's sensible and should be done to the gtk side
<evand> Riddell: will do, thanks
<keescook> dholbach: I don't know the gdb code base very well, but if the patch is in upstream, it sounds like it wouldn't hurt to add it
<dholbach> keescook: doko said we might want the new upstream version *shrug*
<dholbach> keescook: it was just one of the things on  http://daniel.holba.ch/really-fix-it  that looked interesting
<keescook> dholbach: yeah.  I'm disappointed with gdb upstream in general -- they continue to not incorporate PIE-handling patches.
<keescook> dholbach: should I just upload the patch anyway?  If we get 6.8 it'll already be in there.
<dholbach> keescook: I know about gdb much much less than you do :)
<dholbach> doko: ^ what do you think?
<doko> keescook: what about the pie patch?
<keescook> doko: is it actually in 6.7?
<doko> keescook: disabled
<keescook> doko: yeah, that's what I thought.  :(
<lool> dholbach: Do you recall the glom issue with updating it in stable?
<doko> keescook: who did you contact for that patch, or did you pull it from somewhere?
<lool> dholbach: murrayc is bringing it up again, he mentions https://bugs.edge.launchpad.net/ubuntu/+source/glom/+bug/186869
<ubotu> Launchpad bug 186869 in glom "Can't change field types" [Undecided,Incomplete]
<lool> dholbach: Would you like to take a look?
<keescook> doko: Elena Zannoni, no reply.  the patch is carried by every distro, but it doesn't apply to 6.7.
<dholbach> lool: -backports might be a better idea then if the patch is really that big
<lool> dholbach: Ack; if you recall the history, he complains that users don't get backports by default
<dholbach> well... he can attach the full diff, then subscribe motu-sru to get an ACK for it
<lool> dholbach: I thought you were updating glom and deps in the past so thought you wanted to guide him further in the process, but I can suggest what you just said if you prefer me to
<dholbach> lool: I don't a lot of packages any more - I can add that myself
<dholbach> don't maintain
<dholbach> DktrKranz2 already mentioned how to proceed in this case
<lool> dholbach: thanks
<dholbach> de rien
<lool> pitti: Re: elisa and stuff, python-twill currently uninstallable which is a dep of elisa; doko told me to check with jinty whether it was ok to update python-mechanize and I just got a yet
<lool> *yes
<lool> pitti: Could you please sync python-mechanize/0.1.7b-2 from unstable?
<lool> Will solve python-twill installability
<pitti> any new features that need an exception in 1.7b?
<lool> pitti: Not that I know of, but it's only used to run the testsuite of schooltool and zope, so it only endangers not being able to run the testsuite
<pitti> ah, ok
<pitti> lool: zzzzzzzzzynced
<lool> pitti: thanksssss and good WE
<pitti> lool: and to you!
<tkamppeter> Anyone of Ubiquity here?
<tkamppeter> Riddell, ping
<Keybuk> GRRRRR
<Keybuk> dear gnome-power-manager/HAL - STOP PLAYING MY SCREEN BRIGHTNESS
<Riddell> tkamppeter: hi
<tkamppeter> Riddell, AFAIR you are working with dual-GUI (KDE/GNOME) applications in Ubuntu.
<tkamppeter> Is this correct?
<Ng> Keybuk: 137598? ;)
<Keybuk> it's not resetting to maximum
<Keybuk> it's dimming
<tkamppeter> bug 137598
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [High,Triaged] https://launchpad.net/bugs/137598
<Riddell> tkamppeter: yes a bit
<tkamppeter> Riddell, I am organizing the mentoring organization application of the Linux Foundation, especially because most project ideas are from OpenPrinting.
<tkamppeter> One of the project ideas is the coding of the Common Printing Dialog:
<tkamppeter> https://www.linux-foundation.org/en/Google_Summer_of_Code#Common_Printing_Dialog:_Coding_on_the_dialog_designed_by_OpenUsability.2C_for_KDE_and.2For_GNOME
<ion_> Dear scim, please do not à¦¤à§à¦¡à¦à§ with my keyboard layout by default each time i hit ctrl-space or shift-space, kthxbye. :-)
<Riddell> tkamppeter: looks like a good project, what do you need me for?
<tkamppeter> Riddell, this is a printing dialog which OpenUsability has designed in the last two years.
<tkamppeter> Applications should all use this dialog called via Portland and the desktop (KDE or GNOME) should provide it.
<tkamppeter> To minimize coding effort it would be great to implement it as a dual-GUI app.
<Keybuk> eurgh
<tkamppeter> Now I am searching for an expert on dual-GUI apps to mentor this project.
<Keybuk> I *HATE* Portland
<tkamppeter> Keybuk, why?
 * slangasek bristles patriotically
<slangasek> :-)
<Keybuk> because Qt and GTK+ are more than just a "theme"
<Keybuk> they're a way of working, interface guidelines, etc.
<Keybuk> trying to make a Qt application look like a GTK+ one means that you confuse people who know Qt applications because it doesn't look like one, but works like one
<Keybuk> and you confuse people who know GTK+ applications because it looks like one, but doesn't work like one
<Keybuk> and we end up with hideous "cross platform" monstrosities like Firefox and OpenOffice
<Keybuk> where the most basic functionality like copy and paste don't even work right
<tkamppeter> Keybuk how would you implement that the user sees the same "Open", "Save as", "Print", and "Export to PDF" dialogs, all from the desktop currently in use, independent of the application which the user is using, for example if a user starts a KDE application under GNOME he gets the standard dialogs from GNOME?
<Keybuk> let alone file opening, etc.
<Keybuk> tkamppeter: I don't think they *SHOULD*
<ion_> Is there a program where copy and paste work right? ;-)
<Keybuk> a KDE application uses KIOParts to access files, etc.
<Keybuk> a GNOME application use GVFS
<Keybuk> these two fundamentally different systems mean that they access files in fundamentally different ways
<zul> slangasek:  samba question for you about the if-up.d bug if you were around
<slangasek> zul: shoot
<Keybuk> so the GNOME dialog boxes aren't even feature compatible with what KDE applications can do
<Keybuk> and then you have the ridiculous affair where the user is using KDE/Qt application
<Keybuk> is used to the way they look, the way they work, etc.
<Keybuk> the tabbing order, button order, layout
<Keybuk> and clicks a perfectly ordinary looking button, and gets *something else*
<Keybuk> so a Qt application suddenly has a GTK+ dialog box
<zul> slangasek: there is a fix for it upstream https://bugzilla.samba.org/show_bug.cgi?id=5267 patch looks ok to mathiaz and me
<ubotu> bugzilla.samba.org bug 5267 in nmbd "nmbd shuts down when network interfaces go down" [Normal,Resolved: fixed]
<trip0> offtopic: who owns trolltech now?
<Keybuk> trip0: Nokia, iirc
<Riddell> tkamppeter: I mostly do python apps, but this would presumably be c/c++ so I expect less code could be shared.  but yes I could in principle mentor that
<trip0> keybuk: i think you are right, thansk
<Riddell> trip0: trolltech's shareholders until the Nokia deal goes through
<tkamppeter> Keybuk, the idea of the Common Print Dialog is to not confuse users. Users will see the same OpenUsability-designed printing dialog with all applications and so if they are familiar with printing in one app, printing in another app will be trivial for him.
<Keybuk> I really, honestly, think that Portland is a nightmare waiting to happen
<Keybuk> the right thing to do is to separate the model and policy from the view
<Keybuk> so you can write separate native UIs for each desktop environment
<Keybuk> where the UI follows the interface guidelines of that DE
<Keybuk> and hook into the common model/control code
<ion_> True
<slangasek> zul: I think in the end it's less elegant than doing an if-up.d script because it gives us an nmbd process that has to poll when we already have an OS that *knows* when the interfaces come up and can trigger an nmbd restart, but if it's committed upstream then I guess there's no harm in taking it
<Keybuk> tkamppeter: so they will see a dialog box that doesn't fit in with any desktop environment?
<Keybuk> and behaves differently to anything else they might have used?
<Riddell> tkamppeter: I'm about to go out now, e-mail me if you have more questions
<zul> slangasek: sounds good
 * Keybuk fails to see how the term "Usability" applies here
<tkamppeter> And the parameters needed to print (printer, paper size, quality, n-Up, ...) are given by CUPS and the printer driver and so they are the same under KDE and GNOME.
<Keybuk> tkamppeter: but the dialog *should not be* the same
<slangasek> zul: oh, what happens for nmbd started at *boot* time when there are no active interfaces?  will it go into this same "reload_interfaces" loop, or will it still just shut down?
<zul> slangasek: no idea
<tkamppeter> Riddell, thank you for your offer, if you know someone more into C/C++ working on dual-GUI apps, please tell me.
<slangasek> zul: might want to check that first then, the if-up.d solution might still be the cleaner option :)
<zul> slangasek: ok will do
<tkamppeter> Riddell, to be a GSoC mentor you need to have a Google account, if you have none yet, create one. Please tell me your Google user name or GMail address. Thanks.
<Riddell> tkamppeter: "riddell"
<Riddell> @gmail.com
<zul> slangasek: it looks like its controlled by NMBD_INTERFACES_RELOAD
<tkamppeter> Riddell, thank you very much. I will add you as a mentor for this project. If you find someone who is even more suitable in terms of dual-GUI apps in C/C++, please let me know.
<keescook> asac: is 44062 fixed in ff3 now?  I was just reviewing security bugs in "fix committed" state.
<mathiaz> slangasek: I've got a merge of mysql-dfsg-5.0 ready to be uploaded - do I need a FFe before I upload ?
<Daviey> dreamnid:
<asac> bug 44062
<ubotu> Launchpad bug 44062 in firefox-3.0 "Firefox allows cookies to be set for second-level domain hierarchies" [Undecided,Fix committed] https://launchpad.net/bugs/44062
<mathiaz> slangasek: http://paste.ubuntu-nl.org/58787/ - .changes file
<slangasek> mathiaz: you need a FFe if it introduces new features
<mathiaz> slangasek: ok. In that case, no.
<slangasek> hmm... maybe we should refresh the screenshot of the world clock applet in the alpha release notes to not show a version which thinks it's simultaneously 6:18 AM in Sydney, Cape Town, and Porto Alegre
<Mithrandir> it's evidence of a flat world.
<davmor2> Hi guys the new world clock applet just crashed out my system when I hit okay for selecting Birmingham as location name :(  (The one in England rather than state side)  Is this known at all?
<LaserJock> maybe it's got something against England ;-)
<davmor2> LaserJock: :P
<Seveas> LaserJock, probably just birmingham
<Seveas> we can live without it
<davmor2> I can select London as timezone but when I go for Birmingham as location it dies.
<davmor2> Seveas: True but then I'm in wolverhampton so it don't bother me ;)
<_MMA_> davmor2: Does the same here to me. Kills the whole panel.
<davmor2> _MMA_: Ah found a bug then :)
<LaserJock> maybe it's an Easter egg
<_MMA_> davmor2: You can add it manually but you have to find the Lat/Long.
<davmor2> _MMA_ I cheated I just selected London as Time zone then changed London the Birmingham.  Probably not right but I didn't care :)
<davmor2> LaserJock: That's just wrong!
<LaserJock> davmor2: a little tribute to Birmingham residents ;-)
<_MMA_> I also notice that if I try to change the time settings (set system time) using the button on the applet the Authentication dialog comes up *under* the time settings. Where I cant get to it.
<_MMA_> I have to move the Time Settings dialog out of the center of the screen 1st.
<seb128> _MMA_: the focus issue is a known bug
<seb128> changing locations work correctly here
<slangasek> davmor2: are you editing or adding a new location?
<seb128> system crashing is not an applet bug, whatever an user app is doing the system should not crash
<davmor2> Adding new
<jdstrand> slangasek: hi!
<slangasek> davmor2: awesome, confirmed here
<_MMA_> seb128: Hmm... Also after authentication the Time Settings dialog crashes. Lemmie see if I can figure it out.
<slangasek> I love the world clock
<jdstrand> slangasek: so does removing strings in an initscript require an FFe?
<davmor2> seb128: I has only done it once the rest of the time the taskbars vanish and reappear
<slangasek> jdstrand: "removing strings"?
<davmor2> s/I/It
<_MMA_> slangasek: I would also if I could set it to use UTC independent of the system settings like the old one. :(
<seb128> davmor2: that is a gnome-panel bug and a known issue I think
<jdstrand> slangasek: thinking of string freeze-- these aren't translated
<jdstrand> slangasek: there was some debugging output in ufw's initscript that I just removed
<slangasek> jdstrand: oh, no (and string freeze is separate from Feature Freeze)
<seb128> slangasek: btw I doubt your "don't use network" bug will be fixed before hardy so you are welcome to work on a patch if you really care
<blueyed> jdstrand: removing is no problem. it means less work in the worst case.
<jdstrand> it wasn't just debugging, but it was too verbose
<slangasek> seb128: can't we just revert to the one that wasn't insane and weather-y? ;)
<davmor2> Cosford works which is up the road so it is just Birmingham
<seb128> jdstrand: feeze string is about no adding new strings, because doing that make non-english users have not translated strings, removing some should be no issue
<slangasek> seb128: another bug report coming, btw :)
<jdstrand> seb128, blueyed, slangasek: I thought as much, but wanted to be sure.  thanks!
<seb128> slangasek: and about duplicate old bugs from new one, I duplicate new comers, the other one was confirmed and milestoned already
<slangasek> seb128: the "newcomer" was also milestoned, fwiw...
<seb128> because you milestoned it when you found about it
<davmor2> seb128: slangasek: Do you want me to report the clock issue if it isn't already?
<seb128> let's say I had the other one at the right place and handled
<slangasek> seb128: I'm pretty sure someone else milestoned it and all I did was move the milestone around
<seb128> davmor2: no
<davmor2> Okay Np's
<slangasek> no?  because it's already reported, or...?
<seb128> slangasek: alright, no big deal anyway, it just has been reassigned this week and I got mail then when I already had the other one handled some time ago
<seb128> slangasek: no because it's a known issue yes
<seb128> let me get the bug number
<slangasek> ok
<_MMA_> seb128: The clock applet is called gnome-clock-applet? I want to put in a feature request to add back the ability to use UTC.
<seb128> _MMA_: it's in gnome-panel
<seb128> _MMA_: can't you add an UTC location and use this one?
<_MMA_> The old clock could use 12hr/24hr/UTC. I no longer see this option.
<seb128> I've 12-24 on the top of the dialog there
<_MMA_> Yep
<seb128> ok, so you just don't see utc
<seb128> why using an utc location doesn't work?
<_MMA_> I personally set 1 clock to local and a 2nd to UTC. Lets me coordinate better with people.
<_MMA_> seb128: And all the location gives me is GMT which isnt always the same. I also cant just look at the panel and see at a glance.
<seb128> what do you mean?
<_MMA_> If you set the old clock to UTC it showed that in the panel correct?
<seb128> right
<_MMA_> That's what I'm after.
<seb128> well, feel free to open a bug, better on bugzilla
<seb128> that's a valid wishlist
<seb128> nobody complained about that yet I think
<_MMA_> Sure. Hence the request for the applet name.
 * _MMA_ goes off to find the place to request it.
<seb128> not sure how many users really want that on the panel all the time rather than having a location for it and if upstream removed it on purpose because it's not that useful
<seb128> _MMA_: gnome-panel, clock applet
<_MMA_> k
<_MMA_> Thanx
<seb128> davmor2, slangasek: http://bugzilla.gnome.org/show_bug.cgi?id=513284
<ubotu> Gnome bug 513284 in clock "crash in Panel: Clicking Ok in the 'add ..." [Critical,New]
<davmor2> seb128: Cool np's
<amitk> keescook: we don't have any plans to move to gcc 4.3, right? http://lwn.net/Articles/272048/rss
<keescook> amitk: for intrepid yes.  (I can't read the article -- subscriber only)
<slangasek> keescook: summary: gcc-4.3 is now respecting a bit of the x86 ABI that it's never respected before, and the kernel doesn't comply with this bit of the x86 ABI, so the "direction flag" bit is now leaking
<slangasek> seems like it would be a good idea to get the kernel for hardy fixed wrt this issue regardless, who knows who else will be building binaries with gcc-4.3
<amitk> keescook: slangasek: but there is already a fix to the kernel upstream, so we will have it in intrepid
<keescook> eeexcellent.  :)
<slangasek> amitk: right; but third-party binaries might be built with gcc-4.3 for installation on hardy...
<amitk> slangasek: true
<amitk> and hardy is LTS
<slangasek> seb128: one more worldclock bug filed for you; I'm done now, at least for the nonce ;)
<seb128> slangasek: right
<seb128> anyway that will be for next week, enough work for this one
<seb128> see you later
<Kopfgeldjaeger> n8
<nepbabu> Is it OK to copy over snippet of text from https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700 while giving the full link in my blog?
<nepbabu> is this the right place to ask or what?
<jdong> nepbabu: I believe the license for wiki content is https://wiki.ubuntu.com/DocumentationTeam/License
<nepbabu> jdong, reading :D
<jdong> IANAL but it sounds like what you are doing meets the requirements
<nepbabu> jdong, it's just a personal blog
<nepbabu> nothing fancy
<nepbabu> jdong, tia
#ubuntu-devel 2008-03-08
 * slangasek hates on whatever is honoring his volume keys that's *not* GNOME, causing every keypress to count twice :P
<jdong> slangasek: introduce a third one that registers the opposite direction once to counteract it :)
<slangasek> OMG >_<
 * jdong pets slangasek 
<jdong> slangasek: don't worry, I've got a 104F fever, my advice might not be as good as usual :)
<slangasek> hmm, what's that bot command again to give me the relevant quote...
<slangasek> ah yes, there it is
<slangasek> !jdong | jdong
<ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<slangasek> I'm thinking the fever isn't keeping you down any ;)
 * jdong resists potential innuendos in above statement....
 * Fujitsu laments the lack of a Sync button on LP, resulting in annoying delays when syncing things.
<jdong> well an archive admin above seems to be active :)
<slangasek> he's otherwise occupied at the moment
<Fujitsu> Does anybody else find the new tooltip colour to be a bit too... orange?
<_MMA_> Fujitsu: "kwwii: I think that for hardy there is little reason to go out on a limb and change things for the sake of change" So I'm pretty sure Hardy will be the old "ubuntulooks" theme.
<Fujitsu> _MMA_: Why is the Murrine-based one evolving fairly quickly and on by default, then?
<sladen> slangasek: is it a thinkpad?
<jdong> _MMA_: that's a shame; I for one like the murrine based theme
<Fujitsu> jdong: As do I. It's much better than it was a couple of days ago.
<Fujitsu> Without the orange scrollbars, particularly.
<_MMA_> Ken has been testing and watching feedback. All the normal stuff. Some love it, some hate it. Cant please everyone. :P
<_MMA_> "kwwii: it is very, very likely that we will use ubuntulooks in the end" So we'll see.
<slangasek> sladen: yes
<slangasek> sladen: you have a fix? or a pointer in the right direction?
<sladen> slangasek: ps aux | grep thinkpad-keys   remember the thinkpad has hardware volumen keys
<sladen> slangasek: is it the volume, or the mute?
<sladen> slangasek: is it a really, really recent model?
<slangasek> sladen: volume; yes, thinkpad-keys is running; what's the issue there?
<slangasek> it's a T60
<slangasek> ~1yr old
<sladen> slangasek: ideally ACPI events are used to generate key presses;  with broken ACPI, the ACPI interupt is used to trigger a polling check;  with some totally broken models, the deamon is running in polling mode
<sladen> slangasek: it's probably a feedback loop somehow;  the hardware keys change the volume *and* get converted to a keypress;   keypress->volume change (in s/w) and "the volume changed"...
<slangasek> sladen: er, this is an entirely issue though
<sladen> ENOADJECTIVE
<slangasek> heh
<slangasek> entirely *new* issue
<slangasek> like, I think it's only been happening since my last login
<slangasek> and it definitely wasn't happening before my last kernel upgrade
<sladen> solved.  blame the kernel people.  Probably the kernel has now started to do it's own handling or something mad
<slangasek> meh
<slangasek> then it's hardly "solved" then, is it :)
<slangasek>   * ACPI: update ACPI blacklist
<slangasek> that's the only suggestive entry in the changelog
<sladen> thinkpad_acpi may have recently started generating its own events directly, recently
<slangasek> if I stop acpid, I see no keypress events for the volume key, and the volume adjusts
<Arwen> [00:11] <Arwen> I have a local APT repository on my machine
<Arwen> [00:11] <Arwen> I try to use "apt-get source" to copy sources from it
<Arwen> [00:11] <Arwen> it goes upstream and fetches a LOWER VERSIOn
<Arwen> [00:12] <Arwen> how to fix?
<PriceChild> Arwen: this isn't really a support channel, but make sure you've added the deb-src lines then apt-get update'd, and an apt-cache madison might be helpful to see what's going on.
<Arwen> I keep asking in the normal channels and people keep ignoring me..
<PriceChild> I haven't seen you in #ubuntu for several thousand lines.
<Arwen> because Seveas banned me 2 years ago
<Arwen> and, apt-cache madison shows my sources without a package name at the start of the line. What does that mean?
<PriceChild> appeal it in -ops, a pastebin would help others help you, I'm off to sleep
<Arwen> last time I asked he replied "not today, not tommorow, not the day after, not even when the world ends"
<Arwen> and oh well..
<Arwen> http://pastebin.ca/933255 <-- any idea why my sources are lower priority and without a package name?
<LaserJock> Arwen: there's a difference between Sources and Packages
<LaserJock> looks like the darnode packages have the highest version
<Arwen> yes, but the version on my sources are the same.
<LaserJock> Arwen: how do you mean?
<Arwen> oh wait no, they are at the top. Then why is apt-get pulling the distribution version.
<LaserJock> do you have a deb-src line for your darnode repo and are you using any apt pinning?
<Arwen> both
<Arwen> pinned at priority 1001
<LaserJock> not sure if the pinning would make a difference, I tend to avoid using apt pinning
<Arwen> but the more important thing is "apt-get source" doesn't see my source packages
<Arwen> it's the same with and without pins
<LaserJock> I would wonder if your repo is set up right
<Arwen> yeah, it might not be
<Arwen> I just used falcon
<LaserJock> hmm
<Arwen> I don't know enough to debug it though
<LaserJock> you could ask Seveas ;-)
<Arwen> he has me on ignore
<YokoZar> What's the difference between language code [pl_PL] and [pl] ?
<YokoZar> Someone's given me translations for a desktop file like the former and I'm wondering why not do the latter
<slangasek> the difference is that a translation listed as pl_PL won't be used when users have their locale set to Polish with a different country code
<slangasek> so the practical difference is approximately nil
<YokoZar> Sounds like I should use [pl] then as any polish local should translate to polish
<slangasek> I think so, yes
<YokoZar> Thanks
<mbt> anybody using hardy with us-intl keyboard layout and having problems with the dead keys?
<Hobbsee> what's this new thing in my panel, i wonder
<Mithrandir> click it and see what explodes?
<Hobbsee> and it cannot be quit
 * Fujitsu hides behind a nice thick sheet of lead.
<Hobbsee> begone from my panel, you rotten thing!
<Fujitsu> Hobbsee: What does the foul creature look like?
<Hobbsee> looks to be scim stuff
 * Hobbsee clicks Mithrandir, to see if he explodes
<Fujitsu> I'm yet to be attacked by SCIM.
<Fujitsu> Though I've been attacked by strange fonts that make the clock applet twitch.
<Hobbsee> what the?
 * superm1 is deeply disturbed by scim by default. 
<Fujitsu> With this morning's upgrade, the system fonts changed to something very strange.
<superm1> i press shift space way too commonly
<Fujitsu> The digits vary in width.
<Hobbsee> superm1: yeah, exactly
 * Hobbsee purges it
<Fujitsu> Hah.
<Fujitsu> Sounds like tracker.
<Hobbsee> and alt+space, and win space
<Hobbsee> yeah, exactly.  i was about to ponder which one would get purged first on all new installs
<superm1> i didn't realize it capitalized that whole corner
<superm1> that means that you can really just say left hand pound + space and get away with it
<Mithrandir> Hobbsee: I dodged your click by going into the kitchen.
<Hobbsee> Mithrandir: my clicks work across continents.  they're not going to be thwarted by some puny kitchen.
<Mithrandir> Hobbsee: X is network transparent, so the former isn't very surprising
<Hobbsee> ouch.  what happened with the fonts?
<Hobbsee> Fujitsu: wha'ts the font fix?
<Fujitsu> Hobbsee: I like most of the new font.
<Hobbsee> what is it?
<Hobbsee> it's just akregator that looks strange.
<Fujitsu> Except for the digits being stupid. And the merged fi glyph being too short.
<Hobbsee> so, it appears that ubuntu doesn't like skim being purged..
<Hobbsee> or thegdm change
<superm1> Hobbsee, well i better not reboot then...
<martin_> can i install ubuntu mobile on an openmoko compatible device
<RAOF> Hobbsee: I've successfully purged scim.  Did that at least a day ago, I'm surprised you lasted this long :)
<martin_> can anyone list devices that run ubuntu mobile
<Hobbsee> RAOF: i only updated a couple of hours ago
<Hobbsee> marcel: that's in the ubuntu mobile FAQ - see the links in #ubuntu-mobile
<RAOF> Hobbsee: Oooh, of course skim != scim.  Silly me.
<Hobbsee> RAOF: i think i was complaining about scim, but yeah
<dsargeant> Scim's been harrassing me all night. How did it get in my system tray and how do I remove it safely?
<RAOF> dsargeant: I've always been partial to "sudo aptitude remove scim", and telling aptitude to forget that ubuntu-desktop recommends it.
<dsargeant> RAOF: how do I tell aptitude to forget aptitude recommends it?
<dsargeant> nevermind, I found https://bugs.launchpad.net/ubuntu/+source/scim/+bug/199030
<ubotu> Launchpad bug 199030 in scim "Can't close SCIM" [Undecided,Fix released]
<Nafallo> ehrm
<Hobbsee> grumble
<Hobbsee> it *is* a scim problem
<scobby> hi i get an segmentation fault error when i run dpkg-reconfigure, with strace there is a bad adress error
<pushax> what do people think of Icedtea-Java over Sun-Java?  Not sure which one I should elave on machine or use to start learnign Java.
<azeem> pushax: that's not an appropriate question in this channel, ask #ubuntu, maybe
<pushax> azeem: isn't this room for developing software?
<pushax> or is it for kernel dev?
<ion_> Developing Ubuntu
<ion_> Please read the topic.
<pushax> ok
<theunixgeek> so they ARE adding new theme thingies to Hardy :D
<theunixgeek> there's an orange line to the right of the menus :D
<theunixgeek> seems like Ubuntu is moving towards orange now
<theunixgeek> the add/remove is changed
<theunixgeek> buttons aren't as shiny
<ogra_cmpc> hrm, something seems wrong with the publisher, there is still no classmate-tools binary, even though it built fine
 * xhaker thinks that whoever needs to disable scim should just uncheck that option on the new language-selector, that mvo uploaded
<TomaszD> can anyone please look at this bug https://bugs.launchpad.net/ubuntu/+source/nautilus-sendto/+bug/197145 ? A patch is available, so this shouldn't be hard.
<ubotu> Launchpad bug 197145 in nautilus-sendto "nautilus-sendto not compatible with bluetooth-sendto" [Undecided,Confirmed]
<TomaszD> it's really a let down that this doesn't work properly, you can send file via bluetooth this way :(
<TomaszD> this needs some love :]
<TomaszD> *can't send
<minghua> TomaszD: That's one big patch.  It's also a new feature, so needs feature freeze exception (https://wiki.ubuntu.com/FreezeExceptionProcess).
<TomaszD> minghua, it's not a new feature, it's a missing feature that needs to be re-added. It's a bug that it doesn't work. User is left with no message when he/she tries to send something, it just fails silently.
<minghua> TomaszD: Re-added?  So bluetooth-sendto had the --dest option before?
<TomaszD> minghua, of course
<TomaszD> it works in gutsy as expected
<TomaszD> the --dest option is there
<minghua> Well, then it should be clarified in the bug report.
<TomaszD> and I'm sure of it as I have shortcuts on my desktop with --dest so that I don't have to choose the destination
<TomaszD> alright, I'll do it in a moment
<minghua> TomaszD: Also, nothing stops you from working on this bug.  Only asking on IRC usually doesn't achieve much, IMHO.
<TomaszD> minghua, you'd be surprised. :]
<minghua> Huh?  Surprised by what?
<Yash> Hello, I would like to contribute to ubuntu as a developer.
<Yash> Can someone please guide me?
<james_w> Yash: https://wiki.ubuntu.com/MOTU/GettingStarted is a good place to start.
<realitybender_> hello?
<warren_> hello
<warren_> can someone reolve a bug? :D
<LaserJock> warren_: you might want to ask #ubuntu-bugs
<warren_> ok
<nixternal> pitti: possible to give me a brief tutorial on getting editmoin to work with the wiki?
<Amaranth> hmm, i wonder if launchpad would flip out if i tried to close ~100 bugs at once via email
<Nafallo> Amaranth: try? :-)
<Amaranth> got another week before they've been in Incomplete state long enough
<Fujitsu> Amaranth: I've closed more bugs than that at once.
<Fujitsu> With a lot of To addresses.
<Amaranth> heh
<Amaranth> now i just need to figure out how to automate it
<YokoZar> hmm, pbuilder doesn't work out of the box for me on hardy amd64
<YokoZar> Though, maybe that's as it should be since it's not working due to universe support
<sistpoty> infinity: can you increase the lp timeout of sparc for ghc6 (one particular ghc6 -> gcc invocation w.o. output took ~900 minutes w.o. producing output iirc on a TI UltraSparc II  (BlackBird)) thanks!
<sistpoty> (cf. bug #194912)
<geser> 900 minutes = 15 hours, wow
<sistpoty> yes, I added the total build time to the bug ;)
<sistpoty> not too sure, what exactly gcc does during that time, but it was definitely gcc taking this long time *g*
<sistpoty> (and it didn't even swap)
<sistpoty> fabbione | pitti | keescook: could you give a hint how you feel about getting a new version of ltp in? (bug #199663) thanks!
<ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
<ubotu> Launchpad bug 199663 in ltp "Hardy FFe: ltp snapshot should be updated" [Undecided,New] https://launchpad.net/bugs/199663
<keescook> sistpoty: I'm all for it.  :)  the old one doesn't work at all.
<sistpoty> keescook: thanks!
<keescook> np
<nixternal> pitti: nevermind my previous question..thanks
<geser> Keybuk: Hi, do you know if it's possible to fix bug #57755 somehow for hardy? Three (independent) packages have use for the same udev rules but only one can install them.
<Keybuk> err?
<Keybuk> that was fixed, wasn't it?
<Keybuk> or did they never agree
<Keybuk> arguably it's irrelevant now
<Keybuk> ship a HAL fdi file and PK policy to apply an ACL
<geser> IIRC the result of the discussion here some months ago was to wait for policykit
<geser> is there a package where I could look how it should be done?
<Amaranth> !ping
<Amaranth> hrm
<geser> Keybuk: and which package should ship this HAL fdi file?
<RAOF> Is the amd64 apport retracer on launchpad known-broken?  It's stripped the "need-amd64-retrace" tag from bug #199392 three times now, but hasn't actually done any retracing?
<Keybuk> geser: whichever package wants it
<geser> gnupg, gnupg2 and libccid want access to the smartcard reader they support
<geser> so ship it in every package?
<Keybuk> does gnupg not use libccid?
<geser> no, gnupg{,2} have direct support for some smartcard readers (some SCM ones) and can use others though libpcsclite
<geser> that's the problem, if it would depend on libccid, libccid could ship those udev rules (which it already does) and the bug be closed
<Keybuk> so why not just have a common file they can all depend on?
<Keybuk> pitti may not be adverse to those rules being in HAL either
<Keybuk> since you wouldn't be creating a group, but entries in PK's db
<Keybuk> hurrah for the end of group-per-device :-)
<geser> is there some good documentation for this somewhere?
<Keybuk> for which?
<geser> I mean how HAL and PK work together and how to grant an app access to one specific device
<Keybuk> HAL/PK?
<Keybuk> see the HAL spec on hal.fd.o
<Keybuk> it's granted by user/session usually
<geser> does it need changes to the app itself or does hald(?) change the permission of the devices itself?
<Keybuk> not sure why you're worry about the app?
<Keybuk> access to devices is granted by user
<Keybuk> hald sets and removes ACLs on the devices
<Keybuk> System -> Administration -> Authorizations
<Keybuk> you'd add something like "Directly access smartcard readers" to it
<Keybuk> (assumedly under org.freedesktop.hal.device-access)
<Keybuk> you can grant implicit authorisation to the user on the active console, for example
<geser> I've never worked with HAL/PK till now, so I don't know yet how all this works
<Keybuk> this is just for device ACLs
<Keybuk> (better than device groups)
<geser> what I don't understand yet, who checks the ACLs and allows a user to access the device with e.g. gnupg
<geser> and does it also work with a normal console login (no X11)?
<geser> I guess I need to read the HAL documentation first to understand it
<Keybuk> the filesystem
<Keybuk> getfacl /dev/snd/controlC0
<Keybuk> you should see a user:geser:rw- in there
<slangasek> oh, blink, we're using POSIX ACLs?
<geser> ah, I forgot filesystems ACLs completely and only thought about the traditional permissions (rwx)
<Keybuk> slangasek: yes...
<ubotu> Launchpad bug 57755 in gnupg "Udev Rules for SmartCard Support" [Undecided,New] https://launchpad.net/bugs/57755
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<ubotu> Bug 199392 on http://launchpad.net/bugs/199392 is private
<YokoZar> Wine's Tahoma replacement font still needs glyphs for some languages: Lithuanian, Greek, and probably others.  Is there a better mailing list than devel-discuss to ask for help from aspiring font authors?
<slangasek> Keybuk: hurray!
<Keybuk> slangasek: hopefully we'll be able to get rid of all "video", "sound", "tty3", "disk", etc. device groups eventually :p
<ion_> Awesome
<slangasek> Keybuk: er... why would getting rid of "disk" be a good idea?
<slangasek> do you mean to make the disks root.root?
<Amaranth> wait, doesn't all access in that case go through hal?
<Amaranth> or the service hooked to the other end of policy kit
<slangasek> that would seem to require backup software to either run as root instead of disk, or require some sort of PKage for backup packages?
<Amaranth> I'm pretty sure it's just an ACL for who can access a dbus service
<Amaranth> So...eww
<Keybuk> slangasek: right
#ubuntu-devel 2008-03-09
<slangasek> Keybuk: this doesn't sound like an improvement to me
<slangasek> at best, it sounds like needless churn...
<Keybuk> slangasek: if the backup program runs as a known user, you can grant that in PK as a permanent authorisation
<Keybuk> therefore it always has an ACL
<slangasek> yes, you can - but why do that?
<slangasek> what's the pk equivalent to adduser --system?
<Keybuk> I don't understand, sorry?
<slangasek> you're installing a backup package. you want the backup package to set itself up in the correct group when added.  Today, you do that by adding a system user and putting it in the disk group using standard commands.
<Keybuk> ah, we're talking about different cases
<ion_> I guess adduser --system ...; polkit-auth ...
<Keybuk> sorry, I was thinking of a random user running a backup program
<slangasek> ah
<Keybuk> if they weren't authorised to access the disk, it would require some kind of better authorisation
<Keybuk> ie. it'd pop up a dialog asking for the root password, or something
<Keybuk> if they're an admin, it would instead ask for their password
<Keybuk> etc.
<Keybuk> but without setuid helpers
<Keybuk> which are evil
<slangasek> but I don't think giving end users full read access to the disks is ever the right thing either, whether it's brokered through policy kit or otherwise
<Keybuk> you say "I want to access this device", and if you are allowed (by implicit, explicit or obtained authorisation) you get an ACL on it
<Keybuk> the problem with the group-per-device model is that you need a group per device
<Keybuk> e.g. that scard group
<Keybuk> we have yet another class of device "smartcards"
<Keybuk> so someone invents yet another system group
<Keybuk> and then grants some application implicit access to those kinds of devices
<Keybuk> or expects you to grant access to all users, etc.
<ion_> Does policykit modify the actual filesystem ACLs and then reset them when the authorization expires?
<Keybuk> ion_: HAL does that
<slangasek> for devices where you routinely want to grant end-users access, I agree that the ACL model is better
<slangasek> but you listed the 'disk' group, and I think that's a bug :)
<Keybuk> slangasek: I think we can both agree background daemons are a special case
<Keybuk> yeah disk was, I was typing dialout actually, then came back and saw "di" so finished with disk
<Keybuk> obviously we don't normally place users in the disk group right now
<slangasek> aha :)
<fabbione> superm1: congrats on the mythtv release
 * fabbione tests
<superm1> thanks fabbione.  went surprisingly smooth :)
<superm1> i need to pester someone in ~ubuntu-backporters now
<superm1> and get it in gutsy
<superm1> and we'll be done
<fabbione> i hope they have fixed the .iso/dvd playback
<fabbione> because i tested also normal DVD playback using Cars from Disney in a normal dvd player and it was royal crap
<fabbione> and yes the dvd was original..
<jdong> fabbione: Disney and Sony DVD's are horrendously awful to play on computers because of the ARCcOS crap they use
<jdong> I can't even get mplayer to play some of these discs
<fabbione> jdong: it used to play fine with older version of Mythtv
<jdong> superm1: I'm no sick break, so no!
<jdong> fabbione: ah, then you aren't affected
<superm1> on sick break?
<jdong> fabbione: but for the record High School Musical 2 is ARCcOS protected ;-)
<fabbione> jdong: this is a regression i already discussed with superm1
<jdong> (little sister. I swear.)
<superm1> jdong, being on sick break is even more of a reason to ack such backport bugs :)
<jdong> superm1: yes, no backporting while I'm vomiting :)
<superm1> bah.
<superm1> that
<superm1> s boring
 * Fujitsu strangles jdong for mentioning such a vile, vile movie.
<jdong> superm1: not when it's possibly due to contamination of food utensils
<superm1> wow that's horrible.
<fabbione> jdong: i was able to reproduce that problem with several others non sony nor disney dvd's
<jdong> Fujitsu: lol, I know. I scrubbed the images off my computer.
<fabbione> jdong: some just don't start play.. others only audio.. other times only video
<jdong> fabbione: ah different problem then
<fabbione> and i am sure they used to work before 0.21*
<fabbione> yup indeed
<jdong> fabbione: I've had different issues with media players getting stuck in copy protection pits
<jdong> annoying as hell, takes 30+ minutes to dig itself out and continue playing
<jdong> ah the lengths the movie industry goes for annoying the consumer
<fabbione> jdong: thing is that both mplayer and xine plays those DVD's just fine on the same machine
<slangasek> their target audience is too young to have taken a civics class
<fabbione> only mythtv interal player doesn't
 * jdong kicks fglrx.
<jdong> *cry* My tummy hurts, my head hurts, and fglrx corrupted my screen. How could my day get any worse?
<superm1> it took your GPG key with it?
<fabbione> your hd will die in a few minutes
<jdong> lol you guys are evil
<jdong> click.
<fabbione> i don't remember any part of the CoC that explicity requires me _NOT_ to be evil :P
<fabbione> oh speaking of GPG.. need to revoke a few uid's
<superm1> jdong, well i'm doing the legwork on the backport and attaching the build logs and such.  so it will just need a shiny +1 attached from you when you are alive again
 * Fujitsu revokes fabbione.
<jdong> superm1: alright, that sounds good, thanks
<ion_> fabbione: Please do not revoke mine.
<fabbione> ion_: ?
<fabbione> i can only remove uid's from my keys...
<ion_> Just a poor attempt at a joke. :-)
<fabbione> it's like 5:40am here.. have been awake all night cleaning my son's vomit and poking at xml
<ion_> (Yeah, unless youâre a Chuck Norris.)
<fabbione> ask yourself how much humor i have left in my body
 * ChuckNorris bashes ion_ 
<ion_> Better than cleaning your sonâs xml and poking at vomit.
<ion_> And iâm sorry your son is sick. :-(
<fabbione> not your fault dude..
<fabbione> he got somekind of bug 2 days ago
<fabbione> high fever and all that crap
<ion_> Sorry, as in feeling sorry for him.
<fabbione> yeah
<fabbione> thanks
<ion_> How old is he?
<fabbione> 18 months
<jdong> aww poor kid
<jdong> somehow, though, I think the parents suffer more than the kids
<fabbione> jdong: you are so right on this
<jdong> not in the sense of cleaning up, but watching a helplessly miserably toddler
<fabbione> indeed
<ion_> About the age of my nephew.
<jdong> well, hope he gets better soon...
<fabbione> yeah so do i
<fabbione> also because when he is sick he hangs on my neck all the time like a little monkey
<fabbione> he doesn't go to mummy at all
<Hobbsee> fabbione: bet mummy's happy with that
<jdong> fabbione: aww surely you've gotta feel some inner sense of satisfaction with that :)
<fabbione> Hobbsee: indeed :)
<fabbione> jdong: only when i am not dead tired
<superm1> jdong, okay its bug 200044.  i'll subscribe ubuntu-backporters though in case someone else decides to grab it.
<ubotu> Launchpad bug 200044 in gutsy-backports "MythTV 0.21 Suite backport" [Undecided,New] https://launchpad.net/bugs/200044
<jdong> superm1: mmkay, the perl module is a new hardy package?
<superm1> yeah
<Hobbsee> what's up with tzdata?
<superm1> i wanted to get it to debian too, but i dont have a sponsor yet for it in debian
<Hobbsee> pitti: ping?
<Hobbsee> Setting up tzdata (2007k-0ubuntu0.7.10.1) ...
<Hobbsee> dpkg: error processing tzdata (--configure):
<Hobbsee>  subprocess post-installation script returned error exit status 10
<Hobbsee> Errors were encountered while processing:
<Hobbsee>  tzdata
<jdong> Hobbsee: guess it's too late!
<Hobbsee> jdong: this is gutsy.  i'ts not supposed to break!
<jdong> Hobbsee: it seemed to work fine for me when I applied it earlier today (as a data point)
<Hobbsee> hmmm
<superm1> an older release breaking from an update?  blasphemy !
<Hobbsee> ahhh
<Hobbsee> it's because i've changed the default timezone
<Hobbsee> yeah, there we go.
<superm1> jdong, er yeah you probably wanted a build log from the perl module too. i'll attach that.
<jdong> superm1: nah I trust your word
<dbmoodb> in case you don't know - broadcom pcmcia laptop card freezes on eject - have not given it the firmware yet - i assume this is to do with networking manager ....
<jdong> is there a bug filed on this?
<dbmoodb> --- i don't know i have just installed hardy and was testing it out
<jdong> randomly coming into IRC with bugs rarely allows the message to reach the right people...
<dbmoodb> yes i was hoping i would be told if some one was aware of one
<dbmoodb> i am tired and was hoping that a bug had already been filed
<jdong> :)
<dbmoodb> sorry - wrong room should have joined ubuntu+1
<jdong> not a problem
<`Xenocide> the odds of someone else reporting this AND paying attention to IRC are low
<dbmoodb> - should i repost it in there or are most people in both
<`Xenocide> you might as well use launchpad itself to find similar bugs
<dbmoodb> well i am not involved with ubuntu that much at this stage and have previously made a noise and a blah of my self in #ubuntu so i don't really want to do work for you guys - in a major form i am just testing hardy out of interest.
<`Xenocide> well, the only way it gets fixed is if the people with the problem communicate with the people who can fix it
<slangasek> I don't understand why you would want to test hardy and bother to report issues, but not report them in the manner than will get them fixed?
<dbmoodb> because i don't want to get recognition for them because an attempt to contribute in an extended manner is not what i can do for the ubuntu community. i will give our cds but i am not wanting recognition online
<`Xenocide> recognition, or responsibility?
<dbmoodb> recognition
<LaserJock> that didn't make a whole lot of sense
<slangasek> LaserJock: clearly he's a famous Microsoft employee who doesn't want us to recognize him when he files bug reports :)
<LaserJock> yeah ...
<Hobbsee> he's not.
<Hobbsee> (thank goodness)
<Hobbsee> he's at my uni
<slangasek> Hobbsee: oh. why is he being weird about bugfiling? :)
<fabbione> slangasek: because the water spins the opposite direction in Down Under
<Hobbsee> slangasek: nfi.
 * fabbione starts to have nightmares about xml
<Hobbsee> so, this is strange.
<tjaalton> hm, what happened to the fonts.. they look "bigger" and fuzzier now
<zdzichu_1> tjaalton: check workaround at second-to-last comment in https://bugs.launchpad.net/ubuntu/+bug/153521
<ubotu> Launchpad bug 153521 in ubuntu "fonts are blurred with subpixel rendering" [Undecided,New]
<afflux> Is this intended or will this be fixed eventually?
<zdzichu_1> AFAIK this won't be fixed.
<afflux> :(
<tjaalton> zdzichu_1: thanks!
<tjaalton> maybe that bug should be reassigned..
<tjaalton> it's not against any package atm
<Hobbsee> !ping
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<ompaul> !ops | sorry to be a pain - ubotu is currently lagged like crazy can't be fixed due to auth issues - please people in #ubuntu-ops and I'll can a spare bot to join and please mute ubotu
<ompaul> ohh like that is going to be fun -- there will be a 20 min lag on reply or there abouts
<ubotu> sorry to be a pain - ubotu is currently lagged like crazy can't be fixed due to auth issues - please people in #ubuntu-ops and I'll can a spare bot to join and please mute ubotu: Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<highvolt1ge> ubotu: ping?
<ubotu> Sorry, I don't know anything about ping? - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<ompaul> highvolt1ge, it was 20 mins before that we seem to be getting waves of this
<ompaul> since yesterday
<ompaul> seveas said he can't get secure access for a couple of days if it is problematic drop into #ubuntu-ops and request ubotwo if ubotu is muted
<highvolt1ge> ompaul: ok thanks, doesn't seem serious (yet) though
<ompaul> (tm) ;-)9
<xsystemx>  Xlibs not found at -L/usr/X11R6/lib - How can I find out what package is required ?
<crimsun> xsystemx: fix the build system; that path is deprecated
<crimsun> xsystemx: in any case, you'd want at least libx11-dev, possibly more.  Check the log.
<xsystemx> crimsun - just trying to install virtualbox from source?
<xsystemx> crimsun - install all imaginable binary packages and still getting the error?
<crimsun> xsystemx: you'd need some subset of "apt-get build-dep virtualbox-ose"
<crimsun> xsystemx: may be better directed to #ubuntu-motu, in fact
<xsystemx> crisum - motu = ?
<pochu> jcastro: hello, I have a question regarding UDS, do you have a moment for a /msg ?
<afflux> Apport is doing weird things these days. ubuntu-crashes-* isn't subscribed to some bugs (for example bug 199846, which was reported by myself), some bugs just don't have the "need-*-retrace" tags (bug 199911) the retracer simply removes the "need-*-retrace" tags (also bug 199846). Anyone knows what's going on?
<ubotu> Bug 199846 on http://launchpad.net/bugs/199846 is private
<ubotu> Launchpad bug 199911 in emerald "emerald crashed with SIGSEGV in gdk_gc_new_with_values()" [Undecided,New] https://launchpad.net/bugs/199911
<ubotu> Bug 199846 on http://launchpad.net/bugs/199846 is private
<afflux> (I manually added the need-i386-retrace tag to 199911)
<Adri2000> who takes care of https://lists.ubuntu.com ? I doubt ubuntu-qa is a loco team :)
<LaserJock> depends on which "loco" they're talking about ;p
<Adri2000> :p
<m8ram> is this the right place for general questions on developing packages?
<james_w> m8ram: not really. #ubuntu-motu may be better.
<m8ram> thx, will check it
<m8ram> james_w: ubuntu-motu is specific for ubuntu, do you have an idea where I can get some directions on how to become an upstream developer as well?
<andrea-bs> m8ram: you should contact the upstream developers
<m8ram> andrea-bs: that's exactly the problem: I'd like to work on/help with the abcde package but the upstream developer (who is also the debian maintainer) appears to have abandoned the project
<andrea-bs> m8ram: did you try to contact him?
<m8ram> andrea-bs: I have sent him an email several months ago requesting him where to send feature requests but got no reply, this afternoon I sent an email to mia@qa-debian.com to see if he is considered MIA or not
<m8ram> andrea-bs: in any case the package has not been touched since sarge, even though various patches are available in the debian bug tracker system
<m8ram> for ubuntu the maintainer is set to Ubuntu MOTU developers
<andrea-bs> m8ram: the project has a Mailing List, did you know?
<m8ram> andrea-bs: haven't found it yet
<m8ram> andrea-bs: the SVN repos gives an error 503 service unavailable...
<jdong> yay svnadmin recover.
<andrea-bs> m8ram: I'm reading the readme from the ubuntu package
<m8ram> andrea-bs: the archives of the old mailing list appear to have been taken offline
<m8ram> andrea-bs: and the readme itself says that the new list was at that time not activley used
<m8ram> andrea-bs: last message on this list is from March 2007
<m8ram> andrea-bs: and it's in spanish...
<andrea-bs> m8ram: I can see that it's developed in debian, did you try to contact debian developers?
<m8ram> andrea-bs: not yet, other than the mail I sent to mia@qa-debian.org (not .com as I wrote earlier)
<m8ram> andrea-bs: but the maintainer at debian is also Jesus Climent, the upstream author
<andrea-bs> m8ram: I know, but this package is not maintained in ubuntu so I think you will have more chances with debian devs
<m8ram> andrea-bs: ok, do you know where I could find them?  I couldn't find an IRC channel for debian devel yet (I'm not really used to IRC)
<andrea-bs> m8ram: maybe #debian, but I'm not sure
<m8ram> andrea-bs:and debian-qa was really quiet earlier today
<m8ram> andrea-bs: thx, will check
<pochu> m8ram: irc.debian.org, #debian-devel
<m8ram> pochu: thx, will check it
<m8ram> thx: the original author appears to be on #debian-devel, hasn't responded yet but at least I'm at the right place
<pwnguin> is there a wiki for summer of code ideas yet?
<Amaranth> pwnguin: brainstorm.ubuntu.com
<pwnguin> the fun part about brainstorm is taking what they say and interpreting what they really want / need
<pwnguin> it's a bit like those GIMP / GNOME makeovers where the mockup is just a photoshop of what they want, with no considerations for what's feasible.
<TheMuso> Wow! Nice that the config file prompting is now via debconf. Slick. :)
<TheMuso> 5~/c
#ubuntu-devel 2009-03-02
<CarlFK> pitti: I was told to bug you (don't you feel lucky) - i'm trying to do 'this' https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/212073
<ubottu> Ubuntu bug 212073 in xorg-server "Touchscreen stops functioning correctly in Xorg if the device is removed/reinserted" [Low,Fix released]
<CarlFK> I see the changes in lshal, but 0 effect on X
<CarlFK> the problem I am trying to fix: when I move my finger to the left, the mouse cursor moves to the right
<ScottK> I suppose turning the machine upside down won't do it?
<ScottK> ;-)
<CarlFK> don't laugh - I was considering that
<CarlFK> but then the up/down will have problems
<Hobbsee> kirkland: that's fixed it, thanks.  I'll upload the change, if you like.
<Hobbsee> hrm, it's in bzr.  damn.
<Guest49220> argh
<Hobbsee> kirkland: blah, it's done already.  Who said fixes in ubuntu weren't fast?  ;)  Thanks!
<NCommander> hey Hobbsee
<directhex> NCommander, i did it, i got an arm system booted in qemu
<NCommander> score :-)
<directhex> NCommander, if i might make a suggestion... could someone DOCUMENT the fact that the default kernel cmdline includes "mem=32M"?
<Hobbsee> hey NCommander
<directhex> hair was torn out over that
 * NCommander didn't know that
<NCommander> Hobbsee, how goes it
<directhex> NCommander, i got the screenshot i wanted - http://www2.apebox.org/wordpress/wp-content/gallery/00-single/armless.png
<NCommander> lol
<NCommander> Xubuntu!
<Hobbsee> NCommander: fighting matlab :)
<NCommander> FTW!
<directhex> NCommander, MID was uninstallable this morning due to python transition
<NCommander> Hobbsee, have you prepared the scarifies in the necessary order?
<NCommander> directhex, the python transition has/had most of the archive broken :-/
 * StevenK is kicking python-hildondesktop now
<Hobbsee> NCommander: no.  I think that might be my problem...
<directhex> StevenK, well, i'm not moaning, fixing lp-integration made xubuntu installable :p
<NCommander> Yay for installable xubuntu
<directhex> matlab? :|
 * NCommander just installed Alpha 5 on his new machine :-)
<NCommander> StevenK, what's wrong with it
<StevenK> NCommander: Python 2.6
<directhex> NCommander, i wasn't going to push my luck & try a full-on gnome on arm in qemu with 256M
<NCommander> I mean is it FTBFSing?
<NCommander> directhex, 256 is the max you can run. GNOME runs slowly, but it does work
<directhex> NCommander, at any rate, silverlight on ARM, complete with media support! :p
<NCommander> nice!
<StevenK> NCommander: It's uninstallable, I'm looking at fixing it.
<NCommander> StevenK, would you like some help?
<directhex> NCommander, mostly i was documenting the procedure, to allow novell to produce one of those optional licensed binary codec downloads for arm. in case ffmpeg ever loses the required abilities for any reason.
 * TheMuso kinda wished that the python transition happened earlier in the cycle...
<TheMuso> IMO transitions should only be before feature freeze.
<directhex> started, certainly. sometimes they can drag on a bit, depending on size
<ScottK> Major ones anyway.
<NCommander> But python2.6 was uploaded past FF?
<NCommander> s/?/.
<ScottK> It was, but it was spec'ed and approved.
<directhex> bam, i have now entered the debian web o' trust
<NCommander> What's the point of FF if we break everything post it :-/
 * NCommander is reminded of libbluetooth last cycle, although that was kinda an exception cirmstance.
<StevenK> NCommander: It wasn't python2.6 that was the issue, it's python-defaults.
<andersk> Is there a main sponsor available to look at the one-line patch in bug 336436?
<ubottu> Launchpad bug 336436 in lsb "/usr/bin/lsb_release:81: DeprecationWarning: the sets module is deprecated" [Undecided,Confirmed] https://launchpad.net/bugs/336436
<redvamp128> okay quick question-- I need to find out what version of oss is installed on someones computer -- is there a quick command to find that?
<maco> apt-cache policy or dpkg -l will both tell you package versions
<maco> i assume you mean either alsa-oss or oss-compat
<redvamp128> oss-compat
<redvamp128> thanks
<maco> np
<redvamp128> he can hear system sounds but they are distorted and he is using oss
<redvamp128> so I fount 4.1 and 4.0 is the installed version and according to their page they fixed a few issues with his sound card
<CarlFK> for jaunty, did alsamixer get replaced?  (or, how do I adjust volume levels in a script)
<redvamp128> this one I am afraid is for hardy-- and I think it fixed his issue before just too many people -- too many configurations -- plus my 3 here at the house and 2 linux ones at work and 10 computers at work and 2 servers
<redvamp128> and that does not count the 25 laptops
<maco> CarlFK: no, alsamixer's still there
<maco> this isnt really the place to be asking such support questions though....
<CarlFK> maco: oh yeah - the oss stuff distracted me
<pitti> Good morning
<pitti> EtienneG: yes, although there's probably little I can do about it :/
<pitti> jdong_: we should get dbgsyms for -updates/-security
<pitti> CarlFK: 212073> let's discuss that in the bug, please subscribe me
<pitti> CarlFK: oh, you mean you don't have this particular problem? can you please describe the problem more specifically? does it happen after removal/reinstert, or always, and what's lshal output?
<asac> anyone knows if there is precendence of adding libs to ia32 as an SRU?
<asac> \sh: ^^?
<slangasek> asac: I would be very cautious in accepting such an SRU - why is it needed?
<asac> slangasek: two things:
<asac> slangasek: i got complain from NSPR/NSS/chrome developer that libnss3-1d needs libsqlite ... but only libnss3-1d is in intrepid ia32
<asac> slangasek: 2. also they would love to see those in the LTS, as it would allow amd64 users to build chromium
<asac> its a bit strange that it was added there without sqllite ... in jaunty libnss3-1d explicitly depends on libsqlite3-0 (>= 3.5.9)
<slangasek> asac: if it were the case that we were shipping nss in hardy ia32-libs already and it was broken, that would be a good reason for an SRU.  I don't think we should add more libs to ia32-libs in hardy simply because they'd be nice to have.
<mvo> doko: what do you think about writing a mail to ubuntu-devel-announce that explains to the developers that all packages that use python and distutils needs to get the "--install-layout=deb" added? I just did it for command-not-found and unattended-upgrades, but there are much more that need love. its funny, a simple rebuild puts everything in /usr/local now
<asac> slangasek: yes. thats what i thought. intrepid ok, hardy not
<asac> i will provide those in some ppa maybe ... so they can add something more official to their build instructions
<mvo> doko: or at least the scripts and i18n stuff (that is build via python-distutils-extra)
<slangasek> asac: if this is just for building... why not use an i386 chroot?
<asac> slangasek: its also for running ;)
<slangasek> ok
<asac> james_w: bzr-builddeb --merge seems to be broken in jaunty
<james_w> asac: how?
<asac> (still i guess) ... i have debian/ only branches and the top level dir from the tarball ends up in the build tree
<asac> james_w: http://paste.ubuntu.com/125187/
<asac> (ignore the aclocal.m4 ... that was created in pre-build)
<james_w> and what do you expect?
<asac> james_w: i expect the content of NetworkManager.git directory to be in toplevel
<james_w> asac: can you do a find for me?
<james_w> what are the entire contents of that directory?
<asac> james_w: inside NetworkManager.git?
<asac> ok
<asac> james_w: http://pastebin.com/f26d95ae4
<asac> let me get a tar tzf of the tarball too
<asac> james_w: http://pastebin.com/f33d9b4d7
<PecisDarbs> pitti: in Jockey, there are 'DeprecationWarning: the sets module is deprecated' string all over gui, making mess out of it
<james_w> asac: do you still have the Intrepid version pinned?
<pitti> PecisDarbs: do you use 0.5-0ubuntu2 ?
<asac> james_w: ii  bzr-builddeb          2.1~0ubuntu1          bzr plugin for Debian package management
<pitti> PecisDarbs: I did some python 2.6 fixes there
<pitti> PecisDarbs: over the gui? do you have a screenshot?
<cjwatson> lsb_release output perhaps?
<cjwatson> (bug 336436, about to sponsor now)
<ubottu> Launchpad bug 336436 in lsb "/usr/bin/lsb_release:81: DeprecationWarning: the sets module is deprecated" [Low,Confirmed] https://launchpad.net/bugs/336436
<PecisDarbs> pitti: 0.5-0buntu1 or 2
<PecisDarbs> pitti: screenshot comming, one min
<pitti> PecisDarbs: well, the 'or' matters :) ubuntu2 has the 2.6 fixes
<PecisDarbs> pitti: ubuntu2
<asac> james_w: maybe builddeb expects the top level directory name now to be of a certain format?
<james_w> asac: no
<asac> strange
<james_w> asac: can you let me have your branch and tarball?
<PecisDarbs> pitti: http://imagebin.ca/9L_dWXk.html
<james_w> it was working fine for me on Saturday, so I'd like to look at what you are using
<pitti> PecisDarbs: that's 404
<asac> james_w: sure: http://people.ubuntu.com/~asac/tmp/network-manager_0.7.1~rc2+1git7f1c86e3.orig.tar.gz
<PecisDarbs> wait, I will copy&paste :)
<PecisDarbs> pitti: http://imagebin.ca/view/9L_dWXk.html
<asac> james_w: bzr branch lp:~network-manager/network-manager/ubuntu.0.7.1
<pitti> PecisDarbs: right, that's the bug cjwatson mentioned
<directhex> 0.7.1, eh? does it actually save a default static ip yet, rather than ignoring you & re-creating a default dhcp link?
<PecisDarbs> ok, nice to know that you are informed already :)
<cjwatson> pitti,PecisDarbs: fix just uploaded
<cjwatson> pitti: why is jockey displaying lsb_release's stderr in its UI though?
<james_w> asac: wfm, "bzr plugins -v | grep builddeb -A2" please?
<PecisDarbs> cjwatson: thanks man :)
<cjwatson> pitti: and it might make sense to only call it once ...
<pitti> cjwatson: stderr> just fixed in bzr
<cjwatson> heh, ok
<pitti> cjwatson: once> that's what I did initially, but on other platforms "lsb_release -sir" is not predictable wrt. line breaking/spacing
<pitti> cjwatson: longer-term I just want to move this to a build-time check
<asac> james_w: http://pastebin.com/f6d45ce69
<cjwatson> line breaking/spacing> I don't get it. I just meant to call it once up-front and then you could still substitute it into a string and line-wrap that as normal
<pitti> cjwatson: but if it uses space instead of newline as separator, where do I break if there is more than one space?
<james_w> asac: it is odd that it is dist-packages
<pitti> of course that's slightly pathological (if the distro name has a space in it)
<james_w> unless that change was made a little while ago
<asac> james_w: i think before weekend doko did pythong 2.6 transition
<james_w> asac: yeah, but this was built almost 2 weeks ago. I guess it's not a problem, I just didn't expect it
<cjwatson> pitti: the UI shown in the screenshot above only uses "Ubuntu"
<cjwatson> pitti: so you could use -si called just once for those, and call -sr separately if you need the release version number
<pitti> cjwatson: yes, I could do that
<cjwatson> pitti: I didn't mean "just once, absolutely, for the whole program" - I meant "collapse multiple identical calls into one"
<james_w> asac: I don't understand though, I do a "bzr bd --export-only" and it creates the layout you desire
<asac> let me check
<asac> james_w: not for me :(
<asac> james_w: ls ../builds/network-manager-0.7.1~rc2+1git7f1c86e3/
<asac> debian  NetworkManager.git
<james_w> I can see that
<james_w> I just need you to do a bit more digging, as I can't reproduce it
<pitti> cjwatson: it's quite an intrusive change, though (changing all occurrences of using the variables to a function call which lazily calls lsb_release if it wasn't used yet), so I don't want to change it right now
<asac> james_w: i am here - and since i am kind of stuck because of that i will be here ;)
<james_w> asac: can you branch to a fresh area
<james_w> put the tarball in the parent dir
<asac> james_w: my builddeb conf is: [BUILDDEB]
<asac> build-dir = ../builds/
<asac> result-dir = ../results/
<pitti> cjwatson: (it doesn't call "lsb_release -sr" multiple times ATM either)
<asac> oops
<asac> damn paste ;)
<james_w> and run "bzr bd --export-only" and pastebin the output?
<asac> james_w: yes let me check
<asac> james_w: http://paste.ubuntu.com/125199/
<asac> james_w: oh fresh area
<asac> sorry
<asac> james_w: http://paste.ubuntu.com/125200/
<james_w> hmm
<asac> james_w: i branched from the local branch. i can try the remote branch too if that can make any difference
<james_w> it shouldn't
<james_w> asac: do you have any aliases for "tar"?
<james_w> do you have a ~/.bazaar/builddeb.conf?
<doko> mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html
<asac> james_w: yes. i pasted the builddeb a few lines above
<james_w> ah
<asac> (just build-dir = ... and result-dir = ..:)
<james_w> do you have a .bzr-builddeb in this branch?
<asac> james_w: no alias for tar
<asac> james_w: if i have it, its committed
<asac> let me check
<james_w> the one I have is merge = True in default.conf
<asac> james_w: yes, but you should hav eit too
<james_w> do you have anything else?
<asac> right
<asac> no
<james_w> no local.conf?
<asac> local.conf?
<asac> in .bzr-builddeb? no
<james_w> .bzr-builddeb/local.conf
<james_w> ok
<asac> note: i just did a clean branch ;)
<james_w> true :-)
<asac> james_w: is there kind of "verbose" mode?
<james_w> asac: you can look in ~/.bzr.log
<mvo> doko: fair enough, I was just thinking that ubuntu-devel-announce might be a good place too, especially since a rebuild without changes may now move stuff into /usr/local
<doko> mvo: it does work for simple packages, python-support, python-central and cdbs are patched to move these files around
<asac> james_w: http://pastebin.com/f6966bbbc thats what i get on --export-only run
<asac> james_w: line 22.
<asac> what do you run there?
<doko> mvo: do you see any additional, or grave update failures?
<mvo> doko: I just updated command-not-found and unattended-upgrades (they use debhelper) and I suspect gdebi needs a update too
<asac> webkitgtk python is broken ;)
<mvo> doko: maybe more, I need to check my devel tree. most of my python stuff does not use cdbs :/
<doko> mvo: btw, why does update-manager install into /usr/lib/pythonX.Y? Is this used by any other package?
<mvo> doko: but you know better whats doing on in python land, so its up to you where to announce
<doko> mvo: it's a feature not to use cdbs
<james_w> asac:       tempdir = tempfile.mkdtemp(prefix='builddeb-', dir=build_dir)
<james_w> subprocess.call(['tar','-C',tempdir,'-xf',tarball])
<mvo> doko: it installs stuff with nomove for improved stability (if that is what you mean)
<mvo> doko: just like python-apt
<mvo> doko: its one of the things that should be as robust as possible
<mvo> doko: oh, you mean computer-janitor
<doko> mvo: well, using a private libdir would be even more stable (if you don't have dependencies on update-manager)
<mvo> doko: that is fallout from the merge with liw, let me check
<asac> james_w: ok, that would give NetworkManager.git inside of builddeb-XXXX i guess
<glatzor> doko, mvo: packagekit-backend-apt depends on update-manager
<mvo> doko: the computerjanitor stuff is meant to be used by other packages so it needs to be public, but its in the wrong place
<doko> ahh
<liw> mvo, in the wrong place?
<mvo> liw: I see stuff in site-packages here on my system from computerjanitor that should be in dist-packages, but let me rebuild to actually verify that
<asac> james_w: are you running latest jaunty?
<liw> mvo, ah
<geser> doko: a quick question: for the use of py_libdir_sh the (loop) variable should be named python, right?
<james_w> asac: no, not updated over the weekend?
<asac> james_w: do you have python 2.6 as default?
<james_w> asac: nope
<doko> geser: no, the value that you pass should either be pythonX.Y or X.Y
<glatzor> doko, what should I do to improve my python packages which use cdbs?
<asac> james_w: i would think thats the reason then ;)
<asac> james_w: any trick how i can bzr to use 2.5?
<geser> doko: I've "Package bitbake version 1.8.12-1 has an unmet dep:
<asac> james_w: so yeah ;)
<geser>  Depends: python2.4-pysqlite2
<asac> james_w: python 2.6 booooo
<doko> glatzor: I don't know which packages you do maintain, and I won't look at those suggesting improvements ;) what exactly do you want to know?
<geser> doko: bad paste :(
<asac> james_w: python2.5 /usr/bin/bzr bd --export-only works!
<doko> geser: nothing should depend on pysqlite2 anymore
<glatzor> doko, you mentioned that not using cdbs would be feauture. so what does it wrong?
<doko> glatzor: I won't start a cdbs discussion. some like it, some not.
<geser> doko: I've "for py in $(PYVERS); do ..." in a rules file, so I use "$(py_libdir_sh)" instead of the hardcoded site-packages. I'm no makefile expert so I don't know from looking at the python.mk if it will work with the variable being named "py".
<james_w> asac: thanks, I'm trying to update now
 * asac alias python python2.5
<asac> ;)
<doko> geser: $ grep 'Call as' /usr/share/python/python.mk
<mvo> doko, liw: it looks like I was just confused by the fact that 2.6 stuff goes into dist-packages and 2.5 goes into site-packages. so update-manager should now be ok and install into the right locations
<doko> mvo: yes, I didn't want to change existing locations
<mvo> sure
<asac> james_w: let me know when its fixed ...  i repointed my python link to 2.5 now
<mvo> could we do anything to make builds fails that have the lcoation not updated on the buildds? or add some sort of check to fail if stuff ends up in /usr/local at the end of the build?
<mvo> I mean, packages that have no "--install-layout=deb" but get rebuild
<mvo> (e.g. because the maintianer overlooked the required change or because of control.in vs control file confusion etc)
<pitti> mvo: I think that already happends, in pkgbinarymangler (pkgsanitychecks)
<doko> mvo: these should fail, yes.
<mvo> pitti: aha, great.
<pitti> mvo: but I found most of my packages FTBFS much earlier, because of wrong *.install files
<doko> but we only check for /usr/local/lib/pythonX.Y, so maybe I just add a check for /usr/local
<mvo> pitti: yeah, me too. unattended-upgrades does not have one, so having this additional check is certainly good
<mvo> doko: sounds good, e.g. for stuff that is just a python-script with a private dir
 * mvo leaves for lunch
<slangasek> mr_pouit: I see that there are quite a few xfce4-related sync requests; do these have a FFe somewhere?
<slangasek> doko: how's python 2.6 going? the extra python has caused a bit of a jump in CD size. :)
<slangasek> doko: should I expect that to clear up soon, or should I offload some more langpacks in the meantime?
<doko> slangasek: isn't this called collateral damage? ;)
<slangasek> heh
<seb128> slangasek: we have one extra python version so extra use is expected no?
<slangasek> seb128: yes - but it's not supposed to stay that way for release, is it?
<doko> well, the gnome bindings were only built for 2.5 before alpha-5, so python-gnome-*, gtksourceview and deskbar-applet did increase in size
<doko> I'm not aware of other packages going up in size after alpha-5
<slangasek> the main difference was that python2.6 wasn't on the CD before, and is now
<seb128> slangasek: well we don't plan to drop python 2.5 do we?
<doko> ouch, 1MB compressed larger ...
<slangasek> seb128: I would assume that we plan to only have one version of python on the CD
<directhex> why would you want more than one version of ANYTHING on the cd?
<doko> slangasek: ahh, the static lib is in python2.6. will fix this
<slangasek> doko: but that's still two versions of python on the CD, which is mainly what I was asking about...
<doko> slangasek: which packages depend on 2.5 on the CD?
<slangasek> dunno, checking
<geser> if vim is on the CD then vim at least
<doko> looking at vim ...
<slangasek> doko: hmm - evolution
<slangasek> vim isn't on the CD, only vim-tiny
<doko> slangasek, seb128 : this should be fixed with the next upload. seb128, do you plan one?
<pedro_> james_w: may you have a look to bug 336067 later? it's broken since the update to python 2.6
<ubottu> Launchpad bug 336067 in python-httplib2 "python-httplib2 needs a patch for Python2.6 support" [Undecided,New] https://launchpad.net/bugs/336067
<seb128> doko: yes, new GNOME versions due today
<james_w> pedro_: sure, please assign it to me
<pedro_> james_w: will do, thanks you :-)
<pitti> seb128: if you upload a new evo, can you include the screen size patches, or do they need more work/discussion?
<seb128> pitti: I can try, there is just a zillion of those in a tarballs which is going to take a while to review, not to mention that I hate those "add scrollbars everywhere" changes, but shrug
<pitti> seb128: yeah, they are ugly; I only sponsor fixes which are reported/discussed upstream, though
<pitti> seb128: still, ugly is better than broken on netbooks
<seb128> right
<seb128> if they don't add frame one normal desktop case
<seb128> which some of those changes do
<seb128> one -> on
<seb128> grrrr at kubuntu
<seb128> we are getting a zillion of ""gnome-appearance-properties crashed with SIGSEGV in QGtkStyle::drawControl()"
<seb128> gtk-qt-engine is really a crappy crashing thing
<ogra> since it exists :)
<Riddell> seb128: I'd drop it if gtk had a sane default style
<james_w> it would have been nice to have python.mk available well before the transition so that I can actually build a source package containing the needed fixes for me to be able to upgrade past the transition
<seb128> I think I will add an apport hook to refuse any crasher if that thing is installed and display a warning "you installed that crappy kubuntu hack uninstall it if you want stability"
 * pitti arghs at pidgin ftbfs (libtoolish); Keybuk, seb128, you don't happen to know what http://people.ubuntu.com/~pitti/tmp/pidgin_2.5.4-2ubuntu2_i386.build wants to tell me?
<seb128> pitti: run autoreconf
<pitti> seb128: right, I could update the 70autoconf.patch, but it built correctly just 7 days ago..
<seb128> pitti: it will not ftbfs on the buildds, the issue is that it runs automake locally
<pitti> oh, I see
<seb128> pitti: that's a timestamp issue I never bother trying to fix it correctly, it only fails if automake is installed
<liw> tkamppeter, do you happen to know about Brother QL-550 label printer support?
<pitti> seb128: weird, pidgin b-deps on automake through intltool
<tkamppeter> liw, I know about a third-party driver which is linked from the appropriate printer and driver pages on OpenPrinting, but I did not test it.
<liw> tkamppeter, ok, thanks
<seb128> pitti: dunno but some autotools don't get installed and run on the buildd but do locally
<pitti> ah, apparently I had automake1.9 installed
<geser> if a main sponsor has some time: bug #336601
<ubottu> Launchpad bug 336601 in dput "Modules in use deprecated by python 2.6" [Undecided,New] https://launchpad.net/bugs/336601
<ogra_> slangasek, on http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/alpha-5/images/ixp4xx/netboot/ there is some discrepancy between the file creation dates
<ogra_> vmlinuz has a stap from 27th while the other two are from 25th
<ogra_> *stamp
<directhex> ta pitti
<ogra_> i think something went wrong here
<slangasek> ogra_:  well, I see the same in te 20081029ubuntu21 dir it was copied from...
<ogra_> weird
<ogra_> http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/20081029ubuntu22/images/ixp4xx/netboot/ has the same dates on all files
<slangasek> ogra_: so I'm not sure what went wrong, but it went wrong somewhere upstream from the copying I did
<directhex> ogra_, did i mention "woo, i got an arm qemu system booting"?
<pitti> geser: will you forward bug 336601 to Debian as well? It should work with python 2.5, too
<ubottu> Launchpad bug 336601 in dput "Modules in use deprecated by python 2.6" [Undecided,New] https://launchpad.net/bugs/336601
<ogra_> directhex, no, you didnt, congrats :)
<directhex> ogra_, think you could be a sweetheart & document the "mem=32M" bit in the default cmdline? i kept having oom issues until i actually read the kernel config & spotted that
<ogra_> hmm, i wasnt aware of that and all my docs say -m 256 and append "mem=256M"
<ogra_> (see https://wiki.ubuntu.com/ARM/RootfsFromScratch )
<directhex> still... http://www2.apebox.org/wordpress/wp-content/gallery/00-single/armless.png
<slangasek> e
<ogra_> directhex, i dont build the kernels (our kernel team does) but i'll talk to them to drop that default with the next upload
<directhex> ogra_, it'd make it easier for qemu, since you can just use the -m flag
<ahasenack> hey guys, is the python upgrade in jaunty mostly over?
<ogra_> directhex, yeah, understood ... i didnt even notice since as i said i ude append everywhere anyway
<ogra_> *use
<directhex> ogra_, d-i is sad with only 32M ^_^
<ogra_> depends :)
<slangasek> ahasenack: I would say we're still somewhere towards the middle of the end
 * ogra_ just made it work with the NSLU2 port on 30M
<ahasenack> sladen: cool, thanks
<geser> pitti: sure, will do so now
<pitti> geser: thanks; will sponsor in a minute
<slangasek> doko: python-pqueue is in main because it's seeded (ubuntu.jaunty/development); do you want to remove it from the seed or shall I?
<slangasek> (once it's out of the seed, there'd be no need for a bug report, it would just get picked up via component-mismatches...)
<doko> slangasek: please do
<pkern> Could someone upload my debdiff (with the version and suite target corrected) out of LP: #222532 to intrepid-proposed, please?
<seb128> doko: how do you debug issues similar to bug #332799?
<ubottu> Launchpad bug 332799 in gnome-desktop "gnome-about crashed with SIGSEGV in PyGC_Collect()" [Medium,New] https://launchpad.net/bugs/332799
<doko> seb128: try to run it with python-dbg, I suspect it's a missing Py_INCREF somwhere ... see /usr/share/doc/python2.6/SpecialBuilds.txt.gz
<seb128> doko: ok thanks
<ogra> ogra@osiris:/var/build/versatile$ grep physical /var/log/Xorg.0.log
<ogra> [    4.131326] (II) intel(0): Setting screen physical size to 261 x 163
<ogra> ogra@osiris:/var/build/versatile$ xdpyinfo |grep dimensions
<ogra>   dimensions:    1280x800 pixels (339x212 millimeters)
 * ogra doesnt get whats sets this 
<ogra> seb128, does gnome influence my dpi settings in any way to set screen dimensions ?
<seb128> ogra: screen dimensions?
<ogra> yeah
<seb128> ogra: the screen dimension is a physical thing
<ogra> xorg detects my display right at  261 x 163 mm
<seb128> it doesn't change when tweaking software
<ogra> but in my desktop is end up with settings for 339x212 millimeters
<ogra> and i cant find out what resets that
<seb128> you probably forces the dpi?
<seb128> and the resolution?
<ogra> well, my gnome capplet has 100dpi in the entry box
<ogra> i cant remember ever having set that though
<ogra> (it used to be 96)
<seb128> ok so that's the xorg detected value
<seb128> dunno about the physical screen but that should not be revelant
<seb128> you have the dpi value from xorg and the resolution you set
<ogra> well, 1280x800 on 261 x 163 would be 124dpi
<seb128> which is what should matter for what you get on screen
<ogra> and 261 x 163 is the right value (i used a ruler :) )
<doko> slangasek: the python2.6 package gets 1.4MB smaller (compressed)
<slangasek> doko: ok :-)
<seb128> ogra: dunno then, try a non GNOME session and see if you get the same issue
<ogra> will do, good suggestion :)
<ogra> oh, unsetting the dpi value in gconf-editor suddenly gets me huge fonts :) so i apparently have touched it before
<ogra> hrm, and calling the capplet forces it to 96 ...
<ogra> weird
 * ogra tries an xterm session
<ogra> seb128, hmm, seems gnoe actually sets it
<ogra> in the xterm session i have matching values
<seb128> ogra: do you have a .config/monitor.xml?
<ogra> yes
<seb128> ogra: can you move it somewhere else and try restarting your session and see if that's still an issue?
<ogra> yep
<ogra> seb128, ok, removing it *and* unsetting the gconf key gets me the right kes
<ogra> *key
<seb128> ok good
<seb128> so know you need to figure what you do to get a buggy config ;-)
<ogra> seb128, its a bit tricky, if you once touched the advanced font settings before in a former release or with the monitors.xml in place it will enforce 96dpi
<seb128> I guess using the xrandr capplet once to get a config.xml and restarting the session is enough to get the issue
<seb128> hum, it should not write the gconf key if you don't change the dpi value
<ogra> i seemingly had used the advanced font settings before
<seb128> I think there is a bug about the config forcing 96 dpi
<slangasek> jelmer: your debian/copyright on bzr-fastimport omits exporters/svn-archive.c and exporters/svn-fast-export.c
<jelmer> slangasek: Hi
<jelmer> slangasek, Thanks, I'll fix that; fwiw those files are not part of the binary package
<ogra> wow
 * ogra wasnt aware how crisp his display can be
<jelmer> slangasek, I thought bzr-fastimport was rejected though, because it wasn't processed before the FF?
<slangasek> jelmer: ok - I was going to accept it anyway, that's why it was a throw-away comment on IRC instead of a mail ;)
<slangasek> jelmer: it's being revisited following a discussion with motu-release the other day
<jelmer> slangasek, ah, cool
<ogra> hmm, what the heck starts notify-osd
<seb128> dbus
<seb128> that's a dbus service
<ogra> hmm
 * ogra would like to get it to not popup *under* the panel
 * NCommander wonders if he was the only one who thought the disappearing update manager icon was a bug, and not a feature.
<ogra> so i can actually read the notifications :)
<seb128> there is a bug open about that
<seb128> it seems to depend of the start order
<seb128> restart notify-osd
 * ogra did that and waits for a notification now
<seb128> you can use notify-send txt
<ogra> i just uninstalled libnotify-bin yesterday in a cleanup spree :)
<cody-somerville> slangasek, bug #336180 acked
<ubottu> Launchpad bug 336180 in gtk2-engines-xfce "Please sync gtk2-engines-xfce 2.6.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/336180
<ogra> hmm, i got a mail, but no notification
<slangasek> cody-somerville: there's a bunch of others related to xfce 4.6 - are they acked collectively, or do you want me to subscribe you to each for review?
<cody-somerville> slangasek, acked collectively
<slangasek> cody-somerville: ok, thanks
<cody-somerville> slangasek, no problem.
<ogra> aha, it pops up in front now (with notify-send) but not on the edge of the screen anymore
<ogra> but no mail notification at all
<james_w> shutil.move completely changed semantics in python2.6, fantastic
<directhex> james_w, yay for python?
<james_w> indeed
<directhex> james_w, given recently published numbers (was it by jdong? i think it was jdong) i'm gonna have to stop jokingly suggesting ironpython as a replacement, tho
<james_w> so it was actually fixing a bug: http://bugs.python.org/issue1577
<james_w> "I'd rather not do this. It might cause disasters for code that expects
<james_w> the old semantics. If you want a way to do the "mv" semantics, propose
<james_w> a new API.
<james_w> "
<doko> james_w: which package was broken?
<james_w> bzr-builddeb
<nags> doko, http://pastebin.com/d1864c445
<nags> doko, based on discussion with mvo on #ubuntu-testing, pasted the above link to you :)
<ogra> Keybuk, seems we have a prob with ltspfs in jaunty, to me it looks like the rules dont fire the scripts anymore (bug 335767) did anything change in recent udev that could cause that ?
<ubottu> Launchpad bug 335767 in ltsp "Jaunty Alpha 5: Usb stick (flash drive) does not pop up on the Gnome desktop" [Undecided,New] https://launchpad.net/bugs/335767
<doko> nags, mvo: it's a bug in ropemacs, the substvars are wrong (s/Python/python). see the warnings in the build log. apparently nobody checked the binary before upload/sync request
<Keybuk> ogra: lots of things changed
<nags> doko, ok
<ogra> Keybuk, well, i would assume the rules should still fire if a matching device is plugged in, probably the script arguments arent right anymore, could you tale a look ? i attached the currently used runes to the bug
<Keybuk> ogra: no, I don't have LTSP here
<Keybuk> start debugging using udevadm monitor -e to see what's firing and what environment are available
<Keybuk> use udevadm test to make sure your rules are being run correctly
<Keybuk> use udevd --debug to really get in depth
<ogra> err s/runes/rules indeed
<ogra> Keybuk, ok, i'll add that to the bug to get info out of the user
<ogra> (i dont run ltsp myself anymore either)
<Keybuk> actually I quite like runes
<Keybuk> we should rename it upstream to /etc/udev/runes.d
<ogra> hehe
<ogra> yippie, i got working notifications again, seb128 thank for the pointer, adding a wrapper script that makes notify-osd sleep for 5 secs seems to help
<ogra> *thanks even
<seb128> you're welcome
<superm1> james_w, gah that's probably what started causing crashes in mythbuntu-common (shtuil.move  stuff changing)
<vadi2> ops
<sistpoty|work> Mithrandir, StevenK: mind taking a look at bug #331973 (and eventually taking over handling this ffe?)
<ubottu> Launchpad bug 331973 in telepathy-idle "Ship telepathy-idle 0.1.3" [Wishlist,New] https://launchpad.net/bugs/331973
<sistpoty|work> seb128: I've also got a universe FFe for you: bug #334813. mind taking a look?
<ubottu> Launchpad bug 334813 in evolution-rss "installing evolution-rss removes evolution" [Undecided,New] https://launchpad.net/bugs/334813
<seb128> sistpoty|work: granted
<sistpoty|work> thanks seb128
<seb128> you're welcome
<sistpoty|work> Riddell: and one universe FFe for you at well (i.e., at least one, I'm just going through the list): bug #334121... mind taking a look there?
<ubottu> Launchpad bug 334121 in plasma-widget-translatoid "Update to 0.6" [Wishlist,New] https://launchpad.net/bugs/334121
<phomes> would a core-dev help me by updating mobile-broadband-provider-info? Current version (20081015) lacks one of the major danish providers and support questions for this are frequently popping up. #motu told me to go hunt for a core-dev. Bug 317860
<ubottu> Launchpad bug 317860 in mobile-broadband-provider-info "Request to upgrade to latest SVN" [Undecided,Confirmed] https://launchpad.net/bugs/317860
<sistpoty|work> Riddell: FFe's at bug #334690 and bug #335031 also look KDE related, mind taking a look at these as well?
<ubottu> Launchpad bug 334690 in kblogger-kde4 "Update kblogger to 1.0 alpha 3" [Wishlist,New] https://launchpad.net/bugs/334690
<ubottu> Launchpad bug 335031 in filelight "New upstream release filelight 1.9~beta for kde4" [Wishlist,New] https://launchpad.net/bugs/335031
<sianis-devel> asac, bug #279365 please review it
<ubottu> Launchpad bug 279365 in ubufox "Hungarian locale update for Intrepid ubufox" [Undecided,New] https://launchpad.net/bugs/279365
<kees> Keybuk: is there anything we can do to make AppArmor start faster?  sounds like it's eating 1 second at boot?
<Keybuk> kees: I haven't looked at it
<Keybuk> it looks like it's the parser though
<kees> Keybuk: hrm, yeah.  too bad -- that's the part that got speed-ups between 2.1 and 2.3 (i.e. we have the fast version already)
<kees> Keybuk: also, yay http -> https for merges.  :)
<Keybuk> could it be done in the background alongside something else?
<kees> Keybuk: possibly -- though it needs to be started ahead of any processes it's going to confine.
<kees> Keybuk: we've already run into issues with that for dhcp client.
<asac> sianis-devel: done
<kees> Keybuk: do you have any bootcharts handy that shows it?
<Keybuk> kees: http://people.ubuntu.com/~scott/boot-performance/mini9_jaunty-20090218-7.png
<kees> Keybuk: we could run it in parallel to the fsck
<kees> that's the sleep just above it?
<Keybuk> I want to get rid of that sleep too ;)
<Keybuk> does it have to be complete before anything in particular happens?
<kees> Keybuk: basically, before any daemons it confines start up
<kees> dhcp client is already protected to wait for AA to start up
<kees> is that sleep from the fsck script or from procps?  I can't quite read that
<Keybuk> fsck
<Keybuk> hmm
<Keybuk> doesn't that give you a deadlock?
<Keybuk> udev waits for ifup which waits for dhclient which waits for apparmor which waits for udev ?
<Keybuk> can what it parses not be precompiled?
<kees> Keybuk: I don't think it deadlocks -- we can check with jdstrand
<Keybuk> udev calls ifup, remember
<kees> Keybuk: precompiled -- possibly, but it'd need features from AppArmor
<kees> right, but isn't dhclient spawned (i.e. not waited on)?
<Keybuk> can't remember
<kees> and aa doesn't wait for udev
<kees> it just reads files, parses them and shoves them into kernel space
<Keybuk> its parser does seem very expensive
<Keybuk> what is it? XML?
<jdstrand> Keybuk, kees: udev calls idup as a daemon
<kees> no, it's just reading the /etc/apparmor.d/* files, and making a kernel-space DFA out of them, AFAIU
<jdstrand> ifup
<jdstrand> Keybuk: it will not deadlock
<Keybuk> so, err
<Keybuk> if things udev calls depend on apparmor
<Keybuk> why do you call it after udev?
<Keybuk> do you need /usr mounted?
<kees> we don't need /usr (parser is in /sbin)
<kees> I'm happy to relocate aa
<jdstrand> Keybuk: basically, I thought adding an intelligent ifup-pre.d script would be easier to get in and be less expensive than moving apparmor
<kees> I've just not be entirely certain where to put it
<Keybuk> how often do the things it parses change?
<jdstrand> kees: all we should need it securityfs mounted and /sbin/apparmor_parser
<kees> Keybuk: rarely
<kees> jdstrand: right
<jdstrand> Keybuk: very seldom
<calc> Keybuk: have the boot changes made it into the stock image yet?
<Keybuk> could you put it in the initramfs and run it while we're trying to find the root filesystem ? <g>
<Keybuk> calc: there are a lot of changes, some of them have, some of them are still pending
<calc> Keybuk: ok
<kees> Keybuk: we'd need to check where the securityfs is mounted from, but yeah, probably.
 * calc wonders how fast his laptop will boot with all the changes, it can do 100MB/s to disk :)
<jdstrand> Keybuk: I may have missed something-- is the dhclient pre up script causing a problem/slowdown?
<kees> Keybuk: it'd need to copy the entire contents of /etc/apparmor* into the initramfs
<Keybuk> calc: do you have an SSD?
<kees> jdstrand: no, just aa itself.
<calc> Keybuk: no, a 7200rpm hdd
<jdstrand> I see
<kees> jdstrand: it's taking 1 second for itself.
<Keybuk> calc: then you are doomed for a slow boot forever <g>
<kees> jdstrand: but could be run in parallel somewhere
<calc> Keybuk: lol :)
<calc> Keybuk: i was getting ~ 20s boots with my old laptop before i got this new one
<calc> of course that was 20s to gdm
<Keybuk> calc: 20s to a full, logged-in desktop?
<Keybuk> FAIL
<Keybuk> :p
<calc> heh
<calc> unless the seeks eat too much time it should be close to as fast as the netbook, my cpu is 50% faster and hdd is > 100% faster than my old laptop
<calc> at least for sequential reads
<jdong_> anybody know of software/strategies for scraping points off a graph image?
<jdong_> ugh wrong channel
<Keybuk> calc: boot is all about how fast your disk is
<Keybuk> and your seek time is SLOW
<calc> Keybuk: true but doesn't readahead fix that? or is it not being used anymore?
<Keybuk> readahead partially fixes it
<Keybuk> but our gathering has been pretty poor for it in the past
<calc> ok
<Keybuk> so it appears to be quite pessimal compared to sreadahead
<kees> Keybuk: in the bootchart you gave, where is the root fs mount happening?
<Keybuk> kees: before where "rc" starts
<Keybuk> ie. run alongside the udevd that's there
<kees> okay, gotcha
<Keybuk> though that part is probably too CPU contended :-/
<Keybuk> would be worth testing though
<kees> my /etc/apparmor* is well over 320K...
<kees> a relatively stock install is about 260k
<Keybuk> is there really no way to compile that down to something smaller and easier to read?
<kees> there is no existing way that I know of.
<kees> (this is one down-side to "dynamic label" MAC)
<kees> we might be able to write a parser that only includes files that are included (which could avoid some of the stuff in /abstractions)
<jdstrand> I doubt that would save much
<jdong_> lol glad I'm not the only one with oversized apparmor.d :)
<kees> jdstrand: yeah.
<kees> Keybuk: is bloating the initrd really worth it?
<jdstrand> kees: what if you loaded profiles on demand? or at least, load most profiles after login?
<ogra> Keybuk, looking at the end of http://launchpadlibrarian.net/23302773/udevadm_test_dev_sdb.txt it seems udev actually calls "ltspfs_entry add sdb" as it should, do you know if anything wrt environment handling in udev changed ? the script expects to find LOCALDEV=True in the global environment to actually do something
<Cool_Guy> Im not sure if this is the place to ask, but does anyone have experience with distcc/pump? I have it semi working and feeling its now working correctly
<Cool_Guy> *not
<kees> jdstrand: hm, as part of the target process's init script?
<jdstrand> kees: possibly
<jdstrand> kees: just OTOH we could have a really lean apparmor initscript that just mounts securityfs
<Keybuk> kees: no idea without testing
<kees> jdstrand: I think we could just move it earlier and have it run in parallel during the fsck bit
<Keybuk> kees: I'll probably try it at some point
<Keybuk> kees: but given the security issues, I've generally just left it alone
<ScottK> slangasek: If you have a moment to put your archive-admin had back on to finish the clamav backport to Dapper, I've uploaded all the source backports and the input for syncbugbot is at https://bugs.launchpad.net/dapper-backports/+bug/335724/comments/2
<ubottu> Ubuntu bug 335724 in dapper-backports "Please backport clamav 0.94.dfsg.2-1ubuntu0.1 from Intrepid to Dapper (source)" [Wishlist,Fix released]
<Keybuk> ogra: does udevadm monitor show that LOCALDEV is in the environment?
<Keybuk> ogra: your test does not appear to include it
<ogra> oh, good question
 * ogra looks
<kees> jdstrand, Keybuk: how about this: two part init: one starts at like S01 and backgrounds itself, then the S37 just blocks until the S01 component is finished?  we already have the logic for it in the dhclient scripts
<Keybuk> kees: possibly, though I'm wary that the CPU is fairly bound up until that point
<ogra> Keybuk, hmm, i dont even see PATH
<Keybuk> such things can actually make things slower
<Keybuk> ogra: PATH is inherited by udev
<ogra> (http://launchpadlibrarian.net/23299761/udevadm_monitor-e.txt)
<jdstrand> kees: so S01 mounts securityfs?
<kees> jdstrand: S01 would do everything S37 does now.  S37 would just block until apparmor_parser was finished
<kees> Keybuk: there's a ton of CPU time available during the fsck phase
<ogra> Keybuk, so did that change recently ? it seems it only stopped working recently
<kees> Keybuk: like right after procps
<jdstrand> oh I see-- that wouldn't help the boot time would it? or am I missing something?
<Keybuk> kees: note that the fsck ends well before the sleep
<kees> jdstrand: it should help boot time because the CPU load would happen earlier
<Keybuk> in fact the fsck takes virtually no time
<Keybuk> so you should consider that sleep to be a bug that will be fixed ;)
<kees> Keybuk: oh.  :)  heh
<Keybuk> ogra: did what change recently?
<ogra> (the same user did an ltsp test at the beginning of the jaunty cycle and didnt report issues, ltspfs didnt change apart from teh install target for the rules)
<ogra> Keybuk, the environment handling
<kees> Keybuk: well, even when it's only AA loading, it's only at 50% cpu
<kees> Keybuk: so it seems like moving it earlier could help
<Keybuk> kees: you mean "using an entire core" ? :)
<Keybuk> ogra: I could read the changelog for you
<Keybuk> ogra: but I'm not going to :)
<kees> Keybuk: d'oh, is that a dual core?  heh
<ogra> :P
<Keybuk> kees: I think it pretends to be
<Keybuk> not sure
<Keybuk> there's enough "exactly 50%" stuff there
<kees> $ grep sleep /etc/init.d/* | wc -l
<kees> 63
<kees> *cry*
<jdstrand> kees: you, since it is dynamic labeling, what would be most cool is for apparmor to not actually load the profile until the protected binary is called
<jdstrand> s/you/you know/
<kees> jdstrand: yeah, have the kernel call out for it.
<jdstrand> kees: exactly
<Keybuk> . o O { binfmt module ? }
<Keybuk> no
<Keybuk> evil
<Keybuk> BAD
<Keybuk> BAD
<Keybuk> BAD
<kees> :)
<kees> it would need to be lighter than that: i.e. user space tells AA what to call out for, then when one of those executes, user space loads the DFA.
<kees> seems like a lot of engineering for this "problem".
<kees> Keybuk: out of morbid curiosity, which sleep is that in your bootchart?
<Keybuk> I don't know
<Keybuk> I haven't found it yet
<Keybuk> that's why it's still there ;)
<Keybuk> it's an insidious hiding sleep
<Keybuk> I don't quite understand why the script only appears as "sh" either
<ogra> hmm, i cant seem to find anything environment related
<Keybuk> or why logsave runs for so much longer afterwards
<kees> Keybuk: well, I assume it's related to the trickiness pitti created for the usplash-integration-and-skipable-ness.
<kees> though there aren't any long sleeps in there.
<Keybuk> that's my guess
<Keybuk> but as I said, I can't quite find it yet
 * kees nods
<Keybuk> it vexes me
<pitti> Keybuk: hm?
<pitti> Keybuk: scripts in /lib/init/ perhaps? (they are sourced)
<kees> pitti: the longest sleep in there is the 0.5 in the progress loop.
<kees> doesn't seem likely.  *scratch head*
<Stskeeps> udev? :P
<Stskeeps> nm
<kees> Keybuk: seems crazy but, could stuff like "exec 9<&0 </etc/fstab" make bootchart lose the cmd name?  I can't imagine how.  hrm
<RainCT> (btw, someone has just asked me why rsync runs by default at boot on Jaunty)
<Keybuk> RainCT: it doesn't
 * kees holds onto his hat while apt-get dist-upgrade runs
<savvas> rsyncd ?
<ogra> Keybuk, hmm, but each of these not run scripts still spawns a subshell to check for the default value
<ogra> not that it would be much time, but it still costs some
<Keybuk> ogra: ?
<ogra> rsync
<ogra> rsync is installed on every ubuntu system, on boot it spawns a /bin/sh, sources /etc/default/rsync and exits
<ogra> Keybuk, so these actions take time
<ogra> nanoseconds likely, but they do
<Keybuk> correct
<ogra> so its not a totally unreasonable question why we do include these off-by-default scripts
<ogra> its one useless fs access at least to read the defaults
<jdong_> ogra: I don't get why rsync isn't separated into a client and server...
<jdong_> I mean the rsync command is very useful IMO
<jdong_> but rsyncd has less of an average user usecase
<ogra> yeah, especially since you can use a daemon like mode through ssh
<jdong_> right. That's my #1 usecase for rsync.
<jdong_> #2 would be for long local copies where its progress indication is helpful
<RainCT> mpt: Btw, on a dual head setup notify-osd doesn't show up on the same screen as gnome-panel. Should I file a bug about it?
<mpt> RainCT, any new bubble should appear on whichever display the mouse pointer is on at the time. If that's not happening (or if that's a horrible design for someone reason), please do report a bug.
<RainCT> mpt: Oh. Just tried moving the cursor around and it's always on the same screen. (And yesterday it was on the other one.. :P).
<RainCT> (I'm on Intrepid, though, not sure if that makes any difference..)
<mpt> ok, that's a bug then :-)
<mpt> I don't think that makes a difference, that's core notify-osd behavior
<asac> anyone here with a huawei 3g stick that uses the "normal" option driver?
<RainCT> asac: I used to use one :P. What's the "normal" option driver?
<asac> RainCT: the not normal option driver is "hso" ;)
<asac> RainCT: if you dont have it anymore it doesnt matter ;)
<RainCT> I don't see anything like that in nm-applet
<RainCT> mpt: Alright, filed bug #336848
<ubottu> Launchpad bug 336848 in notify-osd "Notifications show up on the wrong screen" [Wishlist,New] https://launchpad.net/bugs/336848
<mpt> thanks
<kees> Keybuk: it is the usplash sleep -- it's just showing up as a single process when it's multiple sleeps.  (I see the same from the dhclient sleep 0.1)
<kees> Keybuk: my boot chart is silly slow
<Keybuk> hmm, interesting
<Keybuk> why is it even sleeping
<Keybuk> fsck has no progress to report
<kees> Keybuk: from looking at the loop, I think it leads with a sleep instead of ending with a sleep.
<kees> but it's got 0.5 granularity, so dropping it to 0.1 would probably make the bulk of it go away
<kees> my bootchart is ALL io bound.
<kees> it seems like readahead-list isn't backgrounded?
<Keybuk> could it just not sleep at all?
<Keybuk> kees: readahead isn't backgrounded deliberately
<kees> ah, cool.
<kees> Keybuk: check with pitti, the scripts are pretty sensitive there
<BUGabundo> apw: ogasawara ping
<BUGabundo> any of you guys (or anyone else from kernel debug team) here?
<apw> BUGabundo, ?
<BUGabundo> so that vbgunz can find help with his SATA disk prob on resume?
<BUGabundo> hi apw... meet vbgunz
<BUGabundo> vbgunz: please describe your prob
<BUGabundo> do you have a LP bug too?
<apw> is it a kernel problem?
<vbgunz> hello everyone. Been on Jaunty for a while and everything is great. honest. just great. *but* no matter what I try, I can never suspend to ram or disk whether S1 or S3 in bios, BIOS or OS wakeup. everything comes back from resume after about 1 minute *but* the sata disk is dead :(
<apw> if so do it over on #ubuntu-kernel
<apw> and how do you know the disk is dead?
<vbgunz> apw: I cannot read or write to it, and somewhere in the terminal I always get a I/O denied to /dev/sda which is my sata disk
<ogra> (using a multimeter ? :) )
<BUGabundo> heeheheeh
<vbgunz> heh
<BUGabundo> ogra: just can't "shock" it to life...
<apw> are you able to run dmesg?
<apw> specifically if you run dmesg before you suspend
<apw> so its caches first
<ogra> BUGabundo, cold water might ...
<vbgunz> I cannot run any sudo commands at all what-so-ever ... e.g., sudo mount -a ... that disk is dead when I resume :(
<apw> yep, you would need the command to be already loaded
<vbgunz> well, after about 1 minute after resuming  everything appears on screen the way I left it
<vbgunz> it sleeps in seconds. wakes up after about a minute. cannot do anything
<apw> so run dmesg, suspend, resume, run dmesg
<apw> and see if that at lest lets you see the kernel logs from the suspend/\resume
<BUGabundo> apw: do you think a serial link could help debug it too?
<apw> if they can see the dmesg output we'd be ok
<vbgunz> I tried the 2.26.29 kernel from ppa. I read the resume/suspend was solved in that version *but* no matter what. I get the same results :/
<vbgunz> apw. even if I could see the anything, I wouldn't know what to do with it... I thought I would be slick the other day but no matter, so much reading and writing is supposed to happen on my sata that I cannot do anything... I tried creating a file on MS and the file protocol died
<apw> you got a digital camera?
<apw> photos is a common way to get the information to us
<vbgunz> heh, believe it or not, sent it in for repair :/
<apw> always the way
<apw> well you can give us a feel for whats in there if it comes out
<Codd> I tried asking this in the ubuntu channel and google but It might be a bit advanced of a question.  Is there a way from the kernel arguments on start up to make a live session automatically use restricted drivers over the OSS ones?
<vbgunz> I've got 2 sonys, both died at the same time. worse ever :/
<apw> anything relating to the disk
<vbgunz> well. I have other disk... Cant I just reroute these messages or logs to my IDE drives? I think they come back *but* I am not absolutely sure... I cannot do anything from the desktop about it :(
<BUGabundo> vbgunz: $dmesg > /mountpoint/otherdisk/log.txt ?
<BUGabundo> or $ pastebinit -i /var/log/kernel.o.log
<apw> so can you switch to VT-1 ?
<apw> something else to try
<apw> sounds like BUGabundo can talk you thought it all :)
<BUGabundo> me ? noo lol
<apw> then get a bug filed with all the info
<apw> agaainst the linux package
<apw> we do need that dmesg output i recon
 * BUGabundo vbgunz you can always zero absolute the machine and dump the contents of the memory while in resume eeheh
<vbgunz> man anything to get a better log
<vbgunz> I dont want to break anything. everything is fantastic. godforbid I suspend though. nightmare :(
<vbgunz> damn. I thought I saw a command in here. dmesg, sleep, resume, dmesg or something
<vbgunz> ok can someone provide the command to keep my logs or dmegs going to my MS *after* resume?
<vbgunz> I'll try it now just to bork it all *but* hopefully I can save a log
<LaserJock> cjwatson: absolutely brilliant blog post, thanks so much for that
 * highvoltage fires up liferea
<mr_pouit> slangasek: why would my sync requests need a FFe? It updates xfce* from 4.6rc1 to 4.6, which is bugfix-only, and thus doesn't require a FFe (and this was described in the sync requests...).
<vbgunz> the second dmesg was never written. My bios though was using S1. I have better luck with S3 ... atleast I get back to a dead desktop :)
<vbgunz> am going to try it again...
<BUGabundo> bye
<BUGabundo> let me know how it goes
<gimpuzmani> hi
<gimpuzmani> hello
<vbgunz> yeah! I got the second dmesg
<vbgunz> in it are the I/O errors I was talking about
<vbgunz> do you guys want the one *before* and *after* or just after?
<vbgunz> http://dpaste.com/4775/
<vbgunz> thats after
<vbgunz> IntuitiveNipple: I managed to save a dmesg after a failed resume, can you check it out http://dpaste.com/4775/ ?
<IntuitiveNipple> vbgunz: That's better! Add it to the bug report
<vbgunz> ok
<vbgunz> I think the hell starts at line 1283
<vbgunz> sda is my sata disk that keeps dying on resume
<IntuitiveNipple> vbgunz: Let's switch this conversation to #ubuntu-bugs
<vbgunz> ok there
<slangasek> mr_pouit: hmm, I don't see any mention in bug #336180 that this was bugfix only... anyway, approved by cody-somerville, so all done now :)
<ubottu> Launchpad bug 336180 in gtk2-engines-xfce "Please sync gtk2-engines-xfce 2.6.0-1 (universe) from Debian experimental (main)" [Wishlist,Fix released] https://launchpad.net/bugs/336180
<mr_pouit> "This is the final release (jaunty ships the rc1 for the moment). There's no Ubuntu delta."
<mr_pouit> I don't know lots of upstream developers that add new features between a RC and the final release. ;)
<ScottK> slangasek: Did you see my earlier ping about clamav?
<slangasek> ScottK: yep, was just grabbing it now
<ScottK> slangasek: Great.  Thanks.
<maxb> mr_pouit: Oh, you're so trusting! :-)
<mr_pouit> maxb: I'm subscribed to svn commits, so, kind of :P
<maxb> ah, fair enough. If you can truthfully state "I have verified the changes between rc1 and final are bugfix-only in nature" then you should definitely do so in the bug - then there's no ambiguity regarding the need for a FFe
<maxb> So... I have a perplexing problem. Recently, in Jaunty, one of my partitions (and only one, out of three ext3 partitions on the disk) has suddenly started getting the wrong uuid in /dev/disk/by-uuid/ - it's not even the right format - rather than being a true UUID, it's just 16 hex digits. Any prods towards where I should be debugging?
<maxb> btw, blkid is still reporting the true uuid
<slangasek> zul_: fyi, I'm planning to request a FFe for samba 3.3.1 and handle the merge on it
<slangasek> (there's a bit of cruft I want to get pulled out of the Ubuntu delta...)
<zul_> slangasek: what cruft?
<slangasek> zul_: changes to every one of the .po files; plus some winbind changes that are obsolete because they were done in Debian in a different way (but the patch still applies)
<zul_> slangasek: sounds good to me
<vbgunz> fellas. the pci=nomsi solution worked. I could actually resume from a suspend... I am just curious. is this a good idea or what? I feel it could be hackish or not wise. would like any input on solving the real problem if one exists
<vbgunz> im excited. I need to try suspending one more time. brb hopefully without rebooting
<vbgunz> no way. this is just great :D
<calc> pitti: followed up to the email
<vbgunz> wow. my second resume. its working for me :)
<calc> pitti: looks like OOo schedule is going to slip yet again, so i'm glad we stick with the version released at feature freeze :)
<calc> pitti: the first rc looks like it will be released march 19 and possibly 6 or more rc's will be needed (like with 3.0)
<mrooney> 6 or more RC's? O_o
<emgent> calc: ping
<kirkland> where might i find someone to help with an lpia build error?
 * kirkland sees no #ubuntu-lpia channel
<cody-somerville> kirkland, lpia is just i386 really
<cody-somerville> kirkland, whats your build problem?
<Mithrandir> kirkland: #ubuntu-mobile, possibly?
<kirkland> cody-somerville: http://launchpadlibrarian.net/23315733/buildlog_ubuntu-jaunty-lpia.kvm_1%3A84%2Bdfsg-0ubuntu6~ppa1_FAILEDTOBUILD.txt.gz
<kirkland> Mithrandir: thanks.
<kirkland> cody-somerville: nevermind
<kirkland> cody-somerville: found my problem, sorry to bother
<cody-somerville> :)
<kirkland> Keybuk: around?  did you get a chance to read my comments on https://bugs.launchpad.net/bugs/71418
<ubottu> Ubuntu bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed]
<alex-weej> cjwatson: thanks for saying something about expiring bugs on planet today. that has really annoyed me as the list of minor bugs i have reported over the years has constantly been chomped at by karma hunters...
<mathiaz> james_w: hi - do you have a workaround/patch for bug 336686?
<ubottu> Launchpad bug 336686 in bzr-builddeb "merge mode doesn't work under python2.6" [Critical,In progress] https://launchpad.net/bugs/336686
<james_w> mathiaz: in a branch
<james_w> I'm trying to prepare an upload now
<mathiaz> james_w: great - mysql-dfsg-5.1 will be happy again after that :)
<james_w> if can tell you what to edit if you need it to work right now
<james_w> though I will need to get an FFe for this upload, perhaps I should upload the fix for that directly
<mathiaz> james_w: that would be helpful
<mathiaz> james_w: I've --export-only and then debuild -S
<james_w> good idea :-)
<mathiaz> james_w: hm - expect the dsc file is not there
<mathiaz> james_w: oh - nevermind
<cjwatson> LaserJock,alex-weej: glad you liked it
<LaserJock> cjwatson: you nicely articulated exactly what I've been thinking
<LaserJock> made my day
 * ScottK gives a big +1 for cjwatson's blog post too.
<ScottK> Definitely much more diplomatic than I'd have managed too.
 * ogra wants a t-shirt "Bugs are not like fruit" :)
 * directhex hands ogra an apple with some bugs in it
<ogra> :P
<vbgunz> yeah. after walking away and leaving the system suspended in ram for 30+ minutes. I turn it on and all is well *but* I am not prompted for a password :(
<vbgunz> should I just make a script that'll lock up the system *then* suspend?
<Caesar> So, EOL for Dapper on the desktop, June 1 or June 30?
<Caesar> Is there anything authoritative in writing anywhere?
<Nafallo> https://wiki.ubuntu.com/DapperReleaseSchedule <-- looks like June 1st, but I can neither confirm, not deny.
<Nafallo> s/not/nor/
<Caesar> Nafallo: yeah, that's far from really clear on it
<slangasek> the support cycle is generally measured from the actual release date.  I haven't heard otherwise from anyone regarding dapper.
<Caesar> That would imply it's June 1 though
<Caesar> slangasek: nowhere (that I've found) really spells out how support will continue for servers for the remaining two years
<Caesar> Presumably a subset of packages will still receive security support
<slangasek> yes, that's the intent; I don't know the details of what will or won't be included in the server security support
<slangasek> nijaba: is that your department?
<Caesar> I'm just looking for something vaguely authoritative to point my management at
<kees> Caesar: check this script: https://launchpad.net/ubuntu-maintenance-check
<nijaba> slangasek: https://code.launchpad.net/ubuntu-maintenance-check will tell you which packages are maintained for how long on any given system.  Seeds have been reorganized so that we can tell.
<slangasek> nijaba: the historical dapper seeds have been reorganized?
<nijaba> Caesar: http://www.ubuntu.com/products/whatisubuntu/serveredition/benefits/lifecycle should be considered authoritative by your management
<nijaba> slangasek: yep
<slangasek> ok, great
<nijaba> slangasek: that's what I started with, then moved up to current
<nijaba> slangasek: I am glad Colin helped though :-)
<Nafallo> :-)
<Caesar> nijaba: there are exactly zero precise dates at that URL
<Caesar> So I have to operate on the assumption that it's the release date + n months
<Caesar> Which is fine
<nijaba> Caesar: oh, you want precise dates. then your assumption is right
<Caesar> That URL also doesn't clarify what goes on in the 3-5 year life of an LTS
<nijaba> Caesar: but you are right, I think we should start an EOL announcement page
<Caesar> \o/
<nijaba> slangasek: that would be more in your field, but I'd gladly start something
<ScottK> nijaba: Are past-EOL packages going to be moved to old-releases?
<elmo> scottk: that'd be mad crazy difficult
<LaserJock> how'd that work?
<elmo> (so I really hope not)
<slangasek> nijaba: I'd be happy if you could get it started.  Previously the EOL announcements have all followed the same pattern, so there wasn't much need to draft
<nijaba> slangasek: what I thought was more of a summary page with release and EOL dates
<ScottK> elmo: I have no idea, but leaving them in place leaves an odd catagory of packages that hasn't previously existed.
<ScottK> Generally not supported means community supported.
<slangasek> nijaba: hrm, ok
<ScottK> As a community dev, am I still expected to care about these packages?
<Tonio_> slangasek: hi, I just commented out about skrooge in NEW.
<nijaba> slangasek: what did you have in mind?
<LaserJock> ScottK: I think those packages are EOL
<ScottK> If not, that makes clamav backports for Dapper much easier after June.
<LaserJock> not community-supported
<Tonio_> slangasek: also as promissed I fixed kdesudo packaging properly and fixed the seeds so that the dvd depends on kdesudo and not kdesudo-kde4...
<ScottK> It seems odd to have them there, but not there so to speak.
<LaserJock> they're there, but the just have no support whatsoever, as far as I can tell
<LaserJock> *they
<slangasek> nijaba: I assumed you were talking about how to properly communicate the dapper EOL when it's announced.  I don't know that a wiki page to track what's EOLed should be necessary, shouldn't it be enough for the website to state the release dates + the support length? (don't we have this already?)
<slangasek> Tonio_: ok, thanks :)
<nijaba> slangasek: I just thought that it might be clearer if, instead of the algorythm to compute the date, we actually write them down so that people don't have to be guessing
<Caesar> +1
<nijaba> slangasek: but I'll start a draft of the dapper desktop EOL, as it might need more details than the usual one
<nijaba> anyway -> really bed time for me now
#ubuntu-devel 2009-03-03
<phil_ps1> general question regarding libraries....the answer will save me time...
<phil_ps1> is it possible to have a program and its plugin both use the same instance of a library?
<phil_ps1> there is a problem with globals...
<maxb> provided it's a dynamic library (.so) it should work fine, IIUC
<lifeless> phil_ps1: its normal
<lifeless> phil_ps1: its a problem for a progrm and plugin to use different instances
<phil_ps1> I don't understand how to make them the same instances...
<phil_ps1> *how to make them use the same instances...
<lifeless> they will by default
<phil_ps1> okay, maybe this is not the problem.  I just read it was...have to verify it
<lifeless> you have to go to some effort [or some special edge cases] to avoid it
<phil_ps1> read it on a bug report....https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/248684
<ubottu> Launchpad bug 248684 in pidgin-otr "pidgin resolver process crashes with ldap accounts" [Undecided,Confirmed]
<lifeless> packaging is potentiall one such edge case :P
<phil_ps1> asked here because people would know about libraries...sorry if its the wrong topic...
<lifeless> phil_ps1: https://bugs.edge.launchpad.net/ubuntu/+source/pidgin-otr/+bug/248684/comments/7
<ubottu> Launchpad bug 248684 in pidgin-otr "pidgin resolver process crashes with ldap accounts" [Undecided,Confirmed]
<lifeless> phil_ps1: not libraries in general, one specific library, apparently.
<phil_ps1> yeah that is what I read...trying to find a fix...without exhaustively removing globals
<phil_ps1> okay, I will read more about libgcrypt...thanks lifeless
<lifeless> phil_ps1: so, its nothing to do with libraries
<Skiess1> graphics on my Lifebook C1020 default to vesa, which I think is wrong...
<lifeless> phil_ps1: imagine you have two different uses for the gcrypt functions in one program, - two unrelated uses.
<phil_ps1> okay
<lifeless> phil_ps1: as long as that works, without the programing needing its own globals, it will work fine if the gcrypt stuff is in alibrary; if not it won't
<lifeless> [IOW, globals are bad, get rid of them]
<phil_ps1> yeah, pidgin dies when a whole bunch of threads are spawned...
<phil_ps1> so there is a shared state
<phil_ps1> yes, I agree, globals are bad
<phil_ps1> (what does IOW mean, I am new. :)
<StevenK> In Other Words
<phil_ps1> I should make a program that first finds globals...would help in my parallel computing research...
<phil_ps1> thanks StevenK
<phil_ps1> oh, wait I have one....
<phil_ps1> by my professor...
<phil_ps1> for grading student's assignments
<phil_ps1> we enforce no globals, no public data, cyclomatic complexity of function < 10, line count of function < 50 lines
<phil_ps1> maybe things in here will fix my problem...http://olympus.het.brown.edu/cgi-bin/dwww?type=file&location=/usr/share/doc/libgcrypt11-doc/html/gcrypt_2.html#SEC9
<phil_ps1> also my ibm desktop ubuntu installation doesn't work...
<phil_ps1> I get as far as a login screen and then just a black screen
<phil_ps1> is this because no video driver?
<slangasek> Tonio___: knemo seems to have the same problem, no FFe for a new package
<slangasek> (and not even a needs-packaging bug for this one)
<lamont> why is my jaunty debootstrap pulling in an MTA?
<lamont> admittedly, the script is also installing a boatloadd of build-deps
<Tonio___> slangasek: yeah, I discussed this with Riddell... it was in the repos as a KDE3 app but was removed in the KDE4 transition...
<Tonio___> slangasek: shouldn't be considered a new app for him, as well as kblogger
<slangasek> Riddell: ^^ is knemo ok to re-add to the archive (FFe)?
<slangasek> lamont: which MTA?
<Tonio_> slangasek: I know a bug would have been nice, but I expected him to take care of that sooner, hehe :)
<slangasek> lamont: oh, you're running a script - SEP :-P
<slangasek> Tonio_: ok, I can just leave those in the queue for Riddell to review ;)
<Tonio_> sladen: yup, that should concern kblogger and knemo, and skrooge is waiting for your or his approval...
<lamont> slangasek: halley:~lamont/make-chroot.sh
<Riddell> slangasek: yeah I'll get to them tomorrow
<slangasek> lamont: so maybe the 'ssmtp' listed as a build-dep is the clue? :)
<slangasek> lamont: also, did you mean to install git-core instead of git? :)
<lamont> heh
<lamont> dunno
<slangasek> oh, you're grabbing the build-deps /of/ the packages listed in builddep... hmm
<lamont> slangasek: it'll have git-core and a few other things (kernel builddeps) before I'm done with it
<slangasek> anyway, smartmontools Recommends: mailx | mailutils, mailx Depends: m-t-a
<lamont> ah ha
<Tonio_> Riddell: thanks :)
<lamont> it was more one of "wtf??" without otherwise looking at it
<mrooney> Hmm, anyone have any input on bug 336992, is that expected?
<ubottu> Launchpad bug 336992 in ubiquity "UUID of existing partitions are changed" [Undecided,New] https://launchpad.net/bugs/336992
<greg-g> pitti: what is the likelihood of getting an update of apport for hardy/intrepid to include the apport-collect feature? as it is a new feature I don't believe it qualifies for a SRU.
<mrooney> greg-g: that could be pretty awesome
<greg-g> pitti: after testing it, I see it requires a new dependency (python-launchpadlib) so that probably decreases the chances even more.
<greg-g> mrooney: yeah, it would be great
<calc> doko: are you in charge of libxalan2-java? :)
<roy_hobbs> Hey, if I'm commenting on a bug in launchpad, how do I reference a bug properly so that it shows up as a link to that bug?
<ScottK> Bug #nnnnnn is enough
<roy_hobbs> thanks
<ScottK> YW
<leftyfb> where can I go to find the changes in the latest kernel/headers/restricted modules ?
<ebroder> I know this is a little off-topic, but does anyone know of a package that will list the files that dpkg's database doesn't know about?
<TheMuso> ebroder: apt-file
<LaserJock> TheMuso: will that list files that dpkg doesn't know about?
<ebroder> No, no - I'm trying to figure out where all of my data is so I know what to backup on this machine. I want to know the files that are currently on my system that dpkg didn't put there
<TheMuso> LaserJock: it will list files from packages that dpkg doesn't yet know about
<TheMuso> ebroder: ah ok
<TheMuso> well you could script something.
<TheMuso> get a list f all files on your system, dump all package file lists of isntalled packages, and compare.
<ebroder> Yeah, sure
<ebroder> That was what I was going to do if someone hadn't done it already :)
<LaserJock> I suspect that'll be very unhelpful though
<leftyfb> Anyone know where can I go to find the changes in the latest kernel/headers/restricted modules ?
<LaserJock> maybe not "very", but there's a lot of stuff there that are created postinst, for instance
<TheMuso> LaserJock: good point
<ebroder> LaserJack: Maybe. I'm willing to see what it comes up with. It might be filterable by-hand
<LaserJock> and you've got things like /var
<ebroder> Hmm...yeah, but a lot of the files I want this script to track down are in /var. Maybe I can come up with a relatively short blacklist
<LaserJock> anyway, not saying you shouldn't do it, but you're like to get thousands of files and going through by hand might be a bit tedious
<LaserJock> *likely
<foxbuntu> leftyfb, look here: http://packages.debian.org/search?keywords=kernel&searchon=names&suite=stable&section=all
<leftyfb> foxbuntu: how does that help me?
<leftyfb> that's not ubuntu or the latest kernel
<foxbuntu> leftyfb, the Ubuntu kernel comes from upstream Debian
<leftyfb> I didn't think every update came from upstream. There is a kernel dev team at ubuntu
<LaserJock> leftyfb: are you wanting changelog or patches?
<foxbuntu> leftyfb, they submit upstream
<leftyfb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/322879
<ubottu> Launchpad bug 322879 in linux "Verizon CDMA card no longer works" [High,Incomplete]
<LaserJock> foxbuntu: not everything comes from Debian
<dtchen_> leftyfb: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty{,-lrm}.git;a=summary
<leftyfb> i'm looking to see if that was fixed in the latest update that was pushed yesterday
<foxbuntu> LaserJock, not saying it does
<dtchen_> leftyfb: replace jaunty with the intended Ubuntu release
<leftyfb> it seems to be working, but I'd like to confirm it was fixed and then submit that that bug be closed
<leftyfb> dtchen_: 403 Forbidden - No such project
<dtchen_> leftyfb: that's shorthand for http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=summary and http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty-lrm.git;a=summary
<ebroder> LaserJack: Apparently `diff -u <(sort -u /var/lib/dpkg/info/*.list) <(find / -xdev)` runs pretty damn fast :)
<leftyfb> dtchen_: thanks ... might have found what I was looking for
<leftyfb> do you think "  * USB: gadget: cdc-acm deadlock fix" is what fixed the bug i posted previously?
<ScottK> foxbuntu: The kernel is one place we explicitly do not take from Debian.  Generally we are on a newer version than Debian and the kernel team works directly from upstream kernel sources.
<foxbuntu> ScottK, ah, well thanks for clearing that up for me
<TheMuso> However the way the kernels are built is loosely derived from Debian.
<ScottK> True.
<ScottK> So if your interested in kernel packaging methods, Debian is a good place to look.
<Ademan> does anyone know how I could run a process after a given amount of idle time? (as root) is that something i could do via upstart?
<jdong_> haha what's "idle time" defined as?
<Ademan> jdong_: user idle time I guess?  based on mouse/keyboard use.
<jdong_> I don't think at this time that's an upstart answerable question
<jdong_> I guess you can have a proxy in each user's X session that reports whether it's idle
<Ademan> jdong_: :-/  any idea how gnome-screensaver does it?  I'm not sure I want to depend on the same mechanism, but if that's the best i've got i'm interested
<bryce> tjaalton_: hmm, on fdo #19574 it is said that our patch 156 should be upstream, however the change doesn't appear to be present in our xserver git tree
<Ademan> i suppose xscreensaver probably uses the same method, whatever it is,
<bryce> tjaalton_: this is our bug 311254 btw
<ubottu> Launchpad bug 311254 in xorg-server "Xorg crashed with SIGSEGV in CopyKeyClass()" [High,Fix released] https://launchpad.net/bugs/311254
<jdong_> Ademan: yeah I would guess it's a *-screensaver API call on the GNOME side
<jdong_> Ademan: also look at how gnome-power-manager grabs idle time for DPMS blanking
<jdong_> because that also works on the KDE side
<Ademan> thanks jdong i'll poke around
<jdong_> which leads me to believe there's some DBUS-ish call for it
<jdong_> or other freedesktop.org tpye call
<Ademan> hrm, i didn't think kde 3.x used dbus at all... either way... freedesktop may have a spec for that, thanks
<pitti> Good morning
<ion_> Ditto
<bluefox_> http://sourceware.org/ml/binutils/2009-03/msg00032.html  Relevant to anyone who likes playing with the toolchain
<pitti> calc: ah, thanks for the heads-up
<bluefox_> and also because I'm crazy and need attention so I can fill an information gap (i.e. why the hell does/doesn't this work and why hasn't it been done this way if it actually works as I think)
<pitti> greg-g: apport-collect> indeed; you can get it from http://people.ubuntu.com/~pitti/scripts/apport-collect and ask people to run it; it will point out that you need to install python-launchpadlib
<a|wen> cprov: can see you are a soyuz contact, i'm sorry for disturbing you this unorthodox way, but we are a little in a hurry, kde4.2.1 is due out today and we've reach the limit in the ppa for release packaging -> https://answers.launchpad.net/soyuz/+question/62925
<Hobbsee> morning pitti
<Mithrand1r> yo, Hobbsee
 * Hobbsee stomps on Mithrand1r's feet
<Hobbsee> hello, imposter!
 * ion_ returns Mithrandirâs i, thanks for the loan.
<Mithrandir> 08:37 -NickServ(NickServ@services.)- 31 failed logins since last login.
<Mithrandir> hmm
<StevenK> 31 imposters?
<Mithrandir> or just one who's trying a fair bit.
<Hobbsee> unless it was yours :P
<Mithrandir> last time I checked, I did not irc off a host in Germany.
<StevenK> Perhaps you need to check again
<Hobbsee> blame pitti.
<lifeless> .com?
<Hobbsee> it must be pitti's fault.
<pitti> sheesh!
<StevenK> pitti: architecture-mismatches.txt looks tasty. I'm happy to sort it out, but should I be demoting or promoting?
<lifeless> ugh, I'm lost where on cdimage.ubuntu.com/releases/intrepid/release is a plain ol 32-bit live CD
<StevenK> lifeless: It's on releases.u.c
<StevenK> http://releases.ubuntu.com/intrepid/
<lifeless> *thats* not confusing at all. No really.
<lifeless> (thanks btw)
<lifeless> I could rant more if you like
<lifeless> if hal loses the plot
<lifeless> how do I get it to release the .hal-mtab lock and start over
<pitti> StevenK: promote; it's recommended by libgpod4
<pitti> StevenK: that is, gpod-common; python-gpod doesn't have main rdepends, so that should be demoted
<StevenK> pitti: Okay, gpod-common gets a promote, and python-gpod gets demoted. I'll sort it out.
<pitti> StevenK: great, thanks
<seb128> pitti, StevenK: if somebody of you does some NEW could you give a quick review to nautilus-sendto-universe and evolution-mapi? I did work with the contributors on those so would be nice to have somebody else checking too
<lool> mvo: You might recall I had lost my keybindings in compiz after an upgrade?  this was on my desktop and it hit my laptop yesterday (hadn't updated it for a while)
<seb128> lool: is the gnome compat option enabled?
<lool> seb128: I can't check on the laptop right now, but it was enabled on my desktop
<mvo_> lool: I suspect the gnome compat module, I'm not 100% sure what the best way to fix it is, but I have it on my radar
<lool> seb128, mvo_: Was disabled indeed
<lool> mvo_: Ok if you know about it then I'm fine
<mok01> Keybuk: ping
<Keybuk> mok01: hello
<mok01> Keybuk: hi
<mok01> Keybuk: have you seen I've proposed a branch for merge with m-o-m
<mok01> ?
<Keybuk> no
<mok01> Keybuk:  https://code.edge.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/+merges
<mok01> Keybuk: it's a couple of very simple things
<Keybuk> could you e-mail me, and I'll take a look at some point
<mok01> Keybuk: sure
<Keybuk> someone else is working on a redesign of MoM's pages (RainCT), you might want to co-ordinate with him
<mok01> Keybuk: it's rainct
<mok01> Keybuk: will do, ok! Thanks!
<Keybuk> pitti: gnargh
<Keybuk> I have to update all my slides
<Keybuk> DeviceKit is no more
<pitti> Keybuk: huh?
<TheMuso> wooa if thats true
<pitti> Keybuk: 003 was just released yesterday
<pitti> http://hal.freedesktop.org/releases/
<TheMuso> as in my goodness
<pitti> Keybuk: is it DavidKit now?
<Keybuk> did you read the release notes? :)
<pitti> Keybuk: no
<pitti> what, back to hal?
<Keybuk> ah, read them ;)
<pitti> Keybuk: url?
<Keybuk> no
<Keybuk> basically the current DK will become simply the D-Bus API to udev
<Keybuk> and the D-Bus name will be just org.kernel.udev
<Keybuk> you'll still have DeviceKit-power and stuff
<pitti> aah
<pitti> Keybuk: I didn't see release notes on http://cgit.freedesktop.org/DeviceKit/DeviceKit/tree/
<TheMuso> are there still plans for device kit sound, as that seems pointless now, at least to me
<Keybuk> TheMuso: pointless how?
<pitti> Keybuk: nice if it just gets integrated into udev
<Keybuk> http://lists.freedesktop.org/archives/devkit-devel/2009-March/000123.html
<TheMuso> Keybuk: well most sound related stuff goes through alsa-lib
<TheMuso> if not all of it
<Keybuk> I didn't know there were plans for a DK-sound
<Keybuk> since HAL doesn't really have any kind of sound API right now
<TheMuso> Keybuk: I thought there were, but I don't know where i heard that
<lifeless> is there an offline bug reader for lp ?
<pitti> email?
<Keybuk> random Q of the day
<lifeless> pitti: bah
<Keybuk> does anyone have a machine that doesn't have ACPI anymore?
<lifeless> pitti: that doesn't go back in time
<lifeless> Keybuk: is that new or old? I have a pentium that I still can't boot a current ubuntu kernel on ...
<Keybuk> lifeless: when was the last time you could boot it?
<lifeless> Keybuk: couple of releases back, its my firewall :P
<Keybuk> did it work on hardy?
<geser> lifeless: try leonov, iirc it has some caching so you can use it offline
<lifeless> Keybuk: don't think so, I thik thats where I started complaining to ben :P
<lifeless> Keybuk: anyhow, if you want before-acpi, that may qualifyt
<Keybuk> I'm asking because we don't have any bugs that I can see that non-ACPI machines aren't working anymore
<Keybuk> and we think they've been broken for a couple of releases now
<Keybuk> and since nobody's complained
<Keybuk> and we hadn't actually noticed they were broken
<apw> lifeless, i have an old clunker which does work even though acpi says "noooooo"
<Keybuk> that maybe we should just note that we don't support them anymore :p
<lifeless> Keybuk: how can I tell its non-acpi ?
<apw> lifeless, what is the symptoms?
<apw> if you can't boot it it is hard
<lifeless> apw: my one, is hard-lock on boot
<apw> last thing it says?
<lifeless> apw: no monitor :P
<cjwatson> I don't understand this "nobody's complained" mentality
<apw> heh
<lifeless> apw: and I last tried about 9 months back
<cjwatson> doesn't it mean "I haven't seen any complaints"?
<lifeless> apw: because its such a high hurdle to test
<cjwatson> unless you read all bug reports and all forums posts :-)
<lifeless> best way to tell if a machine (thats running) is acpi ?
<apw> cjwatson, yeah it means the machine is blowing up and noone has brought it to the attention of <someone who cares>
<cjwatson> I suspect it may just be that developers are biased towards newer machines, and so there is a higher chance that people with older machines will report problems in the "wrong place"
<cjwatson> I'm not sure that translates accurately into "nobody complained"
<apw> cjwatson, i think that is very likely
<lifeless> 2.6.15-23-386,
<apw> we are demand dirven though as we have nothing to test on
<lifeless> model name      : Pentium 75 - 200
<apw> it took me half a day to get this machien with a floppy to even work
<cjwatson> no, I understand that, I just dislike the "nobody managed to file bug reports, let's bin it" approach
<lifeless> cjwatson: me too :P
<lifeless> Keybuk: its running 8.04
<apw> cjwatson, indeed, but if we lost something and didn't notice and need to maek a kernel change to fix it but cannot as we have none, its very hard to do anything about
<lifeless> apw: do you know, how I can tell if this is acpi or not ?
<apw> there are acpi_available and apm_available iirc
<apw> which exit 0 if there is some of that
<apw> apw@dm$ acpi_available ; echo $?
<apw> 0
<apw> apw@dm$ apm_available ; echo $?
<apw> 1
<lifeless> apw: neither command exists
<apw> gurgle
<lifeless> :)
<Keybuk> [ -d /proc/acpi ]
<Keybuk> :p
<apw> cat /proc/apm
<apw> ls -l /proc/acpi
<lifeless> $ [ -d /proc/acpi ]
<lifeless> robertc@lifelessgwy:~$ echo $?
<lifeless> 1
<apw> so no acpi
<apw> apm ?
<lifeless> cat /proc/apm
<lifeless> cat: /proc/apm: No such file or directory
<Keybuk> apw: apm only covers power, not device discovery/enablement
<apw> right, but having apm tells us you don't have acpi
<lifeless> Keybuk: so, I can't until next weekend, but then I can, get a newer kernel and see if its bootable and report back
<lifeless> Keybuk: and if it boots answer any other queries while I upgrade from 8.04
<apw> lifeless, sounds good to me
<Keybuk> apw: not necessarily
<Keybuk> I have a laptop that has both
<apw> double gurble
 * apw climbs back into his nice shiney acpi only world, la la la, can't hear you
<lifeless> Keybuk: will that help you?
<Keybuk> cjwatson: I'd claim the opposite
<Keybuk> thost people who are trying to run Linux on older machines are more likely to be tech savvy and trying to keep the older machines running, so more likely to complain in the right place
<Keybuk> (or at least complain somewhere audible)
<Keybuk> lifeless: I'd be interested to see the results
<lifeless> Keybuk:
<lifeless> bah.
<apw> Keybuk, a resonable conjecture
<lifeless> ok, will fiddle around to get a newer kernel and a monitor and give it a spin
<lifeless> if it doesn't work, I may bite the bullet and replace it, and shit it to you. Its about 1/8th of a cubic metre.
<cjwatson> Keybuk: neither of our opinions is supported by data, I suppose :-)
<Keybuk> lifeless: hey, I didn't say I was going to _fix_ it :p
<apw> Keybuk, that reminds me, if you are shipping an empty modprobe.d how are we handling blacklisting
<Keybuk> I'm somewhat concious that the amount of work needed to put code into the kernel to deal with the non-ACPI cases is so large and error-prone that it may simply not be worth it
<cjwatson> I keep reading stuff at the moment about how people are more likely to be recycling old machines in the depths of a recession, rather than buying new ones
<Keybuk> apw: they're probably going in /lib/modules/$(uname -r)/modules.conf
<apw> so we will be cslurping them up basically
<Keybuk> cjwatson: "old" in this case does mean "1999 and before though", no?
<apw> yeah i was amazed to find there was a floppy on a machine that worked any more
<apw> for osmeone to complain about it
<cjwatson> I've learned never to make that kind of generalisation :-)
<cjwatson> I was trying to get Ubuntu to work last night with a monitor that doesn't support DDC
<Keybuk> heh
<cjwatson> I'd say the monitor is at least 15 years old, at a guess
<apw> Keybuk, so are you handling the integration with the kernel or does someone here need to start thinking about it?
<Keybuk> "Writing X Mode lines for dummies"
<Keybuk> cjwatson: I think that's the point though - we don't actually support those monitors either right now, do we?
<TheMuso> cjwatson: Interesting you should say that, some cheap KVM switches out there don't support DDC either.
<cjwatson> I gave up, but I'd rather argue that I shouldn't have to
<cjwatson> because if I weren't an Ubuntu developer, I'd be installing some other operating system on it right now
<Keybuk> apw: I'll handle it ;)
<apw> Keybuk, ok cool.  /me scuttles off to his tunnels
<Keybuk> cjwatson: I'd be intrigued to know whether the current version of any other operating system works either <g>
<Keybuk> I'd wager lots of money that neither Vista nor Mac OS X would support that monitor
<cjwatson> I could, for example, reinstall the Windows 2000 that was on there when I got it
<Keybuk> Win 2000 is EOL
<Keybuk> you could install warty on it
 * apw wonders if hardy would work
<cjwatson> so what? (from the point of view of somebody who isn't an OS person)
<cjwatson> works > current
<Keybuk> I guess I don't see "the current version doesn't work -> use an older one" as a problem
 * sistpoty|work wonders wether qemu than does work OOTB with a daily, since iirc it doesn't support ddc either
<apw> we probabally don't recommend it loudly enough
<Keybuk> since that's generally the solution
<cjwatson> the operating system that was already there will get a free pass in a lot of people's minds, whether it's old or not
<apw> "if you have pre-2000 h/w" you might want to start with this version
<lifeless> Keybuk: security fixes
<cjwatson> some *other* old operating system will not get that same free pass
<Keybuk> lifeless: Win 2000 doesn't have security fixes from MS anymore
<lifeless> Keybuk: I don't use win2000, so thats irrelevant :)
<Keybuk> cjwatson: and this is the end of the world?
<cjwatson> Keybuk: oh FFS
<cjwatson> "this is a bug, I'm trying to get you to acknowledge that" != "end of the world"
<cjwatson> stop turning everything into the worst possible extreme
<Keybuk> I'm not saying it's not a bug
<Keybuk> I'm saying its a bug I'm inclined to Won't Fix
<cjwatson> or even "we should fix this" != "end of the world"
 * TheMuso has jaunty running on a dual celeron 466 box, and the board was from 1999. Works fine, appart from the broken mga driver for the matrox card in there last I checked. :)
<apw> TheMuso, woh thats old!
<apw> i should introduce it to my thinkpad 570e, they are the same age
<cjwatson> sistpoty|work: qemu support some modeline that X tries by default; this monitor apparently doesn't
<Keybuk> cjwatson: maybe that's where we're disagreeing here
<TheMuso> apw: heh, its an abit BP6. I keep it around because it has ISA slots, which allows me to muck around with some ISA hardware speech synthesizers i have.
<apw> cjwatson, the right thing to do is fedex the thing to bryce ...
<Keybuk> cjwatson: I'm not disagreeing that things don't work (they clearly don't)
<cjwatson> Keybuk: I have consistently been given direction that we are to support the long tail of hardware in Ubuntu
<Keybuk> I'm claiming that the effort to fix those things is probably too large compared to the benefit
<sistpoty|work> cjwatson: ah, makes sense
<Keybuk> cjwatson: and at some point, the tail has to end
<Keybuk> we can't support all hardware ever created
<Keybuk> maybe we'd like to
<Keybuk> but that's an awful lot of work
<cjwatson> I acknowledge that; I think you perhaps overestimate how frequently people upgrade hardware, though
<evand> I don't pretend to know what I'm talking about here, but just an idea, what if we only rip out support for non-ACPI machines in the desktop kernel.  That would allow people who really cared about getting Ubuntu running on their P2 to still do so through the server CD.
<cjwatson> I think we're cutting off a bigger tail than you think
<Keybuk> and you'd get into the strange situation that the exotic hardware you're supporting only exists in your labs, because you purchased all available models of that hardware to test it on ;)
<cjwatson> evand: this is about the work required to reintroduce support dropped due to a bug
<evand> oh, my mistake then
<cjwatson> evand: it's not about the space required to keep support
<apw> i would say peoples first experience with ubuntu is as often as not installed on their 'old' laptop after an upgrade
<Keybuk> it's not necessarily "because of a bug"
<cjwatson> Keybuk: that's a gross exaggeration, and unhelpful in this case
<cjwatson> pre-ACPI hardware is not as rare as all that
<Keybuk> it's not a "oh, look, a one line patch"
<Keybuk> or a "this little patch broke non-ACPI machines"
<cjwatson> "due to a bug"> OK, that was an excessive abbreviation
<Keybuk> it's "the kernel really assumes ACPI for a lot of things now, and there's no equivalent non-ACPI code"
<apw> cjwatson, i wonder if machines booted acpi=off count
<Keybuk> (and there probably wasn't any non-ACPI code before - since the kernel didn't bother with such niceties in those days)
<Keybuk> ie. we never had non-ACPI hotplug
<apw> it cirtainly assumed synchronised userspace
<apw> we did have userspace hotplug though
<apw> and its our removal if that which broke things
<Keybuk> we used to run isapnp and write config files, and then use those
<cjwatson> so the appropriate way to do this would be to post somewhere very public saying "we've discovered that we don't appear to support pre-ACPI machines any more; do you care? if so, please write to us"
<Keybuk> apw: nah, that was just how we _found_ this underlying problem
<apw> that is hotplug in userspace
<cjwatson> and assess the responses objectively
<Keybuk> cjwatson: which was my suggestion
 * TheMuso still has an ISApnp sound card, that actually still works.
<Keybuk> TheMuso: it should work on an ACPI-machine
<cjwatson> Keybuk: I didn't see that suggestion - where?
<TheMuso> Keybuk: It does.
<cjwatson> you said
<cjwatson> 11:46 <Keybuk> that maybe we should just note that we don't support them anymore :p
<cjwatson> which sounded like a release note "hi guys, unsupported, you lose" :-)
<TheMuso> anyway, bed time for me.
<Keybuk> cjwatson: somewhere, this conversation has crossed three channels and several bugs now ;)
<cjwatson> heh
<Keybuk> I started by asking lifeless ;P
<Keybuk> and I did start here by asking <g>
<Keybuk> (generally)
<cjwatson> right, and several people said that they had machines with issues
<cjwatson> didn't they?
<Keybuk> just lifeless so far
<cjwatson> and apw
 * apw has a machine whcih is affected too for the record
<apw> though i prefer not to admit its existance
<apw> Keybuk, i wonder if some combination of my fixes are appropriate
<Keybuk> whoo
<apw> to generate pnp event IFF acpi is not working
<Keybuk> I get a full-on kernel panic trying to boot with acpi=off
<mneptok> james_w: meep.
<james_w> mneptok: ahoy
<apw> Keybuk, what from?
<Keybuk> apw: the problem there is you have to then patch all the pnp modules to also support the other subsystem
<Keybuk> apw: somewhere insire parport_pc_init
<Keybuk> and pnp_register_driver
<mneptok> james_w: are you responsible for kurts_self_image.deb? if so, you're doing a terrible job as package maintainer. allow me to send you a 14 page e-mail with details ....
<StevenK> My firewall is too early for the cutoff too.
<apw> Keybuk, well yes we'd need some new aliases
<apw> but other than that probabally not
<Keybuk> apw: dunno, am reading through the code of many of them
<james_w> mneptok: oh, I thought we were using a different image of you now? mnempolo.deb?
 * StevenK twitches
<StevenK> james_w: I did *not* need a reminder of that.
<mneptok> :D
<mneptok> StevenK: install Kees' usplash ... you know you want to ....
<StevenK> mneptok: I'd rather burn out my optic nerves
<mneptok> like i said. install the PPA.
<Mithrandir> a mneptok!
<apw> Keybuk, ok at least one of my machines boots acpi=off
<mneptok> Mithrandir! Mithrandir!
 * mneptok feels like a juvenile hobbit about to see fireworks
<apw> Keybuk, on the module aliases for isa those actually are already in place in a lot fo cases
<apw> as i got some broken modules loaded as a result
<Mithrandir> mneptok: how's the new job?
<apw> when i started generating pnp:dPNP700 style ones
<mneptok> Mithrandir: delightfully busy and stressful :)
<Keybuk> apw: err, well, there's about 6 modules with them
<Keybuk> and those modules don't look like they've been touched in years
<Keybuk> so those aliases are probably only in there by accident <g>
<Keybuk> hmm
<Keybuk> interestingly there is a struct pnp_device_id
<apw> yep, there is a full infrastructre to get them to modules.modaliases
<apw> but nothing generates them right now, other than my patch of course
<Keybuk> which is odd
<Keybuk> look at parport_pc for an example
<Keybuk> it only has the pnp_device_id DEVICE_TABLE
<Keybuk> but it ends up with both acpi: and pnp: aliases
<apw> the device is also listed in the acpi tables independantly
<Keybuk> is it?
<apw> for it to have an acpi thing i would say yes
<Keybuk> I can't find _that_ code
<apw> i think udev fakes the events
<Keybuk> nope
<apw> there are modalias files in /sys for somethings
<apw> i thought udev had to scan there for things that appeared before it did
<apw> and i had been assuming it did so using the modalias files in /sys
<Keybuk> udev doesn't touch those
<apw> how does it find old things, things that preceeded its first invokation
<Keybuk> it just writes "add" to all the uevent files
<Keybuk> which makes the kernel resend the netlink messages
<apw> which is probabally why the kernel keeps them in modalias
<Keybuk> that's mostly just for debugging
<apw> Keybuk, if you have a machine with a floppy with acpi could you let me have your udev log
<apw> want to see how it would interact should i introduce a modalias on the pnp events too
<Keybuk> http://people.ubuntu.com/~scott/udev
<Keybuk> you'd get two different MODALIAS strings from two different devices on two different subsystems
<Keybuk> which would be bad
<Keybuk> (both resolving to the same module)
<apw> why would that be bad
<apw> you would get two events anyhow
<apw> one with each
<Keybuk> the pnp devices aren't "under" the acpi ones
<Keybuk> likewise the acpi ones aren't "under" the pnp ones
<Keybuk> it'd be interesting to find out why the kernel did it this way in the first place
<apw> actually you don't get the pnp events at all on yours
<Keybuk> ooooh
<Keybuk> I just had a thought
<apw> the events in my log with the APW: on them i didn't add those events they were there
<Keybuk> could we make the MODALIAS for the pnp thing only show up if pnpacpi isn't working?
<apw> yeah we could indeed though i suspect you arn't getting them anyhow already
<Keybuk> should be
<Keybuk> I have /devices/pnp0 and stuff
<apw> whats in your /proc/bus/pnp
<Keybuk> ENOENT
<Keybuk> quest scott% ls /sys/bus/pnp/devices
<Keybuk> 00:00@  00:02@  00:04@  00:06@  00:08@  00:0a@
<Keybuk> 00:01@  00:03@  00:05@  00:07@  00:09@  00:0b@
<Keybuk> for example
<Keybuk> you have
<Keybuk> UEVENT[1236073926.075992] add      /devices/pnp0/00:11 (pnp)
<Keybuk> UDEV_LOG=3
<Keybuk> ACTION=add
<Keybuk> DEVPATH=/devices/pnp0/00:11
<Keybuk> SUBSYSTEM=pnp
<Keybuk> MODALIAS=APW:dPNP0700
<Keybuk> SEQNUM=979
<apw> right ... i had those events even before i added APW: to them
<apw> just without alias
<Keybuk> I have them too
<Keybuk> UEVENT[1235981705.266498] add      /devices/pnp0/00:09 (pnp)
<Keybuk> ACTION=add
<Keybuk> DEVPATH=/devices/pnp0/00:09
<Keybuk> SUBSYSTEM=pnp
<Keybuk> SEQNUM=2129
<Keybuk> (that id file contains PNP0401)
<apw> so i don't see why it would be an issue to have the pnp: style aliases on there
<Keybuk> the trouble is, I also have
<apw> (i missed them somehow)
<Keybuk> UEVENT[1235981705.260729] add      /devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0401:00 (acpi)
<Keybuk> ACTION=add
<Keybuk> DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0401:00
<Keybuk> SUBSYSTEM=acpi
<Keybuk> MODALIAS=acpi:PNP0401:
<Keybuk> SEQNUM=1967
<apw> but thats not an issue
<apw> loading the modules twice isn't an issue
<Keybuk> the issue is that why does pnpacpi exist at all?
<Keybuk> I'm trying to understand why the kernel doesn't already do it the way you describe
<apw> we simply don't have the aliases on there as far as i can see
<Keybuk> right, but when upstream fixed that problem
<Keybuk> they did it completely differently
<apw> and as you have found we have some destinations
<Keybuk> it would have been far simpler to do your patch
<apw> well if our userspace was anything to go by
<Keybuk> but instead they wrote this entire new pnpacpi subsystem
<apw> they were allowing udev to generate them
<Keybuk> and, most notably
<apw> _ahh_
<Keybuk> your patch makes pnpacpi irrelevant
<Keybuk> at least, apparently so
<apw> the one problem i found is there is no way to generate mroe than one
<apw> event per device
<Keybuk> sure there is, just attach multiple kobjects to it
<apw> note the proggy in the 80-* patch does a while <> { }
<apw> well not in the interface as it is
<Keybuk> ie. why isn't it /devices/pnp0/00:09/PNP0401
<Keybuk> apw: note the Author in the patch you're reading <g>
<apw> right, so there is no way at the bus level which is where they are generated
<apw> to produce all the aliases there
<Keybuk> so how does pnpacpi do it?
<apw> it cheats right
<apw> and produces acpi:id1:id2:id3
<apw> not sure if that is right, if it is that is why we have to load
<apw> all matching modules not just the first
<apw> MODALIAS=acpi:PNP0A08:PNP0A03:
<apw> that is carrying two things
<apw> though i have yet to understand why we would not just make the format
<apw> MODALIAS=acpi:PNP1 acpi:PNP2
<Keybuk> you can't have spaces in a modalias
<apw> and do the right thing with those in udev
<apw> there isn't a space, there are two aliases
<apw> and modprobe would do the right thing
<apw> it might need an option i can't remember but nothing insoluable
<apw> but thats getting hugely far ahead of ourselves
<Keybuk> simplicity of interface, I guess
<Keybuk> MODALIAS being a single string you pass to modprobe has its elegance
<apw> but i think the line in udev would be the same
<Keybuk> and it actually lets you do things like have modules that say
<apw> we we do pass it in such a way if it has spaces its N arguments
<Keybuk>   acpi*:PNP1:PNP2:*
<Keybuk> ie. a module that handles devices that export two pnp ids
<apw> yeah, though those two id's repreent separat functionalities
<apw> so that would be strange
<apw> and you could just as well say
<apw> MODALIAS(acpi*:PNP1*)
<apw> MODALIAS(acpi*:PNP2*)
<apw> but hey
<Keybuk> then you'd be loaded for both
<Keybuk> not for once device that implements both
<Keybuk> *shrug*
<apw> but i can't really see any reason not to produce pnp: style aliases at the PNP level as well
<Keybuk> I figured out where the pnp:/acpi: aliases come from
<apw> other than as i have discovered new modules _do_ get loaded, and some of them PANIC
<Keybuk> hmm
<Keybuk> if a device is currently using acpi
<Keybuk> you only want it loaded on the acpi: device
<Keybuk> since you need the acpi subsystem to have been init'd
<Keybuk> if a device is using pnp: you can load it on either the pnp: device or the acpi: device
<Keybuk> that's the problem
<apw> i assume the acpi: ones have more information in them, such as the device id's
<Keybuk> if you generate pnp: modaliases for all pnp devices, including acpi: ones
<Keybuk> udev will load the modules
<Keybuk> possibly before the pnpacpi stuff has even been initialised
<Keybuk> or while it's being initialised
<apw> if the device is found using acpi it will have to necessarily have ACPI up by then
<Keybuk> ahh
<Keybuk> no you're misordering things
<Keybuk> these devices can be found by either pnp *or* acpi
<Keybuk> they are in fact found by *both*
<Keybuk> however some drivers now assume acpi
<Keybuk> while older drivers assume pnp
<apw> right but actually they are only found way after that
<Keybuk> floppy happens to assume pnp
<apw> cause udev isn't there to see the event order
<Keybuk> battery for example assumes acpi
<Keybuk> not necessarily
<apw> find me a way you can get to userspace before acpi is complete
<Keybuk> config PNPACPI=m
<Keybuk> meh, that's a bool :p
<apw> i think it would have to be
<apw> i just don't see why it is bad that way
<apw> udev has been doing it that way before
<apw> even if we did fake up the rules
<Keybuk> I'm trying to forsee why your patch will be rejected upstream
<apw> completly reasonable
<Keybuk> and right now, it will be rejected because "we already have these modaliases, they are generated by pnpacpi"
<apw> i would be suggesting ripping out all the aliases as part of it
<apw> (the pnp: ones
<Keybuk> why the pnp: ones?
<geser> doko (or any other main sponsor): have you time to review the debdiff for bug #336871 and sponsor it? (python 2.6 transition)
<apw> or generating them in a differennt form
<ubottu> Launchpad bug 336871 in urlgrabber "Deprecated modules with python 2.6" [Undecided,New] https://launchpad.net/bugs/336871
<apw> as they ahve risk, as i discovered, if you have the events
<apw> then the modules which are marked get loaded, and that blows up my machine
<apw> as the modules are crap
<doko> geser: yes, will do
<Keybuk> isn't it just that the modules are assuming ACPI?
<apw> possibly dunno yet
 * apw thinks
<Keybuk> the logic line I'm thinking is
<apw> perhaps there does need to be something thats used !acpi
<Keybuk>  - we need MODALIASes from the pnp subsystem when pnpacpi doesn't generate them
<Keybuk>  - if we generate them from pnp subsystem, we don't need the ones pnpacpi generates
<Keybuk>  - pnpacpi exists for a reason
<Keybuk>  - so we're missing something :p
<apw> i am suspicious that your 3 there is false and thats your 4
<apw> i will go spend half an hour trying to find out its origins
<Keybuk> I wonder whether this all fundamentally comes down to pnp configuration
<Keybuk> ie. loading device configuration
<apw> well first thing, acpipnp is very very old
<Keybuk> ~2004
<Keybuk> that's about the midpoint of driver-core development
<Keybuk> (assuming you mean the code)
<ScottK> Sorry to come late to the party (just finished the backscroll).  I've got a server running that's pre-2000 and so pre-ACPI.  It's running Intrepid apparently successfully.
<ScottK> Or is it?
 * ScottK checks
<Keybuk> some things seem to work, some don't
<apw> Keybuk, where did you find the acpi:'s being gnerated
<Keybuk> apw: which bit?
<Keybuk> there's two types of "generated"
<ScottK> Still hardy
<Keybuk> MODALIAS for a hardware device
<apw> the kernel generating the uevents
<Keybuk> or alias line inside a module
<apw> the MODALIAS=foo part
<Keybuk> apw: drivers/acpi/scan.c
<Keybuk> with the actual device ids created by drivers/pnp/pnpacpi/core.c
 * Keybuk looks at pnpbios with interest
 * ScottK considers continuing to forget to upgrade that one.
<apw> there is some mad shit still in there
<Keybuk> this is quite, quite, evil
<Keybuk> btw, can I see your patch?
<ScottK> So if you need something tested, I can do it on that box.  It's not actually busy with any real tasks currently.
<apw> Keybuk, how does udev decide on ordering of its requests when catching up in the beginning?
<apw> as i note your acpi: events come out before you pnp events
<Keybuk> apw: tree order
<Keybuk>  /a/b comes after /a
<Keybuk> which was the original problem I was alluding to
<apw> hmmmm ...
<apw> so they ahppen to be in the right order
<Keybuk> the /devices/pnp0/* and /devices/LNXSYSTM:00/device:00/PNP*:00/PNP*:00 are unrelated in the tree
<Keybuk> so there are no ordering guarantees
<apw> creation order to some degree i guess
<Keybuk> no
<Keybuk> just sunspot order
<apw> i bet they will be in creation order in each directory, but no guarenttes over time
<Keybuk> I'm guessing you added a .uevent = pnp_bus_uevent line to pnp_bus_type
<Keybuk> and in that function added MODALIAS to the uevent?
<apw> yes exactly, nothing magic
<apw> i suspect that is an error for this
<Keybuk> I'm trying to work out what you need to put in the MODALIAS
<apw> i suspect there must be an enumerator which is not the acpipnp which i shoul dhave hooked
<Keybuk> based on pnp_bus_match
<Keybuk> yeah, I suspect that's probably more technically correct
<Keybuk> figure out what's adding the pnp devices in the first place
<apw> in the absence of acpi to do it
<apw> i think i have some isa busses on there which are not there else
<Keybuk> how do you mean?
<apw> i'll let you know waht i find
<Keybuk> you have things in /sys/bus/pnp/devices that don't show up as ACPI platform devices?
<Keybuk> btw. interestingly, pnpacpi sets pnp_platform_devices = 1
<apw> this is a non acpi machine
<apw> and i have stuff in pnp
<apw> machine is booting
<apw> machine is still booting
<apw> Keybuk, can't you speed this boot up or something :-P
<Keybuk> silly question
<Keybuk> what calls pnp_add_device () if it's not pnpacpi?
<apw> pnpbios
<apw> and pnpacpi
<apw> i suspect i need to hook the latter
<Keybuk> pnpbios isn't enabled in our kernels is it? :P
<Keybuk> at least, it doesn't show up in /boot/config-*
<apw> its enabled
<apw> debian/config/i386/config:CONFIG_PNPBIOS=y
<Keybuk> sorry
<Keybuk> someone must have renamed the option
<Keybuk> it shows up in jaunty
<Keybuk> just not intrepid
<apw> ahh, there is also an isapnp directory here
<Keybuk> dmesg | grep PnPBIOS
<Keybuk> ?
 * apw waits
<Keybuk> (I had to look at /var/log/dmesg because my dmesg is full of TKIP)
<apw> PnPBIOS: Scanning ...
<apw> and finding 20 nodes
<Keybuk> aha!
<Keybuk> I see
<apw> also isapnp speaks
<Keybuk> PnPBIOS: Disabled by ACPI PNP
<apw> so thats my likely target
<Keybuk> yeah
<Keybuk> it sounds like we just need PnPBIOS to add MODALIASES in almost the same form as acpi: but different
<apw> pnpbios:dNNNNN
<apw> or something
<Keybuk> then we can have file2modalias spit out pnp: acpi: and pnpbios: MODALIASes for anything with a pnp_device_id
<Keybuk> I'd go with pnpbios:PNPXXXX:PNPYYYY: just like acpi
<apw> yeah
<Keybuk> since then you can probably just steal the code ;)
<Keybuk> anything using acpi_device_id will only work if you have ACPI
<apw> who me i would never, 10yyp
<Keybuk> but those drivers probably only work if you have ACPI anyway
<apw> agreed
<Keybuk> anything using pnpbios directly wouldn't work if you have ACPI
<Keybuk> but I don't think there are such a thing
<Keybuk> and ancient legacy drivers (like floppy!) would work on ACPI or PnPBIOS
<Keybuk> and I'll rework my floppy patch to use pnp_device_id
<apw> Keybuk, i would leave your patch alone
<apw> as that is much more suitable for intrepid
<Keybuk> apw: actually, it's arguably wrong if I use acpi_device_id
<apw> maybe jaunty too depending on upstream
<apw> perhaps os
<Keybuk> pnp_device_id would be correct
<Keybuk> match the other drivers nearby
<apw> ok then
<Keybuk> and make it work on intrepid and jaunty
<apw> ack
<Keybuk> (pnp_device_id exists already - this would not depend on your patch)
<Keybuk> and the kernel already turns pnp_device_id lines into acpi*:PNPxxxx: matches for modules.alias
<apw> oh fine then
<Keybuk> lots of things will still be broken for non-ACPI machines
<Keybuk> but their floppy drive will work!
<apw> heh
<Keybuk> and probably their soundblaster too ;)
<ScottK> doko: Would you please look at the xdelta3 package.  I've rebuilt it for Python 2.6 with layout=deb and all and while it provides python2.5/2.6-xdelta3 is manages still to depend on python2.4, python2.5 which is clearly wrong and I have no idea why.
<doko> ScottK: your debdiff?
<ScottK> doko: It's in Jaunty already.  I didn't notice before I uploaded.
<ScottK> doko: Here's what I changed http://pastebin.com/fdbb8fc
<doko> ScottK: a .dirs file in debian creates a python2.4 dir, and xdelta3-regtest.py uses 2.5 as versioned interpreter (dh_examples is called *after* fixing the interpreter names)
<geser> ScottK: look at the shebang line of the examples in the usr/share/doc/python-xdelta3/examples: one uses python2.4 and the other python2.5 as interpreter
<ScottK> doko: I missed that.  Thanks.
<ScottK> geser: Thanks.
<nxvl> robbiew: hi robbie, just looking at the Karmic Release Schedule, is this FeautreDefinitionFreeze a new thing?
<nxvl> cjwatson: ^^
<Hobbsee> mvo_: ping?
<pitti> nxvl: it was formerly called "Specifications must be finished" or so
 * Keybuk gnarghs @ fuse
<Keybuk> evil install rule
<Keybuk> slangasek: around?
<nxvl> pitti: yeah, i understand what i means, i'm just curious since i see a lot of new Freezes that weren't there before
<nxvl> pitti: well, a lot of "Notes" have been moved to Freezes actually
<Keybuk> pitti: you've made some uncommited changes to acpi-support
<pitti> Keybuk: indeed, we should get those in at some point
<vbgunz> part 2. suspending to ram seems to work flawlessly. 2 issues though. 1. I have no way to associate the power button with "suspend to ram", powerdevil doesn't work here. 2. selecting "suspend to ram" in kickoff successfully works. pressing the power button successfully wakes up *but* the screen is not locked :/ . what would be nice is, press the power button, sleep, press it again, wake up with the screen locked
<vbgunz> I just installed kpowersave and configured it to do this and it actually works *but* I already have powerdevil and want to keep it. what can I do to help powerdevil actually work here?
<cjwatson> nxvl: the only additions, I believe, are feature definition freeze and new packages freeze (I'm not sure how well the latter will work; I queried that)
<Keybuk> pitti: do you know why you were asked not to just upload?
<cjwatson> nxvl: this cycle some of the specs landed very late, and I do think that's a problem we should address
<nxvl> cjwatson: yup, i think the same, just cheking :D
<pitti> Keybuk: can't remember any more, I'm afraid
<RainCT> cjwatson: that's funny.. I've just re-opened a bug of yours someone closed and pointed them to the rant on planet.ubuntu.com and now I see that's actually a post from you :)
 * cjwatson grins
<cjwatson> RainCT: BTW I don't want it to be an argument from authority ("Ubuntu developer told me to do it this way, so I must obey")
<seb128> worth noticing that bug triaging practice changes between maintainers and teams
<cjwatson> some practices are just wrong wherever they sit
<cjwatson> closing bugs without having taken the time to understand them and determine where they best live is one of those practices
<seb128> well, we do agressive bug closing on desktop bugs which I'm pretty sure other maintainers would disagree with, but we just have enough good quality bugs to be busy until end of time
<seb128> so there is no need to keep tons of low quality bugs which might turn to something useful after hard work
<cjwatson> was my bug low-quality?
<cjwatson> I'm genuinely asking - if it wasn't, I don't see how this point is remotely relevant
<cjwatson> the problem is that some of the people closing bugs are *unable to tell the difference*
<cjwatson> and that's wrong no matter whether it's desktop or anywhere else
<seb128> well, we do close crash bugs which are not sent using apport for example
<cjwatson> not relevant to this bug
<seb128> which I'm pretty sure you will disagree with
<seb128> oh, I don't know of what specific bug you are speaking about
<cjwatson> bug 328486
<seb128> I just read some comments about bug triagers work
<ubottu> Launchpad bug 328486 in apturl "automatically add keys when whitelisted for apturl" [Wishlist,New] https://launchpad.net/bugs/328486
<seb128> I don't discuss specifically this one
<RainCT> cjwatson: Heh. I think yours was fine :). I'm not familiar with the recent changes so mvo_ will have to tell, though :P
<cjwatson> if desktop practices could effectively be confined to desktop work, I would have much less issue with it
<cjwatson> part of the problem is that people see desktop practices and think they are appropriate everywhere
 * RainCT writes down "do not file crash reports for desktop bugs" *g*
<cjwatson> seb128: crash / not apport> *shrug* I don't feel strongly about that, actually
<cjwatson> seb128: I wouldn't if it were mine, but I can understand why you do that and it doesn't seem totally unreasonable
<seb128> we also close duplicate without sending those probably as duplicate some time which tend to make some people unhappy too
<seb128> anyway dealing with lot of bugs is not easy
<seb128> some time -> sometimes
<cjwatson> again, I don't feel strongly about that; I think it would be *better* if you could duplicate them properly but I understand that it is a lot of work
<RainCT> seb128: Yeah I understand that. I don't agree, but sometimes I'm tempted to do the same ^^
<cjwatson> the problems I have with bug triage are not ones that I think developers would generally accept; they are usually closely related to bug triagers working without particular regard to what developers need
<cjwatson> if you work closely with bug triagers, then almost certainly they're generally doing things that fit well with your practices
<cjwatson> my problems are when bug triagers do things that don't fit well with my practices as a developer, and don't put any effort into checking
<cjwatson> and I don't really see that as likely to be controversial among developers?
<cjwatson> the point of bug triage is to improve the state of bugs so that it's easier for developers to fix them efficiently
<cjwatson> if it's making developers' lives more difficult, then it is failing
<cjwatson> and the point of bugs, of course, is to improve the software
 * broonie notes that he doesn't often report bugs to Ubuntu largely because of the triage.
<cjwatson> yes, I've heard the same sentiment from many people
<seb128> right
<cjwatson> I am deeply disturbed by this state of affairs and want to get it fixed if at all possible
<seb128> I just know that I tend to read argument on #ubuntu-bugs between agressive closing or letting lot of bugs which lack details open
<broonie> It's particularly disturbing in that there are humans implementing what looks entirely like a mindless automated system.
<cjwatson> seb128: I don't mind closing bugs that genuinely don't have enough information to fix them, and where the reporter isn't responsive
<seb128> ie we often get people who argue that we shouldn't close duplicate without marking them as proper duplicate even if we know they are dups for sure
<cjwatson> seb128: I *do* mind us closing bugs when the triager simply doesn't understand the information that was given
<cjwatson> seb128: or doesn't understand what information the developer needs, and so asks for a bunch of completely useless stuff
<seb128> right
<seb128> I agree with you on that
<cjwatson> seb128: this is a situation I see regularly, and is essentially what I'm complaining about. I'm not complaining about the desktop team's practices
<cjwatson> and I don't think that, to date, the Ubuntu development team has really stood up and said "look, this isn't what we want, and it isn't what we need" in an organised way
<cjwatson> that's sort of what I was trying to kick-start
<seb128> cjwatson: right, I didn't take your post as something again desktop bug triaging, my comment was rather a follow up to some other comments I read on IRC since yesterday
<seb128> ideally people who don't understand what they are doing should not be in bugsquad and allow to close bug to start
<cjwatson> (BTW, I ran it past heno before posting, since I didn't want to be taken as having a go at the people who *are* doing a good job of Ubuntu QA)
<seb128> allow -> allowed
<Keybuk> quest linux-jaunty% git rebase --onto gnargh c09024e129f515dd87e0abafc7ff3a4791216838 topic/modprobe
<Keybuk> *sometimes*
<Keybuk> just
<Keybuk> *sometimes*
<Keybuk> I like git
<pitti> wohoo :)
<pitti> Keybuk: that extracts a patch and applies it to a different branch/file?
<Keybuk> it reapplies the branch of patches since the revid I gave to my current branch
<pitti> seb128: ah, you already saw the weird amd64 retracer error and removed lock?
<seb128> pitti: yes
<pitti> thanks
<seb128> pitti: it seemed to be a launchpad timeout or something
<seb128> np
<pitti> seb128: as I said, might be that weird python-apt thing again
<seb128> right
<pitti> but well, at least it's so much better than a couple of weeks ago
<seb128> it doesn't seem to be happened as often though
<pitti> it wouldn't finish two bugs without a timeout back then
<seb128> right
<pitti> seb128: after the UIF rush I'll see to switch to launchpadlib, get backports for hardy/intrepid, and update the retracers to use it
<seb128> cool
<pitti> but that sounds like an entire day of work
<pitti> tseliot: there's a sponsoring bug 95444; do you think you can have a look at it in the next nvidia-180 upload?
<ubottu> Launchpad bug 95444 in nvidia-graphics-drivers-180 "No Screen Backlight Control; Notebooks (Vaio, Macbook, HP/Compaq, Samsung, Zepto et al.) with Nvidia Geforce8/Geforce9/Quadro series graphics" [Undecided,New] https://launchpad.net/bugs/95444
<tseliot> pitti: sure
<jdstrand> seb128: does evolution-mapi have an FFe? was it discussed somewhere off-list?
<seb128> jdstrand: expection granted, it's part of GNOME 2.26 official and I can grant universe desktop exceptions
<jdstrand> seb128: ok cool
<jdstrand> seb128: just out of curiosity, I guess JRiddell can do the same for KDE?
 * pitti args at Rosetta spam
<seb128> jdstrand: not sure, MOTU sent an email with the delegation lists for teams, I would expect so yes
<jdstrand> seb128: ok, I'll check that out. thanks :)
<seb128> you're welcome
<seb128> jdstrand: "Feature Freeze this Thursday" on u-d-a
<seb128> jdstrand: this email has the detailed list
<jdstrand> seb128: excellent
<Riddell> jdstrand: yes I can
<asac> slangasek: something funny: http://mail.gnome.org/archives/networkmanager-list/2009-March/msg00010.html
<jdstrand> cool, got it
<asac> slangasek: seems they try to achieve quite the oposite
<asac> which might mean we need a different solution. at best getting a property into udev/hal
<asac> for virtual stuff
<slangasek> Keybuk: moo
<slangasek> asac: hrm, surely hal should show a driver associated with those modules whether or not they're compiled in?
<Keybuk> slangasek: acpi-support
<slangasek> since "driver" != "module"
<Keybuk> why are we holding off uploading?
<slangasek> Keybuk: mm, are we?
<Keybuk> slangasek: you'd asked pitti not to upload acpi-support
<Keybuk> and I'm pretty sure you asked me not to too
<slangasek> Keybuk: that may have been an offer to do the upload that I failed to make good on
<Keybuk> may I?
<slangasek> yes, please :)
<Keybuk> done
<asac> slangasek: i think its a hal bug. yes
<asac> slangasek: but i doubt its a fixable one for jaunty
<asac> (guts feeling)
<Keybuk> yeah, this sounds one of those HAL being stupid problems
<slangasek> asac: it surprises me if that's the case; seems to me that it should be straightforward to resolve via sysfs
<slangasek> asac: except actually, the guy is talking about coLinux, so that may really be a virtual device and they have a different problem there
<Keybuk> huh
<Keybuk> actually
<Keybuk> HAL resolves the last element
<Keybuk> so it should work with compiled-in
<Keybuk> $ readlink /sys/bus/pci/devices/0000:00:1f.1/driver
<Keybuk> ../../../bus/pci/drivers/ata_piix
<Keybuk> $ lshal | grep atea_piix
<Keybuk>   info.linux.driver = 'ata_piix'  (string)
<Keybuk> (ignore spelling mistake typing from one screen to the other)
<Keybuk> $ readlink /sys/bus/pci/drivers/ata_piix/module
<Keybuk> $ echo $?
<Keybuk> 1
 * slangasek nods
<asac> slangasek: are we actually sure that virtual devices cannot be used like normal devices? e.g. dhlicent, get IP, and so on.
<slangasek> asac: no - but there are definitely *some* set of virtual devices that should not be managed by NM, and the ones that can be should be identified and whitelisted
<slangasek> and this patch restores the behavior from 8.10
<slangasek> I think coLinux in particular is a case where you would want NM managing a virtual device.  You might have the same thing with e.g., VMware, depending how the network device looks from userspace
<jdstrand> mathiaz: fyi, I deNEWd evolution-mapi source
<slangasek> but, those are special cases
<mathiaz> jdstrand: \o/ - thanks you!
<mathiaz> ivoks: ^^
<ivoks> mathiaz: jdstrand great
<asac> slangasek: personally i would prefer if we could mark devices that cannot be managed than the other way around ... and only blacklist those that are marked like that
<ivoks> mathiaz: i'll test it tomorrow
<slangasek> asac: I think that's upside-down for the case of virtual devices; virtual devices that NM shouldn't touch are, I believe, the common case
<slangasek> asac: I believe kees had this same problem on a different sort of virtual device
<asac> slangasek: we will see. i will get this uploaded today i hope
<mathiaz> ivoks: great - could you drop me an email with some testing instructions?
<asac> slangasek: i know that there were complains from kees, you and soren ... and some bugs
<ivoks> mathiaz: sure, once i try it my self
<asac> slangasek: lets see how many complain when we dont do that anymore ;)
<mathiaz> ivoks: so that I can write a call for testing and have other test the plugin too
<mathiaz> ivoks: sure
<asac> slangasek: i will try to get feedback from QA team and maybe soren to check VMs
<seb128> jdstrand: thanks
<slangasek> ok :)
<asac> i just fear that we introduce yet another upgrade regression by flipping the coin
<slangasek> asac: it would be an upgrade regression confined to jaunty, and if someone complains, then we'll have information about what kinds of virtual devices it makes sense for NM to manage :)
<mathiaz> slangasek: openldap 2.4.15 seems to be an bug-fix only release. Should I request an FFe to merge from Debian?
<slangasek> mathiaz: I haven't analyzed whether it's bugfix-only, I'll leave that to your judgement whether it needs an FFe. :)
<jdstrand> mathiaz, ivoks, seb128: np
<Daviey> Keybuk: Is there much chance of getting a FFe for a conversion from init.d to upstart?  Once any potential upgrade regressions are tested?
<kees> asac: I'm not sure my corner-cases of network interface madness really need to be considered until the NM core is more stable.
<Keybuk> Daviey: not this release ;)
<slangasek> kees: hey, a little support here, I'd like it if configuring openvpn didn't cause NM to screw up my default route ;)
<ogra> heh, upstart as FFe ?
<ogra> funny thought
<ogra> Keybuk, did we drop the hwclock initscript call on shutdown as well with your cleanup ?
<Keybuk> no
<asac> kees: right. i will decide whether we really fix the virtual-shoudlnt-be managed based on feedback i get during beta
<ogra> :( ... sad that would have solved a lot of probs on ARM :)
<kees> slangasek: heh, sorry.  :)  Yes, while I'd like NM to work sanely given my crackful configs, I'm not convinced it's possible in the short-term.
<asac> kees: also: the NM core is quite stable now
<asac> kees: at least architecture wise
<kees> asac: I'm happy to start opening bugs if you think it's the right time for it.
<asac> kees: lets wait for 0.7.1 to be final ;)
<kees> asac: between libvirt, my bridge, and VLAN interfaces, it gets really really upset at me.
<kees> heh, okay
<asac> should happen in a few days ;)
<kees> cool
<Daviey> Keybuk: forgive me, i mean just for one package.  Wasn't clear :)
<Keybuk> Daviey: what package?
<Daviey> mythtv-backend
<Keybuk> what's the rule?
<Keybuk> the upstart job, sorry
<Daviey> ahh
<Daviey> currently just
<Daviey> respawn
<Daviey> exec /usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log
<Daviey> (iirc)
<Daviey> (and the "start on/stop on" ofc)
<Keybuk> that job will not work with upstart 0.5
<Keybuk> what's your upgrade plan?
<Keybuk> how will you cope if people change the file between now and the next release?
<Daviey> It was the intention to tear out the old init.d using rm_conffile in packaging
<Keybuk> it's not the init script I'm concerned about
<Daviey> ofc, a warning might be prudent
<Keybuk> it's the migration between upstart versions
<Keybuk> the next version of Upstart in Ubuntu does not have a compatible configuration file format
<Keybuk> they're not even in the same directory
<Daviey> ahh, jobs.d ?
<Keybuk> no
<Keybuk> (this is me saying I'd recommend not converting things to Upstart just yet, btw :p)
<Daviey> (i guessed as such :) )
<Daviey> thanks
<Keybuk> you'd only be creating more work for yourself
<Keybuk> with no immediate benefit
<superm1> well other than having the ability to automatically respawn the init script to cope with crashes
<superm1> i think that was the driving feature for wanting to convert to upstart
<Daviey> yep.. it's just that we've been umming and arrr'ing over switching for a couple of releases now :).  Currently we don't have a watcher, like mysql etc.  A crash goes unnoticed.. Ah well, good things will come from kinky koala
<Daviey> Keybuk: ^^
<Daviey> thanks
<liw> hmm... https://bugs.launchpad.net/evolution/+bug/150963 shows the bug as confirmed/unknown in the Evolution project (that's upstream), and Fix released/wishlist on Ubuntu. because of the upstream status, it shows up in the list of bugs related to me.
<ubottu> Launchpad bug 150963 in evolution "evolution should allow me to configure it to not switch emails/folders when space is pressed at the end of a message" [Wishlist,Fix released]
<liw> is there something I can to get it off the list?
<directhex> ask #launchpad imho
<LaserJock> is there any place that says that spec wiki pages should use a particular namespace (such as Spec/ or Specs/)?
<LaserJock> or a category like CategorySpec
<liw> directhex, ack, good point
<jcastro> do we have an lp tag for bugs/patches that are major deltas from upstream or debian?
<slangasek> liw: use https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=$me ?
<liw> slangasek, I reported the bug, and I sort of feel I should stay subscribed, though
<liw> the status for the upstream project is wrong, that is
<slangasek> using that url certainly doesn't unsubscribe you, it just gives you a view that hides non-Ubuntu tasks
<slangasek> oh
<liw> slangasek, otoh, the url you gave is probably better for me anyway :)
<liw> slangasek, incidentally, since you're awake -- do you have any
<liw> er...
<liw> slangasek, incidentally, since you're awake -- do you have any timetable for finalizing the debian/copyright spec in Debian? I expect it won't happen before jaunty releases
<slangasek> for finalizing it - yeah, I don't think that'll happen before jaunty
<slangasek> I do want to still get a decision on harmonizing with Fedora's naming scheme done before then
<slangasek> (with enough lead time to be able to deploy some of these in jaunty)
<directhex> the spec's going to be actually finalized? :o
<bigon> does somebody know if I can get an upstream version freeze for dbus-glib with that debdiff? http://www.pastebin.be/16987 ?
<ScottK> pitti: Are you interested to be subscribed to bugs that affect gnome-stracciatella-session?
<rtg> ogra, lool: https://edge.launchpad.net/%7Etimg-tpi/+archive/ppa/+sourcepub/506110/+listing-archive-extra
<lool> rtg: Ah it's great to see your efforts, thanks a lot; I'll try having a look tomorrow (late-ish here)
<lool> ogra: Would love if you could have a look
<rtg> lool: yeah, now I need to make sure it all still works.
<lool> rtg: I'm not sure how I'll test it yet, but I'm NCommander and ogra have use cases already
<lool> s/I'm/
<rtg> lool: I have an x86_64 test case, which is my primary interest
<lool> rtg: I think NCommander was testing under qemu/armel
<rtg> lool: I'm pretty sure kexec itself will work. I've had mor issuers with initramfs hooks and such.
<mdke> hi there. Is the removal of the log out and shut down buttons from the System menu in jaunty intentional?
<mdke> (am asking for documentation purposes - that affects quite a few of our docs)
<Nafallo> mdke: they come back if you remove the FUSA-applet from the panel is my understanding.
<mdke> ah, so they do
<slangasek> IOW: yes, it's intentional
<superm1> nifty; i didn't know there was a way to get them back
<mdke> ok, so we'll have to try and explain that there are two possibilities in the documentation
<Nafallo> well... they are not gone then ;-)
<Nafallo> just hidden
<mdke> it's not very obvious how th get the FUSA applet back again :)
<mdke> it has a different icon in the Add to Panel dialogue
<mdke> so people who accidentally remove the applet may have some trouble turning off their computer...
<mdke> unless we document both ways
<mdke> so I guess the documents will have to explain both as alternatives
<slangasek> lamont: why does https://launchpad.net/ubuntu/+source/ia32-libs/2.7ubuntu3/+build/849008/+files/
<slangasek> lamont: why does https://launchpad.net/ubuntu/+source/ia32-libs/2.7ubuntu3/+build/849008/+files/buildlog_ubuntu-jaunty-ia64.ia32-libs_2.7ubuntu3_FAILEDTOBUILD.txt.gz show ia32-libs FTBFS on ia64 when running a command that's not what it was told to run?
<slangasek> lamont: nah, ignore me, reading comprehension fail
<slangasek> doko: do you know why lib32gcc1 on ia64 is being built from ia32-libs instead of from gcc-4.3?
<slangasek> net result is that ia32-libs is FTBFS on ia64 since intrepid, AFAICS
<doko> slangasek: ia64 doesn't have a biarch setup, would require a ia64->i386 cross compiler; I never did care much about doing this cross toolchain
<slangasek> doko: that's fair
<doko> but I can have a look at ia32-libs tomorrow
<slangasek> doko: ok - no hurry as far as I'm concerned, I just TIL but I don't particularly want to lose a whole day trying to wrangle the stupid thing
<directhex> are the ia64 buildds itanic 1 or 2?
<mdke> didrocks: the latest update of yelp seems to have broken the adapt 04_new_ubuntu_layout.patch
<mdke> didrocks: scratch "adapt" from that, was a bad paste
<mdke> didrocks: yelp doesn't show the Ubuntu frontpage anymore, but rather the upstream TOC
<seb128> mdke: he's sleeping now I think but I will sort that with him tomorrow
<mdke> seb128: ok, thanks very much. I can send an email or file a bug. It's not clear to me whether it's the change he made or an upstream change causing the problem
<seb128> mdke: let me have a look
<mdke> seb128: no rush, thanks for looking into it
<seb128> mdke: nothing obvious, the patch is still there, didn't change a lot and applied during the build
<mdke> yeah, I saw it applied ok
<seb128> mdke: seems to be rather an upstream change, will sort that with him tomorrow
<mdke> seb128: thank a lot
<seb128> you're welcome
<seb128> there is not so many upstream changes, weird
<mdke> yeah, I was wondering if it was 2.24.1
<mdke> but that's in intrepid too, right?
<mdke> oh, maybe not
<seb128> no
<seb128> no such version in the NEWS or changelog
<mdke> yeah
<mdke> mysterious. I will try and get hold of DonS if we can't figure it out over the next few days
<ryanakca> On the UDS sponsorship form, the ``crew'' does what? Setup tables / chairs / sound systems / errands / etc?
<seb128> should be easy to revert the few commits between version and figure which one breaks it
<khem> On jaunty after applying updates from yesterday my wireless stopped working. I have a T61 before I investigate I thought to ask if someone else is seeing same
<maxb> khem: I have a Z61p, still working... probably too different to be relevant... anyway, probably #ubuntu+1 would be a better place?
<khem> maxb: thx
<maxb> Oops, I spoke too soon, after a reboot my wireless is gone too
<maxb> Oh no, it was just being slow to associate
<ebroder> I'm...having a hard time debootstrapping a jaunty chroot - I'm getting an error about libstdc++.so.6 when I try to do an apt-get update within the newly created chroot. Did something about libc/libc++ change recently (or not so recently)?
<ebroder> (I'm debootstrapping on a lenny machine. I've tried lenny's, unstable's, and jaunty's debootstrap package, and it errors out the same way each time)
<ebroder> ...oh wait. "W: Couldn't download package libstdc++6" is probably relevant
<maxb> :-)
<ebroder> It looks like te mirror I was using sucks
#ubuntu-devel 2009-03-04
<yao_ziyuan> i wonder if ubuntu can employ a mixed development model
<yao_ziyuan> update core packages slowly,
<yao_ziyuan> but app packages quickly
<yao_ziyuan> apps such as gimp, pidgin, supertuxkart
<yao_ziyuan> their latest versions better be released fast
<yao_ziyuan> so you can have both stability and cutting-edge
<LaserJock> yao_ziyuan: I think that happens fairly naturally anyway
<LaserJock> yao_ziyuan: having 6 month releases allows core packages to go slowly but app packages to go quicker
<yao_ziyuan> but apps such as pidgin are still outdated
<yao_ziyuan> ubuntu pidgin is 2.5.2
<yao_ziyuan> latest pidgin is 2.5.5
<yao_ziyuan> how can you say apps get updated fast?
<Nafallo> jaunty  development  main  release  1:2.5.4-2ubuntu2
<Amaranth> yao_ziyuan: that doesn't sound too out-dated
<Amaranth> Unless they rewrote pidgin between 2.5.2 and 2.5.5
<LaserJock> so we are 0.0.1 behind :-)
<yao_ziyuan> i'm interested in finding another repository that offers latest apps
<yao_ziyuan> getdeb.net is one but not sure if it has a repository
<LaserJock> and 2.5.5 was released 2 days ago
<yao_ziyuan> is there a ppa.launchpad.net repository for my purpose?
<LaserJock> so we're all ove 2 days behind :-)
<LaserJock> *of
<LaserJock> yao_ziyuan: you can go to launchpad.net/ubuntu/+ppas and search for it
<TheMuso> c
<LaserJock> you know, I wonder if it'd be possible for the CD autorun thing to compare the Ubuntu version that's on the CD with the one that's currently running
<LaserJock> I just put in a gutsy CD and it wanted to know if I wanted to upgrade :-)
<ScottK> Maybe it just has a poor opinion of the release you're running?
<TheMuso> heh
<TheMuso> ROCK ON ALESSIO ABOGANI! You have made my day dude! We, (or at least I), have a bootable i386 RT kernel!
<TheMuso> woops wrong channel
 * TheMuso has too much excitement atm. :p
<bryce> pitti: are you really sure the patch for 218671 should go to hardy and intrepid?  The patch isn't taken upstream and looks to me like it'd cause regression for all current users of -elographics?  I can put it in if you're certain it's the right fix, but personally I think it needs more work to not cause regressions.
<bryce> pitti: commented on 218671.
<didrocks> mdke: I will have a look today at it
<pitti> Good morning
<pitti> ScottK: stracciatella> I'm a package bug contact (or at least I'll watch them), but I'm of course interested in getting subscriptions to bugs which interact with it
<StevenK> Morning pitti!
<pitti> bryce: no, not at all; apparently I misunderstood it as "came from upstream", and since I can't really judge it, I asked you to have a look
<bryce> pitti: ah ok
<bryce> pitti: yeah it's a confusing bug, but I think going upstream is the next step for it
<pitti> absolutely, and we shouldn't backport it too fast; it should at least spend some time in jaunty
<pitti> hey StevenK
<mdke> didrocks: many thanks
<didrocks> mdke: that's very strange, the context of the patch didn't change too much. I was pretty confident. I will have a deeper look this evening :)
<mdke> didrocks: ok.
 * slangasek waves to pitti from the far side of Debian bug #215219
<ubottu> Debian bug 215219 in libpam-cracklib "libpam-cracklib: Does not call cracklib when doing passwd" [Important,Closed] http://bugs.debian.org/215219
<pitti> slangasek: ugh, that's ages old :) great that it came to a good end eventually
<doko> seb128, slomo_ : I didn't follow https://bugzilla.redhat.com/show_bug.cgi?id=470000 . Is this applied?
<ubottu> bugzilla.redhat.com bug 470000 in gstreamer-plugins-good "gstreamer + pulse leaking threads on sound output (pidgin crash)" [High,Closed: nextrelease]
<slomo_> doko: gst-plugins-good 0.10.14 should have this fixed
<slomo_> doko: and 0.10.13-something
<seb128> doko: yes
<doko> thanks!
<seb128> slomo_: should we sync 0.10.14? is that a bug fix version?
<slomo_> seb128: what's the current version in ubuntu?
<slomo_> seb128: 0.10.13.2-1, ok... compared to that it's a bugfix release, yes
<seb128> slomo_: ok, good to sync then? ;-) what about vala 0.1.7?
<slomo_> good to sync, yes... same goes for gst-plugins-bad0.10 0.10.10-3 (or -2, whatever the latest is)
<seb128> ok thanks
 * seb128 does syncing
<slomo_> vala 0.1.7 has many bugfixes but also some new features iirc... but for such a new language that's ok i guess ;)
<seb128> yeah, I don't think it will break lot of things
<directhex> afaik thefre's only one app in the archive built using vala
<directhex> so test that for buildability with 0.1.7, if it's fine, i see no pressing reason not to update it
<directhex> a good vala dev environment is a nice thing to have for jaunty
<slytherin> asac: hi, do you maintain network-manager-openvpn package?
<asac> slytherin: ?
<slytherin> asac: any idea where could I forward this bug 285138
<ubottu> Launchpad bug 285138 in network-manager-openvpn "Does not import certificate and key settings" [Undecided,Confirmed] https://launchpad.net/bugs/285138
<asac> slytherin: bugzilla.gnome.org
<asac> slytherin: have you checked the NM on jaunty?
<YokoZar> jcastro: I hope you don't mind me applying for sponsorship on the very last day.  I've been out with some particularly nasty food poisoning the past week
<slytherin> asac: no I haven't. I will do today.
<asac> slytherin: yes, please do that. maybe its fixed
<slytherin> asac: I feel this is more of the plugin issue. Still I will check.
<asac> slytherin: not sure why you think that plugin hasnt changed in jaunty ;)
<asac> just check before forwarding ... thanks
<slytherin> sure
<slytherin> by the way, has anyone seen ath_pci causing kernel panic at boot time? I faced this issue on an acer laptop yesterday. searched google but didn't find sufficient information.
<ogra> cjwatson, "Don't disable /dev/ramzswap* swap devices." in partman ? why is that ?
<ogra> oh, that means it shoudnt swapoff ?
<cjwatson> ogra: this is a change that's been there for ages
<cjwatson> ogra: yes, indeed, it inhibits swapoff on those
<ogra> right, i was just wondering, and then did remember the actual change
<mnabil> guys ,i customizing intrepid alternate cd , i added some packages to the /pool/extras and i did every thing using else using uck , my question is how can i install these package automatically  i mean what is the statement to do this in the preseed file
<directhex> d-i     pkgsel/install-pattern  string ~n^pkgname$|~n^anotherpkgname$
<directhex> mnabil, ^^
<cjwatson> goodness, why would you use such a complicated syntax
<cjwatson> d-i pkgsel/include pkgname anotherpkgname
<directhex> dunno, an old sarge d-i guide i think
<directhex> it'd help if d-i syntax didn't change between every build
<cjwatson> doubt it, I think that was an Ubuntuism
<cjwatson> you can use Kickstart if you want a stable syntax
<mnabil> k
<mnabil> thanks
<directhex> cjwatson, i had to switch target distro twice during the project, so whatever it came from initially, it works in etch
<cjwatson> directhex: pkgsel/install-pattern is definitely not supported in etch; pkgsel/include is
<cjwatson> (see e.g. http://svn.debian.org/wsvn/d-i/branches/d-i/etch/packages/pkgsel/debian/pkgsel.templates?op=file&rev=0&sc=0 and http://svn.debian.org/wsvn/d-i/branches/d-i/etch/packages/pkgsel/debian/postinst?op=file&rev=0&sc=0)
<directhex> i might be looking at an old revision of the seed
<directhex> well guessed. i was looking at the dapper version of the file
<pitti> cjwatson: do you know where /etc/usplash.conf is written during install?
 * mneptok guesses /etc
<pitti> cjwatson: usplash's postinst attempts that, but that wouldn't normally run when installing with ubiquity?
<pitti> mneptok: right, sorry; I mean "how", "what part of the install", and "which resolution does it use"
<mneptok> pitti: sorry, i try to be egalitarian and fair when spreading snarky comments. ;)
 * mneptok hugs pitti 
 * pitti hugs back mneptok
<ogra> pitti, just a gues ... update-initramfs ?
<ogra> *guess
<ogra> (i didnt look, just speculating)
<pitti> ogra: good shot; however, /usr/share/initramfs-tools/hooks/usplash doesn't have detection code
<pitti> it just copies /etc/usplash.conf into the initramfs
<ogra> hmm
<pitti> ideally it would be written in the installer, according to the currently dtected/configured X.org resolution
<mneptok> pitti: wouldn't a dpkg-reconfigure of usplash call whatever piece you're looking for?
<pitti> and I *think* that's what happens, but kwwii asked me to confirm
<ogra> either that or by initramfs on boot
<pitti> mneptok: yes it would
<Keybuk> my favourite bug of the day
<Keybuk> bug #336762
<ogra> if the .conf doesnt exist yet
<ubottu> Launchpad bug 336762 in util-linux "ntfs hard links not working" [Undecided,New] https://launchpad.net/bugs/336762
<directhex> wasn't there some magic non-sucky replacement for usplash being mentioned?
<pitti> directhex: KMS and plymouth, but not for jaunty
<mneptok> pitti: OK, so i would think there would be a way to watch that happen.
<pitti> Keybuk: lol
<mneptok> Keybuk: my favorite bug of the day slipped back beneath the underwear waistband before i could find tweezers. :/
<directhex> pitti, something which can handle widescreen without rescaling badly 3 times would be welcome
 * Keybuk hands mneptok the Derbac
<pitti> directhex: you mean mode switching; and yes, KMS should provide that eventually
<mneptok> Keybuk: in better news, from what i could see, he has your eyes.
<pitti> but it's not quite there yet
<cjwatson> pitti: ubiquity explicitly runs dpkg-reconfigure usplash, so the postinst is run
<pitti> cjwatson: ah, that solves it; thanks
<cjwatson> and it removes /etc/usplash.conf first to force regeneration
<cjwatson> a bit like Doctor Who
<directhex> i need to mangle usplash.conf manually on my laptop or i get corruption on screen when booting
<Keybuk> cjwatson: following up on your rant
<Keybuk> I wonder whether the triage tendancy to post to any bug older than a few weeks asking whether it's still present ...
<Keybuk> ... is what causes people to keep posting to my bugs saying "THIS BUG IS STILL PRESENT IN JAUNTY! OMGZ!"
<directhex> O NOEZ!
<cjwatson> there seems to be a vast misestimation of available developer effort somewhere
<cjwatson> leading to people believing that if a bug hasn't been fixed then this must be because it's no longer relevant
<directhex> cjwatson, every user assumes every other user is a developer (and they're the only "mooch")?
<Mirv> should the "Incomplete Language Support" light bulb be appearing in jaunty too, after installation? which package it's a problem of, as it does not? language-selector still has the strings at /usr/share/language-support/incomplete-language-support-gnome.note but those are not shown/triggered.
<Mirv> I guess it would be ubiquity, and I'd file a bug about it if cjwatson doesn't object. I don't know how things should go with the new notification systems etc.
<RainCT> Btw, apport shows a notification which says "click the icon". Shouldn't the bubble and the notification icon be replaced directly by window?
<AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
<ubottu> Debian bug 411851 in sl-modem-daemon "slmodemd not restarted on resume" [Normal,Open] http://bugs.debian.org/411851
<MacSlow> how do I create a pbuilder environment for jaunty (under jaunty again)?
<cjwatson> Mirv: ubiquity does have code to do that, so bear that in mind when you file the bug - we'd need to figure out why the existing code isn't working
<huats> I am experiencing a weird issue :  when I am building a package in my pbuilder it builds fine, but in soyuz it fails because it cannot find a bdeps (liblocale-gettext-perl). This package is installed on my pbuilder, so why is it not installed in soyuz ?
<MacSlow> what's the exact pbuilder command again?
<RainCT> MacSlow: with pbuilder-dist or plain pbuilder?
<ScottK> MacSlow: One of the easiest ways to do it is with pbuilder-dist.
<MacSlow> pbuilder --distribution jaunty --create
 * ScottK notes RainCT must type faster than he does.
<primes2h> doko: Hi, I just added a link to the diff in bug 333727
<ubottu> Launchpad bug 333727 in system-config-printer "[jaunty] Cannot add a printer " [Unknown,Fix released] https://launchpad.net/bugs/333727
<MacSlow> hm... no pbuilder-dist command here
<RainCT> ScottK: Heh. Yeah, I have "learn Dvorak" on my TODO :)
 * MacSlow does "sudo apt-get install ubuntu-dev-tools"
<primes2h> doko: This bug prevents me from translating the application correctly because I can't add a printer.
<MacSlow> *sigh* why did that not survive my upgrade to jaunty?
<AnAnt> RainCT: isn't that the keyboard layout in UK ?
<ScottK> If you have pbuilder-dist (it's in ubuntu-dev-tools) it's just pbuilder-dist jaunty create
<cjwatson> AnAnt: *blink* no
 * MacSlow and packaging *sighÂ³*
<MacSlow> hey tedg
<AnAnt> where should I ask about suspend/resume & pm-utils  ?
<RainCT> AnAnt: No. See dvzine.org
<tedg> Good morning MacSlow
<RainCT> MacSlow: With pbuilder-dist, you can also create a symlink to it called pbuilder-<distro> and then use  pbuilder-<distro>  directly instead of  pbuilder-dist <distro>
<ogra> MacSlow, hey, remember my "notificatons pup under the panel issue" ? ... delaying the startup of notify-osd by 5 secs solves it (i simply added a wrapper script around notify-osd that gets called by the dbus service file and lets it sleep 5 secs)
<ogra> *pop
<cjwatson> Keybuk: can I poke you to vote on my TB Landscape resolution?
<MacSlow> ogra, there is a temp. fix in place now, but it's not a wrapper-script
<ogra> MacSlow, yeah, wrapper scripts are hacks anyway, just wanted to give you a hint ;)
<MacSlow> ogra, don't worry I know about many issues :)
<ogra> oki :)
<doko> primes2h: please let Till review and upload
<primes2h> doko: ok, I asked you because he is not here today.
<lool> I just did a deboostrap and saw it detect new required base dependencies with the move to python2.6
<lool> I think python2.6 needs promotion to priority important and -minimal to required
<lool> And python2.5 ones should be demoted
<lool> Is an archive admin around to change that?
 * MacSlow remembers why he hates packaging
<MacSlow> a command like "pbuilder-dist jaunty create" has do be done with sudo, right?
<Hobbsee> yes
<MacSlow> *sigh*
<MacSlow> "nice" that it does not complain if I start it without sudo
<MacSlow> just diligently does thing and wasts time
<Laney> pbuilder-dist calls sudo itself, no?
<MacSlow> Hobbsee, Laney: well it certainly did not create this /var/pbuilder/something/base.tgz
<MacSlow> Hobbsee, Laney: well it certainly did not create this /var/pbuilder/something/base.tgz
<MacSlow> ups
<Laney> It makes them in ~/pbuilder/
<Hobbsee> hrm.  You might be right there, actually
<MacSlow> Laney, how can I instruct pbuilder to use that  ~/pbuilder instead of /var/pbuilder/something?
<Laney> pbuilder --basetgz (IIRC)
<MacSlow> I have that actually
<Laney> but why not just use pbuilder-dist to build stuff?
<MacSlow> Laney, I honestly have no idea what I'm doing right now
<MacSlow> the last package I did is months ago
<Laney> MacSlow: What are you trying to do? build a package?
<MacSlow> Laney, well I want to use pbuilder to verify my package before I upload it to the build-server
<MacSlow> PPA rather
<Laney> ok, well
<Laney> pbuilder-dist jaunty build xxx.dsc I believe
<directhex> ooh, xxx
<Laney> 18+ source package
 * Laney covers directhex's eyes
<MacSlow> no I've to use pdebuild I think
<MacSlow> I don't yet have a .dsc
<MacSlow> file
<Laney> just run debuild -S inside the package dir and it will spit one out for you
<directhex> Laney, hot-babe 0.2.2-3ubuntu1?
<MacSlow> pdebuild -- --basetgz /home/mirco/pbuilder/jaunty-base.tgz
<Laney> guh, if you like
<MacSlow> packaging is like using git
<RainCT> Btw, poweroff / reboot don't work anymore here since I updated my laptop to Jaunty ("halt" works, though)
<Laney> simple and intuitive?
<maxb> I like --use-pdebuild-internal, which builds straight from a directory, doesn't need a source package
<MacSlow> it only makes sense to people who do it on  a daily basis ... not if you only do it every 6 months
<directhex> Laney, git is as intuitive as DIY laser eye surgery
<directhex> and more painful
 * RainCT is away for 2 hours
<RainCT> directhex: +1 :)
<Laney> HMM
<Laney> IDEA! pdebuild-dist
<maxb> The scary thing is how git starts to make sense after a while.... and you wonder how warped your brain has become :-)
<Hobbsee> MacSlow: the trick is to keep the scripts around, use sed on them, then upgrade them from there - not recreate from scratch each time ;)
<Laney> all it does is figure out your pbuilder-dist basetgz location and pass that to pdebuild, parsing changelog to get the right release
<AnAnt> RainCT: that was a nice comic !
<AnAnt> thanks
<cjwatson> lool: done the priority changes, thanks. (BTW, http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt)
<lool> cjwatson: ah didn't think it would check for that
<cjwatson> now, what on earth is pulling gtk into standard
<lool> cjwatson: one thing the mismatches report doesn't mention is the db4.2
<lool> I: Found additional base dependencies: libdb4.2 python2.6
<cjwatson> if the report doesn't mention it, that's a good sign that something weird is going on ...
<cjwatson> lool: which architecture, to save me time?
<lool> cjwatson: armel
<lool> cjwatson: It's a foreign debootstrap of jaunty BTW
<MacSlow> hm... what's -I meaning for debuild?
<lool> debootstrap --arch=armel --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --verbose --foreign jaunty .
<lool> MacSlow: Ignore vcs files when building the .tar.gz for native packages
<MacSlow> the manpage to debuild doesn't state this paramter
<lool> MacSlow: it's a dpkg-buildpackage flag
<cjwatson> debuild's manual page says that most of its parameters are passed on to dpkg-buildpackage
<MacSlow> lool, ah I was thing of -I (nclude) like in gcc
<ogra> dpkg-preconfigure: unable to re-open stdin: ...
<ogra> hmm, i wonder if that needs to worry me
<MacSlow> dput is stuck
<MacSlow> can one savely Ctrl-C a hanging dput?
<cjwatson> ogra: probably not overly
<pitti> MacSlow: yes
<cjwatson> MacSlow: yes
<MacSlow> hm... damn ... lp is dog-slow or so
<MacSlow> no idea what's wrong
<MacSlow> must be UIF causing tons of uploads :)
<MacSlow> is there some local log I can look up to see why it might be hanging?
<seb128> MacSlow: using edge or normal server?
<MacSlow> ppa.launchpad.net
<sistpoty|work> MacSlow: can you ftp to ppa.lp.net? if so, you can just upload the 4 files with ftp, (.changes file must be last) and see what's going wrong... dput does actually the same thing
<pitti> asac: are we actually using the modem prober in jaunty now?
<pitti> asac: I wonder what to do with bug 291333
<ubottu> Launchpad bug 291333 in hal-info "Onda MT505UP / MF632 not working" [Wishlist,Fix released] https://launchpad.net/bugs/291333
<pitti> with just hal-info, I'm between a rock and a hard place
<pitti> you can't fix it for everyone :(
<asac> pitti: could be that the latest package has a build system bug still
<asac> pitti: do you have /lib/udev/nm*probe*
<asac> ?
<pitti> asac: no, I don't
<pitti> ah, that's where it should be?
<asac> hmm. ok thats the problem then
<asac> pitti: yes
<asac> pitti: todays upload will certainly have that then
<pitti> asac: so it's meant to be used in jaunty, awesome
<asac> yes for sure
<pitti> asac: how does that work wrt. priorities? n-m uses the modem prober, and if that doesn't find anything, falls back to reading hal fdi?
<pitti> or the other way round?
<asac> pitti: yes. i played a bit around with changing that to "try hal" first, then udev
<asac> but i guess we should at least have the "upstream" order in beta
<asac> so we see if there are issues
<pitti> asac: hm, so that way around I'd actually need to remove those hal-info entries
<pitti> asac: *nod*
<asac> pitti: i think we will prioritize udev over hal from what i can see now
<pitti> asac: i. e. if the hal-info is wrong for some people (like in above bug), the nm-prober wouldn't fix it
<asac> pitti: yeah. thats why we should use udev first
<pitti> asac: ok; let's see how that works; if we need to swap the priority (in case the udev prober needs overrides for some hardware), please let me know, and I'll remove that fdi entirely
<asac> pitti: let me check if dan already tagged rc3. i can upload that then
<asac> seems not. i will prod him to do that now
<MacSlow> sistpoty|work, I need the .dsc (1st), .tar.gz (2nd) and .changes (4th) ... what's the third file (.diff)?
<ScottK> Yes
<sistpoty|work> MacSlow: .diff.gz (in case you have it)
<pitti> asac: ah, just found Dan's reply on the hal ML; he also says that hal is a fallback
<sistpoty|work> MacSlow: basically all files mentioned in the .changes iirc
<MacSlow> sistpoty|work, I'm not sure my manual ftp transfer triggered anything
<sistpoty|work> MacSlow: triggered as in triggered a problem in dput, or as in makes the upload work in ppa?
<MacSlow> sistpoty|work, makes the upload work in the ppa (e.g. I have yet to see it appear in the PPA-page or get an upload-confirmation email
<sistpoty|work> MacSlow: ah, sorry... I just saw that the files need to be put to the remote directory "~%(ppa)s/ubuntu" (but I'm not exactly sure to what the ~%(ppa)s expands to
<sistpoty|work> +)
<BUGabundo> any reports of intel wifi 4965 stop working on Jaunty after linux-backports-modules-2.6.28 (2.6.28-8.7 upgrade?
<sistpoty|work> MacSlow: however I assume that dput -s should give the hint of what it expands to ;)
<pitti> james_w: o_O http://jameswestby.net/weblog/debian/09-for-the-record.html
<ogra> james_w, liar
<ogra> ogra@osiris:~$ apt-cache show crap|grep -i maintainer
<ogra> W: Unable to locate package crap
<ogra> E: No packages found
<pitti> asac: do you have a lock on bug 317860 or shall I do that now?
<ubottu> Launchpad bug 317860 in mobile-broadband-provider-info "Request to upgrade to latest SVN 3G profiles" [Undecided,Confirmed] https://launchpad.net/bugs/317860
<asac> pitti: yes. antti is currently moving
<asac> i wanted to get all the pending stuff from launchpad committed
<pitti> okay
<pitti> just saw it on the sponsoring queue
<asac> but probably we have to prepatch that then
<directhex> tseliot, tested it, nvidia 180 from jaunty works perfectly on intrepid, so is ripe for SRUdom
<asac> sure. thanks for the prod. i have an update round on my high-prio todo list :)
<asac> (not that its a short list)
<tseliot> directhex: I'm not sure as to whether we should do an SRU for this. Have a look at this bug: https://bugs.launchpad.net/bugs/335879
<ubottu> Launchpad bug 335879 in nvidia-graphics-drivers-180 "nvidia driver 180.35 breaks KDE 4" [Undecided,Confirmed]
<directhex> tseliot, erm... what an odd bug
<pitti> asac: wasn't meant to be a prod, I'm happy to do the upload; just checking whether anything should block it
<tseliot> directhex: maybe you could file a backport request instead
<emgent> it's official.. http://marketing.openoffice.org/ooocon2009/cfl/results.png
<directhex> tseliot, if it's breaking systems, perhaps i should wait
<asac> pitti:  i wanted to take all the other submissions we had. but given the long number of bugs we should just do it i guess
<directhex> tseliot, it's in my PPA so i can use it that way
<tseliot> directhex: even better ;)
<directhex> tseliot, i put the latest upstream fglrx in there too for kicks
<tseliot> directhex: good work :-)
<asac> pitti: hmm. seems the bzr branch is broken :(
<asac> sigh
<directhex> tseliot, which needed gentle massage to compile *cough* superm1, that's your cue *cough*
<asac> pitti: i guess you can just branch it and the pull the rest from playground
<asac> or do it the old way
<pitti> asac: broken how?
<pitti> well, I'll figure it out
<asac> pitti: all bzr playground syncs are broken on launchpad
<asac> pitti: https://code.edge.launchpad.net/~network-manager/mobile-broadband-provider-info/trunk
<directhex> tseliot, http://www.nvnews.net/vbulletin/showpost.php?p=1946545&postcount=46 implies 180.35++ should be fine
<pitti> asac: ah, that; ok, no prob
<asac> which is kind of a shame now that gnome mirrors everythng there
<tseliot> directhex: good to know. This means that I won't have to revert to a previous version in Jaunty
<directhex> tseliot, assuming the next revision happens before release
<tseliot> directhex: yes, of course ;)
<directhex> tseliot, got anyone you can poke into pushing a 180.36?
<asac> pitti: just use http://bzr-playground.gnome.org/mobile-broadband-provider-info/trunk to get the latest or svn ;)
<pitti> asac: yep
<tseliot> directhex: usually I file a FFE and bug pitti for the upload :-P
<directhex> tseliot, i meant at nvidia, to let them know you really really need 180.35++ before april
<tseliot> directhex: there's Aaron Plattner and he's subscribed to that bug report
<MacSlow> sistpoty|work, so now the manual upload worked
<sistpoty|work> :)
<MacSlow> sistpoty|work, still no idea what's wrong with dput
<calc> doko: ping
<sistpoty|work> MacSlow: maybe firewall problems (in case dput doesn't use passive mode)? (there should be an option to force passive mode for dput as well, can't recall right now)
<Keybuk> cjwatson: the problem isn't the proposal, it's the length of it
<Keybuk> I'm easily distracted
<Keybuk> so if the proposal is pretty long and complicated, by about half way do..ooh, shiny
<calc> anyone in here know how to tell ant to compile java app to a specific source version of java (eg javac -source 5 foo)?
<ScottK> MacSlow: I'm finding LP very slow today, so it may just be hitting some internal timeouts.
<doko> calc: ?
<MacSlow> scottK: hm... manual ftp was super fast and responsive
<calc> doko: do you know how to tell ant (i guess via build.xml?) to compile code using a specific java version eg javac -source 5 ?
<ScottK> Maybe what sistpoty|work said about passive FTP then.  Dunno.
<calc> doko: i am trying to port some old java code over to using default-jdk
<doko> calc: javac -source 1.5
<sconklin> asac (or anyone): I'm seeing some new and wrong behavior on my Intrepid desktop that apparently started with a recent update - as  kernel guy I'm not sure how to debug or report it. The little applet displays in the window manager panel aren't being displayed correctly. My screen is two displays which are tiled (laptop display and an external monitor).  If anyone can suggest what to report it against I'll put in a full descriptio
<calc> doko: but how do i stick that into a cdbs rules that uses ant to build? :)
<asac> sconklin: can you get me a screenshot that shows the problem
<sconklin> well, it will take a photo because of the two screens.
<sconklin> but yes
<doko> calc: see the cdbs page, there is a marcro called ANT_ARGS or something like that
<calc> doko: ok
 * cjwatson buys Keybuk some attention span
<Keybuk> you can buy that shit?
<mneptok> DUDE! wait ... what?
<superm1> directhex, what was missing from fglrx?  do you have some stuff needed for packaging?
<directhex> superm1, ftbfs without xinerama added to build-deps
<directhex> the binary lib, not the dev headers
<Pici> 00
<directhex> superm1, for catalyst 9.2, this is
<sconklin> asac: sent screenshot link and description by  email
<directhex> superm1, dpkg-shlibdeps: failure: couldn't find library libXinerama.so.1 needed by debian/xorg-driver-fglrx/usr/lib/libatiadlxx.so (its RPATH is '').
<directhex> http://launchpadlibrarian.net/23372288/buildlog_ubuntu-hardy-amd64.fglrx-installer_2%3A8.582-0ubuntu1~intrepid~dhx1_FAILEDTOBUILD.txt.gz
<superm1> directhex, did you check if phorogit had that already resolved?
<superm1> directhex, http://www.phorogit.com/index.php?p=fglrx-packaging.git&t=097e896bf9c55b440b907541f6e3e18ff1414748
<directhex> superm1, never heard of it!
<superm1> directhex, yeah it looks like the packaging that got included in the 9.2 was a little behind what was in phorogit.  AMD regularly takes snapshots when they do releases
<asac> sconklin: instead of mail you could have opened a bug directly ;)
<savvas> erm.. is the default locale dir /usr/share/locale or /usr/share/locale-langpack ?
<sconklin> asac: I will, just don't know what to report it against
<slangasek> seb128: desktop ISOs grew 4 MB overnight, with most of the new packages coming from GNOME; any ideas what grew?
<asac> sconklin: if its the applet its network-manager-applet to start with
<asac> sconklin: let me look at mail. wait a sec
<directhex> superm1, so i'm just behind the times, then. still, 9.2 packages for intrepid \o/
<asac> sconklin: whats the subject?
<sconklin> screenshot.
<sconklin> no period
<superm1> directhex, yeah i wish there was a good way to get those scripts updated on demand.  if you've got ideas, i'd be open
<seb128> slangasek: no
<seb128> slangasek: there was no major changes in GNOME packages as far as I know
<slangasek> seb128: ok; I'll dig into it (and grumble some more about how we should store the package size info with the builds or in the logs :)
<directhex> graph it, per package, using historic data from launchpad!
<directhex> throw in some magic to let you see how much space a given dep tree used on a given timestamp, do it with ajax or flash or silverlight or something & make it responsive enough to be useful...
 * directhex tickles jcastro 
<ttx> slangasek: I just read your comment @ https://bugs.launchpad.net/ubuntu/+source/samba/+bug/254151/comments/4 -- I suppose we should abandon the proposed 'fix' in bug 312449, then ?
<ubottu> Launchpad bug 312449 in samba "samba-common fails to upgrade if smb.conf is deleted" [Medium,Confirmed] https://launchpad.net/bugs/312449
<ubottu> Launchpad bug 254151 in samba "samba fails to install prperly after unnistall+deleting smb.conf" [Undecided,Invalid]
<slangasek> ttx: yeah, no matter how obvious it might seem to restore a config file whose absence breaks the package, doing that automatically breaks one of the assumptions about how config files work in Debian...  if we think this is needed, then I would like it to get wider discussion on ubuntu-devel
<ttx> slangasek: it's not really needed, it's just we keep on getting samba bug reports about it, so it's a triage effort to educate users to apt-get purge samba-common
 * ttx ponders echoing a more useful error message
<BUGabundo> apw: ping
<BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/193970?comments=all
<ubottu> Launchpad bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Confirmed]
<BUGabundo> I'm one of those that lost WiFi
<apw> BUGabundo, lets take that to #ubuntu-kernel
<ttx> slangasek: Failing with <<Not replacing deleted config file /etc/samba/smb.conf -- run "sudo apt-get purge samba-common">> might help...
 * ttx will adjust patch.
<slangasek> ttx: should we tell them to purge the package, or just cp /usr/share/samba/smb.conf /etc/samba/smb.conf?
<ttx> slangasek: cp sounds more productive.
<savvas> About locale translations directory: should a program read /usr/share/locale-langpack as well as /usr/share/locale ?
<liw> is there an .ics feed somewhere that actually has ubuntu release dates such as UI freeze?
<ttx> "cp and dpkg --configure -a"
<slangasek> liw: http://people.ubuntu.com/~vorlon/JauntyReleaseSchedule.ics
<liw> slangasek, I have that configured in evolution, it doesn't show anything about a UI freeze :(
<liw> no, wait
<liw> webcal://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
<liw> that's what I have
<slangasek> liw: that's not JauntyReleaseSchedule :)
<liw> slangasek, so I need both?
<cjwatson> or 'dpkg --force-confnew -i /var/cache/apt/archives/samba-common_whatever.deb'
<cjwatson> UbuntuReleaseSchedule is the 10000-foot view
<cjwatson> JauntyReleaseSchedule has the details
<slangasek> cjwatson: is ucf going to honor --force-confnew?
<cjwatson> slangasek: oh, ucf? probably not then
<slangasek> it might! but I haven't tried :)
<Mithrandir> we could teach it to, but currently dpkg doesn't pass it to subprocesses.
 * slangasek nods
<liw> cjwatson, slangasek: so I only need the JauntyReleaseSchedule one?
<Keybuk> you could walk your pid and read its cmdline
<Keybuk> ppid
 * liw seems to have a long evening ahead of him, to fix a few UI problems in computer-janitor before tomorrow
<slangasek> liw: you only need the {Jaunty,Karmic,Lackadaisical}ReleaseSchedules
<slangasek> Keybuk: hiss
<liw> slangasek, ok, thanks
<seb128> slangasek: did you figure what changed between yesterday and today?
<slangasek> seb128: not yet
 * RainCT is back
<RainCT> >> Btw, poweroff / reboot don't work anymore here since I updated my laptop to Jaunty ("halt" works, though)     -     Any idea?
<slangasek> seb128: gnome-games-data grew by 2M
<slangasek> seb128: I guess that's not really bloat and we should find room for it :)
<seb128> slangasek: I guess that's extra translations and screenshots
<slangasek> ah
<slangasek> gnome-user-guide also grew by 1.6M
<seb128> likely same story
<seb128> I'm downloading the gnome-games-data to make sure
<seb128> slangasek: gnome-games could be another good candidate for documentation split if we still want to win some CD space
<_MMA_> Can anyone tell me if there's a written policy for installing *anything* to /root?
<highvoltage> Has *anyone* at canonical actually looked at http://www.ubuntu.com/education/management#licence ?
<slangasek> seb128: we're not desperate for CD space - I definitely have some langpacks I can kick off as needed - I'm just trying to stay on top of the size changes as they happen since that's way easier than figuring out where the space went afterwards
<highvoltage> It says "All Ubuntu software is released under GPL, which means it is effectively licence free as opposed to free licence. "
<Keybuk> cjwatson: been doing a bit of research into the whole /etc/adjtime thing
<Keybuk> cjwatson: what was ppc using that for?
<highvoltage> it also says "# Ubuntu is Licence Free"
<Keybuk> because afaict, the contents of the file are never actually used by default
<Keybuk> just kept up to date
<slangasek> seb128: anyway, getting evolution off of python 2.5 is the first priority as far as space :)
<slangasek> _MMA_: "don't"
<seb128> slangasek: well, one of the things I would like for jaunty is as many language packs on the CD as possible
<seb128> slangasek: doko said a rebuild would be enough and we did upload a new version?
<Chipzz> _MMA_: I think it is considered a homedir just like other users' homedirs
<Chipzz> which you shouldn't touch
<Chipzz> slangasek: on that note, debian-installer DOES install a .profile etc in /root
<Chipzz> or at least, sth does
<_MMA_> slangasek: I need more than that. :) Why I worded things the way I did. Is what Chipzz said pretty much the reason? (the only one I could think of also)
<calc> doko: how do i determine what the default -bootclasspath is so i can override it sanely?
<slangasek> seb128: ah - must not have been a livefs rebuild yet with that version of python; I do see that the alternate CDs have come down in size
<calc> doko: is there a way to have eg javac tell me?
<seb128> slangasek: right, the current jaunty version depends on libpython2.6
<slangasek> Chipzz: 'adduser' is what creates it in /root, using /etc/skel
<Chipzz> slangasek: I don't think it is
<Chipzz> slangasek: because the .profile etc for root differ from the .bash_profile for regular users
<cjwatson> Keybuk: I think it was the same as x86, but don't honestly remember for sure - the powerpc-utils package is probably more useful than I
<seb128> slangasek: gnome-games-data
<seb128> Installed-Size: [-43088-] {+40264+}
<seb128> Version: [-1:2.25.91-0ubuntu1-] {+1:2.25.92-0ubuntu1+}
<cjwatson> highvoltage: meep. Is there a website bug on this?
<Chipzz> ie regular users get a .bash_profile, root gets a .profile (which is substantially different from, and shorter than, the .bash_profile)
<Keybuk> cjwatson: you said you found that ppc was putting magic times in there to cope with obscenely old clocks
<seb128> slangasek: weird that the deb got bigger
<Keybuk> and that ppc-utils was moving the file around?
<slangasek> _MMA_: it is a homedir, and you shouldn't install things to it from a package for that reason, yes
<cjwatson> Keybuk: and then I said that I'd said that without looking at the code, and when I looked at the code I found that it was basically just a hwclock clone
<seb128> slangasek: in fact they added quite some localized screenshots
<slangasek> seb128: hmmm, strange
<Keybuk> cjwatson: oh, so it doesn't even use util-linux-ng's?
<slangasek> seb128: unless the 'installed-size' between the two has been calculated on two different machines with different block sizes
<cjwatson> Keybuk: but I also said that there was a problem unique to powerpc where hardware battery failures could result in negative Unix time after boot, which means that it's particularly important on those systems to ensure a vaguely current time even if the network is not avaiable
<cjwatson> available
<Keybuk> cjwatson: right, but if it's not using hwclock, it's nothing to do with me - right? :p
<doko> slangasek: what are the current sizes?
<slangasek> Chipzz: well, .profile != .bash_profile, obviously; I could be mistaken about whether d-i uses adduser when setting up the root account, but that seems like it'd be doing things the hard way
<highvoltage> cjwatson: LaserJock has just alerted news2000, I'll check check with him whether there's a bug
<cjwatson> Keybuk: the reason various people mentioned you was that the removal of adjtime broke installation of the powerpc-utils package
<cjwatson> Chipzz: base-files installs /root/.profile in its postinst
<Keybuk> cjwatson: but I only changed the util-linux-ng postinst
<Keybuk> not ppc-utils
<seb128> slangasek: dpkg-deb -x and du gives 27 to 29 megas
<Chipzz> slangasek: hrrrm I was mistaken too; regular users get a .profile; but it's still different
<seb128> slangasek: I guess the "installed-size" is not smart about symlinks?
<cjwatson> Keybuk: didn't you arrange for /etc/adjtime no longer to be created at installation?
<doko> calc: why would you want to override it? afaik _rene_ did do some experiments on this, so maybe ask him
<Keybuk> cjwatson: no, just removed on upgrade
<Keybuk> in the util-linux postinst
<slangasek> doko: currently, 715/717 MB for the desktop CDs; python2.5 is still on there, looking into that now
<seb128> slangasek: the new version added some localized screenshots, which means symlinks replaced by real files
<_MMA_> slangasek: Thanx man. There's a desire floating around to make the theme look more "cautious" when using su/sudo/root. Something like some of the XFCE apps do. It involved having a theme in /root. On to find plan "b".
<Keybuk> I don't know what creates it
<Chipzz> cjwatson: thx :)
<Keybuk> you suggested base-files
<Keybuk> but I haven't looked into that
<cjwatson> Keybuk: all I know is that TheMuso said stuff now broke
<Keybuk> :)
<cjwatson> I no longer have a functioning powerpc system to try it out myself
<slangasek> seb128: hrm, it certainly should account for symlinks, AFAIK 'installed-size' is meant to be equivalent to 'du' :)
<Keybuk> me neither
<cjwatson> installed-size is implemented with du -k -s
<Keybuk> cjwatson: base-files does create one though
<seb128> slangasek: well it's not
<cjwatson> or 'cd $builddir && du -k -s .' really
<seb128> $ du -ksh 91
<seb128> 27M	91
<cjwatson> Keybuk: yes
<Keybuk> in its postinst
<seb128> $ dpkg -I gnome-games-data_2.25.91-0ubuntu1_all.deb | grep Install
<seb128>  Installed-Size: 43088
<Keybuk> cjwatson: and, in fact, hard-codes an assumption that the hardware clock is in UTC :p
<seb128> where 91 is a dpkg-deb -x deb 91
<Keybuk> bet the installer doesn't change that
<cjwatson> Keybuk: I suspect the correct fix is to migrate whatever changes are in clock (the powerpc-utils one), migrate those to util-linux-ng, and then find whatever's calling the one from powerpc-utils and make it call the one from util-linux-ng insteas
<cjwatson> instead
<Keybuk> right
<cjwatson> I don't think anyone is particularly attached to there being a separate version
<Keybuk> *separately* to that
<Keybuk> we need to decode whether or not we want an /etc/adjtime on our system
<Keybuk> if we do, I'll remove the rm from the util-linux postinst
<Keybuk> if we don't, we should remove its creation from the base-files postinst
<TheMuso> cjwatson: I don't think the utility from powerpc-utils actually gets used any more, so far as I checked. i.e its not used as an alternative, however I'll have to check that again.
<slangasek> seb128: ok, I have no idea.  Maybe the buildd it builds on is using very large blocks
<Keybuk> I removed it because it's not *used*
<Chipzz> cjwatson, Keybuk: on a seperate note, I'm doing automated installs using debian-installer and preseeding. in some cases I want to install configs in /etc . what should be the preferred way to do that?
<Keybuk> hwclock just keeps updating it
<Keybuk> which incurs a time cost
<seb128> slangasek: ok, anyway the change is extra screenshots for localized documentation
<Keybuk> so I saved a few tenths of a second on boot and shutdown by not using it
<Keybuk> cjwatson: what are your thoughts here?
<cjwatson> Keybuk: the remaining value in base-files' creation of /etc/adjtime is that it gives a vaguely sane lower bound on the possible system time. I suggested that we replace this by having hwclock compare the system time with the timestamp on its own executable
<cjwatson> or something similar
<Keybuk> ah
<cjwatson> since the executable timestamp will be preserved during installation when extracting it with tar
<Keybuk> you're missing the key piece of evidence
<Keybuk> you can put whatever you like in that file
<Keybuk> *hwclock doesn't use it*
<cjwatson> clock (from powerpc-utils) does
<Keybuk> so right now, the only purpose creating that file has, no matter what you put in it, is to slow down the boot and shutdown by a few tenths
<cjwatson> that being the point of its postinst
<Keybuk> that may be the key difference
<cjwatson> I suggest that you go and read its source; it should not take long
<Keybuk> if the ppc hwclock uses it as a baseline
<Keybuk> but TheMuso says ppc doesn't use it anymore?
<cjwatson> it will certainly be faster than debating it with me, who has only gone and glanced over it :)
<Keybuk> cjwatson: what's the source package name?
<cjwatson> powerpc-utils
<TheMuso> powerpc-utils
<Keybuk> not debating, seeking advice
<cjwatson> I'm not actually asserting that powerpc's clock setup is bug-free - not in the slightest
<cjwatson> it is entirely possible that it does not work properly
<cjwatson> nevertheless, this is a well-understood problem for those who have dealt with powerpc systems :)
<cjwatson> we used to get Ubuntu bug reports fairly frequently that people rebooted their Mac and then the desktop wouldn't start
<cjwatson> and this turned out to be due to the clock
<cjwatson> so even if it doesn't get handled correctly right now, I think it should
<cjwatson> Keybuk: I think what you're missing is that I'm trying to describe what I think the correct state of affairs should be, rather than what the current state of affairs is :-)
<ogra> seb128, hey, i'm finally able to reproduce that gnome-keyring-daemon hang here ... getting the dbg version now and will attach some info to the bug
<cjwatson> I can no longer remember whether clock is called from anywhere
<seb128> ok thanks
<Keybuk> TheMuso: does ppc still use this clock util instead of hwclock?
<seb128> ogra: upstream is very responsive if you want to take that to bugzilla directly
<ogra> strace just tells me FUTEX_WAIT if i attach to the process
<cjwatson> but something along the lines of the above is the obvious way to fix this class of bugs
<TheMuso> Keybuk: as I said above, I don't think so, but I would need to check on a working system.
<seb128> ogra: would avoid having somebody doing the bug tracker pingpong for nothing
<ogra> seb128, understood
<seb128> ogra: and they know their code better
<ogra> yup, though i'D love to know if its really only arm
<Keybuk> TheMuso: right, there's no init script in this package
<seb128> ogra: we got no ubuntu desktop user running into that yet
<seb128> ogra: so it's setup or arch specific
<ogra> seb128, yeah, thats what i thought
<liw> I'm working on a new description for computer-janitor-gtk's main window. How does this sound: "This application helps you find and remove software packages that might not be needed anymore. It also suggests configuration changes that might benefit your system."
<cjwatson> I haven't thought hard about it, but just in case nobody else says, "anymore" => "any more"
<Keybuk> cjwatson: some brief packaging archaeology indicates that Ubuntu has *never* used clock on ppc
<Keybuk> it's always used hwclock
<cjwatson> Keybuk: ok
<Keybuk> and Debian hasn't for almost 8 years either ;)
<Keybuk> +powerpc-utils (1.1.3-4) unstable; urgency=low
<Keybuk> +
<Keybuk> +  * Actually change maintainer name this time.
<Keybuk> +  * No longer divert hwclock.sh; Debian kernels have included CONFIG_PPC_RTC
<Keybuk> +    for a long enough time now.  Document the issue.  (Closes: #99875).
<Keybuk> +  * Builds on current unstable now.  (Closes: #99735).
<Keybuk> +
<Keybuk> + -- Daniel Jacobowitz <dan@debian.org>  Sun, 15 Jul 2001 22:01:36 -0700
<cjwatson> would it be worth ensuring that the necessary magic from clock.c is now in hwclock.c?
<Keybuk> cjwatson: that's the thing, there isn't any "necessary magic"
<liw> cjwatson, I'll change it to "any more"
<cjwatson> Keybuk: aha
<Keybuk> you could do the same by just calling hwclock --adjust on boot
<cjwatson> in that case I see no reason why we can't just delete the adjtime stuff from powerpc-utils.postinst
<Keybuk> and we know why we don't want to do that :p
<Keybuk> cjwatson: TheMuso already has
<Keybuk> cjwatson: so separately to that, do we want to patch hwclock to use a common timestamp as a lower-bound for whatever it sets the system time to?
<cjwatson> Keybuk: I'm just thinking about how it will appear to users
<cjwatson> obviously we want to ensure that Unix time is always >= 0
<cjwatson> but it occurs to me that it might be rather confusing if it gets set to a (to a user) essentially random time
<cjwatson> which happens to be sometime around the release of your operating system
<cjwatson> maybe the correct approach is if (time < 0) time = 0;
<cjwatson> that way they say "hey, my computer says it's in January 1970" and we can easily say "ah, your hardware battery appears to have been eaten by a gorilla"
<cjwatson> and a lot of people would recognise "clock in January 1970" as a symptom of a hardware bug, whereas "clock in March 2009" maybe not so much
<cjwatson> yes, I have persuaded myself
<Keybuk> why would time be < 0 ?
<Mithrandir> because macs are special.
<Keybuk> I'm just tracing the effect of the current adjtime file on hwclock
 * slangasek raises his fist at the battery-eating ape. "Koooooooooong!"
<Keybuk> base-files sets last_adj_time = <bignum>
<Keybuk> and last_calib_time = <same bignum>
<Keybuk> but drift_factor=0.0 and not_adjusted=0.0
<Keybuk> only drift_factor and last_adj_time are used
<cjwatson> Keybuk: the reason why time might be <0 is that the Mac epoch is somewhere in 1904
<Keybuk> and last_adj_time is subtracted from the current time and multipled by the factor
<Keybuk> which is 0
<cjwatson> so if a Mac's CMOS-battery-equivalent fails, it starts up with the hardware clock in 1904 by default
<Keybuk> so the adjustment will always be 0
<Keybuk> thus the current base-files adjtime does nothing useful to hwclock
<cjwatson> I believe you
<Keybuk> it just says "hey, the clock last had 0 drift at <some time>"
<Keybuk> I suspect this is a regression from clock.c
<cjwatson> I'm not saying that /etc/adjtime in base-files is the right approach :)
<Keybuk> I know, I'm just following through all the lines to make sure I'm not missing the pachyderm in the pantry
<Keybuk> *blink*
<Keybuk> err
<Keybuk> clock.c multiplies by the drift factor as well
<Keybuk> so unless I'm mistaken
<Keybuk> this "writing some standard time into adjtime" has no effect
<Keybuk> and didn't have any effect on ppc either
<cjwatson> maybe that wasn't the intent at all
<cjwatson> I never actually saw a reason for it, and was extrapolating based on a best guess
<Keybuk> the field it puts it in is just a comment, basically
<Keybuk> hwclock and clock.c only use it to avoid adjusting more than once a day
<cjwatson> perhaps the adjtime increments on all of Santiago's base-files uploads were for some other reason - an attempt to minimise drift?
<Keybuk> again, wouldn't have any effect; the drift factor being 0.0 would tell hwclock to start afresh
<Keybuk> does Santiago IRC? :p
<Keybuk> (ie. could we ask him why he periodically updates it)
<slangasek> no, he doesn't
<LaserJock> james_w: what do you mean by "LTS doesn't know what LTS+1 is going to be called"?
<james_w> to implement it by mime types you would need to name the type for each cd differently
<RainCT> LaserJock: Karmic+1 has no name yet
<james_w> e.g. x-content/ubuntu-cd-jaunty
<LaserJock> why don't we use the release numbers?
<james_w> I guess you could
<cjwatson> Keybuk: usually fairly responsive to mail IIRC
<Keybuk> int rtc_valid_tm(struct rtc_time *tm)
<Keybuk> {
<Keybuk>         if (tm->tm_year < 70
<Keybuk>                 || ((unsigned)tm->tm_mon) >= 12
<Keybuk>                 || tm->tm_mday < 1
<Keybuk>                 || tm->tm_mday > rtc_month_days(tm->tm_mon, tm->tm_year + 1900)
<Keybuk>                 || ((unsigned)tm->tm_hour) >= 24
<Tm_T> LaserJock: james_w: release numbers maight move too
<Keybuk>                 || ((unsigned)tm->tm_min) >= 60
<Keybuk>                 || ((unsigned)tm->tm_sec) >= 60)
<Keybuk>                 return -EINVAL;
<Keybuk>         return 0;
<Keybuk> }
<Keybuk> EXPORT_SYMBOL(rtc_valid_tm);
<Keybuk> oops
<Keybuk> overpaste
<Keybuk> but anyway, the kernel itself rejects any hardware clock with a year < 1970
<LaserJock> Tm_T: how do you mean?
<james_w> LaserJock: really the issue is that the spec doesn't have room to say x-content/ubuntu-cd-${something you find from the disk, i.e. release number}
<Tm_T> LaserJock: I know it's not expected, but remember 6.06 (:
<LaserJock> Tm_T: no, but there's logic ther
<james_w> LaserJock: if you read the shared-mime-info spec and can come up with a workable solution then please propose it
<LaserJock> well, I don't care about the mime stuff
<LaserJock> I think we need logic
<LaserJock> I don't care where it is
<LaserJock> just have the mime call a wrapper that does the proper logic
<slangasek> cjwatson: what does this error point to?: Missing debootstrap-required python2.5-minimal
<slangasek> (alternate CD build failure)
<james_w> LaserJock: ok, please provide that logic in such a way that it can be reasonably integrated in to Ubuntu and I will happily review it. I couldn't see a way to achieve what you want given the current state of things
<kees> does anyone know the right magic for CDBS to run test.py from a python package?
<Keybuk> kees: three chicken livers, a raw egg and twice widdershins by candle light iirc
<LaserJock> james_w: I would think x-content/ubuntu-cd could call a wrapper script that checks /etc/lsb-release and the .iso contents and pops up the appropriate dialog
<LaserJock> james_w: does that make sense?
<elmo> speaking of clocks, it's never been clear to me why something (userland or kernel) doesn't automatically slew the time to 2009-01-01 12:00 if it finds the clock is set earlier than that
<elmo> it would avoid the mac 1904 thing breaking your desktop, if nothing else
<Keybuk> elmo: that's pretty much the discussion we're having
<elmo> oh, ok
<elmo> sorry
<james_w> LaserJock: apart from the fact that you are talking about a string running code, yes. Please go look at what is available and you will see that that is not so easy in the current framework.
<Keybuk> it looks like santiago regularly updates /etc/adjtime in base-files with a value Colin *thinks* is precisely for that purpose
<Keybuk> but nothing will use that
<elmo> \o/
<LaserJock> james_w: I didn't say it was easy, I just said that seems like the most logical way to handle use cases and be non-confusing to users
<james_w> LaserJock: I agree
<james_w> LaserJock: my proposal was something that for little effort could improve the situation. If you want to put in more effort and improve it further I have no problem with you doing so.
<LaserJock> james_w: I just don't want the Ubuntu Education CD to open nautilus, if our current popup still happens then I'm certainly OK with what you're doing
<cjwatson> slangasek: usually wrong priorities (see priority-mismatches.txt); but I already adjusted those priorities today
<cjwatson> slangasek: so I think that that should clear itself up tomorrow
<slangasek> ok, thanks
<james_w> LaserJock: well, that's not what I understood from your email
<slangasek> I'll probably do another CD build run today, to check sizes
<LaserJock> james_w: that my only real concern
<LaserJock> james_w: "what'd be nice" is different ;-)
<james_w> LaserJock: in fact reading your email again I still don't get that message
<kees> Keybuk: I hate adding chicken livers to the build-deps
<LaserJock> james_w: oh? I certainly wasn't attacking your proposal
<TheMuso> ab/c
<LaserJock> james_w: just saying that perhaps we can do even better (whatever the time frame) by adding more logic
<james_w> LaserJock: no, but you seemed to be talking about the other thing more, and I completely missed the fact that you didn't want nautilus to open
<LaserJock> james_w: well, that's because I just have the one use case in the Edu CD
<LaserJock> so I was trying to speak generally
<LaserJock> but the Edu CD is a concern for me regarding how the CD is opened
<LaserJock> as that's actually our "installer"
<sconklin> TheMuso: I have a bug reported against alsa and I'm not familiar with the structure or how to tell if it's kernel vs. userspace - if you suspend and resume with the headphones plugged in, you never get the speakers back on no matter whether the headphone is unplugged. Any advice?
<sconklin> I need a skooling in alsa
<TheMuso> sconklin: bug number?
<sconklin> TheMuso: in another chat
<TheMuso> sconklin: gotcha
<superm1> sconklin, wouldn't that likely be an EAPD bit not getting set correctly on the kernel side most likely after resume?
<sconklin> superm1: could be, I've not dealt with sound at all really
<mvo> doko: re the python relaeated upgrade question you asked during the meeting. there is currently #337705 pending, that needs to get resolved before we can give green light for upgrades again
<kirkland> mvo: hi there, around?
<mvo> kirkland: yes, but almost ready to leave for the evening
<kirkland> mvo: okay, could you please point me to the file that updates /var/run/updates-available?
<kirkland> mvo: there's a minor tweak i'd like to test, and send you a patch for
<kirkland> mvo: basically, removing that file is giving me problems;  would be much better if it printed "0 updates available" instead ...
<tedg> So why am I blocked from calling ConsoleKit's "GetSessions" when I can just introspect on the ConsoleKit object and get the paths that are on the object anyway?
<Keybuk> a bug?
<tedg> Just the latter one forces me to parse the strings to determine which are sessions (oh, and all the XML)
<mvo> kirkland: debian/99update-notifier removes it again
<mvo> kirkland: (in the lp:update-notifier source)
<kirkland> mvo: awesome, thanks.
<kirkland> mvo: i'll get this tested, and have a patch for you to review tomorrow
<tedg> Keybuk: Hmm, so you don't see any reason?
<mvo> kirkland: ok, thanks
<Keybuk> tedg: no formal reason
<Keybuk> it's either a bug that you can introspect
<Keybuk> or a bug you can't call getsessions
<mvo> kirkland: on desktop system this should not be a issue because update-notifier is running all the time and notices that the cache changed and that it needs to update that file
<mvo> kirkland: for the server it is of course
<tedg> Keybuk: Do you know of any security issues with knowing how many sessions there are?
<Keybuk> *shrug*
<Keybuk> not off hand ;)
<ogra> ck-list-sessions showsw them all anyway
<mvo> kirkland: it would be nice if the calcuation would not be duplicated, ie. if the running u-n picked up the change already it should not be done agan by update-motd (but we can talk how to do this tomorrow)
<tedg> ogra: Hmm, so why can I do that, but I can't call it over DBus.  Does 'ck-list-sessions' not do DBus?
<ogra> no idea :)
<ogra> i just know that it shows all sessions
<kirkland> mvo: you bet
<tedg> Heh, so ck-list-sessions doesn't call "GetSessions" it calls "GetSeats" and then "GetSessions" on each seat, which I'm allowed to do :)
<liw> slangasek, are you around? I'd like to ask about an ffe for computer-janitor, for some UI fixes
<slangasek> liw: hi
<liw> slangasek, this is embarrassingly basic, but... I'd like to have a new version of computer-janitor uploaded, with three UI changes and a package description change, all pretty small; should I file bugs to request freeze exception before the package gets uploaded, or should the upload happen first?
<beuno> liw, computer-janitor!  I'm happy to see you solved it  :)
<tedg> Keybuk: Do you know where that policy is set?  It seems like the consolekit stuff in /usr/share/PolicyKit/policy doesn't set these functions.
<liw> beuno, I failed to solve the more glaring usability problems, alas
<slangasek> liw: bug first; if you upload, the package will go straight into the archive, so that gives the release team no opportunity to object
<beuno> liw, did my suggestions not really fix the problem?
<Keybuk> tedg: that sounds like simple dbus policy
<Keybuk> so /etc/dbus-1/system.d
<liw> beuno, I failed to find a good way to implement them and the UI freeze snuck up on me, since I had subscribed to the wrong calendar and I generally suck
<gencho> by default ? :)
<beuno> liw, argh, sorry to hear that. Let me know if I can help you at all at any point
<liw> slangasek, ack; and should I file bugs for the UI change that didn't have a bug, and the package description change?
<liw> beuno, sure, thanks
<slangasek> liw: well - we're not in UI freeze yet, could those changes get in before tomorrow without a UIFe?
<slangasek> liw: in any case, it's preferable from my end to have a single bug documenting all the changes in the upload, so I can review it at once
<liw> slangasek, hm, I'm confusing myself, I think... they're not really feature changes, either, so perhaps I don't need feature freeze exceptions either
<slangasek> liw: if that means adding information to the existing bug, or filing a completely new bug with a summary, either is fine for me
<slangasek> liw: but if you can upload it without a freeze exception at all, even better, that saves us both time on paperwork :)
<liw> slangasek, I'll decide that I don't need freeze exception at all, thanks; now I just need to find someone to upload this to main
<tedg> Keybuk: Yup, that's what I wanted, thanks!
<slangasek> liw: if you don't find anyone else, throw it at me and I can commit to uploading it before end of day
<liw> slangasek, thank you
 * liw waves to mvo
<jelmer> didrocks, ping
<didrocks> jelmer: pong
<slangasek> liw: please be explicit that you're doing this, of course, so I know it's on my todo list :)
<liw> slangasek, of course
<liw> slangasek, I'll e-mail you if I can't lure mvo into uploading for me
<slangasek> ok
<davmor2> meh I just found a bug but I'm not sure what to report it against.  If you use the youtube plugin in totem and get the codec update so it works you then can't install ubuntu-restricted-extras from add/remove? So what is at fault is it totem for installing the wrong thing, add/remove for poor package management or the codec that is causing the issue?
<slangasek> pitti, doko: FYI, I'm taking care of transitioning postgresql-8.3 to python 2.6
<davmor2> D'oh wrong channel I need to look up from time to time :(
<didrocks> jelmer: ? :)
<jelmer> didrocks: sorry
<jelmer> didrocks, I was wondering what's left to be done for evolution-mapi
<didrocks> jelmer: it's ok, it will entered soon the archives. seb128 gave the FFe
<jelmer> didrocks: cool, thanks!
<didrocks> jelmer: you're welcome :)
 * didrocks is striking on a yelp regressionâ¦
<jdstrand> doko: fyi-- I responded to your questions in bug #337705 (letting you know here since I didn't see you were subscribed to the bug)
<ubottu> Launchpad bug 337705 in ufw "ufw crashes in trigger on intrepid->jaunty upgrade" [Undecided,Triaged] https://launchpad.net/bugs/337705
<pitti> slangasek: /away -all
<pitti> argh, sorry
<pitti> slangasek: oh, ok; will grab the diff from LP then and commit it to Debian
<slangasek> pitti: the diff is "build1"
<pitti> :)
<mvo> jdstrand: I outlined a possible workaround there as well (not a great one, but good enough)
<mvo> jdstrand: the upgrade test is still running
<jdstrand> mvo: you mean python conflicting with versioned ufw?
<mvo> jdstrand: yes
<jdstrand> mvo: it seems we are seeing this primarily because ufw is a python app that uses triggers...
<jdstrand> mvo: it would be best if this could be handled within ufw, since we know there will eveentually be other python transitions
<calc> ugh i crashed strace
<mvo> jdstrand: I think it will be less of a issue with the next transition because now it has "Depends: python (>= 2.5), python (<< 2.7)
<calc> it helps if debugging utilities weren't buggy themselves, lol :)
<mvo> jdstrand: this will ensure that on the next transition ufw will get updated to a new version before the new python gets installed
<mvo> jdstrand: I put that as a altnernative (less good) solution to issue a update for the intrepid version that does the same (for python (<< 2.6)
<doko> mvo, jdstrand: well, but it won't help if we have only one python version in the distro?
<mvo> jdstrand: more robustness inside ufw is always a plus of course :) I'm not sure what the best way to handle this is inside ufw, I do not enough enough about it
<mvo> doko: what would not help? the >= 2.5,  <<2.7 depends?
<jdstrand> mvo: I suppose I could program defensively around frontend.py not being available, but it would necessarily have to exit
<jdstrand> mvo: and we lose the trigger...
<doko> mvo: ahh, ok, but then the package could be updated in intrepid as well?
<mvo> jdstrand: I guess the question is what does a missed trigger mean
<doko> jdstrand: are the iptables still in place when the package is removed?
<ivoks> seb128: ping
<jdstrand> mvo: it ends up being called later in the upgrade, so I don't think it would be too horrible
<mvo> doko: right, I put that as a solution into the bugreport, its not ideal though because people may upgrade without intrepid-updates (e.g. when they do CD->CD upgrades without network)
<mvo> jdstrand: sounds like a good solution then, does not help for the problem with the intrepid version though
<jdstrand> doko: yes. default is set to ACCEPT on purge
<seb128> ivoks: contextless ping gives no reply
<mvo> we could do some magic in update-manager (e.g. killing the trigger before the upgrade or something ugly like that). but I would prefer a solution that avoids that
<ivoks> seb128: evolution-mapi didn't work at all; evolution crashed on authentication
<doko> ok, so the rules stay intact during upgrade
<ivoks> seb128: right, sorry
<jdstrand> doko: heh, I meant 'no. default is set to ACCEPT on purge'
<seb128> ivoks: oh? did you get a stacktrace?
<seb128> ivoks: thanks for testing
<doko> jdstrand: but not on remove?
<doko> or upgrade
<ivoks> seb128: not yet, i'll test more... i got vpn connection to that site, so i'll investigate more these days
<jdstrand> doko: putting triggers aside, remove and upgrade does not touch the iptables rules
<doko> jdstrand, mvo: another solution would be to create another symlink farm in /usr/share/ufw/lib or something like this, and fall back to this if the module cannot be found on sys.path. ugly as well ...
<seb128> ivoks: thanks!
<mvo> doko: and would mean to update the intrepid version again :/
<tedg> It seems that ConsoleKit is failing to build, but I'm reasonably certain I didn't do it :)  Is there any reason the documentation would fail to build?  http://www.tighturl.com/c1w
<doko> mvo: please could you update python-defaults then? I'm away then. so it's not a packaging helper problem.
<mvo> doko: sure, is it maintained in bzr or should I just use the package
<mvo> doko: no helper problem, just a general upgrade problem
<ivoks> seb128: np
<mvo> (I initially though it was a unpack/configure race, but that was not it)
<mvo> tought
<mvo> thought *sigh*
 * mvo needs sleep
<jdstrand> heh
<jdstrand> mvo: I can certainly fix jaunty and do an SRU for intrepid which would minimize the impact
<jdstrand> mvo: but if you are adjusting python deps, I guess the SRU is not needed
<jdstrand> s/deps/conflicts/
<mvo> jdstrand: yeah, I think so too
<mvo> jdstrand: the sru is not sufficient to deal with all users so we can as well skip it and add the workaround
<jdstrand> mvo: can you add a task to the bug for whatever python package needs updating? will you handle the change to that package or shall I?
<mvo> jdstrand: I can do the python update
<calc> anyone know why i see weird stuff in my strace log like this: 22379 14:39:51.796775 read(56, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0output.strace\0\0\0"..., 1024) = 32
<calc> it looks like strace is dumping some of its own info into the strace output file
<jdstrand> mvo: cool, thanks. I'll fix up ufw
<davmor2> Meh launchpad keeps timing out on me :(  is there anyway that libavcodec52 and libavutils49 can be replaced by lbavcodec-unstripped-52 and libavutils-unstripped-49
<davmor2> meh sorry hit enter. when upgrading from totem's codec install to ubuntu-restricte-extras
<davmor2> s/restricte/restricted
<oliver_g_1> hi
<oliver_g_1> I tried running `bzr  branch "http://package-import.ubuntu.com/v/vino/jaunty"` on my Debian Lenny system, and it complained that "Bazaar Branch Format 7 (needs bzr 1.6)"...
<oliver_g_1> is there a mirror available of these repos which works with older bzr versions as well?
<oliver_g_1> (bzr on my system is at 1.5-1.1)
<oliver_g_1> or, do you know another way to quickly see the changes between Vino from Intrepid and Vino from Jaunty?
<Rocket2DMn> pitti, ping, can I borrow a moment of your time?
<LaserJock> oliver_g_1: you could grab the actual source packages and debdiff
<oliver_g_1> LaserJock: sounds good
<oliver_g_1> LaserJock: what would be the command to get a diff between two source packages?
<LaserJock> oliver_g_1: debdiff <first package>.dsc <second package>.dsc
<calc> how do i set a breakpoint for c++ code that has weird parameters?
<oliver_g_1> LaserJock: thanks, that worked nicely
<oliver_g_1> with 2x dget and then debdiff
<pitti> persia, TheMuso: could you please pull lp:~pitti/usplash-theme-ubuntustudio/usplash-theme-4/ into lp:~ubuntustudio-dev/usplash-theme-ubuntustudio/ubuntu ? I just uploaded it
<TheMuso> pitti: sure, will take care of that now.
<pitti> TheMuso: thank you
<LaserJock> pitti: were you planning on updating edubuntu's usplash?
<pitti> LaserJock: yes, I'm doing them all
<LaserJock> pitti: don't bother, I'm removing it altogether
<pitti> LaserJock: oh, ok; shall I remove the package now/
<pitti> ?
<LaserJock> pitti: if you want
<pitti> LaserJock: what shall I put as rationale?
<LaserJock> we decided with our status as an addon and the maintanence burden that we'd just get rid of our usplash
<TheMuso> pitti: pulled and pushed to our branch, thanks a lot.
<pitti> okay
<LaserJock> it doesn't make sense to change all branding when we're just an addon
<pitti> right
<LaserJock> and I don't want to mess with usplash bugs ;-)
<pitti> TheMuso: thanks
<slangasek> pitti: why did you mark bug #217504 as 'triaged' again for linux?  AFAICS there's no change we're going to make to the kernel for this
<ubottu> Launchpad bug 217504 in linux "acpi_fakekey stopped working for certain keycodes" [Undecided,Invalid] https://launchpad.net/bugs/217504
<pitti> slangasek: I thought we'd still need acpi-support for all the ACPI events that the kernel doesn't (yet) convert to key events?
<pitti> if we instead want to fix all those in the kernel, I'm more than happy to drop the acpi_fakekey hack
<slangasek> pitti: then that would be a bug on acpi-support, or am I missing some reason it should be assigned to linux?
<pitti> slangasek: it's meant to be on acpi-support, yes
<slangasek> the acpi_fakekey hack is already broken; are you proposing to revert the upstream kernel change?  oh, ok
<pitti> sorry if I screwed up something
<slangasek> I was just confused because it was still listed against linux :)
 * TheMuso should have a play with plymouth at some point.
<pitti> superm1: hm, I'd like to fix mythbuntu-artwork-usplash, but the Vcs-Bzr: field is wrong; do you have the correct branch, or shall I just upload and send you the diff?
<superm1> pitti, try lp:~mythbuntu/mythbuntu/mythbuntu-artwork-usplash
<superm1> what's it listed as?
<pitti> superm1: meh, I just typoed, sorry
<Daviey> pitti: What's up with it?
<pitti> Daviey: I uploaded a new usplash which defines a new theme version, so I need to update/rebuild all usplash themes
<Daviey> pitti: okey, cool. Thanks
<pitti> Rocket2DMn: pong
<pitti> superm1: can you please pull lp:~pitti/%2Bjunk/mythbuntu-artwork-usplash-theme-4/ into lp:~mythbuntu/mythbuntu/mythbuntu-artwork-usplash/ ?
<superm1> pitti, sure
 * calc tries to get OOo to compile in full debug mode for debugging gvfs/gio breakage
<superm1> pitti, merged, you can trash your branch now if you want
<pitti> superm1: thanks
<didrocks> mdke: I found the issue in yelp. It's related to a new .in upstream file. Fixing it now
<calc> it appears debug mode doesn't work it causes the build to fail, lovely :\
<calc> yet another reason to attempt to switch to upstream version (/me bets this is ooo-build breakage)
<calc> actually this looks like upstream never builds with debug mode (i think?) doesn't look like ooo-build broke it
<gencho> good night guys and gals :)
<Rocket2DMn> pitti, ping back
<pitti> good night everyone
<Rocket2DMn> ah, good night, I'll talk to you tomorrow pitti
<mdke> didrocks: yay!! thanks a lot
<mathiaz> slangasek: which test was failing for openldap 2.4.15 in debian? test034-translucent?
<slangasek> mathiaz: no, it was a concurrency test
<slangasek> i.e., it had 'concurrency' in the name
<slangasek> (easy to guess why it failed, since it hung - non-trivial to debug, though)
<mathiaz> slangasek: hm ok. 2.4.15 fails to build because test034-translucent fails on jaunty
<slangasek> hmm, not reproducible in sid
<avb> guys, does gnome still use libgnome to play sound events?
<avb> i figured out that only libgnome2-0 now depends on libesd
<avb> so, once this functional is already depricated its probably will be good reason to drop this dependency and build it with --disable-esd
<TheMuso> avb: no it now uses libcanberra, as of the verfsion in intrepid
<avb> so it will be possible to drop libesd and esound-clients package from ubuntu-desktop
<TheMuso> avb: No, because of pulseaudio's esound compatibility.
<TheMuso> esound-clients maybe, but certainly not libesd
<TheMuso> but again, I could be wrong.
<TheMuso> it may no longer be needed.
<TheMuso> haven't looked that deaply into it.
<avb> i feel it should be more deeply researched.
<avb> its hard to say for sure
<avb> so just a thought for now
<TheMuso> avb: certainly an idea for karmic.
<avb> libesd will be installed as a dependency for an applications which it requires. and its nothing to do with pa esound  emulation, i feel
<TheMuso> ok
<avb> yes, i will research more what is what
<avb> and will send a mail to a ml
<avb> probably its a non needed job, coz i feel for gnome 2.28 libgnome will be completly deprecated
<TheMuso> I don't know anything about that.
<avb> http://live.gnome.org/ProjectRidley
<avb> http://live.gnome.org/LibgnomeMustDie
<giaco> hello
<giaco> how can I use the debug symbols I've downloaded from the mesa-swx11-dbg package now located in /usr/lib/debug/usr/lib/libGL.so.1.5.070200
<giaco> ? please
<slangasek> they're used automatically by gdb.
<azeem> that's a new one. Escalating from (I guess) #ubuntu to #debian and then to #ubuntu-devel
#ubuntu-devel 2009-03-05
<giaco> azeem, you missed the right order
<azeem> dang
<giaco> but probably you could guess one answer :-P
<giaco> really, I'm reading the gdb manual to find out why the backtrace always says that the library doesn't have any debug symbol.
<avb> giaco: just in case u can use LD_PRELOAD=/usr/lib/debug/usr/lib/libGL.so.1.5.070200 gdb myappname
<slangasek> no, you can't
<avb> why?
<avb> was working all the time just fine
<avb> :)
<giaco> no, it just contains debug symbols
<avb> ah
<avb> i see
<giaco> that's what I've just learned: it segfaults immediately if I preload it
<giaco> isn't there a way to confirm that gdb loads the symbols automatically? The backtrace says that /usr/lib/libGL.so.1 is used, but no symbols inside
<slangasek> giaco: that's really not on-topic for this channel; but are you sure that /usr/lib/GL.so.1 on your system is the one from libgl1-mesa-swx11?
<giaco> slangasek, that's what this page says http://packages.ubuntu.com/intrepid/i386/libgl1-mesa-swx11/filelist
<giaco> I've just installed it, I could reinstall it if it's necessary
<slangasek> that's the wrong place to look; the question is not "does libgl1-mesa-swx11 contain such a file", the question is "is that the package which provides that file on your system"
<slangasek> that question is answered by dpkg -S /usr/lib/libGL.so.1 - and now this is definitely off-topic
<giaco> it's off topic, ok, btw libgl1-mesa-swx11: /usr/lib/libGL.so.1 and the debug is not working
<mathiaz> kees: so it seems that pie breaks at least one test case in openldap 2.4.15
<mathiaz> slangasek: ^^
<mathiaz> slangasek: debian doesn
<mathiaz> slangasek: debian doesn't enable pie in openldap right?
<slangasek> there's nothing in the Debian packaging to enable PIE, no
<mathiaz> slangasek: great - thanks.
<mathiaz> kees: how can I debug this?
<kees> mathiaz: ew, is it only with the new version?
<kees> mathiaz: I've actually never debugged a PIE problem, but I'd basically treat it like any other corruption problem -- what's die, where, what variables are involved, and how does it compare to the non-PIE version
<mathiaz> kees: yes - 2.4.14 built sucessfully in jaunty
<mathiaz> kees: 2.4.15 does not
<mathiaz> kees: it always fails in the same test case.
<mathiaz> kees: ok - I'll try to replicate the setup - a least I've got a test case to work from
<TheMuso> /c/c
<vbgunz> I pretty much got suspend to ram working pretty flawlessly. anyone have any ideas why suspending to disk can still be an epic failure? I'll try anything, any ideas?
<vbgunz> I finally got suspend to disk working too. but upon second resume, although everything appeared fine, my networking is dead. the first time it was fine. the second time, dead and sudo /etc/init.d/networking restart|stop|start didn't do a thing about it :/
<vbgunz> can someone help me troubleshoot that?
<ScottK> vbgunz: Help is in #ubuntu for dapper/gutsy/hardy/intrepid and #ubuntu+1 for Jaunty
<vbgunz> ScottK: ok. thought this was a big issue here. I have about 90% suspend issues solved. 100% if not for the failed network on second resume. cool.
<pitti> Good morning
<sbeattie> pitti: moin
<sbeattie> pitti: re apport-collect, in https://bugs.launchpad.net/ubuntu/+source/cups/+bug/336512 the reporter used apport-collect to collect additional information, but it looks like only the stuff reported by attach_hardware(report) got attached and not attach_printing(report), which is sadly the crucial bit. Any idea why?
<ubottu> Launchpad bug 336512 in cups "HP Deskjet F4180 not detected as printer on Jaunty" [Undecided,Incomplete]
<pitti> sbeattie: but it does
<pitti> sbeattie: there's Papersize and a (failed) lpstat
<sbeattie> pitti: hrm, but where's the cups error log?
<pitti> sbeattie: problem for error_log is that a normal user doesn't have permission to access it
<sbeattie> Oh. mu.
<pitti> PpdFiles is missing, too, though
<pitti> sbeattie: looks like the hook crashed halfway through
<pitti> sbeattie: let me try that here locally
<sbeattie> pitti: was wondering if the failed lpstat was causing something like that.
<pitti> no, shouldn't
<pitti> but wait..
<pitti>     nicknames = command_output(['fgrep', '-H', '*NickName'] + glob.glob('/etc/cups/ppd/*.ppd'))
<pitti> sbeattie: ^ if the glob is empty, then this will hang forever
<pitti> >>> apport.hookutils.attach_printing(r)
<pitti> -> indeed that never returns
 * pitti fixes
<pitti> sbeattie: ah, and it also tries to attach "error-log", not "error_log"
<sbeattie> cool, thanks for digging into it.
<pitti> sbeattie: btw, attaching error_log will do fine for crashes (which are processed as root), but not for bug reports
<pitti> arguably those log files should be root:adm, not root:lp
<sbeattie> is there anything sensitive that gets reported in error_log?
<pitti> well, file names, dates, etc.
<directhex> tseliot, after all that, seems 180.11 DOES support the 216-core gtx260..... however, intrepid's kernel doesn't support the audio or networking on my board ;)
<directhex> so seems i'll be updating my desktop to jaunty earlier than planned :|
<tseliot> directhex: problem solved then, well kind of ;)
<directhex> tseliot, good thing i had a spare tg3 card
<slytherin> StevenK: Hi. Do you maintain seed for mobile-meta?
<StevenK> slytherin: I do.
<slytherin> StevenK: just wanted to bring bug 337881 to your attention. :-)
<ubottu> Launchpad bug 337881 in mobile-meta "Please remove libpt-1.10.10-plugins-* from ubuntu-netbook-remix dependencies" [Undecided,New] https://launchpad.net/bugs/337881
<StevenK> slytherin: Commented on, thanks!
<lool> Where are the removal reasons again?
<lool> StevenK: Could you please check why mesa-swx11-source was removed in intrepid?
<lool> StevenK: it's needed to build vnc4 it seems
<lool> Build-Depends: ... mesa-swx11-source (>> 6.4.1)
<StevenK> lool: The removal reasons have all been pulled into LP
<lool> Ah right
<StevenK> lool: But dropping a binary is up to the source package that provided it
<lool> StevenK: Right, I see it was dropped in mesa now; thanks
<Cimi> how can I download the linux-image souce?
<Cimi> the LPIA jaunty port has a mistake
<Cimi> strangely it lacks of the ext4 module
<Cimi> it has to be recompiled/patched
<cjwatson> I'm fairly sure there's a bug report about that
<cjwatson> apt-get --only-source source linux
<Cimi> I did them
<cjwatson> I've targeted it for jaunty so that it doesn't get forgotten (bug 331848)
<ubottu> Launchpad bug 331848 in linux "Cannot mount ext4 on linux-image-lpia" [Medium,Triaged] https://launchpad.net/bugs/331848
<Cimi> perfect
<Cimi> anyway apt-get --only-source source linux doesn't work with jaunty
<Cimi> it doesn't fetch the sources
<Cimi> just something like a meta package
<Cimi> only few bytes
<directhex> correct
<directhex> linux-meta
<Cimi> where's the source of those packages?
<cjwatson> are you sure you used the --only-source option?
<Cimi> I've tried a lot of combinations, it just downloads the linux.meta
<cjwatson> hmm, indeed that doesn't work, odd
<directhex> oh. tee hee. the source package "linux" contains images; the source package "linux-meta" contains the "linux" package
<cjwatson> yeah, but --only-source is meant to avoid that problem
<cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ anyway
<directhex> apt-get source linux-image-2.6.28-8-generic ;)
<directhex> sigh, there has GOT to be a better way to enumerate model= parameters for snd-hda-intel than looking at the source
<Cimi> generic will work for LPIA?
<cjwatson> Cimi: same source package, don't worry about it
<cjwatson> hmm, apt-get source seems a bit broken here
<Cimi> I mean when I will run the dpkg-buildpackage it will generate the lpia deb with custom kernel config?
<cjwatson> if you're building on an lpia system, yes
<Cimi> but I want the lpia config with the lpia patches
<Cimi> just with ext4 support
<cjwatson> mvo: why does 'apt-get source linux-source-2.6.28' print out some strange misformatted messages and then get me the linux-meta source?
<cjwatson> Cimi: yes
<Cimi> I don't want a generic, i385 compiled for lpia
<Cimi> ok
<Cimi> *i386
<cjwatson> 'apt-get source linux-image-2.6.28-8-generic' doesn't work at the moment anyway
<cjwatson> Cimi: just download the source from http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ directly
<Cimi> cjwatson, I'm using apt-get source linux-image-2.6.28-8-generic
<Cimi> it works here
<cjwatson> Cimi: you want the linux_2.6.28.orig.tar.gz, linux_2.6.28-8.27.diff.gz, and linux_2.6.28-8.27.dsc files
<cjwatson> ok
<Cimi> cjwatson, I would like to attach a patch on the bugreport, which is the correct way to get debian diffs? I mean, i just need to use diff on the uncompressed folder or something different?
<cjwatson> Cimi: is a patch actually going to speed things up? it would take a kernel developer about ten seconds to fix
<cjwatson> (so I nudged them)
<Cimi> it's one second patch
<cjwatson> so don't bother :)
<Cimi> ok ;)
<cjwatson> Cimi: for submitting patches to the kernel in general though, https://wiki.ubuntu.com/KernelGitGuide
<Cimi> but since this bugreport is opened from days and no one did anything...
<cjwatson> Cimi: so you could do that
<mvo> cjwatson: looks like a bug, give me a sec, I have a closer look (it seems to prefer the binary "linux" that is build from linux-meta over the srcpkg "linux"
<cjwatson> mvo: well, that's just the behaviour that --only-source changes; but linux-source-2.6.28 should be unambiguous
<cjwatson> (I'm not asking for the --only-source default to change, that seems like a bikeshed)
<cjwatson> Cimi: smb_tp said he'd fix it
<Cimi> cjwatson, so I just need to wait for an updated package?
<cjwatson> that's usual when a developer says he'll fix something, yes :)
<Cimi> cjwatson, please ask him when it will be released: I have a big partition I would like to use, and I need to know if it worth a compile on my netbook
<cjwatson> Cimi: you can ask him yourself, he's here
<Cimi> oh :)
<Cimi> smb_tp, ^^
<smb_tp> I am on it to enable the ext4 module
<Cimi> yeah
<Cimi> do you know when the package will hit the repository?
<smb_tp> not exactly, I'll have to check with someone else, but I could provide you with intermediate kernels.
<Cimi> that would be wonderful, compilation on an atom is somewhat painful :)
<directhex>         _R("RTL8168d/8111d",    RTL_GIGA_MAC_VER_25, 0xff7e1880)  // PCI-E
<directhex> damn. jaunty supports this, but not intrepid
<smb_tp> I know :) Will update the bug when I got something up
<Cimi> smb_tp, something like a link on a deb? :-)
<smb_tp> yep
<Cimi> amazing, thank you
<directhex> intrepid has RTL_GIGA_MAC up to VER_20, new motherboard has VER_25
<mvo> cjwatson: it seems like the prolem is that it goes over the Source file sequentially and stops on the first (bin|src) name it finds. so if the bin linux name is found first it gives this confusing result
<Cimi> mvo, cjwatson https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/330103
<ubottu> Launchpad bug 330103 in linux-meta "[jaunty] apt-get source linux-image`-uname -r` does not download sources" [Undecided,New]
<mvo> thanks Cimi
<slytherin> pitti: with regards to bug 305790, any idea why lucene2 was never moved to main?
<ubottu> Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790
<davmor2> guys what package should I file this too Bug 338159
<ubottu> Launchpad bug 338159 in ubuntu "Jaunty: libavcodec52 and libavutils49 conflict with the unstripped versions" [Undecided,New] https://launchpad.net/bugs/338159
<directhex> davmor2, you know that's intentional, right?
<davmor2> almost certainly but you can't overwrite the one with the other
<slytherin> davmor2: what do you mean by overwrite?
<directhex> not clear to me. the conflicts is intentional, it forces apt to replace onewith the other (but never both together) as needed
<slytherin> right. Even I am not clear what the issue is.
<davmor2> slytherin: I understand this.  How ever only synaptic is able to replace the packages.  Add/remove and apt-get can't and don't give a sensible explanation as to why it failed
<davmor2> slytherin, directhex: It is this that I'm having issues with rather than the conflict in packages
<slytherin> davmor2: Both synaptic and add/remove use apt-get as backend. So I don't see why it should fail in apt-get and add/remove while it works in synaptic.
<directhex> davmor2, you've neglected to paste the actual messages from apt/synaptic/whatever, which makes it harder to diagnose
<slytherin> davmor2: may be there is something wrong on your system.
<davmor2> slytherin: it's a vanilla install and it has been confirmed by others
<davmor2> directhex: it just says it can't be installed in add/remove syaptic says nothing it just removes the non-unstripped versions
<Keybuk> superm1: around?
<directhex> hm @ current gdm theme in jaunty. not unique & brown enough!
<slytherin> directhex: and I remember some problem with the right click menu not visible enough.
<asac> Keybuk: http://launchpadlibrarian.net/20975050/ifupdown_0.6.8ubuntu13_0.6.8ubuntu14.diff.gz
<asac> Keybuk: did you look at the debdiff before uploading?
<Keybuk> asac: webm always goes mad
<Keybuk> oh
<Keybuk> that debdiff isn't even webm mostly
<asac> Keybuk: well. you trashed the complete _darcs directory ;)
<Keybuk> it's just that _darcs isn't included in the .tar.gz now
<asac> Keybuk: can you do something like that: https://edge.launchpad.net/ubuntu/+source/ifupdown/0.6.8ubuntu12
<Keybuk> and this is a bad thing because?
<asac> Keybuk: unreadable debdiff ...
<asac> Keybuk: i dont care. its just that the feature to not up interfaces if they are managed=true by NM seemed not to work
<asac> and i tried to find the reason ;)
<Keybuk> I guess dpkg doesn't include the _darcs directories anymore?
<Keybuk> I would have just done dpkg-buildpackage -S
<asac> Keybuk: yes. you need to trick it
<asac> thats why i had this issue in ubuntu11
<Keybuk> yeah, can't be arsed with that
<Keybuk> if a package needs to be tricked to dpkg-buildpackage, it's a bug in the package
<asac> Keybuk: its -I""
<asac> or something
<Keybuk> putting revision control in the package is a bug anyway
<asac> Keybuk: well. tell that debian ;)
<asac> Keybuk: i agree, but do having this diff in ubuntu makes future merges hard
<Keybuk> we can fix that next time we merge
<cjwatson> Keybuk: are you building on intrepid by any chance?
<Keybuk> asac: hmm, the _darcs directory has come back again?
<asac> Keybuk: even after filtering out _darcs from the diff its still really huge ;)
<Keybuk> cjwatson: yes
<cjwatson> Keybuk: see bug 317761
<ubottu> Launchpad bug 317761 in dpkg "dpkg-source sets -i -I by default" [Undecided,Fix released] https://launchpad.net/bugs/317761
<cjwatson> I'm just uploading an SRU for that now
<Keybuk> ahh
<Keybuk> interesting
<asac> Keybuk: not sure. i will check now if the ifupdown feature is really broken ... if not i will not care
<Keybuk> I thought that was deliberate :p
<asac> if it is, i will let you knwo ;)
<cjwatson> nah, causes real problems
<Keybuk> heh
<Keybuk> I should just upgrade dpkg to jaunty I guess
<cjwatson> particularly for people who are intentionally trying to put binary gunk in source packages for one reason or another
<cjwatson> you can test my SRU once it's approved :)
<Keybuk> ok, deal
<asac> Keybuk: could it be that we dont run ifup -a at boot time anymore now?
<asac> but ifup IFACE for each individual one?
<Keybuk> we do run ifup -a at boot
<asac> Keybuk: hmm ok. i will check why the managed=true NM case was broken on my last boot then
<asac> e.g. it was upped
<asac> thanks
<Keybuk> just once
<Keybuk> for one release
<Keybuk> or even just one day
<Keybuk> I'd like the brightness setting and keys to work properly on my Dell
<ion_> :-)
<directhex> i've never owned a dell where they DON'T work!
<directhex> it seems computers just hate you, Keybuk
<Hobbsee> wfm?
<Hobbsee> but still - i'd *love* my next track button to work again!
 * Hobbsee has never been able to track that one down
<Keybuk> directhex: if I don't touch my laptop, the backlight basically turns off
<Keybuk> then if I do anything ... nothing happens
<Keybuk> it doesn't go brighter again
<Keybuk> if I use the brightness keys, there are over a hundred presses required to get it back to full brightness
<Keybuk> and you can't just hold the key down either :p
<asac> Keybuk: so the reason seems to be that the udev rules now trigger ifup UDEVDEVICE
<Keybuk> asac: they have since ~dapper
<asac> really?
<Keybuk> pretty sure it was dapper, yeah
<asac> Keybuk: then the order seems to have changed ... or the udev rules are now triggered on startup while they were not in intrepid?
<Keybuk> nope, always been triggered on startup ;)
<asac> Keybuk: well. i 100% sure that ifup IFACE was not run on startup ... only ifup -a in intrepid ;)
<asac> Keybuk: any idea why? maybe the rules were broken?
<asac> anyway. now that i know whats up i will fix that somehow.
<Keybuk> if they didn't run, that was a bug in intrepid
<cjwatson> pitti: damn, you're ahead of me on http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html
<Keybuk> it might have been caused by that whole /var/run/network/initialized madness
 * cjwatson considers strategies for catching up
<cjwatson> ... ethical ones
<asac> Keybuk: you mean ifstate?
<Keybuk> asac: no, siretart did a whole bunch of changes in intrepid to try and fix a wpa_supplicant bug
<Keybuk> but broke just about everything else in the process
<Keybuk> he may have broken udev ifup too
<Keybuk> we reverted them all in jaunty
<asac> oh... that might be possible
<pitti> cjwatson: *psssst* <whisper>secret tip: fix more?</whisper
<pitti> cjwatson: I have 5 more in the pipe right now :)
<asac> anyway, i will fix that somehow, but come back to you in case i am still on top of changelog for next merge round ;)
<cjwatson> pitti: bah :)
<cjwatson> I'm working on it :)
<asac> pitti: so i talked to wellark. he said he would prefer if we wait till next week with mbpi
<pitti> go, cjwatson, go!
<asac> pitti: he wants to bake a real release over the weekend
<asac> pitti: did you already push the upload out?
<pitti> asac: hm, MBPI?
<pitti> oh, that
 * pitti knows that as Meyer-Briggs Personality Index
<asac> ;)
<pitti> (or something like that)
<ogra> cjwatson, hmm, didnt flash-kernel get moved to main during the arm enablement ?
<pitti> asac: can't talk longer, must fix more bugz!!
 * mneptok is an ENFP
<asac> pitti: sure. just wanted to let you know that we should wait with the upload/SRU
 * pitti is ISTJ
<pitti> asac: (just kidding); thanks for the heads-up
 * Hobbsee twitches at pitti
<cjwatson> ogra: I had thought so but apparently not
<ogra> cjwatson, ah, that might explain bug 336770 then *g*
<ubottu> Launchpad bug 336770 in debian-installer "Problems Installing Jaunty On NSLU2" [Undecided,Confirmed] https://launchpad.net/bugs/336770
<cjwatson> ogra: no bugs ever reported on flash-kernel so there can't have been an MIR either
<mneptok> asac: your nick always makes me think of notes Spanish-speaking developers write themselves to remind them to lock the house on the way out. ;)
<cjwatson> yes, I'll reassign
<ogra> right, i'll write one later today
<pitti> Hobbsee: http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
<asac> mneptok: heh. how does that come?
<Hobbsee> pitti: i'm aware.  it was discussed in lecture today, along with a whole lot of other management type things.   it's interesting, but...wow...
<mneptok> casa
<asac> mneptok: ;)
<mneptok>    make food
<mneptok>     watch movie
<mneptok> asac
<asac> mneptok: actually when my nick is not avail, i use asacasa :)
 * directhex is chaotic neutral
<mneptok> directhex: Chaotic Good FTW
<directhex> mneptok, i'm a mono packager, i don't think i'm allowed good alignments
<mneptok> directhex: http://www.wilddamntexan.com/kids/demotivators/chaotic_good.jpg
 * Keybuk always gets a different result every time he takes one of those tests
<Keybuk> mneptok: isn't that just "good" in 4th ed?
<mneptok> Keybuk: i still have my First Edition rules. you kids ...
<stgraber> seb128: hey, any idea what change in Jaunty's gnome broke the way LTSP makes USB keys and other local medias to work ?
<seb128> no
<stgraber> seb128: basically mounting something in /media no longer appears on the desktop
<seb128> I've not clue about ltsp
<ogra> seb128, gvfs used to pick up all mounts that show up in /media, does it still do that ?
<stgraber> seb128: LTSP mounts local devices in /media/<USERNAME>/<device name> so something like /media/stgraber/usbdisk-sdc
<seb128> ogra: dunno, we got no bug about it not doing that and there is no reason to think that it changed
<ogra> well, ltsp is the only thing acutally relying on it
<seb128> you guys write a testcase which work on an ubuntu desktop and I will have a look
<seb128> I don't plan to a ltsp install for that
<ogra> indeed
<seb128> hum? on media mounts?
<ogra> and thats not needed
<seb128> usb keys are mounted there
<seb128> I've fstab partitions mounted there
<ogra> on gvfs picking it up from the directory change
<seb128> wfm
<ogra> without hal being involved
<seb128> ntfs and usb key are listed
<ogra> or dbus ...
<ogra> ok
<savvas> is nvidia graphics driver 180 in intrepid considered "silent"? it's not present in hardware drivers and many users are wondering why
<directhex> savvas, it's a backport. you need to explicitly install the modaliases
<directhex> nvidia-180-modaliases package
<directhex> possibly also run jockey-gtk -u
<savvas> ah... thanks for the tip directhex :)
<james_w> for those that were hitting the 2.6 problems with it, a fixed bzr-builddeb has just been synced, sorry for the delay
<Keybuk> cjwatson: got that SRU yet?
<cjwatson> Keybuk: it's uploaded and waiting for ubuntu-sru to review, I believe
<cjwatson> Keybuk: you could pull the patch from the bug and build it
<Keybuk> what's the bug#?
<cjwatson> 12:02 <cjwatson> Keybuk: see bug 317761
<ubottu> Launchpad bug 317761 in dpkg "dpkg-source sets -i -I by default" [Undecided,Fix released] https://launchpad.net/bugs/317761
<geser> doko: have you some time to look at python-4suite? Building for python2.5 works but with python2.6 setup.py only eats memory and I've no idea how to debug this. A build log is at http://launchpadlibrarian.net/23448421/buildlog_ubuntu-jaunty-amd64.python-4suite_1.0.2-7ubuntu1_FAILEDTOBUILD.txt.gz
<doko> geser: there's a bug report about it, not compatible with 2.6. we should repackage this as python2.5-4suite
<ScottK> doko: It is problematic though since it has rdepends.
<doko> ScottK: yes, however what do you want to do?
<ScottK> I want you to fix it?
<ScottK> Dunno.  I'm afraid the transition to 2.6 isn't quite as smooth as I'd hoped.
<ScottK> jelmer: Are you interested in doing the packaging changes for samaba4 for Python2.6?  I'd rather not be touched-it-last for samba4.
<james_w> it's not a trivial one
<jelmer> ScottK, shouldn't it just be a binNMU (or whatever the equivalent of that is in Ubuntu)?
<ScottK> jelmer: We don't have binNMU, it's all sourceful uploads.  It does look like rules needs a spot of work due to site-packages/dist-packages in 2.6.
<directhex> jelmer, ubuntu doesn't have a maintainer per package per se, so there's no "non-maintainer" to upload. however, generally the last guy in changelog gets consulted about the package as a guy who "cares" about it, and i think ScottK would rather someone convenient with an @samba.org address did it instead of him ;)
<kirkland> Keybuk: hi, are you around?
<Keybuk> always
<kirkland> Keybuk: sweet, could you have a look at Bug 71418
<ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed] https://launchpad.net/bugs/71418
<maxb> Hi, when proposing a debdiff to a package not currently using a patch system and not currently having any patches outside debian/ dir, is it correct to just patch the package in the traditional directly-in-.diff.gz way?
<Keybuk> is there new information on it?
<kirkland> Keybuk: yes, i mean my latest comments :-)
<cjwatson> maxb: yes
<cjwatson> maxb: don't add patch systems to packages that don't have them, generally
<pitti> cjwatson: we had the "cdrom in fstab" discussion a number of times already; however, do you think it would be reasonable to at least use /dev/cdrom instead of hardcoded /dev/scd0??
<pitti> cjwatson: aside from the fact that the number might change, scd0 is already deprecated again AFAIUI (it's srN now)
<Keybuk> right
<kirkland> Keybuk: ?
<cjwatson> pitti: the installer doesn't hardcode /dev/scd0, actually
<kirkland> Keybuk: oh, that probably wasn't for me :-)
<Keybuk> kirkland: tab open, please wait ;)
<cjwatson> pitti: it uses the device that /cdrom gets mounted on
<cjwatson> pitti: which I think comes out of 'list-devices cd'
<pitti> cjwatson: right, I expect it detects it, but for the purpose of writing it into fstab I still consider it hardcoding
<cjwatson> I could try to check whether there's a symlink pointing there
<Keybuk> scd0 is a symlink itself
<pitti> cjwatson: maybe easier: if /dev/cdrom exists, put that in, otherwise use the current device name?
<cjwatson> scd0 isn't relevant
<directhex> there's a /dev/cdrom and /dev/dvd, i wonder if there are blu-ray names. remind me to check
<cjwatson> pitti: no, we should check that it matches the device actually in use, in case of multiple drives
<Keybuk> cjwatson: be thankful it's even there before ;)
<pitti> cjwatson: okay
<Keybuk> the scsi cd maintainer was pushing pretty hard to just drop it and only have /dev/sr0
 * pitti wishes we could just drop it entirely for desktop installs
<Keybuk> directhex: there are not
<seb128> I've "/dev/scd0       /media/cdrom   udf,iso9660 user,noauto,exec 0       0" in my fstab which breaks eject of unmounted CDs
<directhex> Keybuk, aw. but how else can i feel special about owning a blu-ray drive? :o
<pitti> for seb128's problem: eject apparently doesn't resolve symlinks in mount points
<seb128> $ eject /media/cdrom0
<seb128> eject: tried to use `/media/cdrom0' as device name but it is no block device
<seb128> eject: unable to find or open device for: `/media/cdrom0'
<directhex> so the bug is with eject, shirley?
<Keybuk> well, that's clearly just a bug in eject as well ;)
<pitti> absolutely
<Keybuk> if it can't found the mount point name, and it's looking at a symlink, it should at least call readlink()
<pitti> it just reminded me that we still put it into fstab in the first place, and with hardcoded device names
<Keybuk> yeah, the fstab entry is ugly
<Keybuk> I also find it odd that it's /dev/scd0 and /media/cdrom0
<Keybuk> shouldn't it /media/scd0 ?
<Keybuk> (or just /dev/cdrom and /media/cdrom)
<seb128> hum
<seb128> bug #264071
<ubottu> Launchpad bug 264071 in eject "eject -X reports "error while finding CD-ROM name"." [Undecided,Fix released] https://launchpad.net/bugs/264071
<seb128> pitti: you fixed that symlink bug in intrepid apparently
<pitti> seb128: that's what I seemed to remember, but apparently not then
<Keybuk> someone sync'd eject
<Keybuk>   * Merge to Debian unstable. Remaining Ubuntu changes:
<Keybuk>     - Fix eject -T for Macs (ioctl() can return EIO if tray is open). Thanks
<Keybuk>       to Andy Matteson for the patch. (LP #91873, Debian #504478)
<Keybuk>     - Resolve symbolic links when reading CD-ROM names, to fix "eject -X"
<Keybuk>       and possibly other modes. Thanks to Adam Buchbinder for the patch.
<Keybuk>       (LP #264071, Debian ##504480, submitted upstream via email)
<pitti> it might also have been to resolve symlinks for device names
<Keybuk> pitti did a merge
<ubottu> Launchpad bug 91873 in eject "eject -T doesn't close the tray" [High,Fix released] https://launchpad.net/bugs/91873
<ubottu> Debian bug 504478 in eject "eject: eject -T does not work on Mac" [Unknown,Closed] http://bugs.debian.org/504478
<ubottu> Launchpad bug 264071 in eject "eject -X reports "error while finding CD-ROM name"." [Undecided,Fix released] https://launchpad.net/bugs/264071
<Keybuk> then barely two days later, someone sync'd it
<Keybuk> says that pitti requested the sync ;)
<pitti>   * Added patches from Ubuntu submitted by Martin Pitt:
<pitti>     + Fix cdrom speed detection if /proc/sys/dev/cdrom/info references a
<pitti>       symlink. LP: #264071, Closes: #504480
<pitti> different symlink :)
<seb128> seems a different issue, the log on the debian bug had "eject: error while finding CD-ROM name"
<seb128> now it does
<seb128> "eject: listing CD-ROM speed
<seb128> 24
<seb128> "
<seb128> not sure what this 24 is about though
<Keybuk> eep
<Keybuk> should have so done a test reboot before that upload
<pitti> Keybuk: you want to say "don't dist-upgrade in the next couple of hours"?
<Keybuk> no ;) it's all good
<Keybuk> I just should have tested that one :p
<Keybuk> kirkland: right, let's look at this bug of yours
<kirkland> Keybuk: ;-)
<Keybuk> kirkland: ethtool enables wake-on-lan right?
<Keybuk> but you still need to not have the -i iirc
<Keybuk> otherwise reboot downs the interface, disabling it
<kirkland> Keybuk: one of many things that it does, but yes, it can set the WoL mode
<Keybuk> extra lines in /e/n/i are passed to the /etc/network/if-*.d scripts
<kirkland> Keybuk: I don't disagree with that;  but that alone is not sufficient to solve the problem on my kit
<Keybuk> so all you actually need to do is read $WAKEONLAN in /etc/network/if-down.d
<Keybuk> .../wakeonlan
<Keybuk> or is it up.d?
<Keybuk> whichever ifup phase you need ;)
<kirkland> Keybuk: cool, that actually sounds pretty straight forward
<Keybuk> (it might be $IF_WAKEONLAN actually)
<Keybuk> though configuring such things with /e/n/i sounds evil to me
<Keybuk> how will that interact with NetworkManager
<Keybuk> what about desktops?
<Keybuk> etc.
<kirkland> Keybuk: hmm, i thought you might say that
<kirkland> Keybuk: is NetworkManager able to set the WoL mode?
<Keybuk> kirkland: -> asac
<kirkland> asac and I discussed this briefly last week
<kirkland> asac: around? i did a bit of testing that you asked for, regarding bug #71418
<ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed] https://launchpad.net/bugs/71418
<kirkland> cjwatson: question for you, about a bug that i marked as a 'pet-bug' ...  bug #63172
<ubottu> Launchpad bug 63172 in vim "Better vimrc default" [Wishlist,Triaged] https://launchpad.net/bugs/63172
<kirkland> cjwatson: i'd like to upload something like this: http://pastebin.ubuntu.com/126749/
<kirkland> cjwatson: but i thought i'd check with you first
<cjwatson> kirkland: yes, I think that's fine
<cjwatson> kirkland: autoindent is known to piss some people off
<kirkland> cjwatson: agreed.
<asac> Keybuk: for me connection managers dont sound like the right place to set WoL ... which seems to be rather a device thing
<asac> i though it could be done in something lower, like udev looking at some config somewhere
<asac> thought
<cjwatson> kirkland: commented on the bug
<kirkland> cjwatson: cheers, thanks much
<Keybuk> I HATE YADA
<Keybuk> asac: then you need a root helper just to change the config
<asac> yeah. still putting it into a connection manager still sounds wrong. anyway, if its done it should be done in a if-*.d/ script, right.
<Keybuk> but does NM call those scripts properly?
<Chipzz> cjwatson: I have the following snippet in my .vimrc:
<Chipzz> " In normal mode, have <Insert> go to insert mode...
<Chipzz> noremap <Insert> i
<Chipzz> " ...and in insert mode, have <Insert> toggle paste mode (who uses replace anyway?)
<Chipzz> set pastetoggle=<Insert>
<asac> Keybuk: depends on what is properly for this case
<cjwatson> Chipzz: sure, so do I (or similar)
<Chipzz> dunnow if that makes sense though as a default
<Keybuk> asac: does it parse /e/n/i and pass the variables for the unknown options from it?
<Chipzz> Keybuk: what do you mean by "extra lines"?
<asac> Keybuk: probably not. which option should be passed in?
<Keybuk> asac: all of them
<Keybuk> Chipzz: if you put
<Keybuk> iface eth0 inet dhcp
<Keybuk>   hello-foo bar
<Keybuk> then the if-*.d scripts will get $IF_HELLO_FOO=bar passed to them in their environment
<Chipzz> that looks rather ambiguous?
<kirkland> cjwatson: i'm also going to decline that vimrc syntax-on change for Hardy
<kirkland> cjwatson: doesn't seem to rise to the level for SRU, IMHO
<asac> Keybuk: i wonder if you ask that because using /etc/network/interfaces is suggested in the bug or because you think thats the right place to configure WoL?
<Keybuk> just the former
<Keybuk> ie. I don't think ifup is the right place to do it at all
<kirkland> yeah, that was purely my crackpot idea
<asac> Keybuk: yeah. i dont think its the right place. this was ment to be a workaround for server setup
<Chipzz> kirkland: as you're on the topic of vimrc options; what about set background=dark by default to get decent colors in screen?
<asac> Keybuk: similar i dont think NM is the right place
<cjwatson> kirkland: oh heck yes
<cjwatson> kirkland: nominations crack is fairly common
<kirkland> Keybuk: asac: it's the first place i would go to as a system administrator to permanently (across interface restarts) change some aspect of my interface's configuration
<Keybuk> isn't it something you only want to do when powering down?
<Keybuk> "power down and wake on lan"
<kirkland> cjwatson: ;-)  cheers.
<Keybuk> sounds a bit like "power down and wake for updates"
<Chipzz> Keybuk: do options that get recognized by ifupdown also get passed that way, or just the unrecognized options?
<Keybuk> and "power down and wake on keyboard press"
<kirkland> Chipzz: hmm, dunno about that one
<asac> sounds a bit like powermanager should do the root config
<superm1> Keybuk, hi.  what's up?
<cjwatson> oh joy oh rapture I need a feisty chroot to investigate this bug
<directhex> yay feisty!
<directhex> isn't feisty dead?
<cjwatson> sure, but it's easier to start by reproducing the bug on the same release
<cjwatson> unless you have this strange religious belief that bugs magically become obsolete when we EOL releases ;-)
<directhex> i do!
<cjwatson> odd person
<Keybuk> superm1: there's an upload of dkms in the archive that you'll want to merge into your GIT tree
<superm1> Keybuk, noted. thanks.
<superm1> Keybuk, looking at http://launchpadlibrarian.net/23511372/dkms_2.0.21.1-0ubuntu1_2.0.21.1-0ubuntu2.diff.gz , was there actually anything changed for the second changelog entry?
<Keybuk> how do you mean?
<Keybuk> oh, weird
<Keybuk> where did that go?
<Keybuk> dkms isn't generated it is?
<Keybuk> *shrug*
<Keybuk> superm1: uploaded again ;)
<superm1> Keybuk, okay thanks
<Keybuk> it's in my test .deb
<Keybuk> but not in the source
<Keybuk> must have forgotten to run -S again after <g>
<ion_> Perhaps dput should be replaced as the preferred tool by something that runs both debuild -S and dput for its result. :-)
<ogra_> when did our default for TERM change ?
<Keybuk> ogra_: our default for TERM is "linux"
<Keybuk> this changed sometime in the 90s
<ogra_> ogra@osiris:~$ env|grep TERM
<ogra_> TERM=xterm
<ogra_> COLORTERM=gnome-terminal
<ogra_> ogra@osiris:~$
<ogra_> so why is minbe not since i upgraded to jaunty ?
<Keybuk> oh, no idea on _that_ one ;)
<Keybuk> you didn't say which default <g>
<ogra_> i juwst found out thats the reason why my minicom freaks out since the upgrade
<Keybuk> TERM=xterm has been the default for every ubuntu release though, no?
<ogra_> took me since the sprint to find that
<ion_> My gnome-terminal in jaunty seems to have TERM=xterm as well.
<Keybuk> (for X)
<ion_> Oh, so does my gnome-terminal in intrepid. So no change there.
<ogra_> Keybuk, well, then minicom doesnt know about xterm anymore since jaunty or something
<Keybuk> minicom should know about everything that terminfo knows about
<ogra_> right
<Keybuk> you have a /lib/terminfo/x/xterm ?
<ogra> yup
<Keybuk> ogra: though, WHILE YOU'RE HERE ... ;)
<ogra> YES ?!?
<Keybuk> ogra: /etc/modprobe.d/fuse
<Keybuk> is that one of yours? :p
<ogra> not completely, but i added it
<Keybuk> I have a few questions
<ogra> shoot
<Keybuk> what uses /sys/fs/fuse/connections ?
<ogra> fusectl iirc
<Keybuk> so, I can see why you did it that way
<Keybuk> but it's rather broken
<Keybuk> for example
<Keybuk> try this:
<Keybuk> sudo modprobe -f fuse
<ogra> feel free to wipe/redo/improve :)
<Keybuk> err
<Keybuk> sudo modprobe -r fuse
<ogra> that doesnt exec the modprobe.d stuff ?
<Keybuk> no, try it ;)
<ogra> do you promis it wont trash my system ?
<Keybuk> I promise
<ogra> i havew important stuff going on
<ogra> ok
<Keybuk> but if it does, you wrote that file <g>
<Keybuk> you'll get an error that fuse is in use, right?
<ogra> yup
<Keybuk> now ls /sys/fs/fuse/connections
<ogra> nothing
<Keybuk> right
<Keybuk> in fact
<Keybuk> it's not even mounted anymore
<ogra> right
<Keybuk> your remove rule unmounts it before attempting to remove the module
<Keybuk> but if the module fails to remove, the unmount has still happened
<ogra> right
<ogra> so the script needs a check
<Keybuk> you also don't use $CMDLINE_OPTS there
<Keybuk> so any command-line options passed to modprobe for the module will be dropped
<ogra> hmm
<Keybuk> I can't think of any better way to do what you're trying to do though :-/
<Keybuk> you can't do it from a udev rule because you can't remove the fuse module while the path is mounted
<ogra> right
<Keybuk> remove fuse { if grep -q " /sys/fs/fuse/connections " /proc/mounts; then /bin/umount /sys/fs/fuse/connections; fi } && \
<ogra> i tried with a udev rule first iirc
<Keybuk>         /sbin/modprobe -r --ignore-remove fuse $CMDLINE_OPTS || \
<Keybuk>         { if grep -q fusectl /proc/filesystems; then /bin/mount -t fusectl fusectl /sys/fs/fuse/connections; fi ; : ; }
<Keybuk> is what I came up with
<Keybuk> of course
<ogra> ugh
<Keybuk> none of this works if fuse is built into the kernel
<ogra> is it yet ?
<Keybuk> not yet
<Keybuk> but it's worth thinking about
<ogra> if its in the kernel we can have fusectl permanently mounted
<ogra> thats a non issue then
<Keybuk> it's force-loaded in /etc/modules
<ion_> Shouldnât that be modprobe -r || { mount; ... exit 1; } or something to convey the failure?
<ogra> right
<ogra> ion_, thats what it does ?
<Keybuk> ion_: that'd fail the remove and remove the module again I think :p
<ogra> oh, the exit
<Keybuk> oh, hmm, no idea what it'd do on a failed remove actually
<Keybuk> sorry, was thinking in terms of the actual C code there
<allquixotic> Well, there goes the rest of my day: http://watchout4snakes.com/creativitytools/RandomParagraph/RandomParagraph.aspx
<ion_> I prefixed the remove rule with âexit 1;â. % sudo modprobe -r fuse
<ion_> FATAL: Error running remove command for fuse
<allquixotic> ion_: Can't remove your fuse module? tried rmmod?
<ion_> allquixotic: You missed the context, that error message was intentional.
<allquixotic> ah!
<allquixotic> yes, I did miss the context
<ogra> Keybuk, well, i'd be for including it in the kernel by default
<ogra> and make fusectl a kernfs
<ogra> we add all users to fuse by default anyway and gvfs makes use of fuse all the time
<ogra> no need to keep it modular anymore
 * ogra vomits over his crashy X and hugs Keybuk for making reboots reasonably fast at least
<Keybuk> they'll get about 10s faster rsn
<ion_> How?
<ion_> sreadahead?
<Keybuk> ion_: new module-init-tools
<Keybuk> finally
<ion_> Oh, ok
<ion_> keybuk: I seem to fail at finding information about what has changed re: speed/performance.
<JanC> ion_: IIRC there was something that made modprobe much slower than needed
<Keybuk> ion_: https://wiki.ubuntu.com/FoundationsTeam/BootPerformance
<ion_> keybuk: Thanks!
<Keybuk> not fully up to date
<savvas> is there a pykde module I could use that reads /usr/share/locale and /usr/share/locale-langpacks directories?
<pitti> bash: x-terminal-emulator: command not found
<pitti> le huh?
<pitti> oh, argh; go, broken alternatives handling
 * Keybuk wonders who the hell LÃ¶dur is
<pedahzur> Is there anyone doing Qt 4.5 builds for Ubuntu Hardy?  (And planning on doing PyQt4.5 builds for Hardy?)  I want to do some Qt 4.5 work, but I'm not readyto move off of an LTS version.  Should I file a bug and ask for a back-port for those packages?
<SyL> anybody use eucalyptus?
<highvoltage> aparently colgate uses it in herbal toothpaste
<highvoltage> (and aparently ubuntu will too in 9.10)
<LaserJock> highvoltage: lol
<ScottK> pedahzur: Qt has far too many reverse dependencies to backport.  I can tell you right now I wouldn't approve it.
<SyL> I'm just asking about ubuntu's version of eucalyptus is all...
<pedahzur> ScottK: Bummer. Thanks, though.
<maxb> Can anyone enlighten me on how to build udev packages from the ubuntu packaging bzr? I've got the branch, I've got the orig.tar.gz in ../, but when I dpkg-buildpackage, it spews huge amounts of warnings about unrepresentable changes.
<pedahzur> join #kubuntu-devel
<pedahzur> oops
 * ScottK hands pedahzur a '/'
 * ogra hands ScottK a '\' so the / doesnt fall over
<ScottK> \o/
<ogra> heh
<ScottK> Tonio_: Altnernatively the problem is no one uploaded kde4bindings.
<cjwatson> maxb: I think you need to use bzr builddeb
<ScottK> Sorry wrong channel
<cjwatson> maxb: (which basically just chains through to dpkg-buildpackage but with the right options ...)
<maxb> cjwatson: that was my second guess, but apparently not - same errors
<Tonio_> ScottK: hum... https://edge.launchpad.net/ubuntu/jaunty/+source/kdebindings/4:4.2.1-0ubuntu2
<alex-weej> pulseaudio has frequently just killed itself since ubuntu introduced it, and it still happens in jaunty
<alex-weej> do we need a process to babysit it?
<alex-weej> it's really bad that sound apps sometimes just don't work when you try to launch them
<cjwatson> maxb: ok, I think it might be something like -i'(?:^|/)(?:\.bzr|\.git|test/)' then
<cjwatson> maxb: IIRC Keybuk had some problems getting bzr builddeb to DTRT
<maxb> yikes. Ok, I'll try. I can't imagine that people type that regex every build, though
<slangasek> alex-weej: Works For Me; maybe you should file a bug report about your issue
<slangasek> as for using a supervisor process... that would almost certainly make things worse.
<slytherin> can someone please give back evolution-exchange?
<alex-weej> /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute /usr/bin/gnome-session
<alex-weej> is this how we launch our desktop session?
<slangasek> alex-weej: yes?
<slytherin> can someone please give back evolution-exchange?
<jdstrand> kees: do you know what package sets up the sources.list file? specifically, the parts that say '## N.B. software from this repository is ENTIRELY UNSUPPORTED ..."
<kees> jdstrand: hrm, I don't -- I would assume it's a d-i template, maybe
<slangasek> apt-setup udeb, I think
<slangasek> sorry, 'apt-setup-udeb' actually :)
<jdstrand> slangasek: cool, thanks
<dtchen> alex-weej: please ensure your symptoms for 338377 are not in fact caused by 330814, and try my PPA packages.
<alex-weej> dtchen: does pa log anything anywhere that i can check?
<dtchen> alex-weej: yes, by default, /var/log/syslog
<dtchen> alex-weej: you will likely find it more useful to use `killall pulseaudio;pulseaudio -vvv'
<alex-weej> dtchen: ok, i will try and figure it out
<SuperQ> So this is probably too late for jaunty
<SuperQ> but is there a reason server installs don't include acpid?
<slangasek> what do you want acpid for?
<slangasek> (we're in the process of trying to get rid of it on the desktop)
<SuperQ> hardware event notification
<SuperQ> like powerbutton
<SuperQ> I'm playing with libvirt/kvm, and I noticed my hardy guests didn't shutdown when asked
<SuperQ> but Lenny would
<SuperQ> turns out it was that acpid was missing from hardy
<cjwatson> SuperQ: https://wiki.ubuntu.com/Hotkeys/Architecture
<cjwatson> also https://wiki.ubuntu.com/Hotkeys/Troubleshooting
<slangasek> I believe the power button handler is meant to be implemented by hal rather than acpid in jaunty
<slangasek> (which is not a hotkey actually, but a some-sort-of-standard ACPI 'button' event)
<SuperQ> That sounds like a great solution
<SuperQ> yea, psudo-standard event
<SuperQ> like standby-button
<slangasek> I don't think hal is currently in the server seed either, though
<slangasek> and even if it were, hal only handles propagating the event across dbus, it doesn't include anything to act on the event
<kees> cjwatson: dpkg is so much prettier with 392317 solved.  quiet postinst scripts shouldn't make themselves known via the dpkg output.  :P  This seems like a good fix to keep.
<kees> (that's debian bug 392317)
<ubottu> Debian bug 392317 in dpkg "dpkg: Empty lines in install/configure output (Setting up ...)" [Minor,Closed] http://bugs.debian.org/392317
<slangasek> so adding acpid+acpi-support to the servers might be the only possible short-term solution
<cjwatson> kees: I actually prefer it the way we have it now
<SuperQ> slangasek: hrm
<cjwatson> kees: I'd revert to the Debian fix if that was essentially our only remaining dpkg diff, though
<cjwatson> kees: that's actually not wildly implausible with the dpkg 1.15 series
<slangasek> SuperQ: I would suggest filing a bug on the ubuntu-meta package for this and subscribing the ubuntu server team
<Tonio_> hi
<SuperQ> slangasek: Sure
<Tonio_> slangasek: may I ping about something ? skrooge finally got accepted from NEW? and ended up... nowhere :)
<cjwatson> err ... I mean the Debian state, since I don't regard it as a fix :)
<Tonio_> slangasek: I have the email confirming it was accepted, btw...
<slangasek> Tonio_: it's in universe, dunno why you think it's "nowhere"
<kees> cjwatson: cool.  I'm curious about the technical benefit you see with it, since it's always erked me aesthetically
<slangasek> Tonio_: I see it in apt-cache policy as well, so it's mirrored successully
<SuperQ> slangasek: So this would be a bug against ubuntu-minimal or ubuntu-standard?
<slangasek> SuperQ: "ubuntu-meta", bugs are filed by source package :)
<slangasek> (so don't worry about the implementation details too much)
<Tonio_> slangasek: it just appeared, indeed... sorry for the stupid ping... when I looked a couple of hours ago I couldn't find it (it was accepted yesterday morning...)
<SuperQ> slangasek: Ok
<cjwatson> kees: I just always found it useful to know which packages actually had postinst scripts and which didn't, when debugging problems
<cjwatson> kees: if a package doesn't have a postinst, it saves time going and looking
<cjwatson> I don't actually recall the details, but I know that there have been cases where this saved me time :)
<kees> cjwatson: just a short-cut to looking in /var/lib/dpkg/info ?  yeah, I guess that can be useful.
<TheMuso> /c/c
<SuperQ> slangasek: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/36838
<ubottu> Launchpad bug 36838 in acpi-support "ubuntu-minimal/Server does not depend on acpi-support" [Medium,Fix released]
<SuperQ> slangasek: Matt Zimmerman says: No
<slangasek> ah. :)
<SuperQ> Not a great answer
<SuperQ> I can see the case for not caring about suspend
<SuperQ> but powerbutton is a very good use case for servers
<ivoks> that's acpid
<cjwatson> kees: a shortcut to looking in somebody else's /var/lib/dpkg/info/ when digging through dpkg output in bug reports :)
<slangasek> SuperQ: however, the rationale given was about 'power management', which I think overlooks the power button use case
<slangasek> SuperQ: so I think it's worth revisiting this
<SuperQ> I agree
<kees> cjwatson: I remain unconvinced :)  but then I want to have nothing to do with doing dpkg merges, so you can do whatever you like.  :)
 * slangasek plays whack-a-mole with the python2.5 server reverse-deps
<davismj> where would i go to ask a question about alpha 5 network manager?
<RainCT> davismj: try #ubuntu+1
<davismj> cool thanks
<SuperQ> slangasek: https://bugs.launchpad.net/bugs/338493
<ubottu> Launchpad bug 338493 in ubuntu-meta "server/minimal installs don't support power button events" [Undecided,New]
<slangasek> SuperQ: hmm, I expected we would reopen the old bug, but I guess a bug reference also works. :)
<SuperQ> well, the use case is different
<ScottK> SuperQ: I'd suggest talking to kirkland about it on #ubuntu-server as he's been investigating power related issues for server recently.
<SuperQ> ScottK: Thanks
<kirkland> SuperQ: ScottK: hi
<SuperQ> :)
<ScottK> OK.  or here
<kirkland> SuperQ: what's up?
<kirkland> (i'm only partially here ...  helping the wife with some chores)
<SuperQ> kirkland: I've been playing around with libvirt+kvm
<SuperQ> kirkland: One "bug" I found was that ubuntu-server installs don't pick up the acpi power button event by default
<SuperQ> kirkland: so when I tell libvirt "shutdown FOO" it doesn't go into init 0
<mathiaz> SuperQ: right - install acpid in the guest and the shutdown command will work correclty.
<SuperQ> kirkland: Lenny default minimal install includes acpid, which supports the event
<SuperQ> mathiaz: Yes, I found this out
<SuperQ> mathiaz: I'm arguing for the case that acpid (or powerbutton events) should be include with ubuntu-standard
<SuperQ> (Debian does this, I figure why not Ubuntu as well)
<slangasek> mm, acpid isn't "standard" on Debian; I'm not sure what would be pulling it in by default
<cjwatson> debian-installer/packages/hw-detect/hw-detect.sh:526:   apt-install acpid || true
<slangasek> ah
<cjwatson> conditional on existence of /proc/acpi
<cjwatson> actually, that code is there in Ubuntu as well!
<cjwatson> don't suppose somebody who knows about this could go and fix it up? lp:~ubuntu-core-dev/hw-detect/ubuntu
<mathiaz> SuperQ: how do you install your guests? Do you enable acpi support in libvirt?
<mathiaz> SuperQ: if you start an install with a guest that has acpi support, acpid will automatically be installed.
<slangasek> was it there in intrepid?
<mathiaz> I think so.
<SuperQ> mathiaz: virt-install python script
<mathiaz> kees: so I've able to reproduce the openldap issue - one test fails when pie is enabled while it passes when slapd is not compiled with the hardening flags
<mathiaz> kees: how should I proceed now?
<mathiaz> SuperQ: so you're not using the installer?
<SuperQ> mathiaz: I spawn a VM with the ubuntu server ISO as a boot device
<SuperQ> mathiaz: Then I go through a normal alternate menu install
<slangasek> mathiaz: anything suspicious in the compile-time warnings?
<SuperQ> mathiaz: acpi is True
<SuperQ> mathiaz: so it should be on when the VM starts up
<kees> mathiaz: open an upstream bug report?
<kees> anyone know the pythonic form of    blah ? "true" : "false"   ?
<mathiaz> slangasek: http://people.ubuntu.com/~mathiaz/trans.1
<SuperQ> cjwatson: I don't think the ubuntu version of that is working
<SuperQ> cjwatson: Atleast in hardy
<mathiaz> slangasek: ^^ this grep translu from the build log
<mathiaz> kees: I guess that's the next step. However I'd like to include the compilation flags
 * kees nods
<mathiaz> kees: reading through the build logs doesn't help me
<SuperQ> Ugh, late for a meeting
<slangasek> mathiaz: what about grepping 'warning', and filtering out those stupid 'too many arguments for format' warnings that I haven't been able to get rid of (grr)?
<kees> mathiaz: -fPIE -pie
<mathiaz> slangasek: http://paste.ubuntu.com/126966/
<slangasek> kees: blah and "true" or "false"
<kees> slangasek: oh.  heh.
<mathiaz> kees: should these be in the build logs?
<slangasek> mathiaz: I meant over the whole log, without first filtering for translucent :)
<mathiaz> kees: because I don't see any PIE/pie in the build logs
<slangasek> mathiaz: but is this just the build log on LP?
<kees> mathiaz: no, they're forced under the hood
<mathiaz> slangasek: it's a local sbuild log
<mathiaz> kees: ok thanks.
<slangasek> mathiaz: ok
<kees> mathiaz: if you want to see the final output, set export DEB_BUILD_HARDENING_DEBUG=1 in the rules dfile
<kees> mathiaz: that'll spew the actual gcc command line that hardening-wrapper is generating.
<cjwatson> SuperQ: probably because acpid isn't on the server CD
<cjwatson> SuperQ: I bet it'd work for netboot installs
<mathiaz> slangasek: http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744 <- 1MB build log of a local sbuild
<slangasek> kees: wait, so PIE is being forced on now for all packages?  Does that mean I can drop that bit of delta on the samba package?
<kees> slangasek: no, PIE is enabled via native upstream mechanisms in samba.  for openldap (and most other PIE builds) PIE is enabled via the use of the hardening-wrapper package.
<SuperQ> cjwatson: Ahhh, that would make sense
<slangasek> kees: so the hardening-wrapper package doesn't do anything to builds by default...?
<SuperQ> cjwatson: hrm, no, my VM installs do have network access
<slangasek> (the 'native upstream' method in Samba isn't particularly interesting, it just adds stuff to the compiler flags AFAIK)
<kees> slangasek: correct, it must be enabled with an environment variable in the rules file
<slangasek> ah
<cjwatson> SuperQ: it's a property of the installation method, not of whether the VM had network access during installation
<SuperQ> cjwatson: ok
<cjwatson> SuperQ: the installer deliberately only uses packages on the CD at certain points, for CD installs
<kees> slangasek: right, but doing PIE builds tends to be non-trivial, so it's nice to have native upstream support.
<SuperQ> so it's just a matter of getting the extra deb(s) on the CD
<cjwatson> well, only if that's appropriate
<kees> slangasek: i.e. you can't just arbitrarily add -fPIE -pie to CFLAGS and everything works out.  :)
<cjwatson> the seed change would take care of that automatically
<SuperQ> <- thinks so
<cjwatson> right, but there seems to be some debate on the subject
<slangasek> kees: are we also carrying gdb patches related to PIE?  I would enable PIE in Debian then, except the last time I tried to debug a Samba bug that showed up in Ubuntu but not in Debian, my backtraces with the Debian gdb went all to crap
<cjwatson> ... which I don't really want to have to get involved in :)
<SuperQ> hehe
<SuperQ> well, I'm perfectly willing to get involved
<slangasek> mathiaz: heh, there are some very nice hardened warnings in there that we should take a look at some time :/
<mathiaz> slangasek: yes. I'm building a package with DEB_BUILD_HARDENING_DEBUG=1 and plan to file a bug with upstream about pie.
<mathiaz> slangasek: upstream may be interested at fixing the other issues brough up by the hardening wrappers.
 * slangasek nods
<slangasek> really nothing that looks like it's related to your bug, though
<kees> slangasek: Debian's gdb is not carrying the PIE patches.  Ubuntu's is.
<slangasek> kees: right.  upstream and/or Debian prognosis for those patches?
<kees> slangasek: Debian's gdb maintainer does not want the PIE patches because they are semi-crack.
<slangasek> ... it's gdb
<slangasek> how can you tell the difference
<kees> slangasek: upstream gdb wants the functionality, but doesn't have time to fix up the patch that Ubuntu, RH, and SuSE carry around for PIE.
<slangasek> anyway, I'll defer to Dan's judgement there :)
<kees> yeah
<jdong> kees: is there a non-crackful way to generate an on-the-fly apparmor profile for executing a single process under, like sandbox-exec() on OS X?
<jdong> haha even re-reading the idea sounds like crack :)
<kees> jdong: I don't know OSX, but the best I've done for on-the-fly AA profiling is just to use aa-genprof -- run it in "complain" mode until it's done, and then end the genprof run, and it flips to "enforce"
<test> in Ubuntu 9.04 for testing we removed eth0, now we are unable to add it back
<test> and get an error "Adding connection failed: PolicyKit authorization could not be created"
<test> any help ?
<test> bdmurray, ping
<test> is this a known issue ?
<jdong> kees: well I'm working on a crazy easily verifiable middleman for breaking out of the Apparmor confines of Firefox (i.e. to open a download in OpenOffice, for example) and would like to provide an option for "Open with constrained system access" which would launch the helper app with a limited set of privs plus access to the downloaded files
<sbeattie> jdong: I've not used sandbox-exec() either, but I'm guessing it's using the systrace tools interactively. That's been a wishlist goal for apparmor for a long time.
<jdong> kees: and I guess I just wanted a way to inject an apparmor profile for one binary without having to apply it system-wide or put it in apparmor.d
<jdong> sandbox-exec basically would be like "apparmor-run some_profile /usr/bin/foo ...."
<jdong> where it would temporarily attach some_profile to foo
<kees> jdong: well, you need to be root to add a profile, and the profile is tied to the application across all runs, so I'm not sure what you want exists.
<jdong> kees: ah, I guess "it doesn't exist" would be an acceptable answer then.
<jdong> it would be nice if available :)
<kees> jdong: yeah, sorry about that.
<sbeattie> test: I suspect it may be related to bug 312105
<ubottu> Launchpad bug 312105 in network-manager "[jaunty] Cannot change eth0 properties (greyed out)" [Undecided,Incomplete] https://launchpad.net/bugs/312105
<jdong> I mean I could always hack something up with (ugh) temp file juggling.
<jdong> just trying to work on a solution for the #1 nag with my Firefox AA profile, opening downloaded files.
<jdong> having apps launch with Ux arbitrary is obviously not gonna work, having them launch with Px requires a lot of work on my part, ix puts on too tough restrictions for say starting up openoffice.org ;-)
<jdong> so my current compromise solution is to have a simple GTK middleman that can be Ux'ed with minimal risk.
<test> sbeattie, not sure
<sbeattie> jdong: in intrepid's apparmor, you can have an "inner" profile that only applies to a program when invoked from from the surrounding profile.
<jdong> sbeattie: I guess what I need is to be able to dynamically supplement/substitute that based on a template of an app the user wants to execute
<jdong> but meh it already sounds like more trouble than it would be worth :)
<jdong> I'll just stay with unconfined-executes once it gets to the middleman level
<jdong> it's the user's (read: my) responsiblity at that point to not be an idiot ;-)
<mathiaz> kees: hm - using export DEB_BUILD_HARDENING_DEBUG=1 makes the build fail in a completely different places
<mathiaz> *place*
<kees> mathiaz: yeah, it's not perfect, some build systems are very sensitive to stderr output
<kees> mathiaz: basically, everything building .o's has -fPIE added, and everything building executables has -pie added
<mathiaz> kees: ok - thanks. I'll file a bug with upstream and attach the failed build log (but not the hardened_debug =1 one)
<sbeattie> jdong: well, it's an interesting problem to solve, IMO. Though I'm not quite sure what solution you're envisioning... feel free to take it to email, if you'd like.
#ubuntu-devel 2009-03-06
<calc> doko: do you know if it there would be any sort of problem with downgrading libxalan2-java to 2.7.0, I don't know how java libraries work wrt needing recompiling apps using them etc?
<calc> anyone here that can do a sync request?
<calc> i need lp-solve and suitesparse synced from debian unstable
<StevenK> Are they new upstream versions?
<calc> the hacks i did for them in january have been accepted and integrated properly
<calc> no, just new debian updates
<james_w> given that I couldn't be sure what day it is or what country I am in, I will have to say no :-)
<calc> the ubuntu patches are no longer needed
<StevenK> If they have Ubuntu changes, file bugs
<calc> ok will do
<slangasek> james_w: Katilsday in Uruguay
<james_w> could be
<james_w> oh, just been told I've got to change countries again
<calc> https://edge.launchpad.net/bugs/338571 https://edge.launchpad.net/bugs/338572
<ubottu> Ubuntu bug 338571 in suitesparse "Sync suitesparse 1:3.2.0-4 (main) from Debian unstable (main)." [Wishlist,Confirmed]
<slangasek> james_w: have fun in Mauritania!
<calc> StevenK: ^
<james_w> slangasek: thanks :-)
<calc> StevenK: will you be able to get to sync those two packages?
 * calc needs them for his OOo build in the morning
 * calc installed the debian version for his local build and will upload in the morning once its tested
<StevenK> calc: I guess suitesparse needs to be published before lp-solve is synced?
<calc> StevenK: let me see, if it build depends on the right version it can be synced at the same time
<calc> StevenK: it build depends on suitesparse 1:3.2.0-2 which isn't in ubuntu yet so it can be synced at the same time or later either way will work fine
<StevenK> calc: Both done.
<calc> thanks :-)
<calc> now hopefully my build doesn't mysteriously blow up while i am asleep and i can upload in the morning :)
<calc> then back to beating on OOo gvfs support to see i can fix it in time for release
<dholbach> good morning
<highvoltage> good mornign dholbach
<dholbach> hiya highvoltage
<bryce> hi dholbach
<dholbach> hiya bryce, hi ara, hi iulian!
<ara> hey dholbach :) welcome back :)
<dholbach> yoooho
<iulian> Hello dholbach.
<Hobbsee> evening dholbach
<dholbach> hey Hobbsee
<bryce> heya Hobbsee
<dholbach> morning doko - what do you think about bug 330613?
<ubottu> Launchpad bug 330613 in python3-defaults "python3-minimal should not have 'Essential' set to yes" [Undecided,New] https://launchpad.net/bugs/330613
<doko> dholbach: yes, on my list ...
<dholbach> doko: super, danke!
<pitti> Good morning
<persia> jdstrand, When you get a chance, could you look at accepting syslinux into hardy-proposed?
<persia> jdstrand, OOps.  Ignore that.  It's been too long since I did an SRU.
<persia> Good morning pitti
<pitti> hey persia, how are you?
<persia> Reasonably well, although it's a dark and rainy day.  You?
 * StevenK kicks his clock applet for no longer updating the weather
<pitti> StevenK: no, it's indeed as bad as it says!
<StevenK> pitti: It doesn't show the weather for any of the cites I have set as locations ...
<primes2h> StevenK: There are also other problems relating to libgweather... bug 334377
<ubottu> Launchpad bug 334377 in libmbca "Lots of country names are missing, showing "missing from libgweather" in mobile broadband connection wizard." [Undecided,Invalid] https://launchpad.net/bugs/334377
<StevenK> My machine has been logged in for 11 days, I guess libgweather got freaked out about ... 3 days ago?
<savvas> Mirv: the patch for bug 102773 is already merged :)
<ubottu> Launchpad bug 102773 in software-properties "l10n broken in the KDE frontend" [Medium,Fix committed] https://launchpad.net/bugs/102773
<Mirv> savvas: oh, right, I visited the bzr page very quickly but apparently missed it :) great, anyway
<savvas> ok:)
<dholbach> Keybuk: it seems that using libdb-dev (db4.7) in cyrus-sasl2 makes it crash all over the place - bug 323409 requests changing it back to db4.6 - WDYT?
<ubottu> Launchpad bug 323409 in cyrus-sasl2 "sasl2-bin broken, segfaulting during install" [High,Triaged] https://launchpad.net/bugs/323409
 * Mirv is starting to see hope at https://wiki.ubuntu.com/TranslatingUbuntu/JauntyTranslationIssues
<dholbach> Keybuk: just confirmed that it fixes things for me again
<seb128> does anybody has an idea about the build error on http://launchpadlibrarian.net/23540712/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu2_FAILEDTOBUILD.txt.gz?
<seb128> "shift: 2353: can't shift that many"
<seb128> it does that in the po directory on the buildds but built fine locally
<directhex> i hate site-specific issues like that
<cjwatson> bdmurray: how often does http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html update? seems to have been static since I first looked at it yesterday
<pitti> Keybuk: hm, I'm pulling out my hair in bug 333903; it seems that even if you blacklist a module in modprobe.d/, it still gets autoloaded; any idea what that could be? I checked the udev rules, and all its modprobe calls use -b
<ubottu> Launchpad bug 333903 in jockey "jockey fails to enable broadcom STA driver" [Undecided,Incomplete] https://launchpad.net/bugs/333903
<lool> pitti: Hey, not sure why you moved the apport traceback to germinate
<lool> pitti: Usually apport doesn't report anything when another program generates an exception
<pitti> doko: should ubuntu-restricted-extras really still pull in sun-java6-plugin, and thus the sun-java6 JDK? Or should we drop that and replace with icedtea6-plugin ?
<lool> pitti: I don't see why I should get an exception on the console from apport in any case
<pitti> lool: well, it's an exception from germinate, which should appear on the console?
<cjwatson> seb128: hmm, complete mystery to me too, I can't even find what *might* be generating it by 'grep -r shift. .'
<lool> In fact we should not ever see exceptions on console, unless it's a report of an internal error which has to be fixde
<lool> pitti: It's not, there's an exception from germinate and then an exception from apport
<lool> In handling that exception
<lool> At least that's my understanding
<pitti> lool: if you want apport to suppress its exception about the file already existing, I can do that
<lool> pitti: I think you should; it shouldn't be an exception in apport in any case
<lool> (I mean it shouldn't reach the console)
<pitti> lool: okay; what was the bug# again?
<lool> I don't mind if you print a message, albeit I would do exactly the same thing as for the first exception (nothing)
<doko> pitti: hmm, difficult question; now with sun-java 6u12, there are features again, which are not found in the icedtea plugin. but maybe we should just drop it for now
<cjwatson> the exception from germinate is basically "debootstrap failed" and has been dealt with separately (by printing its stderr too)
<lool> pitti: bug #323714
<ubottu> Launchpad bug 323714 in germinate "OSError: [Errno 17] File exists: '/var/crash/_usr_lib_germinate_update-metapackage.py.1000.crash' " [Undecided,New] https://launchpad.net/bugs/323714
<pitti> lool: okay, thanks; I'll add an apport task
<cjwatson> maybe it should print an error and sys.exit(1) rather than raising an exception though
<lool> pitti: the exception in germinate is fixed
<lool> cjwatson: ah right, that might be nice too
<lool> pitti: Ok let's keep the germiante task
<pitti> doko: do you think that by and large, the icedtea6-plugin will work?
<lool> thanks folks
<pitti> asac: if a user visits a webpage with a java applet, is there some magic to auto-install icedtea6-plugin, like for flash?
<doko> pitti: 6u12 was released half a year ago. Now applets appear using these new features. I really don't know ...
<seb128> cjwatson: ok, thanks for having a look anyway
<seb128> lool: any idea about http://launchpadlibrarian.net/23540712/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu2_FAILEDTOBUILD.txt.gz maybe? you usually have good idea about weird toolchain issues ;-)
<pitti> doko: ok, thanks; I'll check with asac whether we have a working plugin installer in firefox
<cjwatson> seb128: is it possible that it varies with /bin/sh -> bash vs. dash?
<seb128> cjwatson: sh is dash here, do we use bash on buildds?
<pitti> seb128: I fixed the amd64 retracer, FYI (or, rather, the bug which it stumbled upon
<seb128> pitti: ok, thanks, I pinged you about that on #ubuntu-desktop when I joined but you probably didn't notice
<pitti> seb128: whoops
<seb128> pitti: your IRC client clearly needs to be ported to the message indicator system so you know about unread pings ;-)
<pitti> hehe
<cjwatson> seb128: I think it has been known to be bash on buildds, so while I don't know for sure, it's worth checking
<seb128> cjwatson: ok thanks, I will give it a try now
<lool> seb128: That's probably the same bug
<lool> seb128: config.status being run by /bin/sh instead of @SHELL@
<seb128> lool: the one you fixed for glib and gtk?
<lool> seb128: Yes, and it's fixed upstream in intltool and gettext too
<seb128> lool: ok, I knew that was ringing a bell somewhere ;-) how did you fix it?
<pitti> asac: nevermind, figured it out; discussing on the bug
<lool> seb128: Try changing the $(SHELL) before config.status in Makefile.in.in to @SHELL@
<lool> seb128: Or rather, add SHELL = @SHELL@ to po/Makefile.in.in, that's what the GNOME guys preferred
<lool> seb128: it will be fixed when the tarball is rerolled with a new intltool/glib-gettext
<seb128> $ grep SHELL po/*
<seb128> po/Makefile.in.in:SHELL = /bin/sh
<seb128> po/Makefile.in.in:	       $(SHELL) ./config.status
<seb128> ok
<seb128> lool: thanks!
<lool> Yeah, you want @SHELL@ instead
<seb128> we should ask dobey to roll a new intool tarball
<lool> Please do
<seb128> so that get fixed in 2.26
<cjwatson> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=df8857c0472c33bd786a967569c4b3c9c4c177b2
<cjwatson> FWIW
<lool> cjwatson: Yes, but not released yet; I patched our package
<cjwatson> right, I just figured I'd gone and looked for that so might as well give the URL :)
<cjwatson> thanks for backporting it
<lool> cjwatson: thanks, it's linked from the bug report too already
<seb128> bug #332840
<ubottu> Launchpad bug 332840 in gnulib "$(SHELL) config.status broken" [Undecided,In progress] https://launchpad.net/bugs/332840
<lool> I don't intend to fix gnulib, I don't think it's used that much for Makefile.in.in
<lool> It will be fixed upstream by the same guy
<persia> doko, I've uploaded the last change required to not have anything not otherwise scheduled for removal depend on sun-java5-jre or build-depend(-indep) on sun-java5-jdk.  Do you have any concerns about final removal?
<seb128> lool: http://launchpadlibrarian.net/23542187/buildlog_ubuntu-jaunty-i386.gnome-control-center_1%3A2.25.92-0ubuntu3_FULLYBUILT.txt.gz
<seb128> lool: thanks ;-)
<doko> persia: yes, make first sure, that the current package is available in dapper, hardy and intrepid
<persia> doko, So you want 1.5.0-17 backported into -proposed for everything first?
<doko> persia: well, sru's require to have the new version in the development version
<persia> That makes it complicated.  We don't want to include it because Sun stops offering support before even intrepid expires, but what if Sun releases a new version between now and their end-of-support?
<cjwatson> if the package doesn't exist any more in jaunty, I would regard that as justification for an exception from the "must be in jaunty first" SRU rule, personally
<cjwatson> it's there so that we get the maximum testing possible before inflicting on stable users
<quadrispro> hi pitti, gegl FTBFS cause of libopenraw-dev is in universe and there are 2 ways to solve that
<persia> OK.  I'll proceed with the plan to drop it from jaunty on that basis, in case there is a future 1.5.0-18, but not request removal until the current updates are complete.
<quadrispro> 1) file a MIR 2) build the package without libopenraw-dev build-dep (which is unnecessary)
<pitti> cjwatson: I wonder what to do with bug 328486; a beta-blocking milestoned wishlist bug, without an assignee..
<ubottu> Launchpad bug 328486 in apturl "automatically add keys when whitelisted for apturl" [Wishlist,New] https://launchpad.net/bugs/328486
<pitti> cjwatson: From my POV I'd just un-milestone/un-target for jaunty; or did you discuss this with someone who wants to work on this soon?
<quadrispro> pitti, what do you think about it? what solution could be better?
<cjwatson> pitti: I discussed it with mvo before filing it
<cjwatson> 11:55 <cjwatson> just thinking about jaunty-apturl-add-repo in the context of some previous discussions, and an e-mail thread with Mark today
<cjwatson> 11:56 <cjwatson> would it make sense for the keys that are whitelisted according to the partner-repositories specification also to be available if you add repositories in Software Sources?
<cjwatson> 11:57 <cjwatson> i.e. if apturl is willing to add the signing key automatically, then it seems to make sense for it to be added automatically if you add the corresponding repository by hand, too
<cjwatson> 11:58 <mvo> sounds sensible indeed
<cjwatson> 12:01 <cjwatson> should I file a bug?
<cjwatson> from 12 Feb
<cjwatson> 12:03 <mvo> I can do that too, no problem (and milestone it)
<cjwatson> I'll just assign it to mvo now
<pitti> cjwatson: ok, assigning to mvo then
<lool> seb128: cool
<pitti> quadrispro: if libopenraw-dev isn't really needed, then dropping the b-dep is always better
<pitti> quadrispro: if libopenraw-dev provides features which were previously in gimp as well, or are otherwise important, then a MIR sounds better (but keep in mind that we are in feature freeze)
<Mirv> seb128: do you think the gnome.mk cdbs could be used also for libmbca? but thanks for that one fix, it could be solving some other problem(s) as well
<seb128> Mirv: dunno about libmbca, gnome.mk is for desktop packages usually and the pidgin-libnotify was already using cdbs
<Mirv> seb128: dunno either, but libmbca is also using cdbs and having the same problem, so I wonder if there is any other besides gnome.mk that could fix the similar problem there
<seb128> Mirv: well the issue is simple something needs to call intltool-update, cdbs gnome.mk does that for us but it can also be called manually in the rules
<quadrispro> thank you pitti, I'm going to do some tests
<Mirv> seb128: ok.
<lool> Wow valgrind is 45 MB
<lool> 47M     /usr/lib/valgrind/x86-linux
<pitti> james_w: do you still have enough context of bug 275432 in your head to be able to work on this? Or would you rather not? (then I'll see to make some time to look into it)
<ubottu> Launchpad bug 275432 in policykit "libpolkit requires files from policykit for polkit_context_init to work" [High,Confirmed] https://launchpad.net/bugs/275432
<pitti> james_w: it's a jaunty-targetted bug, so it should have an assignee
<cjwatson> oh, this is going to be unpleasant. Apparently at one point openssl had an rpath pointing to /usr/lib
<cjwatson> I think I'm going to have to leave symlinks behind
<lool> cjwatson: On a TI EVM board running jaunty armel and otherwise idle: # time /etc/init.d/console-setup start => real    0m27.171s, user    0m26.281s
<lool> cjwatson: That sounds terribly long
<cjwatson> did it have a saved keymap previously?
<lool> It's subsecond on my desktop
<lool> cjwatson: It's the second run
<cjwatson> was the first run in the boot sequence?
<lool> cjwatson: No
<lool> cjwatson: I noticed slowness during upgrade, then reproduced manually on the running system
<cjwatson> would be useful to know which bit of setupcon is taking lots of time
<lool> cjwatson: On a FSL Babbage, also jaunty armel but might be a different keymap, it's real    0m5.121s
<lool> cjwatson: Could it be using lots of rAM?
<lool> I only have 128M on the EVM
<cjwatson> well, if it has the keymap files cached, the particular keymap in use should make no difference
<cjwatson> lool: I don't want to speculate too much without knowing which bit of setupcon is taking ages
<cjwatson> lool: it's a shell script - you could sh -x it
<lool> I'm doing that
<lool> setupcon --force --save
<lool> That's what hangs for long
<cjwatson> now sh -x *that*
<cjwatson> setupcon does quite a few different things
<lool> + ckbcomp -model pc105 us
<lool> + gzip -9
<cjwatson> can I have the bit before that with the tests?
<cjwatson> from just after setting rules_option
<lool> cjwatson: http://paste.ubuntu.com/127152/
<cjwatson> you have a /root/.console-setup file
<cjwatson> any particular reason?
<lool> time (ckbcomp -model pc105 us | gzip -9 >/dev/null) => 0m25.938s
<lool> cjwatson: I don't
<cjwatson> when you have that file, it assumes that you're using a per-user (well, root, but still not the one in /etc) configuration and therefore that it shouldn't use the cached keymap
<lool> cjwatson: http://paste.ubuntu.com/
<cjwatson> this was in response to bug 332728
<lool> cjwatson: kernel is hand built though
<ubottu> Launchpad bug 332728 in console-setup "uses cached keymap even when reading a user configuration file" [Undecided,Fix released] https://launchpad.net/bugs/332728
<cjwatson> lool: ... I think you forgot the last bit in that URL ;-)
<lool> Hmm?
<lool> cjwatson: sorry didn't understand
<lool> cjwatson: Note: no initramfs
<lool> Probably what causes the difference
<lool> without -9 doesn't change anything
<lool> cjwatson: ooohhh sorry
<lool> cjwatson: http://paste.ubuntu.com/127156/
<cjwatson> lool: sorry, the last I have is:
<cjwatson> 11:12 <lool> cjwatson: http://paste.ubuntu.com/
<lool> 12:16 < lool> cjwatson: ooohhh sorry
<cjwatson> 11:12 <cjwatson> this was in response to bug 332728
<lool> 12:16 < lool> cjwatson: http://paste.ubuntu.com/127156/
<ubottu> Launchpad bug 332728 in console-setup "uses cached keymap even when reading a user configuration file" [Undecided,Fix released] https://launchpad.net/bugs/332728
<cjwatson> 11:12 <cjwatson> lool: ... I think you forgot the last bit in that URL ;-)
<lool> cjwatson: I don't have the /root/.console-setup
<lool> cjwatson: And I don't have an initramfs
<lool> and without -9 makes no difference
<cjwatson> apparently I can't read
<cjwatson> lool: ok, can you please file a bug and assign it to me? --save probably shouldn't bother updating the cached keymap when it's already up-to-date
<cjwatson> lool: this shouldn't affect the boot sequence, though
<cjwatson> lool: when running in the boot sequence, --save isn't used
<lool> Ok
<cjwatson> lool: assuming, that is, that the run_by_init function in /etc/init.d/console-setup still works
<cjwatson> lool: oh, actually, maybe don't file a bug
<cjwatson> lool: your issue is during upgrade, yes?
<cjwatson> lool: in that case, it's perfectly conceivable that stuff may have changed such that the keymap *does* need to be regenerated
<lool> cjwatson: It was during upgrade yes
<lool> cjwatson: Will it affect first boot?
<cjwatson> no, it won't
<cjwatson> it's interesting that it's so slow though
<lool> cjwatson: Ok, so it's normal that it takes so long on console-setup upgrades?
<lool> Right, I find that really slow
<cjwatson> ckbcomp only uses maybe 5MB of memory tops
<cjwatson> $ time ckbcomp -model pc105 us '' '' >/dev/null
<cjwatson> real    0m0.618s
<lool> time (ckbcomp -model pc105 us >/dev/null) => 0m26.826s
<cjwatson> lool: is it possible that 'use integer;' near the top of ckbcomp would speed it up?
<lool> I don't see any faults in /proc/cpu/alignment
<cjwatson> I don't think it needs FP math
<lool> That's likely, trying
<lool> 0m25.583s
<lool> no
<cjwatson> might be worth trying it with -v 10 and seeing what's taking time
<cjwatson> oh, hmm, -v 10 actually not that informative
<cjwatson> verbose perl debugging will probably slow the whole thing down to the point of making it hard to tell
<cjwatson> maybe just print debugging at appropriate points?
<lool> Ok
<cjwatson> I don't have any other obvious bright ideas :-(
<lool> cjwatson: time is spent on iterations of this loop foreach my $key (sort {$a <=> $b} (keys %symbols_table)) {
<cjwatson> lool: would be useful to know how many elements %symbols_table has, and the same recursively for its elements
<cjwatson> the actual work done in the inner loop is trivial
<cjwatson> if the hash lookups are taking ages then we could arrange to do that just once
<lool> cjwatson: flatten() is the one taking most time
<cjwatson> lool: flatten() isn't in the loop you mentioned ...
<cjwatson> oh, you're talking about a different loop than I'm looking at
 * cjwatson starts again
<cjwatson> lool: the Devel::DProf module might help here
<cjwatson> 'perl -d:DProf /usr/bin/ckbcomp -model pc105 us >/dev/null' will produce tmon.out and dprofpp can analyse that
<persia> pitti, When you get a chance, could you look at bug #309396?  There's some interest in getting it into -proposed before the Alpha Freeze.
<ubottu> Launchpad bug 309396 in syslinux "Ubuntu UMPC boot menu is truncated" [Medium,In progress] https://launchpad.net/bugs/309396
<pitti> persia: okay, will have a look today
<persia> pitti, Thanks.
<pitti> persia: did you upload it already?
<persia> via sponsorship, yes.
<StevenK> pitti: I uploaded it, which is why I'm not looking at it
<persia> StevenK, I thought you weren't looking at it because you weren't ubuntu-sru
<pitti> ah, good
<StevenK> persia: Shhh
<directhex> ta seb128
<seb128> directhex: you're welcome
<seb128> directhex: there was a sync where I asked if there was something other than cosmetic change the other day, did you close it after that?
<directhex> seb128, no, i replied & said the exisiting archive version would ftbfs due to transition
<directhex> seb128, so it's that or ubuntu1
<seb128> didrocks: you didn't reopen when replying because it's not on the sponsoring list
<directhex> damn. incomplete
<directhex> i suck
<directhex> New again?
<seb128> yes
<seb128> bug number?
<directhex> bug 337634
<ubottu> Launchpad bug 337634 in gnome-keyring-sharp "Please sync gnome-keyring-sharp 1.0.0~svn.r87622-2 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/337634
<seb128> directhex: synced, don't forget to reopen next time
<directhex> yeah, my mistake.
<directhex> i wonder what time i replied...
<directhex> 20 past 10, can't even blame tiredness. bah
<Keybuk> dholbach: probably correct
<Keybuk> pitti: blacklist only prevents then named modules from appearing in alias expansion
<Keybuk> pitti: it doesn't actually stop anyone doing "modprobe foo"
<pitti> DktrKranz, ScottK, sistpoty|work, Hobbsee: with your motu-release hat on, any objection against me updating devicekit-power to the latest upstream version? it has zero reverse dependencies, but I'd like to package the new g-p-m into a PPA for playing; it adds two small new features
<Keybuk> There must be something wrong with the /etc/modprobe.d/blacklist-bcm43.
<Keybuk> pitti: that should be blacklist-bcm43.conf btw ;)
<pitti> Keybuk: right, but the udev rules all use -b, which should respect the blacklist?
<pitti> Keybuk: oh, you mean it only considers files ending in .conf now?
<pitti> Keybuk: that might be the very bug I'm looking for then
<Keybuk> # load wl before b44 so that both work
<Keybuk> install wl modprobe -r b43 b44 b43legacy ssb; modprobe --ignore-install wl $CMDLINE_OPTS; modprobe -Qba b44
<Keybuk> the comment is exactly the opposite of what you're actually doing ;)
<Keybuk> you probably want an && in there too
<Keybuk> and -Q has gone, so you don't want that
<Keybuk> (and you don't want -a either)
<pitti> Keybuk: is .conf required now, or just "best practice"?
<Keybuk> pitti: required
<pitti> oh
<Keybuk> it's not fully deprecated yet, but EVERY SINGLE modprobe invocation will bitch about it
<Keybuk> that's not your bug though
<Keybuk> I'm just going down the list :p
<pitti> Keybuk: almost all files in modprobe.d/ violate that then
<pitti> okay
<Keybuk> pitti: actually, if you look at -changes, I fixed almost all of them yesterday
<Keybuk> the only ones left are those that come with module-init-tools itself
<cjwatson> this is breakage for the sake of breakage from m-i-t upstream, right? :)
<Keybuk> and those created by programs
<cjwatson> the only justification I can think of is things like .dpkg-tmp
<cjwatson> which would be addressed by just saying that your filename can't contain a dot
<Keybuk> cjwatson: no, there's enormous numbers of bugs of people's swap files being treated as module aliases, etc.
<pitti> like .dpkg-old or so?
<Keybuk> that doesn't help with /etc/modprobe.d/4913 which vi likes to create <g>
<cjwatson> the run-parts rules deal with that perfectly well, and much less intrusively
<Keybuk> cjwatson: I don't think I agree anymore
<Keybuk> after having tried to maintain the same thing with Upstart
<Keybuk> that's shifting to .conf too
<Keybuk> there's just too many damned stupid file rules to ignore nowadays
<cjwatson> and so the world gets gradually worse :-/
<Keybuk> why worse?
<cjwatson> upgrade pain on a stick; I expect lots of people to have local modprobe.d files
<Keybuk> it'll pass
<cjwatson> just because it was too hard to DTRT
<cjwatson> upgrade pain is cumulative, and everybody keeps adding their own little bit to the pile
<cjwatson> upgrade problems are something we get hammered about by users
<Keybuk> anyway
<Keybuk> bitching aside
<Keybuk> back to the bug
<Keybuk> pitti: I can't quite see what's going in the description
<cjwatson> I'm sorry that you feel that raising a design concern is bitching :P
<pitti> Keybuk: my main headache is that modules get auto-loaded despite being blacklisted
<Keybuk> cjwatson: it's bitching because you're doing it to me, and not upstream
<pitti> Keybuk: this obviously worked in intrepid, so I wonder what changed
<cjwatson> as usual, we raise bug reports through distro maintainers
<cjwatson> I can do it as a bug report if you'd rather, but from this conversation it sounds like you'd just close it
<Keybuk> cjwatson: I happen to agree with the upstream in this case ;)
<Keybuk> having tried to maintain a "filter out known filename patterns" list, it's just too damned hard
<Keybuk> especially if you're doing it in a piece of software that can run at any time
<Keybuk> so you need to deal with transient things like vi's silly "can I write to this directory?" files
<cjwatson> upstart doesn't really worry me much because it's new and not many people are going to have written jobs files for it
<Keybuk> ANYWAY BACK TO THE BUG
<Keybuk> pitti: hmm
<Keybuk> pitti: bug the bug seems to say that a driver *isn't* being loaded
<Keybuk> or am I reading this all wrong?
<pitti> Keybuk: sec, doorbell
<sistpoty|work> pitti: no objections from me in regards to devicekit-power
<pitti> Keybuk: no, the bug is that wl isn't being loaded because ssb is auto-loaded
<pitti> Keybuk: in intrepid this blacklisted ssb, b43, and b44
<Keybuk> wl is failing to load?
<Keybuk> ie. it tries, and throws it out?
<pitti> Keybuk: thus the modaliases for wl got "unshadowed"
<Keybuk> what do you mean by "unshadowed"?
<pitti> thus wl then got auto-loaded through the udev rules, and the rule made sure that b44 got, too
<pitti> Keybuk: ssb and wl have the same modaliases
<Keybuk> right
<pitti> and apparently ssb won
<Keybuk> so both will be loaded
<Keybuk> whichever is first in depmod.conf/modules.order will win
<Keybuk> if wl is in ubuntu/ it should win
<Keybuk> as long as ssb isn't
<pitti> but if ssb and b43 already grabbed the device, wl didn't find anything to drive
<pitti> so someone came up with that idea of blacklisting ssb/b43/b44 and let wl install b44 alongside
<pitti> which worked fine in intrepid
<pitti> but now, the blacklist seems to get ignored entirely
<pitti> Keybuk: changing the probing order sounds interesting; where is that configured?
<DktrKranz> pitti: is bug 318775 addressed?
<ubottu> Launchpad bug 318775 in devicekit-power "D-Bus Policy needs checking" [Undecided,New] https://launchpad.net/bugs/318775
<Keybuk> pitti: two places
<Keybuk> pitti: /etc/depmod.d/depmod.conf configures the search order of directories
<Keybuk> so it will search updates, then ubuntu, then kernel
<Keybuk> err
<Keybuk> /etc/depmod.d/ubuntu.conf
<Keybuk> sorry
<Keybuk> /lib/modules/$(uname -r)/modules.order specifies the load order in general
<pitti> DktrKranz: it's fixed in devicekit; not sure whether it's needed in devkit-power, I'll look
<DktrKranz> pitti: thanks. Anyway, it looks fine to me
<Keybuk> pitti: is b43legacy being loaded?
<DktrKranz> (and it's not probably motu-release stuff, btw)
<Keybuk> or is b43 itself being loaded?
<pitti> Keybuk: b43 in that case
<Keybuk> b43 deps on ssb
<pitti> DktrKranz: thanks
<pitti> Keybuk: right, that's why all three get blacklisted right now
<asac> pitti: yes. there should be a "missing plugin .." button
<lool> cjwatson: Hmpf dprof isn't packaged, this is getting a bit far for me; if you don't mind I'll document that in a low priority bug report and people who want to do the research are welcome to
<Keybuk> pitti: you don't want the "_" in b43_legacy :p
<Keybuk> b44 would also load ssb
<cjwatson> lool: uh - it's in the perl package
<cjwatson> perl: /usr/lib/perl/5.10.0/Devel/DProf.pm
<pitti> Keybuk: no, I don't think so :) it's called b43legacy
<pitti> Keybuk: hm, /etc/depmod.d/ubuntu.conf doesn't look like something I should modify in apport
<Keybuk> random thought
<Keybuk> WHEN are they being autloaded?
<Keybuk> are these modules being copied into the initramfs?
<pitti> Keybuk: haven't pinpointed that yet with the reporter
<Keybuk> pitti: yes
<Keybuk> ssb is in my initramfs
<pitti> Keybuk: ah, you think that the blacklist needs to be copied to initramfs?
<Keybuk> pitti: probably
<pitti> aaah
<Keybuk> I'd guess that's the regression - more modules have been copied into the initramfs, but the blacklist isn't being
<pitti> Keybuk: good point, I'll try that
<Keybuk> you prob. just need an update-initramfs
<Keybuk> as I'm pretty sure all files in /etc/modprobe.d are copied across
<pitti> Keybuk: so, the jockey handler does call update-initramfs
<pitti> Keybuk: but i didn't ask the bug reporter to do so after changing it
<lool> cjwatson: Oh ok
<pitti> Keybuk: so it's not the entire explanation, but it might explain the failures in debugging it
<lool> cjwatson: I didn't imagine that for a second
<Keybuk> pitti: to help debug, /var/log/udev would tell us the modaliases on his system
<Keybuk> and get him to try modprobe -n -v on each of the aliases he finds there
<lool> bryce: When you have a sec, please look at #334711
<ScottK> pitti: If you're confortable with it, I'm good.
<pitti> ScottK: ok, thanks
<pitti> Keybuk: you can run modprobe for a modalias?
<pitti> Keybuk: i. e. "sudo modprobe ssb:v4243id0812rev09"?
<pitti> indeed, nice
<lool> cjwatson: http://paste.ubuntu.com/127211/
<cjwatson> lool: could I get the full tmon.out?
<lool> cjwatson: http://people.ubuntu.com/~lool/tmon.out
<lool> cjwatson: That's a really interesting tool BTW
<cjwatson> thanks, got it
<cjwatson> it's not going to be straightforward though :-/
<cjwatson> the biggest user is simply 100000 calls to one subroutine that takes a tiny fraction of a second per call, but it mounts up
<cjwatson> it could be that sub calls are just really slow on arm
<cjwatson> or it could be that the whole algorithm needs to be improved
<lool> cjwatson: Perhaps we could avoid ::approximate?
<lool> 100000 calls seems bad indeed
<cjwatson> nytprof (http://blog.timbunce.org/tag/perl/) looks really amazing but I think I'll work with this first :)
<cjwatson> lool: err. I don't think we can just throw out bits of the algorithm, no. :)
<lool> cjwatson: Sorry, I first thought approximate was some perl function, but I saw it in the source later on
<cjwatson> ah, no, it's part of the xkb symbol resolution stuff
<cjwatson> I admit that I don't actually understand its purpose yet myself
<lool> cjwatson: The next idea I thought of was to convince perl it needs more optimization, perhaps there's some inlining concept in perl?
<cjwatson> but I would start by doing so
<cjwatson> not really, no
<cjwatson> I would rather start by analysing and understanding the problem
<lool> cjwatson: It looks like a many hours job from my side; I hope you don't mind I leave it here
<lool> cjwatson: Happy to assist in testing or benchmarks though
<lool> #338729
<cjwatson> lool: yep, that should be fine, thanks
<Keybuk> pitti: yes, that's _kinda_ the whole point <g>
<dholbach> Keybuk: are you going to sponsor it? :)
<Keybuk> dholbach: what's sponsoring?
<dholbach> Keybuk: right
<Keybuk> dholbach: assign the bug to me
<Keybuk> and I'll do it in my sponsoring hour next week
<dholbach> Keybuk: I think it's more urgent than that - so I'll do it now
<BUGabundo> pitti: ping
<BUGabundo> apport Suggest python-launchpadlib
<pitti> bryce: some speculations for i845: could we resurrect -i810 on those? could we start vesa on those by default
<pitti> BUGabundo: yes?
<BUGabundo> but to use apport-collect its required
<BUGabundo> shouldn't it be recommends?
<BUGabundo> or depends?
<pitti> bryce: just thinking about a fallback strategy if we won't find a proper solution by the release, so that upgrades won't break completely
<pitti> BUGabundo: I'll switch apport over to launchpadlib soon anyway
<pitti> BUGabundo: for now, apport-collect tells you that the package is missing
<pitti> seb128: ah, seems bug 277309 is fixed now; confirm?
<ubottu> Launchpad bug 277309 in gnome-session "[Jaunty] Missing suspend icon" [Low,Confirmed] https://launchpad.net/bugs/277309
<pitti> seb128: (WFM)
<seb128> pitti: no it's not
<seb128> pitti: again that bug is the "suspend icon is only in the human theme"
<seb128> the jaunty issue (no theming) has been fixed
<seb128> pitti: switch to clearlooks, press the power button, notice the "no icon"
<pitti> seb128: ah, but that remaining issue isn't a regression, is it?
<seb128> no it's not
<seb128> it's there since intrepid
<seb128> since we use the new dialog
<pitti> I wonder why it should be a release blocker then
<seb128> it should not?
<pitti> seb128: there's no good counterpart in clearlooks and other themes for the icon?
<seb128> that's you guys who have confused the jaunty issue with this one and have dups and tweaked settings the wrong way
<seb128> pitti: there is no suspend icon, I don't know if one other icon could be a good workaround, should be a question for icon guys ;-)
<seb128> pitti: see bug #274889 for a discussion about the icons used
<ubottu> Launchpad bug 274889 in gnome-session "the new session dialog should use other icon names (dup-of: 277309)" [Low,Incomplete] https://launchpad.net/bugs/274889
<ubottu> Launchpad bug 277309 in gnome-session "[Jaunty] Missing suspend icon" [Low,Confirmed] https://launchpad.net/bugs/277309
<pitti> seb128: ok, thanks for the heads-up
<seb128> pitti: your marked duplicated the wrong way around imho, you closed the bug which had a technical discussion about the issue for a newer one with less details
<pitti> uh, was that me?
<seb128> yes
<pitti> sorry then
<pitti> please feel free to swap them
<seb128> according to the launchpad activity log
<seb128> ok, will do
<BUGabundo1> back
 * BUGabundo1 wonders if ADSL is going to be up for a while
<pitti> asac: bug 323109 is on track for jaunty release, or rather not? (it's not a regression)
<ubottu> Launchpad bug 323109 in firefox-3.0 "network-manager integration: firefox downloads do not honour network-manager online/offline state" [High,Triaged] https://launchpad.net/bugs/323109
<BUGabundo1> pitti: asac told me once that upstream doesn't want us using the integration with NM
<pitti> huh?
<Amaranth> BUGabundo1: we already do though, if NM is not connected firefox goes into offline mode
<BUGabundo1> that should not be like that, according to asac
<BUGabundo1> upstream doesn't seem to want that!
<Keybuk> seb128: randomly
<Keybuk> which is the right package to assign "my USB stick doesn't auto-mount" bugs to?
<Keybuk> I've utterly lost track with which bit of the GNOME stack is responsible
<Keybuk> gvfs or nautilus now?
<asac> pitti: upstream has networkmanager support disabled by default on trunk. so unless we can convince them they wont put much resources in it. it could be an easy fix though. just requires some debugging to find out, what breaks this existing feature when you use NM for offline state. (it works if you dont use NM, but manually iirc)
<asac> so we cannot really say if its on track for jaunty or not as we dont know the cause for the brokenness yet.
<pitti> asac: right, I meant if it *should* be on the jaunty radar, i. e. if you consider it a release blocker
<asac> pitti: its an important bug for the spec, but i dont think its a blocker
<pitti> asac: I agree
<asac> i think the spec is medium itself
<asac> but dont remember exactly
<asac> pitti: but why are not-milestoned targetted bugs bad?
<asac> pitti: i thought it means its an "oppertunity"
<pitti> asac: well, every bug is an opportunity
<asac> hehe
<pitti> asac: if a bug is targeted at jaunty, it means that it's on the release team's radar and should be fixed ASAP
<pitti> it's basically the set of bugs which we consider "release critical" for jaunty
<asac> pitti: so what would you suggest me to use for "my" jaunty radar?
<pitti> asac: personally I assign bugs to me and set them to "in progress"; that's the set of bugs I"m currently working on
<pitti> asac: you can also milestone it for ubuntu-9.04 without targetting it at jaunty
<pitti> if you like that better
<asac> pitti: thats true. but i like to have a in progress list for jaunty
<asac> but well.
<pitti> asac: use the ubuntu-9.04 milestone then
<asac> i wiill misuse importance than to tweak my personal priority
<pitti> milestones on the floating task are for personal use
<asac> ok. i will think abit about it, now that i know that any targetted task are RM
<BUGabundo1> asac: I've changed my FF to use NM, and it fails to set Offline 50% of the times!
<asac> BUGabundo1: well. disable your 70 extensions first ;) ... can you still reproduce then=
<asac> ?
<BUGabundo1> asac: I'll try latter with 3.2
<BUGabundo1> can't take the net off now! connected to server ss
<BUGabundo1> *ssh
<asac> i mean, afaik you run firefox 3.1 dailies with disableextensioncheck and 70 extensions installed out of which 60 claim maxVersion=3.0 :)
<asac> BUGabundo1: try without extensions and not with 3.2 ;)
<BUGabundo1> that would require a new 3.1 profile!
<BUGabundo1> I don't close my FF all that much
<asac> BUGabundo1: no you can use safe-mode
<BUGabundo1> that too
<BUGabundo1> forgot about that
<BUGabundo1> still requires to close FF
<BUGabundo1> asac: will try when I get home
<asac> cool
<BUGabundo1> asac: FYI its only 53 addons.... lol
<seb128> Keybuk: not easy to say without debug info, you can reassign to gvfs, it's often hal which is buggy though
<Keybuk> seb128: indeed, just never sure which bit of the stack to assign it to so that debugging can begin that's not something ridiculous like util-linux
<seb128> Keybuk: gvfs
<seb128> it's likely wrong but I will read those and I know what to ask
<Keybuk> it'd be interesting to see if we can move that stuff to CoreDisksKitStar sooner rather than later ;)
<Keybuk> ie. karmic
<superm1> seb128, reg bug 331818, did I not properly push the upload to bzr, or was it something on your end that didn't get pushed right?  If it was me, i'd just like to make sure i'm aware of it so I dont make a mistake again.
<ubottu> Launchpad bug 331818 in gnome-control-center "Notification window is not translatable " [Low,Fix released] https://launchpad.net/bugs/331818
<seb128> superm1: we moved the bzr to the ubuntu-desktop team I think you pushed to the "old" location
<superm1> seb128, ah yeah this i didn't realize.  i did push to the core-dev branches
<superm1> seb128, did you update the Vcs-Bzr in the debian/control to reflect it too now then?
<seb128> superm1: yes
<seb128> I think that was just a race between change and your upload
<seb128> nothing to worry about really
<superm1> seb128, okay thanks
<thbishop> now that Dell and others are shipping Ubuntu pre-installs and the whole Netbook linux thing is taking off, are these companies dedicating resources to Ubuntu development upstream?
 * directhex hands dholbach a slice of cake
<dholbach> directhex: gracias!
 * directhex really does attempt to show appreciation when people process his crap, he's just not very good at it
<slangasek> doko: I see jflex 1.4.2-1 is unstable now; is that the version we need to sync, or are we waiting for yet another upload?
<pitti> slangasek: the latter
<pitti> slangasek: jaunty and sid have by and large the same version, modulo changelog
<pitti> slangasek: I updated the bug this morning and linked to the debian svn fix
<slangasek> ok
<bdmurray> cjwatson: I've updated and I'm setting up a daily cronjob for it
<cjwatson> bdmurray: cool, thanks
<slangasek> Keybuk: ah, the binary-index modprobe isn't in yet?
<Keybuk> slangasek: not yet
<slangasek> ok. is that the same upstream version that breaks compatibility with /etc/modprobe.d?
<Keybuk> it doesn't break any compatibility
<Keybuk> it does warn if the filenames don't end in ".conf"
<slangasek> ah, right
<slangasek> but we hide that by default at boot so it's ok :)
<cjwatson> dendrobates: should have trimmed off a little under 4MB of your amd64 server CD size now
<dendrobates> cjwatson: great, thanks.
<cjwatson> you have about 11 to go ...
<alex-weej> with notify-osd is it intended that i can only show one bubble per app?
<kees> doko: my local machine can't compile openjdk-6; it eventually dies with:
<kees> Could not reserve enough space for object heap
<kees> but that's because I use a 1G vmem rlimit.
<kees> [pid  1187] mmap(NULL, 2225078272, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
<kees> (this is from "bootstrap/jdk1.6.0/bin/java -version")
<cody-somerville> seb128, search in gedit seems broken. The find button stays deactivated even if you type stuff in.
<ScottK> alex-weej: Try #dx.
<alex-weej> scottK: no topic. what is it?
<ScottK> alex-weej: That's where the Canonical Desktop Experience people who do notify-osd are.
<jdong> does anyone know how crack-ish the freenx stack is these days?
<jdong> I have to look into some low-bandwidth remote desktopping solutions and remember from the ol' days that FreeNX was one of the best in terms of usability
<slangasek> awesome, right-clicking on an event in evolution crashes it
<Simira> a new feature?
<slangasek> the backtrace on the console is very pretty, so I assume so
<slangasek> but maybe I'll file a bug report just in case
<seb128> slangasek: it's fixed in svn
<slangasek> oh, ok :)
<slangasek> the 'BADARG: Bad argument to function' one?
<seb128> slangasek: that's because libical is built to abort on error, I'm pondering unsetting that before jaunty
<seb128> slangasek: bug #331428?
<ubottu> Launchpad bug 331428 in evolution "crash when right clicking on a calendar entry" [Medium,Fix committed] https://launchpad.net/bugs/331428
<seb128> slangasek: I might backport that now in fact because we will not get new tarball before alpha6 and that's an annoying one
<slangasek> seb128: yep, that's the one :)
<tx2650> Hi. How can I tell Intrepid to download the old (2.6.24) Hardy kernel?
<mrooney> tx2650: good question, if you don't get an answer here you could also try #ubuntu-bugs
<tx2650> tnx
<siretart>   
<andresmujica> tx2650:  clean your apt-cache, backup your source.list, then change intrepid with hardy, then update your cache then install the hardy kernel, then recover your original source.list, clean your cache, and update again.  CAREFULLY
<maxb> andresmujica, tx2650: No, don't clean your apt-cache. That is not useful and would just waste download time in the future, potentially
<tx2650> internet connection is not an issue
<maxb> Still needless
<maxb> I'd be tempted to just download the .debs manually rather than messing with apt, if it's just for a kernel
<tx2650> it seems that that would cause many problems. I`m going to backup and reinstall.
<stgraber> seb128: what could cause whatever monitors /media/ not to send a dbus signal ?
<tx2650> just a question: what`s with cpufreq on em64t? No support in Hardy or Intrepid?
<seb128> stgraber: directory are filesystem entries they don't talk dbus
<seb128> stgraber: not sure a dbus signal should be sent there
<stgraber> seb128: dbus-monitor shows a few entry from a vfs service when a mountpoint appears in /media but for some reasons on some of my systems (intrepid/jaunty) nothing happens ...
<seb128> stgraber: no idea about that it's friday evening now and over work hour, will have a look next week
<joinAD> how do we go about adding ubuntu to a active directory domain?   was trying Likewise
<slangasek> likewise does it.
<joinAD> my syntax must be wrong then, or Server08 is not playing nice
<joinAD> sudo domainjoin-cli join syrtime-local ACCOUNT PASS
<Laney> Can someone help debug an FTBFS in miro? Seems to be boost-python related: http://orangesquash.org.uk/~laney/miro_ftbfs.txt
<slangasek> joinAD: I don't recall the syntax off the top of my head, but I've tested it successfully in the past; if #ubuntu holds no answers for you, you might ask on #ubuntu-server
<joinAD> thanks
<sistpoty> Laney: /usr/include/boost/python/detail/wrap_python.hpp (failed) would be the first point to look for, I guess
<sistpoty> Laney: so question is, why boost doesn't find it (it's from there) and if boosts deps are right (in regards to -dev packages)
<Laney> yeah, it seemed fine to me
<sistpoty> Laney: I can't find a failed buildlog in lp... where does it actually fail?
<Laney> sistpoty: It didn't fail when it was uploaded
<Laney> It needs updating for py 2.6, which is when I came across this
<Laney> download the source and try to build and you'll see
<sistpoty> Laney: ok, will try later ;)
<Laney> hmm, this might be because of 2.5/2.6 skew
<Laney> but miro does not work with py 2.6
<sistpoty> Laney: complete guess right now (I'm just going through FFe's and found it): libtorrent-rasterbar has this in changelog: "--with-boost-python=boost_python-mt-py26 flag."
<sistpoty> Laney: so maybe it might be worth a look what libtorrent-rasterbar makes with this flag
<Laney> alright
<sistpoty> Laney: cf. bug #335741
<ubottu> Launchpad bug 335741 in libtorrent-rasterbar "[jaunty]python(<2.6)-based apps cannot meet dependencies" [High,New] https://launchpad.net/bugs/335741
<Laney> I see problems with Boost.Python and forcing 2.5 though
<Laney> ooh
<Laney> that title sounds workable
<Laney> thanks
<superm1> slangasek, i think i may have encountered a bug on cdimage when creating alternate disks.  what project is the appropriate place to file such bugs?
<superm1> (unless you can confirm that it's the right behavior; it appears that udeb dependencies are not getting resolved when the cd is built)
<superm1> slangasek, i'll put it on germinate for now, if you've got some better ideas i'll  be all ears
<sistpoty> Riddell: may I bug you to look at FFe bug #334121 again? ;)
<ubottu> Launchpad bug 334121 in plasma-widget-translatoid "Update to 0.6" [Wishlist,New] https://launchpad.net/bugs/334121
<sistpoty> thanks jdstrand for letting faumachine through new (3rd time indeed was a charm) *g* :)
<BUGabundo> asac: pitti I tested FF 3.1 with a clean profile: Without NM integration it will not change to off line. with flag to FALSE if NM is off, FF will go Offline too
<slangasek> superm1: I was going to suggest the ubuntu-cdimage project; I guess udeb deps are supposed to get resolved, or else lib deps would be a headache - what udeb are you seeing that problem with?
<avb1> hello all
<avb1> guys, why everything is linked with libselinux?
<avb1> ubuntu doesnt use it
<avb1> or its in use by apparmor?
<avb1> i thought its not
<slangasek> various core utilities have to be linked with libselinux in order for them to correctly handle SELinux when it is enabled
<slangasek> so we link against the lib even though it's not enabled by default.
<avb1> i see, so, ubuntu dont use it by default, but its still "supported"
<superm1> slangasek, i've filed bug 338967, so maybe follow up on that
<ubottu> Launchpad bug 338967 in germinate "alternate and server CDs are not pulling in udeb dependencies" [Undecided,New] https://launchpad.net/bugs/338967
#ubuntu-devel 2009-03-07
<slangasek> superm1: are you sure media-retriever/mountmedia aren't in the initramfs?
<slangasek> superm1: media-retriever should be included in all cdrom initramfses, according to the d-i source
<TheMuso> slangasek: have livefs builds for powerpc been turned off, or are they dying in another way that I can't see, as I don't see any logs since Feb 27th.
<TheMuso> livefs builds for ports in general actually.
<slangasek> TheMuso: ports CD builds have been disabled because ports.u.c was having Issues, and the ports builds were both causing contention on the mirror while it was trying to repair its RAID array, and also breaking the non-ports builds due to locking issues
<slangasek> I'll check with IS whether it's safe to re-enable
<TheMuso> slangasek: ok thanks for that.
<jdong> any X deities know why compiz trying to start on my jaunty Intel GMA950 would instantly lock up the system?
<superm1> slangasek, i'll verify on monday. this came about because i was attempting to use a patched media-retriever so i didn't realize i'd have to repack the initramfs to use it.
<jdong> sbeattie: http://jdong.mit.edu/~jdong/jailbuddy2.png this is what came of our discussion the other day :)
<jdong> it's an ugly solution but it works
<jdong> at least that gives some user interaction for willingly escaping out of apparmor
<jdong> I will eat my hat if /usr/bin/file becomes vulnerable to some untrusted input exploit :)
<jdong> (actually... that has probably happened before)
<LaserJock> jdong: what kind of hat do you wear?
<jdong> not a fedora ;-)
<LaserJock> an edible hat might be nice
<slangasek> superm1: aha
<kees> doko: openjdk looks good with stack/fortify.  2 new errors, 1 fixed error, out of almost 3300 tests.
<ion_> Woot, grub2 works.
<ideamonk_> http://i39.tinypic.com/14cd4xi.png
<ideamonk_> isn't the file selection windows too wide there
<ideamonk_> imagine if a upload popup wished to allow users any one ".abc,.abd..... 60 such things
<ideamonk_> won't that fill up all my screen space ?
<ideamonk_> i've proposed a solution - http://ideamonk.blogspot.com/2009/03/trying-to-make-ubuntu-better.html
<ideamonk_> i wonder if that window is handled totally by firefox or gnome makes it for the user
<ideamonk_> any ideas ?
<maxb> TheMuso: My audio was glitching horribly, your PPA packages fixed it up nicely. Is there any testing I can do to help with getting Jaunty's official audio fixed?
<Laney> related, where would a bug where my master volume always resets to muted after login go?
<hyperair> Laney: how about the init-scripts
<Laney> really?
<hyperair> Laney: one of the alsa ones
<hyperair> Laney: it's supposed to save your volume when stop is called, and restore when start is called
<hyperair> Laney: i noticed this in archlinux. probably is the same on debian-based systems
<Laney> right, I never know what's pulse and what's alsa
<hyperair> hahah
<hyperair> pulseaudio is purely userspace
<hyperair> whereas alsa has stuff both in kernelspace and userspace
<Laney> but it has something to do with volume controls
<hyperair> that's the way i understand it
<hyperair> pulseaudio doesn't attack your volume controls on its own unless i'm mistaken
<hyperair> as in the system's volume control
<hyperair> individual apps yes, but not the system's volume control
<hyperair> the system's one is handled by the alsa initscript
<hyperair> erm alsasound
<hyperair> /etc/init.d/alsasound
<hyperair> it saves into /etc/asound.state
<hyperair> and restores from there
<Laney> I don't even have that file
<Laney> the initscript, that is
<hyperair> eh?
<hyperair> lemme do a dpkg -S
<hyperair> okay, thisi s strange, i can't find it
<cjwatson> ISTR a bug being filed about this already
<cjwatson> /etc/init.d/alsa-utils, BTW
<hyperair> hmm? does that poke asound.state?
<Laney> cjwatson: Cool, I was just trying to find the right places to search
<hyperair> oh it does!
<cjwatson> via alsactl, yes
<hyperair> /var/lib/alsa/asound.state
<Laney> bug 227505
<ubottu> Launchpad bug 227505 in alsa-utils "Not restoring volume levels" [Undecided,Confirmed] https://launchpad.net/bugs/227505
<geser> jdstrand: re bug 337659: where did you find the dependency? I see bmpx only listed in recommends with two other alternatives.
<ubottu> Launchpad bug 337659 in bmpx "RM: bmpx -- RoM; unmaintained upstream, uses outdated libraries" [Wishlist,Invalid] https://launchpad.net/bugs/337659
<chris-p> pulseaudio on Jaunty is very stuttery
<chris-p> did a test and: Underruns for  pulse:   26, Underruns for   alsa:    1
<directhex> is cdimage down for everyone, or just me?
<StevenK> http://downforeveryoneorjustme.com/cdimage.ubuntu.com
<directhex> poot.
<directhex> well, i'll use an intrepid cd & upgrade
<sebner> StevenK: lol, cool site
<chris-p> directhex: why not download it off a different mirror
<directhex> chris-p, there arfe mirrors for jaunty discs?
<chris-p> directhex: http://ftp.heanet.ie/mirrors/ubuntu-cdimage/releases/9.04/alpha-5/
<directhex> oh, those crazy irish. woo!
<elmo> maswan also has a mirror
<elmo> in any event, I've kicked some of the worst offenders off of cdimage, and it's backup
<directhex> i should poke the mirror.ox.ac.uk people
<hyperair> directhex: down for me. it was up 6 minutes ago
<hyperair> *5
<hyperair> ah it's back up
<directhex> i'll just wait for heanet's sloooow download
<directhex> doko, thanks for ironpython upload in sid
<Laney> anyone able to NEW pywebkitgtk binaries pretty please?
<DktrKranz> Riddell, if you have time, mind looking at bug 334121 with your motu-release delegate hat on?
<ubottu> Launchpad bug 334121 in plasma-widget-translatoid "Update to 0.6" [Wishlist,New] https://launchpad.net/bugs/334121
<sebner> DktrKranz: nahh, kde is evil :P
<DktrKranz> hey sebner!
<jdstrand> geser: I see now that you are right. it is a Recommends only. script output didn't make that difference. my bad. I'll remove
<jdstrand> geser: done
<chris-p> directhex: download finished yet?
<directhex> chris-p, oh, yeah
<RainCT> pitti: about bug #338279, $GDMSESSION is "default" here, so the "if [ $GDMSESSION = gnome ]; then exec" won't work
<ubottu> Launchpad bug 338279 in notify-osd "notify-osd should be aware of if the messaging indicator is present and fall back to old style notifications if it's not" [Undecided,New] https://launchpad.net/bugs/338279
<ScottK> DktrKranz: Riddell is at a free software conference in Nigeria, so probably not for a few days.
<DktrKranz> ScottK, oh, I didn't know that, thanks
<Laney> doko: Would it be a problem for boost to depends on all of the pythonx.y-dev packages as alternatives?
<Laney> libboost-pythonfoo-dev, that is
<darksmoke> is there a way to install firefox on kubuntu without the list of unneeded-dontknow-why-they-where-added-as-dependencies dependencies?
<darksmoke> like synaptics and suck
<darksmoke> *such
<azeem> darksmoke: that's a question for #ubuntu
<directhex> azeem, or even for #kubuntu!
<Toobaz> is there an Ubuntu official policy about packages which only have a menu item in the Debian menu (and hence end up in "Others" section)? I've asked a maintainer to add a .desktop under "Education;Science;Math;", but (also because of the bug that Science is no main cathegory) he prefers "Applications/Science/Data Analysis", and I can understand him. Is there any possibility to avoid a (quite permanent) patch at the M
<Toobaz> (reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518596
<ubottu> Debian bug 518596 in r-cran-rcmdr "R Commander missing in applications menu" [Unknown,Open]
<Toobaz> well, maybe #motu is the right channel, I move there, please forget my question here
<Adri2000> slangasek: now that the samba sru is uploaded, can you approve it on behalf of ubuntu-sru please? (#328874)
<lfaraone> Would it be reasonable to add apparmor profiles to userland SSH in jaunty+1?
<jdong> lfaraone: do you have samples of what those profiles would look like?
<jdong> I assume you have some change_hat patching for openssh
<lfaraone> jdong: no clue, I'm not too familiar with openssh yet.
<jdong> lfaraone: well the fundamental problem is Apparmor alone is not really granular enough to encapsulate openssh's role
<jdong> lfaraone: in effect you need to allow openssh touch enough of pam and uid switching that it is probably going to end up not any more constricted than otherwise
<jdong> at least that was my experience with attempting to secure it with apparmor
<lfaraone> jdong: is there a way to make it that the only app that is allowed access to ~/.ssh is /usr/bin/ssh?
<jdong> no.
<jdong> apparmor is not good for doing system-wide restrictions like that
<jdong> that's much easier to express in SELinux
<lfaraone> jdong: why was apparmor chosen over selinux?
<lfaraone> (I was juuust going to say, lol)
<jdong> lfaraone: lack of intrusiveness, low overhead, simplicity of configuring
<lfaraone> jdong: is there a way to improve apparmor in order to make it easier to implement system-wide restrictions?
<jdong> lfaraone: it's not designed to do that I am afraid.
<jdong> to clarify on "simplicity"
<jdong> here's my irssi profile in apparmor for Hardy: http://paste.ubuntu.com/127980/
<jdong> and here's the same thing in SELinux for Lenny: http://jdong.mit.edu/~jdong/selinux/irssi.if
<jdong> the former I can explain to my 9 year old sister :)
<lfaraone> jdong: hehe, because you hide all the scary bits in templates, I assume? :)
<lfaraone> *include files
<jdong> lfaraone: not at all
<jdong> lfaraone: most of those bits are not required
<jdong> lfaraone: note that SELinux is all in templates too
<maco> at some point i have to learn to read that, and then to write it myself
<jdong> i.e. corenet, corecmd, manage_*_pattern
<jdong> userdom_*
<lfaraone> maco: what, SELinux?
<maco> lfaraone: yeah
<jdong> in practice it's not IMO any more *difficult* to configure
<lfaraone> maco: god, I'm going to kill myself if I end up managing RHEL systems; at least until they simplify that.
<jdong> just the learning curve is a step function
<lfaraone> jdong: is there a gui? :)
<maco> lfaraone: why would you have a gui on a server?
<maco> lfaraone: and RHEL includes some default contexts pre-configured, i think
<jdong> lfaraone: not for either, in practice.
<lfaraone> maco: yeah, I know.
<jdong> there are some automated tools in GUI and CLI form for developing policies but none of them work in practice for me
<lfaraone> maco: I mean for use on the desktop.
<lfaraone> jdong: that's terrible.
<lfaraone> maco: as in, I write a policy on my nice desky and scp it to the server.
<jdong> audit2allow (SELinux) tends to suggest all the wrong things to do (i.e. give unconfined access, comeon do it! do it!)
<lfaraone> jdong: unconfined? (you can tell I'm new to this)
<jdong> and aa-logprof is equally unclear in asking a bazillion questions for something one glob accesses.
<jdong> lfaraone: i.e. if irssi tries to read ~/.irssi and you haven't configured it to allow this
<jdong> and then you run audit2allow
<jdong> the deafult rule it generates is "read_files_pattern($1_irssi_t, $1_home_t, $1_home_t)
<jdong> and similar for write files
<jdong> which gives irssi full access to your unlabeled sections of your home directory
<jdong> the "correct" pattern would have been to create a file context globbing the areas it tried to access if they were a general label
<jdong> IMO neither of these tools NEED a GUI.
<jdong> the hardest part is describing what your process to confine needs access to.
<jdong> and if you can explain that to me in English, you can write it in selinux or apparmor just as easily
<jdong> especially apparmor.
<lfaraone> jdong: Well, AppArmor seems simple enough.
<lfaraone> jdong: however SELinux seems unreadable to me.
<jdong> lfaraone: it's a much more powerful system capable fo expressing far more relationships than an ACL.
<jdong> it's necessarily complex.
<jdong> hence it is capable of doing the OpenSSH profiles and GnuPG profiles you wanted :)
<lfaraone> jdong: it is possible to have complexity while retaining ease of understanding and use, no?
<jdong> lfaraone: not really
<jdong> lfaraone: the apparmor language cannot define domains and file types between domains.
<jdong> and that's fundamentally one of the things SELinux lets you do that makes possible the things you are asking for
<jdong> and also, when SELinux "breaks" even your unconfined users are affected.
<jdong> there are things that unconfined_u cannot do, and there's more of those when your policy is broken!
<jdong> and I still haven't begun to understand how SELinuxing GUI apps correctly works :)
<lfaraone> hm.
<lfaraone> jdong: has any thought been put into using the rainbow/bitfrost framework for GUI apps?
<lfaraone> jdong: OLPC did a pretty good job with the XO, with a (IMHO) very good framework.
<jdong> lfaraone: what does bitfrost do in terms of domain-to-domain interaction though?
<jdong> I recall it seemed to have next to NO protection for things that "interact with the home directory"
<lfaraone> jdong: domain-to-domain?
<lfaraone> jdong: you can't write to ~ at all, hehe.
<jdong> lfaraone: Firefox needs to save a file you download, and then open it with Evince.
<lfaraone> jdong: since each app is technically running as its own user.
<jdong> how do you implement that with a bitfrost setup?
<jdong> like with Apparmor it's a relationship that's pertty freaking hard to describe.
<lfaraone> jdong: currently we have firefox save an object to the journal (which is a problem once you are talking about non-abstract file structures), and you're sent to the object's details page where you choose to open it in evince.
<LaserJock> lfaraone: btw, how is Abiword going?
<jdong> sounds as hackish as my apparmor solution.
<jdong> http://jdong.mit.edu/~jdong/jailbuddy2.png
<lfaraone> LaserJock: it isn't, I was hopelessly lost. I *think* morgs was working on it,
<lfaraone> *.
<jdong> someone told me yesterday jail buddy reminded them of UAC :(
<LaserJock> k
<lfaraone> jdong: hehe
<lfaraone> jdong: it's like that, but in OLPC/sugar we're intergrating it with the whole UI paradigm so it's unintrusive (assuming you don't expect computers to work the way Windows/GNOME/KDE does)
<jdong> lfaraone: one of my longer term projects is working on a Firefox SELinux profile that supports the concept of quarantined files the way OS X handles them
<LaserJock> jdong: shouldn't that be called JailFileKit or similar? :-)
<jdong> i.e. they are labeled in such a way that the user is neither allowed to access nor execute them until "bringing it out of quarantine"
<lfaraone> jdong: interesting
<jdong> lfaraone: how does bitfrost deal with local priviledge escalation once an app is compromised?
<jdong> lfaraone: i.e. if I took advantage of that flashplayer 0day and had a shell within Firefox, what can I do?
<lfaraone> jdong: anything firefox can do , which is steal your cookies.
<lfaraone> jdong: write huuuuuge files to the journal (currently nothing stops you from doing that)
<lfaraone> jdong: and nothing else. you cannot su, etc.
<lfaraone> jdong: you can only see things that you have been explitly given access to by a user action.
<lfaraone> jdong: and steal your banking info.
<lfaraone> jdong: however it's isolated; unless you are able to exploit another app you can't spread to it.
<lfaraone> jdong: (ie if I write shell code to the journal, the user has to exec it manually)
<jdong> lfaraone: how is the process space divided? can I ptrace() existing processes or peer into /proc or /sys?
<jdong> flashplugin definitely requires access to /proc to work correctly.
<TheMuso> maxb: Talk to dtchen when he is online, he is trying to get glitchy issues sorted out.
<lfaraone> jdong: would it be a problem if you were? I think you *can*, currently.
<jdong> lfaraone: well yes in a way it would be
<lfaraone> jdong: how exactly?
<jdong> lfaraone: a few of the root level kernel exploits were done through malformed proc/sys not to mention seeing what processes are running can be a serious privacy breach.
<jdong> it still doesn't stop me from abusing your firefox into a free-for-all worm/zombie spam server
<lfaraone> jdong: does SELinux?
<jdong> yes.
<jdong> 18:26 Exec: /bin/sh: Permission denied
<jdong> 18:26 -!- Irssi: process 0 (ls) terminated with return code 255
<jdong> jdong@CLOSETMONSTER:~$ ps aux | wc -l
<jdong> 4
<jdong> I think there's more than 4 processes running on my system ;-)
<jdong> jdong@CLOSETMONSTER:~$ su -
<jdong> Password:
<jdong> ls: cannot access /root: Permission denied
<jdong> ls: cannot open directory /home/jdong: Permission denied
<jdong> su'ing to root actually ended in a useless context that had access to neither root's home nor the original user's home :)
<lfaraone> jdong: 18:32  m_stone$ lfaraone: you can ptrace() processes running as your same uid.
<lfaraone> jdong: lol. I already told you, though, that /bin/su isn't executable by the world.
<lfaraone> jdong: (in our magic rainbow situation)
<jdong> lfaraone: but that doesn't preclude a root exploit being leveraged via another means -- you provide basically any Linux ability that your jail environment has, and as you get domains to interact with each other (which FRANKLY in the current setup -- they CAN'T) it's going to get harder and harder to balance security and intrusiveness.
<jdong> IMO it's not a good replacement for something like the UBAC SELinux refpolicy that was just checked in @ tresys
<lfaraone> jdong: oh yes, we're most surely going to persue a system where rainbow and SELinux complement each other.
<lfaraone> jdong: RH sent over some of their own engineers, and even the "selinux people" couldn't think of how to make selinux do what we were trying to accomplish.
<jdong> well indeed SELinux is not the magic bullet for this stuff either.
#ubuntu-devel 2009-03-08
<maxb> TheMuso: ok, will do - thanks
<ebroder> The mit-scheme package is currently complete broken - uninstallable. Do I have a chance of getting a freeze exception to essentially re-merge with Debian?
<ebroder> (Actually coming up with something like a minimal path would be more work than I'm interested in doing, but I think I mostly have the merge finished)
<Hobbsee> quite likely
<Hobbsee> is that even a new upstream version?  You could probably just do it, without the exception
<ebroder> It's...not technically an upstream version, but it seems that the "releases" for a while have just been dated snapshots
<ebroder> Cool - I have one more build to try. If it works I'll go ahead and open a bug
<ebroder> Hmm...if I'm putting multiple LP closers in a changelog entry, is that "(LP: #123456, #654321)"?
<Mithrandir> iirc we made that work, yes.
<bluefoxicy> rhythmbox is eating freaking lots of CPU
<bluefoxicy> 87% to play this MP3
<xtknight> what configuration file is written to when the primary mixer track is changed under Sound Preferences?
<xtknight> i'm having a problem where my system forgets the device i select upon next reboot.  trying to debug it
<xtknight> also where is the sound preferences applet stored since there is no capplets/sound-properties in capplets-data
<calc> cjwatson: i was reading on tytso blog that for non dual boot systems that are being freshly installed using GPT may be a better idea than using msdos partition format, has there been any discussion on doing this in ubuntu?
<ITechJunkie> Does anyone here know why my terminals don't seem to be refreshing right? I have to press enter twice just to see the text output of the next line...
<RainCT> ITechJunkie: Same here, please tell me if you find out how to fix it :P
<ITechJunkie> gnome-terminal is the worst, xterm isn't quite as bad
<RainCT> Well, it only happens some times here with irssi and such, not always
<ITechJunkie> RainCT: I'm wondering if it was an update...
<ITechJunkie> Yeah, i'm using irssi now and it's being janky...
<RainCT> ITechJunkie: as a workaround, pressing Ctrl+L will force it to refresh and after doing that a few times it may work again
<ITechJunkie> is that for irssi or gnome-term?
<RainCT> ITechJunkie: for the terminal, I think
<ITechJunkie> Is there a log where I can see the updates I have installed recently?
<Laney> :q
<Laney> whoops
<geser> ITechJunkie: /var/log/dpkg.log
<ITechJunkie> geser: thanks
<ITechJunkie> I really hope it wasn't that kernel update that came out...
<ITechJunkie> but I bet it was, i've had several problems since then including nvidia drivers
<zyga> hello, I'd like to ask if pydoc3 is broken by design or is something invalid with py3 in jaunty? compare: 'pydoc os' vs 'pydoc3 os'?
<ebroder> Do I need to argue for a freeze exception for bug #339618?
<ubottu> Launchpad bug 339618 in mpb "Update libctl to use guile-1.8" [Undecided,New] https://launchpad.net/bugs/339618
<RainCT> kirkland: Uhm.. Where did the key binding to close windows in screen-profiles go?
<JanC> zyga: there is a thread on c.l.py about that, I think
<Laney> Is it possible to sync from lenny instead of sid or am I better off just uploading myself?
<slangasek> it's possible, yes
<slangasek> ArneGoetje: can you help me understand why we have -base vs. non-base langpacks?  the latest langpack uploads with duplication of the xulrunner translations have contributed to kicking us back oversize on CDs - I'd like to keep the CDs packed as tight as possible during development so we have early warning when something's getting bigger than it should, but that doesn't work so well when I get a full langpack's-worth of fluctuation from the langpack
<slangasek> ... themselves :)
<johanbr> tkamppeter: I recently tried printing 40 pages out of a 350 page pdf document with total size 4.5 megs. Those 40 pages were run through gs to produce a 100 meg ps file. Cups then converted this to pdf again to mess with it for a bit, giving a 166 meg temporary pdf file. Finally this was piped to pdf2ps to send to the printer.
<johanbr> Is this really the way things are supposed to work? This is with Jaunty, by the way.
<tkamppeter> johanbr, the plans are that no PostScript at all is involved in that process.
<tkamppeter> The first conversion to PS is probably caused by the application from which you are printing. Which app did you use?
<johanbr> evince
<johanbr> which uses the gtk printing libraries
<tkamppeter> CUPS is PDF-centric from Intrepid on. This means it turns everything to PDF and if it gets PDF it leaves it as PDF. Then it does page management (N-up, selecting pages, ...) on a PDF data stream which is more reliable than on PS. Now it converts PDF directly to the printer's native language (the native language of some printers is PostScript, here we have to convert to PS).
<slangasek> but no one told our primary pdf viewing software about this?
<tkamppeter> If your printer is not a PostScript printer make sure that you have a PPD file of Intrepid or later (with two or more "cupsFilter" lines), if not, re-create your print queue with system-config-printer.
<johanbr> It is a postscript printer (HP Laserjet). And the print queue was created on a fresh install with a Jaunty daily build from a month or so ago.
<tkamppeter> GTK has standard functionality for generating print data, opening a print dialog, ..., but unfortunately there are many ways to call these functions, and this makes a simple patch like in bug #258421 bot switching all apps to PDF. Some apps need to be taken care of individually. Patches welcome ...
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421
<johanbr> from bug: "Other programs, like evince and Firefox still send PostScript. Here there are probably similar patches needed in the applications themselves."
<johanbr> I see. Thanks for the explanation.
<tkamppeter> slangasek, perhaps the patch needed for evince is as simple as the patch of bug 258421.
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421
<calc> anyone able to spot what is wrong with my compiler args here: http://paste.ubuntu.com/128477/  ?
<slangasek> tkamppeter: I just don't understand why it wasn't a priority to make sure the PDF viewer was doing the right thing as part of the cups transition...
<calc> it compiles the code it just refuses to link it for some reason
<johanbr> tkamppeter: looks like a simple patch to line 1016 of ev-print-operation.c would work.
<johanbr> http://svn.gnome.org/viewvc/evince/trunk/shell/ev-print-operation.c?view=markup
<RainCT> Arr.. If you move a file which Totem is playing it stops.. This didn't happen before :(
<tkamppeter> johanbr, so I will add an evince task to bug 258421, please add the link to the bug report.
<ubottu> Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421
<johanbr> tkamppeter: Sure. I'm now compiling evince with the change I mentioned. If it works, I'll attach the patch.
<tkamppeter> johanbr, it looks like that the line 1016 gets the desired output format (PS or PDF) from some centralized configuration. Perhaps we should change this configurationm to get more apps to print in PDF.
<TheMuso> dtchen: Will we be able to push a new rev of pulseaudio before Tuesday?
<johanbr> tkamppeter: Right. Looking at that now.
<UnixOne> hi
<UnixOne> I've had some problems with the package comerr-dev. Kind of dependancy problems.
<UnixOne> Is that a known error?
<ebroder> What exactly are you running into?
<UnixOne> ebroder: I tried compiling the latest kernel that requires installation of several -dev packages. which was never a problem for me. But my apt got stuck with the package comerr-dev which has some dependancies that were defect also because of it.
<UnixOne> ebroder: It's a clean system no foreign repositories except the backports.
<ebroder> You're still not being specific enough
<UnixOne> ebroder: the un/install routine of comerr-dev is defect
<ebroder> What version of Ubuntu is this on?
<UnixOne> Intrepid
<jdong> could you pastebin the exact error message?
<UnixOne> only checking the backports maybe even the proposed updates. causes that huge error.
<UnixOne> jdong: I've manuall uninstalled it by hand.. I don't like to run into that trouble again.
<jdong> well then the short answer is no, this is not a known problem.
<UnixOne> jdong_: I removed the installed files and reset the status of dpkg
<ebroder> The group that I work with uses a lot of software that depends on comerr, and we haven't had any problems with it
<jdong> *cringe*
<jdong> you hand edited *WHAT*?
<ebroder> (Well, I mean, we have, but those are related to comerr being worthless, not the packaging being wrong :-P)
<UnixOne> ebroder: did you enable backporst and proposed updates?
<jdong> I use both here on all my Ubuntu machines.
<UnixOne> jdong: are you running kubuntu?
<ebroder> I use -backports on virtually all of my machines, although not -proposed
<ebroder> Shouldn't matter
<jdong> backports doesn't do anything related to comerr
<UnixOne> maybe proposed-updates is the key factor
<jdong> and kubuntu vs ubuntu use the same repositories.
<UnixOne> jdong_: indeed
<jdong> I'm looking at this month's and last month's propsoed uploads
<jdong> see nothing comerr related.
<jdong> next time, please capture a precise error message -- without it diagnosing something like this is next to impossible
<UnixOne> jdong how can I find the cause of that error?
<ebroder> That's impossible to say without knowing what the error was
<UnixOne> I mean how do I reversely look into that dependancy problem
<jdong> I don't even know what error you are referring to.
<ebroder> There is no dependency problem. The package installs cleanly
<UnixOne> ebroder: ok, I'll install it again
<jdong> and "some package has a defect" is not really helpful
 * jdong notes there is some irony about errors in libcomerr :)
<ebroder> You know what the best thing about the common error library is? There are so damn many of them
<UnixOne> jdong: a question before I do install it. may it affect the system when I used backports+proposed to upgrade my system, when I remove proposed now?
<jdong> not really?
<UnixOne> k
<slangasek> ebroder: only one in Ubuntu :-P
<ebroder> slangasek: Incorrect
<UnixOne> I'll uncheck proposed updates then
<ebroder> AFS ships its own com_err :)
<slangasek> eh, really?
<jdong> well AFS is weird in all its own ways :)
<slangasek> krb5 uses the common one
<ebroder> Right
<slangasek> I would've thought someone would send up the AFS stuff by now
<ebroder> There's a lot of muttering about how someone really should, but I don't think anyone's actually gone and unified the libraries
<ebroder> Actually...I bet Heimdal has a separate com_err from MIT Kerberos
<ebroder> So that might be 3
<slangasek> heimdal may not use it at all
<UnixOne> comerr-dev is an error for me :P but it's installing.. will pastebin the logs
<jdong> libopenafs-dev: /usr/include/afs/com_err.h
<jdong> AFS definitely has its own :)
<UnixOne> yay I've an errror with comerr
<jdong> so we've heard the first time
<ebroder> Yeah - the default API calls have afs_ prepended onto them, but there's a #define you can set to make it collide
<UnixOne> ehrm how do I copy the log out of the terminal window in synpatic? STRG+C or STRG+SHIFT+C don't do it. Synaptic asks I really want to terminate. I say no. And I can't copy it.
<UnixOne> but I was able to copy the popup that appeared before
<jdong> ctrl-shift-c will do it
<jdong> otherwise use mouse paste
<jdong> or use a screenshot
<jdong> I think /var/log/apt/term.log or something stores transcripts too
<UnixOne> jdong: yes, I got it. It was related to klipper a clipboard tool default in kubuntu. It just gave me the earlier content of the clipboard. I deleted the clipboard history have done another ctrl+shift+c and voila.
<UnixOne> short version(popup) http://paste.nn-d.de/839 very very long version -> (terminal) http://paste.nn-d.de/840
<ebroder> Well, English is definitely my only language, but I'm pretty sure that the problem is with gettext, not comerr-dev
<slangasek> both give the error
<ebroder> Hmm...good point
<UnixOne> I tried installing THIS http://paste.nn-d.de/841 in short build-essential kernel-package qt4-dev-tools libqt4-dev
<slangasek> 'subprocess post-installation script returned 1'
<jdong> well yay.
<slangasek> UnixOne: 'info' is broken on your system
<UnixOne> info ?
<UnixOne> :D
<UnixOne> lol
<slangasek> specifically, the install-info script provided by dpkg to register info documentation
<UnixOne> first the error was broken, now it's info
<jdong> install-info --quiet --section "Development" "Development" \ --description="" /usr/share/info/gettext.info
<jdong> that is what gettext attempts to do
<slangasek> it's failing in the postinsts of any program that calls it
<ajmitch> but which install-info is being used here?
<UnixOne> I there's a part that needs translation or is important I could translate it
<UnixOne> it is  info_4.11.dfsg.1-4_i386
<UnixOne> the default one I guess
<slangasek> UnixOne: what's the output of 'debsums -s dpkg' on your system?
 * ajmitch was meaning more along the lines of 'whereis install-info', in case you have one in /usr/local/bin or otherwise
<UnixOne> that package isn't installed currently
<UnixOne> slangasek: debsums: checksum mismatch dpkg file /sbin/start-stop-daemon
<slangasek> well, that's interesting
<slangasek> but not directly relevant
<UnixOne> yes, has nothing to with comerr-dev.. somehow. strange
<slangasek> UnixOne: does /usr/local/bin/install-info exist, as ajmitch suggests?
<jdong> which install-info
<UnixOne> slangasek jdong yes /usr/local/bin/install-info
<slangasek> yeah... you'll need to get rid of that
<jdong> uhh.
<jdong> yeah...
<jdong> that could be problem #1...
<jdong> though maybe dpkg shouldn't be operating with /usr/local in the PATH?
<jdong> or is there actually a use-case for that
<slangasek> jdong: the general principle is that dpkg shouldn't behave differently than the rest of the system wrt PATH
 * jdong nods
<ebroder> I could imagine wanting it for testing purposes
<jdong> indeed the rest of the system is no different about succumbing to /usr/local poison
<ScottK-desktop> That's by design.
<ebroder> If the system didn't respect /usr/local, then you'd have people putting a bunch of stuff in /usr, and that just doesn't end well
<ScottK-desktop> If an admin installs something, it should take precendence because presumably they know what they are doing.
<andersk> python3-minimal is currently getting pulled into all Jaunty installs. Can someone look at my debdiff in bug 330613?
<ubottu> Launchpad bug 330613 in python3-defaults "python3-minimal should not have 'Essential' set to yes" [Undecided,Confirmed] https://launchpad.net/bugs/330613
<UnixOne> ebroder jdong can you help me?
<UnixOne> I've sent you all logs. do you know what I can do to fix that error?
<ebroder> UnixOne: remove the install-info in /usr/local
<UnixOne> ebroder: sudo mv /usr/local/bin/install-info  /usr/local/bin/install-info.backup ?
<ebroder> Sure
<UnixOne> ok
<UnixOne> and then reinstall those packages, right?
<ebroder> Should work
<UnixOne> ok
<ebroder> If you've got anything else lying around in /usr/local/bin or /usr/local/sbin, you should think long and hard about whether they should be there
<UnixOne> ebroder: why? I've just texlive2008 installed
<UnixOne> in the default location
<UnixOne> that's /usr/local/bin
<UnixOne> ebroder: it worked wow
<UnixOne> genius!
<TheMuso> dtchen: With the work you are doing on pulse, will things be in a state such that we can push a change for alpha 6, due this week?
<UnixOne> ebroder: why did install-info in /usr/local cause an error?
<dtchen> TheMuso: yes
<TheMuso> dtchen: ok great.
<ebroder> Anyone willing to sponsor an upload for bug #339449?
<ubottu> Launchpad bug 339449 in mit-scheme "FeatureFreezeException: Merge mit-scheme with Debian" [High,Confirmed] https://launchpad.net/bugs/339449
<rbrito> Hi there.
<rbrito> I am an experienced linux user and I would like to help with the PowerPC port of Ubuntu.
<rbrito> I have 5 packages on the Debian archive and I use PowerPC since 2000.
<rbrito> I have also contributed some patches to the Linux kernel.
<rbrito> What would it be necessary to be a contributor so that PowerPC gets in a better shape?
<rbrito> For the task of helping with the PowerPC port, I can test it under an OldWorld computer (a PowerMac 9500/180MP upgraded to a G3/400MHz), a NewWorld computer (an iBook 12" G3 600MHz) and a Kurobox (an embedded device using a Freescale processor).
<rbrito> Of course, the easier task would be to get things running with the NewWorld computers.
<TheMuso> rbrito: please head over to #ubuntu-powerpc and we can chat there.
<rbrito> But I would like to know how the ports of Ubuntu are maintained, so that I can take the proper measures.
<rbrito> TheMuso, Thank you very much.
<johanbr> tkamppeter: Forcing evince to export pdf doesn't seem to work very well. The pdftopdf filter runs out of memory on large documents, and on small ones I get black borders and similar artifacts.
<tkamppeter> johanbr, can you direct the PDF printing output of evince into files to investigate the integrity, for example to see of acroread or gv handle this PDF correctly?
<tkamppeter> johanbr, what is your Launchpad user name?
<johanbr> tkamppeter: Sorry, I partially take that back. I think the small pdf document I started with was not very good.
<johanbr> and I just subscribed myself to the bug
<johanbr> For the "large" pdf document, pdftopdf grew to 1.6 gig resident size and the computer started swapping like crazy. Even though the original size is less than five megs.
<johanbr> tkamppeter: Which options does cups use when it calls pdftopdf? I tried running it by hand, and it worked fine (even if the resulting pdf file is a bit large, about 100 megs).
<tkamppeter> johanbr, can you attach the large PDF file which causes problems for you to the bug report?
<tkamppeter> To test CUPS filter chains there is a utility named "cupsfilter". See also its man page.
 * calc didn't realize he was going to end up learning how to write gnome code to fix bugs in OOo, heh
<tkamppeter> In general a CUPS filter (or backend) is called with 5 or 6 options. See "man 7 filter".
 * calc hopes he learns fast enough to fix the gvfs/gio bugs in OOo by beta
<tkamppeter> johanbr, you can call CUPS filters simply with "<filter> 1 1 1 1 '' <input file>" and get the output file on stdout.
<LaserJock> calc: OOo uses gcfs/gio directly?
<LaserJock> *gvfs
<johanbr> tkamppeter: Unfortunately I can't attach the document to the bug, but I could send it to you privately.
<tkamppeter> johanbr, then please do so: till dot kamppeter at gmail dot com
<johanbr> Interestingly enough, calling pdftopdf directly produces a large file (~ 100 megs), but calling cupsfilter produces a file of the same size as the original (~5 megs).
<tkamppeter> johanbr, is the file too big to attach or is it of confidential content?
<johanbr> The latter. Well, semi-confidential.
#ubuntu-devel 2010-03-08
<cjwatson> jibel: also I backported from git - I didn't apply a patch from the bug report
<cjwatson> jibel: so I would assume that Guillem would not have committed to git unless he thought it was OK
<jibel> see last comment on the upstream report.
<jibel> I had no news from him since then.
<cjwatson> jibel: see git.
<cjwatson> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=62668eb422853854976560949f95a5afcc6a8677
<jibel> I'll test the latest git
<cjwatson> thanks
<cjwatson> you could test http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/dpkg/lucid/ too if you like ...
<cjwatson> (er, in shorter form, lp:ubuntu/dpkg)
<jibel> cjwatson, ok, I'll run my use case and let you know about the results. thanks
<jibel> s/case/cases
<cjwatson> I test-built and test-double-installed it, but didn't do performance testing
<jibel> cjwatson, I test install/upgrade/removal/purge followed by a crash and check if all the files are there and in good shape
<jibel> cjwatson, and then I'll check the performance.
<psusi> is there anyone who can give me some tips on debugging what appears to be an infinite udev loop?  lucid alpha 3 hangs during boot for me with dmraid enabled and when I run udevadm monitor from the busybox after it times out, it appears to be processing infinite change events from sda and sdb
<psusi> I guess what I need is to see exactly what udev is attempting to do to process the events, and exactly what the events are... udevadm monitor just mentions they are change events... I need more details... any ideas on how to get some?
<jibel> cjwatson, the latest git does not work.
<jibel> cjwatson, There is a missing fsync on the dpkg database directory and the status file is not the right one after a crash.
<jibel> I'll report to upstream.
<psusi> is there anyone who can give me some tips on debugging what appears to be an infinite udev loop?  lucid alpha 3 hangs during boot for me with dmraid enabled and when I run udevadm monitor from the busybox after it times out, it appears to be processing infinite change events from sda and sdb
<persia> psusi: I'm 90% sure you want to ask that question between 10:00 and 17:00 UTC.  Someone might swing by, or read backscroll, but repetitions at this time of day aren't likely to find that many new readers.
<psusi> persia, yea I figured... the usual 2-3 guys working on dmraid are euro tz and don't appear to be active atm...
<psusi> it's frustrating that I have an idea of what's wrong but do not know where to proceed from here... I can't see any changes done to the dmraid udev rules or initrd scripts since it worked yet the new version definitely hangs up on it...
<lifeless> whats the new magic to do patch system abstraction
<persia> lifeless: edit-patch or format:3.0
<lifeless> uhm, must be neewer dev-tools.Thanks
<persia> just the most recent upload.
<emgent> FYI, http://www.backtrack.it/~emgent/stuff/facebook_USA_intelligence_guide.pdf
<persia> emgent: Please don't post stuff which potentially violates the content to read, even if it is interesting.
<alkisg> cjwatson: could you please excuse a direct question about update-binfmts? `chroot "$ROOT" mount -t proc proc /proc  && chroot "$ROOT" update-binfmts --import wine && umount "$ROOT/proc"` ==> this complains about $ROOT/proc being in use.
<alkisg> So I'd like to prevent update-binfmts from executing `if (system ('/bin/mount', '-t', 'binfmt_misc',  '-o', 'nodev,noexec,nosuid', 'binfmt_misc', $procdir))`
<alkisg> Is there any way to do that (or any other way to cleanly umount $CHROOT/proc)?
<micahg> pitti: is the retracer working?
<alkisg> cjwatson: If I try to divert `mount` and put `true` in its place, I'm getting "update-binfmts: warning: binfmt_misc initialized, but /proc/sys/fs/binfmt_misc/register missing! Giving up.". So I haven't found _any_ way at all to use update-binfmts in a chroot...
<dholbach> good morning
<alkisg> I've submitted my problem as a bug (or should I file it as a question instead?): https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/534211
<ubottu> Launchpad bug 534211 in binfmt-support "Cannot umount /proc after using update-binfmts in a chroot" [Undecided,New]
<pitti> Good morning
<RAOF> Good morning pitti
<pitti> hey RAOF, how are you?
<RAOF> Slightly frazzled.  I seem to be leaking memory in f-spot, file-backed undo shouldn't impact performance so badly, and I haven't moved around much today.
<lifeless> RAOF: walk to the shops and back
<lifeless> gets the blood moving. good for you
<RAOF> lifeless: My running shoes are already on...
<\sh> mahlzeit
<lifeless> seb128: https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/glib2.0/subunit/+merge/20879
<seb128> hi
<seb128> will look at that later, could you open a bug about it?
<lifeless> seb128: there's an upstream bug
<lifeless> seb128: or do you mean an ubuntu one, just to track it ?
 * lifeless thinks merge proposals shouldn't also need bugs; its redundant
<seb128> we don't track merge proposal so it's just going to be ignored the current way
<pitti> they are on the sponsoring queue righht now
<seb128> our current workflow is designed around bug reports and sponsoring
<seb128> pitti, well I don't track that either atm, ETOOMUCH
<pitti> but there are so many, that they get lost in the crowd
<seb128> but if somebody else do good
<pitti> seb128: *nod*
<seb128> I'm just telling that you of having a bug it will fell of my radar
<seb128> but if it's coming from upstream no need to bother about it
<seb128> new tarballs are due today
<persia> seb128: Have you looked at dholbach's sponsoring overview page?  Does that not work for you?  It's supposed to simplify stuff.
<seb128> persia, I did, I'm just so overloaded with tasks that I've no time to look at sponsoring recently
<lifeless> seb128: they are putting it *after* the new release.
<seb128> why?
<lifeless> dunno
<lifeless> 'Looks like an ok addition to me, but at this point, it should wait until we get
<seb128> in which case do we want it in lucid if upstream thinks it's not suitable for the current serie?
<lifeless> 2.24 out.'
<persia> seb128: OK.  When you have a chance, please file bugs, as making your life easy is important.
<lifeless> seb128: I think we do
<lifeless> seb128: because it lets the dx stuff - dbusmenu etc - have their tests introspected by hudson
<seb128> persia, will do, one issue right now is the number of random bzr junks listed there and finding items revelant to you or your team too
<lifeless> njpatel: ^ look up for the merge proposal
<seb128> shrug
<seb128> open a bug with a rational
<lifeless> seb128: doing so
<seb128> so we can discuss ffe there
<njpatel> oh, seb128's here! morning dude :)
<seb128> hey njpatel
<persia> seb128: OK.  Thanks.  The "finding relevant stuff" one is something that's widely important.  I haven't investigated the bzr branches yet.  I'll see if I can understand the state.
<al-maisan> Is there any particular reason why the most recent vim version in lucid was compiled w/o python support?
<persia> al-maisan: The latest upload was supposed to be a no-changes rebuild.  Check the build-log (I'm sure it wasn't intentional)
 * al-maisan looks at the build log
<al-maisan> In any case, it breaks plugins like vim-pyflakes and I guess quite a few Ubuntu users would be using vim along with python
<persia> al-maisan: Please fix :)
<persia> (although I think geser was also doing some vim work: check the sponsors queue)
<al-maisan> persia: let me have a look first, maybe something is in the pipeline already.
<dholbach> persia: james_w has landed a fix in LP that will remove the irrelevant branches
<geser> al-maisan: my vim merge awaiting sponsoring fixes this problem
 * dholbach really goes out now
<persia> dholbach: Cool.  Thanks for pulling that off my TODO list :)
<al-maisan> geser: great!
 * al-maisan takes a look at vim-nox (a separate package with built-in python support but no gui)
<geser> al-maisan: the problem is that vim uses MODLIBS from python (which should be only used by python itself) and tries to link with -lssl (and libopenssl-dev is not installed). all vim flavours are affected
<al-maisan> geser: ah, I see. Thanks for the explanation.
<geser> al-maisan: http://bazaar.launchpad.net/~geser/ubuntu/lucid/vim/merge-7.2.330-1/revision/55 if you want to cherry-pick from my merge
<al-maisan> geser: thanks!
<pitti> Riddell: ok to remove polkit-qt from lucid? no rdepends at all, and superseded by polkit-qt-1
<lifeless> seb128: bug filed - bug 534257
<ubottu> Launchpad bug 534257 in glib "support subunit in gtester-report" [Undecided,New] https://launchpad.net/bugs/534257
<seb128> thank you
<cjwatson> alkisg: the contract for update-binfmts --import is that the new format ends up enabled in the kernel at the end of it; I'm not sure how to satisfy that contract withoutmounting binfmt_misc
<alkisg> cjwatson: could I just divert update-binfmts to work around it?
<cjwatson> alkisg: you could umount /proc/sys/fs/binfmt_misc afterwards
<alkisg> I think I tried that but it didn't work, /me looks again...
<cjwatson> don't see why it shouldn't
<alkisg> cjwatson: worked fine, thanks a lot. I'll convert the bug into a question :)
<cjwatson> uh
<cjwatson> just 'cos there's a workaround doesn't necessarily mean that it isn't a bug
<cjwatson> of some kind
<alkisg> cjwatson: ah, should I leave it open then?
<alkisg> Ok, I'll comment about the workaround there and leave it open.
<cjwatson> I've commented
<cjwatson> we could for example alleviate the unmounting problem by automatically unmounting after an import if it wasn't mounted before
<cjwatson> but leaving it mounted on normal init script startup
<alkisg> Yeah, that sounds good
<alkisg> Another way could be to check for an environment variable
<alkisg> E.g. "IN_CHROOT=True" or something...
<cjwatson> alkisg: I don't want to require an environment variable to work "properly", whatever properly might be
<cjwatson> particularly not a non-standard one that might end up varying between programs
<cjwatson> IN_CHROOT=True RUNNING_IN_CHROOT=true CHROOT_SAFE=1 ARGH=foo
<alkisg> Sure, it would be a hack, not a proper solution.
<cjwatson> I won't add that
<cjwatson> there are certainly better ways
 * ogra thinks if linux containers would be easier to use that would solve a lot chroot /proc probs :)
<cjwatson> the kernel should just do the right thing by default
<ogra> or that
<cjwatson> it shouldn't require special action from userspace
<mok0> Why am I getting 2 popup notifications? It really bugs me
<alkisg> Linux containers would be a fine way to create/maintain ltsp chroots, but it would require a lot of rewriting. :-/
<ogra> alkisg, yeah, thats my complaint
<ogra> lxc shoudl *just work* without extra setup being needed
<ogra> imagine: lxc-mount proc -t proc /proc :)
<ogra> and it just vanishing if you exit the chroot
<mok0> Ah, I have 2 panels on top of each other
<Riddell> pitti: yes polkit-qt can go thanks
<ara> soren, hello
<soren> ara: Hey.
<slacker_nl> mvo: ping
<mvo> hello slacker_nl
<slacker_nl> mvo: hi, i send you an e-mail yesterday about update-manager
<slacker_nl> mvo: i've also added a -V option to do-release upgrade, do I need to create a new bug to submit the patch, just mail it to you?
<mvo> slacker_nl: thanks, the patch looks fine, I will apply it (the -c one)
<mvo> slacker_nl: best is either to submit a bzr branch or mail me
<mvo> slacker_nl: I'm usually slow with the bugreports (unfortunately :(
<slacker_nl> mvo: i don't agree with the last thing, i've seen your quick responses ;). I'll mail you the patch for -V
<mvo> slacker_nl: cool, thanks!
<mvo> slacker_nl: for patches and the like you can also always ping me on irc :)
<slacker_nl> mvo: cool
<slacker_nl> last question, manpages, I know I read the bug report with missing manpages, and now it seems you have manpages already, do you still need docbook manpages (started on it anyways, for the heck of it)
<slacker_nl> mvo: ^^
<mvo> slacker_nl: docbook is nice becasue it makes translations of the manpage easier, but because we are releatively late in the cycle I think its not critical to convert it now
<mvo> in the longer run using a xml format like docbook is nice, maybe you can get in touch with the ubuntu documentation team?
<slacker_nl> mvo: I will, I'll keep working on them, submit them, you decide when it will hit the shops :)
<mvo> slacker_nl: heh :) ok, cool! many thanks for working on this (and the previous patches)
<slacker_nl> np, glad to help!
<cjwatson> lidaobing: I'm trying to resolve bug 530178.  ibus-pinyin-db-open-phrase currently (a) ships a dangling open-phrase.db symlink and (b) depends on a version of pinyin-database that's not in Debian yet.  Did you by any chance just forget to upload a newer version of pinyin-database that ships the main.db file in unpacked form, or is something else going on?
<ubottu> Launchpad bug 530178 in pinyin-database "[MIR] pinyin-database" [Undecided,Fix committed] https://launchpad.net/bugs/530178
<lidaobing> cjwatson, wait a minute
<lidaobing> cjwatson, bug confirmed, I'll fix it ASAP
<lidaobing> cjohnston, thanks for your information
<cjwatson> lidaobing: cool, give me a shout and I'll pull the fix into lucid - I want to unbreak our DVD builds :)
<lidaobing> cjwatson, ok
<pitti> Riddell: do you think we should aim to drop Qt3 from lucid main?
<lidaobing> cjohnston, I have uploaded the new version, but you still need wait some time before it is ready.
<Riddell> pitti: it would be nice, let's see what's still in rdepends
<pitti> Riddell: I listed them on https://wiki.ubuntu.com/Specs/Lucid/DuplicatedPackages
<pitti> Riddell: many are supposedly just bindings (avahi, poppler, etc.)
<pitti> Riddell: e. g. libavahi-qt3-1 is not used by anything in main, just from the old kdelibs4c2a
<Riddell> pitti: lsb-desktop and scribus are the tricky areas I'd think
<pitti> Riddell: cases like these (source in main, binary which could go to universe) the resolution is a little tricky, though
<pitti> Riddell: since you would need the Qt3 b-dep in main if you want to build avahi-qt3 at all
<pitti> Riddell: oh, lsb still requires Qt3?
<Riddell> yes, it's part of the standard (LSB seems to be unmaintained as far as I can tell)
<pitti> well, it's maintained, but I guess they are slow to catch up
<pitti> Riddell: lsb-dekstop depends on lsb-qt4, though
<pitti> Riddell: where do you see the lsb qt3 rdep?
<Riddell> it Provides lsb-qt4, it depends on libqt3-mt and libqt4-gui
<pitti> that sounds wrong
<Riddell> why?  qt3 and qt4 are both part of LSB
<pitti> in the same version? (4.0)
<Riddell> I believe so yes
<Riddell> although I can't actually find it online to confirm, but I'm sure we looked at it last UDS
<Riddell> yes http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/tocqt.html and http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/tocqt3.html
<mvo> what is the kernelcommandline to disable frambuffer loading these days? it seems like nofb is not honored in current lucid and something swtich video modes (plymouth is already removed)
<Riddell> mvo: nomodeset ?
<mvo> Riddell: thanks, that was the one
<seb128> slangasek, sorry about the over reassigning to plymouth, I just tried to cut through the some hundred bug emails from the weekend and 90% of the gdm bugs we get atm are plytmouth issues
<seb128> ie people getting a text vt with a mouse cursor
<seb128> or people having gdm crash on enter
<amitk> Keybuk: cjwatson: should I have to update initramfs if I add a new disk to my Lucid server setup that was LVM at install?
<amitk> I see the new bootsplash with "Waiting for /home [SM]"
<cjwatson> I'm not sure.  Theoretically you probably ought not to have to, but there might be bugs ...
<\sh> amitk: the same issue I had with newly created LVM devices during boot up in lucid server...
<chrisccoulson> does anybody know if doko is likely to be around today?
<amitk> cjwatson: the init goes by too quickly to tell me what the real problem is (in recovery mode) and break=init doesn't hit the problem. Any other ways to store the messageS?
<amitk> \sh: how did you solve it?
<amitk> AFAICT the only thing I did to get it "working" was update-initramfs
<\sh> amitk: I didn't .. I removed the lvm devices (I was lucky to not have /home or whatever important on it)
<\sh> amitk: and asked here...but nobody had problems at this time...
<\sh> amitk: what I did was creating a new volume group on /dev/cciss/c0d0p9 + adding some logica volumes, adding them (xfs fs) to fstab and hit reboot...machine came up and was "waiting...."
<amitk> \sh: sounds like what I did. Added a new VG, some LVs, formatted them and added them to /etc/fstab with the right /dev/mapper/foo paths
<\sh> amitk: well I used /dev/<vg identifier>/<lv identifier> same thing....
<\sh> amitk: funny part, I did a reinstall, d-i partitioner got the vg device and failed somehow...I didn't check the logfiles (my bad) because I had no time...needed to bring the machine up and running
<\sh> ah it failed installing grub at the end of reinstall...neither adding (hd0) manually helped here
 * pitti yays the "upgrade branch" button in LP
<nicknewbie> http://pastie.org/859350 -- This is a multiwan script I'm working on, based on the info on this page http://lartc.org/howto/lartc.rpdb.multiple-links.html -- I'm trying to take these instructions, and turn them into a script that can just be edited with the right variables to give multiwan setup. I think it would be good for the community, but I do need some help, can someone take a quick look?
<apw> TheMuso, just a heads up we have a new kernel abi
<pedro_> pitti, hello! may you please have a look into bug 532924 later?
<ubottu> Launchpad bug 532924 in tzdata "Chilean timezone extraordinary change" [Undecided,New] https://launchpad.net/bugs/532924
<pitti> hey pedro_
<pitti> pedro_: argh timing -- I just did a tzdata update for all stables yesterday
<pitti> pedro_: sure, I'll look at it; I'll contact upstream first, to coordinate a patch
<pedro_> pitti, thanks a lot!
<pitti> pedro_: ah, upstream is aware -- http://article.gmane.org/gmane.comp.time.tz/3124
<pedro_> \o/ awesome
<nicknewbie> http://pastie.org/859350 -- This is a multiwan bash script I'm working on, based on the info on this page http://lartc.org/howto/lartc.rpdb.multiple-links.html -- I'm trying to take these instructions, and turn them into a script that can just be edited with the right variables to give multiwan setup. I think it would be good for the community, but I do need some help, can someone take a quick look? #mwan-script
<nicknewbie> OH??!
<jarnos>  My remote control stopped working, after I upgraded to 9.10. I hope my remote control (= vlsystem mplay mini) works in 10.4 again.
<nicknewbie> Is this channel for people developing ubuntu, or developing ON ubuntu!?
<asac> nicknewbie: the first
<jarnos> Also it would be nice, if my tv-tuner would work in 10.4: http://ubuntuforums.org/showthread.php?t=1420878
<jdstrand> ScottK: please see my email to you and cemc and also the different bug #533423 regarding the recent clamav update
<ubottu> Launchpad bug 533423 in clamav "package clamav 0.95.3 dfsg-1ubuntu0.09.04~hardy2.2 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/533423
<nicknewbie> asac, Oh right! that would explain why a lof of questions don't get answered!
<nicknewbie> because they are not the right ones. -- Guys, I'll go track down the right room!
<asac> ack
<persia> For the reference of anyone answering questions like nicknewbie's, there's the shiny new #ubuntu-app-deve;
<persia> Err, #ubuntu-app-devel
<asac> gtk
<asac> maybe we hsould include that in the /topic part that deals with this?
<asac> persia: ?
<persia> I did a few weeks back :)
<asac> hmm
<asac> hehe
<asac> ok Development of Ubuntu (not support, not app development)
<asac> made me stop reading
<persia> RIght before the pointers for support & app development :)
<pitti> Riddell: kdeedu currently b-deps on libreadline5-dev, but should b-dep on libreadline-dev (to build against libreadline6); I can't commit to the branch; want me to upload and propose a merge, or do you want to "just do" it?
<Riddell> pitti: I can do it
<pitti> Riddell: cheers
<pitti> Riddell: want a bug for it?
<Riddell> pitti: no thanks
 * pitti uploads transitions for the other 5ish packages
<pitti> robbiew_: can you please take a look at/approve https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages?
<mdeslaur> seb128: I've built test packages that backport GtkStatusIcon support into the liferea and pidgin versions we have in Lucid in order to fix the tray icons not being transparent with the new themes. (see bugs 529375 and 191980)
<ubottu> Launchpad bug 529375 in pidgin "pidgin doesn't use theme background colour in notification area applet" [Undecided,Confirmed] https://launchpad.net/bugs/529375
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/191980)
<mdeslaur> sorry, bug 101980
<ubottu> Launchpad bug 101980 in liferea "liferea icon in notification-area not transparent when showing number of new items" [Low,Triaged] https://launchpad.net/bugs/101980
<mdeslaur> seb128: what would you think about this going into lucid?
<seb128> mdeslaur, would be nice to have indeed
<seb128> mdeslaur, feel free to upload
<mdeslaur> cool, thanks seb128
<pitti> Riddell: thanks; I did the other uploads, so another duplicate library bites the dust \o/
<sebner> pitti: something interesting; 2 days ago I attached my external harddrive and nothing happened (as I told you once) then I unplugged it, started ubuntu-bug storage, plugged it in again and it worked ..
<Riddell> pitti: awooga
<pitti> sebner: I sometimes get a similar effect as well, I'll debug that on my devices here
<pitti> Riddell: saves you a whopping 147 kB :)
<sebner> pitti: cool, just wanted to let you know :)
<amitk> cjwatson: how do feel about turning on dpms on all virtual consoles (/etc/kbd/config)?
<mdeslaur> pitti, seb128: I get that also with my kindle
<pitti> mdeslaur: same for my sony ebook
<cjwatson> amitk: no opinion
 * pitti thinks mdeslaur meant sebner, not seb128
<seb128> right
<mdeslaur> oh, right, darn autocompletion :)
<sebner> mdeslaur: pretty annoying, isn't it?
<mdeslaur> sebner: it's only annoying when it gets it wrong :)
<sebner> mdeslaur: heh
<Riddell> pitti: for my work item on https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages shouldn't it be marked postponed due to lsb requirements?
<pitti> Riddell: oh, if the decision is made to keep it, then the "decide.." is DONE
<bdrung> bryceh: do you have time to sponsor bug #534026?
<ubottu> Launchpad bug 534026 in xserver-xorg-video-ati "Please merge xserver-xorg-video-ati 1:6.12.191-1 (main) from Debian experimental (main)." [Undecided,Confirmed] https://launchpad.net/bugs/534026
<pitti> Riddell: so we're going to keep it then?
<Riddell> pitti: I assume we want to stay within LSB
<pitti> Riddell: agree
<Riddell> pitti: and I don't see a point in getting rid of the bindings in that case, it's just deviation from Debian
<pitti> Riddell: agreed; I updated the spec
<Riddell> thanks
<pitti> thanks to you
 * _UsUrPeR_ tips his hat
<_UsUrPeR_> I would like some help with preseeding. Could somebody take a look at my preseed.conf and tell me what I am doing wrong please?
<cjwatson> sure
<_UsUrPeR_> it's here: http://pastebin.com/QPhxM4MB
<_UsUrPeR_> cjohnston: for some reason, I cannot get this to partition an LVM correctly
<cjwatson> I'm cjwatson not cjohnston; careful with that tab-completion :)
<cjwatson> can I also see the syslog and partman logs from the installer, please?
<_UsUrPeR_> cjwatson: right now, with the current configuration, it makes a boot partition, a single LVM, and a root directory inside the LVM.
<_UsUrPeR_> hah. whoops
<_UsUrPeR_> sorry mr. johnston
<_UsUrPeR_> cjwatson: can I get back to you with those in a bit? I need to re-run the installation with the seed I sent you.
<robbiew> pitti: https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-duplicated-packages has been approved ;)
<pitti> robbiew: schweet
<pitti> robbiew: that was a hard debate :-P
<robbiew> lol
<cjwatson> _UsUrPeR_: at a first glance, I think you should remove $lvmok{ } from /boot (assuming that you don't want it to be a logical volume?) and add $defaultignore{ } to the other partitions you want to be LVs as well as /
 * _UsUrPeR_ follows advise
<cjwatson> that may not be enough though - logs may help
<cjwatson> I think that will probably amount to tidying up rather than actually fixing your problem, although I always have to look up the exact semantics of $defaultignore{ } and friends
<_UsUrPeR_> cjwatson: ok, I'm running through an install with the new settings now
<_UsUrPeR_> I'll get the logs as soon as the installation is complete
<cjwatson> ok
<mpt> ev, https://bugzilla.gnome.org/show_bug.cgi?id=99604#c7
<ubottu> Gnome bug 99604 in general "Better abbreviation of titles when space is tight" [Enhancement,Reopened]
<pitti> ttx: thanks for the asm research
<ttx> pitti: easy one, I already did it :)
<pitti> yep, just saw
<ttx> pitti: the goal is to demote to universe, or get rid of them ?
<pitti> ttx: primarily, universe
<pitti> if we can remove any of those completely, bonus of course
<pitti> ttx: any hope for the three servlet APIs?
<ttx> pitti: There is some concerted effort between ubuntu and debian java to get rid completely of 2.3 and 2.4, but it's blocking on some packages (struts for 2.3, eclipse for 2.4)
<ttx> however, keeping them out of main might be doable
<ttx> (especially 2.3)
<pitti> ttx: if we can migrate away at least some, then this would at least help with bug fixing (you need to fix bugs in just one place, not three)
<pitti> so there's some benefit even if there's one remaining sucker package which needs the old API still :)
<ttx> pitti: that was the original goal of https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-java-library-fixes
<pitti> ttx: dom4j is pretty strange though
<kirkland> pitti: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
<ttx> pitti: java is strange, in general.
<pitti> ttx: ah, good; if that one has WIs for the same issue, please feel to drop the ones from the lucid-dups spec
<ttx> pitti: no, I missed a few targets, so it's in addition to that spec (which is complete)
<pitti> kirkland: pah -- I'll catch you again!
<kirkland> pitti: hehe :-)
<ttx> pitti: you can't win, eucalyptus is a unlimited source of bugs.
<pitti> heh
<mvo> tseliot: I get a fsck while plymouth is running - all I see on the screen is a big [C] in the center. is this a known bug? are you the right person to ask?
<tseliot> mvo: what graphics driver are you using?
<mvo> tseliot: this time I booted with nofb, before I was using nouveau but only got a blank screen
<mvo> tseliot: I also have a flickering  bar (in ascii)
<tseliot> mvo: I guess this time you used the text plugin
<mvo> right, but shouldn't it show me something else in addition to the [C] ?
<tseliot> Keybuk: ^^
<Keybuk> mvo: yes, eventually ;)
<mvo> Keybuk: aha, known issue? thats fine then
 * tseliot 's theme is supposed to work with drm renderers
<Keybuk> tseliot: sounds like he's got the text plugin
<tseliot> right
 * mvo waits until the fsck finishes
<tseliot> which is why I asked you
<Riddell> ev: any plans to review shtylman's ubiquity changes?
<sebner> tseliot: btw, using the actual nvidia driver it's ~1-2Â° hotter than usual but nothing serious. + I heard you are working also for a nice booting experience for nvidia driver users ;D
<pitti> james_w: ok to flush your redntoebook sync?
<pitti> james_w: (I have another sync I need to do)
<shtylman> Riddell: I think he has reviewed them... just not merged yet? <-- ev
<tseliot> sebner: yes, I'm working on it. It should be 16 colours though
<james_w> pitti: I was in the middle of a mass-sync but LP is broken
<james_w> pitti: so, fine
<sebner> tseliot: wondering what level of "nice" that'll be ^_^
<tseliot> sebner: better than ascii
<tseliot> ;)
<sebner> tseliot: that certainly nice but we live in 2010 :P
<tseliot> right and drivers use KMS now...
<Keybuk> sebner: get a graphics card supported by free software then
<sebner> tseliot: plymouth and that stuff should have used technologies that also 3D blob drivers can use
 * sebner is afraid of Keybuk and hides :P
<tseliot> sebner: you can always use vesafb or some other module if you want more colours
<Keybuk> (and don't want suspend/resume :P)
<Keybuk> tseliot: I wonder why the nvidia blob doesn't provide a framebuffer
<sebner> it seems either way a lot stuff is b0rken on linux
<tseliot> Keybuk: who needs suspend/resume anyway :-P ?
<sebner> tseliot++
 * sebner doesn't use it
<sebner> also hibernate takes longer than a reboot :P
<_UsUrPeR_> cjwatson: the changes appear to have worked! :D
<cjwatson> _UsUrPeR_: cool
<_UsUrPeR_> It seemed that $defaultignore { } would ignore lvm settings, but it's the opposite. I had read over preseeding docs a few times, and I guess I never grasped the concept :/
<_UsUrPeR_> cjwatson: thanks for your help.
<cjwatson> _UsUrPeR_: the naming is definitely suboptimal.  glad to help
<_UsUrPeR_> cjwatson: one question though: My partitions were created strangely. I had specified the max for swap to be 300% (Of total RAM, if I read the docs correctly), but the swap partition was created as 122 gigs.
<_UsUrPeR_> cjwatson: while the /home directory was created with 10 gigs.
<_UsUrPeR_> how did swap exceed the RAM count by almost 110 gigs? :)
<cjwatson> that's almost certainly a bug, but you might try making the swap partition not the last one in the recipe
<cjwatson> oh, or alternatively
<cjwatson> set bigger weights (second field) for the partitions you want to grow more
<cjwatson> you probably want /home's priority/weight to be rather closer to the maximum size than the minimum size
<_UsUrPeR_> cjwatson: Yeah, I just hard-coded the swap partition's max, and added another 0 to /home
<_UsUrPeR_> which would put it around 100 gigs :)
 * _UsUrPeR_ looks for a preseed project on launchpad
<cjwatson> the maximum isn't so important in this case (you already have it set to a terabyte).  worry about the priority
<cjwatson> you don't want the preseed project on launchpad
<_UsUrPeR_> ok
<cjwatson> if you're looking to file a bug report, it would go on the partman-auto package in Ubuntu
<_UsUrPeR_> cjwatson: ahh. ok, cool. thanks for the pointer
<chrisccoulson> hi doko, i'm trying to investigate an openjdk-6 build failure as part of the xulrunner-1.9.2 migration, and wondered if you had any pointers to what might be going wrong?
<chrisccoulson> the build log is here: http://launchpadlibrarian.net/40287073/buildlog_ubuntu-lucid-amd64.openjdk-6_6b18~pre1-1ubuntu1.0ffox36.1_FAILEDTOBUILD.txt.gz
<chrisccoulson> and i can also recreate the issue with the current version in the archive with the current xulrunner version too
<doko> chrisccoulson: ENOCLUE. are there other packages in the ppa? : Unknown command line argument '-mcpu=k8-sse3'.  Try: ' -help'
<chrisccoulson> doko - my local uild environment isn't pulling in any PPA packages
<chrisccoulson> s/uild/build
<chrisccoulson> doko - I've still got a shell open in the broken build environment, and if I call "./gamm" (with no arguments), I get the same error
<chrisccoulson> sorry, i meant "./gamma"
<chrisccoulson> (keep missing keys today)
<doko> chrisccoulson: and does strings ./gamma |grep mcpu show something?
<chrisccoulson> doko - it doesn't show anything
<doko> chrisccoulson: please try stracing ./gamma
<chrisccoulson> doko - http://paste.ubuntu.com/391125/
<doko> chrisccoulson: no clue yet; maybe search the string in the linked libs? in the Makefile/config.status?
<chrisccoulson> doko - will do. thanks
 * pitti hugs mvo -- my  hero!
<mvo> heh .) thanks pitti
<mvo> only a small contribution
<pitti> mvo: I'll change g-p-extras to drop python-gtkhtml2 then
<pitti> ah, oops
<pitti> a handful of universe packages needs it as well
<pitti> hmm
<pitti> but nothing too interesting
<pitti> mvo: gnome-app-install is the only interesting universe package which still uses it
<pitti> mvo: but in the light of software-center (which is like its successor), shoudl we even keep that one?
<mvo> pitti: I can port that too
<juliank> pitti, mvo: How about dropping gnome-app-install; I've already done it in Debian.
<pitti> if we can just remove it, that would be even easier
<pitti> juliank: my thought
<mvo> yeah, the only reason to keep it is that the a11y is better than in software-center
<pitti> s-c FTW :)
<mvo> but its now pretty much unmaintained :)
<pitti> right
<mvo> so better fix s-c
<pitti> or use apt-get install.. :)
<mvo> heh :)
 * pitti removes
<juliank> mvo: pochu said for the Debian package we should be thinking about a transitional package (aka http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572941); maybe the same for the Ubuntu one?
<ubottu> Debian bug 572941 in software-center "software-center: Please build a gnome-app-install transitional package" [Normal,Open]
<pitti> yes, that'd make sense
 * mvo nods
<juliank> mvo: When you add one, could you add a 'Closes: #572941' for the Debian bug, to make this close automatically when I backmerge it into Debian.
<mvo> juliank: sure
<mvo> juliank: commited as r637
<mvo> juliank: it uses "section: transitional" so that apt does not mark s-c as auto-installed
<pitti> mvo: oh, that exists now? I still use "oldlibs" for those
<mvo> pitti: well, not officiallyâ¦
<pitti> mvo: does it check for oldlibs as well?
<mvo> pitti: but I think it really should be there so that the automatic install magic can be prevented, otherwise gnome-app-install -> software-center will mark software-center as auto installed
<mvo> pitti: hm, good point about oldlibs
<mvo> pitti: it seems like nowdays its pretty much only used for transtional package, I guess I should use that instead
<mvo> pitti: what do you think?
<pitti> mvo: you could check for both
 * mvo nods
<geser> doko: do we keep python3.0 for lucid or is it planned to get removed before release?
<doko> geser: remove definitely. could you care about it?
<geser> doko: sure, will file a removal bug
<geser> cjwatson: thanks for sponsoring the vim merge
<cjwatson> that's ok - I looked through it and agreed there didn't seem to be a need for an FFE given the nature of the changes
<kasi> does anyone know whether apache 2.2.12-1ubuntu is affected by this? http://www.senseofsecurity.com.au/advisories/SOS-10-002
<mdeslaur> kasi: only on windows, so, no
<kasi> oops. my bad.
<kasi> thanks
 * kasi stands ashamed in a corner and things of the common saying "reading helps".
<cjwatson> geser: can you see why it fails to build on i386?  the log is uninformative, and I had test-built it locally already.  http://launchpadlibrarian.net/40508406/buildlog_ubuntu-lucid-i386.vim_2%3A7.2.330-1ubuntu1_FAILEDTOBUILD.txt.gz
<cjwatson> geser: oh, maybe needs rm -f?
<cjwatson> except I can't see where that rm is being called, maybe internal to make?
<cjwatson> or parallelisation or something?
<cjwatson> I think that rm is internal for intermediate files, and it's in fact more closely equivalent to rm -f; it ignores ENOENT, at any rate
<_UsUrPeR_> cjwatson: I have one more question about preseeding. I am attempting to create a seed that partitions in LVM (works! thanks :D), and am also trying to have all the packages for LTSP installed + build an LTSP image. I attempted to use the LTSP preseed (on the installation CD) as an example, but it does not appear to be building a client image like I had expected.
<cjwatson> _UsUrPeR_: I'll need syslog again
<cjwatson> ltsp is not really my area but I can have a look
<_UsUrPeR_> cjwatson: ok. I'll get that for you now. Here's my present preseed: http://pastebin.com/i0mJ9BSe
<_UsUrPeR_> cjwatson: the commands for building/installing ltsp are at the bottom of the .seed
 * _UsUrPeR_ goes to get the syslog post-install
<cjwatson> looks ok on the face of it
<_UsUrPeR_> cjwatson: here's the syslog post-install: http://pastebin.com/w2b4xZ31
<cjwatson> no, that's not the one I need - it winds up in /var/log/installer/syslog post-install
<cjwatson> (dinner, back later)
<mterry> ccheney, you recently updated the openoffice.org thesauruses to not depend on language-support-writing-*.  Now language-support-writing-* packages pull in all of OO.o.  Was that intended?
<_UsUrPeR_> cjwatson: ok, here's the correct log (sorry I sent you the wrong one before): http://pastebin.com/neVSXq1M
<ccheney> mterry: yes and no, i will be fixing it soon again, there was a misunderstanding that all language-support-* was going away when it was only language-support-translations-*
<geser> cjwatson: I assume too that it's because of parallel building as the log contains "*** DEBIAN *** CONFIGURING VARIANT vim-tiny" directly followed by "*** DEBIAN *** CONFIGURING VARIANT vim-gtk"
<ccheney> mterry: or something to that effect
<mterry> ccheney, ah, cool.  Thanks!
<geser> cjwatson: I could reproduce the problem with DEB_BUILD_OPTIONS="parallel=2" inside my pbuilder
<lamalex> Hey sponsors, can someone (when they get a moment) take a look at https://code.edge.launchpad.net/~alexlauni/ubuntu/lucid/gnome-power-manager/gpm-fix-530751/+merge/20920 ? fixes another g-p-m papercut
<chrisccoulson> lamalex, the gpm fix should wait really, as I'll have some other fixes to upload this week
<shtylman> is the latest kernel (16) giving anyone problems with the nvidia-current drivers?
<lamalex> chrisccoulson, right on
<chrisccoulson> lamalex, and we're in to UI freeze now, we really should stop making string changes
<chrisccoulson> they break translations
<chrisccoulson> so the translation team needs to be notified really
<Riddell> mvo: I just added this to packagekit http://people.canonical.com/~jriddell/tmp/fix_upgrade_distro.diff and put update-manager-kde back into main with kpackagekit depending on it
<Riddell> just FYI
<lamalex> we're not far into UI freeze.. so merge soon! it seems odd that we'd break our own notify-osd spec
<chrisccoulson> lamalex, being "not far in to UI freeze" isn't a good excuse for breaking it
<chrisccoulson> if it was ok, then we'd shift UI freeze back a few days
<mvo> Riddell: nice, thanks
<cjwatson> geser: so we should just disable parallel building?
<cjwatson> _UsUrPeR_: try putting anna/choose_modules=ltsp-client-builder on the kernel command line
<_UsUrPeR_> cjwatson: rgr. Uno momento
<sebner> sebner: " - Put tabs at the top again" *WUHUHUHUUUUUUHUHH*
<sebner> urgh. /me seems to be egocentric xD
<_UsUrPeR_> cjohnston: command not found.
<_UsUrPeR_> fuuu
<_UsUrPeR_> cjwatson: ^^^
<_UsUrPeR_> mr. johnston: again, I apologize
<_UsUrPeR_> cjwatson: hmm. I know that the LTSP build in 9.10 alternate works when run from a normal CD.
<_UsUrPeR_> cjwatson: Where is that command stored? :/
<geser> cjwatson: unless you know how to debug this (I don't), commenting out line 32 in debian/rules seems to be sufficient to disable the parallel build and make the package build
<cjwatson> _UsUrPeR_: um, what command
<cjwatson> ?
<_UsUrPeR_> d'oh type. Let me try that again
<cjwatson> _UsUrPeR_: what I mean is to append that string as a kernel parameter
<_UsUrPeR_> cjwatson: ahh. Will do.
<geser> cjwatson: and I couldn't find yet the change between the recent rebuild upload and the merge which explains the problem as the previous version supported parallel building too
 * _UsUrPeR_ makes the seed changes
<cjwatson> geser: right, I can't see anything relevant either.  can you give me a branch?
<_UsUrPeR_> cjwatson: so that will replace the following command already in the preseed: "d-i     anna/choose_modules     string ltsp-client-builder"
<_UsUrPeR_> is that correct?
<cjwatson> it should not go in the preseed file
<shtylman> bug #534469 is hot :)
<cjwatson> it's a kernel parameter
<ubottu> Launchpad bug 534469 in nvidia-graphics-drivers "Failed To Load NVIDIA 195.36.08 Kernel modules" [Undecided,New] https://launchpad.net/bugs/534469
<_UsUrPeR_> cjwatson: oh. My apologies. How/where should I input that change? I am not sure where I would add that.
<Chipzz> grub
<Chipzz> pxelinux
<Chipzz> isolinux
<Chipzz> pick one :P
 * _UsUrPeR_ points ant himself and mouths "me?"
<cjwatson> _UsUrPeR_: usually goes in pxelinux.cfg, on the append line
<cjwatson> you should have something like url=http://url/of/your/preseed/file there already
<_UsUrPeR_> ahh! Ok, I gotcha. That would be in /syslinux/text.cfg on the edited menu system I set up to run the preseed, then.
<_UsUrPeR_> ok, so here's what I have for the menu.txt right now: http://pastebin.com/QK0AtRF7
<_UsUrPeR_> this is run upon boot
<_UsUrPeR_> I just added that parameter to the end
<geser> cjwatson: https://code.edge.launchpad.net/~geser/ubuntu/lucid/vim/disable-parallel-building/+merge/20925
<mvo> Riddell: if you have nothing else pending I will upload update-manager now
<ScottK> mvo: I don't suppose you'll have any time to squeeze the backports not-automatic fixes ....
<cjwatson> _UsUrPeR_: looks fine.  you can shorten debian-installer/locale= to locale= if you like
<_UsUrPeR_> oh nice. I'll do that later. Thanks for the pointers. I'm running the installation process now.
<jbebel> apw, are you aware of bug 534635
<ubottu> Launchpad bug 534635 in linux "linux-image-2.6.32-16-generic depends on linux-tools which is not in main" [Undecided,New] https://launchpad.net/bugs/534635
<TheMuso> apw: I know.
<apw> jbebel, hrm ... no, thanks
<sits> can someone say if https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/532095 really is an upstream issue?
<ubottu> Launchpad bug 532095 in gnome-media "Changing left/right balance in sound-preferences changes the output volume slider" [Low,Confirmed]
<Beaver> www.search2.net (new search engine)
<rurti> hello
<rurti> is anyone here available to help me with a problem, i have already been on the #ubuntu,  #ubuntu-desktop and #channels and then was finally directed here
<rurti> what i am trying to do is to add my own dir to the PATH variable, i put it in the .profile file however applications like gedit do not see the bin when execute the make within it.
<kirkland> jcastro: yo
<kirkland> jcastro: tell me about your experience with Bug 530289
<ubottu> Launchpad bug 530289 in testdrive "ERROR: You must have either /usr/bin/kvm or /usr/bin/VBoxManage installed" [Low,Incomplete] https://launchpad.net/bugs/530289
<jcastro> kirkland: sure, so I did a reinstall on this machine
<jcastro> and then wanted to test something
<jcastro> kirkland: after it installed I tried to fire it up, but it told me kvm was busted, so I modprobed like it said
<jcastro> but I didn't do "kvm_intel" just "kvm"
<rurti> is there anyone here that can help me with this problem/
<rurti> ?
<jcastro> kirkland: I think for me it was just user error
<jcastro> kirkland: I assumed modprobing kvm would take care of the right bits
<kirkland> jcastro: gotcha; okay, i'm going to fix this in kvm-ok with better instructions
<kirkland> jcastro: thanks!
<kirkland> jcastro: sorry about that
<jcastro> kirkland: no worries, I was using it to test for something else so glad I found it!
<rurti> jcastro may i bother you for a moment please?
<jcastro> rurti: you're probably better off on a mailing list
 * jcastro can't remember the last time he messed with PATH
<rurti> jcastro: what mailing list should post this on?
<jcastro> rurti: ubuntu-users most likely
<jcastro> http://lists.ubuntu.com
<rurti> jcasstro: thank your very much for your advice.
<jcastro> good luck!
<kirkland> rurti: have you logged out and back in?
<Riddell> ev: not merging roman's ubiquity branch?
<rurti> kirkland: yes i have, it shows up in the terminal fine, however when apps like gnome execute it i know see the parameters et by ENV_PATH in /etc/login.defs
<kirkland> rurti: you're going to need to ask one of the desktop guys about that ...  pitti, seb128: how does a user affect their $PATH env within Gnome?
<seb128> kirkland, I don't know
<seb128> I told him to ask there that might somebody would know
<kirkland> seb128: there = here?
<seb128> I would have changed it in profile or gnomerc
<seb128> but apparently that doesn't work
<rurti> kirkland: i was just talking with seb128 he told me to come here
<seb128> kirkland, he asked in #ubuntu-desktop first and I bounced him to #ubuntu-devel
<kirkland> seb128: okay, hrm, interesting
<seb128> not sure why changing .profile doesn't work
<kirkland> rurti: ls -alF /etc/profile.d
<rurti> yes it is an interesting problem in deed
<persia> Does ${foo}-session source .profile?  I thought such variables had to be set in the Xsession files or ${foo}-session specific files.
<chrisccoulson> for changing $PATH, i normally define it in /etc/environment
<rurti> kirkland: trying it one second
<persia> chrisccoulson: That's a big hammer.
<rurti> Kirkland: there is nothing in there
<seb128> rurti, changing /etc/environment should work
<kirkland> persia: agreed, and requires admin privilege
<rurti> seb128: that will change it for all accounts though wont it?
<seb128> rurti, yes
<rurti> seb128: i guess we cannot change it just for one profile?
<chrisccoulson> i'm not sure of any other way of doing it, which is picked up in the enviorment of the various session components
<persia> kirkland: For ~/.Xsession ?
<kirkland> hrm, you know, i've gotten a strange byobu bug report recently, about .profile settings not being respected ....
<kirkland> persia: i was supporting your "big hammer" comment
<persia> Oh yeah.
<seb128> kirkland, he's using hardy not lucid and other env variable are set correctly it's only a path issue
<kirkland> seb128: ah, okay
<seb128> rurti, change the launcher to the application you want to start this way by a wrapper?
<seb128> rurti, ie a small script setting path and running the binary
<chrisccoulson> which application has the wrong $PATH?
<chrisccoulson> and how is it launched?
<rurti> seb128: I am thinking that may have to be the route i go.
<rurti> seb128: i could change the commands to go "setToolEnv; make all"
<rurti> just some people use different tools
<rurti> i was hoping that the path could make it happen for all apps
<rurti> sorry .profile not path
<cjwatson> I believe you can edit .pam_environment and that'll apply to all PAM sessions
<cjwatson> same format as /etc/environment
<cjwatson> note that it is not a shell script, it's just KEY=VALUE, so don't expect e.g. shell variable expansions to work
<cjwatson> though I think you can substitute environment variables with ${var}, according to /usr/share/doc/libpam-doc/html/sag-pam_env.html
<cjwatson> ... actually skip that last part, misreading
<rurti> ok
<rurti> one quick question, is /etc/environment a regular script file?
<psusi> TheMuso, ping
<TheMuso> psusi: Just ask your question/make your statement, and I'll respond when I get to it, but yes, I am around now. Whats up?
<psusi> TheMuso, cool... long time no see... been tracking down a dmraid bug in Karmic and I finally found the problem and was wondering if I could get your opinion on what the solution should be
<psusi> it seems dmraid is causing a udev event feedback loop in Karmic... my first thought was to change the udev rule to only activate on add events, not change events as well
<psusi> but I'm not sure if that could have other consequences
<TheMuso> psusi: Hrm. I guess the whole change events would only be an issue for externally connected disks. Have you checked to see whether anyone using Debian are also experiencing this bug?
#ubuntu-devel 2010-03-09
<psusi> no, it's an issue for internal disks too... see what happens is udev runs dmraid-activate which runs dmraid with the -Z switch to delete the kernel partition table from the underlying physical disks, so that you no longer see an /dev/sda1
<TheMuso> right
<psusi> and this causes a change event... I'm not sure why but in 9.10 it only makes a change event on the device being processed, so while processing the add for sda, it makes  change only for sda, which it seems udev is smart enough not to recursively process
<TheMuso> ah ok
<psusi> but in Karmic it causes a change event for sdb as well, which in turn causes dmraid-activate sdb to be called, which changes sda, and so on
<psusi> my guess is there was an upstream bug that got fixed in dmraid where it used to only apply the -Z to the device it was passed, and now it applies to all the underlying devices in the set being activated
<rurti> seb128: putting it /etc/environment didn't work, i had to back out the changes in terminal mode, I am just going to do the script; should i possibly add this as a bug?
<psusi> so do you think just dropping the |change part from the udev rule would do the trick, or are there other changes that should trigger an activate?
<seb128> no idea but I guess it's not a bug no
<rurti> seb128: design flaw?
<seb128> dunno
<cjwatson> rurti: /etc/environment is KEY=VALUE as well, not a shell script
<seb128> enough for today anyway, good night everybody
<rurti> cjwatson: can i use other variables in it like a script, ie: path=$ToolDir/tool1/bin
<cjwatson> as I think I said above: no.
<TheMuso> psusi: yes sounds sane.
<rurti> cjwatson: thanks, for the information.  I will have to think this over a bit, without the scripting variables it means i have to rethink where i put the tools, as well as whom has access.  I suppose i could add a dev group who is the only one with access to them.
<cjwatson> there are other less elegant ways to do it, usually involving a single (shell-script-format) file that you source from multiple places, such as .bash_profile and .xsession
<rurti> cjwatson: .bash_profile does not exist and i put it in .profile but that does not get run for apps.  As for .xsessions is that run at login?
<cjwatson> the fact that .bash_profile does not exist by default does not mean that it isn't read if it exist.  Please read the bash(1) manual page for specific information
<cjwatson> .xsession (no trailing s) is sourced as part of standard X session startup
<cjwatson> .bash_profile is not sourced until you start an interactive login shell
<rurti> cjwatson: is .bash_profile any different from .profile?
<cjwatson> read the manual page
<cjwatson> it's just bash-specific - you can use either, and they're sourced at around the same place
<cjwatson> you may also need to get .bashrc to read the file in question
<cjwatson> personally, I have my .bash_profile do little else apart from read .bashrc, and in fact that appears to be how we ship .profile by default these days
<rurti> cjwatson: well i know that putting it in .profile does not work. and putting it in .bashrc only works if opening a terminal window.
<cjwatson> .profile does work, just not for things that are spawned without going through an interactive login shell!
<cjwatson> what I'm telling you is that there is no one place (other than .pam_environment) where you can put this change without having to change multiple files!
<cjwatson> this is unfortunate
<cjwatson> but in order to cover all the bases, you need to arrange for the variable to be set from both .bashrc and .xsession
<cjwatson> (I think I've got the file names right, stuff changes from time to time, adjust to taste)
<rurti> cjwatson: so putting the script lines in .xsession and .profile should cover it?  also is there a way to change how an app spawns?
<cjwatson> .xsession and .bashrc
<rurti> ok
<cjwatson> and check that .profile sources .bashrc
<cjwatson> "change how an app spawns"?  BTW this is getting well off-topic for #-devel
<rurti> cjwatson: yes .profile does source .bashrc i know that.
<rurti> cjwatson: its ok ill not bother you anymore ill check into the information you have given me and try some things out then come back to irc if i need more help.
<rurti> thanks for the help guys :)
<cjwatson> I suggest that #ubuntu would be better for future questions
<cjwatson> this isn't really a development topic
<rurti> cjwatson: thats where i started, then they sent me to #bash, whom sent me to #ubuntu-desktop, whom sent me here.
<cjwatson> grrr
<rurti> sorry
<cjwatson> boo @ #ubuntu-desktop, that was inappropriate IMO
<cjwatson> not your fault if you were told that
<rurti> yea unfortunately no one has the answer i need lol, may i add some times gui's are a pain
<rurti> thanks anyway for the help
<rurti> i will take a look at .session
<rurti> sorry .xsession
<chrisccoulson> doko - FYI, it seems to be the latest version of llvm which breaks the openjdk-6 build
<chrisccoulson> the current version of openjdk-6 in the archive is not built with the latest version of llvm
<chrisccoulson> heh, i see you've just uploaded another new version of that too
<lamalex> is cowbuilder-dist broken in lucid? I'm getting tons of errors  like cp: cannot create link `/var/cache/pbuilder/build//cow.14578/lib/libnss_files.so.2': Invalid cross-device link
<slangasek> cjwatson: syncing pinyin-database 1.2.99-3 from unstable, per the discussion last night (looks like cjohnston struck again :-)
<cjwatson> oh yes, thanks
<cjwatson> I did actually see it, but forgot
<cjwatson> will you also deal with main promotion now that pitti's objection in the MIR bug is resolveD?
<cjwatson> resolved
<slangasek> cjwatson: how was it resolved? I don't see the resolution mentioned in the bug
<cjwatson> the problem was that ibus-pinyin was depending on pinyin-database but not appearing to actually use it, because the dangling symlink it shipped wasn't actually pointing to anything in the pinyin-database package
<cjwatson> (there was also some confusion about build-dependencies - from a casual grep it *looked* as though ibus-pinyin was using pinyin-database at build-time, although it wasn't actually)
<cjwatson> now, pinyin-database ships the file that's the target of the symlink in ibus-pinyin-db-open-phrase
<slangasek> hmm - I understood pitti's objection as "described as a build-dep, not a runtime dep, do we want 10MB more on the dVD"
<cjwatson> so the dependency is correct
<cjwatson> my understanding was that he didn't want 10mb more on the dvd without this confusion being resolvd
<slangasek> oh, no, I see what he's said
<cjwatson> *resolved
<slangasek> ack, will promote
<cjwatson> but I'm happy to wait until tomorrow morning and ask him
<cjwatson> there doesn't appear to be much of a compilation step, so if we're short on space then the question needs to become whether we want ibus-pinyin-db-open-phrase or not, rather than whether we want pinyin-database or not, IYSWIM
<cjwatson> ibus-pinyin-db-open-phrase is non-functional without pinyin-database
<slangasek> right
<poolie> superm1: hi, in the tip of usb-creator trunk it still seems to prefer a local cd device to the specified ios
<poolie> therefore i think hiding the list would be bad
<superm1> poolie, local cd device?
<superm1> i didn't realize that's even an option.  i thought it only populated ~/Downloads ?
<poolie> it does
<poolie> that's the problem in bug 477529 that i was trying to fix
<ubottu> Launchpad bug 477529 in usb-creator "Fails with uncaught exception "No such file or directory"" [Undecided,In progress] https://launchpad.net/bugs/477529
<superm1> interesting.
<poolie> this little sandisk device pretends to also have a usb cd drive
<poolie> containing win32 stuff
<poolie> superm1: istm that if --iso is given, we want to absolutely force the iso to be taken from that value
<poolie> and avoid this whole messy issue of trying to force that list to have the right value selected
<superm1> yes
<poolie> superm1: you can probably reproduce this yourself by having a cd mounted when you run the program
<superm1> poolie, great.  i'll take a look this week and see if I can
<superm1> i'll hold off reverting the GUI to be hidden until I can sort that out
<poolie> yeah, my fix is very far from ideal, but at least it makes the error a bit less confusing
<poolie> but i had a train to catch
<poolie> and just haven't come back to it since then
<smoser> slangasek, finally bug 532682 was fixed, which allowed me to try the old upstart.  reverting from 0.6.5-4 ro 0.6.5-3 made me unable to reproduce bug 531494
<ubottu> Launchpad bug 532682 in eucalyptus "instance stays in pending for > 1 hour, then to terminated" [Undecided,Fix committed] https://launchpad.net/bugs/532682
<ubottu> Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Critical,New] https://launchpad.net/bugs/531494
<ScottK> doko: Would you please look at Bug 525547 and let us know what you think?
<ubottu> Launchpad bug 525547 in ironpython "[FFe] for dlr-languages sync from Debian NEW" [Undecided,New] https://launchpad.net/bugs/525547
<pitti> Good morning
<pitti> cjwatson, slangasek: thanks for resolving the ibus-pinyin-db; if that's the actual runtime data file, it's fine of course; it just was described differently, so I didn't want to spend the space for an useless dependency (which it isn't apparently)
<pitti> cjwatson: wrt udisks, yesterday I committed the b-dep change to libparted-2.1-dev to Debian git; do you plan to introduce libparted0 into unstable soon as well?
<pitti> (then I can do that in Debian git and get back in sync)
<superm1> pitti, i thought it was in debian's NEW right now still
<pitti> ah, great
<lifeless> NEW seems to be backlogged again
<dholbach> good morning
<dottedmag> p
<dottedmag> -ECHAN
<cjwatson> pitti: parted 2.2 (a.k.a. libparted0-dev) is currently in NEW for Debian experimental; I would like to get parted 1.8.8.git.2009.07.19-6 into testing to simplify the upgrade process before uploading 2.2 to unstable, but other than that there are no blockers
<cjwatson> pitti: (2.1 is in experimental too, and will never be in unstable ...)
<mvo> DktrKranz: hi, I think lp:gdebi is looking good now for a debian upload (and a sync to ubuntu) - to you want to do the upload? or shall I?
<siretart`> seb128: who is caring for gst-ffmpeg these days?
<seb128> siretart`, slomo
<seb128> siretart`, we get in sync from debian
<siretart`> seb128: do you know if gst-ffmpeg for lucid is going to use the system or the internal copy of ffmpeg?
<seb128> whatever we have now
<seb128> I don't expect any other change, we synced yesterday
<seb128> usually it's using the system ffmpeg IIRC
<seb128> I've not looked to it for a while though
<siretart`> seb128: the thing is that upstream is pretty vocal against using our system ffmpeg copy
<siretart`> which I can understand to some extend, but updating it is not an option at this point
<seb128> siretart`, why?
<seb128> why are they vocal about it?
<siretart`> bilboed explicitly states using ffmpeg 0.5 is absolutely unsupported with the current gst-ffmpeg
<siretart`> I expect many crashes will occur because of that, but that's what time will show
<seb128> siretart`, I guess debian will have the same issue
<seb128> siretart`, can you try to talk to slomo about it?
<siretart`> seb128: sure, if I catch him. although I don't think there is much to discuss
<siretart`> the debian package is compiled against 0.5
<seb128> siretart`, so you would recommend using the gst-ffmpeg copy?
<siretart`> seb128: if you manage to convince the security team to support both versions of ffmpeg, that would be an option
<seb128> siretart`, what else is an option?
<seb128> pitti, kees: ^
<siretart`> move gst-ffmpeg from official repo to an PPA with a ffmpeg 0.6 backport from lucid+1?
<siretart`> or live with crashers
<seb128> using the copy seems to best option we have there
<seb128> having a ppa will not work, most users will never find it
<DktrKranz> mvo: I can do it this evening, unless you've got some time to manage it yourself. is version = 0.6.0 fine for you?
<mvo> DktrKranz: 0.6.0 is fine yes - thanks
<cjwatson> pitti: so can we remove devicekit-disks from lucid yet?
<cjwatson> pitti: oh, never mind, I just realised somebody already did :)
<DktrKranz> mvo: have you had the chance to see if python-apt 0.8 api is suitable for merging?
<mvo> DktrKranz: for gdebi? well, yes and no. we will have to port DebPackages.py back to python-apt, its more featureful and contains fixes that the python-apt version does not have
<mvo> that is going to be a bit of work as the python-apt version contains a bunch of formating/variable name changes as well
<mvo> once that is done, the rest is trivial
<persia> mvo: Have you had a chance to review my python-apt ports stuff for the SRU?
<persia> (and do you have any idea why it FTBFS in lucid?)
<mvo> persia: sorry, doing that now. i forgot about that
<persia> mvo: Thanks.  Be warned that I couldn't build in lucid (older releases work), so there's something else odd there.
<persia> mvo: Also, the information isn't strictly correct for warty (but I don't imagine that matters that much).
 * persia hasn't dug out the correct information yet
<cjwatson> debootstrap should have canonical information
 * persia looks at debootstrap
<cjwatson> (modulo bugs obviously ...)
 * persia is amused by the logic in debootstrap/scripts/ubuntu/gutsy
<persia> mvo: Let me update those branches again quickly, now that I have authoritative information
<DktrKranz> mvo: ok, let's keep it out for a while then, after all it won't change before {Squeeze,Lucid} + 1
<mvo> DktrKranz: yeah, I need to get to it at some point, but its not super urgent IMO
<mvo> DktrKranz: uploaded and I file a sync request now
<DktrKranz> great!
<cjwatson> http://norvig.com/21-days.html # great page for all the people who show up here asking how to learn enough programming to contribute to Ubuntu
<persia> mvo: Nevermind.  debootstrap doesn't have the bits that I don't know.
<cjwatson> persia: which bits don't you know?
<persia> cjwatson: Modern debootstrap (properly) points at old-releases.ubuntu.com for warty/hoary, and dapper debootstrap doesn't seem to know about ports.
<persia> cjwatson: I don't know whether ia64 or hppa existed for warty.
<cjwatson> persia: they didn't
<persia> My previous information is that they did for hoary.  Does that match your understanding?
<cjwatson> pretty sure ia64 did; I'll have to check back to remember for hppa
<DktrKranz> mvo: I'm going to remove bzr branch on bzr.d.o/collab-maint, just to use a unique location
<cjwatson> ubuntu-meta (0.17) hoary; urgency=low
<cjwatson>   * Added ia64 support.  No changes to dependencies.
<cjwatson>  -- LaMont Jones <lamont@canonical.com>  Sun,  9 Jan 2005 14:45:39 -0700
<cjwatson> ubuntu-meta (0.53) breezy; urgency=low
<persia> cjwatson: lamont said that ia64 and hppa came at the same time, and thought it was hoary.  No need to check.
<cjwatson>   * Add hppa, no dependency changes.
<cjwatson>  -- LaMont Jones <lamont@ubuntu.com>  Thu, 30 Jun 2005 23:25:54 -0600
<mvo> DktrKranz: ok, fine with me.
<persia> cjwatson: Oh, thanks :)
<cjwatson> persia: my memory and the ubuntu-meta changelog respectfully disagree with lamont ;-)
<persia> And ubuntu-meta ought be authoritative
 * persia edits the hint files
<persia> (not that I'm expecting anyone to really do upgrades from warty with do-release-upgrade or anything)
<cjwatson> hm, apparently there was some hppa support in hoary
<cjwatson> I applied a patch from lamont to debian-installer in hoary to add hppa support
<persia> Then for safety, I'll assume there may have been stuff on ports.ubuntu.com then.
<mvo> the whole ports/old-releases/archive is a bit of a problem for update-manager (and users). I hope we can use something like "mirrors.ubuntu.com" for the next release that does auto detection on this and just brings us to the right place
<mvo> there is some support for this in apt for this already
<cjwatson> persia: what tool is this?
<cjwatson> oh, u-m
<persia> cjwatson: python-apt
<persia> Oddly, debootstrap claims that powerpc was on archive.ubuntu.com for feisty, but there's a TB ruling that powerpc was on ports for 7.04
<persia> I think that's probably a bug in debootstrap (not that it matters much now)
<DktrKranz> mvo: some months ago I asked to insert gdebi in blacklist because of difference between Debian and Ubuntu versions. That is no longer true, I'll ask to remove such entry.
<cjwatson> persia: the archive didn't catch up with the TB ruling
<cjwatson> I checked that one quite carefully :)
<persia> cjwatson: Thanks.  I'll put powerpc on archive for feisty then.
<cjwatson> persia: ports.ubuntu.com itself wasn't created until October 2005, confusing the issue a bit; I think ia64 and hppa initially lived on people.ubuntu.com, and my mail records indicate that hppa was just a sketch in hoary
<DktrKranz> Riddell (or another archive-admin available): mind removing gdebi from sync-blacklist? Current versions are now in sync, thus blacklist is no longer needed.
<persia> cjwatson: If ports.ubuntu.com existed in October 2005, then I'm willing to claim that entries in sources.list pointing to ports.ubuntu.com for hppa and ia64 for a hoary install are correct.  Do you see any reason I shouldn't?
<cjwatson> I don't think it matters if you add those, so go for it
<mvo> DktrKranz: yeah, its no longer true, but I think it was also not done, gdebi in ubuntu/lucid got auto synced
<DktrKranz> mvo: that's why I asked to blacklist it after it got autosynced (that's why of the 0.5.9debian2 package currently available in Lucid)
<DktrKranz> I figured out only later :(
<mvo> DktrKranz: aha, ok :)
<mvo> DktrKranz: thanks! we can unblacklist now - I'm pretty happy about the unifcation release
<DktrKranz> me too
<mvo> I also like "look inside files in the deb" feature that we got recently, also seeing what is done in the postinst so easily is sometimes scary (at least for certain third party debs ;)
<DktrKranz> tonight I will have a triage run at outstanding bugs, to see if we can close some
<mvo> DktrKranz: great!
<mvo> persia: I looked at the diff, looks fine to me. if there is consensus on the exact times when stuff moved/was created I'm happy to upload
<persia> mvo: All branches should be updated to reflect powerpc on archive for feisty and no ports for warty.  Please double-check my syntax :)
<mvo> persia: just let me know
<mvo> persia: ok, I will :)
<mvo> persia: will you do the update for this?
<persia> mvo: Might take a few minutes for bzr to sync, but they should all be good to upload.
<persia> mvo: I'm not a core-dev even though LP thinks I am.
<mvo> persia: ok, no worries. I can take the upload (thats the easy bit)
<persia> mvo: OK.  Please upload for all releases: I'll chat with the SRU team.  Also, if you have any suggestions for dapper, I'd be glad to hear them :)
<ogra> W: Failure while configuring base packages.  This will be attempted 5 times.
<ogra> hmm, seems debootstrap is missing something
<cjwatson> should be more in the log file it leaves around
<ogra> heh, if that wouldnt live inside a vm image i would be able to read it :)
<persia> ogra: can't you mount the VM image as a secondary disk in another VM and then mount it as a filesystem to check that?
<mvo> persia: ok, I have a look at the dapper problem too
<ogra> persia, the prob is that rootstock dies to fast because glib is also out of sync ...
 * ogra tries to save the img somewhere
<persia> ogra: Ah.  That makes it tricky.  If you can capture the image, it should be easy to use -hdb or something in kvm to dig into it.
<ogra> cjwatson, /var/log/bootstrap.log  ?
 * ogra got it quick enough
<ogra> oh, its actually glib's fault ... i wasnt aware debootstrap pulls that in
<cjwatson> plymouth
<ogra> well, i gave it back already and its currently building ... so should be fine later today again
<ogra> ah, the root of all evil, plymouth :)
<persia> Works for some folk, and is even essential for some use cases.
 * ogra wonders if he should somehow cat the bootstrap.log into the rootstock log for such cases
<ttx> pitti: updated the servlet-api dependencies, you should be able to demote libservlet2.{3,4}-java in a few.
<persia> mvo: You figured out the python-apt FTBFS in lucid, or will we plan another upload for that?
<lool> Something is adding massive load to my laptop since the latest upgrade
<lool> I can't figure out what it is; I see one of my CPU is busy in kernel space
<lool> iotop shows nothing (nor top obviously)
<soren> If I want to have a python package work with python2.4, do I really have to rebuild it with an explicit b-d on python2.4?
<lool> I have a long list of console-kit processes though
<lool> soren: You mean only python2.4?
<soren> lool: No.
<soren> lool: python2.4 in addition to whatever it supports now (which is just 2.6).
<lool> soren: problem is that it's not really supported to rebuild modules for python2.4 anymore
<soren> lool: The available python versions at build time mandates which of /usr/lib/python* it gets installed to.
<lool> soren: in theory you should intersect the supported versions wiht the ones available (which you bdep on)
<soren> lool: ..so if I have something that only really works with python2.4, and I want to use twisted with it, I'm kind of screwed, AFAICT.
<lool> soren: pyversions shouldn't return 2.4 anymore
<lool> soren: Yes
<soren> Hm. Ok.
<lool> You have to install a local python2.4 and the relevant packages
<lool> Well I guess I'll just reboot *sigh*
 * soren builds an Intrepid VM to play with python 2.4
<soren> lool: Thanks.
<awoodland> is it possible to request debian->ubuntu syncs for packages in lucid still if they fix ubuntu bugs?
<cjwatson> yes
<cjwatson> if they introduce new features, they'll need a feature freeze exception; if they're bug-fixes alone, that's fine
<awoodland> I can split them out, I wanted to add a feature but I can do that once the fix has hit testing
<persia> awoodland: If you're really confident, it's possible to sync the bugfixes from unstable.
<awoodland> it's a pretty trivial change, developed by upstream not me
<awoodland> so that probably makes sense. I'll upload the fix only with a reference to the LP bug in the changelog shortly then
<mvo> persia: FTBFS> let me check
<persia> mvo: Thanks.  I'm stumped.  The prior version FTBFS on rebuild in lucid also.
<persia> mvo: The karmic branch builds in karmic though, so I'm convinced it's a change to the build-deps.
<mvo> persia: thanks, I think I have a idea about this, I will work on it
<persia> mvo: Oh, excellent.  Thanks!
<amitk> pitti: I've pushed a bzr branch for pm-utils-powersave-policy (https://code.edge.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit). I'm still testing it, but I'd like you to have a look when you have time.
<amitk> pitti: I was thinking of uploading it to a PPA to allow for wider testing prior to integration
<kermiac> sladen: sorry for the pm. this chan didn't show in whois
<lamont> cjwatson: hppa/hoary was outside the datacenter, and lived under people.u.c/~lamont/hppa for quite some time (I noticed it and killed it within the last year)
<apw> cjwatson, wondering what the right approach with linux-tools package.  seems it ended up in universe.  as it carries useful but not necessary things i wonder if i should move it to Recommends: ... though that would leave a binary in main with its manuals in universe
<lamont> at least I'm pretty sure it was hoary...
<cjwatson> apw: any particular reason for Recommends as opposed to explicitly seeding it?  (there might be but I want to make sure you've thought about it)
<cjwatson> apw: for example, does it need to be on CDs?  I think probably not
<apw> cjwatson, no i'm not sure as to the right approach at all, i suspect it needs to be with linux-image policy wise
<apw> no its not needed on a CD, but currently is Depends: from linux-image so causing issues for netboot
<cjwatson> so why not just seed it as a supported thing for developers?
<cjwatson> e.g. in platform.lucid/supported-kernel-common
<cjwatson> linux-doc and linux-source are already there
<cjwatson> Depends from linux-image sounds wrong; that means that it MUST be on the CD
<cjwatson> I would weaken that to Suggests if I were you
<apw> seems completely reasonable to me
<cjwatson> I've promoted it to main for now anyway
<apw> ok thanks for that
 * apw has no idea as to the process for handling seed updates
<cjwatson> and I've seeded it explicitly in platform.lucid/supported-kernel-common
<apw> ahh i see, waiting a bit ... thanks
<cjwatson> core-dev commit access
<apw> i'll move it to Suggests: then
<cjwatson> (lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid)
<cjwatson> thanks, that should complete it
<Riddell> DktrKranz: gdebi removed from sync-blacklist
<al-maisan> hello geser, thank you very much for the vim fix!
<zubin71> hi, will ubuntu be taking part in gsoc this year?
<pitti> cjwatson: thanks for the heads-up; yes, I removed dk-disks on the day when I did the udisks migration :)
<pitti> ttx: yay you!
<pitti> amitk: thanks, I'll have a look; PPA for wider testing sounds good
<DktrKranz> Riddell: thanks
<cjwatson> mvo: so I'm currently trying a hardy->lucid upgrade using dselect (yes I know, but I thought it might be amusing ...).  I ran into an interesting loop and wondered if we ought to solve it some other way.  libc6 Depends: findutils (newer than hardy), because old xargs breaks with new libc6; findutils Depends: dpkg (>= 1.15.4) | install-info for the install-info transition; dpkg Pre-Depends: libc6 (>= 2.11), presumably due ...
<cjwatson> ... to newer symbols
<cjwatson> mvo: are you familiar with this problem?  I was wondering if we could break it at findutils somehow, to simplify things
<cjwatson> It can be done if you know what you're doing but it does require --force-depends once.
<cjwatson> and apt refuses to perform immediate configuration on libc6
<mvo> cjwatson: its showing up at http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/ since a couple of days, but I have not looked at it in details yet. I can give it some time today and see what can be done, but my gut-feeling is that findutils is the best choice for a fix
<cjwatson> I'm very much inclined to just remove that dependency
<cjwatson> the policy directive is:
<cjwatson>      The `install-info' program maintains a directory of installed info
<cjwatson>      documents in `/usr/share/info/dir' for the use of info readers.[1]
<cjwatson>      This file must not be included in packages.  Packages containing info
<cjwatson>      documents should depend on `dpkg (>= 1.15.4) | install-info' to ensure
<cjwatson>      that the directory file is properly rebuilt during partial upgrades
<cjwatson>      from Debian 5.0 (lenny) and earlier.
<cjwatson> but (a) it's not the end of the world if it isn't and (b) in these upgrades it will be taken care of anyway
<cjwatson> findutils.postinst doesn't call install-info itself now - it's done with dpkg triggers
<cjwatson> mvo: I think I've convinced myself :-) I'll make that change
<mvo> cjwatson: I have no objections :) thanks, I will trigger another upgrade test run once its uploaded to see if its happy
<cjwatson> mvo: source uploaded
<primes2h> seb128: Hello, who could I address this to, please? bug 535041
<ubottu> Launchpad bug 535041 in openoffice.org "OpenOffice splash screen is incongruous with new Lucid theme" [Undecided,New] https://launchpad.net/bugs/535041
<seb128> primes2h, hi, why do you ask me?
<seb128> primes2h, try asking ccheney or kwwii they are openoffice and artwork maintainers there
<primes2h> seb128: Thank you very much. Sorry if I bothered you. :-)
<seb128> primes2h, no bothering don't worry
<fatal^> hello. is syncing from debian currently frozen?
<pitti> fatal^: no, why?
<pitti> we got a whole slew of syncs just today
<fatal^> could you please sync rygel which has a small but important fix.
<SwedeMike> February 11th was "LTSdebianimportfreeze" according to the release schedule, what does that mean?
<pitti> it means that we stopped syncing from Debian automatically
<SwedeMike> ah
<pitti> manual syncs upon explicit request are still handled
<SwedeMike> thanks.
<fatal^> also, you might want to consider syncing libarchive which brings the much requested ISO9660 joliet extension support.
<pitti> fatal^: can you please file a bug about it? (requestsync is handy for this, in ubuntu-dev-tools)
<fatal^> I'm not running ubuntu... just trying to give you some hints for packages I maintain in debian.
<pitti> fatal^: we are in FF, so the latter might not be approved (but that needs a bug for documentatino/review in any case)
<pitti> fatal^: ah, ok; thanks
<pitti> rygel looks fine
<pitti> fatal^: rygel synced
<ogra> fatal^, https://wiki.ubuntu.com/SyncRequestProcess
<geser> fatal^: ubuntu-dev-tools is also in Debian
<fatal^> ogra: thanks... (but unfortunately I'll probably forget it before next time I consider looking at which version of packages ubuntu is carrying. :P)
<ogra> fatal^, for libarchive a feature freeze exception is needed, that requires a bug
<ttx> pitti: the ubuntu-server dailies are borken ?
<persia> ttx: For image build or image install?  If install, you need the new glib (recently building)
 * persia thought the images built, from the logs
<ttx> image build: http://cdimage.ubuntu.com/daily/20100309/
<cjwatson> no, they failed
<cjwatson> should be fixed though
<ttx> I mean, http://cdimage.ubuntu.com/ubuntu-server/daily/20100309/
<cjwatson> it's just d-i kernel version desync
<ttx> cjwatson: OK, I assume it was fixed today ?
<persia> Oh, that explains why the architecture I checked appeared to have worked :)
<cjwatson> late last night, I probably just missed the server build
<ttx> cjwatson: ok, thx !
<alkisg> In LTSP, when running `ck-list-sessions` we're getting "active = FALSE" possibly because `ck-launch-session` sets the display-device instead of the x11-display-device. Could someone tell me how to tell ck-launch-session to set x11-display-device?
<kees> seb128: I would prefer a single copy of ffmpeg.  :P
<primes2h> ccheney: kwwii: Hello, about the new theme - icon set, I see this bug 535041,  bug 535061
<ubottu> Launchpad bug 535041 in openoffice.org "OpenOffice splash screen is incongruous with new Lucid theme" [Undecided,New] https://launchpad.net/bugs/535041
<ubottu> Launchpad bug 535061 in light-themes "Install and Startup Disk Creator icon is incongruous (and low resolution) with Ubuntu mono icon set" [Undecided,New] https://launchpad.net/bugs/535061
<nxvl> james_w: ppa's don't get automagic branches, do they?
<ccheney> primes2h: ok, if kwwii gets me a new splash screen for it I will update it in the next upload
<james_w> nxvl: correct
<nxvl> james_w: correct as in they don't or as in they do?
<james_w> they do not
<primes2h> ccheney: That's nice, what about the icon? It looks a bit weird (and with a low resolution i UNE). :-)
<nxvl> ok, thanks
<nxvl> james_w: are there plans to make them get it?
<james_w> nxvl: no
<nxvl> :(
<primes2h> ccheney: Have I to report it to kwwii?
<primes2h> ccheney: it's even always present on desktop using live cd
<ccheney> kwwii: see above about the splash screen for OOo not fitting in with new theme
<ccheney> primes2h: i don't think there is an actual package to assign bugs to him with, letting him know is probably enough
<kwwii> ccheney: the first thing we can do to improve that is change the color of the progress bar ;)
<kwwii> primes2h, ccheney: I'll push this out to my colleagues on the design team
<ccheney> kwwii: iirc there is a file that you can modify the placement and color of the bar with
<ccheney> i don't remember where/how to do it though
<ccheney> i can ask around and see if i can find out
<kwwii> ccheney: if you don't know how would I ever find out?
<ccheney> :)
<ccheney> digging through the source, which would take longer
<ccheney> oh sorry misread
 * ccheney needs more caffeine
<bdrung> pitti: the units policy is finally gone gold?
<pitti> bdrung: yes, with two modifications; the original one was too strong to find TB approval
<pitti> bdrung: but better start a bit smaller and fix the GUI portions first, but get going
<pitti> bdrung: thanks for your persistence, took a while :)
<bdrung> pitti: i saw you changes.
<bdrung> pitti: great.
<bdrung> pitti: we can fix most of the gui portions with bug #369525
<ubottu> Launchpad bug 369525 in glib2.0 "Use IEC standard for binary byte units " [Wishlist,Triaged] https://launchpad.net/bugs/369525
<pitti> bdrung: right, I remember that one; it's somewhat stuck upstream, but I think we'll go ahead and JFDI it
<pitti> bdrung: I put that one on the lucid list now
<bdrung> pitti: JFDI?
<pitti> bdrung: just f* do it, without getting it upstream first
<pitti> bdrung: it might create just the right amount of nudging for them, too :)
<bdrung> pitti: and it's small enough for beeing maintained by us ;)
<ccheney> kwwii: i think this is the information: http://www.oooninja.com/2008/03/change-remove-splash-screen.html
<pitti> that, too; I'm more worried about the behavioural difference, not the patch maintenance
<primes2h> kwwii: btw, did you see this too? it looks a bit weird. bug 535061
<ubottu> Launchpad bug 535061 in light-themes "Install and Startup Disk Creator icon is incongruous (and low resolution) with Ubuntu mono icon set" [Undecided,New] https://launchpad.net/bugs/535061
<ccheney> kwwii: and its already in the /etc/openoffice/sofficerc with values you can tweak
<kwwii> primes2h: hrm, seems that icon is not at the right size
<kwwii> primes2h: but that bug has nothing to do with the ubuntu-mono set
<kwwii> ccheney: ok, I will edit that and get back to you
<primes2h> kwwii: in fact it has because the HD pic in comes about human theme
<primes2h> d/about
<primes2h> s/about/from
<kwwii> primes2h: right
<pitti> bdrung: hah, you missed a "KB" in the description comment :)
<pitti> bdrung: (don't worry, I'll fix it when I sponsor)
<primes2h> kwwii: it should be updated.
<bdrung> pitti: you are right ;)
<ev> slangasek: you're a star; thanks for the Kashmir advice
<kwwii> primes2h: yes, it should ;)
<asac> Riddell: so thats just a helper for the kde dialogs?
<asac> Riddell: why isnt that done inside the mozillatree?
<asac> e.g. is that also distributed by opensuse etc.?
<Riddell> asac: yes it is.  opensuse package it separately so we followed them
<asac> Riddell: ok. just curious ... do you see any mid term reason to keep that out of mozilla tree? is it useful for anything else?
<Riddell> asac: it's not really useful for anything else I can forsee
<Riddell> asac: but mozilla uses autotools and KDE doesn't so that could be fiddly to integrate
<asac> approved
<Riddell> asac: if you're in a MIR mood bug 533990 is wanting looked at too
<ubottu> Launchpad bug 533990 in kubuntu-debug-installer "[MIR] kubuntu-debug-installer" [Undecided,New] https://launchpad.net/bugs/533990
<debfx> mdeslaur: the 62_tray_icon_size_kde.patch can dropped from the pidgin package since the eggtrayicon isn't used anymore
<mdeslaur> debfx: ok, thanks
<asac> Riddell: i assume drkonqi could also e used to put that code in long run?
<asac> e.g. adding a kubuntu backend etc.
<Riddell> asac: I don't follow
<Riddell> asac: this app is run by drkonqi
<asac> Riddell: right. but why not ship this as part of drkonqi ;)
<asac> thats what i wondered about
<asac> e.g. kubuntu should be important enough to justify such code
<asac> anyway approved.
<Riddell> oh I see, yeah we should merge it upstream for the next KDE
<asac> commented on that in MIR bug
<Riddell> thanks asac
<asac> anything else to make KDE happy ;)?
<Riddell> asac: I think that's all thanks, until that gcc ARM segfault manages to fix itself
<asac> hehe
<asac> are there still bad things left? from what i understood most kde things are working now
<asac> well at least building. kdeedu is still on our list in main
<asac> anything that popped up today?
<Riddell> yeah  kdeedu is the issue.  I removed the edu packages from the images so they won't block that but it would be nice to get them back
<asac> Riddell: on ftbfs kdeedu seems to have built
<asac> http://qa.ubuntuwire.com/ftbfs/
<mikebuntu> when I start up my eeePC, I see the ubuntu splash screen then I get a black screen and all I see is the mouse and cursor. I can hit Ctrl+T, then type gdm-restart (even though I can't see anything I'm typing) and then the login screen comes up and everything works... Any ideas?
<Riddell> asac: "Finished 21 hours ago " interesting
<asac> yeah ;)
<Riddell> asac: I wonder if that means kdebindings would build
<asac> Riddell: they are building since a few days already
<asac> i dont have anything i nmain kde related left from what i see
<Riddell> asac: but only because I disabled smoke from kdebindings.  I might try it in the PPA with smoke enabled
<awoodland> can someone sync blcr-0.8.2-10 from Debian/Unstable into Lucid please? It fixes an Ubuntu bug http://packages.qa.debian.org/b/blcr/news/20100309T120216Z.html
<asac> Riddell: do you have a armel ppa somewhere?
<asac> otherwise i can upload to one of mine
<Riddell> asac: the canonical-arm-devs one or whatever its called
<asac> gimme the .dsc
<asac> oh ok
<asac> if that works go for it
<asac> would be lovely to have a fully working kde on armel ;)
<asac> and kde-netbook
<Riddell> awoodland: please file a bug and subscribe ubuntu-archive
<awoodland> file a bug against ubuntu-archive?
<Riddell> ev: did today's ubiquity upload include the fix to the language selection crash?
<Riddell> awoodland: file a bug on the package
<asac> Riddell: xul 1.9.2 is in NEW in case you do an archive run today still ;)
<awoodland> there is a bug on the package
<awoodland> that's why I found it :)
<Riddell> awoodland: a sync request bug
<awoodland> ah ok
 * asac takes a break
<awoodland> so you mean subscribe ubuntu-archive to the bug?
<Riddell> awoodland: that's ok if it's clear to a busy archivev admin that it is a sync request
<asac> there probably is a wiki page about how to request a sync
<asac> awoodland: https://wiki.ubuntu.com/SyncRequestProcess
<awoodland> Thanks (I'm kind of new to doing anything more with Ubuntu development than watching my packages come in from Debian)
<jcastro> awoodland: this might be useful to you: https://wiki.ubuntu.com/Ubuntu/ForDebianDevelopers
<awoodland> yeah I read that, and I've taken advantage of the time period before "DebianImportFreeze" by putting LP bugs in changelogs
<didrocks> kirkland: hey. What is the official way to know for both connected and not connected user those who use an encrypted home? (I want to prevent them to set autologin in gdmsetup)
<kirkland> didrocks: boy that would be phenomenal
<didrocks> kirkland: should be easy on the gdmsetup side, but first, I have to grab the list. Tired of getting but report and tell to people "reboot in recovery modeâ¦ , vim /etc/gdm/custom.conf, urgh :-)"
<kirkland> didrocks: right-o
<kirkland> didrocks: okay, well, it's easy from the ecryptfs side too, so let's hook it up
<Keybuk> pitti: I've discovered something annoying about the fact the Dell Minis need you to press Ctrl-Alt-Fn-F1 to get to a console
<kirkland> didrocks: ls -alF /home/.ecryptfs/$USER/.ecryptfs
<Keybuk> pitti: ...try it on your D420 ;-)
<kirkland> Keybuk: you can change the Fn bit in the BIOS, fyi
<kirkland> Keybuk: ie, make the sound controls secondary and the F-keys primary (if that's your gripe)
<Keybuk> kirkland: the gripe is more that on the other Dells, that's HIBERNATE! :p
<kirkland> Keybuk: doh!  :-)
<kirkland> Keybuk: ie, "take my console away from me" rather than "give me a console"
<Keybuk> more "take my laptop away from me for a few minutes"
<kirkland> didrocks: so if that directory is well-populated (at least has a wrapped-passphrase file), then the user has an encrypted setup
<kirkland> didrocks: if the contents of Private.mnt are equal to the user's $HOME, then they have an encrypted home
<kirkland> didrocks: note that the contents of Private.mnt can be any directory the user owns
<didrocks> kirkland: just tested on two box. awesome, that will be more than easy to fix :)
<kirkland> didrocks: which people like pitti set to $HOME/Private, rather than just $HOME
<kirkland> didrocks: and for older installs (upgrades), if Private.mnt is omitted, it's assumed to be $HOME/Private
<kirkland> didrocks: see also the auto-mount and auto-umount files
<didrocks> kirkland: oh ok, so, looking at that file should be good
<pitti> Keybuk: I switched off the Fn function key thing in the bios
<didrocks> kirkland: auto-mount and auto-umount are empty for me
<pitti> Keybuk: hm, ctrl+alt+hibernate? does that work? :-)
<kirkland> didrocks: right, it's a presence test
<pitti> ah, apparently it does
<kirkland> didrocks: the pam_ecryptfs module will skip it's work, if those are missing on login/logout
<kirkland> didrocks: cool, i think you're money
<kirkland> didrocks: let me know if there's anythign else
<Keybuk> pitti: the problem is I need to switch it off in my BRAIN
<didrocks> kirkland: I guess I just have to look at Private.mnt for each user, see if this corresponds to their home, and not show them in that case. Does that sound correct?
<pitti> Keybuk: just press F2 while you wake up in the morning!
<kirkland> didrocks: yup
<Keybuk> F2?
<kirkland> didrocks: that should do it
<didrocks> kirkland: perfect, thanks a lot, good task for tomorrow morning with a fresh brain :)
<kirkland> didrocks: if $(cat /home/$USER/.ecryptfs/Private.mnt) = $HOME then don't set autologin!
<kirkland> didrocks: good plan
<didrocks> kirkland: agreed ;) of course, gdmsetup is in C with glib, but the idea is there ;)
<kirkland> right
 * ogra lols about pitti'S last comment ... 
<ogra> Keybuk, btw, did i show you that one ? http://people.canonical.com/~ogra/celeron-M-lucid-20100308-3.png
<ogra> ureadahed seems to not really like if L2 cache is only 64k
<Keybuk> ogra: ureadahead --dump | head -2
<ogra> /var/lib/ureadahead/pack: created Mo, 08 MÃ¤r 2010 12:51:39 +0000 for hdd 8:1
<ogra> 19 inode groups, 1878 files, 1933 blocks (102236 kB)
<ogra> Keybuk, ^^^
<Keybuk> ogra: how much memory does that box have?
<ogra> 512
<Keybuk> output of "free" ?
<ogra> MB
<ogra> Mem:        500752     486256      14496          0      44972     138744
<Keybuk> can't see any issue there
<ogra> ogra@ogra-laptop:~$ cat /proc/cpuinfo |grep cache
<ogra> cache size	: 64 KB
<ogra> cache_alignment	: 64
<Keybuk> are you sure it's not just a stupidly slow drive?
<ogra> sure, its not a fast drive additionally
<Keybuk> what debugging have you done to ascertain that this is an L2 cache issue?
<Keybuk> you seem *very* certain
<ogra> Keybuk, no debugging at all ...
<Keybuk> could you describe to me what effect the size of the L2 cache would have on the kernel's CFQ algorithms?
<ogra> no idea but i have other machines with similar setup that are way faster L2 is the one big difference
<Keybuk> have you put the drive from this machine in the others?
<ogra> no, its a little laptop and requires some screwdriver work i havent had time for yet to replace the drives
<Keybuk> ok
<Keybuk> well, I think it's a shit drive
<ogra> but you think it clearly is a drive issue ?
<ogra> ok
<Keybuk> your pack size isn't huge (100MB)
<Keybuk> it's smaller than your page cache after you've been running
<Keybuk> so it's not an issue with that
<Keybuk> the throughput profile shape looks normal
<Keybuk> it's just very long
<Keybuk> and very low throughput
<Keybuk> that to me says shit drive or shit I/O controller
<ogra> /dev/sda1:
<ogra>  Timing buffered disk reads:   70 MB in  3.07 seconds =  22.77 MB/sec
<ogra> yeah, iirc its attached to USB
<ogra> internally
<Keybuk> *facepalms*
<Keybuk> there you go then
<Keybuk> you could read from that drive faster with a magnet and a tweed jacket
<ogra> seems more and more manufacturers fake SATA on a USB port
<ogra> its very intresting though that my ARM board has faster readahead (other speed issues though) with a similar drive setup and throughput
<ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png
<Keybuk> ARM manufacturers would fake SATA using ancient egyptian canal and aqueduct systems if they thought it'd save them a cent on production costs
<ogra> it peaks even 10MB less
<ogra> Keybuk, note, the first bootchart is a celeron :)
<Keybuk> ogra: you're getting much faster seek times
<Keybuk> ie. it costs less to skip the bits of the files you don't need
<ogra> no arm involved ... and the celeron is actually 1/2 min slower
<Keybuk> I don't think the processor is relevant, as I said
<Keybuk> it's the I/O controller through to the drive
<ogra> right
<Keybuk> ogra: another possibility could be syscall time
<Keybuk> to read 1,933 blocks, ureadahead has to make 1,933 syscalls
<Keybuk> if that round trip and context switch time is high - that'd make it slower
<ogra> yeah
<Q-FUNK> call me silly, but where does the patch being edited go to when we call 'edit-patch'?  debian/patches ends up empty in the working directory created by edit-patch.
<Q-FUNK> ah.  it applies the patches and tries to rebuild them afterwards.  hmm.  ok.  this will take some getting used to.
<\sh> guys...did anyone had a look at the problem described in bug #527666 ? creating VGs + LVs + update-initramfs could not be a valid solution for this...
<ubottu> Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [Undecided,Incomplete] https://launchpad.net/bugs/527666
<Keybuk> since discovering the gdb "handle" command, my debugging productivity has increased at least 5%!
<Caesar> wtf. nano has equal alternatives priority to vim-nox?
<Caesar> but vim-gnome has higher
<slangasek> for sensible-editor?
<Caesar> editor
 * slangasek nods
<Caesar> When does editor come into play versus sensible-editor?
<Caesar> Ah, sensible-editor is that fandangled wrapper
<Caesar> editor is the alternative
<ccheney> is there a way to keep light-themes from continously resetting button layout, or do I just need to someone rip it out of the install?
<slangasek> Caesar: yes; sensible-editor is what you're meant to invoke, it honors $EDITOR as a per-user pref
<Caesar> Yeah I note that that uses one's homedir
<Caesar> Again, not ideal on a server
<slangasek> hmm?
<Caesar> We don't automount /home on servers
<Caesar> You just don't get a homedir on servers by default
<slangasek> ... eew :)
<jdong> can't you initialize the environment at the PAM level in that case?
<Caesar> Consider the alternative: you're homedir is in Mountain View and you log into a server in Bangalore
<slangasek> Caesar: I'm not arguing for automounting, but not having a homedir == eew
<Caesar> We seem to survive
<slangasek> jdong: why would you do that instead of adjusting the alternative?
<Caesar> I guess the path of least resistance here is to adjust the alternative with Puppet
<Caesar> But the whole thing makes me sad
<jdong> slangasek: the use case where each user has his own editor preference
<directhex> that was unpleasant
<directhex> total lucid upgrade failure on 2 different issues
<jdong> directhex: apport is refusing to process a upowerd assertion failure here...
<directhex> jdong, at least your system boots! i was unbootable :'(
<slangasek> jdong: so you'd rather write a PAM module to pull in per-user environment settings from $arbitrary_store, instead of allowing for some sort of stub homedir that would provide the settings?
<\sh> Caesar: is there any reason why you don't share a centralized home for your users on servers? just out of curiosity
<jdong> slangasek: well a stub-home would be nice. I'd like that option too :)
<Caesar> \sh: latency
<Caesar> I described the situation earlier
<Caesar> Basically we have the home directories close to the user, but if the user (usually) an admin has to log into a server that is not local to them, they're not going to want the added latency of their home directory
<Caesar> Sorry, that should have been (usually an admin)
<Caesar> Gah. Trying to manage alternatives with Puppet is going to suck :-(
<\sh> hmmmm...latency can be fixed ;) just put some more 10GbE to the cores and sides ;)
<Caesar> \sh: there's this speed of light thing
<Caesar> Asia is always going to be about 130ms from the US
<directhex> hm, this really hasn't gone smoothly :(
<Caesar> 130-210ms for me from my desk to servers in Taiwan and Bangalore for example
<\sh> oh well...I
<\sh> 'm a child of old analog lines...130ms is nothing ;)
<\sh> but depending on the work I need to do remotely...it can be a problem agreed...
<\sh> that reminds me, to solve this problem, too
<Caesar> Anyway, back to the problem at hand
<Caesar> I would argue that if someone has gone to the trouble of installing vim-nox they probably want that to be their editor
<Caesar> That logic seems to extend to vim-gnome, but not vim-nox
<Caesar> In fact, looking at vim-nox's postinst, it seems kinda crazy how the priority of the alternative varies wildly depending on the package variant installed
<Caesar> Maybe the real issue is nano's priority is too high...
<Caesar> slangasek: if I do the work for either change (lowering nano's priority or raising vim-nox's) can that make 10.04?
<slangasek> "if someone has gone to the trouble of installing vim-nox" - no, because if you apply that reasoning equally to any package that provides the alternative, you wind up with whatever arbitrary editor one of the admins *personally* prefers being used as the default for all users on the system
<slangasek> currently I'm reviewing what policy has to say about this particular alternative, if anything
<Caesar> ok
<slangasek> hmm, no guidance there; I guess it's list archaeology to recover the rationale for the current values, then
<Caesar> :-(
<Caesar> I bet they were all arrived at independenty
<slangasek> personally, I hold the view that nano is a much better value for a "sensible" editor, on the grounds that it has a low learning curve compared to vim (self documenting, etc)
<Caesar> I agree, but I disagree about visudo for example using it
<slangasek> ah, heh
<Caesar> I guess we could set EDITOR in /etc/bashrc
<Caesar> That doesn't appear to do the trick though
<slangasek> /etc/bashrc, or /etc/bash.bashrc?
<Caesar> I just tried setting the environment variable and then running visudo
<slangasek> and it wasn't honored?
<Caesar> Simulating having added it to /etc/whatever it is
<Caesar> No it was not
<Caesar> sudo liking to strip environment variables and all
<Caesar> We have "Defaults env_reset,always_set_home" in our sudoers file
<slangasek> heh, ironic
<Caesar> I might be able to use env_keep though
<Caesar> Woot
<Caesar> That seems to work
<cjwatson> somebody at some point wrote an extensive justification of all the editor alternative priorities
<cjwatson> I distinctly remember reading it about five years ago
<Caesar> I have a workaround that doesn't require me to write gobs of Ruby to try and manage alternatives properly with Puppet
<cjwatson> Steve Greenland maybe?
<cjwatson> the modern numbers were certainly not all arrived at independently - somebody sat down and thrashed out a list of rules
<Caesar> I just find it weird that vim-nox and nano have the same priority, but vim-gnome is higher
<cjwatson> there's a bit of a danger of hard cases making bad law
<cjwatson> better to find the ruleset, tweak it if necessary, and get a global view of what that would mean for all the editors
<Caesar> I've found something on -policy from 2000 from Steve Greenland
<cjwatson> that might be it ...
<cjwatson> at least that sounds like it'll be what our current numbers evolved from
 * Caesar goes and reads the thread
<Caesar> Heh. 1997
<Caesar> http://lists.debian.org/debian-policy/2000/06/msg00122.html
<cousteau> is there a place to submit hand-drawn ideas of an interface?
<cousteau> I've been playing with a small idea I had for the netbook edition and I think it could be interesting
<cousteau> don't know much about programming, I would just do it if I knew
<cousteau> maybe I just post it on Ubuntu Brainstorm, but I don't feel like it's the right place for these kind of things
<vorian> cousteau: you can use a "whiteboard" on launchpad.net
<vorian> start a project page, and recruit developers who may also share an intrest in your idea
<cousteau> well, I don't think it might require quite a big development, it's more a look for the UNE launcher
<vorian> cousteau: there are many projects on lanchpad that aren't "big"
<vorian> it's just a place to develop an idea, track progress and bugs
<cousteau> it's an interface that could be also controlled wit the keyboard, in case you don't have a tablet pc
<wgrant> cjwatson: Argh, that custom upload breakage is due to a last-minute change requested by the reviewer :(
<vorian> cousteau: sound interesting, gtk or qt?
<cousteau> that's the problem, I've no idea about programming... my idea was to modify the current launcher
<vorian> in gnome or kde?
<cousteau> gtk, I guess...
<cousteau> well, the current one is done in gtk, right?
<vorian> in gnome, yes
<vorian> i suppose this is ubuntu-devel
<cousteau> http://img214.imageshack.us/img214/5690/ubuntunetbooklauncher2.png
<cousteau> the idea was to control the upper tabs with the F-keys and escape, the app buttons with 1-7, Q-U, A-J and Z-M
<vorian> ah
<cousteau> and space bar to give focus to the "Search" bar
<cousteau> which would be used to filter apps, files, do internet searches and open web pages, much like gnome-do or gnome launcher
#ubuntu-devel 2010-03-10
<cousteau> I have a netbook and it's very uncomfortable to navigate normal "netbook- and MID-oriented launchers" using that small touchpad, since those launchers are more intended for tablet PCs and other touchscreen devices
<Riddell> tjaalton, bryceh: able to confirm bug 528683 ?
<ubottu> Launchpad bug 528683 in nouveau-kernel-source "Please remove nouveau-kernel-source from the archive (lucid)" [Undecided,New] https://launchpad.net/bugs/528683
<RAOF> Riddell: Yup.  Unused, won't build.
<RAOF> cousteau: How does gnome-do itself work on your netbook?
<Riddell> RAOF: thanks, it's gone
<cousteau> RAOF: I think it worked well... dunno, had to format the netbook and get the original OS installed on it, now I was trying moblin (I use Do on my desktop)
<cousteau> gnome-do would be a good alternative to other launchers on netbooks
<cousteau> (my idea didn't attempt to implement the full Do's functionality, just a small part of it)
<RAOF> I was thinking more of an addition, but yes.  I'm pondering whether to suggest Do for ubuntu-netbook inclusion.
<cousteau> well, maybe the search bar on my idea could be an interface to Gnome Do, or even further, maybe my whole idea could be implemented as a Do theme, I don't know
<cousteau> but I have absolutely no idea of C#
<cousteau> and I don't even know if all that can be implemented as a Gnome Do interface, but it probably does
<lifeless> RAOF: does do have a bar like the mac os X big bar at the bottom of the screen ?
<RAOF> You mean a dock?  It used to; that's now in the docky package.
<cousteau> lifeless: it had, but afaik they splitted it as a separate project, "docky"
<lifeless> RAOF: thanks
<RAOF> lifeless: Docky is actually rather neat; particularly the glow around needs-attention windows that bleeds onto your screen when the dock is hidden.
<cousteau> I personally don't like it since 1) it groups windows, 2) it needs compiz or any other composition and that makes my graphics card slow
<lifeless> RAOF: I'll tell you what lynne things :P
<wgrant> I wish Docky handled multiple windows properly.
<lifeless> s/things/thinks/
<lifeless> she's being weened from Mac OSX on her new netbook.
<RAOF> Docky + autohide on a netbook is quite nice.
<RAOF> wgrant: What behaviour would you prefer?
<wgrant> RAOF: I want my several terminals to be separated.
<wgrant> And my browser windows.
<RAOF> Ah, right.  Not one icon per app, but one icon per window.
<RAOF> There's something coming down the pipeline that may solve that for you, but it's currently just a glimmer in a dev's eye.
<cousteau> I had an idea about showing thumbnails of all the windows of a program when hovering the program icon, but they didn't like it
<RAOF> Man, I hope xulrunner-1.9.2 didn't break libmozjs api.
<micahg> RAOF: idk, which program?
<cousteau> which one is that? I have a package called like that, but it's "not installed" and I don't know which firefox it belongs to
<micahg> RAOF: it's been mostly pretty smooth...
<RAOF> micahg: Oh, I'm concerned about libgjs.
 * micahg check if anything's been done with that yet
<RAOF> micahg: Obviously, xul hasn't yet built, and it'll be even longer before it's built on armel, at which point I'll (a) check if it still fails to build and (b) fix it if it does.
<micahg> RAOF: it's FTBFS with a no change rebuild
<micahg> oops..might actually work..
<chrisccoulson> RAOF - your concern is why we want to minimize the number of things using xulrunner in the archive
<RAOF> chrisccoulson: Absolutely.  gnome-shell hasn't moved off libgjs (yet?  please make it yet!), so libgjs remains.
<chrisccoulson> RAOF - someone started a discussion on the desktop-devel list last year about using seed, but the discussion never went anywhere
<RAOF> Yeah, I followed that.
<micahg> RAOF: I'll try to make sure it's ported by the beta
<RAOF> It seemed like everyone agreed that it wouldn't be a huge effort, though.
<RAOF> micahg: That gnome-shell is ported to seed before the beta?  Or gjs?
<micahg> RAOF: gjs to xul192
 * cousteau has just downloaded the netbook-launcher source and steps back frightened
<RAOF> micahg: Thanks.  If everything's nice it should need nothing more that a no-change rebuild, plus some investigation as to why the test-suite fails on armel.
<cousteau> maybe I just do a javascript mockup of how I'd like it to be...
<micahg> RAOF: so far most of the changes have been what a component is called or a small API change
<micahg> about 25% worked as no change or 1.9.1 to 1.9.2 changes
<micahg> RAOF: gjs built :)
<micahg> I'll stage in PPA later
<RAOF> micahg: Yay!
<RAOF> So, I'll look into the armel ftbfs then?
<micahg> RAOF: yeah, that would be great, I'll prepare a debdiff on a bug for the xul192 change
<RAOF> micahg: Oh, gjs required source changes?  Ok.
<micahg> RAOF: no, just debian/rules
<RAOF> Oh, really?  That's a bit strange.  Did the directory layout change?
<micahg> RAOF: xulrunner version is hard coded :)
<RAOF> Was it?  I thought I was extracting it from somewhere. :)
<RAOF> Oh.  Right.  *That* package version :)
<micahg> yep, that's the only change
<RAOF> Is it possible to get apport hooks to enable bug reporting against PPA packages (with the bugs filed in Ubuntu)?
<RAOF> I seem to recall network-manager having something like this.
<\sh> jcastro: happy birthday
<jarlath> parted + udisks won't install in the updates. Is this known?
 * persia notes that the updates *do* install if one updates enough simultaneous packages
<YokoZar> Is the sponsorship page still doing that loop endlessly thing after submit?
<RAOF> Is gdb expected to work in a qemu arm environment?
<persia> RAOF: for some values of "work", yes.  What isn't happening?
<RAOF> It's not catching SIGSEGV
<RAOF> âunsupported syscall 26â.
<persia> Ugh.  Please report a bug against qemu-kvm.
<persia> That really should work (although note that many times things still work when reporting "unsupported syscall", depending on precisely which syscall it was and why it was called)
<RAOF> So, the gjs testsuite failure isn't a false-alarm. :)
<micahg> RAOF: it failed on i386
<RAOF> Oh.  It succeeded on my amd64
<micahg> RAOF: on mine also :)
<micahg> RAOF: https://edge.launchpad.net/~mozillateam/+archive/ffox35/+build/1553647
<persia> As a side note, running sbuild against i386 on an amd64 runs a lot faster than running it against armel :)
<RAOF> But doesn't pick up the armel-specific failure.
<persia> True.
<RAOF> i386 apparently has a new and different failure.
<RAOF> ie: *everything* segfaults on armel, but the i386 build passed an entire set of unit tests.
<persia> That's somewhat unexpected.
<persia> Is there assembly code or something?
<RAOF> I have no idea what crazy javascript hacks are running around in mozjs.
<RAOF> Since they've been going for javascript performance, and that necessarily involves JIT, I'd guess that yes, there is assembly code involved.
<persia> Indeed, and probably code-generation code.
<persia> (which is hard to port).
<RAOF> Right
<NCommander> persia: RAOF: gdb won't work in qemu
<NCommander> er, qemu-linux-arm
<NCommander> ptrace isn't implemented, and its technically difficult (if not boardline impossible) to implement it
<micahg> RAOF: do you have any idea why the test failed on i386 for me?
<RAOF> No, but I'm updating my i386 schroot to investigate.
<RAOF> NCommander: So, no use in filing a bug? :(
<RAOF> NCommander: How is one expected to debug segfaults then?
<NCommander> RAOF: well, file a bug, but its unlikely to get implemented any time soon :-/
<persia> Let's get the bug filed for reference.  We can link to the ustream bug.
<NCommander> RAOF: use real hardware, or qemu-system-arm
<pitti> Good morning
<RAOF> Morning pitti!
<pitti> hey RAOF, how are you?
<RAOF> Good.  I'm off to see Alice in Wonderland shortly :)
<pitti> o_O
<micahg> you can simulate armel in qemu?
<RAOF> Yes; that's exactly what I've been doing.
<micahg> ah, can you simulate ia64 also?
<RAOF> micahg: I'm off.  You can leave the i386 test suite failure with me if you like; I'll get to it tomorrow, along with the armel failure.
<RAOF> If you want to take it up, you're very welcome to :)
<micahg> RAOF: nah, I've got other stuff to port, let me know when I can file the debdiff for xul192 :)
<RAOF> I've made that change locally; once I've figured out the test-suite failures, I'll upload.  Unless the debdiff was more than s/1.9.1/1.9.2/?
<RAOF> Or if you'd like TIL status on gjs :)
<micahg> RAOF: k, no that's it :)
<RAOF> Anyway; really off :)
<micahg> RAOF: k
<persia> micahg: You should be able to simulate anything (pbuilder-dist and mk-sbuild support this), but many architecture pairs don't quite work as well as one might hope.
<persia> micahg: For example: `mk-sbuild --arch=ia64 lucid` is a valid command, and tries to do the right thing.
<micahg> persia: k, I might try it
<persia> micahg: No promises it works.  I've only been testing with amd64-armel (which works fairly well) and amd64-powerpc (which works, but not so well).
<dholbach> good morning
<dholbach> tjaalton: did your comment on bug 520796 mean you ACKed it?
<ubottu> Launchpad bug 520796 in x11proto-dri2 "Sync x11proto-dri2 2.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/520796
<tjaalton> dholbach: yes
<tjaalton> should've probably sub'd archive admins while at it
<dholbach> tjaalton: ok, you better would've subscribed the ubuntu-archive team too then and unsubscribed the sponsors - I'll do that :)
<tjaalton> dholbach: thanks :)
<dholbach> high time we reduce the time of the sponsoring queue somewhat
<pitti> amitk: hm, the ac97 pm-powersave hook looks a bit wild -- echo 1 > /dev/dsp looks like there could be half a dozen things which could go wrong
<pitti> amitk: like using an obsolete API (OSS), interfering with pulseaudio, producing a loud noise, etc
<amitk> pitti: I agree. It is recommended on lesswatts too. I was hoping someone with the HW would be able to tell me what it does.
<pitti> amitk: also, I think we previously enabled powersaving on intel sound chips, but crimsun had to disable it again because it caused problems -- do we know that these wouldn't affect that ac97 hook?
<amitk> pitti: I've found some problems in 2 scripts since then that I'll fix now.
<pitti> amitk: well, ac97 is used in a million machines, and there's lots of different hardware, amplifiers, loudspeakers, etc.
<amitk> pitti: ac97 is pre-intel-hda. They have no relation
<pitti> amitk: right, it's technically a different driver, but the problems from the hda powersave ones (producing plops, latency, etc.) might hit ac97 as well
<pitti> that's why I'm a little nervous about this
<amitk> pitti: I hope to gather more info through the PPA testing
<pitti> amitk: is http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/13 just for text VTs, or for X as well? I thought that X would already do it
<pitti> ah, the next commit explains
<amitk> pitti: only for text
<pitti> amitk: so this is for servers primarily?
<amitk> pitti: likely, but I just noticed that the server seeds don't contain pm-utils*
<pitti> amitk: do we know that setterm doesn't interfere with X?
<amitk> pitti: it doesn't AFAICT
<pitti> amitk: ok, that sounds rather harmless then
<pitti> amitk: next question, http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/15
<pitti> amitk: why wouldn't that be something that could be enabled in the kernel by default?
<pitti> amitk: also, I don't think [ -lt ] works with floats
<amitk> pitti: yeah, that is one of the bugs I found :)
<pitti> $ LANG= /bin/sh -c '[ 0.34 -lt 0.50 ] && echo yes'
<pitti> [: 1: Illegal number: 0.34
<amitk> pitti: I think it is still under devel. As I noted in the comment, this is not the best way to do it, it has to be done periodically in the scheduler
<pitti> amitk: r16 likewise then, I figure
<amitk> yes
<pitti> amitk: http://bazaar.launchpad.net/~amitk/ubuntu/lucid/pm-utils-powersave-policy/amit/revision/17
<pitti> amitk: would you mind checking type ethtool? (since we don't seem to install that by default)
<amitk> pitti: we don't. I should add a Deps in the packaging
<amitk> pitti: thanks for the review. I'll fix stuff and upload to PPA
<spaetz> cwatson?
<spaetz> ubi-partman exits with error 141 in todays UNR installer
<spaetz> syslog says: "/lib/partman/choose_partition//do_option: not found"
<persia> spaetz: That's usually best debugged with more logs.  I believe it happens when some partman module doesn't successfully identify the target.
<spaetz> my syslog seems pretty identical to the one in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/527848 which cwtson closed as fixed 8 days ago.
<ubottu> Launchpad bug 527848 in ubiquity "[Lucid] ubi-partman failed with exit code 141 during manual partitioning" [Undecided,Fix released]
<spaetz> I will make sure that I really use todays build and comment on that bug then. Thanks
<cjwatson> spaetz: if you want to highlight me, you need to get my nick right, too :-)
<cjwatson> spaetz: if you can definitely reproduce it with a current build, start the installer with 'ubiquity --debug' in a terminal, exit the installer when it crashes, and then run 'ubuntu-bug ubiquity' to create a new bug with all the necessary information
<cjwatson> spaetz: DO NOT ATTACH LOGS TO AN EXISTING BUG EVEN IF IT LOOKS THE SAME :-)
<spaetz> cjwatson: ahh there you are, hello :)
<spaetz> Just commented on the above bug
<spaetz> Definitely reproducable
<cjwatson> please DO NOT COMMENT ON AN EXISTING BUG
<cjwatson> file a new one, please!
<spaetz> will do.
<cjwatson> there are multiple causes for that symptom
<cjwatson> spaetz: oh, if your network card doesn't work - the log files I need are /var/log/syslog, /var/log/partman, and /var/log/installer/debug
<cjwatson> spaetz: you can extract them onto a USB stick
<cjwatson> sorry to shout above, but it's really hard work disentangling multiple problems from a single bug and I want to discourage the practice as much as possible
<spaetz> ok, will do. No problem about shouting :)
<spaetz> no offense :)
<cjwatson> spaetz: please let me know the bug number once you file it - we've had a few of these problems and I want to stomp on them hard and quickly
<spaetz> Yep, just copied over log files. Battleing with launchpad right now.
<spaetz> "Sorry, something just went wrong in Launchpad. "
<spaetz> when looking for package ubiquity (https://launchpad.net/ubuntu/+search?text=ubiquity)
<spaetz> cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/535630
<ubottu> Launchpad bug 535630 in ubiquity "[lucid UNR] ubi-partman crashes with error 141" [Undecided,New]
<spaetz> attachments uploaded
<cjwatson> spaetz: you didn't appear to reproduce the failure when running in debug mode
<cjwatson> spaetz: or if you did, you didn't exit the installer before saving off the logs, so it didn't flush all the log data out
<spaetz> opps, no the installer is still open
<spaetz> should I close it and attach full logs?
<cjwatson> yes please
<cjwatson> I need a debug log that actually shows the failure :)
<spaetz> or rather, let me restart the install, I will attach a clean log
<cjwatson> yeah, that would be best if you could, thanks
<spaetz> cjwatson: reattached new logs
<spaetz> not rebooted, but fresh ubiquity -d run
<spaetz> which I actually quited after the error dialog
<spaetz> Hey, and that bug was already closed by some "mercedes" as fixed released...
<cjwatson> I will reopen and LART mercedes
<spaetz> thanks a bunch :)
<cjwatson> kirkland`: any reason qemu-kvm's Architecture field doesn't include sparc?
<cjwatson> kirkland`: the actual code seems to build fine there
<cjwatson> kirkland`: I'm having to remove libvirt on powerpc and sparc even though that makes some things uninstallable there, because the lesser evil is getting rid of the old libparted from the archive
<cjwatson> kirkland`: (actually just libvirt-bin; cf. bug 535368)
<ubottu> Launchpad bug 535368 in parted "gparted will not install on lucid Alpha3" [Undecided,Confirmed] https://launchpad.net/bugs/535368
<pitti> james_w: I think it's the second time that I look at a branch (lp:ubuntu/sysvinit) which only has the karmic version; does that mean that something in lucid packaging changed which made the auto-importer fail?
<Riddell> asac: kdebindings still fails in the same place on ARM
<Riddell> still, I can add the kdeedu packages back to the seed
<asac> Riddell: ok. so kdebindings succeeds because you disabled smoke, right?
<asac> how important?
<Riddell> asac: yes
<asac> we should file a bug about that i think
<asac> otherwise we will forget because its gone from ftbfs
<Riddell> asac: not very, it makes the ruby and csharp bindings for KDE but they're not much used.  a bug would be good though
<cjwatson> free: re these twisted syncs, it's OK in future to use a single bug for lots of closely associated syncs rather than a set of bugs with the same description, if you prefer that
<cjwatson> free: (but leave it alone now, I'm processing them the way they are)
<free> cjwatson: thanks, I'll keep it mind
<cjwatson> might cut down on FFe paperwork
<persia> cjwatson: Prior recommendations in this channel have been to either file a bundle of bugs, or manually provide an archive-admin with a preformatted list.  Would it be worth adding clear documentation on which works better with the tools to the wiki somewhere?
<free> cjwatson: yeah, sorry for the extra burdeon
<cjwatson> persia: both work fine with the tools
<cjwatson> persia: normally separate bugs would be easier to keep track of (you'd get a more sensible comment trail), but when applying for a combined FFe I think a single bug is easier
<doko__> asac: is xulrunner-dev still the right package to build the java plugin?
<asac> doko__: yes
<persia> cjwatson: Ah, OK.  Thanks.
<tankenmate> anyone know of any tmpfs corruptions on jaunty? i have a server that has a mildly corrupt /var/run..
<tankenmate> dirent is returning a vnode that doesn't exist..
<tankenmate> no kernel hackers
<tankenmate> ?
<persia> The kernel hacker / IRC nick ratio is slightly higher in #ubuntu-kernel
<tankenmate> persia: will do thanks..
<zyga> has anyone seen mvo lately?
<tankenmate> hmmm no voice on #ubuntu-kernel?
<apw> pitti, what criteria does lucid-burndown use to select blueprints?   i assume it is 'series goal' of lucid ?
<sistpoty|work> lamont | doko__ : just looking at https://launchpad.net/ubuntu/+source/ghc6/6.12.1-12/+build/1526050/+files/buildlog_ubuntu-lucid-armel.ghc6_6.12.1-12_FAILEDTOBUILD.txt.gz, I assume the build was killed by hand? do we have a faster armel box than jackfruit?
<persia> sistpoty|work: I can confirm it was killed by hand, by Laney's request.  There's a don't-die-from-timeout loop in there that makes it not die.
<sistpoty|work> persia: yes, that's the watcher script. ghc6 was still running though
<persia> Then I'm not sure why Laney asked for the build to be killed.
<persia> "[03:54] <Laney> lamont: please kill https://launchpad.net/ubuntu/+source/ghc6/6.12.1-12/+build/1526050 - it's obviously hung"
<persia> (from #launchpad)
<Laney> sistpoty|work: what makes you think it was still progressing?
<sistpoty|work> Laney: mainly that I've watched a ghc6 stage2 compile pass taking a week a long time ago. ghc6 was still running in the build, so why should it not progress?
<sistpoty|work> Laney: indeed, I think progress at this point was highly unlikely, since I can't see gcc running (and usually that's where it takes very long)
<persia> Should maybe the watcher script be modified to print out an extract of ps output ?
<sistpoty|work> persia: it does that already
<sistpoty|work> (that's where I gather my knowledge from ;))
<Laney> I would have expected to see some build output
<Laney> but the fact that it hung at the start of stage2, and took so long, led me to that conclusion
<Laney> it has also been tried and aborted several times before on different buildds
<persia> I don't think there's any real difference between the buildds.
<sistpoty|work> Laney: *nod*, makes sense
<sistpoty|work> Laney: maybe we should retry again? there's a newer eglibc available that includes an arm specific change
<Laney> sistpoty|work: a local test build would probably be a better use of resources
<sistpoty|work> Laney: sure, but I don't have an arm box :/
<pitti> apw: correct, it parses ubuntu/lucid/+specs
<persia> Laney: sistpoty|work: How long is this expected to take to build, and how well does it deal with sleep?  I have an ARM box, but I carry it with me and don't want to kill the battery whenever I go between power connections.
<sistpoty|work> persia: the debian build took at least 5 days. No clue about sleeping though
<persia> 5 days!  Hrm.  Maybe I can do something.
<sistpoty|work> persia: that would be awesome!
<persia> What do you need?  Just confirmation success/fail?  A buildlog?
<persia> Also, should I be able to build in a lucid pbuilder from jaunty?
<sistpoty|work> persia: build log if it fails would be good, I guess. I think building from jaunty should work. Laney, anything else?
<persia> Laney: Also, does it still fail to configure in qemu?
<Laney> sistpoty|work: should be fine indeed
<Laney> persia: I don't know, and my PC has locked up again so I can't check until later
<Laney> . o O ( I should debug that )
<persia> Laney: Could you?  I have significantly more memory/processor cycles to throw at qemu-armel than real armel (as do most of us, I suspect).
<directhex> is aptitude on lucid on amd64 broken for anyone else?
<Laney> I guess you could also try to pbuilder-armel it too, persia
<Laney> if you have the requisite hardware to hand
 * persia mostly needs a good kick to install Ubuntu on the new server still sitting in shiny packaging.
<persia> I'll definitely start an sbuild-armel run on an amd64 server tomorrow.  I need to fiddle a bit to make sure I have ~5 days where I won't run out of power for the real build.
<kirkland`> cjwatson: okay, thanks for the heads up on libvirt/sparc
<Keybuk> Dear Launchpad folks,
<Keybuk> I want a button on a bug report.
<Keybuk> Clicking this button should electrocute the original reporter.
<pitti> "Please wait while bug data is processed"
<Keybuk> Then bar them from ever making any status changes to any bug ever again.
<Keybuk> if this could be automatic if someone changes a bug from the "Won't Fix" status, that would be AWESOME
<persia> Keybuk: Do you have an example bug where a non-developer managed to unset Won'tFix ?  I thought that wasn't supposed to be possible.
<zul> mvo: ping
<Keybuk> persia: there's nothing that makes it not possible
<Keybuk> bug #535120
<ubottu> Launchpad bug 535120 in upstart "Please add option -f and -F to shutdown for LPIC compatibility" [Wishlist,Won't fix] https://launchpad.net/bugs/535120
<pitti> ogra: is bug 536670 what you see as well? i. e. do you have an unpartitioned device which doesn't automount?
<ubottu> Launchpad bug 536670 in gvfs "Does not automount unpartitioned devices" [High,Confirmed] https://launchpad.net/bugs/536670
<ogra> pitti, hmm, i dont knoe if my reader is unpartitioned
<pitti> ogra: my Sony PRS 505 is
 * ogra has a TS 600
<ogra> let me get it ...
<pitti> ogra: well, if you get around to it in the next week or so, would be great to check (not that urgent)
<pitti> ogra: I can perfectly reproduce the bug with both an USB stick and my ebook; I just wanted to know whether a partitioned device failed for you (that works well for me)
<ogra> ok, its unpartitioned .... funny though that they put two separate devices in instead of one with two partitons
<ogra> pitti, partitioned USB keys work
<pitti> ogra: thanks, so that seems to be your bug then
<ogra> right, do you need a confirmation comment or anything ?
<pitti> ogra: heh, mine has three - internal flash memory, SD card reader, and a proprietary sony card reader
<pitti> ogra: no, I don't; if you are interested you can subscribe
<ogra> yeah, mine has the readers too, but internally it also has two deviced
<ogra> *devices
<pitti> ogra: knowing that it's not yet something else which is broken is enough for me :)
<pitti> thanks for checking
<ogra> one with the windows SW i never use and one for the book db
<pitti> ogra: oh, is that windows sw one readonly?
<ogra> no idea i never looked at it :)
<pitti> ogra: if that's useless under Linux, please feel free to file a bug against udisks to entirely ignore that one
<pitti> (similar to all those rescure partitions, etc.)
<pitti> ogra: it'd be a 5-minute fix, and it's one more bug to fix to catch up with kirkland :-P
<ogra> ogra@osiris:/var/build$ sudo mount /dev/sde /mnt/
<ogra> mount: blockorientiertes GerÃ¤t /dev/sde ist schreibgeschÃ¼tzt, wird eingehÃ¤ngt im Nur-Lese-Modus
<pitti> *nod*
<pitti> so, ROM
<ogra> but i dont know how to find out any additional info you could match on
<ogra> it looks like a std scsi disk
<pitti> ogra: ubuntu-bug storage
<ogra> with it mounted ?
<cjwatson> Keybuk: I have somebody spuriously setting newly filed bugs to Fix Released with no comment
<pitti> ogra: actually, that's broken right now unfortunately (I just uploaded a fix, but it still needs to get published)
<ogra> i'll do it later then
<pitti> ogra: file it manually, plug it in, and attach the output of "udevadm info --export-db"
<pitti> ogra: or that; I'll ping you again
<Keybuk> cjwatson: that I wouldn't mind ;)
<Keybuk> (assuming the someone is the reporter)
<kirkland> pitti: bring it on!
<cjwatson> Keybuk: nope, just some random person, and the bug was one I was in the middle of working on
<pitti> Russian bug roulette?
<JamieBennett> sistpoty, Laney: did you have a gh6 fix you wanted to test on ARM hardware?
<sistpoty|work> JamieBennett: not a fix, just a test-build with the current sources against the current libc (that changed since the last failed build on the buildds)
<JamieBennett> sistpoty|work:: I have ARM hardware available that can be used if you give me a run down of exactly what you want me to do with it
<Laney> If you could do a test-build of ghc from Lucid and see if it succeeds, that would be cool.
<Laney> And then if and when it starts looping at the stage2 build, poking around to see what is going on
<didrocks> JamieBennett: I was wondering, what draws the background in n-l-efl? g-s-d or do you have your own way in n-l-efl to draw it?
<Laney> JamieBennett: are you familiar with the difference between Debian and Ubuntu wrt ARM that could cause FTBFS like this? Or are there many and numerous?
<james_w> pitti: yes, that package failed to import a recent version
<JamieBennett> didrocks:  I'm not sure, that would be one for mterry to answer
<didrocks> mterry: ^ ?
<JamieBennett> Laney: I haven't looked into the specifics of this build failure yet, just got a 'call for hardware' message. I'll investigate.
<mterry> didrocks, huh.  probably NLE, but I can't give a 100% answer without grepping the code
<didrocks> mterry: if it's not g-s-d and if you don't use gnome-desktop to draw it, you might be interested by the cache I have implemented. This can save some time at boot. Just tell me :)
<mterry> didrocks, ah neat
<mterry> didrocks, will do, once i check in a bit
<persia> Laney: At a high level, all the toolchain defaults differ, including the target ISA, which has a number of effects.
<smoser> Keybuk, for bug 531494 i'll try to get you /var/log/udev . is there anything else that woudl be helpful ?
<ubottu> Launchpad bug 531494 in upstart "cloud-init job not running in eucalyptus without ramdisk" [Critical,Confirmed] https://launchpad.net/bugs/531494
<didrocks> mterry: sweet :)
<Keybuk> smoser: a patch <g>
<smoser> Keybuk, you'll be happy, or sad to know, that in my first test on the 20100310 image, i did not reproduce failure.
<smoser> however, that is on a different UEC rig than i was seeing it on with 20100303
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<Gemmazz> http://imgnow.info/DSC-1268236606.jpg does my ass look big?
<tkamppeter> pitti, have you seen that I have SRUed bug 293832?
<ubottu> Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832
<pitti> tkamppeter: I'll get to SRU this week, then I'll process it
<tkamppeter> pitti, OK.
<sistpoty|work> kees, doko: just looking at bug #438876, might this be a problem with gcc-4.4 and stack-protector on sparc?
<ubottu> Launchpad bug 438876 in perl "perl ftbfs with gcc-4.4 -O2 on sparc" [Medium,Triaged] https://launchpad.net/bugs/438876
<sistpoty|work> kees, doko: erm, actually bug #534459, sorry
<ubottu> Launchpad bug 534459 in patch "2.6-2 FTBFS on sparc (bus error in test cases)" [Undecided,Confirmed] https://launchpad.net/bugs/534459
<Keybuk> I need to write a small C program that sets the current console back to KD_TEXT and VT_AUTO, etc.
<Keybuk> either that, or remember to keep X running and chvt to that
<psusi> wow... seems a LOT of users have problems with grub using the embed area and bad windows software overwriting it... but it doesn't look like anything is being done about this.  Shouldn't we change grub to not use the embed area by default?
<cjwatson> psusi: definitely not!
<cjwatson> psusi: that would suck differently
<psusi> why?
<cjwatson> I don't have time to explain, sorry
<cjwatson> in a meeting
<cjwatson> suffice to say I would absolutely veto that change
<psusi> heh... iirc we dind't used to use stage1.5 by default in grub legacy.. so I'm wondering why it's defaulted to now....
<cjwatson> false.
<cjwatson> pretty sure we configured grub legacy essentially the same way.
<psusi> really?  hrm... maybe it was just me then since I've always had an unusual config due to fakeraid ;)
<psusi> but unless you want to do something radical like online defrag that would disturb /boot/grub, I don't see what disadvantage you would have by not using the embed area
<cjwatson> totally unreliable
<psusi> how so?  as long as the core file isn't moved...
<cjwatson> putting grub in the partition means that you have to use blocklists which means that "significant enough" changes to the partition break stuff
<cjwatson> upstream have deprecated this and for good reason.
<cjwatson> and it isn't just defrag
<psusi> resizing the partition then I guess could do it as well
<cjwatson> http://grub.enbug.org/BIOS_Boot_Partition
<cjwatson> (that focuses on GPT, but the section on blocklists is generally applicable
<cjwatson> )
<psusi> yea, that's nice for GPT, but we aren't talking about people using GPT ;)
<cjwatson> psusi: please read what I just said!
<cjwatson> "the section on blocklists is generally applicable"
<psusi> I'm aware of the issues... it just seems to me that most of our users would not have a problem with that since they don't tend to do radical operations to the filesystem
<cjwatson> *blink* how about the way our installer automatically resizes things to make room? :-)
<cjwatson> also, I'm just not seeing the number of issues you refer to
<cjwatson> they're dwarfed by other things
<psusi> it automatically resizes windows partition to make room for Ubuntu...
<cjwatson> you haven't looked at the code, obviously :)
<cjwatson> it doesn't care whether it's Windows
<psusi> well I see a lot of people complaining about bug #441941
<ubottu> Launchpad bug 441941 in grub2 "grub fails after running Windows" [Undecided,Confirmed] https://launchpad.net/bugs/441941
<psusi> well yea, I suppose if you install a new version of Ubuntu it would shrink the old partition
<cjwatson> I think that's specialised, it doesn't seem to hit everyone
<psusi> of course if you do that, then you'd re install the mbr after the resize anyhow so no problem ;)
<cjwatson> and that bug is unusable anyway, it's full of conflicting comments and invective
<cjwatson> so meh
<psusi> yea, just hits a lot of people with HP and Dell PCs ;)
<cjwatson> I ignore bugs that are full of people ranting :)
<cjwatson> it's not worth the energy usually
<psusi> that's what I figured was going on
<cjwatson> and I do think it should be fixed in the other software
<cjwatson> since it doesn't actually seem to be Windows itself doing it
<psusi> but after spending time reading through there, and a thread or two on the forums, it seems that this effects a fair number of people
<james_w> JFo: have you had a launchpadlib script get a little to eager with its tagging?
<cjwatson> seriously.  I'm not going to stop using the embedding area.  other changes may be possible, but please give that one up
<psusi> sure, but if we could easily fix it by not using the embed area...
<cjwatson> no.
<cjwatson> I'm not going to keep on repeating myself here - that would break other things and I won't do it
<psusi> what use case do you see that causing a problem?
<cjwatson> sorry.
<cjwatson> we're going round in circles.
<tseliot> slangasek: do you mind if I bump the plymouth version to 0.8.0~-13 and upload my changes to both Lucid and the bzr branch? Or do you have something else to add?
<psusi> you  mentioned installing a new ubuntu which would resize the partition, but that also reinstalls grub, so no problem
<slangasek> tseliot: there are pending changes from Keybuk, you should talk to him
<tseliot> slangasek: will do, thanks
<cjwatson> psusi: as the upstream wiki page points out, even aggressive fsck changes can break it
<slangasek> tseliot: also, yes, I do mind bumping to "-13" when this is not a Debian package and Debian is packaging it separately
<cjwatson> psusi: I simply don't want to have to deal with that kind of problem
<psusi> hrm...
<slangasek> and I will continue to let 'dch' DTRT whenever I'm uploading plymouth
<tseliot> slangasek: even if I have a new png logo?
<cjwatson> it may be that simply having a bigger embedding area would deal with it, and we'll be doing that by default in lucid anyway
<cjwatson> (it's not in place yet)
<slangasek> tseliot: Ubuntu uploads should use Ubuntu version numbers; right now we're clobbering the Debian version numbers
<psusi> eh?  what do you mean?
<tseliot> slangasek: do they really have plymouth in Debian?
<slangasek> tseliot: yes, of course, and even if they didn't we should still be using -0ubuntuN
<psusi> as in have the resize stage also move the start of the windows partition further down the drive than sector 63?
<slangasek> but I expect plymouth to take over the boot splash space in Debian just like it's doing everywhere else
<Keybuk> slangasek: no they shouldn't :)
<Keybuk> Ubuntu uploads of packages that were made for Ubuntu by Ubuntu should be -N :p
<cjwatson> oh, if Windows is already installed - well, even then, recent versions of Windows tend to align themselves to 1MB start positions
<Chipzz>   
<cjwatson> I apologise for saying that GRUB Legacy used the embedding area too - looks like I was wrong there
<cjwatson> but the alternative with GRUB 2 is not the same as the way GRUB Legacy worked
<psusi> yea, I thought you had to explicitly throw the --stage1.5 flag when installing it ;)
<psusi> it isn't?
<cjwatson> or at least not quite
<cjwatson> I don't think so.  But honestly the alternative sucks so much I haven't put lots of time into investigating it
<cjwatson> and if I do it, upstream will probably refuse to support me :)
<slangasek> Keybuk: I know that's the rule you use, but all that does is make it harder to get in sync with Debian later and works against tools like dch
<cjwatson> which matters too ...
<Keybuk> slangasek: we don't always want to be in sync with Debian
<psusi> what if we created an actual tiny partition to hold the core by default?
<slangasek> Keybuk: that's no reason to preclude trying to minimize the delta with Debian for packages that aren't Ubuntu-specific
<Keybuk> slangasek: there can be lots of reasons
<Keybuk> for a start, anything at the boot level is wildly different anyway
<Keybuk> anything we've packaged ourselves based off upstream - it's going to be easier for us to keep basing off upstream
<slangasek> I don't agree with that
<slangasek> there are many things that have been packaged first in Ubuntu that core maintenance has moved to Debian afterwards, to save effort
<cjwatson> that might work (although has some other problems)
<Keybuk> slangasek: such as?
 * _UsUrPeR_ tips his hat
<Keybuk> initramfs-tools has been harder to maintain as a result of trying to recognise Debian as an upsteam
<cjwatson> the obvious source of breakage there is BIOSes that can't read past a certain limit, so putting the GRUB code at the very start of the disk is strongly advantageous
<psusi> aside from using up another partition table entry?
<_UsUrPeR_> Can anybody describe the process of adding a network driver to the 9.10 installation CD? I already have the CD on a writable USB key, so I can make changes to the image. The undetected ethernet card is a  Atheros AR8132 / L1c Gigabit Ethernet Adapter
<cjwatson> in fact that's a case you break by putting GRUB code in the partition, too, since Windows is typically preconfigured to occupy a huge whack of space right at the start
<psusi> true, but I don't think any computers younger than... 10 years now?  have that issue
<cjwatson> initramfs-tools has mostly been hard to maintain as a result of doing a bad job of trying to recognise Debian as an upstream ...
<cjwatson> psusi: I got a bug about that just last week
<cjwatson> so don't tell me it doesn't exist :)
<cjwatson> you'd be amazed at how broken even quite new BIOSes can be
<Keybuk> cjwatson: mostly because we tend to disagree with the Debian maintainer on his changes
<cjwatson> I thought the same as you until I started hearing from reality
<psusi> wow
<cjwatson> I was disappointed
<slangasek> Keybuk: I'm not going to trawl changelogs for examples; they're out there, and boot-related or not, I don't see why plymouth should wind up in the same bucket as udev in terms of Debian collaboration
<psusi> such a computer though would only succesfully boot windows by luck
<psusi> since windows typically also puts its loader in a single full disk filesystem
<Keybuk> slangasek: udev is a good example of Debian collaboration?
<Keybuk> Marco and I get on very well
<cjwatson> psusi: no - it generally jumps to somewhere pretty early in the partition, and then ignores the BIOS from then on
<cjwatson> AFAICT
<Keybuk> by packaging separately based around a common upstream code, we don't have conflicts
<cjwatson> there may be some luck involved, but people seem to generally get the good bit of it
<slangasek> Keybuk: no conflicts, and no capacity to use any of the UDD tools for sharing packaging, either?
<Keybuk> slangasek: this hasn't proved to be a problem
<slangasek> you never have conflicts if you never merge :)
<psusi> the mbr jumps to the boot sector, which then has to use the bios to read the MFT to find NTLDR and then load that... then NTLDR continues to use the bios to access the disk in typical installations until it loads the kernel and passes control to that
<Keybuk> by not sharing the packaging, we've worked to minimise it
<Keybuk> so we carry no patches
<Keybuk> instead everything is done upstream
<psusi> so if the kernel happens to he stuck on a high sector of the disk the broken bios couldn't access, windows would fail to boot
<cjwatson> that may be true, but I wouldn't hear the complaints about Windows breaking, I only hear the complaints about Ubuntu breaking
<psusi> heh..
<Keybuk> slangasek: and, frankly, this works both ways
<Keybuk> I would begin a discussion about why Debian didn't base their plymouth packages off ours
<Keybuk> and why they aren't collaborating with us
<Keybuk> why their package isn't -XdebianY based off ours
<Keybuk> and I would argue that the fault is theirs, not ours
<Keybuk> and I do acknowledge and respect that there are those within Ubuntu with a more pro-Debian stance than me <g>
 * psusi wonders if windows 7 can boot from GPT disks... then we could use the damn bios partition
<Keybuk> but I don't think my "Ubuntu can be separate from Debian" stance is any less valid
<Keybuk> it's just in a different bit of the room ;)
<statik> hi chrisccoulson, ken pinged me about bug#536737. the debdiff looks good to me, but he wanted me to get a testing ack from you before uploading.
<Keybuk> personally, I'd prefer it if "packaging" just went away
<Keybuk> and upstream sources could include "this is how you build it" meta-rules
<Keybuk> so all you add as a distribution is things that are unique to your distribution
<chrisccoulson> statik - cool, i'm just testing it quickly now
<Keybuk> (and Ubuntu and Debian can be quite different - especially in areas I've touched <g>)
<chrisccoulson> statik, will you be ok to upload that, or do you want me to?
<psusi> oh well, at least I successfully got grub2 working last night for the first time... even got it to boot the system in an lvm root and no other /boot... even got it to boot from a snapshot I made then upgraded to lucid in it ;)
<slangasek> Keybuk: "why their package isn't -XdebianY" - because it's not meant to be about props for whose package was first, it's meant to be about having a consistent model for collaboration between Debian and Ubuntu so that other Ubuntu devs can look at a package without going cross-eyed at the equivalent of a criss-cross merge :)
<statik> chrisccoulson: oh, I thought you needed me to do the upload. I don't mind either way, if you have permissions no reason for me to do it.
<psusi> lvm on top of dmraid no less...
<slangasek> the Ubuntu toolchain works great for -XubuntuY, and suboptimally when you use -X for Ubuntu stuff; the Debian toolchain works not at all for -XdebianY
<chrisccoulson> statik, yeah, i think i've got permissions to upload that
<Keybuk> the Ubuntu toolchain works just fine?
<Keybuk> since most packags I touched are -X :p
<slangasek> it works to *your* satisfaction
<statik> chrisccoulson: excellent. thanks! ping me if it turns out you need me to do anything with it. thanks for your work on this.
<slangasek> I gather you don't use 'dch', for starters :)
<Keybuk> I do use dch
<slangasek> to autoincrement changelog version numbers?
<chrisccoulson> statik - no worries. micahg should probably take the credit though :)
<statik> indeed
<Keybuk> slangasek: yes
<Keybuk> slangasek: if you look through dch's own changelog, you'll see I even fixed dch so this was possible on ubuntu packages <g>
<pitti> hm, I alwasy have to use -U for that when working on Debian packages
<Keybuk> actually, that's a reasonable point
<Keybuk> dch fails here for working on Debian packages while running Ubuntu :p
<pitti> (but on a tangent, yay for consistent versioning and XubuntuY)
<slangasek> Keybuk: so you pass the extra argument every time you work on an Ubuntu package that's versioned as -X?  That's the kind of state I think we shouldn't have to keep track of :)
<Keybuk> it WFM
<slangasek> Keybuk: so anyway!  how's plymouth coming? :-)
<Keybuk> slangasek: I've not been able to do anything on it for a while, because someone's complaining about the versions I use ;)
<slangasek> you didn't have to take the bait ;)
<Keybuk> yes I did <g>
 * stgraber hears about plymouth and goes to look at his pet bug (though more likely to be cryptsetup's fault)
<Keybuk> stgraber: which one?
<stgraber> bug 509487
<ubottu> Launchpad bug 509487 in plymouth "[lucid] plymouth in initramfs doesn't know to chroot() when init does, can't load files from disk" [Medium,Fix released] https://launchpad.net/bugs/509487
<slangasek> the "when I type my passphrase, my laptop goes into a tailspin" one
<stgraber> slangasek: yeah, that one ;) though seems like I could provide more info to help debugging it. I'll need to reboot my laptop at some point ... two weeks I didn't reboot.
<Keybuk> says it fixed :)
<slangasek> Keybuk: the task on cryptsetup is still open
<Keybuk> I can solve that, through an accident in the archive
<_UsUrPeR_> How do I add network drivers to a ubuntu alternate install CD? The network driver (atheros on a new Acer netbook) is not being detected by the 9.10 alternate install CD, and because of that, I cannot install with a preseed.cfg over my local network.
<_UsUrPeR_> There is no need to discuss the process of managing an .iso, I can figure that out myself. Where do I put the drivers on the CD to have them loaded during the detection process?
<amitk> \sh: were you able to look at your LVM problem again?
<\sh> amitk: nope...but I think bug #527666 is exactly that...
<ubottu> Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/527666
<amitk> Keybuk: ^^^
<Keybuk> amitk: --debug would be nice
<\sh> amitk: sadly it was "incomplete", but reporter got down to the problems....and I set it to confirmed
<\sh> amitk: but you say, that update-initramfs fixes that boot problem?
<amitk> \sh: I thought it did. But now the problem is back. IOW, I booted completely once but it could be a red herring
<amitk> Keybuk: --debug of what?
<Keybuk> mountall
<\sh> Keybuk: help me with the --debug upstart bootmagic or whatever you need
<Keybuk> ?
<\sh> Keybuk: I'll just have a clean lucid server installation here...where I can create some nice VGs +
<Keybuk> the usual thing
<Keybuk> add --debug to mountall, capture output
<\sh> no update-initramfs or some other magic?
<Keybuk> no
 * \sh waits for the latest updates
<\sh> Keybuk: mountall logs where when --debug enabled?
<ogra> \sh, you will see where it logs :)
<\sh> let me guess...console? which means some redirection needs to be done...
<ogra> (so better also pipe it to a file when adding --debug)
<Keybuk> \sh: pipe to /dev/kmsg and use netconsole
<\sh> ogra: done ;)
<ogra> but that might be tricky since it remounts stuff
<Keybuk> (is my favourite trick)
<ogra> we should just all switch to ARM :) serial consoles everywhere !
<\sh> ok...my machine sits somewhere 50 meters away...damn..why me ;)
<ogra> then you need longARM :)
<highvoltage> heh
<\sh> anyways..I'm admin...it must be easy ,-)
<\sh> reboot
 * \sh runs
<JFo> james_w, I did :)
<JFo> working on it now
 * JFo wipes the grease off his hands and gets back to it
<\sh> hmmm
<\sh> amitk: it works now
<amitk> \sh: what did you do?
<amitk> I've been distracted with other things
<\sh> amitk: I installed the new updates...something changed
<\sh> now ssh is broken lol
<amitk> heh
<\sh> junior admin set two default gateways
<amitk> redundancy, you know :)
<\sh> well, yeah...but without policy routing ==> failed
 * ScottK hands \\sh http://bofh.ntk.net/Bastard_Indexes.html for inspiration about how to "counsel" the admin in question.
<\sh> ScottK: he won't get his after work beer...that's punishment enough ;)
<Daviey> I assumed amitk was refering to a different type of redundancy, for the junior sysadmin. :)
<\sh> anyways...there was now initramfs-tools update and a kernel update and a mountall update as it seems
<\sh> now which package could fixed that problem
<hggdh> pitti: could you please look at bug 442272 and suggest me who to contact?
<ubottu> Launchpad bug 442272 in coreutils "env crashed with SIGSEGV in setlocale()" [Medium,Confirmed] https://launchpad.net/bugs/442272
<\sh> the VG + LV wasn't created before the dist-upgrade...so I'm sure, that somehow someone fixed the bug without knowing
<pitti> hggdh: hm, at first sight this looks like a glibc bug
<\sh> amitk: did you dist-upgrade your machine regualary?
<hggdh> pitti: yes, this is what I think. But I cannot find any hits on the glibc BTS, nor on SUSE and Fedora
<amitk> \sh: not since the weekend
<\sh> amitk: can you try now?
<amitk> \sh: as soon as I can edit /root/etc/fstab from initramfs, /root being mounted read-only and not permitting me to remount it as rw
<\sh> amitk: rescue system from cd ;)
<amitk> i guess
<\sh> dear google, please provide android sdk for x86_64, because running sun-java6 in ia32 mode does work, but is no fun and I could write my fai frontend also for android, to deploy servers via nexus one while train hopping, kthxbye ;)
<\sh> amitk: when you tested it again, please comment on bug #527666 ... so we can track this in one place
<ubottu> Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/527666
<amitk> will do
<\sh> uh oh...junior admin got orders by senior network admin to do cisco ASR configuration on production machines...I'm not sure that this was a wise decision ;)
<highvoltage> lamont: hi there. bug 531546 is becomming quite critical as time runs short, and you seem to be the only one who can help with it
<ubottu> Launchpad bug 531546 in livecd-rootfs "Have a LTSP chroot built and placed on the Edubuntu DVD" [Undecided,New] https://launchpad.net/bugs/531546
<_UsUrPeR_> How do I add network drivers to a ubuntu alternate install CD? The network driver (atheros on a new Acer netbook) is not being detected by the 9.10 alternate install CD, and because of that, I cannot install with a preseed.cfg over my local network.
<_UsUrPeR_> the network card is an atheros AR8132 gigabit ethernet card.
 * Keybuk had an evil moment
<Keybuk> I wrote a text plugin for plymouth that looks a bit like our graphical one ;-)
<Keybuk> the colours match and *everything* :p
<amitk> \sh: still doesn't work. It got past the first filesystem and got stuck on the second one
<highvoltage> rhmm? as in aalib'd?
<Keybuk> highvoltage: no, just "ubuntu" written in the ordinary console font
<sebner> Keybuk: you are satan! :P
<Keybuk> it means if you have to use text, you're still purple! :D
<sebner> lol
<Keybuk> of course
 * highvoltage has to constantly work hard at not making references to sexual frustration
<Keybuk> one slight issue is that the default consoles turn purple too
<slangasek> Keybuk: but does it pick the color automatically from the image?
<Keybuk> so you have the whole Ubuntu 10,04 login: thing in purple
<_UsUrPeR_> ok, I have to ask, I have not really gotten much of a response to my question. Am I inquiring about driver support in the wrong place?
<Keybuk> so I must make sure sabdfl never sees that, or he'll want it by default <g>
<highvoltage> you realised you just highlighted him :)
<Keybuk> slangasek: there is no image!  It's a hex value tseliot hardcoded into the script plugin
<Keybuk> highvoltage: yes :p
<slangasek> Keybuk: hah
<amitk> Keybuk: purple console can't be that bad, considering our terminals in X are all purple now :-/
<slangasek> Keybuk: ok :)
<_UsUrPeR_> can you guys see what I am typing?
<highvoltage> _UsUrPeR_: no
<Keybuk> _UsUrPeR_: no, try typing in a larger font
<cjwatson> _UsUrPeR_: I can see, but haven't had time to answer
<_UsUrPeR_> ok, no problem. I just noticed I was not authenticated.
 * Keybuk never knew you could change the actual colours of the Linux VT to whatever rgb values you liked
<Keybuk> I always thought they were fixed
<cjwatson> _UsUrPeR_: it's easiest to look into the build system in debian-installer, which has lots of hooks for things like copying in extra files.  If you 'apt-get source debian-installer', look in build/README
<_UsUrPeR_> cjwatson: thank you so much. I'll look in to that now.
<\sh> amitk: ok...then there is another problem...for me it didn't work even with a partition != /home or whatever essential
<amitk> \sh: exactly, I have 3 volumes on that disk. /home, /shared, /private listed in that order in fstab. Sometimes it gets past home but gets stuck at shared
 * amitk calls it a night. Will debug tomorrow
<\sh> amitk: have a good night :)
<psusi> Keybuk: colors?  hell, I remember years ago on slackware 2 or 3 I used some utility to load a new font into the vga character generator for the console.. come to think of it, it was a pretty bad ass looking font... which I could find it again these days...
<Keybuk> http://people.canonical.com/~scott/purple.py
<Keybuk> ^ run as root on your console ;-)
<Keybuk> psusi: cjwatson likes loading silly fonts and keymaps on consoles
<psusi> I guess these days we have the fancy graphics mode consoles makes it easy
<Keybuk> there's probably a much easier way to do that, of course
<Keybuk> but it has amused me
<psusi> although slow as hell
<psusi> whenever I've tried mucking with the graphic consoles it has always been slow anyhow... that was the nice thing about the old method of doing it... since it still had the video card in text mode, there was no slow down
<Keybuk> yeah, fbcon is much slower than vgacon
<Keybuk> I'm surprised that nobody has done much work towards just using vte there
<Keybuk> then you could have pango-rendered anti-aliased fonts on your framebuffer
<\sh> Keybuk: implement this in lucid+1 , make it mature for the next LTS...and linux is ready for the desktop ,-)
<slangasek> this is akin to "I'm surprised the Libertarians don't hold the majority in Congress", right?
<slangasek> "wow, the craziest thing I can imagine is crazier than the world actually is"
<Keybuk> why crazy?
<Keybuk> we could get rid of vgacon, fbcon, etc.
<Keybuk> and a whole world of kernel code hurt
<\sh> dear linus, please remove console code from kernel, we don't need it
<Keybuk> shifting all worrying about such things to userspace
<slangasek> pango as a prerequisite for console output? :)
<psusi> someone asked on the forums the other day about the ability to do something akin to windows restore points and that got me thinking, so I've been looking into using lvm snapshots to time machine the entire system state for possible rollback... and I read that another distro is planning on using btrfs for this.. has anyone else done any work in this area?  are there any plans to for luicid+?
<Keybuk> slangasek: I think pango should be a prerequisite for everything!
<Keybuk> psusi: it's the kind of thing we could use btrfs for, yes
<Keybuk> I suspect our "plans" are much the same as other distro
<slangasek> pango-breaded chicken strips
<Keybuk>  1. wait for btrfs to be ready
<Keybuk>  2. wait for btrfs to be stable
<Keybuk>  3. wait for btrfs to be documented
<Keybuk>  4. ...
<elmo> 5. profit
<\sh> 3. use ZFS when oracle releases it as GPL
<Keybuk> \sh: btrfs is "better" than ZFS
<psusi> I'm trying to figure out which is better, use btrfs, or lvm snapshots with whatever fs you want
<slangasek> everything's better with btr
<cjwatson> but ZFS is released by Sun, it must be perfect
<\sh> Keybuk: somebody said this pointing to  reiserfs too
<Keybuk> \sh: btrfs borrows some things from reiser
<Keybuk> but not the murdering and killing
<elmo> I can't believe it's not btrfs
<\sh> Keybuk: that's the problem I think...reiserfs was really a pain to recover it by ontrack in the early days
<Keybuk> reiserfs lies about where it puts the bodies of your files
<psusi> last night I managed to use an lvm snapshot to clone the root, boot using the clone, then upgrade to lucid and could reboot into either the original fs or the now lucid snapshot... it seems though that the ability to merge the snapshot back into the original fs and discard the old system just went into the upstream kernel in .33, which doesn't look like it's going to make it into lucid
<\sh> good...now for some fun...having a burger and some beer...and tomorrow again a nice nightshift
<sebner> Keybuk: I somewhere read that btrfs will be usable (not that unstable anymore) with 2.6.34 or 2.6.35. Do you have any info on that?
 * \sh 's gone
<sebner> \sh: hf
<cjwatson> sebner: the warning sign is when you keep reading things like that, but the numbers keep changing
<sebner> heh
<Keybuk> sebner: right, I'll wait until they say "btrfs is usable"
<Keybuk> or, more to the point
<sebner> cjwatson: it didn't change from 34 to 35 but was explicitely said that way
<Keybuk> I'll wait until Linus says "I've been using btrfs for a while now, and I haven't killed the maintainer for destroying my filesystem"
<psusi> lol
<cjwatson> sebner: you say this as if this is the first time somebody said "btrfs will be usable with 2.6.<foo>"
<sebner> Keybuk: kk, so I just thought about offering a possibility to use it as filesystem (maybe with ubuntu 10.10 or 11.04) like we did with ext4
<sebner> cjwatson: As this was the first time I read that, yes ;)
<sebner> cjwatson: that's under the category of "lack of information" then :P
<cjwatson> http://kitenet.net/~joey/blog/entry/aloha_btrfs/ somewhat related
<psusi> that reminds me... I need to dust off the old e2defrag code and see if I can update it to work on ext4
<siretart`> sebner: AFAIUI, it is already usable for some cases, but has some obvious annoyances. e.g. the disk usage is notoriously wrong, and you'll get occasionally 'disk full' even when there is still plenty of space on the hard drive
<sebner> siretart`: that's why I asked about the .34-.35 stuff as there is should be really *usable*
<sebner> cjwatson: well right but this isn't the same like ext4 where Tso said "I used it the past 6 months without problems"
<kees> doko: for gcc -m32 I use gcc-multilib.  this package doesn't exist on dapper; what should I be using there?
<kees> doko: ah, nm, libc6-dev-i386 seems sufficient
<Laney> Right, I need help debugging a system lock up I get frequently on Lucid
<Laney> It seems related to high load
<Laney> magic sysrq still works, but nowt else
<xnox> Best way to request rebuild of a few packages? (no source changes)
<xnox> ^ What's the best way
<slangasek> xnox: that probably depends on why the packages need rebuilt
<slangasek> generally we only rebuild packages for library transitions or the like
<xnox> It is library transitions
<slangasek> it's probably best to coordinate directly with a developer on IRC for that; filing bugs would just be busy work.  What library?
<xnox> I've filed bug #536869
<ubottu> Launchpad bug 536869 in yorick-hdf5 "hdf5 1.8.3 -> 1.8.4 transition" [Undecided,New] https://launchpad.net/bugs/536869
<xnox> It's libhdf5 and it affects a few packages
<xnox> I've tested all the packages by rebuilding & testing them using lucid pbuilder and lucid installation
<xnox> slangasek: I did send an email about it ~2 weeks ago do ubuntu-devel-discuss and I had no reply =(
<xnox> should I create non-change source debdiffs?
<slangasek> no
<xnox> ok good (that seemed like duplication)
<slangasek> note that rebuilds of packages that depend on out-of-date libraries are done as a matter of course across the release cycle anyway; I'll have a look at these and see about getting them rebuilt today
<xnox> slangasek: Didn't know that. Thanks. But currently you can't install latest octave and any of these packages because of conflicting hdf5. =(
<xnox> s/But/Note that
<slangasek> erm, you really opened bug tasks against all the packages?
<xnox> Yeah, kind off. It's a single bug which affects all of the packages
<xnox> "meta-bug"
<slangasek> developers typically wouldn't look for such bugs before doing no-change rebuilds :)
<xnox> =) ok, fair enough. Is there a way for non developers to request no-chnage rebuilds similar to the scheduling of bin-nmu's in debian?
<slangasek> not formally, no
<slangasek> as I said, IRC is easiest
<xnox> Ok I'll know in the future then. It's just I've seen OCmal transition done like that with "meta-bug" but then again that one must be done in 6 rounds
<Laney> Previously I have just asked for them through the sponsor queue
<xnox> =/ well I spent about 12 hours rebuilding all of them and testing the once I use / have clue about. So I did as much as could =)
<slangasek> xnox: wasn't the ocaml transition mostly about syncs, rather than rebuilds?
<xnox> slangasek: not sure. As far as I understand it has syncs & rebuilds =/ maybe I'm wrong I don't use ocaml.
<slangasek> fair 'nuff
<slangasek> xnox: second package on the list (gnudatalanguage) has unsatisfiable build-deps (libplplot-dev)
<slangasek> xnox: so I wonder how you rebuild-tested this?
<slangasek> things that don't belong in a package clean target:
<slangasek> Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c9-py2.6.egg
<aliendude3500> Hi, I'm working on writing some code to make it easy to rearrange the title bar buttons for now users who don't feel like manually editing gconf settings. The code I have is written in Java, and works VERY well except for a slight bug that is preventing me from releasing the code. The application is able to generate the command to be ran as a String, and when I print the command to stdout, and run it manually, it
<aliendude3500>  works PERFECTLY, however, I can't get the program to automatically run the program. I'm not sure what is wrong with my code, as I have done similar things in the past, and I was able to make java execute commands using Runtime.getRuntime().exec(command);, but it's not working in this case. Because this project is Ubuntu (and GNOME) specific at the moment, I thought I'd ask here to see if anyone knows what could
<aliendude3500> be wrong. I'm almost positive it has to do with application permissions, but I tried signing the application, and even running it as root (Note: the command run by the program to change the title bar location does not need root permissions), but to no avail. I am open to suggestions.
<crimsun> kees: ping, do you have a moment for private query?
<kees> crimsun: sure, privmsg away
<kirkland> slangasek: i'm trying to use status to programmatically determine if a service is running or not
<kirkland> slangasek: evidently i can't op on the exit code of 'status foo' though
<kirkland> ubuntu@aussie:~$ sudo stop eucalyptus
<kirkland> [sudo] password for ubuntu:
<kirkland> eucalyptus stop/waiting
<kirkland> ubuntu@aussie:~$ status eucalyptus
<kirkland> eucalyptus stop/waiting
<kirkland> ubuntu@aussie:~$ echo $?
<kirkland> 0
<aliendude3500> The source code I have so far is located at: http://ad5300.pastebin.com/nSw80yTT
<slangasek> kirkland: indeed; you'd have to parse the output
<kirkland> slangasek: is that internationalized?
<kirkland> slangasek: and is it intended to be?
<slangasek> kirkland: dunno; you can LANG=C it if that's a concern
<kirkland> slangasek: great, thanks!
<kirkland> mathiaz: ^
<cjwatson> aliendude3500: quoting in Runtime.exec() doesn't work the way you think it does - it doesn't do full shell quoting, it just parses things into words
<cjwatson> ARGH
<cjwatson> aliendude3500: quoting in Runtime.exec() doesn't work the way you think it does - it doesn't do full shell quoting, it just parses things into words
<cjwatson> aliendude3500: you can see this if you write a small test case and run 'strace -f -etrace=exec' on it
<cjwatson> Runtime.getRuntime().exec("ls \"foo bar\"");
<cjwatson> turns into:
<cjwatson> [pid 26481] execve("/bin/ls", ["ls", "\"foo", "bar\""], [/* 73 vars */]) = 0
<aliendude3500> cjwatson, so how would I fix that?
<cjwatson> aliendude3500: I'd recommend that you use the list syntax instead
<cjwatson> so you'd have an array something like ["gconftool-2", "--set", "/apps/metacity/general/button_layout", "--type", "string", that_thing_you_build_up_with_minimize_etc]
<cjwatson> note that you don't have any shell-style quoting in that array - it's important to understand that quoting is handled by the Unix shell, and when a program starts all it sees is an array of arguments with no quoting
<aliendude3500> ah, I see, so I pass the arguments to exec as array elements?
<cjwatson> right
<cjwatson> if you need spaces in the arguments, you can just put them straight in there in a single element, no quoting required
<aliendude3500> cjwatson, I'll try to get that working.
<cjwatson> it's easier in some ways - I recommend using this form in any language when it's available, and these days nearly every language does have it available
<cjwatson> re permissions, all you need is execute permission on gconftool-2, which will already be there
<aliendude3500> does it automatically add spaces between arguments? or do I manually put those in?
<cjwatson> spaces between arguments are also parsed by the Unix shell
<cjwatson> so it doesn't add them, but it produces the same effect as if it did, if you see what I mean
<cjwatson> when you do   ls "a b" c "d e"   ls is invoked with argc == 4 and argv == ["ls", "a b", "c", "d e"]
<cjwatson> if you try to add spaces, those will show up in the arguments as if you'd quoted them, so you probably don't want to do that
#ubuntu-devel 2010-03-11
<aliendude3500> cjwatson, Thanks for the help! It works flawlessly! :)
<crimsun> slangasek: do I need a UserInterfaceFreeze exception for the pulseaudio task in bug 533877? The effect is an addition of the correct "Connector" in gnome-volume-control's Input tab.
<ubottu> Launchpad bug 533877 in alsa-utils "[SigmaTel STAC9228] Recording problem - integrated microphone no longer available on Dell XPS 1330" [Low,Fix released] https://launchpad.net/bugs/533877
<crimsun> ^^ anyone else on the release team
<crimsun> (err, am I supposed to be asking in -release?)
<Riddell> tjaalton, bryceh: any X dudes about?
<cjwatson> aliendude3500: good, happy to help
<bryceh> Riddell, mm?
<Riddell> bryceh: has the intel version string changed recently?
<Riddell> I mean the format
<Riddell> bryceh: kwin expects something like "20061017" but it seems to be "2009" "Q" "4"
<bryceh> Riddell, it quite possibly could have
<bryceh> Riddell, they have adopted a quarterly release process and it seems quite likely they'd change the nomenclature to suit
<bryceh> Riddell, probably worth making kwin's regex support either style
<xnox> thanks to everyone involved in UDD, bzr and lp! I've just did bzr merge-package and it did the right thing without generating a single conflict!
<cjwatson> nice, isn't it :)
<xnox> cjwatson: It's awesome. Thank you ;-)
<cjwatson> not I, really
<xnox> cjwatson: btw - there are no bzr-nightly builds for lucid
<cjwatson> I wouldn't know about that
<xnox> I can update cookbook branch (or do a merge proposal) but do i need to poke james westby about that?
<cjwatson> check whoever seems to be uploading the others, or runs the team, or whatever ...
<xnox> Yeah it's james =)
 * xnox is stuck in stone age without bzr nightly builds for lucid ;-)
<slangasek> crimsun: I don't think that needs a UI freeze exception
<bdrung> cjwatson: what's the status of bug #513197?
<ubottu> Launchpad bug 513197 in ntfs-3g "Please merge ntfs-3g 1:2010.1.16-0.1 (main) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/513197
<cjwatson> I intend to apply for a feature freeze exception for it, but have not got round to it yet.  no other statuss
<cjwatson> *status
<cjwatson> ArneGoetje: gbrainy.mo is in both base and gnome langpacks, breaking DVD builds.  Where's a good place to report this sort of thing, that isn't specific to a single package?
<ArneGoetje> cjwatson: those exceptions are handled individually in langpack-o-matic
<ArneGoetje> cjwatson: so, I take it that it should be only present in the gnome langpacks?
<cjwatson> ArneGoetje: I don't know; I just know it shouldn't be in both :-)
<ArneGoetje> cjwatson: ok, I'll check
<cjwatson> err, it's part of what used to be gnome-games isn't it?
<cjwatson> and it's in ubuntu-desktop and not kubuntu-desktop
<cjwatson> so yes, I think that would make it gnome langpacks
<ArneGoetje> cjwatson: ok
<ArneGoetje> cjwatson: I will add an override to langpack-o-matic.
<cjwatson> great, thank you
<cjwatson> will there be another langpack upload before beta-1?
<slangasek> I think it's important that we have buildable DVDs for beta-1
<cjwatson> agreed, I was wondering whether new langpacks were planned anyway, or would need to be added
<ArneGoetje> cjwatson: current situation is that in the -base langpacks (full-export), gbrainy.po is in the base package. In one of the delta updates it seems to have switched over to the gnome langpacks. So, what I can do now is to manually delete it from the gnome langpack updates and re-upload them.
<ArneGoetje> cjwatson: next full-export is scheduled for Saturday night (UTC), so new langpacks will be available on MOnday
<ArneGoetje> cjwatson: and with the next langpacks gbrainy.po should be in the gnome langpacks only.
<cjwatson> that sounds workable
<cjwatson> as long as we get the delta fixes before Saturday, since we'll need to iterate some more on DVD builds and need as much lead time as we can get
<ArneGoetje> cjwatson: yes, I will do it right away
<cjwatson> they've been failing since January on and off, so we can't expect them to be particularly sound :(
<cjwatson> (not your fault, this is the first time I've seen this particular error)
<cjwatson> great, thank you
<ArneGoetje> cjwatson: :)
<maco2> Any archive admins around? https://edge.launchpad.net/ubuntu/+source/spim/8.0-0ubuntu1 should be in universe, not multiverse
<maco2> (license changed this release; it's now 3-clause BSD)
<ArneGoetje> cjwatson: ok, so gbrainy will be without translation updates for this short period, but will get them back on Monday.
<maco2> cjwatson: can i borrow you a moment?
<slangasek> maco2: is there a bug report open for this?  There's no interface that lets us comment on component changes, so a bug report is our best bet for figuring out why it moved if there are questions later
<maco2> slangasek: i can go file one
<slangasek> appreciated :)
<maco2> slangasek: sure, now there's bug 537063
<ubottu> Launchpad bug 537063 in spim "spim 8.0 should be moved from multiverse to universe" [Undecided,New] https://launchpad.net/bugs/537063
<ArneGoetje> cjwatson: gaa, doesn't work this way... need to run the complete delta update again, otherwise it will mess up the packages... should not take that long...
<slangasek> maco2: and promoted
<maco2> slangasek: thanks
<micahg> ArneGoetje: I wanted to ask you about bug 534417
<ubottu> Launchpad bug 534417 in thunderbird "Thunderbird: localization not installed automatically" [Undecided,Confirmed] https://launchpad.net/bugs/534417
<ArneGoetje> micahg: right, need to move that bug to software-center. That function is already implemented in language-selector and software-center just needs to call a function to get this. I will add a comment and move it over later, when I'm done with the language-packs
<micahg> ArneGoetje: great...I also wanted to ask you about the template for the firefox langpacks
<micahg> do  you want to switch from firefox-3.6 to firefox after beta 1?
<ArneGoetje> micahg: template has been fixed
<micahg> ArneGoetje: it's firefox now?
<ArneGoetje> micahg: oh, that... no, we can only switch when 3.0 and 3.5 are out of life and firefox has been upgraded to 3.6 for all releases.
<micahg> ArneGoetje: oh, I thought it was going to be sooner...ok, I'll talk to asac about the translation menu link in ubufox then
<ArneGoetje> micahg: ok, thanks
<leagris> Hello, anyone interested in kernel BUG at /build/buildd/linux-2.6.31/fs/btrfs/inode.c:735 ?
<persia> leagris: I suspect a number of folk are.  I'd recommend running `ubuntu-bug linux` to gather up a lot of the information about the bug and your system, and then report with as much additional detail as you can to the bug tracker.
<leagris> persia, here is a extract from dmesg: http://pastebin.ca/1832949
<persia> leagris: Thanks, but I'm not someone who can understand the problem from that.  Please do file a bug.  IRC is a poor place for bug reports, because lots of folk sleep.
<persia> (well, other reasons too, but that's a big one)
<leagris> :)
<leagris> thanks persia
<ccheney> for some reason i can no longer ssh to my systems foo.local address, anyone know what could cause that?
<ccheney> hmm it works after resetting the ethernet connection
<emgent`> aloha jono
<jono> hey emgent`
<nonix4> How can I use the *-dbg* packages with gdb?
<persia> nonix4: Install the -dbg package.  Start gdb.  If you have to do something special, file a bug.
 * nonix4 ponders (a bit offtopicly) which alternate browser to use since the buggy app in this case is firefox in infinite loop and gdb says "no debugging symbols found"
<micahg> nonix4: what's wrong with firefox?
<nonix4> It got to infinite loop switching mouse cursor between pointer and hand. Thoughts on how to analyze situation better? gdb backtrace doesn't tell much to untrained eyes with missing symbols
<micahg> nonix4: what were you hovering over?
<nonix4> Not sure anymore... one of {a login input, submit button, help href, another tab}. But regarding the -dbg packages I was apparently just missing some of them (guess there're no dependancies between them)
<nonix4b> oh great, X froze on attach to firefox...
 * nonix4b makes a mental note of debugging X apps requiring remote connection for the control
<micahg> nonix4b: well, if you get enough info feel free to file a bug and I'll try to get to it at some point
<micahg> pitti: could you please check on the lucid retracer (bug 533357 has been waiting 4 days) -- thanks
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/533357)
 * nonix4b considers filing a bug on debug symbols of gdb itself missing
<pitti> Good morning
<RAOF> pitti: Good morning.
<nonix4> 'k "kill -CONT $ff; kill -9 $gdb" got X back alive, so may actually be able to get some information out of it :)
<pitti> ev: oh, nice! usb-creator has completed 140% :)
<emgent> Riddell, ping.
<emgent> morning pitti
<emgent> apachelogger, ping too
<dholbach> good morning
<amitk> morning dholbach
<emgent> hey dholbach ! how goes?
<emgent> long time to saw you
<dholbach> hey amitk, hi emgent
<dholbach> how are you guys doing?
<emgent> really busy with my job :-\
<emgent> and anyway i have a not good news for us..
<lifeless> ?
<emgent> lifeless, ola, are you in involved in canonical webapps ?
<lifeless> somewhat
<lifeless> why?
<emgent> i have some security hole to notify.
<lifeless> so do so
<lifeless> we use launchpad, it has support for that
<emgent> are not ubuntu stuff bug.. are canonical webapps issue
<emgent> but if you prefer.. i will notify in LP.
<emgent> dholbach, when back query me
<dholbach> I'm all here
<spaetz> would opening a kernel bug with patch to support the Marvel 8431 (which is in newer netbooks) be appropriate?
<persia> spaetz: You could, but I think they kernel team likes git-formatted patches to their mailing list (although I may be mistaken).
<persia> spaetz: You ought get guidance in a bug if you file it though.
<dholbach> spaetz: https://wiki.ubuntu.com/KernelTeam/KernelPatches
<dholbach> spaetz: having the patch in a bug is good, but the kernel team prefers discussion on their mailing list
<alkisg> I'm trying to use pam_ck_connector to make local LTSP sessions CK-aware, but I don't understand how I'm supposed to export the CKCON_X11_DISPLAY_DEVICE environment variable (i.e. export doesn't work). It does work if I put it in /etc/environment, but I want it to have different values per session, so I don't want it in a global file. Would someone care to give me some hint?
<dholbach> https://wiki.ubuntu.com/MeetingLogs/devweek1001/KernelPatches has some good discussion about it too
<spaetz> persia, dholbach thanks. I can point to the corresponding git commit for the opensuse kernel, hope that is fine. I will send a mail to the mailing list.
<dholbach> awesome
<lifeless> emgent: we have products in lp for many/most of our webapps
<lifeless> emgent: which ones are affected? you can privmsg if you want
<spaetz> dholbach: filed bug 537168. Thanks for your pointers.
<ubottu> Launchpad bug 537168 in linux "[lucid] add support for Marvel 0x8431 (88E8059)" [Undecided,New] https://launchpad.net/bugs/537168
<dholbach> no worries :)
<dugger5688> Anyone got some tips on where to get started in bug fixing? I want to get into developing for ubuntu, but for obvious reasons don't want to dice into the deep end trying to start my own project.
<dugger5688> dive*
<slangasek> bigon: gupnp-igd FTBFS in lucid because of a problem with the test suite, which I assume was enabled as an MIR requirement; there's a fix upstream for getting the test suite to *build*, but enabling 'make check' in debian/rules still causes the package to FTBFS even with version 0.1.6-1 - do you have any ideas on this? (bug #534311)
<ubottu> Launchpad bug 534311 in gupnp-igd "gupnp-igd ftbfs on all archs in lucid" [Critical,Triaged] https://launchpad.net/bugs/534311
<dholbach> dugger5688: try https://wiki.ubuntu.com/MOTU/GettingStarted
<slangasek> bigon: it looks like it might need dbus running for the testsuite
<dugger5688> Thanks, found my way there already :-) Will go through it in the morning.
<bigon> slangasek: well there is the same bug in debian
<slangasek> bigon: in Debian the testsuite isn't enabled - do you mean this is why it's not enabled?
<bigon> wait I check
<sabdfl> Keybuk: purple consoles, +1 ftw
<bigon> slangasek: it could be related to nm support (and the fact that dbus-glib is not working properly when initialised inside a thread, dixit gupnp-igd upstream
<bigon> slangasek: I'm planning to make a gupnp-igd without nm support in debian to fix a related FTBFS
<directhex> seb128, moonlight 2.2 uploaded. good luck to whomever needs to clear that through NEW.
<seb128> directhex, thanks!
<directhex> 1.0.1-3ubuntu0.xul191build2 to 2.2-0ubuntu1 (36.1 MiB)
<slangasek> bigon: ok - if you decide to fix it in Ubuntu as well, please note that I've merged up to 0.1.3-4 (testing) already on the lp:ubuntu/gupnp-igd branch, so if we continue with 0.1.3+fixes, would be good to preserve that
<cjwatson> maco2: did slangasek cover what you wanted, or was there something different you wanted to ask me about?
<bigon> slangasek: do you have logs of gupnp-igd 0.1.6 FBTFS?
<slangasek> bigon: posted to the bug
<bigon> slangasek: oh it's not a crash (I thought so) well then It could be http://bugzilla.openedhand.com/show_bug.cgi?id=1979 then
<ubottu> bugzilla.openedhand.com bug 1979 in gupnp "g_warning make gupnp-igd test fails" [Normal,New]
<slangasek> bigon: ah, looks right, yes
<Mikerhinos> hi
<alkisg> Does /etc/security/pam_env.conf have access to the normal environment variables, or it can only access pam-environment? E.g. I'm trying to put MYVAR DEFAULT=${LANG} there, but it doesn't work for me...
<spaetz> cjwatson: thanks for fixing ubiquity so fast. Glad I could help with my logs
<pitti> apw: do you think there's a chance to fix bug 397734 for lucid? it still causes a lot of grief, and OEM team also has trouble
<ubottu> Launchpad bug 397734 in devicekit-disks "can't eject cdrom with hardware button" [Medium,Fix released] https://launchpad.net/bugs/397734
<pitti> apw: (it's basically flipping the default value of /proc/sys/dev/cdrom/lock to 0)
<pitti> apw: we could set it in /etc/sysctl.d somewhere, but first that's racy (doesn't get active if the cdrom module isn't loaded yet), and also means extra parsing during boot, etc.
<pitti> apw: hm, I guess it could be a modprobe.d file, but it'd still feel cleaner to set the default right at the source
<apw> pitti, i'll have a look
<pitti> apw: thanks
<seb128> siretart`, hello
<siretart`> hi seb128! how are you?
<seb128> siretart`, good, you?
<seb128> siretart`, I'm starting that gst-ffmpeg against ffmpeg discussion with pitti again
<pitti> hey siretart`, wie gehts?
<siretart`> thanks, fine.
<siretart`> danke! :-)
<seb128> since he was not around the other day
<seb128> siretart`, can you summarize the issue between both?
<seb128> does gst-ffmpeg need a newer or older ffmpeg to work correctly?
<siretart`> ah, another round in the gst-ffmpeg vs ffmpeg deathmatch :-) - okay, let the fun begin
<seb128> is downgrading or upgrading ffmpeg to that version an option?
<pitti> siretart`: background is, ffmpeg is pretty prone to security flaws (and bugs, too, I suppose), so if we can avoid a copy, we should
<siretart`> okay, short recap: ffmpeg 0.5 is now pretty exactly 12 months old, and has since then gained quite a lot of additional codecs
<siretart`> gst-ffmpeg upstream has decided that these additional codecs are important for them and switched from tracking the 0.5 release branch (which we use as system ffmpeg) to ffmpeg trunk
<pitti> seb128: 0.5+svn was in karmic as well, so I guess that had the same problem?
<siretart`> naturally, some details have changed, and gst-ffmpeg has strongly advised me against compiling it against 0.5
<seb128> pitti, ok, seems I got my version wrong, better to read what siretart` is writting
<siretart`> slomo however has identified which parts don't work against 0.5, and patched them out
<pitti> siretart`: ah, so the issue is that gst-ffmpeg has a _newer_ copy than our system ffmpeg?
<siretart`> pitti: exactly. gst-ffmpeg will track the 0.6 branch as soon as it opens (maybe we'll create that branch this weekend, maybe next weekend, we'll see)
<siretart`> pitti: regarding security issues, does the security team really care about the security patches in the ffmpeg package? I did write a mail to security, but they were rejected because "no testcase"
<siretart`> in the mean time the patches I did for the debian package got integrated in 0.5.1
<pitti> hm, I had assumed they did; kees, jdstrand, mdeslaur ^ ?
<siretart`> and are now in lucid. but for karmic the patches are still missing
<seb128> siretart`, should we understand from that using the system 0.5 ffmpeg will mean cutting or features and codecs which would work using the copy then?
<pitti> siretart`: ah, so is there actually a problem in lucid then?
<seb128> or->on
<kees> I really care about security patches.  :P
<kees> I'm not sure I understand the question, though.
<siretart`> pitti: 0.5.1-1ubuntu is in lucid and has these patches. all sec related patches I'm aware of are included there
<seb128> kees, the question is "do you care if gst-ffmpeg uses a ffmpeg copy" ;-)
<pitti> siretart`: I meant, you said that slomo patched out the bits of gst-ffmpeg which don't work with our 0.5.1 ffmpeg lib
<siretart`> seb128: yes, trunk always has (almost per definition) more codecs then a release branch
<pitti> siretart`: so it seems that in lucid it's actually fine?
<kees> `I did write a mail to security, but they were rejected because "no testcase"` ?  surely not security@ubuntu.com ?
<siretart`> pitti: lucid should be fine
<kees> seb128: yes, I care -- it absolutely should not use an embedded copy.
<pitti> siretart`: *phew* great to hear
<siretart`> kees: I'll fetch the message id
<seb128> siretart`, if lucid should be fine I'm getting confused about your ping from the other day
<siretart`> seb128: security wise. gst-ffmpeg in lucid is compiled against 0.5, which upstream strongly opposes
<seb128> why, if it works fine?
<seb128> I had the impression you told me it was open door for crasher issues
<seb128> but now you say it's fine
<siretart`> pitti: kees: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550442#35 this is the last message I got from the ubuntu security team, I think
<ubottu> Debian bug 550442 in ffmpeg "ffmpeg: deluge of crashes due to missing input sanitization" [Serious,Fixed]
<siretart`> I understood the last sentence as "we need an proof-of-concept exploit" for each crash
<siretart`> which I really don't have the time for
<pitti> that would be weird
<pitti> most security issues we fix don't have one, AFAIK?
<kees> siretart`: he meant "someone needs to analyze these crashes to see if they're really security issues."
<siretart`> seb128: yes, and that is right. we are having two seperate discussions here
<persia> I'd hope that we weren't writing test cases for every security hole.  That code would be dangerous.
<kees> persia: we do try -- how else to better validate a vulnerability has been fixed?
<siretart`> kees: I've discussed each single patch with other ffmpeg developers, and I think only one or two were classified as 'not security relevant'
<persia> Oh my!
<lifeless> persia: kees has bee doing this for years :)
<lifeless> s/ee/een/
<kees> persia: have you not see lp:~ubuntu-bugcontrol/qa-regression-testing/master  ?
<persia> kees: I've not looked in detail, no.
 * persia wonders how the publication of that branch intersects with UEC images
<siretart`> seb128: I'm saying that *ffmpeg* itself should be fine security wise. I didn't say that about gst-ffmpeg!
<seb128> siretart`, I've to admit I'm confused about the discussion now
<seb128> siretart`, I though the discussion was about having something which is stable against something not tested and crashy
<kees> siretart`: if there are open security issues in ffmpeg in releases of ubuntu, we need to track them.  mdeslaur seemed to be identifying where various things were fixed already?  this list needs to be clarified, etc.
<seb128> siretart`, and now it turns to be a discussion about ffmpeg security which I've no real clue about or interest in
<siretart`> kees: pitti: anyway, in the mean time a DSA has been released about these issues, so the patches could be taken straigt from there. however, looking at the latest commits svn://ffmpeg.org/branches/0.5 might be helpful as well
<seb128> siretart`, so I will let you guys sort that one
<siretart`> seb128: okay, let's discuss open security issues first and then return to gst-ffmpeg
<seb128> siretart`, thanks
<siretart`> kees: I haven't heared anything back from mdeslaur since then, no idea if he continued to track that issue
<kees> siretart`: okay, I'd like to get it clarified.  specific what patches are missing for which ubuntu releases of ffmpeg.
<siretart`> kees: for intrepid, I think taking the patches from the debian DSA would probably be easiest, although I didn't check if I haven't missed to backport some patched back then. I think there might be even some newer patches to check
<kees> siretart`: can you perhaps open a new LP bug (tracking this in a debian bug probably isn't the clearest way to handle this)?
<siretart`> kees: for jaunty and karmic (they are effectivly both 0.5), replaying the patches from the 0.5 release branch should be easiest
<siretart`> okay, I can do that
<siretart`> shall we return to the issue of gst-ffmpeg then?
<kees> siretart`: cool thanks.  when mdeslaur wakes up, he can poke at it more.  I'm overdue for sleep.  :) g'night!
<ev> pitti: :)
<pitti> siretart`: so now I'm confused; I thought it would work well in lucid now, with slomo's patches?
<siretart`> kees: good night! :-)
<pitti> kees: sleep well!
<siretart`> pitti: well, it is the 'well' that upstream objects. They highly doubt that it works 'well'
<siretart`> it builds, but nobody really tested that combination
<siretart`> and I have to admit that I'm not going to look to deeply into crashers that come via that way
<pitti> siretart`: if you feel too unsure about it, perhaps we could downgrade to an earlier gst-ffmpeg from a time when 0.5.1 was current?
<siretart`> pitti: yes, sticking to the version of gst-ffmpeg from karmic seems to me a safe solution
<pitti> siretart`: so we should go back from 0.10.10 to 0.10.9?
<seb128> or use the gst-ffmpeg copy?
<seb128> I don't fancy using year old code
<seb128> especially for multimedia, it often means lack of support for codecs, etc
<pitti> well, we should either upgrade ffmpeg to trunk or downgrade gst-ffmpeg
<siretart`> pitti: that would make us stick to a codebase that we know, but it also would make seb128 and many users sad because we're missing lots of codecs
<pitti> having two copies of ffmpeg really doesn't make sense, either from security or maintenance POV
<pitti> if we keep a newer ffmpeg in gst-ffmpeg, then we'd still have those codec/bugs problems in the system library
<seb128> pitti, it would make sense in the sense it would provide a decent multimedia experience to our user
<pitti> seb128: how wouldn't that be provided by updating the system library?
<siretart`> pitti: as for long term plans, I plan to work on the 0.6 release soon, and bilboed (gst-ffmpeg upstream) has indicated that they will start tracking that branch as soon as it opens
<apw> pitti, this CDROM lock thing ... i just played with mine and i am unsure as to what the real issue here is... as far as i can tell the button works when you are allowed to eject the CD and not when you are not (its in use) ... are we saying we want to allow eject even on mounted FSs?
<seb128> pitti, you are trading distro work against user experience, ie arguing that we care about having less work and not about providing a good user experience there
<pitti> seb128: but if it's not ready for release yet, then that's just bad luck and timing
<siretart`> pitti: I didn't push 0.6 for lucid because I cannot commit to transition all package in ubuntu from 0.5 to 0.6. I have really no idea how much breakage that will cause
<pitti> so
<siretart`> for me, the plan was to go with 0.5 for both lucid and squeeze
<seb128> pitti, by experience upgrading system ffmpeg is not trivial
<pitti> we are saying that ffmpeg 0.5 is stable, and 0.6 is not there yet
<apw> pitti, also having just tried it, when you rip out the disk the fs remains mounted from there on ... and nautilus (i think) triggers 5 errors to syslog every few seconds until its reinserted or unmounted
<seb128> pitti, right
<siretart`> bilboed was fully aware of that plan but decided to go for trunk anyways
<pitti> apw: that's a separate bug indeed
<siretart`> and I can udnerstand him in some ways. there are really very interesting new features in 0.6
<pitti> seb128: so either 0.6 is ready for release, then we can update to it, or it's not, then I don't see a major reason why we shouldn't stay with 0.5?
<apw> pitti, i also can't see what would stop eject working in the middle of a disk burn ...
<siretart`> but since we are way past feature freeze, I did considered upgrading as an option
<pitti> seb128: do you really think 0.5 was so bad? video codecs have worked great in linux for at least a decade, after all
<siretart`> upgrading gst-ffmpeg to use ffmpeg 0.6 would require a FFe anyway AFAIUI..
<pitti> seb128: do we have lots of bug reports which would be fixed with 0.6?
<siretart`> pitti: well, we could also see it that way:
<seb128> pitti, I don't know enough about ffmpeg to say
<siretart`> pitti: for lucid+1, I will very soon upload a ffmpeg 0.6 package as system ffmpeg
<seb128> pitti, I just know that a year is lot in multimedia things
<pitti> seb128: but you just argued that we need 0.6 for good user experience?
<seb128> pitti, and sirestart said slomo had to turn codecs and things off since they didn't work with ffmpeg 0.5
<siretart`> pitti: so as soon as ffmpeg 0.6 is releasd, the security team would have to care for 0.6 as well anyways..
<seb128> pitti, I'm just saying that based on siretart`s comment
<seb128> "users sad because we're missing lots of codecs"
<pitti> siretart`: that's the natural flow of things, yes; but they'd have to care about it much longer if it's in lucid, too;
<pitti> siretart`: and apart from the seucrity side, if 0.6 isn't stable yet, it sounds like we would introduce more problems than we solve
<pitti> I mean seriously, how many video formats cause problems on recent linux? My feeling is "hardly any"
<pitti> but we do have a lot of _bugs_ with playing back videos indeed
<siretart`> pitti: seb128: http://paste.ubuntu.com/393150/ is the change log in ffmpeg trunk so far since the 0.5 release
<pitti> (thinks like searching in totem, etc.)
<kees> pitti: AVC HD is miserable currently.  /me really goes to bed now
<siretart`> I even had been presented a backport of wmapro for 0.5...
<pitti> kees: in totem?
<kees> pitti: right.  and not even mplayer can play it right.  the only thing that seems to get it right is mythtv's internal player.
<siretart`> pitti: AVC HD playback is pretty bad shape in all ubuntu packages right now
<pitti> seb128: so, I guess we can argue either way (for 0.5 or 0.6), but I really object to having _both_ as a rational answer
<kees> there will always be new codecs.
 * kees votes for 0.6 just because it'll be easier to get fixes for in 3 years.  :)
 * kees really really goes to bed
<pitti> well, that's fair enough
<seb128> pitti, I've not spent enough time looking at bugs and I don't know enough about gst-ffmpeg and ffmpeg to have an argumented answer there
<pitti> but that wouldn't help you at all if gst used 0.6 and everything else 0.5
<siretart`> pitti: there are no 'stable' releases. ffmpeg development is way to fast to even think about that. It took years to convince upstream to do at least snapshot releases. ATM, its mainly me who tries to identify security related changes in trunk and backports them to release branches
<pitti> siretart`: so, what's your recommendation right now?
<seb128> pitti, I'm mainly trying to avoid us realizing in one month that we are flooded by totem gst-ffmpeg crash bugs because we use a non support ffmpeg and gst combinaison
<ttx> asac: about bug 526480 -- you think you'll have time for it ?
<ubottu> Launchpad bug 526480 in liblog-log4perl-perl "[MIR] liblog-log4perl-perl" [High,New] https://launchpad.net/bugs/526480
<ttx> otherwise may be best to assign it to someone else in MIR team
<seb128> pitti, and being stucked in a sucking position then for the lts because it's too late for changes
<pitti> seb128: right, and I'm trying to avoid that flood by suddenly switching to a new upstream ffmpeg in gst which nobody tested yet..
<seb128> well it's an internal copy
<seb128> it has been tested by upstream
<seb128> and switch the configure flag back is easy
<siretart`> pitti: with following three options: A) compiling new gst-ffmpeg against 0.5 B) reverting to old gst-ffmpeg and C) new gst-ffmpeg with internal copy
<siretart`> pitti: I'd probably vote C>B>A
<seb128> same here
<pitti> siretart`: I'm interested why you favor C
<seb128> since the first one is unsupported and crashing
<pitti> it seems like the least sensible option to me
<siretart`> pitti: it is the only option blessed by upstream
<seb128> it's the one providing the best user experience
<pitti> siretart`: like, "get twice the amount of bugs for double the price"?
<seb128> at a cost for us to fix issues in that copy
<seb128> pitti, well, we have to choice is we care about having less work or about having a better user experience
<siretart`> let me ask in a different way
<seb128> since the less work solution will bring trouble and crashes
<siretart`> who cares for gst-ffmpeg bugs these days?
<pitti> so what about D) update system ffmpeg?
<siretart`> in terms of crashers?
<seb128> care in which sense?
<seb128> nobody work on those
<seb128> but I would prefer not having crashers there
<seb128> I do care about what we ship to our users
<pitti> seb128: you are sure that updating ffmpeg won't bring new problems?
<seb128> pitti, we would not update, we would use the gst-ffmpeg ffmpeg copy with is what upstream work on and test
<seb128> and which is the version which probably match best what gst-ffmpeg handle
<pitti> seb128: sure we would
<siretart`> pitti: D) would be an option as soon as we have an 0.6 release branch, or even better, the 0.6 release. I don't think that will happen in time for lucid
<pitti> whether it's linked or internal, it's still a new version
<persia> seb128: But why not take the ffmpeg gst-ffmpeg recommends and use that for system ffmpeg?
<seb128> D) would also mean a transition
<seb128> how much other things would that break?
<siretart`> pitti: and I cannot commit for doing that transition in a couple of weeks. the last ffmpeg upgrade was pretty painful
<seb128> persia, because we are not sure how it would impact on everything else using ffmpe
<seb128> persia, ie xine, vlc, ...
<seb128> persia, what sirestart says
<persia> And given schedule, urk.
<pitti> siretart`: yes, I wasn't going to ask you to actually; (I favor neither C nor D, FWIW, but it seemed prudent to at least complete the option table)
<siretart`> I can say for sure that our mplayer won't remotely compile against 0.6
<siretart`> but mplayer is special
<siretart`> anyway
<seb128> pitti, well new version right, but with limited scope, it just needs to be tested on gst-ffmpeg, we don't risk stability issue for ie xine
<seb128> or mplayer or vlc or etc
<pitti> so, I don't think I have any new arguments at this point; seems we just need to agree to disagree then :)
<siretart`> I think the safest option would be to revert to lucid's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg
<pitti> siretart`: s/lucid/karmic/ ?
<siretart`> err, of course
<siretart`> I think the safest option would be to revert to karmic's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg
<siretart`> and upload a newer gst-ffmpeg to lucid-backports that uses the internal copy of ffmpeg
<seb128> how much drawback is that compared in format supports, bug fixed, etc?
<pitti> (we should probably go to 0.10.9-3, not -1, but details..)
<seb128> siretart`, do you know what slomo plans to do for debian?
<siretart`> seb128: no idea, I havn't seen him on irc for quite some time now
<siretart`> I think he is going with newer gst-ffmpeg compiled against 0.5
<siretart`> read: option A
<seb128> so it seems pitti and security team stand strongly against C
<seb128> so we have choice between downgrade or stay with that unsupposed binaison
<seb128> how can we get feedback on well or not gst-ffmpeg + ffmpeg 0.5 is working or crashing or...?
<seb128> on *how* well
<pitti> my personal gut feeling is A>B>D>C, but since it seems that D) is not practical, it reduces to A>B>C
<siretart`> I'm told that gst-ffmpeg comes with an extensive testsuite
<pitti> seb128: hm, we could look at gstreamer/totem/gst-ffmpeg bugs since lucid?
<RAOF> I guess we could run totem over a test-suite of video files; I know they exist.
<siretart`> perhaps running that would give us more insight?
<pitti> siretart`: sounds like a good idea
<pitti> everyone watch pr0n for a week and report the results!
<seb128> ok, so let's stay on A and try to do some testing with it?
<seb128> maybe talk to the qa team about organizing some testing on that?
<seb128> just to know where we stand
<siretart`> seb128: perhaps you could try talking to upstream about that issue?
<siretart`> I mean with your ubuntu gnome guy hat on?
<pitti> looks like http://live.gnome.org/GStreamerMediaTest
<seb128> what issue? how to test?
<siretart`> about option A) anyway despite their explicit disapproval
<siretart`> this choice is not going to please them
<seb128> siretart`, who did you talk to upstream about that before?
<seb128> I will get in touch with them
<siretart`> seb128: to bilboed
<seb128> ok thanks
<siretart`> seb128: he approached me in #ffmpeg-devel
<siretart`> not sure if there is an gst-ffmpeg specific dev channel
<seb128> siretart`, #gstreamer will do
<siretart`> I'll lurk
<Keybuk> well, I can replicate the press-ENTER-to-kill-X bug
<pitti> Keybuk: ah, when you see the mouse cursor on a VT?
<siretart`> anyway, need to return to work now, will file the sec bug later
<pitti> siretart`: thanks a lot for the heads-up!
<Keybuk> pitti: no, fixed those bugs - now you see full X with gnome panels
<ogra> funny, that bug vanished for me exactly today
<pitti> yay
<pitti> ogra: oh, how? nothing changed in that regard, except perhaps the moon phase to influence the chances?
<sladen> I got the mouse-on text vt... it even changes cursor when you hover over the GDM login box
<sladen> (not that you can see it)
<ogra> pitti, well, then its the moon phase :) for the first time i could hit enter in the keyring dialog without ending up at gdm
<pitti> ogra: I suppose it's just because your CPU now starts slightly warmer with the winter end, so the booting is 0.01 s faster
<ogra> hmm, its actually slower
<ogra> but i think thats due to ureadahead reprofiling, i didnt reboot twice
<ogra> 11s
<apw> Keybuk, as some additioanl data i think that the die on return is occurs every time if you use nomodeset ... seemed to on my mini10
<apw> pitti, ok this new behaviour is already being complained about ... that you can eject and it stays mounted ... which it would
<apw> pitti, presumably due to the devkit-disks cahnge which makes it work for some types of mount
<apw> bug #476654
<ubottu> Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged] https://launchpad.net/bugs/476654
<pitti> apw: right, it's that bug
<pitti> apw: it's not clear yet whether that's a kernel bug or feature
<pitti> apw: the kernel already cleans up stale mounts for e. g. USB sticks, if you yank them out
<pitti> apw: if it's a feature that this isn't done for CD-ROMs, then we need to add userspace code to listen to remove events and call umount -l
<apw> pitti, its not at all clear to me letting you take it out is good at all
<pitti> apw: I talked to cooloney-Beijing, and he was going to look into it
<ogra> pitti, but as you explained to me yesterday the kernel also powers down the device
<ogra> (in the usb case)
<apw> pitti, seems we are chaniging good behaviour just because people don't know what their eject button means
<pitti> apw: there's no other way for e. g. DVDs
<pitti> apw: udisks unlocks the door after mounting
<pitti> apw: but if totem open()s it again, it again triggers the lock, and there's nothing we can do to unlock it again
<apw> pitti, yep and i personally think thats a mistake
<apw> pitti, its locked cause its in use
<pitti> well, it's one interpretation; but it basically renders the eject button useless
<pitti> and it seems people are used to it
<pitti> and taking out a readonly medium like a DVD is pretty harmless, at least compared to yanking out USB sticks
<apw> well in reality people don't think generally thats why we have to handle them just pulling out USB disks when we know its something you should never do
 * apw grumbles ... yes but what about non-read only media
<apw> like in the middle of a burn
<ogra> wouldnt that lock ?
<pitti> apw: just passing the message here.. OEM team currently adds a sysctl.d file to set the flag..
<apw> ogra, not with the requested change to the kernel to turn off the lock
<pitti> ogra: we can probably make it to lock (not sure if it does right now)
<ogra> we should
<cooloney> apw: we found all the eject button do not work
<pitti> not locking by default doesn't mean that we can't lock manually, surely?
<ogra> pulling out in the middle of a burn seems bad
<cooloney> so we have to add sysctl.d trick to make it works
<apw> cooloney, they don't work till you unmount the media in software right?
<pitti> ogra: well, YAFIYGI.. :)
<cooloney> apw: exactly
<pitti> apw: (in which case you'd just use the eject button in nautilus to get it ejected)
<cooloney> if the data disc is mounted, eject button does not work
<apw> and now you tell the kernel to allow you do something stupid, and complain when it does something stupid?
<pitti> ogra: but yes, we should lock during burn
<ogra> pitti, i didnt ask :)
<apw> cooloney, that is as designed though
<pitti> apw: why is taking out a mounted CD-ROM stupid?
<apw> its stupid if you didn't unmount it cause you didn't tell me it wasn't needed (me == kernel)
<cooloney> apw: actually, 99% normal users will press that button
<apw> yep, and does it work in windows?
<cooloney> instead of umounting it in the GUI
<pitti> apw: yes, it does
<cooloney> apw: right
<pitti> windows doesn't lock the tray door
<apw> bah ...
<cooloney> windows does not do that
<ogra> apw, but but .... there is a button on the device and i pressed it ... must be broken if the Cd doesnt come out
 * apw cuts off one of ogra's fingers ... and now?
 * ogra takes a toe 
<cooloney> ogra: exactly, user will think that is a hardware problem
<pitti> ouch
<cooloney> button does not work
<pitti> apw: so, I agree that both bugs (locking and unmounting of stale mounts) should be fixed together; if the latter requires an userspace monitor, I'm happy to look into that
<apw> hrm you won't convince me that ill informed users are right
<apw> but i seem to be in the minority here
<ogra> doesnt have to do with being informed
<ogra> just with natural expectations
<persia> I'm confused.  Will pressing the button just eject, or tell the kernel to force-umount and then eject?
<apw> changing the default in the kernel is 'easy' but there will be two instant issues: 1) burn will be vunerable, 2) the errors will puke till it gets unmounted
<pitti> persia: it will just eject, and kernel/userspace have to tidy up after it
<smb> Well sort of yes. I would expect the button not to work when the cdrom is mounted because its in use
<apw> persia, the button doesn't go to the kernel
<apw> the kernel doesn't find out till the tray has opened and the media is gone
<ogra> smb, whats mounting ? can you explain to my mother ?
<cooloney> apw: actually burning issue is the same issue as you yanking a usb stick when you are writting something into the usb stick
<ogra> she popped that CD in and played some music ... now she pressed the button ...
<apw> ogra, no i can't but then i can explain 'click here' ... and thats what i do
<smb> ogra, Thats about ill informed users. Linux != Windows != Mac
<Keybuk> reading documentation on Linux terminal devices, while working for this company, is confusing
<ogra> smb, i would agree if there were only slot-in CD roms
<ogra> as soon as you have a button the button should just work
<apw> but ogra the button does just work, the error is that you think its an eject button
<ogra> Keybuk, stop reading ! we dont want you to resign to understand the prob !
<apw> when its actually an eject the media if its not being used, button
<apw> always was
<ogra> apw, there is a eject logo on it
<apw> you think thast what the logo is, thats not my fault
<ogra> (bar with a little triangle above)
<cooloney> but the problem is the data disc is auto mounted defautly
<apw> yep, but thats a design issue, i can't help they have used the wrong logo
<cooloney> if you insert the data disc, the eject button won't work
<ogra> cooloney, right and the button should properly unmount it
<apw> and by design the button _cannot_ do that
<ogra> and then eject the CD
<apw> as it does not have a channel to tell the kernel it has been pressed
<ogra> apw, why ? userspace surely gets a button event
<apw> why do you assume that, cause it has an eject logo?
<ogra> yes :)
<apw> the button is a physical eject, it tell the drive to open if its not locked
<cooloney> apw: yeah, since I use my cd player, we think that button means open the tray
<ogra> ok, thats a hardware flaw
<apw> the drive if unlocked will open and send a 'i just opened and your media went away' event
<ogra> still ... user expectations are differently and we should apply
<apw> its far too late by then to cope
 * apw goes back into his troll cave, and erects his anti-user force field
<pitti> why? you unmount, and userspace copes just fine
<ogra> why is it to late ? you can still unmount then
<smb> In theory maybe you could. But question would be is it done
<pitti> udisks and friends get the removal events, nautilus switches away from it, etc.
<apw> you can't unmount a r/w device then ... if yo uhave any data to write
<ogra> its not like you write to a readonly media
<pitti> the fun thing is that the kernel unmounts the r/w usb stick just fine
<smb> ogra, And my cd burner?
<pitti> but doesn't for a read-only CD-ROM mount
<ogra> smb, your CD burner software should acre for locking
<ogra> *care
<ogra> and remove the lock when its done
<apw> pitti, 'just fine' is a little unfair
<smb> ogra, Agreed, do we know it does :)
<apw> ogra, it doesn't need to ... cause its locked on use ... currently
<ogra> smb, if it doesnt its a bug :)
<apw> anyhow ... i'll go change the default, you can handle the fallout :)
<ogra> its not like there are millions of linux CD write apps
<apw> pitti, i think ogra just volunteered to fix all apps which _write_ to cd media
<ogra> its a handfull of patches in max if burning SW really misses here
<pitti> sweet ;)
<ogra> what ?
 * ogra glares at apw 
<apw> ogra, note that that includes things which mount r/w disks for instance
 * apw heard you
<pitti> ogra: I can look at brasero
<soren> I could have sworn that it used to work that way.
<ogra> pitti, well, arent there only two low level tools atm ? we should fix the backend
<pitti> soren: in the hal era, hal polled the CD-ROM for button presses and did a lazy unmount/eject
<soren> pitti: Back in the hal days, didn't we somehow detect that the user had pressed the eject button=?
<soren> Right, exactly.
<soren> There's and SG_IO ioctl thingamabob to do that.
<cooloney> that is funny, because the button works very well in jaunty
<pitti> ogra: yes, probably
<cooloney> but we failed since karmic
<pitti> cooloney: that was still the hal polling
<Keybuk> \o/
<cooloney> pitti: i understand
<Keybuk> I fixed the enter-kills-X bug
<pitti> but it causes an awful amount of wakeups, etc.
 * pitti hugs Keybuk
 * seb128 hugs Keybuk
<soren> Keybuk: Oh, no!
<apw> Keybuk, sounds good ... what the heck was it
<ogra> grouphug !
<Keybuk> apw: plymouth was setting the VT back into Canonical Mode
<soren> Keybuk: I rely on that bug to get to gdm occasionally. :)
<pitti> does that prove that Canonical is bad then?
<apw> oh no time for a name change
<pitti> apw: is that "oh, no time" or "oh no, time"?  :)
<Keybuk> since Raw Mode is better, let's call ourselves RAW Ltd
<apw> oh no,
<cooloney> apw: actually, i wanna talk about the second cdrom issue
<soren> Every now an again when I boot, I will have a console login prompt and a mouse cursor(!). Typing yields nonsense on the console. Pressing return kills X, it restarts, and yay, I have gdm.
<cooloney> apw: https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/476654
<ubottu> Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged]
<Keybuk> soren: I fixed that one last week ;)
<apw> i am assuming someone else will look after that one cooloney
<pitti> soren: that's bug 523788 which Keybuk supposedly fixed in his local branch
<ubottu> Launchpad bug 523788 in plymouth "Only see X mouse cursor on VT during boot" [High,Confirmed] https://launchpad.net/bugs/523788
<Keybuk> "supposedly" ... what, you don't trust me? :p
<soren> Keybuk: I'm /almost/ sure I've seen it this week. I'll keep an eye out to make sure.
<pitti> soren: yes, it's in today's lucid
<pitti> Keybuk: upload it! upload it!
<Keybuk> soren: I haven't uploaded fixed plymouth yet
<soren> Keybuk: Fixed and uploaded last week?
<soren> Ah, ok.
<soren> that explains :)
<Keybuk> on the basis that if I don't fix all of the known bugs, I'll get lynched
<seb128> Keybuk doesn't like to share fixes apparently ;-)
<smb> Keybuk, Just doit :)
<cooloney> apw: i am working on this. heh
<apw> cooloney, ok what you thinking
<Keybuk> plus am testing to make sure I don't introduce new ones
<Keybuk> like right now, the text renderer is broken again
<Keybuk> :'(
<pitti> Keybuk: does it render Klingon now?
<cooloney> apw: i failed to find where does kernel umount or cleanup the removed usb stick
<Keybuk> pitti: you could write a klingon plugin if you like
<cooloney> when you yanking a usb stick from a machine
<apw> cooloney, are we sure the kernel even does that?
<cooloney> it should be similar to press button eject t a file system
<Keybuk> cooloney: the kernel doesn't
<apw> Keybuk, who _does_ do that
<cooloney> apw: i am not sure
<Keybuk> apw: userspace
<cooloney> i guess is user app
<smb> Keybuk, udev?
<cooloney> but pitti told me that kernel does that
<Keybuk> kernel gives us a "device removed" uevent
<cooloney> right Keybuk
<Keybuk> udev tells udisks tells session, tells udisks to unmount
<pitti> hm, didn't it use to?
<apw> Keybuk, do we know who in userspace, and why cdroms don't ?
<apw> hrm
<Keybuk> pitti: don't think so - it'd be pretty strange for the kernel to just vanish half the filesystem without userspace doing it
 * pitti tries
<cooloney> right, why cdrom fails
<pitti> Keybuk: ok, then we need to teach udisks about that
<apw> cooloney, cause the 'drive' isn't gone like is in usb i assume
<cooloney> i monitors the udisks in lucid
<Keybuk> but I don't know for ausre
<Keybuk> apw: right, that's what I suspect
<cooloney> and devicekit-disk in karmic
<Keybuk> apw: which would fit what I believe to be true
<cooloney> it will get cd remove event as usb stick
<Keybuk> usb key removed => remove event for device => userspace cleans up
<Keybuk> cdrom ejected => device is still there => userspace unaware
<Keybuk> I thought we locked the CD tray ? :)
<smb> apw, So the "media gone away" probably not produce a uevent?
<davmor2> Keybuk: I have the enter to get gdm issue on une this morning and last night
<apw> Keybuk, i wish :)
<Keybuk> in fact, I'm pretty sure this is *why* we locked the CD tray :p
<Keybuk> davmor2: I had it 10 minutes ago, before I fixed it :p
<cooloney> ok, remove usb key
<pitti> Keybuk, apw: so, if I yank out a mounted usb key, it gets unmounted
<davmor2> Keybuk: so the fix should be in for tomorrow then?
<pitti> but I guess it's not the kernel then
<ogra> davmor2, you need the secret sources.list entry to pull directly from Keybuks laptop and then dist-upgrade
<cooloney> got 2 uevent, one is sdb, the other is sdb1
<Keybuk> davmor2: should be
<Keybuk> ogra: sources.list?!
<ogra> davmor2, or wait :)
<pitti> Keybuk, apw: ah, if I kill udisks-daemon, it doesn't, so I guess we need to fix udisks to lazy-unmount CD-ROMs then
<cooloney> remove cd disc, a one remove event
<Keybuk> you need to cd into co/plymouth, then run "make install", then move bits around a bit to match :p
<apw> pitti, how would it know to do it
<ogra> details :)
<davmor2> ogra: no I just need to travel over to keybuks hand him all my lucid boxes and say fix these ;)
<cooloney> pitti: agree
<Keybuk> pitti: as apw said, I suspect the problem here is that we don't know the CD-ROM has been ejected :p
<apw> pitti, without polling ... when you might as well do what hal did
<cooloney> so is there any event from cdrom.c driver for ejecting?
<pitti> we do get an uevent with CD-rom eject
<Keybuk> cooloney: no
<Keybuk> pitti: no!
<cooloney> Keybuk: too bad
<pitti> UDEV  [1268304083.700451] change   /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0 (scsi)
<Keybuk> pitti: the drive is *still there* :)
<Keybuk> right, there might be a change event
<pitti> Keybuk: not a remove, a change
<Keybuk> that would be worth investigating
<pitti> which is just fine
<pitti> I just tried it here
<apw> pitti, so you could use that ... excellent
<Keybuk> change => check for media => media gone => unmount
<pitti> 'zactly
<Keybuk> I was building up to that
<apw> ok so that sounds like a plan ...
<cooloney> how about add a new uevent in cdrom.c driver to do that
<pitti> apw, Keybuk, cooloney: ok, I'll look into fixing the cdrom unmount in udisks
<apw> pitti, thanks
<pitti> cooloney: uevents are all fine
<apw> cooloney, sounds like we have what we need ...
<matti> Hi apw
 * cooloney hugs pitti 
<cooloney> apw: thanks,
<cooloney> Keybuk: thanks
<pitti> bug 476654 targetted to lucid adn assigned to me
<ubottu> Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged] https://launchpad.net/bugs/476654
<cooloney> i will let those guys know this issue
<Keybuk> slangasek: I guess you're not up?
<apw> pitti, do we need to track the 'fix burners' side of this issue?
<apw> get a nice bug assigned to ogra
<pitti> apw: I'll add a task to bug 397734 for checking this
<ubottu> Launchpad bug 397734 in devicekit-disks "can't eject cdrom with hardware button" [Medium,Fix released] https://launchpad.net/bugs/397734
<cooloney> apw: you scared ogra away, heh
<pitti> done
<ogra> ah, back to normal ... http://people.canonical.com/~ogra/osiris-lucid-20100311-3.png
<pitti> *envy*
<apw> pitti, where will i fine the usdisks changes you made which unlock the drive?  i need to disable them to test this change
<pitti> apw: sudo python, open("/dev/sr0") should lock it again
<pitti> apw: but the thing you asked for is http://cgit.freedesktop.org/udisks/commit/?id=1064be64a7398b9b5dec4ece39b738ff15073d56
<directhex> so does anyone know what would cause an ntfs entry in /etc/fstab to lock up lucid during boot?
<asac> cjwatson: thanks for klibc fix
<apw> directhex, what does it say?  waiting for it?
<directhex> apw, yeah, i think that was it
<apw> smb, you had something about mount lines needing a new option (that they should always have had) to make boot work
<smb> right
<smb> nobootwait or so...
<smb> directhex, Right, try "nobootwait" in fstab as one of the options
<directhex> i'll give it a shot when i'm feeling brave enough to go potentially unbootable again
<directhex> how about the switch to nouveau? totally killed my x, with no obvious way to go back to nvidia-glx (ended up dropping to a terminal & installing things manually)
<smb> directhex, It worked well for me as I had entries in there with "user" for usb sticks which was not enough anymore
<directhex> smb, if the lack of nobootwait, which i'd never heard of until today, is enough to make the system unbootable, even in recovery mode, perhaps something needs to behave better?
 * matti seconds directhex 
<apw> directhex, see if thats the fix, i think that someone was meant to be making the prompt easier to understand
<smb> directhex, Actually it gives you some "imo cryptic" hint. Though I am not sure its carried over to plymouth. Was it displaying some text waiting for xxx [SM]?
<apw> directhex, it did prompt you to tell you there was an issue right?
<directhex> smb, yes
<smb> At that point you can press 's' to skip
<apw> pitti, was it you who said that those messages were on the list to fix?
<directhex> smb, really? THAT wasn't made clear
 * smb is not even sure what 'm' would do. But 's' was going on
 * ogra always thought SM was something that involves whips
<directhex> wait, [sm] is a prompt?
<smb> Waiting indefinitely for a mount really counts as "sm" to me
<ogra> it tells you the keys you can press
<smb> directhex, yep
<directhex> son of a...
<ogra> on fsck there is also C
<ogra> (for cancel)
<ogra> if the theme doesnt handle that now though
<pitti> apw: "those messages"?
<apw> pitti, sorry, the plymouth mesages when it wants you to skip a mount and says /boot [SM]
<pitti> apw: oh, I'm afraid I have no idea about that one
<apw> someone was saying they were under review, and wanted to make sure that i was correct
<apw> may have been slangasek
<cjwatson> asac: upstream backports are the easy ones ;-)
<Keybuk> that's interesting
<Keybuk> a bug is fixed by a random line of code that slangasek added, without any reference to a bug number, and that he didn't send upstream
<Keybuk> and I can't find any reason for him adding that other than "he noticed it was probably needed"
<siretart`> pitti: mdeslaur: ffmpeg bug as discussed earlier today filed as bug #537297
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/537297)
<sabdfl> is anyone here particularly focused on chromium?
<persia> fta seems to spend the most time on it (dailies, etc.)
<persia> (assuming you mean chromium-browser rather than chromium-bsu)
<ogra> or chromium OS :)
<persia> That's "Chrome OS"
<ogra> i thought there was a chromium branch of it as well ?
<cjwatson> Chromium OS is the open-source bit of Chrome OS
 * persia isn't 100% sure
<persia> Aha!
<cjwatson> analogously to Chromium/Chrome
<ogra> yeah
<sabdfl> yup
<sabdfl> to see if we can add http://www.ubuntugeek.com/ambiance-theme-for-google-chromechromium.html to the package
<sabdfl> or maybe it needs to be in the light-themes package?
<sabdfl> seems odd to have bits there for a Universe app
<sabdfl> but it's a *popular* universe app :-)
<persia> Could do a light-chromium-theme package.
<ogra> asac, ^^^
<persia> (or chromium-theme-light)
<cjwatson> lamont: is it feasible to update util-linux to 2.17.1?  see bug 530071
<ubottu> Launchpad bug 530071 in ubiquity "Lucid Default live-cd install fails with 4K sector / Advanced Format drives" [High,Triaged] https://launchpad.net/bugs/530071
<asac> fta: ^^
<asac> fta: (see a few lines above for chromium theming)
 * ogra thinks we should just set them as defaults in the package
<ogra> (both, the scrollbar and the theme)
<persia> How does that play with xubuntu/kubuntu?  (I'm not sure folks using mythbuntu, ubuntustudio, or ubuntu-server will run chromium-browser so much)
<superm1> ogra, the scrollbar is an extension, so i doubt it can be set up by default like that
<superm1> and it doesn't work on internal pages (chrome://)
<ogra> hrm
<\sh> moins
<cjwatson> pitti: so, you removed libjpeg7 from the archive saying "not needed in lucid", but libjpeg-progs still depends on it
<cjwatson> pitti: what's up with that?/
<pitti> uh? I ran checkrdepends on it
<cjwatson> it has a bunch of rdepends, and we don't have libjpeg8 in lucid
<cjwatson> (and I'm a bit sceptical about upgrading to it at this point)
<cjwatson> you apparently left the libjpeg-progs binary in there, even though it's in the same source package, and libjpeg7 wasn't NBS
<cjwatson> so I'm confused about what was going on :)
<pitti> I spotted libjpeg7 while reviewing duplicated libraries
<pitti> so I ran checkrdepends on those, and it seemed to have none
<pitti> apparently I screwed up on that one then
<cjwatson> pitti: shall I just reupload libjpeg7 to put it back?
<cjwatson> pitti: what was the other duplicate, though?
<pitti> cjwatson: I'd rather build it from 6b again
<cjwatson> I wouldn't
<cjwatson> 6b's build system sucked
<cjwatson> IIRC it wasn't cross-buildable
<pitti> hm, having a second implementation just because of that? it was built from 6b in karmic as well
<cjwatson> plus libjpeg-progs was already bumped to 7, so going backward would be hard
<cjwatson> can we just transition to 7?
<pitti> $ apt-cache rdepends libjpeg62|wc -l
<pitti> 555
<cjwatson> hm
<pitti> that's what I wanted to avoid
<yofel> hey, will there be 64bit installation media for ubuntu-netbook? as there are 64bit atom cpu's out there now
<cjwatson> Debian's libjpeg-progs is built from 8
<cjwatson> so we could do 7+really6b-1 as the version for just the libjpeg-progs binary
<pitti> right, I just thought the same
<pitti> and in manic we can just sync it again
<pitti> cjwatson: ok, I'll get that fixed ASAP, thanks for pointing out
<cjwatson> pitti: oh, ok, thanks, I can do it if you're busy
<pitti> I am, but since I broke it..
<cjwatson> heh
<cjwatson> who isn't busy at the moment I guess
<pitti> cjwatson: I created bug 537370 as a reminder
<ubottu> Launchpad bug 537370 in libjpeg6b "build libjpeg-progs again" [High,In progress] https://launchpad.net/bugs/537370
<cjwatson> pitti: thanks
<mr_pouit> there was already bug 535629 opened
<ubottu> Launchpad bug 535629 in libjpeg6b "package libjpeg-progs is not built from any source package but several packages in lucid depend on it (dup-of: 537370)" [High,New] https://launchpad.net/bugs/535629
<mr_pouit> erf, ok
<pitti> mr_pouit: sorry, noticed too late; duped
<\sh> pitti: does that mean, for lucid+1 total transition to 7 or 8 ? hopefully mostly done by debian at some point?
<pitti> \sh: to 8 presumably
<pitti> I guess we'll get a lot through autosyncs
<\sh> well...I get some new hardware for an additional buildserver in the next 2 months...it should be ready for lucid+1 ;)
<lamont> cjwatson: Keybuk is the better one to ask about 2.17.1 though I think he might poke me about it, istr
<zul> asac: ping
<asac> zul: hi
<asac> on MIR?
<zul> asac: you read my mind ;)
<asac> i approved the log thing (with a few comments)
<zul> asac: cool thanks
<asac> anything else i havent checked that is on your list?
<zul> asac: not that I know of
<asac> ok great
<zul> thanks
<tumbleweed> fr43ed
<tumbleweed> garr, excues that, lag--
<pitti> tumbleweed: better change your password now :)
<tumbleweed> pitti: that wasn't a password, thankfully
<maco2> cjwatson: slangasek got it
<fta> asac, ogra, persia, cjwatson: i don't think chromium has a system wide location for extensions like firefox, but i can sure check
<persia> fta: Look a little higher up in the scrollback :)  But good luck.
<asac> fta: thanks
<fta> persia, how far?
<ogra> fta, up to the person who requested it i guess :)
<fta> sabdfl, ^^ + i've been working on chromium since day one. I'll have a look at what's possible for that theme but i think we need a scheme for chromium extensions in general
<stefanlsd> Anyone else have an issue running /usr on a seperate partition on lucid? Trying to debug why. 1/2 times mountall doesnt mount /usr and need to hard reboot. Having an issue now where noveua drivers wont blacklist either
<\sh> stefanlsd: last night I booted lucid with /usr on a separate partition successfully
<stefanlsd> \sh: any issues since? my first boot always fails, then reboot works...
<\sh> stefanlsd: nope...even my problem with LVMs disappeared yesterday
<sabdfl> fta: yes. i don't know if they allow both system-level and per-user extensions
<sabdfl> took ff years to get extensions working well
<stefanlsd> \sh: kk. thanks. maybe i just need to re-install and start fresh :)
<fta> sabdfl, i still have to push the ffmpeg codecs to lucid (currently only in the 3 chromium PPAs). the package is ready but i'm unsure about the redistribution license of some of those codecs (h264, aac..). I wouldn't mind some help here
<fta> (this is needed for the HTML5 audio/video tags)
<sabdfl> if they are open source, go ahead
<fta> it's basically ffmpeg, which we already have, but configured/packaged differently
<\sh> fta: talk to siretart` ;)
<siretart`> I got hilighted?
<persia> siretart`: You were highlighted as a contact for fta to discuss ffmpeg packaging for the chromium-browser ffmpeg stuff
<siretart`> fta: what do you mean with 'push ffmpeg codecs to lucid'?
<siretart`> AFAIUI, chromium tracks astrange's ffmpeg-mt branch, is that right?
<siretart`> fta?
<fta> siretart`, http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-codecs-ffmpeg.head/files/head:/debian/
 * Keybuk teaches popey about =
<popey> ruhroh
<fta> siretart`, yes, it's the -mt branch, with a bunch of patches and a build system from the chromium devs, and different flavors of codecs depending on the branding (chrome vs chromium)
<Keybuk> shells used by Real Men have a neat =thingy shortcut ;)
<Keybuk> it's basically `which thingy`
<Keybuk> so I just do dpkg -S =skype
<Keybuk> :p
<mathiaz> Could an archive admin promote vlan-modules-2.6.32-16-generic-di and vlan-udeb to main?
<popey> ahhh neato!
<popey> thanks :)
<mathiaz> These are binary packages only
<Keybuk> doesn't work in bash though
<popey> bah
<popey> do I have to use keybuksh
<davmor2> popey: emacs ;)
<ogra> Keybuk, now whats a real mans shell ?
<Keybuk> zsh!
<ogra> pfft
<Keybuk> I resisted the urge to make a \sh! joke
<ogra> lol
<zyga> has anyone seen mvo recently?
<Keybuk> he's on holiday I believe
<blueyed> zyga: just wanted to ping him also, about bug 502641
<ubottu> Launchpad bug 502641 in apt "[Lucid] apt-get source always selects highest available version instead of the specified one" [Unknown,Fix released] https://launchpad.net/bugs/502641
<blueyed> it should be fixed, but does not appear so..
<blueyed> the proposed fix (http://bazaar.launchpad.net/~mvo/apt/mvo/revision/1693) appears to be in Ubuntu.
<blueyed> Nobody affected by this? Even the "--only-source" workaround mentioned in the Debian bug does not work for me.. have to resort to using dget..
<kamusin> pitti, thanks for patching tzdata at time, you are our hero
<zyga> Keybuk: I see
<fta> siretart`, persia: i guess i should just send chromium-codecs-ffmpeg to lucid and wait for the NEW to be reviewed, unless you already have comments i should address
 * persia is just passing messages
<mathiaz> lamont: re bug 532587 - is it important/mandatory that system users/groups are removed when the package is removed/purged?
<ubottu> Launchpad bug 532587 in puppet "removal of package does not stop daemon" [Medium,Fix released] https://launchpad.net/bugs/532587
<cjwatson> zyga,blueyed: I think he's off ill
<Keybuk> PITTI!
<\sh> Keybuk: please do...I need to laugh today ;)
<lamont> mathiaz: uh...  see policy?
<lamont> but stopping the daemon is kinda critical
<mathiaz> lamont: right - that is fixed in lucid now
<mathiaz> lamont: hm - where in the policy is the user/group remove on package removal documented?
<mathiaz> lamont: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2 deals with system users/groups
<mathiaz> lamont: but doesn't refer to what should be done on package removal
<persia> mathiaz: I'll suggest not removing the users/groups on package removal (which I've seen in a number of packages): this avoids the problem of potentially chowning files that are to be preserved, etc.
<lamont> yeah - and I don't see it anywhere either
<lamont> not removing is a good answer
<persia> (plus it means end-users get the *same* uid/gid if they reinstall later)
<lamont> postfix package removes the users and groups it created, many other packages don't
<mathiaz> persia: right - not removing the user/group seems to safest option to me as well
<mathiaz> lamont: do you need an SRU for karmic on the puppet bug?
<persia> lamont: Do you happen to know why postfix does it that way?
<mathiaz> lamont: or lucid is fine?
<lamont> mathiaz: romantic notions of cleaning up after myself?
<persia> OK.  As long as there's a good reason :)
<lamont> bind9 likewise - most likely I copied the bind behavior into postfix
<lamont> mathiaz: ultimately, I'm certain it was "the standard reason": it seemed like a good idea, at the time
<persia> Being tidy seems more defensible.
<persia> lamont: On a completely different note: did my last comment to bug #67544 contain enough information, or is more useful?
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Unknown,Fix released] https://launchpad.net/bugs/67544
<persia> (not really Fix Released)
<Keybuk> <grin> at bug #537248
<ubottu> Launchpad bug 537248 in plymouth "does not format usb flash" [Undecided,New] https://launchpad.net/bugs/537248
<Keybuk> most people think that Plymouth not formatting usb flash devices is a feature
<Keybuk> filesystem corruption is about the only bad thing it *doesn't* do :p
<mdeslaur> lol
<zyga> does anyone know if it's possible to link PPA with a launchpad project somehow?
<jpds> zyga: Try asking #launchpad.
<slangasek> Keybuk: the line in src/main.c?
<slangasek> Keybuk: that was: after fixing the proximate cause of bug #506717, plymouth would helpfully segfault
<ubottu> Launchpad bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,Fix released] https://launchpad.net/bugs/506717
<Keybuk> was the fix for 506717 the declining to show the script plugin thing?
<alexmoldovan> Hello guys, I have a q: I am running apport and it asks me "Has this issue been confirmed to exist with the upstream kernel?". I don't know what this means, so I don't know what to answer. I would like to help, so I need to understand this.
<bdrung> a package FTBFS in the archive, because a network test failed. i tried to reproduce it locally by disabling the network, but the package still builds. how can i reconstruct the buildd environment?
<bdrung> i am talking about bug #521204
<ubottu> Launchpad bug 521204 in lucene2 "lucene2 2.9.1+ds1-5 fails to build from source" [Undecided,New] https://launchpad.net/bugs/521204
<kkszysiu> hello
<kkszysiu> well anyone working to integrate somerhing like http://www.omgubuntu.co.uk/2010/03/easy-gui-window-button-switcher-for.html into gnome-appearance-properties ?
<johnsgruber> Is there anything afoot to get plymouth to start gdm on a tty >=7 ?
<slangasek> Keybuk: 506717> well, what I was fixing was that plymouth wouldn't fall back to the text plugin when script was selected
<Keybuk> right
<Keybuk> that's ok, it fits what I thought
<viyyer> hi kirkland there?
<YokoZar> What component do I file this against?  I've noticed that when I change from noveau to proprietary nvidia drivers my laptop stops working well with my docking station / monitor (have to manually tell it to switch displays and then manually change resolution)
<YokoZar> Somehow it seems to me that's not entirely an nvidia mode setting thing, but I don't know too much about it
<Keybuk> YokoZar: file it with your NVIDIA support contact?
<YokoZar> so is it all a proprietary drivers thing?
<YokoZar> *s/package/component, been filing too many bugs upstream lately
<Keybuk> well, if it works with nouveau, and doesn't with nvidia-glx - it's a binary driver problem, no?
<persia> Could file a bug against the nvidia-glx package, but it won't get fixed there unless it's fixed upstream.
<YokoZar> Keybuk: Not necessarily, no.
<YokoZar> In my experience usually X is involved in all unwanted resolution changes
<viyyer> I wanted to try out testdrive . While installing apt-get gives an error. viyyer@Atri:~/Desktop/panel$ sudo apt-get install testdrive
<viyyer> [sudo] password for viyyer:
<viyyer> Reading package lists... Done
<viyyer> Building dependency tree
<viyyer> Reading state information... Done
<viyyer> Some packages could not be installed. This may mean that you have
<viyyer> requested an impossible situation or if you are using the unstable
<viyyer> distribution that some required packages have not yet been created
<viyyer> or been moved out of Incoming.
<viyyer> The following information may help to resolve the situation:
<YokoZar> spam
<viyyer> The following packages have unmet dependencies:
<viyyer>   testdrive: Depends: cpu-checker but it is not installable
<viyyer> E: Broken packages
<viyyer> oops
<persia> !paste | viyyer
<ubottu> viyyer: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<tesuki> If I make a proprietary program could I get it into the standard repos? (a program that needs a license file and accepting of a license)
<Keybuk> YokoZar: X *is* whatever driver you're using
<Keybuk> there isn't much more to it than that, really
<persia> tesuki: Depends on the license.  If it can be distributed freely, but needs a license to use, it can be in multiverse, but you may have a hard time interesting developers in uploading it.
<YokoZar> Keybuk: But X has multiple components, and not all are the drivers, hence the questions.  I remember specifically having a resolution problem in the past that was an XRandR issue, for instance.
<tesuki> If I make a deb (that I can install with dpkg -i name.deb) would it still be hard? Could money help?
<YokoZar> If it's packaged right
<persia> tesuki: making a .deb makes it impossible.  It needs to be a source package.  The sun-java6 package in jaunty is a good example of how that works.
<YokoZar> ^^ what persia said
<persia> tesuki: I believe Cannical offers a program where you can pay to have proprietary appls inthe partner archive.  No idea on costs.
<viyyer> kirkland,  http://pastebin.ca/1834309  what package is cpu-checker ?
<Keybuk> YokoZar: I don't think nvidia-glx *does* xrandr
<Keybuk> YokoZar: it does mad TwinView crap
<YokoZar> Keybuk: ahh ok, hence the problem.  You've sated me.
<YokoZar> viyyer: packages.ubuntu.com can answer that for you
<viyyer> YokoZar, there is none
<YokoZar> viyyer: change "karmic" to "lucid", it seems it's a new package
<tesuki> persia: that program is namned?
<YokoZar> regardless ubuntu-bug packagename will work even if it's a binary package name and not a source package name
<\sh> tesuki: http://www.canonical.com/services/packaging <- canonical packaging service for partner apps
<tesuki> \sh, persia thank you.
<viyyer> YokoZar, the purpose of installing testdrive is to test out lucid. I don't want to install lucid right now
<viyyer> YokoZar, testdrive allows one to test lucid on a VM
<debfx> Adri2000: hi, I just noticed you filed a FFe to get blobby into lucid
<debfx> I'm the debian maintainer and wanted to make it build-depend on the (just accepted) tinyxml package (instead of building its own copy) for the next upload
<Adri2000> debfx: hi
<Adri2000> debfx: hmm then in this case maybe we're going to sync the current blobby and not wait for your next upload...
<Adri2000> otherwise it would require another FFe for tinyxml
<debfx> Adri2000: yes, I guess that's the best way as these architectures aren't supported by ubuntu anyway and chances that someone wants to play blobby on them are pretty low :)
<Adri2000> debfx: I've just added a comment about this in the FFe bug. thanks for notifying me of this. do you think you could wait a bit before uploading the new version in debian, until we've decided for sure what version we sync? (so if we choose -1, it will still be possible to "sync")
<ccheney> what util does line ending conversion from dos to unix?
 * ccheney can't find it with apropos
<cjwatson> fromdos
<ccheney> cjwatson: thanks
<genii> cjwatson: Isn't also dostou ?
<kirkland> viyyer: hi, sorry about that ... I'm uploading cpu-checker to the ppa now
<kirkland> viyyer: that was a recent change for lucid, forgot to backport until you reminded me :-)
<viyyer> kirkland, thanks .. I think test drive is great idea.
<viyyer> kirkland, when would you be able to upload the same ?
<kirkland> viyyer: what do you mean?
<kirkland> viyyer: https://edge.launchpad.net/~testdrive/+archive/ppa/+packages
<kirkland> viyyer: the builds are queued, should be done in ~45 minutes
<viyyer> kirkland, thanks :)
<kirkland> viyyer: i'm also looking at the code, trying to remove (soften) the cpu-checker dependency
<\sh> why does sun-java6-bin need libnss-mdns and therefore avahi-daemon?
<kirkland> viyyer: okay, cool ... I just modified the code to use cpu-checker if there, but not depend on it; this should solve the issue much better :-)
<kirkland> viyyer: i'm uploading to the PPA now
<kirkland> viyyer: again, will build in a bit
<mathiaz> kirkland: what is responsible for creating /dev/kvm?
<kirkland> mathiaz: in lucid?  /etc/init/qemu-kvm.conf
<kirkland> mathiaz: <lucid, the init script
<mathiaz> kirkland: on lucid, on an NC I get this: http://paste.ubuntu.com/393565/
<mathiaz> kirkland: that was *after* installing eucalyptus-nc as a package
<kirkland> mathiaz: does /dev/kvm exist?
<kirkland> mathiaz: lsmod | grep kvm
<mathiaz> kirkland: hm - now yest
<kirkland> mathiaz: ?
<mathiaz> kirkland: because I manually modprobed kvm_intl
<kirkland> mathiaz: pastebin your /etc/init/qemu-kvm.conf
<kirkland> mathiaz: status qemu-kvm
<slangasek> Keybuk: any idea what's causing these "plymouth not stopping at shutdown" bugs suddenly?
<mathiaz> kirkland: http://paste.ubuntu.com/393569/
<kirkland> mathiaz: modprobe -r those two kvm modules
<kirkland> mathiaz: and sudo start qemu-kvm
<kirkland> mathiaz: make sure that that get's the module loaded correctly
<mathiaz> kirkland: is qemu-kvm started by the postinst?
<kirkland> mathiaz: hmm
<mathiaz> kirkland: I haven't rebooted the NC after the eucalyptus-nc package has been installed
<kirkland> mathiaz: i'm not sure, actually
<kirkland> mathiaz: let me check
<slangasek> Keybuk: ah, an apport change
<kirkland> mathiaz: oh, one more thing ... dpkg -S /etc/init/qemu-kvm.conf
<slangasek> pitti: this new "unkillable_shutdown" hook is broken
<mathiaz> kirkland: according to /var/lib/dpkg/info/qemu-kvm.postinst there is nothing that start qemu-kvm in there
<kirkland> mathiaz: yeah, i agree
<mathiaz> kirkland: qemu-kvm is the package shipping /etc/init/qemu-kvm.conf
<kirkland> mathiaz: cool ... so just a "start qemu-kvm | true" toward the end of that?
<mathiaz> kirkland: how do you install the qemu-kvm upstart job?
<mathiaz> kirkland: with dh_installinit?
<kirkland>         dh_installinit -s --no-restart-on-upgrade --error-handler=true --noscripts
<kirkland> hmm
<kirkland> mathiaz: oh, i think the --noscripts is breaking me
<mathiaz> kirkland: yeah - probably
<mathiaz> kirkland: should I report a bug?
<slangasek> pitti: specifically, it's reporting plymouth as unkillable (bug #537248 et al.)
<ubottu> Launchpad bug 537248 in plymouth "does not format usb flash" [Undecided,New] https://launchpad.net/bugs/537248
<kirkland> mathiaz: yes, please
<kirkland> mathiaz: i'm fixing it now
<kirkland> mathiaz: i'd like a bug to reference
<mathiaz> kirkland: bug 537682
<ubottu> Launchpad bug 537682 in qemu-kvm "qemu/kvm not started after package install" [Undecided,New] https://launchpad.net/bugs/537682
<kirkland> mathiaz: thanks
<cjwatson> genii: it's the sort of thing that is sufficiently easy to write that many people have written it.  I don't know that enumerating all the versions of it is useful :-)
<mdz> say, why does my system slow to a crawl with disk I/O whenever apparmor is upgraded and reloads its profiles?
<cjwatson> hey, I noticed that too, had been meaning to report it
<jdstrand> it regenerating its cached files
<jdstrand> cached profiles
<jdstrand> we now have binary blobs that load super fast on boot rather than having to generate them on the fly
<jdstrand> that helps with boot times, but slows down install a bit
<cjwatson> it absolutely hammers my laptop on upgrade
<jdstrand> the system shouldn't slow to a crawl though...
<cjwatson> is it trying to massively parallelise the caching or something?
<jdstrand> I'm not sure-- jjohansen is the one to ask
<jdstrand> (or possibly kees, if he did something in packaging that would affec it)
<jjohansen> cjwatson: no
 * sebner waves at jdstrand and reminds him of moin 
<jjohansen> cjwatson: its single threaded, compiling the policy can hit the cpu pretty hard though
<cjwatson> from what I very vaguely recall, the load seemed to be in a kernel thread, but I couldn't look closely because I couldn't do very much :-)
<cjwatson> so that might be bogus data
<jdstrand> sebner: don't need to remind-- I've pretty much only been working on it this week :)
<cjwatson> jjohansen: if it's just that, then maybe nice(1) would be in order
<jdstrand> sebner: I need to get the stable releases out, then I'll review your debdiff
<jjohansen> cjwatson: sure that could be done
<sebner> jdstrand: aye aye, just thought you might have forgotten it :)
<kees> cjwatson: yes, it uses all available CPUs when generating the caches
<kees> cjwatson: using "nice" would defeat the purpose of loading it as fast as possible, though?
<jjohansen> hrmmm, thats right kees parallelized it launch multiple compiles
<jjohansen> I had forgotten that
 * kees nods
<jjohansen> the compile is itself single threaded
<kees> right
<micahg> didrocks: could I get you to test your firefox LP bug in the upstream build as well?
<jdstrand> maybe 1 - N-1 would be the way to go
<jdstrand> kees: ^
<kees> well, the actual issue was mdz claiming heavy disk I/O, which is unrelated to the parallelization, I would imagine.
<jdstrand> true
<jjohansen> it does very little disk I/O
<mdz> jdstrand, it really hammers my system, to the point where the desktop is unresponsive
<cjwatson> kees: ^- indeed, I'm seeing the same thing as mdz.  "as fast as possible" becomes counterproductive at that point
<cjwatson> it wasn't directly clear to me whether it was disk I/O or something else - unresponsiveness was the main symptom
<mdz>         xargs -n1 -P$(getconf _NPROCESSORS_ONLN) "$PARSER" "$@" --
<mdz> kees, is that what you're referring to?
<cjwatson> I think I may have been getting some kind of disk thrashing as a second-order effect
<directhex> okay, am i the only one experiencing weirdness when gdb appears? if i hit enter to select myself from the user list, gdm seems to die & restart
<directhex> the second time, it's fine. just buggered post-boot
<RAOF> directhex: No, you're far from the only one.
<mdz>  /etc/init.d/apparmor reload with a hot cache is reasonably sane
<RAOF> directhex: That's plymouth being evil.
<kees> mdz: yup, that's the parallelization
<sbeattie> mdz|cjwatson: are you guys near memory limits where non-trivial amounts of memory consumption might cause swapping to occur?
<cjwatson> sbeattie: nowhere close
<kees> mdz: seb128 has been complaining about how long some of the reloads were taking when doing package installs, so we pulled out the stops to speed it up.
<mdz> sbeattie, nope
<kees> I guess we could nice it.
<cjwatson> even with two kvm instances running (which I didn't at the time), I have over 1GB free
<kees> seems weird to me.
<mdz> 4.72user 0.15system 0:03.63elapsed 133%CPU (0avgtext+0avgdata 141552maxresident)k
<mdz> 0inputs+1528outputs (0major+40010minor)pagefaults 0swaps
<cjwatson> kees: or use only up to n-1 processors if n > 1
<cjwatson> perhaps
<mdz> kees, what does apparmor_parser do?
<kees> I wonder if xargs correctly handles -P0 ...
<cjwatson> -P0 means "run as many as possible" per the man page
<cjwatson> equivalent of make -j
<kees> cjwatson: eek
<ion> mdz, cjwatson: I take it itâs not bug #458299 youâre encountering, though?
<ubottu> Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Confirmed] https://launchpad.net/bugs/458299
<kees> mdz: it builds the kernel rules for apparmor from the text file rules
<mdz> ion, I don't see that message, no
<mdz> kees, right, but what sort of system calls does that involve?
<kees> mdz: i.e. parses them into the binary DFA that the kernel uses for following AA rules
<mdz> why should it be so I/O intensive?
<cjwatson> ion: hmm, I do have one of those in my logs
<cjwatson> so perhaps mdz and I have different problems
<kees> mdz: it just uses open read write.  the files are relatively small.
<mdz> kees, something else is going on here, then
<kees> mdz: what does du -sh /etc/apparmor.d/cache say ?
<mdz> kees, there are only 1.1MB of files in /etc/apparmor.d in total
<mdz> that doesn't even come close to explaining the behavior I' see
<kees> mdz: yup, sounds about right
<ion> cjwatson: The symptoms of that issue seem be something in kernel space constantly allocating all free memory in an infinite loop, making the system unusably slow.
<mdz> kees, what happens to running processes when those are reloaded?
<cjwatson> ion: that sounds plausible
<mdz> kees, is it possible that it's paging in a lot of stuff?
<kees> mdz: do you mean "how are the AA protections for the processes handled?" they are atomically swapped for the new profiles once they're loaded.
<kees> jjohansen: ^^ is it possible the kernel is hauling in lots of memory to attach/swap the profiles?
<mdz> kees, does that involve touching more than a trivial amount of process memory?
<kees> mdz: if that were the case, I would assume a standard hot-cache "sudo service apparmor reload" would show the same problem.
<mdz> kees, except that it's all paged in
<mdz> I have plenty of RAM
<jjohansen> well it pulls in some memory dependent on what the policy is but trivial on todays machines 2-4 MB
<kees> mdz: the blobs in /etc/apparmor.d/cache are what is being loaded in the kernel, so that's the extent of the kernel memory.  the userspace parser uses more memory than that when parsing, but it's not huge.
<ion> Cache in /etc? Eww. :-)
<jjohansen> userspace compilation does get large
<kees> ion: :)
<mdz> jjohansen, so you think it's apparmor_parser itself which is the likely culprit?
<jjohansen> yes
<jjohansen> mdz: we can experiment with running this without doing the actual kernel load
<jjohansen> vs. just loading from prebuilt cache
<slangasek> Keybuk: so I'm getting casper-md5check to talk to plymouth; is there any sort of distinction in plymouth between displaying errors vs. high-prio text vs. normal text?  I don't see anything along those lines in the API
<Keybuk> no
<slangasek> ok
<Keybuk> we can add things like that
<Keybuk> there are two types of message our theme supports
<Keybuk> generic blah blah types like "Checking your disks"
<Keybuk> and beneath that, a message about what keys you can press
<Keybuk> "Press C to cancel" etc.
<slangasek> well, this certainly doesn't seem like something that should be added into a theme if there's no protocol-level distinction
<Keybuk> I think you misunderstand me
<Keybuk> this kind of thing, in plymouth, is deliberately left up to the theme
<Keybuk> plymouth provides basic ways to communicate with the theme
<Keybuk> and you build from there
<Keybuk> that's how our fsck progress works, for example
<slangasek> I don't think I misunderstand you, I think I disagree with you that this is a reasonable design :)
<Keybuk> really, why?
<Keybuk> plymouth is just a plugin architecture for dealing with displays really
<Keybuk> where the most common use is to make splash screens
<persia> Keybuk: So if I get text overlaying an entry box during boot, that's a plymouth bug, or a theme bug?
<Keybuk> persia: theme bug
<persia> Thanks.
<Keybuk> relevant aside: there's new gdm, mountall + plymouth packages in my PPA
<Keybuk> would appreciate testing
<slangasek> Keybuk: that the client and the theme have a private agreement for the meaning of the text strings?  Yes, I think that's a bad design
<slangasek> it means anyone who wants to use a different theme gets weird handling of the annotated strings the client is sending
<Keybuk> though that being said, I never really got how some text can be "urgent" and some can't be
<Keybuk> slangasek: but in plymouth, switching a plugin can be switching from a splash screen to a login screen to an OS switcher, etc.
<slangasek> plugin, or theme?
<slangasek> none of the themes shipped here seem to be login screens or OS switchers
<Keybuk> plugins and themes are the same thing
<Keybuk> slangasek: half the themes in plymouth don't even support message ;-)
<slangasek> well - that's better than having them support it and wind up with "keys:" prepended? :)
<Keybuk> *shrug*
<Keybuk> the alternative is that you put a massive burden on theme authors to support dozens of commands that they might not care about
<slangasek> I half think that if a theme isn't going to behave sensibly with mountall, we shouldn't ship that theme by default
<slangasek> dump it in plymouth-bad-for-ubuntu or something :)
<Keybuk> I don't disagree :p
<Keybuk> splitting the themes out is on the todo
<Keybuk> that being said, I did make the text theme work with mountall ;)
<slangasek> ok
<ion> Nice
<ion> (add-apt-repository ppa:scott)
<ion> keybuk: Worksformeâ¢
#ubuntu-devel 2010-03-12
<blueyed_> Apport retracing service is down?
<Debian911> can anyone confirm that the version of eglibc (2.11.1-0ubuntu4) is superior then that of Debian Expermential is using as I can see there version 2.11-0exp6 lists a fix for "Add the fallocate64() syscall.  Closes: bug#568924" but cant see it listed in Ubuntus' changelog - http://changelogs.ubuntu.com/changelogs/pool/main/e/eglibc/eglibc_2.11.1-0ubuntu4/changelog and http://packages.debian.org/changelogs/pool/main/e/eglibc/e
<cjwatson> $ nm -D /lib/libc.so.6 | grep fallocate64
<cjwatson> 000c5f70 T fallocate64
<Debian911> cjwatson: 00000000000dd130 T fallocate64, 00000000000da010 T posix_fallocate64 - am I to assume we're fine and my system has fallocate?
<cjwatson> that means your libc has the fallocate64 syscall stub, yes
<crimsun> Debian911: since you parted +1 before I could paste the reference, see http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1f3615a1c97a030bca59f728f998947f852679b9 and walk the appropriate sources in loggerhead, e.g., http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/eglibc/lucid/annotate/head:/sysdeps/unix/sysv/linux/wordsize-64/Versions
<slangasek> Keybuk: so when casper-md5check is done checking, it says "press any key to continue"... what's a better way to do that than exhaustively listing all possible keys in an argument to ply_boot_client_ask_daemon_to_watch_for_keystroke()? :)  Should I tell plymouth to shutdown and stay on screen, then claim the console back?
<jono> are you folks aware of a bug in Rhythmbox where the volume is set to minimum by default?
<Keybuk> slangasek: you can't claim the console if you've told plymouth to shutdown
<Keybuk> not unless you want to deal with raw keyboard and graphics mode
<Keybuk> I guess you'd want to extend plymouth to support any key press
<slangasek> Keybuk: OOI, would dealing with raw keyboard and graphics mode be so hard?  Would getchar() no longer DWIM?
<Keybuk> slangasek: it would very definitely not DWYM
<Keybuk> that kind of thing only works in XLATE
<slangasek> there'd be characters on the fd even when no key was pressed?
<Keybuk> yeah, you get them for other things iirc
<slangasek> huh, ok
 * Keybuk isn't an expoert
<Keybuk> you can try it, of course
<Keybuk> plymouth quit --retain-splash is probably what you want
<Keybuk> that'll leave you in graphics mode, with the keyboard in raw
 * slangasek nods
<directhex> what was i supposed to add to /etc/fstab to make my ntfs mount not hang forever?
<directhex> ah, nobootwait
 * lamont pounds his head on grub2's desk
<lamont> given the wonderful error messages about "terminal" and "serial" being unknown/invalid/lalala-need-to-reboot-_AGAIN_, how do I teach grub2 that the console lives on ttyS1,38400?
 * \sh tells lamont to use ILO2 and runs far far away ;-)
 * lamont throws rocks at \sh
<lamont> no ilo on this beast
<micahg> lamont: any chance of an updated nmap in debian?
<lamont> fortunately, I was done playing with what I needed to do today, and decided to maybe put lucid on it to play
<\sh> lamont: GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,9600n8" ?
<lamont> micahg: I think I even have it packaged.  I just need to verify it and upload.  OTOH, been sick much of this week, so I'm playing catchup tomorrow
<micahg> lamont: k, thanks, feel better :)
<\sh> lamont: the hint came from http://linux.xvx.cz/2009/08/debian-with-grub2-and-serial-connection/#comments
<lamont> \sh: and I set that where, I wonder.
 * lamont goes to read
<\sh> lamont: Quote: Edit file containing configuration in Debian: /etc/default/grub
<\sh> dunno if that helps you
<lamont> we'll see
<\sh> lamont: report back pls :)
<lamont> Cannot find list of partitions!
<lamont> I wonder where it expects to find that
<lamont> under /sys, of course.
<lamont> error: bad unit number.
<lamont> error: unknown terminal 'serial'
<lamont> .
<lamont> error: unknown command `terminal'.
<lamont> error: unknown terminal 'serial'
<lamont> .
<lamont> error: unknown command `terminal'.
<lamont> [    0.000000] Initializing cgroup subsys cpuset
<lamont> but it does continue on into the boot
<lamont> and then there's the "cute" bit where it drops to busybox because the root disk wasn't there yet, somewhere between 19 and 34 seconds into the boot.  The drive showed up at 38 seconds
<lamont> so typing 'exit' to busybox?  win
<lamont> anyway, yeah... that fixed it... now I just need to automate that bit... :-(
<lamont> and afk for a few hours.
<lamont> \sh: thanks much
<\sh> lamont: did it work as documented?
<\sh> lamont: plus "add ttyS1 to /etc/inittab" or say upstart to start up a getty for a ttyS
<\sh> or simply add a RIB to your machine ;)
<lamont> got a getty all by itself
<psusi> I'm going over some upstart rules trying to make sure I understand everything and I notice that mountall.conf says stop on starting rcS... does that not block rcS from running until after mountall finishes?  but then mountall daemonizes, which seems to negate that?
<slangasek> psusi: what do you mean, "daemonizes"?  upstart supervises daemons.
<slangasek> and it doesn't block rcS from running until mountall /finishes/, it blocks rcS from running until mountall is /stopped/
<psusi> well, the job runs mountall --daemon, so mountall forks into the background to continue mounting and monitoring for devices to appear that still need mounting, then the initial mountall process exits, which means the mountall task is now finished doesn't it?
<psusi> yes, that difference is what I'm trying to understand
<slangasek> no, --daemon doesn't mean the task is finished
<slangasek> the 'expect daemon' at the top tells upstart to track the grandchild process
<psusi> so rcS is blocked from running until the mountall daemon finishes, even though the initial mountall process exits after forking?  and that does not happen until all of the devices listed in fstab are detected and mounted?
<slangasek> no, not "finishes"
<slangasek> you're reading it backwards
<slangasek> when rcS starts, upstart *kills* mountall if it's still running
<psusi> that doesn't make sense... since it should try to start rcS immediately after starting mountall, which can take some time to finish
<slangasek> no
<slangasek> I think you misunderstand what the rcS job is
<slangasek> rcS != /etc/rcS.d
<psusi> it isn't?  I thought the rcS event caused /etc/rcS to run which executes all the scripts in /etc/rcS.d?
<slangasek> read /etc/init/rcS.conf for yourself
<slangasek> it's only executed when booting into single user mode
<psusi> ohh
<psusi> why was I thinking that /etc/rcS was executed on startup?
<slangasek> it is, but that's executed by /etc/init/rc-sysinit.conf
<psusi> hrm... so a switch to single user runlevel kills mountall then
<slangasek> yes
<psusi> so if you boot into single user mode, and mountall takes some time to complete, it is terminated before it finishes mounting everything?
<slangasek> rc-sysinit.conf is 'start on filesystem' - so mountall won't be killed until it's at least mounted all of the core filesystems
<slangasek> because it's mountall emits 'filesystem', rc-sysinit.conf executes and calls "telinit S", which kills mountall and starts the rcS job
<psusi> I see, so the mountall process directly contacts init and emits these listed events as it mounts the various filesystems, and the sysV rc system doesn't start up until after mountall has finished mounting the core filesystems?  what are NON core filesystems that it could still be trying to mount?
<slangasek> at this point, I think it may only be those filesystems explicitly marked 'nobootwait' in /etc/fstab
<psusi> I see... ok, starting to make sense now... what is the difference between expect fork and expect daemon?  the man page says something about daemon forking twice... I thought a daemon forked once, and the parent process exited leaving the child in the background?
<psusi> ureadahead.conf says exec ureadahead --daemon but expect fork
<slangasek> most daemons fork twice, due to esoteric requirements involving process groups
<psusi> ok, so since mountall starts on startup, and ureadahead starts on starting mountall, upstart starts mountall, then without waiting for it to complete, starts ureadahead in paralell?  if so why does ureadahead start on starting mountall instead of on startup?
<psusi> ohh, but because of the daemon directive, it waits for mountall to perform initial startup, then background the daemon before starting ureadahead?
<slangasek> no, "start on starting" blocks mountall until ureadahead is done
<psusi> huh?  I thought starting was the very first event auto generated by init?
<slangasek> starting, not startup
<slangasek> but reading the ureadahead job, I'm wrong
<slangasek> "start on starting" means ureadahead has to be started before mountall starts
<psusi> yea, it's mountall that is start on startup, ureadhead is start on starting mountall
<slangasek> (if ureadahead were a task, mountall couldn't start until ureadahead was done)
<psusi> I thought it meant ureadahead is started between the time mountall's startup job is run ( which there is none ) and mountall's main job is run
<slangasek> by "startup", do you mean "pre-start"?
<psusi> yea
<slangasek> init(5) - "pre-start [...] This process will be run after the job's starting(7) event has finished"
<slangasek> so ureadahead would be started before any pre-start script
<psusi> so start on starting means this job has to be running before the other job is even pre started?
<psusi> hrm...
<slangasek> yes
<psusi> but the other job can be started before this job is considered running?
<psusi> i.e. start this job first, and if it forks or daemonizes, THEN you can start the other job?
<slangasek> the processing of the "starting" signal is only done when the jobs it triggers are running
<slangasek> if this job forks or daemonizes, that's what tells upstart that it *is* running
<psusi> so if it does not fork or daemonize, but just keeps running... is post-start then run if it exists, then when THAT finishes, the job is considered running?
<slangasek> post-start is run after upstart considers the job to be running.  there are a number of different conditions you can set for upstart to wait for before considering the job to be running - the 'expect' options documented in init(5)
<psusi> wait a second though... ureadahead starts on mountall startING, not started, so it should run in paralell with mountall, not before it
<slangasek> once ureadahead has forked, telling upstart that it's started, mountall will run in parallel, yes
<psusi> I think that is what would happen if it was on startED, but not startING
<slangasek> no
<slangasek> the start condition for mountall is met
<slangasek> so upstart looks for other jobs that are 'start on starting mountall' or 'stop on starting mountall'
<slangasek> and processes those first
<slangasek> and the 'starting' signal isn't done until those other jobs that are '(start|stop) on starting mountall' are started or stopped
<psusi> it seems to me that the man page is saying that the starting event for mountall is emitted before even the pre-start for mountall is run
<slangasek> yes
<psusi> ohh... so it processes the starting event, which means start readahead, THEN actually starts mountall?
<slangasek> yes
<psusi> so the starting event being emitted is processed synchronously before moving on?  hrm...
<Emzzzz> http://imggmi.info/DSC-1268361777.jpg/ do my tits look big?
<lamont> against which package do I file the bug where boot bails out to busybox because it gives up on the root disk showing up 4-20 seconds before it does?
<lamont> when the hell did netcat-openbsd become the default?
<slangasek> mid-lucid-cycle
 * lamont looks for a place to vomit
<lamont> I assume it had rational arguments...
<slangasek> I don't recall seeing any
<lamont> I wonder if it's related to us maintaining a fork of netcat-openbsd since hardy
<lifeless> hmm, confused langpack.. logged in with latin, have klingon menus ><
<jdong> *blinks*
<jdong> http://manpages.ubuntu.com/manpages/intrepid/man3/printf.3.html
<jdong> "including the trailing null byte (' <EOF>"
<jdong> did what I think happen just happen there?
<joefox> looks like there is something missing...
<jdong> it literally attempted to interpret the NULL byte in the manpage
<jdong> which signaled an end of string XD
<joefox> a '\0' ?
<joefox> XD
<jdong> yup
<RAOF> Input sanitisation is for wimps.
<jdong> XD
<jdong> anyone wanna submit that to thedailywtf for giggles?
<jdong> or planet Ubuntu?
<RAOF> Ah.  Sweet, sweet SIGILL
<joefox> what does SIGILL mean?
<jdong> illegal opcode I'd guess
<RAOF> The CPU has barfed on the illegal instruction you've sent it.
<joefox> ah ok. i am new in this channel
<RAOF> Well, there's a surprise.  JIT breaks gjs on armel.
<RAOF> And for an *actual* surprise, it also breaks gjs on i386.
<RAOF> But works on amd64.  Take that, IA32!
<joefox> ^^
<joefox> what is armel? sorry all the questions :/
<RAOF> Arm - those swanky, tiny, processors found in phones and moving into tiny netbooks.
<joefox> oh ok i know arm
<RAOF> Hurray for trying to build a stable library upon mozjs. :/
<micahg> RAOF: a bug in mozjs?
<RAOF> Probably not a bug so much as a changed API without a changed ABI.
<RAOF> Well, except perhaps on arm, where it SIGILLS.
 * micahg just got an armel failure for another uploaded xul192 port
<RAOF> But that's xulrunner-1.9.1, 'cause I can't install xul-1.9.2 on there.
<RAOF> It also seems that something's changed in the mozjs API.  gjs seems to be assuming that destroying a context will call the finaliser, but it's not getting called.
<micahg> RAOF: can you tell me where, that's one reason we can't package it as the api changes, I can look it up for you though
<RAOF> Strangely, this seems to only apply to i386; amd64 sails happily along with the previous behaviour.
<micahg> RAOF: that's weird
<micahg> RAOF: is it that test that failed for me?
<RAOF> If it was a testsuite failure on gjs-unit /js/self on i386, then yes.
<micahg> RAOF: jsapi
<micahg> oh,, js/self
<micahg> yes
<micahg> RAOF: do you want me to look into it?
<RAOF> Yeah.
<RAOF> If you're likely to be able to hunt it down faster, go for it.
<RAOF> I'll give you what I've got so far.
<RAOF> (Once I rebuild this with -DGJS_ENABLE_LIFECYCLE)
<micahg> RAOF: k
<RAOF> It doesn't *actually* break the tests on i386; it just makes them leak memory, which the testsuite detects, and causes a failure.
<micahg> RAOF: do you know which one specifically?
<RAOF> GjsFileImporter
<RAOF> In particular, initialising GjsFileImporter & then destroying the context won't result in it's finalizer being called, which the testsuite detects and bails on.
<RAOF> If you disable JIT, then everything goes swimmingly
<RAOF> GJS_DISABLE_JIT="aww, yeah" make check succeeds.
<micahg> but is it the test or funxtions?
<StevenK> RAOF: A Duffman quote?
<RAOF> StevenK: It was going to be GJS_DISABLE_JIT="hells, yes".  Not a Duffman quote :)
<RAOF> micahg: I'm not sure what you mean.  The tests themselves generate the expected output.  It's in the teardown method of the testsuite which destroys the js context and then checks that everything's been properly destroyed that it fails.
<micahg> RAOF: I don't see GjsFileImporter defined anywhere
<RAOF> gjs/importer.c; it's the javascript name for it.
<micahg> ah, k, sorry, I'm used to C++...
<RAOF> As you would be, if you've been wrestling the mozilla beast.
<RAOF> So, if you define GJS_VERBOSE_ENABLE_LIFECYCLE during the build, test_user_data/logs/gjs.log will contain debugging information about the initialisation & finalisation of JS IMPORT.
<micahg> RAOF: do you have the output of that handy?
<RAOF> http://pastebin.ca/1835094 â successful check, with GJS_DISABLE_JIT
<RAOF> http://pastebin.ca/1835095 -
<RAOF> That one's failed.  Note that there's no finaliser called after Destroying JS context
<micahg> I'll check the finalize function...
<RAOF> Line 973 of gjs/importer.c
<RAOF> That function is simple enough; it's not called anywhere by the gjs code, but it's shoved in the GjsFileImporter JSClass vtable.
<micahg> yes, but I'm wondeing about the functions it uses
<pitti> Good morning
<pitti> slangasek: oh, is that not in sendsigs/omit.d? I'll have a look
<slangasek> pitti: it's an upstart job, so it looks like the handling in /etc/init.d/sendsigs is supposed to ignore it
<pitti> slangasek: I'll track it down
<micahg> pitti: are the retracers working?
<pitti> micahg: no, they broke down a couple of days ago, I didn't yet find time to restore them
<micahg> pitti: k, thanks
<RAOF> micahg: Can I leave that with you?  At worst, we can disable JIT on armel & i386, and everything should work.
<micahg> RAOF: sure
<micahg> RAOF: my guess is it's returning null where it shouldn't
<micahg> but I have to see how the js functions changed
<micahg> RAOF: would you be able to file a bug in LP and assign to me?
<micahg> RAOF: actually, I can do it
<RAOF> Ok.  Thanks.
<micahg> RAOF: I'll talk to asac in the morning (CST) and see if it's worth working on now or later
<micahg> but I'll file the bug so we don't lose it
<dholbach> good morning
<thekorn> good morning dholbach :)
<dholbach> hey thekorn
<micahg> RAOF: is bug 537903 sufficient?
<ubottu> Launchpad bug 537903 in gjs "JS tests failing in gjs on i386 and armel" [Low,Triaged] https://launchpad.net/bugs/537903
<RAOF> armel doesn't fail to call the finalizer; it SIGILLs in libmozjs.  I'll add that to the bug
<RAOF> micahg: There you go; backtrace, such as it is, of gjs dying on armel added to the bug.
<micahg> RAOF: ah, maybe they should be two bugs then?
<RAOF> Quite possibly.
<siretart`> fta: I hope you don't expect to "push" that branch to lucid. what were you referring to?
<micahg> RAOF: k, thanks, I'll talk to asac in the morning
<micahg> RAOF: so, we only have a workaround for i386?
<RAOF> micahg: Disabling JIT works on both i386 and armel.
<micahg> RAOF: k
<alkisg> seb128: in LP bug #401497 you asked if the gdm keyboard layout problem is still an issue in Lucid. I answered there -it is, e.g. Greek people can't write Greek with the default installation- but if you need any more info/testing, I'd be glad to help as much as I can.
<ubottu> Launchpad bug 401497 in ubiquity "wrong keyboard layout after upgrade with autologin" [Low,Confirmed] https://launchpad.net/bugs/401497
<seb128> alkisg, why can't they? it's a bit weird
<alkisg> seb128: because gdm forces a [us] layout
<seb128> alkisg, I don't plan to work on this bug specifically but thanks for being responsive, I'm just looking at bugs we want to milestone for lucid
<alkisg> It doesn't respect the system wide default in /etc/default/console-setup...
<seb128> alkisg, what do you have in this file?
<alkisg> XKBLAYOUT="us,gr"
<seb128> console-setup that is
<seb128> ok
<seb128> I think it's a known issue with multiple values there
<seb128> I'm not sure why you don't get ="gr"
<alkisg> Yes, I think so too. It's really annoying, i.e. we can't preselect greek for e.g. a school
<seb128> I think pitti was looking at that some time ago
<alkisg> seb128: =gr is  *not* a correct value
<alkisg> I needs to be [us,gr]
<seb128> why?
<seb128> that seems to be 2 layouts?
<alkisg> Yes, it is
<alkisg> 2 layouts are needed in many countries
<seb128> why do you need 2 default layouts?
<persia> seb128: Many keyboards *need* multilayer to handle things smoothly.
<seb128> I'm just trying to understand the issue
<alkisg> Because I can't type "www.google.com" without a us layout
<persia> seb128: So you can type in roman and non-roman alphabets easily.
<seb128> alkisg, persia: ok thanks, that's valuable information, I will milestone this bug
<persia> seb128: For reference this affects all non-latin except CJKV
<seb128> persia, ok thanks
<seb128> it makes a good candidate for the lucid buglist I'm building for the desktop team
<alkisg> seb128: as I say in the last comment in the bug report, a reasonable way to solve this is to have a "system default layout" entry in the combobox in the gdm login screen
<alkisg> It's really important for many countries. Thanks for milestoning this :)
<seb128> alkisg, I don't we will do UI changes and new feature now
<alkisg> seb128: no, that's not a new feature
<alkisg> There's a combo box with 200 keyboard layouts there
<alkisg> The default is [us]
<alkisg> That's a wrong assumption
<seb128> well
<alkisg> The default should be [system default]
<seb128> <alkisg> XKBLAYOUT="us,gr"
<seb128> the default is the first in that list
<alkisg> Taken from console-setup...
<seb128> should it be gr,us?
<alkisg> No
<persia> seb128: The list needs to handle multilayer layouts
<persia> (or perhaps not be a list)
<alkisg> By "default" gdm means *the only* layout
<seb128> well, would it be fine if you have us and gr under GNOME
<seb128> with the notification icon to switch
<seb128> and default being set to "us"
<seb128> or would that still be buggy?
<persia> seb128: Not if you use greek in your password.
<alkisg> Right. So gdm is broken now. It doesn't set 2 layouts, it only sets the first one.
<seb128> you can set 2 layouts at the same time?
<persia> seb128: Yes.  Multilayer.
<seb128> or do you mean you need to be able to switch between those?
<alkisg> To be able to switch between them
<alkisg> Gdm *removes* this possibility
<persia> seb128: at the same time.  There's usually special keystrokes that switch between layers.
<alkisg> persia: that's part of the same layout, though
<seb128> persia, right but you can only have 1 layout at time, ie you have both configured and you switch with a shortcut right?
<alkisg> I.e. in Greek I can use right alt+E to type the euro sign
<slangasek> seb128: morning - can you tell me who the right person is to look at bug #445621 in gtk?
<ubottu> Launchpad bug 445621 in libgtk2-perl "libgtk2-perl FTBFS on all archs -- test failures" [High,Triaged] https://launchpad.net/bugs/445621
<seb128> slangasek, I think it's a libgtk2-perl bug
<slangasek> seb128: you think the second failure is, too?
<persia> seb128: No.  X supports up to 4 layers in a keymap.
<seb128> slangasek, I was planning to look at it but tried to finish things before you freeze lucid first :p
<seb128> slangasek, yes
<slangasek> hmm, ok
<seb128> slangasek, let me get you the upstream change
<persia> seb128: So depending on hardware, etc. it's potentially possible to have several simultaneously enabled.
<alkisg> seb128: to make it as clear as I can, because my english isn't good enough: we're not asking for a new feature. It's a bug that wasn't there up until jaunty, and was introduced with the new gdm in karmic. We just need gdm to not mess up with the system defaults...
<seb128> alkisg, right, I don't discuss that there is a bug to fix, I'm just not sure it requires new UI rather than just settings things correctly
<alkisg> The current UI is fine
<alkisg> There's a combobox there with 200 different layout
<alkisg> It just lacks an additional entry: "use the system default layout"
<seb128> slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=591085
<ubottu> Gnome bug 591085 in GtkBuilder "GtkBuilder object ID bounded to GtkWidget "name" property" [Normal,Resolved: fixed]
<persia> Well, the combobox is defective because it can7t handle dual layouts, but that's a different issue.
<alkisg> persia: ok, but I'm not asking for this
<seb128> slangasek, see comment #19
<alkisg> I'm not asking for a new UI that would enable someone to select multiple layouts
<persia> alkisg: Understood.  The "system default" choice is the best workaround we can expect for lucid.
<alkisg> I'm just asking for an entry to respect the system defaults
<alkisg> Whatever those may be. Either 1, 2, or 10 different layouts in XKBLAYOUT, gdm should use those.
<seb128> alkisg, right
<seb128> gotcha
<alkisg> It shouldn't be hard - a copy from console-setup to the gconf key.
<seb128> I would just expect the gconf key in GNOME to be the XKBLAYOUT list by default
<seb128> right
<slangasek> seb128: so we can expect other parts of this test suite to break in the future, because get_name() is not guaranteed to return this value?
<slangasek> (the reason I thought it was a gtk bug was that it's only one object out of several that causes the error)
<seb128> slangasek, well, the semantic changed, it was buggy before and has been fixed, it should not change again no, ie once you fix the testsuite you should be good
<geser> does somebody know if the python-apt 0.8 API gets into lucid?
<seb128> slangasek, but you will probably get the same issue for any get_name() used this way yes
<seb128> slangasek, I can have a look in fixing that today if you want
<slangasek> seb128: no, that's my point, it's only *one* object that shows this behavior with get_name(), and the test suite tests multiple objects
<persia> geser: DktrKranz and mvo were discussing an updated merge.  Check the bugs.
<seb128> slangasek, hum ok, I will have to check what happens there
<seb128> slangasek, I will do that today
<slangasek> seb128: ok, cheers
<seb128> np
<seb128> slangasek, http://git.gnome.org/browse/perl-Gtk2/commit/?id=d0b0e0baf7a611c307040cef13773556a4898d08
<seb128> slangasek, ?
<slangasek> seb128: aha, that's it :)
<seb128> slangasek, good ;-)
<seb128> slangasek, I like when upstream does fix bugs before we report those :p
<slangasek> :)
<seb128> slangasek, the comment also explain why you get it only for that widget
 * slangasek nods
<seb128> which is good to know too ;-)
<pitti> seb128: XKBLAYOUT="us,gr" -> that bug is known; it originally seems to be an installer bug, but we have to workaround it in existing installations
<seb128> pitti, do you have the bug number? I want to add it to our lucid list
<seb128> pitti, if you read backlog that seems to not be a bug in the installer
<seb128> pitti, they apparently need 2 layouts in non latin cases
<seb128> pitti, those 2 same layouts should be in gdm and GNOME
<pitti> seb128: ok, that requires a more intrusive fix then (it's currently a signle layout, not a list
<pitti> seb128: bug 460328
<ubottu> Launchpad bug 460328 in xserver-xorg-input-evdev "Wrong keyboard settings when console-settings has multiple layouts" [Undecided,In progress] https://launchpad.net/bugs/460328
* slangasek changed the topic of #ubuntu-devel to: Archive: Feature Freeze + Beta Freeze | MoM running (but use bzr!) | 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 agree, the multiple layouts there are absolutely deliberate in the installer
 * popey wonders why he's just got an "Ubuntu 9.10 beta freeze now in effect" dated 24/09/2009 from slangasek 
<slangasek> oh, sigh
<popey> ah, my bad, slangasek replied to that mail :)
<popey> *chuckle*
 * slangasek sends a better one
<pitti> cjwatson: libjpeg fix uploaded, FTR
<cjwatson> thanks
<persia> Just to make sure I remember correctly, with BetaFreeze, we're back to hard-freeze, where the release managers need to approve each upload, right?  Do we need special bugs for tracking each approval?
<YokoZar> slangasek: one of the beta freeze emails you sent said 9.10 in the subject
<slangasek> YokoZar: yep, that's why there were two instead of one :)
<seb128> pitti, bug #460328, is that a g-s-d or gdm issue?
<ubottu> Launchpad bug 460328 in xserver-xorg-input-evdev "Wrong keyboard settings when console-settings has multiple layouts" [Undecided,In progress] https://launchpad.net/bugs/460328
<YokoZar> slangasek: ahh ok I thought I got 2 cuz of different lists ;)
<slangasek> persia: please no - upload, let it be reviewed in queue
<slangasek> persia: yell on IRC if that's not working :)
<persia> slangasek: That's how it used to work, and I'm glad to see we haven't added more process.  Thanks.
<pitti> seb128: if we need to support lists, it's both (and potentially -evdev as well, since that ships the udev rules)
<seb128> pitti, should I add gdm and g-s-d tasks there, do you think it's likely fixable for lucid now?
<pitti> seb128: not for beta-1, but for beta-2
<pitti> seb128: you are welcome to add tasks, and assign it to me
<seb128> pitti, ok thanks, adding it to our lucid tasks
<seb128> pitti, danke!
<seb128> bah
<seb128> retracers crashed on "lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error"
 * seb128 removes lock
<pitti> again? thanks
<seb128> np
<ogra> so if i have a package using gksu, lintian screams at me to use su-to-root ... but su-to-root a) lacks functionallity and b) is only in unioverse
<ogra> whats our policy on that ?
<persia> Our policy is undecided.
<persia> We are not planning to start installing menu by default on every installation, so the Debian policy doesn't work.
<persia> Try to change your application to not need gksu because it uses policykit or something.
<dholbach> can somebody moderate my mail to ubuntu-devel-announce@
<cjwatson> done
<dholbach> thanks cjwatson!
<Chipzz> lamont: fwiw, my opinion on https://launchpad.net/bugs/532587 is that the user/group should be removed on purge
<ubottu> Launchpad bug 532587 in puppet "removal of package does not stop daemon" [Medium,Fix released]
<Chipzz> I expect (and I know that it doesn't hold right now anyway, but...) apt-get install foo; dpkg -P foo to be idempotent (if foo doesn't pull in extra dependencies)
<Chipzz> imo, if I debootstrap 2 environments, and run 'apt-get install foo; dpkg -P foo' in one of them, a diff should show up no differences at all
<persia> Chipzz: Why?  Can we be sure there are no logs or extra files that might have that user/group as owner?  Are we sure that the admin wouldn't prefer to keep the same UID/GID if later reinstalled?  Do we expect the admin to be running out of system UID/GIDs ?
<cjwatson> persia: this is something that piuparts checks in Debian (and it certainly isn't at anywhere near 100% compliance)
<cjwatson> --purge should remove the uid/gid; if the admin wants to keep configuration, they should use --remove
<persia> cjwatson: Ah.  We were discussing this recently, and nobody could find the relevant bits in policy.
<persia> mathiaz: You may also be interested in the above comment.
<cjwatson> I'm sure it's an interpretation thing, but given that uids/gids reside in /etc I would account them as configuration
<persia> Plus the idempotent argument above.
<cjwatson> obviously you have to be careful about existing files using those ids; I'm not claiming it's easy to comply with this
<cjwatson> particularly in the case of a user shared among multiple packages
<cjwatson> and there may well be cases where complying with the letter of policy is worse than not doing so.  there's probably an extensive argument on this somewhere in the debian-policy list archives. :-)
<persia> I've always been a fan of leaving logs on --purge for later reference, and tend to like to run daemons as non-root, writing their own logs, which is probably why I had the opinion I did.
<cjwatson> Chipzz: BTW I hope you're not counting /var/log/dpkg.log. ;-)
<cjwatson> persia: policy is explicit that logs should be removed on purge
<cjwatson> 10.8
<persia> That defeats the last bastion of my support for my previous position.
<persia> Thank you for the disabuse.
<cjwatson> but of course if stuff is lying around in home directories or something ... gets complicated I'm sure
<persia> Well, aside from the shared UID/GID scenario, it ought be possible to know what is being done, and (mostly) clean up in the maintainer scripts.
<persia> For shared UID/GID, I thought the maintainer was supposed to request allocation of a system-wide UID.
<cjwatson> depends how shared
<cjwatson> if it's among a group of cooperating packages maintained by the same people, that's not necessary
<cjwatson> in fact it's not really necessary in general; the only reason to require allocation of a static uid is if you actually care about the number
<persia> Is that because of the "same people" or because of the "cooperating packages"?
<cjwatson> otherwise in general packages should just use adduser --system
<cjwatson> cooperating> actually a red herring I think, thinking on the fly :)
<persia> On an unrelated note, the debian-installer powerpc FTBFS confuses me.  It builds fine on a local powerpc.
<cjwatson> you only really need static ids if the id is baked into binaries somehow that for some reason can't or won't use normal name lookup
<cjwatson> that ftbfs is bug 537733
<ubottu> Launchpad bug 537733 in launchpad-buildd "/etc/apt/sources.list unreadable on powerpc" [Undecided,New] https://launchpad.net/bugs/537733
<persia> Aha, so really we should be striving for a minimum of static UID/GID?
<cjwatson> yes - indeed my default response as base-passwd@packages.debian.org to such requests is to attempt to persuade the requestor that they can do things some other way. :)
<Chipzz> persia: imo it really doesn't matter - the admin requested purge, the package should be removed as complete as possible
<cjwatson> /usr/share/doc/base-passwd/README <- very few package-specific ones have been allocated
<cjwatson> the global static ones (0-99) are "shared" in a stronger sense, but it takes a lot to get me to add one of those
<persia> Chipzz: Yes.  I now agree with you.
<cjwatson> plugdev was the last one, and even that was arguably a mistake
<cjwatson> and the reason that was static was that we needed to hardcode the gid in /etc/fstab from the installer
<cjwatson> (at the time)
<persia> So the static UID/GID registrations can be thought of as extremely low-priority bugs, in a way.
<cjwatson> kind of.  of course, once they've been allocated, that's final.
<cjwatson> deallocating them obviously wouldn't free up the numbers
<Chipzz> cjwatson: does plugdev still get used these days?
<cjwatson> the *uses* of the registrations are low-priority bugs
<cjwatson> Chipzz: there are probably ghosts here and there, but mostly not
<Chipzz> so the number can't be deallocated even if the package stops to use them, or the package is obsoleted?
<persia> Chipzz: No, because some people have very long-lived systems (my last potato system is still at my desk, although I haven't turned it on in several months, and it was running intrepid or jaunty last I looked)
<siretart`> fta: in any case, can you please rename the package chromium-codecs-ffmpeg-nonfree? I guess something like 'chromium-codecs-ffmpeg-extra' would be much clearer.
<Chipzz> persia: I mean in future releaese
<Chipzz> obviously you can't deallocate them from a past release, duh ;P
<siretart`> fta: the package description sounds like ffmpeg would contain 'nonfree' codecs, which isn't exactly true. In fact, some ffmpeg developers have expressed that they are very unhappy with that naming.
<persia> Chipzz: Again, I have a machine that was first installed Debian potato at my desk, so it's been continuously upgraded for a decade or so (including HW upgrades).
<Chipzz> persia: but once you upgrade that potato system, if you have packages using static uids, and those migrate to a solution where they aren't needed anymore, or obsoleted...
<persia> Chipzz: The point being that we can't ever know that a given UID or GID really isn't being used on any systems.
<persia> Chipzz: I still have that UID in my /etc/passwd
<Chipzz> persia: uhm, yes you can?
<cjwatson> Chipzz: the numbers will never, ever be deallocated.  live with it. :-)
<geser> is using clean-la.mk from cdbs the prefered way when "fixing" .la files? (a .la files references an other .la file without a dependency on its -dev package)
<cjwatson> I don't care whether it's theoretically possible to work it out, maybe, sometimes.
<persia> Chipzz: I can't because the new versions of the package that use dynamic methods to find out the UID or GID based on the name will get the old numbers and not run adduser --system
<Chipzz> as a package maintainer you can fix your postinst etc scripts to migrate known files away from the static UID or GID for example
<Chipzz> persia: right, they can not be removed from an UPGRADED system
<Chipzz> what I meant is that they are no longer part of the standard /etc/passwd etc on NEW installs
<cjwatson> the allocations in /usr/share/doc/base-passwd/README are not part of /etc/passwd unless explicitly created by a package anyway.
<persia> Chipzz: Sure.  You could probably do that, but you can't ever reuse a previously allocated static value.
<cjwatson> indeed we have sometimes removed entries from new installations, but as you say, reuse is forbidden.
<Chipzz> on a related note
<Chipzz> someone should probably beat some sense into Bernstein :P
<Chipzz> qmail packages are ARGH
<seb128> slangasek, still awake? are you working on the gtk-perl buildfix or should I do that?
<seb128> slangasek, I can do it now
<geser> will the beta1 freeze get lifted after beta1 release?
<lamont> persia: I knew there were reasons I removed uids/gids
<persia> lamont: I think I preferred "tastefulness" to "well, policy says to do it that way", but yeah :)
<persia> lamont: Also, do you know who can fix bug 537733 ?
<ubottu> Launchpad bug 537733 in launchpad-buildd "/etc/apt/sources.list unreadable on powerpc" [Undecided,New] https://launchpad.net/bugs/537733
<lamont> persia: is it reproducible?
<cjwatson> yes, happened two or three times now
<persia> Yes.  I just reproduced it.
<lamont> because looking at builds, the file sure seems readable to me...
<persia> lamont: Look at the debian-installer build
<persia> https://launchpad.net/ubuntu/+source/debian-installer/20081029ubuntu90/+build/1557158
 * lamont forces the build down ross' throat to see if that changes anything
<lamont> -rw------- 1 root root 48 Mar 12 11:58 /etc/apt/sources.list
<lamont> I take back what I said
<lamont> WTF?
<lamont> OH.  &^$%)&*&^%)$^%)P TWISTED
 * lamont goes to beat on the right peopld
<persia> lamont: Thank you.
<lamont> persia: slapped around, fix live and testing on ross, will smack adare once its build finishes, and will be pushing code to close the bug shortly
<persia> lamont: Excellent.  Thank you very much.
<lamont> WARNING: The data in 'translation-status' is older than 2 weeks.
<lamont>          Should it maybe be updated?
<lamont> giggle
<cjwatson> makes slightly more sense in Debian :-)
<lamont> heh
<cjwatson> ooh.  I think I have console-setup working again
 * cjwatson fine-tunes against bootchart
<lamont> 2010-03-12 12:16:57+0000 [-] Unpacking anna (from udebs/anna.udeb) ...
<lamont> I think that means it's going to work
<cjwatson> yep, looks good
<persia> At least the failure we have been seeing isn't the issue.
<lamont> so.. when my boot bails out to busybox with ZOMG-NO-ROOT-PARTITION literally < 5 seconds before the partition shows up from scsi, what package do I file that against>?
<lamont> I suppose I'm magically supposed to know about rootdelay at install time so that I can fix it?
<lamont> persia: and built successfully
<persia> lamont: Wonderful.  I have renewed confidence in beta for powerpc.  Is there anything else I should add on the fpc bit?
<lamont> dunno - do keep pestering me though
<persia> OK.  Please review the last comment in bug #67544 then, just to confirm I've added all the right bits.
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Unknown,Fix released] https://launchpad.net/bugs/67544
<persia> Also let me know if I should pester some nominated third party instead :)
<lamont> persia: the last 2 paragraphs are a nice restatement of the practice we've always followed
<persia> I figured, but given that the last set of instructions didn't work, I felt it wouldn't hurt to be overprecise.
<lamont> true
<lamont> was kind of hoping for the expanded list of exactly which versions of which debs were fetched, since that apt-get command referencing ftp.debian.org?  not so functional behind the buildd firewall
<persia> lamont: I'm really only pulling those 5 debs from Debian.  Everything else is lucid.
<lamont> awesome
<persia> That's the bit about --download-only and then sed on sources.list with a new cache update before the install loop.
<lamont> persia: the other bit here is that we're using this as a perfect test case for another admin to validate my "how to bootstrap a package" instructions
<persia> lamont: That's why I keep volunteering to chase someone other than you about it :)
<Garfeild> hi all
<Garfeild> Where can I found sources of Installation manager from LiveCD?
<cjwatson> the installer, you mean?  apt-get source ubiquity
<Garfeild> thanks
<qense> statik: An idea for the Ubuntu One GSOC project idea: integrating Ubuntu One with a website, maybe something like Roundcube -- contacts -- or something else. It would be something great: data integration between the desktop and the web.
<doko_> qt4-x11 is a 160MB source? insane ...
<emgent> http://www.ns.umich.edu/htdocs/releases/story.php?id=7551
<apw> cjwatson, this dpkg change to add an fsync ... when does it add the fsync?
<Keybuk> apw: heh, I was just about to grab him too
<Keybuk> apw: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=62668eb
<Keybuk> that's the patch
<apw> Keybuk, ta
<cjwatson> right - there was another one upstream to do the same for status file writes
<Keybuk> the one in tarobject would be the culprit I expect
<cjwatson> culprit?
<Keybuk> cjwatson: you've utterly killed dpkg performance from what we can tell
<Keybuk> it took over an hour to unpack the linux headers deb
<Keybuk> if it's doing an fsync() before every rename() for every single file in a deb ...
<apw> there are 11k files in there, so we are suspecting we have 11k fsync's now
<cjwatson> all I did was backport it, but possibly - I was more immediately worried about stemming the flow of correctness
<cjwatson> bugs
<cjwatson> but yeah, an hour is ridiculous
<Keybuk> apw: which options are we mounting ext4 with by default at the moment?
<apw> data=ordered i believe
<cjwatson> I can take out that fsync and we can see if that helps; the bugs were more related to getting ENOEXEC on maintainer scripts
 * apw checks
<cjwatson> we were getting flooded by bugs of that form
<apw> cjwatson, i worry the one you need applies to all files
<Keybuk> cjwatson: that would only be true if people have changed their ext4 mount options though, no?
<cjwatson> apw: could you rephrase that?  I don't understand
<Keybuk> our defaults are sync metadata first
<cjwatson> Keybuk: I have no idea, feel free to debug
<apw> cjwatson, if you need the rename on the maintainer sync, i won't be supprised if its the same one we don't want for non-maintainer
<cjwatson> bug 512096 is the master Ubuntu bug
<ubottu> Launchpad bug 512096 in dpkg "[MASTER] Exec format error : package failed to install/remove : installation/removal script returned error exit status 2" [High,Fix released] https://launchpad.net/bugs/512096
<smb> Keybuk, apw Remember there has been the issue that the default was changed implicitely on Karmic
<cjwatson> note the duplicate count
<smb> Eh forget it that was ext3 I thinkg
<cjwatson> apw: well, maintainer scripts are used rather more immediately
 * apw does not see how an fsync could fix any of these issues unless the filesystem is well broken
<Keybuk> apw: this is the whole O_PONIES problem in a nutshell
<Keybuk> Ted would describe it as "but you didn't call fsync(), so why would you expect the data you write/permissions you applied to be visible on the filesystem yet?"
<Keybuk> if one process opens file, writes, set permissions, closes
<Keybuk> there's no guarantee that a separate process will see that
<apw> fsync only guarentees it will survive a crash
<apw> as far as i know there is no ordering issue between threads
<Keybuk> well, that's a different argument
<Keybuk> at least the bug colin quoted explicitly says "crash"
<apw> hrm
<Keybuk> actually, no
<apw> you'd think a sync at the end of the extract would do the trick
<Keybuk> I think there *are* ordering issues between threads
 * Keybuk is recalling presentations
<apw> but yeeks ... well we don't need to worry about the time it takes to compress the initramfs any more :)
<Keybuk> POSIX provides no guarantees about the contents of files between threads
<Keybuk> of their metadata
<cjwatson> somebody did suggest a single sync()
<Keybuk> or of their metadata, that should say
<cjwatson> apw: as I said in the comments, we can address the performance, I wasn't particularly expecting it to stay this way for lucid
<cjwatson> s/comments/changelog/
<apw> cjwatson, that seems more reasonable, but ...
<Keybuk> so if one thread writes, the other isn't guaranteed to actually see the written data until fsync()
<apw> Keybuk, hrm, ok ...
<Keybuk> fsync() is not "guarantee data hits disk"
<Keybuk> fsync() is "guarantee data is available for other processes"
<Keybuk> so in fact, fsync() doesn't necessarily make you safe from crashing <g>
<apw> fsync really is 'to disk'
<sistpoty|work> Keybuk: I beg to differ
<apw> DESCRIPTION
<apw>        fsync() transfers ("flushes") all modified in-core data of (i.e., modiâ
<apw>        fied  buffer cache pages for) the file referred to by the file descripâ
<apw>        tor fd to the disk device (or other  permanent  storage  device)  where
<Keybuk>        Calling  fsync()  does  not  necessarily  ensure  that the entry in the
<Keybuk>        directory containing the file has  also  reached  disk.   For  that  an
<Keybuk>        explicit fsync() on a file descriptor for the directory is also needed.
<apw>        that  file  resides.
<Keybuk> sistpoty|work: I'm reading slides presented by the ext4 filesystem maintainer here
<Keybuk> if you have more authorative notes on the behaviour with fsync on ext4, please do share
<sistpoty|work> Keybuk: I'm using common sense :P
<cjwatson> the problem reported here was not, though, that the directory entry didn't exist
<Keybuk> sistpoty|work: fsync does not guarantee the data has reached disk, because ATA and SCSI do not provide any such barrier command
<apw> Keybuk, i think with ordered mode, the updates may ben ensured
<Keybuk> you can send the writes to the disk, and the disk can acknowledgfe
<Keybuk> but there's no guarantee the disk has done anything with them other than store the need to write in its memory
<sistpoty|work> Keybuk: the disk guarantees that the data in the cache gets written
<cjwatson> (FWIW, I did test an upgrade before upload, and while it was slower, I didn't see anything like that order of slowdown or I probably wouldn't have uploaded it)
<Keybuk> sistpoty|work: not according to Ted
<apw> Keybuk, that may be true, but the disk is lying if it says yes when its not written yet
<Keybuk> cjwatson: the killer seems to be "packages with thousands of small files"
<Keybuk> apw: apparently the disk is permitted to lie
<Keybuk> anyway
<Keybuk> that's a little sliding off topic
<Keybuk> the key point is:
<Keybuk> process #1 writes
<Keybuk> process #2 reads
<apw> Keybuk, i suspect its not allowed to, but they do
<Keybuk> there's no guarantee in POSIX that process #2 can see what process #1 wrote
<Keybuk> unless process #1 happened to call fsync()
<Keybuk> and since dpkg uses separate processes to unpack
<Keybuk> that would explain the bug
<apw> that leaves us in a hole
<Keybuk> dpkg unpacks the tarfile, writing maintainer scripts
<sistpoty|work> Keybuk: a proper disk will write the data. if power goes out power to do the write is gained from the still rotating disc ;)
<Keybuk> and calls rename()
<Keybuk> at the rename() point, there's no guarantee that the metadata is sync'd
<Keybuk> though fwict, ext4 data=ordered *is* supposed to guarantee that
<Keybuk> sistpoty|work: again, please cite references
<cjwatson> what are the guarantees on sync()?
<sistpoty|work> Keybuk: please cite references that it's not the case
<Keybuk> sistpoty|work: for a start, the fsync man page
<Keybuk>        If the underlying hard disk has write caching enabled,  then  the  data
<Keybuk>        may  not  really  be  on  permanent  storage when fsync() / fdatasync()
<Keybuk>        return.
<cjwatson> sistpoty|work: I would appreciate it if we could stay on the topic of this bug, and not go off onto a tangent about how it should be (which we had at great length when the whole ext4/rename/fsync saga came up last summer)
<Keybuk> also see Ted Tso's presentation given at the Linux Filesystem Summit last year
<apw> Keybuk, does that mean not another thread will be ok
<apw> ie can we only sync the maintainer scripts
<apw> ie a process which is not a thread
<cjwatson> we do need to sync other things at *some* point - the maintainer scripts will use the contents of the package
<Keybuk> cjwatson: I *think* sync() on a filesystem is intepreted as "fsync all files currently open"
<Keybuk> but, reading my notes and Ted's notes here
<Keybuk> that won't be right
<Keybuk> the problem is that
<apw> cjwatson, yeah that was what i was angling at too
<Keybuk> open ()
<Keybuk> write ()
<cjwatson> void sync(void); # of course
<Keybuk> fstat ()
<Keybuk> close ()
<Keybuk> rename ()
<Keybuk> there's no guarantee that the rename() actually copies the metadata
<Keybuk> which is, I suspect, what you're seeing
<cjwatson> Keybuk: that's the problem discussed at enormous length last year, and I was under the very strong impression that ext4 had been modified to consider rename() a barrier
<Keybuk> cjwatson: only depending on mount options
<cjwatson> even if Ted didn't like it, and didn't put it in his presentation ;-)
<Keybuk> which is why I'm wondering if most of the reporters have changed their ext4 mount options
<Keybuk> perhaps related to the whole bruaha about the fact we changed the default on them in karmic
<cjwatson> 200 bugs?  I suppose it's possible but this is a *lot*
<Keybuk> possibly ... but otoh, I've *never* seen this issue
<Keybuk> and I upgrade a *lot*
<cjwatson> and I'm not sure it's an excuse for dpkg to fall over in a smelly heap anyway
<Keybuk> cjwatson: right, so this was the whole O_PONIES thing
<apw> we cirtinaly changed the default to be sensible now
<Keybuk> the response from Ted was "use fsync() if you really want the data there ... but I'll add a data mode to provide the guarantee that ext3 did"
<apw> to err on the side of safety
<apw> i guess the issue is not that we have fsync'd but that we wait for it to finish before moving on to the next file
<Keybuk> I think you have to wait for it to finish before you can rename()
<apw> perhaps so, but none of that stops you moving on to the next file per-see
<apw> as in using a thread per file in some sense and overlapping N files then each could fsync
<cjwatson> is the file *permanently* truncated if you don't fsync before rename?
<apw> and likely not break things
<Keybuk> cjwatson: I thiiiiiink so
<cjwatson> I didn't think that was the case
<Keybuk> also permanently without its metadata
<cjwatson> I thought it merely broke assumptions that the file was atomically in-place after rename
<Keybuk> Ted sadly seems asleep right now
<apw> Keybuk, now that i find hard to believe
<apw> yeah i can believe there might be a window, but permenantly ... i doubt
<Keybuk> it may be "shows up later" of course
<apw> i would assume at least expec the next pdflush run to make it right
<apw> and likelyt he window is smaller than that
<cjwatson> of course, that is what dpkg is trying to achieve by its "write to .dpkg-new, rename" thing
<cjwatson> it's deliberately trying to ensure that the window where you don't have full contents is *zero*
<cjwatson> not just "oh, not a lot, pdflush will get to it"
<apw> yeah fsync is not mad conceptually
<cjwatson> because otherwise you end up with unreliable applications, etc.
<apw> its that its blocking necesarily that its an issue
<Keybuk> yeah, dpkg is using ian's ancient and wholly sensible that "write over there, rename to where you want it" is a very big and obvious clue about atomicity
<Keybuk> and that was basically the crux of the argument against Ted
<apw> i wonder how hard it would be to have multiple paralell writeres
<cjwatson> it's news to me that ext4 only gained this guarantee on data=ordered, but reading git log I see that you're right
<Keybuk> you have to do this rename() to provide atomicity of contents *anyway*
<apw> so that each can fsync as long as they like
<cjwatson> apw: in dpkg?  *swallow* don't go there
<apw> shame
<apw> according to the sync() manual page that isn't guarenteed to wait for the sync to complete
<Keybuk> apw: yes it is
<apw> though it is believed to for current versions
<Keybuk> apw: see BUGS
<apw> thats what i just presee'd
<Keybuk> Linux always waits for sync() to finish
<apw> sync does here, but not everywhere where sync is
<cjwatson> Keybuk: on another note, I almost hate to ask, but is the plymouth stuff likely to land in time that I can say it's done in the release meeting this afternoon? :)
<apw> so its not a portable solution
<Keybuk> cjwatson: we hit other bugs in testing
<Keybuk> have you tested it to see whether it works for you?
<cjwatson> "it" - your plymouth stuff?
<Keybuk> yes
<Keybuk> cjwatson: ppa:scott/ppa
<cjwatson> I didn't know you'd published it :)
<cjwatson> aha
<sgallagh> Keybuk: Who's handling SSSD in Ubuntu these days?
<Keybuk> nope, can't decode that one?
<Keybuk> super secret squirrel detector?
<Keybuk> SQUIRREL!
<sgallagh> Keybuk: System Security Services Daemon
<Keybuk> sgallagh: nope, still drawing a blank there
<Keybuk> Prior to Ted Ts'o's session on fsync() and rename(), some joker filled the room with coloring-book pages depicting ponies. These pages reflected the sentiment that Ted has often expressed: application developers are asking too much of the filesystem, so they might as well request a pony while they're at it.
<Keybuk> ...
<Keybuk> heh
<Keybuk> the "joker" was Ted!
<Keybuk> http://blahg.josefsipek.net/?p=364
<sgallagh> Keybuk: I was wondering who was the Ubuntu maintainer. We (upstream) are working on releasing 1.1.0 next week, and I wanted to get them to pull down the nightlies and make sure we haven't broken anything on Ubuntu
<Keybuk> sgallagh: Ubuntu doesn't have maintainers
<Keybuk> (mostly)
<sgallagh> ...
<Keybuk> we use the time honoured tradition of "who touched it last"
<sgallagh> Keybuk: Ok, so "Who touched it last"? :)
<Keybuk> sgallagh: dunno, never heard of it
<Keybuk> sgallagh: what does Launchpad say?
<sgallagh> Keybuk: I have discussed it with you on at least three separate occasions :-/
<Keybuk> sgallagh: I have literally hundreds of discussions per day
<sgallagh> Looks like Mathias Gug
<Keybuk> and am right now devoting 95% of my brain to reading about ext4's issues with rename()
<sgallagh> Ouch
<Keybuk> now is not a good time for me to pretend to be google for you
<sgallagh> Keybuk: no problem. I understand.
<sgallagh> I'm not familiar with Ubuntu at all, really. A simple "It's in launchpad" would have been all the direction I needed :)
<Keybuk> sgallagh: everything is in Launchpad
<sgallagh> Good to know
<cjwatson> sgallagh: I have a browser keyword for https://launchpad.net/ubuntu/+source/%s
<cjwatson> substitute in a source package name and that gets you everything about that source package - very handy
<sgallagh> cjwatson: Thanks
<sgallagh> I mostly develop in Fedora, so my knowledge of other distros' build environments is... limited.
<cjwatson> Keybuk: trying that out in conjunction with my console-setup work, thanks
<tjaalton> sgallagh: hi, yeah mathias uploaded 1.0.2 on january, and it probably deserves an update since that version is known to be broken ;)
<cjwatson> though it'll be a "works/doesn't-work for me" at best, I have too many other things to do as well
<sgallagh> tjaalton: Yeah, that's rather old.
<sgallagh> tjaalton: We're aiming to launch 1.1.0 sometime next week, but I'd like to know ahead of time if we're going to break the build on a non-Red Hat-based build-system.
<Keybuk> cjwatson: of those 200-odd bugs, don't suppose you have a rough idea how many were "after a crash ..." and how many were "dpkg went wrong all on its own!"
<cjwatson> Keybuk: do apparmor and brltty need to be migrated to udev/upstart at all for lucid?  they're still on the list, but I'm wondering if they should be postponed at this point
<sgallagh> tjaalton: So if you have some free time...
<cjwatson> Keybuk: unfortunately not, somebody else was dealing with triaging them and I talked to that guy rather than doing most of the legwork myself
<cjwatson> Keybuk: it was jibel, I believe
<tjaalton> sgallagh: I managed to get winbind to work, and haven't had time to play with sssd for awhile
<sgallagh> I'd like to collaborate with whomever is going to do the build, because a few things changed (of note, we're producing quite a few additional shared libraries)
<Keybuk> cjwatson: I would like to, if I find the time
<tjaalton> sgallagh: I can try if it builds
<sgallagh> tjaalton: That would be great.
<sgallagh> tjaalton: What's in our nightly right now is pretty close to the final build (unless of course we've broken it for other distros)
<tjaalton> sgallagh: ok, I'll try 1.0.99 first, or is it too old to bother?
<cjwatson> Keybuk: beta-2, then?
<Keybuk> cjwatson: yeah
<sgallagh> tjaalton: Better to use the latest nightly.
<cjwatson> ok, updating metadata
<Keybuk> it's one of those "they should have been done by now, but too many other things that should have been done by are taking too long" things
<Keybuk> e.g. I've been saying "Plymouth will be uploaded today" all week
<sgallagh> tjaalton: I made several build-system changes after 1.0.99 (not that I had originally planned to...)
<tjaalton> sgallagh: where can I find the nightly build?
<Keybuk> cjwatson, apw: ok, so my understanding is that after open() write() close() rename(), there is a period during which there's no guarantees what the file might actually contain
<Keybuk> and that in practice, this period tends to be "up to 5s"
<cjwatson> Keybuk: we should probably revisit the dpkg discussion after beta-1/
<cjwatson> ?
<Keybuk> so writing out maintainer scripts, renaming them, then trying to exec() them may fail
<Keybuk> because they're not executable
<Keybuk> and because they don't have any data in them
<sgallagh> tjaalton: git clone git://git.fedorahosted.org/sssd.git
<Keybuk> I'll need to talk with Ted to make sure I'm right though
<cjwatson> though I suppose it wouldn't hurt to check that d-i doesn't take unreasonably long
<tjaalton> sgallagh: got it, thanks
<sgallagh> tjaalton: There's an RPM repository available at http://jdennis.fedorapeople.org/ipa-devel/fedora/12/x86_64/os/ if you want to compare to the Fedora packages
<tjaalton> sgallagh: is the packaging in git or svn?
<sgallagh> tjaalton: I don't understand the question
<tjaalton> sgallagh: the spec file etc
<tjaalton> like in cvs.fp.org
<sgallagh> tjaalton: We have a reference spec file in the contrib/ directory in the source
<tjaalton> alright
<sgallagh> That forms the basis for what goes into cvs.fp.org
<sgallagh> (Right now cvs.fp.org is still building SSSD 1.0.5)
<tjaalton> the spec file in contrib/ is older :)
<sgallagh> tjaalton: Huh?
<tjaalton> at least the version says 0.6.0
<sgallagh> That doesn't seem right. Hang on.
<sgallagh> Oh, ignore the changelog
<tjaalton> ok
<sgallagh> We don't usually keep that up to date in that spec file
<sgallagh> We should, though
<sgallagh> At some point I'm going to make that autogenerated from the git commit list.
<tjaalton> ok I'll give it a go and will post the result on #freeipa :)
<sgallagh> tjaalton: Thanks much!
<jibel> Keybuk, cjwatson, hi, to answer your question above. nearly 90% are due to a system crash.
<gnumdk> Hello
<gnumdk> Is there any firefox packager in the place?
<jibel> Keybuk, I reviewed a large part of them  http://paste.ubuntu.com/394082/
<Keybuk> jibel: that's good to know
<Keybuk> it's a shame we don't know which ext3/4 mount options they're using
<Keybuk> or if they're using XFS, etc.
<tjaalton> mathiaz: hey, sgallagh asked to test-build the upcoming sssd 1.1.0. I did that, seemed to build fine, though it probably needs some packaging changes
<mathiaz> tjaalton: hi - good to know
<tjaalton> had to comment out the patches, and the final packaging phase fails, but upstream-wise it builds fine
<mpt> mvo, bug 538129
<ubottu> Launchpad bug 538129 in software-center "UI freeze exception: Remove stars and reference to non-existent "reviews"" [Undecided,New] https://launchpad.net/bugs/538129
<jibel> Keybuk, from the type of reporter, most of them are using the standard setup.
<mathiaz> tjaalton: I was planning to upload the latest 1.0.X to lucid
<mathiaz> tjaalton: It seems that 1.1.0 has new features, which is too late for lucid IMO
<sgallagh> tjaalton: I suspect that the patches in your build-system were the ones that we got pushed upstream a few months ago
<jibel> Keybuk, the problem appeared in Jaunty, with the release of ext4
<tjaalton> sgallagh: actually they just touched the config, and Makefile.am to change some paths
<tjaalton> mathiaz: well, I'll let sgallagh comment on that :)
<sgallagh> oh, ok. I thought it was the linking bug we fixed a while ago
<tjaalton> sgallagh: nah it never got to the package..
<Keybuk> jibel: the "standard setup" has changed many times
<tjaalton> could've uploaded it myself but.
<sgallagh> mathiaz: Is lucid in feature freeze?
<mathiaz> sgallagh: yes
<mathiaz> sgallagh: that's why I was planning to upload the latest 1.0.x (1.0.4) IIRC
<tjaalton> it's 1.0.5
<sgallagh> mathiaz: It's 1.0.5, but there are no functional changes between them. We just discovered that we were missing license attribution on several files.
<sgallagh> And we removed some dead code
<tjaalton> the package is in universe though, and because of the linking bug was practically unusable :)
<tjaalton> so maybe no-one used it in the meantime
<tjaalton> (other than me)
<tjaalton> no wait, some Finn thanked on the bug for the linking patch :)
<sgallagh> :)
<sgallagh> So, yeah, there are some new features in 1.1 (https://fedorahosted.org/sssd/wiki/Releases/Notes-1.0.99 has a list of pretty much all of them, we've mainly just been stabilizing since then)
<sgallagh> The three biggest are full IPv6 support, support for ldap referral tracking and we substantially improved performance when enumerate=false (so it's now the better solution for 99% of all deployments)
<psusi> Keybuk: got some questions for you about ureadahead... does --dump list the files in the order they were accessed?  Is that the order they are read in, or are they read in inode order or something else to attempt to speed it up?
<Keybuk> psusi: depends on --sort ;-)
<psusi> Keybuk: which part?  the dumping or the reading?
<Keybuk> --dump usually dumps files in the order that they'll be opened
<psusi> ok... and when they are read, are they read in that order, or some other order to attempt to minimize seeks?
<Keybuk> no
<Keybuk> ureadahead doesn't read files ;-)
<Keybuk> files are merely a method of getting to blocks
<psusi> well, it calls readahead() on the files in question ;)
<Keybuk> no it doesn't
<psusi> it doesn't?  that's what the man page said I could have sworn
<Keybuk> that's the kind of thing that dumb-arse entirely-un-Ã¼ber readahead implementations do ;-)
<psusi> ohh, goody.... so you do it better?  I was thinking that calling readahead() was sub-optimal
<psusi> so what does ureadahead do?
<Keybuk> depends on whether you're using an SSD or HDD :-)
 * psusi is trying to use defrag to pack the files in the most optimal way
<psusi> well let's start with HDD then go into SSD since I just ordered one yesterday and my wife says it arrived an hour ago ;)
<Keybuk> HDD
<Keybuk> given a set of files that were opened during boot
<Keybuk> we query the kernel to find out what segments of those files are in the page cache
<Keybuk> then, for each of those segments, we query the kernel to break them into lists of on-disk extents
<psusi> ohh, it doesn't use blocktrace to see what is actually being read and in what order?
<Keybuk> we take the big list of on-disk extents, and sort that
<Keybuk> that gives us the "blocks to be read"
<Keybuk> we can't read blocks directly though, we need file descriptors
<Keybuk> so we retain the list of opened files (which is sorted by ext inode number, so roughly on disk position)
<Keybuk> we open all files in one pass
<Keybuk> then, with all the files open, we iterate the blocks list
<Keybuk> this means that as far as files are concerned, our reading is entirely random
<Keybuk> we might read 4k from the end of the file
<Keybuk> then 4k from the middle of another file
<Keybuk> then 4k from the start of the first file
<Keybuk> then 16k from another file
<Keybuk> etc.
<psusi> aye, so you read in actual block order to minimize seeks?
<Keybuk> correct
<Keybuk> ureadahead under blktrace looks like two (well three) passes
<psusi> and what method do you actually do the reading by if not readahead()?
<Keybuk> you have a pass to open the files from start to end of the disk
<Keybuk> then a pass across the disk to readahead
<Keybuk> we use readahead, just not "on [whole] files"
<psusi> right, that's what I thought, you specifically readahead only the parts of the files that ar eneeded
<Keybuk> yes
<Keybuk> in a random order with other files interspersed
<psusi> aye, in the order the blocks actually appear on disk
<Keybuk> on SSD, this is slightly different
<Keybuk> we don't break file segments by on disk extents
<Keybuk> the files list is sorted by access order
<Keybuk> the block list is "collapsed" files list
<Keybuk> we iterate the blocks list without opening files
<Keybuk> so effectively, we read all the blocks for each file in turn, in the order the file was accessed
<Keybuk> opening files at the first point we have a block for that file
<Keybuk> this gives a *very* scattered, random read profile under blktrace
<Keybuk> SSDs like that
<psusi> hrm... well ok... so having defrag pack the files at the start of the disk should help some since you won't have to do any seeking at all, but ureadahead already eliminates any backwards seeking
<psusi> so it won't help a whole lot
<Keybuk> it'll eliminate the seeks
<Keybuk> the seeks are a big part of the loss of throughput
<Keybuk> if we had all the data we want to read, at the start of the disk, contiguously
<Keybuk> we could slam the kernel quickly with it
<Keybuk> and hope the I/O elevator goes "oh, you want the first 100MB, I can do that" *reeeeeeeeeeeeeeeeeeeeeeeead*
<psusi> right, but ureadahead already eliminates any  backwards seeking so you are only left with some forward seeks to slow you down, so there is still some room for improvement, just not a whole lot
<Keybuk> forward seeks are still a lot
<Keybuk> reading data from disk is like shopping with your granny
<Keybuk> sure, it's very helpful keeping her in a straight line
<psusi> hehehe
<psusi> yea
<Keybuk> if she turns around, you're going to be there for weeks
<Keybuk> but you're still going to be spending a lot of your time staring at your feet, wondering how slow it's actually possible for you to walk, and experimenting with games of feet placement
<psusi> it's a shame that there isn't a system call where you could force the kernel to populate the buffer cache with data that you read from a contiguous pack file
<Keybuk> you'd need to know which file it was
<psusi> i.e. rather than just put the block trace info in the pack file, actually copy the needed data pages there, so you can read them all in at once and in order from that file at boot
<Keybuk> which means your pack could go out of date every time the filesystem shifted about a bit
<psusi> even if the files themselves are scattered all over hell and back
<psusi> right... true...
<Keybuk> kernel block cache is mostly along the lines of "N pages at sector X"
<Keybuk> it'd be nice if we didn't have to open() files to readahead() blocks from them
<Keybuk> the kernel team are vaguely playing with that
<mvo> bdmurray: did we get dupes of #369951 in recent history? can you see that with your magic LP superpowers :) ? the empty VarLogDistupgrade200xxx - do we get those on more recent releases like lucid or karmic?
<psusi> would also be nice if you didn't have to block on readahead, then have the disk idle for a split second while you issue the next readahead
<Keybuk> we don't have to block on readahead
<Keybuk> we can use posix_fadvise (WILLNEED)
<Keybuk> but I didn't find that helped any
<psusi> what do you mean we don't have to block on readahead?  it's a blocking call isn't it?
<Keybuk> readahead() is, posix_fadvise() isn't
<psusi> is that actually implemented?
<Keybuk> in kernel, yes
<psusi> ohh.. hrm... wonder how that works
<psusi> ideally you want to keep the disk io queue from being empty ever, which it is for a moment between calls to readahead()
<Keybuk> that we don't have a problem with
<psusi> and I seem to remember something about IO plugging where the disk driver decides to plug up when the queue goes empty, and when the first request comes in from the next readahead(), it waits like 20 ms before servicing it to see if any further requests enter the queue and give the elevator a chance to coalese them
<psusi> why not?
<nxvl> dholbach: ping
<Keybuk> cause we spent a long time staring at blktrace output to make sure we were always getting merges with contiguous blocks
<Keybuk> it's quite cute
<Keybuk> when you read 4K from one file, and 4K from another
<Keybuk> but the blocks are actually contiguous from disk
<Keybuk> the kernel does a single read
<psusi> right...
<Keybuk> and ureadahead on HDD is like IO_PRIO_IVANOVA and CPU_PRIO_GOD
<psusi> but you don't read 4k from the second file until the 4k from the first file has been read
<Keybuk> sure we do
<dholbach> nxvl: pong
<Keybuk> readahead() doesn't seem to actually block :p
<psusi> lol, really?
<psusi> the man page seems to indicate that it does not return until the data is actually in the page cache
<nxvl> dholbach: about GSoC, i'm participating as community member, where should i send the proposal of my idea? To you or write it somewhere in the wiki?
<nxvl> dholbach: and until when do i have to send the proposal
<Keybuk> psusi: pfft, manpages :p
<psusi> but if it just puts the read request in the queue then returns... then yea. that's fantastic
<dholbach> nxvl: can you join #ubuntu-gsoc
<Keybuk> psusi: I didn't see any difference between readahead() and posix_fadvise(WILLNEED)
<psusi> so then it doesn't matter what order the files are in, as long as defrag packs them all at the start of the disk. ureadahead will read them in order... hrm... I gotta try this...
<Keybuk> start or end
<Keybuk> or middle
<psusi> well, start is usually fastests
<Keybuk> or in interesting places somewhere across the sector boundaries
<Keybuk> start's usually around the outside of a cylinder isn't it? :p
<psusi> it's usually wherever the drive is fastest ;)
<psusi> up to the drive to figure that out
<Keybuk> but yeah, sounds good
<apw> Keybuk, i don't think that can be right, there is no way that i edit source, and then it may or may not be in the file if i open it for 5 s
<apw> that is mental semantics
<Keybuk> for added bonus, ureadahead was always intended to be able to output its pack file in a "format ready for defrag"
<Keybuk> apw: reading back, I don't think I am right - I think a crash has to apply between
<Keybuk> I may have confused NFS with reality there
<psusi> well, I stripped the output of --dump down to the bare file names last night... will have to have ls translate that into inode numbers tonight and pass the list to e2defrag and see what happens
<apw> Keybuk, ok phew
<Keybuk> psusi: inode numbers are in the pack file
<Keybuk> would it help if I told you the pack file format? :p
<psusi> lol... no, I'd rather not write any C code if I can do it with some shell ;)
<Keybuk> you can do it with python
<Keybuk> it means you get correct results
<psusi> I don't know python
<Keybuk> or you could tell me what data you actually want, in what order
<Keybuk> and I can knock you up some code in a few minutes ;)
<psusi> well e2defrag just wants a list of inode numbers and you can tag them with a priority
<Keybuk> ok, two secs
<psusi> it then uses that list to alter the standard order it packs the files in, which is normally just inode number order
<Keybuk> psusi: http://people.canonical.com/~scott/inodes.pl
<jpds> Keybuk: 404!
<Keybuk> shouldn't be now
<unggnu> hi all
<Keybuk> I so just thought I saw ubuntulog saying "hi all"
<unggnu> :D
<unggnu> Are there plans to switch from bz2 to lzma for the repository files? Afaik for some packages lzma is already used so it shouldn't be a big deal. I mean the files are downloaded nearly every day and are quite big I think.
<unggnu> Also the decompression should be faster than with bz2. :)
<cjwatson> it's a package-specific decision
<cjwatson> the default remains gz and is likely to stay that way
<unggnu> cjwatson: I don't mean for the packages itself but for the information about the packages.
<cjwatson> oh, ask the launchpad team, not something we control
<unggnu> cjwatson: something like that: http://archive.ubuntu.com/ubuntu/dists/lucid/universe/binary-i386/
<cjwatson> though that said apt might not support it yet
<unggnu> cjwatson: afaik packages like openoffice and similar are already compressed with lzma so dpkg should be able to do it, at least with Lucid and most likely Karmic
<unggnu> I don't know, I just thought it would be great especially for people with slower connections.
<cjwatson> why does that follow?  package decompression and index acquisition is completely different code, and dpkg doesn't do that decompression anyway.
<unggnu> Even with six megabit they take some time.
<unggnu> cjwatson: Ok, but some parts are able to use lzma that's why I thought it shouldn't be a big deal
<cjwatson> unggnu: I didn't say it would be a big deal
 * Keybuk hands cjwatson the "patches welcome" button
<cjwatson> anyway, adding it to the dists tree on archive.ubuntu.com is still something the Launchpad team would need to do
<unggnu> Of course incremental update information would be better but until then :)
<ogra> it is a big deal for arches that already have issues to handle the current uncompressing though
 * ogra points to armel
<unggnu> ogra: afaik lzma decompresses faster than bz2, it only uses more mem
<ogra> unggnu, right, which is a problem on armel :)
<unggnu> But this shouldn't be a problem for ~six MB files
<ogra> its limited in both, CPU and memory
<cjwatson> this conversation belongs in a bug report or something
<unggnu> ogra: they can use bz2 or gz (I suppose there is a reason why the reps are still shipped with gz)
<Caesar> lucas: so can I reassign that bug back to Ruby then?
<unggnu> cjwatson: Would it make sense? I mean it is considerable? That's what I am mainly asking. :)
<unggnu> *possible
<cjwatson> unggnu: I thought I'd answered that.  I don't see why it would be infeasible
<cjwatson> it might not be *straightforward* for reasons you haven't considered, but I don't see why it would be *infeasible*
<unggnu> That's the point why I am asking here :=)
<lucas> Caesar: I think it's still assigned to it
<unggnu> cjwatson: btw. this is/was the blueprint for the packages https://wiki.ubuntu.com/dpkg-lzma
<Caesar> lucas: it is, I'm asking if I should reassign it back to ruby
<cjwatson> unggnu: thanks, I was aware of that
<lucas> Caesar: I meant: it is still assigned to ruby. (ruby-defaults, while it should be ruby1.8). Anyway, it's on my radar, and on my todo list
<Caesar> ok
<doko> Riddell, kees: why is qt4-x11 built with -fno-stack-protector  ?
<nixternal> cjwatson: just got an email about dmb joining cli/mono...did I miss something there?
<cjwatson> nixternal: requested and approved delegation from the technical board
<cjwatson> I'm in the process of setting it up, with the DMB as team admin
<nixternal> gotcha..just wanted to make sure something silly wasn't going on :)
<nixternal> i get spam emails from time-to-time that are similar in nature
<cjwatson> ah, no, this was legit
<nixternal> i got one the other day that said the ubuntu france loco team was now the admin of ubuntu-devel :)
<cjwatson> maybe I'll change it to "uploaders"
<maco> are all the amd64 buildd's broken?
<maco> i just had one package on yellow and one on osmium fail with "chroot problem"
<james_w> what particular problem?
<james_w> ntp?
<maco> james_w: yep
<maco> both systems
<ScottK> maco: lamont is giving back the in archive ones.  You'll have to retry any PPA builds yourself.
<maco> ScottK: ok well im leaving for the airport in an hour, so if amarok in kubuntu experimental fails can you retry it for me?
<maco> (i386 is done)
<ScottK> maco: Link me.
<maco> ScottK: https://edge.launchpad.net/~kubuntu-ppa/+archive/experimental/+build/1558557
<ScottK> Got it.
<maco> ScottK: thanks
<rzr> cjwatson: hi i am reading your email about parted
<rzr> cjwatson: as fatresize maintainer ,  how can I help ? BTW I plan to move it to some team
<rzr> cjwatson: will try to rebuild it this W/E
<rzr> back
<Roblob> why are the menus on the left?
<rzr> cjwatson: i applied to parted debian team
<Keybuk> Roblob: because Ubuntu comes from the UK
<Keybuk> if it came from Europe or the US, they'd be on the right
<vish> lol
<Keybuk> it's a bit like driving an import
<maco> Keybuk: :P
<Roblob> Keybuk, doesnt ubuntu come from ZA? South Africa?
<maco> Roblob: canonical is based in london
<maco> Roblob: though mark originally comes from ZA
<zyga> manjo: ping
<zyga> marjo: ping
<zyga> (sorry manjo)
<cjwatson> rzr: I'll send you a reference to the patch - it's fairly straightforward
<kees> doko: I don't know -- I find that highly upsetting.
<kees> doko: anything with such exceptions is supposed to be listed here: https://wiki.ubuntu.com/CompilerFlags#Problems
<jdong> hmmm do we have a procedure for archive removals (completely), like what we did with sun-java*?
<jdong> the upstream Sagemath guys are pretty irate about our packages
<yannick> hey guys how can i get kdelibs >= 4.4. ?
<jdong> debian bug 573538
<ubottu> Debian bug 573538 in sagemath "Please remove the sagemath package" [Grave,Open] http://bugs.debian.org/573538
<ScottK> I think there's already a removal bug for sagemath.
<sebner> doko: MOTU-MONO hasn't been active for years anyways but would it be a good idea to close it as we now finally have our cli-package-set?
<ScottK> jdong: sagemath is already removed from Lucid.
<jdong> ScottK: can we backpropagate that removal to Karmic?
<ScottK> Not a lot we can do about stuff that's already released.
<cjwatson> jdong: no, sorry
<jdong> *nods*
<jdong> ok, I'll let the Debian maintainer know.
<Chipzz> sigh
<Chipzz> that looks like a very poor way of handling things
<Chipzz> (on account of upstream)
<Chipzz> they should have worked with the debian maintainer to get a more recent version included, or have the bugs fixed
<Chipzz> but encouraging users to compile it themselves... where did I leave my cluebat? :P
<jdong> with regards to sagemath, if in the future a proper package shows up, would it be okay to send it through the SRU process to karmic-updates?
<zyga> mvo: hi!
<zyga> mvo: how are you? I heard you are ill
<james_w> jdong: worth a go if there is a significant improvement IMO. No-one's going to pre-approve an unseen package though.
<mvo> hey zyga - indeed, good to see you! how are you doing?
<jdong> james_w: oh definitely. Just making sure there's no *SLAP* BAD JDONG CRACK initial reaction to the idea :)
<Chipzz> reading the discussion further... shipping forked copies of other libraries... another facepalm :P
<mvo> zyga: I'm much better now, I was sick with a stomach bug, but I'm much better now
<cjwatson> Riddell: is bug 538231 the same as bug 538142?
<ubottu> Launchpad bug 538231 in ubiquity "[Lucid]Ubiquity appears to crash in Kubuntu Live CD environment but then runs successfully after error dialogs closed." [Undecided,New] https://launchpad.net/bugs/538231
<ubottu> Launchpad bug 538142 in ubiquity "kconfig permissions errors starting kubuntu ubiquity" [Undecided,New] https://launchpad.net/bugs/538142
<zyga> mvo: I released c-n-f 0.2.41
<zyga> a minor update since previous ubuntu package
<mvo> zyga: sweet, does it fix bug #507760?
<ubottu> Launchpad bug 507760 in command-not-found "c-n-f does not suggest commands with numbers ('bzip' does not suggest 'bzip2')" [Low,Fix released] https://launchpad.net/bugs/507760
<mvo> zyga: it appears it does \o/
<mvo> zyga: I sposnor it tonight!
<zyga> mvo: thanks
<zyga> mvo: I'll make a few more releases with less critical fixes
<zyga> mvo: but this one is targeted for lucid
<mvo> zyga: excellent, much appreciated
<mvo> zyga: keep me updated at irc, I will immediately sponsor
<zyga> mvo: thanks! :-)
<mvo> well, thank *you* :)
<zyga> that's all from me, I'm going back to coding
<mvo> happy hacking
 * mvo will also do a data-updated while at it
<zyga> oh
<zyga> that reminds me
<zyga> where can I find scan.data?
<zyga> I found one in ubuntu source package
<zyga> mvo: https://edge.launchpad.net/~zkrynicki/+archive/command-not-found (PPA with release)
<mvo> zyga: http://people.canonical.com/~mvo/command-not-found/
<mvo> zyga: I assume you have the code in a bzr branch as well?
<mvo> ready for merging
<zyga> mvo: yes
<zyga> mvo: it's in lp:command-not-found
<zyga> trunk
<zyga> mvo: there are +3 new strings I think, I don't know if that's a problem
<zyga> if so I can work around that by removing some features
<zyga> mvo: I was going to ask about #533031
<GheRivero> hi everyone
<zyga> bug #533031
<ubottu> Launchpad bug 533031 in command-not-found "command-not-found fails to work on ports architectures" [Low,Triaged] https://launchpad.net/bugs/533031
<mvo> zyga: its a bit of a problem because we are in UI (string) freeze, but we can mail the translators list if its important
 * hyperair wonders if jdstrand is around.
<mvo> zyga: port> oh, right. its currently not crawling those as the server I run it on has only the normal archive mirrored
<zyga> mvo: it's not critical, if you want I can work on that to remove the requirement
<mvo> zyga: I have a look and let you know
<zyga> thanks
<zyga> mvo: I integrated ubuntu translations into trunk so hopefully we can have a better state of translations the next time, translations can happen upstream for a change
<nxvl> bryceh: ping
<lucas> pitti: can you clarify why you switched ruby1.8 to libreadline-dev instead of libreadline5-dev? according to #553843 it is a license violation
<lucas> pitti: ruby1.8 is "ruby license or GPLv2". readline6 is GPLv3
<Keybuk> lucas: ruby doesn't appear to specify which GPL version, actually
<Keybuk> it just says "the terms of the GPL"
<lucas> Keybuk: next line
<lucas> :-)
<Keybuk> what next line?
<lucas> in COPYING?
<micahg> lucas: I think the plan was to drop libreadline5-dev from Lucid
<Keybuk> I was reading debian/copyright
<lucas> never trust the debian maintainer
<Keybuk> lucas: I'm quoting you on that next time I follow one of your talks at a conference ;-)
<Keybuk> though that being said
<Keybuk> COPYING was changed years after debian/copyright was written
<lucas>     * COPYING: explicitly note GPLv2.  [ruby-talk:187922]
<lucas> Date:   Sun Apr 9 16:10:40 2006 +0000
<Keybuk> right, and debian/copyright was written 2003!
<Keybuk> but yes, I agree with you
<Keybuk> ruby1.8 is GPLv2 only
<Keybuk> so cannot link with GPLv3 code, or LGPLv3 code
<lucas> there's another, more serious problem with ruby1.8, actually. we link to openssl, so we basically choose the ruby license, not the GPLv2 one. and then we link to readline5 (in Debian), which is GPLv2 or later
<Keybuk> does that problem exist in Debian too? :p
<lucas> Keybuk: yes
<lucas> Keybuk: (I'm one of the maintainers)
<Keybuk> hmm, just checking
<Keybuk> doesn't only libopenssl-ruby1.8 end up linked with libopenssl?
<Keybuk> and doesn't get linked to readline?
<Keybuk> that's not _technically_ in violation then <g>
<lucas> that's correct
<slangasek> technical violations are the only ones that matter ;)
<Keybuk> each binary package is individually redistributable without breaking licence
<Keybuk> so they can be distributed together too
<Keybuk> (aggregate argument)
<lucas> mmh, what happens if a ruby app uses both the openssl and readline libraries?
<Keybuk> except for the libreadline6 link, obviously - that's a definite violation
<cjwatson> is it possible to use libedit?
<Keybuk> lucas: emacs and python argument => scripting languages can load plugins that are otherwise licence contradictory
<cjwatson> it's not quite as good, but the *point* of readline being GPL is that the good stuff is restricted to GPLed programs :)
<zyga> Keybuk: o_O ?
<zyga> Keybuk: can you expand that statement, it's quite interesting
<Keybuk> zyga: it's the FSF's position
<Keybuk> go look it up on fsf.org ;)
<zyga> mmm, I will
<lucas> ok, then we are fine, and just need to revert the ubuntu-specific change
<zyga> (so a scripting language inside the kernel... ;-)
<slangasek> Keybuk: I don't think that argument holds water if the ruby app is in our archive
<cjwatson> lucas: this is still a problem, though, we don't want multiple readline versions in main if we can avoid it
<lucas> I'll request a sync of the debian version, which also fixes the ruby+threads+timeout/puppet bug
<cjwatson> and indeed libreadline5 is currently in universe, although presumably that's only once pitti rebuilt ruby against libreadline6
<lucas> cjwatson: I don't see a way to avoid it, except dropping readline support in ruby. you don't want to do that, because all ruby developers use irb, which uses readline AFAIK
<cjwatson> lucas: 20:55 <cjwatson> is it possible to use libedit?
<cjwatson> it has a readline wrapper, and it's BSD-licensed
<cjwatson> as I say, it's not quite as good, but it's not that bad either
<siretart`> while discussing this subject, there is popular request to compile ffmpeg against opencore-amr. however, since the latter uses apache license, this would require us to distribute libavcodec under GPLv3. My conclusion is that this would cause problems for ubuntu. Is that right?
<lucas> cjwatson: it's a drop-in replacement?
<cjwatson> to some extent
<lucas> :-)
<cjwatson> it has a wrapper which attempts to emulate at least a decent chunk of the readline API
<cjwatson> I'm not saying it will definitely meet your needs, but it's possible that it might get you out of a hole so it seems worth a look
<lucas> that might be a long term solution, but I don't see this happening before the lucid release (especially if I'm the one doing it)
<cjwatson> for lucid, it does seem like going back to readline5, biting our tongues, and accepting two readline versions in main is what it'll have to be
<cjwatson> at least it isn't on the CD
<cjwatson> pitti: ^-
<siretart`> to make matters more complicated, would enabling opencore-amr for the ffmpeg-extra package acceptable? We could then advice users of GPLv2 applications to avoid the ffmpeg-extra package...
<mvo> zyga: could you add in the debian/changelog what bugs are fixed with the release please?
<zyga> mvo: such as the stuff listed in the release notes for this version on launchpad? (I'm searching for a link)
<zyga> https://launchpad.net/command-not-found/trunk/0.2.41
<zyga> shall I add that stuff to the changelog below '* new upstream release' ?
<mvo> zyga: yes, exactly this :) just below new upstream version is fine. and please include the bugnubmers as LP: #bugnr - then they will get auto closed on upload
<zyga> okay just a moment
<mvo> sure
<zyga> I branched from tag 0.2.41ubuntu1
 * zyga is pleased to see vim is aware of LP: #[0-9]+
<zyga> mvo: shall I bump version to ubuntu2?
<mvo> zyga: its not uploaded yet, so we can keep ubuntu1
<zyga> k
<mvo> zyga: you could also use a NEWS file (that would be more upstreamish) and I copy the content into debian/changelog when making releases. but both is fine really
<zyga> mvo https://code.launchpad.net/~zkrynicki/command-not-found/lucid
<zyga> mvo: I'll keep the NEWS file up-to-date since .42 :-)
<zyga> this branch can be used for lucid if we need to cut strings and patch other stuff
<mvo> zyga: if we can avoid the new strings somehow that would be nice, at least for the beta-1 upload, we need a UI freeze exception for new strings at this point
<mvo> zyga: thanks for the changelog, that looks good now :)
<ccheney> anyone here familiar with gtk?
<zyga> mvo: I'll can revert features that add new strings but this will make version ackward
<ccheney> i am having a problem linking to it
<ccheney> http://pastebin.ubuntu.com/394262/
<zyga> mvo: basically new strings are for auto-install feature
<ccheney> during the epiphany browser backport for hardy
<mvo> zyga: ok, I think we have two option a) file UI freeze exception (should be ok, just one string) and upload on monday b) create lucid branch 2.40ubuntu2 that cheery picks all but the string
<zyga> mvo: pick the one you like, I'm fine with either since it's my fault it is soo late again
<mvo> zyga: I would say b) for now, then I can upload tonight :) otherwise a) is fine as well
<zyga> hmmm, a) would mean less messing with the history, I'll try to fix all the issues in the next few days so that once lucid+1 is around this will not happen again
<mvo> zyga: yeah, I like a) better too, https://wiki.ubuntu.com/FreezeExceptionProcess has the details (if its ok for you to write the exception)
<zyga> okay I'm on it
<zyga> #UserInterfaceFreeze Exceptions ?
<zyga> or new upstream release?
<zyga> okay so I'm filing a new bug on /ubuntu/+source/command-not-found about FreezeExceptionProcess
<RoAkSoAx> jcastro, does the summit sponsorship website still has the bug showing a blank page when finishing requesting the sponsorship?
<jcastro> RoAkSoAx: yep, pm me your lp username and I can make sure it's in there
 * jcastro likes to doublecheck
<RoAkSoAx> jcastro, done :)
<mvo> zyga: yes, and please subscribe ubuntu-release when the bug is there
<mvo> zyga: thanks .)
<mvo> zyga: I'm off to bed now!
<zyga> mvo: thanks, bye!
<jpds> Keybuk: bug #538292 just came up.
<ubottu> Launchpad bug 538292 in plymouth "Latest plymouth update makes lucid stop at startup" [Undecided,New] https://launchpad.net/bugs/538292
<chrisccoulson> heh, i just saw people talking about that in #ubuntu+1 too
<Keybuk> jpds: it works for me
<Keybuk> oh, that
<Keybuk> *shrug*
<Keybuk> they need to update mountall too
<chrisccoulson> Keybuk - i'm not sure that's published yet
<jpds> chrisccoulson: It is.
<Keybuk> well, people shouldn't be so eager on the update button, should they <g>
<chrisccoulson> yeah, probably ;)
<chrisccoulson> jpds - there's no 2.8 in the archive yet: http://archive.ubuntu.com/ubuntu/pool/main/m/mountall/
<cjwatson> discussion in #ubuntu-release indicated that we were going to have new libplymouth2 Breaks: old mountall, but I don't see that in the package?
<jpds> chrisccoulson: Oh, the source is published, right.
<Keybuk> cjwatson: one had to be built before the other
<Keybuk> or the chroots would have removed upstart
<Keybuk> and killed themselves
<cjwatson> oh, I see we're waiting for mountall before going round with the Breaks, for reasons I didn't follow but you and slangasek seemed to be on top of it
<cjwatson> right, I didn't attach that to missing Breaks the first time
<slangasek> jpds: just replied to bug #538292 with explanation, sorry
<ubottu> Launchpad bug 538292 in plymouth "Latest plymouth update makes lucid stop at startup" [Undecided,Fix released] https://launchpad.net/bugs/538292
<slangasek> cjwatson: you're a buildd admin?
<slangasek> mountall/{ia64,sparc} need rescored
<slangasek> once they start building, I can accept the fixed plymouth
<slangasek> and it would be nice if that happens sooner than 7h from now
<cjwatson> slangasek: yup, sec
<cjwatson> I've taken the precaution of putting the publisher on manual
<cjwatson> slangasek: both scored up, but I can't do anything about the existing builds running on ia64
<cjwatson> so it's still nearly an hour away
<jpds> cjwatson: amd64 was about to be published and i386 binaries are on the archive.
<cjwatson> yeah, I've taken it off manual again since there's no benefit with ia64 an hour out
<cjwatson> jpds: but that wasn't what the precaution was for - if the ia64/sparc builds were going to arrive quickly, I could have got them published faster with the publisher on manual
<slangasek> oh pah, we got stuck behind eucalyptus and openjdk?
<cjwatson> slangasek: if you're truly desperate, I think lamont can kill jobs
 * Caesar discovers mountall and throws up in his mouth a bit
<slangasek> cjwatson: if the builds were still at the unpack phase I might worry about dpkg+fsync and the accuracy of the estimate... I think we might as well let this run its course now
<Caesar> Wow, this mountall thing is a total black box
<wgrant> The LP estimate is solely based on the previous build times.
<sistpoty> fta: the name of the binary packages are left to your discretion for bug #537617, just if that was not clear from my comment. Do you have any ETA for landing it in lucid?
<ubottu> Launchpad bug 537617 in chromium-browser "[FFe] chromium-codecs-ffmpeg for lucid" [Undecided,New] https://launchpad.net/bugs/537617
<slangasek> wgrant: yep - but eucalyptus is already at least halfway done now
* slangasek changed the topic of #ubuntu-devel to: don't reboot with libplymouth2 0.8.0~-13 without mountall 2.8! | Archive: Feature Freeze + Beta Freeze | MoM running (but use bzr!) | 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.
* slangasek changed the topic of #ubuntu-devel to: don't reboot with libplymouth2 0.8.0~-13 without mountall 2.8! | 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
<slangasek> mountall publishing
<slangasek> cjwatson: and plymouth accepted again, could use rescoring on ia64/sparc
<cjwatson> slangasek: dodne
<cjwatson> *done
<slangasek> cheers
<cjwatson> should be quicker this time
<cjwatson> slangasek: they're taking their time about it.  should I put the publisher in manual in the hope of getting all architectures into this hour, or would you rather get i386 in ASAP?
<cjwatson> (amd64 is waiting as well, or I would just assume the latter)
#ubuntu-devel 2010-03-13
<slangasek> cjwatson: well, at least we now have a mountall+plymouth publishing that *work* together, so users won't wind up with breakage after a normal dist-upgrade
<peitschie> hello everyone :)
<cjwatson> slangasek: ah yes, ok
<slangasek> so I'm less worried about timing of the Breaks: arriving
<cjwatson> I'll leave the publisher alone then
<slangasek> my current manual run is going to clip the next scheduled run, regardless :)
<peitschie> i was wondering if anyone knows who is best to talk to about getting a patch into the python launchpad integration source?
<ScottK> File a bug and attach the patch.
<peitschie> ScottK: I've done that about a week ago already :)   just seeing if there was a way I could get it looked at any sooner :)
<ScottK> If you can make it into a debdiff ready for upload then you can subscribe ubuntu-main-sponsors.
<slangasek> Keybuk: I wonder - shouldn't the mountall failure due to missing libs have triggered mountall-shell.conf?
<peitschie> ScottK: I'll look into that :).  Thanks heaps :)
<Keybuk> slangasek: no, because mountall never ran
<Keybuk> I assume it was an exec() failure rather than an exit code?
<slangasek> hmm, does that get reported as an exec() failure?
<Keybuk> yes
<slangasek> ok
<Keybuk> upstart holds a close-on-exec fd open to its children
<Keybuk> if it closes, then the exec succeeded
 * slangasek nods
<Keybuk> if it gets data, then the exec failed and the data is the errno
<Keybuk> so it can distinguish between child failure and the actual processes own exit codes
<slangasek> right, all part of upstart's "No Child Left Behind" policy
<robbiew> Keybuk: slangasek: what if someone did? how can they fix that?
<robbiew> re: mountall/libplymouth2
<slangasek> robbiew: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/538292/comments/3
<ubottu> Launchpad bug 538292 in plymouth "Latest plymouth update makes lucid stop at startup" [Critical,Fix committed]
<Keybuk> slangasek: well, more as part of Upstart's "I look after my children, and looking after my children includes killing them myself" policy
<slangasek> Keybuk: I prefer my allusions to the Bush Administration's education policies
<robbiew> slangasek: ack
<Keybuk> slangasek: I don't know anything about that
<Keybuk> but I'm good at mass-murder
 * cjwatson finds the blkid hang
<slangasek> afk for a few
<Nafallo> heh. doesn't seem like I need to report the mountall can't find libplybootclient.so.2 then? ;-)
<jdong> hahaha
<nixternal> slangasek: note that the fix you listed in the bug report is only good for i386 users right now
<Nafallo> oh well. was a nice exercise :-)
<Nafallo> long time since I had to break into my initramfs ;-)
<crimsun> nixternal: it's good for amd64, too.
 * directhex is scared to shut down & go to sleep
<jpds> directhex: Nah, updates are on the archive.
<directhex> which version is doom?
<directhex> "the" archive != mirror.ox
<slangasek> directhex: the one in the topic
<directhex> oh, topic. fancy
<jpds> directhex: That mirror going to become a push mirror in future I believe. ;)
<directhex> 0.8.0~-12 is safe?
<slangasek> yes
<slangasek> and 0.8.0~-14 is safe
<directhex> i can sleep then. woo!
 * Nafallo upgrades mountall and reverts his copied lib :-)
 * sistpoty wishes he could upgrade to a new bios containing a sane mac after some flashrom accident :P
<nixternal> crimsun: no amd64 here yet for mountall 2.8
<jpds> nixternal: Which mirror?
<nixternal> figures, as soon as I say that amd64 is there :)
<kees> Keybuk: do you have knowledge about default readahead values for devices?  is 256 right?
<Keybuk> no
<Keybuk> 128 KB
<kees> 256 * 512 == 128KB, so yes
<kees> I have seen raw performance graphs that imply 4096 is the right block readahead, but that seems like a lot
<Keybuk> probably depends wildly on the disk
 * kees nods
<kees> mathiaz: who does server install testing?  I'm curious about 525425 -- would be nice to get it fixed for this beta.
<mathiaz> bug 525425
<ubottu> Launchpad bug 525425 in grub2 "lucid server/alternate, software raid 1 will not install correctly; unbootable after failed grub install" [High,Confirmed] https://launchpad.net/bugs/525425
<kees> mathiaz: and I know kirkland has a lot on his plate at the moment, so I'm trying to find someone with cycles.  :)
 * mathiaz tries to remember last time he had free cycles....
<kees> heh
<mathiaz> kees: well - I don't really know what I can do on this one
<mathiaz> kees: yes it's a bug
<mathiaz> kees: I'm not sure *I* will have time to look into it
 * kees nods
<kees> yeah.  I just wanted to make sure it stays on the radar.  It seems like a high priority issue -- the server ISO is uninstallable for a majority of users (who installs a server without raid?)
<mathiaz> kees: cloud instances? vms?
<cjwatson> I've put it on my list for Monday
<mathiaz> kees: but yes - I agree
<kees> cjwatson: ah! okay
<mathiaz> kees: RAID is an important use case
<bryceh> kees, hey question on maintaining project packaging using bzr if you're around
<cjwatson> unless somebody else can do it faster, but given it's Monday and nobody else really knows grub2?
<kees> bryceh: I may be the wrong person, but go ahead.  :)
<bryceh> kees, I've got an upstream project foo, and I want to maintain its debian packaging stuff in bzr
<cjwatson> s/Monday/Friday/ argh
<bryceh> so like have trunk be an import of foo, and branch that to add debian/ and such atop
 * kees nods
<bryceh> should I register foo as a project in launchpad, and then upload its code to that project's bzr?
<kees> bryceh: that's how apparmor's bzr branches are done
<bryceh> or is there a better way to do it that doesn't require creating a project?
<Keybuk> bryceh: if you upload, james_w's importer will make a lp:ubuntu/foo branch for it
<Keybuk> then just push --overwrite your own branch over the top
<Keybuk> then use that
<kees> bryceh: what Keybuk said or create a project, those are the only two I've ever done.
<cjwatson> creating a project: it depends how much of an independent existence you want the upstream to have
<mathiaz> bryceh: is your project already packaged in ubuntu?
<Nafallo> kees: job-1 installed servers without raid... they used the second hard drive to do rsync backups in cron.daily...
<bryceh> mathiaz, no I'm doing the packaging for it from scratch
<cjwatson> logically, upstream => project, even though it isn't always worth bothering
<bryceh> mathiaz, it's an existing upstream project by a university, hosted in a random git repo somewhere
<bryceh> cjwatson, ok
<slangasek> is the git repo public?
<slangasek> if so, I have a nice recipe that I'm in the process of refining for bzr git-import + bzr-builddeb
<cjwatson> or you can use launchpad's automatic git imports
<mathiaz> slangasek: ^^ I was about to ask about that
<bryceh> slangasek, I don't think it is accessible publically; I think they have an application to get one from fdo though
<slangasek> (git-import -> launchpad project; otherwise, you can import *just* the master branch and go the lp:ubuntu/$pkg route)
<slangasek> cjwatson: does launchpad do full-repo imports?
<cjwatson> just master, I think
<slangasek> right
<bryceh> ok, I'll make a lp project and shove it in there
<cjwatson> though, well, I think you can do multiple imports if they're different series
<cjwatson> e.g. grub
<slangasek> bryceh: http://www.advogato.org/person/robertc/diary/130.html for lifeless's howto for initial Debianization w/ builddeb
<bryceh> slangasek, sweet thanks
<slangasek> bryceh: N.B.: when he says 'bzr revert', he actually means "rm -rf debian" :)
<bryceh> slangasek, that makes more sense, I was about to ??
<bryceh> any conventions for naming of the packaging branch?  'packaging'?  'debian'? 'ubuntu'?
<Keybuk> slangasek: what a wonderful command
<slangasek> bryceh: well, when you push it to LP, it'll be called "lucid"
<bryceh> ok, wfm
<bryceh> presto, it lives: https://code.edge.launchpad.net/multitouchd
<slangasek> here we go, testing update-manager's upgrading of plymouth+mountall
<slangasek> success, good
<psusi> jesus, I got my SSD today and had lvm migrate the root over to it, then I rebooted... 5 seconds to initial X startup, which then crashes and has to be restarted, hehe... guess it's too fast.. must be a race condition somewhere...
<slangasek> psusi: what version of plymouth?
<psusi> what IS this plymouth thing everyone is talking about?  looks like... ohh, boot graphic eh?  version 0.8.0~-13
<bryceh> next question with maintaining packaging in bzr...  I would like to just apply changes directly, and not use quilt and debian/patches/* stuff.  Am I insane for wanting to do it this way?  Should I stick with quilt?
<Keybuk> nvidia card?
<psusi> ati
<Keybuk> bryceh: I do it that way
<psusi> 4850 hd
<Keybuk> psusi: do you see a graphical logo or "Ubuntu 10.04" ?
<psusi> no... tty7 looks like it switches modes, but just sits there with a blinking text cursor in the top left and a mouse cursor in the middle of the screen
<slangasek> bryceh: not insane; I would recommend a separate topic branch for each logical upstream change, + an integration branch, though I don't know any recipes for this yet
<slangasek> psusi: at boot time, which do you see: a graphical logo, or "Ubuntu 10.04"?
<psusi> logs show gnome session is up at 5 seconds into the boot, then crashes, and gets respawned on tty8
<slangasek> bryceh: (bzr looms might also be relevant here)
<bryceh> slangasek, ok
<psusi> slangasek, neither
<bryceh> slangasek, probably overkill for this project but noted.
<slangasek> bryceh: overkill> that just makes this a good project to practice it on :)
<bryceh> true :-)
<slangasek> psusi: interesting
<psusi> log says the X server gets a SIGQUIT
<psusi> and it dumps a stack trace
<slangasek> psusi: gdm, kdm, or xdm?
<Keybuk> psusi: err, you're *sure* you have -13 there/
<psusi> after it has initalized everything by the looks of it
<psusi> gdm
<psusi> ohh, no... it's ~12
<slangasek> ah, heh
<Keybuk> thanks
<Keybuk> because what nearly happened there was that I nearly gave up entirely
<Keybuk> broke down
<slangasek> yeah, upgrade to -14 :)
<Keybuk> and got carried away by men in white coats
<psusi> lol, so I guess I'll try updating and see what happens
<Keybuk> screaming "BUT I CHANGED ALMOST EVER LINE OF CODE IN THE TRANSITION!!!!  HOW CAN IT STILL DO THAT?"
<psusi> or maybe I just disable it... don't really need a boot progress screen when you're able to login after 5 seconds ;)
<slangasek> "disable it" - not supported, not an option
<Keybuk> psusi: you need plymouth to deal with the cases where the boot doesn't progress
<psusi> ohh?
<Keybuk> otherwise the first time you have filesystem issues, you'll be up fuck alley without any lube
<psusi> how so?
<slangasek> plymouth isn't "splash screen pretty"; it's "boot-time I/O arbitration"
<Keybuk> "hai psusi, bit of problem with your filesystem, want me to try fixing it?"
<Keybuk> type questions
<psusi> I don't need that ;)
 * ScottK considers the BOFH archives.
<slangasek> Keybuk: apparently he's not a fan of lube
<Keybuk> psusi: I will remember you saying this when you're in here weeping that you lost your root filesystem
<Keybuk> and I will laugh
<Keybuk> like this
<Keybuk> BWAHAHAHAHA
<Keybuk> ;-)
<psusi> when I got a problem with my filesystem, I don't want anything trying to automagically jigger with it... I'll boot to single user mode or just the initramfs and diagnose and repair from there ;)
<psusi> I've had to do that plenty of times over the years because of my dmraid... when I first got this computer and tried Ubuntu I spend 3 weeks trying to get it to recognize the raid and install and boot up, hehe... had to hex edit partition tables and such a few times
<psusi> that was what?  breezy?
 * ScottK is really reminded of the BOFH archives.
<psusi> hehe... "I need more disk space, I only have 10 megs quota, and it's used up"
<psusi> "there you go, you now have 10 megs free"
<psusi> "oh wow, 10 megs used, 10 megs free, 20 meg quote... nice!"
<psusi> "no, you just have 10 megs free".
<bryceh> "let me help you with your bandwidth next..."
<psusi> hehehe
<psusi> now I still need to figure out why grub is still using the config file on the old hd even though I reinstalled it on the ssd and set the bios to boot from it...
 * ScottK was thinking more about the ones where the end user claimed to know better, but whatever.
<psusi> wow... bootchart stops at 15 seconds now... 7 seconds of that looks like it was the time it took me to type my password and log in... heh.
<psusi> so... what else does plymouth do other than pretty boot candy?
<psusi> ohh, it DOES have a man page
<Keybuk> heh, the manpage is probably all wrong
<psusi> I must say, migrating the root filesystem of the running system over to the new disk on the fly was pretty cool... though the Logical Volume Manager gui locked up during the process... now if only I could have hot plugged the drive.... hrm...
<psusi> I'm still surprised that lvm worked on top of dmraid these days
<psusi> yea, the man page just describes plymouth-set-default
<walters> Keybuk: while you're around, can you fix the FAQ for "Will Upstart replace D-Bus?"; you say "The mechanism for doing this is to send a nonsense message to the service, so D-Bus starts the service (in theory to handle your message).", but actually you can just call StartServiceByName if you want to start a service by side effect
<walters> Keybuk: also, is there a way in upstart right now to do something on inotify watches?
<walters> Keybuk: we also tossed around the idea of having it handle ACPI events like shutdown, rather than having acpid
<Keybuk> there isn't a way right _now_, but there will be
<walters> that's for the inotify question?
<Keybuk> for both
<walters> ah, great
<walters> it came out that X used to listen for ACPI events, but no longer does
<Keybuk> are there many interesting ones left?
<walters> i don't think so but haven't checked
<Keybuk> the probable pattern is you'd have something connect to the socket, and make upstart events for them
<Keybuk> where we have acpi-support now
<psusi> I thought I heard we got rid of hald?
<Keybuk> for most things
<slangasek> there are a handful of ACPI events still not handled as input-events - ac adapter, battery, power button, I think
<psusi> hrm... I'm getting unreleased mem pools running update-grub... looks like os-prober
<Keybuk> probably because you haven't got plymouth
<psusi> I do
<psusi> ohh, THAT logo... ;)
<Keybuk> which ?
 * Keybuk makes a psusi logo out of the font
<psusi> ohh, the ubuntu logo from plymouth
<Keybuk> right
<psusi> wow... I got lm-sensors fancontrol to stop the fans because the cpu is cool, and told hdparm to spin down the hard drives... that's some peace and quiet... though I still can't get grub to load the .cfg from the ssd automatically ( it still goes to the hd and I have to tell it to switch )
<yannick> hello :-) how can i upload a file from my pc to my server?
<persia> yannick: I strongly suspect that you would do better to ask that question in #ubuntu
<ccheney> persia: heh :)
<ccheney> asking any question devel related or not at this time of day on a fri/sat won't get much response
<persia> Well, most days.  I happened to be sick this morning, so cancelled my other plans and am around.
<persia> I suspect that for most classes of interesting developer question, statistically someone would be around at this hour most weeks.
<ccheney> ah
<persia> But lots of questions on this channel remain unanswered anyway, as there are few people who know the answers.
<ccheney> i figured at Sat 6:20 UTC people would either be asleep or out at a bar
<ccheney> except for eastern europe and asia of course
<persia> You forget this side of the world, where one has to be farily dedicated to head to a bar at this hour.
<ccheney> not a lot of those people in this channel though afaik :)
<persia> Yeah, well.  I suspect there's some correspondance between the common assumption that there aren't any and that there aren't any.
<ccheney> persia: 3pm is a great time to go to a bar :)
<persia> Plus, you forget antipodeans (although I suspect it's a good time for the pub there anyway)
<persia> If you're dedicated, sure :)
 * persia goes back to trying to saturate the links to the DC
<ccheney> i thought antipodean's were classified as being part of asia
<persia> Different crustal plate.
<ccheney> ah ok
<ccheney> i think i got confused by thinking autralasia was just more specific for asia, heh :)
<ccheney> its actually appears to be the area southeast of asia
<ccheney> s/its/it/
<slangasek> I think it's sad that we label these people because of their opposition to iPods
<wgrant> We all keep a box of crushed iPods with us at all times to show our true alignment.
<ccheney> heh :)
<pitti> lucas: hm, I read it as "ruby is GPL or ruby license" and readline is "GPL", so that seemed fine; ruby's copyright file does not restrict the version of the GPL
<pitti> ah, I see that was extensively discussed
<persia> "GPL" is unfortunately losing independent semantic value with increasing use of "GPLv2" and "GPLv3"
<pitti> cjwatson: yeah, seems to be (yay license stupidity); I only looked at debian/copyright, sorry
<sivang> hi all
<lucas> pitti: I fixed debian/copyright in pkg-ruby's svn ;)
<pitti> lucas: thanks
<sebner> pitti: is it safe to upgrade to latest udisks (does not happen automatically here) and remove devkit-disks?
<pitti> sebner: the udisks upgrade doesn't work because of a libparted problem; yes, it's safe to updated
<sebner> great :)
<kees> Keybuk: so... how exactly did we go from 18.43s to 10.43s?
<sebner> kees: that's certainly black evil magic!
<kees> yeaaaa.
<cjwatson> kees: see -release from this morning; something to do with a bug causing the switch to vt7 to happen, and compiz is insanely faster at doing its drawing offscreen
<cjwatson> er.  NOT to happen
<kees> "off screen"? oh, you mean since it's drawing X on vt1 while we're looking at vt7?
 * kees goes to read
<crimsun> hmm, is -release not logged?
<cjwatson> other way round, drawing X on vt7 while we're looking at vt1, I think
<cjwatson> this is second-hand though
<kees> this cements my opinion that compiz is to blame for everything.  ;)
<ScottK> crimsun: It's not.  I have pretty complete logs though if you need someting.
<ScottK> ting/thing
<crimsun> ScottK: was just interested in the discussion above to which colin referred
<ScottK> crimsun: http://paste.debian.net/63969/ is I think it.
<cjwatson> yup, that's what I meant.
<crimsun> ScottK: thanks
<danyR> hi there. has anyone read about possibly steam coming to linux?
<YokoZar> Anyone else getting "unable to connect to crash database" with ubuntu-bug ?  It's been broken for a couple days for me now.
<geser> bug 538097
<ubottu> Launchpad bug 538097 in launchpad "Apport cannot connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/538097
<jarlath> I'd like to contribute to the bug-triaging effort. Are there any low-hanging-fruit, like following up on old and inactive reports to see if they can be closed?
<jpds> jarlath: The BugSquad might be able to help you out, try #ubuntu-bugs.
<jarlath> ah yes. Thanks jpds
#ubuntu-devel 2010-03-14
<rickspencer3> YokoZar, hey man
<LaserJock> rickspencer3: you sure you want social-from-the-start? ;-)
<rickspencer3> LaserJock, ?
<LaserJock> rickspencer3: the "fun" on identi.ca's !ubuntu
<LaserJock> it's so depressing some days to watch that group
<rickspencer3> LaserJock, yeah
<rickspencer3> I should have just started blocking instead of speaking up
<rickspencer3> but if you let certain things go unchallenged, people think certain behavior is ok
<LaserJock> yeah, it's tough to know what to do
<LaserJock> much *more* difficult for Canonical people as well, since that often plays into the dynamic
<rickspencer3> LaserJock, yes, I fed the troll
<rickspencer3> but I don't just work for Canonical, I consider myself part of the community
<rickspencer3> since that predates me getting the job by a matter of some years
<rickspencer3> oh well
 * rickspencer3 moves on
<nigelb> speaking of which, it would be nice to have a list of admins for that group
<nigelb> (to ping when spam
<rickspencer3> nigelb, yeah
<rickspencer3> I guess the ucoc doesn't extend to that group though
<nigelb> well, it extends to all ubuntu members who've signed the coc who're there
<rickspencer3> nigelb, good point
<nigelb> just like bugs
<ScottK> nigelb: I don't think it does.
<rickspencer3> speaking of which, I wanted to congratulate YokoZar on a well written critique
<rickspencer3> that will have more impact than any amount of trolling in !ubuntu
<nigelb> ScottK: "This Code of Conduct covers our behaviour as members of the Ubuntu Community, in any forum, mailing list, wiki, web site, IRC channel, install-fest, public meeting or private correspondence."
<ScottK> nigelb: Identi.ca isn't part of Ubuntu.
<LaserJock> rickspencer3: I love that I'm immune to button placement controversies since I run UNE ;-)
<rickspencer3> LaserJock, oh?
<rickspencer3> I use UNE on my desktop actually, and I run the new themes
<ScottK> LaserJock: They just didn't get to you yet.
<nigelb> ScottK: I thought the coc applied to those who have signed it whereever we represented ubuntu
<rickspencer3> ironically, I button placement has no impact on me
<LaserJock> exactly
<ScottK> nigelb: Certainly, but every time I mention Ubuntu, doesn't mean I'm representing Ubuntu.
<rickspencer3> I use keyboards for closing windows, and it took me less than a day to adjust to pointing with the mouse
<ScottK> rickspencer3: It's easy to get used to doesn't address the question of why the change is benificial.
<ScottK> I still didn't see that question addressed.
<rickspencer3> ScottK, I know
<nigelb> ScottK: ah, but if I swear at someone on the !ubuntu group that would be against coc?
<LaserJock> ScottK: because it messes with notifications
<rickspencer3> I'm not really involved, but I wish the designers were a bit more communcative
<ScottK> LaserJock: But notifications are semi-transparent and click through so it doesn't matter.
<ScottK> That's the whole rationale for no actions.
<rickspencer3> but nasty-grams won't get them out of their shells
<ScottK> nigelb: I think it's orthogonal to the CoC.
<nigelb> orthogonal?
<ScottK> Unrelated
<LaserJock> ScottK: the semi-transparent thing is sort of annoying, so if you never go up there maybe it helps? I dunno
<nigelb> ScottK: its kinda like a grey area to me
<rickspencer3> nigelb, perhaps someone should start a new !ubuntu group that does strive to have members that conform to the coc
<rickspencer3> and actually admin it that way
<ScottK> LaserJock: I agree. I tried the new notification style when we had a KDE version of it and really didn't like it.
<LaserJock> rickspencer3: maybe !ubuntu-members?
<rickspencer3> dunno
<nigelb> I dunno, I'm meh about it
<LaserJock> I just went back to using twitter more
<rickspencer3> LaserJock, but !ubuntu was a lot more interesting when it was a stream of what people were working on
<LaserJock> agreed
<nigelb> rickspencer3: that's what I do.  I use it to say what I'm working on
<rickspencer3> I guess there's still mostly that
<rickspencer3> nigelb, me too, mostly
<LaserJock> it seems more like IRC+spam to me
<rickspencer3> oh well
<ScottK> rickspencer3: Since the Ux stuff is defined as a designer led effort, I guess I'm suprised they aren't prepared to communicate about it.
<rickspencer3> ScottK, yeah
<rickspencer3> I think it's just a really hard thing to get used to
<LaserJock> yeah, I don't mind UI changes nearly as much as UI changes that lack rationale
<rickspencer3> like having to discuss with people who aren't just the client
<ScottK> Equally, I think that I can understand why people are getting upset about the lack of communication.
<rickspencer3> ScottK, ack
<rickspencer3> lack of communication is the single biggest cause of stress
<ScottK> I agree that reasoned discourse is better, it's just that I can understand being upset.
<rickspencer3> and when you don't speak up, you leave more room for trolls and rumor mongers
<LaserJock> rickspencer3: perhaps it would help if their view of "client" was expanded a bit more?
<rickspencer3> and no way for anyone to defend your position
<ScottK> Yep.
<rickspencer3> LaserJock, yeah, it's a process though
<rickspencer3> I'm really happy to be working on distro that has a serious design team
<LaserJock> sure
<LaserJock> I was really impressed with mark's blog post
<ScottK> At this point I think they've pretty well lost public opinion on the moving the window controls.
<rickspencer3> so I expect in time we'll all figure out how this works
<ScottK> I don't think that they'll turn it around.
<LaserJock> outlining what was going on, why, and most importantly going through examples
<rickspencer3> well ... tbh, I expect most folks will find in time that the window ordering thing is not as big a deal as they think
<rickspencer3> but I am biased, since I so completely don't care
<rickspencer3> and I think it looks better the new way
<LaserJock> well, and it can be reverted at some point right? I mean we aren't technically even at Beta
<rickspencer3> LaserJock, sure
<rickspencer3> I think changing it back is still on the table tbj
<rickspencer3> tbh, even
<LaserJock> it's going to make people gun shy if they can't even put out a design for testing without getting flamed to death
<rickspencer3> the right thing will happen
<ScottK> LaserJock: Probably.  People usually learn the wrong lesson.
<rickspencer3> LaserJock, right, but to ScottK's point, the flaming is a bit of self-inflicted wound
<LaserJock> true
<rickspencer3> if there were up front talking about it from the moment it released, I bet it would blow over
<LaserJock> but the natural reaction would be to run the other way
<rickspencer3> yeah
<LaserJock> yeah
<rickspencer3> it can be scary talking to "the community"
<LaserJock> 1 good blog post with rationale for the changes would have done a world of good
<ScottK> Given the one sided nature of the discussion, if it doesn't get reverted, it will reinforce people's perceptions about Canonical not caring about community.
<rickspencer3> seeing the "community" as something other than real people that you can talk to
<rickspencer3> well, it's not one-sided, imo
<rickspencer3> (assuming you mean universal support for YokoZar's position)
<ScottK> rickspencer3: I've seen very little positive reaction.  Most non-negative reaction seems to be "I got used to it".
<LaserJock> it seems like everything but the button-placement has been discussed pretty well it seems to me
<rickspencer3> yeah
<ScottK> rickspencer3: No, it's not universal, but it's pretty strongly against the change from what I see.
<rickspencer3> I mean, man, what a small issue
<LaserJock> but the only reasoning I've seen from a design person was something like "dunno, we're just having fun trying something out"
<rickspencer3> all the incredible stuff getting done in Lucid, and folks are so obsessed with button placement
<rickspencer3> LaserJock, I wonder if it is truly just a matter of taste
<rickspencer3> ?
<ScottK> rickspencer3: It's not really small.  That's probably the second most common area for me to click on something.
<rickspencer3> fair enough
<rickspencer3> but still
<LaserJock> which side is probably a matter or taste
<LaserJock> the problem is cognitive momentum
<LaserJock> it's a cost to change the habit
<rickspencer3> right, but that's the "you can never change UI" slippery slope
<LaserJock> so the cost of the change needs to be lower than the benefit
<LaserJock> yep
<ScottK> rickspencer3: Right, but if there was some communication of the benifit, people would be more open to it.
<rickspencer3> so the question is, is the aesthetic benefit worth the perceived cost?
<LaserJock> that's why I think it's great to "test", but without rationale it's hard to see the benefit
<rickspencer3> ScottK, right, I think I am in raging agreement with you on that
<ScottK> Or if they had even said, "we're trying this out, let us know what you think"
<rickspencer3> or "we really really think foo"
<LaserJock> instead of "new world order"
<ScottK> As it is, people think they are going to be stuck with it (which may be true)
<rickspencer3> where foo was pretty much anything
<rickspencer3> ScottK, well, not surprisingly, there are already two UI projects I've seen to control button placement ;)
<ScottK> rickspencer3: Yep.  I'll be glad to grant a FFE for the first guy that packages one.
<rickspencer3> but, I think we need to figure out how to pull the design team out of their shells
<rickspencer3> I know them as specific individual people that I like
<ScottK> rickspencer3: I think the antecedent of we in that statement is Canonical management.
<rickspencer3> ScottK well ...
<rickspencer3> I think the community needs to figure this out as well
<ScottK> The community doesn't have access to them.
<LaserJock> the Ubuntu developer community can't do much to help if DX doesn't give us anything to run with
<rickspencer3> though certainly as members of the community, folks inside canonical has a role to play
<rickspencer3> ScottK, not true
<rickspencer3> they have a channel and a list
<rickspencer3> and a lot gets done in those forums
<ScottK> rickspencer3: Dx does, but not the Ux people, AFAIK.
<rickspencer3> in fact, button placement has an interesting thread on their list
<rickspencer3> ScottK, #ayatana
<ScottK> rickspencer3: That's just Dx.
<rickspencer3> ScottK, nope
<ScottK> They don't decide this stuff, they just implement what they get told.
<rickspencer3> ScottK, though ironically, no on in design is online right now
<rickspencer3> one thing is the design team works co-located in rooms, not in front of their computers
<rickspencer3> so they can be hard to get on IRC
<ScottK> That's part of why I quit hanging out there.
 * rickspencer3 nods
<LaserJock> I don't know that the community really knows who they are, etc.
<ScottK> The general answer was "we just gdo what we're told"
<ScottK> gdo/do
<rickspencer3> ScottK, Dx or design says that?
<ScottK> Dx
<rickspencer3> sounds fun
<rickspencer3> ScottK, once again, you and I are in raging agreement ;)
<ScottK> Also, Ayatana has been defined as a design led effort, so why should they listen?  They've been told it's there's to figure out.
<rickspencer3> on that note, I am going to the brew pub to fill our growler
<rickspencer3> 4 11 y.o. girls + 1 karoake machine + 1 sleepover birthday party = requirement for full growler
<rickspencer3> ;)
<ScottK> No kidding.
<LaserJock> lol
<LaserJock> good luck with that
<LaserJock> grrrr, apps with 3+ rows of toolbars makes working on a netbook not-so-fun
<rickspencer3> later guys
<xrc> hi, where i can consult about developing snmp application using snmpkit headers from libsnmp-dev?
<micahg> xrc: as an Ubuntu app?
<xrc> as an genereal linux app
<xrc> not specific ubuntu
<xrc> just ubuntu is working environment, where i develop
<micahg> xrc: well, in the channel title is an ubuntu app development channel
<xrc> ok, then let's talk about developing app for ubuntu
<micahg> xrc: but the net snmp project is here: http://net-snmp.sourceforge.net/ and they might have their own IRC channel for general questions
<xrc> they also state they have different header file structure and talk about package "net-snmp". ubuntu has differences from their perspective, so, i assume ubuntu has differences and somebody has done them
<xrc> but, away from snmp: headers in /usr/include - they are just meant to be only structural headers, or are functions declared there availible somewhere?
<micahg> xrc: well, we sync from debian, so I don't know about what differences we have, but maybe the #ubuntu-app-devel channel would be a good place
<davmor2-netbook> Guys is it known that you can't add apps to favourites in une?
<lucas> questions: what is the exact definition of the "main" component? what's the exact difference with "universe"?
<kurapix> hi
<nigelb> !main
<ubottu> The packages in Ubuntu are divided into several sections. More information at https://help.ubuntu.com/community/Repositories and http://www.ubuntu.com/ubuntu/components - See https://wiki.ubuntu.com/RecommendedSources for the recommended way to set up your repositories
<persia> lucas: "main" is the set of stuff that is recursive dependencies, recommendations, or build-dependencies of stuff in main.
<kurapix> i'm quite interested in contributing in the Ubuntu projects but I don't know where to start and which one to work on, i've been reading a bit but can't seem to decide
<kurapix> do you have any tips and tricks about it?
<nigelb> you're interested in development?
<kurapix> yes I am
<nigelb> in that case most people would ask you to start bug triage
<persia> lucas: It has a loose mapping to a number of other things (e.g. Packages receiving security support, packages receiving translations in langpacks, upload permissions, packages that are used to build flavours defined as being in "main", packages supported by Canonical), but none of these are accurate descriptions.
<nigelb> kurapix: here you go for bug squad https://wiki.ubuntu.com/BugSquad
<persia> lucas: So there exist packages in main that do not fit into any of the more descriptive sets, and there exist packages not in main that do fit into each of those sets.
<kurapix> bug triage? going around launchpad and fix bugs? if I don't have a deep knowledge of the software being debugged, wouldn't it be a problem?
<nigelb> kurapix: you can triage bugs for some time and then slowly try to fix the ones you think you can handle
<nigelb> kurapix: bug triage is not fixing, bug triaging is handling bugs to confirm which of them is actually a bug and which is not a bug
<kurapix> oh ok
<kurapix> doesn't seem like a bad idea at all :)
<nigelb> kurapix: I myself started with bug triage and now I understand enough to fix small bugs, so I talk from experience too!
<kurapix> ok thank you for the tip :)
<lucas> persia: so, to rephrase, there's no clear definition besides the recursive one. and the "all packages in main are supported by the Ubuntu team" claim is wrong, since there are packages in main that are not supported (except for major security problems, but clearly not for bug fixes, even important ones)
<kurapix> I'm quite interested in OS thing so I think it'll be a good thing to start :) and not to hide anything, I'm also interested in GSOC
<persia> lucas: Yes, I have found packages that were not being maintained at all, even with important bugfixes (in the "does not work at all for any purpose" category).
<lucas> http://www.ubuntu.com/community/ubuntustory/components says: "When you install software from the main component you are assured that the software will come with security updates and technical support.". I wonder what the definition of "technical support" is.
<persia> I think it means you can purchase support from Canonical.
<lucas> I see
<wgrant> Which is false, AFAIK.
<persia> Note that when we find packages not maintained in main, we make an effort to pull them out, and when we add new packages to main, there is a process that is supposed to make sure they are maintained.
<persia> wgrant: It is?
<lucas> persia: sure, but then sometimes, you need packages in main because they are (build-)?depends that you can't drop
<wgrant> I don't believe commercial support is available for everything in main.
<lucas> then someone uses that package directly (not as a depend) and it breaks
<persia> lucas: Indeed, and there's >1000 packages in main that were stuck in intiially, some that would most certainly not pass the MIR criteria if checked.
<wgrant> But my hazy memory of the hazy definition is hazy.
<nigelb> wgrant: too much haziness ;)
<persia> wgrant: Hrm.  You might be right.  I haven't investigated the options there in depth.
<persia> lucas: This complete lack of a definition for main is one of the drivers for ArchiveReorganisation.
<lucas> persia: I thought that was an orthogonal issue?
<lucas> ie main will stay because of the need to track (b-)?deps?
<persia> Essentially, by organising on a per-flavour basis, we can (presumably) identify sets of folk that commit to certain levels of support for sets of packages, but that's a long way off still (we're still working out how to set upload permissions, and haven't even begun the work on how to expose in the archive, or how groups can specify support)
<mr_pouit> is there a log of universe demotions avilable somewhere?
<persia> lucas: No, because seeds track (b-)deps just fine, if asked.  main is going away, but it will take a while.  See https://wiki.ubuntu.com/ArchiveReorganisation/Components
<persia> mr_pouit: The info is in LP: one may be able to extract with lplib.  Much like MIRs, they are mostly tracked in bugs.
<persia> (although not always, when an archive admin digs at component-mismatches with a will)
<lucas> persia: so it's even worse, because ruby1.8 (in main as a dep, not cared for), will be in even more sets are a dependency
<lucas> s/are/as/
<mr_pouit> persia: and a more direct way? Because someone just demoted lots of (b-)deps of abiword to universe *without warning*, and I'll have to find which ones, and rebuild them because otherwise all translations will be missingâ¦
<persia> lucas: Well, in the short term, yes, in the longer term, perhaps not, depending on what level of "support" we expect from those who indicate that they provide support for something.
<persia> mr_pouit: I don't know of any.  Sorry.
<persia> mr_pouit: Maybe an archive-admin can check some log?
<wgrant> You can get a list of universe publications from LP ordered by date.
<mr_pouit> ahah, ok, so I have to waste time doing that because some archive-admin thought I was a good idea to throw them to the garbage-can^W^W universe without warning
<mr_pouit> *it was
<mr_pouit> that's always the same thing
<mr_pouit> and that's aboring
<persia> We really need to sort the Rosetta part of Archive Reorg soon.  There's a bunch of packages in universe with langpacks in a special list, and regular accidents with stuff moving in and out of main.
<persia> It oughtn't be hard to just drop the component check, and use lists.
<wgrant> How does that help this situation?
<persia> wgrant: Because the list wouldn't change when the component changed, and when the list changed, reuploading could occur if required.
<persia> Doesn't help retroactively, but avoids recurrances.
<persia> (and we already have code in place to be able to do it, which is always nice)
<mr_pouit> persia: nothing has changed since hardy. For hardy, all xubuntu was demoted to universe, and I had to rebuild everything myself, nobody helped
<wgrant> Well, I guess it does slightly solve it.
<persia> mr_pouit: I know.  I've been in discussions about ArchiveReorg since shortly after Hardy release.  Progress is just slow.
<wgrant> But we need a good solution to translations.
<persia> wgrant: What would you suggest, if not using lists?
<wgrant> persia: How do we declare which lists are included in the langpacks?
<persia> wgrant: Same as we do now.
<wgrant> persia: That's impossible.
 * persia doesn't know the details, but was told firmly that there were override lists to permit additional packages in universe to be included in each langpack
<wgrant> main will cease to exist.
<mr_pouit> but there is a quick fix: communicating on ml or LP. For example when someone uploaded a new libxkavier package that bumped the soname, nobody was notified, main was fixed, and universe packages were let broken
<persia> mr_pouit: NBS is the way to handle the SONAME stuff, really.
<mr_pouit> debian people are (almost) able to coordinate transitions, so why can't we do it in ubuntu?
<mr_pouit> persia: no, bug reports are the way
<persia> mr_pouit: Let's focus on translations: that's a separately soluable issue.
<mr_pouit> but it's the same "I don't care of what could happen in universe" idea
<persia> No, bug reports are very much *not* the way.  That class of bug report causes way to much mail for people who don't want it.
<mr_pouit> they should just unsubscribe then
<persia> They can't.
<mr_pouit> add mail fiters
<mr_pouit> whatever
<mr_pouit> because otherwise we're not notified
<persia> I know a number of upstream developers and Debian Developers who have decided not to subscribe to LP bugs for their packages precisely because of such bugs.
<persia> Just poll NBS regularly.
<mr_pouit> sorry, that's wrong
<wgrant> Using bugs for that purpose has been tried, and it went disastrously in some cases.
<persia> We often don't even know when a transition happens, because it's autosync.
<persia> so there's no person who would file the bug.
<mr_pouit> I'm supposed to read all -changes@ and NBS to detect all possible breakages caused to xubuntu by the desktop team
<mr_pouit> do you know how mcuh time I waste for that?
<mr_pouit> time that could be used better?
<persia> approximetely yes.
<persia> But note that not all breakage is caused by someone doing something specific.
<persia> When it is, and nothing gets done, and there is no notification, replying to the -changes mail asking for notification is appropriate to encourage cooperation.
<persia> But lots of transitions happen anyway, when nobody takes specific action to make them happen.
<slytherin> Any ubuntu-release team members here (and not busy)?
<mr_pouit> persia: bah, already tried, nothing changed. The changes in desktop files some releases ago (which broke kubuntu translations), or the "let's introduce appindicators everywhere and oversize the xubuntu cd" recently, everything has been done after the ff without warning. So everything's fine, and I'll stop complaining.
<persia> No, everything isn't fine.
<persia> That sort of intentional change needs to be communicated.
<persia> Filing a bug that affects umpteen packages just isn't the way to perform that communication.
<persia> It should be an email to ubuntu-devel@
<mr_pouit> Right, that's precisely my point, I don't care of the way (bug report, ml, ping on irc), if there is some communication. But that's not the case.
<persia> For the set of intentional changes, I agree with you except I strongly feel it shouldn't be a bug report.
<persia> For the set of autosync changes, I don't think anyone can be expected to know to send such communications.
<persia> But after DIF, it ought be clearer, and after FF, it ought not happen.
<cjwatson> mr_pouit: personally, when I do intentional transitions, I make an effort to fix everything, not just main - see the recent parted transition for instance.  That just seems like good engineering to me.  persia's right that there isn't always a deliberate action in Ubuntu associated with such changes though, unfortunately
<persia> cjwatson: Unfortunately, not all are as diligent as you, and some go so far as to share their opinion that it isn't important in public fora.  I believe this to be entirely a social issue, and soluable through gentle queries (noting that there's usually a few people willing to help with any particularly large transition if it's just a volume-of-work thing).
<cjwatson> I can understand that some transitions are more work than others, but I think wilfully ignoring it (and not at least telling people that there's something to do - you don't have to spend hours and hours on it yourself, necessarily) borders on negligence
<persia> Indeed.
<cjwatson> to be frank
<cjwatson> obviously sometimes it's just load-induced forgetfulness, don't assume malice when forgetfulness will do etc.
<persia> Personally, I've yet to see a case where a call for help with a transition was announced on IRC or the mailing list that didn't get at least two people helping.
<slytherin> Can anyone from release team take a look at this FFe - bug 534289. Without this the x264 plugin in gstreamer does not build with latest libx264.
<ubottu> Launchpad bug 534289 in gst-plugins-ugly-multiverse0.10 "[FFe] New upstream release 0.10.14" [Undecided,New] https://launchpad.net/bugs/534289
<hdon> on karmic, printf(3) docs say libc supports %z, but when i build with libc6 it turns out to not be supported at all. any ideas?
<hdon> oh, duh, i forgot d/u
<sladen> slacker_nl: FTBFS is a pretty good reason
<slacker_nl> ?
<nigelb> I think tabfail ;)
<nigelb> slacker_nl: was meant for shadeslayer I guess
<slacker_nl> nigelb: i think a tabtypo
<nigelb> yup
<nigelb> I've been trying to get a new workflow for bugs with patches attached.  Its still in discussion but if anyone has any thoughts on what we're come up with, I'd be happy to hear http://etherpad.com/L6x2FUVnYi
<nigelb> s/'re/'ve
<bluefoxicy> is it time to revamp the Gnome properties dialog box to look more like the NT Security Settings dialog box?
<bluefoxicy> we've had POSIX enhanced ACLs forever
<bluefoxicy> can add multiple user and group permissions to files; set the owner (user) and group; and set permissions individually
<ScottK> bdrung: Apparently your glib2.0 patch broke sparc.  Please fix.
<hdon> hi all. it appears that COLUMNS is not exported by bash by default. why is this?
<hdon> i'm used to systems exporting COLUMNS and LINES
<c_korn> hdon: hello, it is exported for me in the gnome-terminal. but this is definitely the wrong channel for this question
<kurapix_> good night
<bdrung> ScottK: do you have a build log?
#ubuntu-devel 2011-03-07
<TheMuso> psusi: ah ok
<psusi> TheMuso, so umm... what exactly does that patch fix?
<TheMuso> psusi: I'd have to read the patch again to clearly remember... One of my first changelog entries for parted should explain it.
<psusi> TheMuso, the description in the changelog says " dmraid.patch: Ensure that device-mapper devices for dmraid arrays do not have extra nodes created needlessly, as well as making sure that partition nodes for dmraid devices are not probed."  I can't figure that out.  What nodes were being created under what conditions?
<TheMuso> psusi: At the time, every dmraid device node that was created that parted dealt with, had additional nodes created to represent partitions, I think. This code was written over 3 years ago, so of course things may have changed. I understood why at the time. :)
<TheMuso> psusi: I guess the best experiment is to take out my patch, play with dmraid stuff and parted, and see what happens.
<psusi> TheMuso, k.. guess I'll try that...
<TheMuso> If I continued dmraid related code maintenance, I'm sure I'd still know. I think that a ${node}p1 node was being created for every dmraid related node at the time, including partitino nodes, which is why the patch also stops dmraid partition nodes from beinb probed.
<TheMuso> Now that I think, it was to do with probing. For some reason parted thought that every dmraid node had a partition table of some kind... beats me why
<psusi> hrm... now this is weird... gnome-power-manager is running, but doesn't seem to actually be used.. it looks like we use upowerd to suspend, so what the heck is gnome-power-manager doing?
<RAOF> Display blanking, automated âsuspend when low batteryâ stuff?
<psusi> RAOF, doesn't appear to be.. looks like upower is doing that these days... which explains bug #578542
<ubottu> Launchpad bug 578542 in gnome-power-manager (Ubuntu) "resuming from S3 wrongly prompts for password" [Low,Confirmed] https://launchpad.net/bugs/578542
<psusi> I sent g-p-m a SIGSTOP and clicked suspend on the menu and it worked normally
<RAOF> psusi: That's orthogonal to what I said.  That's neither âsuspend when battery lowâ nor âdim screen on inactivityâ. :)
<RAOF> Those are policy decisions rather than implementation methods.
<psusi> ahh...
<psusi> so where is the darn screen saver being started and the screen locked?  hrm...
<psusi> hrm.. can you use dbus-send to manually emit an org.freedesktop.UPower signal?
<psusi> or better yet, find out what is listening for that signal?
<RAOF> psusi: I don't think you can track what's listening to the signal.  I think dbus-send should be able to fanangle a signal for you, though.
<psusi> RAOF, I thought so but I can't seem to figure it out... I don't quite understand the arguments it wants, specifically what the difference is between --dest=, <destination object path> and <message name>..
<RAOF> Heh.
<RAOF> Say hello to DBus!
<RAOF> --dest= is the *interface* that the signal you want to send is from.
<RAOF> Oooh, actually, no.
<RAOF> You shouldn't need --dest, because you're not sending it anywhere specific.
<RAOF> <destination object path> should be the object path of the object you want to raise the signal _on_
<RAOF> <message name> should be the signal you want to raise, namely the fully-qualified signal from the interface (org.freedesktop.UPower.$INTERFACE.$SIGNAL)
<psusi> so org/freedesktop/UPower and org.freedesktop.UPower.Sleeping?
<psusi> err, what's $INTERFACE?
<RAOF> Sounds like $INTERFACE is ""
<RAOF> So you'd want to send org.freedesktop.UPower.Sleeping
<RAOF> But if UPower had multiple interfaces (o.f.UPower.Bar.Sleeping, o.f.UPower.Baz.Sleeping, for example) you'd stick in the fully qualified thingy.
<psusi> process 19675: arguments to dbus_message_new_signal() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1289.
<RAOF> Sounds like you've got the wrong object path?
 * RAOF fires up d-feet
<psusi> d-feet?
<RAOF> â¦and immediately notices he doesn't have a UPower interface.
<RAOF> Oh, man.  You're debugging DBus issues and you don't know about d-feet?  Sorry!
<RAOF> It's a DBus browser.  It can't raise signals, but it does enumerate the bus and such.
<RAOF> Oh, of course.  It's on the system bus.
<RAOF> So âdbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleepingâ works for me.
<RAOF> So âdbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleepingâ works for me.
<psusi> DOH!
<psusi> I wasn't using the leading / before org
<RAOF> It also doesn't trigger anything obvious for me :)
<psusi> me neither... hrm...
<psusi> so there's no way to monitor who is interested in the signal?
<psusi> hrm... this doesn't seem to do anything either: dbus-send --type=method_call --dest=org.freedesktop.UPower --system /org/freedeskop/UPower org.freedesktop.UPower.Suspend
<RAOF> Wheras that was very happy to suspend my system.
<RAOF> And, of course, did not result in gnome-screensaver coming back with a screen lock.
<psusi> hrm.. it works when I use d-feet to call it and yea, doesn't lock the screen
<psusi> hrm...
<RAOF> In hindsight, I knew that; I needed to fix a bug where Do wouldn't lock the screen before suspend because it was calling UPower directly.
<psusi> so what on earth DOES lock the screen?
<RAOF> Well, in Do we call out to gnome-screensaver ourselves.
<psusi> bingo... indicator-session... session-service.c:machine_sleep()
<psusi> now I wonder why the gconf key for g-p-m to lock or not is still there when it doesn't handle that function?  hrm..
<abhinav_> is there a command to delete a branch from the repository ?
<abhinav_> in bazaar
<RAOF> rm -r?
<abhinav_> so bazaar will know that the branch is gone, if I do that ?
<RAOF> Yes.
<abhinav_> oh ok. thanks
<RAOF> * For some values of âyesâ.
<RAOF> What exactly do you want to do?  Free disk space?  Strip out some unwanted stuff from a repository?  Clean your source trees?
<abhinav_> yeah. I was experimenting something in a branch. I do not want to merge those changes,
<RAOF> Oh.  Then just don't merge those changes :)
<nigelb> lol, rm -r
<abhinav_> yeah, but that branch is pretty useless now. deleting it should not be any harm ?
<RAOF> The repository is just a performance optimisation.  It doesn't actually have any semantic meaning.
<RAOF> So, while those commits will remain in your local repository, they won't get pushed anywhere (unless you push something that refers to them, but you'd need to merge them for that to happen).
<RAOF> Your local repository will be a couple of KB larger than it would otherwise be :)
<abhinav_> ah ok. that's fine :)
<RAOF> Mmmm, âAbout 8 hours remainingâ.  dpkg really, really likes unpacking onto btrfs, doesn't it :)
<abhinav_> why does dch -i add maverick at the top of the changelog entry, even though I am working on natty package ?
<dholbach> good morning
<abhinav_> good morning :)
<micahg> abhinav_: you can pass -Dnatty to work on a natty package (I'm assuming you're on maverick)
<abhinav_> yes, I am on maverick
<abhinav_> I have already saved the changelog. I suppose I can edit it and write natty instead of maverick.
<micahg> abhinav_: yeah, if you start with UNRELEASED, you can use -D to add the series later, but now you'll have to just edit it
<abhinav_> ok thanks :-)
<abhinav_> well actually I am working on a bug fix of tomcat6, as I see in the changelog, all the entries say "unstable" instead of maverick or natty
<micahg> abhinav_: that's because it comes from Debian
<abhinav_> ohsix, so I should write unstable too ?
<abhinav_> *sorry
<micahg> abhinav_: no
<ohsix> tell debian about it,  no?
<micahg> well, the patch should be upstreamed to Debian if appropriate, but that's another question :)
<ohsix> i can never remember if unstable or testing is the one to expect breakage
<ohsix> (lots of, not some)
<abhinav_> hmm , I have the patch ready :-), Its my first bug-fix, so I have not much idea about the process
<abhinav_> but the package is tomcat6-6.0.28, I believe same is available in maverick repositories
<micahg> abhinav_: https://wiki.ubuntu.com/SponsorshipProcess
<zanaga> what is the correct way of requesting a sync from debian that replaces a package from a different source? I just want to get this stuff filed for the next release cycle.. Regarding LP#378240
<pitti> Good morning
<pitti> slangasek: sure, no prob
 * SpamapS_ gulps
<SpamapS_> 933 upgraded, 66 newly installed, 1 to remove and 1 not upgraded.
<SpamapS_> Need to get 977 MB/977 MB of archives.
 * SpamapS answers yes... here we go!
<pitti> slangasek: gtk 2 uploaded
<abhinav_> where can I get some help on gtk# ?
<RAOF> abhinav_: #mono on gimpnet is a reasonable place for gtk# help.
<abhinav_> RAOF: thanks. I will ping there :)
<RAOF> abhinav_: But mainly what I use is the python & C gtk doc; gtk# is a fairly obvious translation to C#.  Code-completion helps, too :)
<abhinav_> yes, I don't know. I need some help with the TreeView, but the functionality that I am looking for does not seem to be available as per the documentation
<dpm> hey mvo, good morning. A translator has found some encoding problems in apt translations in Launchpad. Before I can help him I wanted to ask you: how are apt translations handled? Are translations from LP ever exported and committed to the code, or do translations come exclusively from upstream in Debian?
<kirkland`> didrocks: hi
<kirkland`> didrocks: how do i make the unity search thing look for stuff in my $HOME/bin?
<didrocks> kirkland: hey, the search is only based on desktop files
<didrocks> so put a desktop file in your XDG path
<kirkland> didrocks: dang
<didrocks> we'll have an alt + F2 soon
<kirkland> didrocks: i just want to run a wrapper script
<soren> \o/
<kirkland> didrocks: like i used to do with alt-F2
 * soren misses Alt-F2
<kirkland> didrocks: oh, okay, as long as alt-f2 comes back, that'll be fine
<didrocks> kirkland: you'll have one if I find the time to code it :)
<didrocks> yeah
<kirkland> didrocks: cool, thanks
<didrocks> yw :)
<nigelb> bdrung_: Thought you might have liked to see http://stopabusingsiprefixes.org/stopabusing.html
<kirkland> didrocks: if you're writing this, could you make sure that the alt-f2 path contains $HOME/bin?
<nigelb> Ubuntu is lame.
<nigelb> Maybe, but at least they have a sensible units policy.
<didrocks> kirkland: it will respect the PATH
<nigelb> bdrung_: direct quote ^^
<didrocks> sounds less hackish :)
<mvo> dpm: they come exclusively from upstream
<mvo> dpm: what language(s) are affected?
<bdrung_> nigelb: :) sadly the upstream authors with power refuse to do something regarding this bikeshed topic
<kirkland> didrocks: okay
<nigelb> bdrung_: oh, ouch :(
<bdrung_> nigelb: https://bugzilla.gnome.org/show_bug.cgi?id=640432
<dpm> mvo, thanks for confirming. Slovenian: look at the squares in the suggestions on https://translations.launchpad.net/ubuntu/natty/+source/apt/+pots/apt-all/sl/+translate (note that the translators have already corrected it in LP) - due to message sharing, I'm not sure if these translations were imported from a natty, lucid or maverick upload
<nigelb> bdrung_: oh dear.  Its bad when someone says, "flame" in the beginning of the bug
<mvo> dpm: thanks, I check it ou
<mvo> t
<dpm> thanks :)
<dpm> mvo, it's translations questions day today! :-) Here's another one: do you happen to know who handles translations for gdebi, and how/where they are done?
<mdz> pitti, is there a problem with the retracer? I'm seeing 16-hour-old bugs like 730243 are not retraced yet
<mdz> dbarth, I noticed the above because I got a compiz crash and saw there were plenty of others coming in like it (unity-window-decorator crashed with SIGSEGV in g_closure_invoke())
<dbarth> mdz: the decorator issue is on our radar
<dbarth> mdz: smpillaz has made more fixes for it, and i'm seeing with didrocks when he can release that
<mdz> dbarth, ok
<seb128> mdz, let me check on the retracers
<seb128> mdz, the amd64 had a lock set but was not running, the log had no error though so I just restarted it to see
<mdz> seb128, ok, thanks
<seb128> mdz, you're welcome
<mdz> seb128, did you see the new global bugpatterns code which is now in natty? you can write bug patterns which are not specific to a package, e.g. to catch crashes from a library which bubble up to many different apps
<seb128> mdz, no I didn't see it before and I didn't realize that matching was specific to components
<mdz> seb128, in the past, you had to put bug patterns into a file named after the package, and we would only check for patterns which applied to the package where the bug was being reported
<mdz> so if you had a libdbusmenu bug which caused crashes in gnome-terminal and nautilus, you would have to add separate bugpatterns for those (and any other app using libdbusmenu)
<mdz> now you can just write one which will (e.g.) match on the stack trace, regardless of which program crashed
<seb128> mdz, ok, I thought we had a pattern for this XAllocId ret != invalid crash for example
<seb128> but that's might be why it didn't seem to work ;-)
<seb128> mdz, thanks for working on that
<seb128> mdz, btw your bug got retraced
<mdz> seb128, in some places we suppressed the bugs in other ways, e.g. in a general hook or in apt
<mdz> seb128, I'm not familiar with the XAllocId issue and I don't see that string in the existing bug patterns; is it an active problem?
<mdz> maybe it would be a good test case :-)
<seb128> mdz,
<seb128> <!-- Converted from libxcb.xml -->
<seb128>     <pattern url="http://launchpad.net/bugs/507062">
<seb128>         <re key="AssertionMessage">_XAllocID:.*ret.*inval_id</re>
<ubottu> Ubuntu bug 507062 in libx11 (Ubuntu Lucid) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed." [High,Triaged]
<seb128> mdz, I was speaking about this one
<cjwatson> on merges.ubuntu.com: I've tracked down what was causing the failure, prepared a backport of the relevant dpkg fix, and filed a ticket for our sysadmins to deploy that
<cjwatson> there may still be some work needed to avoid it running out of disk during the next run
<mdz> seb128, ah, I should have searched with -i. ;-)
<mdz> seb128, so that pattern will only get checked for bugs which are about to be reported on libxcb
<cjwatson> (Debian #594440 bit our eucalyptus package)
<ubottu> Debian bug 594440 in dpkg-dev "debian/source/include-binaries doesn't allow for inclusion of modified binaries" [Important,Fixed] http://bugs.debian.org/594440
<seb128> mdz, ok, that explains why we keep getting bugs reported against random binaries crashing this way
<mdz> seb128, er...actually pitti converted it to be package-independent already :-)
<pitti> mdz: retracers> checking; they crash very often these days
<mdz> pitti, I did the bugpatterns conversion based on r178, and there was no libxcb.xml in that version. did I make a bad merge or something?
<seb128> pitti, I sorted the retracers
<mdz> I don't see a mention of libxcb in the commit log, other than yours...
<pitti> mdz: I guess it was PEBCAK on my end, and I forgot to bzr add back then
<seb128> pitti, it's weird, it had a lock from yesterday and no error in the log
<seb128> pitti, removed the lock and it's fine
<pitti> seb128: amd64 is running, but i386 is locked and not running
<seb128> it's running
<debfx> cjwatson: on the weekend I painfully noticed that all kde-l10n-* packages are also missing from the kubuntu package set
<pitti> seb128: i386? I don't see it running
<seb128> pitti, ok, it might have had the same issue, the log had been updated recently when I checked on i386
<seb128> pitti, no, the timestamp was recent on i386
<debfx> cjwatson: I'd really appreciate if you could add them and the ones I emailed you
 * pitti starts manually and checks
<seb128> amd64 was from yesterday and I restarted it
<seb128> which worked
<pitti> seb128: bah, same "huge wadl HTML output spew" issue :/
<pitti> cache purged, restarted
<seb128> pitti, danke
<artfwo> seb128, I noticed you've just made bug 730528 affect libappindicator, but https://bugs.launchpad.net/libappindicator page is empty and states that libappindicator is not configured in order for Launchpad - how's that?
<ubottu> Launchpad bug 730528 in libappindicator (Ubuntu) "Impossible to inherit a class from AppIndicator*.Indicator in Python (gir)" [Undecided,New] https://launchpad.net/bugs/730528
<seb128> artfwo, I guess they didn't create a new component out of indicator-application when the source was splitted out
<seb128> artfwo, I basically just said "also affect component" and used what was suggested
<artfwo> ah, I see
<artfwo> thanks
<seb128> artfwo, I will check with kenvandine and ted if libappindicator should work as a project or if they want to use indicator-application
<artfwo> seb128, until than is it okay to use "also affects libappindicator" for upstream related bugs?
<artfwo> s/than/then
<seb128> it's fine, either libappindicator or indicator-application
<seb128> both will reach the same people
<cjwatson> debfx: I've done the ones you mailed me, but hmm, making a wildcard exception isn't supported by my current code AFAIK
<cjwatson> and there's no way I'm maintaining that package list by hand
<cjwatson> debfx: I think this is a matter for fixing the code that generates the package sets, not for making exceptions
<cjwatson> (it's my problem either way, but just to let you know)
<lamont> how does one reset the password on the gnome keyring?  wifely one is annoyed at the computer today
<debfx> cjwatson: ok
<seb128> lamont, reset?
<lamont> change
<seb128> you mean the password to unlock the keyring?
<seb128> you can do that using seahorse
<seb128> but it's the same as your login one by default and should be updated when passdw is used to change it
<lamont> ah, ok.
<lamont> that now all makes sense
<lamont> OTOH, password is coming from libnss-db, not via passwd command. so seahorse to change it is the right way, yes?
<cjwatson> debfx: fixed now, along with everything else in your supported seed
<cnd> do I need to request for an archive admin to review a package in the new queue, or will that be done automatically?
<debfx> cjwatson: that was fast, thanks
<cjwatson> cnd: you only need to request if you have a good reason to want to jump the queue
<cnd> cjwatson, ok, I assume it will be handled in due time then
<cnd> thanks
<chrisccoulson> @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: bdmurray, chrisccoulson
<chrisccoulson> \o/
<pitti> chrisccoulson: happy piloting
<debfx> cjwatson: I think the kubuntu mobile seed isn't part of the package set anymore
<c2tarun> I got this error while building a package http://paste.kde.org/6690/, when looked into file I found this line creating the problem http://paste.kde.org/6689/
<c2tarun> I need help with the second argument passed in the function, what does it mean? is it typecasting?
<mr_pouit> c2tarun: GTK_DISABLE_DEPRECATED is set, and GtkFunction is deprecated since gtk+ 2.24.
<cjwatson> debfx: probably not.  should it be the same set or a new one?
<c2tarun> mr_pouit: sorry :( what does it mean?
<debfx> cjwatson: for example plasma-mobile was in the kubuntu set before. imho it doesn't make sense to create a new one
<cjwatson> pitti: please note my changes to bug 723016, since it looks like it was you who turned it from a merge request into a sync request
<ubottu> Launchpad bug 723016 in pcsc-lite (Ubuntu) "[FFe] Please sync new upstream release 1.6.7-1 from Debian Unstable" [Undecided,Confirmed] https://launchpad.net/bugs/723016
<pitti> cjwatson: right, sorry; comment 1 seemed to indicate a sync request; reverted my changes
<cjwatson> yeah, I think that may have been non-jargon use of "sync"
<ari-tczew> pitti: thank you very much for sponsoring!
<pitti> ari-tczew: you're welcome, thanks for working on the merge!
<ari-tczew> ;-)
<doko> mterry: would you have time on a quick component-mismatches cleanup today? would like to do that before starting the rebuild test
<mterry> doko, I suppose?  you mean processing MIRs or something else?
<doko> mterry: there are no MIR's yet, I assume we could hunt down tkamppeter for the printing stuff, and maybe ScottK for the perl stuff
<mterry> doko, but yeah, I can help
<doko> otp now, later ...
<cjwatson> barry: FYI, I've started looking at that Wubi bug
<cjwatson> barry: I'm wondering if the use of grub4dos-derived code here is fundamentally misguided (it's *extremely* hard to debug) - it might be simpler to arrange to load GRUB 2 from NTLDR directly
<ari-tczew> doko: where can I find every fresh archive rebuild?
<barry> cjwatson: sounds good.  let me know if you have something you'd like me to test.  i'm patch piloting today
<tkamppeter> doko, what is the problem with the printing stuff?
<doko> tkamppeter: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt  all the cmap-* stuff
<doko> mterry: could you address the zope.fixers MIR?
<tkamppeter> doko, do they all need to get MIRed?
<doko> tkamppeter: yes, unless you remove them from gs-cjk-resource b-d's. or demote gs-cjk-resource
<tkamppeter> doko, seems that these files are fonts for Ghostscript being able to display documents in CJK languages.
<doko> tkamppeter: then please write a short MIR, and have a look at the packages
<tkamppeter> I have MIRed gs-cjk-resource recently as I have merged GS from Debian.
<tkamppeter> OK, Is it OK to make one MIR for all? They are pure data, so no security problems possible.
<tkamppeter> doko: ^^
<doko> tkamppeter: sure, as long as you review the package
<doko> (s)
<mterry> doko, ack re: zope.fixers
<doko> TheMuso: you did sync libffado.  but MIR's for libconfig and dbus-c++ are missing
<doko> mterry: thanks
<doko> Riddell: kdesvn: kdesvn-kio-plugins libsvnqt6
<doko>    [Reverse-Depends: kdesdk, kdesvn-kio-plugins]
<doko> didrocks, seb128, pitti:  o libquvi: libquvi-dev libquvi-doc libquvi0
<doko>    [Reverse-Depends: Rescued from libquvi, libquvi-dev]
<doko>    [Reverse-Build-Depends: totem-pl-parser]
<doko> MIR?
<doko> I'll look at the lintian related libperl-* stuff
<seb128> doko, bug #722591
<seb128> ?
<ubottu> Launchpad bug 722591 in libquvi (Ubuntu) "[MIR] libquvi" [High,New] https://launchpad.net/bugs/722591
<hallyn> soren: hey, my upload rights for vmbuilder are not yet in effect - would you mind uploading people.canonical.com:~serge/vm-builder_0.12.4+bzr463.tgz  ?
<doko> oops
<doko> seb128: well, then fix it?
<seb128> doko, there was no review from the mir team yet
<doko> mterry: ^^^ please?
<seb128> doko, what needs fixing? pitti just pointed some issues but said they were not blockers
<seb128> doko, it's assigned to kees
<doko> ahh, ok, anyway, it's assigned to kees
<barry> @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: barry, bdmurray, chrisccoulson
<pitti> wow, three pilots?
<barry> sure, why not? :)
<micahg> barry: hi, can you help me with a test case for a python exception for an SRU?
<barry> micahg: sure
<barry> micahg: do you have an issue #?
<micahg> barry: bug 702990
<psusi> pitti: oh boy, I think this was your area so maybe you can help.. I've been trying to run down a bug about why the gconf keys for g-p-m to NOT lock the screen and run the screen saver no longer work.  If I understood all the code I poured through last night, it looks like gpm has had its interface for initiating suspend removed and that is now handled by UPower now, is that correct?
<ubottu> Launchpad bug 702990 in wireshark (Ubuntu Maverick) "raise Python 2.6 compatible exceptions" [Low,In progress] https://launchpad.net/bugs/702990
<psusi> pitti: my theory is that the correct solution is to rejigger gpm to monitor the suspending signal from UPower and lock/ss if configured to do so, and the code to lock/ss needs removed from indicator-session, does that sound reasonable?
<cjwatson> hmm,/wg 20
<cjwatson> oops
<barry> micahg: i'm not sure exactly what you're looking for.  a unittest for wireshark that exposes the problem?  a recipe some human could perform to show the problem has been fixed?  something else?
<micahg> barry: idk, I'd like to SRU this so we can continue to fakesync security updates from squeeze, is something like this fragile and likely to break anything?
<micahg> oh, there's no debdiff, let me fix that
<barry> micahg: changing string exceptions to class exceptions can indeed break things, or it could be perfectly safe ;).  it depends on how the code uses the exceptions.  if it's primarily just raising and catching them, you should be safe.  if it does some kinds of introspection (i.e. checking the type) then you could be broken if that code wasn't also changed
<barry> of course, as the issue points out, string exceptions could have lots of reliability problems too, if not done right
<barry> cool.  a debdiff will help
<ari-tczew> micahg: did you see it? bug 730413
<ubottu> Launchpad bug 730413 in wireshark (Ubuntu) "CVE-2011-0538 Wireshark: memory corruption when reading a malformed pcap file" [Medium,New] https://launchpad.net/bugs/730413
<micahg> ari-tczew: yes, I chatted with udienz already, thanks
 * micahg has a little bug cleanup work later though
<micahg> barry: diff attached
<barry> micahg: omg.  yeah, those old string exceptions are completely broken, even in a python that supports string exceptions. :)
<micahg> barry: so, is it possible to safely SRU?
<barry> micahg: it's difficult to tell without a full code review.  e.g. are those string exceptions caught anywhere?  i'd be *very* surprised if the code had an 'except' that expected to catch those, 'cause it'd essentially be impossible.  i guess what i'm saying is that i can't see how the patch could make anything worse :)
<pitti> psusi: hm, g-p-m didn't change since maverick
<barry> micahg: is that good enough? ;)
<pitti> psusi: but yes, I believe the "initiate suspend" etc. stuff moved to gnome-session a while ago
<micahg> barry: umm, let's see
<micahg> pitti: what do you think about the above wireshark SRU bug and barry's comments?
<barry> micahg, pitti i suppose it's also possible that some code which would not otherwise catch the string exceptions, could start catching those new class exceptions.  but it seems very weird that you'd write an except clause for which you would specifically not want to catch those string exceptions.
<barry> micahg, pitti if that makes sense. ;)
<pitti> yes, it does
<barry> micahg, pitti so again, short of a full code audit, it doesn't seem like this patch can make things worse
<pitti> string exceptions are not a thing you'd ever want to catch and handle
<barry> most definitely not, though it *was* possible if done right
<pitti> seems okay to me
<pitti> and it's a standalone GUI app, i. e. not something that is used as a library and needs to maintain a stable public api
<barry> i suppose if you wanted to be really really safe, you could definite a local exception class that inherits from BaseException.  that way 'except Exception' wouldn't catch it.
<barry> pitti: in that case, i think the patch is fine
<micahg> pitti: so, what's the process for SRU since I don't have a test case?  the goal is to be able to continue to fakesync security updates from squeeze
<pitti> micahg: primarily "make sure that the program still works", by running through some standard use cases with it
<micahg> pitti: ok, can do, thansk
<micahg> *thanks
<psusi> pitti: yea, this has been going on at least since lucid
<psusi> pitti: it looks like idicator-session is what provides the menu on the pannel, and that appears to lock the screen, start the screen saver, and then send the Suspend message to UPower to actually suspend the system.  I think gpm used to be the thing that supplied the Suspend method and in response, it would lock the screen if configured to do so, but it looks like since UPower was introduced, this is no longer the case
<ari-tczew> pitti: can we drop changes with Break: udev ?
<pitti> ari-tczew: yes, lucid's udev is much newer already
<ari-tczew> pitti: ok thanks
<ScottK> doko: I'm very unlikely to have time to work on MIRs this week.
<doko> yeah, I know, trying to keep other people busy ...
<amitk> njpatel: do you already know of a unity bug where the app panel doesn't auto disappear?
<amitk> njpatel: and the bug where search just doesn't work?
<njpatel> amitk, when you fullscreen? Is this on multiple monitors?
<njpatel> amitk, re:search, do you have unity-place-files and unity-place-applications installed?
<amitk> njpatel: yes, 2 monitors
<njpatel> amitk, then, yeah, it's known hopefully fixed this week
<amitk> njpatel: for some reason those two were not installed (I've been upgrading natty since alpha 2)
<njpatel> weird :/ You'll need to restart unity after installing them (unity --replace from a terminal should do it)
<amitk> njpatel: much better, thx
<abhinav-> asac: http://gwibber.com/develop/ won't open ?
<njpatel> np :)
<SpamapS> zul: so, you're thinking the mysql maintainer scripts / upstart job need reworking, right?
<zul> SpamapS: thats what i was thinking
<tseliot> cjwatson: do you know if it's ok to install 2 alternatives (as in update-alternatives) in the same package? Is the debian policy against this?
<SpamapS> zul: so I think we should just follow dh_installinit's model and let the preinst stop, and the postinst start...
<SpamapS> zul: on a slightly related note, did you see that mysql 5.5.10 will have a libmysqlclient.so.18 ?
<zul> SpamapS: cool beans
<zul> SpamapS: yeah i saw that, that....will be fun
<SpamapS> zul: I suspect this bit is the issue...
<SpamapS> # to be sure
<SpamapS> stop_server
<chrisccoulson> cjwatson, is there a reason that metacity isn't in the ubuntu-desktop package set? i seem to recall it was at some point
<chrisccoulson> (although, i could be mistaken there) ;)
<RoAkSoAx> hggdh: Daviey bug #711587 comment #3
<ubottu> Launchpad bug 711587 in eucalyptus (Ubuntu Natty) "powernap and Eucalyptus seem unable to reach an understanding" [High,New] https://launchpad.net/bugs/711587
<Daviey> RoAkSoAx, looking
<cjwatson> tseliot: I can't think of a reason not to, I suppose
<cjwatson> chrisccoulson: probably build-dependencies from rest-of-world
<cjwatson> or just dependencies perhaps
<cjwatson> ubiquity depending on it might well pull it up
<tseliot> cjwatson: ok, thanks
<cjwatson> chrisccoulson: I can make an exception for it if you're requesting it
<Daviey> RoAkSoAx, Reading your comment, isn't this now a powernap bug rather than euca?
<RoAkSoAx> Daviey: is not a bug in PowerNap :)
<RoAkSoAx> Daviey: the thing is that before, PowerNap by default always run monitoring /sbin/init which cause to never perform any action to the machine and Eucalyptus never had any "issues" because it only told powernap "sleep now"
<chrisccoulson> cjwatson, i would like that, if you can do that
<RoAkSoAx> Daviey: so in fact, the relationship between powernap and eucalyptus before, was that powernap did nothing than run all the time waiting for a command from eucalyptus
<RoAkSoAx> Daviey: now, since powernap has evolved, other things need to be considered when configuring it to work with euca
<RoAkSoAx> so this is rather "best-practices" when working together
<kirkland> RoAkSoAx: honestly, Eucalyptus wants powernap to stay out of their way
<cjwatson> chrisccoulson: done
<kirkland> RoAkSoAx: all they want to do is call powernap-now
<chrisccoulson> cjwatson, excellent, thanks :)
<Daviey> RoAkSoAx, Yeah.... so either, powernap needs to revert to the previous behaviour ... or have a config.d/ where euca can throw in a /sbin/init as it's process... Can't think of another decent fix
<Daviey> RoAkSoAx, Can you?
<kirkland> RoAkSoAx: they don't want to leverage the flexibility of powernap, and that saddens me
<kirkland> RoAkSoAx: but so be it
<kirkland> RoAkSoAx: that's how they want to do it
<RoAkSoAx> kirkland: ah I was planning to email you my findings in a little bit more detail
<kirkland> RoAkSoAx: okay
<kirkland> RoAkSoAx: you can do that
<Daviey> RoAkSoAx, TBH... remember that this is a point release of euca... so expecting them to add new functionality is somewhat unfair
<kirkland> RoAkSoAx: Daviey's suggestion is reasonable
<RoAkSoAx> Daviey: I don't really want functionality added to euca just now, but it is just "recommended PowerNap config when runnning with euca"
<hggdh> actually a bit more than that
<hggdh> the current powernap config may cause problems with euca, so one of them should be adjusted. Given that it is just euca that gives us problems, we should adjust it there
<Daviey> RoAkSoAx, I'd recommend adding a config.d for powernap... That seems the least intrusive, and still enables powernap to be more useful in other scenarios
<RoAkSoAx> Daviey: yeah maybe it indeed is. Let me finish writing the email so that you can have a clearer picture of whats happening :)
<Daviey> RoAkSoAx, coolio
 * Daviey wonders if he /really/ just said coolio. :/
<ogra> it had a british accent
<ogra> so its ok :)
<dholbach> Daviey, I think after 15 years it's OK to refer to one hit wonders again ;-)
<Daviey> heh
<mterry> doko, so I'm finally getting to zope.fixers, and I'm having some problems with python3 and the control file.  I fixed some low-hanging fruit like enabling the test suite, but substitution variables in debian/control are bugging me.  python3:Versions isn't being defined by dh_python3.  Do you know why that would be?   Here's the current control file I'm working with: http://pastebin.ubuntu.com/577070/
<doko> mterry: ugh, sorry, I did interpret your ack as an ok
<doko> mterry: please go ahead and upload if possible
<GunnarHj> ScottK: Uploaded at last; thanks! :-)
<GunnarHj> ScottK: Seems like those l-s and gdm changes didn't fit well either for -updates or -backports, and that I was granted an exception. Is it so, and if it is, are the related procedures optimal?
<ScottK> I think backports was best.  It's just a difficult situation since it's such a core package.  Not sure how much better it could have been.
<mterry> barry, hello!  Got a sec?
<Daviey> RoAkSoAx, Thought about adding powernap support for openstack?
<barry> mterry: sure thing
<RoAkSoAx> Daviey: well I haven't yet seen OpenStack architecture so idk :). kirkland ideas?
<mterry> barry, look up a bit, I was asking doko about python3:Versions issues I was having with python3-zope.fixers.  It's not being defined by dh_python3 it seems?  Nor is Suggests or Provides...
<kirkland> Daviey: we discussed it in San Antonio
<kirkland> Daviey: the crowd was quite keen on the idea, as i recall
<barry> mterry: let me ask over in #debian-python
<mterry> ooh, new channel.  I'll join too
<barry> mterry: it's on oftc not freenode.  but if you join, do you want to just re-ask over there?
<mterry> ok
<barry> mterry: awesome.  i'll follow along
<Daviey> kirkland, yeah... as RoAkSoAx is working on powernap - wondered if it was a potential upstream contribution he'd like to undertake.
<kirkland> Daviey: RoAkSoAx: strong +1 from me
<abhinav-> barry, thanks for the review of the Tomboy merge proposal :)
<abhinav-> TheMuso, has communicated to the upstream about the patch https://bugzilla.gnome.org/show_bug.cgi?id=588730
<barry> abhinav-: np!  thanks for nice improvement.  hopefully my review is helpful?
<abhinav-> yes
<abhinav-> that was quite detailed and I learnt to notice fine details before submitting patches :)
<GunnarHj> ScottK: I see. Of course it would have been possible to do it the other way, i.e. starting with the latest Natty revision and revert changes that don't work in Lucid/Maverick. But since that would have involved stuff that I know almost nothing about (Python 2.7 -> 2.6, quite a few dependencies, etc.) I chose to add the changes I wanted to see backported. Maybe an experienced developer would have done it otherwise.
<barry> abhinav-: :)  sounds like the tomboy devs are receptive to the improvement!  nicely done
<ScottK> GunnarHj: I think it was a reasonable approach.
<abhinav-> barry, however, I have replaced the messagebox with a message and a button inside the tomboy itself.  i am still looking on ways to improve it.
<GunnarHj> ScottK: Ok. Anyway, glad it could be done. Thx again.
<abhinav-> soren, I was wondering, should I submit the new changes as a new merge proposal (in a new branch) or just push through this branch only ?
<barry> abhinav-: cool
<barry> abhinav-: no sure that comment was directed at me, but you can always just update your current branch and push the update.  the merge proposal will adjust.  unless the change is totally different, in which case, you can push a new branch and supersede the merge proposal with the new branch
<abhinav-> barry, ok. thanks for the help and guidance. after yours and dholbach's session, I have got a start in ubuntu development :)
<barry> abhinav-: yay!  do feel free to ask any questions about udd
<abhinav-> yup sure :)
<chrisccoulson> @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: barry, bdmurray
<RoAkSoAx> kirkland: Daviey email sent
<Daviey> wow RoAkSoAx, you like the long emails :)
<cnd> Riddell, did you know there's a *HUGE* debian-changes-4:4.7.2-0ubuntu1 file in qt4-x11?
<cnd> 1,113,501 lines
<cnd> seems like something is off
<doko> cnd, Riddell: if if plan to fix that, please wait until today's gcc-4.5 is built on armel, or add a versioned b-d
<doko> ogra: ^^^
<cnd> doko, I'll keep that in mind
<doko> and ogra did want to revert something ...
<psusi> say umm... don't you have to dereference or free the connection pointer you get from dbus_g_bus_get()?
<cjwatson> the documentation says "Returns a connection to the given bus. The connection is a global variable shared with other callers of this function."
<psusi> so that's a no then? ;)
<cjwatson> it's a "let Colin finish typing"
 * psusi will get this gnome stuff figured out yet
<janimo> cnd, that is probably because of upstream changes between 4.7.1 and 4.7.2 which are in that diff
<cnd> janimo, shouldn't the source package have been updated with the upstream changes?
<cjwatson> looking at the source, dbus_g_bus_get doesn't take a reference
<cjwatson> wait, does it
<cjwatson> dbus_g_connection_unref is a typed shim through to dbus_connection_unref
<cjwatson> and dbus_g_bus_get calls dbus_bus_get which takes a reference to the connection
<cjwatson> psusi: so the answer is, yes, you should dbus_g_connection_unref the return value of dbus_g_bus_get when you're finished with it
<cjwatson> it may be a global variable but it still has a reference count
<cjwatson> AFAICS
<cjwatson> and it's only global in the same way that dbus_bus_get returns a global, and its documentation says "The caller of this function owns a reference to the bus."
<debfx> doko: the new gcc upload makes virtualbox-ose ftbfs: http://paste.ubuntu.com/577138/
<debfx> should I open a bug report?
<doko> debfx: please do so, with the preprocessed source attached
<psusi> cjwatson: hrm.. then it is a bug that gpm-manager.c in g-p-m doesn't do that?
<doko> debfx: do you prepare the report?
<debfx> doko: I'm on it, what preprocessed source should I attach?
<doko> .i
<doko> build it with -save-temps
<janimo> cnd, yes. But I have the impression the diffs LP outputs are for the whole package not just debian/ diffs
<cnd> janimo, I'm looking at one of the patches in debian/patches
<cnd> it's an autogenerated patch from dh
<janimo> cnd, in that case I take back what I said
<cnd> it makes me wonder if the qt 4.7.2 merge is correct, since it often suggests that you've updated the tarball but not the package
<cnd> so the autogenerated patch ends up undoing all the changes
<janimo> cnd, now I see that patch too, indeed quite large
<janimo> cnd, did you see regressions because of that patch?
<cnd> janimo, no, I went to check the source
<cnd> and fix an issue with the xi 2.1 multitouch patch
<cnd> when I saw that huge thing
<debfx> doko: bug #730860
<ubottu> Launchpad bug 730860 in gcc-4.5 (Ubuntu) "virtualbox-ose fails to build due to an internal compiler error" [Undecided,New] https://launchpad.net/bugs/730860
<janimo> cnd, the first lines in it suggest it is autogenerated as a summary of upstream changes, but I don't know why it is included there
<doko> debfx: amd64 only?
<janimo> one of the Kubuntu folk may know, Riddell is away this week AFAIK
<janimo> ScottK, ^
<debfx> doko: haven't tested i386 yet
<cnd> janimo, the header of the patch is just autogenerated
<cjwatson> psusi: I guess so.  it may not be serious
<cjwatson> cnd: dpkg-source is what autogenerates the patch, not dh.
<cjwatson> (FYI)
<cnd> cjwatson, since you stepped into the conversation :), do you have any ideas as to how a 1+ million line patch could be generated?
<debfx> cnd: that patch should be dropped
<cnd> debfx, yes, but it's not as easy as just saying it should be :)
<cnd> the question is: how did it get there in the first place
<cnd> and is the package being built correctly
<debfx> cnd: either it's some 4.7.1 vs 4.7.2 mixup or the build process changed some files that weren't cleaned properly
<debfx> I've looked at the diffstat, there is nothing we want to keep
<cnd> debfx, yeah, so I'm thinking we need to wait till Riddell can take a look, since he's the one who updated to 4.7.2
<cnd> just to be sure
<psusi> hrm... I think I need to add an argument to org.freedesktop.UPower.Sleeping to say whether it's hibernate or suspend... hrm... now to figure out how to extract such an argument from a GVariant...
<bryceh_> @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: barry, bdmurray, bryceh_
<micahg> wow, 4 patch pilots in one day :)
<bryceh_> heh
 * micahg guesses it makes sense
<bryceh_> suspect a couple just forgot to log out
<micahg> Is there an AA to apply some overrides
<bryceh_> AA?
<micahg> archive adin
<micahg> *admin
<bryceh_> not me, bug cjwatson might still be around
<bryceh_> er, s/bug/but/
<ScottK> janimo: debfx is probably your best bet if Riddell isn't around.
<janimo> ScottK, ok
<janimo> cnd, ^ :)
<cnd> debfx, janimo: are either of you familiar with qt4-x11?
<cnd> I really don't know the regular maintainers of the package
<cnd> I just provided one patch
<cnd> so if you guys are the regular maintainers, then by all means have at it :)
<janimo> cnd, me too :)
<micahg> ScottK: can you apply archive overrides?
<ScottK> micahg: No.
<debfx> cnd: yes, what needs to be done? :)
<sbeattie> micahg: best to ask in #ubuntu-release.
<cnd> debfx, just figure out what's up with that odd debian patch
<cnd> make sure qt is building correctly
<psusi> oh boy, lots of patch pilots.. I wonder if my fixes to dmraid and parted will get merged today...
<psusi> does this look about right to register for a dbus signal? http://pastebin.ubuntu.com/577165/
<debfx_> rsalveti: do you have patches for the packages that broke by switching to gles in qt? bug #707794
<ubottu> Launchpad bug 707794 in koffice (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [High,Triaged] https://launchpad.net/bugs/707794
<rsalveti> debfx: not yet
<rsalveti> but plan to help porting all those packages
<MeltingKeyboard> Anything I can do to help?
<MeltingKeyboard> where would I look to find stuff to do?
<doko> TheMuso: ping
<doko> mterry: you accepted the wrong ones \o/ ;-P
<mterry> doko, yeah, sorry  :)
<mterry> those perl packages were delightfully well-maintained though
<arand> MeltingKeyboard: Harvest might be one place to look: http://harvest.ubuntu.com/ , I'm not completely sure what you're asking about though
<MeltingKeyboard> ok
<MeltingKeyboard> I will look there
<MeltingKeyboard> I was just wondering if there was something I could help with with the new release date looming
<MeltingKeyboard> thanks
<doko> mterry: so the missing symbols files are the only complaints?
<mterry> doko, and dbus-c++ is orphaned in debian.  Doesn't inspire confidence
<doko> mterry: sure, but we had it in main before
<mterry> doko, it was in main as part of another package, whose maintainer presumably took care of it, right?
<mterry> now no one claims to
<doko> and makes ubuntustudio uninstallable
<doko> or was it for mythbuntu?
<arand> MeltingKeyboard: https://wiki.ubuntu.com/UbuntuDevelopment is a more general overview. It may be a good idea to pick a specific area and engage the relevant people with your specific ideas about what you would help with.
<barry> @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: bdmurray, bryceh_
<soren> abhinav-: Sorry, what's the context?
<apachelogger> cjwatson: can I somehow get the pid of a process using libpipeline?
<doko> mterry: one is missing, which I didn't see.  please could you look at bug #729907 too?
<ubottu> Launchpad bug 729907 in libnet-domain-tld-perl (Ubuntu) "[MIR] libnet-domain-tld-perl" [Undecided,New] https://launchpad.net/bugs/729907
#ubuntu-devel 2011-03-08
<abhinav-> soren,  sorry for wrongly disturbing you. this stupid xchat does autocompletion whenever it wishes :-/
<bryceh_> kees, hmm did you put your mountall changes into bzr?
<kees> bryceh_: there is no bzr tree in debian/control for it. did I miss something?
<bryceh_> yeah, there is a bzr tree with a change from cjwatson
<bryceh_> (and an outstanding merge from me; I'd made the mistake of assuming bzr had current mountall changes)
<bryceh_> kees, no worries, I'll fix up
<bryceh_> (and fix up control)
<kees> bryceh_: argh, uncommitted in UDD? crap, sorry.
<kees> bryceh_: I'm still getting used to the idea of people developing in UDD without doing uploads.
<bryceh_> it's a bit weird for me too, although we've been doing this (in git) with X a while
<kees> yeah, for me, I just don't like having both the automatic upload stomping on the same tree as devel work
<kees> bryceh_: if you're not already in the middle of it, I can clean up my mistake; just let me know.
<bryceh_> already done
<kees> heh, cool.
<superm1> doko, mterry what was the package in question that's making mythbuntu uninstallable? i didn't see it mentioned in bt
<doko> superm1: dbus-c++ and libconfig, b-d's of libffado
<superm1> ah libffado isn't a direct rdepend of anything seeded - but it is of libjack-dev
<superm1> that will probably mess both mythbuntu and ubuntu studio then
<doko> see the two MIR's, I think both could need a version update and symbols files
<superm1> jack support isn't that important in mythbuntu though, so if yall decide jack support has to go for any reason, it's not that big of a deal to just disable it
<superm1> the studio guys might feel a bit differently
<doko> superm1: could you subscribe these groups to the reports?
<superm1> doko, sure what were the bug numbers?
<doko> looking ...
<kees> bryceh_: I double-checked it too and added the missing conf file.
<doko> superm1: bug #730759 and bug #730760
<ubottu> Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete] https://launchpad.net/bugs/730759
<ubottu> Launchpad bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete] https://launchpad.net/bugs/730760
<LLStarks> jcastro, is there any way to completely wipe unity settings?
<superm1> doko, okay subscribed.  in the meanwhile, i'll disable jack so that the builds stay installable for your archive rebuild
<doko> superm1: thanks, will look tomorrow if libffado can be demoted
<abhinav-> TheMuso, thanks for looking at my tomboy patch for bug 386893.
<ubottu> Launchpad bug 386893 in tomboy (Ubuntu) "Searching within a notebook should inform the user that no results were found within that notebook" [Wishlist,In progress] https://launchpad.net/bugs/386893
<abhinav-> I have replaced the messagebox with a label and buttons in the tomboy UI itself. I also posted in the tomboy mailing list, about the changes that I am making. There hasn't been much response :-|
<wip> almost done with packaging (.deb) my own application. i have all those dependencies for my application: http://pastebin.com/aTqQEciF (objdump -p ./myapp | grep NEEDED) do i need to list all (and how) in control depends. for example: libgmodule-2.0.so.0 how to write it in my control file: Depends:Â libgmodule-2.0 OR Depends:Â libgmodule-2.0.so.0 or...?
<highvoltage> wip: you probably want to ask that in #ubuntu-packaging or #ubuntu-motu
<wip> highvoltage: thx!
<highvoltage> wip: you're welcome
<abhinav-> barry, I pushed the changes for the tomcat6 bug , I requested another review :)
<abhinav-> could someone please give me the link for getting the latest build of natty ?
<abhinav-> I think I found it :)
<abhinav-> http://cdimage.ubuntu.com/
<c2tarun> need help with last comment of bug 730121 can anyone please tell do I have to make change in Makefile.in as well because changing only Makefile.am is not working.
<ubottu> Launchpad bug 730121 in btnx (Ubuntu) "pacakge btnx_0.4.11-3ubuntu1 failed to build from source" [Undecided,In progress] https://launchpad.net/bugs/730121
<geser> c2tarun: Makefile.in is generated from Makefile.am ; so you either regenerated it or what I do for simple changes is to patch both files (Makefile.am and Makefile.in) so the change doesn't get lost if someone later regenerates it
<didrocks> good morning
<geser> good morning
<pitti> Good morning
<dholbach> good morning
<ion> that
<c2tarun> geser: ping
<pitti> kees: publishing https://launchpad.net/ubuntu/lucid/+source/linux-ec2/2.6.32-314.27 to lucid-{updates,security}
<didrocks> ev: hey, when you have some time, can we discuss about bug #730588 (see the discussion on it)?
<ubottu> Launchpad bug 730588 in unity (Ubuntu) "Fallback from 3D should offer Unity 2D download as an option" [Medium,Triaged] https://launchpad.net/bugs/730588
<cjwatson> apachelogger: libpipeline tracks it internally, but there's no method to get pids externally right now.  could you file a bug with an explanation of what you're doing and what you need?
<cjwatson> kees: while the automatic upload may stomp on the same tree as development work, it moves any pending changes aside so that they can be restored easily
<cjwatson> bryceh_: urgh, I had some review comments on Surbhi's mountall branch :-/
<cjwatson> (problem with patch piloting: you have to be quick to grab something you actually want to substantively review ...)
<speakman> hi dev folks! This is the second computer having problem with gnome-session-daemon hanging (or dysfunction) on login. If you could tell me who to speak to, I can help tracing this bug as it hits every single time I log in.
<lag> Doh! I just competed a dist-upgrade, how my desktop is FBARed
<speakman> I've even got a 'bt full' available, but according to that it isn't supposed to be locked up. But it still doesn't die on SIGTERM for example.
<lag> s/how/now
<bryceh_> cjwatson, urp sorry
<lag> cjwatson: Hi Colin
<bryceh_> cjwatson, fwiw I did leave the two dmraid ones for you ;-)
<cjwatson> bryceh_: thanks, that's good
<cjwatson> lag: hi
<lag> cjwatson: Have you seen any bugs which allude to problems booting post-dist-upgrade?
<lag> cjwatson: The last think I see on my screen is: "*Starting TiMidity++ ALSA midi emulation..."
<lag> thing*
<cjwatson> lag: I fixed such a bug the other day
<cjwatson> bug 723482
<ubottu> Launchpad bug 723482 in alsa-utils (Ubuntu) "system hangs on boot after updates from 2011-02-22" [High,Fix released] https://launchpad.net/bugs/723482
<cjwatson> but that fix was last Wednesday
 * speakman having serious problems booting his RAID0 too. Two out of three times, it asks me to run the RAID0 degraded (how that's possible..). Even though dmesg tells me Linux has found both disks and both partitions.
 * cjwatson is not prepared to debug everyone's boot problems all at once :-)
<lag> cjwatson: :)
 * speakman is a developer himself, but won't invent the wheel if there's already some known issues.
<cjwatson> speakman: whatever your problem is is (a) entirely unrelated to what I was talking about (b) nothing I know about myself
<speakman> cjwatson: I see. Just joined so wasn't really aware of that's discussed.
<speakman> But is there a ubuntu gnome developer channel on freenode? My primary goal is to fix the gnome-session-daemon issue.
<cjwatson> #ubuntu-desktop
<speakman> Great, thanks!
<tdn> I am trying to report a bug in the amd64 version of the linux kernel. What package do I report it on?
<pitti> tdn: ubuntu-bug linux
<tdn> pitti, ok.
<tkamppeter> doko, hi
<cjwatson> apachelogger: I have a plausible-looking implementation of pipeline_get_pid now - if you file that bug, I can check whether it will meet your requirements
<SpamapS> cjwatson: btw, I have not forgotten your rpcbind diffs. Should be able to look at them soon.
<ara> cjwatson, did you find useful the list of system and splash screen videos?
<speakman> cjwatson: Do you know a certain channel for solving my raid0 issue described earlier?
<GunnarHj> dpm: Hi David, Thought I'd review and update the docs with respect to languages and locales including language-selector, but the only page I found was https://help.ubuntu.com/community/Locale. Are you aware of anything else?
<dpm> hi GunnarHj, what are you trying exactly to document?
<GunnarHj> dpm: Well, at first hand I'm thinking of a short manual for l-s (to the extent it's not obvious by the UI). Another thing is to explain how to make a more fine grained locales configuration, e.g. separate locales for date formats and numbers. Third I'm thinking of explaining where and how things are stored now, bearing those in mind who help with answering questions.
<dpm> GunnarHj, ok. Two things come to mind: either document it first on the wiki, or create a help document for language-selector. For the first one you can start straight away; for the second you might want to contact the docs team about how they work, the tools they use, etc.
<GunnarHj> dpm: That sounds reasonable. I take that neither you know of any other existing docs.
<GunnarHj> dpm: On another topic, since a few translatable text strings in language-selector were changed recently, shouldn't https://translations.edge.launchpad.net/ubuntu/natty/+source/language-selector/+imports show those strings? Is the time lag that long, or does it indicate that I missed something when updating language-selector?
<dpm> GunnarHj, on the first question: no, I don't know of any other documentation. There are some links here you could use as a reference -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Coding#Additional%20documentation, but they serve a bit of a different purpose
<cjwatson> SpamapS: don't worry too urgently about it - libtirpc/nfs-utils needs work in order to let us configure nfs-utils with TI-RPC support without breaking interoperability with portmap
<cjwatson> ara: I will find them useful, but have not started working through them yet
<cjwatson> speakman: no, sorry
<cjwatson> speakman: maybe #ubuntu-server I suppose
<GunnarHj> dpm: Yeah, that page rather shows what you need to do to turn a package to a package which is parsed for strings to be translated. Since l-s already is that kind of package, I thought it would work 'magically' already without doing anything special. Maybe I was wrong...
<dpm> GunnarHj, as for the 2nd question, that url ^ shows the status of the templates (or translations) imported. If it's empty, it means that either the templates or the translations have just been imported or that they haven't reached the queue yet. When was the package uploaded with the changes, and are they not in https://translations.launchpad.net/ubuntu/natty/+source/language-selector/+pots/language-selector/sv/+translate ? (you can use the search box i
<dpm> n there)
<GunnarHj> dpm: No, they are not there (checked it already). And according to https://translations.edge.launchpad.net/ubuntu/natty/+source/language-selector the last edit was made 2010-09-24.
<dpm> GunnarHj, could you point me to the package version which introduced them, and give me one of the strings that were modified in the source? (btw https://translations.launchpad.net/ubuntu/natty/+source/language-selector lists the last edit done by translators, it has nothing to do with the date the template was uploaded)
<dpm> <dpm> GunnarHj, could you point me to the package version which introduced them, and give me one of the strings that were modified in the source? (btw https://translations.launchpad.net/ubuntu/natty/+source/language-selector lists the last edit done by translators, it has nothing to do with the date the template was uploaded)
<YokoZar> What's the proper way for a package to demand the uninstall of a package before it starts installing?  I have a weird situation where if I uninstall foo and then install bar, it works fine, but if I install bar (which is a later version of foo!) it breaks
<YokoZar> Should I make the package conflict with earlier versions of itself?  Somehow that sounds absurd
<GunnarHj> dpm: These were two altered strings in language-selector (0.12), released on January 28:
<GunnarHj> Language &amp; Format
<GunnarHj> &lt;small&gt;Use the same language choices for startup and the login screen.\nChanges take effect only after a restart of the system.&lt;/small&gt;
<dpm> GunnarHj, btw, why did you use &amp; and &lt;?
<GunnarHj> dpm: I didn't introduce them. Think they are needed for GTK to do the right thing.
<GunnarHj> dpm: or maybe because it's XML...
<dpm> not sure why & and <> cannot be used, though
<dpm> anyway, let me have a look at the strings
<GunnarHj> dpm: Not sure about & and <> - didn't test.
<apachelogger> cjwatson: https://savannah.nongnu.org/bugs/index.php?32710 within the same context, would it be possible to get a function to write something on the pipeline (i.e. vpnc gets informatin from stdin unless one defines a config file)
<dpm> GunnarHj, the latest template seems to have &:
<dpm> #: ../data/LanguageSelector.ui.h:26
<dpm> msgid "Language & Format"
<dpm> msgstr ""
<dpm> pitti, I've just built language-selector locally and it didn't create a translations tarball (I've got pkgbinarymangler installed and striptranslations enabled). This might be why GunnarHj didn't see the template in LP being updated. Any hints on what could be happening?
<dpm> GunnarHj, btw, if you want to test this yourself, you can try this: https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/RecipeVerifyingTranslationUploads
<GunnarHj> dpm: In that case the changes resulted in new templates, at least...
<GunnarHj> dpm: Thanks for the tip on how to verify translation uploads.
<dpm> no worries :)
<pitti> GunnarHj, dpm: language-selector sets NO_PKG_MANGLE=1 in debian/rules
<pitti> GunnarHj, dpm: presumably we want language-selector .deb to include all translations, so that at least this program is translated into your language when you need to install missing langpacks
<dpm> pitti, ah, ok. So template changes are better uploaded manually, I guess.
<pitti> dpm: no, hang on
<pitti> dpm: see https://launchpad.net/ubuntu/+source/language-selector/0.6.6 changelog
<pitti> dpm: that's bug 654548
<ubottu> Launchpad bug 654548 in Ubuntu Translations "Language selector translation is missing from the final Maverick language packs" [High,Fix released] https://launchpad.net/bugs/654548
<pitti> dpm: I think we can just drop the NO_PKG_MANGLE
<dpm> pitti, ok
<pitti> verified that it's in the blacklist
<pitti> dpm: I'll upload a new package now
<dpm> cool, thanks pitti
<pitti> dpm: sorry for forgetting about it
<dpm> no worries!
<GunnarHj> pitti, dpm: Thanks for helping with this. Suppose it means that fresh templates with the latest changed strings will soon appear at Launchpad.
<pitti> they should; just uploaded 0.24
<GunnarHj> Great!
<brendand> hi,
<brendand> i have a HP Elitebook 6930p
<brendand> with a Radeon HD 3400 Series graphics card
<brendand> it is a complete disaster with natty
<brendand> there are so many problems i can't even isolate one to raise a bug
<dpm> pitti, ah, and another thing. While you are looking at the FF xpis to appear in the language packs, do you think you could look at that issue I was mentioning re: the FF translations having disappeared from the maverick+lucid langpack PPAs?. I just want to make sure it's in your radar, as I didn't report it as a bug or anything.
<brendand> i'm currently using classic desktop (no effects)
<brendand> which is just about stable
<pitti> dpm: would you mind reporting it as a bug against langpack-o-matic? I'm working on something else ATM, and still need to wait for the new firefox XPIs to get relaseed anyway
<brendand> does anyone else have any experience with this card?
<cjwatson> apachelogger: if you use pipeline_want_in (p, -1), then you can call pipeline_get_infile (p) after the pipeline is started and write to that.  Is that what you need?
<brendand> it's not really support. i'm wondering have ATI cards ever been tested
<dpm> pitti, sure, bug 731298
<ubottu> Launchpad bug 731298 in langpack-o-matic "Untranslated Firefox in the Maverick and Lucid language pack PPAs" [Undecided,New] https://launchpad.net/bugs/731298
<jhunt> cjwatson: thx for merging https://code.launchpad.net/~jamesodhunt/ubuntu/natty/vim/add-upstart-syntax, however we've got a FTBFS: "internal compiler error" (i386).
<Daviey> jhunt, Is this part of a master plan to wean people off i686?
<jhunt> :)
<apachelogger> cjwatson: sounds like it, I will give it a try later, thank you :)
<cjwatson> jhunt: hmm, that would be a doko question
<smoser> cjwatson, i'd like your opinion on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/731307
<ubottu> Ubuntu bug 731307 in grub2 (Ubuntu) "change to /etc/default/grub causes prompt on grub-pc upgrade" [Undecided,New]
<cjwatson> smoser: sorry, later, am still patch piloting
<cjwatson> drat, forgot to add myself to the topic, oh well too late
<SpamapS> slangasek: ping, when you are around, could you confirm bug #726348 and review the fix .. I filed it based on your comments and I'd prefer not to confirm my own bug report. :)
<ubottu> Launchpad bug 726348 in squid (Ubuntu) "squid's maintainer scripts call start/stop directly instead of using invoke-rc.d" [Undecided,New] https://launchpad.net/bugs/726348
<jhunt> doko_: FYI, I've raised bug 731327 on the gcc internal compiler error issue just mentioned.
<ubottu> Launchpad bug 731327 in gcc-4.5 (Ubuntu) "vim FTBFS with natty gcc on i386" [Undecided,New] https://launchpad.net/bugs/731327
<cjwatson> SpamapS: FYI, holding off on your upstart branch because jhunt has a big merge in progress
<doko_> jhunt: known, preparing a fix
<jhunt> doko_: thanks!
<SpamapS> cjwatson: ah the 1.0 commeth? ;)
<cjwatson> SpamapS: 0.9.1
<tjaalton> is there a way to keep packages in main other than keeping deps on them?
<cjwatson> tjaalton: seed them
<tjaalton> cjwatson: ok. just wondering about dropping some xorg drivers to recommends like they are in debian, and whether it's worth it or not
<tjaalton> probably not at this point of release
<cjwatson> tjaalton: Recommends keeps things in main too
<cjwatson> smoser: commented
<tjaalton> cjwatson: ah ok, well I'll postpone it anyway and we'll revisit it for OO
<smoser> cjwatson, the issue is that a major use-case is for apt-get upgrade to be run un-attended on boot of the image (or at least at some point)
<smoser> so a prompt will completely block that
<cjwatson> smoser: I know, but I don't know how to fix your problem ...
<cjwatson> (without making the already horrible configuration file handling even worse)
<cjwatson> smoser: I suppose you could try to figure out why GRUB_TERMINAL=console is needed
<smoser> but what about GRUB_HIDDEN_TIMEOUT_QUIET ? and isn't this problem larger than me? doesnt it affect anyone who changes that file ?
<cjwatson> smoser: I commented in the bug about that part
<cjwatson> smoser: by design, if you change a configuration file and it is also changed in the package, you get prompted
<cjwatson> smoser: I'm not concerned about a larger problem heree
<cjwatson> *here
<psusi> cjwatson: what's a DEP-3 patch header?
<Ampelbein> psusi: http://dep.debian.net/deps/dep3/
<psusi> nevermind, just found the answer ;)
<cjwatson> psusi: I even gave you that link in the review :-/
<cjwatson> (maybe only in one of them ...)
<cjwatson> I wrote the dmraid review first, maybe read that first
<psusi> cjwatson: also, about the mutual Breaks: I was thinking... the change is actually only incompatible with the previous natty release where we added the 'p' all the time.  Since the 'p' is now only added if the previous character was a digit, then it is compatable with oder versions
<psusi> cjwatson: so should I only breaks that one version, or not bother since it was only during development cycle?
<cjwatson> psusi: personally I'd just add the Breaks anyway if it was me
<cjwatson> in this case it's not going to hurt to be overly strict, and it saves having to think about more interoperability cases
<psusi> true
<psusi> hrm.. I wonder then, if I should also add a Breaks: for old versions of gparted to parted?
<doko_> bdrung: lintian: Missing build dependencies: perl (>= 5.12)
<bdrung> doko_: i am asking myself why i didn't stumbled over it
<bdrung> doko_: what can i do to solve it?
<doko_> please don't sync perl
<cjwatson> psusi: I don't know
<YokoZar> Would merging in experimental gnome-games from Debian be appropriate?
<YokoZar> It was released in October
<pitti> YokoZar: you should coordinate with robert_ancell aobut that
<YokoZar> pitti: gnome-games maintainer?  Debian dev?
<pitti> YokoZar: gnome-games upstream and Ubuntu maintainer
<YokoZar> pitti: Ahh ok.  Long story short I was updating the branding package and I noticed that the background for solitaire disappeared entirely in Maverick (and is still gone in Natty)
<cjwatson> bdrung,doko_: the build-dependency is perl (>= 5.12) | libtest-simple-perl (>= 0.93), and libtest-simple-perl 0.96-1 is in natty
<cjwatson> doko_: get a better build-dependency resolver? :)
<doko_> cjwatson: tell it launchpad ;p
<cjwatson> doko_: I'm surprised that's a problem in Launchpad; I distinctly remember working with lamont way back in 2004 or so to teach sbuild to fall back to second and subsequent alternatives in build-dependencies
<doko_> cjwatson: https://edge.launchpad.net/ubuntu/+source/lintian/2.5.0~rc1ubuntu1/+buildjob/2283540
<cjwatson> yes, I see it
<doko_> ahh, ok
<cjwatson> perhaps it can't cope with that when the first alternative is merely insufficient-version rather than missing
<cjwatson> well, simple fix, just drop the first half of that alternative for the time being
<micahg> cjwatson: I have a bug open for that dependency issue
<micahg> bug 594916
<ubottu> Launchpad bug 594916 in Launchpad Auto Build System "buildd doesn't correctly check versioned ORed build-dependencies" [High,Triaged] https://launchpad.net/bugs/594916
<ari-tczew> doko_: did you fresh rebuild already?
<ari-tczew> with reverted binutils-gold
<doko_> ari-tczew: I don't know what you are talking about
<ari-tczew> doko_: https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032634.html
<doko_> ari-tczew: this is nothing to do with binutils-gold. and no, no rebuild started
<ari-tczew> doko_: what's the difference between linking in binutils-gold and --no-add-needed?
<ari-tczew> janimo: could you forward your patch for axis2c to Debian in order to keep in sync with Debian?
<doko_> gold is a different linker, which happens to default to --no-add-needed
<psusi> cjwatson: if other quilt patches apply but with some offset, should I refresh them, or leave them be?
<ari-tczew> doko_: if I'm fixing ftbfs with 'undefined reference to...' how should do I describe it? ftbfs with binutils-gold or rather --no-add-needed?
<doko_> it depends on the error message. it can be caused by --as-needed too
<cjwatson> psusi: I would refresh them
<barry> doko_: bug 719206 can be fixed by uploading my scons 2.0.1-1 merge and doing a no-change rebuild upload for csound.  merge proposal: https://code.launchpad.net/~barry/ubuntu/natty/scons/scons-2.0.1/+merge/52571
<ubottu> Launchpad bug 719206 in csound (Ubuntu Natty) "import (and examples) fail" [Medium,In progress] https://launchpad.net/bugs/719206
<doko_> see http://wiki.debian.org/ToolChain/DSOLinking
<ari-tczew> doko_: should do we still fix these ftbfs if you've reverted it?
<barry> doko_: i can put some source packages on chinstrap if you prefer
<barry> doko_: would you do the uploads for me?
<doko_> yes, and I didn't revert the ld --no-add-needed default
<doko_> barry: on chinstrap?
<barry> doko_: i haven't yet, but i can
<barry> doko_: % scp scons_2.0.1-1* chinstrap:
<barry> scons_2.0.1-1.debian.tar.gz                   100% 6897     6.7KB/s   00:00
<barry> scons_2.0.1-1.dsc                             100% 1832     1.8KB/s   00:00
<barry> scons_2.0.1-1_source.changes                  100% 2216     2.2KB/s   00:00
<barry> scons_2.0.1-1_source.ppa.upload               100%  307     0.3KB/s   00:00
<janimo> ari-tczew, upstream axis2c seems to have fixed the bug in their trunk
<micahg> barry: why isn't scons a ync?
<micahg> *sync
<barry> micahg: yeah
<janimo> ari-tczew, feel free to ping debian though - are they not following merge-o-matic or some similar output?
<micahg> barry: so, you should just use requestsync for it and it'll be brought into natty later this week
<ari-tczew> janimo: it's rare case when maintainer takes a look on Ubuntu delta. btw. merge-o-matic is broken.
<micahg> barry: you probably need an FFe as well
<barry> micahg: i won't be around to verify it later this week though since i'm at pycon for 10 days starting tomorrow
<barry> an FFe for a micro release update?
<janimo> ari-tczew, that is sad. As it would help a lot in avoiding manual work to subscrobe to the LP packages they maintain in Debian.
<micahg> barry: yes, unless it has an exception since it's in main
<ari-tczew> janimo: I don't understand what do you mean, sorry.
<barry> micahg: i'll get the ball rolling but someone else is going to have to follow through with both scons and csound bugs.  i'll assign them to doko_ after i do what i can
<doko_> barry: so I can sync it?
<janimo> ari-tczew, if a debian maintainer subscribed to the LP notifications concerning their packages they could fish out interesting thigs themseleves
<janimo> and not requiring ubuntu devs to explicitly forward everything
<janimo> makes sense especially for a lot of universe stuff which we do not usually patch
<ari-tczew> janimo: feel free to suggest him it :)
<barry> doko_: sync'ing scons to debian testing version, then no-change rebuild of csound after that lands will fix the csound bug
<cjwatson> ari-tczew: merge-o-matic will be fixed soon, I have it nearly fixed now
<ari-tczew> cjwatson: ok nice :) would be nice if you could inform it via lists - I've opened a thread for this case.
<cjwatson> yeah, I'll mention it on -devel
<cjwatson> (the MoM downtime was a combination of a dpkg bug-fix that needed to be backported, and then casey running out of disk space again - both fixed now)
<YokoZar> mvo: what does X-AppInstall-Popcon=#### do in a .desktop file in app-install-data?
<YokoZar> (these days)
<YokoZar> If it is what I think it is, is that data being autoregenerated still?
<ivoks> i have serious issue to report; latest dist-upgrade is telling me that it will remove 'vim'; that's a critical bug :)
<cjwatson> known build failure
<cjwatson> probably resulted in bits of vim being out of sync across architectures
<cjwatson> 14:09 <doko_> jhunt: known, preparing a fix
<ivoks> but it was very funny :)
<cjwatson> bug 731327
<ubottu> Launchpad bug 731327 in gcc-4.5 (Ubuntu) "vim FTBFS with natty gcc on i386 (dup-of: 730860)" [Undecided,New] https://launchpad.net/bugs/731327
<ubottu> Launchpad bug 730860 in Linaro GCC "[regression] ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1861" [Medium,Triaged] https://launchpad.net/bugs/730860
<cjwatson> (bug status alone isn't very clear - from the bug history, I believe that's now worked around for natty)
<lamont> cjwatson: I'm pretty sure that the sbuild hackery didn't take versioned build-deps into account... since perl exists, it gets picked, even though it's verison is insufficient
<lamont> at least iirc
<terlmann> Let's say you had a package that didn't have a newer version available because of  developer circumstances. It is needed by the user because of their usage circumstances. It relies on core libraries that the user wanted to upgrade to newer versions, like gtklib from 2 to 2.9/3.
<terlmann> Could you add logic to your apt chain of tools to automatically detect such "dead-end" packages and sandbox them with the specific dependencies that would differ from the new packageset in a /opt chroot, until such time as they can be upgraded?
<NCommander> doko_: directhex: ping, do we have a VCS for mono's packaging on ARM? I found the Debian git repo, but I can't find something for Ubuntu
<doko_> NCommander: I don't have one
<directhex> NCommander, nothing ubuntu specific
<NCommander> doko_: so you just uploaded the package directly? (I have patches to mono to help fix it with SMP+Thumb2)
<directhex> NCommander, generally, ubuntu things can go into git branches, although you won't have write access to that repo
<pitti> dpm: ah, the new natty langpack build just finished
<NCommander> directhex: I don't even see an ubuntu branch for that git repo
<Laney> could the patch not go into Debian?
<pitti> chrisccoulson: ^ FYI; so I'm ready to build new packs whenever we have a decision what to do with the xpis
<Laney> . o O ( or upstream )
<NCommander> Laney: mono on Debian moving to 2.10 which has this properly fixed in git
<directhex> NCommander, we don't have any ubuntu specific things that we're tracking in debian right now.
<Laney> oh, they're upstream already â great
<dpm> pitti, ah, what does it look like? Does it come with FF translation goodness? :-)
<NCommander> the backport to 2.6 is complicated since it only should be applied to ARMv7
<NCommander> 2.10 has a nice mechanism to handle that
<NCommander> 2.6, not so much
<pitti> dpm: no, I didn't enable po2xpi
<pitti> it's still broken (and it wasn't used before either)
<NCommander> Laney: the SMP partch should be acceptable for Debian but I don't ahve any hardware to properly test it
<Laney> I'd use the UDD branches, or you can push mono.git to github
<Laney> and create a branch there
<NCommander> directhex: we have a ubuntu1 version on Ubuntu
<chrisccoulson> pitti - we should use the new rc1 xpi's from ftp://ftp.mozilla.org/pub/firefox/nightly/4.0rc1-candidates/build1/linux-i686/xpi/
<chrisccoulson> (i shall be uploading RC1 later this week)
<pitti> chrisccoulson: I thought they'd have a too tight version?
<pitti> chrisccoulson: ah, you mean they'll actually work until the final, and we only need to update them then
<chrisccoulson> pitti - yeah they do. for now, we'll either need to mangle the maxVersion in them, or we could ship them as they are and update them later
<Laney> NCommander: from the mono group POV it was syncable. A Ubuntu developer then uploaded it and made this not so any more. Thus there is no Ubuntu branch from our side.
<directhex> NCommander, perhaps, but we didn't put it there
<chrisccoulson> either way will work fine for now
<pitti> chrisccoulson: ack; so, I'll update my po2xpi branch with them now, can you merge afterwards?
<chrisccoulson> pitti - sure, no problem
<directhex> NCommander, to an extent, it doesn't matter - we're working on 2.10 in debian, so 2.6-specifics are a bit meh
<NCommander> directhex: so the basic answer is, just upload with the backports from upstream
<psusi> what's the difference between Conflicts: and Breaks:?
<Laney> and if you want, make a branch and get us to pull it
<directhex> NCommander, if the changes are upstream in 2.10, then yeah
<NCommander> Laney: if your on 2.10.1, you should get it for free
<Laney> yep
<NCommander> cool
<NCommander> That makes my life MUCH simplier
<directhex> Laney, won't there be automatic bze branches we can cherry pick from?
<Laney> dunno
<pitti> seb128: calendar> sometimes I do (evo sometimes seems to just forget about them), but right now they all work
<seb128> pitti, the indicator is still empty?
<Laney> NCommander: Yeah, just to track the Ubuntu stuff on alioth. We do it for other packages, but whatever it's not so important here
<pitti> seb128: yes, clicking on it opens an 1-pixel empty menu
<seb128> pitti, usually it means it's crashing, https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/724856 most likely
<ubottu> Error: Bug 724856 is private
<Laney> psusi: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
<pitti> seb128: checking
<seb128> pitti, try turning off you gcalendar in evo
<seb128> just to see
<Laney> Breaks means the broken package must be deconfigured, Conflicts means it must not be on the system at all
<pitti> seb128: yes, no indicator-time-something
<seb128> pitti, is indicator-datetime installed?
<pitti> seb128: confirmed; running /usr/lib/indicator-datetime/indicator-datetime-service crashes immediately
<pitti> seb128: thansk!
<seb128> pitti, is that the same crash?
<dpm> pitti, so what is this new langpack build going to be? A -base refresh without the xpis?
<pitti> dpm: no, -base with xpis
<pitti> dpm: but the upstream ones (as we used to do in all releases so far)
<pitti> seb128: need some debug symbols, hang on
 * psusi goes with Conflicts
<Laney> breaks is usually sufficient
<dpm> pitti, yeah, that was my question earlier, I should have rephrased it a bit clearer. So regardless of whether they are upstream ones or LP ones, we will have a localized Firefox after this langpack update I understand?
<pitti> dpm: correct
<chrisccoulson> dpm - we will do once we get ff4.0rc1 in the archive
<psusi> I don't see what difference it really makes whether the package is just unconfigured or not... if the library is installed, then it's installed
<pitti> seb128: ah no, your's is an FPE, mine is a SEGV
<chrisccoulson> (the new xpi's won't work with b12, but there's no point in uploading b12 xpi's now)
<dpm> chrisccoulson, ah, ok, understood
<pitti> seb128: in update_appointment_menu_items(); looking for an existing bug, or filing one
<doko_> janimo: do you want to join robbiew's server team, now starting to fix server bugs? ;P
<chrisccoulson> pitti - i think i might get the same crash as you then ;)
<chrisccoulson> (although, i didn't debug it yet)
<chrisccoulson> but i get a SEGV on start
<seb128> pitti, likely bug #729444
<ubottu> Launchpad bug 729444 in Indicator Date and Time "indicator-datetime-service crashed with SIGSEGV in update_appointment_menu_items()" [Medium,Triaged] https://launchpad.net/bugs/729444
<seb128> bug #729175
<ubottu> Launchpad bug 729175 in indicator-datetime (Ubuntu Natty) "valgrind invalid read" [High,Triaged] https://launchpad.net/bugs/729175
<seb128> ^ that's a valgrind log I did some days ago which is likely the same issue
<pitti> seb128: correct
<janimo> doko_, nah, it just happens I get bugged by some packages :)
<dpm> pitti, ah, cool, thanks. We did use po2xpi for some languages, though. For example until ast was accepted upstream it was built with po2xpi.
<seb128> chrisccoulson, if you want to have a go to it please do
<NCommander> directhex: For the sake of mantience, I'll put these on the UDD branch for mono.
<seb128> chrisccoulson, klattimer is off tonight until the end of the week
<janimo> since it was on server list it appeared more than once in the ftbfs report, so I think that is why I went for axis2
<NCommander> as I don't feel like adding a patch system to the mono package
<chrisccoulson> seb128 - ok, will take a look once i've figured out the other menu issues
<seb128> chrisccoulson, thanks
<pitti> dpm: right; we only have fi and oc on the whitelist, though
<janimo> NCommander, narrowed down the mono issue? Something besides memory barriers?
<dpm> pitti, ack. yeah, just pointing out that po2xpi was not entirely useless :)
<pitti> dpm: no, to the contrary; but it is broken right now, so I'm afraid we can't use it just now
<NCommander> janimo: more I just got around to finally getting everything to the point I'm ready to cook a test package
<janimo> NCommander, based on 2.6 ?
<dpm> pitti, yeah, sure, I understand. I just wanted to point that out
<dpm> pitti, another question: I've been asked this on gnome #i18n. Could you tell me if it's correct? -> http://paste.ubuntu.com/577519/
<NCommander> janimo: yeah
<pitti> dpm: that's correct, it's rather easy to include them
<dpm> pitti, I guess the easiest thing is to file a bug requesting a package update? Or what would be your recommendation?
<rollo>  hi pitti
<pitti> dpm: yes, with a pointer to the upstream bugs
<dpm> pitti, ok, thanks a lot, I'll go ahead and do that, then
<pitti> dpm: I'd appreciate if you (or the submitter) could subscribe me, for faster processing
<OraLinda> Hi all
<pitti> hey rollo
<dpm> pitti, ok, will do
<OraLinda> How are you guys doing ?
<OraLinda> Tell me, where can I get the source for the gorgeous libvisual plugin infinite I can see running in Totem visualization?
<NCommander> OraLinda: apt-get source totem-plugins
<NCommander> OraLinda: run that on command line. That should put you on the right track, although I'm not sure if that plugin is in totem-plugins or another package
<OraLinda> Thanks. Let me have check.
<cnd> stgraber, cody-somerville, bdrung: I just tried to upload utouch-geis, but was rejected
<cnd> does some bit need to be twiddled somewhere?
<pitti> cnd: upload ACLs need to be set in Launchpad, yes; was that recently approved by DMB?
<cnd> pitti, yes at the last dmb meeting
<cnd> a utouch package set was created
 * pitti checks
<pitti> nope, no ACL set for utouch-geis
<cnd> pitti, this was the package set approved: https://wiki.ubuntu.com/Multitouch/uTouchPackageSetApplication
<pitti> cnd: there is no "utouch" package set right now; could it be spelled differently?
<pitti> or perhaps it wasn't created yet
<pitti> cnd: is your LP ID "cnd"?
<pitti> it's not
<cnd> pitti, chasedouglas
<pitti> cnd: you currently can uplaod linux-firmware, linux-firmware-nonfree, and trace-cmd
<cnd> pitti, that's correct
<pitti> cjwatson: can/should I run "./edit_acl.py -P utouch -S natty add"? or does it require special magic on your side?
<cjwatson> create rather than add, I think
<cjwatson> and then add packages to it
<pitti> cjwatson: so it's (1) create package set, (2) add packages and people with "add"?
<cjwatson> yeah
<cjwatson> the owner should, I assume, be developer-membership-board
<tkamppeter> pitti, I have a question. There is bug 731420
<ubottu> Launchpad bug 731420 in hplip (Ubuntu) "printer hp deskjet 2050 j510 impossible to install also when turning on must go to recovery mode and use startx because it reports low mode" [Undecided,New] https://launchpad.net/bugs/731420
<tkamppeter> pitti, have you any idea what this "low mode" is?
<pitti> tkamppeter: I assume it's the 640x480 VESA mode that X.org falls back to if the real driver (such as nvidia) doesn't work
<tkamppeter> pitti, for me it looks more like a problem of X and not of the printer.
<pitti> cnd: ok, I created the package set with the minimal contents (you as member, and utouch-geis); try uploading again?
<cnd> pitti, will do, thanks!
<cnd> pitti, it was accepted this time :)
<pitti> cjwatson: does http://paste.ubuntu.com/577541/ look reasonable to you?
<cjwatson> pitti: yep
<doko> bdrung: now a real lintian build result ... ftbfs ;-P
<kees> pitti: lucid linux-ec2 2.6.32-314.27> noted, thanks
<bdrung> ups
<mvo> YokoZar: its still auto-generated at package build time
<abhinav-> barry, I have pushed the changes on the tomcat6 branch. and hope you have a great time at Pycon :-)
<mvo> YokoZar: but its (much) less interessting nowdays
<YokoZar> mvo: even for the static entries?
<YokoZar> eg in menu-data-additional
<mvo> YokoZar: it should be auto-generated for that too
<mvo> unless there is a bug of course?
<YokoZar> nah, I was just wondering since I'm changing package names in those files and using the wrong data, but if it gets replaced as soon as it builds who cares
<cjwatson> barry: sigh, now this wubi bug has got to the point where I'm emulating x86 code by hand :-/
<cjwatson> (assembly)
<RoAkSoAx> \/win 2
<bdrung> tumbleweed: let's wait until u-d-t migrated to testing and then upload 0.120
<lool> pitti: Oy; gdb builds started failing with unrelated changes, it seems to be in the documentation de-duper logic; e.g. http://launchpadlibrarian.net/65878156/buildlog_ubuntu-natty-amd64.gdb_7.2-1ubuntu9_FAILEDTOBUILD.txt.gz
<lool> pitti: I copied the previous version of the source which built fine in natty some time ago into my PPA, and it failed to build too
<lool> This is with cdbs 0.4.90ubuntu6
<lool> pitti: is this something you saw on other packages?
<lool> Ok, I think it's gdb's symlink in parallel builds which confuses cdbs
<pitti> lool: (sorry, busy; will have a look tomorrow, have a tab open for it now)
<pitti> lool: I haven't seen it on other packages so far
<lool> pitti: gdb is creating some gdb-foo -> gdb symlinks below usr/share/doc before gdb dir exists (built in parallel too)
<lool> pitti: I'm going to test a change in cdbs to skip creation of symlinks below usr/share/doc/$(cdbs_curpkg) if that's a symlink
<pitti> lool: ah; dir symlinks are really evil, packages shouldn't do that (due to dpkg's special handling of symlinks)
<pitti> lool: but that's something that should be testable
<pitti> lool: indeed, if any dir along the path is a symlink, it should skip its own thing
<pitti> lool: merci
<terlmann> Hey people.
<highvoltage> hey terlmann
<terlmann> You know google's new l33t compression tool that they're using to diff assembly for binaries?
<terlmann> What if we precompiled all our mono binaries from bytecode to each of the possible ~40 architectures and just kept one basic binary+diffs, to save memory space ?
<terlmann> Then they wouldn't need to be built jit.
<YokoZar> uhhh
<till_> i'm building a package and it relies on one of my other packages. how do i tell launchpad that this is a valid build dependency?
<SpamapS> slangasek: thanks for the triage ;)
<SpamapS> till_: you upload the other package into the PPA
<till_> SpamapS: i did that, of course. but when i upload the other package, it still complains that it doesn't know about the other package
<SpamapS> ETOOMUCHINDIRECTION
<SpamapS> till_: package A build-depends on package B, yes?
<till_> yeah
<till_> i'm doublechecking the ppa :x
<SpamapS> till_: Then B must precede A into the PPA.
<till_> ok, good to know
<SpamapS> till_: if B also build-depends on A, then you have to play a trick and upload one before the other w/o the build-depend in the control file, and which embeds whatever it needs.
<till_> yeah, makes sense
<till_> if it works if both are in the same ppa, let me doublecheck that the one the other depends on was build first.
<slangasek> SpamapS: n/p :)
<broder> jhunt: you wanted that merge proposal to be against lp:ubuntu/gdm, not lp:gdm
<davidm> OK coffee time
<tumbleweed> bdrung: sounds good to me
<jhunt> broder: thx - can you be manifest? I cannot push it to lp:~jamesodhunt/ubuntu/gdm/blah ("No such distribution series")
<broder> lp:~jamesodhunt/ubuntu/gdm/natty/blah :)
<jhunt> broder: so there is no way to push to the "upstream ubuntu" branch"? (presumably because that points to the latest release (natty)?)
<jhunt> broder: this is confusing because the branch I branched from was: lp:~ubuntu-desktop/gdm/ubuntu.
<broder> jhunt: lp:ubuntu/foo is an alias for lp:~ubuntu-branches/ubuntu/natty/gdm/natty (where the last natty is an "arbitrary" identifier a la blah)
<jhunt> not very symmetrical, or am I missing something?
<broder> in user branches (i.e. with a ~), the second component is the project. if the project is ubuntu, the third component must be a distribution series. the last component is an arbitrary tag you give the branch
<broder> so lp:~ubuntu-desktop/gdm/ubuntu is a branch off of the gdm project, and ubuntu is their arbitrary tag
<broder> jhunt: on the actual patch itself, is this going to cause any of the pain around mixing and and or in a start on block? and do we ever have to worry about switching from runlevel S but not having dbus/filesystem/etc?
<jhunt> broder: take 15: This works (not it is not the same as your example above): bzr push lp:~jamesodhunt/ubuntu/natty/gdm/ubuntu-desktop-single-user-mode-fix
<broder> jhunt: where the branch goes is less important than proposing a merge into the same branch you started from
<jhunt> broder: thanks very much for your help - your explanation is clearer than any other I've seen!
<jhunt> broder: please tell me I've pushed the right branch to the right place now or I may have to open a bottle of something strong... :)
<broder> so the diff is still massive. i think i may have given you bad advice when i said to merge into lp:ubuntu/gdm. if you branched from lp:~ubuntu-desktop/gdm/ubuntu, you should merge back into that
<broder> if you look at the diff on https://code.launchpad.net/~jamesodhunt/ubuntu/natty/gdm/single-user-mode-fix/+merge/52610, it's, like, the entirety of the repository, which is something of a red flag
<bdrung> tumbleweed: "pull-debian-source lintian experimental" fails
<tumbleweed> bdrung: aah, that's easy :)
<bryceh_> @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: bdmurray
<bryceh_> bdmurray, still piloting?  ;-)
<ari-tczew> I guess bdmurray has forgot to do out from piloting. May topic needs fixing manually?
<bdmurray> @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:
<tumbleweed> bdrung: that commit should have fixed it
<bdrung> tumbleweed: maybe put is_suite into DistroInfo?
<bdrung> tumbleweed: confirming that your commit fixes my issue
<tumbleweed> bdrung: yeah, that probably is a good idea. However it's by no means perfect (there isn't an experimental-p-u :)
<bdrung> tumbleweed: yes, but experimental-p-u isn't a good name for a version ;)
<tumbleweed> well, there isn't an unstable on either
<tumbleweed> but yeah, experimental on its own makes moving it there complex
<till_> SpamapS: thanks again, the correct order worked!
<SpamapS> till_: w00t
#ubuntu-devel 2011-03-09
<psusi> cjwatson, still not had a chance to look at the logs and figure out the partman-auto problem?
<cjwatson> psusi: I'm focusing on a wubi bug at the moment; it's taking a lot of attention
<psusi> oh joy
<cjwatson> I'll try to look at your bug next
<psusi> I also made those cleanups you wanted for the two branches to merge... I used Conflicts instead of Breaks though, that ok?
<cjwatson> no, please use Breaks
<cjwatson> Conflicts << is generally bad
<cjwatson> nowadays the policy manual has explicit language about when you should use Conflicts and when Breaks
<psusi> hrm... why is that?  I read that the difference is that breaks still allows the other package to be installed, just not configured... well who cares of dpkg thinks it is configured or not, if the lib is there, it's going to be used and thus, cause breakage, won't it?
<cjwatson> see the policy manual
<cjwatson> I won't merge a branch that uses Conflicts
<cjwatson> (in this way)
<cjwatson> it makes apt's job unnecessarily harder on upgrade
<psusi> hrm...
 * psusi runs and changes the Conflicts to Breaks
<cjwatson> thanks for making the other cleanups; I haven't looked at them yet for much the same reason
<psusi> changed Conflicted to Breaks and pushed... man I love emacs
<psusi> honestly, how does gnome-system-monitor manage to burn through ~20% of the cpu when audacious playing mp3s doesn't even register as 1%...
<azeem> playing mp3s is a common hw-accelerated operation, no?
<psusi> azeem, no
 * psusi remembers winamp using 90% of his 90 MHz pentium cpu, hehe.... come a long way since then...
<azeem> psusi: pentiums didn't have hw-acceleration, no?
<psusi> azeem, hw-acceleration is a function of... hardware... like a 3d video card... mp3s are decoded in software still... even idling alone at the low power 1.6 GHz state, this core i5-2500k is something like 100 times faster than that p-90... then you throw in the fact that it's got 4 cores... and somehow gnome-system-monitor manages to use a significant chunk of that... go figure.
<TheMuso> psusi: I've found that gnome-system-monitor has been a CPU hog in the past too, no idea why though.
<directhex> the cpu meter drawing algorithm is abysmal?
<psusi> do I have to create a dedicated proxy object to use dbus_g_proxy_connect_signal(), then attach a signal handler to that proxy object, or can I use an existing gobject class that already has the desired signal handler and pass that AS the proxy to dbus_g_proxy_connect_signal?
<directhex> that's the true answer btw. gnome-system-monitor is so slow because the resources graphs are written in about the most idiotic way they could be. see also http://audidude.com/?p=404
<psusi> nothing like blaring loud rock ( Korn ) on a hacking session while the wife is out seeing a play with a friend
 * RAOF prefers Cowboy Bebop for hacking.  Or Radiohead when cooking up an undodly abomination unto nature of a regex, like now.
 * StevenK is hacking LP while listing to Rammstein
<StevenK> Er. Listening
<RAOF> Not drunk-hacking? :)
<StevenK> No, just having my brain going faster than my fingers. Like usual.
<RAOF> Hm.  dpkg-buildpackage is suggesting that missing build-deps is going to become a fatal error for -S in the future.
<RAOF> That would be annoying.
<StevenK> Indeed
<StevenK> I routinely build source packages with only debhelper installed.
<psusi> ohh, Rammestein... there's something I've not listened to in quite some time...
<RAOF> Run along now evolution.  Daddy wants his 2GiB back for the build tmpfs.
<hallyn> I compiled my own version of open-vm-dkms (using sbuild -d natty -A *.dsc), but installing the resulting open-vm-dkms*.deb gives me:
<hallyn> This package appears to be a binaries-only package you will not be able to build against kernel 2.6.38-5-generic since the package source was not provided
<hallyn> i don't know what htat means
<StevenK> RAOF: Thunderbird is only taking up 1GiB here
<RAOF> Yeah, I've tried Thunderbird in the past.  I've always found it to be just a little bit more crap than Evolution.
<StevenK> Maybe we just should just ship mutt at the default MUA.
<psusi> odd... my tibrd process only has 121m rss atm... and I have a LOT of very LARGE mailboxes ;)
<StevenK> My thunderbird's RSS is 300MiB, but virtual is a touch over 1GiB
<psusi> I have been wondering lately why so many processes seem to have such massive virtual sizes when rss is reasonable
<RAOF> Leprachauns.
<TheMuso> Interesting discussion at a time when I am poindering trying anothe email client for a bit...
<TheMuso> pondering
<TheMuso> And evolution is off the list already...
<psusi> I keep meaning to make myself try mutt
<TheMuso> ...and xul apps are off the list, as they perform poorly with Orca atm.
<StevenK> TheMuso: I suggest telnet
<TheMuso> StevenK: lol
<maco> TheMuso: and kmail as well of course....
<TheMuso> maco: Of course...
<maco> oh right! there's a qt at spi tarball im supposed to turn into a package soonish
<TheMuso> I was thinking about Claws actually, as its GTK based.
<psusi> then again, I find myself getting sucked more and more into emacs lately... been using it for terminal windows now... probably going to end up using gnus to read mail
<maco> by which i mean 2 days ago
<StevenK> TheMuso: That isn't dead yet?
<RAOF> I tried claws for a while.
 * psusi tries claws too for a while
<TheMuso> StevenK: Not sure, haven't really started investigating yet.
<StevenK> I used to used emacs to read mail ...
<RAOF> Claws wasn't really better than evolution in any way I found, didn't have calendar stuff, and didn't have my 50-odd filtering rules.
<StevenK> That's what server-side filtering is for.
<psusi> filtering rules go on the server.. sieve for the winz ;)
<TheMuso> Well calendaring doesn't matter as I have to use Evolution to do that anyways *grumble grumble*, and filtering is done server side for me.
<StevenK> RAOF: If you use dovecot for IMAP (and you should!), setting up sieve is easy and full of win
 * psusi been using dovecot for imap with sieve on his server at work for a few years now
<RAOF> StevenK: Why would I run an imap server?
<StevenK> RAOF: For your personal e-mail?
<RAOF> Eh; google's got that.
<psusi> though I need to rejigger it to put all of the old archives into a compressed mbox file instead of the Maildir
<StevenK> RAOF: I thought gmail did filtering anyway
<RAOF> It does, but it sucks at it.
<StevenK> Buy a Linode, set up dovecot and postfix, use sieve, profit?
<RAOF> Or, at least, almost all of my filters are filter-by-mailinglist (which it doesn't do correctly, or didn't last time I checked) or specific-header matching (likewise)
<RAOF> I guess I couldâ¦
<RAOF> It seems an awful lot like unnecessary work, though.
<psusi> RAOF, what is "it"?
<RAOF> Buying a Linode, setting up dovecot and postfix, and sieve.
<StevenK> Then you need to move MX records and such :-)
<RAOF> Then maintaining the same.
<psusi> is linode like a virtual server?  I run dovecot and postfix on my server at work with sieve for filter rules and it works great
<StevenK> A Linode is a VPS
<psusi> it pulls mail with fetchmail, then uses postfix and dovecot with sieve filters to sort, store, and serve mail
<psusi> which I read with thunderbird at home and at work... though I have also tried using claws and evolution and ended up back in tbird
<psusi> really need to give mutt a good try one of these days...
<StevenK> RAOF: I have dovecot, postfix, apache and duplicity to handle the-datacentre-is-now-a-smoking-crater case and spend maybe ten minutes a week looking after it. Then again, it is your time.
 * psusi needs to spend some time again soon deciding if he should improve dump ( if it needs it ) or go back to using tar
<ajmitch> StevenK: some of us still use procmail instead :)
<StevenK> Work mail is filtered using procmail, so I can use that too.
<psusi> then again, maybe first I should finish my proposal from years ago about automagical read/write mounts of cd/dvd/bd-rw media so they behave like giant floppies
<psusi> yea, so.. macs have a little check box in the gui to disable permissions on mounts... I did some work in that area for udf a few years aback... would it be useful to do some kernel work for ext4 to be able to disable permissions on external media and integrate that into the gui disc properties dialog box?
<didrocks> good morning
<pitti> Good morning
<geser> good morning
<pitti> lool: thanks for fixing cdbs!
<pitti> lool: retrying gdb build
 * pitti sends a metric ton of new langpacks launchpadwards
<pitti> dpm: ^ FYI; note that they already have the firefox 4.0 final XPIs, so they won't work yet with our beta12; but Chris is going to upload 4.0rc1 this week
<dpm> morning pitti. Thanks for the heads up. Can you paste the message you are pointing to above? I wasn't on the channel yet and I cannot see it
<pitti> dpm: oh, nothing special: "* | pitti sends a metric ton of new langpacks launchpadwards"
<dpm> ah, ok :)
<dpm> pitti, do you think you'll be able to have a look at bug 731298, so that we can start the maverick langpack testing tomorrow? If not, I'll simply delay the call for testing
<ubottu> Launchpad bug 731298 in langpack-o-matic "Untranslated Firefox in the Maverick and Lucid language pack PPAs" [Undecided,New] https://launchpad.net/bugs/731298
<pitti> dpm: I'll try
<pitti> I hope it's not too involved
<dpm> pitti, thanks a lot. Yeah, if you could just let me know whatever the outcome is, that'd be great, so I know whether I should send the announcement or delay it
<dholbach> good morning
<richardcavell> good morning
<pitti> dpm: hm, they've always been meant to also be in the update package, but I guess since we don't use LP translations for them anyway they wouldn't need to be
<pitti> dpm: that doesn't seem to be the actual problem, but it might aggravate it
<pitti> dpm: anyway, I'm afraid we'll need fresh -base packages to clean this up
<dpm> pitti, ah, I didn't know that. I thought they could only be on the -base packages because LP only exported FF translations on full exports
<pitti> dpm: when I originally implemented that, I assumed that we do want them in updates as well, just as normal po files
<pitti> dpm: I wasn't actually aware that we only use po2xpi
<pitti> dpm: I'm totally unsure why https://lists.ubuntu.com/archives/ubuntu-translators/2011-March/004486.html claims that there's an empty firefox 4.0 dir, though; his dpkg -L output doesn't show that
<pitti> but indeed it does show that the file structure changed quite a bit; I'll try to reproduce that
<dpm> pitti, I'm not sure why LP can't export them in delta exports, because they are essentially PO files with a bit of a different format. Theoretically, it would be useful to have them in delta packages too, but I don't know if there are technical limitations there (either on the LP or the packaging side). "dpm: I wasn't actually aware that we only use po2xpi" - I'm not sure I follow this part, what do you mean with that?
<pitti> dpm: sorry, I mistyped; I meant to say "that we only use xpi2xpi, and not the LP translations"
<dpm> ah, ok
<pitti> anyway, I see the problem
<pitti> dpm: I'll create a test case for it first
<dpm> ok, cool
<pitti> I still don't understand why installing the update package makes the original files go away, though
<pitti> dpm: just to be sure, this only affects the PPA, not current lucid-updates, right?
<pitti> or lucid-proposed as well?
<dpm> pitti, that's what translators reported (it affects only PPA). They only started seeing it when they got the latest PPA update, as far as I understood it
<dpm> in maverick, and then someone confirmed it for the Lucid PPA as well
<pitti> dpm: right, because the lucid-proposed packs are empty
<pitti> we had a -base refresh on 20110204
<pitti> ok, good
<pitti> dpm: so, the PPA update packages do ship a single empty ./usr/lib/firefox-addons/extensions/langpack-de@firefox-4.0.ubuntu.com/ dir, but why does that remove the 3.6 translations..
<Daviey> @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: Daviey
<dholbach> pitti, do you think apport could grow a "report & restart" option?
<dholbach> in the case of compiz crashing I'd LOVE for it to be reported and compiz restarted, so I can get back to work afterwards
<dholbach> (and I'm never sure if compiz needs a bunch of command line arguments that I don't know of)
<pitti> dholbach: sure; I guess at that point one of it should perhaps become a checkbox instead
<pitti> to avoid having four buttons
<dholbach> whatever way it's implemented, I'm happy :)
<pitti> dpm: would it matter much if we postpone today's call for testing?
<pitti> dpm: I could do a half-arsed hack and hope for the best, or fix it properly, with test cases, and in a robust fashion, but then it'll take a bit longer than "today 1400"
<dpm> pitti, I'd prefer the full-arsed fix as well :) So let's delay it. Do you have any rough estimate when you'll have time to implement the proper fix, so I can add some info to the announcement?
<pitti> dpm: I think I can get that done today, and let the new build/upload run overnight
<pitti> dpm: should I do that straight to -proposed, or do you prefer having it in the PPA first?
<pitti> (the former would avoid another build round in the ppa)
<dpm> pitti, yeah, I think direct upload to -proposed would be a good idea. That's where people should test it from, no need to have it first on the PPA at this point
<pitti> *nod*
<dpm> thanks a lot pitti
<janimo> fta, hello, the arm build still has not hardening enabled and needs debugging?
<lool> pitti: gdb rebuild worked fine; thanks!
<Daviey> janimo, Thanks for fixing i386 / axis2c... such a frustrating bug
<janimo> Daviey, cheers
<ogra> Daviey, you are aware that if janimo fixes an x86 bug for you you are on duty to fix an arm bug for us, right ?
<ogra> *g*
<dholbach> ogra, you need to twist his ARM harder
<ogra> haha
<dholbach> just when everybody thought all stupid ARM jokes had been made already :)
<Daviey> ogra, If you give me arm hardware, i'll gladly fix stuff :)
<Daviey> I know they don't cost an ARM and a leg... but even so.
<Daviey> (hope that isn't purely a britishism)
 * ogra hands Daviey a bangle ... (i didnt know you were that much into jewelry)
<Daviey> thanks :)
<pitti> dpm: btw, do you want me to upload both lucid and maverick at the same time? or just one?
<dpm> pitti, just maverick to -proposed. I guess Lucid will be fixed automatically at the next PPA upload, and we're not planning any updates until the next point release there
<tseliot> cjwatson: if grub-gfxpayload-lists is in universe, I don't think I can fix cards that have problems with grub's bootsplash with nvidia and fglrx
<dpm> pitti, FYI henninge just confirmed that for firefox translations exported from Launchpad there is no special treatment, i.e. they can either be exported in the delta tarballs or in the full ones, so my assumption that they were only exported on full tarballs was wrong
<tseliot> cjwatson: any plans to move it to main?
<cjwatson> tseliot: oh, yes, it really ought to be moved to main
<cjwatson> tseliot: could you send me an e-mail reminder?
<tseliot> cjwatson: sure
<tseliot> thanks
<pitti> dpm: ok, thanks; I disabled the maverick cron job now, and kept lucid
<dpm> pitti, ok, cool. Do you think you could you also enable the natty ones now that the full langpack is building? Btw, I see on http://macquarie.canonical.com/~langpack/crontab that natty langpacks are only being build on Tue, but according to the schedule they should also be built on Fri. Is the cron job set for Fridays as well, or is it just a glitch in the parser that creates the human friendly description on the exported crontab page?
<pitti> dpm: sure; do you want to enable it youselves, to get the hang of it?
<dpm> pitti, sure :-)
<pitti> dpm: it's not just a glitch, natty cronjobs really just run once a week right now
<pitti> dpm: but I'm sure that the current perl magic won't get along with two days
<dpm> pitti, ok, that's not critical as long as the two days are enabled, and it shows it's enabled/disabled
<c2tarun> I am working on security issues of package phpmyadmin. the patch available on http://www.phpmyadmin.net/home_page/security/PMASA-2011-2.php . it seems that they are fixing all the issues in 3.3.x version, lucid has 3.3.2 with no issues fixed while maverick has 3.3.7 with most of the issues fixed. What should I do, take the patch from the link and fix version 3.3.2 or backport the maverick one?
<geser> c2tarun: patch any issue the lucid version is affect by and ask ubuntu-security-sponsors for sponsoring
<c2tarun> geser: hey just applying is enough or we have to test also that patch is working or not?
<geser> c2tarun: don't know, better ask someone from the security team.
<geser> you should at least test if the application still works
<c2tarun> geser: ok thanks :) i'll do that
<Norrlanning> Hi there! couldn't find a development channel so I thought that I'd give it a try  here. Is there anyone that tried to customize ubiquity? I've done quite a lot but  there's one problem I can't seem to solve. And that is how to change the  pre-highlighted install language. By default the highlighted installer-language  is english. I would just like to change it to Swedish. However it seems like
<Norrlanning>  tere 's ALOT of files ubiquity uses to process that kind of information...Oops, cut and paste from the ordinary ubuntu channel ;)
<cjwatson> Norrlanning: just put sv in /isolinux/lang on the CD
<cjwatson> or boot with debian-installer/language=sv as a boot parameter
<Norrlanning> cjwatson: And that will also make the english option remain? in that case that sounds awesome :-)
<cjwatson> yes, that should just change the default
<diwic> Norrlanning, I'm SkÃ¥ning ;-)
<Norrlanning> Because the default on the system is correct, it's just ubiquitys installer that needs to change :-)
<Norrlanning> diwic: Hehe well hiya :-D
<Norrlanning> diwic: LX?
<diwic> Norrlanning, I think we have to make skÃ¥nska the default ;-)
<cjwatson> Norrlanning: yes, I mean it should change the default selection on ubiquity's language selection page
<pitti> dpm: at least it shows the first day correctly on http://macquarie.canonical.com/~langpack/crontab
<Norrlanning> cjwatson: Thank you very much. This problem has been bugging me for 2 whole days :-D
<Norrlanning> diwic: Haha oh yes ;)
<dpm>  pitti yeah :)
<Daviey> c2tarun, Hey, are you around?
<c2tarun> Daviey: yup
<c2tarun> hi
<Daviey> c2tarun, Super... you've been super busy fixing some of the FTBFS bugs!
<c2tarun> Daviey: I was fixing some FTBFS but in free time :) not busy, why what happened?
<dholbach> barry, I just replied on the ubuntu-packaging-guide merge proposal
<dholbach> sorry for the long wait
<dholbach> although I had hoped somebody else would get to it earlier
<Daviey> c2tarun, it's really good work....
<c2tarun> Daviey: thanks :)
<Daviey> c2tarun, The only thing i'm thinking is https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032632.html
<Daviey> c2tarun, Under the latest natty toolchain they do build..
<Daviey> c2tarun, As that mail says, when o-series opens - we'll have the same bug again.  So i was thinking, keep the bug open, see if Debian adopt the patches when O-Series opens?
<Daviey> c2tarun, This will mean we should get the fix for free, without deviating too far from Debian.  What are your thoughts?
<Daviey> c2tarun, Over the weekend, i did forward one of your patches to Debian... but am i right in saying that you have pushed the rest of the patches to Debian?
<c2tarun> Daviey: yup, artur told me to file a bug in debian first and then close that bug in changelog.
<Daviey> c2tarun, So you are ok with your patches not going into Natty?
<barry> dholbach: no worries.  i'll do the merge.  i'll be taking off soon-ish to pack and travel for pycon
<dholbach> barry, gotcha - just get it in there and I'll put some work into restructuring
<dholbach> it'll be great to just have the content in there first
<barry> dholbach: awesome!
<c2tarun> Daviey: what do you mean by not going into natty? I mean they are being fixed at both places I guess in debian as well as in natty, + I dont understand what on that link mean exactly? I mean the one who posted the bug is saying that do not drop ld --as-neede patch, why would someone drop that patch?
<c2tarun> Daviey: is he saying for the release next to natty?
<Daviey> c2tarun, So, the patches you have submitted fix FTBFS.... but under the current toolchain in Natty they do build.  What i am suggesting is that your work goes straight into Debian, and next cycle they'll get sync'd across.
<Daviey> So your fixes will be in O-Series when it opens.
<c2tarun> Daviey: sorry to ask this but what is O-Series?
<Daviey> c2tarun, Part of the concern i have is that some of these packages, it introducing a delta - which means that someone will need to manually request a sync.
<barry> dholbach: merged and pushed
<dholbach> ROCK
 * dholbach hugs barry
<dholbach> barry, blueprint updated
<Daviey> c2tarun, O-Series is the name of the next development cycle, that i can neither spell nor pronounce :)
 * barry feels better already!
<c2tarun> Daviey: ok :) so if my work goes straight to debian we can easily get them sync automatically without any manual sync request right? that sounds good :)
<c2tarun> Daviey: ping
<Daviey> c2tarun, yeah!  There is one more thing you can add to make tracking easier for the bugs you've opened... On Launchpad you can mark, "affects distribution" and paste the url to the debian bug.  Makes it easier to track next for next cycle.
<\sh> micahg: zf 1.11.4 is ready for backport :) thx :)
<c2tarun> Daviey: sure I'll do that :) not a problem at all.
<Daviey> c2tarun, you rock, thanks :)
<SpamapS> Daviey: ty for the squid upload. :)
<Daviey> SpamapS, I wasn't sure if ":" was a bashism, that wouldn't work in dash... seems it does... perfect, didn't even need to comment on it :)
<SpamapS> Daviey: I tend to think that all terse confusing things will work in dash.
<cjwatson> portability of ':'> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#colon
<cjwatson> the difference between : and true is that : is required to be a "special built-in utility", so need not be execve-able etc.
<cjwatson> in some shells the special built-ins will be more efficient
<Daviey> cjwatson, bash doesn't have a built-in 'true' does it?
<soren> $ which true
<soren> /bin/true
<soren> Nope.
<cjwatson> yes it does!
<soren> Really?
<Daviey> soren, I just did that aswell :), but wondered if exec overides the which :)
<ogra_> man bash
<cjwatson> true has to be provided on the search path, per POSIX
<soren> I thought which would say it was a built-in.
<cjwatson> type will say it's built-in
<cjwatson> which explicitly searches $PATH
<cjwatson> $ type true
<cjwatson> true is a shell builtin
<Daviey> ah, so it does!
 * soren thought which was a built-in, but apparantly not.
<cjwatson> nope
<soren> I guess it would be kind of hard for a not-builtin to decide if something else was a built-in.
<cjwatson> exactly
<Daviey> type is a built-in :)
<Daviey> This patch piloting lark, is educational :)
<soren> Indeed.
 * soren crawls back under his rock
<Daviey> cjwatson, so in this instance : is as efficient as true, but if we had a shell which doesn't builtin true - : would be better?
<cjwatson> right
<Daviey> nice.
<cjwatson> 'true' is a "regular built-in utility" in POSIX parlance - may be built into shells, must still be provided on search path, has special treatment for command execution (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01)
<Daviey> Who needs the internet / grep code, when you have a cjwatson.
<cjwatson> that special treatment being in brief that you can't change its behaviour just by putting a different implementation in front of the system one on $PATH
<cjwatson> (which is probably not widely known - it's not something I remembered until I looked it up just now)
<Daviey> Interesting.
<pitti> dpm: ah, forgot one thing to reply: the lucid .debs in the PPA will get fixed automatically in the next run, but people who already upgraded to the broken ones will need to purge them and the -base and reinstall
<dpm> pitti, ah, thanks for the heads up. I'll let translators know
<pitti> dpm: thanks
<artfwo> I see there's a blueprint to replace gdm with lightdm in natty, but it's not implemented yet. will this feature come in natty or natty+1?
<pitti> artfwo: the blueprint was about providing lightdm; it wasn't planned to replace the default in natty
<seb128> artfwo, not natty for sure but it will be discussed at uds for next cycle
<artfwo> it's about replacement judging from description, https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-display-manager
<artfwo> but thanks for the answers, hopefully this area will get some attention for the ocelot
<seb128> artfwo, see the whiteboard
<seb128> seems like the whiteboard didn't really get a summary of the UDS discussion notes though
<mdz> seb128, gnome-user-share was in the default install in 10.04 but gone in 10.10; was it an intentional change? (looking at bug 536766)
<ubottu> Launchpad bug 536766 in gnome-user-share (Ubuntu) "Personal file sharing preferences dialog does not offer to install needed packages" [Low,Triaged] https://launchpad.net/bugs/536766
<mdz> chrisccoulson, ^
<seb128> mdz, was it?
<chrisccoulson> yeah, i think it was recommended by gnome-bluetooth
<mdz> seb128, it wasn't seeded, but it was on the CD (chrisccoulson pointed it out to me)
<mdz> that's how I noticed: I wanted to receive files over bluetooth and it took a while to figure out what to install
<seb128> seems like it should still be recommended
<seb128> not sure when and why it got dropped though
<mdz> it was dropped to suggests
<chrisccoulson> ah
<seb128> that seems wrong
<chrisccoulson> yeah, the "Receive Files" button in gnome-bluetooth doesn't work without it
<mdz> no mention in the changelog
<mdz> oh, the changelog is abbreviated
<mdz>   [ Andrea Veri ]
<mdz>   * debian/control:
<mdz>     - added a suggests on gnome-user-share, its bluetooth
<mdz>       support should be working fine now.
<seb128> mdz, that seems wrong
<mdz> seb128, it's an odd thing to say if it already had a Recommends
<seb128> mdz, ?
<seb128> oh the changelog
<mdz> y
<seb128> mdz, ok, it's a merge error in http://launchpadlibrarian.net/49137567/gnome-bluetooth_2.30.0-0ubuntu3_2.30.0-1ubuntu1.diff.gz
<mdz> seb128, ahh, well spotted
<seb128> mdz, I will put it back, thanks for spotting it
<mdz> seb128, should we use bug 536766 to track the lost recommends then?
<ubottu> Launchpad bug 536766 in gnome-user-share (Ubuntu) "Personal file sharing preferences dialog does not offer to install needed packages" [Low,Triaged] https://launchpad.net/bugs/536766
<mdz> I will fix it up if so
<mdz> it should be a non-issue if gnome-user-share is installed by default
<mdz> though it's not directly to do with bluetooth
<mdz> maybe it would make sense to seed gnome-user-share
<abhinav-> is there any option to pass to fsck so that it takes all answers as yes by default ? :-| I am unable to boot , filesystem seems to be corrupted
<seb128> mdz, no, let's keep that bug about what the title describes, people might still uninstall the recommends and run into it
<seb128> mdz, I will add the Recommends back now, no need to track it in a bug
<mdz> ok
<mdz> yeah, it's talking about the apache based sharing so a different issue
<janimo> TheMuso, hello, planning a new pulse upload soon?
<ogra_> janimo, did you recieve the patches from ndec ?
 * ogra_ cant remember seeing them yet
<janimo> ogra_, ndec? Related to what?
<janimo> who is ndec? :)
<ogra_> janimo, nicolas from TI ... he has pulse atches we need to integrate
<ogra_> *patches
<janimo> ogra_, ah no. There's just one small issue in the porting queu
<ogra_> ah
<janimo> ogra_, I did not know about anything TI &pulse related
<ogra_> we still need to add the UCM config to alsa-utils first though
<ogra_> and we can only do that after the kernel was switched to .38
 * ogra_ grumbles, still no trace of the new livecd-rootfs ... the publisher annoys me 
<YokoZar> mvo: any objections for a patch to app-install-data for a package before it's in the archive?
<YokoZar> (but is in my PPA ;) )
<mvo> YokoZar: hello! will it be in the archive soon?
<YokoZar> mvo: I hope so, but there's a chance it might not make it in at all in the release.  Would that be a bad thing?
<YokoZar> mvo: I'm hoping software center does the smart thing and hides it completely if the referent package doesn't exist.  Which would make adding it a good thing even if it only existed in PPA
<mvo> I need to double check that, it may assume your repo data is outdated
<mvo> (i.e. for some reason /var/lib/apt/lists/ is empty/incomplete)
<mvo> so it will probably offer you to update
<YokoZar> over and over
<YokoZar> which would be bad
<YokoZar> but wouldn't that happen if a user disabled universe?
<kiwinote> YokoZar: if an app is listed in app-install-data, then s-c will display it in the listings whether it is available or not; in the details view an error will appear 'the pkg $pkgname is not available in your current software sources'
<YokoZar> kiwinote: ahh ok, that makes sense.  Best to get it in the archive then!
<kiwinote> YokoZar: yep, that would be best ;)
 * YokoZar laments that we still don't have the ability for PPAs to add additional proper entries
<hallyn> hm, why is my install-exec-hook not happening?
<pitti> dpm: uploading maverick-proposed langpacks now; they'll compete on buildd power with the natty ones, so it'll take a while
<alkisg> LP bug #422298 has been fixed in Debian's dash 0.5.6.1-1~exp1, but Natty has 0.5.5.1-7.2ubuntu1.
<alkisg> I'm interested in helping get this backported for Lucid, what method should I follow? I think the standard SRU policy doesn't apply here as the bug isn't fixed in Natty...
<ubottu> Launchpad bug 422298 in dash (Ubuntu) "dash interpreter don't handle some unicode characters correctly" [Undecided,New] https://launchpad.net/bugs/422298
<Chipzz> alkisg: do you really think that is a good idea? I *SERIOUSLY* doubt it
<Chipzz> alkisg: given that dash is the default /bin/sh, there is a LOT of potentital for regressions
<fta> janimo, hi, correct, pie disabled on arm (only), due to lack of h/w on my side and lack of help in general
<nigelb> diwic: Hey, just wanted to let you know --> Great work on the audio hook!
<alkisg> Chipzz: why not? It currently breaks even touching a file in the Greek translation of "desktop"
<diwic> nigelb, thanks :-)
<nigelb> diwic: I'd taken a session on apport hooks and was WOW when I saw it :)
 * nigelb hugs diwic 
<Chipzz> alkisg: I just told you why...
<alkisg> Chipzz: well, it's a 2 lines patch, which is confirmed to fix a serious problem
<alkisg> So I don't see why I should be afraid of regressions for that
<Chipzz> alkisg: yeah? and? so? what?
<alkisg> Chipzz: and so, systems here break, and they can be fixed
<Chipzz> alkisg: you do realize that not every bugfix gets a backport to stable, do you?
<alkisg> I don't see your point
<Chipzz> and I do not see your point at all
<alkisg> Sure. I only care about serious bugs
<Chipzz> and IMO that one is not serious
<alkisg> I say again, that touching a file in the greek desktop fails because of this bug
<Chipzz> (but that's just my 2c)
<alkisg> I wouldn't have reported that bug if I wasn't affected
<alkisg> Anyway, any answers to my question?
<alkisg> (thank you for your thoughts + time btw)
<Chipzz> alkisg: please elaborate on how the fact that this bug affects you personally makes it important?
<alkisg> Chipzz: no, it affects all of 200 greek schools I keep an eye on
<Chipzz> I have dozens of bugs affecting me, but I'm not going to claim they're important because they affect me...
<alkisg> It doesn't affect me personally
<cjwatson> alkisg: to me, that bug sounds reasonable to fix in an SRU
<cjwatson> it's high-impact for many people
<alkisg> cjwatson: thank you. My problem is that I think that for an SRU, it needs to be fixed in Natty first
<cjwatson> yes, it does
<cjwatson> figure that out first :)
<alkisg> Yup, that's where I have the problem, and why I was asking :)
<alkisg> How to get that fixed for natty past feature freeze :)
<Chipzz> cjwatson: do you really think it is a good idea to mess around with the default /bin/sh ??
<cjwatson> are there any other feature changes between what we have now and what's in Debian
<cjwatson> Chipzz: if it's having that kind of impact, it is perfectly reasonable to consider it
<alkisg> I haven't checked the changelog from natty to debian exp
<Chipzz> cjwatson: like I mentioned above, the regression potential is HUGE
<cjwatson> obviously such a change should be well-tested
<cjwatson> but I think it's inappropriate of you to reject it out of hand
<Chipzz> if a backport of dash breaks, it doesn't just break lightly, it breaks everything everywhere
<cjwatson> alkisg: you should - but if it's too big, we can backport just that fix to natty
<alkisg> Is there some cherry picking procedure that we could use to only backport those 2 lines?
<cjwatson> Chipzz: excellent, then we'll notice it and we can avoid promoting it to -updates
<alkisg> Thank you cjwatson, will check the changelog and comment on the bug report
<cjwatson> alkisg: sure, fish out the patch and apply it :)
<Chipzz> cjwatson: I doubt users of an LTS release would appreciate literrally having half of their system broken ^^ ;)
<cjwatson> Chipzz: it won't affect them until it's been regression-tested in -proposed
<cjwatson> it is sensible to take care with -updates, but frankly I think you're being unnecessarily alarmist
<cjwatson> we can assess this sort of thing calmly, without resorting to hyperbole
<cjwatson> if an update exhibits that kind of breakage, then it's an easy decision not to roll it out to everyone
<Ampelbein> Daviey: If you are still on duty, could you check on the branch at bug 715766?
<ubottu> Launchpad bug 715766 in pyserial (Ubuntu) "ImportError: no module named serial" [Medium,Confirmed] https://launchpad.net/bugs/715766
<Chipzz> well I'ld say if that bug is so important how come it was unfixed in an LTS for close to a year?
<cjwatson> oh come on, we have lots of bugs which are important which were unfixed in the LTS and which we fix in updates
<Chipzz> sure
<cjwatson> that's a circular argument for never issuing any updates
<Daviey> Ampelbein, Hey, yes - I was hoping to speak to doko about that - he is the Debian maintainer.
<Chipzz> I'm not saying you're doing a bad job fixing bugs
<cjwatson> you're actively discouraging people from doing so
<Chipzz> I don't have any figures, but I'ld say that most SRU's are a) either fixed soon(ish) after release, or are the result of an earlier regression?
<Ampelbein> Daviey: ok, thank you!
<cjwatson> Chipzz: I think your gut feel is incorrect here
<Chipzz> it might be; you would have more knowledge about it than me
<bluegoat> anybody here using quickly?
<Chipzz> my feeling is simply that if a bug in a core package is critical, it would be fixed a lot faster than a year (allmost 2 full release cycles)
<cjwatson> this really isn't a good argument for things that only affect a section of the userbase
<cjwatson> native English speakers will likely never notice this bug
<cjwatson> but I don't think that's a good reason for us to be Anglocentric
<cjwatson> (or Latin-language-centric)
<cjwatson> UTF-8 handling bugs *are* important
<cjwatson> most of our core developers speak English much of the time, and few of them use non-Latin languages very much, and that inevitably skews what we work on; but that is not necessarily a good reflection of our userbase, and it is not an excuse for failing to fix bugs that affect others
<Daviey> Ampelbein, Thanks for the branch!  It does look like it fixes the issue, the only concern i have is that it's not the best way.  Looks like doko is away for the rest of the week... Looking further.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<Ampelbein> Daviey: hm, what do you mean with 'not the best way' I thought that keeping the python modules in /usr/share/pyshared and symlinking from /usr/lib/python2.X/dist-packages is correct? And if I understand dh_python2 script correctly it does that?
<Chipzz> cjwatson: well I just read the SRU guidelines again; none of them seem to apply in this case (although it does state above that they're examples so I guess the list isn't exhaustive); but when I read sth like "As for dash-0.5.4, in expand.c:240 there is a line rmescapes(p);", alarmbells start to ring
<Chipzz> changing a macro which removes escapes seems like a good opportunity to introduce new problems
<cjwatson> you're welcome to disagree
<Chipzz> like I said above, just my 2c
<Chipzz> :)
<cjwatson> I don't think we're going to get anywhere arguing about it
<Chipzz> then I'll just stop arguing :)
<ogra> mumble mumble ...
<ogra> so the publisher ... if i upload a package and it builds in less than 5min, why doesnt the darn thing publish source *and* binary then ...
<ogra> i always have to wait two runs to actually get my binary
<cjwatson> ogra: it does if the binaries land in time
<ogra> hmm, but i'm sure they did
<Daviey> Ampelbein, Yes, i think you are right... but i'm trying to work out why doko did it the way he did.
<cjwatson> ogra: they need to land before :00, not before :03, in order to catch the queue run job
<ogra> hmm, k
<cjwatson> that may have confused you, perhaps
<ogra> dunno, i see i did the upload at :49
<ogra> building livecd-rootfs takes around 5min
<ogra> thats why i would have expected it to make this run ...
<ogra> hmm, seems i was tricked by the queue, binary only finished 47min ago
 * ogra rests his case then
<cjwatson> ogra: your source upload was processed in the queue run at 16:00 UTC, and didn't actually process livecd-rootfs until 16:02:41 because the queue was swamped with language packs
<cjwatson> ogra: the queue doesn't run at :55, perhaps for historical reasons, which may not have helped
<ogra> cjwatson, yep grokked that now
<cjwatson> ogra: in any case, the build time of the binary does not mean it'll be scheduled immediately :)
<ogra> ah, and indeed i know about the :55 omission
 * ogra totally forgot about that one
<Daviey> Ampelbein, I think i was worrying too much... merging now :)
<Ampelbein> Daviey: better save than sorry or how do they say ;-)
<ryanakca> Could somebody with bash-4.0 (not 4.1) please try to reproduce http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537525 , you'll need to setup PS1 as he described.
<Daviey> Ampelbein, That is great, thanks!  Uploaded... nice work
<ryanakca> (You can use whichever term you want, no need to use urxvt)
<abhinav-> ttx, thank you for accepting the tomcat6 patch. bug 707405 . :-)
<ubottu> Launchpad bug 707405 in tomcat6 (Ubuntu) "tomcat6-instance-create should allow -c -1" [Low,In progress] https://launchpad.net/bugs/707405
<c2tarun> Daviey: ping
<Daviey> c2tarun, o/
<c2tarun> Daviey: can you please look at debian bug 617465
<ubottu> Debian bug 617465 in alex4 "Package alex4_1.1-3 failed to build from source on Ubuntu natty" [Normal,Open] http://bugs.debian.org/617465
<c2tarun> Daviey: there are several patches in there? where did they come from?
<c2tarun> Daviey: and what am I suppose to do with them?
<Daviey> c2tarun, crikey!
<Daviey> c2tarun, looking
<Daviey> there are many there :)
<c2tarun> Daviey: actually I am not getting what Peter is trying to say, I looked at most of the patches and they work fine as they should.
<Daviey> c2tarun, A quick visual look at the patches, they look really good!  If that gets pushed to Debian this week, i think a sync request is a really good idea.
<c2tarun> Daviey: yup they are good, but what am I suppose to do here? and what is a principal maintainer.
<Daviey> c2tarun, It's always nice to see a package have a good clean, and convert to quilt (3.0) IMO... so i'd like to see that get into Debian soon :)
<Daviey> c2tarun, I think you need to just wait to see if the get applied and uploaded to debian unstable/experimental ?
<Daviey> c2tarun, Ideally - they'll do it this week... but I don't think you can do too much to influence that.
<c2tarun> Daviey: or i'll just say that I have no objections ;D as they asked?
<Daviey> c2tarun, I think he was thanking you; but asking the Debian Maintainer what he thought of his patches.
<c2tarun> Daviey: thats good, one more help please, how else can I contribute except packaging?
<Daviey> c2tarun, I've noticed you've been super busy the last week contributing patches, and that is really, really useful...  The other area we really need help is testing.
<Daviey> c2tarun, -> Does that interest you?
<c2tarun> Daviey: i'll try :)
<Daviey> c2tarun, join -> #ubuntu-quality
<Daviey> bdmurray, Can i pick on you for a comment?
<bdmurray> Daviey: hmm, I was on a call
<dpm> pitti, ok, cool, thanks (re: maverick-proposed langpack upload)
<Daviey> bdmurray, Sorry.. it's not urgent.  I just wanted to gauge your opinion on something.  I have a situation where someone has submitted a one line branch fixing something, but not updated the changelog.  What do you think a sponsor / patch pilot should do in this sitaution?
<Daviey> I mean, I could fudge a changelog to look like theres... but then have i gone too far in helping them get their code in the branch?
<Daviey> s/branch/archive
<bdmurray> I don't think so - our documentation is spread out all over the place and its possibly wrong is some places.  So I'd do it for them but be very verbose about what you did and where the supporting documentation is.
<bdmurray> Imagine their response "wow, this daviey guy was great and helped me get this done" vs "man this daviey guys want me to do more? I already had to do this that and the other thing."
<Daviey> bdmurray, Oh totally, earlier on i fixed someones email address and s/maverick/natty for that reason.
<Daviey> bdmurray, I don't agree with just bouncing comments back saying fix every trivial thing as "that is the only way they will learn"... but creating a new entry n the changelog , i was mixed on
<ScottK> If it's their first experience with contributing I think the most important thing they feel is that they are successful and it's not tiresome to participate.
<Daviey> ScottK, Yeah - I agree with that...
<ScottK> I once sponsored an upload where the only thing that was left untouched of the contributors input was their name in the changelog.
<bdmurray> Daviey: I just wouldn't be surprised if writing a debian changelog is a missing step in documentation somewhere.  Additionally, how long might it take you to fix it vs waiting for them and it getting lost.
<Daviey> Yeah, ping-pong is a timesink for just GTD/JFDI.
<Daviey> ping-pong of comments, "Needs Fixing"
<abhinav-> Daviey, bdmurray I also submitted my first two patches recently :) . I was confused about the debian changelog entry, it said Maverick in the top, but I was working on the natty release of source code.
<abhinav-> but yes my working in maverick
<abhinav-> *I was workin in maverick :D
<jdstrand> @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: jdstrand, Daviey
<Daviey> abhinav-, Yeah - Really i think dch should default to the next development version...
<Daviey> most of us run the development version so we don't notice it. :/
<abhinav-> yes, so it should be changed to the latest release anyways ?
<Daviey> abhinav-, raise a bug :)
<Daviey> abhinav-, probably against devscripts
 * Daviey ^5's jdstrand 
<jdstrand> :)
<jdstrand>  5
<jdstrand> o/
<abhinav-> Daviey,  oh , I thought it was usual. but I dont know about devscripts much
<Daviey> abhinav-, Having said that, if people are using PPA's, it's likely it's for the version they are currently running.  So perhaps not a bug.
<geser> oh, no backport of natty's devscripts in maverick-backports?
<abhinav-> Daviey, yes perhaps right.
<ScottK> jdstrand: thanks for taking care of linux-n900.
<jdstrand> ScottK: sure thing :)
<Daviey> bdmurray, It bit me in the bum... :)
<Daviey> bdmurray, Had i of uploaded this, i image i would have upset people :/ .. https://code.launchpad.net/~dave-martin-arm/ubuntu/natty/linaro-image-tools/udisks-dep/+merge/52543
<NCommander> directhex:is there a nice set of prepackaged mono 2.10.1 packages somewhere? :-)
<directhex> NCommander, not yet.
<abhinav-> Daviey, thank a lot :-) . made my week by approving my first patch :)
<bdmurray> Daviey: you never said it was a linaro thing ;-)
<Daviey> bdmurray, it /shouldn't/ matter. :)
<Daviey> abhinav-, Which one was that?  I've had patches coming out of my ears today!
<abhinav-> Daviey,  :-D bug 707405
<ubottu> Launchpad bug 707405 in tomcat6 (Ubuntu) "tomcat6-instance-create should allow -c -1" [Low,Fix released] https://launchpad.net/bugs/707405
<abhinav-> tomcat6 one
<Daviey> abhinav-, Yeah, that was a good catch! :)
<abhinav-> thank you :)
<Daviey> abhinav-, Just FYI, an easy(ish) way of submitting patches to debian, is the console tool - 'submittodebian' ..
<Daviey> i've done that now, and added the bug to the LP bug
<abhinav-> Daviey, oh I did not know that :-|
<Daviey> abhinav-, Don't worry, you did good.. :)
<abhinav-> I attended barry's session in developer week, and since then I have been learning everyday :)
<abhinav-> thank you
<TheMuso> janimo: Yes, I am, today hopefully.
<janimo> TheMuso, ok, I was asking because of the pending arm FTBFS patch you had iun your PPA, and the removal of implicit-it from debian.rules
<TheMuso> janimo: Yeah figured as much.
<Daviey> @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: jdstrand
<calc> anyone happen to know how to select which display on a multihead setup the menus show up on?
 * andreserl if would have known that Daviey was piloting, he'd have given him lots of things to review :)
<RoAkSoAx> arg
 * RoAkSoAx if would have known that Daviey was piloting, he'd have given him lots of things to review :)
<NCommander> directhex: nuts :-(
<soren> RoAkSoAx, andreserl: What's with the split personality?
<RoAkSoAx> soren: wanted to change nicks to andreserl (cause many people couldn't relate my LP page with nickname) but when I used it people don't have idea of who I am either :)
<NCommander> directhex: what would be necessary to test mono 2.10.1 on Ubuntu?
<soren> RoAkSoAx: Ah :)
<Daviey> andreserl / RoAkSoAx: If it was in the queue, it would have got looked at.... *hint*, subscribe ~ubuntu-sponsors :)
<RoAkSoAx> Daviey: haha was just messing around ;)
<Daviey> :)
<hallyn> kees: is there a way to get sbuild to install a particular .deb before compiling?
<hallyn> can't really do '--pre-build-commands="dpkg -i x.deb"' since I'm not root...
<kees> hallyn: yes, one sec
<hallyn> well i suppose i can temporarily install it in the -sources chroot
<hallyn> then remove it when i'm done.  ugly.
<kees> hallyn: try using --chroot-setup-commands instead of --pre-build-commands
<hallyn> kees: will try, thanks
<slangasek> mvo: hi, I've got a couple of apt bugfixes needed in natty for multiarch (one prevents multiarch from working as designed, the other breaks your system horribly if you try to remove foreign-arch packages from your system); DonKult has reviewed them but I think I've depressed him with my patch that removes half of his work around Arch: all packages... :)  Do you want to review these changes, or should I just push?
<slangasek> calc: xrandr --output $name --primary; I don't think there's a way to do it from the GUI, and that's been annoying me lately ;)
<mvo> slangasek: I would like to look at them before pushing, I quickly scanned them today and first glance is good (as excpted)
<mvo> slangasek: I have a udev cdrom bugfix pending as well
<mvo> slangasek: if tomorrow is fine with you I will prepare a upload then
<slangasek> mvo: that would be awesome, thanks :)
<mvo> slangasek: great
<hallyn> kees: success!  (once I used absolute path instead of relative :)  thanks
<kees> hallyn: great! :)
<alkisg> (06:31:50 PM) Chipzz: my feeling is simply that if a bug in a core package is critical, it would be fixed a lot faster than a year (allmost 2 full release cycles)
<alkisg> ==> for another example, see LP bug #580961, it affects 772 people (in launchpad, thousands in reality), it's been broken since Jaunty and while a fix exists it hasn't been committed yet
<ubottu> Launchpad bug 580961 in unzip (Ubuntu) "unzip fails to deal correctly with filename encodings" [High,Triaged] https://launchpad.net/bugs/580961
<alkisg> I'll try to propose a debdiff for that too, if pitti isn't working on it atm
<abhinav-> I tried booting from a live usb of natty , it gave crash errors of compiz and ubiquity. apport created a log report, but I could not report it because the keyboard was also not workin in there. is the the information that apport collects stored somewhere in the usb ?
<slangasek> lamont: there's not supposed to be any persistent state in ppa chroots, right?
<calc> slangasek: thanks :)
<jdstrand> @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:
#ubuntu-devel 2011-03-10
<Mase_wk> hey guys, i have a developer who has packaged an application for debian and would like a mentor to  get it into debian. I would also be happy to maintain this package,in either debian or ubuntu.
<Mase_wk> http://git.debian.org/?p=pkg-symfony/phing.git
<Mase_wk> i was wondering how we could go about getting this included in ubuntu /debian
<aroman> hey, I'm working on an ubuntu based linux distro. When I change /etc/lsb-release to be custom to this distro, it breaks most of apt/package management. It tries to look for repositories with the name of my distro, not with maverick. However, if I use "maverick", other things do not display correctly. How can I fix this?
<syn-ack> fta, Nevermind. I found you in here... You around, sir?
<micahg> syn-ack: not likely for a few more hours
<syn-ack> hrm wanted to see if Chromium misbehaving was a product of the browser or if it may be something else...
<syn-ack> I have a feeling its Mutter, but since I couldn't find a bug list for Chromium, I figured I'd hunt him down and get his advice.
<micahg> syn-ack: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/
<syn-ack> ugh, I feel like such a tool. I went to the PPA for it.
<syn-ack> I'm not normally this absent minded.
<micahg> syn-ack: don't worry about it
<syn-ack> Good evening sabdfl.
<sabdfl> hiya syn-ack
<syn-ack> sabdfl, Nice to see you around. I don't normally come in to the dev channel so I guess I lucked out for once. ;)
<sabdfl> i'm often around, but i'm not the real expert here ;-)
<Mase_wk> hey guys, i have a developer who has packaged an application for debian and would like a mentor to  get it into debian. I would also be happy to maintain this package,in either debian or ubuntu.
<Mase_wk> http://git.debian.org/?p=pkg-symfony/phing.git
<Mase_wk> i was wondering how we could go about getting this included in ubuntu /debian
<Mase_wk> apparently Nicolas, the guy who packaged this has tried to get a mentor in debian
<Mase_wk> but has so far been unsuccessful
<Mase_wk> i believe there are now at least 3 frameworks that use this build system and at least two people willing to maintain it, we just need some guidance as to how to procede from here
<didrocks> good morning
<pitti> good morning
<raphink> good morning
<dholbach> good morning
<raphink> hi dholbach  :-)
<dholbach> hey raphink
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 09:00-10:30UTC for a code update | 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
<amitk> njpatel: where would a developer look for specs to integrate software with the global menu?
<njpatel> amitk, is it non gtk/qt/xul/OO.org software?
<njpatel> amitk, if so, I think the best person to speak to is tedg when he's up, as he will know at which point to attack from :)
<amitk> njpatel: it is mumble, I filled bug 731302 against it and the developer wants to know how to go about integrating into the global menu
<ubottu> Launchpad bug 731302 in mumble (Ubuntu) "mumble not integrated with global menu" [Undecided,New] https://launchpad.net/bugs/731302
<amitk> *filed
<njpatel> amitk, ah, interesting
<njpatel> ted will know for sure
<amitk> I'll add him to the bg
<amitk> bug
<njpatel> I thought mumble was Qt?
<amitk> yeah, i think so too
<njpatel> or maybe they are doing something different
<njpatel> I thought Qt apps were automatically supported
<njpatel> anyway, will also ping ted
<njpatel> he normally logs in around 2pm GMT
<RAOF> Hm.  There'll be some ELF/TLS ABI wizards in here at some point I bet.  Am I correct in my belief that dlopen-ing a shared library with class TLS_STATIC will only work by accident, and cause wierd things like bug #259219 if you're unlucky?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/259219)
<amitk> njpatel: I wonder if the skype icon not showing up in the systray is also related (it being in Qt as well)
<njpatel> amitk, skype should definitely be showing up (I have it now), what version of Unity are you running?
<amitk> njpatel: 3.6.2-0ubuntu1
<pitti> nooo, Lp offline
<njpatel> pitti, yeah, for the next 1.5 hours
<pitti> didn't we use to have a yellow warning box about an hour before in the past?
<pitti> anyway, /me pats firefox for not eating his very long comment I just typed, when going back a page
<njpatel> amitk, hmm,  inside your ~/.Xsession-errors, can you grep for "skype" and see if you got an Accepted or Rejected from Unity?
<njpatel> pitti, oh, yes, we definitely did
<njpatel> I wonder what happened to that...
 * RAOF saw a 10 minute warning, at least.
<amitk> njpatel: ** (<unknown>:2434): DEBUG: TrayChild (null): skype Skype
<amitk> ** (<unknown>:2434): DEBUG: MaximizeIfBigEnough: Skype window size doesn't fit
<njpatel> amitk, press Super+E and see if you can spot the tray in the desktop thumbnails that appear pleace
<njpatel> amitk, I wonder if it's just hiding behind the panek
<njpatel> and if it is, I've fixed that for today's release
<amitk> njpatel: heh, you're right, I can see the green icon there
<njpatel> amitk, heh, okay, just wait for todays updates, it should be fixed for you :)
<amitk> njpatel: \o/ awesome
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Launchpad down/read-only from 09:00-10:30UTC for a code update | 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
<dholbach> hum
<dholbach> topic a bit long, eh? :)
* dholbach changed the topic of #ubuntu-devel to: Launchpad down/read-only from 9-10:30UTC for code update | Archive: feature freeze | Development of Ubuntu (no support, no app development) | #ubuntu for support and general discussion for dapperâmaverick | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Launchpad down/read-only from 9-10:30UTC for code update | Archive: feature freeze | Development of Ubuntu (no support, no app development) | #ubuntu for support and general discussion for dapperâmaverick | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current | Current Friendly
<dholbach> bah
<dholbach> sorry
* dholbach changed the topic of #ubuntu-devel to: Launchpad down/read-only from 9-10:30UTC for code update | Archive: feature freeze | Development of Ubuntu (no support, no app development) | #ubuntu for support and general discussion for dapperâmaverick | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Launchpad down/read-only from 9-10:30UTC for code update | Archive: feature freeze | Development of Ubuntu (no support, no app development) | #ubuntu for support and general discussion for dapperâmaverick | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pil
<dholbach> ok, I give up
<dholbach> if you haven't noticed: I'm patch pilot
 * amitk wonders who the patch pilot is today...
 * dholbach strangles amitk passionately
<ion> dholbach: Weâre supposed to trust your word? The topic doesnât agree.
<amitk> lol @ dholbach
<dholbach> . o O { hippies! }
<udienz> dholbach, i'm uploading a new packages before FF but it's was rejected by archive-admin because technical problem (dep3). can i submit it again?
<dholbach> udienz, you might have to get a FF exception for it - what is it?
<udienz> dholbach, here http://revu.ubuntuwire.com/p/gkamus
<udienz> https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039752.html and here is the reason
<dholbach> udienz, I can give it another review, but you might want to have a chat with somebody in ~ubuntu-release about it first
<dholbach> just to make sure
<dholbach> thanks for all the pointers
<udienz> dholbach, okay. thanks
<dholbach> rock
* mthaddon 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:
 * pitti gives up on handling pre-applied patches and .pc in UDD branches; that's ridiculously error prone and fiddly
<Daviey> pitti, not to mention ugly diffs.
<Laney> pitti: do you recommend adding 'unapply-patches' to d/source/local-options when working in UDD then?
<pitti> Laney: hm, I thought local-options would by definition not go into source packages?
<pitti> and it would again introduce an inconsistency
<YokoZar> Anyone else notice "oneiric" isn't even in Ubuntu's english dictionary?  It's got red squiggly lines underneath it as I type it here ;)
<Laney> it doesn't go in the generated source package indeed
<pitti> but I tried to apply two changes three times, and it always either failed to apply it right away, or mess up the .pc so that quilt got broken
<Laney> from the man page: 'It can be useful to  store  a  preference tied to the maintainer or to the VCS repository where the source package is maintained.
<pitti> Laney: and the .pc/ stuff and applied patches are already in the bzr branches, so I doublt that this would even help
<pitti> Laney: did you try that?
<pitti> Laney: I'm not sure what the auto-importer does -- wouldn't it just stomp on the changes and overwrite htem with what got uploaded?
<Laney> it would help for subsequent uploads
<Laney> I imagine you'd have to commit the initial patch removing .pc though
<pitti> right, but as archive trumps bzr, the importer would usually overwrite it, or does it have special handling of this?
<Laney> it'd be the same as normal UDD usage I guess
<Laney> i.e. it gets stomped if someone doesn't usse UDD in the future
<Laney> (just guessing)
<Laney> I agree it's irritating behaviour though; maybe the importer could add it by default (or bzr-bd)
<soren> YokoZar: For the longest time, "Ubuntu" wasn't in Ubuntu's dictionaries.
<YokoZar> soren: to be fair, we did popularize the term ;)
<soren> YokoZar: bug 93843
<ubottu> Launchpad bug 93843 in mesa (Ubuntu Natty) "Broken TLS support in libGL.so" [High,In progress] https://launchpad.net/bugs/93843
<soren> Whoops.
<soren> ?!?
<soren> That *is* the right bug number.
<soren> https://bugs.launchpad.net/ubuntu/+source/aspell-en/+bug/93843
<ubottu> Ubuntu bug 93843 in aspell-en (Ubuntu) ""Ubuntu" and "Debian" are not in the dictionary" [Wishlist,Fix released]
<soren> Err.... Who's in charge of ubottu?
<soren> It seems to be on crack.
<Hobbsee> ubuntu irc team
<Hobbsee> or at least, they'll point in the right direction
<soren> I seem to (indirectly) be a member of that team. :-/
<Hobbsee> likely, for cloaks
<Hobbsee> ubuntu ops team, more likely.  ask in #ubuntu-ops
<soren> Hobbsee: Ta
<dpm> hi cjwatson, could you moderate the message I sent re: AppDeveloperWeek in ubuntu-devel when you've got a minute? thanks!
<dholbach> @pilot out
<rcaskey> is there a way to prevent unity from auto-placing windows where they will cause the side bar to hide?
<mterry> rcaskey, I think that's considered a bug, not a feature.  There's an LP bug about it somewhere
<c2tarun> Daviey: ping
<rcaskey> mterry, on the plus side I didn't _mean_ to upgrade to unity but compositing is not crashy now like it has been in every release for the last 3 years
<mterry> \o/
<Daviey> c2tarun, o/
<c2tarun> Daviey: hi :) can you please look at bug 730653 debian fixed this, should I request for a sync now?
<ubottu> Launchpad bug 730653 in alex4 (Ubuntu) "Package alex4-1.1-3 failed to build from source with "ld --as-needed" option" [Undecided,Confirmed] https://launchpad.net/bugs/730653
<c2tarun> Daviey: I just pulled the source code from debian and it failed to build on natty again, why so?
<Daviey> c2tarun, Okay, doesn't look like it's yet been uploaded to Debian... The person commented that they have uploaded it to a holding area, mentors.debian.org - and is looking for someone to sponsor it into Debian.  We should wait for that to happen before doing anything.
<Daviey> c2tarun, The package he uploaded to mentors is failing to build on natty?
<c2tarun> Daviey: got, it, so how do I know that the package is uploaded in debian?
<Daviey> c2tarun, The debian bug will have an update "We believe this has been fixed ..." similar to how our bugs gets closed on Launchpad.
<Daviey> c2tarun, Not immediately, but also the Debian entry on the launchpad bug will be marked "Fixed Released"
<pitti> is that just me, or do other people also get a "426 Transfer aborted.  Data connection closed." on dput? I tried on two different hosts now
<c2tarun> pitti: yup I am also getting same error.
<seb128> pitti, likely the launchpad update from this morning, did you check on #launchpad?
<geser> pitti: janimo just asked the same question on #launchpad
<pitti> hm, the dput actually worked
<janimo> pitti, same here
<janimo> pitti I get warnings on my GPG key, not being certified or somesuch
<janimo> LP folk say this may be the cause
<pitti> dpm: btw, all natty and maverick langpacks are built now
<abhinav-> ttx, bug 297675 . can I work on this ?
<ubottu> Launchpad bug 297675 in tomcat6 (Ubuntu) "Eclipse can't find catalina.policy and bootstrap.jar where it expects them" [Wishlist,Triaged] https://launchpad.net/bugs/297675
<m4n1sh> abhinav-: is permission required to work?
<m4n1sh> I just consult if someone is working on it
<m4n1sh> attach the patch
<abhinav-> m4n1sh, no its an old bug, no one ever worked on it. its worth working if only it will be useful :)
<dpm> thanks pitti, I sent the call for testing as well https://lists.ubuntu.com/archives/ubuntu-translators/2011-March/004496.html
<m4n1sh> abhinav-: if the same version is present in supported series and upcoming then yes, it is useful
<m4n1sh> series = versions
<abhinav-> m4n1sh,  yes. the latest revisions have the same problem. Infact it has only worsen, eclipse now demands more files for its configuration which are not there
<abhinav-> developers have to create symlinks for those files
<m4n1sh> bad. just too bad
<abhinav-> yeah. I am going to work on this right now :-)
<m4n1sh> abhinav-: GO GO GO :)
<ttx> abhinav-: GO GO GO :)
<abhinav-> thanks :-)
<jhunt_> cjwatson: fyi, I've updated lp:~jamesodhunt/ubuntu/natty/upstart/proposed-stage2.
<ion> Stage 2 of what, btw?
<jhunt_> ion: see bug 723846
<ubottu> Launchpad bug 723846 in upstart (Ubuntu Natty) "Feature Freeze Exception request for Upstart in Natty" [High,In progress] https://launchpad.net/bugs/723846
<ion> Ah
<ion> Iâve read that but i forgot about the stages.
<YokoZar> pitti: poke
<pitti> hi YokoZar
<YokoZar> pitti: Just noticed you last touched branding-ubuntu...what do you think of the approach here https://bugs.launchpad.net/ubuntu/+source/branding-ubuntu/+bug/394093
<ubottu> Ubuntu bug 394093 in branding-ubuntu (Ubuntu) "branding-ubuntu should use config-package-dev" [Low,In progress]
<YokoZar> I guess avoiding cdbs and manual entries in the rules file is a good thing
<pitti> hm, no patch in the pacakge
<pitti> YokoZar: the current 0.5 package is already quite simple, though; using dh now
<YokoZar> Yeah, I'm inclined to just go from current and drop the one in the bug report
<YokoZar> even though it was better than what existed at the time it was suggested ;)
<pitti> simplifying the diversions would make sense, though
<pitti> I don't know config-package-dev at all, though, so I can't say how good it is
<pitti> needs a MIR first, though
<YokoZar> me neither
<YokoZar> I'll tell you one thing
<YokoZar> I was trying his version and installed it with dpkg -i and somehow I got warnings about dpkg-diversions existing for the files in the package.  I managed to fix it by removing the package and then reinstalling it.
<YokoZar> So somehow it failed in the upgrade case but not the uninstall->install case
<YokoZar> and that makes no sense to me at all
 * YokoZar has new artwork to put into branding-ubuntu
<pitti> SpamapS: hm, the one time I need some -proposed uploads there aren't any..
<pitti> YokoZar: that should certainly be investigated before switching to this; if you still have the output, you might send that to the bug report and let the reporter comment?
<YokoZar> pitti: I'm just trying to figure out how it's even possible.  Does apt run different maintainer scripts for uninstall->install than it does on upgrade?
<YokoZar> err dpkg rather
<pitti> YokoZar: no, but on upgrade you'd have an already existing diversion while on a fresh install you don't
<pitti> YokoZar: it does run the scripts with different arguments, though
<YokoZar> So something went bad when there was a diversion from an earlier version of the package
<pitti> "install" vs "upgrade" for $1, and the versino number for $2
<YokoZar> I think I'll just put the new artwork into the current version of the package, see if it breaks, and if it doesn't not bother
<YokoZar> we're probably already overengineering by just talking about it so much
<SpamapS> pitti: If only somebody would sponsor my openssh MP's ;)
<pitti> SpamapS: ... which you then couldn't approve :)
<SpamapS> Right! An opportunity to demonstrate the checks and balances of the process.
 * pitti goes to fix the broken queue count on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<SpamapS> pitti: we can do it tomorrow at 16:00 UTC .. in fact that would probably be easier for me.
<pitti> SpamapS: I have release team meeting
<pitti> let's talk on IRC next week, when there actually are uploads
<SpamapS> That sounds good. I'll ping you when I'm on since my TZ doesn't overlap much with yours. ;)
<mdz> cjwatson, are you chairing TB today? if you can't, let me know and I will
<mvo> slangasek: new apt is uploaded (just fyi)
<slangasek> mvo: saw the Debian bug closures, thanks!
<mvo> thank you for your fixed
<mvo> fixes
 * mvo can't type today
<mvo> eh, my dput just closed the connection on me, so no apt just yet :/
<Sarvatt> mvo: yeah its been dying all morning, but it actually does complete
<mvo> aha, ok
<Sarvatt> it's spitting out an error when it was successful, your apt is up there. at least you didn't upload fglrx multiple times like tseliot :P
<mvo> just apt three times :)
<tseliot> yes, 68mb twice...
<pitti> mvo, cjwatson: with the latest apt upload, should we revert the casper hack to symlink /cdrom again?
<jelmer> jhunt_: hi
<jhunt_> jelmer: hi
<jelmer> jhunt_, I noticed you just updated the UDD wiki page - you can also use "bzr branch deb:packagename" to access a branch using the Vcs-Bzr URL
<jhunt_> jelmer: thx. I'll add this. I am able to update wiki pages, but seemingly updating the gdm package approximates "impossible" without copious numbers of chickens a sharp knife, and a bagful of blue moons and flying pigs.
<jelmer> jhunt_: You should always be able to use deb:, even for Launchpad branches
<jelmer> as bzr will happily work with http:// URLs to access Launchpad branches
<pitti> jelmer: oh, I didn't know that one -- so that will use Vcs-Bzr if it exists, and fall back to lp:ubuntu/pkg if not?
<pitti> jelmer: that's even better than debcheckout then
<jelmer> pitti: Ah, no it won't fall back to lp:ubuntu/pkg; the wiki page says to manually translate Vcs-Bzr: http://bazaar.launchpad.net/... to lp: though, and that's not necessary
<pitti> ah, so it's similar to debcheckout
<jelmer> pitti: yeah, the main difference is that it will always checkout into a bzr format, even if Vcs-Git or Vcs-Svn is set.
<ari-tczew> does change on Makefile needs run autoreconf?
<jhunt_> pitti, jelmer: I've updated the udd pages GettingTheSource and SeekingSponsorship, however from the gdm discussions, I think we need a bit of detail on the branch to push to *and* the (different) branch to raise the merge proposal on?
<pitti> jhunt_: in general you should propose to merge into the branch you were branching from
<jhunt_> pitti: ok, I'll add that now...
<pitti> jhunt_: I wish bzr lp-propose-merge would actually work
<pitti> locally it already knows the "from" branch, so it could set up things correctly; but it keeps failing for me
<jelmer> pitti, how does it fail?
<pitti> $ bzr lp-propose
<pitti> bzr: ERROR: No reviewer specified
<pitti> jelmer: that's difficulty #1 -- I don't know the default reviewer
<YokoZar> mvo: slangasek: new apt...multiarch imminent?
<ari-tczew> pitti: about sane-backends last upload. you did a change "debian/rules: Drop "acl" dependency." <- is it forwardable or rather ubuntu-specific?
<pitti> jelmer: (that's a branch from lp:indicator-session)
<pitti> jelmer: if I explicitly specify bzr lp-propose lp:indicator-session, then I get "bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/indicator-session/ is not registered on Launchpad"
<jelmer> pitti, that bug is fixed
<jelmer> the default reviewer I mean
<pitti> (    push branch: bzr+ssh://bazaar.launchpad.net/~pitti/indicator-session/extra-launcher-dir/
<pitti>   parent branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/indicator-session/
<pitti> so the branch does exist
<pitti> jelmer: ah, cool
<pitti> jelmer: (lagging, have meeting now)
<jelmer> pitti, the second issue is a Launchpad issue - when it looks up a branch URL it doesn't support "%2B", only "~"
<pitti> ah
<jelmer> pitti, https://bugs.launchpad.net/launchpad/+bug/704606
<ubottu> Ubuntu bug 704606 in Launchpad itself "launchpad.branches.getByUrl() doesn't support properly urlencoded URLs" [Medium,Triaged]
<jhunt_> pitti, jelmer: I've just added a new paragraph at the end of section 2 (Pushing to lp) here: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship - could you sanity check at some point please?
<pitti> jhunt_: I find "bzr lp-open" quite convenient -- it opens the LP page for your push branch
<pitti> jhunt_: (if you don't specify one)
<pitti> that's easier than xdg-open
<slangasek> YokoZar: yes
<YokoZar> slangasek: I feel like we should have a party
<slangasek> YokoZar: a little early yet for the party, there's still work to do to make it useful :)
<ari-tczew> pitti: about sane-backends last upload. you did a change "debian/rules: Drop "acl" dependency." <- is it forwardable or rather ubuntu-specific?
<pitti> ari-tczew: in principle yes, but the explicit setfacl call shoudl then be removed from the udev rule as well
<Nafallo> hi. anyone want to help me boot natty? apparently the magic to account for / on btrfs disappeared (upgraded this morning)
 * Nafallo goes to search launchpad for open bugs in the meantime
<alkisg> Nafallo: maybe that's a question for #ubuntu+1
<mvo> YokoZar: party! (a bit early, but it could be a multarch warmup party)
<YokoZar> mvo: and by "join the party" we mean "start on the 1000+ packages we need multiarch aware"
<ogra> can't party enough
<didrocks> hum? am I the only one not being to push to hudson? (I just rebooted so no log of the chan :/)
<didrocks> hum, sorry, not hudson, the buildds
<didrocks> I read the thread about the new ftp authentication, should be linked of course :)
<hyperair> hi. can someone from ubuntu-sru please handle https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/659590?
<ubottu> Ubuntu bug 659590 in bzr (Ubuntu) "[SRU] dput sftp upload hangs after all files successfully uploaded" [Undecided,In progress]
<hyperair> for some reason, my ftp uploads are screwing up at the end-point
<hyperair> and my sftp uploads hang so i need to ^C the process
<hyperair> which makes dput via sftp impossible to use for automated scripts.
<didrocks> hyperair: same issue for me
<didrocks> can't push unity
<hyperair> didrocks: ftp screwing up?
<didrocks> hyperair: yeah
<hyperair> it seems to return a 426 error
<hyperair> =\
<hyperair> didrocks: for the time being you can upload via sftp
<hyperair> and ^C when you're done
<didrocks> let's try
<hyperair> but your automated scripts are screwed
<didrocks> ok, the uploads succeeded in fact, even if the .changes got an error and I don't have a .upload file then
<Ampelbein> yes that's bug 732638
<ubottu> Launchpad bug 732638 in Launchpad itself "Poppy FTP server returning "426 transfer aborted" errors for .changes files" [Critical,Triaged] https://launchpad.net/bugs/732638
<didrocks> as long as it uploads :)
<hyperair> heh
<Nafallo> so ehrm. for some reason my btrfs didn't get mounted with the default subvolume. adding rootflags=subvol=@ to my grub command line fixed it. since I'm not sure about the root cause, do you guys still want me to file a bug about it?
<tkamppeter> Someone around who can help me on an upload problem?
<nigelb> !anyone
<ubottu> A large amount of the first questions asked in this channel start with "Does anyone/anybody..."  Why not ask your next question (the real one) and find out? See also !details, !gq, and !poll.
<nigelb> ;)
<tkamppeter> When uploading HPLIP I get the error "2k/3k426 Transfer aborted.  Data connection closed." on the .changes file. Does someone know what has happened?
<micahg> tkamppeter: bug 732638
<ubottu> Launchpad bug 732638 in Launchpad itself "Poppy FTP server returning "426 transfer aborted" errors for .changes files" [Critical,Triaged] https://launchpad.net/bugs/732638
<nigelb> the new ftp server giving trouble?
<nigelb> gah, too slow
<tkamppeter> nigelb, can I do something or have I to wait for the bug getting fixed?
<nigelb> I think the good folks at #launchpad can give you the answer
<nigelb> isn't it am already for lifeless...
<tkamppeter> nigelb, thanks, will be boring for whom does an update on his Natty in the next hours ...
<nigelb> hehe
<kees> @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: kees
<tkamppeter> nigelb, will not get boring, uploads work anyway.
<nigelb> tkamppeter: yay :)
<hallyn> Is there a 'proper' automatic way to get m4/introspection.m4 (like libdbusmenu has), or does one just copy it from a package that has it?
<hallyn> I'd have thought that autoreconf -fi would create it
#ubuntu-devel 2011-03-11
<kees> @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:
<robert_ancell> Does anyone know how to add a package to a packageset?  I've got edit_acl.py but not sure how to use it
<james_w> robert_ancell, I think you may need to be in ~techboard or something to do that
<broder> robert_ancell: you e-mail either the TB or DMB
<robert_ancell> james_w, I thought that might be the case :)
<robert_ancell> broder, cheers
<didrocks> good morning
<abhinav-> dch -i always puts "low" as the value of urgency field in the changelog. what if the bug was triaged as "wishlist" on launchpad ?
<micahg> abhinav-: we don't really bother with urgency in Ubuntu
<micahg> abhinav-: here's an explanation of valid values and what Launchpad does with it though: https://help.launchpad.net/Packaging/BuildScores
<abhinav-> micahg, ok thanks. also, I am working on tomcat6-user package. do I need to use submittodebian as well ?
<abhinav-> I mean I have the patch ready
<micahg> abhinav-: using submittodebian to send patches adds some tags as to the origin of the patch which is helpful to track
<pitti> Good morning
<didrocks> @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: didrocks
<abhinav-> ttx: ping
<ttx> abhinav-: pong
<pitti> didrocks: ooh, happy piloting
<dholbach> good morning
<abhinav-> ttx: i have the patch ready for the tomcat6 wishlist bug. I was confused about the changelog entries for it
<didrocks> pitti: thanks :)
<ttx> abhinav-: cool, maybe propose the branch ?
<abhinav-> I see the other entries in the debian changelog file , all of them say "unstable" but running dch -i by default adds "maverick"
 * nixternal hugs dholbach 
 * dholbach hugs nixternal back
<dholbach> how are you doing? :)
<nixternal> doing good. trying to find out if persia is ok
<dpm> hi mvo, good morning! Do you think you could have a look at bug 690270? It seems some translations are not being loaded in Traditional Chinese
<ubottu> Launchpad bug 690270 in Aptdaemon "Translated String (zh_TW) Not Showed within aptdaemon" [Undecided,New] https://launchpad.net/bugs/690270
<nixternal> how about yourself dholbach, how you been?
<dholbach> excellent - thanks
<mvo> hey dpm
<dpm> hey :)
<mvo> dpm: how strange
<dpm> yeah, it's weird, it seems to work for other languages
<sforshee> 1
<c2tarun> why I am getting this error while submitting bug? http://pastebin.com/LhRsYjHQ
<weasel> moin
<weasel> is it possible to get the code/setup behind http://mirrors.ubuntu.com/mirrors.txt?  elmo?
<wgrant> weasel: The files are generated by Launchpad, but I'm not sure if the GeoIP magic is available anywhere.
<mvo> weasel: hello, afaik its part of launchpad itself, maybe worth asking in #launchpad ? but I guess there is some additional magic in apache for the per-country caching and redirecting
<weasel> generating the per-country files is the easy part :)
<weasel> how mirrors.txt is actually implemented is the interesting one
<lifeless> pretty sure its just a reverse lookup on geoip into the country files lp maintains
<pitti> ScottK: hey, how are you?
<lifeless> disclaimer: I haven't looked to see ;)
<pitti> ScottK: did you notice that I have some questions for you in bug 712554?
<ubottu> Launchpad bug 712554 in jockey (Ubuntu Natty) "Unable to install Broadcom drivers from live session" [Medium,Incomplete] https://launchpad.net/bugs/712554
<mvo> weasel:  salgado did most of the work on this irrc (but he is currently not online afaict)
<weasel> ok, thanks
<weasel> I guess I'll just reimplement it for now :)
<mvo> heh :)
<cjwatson> dpm: done
<dpm> thanks cjwatson
<cjwatson> pitti: casper /cdrom> I would prefer to leave as many of the workarounds for that in place simultaneously as we can - defence in depth
<pitti> cjwatson: ok
<soren> Has anyone heard from persia this morning?
<lifeless> yes
<cjwatson> Nafallo: that rootflags should have been added automatically.  I'm interested in why this didn't happen; let me know when you're around to debug with me
<soren> lifeless: After the earth quake?
<lifeless> soren: I hear (2nd hand) that he is fine
<janimo> soren, in the arm channel Cody said he's glad to hear he's ok so probably yes
<soren> lifeless, janimo: Great, thanks guys.
<bdrung> didrocks: will you sync portaudio19 too?
<didrocks> bdrung: I'll have a look at remaining syncs in a few minutes
<ttx> lifeless: re:voters email, your suggestion should work, thanks!
<abhinav-> ttx, I proposed the branch for merging. however I don't know how to use submittodebian
<ttx> abhinav-: I'll pick it up when I fix the other in Debian.
<abhinav-> ok thanks :)
<abhinav-> fta: ping
<apw> pitti, do we still have a way to specify pm-utils quirks?  or did the halsectomy kill those
<pitti> apw: we do, they moved into pm-utils proper
<pitti> apw: see /usr/lib/pm-utils/video-quirks/*
<pitti> apw: they are similar in spirit to the old hal fdi rules (i. e. match on DMI vendor/product etc.), just look a little different in syntax
<apw> pitti, excellent thanks
<pitti> apw: did you see the linux powerpc failure due to an internal compiler error? (http://launchpadlibrarian.net/65965812/buildlog_ubuntu-natty-powerpc.linux_2.6.38-6.34_FAILEDTOBUILD.txt.gz); is that being discussed already?
<pitti> ogra, didrocks: ubuntu-netbook-default-settings and ubuntu-netbook-efl-default-settings packages want to go to universe now; should we just remove them completely?
<pitti> ScottK, Riddell: likewise, kubuntu-mobile-default-settings -> demote or kill?
<doko> pitti, seb128: component-mismatches:
<doko>  o gnome-user-share: gnome-user-share
<doko>    [Reverse-Recommends: gnome-bluetooth]
<pitti> doko: just re-promited
<doko> ahh, ok
<pitti> due to a mis-merge the recommends was lost
<pitti> it was added back
<pitti> doko: openoffice.org-gcj also promoted (transitional package for upgrades)
<doko> pitti: if the mythbuntu/ubuntustudio guys are in the release meeting today, could you address libconfig an dbus-c++? not sure if I'm online. there are two bug reports for it
<pitti> doko: I guess they won't join, but if they do, I'll bring it up
<ScottK> pitti: Demote.
<pitti> ScottK: together with qmf/qtmobility then?
<ScottK> pitti: I believe so.
<pitti> ScottK: ok, thanks; re-promotion is cheap anyway, in case we'll need it back
<ScottK> I know we're trying to get Kubuntu Mobile out of Main, so this fits the overall goal.
<Daviey> pitti, I'll be there.
<Daviey> doko, bug 730760?
<ubottu> Launchpad bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete] https://launchpad.net/bugs/730760
<Daviey> and bug #730759 i guess.
<ubottu> Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete] https://launchpad.net/bugs/730759
<doko> Daviey: yes
<Daviey> doko, What are you asking from us?  You want someone to take the action that mterry pointed out, or?
<doko> Daviey: yes, or demotion of libffado
<Daviey> doko, I don't know how else people do audio over firewire...  so scared to break peoples things.  But remember both mythbuntu and ubuntu studio build from universe anyway, so we don't care if it's main or universe.
<doko> Daviey: then find out what uses libffado in main, and disable it?
<Daviey> doko, ok
<Daviey> looks like jack.
<sconklin> pitti: Martin, could you please copy the Lucid linux-fsl-imx51 kernel from our PPA to -proposed?
<didrocks> pitti: for me it's ok, but check with ogra if they still uses some part of the settings
<StevenK> pitti: Should we NBS out the parts of OO.o that can be culled, or leave it as one bit lump until everything can go?
<didrocks> @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:
<ogra> pitti, put them to and leave them in universe, i think there are some people having intrest in them
<ogra> jhunt_, around ?
 * ogra is desparate with an upstart script
<pitti> ogra: ack
<ogra> hmm, probably someone else knows, i have a serial getty i only want to run if oem-config isnt running ...
<ogra> start on (runlevel [23]
<ogra>           and stopped oem-config-debconf)
<pitti> StevenK: I already cleaned it up
<ogra> is what i have now
<ogra> that works fine as long as oem-config is actually installed
<ogra> but indeed once i uninstall it the condition of "stopped oem-config..." can never be fulfilled
<ogra> how does one handle app deps in upstart jobs for apps that er being uninstalled
<ogra> *are
<cjwatson> rearrange - perhaps, for instance, you can have oem-config-debconf be 'start on starting your-serial-getty-job'
<cjwatson> (presumably as one of a set of or-ed conditions)
<cjwatson> will need some care of course
<cjwatson> that's just one possibility, intended to illustrate that you can do things other ways.  it may not work as stated
<ogra> well, i tried to replace the and with or but i end up with both runningy on the serial tty indeed
<cjwatson> Scott's recent series of upstart blog posts may be helpful
<ogra> i'll try to rearrange and indeed i dont want to fiddle with oem-confis job
<ogra> *oem-configs
<cjwatson> there's nothing necessarily wrong with fiddling with that if it's the right way to achieve your goal
<ogra> but i might break other setups
<cjwatson> obviously care is required :)
<ogra> i.e. you might want it to start on tty1 while still having a serial console
<oubiwann> cjwatson: we've got someone in the community who has proposed a patch for utouch that adds support for building rpms... the patch seems fairly intrusive, and I wanted to get your take on things
<oubiwann> cjwatson: in particular, what sort of accommodations are generally made for rpm support?
<cjwatson> oubiwann: what sort of accommodations are they asking for?  I assume it's more than just a spec file
<oubiwann> cjwatson: https://bugs.launchpad.net/utouch-geis/+bug/732829
<ubottu> Ubuntu bug 732829 in utouch-geis "No rpm spec support." [Wishlist,Triaged]
<cnd> cjwatson, I'm guessing the patch is a little malformed, it shouldn't be removing m4/libtool.m4
<cnd> and his other spec file proposals for other packages don't remove any files
<cjwatson> well, firstly, it's not desperately unusual for people to add spec files to projects; IMO it's up to the project whether they want to accept the burden of maintaining that kind of thing
<cjwatson> I suspect that he ran autoreconf on a system without libtool installed, or something
<cjwatson> those file removals seem extraneous
<cnd> cjwatson, I suppose we're looking for best practices guidance, if you feel comfortable giving any here
<cnd> we're not rpm gurus :)
<oubiwann> cnd: well, I think he just did, more or less
<cjwatson> I don't really have any :)
<oubiwann> "it's not desperately unusual for people to add spec files to projects; IMO it's up to the project whether they want to accept the burden of maintaining that kind of thin"
<cjwatson> just an opinion based on what I've seen; there isn't much consistency
<oubiwann> cjwatson: thanks, man -- that's exactly the sort of thing we were looking for :-)
<cjwatson> I do feel that people who are expecting to follow a model of finding spec files in every project are probably onto a hiding to nothing, given how many projects don't ship them
<cjwatson> but that's their problem I suppose
<cjwatson> I think if I were you I would look for an ongoing commitment to maintaining the spec file, rather than just a patch
<cjwatson> unless you're happy to test it on new versions
<oubiwann> cjwatson: right, that makes sense
<oubiwann> cjwatson: thanks again!
<cjwatson> np
<kenvandine> @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: kenvandine
<Daviey> doko, ubuntu studio is now aware of the bugs, and they are trying to come up with a solution, there will be representation at the meeting
<sconklin> pitti: Martin, could you please copy the Lucid linux-fsl-imx51 kernel from our PPA to -proposed?
<pitti> hey sconklin
<sconklin> Hi Martin
<pitti> ok, in a bit
<sconklin> thanks
<pitti> sconklin: hm, the changelog in http://launchpadlibrarian.net/66051409/linux-fsl-imx51_2.6.31-608.25_source.changes looks a bit broken
<pitti> sconklin: there's no tracking bug for this, just one bug fix?
<sconklin> yes, that's right
<doko> pitti: if this is the only concern, please ignore, currently all builds in natty breaking java fail because of this. we need the kernel on the buildds
<pitti> copied
<pitti> it just won't appear on the sru report, so if I overlook it for -updates, please pokeme
<holstein> i have a question about a couple bugs
<holstein> https://bugs.launchpad.net/ubuntu/+source/dbus-c++/+bug/730759
<ubottu> Ubuntu bug 730759 in dbus-c++ (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete]
<holstein> https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760
<ubottu> Ubuntu bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete]
<holstein> would someone have a minute to help me understand how to help with these?
<holstein> i have a few pings out to MIR team members :)
<holstein> didrocks: ping
<didrocks> holstein: hey
<holstein> :)
<holstein> you have a minute in regards to an MIR issue?
<holstein> https://bugs.launchpad.net/ubuntu/+source/dbus-c++/+bug/730759
<ubottu> Ubuntu bug 730759 in dbus-c++ (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete]
<holstein> https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760
<ubottu> Ubuntu bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Incomplete]
<didrocks> holstein: hum, quite busy there, as mterry did the first review, I'll propose waiting on him
<holstein> right
<Daviey> pitti, would you be able to look at bug #732759 FFe (NEW for universe)?
<ubottu> Launchpad bug 732759 in Ubuntu "[FFe] [needs-packaging] python-ethtool" [Wishlist,New] https://launchpad.net/bugs/732759
<holstein> the issue is, im attending a meeting in a bit
<holstein> and im not sure what all of it means
<holstein> BUT it is proposed taking libffado out of the repos
<holstein> which would be bad for ubuntustudio
<Daviey> holstein, *no*... demoting it to universe.
<holstein> right
<holstein> ^^
<Daviey> (which means JACK can't build against it)
<holstein> either way, apps will not be built with firewire support
<holstein> out of the box
<didrocks> holstein: you mean, you don't know what a symbols file is?
<holstein> didrocks: right
<holstein> im a musician
<didrocks> ok, let me find some doc
<didrocks> ok, doko is the reporter
<didrocks> holstein: let doko handle the packaging bits then, we'll figure it out :)
<holstein> didrocks: ok, thanks :)
<holstein> is this something doko is aware of?
<didrocks> I think he received the emails for that MIR
<holstein> didrocks: OK
<didrocks> and he should have seen the hilights there :)
<holstein> didrocks: I C
<holstein> thats who i wanted to talk to about it
<holstein> and wasnt able to find a nick
<didrocks> yeah, you have it now :)
<holstein> doko: seems i should have pinged you over here instead of in -meeting
<holstein> appologies
<mdz> pitti, setting techboard as the owner of ubuntu-release seems to be causing release team traffic to go to technical-board@
<pitti> mdz: I thought teams had an explicit contact point
<mdz> pitti, https://launchpad.net/~ubuntu-release says "No contact email [set]"
<mdz> pitti, should it be ubuntu-release@lists?
<pitti> mdz: right, so I'd assume it would just go to the members, as before
<mdz> pitti, adding techboard as owner seems to have also made it a member and administrator
<mdz> maybe I should just deactivate it/
<pitti> it seems utterly hard to prevent getting spammed just by setting up proper team structures *sigh*
<mdz> yes, and hard to predict what the effect of a change will be
<pitti> mdz: setting the contact point explicitly would then cause a lot of ML moderation traffic on that list, so nothing is won with that
<mdz> pitti, I deactivated TB as a member, let's see what that does
<mdz> it's still the owner, so no perms should change I think
<pitti> mdz: ah, so it's an owner, but not a member? that makes more sense anyway
 * pitti flushes the moderation queue now
<pitti> done
<pitti> mdz: we're still getting the merge request mail, but my .listadmin.ini rejects them automatically, so it doesn't really hurt any more
 * pitti pats discard_if_subject
<ScottK> ogra: Any objection if I go ahead and upload Qt building against gcc4.5 tonight or tomorrow (figuring not to do it now so GrueMaster has some time to test)?
<GrueMaster> Test?  What do I need to test one it?
<ScottK> GrueMaster: We're waiting to hear if the runtime neon detection works.
<ScottK> It's allegedly on your TODO.
<GrueMaster> Ah.  Ok.  Hmmm.  I'll have to set up a dove to test it.  And some apps that specifically hit areas that use neon optimizations if available.
<GrueMaster> I got side tracked with other High P issues.
<ogra> GrueMaster, mumble is easiest
<GrueMaster> ok
<ogra> GrueMaster, has only a small set of deps and will immediately SIGILL on startup if it doesnt work
<GrueMaster> Sigh.  Server & desktop are out of drive space.
<ogra> mean
<cnd> jdstrand, new package libgrip has been sitting in the new queue since monday
<cnd> I was wondering what needs to be done to get it approved
<jdstrand> cnd: I need to start processing the new queue. I plan to later today
<cnd> jdstrand, ok, thanks!
<cr3> hi folks, working on a plymouth bug so I want to bisect the package. after branching lp:ubuntu/plymouth, I try to debuild but get an error about a missing orig.tar file, should I be running a command other than debuild?
<kklimonda> cr3: bzr bd will make a tarball for you
<cr3> kklimonda: if I bzr revert'ed, it will make that tarball based on the files in the project rather than the latest revision, right?
<hallyn> cr3: 'bzr bd -S' is i believe the better way to create source pkg from bzr
<hallyn> oh, sorry
<kklimonda> cr3: I'm not sure, I kinda just do the stuff and it works :)
<hallyn> cr3: I'm not sure, but apart from satisfying curiosity i'd just bzr unbind and bzr checkin, and then it'll definately use the local
<kklimonda> but I always commit changes before bzr bd
<cr3> kklimonda: I rarely work from reverted revisions, first time bisecting a package
<snow_ru_> hi
<kenvandine> @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:
<thinktux> QUESTION: Why are we not being prompted during install with the option on setting password on Grub ? It is quite sad that a fresh install of Ubuntu is more insecure than Windows`98 on that point.
<ion> WORD IN ALL CAPS: if you have physical access to the box, all security measures are more or less meaningless.
<thinktux> yes, that is true. But making it so easy to invoke Runlevel 1, post-install is just wrong.
<NCommander> directhex: ping, how long until we see mono 2.10.1 in Debain experimental/sid?
<directhex> NCommander, i have no idea. it's all blocking on meebey, who is having a hard time at work at the moment so is short on debian time
<NCommander> directhex: is there a straightforward way I can drop 2.10 into a chroot and test to see if banshee still works. My attempts to build it from scratch more or less fell on their face
<NCommander> (as in build the entire mono stack up to banshee)
<NCommander> I run into the problems with mon-addins
<NCommander> *mono
<NCommander> and issues like this:
<NCommander> Method not found: 'System.Threading.Monitor.Enter'.
<NCommander> System.MissingMethodException: Method not found: 'System.Threading.Monitor.Enter'.
<directhex> NCommander, http://apebox.org/wordpress/linux/370/
<directhex> NCommander, follow that for a parallel mono, which will use system libs. then just check the banshee script in /usr/bin to see how it's calling mono
<NCommander> directhex: do I have to worry about an ABI skew or something?
<directhex> only when building mono apps
<NCommander> directhex: so I can install 2.10, and test the current banshee. That helps a lot
<NCommander> thanks
<Keybuk> jhunt_: you just totally /msg'd and ran, didn't you?
<soreau> Trying to use a live persistent usb but every single package I install tries to setup the kernel, update initrd etc but fails and takes a long time doing it. Is there a way to tell it to forget about kernel upgrades altogether?
<beuno> soreau, I guess you could pin the kernel package?
<soreau> beuno: Not sure, how can I do that?
<beuno> soreau, this is probably not the right channel to get ubuntu support  ;)   google apt pinning
<soreau> Ok thanks for the hint
<broder> soreau: you could just install directly onto the usb drive instead of using the persistent live usb stuff
<soreau> broder: I tried to do that but the live cd did not show the usb node as an option in gparted
<soreau> Actually, I'd like to install it though because the usb stick is 8GB
<soreau> and I'd like to be able to upgrade the kernel etc
<GrueMaster> ogra, ScottK:  Mumble appears to work on Marvell Dove in a chroot of natty.  Took a while, as I had to install tightvnc and a bunch of other stuff.
<ScottK> GrueMaster: Cool.  I guess we can mark that done.
<jdstrand> cnd: fyi, accepted
<wright_> hi.. i just found serious bug in ubuntu
<wright_> is this the right place to report it?
<broder> wright_: https://help.ubuntu.com/community/ReportingBugs
<wright_> thanks.. but this one is so serious that it need instant repair.. if i report there, it might be weeks that they even read it
<broder> wright_: Always start by filing a bug in Launchpad
<slangasek> wright_: you can tell us here what it is, but the bug report should still be filed in launchpad
<wright_> i found a bug what allows user to view hard drive files with sudo and this all can be done in startup
<wright_> before you even need to give your user name and password
<wright_> ok.. i will do that
<wright_> sorry my bad engilsh
<wright_> *english
<slangasek> based on that limited description I suspect you've encountered intended behavior rather than a bug, but when you have the bug report opened please point us to it
<wright_> ok
<wright_> probably becouse of my bad english i found only "Report and amend bugs using the email interface". Is this the right place. Hope not becouse i dont understand anything how to report it right.
<Ampelbein> wright_: type 'ubuntu-bug' in a terminal
<Ampelbein> wright_: it should guide you through some questions to report an issue
<wright_> ok
<wright_> damn.. when i press other problem it gives me.. i try to translate this.. you must give package or PID id
<wright_> ..feeling so stupid
<wright_> can i write it here.. that someone can report it, couse i dont know how
<slangasek> wright_: ok, go ahead and tell us about the bug
<wright_> ok
<slangasek> as I said, I suspect it's not a bug at all, in which case there's no need for us to torture you with the bug filing interface :)
<wright_> i had a mount problem with my external hard drive (it did not mount right) so i add it to /etc/fstab. I unplugged the external hard drive and start computer, Ubuntu loads and give me an mount error. Press "S" to skip or "M" to mount manually. When i press "M", i get in command promt with sudo and i can do anything. And all this was before i even need to set username and password.
<slangasek> wright_: the package to file this against is 'mountall'; I'm trying to reason through if this is actually a bug or expected
<slangasek> because the behavior is somewhat configurable
<broder> slangasek: i'm digging through the code to see what it's doing currently, but should it possibly be dropping into runlevel S?
<wright_> ok. thanks
<wright_> :)
<slangasek> wright_: so when you tell mountall 'M', it triggers /etc/init/mountall-shell.conf which calls /sbin/sulogin.  sulogin has configurable behavior; if the root user has no password, it can't *prompt* for a root password and drops you directly to a shell
<slangasek> this is documented in the sulogin(8) manpage
<slangasek> if you want to require password authentication, your root account must have a password set
<wright_> no.. i have root pass
<slangasek> so when you type 'su', you can enter a password and it works?
<wright_> do you mean type su in this "bug" or normally in command promt?
<slangasek> in a command prompt
<wright_> yes
<slangasek> ok
<slangasek> wright_: if you run 'sudo sulogin', do you get a "Give root password for maintenance" prompt?
<wright_> yes i do
<slangasek> broder: well, it's not supposed to be dropping into runlevel S
<slangasek> wright_: ok, please file a bug against mountall with 'ubuntu-bug mountall'.
<slangasek> and when it asks for information, include this information about the behavior of su and sulogin on your system
<wright_> ok.. i do that
#ubuntu-devel 2011-03-12
<calc> anyone happen to know if the day/date being in black on dark grey on the calendar is intentional? its barely visible on my screen at least
<kalon33> hello all
<kalon33> @cjwatson: Could you review again my pcsc-lite branch?
<udevbot> Error: "cjwatson:" is not a valid command.
<kalon33> please :)
<kalon33> I made the changes you asked and need your advice on them :)
<kalon33> hello, I need someone help to review a packaging branch please
<aroman> hi, does anyone know of a way to execute a script after ubiquity finishes the install? Thanks ;)
<kalon33> aroman, did you looked at the oem install mode?
<highvoltage> A/win 11
<aroman> kalon33: wouldn't that be for unattended upgrades and stuff?
<kalon33> aroman, I didn't tested it for a while (1 or 2 years) but I used to use them to prepare computers for friends
<kalon33> why did you need to execute a script ?
<aroman> kalon33: to change some gconf keys and remove a file or two
<aroman> that we can only do after the install
<kalon33> to replicate configurations, have you ever tried oneconf ?
<aroman> kalon33: this is actually a situation where the gconf keys for the livecd and the gconf keys for the installed dekstop need to be different
<abhinav-> I am trying to build the latest source release of gedit which I branched from launchpad, but on running make it is giving error that "undefined reference to launchpad_integration_add_ui" , do I need need some other libraries ?
<Ampelbein> abhinav-: looks like you miss one of the liblaunchpad-integration libraries
<abhinav-> Ampelbein, checked it. I have the liblaunchpad-integration libraries as well as its development headers.
<abhinav-> Ampelbein, is it the case that the latest release of gedit won't build on Maverick ?
<Ampelbein> abhinav-: It should build.
<Ampelbein> abhinav-: are you using the correct arguments to the linker?
<abhinav-> Ampelbein : I did not change anything. simply ran ./configure followed by make
<manish> abhinav-: do you have the build-deps installed?
<abhinav-> yes , I did build-dep for gedit
<Ampelbein> abhinav-: if the lpi (launchpad-integration) patch is applied you need to autoreconf because it changes configure.ac
<Ampelbein> abhinav-: and if you don't want to mess up your system, I strongly advise to build a debian package and install that with dpkg.
<Ampelbein> abhinav-: if you branched from ubuntu:gedit (or lp:ubuntu/gedit): 'bzr bd' should do.
<abhinav-> Ampelbein : oh, ok. I will do autoreconf. I am trying to fix a bug, so need to build and test it
<abhinav-> ok. yes. bzr bd is a better option
<abhinav-> I want to run it with a debugger
<Ampelbein> abhinav-: you can change debian/rules to not strip debugging symbols
<abhinav-> Ampelbein: ok yes. I did not know about debian/rules. Just looked at it. Thanks. It should do :)
<psusi> yay for python... 50 lines of code and I have a handy program to calculate the correlation of ordering between file names and inodes, inodes and blocks, and names to blocks for a given directory
<srk9> Would someone running Ubuntu 11.04 Alpha 3 post the output of 'strings /lib/libc.so.6 | grep "release version"'? Run that without the single quotes please.
<Laney> why not download the deb yourself?
<sebner> srk9: GNU C Library (Ubuntu EGLIBC 2.13-0ubuntu4) stable release version 2.13, by Roland McGrath et al.
<srk9> sebner: Thanks.
<sebner> you're welcome
<sebner> Laney: you meanie :P
<Laney> give a man a fishâ¦
<srk9> Laney: I am not familiar with how Canonical has things organized. I only wanted to know what version of GLIBC that they were planning to use in 11.04.
<Laney> srk9: If you look on packages.ubuntu.com you can find out which package contains that file, and then download it.
<srk9> Laney: I also did look for the .deb. I am a Gentoo Linux user, so I do not know what Canonical calls it.
<Laney> Then you can use dpkg --extract foo.deb on the file and run strings on the library contained therein
<Laney> :-)
<srk9> Laney: neat, I didn't know that Canonical had a "search in packages" feature on their site.
<Laney> you should s/Canonical/Ubuntu/ in general too
<srk9> Laney: Isn't Ubuntu a distribution while Canonical is the company behind the website?
<tumbleweed> can a core-dev please accept the nominations on bug 642913?
<ubottu> Launchpad bug 642913 in Gnome Python Desktop "python wnck bindings have broken constants again" [Medium,New] https://launchpad.net/bugs/642913
<srk9> I don't use Ubuntu Linux, so I really don't care enough to file a bug report, but I know for a fact that programs that rely on libsdl will be affected by a memcpy() issue that is triggered by using glibc 2.13 or later: http://bugzilla.libsdl.org/show_bug.cgi?id=1090 - is there any way I could casually tell someone who cares about this so that it will be patched in time for the Ubuntu Linux 11.04 release?
<ubottu> bugzilla.libsdl.org bug 1090 in video "SDL_BlitCopyOverlap() assumes memcpy() operates in order" [Normal,Resolved: fixed]
<srk9> Upstream has a patch for it, but it has not made a release with that patch yet.
<srk9> Ubuntu 11.04 will use glibc 2.13, so it will be affected by this. Anything that uses libsdl to do bliting will likely be affected. Battle for Wesnoth is one such program.
<penguin42> srk9: It appears there is at least one memove v memcpy patch in there
<penguin42> hmm but maybe not that one
<penguin42> srk9: Filing a bug would certainly be the best way and fairly easy
<hv> is it known that every emacs window (upstream, and probably the one in the repos) causes indicator-applet-appmenu to leak about a few megabytes?
<srk9> penguin42: In the Ubuntu 11.04 package? Is there any where I can see what patches were applied?
<arand> srk9: apt-get source libsdl2.0 ?
<penguin42> srk9: http://packages.ubuntu.com/natty/libsdl1.2-dev  you can see the diff.gz on the right hand side
<srk9> arand: I use Gentoo Linux. I was only passing on the information.
<srk9> penguin42: I just saw the changelog at packages.ubuntu.com. That is for a different memcpy().
<arand> srk9: Ah, ok, my bad
<penguin42> srk9: Yeh a joystick one, it doesn't look like the fix you are referring to is in there - is there an easy test that fails?
<srk9> penguin42: No. Not all systems use the reverse memcpy().
<srk9> If your system is one that uses the reverse memcpy(), you could try running Battle for Wesnoth.
<srk9> Scrolling right in a Battle for Wesnoth game tends to trigger it on systems where the reverse memcpy() is used. These seem to be only amd64 systems so far.
<srk9> Battle for Wesnoth has a bug report regarding it: https://gna.org/bugs/?17573
<srk9> Here is what it looks like when the reverse memcpy() occurs: http://img163.imageshack.us/i/wesnothbug.png/
<penguin42> nothing smaller?
<srk9> penguin42: Triggering it is not a surefire thing. It depends on the extremely complex behavior that glibc implements.
<penguin42> srk9: Sure, it's just I need to download 299MB for Wesnoth
<srk9> I see what you mean.
<penguin42> and I haven't got a clue how to play it when it arrives!
<srk9> Just start the tutorial and scroll right. It isn't a surefire thing that you will be hit by the bug unless your system is one that glibc thinks that copying backward is more optimal.
<srk9> *one where
<penguin42> ok, should be downloaded in 3 mins
<srk9> I have a better idea. arand suggested apt-get source libsdl2.0
<srk9> You can check to see if the sources are prepatched.
<penguin42> srk9: I checked, they aren't
<srk9> penguin42: Then Ubuntu 11.04 is probably affected.
<srk9> There is a testcase for this available on the libsdl bug tracker: http://bugzilla.libsdl.org/attachment.cgi?id=579
<srk9> Compiling that might be worthwhile
<penguin42> srk9: Well scrolling in wesnoth doesn't crash - but I could believe that's a corrupt rendering
<srk9> It isn't supposed to crash.
<srk9> penguin42: The only thing that occurs is corruption.
<penguin42> ok, well I'd say it's corrupt
<srk9> penguin42: Then Ubuntu 11.04 is affected. :/
<penguin42> let me just see if there is a wesnoth bug for it in lp
<penguin42> ah there is - bug 725044
<ubottu> Launchpad bug 725044 in wesnoth-1.8 (Ubuntu) "graphic corruption while scrolling right" [Undecided,New] https://launchpad.net/bugs/725044
<srk9> penguin42: The issue isn't in Wesnoth. It is in libSDL. A separate bug report should be filed for libsdl with 725044 being blocked by it.
<srk9> I don't use Ubuntu, so I don't think I have an account to file a bug report. Would you mind filing it?
<penguin42> ok
<penguin42> srk9: OK, see bug 725044 now
<ubottu> Launchpad bug 725044 in wesnoth-1.8 (Ubuntu) "graphic corruption while scrolling right" [Undecided,New] https://launchpad.net/bugs/725044
#ubuntu-devel 2011-03-13
<Stryker> is the alpha release able to support nvidia cards yet without xorg crashing?
<srk9> penguin42: I meant to file a separate bug report so that the Ubuntu SDL maintainer sees it. It turns out that I do have a launchpad account from several years back, so I will file one for that.
<penguin42> srk9: Don't need to, that bug is against libsdl now
<penguin42> (as well as wesnoth) - I guess I could update the title
<srk9> Ah, cool.
<penguin42> srk9: I tried and built an sdl with that fix in, wesnoth now does scroll right - not that I've got a clue about the game, but hey
<srk9> penguin42: Neat. I am going to post some more information in the bug report.
<penguin42> please do - and thanks for the pointer
<srk9> penguin42: Any time. I only wish there was an easier way to promulgate knowledge about bugs between distributions.
<srk9> I posted more information about this to the bug report: https://bugs.launchpad.net/ubuntu/+source/wesnoth-1.8/+bug/725044
<ubottu> Ubuntu bug 725044 in wesnoth-1.8 (Ubuntu) "graphic corruption while scrolling right" [Undecided,New]
<penguin42> srk9: Launchpad can link to bug reports in other distros
<srk9> penguin42: Really?
<penguin42> srk9: Yeh - have you got a gentoo bug for it?
<srk9> How?
<srk9> Yes. I forgot to include the link.
<penguin42> what's the URL?
<srk9> http://bugs.gentoo.org/show_bug.cgi?id=357687
<ubottu> bugs.gentoo.org bug 357687 in Core system "media-libs/libsdl assumes passing overlapping memory regions to memcpy() is safe" [Normal,Resolved: fixed]
<SpamapS> ^Z9349kB   109kB/s | Fetching revisions:Inserting stream:Estimate 91760/91939
<SpamapS> I just love checking out samba... :-P
<srk9> There is also a separate bug for Wesnoth specifically: http://bugs.gentoo.org/show_bug.cgi?id=354175
<ubottu> bugs.gentoo.org bug 354175 in Games "games-strategy/wesnoth-1.8.5 scrolling breaks with sys-libs/glibc-2.13" [Normal,Resolved: fixed]
<srk9> Ah, I see.
<penguin42> srk9: See, I added an also affects distribution
<srk9> Nice.
<penguin42> hey - how did it pick up the link to teh sdl one?
<srk9> ?
<penguin42> it somehow picked up a link to the sdl bugzilla, not quite sure how lp did that
<srk9> You posted one in a comment.
<srk9> It must have parsed the comment and detected it.
 * penguin42 didn't think it was that smart!
<srk9> I added an "Also affects Fedora", although the bug report I cited is not a fedora bug tracker bug. It is the Wesnoth bug where a Fedora user reported this issue.
<srk9> I wanted if there is some way I can change my name on Launch Pad. I would prefer to use my real first name as opposed to my email handle.
<penguin42> srk9: Ask on #launchpad for that, although it's very quiet
<srk9> Thanks.
<srk9> Is there any way for someone to nominate a bug for blocker status? This is probably something that should be addressed before Ubuntu 11.04 is released, although I am not sure if it will get attention.
<srk9> It seems I messed up. I noticed that I could add "also affects project", but it ended up being added to libsdl rather than wesnoth. :/
<srk9> I seem to have fixed it. :)
<penguin42> There used to be a 'nominate for...' but that seems to have gone
<srk9> penguin42: I guess only privileged people can use that now. Perhaps they had too many nominations.
<penguin42> I've asked on #ubuntu-bugs for someone to set priority - I'll try keep asking
<penguin42> and they've done that and added a nomination for Natty; so just sit back and we're hopefully good
<SpamapS> wtf.. samba's revision history is 300+MB ?!
 * SpamapS just had de ja vu
<SpamapS> I think I was shocked at this last summer too
<broder> That doesn't seem all that unreasonable. It's an old project, for starters
<SpamapS> yeah and a bear to maintain
<broder> Probably been rewritten, or at least heavily refactored, more than once in its lifetime
<SpamapS> 375061kB   156kB/s \ Fetching revisions:Inserting stream:Estimate 97479/97519
<SpamapS> luckily starbucks is fairly empty
<SpamapS> whats awesome.. after all of that... "Branched 102 revision(s)."
<SpamapS> broder: definitely an old package.. its on its *third* epoch
<lifeless> SpamapS: o/
<SpamapS> lifeless: 'morning
<SpamapS> or, afternoon.. ;)
<SpamapS> lifeless: all quiet down there?
 * SpamapS disappears back into the shadows
<Stryker> BREAKING THE SILENCE
<lifeless> SpamapS: yes
<porthose> Any one aware of this?  Would be interesting to see Ubuntu represented there :) http://www.nasa.gov/home/hqnews/2011/mar/HQ_11-070_Open_Source_Summit.html
<SpamapS> I think Jono Bacon lives nearby.. I'm always surprised how few ubuntu-ers are in the bay area tho
<SpamapS> tons of users.. but not many devs
 * porthose wants to see an ubuntu sticker on the side of a mars rover :)
<jason> many binary packages are built from "xorg-server" source..   it takes long time, so I want to build xorg-server-core only...  Anyone has an idea on how to build a specific binary package?
<ScottK> Unless you're going to do it regularly it would take longer to customize the packaging than to just build the whole thing.
<evilvish> porthose: iirc, maco blogged that she had seen NASA systems using Ubuntu..
<evilvish> maybe 2 yrs ago..
<evilvish> yup Â» http://ubuntulinuxtipstricks.blogspot.com/2008/07/nasa-uses-ubuntu.html
<aroman> anyone know how I can trick ubiquity into showing it's panel?
<aroman> i've gotten it to show the greeter interface by setting some environment variables, but it will not show it's panel
<abhinav-> If the development release of apport is 1.19 then why does the lp:ubuntu/apport branch is having 1.14 ?
<micahg> abhinav-: http://package-import.ubuntu.com/status/apport.html#2011-02-24%2020:16:15.351708
<abhinav-> micahg, oh ok. I had a patch for a small bitesize bug which I unknowingly developed against the branch I forked from lp:ubuntu/apport
<abhinav-> micahg : I see that lp:~ubuntu-core-dev/ubuntu/natty/apport/ubuntu has the latest version. I will branch from here and submit a merge proposal for this branch . would that be right ?
<micahg> abhinav-: yes
<abhinav-> micahg: ok thanks :)
#ubuntu-devel 2012-03-05
<micahg> slangasek: your merges seem to be lacking teh Debian changelogs
<slangasek> micahg: sigh
<slangasek> micahg: sorry
<RAOF> We should probably get some tooling to detect and reject that.
<RAOF> It's *way* too easy to neglect.
<ajmitch> what's that, missing -v?
<slangasek> missing --package-merge
<infinity> RAOF: Rejecting just because the .changes is lacking entries seems a bit harsh.  We certainly allow much buggier uploads than that. :P
<RAOF> Only because we can't catch them :)\
<infinity> Well, but a truncated .changes isn't a package bug at all.
<infinity> (Not saying we shouldn't continue to promote a best-practice of -v(last_upload), just that I don't see the point in rejecting if someone forgets)
<infinity> It doesn't affect the quality of the package at all, nor even the contents of the real changelog, just the mail to -changes, and the upload record in LP.
<infinity> (And if we're "checking" that it's correct by tearing apart the package and reading the real changelog, then LP could correct both those issues instead of rejecting)
<RAOF> It'll sometimes cause launchpad bugs that would be closed by a proper changes file to go un-closed.
<RAOF> Well, making launchpad do the right thing would be nice, too :)
<infinity> Yes, it can leave bugs unclosed.  And the upload can and should fix that. :P
<infinity> But I still don't see rejecting non-buggy packages as the answer.
<infinity> I find it about as distasteful as the people who spend hours arguing over someone submitting a patch in the "wrong" format instead of just applying it.
<infinity> Not that the two things relate at all, but in both cases, it's a question of process, not function.
<infinity> s/the upload can/the uploader can/
<hallyn> broder: stgraber: to be clear, on that bluez patch, that didn't originate with me
<hallyn> maybe i didn't do the right thing there, but i wanted to keep the guys' patch going, but didnt' have the rights to do anything but make a new merge proposal myself
<stokachu> can i ask a packaging question here or does that fall under ubuntu-app-devel?
<RAOF> It depends; is it to do with the development of ubuntu?
<RAOF> (#ubuntu-motu can also be reasonable for packaging questions)
<stokachu> ah ok ill try there
<stokachu> thanks
<RAOF> Basically - if the objective is to work on a package in the main archive, then either here or #ubuntu-motu is entirely appropriate.
<pitti> Good morning
<samy241190> bdfhjk: Hi
<apw> the binary packages from the latest linux-meta upload in precise (3.2.0.18.18) seem to be MIA, can't find them anywhere
<pitti> apw: I binNEWed them an hour ago
<pitti> they should appear RSN
<pitti> they should be there now, actually
<apw> pitti, hmmm, ahh, compat-wireless was added ... didn't spot that
 * pitti cleans up http://people.canonical.com/~ubuntu-archive/nbs.html
<apw> thanks
<pitti> apw: any chance to get a bumped linux-meta-ti-omap4, too?
<apw> pitti, will do
<pitti> cheers
<pitti> apw: linux-meta added a modules-cw package which depends on a non-existing linux-backports-modules-cw-3.3-3.2.0-18-server
<pitti> apw: is that binary package going to exist, or does -meta need to drop that?
<apw> pitti, i believe it will ... /me checks
<apw> pitti, oh is that in amd64 ?
<pitti> yes
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<apw> pitti, ok leave that with me, i think thats a thinko
<infinity> apw: It won't exist, -server was replaced with generic...
<infinity> apw: (And you just dropped the cw-server stuff in the last lbm upload)
<apw> yeah, i'll fix that and get it updated
 * infinity wonders how deeply he cares about fixing -tools-armadaxp.
<pitti> infinity: we could just drop the package temporarily instead, to get rid of the uninstallability?
<infinity> pitti: If it bugs you terribly, I can just drop it from the meta for now, sure.
<pitti> it's the one step away from beer :)
<pitti> well, now two steps since yesterday, but apw is sorting this out
<infinity> Fine.  I'll fix the meta JUST FOR YOU.
<infinity> Oh man, I'd gotten so used to the syntax hilighting in vim with the incorrect background=, that the new and correct setting just looks weird.
<infinity> Figures.
<pitti> infinity: thanks!
<pitti> infinity: yeah, the new default totally broke here as well; I added "set bg=light" to my .vimrc now
<pitti> bright text on dark background is just plain wrong
<infinity> Well, it makes some sense this way.  And that bright text definitely would have been unreadable on white backgrounds.
<infinity> Still.
<infinity> Weird.
<infinity> I might flip it back locally too. :P
<infinity> pitti: I think I stand by my belief that the new default is "correct", and old nerds like us just hate change.
<pitti> infinity: no, it's a matter of ergonomy
<pitti> at least for people who work in a bright environment
<pitti> infinity: which might not apply to night-time workers like you of course :)
<infinity> pitti: Perhaps, but edit a changelog with bg=dark, and tell me that package name field in incredibly dark blue is actually readable without eye strain.
<pitti> infinity: oh, it's certainly matching our default terminal colors better
<infinity> (I'm used to it, and I pretend it's readable, but I'm not sure it actually is)
<pitti> infinity: but I never said that _those_ were correct either
<infinity> ;)
<infinity> pitti: Oh, wait.  Do you use white terminals?
<pitti> yes, of course
<pitti> well, white-ish
<infinity> pitti: Oh, kay, then I misunderstood your complaint.
<infinity> pitti: And I choose to just pretend people like you don't exist.  Terminals should be black. ;)
<infinity> pitti: (But as I noted when the change was being discussed, it shouldn't be hard to make vim smart enough to actually detect the bg hue and DTRT... termcap makes that available)
<pitti> yeah, and many centuries of experience in book printing just got it all wrong
<infinity> pitti: So, yeah, someone really should do that.
<pitti> infinity: indeed I actually thought that vim did that already
<pitti> until it got that explicit default
<infinity> pitti: You'd think, but apparently not. :/
<infinity> pitti: No, before that default change, I was getting your "light" colours in my black terminals.
<infinity> pitti: It would be stellar if someone sorted out making it smart.
<apw> pitti, ok linux-meta is building ...
<infinity> (And maybe the smart is already there and the Debian package just fails to turn it on or something silly?)
<infinity> pitti: meta-armadaxp uploaded mit fixen.
<pitti> infinity: cheers!
<YokoZar> ScottK: ~email to u-devel -- I see priority: required on apt-cache show libncurses5, which is the same as dpkg...
<micahg> YokoZar: dpkg is Essential: yes
<YokoZar> micahg: Ahh I see my source of confusion. I'm not talking about the essential field then, I'm talking about the priority field.  Is it not the case that all priority: required packages are installed on a system?
<YokoZar> (of the system native arch, that is)
<micahg> YokoZar: no
<micahg> only Essential: yes
<YokoZar> so, uh, what's the point?
<YokoZar> The point of the Priority: Required category, rather
<micahg> YokoZar: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies
<micahg> YokoZar: they're generall installed, but you can't depend on them being there unless they're Essential: yes or (usually transitively Essential: yes)
<YokoZar> micahg: See, I was confused by http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities  which seems to indicate that removing a required package is something that can totally break things (dpkg included), and (perhaps wrongly) interpreted that as being safe to assume they're there
<micahg> YokoZar: they usually are, also, I'm curious why ${shlibs:Depends} isn't adding the dependency for you
<YokoZar> micahg: I was wondering that myself.  It seems Wine likes to dlopen libraries at runtime and fail gracefully if they're not there by disabling components
<YokoZar> Which makes me think I have potentially a lot of missing dependencies that are only now coming out.
<micahg> well, normally that's called friendly :)
<YokoZar> meh, if the program quits on startup because it can't dlopen a particular library, it might as well be flat out linked against it
<YokoZar> (as was the case with libncurses)
<micahg> yes, I'd suggest that's an upstream bug then
<apw> pitti, how often does the problems page update?  hopefully everything is published
<dholbach> good morning
<pitti> apw: every half an hour after the publisher
<apw> pitti, with luck things should be good by :30 then
<cousteau`uni> I have a suggestion for a keyboard layout, where should I send it?
<cousteau`uni> (it's a modification on the Spanish layout; it adds n- and m-dash, 1/4 and 3/4 fractions, and dead caron)
<cousteau`uni> I made an xkb file for it; I don't have it here but it's on my PC at home
<cousteau`uni> (now it's when someone will tell me that xkb isn't used anymore or something like that...)
<RAOF> cousteau`uni: Upstream is a good place for that - bugzilla.freedesktop.org.
<cousteau`uni> ok
<cousteau`uni> Ok, I think I have an account on that site; however I forgot the user and password.  Any clue?
<cousteau`uni> (i.e. user is a name or an e-mail address?  and were there any restrictions on the password?)
<RAOF> email address, no restrictions.
<jalcine> Reset?
<cousteau`uni> jalcine: would need the user for that
<cousteau`uni> RAOF: ok
<cousteau`uni> I'm starting to think I don't have an account there...
<tjaalton> is there a master bug for '..foo/changelog.Debian.gz is different from the same file on the system' install errors?
<micahg> tjaalton: idk, there's Bug #871083
<ubottu> Launchpad bug 871083 in libtasn1-3 (Ubuntu Precise) "gzip -9n sometimes generates a different output file on different architectures" [Medium,Triaged] https://launchpad.net/bugs/871083
<tjaalton> micahg: thanks, would that mean a rebuild of the affected packages is needed?
<micahg> tjaalton: I think so
<tjaalton> alrighty
<micahg> dholbach: did you get an FFe for mdbtools, looks like it needed one
<dholbach> micahg, really? why?
<micahg> * Added support for REPID (UUID) fields. Thanks Will Daniels from Ubuntu.
<tjaalton> hmm, though looks like this time the fault was in not having a i386 version update available and the amd64 update failed with that error
<dholbach> micahg, it's a small patch which makes the exported data a bit more useful by adding another piece of data
<dholbach> micahg, I didn't read that as a new feature
<micahg> well, IANA release team member, maybe one can chime in :)
<dholbach> sure you can :)
<jalcine> dholbach: loved your post about the Ubuntu weekend :)
<dholbach> micahg, but in general the update looked like a good idea, as it fixed a crash and it was requested by the debian maintainer who seems to have a look over things, so I felt additionally encouraged :)
<dholbach> jalcine, thanks a lot
<dholbach> jalcine, I'm going to write a summary of the activity in a bit
<micahg> dholbach: oh, I agree it was a good idea, just thought it needed an FFe, that's all :)
<dholbach> jalcine, and I'm already looking forward to the next Friday :)
<jalcine> Same here!
<dholbach> micahg, thanks a bunch for keeping an eye on things :)
<apw> cjwatson, would we expect an external esata connected drive to be handled sensibly ?  ie mounted when connected etc?
<cjwatson> don't see why not
<apw> cjwatson, it seems to behave like its an internal drive, it detects it ok as it appears etc, but i have to open 'disk utility' and hit mount to get it moutned
<infinity> I tend to prefer them to behave like internal ones.
<infinity> But I'm not sure what the "normal usecase" is.
<broder> i thought you couldn't tell from udev whether or not a sata drive was esata or internal
<apw> infinity, yeah not clear cut, but i'd say that could apply to any external drive
<broder> so udisks treats them all as internal
<Laney> .
<Laney> oops
<apw> broder, then our handling of new internal drives is also poor, as i added this 'internal drive' and there is no interface i can find to make it mount by default
<apw> yeah i can edit /etc/fstab cause i is smart, but ...
<infinity> Well, and I use eSATA drives as "normal system" drives.  I'm not sure I'd want to deal with the strange races involved in, say, my system trying to simultaenously mount it on my desktop and rebuild a raid array from the cold-swap.
<apw> infinity, indeed, but i have wanted that in that past with USB drives, an option to say "this is a key drive, the world is over without it" seems reasonable either way
<apw> pitti, ahhh frothy beer
<ogra_> woah
<ogra_> ogra@horus:~$ mkdir bin
<ogra_> ogra@horus:~$ cp /bin/ls bin/foo
<ogra_> ogra@horus:~$ foo
<ogra_> Segmentation fault
<ogra_> evil
<apw> ogra_, arm ?
<ogra_> apw, yes, works fine if i re-loagin to do a "sudo -i -u ogra"
<ogra_> *login
<apw> ogra_, worked for me not on arm
<ogra_> did you have ~/bin in your PATH already ?
<ogra_> it only happens for me if it isnt in PATH and i newly create the dir without re-login
<apw> nope bin not in my path
 * ogra_ will try on armhf to verify it happens there too
<ogra_> still running el here
<pkh> is this the right place to discuss kernel issues with the latest beta?
<ogra_> try #ubuntu-kernel
<pkh> cheers.
 * micahg wonders if anyone's interested in processing a round of removals
<Daviey> stgraber: Have you seen, bug 946754?
<ubottu> Launchpad bug 946754 in dnsmasq (Ubuntu) "dnsmasq does not respect/watch '/etc/hosts' updates" [Undecided,New] https://launchpad.net/bugs/946754
<dupondje> could somebody have a look at https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264
<ubottu> Launchpad bug 776264 in cryptsetup (Ubuntu) "Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,New]
<geser> dupondje: have you checked if any packages depending libcryptsetup1 build with the new libcryptsetup-dev? as there was a API change
<debfx> dupondje: you should subscribe ubuntu-release to the bug, it needs a FFe
<stgraber> Daviey: the latest NetworkManager upload actually turned off /etc/hosts parsing entirely giving that job back to the libc/nss
<dholbach> jelmer, mvo: mhall119 and I ran into a small problem with UDD work-flows - basically it was just about this use-case: branch ubuntu:geany, use edit-patch to change a .desktop file - the resulting diff is HUGE because of applied quilt patches
<dholbach> do you think we should add a    quilt pop -af; bzr commit -m "unapply quilt patches"     step somewhere?
<dholbach> and where might be a good place for this?
<dholbach> it's certainly confusing contributors and reviewers alike
<seb128> dholbach, that commit idea seems a workaround, it mean you couldn't bzr merge without getting that "buggy commit" in the middle
<dholbach> seb128, yes it is a workaround
<dholbach> but it makes things a bit less confusing
<mhall119> seb128: right now, making a 1-line change to geany.desktop.in results in a 4745 line diff
<seb128> mhall119, dholbach: I'm not saying "right now" is not buggy ;-)
<dholbach> yeah, it'd be nice to get some advice on what might be a good way of solving it or in the meantime workaround it, so we can let new contributors know what to do
 * seb128 puts debian dir only desktop vcs use 
<seb128> ups, "pets"
<mhall119> seb128: I'm going to try and get the quicklist and keywords contributors making proper patches, as requested, but I need an easy-to-follow process that "just works"
<seb128> mhall119, yeah, anyway I'm not the one working on that, I was just doing a side comment so I'm stepping out
<mhall119> dholbach: it looks like edit-patch *should* be quilt pop'ing all the patches before it commits
<dholbach> mhall119, the question is: should it commit the unapplied patches into history?
<mhall119> so the question is, when there are applied patches on the branch, should they be unapplied in a separate revision from the actual change, or as part of the same revision
<dholbach> :)
<mhall119> not so much "if" as "when"
<cjwatson> absolutely not in a separate revision
<mhall119> cjwatson: why?
<cjwatson> because each revision should be self-contained
<cjwatson> if there are applied patches on the branch, then you should leave the branch that way
<cjwatson> if there are unapplied patches on the branch, then you should leave the branch that way
<mhall119> cjwatson: ok, but edit-patch unapplies all patches
<cjwatson> edit-patch shouldn't be changing the branch handling policy
<mhall119> so should edit-patch not be used?
<cjwatson> surely it should be fixed
<mhall119> so that's a bug in edit-patch?  If so, I'll file a bug report
<cjwatson> sounds like it; it should try as hard as possible to leave stuff the way it found it ...
<dholbach> ogra_, were you going to upload https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618?
<mhall119> cjwatson: filed bug #947180
<ubottu> Launchpad bug 947180 in devscripts (Ubuntu) "edit-patch should not unapply quilt patches" [Undecided,New] https://launchpad.net/bugs/947180
<ogra_> dholbach, see -changes, already done
<dholbach> aha
<ogra_> (it needed some changes, i didnt bother to ask GrueMaster to change it again but made them on the go)
<dholbach> ogra_, should it be marked as merged then?
<jokerdino> hey thanks dholbach !
<dholbach> ogra_, or maybe rejected as it wasn't merged as is
<ogra_> dholbach, oh, indeed, will do, thanks for the pointer
<jokerdino> (not intended to be completely random, but was just too excited)
<dholbach> ogra_, it's possible you can't reject it yourself, but somebody else in here should be able to do it
<ogra_> i dont want to reject it ... but mark it merged with the comment that i dropped a misaligned chnage from a former iteration
<ogra_> and i think i can mark it as i used to own the branch it wants to be merged in (at least in the past)
<dholbach> or did you file one already?
<dholbach> oops :)
<dholbach> can somebody reject https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618 please? (fixed in a different way)
<ScottK> I think ogra_ has to do it.
<lynxman> Question about packaging, if I wanted to say that package B is an upgrade for B but also obsoletes package A just adding in the control file Replaces: A would be enough?
<ogra_> dholbach, so why the heck do i have to do all this crap, it now took me 20min of paperwork for a less than 5 min package fix (incl. upload)... i though UDD would nowadays just take care of it
<ScottK> lynxman: if it replaces some of the files in A, but not the entire package.  If it entirely supercedes it, you need both Replaces and Breaks.
<dholbach> ogra_, I guess if it's fixed in a different way, the machinery can't figure out which fix it originally was and how it was applied
<lynxman> ScottK: it entirely supercedes, so Replaces and Breaks then?
<dholbach> ogra_, I don't know all the internals
<ScottK> Yes.
<ogra_> well, why cant i just mark it merged with a comment that a part of the merge was omitted
<lynxman> ScottK: cool, thank you :)
<ScottK> You're welcome.
<dholbach> ogra_, I'm sure there's a bug open about it - I don't know - I mostly just asked in here and somebody with more powers in LP did it for me
<ogra_> ah, seems i can, i just tried it with the wrong button
<dholbach> aha!
 * ogra_ was expecting it in the review pulldown at the bottom 
<stgraber> dpm: hey there, any idea when I can expect a go/no-go from the translations team on bug 926493?
<ubottu> Launchpad bug 926493 in ubiquity (Ubuntu) "[UIFe] The installer still says your picture will be used on the login screen" [Low,Triaged] https://launchpad.net/bugs/926493
 * dpm looks
<mhall119> when running 'quilt' commands, should I be in the ./debian/ directory, or in ./?
<mhall119> in ./ it thinks everything is applied but can't find a series file, in ./debian/ it thinks none are applied but it sees the series
<cyphermox> mhall119: do you have a ~/.quiltrc file?
<cjwatson> you should not be in the debian/ directory
<cyphermox> mhall119: sounds like QUILT_PATCHES isn't set
<mhall119> cyphermox: no
<dpm> stgraber, +1'd it with a suggestion
<cjwatson> http://paste.ubuntu.com/870039/ <- my .quiltrc
<cjwatson> (though 'export QUILT_PATCHES=debian/patches' is sufficient for a one-off)
<mhall119> ok, that got it working
<mhall119> it that needed for edit-patch to run?
<stgraber> dpm: any suggestion on who to poke to get a nice proper english sentence that sounds right? :)
<mhall119> ah, nvm, I see it's being set in edit-patch
<dpm> stgraber, try with mattprice
<GrueMaster> ogra_: dholbach, what was wrong with my patch (other than maybe no changelog entry (which I thought was autogenerated)).
<dholbach> GrueMaster, I was just wondering why it was still on the list
<dholbach> I had no specific comment about the patch itself
<dholbach> can somebody please reject https://code.launchpad.net/~nik90/ubuntu/precise/software-center/add_quicklist/+merge/94178 from the list?
<dholbach> err, reject the MP :)
<stgraber> dpm: ok, poked him
<GrueMaster> I pushed it Friday, and ogra said he would pull it in today.
<stgraber> dpm: thanks
<dpm> stgraber, no worries ;)
<infinity> stgraber: I prefer the proposed string with s/some/certain/
<dholbach> GrueMaster, likely a problem in the machinery - it didn't get the memo
<GrueMaster> ah.
<mhall119> mvo: dholbach: cjwatson: https://code.launchpad.net/~mhall119/devscripts/fixes-947180/+merge/95929
<mhall119> that should fix the problem I was having
<mvo> mhall119: in a call right now, but from looking at it for 3s it looks fine
<ogra_> GrueMaster, your patch had changes in the mx5/imx51 section that were bogus, i just omitted them and merged the rest (as i said in the merge comment on LP)
<GrueMaster> Oh.  Actually, they weren't bogus as they actually fixed a potential problem I noticed when editing the code, but I can easily re-add them and push them.  I had just forgotten about them when I made the initial no-mtd fix.
<ogra_> they wre between two case statements
<ogra_> that would have choked heavily :)
<ogra_> i thought it was just an accidential paste, the code surely didnt belong where it was
<TREllis> slangasek: hmmm, don't suppose gconf 3.2.3-2 will make precise? it had some multi-arch fixes
<GrueMaster> Looking at my actual code, it looks like somehow the ;; got pasted in at the beginning of the if statement.  Not sure how that happened.
<ogra_> right, thats what gave me the impression there was something wrong with the first bit of the patch
<ogra_> but since i had promised you i would merge it asap i took the working part of it :)
<GrueMaster> Ok.  Well, it isn't critical, but it does fix a potential issue of no-mtd on Freescale platforms.  I'll fix and repush.
<GrueMaster> Or push as separate I should say.
<ogra_> just give me a pastebin with the patch and i'll upload immediately
<hrw> is there a command which will grab bug info from launchpad?
<brendand> hrw, there should be
<brendand> don't know if there is though
<brendand> someone could surely whip one up in launchpadlib in a few moments
<mhall119> seb128: updated https://code.launchpad.net/~mhall119/ubuntu/precise/geany/add_keywords/+merge/94825 after fixing edit-patch, does it look good now?
<seb128> mhall119, if you actually file the "## Description: add some description"  "## Origin/Author: add some origin or author" "## Bug: bug URL" yes
<seb128> mhall119, that and lp: #.... in the changelog so the bug gets closed on upload
<mhall119> seb128: ah,  didn't know I had to further edit the patches
<seb128> mhall119, well it's clearly written ;-)
<mhall119> seb128: written where? edit-patch  made it and committed it for me without prompting me to change those parts
<seb128> mhall119, at the top of the patches
<seb128> mhall119, hum, edit-patch shouldn't commit for you...
<seb128> it should create the patch so you can bzr diff
<seb128> review your change
<seb128> edit if needed, then commit
<mhall119> seb128: (LP: 942154) or (Closes: 942154)
<seb128> mhall119, lp: #nnnn
<mhall119> pushing changes
<ScottK> mhall119: (Closes: #nnnnnn) is for Debian.
<jodh> brendand: lptools pkg, wget -O /tmp/${bug}.txt https://bugs.launchpad.net/bugs/$bug/%2Btext, http://people.canonical.com/~jhunt/scripts/lp-show-bug.py (caveat - hideous code).
<brendand> jodh, would be nice to have something in universe that does it
<SpamapS> Will precise-backports open early this cycle?
 * ScottK doesn't think the tech board has approved it yet and there are some LP changes needed in any case.
<ScottK> broder: ^^^?
<Laney> pretty sure they did approve it, but at any rate the implementation isn't ready AFAIK
<Laney> not sure what the blockers are though
<Laney> at least n+1 initialisation
<SpamapS> Ah ok
<SpamapS> Since we're being conservative and not shipping PHP 5.4.0 , I want to get it into precise-backports early.
<SpamapS> We've never had a PHP version in backports, but in this case, I think its going to be key given the unfortunate timing of their release.
<micahg> SpamapS: it will require a install/run test of all the reverse dependencies
<SpamapS> micahg: I think its time we re-evaluate what "test" means. :)
<Laney> test already is the loosest it can be
<micahg> SpamapS: and PHP being what it is, I think we'd have to ask for some type of commitment to keep the backport updated for security patches
<infinity> Yeah, I don't like the idea of shipping a backport that we think many/most people will end up installing.
<infinity> At that point, it's worth re-examining the possibility of a freeze exception, with perhaps a loose "and make it 5.4.1 ASAFP".
<SpamapS> infinity: would you argue instead for just shipping 5.4.0? I've closed that door a few times only to have a few people try and kick it down again.
<infinity> Cause well all knw dot-zero from php.net is lollerskates pretty much every time.
<infinity> SpamapS: Well, I really don't want to see 5.3.x not being used in favour of an unsupported backport.
<SpamapS> infinity: the release process is light years different.. I think this one may be at least better.
<infinity> SpamapS: And that's what's likely to happen in your scenario.
<infinity> SpamapS: Unfortunately, many webapps will break horribly with the pass-by-reference changes.
<SpamapS> infinity: 5.3.x is just as likely to be used by stubborn organizations.
<infinity> SpamapS: Which is a non-issue for 3rd party stuff, but sucks for anything we ship.
<SpamapS> 5.4 has a pass by reference change?
<infinity> Uhm.  Yeah.
<SpamapS> I thought that was 5.3's big suckage
<SpamapS> infinity: oh, that has been spitting E_WARNING since 5.3 was released 3 years ago. I have almost no sympathy for those people who ignored that change.
<SpamapS> I think even 5.2 had it as an E_DEPRECATED
<infinity> SpamapS: As long as nothing in the archive breaks, I don't care.  3rd party upstreams will fix their shit.
<infinity> SpamapS: But yeah, with my release hat on, if our options are "split the userbase between 5.3.x and an unsupported 5.4.x backport" or "just effin' make 5.4.0 work", I'm for the latter.
<SpamapS> infinity: Yeah, thats why we're not shipping 5.4.. because *ZERO* people stepped up to test anything in the archive.
<infinity> SpamapS: That needs some commitment from the server team of making sure it kinda works.
<infinity> SpamapS: And I care less about webapps here than making sure extensions DTRT, etc.  Which should be trivial.
<infinity> SpamapS: But some few "important" webapps we ship should be tested...
<SpamapS> I believe I found only 2 php dependencies in main, and they both work fine w/ 5.4
<micahg> backports doesn't particularly care about the main/universe split :)
<SpamapS> but the 107 other reverse deps .. no clue if they work
<infinity> SpamapS: Putting it in the inverse, I'd be inclined to forbid 5.4.x backports if we ship 5.3.x. :P
<infinity> SpamapS: So, given all those options, shipping 5.4.x seems the least nasty.
<infinity> But *some* testing needs to be done.
<infinity> Really.
<infinity> At this point in the game, we can't guess.
<SpamapS> infinity: so, if we went the 5.4.0 route.. we are ignoring the fact that MANY users are only just now migrating to 5.3.x .. so *they* will be even less likely to upgrade to precise.
<SpamapS> Or they'll go on some wonky unsupported 5.3.x package.. or upstream
<infinity> I don't see that as an issue.  New releases have new software.  They'll learn to cope.
<micahg> SpamapS: that means they skipped lucid as well or so it would seem
<SpamapS> micahg: there are quite a few questions out there on the forums and askubuntu about how to run 5.2.x on lucid
<infinity> And yes, lucid was 5.3.x
<SpamapS> I really want to ship 5.4.0
<infinity> People running old releases are more rare than people wanting the new shiny.
<SpamapS> Ondrej from the Debian PHP team suggested I should do it.
<PaoloRotolo> Hi all!
<SpamapS> infinity: hrm.. not sure I agree with that from my experience w/ PHP. Its bass-ackwards from most of the other languages.
<SpamapS> infinity: thats part of the reason the PHP devs adopted their new stricter release process.. because people were almost completely unable to upgrade due to the insanity of the past 5.1.x -> 5.2.x and 5.2.x -> 5.3.x
<infinity> From my experience maintaining it in the past, there was always a small set of corporate holdouts that hated rewriting that stayed on old versions for "too long", and everyone else upgraded to CVS versions before they were even released. :P
<infinity> But that was then.
<infinity> I'm not sure how things work now, to be fair.
<SpamapS> Every PHP meetup I go to is full of sad developers who are forced to stay on ridiculously old versions because they have no test suite and tens of thousands of lines of code.
<infinity> Still, I think shipping a new language version in backports is the wrong answer to any of these questions.
<SpamapS> I think we should kick them in the shins w/ 5.4 actually
<infinity> lucid is still supported for 3 more years if people need 5.3
<infinity> And heck, hardy is supported for another year, if they need 5.2
<SpamapS> ok, since this issue has been raised from the dead I think 5 times now.. it warrants a re-evaluation of my priorities.
<infinity> To be honest, I'd like to go back in time and spend a couple of weeks on evaluating apache2.4 as well, but at least that one's not "necessary" for anyone, just nice-to-have.
<micahg> SpamapS: well, that's why I'm shocked by the new PHP roadmap in general, things would seem to be moving too fast for most PHP devs
<Laney> I wouldn't mind shipping 5.4.* in Precise, but breaking half the Universe package would be uncool, so some evaluation is needed. I also don't think I would forbid a backport on principle if there is a maintenance commitment (aside: we should extend tools like the CVE tracker to cover backports).
<infinity> And, well, every bit of software has an "I wish it was newer" version.
<infinity> Laney: If there was a maint commitment, sure, but I don't honestly see that happening.
<micahg> Laney: I didn't say anything about forbidding on principle, that was infinity :)
<Laney> I didn't say I was addressing you micahg :P
<Laney> maybe I was with the CVE comment though ...
 * Laney runs
<micahg> Laney: oh, silly me with my backport highlight :)
<infinity> backport backport backport
<infinity> This could be fun.
<ogra_> backwards rolling releases ?
 * Laney eyes the universe page on the CVE tracker
<Laney> bad community
<infinity> No biscuit?
<micahg> Laney: people in glass houses :)
<infinity> ... shouldn't walk around naked?
<ogra_> depends
<infinity> ogras in glass houses shouldn't walk around naked?
<infinity> Anyhow.  Back to work with me.
<infinity> SpamapS: Ping me and keep me in some sort of loop about whatever's going down.
<infinity> SpamapS: As Laney says, a backport with a firm support commitment would probably be fine, but I don't see the security team agreeing to it, and I suspect your team doesn't want to maintain a precise backport for five years.
<SpamapS> infinity: I'm going to put 5.4.0 in a PPA and make a call for testing.. and test whatever I can myself.
<infinity> SpamapS: But.  I could be wrong on the latter (I suspect I'm not wrong on the former)
<micahg> the security team will not be supporting the backport :)
<SpamapS> infinity: one thing thats going to suck is how many upstreams are not ready for it because it only came out 2 weeks ago.
<infinity> Most of the "important" ones move pretty fast.
<mhall119> seb128: ping
 * SpamapS is convinced the backport is a bad idea.
<infinity> And, as you point out, the one really nasty change has been a deprecated/warning for years.
<seb128> mhall119, hey
<SpamapS> infinity: right, but at this point in the cycle.. shouldn't we be moving.. slow. ;)
<mhall119> seb128: your last comment on https://code.launchpad.net/~mhall119/ubuntu/precise/geany/add_keywords/+merge/94825 was talking about quicklist changes, but the MP is for keywords
<infinity> SpamapS: Yup.  I'm just trying to mediate a lesser of multiple weevils in this case.
<micahg> SpamapS: you have the option to backport PHP later as well if at some point you find testers/people willing to help make sure security updates flow (i.e. build and don't break the old backport)
<seb128> mhall119, your upstream pull request link confused me
<seb128> mhall119, you have 3 patches there, 2 of them dealing with lists
<mdeslaur> oh, please, let's not ship an LTS with a .0 PHP release
<infinity> SpamapS: If enough testing can happen "soonish", my preference is definitely with shipping 5.4.0, and maybe even a short-term (ie: not standing) SRU exception to jam a point release into updates post-release.
<mdeslaur> trying to maintain that security-wise for the next 5 years will be brutal
<mhall119> seb128: one pull request should have been deleted....
<mhall119> I'll go back and check
<infinity> mdeslaur: And 5.3.x for another 5 years won't be? :)
<seb128> mhall119, thanks
<seb128> mhall119, otherwise the keyword stuff looks good now
<mdeslaur> infinity: no, because the code stopped evolving...the thing with .0 releases is everyone then panics and does major changes in .1 and .2 and .3 and then we're stuck with code that's not like the previous stable release, and looks nothing like the current stable release
<infinity> mdeslaur: PHP vulns seem to be pretty awesome at applying universally all the way back to 4.0 (and sometimes 3.x!)
<infinity> mdeslaur: I'm told by SpamapS that the release process has "changed".  I'm kinda taking his word on that.
<infinity> mdeslaur: Though, the part where they had eight RCs is a good sign.
<mdeslaur> infinity: aren't you on the release team? you should be fighting against major last minute changes like this in an LTS, not arguing for them :)
<infinity> mdeslaur: I'm fighting against shipping a 5.4.0 backport that's unsupported and we know damn well a large number of users will use.
<mdeslaur> yeah, I don't think we should be doing that either
<mdeslaur> they can wait until lts+1, or get it from a PPA
<infinity> mdeslaur: But I too am in the "php dot-zeros suck" camp from my years of maintaining it, which is why I'd be willing to have a post-release temporary SRU exception for a dot release or two.
<infinity> I just think that is a large enough number of users will be looking elswwhere for PHP (and not the ones that always build it themselves anyway), we need to sort out how to make this the least scary nightmare.
<mdeslaur> infinity: ah, yeah, that would make more sense then living with .0 for 5 years...
<infinity> (Other than dropping PHP completely, so don't suggest it)
<mdeslaur> hehe
<infinity> But yeah, I think a couple of dot releases would likely solve my concerns and yours.
<infinity> Assuming 5.4.x is viable at all, which SpamapS will test.
<infinity> Until that testing's vaguely underway, I don't much care about the other tangents of the conversation anyway.  Cause the point may prove moot.
<infinity> But if it looks really viable, we can make it work.
 * mdeslaur nods
<infinity> We have the flexibility and a little bit of creativity between us. ;)
<SpamapS> mdeslaur: the PHP release process is *completely* different. No major features or backward incompatible changes are allowed in 5.4
<SpamapS> mdeslaur: and they are targetting releaseing 5.5 in *October*
<SpamapS> mdeslaur: https://wiki.php.net/rfc/releaseprocess
<SpamapS> "No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis.
<SpamapS> "
<SpamapS> mdeslaur: lets not get too far ahead of ourselves, but I think we might even be able to consider a micro release exception
<SpamapS> *IF* they prove disciplined in sticking to this RFC
 * mdeslaur crosses fingers
<cjwatson> hallyn: so, grub2 is failing its tests for me: it's non-deterministically hanging when trying to halt a qemu instance
<cjwatson> hallyn: Debian's qemu has got through 20 runs of that test without failing, so I think this is a bug in Ubuntu's qemu.  What do you need?
<hallyn> cjwatson: i have no idea.  Since i'm basically out all this week i'm afraid i may have to ask someone else to look at it.  But, how do i reproduce?
<cjwatson> http://people.canonical.com/~cjwatson/tmp/grub-test-build.tar.gz - untar and run  for x in `seq 1 100`; do echo "RUN $x"; /bin/sh -e ./grub-shell --qemu-opts= --modules= ./grub_script_break; done
<cjwatson> (that's actually finished uploading now ...)
<cjwatson> I can try to decompose this a bit further so that it doesn't need a full build tree
<hallyn> downloading
<cjwatson> ok, http://people.canonical.com/~cjwatson/tmp/grub-breaks-qemu.iso, considerably smaller
<cjwatson> qemu-system-i386 -nographic -serial file:/dev/stdout -monitor file:/dev/null -hda grub-breaks-qemu.iso -boot c
<cjwatson> should print a load of output and exit; instead, sometimes prints the same load of output and hangs
<hallyn> cjwatson: http://people.canonical.com/~cjwatson/tmp/grub-breaks-qemu.iso permission denied
<cjwatson> sorry, fixed
<hallyn> haven't reproduced it yet, but i wonder if it's a seabios bug
<cjwatson> hallyn: I'm on an amd64 kernel with i386 userspace, if that matters; but since Debian qemu works and I see the same thing with qemu-system-x86_64, it seems not
<broder> ScottK, SpamapS, Laney: the TB has approved the policy, but i want to ping them about one tweak. lp needs to be modified in a couple of key ways for us to accept backports when the archive is not frozen/released. and i need to write the bot that tells us when the release pocket might have a change that backports doesn't
<broder> (i want to tweak the requirement about the components that are enabled for backports builds - TB approved making it the same as the rest of the archive, but i want to nix that given how we ended up deciding to implement it)
<hallyn> cjwatson: how often would you say it hangs for you?
<hallyn> i'm doing 64-bit userspace.  guess i'll debootstrap a 32-bit userspace and try it in a chroot
<cjwatson> hallyn: it's a bit sporadic, but somewhere between 10% and 50% of the time
<cyphermox> jdstrand: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/947416
<ubottu> Launchpad bug 947416 in ufw (Ubuntu) "DHCPv6 isn't allowed through" [Undecided,New]
<jdstrand> cyphermox: thanks! :)
<cyphermox> np :)
<cyphermox> it's getting ridiculously late to notice this, but oh well ;)
<broder> if anybody's got a sec, i'd appreciate a second pair of eyeballs on https://code.launchpad.net/~broder/ubuntu/precise/bluez/bluez-respawn/+merge/95979
<broder> i think i got the maintainer scripts right, but i've never been good at the weird corner cases like these
<hallyn> cjwatson: still not reproduced (in a seq 1 100 on i386 chroot right now, still going)
<cjwatson> hallyn: huh
<cjwatson> hallyn: that's bizarre, I saw it first in sbuild where there's definitely no funny business
<cjwatson> i386 chroot on amd64 install should be completely equivalent
<hallyn> cjwatson: can you see if you can reproduce it in gdb with qemu-kvm-dbgsym installed?
<hallyn> cjwatson: oh, when you tried debian's qemu, that was with precise's seabios installed?
<SpamapS> am I crazy or does my focus seem to just jump around every once in a while while typing in precise?
 * SpamapS suspects a new obscure keyboard shortcut
<hallyn> not your huge-ass trackpad?
<SpamapS> its 2 feet away from my fingers which are on my USB keyboard ;)
<lifeless> see
<lifeless> thats huge ass
<SpamapS> could be its catching clicks from dust falling in the room
<hallyn> :)
<lifeless> if you can hit it from 2ft away
<hallyn> <chekcs bofh calendar>  solar flares
 * SpamapS does breathe heavily
<hallyn> SpamapS: i personally haven't seen anything like that, but then i keep hitting the 'menu' key and getting terminal menu, so might not even notice if it was there
<hallyn> cjwatson: yeah, 100 runs in i386 chroot, no hangs
<hallyn> trying to think what coudl be different
<hallyn> are you on amd?
<infinity> Host kernel version?
<hallyn> 3.2.0-17-generic #26 for me
<imbrandon> SpamapS: i get/got that with my bluetooth mice batterys go low and i get random ghost clicks
<hallyn> cjwatson: you're running with kvm enabled right?
<ajmitch> SpamapS: php 5.4.x came up again? I didn't test much beyond merging an RC & seeing what extensions broke because of how the RCs were still coming out
<imbrandon> ajmitch: its not too bad been running our apps on 5.4 a few weeks in prep
<imbrandon> ajmitch: even got runkit working :)
<mhall119> mvo: I submitted the edit-patch changes upstream too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662689
<ubottu> Debian bug 662689 in devscripts "devscripts: [edit-patch] should not unapply quilt patches" [Normal,Open]
<Daviey> mhall119: Fancy making it not prepend stock (##'d out) DEP-3 headers when there are already valud entries there
<Daviey> Oh, also make it use DEBEMAIL for Author: field?
<Daviey> kkthnx
<mhall119> Daviey: say what now?
<Daviey> mhall119: if you edit-patch an existing patch, it'll add stock headers to a patch that already contains valid headers. this sucks.
<mhall119> Daviey: I only fixed what I needed fixed, I haven't contributed enough to get stuch with othership :P
<mhall119> s/stuch/stuck/
<mhall119> s/othership/ownership/
<mhall119> wow, I need more sleep and/or caffiene
<Daviey> mhall119: touched-it-last is ownership, :)
<mhall119> I thought it was a three-strikes policy
<Daviey> mhall119: fair enough. :)
<slangasek> stgraber: as long as you're looking at 946215, could you see if you can figure out bug #946783?  The submitter of 946215 seems to allude to a similar problem in his install
<ubottu> Launchpad bug 946783 in live-build (Ubuntu) "No networking in live-cd " [High,Incomplete] https://launchpad.net/bugs/946783
<cjwatson> hallyn: (1) trying gdb; (2) when I tried Debian's qemu, that was in an actual unstable chroot, so Debian's seabios too, but I'll try with precise's seabios; (3) intel core2duo; (4) 3.2.0-17-generic #27; (5) yes, kvm is enabled
<stgraber> slangasek: ok, I'll have a look. bug 946215 was a casper bug (we were writing /etc/resolv.conf directly instead of using /run/resolvconf/interfaces/casper when resolvconf is around)
<ubottu> Launchpad bug 946215 in casper (Ubuntu Precise) "12.04 not set nameserver in pxe boot ( resolvconf or dhcp client bug)" [Medium,Triaged] https://launchpad.net/bugs/946215
<slangasek> stgraber: yep, saw your comment :)
<cjwatson> hallyn: Debian's qemu + precise's seabios seems to work fine (I'm assuming Debian's qemu is configured to use it, mind you)
<stgraber> slangasek: right, just saw your comment in 946783 and indeed the only case where I see this kind of thing being possible is with NETBOOT being set and in that case you definitely don't want NM messing with it
<slangasek> stgraber: ok.  didn't know if there was another package I should have looked at for code that would do this (I looked in casper and live-build)
<stgraber> slangasek: so if he confirms it's a netboot live session, then it's a duplicate of bug 946215 (assuming his only problem is lack of working DNS)
<ubottu> Launchpad bug 946215 in casper (Ubuntu Precise) "12.04 not set nameserver in pxe boot ( resolvconf or dhcp client bug)" [Medium,Fix released] https://launchpad.net/bugs/946215
<cjwatson> hallyn: similarly, precise's qemu + unstable's seabios still fails - so I don't think this is a seabios bug
<stgraber> slangasek: I quickly went through all of the initramfs code and casper for the resolv.conf one, the only place I saw messing with /etc/network/interfaces is in casper (23networking)
<stgraber> well, there are a few other initramfs hooks doing the same kind of thing (like LTSP) but it shouldn't be relevant to that bug
<slangasek> stgraber: I'm pretty sure he had no networking at all; but I'm waiting for him to respond to my question... he's a local student that was at the global jam yesterday, I'll continue to nag him on IRC
<stgraber> slangasek: ok. /proc/cmdline would likely be helpful to find exactly what path he's taking at boot time
<hallyn> cjwatson: ok, thanks, i'll look through the changelogs
<hallyn> (biab)
<cjwatson> hallyn: gdb: http://paste.ubuntu.com/870479/
<cjwatson> (which aligns with strace, which shows it stuck in a futex)
<cjwatson> ... maybe I should open a bug at this point ...
<dupondje> Where can I report typo's on canonical's website ? ;)
<highvoltage> https://launchpad.net/canonical-web seems appropriate
<cjwatson> bugs.launchpad.net/canonical-website
<cjwatson> oh, yes, what highvoltage said, sorry
<dupondje> that seems more like layout and framework things no? Not really the text itself
<cjwatson> mdz,pitti: TB?
<mdz> cjwatson, y
<Daviey> mdz: wow, you are still alive!
<mdz> I am!
<slangasek> TREllis: gconf 3.2.3-2> let me have a look
<bryceh> heya mdz, long time
<mdz> bryceh, howdy!
<cjwatson> scott-work: do you happen to be around?  if so, TB in #ubuntu-meeting
<scott-work> cjwatson: aye
<SpamapS> ajmitch: it would have been nice to have seen your results reported on the blueprint https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54
<alexbligh> Is there some lazy way for me to spit out all the stuff apport does into a text file, without reporting a bug? (IE does apport invoke one program, or do all the hard work itself)
<broder> alexbligh: are you looking for apport-unpack?
<broder> oh sorry, collect the information? you can do that with ubuntu-bug --save=something.crash
<alexbligh> broder, don't think so. I want to run it on the system with the problem, but not send the system info in via apport / lp
<broder> (apport does all the collection internally)
<alexbligh> $ ubuntu-bug --save=x.crash
<alexbligh> No pending crash reports. Try --help for more information.
<alexbligh> (note there will have been no crashes - I just want all the system information)
<broder> you have to give it a package name. apport collects different information based on which package it's reporting a bug against
<broder> see ubuntu-bug --help
<alexbligh> broder, oh sure, so apport-bug linux --save=blah. But I don't want to report against a package, as I don't want it to ask me questions (it's in an automated script gathering system info), I just want it to do the system info bit.
<broder> alexbligh: i don't know of any way to do that
<alexbligh> broder, thx - I will just have to be less lazy and do it myself...
<cjwatson> hallyn: I filed this as bug 947597
<ubottu> Launchpad bug 947597 in qemu-kvm (Ubuntu) "qemu sometimes hangs on shutdown in GRUB tests" [Undecided,New] https://launchpad.net/bugs/947597
#ubuntu-devel 2012-03-06
 * SpamapS has 5Mbit upstream and doesn't know what to do with it. :-P
<chilicuil> seeding movies? =)
<SpamapS> I don't own the copyrights to any movies, so no, that doesn't sound like a good idea.
<chilicuil> u dont need to own the copyright since u'll not being doing profit of it, at least that's how it's here (mexico), I was just suggesting n.n
<cjwatson> I'm pretty confident that's not how it is where SpamapS lives.
<cjwatson> broder: is lintian.ubuntuwire.org stuck?  http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html shows last updated on Saturday
<ion> There are movies youâre free to seed. :-P
<RAOF> SpamapS: Back up to U1!
<broder> cjwatson: oh yeah, my vm host forgot how to talk to its disks on saturday, and the vm that's running l.uw.o probably didn't come back up. dealing...
 * cjwatson sings the I-hate-threads song
<cjwatson> it goes "la la la I hate threads"
<ion> Sounds more like you hate sucky implementations of threads.
<cjwatson> nope, I hate threads
<cjwatson> unless you mean the "process" implementation
<cjwatson> which hardly counts given the lack of shared data :)
<SpamapS> everybody sings that song, until they deal with twisted, then they start stalking their old crazy lover, threads.. hiding in the bushes.. following threads to work..
<ion> Not sharing mutable data directly is an impotant part of threads sucking, yes.
<ion> err
<ion> s/threads sucking/a non-sucky implementation/
<RAOF> cjwatson: I'm currently singing the I-hate-posix-signals song.  I WIN!
<cjwatson> RAOF: I'm dealing with signals *and* threads
<cjwatson> who wins now?
<RAOF> Ok, you win.
<broder> nobody
<broder> nobody wins
<cjwatson> (I don't even actually want to use threads myself, but somebody wants this library to be thread-safe ...)
<broder> cjwatson: the vm is back up and running an update. new results should be posted within the next couple of hours
<cjwatson> broder: great, thanks
<RAOF> cjwatson: Isn't the basic premise: {threads, signals} - pick one?
<broder> thanks for mentioning it. i've gone ahead and set this vm to autostart, so maybe it won't happen again
<cjwatson> I think that with extreme care it is possible to make them interoperate in this very specific case
<slangasek> I thought it was pick none
<cjwatson> specifically use the self-pipe trick to wake up all threads that are sitting in select any time the signal in question is delivered to any of them, and ensure that any of those threads is capable of handling whatever ensues
<cjwatson> you can get away with it if (as a friend pointed out) you *both* block the signal in question and take out a mutex around any manipulation of process-wide state
<cjwatson> but it's hairy as all hell
<broder> cjwatson: is this for libpipeline/SIGCHILD? does something like signalfd make this better?
<cjwatson> yes, and signalfd doesn't really help much
<broder> oh hmm, yeah, i see
<cjwatson> you could avoid self-pipe that way but you still have to do the extreme-care-for-process-wide-state bits
<cjwatson> I think it would be an optimisation at best
<SpamapS> cjwatson: well behaved libraries and threaded programs don't keep much process wide state though. :)
<cjwatson> SpamapS: Yes, but you have no choice when you have to interact with process-directed signals.
<SpamapS> cjwatson: indeed, signals are to threads as bowling balls are to pristine windless lakes early in the morning.
<slangasek> SpamapS: that's far too poetic :)
<slangasek> TREllis: gconf 3.2.3-3 merged
<SpamapS> sigstop from upstart, you just want to trace my forks, forever wait for my fork      bug 406397
<ubottu> Launchpad bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Medium,Triaged] https://launchpad.net/bugs/406397
<SpamapS> damnit, I meant forever you wait
<SpamapS> sigstop from upstart, you just want to trace my forks, forever you wait      bug 406397
 * SpamapS decides to do haikus only on bugs that are Triaged and > 1 year old from now on
<broder> can we make that a bug filing requirement? i think having all bug titles in the form of haikus would be awesome. or at least interesting
<cjwatson> the changelogs for debconf 0.9.10 and 0.9.11 are such that I've never bothered trying to beat them
<cjwatson> "I updated the / Dutch translation (or rather, / some Dutch guy did -- thanks)."
<SpamapS> those are epic
<pitti> Good morning
<rickspencer3> pitti, more beer this morning!
<pitti> :-D
<rickspencer3> wow, and the smoke tests look good too
<pitti> upgrades are still poor, though
<slangasek> mvo has been making progress on the apt issues there
<pitti> I'll have a look into the other issues RSN (kdebase, the opencv breaks)
<dholbach> good morning
<jalcine> Morning, dholbach
<dholbach> hey jalcine
<TREllis> slangasek: brilliant! Thanks!
<lenios> how would you recommend overriding a setting set in a /usr/share/glib-2.0/schemas/*.gschema.override file? (for example org.gnome.desktop.background)
<lenios> i don't like the idea of modifying the file from gsettings-desktop-schemas package, and writing another override file doesn't work
<dholbach> lenios, you might want to ask in #ubuntu-desktop
<angeloc> james_w: I'm intrested in solving bug 830110, can you help me? I'm relatively new to ubuntu contribution
<ubottu> Launchpad bug 830110 in compiz (Ubuntu) "Horrifically bright "Aero Snap" color (grid plugin?)" [Undecided,Confirmed] https://launchpad.net/bugs/830110
<pitti> mvo: hm, I went through https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu-amd64/apt.log
<pitti> mvo: and I'm still unable to see what it complains about; there seems to be a lot of problems with python:amd64, but I went through all of them, and I don't see a particular reason why it's held back?
<mvo> pitti: let me have a look
 * pitti wishes that he could peek into mvo's brain to see what he's looking for
<zyga> hi
<pitti> mvo: hm, the upgrade succeeded on i386, so perhaps it was just due to i386/amd64 buildd skew and the resulting uninstallability?
<zyga> I've reported a bug on the software center: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/947899
<ubottu> Launchpad bug 947899 in software-center (Ubuntu) "Empty "cancel" button while installing application" [Undecided,New]
<zyga> can someone check if this affects other locale (I've tested this on pl_PL)
<zyga> it could be broken translation or some kind of unrelated bug/race (it's not 100% reproducible for me)
<pitti> mvo: similar with oneiric-main; so let's wait for the next run for now, and assume it was buildd skew
<zyga> mvo: https://launchpadlibrarian.net/95596771/software-center-empty-button-bug.png (if you have the time)
<pitti> mvo: so I think somewhere in http://paste.ubuntu.com/871292/ (small except) the reason for update-manager removal is hidden
<pitti> mvo: am I right that the first "Broken" block was resolved successfully? (until line 19)
<pitti> mvo: so I don't understand the complaint from lines 20 to 22
<mvo> pitti: the catch is "Investigating (3) software-properties-gtk [ amd64 ] < 0.75.10.2 -> 0.82.4 > ( gnome )
<mvo> Broken software-properties-gtk:amd64 Depends on python [ amd64 ] < 2.6.5-0ubuntu1 -> 2.7.2-9ubuntu2 > ( python ) (< 2.7)
<mvo>   Considering python:amd64 1269 as a solution to software-properties-gtk:amd64 10000
<mvo>   Added python:amd64 to the remove list"
<mvo> pitti: I think :)
<pitti> mvo: hm, s-c-gtk does not look any different than other python stuff
<pitti> Depends: python2.7, python (>= 2.7.1-0ubuntu2), python (<< 2.8)
<pitti> looks fairly normal?
<pitti> mvo: there's a ton of similar messages there
<pitti> mvo: wrt. http://paste.ubuntu.com/871292/, I just ran through the log to find why it's refusing to install/update python-gobject, but I don't find anything
<pitti> mvo: let's look at the i386 logs (the one I took the paste from), yesterday's GNOME updates broke amd64 installability temporarily
<pitti> mvo: i. e. https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu/apt.log
<pitti> mvo: but perhaps start with the pastebin, that's only 30-is lines and easier to see?
<mvo> ok, I check the i386 one now
<pitti> (I might have caught the wrong ones, of course)
<pitti> oh, found it
<pitti>   Considering python-gi:i386 114 as a solution to python-gobject:i386 56
<pitti>     Reinst Failed because of libglib2.0-0:i386
<pitti>     Reinst Failed because of libgirepository-1.0-1:i386
<pitti>     Reinst Failed because of python-gi:i386
<hrw> dholbach: thanks for comment on my MOTU application
 * pitti drills down the chain
<dholbach> hrw, anytime :-)
<mvo> pitti: what is the parent of this ? I look at i386,lts,ubuntu,upgrade,test (precise-upgrade-lucid-desktop) and that is a pass for me
<mvo> I mean, it failed becuase of test failures, but the actual upgade was fine
<pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/
<pitti> and then i386
<mvo> aha, thanks!
<mvo> indeed, jenkins confused me
<pitti> Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3)
<pitti>   Considering gnome-control-center:i386 27 as a solution to libglib2.0-0:i386 3189
<pitti>   Upgrading gnome-control-center:i386 due to Breaks field in libglib2.0-0:i386
<pitti> mvo: ^ this is a success, right?
<mvo> yes
<pitti> but further down
<pitti> Investigating (2) libglib2.0-0 [ i386 ] < 2.24.1-0ubuntu1 -> 2.31.20-0ubuntu1 > ( libs )
<pitti> Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3)
<pitti>   Considering gnome-control-center:i386 10000 as a solution to libglib2.0-0:i386 2690
<pitti>   Holding Back libglib2.0-0:i386 rather than change gnome-control-center:i386
<pitti> isn't that the very thing it just looked at, and now decides it's suddenly broken?
<mvo> pitti: "  Removing aptdaemon:i386 rather than change python-aptdaemon:i386" <- this one looks fishy
<pitti> so in that log it holds back a ton of packages due to libglib2.0-0
<pitti> which holds back python-gi, which holds back python-gobject, which probably also cuases the aptdaemon failure?
<pitti> mvo: ^
<mvo> aha, ok
<mvo> yes, make sense, I'm not that far inth elog yet
<pitti> mvo: so I'm currnetly wondering why libglib2.0-0 gets held back
<pitti> mvo: especially with above two snippets (the breaks: on control-center)
<pitti> which first was happy, and the second time not
<mvo> pitti: is this one here: Broken gnome-control-center:i386 Depends on gnome-icon-theme-symbolic [ i386 ] < none -> 3.2.2-1 > ( gnome )
<mvo>   Considering gnome-icon-theme-symbolic:i386 2 as a solution to gnome-control-center:i386 27
<mvo>   Removing gnome-control-center:i386 rather than change gnome-icon-theme-symbolic:i386 <-ok?
<pitti> uh?
<pitti> mvo: I don't see why the two would collide; control-center depends on icon-theme-symbolic
<pitti> gnome-icon-theme-symbolic:i386 Depends on gnome-icon-theme [ i386 ] < 2.28.0-1ubuntu1 -> 3.3.91-0ubuntu1 > ( gnome ) (< 3.3) can't be satisfied!
<pitti> mvo: we updated both to 3.3 today, but yesterday they were both at 3.2
<mvo> pitti: so just a issue that the archive was out-of-sync?
<pitti> mvo: it should have been fine at the time when this ran
<pitti> mvo: well, icon-theme anyway
<pitti> mvo: do you see a reason why it refuses to upgrade libglib2.0-0?
<pitti> mvo: especially the weird breaks: to control-center?
<mvo> pitti: I think what happens is that the removal of gnome-control-center is tried ot be undone because it would mean that ubuntu-desktop gets removed. so it tries to reinstall it, that does not work, so it keeps it, but because of the keep it needs to keep libglib2.0-0 too and that causes a cascade of error - does that sound plausible?
<pitti> why would it remove it instead of upgrade? it's a versioned breaks
<mvo> pitti: but the original problem (that triggers this) is that the icons can not be installed and therefore gnome-control-center can not be upgraded
<pitti> mvo: ah, so that's the second breaks:?
<mvo> pitti: it can't upgrade it because of the icon-theme-symbolic dependency that it can not satisfy
<pitti> mvo: ah, I see
<pitti> mvo: so first it resolves the breaks with an upgarde, then it complains about icon-theme
<mvo> pitti: yes, and appears to be the case (it may even be more complicated, I see a message about libgoa-1.0-0 that I don't know what it is)
<pitti> mvo: ooh, indeed that test only started 3 hours ago
<pitti> mvo: ok, thanks
<pitti> mvo: so let's try this again
<mvo> pitti: shall I re-run the test with the current archive just to ensure that its not archive-churn?
<pitti> mvo: ah, can you?
<pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/ -> this one
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is currently "Beer"
<pitti> so it ought to work
<pitti> it did have a lot of stuff this morning indeed
<mvo> haha
<seb128> pitti, beer at this time?
<mvo> maybe we should actually make the tester look at that file before it runs?
<seb128> pitti, that might explain why we see some breakages in the afternoons :p
<pitti> seb128: our goal is to have beer at all times
<mvo> for me it said tea
<pitti> mvo: it certainly doesn't make much sense to try and run if ubuntu-desktop is uninstallable
<pitti> which is often the case when seb128 upgrades gnome
<pitti> he grabs the beer, and swoosh, the archive becomes a mess
 * pitti hugs seb128
<mvo> s/often/everytime/ ;)
<seb128> lol
 * seb128 hugs pitti mvo
 * mvo hugs seb128
<pitti> mvo: I was going to ask jibel to restart it, but if you could?
<mvo> ok,lets talk after lunch
<mvo> I trigger a manual run now and let you know
<pitti> mvo: that test hasn't succeeded in 12 days, so I'm eager to get a run on a known-good archive (which is now0
<pitti> mvo: cool, thanks
<pitti> mvo: will that appear in jenkins?
<mvo> I don't know, jibel will know :) he is the master of the jenkins
<jibel> pitti, I was about to restart the test now that icon-theme-symbolic is in the archive. i386 succeeded yesterday
<pitti> jibel: ah, merci
<pitti> mvo: ok, after lunch we need to talk about another weirdness
<pitti> but lunch -> good idea, bbl
<pitti> jibel: so I guess mvo already started it now
<jibel> pitti, right, i386 is running and upgrading. I'll re-run from jenkins when it's finished to publish the resutls
<sladen> pitti: scour.  Currently it only Suggests: python-rsvg, python-cairo.  However both of these are needed dependencies for 'cmpsvg' otherwise it shrug and gives up
<sladen> pitti: this means that during build scour is run by the exercise is pointless(?)
<sladen> pitti: what's your preferred.  Move those to Recommends:/Depends: ?
<sladen> pitti: or pull in those two as dependenices in indivudal packages?
<sladen> pitti: hold on, you've answed this at  https://bugs.launchpad.net/ubuntu/+source/ubuntu-mono/+bug/927606
<ubottu> Launchpad bug 927606 in ubuntu-mono (Ubuntu) "add python-rsvg build dependency for verifying scour results" [Medium,Fix released]
<jibel> pitti, mvo i386 passed, re-running with jenkins now
<pitti> slangasek: we can't add them as recommends, it creates recursive build depends loops
<pitti> sorry, sladen ^
<pitti> sladen: packages which have a lot of svgs, such as icon themes, need to b-dep on those themselves
<pitti> jibel: ah, taht seems to be https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/53/ ?
<pitti> jibel: or was that mvo's manual job?
<pitti> jibel: anyway, amd64 passed, and i386 test failure, nice
<pitti> jibel: is the x server test a race condition in the tests?
<pitti> I see this quite often
<pitti> jibel: I'm filing a bug for the libreoffice-common failure in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=i386,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-i386/apt-term.log
<jibel> pitti, that's bug 916291 Sweetshark fixed yesterday
<ubottu> Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Fix released] https://launchpad.net/bugs/916291
<pitti> jibel: oh, that's why I didn't see it
<pitti> jibel: thanks, duplicating
<pitti> jibel: ok, so looking forward to the next run :)
<pitti> jibel: so I'll trawl through the lucid-universe apt log now; it seems the failures of all other tests are already fixed or in progress
<pitti> roaksoax: any progress on bug 840406?
<ubottu> Launchpad bug 840406 in powernap (Ubuntu Precise) "powerwaked crashed with ImportError in /usr/lib/python2.7/dist-packages/powerwake/monitors/ARPMonitor.py: No module named scapy.all" [High,Triaged] https://launchpad.net/bugs/840406
<pitti> roaksoax: python-scapy is in universe, so at this point the new dependency should probably be dropped?
<pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-main/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all/apt-term.log
<pitti> mvo: to my untrained eye this looks like another instance of bug 927993, do you agree?
<ubottu> Launchpad bug 927993 in apt (Ubuntu Precise) "ordering code may mark a package for configure before its unpacked" [Critical,Triaged] https://launchpad.net/bugs/927993
<pitti> mvo: or perhaps not? it tries to configure kde-runtime before libsmbclient gets unpacked and configured
<bigon> is there a way to tell upstart that we want to track a pid file?
<mvo> pitti: indeed, this looks like another order failure, let me try to reproduce first
<pitti> mvo: oh, so it's not the same bug?
<mvo> pitti: I doubt it but lets see
<pitti> mvo: I picked up some of your training and now walk through the apt.log of precise-upgrade-lucid-universe :)
<pitti> man, the day that this thing goes green I'm so much having a beer
<jalcine> lol
 * mvo runs with order code debug enabled to see what he can find out
<mvo> pitti: haha
<jibel> pitti, this was bug 940396 and it was duplicated to 927993
<ubottu> Launchpad bug 927993 in apt (Ubuntu Precise) "duplicate for #940396 ordering code may mark a package for configure before its unpacked" [Critical,Triaged] https://launchpad.net/bugs/927993
<pitti> jibel: ah, thanks
<pitti> mvo: ^ so maybe undupe it, if appropriate?
<mvo> pitti: yes, the first bug is about --configure being call on a package that never saw --unpack, the second one is about a package that is configured before all of its dependencies are configured
<pitti> mvo: for the second one, I just discovered bug 892630 and commented on it
<ubottu> Launchpad bug 892630 in apt (Ubuntu) "package gir1.2-glib-2.0 1.30.0-0ubuntu2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/892630
<pitti> with an extraction of the log
<pitti> mvo: that seems to be an instance of the second one (forgot to configure library before configuring rdep)
<mvo> pitti: yes
 * pitti retitles it to something easier
<pitti> mvo: so we should undupe bug 940396 and I make 892630 a dupe of it (or the other way round)?
<ubottu> Launchpad bug 940396 in apt (Ubuntu) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396
<mvo> pitti: but that is not reproducable via some upgrade test run, right? that was a user reported problem?
<pitti> mvo: yes, 892630 was a user report
<pitti> mvo: 940396 is from jenkins
<mvo> pitti: sounds good to me, maybe 940396 as its actually possible to reproduce this error
<pitti> mvo: ack
<mvo> 940396 as the master I mean
<mvo> ta
<pitti> done
<pitti> ok, I think all current upgrade failures are covered with bug reports then
<pitti> and I think it's mostly these two apt bugs now
<jrgifford> I'm attempting to submit a fix for this bug, and following the instructions jbicha gave me have proved... less than fruitful. https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/771375
<ubottu> Launchpad bug 771375 in gnome-games (Ubuntu) "No Unity QuickList for gnomine" [Undecided,Confirmed]
<mvo> pitti: meh, the main-all takes forever to run :/
<pitti> mvo: :/ 8.5 hours on jenkins :/
<mvo> "fun"
<mvo> pitti: it looks ike its a dependency loop problem, but it still should not fail like this
<jibel> pitti, I ran oneiric universe again and libreoffice 1:3.5.0-2ubuntu1 is still failing to upgrade. same error
<lynxman> packaging question, I'm trying to copy the config files I have working in the debian/conf/* directory on a package that doesn't have an install file, the rules file looks like this http://pastebin.ubuntu.com/871481/
<lynxman> line 22 is the one I added, I know cp is not the right one, I tried install -p -d -D -m 0755 but didn't work, for config files what would be the recommended best way?
<seb128> pitti, apw: help on bug #947748
<ubottu> Launchpad bug 947748 in gnome-settings-daemon (Ubuntu) "Brightness control not working after latest update" [Undecided,Confirmed] https://launchpad.net/bugs/947748
<seb128> do you know guys know how to debug that?
<seb128> is there a known kernel issue?
<james_w> angeloc, I'm not sure I know what to do with that bug. Was there a particular reason you asked me?
<apw> seb128, there might have been something to do with macs in the -18 kernel
<seb128> apw, right, those are macs users
<apw> massocists all
<apw> seb128, am discussing on #ubuntu-kernel
<seb128> apw, thanks, I'm going to lurk there ;-)
<Laney> I noticed that my macbook no longer sleeps if I just shut the lid on the newest kernel
<Laney> guess that is part of this.
 * Laney goes to lurk there too
<cjwatson> dpm: could you see if a Chinese translator could review stgraber's suggestion for https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/892386/comments/5 ?
<ubottu> Launchpad bug 892386 in ubiquity (Ubuntu) "No shortcut available for "forward" button for Chinese during installation / oem-config" [High,Triaged]
<angeloc> james_w: because you are the one who created the source package, sorry if it was a problem
<dpm> cjwatson, pinged translators and I'll follow it up
<dpm> thanks for the heads up
<cjwatson> ta
<dpm> cjwatson, stgraber, the Chinese translators didn't seem to happy about adding a shortcut on the translation where there isn't one in the original string. I've asked them to comment on the bug
<pitti> mvo: what is a dependency loop problem?
<pitti> jibel: ah, so we should reopen this?
<cjwatson> I kind of wonder why we don't have a shortcut on that msgstr to match GTK, in some ways
<cjwatson> maybe it's also used in the KDE frontend though?
<jibel> pitti, I reopened it.
<jibel> Sweetshark, ^ bug 916291
<ubottu> Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Triaged] https://launchpad.net/bugs/916291
<stgraber> dpm: I can definitely understand that, though the reason for the bug is that they added it for all the other ones in gtk ...
<stgraber> dpm: so they should either add the shortcut for that one too or remove all of these they added for all the gtk stock buttons
<stgraber> dpm: otherwise you get an inconsistent installer UI
<dpm> stgraber, I'm not sure I quite follow why the shortcut appears in one button and not in the other. Is it because the Back one is stock and thus has a shortcut, and the Continue one is not stock and doesn't have one?
<dpm> if so, would it not be better to add a shortcut in the Continue button in the source code?
<cjwatson> stgraber: well, no, the "Continue" string is in ubiquity proper but the others are imported from GTK
<mvo> pitti: the one in the bugreport? well, that its not resolved correctly :) I think the loop in itself is ok and is resolvable afaict
<pitti> mvo: I mean, if we could break a loop somewhere, that might help, but I didn't see a loop dependency on either glib or libsmbclient
<mvo> pitti: its kde-runtime, glib is fine
<cjwatson> dpm,stgraber: yeah, on inspection, this string is shared with KDE which I'm fairly sure has different shortcut conventions
<mvo> pitti: and libkrb5
<cjwatson> so I don't think it can be as simple as adding _, even in the translation
<mvo> pitti: well, I'm not sure, we could workaround it, but  I prefer to see it  be fixed in libapt
 * cjwatson tries to remember why the stock labels weren't good enough
<cjwatson> It would read "Forward" rather than "Continue"
<roaksoax> pitti: Hi! yes I'm going to take care of that bug this week. Thanks for the reminder!
<cjwatson> but it does seem illogical to use stock labels for one thing and not another, in the same button bar
<pitti> roaksoax: thank you!
<cjwatson> maybe check with mpt?
<cjwatson> our back/forward button handling doesn't look desperately consistent in general
<sconklin> @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: sconklin
<sveinse> In ext[4] rootfs, when is the "Last mount time" updated? Will it be updated on umount e.g. shutdown, or just mount/startup?
<mpt> dpm, I don't know why the stock string was never changed. Probably because it was inappropriately shared with (for example) the navigation buttons in browsers, where you do want just "Back" and "Forward"
<dpm> mpt, what do you think the best way to solve that bug and be consistent should be? Both stock buttons with shortcut, or both non-stock buttons?
<mpt> dpm, I think the best way would be to make the keyboard combo for going to the next step Enter, and the keyboard combo for going to the previous step Esc.
<Sweetshark> jibel: k, thx
<dpm> mpt, cjwatson, that's probably a solution for +1, though, right? ^ Is there anything that can be done at this point in the cycle, or should the bug be wontfix for oneiric and precise?
<Sweetshark> pitti: any idea what in http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=libreoffice-common.postinst.in;h=f2995c1058c96f1ed123ac0d1211a7a75ac8f395;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c could trigger bug 916291? I dont even see anything UNOy being touched there ....
<ubottu> Launchpad bug 916291 in libreoffice (Ubuntu Precise) "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [High,Triaged] https://launchpad.net/bugs/916291
<pitti> Sweetshark: what does #INCLUDE_SHELL_LIB# expand to?
<Sweetshark> http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=shell-lib-extensions.sh;h=21dafe32323e261d0943bcb99cb2429b9aab0602;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c
<pitti> Sweetshark: btw, that postinst.in is wrong -- dpkg-maintscript-helper MUST NOT be placed within a $1 check
<cjwatson> mpt: I thought that was in general the case anyway, but it's not very discoverable so people missed it
<pitti> Sweetshark: well, in postinst you might get away with it, but it's still wrong conceptually
<pitti> Sweetshark: as dpkg-maintscript-helper also does stuff on other values of $1
<pitti> Sweetshark: so, presumably it's the dpkg-trigger /@OODIR@/share/extensions
<pitti> Sweetshark: which causes an unopkg call
<pitti> Sweetshark: there might not be a locale set at this point?
<pitti> or one that it doesn't like?
<Sweetshark> as for dpkg-maintscript-helper, that was cjwatson IIRC.
<Sweetshark> cjwatson, pitti: ubuntu veteran fight!
<cjwatson> uh, no, but on the phone
<mpt> cjwatson, if something isn't discoverable, I try to make it more discoverable before adding a second thing :-)
<cjwatson> will get back to you in a bit
<pitti> Sweetshark: for dpkg-maintscript-helper it's easiest to use debian/package.maintscript (see man dh_installdeb), that'll remove any remaining doubt; )
<pitti> Sweetshark: but anyway, it's not the cause for this bug, it just caught my eye
<cjwatson> I thought that's what I suggested for LO
<cjwatson> oh, no
<cjwatson> it was a bit awkward I think
<cjwatson> I think there were ordering concerns
<Sweetshark> hmm, so its that the share/extensions trigger (which I moved to -core) firing. However in the log provided from the jenkins-qa there does not seem to be any libreoffice-core action happening at all, so how can a trigger by it do any harm (shouldnt be there yet).
<pitti> cjwatson: I suppose .maintscript expands into #DEBHELPER#?
<cjwatson> pitti: yes
<pitti> so that could just be moved earlier if necessary
<cjwatson> pitti: .maintscript definitely isn't mandatory though - I converted dozens of packages, most of them could be handled with .maintscript, but a handful couldn't and I do think that's OK
<pitti> cjwatson: oh, absolutely, I was just pointing out that it makes things easier
<cjwatson> and I think it's better to not use .maintscript if the alternative is moving code around in ways that we aren't entirely certain of
<pitti> cjwatson: the thing that is wrong is putting dpkg-maintscript-helper into an if [ $1 = ... ]
<pitti> it might be harmless in a postinst (as at that point you can't roll back any more)
<pitti> but it is actively breaking stuff in preinst and prerm
<cjwatson> sure
<cjwatson> contrary to what Sweetshark says though, I didn't put it there
<cjwatson> the most you can pin on me is that I failed to move it out of there :)
<cjwatson> my change was to remove 'dpkg-maintscript-helper supports' guards and the like, which do more harm than good
<pitti> *nod*
<pitti> Sweetshark: so, we violently agree :)
<pitti> no fight, sorry
<ogra_> bah
 * ogra_ puts away the popcorn
<L3top> can anyone explain to me how "Select best server" works? Or better yet, just point me to the code.
 * Sweetshark grabs ogra_ s popcorn and runs.
<AnAnt> how can I test upgrade from lucid to precise ?
<ogra_> haha
<mvo> can someone with a nvidia (either free or proprietary) run  "python /usr/share/pyshared/debtagshw/opengl.py " and tell me the renderer string please? same for the fglrx driver please :) ?
<mvo> (on precise I should add)
<L3top> was just gonna say...
<broder> who's the language-selector expert? there are 2 mp's that have been sitting around for a while that i don't know how to evaluate (https://code.launchpad.net/~debfx/ubuntu/precise/language-selector/kubuntu/+merge/92967 and https://code.launchpad.net/~jincreator/ubuntu/precise/language-selector/korean/+merge/93535)
<james_w> angeloc, ah, that's an artefact of the way Launchpad reports these things, I don't actually know anything about that package
<james_w> angeloc, smspillaz might be a good person to talk to as he commented on the bug
<Sweetshark> pitti: what is the canonical way to find out if another package is installed in a postinst script?
<pitti> Sweetshark: not sure whether there is THE  canonical way, but I believe "dpkg -s coreutils | grep ^Status" should give you the status
<pitti> Sweetshark: that'll tell you if it's uninstalled, unpacked, or configured
<Sweetshark> jibel: can you tell me if libreoffice-core was installed before this update was run, and if so at which version?
<jibel> Sweetshark, from dpkg.log 1:3.4.4-0ubuntu1 was installed
<jibel> Sweetshark, correction that's libreoffice-common
<jibel> libreoffice-base-core was installed
<jibel> 1:3.4.4-0ubuntu1
<Sweetshark> jibel: but no libreoffice-core?
<cjwatson> pitti: please don't use dpkg -s in a postinst
<pitti> cjwatson: dpkg-query ok?
<cjwatson> if you must, use dpkg-query instead, but I'm not certain it's reliable in a maintainer script
<jibel> Sweetshark, and libreoffice-core 1:3.4.4-0ubuntu1
<cjwatson> I *think* these days it might be; it used to be that dpkg wasn't re-entrant, in that the status file on disk wasn't necessarily up to date
<cjwatson> but generally if you have to do that it's the sign of a design error anyway
<pitti> Sweetshark: does the "cannot determine language" error message correspond to any code in unopkg itself? it might check the locale which might be invalid during the dist-upgrade
<jibel> Sweetshark, list of libreoffice-* packages installed before upgrade: http://paste.ubuntu.com/871618/
<Sweetshark> pitti: unopkg uses a _lot_ of libreoffice infra. calling it halfway through the install is icky.
<Sweetshark> jibel: thanks.
<pitti> Sweetshark: so perhaps the trigger should be made robust against failures, and the postinst configure then does another call (at a point when all dependencies are configured and unopkg has a better chance of working)
<pitti> Sweetshark: in general, triggers can be (and often are) called when packages are unpacked but not configured
<Sweetshark> pitti: But I still wonder which trigger is actually called there: -common 3.4.4-0ubuntu1 should be gone, -common 3.5.0-2ubuntu1 has no does not provide a tigger action, it just fires it, -core 3.4.4-0ubuntu1 has no trigger action, -core 3.5.0-2ubuntu1 is not installed yet. so where does the trigger action come from?
<Sweetshark> pitti: so "the trigger should be made robust" *confused* which one?
<mhall119> mvo: ping
<mhall119> mvo: did you have a change to look over the edit-patch MP from yesterday?
<mvo> mhall119: not yet, I will try to do it next
<Sweetshark> pitti: so what I would consider to do: in both -common and -core postinsts, check if we have both a  3.5.X -core and 3.5.0 -common and then and only then trigger the trigger.
<ritz> Is it possible to locally build a package for oneiric from bzr branch on precise, using buildeb plugin ?
<mhall119> mvo: thanks, I'm working on a blog to get people using it for their quicklist and keyworkds submissions
<Sweetshark> jibel: is there a way to recreate that update scenario easily locally (in a VirtualBox or whatever)?
<jibel> Sweetshark, you can restore the clone in a VM and reproduce from there
<jibel> Sweetshark, http://10.189.74.2:8080/view/Precise%20Upgrades/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz
<jibel> Sweetshark, hm, try https://jenkins.qa.ubuntu.com/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz instead
 * Sweetshark just recognized again how awesome mutt is.
<Sweetshark> when you edit a mail (what I just did in my todo-folder), it marks the old mails as deleted an creates a new one, thus not confusing other clients.
<shadeslayer> mterry: ping
<mterry> shadeslayer, yo
<shadeslayer> mterry: hey hey!
<shadeslayer> mterry: https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/586324
<ubottu> Launchpad bug 586324 in openal-soft (Ubuntu) "[MIR] openal-soft" [Undecided,Incomplete]
<shadeslayer> mterry: I'm almost done generating the symbols file and uploading a package to my PPA, could you upload it to the archives?
<shadeslayer> ( I don't have upload rights just yet, working on fixing that ;) )
<shadeslayer> mterry: packages should appear here : https://launchpad.net/~rohangarg/+archive/experimental
<mterry> shadeslayer, ok.  will check back after lunch if they are done building
<shadeslayer> mterry: thanks!
<mterry> shadeslayer, thanks for patching!  :)
<shadeslayer> :)
<shadeslayer> derp
<shadeslayer> that PPA is full
<apw> can anyone tell me what gvfsd-trash's role in the world is?
<mali> apw, I would assume it tries to provide underlying services to the file manager say , especially with regards to auto mounted volumes. but thats just a guess
<slangasek> bdmurray: you said on 941172 that you pushed a new branch, I don't see changes in lp:update-manager and I don't see a branch listed at https://code.launchpad.net/update-manager/ ?
<bdmurray> slangasek: thanks, really pushing now
<apw> cjwatson, is it VT7 that has the kernel console output when installing from the liveCD ?
<cjwatson> apw: not sure I recall offhand, since the live CD doesn't do the transparent VT thing
<apw> cjwatson, thanks, i'll let them search for it :)
<pitti> Sweetshark: wouldn't it be easier to add an || true to avoid package installation failure if the trigger fails?
<pitti> Sweetshark: and then re-run unopkg in "configure" (i. e. not triggered)
<dobey> how does one find a diff of what changed exactly between different debian policy versions? ie, 3.9.2->3.9.3?
<micahg> dobey: there's an upgade checklist file in the debian-policy package
<SpamapS> can packages in main use -Zxz ?
<micahg> SpamapS: as long as you have a Pre-Depends on dpkg >= 1.15.6
<micahg> *binary Pre-Depends
<micahg> component doesn't matter in this case
<SpamapS> micahg: I had thought there was some problem with xz and d-i
<micahg> AIUI, it won't improve space on the images, I though that the issues with d-i were fixed, but I guess cjwatson could speak to that point
<SpamapS> Please do not use this for packages that are Priority: required or
<SpamapS> Priority: important, as you will break the installer if you do (and
<SpamapS> http://ubuntu.5.n6.nabble.com/data-tar-xz-support-added-to-Launchpad-td718118.html
<micahg> ah, then I guess that the answer is no :)
<SpamapS> whois is standard.. so.. should be ok
 * micahg thanks SpamapS for the reminder about that
<shadeslayer> mterry: so, openal-soft is going to be in main now?
<mterry> shadeslayer, once and if archive-admins approve and push it in
<shadeslayer> ah ok
<broder> micahg: i think -Zxz will improve the server/alternate cds
<micahg> right, it's the squashfs it won't help
<SpamapS> that reminds me.. I need to un-static-link mysql-client and mysql-server soon
<cjwatson> SpamapS: yeah, if you convert something debootstrap has to install to xz, I'll have to revert it, but otherwise it's fine
<SpamapS> cjwatson: just to confirm, Priority: standard is ok, yes?
<cjwatson> SpamapS: in general, yes.  whois is ok.
<cjwatson> build-essential would be bad due to --variant=buildd.
<cjwatson> actually no, that's fine, debootstrap can do it in general it's just when it's run in the context of d-i
<cjwatson> brain atrophying, apparently
<bdrung> iulian, Laney: is there a reason why i should not sync haskell-csv?
 * micahg would guess the fact that the whole stack needs to be rebuilt would be a reason to wait
<iulian> bdrung: We are gonna get all the Haskell packages sync'ed and thus I think there's no point in syncing it now. We also have to fix the armhf build failure (GHC currently fails to build on that architecture).
<bdrung> iulian: k, then i will wait for it
<jdstrand> mdz: fyi, since you asked about it before, I filed bug #948481
<ubottu> Launchpad bug 948481 in telepathy-mission-control-5 (Ubuntu) "adjust Build-Depends to include dh-apparmor" [Low,Triaged] https://launchpad.net/bugs/948481
<jdstrand> mdz: sorry
<jdstrand> mdeslaur: ^
<jdstrand> mdeslaur: that is a master bug with a bunch of tasks for the packages that use dh_apparmor
<jdstrand> (that I didn't fix earlier today)
<mdeslaur> jdstrand: cool
<infinity> SpamapS: You missed the dpkg pre-dep on your whois upload.
<dupondje> superm1: there perhaps ?
<infinity> SpamapS: See the LP binary upload failure logs.
<superm1> dupondje: yeah, what's up
<infinity> iulian: Ugh, GHC regressed on armhf?
<dupondje> superm1: I dunno if you can forward bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/901410 somewhere internal @ Dell ? :)
<ubottu> Launchpad bug 901410 in linux (Ubuntu) "[Dell XPS L502X] Applying soft block to bluetooth hard blocks wlan" [Medium,Triaged]
<superm1> dupondje: ah interesting.  that's one of the new XPS 13's right?
<slangasek> infinity: ghc - build regression?
<dupondje> well i'm having a XPS 15, seems like somebody else with a XPS 13 has same issue now
<seb128> slangasek, hey
<slangasek> seb128: hi there :)
<infinity> slangasek: Yeah.  Happened last week, I guess, I didn't notice until going through logs today. :P
<seb128> slangasek, can you look at bug #948294? I didn't look at it yet but we just got 3 dups and since you did the update..; ;-)
<ubottu> Launchpad bug 948294 in gconf (Ubuntu) "package gconf2 3.2.3-3ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 250" [Undecided,Confirmed] https://launchpad.net/bugs/948294
<slangasek> seb128: yeah, looking
<seb128> slangasek, thanks
<superm1> dupondje: ah ok.  well we don't do certification for ubuntu on XPS, but i'll see what we can do about it
<dupondje> superm1: I know :) but if it can fixed it would be cool.
<dupondje> superm1: its just annoying that I can't disable bluetooth properly now. This eats power ofc :D
<slangasek> seb128: hmm, right - so the old gconf2 package is still installed and its trigger is being called, but the underlying libs are apparently in an inconsistent state :(
<seb128> slangasek, lack of breaks?
<slangasek> maybe
<slangasek> not sure if it's better to do that, or to make libgconf-2-4 have a circular dependency with gconf-service
<superm1> dupondje: as a temporary workaround you might be able to just disable bluetooth in the firmware if you don't use it much to help with the power eatings
<seb128> slangasek, can you get https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3264443 https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3264444 to build?
<seb128> slangasek, i.e scored up
<slangasek> seb128: not a buildd admin
<seb128> slangasek, since you are around ;-)
<slangasek> infinity can though
<seb128> oh, I though you were
<seb128> infinity, ^
<dupondje> superm1: true. Anyway it would be cool if it could be fixed :)
<infinity> seb128: Done.
<seb128> infinity, thanks
<seb128> infinity, both? the amd64 score didn't change
<infinity> seb128: Picky, picky.
<seb128> infinity, ;-)
<seb128> infinity, now it did!
<seb128> thanks ;-)
<iulian> infinity: Yea, it was really a surprise to be honest. It seems that janimo` has a fix though. I'm gonna take a look at it as soon as possible if Laney doesn't beat me to it.
<infinity> iulian: Oh, shiny.  If Jani's on it, I'll happily ignore it.
<mhall119> seb128: is there an easy way to say "Take the last n revisions of this bzr branch, and turn them into a patch instead"?
<seb128> mhall119, bzr diff -c <rev> > patch ?
<slangasek> bdmurray, infinity: looking at the InstallCmdLine in bug #947738, can either of you tell offhand if this is a CD or USB?
<ubottu> Launchpad bug 947738 in ubiquity (Ubuntu) "precise failed to install: unable to initialize policy plugin" [High,Confirmed] https://launchpad.net/bugs/947738
<slangasek> mhall119: bzr diff -r -$((n+1)) > patch
<mhall119> seb128: I meant a package patch
<seb128> no
<slangasek> bzr diff -r -$((n+1)) > debian/patches/patch? :)
<mhall119> will a bzr diff work for a quilt patch?
<slangasek> yes, it's the same format
<mhall119> oh nice, so much easier
<slangasek> oh, you should probably do:
<slangasek> bzr diff -p1 -r -$((n+1))
<slangasek> since quilt really wants -p1 instead of bzr's default of -p0
<slangasek> (an unfortunate bzr default, that)
<mhall119> so, bzr uncommit; bzr diff -p 1 > debian/patches/patch; bzr add debian/patches/patch; bzr revert; dch -i; bzr commit?
<mhall119> like that?
<slangasek> you also need to add the patch to debian/patches/series
<seb128> mhall119, why uncommit?
<mhall119> seb128: to get the patch's changes out of the source
<slangasek> so echo patch >> debian/patches/series
 * mhall119 is writing for people who have already committed their changes to a bzr branch
<slangasek> who's the audience?
<mhall119> slangasek: people who have been following my previous blogs about adding quicklists and keywords
<slangasek> if this is for new contributors to Ubuntu, I'd rather they just push a merge proposal with whatever changes they've already made...
<mhall119> slangasek: you'd be in the minority on that preference I think
<slangasek> among Ubuntu developers who'll be merging?
<mhall119> well, among people who have been asking me to get them to use edit-patch and submit changes that way
<seb128> slangasek, the complain I think that those are inline changes without changelog entry
<seb128> slangasek, mostly against the wrong vcs for desktop stuff
<seb128> though agree it might be easier to just deal with those by fixing them ourself
<seb128> but we shouldn't recommend stuff to keep done this way
<slangasek> oh, well, I've never used edit-patch, and it doesn't look like an obvious fit for the UDD workflow at all
<ScottK> Some of us still prefer the ways that have nothing to do with UDD.
<james_w> mhall119, bzr dep3-patch -r -n..
<seb128> slangasek, it's just a wrapper about dpatch-edit-patch and the cdbs quilt equivalents
<slangasek> dep3-patch> hunh
<slangasek> seb128: yeah... none of those are part of my workflow :)
<james_w> I think it might be spelt bzr patch --format something in precise
<james_w> jelmer will know of course
<mhall119> james_w: bzr: ERROR: command 'dep3-patch' requires argument LOCATION
<james_w> oh, you expected my suggestion to work?! :-)
<mhall119> james_w: also, bzr patch is for applying patches, according to it's help
<james_w> diff I mean, don't I
 * jelmer waves
<jelmer> there was some talk about integrating 'bzr dep3-patch' back into 'bzr diff --format=dep3', indeed. But it hasn't happened yet.
<james_w> ah, ok
<james_w> mhall119, try "bzr dep3-patch -r-n..-1 . > debian/patches/whatever"
 * mhall119 wants a "bzr patchdeb" that finds the last revision that matches the parent branch, pops them off into a patch, add's their comments to the changelog, and commits the result
<mhall119> all I want is everything, is that so much to ask?
<jelmer> mhall119: that is mostly what 'bzr dep3-patch' does
<jelmer> mhall119: basically, if you run it inside of the package branch and specify the location of the branch with the patch it will do that.
<mhall119> jelmer: does dep3-patch only work on uncommited changes?
<jelmer> mhall119: no, it only works on committed changes
<slangasek> well, if you diff against the current branch and use -r, it should work with both, no?
<slangasek> but if they're committed, it's going to be awkward to get them into quilt in a way that makes everything happy
<bdmurray> slangasek: I cannot tell
<slangasek> you almost might as well use dpkg-source --commit at that point
<slangasek> bdmurray: ok, thanks for looking
<jelmer> the most interesting thing about dep3-patch is that it tries to generate the DEP-3 header
<bdmurray> slangasek: however changelog for usbcreator mentions 'Always write cdrom-detect/try-usb=true' so sounds like a usb stick
<slangasek> right
<slangasek> that was my best guess
<slangasek> and the dupe bug does *not* have this, so looks like a CD
<mhall119> alright, I'm not getting how to use dep3-patch
<jelmer> mhall119: what are you trying to do exactly?
<mhall119> say I have lp:~tcfox54-gmail/ubuntu/precise/gimp/add_quicklist
<mhall119> it has 1 revision on top of ubuntu:gimp, rev 51
<mhall119> I want to turn rev 51 into a patch
<stgraber> mhall119: let me try something quickly
<stgraber> once I finished downloading that gimp branch ... isn't exactly light apparently ;)
<jelmer> mhall119: here is an example of what I'm using: http://pastebin.ubuntu.com/872184/
 * jelmer tries for gimp
<mhall119> and just to make things more fun, say this branch has already been pushed to LP and an MP created for it
<mhall119> jelmer: so -d is for the unmodified branch, and LOCATION is the modified?
<jelmer> mhall119: (yes, though -d defaults to ".")
<mhall119> ah, perfect, I had that all backwards it seems
<mhall119> so the output of that goes into debian/patches/add_quicklist, echo "add_quicklist" > debian/patches/series, then should I have them remove their changes from the source, or just dch -i and push with both the changed source *and* the patch?
<mhall119> is this even worth having people do for existing MPs and branches, or should I just make a tutorial for new contributions?
<stgraber> mhall119: alternatively: bzr uncommit && dpkg-source --commit
<stgraber> mhall119: assuming you have the .orig.tar.gz in the parent directory
<mhall119> stgraber: I'll assume they won't
<stgraber> this will prompt you for a patch name, generate debian/series and open vim in your patch so you can set the headers
<mhall119> since I instructed them to get things from bzr
<stgraber> mhall119: then they can just run bzr bd -S which will generate it from the branch for them
<mhall119> again though, is it worth if for the few existing, non-merged branches?
<infinity> I'd like to pretend that people changing packages will have the .orig (and, indeed, the previous source version) in their parent.
<stgraber> mhall119: actually: bzr bd -e && bzr uncommit && dpkg-source --commit
<infinity> Because I sure do love when people obviously didn't debdiff a.dsc b.dsc to see how many undocumented changes they accidentally introduced (or what they dropped)
<stgraber> mhall119: that will generate the orig.tar.gz, will uncommit and commit the diff to a patch
<mhall119> dpkg-source will do a bzr commit? or just create the patchfile?
<infinity> The latter.
<mhall119> will it update the changelog?
<stgraber> mhall119: it'll take any delta in the source directory and make that a patchfile, creating debian/patches/series if necessary
<stgraber> mhall119: it also adds the default patch headers that you just then need to fill
<infinity> It won't touch the changelog, no.
<stgraber> mhall119: no, it doesn't touch the changelog and won't include changelog changes in the patch because they're fine where they are
<stgraber> mhall119: so if yu run: bzr bd -e && bzr uncommit && dpkg-source --commit && bzr add && bzr commit -m "Clean commit this time"
<stgraber> you'll have a new commit called "Clean commit this time" replacing your old commit and with the changes in debian/patches instead of inline
<slangasek> mhall119: however, there's a 'dep3changelog' helper in devscripts which will take the dep3 patch header and attempt to create a changelog
<mhall119> so many options...
<slangasek> yes :/
<mhall119> ok, gotta run, but thanks everyone, I'll try all of these out and see which one I'm most comfortable writing about
<SpamapS> infinity: ACK, fixing
<SpamapS> infinity: and thanks.. I was a bit confused by the fail to upload :-P
<infinity> SpamapS: There's an upload log that points out why. ;)
<SpamapS> Yeah I didn't see that before I ran off to the dentist :p
#ubuntu-devel 2012-03-07
<SpamapS> jdstrand: for the dh_apparmor bugs .. to make packages easier to no-change backport, can one | debhelper (<< 9.20120115ubuntu3) ?
<infinity> SpamapS: Don't see why not.
<ScottK> Just don't try it in Debian.
<SpamapS> ScottK: in Debian I'm thinking the packaging needs some revisiting so we can get in sync w/ Ubuntu.
<SpamapS> Hrm.. gcc-4.5 wasn't in lucid .. I wonder if I should just punt the no-change idea.
<ScottK> OK.  I don't know your specifics, but alternate build-depends aren't supported on Debian.
<jdstrand> SpamapS: I don't see any problems with that. makes syncing with Debian harder as mentioned
<SpamapS> jdstrand: yeah I just found 3 other things that make it hard to build w/o changes on lucid.. not really worried about any of the others so I'm dropping the idea. ;)
<jdstrand> heh
<Laney> iulian: I don't know. I've tried a few patches but it's just fail after fail, and the builds take about 10 hours.
<bdmurray> slangasek: what do you think about bug 226780? should it be won't fix or fixed?
<ubottu> Launchpad bug 226780 in apt (Ubuntu) "apt-key net-update does not obey APT::Acquire::http::Proxy" [Undecided,Confirmed] https://launchpad.net/bugs/226780
<slangasek> bdmurray: I think it should be fixed
<bdmurray> slangasek: okay, the fix should really be in apt-key though not the cronjob like in the patch. correct?
<slangasek> bdmurray: ah, hadn't looked at the patch... yes, I think apt-key itself should respect the setting
<slangasek> bdmurray: apt-key is a shell script that already calls apt-config for lots of settings, it should pick the proxy out as well
<lcc> I'm getting occasional kernel panics with 12.04. I've never had any kernel panics with 11.10.
<SpamapS> lcc: you may want to join #ubuntu+1 , as that is frequented by quite a few beta testers
<SpamapS> lcc: while this channel is just for discussion fo development itself
<lcc> oh ok
<smoser> slangasek, you around ?
<smoser> you able to take a quick sniff of bug 948461
<ubottu> Launchpad bug 948461 in apt (Ubuntu) "apt-get hashsum/size mismatch due caused by swapped local file names" [Undecided,Confirmed] https://launchpad.net/bugs/948461
<lerop> anyone willing to write me a fully selinux script for 11.10 it can be python if thats easier and be willing to do it for $25
<lerop> as selinux as can be
<ScottK> Heh.
<ScottK> For $25 I'd type #!/usr/bin/python.
<StevenK> zsh: no such file or directory: /usr/bin/python.
<StevenK> :-P
 * ScottK didn't say it'd do anything.
<StevenK> You also didn't say where you'd type it
<ScottK> That too.
<ScottK> But what to you expect for $25.
<ScottK> (even US or Canadian, he may have meant Australian)
<lerop> i can type that with my pinky toe
<elky> My pinkie toe can send you an artistic interpretation of a selinux script for $25. I take non-refundable payment in advance.
<Gaming4JC> I don't suppose any nice developer could get this moving along? :)
<Gaming4JC> https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/821100/
<ubottu> Launchpad bug 821100 in ia32-libs (Ubuntu Natty) "ia32-libs does not install /usr/lib32/libGL.so.1" [Undecided,Confirmed]
<Gaming4JC> I really need ia32libs with libGL on natty for a project I'm working on
<Gaming4JC> and sadly it doesn't exist :/
<slangasek> smoser: I'm entirely failing to understand the thesis statement of this bug
<slangasek> smoser: the claim is that *apt* is saving the files to the wrong filenames after downloading them?  I have a hard time believing that's been happening since hardy and someone's just noticed it now
<smoser> i have your same thoughts.
<smoser> you do understand the thesis statement.
<slangasek> hmm
<smoser> http://paste.ubuntu.com/872478/
<smoser> that kind of shows the failure.
<smoser> (and i just updated the bug with a comment)
<smoser> note, in that pastebin at the end, i download the libpolkit-agent-1-0_0.104-1_amd64.deb via wget
<smoser> and md5sum it
<smoser> in the wget output, the md5sum matches that of the 'apt-get' download of libxcb-util0_0.3.8-2_amd64.deb
<smoser> slangasek, so i'm trying to reproduce with more traditional mirrors.
<smoser> but believing that S3 is serving incorrect file content, is only moderately more difficult than to believe that apt is $*#@ing up itself.
<smoser> as both are involved in huge amounts of gets per day
 * slangasek nods
<slangasek> so wget returns the correct file where apt-get returns the wrong one/
<lifeless> one thing that can look the same
<lifeless> is truncated content
<lifeless> if you have a non-TE stream and no content-length header, HTTP cannot tell the difference between internet fail and EOF
<slangasek> lifeless: this doesn't appear to be a case of truncation; the objects are just plain swapped on the filesystem after download
<slangasek> clean md5sum... belonging to the wrong file
<lifeless> kk
<lifeless> was just putting it out there :)
<slangasek> smoser: is it reproducible with a single package download (e.g., apt-get install thing-with-no-depends)?  or does it only go wrong when downloading multiple files with the same http process?
<smoser> lifeless, its not truncated content.
<smoser> dpkg -I shows info on the deb downloaded
<smoser> slangasek, i'm going to test now, just runnig wget in a loop
<smoser> on that file that had bad content
<smoser> and wget ... checksum ... wget ...
<smoser> see if i can take apt out completely
<slangasek> smoser: see if it's reproducible with Acquire::http::Pipeline-Depth=0
<slangasek> (cf. apt.conf(5))
<smoser> slangasek, k. let me test this wget in a loop for a while first.
<psusi> lifeless, huh?  connection failure will result in a connection reset, not a clean close...
<lifeless> psusi: and yes wget curl etc all have displayed this in the past
<psusi> lifeless, you mean they return a zero exit status when they get a connection reset instead of eof?
<psusi> I could have sworn that wget was smart enough to detect that and try to reconnect and resume the download...
<lifeless> psusi: it may be nowadays, my HTTP mental model is a melange of 16 years encounters ;)
<smoser> slangasek, so.. some info.
<smoser>  http://paste.ubuntu.com/872513/
<smoser> doesn't seem to fail. (just repeated wget).
<smoser>  http://paste.ubuntu.com/872514/
<smoser> doesnt seem to fail (it has your Pipeline-Depth)
<smoser> but a simple removing of that Pipeline-Depth seems to give failure.
<lifeless> http pipelining ? Terrible idea :(. (poorly supported, and a microoptimisation that encourages serious security issues and bugs)
<lifeless> channels are much better, which spdy and AFAICT all the other HTTP 2.x candidates offer
<smoser> and apparently default behavior in apt
<smoser> :)
<lifeless> smoser: I argued against this on debian-devel.
<smoser> lifeless, then i blame you
<lifeless> Apparently upstream cache developers don't know enough.
<smoser> for not winning that argument
<smoser> :)
<smoser> http://kb.cloudopt.com/index.php/Known_Problem:_HTTP_Pipelining_Fails_with_BucketExplorer
<smoser> well this royally sucks.
<lifeless> http://old.nabble.com/APT-do-not-work-with-Squid-as-a-proxy-because-of-pipelining-default-td28579596.html
<smoser> lifeless, thanks.
<smoser> i'm headed to bed, but anyones thoughts (slangasek) on what we could do about this issue would be greatly apprecited.
<smoser> ie, we want to put these S3 mirrrors in place , and this would block that.
<smoser> and this default seems present back to hardy
<TheMuso> Is it just me, or is firefox segfaulting on startup after latest updates?
<pitti> Good morning
<scientes> what does the ubuntu live-cd installer use to make a new partition label?
<SpamapS> probably gparted, but I'm just guessing
<scientes> you mean parted
<scientes> which gparted is a front-end to
<scientes> cause if you have a iso9660 live cd on the sd card, and then try partitioning it, grub-install fails cause it still detects the iso9660 file system even though there is a msdos partition table
<scientes> so i am about to write the patch that zeros out the rest of the header in the msdos partition lable
<scientes> if it detects a iso9660 image already there
<scientes> instead of just writing the bare minimum
<scientes> there is a small gap that grub is using that i guss isn't zeroed
<ritz> Is it possible to locally build a package for oneiric from bzr branch on precise, using buildeb plugin ?
<micahg> ritz: with sbuild or pbuilder, sure
 * ritz checks sbuild 
<dholbach> good morning
<rickspencer3> hey pitti, close to a beer this morning!
<pitti> not sure what's wrong with the meta-kde packages
<micahg> pitti: kde4libs was uploaded w/out the rest of the stack
<micahg> oh, rather, meta-kde was uploaded without the rest of the stack save kde4libs :)
<rickspencer3> pitti, micahg well, it looks like the rest of the archives, including armhf are in good shape now for multiple days in a row
<rickspencer3> this has to be a good thing for developers
<pitti> yes, indeed
<rickspencer3> :)
<seb128> slangasek, hey
<seb128> slangasek, did you get anywhere with that gconf upgrade bug?
<seb128> it's flooding my bug emails box :p
<tjaalton> i synced a package with syncpackage, but it's not processed yet unlike the other upload I just did
<tjaalton> is the process different there?
<pitti> tjaalton: it's source NEW, and thus in https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<tjaalton> pitti: oh right, it got split from arduino..
<tjaalton> @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: tjaalton, sconklin
 * dholbach hugs tjaalton and sconklin
<sladen> who synced 'tzdata' ~3 hours ago?
<micahg> sladen: pitti did, why?
<sladen> pitti: it appears to be resetting the timezone on package install
<pitti> reset how?
<pitti> works fine here
<pitti> $ cat /etc/timezone
<pitti> Europe/Berlin
<sladen> $ cat /etc/timezone
<sladen> Africa/Bamako
<sladen> filed as bug #948809
<ubottu> Launchpad bug 948809 in tzdata (Ubuntu) "tzdata says "Current default time zone: 'Africa/Bamako' during package install; previously was 'Europe/London' during OS install" [Undecided,New] https://launchpad.net/bugs/948809
<sladen> whether that's because Europe/London is sometimes the same as UTC
<pitti> slangasek: could you please add the output of "grep -A3 '^Name:.*tzdata' /var/cache/debconf/config.dat" ?
<pitti> argh, sladen ^
<pitti> slangasek: please ignore me
<micahg> tjaalton: seamonkey-browser is now a transitional package, can you fix your upload to enhance seamonkey?
<sladen> pitti: added.  The two interesting Value: lines are "Berlin" and "UTC"
<tjaalton> micahg: sure
<pitti> there's no packaging change in latest tzdata, so it must be a bug that's lurking for ages already
<sladen> yikes. it's changed it in indicator-timedate too
<pitti> slangasek: no "london" at all, hmm
<pitti> sladen: I take it you don't know what /etc/timezone said before the upgrade
<sladen> pitti: would have been 'Europe/London'
<sladen> pitti: would it be worth patching the package in the short term to at least dump the previous value, before the logic takes place
<pitti> we could, but here we are pretty sure about the previous value
<micahg> tjaalton: thanks
<tjaalton> anyone opposed to the change proposed here https://code.launchpad.net/~blkperl/ubuntu/precise/plymouth/fix_blank_screen/+merge/95817
<tjaalton> it's true that on servers you get a blank screen on startup
<tjaalton> tested that it works
<tjaalton> huh, not a single plymouth upload in precise
<tjaalton> guess it's stable then ;)
<seb128> tjaalton, you know how it goes: "you upload it, you maintain it"
<seb128> tjaalton, nobody wants to maintain it ;-)
<RAOF> Broken on hybrid graphics in some circumstances, sadly.
<tjaalton> seb128: yeah, I'll just ack the change then :)
<tjaalton> uh, cryptsetup is 1,5y old
<tjaalton> last merge in november 2010
<dupondje> tjaalton: indeed, thats why I prepared a merge for it
<dupondje> :)
<Daviey> infinity: Are you going to be looking at bug 759545?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<Daviey> cjwatson: noticed biosdevname bugs starting to appear, bug 948559 and bug 948546, for example
<ubottu> Launchpad bug 948559 in vlan (Ubuntu) "eth* NIC names hardcoded" [Undecided,New] https://launchpad.net/bugs/948559
<ubottu> Launchpad bug 948546 in bridge-utils (Ubuntu) "eth* device names hardcoded in debian/bridge-utils.sh" [Undecided,New] https://launchpad.net/bugs/948546
<jodh> Any French speakers interested in taking a look at bug 948884? rickspencer3 ? ;)
<tjaalton> dupondje: yeah, acked, hopefully accepted too..
<ubottu> Launchpad bug 948884 in mbrola (Ubuntu) "mbrola is unable to pronounce the French word "les"" [Undecided,New] https://launchpad.net/bugs/948884
<dupondje> lets hope so :)
<dupondje> there is also TRIM support in the new version
<cjwatson> Daviey: thanks
<roignac_> hi all! I'm trying to propose a merge for lp:~ubuntu-desktop/nautilus/debian
<roignac_> but lp keeps switching me to lp:nautilus
<roignac_> is there any way to avoid this redirect?
<roignac_> Or should I abandon all hope and send patches instead of branches?
<dupondje> tjaalton: who could push it ? :)
<seb128> roignac_, hey, how do you propose the merge? did you branch of lp:~ubuntu-desktop/nautilus/debian ?
<seb128> roignac_, it should use the parent branch...
<tjaalton> dupondje: someone of the release team needs to ack it
<roignac_> seb128: I branched lp:~ubuntu-desktop/nautilus/ubuntu
<seb128> roignac_, on https://code.launchpad.net/~roignac/ubuntu/precise/nautilus/bug_32542_save_search_as_button/+register-merge
<seb128> roignac_, select other and type ~ubuntu-desktop/nautilus/ubuntu
<seb128> that should work?
<roignac_> seb128: target branch is specified as lp:ubuntu/nautilus =/
<seb128> roignac_, right, but you can pick "other" and type ~ubuntu-desktop/nautilus/ubuntu no?
<roignac_> seb128: i tried this, but LP keeps redirecting to lp:nautilus
<seb128> roignac_, ask on #launchpad I guess
<roignac_> ok, thanks
<roignac_> seb128: thanks, #launchpad guys did help
<seb128> roignac_, what was the issue?
<roignac_> Though they also wondered why does ~ubuntu-desktop uses lp:~ubuntu-desktop/nautilus, but not lp:~ubuntu-desktop/ubuntu/nautilus branches for packaging
<dupondje> cjwatson: could you check https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 for me ? :)
<ubottu> Launchpad bug 776264 in cryptsetup (Ubuntu) "FFe: Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,Confirmed]
<roignac_> seb128: I've created a branch in /ubuntu (following the tutorial), but the destination branch was in /nautilus
<seb128> seems like a launchpad bug
<seb128> it shouldn't stop on namespace and let you overwrite the destination
<roignac_> nope, this is a little problem with packaging branch. If a newbie like me strictly follows tutorial at Bugs/HowToFix one will branch lp:ubuntu/nautilus
<roignac_> sorry, will branch ~ubuntu-desktop branch and will push it to lp:~username/ubuntu/nautilus
<cjwatson> dupondje: I'd rather not, I don't know cryptsetup at all well
<dupondje> ok no problem
<roignac_> seb128: so he won't be able to merge with lp:~ubuntu/nautilus
<roignac_> sorry for spam, everybody
<seb128> roignac_, sorry that the workflow is not consistent
<seb128> roignac_, we don't use the udd way for desktop for several reasons
<seb128> roignac_, that's part of the issue
<roignac_> I see, so attaching patches is easier and much safer
<dupondje> maby we should add 'last time merged (days ago)' to the MoM? Cause I guess some more packages are really out-of-date
<cjwatson> https://bugs.launchpad.net/merge-o-matic/+bug/881487
<ubottu> Launchpad bug 881487 in Merge-o-Matic "need to be able to see how long it's been since the package was last merged" [Undecided,New]
<dupondje> hehe :D
<cjwatson> Daviey: OK, fixed both of those now
<Daviey> cjwatson: Oh, i wasn't prodding you to fix them!  Just a FYI
<ritz> gtk+3.0 build fails from source on precise, with ./.libs/libgtk-3.so: undefined reference to `ubuntu_menu_proxy_insert'
<ritz> https://pastebin.canonical.com/61799/
<ritz> what am I missing here ?
<seb128> ritz, no it doesn't
<ritz> seb128, hmmm, the is a bzr branch  lp:ubuntu/gtk+3.0, over which I ran configure with the stated option
<seb128> ritz, what version did you try to build and how?
<seb128> ritz, did you apply the patches in debian/patches?
<ritz> I did nothing, just branch and ran configure
<seb128> ritz, those are packaging branches, they are made to build packages not to be built like a trunk
<seb128> i.e debian/rules has usually the correct recipies to build
<seb128> which include i.e applying the distro patches
<infinity> Daviey: Yes.  I think I'll look harder at it today.
<ritz> interesting, was not aware of this
<seb128> ritz, well you can of course build it like a trunk, you just need to figure what the packaging is doing and you are not, could be that forgot to apply patches or forgot ldflags or build options
<ritz> cool, thanks
<sconklin> @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: tjaalton
<ritz> seb128,  where does ubuntu store "trunk" , or ubuntu requires patches for most packages ( like gtk/indicator) ?
<seb128> ritz, define trunk
<seb128> ritz, the packacing is usually upstream trunk with build rules and distro patches
<seb128> well upstream "trunk" -> "tarballs"
<ritz> hmmm, fair enough
<ritz> so, debian/rules will enable the ubuntu specific build/patches
<ritz> seb128, Thanks, build fine now
<ritz> me--
<infinity> ritz: Yes.  In general, something like "debuild -b" will give you what you want.
<Daviey> infinity: thanks!
<ritz> hmm, interesting.
<ritz> infinity, thanks :)
<Q-FUNK> would anyone happen to know where the keyring password for ubuntu-dev-tools e.g. synpackage is stored? I would need to change it.
<infinity> Q-FUNK: https://launchpad.net/people/+me/+oauth-tokens
<infinity> Q-FUNK: And revoke?
<Q-FUNK> infinity: I meant that password that is asked in the shell whenever I run 'syncpackage'
<infinity> Oh.  I don't think I've ever been asked for a password...
<Q-FUNK> not the access rights granted to applications to play with LP on my behalf :)
<infinity> It doesn't need any other passwords... Except possibly GPG passphrases for --no-lp use.
<pitti> Riddell: do you know what changed yesterday to cause http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html ?
<ScottK> pitti: Without looking, I'll guess we started uploading KDE 4.8.1.
<Q-FUNK> infinity: here, it asks for a password
<infinity> Sure looks that way.
<geser> Q-FUNK: if you're running GNOME then it's in your gnome keyring (similar if you use KDE)
<ScottK> pitti: That's it.  It should get sorted today.
<Q-FUNK> geser: stored under which key name?
<pitti> ScottK: thahnks
<pitti> ScottK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt now has a large armada of stuff that wants to go to universe; are these really all obsolete, or is that just temporary?
<infinity> pitti: Probably worth completely ignoring archive reports about anything vaguely KDE-related until the transition's done.  It's always bumpy. :/
<pitti> ack
<ScottK> pitti: I'd be very surprised if it's not temporary.
<geser> Q-FUNK: good question, never had to look it up yet how in detail python-launchpadlib stores the password; perhaps ask in #launchpad
<tjaalton> are cross-architecture depends/recommends allowed yet?
<infinity> tjaalton: Only if it's never going to happen on a buildd.
<dupondje> pitti: about cryptsetup merge, how you want to test it exactly? root disk completely encrypted with LUKS or ?
<infinity> tjaalton: See, eg: ia32-libs (on amd64), which depends on ia32-libs-multiarch (which only exists on i386)
<pitti> dupondje: yes, something like that; the alternate install supports this schema
<dupondje> so just a precise daily install and then upgrade
<dupondje> i'll fix :D
<pitti> dupondje: usually it's raw disk <- cryptsetup partion <- LVM <- root/home etc.; and then a separate /boot
<infinity> tjaalton: Buildds, however, are intentionally not multiarch-aware, to keep the architectures self-contained, so no pulling of such tricks on anything that might be a build-dep of.. Anything.
<ScottK> stgraber: What would be an example of a social membership that the DMB would process?
<pitti> dupondje: thanks, much appreciated!
<tjaalton> infinity: right, this is for !buildd
<infinity> tjaalton: Then yeah, it can be done, and we've been doing it since oneiric (see the above example)
<infinity> tjaalton: flashplugin-nonfree works similarly.
<stgraber> ScottK: an existing coredev who isn't a direct member of MOTU and who's been spending a lot of time helping people in #ubuntu-motu or helped with universe QA or similar activities and who wants to be a MOTU has they feel they're part of that effort (vs just wanting the upload rights that they already have anyway)
<tjaalton> infinity: right, of course. just double-checking :)
<ScottK> stgraber: OK.  That makes complete sense.  It wasn't so clear from the wiki entry.  You might add an example ...
<ScottK> Thanks.
<infinity> tjaalton: There are upgrade concerns to watch for.  flashplugin-nonfree and ia32-libs both introduced new-named packages to make sure that upgrades did sane things.
<infinity> tjaalton: (As in, if you just drop the amd64 version of a package, and expect apt to magically upgrade it to i386, that might end badly for you)
<infinity> tjaalton: In those cases, we kept the old package names in place, but made them transitional packages that depended on a new i386-only package.
<tjaalton> infinity: hmm actually I'm thinking if it was possible for a package to declare a relationship like "Depends: foo:i386 [amd64]", but now I realize how that'd not be that useful on debian :)
<infinity> tjaalton: That's not doable, no.
<infinity> tjaalton: The tricks we pull are based on transitive dependency backfill, I guess is a good way to put it.  As in, we make sure the package only exists on one arch in the first place.
<infinity> And then depend on it.
<infinity> "Depends: foo:arch" isn't allowed.
<infinity> (Though people pulling dirty tricks like we have might be proof that we should revisit adding foo:arch deps)
<tjaalton> :)
<jamespage> please could someone poke the package importer to update the rabbitmq-server branch - its a bit out of date..
<ogra_> infinity, what did you do last time to make alsa-lib build on x86 ? it failed again with the same cryptic error
<ogra_> ...
<ogra_> checking whether we are cross compiling... configure: error: in `/build/buildd/alsa-lib-1.0.25/bibuild':
<ogra_> configure: error: cannot run C compiled programs.
<ogra_> ...
<infinity> ogra_: Build it on palmer.  I'll do it.
<ogra_> thx
<infinity> Err, roseapple.
<infinity> Whatever.
<ogra_> any idea what causes it ?
<infinity> It's running amd64 code. :/
<ogra_> ouch, k
<infinity> It needs merging to fix that.
<infinity> Some day.
<infinity> Alright, I have to head out for a bit.
<infinity> alsa-lib building.
<smoser> hi, i have a question about debconf usage that i'd like to get some input on.
<smoser> cloud-init has a couple debconf things that can be seeded, and a configuration format that supports config.d type behavior.
<smoser> i'm considering allowing a debconf preseed value of "local-config" or something that would then largely just get dropped into cloud.cfg.d/99-local
<smoser> the reason for this is that cloud-init preseeding is likely to be done by a machine.
<smoser> so more friendly menus or such are not necessary, but i'd like to open up a very generic window to doing this without having the pre-seeder need a late_command script or something to populate that.
<dupondje> pitti: I installed a precise system, upgraded cryptsetup. Now I rebooted and it works fine, but I get some delay @ booting, the error: error: no video mode activated
<dupondje> but thats unrelated I guess ?
<pitti> doesn't sound cryptsetup-ish
<pitti> dupondje: did you get this with the previous cryptsetup, too?
<jcastro> cyphermox: hey so the reason I said "12.10" for the BT audio mail is I don't know enough about it to know if it was a ood idea for 12.04
<jcastro> cyphermox: is it really that simple a fix though? I mean, there's a wireless device and audio involved, I was expecting mountains needing to be moved, etc.
<cyphermox> jcastro: no, it's a simple two-line patch to enable this in bluez
<jcastro> cyphermox: and the sound indicator has GUI support for this and all that?
<cyphermox> there's still going to be the need for manual setup to reroute the streams to the right output device though
<cyphermox> right, no it doesn't ;)
<jcastro> oh ok, so we can at least suck less off the bat, that's good!
<smoser> cjwatson, do you have thoughts on my debconf idea above ? or slangasek ?
<smoser> (sorry for asking by name)
<cyphermox> jcastro: right, this makes us suck less from the start
<dupondje> hmz pitti Mar  7 16:09:09 ubuntu kernel: [   15.858831] init: udev-fallback-graphics main process (773) terminated with status 1
<tjaalton> slangasek: I pushed a commit to plymouth and noticed it had two commits staged since september. mind checking if they should get in precise, and check the new one too :)
<pitti> dupondje: is this with the current cryptsetup, or only with the updated one? if the latter, this needs to be investigated
<dupondje> lets see if downgrade fixes it
<dupondje> pitti: downgraded again, same issue.
<pitti> dupondje: ok, thanks; so that confirms it's not due to that
<cjwatson> smoser: not sure I really know cloud-init well enough to be able to comment usefully, TBH
<smoser> well, generally, cjwatson i'm asking if it would be appropriate to have a debconf question like "local-config"
<smoser> which woudl contain config-blob for the $GENERIC_PACKAGE
<smoser> or if that is bad form for some reason or another
<cjwatson> I have no idea, you'll find all sorts of examples in the archive probably :-)
<smoser> (i assume i'm going to possibly need to be smart with new line hanling or something in the value of the string)
<cjwatson> I don't see why late_command scripts are somehow evil though
<cjwatson> it is explicitly not a design goal of debconf to let you configure every last possible scenario
<cjwatson> but, if you want your package to have its own more targeted equivalent of late_command, *shrug*
<cjwatson> just think about how it's going to handle upgrades
<smoser> cjwatson, thank you for the feedback.
<smoser> Daviey, ^
<slangasek> seb128: no, no progress on gconf yet :/
<smoser> my thought process there is, that rather than generally allowing configuration of one bit of cloud-init (for bug 924375), i'll just open up a big blob
<ubottu> Launchpad bug 924375 in cloud-init (Ubuntu) "cloud-init should allow pre-seeding of ec2 datasource:Ec2:metadata_urls" [Medium,New] https://launchpad.net/bugs/924375
<Daviey> smoser: Yeah, late command of, "echo "http://foo/bar" > /etc/cloud-init.d/next-server , is pretty cheap
<Daviey> cjwatson: debconf low, and default value should handle upgrades fine, no?
<smoser> Daviey, right, but i see value in not requiring late_command (at least i think i do )
<cjwatson> Daviey: it sounds like it shouldn't even be asked at all
<cjwatson> you don't actually need to db_input things ...
<smoser> i'm good with not even asked at all if thats possible.
<smoser> good enough for me.
<smoser> is there a defined escaping mechanism for debconf values ?
<mhall119> mvo: ping (you know why)
<smoser> (ie, to deal with '\n' or other potentially problematic things)
<mvo> mhall119: *cough* I do! and no excuses from me this time let me look at the branch
<cjwatson> debconf-escape(1)
<Daviey> cjwatson: right, but i was thinking smoser might want people to be able to enter a value
<cjwatson> I don't think that's generally the right answer for "giant blob" type things
<cjwatson> preseed/late_command doesn't get asked
<cjwatson> can't remember whether it would be a good idea to set the 'escape' capability in this circumstance; possibly not, but try either way :)
<Daviey> Yes, so it really depends if smoser thinks users will want that question asked... if late_command on a debconf question is suitable
<smoser> i dont think users would want the question asked.
<smoser> i'm inserting it for machines.
<Daviey> smoser: ok, then late_command is almost free :)
<smoser> machine's whose only real interface is preseed
<smoser> the issue with late_command is that it doesn't stack terribly easy
<smoser> without some general infrastructure in place.
<smoser> ie, if 3 things want to add late_command, something has to join them on ';' or something.
<cjwatson> I don't have a problem as such with an extra specialised unasked question for this; this is totally up to packages
<smoser> thanks, cjwatson .
<dupondje> cjwatson: some question about grub2. Getting "error: no video mode activated", could this be caused because it tries to read fonts from /usr/share/grub/ ?
<tjaalton> doko: icedtea-netx-common is marked arch: all, but it builds a desktop file with the path to javaws with an arch dependent path. should the binary package be made arch: any, or the desktop file moved?
<doko> tjaalton, best to move to icedtea-netx, I'll do this for the final 1.2 packages. thanks
<tjaalton> doko: ok, cool
<tjaalton> also, looks like installing the package isn't enough to make the links load the app by default, instead firefox will try to "open" it which just results in an empty tab..
<tjaalton> .jnlp links I mean
<tjaalton> this all to get my kid to do her homework ;)
<blackbug> Hello, I have a question regarding the screenshot application in ubuntu. Which is the default application invoked with printscreen key?
<tjaalton> blackbug: gnome-screenshot
<cjwatson> dupondje: yeah, known problem when using cryptsetup, will be fixed with 2.00
<cjwatson> dupondje: best ignored for now :)
<dupondje> 2.00 will get into precise?
<blackbug> tjaalton: thanks, where i can find src code for it?
<tjaalton> blackbug: apt-get source gnome-screenshot
<dupondje> pitti: the error I got is grub2 related (tries to open files on /usr/share which is still crypted). Will you upload cryptsetup? or want me to comment the bug?
<tjaalton> or bzr branch lp:ubuntu/gnome-screenshot
<tjaalton> ah, that doesn't work
<blackbug> tjaalton: thanks i needed bazaar branch.
<ScottK> apt-get source gnome-screenshot should work too
<blackbug> yes, "bzr branch lp:ubuntu/gnome-screenshot" isnt working..
<tjaalton> @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:
<cjwatson> dupondje: no
<cjwatson> dupondje: waaaaaaaaaaaay too many changes
<blackbug> a naive question: i have just started exploring ubuntu apps source code, in case I make some changes, how should i test it? should i compile/build whole code on my machine and replace install new binaries.. or any other test enviornment method or way
<dupondje> cjwatson: hÃ©hÃ©h :) no workaround that can be made for that issue? cause now there is some delay ... :)
<cjwatson> dupondje: no, sorry
<cjwatson> dupondje: at least not one I consider safe for precise
<cjwatson> I'd rather have stable-and-slow than unknown-and-fast
<cjwatson> at least for non-default scenarios like cryptsetup
<dupondje> cjwatson: ok no big issue indeed :)
 * seb128 closes another set of duplicates of bug #948294 and look at slangasek
<ubottu> Launchpad bug 948294 in gconf (Ubuntu) "package gconf2 3.2.3-3ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 250" [High,Confirmed] https://launchpad.net/bugs/948294
<slangasek> yes
<seb128> slangasek, I think bug #948457 and bug #948296 are yours as well
<ubottu> Launchpad bug 948457 in gconf (Ubuntu) "package gconf2 3.2.3-3ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [Undecided,Confirmed] https://launchpad.net/bugs/948457
<ubottu> Launchpad bug 948296 in gconf (Ubuntu) "gconftool-2 crashed with SIGABRT in g_test_log()" [Medium,Confirmed] https://launchpad.net/bugs/948296
<seb128> slangasek, could be the same underlining issue
<slangasek> if they're new symptoms, I guess so
<seb128> slangasek, yes, all started with 3ubuntu1 and all happen "while upgrading"
<bdmurray> seb128: is there a bug about icon text wrapping on periods like in bug 942539?
<ubottu> Launchpad bug 942539 in ubiquity (Ubuntu) "Ubiquity desktop icon text looks messy" [Low,Triaged] https://launchpad.net/bugs/942539
<seb128> bdmurray, I don't think so, I'm not convinced it's a bug
<seb128> bdmurray, you need to wrap somewhere, dot are usually end of words or sentences
<seb128> bdmurray, though indeed in that case it's unfortunate
<blackbug> Hello, repeating my question, in case anyone has any idea about it. "a naive question: i have just started exploring ubuntu apps source code, in case I make some changes, how should i test it? should i compile/build whole code on my machine and replace install new binaries.. or any other test enviornment method or way"
<mvo> mhall119: I gave the MP a +1, while I'm the original edit-patch author, I don't actually have commit access to devscripts so that is all I can do for now
<mhall119> mvo: thanks, do you know who can approve it?
<slangasek> seb128: I certainly think wrapping after a period with no space after it is a bug; it violates all the standard word-wrapping rules for English.
<roaksoax> pitti: ping?
<roaksoax> pitti: Hi! I'm looking to create a user/pass and a db for postgresql, from .postinst file. Is there any recommended way to do so?
<mvo> mhall119: I think its https://launchpad.net/~devscripts-dev - so bdrung
<mhall119> mvo: thanks, I've already pinged bdrung about my submission to debian too
<mvo> thanks
<mhall119> bdrung: ^^ Please ping me if you need anything else for than MP
<bdrung> mhall119: the edit-patch fix?
<mhall119> bdrung: yes
<bdrung> mhall119: i can look into it tomorrow. feel free to ping me again.
<seb128> slangasek, right, though it's not a word, it's numbers and dot only, like if you had 123.456.789.123 not sure if rules dictate that to not be wrapped
<PaoloRotolo> Hi all!
<seb128> slangasek, but I don't know enough about unicode rules to say
<slangasek> seb128: er, Unicode certainly can't dictate the rules here, they may vary by language
<slangasek> for *English*, splitting on the dot is wrong :)
<seb128> slangasek, well, gtk upstream apparently follow http://www.unicode.org/reports/tr14/
<seb128> "Unicode Line Breaking Algorithm"
<mhall119> bdrung: will do, thanks
<slangasek> phooey
<seb128> slangasek, so unicode can't dictate but they do :p
<seb128> slangasek, though gedit seems to wrap 12.04 correctly so it might well be a nautilus bug indeed
<smoser> @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: smoser
<seb128> slangasek, bdmurray: yeah, seems a nautilus icon grid bug, when renaming the text entry wraps it correctly
<slangasek> seb128: the unicode standard lists . as an "Infix Numeric Separator" that should only break between numbers if accompanied by a space
<seb128> slangasek, right, nautilus bug
<seb128> I somewhat doubt it's important enough on the nautilus list for having anyone upstream to care about it
<seb128> it's unfortunate it's showing on the liveCD though :-(
<brendand> i don't think it's anything to do with the full stop
<brendand> if you put, e.g. - then it still breaks at the dash
<brendand> hmm, but not with anything else
<brendand> seb128 - workaround is to stick a unicode 000D (CR) character in there. will that fly?
<bdmurray> brendand: that idea was discussed in the bug
<seb128> brendand, if that works sure
<brendand> stgraber has a good point about the translation implications though
<blackbug> I have posted a bug 949116 which is related to mounting of internal/external harddisk and usb drives in 12.04. Also, nautilius
<ubottu> Launchpad bug 949116 in gvfs (Ubuntu) "Internal hard disk partition is not displayed in Places menu,. My computer icon doesn't open up and show the internal/usb disk." [Undecided,New] https://launchpad.net/bugs/949116
<smoser> kenvandine, ping
<cnd> is there any issue with always building static libraries with -fPIC?
<cnd> I'm trying to figure out a resolution for https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/949244
<ubottu> Launchpad bug 949244 in gtest (Ubuntu) "libgtest.a needs to be built with -fPIC" [Undecided,New]
<cnd> I'm thinking of just adding "--with-pic" to the configure flags when building the package
<kenvandine> smoser, pong
<smoser> kenvandine, http://pad.lv/762167
<ubottu> Launchpad bug 762167 in light-themes (Ubuntu) "missing dependency on gtk2-engines-pixbuf" [Undecided,Triaged]
<smoser> i'm patch piloting, and that looks sane to me, but seb had asked you to look at it.
<smoser> i'll build and upload if you think its sane.
<smoser> the only question i had is if gtk2-engines-pixbuf should have a versioned depends of some sort (since gtk-engines-murrine does, but i have no other reason than that)
<kenvandine> smoser, the version probably isn't really important anymore
<kenvandine> looks fine to me, go for it!
<kenvandine> smoser, thanks
<smoser> thanks.
<slangasek> cnd: convention is to build a .a and a _pic.a, but that's not a hard rule; we sometimes build .a with -fPIC when it's not logical to ever support a non-PIC lib
<cnd> slangasek, when would we want to support a non-PIC lib?
<slangasek> cnd: the only reason anyone cares about non-PIC .a is because i386 is register-poor, and PIC eats registers
<cnd> this is for gtest, which wouldn't be used outside of test runs
<cnd> slangasek, I assume the only problem with i386 being register poor is that stuff will run slower?
<cnd> if so, I think that's ok for tests
<blackbug> hello, i am trying to compile an apps code, but getting the following error.."configure: error: Package requirements (glib-2.0 >= 2.31.0
<blackbug>                   gtk+-3.0 >= 3.0.0
<blackbug>                   libcanberra-gtk3) were not met:
<blackbug> No package 'gtk+-3.0' found
<blackbug> No package 'libcanberra-gtk3' found
<blackbug> Consider adjusting the PKG_CONFIG_PATH environment variable if you
<blackbug> installed software in a non-standard prefix.
<blackbug> "  i am using 12.04 gnome.
<slangasek> cnd: much, much slower, yes - but yeah, for gtest it's probably ok
<cnd> ok
<cnd> slangasek, thanks!
<arges> if I want to see the output of g_debug in gnome-settings-daemon is there  a package with the debug output enabled? or do I need to build my own package? thanks
<ScottK> arges: Yes.  No.  See https://wiki.ubuntu.com/DebuggingProgramCrash
<arges> ScottK, thanks
<iulian> Laney: Errm, it should've worked! :-(
 * iulian sighs.
<blackbug> i want to debug a core file. but the application is not giving the core file inspite of displaying segmentation fault and dumping core file msg. i already checked ulimit which is set to unlimited. any other clues?
<mhall119> stgraber: jelmer: james_w: seb128: can you guys please read over http://people.ubuntu.com/~mhall119/blog/patching.html and let me know if you think it's okay?  I tested it out with geany and all the commands worked fine there.
<james_w> mhall119, looks ok
<james_w> mhall119, for the reverting, "bzr revert" might be easiest, but if there are extra revisions, then I would suggest "bzr merge . -r 32..31" as it saves a command and will handle renames and things better
<mhall119> james_w: what command does it save?
<james_w> bzr patch
<mhall119> james_w: doing it with merge makes bzr fail, somethign to do with geany having applied quilt patches on the branch
<james_w> ah, hmm
<seb128> mhall119, it's over my bzr knowledge, if james_w is happy with it I'm sure it's good
<mhall119> james_w: here's the fun output from trying to do it via merge: http://paste.ubuntu.com/873490/
<mhall119> I did realize I forgot to have them update the changelog with dch -i, I'm adding that step now
<mhall119> seb128: ^^ I assume that should be done, right?
<dobey> is there no way to say "if x is installed, then y must be installed" when x is a recommends, and it doesn't itself rquire y, but the package's usage of x does require both?
<dobey> i guess not
<ajmitch> only way I can think of offhand is depending/recommending a metapackage that depends on both x & Y, but that isn't nice at all
<slangasek> yeah, there's really no way to do conditional package relationships
<broder> ah, damn. i screwed up the udd branch for bluez because i didn't see that cyphermox had already uploaded 4.98-2ubuntu3 (he apparently beat me by 6 minutes). what can i do to reset the state of the udd branch?
<cyphermox> dah, sorry broder
 * broder shrugs
<broder> i'll merge and re-upload - it's no big deal
<broder> just not sure how to fix the branch, since i already pushed my (now inaccurate) tag
<mhall119> james_w: refresh, I added step 4 (dch -i)
<slangasek> broder: if you want the importer to not fall over later down the line, I guess it's best to just leave the tag wrong.
<slangasek> (there are no great choices here, given the importer's persistent refusal to accept bzr tag --delete as a possibility)
<broder> :(
<cnd> slangasek, I attempted to file a debian bug report using reportbug, but I think it failed to send the email at the end
<cnd> do you know how to be sure and/or how to send it manually?
<cnd> I have ssmtp set up
<cnd> actually, it's msmtp
<cnd> don't know if that makes a difference
<slangasek> cnd: with those MTAs I'm not sure how to check, but to send it manually, you just have to send the message to submit@bugs.debian.org with the body of the message intact
<stgraber> cnd: ssmtp logs in syslog usually (though it's very limited logging and won't give you a way to access your mail as it doesn't do spooling)
<cnd> ok
<cnd> slangasek, I assume the turn around time for filing a bug report and receiving a reply back should be less than 15 mins?
<broder> slangasek: the importer did actually just move my branch aside and recreated it with the correct histor
<cnd> slangasek, looks like it got filed, thanks!
<slangasek> broder: oh, wunderbar :)
<slangasek> cnd: < 15 mins - no guarantees ;)
<broder> slangasek: https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/bluez/precise-201203072011/+merge/96445
<broder> (which i'm going to reject, because i've already handled the merge)
<seb128> slangasek,
<seb128> bzr: ERROR: An error (1) occurred running quilt: Patch 05_readd_gconf_engine_key_is_writable.patch does not exist
<seb128> slangasek, seems you forgot to bzr add that patch to the vcs?
<slangasek> oh what
<seb128> slangasek, I'm fixing it
<slangasek> seb128: no, I've got it here
<slangasek> bzr add debian && bzr push, already done
<seb128> slangasek, hum, bzr pull didn't pull it for me?!
<slangasek> no, I *just* pushed it
<seb128> oh ok
<seb128> slangasek, thanks
<slangasek> sure
<slangasek> and sorry
<seb128> no worry
<slangasek> note that if you guys were using the UDD branch, this wouldn't have happened ;)
<seb128> slangasek, I'm doing a test build for another issue, just ran into it
<slangasek> (since I did a UDD merge first and then copied over to the ~ubuntu-desktop branch ;)
<seb128> slangasek, right, we would just have to deal with 5x issues with outdated import, quilt problems and other issues
<slangasek> ah, trollfail
 * slangasek crawls back into his cave
<stgraber> ;)
<seb128> slangasek, I'm happy to trade that sort of issue to not use UDD any day ;-)
<seb128> lol
<seb128> rather
<seb128> :-(
<seb128> using UDD would be great, it would mean it's working decently enough
<mhall119> james_w: are you happy with that blog?
<mhall119> stgraber: have you had a chance to look at it?
<james_w> mhall119, looks ok, though I haven't tested obviously
<mhall119> sure, I didn't expect you too, just wanted to make sure there aren't any glaring errors in the process
<mhall119> the end result is a new file in debian/patches/, a new line in debian/patches/series, and a new entry in debian/changelog
<mhall119> no changes being made to the source itself
<stgraber> mhall119: haven't yet, busy pushing some changes to wubi, will have a look in a minute (pretty much done pushing all I have)
<mhall119> stgraber: thanks
<stgraber> mhall119: you seem to be missing a "mkdir debian/patches"?
<slangasek> mkdir -p debian/patches, so it works whether or not the directory is already there? :)
<mhall119> I guess I shouldn't assume they have a debian/patches in the branch, huh
<stgraber> though just creaating debian/patches will only work with 3.0 (quilt) packages, for older packaging you'd need to create it + add a build-dep on quilt and add to debian/rules
<mhall119> stgraber: how bad would it be if somebody submits a patch file to an older package without that dependency?
<stgraber> if whoever doesn't review carefully, the package will build but the patch won't be applied
<stgraber> *if whoever does the review doesn't look carefully
<broder> does it actually make sense for people who don't have a packaging background to be rewriting their patches? there are still lots of things that could go wrong - .pc conflicts, packages using dpatch (god forbid and not really that likely)
<broder> and most importantly this doesn't address the desktop team's weird separate branches
<broder> (i think i may have argued in the past that we needed to be telling people how to do this, and if so i apologize  because i think i was wrong to do so)
<mhall119> stgraber: how would somebody tell if it's an old or new package?
<stgraber> mhall119: debian/source/format
<stgraber> mhall119: if it's not "3.0 (quilt)" it won't work with your instructions
<jalcine> Anyone know where I can find doku?
<smoser> @pilot-out
<udevbot> Error: "pilot-out" is not a valid command.
<smoser> @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:
<mhall119> stgraber: do you think quilt 3 will be a minority of majority of packages?
<broder> mhall119: zack keeps some stats on adoption in debian: http://upsilon.cc/~zack/stuff/dpkg-v3/ - looks like about 60% of packages in the debian archive are 3.0 (quilt)
<mhall119> better odds than Vegas
<mhall119> I'll just have them check their debian/source/format before following along
<mhall119> what should I tell people who's packages aren't using quilt 3?
<ScottK> 3.0 (quilt) just makes my head hurt.
<ScottK> mhall119: Nothing.  It's optional.
<stgraber> mhall119: http://raphaelhertzog.com/files/2011/12/formats-patches.png
<broder> mhall119: anyway, i'm still trying to figure out whether it's actually important that your contributors rephrase their patches with quilt and a changelog, or whether there are other problems with the quicklists and keywords rounds that we should be focusing on instead
<broder> i tend to argue that we should be willing to take patches that aren't quiltified as long as everything else is in order, and there's enough information for a contributor to fill in the changelog/dep-3 info
<mhall119> broder: it won't hurt if I teach people to make quilt patches when their source package will use it though, will it?
<broder> sure, it'd certainly make me happier if i was sponsoring them
<broder> but your current instructions make me less happy because the resulting commit doesn't have the patch applied with the .pc changes in the branch
<broder> because i've had bad luck trying to merge branches that don't apply patches
<mhall119> broder: so the patches *should* be applied?
<mhall119> if so, I can just remove the step that reverts that
<broder> this is sort of a sticky point in the udd/3.0 (quilt) processes
<broder> but right now the branches track patches applied
<broder> but they should be applied by quilt, which generates a .pc directory with a bunch of metadata
<broder> and that *also* needs to be in the commit
<broder> so what i would want to see would be (a) unapply the patches (b) run quilt push -a (c) bzr add everything (including the .pc file)
<mhall119> broder: unapply all applied patches, then apply them all?
<stgraber> mhall119: what I gave you yesterday actually generated a .pc with the patch applied
<broder> unapply the patches that the contributor made, because those would be the ones not currently "owned" by quilt
<mhall119> broder: and then quilt push <new patch>?
<broder> yeah, or just quilt push -a
<mhall119> ok, that's easy enough to add
<slangasek> tjaalton: fwiw, I'm still meditating on this latest plymouth change; although I worked with William at the Ubuntu Global Jam over the weekend to prepare this change, I'm a little concerned about the possibility that a raw chvt here could racily break desktop systems
<slangasek> tjaalton: by having the chvt called underneath lightdm
<ScottK> broder: This would be so much easier if 3.0 (quilt) didn't apply patches by default.
<ScottK> It would even make sense to me then.
<broder> ScottK: i go back and forth on which i prefer. there are some compelling pros to applying patches when you unpack, but the bad interaction with any sort of vcs is definitely unfortunate
<ScottK> Independent of VCS issues, applying patches on unpack seems fundamentlaly wrong to me.
<ScottK> It's like a layer violation between the upstream and distro layers of the package.
<broder> but it also helps reduce confusion about what the package is going to build for people who walk up to it without packaging background
<mhall119> broder: added quilt push -a instructions to http://people.ubuntu.com/~mhall119/blog/patching.html
<mhall119> in step 3
<broder> yeah, looks good. you may also need to bzr add .pc to pick up the extra crap files there
<ScottK> IME nothing regarding quilt avoids confusion for people who are new to it.
<broder> hmm, compelling point
<mhall119> broder: I have a bunch of .pc/*.patch/.timestamp files now that bzr isn't aware of
<mhall119> should all of those be added?
<broder> mhall119: yep
<broder> otherwise you're only adding half of quilt's state
<mhall119> why do I have these files for patches that were previously there though?
<jelmer> hi mhall119
<mhall119> hey jelmer
<jelmer> mhall119: did you still need feedback on http://people.ubuntu.com/~mhall119/blog/patching.html ?
<jelmer> mhall119: ".dekstop" seems to be consistently misspelled, is that intentional ? :)
<mhall119> jelmer: yes please
<mhall119> doh! no
<jelmer> mhall119: Cool, I'll have a look now.. might be an hour or as my battery is about to die
<mhall119> jelmer: ok, I wasn't planning on having it post until tomorrow morning anywa
<broder> mhall119: sorry, irc flaked. the .pc files are how quilt tracks which patches have been applied
<broder> if you apply patches but don't include the .pc files that quilt creates, it's worse than not applying the patches at all
<mhall119> broder: in that case, I think the geany branch is a mess
<broder> mhall119: no, because the patch isn't applied
<broder> from my perspective as a sponsor of a udd changes, the best possible world is patches applied with .pc files, then new patch was not applied
<broder> patch applied to the osurce tree but without the .pc files is the worst possible setup
<jelmer> mhall119: it's a bit confusing that you're mixing both the upstream change and the packaging change in the same branch
<mhall119> broder: on a clean bzr branch of ubuntu:geany
<mhall119> quilt top says that all patches are applied
<mhall119> but I don't see any of those .timestamp files in .pc/
<jelmer> mhall119: I can understand why, but it also makes the use of bzr diff and dep3-patch slightly awkward
<jelmer> I wonder if we need some better tools for this particular case
<broder> mhall119: grabbing the branch and looking
<mhall119> jelmer: I was originally leaving the source the same as upstream, but was told that I should apply the patch before committing
<jelmer> (or pehrpas just need to improve dep3-patch to handle this case better)
<broder> jelmer: since udd tracks 3.0 (quilt) branches with patches applied, you want to apply your new patch as well
<broder> otherwise you have a branch with patches partially applied
 * mhall119 is so confused right now
<jelmer> broder: that does make sense, but I think the use of dep3-patch for that case is a bit awkward at the moment
<broder> mhall119: oh, ugh. i bet this is caused by changes in quilt
<jelmer> mhall119: sorry :-?
<jelmer> I mean :-/
<broder> mhall119: if you pop all the patches then push them back on, you get .timestamp files
<mhall119> broder: yes, that appears to be what's happening
<broder> (also .pc/.quilt_patches and .pc/.quilt_series)
<broder> that sucks
<mhall119> so would it be okay for a submission to suddenly add these .timestamp files?
<jelmer> wait.. changes in the quilt format?
<broder> jelmer: bzr branch ubuntu:geany && cd geany && quilt pop -a && quilt push -a && bzr status
<broder> http://paste.ubuntu.com/873736/
<broder> the udd importer would be running on lucid, right? so there's plenty of room for changes to quilt
<mhall119> ok, I'm going to leave this post unscheduled for now, and take my son to karate, I'll be back later and see what you guys have decided on ;)
<broder> mhall119: for the record, i no longer have any idea what the best option is :(
<mhall119> broder: welcome to the club
<jelmer> broder: I think that's another argument for not actually storing the applied quilt patches in the udd branches
<jelmer> broder: but rather have them applied at checkout time by bzr
<broder> jelmer: that would require us to throw away all of the udd history we have and restart from scratch, right? is that even an option?
<jelmer> broder: it would be possible to not apply quilt patches for newly imported versions I guess
<jelmer> I'm not sur, needs some more thought I guess
<jelmer> *sure
<seb128> slangasek, hey
<seb128> slangasek, I just saw your comment on that lightdm uninstall bug
<seb128> slangasek, I was just wondering, what's the standard thing to do for people trying to uninstall a service while it's running?
<slangasek> seb128: the service should certainly be stopped
<seb128> slangasek, I think we still have a bug about one of the maintainer script trying to delete to lightdm user on uninstall which fails if you uninstall it from your user session while lightdm is still running
<slangasek> and then the package removal should continue
<seb128> slangasek, that would log all users out with a dm...
<seb128> isn't that bad taste?
<slangasek> well, I suppose if they're running *under* the dm, you could bail
<slangasek> but in this case, I know it was being uninstalled from the commandline
<slangasek> and it still failed :)
<seb128> "bail" like break the script?
<seb128> slangasek, right, it just made me think about the other case
<seb128> or "bail" like success but fail to clean the lightdm user behind?
<slangasek> "bail" like break the script
<seb128> ok
<seb128> so those bugs a "Invalid" then
<seb128> i.e "don't do that, don't try to purge a dm you are running and logged with in a session"
 * slangasek nods
<seb128> slangasek, thanks
<slangasek> sure :)
<seb128> it happens frequently enough that the bug has half a dozen dups
#ubuntu-devel 2012-03-08
<cjohnston> m_3: ping
<mhall119> broder: jelmer: I'm back, did you guys come to a consensus?
<infinity> smoser: Can you do me a favour and grab the patch from my latest bacula upload and forward that upstream instead of the one you gave them previously?
<infinity> smoser: Their bug tracker seems to require an account, and I can't be bothered, but I assume you have one. :P
<infinity> smoser: Also (relating to bacula against), does the console client need curses?  I saw some "curses.h: No such file" zip past in the build log, though this isn't new, old logs have that too.
<infinity> smoser: If that's required, I'd assume it's missing a build-dep.  But I dunno.  Maybe it's fine without.
<infinity> smoser: Oh, I see.  I think this is just a maintainer oops, based on the fact that readline-dev used to depend on curses-dev.  I'll do a test-build with the fixed build-dep and upload again.
<tjaalton> slangasek: well, it shouldn't run chvt if a dm is installed, as i see it
<tjaalton> slangasek: but yeah, if you know the issue exists then that's enough for me :)
<infinity> smoser: Oh, haha.  Even better.  The curses thing is upstream brain damage.  We turn off conio (their readline substitute) and turn on readline, but if conio's tests (which need curses) fail, it doesn't enable either.
<infinity> smoser: So, having curses.h makes the readline support work, despite not actually needing it for the build.  Smart.
<pitti> good morning
<pitti> roaksoax: the recommended way is to not set a password at all
<pitti> roaksoax: and use ident authentication -- i. e. create a system user for that service, and a db user of the same name
<pitti> roaksoax: static passwords do not make sense
<pitti> roaksoax: so if it needs to be a custom one, you need to ask a debconf question and then pg_createuser
<jono> hey folks
<jono> does anyone know who looks after Twisted in Ubuntu?
<jono> I found a pretty ugly bug - https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/949685
<ubottu> Launchpad bug 949685 in twisted (Ubuntu) "When running processes a process regularly gets stuck and does not complete" [Undecided,New]
<cody-somerville> jono, Is the problem on precise?
<jono> cody-somerville, I can confirm it on Precise
<jono> cody-somerville, I am not sure if the issue is on Oneiric
<jono> there is a script to test attached to the bug
<cody-somerville> Hmm... dobey made an upload to twisted on 2012-02-16 that might be related.
<jono> cody-somerville, I have noticed this problem for a while
<jono> I presumed it was a bug in my code
<jono> until I dug into it last night
<pitti> jdstrand: seems we have a huge boot speed regression since March 06 -- http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-02/2012-03-07_13-17-19/bootchart.png
<pitti> jdstrand: seems the apparmor_parser now needs some 40 seconds
<dholbach> good morning
<seb128> slangasek, hey
<seb128> slangasek, I got over 30 bug emails about that gconf upgrade issue on yours this night
<seb128> slangasek, is there any chance you raise up it in your todolist?
<seb128> on yours->of yours
<dupondje> pitti: thanks for the cryptsetup follow up :) Good to have new version in Precise now :D
<pitti> dupondje: no worries, thanks for the merge and testing!
<apw> anyone else seeing a new 'Progress' popup when pushing from the command line?  and is anyone else seeing it get stuck on the screen after the command has finished
<jodh> apw: yup
 * apw is perplexed enough getting on screen bling for a command line incantation
<apw> jodh, know if there is a bug, or if he should be filing ...
<jodh> apw: I was about to check. looks like a rogue bzr-notify process not being killed off.
<apw> jodh, so perhaps i can deinstall it ... hmm
 * apw asks on #bzr
<jodh> apw: bug 949798
<ubottu> Launchpad bug 949798 in Bazaar "bzr-notify leaves a rogue status throbber on screen after bzr push completes" [Undecided,New] https://launchpad.net/bugs/949798
<apw> jodh, thanks, doesn't seem to be known on #bzr either, though they also sound like they'd like it too :/
<xdatap1> Hello guys. I just noticed that libmysqlclient18 libqt4-sql-mysql mysql-common are seeded into the CD but no package seeded look like to needed them. Is that correct? Do should I open a bug?
<dholbach> pitti, ^ do you know anything about xdatap1's question?
<noodles785> Hi people, does anyone know if there are reasons why the nodejs package on precise is so old? Is something holding back updating it, or is it just gettiing someone to do it?
<noodles785> https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/892034
<ubottu> Launchpad bug 892034 in nodejs (Ubuntu) "Update Node.js to the latest version (v0.6.1)" [Undecided,Confirmed]
<noodles785> IIt seems like something that could be quite important for an LTS resease (although it may be too late).
<pitti> xdatap1, dholbach: it's a dependency chain; unity-2d needs qt needs libqt4-sql recommends libqt4-sql-mysql depends libmysqlclient18 depends mysql-common
<xdatap1> pitti, it's a dependency of a recommendation then. Thank you
<pitti> we could seed libqt4-sql-sqlite and thus satisfy the recommends
<pitti> this might downsize the CD a bit even
<pitti> Size: 946770
<pitti> urgh, indeed!
<pitti> xdatap1: thanks for pointing out, I'll try this
<xdatap1> pitti, you're welcome
<pitti> xdatap1: FYI, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/desktop.depends is quite helpful for this
<xdatap1> pitti, WOW! awesome! this is super useful!
<tseliot> pitti: can you accept nvidia-settings-updates in oneiric-proposed for testing, please? (since nvidia-current-updates was accepted)
<tseliot> pitti: same SRU (bug #919992)
<ubottu> Launchpad bug 919992 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "current-updates is not up to date" [Medium,Fix committed] https://launchpad.net/bugs/919992
<pitti> tseliot: yep, will do an SRU round soon
<tseliot> pitti: thanks a lot!
<geser> noodles785: as jamespage merged nodejs the last time, try asking him if he intends to merge it for precise or not (I don't know if nodejs would get the needed FFe)
<noodles785> geser: Thanks. And yes, it might be too late, but perhaps worth checking. jamespage ^^?
<jamespage> geser, noodles785: the later version of nodejs (and libev + libv8) only landed in Debian unstable a couple of weeks ago
<jamespage> the Debian maintainer did let me know but I've not had the time to take a look at it....
<jamespage> it is relatively self contained (just the three packages) but would need an FFe
<noodles785> jamespage: cool, good to know. Thanks for the info!
<jamespage> noodles785, its on my list but right at the bottom so probably won't get done for precise so if you want to pick it up please feel free
<noodles785> jamespage: I'm no packager, but I can try :) It's not for me personally (it's pretty easy to install), I just thought it would benefit Ubuntu server.
<zyga-xchat> anyone interested in repeatable X crash on fglrx?
<directhex> zyga, not a lot anyone can do with closed-source crashes
<zyga> directhex, yeah but I'm sure we can do better than that, raise a ticket with AMD or something
<seb128> zyga, is that on video playing?
<zyga> seb128, yes but it also happens when totem runs visualization for audio
<seb128> zyga, known issue
<zyga> seb128, ah, I've reported it, should I find the master and dupe?
<seb128> zyga, bug #921384
<ubottu> Launchpad bug 921384 in fglrx-installer (Ubuntu Precise) "[MASTER] Xorg crashes when trying to play a video with XV under xserver 1.11 - xs111LookupPrivate" [High,In progress] https://launchpad.net/bugs/921384
<zyga> seb128, thanks
<seb128> yw
<zyga> seb128, done
<mhall119> pitti: ping
<pitti> mhall119: hello
<mhall119> hiya, is https://bugs.launchpad.net/ubuntu/+bug/942782 waiting on something?
<ubottu> Launchpad bug 942782 in Ubuntu "FFE: Add unity-quickly-lens-template package to Universe" [Wishlist,Fix committed]
<pitti> mhall119: yes, on an archive admin processing it through source NEW
<mhall119> ok, so nothing to do but be patient?
<pitti> or prod the archive admin of the day
<pitti> mhall119: https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
<mhall119> thanks
<mhall119> StevenK: ping
<pitti> ogra_: can you start gnome-language-selector on current arm?
<pitti> ogra_: I wonder if anyone can reproduce bug 936045
<ubottu> Launchpad bug 936045 in language-selector (Ubuntu) "[armhf] gnome-language-selector crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/936045
<ogra_> ogra@horus:~$ gnome-language-selector
<ogra_> Segmentation fault
<ogra_> though this system is armel and outdated
<ogra_> i have another armhf that was installed with B1, gimme a sec
<pitti> armel, armhf, shoudln't make much difference
<pitti> ogra_: ah, thanks
<ogra_> pitti, works fine with the newer armhf install
<ogra_> in fact i had used it right after install
<ogra_> i get a unicode warning in the terminal though
<pitti> ogra_: I get that as well, that's harmless
<nigelb> mhall119: FWIW StevenK is probably asleep. At least he should be.
<TLE> pitti: Hallo, could I persuade you to copy the last batch of oneiric language packs over to the -proposed archive
<pitti> TLE: I'm just running that :)
<pitti> TLE: it took a while to get the builds sorted out as they starved
<pitti> one build failed, I need to hack around that a bit
<TLE> awesome, you were already on it, it must be my part betazoid heritage
<pitti> TLE: well, it really was your mail, but close enough :)
<TLE> :)
<TLE> let me know when it's all ready
<pitti> I will
<mhall119> nigelb: thanks, I'll try him tonight then
<mhall119> though...it'll be Friday for hiim, so he wont be the archive admin of the day anymore
<jalcine> mhall119: fantastic post about packaging patching :)
<mhall119> jalcine: thanks, though there never was a conclusion last night about whether to apply patches before committing
<mhall119> I'm hoping this is still okay
<pitti> TLE: copying done now, also mailed back
<TLE> pitti: thanks
<ogra_> does anyone know why i cant open .manifest files inline in the browser anymore ? its pretty annoying to have to download and start gedit every time ...
<ogra_> did the mime type change ? the browser or the .htaccess on the server ?
<mhall119> jdstrand: ping
<smoser> infinity, thank you for your bacula fixes.
<smoser> infinity, i forwarded patch to http://bugs.bacula.org/view.php?id=1829
<infinity> smoser: I can't read that URL anyway, but thanks. ;)
<smoser> infinity, wow.
<smoser> that is annoying.
<infinity> smoser: Might be worth mentioning to them that the exact same mysql_config fix can (and should) be applied about 200 lines up in the dbi-mysql section (which we don't use, so I didn't bother).
<smoser> i'll mention in bug.
<infinity> Danke.
<smoser> fwiw, i am not really a bacula user :)
<smoser> i just pulled a bug at one point, and it was an unending task
<infinity> Hah.
<smoser> you use it?
<infinity> Does this mean I've inherited the TILM mantle?
<infinity> No, I don't use it.
<infinity> GrueMaster complained to me about it being broken, so I fixed it.
<smoser> well i pass the baton to you then
<smoser> :)
<infinity> Cause I was bored.
<smoser> but, its in a *much* better state now than it was in oneiric.
<smoser> (ie, it can install and run!)
<infinity> You're setting a pretty high bar there.
<jdstrand> mhall119: hi
<mhall119> jdstrand: hey, I know you're not archive admin of the day, but could you look at https://bugs.launchpad.net/ubuntu/+bug/942782 if you have time?
<ubottu> Launchpad bug 942782 in Ubuntu "FFE: Add unity-quickly-lens-template package to Universe" [Wishlist,Fix committed]
<dupondje> a missing depend, reason for SRU ?
<jdstrand> mhall119: ok
<mhall119> thanks jdstrand
<dholbach> jelmer, are we going to sync the new bzr-builddeb from Debian?
<jelmer> dholbach: yes, please (I just synced it); 2.8.3 is a bug-fix-only-upload
<dholbach> ah, ok, so you just synced it - great :)
<dholbach> awesome :)
<jelmer> dholbach: smoser just asked about it in #bzr
<dholbach> great, I saw it on the rcbugs list :)
 * jelmer wonders if he's whatever is causing everybody to talk about it in the last 5 minutes..
<smoser> jelmer, well, i just woke up, came into work, and that bug was on my screen
<smoser> since the last thing i did before leaving was have 'bzr  merge' crash on me
<smoser> and i had hit the submit-bug dialog
<smoser> so i asked.
<eitch> locking the screen doesn't work on my precise installation with all updates installed. Can someone tell me for which package i should file a bug report? Or is this already known and no bug report is required?
<mdeslaur> eitch: when is it not locking? ie: how are you trying to get it to lock?
<eitch> both ways i know: ctrl+alt+l and the action from the system/user menu
<mdeslaur> eitch: file it against gnome-screensaver
<eitch> i thought maybe it was a configuration bug from an earlier version as i have had precise installed for about 1.5 months now, but even then it didn't work
<eitch> ok
<eitch> mdeslaur, thanks
<mhall119> jdstrand: quickly-unity-lens-template doesn't have a separate source tarball
<mhall119> so what should I put in debian/watch?
<jdstrand> mhall119: I mentioned it in the email. Ideally, you would have a tarball rather than a bzr snapshot. you need to provide instructions on how to generate the tarball. you can do that in watch or README.source. you can also write a get-orig-source for debian/rules
<jdstrand> mhall119: (if watch file, it needs to be comments only
<m_3> cjohnston: pong
<roaksoax> pitti: cool, thanks for the recommendation.
<dholbach> superm1, should bug 931626 be resolved by a sync? (will probably need release team ack)
<ubottu> Launchpad bug 931626 in Ubuntu "[needs-packaging] needs-packaging: ledmon" [Wishlist,Fix committed] https://launchpad.net/bugs/931626
<pitti> tseliot: I didn't see nvidia bits in the oneiric-proposed unapproved queue?
<jodh> Please could someone bump the 2 builds here: https://code.launchpad.net/~jamesodhunt/+recipe/upstart-daily-build-test ?
<cjohnston> m_3: whats the status of the charm
<mhall119> jdstrand: I've added a watch file to the branch
<mhall119> it looks for a tar.gz download on Launchpad, which I've also uploaded
<jdstrand> mhall119: perfect! thanks :)
 * jdstrand reviews
<m_3> cjohnston: hey.. summit's still in progress, still on schedule to hand it off tomorrow
<cjohnston> cool
<cjohnston> jcastro: ^
<m_3> cjohnston: only problem so far has been the charm trying to branch from bzr+ssh: repos without creating a key first!
<cjohnston> ic
<mhall119> m_3: for the pullapps?
<mhall119> can't we pull them over http or something?
<cjwatson> jodh: done
<cjwatson> why not use lp: and let bzr DTRT
<m_3> mhall119: yes, but I'd have to push those changes back to summit and/or rewrite them on the fly in the charm
<jibel> pitti, FYI I added a post-upgrade  test that checks for obsolete config files.
 * m_3 finding repos
<jibel> pitti, It's currently enabled only for LTS to LTS. That's what explain lucid desktop and server became unstable.
<mhall119> m_3: tell cjohnston what changes need to be made, I'm okay with making it always use http
<cjwatson> m_3: if you use lp: instead it should use the equivalent of bzr+ssh: if it can and otherwise http:, as I understand it
<m_3> mhall119: thanks
<mhall119> cjwatson: I tried using lp:, but since it's calling bzrlib, not bzr cli, it didn't like it
<cjwatson> oh, well, you can do directory lookups in bzrlib too although I don't happen to know how
<mhall119> yeah, I was probably just not using the write API calls
<mhall119> s/write/right/
<blackbug> i am trying to make some changes in a application packaged with ubuntu. but even after compiling and building my changes, they are not reflected in the executable. I even tried just to print a message the moment application is initialised, but nothing is displayed. is there any special way to test any application? i am doing this first time.
<cjwatson> when I work on packages and want to test the program I just built I generally just run it from the build tree rather than bothering to install it
<cjwatson> unless there's some reason I need other associated files in place rather than just the executable
<cjwatson> is that what you're trying to do?
<jodh> cjwatson: thanks!
<blackbug> yes i am running the exe from the build tree, i am not much familiar with gtk code, simple printf statements doesnt display message on console on a gtk application? with wxwidgets i can display messages on console using printf or cout
<cjwatson> blackbug: silly question, exactly what command line are you using to run it from the build tree?
<cjwatson> gtk doesn't fiddle with standard output; printf should work
<tseliot> pitti: oh, my bad, please try again now
<blackbug> i am making changes in necessary .c & .h file, compiling and building with make and make install
<blackbug> and then using the executable
<cjwatson> blackbug: exactly what command line are you using to run the executable?  please copy and paste
<blackbug> sudo make;sudo make install; ./leafpad
<pitti> jibel: thanks
<cjwatson> you don't need make install if you're running from the current directory; and you don't need sudo in front of make, only make install
<cjwatson> I would suggest as a test putting a printf right at the top of main() and seeing what that does
<cjwatson> did make print any errors?
<blackbug> actually i was trying it from build tree and the dir location wic i used with configure --prefix option. i had to use sudo bcz there were some permission issues with my user and compilation was interuppted while creating files.
<cjwatson> 'sudo make clean' and then you shouldn't need sudo any more.
<cjwatson> I don't understand what you mean about --prefix; the prefix shouldn't be involved when you're just running 'make'
<blackbug> no i used prefix initially with ./configure file.
<cjwatson> sure, but you said you were trying it "from ... the dir location" [--prefix]
<cjwatson> that doesn't make sense :)
<ogra_> cjwatson, sudo might be needed depending *where* exactly the build tree is unpacked :)
<blackbug> i just cleaned everything and tried again. now i can see the messages
<cjwatson> this would be easier with full transcripts on paste.ubuntu.com rather than summarised versions
<cjwatson> ok
<ogra_> (i.e. in /usr/src ...)
<cjwatson> ogra_: well, yeah, but Don't Do That Then ...
<ogra_> indeed
<cjwatson> /usr/src <- abomination
<blackbug> but in my user home directory i should have permissions for it..still it was giving errors without sudo
<ogra_> did you run apt-get source with sudo before ?
<cjwatson> if you built it as root once then there might have been root-owned files
<cjwatson> or, indeed, if you incorrectly used sudo apt-get source
<blackbug> yes i did, you right cjwatson it looks the same :)
<tseliot> pitti: thanks
<ev> pitti: might I trouble you to cherry pick r2226 from lp:~ev/apport/whoopsie
<blackbug> thanks for suggestions cjwatson and ogra_
<pitti> ev: ah, did you get the tests fixed?
<ev> tests fixed?
<pitti> ev: https://code.launchpad.net/~ev/apport/whoopsie/+merge/96416
<pitti> ev: without my "if 'DistroRelease' in self.report:" fix I get KeyErrors
<ev> ah, odd that didn't come through to my inbox
<ev> I'll have a look
<pitti> ev: ah, 2226 looks fine, applying
<ev> cheers
<kees> hrm, I think the fix for 890434 needs to be reverted. See 949732.
<pitti> ev: should I link that to any bug?
<ev> pitti: I haven't filed one, but can if you think that's what it needs to get in the archive
<pitti> ev: no, that's fine
<pitti> just wondering about existing bugs
<ev> sure
<pitti> ev: cherry-picked, trunk r2225
<ev> cheers
<blackbug> one more question, how in ubuntu the code flow is returned back. for eg say i have entered invalid data, pathname, filename. shall i terminate application with proper message or should i ask for the input again. what is usual pattern with ubuntu apps.
<cjwatson> blackbug: if it's command-line parsing it should terminate with an error; if it's graphical, e.g. text boxes, display error and ask again
<jdstrand> mhall119: quickly-lens-templates never showed up in new
<blackbug> cjwatson: thanks for the information)
<mhall119> jdstrand: I pushed to the branch, I don't think I can uploaded it
<superm1> dholbach: already been synced, just forgot to close the bug
<dholbach> ah cool
<jdstrand> mhall119: can you prepare a new source package incorporating the fix and have your sponsor reupload it? (if I upload it, I am not allowed to deNEW it)
<dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/precise/twisted/fix-935756/+merge/96617 ? jono and the world will love you if you do :)
<mhall119> didrocks: will you be around for a bit to upload a new source package for my quickly template?
<didrocks> mhall119: I'm leaving in a hour, but happy to be help you again
<didrocks> or drop me an email if not
<didrocks> do you know what the rejection was about?
<mhall119> didrocks: initially for lack of a debian/watch file
<mhall119> but also jdstrand would like just the debian/ files on their own
<didrocks> jdstrand: you do reject on that? :) even when upstream won't cut "outside ubuntu" tarballs?
<didrocks> hum, which ones, just being curious :)
<mhall119> didrocks: jdstrand: https://code.launchpad.net/~mhall119/unity-quickly-templates/precise-package
<jdstrand> didrocks: I don't care so much about debian/ being separate. I do care about being able to verify the source integrity of the package. there wasn't an upstream tarball with a corresponding watch file. but there also wasn't any documentation in the packaging on how to create the tarball.
<jdstrand> didrocks: so I asked to either do upstream tarball + watch, use get-orig-source or document how the tarball was generated
<mhall119> jdstrand: you now have either the combined branch or the stand-alone package branch, both have watch files to pull the source tarball
<jdstrand> mhall119: if I upload I can't deNEW for you (this is archive admin policy). please have someone upload on your behalf and I can review then
<mhall119> didrocks: ^^ please upload for jdstrand
<didrocks> jdstrand: ok, we do have quite some packages that are using a split bzr mode without upstream tarball
<mhall119> didrocks: lp:unity-quickly-templates/precise-package is the ./debian/ only branch
<jdstrand> didrocks: I realize that, and one by one as they come through NEW I ask for this
<didrocks> jdstrand: ok, good to know, I never made this a requirement for packages that were ubuntuish
<jdstrand> my long term goal is to be able to automate the source integrity of the archive
<didrocks> jdstrand: do you have anything to do withâ¦ security? j/k ;)
<jdstrand> heh
<stgraber> pitti: ping
 * mhall119 has been causing so much trouble in this channel lately
<mhall119> I apologize
<jdstrand> mhall119: no trouble on my end
<mhall119> yet
<didrocks> mhall119: you can have shorter url in debian/watch btw
<mhall119> yeah probably
<mhall119> if there's one thing I've discovered about packaging, it's that there's *always* a better way to do it
<didrocks> version=3
<didrocks> https://launchpad.net/unity/+download .*/unity-([0-9.]+)\.tar\.bz2
<didrocks> mhall119: for instance ^
<didrocks> don't need to put again the full URL
<mhall119> didrocks: thanks, I'll remember that next time I write one, that is a lot easier
<didrocks> mhall119: you can maybe stage the change in bzr so that next upload can get it
<mhall119> ok
<didrocks> jdstrand: uploaded
<mhall119> thanks didrocks
<didrocks> mhall119: yw ;)
<jdstrand> thanks, will deNEW now
<mhall119> thanks jdstrand
<mhall119> bdrung: pinging you again about devscripts/edit-patch
<zyga> hi, I've noticed that rhythmbox cannot play more than a few seconds of most of my media library
<zyga> while banshee/totem have no issues
<zyga> has anyone observed this?
<zyga> ah, just noticed it's a duplicate from launchpad
<zyga> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/815837
<ubottu> Launchpad bug 815837 in rhythmbox (Ubuntu) "rhythmbox-metadata crashed with SIGSEGV in _start()" [High,Confirmed]
<zyga> https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/949886
<ubottu> Launchpad bug 815837 in rhythmbox (Ubuntu) "duplicate for #949886 rhythmbox-metadata crashed with SIGSEGV in _start()" [High,Confirmed]
<kk_> I am trying to fix an issue, i have done sanity testing it's almost fine, but how to make sure it adher's ubuntu coding guidelines. who will review it?
<cjwatson> https://wiki.ubuntu.com/SponsorshipProcess
<blackbug> hi again cjwatson, can you answer my question it was from different id (kk_) before..  I am trying to fix an issue, i have done sanity testing it's almost fine, but how to make sure it adher's ubuntu coding guidelines. who will review it?
<cjwatson> https://wiki.ubuntu.com/SponsorshipProcess
<cjwatson> it's not possible to give you a specific name of somebody who will review it in advance
<cjwatson> in many cases it ought to go to the upstream developers
<blackbug> ah ok, thanks)
<shnatsel> Hello! I suspect that one unit test in Ubiquity goes mad and doesn't let me build a package
<cjwatson> as in the people who actually wrote the software in question; Ubuntu is just a distributor, although we do often modify packages
<cjwatson> shnatsel: oh?
<shnatsel> I've replaced two pics with pics of smaller size, and now it fails in "test_pages_fit_on_a_netbook"
<shnatsel> cjwatson: bug 950125
<ubottu> Launchpad bug 950125 in ubiquity (Ubuntu) "[ftbfs] Fails to build due to test failing" [Undecided,New] https://launchpad.net/bugs/950125
<cjwatson> that test is a bit delicate
<cjwatson> ftbfs isn't accurate though, that means unmodified builds in the archive ...
<shnatsel> cjwatson: it builds fine locally, but not in PPA
<cjwatson> I think it may be somewhat theming-dependent
<blackbug> hmm ok, the thing is intially one is ot aware about the coding guidelines and practices followed, and it can go smooth only with some tips or suggestions after reviewing code. anyway thanks for the link cjwatson.
<cjwatson> blackbug: there's no single such thing as Ubuntu coding guidelines though, it depends on the package you're working on
<shnatsel> cjwatson: thanks! , won't misuse again
<cjwatson> blackbug: you should follow the coding style of the package you're working on
<shnatsel> s/ ,/my bad,/
<cjwatson> shnatsel: have you tried it in a local sbuild?
<shnatsel> cjwatson: no, because I don't know what's an sbuild
<cjwatson> apt-cache show
<cjwatson> or pbuilder
<shnatsel> cjwatson: thanks, will do!
<cjwatson> the important bit is that it's a clean chroot without any bits of your normal user's desktop environment lying around in it
<cjwatson> but, if it's really getting in your way, you can of course just bump the numbers there or disable the test; you may not care about what it's testing for
<shnatsel> that's going to land in elementary OS, so I do care
<shnatsel> brb relogin to make sbuild work
<cjwatson> shnatsel: ah, apparently broke in 2.9.25 (#ubuntu-installer)
<cjwatson> so it's not about your changes, something changed under us
<shnatsel> cjwatson: is this going to be fixed for Precise or it's a low-priority item and I should just disable testing if I want it to work?
<cjwatson> it will have to be fixed for precise since it's blocking us
<cjwatson> so the ftbfs tag was accurate after all ;)
<shnatsel> cjwatson: ok, is there a bug report to which I should mark mine as duplicate?
<cjwatson> no
<stgraber> shnatsel: yours just became the main bug report ;)
<shnatsel> stgraber: good to know :)
<stgraber> shnatsel: I'm currently looking into that bug as it caused by upload to fail even though I ran the test before uploading...
<shnatsel> stgraber: thanks!
<cjwatson> blackbug: please don't do that, DCC is useless
<cjwatson> (it can't traverse NAT, at least not in my setup, and I've no intention of putting the work in to figure out how to fix that)
<stgraber> cjwatson: IPv6!
<blackbug> ok, does gnome-screenshot has any bzr branch? i couldnt find it
<cjwatson> DCC CHAT is pointless anyway, just use /query.  but in any case why ask me this kind of thing personally, I have nothing to do with gnome-screenshot
<cjwatson> stgraber: I have IPv6 but I'm willing to bet most of the people who try to DCC CHAT me don't :-)
<cjwatson> (and I rather suspect my firewall would deny it anyway ...)
<blackbug> ok, actually i was workin on 949341 which i encountered last night, but i could not find any branch registered on bzr, so was curious to know.
<stgraber> bug 949341
<ubottu> Launchpad bug 949341 in gnome-screenshot (Ubuntu) "gnome-screenshot crashes with core dump" [Undecided,Confirmed] https://launchpad.net/bugs/949341
<shnatsel> blackbug: I'll try to look up the branch for you
<yofel> cjwatson: hi, could you add konsole back to the kubuntu packageset please? It's not in there anymore for some reason
<blackbug> shnatsel: thanks)
<cjwatson> yofel: needs a manual exception - please send me mail so I have an audit trail
<stgraber> blackbug: it's usually under ~ubuntu-desktop but this package doesn't seem to have one, so the UDD branch is probably the right one "bzr branch ubuntu:gnome-screenshot"
<yofel> will do
 * micahg wonders why konsole would need an exceptions as it's explicitly seeded
<blackbug> shnatsel: doesnt seem to work "bzr branch ubuntu:gnome-screenshot"
<broder> hmm. why don't we patch debcheckout to know about udd branches?
<shnatsel> blackbug: bzr branch lp:ubuntu/gnome-screenshot then
<stgraber> blackbug: hmm, indeed, odd
<shnatsel> blackbug: that's how I do it
<blackbug> nope..doesnt work either
<cjwatson> micahg: it's in desktop-core, presumably something pulls it in more deeply
<stgraber> blackbug: the importer failed (http://package-import.ubuntu.com/status/gnome-screenshot.html#2012-02-17%2010:17:39.345154)
<shnatsel> ah, that's why some bzr branches in launchpad lag behind versions in the archive!
<stgraber> blackbug: so you probably should just go with a good old "apt-get source gnome-screenshot" (requires deb-src lines in /etc/apt/sources.list), then diff manually your changes
<micahg> cjwatson: I think that's a bug too :)
<stgraber> shnatsel: yep, not everyone pushes to the branch before uploading which causes the lag, also there are bugs causing the importer to fail for some branches
<shnatsel> stgraber: I actually planned to maintain patched versions of Ubuntu packages using those branches and LP recipes. Looks like it's a bad idea.
<shnatsel> stgraber: in fact, that ubiquity thing is one of them
<stgraber> shnatsel: yeah, for ubiquity you'd want to use lp:ubiquity instead, that's where we push the changes as they happen
<shnatsel> stgraber: that won't let me maintain older versions though... this way Precise will get Ubiquity from Q release eventually
<cjwatson> shnatsel: we tag every version we upload and you can branch off a tag
<blackbug> yes i made changes on the source code fetched from apt-get source. but how should i attached my changes with the bug?
<cjwatson> or indeed off any revision you like
<shnatsel> cjwatson: thanks, will do something like that
<stgraber> shnatsel: ubiquity bug fixed
<stgraber> shnatsel: I'm releasing 2.9.26 now
<shnatsel> stgraber: w00t! thanks a lot!
<stgraber> shnatsel: adding a build-dependency on ubuntu-artwork makes the test use the right theme and succeed
<shnatsel> stgraber: thanks for the info, that's a thing for me to patch away XD
<stgraber> shnatsel: well, it's just a build-dependency, it won't result in a runtime dependency on ubuntu-artwork, so even if you don't use ubuntu-artwork it should be safe to use as a build-dep
<stgraber> shnatsel: though I guess it'd be best to run the test with your own theme to ensure the rendering works with yours :)
<shnatsel> stgraber: yep, that's the plan :)
<broder> hmm, did the kernel stop passing its command line arguments to PID 1? upstart doesn't seem to be getting my --verbose argument
<broder> oh wait, i'm an idiot
<stgraber> broder: the kernel passes them to /sbin/init in the initramfs, which then has to passe them to /sbin/init on the filesystem
<broder> stgraber: hmm...
<broder> evan@caron:~$ cat /proc/1/cmdline | xargs -0
<broder> /sbin/init
<stgraber> broder: /usr/share/initramfs/tools/init doesn't show anything for --debug
<stgraber> broder: oh but it uses $@ so you should be getting everything indeed
<broder> right. so apparently the initramfs init isn't getting any arguments
<broder> i feel like i remember that being a distro patch...
<broder> i wonder if it should be passing $(cat /proc/cmdline) instead
<broder> or alternatively if upstart should be injecting /proc/cmdline into its argv before parsing
<infinity> broder: init shouldn't be getting cmdline completely raw, though, as it might get parsed and stripped by the initrd.  In theory.
<broder> infinity: ok, i didn't know that was a theoretical possibility. in that case i offer that /usr/share/initramfs-tools/init should be passing $(cat /proc/cmdline) to real root's /sbin/init
<infinity> Well, I was just saying that I don't think that's sane. :P
<broder> err, oh, you're complaining about spaces/quotes/etc?
<broder> was any of that ever actually handled correctly when the kernel was passing it on?
<infinity> Or just stuff that's meant for the initramfs init.  There's no need to pass that on.
<infinity> But the real question here is what't the bug/issue?
<broder> i passed --verbose on the kernel commandline expecting that to get me information from upstart as to what events were being processed
<infinity> I'm not entirely positive that /proc/1/cmdline is an accurate representation of reality.
<broder> that's possible, but upstart definitely wasn't getting the --verbose argument - the log-priority was still set at message when i managed to get to enough of a userspace to check
<infinity> Sure, but we know, for instance, that --log works.
<infinity> So, it's obviously getting arguments.
<broder> err, i should have clarified incidentally that i'm using oneiric
<broder> have not tested this on precise yet
<infinity> initramfs hasn't changes much in that time.
<infinity> Nor klibc.
<infinity> (And /proc/1/cmdline on my precise machine claims init has no arguments, which I know is patently false)
<infinity> So, I suspect it's a red herring that has more to do with all the init pivoting insanity done by run-init to keep PID 1 as PID 1.
<slangasek> I'm sure that I've used --verbose with precise and oneiric kernels and gotten the expected results from upstart
<broder> wait...wtf. it works for me now. wtf was i doing before?
<infinity> :P
<infinity> I probably don't want to know.
<infinity> And you likely don't either.
<broder> probably
<infinity> Back away from the keyboard, grab a drink, and go back to what you were debugging. ;)
<broder> :)
<infinity> I have a lunch date that I should head off to.
<cfhowlett> *oem mode: what is the sudo passwd?*  reinstalled and autologin to oem account.  can't add my users as I don't know oem's admin passwd...
<ScottK> cfhowlett: oem, IIRC.
<mgolisch> will ubuntu for android be available generaly?
<mgolisch> or is that somekind of vendor integration thing only?
<mgolisch> the idea sounds realy cool, id love to test that on my phone
<cfhowlett> mgolisch: ask #ubuntu-phone
<bdrung> mhall119: i tried https://bugs.launchpad.net/ubuntu/+source/devscripts/+bug/947180/comments/2 with your patch applied, but it failed: http://paste.ubuntu.com/875311/
<ubottu> Launchpad bug 947180 in devscripts (Ubuntu) "[edit-patch] should not unapply quilt patches" [Undecided,In progress]
<kees> mterry: did you see my notes on the bison bug?
<kees> mterry: if you don't object, I'd like to just sync bison from Debian.
<mterry> kees, yeah, I saw the comment but didn't have time to re-examine.  if that's the only delta, then I don't disagree
<kees> mterry: yeah, it was.
<kees> mterry: I couldn't find the example FTBFS so I couldn't see what else was suffering from a poor yyerror implementation
<mterry> kees, nip2 is all I can remember
<kees> mterry: yeah, the ftbfs build log vanished off LP, so I couldn't check it :(
#ubuntu-devel 2012-03-09
<psusi> was there another team besides ubuntu-archive that you need to subscribe a sync request to given the feature freeze?
<ajmitch> ubuntu-release if you need a freeze exception
<slangasek> ubuntu-archive doesn't do syncs anymore, you only need to subscribe the sponsors team (and possibly the release team if you need a freeze exception)
<psusi> ahh, just found it
<psusi> yep.. need freeze exception... critical release regression fixed
<slangasek> that sounds like a bug fix, which doesn't need a freeze exception
<slangasek> we're only in feature freeze - so the exceptions would be if you want to add a feature
<psusi> ahh... so... don't subscribe ubuntu-release?  just ubuntu-sponsors?
<slangasek> if it's a bugfix-only sync, just ubuntu-sponsors
<psusi> ahh, ok....
<ajmitch> psusi: gparted?
<psusi> ajmitch, yep
<psusi> bug #947685
<ubottu> Launchpad bug 947685 in gparted (Ubuntu) "sync gparted 0.11.0-2 from debian unstable" [Undecided,New] https://launchpad.net/bugs/947685
<ajmitch> so that's just a sync of a new debian revision, certainly doesn't look like new features there :)
<psusi> see change log, I backported an upstream commit to fix the bug and uploaded to debian first
<ajmitch> yeah I looked at the changelog on the debian PTS
<psusi> that way ubuntu doesn't need to deviate from debian again
<ajmitch> psusi: just test-building it now
<mhall119> bdrung: at which step did it fail?
<bdrung> mhall119: calling devscripts/devscripts/scripts/edit-patch.sh small-desktop-file-fix
<bdrung> mhall119: that's what edit-patch.sh prints
<mhall119> bdrung: it works when run from /usr/bin/edit-patch, but not from ~/projects/Ubuntu/devscripts/trunk/scripts/edit-patch.sh
<mhall119> not sure why that would be
<bdrung> mhall119: i found it. it's in the main function
<bdrung> if [ "$(basename $0)" = "edit-patch" ]; then
<mhall119> oh, because it's .sh in the branch
<mhall119> :q
<bdrung> hm, the question is: how to make it work even with .sh in a sane way
<mhall119> bdrung: my patch didn't create this issue though,  so can it be accepted
<mhall119> ?
<bdrung> mhall119: yes
<ajmitch> psusi: ok, done
<psusi> ajmitch, great, thanks
<mhall119> bdrung: I have a fix for you
<bdrung> mhall119: i can't wait to see it
<mhall119> bdrung: making an MP now
<bdrung> mhall119: you can just pastebinit
<mhall119> ah,  too late
<mhall119> https://code.launchpad.net/~mhall119/devscripts/allow-edit-patch-sh/+merge/96692
<bdrung> mhall119: there is no need for a MP. everything "git am" can handle would be nice. :)
<mhall119> couse, it has my previous fix in it too
<mhall119> bdrung: one second
<bdrung> mhall119: that looks nice.
<mhall119> http://paste.ubuntu.com/875425/
<mhall119> I suppose you don't need the echo "Found *-patch" lines
<bdrung> mhall119: one addition could be added. in the else case it should use fatal_error
<smoser> hey...
<smoser> so, normally, for a preseed value.
<smoser> lets say something (like mysql) takes a preseed/debconf and asks the user for a password.
<smoser> next time it is upgraded, i suspect the expected behavior is that it should not re-set that value (in the event that the user has changed it)
<mhall119> bdrung: is there a reason it didn't?
<smoser> generally, should pre-seed only be used on initial install ?
<smoser> but then if that is the case what about dplkg-reconfigure
<bdrung> mhall119: if someone renames the script, it should fail with a proper error message
<mhall119> bdrung: http://paste.ubuntu.com/875434/
<mhall119> was very tempted to make it: fatal_error "Don't call me $0"
<mhall119> bdrung: http://paste.ubuntu.com/875438/ has the whole set of fixes (excluding the quilt fixes already submitted)
<bdrung> mhall119: :D that would be a funny error message.
<bdrung> mhall119: committed. thanks for the fixes.
<mhall119> bdrung: do I need to submit these to debian too, or can you do that as well?
<bdrung> mhall119: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=84dd95288a16cd821d8fdeaae2207ac08189e0bb
<bdrung> and http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=9d3674964e33eeb7e8a7121b831627f6a84f1c38
<mhall119> that's what I figured when you said anything that git woudl accept ;)
 * mhall119 has patches in debain \0/
<bdrung> mhall119: now it's time for me to get the remaining ubuntu diffs merged into debian
<mhall119> wow, and a big head too it seems
<bdrung> mhall119: one day you might become a DD ;)
<mhall119> I'll leave that to paultag
<mhall119> thanks for your help bdrung
<bdrung> np
<slangasek> smoser: on dpkg-reconfigure, the prompts are shown to the user, with the answer defaulted to whatever value is currently in the debconf cache
<smoser> hm.. yeah, that makes sesne.
<smoser> but if they hit enter, then it sets it back.
<smoser> is that righ t?
<smoser> slangasek, i'm tyring to figure out how i should do this...
<slangasek> yes, that's the idea
<smoser> we want to preseed some data (credentials) into cloud-init
<smoser> that willi really be consumed by the installer
<smoser> but then if the user modified the cloud-init.cfg file that it wrote, what should happen on package upgraade ?
<slangasek> typically, if the .cfg file exists, the config script should suck in the debconf values from there, overwriting anything that was preseeded originally
<smoser> ah. that would make sense too.
<slangasek> smoser: the relevant mantra here is: "Debconf is not a registry" :)  It's a cache only; anything written out to a config file on disk is meant to take precedence.
<smoser> thanks.
<juancarlospaco> I have to make some things for ubucon LatinoAmerica 2012, see you . . .
<FourDollars>  rhythmbox-ubuntuone : Depends: rhythmbox (>= 2.95.5) but 2.95-0ubuntu3 is to be installed
<FourDollars> This occurs on Ubuntu 12.04.
<FourDollars> Does anyone know how to fix it?
<FourDollars> http://packages.ubuntu.com/precise/rhythmbox-ubuntuone V.S. http://packages.ubuntu.com/precise/rhythmbox
<FourDollars> Bug #950546 ârhythmbox-ubuntuone : Depends: rhythmbox (>= 2.95.5...â : Bugs : ârhythmbox-ubuntuoneâ package : Ubuntu http://bit.ly/ygB4qt
<ubottu> Launchpad bug 950546 in rhythmbox-ubuntuone (Ubuntu) "rhythmbox-ubuntuone : Depends: rhythmbox (>= 2.95.5) but 2.95-0ubuntu3 is to be installed" [Undecided,Confirmed] https://launchpad.net/bugs/950546
<RAOF> FourDollars: Looks like the packaging is wrong; you'd need to fix the packaging to make that work.
<pitti> Good morning
<ajmitch> morning pitti
<FourDollars> pitti: Good morning
<FourDollars> RAOF: rhythmbox-ubuntuone has wrong dependency.
<RAOF> FourDollars: Yes, that's right.
<RAOF> FourDollars: And the packging needs to be fixed to give it the right dependency.
<FourDollars> RAOF: Current rhythmbox version is 2.95-0ubuntu3, but rhythmbox-ubuntuone depends on rhythmbox 2.95.5.
<RAOF> FourDollars: Yes, I know.
<RAOF> Which is wrong, and needs to be fixed.
<FourDollars> OK
<FourDollars> Who will take care the fix? Or should I made a fix for it?
<pitti> I just spotted it in http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> I'll fix it
<FourDollars> pitti: Thanks.
<smb> Hm, is it just in my imagination or did a mouse wheel work to scroll text in the a terminal window until recently...
<dholbach> good morning
<RAOF> smb: No, that's not your imagination.  That's gtk3 being weird.
<smb> RAOF, Ah thanks. I had this nagging feeling of going slowly insane... Ok, I know "going" is not right in the first place... :)
<RAOF> kenvandine has hunted down the problem in gwibber; it's likely to be the same thing in gnome-terminal.
<smb> Ok, yes. Well it was this strange thing were it seemed to work everywhere else I checked, just not the terminal (not using gwibber) and me thinking I had been using it before. But then you wonder when you used it at all or when it changed...
<RAOF> smb: Yeah; apparently GTK changed event propagation, so the relevant bit of gnome-terminal is probably not seeing the events anymore.
<smb> lovely. :) but it does match my experience. even when in a text editor the cursor won't move
<geser> I had this problem yesterday (scrolling in terminal didn't work), now it works again. Don't know what exactly changed
<smb> Ah
<smb> seems that may have been fixed by an update I just did
<smb> just not for the terminal in which I had been doing the update and havent closed since
<smb> duh!
<pitti> mvo: so bug 950676 might be a bug in apt, or in seed, or somewhere else; I think I have extracted the relevant portion of apt.log, but not sure where to fix 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
<zyga> hi
<zyga> I've encountered a strange bug in compiz just now
<zyga> my banshee hanged a few momments ago
<zyga> but it's working normally now
<zyga> yet compiz kept the grayscale filter
<zyga> feels like reading a newspaper online after a major tragedy
<RAOF> zyga: Yeah, that's compiz's âsend a WM_PING message to check that the app is still aliveâ algorithm going mad.
<mpt> mvo, do you have a few minutes to talk about what happens to third-party applications when someone upgrades the OS?
<hrw> can someone rebuild pciutils? bug 948205
<ubottu> Launchpad bug 871083 in libtasn1-3 (Ubuntu Precise) "duplicate for #948205 gzip -9n sometimes generates a different output file on different architectures" [Medium,Triaged] https://launchpad.net/bugs/871083
<hrw> I upgraded my system, build pciutils for amd64/armel/armhf and resulting packages are installable
<hrw> s/someone rebuild/someone upload to rebuild/
<cjwatson> I'll do it, thanks
<hrw> thanks
<hrw> one less to worry
<cjwatson> wait, that has nothing to do with the gzip bug actually
<cjwatson> the file you're referring to is *not gzipped*
<cjwatson> so I doubt a mere rebuild will fix this
<cjwatson> hrw: I think the right answer is to remove "Multi-Arch: same" from libpci-dev.  Would that inconvenience you?
<hrw> cjwatson: those files are exactly same on those 3 archs
<cjwatson> Failing that we'd have to move config.h into an architecture-specific directory and hope that everyone is using the .pc file ...
<cjwatson> No they aren't.  See the Debian bug I just linked your bug to
<cjwatson> cjwatson@cocoplum:~/ubuntu/pool/main/p/pciutils$ for x in libpci-dev_3.1.8-2ubuntu4_*.deb; do printf '%s: ' "$x"; dpkg --fsys-tarfile "$x" | tar xOf - ./usr/include/pci/config.h | md5sum; done
<cjwatson> libpci-dev_3.1.8-2ubuntu4_amd64.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
<cjwatson> libpci-dev_3.1.8-2ubuntu4_armel.deb: 473da3dcebfef020d28194407f492ec9  -
<cjwatson> libpci-dev_3.1.8-2ubuntu4_armhf.deb: 473da3dcebfef020d28194407f492ec9  -
<cjwatson> libpci-dev_3.1.8-2ubuntu4_i386.deb: e5cc1d6e20a4b6c2b400c52c22de49c6  -
<cjwatson> libpci-dev_3.1.8-2ubuntu4_powerpc.deb: d5d39ad531d576614153a4af40181950  -
<hrw> libpci-dev_3.1.8-2ubuntu4_amd64.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
<hrw> libpci-dev_3.1.8-2ubuntu4_armel.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
<hrw> libpci-dev_3.1.8-2ubuntu4_armhf.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
<hrw> but I will do more tests - do not worry about it please
<cjwatson> well, I'm looking at the canonical master archive, so my tests win ;)
<hrw> ;)
<cjwatson> perhaps it hardcodes the wrong PCI_ARCH_* in config.h when you cross-build it
<cjwatson> that's pretty plausible
<hrw> probably
<cjwatson> yep, it does
<cjwatson> so that's a separate bug, but it doesn't mean that a rebuild is any use here
<hrw> ugly pciutils - so yet another bug
<hrw> sure, thanks for checks
<cjwatson> would removing Multi-Arch: same inconvenience you?
<cjwatson> most -dev packages don't have M-A: same yet, after all
<hrw> I got 'hit' by that when wanted to cross compile one of packages which depend on libpci-dev
<cjwatson> sure, the worst case would be that you'd have to remove libpci-dev from the chroot in favour of libpci-dev:armhf
<hrw> yep
<cjwatson> so I'll do that then
<hrw> want debdiff?
<cjwatson> already uploaded
<hrw> cool ;)
<mvo> mpt: sure, maybe in some minutes?
<hrw> heh.. armhf
<hrw> bug 935280 on a way to be fixed
<ubottu> Launchpad bug 935280 in linphone (Ubuntu Precise) "linphone version 3.3.2-4.1 FTBFS on armhf in precise" [High,In progress] https://launchpad.net/bugs/935280
<jdstrand> cjwatson: hi, do your apparmor changes address bug 706354?
<ubottu> Launchpad bug 706354 in ntp (Ubuntu) "dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing" [Low,Confirmed] https://launchpad.net/bugs/706354
<hrw> bug 935280 ready for sponsors
<ubottu> Launchpad bug 935280 in linphone (Ubuntu Precise) "linphone version 3.3.2-4.1 FTBFS on armhf in precise" [High,In progress] https://launchpad.net/bugs/935280
<cjwatson> jdstrand: no
<jdstrand> ok, I see that now
<pitti> cjwatson: if you have a minute, could you please have a quick look at bug 889986 ?
<ubottu> Launchpad bug 889986 in ubuntu-defaults-builder (Ubuntu) "Defaults builder does not support @-locales" [Undecided,Confirmed] https://launchpad.net/bugs/889986
<cjwatson> jdstrand: that's really bug 198421, which I suppose I should get round to fixing
<ubottu> Launchpad bug 198421 in debconf (Ubuntu) "DPKG_MAINTSCRIPT_PACKAGE not set by dpkg-reconfigure causing dpkg-trigger to fail" [Medium,Triaged] https://launchpad.net/bugs/198421
<jdstrand> I see
<cjwatson> pitti: hmm, will take a bit more than a minute :-/
<pitti> cjwatson: it was mostly about "do you happen to know if ca@valencia" is valid for /isolinux/lang'
<cjwatson> I don't happen to know
<cjwatson> it probably ought to be
<pitti> cjwatson: I can RTFS myself, do you know which source reads that?
<cjwatson> gfxboot-theme-ubuntu but it's almost certainly several layers deep ...
<cjwatson> the installer doesn't support ca@valencia anyway so ...
<cjwatson> it could also be localechooser
<pitti> ah right, there's no Catalan (Valencia) in the list anyway
<cjwatson> right, commented out since the translations are incomplete
<pitti> ok, so that woudl be a prerequisite for this anyway
<pitti> cjwatson: thanks! that helps already
<cjwatson> jdstrand: duped - it'd be incorrect to fix this in every package that uses dpkg-maintscript-helper, so please don't
<jdstrand> cjwatson: I will glady continue to ignore the bug. thanks ;)
<mpt> mvo, how about now?
<hrw> bug #935006 ready for sponsors
<ubottu> Launchpad bug 935006 in nikwi (Ubuntu Precise) "nikwi version 0.0.20060823-2 FTBFS on armhf in precise" [High,In progress] https://launchpad.net/bugs/935006
<geser> hrw: looks like you forgot to run "update-maintainer"
<hrw> geser: again ;(
<hrw> geser: thanks
<geser> you should got a warning about it from debuild and if you'd use your @ubuntu.com email address debuild would fail with an error
<ogasawara> @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: ogasawara
<ahasenack> hi guys, do you know why precise has "Supported: 0" in http://changelogs.ubuntu.com/meta-release-development ?
<ahasenack> shouldn't it be 1, since it's currently even in beta? Or is there another way to differentiate the current in-development release from the EOL ones?
<ScottK> There's no support promised for the development release.
<ScottK> So what's to distinguish?  The level of support is the same.
<hrw> geser: I use my @linaro.org email
<mvo> mpt: hi, sorry I'm in another call right now
<mpt> ok
<hrw> geser: fixed debdiff uploaded
<geser> hrw: the script that does this Maintainer checks errors only for @ubuntu.com addresses and produce a warning for other
<hrw> ok, will remember
<Malizor> Sweetshark: ping?
<dobey> doko: ping. can you look at sponsoring https://code.launchpad.net/~dobey/ubuntu/precise/twisted/fix-935756/+merge/96617 please?
<Malizor> Sweetshark: I come from #ubuntu-translators, about these 2 LibreOffice bugs: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/950825
<ubottu> Launchpad bug 950825 in Ubuntu Translations "LibreOffice quicklists are not translated" [High,Triaged]
<Malizor> and https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/950834
<ubottu> Launchpad bug 950834 in libreoffice (Ubuntu) "Add keywords to .desktop files" [Undecided,New]
<Sweetshark> Malizor: I made bug 950825 mine and commented on bug 950834.
<ubottu> Launchpad bug 950825 in Ubuntu Translations "LibreOffice quicklists are not translated" [High,Triaged] https://launchpad.net/bugs/950825
<ubottu> Launchpad bug 950834 in LibreOffice Productivity Suite "Add keywords to .desktop files" [Undecided,Incomplete] https://launchpad.net/bugs/950834
<Malizor> Sweetshark: ok, thanks
<cjwatson> jdstrand: I've followed up to the Debian bug now about DPKG_MAINTSCRIPT_PACKAGE with a new set of patches, to try to get this sorted out
<jdstrand> cjwatson: awesome, thanks
<dpm> cjwatson, has there been any recent debian-installer upload that introduced new translatable strings? I've just noticed that comparing it to yesterday, some languages that were translated have now got about 175 untranslated strings
<cjwatson> dpm: glad you noticed :)  bug 812232
<ubottu> Launchpad bug 812232 in tzsetup (Ubuntu) "lucid debian-installer: timezone screen not translated" [Medium,Triaged] https://launchpad.net/bugs/812232
<cjwatson> dpm: I noticed that I hadn't uploaded the consolidated d-i translations in at least a year :-/
<pitti> Riddell: what is the default user-facing package manager in Kubuntu now? I. e. after kpackagekit?
<Riddell> pitti: Muon
<pitti> Riddell: cheers
<Riddell> Muon Installer for the app focused bit
<mpt> mvo, is it possible to tell, ahead of time, whether the computer has enough disk space to upgrade? Or is that impossible because packages stick their files in unpredictable places?
<pitti> mpt: we should be able to make a fairly exact prediction
<pitti> of course postinst scripts could generate tons of data on the fly, but that's only theoretical I hope
<mpt> excellent
<mpt> The current "Do you want to start the upgrade?" alert tells you exactly how many packages will be installed, upgraded, and removed, but not how much disk space is involved
<pitti> mpt: should it actually tell you, or just check that you have enough?
<mpt> pitti, both, I think. E.g. if you're in the sort of job where you often work with large files, but the upgrade is going to leave you with less than 1 G, maybe you want to wait even though the upgrade would work. :-)
 * ogra_ thought it did check and tell you if there isnt enough
<ogra_> (and didnt bother to say anything if there is enough)
<pitti> that was my impression, too
<pitti> at least I did see that in the past when I tried in a VM without enough free space
<ogra_> i definitely had the "not enough space" error in the past
<mpt> good
<dholbach> in the past there were also cases where there were multiple partitions involved where doing the estimation is quite a bit harder
<pitti> that's right, with a separate /usr we have lost
<pitti> i. e. we can't do a reliable check
<pitti> we can be pessimistic and assume that /usr must have enough space for teh whole upgrade
<infinity> @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: ogasawara, infinity
<pitti> skaet: bug 921231 looks like a bug fix to me, and bug 924007 looks nowhere near like a FFE request
<ubottu> Launchpad bug 921231 in Application Menu Indicator "XUL Applications don't show up in HUD" [High,Confirmed] https://launchpad.net/bugs/921231
<ubottu> Launchpad bug 924007 in Application Menu Indicator "Add GMenuModel support to HUD" [High,Fix committed] https://launchpad.net/bugs/924007
<pitti> skaet: for 924007 I'd need some more information
<pitti> about the regression potential etc.
<skaet> pitti,  thanks.   Cimi ^^
 * mpt wonders if we can detect Internet speed, to avoid having to say "This download will take about 1 hour 33 minutes with a 1 Mbit DSL connection and about 1 day 4 hours with a 56k modem"
<ogra_> no
<ogra_> even that statement is bogus
<mpt> It depends on mirror speed etc, right?
<pitti> we could give an estimate after downloading the first MB or so
<ogra_> you cant predict the routing that takes place in internet connections
<ogra_> yeah, what pitti said
<pitti> actually, it could download the package indexes
<pitti> which we'd need to do anyway to figure out what to update
<mpt> aha
<pitti> i. e. before starting the actual upgrade
<cjwatson> we could detect current available bandwidth, but e.g. if your son happened to be downloading youtube videos or something just at the moment then that would throw off the estimate badly
<mpt> a cunning plan
<pitti> and based on the speed/size of that give an estimate
<cjwatson> maybe that's unavoidable
<pitti> but there's no promise that it'll be stable, of course
<mpt> sure
<pitti> but at least it'd be a whole lot more useful than the status quo IMHO
<pitti> sure, if the user maxes out his bandwith with youtube HD during upgrade, no amount of estimation will help there :)
 * mpt waves to ivanka
<mvo> mpt: diskspace> we can and we do check, but what we are not good at is if the user is using a filesystem with a bunch of different mountpoints, e.g. /var on a different parition than /boot
<mvo> mpt: because while we do know the size of the debs data we do not know the distribution of it (easily)
<mvo> mpt: like if it puts stuff in /boot or /usr and what amount
<mpt> mvo, I remember this same problem from USC
<mvo> mpt: but in the typical all is under "/" or "/home", "/" setup its a non-issue
<mvo> mpt: yes, exactly the same problem there
<pitti> mvo: as /usr takes the bulk of the data, I think the check should query df /usr
<pitti> mvo: it'll be too pessimistic for a separate /usr, /var, of course, but the main thing on / is the kernel
<pitti> for that you could just substract 200 MB from the limit?
<ivanka> hi mpt :-)
<masterseh> im selling my macbook pro 15" and asus g74sx laptops. anyone interested? please message me if you are.
<jdstrand> :w
<jdstrand> heh
<lynxman> cjwatson: ping
<m_3> mhall119: ping (summit questions)
<cjwatson> lynxman: hi
<lynxman> cjwatson: ello, saw the chef dependency on mcollective-plugins-ohai
<lynxman> cjwatson: I did that source package, it depends on chef just for that, but removing it would just make that plugin not installable (which makes sense, it bridges with chef)
<lynxman> cjwatson: if someone wants to use it with the opscode ppa it'll work as intended
<cjwatson> lynxman: then I'm not removing chef - I'm not prepared to have uninstallable packages in the archive, sorry
<lynxman> cjwatson: let me talk with robbiew
<cjwatson> you could move the binary to that PPA, or downgrade the Depends to Recommends if that makes sense, or something else
<robbiew>  mcollective-plugins-ohai should be removed too, imo
<lynxman> cjwatson: downgrading sounds good then
<lynxman> robbiew: that shouldn't be difficult either, your call guys :)
<cjwatson> robbiew: archive admins can't do that until the source package stops building it
<robbiew> well the version of chef we have is unsupported by OpsCode
<robbiew> ah
<lynxman> cjwatson: yeah I can do a new version of mcollective-plugins removing that package
<cjwatson> which is why I bounced the bug
<lynxman> cjwatson, robbiew: so either recommends or drop it completely, your call
<robbiew> lynxman: drop it
<lynxman> robbiew: alright, will drop it straight away, submit a debdiff
<robbiew> lynxman: fwiw, I confirmed this with opscode in email...they wanted it dropped in addition to ohai and chef
<lynxman> robbiew: sounds good then :)
<lynxman> cjwatson, robbiew: Attached debdiff to bug, if someone fancies sponsoring it I will be grateful :)
<mvo> pitti: yeah, this is what the code is currently doing, assuming the bulk goes to /usr and adds a fixed amount for /boot for each kernel
<slangasek> seb128: no more complaints about gconf, right? :)
<seb128> slangasek, no, thanks a lot for fixing it!
<slangasek> n/p
<slangasek> sorry it took so long
<seb128> no worry
<seb128> slangasek, want a new bug? ;-)
<seb128> I've some to give away :p
<slangasek> not really... :)
<slangasek> I have some to give away too :)
<seb128> slangasek, joke aside I just saw bug #950967
<ubottu> Launchpad bug 950967 in glib2.0 (Ubuntu) "glib2.0:armel uninstallable on non-native architectures" [Undecided,New] https://launchpad.net/bugs/950967
<seb128> slangasek, no hurry but in case you are interested
<seb128> I might have a look next week but it's low on my list currently
<seb128> I just wanted to point it at least
<slangasek> here, let me fix that bug title
<slangasek> :)
<slangasek> well, let me try and fail to fix that bug title
<seb128> launchpad fail? ;-)
<slangasek> something like that
<slangasek> anyway
<slangasek> I think Neil Williams also opened a bug about this in Debian, let me see
<slangasek> seb128: yeah, mbiebl has already fixed in Debian, I think it's just adding another || true for consistency
<slangasek> oh, but there's also this:
<slangasek>     + Only run gio-querymodules on the non-multiarch path for the hostÂ»
<slangasek>       architecture.
<slangasek> which is just wrong :/
<mbiebl> slangasek: why?
<slangasek> mbiebl: who says /usr/lib/gio/modules belongs to the native arch?
<slangasek> it's for backwards-compatibility only, but multiarch does not guarantee that the packages installing to that path are of the native arch
<mbiebl> slangasek: how can you install no-native modules in a non-ma path?
<slangasek> mbiebl: by installing a foreign-arch package that has not yet been converted to the multiarch path
<mbiebl> how is that possible?
<slangasek> why would it *not* be?
<slangasek> multiarch only says that you can't have the native one installed *at the same time*
<slangasek> it doesn't say you can't install the foreign one
<slangasek> mbiebl: e.g.: http://paste.ubuntu.com/876317/
<mbiebl> slangasek: ouch, so you could install a arm so in the /usr/lib/gio on a i386 system?
<mbiebl> how is that supposed to work
<slangasek> it works because the primary use case is for installing packages of archs whose code you can actually run ;)
<slangasek> and with qemu-user-static + binfmt-support, you can run arm code on x86
<mbiebl> so what matters is the case where /usr/lib/gio is for the native arch
<slangasek> no
<slangasek> if there's a gio module that's only available for i386, the package hasn't been converted to the multiarch path, and my native arch is amd64, what should happen?
<mbiebl> then you have a problem
<mbiebl> if you let random archs put so in /usr/lib/gio
<mbiebl> and process them for every arch
<mbiebl> that won't work
<cjohnston> m_3: ping
<m_3> cjohnston: hey!
<slangasek> mbiebl: it does work, it's been working here for me on Ubuntu for two cycles ;)
<m_3> cjohnston: got a couple of questions on summit production installation if you've got a sec
<cjohnston> postgres
<cjohnston> ;-)
<cjohnston> what's up
<mbiebl> whatever
<m_3> cjohnston: so lemme see what the current state of the app is... (I've been experimenting)... one sec
<slangasek> the modules for the wrong arch are ignored
<cjohnston> ok
<slangasek> and you get a cache of the ones that match your arch
<m_3> cjohnston: yeah, it's still doing it: http://ec2-75-101-197-201.compute-1.amazonaws.com/
<m_3> cjohnston: the installation notes seem to all be about setting up a development environment, but it looks like I'm missing some production config
<cjohnston> m_3: python manage.py shell
<cjohnston> m_3: Menu.objects.create(site_id=1, name='uds', slug='uds')
<cjohnston> m_3: exit()
<m_3> cjohnston: Menu isn't defined
<cjohnston> hrm
<cjohnston> sory
<m_3> cjohnston: the shell told me to remove south though, so that's progress... :)
<cjohnston> from common import Menu
<cjohnston> m_3: Menu.objects.create(site_id=1, name='uds', slug='uds')
<cjohnston> m_3: exit()
<cjohnston> now its complaining about the database engin
<mbiebl> slangasek: talk to Joss, he added that code
<slangasek> ok
<mbiebl> personally I wasn't aware that gio-query-modules can process arch-foreign modules
<slangasek> it can't, but it should discard them gracefully
<slangasek> (AIUI)
<mbiebl> process in the sense that it handles them correctly
<mbiebl> i.e. skip them
<mbiebl> anyway, I'm wondering if it matters much, seing there is no more package installing into /usr/lib/gio
<slangasek> aren't there?
<slangasek> Ubuntu still has one (libgio-fam)
<slangasek> maybe there are third-party ones, I don't know
<slangasek> but this applies to everything, not just gio
<mbiebl> no libgio-fam on debian
<mbiebl> and I think issues like that need to be decided case by case
<seb128> mbiebl, -fam is arch: hurd-any kfreebsd-any
<seb128> mbiebl, but it's in debian as well as Ubuntu iirc
<mbiebl> seb128: so it's just a theoretical issue
<seb128> mbiebl, I didn't follow, I think it is, in fact in Ubuntu I dropped the compat dir support
<mbiebl> i don't see either where this particular issue matters in practice
<mbiebl> anyway, there is more important things to do than this one
<mbiebl> seb128: even the libgio-fam package for non-Linux arch use m-a paths
<seb128> mbiebl, yeah, agree, I think Steve was just pointing it could be problematic, or rather is theorically wrong, without knowing much about gio and how much it's used
<seb128> not sure that was well worded
<seb128> "I don't think he looked at the rdepends or what could potentially be installed there as third party, he just pointed that it could be problematic"
<seb128> mbiebl, i.e imho in practice it's a non issue and we can move on
<mbiebl> slangasek: actually
<slangasek> what I actually mean is, "eew, now the maintainer script is way more complicated than it should be, for something that wasn't a bug in the first place" :)
<mbiebl> running gio-query-modules on a non-native arch will overwrite the giomodule.cache
<mbiebl> you don't want that
<slangasek> mbiebl: no, the giomodule.cache is in an arch-qualified path
<mbiebl> nope, it's created in both
<slangasek> oh
<slangasek> ok, that's a good argument then
<slangasek> though it'd be nice to just drop that compat stuff altogether ASAP :)
<mbiebl> as said, we don't have any /usr/lib/gio modules anymore
<slangasek> I thought the .cache was built only in one dir, not for each dir
<mbiebl> so we will just drop it post-wheezy
 * slangasek nods
<slangasek> SpamapS: can you check my reasoning in bug #950662?
<ubottu> Launchpad bug 950662 in upstart (Ubuntu) "Waiting for network message on bootup when all network devices are up" [Medium,Incomplete] https://launchpad.net/bugs/950662
<SpamapS> slangasek: reading
<stgraber> slangasek: I was also wondering if we shouldn't prevent these messages and the fallback when we actually start configuring an interface
<slangasek> stgraber: no
<slangasek> it's not enough to configure *an* interface
<SpamapS> slangasek: very interesting
<slangasek> you need to successfully configure *all* interfaces to avoid getting a boot delay
<stgraber> slangasek: I have a system here that takes 45s to 1 minute to configure the network and it's fine and expected, so the failsafe kicking in could give unexpected results
<slangasek> stgraber: well, you could tweak the timeouts in the file
<slangasek> but the current behavior is intended
<slangasek> anyway, it's already a 2 minute delay, isn't that long enough for your network to come up?
<stgraber> it's for most of them, one system I have 10 bridges, each of them taking up to 30s to come online (standard wait in bridge-utils)
<SpamapS> slangasek: I do see the point in what stgraber is saying.. failsafe is playing a bit dumb right now and warning of the delay, but it might make sense to make it a more informed message.
<slangasek> how could it be more informed?
<slangasek> without making it way more complicated
<SpamapS> well if we know about the interfaces being waited on.. and their state, we have some clues that perhaps a message is not needed.
<SpamapS> yeah
<SpamapS> thats the thing, complicated..
<SpamapS> slangasek: I agree with your assessment to change it from runlevel to starting rc-sysinit .. will mention in the comment as well.
<stgraber> I'm unsure how to improve the situation and doubt it'd be easy to do for 12.10 but ideally the timeout should be somehow reset every time an interface gets to pre-up
<slangasek> stgraber: right, I can see wanting to reset the timeout in that case
<slangasek> but the messages should still be displayed so people know what's going on
<SpamapS> Or just extend it by a factor of the number of interfaces
<SpamapS> and agreed.. message should stay for user sanity :)
<slangasek> SpamapS: but most of the time the interfaces are going to come up in parallel and 120s is plenty
<stgraber> slangasek: yeah, the "Waiting for network..." one should be displayed, it'sthe waiting one more minute one we should delay more or have reset every time an interface gets to pre-up
<stgraber> yeah, the only case I've seen so far where 120s doesn't work is when you have bridges defined in /etc/network/interfaces with bridge-ports none
<stgraber> these are then started sequentially by /etc/init/networking.conf
<stgraber> (I'm using these for containers and VMs to create separate networks)
<maswan> does https://bugs.launchpad.net/bugs/415353 count? ~10 minutes on my servers.
<ubottu> Launchpad bug 415353 in linux (Ubuntu Lucid) "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,Incomplete]
<stgraber> maswan: it'd help booting a system like this post-install yes, though the delay in your case is definitely a bug :)
<SpamapS> slangasek: if the absolute time of the timeout were simply pushed back, not the amount of time remaining, then parallel or not, it woudl work out and be fairly simple
<slangasek> SpamapS: it would be an inappropriately long timeout in the case of /etc/network/interfaces containing configuration for interfaces that don't exist
<SpamapS> slangasek: as stgraber says, only if they enter pre-up
<SpamapS> slangasek: or are you saying, thos still go pre-up.. ?
<slangasek> oh, no
<slangasek> you said "extend it by a factor of the number of interfaces", I didn't realize you meant to count the number of interfaces coming up
<slangasek> I assumed you meant counting the number of interfaces configured initially
<SpamapS> Its a nice feature to think about..just calculate now+60s and then write that to a file, and any time there is a pre-up, push the time back to now+60s ..
<SpamapS> slangasek: yeah that was folly ;)
<lfaraone> sabdfl: Per discussion on ubuntu-devel@, I'm submitting the application for Ubuntu to GSoC. Can I agree to the terms on behalf of Ubuntu?
<mhall119> m_3: ping
<smoser> would it seem impossible to anyone that 'db_get' in /usr/share/debconf/confmodule seems busted for debconf values with a newline ?
<smoser> it seems i'm only getting the first line if i do :
<smoser> val="$(debconf-escape --escape < my.local )"
<smoser> printf "%s\t%s\t%s\t%s\n" cloud-init cloud-init/local-cloud-config string "$val" | sudo debconf-set-selections -v
<smoser> then, in the postinst of cloud-init, i'm doing:
<smoser>   db_get "${debconf_name}" && ccfg="$RET" || :
<smoser> but it seems like ccfg ends up with only the first line
<smoser> it seems to be getting stored correctly in /var/cache/debconf/config.dat
<Daviey> roaksoax: That curl-udeb we discussed, can you upload it please
<Daviey> (isn't finished? http://bazaar.launchpad.net/~andreserl/ubuntu/precise/curl/lp940425/revision/57)
<roaksoax> Daviey: give me a few seconds
<roaksoax> Daviey: yes and now, I mistakenly uploaded that branch without adding the bin, but I do have a diff with it that i'm applying now
<Daviey> cool, can you pastebin the diff first?
<smoser> slangasek, that seem possible to you ?
<roaksoax> Daviey: http://paste.ubuntu.com/876623/
<smoser> that debconf 'db_get' is broken for multi-line input that has been escaped with 'debconf-escape --escape' ?
<smoser> cjwatson, ^ ? (i'm sure you're not around)
<slangasek> smoser: there's a debconf feature you have to turn on to indicate how to handle escaping
<roaksoax> Daviey: should I upload now?
<Daviey> roaksoax: One mo, i'm in a situation where i can test it easily.
<roaksoax> Daviey: ok cool, this also means adding Depends on curl-udeb for maas-enlist-udeb
<smoser> slangasek, so maybe 'db_capb ESCAPE' ?
<slangasek> smoser: call db_capb escape, yes
<smoser> i'll give that a try. thanks.
<smoser> slangasek, gracias. all happy now.
<infinity> @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: ogasawara
<infinity> ogasawara: Are you really still piloting today, or did you forget to tell the bot you'd left?
<ogasawara> infinity: just about to sign out for today
<ogasawara> @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:
<iulian> janimo`: Thanks for the GHC armhf fix!
<janimo`> iulian, cheers! could be useful in Debian too, are you active there or is Laney the contact?
<Laney> janimo`: I think I have a fix without using sed, using the preprocessor
<Laney> but yes, I'll ask the list and see if we want it in Debian
<ScottK> kenvandine: Your pidgin upload build-depends on a package that's apparently not even in the archive.  This might be the sort of thing that ought to be discussed with the release team (i.e. FFe) before you do it.  Please fix.
<janimo`> Laney, at least the VFPv3D16 change is needed there too to be conformant to what the debian/ubuntu armhf port targets
<kenvandine> ScottK, you mean farsight?
<kenvandine> it was a package rename
<Laney> janimo`: in aclocal? yeah
<ScottK> Is the renamed package in Ubuntu?
<kenvandine> we synced it from debian
<kenvandine> yes, but it had a dep from universe, i uploaded a fix a bit ago
<kenvandine> upstream renamed farsight to farstream and empathy/telepathy stuff depended on it
<ScottK> Telepathy-farstream?
<kenvandine> telepathy-farstream depended on the rename too
<kenvandine> that existed
<kenvandine> farstream is what it needed
<kenvandine> we discussed it with pitti, he said it was fine
<ScottK> https://launchpad.net/ubuntu/+search?text=farstream says it's still not there.
<kenvandine> https://launchpad.net/ubuntu/precise/+source/farstream/0.1.1-1ubuntu1
<ScottK> OK.  Weird.
<kenvandine> once the fix i uploaded is published i am going to kick of rebuilds
<ScottK> OK.
<ScottK> BTW, if there had been an FFe bug that explained all this, then people other than pitti on the release team would have known.
<infinity> Or, if it had all gone smoothly, no one would have cared. ;)
<kenvandine> ScottK, sorry, we figured since it was basically part of the gnome 3.3.90 update
<ScottK> Right, but as infinity says, once it starts to go sideways, people notice.
<ScottK> Also Kubuntu is using Telepathy now, so it's not just an Ubuntu concern.
<iulian> janimo`: I'm also active in Debian but Laney is doing the uploads there because I have limited upload privileges.
<kenvandine> oh, anything using telepathy-farstream?
<ScottK> I'm not sure.
<ScottK> shadeslayer: ^^^?
<ScottK> He'll know.
<kenvandine> nothing according to rdepends
<ScottK> OK.  Thanks for checking.
<sabdfl> lfaraone, probably, yes
<sabdfl> i.e. there's no reason for the big G to shaft us, feel empowered if you've read it carefully
<lfaraone> sabdfl: unfortunately, the deadline for applying closed 10 minutes ago :( pleia2 wrote an email to the community-council@ list why we missed the it.
<sabdfl> ah
<sabdfl> well, thanks for looking at it, pity we didn't get our act together, would be appreciated if a new community member ran that show!
<lfaraone> sabdfl: sent a mail to carols, who runs the programme, but I don't expect much. Next year, then :)
<sabdfl> again :(
<sabdfl> but thank you
#ubuntu-devel 2012-03-10
<slangasek> Riddell: so with soprano, do you think I should just upload it, or do you prefer that I wait for your testing on Monday?
<Riddell> slangasek: what's the change?
<cjwatson> the one I asked about in the release meeting ...
<slangasek> Riddell: yep, that one - linking soprano-daemon against libvirtodbc0 directly instead of using libiodbc2 as a driver manager
<Riddell> slangasek: how about if I test tomorrow?
<slangasek> Riddell: you can test whenever you'd like, I was just checking if you actually thought it was better for me to wait :)
<Riddell> slangasek: soprano is a bit unreliable at the best of times so I think I'd prefer to check it
<slangasek> ok
<SpamapS> woot.. always nice fixing 5xxxxx bugs :) .. though 4xxxxx are even sweeter.. ;)
<scientes_> how much doesn't work if i install systemd?
<scientes_> i.e. how much stuff uses upstart-native?
<scientes_> and _doesn't_ also shit sysvinit scripts
<shadeslayer> ScottK: I think telepathy-qt .... I'm not sure, I recall someone talking about telepathy-qt and farstream a couple of weeks ago
 * shadeslayer doesn't quite remember ...
<Laney> cd
<dupondje> Some small question. When a module is copied to the initramfs, whats the order it will be loaded @ boot?
<ximion> hi! You might want to take a look at my recent upload of the "packagekit" package at Debian...
<ximion> the new upstream version might be wanted in Ubuntu too, and I applied some patches to it...
<ximion> where one of them fixes a crash in PK.
<ximion> so you might want to take the patches at least, to apply them on Ubuntu too :)
<aseem> Hi is this the channel to discuss about Ubuntu's project ideas for GSOc2012 ?
<Chipzz> aseem: I'm not 100% sure, but my guess would be yes (unless there's a more specific channel, but I'm not aware of any)
<Chipzz> aseem: you should be aware though that it's weekend and that a lot of developers are not present
<aseem> Chipzz, HI! There is #ubuntu-gsoc channel, but in the wiki #ubuntu-devel was mentioned so I got confused.
<Darxus> How do I get bug 831768 added to the top of the list of known issues on https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes ?  I would not have upgraded last night if I had known about it.  (Admitedly, I failed to read that document first, but that's where the warning should be.)
<ubottu> Launchpad bug 831768 in aptitude (Ubuntu Precise) "aptitude cannot handle conflicts with multiarch enabled" [High,Triaged] https://launchpad.net/bugs/831768
<awe> Darxus, I'd ping Kate.Stewart, as she's the Ubuntu Release manager ( and also was the last person to edit the page )
<awe> https://wiki.ubuntu.com/ReleaseTeam
<Darxus> Thanks.
<awe> np
<infinity> Darxus: If that's cause you issues, you could just disable multiarch again.
<infinity> Darxus: "I wouldn't have upgraded" seems a bit harsh, when it's just one small config file.
<Darxus> infinity: My understanding is that there will be 32 bit software I'll need to install at some point that I won't be able to because of this.
<Darxus> I don't claim to fully understand the situation.
<infinity> Darxus: That's only true is you already had 32-bit software installed...
<infinity> s/is/if/
<Darxus> infinity: And just disabling multiarch didn't work.  I had to re-enable multi-arch, apt-get install qdbus, and then disable multiarch again.  As I commented to that bug.
<infinity> We have no intention of cutting out 64-bit software and forcing 32-bit stuff on you, just not shipping duplicates (like wine32) on both architectures.
<Darxus> infinity: So.. I probably didn't have 32 bit software installed on natty, so I probably won't care about it on oneric+?
<infinity> Yeah, if you're running a pure 64-bit system, we're not going to take that option away.
<infinity> Did you upgrade with aptitude, or just run into problems with aptitude after upgrading with do-release-upgrade or similar?
<infinity> Darxus: Anyhow, I'm not arguing that "aptitude and multiarch don't entirely get long" shouldn't have been in the Oneiric release notes, and feel free to ping skaet about that.
<Darxus> Awesome, thanks.
<infinity> skaet: ^
<Darxus> I followed the directions for upgrading, so used update manager, then aptitude wouldn't work after.
<infinity> Darxus: Just that there are any number of workarounds (the two most obvious being "disable multiarch" or "don't use aptitude")
<skaet> infinity,  Darxus pinged me about it earlier.   I'll add it on monday.
<infinity> skaet: Alright. ;)
<Darxus> Damn, didn't even give me a chance to type that.
<infinity> Darxus: We'd like to get this all fixed for precise, but I will admit that we have limited resources, and aptitude's not the top of too many priority lists. :/
 * infinity wonders idly how well dselect plays with multiarch.
<Darxus> Hah.
<Darxus> Well, what about disabling multiarch by default on 64 bit systems in precise?
<infinity> Not going to happen.
<infinity> For users of update-manager, software-center, or just hardcore apt-get users, (or python-apt, libapt in general, etc), multiarch is just fine as a default.
<infinity> aptitude's resolver has been known-broken for years, it's just that this hilights it much more than ever before. :/
<infinity> I'd sooner port tasksel to libapt and demote aptitude to universe than disable multiarch.
<infinity> But that's just me.
<infinity> (And, honestly, that should probably be done regardless, even if we do find the time to fix aptitude)
<Darxus> My entire reason for using aptitude is a belief that if I install a package, and its dependencies are automatically installed, then I uninstall that package, only aptitude will handle removing the no-longer needed dependencies.  How true is that?
<infinity> apt-get does that.
<Darxus> Automatically?
<Darxus> I just saw something about apt-get autoremove...
<infinity> Try it.  Install something with deps, remove that something, then note the list of "no longer needed packages", which it will happily remove with "apt-get autoremove"
<Darxus> Why isn't that just done with apt-get remove?
<infinity> Automatic autoremoval, apt won't do.  That was a conscious decision.
<Darxus> Hmm, okay.
<infinity> You may have come to rely on one of those deps.
<Darxus> Sure.
<infinity> autoremove gives you the option to at least think about it briefly.
<infinity> (And you can mark something as "manually installed" just with "apt-get install <already-installed-package>"
<infinity> Bu)
<infinity> Err.
<infinity> Typing hard.
<Darxus> What about stuff installed via the gui package management software?  Will those dependencies also be removed by apt-get autoremove?  I've avoided using them for the same reason.
<infinity> All the GUI tools we support (software-center, update-manager, and synaptic) use libapt (sometimes via python-apt), and so follow the same semantics.
<infinity> So, only the software you manually "select" is marked as manually installed, the rest is transitively installed, and candidate for autoremoval if no longer needed.
<Darxus> Awesome, that all sounds good enough for me to stop using aptitude.  I really appreciate that.  I'll probably mention it on that bug thread in case others are in the same position.
<infinity> Oh hey, we don't support synaptic anymore.  Look at that.  But the above is still true. :P
<infinity> Anyhow, the apt resolver is so much saner than aptitude's at this point that I don't see the point in aptitude usage for most people.
<Darxus> "autoremove" is too long to type :P
<infinity> aptitude and dselect both did a really good job of presenting higher level package relations, but I suspect that's less needed now that resolvers actually kinda work.
<infinity> (I know I used to not be able to do anything without dselect holding my hand, but that was a decade ago)
<Darxus> Heh.
<Darxus> My memories of dselect are so distant at this point.
<Darxus> At the time it seemed magical compared to redhat, which I had just switched from.
<infinity> It was magical.
<Darxus> Finding a package to test autoremove with is hard :P
<infinity> And pre-apt, it was incredibly magical.
<Darxus> Ah, here we go, clisp.
<Darxus> I just accidentally verified that dependencies installed via aptitude also get removed via apt-get autoremove.
<Darxus> This is going to be a tough habit to break.
<infinity> Handy.
<infinity> I think someone switched aptitude to use the apt cache for that a few years ago.
<infinity> Or, it sounds vaguely familiar.
<infinity> Which seems to be backed up by your evidence.
<slangasek> yes, ~4 years ago
<slangasek> when apt started having a notion of autoinstalled packages
<Darxus> Nice.
<infinity> slangasek: So, uhm.  Yeah.  Speaking of aptitude.  I wibbled on above about how it might be a sane idea to make tasksel stop depending on it.
<infinity> slangasek: I suspect that, other than emotional attachment, that's the only reason it's in main.
<slangasek> instead of fixing aptitude to support multiarch?
<infinity> slangasek: Oh, both should happen, IMO.
<slangasek> it is the only TUI we have for package management
<slangasek> (not counting dselect, which I don't :)
<infinity> slangasek: aptitude should stop being broken, but I see no reason why tasksel needs aptitude anymore.  apt has understood tasks for years.
<slangasek> I think the tasksel dep remains reasonable
<slangasek> no, aptitude is there so that users can drill down into tasks further from the installer and make more fine-grained selections interactively
<slangasek> if it were just there for tasksel to tell apt "install tasks", I'd agree, but I don't think that's the rationale
<infinity> Fair enough.
<infinity> (And I would count dselect if we shipped it...)
<infinity> I always thought the dependency was literally just for the "install this task" functionality.
<infinity> Which apt didn't have at the time tasksel was written.
<slangasek> as for fixing aptitude for multiarch, there are some comments on the bug from someone who seems to now be involved in aptitude upstream development... we should probably pull some patches for precise
 * ScottK hands infinity cupt for even more 'fun'.
<infinity> (And, indeed, not for many years after)
<slangasek> yes, because everything's better in perl
<infinity> Well, it's a perl frontend to a C++ library.
<slangasek> The cupt maintainer is actively hostile to multiarch.  That suits me just fine, because I'm hostile towards reimplementing the wheel by casting it out of jello.
<infinity> I'm still not sure why people feel the need to rewrite apt-get/libapt every 3 years, though.
<ScottK> We also have libqapt now.
<infinity> ScottK: Which isn't just a tiny shim on libapt? :/
<ScottK> infinity: Yes.  It's a tiny shim to get a sane API from the author's POV for other development.
<infinity> ScottK: Okay, yeah, looks more like a bindings interface, I'm okay with that.
<ScottK> It is a lot like that.
 * slangasek nods
<infinity> There's a lot of value in making developers of Language/Toolkit X comfortable with using your library.
<infinity> And Qt devs definitely seem to live in a world where if things don't look just like Qt, they die a little inside.
<infinity> (Although, wrapping a C++ library in different-looking C++ just to make it cosmetically more appealing is a bit entertaining)
<ScottK> libqapt was done by one of our developers as part of his drive to get an apt/dpkg native GUI package manager for Kubuntu.  It's in Debian now too.
<Daviey> slangasek: Have you ever tried to dig into tasks deeper using aptitude, within d-i?
<Darxus> Now I need to decid if I want to re-enable multiarch.
<Darxus> I guess I'll leave it off until I need something that won't otherwise work.
<Chipzz> infinity: does anyone even still use dselect?
<Chipzz> I never used or even tried it. and frankly I only have a vague notion what it is/does :)
<Darxus> Wait, how the hell did qdbus:i386 get installed on my system by update-manager?
<Darxus> There's a 64 bit version, and that should've been installed instead, right?
<infinity> It certainly should have been.  Are you sure update-manager was the culprit?
<infinity> Chipzz: Some people still do.  I don't use either aptitude or dselect since apt's resolver is now good enough for me.
<infinity> Chipzz: But I always preferred dselect to aptitude before that.
<Darxus> infinity: Not certain, but how else could it have been installed?  The entire problem with aptitude was it choking on that package, and when I unleased apt-get on it, it switched it to the 64 bit version.
 * Chipzz also an apt-get user
<Chipzz> never really saw the need for aptitude and especially the dependencies it drags it
<Chipzz> esp on a server
<Chipzz> *in
<infinity> Darxus: Not entirely sure how update-manager (via libapt) could mess that up, except in the case of version skew.  And since you were upgrading to oneiric, there would have been no chance of that.
<Chipzz> ironically I have used apt-get dselect-upgrade for several years after I discovered it :P
<Darxus> infinity: Is there anything else I could've done to cause it?  Could an aptitude dist-upgrade have done it?
<infinity> Chipzz: Well, dselect-upgrade is only interesting if you also manipulate the status database by hand (or with dselect or dpkg --set-selections)
<infinity> Chipzz: Though, yeah, it's wildly handy to do batch "dpkg --set-selections" operations, followed by apt-get dselect-upgrade to make sure a proper resolver is checking your work. :)
<Chipzz> infinity: that, and dselect-upgrades also drags in recommends iirc
<Chipzz> or is it suggests? I always forget
<infinity> Darxus: aptitude perhaps could have broken it, yeah.  But I'm the wrong person to ask.  I know that aptitude is "very broken" with multiarch, just not in what sense.
<Chipzz> infinity: I recall dsu being the only way (that I knew of) to install recommends for quite a while
<Darxus> Wow.  Pulse audio volume control now goes over 100%.  That makes me so happy!
<penguin42> you can turn it up to 11 ?
<slangasek> Daviey: aptitude within d-i> not in a long time, why?
<Daviey> slangasek: I just wondered if it was still a valid use.
<Daviey> It's not something i hear of.
<slangasek> it's certainly something that could be revisited
<bkerensa> slangasek: I'm running into this when trying to edit a changelog "but this directory name does not match the package name according to theregex  PACKAGE(-.+)?."
<slangasek> what exactly are you doing?
<bkerensa> slangasek: dch -i  just trying to list my changes
<bkerensa> slangasek: you were the last person to work on this package from what I can see in the changelog
<slangasek> you're running 'dch -i' from within the package directory?
<bkerensa> slangasek: from source dir yes
<slangasek> what's the full error message?
<slangasek> (I've never seen this error from dch in my life, but maybe the full output will tell me what's happening :)
<bkerensa> slangasek: It seems to be a case of user error
<bkerensa> :)
<bkerensa> I was in package/src when I ran dch
<bkerensa> when I moved up one level it worked as expected
<slangasek> ah yes
<bkerensa> The package still seems a bit odd though
<bkerensa> for some reason the package name is "precise" even though it should be something else?
<bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/activity-log-manager/fix-for-943066/+merge/96896
<bkerensa> the package was activity-log-manager but when it came down the source dir was named "precise"
<Daviey> bkerensa: if you bzr branch lp:~ubuntu-branches/ubuntu/precise/PACKAGENAME/precise , it will make a precise directory
<Daviey> if you, bzr branch lp:ubuntu/PACKAGENAME , it'll make one with the package name
<happyface> anyone else getting lots of screen flickering in b1?
<bkerensa> Daviey: Ahh :)
<ScottK> Need more memory: g++ -Wl,--as-needed -Wl,--version-script,/build/buildd/qtwebkit-source-2.2.1/Source/symbols.filter -fuse-ld=gold -fuse-ld=gold -Wl,--no-undefined -fuse-ld=gold -Wl,-Bsymbolic-functions -Wl,-z,relro -shared -Wl,-soname,libQtWebKit.so.4 -o libQtWebKit.so.4.9.0 obj/release/MathMLNames.o obj/release/MathMLElementFactory.o obj/release/SVGNames.o obj/release/SVGElementFactory.o obj/release/JSSVGElementWrapperFactory.o
<ScottK> obj/release/XLinkNames.o obj/release/CSSPropertyNames.o obj/release/CSSValueKeywords.o obj/release/JSCounter.o obj/release/JSCSSCharsetRule.o obj/release/JSCSSFontFaceRule.o obj/release/JSCSSImportRule.o obj/release/JSCSSMediaRule.o obj/release/JSCSSPageRule.o obj/release/JSCSSPrimitiveValue.o obj/release/JSCSSRule.o obj/release/JSCSSRuleList.o obj/release/JSCSSStyleDeclaration.o obj/release/JSCSSStyleRule.o obj/release/JSCSSStyleSheet.o
<ScottK> obj/release/JSCSSValue.o obj/release/JSCSSValueList.o obj/release/JSMediaList.o obj/release/JSMediaQueryList.o obj/release/JSRect.o obj/release/JSRGBColor.o obj/release/JSStyleMedia.o obj/release/JSStyleSheet.o obj/release/JSStyleSheetList.o obj/release/JSWebKitCSSKeyframeRule.o obj/release/JSWebKitCSSKeyframesRule.o obj/release/JSWebKitCSSMatrix.o obj/release/JSWebKitCSSTransformValue.o obj/release/JSAttr.o obj/release/JSBeforeLoadEvent.o
<ScottK> obj/release/JSBeforeProcessEvent.o obj/release/JSCharacterData.o obj/release/JSClientRect.o obj/release/JSClientRectList.o obj/release/JSClipboard.o obj/release/JSCDATASection.o obj/release/JSComment.o obj/release/JSCompositionEvent.o obj/release/JSCustomEvent.o obj/release/JSDataTransferItem.o obj/release/JSDataTransferItems.o obj/release/JSDeviceMotionEvent.o obj/release/JSDeviceOrientationEvent.o obj/release/JSDocumentFragment.o
<ScottK> obj/release/JSDocument.o obj/release/JSDocumentType.o obj/release/JSDOMCoreException.o obj/release/JSDOMImplementation.o obj/release/JSDOMStringList.o obj/release/JSDOMStringMap.o obj/release/JSElement.o obj/release/JSEntity.o obj/release/JSEntityReference.o obj/release/JSErrorEvent.o obj/release/JSEvent.o obj/release/JSEventException.o obj/release/JSHashChangeEvent.o obj/release/JSKeyboardEvent.o obj/release/JSMouseEvent.o
<ScottK> obj/release/JSMessageChannel.o obj/release/JSMessageEvent.o obj/release/JSMessagePort.o obj/release/JSMutationEvent.o obj/release/JSNamedNodeMap.o obj/release/JSNode.o obj/release/JSNodeFilter.o obj/release/JSNodeIterator.o obj/release/JSNodeList.o obj/release/JSNotation.o obj/release/JSOverflowEvent.o obj/release/JSPageTransitionEvent.o obj/release/JSPopStateEvent.o obj/release/JSProcessingInstruction.o obj/release/JSProgressEvent.o
<ScottK> obj/release/JSRangeException.o obj/release/JSRange.o obj/release/JSStringCallback.o obj/release/JSText.o obj/release/JSTextEvent.o obj/release/JSTouch.o obj/release/JSTouchEvent.o obj/release/JSTouchList.o obj/release/JSTreeWalker.o obj/release/JSUIEvent.o obj/release/JSWebKitAnimationEvent.o obj/release/JSWebKitTransitionEvent.o obj/release/JSWheelEvent.o obj/release/JSBlob.o obj/release/JSDirectoryEntry.o obj/release/JSDirectoryEntrySync.o
<ScottK> obj/release/JSDirectoryReader.o obj/release/JSDirectoryReaderSync.o obj/release/JSDOMFileSystem.o obj/release/JSDOMFileSystemSync.o obj/release/JSEntriesCallback.o obj/release/JSEntry.o obj/release/JSEntryArray.o obj/release/JSEntryArraySync.o obj/release/JSEntryCallback.o obj/release/JSEntrySync.o obj/release/JSErrorCallback.o obj/release/JSFile.o obj/release/JSFileCallback.o obj/release/JSFileEntry.o obj/release/JSFileEntrySync.o
<ScottK> obj/release/JSFileError.o obj/release/JSFileException.o obj/release/JSFileList.o obj/release/JSFileReader.o obj/release/JSFileReaderSync.o obj/release/JSFileSystemCallback.o obj/release/JSFileWriter.o obj/release/JSFileWriterCallback.o obj/release/JSWebKitFlags.o obj/release/JSMetadata.o obj/release/JSMetadataCallback.o obj/release/JSWebKitBlobBuilder.o obj/release/JSArrayBufferView.o obj/release/JSArrayBuffer.o obj/release/JSDataView.o
<ScottK> obj/release/JSInt8Array.o obj/release/JSFloat32Array.o obj/release/JSCanvasGradient.o obj/release/JSInt32Array.o obj/release/JSCanvasPattern.o obj/release/JSCanvasRenderingContext.o obj/release/JSCanvasRenderingContext2D.o obj/release/JSOESStandardDerivatives.o obj/release/JSOESTextureFloat.o obj/release/JSOESVertexArrayObject.o obj/release/JSWebGLActiveInfo.o obj/release/JSWebGLBuffer.o obj/release/JSWebGLContextAttributes.o
<ScottK> obj/release/JSWebGLFramebuffer.o obj/release/JSWebGLProgram.o obj/release/JSWebGLRenderbuffer.o obj/release/JSWebGLRenderingContext.o obj/release/JSWebGLShader.o obj/release/JSInt16Array.o obj/release/JSWebGLTexture.o obj/release/JSWebGLUniformLocation.o obj/release/JSWebGLVertexArrayObjectOES.o obj/release/JSWebKitLoseContext.o obj/release/JSUint8Array.o obj/release/JSUint32Array.o obj/release/JSUint16Array.o obj/release/JSDOMFormData.o
<ScottK> obj/release/JSDOMSettableTokenList.o obj/release/JSDOMTokenList.o obj/release/JSDOMURL.o obj/release/JSHTMLAllCollection.o obj/release/JSHTMLAudioElement.o obj/release/JSHTMLAnchorElement.o obj/release/JSHTMLAppletElement.o obj/release/JSHTMLAreaElement.o obj/release/JSHTMLBaseElement.o obj/release/JSHTMLBaseFontElement.o obj/release/JSHTMLBlockquoteElement.o obj/release/JSHTMLBodyElement.o obj/release/JSHTMLBRElement.o
<ScottK> obj/release/JSHTMLButtonElement.o obj/release/JSHTMLCanvasElement.o obj/release/JSHTMLCollection.o obj/release/JSHTMLDataListElement.o obj/release/JSHTMLDetailsElement.o obj/release/JSHTMLDirectoryElement.o obj/release/JSHTMLDivElement.o obj/release/JSHTMLDListElement.o obj/release/JSHTMLDocument.o obj/release/JSHTMLElement.o obj/release/JSHTMLEmbedElement.o obj/release/JSHTMLFieldSetElement.o obj/release/JSHTMLFontElement.o
<ScottK> obj/release/JSHTMLFormElement.o obj/release/JSHTMLFrameElement.o obj/release/JSHTMLFrameSetElement.o obj/release/JSHTMLHeadElement.o obj/release/JSHTMLHeadingElement.o obj/release/JSHTMLHRElement.o obj/release/JSHTMLHtmlElement.o obj/release/JSHTMLIFrameElement.o obj/release/JSHTMLImageElement.o obj/release/JSHTMLInputElement.o obj/release/JSHTMLIsIndexElement.o obj/release/JSHTMLKeygenElement.o obj/release/JSHTMLLabelElement.o
<ScottK> obj/release/JSHTMLLegendElement.o obj/release/JSHTMLLIElement.o obj/release/JSHTMLLinkElement.o obj/release/JSHTMLMapElement.o obj/release/JSHTMLMarqueeElement.o obj/release/JSHTMLMediaElement.o obj/release/JSHTMLMenuElement.o obj/release/JSHTMLMetaElement.o obj/release/JSHTMLMeterElement.o obj/release/JSHTMLModElement.o obj/release/JSHTMLObjectElement.o obj/release/JSHTMLOListElement.o obj/release/JSHTMLOptGroupElement.o
<ScottK> obj/release/JSHTMLOptionElement.o obj/release/JSHTMLOptionsCollection.o obj/release/JSHTMLOutputElement.o obj/release/JSHTMLParagraphElement.o obj/release/JSHTMLParamElement.o obj/release/JSHTMLPreElement.o obj/release/JSHTMLProgressElement.o obj/release/JSHTMLQuoteElement.o obj/release/JSHTMLScriptElement.o obj/release/JSHTMLSelectElement.o obj/release/JSHTMLSourceElement.o obj/release/JSHTMLStyleElement.o obj/release/JSHTMLTableCaptionElement.
<ScottK> o obj/release/JSHTMLTableCellElement.o obj/release/JSHTMLTableColElement.o obj/release/JSHTMLTableElement.o obj/release/JSHTMLTableRowElement.o obj/release/JSHTMLTableSectionElement.o obj/release/JSHTMLTextAreaElement.o obj/release/JSHTMLTitleElement.o obj/release/JSHTMLTrackElement.o obj/release/JSHTMLUListElement.o obj/release/JSHTMLVideoElement.o obj/release/JSImageData.o obj/release/JSMediaError.o obj/release/JSTextMetrics.o
<ScottK> obj/release/JSTimeRanges.o obj/release/JSValidityState.o obj/release/JSVoidCallback.o obj/release/JSInjectedScriptHost.o obj/release/JSInspectorFrontendHost.o obj/release/JSJavaScriptCallFrame.o obj/release/JSScriptProfile.o obj/release/JSScriptProfileNode.o obj/release/JSDOMApplicationCache.o obj/release/JSNotification.o obj/release/JSNotificationCenter.o obj/release/JSBarInfo.o obj/release/JSConsole.o obj/release/JSCoordinates.o
<ScottK> obj/release/JSCrypto.o obj/release/JSDOMSelection.o obj/release/JSDOMWindow.o obj/release/JSEventSource.o obj/release/JSGeolocation.o obj/release/JSGeoposition.o obj/release/JSHistory.o obj/release/JSLocation.o obj/release/JSMemoryInfo.o obj/release/JSNavigator.o obj/release/JSNavigatorUserMediaError.o obj/release/JSNavigatorUserMediaErrorCallback.o obj/release/JSNavigatorUserMediaSuccessCallback.o obj/release/JSPerformance.o
<ScottK> obj/release/JSPerformanceNavigation.o obj/release/JSPerformanceTiming.o obj/release/JSPositionError.o obj/release/JSScreen.o obj/release/JSSpeechInputEvent.o obj/release/JSSpeechInputResult.o obj/release/JSSpeechInputResultList.o obj/release/JSWebKitAnimation.o obj/release/JSWebKitAnimationList.o obj/release/JSWebKitPoint.o obj/release/JSWorkerNavigator.o obj/release/JSDOMPlugin.o obj/release/JSDOMMimeType.o obj/release/JSDOMPluginArray.o
<ScottK> obj/release/JSDOMMimeTypeArray.o obj/release/JSDatabase.o obj/release/JSDatabaseCallback.o obj/release/JSDatabaseSync.o obj/release/JSIDBAny.o obj/release/JSIDBCursor.o obj/release/JSIDBDatabaseError.o obj/release/JSIDBDatabaseException.o obj/release/JSIDBDatabase.o obj/release/JSIDBFactory.o obj/release/JSIDBIndex.o obj/release/JSIDBKey.o obj/release/JSIDBKeyRange.o obj/release/JSIDBObjectStore.o obj/release/JSIDBRequest.o
<ScottK> obj/release/JSIDBTransaction.o obj/release/JSStorage.o obj/release/JSStorageEvent.o obj/release/JSStorageInfo.o obj/release/JSStorageInfoErrorCallback.o obj/release/JSStorageInfoUsageCallback.o obj/release/JSSQLError.o obj/release/JSSQLException.o obj/release/JSSQLResultSet.o obj/release/JSSQLResultSetRowList.o obj/release/JSSQLStatementCallback.o obj/release/JSSQLStatementErrorCallback.o obj/release/JSSQLTransaction.o
<ScottK> obj/release/JSSQLTransactionCallback.o obj/release/JSSQLTransactionErrorCallback.o obj/release/JSSQLTransactionSync.o obj/release/JSSQLTransactionSyncCallback.o obj/release/JSSVGZoomEvent.o obj/release/JSSVGAElement.o obj/release/JSSVGAltGlyphElement.o obj/release/JSSVGAngle.o obj/release/JSSVGAnimateColorElement.o obj/release/JSSVGAnimatedAngle.o obj/release/JSSVGAnimatedBoolean.o obj/release/JSSVGAnimatedEnumeration.o
<ScottK> obj/release/JSSVGAnimatedInteger.o obj/release/JSSVGAnimatedLength.o obj/release/JSSVGAnimatedLengthList.o obj/release/JSSVGAnimatedNumber.o obj/release/JSSVGAnimatedNumberList.o obj/release/JSSVGAnimatedPreserveAspectRatio.o obj/release/JSSVGAnimatedRect.o obj/release/JSSVGAnimatedString.o obj/release/JSSVGAnimatedTransformList.o obj/release/JSSVGAnimateElement.o obj/release/JSSVGAnimateTransformElement.o obj/release/JSSVGAnimationElement.o
<ScottK> obj/release/JSSVGCircleElement.o obj/release/JSSVGClipPathElement.o obj/release/JSSVGColor.o obj/release/JSSVGComponentTransferFunctionElement.o obj/release/JSSVGCursorElement.o obj/release/JSSVGDefsElement.o obj/release/JSSVGDescElement.o obj/release/JSSVGDocument.o obj/release/JSSVGElement.o obj/release/JSSVGElementInstance.o obj/release/JSSVGElementInstanceList.o obj/release/JSSVGEllipseElement.o obj/release/JSSVGException.o
<ScottK> obj/release/JSSVGFEBlendElement.o obj/release/JSSVGFEColorMatrixElement.o obj/release/JSSVGFEComponentTransferElement.o obj/release/JSSVGFECompositeElement.o obj/release/JSSVGFEConvolveMatrixElement.o obj/release/JSSVGFEDiffuseLightingElement.o obj/release/JSSVGFEDisplacementMapElement.o obj/release/JSSVGFEDistantLightElement.o obj/release/JSSVGFEDropShadowElement.o obj/release/JSSVGFEFloodElement.o obj/release/JSSVGFEFuncAElement.o
<ScottK> obj/release/JSSVGFEFuncBElement.o obj/release/JSSVGFEFuncGElement.o obj/release/JSSVGFEFuncRElement.o obj/release/JSSVGFEGaussianBlurElement.o obj/release/JSSVGFEImageElement.o obj/release/JSSVGFEMergeElement.o obj/release/JSSVGFEMergeNodeElement.o obj/release/JSSVGFEMorphologyElement.o obj/release/JSSVGFEOffsetElement.o obj/release/JSSVGFEPointLightElement.o obj/release/JSSVGFESpecularLightingElement.o obj/release/JSSVGFESpotLightElement.o
<ScottK> obj/release/JSSVGFETileElement.o obj/release/JSSVGFETurbulenceElement.o obj/release/JSSVGFilterElement.o obj/release/JSSVGFontElement.o obj/release/JSSVGFontFaceElement.o obj/release/JSSVGFontFaceFormatElement.o obj/release/JSSVGFontFaceNameElement.o obj/release/JSSVGFontFaceSrcElement.o obj/release/JSSVGFontFaceUriElement.o obj/release/JSSVGForeignObjectElement.o obj/release/JSSVGGElement.o obj/release/JSSVGGlyphElement.o
<ScottK> obj/release/JSSVGGradientElement.o obj/release/JSSVGHKernElement.o obj/release/JSSVGImageElement.o obj/release/JSSVGLength.o obj/release/JSSVGLengthList.o obj/release/JSSVGLinearGradientElement.o obj/release/JSSVGLineElement.o obj/release/JSSVGMarkerElement.o obj/release/JSSVGMaskElement.o obj/release/JSSVGMatrix.o obj/release/JSSVGMetadataElement.o obj/release/JSSVGMissingGlyphElement.o obj/release/JSSVGNumber.o obj/release/JSSVGNumberList.o
<ScottK> obj/release/JSSVGPaint.o obj/release/JSSVGPathElement.o obj/release/JSSVGPathSegArcAbs.o obj/release/JSSVGPathSegArcRel.o obj/release/JSSVGPathSegClosePath.o obj/release/JSSVGPathSegCurvetoCubicAbs.o obj/release/JSSVGPathSegCurvetoCubicRel.o obj/release/JSSVGPathSegCurvetoCubicSmoothAbs.o obj/release/JSSVGPathSegCurvetoCubicSmoothRel.o obj/release/JSSVGPathSegCurvetoQuadraticAbs.o obj/release/JSSVGPathSegCurvetoQuadraticRel.o
<ScottK> obj/release/JSSVGPathSegCurvetoQuadraticSmoothAbs.o obj/release/JSSVGPathSegCurvetoQuadraticSmoothRel.o obj/release/JSSVGPathSeg.o obj/release/JSSVGPathSegLinetoAbs.o obj/release/JSSVGPathSegLinetoHorizontalAbs.o obj/release/JSSVGPathSegLinetoHorizontalRel.o obj/release/JSSVGPathSegLinetoRel.o obj/release/JSSVGPathSegLinetoVerticalAbs.o obj/release/JSSVGPathSegLinetoVerticalRel.o obj/release/JSSVGPathSegList.o obj/release/JSSVGPathSegMovetoAbs.o
<ScottK>  obj/release/JSSVGPathSegMovetoRel.o obj/release/JSSVGPatternElement.o obj/release/JSSVGPoint.o obj/release/JSSVGPointList.o obj/release/JSSVGPolygonElement.o obj/release/JSSVGPolylineElement.o obj/release/JSSVGPreserveAspectRatio.o obj/release/JSSVGRadialGradientElement.o obj/release/JSSVGRectElement.o obj/release/JSSVGRect.o obj/release/JSSVGRenderingIntent.o obj/release/JSSVGScriptElement.o obj/release/JSSVGSetElement.o
<ScottK> obj/release/JSSVGStopElement.o obj/release/JSSVGStringList.o obj/release/JSSVGStyleElement.o obj/release/JSSVGSVGElement.o obj/release/JSSVGSwitchElement.o obj/release/JSSVGSymbolElement.o obj/release/JSSVGTextContentElement.o obj/release/JSSVGTextElement.o obj/release/JSSVGTextPathElement.o obj/release/JSSVGTextPositioningElement.o obj/release/JSSVGTitleElement.o obj/release/JSSVGTransform.o obj/release/JSSVGTransformList.o
<ScottK> obj/release/JSSVGTRefElement.o obj/release/JSSVGTSpanElement.o obj/release/JSSVGUnitTypes.o obj/release/JSSVGUseElement.o obj/release/JSSVGViewElement.o obj/release/JSSVGVKernElement.o obj/release/JSInternals.o obj/release/JSAudioBuffer.o obj/release/JSAudioBufferSourceNode.o obj/release/JSAudioChannelMerger.o obj/release/JSAudioChannelSplitter.o obj/release/JSAudioContext.o obj/release/JSAudioDestinationNode.o obj/release/JSAudioGain.o
<ScottK> obj/release/JSAudioGainNode.o obj/release/JSAudioListener.o obj/release/JSAudioNode.o obj/release/JSAudioPannerNode.o obj/release/JSAudioParam.o obj/release/JSAudioProcessingEvent.o obj/release/JSAudioSourceNode.o obj/release/JSConvolverNode.o obj/release/JSDelayNode.o obj/release/JSHighPass2FilterNode.o obj/release/JSJavaScriptAudioNode.o obj/release/JSLowPass2FilterNode.o obj/release/JSRealtimeAnalyserNode.o obj/release/JSWebSocket.o
<ScottK> obj/release/JSAbstractWorker.o obj/release/JSDedicatedWorkerContext.o obj/release/JSSharedWorker.o obj/release/JSSharedWorkerContext.o obj/release/JSWorker.o obj/release/JSWorkerContext.o obj/release/JSWorkerLocation.o obj/release/JSDOMParser.o obj/release/JSXMLHttpRequest.o obj/release/JSXMLHttpRequestException.o obj/release/JSXMLHttpRequestProgressEvent.o obj/release/JSXMLHttpRequestUpload.o obj/release/JSXMLSerializer.o
<Daviey> ScottK: ?!
<ScottK> obj/release/JSXPathNSResolver.o obj/release/JSXPathException.o obj/release/JSXPathExpression.o obj/release/JSXPathResult.o obj/release/JSXPathEvaluator.o obj/release/JSXSLTProcessor.o obj/release/InspectorFrontend.o obj/release/InspectorBackendDispatcher.o obj/release/CSSGrammar.o obj/release/HTMLNames.o obj/release/HTMLElementFactory.o obj/release/JSHTMLElementWrapperFactory.o obj/release/XMLNSNames.o obj/release/XMLNames.o
<ScottK> obj/release/HTMLEntityTable.o obj/release/DocTypeStrings.o obj/release/ColorData.o obj/release/UserAgentStyleSheetsData.o obj/release/XPathGrammar.o obj/release/qwebframe.o obj/release/qgraphicswebview.o obj/release/qwebpage.o obj/release/qwebview.o obj/release/qwebelement.o obj/release/qwebhistory.o obj/release/qwebsettings.o obj/release/qwebhistoryinterface.o obj/release/qwebplugindatabase.o obj/release/qwebpluginfactory.o
<ScottK> obj/release/qwebsecurityorigin.o obj/release/qwebscriptworld.o obj/release/qwebdatabase.o obj/release/qwebinspector.o obj/release/qwebkitversion.o obj/release/QtFallbackWebPopup.o obj/release/ChromeClientQt.o obj/release/ContextMenuClientQt.o obj/release/DragClientQt.o obj/release/DumpRenderTreeSupportQt.o obj/release/EditorClientQt.o obj/release/EditCommandQt.o obj/release/FrameLoaderClientQt.o obj/release/FrameNetworkingContextQt.o
<ScottK> obj/release/GeolocationPermissionClientQt.o obj/release/InspectorClientQt.o obj/release/InspectorServerQt.o obj/release/NotificationPresenterClientQt.o obj/release/PageClientQt.o obj/release/PopupMenuQt.o obj/release/QtPlatformPlugin.o obj/release/SearchPopupMenuQt.o obj/release/WebPlatformStrategies.o obj/release/FullScreenVideoQt.o obj/release/IconDatabaseClientQt.o obj/release/moc_qwebkitplatformplugin.o obj/release/moc_qwebhistoryinterface.o
<ScottK>  obj/release/moc_qwebpluginfactory.o obj/release/moc_qwebinspector.o obj/release/moc_qwebplugindatabase_p.o obj/release/moc_InspectorServerQt.o obj/release/moc_QtFallbackWebPopup.o obj/release/moc_FullScreenVideoQt.o obj/release/qrc_WebCore.o obj/release/qrc_WebKit.o obj/release/qrc_InspectorBackendStub.o   -L../../WebCore/release -L../../JavaScriptCore/release -L/usr/X11R6/lib -L/usr/lib/arm-linux-gnueabihf -lwebcore -ljscore -lsqlite3 -
<ScottK> lXrender -lgio-2.0 -lgstapp-0.10 -lgstinterfaces-0.10 -lgstpbutils-0.10 -pthread -lgstvideo-0.10 -lgstbase-0.10 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -lQtGui -lQtNetwork -lQtCore -lpthread -lXext -lX11 -lm
<ScottK> /usr/bin/ld: final link failed: Memory exhausted
<ScottK> Oops.
<ScottK> Sorry.
<ScottK> infinity: Help.
<ScottK> Almost got QtWebKit to build on armhf.
<ScottK> Needs MOAR RAM.
#ubuntu-devel 2012-03-11
<happyface> anyone else experiencing screen flickering in the beta?
<infinity> ScottK: How is that different than the situation's been for the last month? :)
<happyface> anyone else experiencing screen flickering in the beta?
<micahg> ScottK: have you tried build qtwebkit with -Wl,--no-keep-memory?  that worked for webkitgtk
<infinity> micahg: Ooo, I wasn't aware of that linker flag.
<infinity> micahg: I'm betting that would do it.
 * infinity headdesks.
<infinity> And the upload that updated the symbols for armel didn't add armhf at the same time.
<infinity> That's easy enough to fix, at least.
<infinity> ScottK: I'll try micahg's suggestion on my Panda.
<infinity> ... after I find an SD that actually has an OS on it.
<infinity> shadeslayer: Don't worry about qtwebkit-source on armhf, I have a testbuild going right now, and will upload in the morning, I suspect.
<infinity> micahg: So, looking at the actual packaging for this might have been helpful, instead of people blaming toolchains and kernels.
<infinity> micahg: My guess is that armel being built with -gstabs, and armhf being built with -g might relate (testing that theory now).
<micahg> infinity: heh, we just made the change recently
<infinity> micahg: Your suggestion is probably also a valid an reasonable one, given the borderline memory usage issues of all things webkit.
<infinity> micahg: But I'm betting that "make armhf build the same way as armel" will magically fix it.
 * infinity really needs to rgrep for armel in debian/rules across an entire lintian lab. :/
 * micahg isn't sure what -gstabs does
<infinity> micahg: Different debugging format.
<infinity> Aside from being less verbose than DWARF2 (which could explain the difference in memory usage), it's also apparently causing other issues on some platforms with qtwebkit, which was why it was swapped.
<infinity> I dunno.
<infinity> Not my package.
<infinity> But if this fix works, I'll be kicking myself for not just looking at debian/rules 2 months ago.
<micahg> infinity: I did the same thing with chromium except it was something in debian/control that was the final fix
<infinity> Just needed an s/armel/armel armhf/ ?
<micahg> infinity: yep :)
<infinity> Yeah, I suspect there are a lot of those left in the archive in some form or another.
<infinity> Hence the lintian lab mention.
<micahg> infinity: talk to broder, he might be able to help
<bkerensa> Getting a weird error when trying to bzr branch bash
<bkerensa> bzr: ERROR: Revision {steve.langasek@canonical.com-20111106190907-jzcpeo7ol1yuyip3} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<bkerensa> <bkerensa> "
<infinity> Pretty.
<bkerensa> indeed
<bkerensa> :P
<infinity> If at first you don't succeed, screw it and work on the source package directly? ;)
<ScottK> micahg and infinity: thanls.
 * infinity wonders how all those builders landed in ABORTED...
<AnAnt> Hello, would someone sponsor: LP 946660
<ubottu> Launchpad bug 946660 in fuse (Ubuntu) "Remove loop-aes-utils from Conflicts" [Undecided,Confirmed] https://launchpad.net/bugs/946660
<verwilst> SpamapS, hello, wrt https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54,is php 5.4 still on track for precise inclusion?
<geser> pitti: re your comment on bug #871907: sorry for causing you trouble with this change. As it also causes problems with colorscheme I'm undoing it. Have you time to sponsor the debdiff from bug #951440?
<ubottu> Launchpad bug 871907 in vim (Ubuntu) "vim should have "set bg=dark" by default" [Wishlist,Fix released] https://launchpad.net/bugs/871907
<ubottu> Launchpad bug 951440 in vim (Ubuntu) "vim-gnome ignores colorscheme setting from vimrc" [Undecided,Confirmed] https://launchpad.net/bugs/951440
<mikecb> ScottK: have you tried with -no-keep-memory, --hash-size, or --reduce-memory-overhead?
<dupondje> pitti: I have some work in progress to split up cryptsetup in a bin package. Would it be on time to get in Precise? Or to late anyway?
<geser> dupondje: how confident are you that you don't break anything (e.g. upgrades)? as there isn't much time left to test it thoroughly
<dupondje> geser: maby cryptsetup could provide cryptsetup-bin, and just copy the bins to a new package 'cryptsetup-bin' to make it safer ?
<geser> dupondje: what issue are you trying to fix?
<dupondje> geser: if you connect a crypted device to an ubuntu pc without cryptsetup, it asks a password, but can't open it, because its missing cryptsetup.
<dupondje> installing cryptsetup as a whole is not an option, because it contains some initramfs scripts etc, which are not needed in this case
<geser> so you plan to move the binaries into an own package and let cryptsetup depend on it?
<dupondje> 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]
<geser> sounds like it should be safe to not break existing cryptsetup installs
<geser> dupondje: not sure about the timing, don't have enough expierence with judging such changes that late in the release cycle, luckily there is #ubuntu-release :)
<dupondje> the critical in cryptsetup is also fixed in the next upload in debian :)
<tiagoscd> hi
<tiagoscd> I tried to create a package from lp:ubiquity, but when I use "debuild -us -uc" I have this error: http://paste.ubuntu.com/879353/
<tiagoscd> Can anyone help me?
<infinity> tiagoscd: debian/rules update
<tiagoscd> infinity, thanks. could you tell me why I need to update the rules? (sorry, starting with devel)
<alexbligh1> A wierd one: can I make debian/rules produce not only the normal example.deb, but a second example2.deb which contains example.deb (in /foo/bar/baz/example.deb). Or has rules stopped before the final .deb is generated?
<infinity> alexbligh1: It's conceivably possible to wrap a deb in a deb from the same source package, but the better question is "why"?
<alexbligh1> infinity, I have nodes that tftpboot an ubuntu distribution, and then suck various other .debs over http. I want to put those .debs themselves (which are only installed on the nodes) in a package installed on the server. I'm currently manually doing this (i.e. copying the built .debs into the source repository) which is error prone, so I already have .debs in .debs
<alexbligh1> What I want to do is when I build the inner .deb, make an outer .deb too, and make the package on the server depend upon that.
<alexbligh1> (I bet you wish you never asked)
<infinity> alexbligh1: It's certainly not how I'd do it, but to each their own.  If this monstrosity is for local use, not for the archive. :P
<alexbligh1> infinity, no, not for the archive. I should explain the nodes are diskless, and the server acts like a sort of real time repository. That might help it make more sense.
<alexbligh1> um, boot time repository
<infinity> alexbligh1: But the short answer is that you could just mv inner.deb into debian/outer/usr/share/outer/inner.deb between dh_builddeb -pinner and dh_buildder -pouter
<infinity> And perhaps some tricker to remove the original deb from list.
<alexbligh1> Ah, so dh_builddeb is actually called from rules, and that's (the -pinner bit) what makes the .deb
<infinity> alexbligh1: Yeah, I realise what you're doing.  I'd just publish it all in one repo, however, rather than making debs contain mini repositories.
<alexbligh1> infinity, thanks - I'll have a think
<ScottK> mikecb: No.  I haven't tried with any of those.  Since I don't have direct access to an Ubuntu armhf box, I hope infinity will try out some of those options and see if it helps.
<ScottK> infinity: Would you also please take a look at nihal.  The kdevelop build has been stuck at fully built for over half a day.
<infinity> ScottK: Was the response to mikecb about qtwekbit-source?  If so, I've uploaded a package that should build fine.
<infinity> ScottK: As for nihal, has it been stuck at that "purging chroot" step?
<infinity> ScottK: If so, I'll have to poke people about it tomorrow, I haven't had direct access to buildds for years.
<dupondje> slangasek: there atm ?
<ScottK> infinity: It was and it is, so thanks on both counts.
<infinity> ScottK: Yeah, I feel a bit dumb about qtwebkit-source.  We spent so long hunting kernel (and there was a kernel bug) and toolchain issues, that I didn't even stop to look at debian/rules and apply the s/armel/armel armhf/ fix. :P
<ScottK> infinity: I'm glad you finally got it sorted. I didn't either, so don't feel bad.
<apw> i think one of our builds may have gotten stuck: https://launchpad.net/ubuntu/+source/linux/3.2.0-18.29/+build/3272981 ... i wonder if a buildd admin could check up on it
<infinity> apw: I think there was a network hiccup that confused the crap out of a bunch of buildds.
<infinity> apw: Can't do much about it until the relevant people are at work on Monday.
<apw> infinity, ok ... thanks for looking ...
<scientes> can i install systemd on ubuntu?
<scientes> on precise
<scientes> I want the udev device enumeration for multiseat stuff
<Darxus> Update Manager just hung on me.  Running Oneric.  About half way through applying changes.  Details only says "/tmp/tmprAyyZx" which seems pretty wrong.
<Darxus> That file contains a list of what the updates are.
<Darxus> Is this some incompatability with update manager and that annoying thing that tells me the details of the upgrade?  What is that?
<Darxus> Cancel button is greyed out.
<Darxus> Wow, the details is actually an interactive console?  Neat.
<infinity> Darxus: Expand it a bit, and scroll back with Shift-PgUp.
<infinity> Darxus: If I had to guess, I'd say you have apt-listchanges installed, and it's patiently waiting for you to 'q' out of less, and say "yes" to the upgrade.
<Darxus> It's gone, sorry.
<infinity> Darxus: apt-listchanges and update-manager don't play well together. :/
<Darxus> Yep, I agree.
<Darxus> Yeah.
<infinity> I really should look at fixing that.  My solution was just to uninstall it from GUI systems and only use it on servers.
<Darxus> You don't think that qualifies as a bug?
<Darxus> Heh, yeah.
<infinity> But I swear it used to do sane things (ie: pop a GTK dialog instead of a pager in the terminal window)
<Darxus> Heh.
<infinity> Darxus: There's a bug open, don't recall the number.  Just that no one's made it a priority.
<Darxus> I just uninstalled it.
<Darxus> Okay, thanks.
<Darxus> The bug is https://bugs.launchpad.net/ubuntu/+source/apt-listchanges/+bug/787802
<ubottu> Launchpad bug 787802 in apt-listchanges (Ubuntu) "Update Manager hangs waiting for response to apt-listchanges hidden under Details" [Undecided,Confirmed]
<infinity> Yeah.  There may also be an update-manager bug.
<infinity> Anyhow, I might see about making time for it.  It's annoyed me for a long time.
<infinity> But "uninstall apt-listchanges on GUI systems" is a fair workaround.
<infinity> Since you can see changelogs in the u-m window anyway.
<Darxus> Yeah.
<Darxus> Honestly, that thing has caused me more grief than anything.  By making it one step easier to forget to confirm an upgrade.
<Darxus> "update-manager used to invoke the GTK frontend of apt-listchanges"
<infinity> Yeah.  Maybe this is the cycle where it annoys me enough to figure out why it's broken.
<Darxus> infinity: Neat :)
#ubuntu-devel 2013-03-04
<melodie> Chipzz thanks!
<Andy80> hi
<Andy80> I'm sorry to ask this, but what's happening to ubuntu-devel mailing list?
<Andy80> I'm getting TONS of email since a couple of hours
<Andy80> and I cannot stop them
<Andy80> I've tried unsubscribing from ubuntu-devel ml and I'm still getting them
<ogra_> there were 10 mails today on that list
<Andy80> really I'm getting tons of them
<Andy80> I don't know if these are just delayed emails and I'm getting them all at once
<Andy80> but it's being very bad
<ogra_> sounds more like a problem with your mailserver
<Andy80> ogra_, https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/thread.html looking at the archive it seems the emails are a lot... anyway I'm using GMail, surely I can't fix it
<cjohnston_> Andy80: over the past couple of days the list has 'blown up' in response to a proposal that was made
<ogra_> not sure what you define a lot
<Andy80> ogra_, I'm getting an email every 5-10 seconds
<ogra_> right, there was some discussion, surely not what i define a lot though
<Andy80> I didn't check if they're duplicated or not
<Andy80> but it looks like they're not stopping
<cjohnston_> I'd say there has been 100+ since Thursday.  5-10 seconds though is not what I'm seeing..
<Andy80> I just marked everything as read and archived, and now I've other 6 emails :(
<Andy80> I'm not joking, really :(
<cjohnston_> Andy80: try checking a couple of them and see if your just very delayed in getting the emails that I've been getting over the last few days
<Andy80> I will try to monitor the next I get
<geofft> Andy80: you're not the only person I've heard who's getting the mails all at once
<Andy80> geofft, do you know if those people were using GMail aswell?
<ogra_> i'm actually forwarding that list through gmail and have no delays
<cjwatson> If you need sysadmin help, you'd need to try #canonical-sysadmin; the greatest access level you're likely to find here is that of list moderator, which isn't sufficient to debug this kind of thing
<ogra_> (gets me cheap spam filtering to hook gmail in the loop)
<Andy80> cjohnston_, thanks! If I keep getting emails I will try to ask there if anyone can investigate (maybe at the moment nobody is working, better tomorrow)
<geofft> Andy80: I suspect so.
<cjwatson> You might find the start of the APAC shift
<melodie> good night
<jbicha> I stopped receiving ubuntu-devel emails several days ago, so I resubscribed to the list but started getting the missing emails a few hours ago too (also on gmail)
<Andy80> jbicha, it looks like a common problem then :)
<Andy80> time to go to bed now ;)
<Andy80> see you all!
<lifeless> SpamapS: ^ could have been what happpened to you ?
<SpamapS> lifeless: indeed, though I have not seen any of the old ones arrive just yet
<SpamapS> lifeless: and they definitely stopped on my last day at canonical.. so my guess is that it was some kind of sweep for my email/name that was too broad
<SpamapS> or I was more bitter than I remember, and I did it and forgot ;)
<infinity> SpamapS: Hah.  Probably just overbroad.  Or you were subscribed via you canonical.com address?
<infinity> s/you/your/
<SpamapS> I am 99.9% sure I subscribed w/ my @ubuntu.com email
<SpamapS> but, there was some trouble with that particular email...
<broder> i did not, fwiw, so probably not an @ubuntu.com issue
<SpamapS> because I used clint@ .. but my launchpad id was clint-fewbar .. so I was sort of abusing my canonical username
<SpamapS> I resolved that before my last day, but its entirely possible the sweep and the special forwarding privileges I got were not compatible
<infinity> SpamapS: *nod*
<bradm> gmail decided it didn't want to talk to our mail server for a little while after we upgraded it
<bradm> SpamapS: fwiw, your clint@ address is still subscribed, and mail is being delivered to it.
<SpamapS> bradm: I re-subscribed earlier today
<SpamapS> bradm: at which time the emails started flowing again
<bradm> SpamapS: if you're not on gmail, days ago.
<SpamapS> my MX is a barracuda run by my friend's hosting company
<SpamapS> but again, the ubuntu-devel emails stopped basically the day I departed Canonical, so I'm pretty sure either I unsubbed, or something went wonky
<bradm> SpamapS: you were on ubuntu-devel with your @canonical.com address
<SpamapS> bradm: *DOH*
<SpamapS> bradm: thanks for checking
<bradm> SpamapS: no worries.
<pitti_> Good morning
<pitti> ricotz: FYI, I uploaded https://launchpad.net/ubuntu/+source/udisks2/2.0.92-0ubuntu1 to raring, with a proper port of the "mount in /media" patch
<ricotz> pitti, alright, thanks
<dholbach> good morning
<Quintasan> Hello
<tkamppeter> Is there somewhere documentation about how to participate in the sessions of the UDS?
<Riddell> tkamppeter: http://summit.ubuntu.com/uds-1303/2013-03-05/ has links to videos and irc rooms
<Riddell> but I can't find anything about how to use google hangouts
<tumbleweed> tkamppeter: someone mentioned https://wiki.ubuntu.com/OnAir/BestPractices on the planet
<Laney> "The required participants for a meeting will also be given a link to participate in the hangout"
<Laney> hmm
<xnox> Laney: yeah, I don't like that. I did use required participation - only to force the scheduler to be sensible.
<xnox> as well as to subscribe other people.
<Laney> Unfortunate constraints imposed by the technology
<xnox> Laney: all our base are belong to G+ ?
<Laney> something like that
<ogra_> better than to facebook :)
<zyga> hey
<zyga> update-manager is borked on raring as on version 1:0.183
<zyga> someone might want to figure out an interesting fix
<zyga> http://pastebin.ubuntu.com/5584706/
<zyga> dholbach: do you know who maintains update-manager after mvo left?
<dholbach> zyga, might be good to ask mvo directly - he's still on IRC you know :)
<zyga> mvo: ping?
<zyga> dholbach: yeah but he's not required to be here anymore
<zyga> pitti: perhaps you know (unless mvo is faster) ^^
<dholbach> well he's still part of the Ubuntu and Debian projects
<Laney> have you filed a bug?
<zyga> Laney: filing
<zyga> it's a bit tricky
<zyga> since ubuntu-bug rejects the bug :)
<zyga> as updates are available
 * zyga thinks that's an interesting exception where we should still be able to do so
<pitti> zyga: the two error messages look fairly self-explanatory?
<zyga> pitti: yes, they od
<zyga> do
<zyga> ok, filed as https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1144058
<ubottu> Launchpad bug 1144058 in update-manager (Ubuntu) "update-manager crashes with nboundLocalError: local variable 'installed_file' referenced before assignment" [Undecided,New]
<ivanka> hey seb128, have you got a sec?
<seb128> ivanka, hey, sure
<ivanka> seb128, how do I find what blueprints are being registered for this week?
<seb128> ivanka, https://blueprints.launchpad.net/sprints/uds-1303
<ivanka> seb128, sorry, there is probably an email buried in my inbox but was at MWC and still trying to catch up
<mvo> zyga: hi, sorry for the delay - its group maintained AIUI, mterry is doing quite a bit of work on it too
<seb128> ivanka, or just check the schedule http://summit.ubuntu.com/uds-1303/2013-03-05/display?edit and http://summit.ubuntu.com/uds-1303/2013-03-06/display?edit
<seb128> ups
<seb128> without the edit part
<seb128> http://summit.ubuntu.com/uds-1303/2013-03-05/display
<seb128> ivanka, let me know if need more details
<seb128> ivanka, do you have sessions to add? the schedule is pretty packaged already, we had to make call on stuffs to drop from the list for client
<ivanka> thanks seb128 - that should keep me quiet for the moment
<seb128> ivanka, the community track might have some free slots still though
<ivanka> seb128, I will have a look, but I spoke to pmcgowan before MWC and he suggested that the focus for the first UDS will be on fixes and background stuff so I get some time to prioritise UI elements
<seb128> ok
<zyga> mvo: hey, thanks for getting back to me
<ivanka> seb128, we are just getting back the usability testing results and need to look at what design changes we need to make
<ivanka> seb128, off to check the schedule! :-)
<seb128> ivanka, good luck!
<seb128> ;-)
<ivanka> hey ckpringle there is a UDS session for app development
<ivanka> ckpringle, I am subscribing you and making your participation essential
<ivanka> ckpringle, I shall add Christina too? Mika? Anyone else?
<ckpringle> ivanka: I think that is the session dpm is organising, we spoke about it last week but do you know when exactly it will be?
<ckpringle> ivanka: the three of us would be nice, if we can't all go I at least will though.
<ivanka> ckpringle, xchat just crashed on me! OK - will add the others
<ivanka> ckpringle, I think it is one of the early sessions http://summit.ubuntu.com/uds-1303/2013-03-05/display
<ivanka> ckpringle, as long as the sessions don't move too much
<ckpringle> ivanka: there is also one at 6pm
<ckpringle> ivanka "Ubuntu touch core apps project"
<dpm> ckpringle, ivanka, the schedule is still a bit in flux, as we're populating it right now, and some sessions will need to be reshuffled if they clash with others with the same essential participants. Let me come back to you guys later on on the design sessions
<ivanka> dpm, I am am just assigning people to Blueprints so, if they can't attend that can still contribute discussion points.
<dpm> ivanka, excellent, sounds good
<ivanka> seb128, what's Ubuntu Friendly?
<seb128> ivanka, https://friendly.ubuntu.com/what-is-ubuntu-friendly/
<seb128> ;-)
<ivanka> seb128, oooh nice
<ivanka> xnox, hi
<ivanka> dpm, who is in charge of the schedule?
<dpm> ivanka, there is a track lead for each track in charge of the schedule. For app development I am, then seb128 and jasoncwarner_ are for client, Daviey for server... etc.
<dpm> sorry there are 2 track leads I meant to say
<dpm> popey and I for app development, etc, etc
<ivanka> dpm, great, thanks
<dpm> Let me see if I can get you the full list
<dpm> ok
<ivanka> dpm, sorry, I am frantically trying to catchup as I was at MWC  last week
<dpm> ivanka, no worries, happy to help in what I can
<ivanka> thanks dpm
<dpm> us who weren't in MWC are also frantically catching up at the pace things are running now ;)
<melodie> hi
<melodie> hello
<melodie> I am trying to learn how to use gfxboot-examples in order to get a custom /isolinux/bootsplash archive with a init file in it containing a custom 800x600 jpg image. I read the examples, but when it comes to putting this in practice I am stucked with questions (the exemple is not clear enough to me).
<melodie> I have also read this post: https://lists.ubuntu.com/archives/ubuntu-devel/2005-December/013846.html
<melodie> and I wonder if someone here could help me understand how to use the exemple the right way ?
<melodie> this is in Ubuntu Precise
<bdrung> dholbach: re bug #1140613, please unsubscribe the sponsors team and set the bug to 'fix committed'
<ubottu> bug 1140613 in python-warlock (Ubuntu) "Merge python-warlock 0.8.1-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1140613
<bdrung> dholbach: and this package has a dependency wait
<dholbach> hum, weird - let me have another look
<melodie_> hi, how are the official ubuntu versions creating their isolinux/bootlogo file ?
<melodie_> I ask because I tried https://bugs.launchpad.net/ubuntu/+source/gfxboot-examples/+bug/1077339
<ubottu> Launchpad bug 1077339 in gfxboot-examples (Ubuntu) "gfxboot examples fail to run" [Undecided,New]
<melodie_> and it fails
<melodie_> I would just want to change the color there: http://askubuntu.com/questions/10258/how-to-change-live-cd-splash-screen
<melodie_> same as the one who posted : I can change the first screen but not the following, even after unpacking initrd.lz and changing the ubuntu-plymouth-text "black" hexa code line
<melodie_> and recreating it
<melodie_> it shows only one very small second at shutdown, but none at reboot, so I supposed the guilty one is located in bootlogo (init file) ?
<cjwatson> it's built by the gfxboot-theme-ubuntu package
<cjwatson> gfxboot-examples is of little interest to me
<melodie_> hello cjwatson
<melodie_> is there a tutorial somewhere ? I have also installed gfxboot-theme-ubuntu package in my ubuntu precise host, and I seem to be unable to find a howto
<cjwatson> no
<cjwatson> at least not afaik
<melodie_> :-(
<melodie_> perhaps if I change the hex color code in a *.inc file there and use a "make" command ?
<melodie_> I can copy the content of the gfxboot-theme-ubuntu directory to /tmp and do tests there
<cjwatson> in general you should start from the gfxboot-theme-ubuntu source package and not from any other version of it, certainly
<cjwatson> it's a standard-Debian-format source package so you can build it in the usual way
<melodie_> I am not yet used to packaging
<melodie_> is the build command as presented in the examples ? I posted here the test I did: https://bugs.launchpad.net/ubuntu/+source/gfxboot-examples/+bug/1077339/comments/1  "# make -C themes/example_07"
<ubottu> Launchpad bug 1077339 in gfxboot-examples (Ubuntu) "gfxboot examples fail to run" [Undecided,New]
<melodie_> getting gfxboot-theme-ubuntu source package now. What would be nice would be to know if there is a dedicated forum, mailing list, or chan to learn using it ?
<melodie_> reading into common.inc file now
<ricotz> dholbach, thanks for syncing the libreoffice deps :)
<dholbach> ricotz, no worries
<josepht> sorry
<xnox> ivanka: heya. Sorry, missed your ping from 11:39, what's up? =)
<xnox> (#ubuntu-devel is busy with planning everything today)
<pitti> slangasek: I'd like to participate in the hangout of https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration -- what do I need to do for this? (cjohnston said to contact the track lead)
<cjwatson> melodie_: any Debian-format source package can be built using debuild (read its man page for details); the entry point into each package's build system is always debian/rules
<melodie_> cjwatson thanks (I will restart learning packaging soon) just now what I try to understand while reading in the source package files is how the background for the first live splash is setup
<seb128> pitti, on this topic, I just moved it to 18utc, I hope it works for you
<pitti> seb128: sure, I'll just skip Taekwondo
<seb128> pitti, I want to try to have robert_ancell there and he's not going to be up much earlier I guess
<seb128> pitti, oh, let me put it tomorrow 18utc then
<pitti> seb128: no worries
<melodie_> cjohnston btw, I have found someone to sponsor a openbox-menu package I did and will redo it up to date for debian next. and the mentor talks the same language as me. :)
<seb128> pitti, well, it's the same
<pitti> seb128: I don't plan on going anyway, too many UDS sessions
<seb128> pitti, ok, as you want
<melodie_> sorry
<melodie_> I tabbed too fast: cjwatson
<melodie_> :]
<jbicha> I'm getting chroot problems with building armhf on nasl, I've hit retry a few times but it keeps getting stuck https://launchpad.net/ubuntu/+source/opal/3.10.10~dfsg-1/+build/4343624
<melodie_> cjwatson this is what the project looks like once booted: http://meets.free.fr/debian/images/OBUbuntu-RC3.png
<Laney> jbicha: yeah looks sad: https://launchpad.net/builders/nasl/+history - ping czajkowski in #launchpad
<ckpringle> dpm: any chance we can make the core apps project earlier (currently at 7-8pm0
<dpm> ckpringle, I will try, but there are a lot of sessions to coordinate and we're all on the same boat
<tumbleweed> rickspencer3: are we going to have a UDS session to actually discuss whether we are dropping non-LTS releases or not? I see sessions scheduled about the details, but nothing where we'd actually make that decision and drop 13.04
<rickspencer3> hi tumbleweed
<rickspencer3> I'm not sure what the plan is for that
<tumbleweed> yeah, me neither. I'm just getting concerned that some people see it as a forgone conclusion while others feel that we haven't had the UDS discussion about it yet
<rickspencer3> I'm not certain what kind of discussion would add to what's already been discussed, tbh
<cjwatson> heh, there really ought to be something
<rickspencer3> cjwatson, tumbleweed what would such a session look like?
<cjwatson> if only because if we don't we'll spend time later answering the question why not
<cjwatson> the whole question of monthly snapshots/updates/whatever deserves a session of its own, I guess; and then there's the question of how Ubuntu Desktop's decisions affect flavours
<rickspencer3> oh, I thought there was a session for monthly snapshots
<tumbleweed> yes, we have that
<rickspencer3> and I though slangasek brought one forward for the flavors
<Laney> how does it get decided whether we do 13.04?
<cjwatson> oh, yes, I've found it now
<cjwatson> http://summit.ubuntu.com/uds-1303/meeting/21596/foundations-1303-monthly-snapshots/
<Laney> especially with respect to its release schedule
<tumbleweed> I haven't seen a flavours one yet
<rickspencer3> Laney, aiui the current idea is that we decide some more details and then go to the techboard
 * micahg sees 3 sessions missing, was going to pen a mail to -devel (who, when, how of rolling release)
<Laney> well, we have Feature Freeze on Thursday for example
<cjwatson> fwiw, as Martin said, I don't see how the techboard can make a plausible decision other than "we can't do 13.04 if Canonical isn't funding the engineering to make it happen"
<rickspencer3> cjwatson, there is that
<tumbleweed> there is that, but it hasn't been explicitly stated that I've seen
<cjwatson> but we can do our best to make sure all the other things around that are as good as they can be
<cjwatson> tumbleweed: https://lists.ubuntu.com/archives/technical-board/2013-March/001513.html
<soren> cjwatson: Do you happen to know if we're going forward with the TB meeting this evening in spite of UDS going on?
<micahg> cjwatson: right, but for Canonical to prematurely yank funding if Ubuntu isn't ready to roll seems implausible as well
<tumbleweed> cjwatson: that doesn't say "canonical won't support non-LTS releases" it says people have been saynig that canonical is talking about this
 * tumbleweed really needs to run, but I'll be back in 10 mins
<cjwatson> tumbleweed: oh, ok, granted
<cjwatson> soren: hm, I haven't seen an indication that we wouldn't.  that means I have a long few days :-/
<cjwatson> I'm not sure I can make it given the demands
<micahg> soren: UDS is tomorrow
<soren> micahg: orly?
<micahg> tomorrow + Wed
<rickspencer3> soren, http://summit.ubuntu.com/
<soren> Blimey. So it is.
 * soren adjusts the date on his wrist watch. srsly
 * micahg needed to catch up on the thread before penning the e-mail to devel about the missing sessions
<soren> Stupid thing needs manual adjustment for non-31-day months. I must have gotten it wrong. :)
<tumbleweed> cjwatson: right. so if we don't want to discuss it at the UDS, it'd help if canonical's plans were clear
<tkamppeter> I have some questions to the online UDS. Can I participate without G+ account? Or without webcam (audio-only)?
<melodie_> which one is the package containing debuild ?
<Laney> melodie_: devscripts
<melodie_> Laney thanks
<Laney> sure
<slangasek> mhall119: hmm, pitti asked about being included in the hangout for one of the foundations sessions... is there a particular process for how we handle who goes in which session, or is that just a matter of who we invite to the hangout at the time we set it up?
<Laney> I saw somewhere that the 'required participants' get a link to join the hangout
<slangasek> cjwatson, mhall119: http://summit.ubuntu.com/uds-1303/meeting/21641/community-1303-rolling-toolchain/ needs to be taken off the schedule, because doko's not available to discuss it; I've untargeted the blueprint from the sprint, is there anything else I need to do to get it off the schedule?
 * tumbleweed heard that mentioned but haven't seen it documented anywhere
<Laney> planet I think
 * cjwatson has no idea I'm afraid
<Laney> http://www.chrisjohnston.org/ubuntu/vuds
<tumbleweed> do we have a way to get people who are talking a lot in IRC into the sessions?
<tumbleweed> often the active participants aren't readily determinable in advance
<Laney> you should be able to share the link out of band
<Laney> (I guess)
<tedg> slangasek, lool, xnox, Does it make sense to have a session on proposed solutions to manage ABI/API stability?
<xnox> we had approx. similar one in Copenhagen, driven by steam coming to ubuntu and wanting to keep same binary around for as long as possible, ideally forever.
<slangasek> cjwatson: haha, sorry, I meant cjohnston
<xnox> but nothing per se, resulted from it.
<xnox> (as far as I know)
<xnox> tedg: isn't there already some "app development SDK/ABI/API" sessions?!
<cjohnston> slangasek: your becoming hard to follow...  too many places lol
<cjwatson> slangasek: ah :)
<slangasek> Laney: right, that says "the required participants will be given a link"... I guess that means I can use summit to mark the people I want "required" in the hangout
<tedg> xnox, I think they were mostly targetted at the individual libs instead of a general solution.  But I could have missed it.
<cjwatson> I did wonder
<Laney> slangasek: That's my understanding, but you have the author of the blog post here :-)
<cjohnston> slangasek: they have to be marked as required
<cjohnston> in summit
<xnox> tedg: not sure, what do you have in mind for a session on proposed solutions to manage abi/api stability?
<cjohnston> one sec
<cjwatson> The gaming ABI session mostly ended up being about tracking ABI changes systematically so that we know when they happen and can manage them appropriately
<slangasek> cjohnston: ok.  And I first need to mark them on the blueprint?
<pitti> slangasek: I marked myself as "participation essential" in LP, but I understand that's not the same "required" as cjohnston means
<tedg> xnox, I was thinking like the acc thing we discussed last week.
<cjwatson> Since in the context of libraries we don't maintain it isn't meaningful to say "we won't change the ABI" - we need to find out when they change and keep compatibility packages around, etc.
<tedg> xnox, And getting that to all libs.
<cjohnston> slangasek: they need to be 'attending' via the BP.. essential on the BP doesnt matter..
<tedg> cjwatson, I was also concerned about accidental changes, more than on purpose ones.
<slangasek> pitti: I don't see you subscribed to https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-logind-migration at all?
<dobey> for some upstreams it's basically impossible to do that, sadly :-/
<cjwatson> Right, for those we can only meaningfully find out about them post hoc
<pitti> slangasek: that's the superseded one; https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration is the real thing AFAIUI
<slangasek> pitti: oh blast, the wrong blueprint is linked to the summit session
<cjwatson> As long as it's before release and in time to do something about it ...
<tedg> cjwatson, Release?  I'm unfamiliar with this term you speak of  ;-)  We could block package build if it changes unknowningly, effectively like .symbols files.
<slangasek> cjohnston: hi, sorry - I need http://summit.ubuntu.com/uds-1303/meeting/21636/foundations-1303-logind-migration/ points to a wrong blueprint, I need to get https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration on the schedule in its place... what's the best way to do that?
<cjwatson> tedg: Last I checked we were still doing an LTS :-P
<cjwatson> tedg: Yes, perhaps some kind of autopkgtest or autopkgtest-like checks across the board would be helpful
<cjwatson> So not block build (though packages can and do do that themselves) but block promotion to the release pocket?
<tedg> Anyway, that's what I was thinking for the session.  If we had a plan there, then we could implement it on Canonical-libs first.
<slangasek> cjohnston: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration is targeted to uds-1303, but I don't see it in the system anywhere
<tedg> cjwatson, Sure, blocking getting out into the wild.  Which step I'm not as worried about.
<cjwatson> We could already have Canonical libraries use whatever the dh_makeshlibs option to fail on symbols file mismatches
<cjwatson> *option is
<tedg> And we're migrating many of them to use that.
<cjwatson> dh_makeshlibs -- -c2
<tedg> But it's not really full ABI stability for things like structure sizes.
<tedg> Which are really critical in the GObject world.
<cjwatson> Indeed.  There are various ABI checker tools around - does abicheck handle that?
<cjohnston> slangasek: http://summit.ubuntu.com/uds-1303/2013-03-06/  1815.. isnt that the one you wnat
<cjwatson> Or abi-compliance-checker
<tedg> Yes, and I think that xnox was going to look into using it.
<cjwatson> I think by now this is probably not a wheel we need to reinvent
 * cjwatson nods
<tedg> Basically adding a "symbols file" like thing to a package for the ABI.
<cjwatson> Aha, that's what you meant by "acc"?  That was a bit cryptic for me.
<cjwatson> Yep.  I approve :)
<tedg> Sorry, yes, that's what I meant.
<slangasek> cjohnston: yes... hmm, did something magically fix itself? :)
<cjohnston> i dunno... im confused from trying to keepup with all of the links that kept getting posted
<cjohnston> and im confused why its against client unless it was renamed from client
<cjohnston> it should point to foundations and not client correct?
<slangasek> cjohnston: it was renamed from client; it should be foundations, yes :)
<cjohnston> and removed from the client room?
<slangasek> cjohnston: I imagine so
<slangasek> cjohnston: what's our hangout size limit?
<cjwatson> (Though I'm not wild about abi-compliance-checker's configuration apparently being in XML :-/)
<slangasek> configuration, or manifest?
<cjwatson> Manifest
<cjohnston> slangasek: its removed from the client room, and assigned to foundations. you should now have the ability to schedule it
<slangasek> cjohnston: ta
<cjwatson> Ah, it has some kind of alternative dump format too.  I haven't really looked into it deeply ...
<cjohnston> slangasek: also, in the subnav, you will see 'review attendees'... thats where you mark people required
<slangasek> cjohnston: yes, I know... I was halfway through that list when something reset the statuses on me ;)
<cjohnston> hrm. ok
<cjwatson> slangasek: Unrelatedly, I wonder if the GRUB efinet problem I'm seeing on my test system has anything to do with yours; it seems to just refuse to receive any packets ever, claiming (once I apply sufficient debugging) that the interface is uninitialised, but it can *transmit* packets just fine
<cjwatson> It's very odd
<pitti> Laney: can I ask you to set a britney block on pygobject? I'm about to upload 3.7.91, and while I don't know of anything that's broken I'm paranoid
<Laney> oui
<slangasek> cjwatson: that sounds roughly familiar
<pitti> Laney: i. e. I'd like to wait on all reverse depends autopkgtests
<pitti> Laney: merci mon ami :)
<cjwatson> Specifically it's getting EFI_DEVICE_ERROR on EFI_SIMPLE_NETWORK_PROTOCOL.Receive
<seb128> slangasek, http://summit.ubuntu.com/uds-1303/2013-03-06/display the logind one is at 18:15
<cjwatson> slangasek: Are you still in a position to reproduce what you saw?
<seb128> slangasek, I put it in the client track since after all we had some free slots
<slangasek> tedg, cjwatson: so the question was whether we needed a session on ABI stability.  Does the appdev session have this covered, or do you need me to add something in the foundations track?
<slangasek> seb128: ok
<slangasek> cjwatson: with sufficient swapping of state into my brain, yes
<cjwatson> slangasek: My current debugging patch is http://paste.ubuntu.com/5585573/ (note that that deliberately slows packet reception down to one poll every two seconds so that one can see what's going on); it would be interesting to apply that and see what error get_card_packet is hurling out
<cjwatson> (That's against upstream trunk, ish, hopefully it roughly applies to 2.00)
<cjohnston> slangasek: should http://summit.ubuntu.com/uds-1303/meeting/21603/community-1303-plusone-maintenance/ be renamed to foundations, and not against community and foundations?
<cjwatson> slangasek: Oh, you'll need to "set debug=efinet" for that to work, so either do that in shell/configuration before doing any network operations, or build the netboot image with grub-mknetdir --debug-image=efinet
<tedg> slangasek, I don't see one that covers this topic, I'm not 100% we need one as it seems relatively straightforward, but perhaps to coordinate?
<slangasek> cjwatson: ok, will try to have a look today
<cjwatson> tedg: As long as somebody from foundations is in an appdev session as a general sanity check, I think we could deal with its output later
<slangasek> tedg: so currently I'm feeling a bit too-many-cooks on the question of abi checking; I don't think there's a lot to discuss, we just need to implement ABI checking infrastructure which doesn't really require more meetings IMHO
<cjwatson> amen
<tedg> Heh, sounds good to me.
<tedg> You'll be sending out weekly TPS reports on progress right?  ;-)
<cjohnston> +1
<slangasek> tedg: lool, tvoss and I are already planning to provide Canonical upstreams with a best practices guide for ABI stability, and to identify the correct infrastructure to check at package upload time that ABI/API hasn't silently broken
<cjwatson> slangasek: I think if that fails (efinet) my next step is to try to dump out and disassemble this system's UEFI somehow :-/
<slangasek> cjwatson: fun
<cjwatson> In order to have some freaking clue what it's doing
<cjwatson> It's still possible that GRUB's EFI calling shims are broken, though (a) I've hand-checked them (b) you'd think we'd have noticed
<cjohnston> slangasek: lool how does http://summit.ubuntu.com/uds-1303/track/foundations/ look
<slangasek> cjohnston: LGTM, thanks
<ogra_> fulkl of sessions !
<ogra_> *full
<cjohnston> slangasek: have I addressed all of your concerns (that I can take care of with less than 24 hours to go)
<cjohnston> I don't know if I was able to keep up with everything in both channels
<slangasek> cjohnston: I believe so, yes
<cjohnston> cool. thanks
<slangasek> cjohnston: if not, once I've fully unwound my stack in another hour, I'll let you know :-)
<cjohnston> :-)
 * cjohnston notes to leave in 55 minutes
<lool> cjohnston: thanks for fixing foundations track!  :)
<cjohnston> np
<achiang> if i want to comment on a blueprint (asking a question i would like clarified), what is the convention for doing so? just edit the whiteboard directly, put my nick in [square brackets] then ask my question?
<xnox> achiang: yes.
<xnox> in chronological order =)
<achiang> xnox: should i insert the question inline? or is there typically a q&a section?
<xnox> achiang: wherever it's obvious, subscribed people will get a "diff" format of it anyway =)
<achiang> xnox: thx
<bryce> are the arm64 buildd's swamped?  I've been getting timeouts trying to get a PPA to build a patched xserver for a bug (https://launchpad.net/~bryce/+archive/lp982889/+packages) and wonder if I should keep trying or if it's a lost cause?
<Andy80> hi guys
<xnox> bryce: arm64 ?! wishful thinking =) or do you mean amd64 or armhf?
<bryce> xnox, arg, yeah typo.  amd64
<Andy80> I really don't want to annoy anyone, but.... despite the fact that I really apreciate that Unity is moving to Qt/QML (I told this 2 years ago and nobody listened), I really don't like how the decision was takes: 0 community involvement, just an announcement.
<dobey> Andy80: #ubuntu-unity
<xnox> bryce: it doesn't look that busy, i386 is chugging away in the ppas though.
* xnox changed the topic of #ubuntu-devel to: Packaging apps and software for Ubuntu, including new packages, PPA packages, etc. | Packaging guide: http://developer.ubuntu.com/packaging/html/ |  For working on Ubuntu Core OS, see #ubuntu-devel | For writing apps and software targeting ubuntu, see #ubuntu-app-devel
<xnox> damn, please revert.
<xnox> bryce: https://launchpad.net/builders
<Andy80> dobey, I don't want to be OT, don't worry... but this is not an #ubuntu-unity problem only... it's something bigger. It involves the whole Ubuntu development.
* xnox changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | 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:
<dobey> Andy80: then IRC surely isn't the place to discuss it. you can perhaps bring it up on ubuntu-devel-discuss mailing list or something
<Andy80> dobey, ok... sorry then.
<bryce> xnox, thanks for the link.  yes they don't look bogged down.  Would you suggest I just keep trying?  My build log isn't really very clueful about  what went wrong.
<ScottK> Andy80: I think Unity going to Qt/QML will have less of an impact than their decision to invent their own X windows replacement.
<jbicha> ScottK: I wish they named their display server 'UDS' instead of 'Mir' ;)
<Andy80> ScottK, that's not the point :) (maybe it's better if I blog my thoughts....) I 100% agree with the decision they (finally) made. But I strongly disagree with the way they did it. Community was not involved at all. That's what really hurts me.
<ScottK> Andy80: Right.  Totally agreed.
<ScottK> First UDS, then rolling release, now this.
<ScottK> They have no end of surprised in store, apparently.
<Andy80> ScottK, oh wait... it's already decided for the rolling release :D ? (I agree with this too, but I totally missed the announcement :P )
<ScottK> That's my assumption.
<ScottK> It certainly appears to me that the call do "discuss" it is pro forma.
<Andy80> ok
<Andy80> I already felt this a couple of UDS ago...
<Andy80> but I just didn't want to be "rude" bothering with them
<ScottK> Up until now, it was reasonably possible to avoid it if your interests didn't overlap Canonical's focus.
<ScottK> It doesn't seem so anymore.
<jbicha> I don't think the decision is final, but it looks unlikely to me that the ones who don't want a rolling release will be organized enough to stop the ball in motion
<jbicha> there's still opportunity to steer the ball if you have good ideas for how to best do this
<mlankhorst> do you think it's a good idea to have a release every 6 months then ? :S
<ScottK> I think it comes down to "We don't care about Ubuntu governance, whatever is decide/preferred, we'll control what happens via the budget for our own needs".
<ScottK> mlankhorst: I think it's essential.
<jbicha> mlankhorst: I don't think we're ready to do a rolling release next month and advertise it the same way we always do non-LTS releases
<tumbleweed> jbicha: the only sane way to think of it is as no LTS releases
<tumbleweed> no non-LTS releases even
<jbicha> tumbleweed: ok but what's http://www.ubuntu.com/download/desktop going to say? and will we mark it as just another Ubuntu release only better or will we clearly mark it for early adopters for now?
<tumbleweed> jbicha: "download precise here"
<jbicha> I think I'm ok with the experiment but I'm not ok with experimenting on a million people who aren't aware of the risks; once it's been proven to work than we can relax the marketing
<Andy80> an LTS every 2 years and rolling release the rest of the time would make sense for me. But I'm not expert in this field, so it's just for my tastes...
<tumbleweed> the development release can only really be for enthusiasts
<jbicha> the current site lists 12.10 above 12.04 LTS and it's not at all clear that 12.04 LTS was a better choice in this case for ~90% of people
<jtaylor> barry, cjohnston any objects to me uploading shiboken to see what happens before ff (probably tomorrow or tuesday)?
<tumbleweed> jbicha: a development release isn't the best choice for anyone in our target market
<jtaylor> the thing should at least be be somewhat working, which is better than not at all
<cjohnston> broken is broken, so it cant get worse than broken
<jbicha> tumbleweed: tell that to the website people
<barry> shibroken?
<jtaylor> ^^
<zequence> Ubuntu Studio ISO failed, and I'm having problems debugging the reason. I've recently changed the seeds http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntustudio-dvd/20130304/livecd-20130304-amd64.out
<zequence> It's just about to build the depency tree after having finished with ubuntu-minimal
<dobey> jbicha: it's best not to think of "rolling release" with the word "release"
<dobey> jbicha: there won't be an actual "release" so much. it's just that development will continually happen and people can run from the unstable archives, and the "release" will be an LTS that happens every 2 years
<tumbleweed> there might be snapshots, which are sort of like releases, that's the only new thing
<zequence> I haven't understood the point with snapshots. What's the difference between a snapshot and a daily?
<dobey> well, "copy an image to another directory on the server every 30 days"
<dobey> but doing the snapshots seems like a waste of time to me
<tumbleweed> the point of the snapshot is to avoid having to install mountains of updates every day
<tumbleweed> put that off to once a month
<zequence> If a rolling release is to be a development release, it's not really a rolling release. It's just a development release
<tumbleweed> zequence: what's a rolling release then?
<dobey> it's not a release
<dobey> development or otherwise
<dobey> it's an archive of packages, and there are automated daily image builds to install from
<zequence> tumbleweed: One where you aren't experimenting in the standard repos
<zequence> tumbleweed: And you don't release features until they are complete
<tumbleweed> we don't experiment ni the standard repos
<tumbleweed> and we don't upload things until they are ready to be used
<tumbleweed> (but yes, I assume we'll get a little more conservative with the dev release)
<jbicha> we're going to have a delay though between landing new stuff and that getting pushed to the early adopters right?
<tumbleweed> no
<jbicha> oh that's scary
<cprofitt> question, not sure if this is the right place, will Quickly still be moving forward?
<dobey> why? it's not any different than running a version of ubuntu before it's released right now
<jbicha> not many people will be running the PPA where we'll have to stage big transitions
<tumbleweed> jbicha: we already stage some toolchain changes in PPAs
<jbicha> dobey: sure but I think this new thing will pick up quite a few more users (who were happy with the non-LTS releases or happy with upgrading at Beta, etc.)
<tumbleweed> jbicha: right, and I'm not sure that we'll be ready for them :)
<dobey> jbicha: those people should continue to do what they were doing then, not run the rickroll archive
<dobey> upgrade at beta, or at the next release.
<cprofitt> will new versions of LibreOffice, etc be pushed down to the LTS?
<cprofitt> I am one of the people who uses the non-LTS releases and I do it to stay closer to current on my applications
<zequence> Would it be tons of work adding another repo to the rolling release, where the repo that is currently used in the development release would be something that wasn't enabled by default (and with a different name), but which developers would enable for their work, and then a default repo for users - you'd sync packages from the developer repo to the user repo, whenever something was thoroughly smoke tested and fairly complete feature wise
<cprofitt> if LTS is going to be 'stale' on application updates for two years that would bother me
<dobey> cprofitt: i don't think that can be answered in this channel (or in a general sense), but is something that will be answered on a per-case basis. probably a good question for Sweetshark to weigh in on though, at least for LO. and probably worth bringing up in the UDS discussion
<dobey> zequence: you mean like how everything gets uploaded to -proposed first, like we're already doing?
<cprofitt> thanks dobey
<zequence> dobey: Well, yes.
<zequence> dobey: Only, from what I gather, -proposed is not used in this way
<tumbleweed> things migrate from -proposed when they don't decrease installability
<jbicha> wow, it's not as much as fun to have a flavor that people aren't recommended to use and we can't really backport new GNOME stable releases to an LTS release without breaking Unity in that PPA
<dobey> well, there was also talk of requiring that autopkgtests don't fail, before copying over, no? that would basically implement the "smoke tests" bit
<tumbleweed> dobey: sure, but the longer we hold things out of the release pocket, the nastier disentangling the mess gets
<dobey> certainly
<micahg> cprofitt: anyone can request a libreoffice backport to an LTS if they do the testing and it builds
<tumbleweed> has there ever been one before?
<dobey> backports and updates are quite different though
<micahg> sure, but I see libreoffice as the type of thing that you don't have to update, but can backport
<micahg> some people don't want their office suite changing out from under them ;)
<tumbleweed> jbicha: I hope some of the flavours can have a UDS session to talk about these issues. It sounds like you have the same problems as kubuntu
<jbicha> micahg: bug 888665 is still the annoying blocker for a lot of backports :(
<ubottu> bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] https://launchpad.net/bugs/888665
<micahg> jbicha: infinity promised to fix eventually
<jbicha> tumbleweed: I didn't think we had too much of a problem with the rolling idea but I thought we'd have more of a buffer between the system used by users who like the latest stuff and the system where the developers are doing their work :(
<jbicha> those are 2 separate audiences and we're making things more unpleasant for both sets
<tumbleweed> jbicha: you saw https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-monthly-snapshots ?
<jbicha> something like that was more what I understood; I think doing a ~monthly release cycle is critical to having people actually use the thing
<jbicha> and we should have a deadline each month for major features so that testers, translators and documenters have time to do their thing before it gets pushed out to the perpetual beta users
<slangasek> jbicha: the proposal is not *at all* about doing a monthly release cycle
<slangasek> the goal of moving to a rolling release is to reduce the release overhead.  Reimplementing the release cycle for monthlies has the exact opposite effect.
<jbicha> there are conflicting proposals and I think recognizing a daily and monthly audience has merit
<jbicha> I know I would rather land the huge new GNOME update at the beginning of the month to give us more time to ensure that we found all the big issues during the PPA staging time
<jbicha> is there a successful software project that doesn't have a feature freeze?
<slangasek> jbicha: you're missing the point.  A feature freeze precedes a release; the monthly snapshots are not going to be releases.  There is no way we're investing those kinds of resources into a monthly process.
<seb128> jbicha, the new GNOME update shouldn't land "at the beginning of the month", they should land after GNOME stable .2 when they got testing and are somewhat stable
<slangasek> jbicha: if you think that a monthly snapshot without the release process you describe is not useful, I encourage you to make that case; but there's just no way, given the thesis statement of "we want to do away with 6-month releases and move to a rolling release because the 6-month releases aren't benefitting us" that we would turn around and implement a once-a-month release process
<achiang> can someone clue me in here? once qt5 gets a Mir backend (and assuming Kwin gets ported to Qt5), what more work would there be left to do in Kubuntu (at least specifically to support Mir)?
<slangasek> achiang: a window manager / shell is deeply tied to the X protocol
<achiang> slangasek: ah, so you're saying what i don't know about that piece of plumbing can just about fit into the grand canyon. ;)
<achiang> slangasek: ok, that makes a lot of sense, thanks
<kees> mdz: TB meeting soon
<mdz> yep
<yofel> achiang: we'll talk to martin graesslin when he shows up about that (kwin developer)
<achiang> nod
<superm1> yofel: so for something like xfce's window manager there needs to be a mir backend added for the underlying toolkit first (say GTK) and then additional work on top of that on the window manager itself?
<yofel> I'm the wrong person to ask that, but it is like that usually
<ScottK> achiang: I think the chances of kwin being ported to Mir are very, very low anytime soon.  It looks like ~everything not Unity will be a second class citizen in Ubuntu in a year.
<ScottK> Xfce and Lxde even more so, since at least Canonical is doing work on Qt5.
<RAOF> ScottK: You'll ~always have an X server available to you, even if we shove a Mir compositor underneath it; exactly as the previous system-compositor spec.
<ScottK> I may be a bit lost in terminology here.
<ScottK> Isn't the layer like compiz/kwin the compositor?
<ScottK> So I'm not sure I understand what that means.
<RAOF> Before Mir came along (or, at least, before we knew about it), we were going to do a wayland system compositor, with X nested inside it. So all your X servers talk to the system compositor, and it does the final display bit.
<RAOF> The same thing will apply here - you'll ~always be able to start an X server on the system compositor, it'll run nested, and KWin won't be any the wiser.
<ScottK> OK.
<sarnold> "~always" :)
<RAOF> This is something that we'll have to support for a good long while, too, since we can't magically port everything anyone wants to Mir.
<ScottK> sarnold: Yes.  Preciselye.
<ScottK> s/e//
<sarnold> of course people have wanted to kill off X for as long as I've been using it
<RAOF> sarnold: Heh, yes. I obviously can't commit to how long we'll be supporting X, but I don't see us dropping it in the next, say, decade.
<sarnold> I'm not entirely sure how to feel here... I don't want to say goodbye to old friends like urxvt... and yet, X does have a raft-load of problems :)
<sarnold> RAOF: man, no one _ever_ has good stock tips for the year 2023...
<ScottK> RAOF: Well before today, I'd have rated the chances of Canonical thinking it was a good idea to write their own X windows replacement from scratch as low too.
<superm1> RAOF: so basically these new fangled apps will connect directly to the system compositor and old X apps will connect to the nested X server?  Will it be noticable to the user that they're running X apps in a container theN?
<RAOF> superm1: No, new fangled apps will connect to the Unity session compositor (which will connect to the system compositor), X apps running in a Unity session will connect to a rootless nested X server started by the Unity shell, and non-Mir *sessions* will start a full nested X server.
<RAOF> superm1: Users shouldn't be able to tell that they're running X apps under Unity, and users shouldn't be able to tell that KWin's running in an X server under Mir.
<RAOF> It'll be not dissimilar to how X apps work in OSX currently - they also do a nested rootless X server.
<superm1> ah i see
<mdeslaur> ScottK: what makes you think other distros won't be using Mir?
<superm1> but if you are talking about something legacy that doesn't necssarily operate act as a session compositor, say metacity or xfce-window-manager, is that where you run into troubles then?
<ScottK> mdeslaur: The approximately zero percent success Canonical has had convincing other distros that things like Unity are the way to go.
<ScottK> I expect the trend to continue.
<ScottK> If you go off and develop something in a vacuum and suggest that everyone should just eat it whole, rather than engage with the community, no one is going to listen.
<ScottK> https://plus.google.com/115606635748721265446/posts/93zY4qfpq2X <- Kwin maintainer, fwiw.
<dobey> ScottK: yet it's ok for people in other communities to do that. irony. :)
<ScottK> dobey: Not a all.
<RAOF> superm1: Well, you can't run metacity or xfce-window-manager in a Unity session. But you can still have an XFCE session - it'll just spawn a full X server, and everything will work as it does now.
<dobey> ScottK: many of the things we use in userspace are something someone wrote in a vacuum, and then said "here, i think it's cool, maybe you want to use it"
<dobey> heck, the linux kernel started that way. linus wrote something, and then people started contributing
<ScottK> dobey: Sure, but not so much for huge pieces of infrastructure.
<ScottK> two decades ago things were a bit different.
<mdeslaur> ScottK: that's how all open source software is written...somebody bangs on something until it gets to 0.1 and is worth showing, and then releases it...
<dobey> pulseaudio? gstreamer?
<superm1> RAOF: oh so then it really *shouldn't* be a big deal for flavours that aren't updated to mir immediately then.  it will be more convenient and efficient when they do, but they'll get along fine for now
<rickspencer3> hmmm
<dobey> systemd?
<sarnold> gnome3? :)
<rickspencer3> I'm not sure that debating how right/wrong it is to write software in different ways is totally relevant
<rickspencer3> I'm wondering more if the issue at hand is ensuring that Kubuntu doesn't inadvertnatly get locked out in the cold
<ScottK> It seems like for this particular issue, the concern is more long term, but it's real.
<dobey> i don't think kubuntu is getting locked out in the cold, per RAOF and tedg's comments
<dobey> it seems more like xubuntu, lubuntu, etcâ¦ might more so in the future
<rickspencer3> dobey, I think it's a legitimate concern
<RAOF> superm1: Absolutely. Everyone can basically ignore Mir unless they want to write a display-server-compositor.
<rickspencer3> fair enough, I think it's a concern for all the flavors
<rickspencer3> and I think we shouldn't let it happen
<ScottK> RAOF: Until there's a bug in Mir.
<dobey> rickspencer3: certainly. wasn't saying it wasn't a legitimate concern.
<rickspencer3> the point of Mir is certainly not to keep other DEs from working on Ubuntu
<rickspencer3> that would be a *hideous* outcome
<ScottK> Then you've got the fact that you're running emulation instead of a standard X windows and it makes it hard to know where problems are.
<RAOF> You're not running an emulation.
<tedg> ScottK, It's not really emulation, it's a driver for standard xorg.
<RAOF> You're running an X server.
<ScottK> OK.
<RAOF> An X server, using the same drivers, that just happens to not handle the framebuffer.
<ScottK> What handles the framebuffer then?
<tedg> ScottK, And yes, there'll be bugs, but it'll effect a large number of folks besides other DEs.  Any X11 app really.
<RAOF> Mir handles the framebuffer.
<RAOF> (The Mir system compositor)
<ScottK> And we're back to where I get confused then.
<tedg> There's two Mir's.  A root system compositor Mir and a user session Mir.
<ScottK> I thought Compiz/Kwin were the compositor?
<tedg> (in the Unity case)
<RAOF> I'm pretty sure we've got a diagram of this somewhere. Let me dig it up :)
<tedg> ScottK, System compositor vs. user compositor.
<ScottK> So then how does this Mir system compositor interact with the regular one?
<tedg> ScottK, The system compositor allows effects when doing things like faster user switching.
<ScottK> tedg: But we don't today have a system compositor, right?
<tedg> It's basically a tree
<tedg> No, we don't today.
<tedg> (well, there are packages to do it with weston, but I don't think it is widely done)
<ScottK> So something like Compiz/Kwin will have to overlay this somehow?
<RAOF> Only the X server needs to know about the system compositor.
<tedg> No, it'll be transparent to them.
<tedg> Hmm, visibility descriptions probably aren't good when discussing graphics...
<tedg> They don't need to do anything special.
 * ScottK has found "It'll be a transparent change" to be one of the great lies of system development, but maybe this time.
<RAOF> ScottK: You can run this right now, if you want - it's in a PPA (for Intel and ATI)
<RAOF> Hah. Or, it *will* be, once we've finished copying everything over from the private PPA. It will be in https://launchpad.net/~mir-team/+archive/staging/+packages
<tedg> ScottK, It will, most surly, have bumps over the next year.  But after that it should be relatively straight forward.
<tedg> surely...
<jcastro> RAOF: so how does the PPA work, just add it, install it ... profit?
<ScottK> RAOF: This stuff would get a better reception if it didn't all get developed in secret first.
<RAOF> ScottK: Not my call :/
<ScottK> It's not just me.  Here's Martin GrÃ¤Ãlin's initial reaction: https://plus.google.com/115606635748721265446/posts/93zY4qfpq2X
<ScottK> RAOF: I know.  Just saying.
<robert_ancell> ScottK, think of the current system compositor as VT switching - we're replacing that with a real compositor that can do effects
<ScottK> Are my VTs still going to work?
<RAOF> Maybe.
<RAOF> At the moment, yes.
<robert_ancell> ScottK, not for switching between user sessions - all the graphics will be on one VT
<dobey> i highly doubt having said "hey, we're going to write a compositing system to replace X with on Ubuntu" prior to having developed any actual code would have illicited any different reactions.
<robert_ancell> but text consoles will remain for now
<RAOF> We'd *like* to replace them with something a bit better. But still replace them.
<ScottK> dobey: Sure.  Actually talking to outsiders and trying to work with them might have.
<mdeslaur> ScottK: Mir should be quite exciting for kde, as it is compatible with android drivers AIUI, so it can be used to get kde plasma on the wide range of android hardware currently on the market
<ScottK> Plasma Active already targets a similar hardware segment.
<mdeslaur> ScottK: with what drivers?
<ScottK> I'm not sure exactly where the overlap would hit.
<ScottK> Not sure.
<ScottK> I don't think it'll be exciting for KDE if it's Ubuntu only.
<Niedar> I think this is the reaction that would have happened regardless of if this was done in private or not I dont think you will convince people ahead of time until there is a real result and then we will find out if it was a good idea or not
<jcastro> RAOF: so since you didn't respond I assume I shouldn't try the PPA when builds come up? :)
<jcastro> or will they melt my display or something
<RAOF> jcastro: Ah, sorry. They won't melt your displays.
<RAOF> jcastro: *probably* âº
<RAOF> jcastro: We have a canonical wiki page on how to set it up; basically you should only need to add a âtype=mirâ line to /etc/lightdm/lightdm.conf
<jcastro> cool, is someone working to put that stuff on the ubuntu wiki?
<RAOF> Not as far as I'm aware.
<celso> people, i have some doubts in my vgaswitcheroo setup. can sommeone help me?
#ubuntu-devel 2013-03-05
<celso> curently i am using vgaswitcheroo to shutdown my ati hd5470 card to use the intel hd3000 but for a unknown reason, when i setup the stuff in rc.local file, it disables my sound card. it simply doesn't detect it. I think its because of the "sleep 6" comand that i had there.
<celso> if i remove it, it detects my sound card after reboot.
<celso> anny ideas about to fix this?
<xnox> barry: there is no broken more than shibroken =)))) Have you had a chance to look at the proposed patches to fix it? or should I do a shout-out to digia to review / merge the one that is on Qt side?
<barry> xnox: i haven't had time to look at it.  if you can line up a reviewer, that would be great
<psusi> oh dear... the more I read about udisks2, the worse it sounds
<lfaraone> sarnold: its sort of weird when someone reports a bug, assigns it to themselves, and mark it as "in progress" that you'd go in and mark it as "incomplete"â¦ (re LP #1145560)
<ubottu> Launchpad bug 1145560 in openafs (Ubuntu) "OpenAFS Security Advisories 2013-001 and 2013-002" [High,In progress] https://launchpad.net/bugs/1145560
<sarnold> lfaraone: my apologies :)
<sarnold> lfaraone: I'll be more careful in the future to look for people assigning themselves the bugs. (you're the first :)
<lfaraone> sarnold: no worries :) in this case, I was told "here's a security fix. file a bug and post a debdiff", and had done Â½ of that :P
<sarnold> haha
<lfaraone> And then I had class :P
<sarnold> you left out the *smack* in the middle while I muddle up your bug..
<evck> hi, looking for some advice on how to get started in ubuntu dev
<evck> looking to find places to contribute, but not sure where to start
<dbrown> hello. I need to speak with an ubuntu devoloper if possible
<dbrown> i guess i will come back tomorrow
<lfaraone> !ask | dbrown
<ubottu> dbrown: 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
<dbrown> is ubuntu moving toqt and away from compiz?
<dbrown> excuse me is ubuntu moving to qt? and away from compiz?
<TheMuso> dbrown: Yes.
<TheMuso> I don't know about away from compiz but I believe according to the announcements Unity is moving to Qt.
<dbrown> okay then my problem is that I am visually impared user who uses the enhanced zoom desktop feature of compiz
<TheMuso> dbrown: No promises with regards to magnification and unity in Qt, but there are those of us who are aware of that being a requirement for some users, and will try to get this addressed in some way.
<TheMuso> I myself am vision impared, and use a screen reader, and occasionally use magnification, so I will find it useful too.
<TheMuso> So I will be following up about magnification to see what could be done.
<dbrown> ttyl got to go
<lfaraone> Are any of the archive builders broken?
<lfaraone> https://launchpad.net/ubuntu/+source/openafs/1.6.2-1+ubuntu1/+build/4345033/+files/buildlog_ubuntu-raring-i386.openafs_1.6.2-1%2Bubuntu1_FAILEDTOBUILD.txt.gz died strangely
<infinity> lfaraone: No.
<lfaraone> "/lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation"
<infinity> lfaraone: Read up.
<infinity> lfaraone: You're missing a link to -lpthread.
<ScottK> /usr/bin/ld.bfd.real: note: 'pthread_create@@GLIBC_2.1' is defined in DSO /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker command line
<infinity> I'll admit that "could not read symbols: Invalid operation" is about as intuitive as operating a television with a fish.
<infinity> But the previous two lines are pretty clear.
<lfaraone> hmm. this wasn't a problem in 1.6.2~pre3.
<lfaraone> Apologies.
<lfaraone> ScottK: did we tighten up the linker in raring? (the package builds in quantal)
<slangasek> cjohnston, mhall119: I need to add another 'required' participant to http://summit.ubuntu.com/uds-1303/meeting/21598/foundations-1303-hwe-stack/, but he's not showing up in the 'review attendees' list despite having been added to the blueprint over an hour ago
<infinity> lfaraone: It could be that one of the other libraries it links to used to link pthread and no longer does.
<infinity> lfaraone: Correctly or incorrectly.
<pitti> Good morning
<lfaraone> https://launchpad.net/ubuntu/+source/openafs/1.6.2-1+ubuntu2/+build/4345141 seems to be buildingâ¦ again?
<lfaraone> "currently building", yet "Started 2 minutes ago\n Finished 2 minutes ago (took 31 minutes, 3.5 seconds)"
<infinity> lfaraone: It's a display bug that happens when a build gets thrown back in the queue...
<lfaraone> infinity: I see. Why might that have happened?
<StevenK> Oh, it was given back?
<infinity> Dunno, don't have the old log.
<pitti> infinity: would you mind removing the pygobject propagation block? autopkgtests look good
<infinity> StevenK: Looks like a give-back or previous abort or something.  Hard to say the cause from my vantage point.  You have access to buildd-manager logs, which might be more enlightening.
<pitti> well, at least not worse than they already looked before
<infinity> StevenK: But that display bug has always annoyed me (cf: not resetting the build record properly)
<lfaraone> Ugh. The last build took 30 mintues, so *sadness*
<infinity> pitti: Done.
<pitti> infinity: danke
<infinity> lfaraone: What's the bug hurry?  It'll take longer on ARM anyway.
<infinity> lfaraone: And PPC, where you're stuck behind some security builds...
<lfaraone> infinity: this is a security build.
<infinity> I'll score it up, then.
<infinity> lfaraone: Err, why the weird version number, by the way?
<infinity> 1.6.2-1+ubuntu2 <-- That should be 1.6.2-1ubuntu2
<lfaraone> infinity: no, it shouldn't, because openafs is horrible: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/356861/comments/1
<ubottu> Launchpad bug 356861 in openafs (Ubuntu Jaunty) "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,Fix released]
<wgrant> infinity: It's not a display bug, it's an obscure buildd-manager corruption bug that's never been identified
<wgrant> Retries reset that properly
<infinity> lfaraone: Oh, that's entertaining.
<infinity> wgrant: I didn't mean the bug is in the display code, but that it's displaying the silliness of the data.
<wgrant> In this case it looks like batsu died
<wgrant> Or was killed
<infinity> wgrant: It seems to occur in cases where buildd-manager takes it upon itself to pop a build back in the queue, and reasonably consistently, I'm surprised it's never been identified.  Unfixed, sure, but not unidentified.
<wgrant> infinity: It appears reasonably consistent because you only notice it when it happens.
<infinity> wgrant: Fair enough. :)
<doko> xnox, cjwatson: online?
<cjwatson> doko: only slightly; starting properly in a couple of hours
<doko> cjwatson, I was pointed to #1083498. would it be ok to get this into precise and quantal?
<doko> same for 1018522
<cjwatson> doko: 1018522 should certainly be done in raring (first).  as for precise/quantal, I think it's probably doable in principle under the banner of improved hw enablement or something, but you'd need to think very hard about the regression test plan
<Cheery> I read about https://wiki.ubuntu.com/MirSpec today.
<Cheery> and this might interest anyone working with Mir: https://devtalk.nvidia.com/default/topic/529486/general-graphics-programming/direct-rendering-access-on-linux/
<seb128> Cheery, hey, you can find them on #ubuntu-mir
<Cheery> all right
<ScottK> lfaraone: Yes.
<ScottK> It's more likely you've no longer saved by indirect linking in some other library, but there are some changes too.
<xnox> doko: cjwatson: anything that improves performance and saves power are good candidates for SRU, imho. As both hyperscale and client factors like that a lot =)
<cjohnston> slangasek: ping
<rbasak> cjwatson: how much do we care about cross buildable packages for packages not essential to arch bootstrap?
<cjwatson> rbasak: Varies.  https://wiki.ubuntu.com/CrossBuilding has some arguments
<rbasak> I wasn't aware of that page - thanks!
<cjwatson> rbasak: More relevant for things you might want to build for mobile devices
<rbasak> Ah - of course
<cjohnston> seb128: ping
<seb128> cjohnston, hey
<cjohnston> seb128: short answer: blame jasoncwarner_
<cjohnston> re: last night
<seb128> oh, what did he do?
<cjohnston> he marked them approved in LP, which means LP will not give Summit the info
<seb128> oh, ok
<cjohnston> seb128: for the meetings at the 1500 slot today in client, there are no people required, so it will be an empty hangout
<cjohnston> fwiw
<seb128> hum
<seb128> cjohnston, isn't the lead inviting people?
<seb128> that didn't get very well communicated
<cjohnston> you mark them required and then Summit gives them a link
<seb128> is there some automation?
<seb128> oh
<seb128> I though the link was going to be public
<seb128> lool, ^ you were right
<lool> I hope we don't run into issues with non-canonical.com Google accounts trying to join canonical.com hangouts
<lool> I had trouble with my @gmail being the default logged in account with google trying to join canonical.com hangouts some weeks ago
<didrocks> same here
<jcastro> something was turned on that was enforcing that, that's been shut off
<jcastro> I don't remember the details but they flipped it back
<jcastro> I've been using my non canonical one for team meetins since then and it's been fine
<didrocks> jcastro: ok, let's see how it goes then :)
<jcastro> I didn't say that that would mean that it would all work this morning. For the record, heh.
<didrocks> jcastro: no no no, you *did* personnaly certified it, I have prooves :)
<lool> jcastro: Ok; thanks for confirming this
<lool> I had guessed they had flipped a domain-wide bit at some point, but it's great to hear they flipped it back off
<lool> didrocks: time to put your swimming-suit on
<didrocks> lool: the coffee machine is already on :)
 * rickspencer3 slurps coffee
<rickspencer3> didrocks, lool, jcastro you guys ready?
<didrocks> rickspencer3: more than ever! :-)
 * didrocks hopes that his internet connexion will follow though
<lool> rickspencer3: assuming Didier brings in the coffee in the rooms
<TheMuso> Why are you guys on about coffee? You've been up for hours. :p
<slangasek> cjohnston: pong
<didrocks> lool: now that we have daily release, you think I'm just slackering, isn't it? :p
<rickspencer3> we'll be doing an intro starting in 9 minutes
<cjohnston> slangasek: you were having an issue last night. is that resolved?
<lool> rickspencer3: is that with us?
<jcastro> rickspencer3: I am ready to rock!
<rickspencer3> lool, jono, me, and track leads
<lool> ok
<rickspencer3> an intro with Q+A if there is time
<slangasek> cjohnston: no, I still can't add people as required who need to be there, but I have a theory now that I'm following up quickly
<rickspencer3> it feels weird getting ready for something this important, but being in my normal office
<cjohnston> ok
 * tvoss is ready for UDS :) 
<lool> rickspencer3: I guess track leads will present each track; let me know if there's some specific topic you want me to cover
<didrocks> lool: you may soon start to be the coffee man :p
<lool> (I am happy to present track contents too except for cloud and community and I'd likely not be able to present an exhaustive picture)
<barry> where's the continental breakfast?
<slangasek> on your continent
<tumbleweed> barry: it's the first day, you're supposed to still be able to wake up on time
<TheMuso> barry: In 6 hours. My body is still sleeping at this time. :p
<barry> tumbleweed: i was told there'd be gluten free muffins
<ogra_> i ate them all !
<barry> ooooggraaaaaa!
<ogra_> :)
<TheMuso> lol
<barry> will jono tell us to eat our veggies?
<didrocks> jono_: yes
<tumbleweed> pgraner, rickspencer3: would moving community-1303-rolling-release before the plenaries be possible? (conversation moved from #ubuntu-motu)
<rickspencer3> tumbleweed, I'll check after the kickoff
<seb128> tumbleweed, moved to 16:00 in community 1
<tumbleweed> seb128: ta
<slangasek> cjohnston: right, my problem is required people not being registered for UDS
<slangasek> cjohnston: so, prodding them to fix on their end
<cjohnston> slangasek, glad you were able to figure it out! :-) let me know if you need help
<ogra_> heh, psusi found a fanboy on the devkit-devel list :P
<psusi> ogra_: I can't tell what the hell he was saying... was it sarcasm because he thought I was a "hater"?
<ogra_> psusi, see "2 users simultaneous access to udisks2 mounted drive" ... he started that on feb 12th
<ogra_> i think he is actually fanboying in a weird style
<ogra_> he was talked down with his (rather hackish) proposal
<psusi> so he likes my idea and was simultaniously venting frustration? boy... that does *not* translate well into written language
<ogra_> hahaha, yeah
<ogra_> i just got it because i read the former thread
<psusi> what do you think of the idea?
<ogra_> ++
<ogra_> but upstream will not like it i fear
<ogra_> its their way or none
<psusi> I'm still trying to figure out why in raring I now have two different udisks installed and running, and neither of them seem to be able to read my SMART status
<psusi> smartctl works just fine still of course
<ogra_> you should only have udisks2
<psusi> I seem to have both
<ogra_> i think pitti tried to get rid of the older one
<ogra_> but probably there are still universe packages unported
<pitti> usb-creator still pulls in udisks1
<ogra_> ah
<pitti> xnox is porting it to udisks2
<xnox> pitti: I did, and it segfaults =) i need to fix it up.
<xnox> psusi: something has activated udisks1, since by default udisks1 is not running it's only started when usb-creator is launched.
<psusi> why the big API breakage?
 * xnox is clearly sees network manager dropping wifi connection periodically.
<slangasek> arges, pgraner, Ursinha: hangout open for http://summit.ubuntu.com/uds-1303/meeting/21603/community-1303-plusone-maintenance/
<tvoss> seb128, did you open the hangout yet?
<didrocks> how should we receive the link for required attendees? Seems the hangout is opened but no link on the page
<arges> slangasek: thanks, do you need me on the hangout. I think i'm probably more of an observer. : )
<slangasek> arges: don't need you, but you're welcome
<arges> slangasek: awesome thanks
<slangasek> arges: and we can always rotate you in later if you decide to
<slangasek> cjwatson: do you want to be in the +1 maintenance hangout this morning?
<tvoss> jasoncwarner_, do you run the refactor and cleanup session?
<cjwatson> slangasek: Yes please
<jasoncwarner_> tvoss: ?
<jasoncwarner_> oh tvoss no, seb
<tvoss> seb128, ping
<tvoss> seb128, got a hangout invite for me?
<seb128> tvoss, you should have it in the summit details
<seb128> tvoss, http://summit.ubuntu.com/uds-1303/meeting/21608/client-1303-refactor-platform-api/
<seb128> no?
<jasoncwarner_> seb128: people say they aren't getting invited...I'm pasting URL directly
<seb128> jasoncwarner_, ok
<jasoncwarner_> didrocks: can you take notes for this?
<didrocks> jasoncwarner_: already started :)
<Riddell> mpt: how about adding a topic to community-1303-rolling-release about whether this should be done for raring?
<mpt> Riddell, ScottK suggested that, I just haven't gotten down that far in the thread yet :-)
<mpt> (ah, just got to Stefano saying the same thing)
<slangasek> mhall119|afk: so, what's the expectation with the recordings - I guess I need to do something in youtube to get them published?
<lfaraone> dholbach: can we register a GSoC discussion in the Community track? (preferably scheduled after 6PM EST / before 10AM EST)
<bankix> Hi.
<bankix> I coudn't find the exact command line (genisoimage-call) which was used to create the ISO image for Ubuntu 12.10 or 12.04.2. Maybe someone know where it's documented and give me a pointer?
<seb128> something keeps changing the level of my input source, does anyone know if that google hangout itself?
<didrocks> seb128: yeah, it's a hangout feature
<didrocks> seb128: you can disable it though
<seb128> didrocks, where?
<didrocks> seb128: http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring
<didrocks> ~/.config/google-googletalkplugin/options
<didrocks> swith audio-flags to 1
<didrocks> kill the plugin
<seb128> didrocks, ah, file, I was looking for it in the ui :p
<didrocks> restart it
<didrocks> this will remove audio level autoadjustement
<seb128> didrocks, thanks
<didrocks> yw seb128 :)
<Laney> yeah I applied that just before this UDS in the hope that it will stop me randomly muting
<dholbach> lfaraone, can you file a blueprint for it? community-1303-summer-of-code or some such - propose it for 'ubuntu' on https://blueprints.launchpad.net/sprints/uds-1303
<dholbach> lfaraone, then I can accept it and see if there's still a slot where we can put it
<lfaraone> dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-1303-summer-of-code
<dholbach> thanks lfaraone
<dholbach> lfaraone, accepted the blueprint, will take a while to show up in summit - then I'll check where we have an open slot
<lfaraone> dholbach: stellar.
<lfaraone> dholbach: this year's GSoC deadline is Mar 29, it'd be nice to meet it :)
<dholbach> lfaraone, totally - did you guys get my email?
<lfaraone> dholbach: I believe so
<dholbach> ok cool
<lfaraone> dholbach: also, uh, I'm still waiting on reimbursements for UDS-P and I never received a responseâ¦ who should I contact?
<lfaraone> dholbach: actually I think the last mail I have from you about GSoC was from december.
<dholbach> let'S move to query
<hallino1> Good evening all
<hallino1> I'm new on development and I want to upgrade a .deb file from source.. Teamspeak .deb on repository is outdated and i want to update it but I don't know how to do.. Someone can help me please?
<dholbach> lfaraone, today 18:15
<lfaraone> dholbach: oof, is there space tomorrow at the same time?
<dholbach> lfaraone, that was the only free slot in the community track
<dholbach> lfaraone, you might have to ping some other track leads to see if they still have an empty slot
<dholbach> http://summit.ubuntu.com/uds-1303/2013-03-05/ and http://summit.ubuntu.com/uds-1303/2013-03-06/
<lfaraone> dholbach: thursday isn't scheduled yet it looks like?
<dholbach> there's no thursday
<dholbach> well there is
<dholbach> but not part of UDS
<dholbach> lfaraone, ^ also I subscribed all you guys to the blueprint
<lfaraone> dholbach: could we swap with something at 14:00 UTC tomorrow?
<dholbach> lfaraone, can you join #ubuntu-community-team?
<pitti> cjwatson: I know you are rather firmly against syncing from testing, but WDYT about some middle ground like syncing from unstable after they spent $urgency days in unstable, and not autosync if there are new RC bugs?
<pitti> cjwatson: (I haven't thought about this very deeply, it just came to my mind)
<slangasek> pitti: the big problem, I think, is the very large corner case of transitions
<pitti> slangasek: but those are already caught by britney
<slangasek> pitti: if the maintainer has uploaded 10 packages for a transition, and the package at the base of that transition has an RC bug, what happens in raring-proposed?
<pitti> slangasek: I was thinking about catching the worst functional bugs
<slangasek> in practice what I think would happen is that we would make -proposed a tangled mess
<pitti> slangasek: wouldn't it be better to hold that off then? I'd say it would
<seb128> slangasek, what will happen in this case if we sync from unstable anyway?
<seb128> we will get the RC and the not finished transition
<cjwatson> pitti: It's technically possible, but TBH I think adding an artificial delay just means we get to wait longer for regressions to be fixed; I'm not sure I see it protecting us against must
<cjwatson> pitti: I do think we should do something with RC bugs, though I
<cjwatson> 'm not sure exactly what
<cjwatson> (I posted something to ubuntu-devel about that recently)
<slangasek> pitti: the problem is that the RC bug list only gives you information about holding off *one* of the packages, and it's possibly the worst one to hold off
<pitti> cjwatson: hence waiting for some days, so that people have some time to actually file them
<cjwatson> I think the delay is the most harmful part
<slangasek> because then you've imported the other 9 packages which now misbuild or ftbfs and you have to clean up 10 packages by hand
<pitti> slangasek: yeah, it's obviously not ideal
<cjwatson> So I really want to avoid it
<pitti> I wouldn't like to wait the potentially infinite delay that testing migration would have
<cjwatson> I appreciate that a delay guards against some functional bugs, but I think the flip side is worse
<pitti> ok; seems this was already discussed then
<cjwatson> We should definitely do something about *Ubuntu* RC bugs, if nothing else so that there's a better workflow than "bug release team member to install a block"
<pitti> cjwatson: but people wouldn't even see the new version until it's already in the RR, i. e. too late:
<cjwatson> You yourself have a couple of times asked for a block immediately after upload
<cjwatson> That's time enough
<cjwatson> And there's the brown-paper-bag case
<cjwatson> Also I'd like to have some downward pressure on Critical priority bugs; we don't have much such pressure at the moment and the effect is that you really can't use the Critical list as a guideline of anything much
<cjwatson> Which seems rather a shame
<pitti> cjwatson: I usually ask before a new pygobject upload, until we have britney autopkgtest integration
<pitti> cjwatson: but for autosyncs we don't have that "oh sh*t" window after dput
<cjwatson> There's a window before it builds and publishes
<cjwatson> Sure, not a very long one, but it's sometimes enough to notice a problem
<cjwatson> And certainly for "oh damn I'm not sure I meant to upload that", it's enough
<pitti> cjwatson: I think we are talking about two different things here
<pitti> cjwatson: I'd like to put some additional delay/checks for autosyncs, not for ubuntu uploads
<pitti> as otherwise we'd routinely import new unstable uploads which other people already identified as having an RC regression
<cjwatson> One possibility would perhaps be to get confirmation from +1 maint (somehow) before autosyncing packages with RC bugs
<cjwatson> I really really really don't like the idea of an automatic delay, but if some human is actually on the hook to be responsive, it might be OK to reduce the level of automation?
<pitti> we could try that at least
<cjwatson> auto-sync is already not your grandfather's auto-sync
<cjwatson> Though most of the newer intelligence is related to syncing entirely new packages
<cjwatson> I definitely think there's room to make it smarter, and I think it can be better than a simple delay
<pitti> my main aim is at new Debian RC bugs; but if we want to use them, then we need some delay so that people can actually file them
<cjwatson> Well
<pitti> if we don't want to take RC bugs into account, we won't need that of cours
<pitti> e
<cjwatson> Depends.  We could do a better job of tracking new Debian RC bugs for things we've already imported
<cjwatson> Very very few of them will be kitten-killing regressions
<cjwatson> I mean, right now we basically don't track new Debian RC bugs at all
<cjwatson> slangasek makes a good point about this idea exacerbating import ordering problems though.  We already have this problem with merges, but at least merges by definition have a human who at least peripherally cares associated with them
<cjwatson> Extending the problem to the entirely automated case is ... troublesome
<pitti> it would certainly lead to a lot more things being held back in -proposed
<cjwatson> I think this is a situation where I would rather do after-the-fact cleanup, on the basis that any negative consequences of that are likely to be on the whole less severe
<cjwatson> But that does mean we have to actually track it rather than hope :-)
<pitti> ok; it may make sense to actually do this, and do some post-mortems on concrete cases where this actually bit us
<cjwatson> Yeah
<pitti> right, either way it'd be more human effort (watching RC bugs pre- or post-import)
 * Laney idly wonders if it would be worth not autosyncing things which start transitions
<seb128> Laney, +1
<slangasek> Laney: ITYM things which are /involved/ in transitions... otherwise you get the problem again that you've synced the leaf packages that were uploaded for the transition, but not the base of it
<seb128> otherwise you get a set of packages stuck in proposed until the transition is complete, which might take weeks and block important packages
<Laney> mmm, that's harder to determine though
<cjwatson> I don't see why we should particularly worry about transitions, given that they're exactly what we already have the best handling of
<cjwatson> Seems like solving the wrong problem
<cjwatson> Dunno
<cjwatson> (And if we have -proposed backing up and it's a problem, poke +1 maint, this is in their remit to deal with)
<Laney> Seems to be better when someone has skin in the game to push them through. Granted though that +1 can look after them, not that they wouldn't have stuff to do otherwise.
<seb128> cjwatson, well, let's say that there is a libpng transition that start (or something not trivial) which will includes hundred of packages and block e.g unity from landing ... it means we might hold off any unity work for weeks the time we go through the transition
<pitti> seb128: that's quite different than what I was talking about, though; the new libpng is very likely not having any functional regressions, i. e. RC bugs attached to it
<pitti> seb128: (it still is a problem, of course, just a different one)
<Laney> Functionality bugs is the area where we have worst coverage indeed
<seb128> pitti, sorry i didn't read the full backlog or implied it was what you were talking about
<seb128> pitti, but it's another issue syncing from unstable
<seb128> you might catch the start of a transition that will takes weeks to go through
<seb128> and that will lock proposed meanwhile
<pitti> right
<cjwatson> seb128: I understand the concern - what I'm saying is that if *any* transition takes weeks then that is a problem in itself, regardless of what it blocks
<pitti> if we would do any large transition on the Ubuntu side, we'd probably stage it in a PPA or equivalent, not in -proposed
<seb128> cjwatson, well, if you sync from testing the transition is already done and it doesn't take weeks
<Laney> and my proposal hoping to avoid things taking weeks, because developers get to choose when they happen
<cjwatson> And that I'd rather fix that by making the transitions happen, not by deferring the transition
<cjwatson> seb128: And there are *soooo* many other problems
<cjwatson> It's not worth it
<cjwatson> Also, you actively create problems that way by inverting the build order vs. Debian
<cjwatson> In many cases
<Laney> Because of binNMU you'd mostly end up syncing things which had to be uploaded for API changes which are exactly the packages you don't want
<Laney> hmm
<cjwatson> And syncing from Debian testing doesn't magically make transitions happen for us - we still have to rebuild things that were binNMUed in Debian, and we'll still run into cases where something fails to build in Ubuntu but not in Debian
<cjwatson> So it doesn't solve the problem anyway
<pitti> that's something we have to deal with for a rolling release anyway
<pitti> you can't have "crack of the day" for all packages and robust quality at the same time
<cjwatson> I guess I mostly think that if we're doing a rolling release we can't simultaneously be scared of change
<seb128> well, dealing with a few build failures is easier than to carry through a big transition that only started in Debian
<janimo> pitti, do you know of an uptodate and comprehensive document that describes Ubuntu plumbing components, to be used as a starting point for introducing someone to the big picture?
<psusi> am I off base in expecting to be able to chroot into another system fs and run an apt-get dist-upgrade?  isn't that why we use invoke-rc.d?  so you can do this and NOT have rogue daemons spawned from the foreign system?
<pitti> janimo: I don't think we have one in one big document
<slangasek> psusi: you have policy-rc.d in place?
<slangasek> psusi: being in a chroot doesn't by itself determine any policy for whether services should start; you have to declare this with policy-rc.d, which some of the chroot-creating tools do for you
<psusi> slangasek: it seems like it should since invoke-rc.d won't run things that arne't supposed to be run in this runlevel, and there *is* no runlevel in the chroot
<psusi> and it seems to mostly work, but it looks like some jobs that have been ported to upstart *are* being started, and much to my surprise, initctl still works in the chroot
<psusi> and more annoyingly, initctl outside the chroot shows no evidence that upstart is managing any of the jobs in the chroot, yet *something* keeps restarting them when I kill them
<slangasek> psusi: upstart has chroot support; packages with upstart jobs are not exempt from using the invoke-rc.d abstraction.  Do you have a specific example?
<slangasek> right, upstart has notions of chroot "sessions" which are managed in a separate namespace
<slangasek> jodh: ^^ is there a way to use initctl outside the chroot to list jobs associated with a chroot?
<slangasek> oh that's bizarre, why does my raring chroot not have /sbin on the path?
<psusi> ohh, so upstart *is* managing the jobs of the chroot session, and I'm just not using the right fu to see it?  whew... that actually makes sense... was losing my mind there
<slangasek> psusi: right - and upstart jobs are, of course, much harder to kill than things started by init scripts without process supervision :-)
<psusi> now... why is upstart reachable from within the chroot?  isn't that a bad thing?  unless you explicitly link the socket into the chroot?
<slangasek> no, it's by desin
<slangasek> "link the socket" - upstart uses magic namespace sockets that Just Work <tm>
<slangasek> if you want them to not work, you use a container rather than a chroot
<psusi> I noticed... and very much don't like that ;)
<psusi> hrm... I dont recall seeing anything that indicated the magic namespace wouldn't be shared in a container
<slangasek> well
<slangasek> I can assure you that this is the case, otherwise people wouldn't be able to run upstart in a container and they are able to :)
<slangasek> psusi: anyway, to the earlier question... were you seeing this problem with particular upstart jobs?  I want to make sure nothing's bypassing invoke-rc.d inappropriately
<slangasek> but my recollection is that invoke-rc.d doesn't care about unknown runlevels in any case, so that's probably a bug on invoke-rc.d to request a behavior change
<psusi> slangasek: nmbd, rsyslogd, crond, atd, acpid, whoopsie
<slangasek> psusi: I know for sure that nmbd doesn't have broken invoke-rc.d handling for its upstart job, so sounds like you're just getting bitten by invoke-rc.d default behavior and not having policy-rc.d
<psusi> from what I can see, if `runlevel` fails ( which it does, since there is no utmp in the chroot ), then invoke-rc.d doesn't run anything
<psusi> since it can't verify that it should run it in this runlevel
<slangasek> psusi: in practice, that doesn't seem to be what happens
<psusi> so... why does upstart want to manage jobs in a chroot? ( and not seem to have a way to admin them outside the chroot )?
<BenC> Anyone (possibly network-manager or libnl3 maintainer/developers) know how to debug netlink message sources from the kernel?
<slangasek> cyphermox: ^^ :)
<BenC> I'm debugging a cpu hogging bug in network-manager and I've traced it to the network interfaces being up causing an endless supply of netlink events coming from the kernel, but I can't figure out how to find out where those messages are coming from because of the abstraction in the kernel
<cyphermox> BenC: ahah, yes, I know how to do it, to some degree :)
<cyphermox> BenC: what release though, is that in raring?
<BenC> raring
<BenC> 3.8 kernel
 * cjwatson gets lost in gdb
<cyphermox> BenC: you know you can run NM in NLDBG=3 NLCB=debug ?
<cjwatson> Actually, hmm, I guess if I'm looking for a sample implementation of the target side of the gdb remote protocol, gdb itself is the wrong place to look (it has examples, but not for amd64)
<cyphermox> you can see all the netlink messages that way, but it's a huge amount of info
<BenC> cyphermox: Right, I've done that
<cyphermox> ok
<BenC> But it just shows this loop of nondescript messages, which appear to be triggering the link up/down callback
<BenC> constantly in up state
<cjwatson> Hm, maybe gdbserver
<cyphermox> BenC: can you share the messages you're wondering about, just so we're both on the same page?
<BenC> cyphermox: Give me a sec
<BenC> cyphermox: https://bugs.launchpad.net/network-manager/+bug/1111926
<ubottu> Launchpad bug 1111926 in NetworkManager "NetworkManager increases CPU utilization" [Critical,Confirmed]
<BenC> last comments
<cyphermox> aye
<cyphermox> so yeah, seems like either the kernel is doing something funny, or we're trapping a netlink message in NM that we perhaps shouldn't be
<BenC> cyphermox: Right, that's where I am now, but I can't seem to figure out where this is all coming from kernel sideâ¦any thoughts on where to go from here?
<BenC> cyphermox: If I bring down all of the interfaces (2x1G and 2x10G), it stops the congestion
<cyphermox> BenC you'll want to look at the NM code to match up what message you're receiving exactly
<cyphermox> and then finding its source in the kernel
<cyphermox> that's why you want NLCB=debug, you should be seeing the actual message
<BenC> cyphermox: well, it's calling link_msg_handler() so I assume it's a link up
<BenC> cyphermox: and no, NLCB=debug isn't showing the type of message for this part (it shows it for the other messages, but not this slew of messages)
<BenC> cyphermox: on sec...
<cyphermox> BenC: looking at the code
<BenC> cyphermox: just pasted a loop snippet with NLCB=debug just to be sure
<BenC> cyphermox: I see it decoding the other (normal) messages, but not these
<cyphermox> BenC: always flags 0x11043?
<BenC> cyphermox: yes
<cyphermox> doesn't say much :(
<cyphermox> let's try something
<BenC> cyphermox: I haven't ruled out that this (rare and under tested) ethernet driver isn't doing something stupid, but since it isn't calling netlink directly, I'm not sure how to find out what it's doing wrong
<cyphermox> BenC: we'll be able to say whether it's NM or the driver now
<cyphermox> BenC: what does ip monitor say if you just leave it running?
<cyphermox> 'ip monitor'
<BenC> Should I leave NetworkManager running at the same time?
<cyphermox> it shouldn't matter
<BenC> Without NM, it just shows eth5 as being up, which is correct
<cyphermox> I guess it can't hurt to try it without
<cyphermox> not jumping up and down?
<BenC> Nope
<cyphermox> ok
<BenC> 192.168.0.5 dev eth5 lladdr c8:bc:c8:ee:68:ba REACHABLE
<BenC> 192.168.0.1 dev eth5 lladdr 2c:9e:5f:ca:c5:e3 STALE
<BenC> 192.168.0.5 dev eth5 lladdr c8:bc:c8:ee:68:ba STALE
<cyphermox> and with NM running, it becomes a mess?
<BenC> That's the three messages it has show, and now it is idle
<cyphermox> makes sense so far
<BenC> Yep
<BenC> With NM, it spews messages
<cyphermox> BenC: could you attach some to the bug?
<BenC> cyphermox: http://paste.ubuntu.com/5588528/
<cyphermox> if you're running nm-applet. is the icon also updating?
<BenC> cyphermox: done
<BenC> cyphermox: I am not using desktop
<cyphermox> ok
<BenC> cyphermox: I'm heading out for lunchâ¦will you be around for awhile?
<BenC> Any posts to the bug, I can check on later
<cyphermox> yeah, should be for a few hours
<cyphermox> worse case I'll get back to it later
<cyphermox> BenC: what you could do is run NM in debug and also attach the logs for that to the bug
<cyphermox> looks like an issue in NM, not in the kernel
<cyphermox> (otherwise you should see the same in ip monitor with NM not running)
<BenC> Good to know
<BenC> cyphermox: thanks, and hopefully I'll be back later with more info, or we can continue this debugging
<cyphermox> I think it's trying to bring the device up, but failing to do some for some reason
<cyphermox> BenC: sudo /usr/sbin/NetworkManager --no-daemon --log-level=debug > nm.log 2>&1
<cyphermox> I'll wait for your input
<mterry> cjwatson, I'm not sure if you will notice, so I'll manually ping you that I requested a comment in bug 430197
<ubottu> bug 430197 in update-manager (Ubuntu) "Disable partial upgrades during a development release" [Medium,Triaged] https://launchpad.net/bugs/430197
<cjwatson> mterry: replied
<mterry> cjwatson, thanks
<cjwatson> (twice, even ...)
 * slangasek launches the Foundations day 1 beering Google hangout
<jcastro> wait, you have a beer hangout?
 * tumbleweed is already well beered
<jcastro> Why didn't I think of that?
 * cjwatson should probably go for dinner instead ...
<slangasek> cjwatson: xnox also went to dinner, I've promised to keep the hangout around for a while if people want to join after dinner :-)
<soren> doko: Hi. Would you have any objection to me uploading ruby1.8 adding -fno-tree-dce to CFLAGS to address bug 1142977?
<ubottu> bug 1142977 in ruby1.8 (Ubuntu) "Timeout module segfaults" [Undecided,Confirmed] https://launchpad.net/bugs/1142977
<Maccer> Any raring python 2.x maintainers on? There was recently a fixed regression, but I want to confirm if I have found one myself.
<slangasek> Maccer: the developer doing most of the maintenance of python2.x is at a conference currently
<slangasek> Maccer: perhaps you could file a bug report?
<TheLordOfTime> and perhaps he can not crosspost
<TheLordOfTime> he posted in #ubuntu-bugs too
<slangasek> well :)
<TheLordOfTime> of course, jtaylor asked them what the issue seemed to be, and we've heard nothing back yet. (> 10 minutes(
<TheLordOfTime> ... and i hit enter on that a seconda fter a response
 * TheLordOfTime facepalms
<Maccer> I have mintmenu on my system, which is a .py XFCE/GNOME2 applet. Since upgrading from 12.10 (quantal?) to raring, the script has stopped launching this gtk event that spawns the application you selected. The script itself has not changed in quite a while and received no update from raring, and is not frequently maintained anyways.
<Maccer> <maccer> But I really suck at python, so it's hard for me to trace the error. But it's either the fact that applications won't launch because a gtk event is not called, or a process just won't launch.
<Maccer> Just for you TheLordOfTime
<TheLordOfTime> GAH!  CROSSPOST
 * TheLordOfTime explodes
<TheLordOfTime> (sorry for the random, but i really dislike crossposting)
<BenC> cyphermox: http://paste.ubuntu.com/5588747/
<BenC> cyphermox: still around?
<BenC> cyphermox: one thing I noticed is that the two interfaces that are not connected, "ip monitor" keeps showing them as "state UNKNOWN" as opposed to being DOWN
<BenC> cyphermox: would that cause it to keep requesting to bring it up?
<roby100> hello
<cyphermox> BenC: possibly
<cyphermox> BenC: or perhaps something is fighting with NM to give the device an IP address
<BenC> cyphermox: I have an idea of the issue
<BenC> cyphermox: ethtool shows that the devices (which are not physically connected) claim to have a link active, when it shouldn't
<cyphermox> ok
<cyphermox> what driver does this use?
<BenC> So NM might be confused that if it shows link-active, why isn't it getting an actual link (as opposed to link UNKNOWN)
<cyphermox> could it have an issue with carrier sensing?
<cyphermox> yeah
<BenC> cyphermox: dpaa_eth (only found on certain ppc hw)
<cyphermox> ok
<BenC> cyphermox: So this bug may be two-fold: 1) NM should stop screwing around with interfaces that show this issue, and 2) I need to figure out why the driver shows link-active when it clearly isn't
<cyphermox> BenC: 2) is going to fix 1) too
<mlankhorst> BenC: no the kernel should be fixed instead :-)
<BenC> The kernel should be fixed, because this is clearly broken
<cyphermox> it's a tough issue -- you can't easily tell the difference between a broken driver and a device that is genuinely being disconnected and reconnected ;)
<BenC> But NM should recognize bugginess and not turn into a CPU whore when this condition exists
<cyphermox> I guess there could be a bit of a backoff though, if it's happening too fast
<BenC> cyphermox: At the very least, NM should not get into a busy loopâ¦it should drop to polling this interface to once-a-second at most
<cyphermox> BenC: I'm running the new version of NM right now, to be uploaded to raring incessantly
<cyphermox> BenC: we're not really polling for that, just reacting to netlink
<cyphermox> this is precisely the kind of code that is being changed upstream right now though
<BenC> cyphermox: right, but netlink is only returning messages because NM is sending a request
<BenC> NM requests state, state is UNKNOWN, NM UPs link, requests state, state is UNKNOWN, etc
<mhall119> slangasek: it's probably obvious by now, but there's nothing you need to do for the hangout recordings to be published
<slangasek> mhall119: well, they're published under my account only; the question is, do we intend to publish them in aggregate somewhere on youtube?
<mhall119> slangasek: not unless we can find an easy way of doing that, for now the Summit pages will replay the video for that session
<mhall119> so, summit is our aggregate
<slangasek> mhall119: right... except in the case where my computer exploded mid-session, so there are two videos for a single session :/
<mhall119> oh, yeah, that kinda sucks
<mhall119> slangasek: for now you should put links to both videos in the etherpad
<slangasek> mhall119: ah, good point
<dobey> slangasek, mhall119: I suppose you could download the videos from youtube, "merge" them with an editor (don't know if any on ubuntu are good for that), export, and re-upload; then change all the links to the new URL perhaps
<mhall119> dobey: I'm sure you could do that with a little ffmpeg and enough alcohol
<mhall119> but putting links in the etherpad is probably easier
<sarnold> (cat may be sufficient :)
<dobey> sarnold: probably not. i think webm is a bit more complex than that :)
<dobey> (assuming it's even webm that the originals are in)
<sarnold> dobey: eh, could be :/ time was, it worked great.. :)
<kdub> what's the 'right' way to install a quantal package in raring?
<geofft> kdub: Adding the Quantal repos and apt-get install foo=1.2.3-4 isn't wrong, I think.
<geofft> kdub: apt-cache policy foo will show you what version options you have and from where
<sarnold> you may also be able to do apt-get install foo/quantal
<geofft> ah, I keep forgetting that syntax because I think it does the same thing as apt-get -t quantal, which is useless.
<sarnold> oh :)
<sarnold> I've only tried it for apt-get source, where it is also useless. :(
<sarnold> so: useless.
<geofft> It boosts the priority of the quantal repo, but raring still has a newer version
<kdub> ah, thank you for the pointers geofft and sarnold
<kirkland> strange to think UDS is going on...  doesn't really feel like UDS, does it?
<slangasek> kirkland: that's because you didn't join us at the bar after sessions! https://plus.google.com/hangouts/_/323b397156f35d055833e35fc349120240b8332f
<psusi> not the same when you aren't all gathered around a table with cold beers ;)
<slangasek> pitti, cjwatson: have you had any reports of performance regressions in update-manager with the latest update? I'm seeing it take a /lot/ of (cpu) time to display updates in the latest version
<slangasek> psusi: I've been happily clinking my glass against the web cam lens, I don't know what the problem is ;)
<psusi> heh.... free booze also makes everyone's day brighter ;)
<slangasek> pitti, cjwatson: as in, according to ps it takes 2m10 of cpu time before it shows anything
#ubuntu-devel 2013-03-06
<slangasek> pitti, cjwatson: hmm, so I notice that the startup time is the same if I call update-manager with --no-update as without; so whatever it's doing takes a long time, and the question of whether it checks the server for updates seems to have no impact
<infinity> jbicha: Please don't arch restrict just to hide build failures.
<infinity> jbicha: porters use the FTBFS list as a TODO list, there's no harm in having things not build that need porting/fixing.
<infinity> jbicha: (Backing out your openimageio diff)
<infinity> jbicha: One of those build failures is a simple qreal porting exercise, the other is just using GCC intrinsics properly, neither one is a fundamental "this can only work on x86" issue (like, say, nvidia binary blobs).
<jbicha> infinity: ok...but wouldn't the package be stuck in -proposed?
<infinity> jbicha: No.
<infinity> jbicha: proposed migration ensures that things are built on the arches where they were previously.
<infinity> jbicha: And since this was always FTBFS on arm/powerpc, that'll work fine.
<jbicha> infinity: thanks, the proposed migration was the only reason I did that
<infinity> jbicha: If you've been doing this sort of thing more elsewhere, can you please undo it?
<infinity> jbicha: proposed-migration is the same as Debian testing in this regard.  Testing only cares about build regressions, if something's never built on an arch, it's fine if it continues to not do so.
<infinity> (And, conversely, if it HAS built elsewhere before, it's a bug when it stops doing so, and we should generally try to fix it, not ignore it)
<micahg> infinity: and livecd-rootfs changes you were planning to make?  if not, I'll go ahead an upload changes for Ubuntu Studio
<micahg> *any
<pitti> good morning
<pitti> slangasek: no reports, but I just tried to check that, and update-manager crashes right away with "ImportError: No module named UpdateManager.UpdateManager"
 * pitti reinstalls it, I think I've seen this before when attempting to sponsor a branch for mterry
<pitti> ok, that worked
<pitti> slangasek: so just calling "update-manager" here takes some 10 seconds, then shows me the updates
<pitti> slangasek: (I did run apt-get update just before, though, so updating indexes was fast)
<FourDollars> Who can help me to review https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 ?
<FourDollars> It is just a litte typo.
<FourDollars> s/litte/little/
<micahg> infinity: nevermind, I'm uploading
<jefimenko> does anyone here know how to run the equivalent of debuild using pbuilder-dist? "pbuilder-dist build" requires a .dsc file
<lifeless> is there a pdebuild-dist ? There is a pdebuild
<slangasek> pitti: interesting
<jefimenko> yes, there is pdebuild
<jefimenko> and pbuilder-dist
<jefimenko> the man page for pbuilder-dist says that the `operation` argument can be any operation that pbuilder supports
<jefimenko> one of those operations is debuild, but pbuilder-dist errors out when i try to use it
<infinity> micahg: Checking bzr for pending changes would have worked, but I don't think anyone has any.
<infinity> micahg: Oh, and you committed to bzr anyway.  So, yay.
<pitti> yay for apt-get autoremove cleaning up old kernels
<mitya57> doko: when was the last time you built those docs successfully?
<mitya57> maybe it's related to https://bazaar.launchpad.net/~mitya57/ubuntu/raring/python-docutils/0.10-1ubuntu1/revision/32
<doko> mitya57, see the publishing history
<mitya57> yes, the previous version was built with old docutils
<mitya57> let me look at the docs source
<mitya57> looks like it fails to process lines like ".. _getting-started:"
<testi> Will Applications compiled for Mir run natively without compatibility layer (protocol translation, additional context switches) on Wayland Compositors? Does that apply for the other direction too? By application I mean anything not deeply integrated with the system, especially games, because under no circumstances I want Mir to introduce any delay (context switch, protocol translation) only because some game developer has chosen Mir as ta
<testi> Is Mir capable of reliable bypass offscreen on fullscreen? (also in order to reduce delays)?
<Laney> ubuntu
<Laney> err, #ubuntu-mir is where you'll get proper answers to mir questions
<testi> okay, thanks
<xnox> slangasek: pitti: i have been noticing significant cpu usage from update-manager with top when my system is in swapdeath / under heavy load.
<Adri2000> it seems that pkgbinarymangler removes upstream changelog without removing the associated symlink if there is one (created by dh_installchangelogs -k). that leaves a broken symlink in the package. bug, right?
<seb128> Adri2000, does the package depends on a binary that provides the symlink target?
<Adri2000> seb128: no
<Adri2000> it's all in the same package
<seb128> k, dunno then
<infinity> Adri2000: Sounds like a bug to me.
<infinity> Adri2000: Assuming the behaviour actually matches what you described.
<mitya57> doko: lp:~mitya57/ubuntu/raring/python-docutils/disable-references-patch disables the patch, and I've reported a bug
<mitya57> https://sourceforge.net/tracker/?func=detail&aid=3607029&group_id=38414&atid=422030
<doko> mitya57, ohh, I already had report the bug, see the email
<mitya57> doko: commented there as well, please close it (I'm not able to do that)
<mitya57> it's not a Sphinx issue
<doko> ahh, ok
<mitya57> btw it's a kind of issue that won't happen when britney will test-build all rbuilddepends before copying to -release
<zyga> hey
<zyga> I have a Lenovo G580 laptop, it just stopped booting current raring (it hangs on boot), one thing it does display is "mount: unable to allocate memory" for "/sys/firmware/efi/efivars"
 * zyga hopes that's not laptop bricking on some EFI bug
<hyperair> nah, if it bricked all you would see is a black screen
<hyperair> with no text
<hyperair> no boot logo
<hyperair> nothign
<zyga> yeah, it's not dead-dead
<hyperair> then you have hope
<hyperair> in any case, i think only samsung has a history of making chips that are brickable from supposedly valid commands
<zyga> it seems to be a regression
<hyperair> hmm i think there was an e1000e issue once as well
<zyga> I just booted an earlier kernel
<hyperair> ah
<zyga> let me see if it really works
<hyperair> there you go
<zyga> yup
<zyga> desktop
<zyga> let's see the next kernel
<zyga> so it _works_ on 3.8.0-5
<hyperair> file a bug
<hyperair> and head over to #ubuntu-kernel
<zyga> yeah
<zyga> checking next kernel
<Hobbsee> So long, and thanks for all the fish, guys & girls!
<slangasek> xnox: it's not swapdeath / heavy load for me, except for update-manager itself using the CPU
<hyperair> Hobbsee: you make it sound like you're leaving the ubuntu project.
<Hobbsee> hyperair: I am
<Hobbsee> Still running Ubuntu on a few things though
<hyperair> wat
<hyperair> whyyyy
<Hobbsee> hyperair: It was summed up pretty well in http://doctormo.org/2013/03/06/ubuntu-membership-2/
<hyperair> hmm =\
<hyperair> that's a pity
<Hobbsee> Indeed
<jcastro> Hobbsee: sorry you feel that way!
<ScottK> So long Hobbsee.  I can't say I blame you.  What have you switched to?
 * ScottK doesn't even know what "Technical Architect (Client)" means.
<mlankhorst> presumably the client is a team
<ScottK> No idea.
<ScottK> There was a "Client" track for UDS, so I assume it's somehow related.
<Hobbsee> ScottK: I haven't switched my work machine  & laptop to anything else yet.  We'll see, on that front.  As for the desktop, it's using windows for gaming
<ScottK> Hobbsee: OK.  Maybe we'll see you in Debian then.
<Hobbsee> ScottK: possibly.  You never know :)
<davmor2> guys I did an install from this mornings cd I open the dash I have the cursor in the search bar turning I see the home lens and that's it
<pitti> davmor2: dash search is quite broken right now, didrocks says it's being fixed
<pitti> hm, your's sounds different, though
<didrocks> davmor2: pitti: part of the batch of fix, the lenses are not recommended by default
<davmor2> pitti: sorry I thought I was on the ubuntu-unity channel when I typed this I'm in there now looking through it
<pitti> davmor2: so you hit the right channel after all :)
<didrocks> so if you removed the lenses, yeah, you won't have them :)
<didrocks> (fix is still building)
<davmor2> didrocks: this is a fresh install
<didrocks> davmor2: makes even more sense if you took today's daily :)
<didrocks> yeah, lenses are not installed by default, I missed a build-dep when moving the lens recommendation in a perl script parsing a json file
<davmor2> didrocks: Yeap it's an up-to-date iso
<didrocks> and so the recommends: stenza is empty
<davmor2> didrocks: this is what I see http://ubuntuone.com/4VY5XIUSXNWvpTzctl3hS9
<didrocks> wait for next unity
<didrocks> it's fixing it
<micahg> infinity: I checked the bzr branch, I was looking for conservation of uploads :)
<infinity> micahg: Ahh, the 738th law of thermodynamics.
<jcastro> plenty of room for lightning talks
<jcastro> don't make me start assigning people!
<ev> my debian/control fu is rusty. Is there a way to specify a dependency equal to just the major version component?
<pitti> ev: you can certainly do things like "firefox (>= 3)", it doesn't matter how much prefix you use
<pitti> jcastro: one/two-minute LTs ok as well, I suppose?
<ev> pitti: I thought that might be the case, but dpkg --compare-versions behaved differently so I wasn't certain
<ev> pitti: thanks!
<pitti> ev: orly?
<pitti> people do that all the time with e. g. debhelper (>= 9)
<ev> oh, does it fall over with strictly equals?
<jcastro> pitti: sure, I'm mostly just interested in showing off cool things, so if it's less than 5 that's totally ok
<ev> for example:
<ev> dpkg --compare-versions 1.0.17 '=' '1.0'; echo $?
<ev> 1
<ev> that would make sense, but then how would I express 1.0.x series is fine, 2.0.x wont work
<OdyX> conflicts >= 2~ ?
<pitti> right, or depends <= should probably also work
<slangasek> ev: you'd do it as depends: foo (>= 3), foo (<< 4)
<ev> slangasek: ah, of course! Thanks muchly!
<cjwatson> ev: Depending on what you're doing, the ${source:Upstream-Version} substvar may be helpful too (deb-substvar(5))
<cjwatson> Sorry, deb-substvars(5)
<cjwatson> Only if the dependency is on something else within your own source
<ev> separate package (separately built library depending on the 1.0.x series of Cassandra)
<ev> yeah
<cjwatson> OK
<ev> thanks though!
<slangasek> :)
<zul> mterry:  ping can we get python-json-patch MIRed as well please
<mterry> zul, I didn't notice that MIR
<zul> mterry: i though it subscribed ubuntu-mir
<mterry> zul, doesn't look like it.  Looking now anyway.  But please sub them
<zul> mterry:  just did
<mterry> zul, I talked to the Debian maintainer of the json-pointer package, and he said we probably shouldn't be dropping the openstack-pkg-tools
<mterry> zul, I opened a MIR for it already (it's super tiny, shouldn't be a problem)
<mterry> zul, if we can promote that, we can go back to sync for json-pointer at least
<zul> mterry:  i disagree there is really no reason for that build-depend
<mterry> zul, it only provides some maintainer-oriented functionality now.  But he says that may change in future.  Plus, it forces us to keep a delta.  It's not worth it when we can just MIR it easily.  Is there a reason to actively pursue dropping it?
<zul> mterry:  it doesnt add any value at all and not worth it
<mterry> zul, "worth it"?  What is it costing us?
<mterry> Debian packages do all sorts of things that we aren't directly interested in
<zul> mterry:  its a superflous dependency and a bad idea imho
<mterry> zul, I don't mind a superfluous dependency as long as it is tiny and build-time like this one.  I do mind deltas that don't serve us much purpose.  So can you expand on the "bad idea" comment?  What active harm is the build-dep doing?
<zul> mterry:  its not doing any harm i just dont think its a good idea because the maintenance stuff that is intended for openstack-pkg-tools is not really used in the python-json-patch package or anywhere else
<mterry> zul, I agree it's not actively helping.  But as long as it's not actively hurting, I'd rather avoid the delta
<zul> mterry:  fine
<mterry> zul, I already filed a MIR for it and assigned to didrocks
<zul> mterry:  k
<didrocks> yep
<dobey> hrmm. is there a good overview of how autopkgtests work in practice? i have the spec document open, but it doesn't really say anything about how test runs get triggered
<mitya57> dobey: http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test
<dobey> ah, thanks
<dobey> hrmm
<dobey> "â¦or [when] any of their reverse-dependencies change." <- this is for example the output of apt-cache rdepends $package? or if any of the dependencies listed in Depends: in tests/control change?
<jtaylor> the ones in tests/control
<jtaylor> but it doesn'T work
<jtaylor> (in ubuntu adt jenkins)
<dobey> oh; so tests only get run when the package is uploaded, at the moment?
<jtaylor> it probably depends, some packages to rebuild some don't
<jtaylor> (its a bug)
<mitya57> jtaylor: by the way, any news about scipy tests failing?
<jtaylor> mitya57: the adt tests?
<jtaylor> the atlas one looks ugly
<mitya57> jtaylor: yes, maybe disable it?
<jtaylor> the other one is due to ubuntu compressing png's
<jtaylor> I filed a bug upstream for that
<jtaylor> still need to look at the atlas failure, that will be fun
<mitya57> but why only on amd64?
<mitya57> hm, pyxdg is also failing...
<Laney> fixed that one
<Laney> uploading in 2 mins
<jtaylor> mitya57: which one is amd64 only?
<jtaylor> atlas fails on i386, and that is not unusual for rounding issues
<jtaylor> i386 is horrible concerning that
<mitya57> jtaylor: my wrong, numpy was failing only on amd64, scipy fails on i386 as well
<jtaylor> mitya57: numpy is fixed
<dobey> pyxdg needs to get replaced (removed)
<jtaylor> mitya57: it was just not rebuild due the bug I mentioned earlier
<mitya57> dobey: ???
<dobey> jtaylor: is there any way to say "only run the tests when the deps change, not when it uploads" ?
<jtaylor> dobey: probably not, what would be the use case?
<dobey> mitya57: pyxdg is unmaintained. apps need to move off of it, really
<dobey> jtaylor: well, i don't really want to just run the same tests twice when i upload something (once in the normal source build, and then again in the autopkgtests). seems like a waste of time
<mitya57> dobey: it's now well maintained by Thomas Kluyver â who is also upstream developer
<Laney> I have fixed it
<jtaylor> dobey: true, but you can do in adt tests what you can't do during the build
<jtaylor> dobey: e.g. scipy and numpy, it tests blas, atlas and openblas
<jtaylor> dobey: impossible during the build
<dobey> jtaylor: what do you mean?
<mitya57> Laney: pyxdg? thanks! Will you commit it to Debian or should I do that? :)
<Laney> if you can, feel free
<Laney> it's an upstream cherry-pick
<dobey> jtaylor: i don't quite understand that
<jtaylor> dobey: numpy and scipy can have their blas provider replaced underneath them, during the build I can't install new packages, in adt tests I can (via test dependencies)
<Laney> mitya57: if you take the other patch too then we could sync; shouldn't be harmful on Debian but it's not entirely applicable there either
<Laney> up to you
<mitya57> Laney: I don't yet see the new upload, will look in a couple of minutes (and I can, yes)
<Laney> it's not done yet, that's why ;-)
 * Laney was test building
<dobey> jtaylor: that's a special case though it sounds like. most code probably isn't like that? i mean, unless i can depend on packages from universe in the autopkgtests for a package in main?
<cjwatson> You can
<jtaylor> dobey: you can do that
<jtaylor> dobey: you also test that the binary package is actually usable in adt tests
<dobey> oh, then that might be nominally useful for me then
<jtaylor> dobey: during the build you have everything installed as upstream intended and tests that, binary packages may make mistakes in splitting stuff up
<Laney> mitya57: alright, there we go - perhaps wait and see if it passes in jenkins but feel free to upload at your leisure (or get tumbleweed to do it for you :P)
<Laney> have to go out now - see you later
<tumbleweed> what am I uploading?
<jtaylor> dobey: e.g. gevent, their dbg package is broken, during the build you won't see that, but in adt tests you do (seen in pyzmq)
<dobey> jtaylor: well, "works as intended" with ubuntuone is probably not all that testable in adt either though :)
<dobey> most of the stuff we're already testing in the unit tests anyway, and not much more testing can really be done without actually talking to the server
<jtaylor> another case is ipython which tests stuff only if a mongodb service is running, I can't do that during ab uild, but I can in adt
<jtaylor> but I don'T because mongodb is broken in chroots ._.
<mitya57> Laney: I'll look tomorrow then
<dobey> but for some of the stuff where we use pyqt, we need a package that's in universe to run the tests, so we aren't running all the tests in the package build
<mitya57> tumbleweed: Laney was suggesting to drop ubuntu pyxdg delta by committing it to DPMT
<tumbleweed> ah
<tumbleweed> mitya57: it's team maintained, that's a reasonable approach
<dobey> is there any way to get autopkgtests to work for PPAs as well?
<mitya57> dobey: https://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/doc/USAGE.md#L54
<dobey> mitya57: but there's no infrastructure already set up to do this automatically? i'd have to set up my own jenkins jobs somewhere doing that?
<mitya57> dobey: that's a question to pitti or jibel
<pitti> dobey: technically we can do it, it's just a resource issue
<pitti> dobey: if you mail jibel and toss him a pointer to a PPA and some package names, he can set it up
<pitti> dobey: we already do this for e. g. chrisccoulson's firefox PPA and seb128's gtk
<chrisccoulson> we even get proper test results: https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/69/#showFailuresLink :)
 * chrisccoulson must fix the failures
<jtaylor> :O
<jtaylor> how do you get the test results into jenkins?
<pitti> dobey: e. g. https://jenkins.qa.ubuntu.com/view/Raring/view/All/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/
<dobey> pitti: it would be fine if i had to set it up on a separate jenkins as well (we already have jenkins set up for u1 stuff for testing on windows and landing branches and such, so not a big issue). just wanted to know what's what :)
<dobey> chrisccoulson: jenkins gives you a stormy cloud
<jtaylor> it would be nice when one could see the configurations of the jobs
<chrisccoulson> dobey, ah, i wanted more than a stormy cloud and a 100MB text file though
<dobey> heh
<dobey> oh, that jenkins doesn't use sso
<pitti> dobey: jenkins.q.u.c. is just a r/o mirror
<pitti> dobey: the real one is behind a VPN in Lex, so you won't actually see execution nodes, login, etc.
<dobey> ah right
<lifeless> cr3: ping
<dobey> still, it would be nice to be able to disable running the autopkgtests when their running would be the same as the tests run during the build, except for when any of the dependencies changed
<cjwatson> my concern there would be that there would be no baseline for when they're rerun when deps change
<cjwatson> it's quite possible for the autopkgtest setup files to be wrong even if the unit tests themselves pass
<pitti> slangasek: do you have your systemd changes against 44-10 in some broken-out form like bzr commits, or do I just look at the debdiff?
<dobey> i suppose that's true. i'm just looking to optimize out the bits where it would be unequivocally indifferent from running the tests in the builds, to avoid wasting resources
<dobey> i guess it won't be too big an issue though
<slangasek> pitti: umm I have them in a git tree here which I meant to push somewhere
<slangasek> pitti: speaking of, what's the right way for me to submit my changes to systemd upstream for enabling a Debian backend on timedated?
<pitti> slangasek: or just format-patch origin.. perhaps, then we can directly forward/apply them?
<pitti> slangasek: that's a good question actually; back then I used the debian git, but that still has 44
<pitti> I didn't find a git tree from which mbiebl built his version 195 packages
<slangasek> pitti: I meant for forwarding to systemd upstream rather than Debian
<pitti> oh
<slangasek> well, the 195 packages also aren't published in Debian
<pitti> slangasek: http://lists.freedesktop.org/mailman/listinfo/systemd-devel/
<pitti> slangasek: most patches go there, and it's the fastest way to get them reviewed
<pitti> slangasek: I'm on the list, so if someone acks patches I can push them, too
<slangasek> pitti: great, thanks
<pitti> slangasek: I guess Lennart is fine with me pushing Debianisms :)
<pitti> good night everyone
<ogra_> https://plus.google.com/hangouts/_/914b5784e52c5967784eae44e4b138a346b1ff90?authuser=0 post UDS beer hangout
<chiluk> stgraber, in reference to http://pad.lv/1057358 .... sorry about that..I do have a question about it though.
<ubottu> Launchpad bug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,In progress]
<mbiebl> pitti: http://people.debian.org/~biebl/systemd-198/
<mbiebl> that's not a real git repo though, just some bits I'm currently experimenting with
<mbiebl> which is sufficient to boot a systemd yet
<chiluk> stgraber, the bazaar branch for precise available at lp:ubuntu/precise/isc-dhcp is stuck at 4.1.ESV-R4-0ubuntu5   Is there a newer place for the precise branch?
<stgraber> chiluk: no, you need to pull the current source from LP outside of bzr branches
<chiluk> I'd prefer not to use the patching system if I could instead just use a bazaar branch /
<chiluk> stgraber where?
<chiluk> I ended up using pull-lp-source for the latest debdiff I created.
<stgraber> chiluk: pull-lp-source isc-dhcp precise-updates
<stgraber> right, that's how you have to do it for SRU for isc-dhcp because the UDD branches are busted
<chiluk> I'm still not sure where the logic is that blew away my patch...
<chiluk> but moving the patch above the comment works...
<chiluk> stgraber, anyhow sorry.. do I need to fill out another SRU in 1057358?
<mdeslaur> chiluk: if happens at least twice to every person who touches the isc-dhcp package :P
<mdeslaur> s/if/it/
<chiluk> hah...
<stgraber> chiluk: nope, we can use the same bug, just attach an updated patch to it
<stgraber> mdeslaur: we finally fixed that with 12.10 though!!!
<mdeslaur> stgraber: yes, thanks again :)
<chiluk> I was going to just patch apparmor-profile.dhcpd , but I wanted to be fancy and use the darn patching system
<stgraber> mdeslaur: though we also broke LDAP support in the process and didn't notice until a few weeks ago ;) I pushed an SRU last week that turns on LDAP support in the ldap packages
<stgraber> mdeslaur: because the debian/rules magic dual-build stuff was completely broken and the ldap binary was overwritten by the standard binary
<mdeslaur> stgraber: whoops :) although, meh, maybe it's an acceptable compromise :)
<cr3> lifeless: pong, what's up?
<chiluk> stgraber so you want a modified patch from 5.6 or a patch fixing 5.7?
<stgraber> chiluk: from 5.6 would be easier to review
<lifeless> cr3: subunit v2
<lifeless> cr3: have you seen my blog posts ?
<chiluk> alright.
<cr3> lifeless: dude, what'a coincidence! I just got out of a meeting where I mentionned subunit and testmanager too!
<cr3> lifeless: I haven't seen your blog posts, link? I'll forward to a few colleagues
<lifeless> cr3: rbtcollins.wordpress.com
<stgraber> chiluk: saw the new patch. Thanks, I'll try to review and bundle with other fixes when I have a sec.
<chiluk> that's the fix against 5.7
<cr3> lifeless: any estimate on when you expect v2 to be finalized?
<chiluk> stgraber do you still want me to create a new debdiff against 5.6?
<stgraber> chiluk: it's a simple enough patch that it doesn't really matter. 5.6 would be easier but 5.7 will just take me an extra minute or so
<chiluk> stgraber thanks... I'm still new to how all the patching systems work in Ubuntu..
<lifeless> cr3: soon I hope, the more feedback I get the better :)
<lifeless> cr3: I'd love to be able to replace your custom protocol with v2 ;)
<cr3> lifeless: I haven't touched checkbox in a while, zyga or roadmr should be made aware of this ^^^
<lifeless> cr3: ah!
<lifeless> cr3: well, care to point them at it, or mail me their contact details and I'll mail them a tl;dr summary?
<cr3> lifeless: I was thinking of dropping them a quick email about it, I can cc you too
<lifeless> please
<zyga> lifeless: hey
<lifeless> hi :)
<zyga> lifeless: subunit you say? I read about your v2 work
<lifeless> zyga: ah cool
<lifeless> so yeah, I know checkbox has a reporting format, and I'd like to be sure that subunit v2 is at least an in-principle suitable candidate for you
<zyga> lifeless: as for checkbox, we're not using it actively
<zyga> lifeless: so we have a rewrite going on
<zyga> lifeless: the core is mostly rewritten now
<zyga> lifeless: we have a concept of exporters where all the test data can go to
<zyga> lifeless: we have json, (now removed) yaml, rfc822 and custom certification xml outputs
<zyga> lifeless: and a plain-text human readable output
<zyga> lifeless: who would be a consumer for subunit exporter?
<lifeless> zyga: your server ? Testrepository? Anything doing data mining?
<zyga> we don't have a server, we only send data to certification rewrite that only eats the xml I've mentioned
<zyga> I don't mind having that exporter but I don't know if it's applicable - the exporter is given a session state object that has all of the state, all the test that went by, all the output, all the user feedback, everything
<zyga> then it has to produce some text to a stream
<zyga> there's a sub-layer there that can select a subset of data
<zyga> and we actually do that, also transforming from the objecet graph to something that can be easily json.dump()'ed
<lifeless> well
<zyga> which is also what most derivative exporters consume to be customizable
<lifeless> so the idea of subunit is to avoid the buffering issues that e.g. xml has
<lifeless> and support concurrent tests
<zyga> we alredy buffer everything
<zyga> we don't do any concurrent testing
 * zyga sounds negative but I don't see how we could take advantage of that
<lifeless> fair enough
<zyga> we buffer and save to disk because jobs can crash machines (and do)
<zyga> so we took a painful careful road to save stuff sanely
<lifeless> right - thats what subunit is meant to tackle
<zyga> so we have everything stored on disk anyway
<lifeless> distributed lossy testing - just emit the events as they happen, direct onto the network.
<zyga> lifeless: it would not store everything the way we need I suspect, our resume logic is not a serialization problem
<lifeless> if the machine crashes you know it did because you only see the test start event not the finish
<lifeless> ok
<zyga> do you have docs docs on your v2 work?
<zyga> (I only read the blog headline)
<lifeless> I do, I will dig up in a bit, OTP just now.
<zyga> k
<zyga> lifeless: I'll look at them but frankly, it would probably require us to reachitect the core a little, to put subunit storage as the center of our state holiding
<zyga> lifeless: and I don't think there's anything we gain, apart from a dependency and code sharing
<zyga> lifeless: and correct me if I'm wrong but isn't subunit just equivalent to protocol buffers, json, yaml *records* being written somewhere?
<lifeless> its the semantic rules that matter - the serialisation isn't interesting
<lifeless> http://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/ is the first blog post
 * zyga got a message from cr3 about subunit 2
<zyga> lifeless: some parts of subunit seem like our io_log
<lifeless> https://github.com/rbtcollins/testtools/blob/streamresult/doc/for-framework-folk.rst#extensions-to-testresult is framework author docs around the API you get
<zyga> lifeless: which I fully agree we have a shit implementation of, but that's fine for now
<zyga> lifeless: any chance for testtools.rtfd.org?
<zyga> lifeless: works on kindle :) (and everything else)
<zyga> ah
<zyga> nice
<zyga> reading
<lifeless> http://bazaar.launchpad.net/~lifeless/subunit/streamresult/view/head:/README#L148 is the subunit *wire level* README
<lifeless> parser/serialiser http://bazaar.launchpad.net/~lifeless/subunit/streamresult/view/head:/python/subunit/v2.py
<zyga> lifeless: how are you using that?
<bryce> hey, anyone know if there is an official preferred C++ lib for JSON parsing/writing for Qt/QML devel?
<zyga> lifeless: I need to break for some real-life activities
<zyga> lifeless: I'll look at that and ping you tomorrow
<lifeless> zyga: ok, ping me whenever
<zyga> lifeless: thanks
<lifeless> Not sure what you mean by 'how are you using' - do you mean you want to see the CLI entry points for e.g. subunit.run or subunit-filter ?
<RAOF> bryce: I'm somewhat surprised there's not one in Qt?
<bryce> RAOF, there is qjson.  Would that be considered the official way to go?
<bryce> there's a bunch of more general purpose options on C++, some of which seem pretty popular.  jansson, jsoncpp, rapidjson, et al.  Just wondering if we have a standard, or if I should just choose randomly.  :-)
<RAOF> I'm not aware of a standard, but that's not terribly good evidence that there isn't one :)
<bryce> hrm
<dobey> RAOF, bryce: there's one in qt5, but it's a seprate lib with qt4. it's probably waht you want to use to do json in a c++ app using qt
<dobey> i think a couple of the other people on online servers that are working on a qt/c++ thing are using it for the json parsing
<bryce> alright, guess I'll play it by ear see what Qt does on its own with it
<xnox> jdstrand: so slangasek passed a missed ping to me. Searching for consolekit it's nice to search for org.freedesktop.ConsoleKit as one needs to use this verbantim "well-known" name in the code.
<xnox> regardless of which language is used to talk over dbus.
<xnox> so this string is present in python / c / C++ / some config files etc.
#ubuntu-devel 2013-03-07
<psusi> cjwatson, last time uds was in Orlando and I met you in person you were on a laptop, but watching the videos this uds, I wonder... do you use a "real fucking keyboard"?  I keep hearing loud key clicks and it seems to be you.
<infinity> psusi: He just types very violently.
<m4n1sh> ev: ping, have a question related to whoopsie
<pitti> Good morning
<pitti> Good morning
<doko> slangasek, online?
<slangasek> doko: heya
<pitti> slangasek: AFAIK the pkexec patch in http://launchpadlibrarian.net/105173889/policykit-1_0.104-2_0.104-2ubuntu1.diff.gz should be upstreamed, too, right?
<pitti> or is that Debian/Ubuntu specific somehow?
<slangasek> pitti: hmm, I can't think of any way that it's Debian/Ubuntu-specific.  I'd say it should be upstreamed, yeah
<pitti> slangasek: do you want to send that bugs.fd.o-wards with some background, or shall I file it and CC you in case there's further questions?
<pitti> slangasek, stgraber: what did you do to make logind create the user cgroups properly? when I install logind and the pam module, logind errors wit "Failed to create cgroup name=systemd:/user/joe: No such file or directory", and passes that error to the PAM module which then aborts, too
<pitti> (I don't see any relevant failure in strace)
<dholbach> good morning
<YokoZar> Can someone illuminate how gstreamer0.10-plugins-ugly managed to get multiarched before one of its dependencies? (libcdio)  From what I can tell it's never been coinstallable, and I'm wondering how such a thing could get past -proposed
<SunStar> the -ugly
<tjaalton> tkamppeter_: hey, cups is not cleaning up it's old conffiles, like with the introduction of cups-daemon I now have two logrotate files for cups, and cron is spamming me because of that. there's also /etc/pam.d/cups left over
<OdyX> tjaalton: please report a bug against cups-daemon on Debian/experimental, that's certainly valid there.
<OdyX> tjaalton: ah, wait, that's handled by 666367fc1d9fcdf18b71abf2254f8c12edc67f6b already, by tkamppeter
<tjaalton> OdyX: oh, cool
<OdyX> tjaalton: the problem I guess is that Ubuntu got intermediary versions
<pabs3> anyone know why the samba update hasn't been accepted into precise-updates? its two weeks past the date on https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=samba
<oly> hi, can anyone tell me if there is a way to test why webapp icons are not loaded ?
<oly> it a common problem i have hit, where i put .png files on the system but just get a placeholder image on the left bar,
<oly> i have no idea why, or if this is logged some where from what i can tell the paths are all correct, and i have compared against other webapps like the bbc one but mine does not work
<pitti> stgraber, slangasek: ah, we need to mount a tmpfs on /sys/fs/cgroup, so that logind can write into it
<pitti> stgraber, slangasek: I guess that woudl go into /lib/init/fstab ?
<infinity> pabs3: I was about to apologize for not reviewing it, then realized I uploaded it.
<pabs3> infinity: yeah, its uploaded but not accepted
<tjaalton> looks like the hotkey for enabling wifi on a dell laptop I have doesn't work on raring, and it defaults to being off. is there a way to fake the key so I could enable wifi again?
<tjaalton> hmm according to dmesg the key works..
<tjaalton> oh hell, now it's working :P
<tjaalton> i'll get me coat..
<pitti> slangasek, stgraber: with http://paste.ubuntu.com/5592725/ it works OOTB, but needs a fix to udev to suppress udev-acl; we could also add /sys/fs/cgroup/ mounting to /lib/init/fstab, WDYT?
<mbiebl> # systemd replaces udev-acl entirely, skip if active
<mbiebl> TEST=="/sys/fs/cgroup/systemd", TAG=="uaccess", GOTO="acl_end"
<mbiebl> pitti: that's in the latest 70-udev-acl.rules
<pitti> mbiebl: yes I know, but with above dynamic mounting in logind's upstart job /sys/fs/cgroup/ appears too late
<pitti> mbiebl: that's what I mean: if we mount it in /lib/init/fstab, it's early enough and that rule works
<pitti> mbiebl: and if we keep the late mounting, I'll drop the TEST from that rules
<mbiebl> couldn't you just mount the cgroups in logind itself
<pitti> same thing -- udev coldplugging happens before, and coldplugged devices get tagged with both
<pitti> also, systemd already mounts it, I don't want to create incompatibilities; so that patch only mounts it if it isn't already
<mbiebl> pitti: maybe we could convince rleigh to add similar bits to mountkernfs.sh
<jamespage> Laney, thanks for fixing oslo-config
<Laney> nps
<pitti> mbiebl: systemd mounts that directory by itself, though
<mbiebl> sure
<pitti> mbiebl: so it only becomes relevant with a split, and then we need to check that systemd's mounting doesn't collide with that
<mbiebl> im talking about the sysvinit+logind part
<pitti> mbiebl: oh, mountkernfs.sh wouldn't be run by systemd I guess
<mbiebl> correct
<mbiebl> so if upstart does the mount in /lib/init/fstab
<mbiebl> sysvinit in mountkernfs.sh
<pitti> then everything should work indeed
<mbiebl> and systemd itself
<mbiebl> all should be fine
<mbiebl> (in theory)
<yofel> cjwatson: hi, I just did a sanity check on the kubuntu packageset and noticed  that nepomuk-widgets is missing there even though it's on our images (libnepomukwidgets4). Does that need a manual override?
<yofel> I also added plasmate to supported if you could refresh the set
<cjwatson> it's in desktop-core, presumably bindings
<cjwatson> I guess both that and nepomuk-widgets are functionally maintained by Kubuntu so should be overridden
<yofel> it's part of the KDE SC, so it is maintained by us
<cjwatson> s/nepomuk-widgets/nepomuk-core/ - but that's actually already overridden
<yofel> no, those are 2 different things
<cjwatson> er yes I know
<cjwatson> I was saying that both belong in the kubuntu packageset
<yofel> hm, I got the set with "./edit-acl -P kubuntu -S raring query"
<yofel> and that doesn't show nepomuk-widgets
<cjwatson> sorry I'm being confusing due to not enough coffee and unfamiliar keyboard
<cjwatson> I understand your request and am acting on it
<yofel> hehe
<cjwatson> nepomuk-widgets moved
<yofel> thanks!
<cjwatson> and I'll refresh the autogenerated data now
<xnox> "your call is important to us, please hold the line, while we familiarise ourself with a new keyboard." =)))))))))))
<cjwatson> at least it isn't French layout :-P
<seb128> \o/ azerty :p
<seb128> you guys just don't know what you are missing ;-)
<cjwatson> the ability not to type numbers?
<seb128> that's what the keypad is for :p
<cjwatson> I'd use UK layout on this US keyboard except of course it has one fewer key and it's kind of useful to be able to type \|
<ogra_> so french people dont use laptops ? or are french laptops extra wide to fi a numpad on ?
<didrocks> on an US keyboard with an azerty layout, you are missing * and Âµ. The latter, well, don't really used it since I finished my study. The first one is more worrying :)
<ogra_> *fit
<didrocks> ogra_: I always use "shift"
<seb128> ogra_, numbers are overrated :p
<ogra_> and then a numpad magically slides out of the side of your laptop ?
<ogra_> :)
<cjwatson> ogra_: subscribe
<xnox> ogra_: it's in the cd-tray ;-)
<ogra_> haha
<ev> m4n1sh: pong
<zequence> I'm having some trouble debugging why the Ubuntu Studio ISO is not building. Was wondering if anyone could take a look, and perhaps point me in the right direction. Ever since I edited the seeds (I did some restructuring - and I'm new at this) we get these type of build logs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntustudio-dvd/20130306/livecd-20130306-amd64.out
<zequence> the seeds are at lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.raring
<cjwatson> odd.  easiest way to debug it is probably going to be to attempt a matching local build
<cjwatson> I'll have a go at that
<yofel> cjwatson: hm, did the auto-refresh finish? nepomuk-widgets got added fine (and emacs24 for some reason), but plasmate not and if I did a mistake I don't see it.
<zequence> cjwatson: Thanks a bunch
<cjwatson> yofel: the data generation did, but actually putting it into LP needs another step
 * cjwatson runs that
<yofel> ah ok, sorry for impatient then ^^
<yofel> *for being
<pabs3> infinity: so, who should I ping about the samba update?
<cjwatson> yofel: done now
<yofel> cjwatson: perfect, thanks a lot!
<infinity> pabs3: Someone in ubuntu-sru who isn't me, since we don't self-review our own uploads.
<infinity> pabs3: But I'll work on the queue tomorrow to shrink it, so the ones left over become more obvious to others. :P
<mlankhorst> :D
<pabs3> infinity: cool, thanks :)
<zequence> cjwatson: Do you have some nice resources on how to set up a local build system, that matches Ubuntus'?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<zequence> cjwatson: Ah, great!
<zequence> cjwatson: I suspect that /usr/share/livecd-rootfs/live-build/auto/config has something to with it. Didn't realize that needed to be adjusted in case of a restructuring of the seeds.
<zequence> I've removed some seed files, and restructured
<zequence> Also changed the metas
<zequence> All though.. I've kept the old metas as transitional
<zequence> So, I guess that was not it then..
<zequence> Forgot about the transitional metas
<cjwatson> zequence: It'll be about task names rather than metapackages.  I'll take care of it
<cjwatson> It's trying to look up the ubuntustudio-audio-plugins task and failing
<zequence> cjwatson: Aha. Ok. Yes, I removed it as a task.
<cjwatson> Micah half-fixed it but didn't quite do it all
<jdstrand> xnox: re consolekit> ack. search started, though it'll take a while
<zequence> cjwatson: What I was trying to do was to make sure ubuntustudio-audio-plugins did not show up on the alternate installer as a task
<xnox> jdstrand: awesome, thanks.
<cjwatson> zequence: Yes, I updated tasksel the other day to match your changes
<zequence> cjwatson: So, the seeds are correct then? Where is the error?
<xnox> jdstrand: do we not have hadoop cluster of the unpacked sources?
<cjwatson> zequence: livecd-rootfs 2.110 (just uploaded) should fix it
<zequence> cjwatson: Thanks.
<xnox> jdstrand: i recompressed all debs of all the archive in about 8 hours using tiny instances and juju.
<xnox> i guess it would still take a while for grepping.
<jdstrand> xnox: not that I'm aware of
<xnox> ok. and spinning one up just for consolekit sounds a bit over-engineered =)
<jdstrand> it has been a goal to have the ability for anyone to do this sort of grep without a local mirror, but alas, long todo list
<xnox> jdstrand: well in the cloud one does have almost infinite bandwidth to a mirror on the same network. So in my case I was doing `apt-get download` well one could be doing `apt-get source` and do a grep.
<xnox> and then it's just a question of how many instances one has available and partitioning the job between them.
 * jdstrand nods
<jdstrand> it would probably be fun to work on (please refer to previous said long todo list :)
<xnox> =))))))
<pitti> slangasek, stgraber: FYI, these systemd modifications plus my embarassing hack, plus a logind-ified polkit are in https://launchpad.net/~ubuntu-core-dev/+archive/logind
 * xnox ELOOPDETECTED
<jdstrand> hehe
<ogra_> yay embarassing hacks !
<zul> didrocks: ping
<njin> xnox, are you working on the new ubiquity ?
<njin> hallo, sorry ^^
<xnox> njin: i'm hacking on ubiquity, what's up? =)
<njin> I'm writing the testcase for upgrade ubuntu step from cd , but when I run it , it requre everything (timezone, layout,ecc.) are you planning to adjust this step '
<njin> xnox:^^
<njin> hmmm, it require password too
<njin> * '/?
<xnox> njin: yes, it does at the moment. Since you are reinstalling afresh, while preserving some data.
<njin> xnox, then is not planned any modification on these steps ?
<xnox> njin: i'm not working on that part of the installer at the moment. Our preffered way to upgrade people is via upgrade-manager / do-release-upgrade.
<xnox> and it's not high priority at the moment either for others on the installer team.
<xnox> njin: do you have thoughts on how to improve it?
<njin> xnox: jump directly to the upgrade without asking nothing , but well, if it is not an urgent thing i can write down the testcase without problems, Thanks
<xnox> njin: ok.
<infinity> xnox: All that data should be easily scrapable from the installed system with minimal effort.  user/password being the only sticky one, but surely in-place upgrades preserve passwd/shadow/group/gshadow anyway, or it's not much of an "upgrade"...
<stgraber> pitti: ah right, here I've got cgroup-lite installed so /sys/fs/cgroup is already a tmpfs as cgroup-lite mounts it as one
<pitti> stgraber: ah, that explains it
<stgraber> pitti: if we decide to mount a tmpfs on /sys/fs/cgroup from mountall, we'd need to make sure we don't break cgroup-lite in the process
<stgraber> (which may try to double-mount the path)
<pitti> right, we need to avoid that
 * xnox we have volunteer to fix up ubiquity-ugprade. Thanks a lot infinity =)))))
<pitti> stgraber: but we need to check that also if logind mounts it in the upstart job
<pitti> stgraber: i. e. if logind's job starts before cgroup-lite's
<pitti> stgraber: I take it it mounts it in cgroup-lite's upstart/init script?
<xnox> infinity: true, but there are tweaks and bugfixes needed, apperantly we were wiping mythtv mysql database on in-place upgrade and other similar bugs.
<xnox> it is fragile at the moment.
<infinity> xnox: Yeah, the "fix" for the mythtv bug highlighted a massive design flaw, really.
<pitti> stgraber: it's a race condition either way, of course
<infinity> xnox: The assumption that none of /var is valuable, except a few whitelisted directories is bound to be very fragile.
<xnox> infinity: i haven't looked into it to be honest. Where was the fix? Oh =)
<infinity> xnox: Honestly, I'd be happier if we just removed the option from the installer, but others may disagree.
<xnox> bdmurray wants to remove it =)
<stgraber> pitti: I think both should check if /sys/fs/cgroup is already mounted and only mount it if it's not. There still could be a race if both check+mount run at the exact same time, but that should be very unlikely
<xnox> infinity: i'd be happy to remove it, if we have a way to preseed "keep /home partition unformatted" and or "wipe everything, but preserve /home" but it's more or less same can of warms.
<xnox> s/warms/worms/
<infinity> xnox: Of course, the irony is that, for all the reasons it's an awful way to upgrade a complex desktop system, code very very similar to that may be an ideal way to upgrade phone/tablet installations.
<stgraber> pitti: though I'm not opposed to having this part of our default mountpoints, configured as a very small tmpfs (similar to /run/lock) and mounted by mountall (/lib/init/fstab) so that it's done before anything else
<pitti> if [ -n "`grep /sys/fs/cgroup /proc/mounts`" ]; then
<pitti> urgh
<xnox> infinity: well at the single-image-update session we are leaning to limit our self and make the core-os image read-only, that is less fragile to update, yet still can break the rest of the user-space.
<pitti> stgraber: ^ that's what /bin/cgroups-mount does
<pitti> stgraber: mountpoint -q would certainly be more efficient, but it does the job
<stgraber> pitti: ah good, so cgroup-lite DTRT. So we could simply copy/paste that to the pre-start for logind I guess
<infinity> xnox: Hrm?  Running a union filesystem, then?
<pitti> stgraber: see the pastebin, I do something liek that
<infinity> xnox: That brings in a bunch of other bugs.
<xnox> infinity: no, no unions. But the handwaving technology will teach dpkg about multiple databases of installed packages such that it all just works (tm)
<xnox> ps. duct tape sold separately.
<infinity> xnox: That doesn't instill confidence.  But, uhm.  Okay.
<stgraber> pitti: I remember having some weirdness happening with mountpoint disagreeing on whether something was actually a mountpoint, but /sys/fs/cgroup isn't one of those weird cases, so it's definitely cleaner than the grep
<xnox> infinity: stgraber is assignee, so expect lxc technology and edubuntu logo to sneak in.
 * infinity notes that having UDS double-booked with another conference on the other side of the planet was less than ideal for him.
<infinity> I'll catch up next week, I guess.
<psusi> say, who do you talk to about the single signon service being broken?  even when I click the support link and select problems logging on, I just get a submit link that doesn't take any information and just goes straight to thanks, we'll be in touch shortly...  wtf?
<dobey> psusi: #canonical-isd
<mitya57> Laney: for the record, pyxdg cannot be in sync with Debian because don't have set_default_menu.diff, but Debian should have it
<mitya57> *we don't have
 * mitya57 wonders if we are freezing today
<xnox> mitya57: i believe we are. standard time.
<Laney> mitya57: hmm, its dropping wasn't mentioned in the merge - that's weird
<Laney> I can't see why that patch would cause Ubuntu any problems though
<mitya57> Laney: it is mentioned in seb128's earlier changelog entry
<Laney> so the "remaining changes" missed that one
<mitya57> yes
<mitya57> looks like you are right, it just adds a fallback so shouldn't cause any harm
<Laney> but the menu-xdg dep is gone now
<Laney> in Debian
<mitya57> dholbach: looks like we missed the chance to upload the new ubuntu-packaging-guide :)
<mitya57> apart from that, I'm ready to the freeze
<mitya57> ah, and I also have bug 1152007 ...
<ubottu> bug 1152007 in python-secretstorage (Ubuntu) "Sync python-secretstorage 0.9.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1152007
<seb128> Laney, mitya57: sorry, I tend to copy the previous merge's summary as a start point, I must have forgotten to update it with the extra diff added in between
<tumbleweed> mitya57: you have until 8pm
<Laney> mitya57: I generally tend to like it when sync requests say /why/ the sync is being requested
<Laney> like some compelling new features / bug fixes / ...
<ev> bdmurray: heads up: https://bugs.launchpad.net/daisy/+bug/1152206
<ubottu> Launchpad bug 1152206 in Daisy "Repair overcounts" [Undecided,New]
<mitya57> tumbleweed: it has NEW binaries, so we missed it
<tumbleweed> mitya57: in the queue before freeze is ok (historically)
<Laney> yeah, should be fine
<tumbleweed> oh, debian New queue. historically, that was OK too
<tumbleweed> but of course, the debian new queue is MASSIVE atm
<mitya57> tumbleweed: we can upload it to Ubuntu, and later make a Debian upload
<Laney> s/later/simultaneously/
<xnox> yeah, I'd like boost1.53 =)
<tumbleweed> buy your favorite ftp-master beer :P
<mitya57> Laney: s/simultaneously/when I finish the Python 3 port/
<Laney> is that more of a blocker for debian than us?
<mitya57> Laney: it's a blocker for "upstream" release, but yes, we can upload it to Debian if we find Andrew SB
 * Laney decides to try sponsor-patch again (does it work for syncs?)
<tumbleweed> yes
 * mitya57 is updating the bug description
 * tumbleweed debates uploading a pypy pre-2.0 snapshot (it gained ARM JIT support)
 * mitya57 updated the description
<Laney> merci
<mitya57> Laney: thanks!
<zul> mterry:  hey
<cjwatson> psusi: keyboard> I have a new laptop that has a rather clickier keyboard than the previous one
<psusi> lol
<cjwatson> and yeah, I'm not the most delicate of typists :-)
<mterry> zul, hi
<zul> mterry:  we should be good for python-json-patch now
<mterry> zul, I thought we were already good (I approved it yesterday)
<zul> mterry:  cool thanks
<mitya57> Laney: thanks again, and enjoy http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/?view=log
<Laney> I *do* enjoy!
<bdmurray> barry: did you ever look at bug 1094218?  the most recent comment is interesting.
<ubottu> bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes" [Medium,Confirmed] https://launchpad.net/bugs/1094218
<sforshee> slangasek, cjwatson: do either of you have any idea why we'd hang while booting when efivarfs fails to mount?
<barry> bdmurray: i'll take a look now
<mitya57> dholbach: I've ported add-languages to Python 3, feel free to upload :)
<barry> mitya57: \o/
<dholbach> mitya57, good work! :)
<dholbach> mitya57, I'm in the middle of 5 things right now - mind pinging somebody else to sponsor it?
 * dholbach hugs mitya57
<mitya57> anybody able to upload ubuntu-packaging-guide? ^^
 * mitya57 hugs dholbach back
<mitya57> bdrung ^^
<barry> bdmurray: comments added
<bdmurray> barry: thanks
<barry> bdmurray: let's see what they say ;)
<brendand> do we not patch dch to allow specifying launchpad bugs for --closes?
<brendand> or is there an alternative version available? like 'uch', heh
 * tumbleweed has a shell wrapper around dch, called uch :P
<user99999> hello
<BenC> cyphermox: Re: NM bug, the driver is not at fault
<BenC> It is a static 10G connection, doesn't support auto-negotiation, not does it report link status (if it's up, it's carrier is reported as linked)
<BenC> Many other drivers also do this because the underlying hardware doesn't have link detection
<xnox> BenC: we love powerpc =) would you want to push for lts hwe? or are you interested in raring only?
<BenC> xnox: If raring releases next month, I'm not too concerned about back-porting :)
<xnox> BenC: =) heh, touche.
<BenC> xnox: precise would need lots of extras (qemu, installer, cdimage updates) to be worth it, and I'm not sure the effort is warranted
<xnox> sure.
<BenC> xnox: but I appreciate the support
<xnox> BenC: =) np, yw.
<slangasek> sforshee: because a missing mount point for an optional mount is ignorable, but a failed mount is an error; mountall doesn't know which virtual mounts are "important" or not, and indeed if you're booting under efi and you don't mount efivarfs, bootloader installs / upgrades won't DTRT
<slangasek> sforshee: what made the mount fail for you?
<sforshee> slangasek, it's a kernel bug in 3.9 that also got into 3.8 stable
 * slangasek nods
<sforshee> there's a fix coming down the pipe, just wondered why the machines couldn't continue booting
<slangasek> sforshee: because mountall doesn't presume to know which mounts are important; consider if /proc failed to mount and it carried on booting
<slangasek>  /proc is more important than efivarfs, but they're both important and mountall doesn't play favorites
<sforshee> slangasek, okay. When this happened to me I got nothing but a blank screen. Shouldn't we at least display some kind of error message?
<slangasek> (TBH, if you told me that we *should* play favorites, I'm not sure I have a way to do that in mountall today; but if you think efivarfs failures should be non-fatal, I could look into that)
<slangasek> sforshee: well, that's tricky, because the dependency chain for showing prompts to the user is virtualfs -> udev -> plymouth
<slangasek> we probably *should* say something on console too
<sforshee> slangasek, I definitely think what happens now isn't very good
<sforshee> I don't feel qualified to say whether or not efivarfs is critical, but it seems to me like it wouldn't be
<slangasek> for comparison, here's the full list of 'optional' filesystems that mountall deals with in this particular way; none of which have been reported as a problem before now: http://paste.ubuntu.com/5593851/
<slangasek> I do think we want a message on console.  Can you file a bug against mountall for this?
<sforshee> slangasek, sure
<cjwatson> As slangasek says, there are some hidden issues if you then try to upgrade the boot loader - in particular if you're running in secure boot mode the lack of efivarfs will (currently) have the effect that a boot loader upgrade will silently install an unsigned boot loader and your *next* attempt to boot will crash and burn
<sforshee> cjwatson, yeah that would be a problem
<cjwatson> I say "currently" because this is something we've agreed to change anyway, but ...
<slangasek> sforshee: related bug: bug #610869
<ubottu> bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [Medium,Triaged] https://launchpad.net/bugs/610869
<slangasek> (so, if we really wanted to ignore the failure, we would need to fix that bug first)
<slangasek> pitti: polkit forwarding to bugs.fd.o> I would be grateful if you would file that bug and CC me
<sforshee> slangasek, bug #1152274
<ubottu> bug 1152274 in mountall (Ubuntu) "filesystem mount failures during boot halt boot with a blank screen" [Undecided,New] https://launchpad.net/bugs/1152274
<slangasek> sforshee: cheers
<smoser> psusi, ping.
<psusi> smoser: pong
<smoser> hey.
<smoser> my query today is reguarding your comments on eatmydata
<smoser> do you have that work collected anywhere?
<psusi> I filed a bug report... let me see
<smoser> my interest is for use in cloud-images.  when a stock cloud-image is booted, quite often the first thing that is done is a slew of packages installed...
<psusi> bug #1126314
<ubottu> bug 1126314 in debootstrap (Ubuntu) "Debootstrap is very slow. Please use eatmydata to fix this." [Undecided,New] https://launchpad.net/bugs/1126314
<smoser> and often that is orchestrated by cloud-init. if it was easy to do, cloud-init could utilize that path to make that initial install happen faster (as nothing user-data worrysome has happened at that point)
<psusi> yep, that's the idea
<smoser> at very least, i guess cloud-init should invoke apt-get update with --force-unsafe-io
<slangasek> I thought we were using dpkg --force-unsafe-io for install/bootstrap?
<slangasek> ah, for apt-get
<psusi> we do, but that does very little
<jtaylor> its less effective
<smoser> we do for install and bootstrap.
<mlankhorst> even with --force-unsafe-io it still flushes some updates synchronously
<psusi> still flushes /most/... that option gets rid of rather few syncs
<slangasek> hmm
<cyphermox> BenC: ok, then with the logs you added to the bug I'll circle back and send it upstream for fixin'
<smoser> psusi, did you (or is there already) a obvious/easy way to use eatmydata?
<psusi> I tried to post a patch a year or two back to fix it and it was rejected by the dpkg maintainers and they said to use eatmydata instead, since that would also get rid of any syncs that happen as a result of the maintainer scripts
<slangasek> well, that's true, but dpkg is the main offender :P
<smoser> ah. i see more data in debian bug
<slangasek> I guess cjwatson may weigh in on the bug
<psusi> I'm not sure what you mean... I patched debootstrap to forcibly add the package to the required list so it gets unpacked right away, then set the LD_PRELOAD environment variable so it gets used during the rest of the bootstrap
<psusi> cjwatson suggested adding the LD_PRELOAD to in-target for the rest of d-i to leverage it
 * smoser chuckles at the idea of filing MIR for eatmydata, but that would be necessary for cloud-image usage.
<jtaylor> I use eatmydata for all my installs since its available, it significantly reduces the time, usually takes longer to type in your credentials and stuff
<psusi> also required for the debootstrap patch
<psusi> to be priority:required ( or forced there by debootstrap ) it has to be in main
<smoser> ok. so heres an opportunity for everyone to laugh at the ignorance of smoser.
<smoser> but if i have an install and have data i care about on a different filesystem than my OS (where dpkg is writing to)
<smoser> then why would i want or care for dpkg to call fsync for me.
<smoser> mostly its just ensuring that 100% reproducible data gets written to its target in that case.
<psusi> the idea is that if the power goes out while you are installing or upgrading, you don't corrupt your dpkg database, or end up with packages that are partially upgraded and thus, horribly broken
<smoser> yeah, that makes sense. but if i've separated OS data (extremely reproducible) from non-OS data, i have increased risk of data i cannot reproduce by using eatmydata for apt.
<psusi> that reminds me, I guess the next step to that MIR is to add it to a seed
<psusi> I'm not following
<marrusl> hello!  i have a question about old gnome libraries (specifically: libgnome-desktop-2-17 and libgnomeprint (and printui)).  Can one safely assume they'll at least be in the archives (if not main) for a very long time?
<psusi> what does apt have to do with your music and video collection? ;)
<smoser> psusi, it has nothing to do with it. thats what i'm saying.
<lifeless> psusi: if this is for image creation why not do it on tmpfs?
<smoser> i dont really care about fsync() on data that i can reproduce.
<psusi> lifeless: this is for normal installation in my case, and cloud images in smoser's
<smoser> outside of time recovering, i dont lose anything.
<psusi> you can't readily reproduce the dpkg status database without reinstalling, and a half upgraded package can leave the system unbootable, so your average user wants to make sure those don't happen...
<smoser> lifeless, interesting comment at http://glandium.org/blog/?p=1169
<smoser> " It might just be btrfs. And the best part yet is that since sync() is global, even when running pbuilder over, say, tmpfs, it doesnât change a damn thing."
<smoser> but i think that might be wrong.
<psusi> dpkg doesn't yse sync()... it uses fsync() and sync_file_range()
<smoser> psusi, yeah, thats what iw oudl have thought
<lifeless> so something else might be calling sync
<lifeless> it only takes on maintainer script :)
<lifeless> or say updating a database that calls sync
<psusi> I think someone at some point a few years back suggested having it use one sync() instead of a dozen fsyncs() and the response to that was no, since sync() is global it would flush a bunch of unrelated writes
<lifeless> probably want to instrument it and find out where it is coming from
<psusi> it's coming from dpkg ;)
<lifeless> what dpkg actually needs is barriers
<psusi> right, but there's no user space api for them
<lifeless> yeah. sadface.
<lifeless> psusi: I thought dpkg uses fsync and sync_file_range.
<lifeless> psusi: so I'm saying that that blog author is on crack, or has something *else* calling sync() :)
<smoser> lifeless, thats what i think too.
<psusi> lifeless: or it may have been written when they were trying to use sync() in dpkg instead of fsync and sync_file_range
<lifeless> psusi: 2010-10, we can check that
<psusi> I also found a kernel bug the other day that is hurting things too... iirc, dpkg uses sync_file_range to attempt to initiate background writeout early, then calls it later with the flag to wait until the writeout has finished... seems the kernel implementation was still doing a synchronous write without the wait flag
<psusi> I think the hope was that it could unpack all of the files in a single pakcage, initiating writeout on each file, then doing one wait at the end, and this was supposed to be the best way to get both speed and safety... but with the kernel treating every individual file's non blocking sync_file_range as a blocking sync, that's got to hurt the performance considerably
<psusi> let's see here, what seed should eatmydata be added to?
<slangasek> psusi, lifeless: or we could just declare the kernel filesystem designers to be on crack, and require data=ordered semantics for all filesystems we support in Ubuntu? :)
<psusi> data=ordered *is* the default
<lifeless> slangasek: its metadata out of order that hurts isn't it?
<slangasek> psusi: data=ordered is the *default*, but all the stupid tricks that userspace software is using these days to enforce syncing (including dpkg, and firefox) is effectively a workaround for filesystems *not* using that default
<slangasek> lifeless: data=ordered is what ensures that the data is written before the metadata
<slangasek> (in ext4 terminology)
<psusi> slangasek: no... filesystems do use that default, and the workarounds are to deal with the fact that there is no api to express to the kernel that this file should be synced first, *then* renamed
<slangasek> but this is only a default for ext4, users have the ability to change it; and xfs and btrfs don't give this guarantee
<slangasek> psusi: you don't *need* to express "sync, then rename" if data=ordered is in effect
<slangasek> which is why I'm saying we should renegotiate this contract with the kernel
<psusi> yea, you do, that's why dpkg is doing so much syncing
<slangasek> no, it's not
<slangasek> dpkg is doing this *because it can't rely on the default filesystem options*
<lifeless> ping, pong, ping, pong
<lifeless> so did ext4, during the terror release, not have that default?
<psusi> there are no nfilesystem options to fix it
<lifeless> what was with the 0 length files...
<lifeless> IIRC it was directory content being considered not file metadata, and not being ordered.
<psusi> the zero length files happened when people were using data=writeback
<slangasek> so what we should do, instead of making this the userspace's problem and making everything slower as a result, is to enforce data=ordered as an architecture requirement for the OS and homedir filesystem
<slangasek> lifeless: correct; for a brief period, data=ordered was not the default
<psusi> no slangasek, data=ordered does not fix the problem
<psusi> now I would argue that it *should*, but it doesn't...
<slangasek> psusi: you admit that dpkg is trying to ensure that the data is written to disk before the rename.  This is exactly what data=ordered gives you, with no further userspace acrobatics.
<psusi> nope, it doesn't
<slangasek> psusi: that is the DEFINITION of data=ordered.  Prove otherwise.
<psusi> see the big huge arguments between ted tso and the dpkg maintainers 2 years back ;)
<SunStar> nothing you can paste?
<slangasek> I was there for the argument; I'm not going to waste my time rereading it
<slangasek> I'm quoting the definition of data=ordered from the manpage, the burden of proof is yours
 * SpamapS wonders if the solution isn't just "cheaper SSDs"
<slangasek> SpamapS: that's a bandaid
<psusi> slangasek: I agree that it how it should work, but the reason they added all the syncing to dpkg is because it doesn't
<slangasek> psusi: citation needed.
<SpamapS> slangasek: a pretty good one :)
<lifeless> psusi: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
<lifeless> psusi: auto_da_alloc
<slangasek> SpamapS: except for all the cases where an SSD isn't fit for purpose, or you have so much data that the I/O itself (rather than the disk write) becomes a bottleneck
<lifeless> psusi: thats the thing ted added
<lifeless> psusi: after every developer everywhere called ext4 crack :)
<slangasek> SpamapS: and "cheaper" != "free"; it's still a crap situation for all your existing hardware
<psusi> lifeless: yea, and then the dpkg devs complained because it didn't work, and ted told them they were doing it wrong, add more syncs
<SpamapS> one might view existing hardware as a liability if it complicates one's software.
<lifeless> psusi: I don't recall that; can you point me at the thread?
<psusi> looking for it now...
<slangasek> SpamapS: we don't need to complicate the software, we just need to get a sane contract for userspace
<slangasek> data=ordered, which Linux userspace had assumed for over a decade *was* that contract because it was the only behavior ext{2,3} provided, would be sane
<slangasek> leave data=$other for domain-specific usage, but keep it the heck away from the OS filesystem
<frafu> Hi, I am a member of the onboard development team. We just released an update of Onboard, the onscreen keyboard shipping by default with Ubuntu, that includes new features  also targeted to the nexus 7. I have packaged it for raring. Could anybody with the necessary upload rights please put it into main before feature freeze kicks in? The necessary files are all available here:
<frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1152282
<ubottu> Launchpad bug 1152282 in onboard (Ubuntu) "Onboard update (version 0.99~alpha2~tr1371) available for raring" [Undecided,New]
<micahg> frafu: I was going to ask, any reason why you're not at beta since today is feature freeze, or is the alpha effectively feature frozen?
<frafu> We are calling it alpha because it still misses a few features like the possibility to select a different language than the system language.
<frafu> But you can consider it as feature frozen, as we intend to provide updates to it without adding new features.
<micahg> frafu: ok, I was just concerned with someone not release quality ending up in raring
<psusi> slangasek, lifeless: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#147
<ubottu> Debian bug 605009 in dpkg "serious performance regression with ext4" [Important,Fixed]
<slangasek> psusi: he's not talking about data=ordered.
<slangasek> he's *explicitly* talking about things that aren't data=ordered.
<psusi> no, he's saying that no matter what mount option you use, you can not rely on rename() to leave you with either before or after file over a crash, unless you fsync first, which is why that's what dpkg does now... a fwe comments above, the dpkg maintainer was hoping to just make nodelalloc the default and take all the syncs back out
<slangasek> "fsync() has always been the only guarantee that files would be on disk" - absolutely correct, and absolutely irrelevant to the question at hand.
<psusi> the question at hand is how to make sure rename doesn't leave you with the new, empty file
<psusi> the answer is you fsync, not you use data=ordered
<slangasek> yes, and *data=ordered does that*
<slangasek> and nothing in the mail you link to contradicts this
<psusi> the mail is ted saying you have to use fsync, full stop... not use data=ordered
<slangasek> NO
<slangasek> you have to use fsync IF YOU WANT TO ENSURE THE DATA IS WRITTEN TO DISK
<slangasek> which is NOT what we are trying to ensure
<slangasek> we are trying to ensure that the metadata is not changed BEFORE the data is written to disk
<slangasek> this is exactly what Ted has gotten wrong - he's failed to understand what userspace apps actually need in the common case
<psusi> a few comments up from there, the dpk gmaintanier said what we require is that after a crash, the file is either the old version, or the new version... not the new version, but with all zeros because the data has not been flushed yet
<slangasek> correct
<slangasek> fulfilling this requirement in no way involves a guarantee that the file has been written to disk
<slangasek> it only involves a guarantee of the *order* of writing things to disk
<psusi> right... that's all dpkg cares about... but according to ted, there is no way to do that other than to fsync
<micahg> frafu: I"ll try to upload it if no one beats me to it, but I have 4 things in my queue ahead of it
<slangasek> psusi: no, that's not what Ted said
<psusi> i.e. data=ordered doesn't take care of it
<frafu> <micahg> There are still a few points that might be a bit rough, like the Small layout, that needs a bit of rework to call it really ready for release, but generally, this release represents a good improvement compared to the version currently available in main.
<slangasek> fsync() is a guarantee that the file gets written to disk, which we explicitly /don't/ care about
<psusi> slangasek: right.. so you get more than you want with fsync()... ted's saying too bad... a rename() without the fsync does NOT give the required behavior, except as an accident on ext3...
<micahg> frafu: ok, well, keep in mind that you still have about 6 weeks for polish before final freeze
<slangasek> psusi: "except as an accident on ext3 because ext3 had data=ordered semantics"
<slangasek> this is the key point
<psusi> and so does ext4, yet you still have to fsync
<slangasek> Ted doesn't *want* to give a data=ordered guarantee, therefore he's discounting that in the argument
<slangasek> no, you don't have to fsync if you have ext4 with data=ordered
<slangasek> but you have to fsync because you don't *know* if you have data=ordered
<psusi> then why did ted not say you either have to fsync, OR use data=ordered?  he said you have to fsync, period. on any fs, with any mount options.
<slangasek> no, he said "you have to use fsync, period" because he doesn't want userspace apps making assumptions about filesystem options
<slangasek> which is a reasonable position for him to take
<slangasek> provided that we actually agree on what the baseline filesystem semantics should be, which we do not. :)
<psusi> then why did the dpkg maintainers not just say to hell with it, if people use data=writeback, that's their problem?
<slangasek> because the dpkg maintainers are equally conservative
<slangasek> and it's not the dpkg maintainers' purview to try to make that decision
<psusi> he sure seemed to want to just set the default mount options to sane values and take out the syncs
<slangasek> it needs to be a system-level decision, not an application-level decision
<lifeless> psusi: thats what the option I pointed you at is for, it's the 'workaround' Ted put in.
<psusi> lifeless: nodelalloc just makes sure you don't end up with a zero byte file... you still end up with a file full of garbage
<lifeless> psusi: thats not the option
<psusi> whihc one are you talking about then?
<lifeless> psusi: auto_da_alloc is the option
<lifeless> psusi: its the one that ties rename + file contents together.
<lifeless> psusi: that + data=ordered gives you file data + rename or no file data and no rename
<lifeless> psusi: as a logical consequence
<psusi> I seem to rmeember some discussion about it not being reliable
<psusi> i.e. didn't always work
<slangasek> and AIUI from that, auto_da_alloc is the default
<lifeless> slangasek: that is my understanding too
<frafu> <micahg> Sorry, we just found a bug entering the password in unity-greeter for the nexus. If you have not uploaded it already, it might be better to wait and try to get it in through a feature freeze exception.
<smoser> psusi, so with eatmydata...
<psusi> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009#157
<ubottu> Debian bug 605009 in dpkg "serious performance regression with ext4" [Important,Fixed]
<smoser> if i: eatmydata apt-get install postgres
<psusi> he seemed to interpret ted the way I did... thuogh there was no reply to that...
<smoser> postgres will start on installation, right? and be running with eatmydata preload. right?
<frafu> Sorry for any inconvenience.
<micahg> frafu: up to you, if you can make it feature frozen in a day or two might be worth waiting for the exception (I'm down to 3 ahead of it ATM)
<psusi> smoser: hrm... the postinst doesn't spawn the daemon directly thoguh right?  it has upstart do it
<smoser> and startstopdaemon probably does similar
<smoser> oh wait.
<smoser> hm..
<psusi> though I guess the old sysv init scripts did directly spawn the daemon didn't they?
<frafu> <micahg> What do you mean by waiting for the exception? That is better going through the exception process in one or two days?
<micahg> frafu: I mean requesting an exception if you're close in a few days rather than waiting weeks to request it
<micahg> IANA release team member, but they said they'd be more strict this time around since feature freeze was much later, but the closer to feature freeze you are, the better the chance you have of an approval
<slangasek> smoser: right... any long-running services spawned by a postinst would have eatdata in the preload environment
<slangasek> smoser: so this would be ok for bootstrapping where you know you're rebooting before you actually start services, but not so great for apt-get on a prod system
<slangasek> (but upstart magically avoids this problem, yay ;)
<ScottK> micahg: Personally, I'm more inclined to go easy this time than I had planned on since I think the whole "rolling" discussion threw things off plan for many people.
<slangasek> ScottK: I think that's a good position to take, though if we're going to get to 13.04 we will still need to get the freeze formally instated to get back on track
<frafu> <micahg> Ok; cancel the upload. We will try to fix the bug and request an exception in the next days. Sorry for any inconvenience.
<psusi> that does seem to be a pretty good argument against using eatmydata for upgrades though, and instead having dpkg get the --i-really-mean-no-bloody-syncs type option I proposed a while back
<ScottK> slangasek: Agreed.  I think no formal decision has been made to change the plan, FF is still today.
<ScottK> frafu: If it's just fixing a bug, it can go in much later.
<micahg> frafu: sure, no problem, as Xubuntu uses onboard, I'd prefer a more solid version anyways
<psusi> smoser: did you get around to the growfs thing yet?
<smoser> psusi, i'm about to land it...
<psusi> smoser: did you end up using parted, or sfdisk?
<smoser> cloud-init should have support for using growpart *or* parted partresize
<slangasek> barry: bug #1094218> I suspected the -Es problem myself, but having looked in the teamviewer package, upstream isn't providing any python stuff that would override.  Also, from the errors.u.c page this is definitely being hit with -Es: https://errors.ubuntu.com/oops/3bdeab54-8766-11e2-b117-e4115b0f8a4a
<ubottu> bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes" [Medium,Confirmed] https://launchpad.net/bugs/1094218
<smoser> whichever it finds.
<barry> slangasek: ack
<barry> slangasek: okay, i'll look into it again
<psusi> smoser: so you got around the sfdisk complaining about BLKRRPART problem?
<smoser> with that ugly hack that i showed you
<psusi> ahh
<frafu> <micahg> The problem we found just occurs at the login screen on the nexus in portrait mode. But, it might nevertheless be better to wait and test a few more days. So we decided to ask you cancel the upload.
<micahg> frafu: ok, just mark the bug accordingly, I see sponsors was already unsubscribed
<frafu> <micahg> done
<dobey> /usr/lib/x86_64-linux-gnu/qt5/bin/qmake <- what a weird path for the qmake bin to be installed to. why is it in there and not installed as /usr/bin/qmake-qt5 ?
<xnox> dobey: that is wrong. no-preference on the name, but yeah it should be under /usr/bin/
<dobey> xnox: oh, it seems this weird 'qtchooser' thing is a wrapper
<dobey> xnox: only after i installed ubuntu-sdk did it do anything useful though, so i wonder what specifically was missing there :(
<slangasek> dobey, xnox: the 'qtchooser' only affects /usr/bin/qmake, AFAIK; at least for qt4-qmake, /usr/bin/qmake-qt4 exists, though it's also a symlink into /usr/lib/aardvark
<slangasek> I don't know why the files are shipped under /usr/lib, that seems pointless to me
<slangasek> this is a recent change; as of quantal, /usr/bin/qmake-qt4 was a real file
<YokoZar> slangasek: Do you know the rough amount of default install library packages still waiting on multi-arch transition?
<slangasek> YokoZar: not at all
<YokoZar> slangasek: does libcdio count?
<slangasek> YokoZar: you could test by grabbing a default install, and looking at /lib/*.so.* /usr/lib/*.so.*?
<YokoZar> mmm yeah
<slangasek> YokoZar: however, I've never considered "all libs in the default install converted to multiarch" to be an interesting target; being installed by default says little about whether you need to cross-install it
<YokoZar> slangasek: I suppose because the default install packages depending on them doesn't really mean that there's another package that might depend on a cross-arch version
<slangasek> more interesting targets are "all the common libs used by binary-only software that we know about", and "being able to cross-build everything in the default system with multiarch (no self-conflicts in the build-deps)
<slangasek> "
<slangasek> YokoZar: exactly
<slangasek> for instance, the only libs left in /lib on my system are libcryptsetup, and libraries internal to iptables
<slangasek> not terribly interesting targets
<YokoZar> Yeah that makes sense
<YokoZar> I stumbled on https://bugs.launchpad.net/ubuntu/+source/libcdio/+bug/1151565  recently (needed -ugly plugins for a wine game)
<ubottu> Launchpad bug 1151565 in libcdio (Ubuntu) "Please transition libcdio to multi-arch" [Undecided,New]
<slangasek> oh -ugly, always living up to your name
<slangasek> YokoZar: so my recollection was that we had previously multiarched all the libs used by all of good, bad, and ugly in support of wine; I'm guessing this is a recently added library dependency?
<YokoZar> slangasek: http://packages.ubuntu.com/precise/gstreamer0.10-plugins-ugly  seems to say precise depended on it
<YokoZar> did software center depend on it in precise?
<slangasek> did software center depend on what?
<slangasek> -ugly is in universe and always has been
<YokoZar> did software center depend on libcdio I mean
<slangasek> no idea
<YokoZar> we might not have noticed if it didn't, I mean, because installing foreign -ugly wouldn't have removed software center.
<YokoZar> It seems like precise software-center doesn't pull in libcdio13 but raring does
<slangasek> I'm struggling with the idea of software center requiring libcdio
<YokoZar> It's a transitive dependency
<slangasek> ah, via gvfs-backends; yes, that dep was there in precise too
<YokoZar> Precise software center didn't depend on gvfs-backends
<roaksoax> slangasek: still around?
<roaksoax> slangasek: i was wondering if you could help me out with an upgrade issue described here: http://pastebin.ubuntu.com/5594451/
* Laney 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:
<barry> slangasek: bug 1152359
<ubottu> bug 1152359 in zeroinstall-injector (Ubuntu) "[FFe] sync 2.0-1 from debian/sid" [Undecided,New] https://launchpad.net/bugs/1152359
<tkamppeter> slangasek, hi
<slangasek> roaksoax: can you post the output when running apt-get with -oDebug::pkgProblemResolver=1?
<ogra_> stgraber, you dont inspect real snapshot capable filesystems for the single-image-update spec ?
<roaksoax> slangasek: sure, give me just one sec
<slangasek> tkamppeter: hi
<roaksoax> slangasek: btw.. I uploaded again the python-django changes for maas as ubuntu1.7, sinced the previous upload got rejected because a security fix landed with ubuntu1.6
<stgraber> ogra_: it was mentioned during the session but cjwatson and some others expressed concern regarding the reliability of using snapshotting (block snapshotting with LVM at least)
<ogra_> well, i was referring to nilfs2
<slangasek> roaksoax: ok, thanks for the info - and sorry for not getting to that one yet
<ogra_> which additionally gives a massive performance boots on mmc
<tkamppeter> slangasek, due to all the discussion about rolling release, the UDS placed a day before FF, I was not counting on the FF actually taking place and so I missed FF with some important packages. HPLIP 3.13.2 and an update of foomatic-db. Could there be made an exception for these? They are mainly about updated hardware support.
<roaksoax> slangasek: no worries :)
<slangasek> xnox did some nilfs2 investigation previously, IIRC
<ogra_> yep i pushed for that as well :)
<ogra_> for the nexus7 ... but thats was only to make sure it works as rootfs
<ScottK> slangasek: I took care of python-django.  You can mark that off you list.
<ogra_> (there were initrd hooks not working etc)
<slangasek> ScottK: ah, alrighty then
<slangasek> tkamppeter: if the packages are ready to go today or tomorrow, then that's fine
<slangasek> tkamppeter: if it's going to be next week, we may want to dig into the details more
<tkamppeter> slangasek, hplip is nearly ready and foomatic-db is trivial.
<xnox> ogra_: explain what part of the job you envision to use fs snapshoting for? (as in nilfs2 for example)
<xnox> ogra_: in nil2fs you cannot remove the base snapshot, nor replace it with something else, nor merge them to recover space.
<xnox> if files are deleted one needs to garbage collect. The assumptions so far was that we will not have space for two base images.
<stgraber> ogra_: seems interesting. Only shortcoming that may be problematic is the lack of extended attribute support. IIRC we now have some software (I recall gnome-keyring at least) using those to store capabilities
<ogra_> oh, yeah, that would need to be added
<xnox> stgraber: so we did start using extended attributes?! =) nice. i was still under the assumption that nothing yet uses extended attributes on linux.
<ogra_> xnox, well, would btrfs offer that we pull in a newer snapshot ?
<stgraber> xnox: pretty much nothing is as tarballs can't store them (in a format compatible way anyway), but I know that gnome-keyring uses maintainer script to set some capabilities as xattr
<ogra_> to actually apply a system update in one file
<stgraber> stgraber@castiana:~/data/code/lxc/stgraber-lxc-git$ getcap /usr/bin/gnome-keyring-daemon
<stgraber> /usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep
<ogra_> (i thought nilfs2 actually handles snapshots in userspace ... i would expect that to be modifyable to support what we need)
<xnox> ogra_: i still don't understand what are you after. I have base image, create snapshot, update all files in the snapshot, then what?
<xnox> ogra_: nil2fs can mount older snapshots readonly, up to the point where it's past the log horizon.
<ogra_> xnox, send a zipped snapshot to the user to apply as system update
<roaksoax> slangasek: ok here's the output: http://pastebin.ubuntu.com/5594529/
<xnox> ogra_: since there is no block level deduplication it will be same as sending a zip of any files that have changed + filesystem overhead.
<xnox> (for nil2fs)
<ogra_> right
<xnox> ogra_: for btrfs, it might be smaller than sending a zip of any files that have changed.
<ogra_> well, essentially we woudl want it to be a diff indeed
<ogra_> between original install and update1
<xnox> ogra_: btrfs has file-level deduplication only as well (but that's from 3.6 kernel info, things may have changed)
<xnox> ogra_: a zip of xdeltas ;-)
<ogra_> well, btrfs is sadly extremely underperforming on MMCs
<ogra_> unless that recently changed
<xnox> ogra_: somebody on github was working on a delta format for binaries that are encapsulated in an fs image. but it sounded very experimental.
<ogra_> hmm
<ogra_> the prob is that i dont think btrfs is well suited for our usecase ... and the fact that we cant really rely on a kernel version
<ogra_> all tests that i have seen with btrfs on MMC had very bad results ... like twice as slow as ext4
<RAOF> It's somewhat a pitty that btrfs isn't more mature; it's got all sorts of fancypants things that would make our lives easier (snapshots, the ability to btrfs-send filesystem images, dedupabilityâ¦)
<ogra_> b in btrfs stands for buzzword right ?
<ogra_> or was it bling ?
<ogra_> its like the duke nukem of filesystems :)
<xnox> i like how it doesn't loose data during defragmentation if snapshots are present.... from linux kernel 3.9rc1 and up
<RAOF> I was under the impression that it doesn't lose *deduplication* during defragmentation in that case?
<RAOF> For all my annoyances with it, btrfs hasn't actually lost any of my data for a good long while.
<xnox> RAOF: hm, then it's not that bad, unless one runs out of disk-space while performing defrag =)
<xnox> RAOF: on my current machine I don't have btrfs, but I am planning to use it on my desktop, which was suppose to be here today. Oh well maybe tomorrow?
<RAOF> xnox: Right. I'd guess the defrag would fail in that case rather than losing data.
<RAOF> xnox: With an SSD, or rotating rust? I've found that it bogs down pretty quickly on rotating rust.
<xnox> RAOF: well, all defrags can fail if there is not enough space to shuffle bits about.
<RAOF> Well, yeah :)
<tkamppeter> slangasek, hplip 3.13.2-0ubuntu1 uploaded.
<xnox> RAOF: 4x1TB of rotating rust with Intel Rapid/Matrix RAID or Marvell raid controllers. I have both ;-)
<gaara_akash> "For qmake projects, use the QML_IMPORT_PATH variable to add import paths." - thats an error i keep getting, anyone know what to do?
<mdeslaur> xnox: I was just about to upload an openssl to -proposed for 1066032 :P
 * mdeslaur shakes fist at xnox :)
#ubuntu-devel 2013-03-08
<m4n1sh> ev: I have made changes to privacy manager and need to integrate diagnostics too with it. IIRC prior to this, whoopsie package was not present. Now I can find libwhoopsie package and I am not able to figure out how whoopsie-generated.{c/h} is being generated in the current codebase
<slangasek> roaksoax: which release is this dist-upgrade happening in?
<slangasek> roaksoax: ah, n/m, found at the bottom of your pastebin
<slangasek> roaksoax: so, why are you using a Conflicts: against tftpd-hpa, instead of a Breaks:?
<roaksoax> slangasek: cause i thought conflicts would be more rrstrictive
<roaksoax> so both services dont run at the same time
<roaksoax> slangasek: btw upgrade candidates can be found at ppa:maas-maintainers/stable
<slangasek> roaksoax: Breaks: is sufficient to ensure that both packages aren't "installed" at the same time; let me refresh my memory (from policy) as to whether Breaks is actually a better choice here
<slangasek> roaksoax: ok, I can't convince myself that Breaks: tftpd-hpa would be more correct than Conflicts:, so let's set that aside
<slangasek> roaksoax: however, looking at the package that's in raring, the /other/ Conflicts (on maas (<= ...) and maas-region-controller (<= ...)) should almost certainly be Breaks rather than Conflicts, since they're paired with Replaces
<roaksoax> slangasek: yeah i was thinking on changing that
<slangasek> roaksoax: I don't know if changing those would be sufficient to make apt happy, but it would be an appropriate fix in its own right
<roaksoax> slangasek: i tried taht and disnt make apt happy unfortunately
<slangasek> ok
<roaksoax> but i could give it another try
<slangasek> is the 'cobbler' package installed in this scenario?
<slangasek> Well, I guess maas-provision is more likely
<roaksoax> slangasek: yeah maas-provision
<slangasek> roaksoax: and maas-provision isn't built from maas source... so the current version of that package still has a Recommends: tftpd-hpa?
<slangasek> this may be why apt considers it better to remove maas instead of removing tftpd-hpa
<slangasek> sorry, dinner
<roaksoax> slangasek: yes, so maas-provision is its own source package. And that indeed Recommends tftpd-hpa. I have tried conflict/replace and break/replace maas-provision in both 'maas' binary and 'maas-cluster-controller' binary, with no luck whatsoever
<hyperair> has anyone here used valgrind's memcheck tool successfully on any glib/gtk app?
<hyperair> it always seems to have a ridiculous amount of rubbish from gtk/glib's internals
<RAOF> There's a suppression file for that IIRC
<codebrainz> only one I found was from really old wxWidgets wiki
<hyperair> RAOF: iirc that was last updated in 2009.
<codebrainz> hyperair, ask in #gtk on gimpnet :)
<hyperair> heh
<pitti> Godo morning
<RAOF> pitti: Godot morning!
<pitti> RAOF: hohow are yohoow?
<pitti> slangasek: hey Steve, still here?
<pitti> slangasek: do you have an opinion about mounting /sys/fs/cgroup in /lib/init/fstab? it would eliminiate race conditions and avoid modifying udev's and logind's udev rules (and even there it's a race condition)
<dholbach> good morning
<zyga> utlemming: hey
<Whoopie> arges: Hi, regarding iptables, why haven't also fixed the debian-changes things as described by me in the bug report? Just curious.
<xnox> mdeslaur: I am sorry  about that =) i did think "i bet mdeslaur thinks openssl is his package only by now ;-)"
<vibhav> hyperair: yes, I remember seeing a memory leak via a glib routine
<Mirv> arges: could you accept/evaluate/sync systemtap 2.1 from Debian? bug #1130626 now has pbuilder log as well
<ubottu> bug 1130626 in systemtap (Ubuntu) "Update Ringtail SystemTap to 2.1" [Undecided,New] https://launchpad.net/bugs/1130626
<hyperair> vibhav: did you use a suppresion file or anything? valgrind's output is typically pretty polluted when used on a glib program
<vibhav> No
<vibhav> hyperair: I will try one right now
<vibhav> There are some glib routines which were leaking memory
<vibhav> s/are/were/
<vibhav> hyperair: Is there a specific suppresion file?
<hyperair> vibhav: nah, i was wondering if there was a suppresion file around, because the last time i used it on a glib application it was full of internal glib stuff
<vibhav> Indeed
<hyperair> oh interestingly it seems pretty clean now
<hyperair> =O
<hyperair> just some warninsgs from cairo
<xnox> mdeslaur: you are free to upload your fix for openssl on top of my work and do -v'*2.2' to have all the bug references together.
<xnox> mdeslaur: I was thinking of preparing precise upload for my two bugs as well.
<infinity> xnox: Please do upload your openssl changes to precise as well, yes.
<xnox> infinity: yeah, testing.
<infinity> xnox: I won't be accepting the arm assembly thing until Rob gets me some solid evidece that it doesn't blow up the world, but he's promised me this. :P
 * infinity goes back downstairs to ingest more beer.
<xnox> infinity: for quantal, yesterday I did run full testsuite & benchmarks on nexus7, all was fine.
<xnox> infinity: repeating for precise now.
<xnox> infinity: it's armv4 assembly from way back when ;-)
<infinity> xnox: Can you do some realworld things like a local apache2 w/SSL and abuse it a bit to see if it DTRT?
<xnox> infinity: i do wonder if the elliptic curves optimisations will work on arm64 as well =)))))
<infinity> xnox: But yeah, I have no reason to believe the assembly doesn't work.  Just that it's not been tested in Debian/Ubuntu ever.
<xnox> infinity: well it was tested in raring =))))
<infinity> xnox: FSVO "tested".
<xnox> =))))))))))))))
<infinity> xnox: We don't have that many people abusing openssl on ARM in raring, I suspect.
<xnox> apart from hrw =)
<pitti> xnox: for the list in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration, did you grep the Ubuntu or only the Debian archive?
<pitti> xnox: i. e. indicator-session is missing
<pitti> (adding it now)
<xnox> pitti: I did not finish the debian grep, jdstrand did launch ubuntu grep. Will take some time to get the results back.
<pitti> ack
<pitti> ah, it seems indicator-session tries the org.gnome.SessionManager first, and then fall back to CK
<pitti> so fixing gnome-session ought to help actually; doing that now
<Laney> I have a canonistack instance set up to try and get codesearch working for Ubuntu
<Laney> but I haven't figured out how to work it yet; documentation is quite lacking
<pitti>  ah bummer, our gnome-session needs logind >= 183
<seb128> Laney, it's easier to just do that from the datacenter
<Laney> just do what?
<seb128> Laney, grep the archive
<Laney> I'm talking about setting up http://codesearch.debian.net/ for Ubuntu
<seb128> oh, ok
 * pitti used http://people.canonical.com/~pitti/scripts/for-srcarchive on lillypilly before (that has a local mirror)
<seb128> right
<seb128> Laney, I though you wanted to do a one time grep, not to set up a service for those ;-)
<seb128> Laney, good luck
<Laney> https://github.com/debiancodesearch/dcs/blob/master/README
<Laney> not so detailed ;-)
<Daviey> Laney: ISTR jodh was a fan of this aswell
<Laney> excellent, it's a great service
<Laney> I will get around to asking the developer for better instructions
<Laney> actually I'll do it now while I'm thinking about it
<mitya57> tumbleweed: will you upload pyxdg? :)
<jodh> Daviey/laney: I'm certainly a fan of such a facility but was originally looking at opengrok (which has a bunch of cool features); if the indexing can be partitioned, we could use juju to scale horizontally.
<Daviey> jodh: You just sold it to me :)
<Laney> yeah I'm not sure debiancodesearch has anything like that
<jodh> Daviey: one of the advantages being that opengrok could not only index all the branches on lp, but it could also index the archives and extract meta-data out of the built packages themselves (with a few tweaks).
<Daviey> Interesting.
<Daviey> Whilst we are talking of developer resource tools, xnox - how is your snapshot equivalent thing going? :)
<xnox> Daviey: submerged in the todo list =)
<xnox> Daviey: I dunno, I should fix up my access to lcy02 (for some reason only lcy01 works for me at the moment) and I should really tinker with that. But you know lvm2 SRUs to verify.... =) I'm up for trading ;-)
<Daviey> xnox: lcy01 and lcy02 run different versions of openstack.... what tooling are you using to converse with them.. maybe there is a bug?
<xnox> Daviey: interesting. I'm using juju 0.6.0.1.
<xnox> with openstack providers I believe.
<Daviey> xnox: check in with hazmat, he might know the situation
<xnox> Daviey: thanks.
<Laney> what's the idea there? exposing the librarian somehow or running an actual snapshot equivalent?
<xnox> Laney: something that does rsync of dists/, indexes the various archives by time. something else that will fetch and serve them. something third (nginx reverse proxy) that will in order try: local cache, archive.ubuntu.com, old-releases.ubuntu.com, launchpadlibrarian to actually serve the requested .dsc, *.tar.*, *.deb
<Daviey> Laney: librarian... store valid Packages.gz as time snapshots, but proxy through to librarian AIUI
<Daviey> right
<Laney> then write a deb-bisect? :)
<xnox> Laney: the interested parties can do that then, yes ;-)
 * Daviey fains disinterest 
<Laney> i suppose it would be apt-bisect
<xnox> infinity: apache bench stress tests?! =)
<pitti> slangasek: done, https://bugs.freedesktop.org/show_bug.cgi?id=62016
<ubottu> Freedesktop bug 62016 in daemon "pkexec does not apply PAM's environment" [Normal,New]
<sonne> so will 13.04 have still amazon search enabled by default?
<xnox> sonne: yeah. also see smart search blog post from Allen Bell about the improvements that are planned there.
<xnox> sonne: this is more of a #ubuntu-desktop question though ;-)
<sonne> xnox, alan?
<sonne> i can't seem to be able to find the blog post you're mentioning *shrug*
<sonne> thanks for answering my question though :)
<xnox> sonne: http://www.theopensourcerer.com/2013/01/ubuntu-smart-scopes/
<sonne> cheers
<davidcalle> xnox, sonne, this won't be in 13.04 though
<davidcalle> xnox, sonne, this has been discussed during the UDS session about it two days ago.
<sonne> that's too bad
<davidcalle> sonne, I know :)
<xnox> davidcalle: hehe =) i missed that session. Oh well. Or see latest UDS where things got redefined then ;-)
<sonne> would have been a nice improvement for the search problem
<sonne> i haven't really followed the discussions in the last months, but i know there has been a lot of drama about the search feature
<davidcalle> sonne, indeed. I'm actually implementing most of the new search engines and I'm looking forward to being able to disable/enable them per theme and per data source.
<sonne> davidcalle, personally i'd rather have the user decide whether or not to have searches on the internet on installation
<sonne> or some kind of other solution that would not have the user go and google how to disable the searches
<sonne> but then, i have no clue on how the whole thing is being handled :)
<davidcalle> sonne, I don't know, I think that the settings > privacy > on/off switch is a good design.
<davidcalle> sonne, in that regard, the Dash now advertises the fact that it's searching online "Search your computer and online sources" is in the search field default text (when the switch is ON)
<sonne> maybe adding a "<Click here for options>" right there would be the best to try and protect the most inexperienced (or laziest :) users
<davidcalle> sonne, there is a discoverability issue of that setting, that's true. Hopefully, it will evolve into something most users are happy with :)
<sonne> let's hope it... the whole thing has raised way many concerns, it would be a shame to lose userbase on a wonderful product as ubuntu for such a trifle
<sonne> davidcalle, reading the lens source code for ringtail, i see that the https handling is delegated to the vala libraries... i'm wondering how strict is their certificate authenticity check
<davidcalle> sonne, I actually have no idea about the Vala ones. I guess you could ask that to pstolowski in #ubuntu-unity.
<sonne> thanks for the pointer :)
<davidcalle> sonne, np :)
<zyga> utlemming: around?
<zyga> pitti: last night we've updated virtualbox to 4.2, breaking vagrant 1.0.3 that does not support it, we're in feature freeze now, upstream vagrant 1.0.6 works okay, what can I do to get 1.0.6 into raring? I'm trying to package 1.0.6 based on the current package but my git-buildpackage foo is low
<pitti> zyga: ah, you want to update it in collab-maint?
<zyga> pitti: yes but I don't know how
<zyga> pitti: I got the upstream git tree, I've exported 1.0.6 from the tag
<zyga> pitti: I've got the debian collab-maint tree as well
<pitti> oh, debian's git-buildpackage trees are not based on upstream git
<pitti> you usually just run git-import-orig to import a new tarball
<zyga> yeah, but I needed both to get the pristine tarball, apparently upstream builds none
<pitti> ah, sure
<zyga> trying
<zyga> woot
<zyga> worked!
<zyga> let me build and check this
<zyga> so what happens if it works?
<zyga> can you help me push 1.0.6 to debian git and sync that to ubuntu somehow?
<Laney> https://github.com/mitchellh/vagrant/tags ?
<pitti> zyga: yes, I can
<pitti> zyga: NB that vagrant currently has some ubuntu modifications
<zyga> yes
<pitti> zyga: if they are applicable to Debian they should be committed there; or are they obsolete?
<zyga> I saw two patches
<zyga> one seems to change the location of common files, it just places /usr/share/vagrant there, seems okay
<zyga> the other patch was for dns config that was affecting us ever since we've started to use the internal dns but I cannot see that patch in debian/patches anymore
<zyga> but that was integrated upstream earlier
<zyga> so perhaps it's no longer in the debian git tree
<zyga> creating pbuilder base image
 * zyga needs to grok all the packaging stuff better
<rmannibucau> Hi guys, how do i ask for the creation of a package + addition in repo for ubuntu?
<zyga> rmannibucau: perhaps yuo are interested in #ubuntu-app-devel and developer.ubuntu.com?
<rmannibucau> zyga, i'll conect, thanks
<zyga> pitti: I cannot build a base image for git pbuilder, it stops on cowdancer being missing: http://pastebin.ubuntu.com/5595765/ should I be doing this?
<pitti> zyga: hm, I'm afraid I never did that; for raring I just build on my normal system, and use schroot for everything else
<pitti> zyga: perhaps there's a way to disable cowdancer and just use classic tarballs and temp dirs?
<zyga> ah, I can just try building the package
<zyga> so that worked
<zyga> woot, cool, let me check if the package works
<zyga> pitti: assuming this works, what should I do next?
<pitti> I guess pristine-tar etc. doens't work well with format-patch, so I suggest you push your git someplace, or tar it up and put it on people?
<pitti> zyga: ^
<Laney> ~/public_git on git.d.o is nice
<zyga> Laney: I don't have access to git.debian.org most likely, yet
<zyga> pitti: ok, let me try that
<Laney> well you can sign up, but github/gitorious/whatever also works
<zyga> my ssh key does not work with people.ubuntu.com, I'll try people.canonical.com
<Laney> apparently lillypilly has git installed too, so perhaps you can actually push there!
<zyga> lillypilly?
<Laney> people.c.c
<zyga> oh
<zyga> yeah
<zyga> pushed to http://people.canonical.com/~zyga/vagrant.git/
<mdeslaur> xnox: you do know I was just kidding, right? :)
<mdeslaur> xnox: I'll wait a week, no rush
<zyga> I gave the new vagrant a run here
<zyga> with fresh cloud images from cdimage.ubuntu.com
<zyga> let's see how that goes
<zyga> hmm
<zyga> failed to up vms?
<zyga> odd
 * zyga goes for lunch
<xnox> mdeslaur: i'd rather you not wait a week though =) as your bug is high priority and mine are not.
<mdeslaur> xnox: ok, way a few minutes, and I'll upload it to quantal. I'll give you my precise debdiff too if you're preparing that.
<xnox> mdeslaur: yeap. Finished amd64 test, only armhf test left before uploading precise debdiff.
<mdeslaur> xnox: could you please add this? http://paste.ubuntu.com/5595873/
<xnox> mdeslaur: since quantal's sru was not accepted yet, you can use same version number. Or like give me debdiff for quantal. as well.
<xnox> mdeslaur: looks ok to me.
<mdeslaur> xnox: here's my quantal debdiff: http://paste.ubuntu.com/5595877/
<xnox> awesome, let me work those in ;-)
<mdeslaur> xnox: thanks!
<mdeslaur> xnox: sorry for colliding with you :)
<xnox> mdeslaur: your bug report does not follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template though
<mdeslaur> oh! right, I didn't update it yet...wait a sec
<xnox> can you apply your awesome editorial skills to bug 1066032, please?
<ubottu> bug 1066032 in openssl (Ubuntu Quantal) "Deadlock when reading a public key" [High,Confirmed] https://launchpad.net/bugs/1066032
<xnox> ok. cool.
<mdeslaur> xnox: done, thanks
<xnox> cool =)
<OdyX> tkamppeter: despite my wrong changelog entry in foo2zjs, the code is correct and cares about Ubuntu for mscompress; hence there was no need for a merge; you could have simply synced...
<jdstrand> xnox: http://people.canonical.com/~jamie/consolekit/
<seb128> pitti, ^
<seb128> jdstrand, hey, thanks for the grepping ;-)
<jdstrand> np
<mdeslaur> infinity: do you have an apache2 merge planned soon?
<seb128> ev: hey, sorry to ping you but I'm not sure who to ask ... who is maintaining ubuntu-geonames? Is that #is? do they look at launchpad bugs?
<xnox> seb128: I am the TIL on ubuntu-geonames.
<xnox> seb128: what's up?
<seb128> xnox, pgraner reported https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109
<ubottu> Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,New]
<xnox> seb128: we take straight database from http://www.geonames.org/
<seb128> xnox, not sure how much of an issue that is (well, he reported that against the indicator but it turns out it's a db issue)
<seb128> xnox, but geonames.org lists Hong Kong China
<seb128> it's even the first entry
<seb128> xnox, http://geoname-lookup.ubuntu.com/?query=hong%20kong doesn't
<xnox> seb128: they have full db, we have only free/small db.
<xnox> seb128: but it is weird in deed.
<seb128> xnox, well, Hong Kong is not really small ;-)
<seb128> we should have it in our db
<xnox> seb128: yeah, I'll debug it here locally, assign that bug to me plese.
<seb128> xnox, thanks
<seb128> (done)
<smoser> cjwatson, around ? i'm wondering if you've done before, or would have thoughts on how i could prototype eatmydata use of d-i
<Daviey> smoser: Don't you just need to LD_PRELOAD it?
<cjwatson> My suggestion to psusi was to put it in in-target, in debian-installer-utils
<cjwatson> For prototyping, just edit stuff on the fly in the running installer
<cjwatson> Grr, where oh where did I put my secondary backup disk
<smoser> Daviey, yes, you just LD_PRELOAD it, but i didn't know if there was a clear path to injecting that into the installer then that would immediately affect the majority of the install process.
<xnox> ev: Daviey: my lcy02 troubles ended up being a combination of old sshebang, old novarc, old default-image-id and a wrong ssh key =)
<cjwatson> in-target won't affect debootstrap but will handle the bulk of everything else.
 * xnox really had no chances =))))
<xnox> works fine now.
<smoser> maybe i'll just patch the initramfs launch of the installer.
<cjwatson> Please don't.  Use in-target
<xnox> smoser: I've had stuff spuriously failing with eatmydata, due to things not being present when there were expected to be already.
<cjwatson> Indeed, I do not want this to e.g. interfere with partitioning in some way
<cjwatson> It should be constrained to operations on the target system
<smoser> hm..
<xnox> smoser: it's best to start with in-target and then slowly move up until required performance / speed is gained. E.g. in-target will be the majority gain.
<xnox> anyway.
<cjwatson> You'll have to do it in a couple of places but that's no big deal
<zyga> hey, perhaps someone can hint me with a package I'm trying to make, it's actually a straightforward package but it's nested in a directory, without that I could do all on dh, is there a way to somehow "cheat" that?
<xnox> zyga: man debhelper, see common buildsystem options to specify "src" directory.
<zyga> xnox: thanks!
<xnox> zyga: so you'd need to override_dh_auto_[build|configure|install|test]: with dh_auto_build --sourcedirectory=subdir1/component/plugin/
<tumbleweed> no, you can pass options to dh
<xnox> zyga: I had a hack somewhere to auto strip override_ prefix, to have all four targets.
<xnox> zyga: dh --sourcedirectory=foobar shoudl work, but it didn't in the past.
<zyga> hmm
<zyga> I was just looking at that and wondering if there's DH_OPTIONS that could get that somehow, let me keep trying
<tumbleweed> I think that happens through DH_OPTIONS magic
<tumbleweed> ah, DH_INTERNAL_OPTIONS
<psusi> I'm planning on patching in-target as cjwatson suggested
<xnox> smoser: ^
<psusi> just need to build a custom preseeded install cd to benchmark before slipping in the patched debootstrap, then the patched d-i/in-target and measuring the difference
<smoser> psusi, you know that you can easily patch an initramfs by just appending a gzipped cpio to it, right?
<smoser> i'm sure you're aware, but thats probably the fastest way to hijack (and you can insert a preseed that way too)
<cjwatson> For experimentation it's way easier to just edit on the fly
<psusi> have to patch the cd to include eatmydata anyhow
<cjwatson> Also not that hard to build modified udebs, slap them in build/localudebs/ in the debian-installer source, and build a modified initramfs from there
<smoser> psusi, you can just shove it insto the initramfs, no?
<cjwatson> smoser: no, needs deb
<cjwatson> well, maybe
<cjwatson> I guess a udeb wouldn't be a terrible idea
<psusi> smoser: no, it needs installed into the target system ;)
<psusi> udeb shouldn't be needed since it isn't intented for the installer to use right?  just the target
<cjwatson> depends on whether it's easier to invoke it in the chroot or not
<psusi> so I've patched debootstrap to force install it during the stage 1 bootstrap, then set the LD_PRELOAD to use it during the second phase... so just need to have in-target also set the LD_PRELOAD so it continues to be used during the rest of the in-target install process
<cjwatson> BTW building CDs for this is a mug's game - use netboot for testing, it's way faster
<cjwatson> with a local mirror anyway
<psusi> hrm... have to set up a local mirror then...
<smoser> psusi, squid proxy is simpler there i think.
<psusi> figured it would be easier to just download and modify the cd than to download and setup a local mirror...
<smoser> anyway, psusi i'm interested in your progress there.
<smoser> http://smoser.brickies.net/git/?p=tildabin.git;a=blob;f=overlay-initramfs;hb=HEAD
<smoser> thats my "overlay-initramfs" if you're interested. it just makes patching an initramfs (possibly) simpler.
<tkamppeter> slangasek, system-config-printer 1.3.12+20130308-0ubuntu1 uploaded.
<OdyX> tkamppeter: I'm uploading latest foo2zjs to experimental, you can sync without merge as far as I can see; just ask if there's something left to accomodate.
<tkamppeter> OdyX, only Ubuntu-specific which I have in foo2zjs is that printer-driver-foo2zjs depends on mscompress.
<OdyX> tkamppeter: I have handled that difference specifically in my uploads to Debian experimental.
<OdyX> tkamppeter: granted, my changelog entry was backwards (now corrected), but I made my possible to reduce your work. :)
<tkamppeter> OdyX, great, thank you.
<OdyX> tkamppeter: my pleasure.
<slangasek> roaksoax: if adding a Conflicts: maas-provision to maas, in addition to the Conflicts: on tftpd-hpa, didn't do it, the only other thing I can think of would be to convert maas-provision into a dummy package for upgrade.
<roaksoax> slangasek: i think that would be the only option
<dsathe> hello all , i am not sure if this is the right place to ask but i couldn't find a better place
<dsathe> hello , could someone help me understand cgroup cpuacct
<dsathe> i had a few specific queries
<dsathe> the cpuacct.usage displays the number of nano seconds used by the cgroup
<dsathe> and the stat shows nett and user usages
<dsathe> how are these 2 related , and say i wanted to compute the net cpu utilization of a cgroup how would i do that ?
<roaksoax> slangasek: so basically, make maas-provision binary not depend on anything and not install anything either?
<tkamppeter> slangasek, hi
<OdyX> tkamppeter: can you prepare a cups-filter 1.0.30-1 upload to Debian experimental ?
<tkamppeter> OdyX, I will do it, I am currently only putting in the last packages for Ubuntu FF.
<tkamppeter> slangasek, can you sync QPDF 4.0.1 from Debian experimental to Raring for me? It fixes bug 923955, printing filled PDF forms.
<ubottu> bug 923955 in qpdf (Ubuntu) "pdftopdf filter fails to output form field values" [Undecided,Confirmed] https://launchpad.net/bugs/923955
<tkamppeter> slangasek, can you also sync foo2zjs_20130306dfsg0-1 from debian/experimental? OdyX has uploaded it now and it contains important bug fixes.
<pitti> jdstrand, seb128: archive grep> thanks!
<slangasek> tkamppeter: if you don't have access to sync these yourself, it's probably best if you use the normal sponsorship process (or ping someone who usually sponsors these things for you) - I'm not free just at the moment :)
<slangasek> tkamppeter: btw, on system-config-printer you sent an email asking if it was ok to update it, then you uploaded it - you understand that there is no frozen queue in the archive right now, so that upload has gone in directly?  (i.e., there's no way for me to say 'no' now anyway)
<tkamppeter> slangasek, thanks.
<jdstrand> pitti: sure thing :)
<tkamppeter> pitti, can you sync qpdf from experimental for me?
<tkamppeter> slangasek, foo2zjs I will sync by myself then, it only needs to arrive in the Debian archives.
<pitti> tkamppeter: done
<xnox> tkamppeter: fire off `syncrequest -d experimental qpdf` to file a bug, then it will get into the sponsorship queue =) http://reqorts.qa.ubuntu.com/reports/sponsoring/
<pitti> too late :)
<xnox> tkamppeter: snap. pitti is quick =)
<tkamppeter> OdyX, how long does it take until your foo2zjs from today gets syncable for Ubuntu.
<tkamppeter> xnox, thanks anyway.
<tkamppeter> pitti, thanks for syncing.
<Laney> tkamppeter should apply for upload rights to printing stuff
<OdyX> tkamppeter: I got the "UPLOADED" mail minutes ago, I suspect something in the range of hours, at most.
<tkamppeter> Laney, I am already per-package uploader for printing stuff, only QPDF seems to be missing (neds to get added by the TB).
<OdyX> tkamppeter: I'm not clear with what status the Debian packages must be in for a sync to succeed, so I don't really know.
<tkamppeter> OdyX, the Ubuntu syncpackage still found only 20130303dfsg0-1 and not 20130306dfsg0-1
<xnox> tkamppeter: check http://pad.lv/d/$packagename that's Debian mirror in launchpad. Once launchpad's mirror has the package, one can sync it.
<xnox> (look for latest upload, if stuff is in experimental)
<OdyX> tkamppeter: it's currently being built on the buildds so I guess it's "soon" now ;)
<tkamppeter> xnox, thanks.
<OdyX> tkamppeter: it might be useful for Ubuntu to sync foomatic-db 20130301 too
<tkamppeter> OdyX, I have already updated to 20130308.
<OdyX> tkamppeter: while there was no new change since then ? I'm surprised, as I thought it'd take less time to sync than to upload; apparently I'm wrong. ;)
<infinity> mdeslaur: I can do one.
<mdeslaur> infinity: ok, thanks
<roaksoax> slangasek: yeah the dummy package seems to do the trick! Thanks :) I would have never thought about that :)
<roaksoax> slangasek: but i think the other option would simply be to remove tftpd-hpa as a recommends of maas-provision
<roaksoax> that would introduce less change
<DooMMasteR> hi thereâ¦
<DooMMasteR> I have a "little" problem
<DooMMasteR> running ubuntu on a PC with a radeon HD4850 and the OSS radeon driver (not catalyst) result in a 80% certain reboot for me when using one of the fancy unity features
<DooMMasteR> Alt+Tab, Windowskey or so on
<DooMMasteR> once it worksâ¦ it runs solid
<DooMMasteR> and no logentries whatsoever
<xnox> stokachu: bug 578536 is being removed from lucid-proposed. because it has not been verified in a timely fashion.
<ubottu> bug 578536 in autofs5 (Ubuntu Lucid) "when stopped, automount orphans some mounts" [Medium,Confirmed] https://launchpad.net/bugs/578536
<xnox> stokachu: i'd think we care about it ^
<stokachu> xnox: yep already spoke to bdmurray about it
<xnox> stokachu: is that ok or not?
<stokachu> yea
<stokachu> i personally care but the ones affected by it have since migrated to precise
<xnox> stokachu: oh, nice fair enough =)
<stokachu> thanks for the heads up :P
<xnox> stokachu: I wish you'd idle on #ubuntu-release =) this is were I noticed it.
<tkamppeter> OdyX, foo2zjs 20130306 did not yet arrive on https://launchpad.net/debian/+source/foo2zjs, are you sure it built properly on the Debian buildds?
<OdyX> tkamppeter: https://buildd.debian.org/status/package.php?p=foo2zjs&suite=experimental says that it was indeed, unless you need mipsel (don't know why i386 isn't built yet)
<slangasek> roaksoax: as long as that's a reasonable change, and has the intended effect, sure
<bdmurray> seb128: I'm not sure if you saw my lightning talk but https://errors.ubuntu.com/?user=desktop-packages
<seb128> bdmurray, no, I didn't, that's nice!
<ogra_> he was to distracted by the comics :)
<seb128> lol
<bdmurray> seb128: so those are all the packages that that launchpad team is subscribed to
<seb128> ogra_, I was rather giving a chance to my laptop to cool down in the middle of a day of running hangouts :p
<ogra_> heh
 * ogra_ never runs hangouts on his laptops ... 
<ogra_> but thats just googles fault ... not providing it for arm :)
<zyga> ogra_: with what's going on you may not need a plugin soon
<ogra_> hopefully
 * zyga wonders how to use two buildystems listed by dh --list at the same time
<zyga> I want python3 and sphinxdocs
<mitya57> these are not buildsystems, but plugins â you can use "dh --with python3,sphinxdoc"
<zyga> ah
<zyga> thanks
<zyga> the man page was confusing
<zyga> hmm, it seems that dh --sourcedirectory is ignored by dh_sphinxdoc
<zyga> or I'm doing it wrong, passing --sourcedirectory to dh
<geofft> Is that an option to dh_sphinxdoc or to dh?
<mitya57> to dh
<mitya57> how is dh_sphinxdoc ignoring it?
<zyga> geofft: to dh
<tumbleweed> does the source directory matter to dh_sphinxdoc?
<zyga> mitya57: it's not finiding any docs, this is a perfectly standard python3 + setup.py + sphinx package
<tumbleweed> dh_sphinxdoc cleans up things that have been dh_installed
<zyga> _or_ I may misunderstand what I need to do
<zyga> like build docs explicitly
<zyga> but that's not specified so I don't know
<mitya57> dh_sphinxdoc doesn't build docs
<zyga> oh
<zyga> that's confusing then, ok, let me see if I can build docs explicitly
<tumbleweed> zyga: there's nothing in dh_sphinxdoc's manpage that makes me believe it would build docs
<zyga> tumbleweed: apart from the obvious name that suggest otherwise
<tumbleweed> no dh_programs build anything
<tumbleweed> dh_auto_programs do building etc
<zyga> ah
<zyga> I wasn't aware of that
<zyga> but if there's only dh_auto_build does that mean ther dh-* programs can plug into that to tell it how to build something?
<mitya57> dh_auto_build calls the relevant buildsystem
<tumbleweed> dh_auto_* use buildsystems /usr/share/perl5/Debian/Debhelper/Buildsystem/
<tumbleweed> dh_* do little jobs related to preparing a package, totally independant of build systems.
<zyga> so all the logic is in python3 buildsystem then, right?
<tumbleweed> there isn't a python3 buildsystem
<mitya57> there are distutils and pybuild :)
<tumbleweed> you are thinking of dh_python3, which just handles .pyc generation, dependencies etc.
<zyga> I'm trying to figure out if sphinx docs should build automatically and where to find the code that pokes setup.py
<mitya57> s/distutils/python_distutils/g
<tumbleweed> zyga: nothing builds sphinx automatically, you do it by hand - it takes one command...
<zyga> and I guess I should be using pybuild?
<mitya57> the code is in the relevant buildsystem, in the directory tumbleweed mentioned
<zyga> tumbleweed: ah, with all the automation I was expecting that to be called too, thanks
<tumbleweed> pybuild is still brand new, but, yeah
 * zyga looks at that now
 * tumbleweed hasn't used it for anything yet
<mitya57> brand new = available only in raring/experimental
<zyga> so no way for it to target precise for example?
<tumbleweed> zyga: while we are talking about this, --with adds things to dh's sequences - see /usr/share/perl5/Debian/Debhelper/Sequence/
<tumbleweed> zyga: correct, if you care about precise, do it by hand
<zyga> ok, let me try to get the basics first
<zyga> thanks btw!
 * zyga would wish for the buildsystem glue parts to be backported/SRUd to LTS to allow developers to target that while benefiting from the advancements
<mitya57> but if your package is python3-only then python_distutils won't help you
<zyga> it is
<zyga> so I can only use pybuild?
<tumbleweed> or by hand
<zyga> oh
<tumbleweed> like we all do
<micahg> any reason why we can't backport pybuild to precise?
<zyga> so by hand I'd have to define overide_dh_auto_{build,clean,install}
 * tumbleweed hasn't investigated
 * mitya57 thinks we can
<zyga> and basically run the relevant command there
<zyga> ok
<zyga> let me try stuff first
<tumbleweed> zyga: yes. http://wiki.debian.org/Python/LibraryStyleGuide
<micahg> oh, hrm, is it part of the python sourcE?
<tumbleweed> micahg: that's the complication...
<mitya57> micahg: it's part of python3-defaults source
<tumbleweed> but unlike dh_python2, it doesn't depend on pythonX.Y patches
<mitya57> but there was a plan to move that out
<micahg> if it was its own source,it would be easy to backport
<zyga> tumbleweed: that's very very helpful, thanks
<tumbleweed> micahg: chat to piotr
<tumbleweed> zyga: barry wrote that - it's not the style I use, but it should be helpful, yes
<xnox> zyga: but we don't have nearly as many python packages available with python3 support in precise as we do in quantal. we did massive push for python3- packages at the start of quantal.
<micahg> tumbleweed: someone else chat and I'll volunteer to twiddle the bits to make the backport happen once it's tested :)
<zyga> I'm starting the package from scratch based on the docs tumbleweed linked to
<zyga> do you know of the top of your head if using --sourcedir will allow me to keep using . as the source directory or do I need to mirror everything in each rule
<tumbleweed> . is the default source directory
<zyga> right but I cannot use that, sadly
<dobey> zyga: you need to package something that's using both python2 and 3 on precise?
<tumbleweed> oh, ISWYM. options passed to dh will still apply thansk to the magic of environment variables
<zyga> dobey: no, only python3, but I wanted to use the fancier/better build system
<zyga> (this is a pure python3 package)
<dobey> ah
<zyga> we have an unusual layout where three projects share a repository as they are coupled but need to release on separate schedule, I'm building the daily-ppa recipe+packaging
<dobey> zyga: all the u1 stuff is python2 (or 2 and 3), but this one might be helpful for you: https://bazaar.launchpad.net/~ubuntuone-control-tower/dirspec/packaging-dailies/files
<zyga> thanks, looking
<dobey> zyga: you don't also need to build on lucid do you? just precise and newer?
<zyga> what are dirspec files?
<zyga> just precise-quantal-raring
<zyga> actually
<dobey> dirspec is a python module that implements the XDG base directory specification
<zyga> oh
<zyga> why is that in the package? I'm probably missing something
<dobey> that's the branch with the dailies packaging info
<zyga> ohhhh
<zyga> sorry
 * zyga was dumb
<dobey> :)
<zyga> :)
<zyga> I thought somehow debian packaging had something to do with XDG dirs, it's just the package name here
<dobey> i think you can use that and just remove the python2-specific bits (and change the auto_test override and such if needed) to build for python3 only
<dobey> zyga: yeah, sorry. that's just the project/package name. we have all the daily build branches as lp:$project/packaging-dailies for ubuntuone stuff :)
 * zyga has to somehow drop the linaro cloak
<zyga> hmm, it's not right
<zyga> http://pastebin.ubuntu.com/5596705/ line 148 makes me think that I need to somehow quote -D (aka --sourcedir) when I pass it to dh, it gets glued on top of other options the line after that
<zyga> tumbleweed: sorry to bother you with that but apparently --sourcedirectory= does nothing in practice, all of other make target still run start running in the top-level package directory. Do you know if that's correct / expected or is it just some other mistake on my sinde?
<zyga> side
<tumbleweed> zyga: sourcedir should only affect dh_auto_...
<zyga> so in pratice I need to pass it to dh _and_ actually use it on all the commands I add on top
<xnox> zyga: if you override dh_auto_configure, then yes you will have to add --sourcedir there.
<zyga> grepping for that I find very little references, all in Dh_Buildsystem.pm (opt_sourcedir)
<xnox> zyga: note that dh_install has no idea about sourcedir, only dh_auto_configure|build|install|test do.
<tumbleweed> xnox: practically, I don't think so, thanks to environment variable magic
<zyga> let me try something\
<xnox> tumbleweed: hmm.. interesting. I should experiment more with it then.
<tumbleweed> zyga: if yu are doing a pure-python3 package you have to override dh_auto_* anyway, so --sourcedir is moot
<xnox> zyga: what are you packaging? do you have a tiny example. It's easier to prototype / tinker with stuff.
<zyga> xnox: sure, I'm packaging plainbox, it's a rewrite of checkbox, the code is in lp:checkbox (in the plainbox directory there), the package is still on my disk but it's vanilla example as copied from http://wiki.debian.org/Python/LibraryStyleGuide
<xnox> zyga: and you will still be building the rest of checkbox at the same time? or separate source package?
<zyga> a simple echo + pwd shows that --sourcedirectory does not do any magic to redirect where all the commands from debian/rules are started in
<zyga> xnox: no, checkbox is separate and will stay that way
<zyga> xnox: plainbox is a fresh start so to speak
<zyga> xnox: checkbox is actually a native package so it's even worse than that
<xnox> zyga: sure, so why doen't it release fresh tarballs as top level =) or are you shipping duplicate source code in two packages?
<zyga> xnox: plainbox is normally published on pypi, only the part that builds the daily deb has to worry about the layout
<xnox> zyga: ah, for daily build we can do ugly hacks and tricks then!
<xnox> awesome, gotcha.
<zyga> yeah
<zyga> the normal package should be far saner
<zyga> :-)
<zyga> ok, let me add ( cd plainbox && ..) to all the places that matter then
<xnox> zyga: I would do "normal" packaging in plainbox/debian (such that it can be later reused for archive uploads) and in the top level ./debian/rules change it to be a wrapper script, and symlink the copyright & control.
<zyga> hmm
<zyga> let me think about that because I'm not sure I understand
<xnox> the wrapper script simply does ( cd plainbox && ./debian/rules $@)
<zyga> ah
<zyga> right
<zyga> nice
<zyga> yeah, that might work
<zyga> I need to see if it will work with the way the recipe is expressed
<zyga> it uses nest-part and stuff like that
<xnox> but you will need to symlink control & changelog, as those two things are looked up by e.g. debuild and etc.
<zyga> and starts with the _packaging_ branch, not lp:checkbox, because it's impossible to nest-part of the root recipe repository
<zyga> right, I get that
<zyga> xnox: neat idea, let's see
<xnox> zyga: if you use a recipe, you can nest the _other_ way around. and it should work.
<zyga> xnox: other?
<xnox> starting recipe from packaging branch is good in this case.
<xnox> (that's what I meant)
<zyga> http://pastebin.ubuntu.com/5596780/
<zyga> right
<zyga> that's what I do
<xnox> hmm...
<xnox> wait my hacks might not work then. Or can you commit /plainbox/debian to lp:checkbox?
<zyga> xnox: we _could_ but I think we don't want to
<xnox> zyga: fair enough.
<zyga> xnox: we had debian in checkbox forever and that's a pain to keep
<zyga> xnox: all the changelog updates conflict on merges
<xnox> =)
<xnox> _very good_
<zyga> xnox: with plainbox I always wanted to do packaging with git and build debian/changelog from the git log
<zyga> (but that's hard to do since I was asked to use bzr)
<zyga> almost done with that wrapper layout
<xnox> unless you maintain a mirror, but yeah, still a pain.
<xnox> zyga: yeah, i fear it might fail to build though.
<xnox> zyga: how far back do you need support? precise?
<zyga> yes
<zyga> I'm fine with doing a different build for precise
<zyga> even from manual releases
<zyga> though I _may_ be wrong still
<zyga> we do some magic in which version is used
<zyga> as in: for ubuntu we have stuff in lp:ubuntu/checkbox
<zyga> for development, we have a ppa
<zyga> for everyone else (lots of uses) we have a second ppa
<xnox> zyga: so using this: http://wiki.debian.org/Python/AppStyleGuide
<zyga> (so the recipe does not work as both have 'plainbox' directory, boo, let's see if I can make that work somehow
<xnox> zyga: python2 only or both python2 and python3 supported with plainbox?
<zyga> the full code is in python3.2+, no support for 2.* at all
<xnox> good.
<zyga> I think I know how to solve that
<zyga> I'll do even crazier redirect
<zyga> the top level will redirect to nest-ed checkbox/plainbox
<zyga> so no conflicts on debian/ from lp:checkbox
<zyga> xnox: that worked :D
<zyga> awesome
<zyga> that has to be the most tricky package I ever did
<xnox> zyga: and build the source package -> that can build binary package?
<zyga> thanks a _lot_ xnox, tumbleweed, dobey
<zyga> yes
<zyga> and run the test suite
<zyga> and has autopkgtests
<zyga> and docs
<tumbleweed> np
<xnox> zyga: for reference this works for me - http://paste.ubuntu.com/5596825/
<zyga> thanks
<xnox> obviously needs additional overrides for test/clean.
<zyga> oh, translations
<zyga> I need to look at that
<zyga> the package is not done yet, it still builds phony/broken python2 layout, I just added --without python2
<zyga> but I'm on the right track
<xnox> zyga: yeah, checkbox is on the livecd so it intergrates with language packs.
<zyga> and that's what --with translations does?
<xnox> yes.
<xnox> zyga: better echo 9 > debian/compat
<xnox> zyga: that prevents running python-support, and no need to do "--without".
<xnox> zyga: debhelper 9 is in precise.
<zyga> ah, cool
<xnox> (and it's --without python-support
<xnox> )
<xnox> zyga: or wherever debian/compat is located in your case =))))))
<zyga> I guess I spoke too soon, some of the symlink magic is wrong, let me read the full log
<zyga> heh, yes
<zyga> at the end, dh expects debian/ to have stuff that's really in checkbox/plainbox/debian
<zyga> hmm
<xnox> zyga: yeah, hence my paste above as to making it work "normally"
<zyga> looking again
<zyga> ok, let's see
<xnox> zyga: here is slighltly better version http://paste.ubuntu.com/5596840/ , doesn't run any tests, and works with just normal subdir.
<zyga> let me pastebin mine, it's based on the previous one from you
<zyga> actually, since I snapshot everything: lp:~zkrynicki/+junk/plainbox-daily-pkg
<zyga> mine is still broken, give me a sec
<xnox> I prefer make functions over embedding shell lines \
<xnox> with continuation lines
<xnox> \
<zyga> yeah, I just copied the example from barry
<xnox> *whoops forgot \ *
<barry> whu? huh?
<xnox> zyga: yeah, but it does stuff that you don't need e.g. python2 as well as python3.
<xnox> barry: your wiki page on debian.org. go back to idling =)
<barry> xnox: o/
<xnox> \o
<xnox> barry: w.d.o/py3/LibraryStyleGuide that is in above reference
 * barry nods
<zyga> ah, typo and it should really work
<zyga> yes
<zyga> woot
<jbicha> micahg: I didn't realize gimp was still in main so it'll need a sponsor
<zyga> the -docs package is empty, everything is in the main, let's see
<micahg> jbicha: I can do that (though maybe not until Sunday), where's the debdiff
<zyga> ah
<zyga> barry: "You will not need an .install file for the documentation (TBD: explain why this works automatically)"
<zyga> barry: quoting http://wiki.debian.org/Python/LibraryStyleGuide
<zyga> barry: my package has no python2 support so I named the main docs package python3-plainbox-docs
<zyga> barry: does that not count under the 'this works automatically'?
<jbicha> micahg: bug 1132767
<ubottu> bug 1132767 in gimp (Ubuntu) "Update GIMP to version 2.8.4" [Undecided,Triaged] https://launchpad.net/bugs/1132767
<barry> zyga: sorry, my stack is too deep atm ;)
<zyga> barry: ok, np :)
<zyga> xnox: ^^ do you know why -docs packages don't need '.install' file?
<dobey> "If upstream has documentation that's built by Sphinx, these next few lines will build and install them for the separate python-foo-docs package mentioned above."
<dobey> zyga: ^^ perhaps that section is why?
<zyga> dobey: thanks, I was looking at that now, the problem here is that it assumes hybrid 2k-3k packages and for packages that don't support python2 it makes no sense for python-foo-doc package
<zyga> dobey: I've just added an install file for -doc to see if that's all I nee
<zyga> need
<dobey> zyga: well, it's easy enough to test and correct if it fails, i guess :)
<zyga> yeah
<zyga> hmm, should the package have -docs (as in the wiki) or -doc as most do?
<zyga> is that a bug in the wiki
<captainlinux> Guys, is there any way to give a Qt application direct root privileges without making a jump from one application which will ask user to authenticate and then launch the main app with root privileges?
<dobey> zyga: i think -doc is preferred. both are used according to apt-cache, but for python, most all the ones with -docs say (transitional package)
<zyga> shall I edit the wiki then?
<xnox> captainlinux: you can use policy kit to write a policy and package it to allow limited specific privileged actions.
<dobey> zyga: i don't know. i'd let barry answer that.
<xnox> captainlinux: or use pkexec.
<captainlinux> xnox: My application should be able to edit files in /etc/ and I was already thinking about trying PAM-Api but I'm totally new in the native Linux development so before I will go on and hit my head against the wall I better ask for any alternatives or tricks...
<xnox> captainlinux: scary. one should not programmatically be editing files in /etc/
<xnox> captainlinux: note on ubuntu phone /etc/ will be read only anyway =)
<micahg> jbicha: gimp looks like a merge more than a sync since we still have changes, maybe keep the changelogs so that the reasons for the changes are clear?
<captainlinux> xnox: Okay, and what if I want to edit...Let's say... /etc/default/grub would it still be a bad Idea to try editing it?
<zyga> captainlinux: the problem with everything in /etc is that 1) historically they use different formats 2) most are pretty much mini-programs that have control flow 3) most are designed to be read by humans
<zyga> captainlinux: it's virtually impossible to have any generic too to edit all of that without starting from scratch,
<zyga> captainlinux: for a particular problem, sure it might be doable
<zyga> captainlinux: but getting write access is the least difficult problem
<captainlinux> zyga: Okay, thanks, I understand.
<xnox> captainlinux: yes. we had in the past an "editor" that was editing /etc/default/grub apart from it was inserting invalid characters, thus kernels were failing to upgrade and machines were failing to boot.
<xnox> captainlinux: we have literarly thousands of bugs from users in launchpad, all of who we had to help out.
<xnox> captainlinux: look for many tweak tools in the past
<xnox> captainlinux: all of them eventually are broken, when config move on.
 * zyga would love to see "linux" userspace to adopt plists en-masse
<xnox> captainlinux: there is no guarantee config files will stay compatible for third party applications to modify.
<zyga> parsable, stronger than json, 3 encodings, including one very efficient for really large things
<captainlinux> zyga: I agree on the plist thingy...
<xnox> captainlinux: you could help implement https://wiki.ubuntu.com/StartupSettings
<xnox> captainlinux: we have designs done, but nobody so far started to implement grub boot options as shown there.
<zyga> xnox: I had to move building sphinx from override_dh_installdocs to override_dh_auto_install as otherwise the explicit -doc.install file would break the build
<xnox> captainlinux: we want this as part of the ubuntu control center.
<zyga> xnox: cool stuff, I didn't knew about that
<captainlinux> xnox: Looks nice!
<zyga> xnox: I guess it'd be possible to patch all the grub config tools to use a strict, plist/json like format and build a library that manages that, including schema changes, reverting broken configs etc
<zyga> still an enormous project
<zyga> and grub is quite tricky as mistake == boot gone
<lifeless> booting is overrated.
 * captainlinux laughs at "mistake == boot gone".
<captainlinux> But still, it's true. :)
<dobey> makes it super easy to brick your phone :)
<zyga> lifeless: to the meme "I don't always boot but when I do I do it right" ;)
<lifeless> zyga: brilliant!
<dobey> "I don't always boot, but when I do the framebuffer is full of fuzzy green stuff."
<psusi> lol... the most interesting computer in the world? ;)
<captainlinux> xnox: I'll definately look at this one. Seriously.
<dobey> i wish i could give someone a dos equis to fix my kernel bug, at least
<xnox> captainlinux: mpt did the design he hangs out here and #ubuntu-design and #ubuntu-installer. And this needs to be a plugin/page in gnome-control-center. You are more than welcome to start implementing it. And a few folks here can help with implementation (e.g. me)
 * zyga would start with the low level parsing/validation/testing code
<zyga> the GUI is at the far end of that story
<roadmr> hey folks, I asked a user to run apport-collect on a raring system and he says he got "this functionallity is not avaible.
<zyga> or plain patches to grub config to have no need for parsing
<roadmr> Launchpadlib is not installed." Is this correct? are additional packages needed for him to use apport-collect?
<zyga> roadmr: the functionality of answering questions is not available ;-)
<roadmr> zyga: apt-get install python-force-zyga-to-answer :D
<zyga> roadmr: python3-launchpadlib maybe?
<zyga> roadmr: you forgot sudo
<zyga> roadmr: is launchpadlib not python2 only?
<zyga> roadmr: maybe it's a bug where apport is python3 and launchpadlib isnt?
<roadmr> zyga: yes I know, my question is, is an additional package required to use apport-collect? if so it seems like a sucky user experience :/
<captainlinux> xnox: Are there any restrictions to the language which should be used to implement that thingy?
<roadmr> zyga: oh good point, let me check on my recently-installed raring test box
<zyga> captainlinux: if you include python3, go and Qt in the list then you are good to go probably
<roadmr> zyga: btw: http://xkcd.com/149/
<zyga> captainlinux: I would not touch C++ for that, python3 is probably safest for ensuring quality vs effort needed
<dobey> zyga: i don't think you can write gnome-control-center plug-ins in those
<TheLordOfTime> roadmr, apport-collect *shouldn't* need a separate package, last I checked, at least.
<zyga> roadmr: I knew that, I was expecting it to happen :D
<zyga> dobey: the backend is important
<zyga> dobey: the plugin can talk to that over dbus maybe?
<zyga> dobey: and be written in vala for all we care
<zyga> if that backend was there and robust I would write the gui :D
<roadmr> TheLordOfTime: hmm thanks... well the user reported a problem with checkbox which I can't reproduce, so I guess his system has something weird, which *may* include apport-collect being broken :/
<xnox> captainlinux: at the moment gnome-control-center is Gtk+3, if you implement this in QML / Qt+5 we should be able to integrate it as well at one point in the future.
<zyga> roadmr: I remember some apport bugs when python3 transition happened
<zyga> roadmr: specifically with some stuff that was 2.0 only
<zyga> 2.x
<roadmr> oh interesting, I got "you need to run sudo apt-get install python-apport". That's very disconcerting :/
<zyga> roadmr: but it's lated and I'm checking why dh is not installing docs at all :)
<dobey> xnox: how much of the gnome bits are going to remain on the phone/tablet/converged ubuntu though?
<zyga> ha
<zyga> see
<roadmr> zyga: hehe never mind this, I can always ask the user to just attach a log file.
<zyga> roadmr: "dear user, send me your hard drive"
<roadmr> better yet, the whole laptop! I can reinstall it and leave it like new %)
<captainlinux> xnox: Yeah, I started to work with Qt two days ago. Immediately liked it, lol. Used to work with C# and Java on Windows and dropped C# after switching to Linux.
<dobey> roadmr: please file a bug against apport about apport-collect not working
<roadmr> dobey: phew, at least ubuntu-bug *does* work :D
<zyga> dobey: I suspect that bug is reported if I'm correct, roadmr make sure to look for dupes first
<dobey> roadmr: the "you need to install python-apport" thing is a bug
<dobey> i just looked at the code to verify
<zyga> oh
<dobey> and it's definitely doing the wrong thing
<TheLordOfTime> ah, that bug... i heard about that one...
<zyga> but you know
<TheLordOfTime> forgot about it for a moment there :P
<zyga> if launchpadlib is 2.x only
<roadmr> dobey: ok, thanks for checking! filing now...
<zyga> this might be hard to solve
<dobey> zy it's not
<zyga> no?
<zyga> ah
<zyga> sorry, I was recently coding something against bzrlib
<zyga> (I was using both obviously)
<dobey> zyga: or well, i don't think apport uses launchpadlib any more. i think python-launchpadlib is python2 only
<dobey> zyga: something saying to install launchpadlib is probably wrong
<hallyn> (fwiw, apologies, i won't be able to patch-pilot today.  will cathcup sometime next week)
<zyga> dobey: ah, so launchpadlib _is_ 2.x only?
<dobey> zyga: according to apt-cache search at least, yes
<zyga> right, then I remembered correctly
<zyga> it's one of the few things that prevented me from using python3 then
<captainlinux> xnox: And after I saw the latest news about rewritten Unity and better Qt integration I was like, okay probably it's good to stick with Qt...
 * zyga wonders how soon desktop will start replacing gnome stack with some new qt stuff
<dobey> zyga: kenvandine already rewrote gwibber in qml
<zyga> dobey: I heard, and there's Friends announced recently
<roadmr> dobey: filed bug 1152750, though launchpad found another that might be the same problem; I linked that in my bug
<ubottu> bug 1152750 in apport (Ubuntu) "apport-collect doesn't work, asks to install python-apport" [Undecided,New] https://launchpad.net/bugs/1152750
<captainlinux> dobey: Yeah, I was really glad to see that one finally being rewritten!
<xnox> captainlinux: so at the moment gnome-control-center cannot have plugins written in qt, so it will need to be integrated as a separate app/process but that's ok.
 * zyga wonders about that elementaryos stack for config
<zyga> plugs?
<zyga> but that's all vala
<zyga> so if we're going to stick to qt it might make sense to ignore that
<captainlinux> xnox: I'll think about that. Since I will have to learn some Python for my final exam anyway I can't really deny the fact that I could also try to do it in Python.
<dobey> oh, apport does still use launchpadlib
<dobey> it's just completely ignorant of the fact that it's not ported to python3
<dobey> someone jumped the gun on that one
<zyga> ;D
<zyga> I knew I was right
<zyga> heh
<zyga> I remember bugs about side effects of that bug
<jbicha> micahg: yes it's the tradeoff between simplifying the diff with Ubuntu or simplifying the diff with Debian
<dobey> so even my fixing the u1 apport hook to work in py3 doesn't help because the launchpad craschdb_impl doesn't work in py3
<dobey> whee
<zyga> dobey: how hard would it be to port launchpadlib and lazr to py3k?
<zyga> dobey: I kind of would like that anyway
<dobey> zyga: difficulty quotient greater than 0 :)
 * zyga things someone mis-scheduled porting stuff to py3k without doing those two first
<xnox> zyga: barry gave up on porting launchpadlib and the whole mess of dependencies.
<zyga> ohhhh
<xnox> it was a forest of problems.
<zyga> barry: is porting launchpadlib hopeless?
<xnox> launchpadlib is ok, all the deps are not.
<dobey> there's a reason u1 isn't on py3 yet too :)
<zyga> it's ironic that people can write py3k github.py file with requests and a few classes and launchpadlib is impossible to tackle
<xnox> dobey: what do you mean fixing u1 apport hook to work in py3 doesn't help? why not?
<zyga> dobey: deps include lazr, keyring, oauth, wadlib
 * xnox thought it worked fine when i was testing my patch locally (which got redone differntly upstream)
<jtaylor> this seems to be needing fixes for our python m-a: http://www.gnu.org/software/autoconf-archive/ax_python_devel.html
<dobey> xnox: because the crashdb is launchpad. so it can't actually upload anything to a bug?
<xnox> zyga: wadlib was problematic.
<jtaylor> someone already submotted a patch?
<xnox> dobey: sure it can. apport is fully python3 only and it uploads to launchpad just fine.
<zyga> xnox: depends on lazr, I assume it's from canonical then
<dobey> xnox: /usr/lib/python3/dist-packages/apport/crashdb_impl/launchpad.py:    from launchpadlib.launchpad import Launchpad
<dobey> xnox: ^^ that says otherwise :)
<zyga> xnox: but python3-wadllib is in the archive :D
<zyga> xnox: so it's cannot be hard
<xnox> dobey: right, but apport does execute the hooks with python3.
<xnox> dobey: so they must be in python3.
<dobey> xnox: which is horribly unfortunate, but eh
<xnox> dobey: regardless of what is used elsewhere.
<xnox> dobey: sure but I submitted a patch and it should be sru'ed into quantal.
<zyga> I hope nothing ends up importing bzrlib, good luck porting that to py3k in one go
<xnox> dobey: (but note that my patch was redone)
<dobey> like i said. someone totally jumped the gun on porting apport to py3
<dobey> xnox: yes, i re-did it :)
<zyga> dobey: I recall that was done for some other reason -- porting apport
<zyga> dobey: perhaps that's was a tradeoff they took
<xnox> dobey: no, they didn't. it's easy to write bilingual py2/3 and there shouldn't be anything complex required in the hooks.
<xnox> zyga: push to have none or as little as possible of python2 on the cd.
<dobey> xnox: i think you're confusing multiple issues
<xnox> maybe =)
<xnox> it's late here ;-)
<xnox> and it was a full week here.
<dobey> and forcing python2 apps to have to depend on python3 stuff just because apport is in py3 is silly. it means it's impossible to import something from the app itself (like say, a constants module with some information), to get more information
<dobey> anyway
<dobey> i'm over that
<xnox> i see your point.
<xnox> it was not my call to do apport in python3 in quantal =)
<micahg> jbicha: personally, I don't mind changelogs as it means I don't have to hunt through the package history on launchpad
<barry> zyga, xnox, dobey i'd love to see a py3 launchpadlib, and right, wadllib is done.  port to built-in json, and you can drop pytho-simplejson. lazr.restfulclient and its deps are the pita. :(
<barry> actually, it's deps aren't bad
<barry> modulo json for simplejson, and oauthlib for oauth
<barry> even lazr.uri is py3
<dobey> it's too bad that the python3-twisted* doesn't work though
<barry> dobey: even after our funding?  is it incomplete or is what's there just not working?
<barry> dobey: (i'd like to be able to informatively harass glyph when i see him next week ;)
<zyga> barry: so what is the biggest problem lazr.restfulclient?
<dobey> barry: i don't remember exactly what doesn't work. i tried to run ubuntuone-dev-tools tests with it once and it was a landslide of fail though
<dobey> barry: i think it's mostly trivial stuff ad tedium, though
 * zyga thinks that dh_installdocs is borked
<barry> dobey: so maybe just incompatibilities, but details uncertain atm?
<zyga> why is it installing stuff to $PACKAGE rather than to tmp? it breaks everything as it picks the first package from debian/control
<dobey> barry: yeah. and fixing one thing leads to another, and so on, and on and on and on :)
<barry> zyga: it's been quite a while since i took at crack at l.rc for py3.  what work i did do is checkpointed in lp:~barry/lazr.restfulclient/py3
<dobey> zyga: do you only have one package in debian/control?
<barry> dobey: sounds familiar ;)
<zyga> dobey: no, three
<barry> (as a side project i've been trying to port restish, and have hit a point where if a core data structure, which is a str in py2, cannot be either a str or bytes in py3 without failures somewhere)
<dobey> barry: that also sounds familiar :)
<hallyn> anyone know of a wait option or wait-like call to detect if task is zombie (without parsing /proc/$$/stat{,us}) ?
 * barry thinks we need a lemmecheatstr for py3
<zyga> hehehe
<zyga> barry: would that be bytes | str magic wrapper?
<barry> zyga: exactly, but you'd only be able to use it after 3 days of non-stop porting pain
<zyga> barry: we can also wait for economy to win
<zyga> barry: stuff that's too hard to port or not maintained will be replaced
 * zyga mumbles something about our new ruby on rails overlords
<zyga> ;)
 * slangasek points out that the last typewriter factory closed this decade
<barry> zyga: is that like, "wait long enough and nothing matters"
<slangasek> the long tail is a ribbon covered in ink
<zyga> ok, the package seems to work
<zyga> the rest are upstream bugs on sdist that I'll fix tomorrow
 * zyga pushed new plainbox packaging to launchpad
<zyga> and updated the recipe
<zyga> roadmr: still working?
<zyga> roadmr: I'd like to crate a vagrant environment for running SRUs from the daily ppa
<zyga> roadmr: a vanilla image that adds the ppa and installs/updates the package
<roadmr> zyga: yes, it's only 4:20 PM here :)
<zyga> roadmr: + some testing on what we get from that
<zyga> roadmr: would you like helping me on monday?
<zyga> roadmr: oh
<roadmr> zyga: sure, I can help!
<zyga> roadmr: basically, a new directory with Vagrantfile
<zyga> roadmr: that just deploys plainbox from the ppa and gives us ssh
<roadmr> zyga: so we'd be using a cloud image as the base still?
<zyga> roadmr: yes
<zyga> roadmr: let's start with precise for simplicity
<zyga> roadmr: we'll have some churn over the next few days to add 'plainbox sru' command
<zyga> roadmr: and that's the test target
<roadmr> zyga: ok
<zyga> roadmr: thanks
<zyga> roadmr: I should really be going
<zyga> roadmr: if you want plainbox debs built locally
<zyga> roadmr: I can give you a quick recipe
<roadmr> zyga: sure, I usually use sbuild for that but if this is quicker it's ok
<zyga> roadmr: http://pastebin.ubuntu.com/5597142/
<zyga> roadmr: that's crude, just branch checkbox and plainbox-packaging and update those paths
<roadmr> oh neat!
<zyga> roadmr: then build.sh builds subsequent attempts
<zyga> roadmr: if you need to change anything in packaging, commit, otherwise it gets ignored
<zyga> (in the packaging)
<zyga> roadmr: try getting vanilla precise and installing that package
<zyga> roadmr: if you get an MP for that vagrantfile I'll gladly review that
<roadmr> ok sounds fun
<zyga> roadmr: I rewrote all packaging and it should work now
<roadmr> zyga: does the packaging branch still live in github?
<roadmr> it lives!!
<zyga> no
<zyga> we moved it to lp:~checkbox-dev/checkbox/plainbox-packaging
<roadmr> oh awesome :)
<zyga> I pushed rev3
<zyga> (that was squashed with git, I had ~70 revisions like "snapshot" before I got this right)
<roadmr> haha snapshots ftw
<zyga> roadmr: https://code.launchpad.net/~checkbox-dev/+recipe/plainbox-daily
<zyga> roadmr: I've queued builds to see what I got wrong
<zyga> roadmr: but it builds for me
<zyga> roadmr: though, not in pbuilder, I was too lazy
<zyga> roadmr: if you can check it in sbuild that'd be great too
<roadmr> zyga: hahah :) use sbuild! it's 3 commands to set up
<zyga> roadmr: I need to take a break
<zyga> roadmr: thanks for the help
 * zyga EODs at 22:25
<roadmr> zyga: good night :)
<zyga> barry: is it sane for python3 only package to build-dep on python2-minial to get pyversions which it is _not_ using as needed by python_distutils.pm, see: http://paste.ubuntu.com/5597227/ at line 851
<ScottK> zyga: No
<zyga> ScottK: is that a build system bug?
<ScottK> It's a lack of python3 support in debhelper.
<zyga> ScottK: shouldn't debhelper then depend on python2-minimal?
<ScottK> No.
<barry> pybuild perhaps
<ScottK> You only need it if you are building something for python.
<ScottK> I think you're solving the wrong problem.
<zyga> barry: you mean switch to --buildsystem=pybuild?
<zyga> ScottK: well, as the pastbin shows: it fails to build, and I'm building a python3 only app
<barry> zyga: that's probably the way to go in the long run, yes
<barry> zyga: sorry, i am just slammed right now, with only a day and an hour of work time before pycon :/
<zyga> barry: thanks, sorry
 * roadmr pops up his ears
<ScottK> zyga: build system distutils doesn't know about python3.
<zyga> ScottK: I'm not sure how that works, where does --with=python3 come from? I'm trying to see what's missing the dependency - our package or part of the build system
<ScottK> zyga: Where's the package?
<ScottK> (or pastebin your debian/rules)
<zyga> ScottK: the code is in lp:~checkbox-dev/checkbox/plainbox-packaging
<zyga> roadmr: could you pastebin that please?
 * zyga is on a tiny netbook where any browser hurts
<zyga> (which is ironic given the name)
<zyga> ScottK: that's only the debain package mind you, the code is in lp:checkbox (in the plainbox directory)
<roadmr> zyga, ScottK : http://paste.ubuntu.com/5597238/
<zyga> s/debain/debian/
<ScottK> zyga: Here's one that works - http://paste.ubuntu.com/5597241/
<zyga> ScottK: sorry, what does that mean?
<ScottK> Don't use dh_auto_build/install
<zyga> oh
<ScottK> Since DH doesn't konw about python3, auto_* will not DTRT.
<zyga> would adding --without=python2 be appropriate?
<ScottK> No
<zyga> ok
 * zyga is very confused about how that all works but that's fine 
<zyga> roadmr: ^^
<zyga> roadmr: so I guess we can drop dh_auto_{build,install} and do that manually
<zyga> roadmr: if you can try to solve that and push the packaging branch that'd be a good EOD :)
<ScottK> Note that there's no need to do per python3 version build/install for pure python3 code.
<zyga> oh
<zyga> that's  cool
<zyga> so we can drop most of the complexity
<zyga> thanks for the tip!
<roadmr> zyga: ok I can try :)
<zyga> roadmr: thanks
<zyga> roadmr: the build script should help you do that quickly, then you can check sbuild for correctness
<roadmr> zyga: anyway my raring sbuild complained that python2-minimal is not installable ;(
<micahg> there's python-minimal and python2.7-minimal
<micahg> though in raring, I don't think you'd want either
<ScottK> Certainly not for a python3 application.
#ubuntu-devel 2013-03-09
<YokoZar> If a confirmed bug has a patch is ready for sponsorship posted, what should I set its status to?
<jtaylor> YokoZar: triaged is appropriate but it often doesn't really matter,make sure to subscribe  ubuntu-sponsors
<jtaylor> and add tag patch
<YokoZar> jtaylor: Hmm, adding tag patch isn't on the sponsorship wiki page, should it be?
<YokoZar> jtaylor: thanks regardless :)
<jtaylor> maybe, I don't think it matters much
<jtaylor> it prevents a bot from adding it and posting a comment :)
 * xnox 's new desktop's cpu fan starts with delay, no video, no bios *sigh*
<cjwatson> OdyX: Hmm, I wonder why printer-driver-foo2zjs recommends foomatic-db-engine - isn't that meant to be a build tool?
<cjwatson> OdyX: (FWIW this has broken our image builds since foomatic-db-compressed-ppds now Conflicts: foomatic-db-engine and we're trying to install both)
<cjwatson> tkamppeter: ^-
 * cjwatson files bug 1152831 for that
<ubottu> bug 1152831 in foo2zjs (Ubuntu) "printer-driver-foo2zjs Recommends: foomatic-db-engine while foomatic-db-compressed-ppds Conflicts: it" [Critical,New] https://launchpad.net/bugs/1152831
<psusi> so these days debian has a nice gtk debconf frontend that you can chose to have d-i use from the main install boot menu... why don't we have that?
<SunStar> or a prettier grub like debs
<tkamppeter> cjohnston, new foo2zjs uploaded
<tkamppeter> OdyX, hi
<tkamppeter> OdyX, around
<mlankhorst> well seems i need more ram to compile llvm-3.2 on this poor panda
<ogra_> swap FTW
<mlankhorst> yeah I know, I think I'll hammer the physical ppa builders though instead ;D
<ogra_> if its only a bit, you can install zram-config
<mlankhorst> it's oom
<ogra_> the compression gives you about 50% extra ram
<mlankhorst> won't be enough :)
<ogra_> well, the pandas in the datacenter also just add a 20G swapfile on disk ... we didnt magically solder ram on top :)
<mlankhorst> indeed, but it saves me from killing a ssd
<ogra_> yeah, but the datacenter buildds cant easily use ccache
<mlankhorst> neither can I :)
<OdyX> tkamppeter: now yes ;)
<tkamppeter> OdyX, I have sybced foo2zjs to Ubuntu and shortly after made a new upload, dropping the Recommends: foomatic-db-engine. Due to your Breaks: foomatic-db-engine in foomatic-db-compressed-ppds printer driver packages cannot recommend foomatic-db-engine any more as otherwise Ubuntu does not install.
<OdyX> tkamppeter: hrm, that's unfortunate indeed.
<OdyX> tkamppeter: taking a look at the big picture, is the Breaks: foomatic-db-engine correct at all ?
<tkamppeter> OdyX, I also had to add Conflicts:  and Replaces:  foomatic-db-engine to foomatic-db-compressed-ppds as otherwise the update to the new version of foomatic-db-compressed-ppds did not work.
<OdyX> tkamppeter: because if that's the wrong thing, then that should be fixed.
<tkamppeter> OdyX, I would prefer to remove the Breaks:, as foomatic-db-compressed-ppds is hard-wird into Ubuntu due to a Depends: in ubuntu-desktop and I as printer driver package maintainer have often to install foomatic-db-engine, so I like to have it present together with foomatic-db-compressed-ppds.
<OdyX> tkamppeter: the rationale was in http://bugs.debian.org/627770
<ubottu> Debian bug 627770 in foomatic-db-engine "foomatic-db-engine doesn't work with foomatic-db-compressed-ppds" [Normal,Fixed]
<OdyX> tkamppeter: then foomatic-searchprinter should be fixed to either fail gracefully, or work with -compressed-ppds
<tkamppeter> OdyX, independent of this, we should remove all "Recommends: foomatic-db-engine" in any package, as with foomatic-db-compressed-ppds foomatic-db-engine gets a developer package as gcc.
<bl4de> hi guys
<tkamppeter> OdyX, probably foomatic-searchpackage should give a decent error message telling that no XML database is present.
<bl4de> I'd like to help with devel of Ubuntu...bug correction, implementing new features and so on...in particular I'd like to help with Unity
<OdyX> tkamppeter: yeah, hence cjwatson's point as I read it: foomatic-db-engine is only needed rarely by foo2zjs, and should probably rather be demoted to Suggests
<bl4de> I have already a launchpad account, gpg key, and pbuilder configured...and now? :)
<OdyX> tkamppeter: if foomatic-db-engine gets fixed for foomatic-searchprinter to fail gracefully, I'd be happy to drop the Conflicts in foomatic-db-compressed-ppds
<bl4de> ...anyone can help me to help? XD :)
<vibhav> bl4de: Did you have a look here: http://developer.ubuntu.com/packaging/html/ ?
<cjwatson> bl4de: Does https://wiki.ubuntu.com/ContributeToUbuntu help you at all?
<cjwatson> bl4de: #ubuntu-unity might be useful to you as well
<OdyX> tkamppeter: the packages which recommends foomatic-db-engine are foo2zjs, min12xxw, foomatic-db*, foomatic-filters , education-common and task-print-server , probably too late for Wheezy for those, but I can demote all the printing-related ones in experimental and file bugs for the other ones
<tkamppeter> OdyX, what is the benefit of having foomatic-db-engine installed when one uses foo2zjs? AFAIK printer-driver-foo2zjs has a complete set of ready-made PPD files and so it does not to generate PPDs from XML at runtime.
<tkamppeter> OdyX, for me this Recommends: is a remainder of old on-th-fly XML->PPD times.
<OdyX> tkamppeter: well, I've made foo2zjs build the PPDs at build-time (using foomatic-db-engine), so no it's not needed for that. I guess we can drop that altogether.
<OdyX> tkamppeter: are there some packages shipping only xml files ?
<tkamppeter> OdyX, this is what I did in today's upload to Ubuntu.
<OdyX> tkamppeter: yeah, saw that, I will add that to Debian's git repository.
<OdyX> tkamppeter: will you release a new foomatic-db-engine with the corrected foomatic-searchprinter ?
<OdyX> tkamppeter: ah, could you eventually comment on Debian's #702227 too ?
<vibhav> [edit]
<vibhav> [edit]
<vibhav> [edit]
<vibhav> [edit]
<vibhav> [edit]
<vibhav> sorry people
<vibhav> (stdupid keyboard)
<vibhav> stupid, even
<cjwatson> tkamppeter: Dropping the Breaks would certainly simplify upgrades; the fewer forced removals we have the better, even if we no longer install it by default
<cjwatson> tkamppeter: Though it's no longer urgent - thanks for the fixes
<tkamppeter> OdyX, about Debian bug 702227, CUPS backends with 750 root.root permissions/ownerships are run as root by CUPS, these backends have to run as root as they need access to resources where only root has access (files, network resources). Opening up the permissions so that "lp" can run the backends makes the backends stop working. What alwyas works would be setting the wrapper backends 750 root.root, but this can lead to some non-root backe
<tkamppeter> nds being run as root.
<ubottu> Debian bug 702227 in cups "Permission of the backend too strict for a backend chain (beh, jasmine)" [Minor,Open] http://bugs.debian.org/702227
<mitya57> Hi DktrKranz, may I ask you to review ubuntu-packaging-guide 0.3.1, in Debian NEW queue?
<mitya57> It adds new packages with russian translation
<leex-> if the installer fails on a fresh install with: The 'grub-efi' package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot. And running grub-install manually gives me this: http://pastie.org/6430135 is that an installer related problem and should I commit a detailed bug report or is this just related to my hardware (hardware changes since the last ubuntu installation: new ssd, therefore the reinstall)
<leex> no one any idea?
<DktrKranz> mitya57: I can't right now, if you don't mind asking me again tomorrow if I don't get it first.
<mitya57> DktrKranz: thanks a lot, will do :)
<OdyX> tkamppeter: can I quote your line in the bugreport or can you answer to the bugreport yourself ?
<jbicha> xnox: I guess we're going to have to reintroduce goffice-0.8 since gnucash is GTK2 only?
<cjwatson> leex: full bug report, please, with the installer logs (/var/log/syslog, /var/log/partman)
<cjwatson> leex: not so interested in your attempt to run grub-install manually since that's not what's failing
<cjwatson> (at least I don't think so)
<cjwatson> leex: but the error message suggests that you haven't partitioned correctly
<cjwatson> see https://www.gnu.org/software/grub/manual/grub.html#BIOS-installation
<leex> cjwatson: since 12.10 doesn't have an alternate installer anymore I just clicked on "next", not much to do wrong there + the harddrive is new. I will run it again and submit a bugreport with syslog + partman logs
<tkamppeter> OdyX, please feel free to quote my line.
<cjwatson> leex: I'm prepared to believe it's a bug in our partitioner in some edge case, certainly
<leex> cjwatson: I am just running the installer again. I will do nothing fancy and just click next ;) and then post the results here later and if it's not my fault I will create a bug report
<pranith> Hi, can someone help nominate the patch in bug 1081307 for SRU?
<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
<tkamppeter> OdyX, still there?
<OdyX> tkamppeter: yeah :)
<tkamppeter> OdyX, WDYT about discontinuing beh upstream?
<tkamppeter> OdyX, nearly no one is actually using it
<tkamppeter> OdyX, GUI frontends do not support it
<tkamppeter> OdyX, current CUPS has better error handling than the one of the time when I created beh
<tkamppeter> OdyX, half of the original backends have to run as root and therefore are 750 root.root. For beh to support them, beh has to be 750 root.root by itself, making the non-root backends also run as root.
<OdyX> tkamppeter: I have no definite opinion. Marco (and jasmine upstream) might though. The only problem I see is upgradeability.
<tkamppeter> OdyX, what do you mean with upgradeability?
<tkamppeter> OdyX, the only way to make beh working again is to let it be 750 rott.root and let it check the permissions of the child and depending on the child's permissions run it as root or as lp, but this can make the simple script much more complex.
<OdyX> tkamppeter: how do we ensure that people with actually setup beh backends get a sane behaviour after the upgrade that removes beh
<tkamppeter> OdyX, that would be a problem, when removing it from foomatic-filters, queues using it will not work any more.
<leex> cjwatson: I installed debian and now reinstalled ubuntu successfully, don't ask me what happened there... I wasn't able to install it before the debian install consistently, well good for me, but bad for bug hunting :/
<OdyX> tkamppeter: well, unless there's a backend towards which we can auto-migrate the queues, with a similarly good behavious
<tkamppeter> OdyX, one must check whether CUPS' error policy setting covers the functionality of beh, if not probably improvinmg beh as I described would be the better solution.
<jamescarr> hi guysâ¦ I'm having a hell of a time with an issue I'm investigating today. Apparently mysql_config as part of libmysqlclient-dev no longer reports ssl?
<jamescarr> is there a way to view the commit history to see when this change occured?
<jamescarr> I'm just going to manage mysql_config via puppet and add -lcrypto and -lssl back
<cjwatson> leex: ah well, perhaps somebody else will run across it :)
<jamescarr> SpamapS: so like I said, I noticed -lssl and -lcypto got removed?
<jamescarr> from mysql_config in libmysqlclient-dev
<jamescarr> for now we have our puppet manifests add it back in after installation
<jamescarr> seems that mysql-python depends on this to compile in ssl support :(
<SpamapS> jamescarr: thats because the openssl license and gpl are not compatible
<SpamapS> jamescarr: so you are violating at least one if not both of those licenses
<jamescarr> really?
<jamescarr> oh man
<SpamapS> jamescarr: the embedded yassl bits should still allow it to work though
<jamescarr> embedded yassl its?
<jamescarr> *bits I mean
<jamescarr> SpamapS:  should mysql_config --libs or --libs_r reflect yassl?
<SpamapS> jamescarr: no, it is embedded
<SpamapS> jamescarr: you can test it by trying to use ssl :)
<jamescarr> yeah I noticed it connects
<jamescarr> the problem is with mysql-python then :)
<jamescarr> because it decides whether or not ssl is supported by checking mysql_config --libs
<xnox> jbicha: infinity: cjwatson: RE:  goffice-0.8 does need introducing for the sake of gnucash still being gtk2 only app. Last time I raised it, and it seems to still be the case, where debian does not have a separate goffice-0.8 source package, it is simply that both 0.10 and 0.8 versions are around in sid.
<jamescarr> weird. So if the openssl license isn't compatible with the GPL, shouldn't it be renamed to closedssl
<geofft> that's why it's not named freessl! ... In seriousness, that's ~why gnutls exists
<SpamapS> jamescarr: ah, thats a bug in mysql-python then (and really silly btw)
<jamescarr> yeah!
<celso> Hi people! I would like to ask you, for a newbie guy in the software world, what language and software should i use to make an aplication for ubuntu? (please notice that i have almost no experience on programing). Btw, i need a solution that is compatible with the new Qt option that ubuntu decided a few days.
<ScottK> Then use Qt.
<SpamapS> jamescarr: which python-mysql do you mean btw?
<SpamapS> jamescarr: python-mysqld ?
<jamescarr> 1.2.3 and 1.2.4
<jamescarr> no, the pypi package
<SpamapS> python-mysqldb rather
<jamescarr> yep
<jamescarr> thats it
<SpamapS> well pypi would be MySQLdb
<jamescarr> yeah I'm totally confused!
<celso> ScottK: but its easy to learn?
<ScottK> celso: I don't know.  I haven't learned it.  There are, however, many books, online tutorials, etc, so I would imagine so.
<jamescarr> ScottK: what's that?
<celso> ScottK: well, there is only one way to know it. thanks for the help! i am going to try it. thanks!
<jamescarr> I missed your earlier comment
<ScottK> jamescarr: He was asking about learning Qt/QML.
<SpamapS> celso: there's a nice side benefit to using Qt/QML which is that the app should be portable to many other platforms
<celso> Ah, i was going to ask that! lol by the way, i have read about Qt but Qml, is it the same?
<SpamapS> jamescarr: yeah looking at the code, there's a huge mistake there which is assuming the openssl method is the only one
<jamescarr> yeah, scanned it on github too
<SpamapS> jamescarr: https://github.com/farcepest/moist .. perhaps this one is smarter
<SpamapS> terrible name
<celso> I am asking that because i have Qt creator but dont know what is QML
<jamescarr> the fear with that one is two things: it hasn't been updated recently and I don't think it is compatible with SQLAlchemy
<SpamapS> yeah
<jamescarr> "moist is not yet ready for prime-time"
<jamescarr> yeah, I'll file an issue on the project
<jamescarr> this actually broke our production setup :)
<celso> ah i know what it is. QML is C++ components integration on Qt framework.
<celso> SpamapS: thanks for the help!
<SpamapS> jamescarr: I don't see at all where it looks for ssl in the libs
<SpamapS> #if MYSQL_VERSION_ID >= 50500
<SpamapS> #define HAVE_OPENSSL 1
<SpamapS> #endif
<SpamapS> jamescarr: ?
<jamescarr> SpamapS: I am at a loss for words. That seems like it should pick it up
<jamescarr> Hmph
<SpamapS> jamescarr: why, pray tell, aren't you using the distro package?
<jamescarr> virtual environments
<jamescarr> this doesn't matter for the virtual env though
<jamescarr> so in other words, I should prefer the distro package
<jamescarr> and remove the pip installation
<jamescarr> FFS
<SpamapS> --system-site-packages ?
<SpamapS> jamescarr: well I tend to think unless you need 2 versions of something... the distro package (especially for C extensions) are going to be less problematic.
<jamescarr> yeah
<jamescarr> yeah
<jamescarr> in this situation, we don't need 2 versions of mysqldb
<SpamapS> jamescarr: although I really am surprised that the pip install doesn't DTRT
 * SpamapS looks at the package build for clues
<SpamapS> export mysqloptlibs=ssl crypto
<SpamapS> jamescarr: maybe try that?
<SpamapS> probably easier than rebuilding everything :)
 * SpamapS heads out to do Sunny Saturday things
<jamescarr> SpamapS: thanks for the help
<Siekacz> hello
<Siekacz> any Mir devs here?
<sladen> Siekacz: try Monday-Friday daytime UTC
<Siekacz> right, weekend
<ScottK> Siekacz: Also this channel is for development of Ubuntu the distribution, so it's not really the ideal channel.
<reasz5> http://twixzo.de/spiel.php?id=22248
<xnox> Siekacz: #ubuntu-mir is what you want =)
#ubuntu-devel 2013-03-10
<tigrang> Is there a way to get hover and mouse click event on dbusmenu_menuitem?
<micahg> jamespage: is there any hope with Java 7 and packages that use the sun image libraries?
<Whoopie> debfx: Hi, running ubuntu raring in virtualbox, I get the following message with "LIBGL_DEBUG=verbose glxinfo": "libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so: undefined symbol: XCompositeQueryExtension)"
<Whoopie> debfx: does it influence the 3d part?
<smartboyhw> Any patch pilots?
<mitya57> DktrKranz: Hi again, will you review ubuntu-packaging-guide? It's not urgent, but I'd like to know if we should do a separate upload to Ubuntu or if we'll be able to sync it...
<DktrKranz> mitya57: sync time, it's been just ACCEPTED :)
<mitya57> DktrKranz: yay, thanks again!
<debfx> Whoopie: probably. I think I have a fix for that.
<c_korn> hello, although there is hardening enabled in my debian/rules file (compat 9) lintian still gives the warning "W: libcxx-gtk-utils-2-2.0-0: hardening-no-fortify-functions usr/lib/libcxx-gtk-utils-2-2.0.so.0.2.1"  http://0bin.net/paste/ef491bada67a2b7f6595695322aa696a6de67c35#aIvncN5nMQRYT4bsyjIrR8XOxrYmcDYV+aH5apTdlbI=
<jtaylor> c_korn: that check has many false positives, check that the flags are correctly passed to gcc (via bhlc) and override or ignore it
<c_korn> interesting idea to check the build flags in the log file. seems I have to make it verbose first: http://0bin.net/paste/a4c538a4d6a76c825dcb97bb0f748d6d9e193a2a#v4sWp0kMj2hQkvPIkGKVog7Wm4zalpHISKIsgopVYos=
<jtaylor> always make package builds verbose
<c_korn> ok, now blhc outputs nothing
<c_korn> hum, but even when I comment out the hardening lines in debian/rules blhc does not output anything
<jtaylor> how does a compilation line look like then?
<c_korn> ah, ok. "blhc --all" reports lines when I comment out the hardening in debian/rules. "blhc --all" outputs nothing when I uncomment it again. thanks, jtaylor.
<c_korn> so I think it is save to write a lintian override
<Whoopie> debfx: nice
<Whoopie> debfx: btw, is it okay that glxinfo shows llvmpipe instead of chromium with vbox 4.2.8? previous versions showed chromium.
<debfx> Whoopie: the other problem is: the kernel module is loaded too late (after the X server started)
<debfx> no, it should say chromium
<Whoopie> debfx: ah, as a workaround, could I put vboxvideo into /etc/modules to fix it?
<debfx> yeah that should work
<Whoopie> ok
<Whoopie> debfx: fyi, I backported your 4.2.8 package to precise and glxinfo also shows llvmpipe.
<Whoopie> debfx: even though /var/log/Xorg.0.log shows that vboxvideo is loaded by X.
<debfx> Whoopie: you're talking about the backported X stack, right?
<Whoopie> debfx: no, it's still the old X stack which came with precise.
<debfx> the X Server 1.11 auto-loads vboxvideo so missing the kernel module can't be the problem there
<Whoopie> debfx: right
<cjwatson> bdmurray,ev: I have a crash that I'm still experiencing frequently that was marked Invalid in the middle of last year due to an alleged lack of continuing reports.  I'd like to try to find out whether there are more reports of it on errors.  Is there a way to figure out the bucket for a given Launchpad bug number so that I can refer to that, or failing that to get a list of all the reports for a given package rather than ...
<cjwatson> ... just the top 100?
<xnox> hmm... there was a magic errors url for reverse lookup.
<smartboyhw> xnox, are you operational on Sundays?
<bdmurray> cjwatson: https://errors.ubuntu.com/api/1.0/most-common-problems/?format=json&package=apport&limit=250
<bdmurray> you can adjust limit there
<bdmurray> and I thought I had some code to find the bucket from an apport report
<bdmurray> I'm not finding it right away but will look around later today or Monday
<xnox> cjwatson: or if you submit that crash, you can open firefox 'http://errors.ubuntu.com/user/'$(printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum) find your crash which should get you to the bucket....
<debfx> hm how do I change the runlevels of an init script in postinst? update-rc.d remove before adding the symlinks again?
 * penguin42 wonders if all ASRock motherboards have the UUID 03000200-0400-0500-0006-000700080009  like mine
<xnox> penguin42: hm. we are product_uuid buddies! \o/ 03000200-0400-0500-0006-000700080009
<penguin42> :-)
<xnox> penguin42: basically errors.u.c times out and crashes when I try to view it since probably us two are not the only onces with that product_uuid.
<xnox> penguin42: is your computer "microsoft windows certified" machine?
<penguin42> xnox: Mine the manufacturer, product name, version, serial number, sku number and family are all 'To Be Filled By O.E.M.'
<xnox> penguin42: same here.
<penguin42> xnox: It's an ASRock P55M Pro
<xnox> I'm using Latvian PC manufacturer Gauja, so I guess a few OEM can't be bothered to change those values, extra work for no gain.
<penguin42> xnox: Yeh, I just bought the board and built the machine
<xnox> ev: ^^^^ we have a clash,  03000200-0400-0500-0006-000700080009 should be blacklisted product_uuid, as that is a placeholder.
<penguin42> xnox: any reason you don't use an install time generated UUID instead?
<xnox> penguin42: good point. the other alternative was to use MAC address.
<penguin42> yeh, MAC isn't bad as long as you're consistent about which one you use on a machine with multiple cards
<ogra_> xnox, does that mean you got it booting now ?
<xnox> ogra_: =( still using my laptop.
<ogra_> ah :(
<xnox> ogra_: it's my laptop which is latvian, my new pc is of a mixed origin.
<ogra_> yeah, i saw the pics :)
<xnox> ogra_: so far i have recommendations that it's either dodgy power supply or dodgy memory.
<ogra_> i would bet on the latter
<xnox> ogra_: i am pondering to test with http://www.ebay.co.uk/itm/2GB-2x1GB-Hynix-240-pin-PC3-10600-DDR3-SDRAM-DIMM-Desktop-Memory-Dell-Supplied-/140925738374?_trksid=p5197.m1992&_trkparms=aid%3D111000%26algo%3DREC.CURRENT%26ao%3D1%26asc%3D14%26meid%3D6147530541338586150%26pid%3D100015%26prg%3D1006%26rk%3D1%26sd%3D140925738374%26
<Joshun> hi
<Joshun> anyone know how to get this to compile in ubuntu 12.10:
<Joshun> https://developer.gnome.org/gnome-devel-demos/unstable/button.c.html.en
<Joshun> I have libgtk-3-dev installed
<Joshun> is it just not new enough?
<Joshun> is gtk3 just a bad choice or something
<cjwatson> bdmurray: hm, I can't find it there, and xnox's link returns a mostly-blank page with just the header and footer.  Can you find a bucket for bug 905582 or else figure out why it isn't getting reported?
<ubottu> Error: Launchpad bug 905582 could not be found
<cjwatson> (it's private)
<cjwatson> I guess it could be bug 888036 instead, but I'm not sure why apport redirected me to 905582 then
<ubottu> bug 888036 in compiz-plugins-main (Ubuntu) "compiz crashed with SIGFPE in StaticSwitchScreen::getWindowPosition()" [High,Confirmed] https://launchpad.net/bugs/888036
#ubuntu-devel 2014-03-03
<infinity> @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: infinity
<infinity> Does anybody else have update-notifier whining about ubuntu-emulator-runtime?
<infinity> @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:
<xnox> good morning! =)
<hyperair> it's 3pm here. ;-)
<hyperair> morning anyway. :)
<xnox> hyperair: there i was thinking, i'm up early ;-)
<hyperair> ;-)
<Snow-Man> 3am here, so...
<hyperair> wow, up even earlier!
<Snow-Man> :)
<Unit193> Nah, 3am is late, not early. ;)
<Snow-Man> 3am might be 'passed out early due to excessive drinking, back up now and hacking on Postgres'... :D
<Snow-Man> and wondering if we're really going to get all this snow that's forecasted
<Unit193> We're not, most of it is going to bypass. :(
<Snow-Man> The claim is 4-6" here, but it's all rain right now.
 * Snow-Man is up near DC
<Unit193> Already got some, driving would be fun.
<Snow-Man> hmm, looks like it's just started to snow now
<mapreri> Can someone sync how-can-i-help?
<Noskcaj> mapreri, File a sync bug?
<mapreri> Noskcaj: ok
<cjwatson> mapreri: done
<mapreri> cjwatson: thanks, I was going to file the sync bug.
<mlankhorst> why was egl and gbm disabled on ppc64el and arm64? works just fine
<Laney> I mailed u-d-a if someone could moderate it
<cjwatson> Laney: done
<Laney> ta
<xnox> ogra_: you have my diffs, sort your bugs yourself.
<xnox> ogra_: it should be a good starting point, i'll work on something where my work is not revert for no good reason.
<ogra_> xnox, thats the rule, i dont make the rules
<ogra_> xnox, and i dont have a working diff for enable-modem
<xnox> ogra_: well, that revert introduces a regression.
<ogra_> how so ?
<ogra_> xnox, the breakage was introduced with this change to the image: http://people.canonical.com/~ogra/touch-image-stats/20140301.1.changes
<ogra_> there was nothing else changed but ofono
<ogra_> if that introduces a regression then i dont get how
<xnox> ogra_: because ofono-scripts are reverted to python2.
<ogra_> xnox, yes
<xnox> ogra_: and the bugs and crashes are not related to python3 switch.
<ogra_> but they dont produce crashes anymore
<xnox> ogra_: use that old package now, with python3 scripts.
<xnox> ogra_: so, i should go and dput back the switch to python3 for the scripts?
<ogra_> since the landing team isnt upstream, how are they supposed to know ...
<xnox> ogra_: do you understand what I'm getting at?
<ogra_> they can only roll back the whole landing
<xnox> ogra_: no, but you've asked me to work on it, to presumably avoid the pointless revert.
<ogra_> if you can verify that it doesnt cause the issues, sure
<xnox> ogra_: (that's how i understodd it)
<ogra_> right
<xnox> ogra_: isntead revert has happened anyway.
<ogra_> i didnt know that didrocks did such a quick shot here
<xnox> ogra_: and i've spent my time, now, pointlessly.
<xnox> ogra_: and it's now further blocking mine and barry's work on python3.
<ogra_> since we didnt plan to build an image that soon
<ogra_> xnox, revert the revert (or ask didrocks to do it) and apply your fixes ...
<xnox> ogra_: can you please take that old package, replace /usr/share/ofono/scripts with python3 versions.
<xnox> ogra_: and check if you get the crashes?
<xnox> (you'll need python3-gi if it's not installed)
<ogra_> so keeping ofono-scripts installed and only reverting the ofono package ?
<ogra_> lets see if dpkg allows
<xnox> no, dpkg will not =)
<xnox> so stash / copy override / unpack python3 ofono-scripts on top.
<ogra_>  ofono-scripts depends on ofono (>= 1.12+bzr6856-0ubuntu1); however:
<ogra_>   Version of ofono on system is 1.12+bzr6853-0ubuntu1.
<ogra_> hmm
 * ogra_ forces
<ogra_> and rebooting ...
<ogra_> root@ubuntu-phablet:/# ls /var/crash/
<ogra_> _usr_share_ofono_scripts_enable-modem.0.crash
<ogra_> xnox, ^^^
<ogra_> with old ofono and new (py3) ofono-scripts
<xnox> $ cat /var/crash/_usr_share_ofono_scripts_enable-modem.0.crash
<ogra_>  dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
<xnox> ogra_: at least paste the traceback from the bottom of it....
<ogra_> same issue as always
<xnox> ogra_: great! =) your revert will do you no good ;-)!
<ogra_> xnox, didrocks reverted to the plast ofono source package
<xnox> ogra_: what did you force and what do you have installed?
<ogra_> which will pull the py2 scripts back in
<xnox> ogra_: cause ofono/ofono-scripts have a hard-dep version numbers....
<ogra_> i had the old ofono (pre py2) and the new -scripts (with py3) installed together
<ogra_> there is a versioned dep between them
<ogra_> right
<xnox> i need to look at diffs of what didrocks uploaded.
<ogra_> he just rolled back to the old deb source package
<ogra_> with a bumped changelog
<xnox> ogra_: can you give me ssh to flo's adb?
<ogra_> xnox, not without ripping my firewall apart completely ... probably psivaa can
<ogra_> psivaa, ^^
<ogra_> xnox, but that should all be reproducable on any device ... even on grouper
<xnox> ogra_: right, i'll see about reproducing this on grouper.
<ogra_> flo is just a better grouper :P
<ogra_> (well, completely different HW ... but still :) )
<psivaa> xnox: do you still need access to the device in the lab? I need to check that with ev and retoaded before giving access though
<ev> psivaa: we can give access to a device so long as it's temporary and you take it out of play for the CI engine
<xnox> psivaa: i'll let you know if i need access.
<psivaa> xnox: ev: ack, thanks
<xnox> didrocks: are you going to update https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog with ofono revert upload?
<Laney> xnox: I'm uploading that splitty split split now
<xnox> Laney: \o/ =) !
<Laney> Packages++
<xnox> Laney: btw, that last split, i've read as "spliff" and i was like hang on a minute!
<Laney> got to celebrate somehow ...
<Laney> actually, by going to the cafe down the road and doing the crossword :P
<Laney> #thuglyf
<xnox> =)))))
<didrocks> xnox: sure, when I get the time to do it
<didrocks> ogra_: we talked in the morning meeting about itâ¦ that I would revert
<xnox> didrocks: is it ok with you, if i upload revert of your revert, which also fixes the observed crashes?
<xnox> didrocks: did you talk to people who prepared that upload of ofono?
<ogra_> didrocks, right, i just didnt expect you to be that fast
<didrocks> xnox: watch the phone ML
<ogra_> since there was no urge to do it quickly
<didrocks> xnox: this was discussed here
<didrocks> xnox: ok to upload revert of the revert if you did tests the autopilot tests with the onofo-phonesim
<xnox> didrocks: ok. thanks.
<xnox> didrocks: on mailing list, i see ricardo acknowledging the issue and hoping to work on fixing it today. Which was mailed 4h ago.
<didrocks> xnox: right, but we need to get back to a better image sooner
<didrocks> xnox: as we're going to kick one now
<didrocks> and getting the testing results by the evening meeting
<xnox> didrocks: define "better" =) an image which pulls back in python2 and python2-gobject is, in my opinion, not better but one that regresses =)
<didrocks> xnox: better == less crashers
<didrocks> so yeah, python2 vs crashers
<didrocks> I take python2, sorry
<xnox> didrocks: turn off whoopsie, if you count crashes =)))) *giggles*
<xnox> didrocks: plus the crash was not of any process that is shipped on the image.
<didrocks> xnox: sure, sending the patch and announcing that to ubuntu-devel?
<xnox> didrocks: the crash was in external package, which is installed for testing only.
<didrocks> xnox: yep
<xnox> didrocks: you still count that towards good/bad image? strange.
<didrocks> xnox: I do, developers are running the AP tests
<didrocks> seeing the crash
<ogra_> xnox, didrocks only thinks in AP tests :)
<xnox> didrocks: ok.
<didrocks> and discare their own failure because "it's due to the crash"
<didrocks> ogra_: I do care of an image we can promote, not only AP tests, but dogfooding as well
<xnox> didrocks: well, tell them not to do that =) attribute random things to random crap.
<ogra_> didrocks, right
<shadeslayer> jibel: https://jenkins.qa.ubuntu.com/job/upgrade-kubuntu-precise-trusty-desktop-backports-amd64/7/console < is that just a temporary failiure in the LXC backend?
<jibel> shadeslayer, yes it is. post-upgrade tests started before the container is running. It is fixed.
<shadeslayer> ah ok
<shadeslayer> jibel: are the results posted on some mailing list I can follow? instead of checking that page everyday?
<roadmr> hello! I have a problem with apt-get. Package A lives in a private PPA, and depends on package B which lives on another private PPA. apt-get install A says "Depends: B but it is not going to be installed". However, apt-get install B succeeds; further, apt-get install AB *also* succeds. What could be happening?
<roadmr> er, apt-get install A B
<seb128> mardy, hey, is there any reason to not just land u-s-s and -online-accounts synced in a CI train silo  and be done with that v2 plugin thing?
<jibel> shadeslayer, there is an ubuntu-testing-notifications ML, but it is sometimes pretty high volumes, otherwise I can subscribe you to kubuntu upgrade tests only.
<shadeslayer> jibel: yeah would be nice
<shadeslayer> maybe Riddell / apachelogger too ^^
<mardy> seb128: AFAIK, you can't have the same project in different silos
<mardy> seb128: ATM, online-accounts is on silo 5, and there are more changes I plan to land soon
<mardy> seb128: I wouldn't like to be blocked because of this
<seb128> mardy, indeed not, I see you already have landing prepared in silo5, but once that's cleared we could do one synced with u-s-s for the reset?
<Laney> I did the change now already
<seb128> k
<seb128> let's stop arguing about that then and just land the damn thing :p
<seb128> (well after the ringtone)
<Laney> where's the lander list again?
<Laney> boiko is away today, want to check who does telephony
<seb128> Laney, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
<seb128> bfiller
<Laney> ty
<Laney> bfiller: We'd like to get https://code.launchpad.net/~laney/telephony-service/accountsservice/+merge/201630 in, any objections to training it?
<bfiller> Laney: no objections, as long as it's tested and works
<Laney> bfiller: Ya, and it'll get re-tested in the silo
<Laney> thanks
<cjwatson> jdstrand,sbeattie: Do you know why python3-apparmor-click depends on python3-click?  It doesn't seem to actually use anything from it.
<cjwatson> (Which makes it a non-issue for the work I'm doing at the moment, but I wanted to check as some of the API in python3-click is going away)
<cjwatson> (Or rather being moved elsewhere)
<jdstrand> cjwatson: interesting-- no we don't seem to do any imports from python3-click
<jdstrand> cjwatson: probably a holdover from earlier code iterations
<jdstrand> I've added a todo to test and drop that in the next upload
<cjwatson> jdstrand: Thanks
<dobey> anyone else using evolution having it consistently crash on startup today too?
<seb128> dobey, no, bt?
<dobey> seb128: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1287250
<ubottu> Error: launchpad bug 1287250 not found
<seb128> dobey, can you subscribe me to it?
<dobey> seb128: done
<seb128> dobey, weird, that's a segfault in gsettings, that didn't change recently (neither glib nor dconf)
<dobey> yeah, weird, but now i can't read my e-mail. evo is crashing on every startup :(
<seb128> dobey, weird, maybe ping desrt on #ubuntu-desktop about it. Is the segfault always in gsettings?
<ara> seb128, remember the gnome-settings-daemon upload that fixed https://bugs.launchpad.net/oem-priority/+bug/408903
<ubottu> Launchpad bug 408903 in udev (Ubuntu Raring) "Does not handle microphone mute button (KEY_MICMUTE)" [Medium,Triaged]
<ara> seb128, and it may have caused this regression: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1248368
<ubottu> Launchpad bug 1248368 in gnome-settings-daemon (Ubuntu) "Volume up/down keyboard keys stoped working after gnome-settings-daemon package update" [High,New]
<seb128> ara, yes, I saw your email as well, the recent weeks just have been crazy with ff
<ara> the regression only affects 1 person,and we are not able to reproduce
<dobey> hmm, weird
<dobey> i started in calendar and it worked ok
<ara> yes, I can imagine, but I was talking to bdmurray and he wanted your opinion :)
<dobey> but was crashing all the time in the default view of mail (i don't really use calendar or other things much)
<dobey> and now it starts ok again :(
<ara> if you are unsure, that's fine, but we will need to prepare another gnome-settings-daemon upload without those changes to fix the other issue in the queue
<ara> I am fine either way
<seb128> ara, hum, who tested the SRU?
<ara> seb128, the original or the potential regression?
<seb128> ara, sorry, I got slightly confused by comment #7 on the regression bug
<seb128> which was stating that the versions are the same before/after dist-upgrade
<seb128> ara, I've a test machine next to me, let me put 12.04.
<seb128> 4 on an usb stick and test that
<ara> seb128, thanks
<seb128> ara, yw
<alow> infinity: hi it's me the node.js/v8 guy on powerpc again. I've just done another cleanup sweep of the code - what's the best way to push these changes into http://packages.ubuntu.com/source/trusty/libv8-3.14?
<psusi> in order to get a package synced from debian at this point, doesn't it need subscribed to ubuntu-archive?  bug #1286027 was subscrubed to the release team but they switched it to sponsors since it's only a bug fix so no FFE is needed...
<ubottu> bug 1286027 in gparted (Ubuntu) "Please sync latest GParted 0.18.0 from Debian unstable (only bugfixes and updated translations)" [Undecided,New] https://launchpad.net/bugs/1286027
<psusi> shouldn't that be archive not sponsors?
<cjwatson> No, no reason archive has to be subscribed to sync bugs.
<cjwatson> Syncs became self-service for uploaders a couple of years ago.
<psusi> ohh, I thought sync requests normally were subscribed to archive
<cjwatson> They were ... years ago
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
<psusi> hrm... so I guess I finally need to get my app in for full devel and then I could do it myself?
<cjwatson> Indeed
<psusi> neat
<cjwatson> Or indeed a per-package permission for that package.
<psusi> that reminds me... what's a guy got to do to get upload access to parted in debian? ;)
<psusi> I'm feeling pretty comfortable at this point so it's probably time to just apply for full devel
<cjwatson> There's the DM process
<psusi> yea, I'm a dm... what I meant was that the maintainer of the package is listed as a team rather than an individual... and it's maintained in git... so not only do I need someone to dak me up, but I need git access too
<cjwatson> ok, maybe ask me later this week, trying to finish off https://code.launchpad.net/~cjwatson/click/libclick/+merge/209105 right now
<psusi> ok... I'm hoping to get a new upstream parted released next week and get it into debian as soon as those partman pateches I submitted are applied
<cjwatson> I wouldn't mind converting Debian parted to git-dpm to go with just about everything else I have a hand in maintaining these days, too
<psusi> ohh, I thought it already was
<cjwatson> It'd probably make sense to do that before the new upstream
<cjwatson> Nah, I think it just has patches sitting unapplied in git
<cjwatson> (before> because that way you can use git to resolve the patch queue rather than having to do it in quilt)
<psusi> hrm... reading up more on this now
<cjwatson> http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html is a summary
<cjwatson> Also https://lists.debian.org/debian-ssh/2014/02/msg00007.html
<psusi> this might be handy for util-linux too when lamont finally gets around to uploading it and making me the maintainer ( poke poke ;)
<cjwatson> I absolutely love it, if it isn't clear :)
<psusi> hehe, I gather that... now just trying to understand how it works ;)
<cjwatson> It does have a bit of the git thing where its documentation consists of commit graphs, so it took me a while
<psusi> I had been trying to come up with a sane way of managing patches in git after seeing the util-linux git repo, but gave up
<psusi> and just went back to plain old 3.0 quilt source packages
<cjwatson> Yeah, nothing previously had sold me on it as being worth bothering
<cjwatson> The key is the non-pushed pseudo-fast-forwarding branch, where you have a rebasing branch consisting of upstream + all your patches in sequence, and you merge it onto your master or equivalent any time you change it, so you get to rebase *and* keep the history
<cjwatson> And then various bits of gold-plating so that you don't have to have that branch explicitly around all the time and getting in the way
<psusi> I was thinking it would take something like a branch for upstream, and another for the debian stuff, or a submodule or something
<cjwatson> git-dpm indeed has a branch which consists only of upstream + patches and doesn't have the rest of the packaging, in order that you can cherry-pick between upstream and the patched branch
<cjwatson> But you only check that out when you're working on it (via "git-dpm checkout-patches"), otherwise it's round-tripped to files in debian/patches/
<psusi> how do you keep the debian/changelog and debian/patches/ in sync with that then?
<psusi> if they aren't part of the same commit?
<cjwatson> They're part of the merge
<cjwatson> So git-dpm update-patches merges the rebasing tip, and updates debian/patches/ at the same time
<psusi> one branch for upstream changes, one branch with a paralell set of commits that update the changelog, and a 3 way merge?
<cjwatson> If you want to update debian/changelog too then you can use git-dpm dch which wraps it up for you, or you can edit it afterwards and use git commit --amend
<cjwatson> I'm not sure "parallel" is the right way to look at it
<cjwatson> You could check out say git://anonscm.debian.org/pkg-ssh/openssh.git and look at it with gitk
<psusi> ohh, I see, the debian/patches isn't in git, it is auto generated by the wrapper tool from the git commits?
<cjwatson> The wrapper checks it into git so that when you do a checkout you get something that looks just like the generated source package
<cjwatson> But you indeed don't modify those files manually
<cjwatson> They're the output of git format-patch basically, with support for tweaking the file names
<psusi> I see... so the change log entry is a verbatim copy of the git commit message, and the DEP-3 headers are... auto generated too?
<cjwatson> You put them in your commit message
<cjwatson> So if you're cherry-picking you generally need to amend the commit message, but that's no great problem
<psusi> hrm.... nifty
<lamont> cjwatson: did you see anything about how grub hates my disk and grub-prober exits(1) because of "unknown filesystem"?
<cjwatson> nope ...
<lamont> if not, I'll dig into it
<cjwatson> (also being increasingly insistent called for dinner)
<cjwatson> *insistently
<psusi> by jove, it sounds like this really *is* the best of both worlds
<lamont> psusi: is this git-dpm the package, or what package? (before I read lots of scrollback)
<psusi> lamont: yes.. cjwatson was telling me about git-dpm
<lamont> ta
 * lamont adds that to his "after util-linux" tasklist
 * psusi is getting excited about git-dpm but is worried he's going to be a wonk and do all the manipulation by hand isntead of using git-dpm
<slangasek> the obvious way to guard against this would be to commit yourself to providing workflow documentation for git-dpm on wiki.debian.org as you go <hint ;)>
<psusi> lol
<tarpman> good morning. can anyone suggest the best way to move forward with bug 937200? should I propose a merge for trusty, forward the patch to debian bts, ping doko personally, ??
<ubottu> bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Triaged] https://launchpad.net/bugs/937200
<tarpman> ... "wait a bit longer" is also valid, I'm sure people are busy :)
<psusi> the more I stare at this commit graph the more I love it
<psusi> hrm... does it only work with upstream tarballs though, or can you directly *merge* from upstream?
<psusi> i.e. upstream git repo, not upstream tarball that has been imported
<Noskcaj> seb128, ping
<Noskcaj> The u-c-c and u-s-d merges i put up are so there can be a gnome-desktop FFe.
<Logan_> hi Noskcaj
<Noskcaj> hey Logan_
<alow> hey infinity are you around?
<seb128> Noskcaj, hey, you could have written that in the description ;-)
<Noskcaj> seb128, sorry, i was unsure how well versed you where in the current status of ubuntu-gnome
<seb128> Noskcaj, not at all, though I know about gnome-desktop update being something they want
<seb128> Noskcaj, -1 from me on that ffe, but I'm not one to device on ffes, so let's see what the release team says
<Noskcaj> ok
<seb128> device->decide (doh, autofingers)
<Noskcaj> seb128, one other thing, would it be worth merging all of miniupnpc 1.6-3 this later in the cycle? bug 1264664
<ubottu> bug 1264664 in miniupnpc (Ubuntu) "Enable building python-miniupnpc as in Debian Sid" [Undecided,Triaged] https://launchpad.net/bugs/1264664
<seb128> Noskcaj, no opinion on that, out of that it should get a ffe (e.g subscribe ubuntu-release, etc)
<cjwatson> psusi: you can directly merge from upstream, though what you generally do in practice is "git-dpm import-tar" which tacks a commit onto the upstream release point corresponding to any differences between git and the tarball
<cjwatson> if upstream is "close enough" then you might get away with it, though I think I'm coming to the view that that's a false optimisation
<cjwatson> slangasek: you mean like https://wiki.debian.org/PackagingWithGit/GitDpm ? :-)
<cjwatson> Though it definitely needs more
<cjwatson> Like dealing with new upstreams
<stokachu> barry: https://github.com/cask/cask
<barry> stokachu: ah, nice.  anything that helps emacsers out is a winner in my book
<stokachu> barry: thought you'd like that :)
<slangasek> cjwatson: right, something like that :-)  so it mentions two options for getting started, "import .dsc files" or "start from scratch" - is there any howto for "take existing package VCS and convert it over"?
 * lamont looks around for someone with a machine/vm/whatever running trusty with root on an LV on a VG that still has space for another LV to test something for him
<lamont> cjwatson: ^^ it seems that grub-probe hates lvm snapshots, fwiw
<lamont> still working towards verifying that
<cjwatson> lamont: damnit, I'm sure we've fixed that at least once before
 * lamont runs off for a few while rsync churns
<cjwatson> slangasek: not that the wiki shouldn't be extended, but the man page is actually pretty good
<lamont> cjwatson: that would be a grave bug, imo
<cjwatson> lamont: probably :-/
<lamont> mostly since I couldn;t even install the build-deps for grub2 because of grub-probe.
<cjwatson> slangasek: though the short answer is that "git-dpm init /path/to/upstream/tarball" (possibly with --patches-applied) does it
<cjwatson> of course for a VCS that isn't git it isn't really git-dpm's problem ... may I recommend http://www.catb.org/~esr/reposurgeon/
<slangasek> cjwatson: right, I'm assuming step 1) make sure your package repo is git, step 2) dpmify your existing source package regardless of which format it's currently using
<cjwatson> run on master, git-dpm init takes the existing tree, creates a sequence of commits starting from the "upstream" branch corresponding to each successive patch in debian/patches/, then merges the tip of that into your master branch in a commit that also (a) creates the debian/.git-dpm control file (b) changes all the files in debian/patches/ into git-dpm's canonical form, which basically looks like git format-patch output
<cjwatson> if you're me, you want to use --record-patch-name so that it doesn't change all the file names, and you end up doing "git-dpm checkout-patched; git rebase -i upstream; ...; git-dpm update-patches --amend" immediately afterwards to clean up all of the commit messages and such
<cjwatson> but that's just neatness
<slangasek> cool
<slangasek> how is git-dpm's support for non-git-format-patch-dep3 headers?
<cjwatson> it doesn't have any, you get to accept them turning into git format
<cjwatson> I thought for a while and decided I was OK with that as a trade-off
<cjwatson> given that the information is still there, just differently formatted
<slangasek> cjwatson: I'm ok with it changing the header, I just want it to import the existing one without me having to hand-check it
<slangasek> so s/Description/Subject/, e.g.
<cjwatson> oh, yeah, it imports well enough modulo whitespace occasionally being glitchy
<cjwatson> as in it doesn't outdent space-indented Description continuation blocks
<cjwatson> but that's fairly trivial, and I haven't encountered any information loss
<doko> cjwatson, ftbfs
#ubuntu-devel 2014-03-04
<cjwatson> doko: yes, already looking
<cjwatson> Ah, I think I want sitepackages=True in tox.ini
<lamont> cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1287436
<ubottu> Launchpad bug 1287436 in grub2 (Ubuntu) "grub-probe fails in the presence of snapshot logical volumes" [Undecided,New]
<cjwatson> lamont: could you also figure out the grub-probe command being run here ("sh -x /usr/sbin/grub-mkconfig >/dev/null" should help identify it), run it with -vv added to its arguments, and attach the output?
<lamont> sure
<lamont> cjwatson: I already had the command, just for debugging things
<lamont> cjwatson: done
<cjwatson> ta
<psusi> cjwatson, lamont, did the patch to ignore snapshot volumes get lost?
<lamont> psusi: I didn't bother to see if it was a regression or something new
<lamont> OTOH, I suspect that a test case could be written for this
 * lamont runs dpkg --configure -a
<lamont> File descriptor 3 (pipe:[754560]) leaked on vgs invocation. Parent PID 28874: /usr/sbin/grub-probe
 * lamont reremoves the volume, and does it again, after kicking himself
<cjwatson> psusi: seems unlikely as such, it was an upstream change
<psusi> lamont, last time I played with lvm snapshots a few years back, cjwatson patched grub to ignore snapshot volumes since at the time, I think it was trying to find a filesystem in the snapshot volume.
<cjwatson> unless my changelogs are misleading me, it was fixed upstream, not by me
<cjwatson> 5944958c61a4b8aa11162d01ea61462d02db7ac4
<lamont> well, frankly, I should be able to boot from the snapshot, but maybe that's just crazy talk
<psusi> ohh, I could have sworn you fixed it
<psusi> lol.. yea, it *would* be nice if grub actually understood the snapshots, but.. ;)
<cjwatson> that being said, that area of code *has* changed and no longer explicitly mentions snapshots
<psusi> if you plan on playing with lvm snapshots it is probably a good idea to use a /boot partition
<psusi> (outside of lvm, or at the least, one you never will snapshot )
<psusi> lvm snapshots are kina sucky though anyhow.. btrfs does it much nicer... I really need to play with that again
<cjwatson> wtf, bisect shows fc18f6a3cb15db980e65dda9e305a1d176b14b3a which seems to be an accidental bundling of lots of things into one commit
<cjwatson> ah, but followed by 70e75364fa8627e24bb5ed9eead391c778c4504e which was the changelog for that
<cjwatson> I'm not even sure we're going at this from the right angle - it's quite possible that it's supposed to have snapshot support now and is just having some localised trouble
 * cjwatson gives up for the night
<dholbach> good morning
<dholbach> dobey, do you think you can reply to https://twitter.com/publiclz/status/440421467038027776?
<mlankhorst> ogasawara: hah, I've beat you to https://launchpad.net/~ubuntu-x-swat/+archive/t-lts-backport :D
<didrocks> xnox: the version of ofono in the archive has your fix?
<xnox> didrocks: yes.
<didrocks> xnox: did you try with dialer-app AP tests as suggested?
<xnox> didrocks: they did pass in emulator yesterday, awe did same independantly, that's all before the upload.
<xnox> didrocks: let me try out the version from the archive in the emulator.
<didrocks> xnox: http://ci.ubuntu.com/smokeng/trusty/touch/mako/219:20140304:20140304/6967/dialer_app/
<didrocks> seems there is still a crash on ofono_scripts_dial-number
<ogra_> xnox, the dial-number script still produces a traceback
<xnox> didrocks: looks all good.
<ogra_> the test passes fine though
<didrocks> xnox: do you think the timeout is due to dialer-app crashing?
<didrocks> xnox: (we had this dialer-app crash for quite a while, but without the script issue)
<xnox> didrocks: ogra_: not sure where dial-number is used, it has 120 second timeout.... it'd consider tests to fail, whichever tried to dial a number.
<ogra_> xnox, it was there yesterday, i pointed you to it and you said it would be transient
<didrocks> yeah
<xnox> ogra_: i did not say it's would be transient. i said it's inconclusive, whilst we still have the other two / phonesim not strating reliably.
<ogra_> xnox, i think it just needs the same try/except dance seems to not influence the test
<xnox> ogra_: the call/traceback in dial-number has 120 second timeout.... i can dial numbers faster than that by hand =)
<xnox> didrocks: looking at the Autopilot tests, they appear to be wrong, as they don't check if dial-number succeeds:
<xnox> def invoke_incoming_call():
<xnox>     """Invoke an incoming call for test purpose."""
<xnox>     # magic number 199 will cause a callback from 1234567; dialing 199
<xnox>     # itself will fail, so quiesce the error
<xnox>     subprocess.call(['/usr/share/ofono/scripts/dial-number', '199'],
<xnox>                     stdout=subprocess.PIPE, stderr=subprocess.PIPE)
<didrocks> xnox: can you reach upstream with those infos?
<xnox> didrocks: sure, let me file a bug report.
<didrocks> xnox: ok, and pinging them at the same time, please :)
<xnox> didrocks: ogra_: well the test is written by pitti by the looks of things. let me try to figure out how it is suppose to work =)
<xnox> bug #1287628
<ubottu> bug 1287628 in ofono (Ubuntu) "invoke_incoming_call() doesn't seem to work, result is not checked, yet test_incoming test passes (?!)" [Undecided,New] https://launchpad.net/bugs/1287628
<ogra_> xnox, but thats for incoming
<ogra_> wouldnt involve dialing a number
<ogra_> oh
<ogra_> sorry ... i missed the top part :P
<ogra_> so it dials 199 to get a call back
<ogra_> and it explains why it is supposed to produce the traceback in the comment !
<ogra_> heh
<xnox> ogra_: a dbus method is executed to dial, and that should return something sensible back over dbus to exit the client.... =)
<xnox> ogra_: are magic numbers, magic in ofono or phonesim?
<ogra_> well but it states that an error is expected for dialling 199
<ogra_> xnox, i suspect the dial-number script simply cant properly return an error here which causes the traceback
<ogra_> (same apport issue as with the other scripts i guess)
<xnox> ogra_: no, not the same. ofono is actually returning an error "Operation failed", yet i'm not getting same result on a desktop.
<ogra_> well, the same as in "with py2 approt didnt react to it"
<ogra_> *apport
<ogra_> i'm sure that issue is there forever even with py2, it was just never catched in a .crash file before
<xnox> ogra_: how? it's unrelated to python at all, if dialing the number doesn't work over dbus (e.g. using d-feet and not using the python script at all)
<xnox> ogra_: on desktop, it's suppose to bring up a persistent pop-up.
<ogra_> xnox, could it be that pitti added a new apport hook or something when he ported ?
<xnox> ogra_: or at list get an incomming call listed with ./list-calls.
<ogra_> (during the py3 transition)
<xnox> ogra_: i'm on a slow internet today, downloading both images to compare.
<xnox> ogra_: things you are saying don't make sense. apport doesn't generate crashes / tracebacks, whoopsie does. And that did not change. With the other ofono, the dial-number script / dbus calls to request callback did work. It's strange that autopilot test is not catching it, but it already catches MissmatchError instead of like failing the test / marking it as skipped, thus test_incomming is not working properly at the moment.
<ogra_> what about this one https://github.com/martinpitt/ofono/commit/97ba8139abf0a42d8568fa1cc3ea7432cf639e03
<xnox> ogra_: what about it? do you know python at all? both syntaxes are equivalent.
<ogra_> xnox, the point is that there has not much changed in the scripts, before the port apport didnt produce a crash file, now it does
<xnox> sure, ofono itself has changed as well =)
<ogra_> as you noiticed yesterday that errors must have been there before as well ... for the ofono-phonesim-autostart package they are in the startup script by design
<xnox> ogra_: can you please stop guessing, and give me time to actually debug this.
<ogra_> i'm sure the same goes for the dial-number script
<ogra_> so something changed that makes apport pick the tracebacks up ... which it did not with the python2 version
<ogra_> (and yes, i know they are equivalent)
<xnox> ogra_: did you run dial-number in python2, and it does generate traceback on the whichever image which has either reverted stack or before upgrade?
<xnox> ogra_: i'm still downloading that image here.
<ogra_> not yet, i can doo that soon
<ogra_> (my maguro is dead, needs a bit of charge first, it has an old image)
 * ogra_ sighs, sill ymaguro is in a reboot loop 
 * ogra_ re-flashes with 194
<Laney> mardy: I just got syncevolution building, but your diff doesn't make it install any extra files?
<mardy> Laney: let me check...
<Laney> it builds a library called provideruoa which never gets put into any package
<Laney> is that all that's needed?
<mardy> Laney: yes, that's it
<mardy> Laney: weird that it doesn't warn of missing installed files
<seb128> dh_install --fail-missing ftw
<Laney> you can make it do that, but it's not the default
<Laney> mardy: so, make a syncevolution-provider-uoa package?
<Laney> s/,/, shall I/
<mardy> Laney: I don't know, I don't think it's needed
<Laney> no?
<ogra_> xnox, http://paste.ubuntu.com/7032374/
<xnox> ogra_: and did you get incomming callback popup?
<ogra_> xnox, thats image 188 (about two weeks old, scripts are python2 ... the dialling works btw, i get a call back)
<ogra_> xnox, yeah, works as advertised
<ogra_> just spills that traceback
<ogra_> and i bet i know why it fails ...
 * ogra_ tests something 
<xnox> ogra_: is the magic callback stuff in phonesim? it should return normally over dbus.
<xnox> ogra_: my emulator is still running content-hub hook =)
<ogra_> xnox, soo
<ogra_> i get no traceback when running it as root
<ogra_> but the dialer-app test (as all AP tests) run as phablet user
<ogra_> xnox, yeah, it is in phonesim
<Laney> mardy: there are some .service .provider and .service-type files that it wants to install into /usr/share/doc too?
<xnox> wasn't dialer-app suppose to become a click-app?
<ogra_> i dont think so
<ogra_> i dialer and messaging are the two exceptions
<mardy> Laney: you can ignore them
<Laney> okay
<ogra_> *i think
<ogra_> xnox, ah, and the script is blocking, i have to ctrl-c out of it even as root (which produces the same traceback then)
<xnox> ogra_: well, wait for 120 seconds.
<ogra_> oh, right
<xnox> ogra_: it has a timeout.
<ogra_> yeah, forgot about that
<ogra_> but in any case the traceback was there before as i thought
<ogra_> just that apport didnt pick it up before
<xnox> ogra_: so that crash has always been there. thus not a regression, but still bad none-the-less.
<ogra_> right, and bad because it shows on the testing dashboard
<xnox> we shouldn't have crashes supressed.
<ogra_> we shouldnt have crashes :)
<xnox> ogra_: right, not artificially  however =)
<xnox> ogra_: i don't like the idea of shipping ofono-scripts on the image by default, and allow unpriviledged users to execute them and thus spoof calls / txt messages etc.
<ogra_> well, so for clearing the dashboard lets upload a hack, and then leave it to pitti to fix that properly i'd say ... unless you want to go on debugging it
<ogra_> there are many cases wheer you need the scripts to make use of specific features
<ogra_> if you mess up your PIN three times we dont have a UI to enter the PUK for example ... to unlock the card again
<ogra_> you need the scripts
<ogra_> (there are other features you can only reach via the scripts)
<xnox> ogra_: no, we will not suppress crashes.
<ogra_> once we have UIs for them we can drop the scripts
<xnox> didrocks: the crash in dial-number was always there, we don't know how, but whoopsie/apport were not picking it up before.
<ogra_> xnox, well, do you have another solution in mind apart from rolling back two revisions ?
<didrocks> xnox: interestingâ¦ what makes you think that?
<ogra_> didrocks, see above i have just proven it
<ogra_> didrocks, it is on 188 as well, but does not produce a .crash file
<didrocks> weirdâ¦
<ogra_> didrocks, something wrt apport changed, all the crashes were there before
<xnox> ogra_: my solution is to acknowledge and work on fixing two bugs: one why python2 dial-number is not generating crash, but python3 one does. Two: make it not-crash in ofono, when it succeeds.
<ogra_> it just never produces .crash files for them
<ogra_> *produced
<didrocks> ogra_: ok ;)
<xnox> ogra_: Three: fix dialer-app tests to actually verify that dian-number succeeds and dial back is there.
<xnox> didrocks: there are three bugs to fix however =)
<ogra_> didrocks, are you ok with that ?
<ogra_> promoting with dangling around .crash files on the dashboard ?
<didrocks> ogra_: this sounds legit to me as this was analyzed and it's not a real issue
<ogra_> didrocks, awesome
<didrocks> well, we don't promote until clock app is fixed anyway, so there is time for getting 1/2/3 leaded by xnox done :)
<xnox> ogra_: didrocks: actually, we can fix this in the AP tests. AP tests shouldn't use the dial-number script, instead they should invoke the dbus call to org.ofono themself and thus properly catch/process dbus exception from there.
<ogra_> didrocks, well, not sure we can expect him to do the work of the QA team :)
<ogra_> didrocks, i think the fix of the test is really their responsibility
<didrocks> ogra_: no, but talking to them is "leading" :)
<ogra_> didrocks, its pittis test ... there is a bug filed, but pitti is on vac this week
<didrocks> ok, I think pitti won't lay that off the radar, so fine
<ogra_> beyond that, the unfixed test wont do harm, it still works, it has just unsafe calls to the lower layer
<xnox> filed https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1287659
<ubottu> Launchpad bug 1287659 in whoopsie (Ubuntu) "python2 crash traceback was not caught, yet python3 one was" [Undecided,New]
<ogra_> great !
 * ogra_ hugs xnox ... thanks so much for helping with that 
<xnox> oh, and ofono-phonesim needs autopackage tests for starting up without crashing =)
<xnox> bug #1287660
<ubottu> bug 1287660 in ofono-phonesim (Ubuntu) "Needs autopackage test for phonesim-autostart" [Undecided,New] https://launchpad.net/bugs/1287660
<ev> xnox: that's probably better filed against apport
<ev> remember that whoopsie is just the shovel for daisy.ubuntu.com
<ev> by the time the report hits whoopsie, it's already complete
<xnox> ev: ah ok, i it's all apportwhoopsiedaisyerrors to me =)
<ev> xnox: we could use a nice diagram, yeah
<xnox> ev: in dot, with LaTeX labels, rendered on the fly, by moinmoin wiki page.
<xnox> *nobody will ever edit it again*
<ev> xnox: woefully out of date, but https://wiki.ubuntu.com/ErrorTracker/ServerArchitecture
<ev> xnox: also https://wiki.ubuntu.com/ErrorTracker#Anatomy_of_a_crash.2C_in_detail
<xnox> ev: kernel generates python3 traceback report file?
<ogra_> only if you use the python kernel
<ogra_> :P
<xnox> ev: re:diagram in russian there is a great expression:"I am starring at it, like a goat at a billboard" (as in, it's pretty, but little is comprehended)
<ev> lol
<ev> yeah, I showed that to lifeless ages ago and he very politely suggested that I try a sequence diagram. Never managed to find time for it though
<xnox> ev: do python crashes require python-problem-report to be installed?
<ev> xnox: very much so, yes
<ev> all crashes require it
<xnox> ev: there is also python3-problem-report, i guess either is sufficient (well should match the apport one is running)
<ogra_> xnox, hmm, well, only the python3 one is installed on the images ...
<ev> xnox: there's an easy way of testing you have what you need
<ogra_> let me install the py2 version of it and lets see if i get a crash file
<ev> bash &; kill -SEGV $?
<xnox> ev: well, we get crashes for binaries crashing. we are not getting them for simple python scripts that raise dbus exceptions and not crashing the interpreter itself (python2 one, we get .crash file for python3)
<xnox> ev: ogra_: or we can just move to python3 asap where it's still used =)
<ev> xnox: anything of value in /var/log/apport.log?
<xnox> ev: emulator crashed... rebooting.
<ogra_> ev, nope, not for me
<ogra_> at least nothing related to calling the script that produces the traceback
<ogra_> also installing python-problem-report didnt create any .crash file
<ev> it's python - I'd start instrumenting it and seeing where it's failing to produce the crash file
<ogra_> well, to be honest i dont really care as long as we get them now :)
<ogra_> thats mostly a matter of curiosity why we didnt get them with py2
 * ogra_ is mostly with xnox here ... lets just move to py3 everywhere :) 
<xnox> ev: the apport's test-suite doesn't help, it relies on the python3 crasher under test to install/raise apport hook, but new apport only allows python3 hooks and we want a python2 crasher =/
<ev> xnox: I'm sure pitti would appreciate patches
<jamespage> cjwatson, how would you expect invoke-rc.d to behave for an upstart configuration that does exist but on a system where upstart is not the init system i.e. Debian?
<jamespage> i was expecting a 100 - but a 102 get thrown
<jamespage> xnox, I guess you might have an opinion on this as well
<cjwatson> 102 feels like a bug
<cjwatson> probably best to sh -x it
<jamespage> cjwatson, OK _ I'll poke
<xnox> jamespage: per debian policy, an init.d script and/or systemd unit should be provided.
<xnox> (e.g. systemd unit should be sufficient for a linux-any package)
<xnox> ..
<xnox> how does one do conflicts resolution, between multiple branches that are to be part of one silo?
<jamespage> xnox, we it is
<jamespage> but the upstart configurations have different features
<jamespage> 'ceph' is provided for init.d script
<jamespage> we/well
<xnox> jamespage: oh, if there is equavalent initd script (but under different name)
<Laney> Where does policy talk about systemd?
<xnox> jamespage: one needs to generate dummy / empty - either upstart or initd scripts, to get back to one-to-one mapping.
<xnox> jamespage: i believe slangasek address that in the debian compatible upstart scripts wikipage.
<jamespage> xnox, well its not 100% equivalent as init.d scripts can't really be event driven
<Laney> mardy: ppa:laney/arm - try syncevoluion & syncevolution-provider-uoa please
<jamespage> xnox, ceph under upstart works in quite a different way to ceph under init.d script
<cjwatson> happyaron: what happened to the ibus-pinyin-db-android binary package?  it's no longer built by the ibus-pinyin source, but the changelog doesn't mention that at all, so it's not clear what to do with reverse-dependencies
<xnox> jamespage: right, but either gets you something like a cephd daemon running, albeit different. see https://wiki.ubuntu.com/UpstartCompatibleInitScripts and https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html
<xnox> jamespage: we had same thing with e.g. mountall upstart job and mountall.sh, both are very different, but only one should run under each system.
<xnox> jamespage: and the right one.
<jamespage> xnox, indeed - for ceph you can't really configure your system to run both ways
<jamespage> xnox, you either do it old style (using /etc/ceph/ceph.conf) or you use all of the new-style tooling to create per daemon configs
<jamespage> so infact on Ubuntu and Debian, its really a choice
<xnox> jamespage: thus the missing init.d scripts should be no-op. either not present at all, or do nothing. depends on the situation. Or like exec the normal-initd one instead.
<jamespage> hmm
<xnox> jamespage: where is the packaging for it? can i take a look?
<jamespage> xnox, http://anonscm.debian.org/gitweb/?p=pkg-ceph/ceph.git
<jamespage> xnox, well right now its " either not present at all"
<mardy> Laney: thanks a lot, I will let Renato testing it (he's working with Contacts, and he requested this new version)
<xnox> cjwatson: looking at content-hub hook, it declares "Pattern: ${home}/.local/share/content-hub/${id}" yet none of the apps ship that, yet the hook is triggered. Also is it triggered ones per each click (manual or pre-installed) or once against all of them?
<xnox> (it does a run against all it can find by default)
<cjwatson> xnox: Pattern declares the symlink to create, not the expected target
 * xnox goes to read the docs again.
<cjwatson> xnox: assuming you mean on boot under "click hook ...", the Exec line is run once at the end of syncing up symlinks, and is expected to catch up with everything
<xnox> correct, right.
<cjwatson> (it quite deliberately doesn't e.g. get parameters telling it which package to run on, to encourage good hook design)
<xnox> cjwatson: good, so click side things are all good.
<cjwatson> xnox: but of course! ;-)
<dobey> dholbach: i'd rather not. my only answer is "no" but i don't know if anyone was bringing a fork back or anything. the "official" plug-in is not coming back though
<dholbach> dobey, ok... I just wasn't sure if this was answered anywhere else and I could point to some discussion
<lifeless> ev: :)
<AnAnt> Hello, where does lightdm put logs of the user session ?
<seb128> AnAnt, nowhere, log of the user sessions are not from lightdm and they are in the user directory
<AnAnt> seb128: well, I am trying to debug a problem with GNOME shell extensions on trusty
<AnAnt> seb128: the logs used to be in ~/.xsession-errors
<seb128> try ~/.cache/upstart
<AnAnt> seb128: I ask the guys on GNOME, they say that it is handled by systemd's journal, and I should use journalctl, but there isn't a journalctl command on trusty
<AnAnt> seb128: thanks
<AnAnt> seb128: thanks it is in ~/.cache/upstart/gnome-session-gnome.log
<shadeslayer> could someone offer some advice on the MISSING symbols on this log https://launchpadlibrarian.net/165726560/buildlog_ubuntu-trusty-amd64.kdepimlibs_4%3A4.12.2-0ubuntu2_UPLOADING.txt.gz
<shadeslayer> because the symbols are for the ctor and dtor for a struct
<shadeslayer> KMime::Types::AddrSpec::AddrSpec() and KMime::Types::AddrSpec::~AddrSpec() is what c++filt gives me
<shadeslayer> should I drop them without a ABI bump considering they should have never been exposed ?
<shadeslayer> since it's not really public API?
<xnox> ogra_: in the "Self service CI (CI train)" line 42, one branch was renamed, it's now called lp:~ubuntu-core-dev/ubuntu-ui-toolkit/py32ap
<xnox> ogra_: previously it was owned by ~xnox.
<xnox> ogra_: can you fix it?
<ogra_> xnox, are you sure ? i guess bzoltan changed it
<ogra_> i actually see ~xnox ... you mean i need to point to the url above
<xnox> ogra_: no, i renamed my branch. it used to be owned by ~xnox, that is now 404, it should be https://code.launchpad.net/~ubuntu-core-dev/ubuntu-ui-toolkit/py32ap
<xnox> now.
<ogra_> xnox, right, fixed
<xnox> ogra_: and reset comment for it then.
<xnox> ogra_: comment says "third URL is a 404, needs to be fixed before silo can be assigned"
<ogra_> done
<xnox> ogra_: danke schon.
<ogra_> :D
<smoser> anyone know... in a cloud-image i am not seeing a 'boot.log'
<smoser>  /var/log/boot.log
<smoser> but i do see that in a d-i based install that i did of trusty.
<smoser> anyone know what would cause that ?
<slangasek> smoser: ah, plymouth :P
<smoser> well, yeah, i knew it was my old friend plymouth that did that.
<slangasek> smoser: you're currently not running plymouth in the cloud-image, right?
<smoser> and i'm at this point accustomed to he and I not getting along well.
<smoser> we currently are running it.
<slangasek> ah
<slangasek> not sure then
<smoser> its this: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1160079
<ubottu> Launchpad bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Undecided,Invalid]
<slangasek> oh; why is that marked invalid?
<smoser> it expired
<slangasek> no, utlemming marked it invalid
<utlemming> slangesk: I have no idea why I did that...
<slangasek> k :)
<smoser> slangasek, how do i enable apport ?
<slangasek> smoser: what does /etc/default/apport contain for you?  (Which version of apport is this?)
<slangasek> smoser: oh, the other problem is that /etc/init/apport.conf is 'start on runlevel [2345]', which is late to catch a plymouth crash at boot :P
<smoser> + dpkg-query --show apport
<smoser> apport  2.13.2-0ubuntu5
<smoser> + grep --color=auto -v '^#' /etc/default/apport
<smoser> enabled=1
<smoser> yeah.
<slangasek> smoser: so I think you're probably going to need to grab a core file from plymouth directly by manipulating /etc/init/plymouth.conf to set up the core handler in pre-start
<smoser> thats fine by me. thoguhts on how ?
<slangasek> smoser: it might just be as simple as replacing the 'exec' line of /etc/init/plymouth.conf with this: http://paste.ubuntu.com/7034935/
<smoser> and that will just (we think) dump core.$PID into / ?
<slangasek> yeah
<slangasek> well, depending of the content of /proc/sys/kernel/core_pattern
<slangasek> which you can tweak to name it differently, or you can leave it as-is and just find the core wherever it's dropped :)
<smoser> slangasek, can i maybe just:
<smoser> exec /bin/sh -c 'exec "$@"' -- /sbin/plymouthd --mode=boot --attach-to-session
<smoser> or will that confuse upstarts's process tracking
<slangasek> well, you've confused me
<slangasek> what are you hoping to accomplish?
<slangasek> you need the explicit call to 'ulimit -c unlimited', because by default we don't drop cores
<smoser> right. i forgot that part :)
<jtaylor> hm whats the best way to bisect glibc
<jtaylor> do I need to remove the build folder each time or will incremental build work?
<jtaylor> nice, seems to work
<jtaylor> still seems it would profit from non recursive make :7
<ahoneybun_> are we finally going to get a new icon set for 14.04?
<arges> hallyn: hey. if I wanted to patch vm-builder in precise to have 'trusty' as a proper series. where do I fix this? in the bzr, as a patch, ?
<hallyn> arges: for the current series I use lp:vmbuilder and lp:~vmbuilder-dev/vmbuilder/packaging.  for precise just just do a debdiff against the precise package i guess.
<arges> hallyn: ok i'll do that.
<hallyn> arges: since it doesn't look liek vmbuilder will be out of the archive in time for trusty, I'm looking forward (haha) to spending somet time getting refamiliarized with it
<hallyn> I'll shun uvtool and embrace vmbuilder :)
<arges> hallyn: yea i started using it recently, and it works out pretty nicely. i was using virt-install+preseed files  before
<hallyn> downloading cloud iamges is generally nicer, and i *had* hoped to dump vmbuilder, but it is what it is :)
<hallyn> arges: shout if/when you open a bug and want the debdiff SRU'd into archive
<arges> cool
<jdstrand> barry: hey, so I've got an issue with a test suite using the system python modules if they are installed even if I use PYTHONPATH. Eg:
<jdstrand> PYTHONPATH=./ python3
<jdstrand> import apparmor.click
<jdstrand> ^ that will use /usr/lib/python3/dist-packages/apparmor/click.py if it is installed
<jtaylor> wild guess, try an absolute path
<jdstrand> if I uninstall python3-click-apparmor, then import apparmor.click works fine
<barry> jdstrand: try PYTHONPATH=./ python3 -E
<barry> er, no
<barry> sorry, misunderstood you
<jdstrand> printing out sys.path seems to show that ./ is first
<barry> jdstrand: although it is verbose, you can use -v to see all the import attempts
<jdstrand> barry: I'll try -v now, but this paste shows it is first: http://paste.ubuntu.com/7035400/
<jdstrand> and if I remove what is in /usr/lib/python3/dist-packages/, it will find it
 * jdstrand is puzzled
<jtaylor> did you try $PWD?
<jdstrand> I did
<jtaylor> :(
<jtaylor> is it a binary extension?
<jdstrand> no
<jdstrand> well, actually, I do use a ctype
<jdstrand> this is with -v: http://paste.ubuntu.com/7035419/
<jdstrand> so it finds /home/jamie/bzr-pulls/click-apparmor/apparmor/__init__.py
<barry> jdstrand: the first entry, i.e. '' is interpreted as current working directory
<jdstrand> but down below, it uses /usr/lib/python3/dist-packages/apparmor/click.py
<jdstrand> so I don't even need PYTHONPATH
<jdstrand> which is what I had thought
<barry> not if you're in a directory that contains the package or module you want to import
<jdstrand> barry: can you rephrase? eg, if I am in the toplevel source tree, apparmor/click.py and apparmor/__init__.py exists
<jdstrand> barry: and that is where I am doing 'python3' following by 'import apparmor.click', yet the system apparmor.click is being used
<jdstrand> I feel like this worked before
<barry> jdstrand: can i reproduce your environment?
<jdstrand> barry: sure: bzr branch lp:click-apparmor
<jdstrand> barry: sudo apt-get install python3-apparmor-click
<jdstrand> barry: how I am testing is that towards the top of apparmor/click.py, I added: print("HERE")
<jdstrand> barry: then I just do: cd ./click-apparmor ; python3
<jdstrand> barry: import apparmor.click
<jdstrand> hmm, I have an 'import apparmor' at the top
<barry> jdstrand: try `python3 -S` :)
 * jdstrand scratches head
<jdstrand> I don't even know what that is
<barry> jdstrand: i don't remember exactly how atm, but i think our site.py is hacked to install apparmor from the system path, even before you get an interpreter prompt (or import your own code).  -S disables loading site.py
<jdstrand> huh
 * jdstrand wonders why we do that
<barry> jdstrand: i would have to dig in a little deeper to see how it's done, but don't have the time atm.  as to motivation, i guess you'll have to ask the apparmor devs.  my guess is so that it's embedded at the lowest level so it can't be subverted
 * jdstrand is an apparmor dev
<jdstrand> barry: ok, thanks, I'll look into it
<barry> jdstrand: i guess you should ask jdstrand then!
<barry> :)
<jdstrand> barry: fwiw, we don't seem to do anything special with apparmor in site.py
<barry> jdstrand: hmm.  there has to be some effect, since -S makes it work
<jdstrand> yeah. I'll keep poking at it
<jdstrand> hmm. apparmor-easyprof installs files into /usr/lib/python3/dist-packages/apparmor/, and so does python3-apparmor-click
<jdstrand> but apparmor-easyprof's __init__.py is what's in /usr/lib/python3/dist-packages/apparmor/
<jdstrand> I bet there is a weird interaction that
<jdstrand> there*
<hallyn> arges: I pushed the vmbuilder fix to trusty.  shout if you want me to push the precise one as well
<arges> hallyn: ah you beat me to it
<hallyn> arges: sorry
<arges> hallyn: bug 1287943, its not in any of the other stable releases
<ubottu> bug 1287943 in vm-builder (Ubuntu) "vm-builder needs trusty suite" [High,In progress] https://launchpad.net/bugs/1287943
<arges> hallyn: precise probably the more important on
<arges> one
<hallyn> arges: on it
<arges> hallyn: cool thanks!
<jdstrand> barry: interesting, if I zero out apparmor/__init__.py, then it works
<jdstrand> I think I can work with that
<jtaylor> hm will we get gcc-4.9?
<hallyn> oh no.  it looks like there was a change by xnox in the archive
<jtaylor> or do we have some ppas that provide it?
<jtaylor> I do not feel like building my own gcc to check if a glibc miscompile is fixed :/
<sbeattie> jdstrand, barry: I suspect pep 402 is coming into play; the current easyprof __init__.py doesn't do the declare_namespace() trick.
 * jdstrand doesn't know what the declare_namespace() trick is
<sbeattie> jdstrand: see the __init__.py in click-apparmor
<sbeattie> as well as http://www.python.org/dev/peps/pep-0402/
<jdstrand> sbeattie: yeah, I didn't know what __init__.py was doing
 * jdstrand reads
<sbeattie> jdstrand: I'm not able to reproduce it with the trunk based apparmor packages I'm testing, which also has that in its __init__.py
<sbeattie> jdstrand: http://paste.ubuntu.com/7035580/
<jdstrand> interesting
<jtaylor> doko: do you have some gcc-4.9 builds?
<jdstrand> ok, well, have enough information to do go forward
<jdstrand> sbeattie: thanks!
<barry> jdstrand, sbeattie: there's another thing in play, at least on my system.  if you put a `print('HERE')` in your local apparmor/__init__.py, but *before* the namespace declaration, then import apparmor from the prompt, the print gets executed, and yet apparmor.__file__ is the system one
<hallyn> arges; and after this push to precise I'm cutting out for the day bc it's not going well :)  forgot to mark the lp bug in the changelog for trusty.  sigh
<jdstrand> I think I am going to just do local testing with __init__.py empty, but not commit that. when I get the new apparmor, it should all just work
<jtaylor> do we have a snapshot.debian.org equivalent?
<doko> jtaylor, ubuntu-toolchain-r PPA, or experimental
<sbeattie> (doh, pep420 is the one that got accepted and finalized)
<jtaylor> thx, lets see
<jtaylor> I dread bisecting gcc ..
<jdstrand> sbeattie: yes. should we change apparmor to use pkgutil since it is recommended or stick with pkg_resources.declare_namespace since that is ok too?
<jdstrand> actually, I am just going to uninstall python3-apparmor-click and leave __init__.py alone
<jdstrand> which works for what I'm doing until I get the new apparmor
<jtaylor> mh fixed in 4.9
<sbeattie> jdstrand: oh, hrm. maybe all the declare_namespace stuff can just go away?
<jdstrand> sbeattie: I didn't read the whole thing, but I think everything needs to be the same, and should choose either declare_namespace or the pkutil method
<jdstrand> sbeattie: since different projects are putting things in the same namespace
<jdstrand> sbeattie: assuming I gleened correctly, you did the right thing adding it
#ubuntu-devel 2014-03-05
<slangasek> cjwatson: hmm, so adt-run is not working as I'm expecting... adt-virt-schroot is refusing to do anything sensible with Restrictions: needs-root, do you have any idea about this? http://paste.ubuntu.com/7036025/
<psusi> what the heck runs udisksd?  it doesn't seem to be an upstart or rc job
<hallyn> Daviey: bdmurray: since the full libvirt 1.1.1 maint tree seems to scare people, I've uploaded a new saucy libvirt for SRU with a small subset of the patches.  Please reject the older 1.1.1-0ubuntu8.6 and accept the newer
<slangasek> psusi: dbus
<psusi> slangasek, in response to what and how does it know to do that?  and is there a way to get it to log the output?
<psusi> /etc/dbus-1/system.d/org.freedesktop.Udisks2.conf doesn't seem to mention an executable or anything
<psusi> ahh, there it is... /usr/share/dbus-1-system-services
<slangasek> yep, that'll be it :)
<psusi> so is there a way to get it to log the debug output, and... isn't it wrong to have that activate on demand?  It is supposed to set system policies like standby timers that should be done at boot, whether or not a dbus client calls on udisks
<psusi> and why doesn't it remain a child of the dbus process?
<ahoneybun_> so the 2012 nexus 7 is no longer being worked on?
<infinity> doko: I CCed you on a glibc bug that appears to (maybe) be a GCC bug, based on jtaylor's investigation.
<pitti> Good morning
<happyaron> cjwatson: ibus-pinyin-db-android is still there, while ibus-pinyin-db-open-phrase is gone. the latter does not have reverse-depdens.
<Noskcaj> Can someone please check http://metadata.ftp-master.debian.org/changelogs/main/t/tiff/unstable_changelog ? Is it a worthwhile sync?
<dholbach> good morning
<aswininm> very good morning:)
<pitti> RAOF: hey Chris, how are you? thanks for your umockdev work!
<pitti> RAOF: do you want to work on other things, or should I do a 0.7 release now?
<RAOF> That's a good question.
<RAOF> pitti: I think I'm good for the moment. :)
<pitti> RAOF: ok; do you want/need a release now?
<RAOF> Yes please.
<pitti> RAOF: done, and uploaded to sid; will sync this evening when it's imported
<Noskcaj> pitti, Is there anything in particular you want me to do before you change your comment on https://wiki.ubuntu.com/Noskcaj#MOTU ?
<Noskcaj> I'm hoping to be able to run for MOTU again this month or next, depending on if i can get the relevant testimonies.
<pitti> Noskcaj: I guess I just need to review/sponsor more from you :)
<Noskcaj> well sponsor queue is at 60 packages. But you've sponsored more of my packages since the testimonial
<Noskcaj> A sync of libsigc++-2.0 might be worthwhile. I haven't got time to properly test build tonight though
<Noskcaj> g'night
<seb128> just for info the desktop iso build fails because of
<seb128> http://launchpadlibrarian.net/168350693/webbrowser-app_0.23%2B14.04.20140219-0ubuntu1_0.23%2B14.04.20140304-0ubuntu1.diff.gz
<seb128> that made webbrowser-app depends on some universe binaries
<seb128> that's being worked on (likely to lead to a revert)
<Laney> umm
<xnox> hallyn: what's up? which changes by xnox in the archive =)?!
<cjwatson> slangasek: adt-virt-schroot only offers the root-on-testbed capability if your username is in root-users or one of your groups is in root-groups in the schroot config for it
<cjwatson> happyaron: No, ibus-pinyin-db-android is no longer built by ibus-pinyin.  See https://launchpadlibrarian.net/167756163/ibus-pinyin_1.4.0-2ubuntu3_1.5.0-1ubuntu1.diff.gz where you can quite clearly see it being removed
<cjwatson> happyaron: If you mean that was a mistake, OK, please revert the relevant bit then :-)
<tjaalton> uh, so I have union-overlay-directory set to a tmpfs, but sbuild still builds pkgs on the hd
<tjaalton> what am I missing?
<tjaalton> only the chroot is copied to the overlay
<tjaalton> or such
<tjaalton> /var/lib/sbuild/build then
<tjaalton> that was it
<mapreri> pitti: autopkg test is funny: I run the tests 5 times, and I obtain 5 different results :S
<pitti> mapreri: you mean sometimes it starts up and sometimes not?
<pitti> mapreri: could very well be a bug in the test as well that it doesn't properly wait for the startup, etc.
<mapreri> pitti: could you re-run the tests on jenkins? I'm curios... anyway, also in debian the tests fails: http://ci.debian.net/#package/varnish
<pitti> mapreri: ran it again
<pitti> mapreri: but it was really stable until the previous version, see history on https://jenkins.qa.ubuntu.com/job/trusty-adt-varnish/
<mapreri> I see
<pitti> mapreri: run 31 done, also failed (but with slightly different results indeed)
<pitti> mapreri: debian/tests/ changed significantly in 3.0.5-1 indeed
<pitti> mapreri: I suppose debian/tests/run-tests needs some code to wait for varnish to actually start up (with some reasonable timeout); right now the package gets installed, and apparently the postinst finishes before the daemon is fully running?
<mapreri> pitti: maybe. I should do some tests.
<mapreri> pitti: all the tests were completely rewritten. I'm new to this tests, let me understand what they really do, I'll ping you when I have results.
<pitti> mapreri: great, thanks! yeah, I don't know them either, I'm afraid; I don't even know what varnish is or does so far :)
<mapreri> :)
<pitti> jodh: oh, your pbuilder update collided with slangasek's
<pitti> jodh: reopened the MP, can you please merge? your version is better I think
<kilian> hi
<kilian> is there any official statement where apt-cache show takes its knowledge about Supported: and Origin: from?
<kilian> I've tried to find any notion of these two in the official packaging guides but failed
<kilian> looks like these values appear just right out of nowhere :-?
<geser> kilian: apt knows it from the package lists (/var/lib/apt/lists/*) and those lists are generated by the archive part of LP
<xnox> kilian: indeed they are generated by LP at archive publication/generation. Please note that Supported fields are at the moment are not correct for trusty* suites, and there are discussions around what they should be and a merge proposal against launchpad to correct them.
<kilian> geser: I guess I could override that entry with a simple line in debian/control then?
<kilian> geser: for a local archive
<kilian> xnox: thanks for the explanation.. is there any URL where to read up on this?
<xnox> kilian: no, you shouldn't add it to debian/control.
<xnox> kilian: depending on how you generate your archive, you should be using archive-overrides to add extra fields.
<kilian> xnox: I can't really see anything in apt-ftparchive .. so where would I be adding that?
<xnox> kilian: e.g. apt-ftparchive supports override files.
<xnox> kilian: read $ man apt-ftparchive, look for "override"
<kilian> xnox: ok, will check that.. thanks
<xnox> kilian: but why would you want/need those fields? they are not-required, and are meaningless, unless /you/ attach a meaning to them.
<kilian> ..which is exactly what I want to look at for a purely local repo and a local server farm
<kilian> i.e. pull that into monitoring and shut up the moaning about missing entries for my private packages
<kilian> xnox: or asked around the other way.. is there any frontend tool that I could use to ask my system which packages are out of support for an LTS release?
<xnox> kilian: it's invalid to require/mandate those fields, as none of the Debian packages / Debian archives have them.
<kilian> in some sort of an easy approach?
<kilian> xnox: I know
<xnox> kilian: yeah, i believe there is a tool for that.
<kilian> cool, what's its name? ;-)
<cjwatson> ubuntu-support-status
<kilian> cjwatson: thanks. and that's part of which package?
<xnox> yeah that =) couldn't remember / find it.
<cjwatson> kilian: update-manager-core
<kilian> excellent. thanks!
<jodh> pitti: done, thanks.
<pitti> jodh: and uploaded, take II :)
<pitti> thanks
<pitti> superm1: is dell-recovery still actually being used?
<superm1> pitti: yep
<pitti> superm1: thanks
<superm1> sure.  been busy with other stuff so haven't had much time to look at it with regard to 14.04 though
<pitti> superm1: I'm reviewing the remaining rdepends of udisks 1, so including it in bug 1288253
<ubottu> bug 1288253 in dell-recovery (Ubuntu) "Eliminate udisks 1 from Ubuntu" [High,Triaged] https://launchpad.net/bugs/1288253
<superm1> ick, so that'll be some work to transition then
<pitti> jodh: "Jenkins Fixed - trusty-adt-pbuilder-ppc64el 4" \o/
<jodh> pitti: yay! :)
<Laney> do we still have migrates-when-autopkgtests-fail bugs?
<pitti> Laney: yes, we do
<pitti> Laney: we now have some britney tests which reproduce some bugs (https://code.launchpad.net/~canonical-platform-qa/britney/tests/+merge/207982)
<pitti> Laney: and I started to look into britney to fix some bugs (started with https://code.launchpad.net/~pitti/britney/britney2-autopkgtest-fixes/+merge/208657)
<Laney> pitti: ah, I thought that stuff was in, thanks for the pointers
<Laney> Don't know if this particular problem is covered there, mind
<cjwatson> I'm reviewing it now
<pitti> Laney: no, it's probably not; we found several other cases where things can (and probably do) go haywire in adt-britney; jibel is rewriting and greatly simplifying those, with tests
<Laney> OK
<Laney> Not that I'm complaining in this instance since it means I don't have to fix all of the ubuntuone tests ;-)
<pitti> Laney: which package are you looking at/
<pitti> ?
<Laney> pitti: ubuntuone-sso-client
<Laney> I think it triggered -control-panel and -client, which failed
<cjwatson> pitti: I think invalidate_dep is the wrong method to call here; it will result in some redundant "Depends: ..." output in the excuses with a broken link, which I don't think adds anything over the existing "unsatisfiable Depends:" output.  Normally invalidate_dep is called much later and I don't think it makes sense to drag it in here.
<cjwatson> pitti: Can I suggest http://paste.ubuntu.com/7038848/ on top of your commit as an alternative implementation of this?
<cjwatson> pitti: It'd be worth running through the tests of course
<cjwatson> pitti: sorry, that's not on top of yours, that's against current production
<pitti> cjwatson: oh, thanks; I don't really have a "feeling" how britney should work yet
<pitti> cjwatson: ack
<cjwatson> pitti: it is twisty.  I'd apologise for it except most of it isn't mine :-)
<pitti> cjwatson: ah, so the excuse.invalidate_dep(block_txt.strip()) (which was kind of the gist of it) was ok?
<cjwatson> pitti: well, no, I pulled that out and did it differently by returning a value from excuse_unsat_deps
<cjwatson> pitti: I think I forgot a bit though, let me recheck
<pitti> cjwatson: hm, the test still fails with that patch
<cjwatson> pitti: http://paste.ubuntu.com/7038873/ should be better
<cjwatson> I wasn't actually using the return value properly :)
<cjwatson> the second-to-last hunk there is the most important bit
<pitti> Does not request a test for an uninstallable package ... ok
<pitti> cjwatson: yay, that does it
<pitti> cjwatson: does the test run for you?
<cjwatson> pitti: can you try without the last hunk of that (run_autopkgtest = False in invalidate_excuses), which I've just noticed is pointless as it's called too late?
<cjwatson> pitti: how do I run it?
<pitti> $ tests/autopkgtest.py
<pitti> I needed to create a britneymodule.so -> lib/britneymodule.so symlink
<pitti> otherwise britney doesn't work
<pitti> cjwatson: still works without the last hunk, yes
<cjwatson> It passes that test here, but I get other failures, http://paste.ubuntu.com/7038900/
<cjwatson> known?
<lamont> was it a conscious decision to make gnome terminals come up as 79x21 instead of 80x24?
<pitti> cjwatson: yes, these are other bugs that I found
<pitti> cjwatson: the first three reproduce the gccgo-4.9 issue that we had
<lamont> on the bright side, they've stopped extending below the bottom of the screen
<pitti> cjwatson: the last one is not very important, I just stumbled over it when writing those
<cjwatson> ok, well anyway, I'll apply this diff and merge the combination
 * cjwatson dumps this conversation into the MP
<pitti> cjwatson: I kept the MPs separate as you may not like the tests in its current form, while the fix might be valid; or vice versa, which is what happened now
<pitti> cjwatson: I can also look into the gccgo-4.9 problem (no tests run if new source takes over existing binary), I just needed today to do the usual post-holiday catch up
<pitti> cjwatson: back in 20 mins
<cjwatson> Yeah, I'm mostly working on click at the moment but ...
<cjwatson> pitti: OK, merged, should be effective as of the next p-m run
<cjwatson> thanks!
<hallyn> xnox: you'd made a change to vm-builder (in january) to convert to dh-python2.  I did the next upload based on the lp:~vmbuilder-dev/vmbuilder/packaging tree which didn't have that.
<hallyn> xnox: (i reintroduced your changes;  should have checked archive first)
<cjwatson> pitti: Looks *almost* right in production except that it's not quite doing the right thing for single-arch unsat deps - let me fix that
<cjwatson> That's just an idiot mistake from me
<cjwatson> (fixed)
<cjwatson> zul: there's a dependency typo in manila that's preventing it migrating to trusty, FYI - s/pyhon/python/
<zul> cjwatson: ack ill fix it
<cjwatson> ta
<cjwatson> zul: also tempest, I think Depends: python-prb should be python-pbr to match Build-Depends?
<zul> cjwatson: right :(
<cjwatson> zul: in fact there's already a python-pbr in Depends as well, maybe it's just a duplicate
<zul> ok ill have a look
<Laney> can I help to moderate ubuntu-devel?
<cjwatson> That sounds like a fine idea, it could use more people with a bit of time
<seb128> hum
<seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-control-center
<seb128> unity-control-center (14.04.3+14.04.20140303-0ubuntu1 to 14.04.3+14.04.20140305.1-0ubuntu1)
<seb128>     Maintainer: Ubuntu Desktop Team
<seb128>     0 days old
<seb128>     Not considered"
<seb128> why is it not considered?
<seb128> shouldn't there be a reason in that snippet?
<smoser> anyone else seeing this ? i just dist-upgraded (last one was maybe yesterday) and rebooted (last one was long ago).
<smoser> and now 'vi myfile.<tab>' does not tab complete!
<smoser> hm.. and now its working.
<smoser> very odd.
<seb128> smoser, no such issue here
<smoser> must be luser error.
<smoser> ugh. i'm pretty sure something changed. it must be selectively completing now.
<smoser> hm.. it seems its busted ~/ resolution
<smoser> seb128, just fyi ^ https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1288314
<ubottu> Launchpad bug 1288314 in bash (Ubuntu) "bash completion broken with '~' expansion" [Undecided,New]
<smoser> jodh, around ?
<jodh> smoser: yo
<smoser> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1284164
<ubottu> Launchpad bug 1284164 in upstart (Ubuntu) "~/.cache/upstart grows enormous" [Undecided,New]
<smoser> i thought you'd suggested / implied that my dbus.log would be truncated on log out and log in
<smoser> is that not true?
<jodh> smoser: on login, yes.
<smoser> well, it is not true (as i've just done that and still have ~ 400M :)
<jodh> smoser: what happens when you run "start logrotate" as your user?
<smoser> $ start logrotate
<smoser> logrotate start/running, process 9556
<smoser> still big fat dbus.log
<cjwatson> seb128: there should, wonder if that's a regression from my/pitti's work today
<smoser> jodh, where does that job live ?
<jodh> smoser: so the log hasn't been compressed? If not, logrotate is likely not installed or in the PATH.
<jodh> smoser: /usr/share/upstart/sessions/logrotate.conf
<smoser> $ dpkg-query --show logrotate
<smoser> logrotate	3.8.7-1ubuntu1
<smoser> $ which logrotate
<smoser> /usr/sbin/logrotate
<jodh> smoser: cat ~/.cache/upstart/logrotate.log ?
<smoser> $ file ~/.cache/upstart/dbus.log
<smoser> /home/smoser/.cache/upstart/dbus.log: ASCII text, with very long lines, with CRLF line terminators, with escape sequences
<smoser> error: bad top line in state file /home/smoser/.cache/logrotate/status
<smoser> (64 lines like that)
<jodh> smoser: maybe delete that status file then?
<smoser> i'd say so :)
<smoser> nice:
<smoser> $ ls -l /home/smoser/.cache/logrotate/status
<smoser> -rw-r--r-- 1 smoser smoser 385 May 31  2013 /home/smoser/.cache/logrotate/status
<smoser>  file /home/smoser/.cache/logrotate/status
<smoser> /home/smoser/.cache/logrotate/status: data
<seb128> cjwatson, should I open a bug about that somewhere?
<smoser> ie, file doens' tknow what that thing is.
<cjwatson> seb128: no, it's ok, I'm looking into it now
<seb128> cjwatson, thanks
<smoser> jodh, removal of that file and then running it again does get logrotate happy.
<seb128> gar, ctrl-R on the wrong screen
<jodh> smoser: bug in logrotate then maybe?
<smoser> maybe, yeah
<jodh> xnox, slangasek: would be good to get lp:~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate reviewed. I'd call that a bugfix :)
<slangasek> cjwatson: isn't this a bug in adt-virt-schroot?  Shouldn't it know that if I'm running as uid=0, then the root-on-testbed capability is there?
<slangasek> jodh: ack
<nemo> So. I was rather surprised that the ubuntu maintained package, libumfpack5.4.0 had no -dev package
<nemo> is that normal?
<nemo> (was trying to build the colorize plugin for gimp)
<slangasek> nemo: the corresponding -dev package is libsuitesparse-dev, found by 'apt-cache showsrc libumfpack5.4.0 | grep Binary'
<cjwatson> slangasek: Possibly; does schroot have a bypass in its logic for uid=0?
<cjwatson> i.e. can you do schroot -c thingy -u root?
<cjwatson> I thought that root had to be in root-users for that
<slangasek> cjwatson: I'm not set up to do schroot -c thingy -u root - but if I'm already root, why would it need to be -u root?
<nemo> slangasek: ah. TIL. thanks.
<slangasek> cjwatson: more to the point, the manpage actually says "If your user is not allowed to do that, you need to run adt-run as root instead"
<cjwatson> well, whatever, my point is that schroot is doing its own access control which isn't necessarily aligned with what unix would normally say
<nemo> slangasek: never encountered that before.
<slangasek> cjwatson: except it's *not* doing any access control here :)
<cjwatson> anyway, if adt-virt-schroot doesn't line up with what schroot permits, then indeed that would be an adt-virt-schroot bug
<slangasek> if you're root, you get to run the command, and you get root inside the chroot, EOT
<cjwatson> it's still up to schroot whether it lets you
<cjwatson> but it is true that it does
<cjwatson> seb128: should be fixed, I made a mistake affecting binaries with empty Depends
<seb128> cjwatson, k, thanks for fixing it!
<roaksoax> slangasek: howdy! Do you have some time to review this FFe? https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881
<ubottu> Launchpad bug 1281881 in maas (Ubuntu) "[FFe] Standing FFe for 14.04 features" [Critical,New]
<slangasek> roaksoax: not at the moment... ask #ubuntu-release?
<roaksoax> will do thanks
<slangasek> pitti: so per the above discussion, I have a patch for adt-virt-schroot to make it DTRT when run as root... How do you prefer this submitted?  BTS?
<quadrispro> hello everybody
<smoser> is there any existing tools for listing all packages available?
<smoser> rmadison doesn't seem to want me to give it '--regex=.*'
<smoser> i'm guessing i can use python-apt to reasonably easily do what i want, but figure there might be something already.
<slangasek> smoser: grep Package: /var/lib/apt/lists/*Packages?  I don't think there's a tool
<Laney> `grep-aptavail -ns Package .'?
<StevenK> grep-dctrl ?
<smoser> can i rely on 'Filename' having 'universe' or 'multiverse' in it to be correct ?
<smoser> wrt grep-aptavail ?
<sarnold> apt-cache pkgnames ?
<sarnold> smoser: apt-cache madison <foo> knows main/universe/multiverse
<smoser> yeah i was just hoping to get it from one place.
<xnox> slangasek: tkamppeter: i have fixed cups with socket activation. Not uploading now, as i have to run to volleyball. Will test up and upload into the archive late tonight or tomorrow.
<tkamppeter> xnox, great, thanks.
<seb128> jamespage: hey, do you still plan to look at https://bugs.launchpad.net/ubuntu/precise/+source/iscsitarget/+bug/1262712?
<ubottu> Launchpad bug 1262712 in iscsitarget (Ubuntu Precise) "[SRU] Backport iscsitarget 1.4.20.3+svn490 into Precise" [High,Triaged]
<jamespage> seb128, I do and I've sucked at looking at it so far
<seb128> jamespage: thanks, just checking because it's the older item in the sponsoring queue
<jamespage> seb128, I think the approach is just fine; but I wanted to test it out myself before final ack which I've not found time todo yet
<seb128> no worry, if it's still on your todolist at least it's not lost ;-)
<mapreri> pitti: I can't reproduce the issue -.- I also write a short pbuilder hook (http://goo.gl/exXIbN) to call adt after the build, but the tests now are always successful :S
<mapreri> what do you suggest to try now? I'm very new to autopkgtest, maybe I'm missing something...
<slangasek> cjwatson: archaeology time :)  do you know if there's still a reason for the laptop-detect package to be seeded?  It seemed to be wanted in support of xresprobe, which is no longer seeded at all
#ubuntu-devel 2014-03-06
<TheMuso`> 6/c -all
<ScottK> Just like the good old days.
<jpds> Luxury.
<happyaro1> cjwatson: http://packages.ubuntu.com/source/trusty/ibus-pinyin
<happyaro1> cjwatson: the removed one isn't the android one, but open-phrase.
<ScottK> happyaro1: You'll probably have more luck filing a bug since it's the middle of the night for him (assuming he's not travelling)
<happyaron> ScottK: that's not a bug, cjwatson asked me about it
<ScottK> Oh.  OK.
<lamont> tab completion seems to have gone away in trusty  - or is it just me?
<lamont> ah, it just seems to have gotten smarter in stupid ways
<cjwatson> slangasek: hw-detect still uses it to try to figure out whether it needs to install mouseemu to support single-button mice on Mac laptops ... dunno if there are any other reasons
<cjwatson> happyaron: I don't much care what packages.ubuntu.com thinks is built, it's wrong.  Check Launchpad - if you look at https://launchpad.net/ubuntu/+source/ibus-pinyin/1.5.0-1ubuntu1/+build/5641888 you can see it isn't building the android package
<sarnold> heh, love the description of mouseemu that mentions "only works on 2.6", where "2.6" is The New Kernel :)
<cjwatson> happyaron: Or, you know, you could just look at the source package you uploaded and see that it doesn't have an ibus-pinyin-db-android in debian/control?
<pitti> Good morning
<cjwatson> slangasek: ubiquity also uses laptop-detect as part of its default hostname generation
<cjwatson> slangasek: there may be a few other embedded uses here and there
<pitti> slangasek: -schroot patch> Debian bug or ubuntu bug preferred, but pretty much anything else (mail/pastebin/etc.) WFM :)
<pitti> slangasek: ah, saw your bug, thanks
<slangasek> cjwatson: ah; so a lot of undeclared dependencies?
<cjwatson> slangasek: I think so
<slangasek> bother
<slangasek> ok :)
<cjwatson> Or optional use-if-present but we kind of want it, I guess
<pitti> http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect
<pitti> hm, error
<pitti> Laney, xnox: ^ it seems your codesearch instance is broken ATM? it doesn't seem to find anything
<Logan_> ooh, I didn't know that existed
<Logan_> I was actually looking for something like that last week
<pitti> it's an instance of http://codesearch.debian.net/ for Ubuntu
<pitti> or, rather, was
<Logan_> heh
<pitti> but yes, codesearch.d.n is incredibly useful for questions like that (undeclared dependencies, finding users of deprecated API, etc.)
<sarnold> woot, I thought it was dead entirely after the grand canonistack purge
<pitti> sarnold: ah, so that's probably the cause
<chiluk> cjwatson, bdmurray, apparently my changes to try to fix memtest86+ for bug 560839 caused a regression.  I've uploaded a debdiff that reverts the changes for the serial console, but keeps them for regular terminal.  It wasn't till now that I had a machine up to test serial console on.  off to sleep see you guys in the morning.
<ubottu> bug 560839 in memtest86+ (Debian) "error: too small lower memory (0x99100 > 0x98400)" [Unknown,Confirmed] https://launchpad.net/bugs/560839
<pitti> sarnold: AFAIR Laney set it up, and xnox set up DNS for it for convenience
<sarnold> pitti: the dns is news to me tonight :) it -is- convenient, hehe
<pitti> slangasek: anyway, http://codesearch.debian.net/search?q=laptop-detect might be a bit helpful, but I'm fairly sure that we have some more usages in Ubuntu
<dholbach> good morning
<Logan_> hey Daniel :)
<Noskcaj> evening Logan_, dholbach
<Logan_> hi Jackson
<Logan_> it's actually 2:30 AM where I am, and I should be off to sleep
<Logan_> except for the fact that I'm definitely going to do awful on my exam :(
<dholbach> hi Noskcaj
<dholbach> hi Logan_
<sarnold> Logan_ :/ -- more sleep almost always trumps more study in my experience..
<Noskcaj> Logan_, If you're going to be awake anyway, could you add a testimony to https://wiki.ubuntu.com/Noskcaj#MOTU ?
<Logan_> sarnold: even if you don't have a basic solid understanding of the material? ;P
<Logan_> Noskcaj: ha
<sarnold> Logan_: definitely, it's easier to reason about completely novel things on a fresh brain
<Noskcaj> This month is probably the last one i can apply for MOTU in
<Logan_> sarnold: hmm, that seems valid
<Logan_> ironically, I should know this because my test is on cognitive science :/
<Noskcaj> yep, on april 6th 19UTC becomes 5am
<Logan_> Noskcaj: it seems awfully soon to do that again, no?
<Logan_> don't tell me it's just because of making meetings
<sarnold> Logan_: hehe :) good luck and stay calm, that also helps :)
<Logan_> thanks man :)
<Noskcaj> Logan_, daylight savings ending + i'll never apply by email again + i think my only failure was not getting better testimonials in my 2 month wait
<Noskcaj> and the gnome-xchat screwup
<Logan_> personally, I'd give it more time
<tvoss> doko, around?
<Logan_> Noskcaj: whether or not you might think you're a better candidate a month later, it's not enough time for people to get a new impression of you
<Logan_> and they may think you're being overeager by applying again so quickly
<Noskcaj> I'd would wait, but ~8 months is too much time
<sarnold> Noskcaj: why the pressure? ubuntu will probably still be here two, three, four months away..
<happyaron> cjwatson: I see, will deal with it today.
<happyaron> cjwatson: should be generated from src:libpyzy now.
<Logan_> sarnold: Noskcaj has been experiencing firsthand how broken applying by email is right now
<Logan_> since he's in the land down under, it's hard for him to make DMB meetings
<Noskcaj> sarnold, it's very frustrating waiting for sponsorship
<Noskcaj> especially with xubuntu having no one who has time to sponsor stuff ATM (dev lead gone + micah always busy)
<sarnold> Noskcaj: ohhh, how long does it take for the queue to be handled, typically?
<sarnold> Logan_: meetings during sleep time are -also- unfun. hehe.
<doko> tvoss, yes, but in sessions
<Noskcaj> sarnold, I've got stuff that's been in 2+ weeks currently
<Logan_> oh dear
<Noskcaj> and a few things that are fairly release critical to xubuntu
<sarnold> Noskcaj: ahhhhh. by the time you get feedback on things your brain has long since moved on. makes sense. thanks :)
<Noskcaj> yep
<tvoss> doko, ack. Wanted to ask if you have had a chance to look into the thread sanitizer example I sent you by mail?
<Logan_> okay, imma sleep now
<sarnold> nn Logan_,
<doko> tvoss, sorry, no
<sarnold> good luck
<Logan_> everyone cross his or her fingers that I don't fail cogsci, lol
<Logan_> thanks :)
<tvoss> doko, ack
<doko> tvoss, did you check this with 4.9 too?
<Unit193> Logan_: Awwwh, darn.  Right when I wanted to tell you about a cryptsetup upload you can't do. :P
<tvoss> doko, I haven't, yet
<Logan_> Unit193: wat
<Unit193> Good luck on cogsci.
<Logan_> thanks Unit :P
<Unit193> -_-
<Logan_> lol, I'll try to be a core dev eventually
<Logan_> a lot of people assume I am for some odd reason
<Logan_> but anyway, sleep
<Laney> hey pitti, it regularly breaks
<Laney> let me give it a kick
<pitti> Laney: FYI, I just added the xauth test dep to glib-networking's debian svn (I think that was discussed between you and seb128 yesterday)
<Laney> pitti: no, not discussed but I did add it to some other ones
<Laney> not that one though
<pitti> no 2.39.91 to package, though; I won't upload it just for that
<seb128> yeah, that can wait the next update
<Laney> those failures I only saw in Debian anyways
<pitti> Laney: ah, which ones were you looking at?
<Laney> glib and pango
<pitti> glib for sure
<pitti> ah, good
<Laney> I just forgot about -networking otherwise I would have added it there too
 * Laney goes to kick codesearch now
<pitti> Laney: can we sync pango1.0 from Debian, btw?
<Laney> there's a s/Breaks/Conflicts/ that I didn't do in Debian
<pitti> sid now has 1.36.2, we have 1.36.1-0ubuntnu1
<Laney> but I have an FFe in for that version
<Laney> (as it adds the new tests package)
<pitti> an FFE for a new test? ugh :)
<Laney> should be easy, maybe somebody looked at it already
<Laney> pitti: hm, what search didn't give you results? http://162.213.35.4/search?weighted=1&q=org.gnome.Shell works here, for example
<Laney> also, whoops
<Laney> @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: Laney
<pitti> Laney: I tried on http://ubuntu-codesearch.surgut.co.uk/
<Laney> should be the same
<pitti> Laney: but indeed it seems to work again; this morning it immediately returned with "no search results" for anything I threw at it
<Laney> ah
<pitti> slangasek, cjwatson: so http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect is indeed working again, that should answer the "undeclared reverse depends"?
<darkxst> hey Laney, pitti
<pitti> hey darkxst
<darkxst> Laney, can you look at https://code.launchpad.net/~darkxst/gnome-themes-standard/3.12-backgrounds
<Laney> darkxst: hey, sure
<jodh> pitti: re sbuild dep8 on ppc64el - looks like the lxc config is still missing the required 'lxc.aa_profile = ...' for mounting /proc.
<pitti> jodh: yes, I was just about to look at that
<pitti> jodh: I'm using stgraber's adt profile, but this needs some modifications
<pitti> jodh: I'll test it on one machine, and if it works, roll it out to all ~ 10
<jodh> pitti: thanks!
<pitti> jtaylor: FYI, the recent ipython failure seems to be an autopkgtest bug, with having multiple tests create artifacts; I'll look into that
<seb128> doko, hey, did you see 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" [Undecided,Confirmed]
<pitti> jodh: yay, works locally
<pitti> jibel: ^ see above bug, that's the one you mentioned an hour ago
<pitti> really unnerving bug
<Laney> yeah, not sure why we took the new bash... I didn't see an FFe for it.
<xnox> happyaron: cjwatson: ibus-pinyin android-db is removed and replaced by a dependency on libpyzy (commit by chromium.org person upstream). adjusted the seeds appropriately for the three seeds that seeded -db-android, it's not needed anymore as far as i can tell.
<seb128> Laney, yeah, that update looks not trivial and should have got a ffe imho
<xnox> happyaron: src:libpyzy should generate it? hm. ok.
<jodh> pitti: sbuild => yay! :)
<pitti> jodh: c'est vert! https://jenkins.qa.ubuntu.com/job/trusty-adt-sbuild-ppc64el/9/
<pitti> jodh: hah,  snap
<jodh> pitti: :)
<pitti> jodh: armhf still running
<xnox> happyaron: yeah, you are right, i should revert my seed changes.
 * jodh crosses ahem, arms...
<seb128> xnox, are you doing the 2 sides of the conversations yourself? ;-)
<seb128> xnox, or just going through night backlog and commenting as you go?
<xnox> seb128: yes, yes indeed the latter one. former one sounds bipolar.
<xnox> seb128: i don't think i'm bipolar.
<seb128> ;-)
<darkxst> Laney, thanks
<Laney> no problemo
<pitti> jodh: aaand success! https://jenkins.qa.ubuntu.com/job/trusty-adt-sbuild-armhf/9/
<pitti> jodh: thanks again
<jodh> pitti: phew. np :)
<Laney> @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:
<seb128> Laney, going close from 40, good job!
<cjwatson> seb128: IIRC I added _removable to "click list --manifest" for something you were doing (system settings?).  Do you remember where the code that uses that is?
<cjwatson> seb128: I'm wondering whether existing users would tolerate it being a JSON boolean instead, or if I need to keep it as an int for compatibility
<cjwatson> (I must have been drunk the day I made that be 0/1, or something)
<seb128> cjwatson, hum, that doesn't ring a bell, what is _removable doing?
<cjwatson> It indicates whether this particular version of the package can be removed, as opposed to a preinstalled version
<cjwatson> Maybe it wasn't you then, I'll look elsewhere.  Could've been the scope ...
<cjwatson> ./src/click-interface.vala:130:        const string REMOVABLE_FIELD = "_removable";
<seb128> yeah, shouldn't be us
<cjwatson> ah, there we go
<cjwatson> get_int_member.  I guess I'll leave it alone
<seb128> cjwatson, https://code.launchpad.net/~alecu/unity-scope-click/prevent-non-removable/+merge/188616
<cjwatson> Yeah, I dug it up eventually
<cjwatson> Thanks
<seb128> (click is not an easy name to google for :p)
<seb128> yw ;-)
<cjwatson> The name wasn't my idea ...
<davmor2> seb128, cjwatson: it gets worse when you type installing a click package, You get the first couple of pages of google play, amazon store and ios eventually
<cjwatson> Oh, mind you, get_boolean_member would map back and forth implicitly anyway
<davmor2> cjwatson: the most confusing thing seems to be that click has an install option but that's not how you install an app on touch grrrrrr :)
<sergiusens> cjwatson, are you planning on changing that?
<cjwatson> sergiusens: I was thinking of it just because it's ugly and I was rewriting that code anyway, but I won't do it if it actually breaks anything
<cjwatson> As it happens I'm pretty sure it wouldn't break the scope.  Do you know of other users?
<sergiusens> cjwatson, fwiw I'm not using it yet, but was planning to add it to a couple of packages
<sergiusens> so I can hold off until the change is made
<cjwatson> sergiusens: I would say, if you're writing anything new please be prepared for that field either being int or boolean
<cjwatson> sergiusens: if you're using json-glib, then get_boolean_member is AFAICS fine for this, it'll cope with the value being an int
<cjwatson> sergiusens: I probably won't change it for the moment just to minimise risk
<sergiusens> I'm only adding it to the manifest; not using them directly; and the click scope is where I believe the magic happens
<sergiusens> the merge request linked to seems from last year though
<sergiusens> I thought the scope was under a rewrite
<cjwatson> wait, you're not allowed to add that key to the manifest
<cjwatson> it's dynamically-generated
<cjwatson> and it has to be, because the same .click package might wind up being removable or not depending on the way it's installed
<cjwatson> click build will warn you and ignore the key if you try to add any manifest key starting with an underscore
<sergiusens> great; I was going to look at the docs again wrt this
<sergiusens> so this is a garbage collection thing or an uninstallable flag?
<sergiusens> seems only applied to garbage collection
<sergiusens> do we have anything for making it uninstallable?
<cjwatson> _removable basically means that the package is in a writeable location
<cjwatson> if it's preinstalled on a read-only fs, it's not removable
<cjwatson> the only real point in having a removable flag otherwise is to prevent people accidentally screwing themselves by say hiding the dialer app (because you can "remove" a preinstalled package by slapping a whiteout-style hidden flag on top of it)
<cjwatson> we don't have a flag for that right now, but it's possible.  I'm not sure that the manifest is the right place for that though; I think again it ought to be a property of how the package is installed rather than embedded in the package
<cjwatson> maybe
<sergiusens> a property on how it's installed is fine; and yes; use cases are dialer and friends as well as gallery and camera as they are default 'providers'
<cjwatson> making sure that people can always make emergency calls was the case I'd heard
<xnox> and i like that on android, i can revert to the stock version of the app.
<cjwatson> right, that's true on Ubuntu too
<xnox> so e.g. to unbreak my music app, i've cleared the data and "uninstalled" updates.
<cjwatson> I patterned that very loosely after experience on Android
<cjwatson> (I don't know if the scope exposes it, but it's definitely in place in click)
<xnox> i guess we just don't have ui to unhide pre-installed clicks yet, then.
<xnox> i guess "register that version for a user again"
<cjwatson> that would work though it's simpler to unregister the updated version
<cjwatson> remove => unregister pretty much
<xnox> right, i see.
<cjwatson> stgraber: https://code.launchpad.net/~click-hackers/click/trunk/+merge/209698 - please could you silo me up?  I'd like to try to squeeze this in before Qt 5.2 if possible
<cjwatson> stgraber: (and I have Ubuntu dual-booting on my phone now so testing should be less painful than my last attempt on a Nexus 7)
<cjwatson> stgraber: (never mind, getting Seb to do it)
<hallyn> smoser: hey look!  infinity mentioned my transmeta laptop.  "not widely deployed", he says.  pshaw!
<hallyn> d'oh
<hallyn> i misread email headers.  wasn't him.
<tkamppeter> xnox, hi
<xnox> tkamppeter: hey.
<tkamppeter> xnox, you tell in the Blueprint about printing that you have soved the Upstart/CUPS socket trigger problem, but I do not see any comment in the bug and nowhere a patch or fix.
<xnox> tkamppeter: https://launchpad.net/ubuntu/+source/cups/1.7.1-5ubuntu6 ?
<xnox> tkamppeter: http://launchpadlibrarian.net/168508764/cups_1.7.1-5ubuntu5_1.7.1-5ubuntu6.diff.gz
<tkamppeter> xnox, thank you very much. Can you comment on the bug report and, if appropriate, close the Upstart task?
<xnox> tkamppeter: i didn't remember there was a bug =) which one is that?
<tkamppeter> xnox, it is bug 1276713, also linked in the Blueprint.
<ubottu> bug 1276713 in upstart "upstart socket activation for cups" [Undecided,Confirmed] https://launchpad.net/bugs/1276713
<cjwatson> doko: do you desperately need https://launchpad.net/~ubuntu-toolchain-r/+archive/aarch64/+build/5665607 (on powerpc)?  I could use a powerpc builder ...
<doko> cjwatson, cancelled. please give it back when resources are available
<cjwatson> doko: thanks
<Laney> xnox: rsalveti: can we upload ubuntu-touch-meta for the gst split?
<Laney> I see it's committed but not uploaded
<Laney> wait one second, meta is attached to a landing
<rsalveti> Laney: yeah, probably mir
<Laney> https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/+packages
<rsalveti> Laney: but sure
<Laney> whyever are we adding gst-0.10?
<rsalveti> that's weird
<rsalveti> ogra: ^^
<Laney> is that because it's used by camera or something
<Laney> and those are going to click packages
<rsalveti> I believe it's used by gallery-app
<ogra> Laney, ask sergiusens, i only merged it
<rsalveti> yeah
<rsalveti> Depends: libc6 (>= 2.14), libcontent-hub0, libexiv2-12, libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libglib2.0-0 (>= 2.12.0), libgstreamer0.10-0 (>= 0.10.0), libmediainfo0 (>= 0.7.52), libqt5core5 (>= 5.0.2), libqt5gui5 (>= 5.0.2), libqt5qml5, libqt5quick5, libqt5sql5 (>= 5.0.2), libqt5widgets5 (>= 5.0.2), libstdc++6 (>= 4.1.1), gstreamer0.10-plugins-base, gstreamer0.10-plugins-good, qtdeclarative5-accounts-plugin, libqt5sql5-sqlite, qtdecla
<rsalveti> rative5-qtquick2-plugin, qtdeclarative5-qtmultimedia-plugin, qtdeclarative5-ubuntu-ui-toolkit-plugin, qtdeclarative5-ubuntu-ui-extras0.1 (>= 0.1+13.10.20130829-0ubuntu1), qtdeclarative5-window-plugin
<Laney> man oh man
<rsalveti> wonder if we can get that ported soon
<sergiusens> Laney, rsalveti correct, gallery requires it
<rsalveti> bfiller_afk: can we get someone to drop support for gst0.10 in gallery-app?
<rsalveti> better, just port to gst1.0
<tkamppeter> xnox, I have downloaded the fixed CUPS now, thank you very much.
<rsalveti> it uses gst0.10 and qtmultimedia
<rsalveti> which creates an issue for us
<rsalveti> because qtmultimedia still uses gst0.10
<rsalveti> but wonder if that is still really needed
<rsalveti> or if we could just use the mediaplayer-app to play videos or such
<xnox> tkamppeter: no problem, i was a pain to figure out. I've ended up writing a pure service in python3 and then in C and both worked, and then when i copied all of my stuff from C into early main() was when i realised that -F/-f both set "fg" variable with very diff semantics.
<xnox> s/diff/different/
<stgraber> @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: stgraber
<OdyX> xnox: it'd be nice to report the non-upstart specific cups bugfixes to cups.org
<OdyX> (as well as merging the upstart support code in Debian properly (on a branch that others can review before including) )
<xnox> OdyX: yes, after we shake it out. It only took 3 people and multiple attempts to get it at all do something useful.
<xnox> OdyX: plus it's still buggy in a few ways.
<xnox> OdyX: i'm planning to submit it, but at the moment, it's split across 3-4 messy patches.
<xnox> OdyX: my last one is on top of the stack of the others...
<OdyX> xnox: it won't be made easier as I did the same work for systemd in parallel
<xnox> OdyX: and the two are incompatible. since in upstart you get only one socket, and cups by default uses many sockets. thus while it is started up, it's only partially managed by upstart =(
<OdyX> xnox: with my latest patch iteration, cups manages it's socket configuration for systemd and then systemd wakes up cups on incoming connections on any of the sockets.
<pitti> bdmurray: hm, seems your gpg fix to software-properties wasn't sufficient?
<xnox> OdyX: that's the proper approach to do it. Where can I see those patches?
<bfiller> rsalveti: I think we've dropped it already when the MR to use libthumbnailer
<bfiller> rsalveti: let me check the MR
<xnox> OdyX: it wouldn't be quite easy to do with upstart as is, without me re-engineering the socket-bridge (essentially embedding one into cups =/)
<bdmurray> pitti: right, I've just uploaded a new version of gnupg and will sort out software-properties shortly
<pitti> bdmurray: splendid, thanks
<pitti> bdmurray: oh, something in gnupg itself regressed? interesting
<bdmurray> https://bugs.g10code.com/gnupg/issue1622
<Logan_> pitti: looks like it works now: http://ubuntu-codesearch.surgut.co.uk/search?weighted=1&q=laptop-detect
<pitti> bdmurray: right, just read the diff; it's an unexpected place to find a gnupg regression, but *shrug* nice :)
<pitti> Logan_: yep, seems Laney prodded it hard enough
<Logan_> :)
<tkamppeter> xnox, socket-activated CUPS works now. Thank you very much.
<xnox> OdyX: where is your systemd work / patches for cups?
<tkamppeter> OdyX, starting CUPS socket-activated works now via Upstart, too.
<tkamppeter> xnox, OdyX
<tkamppeter> xnox, OdyX' work is all on the Debian repo of CUPS, master branch.
<tkamppeter> xnox, not (yet) in Ubuntu CUPS, due to FF (or do we need an FFE here?).
<smagoun> seb128: Hey, I think you were working on the LIM changes for Nautilus? There is a regression in nautilus (and probably other apps). Each new window is smaller than the previous one, it looks like we're subtracting the height of a menu bar when we shouldn't be. I filed bug 1288855.
<ubottu> bug 1288855 in nautilus (Ubuntu) "Shrinking windows - each new window is smaller than the previous one" [Undecided,New] https://launchpad.net/bugs/1288855
<seb128> smagoun, hey, that's a compiz bug, Trevinho is working on it
<smagoun> seb128: oh, cool. Good to know
<seb128> Trevinho, if it's an easy fix you might want to just roll that one out and then get back to lockscreen and other things
<Laney> mardy: syncevolution is going up now
<xnox> tkamppeter: well. yes and no, only one of the three default sockets is upstart socket activated, and the other two are self-allocated by cups. And that's upstart socket activation limitation - it only triggers upon one socket, and only passes one socket to the daemon.
<seb128> smagoun, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1287472
<ubottu> Launchpad bug 1287472 in Compiz "compiz unnecessarily shrinks new windows" [Medium,Triaged]
<smagoun> i'll mark 1288855 as a dupe of 1287472
<seb128> smagoun, feel free, I marked it invalid on nautilus with a comment saying it's a compiz issue
<infinity> smagoun: Have you upgraded and logged out recently?  A bug not unlike that one was just fixed.
<seb128> infinity, it's a non fixed issue
<infinity> Okay, so it's not https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1282305 ?
<ubottu> Launchpad bug 1282305 in Compiz "Repeatedly undecorating and redecorating a window shrinks it vertically" [Medium,Fix committed]
<infinity> Just vaguely related, I guess.
<seb128> infinity, the previous one (which got fixed) was that windows were shifted by the decoration height
<infinity> seb128: The one you're referring to is 1282304 (I filed both), but smagoun's sounded more related to 1282305
<seb128> infinity, no, the new one is happening without hidding the decorations
<infinity> Ahh, fun.
<infinity> Kay.
<seb128> infinity, click on nautilus in the launcher, ctrl-W it, cycle
<seb128> and notice how nautilus shrinks
<tkamppeter> xnox, here is the /etc/init/cups.conf which I using successfully for tests. It starts once CUPS on boot, for the case that there are jobs or shared printers, if not cupsd stops after 30 secs, after that it is triggered on either localhost:631 or /var/run/cups/cups.sock and also stops after 30 secs of inactivity: http://paste.ubuntu.com/7045084/
<tkamppeter> OdyX ^^
<tkamppeter> xnox, OdyX: Changes are the "start on ..." rule and the added "-x 30" (30 sec timeout also when started on boot) in the cupsd command line.
<xnox> tkamppeter: next upstart release will have INET6 socket as well. I think there are corner cases, where it would fall apart. Let me test it here more.
<rsalveti> bfiller: cool, maybe we just forgot to remove that dependency from the control file
<rsalveti> which would be easy to fix :-)
<xnox> tkamppeter: as root: stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v  -> error bad file descriptor
<bfiller> rsalveti: we're testing it now on this branch: https://code.launchpad.net/~amanzi-team/gallery-app/gallery-app-sdk-thumbnailer/+merge/207222
<xnox> tkamppeter: thus imho this is fragile, and shouldn't be enabled by default. And only use socket-activation on the phone, via .override file for "start on" and "exec" stanzas only.
<xnox> tkamppeter: because we know that on phone we will not be cups-server / sharing printers.
<dholbach> pitti, infinity: if you're around... the CC is catching up with the TB in #u-meeting
 * pitti joins
<tkamppeter> xnox, if you could provide me an appropriate /etc/init/cups.conf would be great.
<xnox> tkamppeter: it should be reproducible (the bug) with yours cups.conf.
<tkamppeter> xnox, my simple test of the pasted cups.conf and not stopping and starting cups and socket bridge makes everything working for me.
<xnox> tkamppeter: correct. in a simple/common case it works. I'm showing the buggy behaviour that it has.
<xnox> sudo -i -c "stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v"
<xnox> sudo sh -c "stop upstart-socket-bridge; stop cups; start cups; start upstart-socket-bridge; stop cups; lpstat -v"
<tkamppeter> xnox, sorry, I want to say the following: I will upload cups 1.7.1-5ubuntu7 with your last fix plus some further (upstream for general stability, not Upstart socket) patches and it would be great that you then upload -5ubuntu8 with appropriate .override.
<tkamppeter> xnox, this would be great.
<xnox> tkamppeter: hm? all of my patches are uploaded into the archive as ubuntu6.
<xnox> tkamppeter: yeah, upload anything/everything that's needed, but don't change upstart job to auto-shutdown/be socket activated.
<xnox> tkamppeter: i'll do that on touch only.
<tkamppeter> xnox, and I have downloaded this and backported some upstream patches (for other bugs) and upload this as ubuntu7.
<tkamppeter> xnox, OK, I will upload ubuntu7 then.
<xnox> tkamppeter: gotcha. cool! =)
<tkamppeter> xnox, the bug you mention I can reproduce with my cups.conf.
<xnox> tkamppeter: ack.
<tkamppeter> xnox, ubuntu7 uploaded.
<tkamppeter> xnox, now, once I have reproduced the bug you mention, socket activation stopped working for me. How can I reset it.
<rsalveti> bfiller: cool, but this MP is still not removing the dependencies from debian/control
<bfiller> rsalveti: I know, it needs to be updated if all is working
<rsalveti> great
<xnox> tkamppeter: to recover - sudo sh -c "stop upstart-socket-bridge; stop cups; start upstart-socket-bridge; lpstat -v"
<tkamppeter> xnox, thanks.
<pitti> bdmurray: nice, fixed again; thanks!
<tkamppeter> xnox, OdyX, it seems that some apps need to get modified so that they do not keep a connection to CUPS open through the whole session and are not able to reconnect when CUPS has shut down while the app is still running.
<tkamppeter> xnox, OdyX, system-config-printer seems to have problems.
<xnox> tkamppeter: i hope I've done my bit, and don't have to work on that =)
<tkamppeter> xnox, I think so, too.
<xnox> tkamppeter: i daubt it will be the only issue, e.g. i can think of monitoring systems going crazy "cups is not there, oh wait it's not there, oh it's back again" set to flapping & tripping off sysadmins.
<xnox> tkamppeter: hence the siding to only ship socket activation on touch/mobile by default for 14.04, but keep working on enabling it by default.
<tkamppeter> xnox, OK.
<bdmurray> pitti: did you see my bug about apport and default browsers?
<pitti> bdmurray: yes, I did
<mapreri> pitti: I can't reproduce the issue -.- I also write a short pbuilder hook (http://goo.gl/exXIbN) to call adt after the build, but the tests now are always successful :S
<mapreri> what do you suggest to try now? I'm very new to autopkgtest, maybe I'm missing something...
<mapreri> (if you have time right now, of course)
<tkamppeter> OdyX, I have uploaded cups 1.7.1-5ubuntu7 to Ubuntu and also committed it to the Debian GIT, in the master-ubuntu branch. It has basically working (still with some bugs) Upstart-based socket activation support, the official upstream patch for supporting avahi-daemon restarts, and several patches backported from upstream for general stability. Perhaps you want to merger one or another patch to Debian.
<psusi> so I'm trying to debug a coredump and gdb bt just shows kernel_vsyscall, ??, ??, then stops saying previous frame is inner to this frame ( corrupt stack? ).  Is this just one really messed up core dump, or am I doing something stupid, like forgetting to install debug symbols...
<psusi> wait... is the current trusty kernel generating broken core dumps?  there was some sort of bug about that upstream
<Noskcaj> Laney, Thanks for the sponsoring
<seb128> Noskcaj, you need to get upload right for universes so you can help cleaning the queue ;-)
<Noskcaj> seb128, I want to. I'm thinking i might apply for MOTU again this month, since my timezone makes it impossible to apply after april 6th
<seb128> Noskcaj, you can apply by email if needed I think
<slangasek> Noskcaj: the calendar jumps straight from april 6 to Jan 1 in your timezone?
<Noskcaj> slangasek, 19utc becomes 5am
<slangasek> oh ;)
<slangasek> I thought there were provisions for applying by mail
<Noskcaj> seb128, That took 2 months and 2 irc meetings to be told i didn't have enough testimonials, so no
<seb128> Noskcaj, just a recommendation, you need to forward to Debian directly when the change apply to them (especially if we have no delta in Ubuntu)
<Noskcaj> seb128, I do, whenever possible
<sladen> Noskcaj: where's your list of testimonials, how 'lacking' is it---should be reasonably easy to solve...
<arges> bdmurray: hey, checking in. have you looked at the queue yet
<seb128> Noskcaj, it would also be nice if you followed up on bugs you create with your sync requests
<seb128> Noskcaj, https://launchpad.net/ubuntu/trusty/+source/cherrypy3/3.2.2-4ubuntu4 ... is was possible for example ;-)
<Noskcaj> sladen,  ... is was possible for example ;-)
<Noskcaj> crap
<Noskcaj> https://wiki.ubuntu.com/Noskcaj#MOTU
<Noskcaj> stupid irc copy/paste
<Noskcaj> seb128, That's been forwarded to debian i think
<Noskcaj> seb128, All the sync bugs that i've left are from some time ago and are because i lack the skills to fix the issue, so i wouldn't be making the bad syncs again
<seb128> Noskcaj, k, I was just mentioning it because that's the sort of think I would point in your wikipage if you asked me to write some feedback in it
<seb128> Noskcaj, https://code.launchpad.net/~noskcaj/ubuntu/trusty/cherrypy3/lp-463065/+merge/207852 ... I didn't notice it was commited to debian because there was no bug in the bts and no tag in the patch, you also didn't reply to my review comment until I changed the status 10 days later
<Noskcaj> seb128, ok. I'll look into the current rc bug for cherrypy3 so i can get an upload with the ubuntu delta gone
<seb128> Noskcaj, that's not the issue, we can carry a delta for that release, as long as the change is forward so we don't have to carry it forever
<Noskcaj> yep
<Noskcaj> the lack of response was because i had already done the changes in debian and had thought you'd merged it
<seb128> k
<seb128> ok, need to go
<seb128> bbl
 * lamont grumbles at bash completion... grep string file<tab> no longer completes - known?
<ChrisTownsend> lamont: Yes, very annoying.  Here is the bug: 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]
<lamont> ChrisTownsend: ta
<ChrisTownsend> lamont: np
<bdmurray> arges: no, I haven't yet
<arges> bdmurray: ok. I see some green ones
<bdmurray> arges: Why don't you focus on the queues and I'll look at the pending ones
<arges> bdmurray: sure
<arges> hallyn: hey I see two unapproved uploads of libvirt in the saucy queue. I think you just want the latest one. Is that right?
<hallyn> arges: yup.  everyone was scared off by teh first one :)
<arges> hallyn: cool thanks
<hallyn> thank you
<cjwatson> tedg: I'm working on the upstart-app-launch changes to make use of libclick, or at least the first batch of them, and was wondering if you could advise on testing
<cjwatson> tedg: the test for click-exec is going to need to tell libclick to use a different database directory, to replace the current scheme where it relies on tests/click being on $PATH
<tedg> cjwatson, Yeah. Or you can just mock out the libclick API.
<cjwatson> tedg: would it be OK to have click-exec check an environment variable and use a different DB dir if that env var is set?
<cjwatson> tedg: or would such a change have to be only compiled in while testing?
<cjwatson> I'd rather be able to test the as-installed click-exec binary if possible
<cjwatson> tedg: Yeah, I could mock it out, but it would be better to integration-test if possible I think
<tedg> cjwatson, I don't see any reason that would be an issue, we control the environment through Upstart. If someone can add environment variables to upstart it seems we're kinda screwed.
<cjwatson> tedg: Not least because I've just about had my fill of strange LD_PRELOAD hacks for this month
<cjwatson> tedg: Right, and it doesn't matter if somebody runs click-exec by hand?
<tedg> cjwatson, No, it's just set environment variables for their terminal :-)
<tedg> it'd
<cjwatson> OK, cool
<cjwatson> In that case I'll send you over the first branch tomorrow (just about done for today)
<cjwatson> A "click info" replacement isn't in place yet, so it's just "click pkgdir" for now, but I have a branch in progress for "click info" too
<cjwatson> Will hopefully speed things up a bit ...
#ubuntu-devel 2014-03-07
<derEremit> Hi all
<derEremit> should ubuntu webapps like http://developer.ubuntu.com/web/overview/
<derEremit> still work in trusty
<derEremit> i get: Proxy: getUnityObject called with version 1
<derEremit> Uncaught Error: not enough arguments
<derEremit> in unity-api-page-proxy-builder-gen.js
<sarnold> pitti: are the trusty retracers alive and well? this bug report has been waiting for retracing for seven hours: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1288852
<ubottu> Error: launchpad bug 1288852 not found
<derEremit> ok, tested in firefox also, used to work, now i get the message if i would like to add integration but then nothing happens
<derEremit> https://bugs.launchpad.net/unity-chromium-extension/+bug/1277126
<ubottu> Launchpad bug 1277126 in WebApps: unity-chromium-extensions "Latest chromium update breaks webapps integration" [Critical,Confirmed]
<derEremit> can someone confirm that it's also broken in firefox on trusty
<doko> infinity, is the chromium-browser autopkg test really still running, or could you override it?
<teward> The MIR checklist points to liblua5.1 as bad...  Am I to assume that includes other non-Lua Lua compilers as well (like luajit), or no?
<RAOF> teward: You're talking about the ngnix MIR? If so, it's that liblua5.1 isn't supported (liblua5.2 is). So if there is another Lua runtime in the supported seed that the ngnix lua module works against then that would be acceptable.
<teward> RAOF: you've avoided my actual questoin
<teward> if you've read the nginx MIR, you'd see sarnold already explained this
<teward> and that sarnold and infinity explained this to me in this channel even
<teward> you've ignored my actual question, which is, does this also include other Lua interpreters not provided by libljuaX.Y (where X and Y are numbers)
<teward> (such as libluajitX.Y)
<RAOF> I'm still not sure what your question is, sorry.
<teward> then i'll wait for sarnold
<teward> or, unless you want me to talk for a bit?
<teward> (explain the background of this, really)
<RAOF> Sure.
<teward> the third-party Lua module is part of the non-main packages (nginx-extras).  It requires Lua 5.1, or an interpreter that speaks Lua 5.1.  The upstream for that module have already looked and said that it will not be able to build ever against 5.2
<teward> and that they will not support 5.2 either
<teward> they did suggest either static-linking against 5.1, or try something like LuaJIT instead
<teward> problem is, I have no idea if LuaJIT is supported or not, nor if that conflicts as it too speaks 5.1
<RAOF> Ah.
<teward> my question is whether, IF this builds against libluajit-5.1-dev... would that be satisfactory
<teward> because the only other alternative is to drop the lua module
<teward> (which won't exist in nginx-core, the package that would end up in main, anyways.)
<RAOF> libluajit-5.1-dev is also in universe, so ngnix couldn't build-depend on it.
<teward> the moment of truth is right now, RAOF, i'm sbuild-ing this.
<teward> RAOF: then the MIR is permanently blocked and I may as well just reproduce a separate source package for nginx-core
<teward> because we'd *have* to drop Lua and everyone else will be... um...
<teward> "extremely dissatisfied"
 * teward yawns
<teward> i should not be working on code at 9:10PM but meh
<RAOF> Heh.
<teward> it looks like it builds either way, but meh
<RAOF> Why does the lua module not support the ~2 year old Lua 5.2 release? (/me doesn't have any real domain knowledge here)
<teward> RAOF: ask the upstream people
<teward> https://github.com/chaoslawful/lua-nginx-module/issues/343
<teward> RAOF: what I think could be a satisfactory solution is to drop the Lua module from the package, then burn the bridges behind us, as i'll still maintain the PPAs anyways
<teward> and I assume liblua5.1 will still exist in trusty even though it's not going to be supported in trusty?
<RAOF> Yeah, it's unlikely to be removed.
<RAOF> Also, it sounds like Lua is a terrible choice for an embedded language? The language significantly changes between Lua 5.1 and Lua 5.2?!
<teward> that's what sarnold and infinity said
<RAOF> :)
<teward> RAOF: if it's unlikely to be removed from Trusty, then that should still suffice, the people who need Lua can go use the PPA version which I will continue to maintain anyways
<teward> while still satisfying the MIR requirements by dropping the lua module
<teward> 'course, i'd like sarnold and rbasak to voice their opinions on that solution
<RAOF> teward: Sounds reasonable. You could also ask if libluajit is MIR-able.
<RAOF> teward: Since it seems like that's actively maintained upstream?
<teward> RAOF: that's outside my purview :/
<RAOF> Which would be one of the problems with liblua5.1; last release seems to be in 2012.
<teward> RAOF: my... preference... would be to just maintain things that DON'T require additional maintenance
<teward> but that's Debian's decision to add it
<teward> not mine
<RAOF> teward: Well, you should mention that it builds (and runs?) against libluajit-5.1-dev, and that libluajit is maintained upstream.
<teward> RAOF: all testing in due time
<teward> it's still building in sbuild (i386; amd64)
 * teward doesn't test-build for other architectures
<teward> it *looks* like it builds
<teward> but i don't use the lua module so meh
<teward> the question is if it starts
<teward> if it does without SEGV then meh
<teward> hmm, where the heck did my trusty VM go
<teward> RAOF: any idea where i can get a trusty image?
<teward> :/
<teward> my VM exploded itself :/
<RAOF> teward: The autopkgtest build scripts pull a cloud VM image...
<pitti> Good morning
<Unit193> Howdy.
<fishor> slangasek, so far i know pipeligt will add symlink in plugins directory and it uses NAPI interface
<fishor> i can't say more, since i have no more idea then you. Everything i know, wine will start together with update manager if firefox was not previously started
<fishor> slangasek, hm... right now i can reproduce it only with empathy, not with update manager.
<doko> jibel, pitti: need to get gcc-4.8 into trusty, chromium-browser autopkg test still running
<pitti> doko, jibel: fixing the history files
<pitti> doko: FYI, jibel is working on fixing this for good
<jibel> pitti, done
<doko> pitti: and the other thing I'd like to see migrating is readline6, independent of the python3.4 autopkg test
<doko> and then starting the test rebuild
<tkamppeter> Anyone with knowledge about Debian package download servers around?
<pitti> jibel: I edited trusty-proposed_amd64_chromium-browser.20140306-174838.state and results.history, that right?
<jibel> pitti, it is
<pitti> doko: right, the python3.4 failure looks like a problem with the new python3.4 itself, not due to libreadline
<xnox> tkamppeter: what are you after?
<pitti> jibel: can we forge this in the history file? the release team AFAIK can only override the python3.4 test itself, not just that test result for libreadline
<pitti> python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1
<pitti> python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1 readline6 6.3-1ubuntu1
<pitti> jibel: ^ i. e. set it to PASS in the second line, but keep the first?
<jibel> pitti, 3661:python3.4 3.4~rc2-1ubuntu1 FAIL python3.4 3.4~rc2-1ubuntu1 readline6 6.3-1ubuntu1
<jibel> line 3661
<pitti> jibel: I set l 3661 to PASS, keeping the FAIL for python3.4 itself
<pitti> doko: ok, should be set; I'll check britney in ~ 30 mins
<jibel> pitti, correct
<tkamppeter> znox, at Epson they have .deb packages of printer drivers, for auto-download with apt-get. Now the guys are complaining that on their server are too may 404 errors (900000/day) and this is slowing down the server, the problem seems to happen with http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/main/i18n.
<doko> thanks!
<pitti> err, what, znox? is there an ynox as well, putting Dimitry into all three dimensions?
<tkamppeter> xnox, ^^^
<pitti> (TGIF!)
<xnox> tkamppeter: yeah, that's a known problem, so apt does query translation files of package data thus generating a tonne of 404s queries. I think on launchpad ppas it was suggested to short-circuit queries to i18n paths and return 404 to client on frontend without hiting the disk.
<xnox> tkamppeter: or on the repository side, generate empty files there (or some such) such that apt "caches" them and thus does not request/404 them all the time.
<xnox> maybe wgrant can give better advice here.
<OdyX> tkamppeter: the good solution to that is to release this as redistributable and let good packagers distribute that in the distibutions properly
<tkamppeter> wgrant, hi
<OdyX> tkamppeter: I'd not even request full source, just redistributability (for non-free)
<xnox> tkamppeter: wgrant is end-of-week by now, he is in Australia.
<OdyX> tkamppeter: get Epson fix their license please: https://lists.debian.org/debian-legal/2012/12/msg00011.html
<OdyX> (if you're talkin to them)
<tkamppeter> xnox, would it be enough to create an empty http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/main/i18n/Translation-en file?
<xnox> tkamppeter: i think it should be. to test mirror that repository to /var/www/html and try out against local apache at 127.0.0.1 and check the logs =/
<tkamppeter> xnox, I am trying with the OpenPrinting web server now, which was also missing this directory, and it seems only adding the empty i18n directory makes "sudo apt-get update" faster.
<pitti> doko: both propagated now
<wgrant> tkamppeter, xnox: This really needs a fix in apt to not blindly try to download every possible translation.
<wgrant> It currently tries to fetch Translation-en.xz, then that 404s so it tries Translation-en.lzma, Translation-en.bz2, Translation-en.gz, Translation-en, then it finally gives up
<wgrant> I don't know how to make it stop
<wgrant> Translation-* really should only have ever been looked at if they appeared in an index.
<tkamppeter> wgrant, so for best server performance I should create empty Translation-en.xz in all i18n directories on the servers?
<wgrant> tkamppeter: Plus Translation-$LANG.xz for each possible client language :/
<wgrant> It's possible that apt will use TranslationIndex if it's there, but I believe it's deprecated.
<wgrant> Possibly it'll now check if there's any Translation-* at all in Release?
<wgrant> That would seem like a reasonable thing to do in future, even if that's not the current behaviour.
<tkamppeter> wgrant, I hope that this does not cause all deb servers on the world hanging in 404s most of the time.
<wgrant> tkamppeter: It causes serious delays on HTTPS apt repos, but for unencrypted HTTP it's not usually too bad.
<wgrant> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1171047
<ubottu> Launchpad bug 1171047 in apt (Ubuntu) "update-manager times out checking for updates" [High,New]
<mwhudson> are the estimated 14.04.X point release dates listed somewhere?
<xnox> mwhudson: not that i see at https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
<mwhudson> right
<xnox> mwhudson: maybe it makes sense to have vUDS session to discuss it.
<mwhudson> that might be overkill
<mwhudson> also vuds is entirely inhumanely timed for me :)
<mwhudson> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule has point releases every six months, starting the august after release
<tkamppeter> wgrant, xnox, thank you very much.
<xnox> mwhudson: true, but it kind of depends on the .1 timing. Precise .1 was much longer than usual.
<xnox> mwhudson: imho lts point releases should be at .7/.1 cadence - half-way between .4/.10 cadence.
<Laney> Compared to Hardy it was, but it was broadly the same as Lucid
<mwhudson> xnox: ok
<xnox> Laney: hardy was a good release, i liked it a lot. =)
<Laney> it did have the best t-shirt
<jamespage> mwhudson, I quite liked what the Ceph Developer Summit did
<jamespage> they had one day that was better timed for APAC
<infinity> mwhudson: I need to update the release schedule, but the theory is for point releases to be every 6mo, starting at ~3mo after release.  I don't think we need a UDS session for that.
<mwhudson> infinity: coolio
<infinity> mwhudson: Exact dates are a bit more flexible than normal releases, but the aim is to make sure they're well out of sync with normal releases, since it's the same people/resources.
<mwhudson> that makes sense
<mwhudson> so 14.04.2 might have the same kernel as 14.10, say
<infinity> mwhudson: .2 will be the 14.10 kernel, .3 will be the 15.04 kernel, etc.  That's set in stone.
<xnox> mwhudson: why "might"? it will, cause hwe packs start with .2 releases.
<mwhudson> xnox: i don't know if .2 could use a newer kernel or something like that
<mwhudson> but apparently i am wrong :)
<diwic> pitti, hi, is usb-creator working for you in 14.04? It fails to both erase and create here.
<pitti> diwic: I don't know off-hand, it's been some time since I used it
<pitti> diwic: yes, erase fails with
<pitti> WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util sfdisk doesn't support GPT. Use GNU Parted.
<diwic> pitti, ok, do you think I should do anything about it (except filing bug 1289269 )
<ubottu> bug 1289269 in usb-creator (Ubuntu) "Hangs while erasing disk" [Undecided,New] https://launchpad.net/bugs/1289269
<diwic> pitti, okay, then we have at least three bugs :-/
<pitti> oh, it doesn't hang here
<pitti> this is an USB stick which I previously dd'ed the current image on
<pitti> so supposedly that's how it got a GPT table
<GunnarHj> Hi pitti!
<pitti> hey GunnarHj
<GunnarHj> pitti: I tend to think that the request in bug 1288843 is reasonable, even if there is a lack of official sources that support it. t_fmt_ampm is not normative in the same way as d_t_fmt and t_fmt, so as long as we set t_fmt_ampm without touching the other two it should be ok IMO.
<ubottu> bug 1288843 in langpack-locales (Ubuntu) "AM/PM string missing on Spanish locales" [Undecided,New] https://launchpad.net/bugs/1288843
<popey> grr. twice today my x220 has locked up completely.
<pitti> GunnarHj: yeah, maybe; I still like at least some semi-official references, like in major newspapers; I'm not sure how much proof upstream wants these days
<GunnarHj> pitti: Historically they have been pretty picky, as you know much better than me. ;-)
<pitti> GunnarHj: yes, but glibc maintainers changed a while ago
<GunnarHj> pitti: But from a user perspective the result is not good: The UI offers the option to set 12h clock format, and it fails.
<pitti> GunnarHj: yeah, that's certainly a bug in the config UI
<pitti> GunnarHj: which should be fixed anyway; but I'm not opposed to adding some AM/PM format if there is some proof that whichever format is proposed is widespread and not just the knee-jerk invention of the reporter
<GunnarHj> pitti: Or in the locales, depending on how you choose to look at it...
<pitti> GunnarHj: well, e. g. in German there is no official format for AM/PM, so you couldn't "fix" it there
<pitti> and inventing some incomprehensible abbreviations which nobody else understands doesn't help either
<pitti> so it ought to be a wide-spread and recognizable format
<GunnarHj> pitti: In this case there is a history of older bugs with some references. But I'll ask for references on this new bug.
<pitti> i. e. if major newspapers/news sites/governmental sites use it, it's ok
<pitti> GunnarHj: if we have some in dupes, that's fine of course
<GunnarHj> pitti: dupes?
<pitti> GunnarHj: or whatever you meant with "older bugs"?
<GunnarHj> pitti: Aha.
<pitti> GunnarHj: "dupes" == "duplicate bugs"
<GunnarHj> pitti: Got it now. ;-)
<cjwatson> xnox: Did you ever submit upstart-app-launch merge proposals for the changes you uploaded directly?
<xnox> cjwatson: no, i don't think so.
<xnox> cjwatson: looks like there were two. Should i make a manual branch with changelog/changes, or can ci-train sync up trunk at all?
<cjwatson> xnox: Would you mind?  I have some upstart-app-launch changes I want to land myself, and that'll need to be sorted out
<xnox> ok.
<cjwatson> xnox: I'm not sure about changelog, you'd need to ask somebody who knows about ci-train
<seb128> cjwatson, xnox: bonus point if you include the changelog in the mp, if you don't there is an option to force publication over it though
<seb128> the "force publication option" would mean your changelog entry would be dropped of course
<xnox> cjwatson: seb128: well, pushed this https://code.launchpad.net/~xnox/upstart-app-launch/sync-archive/+merge/209908
<xnox> cjwatson: maybe set that one as pre-requisite and/or rebase on top of it?! (not sure)
<cjwatson> xnox: I don't need to set it as a prereq, it'll be fine
<cjwatson> xnox: Thanks
<bonafide> Hallo, ich versuche meine Wiimote mit meinem PC zu pairen, aber bekomme immer  eine Fehlermeldung. Was kann ich tun?
<bonafide> Sorry, I tried to pair my Wiimote but all I get is a error message. Bug is already reported. What can I do?
<mdeslaur_> @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: stgraber, mdeslaur_
<bonafide> Sorry, I tried to pair my Wiimote but all I get is a error message. Bug is already reported. What can I do?
<bonafide> Im on Ubuntu 12.04.4. The error message is: "Setting up 'Nintendo RVL-CNT-01' failed"
<ScottK> cjwatson: I've run into a conundrum about clamav on ppc64el and I think that removal may be appropriate.  In the last upload, I fixed a bug that had caused the test suite to not run since before the first ppc64el build and discovered it fails on (only) ppcd64el, giving me an impression that the ppc64el binaries don't actually work.  I've no idea how to deal with fixing it (nor hardware to test) and so I think removing the binary so it can
<ScottK> migrate might be appropriate since I don't see it as a real regression.  Thoughts?
<ScottK> Build log if you're interested: https://launchpadlibrarian.net/168490729/buildlog_ubuntu-trusty-ppc64el.clamav_0.98.1%2Bdfsg-2ubuntu1_FAILEDTOBUILD.txt.gz
<cjwatson> ScottK: I'm OK in principle but there are several reverse-deps
<cjwatson> clamsmtp, dansguardian, havp, libc-icap-mod-virus-scan, libclamunrar6, proftpd-mod-clamav, python-pyclamav
<cjwatson> that seems like rather a lot to rip out
<cjwatson> if you have any guesses I could puppet for you on an internal porter box?
<ScottK> cjwatson: The only thing comes to mind is if you can go back and look at the diff for the last Hardy uploads, I had to disable (I think) the same functionality that is failing here, so an arch specific build option might be in order.  Other than that, no ideas at ail.
<ScottK> I'm looking for it
<ScottK> Here it is.
<ScottK> ifeq ($(DEB_HOST_ARCH),lpia)
<ScottK>   export enable_llvm=no
<ScottK> endif
<ScottK> cjwatson: ^^^ with lpia/ppc64el, of course.
<ScottK> Put that right before config.status: configure
<cjwatson> ScottK: ok, give me a minute to make sure I can reproduce the failure
<ScottK> OK.  Good luck.
<cjwatson> ScottK: Sorry for the delay; I was called away for urgent childcare.  That change fixes the build.
<ScottK> No problem.  I know how that goes.
<ScottK> cjwatson: Please go ahead and upload then.
<cjwatson> ScottK: Done.
<ScottK> Thanks.
<pitti> xnox: you synced python-apt, right? would you mind terribly if I remove it again? it introduces regressions (like bug 1288171) and thus I can't land a new apport
<ubottu> bug 1288171 in python-apt (Ubuntu Trusty) "0.9.3 regression: Setting APT::Architecture now downloads wrong indexes" [High,New] https://launchpad.net/bugs/1288171
<pitti> remove from -proposed, I mean
<ScottK> Since llvm itself FTBFS on ppc64el, I guess it's no surprise the embedded code copy in clamav didn't work either.
<xnox> pitti: yeah, remove it. there aren't any pressing changes that we need from 0.9.3 to be honest.
<pitti> xnox: ack; i. e. this was mostly a "no remaining Ubuntu changes" sign?
<xnox> pitti: yeah.
<pitti> xnox: ack, thanks
<marcoceppi_> So, I'm attempting to patch 1223229 and I've submitted this patch to the precise package which is the only release of Ubuntu affected by the bug, https://code.launchpad.net/~marcoceppi/ubuntu/precise/charm-tools/lp1223229/+merge/209542
<marcoceppi_> is there anything else I need to do for this? like ping someone or request somethign from somewhere
<pitti> marcoceppi_: no, it's in the sponsoring queue
<pitti> marcoceppi_: well, you need to set up the bug for SRU, i. e. add rationale and testing instructions
<pitti> marcoceppi_: and it needs to be a public bug
<marcoceppi_> pitti: cool, can do
<ScottK> cjwatson: Is there a porters page or something for ppc64el where it might make sense to make a note that if someone fixes llvm on ppc64el, they should look at re-enabling it in clamav too?
<mdeslaur_> @pilot out
<mdeslaur_> udevbot: wake up
* mdeslaur_ 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: stgraber
<bdmurray> seb128: could you have someone look at bug 1289202?
<ubottu> bug 1289202 in thunderbird (Ubuntu) "archive function does not always work - regression" [Undecided,New] https://launchpad.net/bugs/1289202
<seb128> bdmurray, tb issues in stable series are security's team
<seb128> jdstrand, chrisccoulson: ^
* 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: stgraber
<udevbot> Error: "wake" is not a valid command.
<jdstrand> seb128: I assigned to chrisccoulson. He'll take a look as part of the next update
<seb128> jdstrand, thanks
<cjwatson> ScottK: I'm not sure; infinity might know
<jamespage> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jamespage> bug 1280941
<ubottu> bug 1280941 in tripleo "metadata agent throwing AttributeError: 'HTTPClient' object has no attribute 'auth_tenant_id' with latest release" [Critical,In progress] https://launchpad.net/bugs/1280941
<jamespage> the latest 2013.2.2 release has a problem with the neutronclient we have in saucy
<jamespage> not picked up during testing
<jamespage> (obviously)
<jamespage> upstream fix for neutronclient: https://github.com/openstack/python-neutronclient/commit/02baef46968b816ac544b037297273ff6a4e8e1b
<infinity> jamespage: So, erm... What regression is this?
<infinity> jamespage: saucy only has one version of python-neutronclient ...
<infinity> Oh, it's neutron itself that broken neutronclient.  Check.
<jamespage> yes
<jamespage> the fix we need is in neutronclient
<infinity> jamespage: So, can you get a quick neutronclient SRU up that has nothing but the one cherrypick?
<jamespage> infinity, zul is working on it right now
<jamespage> ivoks, fyi ^^
<infinity> How much working on it can there be?  Looks like a 10 second job. :)
<jamespage> infinity, well it takes on TL to run around flapping while zul does the actual work right ?
<infinity> jamespage: Heh.
<jamespage> :-)
<ivoks> jamespage: thanks
<jamespage> ivoks, hey - I'm just making noise - zul's doing the work
<ivoks> zul: we are waiting :)
<ivoks> jamespage: it's not to see noise getting escalated :D
<ivoks> s/not/nice/
<jamespage> lol
<infinity> jamespage: Anyhow, if someone gets something in the queue that looks like it matches that upstream commit, byte-for-byte, I'll review and accept.  I may or may not be around at a convenient time to do an expedited release to -updates after you guys have put it through a bit of testing (flying around the world this weekend), but feel free to find another SRU team member, or even another AA and say "Adam said this is cool as long as we prove we ...
<infinity> ... tested it".
<ivoks> i've tested it
<infinity> ivoks: The package.  You can't have tested the package.  Just saying.
<ivoks> yeah, that's true
<ivoks> i've tested upstream commit
<ScottK> We need the package tested.
<ivoks> yup, i know
<ivoks> ScottK: and i'll test it as soon as it's available
<ivoks> i have broken deployment already prepared for this test
<infinity> Perfect.
<jamespage> nice having a pre-prepared test bed for this
<stgraber> @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:
<zul> jamespage: just doing a local build before uploading
<jamespage> zul, good-oh
<jamespage> zul, I raised a task for bug 1280941
<ubottu> bug 1280941 in tripleo "metadata agent throwing AttributeError: 'HTTPClient' object has no attribute 'auth_tenant_id' with latest release" [Critical,In progress] https://launchpad.net/bugs/1280941
<zul> jamespage: ok just uploaded
<ivoks> zul: jamespage infinity please ping me when it's ready for testing
<jamespage> infinity, its in the queue
<infinity> Wrong bug ref...
<infinity> zul: That should be 1280941, not 1277120
<zul> infinity:  please reject and ill reupload
<infinity> Go ahead.
<ivoks> zul: bug number?
<ivoks> zul: same as upstream?
<zul> done
<infinity> zul: Accepted.
<zul> infinity:  cool thanks
<infinity> zul: (For future reference, you don't have to upload to $series-proposed anymore, $series works just fine and lands in the right queue)
<Nafallo> hey :-)
<zul> infinity:  ok cool
<Nafallo> I found a patch against net-snmp to add btrfs support to hrFSTable. would it be to late for the next LTS? :-)
<infinity> Nafallo: File a bug?
<Nafallo> I can do that.
<xnox> ogra_: if you are about still, is the ubuntu-touch-meta that landed 20h - actually in fact really old build? cause it's out of date =/
<ogra_> which version ?
<Laney> yes it is
<xnox> ogra_: https://launchpad.net/ubuntu/+source/ubuntu-touch-meta/1.109 landed 20h into release pocket.
<Laney> it was put into the silo ages ago and then released from there
<xnox> i see.
<ogra_> xnox, it landed 20th in the PPA
<xnox> ogra_: Laney: what do I need to do to kick off ubuntu-touch-meta refresh?
<Laney> do it normally
<ogra_> the seed change is not relevant anymore and needs adjustment as well, but for the sake of a green image it wasnt done yet
<xnox> ogra_: what do you mean? is r151 which landed is bad? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty
<xnox> ogra_: what needs adjustment?
<ogra_> driving the seeds through the CI train is really awkward too ... not sure how we can prevent them from going out of sync
<ogra_> xnox, no, not bad, but we want to get rid of gst 0.10 at some point ... sergiusens and rsalveti have that in their hands
<ScottK> Not everything that uses it has a 1.0 port though.
<rsalveti> yeah, once gallery-app drops support for it
<ogra_> well, only the gallery app in our case
<rsalveti> right, but at least in touch we don't plan to support anything using 0.10
<rsalveti> as that will not use any hw decoder
<xnox> ogra_: ScottK: rsalveti: i think we all know that we have both gstreamers still on the desktop, on touch, in main and everywhere.
<xnox> ogra_: gst is not the problem, you made it sound as if the seed is somehow broken at the moment.
<ogra_> xnox, well, on touch only gallery app kepps it
<ogra_> xnox, why do you care ?
 * ogra_ didnt mean to make it sound as if anything was broken ... i simply said we will roll parts of the seed change back 
<xnox> ogra_: i care about landing ubuntu-touch-meta refresh to drop a load of libraries.
<ogra_> hmm
<rsalveti> xnox: hey, on a different topic, what is the current state of the i686 android toolchain you were building?
<ogra_> xnox, did you coordinate that with didrocks
<xnox> ogra_: which depend on gtk and don't do anything.
<ogra_> he is anxiously waiting for a 100% image
<xnox> ogra_: hm.... libraries that use X server, which is not running, are cruft =)
<ogra_> xnox, well, as long as you run the testsuite with them removed
<xnox> ogra_: sure!
<ogra_> (i wouldnt trust that all deps in our upstream apps are 100% fine)
<justCarakas> is there already something in place for an HTML5 app as datepicker or timepicker ?
<infinity> jamespage: I'm going to catch some sleep.  If I wake up and discover that SRU has been verified but not released, I'll push it out.
<jamespage> infinity, thanks - testing now
<jamespage> I was able to reconfirm the regression - now testing the fix
<infinity> You shouldn't have a hard time finding someone in a sane NA timezone to release it while I nap, though. :)
<jamespage> ivoks, its in proposed (saucy)
<jamespage> ivoks, I reproduced and then tested OK
<hallyn> oh, i see.  bash completion no longer works with ~ expansion
<hallyn> i.e. "ssh-add ~/.ssh/i<tab>" shows nothing
<ivoks> jamespage: ok
<sergiusens> ogra_, xnox  the gst drop is in a branch bfiller_afk and his team are working on (related to the new thumbnailer) (cc rsalveti)
<jamespage> ivoks, I'd like to run the full smoke test run against it before we release - should take about 1 hr
<rsalveti> xnox: sergiusens: https://code-review.phablet.ubuntu.com/#/c/206/
<rsalveti> xnox: that should hopefully fix the amd64 ftbfs for the i686 androideabi toolchain
<xnox> rsalveti: ok, i'll rebuild the toolchain and check it out. if it's good i'll upload it into the archive.
<xnox> rsalveti: however, it still doesn't do SSP properly thus the image needs to be compiled with -fno-stack-protector, which is quite bad as well.
<xnox> rsalveti: didn't sort out that second problem yet.
<rsalveti> xnox: right, no worries
<mhall119> what's the process for getting a package *removed* from Universe?
<cjwatson> file a bug on it, subscribe ubuntu-archive
<cjwatson> give a good reason
<mhall119> thanks cjwatson
<mhall119> "it's incompatible with it's dependencies" is a good readon
<cjwatson> don't give the reason here :)
<mhall119> ok, I'll see if I can fix/update it over the weekend, but otherwise I'll file for it to be removed
<mhall119> cjwatson: so the package in question is qimo-session, which in 2.x uses a modified Xfce session, but in 3.x will use a modified Unity session, which means there is a drastic change in dependencies for that package, is it okay to just change the Depends or do I need to do something to let the user know that such a big change is happening?
<ivoks> jamespage: ok
<mhall119> it's probably not relevant, because I don't think qimo-session worked in 12.04 either
<jtaylor> someone know the url of the branch the gcc packages are based of?
<ivoks> jamespage: zul ScottK infinity verification done
<slangasek> hallyn: hey, so I tried to do a test build of your qemu 2.0~pre packages on powerpc, and got this error; is this something you could take a look at? http://paste.ubuntu.com/7051684/
<slangasek> hallyn: (we have a powerpc porter box again, so should be easy :)
<zul> ivoks:  excelente
<jtaylor> oh found it, the vcs browser has more than one page
<slangasek> hallyn: in fact, might be as simple as dropping debian/patches/ubuntu/target-ppc-add-stubs-for-kvm-breakpoints, which may be double-applied?
<hallyn> slangasek: hm, ok.
<hallyn> slangasek: yeah, looks like that was prolly fixed in git, and patch was quietly re-adding it.  it didnt' wanna fuss
<hallyn> slangasek: yeah upstream commit c65f9a07a78afa3c98712f6192962ffd6babe339
<hallyn> i'll push a new build with that dropped, thx!
<slangasek> hallyn: thank you :)
<hallyn> thank you!  pushed.
<ScottK> ivoks (and infinity) on it.
<jamespage> thanks ScottK
<ScottK> jamespage, ivoks , zul , infinity: Released.
<jamespage> excellent
<Noskcaj> Can some more people please add testimonials to https://wiki.ubuntu.com/Noskcaj#MOTU ?
<Noskcaj> Laney ^
<Noskcaj> mterry, ^
<mterry> Noskcaj, hello!
<Noskcaj> hey mterry
<mterry> Noskcaj, is there a close deadline or can I do it this weekend?
<Noskcaj> mterry, Just by the next 19UTC meeting
<Noskcaj> That's the only time i can apply till around october
<mterry> What day?
 * mterry forgets when the membership meetings are
<mterry> Noskcaj, ^
<Noskcaj> 24th
<mterry> Noskcaj, ah, pfft.  OK!  I'll add something this weekend.  :)
<Noskcaj> thank you
<mterry> Noskcaj, oh man.  Just now realized your  nick is jackson backwards
 * mterry is smart
<Noskcaj> :)
<Noskcaj> I think that's three people have worked that out now
<Noskcaj> :)
 * mterry goes afk
<Laney> That's the only way I can remember how to spell it
<Laney> I'll write something soon
<Noskcaj> thanks
<sarnold> pitti: another trusty bug not yet retraced after eight hours: https://bugs.launchpad.net/bugs/1289289
<ubottu> Error: launchpad bug 1289289 not found
<barry> mlankhorst: oh man, *anything* i can do to help debug LP: #1284134, just let me know.  it's causing me physical pain ;)  i'll drop everything else to help gather information
<ubottu> Launchpad bug 1284134 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [Undecided,New] https://launchpad.net/bugs/1284134
#ubuntu-devel 2014-03-08
<manchicken> Anybody know how to get a service using polkit to log?
<manchicken> Actually, I guess this isn't even the polkit auth bit, it's just the dbus. I'm having a hard time figuring out how to get the dbus stuff to give me useful information. dbus-monitor doesn't give me anything when I look for the interface I'm trying to call.
<sarnold> manchicken: have you seen d-feet? it may help
<manchicken> sarnold: For some reason it didn't even occur to me that I could look for such a program.
<manchicken> Here's what I used, though:  `dbus-monitor "interface=org.kubuntu.qaptworker2"`
<manchicken> And then I have a piece of code which I know is resulting in a call to that interface, but it doesn't seem like it's making it through to dbus-monitor
<slangasek> session or system bus? ttps://wiki.ubuntu.com/DebuggingDBus
<slangasek> +h
<sarnold> handy page! :) thanks slangasek
<manchicken> I'm guessing it's session since it isn't a service which is running all the time.
<slangasek> services on the system bus can be started on demand
<xnox> wgrant: infinity: thanks for putting postal on manual, do you have magic powers to retry chroot problem / ppc64el things from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-4.9-trusty.html and http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
<cjwatson> xnox: already on it
<cjwatson> xnox: I put them on manual
<xnox> cjwatson: thanks. ah ok =)
<cjwatson> Turns out you can fail a lot of builds very quickly if you're just segfaulting all the time.
<cjwatson> xnox: all done
<Ampelbein> Is upstart supposed to take 7 hours to build? https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5731715 ;)
<Logan_> oh dear
<Logan_> definitely not
<Logan_> I would kill that
<Logan_> I just requested that in #launchpad
<Noskcaj> Should i try and get a FFe for pavucontrol or just cherry pick the RC bug fix
<Logan_> Noskcaj: depends on how many new features there are that could possibly cause regressions
<Logan_> read the NEWS file or whatever
<Noskcaj> Logan_, There's no changelog/news file, but the mailing list has http://paste.ubuntu.com/7057567/
<Logan_> hmm
<Logan_> at this point in the cycle, I'm sure you could get an FFe ACKed
<Logan_> especially since it's unseeded
<Logan_> try it, and if they deny it, cherry pick the bug fix
<Logan_> Noskcaj: have you done a test build yet?
<Logan_> also, see if it fixes any of the bugs at https://bugs.launchpad.net/ubuntu/+source/pavucontrol
<Noskcaj> I was just updating my schroot now
<Noskcaj> Laney, Mind if i package d-conf 0.19.91? It's bugfix only. http://ftp.gnome.org/pub/GNOME/sources/dconf/0.19/dconf-0.19.91.news
#ubuntu-devel 2014-03-09
<Noskcaj> bdrung, There's a fair few big bugfixes in the new owncloud update, mind if i merge it?
<bdrung> Noskcaj: not at all! i would appreciate it
<bdrung> RL keeps me too busy
<Noskcaj> let me know if there's any other merges/syncs you want me to look at, i'm out of stuff to do
<Noskcaj> never mind, my internet is too broken to work on that package
<bdrung> Noskcaj: vlc needs an upstream update + a fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736788 (and then it will be a sync ;) )
<ubottu> Debian bug 736788 in vlc "[src:vlc] Sourceless file" [Serious,Open]
<Noskcaj> That might just be a small enough download to work
<bdrung> Noskcaj: i have other stuff i really want to do, but can't find time for it (beside responding to all the mail backlog)
<Noskcaj> I'll look at the vlc thing then go through what parts of your merge list are FF safe
<bdrung> there are fixes lying around for apt-mirror, mozilla-devscripts could get some love, nemo should be updated (but the new version has some issues)
<bdrung> ubuntu-dev-tools could get some more love, too
<Noskcaj> well vlc is too big as well. sigh
<bdrung> time to go to bed (at least for me)
<Noskcaj> g'night then. it's 11am here
<bdrung> 1:30 (utc+2)
<teward> so, question RE: MIR and https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/6
<ubottu> Launchpad bug 1262710 in nginx (Ubuntu) "[MIR] nginx" [Undecided,Confirmed]
<teward> the Checklist for it points out libssl-dev.  what do i need to "check" for that?
<Logan_> teward: I'm not a fan of having nginx in main
<Logan_> I feel like most people who use it in production environments get it from the PPA
<Logan_> I do, at least
<teward> Logan_: considering that jcastro messed up and jumped the gun on the announcement about nginx getting into main, we're under pressure
<teward> so there.
<teward> blame jcastro
<teward> (the PPAs will continue to be maintained either way)
<teward> (... starting tomorrow, because my brain hurts)
<Logan_> oh dear
<Logan_> teward: where was this announcement made?
<teward> http://www.jorgecastro.org/2014/01/02/nginx-coming-to-main-in-14-dot-04/
<teward> as i said, blame jcastro
<Unit193> That's a blog, not an announcement.
<ekarlso> coming to main what ? ^
<teward> Unit193: that was read by arstechnica and many other blogs as an announcement
<Logan_> > UPDATE: Note that the MIR has been filed, technically it is not in main yet, and it must go through that process, but weâre confident that there wonât be major issues in time for 14.04.
<Unit193> teward: Right, I read it on Ars.
<teward> then OMGUbuntu and many other things and twitter all treated it as an announcement
<teward> then nginx upstream heard about it then boom
 * teward grumbles
<Logan_> OMGUbuntu fucks up a lot of things
<Unit193> OMG!Ubuntu hardly counts for anything.
<teward> THEY want it in main too
<Unit193> Logan_++, quite so.
<Logan_> I complained to them that they misled people about MATE getting in 14.04
<Logan_> and they never wrote back
<Logan_> > it's not happening
<Logan_> http://www.omgubuntu.co.uk/2014/01/mate-desktop-ubuntu-1404
<Logan_> and there were...263 comments/misled people? ffs
<teward> Logan_: key thing is upstream is willing to help maintain it in main
<Unit193> Logan_: How about a mailing list post that says in it that such and such is uploaded, which should be fine if it is kept as a low target and not many downloads landing on the front page?  That's the year/day I marked them as idiots and never looked back. :/
<teward> but ultimately, I think i'm going to end up being the one who maintains things
<Unit193> They will likely help with patches, though.
<Logan_> :/ I feel you, Unit
<teward> Unit193: but ultimately i have to incorporate it to the packaging (they do the source, and provide the patch, I SRU it)
<Unit193> I'd say that's helpful...
<Logan_> teward: okay so
<Logan_> what's your question about libssl-dev? :P
<teward> what do i need to look at regarding it?  it's in the MIR checklist of things to check for build-dep on
<teward> and IDK the specifics
<Logan_> okay, so, that's just a basic check to make sure the build-deps are in main
<Logan_> because that's necessary for a package to be included in main
<mapreri> Is there someone who can help me with this: https://jenkins.qa.ubuntu.com/job/trusty-adt-varnish/ARCH=i386,label=adt/31/console ? I can't reproduce it here... (note: it fails also on debian)
<infinity> SpamapS: So, uhm.  Want to fix the braindead SONAME != packagename bit in mysql-5.6 in experimental?
<infinity> SpamapS: And maybe just remove it from trusty while we're at it, since that would mean 5.6 takes over the client libs...
<infinity> SpamapS: (Currently, if you install both, you end up using the 5.6 lib anyway, because ldconfig is smarter than you, so whoever thought there was value in trying to make them coinstallable was wrong, cause they're not both usable together anyway)
<SpamapS> infinity: do I want to fix the braindead SONAME != package name bit? no. Should somebody? Probably. :)
<infinity> SpamapS: Well, you
<infinity> Err.
<infinity> SpamapS: Well, you're one of the maintainers. :P
<infinity> SpamapS: Anyhow, it should probably be removed from trusty and blacklisted before it's fixed in Debian, since the proper fix is for mysql-5.6 to produce libmysqlclient18, which would take over the one from 5.5
<SpamapS> infinity: I am on the team, but have never touched 5.6 packaging
<infinity> jamespage: ^
<SpamapS> 'twas a surprise to me to see it in Ubuntu, hence my message to the TB
<infinity> Not sure which archive admin reviewed it, but they didn't review very closely (in both the case of Debian and Ubuntu...)
<jamespage> infinity, SpamapS: I'll look tomorrow
<infinity> jamespage: I filed an RC bug on mysql-5.6 in Debian regarding the binary being misnamed and not shipping the .so.18 symlink.
<infinity> jamespage: But given that it would be impossible to ship 5.6 in universe and 5.5 in main (since only one can produce the library, and that would have to be 5.6), I think we're best off just removing it.
<jamespage> infinity, I think I'll probably just drop the libmysqlclient from the 5.6 packaging
<infinity> jamespage: The only other option is a very well tested move wholesale to 5.6
<jamespage> nothing will actually use it for this release
<jamespage> oh - snap
<jamespage> infinity, I was intending on having a mysql-* day tomorrow
<jamespage> the breaks/replaces/conflicts etc... are all over the shop
<infinity> jamespage: You can't breaks/replace/conflict, it's the SAME SONAME.  It needs to be the same package name.
<jamespage> infinity, not on that package
<jamespage> on the mysql-* package
<infinity> Oh.
<infinity> So, dropping the library, how would you view that working?
<jamespage> they work but there is no intelligence in it
<infinity> Surely, things in the mysql source link to the client lib.
<infinity> And would want symbols in the newer version.
<jamespage> infinity, nope - they static link
<infinity> Err.  Lolwut?
<jamespage> (well at least I think they do)
<infinity> They friggin' shouldn't. :P
<jamespage> I think there is a good reason but it pre-dates my involvement so not sure of the details
 * jamespage takes a quick look
<infinity> Anyhow, dropping the client lib until 5.6 is ready to be the default would fix my complaints.
<infinity> Ish.
<jamespage> infinity, ack
<infinity> It doesn't at all fix the "we want to ship 5.6, and we know people will use it, but we won't support it, so nyah nyah" issue.
<infinity> (You can read the above as "I really don't think we should ship a version we won't support, and if we plan to support it, we should be moving to it, not supporting two).
<jamespage> infinity, there is certainly no dep from mysql-*-anything to libmysqlclient
<infinity> jamespage: Indeed, I noticed that myself.
<infinity> jamespage: I still would like to talk you out of having mysql-5.6 in universe at all, but if you honestly can come up with good counter-arguments to mine, removing the client libs is a passable compromise.
<infinity> (I just seriously don't see any point in shipping something we don't want people to run.  And if we want them to run it, we're being duplicitous to the extreme by saying "here, a new version you can try[1]" [1] but it's not supported at all, whee)
<jamespage> infinity, I don't agree with that statement
<infinity> Which part?
<jamespage> that we're shipping something we don't want people to run
<jamespage> we're indicating a clear default in -5.5
<infinity> Then why ship 5.6?
<jamespage> as an option at this point in time
<infinity> People see multiple versions, they'll pick the higher one.  Because version inflation is hip and cool.
<jamespage> we've done the same with other packages
<jamespage> infinity, people will install mysql-server
<jamespage> which will give them 5.5
<infinity> I like your optimism.
<jamespage> infinity, I'm always one of those
<infinity> apt-cache search mysql-server gives me mysql-server-5.5, mariadb-server-5.5, mysql-server-5.6, I'm likely to pick the shiniest of the bunch.
<jamespage> infinity, in reality we'll be proposing the switch next cycle; the reason I asked re 5.6 on the TB MRE is that we do want to support it
<infinity> (Well, I'm not, cause I know what I'm doing, but...)
<infinity> jamespage: Define "support".  5 years of security and SRU?
<infinity> jamespage: Bumping upstream versions isn't quite the same.
<infinity> jamespage: So, seriously, if you want to switch, and you want to support it, why aren't we stress-testing an actual switch instead of faffing with shipping two?
 * lifeless wants to make a fork of mysql called shiniest-$version now
<jamespage> because I'm not happy introducing a complex package and switch the default in a single cycle
<jamespage> esp a LTS cycle
<infinity> jamespage: Anyhow, IME, people often want the latest and greatest, and if it's available, they'll install it.  I love your optimism that people won't do anything other than what the metapackage tells them to, but that's not really supported by history.
<jamespage> infinity, fone
<jamespage> man - its to late for me
<jamespage> fine
<jamespage> personally I would rather folk raise these objections at the start of cycle when we discuss plans
<jamespage> rather than ~1 month before release
<infinity> Not everyone can be in every planning session.
<jamespage> infinity, this plan was been documented since the last vUDS so I find it frustrating
<infinity> And if I'd known about it at the beginning of the cycle, I would have suggested you switch to 5.6 earlier and test it.
<infinity> Like, honestly.  If you don't think it's going to be well-tested enough to support, that's true regardless of which component it ships in.
<jamespage> I don't think that
<jamespage> <jamespage> because I'm not happy introducing a complex package and switch the default in a single cycle
<jamespage> I did not say I don't think its well tested enought to support
<infinity> What would be the argument for not switching the default if it's "well-tested enough to support"?
<infinity> "It's complex, therefor might be broken/buggy" returns to "not well-tested enough to support".
<jamespage> because we categorically stated 4 months ago we would not be doing that
<jamespage> I like to make a plan and stick to it persoanlly
<infinity> And if the TB didn't grant your MRE, would you be able to stick to your plan? :P
<jamespage> infinity, not effectively no
<infinity> So, maybe making plans where input from others would be helpful should solicit input from others.
<jamespage> if they didn't grant the exception I can push microreleases which makes it pretty much impossible to support
<infinity> FTR, your upload to trusty should have been flat-our rejected for the broken library packages too.
<infinity> s/flat-our/flat-out/
<jamespage> infinity, indeed which is why we had representation from teams who are involved with supporting mysql at the session including the security team
<jamespage> its not like I've not thought this through
<jamespage> infinity, fine - but thats just a bug and is fixable
<infinity> But the security team won't be on the hook for maintaining it.  Which means it won't get the level of support that 5.5 does.
<infinity> jamespage: I don't think you're doing anyone any favours with the two version, but do what you will after you've fixed the library mess.  One AA/TB/SRU member's opinion certainly doesn't have the weight of those teams.
<jamespage> infinity, ack
 * jamespage goes to bed
#ubuntu-devel 2015-03-02
<sujx> anyone has been used debootstrap? when i Use debootstrap to build the ubuntu core system, the system is not stable and often crash
<aeoril> darkxst /etc/init.d/gdm seems to have some additional bugs in vivid (not trusty) than just the syntax error.  Found this trying to test on vivid:  http://paste.ubuntu.com/10496518/
<darkxst> aeoril, that is expected
<darkxst> use restart (or stop gdm first)
<aeoril> darkxst really?  just because the path used is different to the script?  That seems kind of odd ...
<darkxst> aeoril, what are you talking about paths for?
<darkxst> you ran gdm start, and it said gdm already running
<aeoril> darkxst look at the paste - when I was testing, I tried to test using "./gdm" because I was in the /etc/init.d directory - it did not fail becasue of the syntax error.  But typing "../init.d/gdm" from the same directory hit the syntax error - then, from the same directory, "/etc/init.d/gdm" gave the proper error message, but never hit the syntax error
<darkxst> aeoril, just fix the syntax error
<aeoril> darkxst that is fine, but shouldn't we be concerned about the odd behavior?
<aeoril> darkxst it doesn't act like that in trusty
<darkxst> aeoril, I don't recommend you step into that world
<aeoril> darkxst ok, I'll "keep it simple" then ... - just had anomalies during test, so figured I'd mention it to you ...
<darkxst> there a ton of wrappers that hook all the various init systems command together
<aeoril> darkxst yes, I went through some of them, loops, etc.
<aeoril> pretty complex
<aeoril> darkxst so don't even file a bug report?
<darkxst> aeoril, you could file a bug
<aeoril> darkxst I was definitely not thinking of fixing it myself ...
<darkxst> aeoril, no one cares about sysv (in Linux anyway) anymore
<darkxst> aeoril, I've been giving you trivial bugs so you can just concentrate on the packaging side
<aeoril> darkxst ok, just trying to be helpful
<darkxst> if you want a fun bug, thats more than just that, then bug 1385572
<ubottu> bug 1385572 in upstart (Ubuntu) "gnome-session not shutting down cleanly" [Low,Confirmed] https://launchpad.net/bugs/1385572
<aeoril> darkxst ok, I'll take a look at it, but I will finish this bug to learn the packaging side of things better
<darkxst> aeoril, btw invoke-rc.d is usually used for sysv scripts I think
<darkxst> and that should have a wrapper that would re-direct to upstart or systemd init (or whatever you boot with)
<aeoril> darkxst I will just do the syntax error fix then look at the next bug.  I really appreciate all the help
<aeoril> darkxst I need to learn how to get a vivid fix back into 14.10 and 14.04 anyway
<darkxst> aeoril, https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=https%3A%2F%2Fwiki.ubuntu.com%2FStableReleaseUpdates&ei=xtvzVKjEE8LbmAXZ2oHQDw&usg=AFQjCNFl9CrvGudijLLJ0UQ8dxx7Lj3WRQ&sig2=ht7tqyA-Zn9MmwlOf-demw&bvm=bv.87269000,d.dGY
<darkxst> silly google links: https://wiki.ubuntu.com/StableReleaseUpdates
<aeoril> darkxst good gosh!  But it worked!  Thanks ... :)
<darkxst> aeoril, I can upload gdm, so all you need worry
<darkxst> about is a  debdiff and the SRU paperwork
<aeoril> ok - thanks
<aeoril> darkxst getting tired, work further tomorrow - that glitch took all my time hunting down the odd behavior
<aeoril> (it was not immediately apparent what was going on, so I was doing all kinds of crazy stuff devling into the scripts)
<darkxst> aeoril, those things come with experience
<darkxst> and wasting an enitre night chasing down a phantom bug, would be considered experience
<darkxst> I've certainly done that before
<darkxst> aeoril, our first realease was 12.10 and I spent the entire cycle fixing about 10 hard bugs
<aeoril> darkxst 12.10 was the first release of Ubuntu GNOME?
<aeoril> darkxst does Fedora still use GNOME as its default GUI?
<darkxst> aeoril, yes and yes
<aeoril> darkxst yes, I looked both answers up - the first release on releases.ubuntu.com is 13.04, though - I wasn't sure what you meant by "our first" - now I understand that what you meant a while back when you said "you should work on gnome" - you meant "Ubuntu GNOME" I guess
<aeoril> darkxst why not?  You are the most helpful person for me, and I like it ok.  I think it will be exciting to fix things in the desktop I have on my own pc.  I could never get that with Windows or Mac
<aeoril> darkxst the whole FOSS thing is just amazing.  When I was starting out way back, that kind of thing did not happen as much - some, but not a lot
<darkxst> aeoril, 12.10 was the first release
<darkxst> 13.04 was the first as an official flavour
<aeoril> darkxst yes, I figured it was something like that
<aeoril> darkxst thanks for the clarification, though
<aeoril> darkxst it is nice that it became an official flavour
<darkxst> aeoril, we founded ubuntu GNOME to get contributors working upstream
<darkxst> so work on GNOME fixing ubuntu bugs upstream kinda thing
<aeoril> darkxst I am sorry, I do not sure what you mean - do you mean fixing upstream GNOME bugs that cause problems specifically with Ubuntu?
<darkxst> aeoril, yes
<aeoril> darkxst yes, that makes sense.  I really like the GNOME website - very professional.  Seems like a well run project
<aeoril> darkxst well, I guess a whole "web" of interrelated projects really - it is very important to Linux, I think
<darkxst> aeoril, although it wasnt really that specific it was more just have people contributing upstream from GNOME on ubuntu
<darkxst> only problem is it has affected my time to work on upstream bugs
<aeoril> darkxst oh, I see - where do you work?
<aeoril> do you actually work for GNOME?
<aeoril> (for pay?)
<darkxst> aeoril, no, everyone on the ubuntu GNOME team is volunteers
<aeoril> oh, sorry - I thought you said "at work" not "to work" - my mistake
<aeoril> darkxst ^
<aeoril> darkxst I thought "at work on upstream bugs" implied you actually worked for pay on the GNOME project or something
<aeoril> (but you said "to" not "at")
<darkxst> aeoril, no, distro patching every little annoyance is rubbish
<aeoril> darkxst lol ok, so pay to work means crappy work?  You can't pick and choose?
<darkxst> some packages have close to 100 patches
<aeoril> wow
<aeoril> darkxst oh, I see what you mean - "distro patching" meaning fixing all the nit-noid things that need to be done for each distro
<darkxst> aeoril, nautilus has 20odd ubuntu patches which will be broken in 3.16
<darkxst> aeoril, yes, mainly ubuntu though, they are the only distro visionary enough to produce their own product
<aeoril> darkxst what do you mean by "produce their own product?"  Don't most distros have unique stuff in them?
<aeoril> (I just don't know)
<darkxst> aeoril, Unity?
<aeoril> darkxst yes, I thought you meant that ...
<darkxst> I don't know any other distro that ships their own DE
<aeoril> What does DE stand for?  I cannot figure it out
<aeoril> Distro Environment?
<darkxst> aeoril, desktop-environment
<aeoril> darkxst oh, ok - duh!
<darkxst> gnome, kde, unity, etc
<aeoril> yes, I understand
<aeoril> I remember when Unity came out - it was GNOME or KDE before that ...
<darkxst> aeoril, it was GNOME2
<darkxst> up until about 11.10 (at a wild guess)
<aeoril> right, the default was Gnome, IIRC - I did not like Unity when if first came out
<aeoril> darkxst yes, that rings a bell
<darkxst> Kubuntu, would have been around back then anyway (for kde)
<aeoril> darkxst I think you may have nailed it - 11.04 -> Gnome2, 11.10 -> Unity, IIRC
<aeoril> Back around 2011 I think
<darkxst> aeoril, yes gnome-shell has really evolved since those early GNOME3 days
<aeoril> darkxst yah, 2011 - I think it was when I was doing this (https://answers.launchpad.net/launchpad/+question/172028) - I think that was on "natty"
<aeoril> darkxst or maybe "precise"
<aeoril> darkxst yes, I was surprised at how much it had changed - I like the improvements
<darkxst> aeoril, what do recipes have to do with anything?
<darkxst> always seemed like a broken way to try things to me
<aeoril> darkxst lol - just what I was into ... learning all about packaging and recipes and stuff - I don't remember why I was all into recipes
<aeoril> darkxst I may have been directed that way, or I may have thought it was some kind of "correct" way of doing things or something
<darkxst> look at how broken UDD branches are and then they automatically building random git branches
<aeoril> UDD?
<darkxst> lp:ubuntu/<package> branches
<darkxst> aeoril, you already found that out right?
<aeoril> darkxst that project was a "learning" project to figure out packaging
<aeoril> darkxst yes, quite ... :P
<darkxst> recipes don't help with packaging
<aeoril> darkxst well, I was making a "super clean" package, and somehow making it work on the recipe led to some insights - I really don't remember all about what I was doing
<darkxst> in fact they only even make sense on stable (bug fix only) branches
<aeoril> darkxst unfortunately, I nuked that PPA (randconverse) - it was actually pretty funny - you had a "conversation" with the computer, and it said abusive, funny things to you randomly based on your inputs
<aeoril> darkxst it was in C++
<aeoril> darkxst I got all into the debian policy guides, extensively into building a package from scratch using only autotools, manually configuring all the .am files myself, learning all about the debian directory and everything - I was really trying to learn packaging from the "ground up".  However, I pretty much forgot all of it
<aeoril> darkxst well, building a "build" from scratch using autotools would be more correct, then adding in the packaging stuff for debian/Ubuntu myself
<aeoril> (its kind of coming back to me a little)
<darkxst> ok, but I don't see the connection between autotools and recipes!
<aeoril> darkxst I just don't remember ... maybe they were just separate things I thought I should learn about?
<darkxst> aeoril, ok keep learning and then maybe you can make the distinction!
<aeoril> darkxst Maybe I thought the "best" build environment was on launchpad using a recipe?
<darkxst> aeoril, and now you know that is sbuild ;)
<aeoril> darkxst that is what everyone says now!
<darkxst> was probably pbuilder back then though
<aeoril> darkxst yes, I was holding off using pbuilder until I learned the underlying stuff that pbuilder "hides" and makes easier ... trying to learn what was below pbuilder
<darkxst> pbuilder doesnt hide anything
<aeoril> darkxst well, I guess I just don't know what I thought I was doing then :(
<darkxst> yes you said that already ;)
<aeoril> darkxst maybe pbuilder automated things that I was trying to learn how to do automatically?
<aeoril> s/automatically/manually/
<darkxst> aeoril, nope
<darkxst> pbuilder is very much like sbuild
<darkxst> i.e take a clean chroot, install builddeps, build packes
<darkxst> packages
<aeoril> hmmmm ... then I just probably didn't even know back then what the heck I was doing, I guess
<aeoril> darkxst yes, that makes sense
<aeoril> darkxst I seem to remember feeling I was making great progress, though, and "experts" were helping me a lot
<darkxst> aeoril, so make this your goal, find and a fix a bug that the "experts" can't fix ;)
<aeoril> darkxst I just want to learn, have fun and contribute to something worthwhile.  And keep my skills up.
<aeoril> darkxst It would certainly be wonderful to become an "expert" though - really know this stuff well
<aeoril> darkxst with your help, I feel I have already come a long way, even just using Linux and understanding how it is put together
<aeoril> sarnold and others have helped me too
<darkxst> aeoril, but an expert in packaging or an expert in coding?
<darkxst> the first is largely generic and there are a bu
<darkxst> bunch of very expert packagers around this part that don't know any coding
<aeoril> darkxst I am much more interested at becoming an expert at coding Linux
<darkxst> aeoril, in which case you need to pick a project
<aeoril> darkxst but, I have to be a competent and preferably accomplished packager, I would think, to work with the community best?
<aeoril> darkxst I was thinking kernel/driver
<darkxst> aeoril, maybe not
<aeoril> darkxst but, you are the person who is helping me the most, so maybe I should go with GNOME because I need the help ...
<aeoril> darkxst why not?
<darkxst> aeoril, kernel code would be pretty scary for someone with no evidence of proper coding experience
<aeoril> darkxst I have no evidence of proper coding experience?
<darkxst> aeoril, I gues that is a little irrelevant, but open a random driver in the kernel and see if you can understand?
<aeoril> darkxst well, I am just wondering - in working with me, have you gotten the impression I have no coding experience?
<darkxst> aeoril, nope, because you haven't asked a single question about code I guess
<darkxst> aeoril, and really I won't judge that until I see a patch ;)
<aeoril> darkxst I have not been having a hard time following code, just using the tools (like git/bzr) and packaging.  Of course, the code changes have been trivial so far
<aeoril> darkxst I made that one stupid mistake following the wrong code in the super-easy fix I am doing now, but oh well - it happens
<aeoril> (not seeing the syntax error in the vivid /etc/init.d/gdm script)
<aeoril> I was embarrassed about that one
<darkxst> aeoril, vala?
<aeoril> darkxst what about vala?
<darkxst> have you used it?
<darkxst> programmed even
<aeoril> darkxst no, never - there was vala in my first bug I tried to fix though, so I saw some of it
<aeoril> (the vim/gnome-terminal racey thing)
<aeoril> vte3
<darkxst> gnome-contacts need a titlebar fix
<darkxst> probably similar to https://bugzilla.gnome.org/show_bug.cgi?id=745346
<aeoril> I could try - bug?
<ubottu> Gnome bug 745346 in general "Use traditional title bars on Unity" [Normal,New]
<aeoril> darkxst my background is embedded and real time design, mostly, C, C++, FORTRAN, assembler, Ada, JOVIAL, etc.  I think I was a reasonably competent programmer for all those years
<darkxst> bug 1339355
<ubottu> bug 1339355 in gnome-contacts (Ubuntu) "Update to 3.14" [Wishlist,Triaged] https://launchpad.net/bugs/1339355
<aeoril> Most recently, since 2011, I took a hiatus from learning about Linux development to learn about JavaScript/HTML5/CSS3 - that was fun, but I think I like this better
<darkxst> aeoril, you reliase gnome-shell/gtk is a funny combination of javascript and css?
<aeoril> darkxst nope
<darkxst> aeoril, there you go, gnome-shell UI is nearly entirely JS, and most all GTK theming is CSS (although generated from SASS now)
<aeoril> darkxst I really learned an incredible amount in a short time doing JavaScript/HTML/CSS - it opened up whole new ways of thinking for me.  A wonderful experience
<aeoril> darkxst I did some GTK/GDK coding on my last job, maybe 10 years ago?
<aeoril> but just a littl
<aeoril> e
<aeoril> darkxst I have learned over time I am not a "great" coder, but I am good enough to make a solid effort and tend to be thorough and careful
<aeoril> darkxst I will never be a "star" but I believe I bring value and can contribute well
<aeoril> darkxst I was thinking about kernel/driver development because I have the most experience in C and have done quite a bit with low-level stuff interacting with hardware and firmware, or even writing firmware.  Since that is where most of my experience lies, I thought that was the best choice for me
<aeoril> darkxst also, there seem to be some very good avenues to learn that stuff (kernelnewbies, osdev) so it might not be too bad
<pitti> aeoril: yes, after checking out trunk you need to select a packaging backend; you can just ./setup.py build, that'll install the dpkg one
<pitti> aeoril: I usually run PYTHONPATH=. gtk/apport-gtk [args]
<pitti> aeoril: thanks for your MP! will look at it today, looks fine at first glance
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey hey seb128
<seb128> :-)
<Mirv> is there an automated way to change Maintainer: to XSBC-Original-Maintainer: and add Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>?
<Mirv> it'd be easy to automate of course, but I wonder if it's something that's already in some tool
<pitti> Mirv: it's called "update-maintainer" :)
<Mirv> ooh! :)
<pitti> Mirv: in ubuntu-dev-tools
<pitti> Mirv: it also DTRT for debian/control.in
<Mirv> thanks a lot!
<mitya57> Mirv: qtscript -2 from Debian will ftbfs on ppc64el, I have just uploaded a potential fix for that
<mitya57> (and also uploaded an untested fix for qtwebkit)
<doko> pitti: are you looking at the autopkg test failures triggered python3-defaults?
<pitti> doko: yes, some 10 mins ago
<doko> cool, thanks
<pitti> infinity: speaking of which, it's not clear to me whether the upstart regression is induced by the new glibc, or if something else broke it
<pitti> so I don't override that one for now
<pitti> (although it probably isn't related to the new glibc)
<Mirv> mitya57: thanks, I noticed you were working on those right at the moment.
<infinity> pitti: Given nothing changed in that libc (other than the compiler/binutils used to build it), the odds of a regression are pretty low.
<infinity> pitti: But not nil.
<pitti> not ok 54 - with single line command writing lots of data fast and exiting
<pitti> wrong value for bytes, expected 3145728 got 3018031
<pitti> at tests/test_job_process.c:3886 (test_start).
<pitti> jodh: ^ does that tell you anything?
<pitti> that happened 4 times during the last 6 runs
<infinity> pitti: But not 6 times?
<pitti> infinity: right
<pitti> but the history on http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-upstart/ looks like that's something recent
<infinity> pitti: Smells like an intentionally racy test meant to test accidentally racy code. :P
<infinity> Even the name of the test sounds racy.
<pitti> so, http://launchpadlibrarian.net/198971296/glibc_2.19-15ubuntu1_2.19-15ubuntu2.diff.gz indeed looks unrelated
 * pitti waves through
<infinity> pitti: Right, the diff is *obviously* unrelated, but that doesn't rule out the toolchain having produced a broken libc.  Seems pretty unlikely that it would have produced whatever breakage we're seeing here, though.
 * pitti leans on the retry button
<infinity> pitti: Another example of why a static foo triggers bar mapping would be nice: linux uploads should trigger ubuntu-drivers-common tests.
<pitti> infinity: yeah, I'm well aware of why this would be useful; new linux broke nvidia-304
<infinity> pitti: I wonder if a new header in debian/tests would be a good place to document such magic.
<pitti> infinity: no, it's not; if we had an index of all debian/tests/control, we would do reverse test dependency checking
<pitti> and as we don't, adding new fields there doesn't help either
<infinity> pitti: So, that specific case is meant to be covered by some automated testing we're going to be doing to make dkms in general block the kernel.  But still, it would have been awesome if u-d-c could have blocked it, which we could get with that sort of mapping.
<pitti> we either need an additional external mapping in britney, or a Tests.gz index
<infinity> pitti: Well, sure, a Tests.gz makes sense.  But we still need a header to define "should be triggered by: foo" when it's not actually a direct dep of the test or package.
<pitti> how is that not a Depends: ?
<infinity> pitti: Well, I assume autopkgtest follows the same "don't need to depend on Essential", for instance.
<infinity> s/, for/rule, for/
<pitti> right, you don't have to, but there's nothing stopping you from doing that once it becomes useful
<infinity> But I guess you could just add explicit deps if you want the trigger, sure.
<pitti> also, for this particular example, linux-headers isn't essential
<infinity> No, true.  linux-headers isn't.
<infinity> So, fair enough.
<infinity> Are you looking to have a Tests.gz produced by apt-ftparchive and published in the archive next to Packages.gz, or externally produced?
<pitti> the former would be nice, but I'm not going to do that myself; I could envision a cronjob on people and put it into http://people.canonical.com/~ubuntu-archive/ somewhere?
<infinity> And does debian/tests/control end up in control.tar.gz or data.tar.gz?  Cause if it's the latter, that will be expensive.
<pitti> no, debian/tests/control is per-source, it doesn't make sense in binary packages anyway
<infinity> I'm guessing it's the latter, cause I doubt autopkgtest has ended up specced/supported in dpkg in any way yet.
<infinity> Err, oh.  Right.  Derp.
<infinity> Sorry, not away.
<infinity> Nor awake.
<pitti> so at most it could live next to Sources.gz
<infinity> Check.  That would be VERY expensive to generate, then. :/
<infinity> Since Sources.gz never unpacks source, it's just a concatenation of .dsc files, essentially.
<pitti> but I think we should prototype it first on people.u.c., see what we need and how far we get with it, and then perhaps send lots of beer and flowers to cjwatson to put it into LP :)
<infinity> It's not about beer and flowers, it's that there's no way I'd let the publisher be slowed down that much.
<pitti> infinity: well, it's grepping Sources.gz for "Testsuite: autopkgtest", and unpacking a 1000 debian.tar.gz tarballs for debian/tests/control
<infinity> Unpacking source is slow.  Very slow.
<pitti> right, you definitively don't want to do that 3 times an hour
<pitti> maybe once a week or so
<pitti> it's more like Contents.gz than Sources.gz
<infinity> pitti: Not a guarantee that it's debian.tar.gz, not the whole world is v3(quilt).
<pitti> infinity: yeah, for those cases you need to dpkg-source -x the whole thing
<pitti> buit we can optimize for v3-quilt
<xnox> pitti: infinity: that one tries to catch a race. I ponder if it should declare "skip" when it didn't manage to race.
<infinity> pitti: Doesn't it become a bit useless if it's doesn't match the archive, since we care about testing the ever-changing -proposed pocket?
<pitti> we could even optimize for a debian.diff.gz, but that'd be a bit hackish
<infinity> xnox: Well, I assume it *did* race, and hence failed.
<infinity> xnox: If it's testing (and finding) a bug in the code could we, I dunno, fix the bug?
<pitti> infinity: obviously, the more current the better; that was just an initial idea for a prototype
<pitti> a more "rolling" db would obviously be better
<infinity> pitti: apt-ftparchive doesn't pull dirty tricks like that, generally, it's more about trusting dpkg to know how to deal with its own formats.  This is usually saner.
<pitti> whenever a source is uploaded, its debian/tests/control goes into that db
<pitti> infinity: yeah, but really expensive
<infinity> Quite.
<infinity> pitti: But, since non-a-f archive probably need to know how to do this too, I guess we could attack it from a different angle and store tests/control on upload.  We already waste a ton of cycles there unpacking and validating.
<pitti> that sounds ideal indeed, as we wouldn't have to download and unpack anything in additon
<infinity> pitti: Not sure how I'd spec that in a DAK world, though.  And I do prefer universal solutions.
<infinity> pitti: But in Soyuz, it would just become another source artefact, like .changes
<infinity> pitti: And, derp.  There's perhaps the real solution.
<infinity> pitti: Add a dh helper to take all deps from debian/tests/control and concat them to XS-AutoPkgTest-Depends, so they end up in .dsc
<infinity> pitti: And then if and when this gets specced in dpkg, dpkg-source can do it on its own without said helper.
<infinity> pitti: Done, clean, and it lands in Sources.gz
<flexiondotorg> Morning. I need some help please.
<flexiondotorg> There are some critical glib 2.43.x compatibility issues in MATE.
<flexiondotorg> The MATE Debian maintainers (of which I am a memeber) requested an unblock in Debian to provide the patches we've prepared.
<pitti> infinity: dpkg-source already adds the Testsuite: header, so it could just as well add the new one
<flexiondotorg> That request was denied.
<pitti> infinity: I thought about that, it'd just inflate Sources.gz even more
<flexiondotorg> So I need to add the required patches directly to Ubuntu.
<flexiondotorg> I have the patches, have built and tested in a PPA.
<flexiondotorg> How do I proceed?
<infinity> pitti: Oh, does it?  Wasn't sure if that was specced in dpkg or not.  Sweet.  That will make it much easier to get guillem to accept a patch for the Testsuite-Deps too.
<infinity> pitti: A tiny inflation in Sources.gz is MUCH better than parsing source packages to generate yet another file.
<pitti> infinity: https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=3e6253 and https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=db3c4ab FYI
<infinity> pitti: Even if every source in the archive had a test-deps line, it wouldn't be that much more data.  About the same as adding a new hash.
<pitti> let's say 5000 packages, 100 bytes dep line == 500 kB uncompressed, perhaps 100 kB compresssed
<pitti> not that bad indeed, but measurable
<infinity> pitti: Yeah, not really a big deal, the archive grows faster than that for other reasons.
<infinity> pitti: And "Sources.gz is getting large because everyone keeps adding testsuites to their packages" is a problem I kinda would like to have.
<infinity> pitti: Normal users (despite RMS arguing viciously to the contrary) shouldn't have deb-src lines enabled anyway, IMO.
<pitti> +1 on that
<infinity> pitti: And certainly not users who care about how long updates take; they turn it off.
<pitti> it's a pretty big waste of download bandwidth
<wgrant> 100 bytes?
<flexiondotorg> dholbach, Have you the time to help point me in the right direction regarding glib2.43 patches?
<wgrant> Would most packages really have that many?
<dholbach> flexiondotorg, I would suggest asking in #ubuntu-desktop
<pitti> wgrant: a wild guesstimated pessimistic average between a lot of packages just doing "Depends: @" and some needing a lot
<dholbach> flexiondotorg, I'm in the middle of 3 things right now
<infinity> wgrant: Header plus lots of deps, might average out to more like 50 or 75, but whatever.
<dholbach> plus, the guys in #u-desktop are far more knowledgeable when it comes to glib than I am
<pitti> wgrant: we also only have ~ 1300 tests, but the number has doubled every release for 4 releases neow
<pitti> now
<infinity> Either way, I don't think it's a big deal.
<pitti> yeah, agreed
<infinity> Sources.gz/.dsc feels like the right place for it.
<wgrant> It does.
<infinity> And the code to do that is simple and clear.
<flexiondotorg> dholbach, Thanks.
<infinity> It does mean we don't get the benefit until those old source packages are rebuilt with a new dpkg-source, but I suspect 95% of tests are in the 5% of packages that are uploaded quite frequently.
<pitti> right; and in particular, we could upload ubuntu-drivers-common and glibc (i. e. the use cases which were particular important)
<infinity> pitti: Right, I'm crazy tired, but can you file a bug on dpkg on assign it to me (or to yourself, if you're comfy with the perl in dpkg-source), and we'll discuss it with guillem too?
<pitti> infinity: sure
<infinity> pitti: Just copy-pasta some of the IRC log. :P
<pitti> infinity: I'll file it to Debian BTS and CC: you?
<infinity> pitti: Or that, I figured an LP bug to start with and we can work on the implementation in Ubuntu while talking guillem into taking it.
<infinity> pitti: But we could just work directly in Debian, up to you.
<infinity> pitti: I think there'd be value in us doing it ahead of Debian anyway, but obviously the biggest benifit is if it happens in Debian too, so we get the header in syncs.
<pitti> infinity: right, so I thought we discuss it in a Debian bug, then implement it in Ubuntu, and send the patch
<infinity> pitti: WFM.
<pitti> but let's rather get agreement (or some input) from Debian first?
 * infinity nods.
<xnox> slangasek: thanks a lot for this post https://lists.debian.org/debian-devel/2007/02/msg00398.html
<pitti> infinity: debian bug 779559, I CC:ed you
<ubottu> Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Normal,Open] http://bugs.debian.org/779559
<infinity> pitti: Ta.
<pitti> bah, forgot wishlist, /me "bts"es
<infinity> pitti: That should be Testsuite-Depends, I think, to match the existing Testuite: header.  But I imagine guillem will make the same argument.
<pitti> infinity: yeah, I don't care that much about the precise name
<aeoril> pitti ok, cool - I tried 'setup.py', and figured there was some command line argument to pass into it i was missing, but did not know what - I guess I should have looked at it better.  That was a challenging one to test for me, since I did not know the way to do it directly with the source code I downloaded, but I made due ...
<aeoril> pitti you can see how I tested it in the MP comments
<seb128> mvo, hey, is there any known issue with click/schroot/ecryptfs user directories?
<seb128> "E: 10mount: umount: /var/lib/schroot/mount/click-ubuntu-sdk-14.10-armhf-ec6aaf62-31e0-47e9-b2f8-73f0b038fb4d/home/ubuntu: target is busy E: 10mount: (In some cases useful info about processes that E: 10mount: use the device is found by lsof(8) or fuser(1).) "
<seb128> it's consistent here, it tries to unmount my real userdir for some reason, which of course doesn't work since I'm logged in with that user
<flexiondotorg> Trevinho, Can you take a peek at this little merge proposal please? https://code.launchpad.net/~ubuntu-mate-dev/compiz/improved-compiz-mate-profile/+merge/251438
 * Trevinho on it
<ginggs> hi, anyone from ubuntu-archive around?  I need someone to remove pycuda i386 binaries (LP: #1426722) please, they are blocking nvidia-cuda-toolkit.
<ubottu> Launchpad bug 1426722 in pycuda (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1426722
<cjwatson> ginggs: done
<ginggs> cjwatson: thanks!
<mvo> seb128: not know to me at least, no.
<seb128> mvo, hey :-)
<seb128> mvo, wie gehts?
<mvo> seb128: good, thanks! and you?
<seb128> mvo, I'm good, thanks :-)
<mvo> seb128: if you could file a bug I will have a look
<seb128> mvo, I can try to debug as well, http://people.canonical.com/~seb128/clickfail.log is my qtcreator framework adding log
<seb128> mvo, but I also have an issue that the click schroot can't be unmounted, which leads to spam, since it restores previous sessions on reboot and adds a new one
<mvo> seb128: oh, so this might be releated I wonder - i wonder if that also happens in a fresh install / clena chroot
<seb128> mvo, clean chroot? I don't have any of those, I had purged schroot because of those issues and cleaned the dirs, just tried again, it fails to create any because it tries to unmount the real homedir for some reason
<mvo> seb128: ok
<seb128> mvo, tried to create one from another user on the same machine, which isn't using ecryptfs
<mvo> seb128: and same result with that?
<seb128> mvo, sorry, "trying", it's running
<mvo> aha, ok
<seb128> I can let you know in a bit :-)
<mvo> ta
<seb128> yw!
<mvo> yeah, I'm debugging some different problem right now, but I'm >< close :)
<mvo> (hopefully)
<seb128> mvo, k, I'm going to try to debug the click issue myself, but help might be welcome if you are available for that later on
<mvo> seb128: please tell me once you finished the test with the other user :)
<flexiondotorg> Trevinho, Thanks.
<flexiondotorg> cjwatson, Can you take a quick peek at this please? https://bugs.launchpad.net/ubuntu-mate/+bug/1426436
<ubottu> Launchpad bug 1426436 in ubuntu-mate "15.04-Beta-1: Package 'grub-pc' has no installation candidate" [Undecided,Incomplete]
<flexiondotorg> cjwatson, I can't reproduce this. Does this look familiar to you?
<flexiondotorg> cjwatson, Am I missing something in my seeds? Could it be EFI related? I have no EFI hardware.
<cjwatson> flexiondotorg: After lunch.
<flexiondotorg> cjwatson, Thanks.
<ochosi> hmm, someone contacted me as xubuntu project lead and asked whether there is an easy way to download/get the full source of xubuntu14.10 (in order to run the code through fossology for license checking). frankly i have no clue, any of you got a pointer here?
<pitti> didrocks: FYI, I updated bug 1312976 with some noninteractive commands how to set up a VM for nfs server+client
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,In progress] https://launchpad.net/bugs/1312976
<pitti> didrocks: after that works, we can test server and client separately, but that should be good enough for initial testing
<didrocks> pitti: oh nice! I want to finish fsck+systemd autopkgtests first (the turnaround to get more complex issues dealt with the testbed installing lightdm is really slow), but then (I guess tomorrow), will jump on that!
<cjwatson> flexiondotorg: It's broken because you turned off Recommends, and it works in Ubuntu because ubiquity Recommends: grub-pc.
<cjwatson> (This is arguably a bit fragile ...)
<cjwatson> flexiondotorg: I'd suggest http://paste.ubuntu.com/10501858/
<doko> Mirv, Qt & GCC 5 ping
<flexiondotorg> cjwatson, Thanks.
<Mirv> doko: the destructor related symbol changes coming via Debian for the 5.4.1 in landing in ~two weeks
<cjwatson> flexiondotorg: I think you should put this on your list of reasons to get back to being able to enable Recommends
<flexiondotorg> cjwatson, I am contributing patches to indicator-* to add MATE support so I can eventually disable the no-install-recommends feature.
<flexiondotorg> cjwatson, Thanks for looking.
<doko> Mirv, cool, that's what I wanted to know
<cjwatson> flexiondotorg: Cool.
<slangasek> xnox: heh, that was a while ago
<xnox> slangasek: but i did answer "wtf nis is loaded" and the other statement about BenC is still true I guess =)
<slangasek> heh
<BenC> ??
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<cjwatson> BenC: The context was https://lists.debian.org/debian-devel/2007/02/msg00398.html
<BenC> Hehe
<BenC> Yes, NIS and DFS had a hold on me at the time. Blame NASA
<BenC> cjwatson, slangasek: Are you both still Debian developers?
<cjwatson> Yep
<BenC> cjwatson: I have an new GPG key I need signed so I can get my debian account reactivated (my account wasnât closed in a nice way, so I have to basically re-do NM process).
<BenC> Is there a protocol for verifying me via launchpad, but old GPG key, a picture of my photo ID signed by my old key, and getting my new key signed?
<cjwatson> BenC: If I've signed your old key, and it wasn't revoked, I'm generally happy (if slow ...) to sign the new key given a signed statement of transition
<cjwatson> BenC: Mail me
<slangasek> BenC: my personal policy is similar, I wouldn't use launchpad as a proxy for id but I would sign a new key for someone I'd previously signed given a transition statement; but AFAICS I didn't sign your previous key so this doesn't help you :/
<BenC> No, you didnât.
<BenC> Iâm having difficulty locating Debian folks to get my signatures, so Iâm reaching out to people who may be willing to secure by alternative means.
<BenC> Although, I am going to Boston next week, so I might be able to rally some folks around there.
<Snow-Man> BenC: Where-abouts are you..?
<Snow-Man> BenC: If it's still "somewhere, VA", then we might be able to work something out..
<BenC> Snow-Man: Hampton Roads area
<Snow-Man> BenC: ok.  I'm in the NoVa area (right near dulles airport)
<Snow-Man> BenC: Maybe we could meet in Richmond for lunch or something?
<BenC> Snow-Man: Thatâs a good hike. Let me see what I can do in Boston, but Iâll let you know if I still need a sig after that.
<BenC> Thanks
<Snow-Man> k.
<Snow-Man> I don't mind trying to work something out half-way
<Snow-Man> BenC: and, of course, if you're flying through dulles or national and have a long enough layover, that'd probably work too.
<alexbligh1> What's the canonical way to determine whether some is in trusty-proposed for an SRU? http://people.canonical.com/~ubuntu-archive/pending-sru.html is not showing the package concerned.
<cjwatson> rmadison will tell you what suites a package is in
<alexbligh1> cjwatson, I mean I have a bug which says it's been uploaded to trusty-proposed, but I can't see it in the Packages file or http://people.canonical.com/~ubuntu-archive/pending-sru.html , so I'm presuming rmadison wouldn't see it either.
<alexbligh1> cjwatson, (and to be clear, rmadison does not show it)
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> will do a bit more tomorrow probably
<cjwatson> alexbligh1: No, if rmadison doesn't show it then it isn't there.
<cjwatson> alexbligh1: But what exactly does the bug say?
<cjwatson> alexbligh1: "uploaded" could well simply mean "developer has uploaded it, but it's in the queue waiting for approval", in which case you'll find it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 (linked from near the bottom of pending-sru)
<cjwatson> alexbligh1: apache2 is there and mentions your name, so that's probably it.
<cjwatson> alexbligh1: And indeed I see that bug explicitly says "I have uploaded this to trusty-proposed and this now awaits review from the SRU team."
<cjwatson> alexbligh1: That is, it needs review before it enters trusty-proposed.
<infinity> BenC: I'd do a video call reading of fingerprints with you, if you're going to go to the effort to fake a call to the point where I believe it's you, you deserve the sig anyway.
<BenC> infinity: I can do that. Which service, and whenâs a good time?
<infinity> BenC: hangouts, skype, whatever.  And sometime soonish?
<BenC> Hangouts I can do.
<BenC> infinity: Connectedâ¦just start it up
<alexbligh1> cjwatson, https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1366174 says "I have uploaded this to trusty-proposed and this now awaits review from the SRU team. As Chris Arges looked at this previously, I'll ask him if he can look at this again now."
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,In progress]
<alexbligh1> cjwatson, I'd presumed (wrongly) that you could see what was in the SRU queue at http://people.canonical.com/~ubuntu-archive/pending-sru.html
<alexbligh1> cjwatson, and yes I'm still going on about the same bug :-)
<cjwatson> alexbligh1: Right, so as I said above.  Robie meant that it was waiting for review before being accepted into trusty-proposed.
<alexbligh1> cjwatson, thanks
<Noskcaj> ScottK, What should i be doing to get a +1 from you for MOTU next time i try?
<Noskcaj> And is there any chance of me just getting the xubuntu packageset?
<slangasek> hallyn_: bug #1358835.. did bugproxy get itself in a busy loop?
<ubottu> bug 1358835 in numactl (Ubuntu Trusty) "numa_node_of_cpu() returns warning when cpu_index > 79" [High,New] https://launchpad.net/bugs/1358835
<hallyn_> seems like
 * hallyn_ out for lunch ,biab
<bdmurray> pitti: there is still one outstanding apport merge-proposal from me
<smoser> barry, sorry to bother you... what am i doing wrong:
<smoser> http://paste.ubuntu.com/10506162/
<barry> smoser: in a meeting.  will look when i'm done
<smoser> thats lifed from https://oauthlib.readthedocs.org/en/latest/oauth1/client.html
<smoser> k
<Noskcaj> jpds, Are you planning to package the current release of efitools (1.5.2)? There's a fair few issues it fixes. If you do, can you drop the arches that won't build from d/control.
<flexiondotorg> cyphermox, Are you about?
<cyphermox> yes
<infinity> Noskcaj: No need to drop arches.
<infinity> Noskcaj: Having it dep-wait where gnu-efi and sbsigntool don't exist is fine, it this offending you somehow? :P
<infinity> jpds: ^
<infinity> Noskcaj: As a general rule, please don't recommend people drop arches unless the package is VERY arch-specific.  Nothing about EFI is meant to be arch-specific, and more arches should have those things working in time.
<infinity> Noskcaj: It hurts no one to have packages dep-wait or ftbfs, and it's a handy pointer to porters as to what work could be done.
<cyphermox> flexiondotorg: what's up?
<flexiondotorg> cyphermox, Hey ð
<flexiondotorg> Are you super busy?
<cyphermox> flexiondotorg: I can help
<flexiondotorg> I raised a few package update bugs earlier. Some got actioned a couple more need updates.
<flexiondotorg> Could you take a peek?
<cyphermox> flexiondotorg: could you get me a list?
<flexiondotorg> cyphermox, This one is kind of important. https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1427195
<ubottu> Launchpad bug 1427195 in ubuntu-mate "ubuntu-mate-meta package needs updating" [Critical,New]
<flexiondotorg> Get you on a list?
<cyphermox> no on.
<cyphermox> :)
<flexiondotorg> cyphermox, Lost in translation :) What do you want me to do?
<cyphermox> is this the only bug or are there more?
<cyphermox> I think Laney may have meant to do this one
<flexiondotorg> cyphermox, Well Laney was Patch Pilot today so looked at them all.
<flexiondotorg> There are 2 over.
<flexiondotorg> The meta package.
<cyphermox> ok
<flexiondotorg> And the settings - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1427182
<ubottu> Launchpad bug 1427182 in ubuntu-mate "ubuntu-mate-settings package needs updating" [Critical,New]
<barry> smoser: you need to "import oauthlib.oauth1" if you want to access a class from that submodule.  nothing special going on here, just standard python semantics (discounting os.path, which *is* a special snowflake)
<smoser> barry, yeah. i got it.
<doko> Mirv, is there an easy way to turn off PCH in the qt builds?
<doko> Mirv, in qttools-opensource-src
<Unit193> Hello.  While there is a new bugfix version, and it'd likely just be a better idea to just go to that, would someone mind taking a look at https://bugs.launchpad.net/ubuntu/+source/exo/+bug/1425972 ?  it fixes a problem with exo and the new firefox version that landed, in trusty, utopic, and vivid.
<ubottu> Launchpad bug 1425972 in exo (Ubuntu) "Firefox no longer supports -remote parameter" [Medium,Confirmed]
#ubuntu-devel 2015-03-03
<aeoril> darkxst something came up and I will be unable to fix bug 1315442.  I wanted to let you know because I said I would get it in today.  Sorry.  Thanks for all the help.
<ubottu> bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<pitti> Good morning
<pitti> bdmurray: oh sorry, must have missed that mail then
<Noskcaj> infinity, ok. For some reason i was under the impression it wasn't a package for all arches. I just keep seeing it on the ftbfs list, but it's not a real issue
<Mirv> doko_: seen in qtwebkit, not tested in qttools.. but you may try to add to debian/rules echo "CONFIG -= precompile_header" >> .qmake.conf
<Mirv> doko_: I'm seeing hints it'd be globally available, so it could just work
<jpds> Noskcaj: Feel free to do it if you want.
<dholbach> good morning
<pitti> didrocks: FYI, bug 1312976 updated with pointer to PPA and TODO list
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976
<didrocks> pitti: great! setting up :)
<pitti> didrocks: note that you need at least rpcbind from -proposed
<pitti> didrocks: https://launchpad.net/ubuntu/+source/rpcbind/0.2.1-6ubuntu2/+build/7027472
<pitti> didrocks: apparmor and console-setup will not be started with current vivid packages (see bug), but you can ignore those for a first test
<didrocks> pitti: I can grab them from -proposed anyway, clean vm install in progress :)
<pitti> didrocks: oh, you do a new install for that?
<didrocks> pitti: yeah, an independant vm with another disk
<pitti> didrocks: I usually just start (with -snapshot) adt-vivid-amd64-cloud.img
<didrocks> well, if I can get vivid to startâ¦ :/
<didrocks> seems no unity in the daily
<pitti> didrocks: err?
<pitti> didrocks: oh, you mean the desktop image
<didrocks> yeah
<pitti> didrocks: the above is the standard autopkgtest VM, i. e. just minimal stuff
<didrocks> well, screw this for now, manual qemu with the autopkgtest vm then and snaphotting
<pitti> and redirecting port 22 to not go crazy :)
<didrocks> yeah ;)
<pitti> maybe my crappy little "vm" script is worth a G+ post, /me does
<didrocks> pitti: I'm sure it worthes it :)
 * didrocks wonders with -snapshot where to specify the file to write to
<didrocks> yeah, so only temporary, I guess until we stop the vm
<pitti> didrocks: ok, done
<pitti> didrocks: you don't, qemu creates a temp overlay in /var/tmp/
<didrocks> pitti: yeah, so if you want an overlay which can survive host rebootâ¦
<pitti> didrocks: if you want to keep the changes, rather make an explicit snapshot (qemu-img snapshot -c clean-install foo.vm)
<pitti> didrocks: right, or create a new image with your original VM as a base
<pitti> didrocks: most often I don't care, so I don't know that one by heart
<pitti> didrocks: I just record the shell commands to do what I want in the VM, and paste them into ssh
<didrocks> oh, I wasn't using the -net nic
 * didrocks looks
<didrocks> pitti: ok, making sense :)
<pitti> didrocks: qemu-img create -f qcow2 -o backing_file=youroriginalvm.img overlay.img
 * didrocks logs this
<didrocks> thanks pitti, upgrading my adt machine and installing from the ppa
<didrocks> pitti: ok, updated, working here, with the hang you noted on shutdown of course (and so using system_reset to restart it)
<pitti> didrocks: this could just be because nfs-server shuts down before the unmounts
<mitya57> Mirv: I added sip4 to your FFe (as new PyQt5 needs new sip4, and old PyQt5 doesn't support Qt 5.4.1), and also added changelog links for sip/PyQt5
<pitti> cyphermox, slangasek: FYI: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup
<didrocks> pitti: even if shutdown.target will conflicts against it, maybe we can use some dep on umount.target
<pitti> cyphermox, slangasek: two missing dependencies
<Mirv> mitya57: oh, thanks, I didn't realize pyqt5 5.4.1 would have such a change
<Mirv> sip4 release mentions being required for new pyqt5, but the pyqt5 release notes I read do not mention that.
<pitti> didrocks: fixed
<didrocks> pitti: waow, already, how did you deal with this?
<pitti> didrocks: I added Before=remote-fs-pre.target to /lib/systemd/system/nfs-server.service
<pitti> didrocks: i. e. if you have server and client on the same machine, start the server first, then the NFS mounts (client)
<pitti> didrocks: and conversely on shutdown, stop the NFS mounts first, then the server
<pitti> it's certainly a corner case, but as that's merely ordering without adding deps, it should be okay
<didrocks> pitti: hum, but it means we starts the nfs server before having any network? I guess nfs copes with it
<pitti> didrocks: is that bad?
<pitti> didrocks: nfs-server still Requires: network.target
<pitti> didrocks: (not network-online.target)
<didrocks> systemd.special(7) doesn't seem to note anything wrong about it
<didrocks> so yeah, nice trick for that corner case!
<pitti> didrocks: hm, for testing server and client separately, we would now need two QEMUs which talk to each other
<pitti> didrocks: do you happen to know the magic -net invocation for that? I naÃ¯vely tried -net bridge,br=lxcbr0 (wanting to piggy-back on LXC's) but that doesn't work
<pitti> didrocks: I'd like to verify whether 24-systemd-modprobes.patch is still actually required (upstream/fedora doesn't have it)
<infinity> pitti: Here's an example of tun/tap bridged networking from a buildd: http://paste.ubuntu.com/10513248/
<pitti> infinity: oh cool, thanks
<infinity> pitti: notably, the -net nic -net tap,script stuff, and then the script itself.  Which might exist on Ubuntu in a cleaner form in /etc/qemu but doesn't on this awful Fedora base system I'm using. :P
<didrocks> pitti: I would have used the bridge option as well, just tried but without any success either
<infinity> Bonus points to the first person who recognizes the MAC address space our buildds are using. :P
<pitti> infinity: haha, Atari!?
<pitti> infinity: so Atari:leet:40, no idea about the 40
<infinity> pitti: The odds of clashing on the same physical segment with a real computer seem slim. ;)
<infinity> pitti: The last byte is assigned by the order I spun the VMs up in and assigned IP addresses, I think.
<infinity> pitti: But the real question is, did you have to look up 000036, or was that strange nugget of knowlegde stored away in that part of your memory that really shouldn't know such things?
<pitti> infinity: nah, I looked it up
<pitti> infinity: I remember a few from maintaining udev's 75-persistent-net-generator.rules, but for some strange reason I never ran into the Atari prefix :)
<infinity> pitti: Sadly, unlike PCI IDs, MACs seem to be less gimmicky, and thus harder to remember.
<infinity> (Though, there is 8086:F2, and 3C0000)
<infinity> 3C0000 being particularly cute, since that's 3C0M
<pitti> oh, nice! I would have missed the Roman numeral hint
<cjwatson> pitti: So ... we're probably at most weeks away from being able to flip the real-ddebs switch in Launchpad
<cjwatson> pitti: But we don't want to inject the existing ddebs back into Launchpad, since we're not certain enough of their provenance in all cases, so the plan per William is to make ddebs.ubuntu.com slurp from Launchpad proper rather than the buildds after we flip the switch, until such time as we've rebuilt everything (say, after 16.04) and can publish a proper full archive from LP
<cjwatson> pitti: Are you likely to have a bit of time to make the necessary ddeb-retriever changes?
<pitti> cjwatson: good to hear!
<pitti> cjwatson: I'm on VAC from March 16 to 25, but I don't expect this to be more work than a day or so; so as soon as we have some ddebs in LP (or staging) to test against, I can carve out some time
<cjwatson> pitti: I could probably do some in dogfood for you
<infinity> Could test against a PPA with ddebs.
<cjwatson> Or that
<infinity> But the primary archive is a better final test, yes.
<cjwatson> pitti: The main trick is how to do the catch-up thing; I was thinking that you could use Archive.getPublishedBinaries(created_since_date=), and remember the latest ddeb you've successfully fetched
<cjwatson> Perhaps
<cjwatson> pitti: But if you need extra stuff on the webservice, that can be arranged - we just need to know what sort of shape of thing you need
<infinity> cjwatson: I was thinking one would walk Packages.gz and map back, and keep a note of ones you've already fetched, so future runs are only getting deltas.
<cjwatson> created_since_date would achieve deltas too ...
<pitti> cjwatson: yes, that's what I was going to do; wgrant and I discussed that before, I think
<cjwatson> The problem with walking Packages is that you don't know which ones *need* ddebs.  You could certainly keep a note of the ones that fail, but the first run would be exceedingly slow
<pitti> ddeb-retriever already walks Packages.gz and creates an archive map (it has to right now), but I think created_since is fine
<wgrant> Not *fatally* slow.
<cjwatson> I don't have enough of a feel for ddeb-retriever to know which approach is best/easiest, though.
<pitti> iterating over a hundred builds a day is certainly faster than iterating over 30.000 packages
<wgrant> created_since with a bit of a fudge factor probably makes sense, but it would need care around eg. series initialisation to avoid making $lots of requests.
<wgrant> So it would probably want to keep a record locally of what it already had.
<cjwatson> Yeah
<pitti> the current approach is queue based, too -- i. e. "Fetch all ddebs from $given_day", then sort them in
<cjwatson> Damnit why is *_debug_symbols on archives a state secret
<cjwatson> Aha, ppa-self-admins to the rescue
<cjwatson> wgrant: So ubuntu.main_archive will get build_debug_symbols=True but publish_debug_symbols=False (until we have enough of the archive to do a real publisher), is that right?
<infinity> cjwatson: Unless we do a "screw old binaries, let's rebuild the world" flag day, that real publisher thing may never come.
<wgrant> cjwatson: Well, enough of the archive and archive views, really.
<infinity> I guess a gina-like import of old ddebs to glue them to the build records where they belong was just deemed too hard/dangerous?
<wgrant> Unless we want a few terabytes on $new_pepo
<wgrant> infinity: Yes, I do not want to do that unless we have no option.
<wgrant> Because we know that ddeb-retriever is fallible.
<wgrant> And the Launchpad database is a rough approximation of infallibility.
<infinity> Yeah, there may be cases where ddeb-retriever accidentally published a PPA version instead of a PRIMARY version, etc.
<wgrant> Uploading ddebs to random builds is not hugely helpful.
<wgrant> Yep, exactly.
<wgrant> So the plan is that we have a clean break and pretend that we'll rebuild everything before 16.04.
<infinity> Which we won't.
<infinity> But maybe we'll rebuild everything that matters.
<wgrant> Yep.
<infinity> Once we have an archive implementation that finally doesn't suck, I might try to find motivation to make the actual generation less hackish and contribute it back to Debian.
<infinity> Since every conversation there has just spun in circles and given them exactly nothing to show for it.
<wgrant> In the immediate term the archive generation will continue to be ddebs.ubuntu.com, as today.
<mgedmin> any thoughts about replacing ddebs with symbol servers indexed by build-id (as described in https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/)?
<wgrant> Once we have diskless archives, we can publish post-LP-enablement ddebs for very little disk space indeed.
<wgrant> (we could work out some solution to publish them physically on pepo, but that really doesn't seem worth it)
<cjwatson> pitti: So, examples: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa has build_debug_symbols=True and publish_debug_symbols=True; https://code.launchpad.net/~unity-team/+archive/ubuntu/phone-right-edge/+packages has build_debug_symbols=True and publish_debug_symbols=False.  Either should do for your purpose.
<wgrant> build_debug_symbols does what it says on the tin.
<wgrant> publish_debug_symbols is a bit more complicated: they get binary_package_publishing_history records, and they get set to Published as normal, but they never actually hit the archive pool or indices.
<pitti> mgedmin: it's a really nice way of distributing them, but I guess needs design and thinking around authentication and mirroring
<pitti> infinity: thanks for the -net tap hint, works great!
<wgrant> infinity: I was pleasantly surprised this morning to find that we don't have to SRU anything, because I made the relevant changes to pkg-create-dbgsym back in 2009...
<pitti> didrocks: FYI, http://piware.de/tools/vmbr is similar to vm, just with that -tap thing, so that VMs can talk to each other and with LXC containers
<infinity> pitti: At the end of the blog post, he suggests just enhancing Packages to list the buildids that each ddeb maps to.
<infinity> pitti: That wouldn't be an unreasonable approach, and then both "install by package" and "search by buildid" work.
<pitti> infinity: eww -- that's a *lot* of bloat
<didrocks> pitti: oh, excellent!
<pitti> I'd say that can easily double the Packages size
<cjwatson> It'd be much nicer to have something that serves the individual debug object rather than the whole ddeb, too.
<mgedmin> it also wouldn't help with getting symbols for ppa packages
<pitti> right
<infinity> pitti: It is, yes, and having the index server side instead of client side might be more pleasant, but doesn't really fit in an aptish world.
<pitti> you want http://debug.ubuntu.com/d/de/deadbeef1337
<cjwatson> Putting it in LP would let us security-proxy it so that it works for private archives etc.  But it'd be a lot of data and a fairly large new service.
<didrocks> pitti: hum, the second is saying that the device is busy though
<pitti> didrocks: hold that, it's broken
<cjwatson> (And with some kind of diskless view you could still mirror the public parts)
<infinity> It's certainly worth some thought, but without external contribution, I don't see it  happening.
<infinity> Not in a timely fashion anyway.
<sil2100> @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: sil2100
<xnox> there is a fuse filesystem for debug symbols.... when attempted to be accessed they are fetched from http server...
<pitti> slangasek: I now have working NFS under systemd, under various scenarios; bug 1312976 updated; would you like to review the debdiff and comment, or shoudl I just upload?
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976
<xnox> pitti: i have another thing to ponder with you. In ubuntu dbus-daemon is shipped in /bin, rather than /usr/bin.
<xnox> pitti: however i do not believe this to be necessory, if not wrong.
<pitti> xnox: yeah, ancient modification; probably because upstart needs it early on?
<pitti> (I never knew/understood why we need it)
<pitti> it's certainly not wrong, but a moderately annoying delta when merging
<xnox> pitti: the comment from keybuk was "start it earlier" -> but in practice all dbus daemons are in /usr/
<xnox> pitti: upstart doesn't need it, as it opens it's own private bus socket and uses that. And it does operate fully without dbus-daemon ever getting started.
<xnox> (unlike systemd/logind)
<pitti> and under sytsemd dbus starts After=basic.target, i. e. after local-fs.target
<xnox> pitti: upstream we are pondering to move /etc/dbus-1 -> /usr/share/dbus-1, and a question came up whether this will or will not "break ubuntu's /bin"
<xnox> pitti: yeap.
<xnox> pitti: i want to move dbus back to /usr, may i test & prepare a patch to do so?
<pitti> so from my POV I'm happy to drop that delta -- it has caused some pain in various places
<xnox> pitti: /server work under systemd" [High,In progress] https://launchpad.net/bugs/1312976
<xnox> * darkbasic_ (~quassel@niko.linuxsystems.it) has joi
<ubottu> Launchpad bug 1312976 in nfs-utils (Ubuntu) "Make NFS client/server work under systemd" [High,In progress]
<xnox> bah, bad url
<xnox> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=89280
<pitti> xnox: go ahead
<ubottu> Freedesktop bug 89280 in core "support ignore_missing attribute in the includedir element, and use that to support all default configuration in datadir" [Normal,New]
<pitti> xnox: the previous was a copy&paste error? or does that apply to NFS?
<xnox> pitti: copy&paste error.
<pitti> xnox: and yay for throwing out /etc/dbus-1/system.d!
<pitti> (or all such policies, really)
<xnox> pitti: =)
<pitti> a user can put an updated one into /etc, but we shouldn't put the defualt ones there
<xnox> pitti: that's what my patches there achieve.
<pitti> \o/
<xnox> pitti: ditto patches to systemd -> to make policies generate .want symlinks in /run, rather than /etc.
<xnox> pitti: and a bunch of similar patches for other projects as well.
<LocutusOfBorg1> hi sil2100 did you already upload vbox?
<xnox> not everything is forwarded to upstreams yet.
<LocutusOfBorg1> feel free to rename the patch if you didn't already upload the package
<LocutusOfBorg1> yes, a number might be better for future uploads
<xnox> pitti: i see upstartisms in dbus.postinst =/
<xnox> pitti: is there a way to do archive-wide scan for these?
 * xnox guesses lintian.
<pitti> xnox: where?
<pitti> looks fine to me at first sight
<xnox> pitti: http://paste.ubuntu.com/10514296/
<pitti> xnox: ah, so s/status/service/?
<xnox> pitti: well, and then check for return code, rather than 'upstart formatting of pid #' and need to check that service status under both upstart & systemd outputs the same exit codes.
<xnox> pitti: do you have lintian lab or some such way to scan all .deb's maintainer scripts to make sure they don't call initctl / upstart naked commands?
<xnox> q
<xnox> ZZ
<xnox> :wq!
<pitti> I don't, no; do we still have the codesearch setup for ubuntu?
<xnox> pitti: well i only provide dns for it http://ubuntu-codesearch.surgut.co.uk/ and it points into 502 inside canonistack.
<xnox> Laney: are you running codesearch still?
<Laney> nein
<xnox> Laney: warum nicht? =)
<LocutusOfBorg1> hi all :)
<Laney> keine zeit
<Laney> basically it kept breaking
<Laney> the easiest way I know of atm is to ask j_dstrand to do a grep for you
<xnox> Laney: well, i want to grep for "upstartisms" in the .deb maintainer scripts.
<xnox> Laney: e.g. dbus postinst calls "status dbus | ...." for a non-upstart specific code-path.
<Laney> I believe you have a good usecase
<Laney> but I'm afraid that codesearch isn't deployed atm :(
<pitti> flexiondotorg: did you ever happen to run MATE under systemd? any problesm there which would block switching to it by default?
<Laney> maybe we could at some point look at doing it again
<xnox> pitti: i still have bits that are not ported on the phone for pid1 systemd.
<xnox> pitti: so at least touch, should be kept on upstart for the time being.
<pitti> xnox: yeah, phone won't switch for sure
<pitti> xnox: just added a work item and discussed with ogra in #u-touch
<pitti> xnox: most touch devices have too old kernels (3.4), that'll block the switch until touch moves to a newer android
<xnox> pitti: really? why? what's needed / missing?
<ogra_> pitti, i doubt we will ever get a newer android for the released phones
<ogra_> and even then it is doubtful that they will have any newer kernels
<xnox> pitti: can't we just patch xattr support back in? http://cgit.freedesktop.org/systemd/systemd/commit/?id=d2edfae0f9bdbecf6a8518e2a5bcf06f470e0d9e&ss=1
<flexiondotorg> pitti, I'm also an Arch TU so I've been running MATE on systemd for a couple of years now ð
<pitti> yeah, I wasn't saying "next week", this will still be a few years in the worst case
<ogra_> i think the only way would be to backport missing bits
<flexiondotorg> pitti, We did the systemd support for MATE a good while back.
<xnox> pitti: or like backport xattr support for cgroups.
<pitti> flexiondotorg: right, but I meant on Ubuntu? I don't expect problems, but I'd like to get a confirmation from each flavor that it doesn't break stuff
<flexiondotorg> pitti, The transition from Ubuntu 14.10 to 15.04 was seamless. No systemd issues that I've encountered.
<ogra_> xnox, our prob here is that porters will have to do the same ... we dont want that porting turns into a kernel patching orgy
<flexiondotorg> *from Ubuntu MATE 14.10 to 15.04
<xnox> ogra_: it already is, e.g. we mandate apparmor.
<pitti> flexiondotorg: the default is still upstart, you need to opt-in (boot systemd in the grub menu or isntall systemd-sysv)
<xnox> flexiondotorg: 15.01 doesn't use systemd-sysv yet.
<flexiondotorg> pitti, Confirm systemd looks good on Ubunut MATE 15.04 currently :)
<pitti> flexiondotorg: ok, thanks!
<ogra_> xnox, right, patching our apparmor in means essentially "delete the upstream apparmor folder in your tree and copy ours in place"
<tjaalton> pitti: I'd say upload nfs-utils now, it doesn't affect current upstart users anyway
<flexiondotorg> xnox, pitti You say systemd is not default?
<flexiondotorg> How do I fully opt it exactly?
<ogra_> xnox, if we can make the systemd patching as easy, then yes, not an issue ... but i fear it will take a bit more there
<xnox> flexiondotorg: correct, you need to install systemd-sysv packge to test that ubuntumate works with systeemd as pid 1.
<pitti> flexiondotorg: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems
<cjwatson> well no you don't
<cjwatson> you can just as well use the grub menu entry
<flexiondotorg> pitti, So I can modify my seeds and rebuild then?
<pitti> the wiki page shows both methods
<flexiondotorg> pitti, Will gladly test that.
<pitti> flexiondotorg: nah, not necessary
<pitti> flexiondotorg: also, you can't -- ubuntu-minimal is shared between flavours
<xnox> cjwatson: true, but that wouldn't catch things that calls "/sbin/init" expecting to start upstart user session and things like that. Although, I believe i fixed all of those by now.
<flexiondotorg> pitti, OK, understood.
<xnox> (e.g. lightdm greeters spawning "init --user" to run indicators.....)
<pitti> also, these ^ shoudln't be desktop specific, but better safe than sorry :)
<flexiondotorg> pitt, I'll do an inplace test now.
<flexiondotorg> pitti, xnox Is the switch to systemd planned for 15.04?
<mardy> pitti: hi! I'm a bit rusty with dbus python: I want to return a DBus error from a mocked method, how do I do that?
<pitti> flexiondotorg: yes, still; I'm currently writing an FFE
<sil2100> LocutusOfBorg1: ouch, already uploaded it as it was...
<pitti> slangasek: FYI, filed bug 1427654
<ubottu> bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,New] https://launchpad.net/bugs/1427654
<sil2100> LocutusOfBorg1: might consider re-uploading or something, but I suppose it shouldn't be a big problem
<sil2100> @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:
<xnox> pitti: i'm not sure if $ service dbus status -> is useful under systemd.
<pitti> xnox: why not?
<xnox> pitti: well, i guess i will use systemctl -q is-active dbus
<xnox> pitti: service dbus status -> outputs a bunch of colored output and exits zero.
<pitti> right, and it exits with 3 for non-running jobs
<ogra_> just write an AI that can judge the colors
<pitti> >/dev/null obviously required :)
<pitti> tjaalton: yeah, it's tempting, but I guess I'll give slangasek at least a chance to review before I upload
<xnox> pitti: ok that should work. let me check this under upstart as well and switch to service command then.
<pitti> mardy: look into e. g. the bluez4.py template: raise dbus.exceptions.DBusException('org.foo.bar', 'not foobarized')
<pitti> xnox: so what Debian does should actually work fine?
<pitti> xnox: calling /etc/init.d/dbus is not the most efficient as it needs to go through the lsb script, but it should work
<pitti> but *shrug*, it's not like it matters
<xnox> pitti: well, "$ service dbus status" under upstart gives: "dbus stop/waining" and exits 0
<xnox> =(
<pitti> bah
<xnox> (in a single user mode, as otherwise stopping dbus under upstart brings the systemd down)
<pitti> yeah, try that with anacron or somethign harmless :)
<xnox> pitti: i'm not proud http://paste.ubuntu.com/10514602/
<flexiondotorg> pitti, pitti install systemd testing is going well on Ubuntu MATE. Actually resolves a shutdown issue I've been having :)
<pitti> xnox: hm, that still doesn't work for Debian under sysvinit? can we do a "if <runnign under upstart> status else /etc/init.d/dbus status"?
<pitti> xnox: also, why doesn't /etc/init.d/dbus status work? /lib/lsb/init-functions.d/01-upstart-lsb shoudl divert it to status already?
<xnox> let me check exit codes.
<pitti> flexiondotorg: nice, thanks! once you are sufficiently convinced that it doesn't break stuff, woudl you mind sending something like "confirming that MATE works with systemd" to bug 1427654?
<ubottu> bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,New] https://launchpad.net/bugs/1427654
<xnox> pitti: (a) 01-upstart-lsb is in ubuntu only (b) /etc/init.d/dbus status exists zero here under upstart and dbus not running.
<pitti> ok, so 01-upstart-lsb is broken
<pitti> xnox: I guess Debian doesn't care much about this, and we can drop that delta next cycle (hopefully), so then just go with your's
<flexiondotorg> pitti Will do.
<flexiondotorg> pitti I noticed that plymouth didn't appear. Is this by design?
<flexiondotorg> pitti, I only ask because I remember the back lash when Arch switched to systemd.
<xnox> flexiondotorg: depends if plymouth is integrated correctly on mate.....
<xnox> flexiondotorg: it works under systemd on ubuntu-unity
<flexiondotorg> pitti, Just need to know if I need to find my flame proof trousers again.
<flexiondotorg> xnox, Prior the adding systemd I have a slow boot and Plymouth. After adding systemd VM boot waaaaay faster.
<flexiondotorg> Thinking I might not be seeing plymouth because X was hammered up that much quicker.
<pitti> flexiondotorg: no, should work
<xnox> there is plymouth in VMs.
<flexiondotorg> pitti, Thanks.
<pitti> plymouth in VM is a bit fiddly, though
<mardy> pitti: excellent, thanks!
<flexiondotorg> xnox, VirtualBox VM with Ubuntu MATE in it.
<pitti> flexiondotorg: often the VM is too fast, and you don't actually see it; or the graphics driver (like qemu's default one) causes some corruption
<pitti> it usually shows better on real iron, or with e. g. qemu's -vga std
<flexiondotorg> pitti, xnox - Anyway to test Ubiquity install with systemd installed?
<pitti> flexiondotorg: yes; append "init=/bin/systemd" to the kernel command line in gfxboot
<flexiondotorg> Of course. Thanks.
<pitti> flexiondotorg: i. e. press a key to get the menu, press F6 to get the expert menu, press Esc twice to close it again
<pitti> flexiondotorg: then you can edit the kernel command line
<pitti> flexiondotorg: (I tested that on ubuntu a few months ago)
<flexiondotorg> pitti Yep, done it.
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<flexiondotorg> pitti, One issue with systemd enable during install.
<LocutusOfBorg1> sil2100, maybe I can rename in the next upload :)
<flexiondotorg> pitti, When I click restart it does just that. No prompt to remove the media.
<LocutusOfBorg1> or I can ask -release to reject but I guess it should be fine
<LocutusOfBorg1> I do not really care about them
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<pitti> flexiondotorg: ah, bug report appreciated; thanks for testing!
<doko> jamespage, which packages build-depend on gccgo-go? just juju-core?
<doko> https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1427676
<ubottu> Launchpad bug 1427676 in juju-core (Ubuntu) "juju-core should drop the b-d on gccgo-go and libgo5, using gccgo instead" [Undecided,New]
<flexiondotorg> pitti, Will test some more befre I raise bugs.
<doko> pitti, jibel: looks like a lot of the i386 perl related autopkg tests need a give back
<cjwatson> This is why I always sync perl by copying it into a devirt archive and then copying with binaries to the main archive ...
<doko> noticed for the future ...
<cjwatson> After one too many situations where I wound up with perl being uninstallable and unbuildable in -proposed
<pitti> doko: yep, I got the bunch of errors, I'll lean on the retry button
<jdstrand> pitti: hey, fyi re bug #1312976, apparmor may load files from /var
<ubottu> bug 1312976 in console-setup (Ubuntu) "Make NFS client/server work under systemd" [Undecided,In progress] https://launchpad.net/bugs/1312976
<pitti> jdstrand: hey
<jdstrand> pitti: is /var expected to be nfs-mountable?
<pitti> jdstrand: ah, and we want to support NFS on /var?
<jdstrand> that's the question
<pitti> jdstrand: ok, we could flip that around, if we don't care about protecting all the NFS stuff by apparmor?
<jdstrand> I don't think I can answer that-- I'm not up on the issue
<jdstrand> pitti: so, when cache loading hits and we have proper systemd support for apparmor, the initscript would become a second stage loader to update the cache. I thihnk it could have remote_fs then
<jdstrand> but we don't have that right now, so not sure what the best course of action is in this transition period
<jdstrand> sbeattie: fyi (systemd/apparmor backscroll) ^
<pitti> jdstrand: ah, ok; so I'll see to breaking the dep cycle in some other way
<jdstrand> ok, it seems like it might be easier for now
<jdstrand> well and in the future :)
<pitti> jdstrand: ok; I was a bit concerned about your "start apparmor as early as possible" request, but if you are happy with starting NFS before, I'm ok with that
<pitti> fun, that's the third time when the need for a /cache/ pops up
<pitti> i. e. early-boot cache which is guaranted to be available without NFS, separate partitions, and stuff
<jdstrand> pitti: happy is strong. we will have apparmor start as early as possible with the cache loading work
<pitti> jdstrand: well, then the cache can't go on /var
<jdstrand> it is a bit unfortunate for the initscript since there are profiles available for portmap iirc
<jdstrand> there are two caches> system cache in /etc and snap/click cache in /var
<pitti> jdstrand: ah, so once we split the startup scripts into system/click that'd work?
<jdstrand> maybe
<pitti> jdstrand: cache in /etc/ is really ugly too, though
<pitti> jdstrand: perhaps /lib/apparmor/ ?
<pitti> jdstrand: hwdb.bin is a similar case, I ended up putting it into /lib/udev/
<jdstrand>  /etc is a historical artifact
<jdstrand> we've discussed moving /etc/apparmor.d/cache in the past. looks like we'll need to discuss it again
<jdstrand> the thing is-- currently snaps with systemd jobs have their cache in /var/cache/apparmor. I think those units all have Requires=apparmor.service
<jdstrand> so they should be ok
<pitti> jdstrand: on snappy and touch that shouldn't matter at all; we ship a single root fs, no /var on NFS
<jdstrand> but I feel like we need to revisit the cache locations and timing of things for when libapparmor supports cache loading (and therefore systemd can use it)
<jdstrand> tyhicks: fyi (please see backscroll for last 15 minutes or so)
<pitti> jdstrand: ok, so for now you want me to revert that, and have NFS start before apparmor?
<jdstrand> pitti: I think for today, that is the best option
<pitti> and we revisit after the cache work/job split?
<pitti> jdstrand: ack; thanks for the heads-up! sorry for the misunderstanding
<jdstrand> pitti: I noticed on snappy the other day dhclient was running unconfined. if we don't land the cache work, we'll need to deal with that in some way. perhaps some of that thinking might be put towards portmap profile
<jdstrand> pitti: thanks for the discussion-- now we'll think about it and discuss it as upstream
<doko> xnox, boost ping
<xnox> doko: yo, what about it?
 * xnox doesn't recall a boost ping - you mean gcc5 fixing?
<doko> =)
<doko> xnox, afaiu 1.57 is ready for GCC 5
<xnox> doko: *sigh*
<xnox> doko: i could transition, but in W not in V
<doko> yeah, v is a bit late ...
<xnox> doko: well, and debian experimental i guess
<pitti> jdstrand: hm, that's tricky; this means that network.target, pollinate, and more all need to sort themselves before apparmor, on really early boot
<doko> tjaalton, you're the X guy, aren't you? xauth gained new b-d's. could you file MIR's?
<doko> didrocks, https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1394731   this still has the recommends. is this intended?
<ubottu> Launchpad bug 1394731 in grilo-plugins (Ubuntu) "[MIR] grilo-plugins" [Undecided,Fix committed]
<didrocks> doko: I guess the deal was to not promote that binary
<didrocks> darkxst: that's right, isn't it? ^
<smoser> hey..
<smoser> i have a problem seems like might ave been solved before.
<smoser> curtin runs in python2[.7] or python3.
<smoser> cloud-images in vivid no longer have python-yaml (python2)
<smoser> cloud-images in precise do not have python3-yaml (or python3 at all).
<tjaalton> doko: ok
<smoser> what i'd like is a /usr/bin/python3or2 that ran 3 if possible, otherwise ran 2
<smoser> i'm guessing that is a problem that someone else has seen  and solved.
<smoser> barry, ^ maybe ?
<pitti> jdstrand: just for the rationale: currently /var/cache/apparmor/ is empty for me -- why is it needed to have /var for apparmor?
<pitti> jdstrand: (other than on touch/snappy where /var on NFS isn't an option)
<doko> smoser, I don't think this can work, because you can't ensure that every module is provided for one interpreter
<barry> smoser: the windows launcher has that iirc.  it's been discussed several times in various python forums, but so far nothing exists for *nix afaik
<pitti> jdstrand: i. e. right now the cache actually is in /etc/? or am I missing anything?
<smoser> doko, well, with the help of a 'python -m some_checker_module' you could.
<slangasek> pitti, cyphermox: ok, looks like we should just drop the console-setup-freebsd binary package, thanks for the pointer
<tjaalton> cjwatson: do you remember why our xauth is marked M-A: foreign? to fulfil some cross-arch dependency?
<smoser> and in this simplistic case , it'd be good enough to 'python3 -c "sys.exit(0)"' as a test.
<barry> make be should call it /usr/bin/python2.8 :)
<barry> *maybe we* -- jeebus
<cyphermox> slangasek: agreed, I was working on that just now
<slangasek> cyphermox: great, I'll leave you to it
<pitti> jdstrand: also, /etc/init/apparmor.conf runs before NFS and mounting /var too?
<jdstrand> pitti: /etc/apparmor.d/cache is for any profiles in /etc/apparmor.d. profiles shipped in debs are put in /etc/apparmor.d/
<doko> smoser, but how do you express this using package dependencies?
<jdstrand> pitti: /var/cache/apparmor is for any profiles in /var/lib/apparmor/profiles. profiles for clicks and snaps are generated and put in /var/lib/apparmor/profiles
<pitti> jdstrand: right; my question was (1) what is in /var/cache/apparmor (I don't have that here), and (2) if that's important, how does /var on NFS work under upstart?
<ogra_> pitti, click app profiles
<ogra_> (which we plan to support on desktop iirc)
<pitti> ogra_: right; but I still fail to see how you can have /var/lib/apparmor on NFS under upstart
<pitti> it's a pretty drastic cyclic dependency
<pitti> (and we don't currently have it)
<ogra_> no idea, i havent use NFS in 8 years or so :)
<pitti> /etc/init/apparmor.conf is "start on starting rc-sysinit", it makes no effort to wait for NFS or /var etc.
<ogra_> (on the phone it has ano override ... that set "start on lightdm")
<ogra_> err
<ogra_> start on startin
<ogra_> g
<jdstrand> pitti: I don't recall if NFS /var and apparmor worked with apparmor. perhaps mdeslaur recalls? istr we may have discussed it
<cjwatson> tjaalton: It can be depended on to provide an interface (i.e. /usr/bin/xauth), isn't coinstallable with other versions of itself, and that interface isn't architecture-dependent; that's reason enough
<cjwatson> tjaalton: I expect there was probably a dependency or build-dependency somewhere that made this useful, yes, though I don't remember what
<cjwatson> tjaalton: Oh, I filed a Debian bug and gave some reasoning.  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695087
<ubottu> Debian bug 695087 in xauth "xauth: Please mark Multi-Arch: foreign" [Wishlist,Open]
<jdstrand> pitti: apparmor aside, I think we are getting back to the previous question-- is NFS mounted /var even expected to work on Ubuntu at all?
<jdstrand> and I don't have an answer to that
<pitti> jdstrand: I don't know :/
<jdstrand> seems logging would break pretty hard
<mdeslaur> pitti: yes, but rc.sysinit is start on filesystem
<pitti> well, people might expect it :) but I have no idea whether it actually works
<jdstrand> slangasek: hey-- is /var mounted on NFS supposed to work?
<mdeslaur> pitti: filesystem includes local-filesystems and remote
<smoser> doko, yeah, from a package perspective not easily solved.
<pitti> mdeslaur: ah, ok; so under upstart we also let rpcbind, the nfs daemons, pollinate, and whatnot run before, so that we can't apparmor-protect them?
<pitti> we can do that, it just seems the wrong way around to me
<mdeslaur> pitti: right, but we do need to protect the dhclient that gets run as part of the network interface coming up
<jdstrand> with upstart we had a bunch of patches for updating upstart jobs
<slangasek> jdstrand: I'd say it's known to not work, because of /var/lib/nfs
<jdstrand> slangasek: oh, heh
<mdeslaur> pitti: which is why apparmor cache is in /etc, and not in /var
<pitti> mdeslaur: but then /etc/init/apparmor.conf would run too late?
<jdstrand> mdeslaur: so, there is /var/cache/apparmor for clicks/snaps. we may need to rethink that
<ogra_> pitti, bug 525154 claims it worked once (after this was fixed)
<ubottu> bug 525154 in nfs-utils (Ubuntu Natty) "mountall for /var or other nfs mount races with rpc.statd" [High,Fix released] https://launchpad.net/bugs/525154
<pitti> mdeslaur: right; I think it's correct to have apparmor caches on the root fs (just perhaps not in /etc/, but that's a different question)
<slangasek> jdstrand: there are some things that can be moved to /run (and have been), but /var/lib/nfs is used for the lock state across reboots... not sure what we do with that, except for perhaps breaking lockd
<mdeslaur> pitti: yes, which is why we have apparmor hooks in a whole slew of other upstart jobs and the ifup scripts
<tjaalton> cjwatson: oh good, I'll check that and commit it there if pkg-xorg doesn't oppose
<jdstrand> our goal with proper apparmor cache loading and systemd is to clean all this up
<mdeslaur> jdstrand: yes, but at that point, /var is guaranteed to be mounted
<jdstrand> mdeslaur: yes, but when we have the libapparmor patches, it may not be
<mdeslaur> jdstrand: oh, wait, you're using that for snaps now, yeah, that's no good
<mdeslaur> jdstrand: it was ok with click packages, but not for snaps
<jdstrand> mdeslaur: snaps are actually covered cause they depend on apparmor
<jdstrand> in their job file
<jdstrand> Requires=apparmor.service
<pitti> (After=, I hope)
<jdstrand> After=apparmor.service
<jdstrand> yes, both
<mdeslaur> jdstrand: and apparmor depends on all the local filesystems?
<mdeslaur> including /var?
<jdstrand> mdeslaur: well, that is what pitti is looking at
<pitti> mdeslaur: local-fs, yes
<mdeslaur> right
<pitti> mdeslaur: the question was about $remote_fs -- i. e. if /var is on NFS
<pitti> IMO we should not have caches which we require on early boot on a potential NFS dir, it's just crying for trouble
<pitti> (and as you said yourself, it's a pain to get to work)
<mdeslaur> right
<jdstrand> mdeslaur: I think we need to discuss this with tyhicks and sbeattie. we should be collecting the requirements here and add them to what we know, then come up with a plan
 * jdstrand has to go to a meeing
<mdeslaur> jdstrand: the plan is to move apparmor to the right place in systemd
<pitti> well, we could split it
<jdstrand> mdeslaur: yes. and that may mean we move dirs around
<pitti> /etc/init.d/appamor for loading /etc/apparmor for early boot, and another one for /var for clicks etc.
<pitti> (or keeping /etc/init.d/apparmor for the late one, and an apparmor-early for the early boot)
<jdstrand> we already know we need 2 stages: first to load caches, and the next to regenerate the caches in case they are out of date
<pitti> or declare that you can't have click/snap packages with /var on NFS
<jdstrand> (since libapparmor will only load caches, not compile them)
<mdeslaur> yeah, we could split it out
<mdeslaur> but if /var on nfs is known not to work at the moment, perhaps we don't care
<pitti> it's not known to work; it hasn't been shown to not work
<pitti> mdeslaur: the trouble would only be with /var on NFS on a system which uses click, right?
<cjwatson> tjaalton: Probably shouldn't, I expect it's just an oversight - I think pkg-xorg has accepted other similar stuff from me
<pitti> but on the pro side we'd have all the networking/NFS/portmap/DHCP parts covered
<jdstrand> we really want all those parts covered
<flexiondotorg> I've just fixed the following bug - https://bugs.launchpad.net/ubuntu-mate/+bug/1422402
<ubottu> Launchpad bug 1422402 in ubuntu-mate "Shell Command Injection in places.py plugin of mate-menu package" [High,Fix committed]
<tjaalton> cjwatson: indeed
<mdeslaur> pitti: what about /usr on nfs?
<flexiondotorg> I would like to raise a bug to package a new version of mate-menu.
<pitti> mdeslaur: that's just sheer madness :)
<mdeslaur> does that work and so people do that?
<jdstrand> what we have with upstart now is a confusing mess. I mean it works, but it is hard to keep straight. not something you really want when dealing with loading security policy
<flexiondotorg> Should it be flagged as security related given the bug it addresses?
<mdeslaur> ok, good, didn't know what is typically done
<pitti> mdeslaur: more seriously, I haven't seen it, and I don't believe that it works until I see it
<pitti> mdeslaur: AFAIR in the last meeting we said that /usr/ on a separate partition must work, but /usr on NFS can't
<mdeslaur> pitti: ok, cool
<pitti> mdeslaur: for once all the nfs/rpc daemons are in /usr/sbin :)
<mdeslaur> do we know what is causing the dhclient race?
<pitti> ah no, not all of them
<pitti> some are in /sbin/
<doko> neutron-lbaas: python-neutron-lbaas
<doko> [Reverse-Depends: neutron-lbaas-agent (MAIN)]
<doko> zul, jamespage: ^^^ did the source change?
<zul> doko: yeah it got split out into its own tree upstream
<doko> ok, thanks
<doko> Mirv, qtbase-opensource-src recommends qttranslations-opensource-src (universe). MIR or suggests?
<tyhicks> mdeslaur: no - we don't know what is causing the race yet
<doko> barry, there's a lot of python* component mismatches. could you have a look? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<tyhicks> mdeslaur: steve is supposed to be looking at it more this week
<barry> doko: i'll look.  i don't know when i'll have time to do anything about it :(
<doko> Laney, you uploaded remmina, needing two MIR's
<Laney> I think not
<Laney> that nx thing shouldn't be in main
<doko> Laney, at least your name is on the changelog ;-P
<Laney> demote it (with remmina-dbg)?
<doko> Laney, so demote the binary?
<Laney> go for it
<Laney> thanks
<pitti> kees, slangasek, stgraber, infinity: TB meeting in 2 mins (reminder)
<pitti> mdeslaur: ^
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> kees, slangasek, stgraber, infinity, mdeslaur: TB meeting in 3 mins, this time for real :) (sorry for confusion)
<slangasek> :)
<mdeslaur> hehe
<slangasek> stgraber: I think you're on for chairing today?
<pitti> slangasek: would you like to review the nfs patches, BTW?
<pitti> or should I just upload them?
<slangasek> pitti: in principle yes, but I don't think I'd be able to get to it today
<pitti> slangasek: in the next days would be enough; I started the FFE, and we have some other thigns to be done for that
<pitti> Unit193: did you test current xubuntu under systemd? (Given how much we talked about it, I suppose yes, but just to avoid doubts..)
<ericsnow> quick question: is vivid going to switch to using systemd for PID 1 at some point?
<Odd_Bloke> ericsnow: I've heard that it's expected to happen some time in the next week.
<ericsnow> Odd_Bloke: ah, thanks
<Odd_Bloke> ericsnow: *waves hands*
<ericsnow> :)
<doko> Logan, infinity: the librdkafka sync broke powerpc. this probably needs to be restored
<Logan> I'll take a look
<Logan> doko: yeah, looks like Adam's patch needs to be restored
<Logan> doko: shall I do an MP? I don't have upload access to main
<doko> Logan, please check with infinity, eod for me
<Logan> sure :)
<Unit193> pitti: And still running under it, yep.  There seems to have been a couple glitches, but nothing consistent.
<Noskcaj> Is anyone planning to merge meta-gnome3? It would be nice to have it updated for our current gnome packages
<jtaylor> mh someone know how one subscribes to the glibc list?
<jtaylor> ah found it, hidden away on the website not the list archive ..
<smoser> is this bug known? https://bugs.launchpad.net/ubuntu/+bug/1427821
<ubottu> Launchpad bug 1427821 in Ubuntu "server iso install fails during grub install" [Critical,Confirmed]
<smoser> i dont know if it applies to server iso or not.
<smoser> er... if it applies to desktop or not.
<smoser> i  kind of suspect not.
<infinity> smoser: Not a bug I'm aware of, will have to give it a try later.
<cyphermox> smoser: that looks like a fun bug
<doko> tumbleweed, online?
<doko> tumbleweed, what is the rationale for a separate /usr/lib/pypy hierarchy?
<tumbleweed> doko: hi
<tumbleweed> you mean dist-packages-wise?
<doko> tumbleweed, yes
<tumbleweed> incompatible .pyc files. One would be using __pyshared__ and the other wouldn't
<tumbleweed> unless we'd symlink-farmed
<tumbleweed> and there's no reasonable way to do transitive dependencies
<doko> well, cpython looks up __pycache__, why not pypy?
<tumbleweed> in 3.x, yes
<tumbleweed> I plan to share dist-packages for 3.x
<doko> yeah, that would be really useful
<doko> are you at PyCon?
<tumbleweed> been meaning to talk to you about that
<tumbleweed> yes, I will be
<doko> let's meet before PyCon, or at the sprints
<tumbleweed> only arriving on the thursday, but I'll be at the sprints
<staylor> I'm curious about a good way to handle an issue I'm having, I have an amd64 host and have used multilib to install arm cross compilers and libraries but since -dev libraries install the .so library links yet can only be installed for a single arch I'm wondering how to handle this (short of manually creating the symlinks).
<dobey> multi-arch packages are installed in the proper places
<dobey> but if you want to cross-compile .deb packages, you should probably look at just using sbuild to do it
<infinity> staylor: Chroots are the way to go, one for native, one for each cross arch.
<infinity> staylor: Having one messy base system that attempts to build for everything will end in misery.
<staylor> I don't see what's messy about software installing itself logically but I guess chroot is the only way right now.
<dobey> everything in the archive doesn't support multi-arch yet
<dobey> so it gets messy quickly
<staylor> is moving .so from -dev to the base lib package something that's on the roadmap though?
<dobey> why would one move .so from -dev to the base lib package?
<dobey> it's possible to install -dev and -dev:armhf for packages that support multi-arch
<staylor> I see okay I didn't realize nothing supports multiarch yet
<dobey> lots of things do
<dobey> i don't know what you're specifically dealing with though. and building packages in clean chroots is always best anyway
<staylor> well glib for one, but I concede chroot seems the way to go
<dobey> the number of times people have built debs locally "just fine" and then had the builds fail in a PPA because they forgot to add things to build-depends, is innumerable
<dobey> ah, the problem with libglib2.0-dev is that it has some things in /usr/bin
<dobey> so that creates conflicts when you try to install the dev package for another arch
<staylor> yeah for packaging I see what you mean and that makes perfect sense, here I am setting up a cross compile environment for developers needing to target arm boards from their workstations so different needs and expecations.
<dobey> still, chroots are better and make management easier
<Bluefoxicy> infinity: if I gave you a reliable way to install multiple conflicting versions of a .so on a system so you could have different applications use different versions, how useful would that be?
<tmpRAOF> Bluefoxicy: Are you describing SOVER?
 * tmpRAOF is not sure if serious.
<Bluefoxicy> tmpRAOF:  https://github.com/bluefoxicy/dpkg-ng/blob/master/README.md
<Bluefoxicy> tmpRAOF:  I never got anywhere because I have nfc what i'm doing :3
<Bluefoxicy> I mean, rewriting dpkg is kind of a big task
<Bluefoxicy> tmpRAOF: the way Nix does it is silly.  If your binary uses 40 libraries, it puts in 40 runpaths pointing to very specific versions of the packages.
<tmpRAOF> So, the Debian library packaging policy makes âinstalling different versions of the library and link different applications against themâ work.
<Bluefoxicy> I figured you would just make the runpath point at /usr/package/$PACKAGE/$VERSION/lib/ first
<Bluefoxicy> tmpRAOF: you can install conflicting libs?
<tmpRAOF> Absolutely.
<tmpRAOF> Or, rather, you can install libfoo3 and libfoo2 at the same time, and dependencies will be resolved appropriately.
<Bluefoxicy> no
<Bluefoxicy> libfoo3 installs /usr/lib/libfoo.so.3
<Bluefoxicy> libfoo2 installs /usr/lib/libfoo.so.2
<sarnold> see e.g. libssl0.9.8 and libssl1.0.0 ..
<Bluefoxicy> but how do you install libfoo3.1 and libfoo3.1.1?
<tmpRAOF> Bluefoxicy: The immediate question is âwhy do you want to?â :)
<Bluefoxicy> how do you install libmysql.so.5 from Percona and libmysql.so.5 from Mariadb?
<tmpRAOF> Ah.
<Bluefoxicy> tmpRAOF:  sometimes you have non-backwards-compat libraries
<tmpRAOF> Bluefoxicy: Right, and in that case it's up to the *library* package to change from libfoo2 to libfoo3.
<Bluefoxicy> tmpRAOF:  This would happen basically constantly if you had a rolling release, too
<tmpRAOF> It absolutely doesn't; Debian Sid manages just fine.
<tmpRAOF> So, as I see it, Nix satisfies the âI want my program to link against _exactly_ the code that I've tested it againstâ desire.
<tmpRAOF> Which is a perfectly reasonable one.
<Bluefoxicy> yeah, though I think the NixOS guys are insane
<tmpRAOF> Regular distros satisfy the âI want my program to work, and benefit from bug fixes in my dependencies without me rebuilding every time one of my dependencies changeâ desire, which is also perfectly reasonable.
<Bluefoxicy> it'd make more sense to have e.g. percona-5.2 look in /usr/packages/percona-5.2/lib for libraries first, and put anything specifically selected for percona as a symlink there
<Bluefoxicy> i.e. normally, that directory would be empty or non-existent
<jtaylor> kind of like limba?
<jtaylor> install everything at once but each app only sees the set it wants
<jtaylor> http://people.freedesktop.org/~mak/limba/
<Bluefoxicy> if your package manager goes, "You can't upgrade $LIBX because Percona will break, and you can't install $FOO because it requires a newer $LIBX", it shuffles current $LIBX into /usr/packages/libx-1.0.0/lib/libx.so.1 and symlinks to it from percona's lib; upgrades libx; and installs foo
<Bluefoxicy> because screw that; conflicts shouldn't prevent me from having two pieces of software installed at the same time
<Bluefoxicy> jtaylor: interesting.
<jtaylor> conda also has a similar approach
<tmpRAOF> Bluefoxicy: How does the package manager know that you can't upgrade libX?
<Bluefoxicy> tmpRAOF:  Conflict:
<tmpRAOF> Bluefoxicy: So libx version 1.1 needs to Conflict with all the packages it might potentially break?
<tmpRAOF> Why isn't it bumping SONAME?
<Bluefoxicy> tmpRAOF:  dpkg notes that you need some lib = some version, > some version, < some version, etc; and that some libs can't be installed at the same time; etc.  It has a pretty complex dependency resolution system that sometimes tells you you need to remove some packages to install others, or that you can't install two things at the same time because they depend on things that can't be installed at the same time.
<tmpRAOF> Ah, so *percona* has a Depends: libx = 1.0?
<Bluefoxicy> eh, percona, maria, and mysql are special cases
<Bluefoxicy> tehy all install libmysql
<Bluefoxicy> they all REPLACE each other
<Bluefoxicy> of course, you get the oddness where libx from some package replaces libx from another, and adds extensions.  Different extensions from another replacement.  Then you get dependencies on one or the other by specific applications, which can't be simultaneously installed.
<Bluefoxicy> it's been a while since I've actually cared
<Bluefoxicy> I was more trying to gauge if it seemed relevant to anyone at this point.
<Bluefoxicy> The last time I remember it being relevant to everyone in the world, all at once, was when gtk+ was dealing with 1.2 vs 2.0, because gtk+ breaks backwards binary compatibility a lot.
<infinity> Bluefoxicy: The solution to people not bumping their SOVER is to bump their SOVER, not reinvent the wheel.
<infinity> Bluefoxicy: And the github-style "use this exact version, or else" mentality is a security vulnerability nightmare.  No sane person should try to replicate it, but instead educate them.
<Bluefoxicy> infinity: thats' why I think the nix approach is insane, versus a "this specifically doesn't work unless you use this version" approach
<infinity> Bluefoxicy: percona/maria/mysql is a non-problem, FWIW, the servers don't need libmysqlclient, and the clients can all use the one from mysql.
<infinity> Bluefoxicy: And, again, if that changes, the SONAME should too.
<Bluefoxicy> rtue
<Bluefoxicy> true
<Bluefoxicy> so the current solution is to eliminate all situations where packages have any conflicts, so that all packages in the repository can be installed simultaneously on one system
<infinity> We define stable ABIs for a reason, if upstreams break that, we educate them.
<infinity> Eliminating all conflicts is a bit harder, and pretty pointless.
<infinity> Why do you need 7 things that all provide /usr/sbin/sendmail?
<Bluefoxicy> heh
<Bluefoxicy> good point
<infinity> Anyhow, the forking library case (like percona/maria) is a pretty uncommon one, and the answer is for them to change the SONAME if they stop being compatible with libmysqlclient.
<infinity> But the GTK example you pointed out is a non-issue, 1.2 and 2.0 could always be installed together.
<infinity> They couldn't be linked together in the same memory space, but that's a problem no matter how clever you make your filesystem layout, you just need to make sure you don't accidentally do that. :P
<Bluefoxicy> pizza delivery special instructions
<Bluefoxicy> "Leave the pizza in front of the door; then turn around and walk away slowly.  Don't look back."
<Bluefoxicy> infinity: there was an issue for a while where you had to recompile for gtk+ in the 1.2 days.  Some commercial applications (AIM, Yahoo Messenger) broke because they were compiled against a prior minor point release.
<Bluefoxicy> they enjoyed keeping the same function calls and such so your code would work, but changing structures used internally.
<Bluefoxicy> as a result, malloc(sizeof(opaque_struct)) would allocate the wrong size
<Bluefoxicy> or whatever else
<Bluefoxicy> it was incredibly bad programming practice
<Bluefoxicy> maybe people have been beaten enough to learn not to do that in the past 10 years
<jtaylor> no, even glibc devs still do that ;)
<jtaylor> (see s390x abi break in 2.18 or 19)
<Bluefoxicy> yes but that's drepper
<sarnold> jtaylor: surely they called all six users to give them a heads up? :)
<Bluefoxicy> jtaylor: tell Drepper next time he breaks s390x, he has to publish a Youtube documentary of his p90x
<infinity> It hasn't been drepper for a long time.
<jtaylor> drepper is not involved since a while
<Bluefoxicy> looks like I'm very out of date
#ubuntu-devel 2015-03-04
<infinity> jtaylor: To be fair, the s390x ABI break (and a SuperH ABI break I need to commit) was widely discussed, and everyone went into it with eyes wide open.
<infinity> jtaylor: It would never happen on x86, because there's zero chance of getting everyone to recompile everything.
<Bluefoxicy> that's the best way t oget a gnat in your eye
<jtaylor> yeah, I guess if debian wouldn't test s390x no one would have noticed
<jtaylor> or cared
<Bluefoxicy> yeah but debian is insane
<Bluefoxicy> they even have an x86-freebsd distro now
<Bluefoxicy> I often think Debian builds for architectures just for the hell of it
<jtaylor> this topic is somewhat offtopic for this channel though
<Bluefoxicy> yeah I was just trying to probe a simple question
<Bluefoxicy> it always turns into a huge philosophical debate when I do that
<infinity> hallyn_: I'm no expert, but I expect that adding a patch to debian/patches/README instead of debian/patches/series probably won't apply it?
<infinity> hallyn_: Oh, nevermind, it's simple-patchsys.  Ew.
<hallyn_> infinity: :)
<Mirv> dobey: I'd say MIR, not a high maintenance package with purely language pack like content
<pitti> Good morning
<Unit193> Howdy.
<pitti> hey Unit193, how are you? thanks for confirming
<Unit193> pitti: Sure.  Only seen the random "session out of sync" issue (can't reboot, suspend, poweroff, etc.) and some strange bug on upgrade that unmutes and sets the volume to 90%, but otherwise smooth sailing.
<pitti> Unit193: but the logind one should be fixed now, right?
<pitti> volume> that's nothing that the init systemd touches, I'm afraid
<Unit193> Haven't seen it within the past week or two.  And figured it might be systemd/logind as it seemed to hit only with systemd upgrades, but no matter.
<pitti> smoser, utlemming: oh, cloud images switched to systemd already? there are some "unable to connect to upstart" messages, and they hang now; is that from https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1072-0ubuntu1 or was the init system changed in the image build process?
<pitti> ah, they are timing out trying to talk to 169.254.169.254
<pitti> hm, odd, http://cloud-images.ubuntu.com/vivid/current/vivid-server-cloudimg-amd64.manifest shows that it has upstart, and no systemd-sysv; but the output is definitively systemd
<pitti> ah, init=/lib/systemd/systemd
<pitti> filed bug 1427999 to track this
<ubottu> bug 1427999 in cloud-init (Ubuntu) "cloud images don't boot with systemd" [Undecided,New] https://launchpad.net/bugs/1427999
<tmpRAOF> Hey, anyone feel like giving a second-opinion on https://code.launchpad.net/~afrantzis/mir/automate-package-abi-versioning/+merge/251442 ?
<tmpRAOF> I'm uncomfortable with the extent of debian/control generation, and it's location, but maybe other people are more sanguine :)
<dholbach> good morning
<pitti> cjwatson: could I pick your brain about seed handling? (bug 1428026)
<ubottu> bug 1428026 in ubuntu-touch-meta (Ubuntu Vivid) "fork required/minimal seed to keep upstart as init system" [Undecided,New] https://launchpad.net/bugs/1428026
<pitti> cjwatson: i. e. do I need to copy required (for keeping upstart) and minimal (no actual change) to ubuntu-touch.vivid as {required,minimal}-touch, and adjust STRUCTURE accordingly, or is there an easier way?
<pitti> also, I'm not sure whether we shoudl actually build an ubuntu-minimal-touch package; we could just fold everything into ubuntu-sdk and ubuntu-touch, as on touch you can't individually uninstall/upgrade them anyway
<pitti> ogra_: ^ do you have an opinion on this? or "I don't care"?
<ogra_> pitti, as long as we dont regress in any way and as long as the new way is slightly documented (with a mail or so) i'm in the "don't care" dept.
<ogra_> it is not like minimal changes a lot
<pitti> ogra_: ack, thanks; I'm leaning towards the "put all dependendies into ubuntu-touch", I don't see much value in having an ubuntu-touch-minimal binary metapackage
<pitti> (as soon as I figure out how to do either solution.. :) )
<ogra_> right, just make it a clear section in the seed file
<ogra_> you might want to check with the SDK guys, not sure if they need minimal in their builder chroots (i dont know how the SDK creates them)
<pitti> ogra_: how do you mean? add a comment to it that says that the only difference should be upstart vs. systemd-sysv?
<pitti> ack
<ogra_> pitti, no add a caption at the bottom "minimal" or some such ...
<pitti> ogra_, cjwatsonL
<pitti> erk
<pitti> ogra_, cjwatson: http://paste.ubuntu.com/10524629/ is my first attempt, but that's apparently not sufficient yet
<ogra_> and add them below ... i.e. dont merge them alphabetically in the other sections in the touch seed or some such :)
<pitti> ogra_: oh, I didn't move them around (see pastebin); I don't know whether the order matters, but I'm fine with reordering them
<pitti> (I just don't understand what you mean)
 * pitti <- seed n00b
<ogra_> pitti, ah, i thought you would just add them to the "touch" file
<pitti> ogra_: hm, wouldn't that make them harder to maintain? I thought in STRUCTURE I could just add the "dependency"
<ogra_> though i see that would break sdk-libs
<pitti> and I don't wnat to copy them into both sdk-libs and touch
<ogra_> yeah, i didnt know there were other "required" deps
<doko> jamespage, zul:  libvirt-daemon isn't packaged in libvirt. looks like the package was never merged
<doko> tjaalton, you synced freeipa, now ftbfs on powerpc and ppc64el, stuck in -proposed
<Odd_Bloke> pitti: Where/how are you booting those cloud images?
<pitti> Odd_Bloke: locally in QEMU (adt-buildvm-ubuntu-cloud)
<pitti> Odd_Bloke: i. e. with a local seed .iso image
<tjaalton> doko: ok, I'll have a look
<pitti> cjwatson: my current progress is in https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1428026/comments/1 but I'm afraid now I really need your help
<ubottu> Launchpad bug 1428026 in ubuntu-touch-meta (Ubuntu Vivid) "fork required/minimal seed to keep upstart as init system" [Undecided,New]
<doko> tbb: you synced tbb, now ftbfs on arm64, powerpc, ppc64el
<doko> Logan: you synced tbb, now ftbfs on arm64, powerpc, ppc64el
<cjwatson> pitti: Aren't we going to have terrible problems getting debootstrap to do the right thing during image builds?
<pitti> cjwatson: yeah, that would have been my next question -- how does ubunut-minimal actually land on images, given that it's not a dependency of anything
<pitti> debootstrap doesn't install ubuntu-minimal, or does it? it's priority: important, not required
<cjwatson> debootstrap installs Priority: important stuff, unless you take special measures to tell it not to.
<pitti> I would have assumed that ubuntu-minimal is hardcoded somewhere in the touch image build process, and it would need to change to ubuntu-minimal-touch
<pitti> ah, so that's how it gets there
<cjwatson> Avoiding ubuntu-minimal is Really Hard.
<cjwatson> I mean, as it happens, the touch build process does hardcode ubuntu-minimal (in livecd-rootfs)
<cjwatson> But I'm fairly sure it's there already by the time that takes effect ... would have to check build logs
<pitti> cjwatson: aye, confirmed that debootstrap pulls in ubuntu-minimal
<pitti> cjwatson: that might explain why "init" is required/essential in Debian, but systemd-sysv or sysvinit-core aren't
<cjwatson> pitti: I will have to think about this; how to express it in the seeds is a secondary concern
<pitti> cjwatson: do alternatives work in seeds, i. e. could we change ubuntu-minimal to "systemd-sysv | upstart" and explicitly seed upstart in ubunut-touch?
<cjwatson> pitti: Well, Essential isn't transitive, but required is
<cjwatson> pitti: No
<cjwatson> pitti: We could manually hack the ubuntu-meta source package to express that, but I'd prefer to explore other options first
<pitti> then as a third option we could replace upstart with "init" in ubuntu-minimal, and seed upstart in touch?
<pitti> and promote init to main and to required
<cjwatson> pitti: That might work, but will still require the build process to remove systemd-sysv when installing upstart, which it may not be willing to do
<cjwatson> pitti: systemd-sysv is functionally Priority: required in Debian according to debootstrap, even if the overrides don't say that
<pitti> *nod*
<cjwatson> That's just a lazy ftpmaster bug :)
<caribou> I'm fixing a Universe package that is synced from debian. Should I remove debian's Uploader: field in the control file and only leave the XSBC-Original-Maintainer ?
<cjwatson> caribou: Just run update-maintainer
<cjwatson> (which leaves Uploaders alone)
<caribou> cjwatson: hmm thanks; didn't know about this one
<darkxst> didrocks, doko, grilo-plugins-extra should stay in universe, just -base is getting promoted to main
<cjwatson> pitti: The third option will potentially leave germinate a bit confused, but it *might* not matter
 * pitti sends a summary to the bug
<pitti> cjwatson: so it seems the main thing to test is whether the image build process gets along with replacing systemd-sysv with upstart; can this be tested locally somehow?
<cjwatson> pitti: It can with some effort, but I'm still caffeinating and thinking about this
<pitti> cjwatson: woudl it help if I put the ubuntu-minimal upstart->init and adding "upstart" to ubuntu-touch changes in a PPA?
<pitti> (we also need to seed systemd-sysv on ubuntu-standard then, so that we actually get this on upgrades; but I'll test that myself)
<cjwatson> pitti: Not really
<cjwatson> Too many variables confounding the test when PPAs are involved
<cjwatson> (At least at that level)
<infinity> pitti: Did you decide against using the "init" package to mirror the Debian setup?
<pitti> infinity: we haven't really done any decision wrt. "init"; just mostly ignored it so far
<cjwatson> I think, at least, having ubuntu-minimal depend on init is a good idea at minimum for this, because it will mean we don't have to remove ubuntu-minimal to make ubuntu-touch work.
<infinity> Oh, I see, the touch/non-touch split makes it a Very Bad Idea to make anything Essential.
<cjwatson> init doesn't have to be Essential, just used as indirection from ubuntu-minimal.
<pitti> infinity: we merely updated its dependencies to reflect ubuntu's init systems (no sysvinit, upstart the defualt), but even the package description is still wrong :)
<cjwatson> Although it wouldn't hurt *this* part of it if it were.
<infinity> cjwatson: Well, init as Essential (which it is in Debian), and then dropping all but the systemd dep seemed like a simple way to force the issue on upgrade.  But that's not what touch wants, so that wouldn't work.
<cjwatson> Both touch and non-touch would have init, just its dependencies satisfied in a different way.
<pitti> at least it needs to be in main, and at the same time we coudl also fix its priority?
<cjwatson> Its priority will be (semi-)magically fixed after it's seeded in the place we want.
<pitti> infinity: right, hence my other idea of adding systemd-sysv to ubuntu-standard
<pitti> (standard isn't on touch)
<infinity> pitti: I guess if we take the view that any system without standard installed isn't ubuntu proper, and thus we don't care if upgrades do the switch...\
<pitti> I tested upgrade with upstart -> systemd in ubuntu-minimal (in a PPA); I expect it to work the same way with init+systemd-sysv in standard, but of course I'll test that again
<cjwatson> standard is an option, but I'm a bit wary of having to chase up other debootstrapped environments that historically expect an init.
<infinity> cjwatson: init as Essential fixes debootstrap.
<infinity> cjwatson: The standard dep is just how pitti proposes forcing the switch.
<cjwatson> infinity: Sure, in which case it would also be in ubuntu-minimal.
<pitti> yeah, with "init" it would have some init
<cjwatson> infinity: Oh, umm, pretty sure germinate-update-metapackage would filter that
<cjwatson> It'd have to be written manually in ubuntu-meta/debian/control
<infinity> That's not rocket surgery.
<pitti> so ubuntu-minimal is on touch+desktop+server and has "init", ubuntu-standard is not on touch and has systemd-sysv, ubuntu-touch has upstart
<infinity> And could be dropped post-16.04
<pitti> cjwatson: you mean it would filter out an explicit upstart or sytemd-sysv seed?
<cjwatson> Yeah, because it won't include stuff that's already effectively in inner seeds
<cjwatson> But as I say it can be written by hand
<pitti> ah, so that wouldn't affect -touch, but -standard, I see
<cjwatson> Probably both actually
<cjwatson> pitti: So as I read it that leaves two questions: (1) is that enough to fix upgrades, (2) will the touch build process work with this scheme
<pitti> as upstart isn't in the "inner seed"
<cjwatson> Er, yeah, you're right
<pitti> cjwatson: right; I'm happy to test (1), that's easy; I'm not sure how to test  (2) without actually having it in the archive
<pitti> for (1) I'm going to prepare a PPA, but you said that doesn't help with (2)
<cjwatson> I can test (2)
<cjwatson> It only needs testing that the relevant apt-get line DTRT
<pitti> we need to promote init to main for that, right?
<cjwatson> I can set it up by hand
<cjwatson> But for actually implementing this, yeah
 * pitti promotes it, should be harmless
<infinity> ... he says, before triggering an apt bug.
<pitti> at worst the next archive admin will demote it again in a few days, if we don't update the seeds by then?
<infinity> mvo_: Did we ever hunt down that weird apt bug that seemed to cause a massive sad on upgrades when the required/essential sets changed?
<pitti> infinity: is that just your usual optimistic self, or do you actually know an apt bug that gets triggered by thaht?
<pitti> eek
<pitti> well, promoting to main doesn't change hte optional priority yet, that'll just appear in priority-mismatches.txt
<mvo_> infinity: I'm not sure, do you have a example issue? if so I can have a look
<infinity> mvo_: We had examples long ago.  Remember it happened when I made util-linux depend on initscripts to force initscripts into the Essential set, and the world exploded?
<infinity> mvo_: And we had to back that out a day or two before release.
<infinity> mvo_: I think you set up reproduction environments at the time and such, but then probably got sidetracked with Other Things and stopped being my whipping boy. :P
<pitti> tseliot: good morning!
<tseliot> pitti: good morning to you
<pitti> tseliot: FYI, the nvidia-304 regression with the new kernel is tracked in bug 1427924 now
<ubottu> bug 1427924 in nvidia-graphics-drivers-304-updates (Ubuntu) "autopkgtest failures if nvidia dkms module fails to build" [High,Triaged] https://launchpad.net/bugs/1427924
<infinity> mvo_: Annoyingly, it didn't break on small-scale upgrades (like buildd chroots or minimal schroots), but apt shot itself in the head doing desktop upgrades after the Essential set changed.
<tseliot> pitti: good, as I'm going to fix it today
<mvo_> infinity: I think that particular one got fixed, but I need to dig into the logs, there was one issue right before 14.04 that sounds a lot like this
<pitti> tseliot: I'm not sure whether we should drop the tests from u-d-common, given that they are useful to spot these (I do agree they run at the wrong time)
<infinity> mvo_: But maaaaybe this was actually a weird side-effect of the "command line too short, breaking loop detection" bug, which you fixed, right?
<tseliot> pitti: I think we should keep them. As - somehow - I didn't catch the failure in my chroot
<infinity> mvo_: Seems plausible, given that small upgrades worked, but large ones broke.
<tseliot> pitti: I've just read slangasek's comment though
<cjwatson> pitti: OK, I can't be absolutely certain as there's some probably-unrelated confusion here with packagekit, but it looks OK to me, once I hit it only slightly harder it's happy to remove systemd-sysv
<pitti> cjwatson, infinity: https://launchpad.net/~pitti/+archive/ubuntu/systemd has the above changes now (seeding init in minimal, adding systemd-sysv to ubuntu-standard, adding upstart to ubuntu-touch)
<cjwatson> let's try your PPA to see
 * pitti tests upgrades from trusty and utopic now
<mvo_> infinity: I think 2f58969150b0daec1de407f61385ccf5b2065aa3 was a fix for the preconfigure issue, the ordering code was buggy, I'm not sure if I ever tried this with the old bug we had back in the day
<cjwatson> pitti: Hmm, I still seem to have to say "apt-get install ubuntu-touch upstart packagekit"
<cjwatson> It's not happy with just ubuntu-touch on its own
<cjwatson> http://paste.ubuntu.com/10525402/
<pitti> cjwatson: that's in which environment now?
<cjwatson> debootstrap
<infinity> mvo_: Am I just dreaming, or didn't you also crank up DPkg::Max{Bytes,Args} too, to fix some "upgrading lots of packages causes bad breaks in loops" issues?
<pitti> ah; my last test just directly changed the ubuntu-minimal dep, and apt was happy enough to replace the package (after fixing ureadahead)
<cjwatson> debootstrap vivid, install systemd-sysv, then upgrade to your PPA and put ubuntu-minimal back, then try to install ubuntu-touch
<cjwatson> However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful
<pitti> cjwatson: that's not just because init is still in universe?
<cjwatson> pitti: No I forced that
<tseliot> pitti: the reverse dependencies test makes a lot of sense to me
<cjwatson> installed init
<cjwatson> pitti: Still, I think this plan is the closest we're likely to get to a right answer, and it's mostly trivial to implement in seeds
<infinity> cjwatson: "apt-get install ubuntu-touch systemd-sysv-" would probably be more elegant, to preserve apt's manual/auto ideas.
<cjwatson> infinity: Yeah, true
<cjwatson> infinity: Still something odd with packagekit, I don't understand that
<pitti> I get http://paste.ubuntu.com/10525435/ on apt-get dist-upgrade from trusty and utopic, to vivid+PPA; looks okay
<infinity> pitti: Note that do-release-upgrade isn't apt-get dist-upgrade, so might behave slightly differently.
<pitti> infinity: yeah, I'll check that next; but plain dist-upgrade also ought to work
<infinity> But given that it tries hard to make sure metapackages stay installed, it's likely going to get the right result.
<infinity> pitti: I agree, dist-upgrade should work.
<pitti> ok, so I debootstapped vivid, added universe and PPA, upgraded (installed init and new ubuntu-minimal)
<pitti> indeed apt-get install ubuntu-touch now fails on packagekit
<infinity> pitti: And "apt-get install ubuntu-touch systemd-sysv-"?
<cjwatson> Yeah same
<cjwatson> http://paste.ubuntu.com/10525468/  from earlier
<cjwatson> (ok, upstart vs. systemd-sysv-, but should be the same for this purpose)
<cousteau> https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972 -- seems fixed, when will it make it into libexo-helpers on the repos?
<ubottu> Launchpad bug 1425972 in exo (Ubuntu) "Firefox no longer supports -remote parameter" [Medium,Confirmed]
<infinity> cjwatson: Not necessarily.
<cousteau> also, will it be on Precise as well?
<pitti> I get some more issues with other packages, but likely just follow-ups of upstart: http://paste.ubuntu.com/10525469/
<cjwatson> infinity: it had the same end effect.  I'll get problem resolver output once I've rebootstrapped
<cjwatson> pitti: Yeah those are all consequences
<cjwatson> pitti: Add systemd-sysv- and then it works
<pitti> confirmed
<pitti> so we need another package to depend on upstart, to bump its scores, or so?
<cjwatson> pitti: 10:27 <cjwatson> However, the worst case from this is that we have to hack livecd-rootfs a little bit, it isn't actually awful
<pitti> yeah, I saw that, I was just wondering if there's a better way
<cjwatson> I would actively prefer that over fragile score guesswork
<pitti> ah, initramfs-tools-ubuntu-touch and others also depend on upstart, so it should already have plenty of dependencies
<cjwatson> So http://paste.ubuntu.com/10525503/
<pitti> cjwatson: but all in all this looks more promising than trying to split ubuntu-minimal{,-touch}, WDYT?
<cjwatson> I completely agree
<cjwatson> These are comparatively minor issues
<pitti> ok, so AFAICS we can add the upstart seed to -touch and change the minimal seed to "init" right now, and they should be no-ops (except for getting the additional empty "init" metapackage)
<cjwatson> Yeah
<pitti> and the live-build change too, as long as systemd-sysv isn't actually installed
<pitti> then the flip woudl just be to upload init with switched dependencies, and add it to ubuntu-standard
<pitti> and -touch would be prepared to keep upstart
<cjwatson> livecd-rootfs but yes
<cjwatson> Yep
<pitti> agreed, sounds like a plan
<pitti> cjwatson, infinity: many thanks for your help!
<pitti> cjwatson: OOI, is there a syntax for purge? with - it'll get removed, but not purged, right?
<pitti> mvo_: ^
<pitti> mvo_: i. e. "apt-get install foo-" removes foo, is there a "purge foo"?
<cjwatson> pitti: Not AFAIK, but doesn't matter in this case since systemd-sysv has no postrm.
<cjwatson> So remove == purge
<pitti> ok
<cjwatson> Though apt-get --purge install foo- works
<cjwatson> But passing that through live-build is probably a pain
<pitti> it's no big deal anyway, I just wondered
<mvo_> pitti: what cjwatson said, if you need a real purge via "pkgname-" I can do that too
<mvo_> pitti: but early lunch first :)
<pitti> mvo_: ack, thanks
<pitti> mvo_: nah, not a biggie; --purge is fine
 * sil2100 silently pokes didrocks regarding a certain endorsement request
<sil2100> ;)
<didrocks> apw: hey, I have some questions on name_to_handle_at vs overlayfs. I see that it's supposed to be supported (from http://goo.gl/OJoowv), but when I'm using a simple example (like the one on the manpage) on our livecd, I'm getting errno == EOVERFLOW, any idea?
<didrocks> sil2100: oh, mind if that waits on Friday? Sorry about the delay
<ogra_> sil2100, you mean he's as bad a slacker as i am ?
<ogra_> that cant be !
<sil2100> didrocks: no worries, any time in the nearest few weeks is fine
<didrocks> good :)
<sil2100> ;)
<sil2100> ogra_: uh oh!
<sil2100> I'm just kindly poking, no haste ;)
<ogra_> heh
<davmor2> ogra_: no one is as bad a slacker as you dude ;)
<ogra_> hmm, probably true :)
<pitti> cjwatson: ./update says "? Unknown required package: init" (http://paste.ubuntu.com/10525662/), seems we need to adjust the priority beforehand?
<apw> didrocks, what code is using that call, as i expect it to be handled by the underlying fs
<davmor2> ogra_: if it isn't a device you don't care about it.  Maybe if they made it snappy, you'd write his review to test that the snap worked, maybe that is the way round it ;)
<pitti> cjwatson: ah no, perhaps the mirror is just slightly out of date wrt. the promotion to main; http://archive.ubuntu.com/ubuntu/pool/main/i/init-system-helpers/ is fine, but I'll try a bit later
<ogra_> davmor2, lol
<cjwatson> pitti: Yeah, that's about presence not priority
<didrocks> apw: I just tried t_name_to_handle_at.c from man name_to_handle_at
<didrocks> apw: context is, tracking a systemd issue when it detects all individual files as mount point in systemd code when used over overlayfs, I'm using that code as the source of this issue ^
<apw> didrocks, it seems to be returning ENOSUPP for me
<apw> didrocks, on overlayfs, not EOVERFLOW
<didrocks> apw: sorry, you're right, it's just that it returns -1 as expected
<apw> didrocks, well it failed, as expected
<didrocks> apw: so, I guess this is expected that overlayfs doesn't support it
<didrocks> hum, I wonder how I can detect if a file is a mount point (meaning, I guess, in that context, being overridden)
<didrocks> apw: the systemd logic is to test a path, test the parent path, and check mount_id
<didrocks> the fallback is using stat()
<didrocks> and comparing st_dev
<apw> which sounds ok ?
<apw> oh perhaps not if the path is a file and the parent a directory
<didrocks> apw: yeah, that exactly what happens here, path is file, parent a dir
<apw> its not clear that name_to_handle_at would work any better if it did work of course
<apw> this seems like an odd way to work out what is a mountpoint to me, then again it is systemd
<didrocks> apw: I'm not debating how it is working ;) but yeah, tracking down a crash due to this
<doko> ScottK, Riddell: https://projects.kde.org/projects/playground/libs/libqinfinity/repository libqinfinity needs an update for the new libinfinity in proposed. are there official tarballs available, or should a snapshot be packaged?
<pitti> xnox: ah, apparenlty we have some hardcoded dbus-daemon paths (http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-notify-osd/38/ARCH=amd64,label=adt/console), I'll look
<apw> didrocks, i am unsure if we have any good way to detect this right now ?
<caribou> I would need a sponsor for openafs-modules-dkms on Trusty : it no longer build following a kernel struct change
<xnox> pitti: i know, uploaded at-spi2-core
<xnox> pitti: once that's rebuild, notify-osd test will need a rerun.
<caribou> the bug seems to be impacting many people
<pitti> xnox: ah, yay you
<didrocks> apw: just run a test, and I confirm that st_dev is different if path == file from parent == dir.
<didrocks> apw: hum, yeah, seems tricky to even think of a workaroundâ¦
<didrocks> the easiest way would be to take another file (if any) into the same dir, but doesn't seem efficientâ¦
<Riddell> doko: what's the new version of libinfinity it needs to work with?
<doko> Riddell, 0.6.5
<didrocks> apw: the fact that major = 0 will only be return by dirs on overlays or am I on crack?
<didrocks> no, tmpfs would as wellâ¦
<pitti> slangasek: hm, you test-forced http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-libtest-requiresinternet-perl/ although the history makes it pretty clear that this is not just a random failure
<caribou> apw: maybe the openafs sponsoring should be looked at by someone from the kernel team; it's a dkms build failure
<pitti> the uninstallables caused by the perl upgrade still hold it in -proposed, but otherwise it would go in
<caribou> .
<apw> caribou, oh goody
<caribou> apw: https://bugs.launchpad.net/bugs/1423151
<ubottu> Launchpad bug 1423151 in openafs (Ubuntu Trusty) "openafs-modules-dkms 1.6.7-1: openafs kernel module failed to build" [Medium,In progress]
<caribou> apw: main part of the patch is one single commit, but I had to bring in two #defines so it would build
<Riddell> doko: there's no new releases, do you know if it compiles with git snapshot? why is this being updated after FF? it's only used by an experimental plugin so qinfinity can be removed if it has to be
<xnox> pitti: see the commit message in hints https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu
<xnox> 910. By Steve Langasek 6 hours ago
<xnox> Override failures from libtest-requiresinternet-perl; discovering that you
<xnox> have no Internet is a perfectly valid test result from a module whose
<xnox> purpose is *to detect whether or not you have Internet*.
<xnox> pitti: i'm subscribed to that branch =) very useful stuff to get notified about.
<pitti> xnox, slangasek: well, something is still wrong; the same package/test succeeds for me locally on vivid (in teh schroot runner), and fails on vivid-proposed
<Riddell> doko: upstream says.. 11:25 < scummos> Riddell: it has been a while but I think I ported it to 0.6, but did not release it yet
<Riddell> 11:25 < scummos> libqinfinity-0.5 does not work with 0.6.5
<doko> Riddell, it was uploaded on 2015-01-22, way before feature freeze. I can't help if you guys don't address things in -proposed ...
<pitti> xnox, slangasek: sorry, it fails in both, but it both cases the test does have internet..
<Riddell> doko: I asked about a git snapshot 11:26 < scummos> Riddell: if that is possible for you, yes, and I will try to get a release for 0.6 some day
<pitti> xnox: I'll ignore the upstart failure for dbus; that's not the new dbus' fault
<pitti> cjwatson: oh, is this alright? minimal/i386: Skipping package init (package not in debootstrap)
<xnox> pitti: at-spi2-core seems to be in, can you re-queue notify-osd test (unless you already have, I only see "public" jenkins)
<pitti> cjwatson: the pacakge is clearly there now (wget -qO- http://archive.ubuntu.com/ubuntu/dists/vivid/main/binary-i386/Packages.bz2| bzcat -cd |grep '^Package: init$')
<pitti> xnox: done 2 mins ago
<xnox> pitti: tah.
<didrocks> apw: do you think I should just return False or bail out if the system is overlayfs?
<apw> didrocks, well not knowing why systemd cares to know, it is hard to say
<pitti> xnox: ah, I got upstart to succeed again after 6 retries..
<didrocks> apw: this is a common functionality for some units to have a ConditionIsMountPoint=<path>. We are using it as /etc/machine-id is not writable if empty at systemd startup (due to our ro mount, contrary to fedora and others), so systemd will overmount it as tmpfs. Then, we detect in a service (triggered by that ismountpoint condition) and do the swapping to a committed rw version to persist across reboots
<didrocks> for snappy
<didrocks> apw: but basically, this is just one example, maybe we will have other services using ConditionIsMountPoint=
<cjwatson> pitti: Ah, *now* it needs to have its priority promoted first
<pitti> ah, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt :)
<pitti> cjwatson: ack
<didrocks> I'm fine to bail out in that specific case, but that wouldn't fix for other services if they expects mount points to perform their operations
<cjwatson> pitti: Go ahead and do that, wait a publisher run, retry
<pitti> cjwatson: *nod*, thanks
<pitti> xnox: notify-osd success, so dbus should go in now
<ogra_> pitti, hmm
<pitti> ogra_: I'm scared if you say "hmm"!
 * pitti hugs ogra
<ogra_> pitti, i'm not sure you should add upstart to the desktop file in the touch seed
<ogra_> this is the base of desktop-next
<pitti> ogra_: that's for desktop-next, isn't it? aren't these system images?
<ogra_> no, isos afaik ...
<pitti> ogra_: I seede it to touch-core
<ogra_> Laney, seb128 ^^^^
<ogra_>   * Added upstart to desktop, touch. This ensures that we keep upstart on
<ogra_>     Touch even when we switch Ubuntu to systemd. (LP: #1428026)
<ubottu> Launchpad bug 1428026 in ubuntu-meta (Ubuntu Vivid) "change seeds to keep upstart as init system on Ubuntu Touch" [Undecided,In progress] https://launchpad.net/bugs/1428026
<pitti> ogra_: so at most it's over-cautious, but I'm not sure anyone ever tested desktop-next with systemd yet
<ogra_> i was just commenting to your chanelog entry
<ogra_> definitely nobody i think
<ogra_> but i also think it wants to use the standard core system
<ogra_> tricky one :)
<Laney> If the jobs left to port are phone/android/whatever specific then it's probably fine
<pitti> ogra_: right, so we'd move upstart from touch-core to touch
<Laney> but someone should check before we do the switch there I guess
<pitti> for now I thought we'd rather switch stuff step by step
<ogra_> Laney, right, i thinnk there will be some that arent ported even for the non phone specific stuff
<pitti> a few more stuff has direct upstart dependencies, like initramfs-tools-ubuntu-touch (but that's in touch-android, so we're fine)
<pitti> ogra_: yes, for sure
<ogra_> right
<pitti> although, xnox' property watcher fixes are for android only
<pitti> anyway, not too many fronts at once, please :)
<ogra_> i dont think -next uses properties
<ScottK> doko: I don't see any commits in the repository newer than the current release (about 6 months ago)
<pitti> ogra_: right, no android container I presume
<ogra_> misses the android backend :)
<pitti> ogra_: but thanks for bringing it up; it seems to me that moving touch-core is a nice intermediate step
<xnox> pitti: hm, i don't like that at-spi2-core is valid candidate, yet dbus is not. the two should go in together.....
<pitti> ogra_: argh, of coruse I mean s/touch-core/desktop-next/
<ogra_> pitti, ok
<pitti> xnox: ah, no versioned deps/breaks?
<xnox> pitti: nah, no change rebuild =)))))
 * xnox is good like that
<ogra_> pitti, i assume you want a test image build once everything landed ?
<pitti> ogra_: it's still a no-op, so not that interesting; but can't hurt indeed
<ogra_> well, i guess you want to at least make sure that trying to remove systemd-sysv doesnt make the build fall over if it isnt installed
<pitti> ogra_: right; unlikely, but good to verify
<cjwatson> I'm pretty confident in that, but indeed, good to verify
<cjwatson> http://paste.ubuntu.com/10526088/
<pitti> xnox: btw, dependencies did save you somehow :) (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
<ogra_> looks good
<pitti> xnox: i. e. now it's accepting both in the same run, before that at-spi2-core was held back due to uninstallability
<ogra_> interesting that you had to add packagekit ...
<cjwatson> I don't understand that bit, but it wasn't worth a lot of time investigating
<cjwatson> If mvo_ gets round to finishing the native-dbus work in click then packagekit goes away anyway
<cjwatson> (Which probably has to happen for desktop-next?)
<cjwatson> And we have to finish the native-dbus work before packagekit is upgraded under our feet to a version that no longer supports plugins
<ogra_> right, i just dont get why it is explicitly needed, it is seeded in touch-core
<xnox> cjwatson: re:native-dbus work in click -> what's that about?
 * xnox is happy to do dbus work.
<cjwatson> Well, that makes it a dependency of ubuntu-touch, but apt probably hasn't worked that out yet :)
<ogra_> ah
<cjwatson> xnox: https://code.launchpad.net/~cjwatson/click/native-dbus but mvo_ had something on top of that
<cjwatson> I don't think it needs significant extra code at this point IIRC, but I also don't know exactly where it's sitting
<cjwatson> https://code.launchpad.net/~mvo/click/native-dbus
<cjwatson> mvo_ probably got eaten by snappy before remembering to finish it :)
<ogra_> haha
<ogra_> now i finally get the namin scheme
<cjwatson> the point was to stop relying on packagekit's dbus interface, which click only ever used in the first place because it was expedient
<ogra_> +g
<cjwatson> but it's a bit awkward for various reasons, it means people have to remember to use pkcon and "click install" doesn't just DTRT internally
<cjwatson> and it's unsustainable because packagekit has removed the "plugin" facility in newer upstream versions, which the current design utterly relies upon
<cjwatson> so if we give click its own dbus service, then we can ditch the dependency on packagekit entirely and simplify the dependency structure, so we no longer have the awkward conflict with aptdaemon
<cjwatson> however it's a three-step thing: first we add the native dbus service to click, then we whack-a-mole all the stuff that's using pkcon or possibly even packagekit's dbus service directly to interact with click packages, then we remove the packagekit plugin from click
<cjwatson> I planned this all out towards the end of last year, but then got burned out and moved to LP
<apw> didrocks, yes, i can see it is an issue not being able to implement that check, i just right now don't have any answers
<didrocks> apw: ok, I'll get the workaround in for now for that specific case, keep me posted if you can think of anything
<pitti> Odd_Bloke, smoser, utlemming: I updated bug 1427999, it's much less severe than I thought
<ubottu> bug 1427999 in cloud-init (Ubuntu) "cloud-init does not purge with systemd" [Medium,New] https://launchpad.net/bugs/1427999
<Odd_Bloke> pitti: Good to know, thanks.
<Odd_Bloke> pitti: The impression I have is that cloud-init is systemd-ready, but smoser and utlemming would know better.
<pitti> Odd_Bloke: I continue to investigate this; the failed initctl is probably/hopefully just harmless noise
<pitti> ok, mystery solved
<doko> zul:
<doko> python-glance-store (0.1.10-0ubuntu2 to 0.1.11-0ubuntu1)
<doko> Maintainer: Ubuntu Developers
<doko> 0 days old
<doko> python-glance-store/amd64 unsatisfiable Depends: ython-jsonschema (>= 2.0.0)
<xnox> doko: ython -> Object Oriented high-level language generated on the fly entirely with yacc =)
<mvo_> cjwatson: haha, I think its ready to land, just needs a review, maybe barry can help with that? but I will double check
<mvo_> cjwatson: and yes, I got eaten by snappy :)
<cjwatson> Cool, thanks :)
<mvo_> xnox: feel free to look at the branch if you want to do a bit of dbus hacking :) iirc it worked but tests were missing
<mvo_> (or incomplete)
<smoser> pitti, thanks.
<smoser> pitti, i hope to get that fixed "righ tnow"
<smoser> as was hoping to get the versio nof cloud-init in archive sufficient to work with snappy, and i did a quick hack in the snappy version (config change) to do that. but for archive we'll have to do something smarter...
<smoser> pitti, with reguard to purging cloud-init from user-data, i dont know that i care too much.. at least not without thinking about it more.
<pitti> smoser: "that" == the initctl message? are there any consumers of that? these will need to get fixed, right? or ist that just some internal communication?
<smoser> theres probably nto consumers of initctl message at this point.
<smoser> it was basically offered as a event that you could have upstart jobs on
<smoser> that would guarantee that cloud-config was available
<pitti> ah, ok
<smoser> and i dont think that functionality is a bad thing...
<smoser> but i dont think a lot of things used it. and it clearly has to have *some* change for systemd :)
<xnox> smoser: but before emitting things for upstart, one should check that one is running with upstart e.g. initctl --system version >/dev/null 2>&1
<smoser> xnox, thanks.
<smoser> i will use that.
<xnox> smoser: there are some versions of upstart that didn't support --system. one sec.
<smoser> i probably dont care aobut them :)
<pitti> smoser: a unit which wants to start on cloud-init can do that without extra measures from cloud-init itself, so I think we are good there
<xnox> smoser: unset UPSTART_SESSION; initctl version >/dev/null 2>&1 is better. or like otherwise make sure user session variable is not set to check that PID1 is upstart.
<smoser> xnox, k. thanks.
<doko> siretart, looking at the x264 ftbfs on arm64, the upstream support seems to be non-functional, afaics. are there newer snapshots with better support?
<smoser> xnox, to be clear...
<smoser> initctl version
<smoser> on a non-upstart-pid-1 system will return non-zero
<smoser> right ?
<xnox> yes.
<xnox> initctl version -> tries to connect to a private socket exported by upstart, query the daemon's version, and return it.
<pitti> not true
<pitti> $ initctl version; echo $?
<pitti> upstart 1.13.2
<pitti> 0
<xnox> it's equivalent of the sd_booted test -> [ -d /run/systemd/system ]
<xnox> pitti: note the unset UPSTART_SESSION; from prior discussion.
<pitti> sorry, that was session upstart
<pitti> ignore me :)
<smoser> ignored
<smoser> :)
<pitti> yes, returns 1 here
<smoser> thank you pitti
<xnox> smoser: yeah but do unexport UPSTART_SESSION -> as then session upstart daemon is queried, rather than the system one.
<pitti> just that in cloud-init case there's no session
<xnox> pitti: yeah, most of the time it's fine. but that's the only safe way to guarantee that really the system one is being checked.
<xnox> initctl --system version -> is another way, but pre-user-session upstarts do not know about --system / --user flags.
<xnox> thus unexporting variable is the backwards compatible way from forever to check the system init.
<dobey> Mirv: huh? :)
<Mirv> dobey: I meant in the morning, that translations are welcome in Ubuntu and MIRing the package is not a big one of a MIR
<Mirv> so it'd make sense to have it available in main
<Mirv> dobey: oh, right wrong [tab]
<Mirv> doko: so yes, MIR:ing qttranslations ok
<doko> Mirv, bug report?
<smoser> xnox, pitti http://paste.ubuntu.com/10527499/
<Mirv> doko: I'll have it still today
<smoser> that is what i'm going with.
<dobey> Mirv: ah ok. :)
<smoser> cloudinit util.subp captures and returns (stderr, stdout) by default.
<smoser> the onequestion, i'm guessing i can assume 'upstart' in the output.
<xnox> smoser: yes.
<pitti> smoser: ah, you don't think it's safer to just check the exit code?
<pitti> $ sudo LANG= initctl version; echo $?
<pitti> initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<pitti> 1
<pitti> the error message has "upstart" in it too :)
<xnox> pitti: that's in stderr
<xnox> pitti: not in out
 * xnox ponders how to check for @/com/ubuntu/upstart socket direct
<smoser> pitti, i checked only because its possible i have a program that is not upstart named 'initctl'
<xnox> as that would be the quickest imho.
<smoser> the fork is fine. it happens once.
<pitti> xnox: nc -U @/com/ubuntu/upstart ?
<pitti> (needs checking on an upstart system)
<pitti> but let's not overdo it
<Mirv> doko: bug #1427677
<pitti> and check internal implementation details
<ubottu> bug 1427677 in double-conversion (Ubuntu) "[MIR] double-conversion" [Undecided,New] https://launchpad.net/bugs/1427677
<Mirv> doko: sorry, not that one
<Mirv> doko: this one bug #1428162
<ubottu> bug 1428162 in qttranslations-opensource-src (Ubuntu) "[MIR] qttranslations-opensource-src" [Undecided,New] https://launchpad.net/bugs/1428162
<flexiondotorg> I'm trying to remove some config files with dpkg-maintscript-helper rm_conffile
<flexiondotorg> Here is my postinst script
<flexiondotorg> http://paste.ubuntu.com/10527664/
<flexiondotorg> The files are not being removed. Could someone point me in the right direction please?
<pitti> flexiondotorg: you need to specify the version that removes it, as it's only done once
<pitti> flexiondotorg: see man dpkg-maintscript-helper
<pitti> flexiondotorg: not sure what the $@ is
<pitti> flexiondotorg: but usually you just put these commands into debian/pkgname.maintscripts, and dh_installdeb DTRT
<flexiondotorg> pitti, DTRT?
<pitti> "do the right thing"
<flexiondotorg> pitti. Thanks. That give me something to go on.
<flexiondotorg> pitti, Should the version be 0.4.2ubuntu1 or 0.4.2?
<pitti> flexiondotorg: I don't know -- whichever version removes the file, with ~ appended
<cjwatson> ScottK: You synced python-astropy from experimental, which causes astroquery to FTBFS.  I think syncing python-astropy-helpers from experimental as well will fix this; was there a special reason you didn't, or was it just an oversight?
<flexiondotorg> pitti, Thanks. Working now :)
<cjwatson> ScottK: I've gone ahead and synced that; it looked likely and only has one reverse-(build-)dep.
<pitti> wgrant: so I just moved python-dbusmock from gitorious to github; https://code.launchpad.net/~pitti/python-dbusmock/trunk is an automatic import of that, how can I change that to the new git location?
<pitti> wgrant: editing the branch doesn't have an origin URL, and I can't delete and re-create as it complains about having associated branches
<cjwatson> pitti: Do you not have an "Edit import source or review import" link?
<pitti> cjwatson: no, I don't; that probably requires extra Launchpad fu
<cjwatson> pitti: What's the GitHub URL?
<pitti> cjwatson: https://github.com/martinpitt/python-dbusmock
<cjwatson> pitti: Updated
<cjwatson> wgrant: ^-
<pitti> cjwatson: cheers!
<cjwatson> Yeah, only ~vcs-imports and ~admins can use that interface, now that I look at it.
<pitti> cjwatson: nice, I even got an automatic mail from LP about it
<slangasek> cyphermox: I see console-setup still hasn't gone through because of console-setup-mini uninstallability on amd64
<pitti> slangasek: yep, cyphermox and I talked about that this moring
<pitti> morning, too
<slangasek> ok
<pitti> (most probably just a missing alternative dep in kbd, but I haven't checked very deeply)
<cjwatson> yes that's the diagnosis I gave cyphermox too
<Chipaca> could somebody confirm that, in bash on vivid, â( read -p "ok? " -n1 -e -t2 && echo "R: $REPLY" ); echoâ leaves the terminal with no echo if you don't reply?
<flexiondotorg> pitti, Where is your systemd FFE?
<pitti> flexiondotorg: bug 1427654
<ubottu> bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,Confirmed] https://launchpad.net/bugs/1427654
<flexiondotorg> pitti ty
<flexiondotorg> pitti, I just dist-upgrade my vm. So, it has happened right? :)
<pitti> flexiondotorg: no, not yet
<pitti> flexiondotorg: still waiting on the FFE and NFS to land
<pitti> flexiondotorg: today I just did some preparatory things to make ubuntu touch continue to use upstart
<flexiondotorg> pitti, I got a new `init` package when I dist upgraded.
<pitti> flexiondotorg: right; that's a meta-package which depends on upstart | systemd-sysv
<pitti> flexiondotorg: and we'll flip that around (hopefully) soon
<flexiondotorg> pitti, OK.
<flexiondotorg> pitti, Before Beta 2?
<pitti> flexiondotorg: hopefully this week :)
<flexiondotorg> pitti, Ace!
<flexiondotorg> pitti, You realise that the Internet will have an aneurysm when it is announced? ;)
<pitti> yes, everybody will hate me, and I earn everyone's boot bugs :)
<didrocks> well, people will just blame fsckd as it seems to be a thingâ¦ :p
<flexiondotorg> pitti, No, everyone will not hate.
<flexiondotorg> pitti, Only the trolls and the ignorant will ;)
<flexiondotorg> pitti, Love you for it.
<flexiondotorg> pitti, Seriously considering hanging up my Arch dev boots because of this.
<didrocks> flexiondotorg: tell that on LAS! :)
<flexiondotorg> didrocks, ;) You listen then?
<flexiondotorg> didrocks, Do you hear last nights/
<didrocks> flexiondotorg: when exercisingâ¦ But I generally lag on LAS/Unplug by 2 weeks, so not yet :)
<flexiondotorg> didrocks, Fair enough. Ubuntu MATE featured a good last night :)
<flexiondotorg> didrocks, I mentioned systemd enablement.
<didrocks> flexiondotorg: nice! I will listen then this time to not only check popey doesn't tell wrong things :)
<popey> I have no idea what you mean :)
<didrocks> heh
<flexiondotorg> didrocks, popey Was very wrong last night. Fortnately I was there to straighten him out.
<flexiondotorg> Oh, Hi popey ;)
<pitti> roaksoax: so in http://paste.ubuntu.com/10529094/
<pitti> roaksoax: +ConditionPathExists=|/var/lib/maas/secret
<pitti> roadmr: what do you mean with the | there? a single | is a no-op; it only really makes sense if you have more than one OR-ed condition
<pitti> roadmr: sorry, I meant roaksoax
<roadmr> :D
<roaksoax> pitti: ah i see
<roaksoax> pitti: so then no need for that then
<pitti> roaksoax: in http://paste.ubuntu.com/10528917/ the last unit, does sourcing maas-proxy-common.sh actually do anything, i. e. have some side effect?
<roaksoax> at all
<pitti> roaksoax: otherwise you probably mean EnvironmentFile=/usr/share/maas/maas-proxy-common.sh if that's supposed to apply to the squid call?
<roaksoax> pitti just ensures permissions are correct. Similar to what squid-deb-proxy does
<pitti> roaksoax: the other two look ok (they could probably get some cleanup, but nevermind)
<pitti> roaksoax: ah, and it's not executable?
<pitti> roaksoax: i. e. you want the unit to fail if maas-proxy-common.sh fails, but it's not exporting env vars for squid? that's fine then
<pitti> roaksoax: although it'd be easier to just call it then, to avoid another shell
<pitti> roaksoax: ExecStartPre=/usr/share/maas/maas-proxy-common.sh
<roaksoax> pitti ok cool
<pitti> roaksoax: or, if it's not executable, ExecStartPre=/bin/sh /usr/share/maas/maas-proxy-common.sh
<pitti> (looks a bit simpler)
<roaksoax> pitti: yeah that should work better
<roaksoax> pitti: awesome then! I'll get this tested
<roaksoax> pitti: and let you know how it goes
<roaksoax> pitti: thanks for the feedback
<pitti> utlemming, Odd_Bloke: oh, with the cloud images being switched to systemd some tests might now behave differently; I guess that deserves some announcement, I'll send an u-d-a@ post
<pitti> jamespage: FYI, https://jenkins.qa.ubuntu.com/job/vivid-adt-heat/? started failing, some problem with the systemd units? (see the u-d-a@ mail I just sent)
<pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-neutron/63/ARCH=amd64,label=adt/console too, although i386 succeeded
<jamespage> hmm
<jamespage> pitti, ok - we'll take a look
<pitti> cheers
<doko> pitti, zul: systemd fall-out: https://launchpad.net/ubuntu/+archive/test-rebuild-20150202/+build/6775834
<doko> ScottK, you are clamav uploader. why is llvm not enabled on all architectures?
<doko> kenvandine, ping on lp:#1428299 and lp:#1428314
<kenvandine> doko, i haven't even looked at those in ages :)
<doko> kenvandine, the version numbers look phonish ;-P
<kenvandine> bregma, ^^
<kenvandine> are you tending to geis and dee these days?
<kenvandine> doko, i'm happy to patch them, but let me check first
<doko> kenvandine, sure, would appreciate it if you could get these in. maybe more will follow, if you look at the list of GCC 5 ftbfs
<kenvandine> doko, good times :)
<kenvandine> doko, i'll go ahead and prepare branches to land while waiting for a reply
<bregma> my first reaction is to run like the dickens when those names come up, but I can take a lok
<kenvandine> bregma, are we landing those with the train?
<kenvandine> i'm happy to prepare bzr branches for you guys to review
<bregma> I believe I have landed those under ci-train in the past, yes
<doko> let me know, I could upload directly to the archive too. these are no code changes
<bregma> they're definitely ci-train projects, should be branched properly before landing
<kenvandine> doko, we'll let you know, it might be less work for us to land it as opposed to pulling the patches back down
<doko> ok
<kenvandine> bregma, https://code.launchpad.net/~ken-vandine/dee/lp1428299/+merge/251827
<kenvandine> https://code.launchpad.net/~ken-vandine/geis/lp1428314/+merge/251828
<kenvandine> bregma, ^^
<bregma> thanks
<kenvandine> np
<doko> kenvandine, bregma: I would appreciate it, if you could scan http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-gcc5-vivid.html  for other phonish packages.  you can find the compiler in the ubuntu-toolchain-r/test PPA. getting these addressed would be appreciated
 * bregma adds to the work queue
<kenvandine> doko, will do
<doko> cool, then I'll skip these for now. just ping here when you address one of those
<kenvandine> doko, libdbusmenu and unity-webapps-qml
<kenvandine> there are 2 other unity related packages there, but i think those are only used in unity7
<doko> anyway, these should be fixed, or demoted ...
<kenvandine> yeah
<kenvandine> none of these are particularly phoneish, a couple have libs that are installed on the phone
<kenvandine> tedg, dbusmenu ftbfs with gcc5
<tedg> gcc5 is a 15.10 thing, no?
<kenvandine> doko, ^^ ?
<kenvandine> i suspect so, not 15.04
<tedg> How weird, seems one of the test is hanging. Wouldn't have expected that to be the issue.
<tedg> In the GTK2 version even.
<tedg> Vim is failing! We need a bug status above Critical!
<Unit193> tedg: Oh, I don't suppose bug 1270486 will be fixed for release?
<ubottu> bug 1270486 in libdbusmenu (Ubuntu) "indicator-application doesn't use the menu item's label if it has a stock icon" [High,Triaged] https://launchpad.net/bugs/1270486
<bregma> emacs does not get installed on the phone by default?  How does it even?
<tedg> Unit193, Not sure if I'll get to it, or not. It's not a high priority for me right now.
<Unit193> Dang, that stinks.  Right now I'm looking at a program with two quit options, but one is "and shutdown daemon" and I'm not sure which..
<ochosi> +1
<sbeattie> pitti: https://jenkins.qa.ubuntu.com/job/vivid-adt-ubuntu-system-settings-online-accounts/137/ARCH=amd64,label=adt/console looks to be a problem with powerd setup?
<bdmurray> roaksoax: Is the verification of bug 1383727 still good?
<ubottu> bug 1383727 in curtin (Ubuntu Utopic) "[SRU] Fast installer - failure to install grub (UEFI mode)" [High,Fix committed] https://launchpad.net/bugs/1383727
<roaksoax> bdmurray: from my perspective, yes, we have tested this in various different types of hardware in OIL and others
<bdmurray> roaksoax: Do you know what comment #23 might mean?
<bdmurray> bluesabre: Did you upload sponsor the fixes for bug 1425972? If so release tasks weren't opened, an SRU test case is missing and ubuntu-sponsors is still subscribed.
<ubottu> bug 1425972 in exo (Ubuntu) "Firefox no longer supports -remote parameter" [Medium,Confirmed] https://launchpad.net/bugs/1425972
<sbeattie> pitti: sorry, I was confusing powerd with upower. Do you have any idea why systemd is failing its adt tests? I can't see anything obvious in the logs in https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/109/?
<doko> tedg, kenvandine: yes, 15.10, but things will be "interesting", so I'd like to fix as many things as possible proactively, so that we don't run into issues during the w-series cycle
<bdmurray> For some reason w seems closer to the end of the alphabet than v
<tedg> bdmurray, It is exactly one letter closer.
<bdmurray> tedg: I think its because I remember the last letters of the alphabet in a block of 4 starting with W
<bluesabre> bdmurray: Yes, updating the bug now and replacing the debdiff for trusty. I'll unsub sponsors and upload trusty to -proposed
<bluesabre> sorry for the unnecessary noise
<bluesabre> er, everything except unsubbing sponsors, can't do that
<flexiondotorg> cyphermox, Are you able to do you package sponsoring today?
<bdmurray> bluesabre: great, thanks
#ubuntu-devel 2015-03-05
<cyphermox> flexiondotorg: I was having dinner by the time you pinged, and carried on to watch tv. it is for ubuntu-mate-settings?
<cyphermox> I can review that now if it's been adjusted to follow some of the recommendations
<ScottK> doko__: It didn't work on all architectures.
<ScottK> Upstream only supports the functionality that needs LLVM on some archs.
<pitti> Good morning
<pitti> sbeattie: no, powerd was just right; I proposed a fix for that weeks ago already, but I just uploaded it last night; I restarted the system-settings-o-a test
<pitti> sbeattie: systemd tests> I'm on them, yesterday it was due some changes in autopkgtest
<pitti> doko__: beanstalkd> queueing, will fix
<pitti> sbeattie: and here it's green again
<sbeattie> pitti: awesome, thanks for digging in to it.
<pitti> Launchpad where are thou?
<pitti> ah, it's back
<pitti> infinity: as slangasek didn't get around to it, do you have an opinion on bug 1427654?
<ubottu> bug 1427654 in ubuntu-meta (Ubuntu Vivid) "FFE: switch system init to systemd [not touch] in 15.04" [Undecided,Confirmed] https://launchpad.net/bugs/1427654
<pitti> if we do it, I'd rather do it earlier than later, and not on a Friday
<pitti> cyphermox: fixed NM's autopkgtest FYI
<tjaalton> pitti: nfs-utils is fixed now? whee
<pitti> tjaalton: well, I just uploaded it
<tjaalton> i need to set up kerberized nfs pronto then :)
<pitti> and I need another followup upload to fix an important issue and add an autopkgtest
<tjaalton> still
<pitti> tjaalton: testing with krb is very much appreciated, I didn't do that
<tjaalton> yeah, need to fix mount options to use that, otherwise things should be set here..
<pitti> sbeattie: ah, the remaining failure is that /var/log/syslog (and all other rsyslog files) ceased to exist
<pitti> sbeattie: looking into that now, not sure if the latest cloud-inits do something funky there
<pitti> smoser`, Odd_Bloke: I just filed bug 1428495; cloud images broke ssh?
<ubottu> bug 1428495 in cloud-init (Ubuntu) "Does not enable ssh even with ssh_enabled: True" [High,New] https://launchpad.net/bugs/1428495
<dholbach> good morning
<SpamapS> jamespage: Hi, any chance you or robie are working on an upload of MySQL 5.5.42 to vivid?
<pitti> I thought 5.5 was slated to die, as soon as 5.6 actually makes it into vivid?
<pitti> (it's been stuck in -proposed on some uninstallability for weeks)
<SpamapS> pitti: ah that would explain 5.5.42 not having been uploaded.
<pitti> rbasak: what's the status of landing 5.6, OOI?
<pitti> according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt it sitll makes the percona-* bits uninstallable?
<SpamapS> Yeah I believe 5.6 introduces the idea of the mysql-commmon package becoming fork-specific.
<SpamapS> So percona server might have to figure that out. :-P
 * SpamapS recedes back into the shadows
<jamespage> SpamapS, pitti: rbasak is technically on holiday this week - I'll take a look and see
<pitti> jamespage: oh, then he'll be on holiday practically too :)
<pitti> "hopefully"
<pitti> jamespage: thanks
<jamespage> SpamapS, ah yes I remember - the galera bits for percona ftbfs on a number of archs - georgelorch is working on that
<jamespage> pitti, he's been around still
<pitti> there, an autopkgtest for NFS
<doko> xnox, do you have a new boost package?
<xnox> doko: no =) i can do that on a my buildbot at home, but it's not on at the moment and cannot power it on remotely.
<xnox> doko: you wanna open new series with 1.57? I can prepare that.
<doko> xnox, yeah, I think opening with 1.57 makes sense, or maybe 1.58. and I want to upload it to my test rebuild ppa too
<xnox> doko: ack.
<xnox> doko: right, i'm not sure when 1.58 will be ready. It's "4 weeks late" cause it should have been first monday in february... i'm guessing it should be last monday in april now e.g. april 27th
<xnox> doko: i think i should prepare 1.57 and if 1.58 is release before open upgrade to that.
<sitter> didrocks: hey, any progress on bluez5?
<didrocks> sitter: unfortunately, still blocked on touch kernel enablement
<sitter> didrocks: still planned this cycle though?
<didrocks> sitter: hopefully, I can't ensure you though that it will be ready or that the FFe will be accepted :/
<ogra_> sitter, it is planned soon ... once we branched off the phone stuff into the production tree again bluez5 is free to land for desktop
<sitter> ok. not landing bluez5 means we have no bluetooth gui in kubuntu so that has me quite a bit worried :/
<Saviq> lool, hey, are you landing vivid silo 22 any time soon?
<pitti> doko: FYI, beanstalkd fixed, patch sent to debian bug 779831
<ubottu> Debian bug 779831 in beanstalkd "beanstalkd: FTBFS with binutils-gold" [Normal,Open] http://bugs.debian.org/779831
<Odd_Bloke> pitti: Hm, that sounds like snappy behaviour bleeding in to the normal world; I'll let smoser` chime in as I wasn't particularly involved with the snappy cloud-init changes.
<didrocks> Saviq: I guess he is at mwc
<pitti> Odd_Bloke: ah, so ssh is supposed to still stay enabled? (that would make a lot of sense, given that it's your only foot into the door on clouds :) )
<Saviq> didrocks, right, and the silo is there since Jan, so unlikely to land ;)
<didrocks> Saviq: I saw his shadows on some photos :)
<Odd_Bloke> pitti: Yeah, disabling SSH would be just a little user-hostile. ;)
<Odd_Bloke> pitti: Oh, in fact, cloud-init 0.7.7~bzr1076-0ubuntu1 merged snappy support in so that will definitely be the problem.
<flexiondotorg_> Anyone here who could do some sponsor for package updates in Ubuntu MATE please?
<infinity> pitti: My opinion is "yes, we should do it" and agreed that it should be a Monday, so we have time to deal with fallout and/or revert.
<infinity> pitti: I'll look at the bug when I'm not completely messed up, sleep-wise. :/
<infinity> pitti: Also, was quite happy to see no pushback from guillem on the .dsc addition.  Just a bit of bikeshedding, then we can go JFDI the implementation.
<pitti> infinity: right, he generally seemed happy about it
<pitti> infinity: ack, so Monday it will be
<pitti> infinity: so I could write the u-d-a@ warning about that now, if we'll do it?
<pitti> to get the warning out a bit ahead of time
<siretart> doko: I see that you already uploaded a fixed package, thanks. with "upstream support" I guess you mean aarch64?
<infinity> pitti: Bug commented on.
<pitti> infinity: ack, thanks; I'll send the warning then and prepare the two uploads
<pitti> doesn't help that much that I'll be on vac 1.5 weeks from March 16 on, but we have a full week, and I have didrocks as my deputy :)
<siretart> doko: looking at the upstream git, yes, it seems that there are in fact a number of aarch64 optimizations applied. I'll work on a new snapshot for experimental and sync it to vivid. thanks for pointing this out to me
<infinity> pitti: A week should be more than enough to determine if it's completely effed up.
<pitti> infinity: right, and a lot of people are running it already anyway
<infinity> pitti: Rough edges that need filing off may take more time, but should generally be less urgent.
<pitti> also, it's one small upload to switch back
<pitti> heh, /me saw lots of those rough edges
<cjwatson> juju still doesn't support it; it might be worth mentioning that.
<cjwatson> (it's in progress, but not done)
<pitti> right, same wit maas
<cjwatson> I don't know whether juju on a systemd host with trusty lxc containers using upstart works.
<smoser`> Odd_Bloke, not intended. we will fix. its easy to user-data turn it back.
<smoser`> sorry. i rushed that change in :(
<smoser> pitti, did you file a bug ?
<pitti> smoser: yes, bug 1428495
<ubottu> bug 1428495 in cloud-init (Ubuntu) "Does not enable ssh even with ssh_enabled: True" [High,Confirmed] https://launchpad.net/bugs/1428495
<pitti> smoser: Odd_Bloke said that disabling ssh by default isn't even intended (which makes sense as it's the only way to talk to a cloud instance really..)
<smoser> pitti, thnaks.
<flexiondotorg_> Anyone here who could do some sponsor for package updates in Ubuntu MATE please?
<Laney> Can't you put them in the queue?
<bluesabre> not sure what icon transmission is expecting on first run, but it is missing in adwaita, humanity, elemenary-xfce... http://i.imgur.com/g3SmBwM.png
<lfrlucas> Hi. Why some package versions are so old in recent ubuntu versions. E.g. Why is ubuntu using polkit-0.105 ? A newer version 0.112  is out
<mlankhorst> in general nobody packaged it yet :)
<lfrlucas> hmmm
<mitya57> I think pitti packaged it for Debian experimental.
<lfrlucas> Recently I filled a bug on policykit and fixed version 0.105 with their last commit: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637 . It was already released on vivid. It wouldn't be better to upgrade policykit to latest version instead of creating additional patches on ubuntu packages?
<ubottu> Launchpad bug 1417637 in policykit-1 (Ubuntu Utopic) "Kdeinit4 is leaking memory on every ssh login due to known bug on policykit-1" [Undecided,Fix committed]
<mitya57> Or, rather, other pkg-gnome members (pitti did only the last upload). And it is there for a long time, parallel with 0.105 in unstable.
<Laney> bluesabre: good question, looks like a gtk bug?
<Laney> same in utopic afaics - those dialogs aren't supposed to have an icon
<pitti> lfrlucas, mitya57: mostly because I really really hate the javascript based policies; this is nuts
<pitti> so we essentially kept it at the old declarative text file policies
<rbasak> SpamapS, jamespage, pitti: 5.6 is blocked on percona-xtradb-cluster-5.6, which is blocked on percona-galera-3 FTBFS on non-Intel architectures. Percona are looking into it.
<rbasak> (it's all in vivid-proposed)
<jamespage> rbasak, thanks for confirming - that's what I thought
<mitya57> pitti, thanks, that explains it
<lfrlucas> pitti: Ok. Now I understand .
<pitti> besides, it's not like polkit would still be alive upstream, it's in low-maintenance mode
<pitti> thus having 105 or 112 doesn't matter much in terms of maintainability
<pitti> I'm sure one of these days systemd will suck this in :)
<mitya57> :)
<flexiondotorg_> Laney, they are in the queue :)
<pitti> flexiondotorg_: I'm patch piloting tomorrow, I'll have a look
<pitti> (meeting now, then EOD)
<bdmurray> shadeslayer: could you please update bug 1375786 with SRU information?
<ubottu> bug 1375786 in Kubuntu PPA ".desktop files can not start apps with kdesu" [High,Confirmed] https://launchpad.net/bugs/1375786
<flexiondotorg_> pitti, Thanks.
<cmagina> i want to propose a change for the trusty systemd package. i thought i should propose it against the bzr branch, however, there does not appear to be a branch for the trusty-updates version of systemd
<strikov> cmagina: i'm not an expert, so this opinion might be completely wrong. How about looking for latest .dsc for systemd package in trusty (you may look at one in -proposed); dget it; do changes; debuild -S and debdiff; open bug against the package and attach debdiff to it;
<strikov> cmagina: That's the .dsc you probably want: https://launchpad.net/ubuntu/+archive/primary/+files/systemd_204-5ubuntu20.11.dsc That's for package in -proposed
<cmagina> strikov: yeah, i know that method, just figured the bzr branch would be the appropriate way. thanks though
<mitya57> Mirv, will you include the one-line fix for bug 1426942 in your 5.4.1 packages?
<ubottu> bug 1426942 in qtbase-opensource-src (Ubuntu) "Kubuntu Vivid - unable to display Gujarati Text" [Undecided,Confirmed] https://launchpad.net/bugs/1426942
<mitya57> http://code.qt.io/cgit/qt/qtbase.git/commit?id=ef22739f47857c18
<tjaalton> is there a tag for systemd-as-init related bugs?
<strikov> cmagina: in case of one of my packages, changes in -security and -proposed were not transferred to bzr branch
<strikov> cmagina,
<tjaalton> "systemctl stop apache2.service; systemctl start apache2" fails
<strikov> cmagina: it means that i was not able to do correct update via bzr, only manual method
<cmagina> strikov: ah, interesting, so there are no bzr branchs kept for all changes made post-release then?
<cmagina> strikov: i'll just use the dsc method, thnaks
<strikov> cmagina: i don't know for sure, that was indeed so for squid3
<cmagina> thanks even
<strikov> cmagina: you know about sru and friends, right?
<mitya57> pitti: please look at tjaalton's question above (if you are still here)
<tarpman> cmagina: maybe check http://package-import.ubuntu.com/status/ for systemd
<tjaalton> mitya57: I'll file a bug
<cmagina> strikov: what do you mean by sru and friends?
<tjaalton> I've seen this with debian too, when testing freeipa.. the installer does exactly that after configuring the service
<strikov> cmagina: trusty is stable release and you need to file SRU request for it: https://wiki.ubuntu.com/StableReleaseUpdates
<mitya57> tjaalton, if you think it's a blocker, please comment on the FFe
<tjaalton> it should be fixable, just don't know how :)
<tjaalton> stop exits too early
<strikov> cmagina: basically prove that your change is indeed required i.e. can add more profit than pain
<cmagina> strikov: yes, i know that, do it often enough these days for the kernel :)
<strikov> cmagina: heh, lucky you :)
<cmagina> strikov: the new part for me is this being a package versus the kernel
<dobey> cmagina: lp:ubuntu/trusty-proposed/systemd is probably the branch to base on
<dobey> assuming it didn't have an import failure
<cmagina> dobey: i would, except that tracks the utopic branch
<cmagina> there was a change made to the trusty-updates package i want to extend, but that change does not appear in any systemd branch
<dobey> cmagina: no it doesn't
<dobey> cmagina: there is a change in -proposed which is not yet in -updates; your changes will have to go through -proposed first, so if -proposed exists, it is generally the thing you should base your chagnes off of
<cmagina> dobey: what does "stacked on" mean for bzr then? the trusty-proposed branch lists stacked on utopic
<cmagina> dobey: that makes sense, but i have a problem with that branch, it lacks the changes i am trying to extend
<dobey> cmagina: the utopic branch is the "current stable release"
<dobey> cmagina: the stacking in launchpad is a bit weird sometimes, you can probably just ignore that; you'll need to propose your changes into the trusty-proposed branch/pocket anyway
<dobey> cmagina: however, the lp branch seems to be out of date
<dobey> cmagina: so you'll need to grab the sources from the trusty-proposed pocket using the dsc that strikov linked to
<cmagina> dobey: yeah, that does seem to be the issue
<cmagina> dobey: yeah, that is what i was planning on doing. just attach the debdiff to the sru bug
<cmagina> dobey: thanks for the help
<dobey> no problem :)
<rlaager> I'm testing systemd in vivid with an eye toward making sure that root-on-ZFS will still work (at least as well as it did pre-systemd). It was suggested to me by someone with a lot of systemd-on-Fedora experience that cron.service should Wants=local-fs.target (possibly by some implicit mechanism). I'm not seeing that dependency. As a result, cron is starting before /var/spool is mounted. Likewise
<rlaager> for atd. Postfix has the same issue with /var/spool. I'm new to systemd. Any thoughts?
<sarnold> hey rlaager :)
<sarnold> rlaager: you may find some information on https://wiki.ubuntu.com/SystemdForUpstartUsers -- you may need to talk with pitti, I believe he's done much of the systemd work so far; he's typically on "very early" european time
<rlaager> sarnold: Yeah, I've read that whole thing a couple times. I'm still not sure if this is a bug in cron.service or not.
<sarnold> rlaager: it -feels- like a bug, the way you defscribed it...
<rlaager> I suppose if I could reproduce this with a separate ext4 filesystem mounted at /var/spool, everyone would agree it's a bug.
<rlaager> Is vivid expected to ship with systemd by default, or not, or has that not been decided yet?
<sarnold> rlaager: I believe the plan is for vivid to ship with systemd barring something surprising...
<ScottK> rlaager and sarnold: the plan is to switch to systemd default on Monday.
<shadeslayer> bdmurray: will do
<bdmurray> shadeslayer: thanks
#ubuntu-devel 2015-03-06
<pabs3> hi folks. I discovered that 91.189.94.232, which is part of assets.ubuntu.com has an SSL cert that is invalid and is different to the other assets.ubuntu.com IPs. where should I report this?
<sarnold> hey pabs3 :)
<sarnold> pabs3: I've passed it along to IS, thanks
<pabs3> oh, cool, thanks sarnold :)
<pitti> tjaalton: yes, tag them with "systemd-boot"
<Unit193> Not 'systemd-doesnt-boot'? /me ducks
<pitti> rlaager: cron.service, like most *.service has DefaultDependencies=yes (that's the default) and hence runs way after local-fs.target and basic.target; see bootup(7) and systemd.special(7)
<pitti> Unit193: hehe
<rlaager> pitti: How can I verify that cron.service is starting after local-fs.target. I'm pretty sure it is not, but again, I'm new to systemd.
<pitti> rlaager: it is, but feel free to look at systemctl list-dependencies cron.service
<rlaager> One of the suggestions the other guy made was that maybe we have a loop, and systemd is breaking it in some non-optimal way.
<pitti> rlaager: if you have a dependency loop, you can see that in journalctl; perhaps do "journalctl -p warning" to filter out the noise, there you see them quite nicely
<rlaager> What do I need to specify in a service to make local-fs.target depend on it?
<rlaager> pitti: You are correct. It seems I had a completely unrelated problem. I'm sorry for the noise.
<pitti> rlaager: you do DefaultDependencies=no, Before=local-fs.target, and [Install]\nWantedBy=local-fs.target (unless you enable it statically, i. e. ship the symlink in the package)
<rlaager> pitti: So an unrelated, and still reproducible problem... The initramfs complains about "Target filesystem doesn't have requested /sbin/init" unless I specify init=/lib/systemd/systemd on the Linux command line.
<pitti> rlaager: you need to be careful with these services, though: they can rely on pretty much nothing except that you have a r/o root fs and /proc, /sys/, /dev mounted (and lo)
<pitti> rlaager: what is your /sbin/init ?
<rlaager> From the initramfs after that error, if I ls /sbin/init, I get: /sbin/init -> /lib/systemd/systemd
<rlaager> I wonder if I have a mismatch between the root filesystem and the initramfs.
<pitti> rlaager: that sounds like bug 1421117
<ubottu> bug 1421117 in initramfs-tools (Ubuntu) "fails to boot with "Attempted to kill init" in VMWare, absolute /sbin/init symlink does not work" [Medium,Fix released] https://launchpad.net/bugs/1421117
<pitti> but it was fixed a week ago already
<rlaager> I updated today before joining this channel.
<pitti> rlaager: if you have current initramfs-tools (i. e. current vivid), please give me the output of "lsinitramfs /initrd.img|grep chroot"
<rlaager> pitti: The output was the empty string. I rebuilt the initramfs and now I have one. And of course it works now. So I guess that was more noise. Thanks.
<pitti> rlaager: weird that updating initramfs-tools didn't update the initramfs then
<pitti> "sudo apt-get install --reinstall initramfs-tools" -> rebuilds it here, hmm
<pitti> rlaager: anyway, if you can reproduce that somehow, a bug report is appreciated
<tjaalton> pitti: done
<rlaager> pitti: It rebuilds for me with apt-get install --reinstall. So I can't reproduce it.
<tjaalton> pitti: looks like the apache fail is actually related to mod_nss, if it's enabled apache2 restart fails
<pitti> tjaalton: there's also a ton of test regressions, that might be related?
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apache2
<tjaalton> I'll check
<pitti> sh: 1: gcc: not found
<pitti> well, that's something different obviously
<pitti> ah, and doesn't make it fail,it's just a sloppy test
<pitti> test ssl-passphrase failed
<pitti> Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xe" for details.
 * pitti fixes ofono-phonesim
<pitti> ... and goes on to udisks2
<pitti> AH00015: Unable to open logs
<pitti> tjaalton: oh, does apache require /var/log to be "syslog" writable?
<pitti> (but systemd in -proposed fixes that, hmm
<tjaalton> not sure
<tjaalton> I'm still trying to verify if it's just mod_nss that causes my error.. leaves a socket behind or such
<mitya57> Mirv, you can now sync qtwayland & sip4 & pyqt5 to landing-012
<dholbach> good morning
<seb128> hey dho
<seb128> hey dholbach
<dholbach> hi seb
<dholbach> hi seb128
<seb128> :-)
<tsdgeos> who do i need to tell so that our gcc packages are updated with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 ?
<ubottu> gcc bug 65309 in c++ "[4.9 Regression] Executes wrong function inside an anonymous namespace on runtime" [Normal,Resolved: fixed]
<cjwatson> tsdgeos: File a bug on the Ubuntu gcc-4.9 source package, and give doko_ a heads-up if it's urgent
<Laney> bluesabre: did you file a bug about that wrong icon in dialog issue?
<flexiondotorg_> pitti, What time will you be piloting today?
<tsdgeos> cjwatson: tx
<pitti> jamespage, zul: I checked why heat's autopkgtest fails, and it is because debian/rules is apparently missing a dh_systemd_enable call
<pitti> it's easiest to do this with "--with systemd"
<jamespage> pitti, ack
<pitti> flexiondotorg_: RSN I hope, still firefighting
<doko> tsdgeos, better check first if it's already fixed
<tsdgeos> doko: well it was not fixed yesterday when i filled the bug
<tsdgeos> i'm sorry i didn't check again
<flexiondotorg_> pitti, I've got a couple of thorny package updates. When you're piloting feel free to ping me if you have questions.
<didrocks> flexiondotorg_: just put them in the queue, I'll co-pilot this afternoon
<didrocks> so first one who gets it will pick them :)
<flexiondotorg_> didrocks, They are in the queue :) But your will see a couple have some history now. So if you have questions please ask.
<didrocks> flexiondotorg_: we always do that (asking if we have questions), don't worry :)
<geser> pitti: I read your announcement on switching to systemd by default on monday. Is it planned that booting with upstart as a fallback should continue to work on newly installed systems (fresh installed with systemd as default)? If yes, then perhaps someone should fix bug #1422681 before release.
<ubottu> bug 1422681 in upstart (Ubuntu) "/etc/init files should get moved from "upstart" to "upstart-bin"" [Undecided,New] https://launchpad.net/bugs/1422681
<pitti> geser: less urgent, but indeed we should fix that
<pitti> xnox: ^ would you be able to look into this?
<xnox> pitti: i thought it was all good. let me check.
<xnox> pitti: right i remember that now. So we didn't want to move config files to upstart-bin, because there is no sensible way to move config files to a new package.
<xnox> or so I thought.
<pitti> xnox: it's going to require a lot of mv_conffile stanzas, yeah :/
<pitti> is there a way to ship them in /lib somewhere? or only /etc?
<xnox> pitti: but one cannot mv_conffile between packages.
<xnox> pitti: there is, but it was never in use on non-touch
<pitti> xnox: ah, so perhaps just a Replaces: ought to do?
<xnox> as long as it doesn't cause dpkg conffile prompts....
<infinity> xnox: Replaces won't cause conffile prompts on non-modified conffiles, the only gotcha is that using Replaces to move conffiles can cause modified files to revert to unmodified in an upgrade-with-purge scenario if the unpack order is unexpected.
<xnox> infinity: lovely =)
<infinity> (Because you completely remove the old one, then install the new one)
<infinity> xnox: If upstart pre-depended on upstart-bin intead of just depending, that would probably close that loophole, but at a bit of an ugly cost, given that adding new pre-deps in the required set can be scary unless you're positive there are no loops anywhere.
<xnox> infinity: everytime i did any upstart pre-depends or depends when shuffling this split, i ended up exploding upgrades or the buildds....
<infinity> xnox: Because a pre-dep would make sure upstart-bin unpacked and took over the files before upstart got a chance to purge the old modified ones.
<infinity> xnox: There are other violent ways to do it too, like having the preinst for both intentionally move modified files out of the way and then put them back on postinst.
<infinity> xnox: Obviously version-guarded, so it doesn't happen on every upgrade forever.
<LocutusOfBorg1> thanks ginggs for the vbox upload!
<ginggs> LoctutusOfBorg: no worries :)
<ginggs> LocutusOfBorg: no worries :) and I spelled your name correctly this time
<pitti> infinity: hm, if you purge upstart, isn't that saying "screw my conffile changes" anyway?
<infinity> pitti: If you do "apt-get --purge dist-upgrade", and a "clever" maintainer has decided to move conffiles between packages, the expected result isn't that your conffiles get reset to default.
<infinity> pitti: If you manually do "apt-get purge upstart && apt-get install upstart-bin" to upgrade, sure, you get to keep both pieces.
<geser> xnox: perhaps move /sbin/init (and the other programs) into upstart-sysv and let systemd-sysv conflict with that if that's easier to do than to move conf files around
<xnox> geser: we already have that....
<xnox> geser: we have upstart-bin and upstart. upstart ships init/reboot/halt and etc/jobs.
<xnox> geser: upstart-bin ships /sbin/upstart which one can use for e.g. user session.
<infinity> xnox: Yes, but it also ships the conffiles, which has this problem.  I can see where he's coming from with the solution.
<xnox> infinity: geser: oh, make upstart ship the conffiles only?
<bluesabre> Laney: not yet, got really busy last night after noticing it
<geser> xnox: yes
<infinity> xnox: upstart-sysv ships init/reboot/halt and depends on upstart, which ships /etc/init, which depends on upstart-bin
<Laney> bluesabre: no worry, I think I fixed it
<Laney> test with the gtk that's going to appear in a couple of hours?
<bluesabre> sure, will do
<xnox> infinity: geser: how will not screw over people who have upstart? i will not able able to put "upstart depends on upstart-sysv"
<infinity> xnox: And a dep loop between upstart and upstart-sysv to give smooth upgrades and allow other deps on "upstart" to continue to Just Work would probably be fine.
 * xnox ponders i could do "upstart -> depends {systemd-sysv | upstart-sysv}"
<infinity> Other way around, I imagine, but yes.
<infinity> Ugly, no matter how you slice it.  But prevents you having to move conffiles.
<geser> is the split between upstart (conf-files only) and upstart-bin then still needed?
<bluesabre> Laney: would you mind ack'ing the other components on here: https://bugs.launchpad.net/ubuntu/+source/xfce4/+bug/1424887 - and with the libxfce4util bump from 6 to 7, we'll need to rebuild a few packages. Should I do the rebuilds after libxfce4util releases from -proposed or do a dep wait for the packages so they can go at once?
<ubottu> Launchpad bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<bluesabre> (sorry to hijack your attention) :)
<infinity> geser: No, probably not.
<infinity> geser: They could be re-unified, and upstart-sysv could ship the conflicting bits.
<infinity> Which would make the upstart split look like the systemd split, which would be pleasant.
<infinity> xnox: ^
 * xnox wants to swtich user session to systemd, like right now.
 * xnox also wants to bastertise systemd source code to run on touch kernels
<infinity> xnox: That'll be a fair bit more work. :/
<infinity> xnox: Re-unifying the uptart split and breaking the sysv bits out, though, sounds elegant enough.
<xnox> infinity: that's to pam_systemd in vivid all desktops have both systemd & upstart user session running in parallel =)
<xnox> infinity: geser: are you volunteering to resplit usptart package then =)
<ogra_> pitti, xnox, i heard jolla uses systemd 208 with 3.4 kernel
<infinity> xnox: I could do the packaging work if you ask me next week.
<infinity> xnox: It would be nice to land the changes in jessie too, though, and I'm not sure how open the Debian release team will be to that.
<ogra_> not sure if they patched the kernel for this though
<xnox> ogra_: i know, we tool too recent systemd, which dropped bits that let it run on older kernels.
<xnox> imho they should be re-introduced.
<xnox> pitti: ^
<xnox> s/tool/took/
<ogra_> we'd carry that forever though
<ogra_> is there a way to convince upstream ?
<pitti> most certainly not
<infinity> Upstream believes that old kernels don't matter, and everyone runs tip of everything always.
<pitti> it'd be a huge patch
<infinity> There was a very long argument about how this breaks distros upgrading.
<xnox> pitti: why the libattr code path was dropped?
<infinity> And upstream didn't care.
<xnox> (that's just the first bit that i found)
<xnox> pitti: what's the lowest kernel version number we have on touch?
<pitti> xnox: why dropped? it was fixed upstream
<pitti> xnox: 3.4 I suppose
<ogra_> xnox, 3,4 ... but porterrs might even go back to 3.2 or some such
<infinity> xnox: 3.1, unless we finally dropped that one.
<infinity> But mostly 3.4
<ogra_> i dont think kitkat has a minimal kernel req. so for ports it could even be older
<xnox> infinity: you talk to me like i still remember what "that one" was. =)
<infinity> I don't remember either. :P
<xnox> ogra_: i don't care for the porters that much, i care for currently supported phones by canonical. i.e. the nexus and the whatever is shipping.
<ogra_> xnox, well, i do care for porters
<ogra_> if they port todays rootfs and get an upgrade that makes their phones not work at all anymore that would be bad
<ogra_> we have a handfull new ports, would be bad to just break them
<infinity> Ahh, grouper is the one that's 3.1, and it's still in the archive.
<infinity> ogra_: Should it be?
<ogra_> nope, wipe it :)
<infinity> ogra_: Is that an official request? :P
<infinity> remove-package -m "Obsolete and buggy, removed at ogra's request" linux-grouper
<ogra_> yes :)
<infinity> ^
<ogra_> cool, do it
<ogra_> grouper is long dead
<ogra_> mir wont properly work on it
<cjwatson> infinity: linux-meta-grouper too
<infinity> And linux-firmware-grouper
<infinity> And maybe linux-firmware-nexus7 ?
<ogra_> yeah
<ogra_> why is that there at all ?
<cjwatson> For that matter linux-nexus7 is still there
<ogra_> that originally came from the linux-nexus7 source
<ogra_> heh, remove it too
<cjwatson> Oh, that's a binary from the linux-meta-grouper source
<ogra_> ah
<infinity> ogra_: http://paste.ubuntu.com/10550064/
<ogra_> infinity, thanks !
<ogra_> wow, that was quite some naming mess between nexus7 and rouper
<ogra_> *grouper
<infinity> ogra_: I think we started with nexus7, then the nexus7 v2 happened, and we realied codenames were better and renamed the world.
<ogra_> yeah, but never cleaned up the old stuff it seems
<infinity> Well, most of that was transitional packages.  Except for -firmware-nexus7, which was just dead code.
<ogra_> yep
<infinity> ogra_: mako/nexus4 had the same renaming shuffle, just didn't have the external firmware problem.
<ogra_> ah
 * infinity sideeyes lubuntu-nexus7-extra-files and lubuntu-nexus7-default-session too.
<infinity> Where's gilir when you need him?
<ogra_> where do these come from ?
<infinity> ogra_: lubuntu-default-settings
<ogra_> interesting
<infinity> They don't build an armhf+nexus7 image, so it's almost certainly dead and forgotten code from an attempt long ago.
<pitti> jamespage, xnox, dannf: open-iscsi doesn't start on installation; that was fixed in http://anonscm.debian.org/cgit/pkg-iscsi/open-iscsi.git/commit/?id=b517ebb5a8f, but is that actually on purpose, or are we just behind on merging?
<pitti> (you were the last uploaders)
<ogra_> right, i wonder if that was me initially
 * ogra_ cant remember
<infinity> ogra_: It may well have been, since we were doing lubuntu ac100, and you might have been playing on the nexus7 with an environment you knew would work, pre-touch days?
<ogra_> yeah
<infinity> ogra_: Feel free to take ownership of commiting a fix to lp:lubuntu-default-settings to drop those packages, I suspect you probably can write to it.
<xnox> pitti: well in upstart world we don't need it that explicit start, do we?
<ogra_> infinity, not without hearing from the lubuntu guys though
<infinity> ogra_: Yeah, core-dev is in lubuntu-dev, so you can totally fix it. :P
<xnox> pitti: we have native job, it gets auto-enabled, and hooks into /etc/network/if-up.d/upstart
<pitti> xnox: it's an init.d script either way, but postinst wasn't starting it on install; so it's not init system specific
<pitti> xnox: ah, ok
<ogra_> i know, but i dont want to steal them the package without any feedback
<xnox> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/open-iscsi/vivid/view/head:/debian/open-iscsi.iscsi-network-interface.upstart
<xnox> pitti: ^
<pitti> xnox: but we'd still run the init.d script as well under upstart after booting, just not on package installtion
<xnox> pitti: correct.
<pitti> ack, thanks for confirming
<xnox> pitti: well, however downloading the deb in vivid
<xnox> pitti: # Automatically added by dh_installinit
<xnox> if [ -x "/etc/init.d/open-iscsi" ]; then
<xnox> 	if [ ! -e "/etc/init/open-iscsi.conf" ]; then
<xnox> 		update-rc.d open-iscsi start 45 S . stop 81 0 1 6 . >/dev/null
<xnox> 	fi
<xnox> fi
<xnox> pitti: which is unconditional. which bits are we missing?
<xnox> oh, invoke
<xnox> pitti: i'd rather drop "--no-start" in the dh_installinit call rather than adding manual invoke-rc.d call.
<pitti> I now did what Debian did, to reduce our delta
<pitti> (bbl)
<xnox> right.
<xnox> emailed maintainer
<cjwatson> pitti: So for exporting the "Request a full language pack export" setting on the webservice, do you literally just need to check that every so often, or do you also have to adjust the other settings on that form at the same time?
<cjwatson> pitti: (The former is easy, the others are potentially rather more complex)
<pitti> cjwatson: I just tick the box; with full exports it's not really important to update the "last used:" ones that the deltas are built against
<cjwatson> pitti: That is the right answer, thank you. :-)
<pitti> haha
<cjwatson> Saves me having to figure out how to export the language pack objects ...
<pitti> I'll take the afternoon off, I'm feeling really crappy
<pitti> see you on Monday!
<pitti> seems I got most of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html under control now
<pitti> perhaps jamespage can add the missing dh_systemd_enable to heat/neutron
<cjwatson> pitti: get well soon
<tjaalton> doko: hey, the binutils upload to trusty has a weird version (2.24-5ubuntu9 vs. 2.24-5ubuntu3.1 in -updates now)
<doko> tjaalton, yes, already used some version numbers in the ubuntu-toolchain-r/ppa before
<Riddell> pitti: systemd working great on kubuntu for me and others
<Riddell> pitti: where does stdout from startkde go to?
<Riddell> pitti: presuambly people doing an upgrade will also have upstart replaced by systemd?
<infinity> Riddell: People with ubuntu-standard installed or using do-release-upgrade should get forcefully switched.
<infinity> Riddell: If you're mising that metapackage and do a standard apt-get dist-upgrade, not so much.
<infinity> Riddell: do-release-upgrade or update-manager, or anything that uses ubuntu-release-upgrader, I should say.
<Riddell> gotcha
<infinity> Riddell: So, people with debootstrapped minimal systems won't get the forced switch (but they might be the sorts who wouldn't want it anyway), and people who intentionally removed ubuntu-standard.
<ogra_> wow, user-mode-linux still exists ?
<infinity> Not sure if we can do much better than that, though.
<infinity> ogra_: It's an amazingly handy debugging tool.
<ogra_> heh
<infinity> ogra_: Being able to run the kernel in gdb without having to do serial debugging is A++
<ogra_> but wasnt the project dead even before ubuntu started to exist ?
<Riddell> weirdly, people still confuse user-mode-linux for unified modelling language and e-mail my umbrello mailing list
<infinity> ogra_: Dead?  It's part of the kernel.  It Just Works.
<ogra_> oh
<Riddell> ogra_: you're thinking of UserLinux
<Riddell> the bruce perens idea to make an enterprise debian
<ogra_> right, i thought uml was part of that
<Riddell> they're as unrelated as user-mode-linux and unified modelling language :)
<ogra_> haha, ok
<infinity> ogra_: No, no.  uml is kernel-as-an-executable.  A sycall interface to itself, essentially.  Super handy.
<infinity> ogra_: It was also the best way to do cheap VM-like things before containers happened.
<ogra_> right, i remember that one
<infinity> But now that LXC won that war, UML is pretty much just a cool debugging tool.
<jorge_> pitti, I think I found a systemd upgrade bug but I'm not sure
<jorge_> moving from 14.04 to 14.10 to 15.04 in steps
<jorge_> `Failed to mount /etc/machine-id: Not a directory` when installing systemd in 15.04
<jorge_> which throws off dpkg and the entire upgrade failed. However if I remove the machine-id directory and replace it with a file with a uuid it finished the upgrade properly
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<alexbligh1> I'm trying to push https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1366174 to completion. There's a fix in trusty-proposed which I have marked verification-done, but looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html there is allegedly a regression in svn. Last build is here: https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=amd64,label=adt/ and indeed the build
<alexbligh1> log shows a failure here: https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=amd64,label=adt/artifact/results/log but I'm having difficulty working out what the failure might be. Possibly due to failure to verify GPG keys. I suspect this is not an apache issue. Any ideas?
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Fix committed]
<alexbligh1> "adt-run [18:49:20]: build not needed" / "tar: Unexpected EOF in archive" is not fantastically helpful ...
 * dholbach hugs didrocks
<cjwatson> alexbligh1: Probably transient, I'll retry it
<alexbligh1> cjwatson, thanks
<cjwatson> The i386 failure looks more real though
 * didrocks hugs dholbach back. Just doing some extras as the queue is quite full :)
<cjwatson> https://jenkins.qa.ubuntu.com/job/trusty-adt-subversion/lastBuild/ARCH=i386,label=adt/console
<dholbach> :)
<dholbach> yes, it is
<cjwatson> Setting up libapache2-mod-svn (1.8.8-1ubuntu3.1) ...
<cjwatson> dpkg: error processing package libapache2-mod-svn (--configure):
<cjwatson>  subprocess installed post-installation script returned error exit status 1
<cjwatson> So there's probably no point in me retrying the amd64 one
<alexbligh1> cjwatson, indeed. I don't have an i386 environment to hand so would be useful to see whether amd64 does the same thing. Do we have a way of knowing whether i386 passed with 2.4.7-1ubuntu4.1 (i.e. the previous release)?
<cjwatson> Probably not, we only brought up autopkgtest for stables relatively recently
<cjwatson> Well, I've retried it
<cjwatson> alexbligh1: This might just mean that the fix for https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1393832 needs to be cherry-picked as well, but I'm not sure.  Perhaps rbasak can investigate.
<ubottu> Launchpad bug 1393832 in apache2 (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [High,Fix released]
<alexbligh1> cjwatson, apt-get install libapache2-mod-svn works fine here (on amd64). Possibly it's broken (and was always broken) on i386.
<cjwatson> I doubt this is architecture-specific.
<cjwatson> It's more likely to be something relatively subtle about ordering like in the bug above.
<alexbligh1> cjwatson, yes, that looks like a good candidate for an explanation. Which would mean it's no more broken than before :-)
<cjwatson> If it is that same issue then it would be better to cherry-pick that fix, I think, rather than trying to identify relative brokenness
<cjwatson> "no more broken than before" is sometimes OK but you have to be quite careful with it.
<alexbligh1> cjwatson, indeed. Presumably someone should nominate https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1393832 for SRU in that case.
<ubottu> Launchpad bug 1393832 in apache2 (Ubuntu) "Modules fail to enable when configured after apache2 is configured" [High,Fix released]
<cjwatson> Well, investigate it first.
<cjwatson> I don't remember whether that only happened due to new dpkg or some other apache2 change.
<cjwatson> alexbligh1: I expect it would not be too hard to reproduce using http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<flexiondotorg_> cjwatson, Can you outline how the 14.04.2 image build are configured to grab the HWE kernel and X stack?
<alexbligh1> cjwatson, interesting. I'll have to look at that over the w/e.
<flexiondotorg_> didrocks, Please consider #1427182 #1427742 #1427744 while you're piloting ;)
<cjwatson> flexiondotorg_: No, sorry, try somebody else :)
<cjwatson> (I'm not up to date)
<flexiondotorg_> cjwatson, :)
<didrocks> flexiondotorg_: I go over bugs as I feel it. I'm already doing some extra rounds, but yeah, I'm reviewing some now :)
<cjwatson> alexbligh1: Yep, now you get the same failure on amd64 too.
<alexbligh1> cjwatson, ok, given it installs fine in a 'normal' situation, I guess it's your difficult-to-reproduce bug. I'll have a look at a chroot over the w/e.
<cjwatson> Like I say it may or may not be the same thing, but that might be a starting point.
<mardy> pitti: hi! I want to write a dbusmock template for my service; can I ship it in my package, or does it have to be included in python-dbusmock itself?
<flexiondotorg_> didrocks, Saw you comments about #1427182. Updated accordingly.
<desrt> didrocks: did anyone mention to you lately that you're a really swell guy?
<desrt> didrocks: because i just thought i'd let you know that
<didrocks> flexiondotorg_: mind providing a debdiff for bug #1427742 (see bug #1427744 for some info), that will make the reviewer's life easier and avoid as well fo you to forget listing some changes
<ubottu> bug 1427742 in mate-menu (Ubuntu) "mate-menu package needs updating" [Undecided,New] https://launchpad.net/bugs/1427742
<ubottu> bug 1427744 in mate-tweak (Ubuntu) "mate-tweak package needs updating" [Undecided,Incomplete] https://launchpad.net/bugs/1427744
<didrocks> also, in the future, better bug title would be appreciated :)
<flexiondotorg_> didrocks, What should the bug title be?
<didrocks> flexiondotorg_: describing why we need the new version in vivid
<flexiondotorg_> didrocks, Understood
<flexiondotorg_> didrocks, Are you asking for debdiffs for these existing bugs or for future requests?
<didrocks> flexiondotorg_: for this ones (well, not the one I commented on with the missing changelog entry, as I did it), but for the remaining ones, please
<didrocks> flexiondotorg_: of course, when you are not doing a merge proposal
<flexiondotorg_> didrocks, OK so for non merge proposals supply a debdiff. Correct?
<didrocks> flexiondotorg_: exactly, that's better than "look at this git with multiple commits where you are not even sure it matches what's the in repo"
<Saviq> pitti, hey, could you point me to some reading about using adt to run autopilot tests on devices?
<flexiondotorg_> didrocks, I am still new to Debian packaging. Therefore, confused.
<flexiondotorg_> didrocks, Please can you tell me the best way to build a new .deb in order to debdiff against it?
<infinity> flexiondotorg_: debdiff the source packages, not binaries.
<ericsnow> pitti: regarding https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020
<ubottu> Launchpad bug 1347020 in lxc (Ubuntu Trusty) "systemd does not boot in a container" [Undecided,Triaged]
<infinity> flexiondotorg_: debdiff old.dsc new.dsc > file.diff
<flexiondotorg_> infinity, Thank you. Fogs clears :)
<ericsnow> pitti: it's still the case that you cannot run a vivid image in a container under trusty, right?
<didrocks> flexiondotorg_: however, please always ensure that your package is building before asking for sponsoring (see my comment on oem-slideshow) :)
<flexiondotorg_> didrocks, Understood.
<flexiondotorg_> didrocks, I checked my build only to discover is was from before I introduced that change. Appologies.
<didrocks> no worry ;)
<infinity> flexiondotorg_: The best documentation of how the 14.04.2 HWE stack is installed is reading the livecd-rootfs source.
<flexiondotorg_> infinity, Yep, found that now thanks :)
<infinity> flexiondotorg_: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trusty-proposed/revision/910?remember=886&compare_revid=886 would be the entire changeset to make it go.
<flexiondotorg_> infinity, Thanks. That's great.
<jamespage> pitti: heat fixed up
<flexiondotorg_> didrocks, Please could you take a look at my last comment in https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1427742
<ubottu> Launchpad bug 1427742 in mate-menu (Ubuntu) "mate-menu package needs updating" [Undecided,New]
<flexiondotorg_> didrocks, Please let me know if this is what you are expecting. If so, I'll prepare the other debdiffs. Thanks for helping.
<jamespage> pitti: well it would be if it did not ftbfs - that's a bit embarrasing
<doko> directhex, could you have a look at https://launchpadlibrarian.net/196773289/buildlog_ubuntu-vivid-amd64.mono_3.2.8%2Bdfsg-4ubuntu2_FAILEDTOBUILD.txt.gz (GCC 5)
<directhex> doko: can you mail jo.shields@xamarin.com and i'll take a look? mid-crisis right now
<doko> directhex, ok, will do
<didrocks> flexiondotorg_: yeah, perfect! sponsored
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<flexiondotorg_> didrocks, Thanks.
<didrocks> yw ;)
<flexiondotorg_> didrocks, So is the one correct now? ;)
<flexiondotorg_> didrocks, https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1427744
<ubottu> Launchpad bug 1427744 in mate-tweak (Ubuntu) "mate-tweak package needs updating" [Undecided,Incomplete]
<didrocks> flexiondotorg_: the debdiff is, however, my comments about debian/copyright changes not listed in changelog and the upstream script changes are still valid
<flexiondotorg_> didrocks, So close ;) One sec...
<flexiondotorg_> didrocks, This? https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1427744/comments/3
<ubottu> Launchpad bug 1427744 in mate-tweak (Ubuntu) "mate-tweak package needs updating" [Undecided,Incomplete]
<flexiondotorg_> didrocks, Thanks for your patience and understanding. I'm reading and learning some of this as I go.
<didrocks> flexiondotorg_: that's good, no worry! always think as rule 0 to ensure your package is building and that the changelog reflects what you change, so it looks good here, let me build it now :)
<didrocks> flexiondotorg_: sponsored (just note that you forgot to reference the bug # in the changelog, please close it manually) :)
<flexiondotorg_> didrocks, Thanks. Adding to my notes about referencing the bug :)
<doko> Riddell, https://launchpadlibrarian.net/196789814/buildlog_ubuntu-vivid-amd64.qca2_2.1.0-0ubuntu3_FAILEDTOBUILD.txt.gz (GCC 5) ... I don't understand the versions for the symbols, why  +git20141126.2258 ?
<doko> kenvandine, bregma: other GCC 5 ftbfs are: unity-scope-home, unity-lens-applications, signon-ui, libdbusmenu, indicator-keyboard
<doko> do you look at any of these?
<kenvandine> doko, mardy handles signon-ui and tedg handles libdbusmenu
<kenvandine> not sure about the rest
<kenvandine> indicator-keyboard is likely the desktop team
<tedg> I think those scopes are bregma's
<kenvandine> yeah
 * tedg tries to convince bregma libdbusmenu is his too
<tedg> :-)
<kenvandine> good luck with that
<bregma> indicator-keyboard is desktop, we'll take care of the scope and lens and libdbusmenu
 * tedg drops mic
 * bregma like to have something mindless to do on a Friday
<doko> GCC 5 fixes are mindless
<tedg> bregma, I looked at that one and it seem the gtk2 tests are breaking. I'd look to see if you can just drop the gtk2 package.
<bregma> numbingly so
<tedg> bregma, I think the xfce folks are moving to gtk3
<infinity> tedg: They are, but not this cycle.
<infinity> tedg: xfce 4.12 is still gtk2.
<tedg> infinity, This is for gcc5 though, so it's next cycle.
<infinity> tedg: Well, "moving to gtk3" has been on the xfce uptream roadmap for 4 years.  I refuse to believe it until I see it land in a stable branch.
<tedg> Heh, well, there is that.
<tedg> I saw it on the Internet, I'm sure it'll happen.
<infinity> tedg: From the 4.12 release engineers:
<infinity> Xfce 4.12 will still use gtk2, with some support of gtk3 for better integration.
<infinity> Port to gtk3 will maybe be done for the next version.
<infinity> ^-- "maybe be done" isn't all that comforting. :P
<ochosi> infinity: will be done
<ochosi> s/maybe be/will be/ :)
<ochosi> https://wiki.xfce.org/releng/4.14/roadmap
<ochosi> we've ported the first component already, so chill out folks ;)
<infinity> ochosi: Ahh, excellent, I hadn't seen the 4.14 roadmap yet.
<infinity> ochosi: Halleluja.
<ochosi> infinity: that's cause i put it up yesterday, maybe? ;)
<infinity> ochosi: Hahaha.
<infinity> ochosi: That would do it. :)
<ochosi> also, if you're referring to gtk2 indicators (not sure from the backlog), we haven't been using those since trusty
<ochosi> our panel has had support for gtk3 plugins for a while now
<ochosi> we even use symbolic icons already for two of our plugins, so you could say we're slightly ahead of the indicators there ;)
<ochosi> anyway, if you have xfce-related questions, feel free to ping me
<ochosi> (or xubuntu-related)
<doko> kenvandine, tedg,, bregma: libdbusmenu, indicator-keyboard, unity-scope-home, signon-ui also fail in vivid (default GCC)
<tedg> Cool, thanks ochosi
<ochosi> np
<infinity> ochosi: "We should have no need for Feature Freeze if we don't add features."
<infinity> ochosi: You're very optimistic about everyone playing your game, I see. :)
<ochosi> infinity: well, that's for -core ;)
<ochosi> and yeah, i can be very strict!
 * ochosi goes to the cabinet and gets the elephant whip...
<infinity> I need one of those.
<tedg> infinity, Ringling Brothers garage sale?
<ochosi> infinity: while i have your attention...
<infinity> ochosi: 'sup?
<ochosi> would you mind ack'ing the other components on here? https://bugs.launchpad.net/ubuntu/+source/xfce4/+bug/1424887 - and with the libxfce4util bump from 6 to 7, we'll need to rebuild a few packages.
<ubottu> Launchpad bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<infinity> ochosi: Can you lend me your whip?
 * ochosi hands infinity the elephant whip
<infinity> Such a trusting fellow.
<ochosi> :]
<ochosi> very
<infinity> ochosi: So, I'm quite fine with just saying that, IMO, we can extend Scott's ACK to cover any 4.12 updates you need to do for the next week or two.
<ochosi> nice, thanks a bunch!
<infinity> ochosi: If things end up close to the wire, we'll want to think hard about it, but for now, I'd rather you get it all in than have half a version bump in xfce.
<ochosi> yeah, in fact we've been stuck with several 4.11 components for a few releases now
<ochosi> so it'd be great to finally be on a stable one for a change :)
 * infinity nods.
<infinity> Go forth and stabilise.
<ochosi> should we do the rebuilds after libxfce4util releases from -proposed or do a dep wait for the packages so they can go at once?
<infinity> ochosi: Why the rebuild?  ABI changes?
<infinity> ochosi: And if ABI changes, does that mean a new SOVER?
<infinity> ochosi: Cause if there's a new SOVER, it'll be stuck in -proposed until it all rebuilds anyway, you have no choice in the matter.
<ochosi> yeah, but lemme quickly check what changed exactly in libxfce4util
<ochosi> bluesabre was handling all that...
<ochosi> (also, i'm not really a packager)
<infinity> ochosi: But no need for a bunch of versioned build-deps, just wait until it's published on all arches according to rmadison, then go to town.
<ochosi> righty
<ochosi> bluesabre: copy that ^
<ochosi> so yeah, SONAME bump from 6 to 7
<infinity> ochosi: Right, so that will just happily sort itself and stage correctly.
<infinity> ochosi: Just so long as the rebuilds are all uploaded after "rmadison libxfce4util7" shows 6 happy published binaries.
<ochosi> yup, dropped some symbols, took me a bit to find that now :)
<ochosi> ok, perfect
<flexiondotorg_> Evening.
<flexiondotorg_> I've just been testing 14.04.2
<flexiondotorg_> Seems a bit busted to me. Is this known about?
<flexiondotorg_> For example, it is impossible to install ubuntu-sdk in a fresh Ubuntu 14.04.2
<xnox> how do I view _my_ repositories on gitorious.org?
#ubuntu-devel 2015-03-07
<doko> adt-run [15:12:32]: test testsuite: -----------------------]
<doko> adt-run [15:12:33]: test testsuite:  - - - - - - - - - - results - - - - - - - - - -
<doko> testsuite            FAIL stderr: status: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<doko> pitti: ^^^ in python2.7 and python3.4
<cjwatson> doko,pitti: Surely that is a bug in your testsuite?  You're using literal "stop" etc. for apport rather than the corresponding service wrappers.
<doko> cjwatson, that's what pitti told me in the past .... will fix it
<tsg_> folks, looking for help to speed up https://bugs.launchpad.net/trusty-backports/+bug/1428834 (backport for trusty).  Anyone from ubuntu backporters team can suggest how to get this moving?  I have a backport for trusty available locally, is there a way I can contribute?
<ubottu> Launchpad bug 1428834 in trusty-backports "[FFE] Please backport jerasure and lib-gf-complete from utopic" [Undecided,New]
#ubuntu-devel 2015-03-08
<knocte> looks like there's an easy workaround with all the 14.04 libmtp bugs (https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1314556): kill the mtp daemons (killall gvfs-{gphoto2|mtp}-volume-monitor)
<ubottu> Launchpad bug 1314556 in gvfs (Ubuntu) "Unable to mount Android MTP device" [High,Confirmed]
<knocte> do you guys know if this has been worked on, in 14.10 or 15.04?
#ubuntu-devel 2016-03-07
<danjared> cyphermox: hey Mathieu, I was wondering where you were with your TPM ITPs (#815846 and #815849)
<cpaelzer> good morning
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg> hi folks, any core-dev here can upload llvm-toolchain-3.8 to main pretty please?
<LocutusOfBorg> trivial diff, the stable 3.8 is out
<LocutusOfBorg> I opened #1553923
<LocutusOfBorg> doko asked me a while ago to do it :)
<ginggs> LocutusOfBorg: i'll look at llvm-toolchain-3.8 now
<LocutusOfBorg> ta
<seb128> dear launchpad could you stop timeouting on bugs edit?
<LocutusOfBorg> can anybody please ignore virtualbox autopkgtest?
<LocutusOfBorg> they are xorg-server related
<jtaylor> its getting really hard to backport packages to trusty, e.g. dpkg does not support !no-check
<jtaylor> which makes backporting dpkg impossible, which is needed for a lot of other packages
<jtaylor> are there maybe plans to bootstrap a newer dpkg into trusty to help backporting?
<LocutusOfBorg> ok folks, I'm really lost.
<LocutusOfBorg> ismrmrd is failing for armhf, but working correctly on pbuilder-qemu chroot
<LocutusOfBorg> same toolchain, seems the ubuntu builders are somewhat broken
<LocutusOfBorg> unknown location(0): fatal error in "test_acquisition_header": memory access violation at address: 0xbefd15da: invalid address alignment
<LocutusOfBorg> Test is aborted
<mapreri> LocutusOfBorg: imho you should get per-package upload rights for llvm-toolchain (at least)
<LocutusOfBorg> or bother about becoming core-dev (joke)
<LocutusOfBorg> :)
<mapreri> can some core-dev try having a look at maybe syncing python-pymysql?
<ginggs> mapreri: 'requestsync -e python-pymysql'
<cyphermox> danjared: should be done today
<mterry> seb128, re: MIR bug 1552507, is that something the desktop team would look after?
<ubottu> bug 1552507 in a11y-profile-manager (Ubuntu) "[MIR/FFE] Promoting a11y-profile-manager to main." [Undecided,Incomplete] https://launchpad.net/bugs/1552507
<seb128> mterry, yes
<mterry> seb128, can you bug subscribe?  that's all that's left for the MIR
<seb128> mterry, done
<mterry> seb128, thanks!
<seb128> mterry, yw!
<smb> mvo, Hm, did something change so a Xenial desktop may not look for dep-11 data on "apt-get update"?
<mvo> smb: there was a new apt version a couple of days ago, but the changes are very small and isolated, I (strongly) doubt this broke anything. what issue do you see? the appstream metadata is not downloading? or do you use something other dep11 metadata?
<smb> mvo, Oh I try try (or tried to) verify fixes to older apt-cacher-ng installs (P and T) and in the pastapt-get update was showing errors with an older caching... But today I fail to get those. Maybe something else I installed on the test box...
<mvo> smb: ok, please let me know if you have more details or if there is anything I can do
<smb> mvo, will do. was just wondering whether that maybe got disabled for normal desktops and I dig around for nothing.
<tjaalton> how can kvm hosts recover a host network restart? they all use the bridge provided by host
<tjaalton> *kvm guests
<caribou> xnox: just saw your s390x sosreport plugin issue, just let me know if I can help
<xnox> caribou, well, it was more of a todo item for myself =)
<xnox> caribou, in general we have a debug.sh script in s390-tools which collects half the things sosreport does, and does a few z Series specific things
<xnox> caribou, imho all the juicy bits should be merged into sosreport.
<caribou> xnox: the plugin is not enabled for Ubuntu/Debian so it will only work on RedHat,
<xnox> caribou, oh.
<xnox> caribou, maybe we shall fix that on s390x =) cause we have s390x on ubuntu....
<caribou> xnox: then just send them my way and I'll get them upstream
<caribou> xnox: indeed, I'll fix that up
<xnox> caribou, is that a packaging change....
 * xnox takes a look
<caribou> xnox: small change in the plugin; look at other 'enabled' pluging (juju is one)
<caribou> xnox: I'm part of the upstream dev team, that could help
<xnox> let me make a merge proposal then =)
<xnox> ;-)
<caribou> xnox: well juju is not a good example as it is only enabled for Ubuntu
<xnox> i found e.g. dbus.py
<xnox> which is what i need/want =)
<caribou> xnox: FYI, I'm currently reorganizing the sosreport git repo so the debian bits are kept on alioth
<barry> pitti: can you poke python-virtualenv 14.0.5+ds-6 in s390x?  it's been sitting in "Test in progress" since the weekend and it's holding up python-pip migration
<xnox> arges, thank you. appointed.
<arges> xnox: : )
<Beret> can someone tell me why software-properties-common requires unattended-upgrades?
<rbasak> mvo: can you help? ^^
<Beret> it's quite reasonable that one would want add-apt-repository without unattended-upgrades - especially now that they're on by default
<Beret> mvo, can you guys sort - https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487 ?
<ubottu> Launchpad bug 831487 in software-properties (Ubuntu) "Dependency on package unattended-upgrades on Ubuntu Server" [Undecided,Confirmed]
<ogra_> infinity, bug 1553110 seems to get worse the deeper i dig
<ubottu> bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110
<juliank> cjwatson: mvo: Can someone syncpackage apt 1.2.5 now?
<juliank> I forgot to mention this when I woke up
<juliank> cjwatson: Given that you want to issue your commit in there as an SRU :)
<juliank> And at the end of the week, there will be 1.2.6 which fixes a stack buffer overflow
<juliank> (outside of parser code, in the solver, when you do crazy things; and caught by stack protector)
<juliank> So _low_-risk
<juliank> I could also release that now, though
<juliank> OK, I released apt 1.2.6 now. It might make sense to get that diff into trusty as well: https://paste.debian.net/412876/
<juliank> (That's the backport to pre-C++11 compilers)
<jderose> cyphermox: this week oem-config seems very broken. as far as i can tell, the underlying problem is the "oem" user isn't getting removed after oem-config-firstboot runs
<cyphermox> jderose: ack, please file a bug and I'll test it here and fix whatever is it that got broken
<jderose> cyphermox: just finished filing a bug - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1554194
<ubottu> Launchpad bug 1554194 in ubiquity (Ubuntu) "/home/oem and oem user are not removed by oem-config-firstboot" [Undecided,New]
<jderose> cyphermox: not sure it's actually a Ubiquity bug yet, could have been broken by other changes too :)
<cyphermox> well, there wasn't a new ubiquity I know of that would have broken it this week
<jderose> cyphermox: it might have been introduced in 2.21.47, it's been a while since i checked. i was originally going to follow up with an issue with oem-config + encrypted home directory, but seems since i last tested, oem-config got kinda broken overall
<cyphermox> ok
<cyphermox> well, things change, maybe this happened as a side-effect of some other thing
<jderose> yeah, could be. that's my guess actually, but i don't know for sure yet :)
<cyphermox> :)
<smoser> is there a reason that 'journal -x -o verbose' would not seem to show a service file output ? ('systemctl status pollinate' shows it ran and had output)
<smoser> i was hoping to basically get a log of all 'Starting' like things
<tjaalton> so with the dhclient/bind bug in xenial I'm forced to restart networking on my kvm host, but it kills network on the guests.. how to fix that?
<tjaalton> [277346.078520] br0: port 5(vnet3) entered disabled state
<tjaalton> etc
<smoser> tjaalton, what is forcing you to restart networking ?
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1551351
<ubottu> Launchpad bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed]
<mvo> rbasak: lets talk tomorrow, I only saw the question about https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487 now
<ubottu> Launchpad bug 831487 in software-properties (Ubuntu) "Dependency on package unattended-upgrades on Ubuntu Server" [High,Triaged]
<mvo> juliank: I can do a sync if it was not done already
<slangasek> nacc: php-imagick is unblocked in proposed-migration now, but there are packages that still depend on php5-imagick, so it won't propagate: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<nacc> slangasek: looking
<slangasek> and I hinted wrong, so php7.0 isn't yet a candidate but will be in the next p-m run
<nacc> slangasek: ok, i see the list, can i provide additional debdiffs in the same bug for the other packages? will need to build & test them here first
<slangasek> nacc: sure, just make sure you open bug tasks against those source packages
<nacc> slangasek: yep, will do
<nacc> slangasek: thanks for all your help! i know this one has been bad
#ubuntu-devel 2016-03-08
<smoser> pitti, awake ?
<Guest36261> Hey guys! Can someone suggest a resource for how to get started submitting this: http://https://askubuntu.com/a/674103/299065 as a patch for 14.04? Every time I update ubuntu base I have to do this and wanted to just backport it once and for all.
<Guest36261> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633
<ubottu> Launchpad bug 1498633 in System76 "drivers/net/ethernet/atheros/alx: please add device ID for Killer E2400" [Critical,Fix released]
<micahg> Guest36261: the xenial kernel will be backported to 14.04 sometime after the initial release
<sarnold> Guest36261: try using the linux-lts-wily packages
<Guest36261> ah ok
<Guest36261> exit
<sarnold> Guest36261: this may be helpful https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<Guest36261> lol
<sarnold> (and you;'re probably looking for /quit)
<Guest36261> heh... been using slack too much. spoiled
<RAOF> Oh, urgh.
<Guest36261> sarnold: oh I think this is exactly what I need
<RAOF> I don't suppose we can throw away a single architecture's builds from -proposed.
<sarnold> Guest36261: note that you'll probably want to switch to linux-generic-lts-xenial once it is available, it'll be supported a lot longer
<RAOF> (apitrace hasn't migrated from -proposed because it built on s390x before libprocps4 was available there)
<sarnold> Guest36261: (or switch to xenial itself, of course, up to you :)
<tumbleweed> RAOF: nope, no-change rebuild
<RAOF> tumbleweed: Yup, thought as much.
<tumbleweed> LP has principles about rewriting history :)
<AustinPray> Guest dude here
<AustinPray> thanks for the help. Maybe one of these days I'll get to patch something :P
<sarnold> :)
<AustinPray> sarnold: I don't think you understand how much that wiley kernel fixed lol
<AustinPray> problems I didn't even know I had
<sarnold> AustinPray: oh? :)
<cpaelzer> good morning
<rbasak> mvo: sure. ping.
<dholbach> good morning
<cpaelzer> hi, I'd ask for some advice on a dependency for a package I'm working on
<cpaelzer> its working fine without, but depending on the case can be enhanced when modules from "linux-image-extra*" are around
<cpaelzer> that fulfils a "suggests" IMHO
<cpaelzer> but my gut feeling says that with a dependency because of a kernel module it might be more complex than just "suggests linux-image-extra-virtual"
<cpaelzer> like what about hwe kernels ...
<cpaelzer> any general rule how we usually do this?
<cpaelzer> still too early :-) rbasak I saw you pinging already this morning do you have an advice on my question above?
<rbasak> I wonder if "extra" is something that those packages official Provide or something.
<rbasak> I don't know though. apw is a good person to ask.
<rbasak> (he's UK based so may be around soon)
<cpaelzer> rbasak: thanks, I'll ask him later
 * LocutusOfBorg wonders about a glibc upgrade for xenial
<smb> cpaelzer, rbasak, If it is just about what "extra" this is. More or less any modules that were not deemed critical (or in other words, those that cloud-image did not want to get installed)
<cpaelzer> smb: I found what the package is about and it clearly is a suggets
<cpaelzer> smb: I wondered if that would be "Suggests: linux-image-extra-virtual" then or any more special case to get dependencies and versioning right
<cpaelzer> that line above is what I think it should be atm, but I wanted some confirmation about that as my gut feeling was telling me this could be a special case
<smb> cpaelzer, That and the virtual. That is something (iirc) that only exists as meta package dependencies. There is (for quite a while now) no kernel flavour of virtual anymore
<smb> only generic and lowlatency (for x86)
<rbasak> Part of the problem is that it's only a moving metapackage and it's feasible to not have one installed.
<cpaelzer> smb: yeah linux-image-extra-virtual is a meta that pulls in what currentl ymatches
<rbasak> So it'd be better if the real package provided an unmoving virtual package.
<rbasak> (I don't know if it already does)
<smb> rbasak, there is no real virtual package
<rbasak> OTOH, it's only a Suggests, and nothing does anything with those by default AFAIK.
<smb> actually linux-image-extra-virtual would be even more feasible having not installed as the whole virtual meta thing is about having a meta that keeps the combination of kernel and headers moving over abi changes without the extra ...
<cpaelzer> smb: rbasak: thanks for the discussion - I just wanted to do it right in te first try, but it seems there are no hard objections against it
<cpaelzer> so I can go on and test it like this for now
<smb> cpaelzer, ^ not sure you saw my last comment as we probably typed at the same time
<cpaelzer> smb: in a meeting, thanks IÃll go through it in a minuzte
<mvo> stgraber: the most recent gosexy-gettext upload had issues, I did a followup upload (just fyi), stuff should be fixed now
<mvo> rbasak: hi, oh, software-properties-common, hm
<mvo> rbasak: I htink we can drop this dependency, we just need to make sure that the GUI does not offer to set "auto-install-security-updates"
<oSoMoN> Mirv, seen the latest comments on https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1552860 ? Can you maybe comment?
<ubottu> Launchpad bug 1552860 in qtsystems-opensource-src (Ubuntu) "[MIR] qtsystems-opensource-src" [Undecided,Incomplete]
<mvo> rbasak: if it is not installed
<mvo> rbasak: that was the question, right?
<rbasak> mvo: yes, I think so. I think it comes from "Why can't I remove unattended-upgrades without breaking my system more deeply?" -> "Can we remove the dependency?" -> "What might we break if we remove the dependency and how might we fix that?"
<Mirv> oSoMoN: ok
<mvo> rbasak: I think we should remove the dependency and fix the gui to ensure it DTRT and then we seed unattended-upgrades explicitely where it is needed
<rbasak> mvo: that sounds good :)
<rbasak> Beret: ^
<rbasak> mvo: right now it's a hard dependency. I wonder if seeding as a recommend would be more appropriate for what it is?
<mvo> rbasak: that might be a good compromise and less work, I think removing the hard dependency is slightly better though
<rbasak> mvo: sorry, I didn't explain that well. That's not what I meant. I mean to remove the hard dependency *and* seed it as a recommend only.
<mvo> rbasak: indeed, that makes a lot of sense
<Odd_Bloke> So I've found a bug in python-colorama, which has no diff from Debian.  Upstream have kindly cut a new microrelease, which only contains bugfixes (including the fix for my bug, obvs :p).  If I find someone to upload the fixed version to Debian, presumably it can just be sync'd across?  Though presumably I still need an FFE?
<juliank> Something seems broken with the APT translation import in launchpad. https://translations.launchpad.net/ubuntu/+source/apt lists the apt-all template shipped in the source package; and a lot of others. Now, apparently the importer tried to import some apt and apt-utils templates (don't ask me how), but those miss headers.
<juliank> mvo: ^ Do you know how this stuff works?
<mvo> juliank: I don't know much about it either, its all black magic to me :/ dpm or danilo probably do
<juliank> OK, I wonder where it gets those split templates from
<seb128> juliank, there are probably several .pot in the apt builddir?
<seb128> or srcdir
<juliank> There are somewhere in build/, yes
<seb128> k, well if they are there then launchpad import them
<seb128> why is that an issue?
<juliank> Because they are only partial templates, they only contain msgid and msgstr, but no headers
<juliank> the files are then merged into apt-all
<seb128> it's fine
<seb128> juliank, https://translations.launchpad.net/ubuntu/xenial/+source/apt/+imports?field.filter_status=all&field.filter_extension=pot
<seb128> the apt-all has been imported
<seb128> which is what matters no?
<juliank> Hmm. The apt packages split apt-all translations later on to create individual apt, apt-utils, ... mo files. So I'd assume the split domain imports are the important ones, as apt does not use an apt-all domain
<seb128> weird setup :-/
<juliank> If so, we might not have noticed that in the past years, and APT never used langpack translations.
<seb128> can you make those templates be valid and have headers then?
<juliank> I don't know yet
<cjwatson> apt basically can't use langpacks anyway
<cjwatson> I mean, it's not just that it happens not to, but that its translations are needed before we get langpacks in place ...
<juliank> cjwatson: then it's kind of silly to waste translator time with this at all, isn't it?
<cjwatson> *shrug*
<cjwatson> ah, no, its translations actually do end up in langpacks, they just can't be *stripped* from the apt packages
<cjwatson> so I guess that means apt gets newer translations from langpacks if they're there, but it also ships its own for bootstrapping purposes
<cjwatson> that would approximately make sense
<juliank> mvo: Feel free to sync 1.2.6 now, BTW. This fixes comment typos and also takes care of the stack buffer overflow in the resolver.
<juliank> cjwatson: yep
<juliank> thanks to xnox for already having done the 1.2.5 sync
<dpm> juliank, seb128, yeah, I don't have to add anything else that cjwatson hasn't already said. apt is a bit of a special case in that regard
<juliank> mvo: oh, it's already there
<xnox> Odd_Bloke, not really. depends on how cryptic the things are.... ping people, e.g. me, when there are things to sync =)
<juliank> It's listed as latest upload; but not under the xenial section in https://launchpad.net/ubuntu/+source/apt
<cjwatson> https://launchpad.net/ubuntu/+source/apt/+publishinghistory makes the state clearer
<juliank> Yeah
<juliank> I should complete my uploading thingy, so I can sync APT bugfixes myself
<Odd_Bloke> xnox: Well, barry last uploaded python-colorama in Debian so I was going to ping him. ^_^
<Odd_Bloke> barry: There's a new upstream version of python-colorama which has a bugfix (https://bugs.launchpad.net/ubuntu/+source/python-colorama/+bug/1554129) that I'd like for xenial; would you be able to upload and sync? :)
<ubottu> Launchpad bug 1554129 in python-colorama (Ubuntu) "python-colorama breaks jedi-vim plugin on xenial" [Undecided,New]
<Odd_Bloke> It's, like, super critical because I can't autocomplete Python in vim any more, and it turns out I have the memory of a dead wombat. :p
<xnox> Odd_Bloke, breaks jedi-vim -> sounds like a feature to me
<Beret> mvo, rbasak - +1 - the hard dependency doesn't make sense
 * xnox hides
<juliank> uploading thingy = https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU2
<juliank> (which was not supposed to have a 2 in it, but wiki did not let me create a page without the 2 IIRC)
<juliank> It also needs severe updating.
<mvo> juliank: yeah, I did sync it this morning
<xnox> caribou, may i cherrypick sosreport patch into ubuntu upload?
<xnox> and then you can trump it whenever?
<caribou> xnox: sure
<cpaelzer> apw - smb and I came to an interim solution, but still want to hear your input on the discussion we had this morning, so just let us know when you are around
<cjwatson> pitti: https://bugs.launchpad.net/bugs/1554266 - neither openssh nor systemd apparently changed at the relevant time.  do you have any ideas even on what category of problem might be involved here?
<ubottu> Launchpad bug 1554266 in openssh (Ubuntu) "sshd does not start on newly installed desktop system" [Undecided,New]
<LocutusOfBorg> please ignore virtualbox autopkgtest
<pitti> cjwatson: the postinst looks okay to me; init-system-helpers changed, perhaps there's some subtle behaviour change there
<Mirv> pitti: could you rerun the failed amd64 ubuntuone-credentials test from https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-050/excuses.html manually since it's one of these "does not have any test results" ones?
<pitti> barry: done; but it failed on the other arches, so that won't unblock it
<pitti> smoser: sorry, I'm sick, please email
<pitti> smoser: ah, I have an email from you already
<pitti> Mirv: poked
<pitti> cjwatson: sorry, can't investigate today, still too sick
<cjwatson> pitti: fair enough!  gws
<pitti> cjwatson: https://launchpad.net/ubuntu/+source/init-system-helpers/1.29ubuntu1 landed on March 4th, so most probably that one
<pitti> cjwatson: most of the changes are for OpenRC and thus a no-op for ubuntu; apparently update-rc.d works fine (as the service works after reboot), so maybe some weird fallout from invoke-rc.d
 * cjwatson scribbles a note in the bug
<Laney> apw: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1550741/comments/10 might interest you :-)
<ubottu> Launchpad bug 1550741 in ubuntu-release-upgrader (Ubuntu) "Upgrade failed - unauthenticated package (module-init-tools)" [Critical,Confirmed]
<jamespage> cjwatson, need a second opinion on a net-tools merge I've managed to miss if you have a second
<cjwatson> jamespage: I guess - what's up?
<jamespage> cjwatson, so - there was a upload of a git snapshot into debian last year (1.60+git20150829.73cef8a)
<jamespage> I've rebased all of the Ubuntu patches, and it works OK but the output of the tools is quite different..
<jamespage> cjwatson, my gut feel is right now is not the right time to make that kind of change in xenial - what do you think?
<cjwatson> hmm.  all other things being equal I'd prefer to have something vaguely resembling an upstream snapshot rather than 14yo orig + pile of patches, but I'd tend to agree now maybe isn't the best time to go finding new and exciting bugs in scripts that use net-tools
<jamespage> cjwatson, for reference:
<jamespage> http://paste.ubuntu.com/15327221/
<jamespage> http://paste.ubuntu.com/15327223/
<jamespage> first is new, second is current
 * jamespage shudders about all of the sed/awk/grep -ing that will break...
<Saviq> doko, hey, can you please have a look at bug #1552914, thanks!
<ubottu> bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,New] https://launchpad.net/bugs/1552914
<tjaalton> pitti: hey, do you know why virtualbox is confused about the xserver version? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/virtualbox/20160306_082831@/log.gz
<tjaalton> oh, some dependency not rebuilt against the new xserver then
<pitti> tjaalton: I re-ran against all of -proposed for now, might just be some missing versioned dep
<jamespage> rbasak, not sure if net-tools is on your list but raised:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/net-tools/+bug/1554490
<ubottu> Launchpad bug 1554490 in net-tools (Ubuntu) "Merge net-tools 1.60+git20150829.73cef8a-2 from unstable" [Undecided,New]
<jamespage> not for this cycle...
<tjaalton> pitti: ok thanks
<cjwatson> jamespage: mm, quite.
<tseliot> pitti: what's up with virtualbox? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/virtualbox/20160307_205918@/log.gz
<rbasak> jamespage: thanks. Looks like it is on our list.
<rbasak> (ie. ~ubuntu-server has a team subscription)
<pitti> tseliot: see tjaalton's question from 3 minutes ago; retried with all of -proposed for now
<pitti> if that still doesn't help, then there's some rebuild missing somewhere
 * pitti crawls back into bed, sorry
<tseliot> pitti: oh, sorry, I missed that
<tjaalton> hehe, echo here too
<tjaalton> pitti: ouch.. sorry for pinging
<pitti> tjaalton: no worries, I answered :)
<tseliot> tjaalton: ok, ok, I'll let you do all the speaking today :P
<tjaalton> tseliot: :P
<jamespage> rbasak, yes - it comes up under ubuntu-server...
<ogra_> hmm, looks like the livefs builders do not produce any images for snappy anymore ... i only see manifest files
<Odd_Bloke> caribou: Any news on https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/1544719?
<ubottu> Launchpad bug 1544719 in squid-deb-proxy (Ubuntu) "does not start on install / depends on squid which is squid3" [Critical,Confirmed]
<caribou> Odd_Bloke: I wanted to ping smoser about it to see if he was planning on fixing it
<caribou> smoser: ^^
<caribou> Odd_Bloke: other than that I don't mind fixing ig, just got bitten by it again today
<LocutusOfBorg> doko, could you please wait next time for llvm-toolchain-3.8?
<LocutusOfBorg> ginggs, ^^
<LocutusOfBorg> I don't agree with your upload
<LocutusOfBorg> you forget to mention the breaks+replaces in changelog, the dh_strip hack is not needed anymore (done in dh_install already), and I don't think disabling lldb on s390x is needed
<LocutusOfBorg> do you have any information about it?
<LocutusOfBorg> oh loool, you didn't disable it, Debian disabled it :) so just changelog needs to be dropped on that point
<cjwatson> ogra_: link?
<LocutusOfBorg> anyhow, maybe you can sponsor this package as ubuntu2 https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/6183347/+listing-archive-extra
<cjwatson> ogra_: note that binary files are garbage-collected after a day or so
<ogra_> cjwatson, yeah, seems it was some browser weirdness, now i see them
<LocutusOfBorg> BTW thanks for your work :)
<ogra_> cjwatson, mind taking a look at http://paste.ubuntu.com/15327524/ ? i want to have the livefs build spit out an os-snap with that (i'm specifically unsure about line 41, but dont really want to make snappy a dependency of livecd-rootfs)
<kirkland> mvo: seb128: hey guys -- could you make unattended-upgrades a "recommends" in software-properties, rather than a depends?
<kirkland> mvo: seb128: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/831487
<ubottu> Launchpad bug 831487 in software-properties (Ubuntu Xenial) "Dependency on package unattended-upgrades on Ubuntu Server" [High,Triaged]
<seb128> kirkland, hey, mvo and rbasak discussed it earlier, see backlog from ~4hours ago
 * kirkland scrolls up
<kirkland> seb128: excellent, thanks.
<seb128> yw
<ricotz> hi, this could probably use some more attention https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/1493999
<ubottu> Launchpad bug 1493999 in xz-utils (Ubuntu) "xz-utils package is really, really old" [Wishlist,Triaged]
<seb128> unsure if somebody agreed on doing the changes though
<ricotz> doko, hi, this aptitude merge should be stable https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6180753/+listing-archive-extra
<rbasak> That's a good point. mvo, are you taking on the work?
<cjwatson> ogra_: don't cd, you don't really need to here and it's implicit state that will confuse somebody.  I don't remember whether you can apt-get install there; try it with a livecd-rootfs in a PPA and see if it works.  The important thing for adding new artifacts is that they need to be copied/moved/linked to something beginning with "$PREFIX."
<cjwatson> ogra_: also consistent indentation would be nice
<cjwatson> (bottom three commands inside the inner if/fi block are misindented)
<ogra_> oh
<ogra_> hmm, the $PREFIX thing might be a bit of a problem since snappy checks the filename against the metat data at install time, so the filename needs to end up without $PREFIX again
<cjwatson> ogra_: you're entirely free to rename it again in whatever code downloads the built artifacts from Launchpad
<ogra_> yeah
<kirkland> seb128: I attached a patch at https://launchpadlibrarian.net/247135751/831487.patch
<kirkland> seb128: can I go ahead and upload that?
<kirkland> seb128: or are you guys working on a different solution?
<flexiondotorg> xnox, smoser, tjaalton Hi pilots - I'd really appreciate it if you can look at my sponsoring requests during your stints today :-)
<seb128> kirkland, it's not as simple I think, as discussed between mvo and rbasak earlier, if it's demoted from depends then the code needs to deal with the case where it's not installed (which it doesn't atm)
<seb128> kirkland, like the combo should let you pick auto update if the service is not there
<seb128> kirkland, sorry, "should *not*"
<kirkland> seb128: oh, interesting.
<kirkland> seb128: is someone actually working that, then?
<seb128> kirkland, that's what I asked earlier, but I don't think so no
<mterry> cyphermox, didrocks: do either of you have time for some python MIRs?
<kirkland> seb128: okay thanks;  mvo, rbasak: can you please comment in the bug, with anything else that needs to be done, above and beyond the simple depends->recommends change?
<didrocks> mterry: unfortunately, not at all :/ I don't have enough time to finish what I need to do already :(
<rbasak> kirkland: done
<cyphermox> mterry: assign me stuff, I'll make the time
<smoser> caribou, i have no plan on fixing squid-deb-proxy, but i think that -proposed should have a fix from rbasak
<smoser> bug https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,Fix committed]
<caribou> smoser: true, he's merging the newest
<caribou> Odd_Bloke: ^^
<caribou> smoser: thanks!
<smoser> Odd_Bloke, caribou you can and should test -proposed
<smoser> enable proposed, see if it works for you
<caribou> smoser: ok, I will
<smoser> if not, please respond on that bug
<barry> Odd_Bloke: yep, i'll look at it
<barry> pitti: no worries, we have a new version i'm about to sync
<Odd_Bloke> barry: Thanks!
<tjaalton> how frequently should "valid candidates" be moved to main from excuses list?
<juliank> Where should bug #1553870 be reassigned? Apparently upgrading a trusty system from the xenial live did not write correct sources.list
<ubottu> bug 1553870 in apt (Ubuntu) "apt sources contain "True" entries after upgrade to xenial" [Undecided,New] https://launchpad.net/bugs/1553870
<Odd_Bloke> rbasak: smoser: I hit a problem when upgrading to the -proposed squid; I've added a comment to bug 1473691 with details. :)
<ubottu> bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,Fix committed] https://launchpad.net/bugs/1473691
<juliank> Alberto Salvia Novella is a pain in the ass.
<juliank> *Every* bug I see him doing something, the importance is extremely wrong; he closed the bug in the wrong package; or did other crazy stuff.
<juliank> It is completely unbelievable to me why he is in ubuntu bug control.
<smoser> rbasak, please see Odd_Bloke 's comment in said bug
<cyphermox> juliank: ubuntu-release-upgrader?
<mdeslaur> pitti: I'm stealing your bsh merge
<juliank> cyphermox: thx
<rbasak> kirkland: I don't know who will fix the GUI. I asked mvo above but I guess he's not around.
<mvo> rbasak: ups, sorry, I must have missed that. I could fix it (i.e. I know this code) but I'm super busy with stuff, would be better if someone from the desktop team could have a look, probably really easy
<seb128> rbasak, mvo, I can have a look I guess
<LocutusOfBorg> can anybody ruby-savvy look at gitlab migration? some dependencies don't build cleanly, e.g. ruby-sentry-raven
<LocutusOfBorg> but I fail to understand why
<mvo> seb128: its hopefully as simple as "if not os.path.exists("/usr/bin/unattended-upgrade"): combobox.remove(security_option)"
<seb128> mvo, yeah, I looked around that code yesterday for the autodownload thing, so I think I know what to do
<mvo> great
<mvo> thanks a bunch seb128
<seb128> yw!
<hallyn> pitti: mvo: is there a way to tell adt to update a kvm image?  or do i need to run it by hand and update?
<Odd_Bloke> arges: I believe you're on the hook for migration of cloud-init in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551419; I've performed validation and it's good to go. :)
<ubottu> Launchpad bug 1551419 in linux (Ubuntu) "[SRU] Handle changing UUID endian-ness on Azure in cloud-init" [Critical,Confirmed]
<arges> Odd_Bloke: looking
<Odd_Bloke> arges: Thanks. :)
<arges> Odd_Bloke: so cloud-init has only been in proposed for 4 days, is the main conern ensuring this gets in before the kernel update?
<Saviq> slangasek, hey, can you make sure someone has a look at bug #1552914
<ubottu> bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,New] https://launchpad.net/bugs/1552914
<Saviq> slangasek, +please, thanks!
<Odd_Bloke> arges: That's the primary concern, yes.
<smoser> so why do i not see journal entries for all jobs that ran ?
<rharper> rbasak: nacc:  I'm doing another git merge reconstruct;  the first ubuntu delta has changes to package debs in debian/control as well as the maintainer change;  should I attempt to break those out into separate changes (so one can commit just the maintainer change as a single commit) ?
<nacc> rharper: right, the maintainer change should be in its own meta
<nacc> and it's only present in reconstruct/
<rharper> ok
<nacc> it gets dropped for logical/
<rharper> yeah
<nacc> so it's best to have it separate
<nacc> iirc, it's always in that first delta, and then propogated from there. I think there's a bit in the wiki that mentions that
<nacc> rharper: but the goal should be one logical (bad choice of words) change in each commit ... ideally relative to the changelog entries themselves, followed by a changelog commit and a meta commit
<rharper> yep; it is
<rharper> it just wasnt' clear from the text if one should explicitly modify control changes into two commits (maintainer, <other changes logged in changelog> )
<doko> LocutusOfBorg, no
<LocutusOfBorg> doko, no <-- context? :p
<nacc> rharper: that's what i've always done, at least :)
<doko> Saviq, next week; please ask xnox if it needs to be done earlier
<doko> Saviq, xnox: maybe just drop that compiler dependency
<Saviq> doko, ack, thanks
<xnox> doko, i think so.
<rbasak> nacc: I think logical is exactly the right choice of words. That's why I call that branch "logical" :)
<rbasak> infinity: around?
<rbasak> (about that Juju discussion)
<mterry> cyphermox,  thanks for the MIR help!
<cyphermox> mterry: no worries
<dobey> does xorg in xenial not do randr 1.5?
<nacc> dobey: it would appear to be 1.4, based upon xrandr's output, but libxrandr2 is at 1.5.0-1?
<seb128> dobey, that's a question for tjaalton but I would guess it does because we had to patch gtk to handle randr 1.5
<tjaalton> dobey: xserver 1.18 just went in, it does 1.5
<dobey> i just took the daily image and booted it, and xrandr was saying the server only does 1.4
<dobey> on haswell i7
<tjaalton> the image is too old
<dobey> oh
<tjaalton> I'm talking it went in like 2h ago :)
<dobey> tomorrow should be good?
<tjaalton> yeah
<dobey> ah
<dobey> ok, i'll try again tomorrow
<tjaalton> hmm I'll sync x11-xserver-utils too so that xrandr can do 1.5
<dobey> because it's my understanding that i need 1.5 to get 60Hz 4K correctly with MST
<tjaalton> oh we have latest x11-xserver-utils already
<tjaalton> probably so
<tjaalton> i've never seen one
<dobey> well i know currently i just get two 1920x2160 screens that are ordered incorrectly by default, when i try to use MST
<dobey> on trusty with lts-wily kernel/xorg
<tjaalton> yep
<nacc> tjaalton: while you're around, i hit bug # 1500751 on my laptop at home over the weekend after updating to xenial; I had been running mainline (which did work) and had to use you workaround from c54 to be able to type my password into the cryptfs prompt at bootup with the stock kernels. I didn't see xenial mentioned specifically in that bug, though
<tjaalton> nacc: should be fixed now?
<nacc> tjaalton: hrm, i can try removing the workaround again ... "now" relative to when? I did the dist-upgrade over this past weekend
<tjaalton> nacc: well the bug apparently got fixed on sunday
<nacc> tjaalton: ah :) ... i'll try w/o the workaround then
<nacc> tjaalton: thanks, didn't see the update to the bug, my fault
<tjaalton> nw
<slangasek> nacc: right, so fixing gosa for php-imagick means it's now uninstallable when updating php7.0, due to the drops of php-mcrypt and php-imap, both of which it depends on
<slangasek> nacc: so that's critical path now :)
<nacc> slangasek: yep, i sent an e-mail last night about it?
<nacc> slangasek: but yeah, i'd like to get that fixed asap, i'm  happy to try my approach, but didn't want to do something that doesn't make sense
<nacc> slangasek: i'm not even sure my suggestion is very good, but it seems like a way forward where the sources *should* be easy to keep in sync
<nacc> slangasek: is it feasible to just have two src packages that are identical, one living in univers and one living in main? i know that's quite ugly, but if they had different control files, they'd generate their respective binaries correctly, and would stay in sync that way too (that's basically what i'm suggesting, except i'd pare down the universe one and make it depend on a binary pkg from the main
<nacc> one)
<xnox> nacc, see boost1.54 and boost-mpi-source1.54 for example.
<nacc> xnox: thanks, will look!
<nacc> Pharaoh_Atem: ping
<Pharaoh_Atem> nacc: pong
<nacc> Pharaoh_Atem: can you check something for me, i think php7.0-dev has a bad symlink, specifically for /usr/lib/php/20151012/build/ltmain.sh
<nacc> Pharaoh_Atem: it seems relevant to LP#359062
<nacc> err, LP #359062
<ubottu> Launchpad bug 359062 in php5 (Ubuntu) "bad symlink or missing package in php5-dev with libtool.m4" [Undecided,Invalid] https://launchpad.net/bugs/359062
<nacc> i wonder if the same change got dropped in php7
<nacc> slangasek: fyi, looks like we're missing at least one more imagmageick backport ofr this test -- when i skipped the version checks, it fails on amd64 :) ... bisecting now
<Pharaoh_Atem> nacc: looks good here
<nacc> Pharaoh_Atem: oh, i wonder
<nacc> Pharaoh_Atem: ok, try install php5-dev as well (just to test)
<Pharaoh_Atem> it seems to properly reference /usr/share/libtool/build-aux/ltmain.sh
<nacc> Pharaoh_Atem: i wonder if the two packages conflict (which is fine for now)
<nacc> xnox: ok, those do seem like a good example to base off of! on first glance, they share an orig.tar.gz (with altered naming) and simply have different debian.tar.gz?
<xnox> nacc, and there is magic in debian/rules to generate the other one, based on the change of the name in the changelog.
<nacc> xnox: ah very cool ... ok, i'll d/l them and take a look
<nacc> xnox: really appreciate it!
<slangasek> nacc: having two source packages - it's feasible, there are certainly other examples of it in the archive; it's also annoying, but until we finalize the build-deps-in-universe change it's unavoidable
<nacc> slangasek: yep, but it seems better than doing what was done with php5 and having (potentially) 4 separate src packages that have to be kept in sync (or so it seems to me)
<slangasek> nacc: sure
<nacc> slangasek: but you're the long term bd-in-universe is the "right" solution
<nacc> slangasek: i'll work on getting something to you by EOD
<kgunn> stgraber: you about? i feel like i'm missing something...
<kgunn> https://pastebin.canonical.com/151393/
<kgunn> i've got a local container, just trying to grab a file off of it...
<stgraber> kgunn: is the path correct?
<stgraber> kgunn: looks like we return this very confusing error when the path doesn't exist
<kgunn> double checking...
<kgunn> hmmm...i could pull hosts like the example
<kgunn> stgraber: permissions?
<kgunn> maybe
<stgraber> it's done as root, so unlikely
<stgraber> kgunn: lxc exec xen -- ls -lh /home/ubuntu/mir-server-snap/mir-client_0.21_amd64.snap
<kgunn> :) right was just doing
<kgunn> sort of
<kgunn> stgraber: well i feel sorry for disturbing you....i think it was perms on my host side
<kgunn> copied fine using .
<kgunn> into my working dir
<stgraber> ah, interesting
<stgraber> anyway, our error reporting for file pull/push really sucks... there are reasons for it sucking but we should try harder :)
<stgraber> (basically we need to fork a tiny C program into the container and then send stuff through fds so the Go daemon isn't the one actually getting the errors)
<kgunn> well thanks...
<kgunn> sorry for pestering
<matv1> can someone please confirm that I can just use relative paths for an image file inside a strictly qml/js (using qmake) app?
<matv1> or do I have to use recources system?
<matv1> it seems the most trivial of things but its about to do my head in :(
<dobey> matv1: you probably need full path URIs for file:///
<dobey> matv1: also, seems like a question for #ubuntu-app-devel
<matv1> ah sorry I seem to be in trouble with my locations in more ways then one :)
<matv1> dobey thanks I will try it
<nacc> Pharaoh_Atem: i think it's a php bug now ... cf my (just posted) update to the pcre bug
<nacc> Pharaoh_Atem: the twig failures
<Pharaoh_Atem> nacc: yeah, I saw
<Pharaoh_Atem> but have you updated the php bug with your conclusions?
<Pharaoh_Atem> or are we just going to kill pcre jit for php7?
<nacc> Pharaoh_Atem: just did
<bdmurray> cyphermox: any ideas about bug 1553870?
<ubottu> bug 1553870 in ubuntu-release-upgrader (Ubuntu) "apt sources contain "True" entries after upgrade to xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1553870
<nacc> slangasek: fyi, i've got a fixed version of fusiondirectory that does update the path (and a ton of string references :/) to php7 naming. Building it now and will send an updated debdiff in the same bug
#ubuntu-devel 2016-03-09
<lfaraone> I applied for PPU for python-django in December 2015 <https://lists.ubuntu.com/archives/devel-permissions/2015-December/000884.html>, pinged again in <https://lists.ubuntu.com/archives/devel-permissions/2016-February/000900.html> â is there a better place to make that request?
 * lfaraone waves at bdmurray , Laney :)
 * Unit193 waves back, then notices wasn't being waved at. >_>
<sarnold> lfaraone: you may need to wait a bit.. https://launchpad.net/~developer-membership-board/+members
<sarnold> (at least I think they're the ones who approve those things)
<lfaraone> sarnold: ah, seat shuffle / lame duckedness.
<hallyn> Hi - so is there a way to tell launchpad "build lp:package from the current xenial package" ?
<sarnold> lfaraone: well, maybe it'll get easier in 22 hours? dunno if quorum could then be satisfied if either infi nity or cyphe rmox alone show up? :)
<sarnold> hallyn: does backportpackage(1) do what you want?
<hallyn> sarnold: I'm looking for a way to do it without having to upload the whole pkg
<hallyn> i.e. save my own bandwidth, since it's all already sitting there :)
<sarnold> hallyn: ah :) fire up a canonistack instance perhaps?
<hallyn> that's an idea - i don't like moving my keys around, but this could be worth it.
<hallyn> But mainly it seemed like this would be one of the two most common cases,
<hallyn> so just like github has a 'fork' button, i would think a 'create this from debian unstable' or 'create from xenial' would be a button
<hallyn> (debian unstable - actually clone the git tree if listed in control file)
<sarnold> hmm, maybe you can do that via launchpad recipes?
<hallyn> wgrant: hey, ^ do you know of a way to do that, tell launchpad : just turn the current xenial package into a git tree at lp:libvirt ?
<hallyn> sarnold: hm.  that's a thought.  i haven't used those in like 5 yrs, don't recall the details.
<hallyn> it's for building source pkgs right?
<sarnold> I think you can get binary builds out of it from (nearly?) arbitrary bzr and git trees
<wgrant> hallyn: How would one turn a package into an upstream VCS repo?
<sarnold> I'm not sure about the "do a git clone for me" aspect of your question to wgrant though.. that sounds like something else :)
<wgrant> lp:foo can't be the Ubuntu package of foo.
<wgrant> It should be foo.
<wgrant> hallyn: Can you explain what you're trying to achieve?
<wgrant> "have a lp:libvirt with some contents from somewhere" isn't really an end goal.
<hallyn> wgrant: I want to be albe to start stashing (i.e. collaborating) changes for next libvirt release at lp:libvirt
<hallyn> so I disagree - I can tweak the branches as I like later on, but I want to populate lp:libvirt with either the xenial pkg source, or the debian git tree contents
<hallyn> when you say "lp:foo can't be the Ubuntu package of foo" - is that saying that there are conventions about hte 'master' branch, that it should be upstream?
<hallyn> it used to be "bzr branch lp:libvirt" would (modulo importer fragility) give me the devel release package contents
<hallyn> i'm looking for a git repo i can use to collaborate with others.  but i guess i'll just do github
<wgrant> hallyn: Do you mean lp:ubuntu/libvirt?
<wgrant> lp:libvirt and lp:ubuntu/libvirt are very different things.
<hallyn> yeah i probably mean lp:ubuntu/libvirt
<hallyn> it's been a few years :)
<hallyn> right, as an alias for lp:ubuntu/$release/libvirt
<wgrant> It is our intent to, given time, have dgit imports set up so trees are maintained automatically like the old days, except working because git rather than bzr.
<wgrant> At that point having an import button won't make sense, because it will already be done.
<wgrant> And it is unlikely that an import button is significantly cheaper to implement than full automatic imports.
<wgrant> To clarify, when you say "libvirt release" and "lp:libvirt" you mean "Ubuntu libvirt package release" and "lp:ubuntu/libvirt" or "lp:ubuntu/+source/libvirt"?
<hallyn> yeah, i did
<hallyn> so it's better fo rme to wait for that to happen, rather than push stuff there myself now?
<wgrant> It will be many months at least. I cannot advise waiting.
<hallyn> (that == dget imports)
<hallyn> well ,waiting would just mean setting something up on github
<infinity> rbasak: Not in the timezone you pinged me in.
<wgrant> libvirt's history isn't that huge; I'd suggest you construct the repository as you desire and push it up yourself.
<infinity> rbasak: I'm in BKK.
<wgrant> Let me know if you need assistance with any of that.
<hallyn> wgrant: and i should be able to just git push that?
<hallyn> wgrant: is there a url describing any branch name conventions which are expected to be used there?
<wgrant> hallyn: Not exactly, but you can push to eg. lp:~hallyn/ubuntu/+source/libvirt, and we can work out what should actually be blessed as lp:ubuntu/+source/libvirt later.
<hallyn> (I'm used to git-dpm, which doesn't quite fit I don't think)
<wgrant> hallyn: There aren't currently conventions.
<wgrant> Conventions will be imposed once we have dgit support for the whole archive.
<hallyn> ok, if i'm using ~hallyn then i can mes it up as i please, so no worries
<hallyn> thanks
 * hallyn goes to try
<hallyn> ruh roh error: pack-objects died of signal 13
<hallyn> wrong ur
<hallyn> l
<hallyn> thanks wgrant
<hallyn> sunova
<hallyn> apparently libvirt just has some files that are too bug and it upsets git push :)
<hallyn> git config http.postBuffer 52428800 appears to have helped
<hallyn> but not enough
<hallyn> yeah one packfile is 364M
<Mirv> pitti: the s390x tests seem eternally stalled at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-050/excuses.html
<Mirv> mostly the ubuntu-system-settings-online-account would be needed to pass
<danjared> so is there a modern way to determine why a package is held back that doesn't involve aptitude? :)
<cpaelzer> good morning
<pitti> Mirv: kicked
<pitti> stgraber: did you see the "realloc(): invalid next size" errors in lxc/i386?
<pitti> (same in lxd)
<stgraber> pitti: yep, working on it
<dholbach> good morning
<stgraber> pitti: and we have a fix, tagging a new upstream release and uploading before going to bed, it's kinda late here.
<rbasak> infinity: ah, Linaro Connect?
<rbasak> Is now any better?
<rbasak> smb: for bug 1547640, I just got a conffile prompt
<ubottu> bug 1547640 in squid3 (Ubuntu Xenial) "proxy tries ipv6 and gets 503 when no ipv6 routes" [High,In progress] https://launchpad.net/bugs/1547640
<rbasak> /etc/cron.daily/apt:
<rbasak> Package 'squid3' has conffile prompt and needs to be upgraded manually
<smb> rbasak, hm... sure you mean me
<rbasak> Sorry
<rbasak> smoser:
<rbasak> ^^
<smb> lamont, do we have news about mgilbert's work on bind9 and reviving something like the exports lib?
<rbasak> smoser: seems unnecessary because the change was in a comment :-/
<_ruben> question: is there still a chance that iputils 3:20150815-2 will land in 16.04?
<_ruben> ah, found bug #1547702
<ubottu> bug 1547702 in iputils (Ubuntu) "iputils-ping does not support IPv6 in ping command" [Undecided,Confirmed] https://launchpad.net/bugs/1547702
<flexiondotorg> infinity, seb128 darkxst Hello Pilots - If you get the time today I'd really appreciate it if you could look at some of my sponsoring requests :-)
<seb128> *shrug*
<seb128> it feels like one of those days I shouldn't have started IRC, I'm online for 5 days and already pinged on 3 channels
<seb128> flexiondotorg, I'm going to see what I can when/if I patch pilot today (I might move it to tomorrow)
<flexiondotorg> seb128, OK
<smb> seb128, "only" 3 ping within 5 days? ;)
<seb128> smb, lol, it was meant to be "5 minutes" ;-)
<smb> seb128, :) I guessed. But it was too good to let it pass.
<seb128> indeed!
<darkxst> flexiondotorg, I think I am going to do my shift tomorrow also, not sure I can even upload your packages though
<flexiondotorg> darkxst, OK
<infinity> rbasak: Yeah.
<ari-tczew> morning
<ari-tczew> don't we have a Feature Freeze already ?
<ari-tczew> since topic says "Archive: open", I'm being confused...
<lamont> smb: I'll be following up on that today - mon/tue were kinda special for me. :(
<smb> lamont, maybe you could make some update to bug 1551351 to have some plan outlined. I feel a certain unrest rising there. But neither did I want to throw anybody else in front of a bus...
<ubottu> bug 1551351 in isc-dhcp (Ubuntu Xenial) "dhclient does not renew leases" [High,Confirmed] https://launchpad.net/bugs/1551351
<lamont> smb: sure
<smb> lamont, much appreciated, thanks!
<lamont> done
<LocutusOfBorg> slow armhf and ppc64el autopkgtests?
<xnox> ari-tczew, archive is open, and we are in  feature freeze =)
<xnox> ari-tczew, i.e. one can upload bug-fixes and ui changes still.
<ari-tczew> xnox: should not we inform about FF in the topic?
<pitti> stgraber: http://images.linuxcontainers.org/images/ubuntu/xenial/amd64/default/ didn't get a new build for three weeks, what's up with that?
<pitti> stgraber: same for i386
<pitti> same for sid
<mterry> seb128, can you help golang-github-mvo5-goconfigparser through NEW?
<Mirv> pitti: hmm, any idea why https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-045/excuses.html hasn't been updated since the morning, or will I need to ping robert about that?
<Mirv> other silo excuses pages have been updating from what I can see
<pitti> Mirv: that'd be Robert indeed
<smoser> rbasak, ? not sure what you were saying above.
<Mirv> pitti: thanks
<caribou> I'm about to upload mstflint4 in Universe for Trusty, and Wily which is the mstflint version that is in Xenial
<caribou> should I add a Replaces: to the current Xenial package so it upgrades correctly (sorry first time I do that kind of stuff) ?
<infinity> caribou: mstflint in xenial should Conflicts/Replaces mstflint4 at the very least.  If you want a smoother upgrade, you should produce an mtsflint4 transitional package (in Section: oldlibs) that Depends: mstflint, and make mstflint Breaks/Replaces mstflint4 (<< 4.1.0+1.46.gb1cdaf7-1ubuntu1)
<infinity> caribou: Option A will upgrade correctly only if the user installs mstflint themselves (or something else pulls it in as a dep), option B will force the upgrade for all users of mstflint4.
<caribou> infinity: thanks! would you mind reviewing my changes once everything is ready ?
<caribou> infinity: I prefer to go with option B; looks cleaner to me
<infinity> caribou: I can review, yeahp.  Just 'debdiff | pastebinit -f diff' and toss me a URL.
<caribou> infinity: sure, I'll ping you once I'm done
<caribou> infinity: in the meantime, could you spare a minute to look at my changes to make the mstflint4  pkg ? http://paste.ubuntu.com/15334753/
<smoser> rbasak, oh. that does stink.
<caribou> infinity: better with the -f diff : http://paste.ubuntu.com/15334753/
<infinity> caribou: That's the same URL. ;P
<caribou> infinity: http://paste.ubuntu.com/15334788/
<infinity> caribou: I'm not laughing at the obvious sed screwup. ;)
<infinity> caribou: (hint: debian/watch)
<infinity> caribou: And the Breaks/Replaces should be Conflicts/Replaces
<infinity> caribou: And possibly a Provides too, in case anything depends on mstflint (which nothing in archive does, but maybe something third-party might)
<caribou> infinity: the upstream pristine tarball name doesn't change, I don't see the sed screwup but looks like I'm missing the obvious
<infinity> caribou: "version="
<infinity> caribou: That refers to the format of the watch file, not the package version.
<caribou> doh !
<caribou> infinity: ok, thanks for the review, I'll fix that up
<ilhami> hey guys
<ilhami> :D
<ilhami> http://www.meizu.com/en/products/pro5ubuntu/summary.html
<ilhami> preordered.
<pitti> Chipaca: can you please set a proper team email for https://launchpad.net/~ubuntu-push-hackers ?
<pitti> Chipaca: all of a sudden all ~ 240 indirect members now get spammed with MPs (and probably bugs too)
<ogra_> thats a new form of "spreading the word" :)
<seb128> mterry, I can have a look after that meeting
<mterry> seb128, sure thanks no rush
<caribou> infinity: here is the mstflint4 changes according to your suggestions : http://paste.ubuntu.com/15335296/
<caribou> infinity: and those are the changes to Xenial's mstflint package : http://paste.ubuntu.com/15335310/
<ilhami> GUYS!!!!!
<ilhami> share the excitement with me
<ogra_> ilhami, the guys in #ubuntu-touch will likely happily share ;)
<ilhami> ogra_: I would share it with them if I wasn't banned.
<seb128> mterry, mvo, golang-github-mvo5-goconfigparser ... shouldn't golang-github-mvo5-goconfigparser-dev C/R/P golang-goconfigparser-dev rather than R/B?
<mterry> seb128, R/B is enough for upgrades, right?  P is only needed if we want a nicer upgrade path?  But I think we only have one or so rdepends
<seb128> mterry, yeah, well it's a rename the provides can be useful no?
<seb128> in practice probably doesn't make a difference
<seb128> mterry, mvo, anyway, not a blocked, NEWed
<xnox> caribou, hey.
<mterry> seb128, thanks!
<seb128> yw!
<caribou> xnox: howdy!
<caribou> xnox: crashkernel on s390 I guess :)
<xnox> caribou, does it make sense that "when bootloader is updated" (~= update-grub), the relevant scripts check <kdump is enabled> and inject the appropriate "crashkernel=" cmdline?
<xnox> caribou, could you help me with <kdump is enabled> -> how should that be checked?
<caribou> xnox: this is historical afaik
<xnox> horum, i see that when kexec-tools is installed in injects "crashkernel=384M-:128M" into grub unconditionally.
<xnox> so should kexec-tools unconditionally inject that into zipl too?
<caribou> <kdump is enabled> relies on kdump-tools being installed which might not be the way to collect dumps on s390
<xnox> as far as I understand "historical" way to collect crashdump is to configure your zvm to dump the crashkernel onto separate drive outside of said machine.
<xnox> using like zdump stuff.
<caribou> xnox: no I meant historical in an ubuntu context
<xnox> caribou, why do we use "crashkernel=384M-:128M" instead of "crashkernel=auto"?
<caribou> crashkernel=auto is RH specific & relies on some kernel code to evaluate how much "auto" really means
<xnox> ack.
<caribou> xnox: we have an old discussion with arges that we should look into bringing that into our own kernels
<xnox> caribou, why shouldn't i have crashkernel= by default?
<nacc> xnox: caribou: they've tried upstreaming it several times, but it's never been accepted, iirc
<xnox> does it reduce my available RAM?
<caribou> xnox: on Debian, it isn't even setup & is up to the sysadmin to read the doc & add it into /etc/default/grub
<caribou> xnox: because it systematically reserves some memory and on small systems (an instances) it is a waste of memory
<nacc> xnox: it does, as it reserves some specific memory for storing the crashdump
<caribou> xnox: though I've been tossing the idea of making it enabled by default on Ubuntu
<nacc> also, i'll say by personal experience, crashkernel=auto has to be constantly adjusted
<nacc> and can still be wrong :/
<nacc> it just hides the values from the end-user/admin, which tbh is worse
<nacc> although the translated upstream equivalent is quite long :)
<caribou> the 128M value only came as a problem in Xenial because of the increase in initramfs size.
<caribou> I fixed kdump-tools so it now relies on a smaller initrd.img that is stored in /var/lib/kdump
<xnox> i wonder if it will work with huge kernel and huge initrd on s390x......
 * nacc admittedly speaking from a powerpc perspective
<caribou> xnox: I think it is worth a revisit in the ML; maybe we can add statements for bigger memories
<xnox> caribou, fyi KDUMP_KERNEL=/var/lib/kdump/vmlinuz does not exist for me.
<caribou> 128M on an AWS micro instance is 20% of the memory
<caribou> xnox: can you sudo kdump-config show | pastebinit ?
<xnox> caribou, https://pastebin.canonical.com/151457/
<xnox> caribou, i've just installed makedumpfile on s390x.
<xnox> caribou, note we don't have linux-crashdump on s390x.
<nacc> caribou: xnox: fwiw, i believe rh only uses kdump if memory >= 2G
<nacc> per https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html
<caribou> xnox: I need to get my hands on one of these to test it out
<smb> xnox, I missed the initial reasoning but why not using zdump?
<caribou> smb: I don't think there is any reason *not to* use it, just that the ubuntu kdump tooling is not prepared for that
<smb> caribou, ah right, might be a format that crash does not recognized I guess.
<xnox> smb, we can use zdump, but doesn't that need the same kernel parameter?
<xnox> (also)
<xnox> smb, the conversation started with https://bugs.launchpad.net/ubuntu/+source/zipl-installer/+bug/1555159
<ubottu> Error: Could not gather data from Launchpad for bug #1555159 (https://launchpad.net/bugs/1555159). The error has been logged
<xnox> smb, filed by partner.
<smb> xnox, it would not. zdump is basically a bootloader you write to a dedicated dump disk and you then ipl an lpar or zvm with special options that preserve cpu state and memory
<smb> xnox, and saying that it unlikely works with zKVM guests
<smb> But I do not know that for sure (did not have zKVM back then)
<cpaelzer> smb: the KVM combination is virsh dump / crash
<caribou> smb: I think that crash speaks s390, I saw some discussion about this on the ML recently
<cpaelzer> yes - crash can be used to load dumps, you "just" have to get it out in the right format
<smb> cpaelzer, Ah ok.
<cpaelzer> I think it was zgetdump -f elf -m /dump/disk
<smb> cpaelzer, I was not sure whether zdump would produce something that crash understands. Way back we used lcrash
<smb> not sure that is around at all, still
<cpaelzer> all normal crash these days
<cpaelzer> and depending which path to dump you have different ways to get it to crash
<cpaelzer> if you went in KVM virsh dump --memory-only ... you can use crash directly
<cpaelzer> if you went zipl -d (creating a dump disk), then you use zgetdump to get it "off" that disk
<smb> cpaelzer, So I guess the choice is to either sacrifice a spare disk or spare memory ... and probably kdump might be able to be automatically triggered, while using zdump is rather admin initiated
<cpaelzer> yes to first 60% of the statement
<cpaelzer> you can configure "boot dump disk on panic" and such
<smb> ah ok
<smb> Think I did not have that either then... or maybe only forgot
<infinity> caribou: +1 on the rename.  The xenial bit is a bit buggy.  The Conflict should be a versioned Breaks (with a conflict, the transitional package can't possibly work), and you have a typo (s/msflint2/msflint4/) in your changelog.
<caribou> infinity: thanks. I'll fix that up tomorrow & upload
<caribou> or maybe ping you one last time for review
<infinity> caribou: Also, as mslfint only exists on 5/7 arches, probably better to make msflint4 match, rather than having it arch:all.  No point bumping up the uninstallable count.
<caribou> true
<infinity> caribou: Oh, and that << version is wrong, it should be higher than the one in trusty,. :P
<infinity> caribou: So, probably (<< xenial-version)
<caribou> infinity: fine; I just picked what you told me to
<infinity> caribou: It was a copy/paste example (it was also based on my assuming the trusty version would be current-xenial~14.04.1)
<seb128> does anyone know where issues about http://changelogs.ubuntu.com/changelogs/binary being missing entries should be reported?
<seb128> e.g http://changelogs.ubuntu.com/changelogs/binary/f/firefox/45.0+build2-0ubuntu1
<seb128> http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_45.0+build2-0ubuntu1/changelog works
<seb128> unsure what's the difference
<seb128> mvo, ^ maybe you know?
<LocutusOfBorg> can anybody please rerun python-numpy python-dtcwt testsuite against 0.10.1+dfsg1-4?
<mvo> seb128: this is probably still generated from https://code.launchpad.net/~mvo/+junk/lp-changelogs-crawler
<seb128> mvo, k, I emailed ubuntu-devel@
<seb128> mvo, the binary url seems to miss updatges
<seb128> updates
<mvo> seb128: I don't even remember this path, so maybe something changed here
<seb128> mvo, well it work most of the time, it seems to miss some though
<seb128> mvo, e.g http://changelogs.ubuntu.com/changelogs/binary/f/firefox/45.0+build2-0ubuntu1
<seb128> mvo, where http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_45.0+build2-0ubuntu1/changelog works
<mvo> seb128: the log says "INFO:root:firefox 45.0+build2-0ubuntu1 in PENDING state"
<seb128> mvo, that update is 5 days old, so I gess something is stucked/buggy
<mvo> seb128: it sounds like it
<seb128> :-/
<mvo> yes :(
<seb128> mvo, sorry, I know you already have too much to do, I was not trying to dump that one on you as well
<seb128> do you know if i.s maintains that service?
<seb128> or is that a custom u-e job on a machine
<mvo> seb128: its running on changelogs.u.c as the changelogs user
<mvo> seb128: stgraber was doing fixes to it (2013)
<seb128> k
<seb128> maybe I can convince him to have a look to that issue ;-)
<seb128> mvo, thanks!
<mvo> seb128: I think he did the binary symlink logic too
<stgraber> I have flushed all of that from memory a long time ago :)
<nacc> Pharaoh_Atem: fyi, php fix does let twig pass its tests!
<bdmurray> seb128: I may have access changelogs
<bdmurray> seb128: to the server
<Pharaoh_Atem> nacc: wooo!!!!
<Pharaoh_Atem> nacc: so is it upstreamed yet?
<nacc> Pharaoh_Atem: nope, just updated the bug
<rharper> cyphermox: I've got a multipath-tools merge mostly done;  I'd appreciate a review and any extra testing: ppa:raharper/merges ;
<rharper> rbasak: smoser: could one of you git-import multipath-tools into ubuntu-server-dev repo on launchpad ?
<cyphermox> rharper: could you add a debdiff to the merge/ffe bug? I'll review it later
<rharper> cyphermox: sure! thanks
<nacc> rbasak: smoser: same for checksecurity, please
<smoser> rharper, will do.
<rharper> smoser: thanks!
<nacc> jgrimm: fyi, checksecurity realy hasn't received many updates in debian either (only 2 releases since utopic). Merge is easy/done, just need the usd tree updated and i can push it
<nacc> actually, i wonder -- checksecurity's merges drop all the recommends to suggests. I assume this is due to main v. universe (not documented). But some of the recommends are in main (at least in xenial). Would it make sense to reduce the delta (even if only marginally) and keep those as recommends?
<nacc> or is it better to have a nice clean patch that just moves them all?
<smoser> nacc, i would think that if the binary packages are in main, then moving only the ones *not* in main to suggests is better.
<smoser> even though its still the same number of lines, the delta is less.
<nacc> smoser: agreed, thanks!
<nacc> smoser: i think people may have been previously just pulling along hte delta because it was easiest :)
<nacc> smoser: let's say the package has a depends on fcron, which was previously dropped to suggests in earlier merges. But fcron is no longer in teh archive at all -- should i just remove it from the control file?
<nacc> rbasak: so this brings up an interesting (to me) question -- checksecurity's previous delta seems to be mostly robo-carried. Which is fine, but can be shrunk (and the changelog reasoning isn't always true, e.g. for fcron as just mentioned). How do I document that properly in the changelog? Should I say remaining changes ... (whatever is still there). then Dropped the fcron change. Then a new change for
<nacc> dropping fcron altogether?
<nacc> that is, should it read like: http://paste.ubuntu.com/15337111/
<chiluk> cyphermox:  any chance you can do the sru review for https://bugs.launchpad.net/ubuntu/trusty/+source/coreutils/+bug/1535349
<ubottu> Launchpad bug 1535349 in coreutils (Ubuntu Trusty) "`df /dev/sda1` no longer reports information for /dev/sda1" [Medium,In progress]
<nacc> or like this
<nacc> http://paste.ubuntu.com/15337118/
<nacc> rbasak: it seems like the former, since the delta is changing
<nacc> actually, this might be the clearest:
<nacc> http://paste.ubuntu.com/15337168/
<nacc> rbasak: --^
<nacc> jgrimm: fyi, looking at the chagnes in checksecurity, i don't think a FFe is needed. They are all bugfixes or non-functional changes to cleanup the control file fields
<jgrimm> nacc, excellent
<cjwatson> hallyn: if you're around, could you hop into #is on the internal server?  a recent change from you to libvirt seems to have made the arm64 builders go boom
<jgrimm> nacc, can you take a look at sg3-utils too? single ubuntu patch to it, so hopefully a quick/easy one to tackle
<nacc> jgrimm: sure
<nacc> smoser: --^ could you import sg3-utils as well, then
<jgrimm> nacc, thanks!
<smoser> nacc, sure. doing that for multipath-tools now and will work my way thorugh your list :)
<nacc> smoser: thanks!
<cjwatson> [6~
<smoser> rharper, https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/multipath-tools/+git/ is there now.
<rharper> smoser: thanks!
<nacc> cyphermox: looking at merging sg3-utils, had a couple of questions about the delta, if you could help me out
<cyphermox> nacc: I'm not sure it's that much worth your time tbh
<nacc> cyphermox: ok ... should i look at syncing? it seems like a lot of the delta was for pulling in a version that doesn't exist (and has now been superseded in debian)?
<cyphermox> what?
<nacc> the chagnelog mentions moving to 1.4.0 from Debian ( which I think was meant to meant 1.40). But that was never released or tagged in Debian's git tree that i can find
<nacc> and they are on 1.41 now
<cyphermox> sg3 should be fine as it is right now, I think -- all of what is in 1.41-1 is already in 1.40-0ubuntu1
<nacc> cyphermox: oh i see
<nacc> cyphermox: ok, thanks!
<nacc> jgrimm: --^ ?
<jgrimm> nacc, cyphermox: cool can we drop the patch and sync?
<cyphermox> no
<cyphermox> well, doesn't seem like it
<cyphermox> scratch that, yes I suppose it can be synced
<jgrimm> nice. tx
<cyphermox> maybe pick 1.42?
<nacc> cyphermox: i think there are post-1.41 chagnes that need to be pulled in still, then, right? for sg3-udeb?
<nacc> cyphermox: yeah
<jgrimm> nacc, cyphermox: that works.
<nacc> jgrimm: 1.41-2 is not released yet, but i think that will mean we can sync
<nacc> cyphermox: --^ i assume you meant that, unless there's going to be a 1.42 instead
<cyphermox> yes, that's what I meant
<nacc> cyphermox: thanks!
<nacc> jgrimm: i'll keep my eyes out for it
<jgrimm> nacc, tx.
<nacc> Pharaoh_Atem: why does prepare-fpm-pools.mk in php7.0 have a reference to php5?
<Pharaoh_Atem> I'm not sure
<Pharaoh_Atem> I didn't write that
<nacc> ok :)
<nacc> Pharaoh_Atem: maybe worth cleaning up
<Pharaoh_Atem> it should probably be changed to actually pick up the correct version :)
<Pharaoh_Atem> yeah, I've not been pulling the pkg-php stuff from alioth lately
<nacc> slangasek: fyi, upstream php has now taken a fix for the twig testsuite, so we can drop our workaround; should i wait til we've packaged the corresponding release before sending an update to twig to drop that delta?
<nacc> slangasek: also, looking at excuses, i think we're in a bit of a loop? php-defaults is waiting on php7.0 which is waiting on php-horde-ansel which failed due to the old version of php-pear which is waiting on php-defaults, as well?
<marcoceppi> is it okay to ask a debian packaging question here?
<mwhudson> marcoceppi: no, that would be terrible!
<mwhudson> marcoceppi: :-)
<marcoceppi> mwhudson: okay, I'll go find another room then ;)
<rharper> ask away
<marcoceppi> I have a python program I'm packaging. One of it's dependencies, as listed in the setup.py is path.py. This is packaged in Xenial as python-path but it keeps trying to install python-path.py how do I tell debian python packaging helper that python-path is what it needs?
<rharper> if we don;t like it , we won't answer
<mwhudson> marcoceppi: there is #ubuntu-packaging but i'm not sure that's an idea that ever took off (a lot fewer people anyway)
<marcoceppi> mwhudson: I'm in it, and I asked there already ;)
<mwhudson> marcoceppi: haha
<marcoceppi> 340 vs 45 audience though, figured I try my luck here
<mwhudson> marcoceppi: #debian-mentors on oftc is fairly repsonsive too
<mwhudson> unfortunately i know very little about packaging python
<bdmurray> Anybody know where /etc/apt/apt.conf.d/20auto-upgrades comes from?
<marcoceppi> mwhudson: thanks, I'll ask there
<nacc> bdmurray: unattended-upgrades
<bdmurray> nacc: thanks
<xnox> bdmurray, installer..... ?!
<xnox> one get's to choose what to do during d-i installation....
<mwhudson> marcoceppi: you seem to be getting a very debian sort of advice :(
<rbasak> nacc: yeah I'd do the former. I think that as long as it's clear what happened, the exact form doesn't matter. To me the former is the clearer of the two.
<rbasak> nacc: you can always go more verbose if unsure.
<marcoceppi> mwhudson: well it got me my answer, so I'm happy
<mwhudson> marcoceppi: cool
<marcoceppi> mwhudson: at the end of the day, the package I need is in Xenial, so I'm going to go with that
<rbasak> smoser: your imports look good, thanks.
<nacc> rbasak: thanks ... i figure that eventually it'll get cleaned up anyways, this one is fairly obvious
<rbasak> nacc: sure, and having a git tree available certainly makes it clearer too :)
<marcoceppi> mwhudson: "path.py python-path (>= 8.1), python-path (<< 9.0)" was all I needed, go figure
<Pharaoh_Atem> I hope one day we have a git mirror of the bzr stuff in lp :/
<Pharaoh_Atem> bzr is slooow
<nacc> rbasak: right, that's why i think the last one is best for this merge, as it matches the commits idetnically
<nacc> and then the future merge will just collapse them
<nacc> rbasak: but either way, the git tree makes it obvious
<rbasak> nacc: completely agree :)
<nacc> slangasek: found the msising imagemagick commit that fixes the test :) https://github.com/ImageMagick/ImageMagick/commit/35a7f566c985215980c8beaa45af6652a89d493c
<nacc> slangasek: will send a new debdiff, w/ and update to the php-imagick test
<shoutme> pitti: hey, nfs-common (a build-dep of libvirt) won't instal lin a container bc gssd fails to run.
#ubuntu-devel 2016-03-10
<shoutme> pitti: should gssd.service just have a ConditionVirtualization=!container  added?
<shoutme> maybe we should just allow the rpc mounts...
<shoutme> but adding that to run-rpc_pipefs.service does work
<nacc> slangasek: apologies for the delay, i think i've got the split main/universe build for php7.0 working with just a one-variable chagne between the two src packages ... build & testing now, will let you know
<nacc> jgrimm: checksecurity merge request sent
<nacc> smoser: thanks for your help!
<jgrimm> nacc: cool, thanks!
<stgraber> Pici: found the issue with the jenkins image importer, fixed now, it's processing its backlog which should take quite a few hours (about 200 images to download, unpack, update, repack, sign, ...)
<stgraber> pitti: ^
<stgraber> Pici: sorry, bad tab completion :)
<pitti> stgraber: yay, thanks for fixing the image builds
<pitti> Good morning
<darkxst> can someone nuke this from the sponsorship queue https://code.launchpad.net/~maozhou/ubuntu/utopic/tomboy/bug-12345/+merge/283581
<darkxst> it was just someone playing around with merges by the looks of it
<pitti> darkxst: set to "rejected", that should do
<darkxst> pitti, thanks!
<darkxst> @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: darkxst
* wilhelm.freenode.net 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:
<pitti> yofel, debfx: both our telepathy-qt and telepathy-qt5 packages are wildly out of date, use gstreamer 0.10 etc., and it seems the reason for the split is long gone: Debian's telepathy-qt builds both qt 4 and qt5 packages
<pitti> can we just sync/merge this?
<pitti> yofel, debfx: see bug 1538772, keeping notes there
<ubottu> bug 1538772 in telepathy-qt5 (Ubuntu) "Stop build-depending on libfarstream-0.1-dev" [Undecided,Confirmed] https://launchpad.net/bugs/1538772
<pitti> yofel, debfx: I put a merged test package into my PPA, some testing would be great
<cpaelzer> good morning
<darkxst> anyone able to add gitg to desktop-extra packageset (I am sure it was meant to be done already, but apparently not)
<tjaalton> how come https://launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu shows the package is in universe when apt-cache policy shows the binary is in main?
<pitti>  xserver-xorg-video-amdgpu     | 1.0.1-1build2 | xenial          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti>  xserver-xorg-video-amdgpu     | 1.0.1-1build2 | xenial/universe | source
<pitti>  xserver-xorg-video-amdgpu-dbg | 1.0.1-1build2 | xenial/universe | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti> tjaalton: wrong overrides; where is this supposed to be?
<tjaalton> main
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1543659
<ubottu> Launchpad bug 1543659 in xserver-xorg-video-amdgpu (Ubuntu) "MIR: xserver-xorg-video-amdgpu" [High,Fix released]
<pitti> tjaalton: ok, fixed
<tjaalton> thanks!
<dax> tjaalton: been fielding support questions about fglrx recently. checking i'm reading right: no more fglrx in xenial onwards, right?
<tjaalton> dax: right
<tjaalton> amd finally confirmed it in public
<dax> thanks (and thanks for getting rid of it, though it'll make #ubuntu fun for a cycle or two i'm glad it's gone)
<tjaalton> there's going to be a userspace blob at some point, but it's only for the amdgpu stack
<dax> *nod*
<dholbach> good morning
<dax> i've been using radeon for ages and have been reading about amdgpu. just wasn't sure if it was yet another temporary delay in xorg compat or if it was permanent
<tjaalton> http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/857070-ubuntu-is-deprecating-fglrx-catalyst-in-16-04-lts/page6?_=1457549209785
<tjaalton> comments by bridgman and twriter
<tjaalton> I emailed tim yesterday and begged that they'd make it public :)
<tjaalton> there's probably going to be a more formal announcement too
<tjaalton> now if only it'd be ok to build a fully featured mesa and then just put some binaries in universe that'd be cool (vaapi, opencl..), but main/universe split makes it impossible
<pitti> wgrant: hey William, how are you?
<pitti> wgrant: I did a boo-boo with process-removals (had some 'y's in the input buffer)
<pitti> wgrant: can I un-remove a package from xenial, or do I need to reupload/rebuild?
<wgrant> pitti: Morning.
<wgrant> pitti: You can use copy-package to revive it.
<pitti> wgrant: copy from where then?
<wgrant> pitti: copy-package --from-suite=xenial --to-suite=xenial -e 1.2.3-4 -b --auto-approve --force-same-destination somepackage
<pitti> wgrant: hah, lol; thanks
<wgrant> The -e picks a version other than the current one.
<wgrant> So it doesn't matter if it's published or not.
<pitti> yofel, debfx: qtmobility got removed in Debian, only rdepends in Ubuntu is artikulate; is this still something we want to keep?
<pitti> (it also uses the obsolete gstreamer0.10)
<debfx> pitti: qtmobility-dev likely just needs to be dropped from build-deps
<yofel> ^
<debfx> where does it use gstreamer0.10? I only see a dep on libqt5gstreamer-1.0-0
<pitti> Comment: (From Debian) ROM; will not get ported to GST 1.0, superseded by Qt5; Debian bug #802642
<ubottu> Debian bug 802642 in ftp.debian.org "RM: qtmobility -- ROM; will not get ported to GST 1.0, superseded by Qt5" [Normal,Open] http://bugs.debian.org/802642
<pitti> that's what the Debian removal bug says
<pitti> and it also seems generally obsolete
<pitti> debfx: libqtmultimediakit1 depends on libgstreamer0.10-0
<debfx> right, so applying http://anonscm.debian.org/cgit/pkg-kde/applications/artikulate.git/commit/?id=609f5b1 and killing qtmobility is the solution
<pitti> debfx: ah, thanks; so good to remove?
<debfx> qtmobility? sure. would be nice if someone could fix artikulate before.
<darkxst> @pilot out
<pitti> debfx: uploaded/removed
<pitti> xnox: hey! do you have some time to look at the s390x test failures of upstart?
<jamespage> please could an archive admin promote python-pika-pool to main? MIR bug 1552827 approved - the old version oslo.messaging in the release pocket is causing test failures right now for openstack testing
<ubottu> bug 1552827 in python-pika-pool (Ubuntu) "[MIR][FFE] Please sync python-pika-pool (0.1.3-1) from Debian (unstable)" [Undecided,Fix committed] https://launchpad.net/bugs/1552827
<pitti> jamespage: it's not on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- you need to make something in main depend on it
<pitti> otherwise the next AA will demote it back
<jamespage> pitti, python-oslo.messaging is depwaiting on it
<jamespage> letme check again
<pitti> jamespage: ah sorry, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<jamespage> pitti, yup
<pitti> promoted
<jamespage> pitti, I'll also need a binary only of python3-pika please
<jamespage> source already in main
<pitti> jamespage: I did all the ones on the above list, including that
<jamespage> pitti, thankyou
<pitti> nacc: php5.6 got removed in Debian, do we want to follow suit? I assume yes as you're heading for 7.0, but want to confirm
<pitti> nacc: well, I remove it for now, our only change was an FTBFS fix; I can bring it back if necessary
<rbasak> nacc won't be up for a while. I know the plan is to remove 5.6. I didn't know what stage nacc was at for that though.
<rbasak> Presumably all the reverse deps are gone now?
<pitti> * php-redis                     (for php5.6-dev)
<pitti> * php5.6-json                   (for php5.6-dev)
<pitti> rbasak: php5.6-json was also removed (I just did that in Ubuntu)
<pitti> rbasak: and php-redis needs a rebuild against php7, I just synced the new Debian package
<pitti> rbasak: i. e. yes,  all gone
<rbasak> Not sure about php-redis. php5.6-json is 5.6-specific. 7.0 has a replacement json that doesn't need a separate source package IIRC.
<pitti> I also removed a whole bunch of obsolete php-* stuff (via debian removals), should help a bit
<pitti> (I also synced dh-php and php-igbinary, as php-redis needs those)
<pitti> Unit193: do you still care about dvdstyler? it's the only thing which still holds the obsolete wxsvg in Ubuntu (got removed in Debian bug 813151)
<ubottu> Debian bug 813151 in ftp.debian.org "RM: wxsvg -- RoM; unmaintained, library without rev deps" [Normal,Open] http://bugs.debian.org/813151
<Unit193> I did the last upload because it didn't function at all, afact there's no new version that ports from wxsvg.
<pitti> Unit193: right, my question was in the direction of "is dvdstyler obsolete and should be removed?" or is there still some upstream for it
<Unit193> pitti: Ah!  Well they did just release a new version in Jan, but I don't actually know much more than that, never used it myself.  Sorry.
 * pitti tries to find some ubuntustudio folks
<pitti> zequence: ^ hey, how are you? do you know about dvddstyler? ^
<pitti> juliank: apparently some amd64-ism crept into apt's test suite? tests now fail on anything except amd64
<pitti> dpkg: error processing archive /tmp/tmp.tKhfFn1igl/aptarchive/pool/pkgb_1_amd64.deb (--unpack):
<pitti>  package architecture (amd64) does not match system (i386)
<juliank> pitti: Yes, I'm aware of that and forwarded it yesterday to DonKult
<pitti> juliank: ah, danke
<juliank> pitti: In the meantime, ignoring them is the way to go. (Problem being that while we set APT's architecture, we do not configure dpkg's architecture, but install packages, which fails)
<juliank> pitti: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e457c94
<pitti> juliank: yay you, danke
<juliank> bb
<juliank> oops
<juliank> i386 also failed the (flaky) download progress test again
<xnox> pitti, upstart is not used on s390x at all =)
<xnox> it's only used in desktop sessions, and there are no desktops on s390x.
<pitti> xnox: oh, so it's not even installed by default?
<pitti> xnox: indeed, only rdepends on my system is unity-greeter (ugh, there should be some more for sure..)
<pitti> xnox: you mean we could/should remove the s390x binaries?
<xnox> pitti, i don't think we will like an arch skew, nor the build depends skew (there are things that depend on libupstart et.al.)
<xnox> but it's definitely not supported =)
<pitti> well, it's ftbfs on s390x; we could also disable the tests on s390x
<xnox> i can look at the test failures out of interest.
<pitti> xnox: oh, I don't have libupstart1 installed
<xnox> however, upstart is a good kernel tester.
<pitti> only libupstart-dev depends on it
<xnox> horum. there should have been deps in app-launchers and things, unless they have switched to dbus direct.
<smoser> pitti, around? i've got some systemd networking questions.
<smoser> https://public.etherpad-mozilla.org/p/cloud-init-networking has some background.
<smoser> see description around line 39 there.
<zequence> pitti: Seems my assistance was not needed :)
<pitti> zequence: why? there was no other answer about this so far (nor an upload)
<pitti> smoser: (be with you in a sec)
<smoser> k. thanks.
<pitti> zequence: i. e. it's still "do we want to keep and update dvdstyler or remove it"
<zequence> pitti: Oh, I thought someone was on it
<zequence> Ah, right. Yes, I'll check with Len Ovens, who is the one in our team who is most informed on that package
<flexiondotorg> smb, ogasawara, seb128 Hello Pilots - If you could take a look at my sponsoring requests during your pilot sessions today I'd really appreciate it :-)
<pitti> smoser: these steps seem fine to me; let me see where cloud-init-local hooks in right now, i. e. that it's a proper place for this
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/systemd/cloud-init-local.service
<zequence> pitti: I'll get back to you about the package within a day or so. Just double checking with Len first.
<pitti> smoser: ah, was just doing "systemctl cat" on a cloud instance
<muktupavels> flexiondotorg, did you test compiz? why did not you update your branch for review?
<pitti> zequence: great, thanks a lot for your efforts
<flexiondotorg> muktupavels, Because I work on this stuff in my spare time and my time is limited :-(
<flexiondotorg> muktupavels, It is 2nd on my list though.
<smoser> pitti, thanks for systemctl cat. did not know.
<pitti> smoser: so, cloud-init is after=local-fs.target, but at first sight I don't see a strict enough Before= that would cause networking stuff to wait?
<smoser> yeah. at the moment networking is not blocked at all.
<pitti> smoser: "systemctl show -p After cloud-init-local" is also quite useful
<pitti> smoser: as that shows you the properties "all combined"
<smoser> cloud-init-local needs filesystems (and yes, /usr)
<pitti> i. e. if some other unit bar.foo does Before=foo", then showing foo.service will show After=bar
<pitti> smoser: can/should we just redefine cloud-init-local to block bringup of network, or is there stuff happening there that already needs network?
<pitti> smoser: (if so, it would be wrong as it doesn't depend on networking, but still asking)
<smoser> no. it should not need network
<smoser> it looks at local sources of information such as attached disks or stuff in the filesystem
<smoser> or as described there to add 'ip=' flag
<flexiondotorg> muktupavels, I see you've got a merge proposal in.
<pitti> smoser: btw, this might not run as early as you think, as it doesn't have DefaultDependencies=no
<flexiondotorg> muktupavels, What help do you require from me to progress this?
<pitti> smoser: in old SysV terms, this runs in rc2, not in rcS (which you'd get with DefaultDeps=no)
<muktupavels> flexiondotorg, what merge proposal?
<flexiondotorg> https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-marco-gsettings/+merge/287820
<muktupavels> flexiondotorg, just merge it in your branch and test it. I pushed that only as example.
<smoser> yeah, goal is "as early as i can pallet". i think i'm probably ok. . i need /var/lib/cloud, /usr/bin/cloud-init really want /run .
<pitti> smoser: /run is always there, that's no problem
<pitti> smoser: do you support craziness like /var on NFS for cloud-init?
<pitti> (as that would be a circular dependency then)
<pitti> for c-i-local.service
<smoser> at this point i dont think so.
<smoser> i think if someone really wanted such a thing, then we might try to get there, but it wouldnt work right now.
<pitti> smoser: so, I left some notes in the pad
<smoser> pitti, thanks. wrt seriallized boot, you may be interested in the generator i added, which means you can completely disable cloud-init (well,. other than the generator running)
<pitti> smoser: line 70 â is that a systemd generator? or some other kind? (as these run even earlier)
<smoser> yeah, the generator is what allows you to disable cloud-init entirely
<smoser> i'd also like at some point it to be able to change cloud-init to only run in a way that is guaranteed to not foobar your ENI
 * pitti yays lots of shell in early boot :)
<pitti> smoser: any chance to at least drop the shell parsing of /proc/cmdline?
<pitti> you can add ConditionKernelCommandLine= to any unit to run (or not run) it for certain kernel command line options
<pitti> smoser: is =enabled and =disabled already released API? (most other kernel options use =1 or =0, or no value at all)
<smoser> pitti, i'm not opposed to changing =enabled or =disabled. to =1 or =0, but one seems less magic.
<smoser> the kernel command line parsing also supports reading the environment variable which could be set in lxd (right now lxc does not mask /proc/cmdline)
<smoser> i dont think performance is likely an issue in reading proc cmdline. the logging in that script probably is much more a performance issue
<smoser> actually, the one fork i make (systemd-detect-virt) is probably 90% of the time for that functionality
<pitti> smoser: ConditionKernelCommandLine= actually does just that
<pitti> smoser: if it's booting on a real kernel, it parses /proc/cmdline, otherwise it takes the argv of pid1
<pitti> i. e. lxc's flavor of a "kernel"(ish) command line
<pitti> and there's ConditionVirtualization= which also avoids the fork
<pitti> (but I think you don't actually need that
<flexiondotorg> muktupavels, OK, will do.
<pitti> smoser: anyway, that's quibbling over less code/optimizing etc; I guess the important bit here is the Before=network-pre.target (and moving earlier into the boot) of c-i-local?
<smoser> yeah.
<pitti> smoser: where does this $KERNEL_CMDLINE thing come from?
<smoser> it would allow you to set that in lxc's pid1
<smoser> i dont know that the argv of pid1 would be sufficient or not
<smoser> can i run '/sbin/init cloudinit=1' and systemd not be bothered by that ?
<smoser> KERNEL_CMDLINE is not standardized in any way. i picked an environment variable name. if there is a more appropriate one, good with that.
<pitti> smoser: well, "bothered", that's how every init is called; it will of course pick out stuff like systemd.log-level or so, but it ignores unknown arguments, yes
<pitti> (or quiet/debug/emergency)
<pitti> so you can e. g. do sudo lxc-start -n adt-wily /sbin/init rescue -F
<pitti> starting a container or a kernel isn't much different wrt. kernel command line parsing really
<pitti> for clarity, the -F belongs to lxc-start, so like: sudo lxc-start -F -n adt-wily /sbin/init debug cloudinit=1
<pitti> systemd will recognize the "debug" as somethign it knows, and just ignore the cloudinit=
<smoser> ok. i'll consider that, adn the systemd conditions in the generator too
<smoser> 2 things i'd like generally...
<pitti> smoser: generators don't have  conditions (as they are not units), they always run
<smoser> i'd like to be able to read "is this a container" (systemd-detect-virt) without  a fork
<pitti> well, you can programatically check for stuff of course
<pitti> i. e. my point is, I believe you don't need the generator at all
<smoser> i'd like to be able to read the cmdline without a fork too (reading /proc/1/cmdline and /proc/1/environ are null terminated. easy for anything but shell)
<pitti> I think this boils down to ConditionKernelCommandLine=!cloud-init=disabled
<smoser> maybe, yeah.
<pitti> and you don't really need the dynamic enaling then, as the condition will already make cloud-init*.service a no-op if disabled
<pitti> and the detect-virt goes away as ConditionKernelCommandLine= DTRT for both "real" kernels and container pid 1's
<smoser> and ConditionPathExists!
<smoser> pitti, oh. the other thing i thouht i got from the generator.
<smoser> was that i have no bottlnecks in boot
<smoser> ie, one thing runs and then if disabled, the others do not run
<smoser> rather than having the bottleneck come down to cloud-init-local and then checking for that file
<pitti> well, they don't actually fork/run anything
<pitti> "they" -> Condition*
<smoser> no. but they force a bottleneck
<smoser> ie, if cloud-init-local blocks networkign coming up, then there is a bottleneck at boot down to that one job
<smoser> and then another at the point where i want cloud-init to run
<pitti> ah, you'd make network-pre.target run after local-fs.target, yes
<smoser> where with the generator i thought i incur the single cost of the generator and if disabled, then cloud-init has *no* affect on boot
<pitti> which is not really a biggie as everything that actually touches network config also needs After=local-fs.target
<smoser> well, then i'm free to do what ever silly things i want to do to boot.
<pitti> smoser: well, cloud-init-local.service really doesn't do much serialization (other than network-pre.target after local-fs.target); I guess the stating and symlinking and parsing that you do there is probably a dozen times heavier :)
<smoser> but i think its probably really a very small optimization.
<smoser> also cloud-init.service forces some bottlenecks.
<pitti> for sshd.service etc.
<smoser> its fine. i think this is mostly in the terms of "small" then. i was more concerned that cloud-init's presense on disk had negative affects on boot when it wasn't utilized.
<smoser> i'd like for peple to not think 'cloud-init sucks, purge it'
<smoser> but rather cloud-init could be useful, i'll just disable it.
<smoser> you've convinced me its a small thing, and i'm not opposed to looking into your path for sure.
<pitti> smoser: so cloud-init.service serializing ssh.service after network-online.target is the main serialization that I see
<smoser> (and i have another email to you about ssh.service and pollinate)
<pitti> smoser: for that a generator might make sense
<smoser> i do want cloud-init.service to generally block everything it can
<smoser> for just about all of boot to serialize on it (and cloud-confnig.service) so that they can affect as much of boot as possible.
<smoser> pitti, that make sense? generally speaking i *want* to serialize boot. so that users can provide user-data that will run "as soon as networking is up" and affect other parts of boot.
<smoser> unfortunately, it seems that systemd is not as dynamic as upstart was in that regard
<smoser> they can't just drop new units in and have them consumed via inotify
<pitti> smoser: sure; you can hook into network-online.target to block that (and everything that waits on it)
<smoser> how can i hook into it ?
<pitti> right, you need to enable new units
<pitti> smoser: Before=network-online.target
<pitti> (or whichever other target you want to "block")
<smoser> and that will run when networking is up
<smoser> but block anything else that would need it ?
<pitti> of course you can't then simultaneously have After=network-online.target as it does rigth now
<pitti> you could add an After=networking.service (for ifupdown), if you don't care about other methods
<smoser> so cloud-init.service will need to use the configured networking to go looking for a datasource
<pitti> then you'd have networking.service -> cloud-init -> network-online.target -> everything that depends on that
<smoser> so yeah, thats what i want. but that is only accomplishable on ubuntu ?
<pitti> but of course not all services depend on that, so if you really want to affect *all* services you can only run a generator
<pitti> (but then have literally no assumptions)
<xnox> .... and dhcp request sent with "wrong" hostname....
<smoser> xnox, well, you'll be happy to know that on azure, they bounce the dhcp interface so that it does it with the right one
<pitti> smoser: network-online (and pretty much all other targets) are cross-distro; *.service are often distro specific, e. g. networking.service is "ifupdown"
<xnox> smoser, excellent. I guess i just need s390x on azure then =)
<pitti> smoser: so indeed  if you run on a distro that doesn't have ifupdown, you can't use this (but they your network config bit wouldn't work in teh first place -- you probably want to ship a networkd config or somethign such)
<smoser> pitti, yeah. well, a cross distro blocking "network is up" event is what i'm after.
<pitti> smoser: that's network-online.target, pretty much
<smoser> yeah. other than the blockign part :)
<pitti> smoser: but I meant, a lot of services don't wait for that, but already start before
<smoser> pitti, you've been so very helpful, thank you.
<xnox> there is a generic event for "network is available" network-online.target, but things that provide network block that, and don't create an alias...
<pitti> say, postgres or ssh
<pitti> smoser: the blocking is your decision (adding a Before=n-o.t)
<xnox> it could be networkd, networkmanager, ifupdown, what not. So I don't think there is a generic way to block /those/ things that configure the network.
<xnox> unless you opportunistically encode all of their names.
<pitti> xnox: yeah, that'd be network.target
<pitti> (sorry, I thought you meant "use the network")
<xnox> pitti, i thought that e.g. "before=network.target" unit, may still run in between say networkd and network.target.
<xnox> as e.g. networkd is simply before network.target.... no?
<smoser> well, yeah. i want to be able to run code when the network is up that basically blocks all other code that would expect the network to be up.
<smoser> but i want to not know what  brought that networking up
<smoser> i want to be special!
<xnox> ah.
<pitti> xnox: right, sorry, network-pre
<pitti> you are talking about two different things
<xnox> pitti, oh, that one, ok.
<xnox> right.
<pitti> smoser talks about "using the network" (but after configuring it) -> network-online.target
<pitti> xnox talks about "things that bring up interfaces" (network-pre.target)
<smoser> yes. i need both.
<smoser> cloud-init-local before network-pre.target
<smoser> and
<smoser> cloud-init after network-online.target
<smoser> but what i want is
<smoser> cloud-init=network-online.target
<pitti> smoser: right, the -local bit should run very early (as said in the pad, that shows how to put it earlier)
<xnox> you can make cloud-init to be required by network-online.target, and just wait for network to be up.
<xnox> because that target is a blocking one already.
<smoser> hm..
<pitti> well, depends
 * xnox with his upstartish ways of doing things
<pitti> stuff like postgres or haveged or whatnot isn't  caring about network
<smoser> right. somet hings i can't affect. thats fine.
<pitti> so those things need to be configured in -local then
<xnox> or local should install a firewall rule =) har har
<pitti> smoser | cloud-init=network-online.target
<pitti> smoser: ^ what does that mean?
<smoser> Before and After
<smoser> :)
<pitti> well, a target is a synchronization point, it doesn't "do" anything
<pitti> i.e. you can run before or after, but not "in" it
<smoser> right. but i need to run after it is there and want to stop evyerthing else that would run 'After' it
<xnox> and by default that target is empty, and a thing that brings up network has a helper to say "network is online".
<pitti> that's similar to upstart, yuou can either do "on starting" or "on started" (before or after)
<xnox> so on ubuntu
<smoser> right.
<pitti> smoser: that concept of "I want to be the only one" doesn't exist in any init system any more
<xnox> network-online.target.wants -> [networking.service, NetworkManager-wait-online.service]
<pitti> (not even sysv with inssersv)
<pitti> because, what happens if there's another package which wants to be the only one? :-)
<xnox> thus on ubuntu you want to be (a) wantedby -online.target (b) after = [networking.service, NetworkManager-wait-online.service]
<smoser> pitti, you're completely missing the point. *I* want to be special
<smoser> i dont care about other people!
<smoser> :)
<pitti> oh, right :)
<xnox> you can add wanted by everywhere, and to work everywhere you should add After = networkd
<xnox> and that's it.
<pitti> reminds me of those bug reports that say "this must be the last thing on boot"
<pitti> (and of course I've seen at least three *different* people/packages claiming that)
<pitti> smoser: so yes, if you want to  block a target, do Before=network-online.target, and wait on the specific thing you just configured, like networking.service
<smoser> there shoudl be a target "basically-last-thing-in-boot"
<pitti> smoser: and if/once cloud-init learns how to setup networkd, you can add After=systemd-networkd.service too
<smoser> rc.local (what it used to provide) is such a very useful thing for normal humans.
<xnox> we call that "multiuser.target" =)
<smoser> but, lets not go there :)
<pitti> well, that conceptually isn't possible :)
<smoser> and 147 things run at 'multiuser.target'
<pitti> (and that's completely independent of insserv/upstart/systemd)
<xnox> not systemd-networkd.service, but after systemd-networkd-wait-online.service.
<smoser> hey.
<smoser> i really do have to run now.
<pitti> ok, time for lunch then
<smoser> xnox and pitti have been very, very helpful
<smoser> thank you
<smoser> pitti at your leisure, yuou have an email about pollinate from me too.
<smoser> thanks again.
<smoser> best irc chat ever.
<xnox> smoser, but given our on/off thing, your cloud init generator will need to install "cloud-init" wanted by "network-online", the After= lines can be encoded for all the world wide known network-online.target wanted'bys....
<smoser> really, thank you!
<xnox> or even better the generator can sniff those off disk.
<xnox> cause you want to create network-online.target.wants/cloud-init.service & create cloud-init.service.d/after.conf -> and that conf will list [Unit]\n After=`ls /etc/systemd/system/network-online.target.wants`
<pitti> xnox: urgh, that sounds  way too hackish
<xnox> =)
<pitti> xnox: cloud-init can only configure ifupdown anyway, so there's little point waiting for the others
<xnox> pitti, it's not about configuring network however. ifupdown can only be done by cloud-init-local. I think what smoser here is after "network is configured by whatever" now block all services and wait for cloud-init to finsih installing/upgrading packages; configure users etc..... do everything. And then unblock network services to spawn everything else.
<xnox> e.g. sshd server.
<pitti> xnox: correct, which is just Before=network-online.target in cloud-init.service
<xnox> pitti, can one be wantedby & before network-online.target?
<xnox> it can't be before network-online.target, as then it will before network is actually configured....
<pitti> xnox: yes, that's by far the most common behaviour (it's unusual for something to want a dependency, but that dependency should run *after* oneseelf)
<xnox> e.g. before network-online.target, will be before networking.service/NetworkManager-wait-online.service
<xnox> no?
<pitti> xnox: right, hence cloud-init.service being After=networking.service Before=network-online.target
<xnox> that's racy.
<pitti> as we don't (currently) care a bout anything else in cloud-init than ifupdown
<xnox> ok. so it's racy in network configs that support -wait-online stuff properly (e.g. networkmanager, networkd)
<pitti> if you want to block on those too, then add them to After=, yes
<xnox> right, gotcha.
<flexiondotorg> muktupavels, I've built Compiz with you changes stacked on mine here - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+build/9327928
<flexiondotorg> muktupavels, And tested it. Works great. Thanks for your help on this, it is much appreciated :-)
<flexiondotorg> muktupavels, Changes merged in the proposal - https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882
<flexiondotorg> Trevinho, I've merged and tested the changes muktupavels suggested for the improve Marco integration in Compiz. Please review https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882
<knome> could somebody look at bug 1555046 and help us get it uploaded? the shimmer-themes package is snatched from xubuntu by some dependencies to the kubuntu packageset so we're unable to do that ourself
<ubottu> bug 1555046 in shimmer-themes (Ubuntu) "Please upload shimmer-themes-2.1.1-0ubuntu1 to xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1555046
<knome> cheers!
<smoser> pitti, "conflicts/before=shutdown.target" ?
<pitti> smoser: that's to ensure that it gets stopped on shutdown (shouldn't be relevant, it's just standard practice; see man systemd.service DefaultDependencies)
<smoser> ah. ok.
<smoser> is there a way that i can get systemd to print a log with microsecond timestampos of services and targets ?
<smoser> that were started thus far.
<smoser> pitti, ^ is that just an ignorant question ?
<pitti> smoser: (in meeting, bbl)
<smoser> perfectly acceptable. thanks.
<pitti> smoser: jounralctl -o short-precise?
<pitti> smoser: journal always stores microseconds, it's just output formatting/presentation
<smoser> but that is just stuff that got written to journal
<smoser> (had journal output or somethingt)
<smoser> suytemd ran a bunch of servivces and decided that some targets were reached.
<smoser> it did that at certain points in the boot
<smoser> i'd like to get timestamps of every one of those.
<smoser> systemd-analyze critical-chain is useful
<pitti> smoser: yes, these are recorded in the journal too
<pitti> smoser: MÃ¤r 10 05:01:27.102984 donald systemd[1]: Starting Load Kernel Modules...
<pitti> smoser: something like this "Starting/Started", coming from systemd itself)
<pitti> smoser: yeah, systemd-analyze can massage these nicely too; "plot" for the visually inclined :)
<caribou> infinity: regarding the mstflint adujstment of yesterday I have a few final questions
<caribou> infinity: trusty's version is 1.4-OFED-1.4.2-1ubuntu1 and wily's version is 3.7.0+1.18.gcdb9f80-3.1ubuntu2. I supposed that the versionned Breaks should be << 3.7.0+1.18.gcdb9f80-3.1ubuntu2 (wily's) ?
<smoser> pitti, ok. i was just not seeing what i was looking for becausae systemd shows the 'Description' there
<smoser> which then you have to map back to the unit
<smoser> ie, if i want to know about 'pollinate'
<smoser> # journalctl -o short-precise | grep Seed
<smoser> that works
<smoser> but this does nto
<smoser> # journalctl -o short-precise | grep pollinate
<smoser> not even
<pitti> smoser: systemctl show <unit> also shows the timestamp, in case that's easier
<smoser> what is the MONOTONIC things there ?
<smoser> unless its hidden in one of those, 'show' only seems to show 1 second granularity
<pitti> smoser: clock_gettime(CLOCK_MONOTONIC); probably not relevant for you, unless you deal with ntp or TZ shifts in between
<pitti> clock_gettime(3) has the gazillion different clocks that Linux provides
<pitti> barry: so pysmbc is on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wanting to go to universe
<pitti> barry: a bit curious, I thought we wanted to kill python *2* stuff
<barry> pitti: this is all caught up in the samba madness
<barry> pitti: in some respects python3-samba should stay in main because it can get installed on-demand by system-config-printer.  but it's off the desktop iso now, so...?
<pitti> barry: so I guess it can go, it's expected to not be there by default
<pitti> ?
<barry> pitti: i think that's fine for now.  unfortunately py2 won't get booted off the desktop in 16.04 because of gvfs-backends.  we'll have to make more progress on upstream samba get any further.  boot it to universe for now
<coreycb> pitti, I had 2 packages in the xenial new queue that aren't showing up now (python-neutron-lib and python-aodhclient).  should I re-upload?
<barry> pitti: (possible it will get re-mained in 16.10)
<pitti> coreycb: err, no idea, did someone reject them? (you should have gotten a mail about that)
<coreycb> pitti, I don't see anything, I'll try to upload again
<pitti> rbasak: I'm a bit confused, why does the ubuntu-server metapackage want to go to universe?
<pitti> rbasak: are we not using that any more? I. e. intended (and should it perhaps be removed?) or unintentional?
<ogra_> main got to small for it
<ogra_> it now wants the whole thing :)
<pitti> I thought that was apt-get install fillherup
 * ogra_ assumes thats a bug ... we still produce server isos
<pitti> well, there was talk about unifying cloud and server images etc., so it's not entirely implausible that it's by intent
<rbasak> smoser: ^
<ogra_> well, we definitely want the server task ... not sure if the metapackage is (was ever) actually needed
<rbasak> I think smoser wants the metapackage so that it's clear when removing packages that you're removing ubuntu-server.
<rbasak> So it defines what ubuntu-server is better.
<smoser> i certainly dont want ubuntu-server in universe.
<ogra_> (does it anything more than installing openssh-server on top of ubuntu-standard ? )
<ogra_> ah, right, removals
 * ogra_ didnt think of that
<pitti> also, dist-upgrades
<pitti> those are the reasons why we keep the package in main for desktop
<pitti> and we seed the metapackage into "itself"
<smoser> pitti, so yes, i guess we should seed that package
<pitti> hm, it wasn't seeded in wily either
<pitti> ah!
<pitti> it's new in xenial
<smoser> its new in xenial
<smoser> seeding a metapackage derived from the seed seemed to circular tom e
<pitti> the metapackage doesn't define the seed
<pitti> we do have (a lot of) seeds without metapackages, too
<pitti> smoser: ok, thanks for cleaning that up; this was a bit confusing
<nacc> is it expected that dpgk-gencontrol doesn't respect -N in DH_OPTIONS?
<pitti> nacc: yes, DH_* is a debhelper option
<pitti> nacc: if you mean dh_gencontrol, then no
 * pitti waves good night, still not feeling too well
<smoser> pitti, the metapackage is derived from the seed.
<nacc> pitti: err, sorry, meant that, yeah
<smoser> so adding it to the seed seems circular
<nacc> pitti: will investigate
<attente> juliank: hi. is there some way to trigger an apt update over dbus (with aptdaemon or packagekit or some other service)?
<juliank> Yes, with both
<juliank> don't ask me how
<attente> juliank: ok. i was trying with org.debian.apt.RefreshCache but for whatever reason it doesn't seem to do anything...
 * juliank would use PK's org.freedesktop.PackageKit.Transaction.RefreshCache ()
<nacc> slangasek: is it just a matter of timing, or is there a reason php7.0 is stil in excuses? I see "Valid candidate" so that just means it hasn't been moved yet?
<Pharaoh_Atem> :(
<Pharaoh_Atem> ubuntu-devel is moderated :(
<nacc> Pharaoh_Atem: yeah.. you get used to it
<Pharaoh_Atem> what's amazing is that none of the other distro MLs I'm on are
<Pharaoh_Atem> or at least, they aren't anymore
<dobey> hmm, why isn't x11-xserver-utils migrated
<nacc> dobey: relatively the same question i just had about php7.0 -- seems like there a few "Valid candidates" that are a bit old
<nacc> dobey: not sure how that works
<dobey> yeah, but i don't need php7 to get 60Hz on 4K monitor :)
<nacc> dobey: heh
<dobey> do need full stack for xrandr 1.5 though
<streulma> hello, am I right here for 16.04 questions ?
<streulma> shim disabled Secure Boot... How can I enable it again ?
<dobey> #ubuntu is the general support channel; #ubuntu+1 is for "next release" stuff, so might be more appropriate
<brendand> hi, having a hard time creating a static cp binary on trusty
<brendand> please don't ask why
<brendand> got and configured coreutils source
<brendand> then 'make SHARED=0 CC="gcc -fPIC -static -std=gnu99"'
<sarnold> that's a funny CC
<sarnold> try CFLAGS="-fPIC -static -std=gnu99"  instead
<sarnold> alternatively grab sash or busybox or something? :)
<sarnold> brendand: ^^^
<lewq> maybe http://askubuntu.com/questions/530617/how-to-make-a-static-binary-of-coreutils ?
<brendand> is the one in busybox static?
<brendand> sarnold: but CFLAGS did the trick, thanks
<rharper> smoser: rbasak:  please git-dsc-import tgt to ubuntu-server-dev in launchpad when you get a chance;
<smoser> k
<chiluk> is anyone else running xenial having massive issues with network-manager not respecting DNS settings when connecting to VPNs?
 * Pharaoh_Atem shrugs
<chiluk> basically whenever I connect to the vpn it uses the vpn dns servers in spite of the fact I've told it not to.
<Pharaoh_Atem> sounds like an NM 1.0.x issue
<Pharaoh_Atem> which vpn type are you using?
<sarnold> chiluk: there's a handful of bugs about dhc* issues.. apparently an isc dhcpcd or dhclient runs with threads but one of the isc bind libraries is not thread safe..
<chiluk> I was leaning more towards network-manager being the culprit.
<juliank> tkamppeter: Maybe you know why hplip has a hplip-kubuntu.desktop, and why the names are different? The reason given is 'Kubuntu doesn't have any application categorised in "Settings"' - but the hplip.desktop (now?) uses  Categories=Application;Utility; - I assume that's fine?
 * juliank is doing a massive hplip packaging cleanup
<juliank> (in Debian)
<stefanct> minor bug in glibc(?) package in xenial: http://dpaste.com/042441N (i am upgrading a test machine right now)
<nacc> stefanct: hrm, it's escaped in xenial for me
<nacc> stefanct: and that's not a bug in libc, it's a reported warning in the specified perl file
<nacc> afaict
<nacc> stefanct: both are escaped in my (current) install of xenial
<stefanct> it is but apparently triggered by configuring the libc package... i have not looked at the code
<nacc> i mean, it *should* complain about every package, i think
<nacc> not just libc
<nacc> as it's going to complain about the deprecation on every load of that file
<nacc> stefanct: what perl do yo have installed (apt-cache policy perl)
<nacc> stefanct: err, rather debconf
<stefanct> it definitely does not for every other package (i have seen it only for glibc yet) but i can look at the log later
<stefanct> well, right now 1.5.58ubuntu1 but it might have been updated already
<nacc> stefanct: yeah, i'm on that version and the referred to source file does not have the referred to issue
<nacc> stefanct: xenial is a moving target, so i think it's been fixed
<nacc> stefanct: looking at the changelog that was fixed in wily (1.5.57ubuntu1)
<nacc> stefanct: technically in debian, 1.5.57
<nacc> stefanct: it's possible the perl update is what caused the deprecation to get emitted (as the chagnelog mentions the message shows up with 5.22 and on)
<stefanct> ill check the log when it is done to look for the sequence and versions of perl and debconf upgrades
<nacc> yeal, wily had 5.20, it seems, so if it was a wily -> xenial upgrade, i think those messages may be possible, not sure
<nacc> rbasak: hey, so trying to understand why php7.0 hasn't migrated yet, can you explain how that works?
<rbasak> nacc: so in update_excuses.html, we see "Valid candidate", so next is to look at update_output.txt
<rbasak> Here, it's trying to find a combination of packages to migrate to the release pocket such that the number of uninstallable packages does not increase.
<rbasak> trying: php7.0
<rbasak> * amd64: fusiondirectory, fusiondirectory-plugin-addressbook, fusiondirectory-plugin-alias...
<nacc> rbasak: ah that's what i was missing! this other file
<rbasak> These are the packages that it says will become uninstallable in the release pocket if php7.0's binaries were to migrate to the release pocket.
<rbasak> Trying easy from autohinter: php7.0/7.0.3-9ubuntu1 phpunit/5.1.3-1+ubuntu3 php-defaults/32ubuntu1 php-codesniffer/2.5.1-1ubuntu4
<rbasak> Here you can see that it's trying to migrate multiple packages at once, but it hits the same problem.
<rbasak> I'd start by seeing why fusiondirectory is uninstallable. "chdist apt-get xenial-proposed install fusiondirectory" may tell us enough.
<nacc> rbasak: yep, thanks!
<nacc> rbasak: in this case, i know what's goi gon
<rbasak> The following packages have unmet dependencies.
<rbasak>  fusiondirectory : Depends: php-imap but it is not going to be installed
<rbasak>                    Depends: php-mcrypt but it is not going to be installed
<nacc> gosa at least is blocked
<nacc> yep
<nacc> i am working on fixing that now
<nacc> we have to split hte src package
<nacc> effectively
<nacc> so that the universe targets can build
<rbasak> OK, great. More information at https://wiki.ubuntu.com/ProposedMigration
<nacc> rbasak: so that makes more sense to me
<nacc> rbasak: thank you very much!
<rbasak> No problem!
<nacc> rbasak: so in the split, we have two control files, the universe one adds the universe build-deps to the base source ... would it be better to just add a substituion variable and keep all the differences between the two packages confined to debian/rules?
<nacc> rbasak: a control fine two different packages, to be clear
<rbasak> Unfortunately you can't do that in the source section of the control file, AFAIK.
<rbasak> (so build deps)
<nacc> rbasak: ah ok, answers that question then :)
<nacc> rbasak: i was trying to find the cleanest "delta" (not a proper delta, but basically waht is needed to build the unvierse package given the main source package)
<stefanct> nacc: first perl (5.22.1-8) over (5.18.2-2ubuntu1.1); then libc6:amd64 (2.21-0ubuntu6) over (2.19-0ubuntu6.7); then debconf (1.5.58ubuntu1) over (1.5.51ubuntu2)
<nacc> stefanct: ah so it's an artifact of the ordering, i guess
<nacc> stefanct: as after debconf is upgraded, the message is gone
<stefanct> and it was from trusty
<nacc> rbasak: it seems like one suggestion is to use sed and a marker in the clean override, but that doesn't seem so much better to justify adding the complexity
<stefanct> i am not so sure about that... the message came exactly two times. for libc6 and libc-dev-bin. and actually i think it was the "unpacking" stage that produced it... it's a bit hard to tread from the log because it sees to be slightly out of order (is there any parallelism?)
<nacc> stefanct: why aren't you sure? the perl upgrade led to the deprecated warning, which is emmited by debconf Perl files when libc6 gets configured, then debconf gets upgrade and silences the warning
<nacc> s/silences/fixes/
<stefanct> there were lots of packages in between
<nacc> stefanct: between the perl and debconf upgrades?
<nacc> stefanct: sorry, I read the above, as the actual order and packages
<stefanct> between both paris respectively
<nacc> stefanct: can you pastebin the log?
<stefanct> *pairs :)
<stefanct> well, i have that information from the screenlog because it seems to be the only one containing all the information including the message - but it is rather unreadable
<stefanct> the apt.log might be suitable i guess?
<nacc> yeah, maybe
<stefanct> (if you trust me on the bogus messages :)
<stefanct> ill pastebin both
<rharper> how does one systemd services using Type=notify and a daemon that's supposed to sd_notify ?
<stefanct> oh well... the screenlog is almost 2MB and neither dpaste nor debian.net like that. apt.log: http://paste.debian.net/413989/
<nacc> rbasak: no need to reply, but it seems like for the univesre source packge, that i can dh_installdocs --link-doc to php7.0-common; is that ok?
<nacc> rbasak: that's per hte debian policy, i mean
<nacc> slangasek: ok, i've got a split package working with everything but php-interbase, which i think needs some extra tweaking (will work on that next). I think that will clear out a lot of the queue (as php7.0 should  migrate then)
<nacc> slangasek: so my plan is to send it in a bug as d ebdiff for php7.0 and a new pckage request for the universe source package
<slangasek> nacc: sounds good, thanks
<nacc> slangasek: np, i think i've got interbase figured, out just need to get the right configure tweak in place; it seems like the extension is relying on something from the -common makefile that isn't run now. Sorry it's taken so long! Had to learn a bit about makefiles :)
<mwhudson> i wonder when the last time the "Package has already been uploaded to" check in dput actually helped anyone was
<nacc> mwhudson: :)
<mwhudson> i guess i should just alias dput='dput -f'
<nacc> mwhudson: i think dput -f for PPAs is probably fine, I got in the habit of the same myself
<nacc> although that wsa the result of the (bad?) habit of not inserting changelog entries for one-off builds
#ubuntu-devel 2016-03-11
<mwhudson> this specific one was because i forgot -sa i think
<nacc> rbasak: we may want to setup a usd tree for php7.0 ... i think with the split packages, esp., it will be easiest to merge with git going forward. I've got the current code in a tree now locally that i've been using to dev on and for purposes of requesting new merges
<jrwren> can anyone point me to what a git url should look like for an ubuntu package on lp?
<jrwren> if it were bzr I'd push to lp:~evarlast/ubuntu/wily/b2/trunk what is the lp git equivalent?
<nacc> jrwren: i'd recommend setting up a lpmep alias as
<nacc> [url "git+ssh://user@git.launchpad.net/~user/ubuntu/+source/"]
<nacc>   insteadof = lpmep:
<nacc> at which point you can use
<nacc> lpmep:packagename
<nacc> and it will dtrt
<nacc> (aiui)
<nacc> jrwren, so that's just shorthand for lp:~user/ubuntu/+source/pkgname
<nacc> the reason to do the ubuntu/+source is that it links it to the gneeral packaging git trees in lp
<rharper> https://help.launchpad.net/Code/Git
<rharper> is useful for config/setup and questions
<nacc> rharper: thanks :)
<rharper> nacc: sure
<rharper> hrm, our disable systemd in udeb patch for multipath-tools also disables in the non-udeb package in the update; this screws up the service starting since it never emits the sd_notify
<rharper> at least I know why it doesn't start with the upstream systemd file;  I think debian suffers from this as well ; indeed
<rharper> the disable for udeb patch is from debian
<rharper> time to fix and file a debian bug
<rharper> heh, no-one notices for several reasons:  1) most folks don't really use multipath 2) there's a socket activation version of multipathd ; so even if multipathd isn't always running, if you just run multipath -ll; it'll spawn and work without the daemon going;  3) we also have an init script which just doesn't do the whole sd_notify and runs without -d (don't daemonize)
<rharper> what a pita
<tarpman> w 21
<tarpman> excuse me.
<jrwren> nacc: thanks! that is exactly what I wanted
<infinity> caribou: The Breaks/Replaces should be << the version where you introduce the transitional package (so, xenial's)
<infinity> caribou: Assuming I'm reading your question correctly.  Would be easier to see your current bits and review.
<cpaelzer> goo dmorning
<tjaalton> lp is slow catching up with debian, packages not syncable after 9h
<dholbach> good morning
<Trevinho> flexiondotorg: ok thanks, will do it.
<sil2100> Laney: hey! What are the requirements to become a DMB member?
<Laney> sil2100: be in ~ubuntu-dev, nominate yourself
<Laney> show up at the meetings and do the thing :)
<sil2100> Laney: aren't I too much of a hmmm... freshman for that?
<sil2100> The DMB had always veterans in it :)
<Laney> sil2100: I wasn't a core-dev when I first joined :-o
<sil2100> Oh
<Laney> I got interviewed by the DMB that I was a member of
<Laney> that was funny
<sil2100> hoho, ok, might be a nice experience then, let me nominate myself
<Laney> 15:00 UTC and 19:00 UTC
<Laney> well I guess that can be changed if the members decide
<Laney> but that's what they are atm
<tjaalton> what's up with lp? still can't sync packages from debian
<tjaalton> the internal mirror doesn't get updates
<Trevinho> seb128: hey... Bonjour! Who can review the theme css changes nowadays?
 * Trevinho thought to be on desktop channel :-P
<Saviq> pitti, morning, can we do anything about these nvidia regressions https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html ?
<ngaio> is there a good reason why ~/.local/bin and ~/.local/share/man are not recognized as valid-locations-in-which-useful-things-are-kept in Ubuntu? pip install --user defaults to these locations
<ngaio> the pip developers tell me these locations just work in Fedora
<ngaio> install an application using pip install --user, and it puts the entry_points scripts in ~/.local/bin, which is not on the default Ubuntu path. It puts the man pages, .desktop files etc. under ~/local/man etc., which means the man page is not recognized by man, and so forth
<ngaio> sorry, that should be ~/.local/share/man
<ngaio> only when the user creates a ~/bin directly and symlinks to the executable in ~/.local/bin does the .desktop file show up in the Dash. Until that point the application cannot even be launched without the end user knowing the complete path
<Saviq> ngaio, at least for ~/.local/bin, it'd be easy for a malicious app to, say, put 'sudo' on your PATH and sniff your password
<ngaio> so how do the Fedora folks get around that problem?
<Saviq> they likely don't
<ngaio> because they have ~/.local/bin on the path
<Saviq> yup
<ngaio> and in ubuntu there is ~/bin.... so what's to stop that being used for a malicious sudo ?
<Saviq> it's not on your PATH by default, I don't think
<ngaio> it is by default
<Saviq> hmm not on mine
<ngaio> if you create a bin folder in the home directory
<ngaio> it will be there on next login
<Saviq> interesting, /me tries
<ngaio> automatically
<ogra_> Saviq, it is a debian default
<_hc> if something has access to write files to ~/bin, it probably also can do a keylogger
<ogra_> we inherit it ...
<_hc> which would leave less of a trace than a malicious ~/bin/sudo
<Saviq> right
<ngaio> sudo pip install foo.tar.gz is definitely not good, but not being able to launch a program is not good either :-) So what is the best way to handle this?
<ogra_> just add the two paths to your env ?
<ngaio> ogra_, that would imply a special shell script just for Ubuntu, as it cannot go in the setup.py, right?
<ogra_> i meant in your ~/.bashrc or ~/.profile
<ngaio> I'm asking because I'm an application developer and I want users to be able to install my application on Ubuntu, and while a PPA would be best not all the dependencies are in Debian and I doubt they will be for some time
 * ogra_ could now say that snappy would help here ... but wont :P ... if you use a PPA, you can as well have your deps in there 
<ngaio> yes a PPA would be best but to be honest it's so difficult trying to figure out the packaging of python packages that aren't mine and use things like SWIG that I'm not familiar with
<ngaio> so in any case, it seems like ~/.local/bin will not be made a default path for 16.04, is that correct?
<pitti> Saviq: I suppose they should just get overridden; I did that now
<Saviq> pitti, thank you
<ogra_> ngaio, unlikely
<ngaio> ogra_, ok thanks... I'll let the pip folks know, as some people in the #pypa channel are curious about it too
<LocutusOfBorg> xnox, hi, any idea/opinion about a nodejs sync/merge?
<dasjoe> cjwatson: I'm just looking at http://bazaar.launchpad.net/~ubuntu-core-dev/partman-efi/ubuntu/annotate/head:/check.d/efi - you found the minimum partition size for FAT32 to be 65536 + 1048 sectors. This smells funny, as FAT32 (which your ESP uses by default) actually apparently has a minimum size of 65527 *sectors*. On 512b disks that makes your number close to the lower bound, but native 4k disks require an ESP of at least 256 MiB, it even
<dasjoe> may be better to use (65536 + 1048) sectors.
<cjwatson> dasjoe: cyphermox is dealing with this kind of thing nowadays
<dasjoe> cjwatson: right, I'll just leave this message here for them to see :)
<smb> cyphermox, there is also some small change to os-proper (bug 1374759) which maybe you could sanity check and maybe sponsor...
<ubottu> bug 1374759 in os-prober (Ubuntu) ">>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old" [Medium,Confirmed] https://launchpad.net/bugs/1374759
 * smb wonders why he almost always fails to spell prober properly
<cyphermox> hehe
<cyphermox> good morning!
<cyphermox> dasjoe: ok, I'll just look to find some way to figure out whether we're on 4k disks or not, or to make sure we can really reliably count in sectors regardless of disk sector size
<smb> cyphermox, good morning too :)
<smb> lamont, errm, I know I am a pita... any news on the bind9 exports frontier?
<Odd_Bloke> smb: You'll proberly work it out one day.
<Odd_Bloke> rbasak: o/ Did you see my comment on https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691?
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,Fix committed]
<rbasak> Odd_Bloke: yes I did. Sorry, I haven't managed to circle back to squid3 yet.
<Odd_Bloke> rbasak: No worries; just checking in. :)
<lamont> smb: this weekend, somehow, I'll get it upcoded, upload sunday or sometime monday evening
<cyphermox> smb: this os-prober change kind of works a little bit by chance ;)
<smb> cyphermox, You mean mine or upstreams? I found mine more reasonable for checking before actually mounting stuff. :)
<cyphermox> yours
<smb> cyphermox, oh why?
<cyphermox> where is upstreams?
<smb> cyphermox, included in os-prober 1.68
<cyphermox> hum, we already have 1.68?
<smb> cyphermox, the addition of having a helper to check for extended partition. Right but they do the check in a function that states it needs partitions mounted
<cyphermox> yeah
<cyphermox> you need both things
<smb> cyphermox, which is the reason its still broken in Xenial
<smb> cyphermox, yep, I was proposing my change on top of the current xenial version
<cyphermox> you should check for an "extended" partition, but that only works because the BIOS GRUB partition has no filesystem data according to blkid, and extended partitions are extended partitions
<smb> cyphermox, the extended partition we talk about is the small thing that gets created for the container. I think its always only about 2 sectors
<cyphermox> well, it's not extended, it's a protective MBR which just happens to look much the same ;)
<cyphermox> wait, we're not talking about the same thing
<cyphermox> this would potentially fix the two bugs, anyway
<smb> cyphermox, could be yeah. What I mean is that say you create an extended msdos partition as sda2 (with the actual partitions being inside being sda5...onwards)
<cyphermox> yep
<smb> So currently this sda2 which contains noting but potentially an mbr is still tried to be mounted and it should not
<smb> So what I believe blkid returns for that sda2 will never be more than a PTTYPE thing (at least not a filesystem). and apparently before would have returned an error for it
<xnox> LocutusOfBorg, we are past featurefreeze.... i have not looked into it.
<smb> lamont, sorry I ignored you a bit... would be awesome. consider me being on watch for it :)
<flexiondotorg> Mirv, Thank you for the sponsoring earlier :-)
<LocutusOfBorg> xnox, it is an LTS release, this is why I'm worrying about a sync/merge
<LocutusOfBorg> see ubuntu-devel or ubuntu-devel-discuss mail list, where somebody asked for it
<xnox> it is a universe package....
<Mirv> flexiondotorg: you're welcome :) the queue was so long, and I'm familiar with your packages by now
<flexiondotorg> Mirv, :-)
<Mirv> LocutusOfBorg: btw when syncing from Debian in order to close filed sync request bugs, the bug filers do appreciate the credit they get if you use the -s parameter for syncpackage (I once forgot it and got a note that the bug filer would have liked it)
<Mirv> and -b to close the bug
<LocutusOfBorg> Mirv, I use -s usually, but the only one that is asking me to sponsor stuff is mapreri :)
<LocutusOfBorg> xnox, I prefer to not sync/merge, I don't want to trigger some sort of transition or similar, I don't know if nodejs-depending packages will still build/work
<LocutusOfBorg> do you think it is safe?
<LocutusOfBorg> how can I test it?
<Mirv> LocutusOfBorg: ok :) I just noticed the yamllint which I tried to sponsor at the same time, but I thanked the bug filer adrien in the bug report.
<LocutusOfBorg> we have autopkgtestsuite for node, I wish I could do something similar locally
<LocutusOfBorg> Mirv, bad timing
<LocutusOfBorg> I usually sync/merge packages I have uploaded/sponsored in Debian
<LocutusOfBorg> https://tracker.debian.org/pkg/yamllint
<LocutusOfBorg> so, sorry but I didn't notice the bug
<LocutusOfBorg> I would have done the -s switch then :)
<Mirv> LocutusOfBorg: oh right! well Adrien got anyway the package he liked :)
<LocutusOfBorg> sure
<LocutusOfBorg> I'll thanks him too for the bug report
<dasjoe> cyphermox: hi! The general recommendation I've seen is to use 260 MB partitions even on 512b disks, just to be safe and to ensure a flawless migration to 4k disks in the future
<cyphermox> what does the spec say?
<dasjoe> cyphermox: which spec? FAT32 defines a minimal partition size of 65527 sectors, iirc
<cyphermox> yes
<lamont> smb: no worries
<smb> lamont, Well "worrying" is what I do a bit. :)
<lamont> heh
<lamont> ditto
<cyphermox> dasjoe: ok, but I don't think we should change the check in partman-efi
<cyphermox> if people know what they're doing and partitioning manually, it should be possible to create a 32Mb partition, and that might well be sufficient for their purpose
<cyphermox> (or you know, a whatever-equivalent size for 4K disks)
<LocutusOfBorg> chrisccoulson, would you sync/merge firefox from debian now? :)
<chrisccoulson> LocutusOfBorg, no
<cyphermox> dasjoe: where we deal with the recommended sizes from Microsoft and all of that would be in partman-auto instead; where the automatic partitioning happens
<dasjoe> cyphermox: probably not, I was looking for where the automatic stuff happens
<LocutusOfBorg> chrisccoulson, I thought it was good to reduce the delta
<dasjoe> cyphermox: right, that's why I couldn't find it in partman-efi
<cyphermox> yeah
<dasjoe> cyphermox: still, formatting a FAT32 with less than 65527 sectors may be invalid so it would be better to use FAT16 in this case
<cyphermox> well, it won't be less than 65527?
<dasjoe> cyphermox: oh right, missed what you said about detecting sector size
<cyphermox> to me it comes up to 66583.998... with the value set in partman-efi right now
<cyphermox> (which is fine for 512b disks, but not for 4K disks, but I don't know yet what the best way to detect 4K would be here)
<dasjoe> http://bazaar.launchpad.net/~ubuntu-core-dev/partman-efi/ubuntu/view/head:/commit.d/format_efi#L65 â This uses "blockdev --getss". 4k disks with 512b emulation may lie here, but that is of no concern to us
<cyphermox> ah, right
<smb> cyphermox, thank you for sponsoring
<cyphermox> smb: my pleasure
<dobey> tjaalton: hey, any idea why x11-xserver-utils hasn't migrated out of proposed yet?
<tjaalton> dobey: let me check
<tjaalton> huh, no idea
<cyphermox> dasjoe: try this for partman-efi: https://code.launchpad.net/~mathieu-tl/partman-efi/too-small-4k
<cyphermox> ah, looking really quickly our minimum for the efi partition would be 538 M anyway
<tjaalton> dobey: poked #ubuntu-release
<cyphermox> dasjoe: ^
<dasjoe> cyphermox: 538M?
<pitti> trying: x11-xserver-utils
<pitti> skipped: x11-xserver-utils (0 <- 40)
<pitti>     got: 213+0: a-54:a-23:a-29:i-28:p-27:p-28:s-24
<pitti>     * amd64: arandr
<pitti> dobey, tjaalton ^
<pitti> apparently it makes arandr uninstallable
<flexiondotorg> muktupavels, Do you have a few mins to help on a compiz merge conflict?
<dobey>   * Add Breaks on arandr << 0.1.9 (see #815731).
<dobey> pitti: yeah, it's supposed to? :)
<muktupavels> flexiondotorg, ?
<cyphermox> dasjoe: on amd64: 538 538 1075 fat32  <--- the first is the minimum, second is a priority value, and third is the maximum
<flexiondotorg> muktupavels, See this comment https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882/comments/737610
<pitti> dobey: well, then arandr apparently needs and update
<tjaalton> pitti: ah, meh
<flexiondotorg> muktupavels, There are conflicts between our merge proposal for Compiz.
<dobey> hmm
<cyphermox> priority should make it go somewhere between the minimum and maximum, possibly somewhere near the minimum AFAICT
<flexiondotorg> muktupavels, How to proceed? Should I take your branch and re-integrate my changes?
<muktupavels> flexiondotorg, i know
<dasjoe> cyphermox: I see, thanks. Sorry for the noise, then
<flexiondotorg> Or can you merge my stuff into your branch?
<dobey> tjaalton: oh i see debian has 0.1.9-1 for arandr, and xenial has 0.1.8-1
<dobey> tjaalton: i guess you need to sync it too?
<tjaalton> yeah
<tjaalton> missed that
<cyphermox> dasjoe: np; it was worth checking. I just tweaked the minimum /boot size recently too.
<tjaalton> dobey: synced
<dobey> hopefully it will migrate now :)
<muktupavels> flexiondotorg, I dont know what is right way to do this... I would probably start with my branch, then merge your branch, fix conflicts and create new merge proposal with my branch set as prerequisite
<dasjoe> cyphermox: can you see why 538M was chosen? I'll talk to rlaager and edit the root-on-ZFS guide
<muktupavels> flexiondotorg, bzr reports 5 conflicts..
<dasjoe> cyphermox: a quick googling for the numbers you pasted results in http://bazaar.launchpad.net/~ubuntu-installer/partman-auto/master/files/head:/recipes-amd64-efi/ - which does not reflect https://lists.debian.org/debian-boot/2015/05/msg00030.html :)
<muktupavels> flexiondotorg, looks like it should not be hard to fix...
<cyphermox> dasjoe: that's not much of an issue, mostly just cosmetic
<dasjoe> cyphermox: found the source, https://bugs.launchpad.net/curtin/+bug/1306164
<ubottu> Launchpad bug 1306164 in curtin (Ubuntu) "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix released]
<cyphermox> yes, that's the right bug
<cyphermox> dasjoe: so, free vs. fat I was hoping it had been fixed already, so I'll look again, but it was about some cases where partman-efi wouldn't notice the EFI partition at all in that case, not that the sizes were wrong
<LocutusOfBorg> can anybody please explain me why gdcm is not migrating? poppler?
<flexiondotorg> muktupavels, OK, I'll take your branch and merge my stuff in to it and resubmit.
<flexiondotorg> muktupavels, I'll ping you with merge proposal when I'm done.
<muktupavels> flexiondotorg, I am alredy fixing conflicts
<rbasak> trying: gdcm
<rbasak> skipped: gdcm (10 <- 30) got: 213+0: a-54:a-23:a-29:i-28:p-27:p-28:s-24 * amd64: libgdcm-tools
<flexiondotorg> muktupavels, Brilliant.
<flexiondotorg> muktupavels, Thanks for your help.
<rbasak> Oh, it might not be that.
<flexiondotorg> muktupavels, I need to go to a meeting, but I'll be back a little later. can we catch up then.
<muktupavels> flexiondotorg, I will push new branch in few seconds...
<LocutusOfBorg> rbasak, exactly
<LocutusOfBorg> I'm not sure what is wrong with that
<LocutusOfBorg> it is obviously installable
<apw> LocutusOfBorg, is it perhaps telling you that other things depending on that get broken via that library, as it next trys to migrate it with other packages which fail for a different reason
<apw> (for kde sounding things)
<rbasak> LocutusOfBorg: it's installable in xenial-proposed. It might not be installable in the release pocket after gdcm has migrated.
<apw> rbasak, though that is an internal package from gdcm
<LocutusOfBorg> rbasak, exactly, internal package
<rbasak> Perhaps it depends on something else in the proposed pocket though.
<rbasak> So it needs to migrate at the same time as something else.
<apw> rbasak, it is tied up with some other bits
<LocutusOfBorg> reverse-depends -r xenial libgdcm-tools
<apw> Trying easy from autohinter: boomaga/0.7.1-1build3 cups-filters/1.8.2-2ubuntu3 gambas3/3.8.4-2ubuntu2 gdal/1.11.3+dfsg-3build1 gdcm/2.6.3-3ubuntu1 inkscape/0.91-7ubuntu2 ipe-tools/20150406-3build4 libreoffice/1:5.1.1~rc2-0ubuntu1 pdf2djvu/0.9.3-1build2 pdf2htmlex/0.14.6+ds-2build1 poppler/0.41.0-0ubuntu1 popplerkit.framework/0.0.20051227svn-7.1build10 texlive-bin/2015.20150524.37493-7build5
<LocutusOfBorg> No reverse dependencies found
<apw> xpdf/3.04-1build1
<apw> LocutusOfBorg, what about its forward ones
<rbasak> I'm just saying that it isn't "obviously installable". That's all. Because our version of installable isn't exactly the same as what would be in the release pocket after migration.
<rbasak> Perhaps it needs a hint, or perhaps there's no combination that works. I don't know.
<LocutusOfBorg> apw, I also tried with -b , isn't it enough?
<LocutusOfBorg> rbasak, maybe some sort of deeper log of the script might help
<apw> britney seems to thnk those others are tied up with it, that they are co-dependant
<LocutusOfBorg> so karbon might be the solution?
<pitti> stgraber: with lxd, is there any way to get ephemeral containers using a tmpfs overlay like good old lxc-start-ephemeral?
<pitti> stgraber: I just found out why my lxd tests are so much slower than the lxc ones, and it's due to that -- I added eatmydata now, but writing all those ephemeral containers to disk is still quite a waste
<pitti> cloning is super-fast thanks to btrfs, but then the fsync axe hits
<stgraber> pitti: unfortunately we don't support overlay filesystems as container storage due to the way they work (makes snapshot, restore, copy, move a nightmare) and because of their odd behavior (problems with inotify and extended attributes)
<pitti> stgraber: ok, fair enough; at least I'm not missing some s3kr1t option; thanks!
<pitti> so, eatmydata it is!
<stgraber> pitti: if you were on zfs you could probably set "sync=disabled and atime=no" which is a eatmydata equivalent but at the backing fs level (can be set recursively for part of the zfs tree, say lxd/containers)
<pitti> stgraber: well, I certainly do want sync for my actual file system
<pitti> but I want testbeds (their overlays/deltas) to be entirely in RAM
<pitti> with QEMU I put the qcow overlay onto tmpfs, but we don't have that storage abstraction there
<pitti> stgraber: but yeah, I feel your pain wrt. inotify and its quirks
<pitti> stgraber: I just found another overlayfs regression in the xenial kernel today
<pitti> stgraber: I mean quirks of overlayfs
<stgraber> what we'd like ideally is for a way to tell zfs/btrfs to store the cow bits of a given subvolume on a specific block device, then have that block device be a ramfs
<stgraber> but neither of them supports anything like that
<pitti> stgraber: right
<pitti> stgraber: I just naÃ¯vely tried to mount a tmpfs onto /var/lib/lxd/containers, that didn't work so well
<pitti> (yay messing around in lxd's guts, rightly got my hand slapped :) )
<infinity> pitti: Have you noticed that component-mismatches is 2 days stale?
<pitti> infinity: err, no, I didn't; but then again *I* am 2 days stale too, so maybe that just compensated
<infinity> pitti: Heh.
<pitti> same for -proposed
 * ogra_ has the feeling he sees the FF crash dialog more often than the main window in 15.10 since the last update FF crashes at least once per hour for me recently :(
<pitti> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 5089560 Mar  9 18:28 mirror/ubuntu-germinate/germinate.output
<pitti> infinity: ^ germinate didn't update for 2 days, and c-m only runs if that changes
<infinity> pitti: Curious.
 * pitti runs it by hand
<pitti> hm, I expected to be greeted with some error message, but it's working silently
<infinity> adconrad@pepo:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ ls -l germinate.output
<infinity> -rw-r--r-- 1 lp_publish lp_publish 5823778 Mar 11 15:23 germinate.output
<infinity> It's updating on pepo.  Looks like it's no longer mirroring...
<cjwatson> wut
<cjwatson> rsync's still open
<pitti> oh, is update-germinate not what creates/updates mirror/ubuntu-germinate/germinate.output ?
<infinity> pitti: No.
<infinity> pitti: It's mirrored from ftpmaster.
<infinity> By archive-reports.
<infinity> Which might be dying before it gets there?  But that also seems unlikely, as the world would be halted.
<cjwatson> depends how late
<cjwatson> I'd suggest commenting out archive-reports from crontab, waiting for everything to quiesce, and then running it under sh -x
<sidi> pitti, hi, regarding https://lists.ubuntu.com/archives/ubuntu-desktop/2016-March/004790.html the reason why xfce4-volumed is still using gst 0.10 is because the GStreamer devs never ported the mixer interface to gst 1.0
<sidi> so it's not so much that the projects are dead, but rather impossible to keep maintained. Still happy for xfce4-volumed to be shot out of the repos though. I don't have time to work around the mixer interface's absence and provide a working package.
<pitti> sidi: I suppose the other mixer apps speak pulse directly now?
<sidi> pitti, yes, albeit we have a separate daemon in Xfce for pulse (xfce4-volumed-pulse)
<pitti> stgraber: how do you get upstream translations for LXD, btw? (noticed some odd-looking mix of German and English)
<pitti> sidi: thanks for the heads-up
<knome> pitti, thanks for taking care (re: xfce4-volumed) :)
<pitti> knome: well, I didn't do anything about it :)
<knome> if you're removing it, should we take care that it's out of our seed, or would you take care of that too
<pitti> knome: I won't remove any seeded package (or any package with reverse deps), that'd be a bit blunt :)
<knome> pitti, i think that'd do good ;>
<knome> ok, we'll coordinate getting it out of the seeds then
<pitti> stgraber: FYI, I'm filing/investigating bug 1556175 which makes reboots of lxd containers reeeeeeally slow (in case you get other reports about that)
<ubottu> bug 1556175 in ifupdown (Ubuntu) "networking.service hangs on shutdown in LXD" [Undecided,New] https://launchpad.net/bugs/1556175
<pitti> oh, that'd also explain why the ppc64el instances reboot so effingly slow, this doesn't seem limited to lxd indeed
<zequence> pitti: Seems our discussion on DVD authoring is taking a bit of time. It's mostly a matter of finding a replacement. Hope we will have come to some kind of a conclusion by monday
<pitti> lamont: as doko is out, would you happen to know why we switched isc-dhcp from libbind-export-dev to libbind-dev and now link with the non-export libs?
<pitti> lamont: oh, the new bind9 doesn't actually have the -export stuff any more; either way, this apparently changed the behaviour of handling SIGTERM (which is now broken in dhclient)
<pitti> lamont: does that ring a bell by any chance?
<lamont> pitti: I'll be restoring -export this weekend
<lamont> it's supposed to be killable, but dhcp isn't tehre yet
<pitti> lamont: ah, so this is more or less known?
 * pitti just spent 1.5 hours drilling down bug 1556175
<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
<lamont> pitti: dhcp leases do not renew
<lamont> not sure which bug number
<pitti> we could quick-fix it to send SIGKILL instead of TERM, but not sure if that could cause other problems
<lamont> it needs things taht are in the lib to not be in the lib, so back to two builds and two sets of libs
<pitti> lamont: ok, thanks; so I'll check that next week when it's split again
<lamont> the path was the dhcp maintainer in debian going "yeah, with 9.10, we can merge these and drop the export libs" followed by the bug erport and the "oh, actually, the version of dhcp that will work is not due out until may/june... oops"
<lamont> and what with everything, my life is hectic with deadlines that put fixing bind below the cutline for too many days running
<lamont> if someone (doko ??) wanted to prep a diff to put things back, the bind9 git tree on anonscm.debian has the 9.9.5 diff (which just needs sonames changeed) relatively isolated
<lamont> otherwise, it's on my list for my sunday afternoon
<pitti> cheers
<ScottK> rbasak: Based on the upstream feedback in #1549388, I think it'd be smart to update postfix in trusty to the latest 2.11 version (mentioning this with my Debian hat on, I don't plan to do it).
<ScottK> lamont: ^^^
<lamont> rbasak: ScottK that does sound like a good excuse for a backport
<lamont> backport/sru
<nacc> slangasek: just realized something with the php7.0/php-universe-source7.0 packages, the autopkgtests are only applicable to the former. They pass with the latter, becasue they just run the former's tests basically. So I think I should just update the rules file to only do the test generation for the former, and delete the tests/control file in the latter?
<slangasek> nacc: none of the tests test these universe extension packages?
<nacc> slangasek: no
<nacc> slangasek: no tests do, actually, in general
<nacc> slangasek: the tests that would can only be run during build-time anda re disabled in rules
<nacc> RUN_TESTS := no, currently
<nacc> as I think it would slow the build down quite a bit :)
<nacc> I can find out from Debian to be sure
<slangasek> nacc: then yeah, that sounds right to me.  I'm in progress on the review of the package you posted already, so a debdiff against the current php-universe package may be easiest for me to incorporate, but whatever you send I'll pick up
<nacc> slangasek: thanks! it's a very small change
<nacc> slangasek: what i'm not sure about and would appreciate your input on, is if it is better to make php7.0 in ubuntu have all the split stuff and then just have php7.0-universe-source have the WITH_UNIVERSE toggle and the renames? THat seemed cleanest to me, but does mean there are some not-strictly-needed for php7.0 chagnes in php7.0. I'm happy to do it either way, though.
<nacc> currently, that is, i've done what i just described, and php7.0 has the split in the latest version and php7.0-universe-source is just a small delta to that
<slangasek> nacc: having extra binary packages listed in debian/control that are not built in debian/rules is permissible, if that answers your question
<slangasek> so e.g. you should be able to drop the prepared: target in debian/rules
<nacc> slangasek: sorry, i asked it too roundabout :) would you rather see the main/universe split happen in src:php7.0 or in src:php7.0-universe-source? Right now, the split happens in src:php7.0 and then src:php7.0-universe-source is just choosing (effectively) to build src:php7.0's universe bits. Alternatively, src:php7.0 could be kept roughly in sync with debian (just with the WITH_UNIVERSE==no cases) and
<rbasak> ScottK: thanks
<nacc> then src:php-universe-source7.0 could have the remainder of the split (all the WITH_UNIVERSE == yes cases)
<slangasek> nacc: I would prefer the two source packages to be as close to one another as possible, minimal delta so that they can be easily diffed against one another later for maintenance
<slangasek> does *that* answer the question? :)
<nacc> slangasek: :) yeah; I personally think what I have is the cleanest for ust ot maintain. MOst of the delta is in php7.0 and then the diff between php7.0 and php-universe-source7.0 is very small. The only issue is the chagne to not run the tests in php-universe-source7.0 woudl be in src:php7.0, which means I need to provide a ubuntu3 debdiff (which is easy) and then a new php-universe-source7.0.dsc and
<nacc> debian.tar.xz
<slangasek> nacc: ok, sounds good - I'm heading afk for a bit but will check for diffs when I get back. btw, if you didn't see it I sent a follow-up comment to the bug with some (untested) thoughts on simplifying some of the debian/rules bits
<nacc> slangasek: actually, i can provide debdiffs for both
<nacc> slangasek: yep, jsut saw it, thanks!
<nacc> slangasek: so one issue with the suggestion above to not alter debian/control (an dI realize this might be a bug in the version i sent already in the bug) is that the .dsc file refers to binary packages that are not created by that src package?
<nacc> slangasek: the "fix" to that might be to have the shipped debian/control files reflect the right values (so i'd put that back in, dropped it in ubuntu2)
<bdmurray> tjaalton: it might be worth adding a DistUpgradeQuirk to the ubuntu-release-upgrader re fglrx. e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeQuirks.py#L161
<tjaalton> bdmurray: indeed
<bdmurray> tjaalton: is that something somebody on your team can take care of?
<tjaalton> bdmurray: probably tseliot
<bdmurray> tjaalton: I reported bug 1556248 about it.
<ubottu> bug 1556248 in ubuntu-release-upgrader (Ubuntu) "dist upgrade quirk need for fglrx and 16.04" [Undecided,New] https://launchpad.net/bugs/1556248
<dobey> tjaalton: hey. might you know how i can make the xrandr monitor config be saved across X restarts? when i --setmonitor, it gets lost on logout/reboot
<tjaalton> dobey: if the monitor config thing doesn't support it, then I guess some script to run on session start is your bet
<tjaalton> bdmurray: thanks
<dobey> tjaalton: so, the way i got a single screen was i had to run the xrandr --setmonitor, then i had to open the control center display properties and hit "Apply"; --setmonitor didn't propagate a visual reconfiguration for some reason
<tjaalton> huh
<dobey> so aside from that, and maybe a couple of minor annoyances, i seem to have reasonably working 60Hz 4k now :)
<tjaalton> cool
<dobey> steam install is busted though :-/
<persia> Good day. Could someone please direct me to the best channel to discuss changes in unity-gtk-module ?
 * ScottK waves to persia 
<ScottK> (no idea about the answer to your question though)
<persia> Heh, no worries.  This might be the channel.
<persia> I wanted to add an entry to the blacklist, to fix bug #1242937  harder: I have a merge proposal, but I've been away long enough not to be confident with what to do with it.
<ubottu> bug 1242937 in Unity GTK+ module "unity-gtk-module does not respect "ubuntu-local" property (used by e.g. Freeciv) as appmenu-gtk did" [Medium,Fix committed] https://launchpad.net/bugs/1242937
<nacc> slangasek: debdiffs just posted
<nacc> slangasek: so the only remaining (outstanding) issue is there is a doc dependency i don't think i can resolve ... the src:php7.0 installdocs target links everything to php7.0-common, e.g. ./usr/share/doc/php7.0-xml -> php7.0-common ... since that binary target is not from this source package, policy doesn't allow linking for src:php-universe-source7.0
<mterry> coreycb, for python-neutron-lib...   I don't see the package in Debian?
<mterry> coreycb, and it needs a team bug subscriber...
<nacc> mterry: it's in the NEW queue
<nacc> i think
<nacc> (per rmadison)
<mterry> nacc, ah the NEW queue in Debian.  Very new package then  :)
<nacc> mterry: yep :)
<mterry> nacc, well it's bug history in Debian is spotless then!  :)
<nacc> mterry: heh, always nice!
<nacc> slangasek: these binary targets depend on php7.0-common, though ... so not sure if this might be a gray area in the policy. I could also override it differently for the universe build, since there is the dependency
<slangasek> nacc: the binary packages built from php-universe-source shouldn't symlink their docs directories to php7.0-common
<nacc> slangasek: ok, they don't (i put in a comment as to why)
<nacc> slangasek: fyi, debian has pulled in the twig-testcase fix in 7.0.4-6
<bdmurray> niedbalski: Your upload fixing bug 1515278 doesn't include a bug reference to it.
<ubottu> bug 1515278 in oslo.messaging (Ubuntu Wily) "[SRU] rabbit queues should expire when unused" [Medium,In progress] https://launchpad.net/bugs/1515278
<flexiondotorg> Where are the ISO boot screen translations on Launchpad?
<flexiondotorg> The are some untranslated strings for Ubuntu MATE. I'd like to point translators in the right direction.
<coreycb> mterry, it's in debian new
<coreycb> mterry, I imagine that doesn't count though
<coreycb> mterry, I just added a team bug subscriber
<mterry> coreycb, left comment approving.  Didn't change status, since it's also an FFe bug
<persia> attente: It seems that we're shipping the wrong default in freeciv: thanks for checking.  I'll fix that in Debian, and do a sync, unless you see a reason to process it twice.
<attente> persia: sure, let me know when that's done and i'll approve your merge proposal
<cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/wily/2016-03-11/22:22:46.log shows sadness in a particular autopkgtest artifact, which is crashing proposed-migration and I suspect also explains the lack of component-mismatches runs (since that's later in archive-reports).  Could you please have a look?
<coreycb> mterry, thanks
<nacc> slangasek: looking at merging libsdl1.2, as we're out of sync with debian. You did a merge in November, I've got the debdiff done and ready to go, do you have any advice on testing? I think it'll also need a FFe, as it's a new upstream version
<slangasek> nacc: my advice is to not merge it, I reviewed the diff already and it's a nonsense "new upstream version" that drops a file, purportedly for freeness reasons, then re-adds the same file in a Debian patch
<nacc> slangasek: ok :) i wondered about that, it didn't really look like a change
<nacc> jgrimm: --^ are you ok with that?
<jgrimm> nacc, yep. doc it
<nacc> jgrimm: will do
<jgrimm> thanks!
<nacc> jgrimm: i'm done with all up to openipmi now, bugs opened, etc.
<jgrimm> you da man!
<nacc> jgrimm: makes sense to me, to have openipmi bug fixed, so i can carry that in the delta, rather than having to ask ibm to retest again
<nacc> jgrimm: are you ok i just put the LP #s in the spreadsheet?
<jgrimm> for now yes
<nacc> jgrimm: just a summary, 4 don't require FFes (as I see it), 1 does and 1 is a sync (does not need ffe)
<jgrimm> nacc, great! I gave hallyn a headsup that you might hit him up for some sponsorship
<slangasek> nacc: fwiw your dh_installchangelogs override inadvertently overrides it to null in the WITH_UNIVERSE case - fixing locally
<nacc> slangasek: that was intentional, but let me explain and you can correct me as you see fit
<nacc> slangasek: so src:php7.0, with that override, only installs changelogs for php7.0-common (the -p paramater) via the NEWS file
<nacc> slangasek: so let's say all packages were in main, then I think only php7.0-common would installchangelogs?
<nacc> slangasek: so I tried to mimic that by not doing anything in the case for php-universe-source7.0
<nacc> slangasek: should I have put the ifeq before the definition of the override?
<slangasek> nacc: dh_installchangelogs has two functions: to install the Debian changelog into the package, and (if specified) to install the upstream changelog.  For php7.0, the NEWS is the upstream changelog, and the override is there to specify the source location of that upstream changelog.  However, it's invoked for only -p$(PHP_COMMON) as an optimization, because we know that the doc directories for all
<slangasek> other binary packages are going to be linked to ...
<slangasek> ... php-common
<slangasek> so no reason to install the files in all the packages only to remove them right afterwards
<slangasek> but for php-universe, the doc dirs are not symlinks; so we want the default behavior of dh_installchangelogs instead
<nacc> ah!
<nacc> slangasek: yep, makes sense, thanks for that
<nacc> slangasek: sorry about that, didn't realize that nuance
<slangasek> ok, now the debian/control target is making my eyes cross ;)
<nacc> slangasek: heh
<nacc> they are *almost* identical
<nacc> slangasek: the issue is that if you leave the packages in control.in there, dh_genchanges complains about missing binary packages
<nacc> so i strip them out with grep-dctrl
<nacc> slangasek: it would be easier to read with a cp; grep-dctrl; rm like i did before, if you prefer (and functionally equivalent)
<slangasek> nacc: seems to me that the grep-dctrl isn't needed, again because we don't need to filter the list of binary packages in debian/control
<nacc> slangasek: the build fails w/o it
<slangasek> hmm, how does it fail?
<nacc> slangasek: let me find the logs
<nacc> slangasek: also, did you see my earlier query? now both src: packages .dsc files say they generate all the binary packages, because they are listed in debian/control
<nacc> slangasek: http://paste.ubuntu.com/15352259/
<nacc> sorry, meant dpkg-genchanges earlier, not dh_genchanges
<slangasek> I missed that query... it's ok that it does list the packages in both places, launchpad refcounts the binaries and that's what matters
<nacc> slangasek: ok cool, wasn't sure; it seemed to not affect the builds and the generated binaries were correct, but wanted to check, thanks
<nacc> for the purposes of merging, let's say the old ubuntu version is based off a debian version that doesn't seem present anymore, per pull-debian-source. Are there standard archives of old builds (including the .dsc and .orig.tar.gz)?
<slangasek> nacc: have you used 'grab-merge'?
<slangasek> merges.u.c archives these things
<nacc> slangasek: ah, i'll look at that, thanks!
#ubuntu-devel 2016-03-12
<slangasek> nacc: ok; so I can't reproduce your build failure, but I am seeing annoying behavior where if I try to simplify the rules, I'm getting (empty) binary packages spit out for all the stanzas listed in debian/control.  It seems like the -a option is somehow taking precedence over the -p options; I'll futz with this some more to try to figure it out
<slangasek> looks like the grep-dctrl might be the simplest solution anyway :/
<nacc> slangasek: yeah, i tried to find better ways, but settled on that. I can take it as an action item to try and clean it up further
<yofel> so, I'm a bit confused. Why was an autopkgtest run for a superseded version here? http://autopkgtest.ubuntu.com/packages/p/plasma-framework/xenial/s390x/
<mitya57> This may be because someone restarted the previously failed job
<nacc> slangasek: fyi, the php-cache-lite regressions seems to be due to deprecation, i can see if i can silence that warning so the tests pass
<nacc> slangasek: looking at php-html-safe, might be a real issue, but checking
<nacc> slangasek: ok, php-html-safe is failing because of a bug in php-xml-htmlsax3, fixed in debian, will request a sync
<nacc> slangasek: and i see why php7.0/php-defaults is hung up, that version of php-defaults needs a more current version of php7.0 than we have. I can do another merge, but would like your input as to what level you'd like to go to? Latest Debian (7.0.4-5) or the last 7.0.3 version (7.0.3-13)
<nacc> slangasek: whichever way you decide, i think we can clear out the rest of the php stuff (I've filed bugs for several) from excuses page at that point
#ubuntu-devel 2016-03-13
<Son_Goku> well
<Son_Goku> this is something I never expected
<Son_Goku> getting the same email twice on two different mailing lists
#ubuntu-devel 2017-03-06
<pitti> xnox: hmm, systemd's new "root-unittest" fails on armhf in test-copy; it works on s390x in lxc, so I wonder if that's an artifact of lxd or an actual bug on armhf; perhaps you can have a quick look what's going wrong, otherwise I'm happy enough to blacklist the test on armhf or lxd (whichever is right) for now
<cpaelzer> pitti: hi, I see in the autopkgtest history of systemd that the "storage" test failed rather often on ppc64el
<cpaelzer> pitti: I' currently ran into the same as well, since it failed/worked so often without any visible difference - are these just "retried until passing"
<cpaelzer> pitti: or is there some background to learn?
<cpaelzer> FYI - issues like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/ppc64el/s/systemd/20170306_005811_4a060@/log.gz
<pitti> cpaelzer: indeed, "reload ioctl on temporary-cryptsetup-5254 failed" -- that ioctl seems to be unreliable in cryptsetup somehow
<pitti> that should be easy enough to reproduce outside the systemd test suite too, for a kernel bug report
<pitti> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests/storage#n74 is the cryptsetup luksFormat call
<cpaelzer> pitti: ok, so in proposed retrying til pass and in a test env trying to debug and understand
<cpaelzer> pitti: thanks
<cpaelzer> depending which of both is faster the debugging might resolve the retrying :-)
<pitti> the test uses scsi_debug as a drive, I suggest to try with both that and a simple loop device to see whether that makes a difference
<cpaelzer> thank you, I will do so
<pitti> cpaelzer: y and x seem fine, so might be a regression of linux 4.11?
<pitti> actually it started failing with trigger linux-meta/4.10.0.8.10
<pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/ppc64el/s/systemd/20170217_024850_73931@/log.gz was the last successful one, with autopkgtest [01:48:28]: testbed running kernel: Linux 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20 15:28:49 UTC 2017
<cpaelzer> yeah I see that this was the "date" it started
<pitti> i. e. 4.9 â 4.10
<cpaelzer> former fails had other errors
<pitti> so apparently 4.10 got promoted with ignoring that regression :(
<cpaelzer> smb: ^^ did you hear (or could you ask around in the kernel team) anything about this?
<smb> cpaelzer, a) no b) might do
<cpaelzer> smb: ok, once (if) I have found a bit more debug data I'll show up in the kernel Teams chan as well then
<bdrung_work> hi, since a recent ubuntu 16.10 package update, the mod4 keyboard layer does not work any more for numbers. e.g. when i press mod4+j, it should result in number 4, but the mouse moves instead. do you have any hint at which package i should look at for this behaviour?
<bdrung_work> mod4 works correctly on the lightdm
<xnox> pitti, we have started to whitelist systemd/armhf failures which are only seen during adt tests but not during package build time
<bdrung_work> (i am using the german neo2 layout)
<xnox> pitti, i have not debugged it yet, and my wild guess that it has something to do with the fact that we run those on arm64 hardware
<xnox> (arm64 kernel)
<pitti> xnox: more interestingly, we run the unittests as root during that autopkgtest but as user during package build, so they skip a lot of stuff
<pitti> xnox: armhf buildds are the same: armhf chroots on the exact same kind of arm64 cloud instances
<xnox> pitti, aha, so that test has never run (on builders); and always failed (during adt); hence steve considered it as a non-regression
<pitti> right, that's plausible
<xnox> so it can be treated as "you shall never pass" unit test. Should be digged into why not, though.
<pitti> but would still be interesting to see what fails, to make sure it's just an lxd limitation and not an actual bug somewhere
<xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1670313
<ubottu> Launchpad bug 1670313 in systemd (Ubuntu) "armhf unit tests as root fail on adt tests, never run on builders" [Medium,Confirmed]
<cpaelzer> pitti: for the systemd ppc test error after some debugging I can confirm a kernel bug which I reported in bug 1670311
<ubottu> bug 1670311 in linux (Ubuntu) "aes-xts and aes-cbc failing to initialize on power since 4.10" [Undecided,New] https://launchpad.net/bugs/1670311
<pitti> cpaelzer: nice work!
<cpaelzer> tyhicks: FYI bug 1670311 also blocks your latest apparmor in zesty-proposed
<ubottu> bug 1670311 in linux (Ubuntu) "aes-xts and aes-cbc failing to initialize on power since 4.10" [Critical,Confirmed] https://launchpad.net/bugs/1670311
<coreycb> rbasak, hi, I responded to bug 1645772
<ubottu> bug 1645772 in ironic (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Incomplete] https://launchpad.net/bugs/1645772
<rbasak> coreycb: you still haven't reported the package versions you tested?
<rbasak> coreycb: doing it automatically is fine, but surely that automation provides that information in its output?
<rbasak> "If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested..."
<coreycb> rbasak, thanks i've tested sru's before :) i'll add the versions tested.
<rbasak> coreycb: thanks. I'm not asking just for the sake of it. I have been involved in at least one severe stable release regression in the past when the package version tested wasn't the one released. I don't want to be responsible for causing that kind of thing.
<rbasak> coreycb: and I figure that our process is good enough to detect that, if only we all followed the process. So I insist on it.
<coreycb> rbasak, ok i've added the versions tested
<rbasak> Thanks I'll take a look.
<coreycb> rbasak, thanks
<rbasak> coreycb: there are some autopkgtest failures in pending-sru on s390x - please could you check? http://autopkgtest.ubuntu.com/packages/n/neutron/yakkety/s390x
<rbasak> Only for neutron.
<coreycb> rbasak, sure
<rbasak> coreycb: I'm happy to release the others now if you would like.
<rbasak> (or I can wait until you've checked/fixed neutron)
<coreycb> rbasak, sure that'd be fine.  I'll let you know when neutron is fixed.
<rbasak> OK
<rbasak> Done
<coreycb> rbasak, thanks.  if i upload a new version of neutron with a dep8 test fix, should i use a new bug # or use the sru bug #?
<rbasak> coreycb: no need for a bug and paperwork for a dep8 fix. So don't refer to a bug at all in your new changelog message (unless there is one already). But do use -v when uploading the replacement, so that the new upload still lists the previous bug as fixed.
<rbasak> coreycb: so I think you'll be uploading a  2:9.1.1-0ubuntu2, source built with -v2:9.0.0-0ubuntu1.16.10.2, with one changelog entry added over  2:9.1.1-0ubuntu1 and no new bug references. Does that make sense?
<coreycb> rbasak, ok yes that makes sense. thanks.
<tyhicks> cpaelzer: thanks for the headsup on that bug
<xnox> rbasak, coreycb: is this not one more ordering bug of the units; where incorrect dependency/ordering is specified, and things do come up if one simply waits?
<xnox> but we have also been fixing the tests to come up the right way around.
<xnox> (in other openstack components)
<cpaelzer> tyhicks: yw
<cpaelzer> tyhicks: I see you have other  blockers as well still
<cpaelzer> tyhicks: but at least one less to debug
<cpaelzer> tyhicks: fyi the fix is enqueued for the next kernel upload already
<tyhicks> cool, that is helpful
<smoser> Laney, you tyhere?
<Laney> hey smoser
<Laney> for you, always!
<smoser> your changtes are good.
<smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/
<smoser> i just did those same changes
<smoser> https://code.launchpad.net/~smoser/software-properties/trunk.lp1670399/+merge/319105
<smoser> but showed a bit more context. and i like my changesn to run-tests better .
<smoser> but lets get this fixed.
<Laney> smoser: ok, as you prefer
<Laney> MP mail sucks, eh?
<smoser> just slow.
<smoser> i didnt see yours
<Laney> bit of a shame that we both spent time debugging it, but eh
<Laney> you go ahead
<smoser> yeah
<smoser> i open3d a bug.
<smoser> did you see that/
<Laney> nope
<Laney> I don't think it existed on Thursday when I submitted the patch
<smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1670399
<ubottu> Launchpad bug 1670399 in software-properties (Ubuntu) "dep8 tests are failing in zesty" [High,In progress]
<smoser> sorry. slow. i wish i'd seen your mp
<Laney> s'ok
<caribou> would someone have time to have a look at a small config change to the tftpd-hpa package I'm preparing ? http://paste.ubuntu.com/24125880/
<caribou> I haven't done much manging with upgrades of config params
<caribou> s/manging/mangling/
<caribou> I stripped the modification of the i18n .po files out of the debdiff btw
<smoser> Laney, http://paste.ubuntu.com/24125897/
<smoser> look goood ?
<Laney> smoser: sure, but spell my name right please :P
<smoser> no deal
<smoser> doh!
<smoser> Laney, uploaded. thanks.
<seb128> smoser, "This (lp...)"?
<seb128> was that missing some text?
<seb128> oh well, if it's uploaded
<coreycb> rbasak, zul has a new version of neutron in the review queue for yakkety, so if you don't mind rejecting that, i'll upload it again with the dep8 fix.
<Laney> yeah it said "fixes a testsuite failure."
<Laney> oh well
<smoser> seb128, yeah. :-(
<smoser> fail smoser
<coreycb> xnox, rbasak: i think we need to use needs-recommends in debian/tests/control to ensure neutron-plugin-ml2 is installed.
<smoser> i noticed that too
<smoser> after dput
<rbasak> ddebs missing for some packages on Trusty. IIRC this is a known thing? I have a bug report about it, not sure what to tell the reporter.
<rbasak> bug 1668299
<ubottu> bug 1668299 in php-json (Ubuntu) "missing debug symbols" [Undecided,Confirmed] https://launchpad.net/bugs/1668299
<rbasak> Ah, I found 1465777
<rbasak> bug 1465777
<ubottu> bug 1465777 in freetype (Ubuntu) "No ddeb for current Trusty updates." [Undecided,Won't fix] https://launchpad.net/bugs/1465777
<nacc> sarnold: is LP: #1582990 still an issue for you?
<ubottu> Launchpad bug 1582990 in libvirt (Ubuntu) "internal error: End of file from monitor" [Medium,Confirmed] https://launchpad.net/bugs/1582990
<sarnold> nacc: good question
<sarnold> nacc: yes
<nacc> sarnold: ok, thanks -- the debian report seems for an older version, so just wanted to double-check
<cpaelzer> nacc: are you working on the bug you asked sarnold about?
<cpaelzer> nacc: or were you only cleaning up and I shall put it on my list?
<nacc> cpaelzer: was only asking
<nacc> cpaelzer: triage duty
<nacc> cpaelzer: i figured i'd ping you about it at somep oint
<cpaelzer> nacc: ok, I put it on my list
<nacc> cpaelzer: thanks!
<stryderc> anybody here able to point me on the path to discerning the logic behind the Dash type down filtering?
<rharper> jgrimm: slangasek:  In attempting to verify resolvconf for yakkety; ran into an issue; I've updated the comments, looking for agreement on how to resolve; https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931
<ubottu> Launchpad bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed]
<slangasek> rharper: isn't systemd-resolved entirely an optimization of the DNS config?  Before systemd-resolved comes up, any DNS servers received should just be added to /etc/resolv.conf directly, and DNS resolution should proceed normally
<slangasek> systemd-resolved integrates with resolvconf, it doesn't supplant it
<rharper> slangasek: I don't know for certain; let me read a bit more
<slangasek> rharper: ok.  As far as I'm concerned systemd-resolved should not have to be running before network-online.target
<slangasek> i.e. it's not a requirement for DNS resolution - but we might choose to enforce this to work around some issue somewhere
<rharper> slangasek: going to confirm but my understanding for yak/zesty is that resolvconf is hook only;  it runs under ifupdown hook, and dhclient (which is for networking/ifupdown services);  in a networkd space, those (ifupdown) hooks don't matter; and systemd-resolved is decorated with pre/post execs to point to systemd-resolved caching namesever (127.0.0.53);
<rharper> we'll have nothing in /etc/resolv.conf prior to systemd-networkd coming up; and if that includes DNS settings, I believe those should be applied via having systemd-resolved unit run before we get to network-online.target;
<slangasek> rharper: ah.  that's an unfortunate outcome of the lack of support for hooks, yes
<slangasek> rharper: in that case, +1 for changing the ordering constraints on systemd-resolved, though I would argue it shouldn't need to hold up the resolvconf change
<rharper> slangasek: agreed;  it's been a bit sticky to separate the networking/ifupdown path vs. systemd path since we don't have a non-ifupdown path by default
<rharper> the verification has been a matrix of xenial, yakkety * ifupdown/networking,networkd
<rharper>  * the two packages involved (systemd and resolvconf)
<rharper> and forgetting all of those parts from time to time
 * slangasek nods
<nacc> slangasek: Just to confirm, I need a FFe for the fix for LP: #1668940, where we are not b-d on a library that provides the headers needed to build the .so in question -- even though we ship a manpage documenting the feature? That is, it's a feature introduction in practice?
<ubottu> Launchpad bug 1668940 in samba (Ubuntu) "samba-vfs-modules misses ceph vfs module" [Medium,Triaged] https://launchpad.net/bugs/1668940
<slangasek> nacc: yeah, I would say that should get a look-sie for an FFe
<smoser> hey. in zesty, the libc6-x32 is supposed to "just work" for 32 bit libc stuff ?
<smoser> i have a executable that works on 32 bit.
<smoser>  $ ldd /usr/bin/brprintconf_mfc9125cn	linux-gate.so.1 =>  (0xb770d000)
<smoser> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7548000)
<smoser> 	/lib/ld-linux.so.2 (0x8006d000)
<slangasek> smoser: libc6-x32 is for x32 binaries, of which there are approximately zero in the wild
<smoser> oh. well, yeah. that'd do it.
<slangasek> you preferably want to install libc6:i386 (multiarch cross-install of the i386-arch package)
<smoser> i was hoping to avoid i386 packages. and i thiought that might e what that was.
<smoser> i just dont want to add the 32 bit arch to dpkg.
<smoser> well, libc6-i386 worked for me.
<smoser> and didn't need foreign arch
<smoser> slangasek, my cloud-init uploads are back in the xenial and yakkety queue now.
<jgrimm> \o/
<nacc> slangasek: ack, thank you!
<nacc> rbasak: would you be able to review: LP: #1669831 ?
<ubottu> Launchpad bug 1669831 in mysql-5.7 (Ubuntu) "package mysql-server 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: Ð¿ÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ð·Ð°Ð²Ð¸ÑÐ¸Ð¼Ð¾ÑÑÐµÐ¹ â Ð¾ÑÑÐ°Ð²Ð»ÑÐµÐ¼ Ð½Ðµ Ð½Ð°ÑÑÑÐ¾ÐµÐ½Ð½ÑÐ¼" [Undecided,New] https://launchpad.net/bugs/1669831
<sarnold> rbasak: <3 1610765 :)
<nacc> sarnold: ah thanks!
#ubuntu-devel 2017-03-07
<nacc> mdeslaur: i believe LP: #1669764 is now fix-committed for zesty (it's in z-p)
<ubottu> Launchpad bug 1669764 in munin (Ubuntu) "security update spams log file" [Undecided,New] https://launchpad.net/bugs/1669764
<tinoco> could someone review LP: #1670659 and close it as won't fix if agrees to same conclusion ?
<ubottu> Launchpad bug 1670659 in libvirt (Ubuntu) "Libvirt can crash on lack of memory when starting multiple instances" [Undecided,New] https://launchpad.net/bugs/1670659
<cpaelzer> tinoco: here
 * cpaelzer reading
<tinoco> cpaelzer: o/ tks
<cpaelzer> tinoco: so you reported, nominated and want me to close - and all that in 19 minutes :-)
<cpaelzer> tinoco: I guess this is just a dump of work you already did right?
<tinoco> cpaelzer: yep, took me 2 hours yesterday
<tinoco> but to review is just follow the idea
<tinoco> cpaelzer: unfortunately its not "so good" because of line breaks, maybe its best to download txt from comment
<tinoco> for the comments on every stack frame
<cpaelzer> tinoco: I think download as text is only for long posts
<cpaelzer> but I can of course copy and read
<tinoco> cool. i had to understand libvirt logic for the monitor logging and its abstraction and all (for fun)
<tinoco> but the main idea is pretty simple, you will see
<tinoco> ill wait you
<cpaelzer> tinoco: I'm with you and commented as well as updated the status
<cpaelzer> tinoco: I've set some traps for optional extra work that you can opt-in or not however you want
<tinoco> cpaelzer: checking
 * cpaelzer <- bad hunter setting traps and warning about it
<tinoco> cpaelzer: nice, ill get the apport cmds to show people how to check that was the error
<tinoco> cpaelzer: tku very much for the review =)
<cpaelzer> tinoco: there is a very similar discussion in the STS channel, you might have the first user of that script "at home" for you
<viral_mutant> I am creating a DEB package. The config files in the package are always being created with 644 permissions. I am tring override_dh_install , install -D -m 0640, but that doesnât seem to work
<viral_mutant> where can I find the documentation for this ?
<cjwatson> viral_mutant: Start by running the build with DH_VERBOSE=1 to see exactly what is operating on that file.
<cjwatson> viral_mutant: But it's almost certainly dh_fixperms.
<viral_mutant> cjwatson: meaning fixperms is modifying the perms ?
<cjwatson> viral_mutant: That would be my guess.
<viral_mutant> cjwatson: oh, that is the default for conf files ?
<cjwatson> viral_mutant: There's generally not much point in having non-world-readable files be shipped by a package, since the packages themselves are usually available on the internet.  But you can write an override_dh_fixperms target if you have a good reason to make a different decision.
<cjwatson> viral_mutant: dh_fixperms makes everything world-readable, with only a few exceptions.
<cjwatson>         complex_doit("find $tmp ! -type l $find_options -print0",
<cjwatson>                 "2>/dev/null | xargs -0r chmod go=rX,u+rw,a-s");
<cjwatson> (there's a bunch more stuff in there, but I expect that's the relevant bit)
<viral_mutant> ok, that is what is within fixperms ?
<viral_mutant> I could not locate any specific chmod on my conf after the verbose output
<viral_mutant> cjwatson: yes got it. It was indeed the code snippet you pasted
<viral_mutant> cjwatson: how do I override it ?
<cjwatson> viral_mutant: do you know how to write debhelper override rules in general?
<viral_mutant> yes
<viral_mutant> cjwatson: using -X option with dh_fixperms ?
<cjwatson> viral_mutant: Yes, that would work fine.
<viral_mutant> cjwatson: it would need just the conf file name or the complete path ?
<cjwatson> man dh_fixperms
<cjwatson> "Exclude files that contain item anywhere in their filename from having their permissions changed."
<cjwatson> You can also do something like this if you need more flexibility:
<cjwatson> override_dh_fixperms:
<cjwatson>         dh_fixperms
<cjwatson>         chmod ...
<viral_mutant> also put in the chown in there ?
<cjwatson> You didn't mention that before, but sure, if you need to.
<cjwatson> A chown will only work sensibly if it's a user with a static ID; if it's dynamic, you'll need to do that in the maintainer scripts instead.
<viral_mutant> I am creating the user in preinst with static ID
<viral_mutant> but that seems to work fine with the install -o -g options
<viral_mutant> only the -m is being disturbed by fixperms
<viral_mutant> BTW, since I new to deb packaging, what is maintainer script ? Where should I look for documentation around the install options etc. ?
<viral_mutant> is the post/pre inst/rm called the maintainer script ?
<cjwatson> viral_mutant: It sounds like you're doing user creation wrongly, from your description.
<cjwatson> viral_mutant: Can you go into more detail about what you're doing?
<cjwatson> viral_mutant: Maintainer scripts are described in the policy manual; indeed, it's the collective term for {pre,post}{inst,rm}
<rbasak> If a maintainer script fails because PATH isn't set sensibly, is that a maintainer script bug for relying on PATH? Or is that a reasonable assumption to make?
<rbasak> /usr/bin I think.
<cjwatson> rbasak: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1
<cjwatson> "Those programs, and any other program that one would expect to be in the PATH, should thus be invoked without an absolute pathname."
<rbasak> Thanks!
<rbasak> I was looking at the policy document but failed to find that part.
<rbasak> nacc: so that's my answer for bug 1669831
<ubottu> bug 1669831 in mysql-5.7 (Ubuntu) "package mysql-server 5.7.17-0ubuntu0.16.04.1 failed to install/upgrade: Ð¿ÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ð·Ð°Ð²Ð¸ÑÐ¸Ð¼Ð¾ÑÑÐµÐ¹ â Ð¾ÑÑÐ°Ð²Ð»ÑÐµÐ¼ Ð½Ðµ Ð½Ð°ÑÑÑÐ¾ÐµÐ½Ð½ÑÐ¼" [Undecided,Incomplete] https://launchpad.net/bugs/1669831
<rbasak> nacc: so wrt. 1aa0f46 in usd-importer, something I learned from the Launchpad team is to not try too hard to line things up after the brackets on a following line, as things tend to get pushed too far to the right. Instead, you can newline and single further indent straight after the '(', and then close ')' on another line afterwards. Looks nicer IMHO, so I thought I'd mention it. Not that I'm
<rbasak> insisting on it or anything, just a suggestion.
<rbasak> Although the only thing I haven't figured with that kind of thing is what to do in a long 'if' or 'for' statement, since then you need an additional indent, and things get confusing. I have never figured out a style I both like and that keeps the pep8 tool happy.
<viral_mutant> cjwatson: I am creating deb package for openstack-swift. I am using our RHEL package as references
<viral_mutant> In the preinst, creating âswiftâ user and group using âaddgroupâ and âadduserâ command
<rbasak> viral_mutant: you know we already have swift packaged, right?
<rbasak> Along with the rest of OpenStack?
<viral_mutant> rbasak: yes
<viral_mutant> The preinst also creates /etc/swift directory and sets âswiftâ as owner. The addgroup and adduser is with specific UID/GID.In the rules files override for dh_install puts the conf files in /etc/swift directory with -o -g as âswiftâ and -m640
<viral_mutant> this 640 is what was not working for me
<viral_mutant> cjwatson: you mentioned that I might be wrongly doing user creation ?
<cjwatson> If you're using dynamic IDs, then there's no guarantee that they'll be present when debian/rules runs, or have the same ID on the installed system.  I forget exactly what happens in the latter case.
<cjwatson> (It may work - I suspect .debs store ownership by name.  But there's still the former problem.)
<cjwatson> You should look at what the existing Ubuntu swift packages do here.
<cjwatson> I have no idea exactly what they do, but it probably has the benefit of working :-)
<viral_mutant> cjwatson: yes, I will surely look into the Ubuntu debian/ dir for reference. Thanks for your help, it really solved some issues in deb installation :)
<viral_mutant> rbasak: We have a forked out code from Openstack community and lot of changes going in. So I cannot use Ubuntu packages. I have been assigned the humongous task to build our own DEB packages from the code :(
<bdmurray> xnox: In bug 1668802 you mention "jounal files" are those things that already show up in apport bug reports in Launchpad? If so what are they called? JournalErrors.txt? journal.txt?
<ubottu> bug 1668802 in systemd (Ubuntu) "/lib/systemd/systemd-journald:6:journal_file_entry_array_n_items:link_entry_into_array:journal_file_link_entry:journal_file_append_entry_internal:journal_file_append_entry" [Undecided,Incomplete] https://launchpad.net/bugs/1668802
<xnox> bdmurray, when you say "apport bugreports" which ones do you? apart from this launchpad bug report, i don't see any others.
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1619844
<ubottu> Launchpad bug 1619844 in systemd (Ubuntu) "[Xenial] shutdown/reboot hangs at "Reached target Shutdown"" [Critical,Confirmed]
<xnox> JournalErrors.txt is already parsed text output which is sans corrupt entries, i'm interested in raw /var/log/journal/*/* files
<xnox> raw, because it would include everything, not just error/warning messages.
<bdmurray> xnox: In that bug report some stuff is collected by apport and makes it to Launchpad, but doesn't end up at errors.ubuntu.com. We could change that if it would help.
<bdmurray> change that by either modifying the apport package hook for systemd or allowing whoopsie to upload already existing info in the report to errors
<xnox> although it's hard to get those logs, if the logger itself is what is crashing (journal logs & journald) =))))))
<bdmurray> xnox: I don't feel like that's an answer. Is there something we can do to get you the log files you need?
<xnox> bdmurray, ideally we should be attaching all of /var/log/journal/*/* and /run/log/journal/*/* but it may be sensitive info; and can span multiple boots.
<xnox> files themself; not the parsed output from $ journalctl
<xnox> unrelated to that studied the logs on the shutdown/reboot hangs bug report and responded to it.
<Laney> yeah not sure about that
<Laney> the journal often contains a super lot of stuff
<Laney> for me information about my mailboxes, and hints to my browsing history
<bluefoxxx> http://pastebin.com/tdW1gRi9 This has been happening for the past few days
<bluefoxxx> on yakkity
<bluefoxxx> wtf
<bluefoxxx> it happens if I install cups, but no hash mismatch if I install just the libgssapi3-heimdal package itself
<bluefoxxx> COMPUTERS DON'T WORK THAT WAY.
<freedwhayt> Hello, where is the apt PGP key in Ubuntu LiveCD? Thank you.
<sarnold> freedwhayt: dunno about the live-cd. apt uses /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/
<sarnold> freedwhayt: the 4096 bit RSA key has fingerprint "790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32" -- other keys are listed at https://wiki.ubuntu.com/SecurityTeam/FAQ#GPG_Keys_used_by_Ubuntu
<freedwhayt> sarnold: Thank you for the hint I will do my best do decipher it.
<mdeslaur> ogra_: did you just modify the tech board meeting on purpose?
<Unit193> http://dev.deluge-torrent.org/wiki/ReleaseNotes/1.3.14: "WebUI users: Highly recommended to upgrade to this release as it contains a fix for CSRF vulnerability that has the real potential to compromise your machine."  that sounds fun.
<tdaitx> slangasek, I have updated LP: #1637239 in case you want to sponsor that merge
<ubottu> Launchpad bug 1637239 in ncurses (Ubuntu) "Please merge ncurses 6.0+20161126-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1637239
<bdmurray> xnox: Have you had a chance to look at the apport autopkgtest apt issue?
#ubuntu-devel 2017-03-08
<nacc> bdmurray: where does 'DpkgHistoryLog.txt' come from normally?
<nacc> bdmurray: as in what file from the local user's system, or what command generates it?
<nacc> slangasek: i was collecting/perusing the bugs we've gotten on php7.0 with failed upgrades. I think in all cases where we see the debconf backtrace ("Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66"), the invocation is from aptdaemon and running apt manually at the terminal fixes it. Is aptdaemon used only by update-manager? Or is it used
<nacc> eventually by all of the various tools?
<slangasek> nacc: only by update-manager
<nacc> slangasek: ok, good to know
<slangasek> maybe some other GUI frontends, but certainly not from apt on cli
<nacc> slangasek: i tried to reproduce it in a VM and I was unable to in a few attempts, so i'm just trying to think of different approaches
<slangasek> I seem to regularly hit it here on my laptop whenever I apply updates but have not had the patience to debug it
<nacc> slangasek: ok, that's good to know -- and do you see it for multiple packages? I can leave this VM around and see if it triggers it eventually
<slangasek> nacc: I see it for any package that uses debconf in its maintainer scripts, regardless of whether that would have triggered a debconf prompt to be displayed.
<nacc> slangasek: interesting
<slangasek> this includes kernel upgrades :P
<slangasek> (which is why I don't have much patience for debugging it)
<nacc> slangasek: and that would correspond to what we see as this seems to trigger for some people on the MRE SRUs, where no debconf prompts should occur
<bdmurray> nacc:  $ grep DpkgHistory /usr/share/apport/package-hooks/*
<bdmurray> nacc: /var/log/apt/history.log so its incorrectly labelled
<nacc> bdmurray: thanks!
<cpaelzer> good morning
<rbasak> o/
<ogra_> mdeslaur, i didnt modify anything on purpose, what happened ?
<rbasak> chrisccoulson: any opinion on bug 1632870 please?
<ubottu> bug 1632870 in pepperflashplugin-nonfree (Ubuntu Yakkety) "Package is broken since Google stopped shipping Flash with Chrome 54 for Linux" [High,In progress] https://launchpad.net/bugs/1632870
<cpaelzer> rbasak: I was reading the bug you linked and I'm puzzled
<cpaelzer> rbasak: I think I get all what was outlined there on pepperflashplugin-nonfree vs partner based adobe-flashplugin
<cpaelzer> rbasak: but I'm missing one bit (surely out of ignorance on the history of flash plugins)
<cpaelzer> rbasak: but what I did for years is install flashplugin-installer - how does that fit into the puzzle there?
<cpaelzer> note: I'm still reading through all the length of this
<cpaelzer> if it is down somewhere
<cpaelzer> rbasak: found it at about 60% of the bug - that is from ubuntu-restricted-addons
<cpaelzer> rbasak: wow, that is a complex maze in this bug - your current question is for your SRU duty to consider accepting them into proposed or not?
<LocutusOfBorg> pitti, hi, sync systemd from experimental? :p
<LocutusOfBorg> btw seems that you are fixing the autopkgtest failures, right? I see activity con git
<rbasak> cpaelzer: yeah, I thought chrisccoulson might be an appropriate person to review or comment as he usually uploads adobe-flashplugin.
<rbasak> But it does look entirely appropriate for an SRU to me. We shipped the package, it's broken, we should fix it.
<rbasak> And decisions about what to recommend or remove should probably be limited to the development release.
<rbasak> (where possible)
<cpaelzer> rbasak: yeah my opinion (very unimportant) would also to fix it especially as it is a security issue
<cpaelzer> rbasak: removing in relase - no-no, removing in zesty or later devel maybe, but even there I don't see the full reason
<cpaelzer> rbasak: there are more things which have multiple possible implementations
<rbasak> Thanks. I'm definitely +1 on fixing it. I'm asking chrisccoulson in case he has any comment or suggestion on the approach taken.
<cpaelzer> rbasak: OTOH (for the furture removal in devel) I agree that a removal might simplify this mess at least a bit
<rbasak> Because as you point out, it's a pretty complex area right now :-/
<cjwatson> jbicha: thanks for the icoutils sync - had been going to do that this morning :)
<cpaelzer> rbasak: sure, waiting for chrisccoulson is better
<cpaelzer> rbasak: yet I didn't want to leave your open question for opinions end up totally unconsidered :-)
<pitti> LocutusOfBorg: I won't sync it for zesty (feature freeze); if someone wants it and wants to do the FFE, be my guest of course :)
<pitti> LocutusOfBorg: I'm only aware of the root-unittests failure on armhf, talked about that with xnox yesterday (no hw access any more, so can't reproduce/investigate myself)
<mdeslaur> ogra_: our techboard meeting keeps getting modified when people modify other meetings on the phone
<mdeslaur> ogra_: I assume you meant to modify something else
<chrisccoulson> rbasak, I don't really have an opinion on pepperflashplugin-nonfree, and that bug is quite long (I've not read the whole thing)
<chrisccoulson> ideally the package wouldn't exist at all (flashplugin-installer exists so that ubuntu-restricted-addons can recommend it)
<rbasak> chrisccoulson: that's fine, thank you for looking. I just wanted to check if you had an opinion :)
<rbasak> chrisccoulson: OOI, how do adobe-flashplugin and flashplugin-installer fit together?
<chrisccoulson> in fact, I think it's fairly bad that we have a flash plugin installer in the archive that requires users run a command outside of the normal update process to upgrade it
<rbasak> I wasn't clear on why that is.
<chrisccoulson> I wonder whether I should just add the ppapi plugin to flashplugin-installer - it has to download it anyway
<tjaalton> doko: llvm 4 & snapshot ftbfs on powerpc, but build fine on debian.. https://launchpadlibrarian.net/305798779/buildlog_ubuntu-zesty-powerpc.llvm-toolchain-4.0_1%3A4.0~+rc2-1_BUILDING.txt.gz
<tjaalton> doko: any ideas if it's a bug in llvm or something else?
<doko> tjaalton: no, I didn't look. and we'll drop powerpc this cycle
<doko> should have happened in Feb afaik
<tjaalton> ahh
<tjaalton> ok
<tjaalton> forgot about that
<handsome_feng> jbicha, hi, what do you mean by tagged the wrong commit? The last commit is "Remove the debian/ directory" in ukui-menu.
<jbicha> handsome_feng: hi!
<jbicha> https://github.com/ukui/ukui-menu/releases shows that you tagged 0f027ad but that's not the last commit
<jbicha> https://github.com/ukui/ukui-menu/commits/master
<handsome_feng> I remove the previous releases and update it, since it has the same tag "v1.0.0", and then it shows 10 commits to master since this release...
<jbicha> handsome_feng: you could use a new tag like 1.0.1?
<handsome_feng> jbicha, I have updated the release just now, :)
<jbicha> handsome_feng: thanks, can I upload to zesty from https://github.com/ukui/debian-packages/tree/master/ukui-menu/debian now?
<handsome_feng> jbicha: sure! thank you!
<jackpot51> cyphermox: jbicha: happyaron: Can we talk about the patch to network-manager-applet? It is a single line change to src/libnma/Makefile.am which fixes the ability to use libnma from Python
<cyphermox> jackpot51: don't need to discuss this, let's jfdi ;)
<jackpot51> awesome - then Zesty's installer won't crash for students at university, or corporate customers
<jackpot51> XD
<cyphermox> well, it already shouldn't crash, no?
<jackpot51> It crashes on any WPA 2 enterprise network
<jackpot51> My patch to ubiquity fixes that crash by implementing WPA 2 enterprise
<cyphermox> afaik that doesn't crash, it just doesn't work
<cyphermox> (well, it doesn't work if you try to use the network panel in ubiquity, you already could use nm-applet directly instead
<jackpot51> It will say something like "Installer has crashed. Entering recovery mode" and then go to a desktop
<cyphermox> ok
<jackpot51> There is no try...except around connecting to the Wifi network, so a DbusException from network manager is uncaught
<jackpot51> My patch adds the try..except block in the gtk and kde components, as well as using libnma to support WPA 2 enterprise in gtk components
<jackpot51> Line 63 here: https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu-applet/tree/src/libnma/Makefile.am#n63
<jackpot51> Needs to change to this: NMA_1_0_gir_INCLUDES = NM-1.0 Gtk-3.0
<jackpot51> cyphermox: What do I need to do to "jfdi"? :P
<cyphermox> nothing, I have your patch I'll upload it
<jackpot51> Thanks very much!
<jbicha> cyphermox: thanks
<spacebear> hi is their any ubuntu devs around
<dobey> usually, that's what this channel is
<spacebear> I've been directed to the right place ty
<salty-horse> hey. ibus seems broken in zesty (can't switch back from layout after changing it). is it officially being phased out?
<jbicha> salty-horse: no
<salty-horse> jbicha, is any integration done by ubuntu developers, or should I take it up with the ibus team?
<jbicha> salty-horse: start with a Launchpad bug, but if you think the issue is upstream you can try talking to them too
<nacc> rbasak: found a few issues with the -devel pointer changes, testing them now
<nacc> slangasek: been doing some digging, cjwatson's comment 10 in LP: #500175 is interesting
<ubottu> Launchpad bug 500175 in software-center (Ubuntu) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [Medium,Confirmed] https://launchpad.net/bugs/500175
<nacc> i think it's the most detailed analysis i've found so far
<nacc> cjwatson: in case you're interested, context is LP: #1597001 and several php7.0 bugs with the same symptom (all using update-manager)
<ubottu> Launchpad bug 1597001 in linux (Ubuntu) "package linux-image-4.4.0-28-generic (not installed) failed to install/upgrade: subprocess new pre-installation script returned error exit status 128" [Medium,Confirmed] https://launchpad.net/bugs/1597001
<nacc> rbasak: awesome, so nice to be able to verify i didn't break anything by my fixed changes now
<nacc> rbasak: so i just compared a from-scratch import of tftp-hpa to what is already pushed by you
<nacc> rbasak: all the series branches match and the devel pointers are different (because they now have a merge-based history)
#ubuntu-devel 2017-03-09
<happyaron> jackpot51, cyphermox, just saw your discussions, and thank you!
<pitti> robru: britney email> niiiiice!
<pitti> robru: does this use REJECTED_TEMPORARILY vs. _PERMANENTLY, so that it doesn't spam on large queue lagging?
<rbasak> nacc: nice!
<Laney> pitti: what's large queue lagging?
<Laney> The policy uses PASS actually as it doesn't itself reject any items
<pitti> Laney: I mean if a package is waiting for test results for more than a day
<pitti> and temporarily vs. permanently is meant for telling these cases apart
<pitti> "known broken" vs. "the machine is still working"
<Laney> I don't think policies have access to the current verdict, do they?
<Laney> it just looks at is_valid
<pitti> Laney: ah, maybe; honestly I forgot the details
<Laney> I guess it would be possible to add it in there though
<Laney> indeed I think it would email in that case
<pitti> maybe generalizing is_valid to current_verdict might not be too hard
<pitti> hmm, but would require changing the Policy API
<Laney> you could probably put it as an attribute on the excuse
<pitti> in britney.py we already have that as "policy_verdict", we just don't pass it into apply_policy()
<Laney> right, but API break as you say
<Laney> so just stuff it into something which already goes into the function
<Laney> I think I'll probably merge this (modulo code review) and file a bug for improvement in the future
 * Laney is making it do a dry run for the first couple of runs too
<pitti> Laney: oh right, maybe just excuse.current_verdict, as an extension (or even better, replacement) to exuse.is_valid
<pitti> Laney: but aside from that, nice work
<Laney> pitti: it's robru's work; I'm just reviewing/merging :)
<Laney> trying to find out how the config generation happens so I can enable it for the dev release only
<Laney> oho, it's in britney1
 * Laney dies slightly
<pitti> one can never have enough britneys
<bregma> tjaalton, is the plan to land x.org 1.19 in Zesty?
<tjaalton> bregma: yes, it's on ppa:canonical-x/x-staging now
<tjaalton> just finished pushing all the drivers
<tjaalton> and upgrading my laptop :P
<bregma> tjaalton, OK, thanks... so far works OK on my laptop sans a few dependency issues when installing (I assume those were fixed)
<tjaalton> what issues? needed dist-upgrade, cirrus and mga probably got removed which is fine
<tjaalton> ooh, someone fixed n-m, my indicator shows the wifi status & networks again
<bregma> tjaalton, when I did a dist-upgrade, it wanted to remove unity8 because of some kind of Qt-related dependency chain; I didn't follow up but I'll retest with the x-staging package
<tjaalton> ah
<tjaalton> ok
<tjaalton> was fine here
 * bregma hums as he run apt update
<bregma> tjaalton, confirmed the package in x-staging has my earlier dependency problems fixed, so no worries
<tjaalton> ok, cool
<xnox> slangasek, is /etc/default/rcS:FSCKFIX=yes at all still in use?
<xnox> it seems to have only affect init.d scripts; which are all masked by systemd
<xnox> and it does not propagate into the initramfs
<jbicha> xnox: https://github.com/debops/ansible-console/issues/39
<xnox> jbicha, hm.
<xnox> slangasek, jbicha: in _xenial_ FSCKFIX= appears to be present in /etc/default/rcS but is it really used?! =) i don't think so, or I am failing to trace that.
<sil2100> pitti, Laney: hey guys! Sorry to bother you but I have an autopkgtest-infra related question - is there any way I could 'fetch' the info about how the autopkgtest for the given package has been run from inside the autopkgtest?
<pitti> sil2100: it's in one of the first lines of the log
<sil2100> pitti: but can I get it somehow from inside the test?
<sil2100> Like, is that somehow exported in the environment of the test or something?
<pitti> e. g. if you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/c/conjure-up/20170309_034802_8947b@/log.gz
<pitti> sil2100: no, it's not
<pitti> the --env variables are, of course
<pitti> but most everything else shouldn't concern the test itself
<pitti> you can determine the type of testbed, release, etc. easily yourself too
<sil2100> AH HA!
<pitti> but the autopkgtest CLI isn't an API for tests -- e. g. it did change quite dramatically with 4.0
<sil2100> pitti: \o/
<sil2100> pitti: you just saved my life, I just noticed that a very useful thing that I needed is actually appended as --env
<sil2100> Thanks!
<pitti> sil2100: the trigger?
<Laney> you want to do something like tell if you're running from a PR?
<sil2100> I'm working on the u-i autopkgtest thingy and I needed the PR number that the test was executed for
<sil2100> And I see now --env=UPSTREAM_PULL_REQUEST=123
<pitti> sil2100: ah, yes -- I'm doing the same for systemd
<sil2100> Awesome
<pitti> sil2100: see https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Preparing_the_test
<pitti> sil2100: this has some other things to consider too
 * sil2100 hugs pitti 
 * pitti hugs sil2100 back
<Laney> pitti: hm, where does TEST_UPSTREAM come from? I don't see that in ubuntu-image's --env
<Laney> is that in the configuration on the github side?
<Laney> looks like it
<Laney> nm
<pitti> yes, that's set in the webhook
<pitti> our machinery only sets $UPSTREAM_PULL_REQUEST
<mun24> I created a executable in linux. which I need to change somtimes
<mun24> so I want to send a command to executable in linux and restart itself
<mun24> how can I do that
<cjwatson> mun24: The usual idiom is to have the program install a SIGHUP handler that sets a flag, and then when the program next gets back to its main event loop it checks the flag and re-execs itself if it's set.
<cjwatson> mun24: That's hopefully enough to give you keywords that you can search for to find examples.
<mun24> thx
<mun24> program is running as a service
<cjwatson> mun24: (Note that you have to be quite careful to do as little as possible in signal handlers, hence my "just set a flag" advice.)
<slangasek> ogra_: you appear to have an Ubuntu phone which is fighting with the TB meeting events on the UES calendar; would you mind disabling syncing there?
<mapreri> mattia@warren ~ % syncpackage -s ricotz -b 1671587 vala
<mapreri> syncpackage: Blacklist Comments:
<mapreri> syncpackage:   vala 0.34.2-1 in sid (same version has unpublished binaries in the
<mapreri> syncpackage:   destination archive for Zesty, please wait for them to be published
<mapreri> syncpackage:   before copying)   -- janitor  Wed, 26 Oct 2016 10:19:44 +0000
<mapreri> syncpackage: Source vala -> zesty/Proposed: current version 0.34.5-1, new version 0.34.6-1
<mapreri> What is that comment supposed to mean?
<cjwatson> For some reason it appears that failed package copy jobs stuff the failure into a DistroSeriesDifferenceComment and then syncpackage gets confused by that ...
<cjwatson> That is fairly weird
<cjwatson> You can safely ignore it for this purpose though
<cjwatson> Don't think I can even delete them, sigh
<sarnold> cjwatson: is this cause for concern? 1671515 (a report of incorrect diff.gz download contents; I couldn't reproduce)
<cjwatson> sarnold: Certainly merits investigation, but I'm about to EOD
<cjwatson> sarnold: Could just be a bad cache
<sarnold> cjwatson: where would you suggest following up? launchpad answers?
<mapreri> cjwatson: you mean that due to some kind of failure in the past that package must stay forever in the autosync blacklist?
<cjwatson> sarnold: I suggest getting the user to be clear about which URL they tried fetching first, and whether they tried forcibly reloading / sending cache-busting HTTP headers
<mapreri> but can be manually synced anytime just fine?
<cjwatson> mapreri: I don't know for sure, finding out would require more time than I have right now.  I suspect that at least the problem will go away with the next Ubuntu series ...
<sarnold> cjwatson: thanks; enjoy your evening :)
<mapreri> cjwatson: ok, so shall I go ahead and sync that, or do you prefer if I leave it there and you will look at it?
<cjwatson> mapreri: just sync it
<mapreri> I suppose it would be easier to just forget and wait for zesty+1
<mapreri> ack, on it
<cjwatson> first time I've seen this problem so I don't expect it's very common
<bdrung_work> pitti, i saw https://www.piware.de/2011/08/apport-retrace-made-useful/
<bdrung_work> pitti, i would like to use apport-retrace for our internal infrastructure (but without apport itself). we only have the coredumps and a list of installed packages with versions.
<bdrung_work> could apport-retrace made work with that?
<tdaitx> wgrant, I was told you could help me on this minor nitpick: the pts link from qa.ubuntuwire.com/ftbfs/ links to packages.qa.debian.org and that page suggests that tracker.debian.org should be used instead, I wonder if there is any reason for that (I'm not that familiar with the "old" debian pts)
<tdaitx> on a second note, I tried to access the "source" link in the bottom of ubuntu's ftbfs (to see what would be required to update that link) but then I get a 403
<dobey> anyond around familiar with proposed-migration?
<Laney> dobey: For some unknown reason ubuntu-touch depends on the versioned gir1.2-ubuntu-app-launch-2 package and the new ubuntu-app-launch doesn't produce such a package any more
 * Laney guesses what you wanted to know
<dobey> oh
<dobey> i wonder why the upload last week migrated then
<dobey> Laney: can you upload a new ubuntu-meta with that dropped from ubuntu-touch?
<Laney> dropped or updated?
<dobey> Laney: i don't know any reason that it needs to be in the ubuntu-touch seed. only autopilot depends on it, which isn't seeded, and should pull it in when autopilot gets installed. so i'd say dropped
<Laney> dobey: some attempt to provide a platform API maybe?
<dobey> Laney: i'm pretty sure the only reason it was seeded was for autopilot on the phone, because running autopilot on the phone used to need things pre-installed
<Laney> ok
<Laney> it's in a "Utils" section so that sounds reasonable
<Laney> weird though, I don't see why it migrated last time
<Laney> must have traded off somehow but no mention of that in the log
<Laney> maybe that's normal
<dobey> yeah, no idea
<slangasek> Laney: doesn't appear that a previous abi of gir1.2-ubuntu-app-launch was ever seeded before?
<Laney> slangasek: ubuntu-touch.zesty touch-core
<slangasek> gir1.2-ubuntu-app-launch-2 is in the seed, exists in zesty; gir1.2-ubuntu-app-launch-3 is the new one in zesty-proposed
<Laney> right
<slangasek> so there was never any previous "trade off"
<Laney> so how did the old one migrate?
<Laney> dobey says that one had 3
<slangasek> ah
<dobey> yeah, the -3 was added last week
<slangasek> NBS and lack of cleanup
<slangasek> something has changed now that makes the old gir1.2-ubuntu-app-launch-2 uninstallable
 * slangasek handwaves based on first principles without looking to see what
<dobey> anyway, no reason for the gir to be seeded any more, afaict
<dobey> so let's drop it
<Laney> that breaks my understanding of how britney works for us
<Laney> but whatever :P
<dobey> heh
<dobey> i won't even pretend to understand how britney works
<slangasek> Laney: "for us"?  we're using near-upstream code now, including support for partial transitions that will let new libs in alongside old provided any given package is individually installable
<Laney> slangasek: That's smooth updates, right? I thought we weren't doing that
<slangasek> Laney: I'm not aware that we had configured britney not to do it... and update_output.txt certainly shows evidence of this being done
<slangasek> maybe that's a misconfiguration, or maybe that's something that happened when pitti rebased
<Laney> # naming a non-existent section will effectively disable new smooth
<Laney> # updates but still allow removals to occur
<Laney> SMOOTH_UPDATES    = badgers
<slangasek> heh
<Laney> dobey: it's uploaded
<dobey> Laney: thanks!
<dobey> hopefully it'll migrate now :)
<Laney> huh, THANKS proposed-migration for emailing me
<Laney> oh yeah, I had already noticed and then forgot about that problem, nothing to do atm
 * Laney 's conscience is clean
<dobey> hmm, i wonder where the upload went
<dobey> don't see it on launchpad or in britney yet :-/
<Laney> dobey: it went in now
<dobey> Laney: ok, thanks
<dobey> ah was looking at ubuntu-meta instead of ubuntu-touch-meta
#ubuntu-devel 2017-03-10
<pitti> bdrung_work: I suppose you could use python3-apport or a tool of your own to construct a .crash file with the data you have
<pitti> bdrung_work: it doesn't require ProcMaps and other bits, but it does require the exact ExecutablePath
<bdrung_work> pitti, thanks. i will have a look at python3-apport. how does apport get the ExecutablePath?
<pitti> bdrung_work: readlink /proc/<pid>/exe
<pitti> bdrung_work: there's some extra magic that it does for interpreters though
<pitti> bdrung_work: i. e. if ExePath is /bin/sh, /usr/bin/python and so on, it dissects teh command line instead to find the "real" program (i. e. the script)
<pitti> if that's not an use case for you, you can ignore that
<pitti> you won't need it for retracing indeed, this is just for filing correctly targetted bug reports
<bdrung_work> interpreter are not our issue
<bdrung_work> pitti, which file format is the apport crash file?
<pitti> bdrung_work: essentially RFC-822, see http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/doc/data-format.tex
<pitti> bdrung_work: if you can use python3, it's easier to use apport.Report(), this is more or less a dictionary with a write() method to spit out the .crash file format
<bdrung_work> pitti, is there a rendered version of that tex file?
<pitti> I was meaning to ship the PDF in apport, but apparently I missed to package it
<pitti> bdrung_work: http://piware.de/tmp/data-format.pdf
<bdrung_work> i can (and prefer) to use python3 for retracing, but the host (where the crash happens) should be kept simple. we use this script (or at least something similar): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857300
<ubottu> Debian bug 857300 in makedumpfile "makedumpfile: Please add a dump-core script" [Wishlist,Open]
<pitti> bdrung_work: look at the various /usr/share/aport/ scripts like gcc_ice_hook or kernel_crashdump for examples how to use the api to generate .crash files
<bdrung_work> pitti, what exactly happens when the kernel crashes (regarding the workflow with apport)?
<bdrung_work> we have the contrain that the servers do not have a disk
<pitti> bdrung_work: it calls /usr/share/apport/apport like in /proc/sys/kernel/core_pattern, see man core(5)
<pitti> and feeds the core dump to its stdin
<pitti> and apport then creates an apport.Report(), sets the report['CoreDump'] to stdin, and adds a few other fields from /proc and its CLI arguments (pid and signal number mostly)
<bdrung_work> pitti, /usr/share/apport/apport looks interesting. the missing bits for our use case is support for directly uploading the coredump
<bdrung_work> since the whole system runs on tmpfs
<pitti> mount a tmpfs on /var/crash? :-)
<bdrung_work> that needs ram too.
<pitti> processing a core dump needs a lot of ram
<pitti> with pipelining it directly to a remote server it might work better, but you probably want to do the .crash file assembly on the server then
<pitti> (still need to compress the core dump in the pipeline)
<bdrung_work> i know. that is why set /proc/sys/kernel/core_pattern to pipe to a core-dump script that pipes stdin into a compression into a busybox ftpput
<bdrung_work> i would want to have the .crash metadata in a separate file
<bdrung_work> then upload the metadata first and then pipe the compressed dump
<pitti> ah, so replace CoreDump: in the local .crash file with some identifier that relates it to the ftpput, so that you can match it up on the server?
<pitti> or CoreDumpID:
<bdrung_work> yes. thinking of CoreDumpFile: foo-20170310.lz4
<bdrung_work> the file will be in the same place
<pitti> bdrung_work: I suggest using gzip, then you don't need to uncompress/recompress on the server
<bdrung_work> gzip is too slow
<bdrung_work> and the retrace would happen on a different host
<bdrung_work> can gdb work with a gzipped crash dump?
<pitti> no
<pitti> it mmaps, so apport-retrace always unpacks it first
<acheronuk> odd http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#rocs
<acheronuk> virtual memory exhausted: Cannot allocate memory
<acheronuk> on amd64
<acheronuk> and on ppc64el
<acheronuk> dotgrammar.cpp
<acheronuk> c++: internal compiler error: Killed (program cc1plus)
<acheronuk> only on the autopkgtest rebuilds. builds fine normally
<pitti> probably needs to be added to bigtests
<Laney> take the opportunity to figure out how to not have to rebuild the whole thing each time
<acheronuk> pitti: to me? that allocates extra resources?
<pitti> yes, that needs to be added to Ubuntu's CI config
<pitti> but yes, if you can't build that with 1 GB of RAM, that's a bit evil :)
<acheronuk> hmmm. longstanding issue it seems: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730170
<ubottu> Debian bug 730170 in src:rocs "rocs: FTBFS: virtual memory exhausted in DotGrammar.cpp" [Important,Open]
<acheronuk> Laney: well as as far as I can see, the build at test time is not really avoidable. So could that maybe added to 'bigtests' as Martin suggested?
<Laney> acheronuk: The autopkgtests are really meant to test against the already built packages that are in the archive, and here I bet you're testing against the thing you just built.
<Laney> Perhaps you can build the tests against the system libraries, or perhaps you can ship them in a binary package like some GNOME stuff does. That would likely require some upstream work though.
<acheronuk> Laney: yes, it would require upstream changes that are likely beyond me/us to work out and submit. I get what you are saying, but this is an interesting but not core/crucial KDE app, so time/benefit there means is not going to happen I think
<Laney> acheronuk: Ok, but basically all of the KDE applications have the same problem AFAICS
<Laney> In addition to not telling you if the packages in the distro are broken, they are a serious strain on the infrastructure
<acheronuk> Laney: yeah, quite aware of that :/
<acheronuk> gotta go. thanks
<Laney> acheronuk: I put it in big_packages for you
<Laney> Some attention to the wider problems would be appreciated
<bdrung_work> pitti, do you collect just the dependencies of the package or do you also collect recommends/suggests?
<pitti> bdrung_work: backends/packaging-apt-dpkg.py get_dependencies() â Pre-Depends:, Depends:, Recommends:
<pitti> bdrung_work: normally that doesn't matter that much for retracing though, as it prefers ProcMaps
<pitti> that will skip irrelevant packages, and more importantly, also catch plugins or other dynamically loaded stuff
<pitti> but it falls back to Dependencies: if there is no ProcMaps field (for your case)
<bdrung_work> ah, cool. and how does it map from ProcMaps to the package with the debug information?
<pitti> bdrung_work: apport-retrace downloads Contents.gz for that
<pitti> and from there, try to install -dbg, or -dbgsym
<pitti> (but you need both the package and the symbols)
<bdrung_work> so with contents you can map the file to the package
<bdrung_work> how do you map the package to the -dbg or -dbgsym package?
<pitti> with string concatenation :)
<pitti> and then asking apt.Cache() if that exists
<bdrung_work> heuristics :D
<pitti> bdrung_work: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/backends/packaging-apt-dpkg.py#L672
<bdrung_work> I am collecting some more information now: http://paste.ubuntu.com/24151344/
<bdrung_work> thanks for the documentation of these fields.
<pitti> yeah, these days we migth actually use the debug links that are part of -dbgsym packages, but this was all written way before that existed
<pitti> bdrung_work: btw, apport itself doesn't collect the expensive stuff (Package:, Dependencies: etc.) at crash time
<pitti> only after you actually agree to send a report
<pitti> just the stuff that's absolutely required to collect while the process is core dumping (/proc and the core dump)
<pitti> but for automatic submission you need to do it, I agree
<bdrung_work> how do you make sure that the packages haven't been updated in the meantime?
<pitti> it compares time stamps
<pitti> but since the popup is triggered via inotify, that rarely happens
<bdrung_work> which timestamps?
<pitti> of the executable file
<bdrung_work> and what about the libraries?
<pitti> no timestamp for those
<bdrung_work> would you notice changes for them?
<pitti> (it has never been a practical problem)
<pitti> due to the inotify popups
<mdeslaur> could someone please push gnutls28 and pcsc-lite out of proposed, please? The failing tests are unrelated.
<Laney> mdeslaur: I retried them with --all-proposed, think that'll work
<mdeslaur> Laney: thanks
<Laney> (any uploader can do that, BTW)
<Laney> mmm, not for pcscada apparently
<mdeslaur> Laney: what tool do you use?
<Laney> mdeslaur: retry-autopkgtest-regressions with --all-proposed from lp:ubuntu-archive-tools
<mdeslaur> Laney: cool, thanks
<jbicha> tseliot: hi, I'm pinging again about bug 1559576, a very serious bug for Ubuntu GNOME that looks like it has a very simple fix
<ubottu> bug 1559576 in gdm3 (Ubuntu Xenial) "Ubuntu GNOME boots to black screen when using proprietary Nvidia drivers" [Critical,Triaged] https://launchpad.net/bugs/1559576
<tseliot> jbicha: yes, sorry but I've been extremely busy with other stuff
<jbicha> tseliot: ok
<bdmurray> powersj: Have you identified a patch which fixes bug 349913?
<ubottu> bug 349913 in openssh (Ubuntu) "sftp: cannot enter umlauts like Ã¤, Ã¶, Ã¼" [Medium,Fix committed] https://launchpad.net/bugs/349913
<powersj> bdmurray: not yet
<bdmurray> powersj: but you thought it was worth adding a Trusty task?
<powersj> bdmurray: sorry if I did this the wrong way, I wanted to work on the bug to fix in trusty, and wanted to assign to to myself, however since it was marked fix committed I thought adding trusty and assigning it to me would be the way to track that
<powersj> if I found the backport to be too large or crazy then could note that, otherwise work on an SRU
<bdmurray> powersj: no, adding a task if you going to assign yourself makes sense to me.
<bdmurray> powersj: there, its been approved
<powersj> bdmurray: thank you!
<cjwatson> powersj: I've suggested some likely commits in the bug, but personally I would consider this too invasive for backporting.
<cjwatson> Especially since it did go wrong.
<powersj> cjwatson: thanks for looking at it! I will happily take your advice :)
<barry> why did the recent chromium browser upgrade *again* forget all of my passwords?  this is the second or third time during zesty that it's done that.  I'm glad i haven't upgraded my other machine yet or i'd have to do password resets for every site i generate random passwords for.  now i have to pick them out of my other browser instance, but some of my passwords are loooongggg
<jackpot51> Hey guys - does anyone have a lead on Gnome Software not installing dependencies for .deb packages?
<jbicha> jackpot51: did you file a bug yet?
<jackpot51> I think https://bugs.launchpad.net/bugs/1573206
<ubottu> Launchpad bug 1573408 in gnome-software (Ubuntu Xenial) "duplicate for #1573206 GNOME Software does not install third-party .deb packages" [High,Fix released]
<jackpot51> https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1573408 says fix released, am I missing something?
<ubottu> Launchpad bug 1573408 in gnome-software (Ubuntu Xenial) "GNOME Software does not install third-party .deb packages" [High,Fix released]
<nacc> jackpot51: fix released refers to the development release at hte time
<jackpot51> Oh, hope to see it in 17.04 then
<nacc> jackpot51: oh but i see that bug also has the 16.04 task as FR
<nacc> ugh, that bug is hard to read
<ginggs> fixed in https://launchpad.net/ubuntu/+source/gnome-software/3.20.1+git20160426.1.a976144-ubuntu-xenial-0ubuntu1
<jackpot51> Thanks ginggs
<nacc> ginggs: confused, though, people kept saying they saw it after that was released?
<ginggs> maybe that release didn't really fix it, or it was subsequently broken again
<nacc> ginggs: ack, it's very unclear from the bug itself
 * nacc is glad not to really work on desktop stuff :)
<dobey> barry: ugh, really?
<dobey> barry: i don't see how it would forget passwords, since it uses gnome-keyring as the storage
<tyhicks> mwhudson: hi - the docker-in-lxd test is broken with recent lxd uploads
<tyhicks> mwhudson: you seem to be tending to that test so I wasn't sure if fixing it was something that you're already working on
<tyhicks> stgraber: it looks like lxd-bridge unit went away recently - what's the correct way to apply configuration that is manually written to /etc/default/lxd-bridge? (asking because the docker-in-lxd docker autopkgtest is stopping lxd-bridge, writing to that file, and then starting lxd-net)
<tyhicks> (I meant "and then starting lxd-bridge")
<jackpot51> nacc ginggs: I will test it again with a clean install
<nacc> tyhicks: iirc, that is now stored in the lxd database
<nacc> tyhicks: and there is a script to migrate, but fresh users don't have any /etc/default/lxd-bridge
<nacc> tyhicks: i believe this changed with `lxc network`
<jackpot51> ginggs nacc: Clean 16.10 install, Chrome installation fails silently with the Software Center
<tyhicks> nacc: ah, I'm starting to remember that now
<tyhicks> nacc: thanks!
<nacc> jackpot51: there does appear to be a version in yakkety-proposed that might be worth testing
<jackpot51> nacc: Ok, I will update, purge the half-installed google-chrome-stable, and retry
<stgraber> tyhicks: yeah, on LXD 2.3 or higher (whichever advertises the "network" extension), you should use the "lxc network ..." commands instead.
<stgraber> tyhicks: we have code that deals with that in the autopkgtest package and also deals with the new storage API from 2.9+
<stgraber> tyhicks: let me get you a link
<stgraber> tyhicks: that's the LXD test setup logic in autopkgtest: //paste.ubuntu.com/24152739/
<stgraber> *http://paste.ubuntu.com/24152739/
<nacc> jackpot51: and the i'd check the chagnelog of the yakkety-proposed one to see if it's also got a bug referring to ti
<stgraber> tyhicks: in the autopkgtest case, it doesn't bounce lxd-bridge because it knows that it's not going to be running at the time (clean setup) and so just relies on the socket activation to bring up the unit afterwards
<tyhicks> stgraber (cc mwhudson): thanks but I now see what's going on with this docker.io autopkgtest...
<tyhicks> stgraber (cc mwhudson): it already knows how to deal with `lxc network` but it doesn't know how to compare software versions
<jackpot51> nacc: Works with updates, just not with the default ISO
<stgraber> tyhicks: ah, it shouldn't compare versions, it really should check for the LXD extensions instead
<nacc> jackpot51: yes, that's sort of expected -- that is with -updates (and not -proposed0?
<tyhicks> stgraber (cc mwhudson): it thinks that version 2.10 is less than 2.2 and is going back to the old way of configuring the bridge
<nacc> jackpot51: as the we don't respin the ISO; were you using a daily?
<stgraber> tyhicks: haha, funny :)
<tyhicks> yeah :)
<stgraber> I think there was a similar but in Juju a while back
<tyhicks> the extension check is the fix - thanks!
<jackpot51> nacc: Complicated - I work for System76 so we do OEM install and keep the install image up to date. ISO failed, but our install doesn't
<nacc> jackpot51: got it!
<nacc> jackpot51: does your install image use -updates?
<nacc> jackpot51: the 16.10 ISO (release ISO) i think never gets updated
<jackpot51> nacc: Yes, the computers will ship with updates
<nacc> jackpot51: but the 16.10 daily would have updates applied (i think?)
<jackpot51> Right
<nacc> jackpot51: so it's not surprising (at least to me) that there is a bug int he release version that's later fixed
<nacc> jackpot51: same would be true of 16.04.0; but 16.04.1 (and i think 16.04.2) have the fix
<jbicha> jackpot51: if you have a good test case, please file a new bug
<jbicha> if the problem is with Google Chrome, I think I heard that there might be a problem there but I don't think there's a bug yet
<jbicha> but the original xenial "can't install a .deb" bug was fixed
<jgrimm> nacc, fwiw i have a debdiff up for the tc man page bug you pointed me at if you'd want to sponsor it. https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1668813
<ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Xenial) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress]
<jgrimm> not urgent at all
<nacc> jgrimm: ack
<nacc> jgrimm: i believe your version is incorrect?
<nacc> jgrimm: should be 4.3.0-1ubuntu3.1 ?
<jgrimm> bah
<jgrimm> nacc, i'll fix
<nacc> jgrimm: and, unfortunately, we'll need to fix yakkety too :/
<nacc> otherwise current upgrades who get the fix from xeniall will not update in yakkety
<nacc> well, i guess that's not 'fatal', but it's unexpected
<nacc> (x and y have the same version)
<jgrimm> nacc, agreed, and trivial
<jgrimm> to do
<nacc> jgrimm: yep, should be easy -- will need a bit of version love :)
<nacc> 4.3.0-1ubuntu3.16.{04,10}.1 i think
<nacc> jgrimm: also, would you mind using `dep3changelog` ?
<nacc> jgrimm: that way "Phil Sutter" gets attribution in the changelog :)
<jgrimm> nacc, apologies for not thinking through the versions, was juggling multiple things yesterday
<nacc> jgrimm: not a problem! nothing to apologize for
<jgrimm> ah, dep3changelog is new to me. cool, i was just adding based on looking a debian docs
<jgrimm> but \o/ for tooling
<nacc> jgrimm: yep! :)
<barry> dobey: yep, definitely.  maybe it's gnome-keyring that got updated and somehow zeroed out its db.  or maybe it just hates me
<dobey> barry: could be maybe the back-end in chromium got flipped to the native thing
<dobey> or something weird
 * barry votes for something weird
<barry> dobey: yeah, it's happened at least twice during zesty
<dobey> hmm
<dobey> someone should write an autopkgtest :)
<barry> ;)
<chiluk> barry is there a way to get launchpad mail for all bugs that contain a specific tag?  in my case sts-sponsor?
<chiluk> barry I only picked on you since you were last to touch the channel.
 * barry quit:
<chiluk> lol.
<barry> chiluk: i'm not sure, but there may be an option in your bugmail
<chiluk> i'll go ask in launchpad
<barry> yeah
<barry> probably best
<xnox> infinity, libc postinst hangs upgrades to yakkety when doing trusty->xenial->yakkety without rebooting
<xnox> apperantly telinit doesn't handle well, when telinit u causes one to reexec upstart into systemd
<xnox> i thought you might find it funny =) i have killed hung telinit, and continue with upgrades.
<xnox> it is a lot of fun.
<jgrimm> nacc, i'd think it would be 1:4.3.0-1ubuntu4 for yakkety, and 1:4.3.0-1ubuntu3.1 for xenial?
<jgrimm> sorry, just getting back to this finally today
<mun24> how to make ssh connection using an existing tcp/ip connection
<nacc> jgrimm: fwiw, ubuntu4 would not be typical for a released version
<nacc> jgrimm: my suggestionearlier was off of https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
 * jgrimm goes off to read. thanks
<jgrimm> nacc, ok i see. invoking the >1 release with common version. thanks.  indeed then would be 1:4.3.0-1ubuntu3.16.10.1 and 1:4.3.0-1ubuntu3.16.04.1
<nacc> jgrimm: yep
<jgrimm> i was looking for a page like that yesterday, thanks for the pointer
<nacc> jgrimm: from a review perspective, as well, it means i don't really need to check if ubuntu4 is already used or published or whatever in the devel release
<nacc> jgrimm: as those versions are so distinct
<jgrimm> indeed, i can totally see that
<nacc> jgrimm: that's on my list of things to broadcast wider in :)
<jgrimm> good cheatsheet!!
<nacc> that page, that is
<jgrimm> indeed, and dep3changelog was cute
<jgrimm> i'll definitely use that again
<nacc> yeah, it simplifies one step (IMO) and makes it repeatable
<jgrimm> +1
<jgrimm> nacc, y and x debdiffs attached to bug fwiw
<nacc> jgrimm: thanks, i'll probably review them early next week
<jgrimm> +1 no urgency at all
<Unit193> cjwatson: Have you seen https://launchpad.net/bugs/1668093?  It'd likely be pretty useful considering https://launchpad.net/bugs/1670745 (https://bugzilla.mindrot.org/show_bug.cgi?id=2692)
<ubottu> Launchpad bug 1668093 in openssh (Ubuntu Yakkety) "ssh-keygen -H corrupts already hashed entries" [High,Triaged]
<ubottu> Launchpad bug 1670745 in openssh (Ubuntu) "ssh-keyscan : bad host signature when using port option" [Undecided,New]
<ubottu> bugzilla.mindrot.org bug 2692 in ssh-keyscan "Hash does not include the port" [Minor,Resolved: fixed]
<cjwatson> Unit193: I replied to it ...
<Unit193> Well dang, I missed that part.  Wasn't subbed. >_<
<Unit193> Sorry for the ping.
<cjwatson> np - might be worth me cherry-picking the fix for bug 1670745 too though, from the sounds of it
<ubottu> bug 1670745 in openssh (Ubuntu) "ssh-keyscan : bad host signature when using port option" [Undecided,New] https://launchpad.net/bugs/1670745
<Unit193> Yeah I just saw 8a2834454c73dfc1eb96453c0e97690595f3f4c2 too, that'd be greatly useful, though if the first is fixed at least there's a workaround.
#ubuntu-devel 2017-03-11
<ogra_> slangasek, i wiped all calendar data from my phone and re-installed/re-created everything ... how does the TB meeting even end up in any way related to my calendar, i never added it, did someone in canonical do that ?
<zyga> mwhudson: hey
<zyga> mwhudson: would you mind having a look at a patch for golang
<mwhudson> zyga: um ok but i'm not really here (sunday and all)
<zyga> mwhudson: haha, I didn't anticipate an instant reply ;)
<zyga> :-)
<mwhudson> heh
<zyga> http://paste.ubuntu.com/24159510/
<mwhudson> zyga: seems like a good thing, although that really is a hacky workaround
<mwhudson> zyga: you'll also need to cover the non-cgo case
<zyga> mwhudson: where is that?
<mwhudson> zyga: good question :)
<zyga> mwhudson: I think that it is a hack but given the fact that we exec it cannot hurt
<zyga> exec will replace all the threads
<zyga> too bad the kernel doesn't say anything like that
<zyga> EABOUTTOEXEC
<zyga> I patched my kernel to see where this fails exactly
<mwhudson> oh right yes
<mwhudson> how does this manage to have bad effects other than the message?
<zyga> and as some people anticipated it fails in kernel/fork.c:1031
<zyga> mwhudson: not clear because the thread just doens't get created
<zyga> something doens't happen
<zyga> I didn't run elaborate tests yet
<mwhudson> the non-cgo case is src/runtime/os_linux.go:newosproc
<zyga> thanks, checking
<mwhudson> so yeah, add the non-cgo case and come up with a good explanation of why this is a problem :)
<mwhudson> and it looks ok
<zyga> mwhudson: does the execing sample attached in the commit message look sufficient?
<mwhudson> zyga: so in the bad case, the exec does not happen?
<zyga> mwhudson: and the non-cgo case, is that in os1_linux.go?
<zyga> mwhudson: yes
<zyga> mwhudson: run that in while ./bug; do :; done
<zyga> and it returns quickly with
<zyga> runtime/cgo: pthread_create failed: Resource temporarily unavailable
<mwhudson> zyga: uh, maybe it's os1_linux.go in older go's, it's os_linux.go in tip
<mwhudson> zyga: ah that does sound bad enough yeah
<zyga> OK
<zyga> will do
<zyga> for you it's sunday right?
<mwhudson> yeah
<zyga> mwhudson: I'll try to patch that part too, never touched the go compiler
<zyga> oh, nice sched_yield is already implemented under osyield
<zyga> I noticed after I wrote the copy :)
<zyga> I think I got it
<jtaylor> hm what is the context? sched_yield should not be used
<jtaylor> on linux
<jtaylor> ah read up, you are only using it a couple times that is probably fine
<jtaylor> but don't use it for busy looping
<zyga> jtaylor: TBH I'm not yet sure what is the correct solution
<zyga> jtaylor: the case is where one thread runs clone/pthread_create while another one runs exefc
<zyga> exec*
<zyga> mwhudson: it worked :)
<zyga> mwhudson: but I think sched_yield is not a good idea indeed, the number of retries is unrelible as well
<jtaylor> don't other programs run into this? or does go just produce a larger amount of threads than everything else?
<zyga> jtaylor: go is special here, normally you don't just create threads in a program that just execs
<zyga> jtaylor: but in go you do
<zyga> http://paste.ubuntu.com/24160079/
<zyga> run this in a loopc
<zyga> comment out the "C" import for another variant
<zyga> while ./golang-bug; do :; done
<zyga> I have two patches that retry pthread_create/clone up to 1000 times
<zyga> I can still reproduce it but far far less frequently
<zyga> while terrible I'm inclined to sleep :/
<zyga> or patch syscall
<zyga> to detect exec and set a flag
<jtaylor> might be something the kernel might be interested in, give userspace the ability to detect a real EAGAIN
<zyga> jtaylor: it is a real EAGAIN
<jtaylor> that one seems more like the typical EINTR case not one where retrying again will result in the same result
<zyga> jtaylor: but ... we just care about one of those
<zyga> jtaylor: not the resource contention EAGAINs
<jtaylor> yes but EAGAIN can be a case where trying again won't help as you hit a limit
<zyga> jtaylor: this EAGAIN is also undocumented
<jtaylor> the others are not real EGAINs
<zyga> jtaylor: well I think this is up to interpretation
<zyga> jtaylor: but I worry that given how kernel development is done this will not change (userspace sees this)
<jtaylor> yeah, but the kernels input on how this should be handled would be valuable
<zyga> jtaylor: and even if, now you have to roll out a fixed kernel everywhere
<zyga> jtaylor: yes, I agree
<zyga> jtaylor: ideally golang would not do this but I think this is somewhat unavoidable
<zyga> jtaylor: perhaps checkinng syscall.Exec is the way actually
<zyga> jtaylor: just set a flag (retry on EAGAIN)
<zyga> jtaylor: and use that flag to retry
<jtaylor> zyga: maybe I don't now go to well to really help
<jtaylor> my alarm clocks just rang on mention of sched_yield as that occurs in lots of old numerics software I work with, written back when sched_yield was more or less equivalent to pause and not what it is today
<jtaylor> but used here is probably a reasonable workaround until a maybe better option if found
#ubuntu-devel 2017-03-12
<R0b0t1> Hello, how are ARM packages built?
<R0b0t1> I ask because with my distribution I have experienced various issues related to cross compilation that go away when compiled on-device. Are packages for ARM devices compiled on ARM devices, or does it depend?
<TheLexx> is this where I ask questions about casper booting system
<cjwatson> R0b0t1: We build ARM packages natively, on 64-bit ARM server hardware (in an appropriate chroot - 64-bit ARM hardware can run 32-bit code).
<R0b0t1> cjwatson: AhHA!
<R0b0t1> So Ubuntu has unobtainium.
<cjwatson> It is admittedly not the most easily-available hardware on the planet.
<cjwatson> AFAIK we did get it off the shelf rather than via any partnership deal or whatever, although I believe the particular hardware we have is no longer available :-(
<R0b0t1> That's unfortunate. Do you know what it is, exactly?
<JanC> is it really that important to use server hardware?
<R0b0t1> JanC: Yes, unfortunately. I'm fighting an uphill battle trying to get every package to compile in a crossdev environment. There are issues with autoconf and some harder to troubleshoot issues with compiling and linking that only show up in the cross compiler.
<R0b0t1> Some of it does seem to be poor support for SIMD acceleration in things like firefox and ffmpeg.
<JanC> I mean server vs. some other ARM SoC
<cjwatson> R0b0t1: HP ProLiant m400
<R0b0t1> JanC: Well, no. But on any other SoC most packages take half a day and there is insufficient IO speed to saturate the processor.
<cjwatson> You might still be able to find it somewhere, I don't know
<R0b0t1> i.e. SD cards are too slow and sometimes end up as the compilation bottleneck.
<R0b0t1> cjwatson, cheers.
<cjwatson> (I just operate the Launchpad end of it - I wasn't involved in the purchasing)
<R0b0t1> cjwatson: Well, with no information whatsoever it was very hard to find companies producing ARM server boards. There's the other issue though, which is that they're still thousands of dollars.
<R0b0t1> So this gives me something to go on but it probably has to wait. Again, thanks.
<cjwatson> np
<JanC> R0b0t1: https://softiron.com/products/overdrive-1000/ might be useful
<Unit193> cjwatson: ...Speaking of, bazaar.launchpad.net hostkeys are 1024 RSA.
<cjwatson> Unit193: bug please, it'll be a little while before I can do much about that
<cjwatson> Unit193: or actually, don't bother, we already have a bug for ecdsa/ed25519 support
<cjwatson> which you know about because you've commented on it :)
<Unit193> I know, I'm subbed and have commented.  Though that's generally more client and less about host keys.
<cjwatson> effectively the same thing
<cjwatson> Unit193: the path for making progress on that is to finish the upgrade to xenial, then convert our build system from buildout to pip, and *then* we'll be able to upgrade twisted in a reasonable way
<Unit193> Yep, just depends on which side generates the key.  And hopefully not making too much noise there.
<cjwatson> until then it's a nightmare
<Unit193> Oouch.
<cjwatson> (I've tried without that and given up)
<Unit193> Heh, no rush as ed25519 isn't finished yet.  And you're already doing great work on LP, so thanks.
<R0b0t1> JanC: A friend linked me to that earlier. Something I couldn't ascertain was whether or not the A53 used in it was an actual server component or an SoC. Reading it again it seems like a server component, but I still can't tell.
<R0b0t1> Like I said most of the bottleneck seemed to be IO, and it seems like it is saying the A53 version supports SATA. I'll give it another look.
<R0b0t1> It seems to be made for development, so...
<R0b0t1> JanC, cheers.
<JanC> R0b0t1: as far as I know many SoCs support SATA actually, even if many boards/devices don't actually expose/use it
<R0b0t1> JanC: Well, I know of the Banana Pi, but it seems to use a USB SATA controller. As far as I know most other boards are the same way as the highest speed interface the phone SoCs tend to support is USB3, and they may only have one USB3 interface.
<R0b0t1> I hope I'm wrong with newer devices of course.
#ubuntu-devel 2018-03-05
<seb128> xnox, doko, hey, is gcc-7 not building a libasan on s390x wanted or a bug?
<xnox> seb128, i do not believe libasan is available on s390x, thus things should have conditional B-D, unfortunately.
<seb128> xnox, k, thanks, meson autopkgtests fail on s390x due to that :/
<Laney> it's usually pulled in by libgcc-*-dev I think
<sarnold> Unit193: I believe leosilva is working on irssi updates; he may be able to push those out in the next day or two
<Unit193> sarnold: I see.  Thanks.
<xnox> infinity, given we do not care about d-i netboot size (it's not fixed, just big enough for current set of things) maybe we should calculate the size of all the things we want to copy, then create the empty dd image of the right size. Or e.g. create something really big, and shrink to smallest possible, after done copying all the things.
<xnox> and we can have a kpi tracking the size, to make sure it doesn't become actually outragous.
<xnox> infinity, cause FTBFS because kernels became bigger (and they will, always become bigger, due to more modules for yet another vendor of network cards)
<xnox> what do you think?
<GunnarHj> mapreri: Hi Mattia! As a DD, can you possibly help out with bug #1621861?
<ubottu> bug 1621861 in libsidplay (Ubuntu) "libsidplay1: Multiarch support is incomplete" [Medium,In progress] https://launchpad.net/bugs/1621861
<infinity> xnox: Who would watch this mysterious kpi?  The argument generally given for the limit is to prevent extreme growth due to oopses (which has, indeed, happened), and I doubt I'd bother watching a graph to see when that happened.
<nacc> tjaalton: heya, just rebooted bionic and all of a sudden my external monitor stopped working (and well, can't get to the greeter without nomodeset), have you seen this:
<nacc> [  178.256143] deja-dup-monito[5011]: segfault at bbadbeef ip 00007f5a67076588 sp 00007ffdc1addb30 error 6 in libjavascriptcoregtk-4.0.so.18.7.6[7f5a662be000+fc4000]
<nacc> jbicha: --^ or you?
<nacc> oh lol, nm, that's unrelated to actual monitors
<nacc> well, the original message then :)
<jbicha> nacc: I don't know any thing about your external monitor but there is LP: #1751460
<ubottu> Launchpad bug 1751460 in webkit2gtk (Ubuntu) "deja-dup-monitor crashed with SIGSEGV in Gigacage::<lambda()>::operator()" [High,Confirmed] https://launchpad.net/bugs/1751460
<nacc> jbicha: thanks for that link
<nacc> i guess it's possible the issue with the monitor is kernel driven, but it's the same kernel i was on before
<nacc> i guess i'm lucky this is the first breakage i've hit in bionic so far :)
<jbicha> nacc: I'll try harder ;)
<nacc> jbicha: heh
<jbicha> we did break -proposed this morning so it's a good thing you weren't using -proposed :|
<nacc> jbicha: hrm, i hav ea feeling it might be the gnome-shell update (it's starting to peg my cpu even in the receovery destkop)
<jbicha> I pass the blame to libglvnd
<nacc> jbicha: :)
<jbicha> I mean we had LP: #1751414 a few days ago
<ubottu> Launchpad bug 1751414 in libglvnd (Ubuntu) "[regression] Missing Wayland login option and missing GL acceleration, after installing libegl1" [Critical,Fix released] https://launchpad.net/bugs/1751414
<nacc> jbicha: ack, i am running the updated packages for that from proposed, i believe
<jbicha> you *are* running proposed? ð¤¦
<nacc> jbicha: those specific packages from proposed
<jbicha> I suggest 'ubuntu-bug display' to start a bug with debug info about your graphics drivers
<nacc> ack
<jbicha> libglvnd and mesa migrated this weekend so maybe you're back on mainline bionic now
<nacc> yeah
<nacc> jbicha: of course happy to debug further, LP: #1753576
<ubottu> Launchpad bug 1753576 in xorg (Ubuntu) "Xorg freeze" [Undecided,New] https://launchpad.net/bugs/1753576
<tjaalton> the dpkg log looks fine
<tjaalton> nacc: ^ meaning you should have everything from the transition
<tjaalton> need a dmesg from a failing boot
<mapreri> GunnarHj: you basically just filed that bug. of you trying to reach GCS and poke at him there is nothing I can do about that bug for some monthsâ¦
<mapreri> unfortunately he doesn't often hang out on IRCâ¦
<nacc> tjaalton: i'm not sure how to get it :/ ... if i pass text to the kernel, for some reason gdm still spins up x and it freezes
<nacc> tjaalton: any suggestsions?
<mapreri> GunnarHj: I supposed you were talking about NMUing the packageâ¦ we've had a recent case of somebody wanting to add a Multi-Arch:foreign to a package, the maintainer made a fuss about the person filing the bug in December and trying to get a NMU in January, and as a coconsequence've been told that without waiting several months it is not acceptable :\
<tjaalton> nacc: well, you could try booting into 4.13 to rule out the kernel
<nacc> tjaalton: ok, i can do that, i'm going to be afk for a bit
<mapreri> How can I unlink the debian bug from https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/238276 ?  ISTM only ~registry and Mark could do it??
<ubottu> Launchpad bug 238276 in inkscape (Ubuntu) "Big translation files for lots of languages are distributed in inkscape deb package instead of language-packs" [Wishlist,Triaged]
<mapreri> or maybe leave it like that, I'll just retitle and re-scope the bugâ¦ but the question stands, it's not the first time I'd like to.
<GunnarHj> mapreri: In this case the maintainer has already taken a step to multiarch'ing the package by fixing https://bugs.debian.org/777224 - he just forgot debian/control. That's why I felt that a NMU would be harmless. But you know the culture better than me. ;)
<ubottu> Debian bug 777224 in libsidplay1 "libsidplay1 is not Multi-Arch compatible" [Normal,Fixed]
<mapreri> GunnarHj: Not that many DDs take NMUs happily.  ISTR gcs does better than others, but would still prefer to do things himself.
<GunnarHj> mapreri: An Ubuntu delta is another option. Would be good to have it fixed in 18.04.
<mapreri> GunnarHj: could you try to mail gcs saying that, or otherwise feel free to ping me like next week and I can upload it to ubuntu.
<GunnarHj> mapreri: Ok, that sounds as a reasonable way to handle it. Will do. Thanks!
<cjwatson> mapreri: Not ~registry.  Looks like basically ~launchpad-debian-maintainers (so in practice probably just wgrant) or admins.
<mapreri> why did I read ~launchpad-debian-maintainers as ~registry -.-
<mapreri> cjwatson: who's ~james-w that I don't remember ever reading about?
<cjwatson> mapreri: Used to do the Bazaar package importer and a bunch of other stuff.  Possibly before your time though
<mapreri> cjwatson: could perhaps ~debiandevelopers be made a bug supervisor for debian?
<cjwatson> I wouldn't object but you'd have to ask William :)
<mapreri> wgrant: could perhaps ~debiandevelopers be made a bug supervisor for debian?
<cjwatson> (It seems odd to me that ~launchpad or ~registry or something isn't in ~launchpad-debian-maintainers, too.)
<mapreri> ~launchpad would be odd, but it really would be ~registry material
<mapreri> (but then, ~launchpad is in ~registry, soâ¦)
#ubuntu-devel 2018-03-06
<mapreri> cjwatson: btw, what would be the launchpad team representing the "launchpad admins"?
<mapreri> (~admins?)
<cjwatson> mapreri: ~admins, yes
<cjwatson> mapreri: being in ~admins shortcuts most permission checks
<mapreri> ack
<arijit> I filed a bug on launchpad, but have not gotten a response in two weeks (https://bugs.launchpad.net/ubuntu/+source/watchdog/+bug/1750942). I can submit a patch, but I'm not sure if the watchdog package is actively maintained at this point. Does anyone have any suggestions?
<ubottu> Launchpad bug 1750942 in watchdog (Ubuntu) "stale pid for watchdog service" [Undecided,New]
<nacc> arijit: it's in univere, which means somoene in the community needs to help support it, possibly no one actively is
<nacc> arijit: but if you provide a patch, it will go into the sponsorship queue
<arijit> nacc: That's good to know, thanks! Will send a patch
<nacc> arijit: yw
<nacc> arijit: and by patch i meant debdiff, if that wasn't clear
<arijit> sg
<wgrant> mapreri, cjwatson: I've set the Debian bug supervisor.
<wgrant> Distro ownership is very powerful so really needs to be restricted beyond ~registry
<ricotz> LocutusOfBorg, hi, libboost-numpy1.65-dev depends on libboost-python1.65.1 which should be ibboost-numpy1.65.1
<xnox> ricotz, hmmmmm
<mapreri> wgrant: thanks!   What do you mean with "Distro ownership is very powerful" - i.e. what would it entail?
<wgrant> mapreri: Particularly because we sync things by copies from Debian, there are spects of the distro configuration that shouldn't be messed with.
<wgrant> ~registry generally owns things that don't matter hugely
<mapreri> note that debian isn't owned/maintained by ~registry, but by basically just you :)
<wgrant> Yes.
<wgrant> I'm saying that's right (well, maybe not just me, but not ~registry either)
<LocutusOfBorg> ricotz, I don't get
<mapreri> And, ack :)
<ricotz> LocutusOfBorg, you don't get "what"?
<Laney> no satisfaction
<LocutusOfBorg> <3 Laney loool
<LocutusOfBorg> ricotz, I have zero boost uploads
<ricotz> hehe
<LocutusOfBorg> xnox, and doko did the whole work
<LocutusOfBorg> I could fix it, just I don't get why you pinged me
<ricotz> LocutusOfBorg, oh, didn't you came up in the changelog at latest
<LocutusOfBorg> I hope not
<LocutusOfBorg> doko is, but I'm grabbing it and having a look, I have some boost knowledge
<ricotz> LocutusOfBorg, oh, aptitude lied to me then :\
<ricotz> thanks
<LocutusOfBorg> :) no problem, I'm happy to fix it
<LocutusOfBorg> I did some boost merges, but a lot of time ago
<ricotz> I see, looks like xnox read my message too
<LocutusOfBorg> xnox, let me know, I confirm the issue
<LocutusOfBorg> ricotz, done.
<ogra_> slangasek, https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
<ogra_> slangasek, particulary the livecd-rootfs in that PPA will be a problem ...
<seb128> cyphermox, do you think you could have a look to https://bugs.launchpad.net/ubuntu/+source/libdazzle/+bug/1748905 ? it's blocking the gnome-calendar 3.28 update in bionic-proposed, we would like to get that in beta1 if possible
<ubottu> Launchpad bug 1748905 in libdazzle (Ubuntu) "[MIR] libdazzle" [Undecided,New]
<GunnarHj> mapreri: Thanks! You were right - pinging GCS made a difference.
<mapreri> GunnarHj: I sometimes believe he sends to /dev/null all mails coming from bts/dak etcâ¦  he maintains too many packages, I wouldn't be surprised he ignores regular bugs.
<GunnarHj> mapreri: I noticed this list:
<GunnarHj> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=gcs%40debian.org
<GunnarHj> Many of them have patches. Bad. Very demotivational for contributors.
<mapreri> wellâ¦
<sarnold> Unit193: https://usn.ubuntu.com/3590-1/ :)
<nacc> cyphermox: is the new MIR verbiage (e.g., "if the Security Team acknowledges they are aware of this requirement" standard now? I had a few MIRs I had looked at that also needed security team review for desktop
<xevious> systemd-firstboot is breaking stuff. Pharaoh_Atem figured it out by looking at the process a couple of times
<xevious> It's spawning random instance units for unit files that don't accept parameters.
<Pharaoh_Atem> which is a bit of a first for me
<Pharaoh_Atem> because I don't think I've seen firstboot behave so oddly
<bdmurray> jbicha: Do you have time to look at bug 1751546 now?
<ubottu> bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Confirmed] https://launchpad.net/bugs/1751546
<jbicha> bdmurray: I forwarded it to darkxst
<jbicha> did you see his comment there?
<bdmurray> jbicha: Ah, I hadn't refreshed
<jbicha> I didn't really look into the issue deeply since I was hoping he would :)
<xevious> Is anyone else seeing a long pause during boot, followed by the message "Gave up waiting for suspend/resume device"? This started happening in Bionic images I'm building. It doesn't happen on images I created at the beginning of February.
<xevious> Pharaoh_Atem: I was able to get the system to boot without creating the weird instance unit symlinks by creating `/lib/systemd/system-preset/01-default.preset` with the contents `disable *`
<cyphermox> nacc: there is no standard verbiage, you're welcome to create something (seeing as you're likely more native an English speaker than I am)
<cyphermox> nacc: this was just one special case where we didn't need immediate code review blocking the MIR
<nacc> cyphermox: oh no, taht's fine, i just wasn't sure if it was somethjing that discussed at the sprint, or if it's something that was done as a one-off (* a few)
 * tsimonq2 grumbles (albeit pointlessly) at systemd-resolved
<cpaelzer> bdrung: hi, still around?
<cpaelzer> bdrung: I see a qemu upload in bionic that fails to build on all arches
<cpaelzer> I have other changes to make and wanted to ask if you are already on this?
<cpaelzer> bdrung: there also is no bug associated and so far I couldn't find the changes upstream
<cpaelzer> bdrung: for now since the current ubuntu3 version FTBFS as it is and I have an alternative already through the usual qemu upload regression testing
<cpaelzer> bdrung: I'm going to revert the changes made by you in ubuntu3 for now and push my changes as ubuntu4
<cpaelzer> bdrung: but please do not feel set back, I'd ask you to file a bug and attach the changes you had
<cpaelzer> bdrung: there we can also check what is causing the build fails
<cpaelzer> bdrung: and I could pre-upload push t through regression checks from a ppa
<cpaelzer> so TL;DR: Hi, I reverted your ubuntu3 (FTBFS) and pushed other changes as ubuntu4 for now
<cpaelzer> please bug me via launchpad :-)
<cpaelzer> bdrung: we are sprinting, so I never know when I'm able to respond therefore through a LP bug I expect it to work better
<cpaelzer> Hmm, I see that I can run into this issue just as much without your changes
<cpaelzer> so something else changed and made this show up now
<cpaelzer> bdrung: should be fixed by https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75e5b70e6b5dcc4f2219992
<cpaelzer> bdmurray: I'll combine our changes plus the fix and check if it builds
<cpaelzer> bdmurray: sorry I meant bdrung
<cpaelzer> bdrung_work: but a bug about the reasons to refer to from the changelog and patches would still be great
<darkxst> jbicha, bdmurray, bug 1751546 is on my list to look into, however I suspect it is an archive issue with tasks, rather than a tasksel issue
<ubottu> bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Confirmed] https://launchpad.net/bugs/1751546
<cpaelzer> bdrung: FYI 1753826 is the FTBFS bug
<cpaelzer> bdrung: I appreciate to work on it, but this is post FF and could be considered a Feature
<cpaelzer> so a bug to discuss is even more appropriate
<bdmurray> darkxst: It looks like a tasksel issue to me https://launchpadlibrarian.net/339723238/tasksel_3.34ubuntu8_3.34ubuntu9.diff.gz
#ubuntu-devel 2018-03-07
<ejat> if i want to install libcurl4 , The following packages will be REMOVED:
<ejat> cryfs dotnet-runtime-2.0.0 dotnet-sdk-2.0.0 libcurl3 powershell slack-desktop virtualbox-5.2
<Unit193> ejat: cryfs is in -proposed, others are external packages so complain to their respective sources?  Or just wait for them to update when bionic is released.
<Unit193> And specifically, virtualbox's repo tends to lag a bit, so expect it a little after release.
<cpaelzer> bdrung: I created bug 1753938 for us to work on it
<ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
<bdrung_work> cpaelzer, i haven't opened a bug report, but instead developed the patches and send them to the mailing list.
<bdrung_work> cpaelzer, looking at #1753938, I missed the feature freeze with my upload
<smoser> infinity if you're awake, we'd like to have rharper added to https://launchpad.net/~ubuntu-release-nominators/+members#active .
<smoser> looks like you or bdmurray can do that , but i'm sure he's sleeping now.
<smoser> infinity: sorry, 'raharper' is who needs adding. not rharper.
<infinity> smoser: Done.
<smoser> thank you
<cpaelzer> bdrung_work: yeah, I think I dumped all we need to do on the bug
<cpaelzer> let me know how you want to proceed once you are ready
<cpaelzer> I assume you go on upstreaming anyway
<cpaelzer> super-worst-case we can still revert the change in a few weeks, but I very much would prefer to clean up things and keep it
<cpaelzer> bdrung_work: up to you
<pitti> cpaelzer: guten Morgen, wie gehts?
<pitti> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1696471/comments/9 "without a clear repro" â you are saying that my reproducer doesn't work?
<ubottu> Launchpad bug 1696471 in libvirt (Ubuntu Xenial) "AppArmor denies access to /etc/gss/mech.d/" [Undecided,Confirmed]
<bdrung_work> cpaelzer, i like to get the patches into upstream and update the package to use the accepted version of the patches
<cpaelzer> pitti: I might have forgotten you had one but just found my own :-/
<cpaelzer> pitti: anyway I can drive it forward now
<pitti> cpaelzer: I posted it to the bug a few days ago
<cpaelzer> bdrung_work: ok, lets do that, if you have an accepted version get in touch with me
<cpaelzer> bdrung_work: ok for yu?
<pitti> but indeed it wasn't very hard, the xml isn't particularly magic
<cpaelzer> you
<pitti> cpaelzer: danke
<cpaelzer> pitti: oh no, that is not it
<cpaelzer> pitti: I can not trigger with your xml
<cpaelzer> pitti: the magic ingredient is libsasl2-modules-gssapi-mit being installed
<cpaelzer> it seems to be loaded and by that makes qemu read the dir
<cpaelzer> without it won't
<cpaelzer> which explains why I only saw it sometimes
<pitti> cpaelzer: ah! I suppose that gets pulled in by a package like virtinst, sssd-tools, or perhaps realmd
<pitti> I don't directly install any *sasl* or *gss* package
<sarnold> cpaelzer: perhaps abstractions/kerberosclient needs to be updated, and perhaps something in libvirt needs to use this abstraction?
<pitti> cpaelzer: nice, thanks for finding that
<bdrung_work> cpaelzer, yes
<xevious> rbasak: Last week, you mentioned that the mysql package changed how the service is started and stopped, which pointed me in the right direction to fix the problem I was having installing it in a `systemd-nspawn` container.
<xevious> rbasak: When you install the mysql-server package, it used to enable the mysql systemd service. It doesn't get enabled automatically now, when I install it in a deboostrapped container. Is that an intentional change?
<sarnold> xevious: at least the debian postinst appears to use invoke-rc.d; does your container have the policy in place that would prevent statup as a result?
<Son_Goku> hey, was there a recent merge of updates to the compiler?
<Son_Goku> it seems to have broken my ability to build qemu locally
<Son_Goku> (as in, the qemu package that's currently shipped in bionic)
<xevious> sarnold: The postinst started failing in my `systemd-nspawn` container, which I was able to fix by adding the `--as-pid2` parameter to `systemd-nspawn`, but maybe that broken enabling the service...
<xevious> (mysql-server's postinst)
<xevious> s/broken/broke/
<nacc> Son_Goku: which qemu are you trying to build?
<Son_Goku> 1:2.11+dfsg-1ubuntu2
<Son_Goku> basically the top of the ubuntu-bionic branch of the qemu code
<rbasak> xevious: the reason for the change was to fix https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1592669
<ubottu> Launchpad bug 1592669 in mysql-5.7 (Ubuntu) "postinst fails when daemon is not running (or is disabled by policy-rc.d)" [High,Fix released]
<nacc> Son_Goku: ok, because i know ubuntu3 FTBFS
<nacc> Son_Goku: there's an ubuntu4 in bionic-proposed
<rbasak> xevious: that changes quite a bit about how it all works. The postinst has to start the daemon to upgrade the db, which we consider to be outside the scope of policy-rc.d.
<nacc> Son_Goku: which did build, so it seems unlikely that the compiler is broken :)
<Son_Goku> nacc, thanks, I'll take a look at that
<rbasak> xevious: I think it's likely that stuff you're doing is colliding with that, because that's a new pid to any management thing like systemd.
<nacc> Son_Goku: ah and ubuntu4 has a fix for FTBFS on newer glibc :)
<nacc> Son_Goku: so yeah, just pull that one down, I think
<Son_Goku> yeah, that looks about right
<xevious> rbasak: Remember my other ticket, though? postinst failed without the `--as-pid2` parameter.
<rbasak> xevious: I believe that the behaviour we have now is correct by policy though, so if you pinpoint something that shows it isn't, please let me know :)
<rbasak> Yep
<Son_Goku> nacc, we're bombing out on memfd_create() :)
<Son_Goku> so that made me suspicious of compiler or other low level packages
<rbasak> Because the postinst does actually start a mysqld instance, which expects to be a daemon and does daemon-like things.
<xevious> rbasak: So, I'll need to manually enable mysql in my build process, since postinst won't be able to do any rc.d stuff inside my container, right?
<rbasak> But that instance is only used within the postinst and is separate from the daemon instance started for you that provides normal service.
<xevious> Yup
<rbasak> xevious: I think there's still something wrong with your build process.
<xevious> It's reproducible by deboostrapping a fresh copy of bionic and installing mysql with `systemd-nspawn`.
<xevious> What's wrong with that process?
<xevious> (that's an honest question, not me being stubborn/challenging/rude/etc.)
<Son_Goku> RUUUUUDE!
<Son_Goku> nacc, as an aside, the d/control for qemu still points Vcs-Browser to the utopic brance
<Son_Goku> *utopic branch
<nacc> cpaelzer_: --^
<xevious> rbasak: Actually, I totally misspoke: it does enable the service if mysql-server is the only thing being installed. I'm currently paring down the difference between the minimal process that works and my imaging script.
<xevious> The `--as-pid2` parameter is definitely required, though.
<rbasak> xevious: --as-pid2 sounds like it's needed for any use of nspawn that isn't an actual init program.
<rbasak> Which also suggests to me that you're misusing it somewhat, though I'm not familiar with it of course.
<xevious> In my experience, you can either fully boot a container (with the -b parameter) or use *most* programs without requiring --as-pid2.
<pgoetz> I installed 18.04 on a workstation with dual GTX 1070 cards, one connected to a 4K monitor and am having the following odd issue. The first person to log in is locked down to a 1024 display and settings doesn't seem to recognize the monitor.  However, if user switching is used to log someone else in, that user gets the full 4K display.  Did not yet test with a 3rd user, as that is already weird enough.
<wxl> pgoetz: #ubuntu for support
<pgoetz> OK, thought this might be an issue with the beta.
<pgoetz> join #ubuntu
<wxl> if it were, you'd probably discuss it at #ubuntu+1
<wxl> sorry i failed to see the 18.04. that would probably be the best place
<pgoetz> thank you.
<xevious> rbasak: I've tracked down the source of my issue. PEBCAK, go figure.
#ubuntu-devel 2018-03-08
<nauticalnexus> Trying to build a zsh 5.4.2 package on Ubuntu 17.10, keep getting this https://paste.ubuntu.com/p/ng385dFPT3/ not sure where to go from here
<nacc> nauticalnexus: perhaps the zsh you are building needs a newer debhelper than is in artful
<nacc> nauticalnexus: it looks like you are trying to backport the one form bionic to artful, but the bionic one is built with debhelper 11
<nauticalnexus> I was trying to build it from source :P
<nauticalnexus> with bzr dh-make
<nacc> nauticalnexus: what source?
<nauticalnexus> tarball, hold on
<nacc> nauticalnexus: dh-make is presumably invoking debhelper
<nauticalnexus> http://zsh.sourceforge.net/Arc/source.html tar xz from here
<nacc> nauticalnexus: if you're building from a tarball, why are you using `bzr` ?
<nauticalnexus> That's what the wiki says to do >.>
<nacc> nauticalnexus: what wiki?
<nauticalnexus> http://packaging.ubuntu.com/html/packaging-new-software.html#starting-a-package
<nauticalnexus> I have no idea what I'm doing if you can't tell.
<nauticalnexus> But I want to learn..
<nacc> nauticalnexus: yeah you probably dont' want to follow that guide at all
<nacc> and you want #ubuntu-packaging
<nacc> nauticalnexus: i need to step away, but i can try and help tmrw
<nauticalnexus> Ah, thanks, I'll go there
<arunc> Hi, I found the version of OpenCV that will be shipped with Bionic will be a 3 year old version. Is it possible to update it to 3.4.x
<arunc> Here is the bug to track https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/1753928
<ubottu> Launchpad bug 1753928 in opencv (Ubuntu) "OpenCV version in Bionic" [Undecided,New]
<sarnold> arunc: there's a small chance; even though it's after feature freeze, opencv is in universe ..
<Faux> The link in the bug report says 3.2 is being shipped, which makes more sense as that's what's in Debian since Oct.
<sarnold> ah so it is. seems very unlikely then.
<arunc> sarnold: sorry, I'm not quite sure what universe means here.
<arunc> Faux: https://launchpad.net/ubuntu/bionic/+source/opencv shows 3.1 and 3.2, not sure which one will be shipped though :-)
<Faux> https://packages.ubuntu.com/search?keywords=opencv is more non-developer friendly.
<sarnold> arunc: packages in universe are community supported; packages in main are canonical-supported. sometimes the rules around packages in univrese are relaxed occasionally when it makes some sense.
<arunc> thanks
<rbasak> nacc: slashd just found that the ubiquity usd-import-team repo is missing an ubuntu/devel branch. I can't think of how this might be expected?
<sarnold> arunc: but there'd have to be a pretty compelling story to try to update a package in universe to something newer than debian is shipping
<arunc> sarnold: I see, there are quite a bit of performance and stability improvements since last year.. FYI https://github.com/opencv/opencv/wiki/ChangeLog
<arunc> 3.2 was released 1.5 years ago
<sarnold> arunc: yeah, I can imagine it has probably seen a lot of use and refinement :) but I can't speak for why the debian maintainers for opencv are on the schedule they are, or what costs and benefits they weighed when deciding what to upload, when
<Faux> The "dsfg" in the version number implies that the package is complicated.
<StevenK> Not so much complicated as the source has had some things removed
<sarnold> that qualifies for "complicated" in my book :) hehe
<sarnold> "
<sarnold> High-level API has been modified and is even more convenient now.
<sarnold> if they removed or broke existing API that might be a huge roadblock to newer versions
<arunc> I'm not familiar with Debian either.. but all I can think of is, Ubuntu 18.04 is going to be a LTS and if it doesn't ship the latest opencv, we will miss out huge benefits by default
<arunc> thanks for your help.
<StevenK> 3.3 is in experimental, so I guess it's not quite ready yet ...
<infinity> arunc: I've always found "if X is an LTS, it must have the shiniest software" a strange argument, since the point of a stable LTS is to have software that doesn't change (modulo bug fixes and security advisories) for 5+ years.
<infinity> arunc: I agree that it's nice to start those five years from a pretty shiny base, but that base gets out of date very quickly, compared to the total life of the release.
<arunc> infinity: I can understand. In opencv's case with improvements in DNN, performance improvements, bug fixes and so on, it is sad not to see that come by default
<rbasak> tjaalton: FYI, I'm looking at bug 1753839. Do you have any opinion (as you last merged)?
<ubottu> bug 1753839 in memcached (Ubuntu) "memcached deadlock fixed in 1.5.5" [High,Triaged] https://launchpad.net/bugs/1753839
<rbasak> I'm considering bumping to 1.5.6. Assessing that bump for feature changes/FFe requirement.
<tjaalton> rbasak: ah, yes 1.5.6 sounds good to me
<coreycb> bdmurray: hi, would you mind rejecting my python-cryptography uploads to xenial and artful?
<coreycb> bdmurray: ty
<bdmurray> no problem
<dx> hey, i found that a bug in the pidgin package is caused by an ubuntu patch. how can i get someone to remove it? as far as i can see the maintainer is nobody in particular
<dx> bug is https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1245666
<ubottu> Launchpad bug 1245666 in pidgin (Ubuntu) "Pidgin is creating zombies" [Medium,Confirmed]
<bdmurray> coreycb: It looks like there is a test case in bug 1722553 but it isn't explicity called out and other SRU information is missing.
<ubottu> bug 1722553 in python-pyperclip (Ubuntu Artful) "openstack command raises exception referencing gi.repository and gnome bug 709183" [High,Triaged] https://launchpad.net/bugs/1722553
<coreycb> bdmurray: sorry about that, it's updated now
<sarnold> LocutusOfBorg: hey :) any chance you can take a look at /lastlog dx ? :) thanks
<jbicha> pitti: I would like to drop python-volume-key from Debian (like we did with python-blockdev)
<pitti> jbicha: ah, python 2 cleanup? sure, I suppose/hope it didn't grow any dependencies by now
<jbicha> I don't see any :)
<pitti> jbicha: ok,  I'll look into that now
<pitti> oh, you did already, thanks
<jbicha> pitti: yeah, it was a cleanup task for LP: #1754422 (which might not happen until 18.10 given the backlog)
<ubottu> Launchpad bug 1754422 in volume-key (Ubuntu) "[MIR] volume-key" [Undecided,New] https://launchpad.net/bugs/1754422
<LocutusOfBorg> sabdfl, ack thanks
<LocutusOfBorg> s/sabdfl / sarnold
<LocutusOfBorg> :)
<LocutusOfBorg> done!
<LocutusOfBorg> dx, thanks to you too
<dx> oh, neat, thanks
<dx> LocutusOfBorg: mind if i ask another thing? the xchat package has too many patches, could you remove the package itself? :P
<tsimonq2> Oh boy. :P
<pitti> xchat? I thought that was removed ages ago, and replaced with hexchat
<pitti> oh really, it came back in artful
<dx> yeah, LocutusOfBorg reintroduced it, and is now the new upstream
<nacc> LP: #1753169
<ubottu> Launchpad bug 1753169 in xchat (Ubuntu) "Please don't include xchat (abandoned upstream) in 18.04" [Undecided,Confirmed] https://launchpad.net/bugs/1753169
<nacc> already filed by you dx :)
<nacc> dx: however, the debian discussion seems more involved
<dx> yeah, i figured i'd just wait for them to decide there
<nacc> dx: yeah, seems reasonable
<dx> of course taking a shortcut and just politely asking LocutusOfBorg to remove it was worth a shot
<dx> it worked to remove a buggy patch from the pidgin package!
<dx> totally the same thing
#ubuntu-devel 2018-03-09
<doko> infinity: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/g/glibc/20180308_104519_a84ec@/log.gz are these expected?
<infinity> doko: Yes, which is why it's badtested.
<infinity> Or was..
<infinity> doko: badtested again.
<jbicha> infinity: can you kick component-mismatches?
<infinity> jbicha: Hrm, that does look a bit stale.
<infinity> jbicha: https://paste.ubuntu.com/p/qWvXJnbYX6/ <--- Looks like someone broke it.  Will fix in a bit.
<infinity> jbicha: Applied a blind fix, should do something useful next publisher run.
<alkisg> initramfs-tools/hooks/casper ==> manual_add_modules overlayfs ==> this hasn't been updated to the new "overlay" name, so live CDs are still falling back/using aufs, is that on purpose?
<alkisg> Whoops sorry I was looking at a 16.04.3 live cd, ignore me, it's fine in 18.04
<sarnold> LocutusOfBorg: thanks! :)
<seb128> cyphermox, hey, could you check if bug #1735499 is good to be promoted? it looks like doko's review issues have been addressed and security gave a +1 so it looks like it's good now but I'm not the MIR team so don't want to set it to fix commited before checking with somebody from the team
<ubottu> bug 1735499 in udisks2 (Ubuntu) "[MIR] libblockdev" [Undecided,New] https://launchpad.net/bugs/1735499
<cpaelzer> jbicha: are you on the sprint, and if so where could I find you?
<cpaelzer> smb: iproute is stuck in proposed, are you taking care of that?
<smb> cpaelzer, yes, there are 3 other packages depending on iproute only which I fixed up and am waiting to get sponsored
<cpaelzer> thanks
<cpaelzer> jbicha: just realized this was a bad question, I'll go over to the desktop team and sort thing out - sorry to bother
<cpaelzer> willcooke: I found Laney he will take a look from the Desktops POV
<willcooke> cpaelzer, Laney - thanks
<ginggs> tseliot: nvidia-settings PR squashed and rebased.  Thanks for looking!
<tseliot> ginggs: thanks!
<ginggs> tseliot: there are still two other PRs, and then some more commits I haven't pushed yet which depend on those
<tseliot> ginggs: ok, then maybe send me an email with all of those, and I'll have a look at them
<tseliot> I'm kind of busy working on prime
<ginggs> tseliot: ok
<sil2100> roaksoax: hey! So I'm looking at the openwsman NEW binaries and I now noticed that apparently the sonames were bumped for libwsman_client to .4 but the binary package name stayed at libwsman-client2
<sil2100> roaksoax: I guess we'd need to bump that to libwsman-client4?
<bigon> hey, where is the procedure to fix a bug in stable release?
<sarnold> bigon: this? https://wiki.ubuntu.com/StableReleaseUpdates
<bigon> it's not clear if it should uploaded to -proposed or -update
<bigon> well IMVHO
<cjwatson> "The upload must have the correct release in the changelog header" - if you do that (without any other adornment, e.g. just "xenial") then it'll be automatically redirected to xenial-proposed
<bigon> oh ok
<bigon> long time I didn't upload to ubuntu
<Laney> nice to see you back here bigon ;-)
<bigon> hehe, I'm just fixing a bug for a colleague here
<Laney> cpaelzer: Those changes in the seeds all look deliberate to me, so I don't see a problem with uploading
<cpaelzer> Laney: the problem are not the changes in the seeds
<cpaelzer> Laney: the problem is what the update makes of it in the changelog and what you want instead
<cpaelzer> Laney: http://paste.ubuntu.com/p/T54hrchZP8/
<sarnold> -- root <root@bionic-meta.lxd>
<Laney> cpaelzer: I know, and the changes in bzr correspond to those
<cpaelzer> sarnold: just a test sys, don't mind
<cpaelzer> Laney: ok, pushing as it is then
<cpaelzer> Laney: thanks for checking
<cpaelzer> Laney: the case I wondered was this
<cpaelzer> * Added gnome-bluetooth to desktop-recommends [s390x]
<cpaelzer> while the actual change was
<sarnold> cpaelzer: ah good :)
<cpaelzer> Laney: sorry for the noise
<cpaelzer> this were too much negations
<cpaelzer> :-)
<Laney> no problems!
<Laney> I was looking at a diff of a diff earlier
<Laney> that's always mind bending too
<cpaelzer> - * (gnome-bluetooth) [!s390x] # desktop bluetooth support
<cpaelzer> + * (gnome-bluetooth) # desktop bluetooth support
<cpaelzer> it really is "add"
<cpaelzer> still awkwared to add it on s390x, but ok
<xevious> nacc: I just noticed this on reddit: https://www.reddit.com/r/PHP/comments/837w5z/the_next_ubuntu_lts_1804_ships_with_php_72/
<xevious> nacc: The PHP community appreciates your effort!
#ubuntu-devel 2018-03-10
<nacc> xevious: nice! thanks for the link!
<tarzeau> is there a reason popcon.ubuntu.com isn't updated anymore?
<tarzeau> Last generated on Wed Jun 22 15:09:05 2016 UTC.
<Unit193> tarzeau: You can file an issue with rt, but I've done that in the past a few times.  They fix it, then not too long later it breaks again.  I finally gave up.
#ubuntu-devel 2018-03-11
<Unit193> tjaalton: Hi.  You uploaded xserver-xorg-video-ati to Debian but as it's after DIF it hasn't made its way to Ubuntu yet.  Any chance you could give it a nudge?
<tjaalton> Unit193: yes, later. -amdgpu too
<Unit193> Great, thanks. :)
<tarzeau> Unit193: if they would just provide the latest input, i'd be happy
<tarzeau> Unit193: because the stats ubuntu AND debian creates, is kind of very limited. so i'll work on something more detailed
<tarzeau> Unit193: where's the rt bug report thing? i've filed one with launchpad
<LocutusOfBorg> hello juliank, can you please do the gnutls28 merge if possible (wrt FFe)? I'm listed as last uploader, but because of a no-change rebuild
<juliank> LocutusOfBorg: ack, will do tomorrow or so
<LocutusOfBorg> thanks juliank ! I can steal the merge if you want, but I prefer to not touch new stuff whenever possible
<juliank> LocutusOfBorg: I'm happy merging it :D
<LocutusOfBorg> thanks!
<LocutusOfBorg> I really hate doing no-change rebuilds, because my name goes in that page
<LocutusOfBorg> the diff is trivial, just a few lines added, nothing interesting, just bugfixes on AES
<LocutusOfBorg> but since the gnutls28 fixed vlc/chromecast too, I might want to keep it up-to-date
#ubuntu-devel 2019-03-04
<cjwatson> seb128,sil2100: We now have langpack export cron jobs for disco.  They're in the previous artful time slot, with the jobs starting at 10:30 UTC on Monday (they normally seem to take <90 minutes).  Is that enough for you to set up the langpack side of the schedule?
<seb128> cjwatson, hey, I think it should be enough but it seems I lost access to the admin page (either acl changes/I dropped from a team, or I'm looking at the wrong place, it has been a while)
<seb128> hopefully Lukasz still has access/can handle the initial export
<seb128> ahasenack, hey, I commented on bug #1818431. i see you closed a bunch of similar bugs pointing out buggy setups, configs, etc. But I think there is a real issue with the package to address, even if their setup as buggy we should fail in the postinst if the service is failing to start, it let system is a wrecked status which is never right
<ubottu> bug 1818431 in samba (Ubuntu) "Regression in winbind package postinstall script" [High,New] https://launchpad.net/bugs/1818431
<sil2100> seb128, cjwatson: let me get to that once I handle the .6 RCs
<seb128> k, I would be happy to look at it but I think I lost the acl required as said
<seb128> or maybe I should apply to get them again, unsure to how/what team though
<rbasak> seb128: unfortunately that's the nature of "server" type packages. Users are expected to change their configurations, and after that if they do it wrong then daemons will fail to start.
<rbasak> We don't consider user misconfigurations to be bugs.
<rbasak> If that should change, then what should the behaviour be instead?
<rbasak> Or are these cases different from that generalisation somehow?
<seb128> rbasak, well, to me failing install with a postinst error and letting the packaging system wrecked up is never a good idea
<rbasak> I understand why you don't like it.
<seb128> imho having a "start job || true" would be better than bailing out in the middle of an upgrade
<rbasak> But right now that's how Debian is designed.
<seb128> what's the value of stopping the upgrade that way?
<rbasak> I've heard it argued that that still leads to a broken system but the user doesn't know that's the case, which is arguably worse.
<seb128> rather than just ignoring the failure and letting the install sucess?
<rbasak> I understand your perspective. We've discussed this kind of thing extensively. I'm just saying that there is no good answer, and that if we want to change it then it's a blueprint-level thing, rather than something we can address with a few bug reports.
<seb128> ok, I was not aware that there was a consensus on that
<rbasak> I'm not sure we have consensus, to be clear.
<rbasak> I'm just saying that it's a non-trivial issue that I don't think we should be addressing piecemeal
<seb128> also desktop and server perspective are probably different in that regard
<rbasak> Yes, absolutely. On server packages, users are expected to change daemon configuration and therefore can be expected to be responsible for service start failures to some extent at least, and that's not the case on desktop.
<seb128> on desktop the last thing you want is to have unattendeed-upgrades applying updates in bg for you, failing, letting your box in a corrupted state and having a system not booting as a result
<seb128> rbasak, thx for the comment, but yeah, I don't have a clear answer here either, I just though we had consensus that failing install in postins was to be avoided in all cases, seems not which is fine, you guys probably gave it more thinking than I did for the server usecases
<rbasak> I think we (server) have some specific cases where we consider it acceptable.
<seb128> (it does feel the wrong hammer to me though, it should be the admin job ot make sure his machine has no failing systemd units and that they got proper monitor for errors)
<seb128> of making*
<rbasak> Eg. user installs daemon, user misconfigures daemon such that it will fail to start, user gets a security update -> postinst runs and fails to start daemon -> dpkg error.
<seb128> it's not even clear from that in this case it's a configuration problem
<rbasak> OTOH, a working, correctly configured and running daemon -> package update -> dpkg error is definitely a problem since that would be a regression.
<seb128> and not a bug in the software or a failure to handle the environment around it leading to an error
<seb128> yeah
<seb128> well imho admins should have reporting of services errors
<rbasak> Given my first acceptable case, it's a massive pain for us to be flooded with "bug reports" through apport for those cases. I've got an item to see about sending those to errors.u.c instead, since in aggregate it might still give us useful information.
<seb128> relying on postinst failures to tell you about those feels wrong
<rbasak> What do you mean by "these"? I've lost context, sorry.
<seb128> if you have a configuration error and a service fails to start, you want to know that immediatly/whenever the service tries to start and fail
<seb128> but I agree with what you said before, if the upgrade is what makes the service start erroring out, then it's a problem
<seb128> snaps solve that :)
<seb128> install, test, rollback if the new version fails
<rbasak> Ah - so you'd prefer to avoid the postinst failure in favor of some kind of earlier failure in principole?
<seb128> yes, I think breaking installs in the middle is a dangerous things to do
<seb128> since it might lead to a system which is going to fail to reboot
<rbasak> I wonder how difficult it would be to only restart a daemon on postinst if it was running at preinst time.
<seb128> which is worth than a failing service
<rbasak> Could that be implemented in debhelper/systemd?
<rbasak> Then postinst wouldn't notify of failures.
<rbasak> And separately, a motd notice (or via PAM after CLI login or something) for services that are configured to run but aren't running.
<seb128> right
<seb128> well, I guess at this point it's non trivial work so would need proper blueprint/discussion/plannification etc
<rbasak> Yeah
<rbasak> Right now I put this in my "the user screwed up but we could be more graceful about it" category.
<rbasak> I'm marking this category of bugs Invalid still, but all the instances are a valid "affects me too" against a "could be more graceful" bug.
<seb128> k
<rbasak> Does that sound reasonable?
<seb128> yes
<rbasak> Thanks.
<rbasak> It's important to us I think because we (server) get this category of bugs daily :)
<seb128> thank you for the discussion/Explaning your position
<rbasak> You're welcome. It's absolutely a valid issue :-/
<seb128> there might be still a valid samba bug behind that one btw
<rbasak> I'll include you in further discussion on this.
<seb128> it's unclear to me if the problem is a configuration error
<seb128> or if winbind is failing to handle a type of environment out of the bo
<seb128> box
<rbasak> OK
<rbasak> I'll leave that to ahasenack I think, since he's generally most knowledgeable about samba/windbind
<seb128> in which case the bug would be to fix winbind to not error out in that setup
<seb128> makes sense
<seb128> thx
<klebers> LocutusOfBorg, hi! thanks for sponsoring the virtualbox pkg for trusty
<klebers> LocutusOfBorg, would you be able to sponsor the pkgs for xenial as well?
<shadeslayer> popey: hey, I heard you were looking for PineBooks?
<seb128> juliank, hey, did you say you would SRU that packagekit segfault fix?
<juliank> right
<seb128> k, just checking, thx :)
<juliank> seb128: on it. Did we see any crashes on xenial? There's another function to fix there (show_warnings), but it should not be too complicated.
<juliank> It's also in main in trusty, so we could fix it there too
<juliank> though i'm not sure which releases use aptcc vs apt
<juliank> ah they all do
<seb128> juliank, I wouldn't bother going back to trusty for desktop fixes at this point, especially that this fix is in the error handling code so it's not like it was failing something would have worked otherwise
<juliank> ack
<seb128> juliank, looking at the error tracker it doesn't seem to bite much xenial users (did we still use aptdaemon then for gnome-software?), I would only do bionic I think
<juliank> hmm
<seb128> juliank, yeah, gnome-software depends on aptdaemon in xenial, it was using the backend robert_ancell wrote at the time because pacagekit was still not up to what we needed
<juliank> ok
<seb128> SRU team, what would be the right place to discuss maybe revisiting the requirement of landing fixes in non-LTS-current to be able to SRU to the LTS?
<seb128> I think that rule is not always bringing much value but increasing cost of landing fixes to the LTS
<bdmurray> seb128: I think the release mailing list would be a fine spot
<seb128> bdmurray, thx
<juliank> +0.5 on that
<ogra> hmm, any screen specialists here  ? i have an arm board that defaults to 1500000 baud ... seems using screen with that value doesnt actually make it go up to 1500000 but still stuck at 115200
<ogra> is there a limit ?
<rbasak> ogra: IIRC baud rate is set by an ioctl (or at least can be) with a set of enumeration constants. I don't think it's a free form integer.
<rbasak> ogra: here you are: https://stackoverflow.com/questions/4968529/how-to-set-baud-rate-to-307200-on-linux
<rbasak> Perhaps screen doesn't support that?
<ogra> yeah, seems like ... minicom works fine but is a pain to use ... i feel like back in the 90s
<seb128> bdmurray, sometime I wonder what are you criterious to convert e.u.c reports into launchpad bug...
<seb128> bdmurray, bug #1818540 has 3 reports ever, all on 18.04, 2 in 2018 and 1 in 2019, all on armhf ... for sure that's not a priority for any sort nor ranking on any top 100 list of any filter, how did you even get to it?
<ubottu> bug 1818540 in gnome-settings-daemon (Ubuntu) "/usr/lib/gnome-settings-daemon/gsd-color:8:__libc_do_syscall:__libc_signal_restore_set:__GI_raise:__aeabi_ldiv0:gcm_session_device_reset_gamma" [Undecided,New] https://launchpad.net/bugs/1818540
<bdmurray> seb128: all the crashes were from non x86 systems which I thought was noteworthy but I could be wrong.
<seb128> bdmurray, yeah, all 3 are on armhf, which I don't think we care enough to put resources into fixing things like color calibration atm (I'm not even there it works at all on that platform)
<seb128> anyway, I closed it
<seb128> just feels like a weird one to pick from the error tracker
<bdmurray> seb128: okay, noted
<seb128> anywa, sorry for the verbose mode, it mostly made curious about your filters/the lists you reviewed :)
<bdmurray> seb128: There's a search of successful armhf/arm64 crashes I review and I appreciate the feedback.
<seb128> k, I don't think arm* desktop is a thing atm though
<seb128> it doesn't mean we shouldn't try to fix existing bugs, but that ranks rather low in our priority list/too low to be acted on seeing the flow of work on things we care about
<Laney> doko: infinity: what's the status of glibc's migration? any way we could help?
<Laney> We've got a few bits stacked up behind that which people ought to be using before the release ideally
<doko> Laney: I'm trying to figure out what else is missing ... didn't get any feedback about the floating point issues
<mwhudson> Laney: https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1818285 <- i bet you were super happy to learn all those things
<ubottu> Launchpad bug 1818285 in ubiquity (Ubuntu Disco) "[disco desktop] Installation fails with parted_server: No data in infifo. parted_server: Line 2387. CRITICAL ERROR!!! EXITING." [Critical,Confirmed]
<tsimonq2> What is the copyright holder for Bileto? I assume Canonical Ltd, but what should I put for e.g. Year?
<tsimonq2> I'm working on a project that involves reusing some Bileto code and I want to make sure I'm dotting my Is and crossing my Ts.
#ubuntu-devel 2019-03-05
<cjwatson> sil2100 (CC seb128, wgrant): LP's language pack exports for disco look sensible.  I suggest going ahead and doing a langpack packages build from them.  Any objection to me unhiding translations for disco?
<seb128> cjwatson, I though I did that last week?
<cjwatson> seb128: Oh.  You disregarded the order on the process wiki page :)
<cjwatson> (https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings)
<seb128> ah, sorry
<cjwatson> Should be no harm done; that part of the process is much less delicate than the start
<seb128> k
<seb128> cjwatson, but do you know what team has access to the +admin from translations? I think I used to have access to that page (is that the one where there is the box telling if the next export is a full one or a delta?)
<sil2100> Seeing that we have the first full language export already, let me kick some base langpacks in some moments
<seb128> speaking of langpacks, I got an email of someone wondering why 18.10 isn't getting weejkly ppa updates
<seb128> is that something we should have set up and didn't?
<cjwatson> seb128: ~ubuntu-translations-coordinators and ~rosetta-admins, I think
<Laney> mwhudson: hah
<cjwatson> mvo: just a post-sprint reminder to cut down the set of Commands files on cnf-extractor.internal and to tell me what the client actually uses :)
<Laney> cjwatson: thanks for that merge
 * Laney notices that partman-base is quite far behind in Ubuntu and screams
<Laney> WOH someone did actually just merge it
<cjwatson> NP.  Good luck with that merge ...
<cjwatson> Oh, hah
<mvo> cjwatson: thanks! sorry for letting you wait on this, I was on vac but will get to it today :)
 * Laney hugs xnox 
<cjwatson> mvo: It's OK, so was I
<Laney> oh right, it was more or less just translations
<xnox> and i was away on leave =) back today =)
<Laney> :>
<cpaelzer> jbicha: juliank; mitya57: vorlon: I have seen that all of you hit retest for tryton-server blocking various things. I haven't found a bug about it at the tryton-server package nor does the issue trigger when run in a local VM
<juliank> It's an odd thing
<cpaelzer> is there any insight on what is going on there already - after all it is a cross-arch segfault which is odd
<mitya57> cpaelzer: it succeeds if you retry it with all-proposed=1, that pulls sqlite3 from -proposed
<juliank> it passes in Debian, but used to crash there too
<mitya57> see Debian #923038
<ubottu> Debian bug 923038 in libsqlite3-0 "tryton-server tests segfault with sqlite 3.27.1" [Important,Fixed] http://bugs.debian.org/923038
<cpaelzer> mitya57: that might be why it passes for me atm, thanks mitya57
<juliank> well, that's helpful
<cpaelzer> mitya57: but I see you had triggered sphinx with sqlite3/3.27.2-1 and it still failed a few times
<cpaelzer> mitya57: what made the difference eventually?
<mitya57> cpaelzer: sqlite3 is part of base chroot so adding it to triggers does not actually upgrade it. Only all-proposed=1 makes it really use the proposed sqlite3.
<cpaelzer> thanks
<jbicha> ooh, thanks :)
<dja> ddstreet: sorry about the chaos for LP: #1818340 ! Was not my intention to leave you with that sort of time bomb!
<ubottu> Launchpad bug 1818340 in systemd (Ubuntu Cosmic) "systemd-networkd core dumps in bionic-proposed" [Critical,In progress] https://launchpad.net/bugs/1818340
<dja> ddstreet: by the way, is there anything in git-ubuntu to make dealing with quilt less painful? Like to turn a git patch into a debian/patches/ patch? I ended up doing it with a bunch of awful intermediate steps when I was working on the original bug and have lost all the command history, so I sort of gave up for this.
<ddstreet> dja no prob, it happens :)
<ddstreet> re: git ubuntu, i dont think there is anything yet that easily will turn normal git patches that you've applied already into d/p/ patches
<ddstreet> you can just quilt import a git patch, but of course if it needs adjustment, the quilt push will fail and you'll have to hand-edit it, which can be quite annoying
<dja> Ah I wonder why I never thought of that
<dja> or maybe I did and they just never worked
<dja> oh well
<dja> It's late here so I will be interested to read your comments on the bug tomorrow!
<ddstreet> yep, i'll try to dig into it and see what i can find :)
<ddstreet> thnx!
<cjwatson> git-dpm and git-buildpackage both have various approaches to let you work on a separate patched branch and have that be automatically serialised into debian/patches/.  If you use those systematically then you never have to touch quilt.  Do read the documentation in depth first though.
 * juliank loves gbp pq
<juliank> One thing I don't like is that it reexports unmodified patches, so you can't just import the patches, and add your own when you want to make a change on a package not using it
<juliank> because you get unrelated changes that way
<rbasak> tjaalton: just glanced at your libxkbcommon upload to Bionic. While you're fixing up the changelog, I'm of the opinion that the changelog should explain what is being fixed in the SRU itself, since users actually read those.
<tjaalton> rbasak: alright
<rbasak> Like "sync packaging to allow coinstallation of i386 and amd64 (LP: #XXXXXX)" or similar would be better for example.
<rbasak> I'm interested to know if others on the SRU team would agree.
<tjaalton> I'll just copy the entry from 0.8.0-2
<rbasak> (so this isn't a hard reject if someone else thinks that's OK, etc)
<tjaalton> and upload again
<tjaalton> no big deal
<tjaalton> it should show on the diff though, but I know users don't read that far
<rbasak> Agreed. I'd prefer users to want to take SRUs, rather than react with "yet another SRU? why?!"
<rbasak> Thanks :)
<tjaalton> dropped the old one too
<rbalint> i would like to create the ubuntu-wsl metapackage (to help us adding utilities later) but i can't find any process for that
<rbalint> should i just go ahead and prepare and upload it and let the archive admins decide or i should update ubuntu-meta?
<rbalint> btw is there a vcs for ubuntu-meta?
<rbasak> I'm not very familiar with ubuntu-meta. I have only used it to regenerate seed-generated metapackages.
<rbasak> I don't believe there's a VCS.
<rbasak> Does ubuntu-meta do non-seed-based metapackages? I' m not aware of that.
<cjwatson> It's of course technically possible but IMO it shouldn't.  If you want something in ubuntu-meta, add a seed for it
<rbalint> cjwatson, i'm ready to do that if that's the process
<cjwatson> There at least never used to be a VCS for ubuntu-meta because so much of it was autogenerated that there didn't seem a great deal of point
<rbalint> rbasak, cjwatson, since i need to add ubuntu-wsl to ubuntu-meta's i guess i need to update the seed first, then upload an updated ubuntu-meta
<juliank> I was just wondering: How would I i18n a string like "%d updates are available, %d are security updates"
<juliank> There are variants for each %d
<rbalint> cjwatson, my imagined point would be to agree on a change first before it hits the archive
<juliank> like this one needs 4 variants in english
<rbasak> juliank: some discussion here: https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html
<sil2100> cjwatson, seb128: base langpack importer is running
<seb128> sil2100, great
<rbalint> cjwatson, rbasak i'm adding the wsl seed, i hope it is ok this way https://code.launchpad.net/~rbalint/ubuntu-seeds/+git/platform/+merge/364003
<infinity> rbalint: There seems to be a lot of duplication there with minimal.
<infinity> rbalint: Is this all to avoid having init?
<rbalint> infinity, yes there is a lot of duplication with minimal, but wsl does not need initramfs-tools
<rbalint> infinity, no, it is about pulling in wslu and pulling in packages later when they show up in the archive
<rbalint> infinity,  minimal is too much for wsl
#ubuntu-devel 2019-03-06
<dja> cjwatson: thanks, at some point I'll look that up - I don't do much packaging in my new role
<Guest56578> Hrm. Someone should do something about the gvfs autopkgtest on s390x.
<tsimonq2> This is curious to me: https://launchpad.net/ubuntu/+source/lubuntu-default-settings/19.04.1 - in the changelog and in source.changes there is "Hans P. MÃ¶ller <EMAIL>" yet Launchpad shows it as "EMAIL (Hans P. MÃ¶ller)" - what's up here?
<sarnold> you noticed seconds after it was uploaded, heh  :)
<tsimonq2> Because I'm the one that uploaded it ;)
<sarnold> I wondered if the umlaut was the cause, but an Ã© didn't appear to cause the email (name) view on https://launchpad.net/ubuntu/+source/lxd/1:0.4
<tsimonq2> It might be the umlaut, either that or the .
<tsimonq2> That's probably something cjwatson would know ;)
<Unit193> Someone should really take care of pastebinit and Debian 916372
<ubottu> Debian bug 916372 in pastebinit "pastebinit: multiple deprecation warnings under Python 3.7" [Normal,Open] http://bugs.debian.org/916372
<tsimonq2> It's not the umlaut: https://launchpad.net/ubuntu/+source/software-properties/0.97.8
<Unit193> Aka LP 1812232
<ubottu> Launchpad bug 1812232 in pastebinit (Ubuntu) "Deprecation warnings" [Undecided,Confirmed] https://launchpad.net/bugs/1812232
<tsimonq2> stgraber: ^
<tsimonq2> Unit193: Would you like to start an NMU process in Debian?
<tsimonq2> I will be happy to sponsor if you do the paperwork.
<sarnold> python :(
<tsimonq2> sarnold: That's news? :)
<sarnold> tsimonq2: just a recurring sadness
<sarnold> every release breaks *something*
<tsimonq2> There's worse packages...
 * tsimonq2 glares at glibc.
<sarnold> most of those are accidents though :)
<tsimonq2> HAH
<tsimonq2> I mean, you're not exactly *wrong*.
<Unit193> tsimonq2: Not really.
<tsimonq2> I'll do it then
<cjwatson> tsimonq2: It's the dot.  See https://git.launchpad.net/launchpad/tree/lib/lp/archiveuploader/utils.py#n229
<ogra> wow, so screen *actually* has a fixed list of baud-rates it supports ... adding the 1500000 to the supported list makes it work with my rockchip board
<ogra> (and oddly enough screen generates it C source from shell scripts dynamically during build ... so weird)
<andrewsh[m]> hi everyone
<andrewsh[m]> somethingâs changed, and when I compile Unity, I get:
<andrewsh[m]> /usr/local/bin/cc -g -O2 -fdebug-prefix-map=/home/andrewsh/projects/unity=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create  -Wl,-Bsymbolic-functions -Wl,-z,relro  -rdynamic CMakeFiles/cmTC_b30f1.dir/CheckFunctionExists.c.o  -o cmTC_b30f1 -lpthreads
<andrewsh[m]> /usr/bin/ld: cannot find -lpthreads
<cjwatson> It surely ought to be -lpthread?
<cjwatson> Even xenial didn't have a libpthreads AFAICS
<cjwatson> I think this must mean that some bit of configure-time checking is failing to detect the actual pthread machinery and falling back to -lpthreads which really belongs to some other OS
<cjwatson> So you probably want to debug the configure-time stuff (cmake or whatever) rather than that link line directly
<cjwatson> (Also it should actually end up being -pthread rather than -lpthread IIRC)
<cjwatson> It might just be a missing -dev package.  Web-searching for "lpthreads" finds e.g. https://stackoverflow.com/questions/31948521/building-error-using-cmake-cannot-find-lpthreads which is a similar sort of tale of woe with that kind of solution
<andrewsh[m]> strange thing, there's no mention of libpthreads anywhere in the source
<andrewsh[m]> $ grep pthreads -R * | grep -v obj-x86_64-linux-gnu | wc -l
<andrewsh[m]> 0
<cjwatson> andrewsh[m]: Maybe in some imported cmake module
<cjwatson> andrewsh[m]: e.g. look at   dpkg -L cmake-data | xargs grep -s pthreads
<cjwatson> Perhaps FindThreads.cmake
<cjwatson> Anyway it's hopefully somewhat clear from the cmake output ...
<andrewsh[m]> well, yes, but why does it fail to find pthread
<andrewsh[m]> weird
<andrewsh[m]> -- Found Threads: TRUE
<andrewsh[m]> I guess I need to set up sbuild ð
<andrewsh[m]> right, sbuild-createchroot went just fine
<cjwatson> rbalint: Please don't use the "Resubmit" vote on merge proposals to mean "I have addressed your comments".  It means "this merge proposal needs to be put together completely differently and resubmitted from scratch".
<ahasenack> doko: hi, could you take a quick look at https://launchpad.net/~ahasenack/+archive/ubuntu/samba-4.10/+packages to see if dependency-wise they match our expectations wrt python2/python3?
<ahasenack> doko: samba in there only uses python3 now, no py2 dependency as far as I can see
<ahasenack> the others (tdb, ldb, etc) have a mix, I chose to use both py2 and py3, and each dep is in its own package
<ahasenack> I will cleanup the d/changelog entries now, some have a few "wip" entries and others I can squash together
<doko> ahasenack: will do after lunch
<ahasenack> ok
<rbasak> jamespage: o/
<jamespage> irc proxy dropped off - not clear...
<rbasak> So on bug 1814911, a few things don't seem right to me, so I wanted to discuss.
<ubottu> bug 1814911 in python-urllib3 (Ubuntu Xenial) "charm deployment fails, when using self-signed certificate, which has IP address only (SAN)" [High,Triaged] https://launchpad.net/bugs/1814911
<jamespage> rbasak: morning
<rbasak> First, it doesn't feel right to be changing the dependency structure in an SRU for a feature, unless we're specifically trying to add that feature in the SRU directly, which I'm not sure we are? I think you alluded to that feeling in comment 4? Anyway, that's why I have other questions.
<rbasak> The SRU user impact says that Trusty isn't really affected - is that still true?
<rbasak> I'm sorry, that Xenial isn't really affected.
<rbasak> jamespage: also, in comment 11, you tested to see if an upgrade would bring in the recommends, but you used "apt install" which I think could be different from "apt upgrade"?
<rbasak> So will adding the Recommends really work?
<rbasak> And then finally, back to my first point - is this something that we really want, or could it be worked around in charms for old releases?
<doko> oSoMoN: fyi, we are aiming for the openjdk-11 transition at the end of March. so LO may stay a little bit longer in -proposed ...
<jamespage> rbasak: more than 1 month ago - need to refresh memory
<doko> oSoMoN: ohh, not sure if you know that: https://hubicka.blogspot.com/2016/03/building-libreoffice-with-gcc-6-and-lto.html
<oSoMoN> doko, no, I didn't know, reading now, thanks!
<jamespage> rbasak: the recommends does not exist in xenial BUT python-ipaddress is already installed on a xenial base image I think
<rbalint> cjwatson, ok, sorry for the wrong vote
<jamespage> so a happy co-incidence means that stuff works OK on xenial, but not on trusty, where python-ipaddress is not installed
<jamespage> rbasak: I'm actually OK with marking the xenial task as invalid - I fixed the UCA part with a UCA specific patch which we auto-apply to add the recommends
<rbasak> jamespage: OK - but it's currently in Xenial unapproved and not in Trusty unapproved.
<jamespage> rbasak: that's true - but this is a UCA specific issue on trusty, not a general trusty issue
<rbasak> I see, OK.
<jamespage> rbasak: xenial feeds trusty/mitaka in the UCA
<rbasak> ah
<rbasak> I think I understand the situation then, thanks.
<rbasak> Are we in agreement to drop the Xenial SRU then? I'm still open to it if you want to push for it; I would prefer not to do it though.
<jamespage> rbasak: updated bug
<rbasak> Thanks!
<rbasak> I'll reject from the queue then.
<jamespage> +!
<jamespage> 1 rather
<LocutusOfBorg> seb128, do you think we should reupload a new poppler with this fix? 0.71.0-3 looks like the regression is not fixed...
<LocutusOfBorg> (in the new upstream release)
<seb128> LocutusOfBorg, "this fix"?
<seb128> sorry I lack context
<LocutusOfBorg> https://packages.qa.debian.org/p/poppler/news/20190302T103433Z.html
<LocutusOfBorg> the new 0.71.0-3 has a fix that is not included in our ubuntu package
<LocutusOfBorg> while the other patch might be useless
<doko> LocutusOfBorg: did you see my virtualbox pings?
<seb128> LocutusOfBorg, we have 0.74 in proposed, we can't bypass that to land a fix in the disco pocket
<LocutusOfBorg> doko, nope! where are them?
<LocutusOfBorg> seb128, I mean, upload a new 0.74 in proposed with that patch
<LocutusOfBorg> how long will it take to migrate?
<seb128> no idea
<doko> LocutusOfBorg: your virtualbox-hwe (and most likely virtualbox as well) ftbfs in bionic-proposed
<LocutusOfBorg> why the hell did it work on my ppa
<LocutusOfBorg> damn
<LocutusOfBorg> kmk: /usr/lib/jvm/default-java/bin/wsimport: Command not found
<LocutusOfBorg> kmk: *** [/<<PKGBUILDDIR>>/src/VBox/Main/webservice/Makefile.kmk:468: /<<PKGBUILDDIR>>/out/obj/vboxjws-gen/jwsgen/jwsglue.list.ts] Error 127
<LocutusOfBorg> kmk: *** Waiting for unfinished jobs....
<LocutusOfBorg> JAVA, what else is to blame?
<doko> LocutusOfBorg: openjdk-11, please fix
<seb128> LocutusOfBorg, I'm going to include that in the new upload, would be nice if upstream reviewed/merged it though
<tdaitx> LocutusOfBorg: for wsimport please take a look at wsimport.sh from jaxws-ri (https://sources.debian.org/src/jaxws/2.3.0.2-1/jaxws-ri/bundles/jaxws-ri/src/main/resources/bin/wsimport.sh/)
<LocutusOfBorg> tdaitx, I think we need some backported jaxstuff
<LocutusOfBorg> yeah
<LocutusOfBorg> I did that in my ppa already
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/virtualbox-ppa
<LocutusOfBorg> but having a fix doesn't make java less ugly
<doko> LocutusOfBorg: all these are in bionic-proposed
<LocutusOfBorg> yep
<LocutusOfBorg> thanks!
<LocutusOfBorg> seb128, the utf patch might be worse than the upstream already available version https://gitlab.freedesktop.org/poppler/poppler/merge_requests/133/diffs
<LocutusOfBorg> the other patch is currently proposed upstream https://gitlab.freedesktop.org/poppler/poppler/merge_requests/189
<doko> LocutusOfBorg: please prepare packages, then I'll build those against the -security pocket, and binary-copy those to -proposed
<seb128> LocutusOfBorg, right
<doko> ahasenack: why build 2 and 3 in parallel? I would just remove 2
<doko> -rw-r--r-- root/root       353 2019-02-26 20:38 ./usr/lib/x86_64-linux-gnu/pkgconfig/pytalloc-util.cpython-37m-x86_64-linux-gnu.pc
<doko> please check the pkgconfig files. these are bogus. and I think if you just build with python3 it's called like the python2 one
<ahasenack> doko: you rather we get rid completely of python2 in these deps too? talloc, tdb, ldb?
<ahasenack> I would have to check the reverse-depends then, see if they can all use python3, no?
<xnox> ahasenack, my personal plan for next cycle is to yeah, start killing all the leaf python2 things if python3 exists, and i don't think there are that many reverse-deps for samba stack, as in, isn't it mostly self-contained?
<ahasenack> it's the deps
<ahasenack> like ldb, used by sssd
<ahasenack> tdb I think also is used elsewhere
<ahasenack> bzr-git pulls in python-tdb
<ahasenack> and I think that's the only one
<ahasenack> talloc and ldb are self contained in terms of reverse-depends
<ahasenack> doko: ^
<nacc> ahasenack: and that's a reverse-recommends
<ahasenack> xnox: ^
<nacc> ahasenack: not a depends
<ahasenack> oh, right
<ahasenack> so a) drop that to a suggests; b) get rid of python2-*?
<nacc> python-samba rev-deps on python-tdb, but that's it
<xnox> drop them.
<ahasenack> hi nacc, btw :)
<nacc> ahasenack: hiya :)
<xnox> plus we probably gonna move to brz-git soon which is python3
<nacc> heh
<ahasenack> brz
<ahasenack> heh
<nacc> xnox: whose clever naming is that?
<ahasenack> xnox: so (a) for bzr-git?
<xnox> nacc, well they had to fork the name to escale the cla. and it does do a provides alternative bzr
<xnox> breezy is the name
<xnox> https://launchpad.net/brz i don't know which one of them came up with the name
<seb128> vorlon, can you review fwupd-signed in cosmic SRU queue? the upload from friday failed binary upload because the package compute a binary version that is different from the source, and while 1.2ubuntu > 1.2 ... 1.2ubuntu+fwdupversion <  1.2 +fwdupversion
<seb128> vorlon, which I workarounded now by changing to 1.2.0ubuntu...
<vorlon> seb128: done
<seb128> vorlon, thx
<ahasenack> doko: after ./configure, make, make install, this is the layout with just python3: https://pastebin.ubuntu.com/p/DvrYypz2w5/
<ahasenack> the pkgconfig name mangling is there. is that really wrong, or just an annoyance?
<doko> ahasenack: I would say, this is wrong, but yes it's upstream. so maybe leave that, and provide a symlink pytalloc-util.pc ?
<ahasenack> sorry, my connection dropped, not sure if you replied
<sarnold> < doko> ahasenack: I would say, this is wrong, but yes it's upstream. so maybe leave that, and  provide a symlink pytalloc-util.pc ?
<ahasenack> sarnold: thanks
<ahasenack> doko: the build-depends on python{,3}-talloc-dev seem to come just from samba itself, ldb and tevent, aka, the "samba ecosystem", and they seem to build fine with that pkgconfig
<ahasenack> how about I leave it as is, make sure I rebuild everything once I got rid of py2 in all these packages, and see if it breaks?
<doko> ahasenack: fine with me
<doko> ahasenack: and you can remove me dependency work around for talloc
<doko> my ...
<directhex> ok, so if i want to file a kernel bug using `apport-bug linux` I get a small (3K) apport log which basically only contains a list of package dependencies. if i want to append an existing bug with `apport-collect existing-kernel-bug` I get a huge 0.5MB report with loads of info - lspci, dmi info, etc. how can i get apport-bug to make a big log for a new kernel bug?
<directhex> it's a networking issue, so i can't use apport-collect whilst booted into the bad kernel
<directhex> aha, cracked it - had to copy the source_linux.py hook to source_linux-hwe.py
<sarnold> aha :)
<directhex> sadly not, you can no longer use ubuntu-bug, apport-cli, etc, to attach an apport report to an existing bug. they all tell you you _must_ use apport-collect to do that, but you can't use apport-collect offline
<directhex> so it's not possible to file attachments to networking bugs ð¤·
<nacc> directhex: can't you use apport-bug --save ?
<nacc> directhex: or apport-cli?
<directhex> apport-cli: error: -u/--update-bug option cannot be used together with options for a new report
<directhex> apparently not.
<xnox> popey, i lack powers! give me morrrrre powers please =)
<mwhudson> good morning
<ahasenack> hi mwhudson
<nacc> directhex: what options did you specify? did you read the manpges, etc.
<nacc> directhex: specifically, you use --save, then file --crash-file with -u, which is specifically mentioned in the manpage for netowrking related issues
<directhex> $ apport-cli -u 1818294 -c ./apport.linux-image-4.15.0-46-generic.lz35uk5j.apport
<nacc> directhex: further, i think you want #ubuntu :)
<infinity> powersj: Yo.
<powersj> infinity, hey I heard you want rails ownership
<infinity> Don't make me start kicking people from this channel too.
<powersj> :D
<mwhudson> don't believe anything Odd_Bloke says
<infinity> powersj: Is the "untested" state of the trusty.6 server ISOs accurate, or is the state actually "tested, but we haven't bothered posting results yet"?
<infinity> powersj: (Asking because I wouldn't mind fixing a small PPC bug, which would trigger a respin of the server world, but I won't bother if it's all tested already)
<powersj> infinity, the latter paride needs to update it. When we chatted this morning he was a go for release
<infinity> powersj: Okay, I will just let my buglet live on then.
<infinity> It was there in .5 too, I just apparently failed to notice, or didn't care enough to fix it.
<infinity> Turns out this doesn't work so well with 4.4 kernels:
<infinity>         case "$KERNEL_MAJOR" in
<infinity>             2.6|3.*)
<infinity> Derp.
<powersj> heh
<mwhudson> i wonder how many things are going to break now that disco has 5
<mwhudson> you'd hope we'd learn that lesson eventually...
<infinity> We learned some lessons with 2->3 and learned a lot harder with 3->4.
<infinity> I don't expect 5 to be much of an event.
<infinity> mwhudson: But also, doesn't everyone run in the --uname-2.6 personality to just fix all the bugs? :)
<infinity> nosferatu:~$ linux64 --uname-2.6 uname -r
<infinity> 2.6.79-13-lowlatency
<infinity> Problem solved.
<infinity> LP buildds ran in that personality for years while we hunted down everything that 3.0 broke.
<mwhudson> infinity: omg what
<mwhudson> i had no idea that was a thing
<vorlon> I run in the SCOSVR3 personality to fix all the bugs
<infinity> 13:48 < infinity> Don't make me start kicking people from this channel too.
<vorlon> I have legitimately used the OSF4 personality before... but not this decade
<mwhudson> what does Task-Key: do in seeds?
<mwhudson> i am confused by the way the cloud-image seed has Task-Key: cloud-init
<mwhudson> but e.g. open-sshserver has "cloud-image" not "cloud-init" in Task
<infinity> mwhudson: Task-Key is a hint to tasksel.  It's mostly useless these days.
<infinity> mwhudson: But rgrep 'Key' in the tasksel source if curious.
<mwhudson> infinity: seed_from_task in livecd-rootfs looks for it
<mwhudson> but i wonder if it shouldn't
<mwhudson> uh was that part of the big branch i reviewed
<mwhudson> seems likely
<infinity> Yup.
<infinity> git blame puts it at 1ab78e78
<mwhudson> yeah
<mwhudson> ok time to re-review that bit of that branch :)
<infinity> For tasks with metapackages, Task-Key should be the metapackage itself, so it probably does what jibel wanted in the cases he wanted it.
<infinity> But that's more luck than design.
<mwhudson> the name that ends up in Task: in Packages is just the name of the seed, right?
<infinity> Yeah.
<mwhudson> so seed_from_task should probably just be echo $1
<infinity> Well, ish.
<mwhudson> depending on what it's actually used for
<infinity> If by "seed" he means "the file called 'desktop'", then it's more complicated than you make out.
<mwhudson> now what about Task-Per-Derivative
<infinity> Cause ubuntu-desktop == ubuntu/desktop
<infinity> Task-Per-Derivative is what defines if the "desktop" file is "desktop" or "$flavour-desktop"
<infinity> bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-archive-publishing/
<infinity> lib/scripts/generate_extra_overrides.py
<infinity> getTaskName() and getTaskSeeds()
<infinity> That's the definitive UTSL documentation of how this works.
<mwhudson> hnngh
<mwhudson> i guess that is the relevant code
<mwhudson> because when you say
<mwhudson> add_task install foo
<mwhudson> that ultimately finds the packages from the foo seed by looking for foo in the Task field in Packages
<infinity> s/seed/task/ :P
<mwhudson> yes
<infinity> We never address anything by seed.  Seeds are a backroom implementation detail.
<infinity> And attempting to refer back to them after the fact might well be the real mistake here.
<mwhudson> so we want to find the snaps that wouold have the foo in their task field if that was a thing
<infinity> But I need tacos more than I need opinions.
<mwhudson> maybe germinate needs to spit some more stuff out?
 * mwhudson tries to figure out if this worked any less by accident before jibel's branch
<mwhudson> hm don't think so
<mwhudson> oh right, the way to get snaps installed in a layered vs non-layered builds are basically disjoint
<mwhudson> perrrobably should make that a bit more obvious
<bdmurray> Why are distro-info-data stable updates also in security?
<sarnold> it's fair game for folks to run with -security only
<bdmurray> so if I have an SRU for it then you'd want to put it in -security?
<sarnold> probably; I
<sarnold> I've never done one myself so I'm not sure the criteria to use :) but if it's important for upgrading from one distro to the next, then it'd probably be a good candidate
<bdmurray> Its not so I still wonder why its in -security. The update just added Disco.
#ubuntu-devel 2019-03-07
<vorlon> bdmurray: certain dev tools fail to work on older releases if the new release name isn't known via distro-info; but I'm not sure why we require that to work in a security-only environment
<nisstyre> Does Ubuntu backport bug fixes in libraries or do they just rely on the Debian maintainers? If it's purely Debian, do they only backport security fixes generally, or any kind of bug fixes?
<nisstyre> Just curious how that works
<sarnold> nisstyre: you can skim a huge number of changelogs pretty quickly at https://lists.ubuntu.com/archives/bionic-changes/ to get a feeling for what gets fixed when
<nisstyre> sarnold: cool thanks for the link
<Unit193> Canonical peeps basically maintain stuff in main, and "the community" takes care of universe (which tends to mean that stuff gets a bit ignored, but really just depends.)  I have seen an update basically get sync'd from Debian, but often that's not quite how it works (if for no other reason than version scheme differs.)
<nisstyre> Unit193: I see. I'm guessing the process for adding packages to universe basically depends on someone creating a PPA and then it becoming popular/used a lot?
<Unit193> nisstyre: Universe is comprised of everything not in main, main is basically the stuff on the main Ubuntu flavor as well as the server set (with some additions, usually because infra stuff uses it.)
<Unit193> One can actually add something to the repo that isn't in Debian, but that usually has a team looking after it or whatnot.
<nisstyre> makes sense
<nisstyre> I'm coming from Arch Linux (beeng using it for the past decade basically), and I'm trying to get more familiar with Ubuntu since I've got to start using it for my work machine now.
<Unit193> A community member doing a security update usually means someone that can read the wiki page, file a bug on LP, attach a debdiff, and find a sponsor (sub them to the bug), so it's not specifically that hard.  I've done it a few times.
<mwhudson> does anyone know how the default mirror selection works in either d-i or ubiquity? is it just http://geoip.ubuntu.com/lookup and then $CountryCode.{archive,ports}.ubuntu.com ?
<seb128> sil2100: hey, please don't copy bug #1740894 to bionic-updates if you didn't do it yet
<ubottu> bug 1740894 in xkeyboard-config (Ubuntu Bionic) "KEY_RFKILL is not passed to userspace" [Low,Fix committed] https://launchpad.net/bugs/1740894
<sil2100> seb128: hm, just did cosmic for now
<sil2100> seb128: are we still missing the systemd changes?
<sil2100> seb128: I mean, seeing that the bug got switched to verification-done (and had no other open tasks), I thought it's good to go
<sil2100> I'll wait with bionic
<seb128> sil2100: I'm in meetings in London today, but my understanding is that the regression isn't fixed, they likely verified that the fix does work on those models that didn't work but that doesn't tell us that it's not sitll breaking the models that used to work
<xnox> doko, vorlon - my understanding is that if one specifies 'skippable' in debian/tests/control Restrictions; one can exit 77 to skip
<xnox> doko, vorlon - i recall you mentioning something like that, but "it didn't work on our infra" or something?
<xnox> doko, vorlon - do we need to fix things in the webui and/or autopkgtest-cloud?
<xnox> Laney, ^^^ might be interesting
<Laney> xnox: should work, some tests use that already
<ricotz> hello, is there a reason why there are no updates here http://cdimage.ubuntu.com/bionic/daily-live/ ?
<Laney> we might not interpret the results in the best way in all circumstances tho
<doko> oSoMoN: uploaded LO again to the apps PPA, we were missing debug symbols in this ppa
<oSoMoN> ack
<xnox> Laney, gotcha
<ahasenack> doko: hi, did you get my last yesterday? bzr-git has a Recommends on python-tdb. We either drop that (and break bzr-git somewhat?), or keep building python-tdb (py2)
<doko> ahasenack: I didn't check, is this a useful thing?
<ahasenack> doko: don't know, not my package (bzr-git)
<ahasenack> someone in the internet always finds something useful
<rbasak> Is another option to demote it?
<rbasak> Oh, it's already in universe. So I guess not.
<rbasak> Keep building python-tdb but leave it in universe maybe? Would that work?
<ahasenack> rbasak: yes, I was just checking what build-requires python-tdb, and it's just bzr-git, ldb (for python-ldb probably, which we don't build anymorE) and samba itself
<ahasenack> I would just have to revert my revert again :)
<ahasenack> that's why I kept building python2, to avoid introducing bigger changes
<ahasenack> my thinking was we could just move all of the python(2) packages to universe in this first step
<ahasenack> doko: everything else in that ppa is py3 now (even tdb, but I will rebuild it with py2 *and* py3 due to bzr-git)
<rbasak> ahasenack: might be worth leaving a "uses py2" bug open against bzr-git?
<ahasenack> I think we should have worked with the previous packages the way they were, building both py2 and py3
<ahasenack> and later figure this out
<ahasenack> but, too late now
<ahasenack> I just don't want to keep dragging this for too long, since it's an FFe already
<ahasenack> beta freeze in march 28th
<cjwatson> bzr-git's tdb thing is used by LP
<cjwatson> for git-to-bzr code imports
<cjwatson> this doesn't mean you should block on it, since we maintain our own copies of the modules we need, just FYI on what sorts of things it's used for
<ahasenack> cjwatson: thanks
<ahasenack> cjwatson: I think I can keep python-tdb around
<cjwatson> Like I say, LP doesn't need you to, though it's perhaps useful for people to be able to reproduce what imports do
<cjwatson> Though we'll hopefully get onto the breezy version in the medium term anyway
<rbasak> Breezy? :)
<cjwatson> Yes?
<cjwatson> Not sure I understand the question :)
<rbasak> Oh
<rbasak> You mean https://en.wikipedia.org/wiki/Breezy_(software)
<cjwatson> Yes
<rbasak> I thought you meant https://en.wikipedia.org/wiki/Breezy_Badger#Ubuntu_5.10_(Breezy_Badger) :-)
<rbasak> (well, obviously you didn't, hence the question)
<rbasak> Eickmeyer: in what way is the process for becoming a Per-Package Uploader convulated? How do you think we should change it?
<Eickmeyer> rbasak: I think it needs to be more clear-cut and better defined. (BTW, that application is still work-in-progress, that might change. I may have been venting a little/in full panic mode considering Ubuntu Studio's status being in danger).
<rbasak> Eickmeyer: well OK, but what about the current process isn't clear cut or clearly defined?
<Eickmeyer> rbasak: The minimum number of packages and experience required doesn't seem to be defined, at least not that I could see.
<Eickmeyer> Or, the minimum number of sponsors required.
<rbasak> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<rbasak> "There is no minimum number of sponsored uploads into the archive that you need to have. You need to have demonstrated enough previous work to be able to assure your endorsers that you can be trusted with unsupervised upload access to the primary archive."
<Eickmeyer> rbasak: I'm actually in the process of eliminating that line from my application right now, as it was written out of frustration/panic.
<Eickmeyer> Doing that since I have not yet formally applied.
<rbasak> OK. You absolutely are allowed to have that line, FWIW. We want feedback on making the process better.
<Eickmeyer> rbasak: I actually changed it to be more about bureaucracy with a little addage about undertanding why it exists, but I have no idea how to improve that. I have a degree in leadership, so different leadership styles and organizations is something I understand pretty well.
<rbasak> Eickmeyer: what bureaucracy? No, really. All we want is for you to write down why you need upload (obvious in this case) and demonstrate that you know what you're doing, and we'll consider it in a meeting.
<rbasak> For exceptional circumstances such as this, I think you'll find that we can stretch quite a bit.
<rbasak> So far, the problem is that nobody has talked to us about it since we all agreed what you needed to do in 2016.
<rbasak> You can't pin that on bureaucracy.
<Eickmeyer> rbasak: Okay.
<Eickmeyer> rbasak: I fixed that. Take a look at the line now, tl;dr: that Ubuntu Studio hasn't had an uploder in several cycles, and not knowing we were required to have one.
<rbasak> Eickmeyer: that's fine, but to be clear, I'm not trying to adjust your opinion in your application, or requiring that your application say the right thing or anything. I'd like to think that I won't hold your opinion against you in your application regardless of whether you state it.
<Eickmeyer> rbasak: I appreciate that.
<rbasak> Eickmeyer: separately from that, I'm frustrated that the current situation seems to be being taken the wrong way. I want to fix it, but I'd like us to end up on the same page about what is wrong and what needs to be addressed in the process (independent of your application)
<Eickmeyer> rbasak: I appreciate that as well. I wish I had been alerted that this problem existed earlier. This all happened as a result of me seeking sponsorship, which I thought was the proper way, since that's what had been done for several cycles earlier.
<ahasenack> vorlon: hi, samba 4.10 FFe, which also lists the other 4 FFes that are needed for its dependencies: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1818518
<ubottu> Launchpad bug 1818518 in samba (Ubuntu) "FFe: samba 4.10.0" [Undecided,New]
<rbasak> Eickmeyer: so, with that in mind, what I'm trying to get to is that, while welcoming criticism, I also have the expectation that they are adjusted as needed so that they are well thought out and identify specifics.
<rbasak> Eickmeyer: yeah. I understand you weren't involved the last time this came up, and that you've been thrown in the deep end.
<rbasak> It wasn't because you requested sponsorship. It's that Steve happened to notice and be reminded because you spoke up.
<rbasak> It's perhaps not appropriate to have caused you to feel like it was your fault somehow.
<rbasak> vorlon: ^
<Eickmeyer> The thought has crossed my mind that I should've kept my mouth shut, but in reality, I know that would've been improper.
<Eickmeyer> rbasak: Thanks for your help, by the way. I really appreciate it, and I appreciate you asking me the tough questions, and forcing me to think through my application. :)
<rbasak> Eickmeyer: sorry, was in a meeting. You're welcome! We want more contributors :)
<rbasak> (and we want them to be able to upload themselves)
<vorlon> Eickmeyer: yes, I don't blame you for the current state of things; it would've been nice if you had happened to have escalated this sooner, but you didn't know there was a reason to.  If the TB fixes having a process of reviewing flavor status, this should be less of a fire drill in the future.
<Eickmeyer> vorlon, rbasak: Very much appreciated. I wish I had and known this needed to be escalated escalate this much sooner as well. I'm also glad it pointed-out an area that needed improvement.
<vorlon> yeah
<vorlon> Eickmeyer: from my perspective, it's an alarm bell that someone who's driving a flavor has to go begging for sponsorship from uploaders across the wider Ubuntu developer community
<vorlon> and that's what I'm trying to sort out, so that ubuntustudio can be self-sustaining and effective
<Eickmeyer> vorlon: Indeed. It seems to be the one missing piece of the puzzle. I hope that either myslf or Ross or both of us can fill that role. My application is in progress.
<vorlon> excellent!
<LocutusOfBorg> seb128, are you fixing poppler?
<LocutusOfBorg> lol I did the same lol :D
<seb128> what needs to be fixed in poppler?
<LocutusOfBorg> I think I fixed gdcm and gdal
<LocutusOfBorg> the last two blockers?
<LocutusOfBorg> I was fixing calligra, and I just discovered your upload sigh
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#disco/gdal/2.4.0+dfsg-1ubuntu1/buildlog
<seb128> oSoMoN said he was going to look at that earlier
<LocutusOfBorg> http://debomatic-i386.debian.net/distribution#disco/gdcm/2.8.8-6ubuntu2/buildlog
<seb128> check with him
<seb128> LocutusOfBorg: next time better to ask before starting to poke :)
<seb128> oSoMoN: ^ fyi
<LocutusOfBorg> sure! but meh, I said "lets do it while on train" :)
<LocutusOfBorg> its a work I started yesterday, this is why I didn't check again
<LocutusOfBorg> oSoMoN, the gdcm fix is trivial, https://github.com/malaterre/GDCM/pull/84
<LocutusOfBorg> you can avoid the build, I'm doing it in the above link (if successful)
<oSoMoN> LocutusOfBorg, thanks, I had come to the same conclusion, and have a local build currently running to verify that it's enough
<seb128> cjwatson: big thanks from the desktop team for the gitlab support :-)
<willcooke> thanks cjwatson!
<oSoMoN> LocutusOfBorg, are you uploading the fixes for gdal and gdcm, then?
<oSoMoN> I can't upload myself anyway
<oSoMoN> gotta go, bbiab
<seb128> oSoMoN: sorry if you had started and dupped work, it's annoying when it happens
<oSoMoN> LocutusOfBorg, thanks for the gdcm upload, are you going to do gdal as well?
#ubuntu-devel 2019-03-08
<lag> Good morning all
<lag> Is there anyone around who can speak about the Ubuntu Installer
<lag> I wish to discuss the possibility of adding a feature which selects an appropriate DTS file on boot - should probably be a Grub thing
<lag> cjwatson: Are you still Grubbing these days?
<cjwatson> lag: I still maintain it in Debian, but I don't maintain the Ubuntu packages any more
<lag> cjwatson: It sounds like everything it being moved to Debian anyway
<lag> cjwatson: I should say "back into"
<lag> cjwatson: Hopefully then upstream *cough* *cough*
<lag> cjwatson: ..
<cjwatson> lag: I don't think I can talk usefully about DTS stuff though
<lag> cjwatson: Do you know if anyone can?
<lag> cjwatson: There are some AArch64 platforms which require DTBs in order to boot
<cjwatson> lag: Maybe cyphermox or waveform
<cjwatson> lag: Or you could simply bring it up directly upstream
<lag> cjwatson: I think it's a distro thing - I can't see Grub carrying DTBs
<cjwatson> lag: It might not *carry* them, but surely it would need configuration support for them?
<lag> cjwatson: It would need to know where (in the Installer) to find them
<cjwatson> Anyway, this is the point when I can't usefully say more, sorry
<lag> cjwatson: :)
<cjwatson> I burned out of doing this stuff in Ubuntu four years ago :P
<lag> cjwatson: Thanks for getting back to me anyway
<lag> cjwatson: NW - I shall continue with Mathieu and Dave
<seb128> sladen: good morning. We got a new ubuntu font version, do you think you would have time to help with the package update (I'm not familiar with the process, is it documented somewhere?). I've opened bug #1819135 with the zip attached there
<ubottu> bug 1819135 in fonts-ubuntu (Ubuntu) "Update to 0.84 (includes a new thin version)" [Undecided,New] https://launchpad.net/bugs/1819135
<sladen> seb128: this is not a new version in the sense that you or I are used to.  This is a binary dump tossed over the wall, or unclear origin with correspondingly little insight into changes or regression potential.  Perhaps one could ask the provider of the binary blob to expand on its origins
<sladen> seb128: (in the meantime, I would plan on extracting only the file 'Ubuntu-Th.ttf', and toss that into the existing package)
<seb128> sladen: thx, indeed just adding the new file seems like easier ... should I just do that to start with?
<seb128> sladen: how did it work for updates in the past? Did we had those details? Or did we end up just taking the new blob, doing the testing we could do and uploading that?
<sladen> seb128: had a script that binary patched a bunch of easily-missed things; then some effort at manually regression-testing via a semi-private repo; the answer has been that the (various) blobs claiming to be '0.84' (or various other numbers) regressed too much in eg. vertical metric, or mono, or such.  (ie. unusable)
<sladen> seb128: the Thin shouldn't regress, because it did not exist before
<sladen> seb128: looking around at how this was done before   0.84+arabic-0ubuntu1~ppa0    0.91-0ubuntu~prerelease~nonfree   0.84~mono0.83+arabicfontconfig   were various attempts to deal with this in the past
<sladen> seb128: in a way that still made things vaguely sane to back out
<sladen> seb128: alternative would be  fonts-ubuntu-thin=0.84   as a separate micro-package
<seb128> sladen: ok, thx for the input, tricky indeed
<seb128> let's start with adding the new ttf then
<seb128> thx
<sladen> seb128: okay, if the md5 of that .ttf is  aa86b6  then it dates from  2015-10-19
<sladen> seb128: and originally Marcus wanted it for just print use within the design team.  Therefore, it is unhinted IIRC
<seb128> sladen: yes it is
<seb128> so that's why it wasn't included?
<sladen> seb128: think so.  (subject to hazy memory).  The reason why it is not in Google Fonts/Google Docs is simpler ... licence != SIL OFL
<sladen> seb128: which is a downstream requirement for new files
<sladen> seb128: actually, it has hint instructions (though this are ignored anyway, because the autohinter is used instead).  Fire at will, see what happens.  If being conservative, wait until 2019-04-19
<seb128> k
<sladen> sabdfl: ^^ if you're ready to make a pragmatic re-evaluation on the licence, everything would become a lot easier (Debian, G.Docs, ...)
<doko> ginggs: is cuda still requiring GCC 7?
<seb128> does anyone understands from update_output.txt what is still needed for poppler to migrate?
<Laney> gdal at least
<Laney> possibly only that, but hard to tell
<seb128> ha, LocutusOfBorg just reuploaded that one
<seb128> k, let's see once it's built
<LocutusOfBorg> seb128, yes, my intention wasn't to upload gdcm yesterday, it has been a wrong dput... and now osmon is not there so lets fixup
<seb128> LocutusOfBorg: thx
<LocutusOfBorg> sorry for the mess, nobody took care of finishing the transition for 15 days, and then we all focused on the same package :(
<seb128> no problem, it's a lesson to check on the channel with others before starting poking next time :)
<ginggs> doko: i think in debian yes, in ubuntu, possibly not - i'll doublecheck
<LocutusOfBorg> seb128, the problem is that when I travel on train, my internet sucks, so I download stuff and do it "offline"
<LocutusOfBorg> otherwise I might miss a lot of messages
<seb128> right, understandable
<LocutusOfBorg> sadly looks like the work started between me leaving the office, and me opening my laptop again on train :p :)
<LocutusOfBorg> anyhow, gdal is now good, lets see if it migrates in the next run or two
<sladen> seb128: think I've found the "sources" for that .ttf  (not that we can rebuild it)
<seb128> ah, where is it?
<sladen> seb128: ~/.../fonts-for-mpt/2015-10-30_Ubuntu_0.84_documentation_tests_r02/Engineering\ Sources/Ubuntu-Th_source_vtt.ttf  ;-)
<seb128> haha
<ginggs> doko: cuda 9.2 in debian supports up to gcc 7 / clang 5, 10.0 in ubuntu gcc 7 / clang 6, and 10.1 (newly released) gcc 8 / clang 7
<ahasenack> doko: do python3 extensions/bindings (aka, they ship .so files) usually have corresponding debian/python3-*.symbols files?
<sforshee> LocutusOfBorg: wanted to make sure you saw my comments on bug 1813071, as virtualbox is the last test failure blocking the disco-proposed kernel
<ubottu> bug 1813071 in virtualbox (Ubuntu) "virtualbox 5.2.24-dfsg-4build1 ADT test failure with linux 5.0.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1813071
<doko> ahasenack: no, that's some samba speciality. I'd say you don't need these just for the support library, not the extension
<ahasenack> doko: both the library and the extension had symbols files for python2, I kept doing it for py3
<ahasenack> doko: sorry, too many double negatives in your sentence to parse :)
<LocutusOfBorg> nice sforshee  thanks!
<LocutusOfBorg> just to know, did you test both host-guest with that change?
<LocutusOfBorg> I'm fine to upload it of course if you tested it
<sforshee> no I have not tested, however the change should make no functional difference
<xnox> hmmm cannot dput into launchpad
<xnox> ftplib just stuck in sendall.....
<xnox> is it me, or everyone?
<ahasenack> ppa uploads are working for me, if that counts
<xnox> that is handled very different to the archive uploads
<xnox> however that too hangs for me
<xnox> i wonder if my openvpn is dead
<xnox> yeah, dead vpn
<xnox> everything works now.
<teward> um... stupid question, but why is openjdk-11-* in Bionic actually openjdk 10?
<Odd_Bloke> tdaitx: ^
<teward> I see 11 is actually in proposed, but curious to why the misnaming in Bionic
<jbicha> teward: see bug 1814133
<ubottu> bug 1814133 in zeroc-ice (Ubuntu) "update to openjdk 11 in 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1814133
<jbicha> and https://lists.ubuntu.com/archives/ubuntu-release/2018-March/004359.html and https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#OpenJDK
<teward> jbicha: neither answers why the package names are openjdk-11* in Bionic, which is the last remaining question, I'd have expectedd that to be named openjdk-10-* instead of 11
<teward> but that does give insights to some of the headaches
<jbicha> we don't want anyone using openjdk-11 in Ubuntu 18.04 once the transition completes
<jbicha> that means that you'd have to make the openjdk-11 packages empty transitional packages
<jbicha> there are potential upgrade challenges with renaming packages in SRUs
<doko> teward: they *are* named 11 in bionic
<teward> doko: i think you've misinterpreted my question
<teward> doko: my question is why arent they named *10* because that's the version they *are*
<teward> but jbicha's answer is valid
<jbicha> *10 in my answer :)
<lag> cyphermox: waveform: Are you guys up yet
<lag> ?
<teward> jbicha: got that from the statement, though.
<teward> somehow.
<teward> (ERR: Not Enough Coffee for me)
<tdaitx> teward: what jbicha said is correct, it was done to prevent having openjdk-10 package in bionic main after openjdk-11 transition was completed
<tdaitx> https://lists.ubuntu.com/archives/ubuntu-release/2018-March/004364.html
<teward> makes sense.
<cyphermox> lag: isn't there already flash-kernel and such that deals with the dtb?
<waveform> lag, I'm around
<lag> cyphermox: waveform: o/
<lag> cyphermox: How does it know which DTB to load?
<lag> cyphermox: So if I were to take the Ubuntu Installer, plug it into my machine, what are the steps to pick the correct DTB?
<cyphermox> what Ubuntu Installer?
<cyphermox> I don't know what curtin does for arm64 installs, I would expect that if you can pick the right kernel the kernel package would ship what you need
<lag> cyphermox: And flash-kernel is used inside the Ubuntu Installer?
<lag> cyphermox: The AArch64 one
<lag> cyphermox: I guess it's this one: http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-arm64.iso
<teward> tdaitx: at least it's in bionic-proposed and I have that enabled (with priority 100, so it doesn't install from proposed unless I tell it to), so for *my* needs I can get actual JRE/JDK 11 installed to run some things that need newer JDK (nothing I have installed or used here has any RDeps currently on the openjdk 11 packages that're actually JDK10 that would break, so at least I have that as an advantage)
<lag> cyphermox: I don't see any DTBs currently installed in that version of the installer
<cyphermox> lag: AFAIK, yes; but exactly how it works I don't know
<tdaitx> teward: nice! please let us know if you see runtime failures, bug reports are very welcome =)
<cyphermox> lag: the DTBs come from some kernel or firmware package.
<cyphermox> dannf: do you know more about this than I do? ^
<lag> cyphermox: So the installed kernel inside the Ubuntu Installer needs to be able to boot the platform
<lag> cyphermox: That cannot happen without pre-installed DTBs
<lag> cyphermox: This is kinda what I'm proposing
<dannf> cyphermox: DTBs are provided in the kernel build. to make a generic installer work w/ unflashed dtbs, we'd need to have a way to select (or detect) the platform at grub-time
<lag> dannf: Right
<dannf> grub can load dtbs w/ the "FDT" option, similar to initrd
<cyphermox> indeed.
<lag> dannf: You mean "devicetree" option?
<dannf> lag: yeah, that
<lag> dannf: Right, but these need to be installed *inside* the Ubuntu Installer ISO
 * dannf hasn't worked w/ unflashed FDT systems in years, going from memory
<lag> dannf: One suggestion would be to have a writeable area inside the ISO
<lag> dannf: So once flashed to the {USB,SD} a user could place a DTB inside said partition which Grub could load from
<cyphermox> I don't think that's very useful
<lag> cyphermox: Happy to hear alternative solutions :)
<dannf> lag: oh, are you trying to solve non-upstream dtbs?
<cyphermox> I think the best would probably to make use of ubuntu-image to generate the right type of image for you
<lag> dannf: Not necessarily
<lag> dannf: If we could load all upstream DTBs into the Installer image, that too is workable
<cyphermox> lag: I think you should open a bug and clearly describe exactly the problem you want to solve so everyone can be on the same page and look at the same information
<lag> cyphermox: I guess I can do that - if you'd prefer to discuss this on LP rather than here
<cyphermox> it's that here it's confusing, especially if we need to have input from other people
<cyphermox> whereas on a bug, we have a written track of what the problem is, etc.
<cyphermox> from there it's easier to assign work to people as appropriate.
<dannf> lag: i think we have udebs already w/ the upstream dtbs - we needed that for our early x-gene support
<dannf> lag: but +1 what cyphermox says - one issue is that we're moving to subiquity, and all my experience is with d-i. hopefully whatever the answer is would have the same user experience though
<lag> dannf: That's fine - I'll write something up on Monday
<vorlon> Trevinho: why does this unity SRU involve a rename (and possible code changes) of tools/migration-scripts/07_unity_migrate_gnome_favorites_v2 to tools/migration-scripts/07_unity_migrate_gnome_favorites_v3 ?
<Trevinho> vorlon: mhmh, for what distro?
<vorlon> Trevinho: cosmic
<Trevinho> vorlon: mh I don't see the diff in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3655/2019-03-04_11:03:56/cosmic_unity_content.diff
<vorlon> Trevinho: that's because I diffed against bionic instead of cosmic, heh
<Trevinho> :)
<vorlon> see, bileto + syncs are bad for the SRU process
<Trevinho> vorlon: you can use the bileto generated ones, should be the quickest and safest way
<vorlon> Trevinho: not integrated in the workflow
<Trevinho> vorlon: it's 2 click aways...
<Trevinho> I know :)
<Trevinho> but well, not sooo complicated.
<vorlon> Trevinho: it's 2 clicks away from a page that is also not integrated in the workflow :P
<vorlon> SRU processing is commandline-driven
<Trevinho> I can imagine... Well, I didn't design this :)
<vorlon> you don't have to use bileto
<Trevinho> that's why sometimes we just do a copy from ppa to proposed, but since I've not such powers, I tend to do this not to bother others.
<Trevinho> although I'm not the only, one using it for SRUs, so since isn't really dead yet, maybe would be nice to integrate it a bit into the tools, I've not clude how hard it could be, but since diffs are there, probably it could be done quite easilty.
<Trevinho> as I understand both you guys and who is using it, being quite conveinent when there are merge proposals that you can land in few clicks instead of having through the manual packaging part
<vorlon> Trevinho: lp:ubuntu-archive-tools and patches welcome; otherwise bileto's behavior continues to be a wart that the SRU team will discourage
<Trevinho> I was already on that xD
<bdmurray> does anybody have access to bug 871007?
<ubottu> Error: Launchpad bug 871007 could not be found
<bdmurray> sarnold: maybe you?
<bdmurray> oh, right its Friday
<Odd_Bloke> bdmurray: Can't print on Tuesdays, can't see bug 871007 on Fridays?
<ubottu> Error: Launchpad bug 871007 could not be found
<bdmurray> Odd_Bloke: I was remembering that Seth is out today.
<bdmurray> xnox: vorlon said you might have some insight into ubuntu-release-upgrader-gtk no depending on python3 as it should https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/debian/control . python3-distupgrade has the right thing.
<vorlon> bdmurray: I think this is the recent package where I was dealing with this https://lists.ubuntu.com/archives/disco-changes/2019-February/007613.html
<Trevinho> vorlon: https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
<bdmurray> Trevinho: That merge gets the diff from bileto?
<Trevinho> bdmurray: yep
<Trevinho> try with ./sru-review indicator-application
<bdmurray> I think infinity had some concerns with the trustworthiness of bileto for the diff.
<Trevinho> well... you know, if you really don't trust it... can still check manually.
<Trevinho> but at least it gives you something
<Trevinho> if you really want we can still download the srcs again locally and do the debdiffing, but ...
<Trevinho> bdmurray: what was the concern for?
<Trevinho> in any case we couldn't use the one from the ppa, since there might multiple revisions in there...
<bdmurray> Trevinho: I'm not certian maybe because he hasn't audited bileto's code?
<Trevinho> could be... well, again the only other option is to download the sources and do the debdiff locally to show, whatever is fine, but since SRUs are still coming on that, spending another hour on it isn't too bad
#ubuntu-devel 2019-03-09
<sforshee> LocutusOfBorg: updated bug 1813071 with information about testing and a patch to fix the vboxvideo build with 5.0
<ubottu> bug 1813071 in virtualbox (Ubuntu) "virtualbox 5.2.24-dfsg-4build1 ADT test failure with linux 5.0.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1813071
<ahasenack> I guess kde just hit britney/autopkgtests
 * ahasenack watches in dismay at all the k*
<valorie> why dismay?
 * valorie is always happy to see packages get through....
<tsimonq2> valorie: KDE autopkgtests take quite a bit of time.
<valorie> sure, but we've got the weekend, right?
<Unit193> k* tends to clog the pipes, someone has to call the plumber, then things get moving again.
 * valorie puts the Plumber's Friend at the ready
<tsimonq2> The plumber doesn't have to be called that much with those nowadays.
<valorie> the snake over there in the corner for backup
<tsimonq2> If it weren't for a specific team member we'd have this solved already. Oh well.
<tsimonq2> Iain's concerns are very much valid.
<tsimonq2> I have to play with that stuff for the CI tooling I'm writing anyway: https://ci.lubuntu.me/
<tsimonq2> I'll see how easy it would be to fix this.
#ubuntu-devel 2019-03-10
<acheronuk> tsimonq2 Unit193: yeah, previously FW tests might have taken some days to clear, but now they are not far off being done now
<acheronuk> much of the more expensive tests (PIM etc) have been dropped by debian kde, allowing us to do the same
<acheronuk> debian gate unstable -> testing migration more strongly now on tests passing on ci.debian.net, so I suspect more will be dropped allowing us to do the same
<acheronuk> oh, and last nights upload will be the last of those for disco. any more kde updates left to do will be quite lightweight test wise
#ubuntu-devel 2020-03-02
<stefandxm> hola
<stefandxm> trying to find some flows of the usb iniating stuff
<stefandxm> seems i have a race condition for my device
<stefandxm> sometimes it docks like a ttyusb** and sometimes it docks the driver to become an ethernet device
<stefandxm> any pointers?
<stefandxm> i think its related to the host. but i cannot debug it / disable the false action
<stefandxm> host as in the usb part
<stefandxm> is there any diagram of the usb support systems in ubuntu?
<stefandxm> is channel alive?
<nickgaw> That is what I was wondering to about my ubuntu installer questions.
<nickgaw> no one is here or just sitting
<stefandxm> i dunno
<stefandxm> i was redirected here
<stefandxm> is there any arch documenations of ubuntu?
<nickgaw> Do you know how to checkout with bzr the ubuntu installer?
<stefandxm> nope
<stefandxm> iam trying to figure out how the usb drivers flow looks like
<stefandxm> i can hack a debugger
<nickgaw> Are there development versions of ubuntu?
<stefandxm> i dont know
<stefandxm> iam merely a user
<stefandxm> trying to understand how stuff work
<nickgaw> ok me to.
<stefandxm> i dont think they care tbh
<stefandxm> not about irc that is
<nickgaw> I think this is just a user channel not an officially supported channel.
<stefandxm> agreed
<nickgaw> It could be the fact it is the weekend now and you might have better luck on a week day.
<stefandxm> could be
<stefandxm>  <oerheks> stefandxm, best chance in #ubuntu-devel is during officehours, uk, but most devs are on the mailinglist, not irc
<stefandxm> so that might be it
<nickgaw> That is understandable.
<stefandxm> agreed
<ahasenack> rbasak: hi, I need some help with your chdist-if script again
<ahasenack> rbasak: https://pastebin.ubuntu.com/p/rvx6NRMSN3/ is the autohinter section
<ahasenack> rbasak: I also have this bit from you, last time you helped: https://pastebin.ubuntu.com/p/yj4nxccWSq/
<rbasak> ahasenack: I don't see the issue immediately
<rbasak> :-/
<ahasenack> same, all combinations I try just work
<rbasak> Also looks like my method doesn't handle Conflicts well
<rbasak> W: Unable to locate package bind9-libs
<rbasak> ^ looks like that's new in focal-proposed
<rbasak> I wonder if that's related or a red herring.
<ahasenack> bind9-libs is new in proposed only, yes
<ahasenack> so there is src:bind9-libs in f-p, and bin:bind9-libs in f-p
<ahasenack> not from the same source
<rbasak> I don't follow the rearrangement
<rbasak> Why doesn't the new bind9 in proposed depend on bind-libs or its  dependants?
<rbasak> Uh
<ahasenack> rbasak: src:bind9-libs is for 9.11.x, whereas src:bind9 (9.16.x) produces a binary package called bind9-libs that pulls together all the individual library packages that 9.11 used to produce
<rbasak> Why doesn't the new bind9 in proposed *build-depend* on bind-libs or its dependants?
<ahasenack> isc-dhcp doesn't build with bind9-9.16.x, it needs 9.11.x
<ahasenack> so we have two binds in main
<ahasenack> one to provide only libraries for legacy apps, and the other package the server at its newest lts version
<ahasenack> last I heard from vor-lon this was entangled in a debian-installer installability problem due to a new kernel, but that was last week, and seems to have resolved
<rbasak> Ah
<rbasak> I hadn't been keeping up-to-date with all the details of this
<rbasak> Should I catch up by asking a million questions, or leave it to you and vor-lon and others who have looked at it alreay?
<ahasenack> this was discussed with foundations and security, I wouldn't do something crazy like this without peer checking :)
<ahasenack> and in standups as well ;)
<rbasak> I had understood something complicated was going on
<ahasenack> I'll keep looking, I was more wondering if I used your script correctly
<rbasak> I missed that the resolution was two source packages. I'm not complaining!
<rbasak> I think you are, but there might well be limitations in my script here
<ahasenack> and my knowledge of udebs
<ahasenack> where is this package stored, for example: libisccc-export161-udeb
<rbasak> I don't understand why britney says that autodns-dhcp would become uninstallable (starting at the beginning)
<Laney> rbasak: ahasenack: Are you talking about the autohint "bind-dyndb-ldap/11.2-1build2 bind9-libs/1:9.11.16+dfsg-3~build1 isc-dhcp/4.4.1-2.1ubuntu2
<Laney> "
<Laney> ?
<ahasenack> yes
<Laney> then it seems to come down to https://paste.ubuntu.com/p/9xXK6ySCxS/
<Laney> afaics
<Laney> bind9's not in that hint
<ahasenack> so bind9-host comes from src:bind9. There is src:bind9 9.11.x in release, and src:bind9 9.16.x in proposed
<ahasenack> why isn't bind9-host 9.11.14 not upgrading to bind9-host 9.16?
<Laney> I don't know why the auto-hinter didn't put it in there
<Laney> I can ask the hint-tester and see what would happen
<rbasak> I don't know why my script can resolve that
<rbasak> But I agree src:bind9 isn't in that hint
<ahasenack> libbind9-161 didn't change sonames between 9.11.14 and 9.11.16
<ahasenack> Laney: how does that work, ask the hint-tester?
<Laney> I can run it with the --hint-tester flag on the archive machine
<ahasenack> what does it do?
<Laney> https://paste.ubuntu.com/p/jGwnq6JRMF/
<Laney> that
<ahasenack> so, debian-installer-udebs
<ahasenack> d-i was rebuilt a few times since bind9 was uploaded
<ahasenack> I see its depends line
 * ahasenack checks
<mwhudson> the thing with vim in focal where middle click pastes the vim buffer not the x one is driving me bananas
<ahasenack> mwhudson: +1
<mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1864424
<ubottu> Launchpad bug 1864424 in vim (Ubuntu) "new vim version in 20.04 sets mouse=a by default" [High,Fix committed]
<ahasenack> in d-i-udebs, I see the diff in the libdns-export and libisc-export sonames, that looks correct
<ahasenack> and I see errors installing kernel -di packages
<ahasenack> so maybe it's still the issue vor-lon said
<ahasenack> well https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#debian-installer
<xnox> ahasenack:  but has the d-i been rebuild against the right kernel, and is that kernel out? =) as far as i can tell -16 kernel no longer exists, it's iether 14 (release pocket) or 17 (proposed pocket)
<ahasenack> xnox: I don't have more details
<xnox> ahasenack:  i think we should rebuild d-i against 17 kernel, and wait for kernel to be released.
<ahasenack> "debian-installer is all that's left, and it needs linux-meta to drop the snapdragon metapackages for a kernel flavor we're no longer building"
<ahasenack> that's what vor-lon said last week, does that ring any bells?
<xnox> whilst true, the statement is incomplete =)
<xnox> well
<xnox> rather things have changed since that was said
<ahasenack> indeed vlan-modules-5.4.0-17-generic-di exists
<ahasenack> but not vlan-modules-5.4.0-17-generic-di
<ahasenack> er
<ahasenack> but not vlan-modules-5.4.0-16-generic-di
<xnox> yes, uploading d-i rebuild against -17
<ahasenack> thank you!
<xnox> however
<xnox> i think the snapdragon bug is still there
<xnox> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/18772755
<xnox> shows that meta for 17 still generates snapdragon packages, let's hope they are still installable....
<xnox> anyway
<ahasenack> the rebuild for -17 was necessary anyway, right
<xnox> ahasenack:  let's wait for this https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu603 to finish building and getting pickup by excuses.
<xnox> then we will see what else is left
<ahasenack> ok
<rbasak> OK so chdist-if-migrated has a bug I think
<Laney> I was using a script I wrote a few years ago: https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper
<rbasak> "chdist apt-cache focal-proposed showsrc bind9-libs" outputs "Package: bind9" as well as "Package: bind9-libs"
<rbasak> I wasn't expecting that
<rbasak> Ah
<rbasak> I need --only-source apparently
<ahasenack> Laney: the mp is pending since 2015? :)
<rbasak> That fixed it
<ahasenack> rbasak: diff please ? :)
<Laney> yeah...
<Laney> I gave up on getting it merged and just use it locally :P
<ahasenack> Laney: is that branch up-to-date?
<ahasenack> https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper specifically
<ahasenack> or, if it's standalone, could you just paste it?
<rbasak> ahasenack: http://paste.ubuntu.com/p/XHngKFM5K4/
<ahasenack> thx
<Laney> it's not going to be up to date with respect to lp:ubuntu-archive-tools itself but you can grab the script out of it if you want to use it
<doko> kanashiro: did you prepare a ruby-defaults transition tracker?
<Laney> sounds like chdist-if-migrated is doing the same thing though?
<ahasenack> the later has some complicated preparation steps, that's why I wanted to look at yours too
<ahasenack> latter
<Laney> okey
<Laney> well of course feel free to use, improve or steal ideas
<ahasenack> :)
<juliank> kanashiro: doko actually made a ruby2.7-only tracker now fwiw
<bdmurray> mdeslaur: Do you care for usb-creator? I was wondering if it should still be in main.
<mdeslaur> bdmurray: what do you want to replace it with?
<mdeslaur> I don't particularly care about it
<rbasak> Time to stick this into git
<rbasak> ahasenack: I added chdist-if-migrated to https://git.launchpad.net/~racb/+git/tools/ and added a note on how to use it to detect d-i related migration issues also
<rbasak> Now it displays exactly what udebs need addressing: http://paste.ubuntu.com/p/SpxDtGKybr/
<bdmurray> mdeslaur: dd
<ahasenack> nice!
<mdeslaur> bdmurray: lol
<kanashiro> juliank, doko is this ruby2.7-only transition page live? I am not finding it
<juliank> kanashiro: i think ben does not pull new configs very often or something
<Laney> it does each time it runs
<juliank> Laney: then it does not run very often :)
<juliank> Laney: end result is the same :D
<Laney> Looks to me like it's running right now
<juliank> ack
<eoli3n> Hi
<eoli3n> i have a strange problem which is hard to explain well
<eoli3n> we use ldap auth, and usernames are mail adresses
<eoli3n> so we have some mail adresses > 32 chars
<eoli3n> its not a problem it works, but in some cases, when i try to log in tty, it just don't asks for password
<juliank> why dont you file a bug report?
<eoli3n> where ?
<juliank> I guess starting with whatever pam  plugin for ldap you use
<eoli3n> just to finish : problem is easy to reproduice
<juliank> it's ubuntu package in launchpad
<eoli3n> juliank: it isn't ldap related
<juliank> then against the pam pacakge?
<eoli3n> i precise that just to explain how i can have some > 32 usernames
<eoli3n> so its maybe pam...
<juliank> I mean, you wrote that all days ago already
<eoli3n> yep
<juliank> and this sounds like a clear bug
<eoli3n> but i didn't know what component is involved
<juliank> pam is the reasonable starting point for that
<juliank> or login
<eoli3n> ok, thx juliank
<juliank> (login being in shadow)
<eoli3n> ok didn't see but i get "checkname failed: Operation not permitted" when i reproduice the bug in /var/log/auth.log
<ahasenack> xnox: the "linux" packae has a block proposed tag: https://launchpad.net/bugs/1865025
<ubottu> Launchpad bug 1865025 in Kernel SRU Workflow regression-testing "focal/linux: 5.4.0-17.21 -proposed tracker" [Medium,In progress]
<ahasenack> I wonder if that will be worked on this week
<xnox> ahasenack:  that's normal process for linux packages.
<xnox> ahasenack:  it will be removed, when linux is ready to migrate.
 * ahasenack sits tight
<xnox> for details you can go to the adt matrix
<xnox> https://people.canonical.com/~kernel/status/adt-matrix/
<xnox> from there you can click on the focal-meta one
<xnox> https://people.canonical.com/~kernel/status/adt-matrix/focal-linux-meta.html
<xnox> from there you can see that there a few "MISS" => missing tests (because deps changed)
<xnox> or regressions, i.e. on the linux package itself
<xnox> ahasenack:  but kernel team handles that
<ahasenack> thanks
<xnox> it is unfortunate like that that most udebs get entangled together.
<ali1234> hello. i performed a kernel bisection at the request of an ubuntu developer andnow i have about 30 broken unofficial kernel packages installed
<ali1234> how do i remove them and go back to the official kernel?
<ali1234> do i have to dpkg remove each one individually?
<ali1234> if so how do i tell which ones are not from the repos?
<nickgaw> Hi, If I already have bzr installed and the git clone of the debian-installer how without making a branch on launchpad would I check out the ubuntu installer what would I type?
<bryce> hey, for retriggering autopkgtests, I have a question on how to automate the sso/2fa process.
<bryce> I know the trick to edit the URL, e.g. https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=armhf&package=asciidoctor&trigger=ruby-defaults%2F1%3A2.7%7E0
<bryce> and then load that in firefox
<bryce> however if we need to requeue, say, all the arch's, then that's N urls to load up.
<bryce> I'd like to load the URL in curl or wget or some such, however this requires SSO
<bryce> I've been tinkering with retrieving the cookies doing the series of request/response stuff, but haven't gotten it to work end to end yet
<bryce> I'm wondering if this is already a figured out process, and/or if anyone knows an existing example of CLI operation against login.ubuntu.com with SSO and 2fa?
<bryce> I've been experimenting with usso-login, which seems like it should do it, but no luck.  The docs for it are kind of sketchy, so if anyone's use that I'd be interested in tips/examples.
<sarnold> bryce: does this help? https://git.launchpad.net/ubuntu-security-tools/tree/README#n197
<sarnold> bryce: it reads the cookie out of firefox, so you've got to be authenticated through that
<bryce> sarnold, let me give it a shot
<bryce> sarnold, hmm, seems the moz sqlite database tables have changed since this was written
<sarnold> bryce: hmm. I wonder which of our tools use this thing, and if they still work :)
<bryce> heh
<bryce> I found that usso-login is able to perform the 2fa transaction ok, but it stores the data as json rather than as cookie data.
#ubuntu-devel 2020-03-03
<bryce> sarnold, thanks for the suggestion to extract the cookies from firefox, while I couldn't do it via the sqlite database programmatically, it made me look from the FF gui itself, and I was able to manually copy each of them to a file, and pass that to wget.  There were a couple other openid-related tweaks specific to autopkgtest I figured out digging through autopkgtest's flask code, but I finally got it all working.
<sarnold> bryce: dang, I wonder why it didn't work for you -- or why it works for us, I think it does anyway :)
<sarnold> bryce: but now you've got a way to restart N autopkgtests at a go?
<bryce> sarnold, I do
<sarnold> yay :)
<bryce> sarnold, do you guys run the scripts on a ubuntu version earlier than focal?  could be as simple as that
<sarnold> bryce: I'm on focal for a few weeks now, and I'm pretty sure I used the responses/security/ scripts recently, which I think use that cookie
<bryce> sarnold, can you run `python2 ./cookies-sql2txt.py ~/.mozilla/firefox/m2yx7v41.default/cookies.sqlite autopkgtest.ubuntu.com` ?
<bryce> I get an error like "pysqlite2.dbapi2.OperationalError: near ".": syntax error"
<sarnold> ImportError: No module named pysqlite2
<sarnold> heh, I don't even get that far.
<bryce> sudo apt-get install python-sqlite
<bryce> anyway, it's an interesting angle on the problem, I may dig more into it later.  thanks again
<sarnold> heh, required python-pysqlite2.
<sarnold> pysqlite2.dbapi2.OperationalError: near ".": syntax error
<bryce> ok, yep
<bryce> I put the database table name in quotes but then it didn't recognize it as a valid table name.
<bryce> wow, and autopkgtest.ubuntu.com has now finished processing all of that.  Looks like chake and ruby-session are still on the board
<mwhudson> bryce: do you know about retry-autopkgtest-regressions from ubuntu-archive-tools?
<mwhudson> looks like it requires you did the cookie out of your browser too though
<bryce> mwhudson, yep that was one of the first things I looked at actually
<mwhudson> bryce: ok good :)
<techalchemy> sarnold, fyi whatever the rason is we're using pysqlite we should probably use the native bindings instead
<cjwatson> Yeah, there's the perfectly good sqlite3 in the standard library
<cjwatson> Since Python 2.5
<cjwatson> Most things that use pysqlite2 were originally written for Python <= 2.4
<mwhudson> i don't seem to be getting a plymouthy boot in focal currently
<mwhudson> is that a known thing?
<seb128> vorlon, a few people pinged me because of bug #1864586, any idea when you will get a fix out?
<ubottu> bug 1864586 in plymouth (Ubuntu Focal) "plymouth does not ask for LUKS password and does not change tty properly" [High,Confirmed] https://launchpad.net/bugs/1864586
<seb128> vorlon, plymouth includes a plymouth-populate-initrd script that can be used and would copy the right content
<mwhudson> oh i'm seeing that
<Laney> me too :'(
<juliank> seb128: the fix is easy, it's just adding a word to the for loop that copies the theme in the initramfs hook
<juliank> -currthemes="${THEME_NAME} ${TEXTTHEME_NAME}"
<juliank> +currthemes="${THEME_NAME} ${TEXTTHEME_NAME} spinner"
<seb128> juliank, I know, it's just that Steve said he would have a fix uploaded on friday and I don't want to dup work
<seb128> but thanks
<dannf> cjwatson: been a while since i tried to do git-dpm/grub work - is there something i need to do to the master to unapply patches? https://paste.ubuntu.com/p/kz4n5t4SXj/
<cjwatson> dannf: don't use quilt!
<cjwatson> dannf: git-dpm gives you patch-applied already.  If you want to edit the patch stack, use git-dpm checkout-patched and commit stuff directly, then git-dpm update-patches to serialise the commits back into debian/patches/
<dannf> cjwatson: yeah, that's what i'm doing - but i'd assumed after update-patches i'd have a quilt-compatible tree.
<dannf> if that's not the case, that's ok :) just trying to make sure i'm doing it correctly
<dannf> bbiab
<cjwatson> dannf: It would be quilt-compatible if you did something like https://people.canonical.com/~cjwatson/dpkg-quilt-setup to set up quilt metadata.  But it's not designed to be managed with quilt, and trying to do so will probably just cause confusion
<cjwatson> dannf: It's just using quilt as an export format
<ahasenack> does ubuntu or debian have this packaged? I couldn't find it: https://git.kernel.dk/cgit/liburing/
<ahasenack> https://lwn.net/Articles/776703/
<dannf> cjwatson: ack, thx
<cpaelzer> rbasak: with the Origin added I guess you can re-reply to the mail
<cpaelzer> rbasak: and then either upload youself now (allowing for bryce to pick up the results)
<cpaelzer> or wait for him to ack and sponsor it
<cpaelzer> kanashiro: the ctioga2 worked now, triggered on all architectures
<seb128> vorlon, I'm having a look to the plymouth/initramfs issue now
<cpaelzer> rbasak: I'm taking a look at the class III bugs
<cpaelzer> rbasak: in case this is another phpunit patch we could do it in one upload
<cpaelzer> Those are the likes of " Declaration of HTTP_Request2_Adapter_CommonNetworkTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /tmp/autopkgtest.Ih0Z0B/build.kMc/src/HTTP_Request2-2.3.0/tests/Request2/Adapter/CommonNetworkTest.php"
<rbasak> Ah yes, I was about to ask if we wanted to bundle any more phpunit fixes before uploading
<kanashiro> cpaelzer, good news, I should come up with another set of packages with similar issue
<cpaelzer> kanashiro: so they all need triggers combined with ruby-defaults and their own version in -proposed then?
<cpaelzer> rbasak: I have patches that will need your phpunit change
<cpaelzer> rbasak: I'll upload all together to a PPA hoping they will test there together nciely
<kanashiro> cpaelzer, I didn't check all the regressions but some of them yes
<cpaelzer> kanashiro: ok once you have a list to restart that way let me know
<rbasak> cpaelzer: sure. Feel free to upload, etc.
<cpaelzer> rbasak: I replied to the thread with two debdiffs
<cpaelzer> will later reply if the testing shows anything useful
<kanashiro> rbasak, don't you want to comment on this MP https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/ruby-dataobjects-mysql/+git/ruby-dataobjects-mysql/+merge/380125 ? I just kept the changes you added in the past to support mysql 8
<rbasak> kanashiro: sorry, I don't read all the MP traffic. I'll comment now.
<kanashiro> np
<roaksoax> win 1
<ahasenack> hi, can one of these two dep8 requests be killed?
<ahasenack> cacti {"requester": "ahasenack", "submit-time": "2020-03-03 17:05:55", "triggers": ["cacti/1.2.9+ds1-1ubuntu2"]}
<ahasenack> cacti {"requester": "ginggs", "submit-time": "2020-03-03 17:54:32", "triggers": ["cacti/1.2.9+ds1-1ubuntu2"]}
<kanashiro> rbasak, could you sponsor ruby-dataobjects-mysql if you are happy with the changes I proposed on that MP?
<rbasak> kanashiro: sure. I'm heading out now though, so it might be later today or tomorrow. Is that OK?
<rbasak> (if not grab someone else maybe?)
<kanashiro> rbasak, totally fine
<rbasak> Though also, is rafaeldtinoco happy with my comment?
<rbasak> I don't want to step on his question without checking he's happy with my response.
<rafaeldtinoco> rbasak: sorry I should have +1ed your comment
<rafaeldtinoco> I read it, agreed and moved on to something else
<rafaeldtinoco> lol
<rafaeldtinoco> kanashiro: ^
<rbasak> OK, I'll sponsor when I get back.
<rbasak> Thanks!
<rafaeldtinoco> tku!
<kanashiro> great :)
<doko> kanashiro: are you working on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-defaults ?
<kanashiro> doko, yes, I should request some re-runs latter today to fix some regressions and start to investigate some actual failures (now I am trying to rebuild some packages against ruby2.7 that are still missing)
<kanashiro> however, help is welcome :)
<kanashiro> doko, any idea about this python related src:subversion failure? https://launchpadlibrarian.net/467386393/buildlog_ubuntu-focal-amd64.subversion_1.13.0-2build1_BUILDING.txt.gz
<kanashiro> I added a patch to drop the '-classic' option (not supported according to the logs) but then I got another error
<kanashiro> subversion/bindings/swig/python/svn_client.c:7517:106: error: âsvn_argnum_swig_objâ undeclared (first use in this function); did you mean âsvn_argnum_obj1â?
<doko> kanashiro: not python related, but more likely swig 4.0. just drop that?
<kanashiro> doko, yep, someone filed a bug upstream about it while ago and not fixed yet apparently: https://issues.apache.org/jira/browse/SVN-4818?jql=project%20%3D%20SVN%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22swig%22%20ORDER%20BY%20priority%20DESC
<kanashiro> this link is better: https://issues.apache.org/jira/browse/SVN-4818
<doko> great, no upstream support
<doko> so maybe package a legacy swig-3.0 and use it?
<doko> or drop the bindings
<kanashiro> doko, I'd go for dropping the python binding
<kanashiro> it is not functional anyway
<doko> take care about the rdeps
<kanashiro> ack
 * rafaeldtinoco takes a break to get back to pacemaker
<vorlon> seb128: yeah sorry, I'm off today so if you were to get the plymouth fix out that would be rgeat
<vorlon> seb128: "great"
#ubuntu-devel 2020-03-04
<cpaelzer> rbasak: please ping me once you are around to coordinate the php* uploads we had prepped yesterday
<cpaelzer> I've synced with bryce on what we could help with today - and uploading these is one of them
<Skuggen> I have a question about livecds: We got a bug report https://bugs.mysql.com/bug.php?id=98819 (technically about Ubuntu's MySQL packages, not upstream's) where it gives a permission error on /etc/mysql/conf.d. Would that be expected to work?
<mwhudson> good morning
<rbasak> Skuggen: I'm not sure. I don't see why it wouldn't work, but I don't see that as an important use case. IMHO the bug should be in Launchpad against Ubuntu (or maybe Lubuntu) and is not valid upstream, and I'd give it Importance: Low.
<rbasak> cpaelzer: I'm online briefly, but depending on the weather I may be out this morning and working in the evening instead
<cpaelzer> rbasak: well of the uploads bryce wanted us to do yours is the first one (phpunit)
<cpaelzer> rbasak: if you are ok doing that with your fix let me know once it is in -proposed peroperly
<rbasak> cpaelzer: on its own, without any further fixes?
<cpaelzer> I have two other packages fixed (see the debdiffs in the mail thread) that need your fix to be present first
<cpaelzer> then after all three are built and in proposed it will be a massive "trigger-tests-together" party
<cpaelzer> and then once the dust settles we see what is really left afterwards
<rbasak> Oh, OK. So only one fix needed for phpunit?
 * rbasak reads the thread
<cpaelzer> yes, the one you provided the fix
<cpaelzer> while there is a chance (see bryce comment) that this is a red herring we need to get it out of the way to make any sense of the test results
<rbasak> cpaelzer: OK. phpunit upload accepted into focal-proposed. Presumably building now
<cpaelzer> ok, I'll check later and upload mine
<cpaelzer> thanks
<scx> Hello
<scx> Is there any equivalent for "snapcraft cleanbuild" in core18?
<ogra> sil2100, https://bugs.launchpad.net/ubuntu/+source/ubuntu-image/+bug/1866002
<ubottu> Launchpad bug 1866002 in ubuntu-image (Ubuntu) "ubuntu-image should allow to disable console-conf at build time" [Undecided,New]
<ogra> for you :)
<ogra> scx, --use-lxd i think ...
<sil2100> ogra: thanks! On it in a minute
<ogra> no hurry :(
<ogra> err
<ogra> :)
<sil2100> (since we're having a meeting, so I have cycles for some quick background work)
<ogra> haha, thats what meetings are for indeed :)
<scx> ogra: thanks!
<kanashiro> xnox, I need autodep8 0.22 to avoid some regressions of some ruby packages, is that doable? should I merge version 0.22 from Debian or do you want to do it?
<xnox> kanashiro:  i'll merge it.
<kanashiro> xnox, thanks
<xnox> kanashiro:  are there any other things needed too?
<xnox> kanashiro:  ie newer gem2deb something rather too?
<kanashiro> xnox, no, we already have the latest gem2deb in proposed
<kanashiro> I just need to make things migrate
<xnox> Cool
<cpaelzer> rbasak: rafaeldtinoco: it seems the debdiff on https://lists.ubuntu.com/archives/ubuntu-server/2020-February/008160.html got lost
<cpaelzer> but part of the "help bryce for php" has just this issue
<cpaelzer> rbasak: rafaeldtinoco: could one of you give the debdiff a review so I can upload that?
<cpaelzer> You probably have the mail in your inbox as well as it was on ubuntu-server ML
<rafaeldtinoco> https://www.irccloud.com/pastebin/4JNTkyJl/
<rafaeldtinoco> cpaelzer: this one ?
<cpaelzer> rafaeldtinoco: yes
 * rbasak is too late
<rafaeldtinoco> cpaelzer: should I review and give a +1 ?
<rafaeldtinoco> or you wanted just the diff ?
<cpaelzer> rafaeldtinoco: review and +1 please
<rafaeldtinoco> ++die("skip");
<cpaelzer> it is small, so it should hopefully not be too broken
<rafaeldtinoco> thats harsh
<cpaelzer> that is their common style, other tests have that already
<rafaeldtinoco> cpaelzer: i know just kidding w/ you :P
 * rafaeldtinoco regrets IRC cant transmit sarcasm
<rafaeldtinoco> cpaelzer: looks good to me
<cpaelzer> thanks
<rafaeldtinoco> sure anytime =)
<rafaeldtinoco> that was easy
<kanashiro> xnox, since you asked could you help me with src:subversion? It FTBFS against swig 4 (https://issues.apache.org/jira/browse/SVN-4818) and I need to rebuild it against ruby2.7
<kanashiro> after a discussion here yesterday I was considering to drop the python bindings
<xnox> kanashiro:  i asked?
<kanashiro> xnox, I thought you were offering some help :p
<xnox> huh
<xnox> kanashiro:  your question above, implies as if we spoke about this before. I never talked to you about neither subversion, ruby, or swig, until right now.
<xnox> kanashiro:  are you sure you have the right person?
<kanashiro> xnox, it was not you, it was doko. I mentioned that a discussion happened here, not that you were involved
<xnox> kanashiro: of you mean my question slightly earlier if anything else is needed for autodep8 change, it was about the autodep8 change. As in, it has undeclared dependencies and whatever generates skips also needs to be in the archive as that piece by itself wouldn't work..... It was not an invite for any wish in the world. Just scoped to the autodep8 change.
<kanashiro> anyway, if that's too much for you leave it on my plate
<xnox> kanashiro: :-)
<xnox> kanashiro: I am not offering unconditional help with ruby stuff.
<kanashiro> xnox, ack
<ahasenack> infinity: hi, would you be inclined to take a look at this glibc sru for bionic-only? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864
<ubottu> Launchpad bug 1864864 in glibc (Ubuntu) "[SRU] pthread_rwlock_trywrlock results in hang" [Undecided,New]
<ahasenack> it has a test case, and patch was already applied in later releases and debian
<ahasenack> rbasak: did you see my n/i on the bacula mp?
<rbasak> ahasenack: n/i?
<rbasak> ahasenack: I did see the review, thanks
<ahasenack> rbasak: needs information
<rbasak> I'll file an FFe bug
<rbasak> Ah
<ahasenack> ok :)
<rbasak> (I've grabbed the card back)
<cpaelzer> kanashiro: libprelude LGTM now
<cpaelzer> do you want me to sponsor it right away or only review?
<sforshee> seb128: it looks like the latest plymouth is causing update-initramfs to hang, bug 1866030
<ubottu> bug 1866030 in linux (Ubuntu) "Unable to install focal 5.4.0-17 proposed kernel, hang with update-initramfs" [Undecided,Confirmed] https://launchpad.net/bugs/1866030
<seb128> sforshee, https://launchpad.net/ubuntu/+source/plymouth/0.9.4git20200109-0ubuntu3.3
<sforshee> seb128: great!
<sforshee> thanks
<seb128> sforshee, though it seems it's still buggy according to the recent comments on bug #1865959 but I would welcome debug info/help to fix it since I can't reproduce (why are people installing plymouth without a theme?)
<ubottu> bug 1865959 in The Ubuntu-power-systems project "plymouth hook hangs waiting for input" [Undecided,New] https://launchpad.net/bugs/1865959
<sforshee> seb128: for the case which I reproduced it was a uv-tool vm, and I did not install plymouth manually
<seb128> sforshee, k, I'm at a sprint but I will try to create a vm between other things to test that
<ahasenack> kanashiro: have you seen this error, though? /usr/lib/ruby/vendor_ruby/gem2deb/metadata.rb:168:in ``': No such file or directory - dpkg-parsechangelog (Errno::ENOENT)
<kanashiro> cpaelzer, re libprelude: sponsor it please
<ahasenack> that code checks for a debian/ directory, and if there is one, calls dpkg-parsechangelog, which isn'g installed
<kanashiro> ahasenack, ah yeah, it requires dpkg-dev installed
<ahasenack> should that be a test dependency, or is it just happening for some reason when we run the tests locally?
<kanashiro> for all packages using ruby autodep8 tests
<kanashiro> ahasenack, I've experienced that when I am using lxd as backend (ubuntu-daily:devel image), but I've not seen it happening in the autopkgtest infra
<sforshee> seb128: plymouth 0.9.4git20200109-0ubuntu3.3 fixes the issue in my vm
<seb128> sforshee, thanks
<scx> Let's say that the program wants to read data from /usr/share/<program_name>/file.xml. How to handle this in snap?
<scx> core18/gnome-3-28
<rbasak> scx: probably something like $SNAP/usr/share/<program_name>/file.xml, but see https://snapcraft.io/docs/environment-variables and if you have questions there are probably more who can help in #snapcraft
<scx> rbasak: thanks!
<eoli3n> why some libraries are located in /snap dir on 20.04 ?
<eoli3n> /snap/core18/1668/lib/x86_64-linux-gnu/libncurses.so.5
<eoli3n> what is that snap dir
<scx> eoli3n: The snap directory for classic confinement: https://forum.snapcraft.io/t/process-for-reviewing-classic-confinement-snaps/1460
<ogra> the /snap dir is where the snap packages are mounted
<ricotz> doko, hi :), source-highlight requires another rebuild against the boost-icu-combo
<xnox> eoli3n:  all snaps include all the library dependencies they need or can be provided by another snap, ubuntu ships some snaps by default and when using those applications the only libraries that are used, are those from under /snap.
<xnox> eoli3n:  nothing outside of /snap uses things from under /snap
<xnox> eoli3n:  core18 is a base snap, which provides "base" libraries and binaries which all "base: core18" snaps used.
<xnox> eoli3n:  core18 is a base snap, which provides "base" libraries and binaries which all "base: core18" snaps use.
<ahasenack> Skuggen: hi, still around?
<ahasenack> Skuggen: should clients stop using my_init()? I'm reading this bit from https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-2.html: "The my_init() function is no longer included in the list of symbols exported from libmysqlclient. It need not be called explicitly by client programs because it is called implicitly by other C API initialization functions. "
<ahasenack> Skuggen: context is https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1859773/comments/3
<ubottu> Launchpad bug 1859773 in apache2 (Ubuntu Focal) "Apache DBD Auth not working with mysql Focal 20.04" [High,Triaged]
<ahasenack> Skuggen: I dropped that my_init(), and now loading the module works
<Skuggen> Hi
<Skuggen> Yeah, it shouldn't be needed at all
<ahasenack> Skuggen: thanks!
<juliank> hmm disco is still listed as supported on LP
<ailion> Notice: I got an "internal server errror" from "https://packages.ubuntu.com/disco/calamares-settings-ubuntu-common"
<ailion> When I refresh it's gone, but the error might be hidden by a loadblancer or something like that. Check the service if needed.
#ubuntu-devel 2020-03-05
<cpaelzer> bryce: nice to hear that so many things that we touched yesterday already migrated
<cpaelzer> I've checked the new tests of the list you sent - half of them fail still
<cpaelzer> the other half didn't run yet
<cpaelzer> I'll take look later once all are complete if they have a single root cause we could address
<mwhudson> good morning
<JackFrost> Heya.
<eoli3n> xnox: so there will be some default packages installed as snap packages in futur release ?
<eoli3n> because i didn't explictly installed any snap packages, so i should not have any /snap dir, am i right ?
<eoli3n> snapd is defaultly installed, i purged it
<doko> ricab_: source-higlight uploaded
<ricab_> doko: ?
<doko> ricab_, no ricotz
<ricab> right
<ricotz> doko, thx
<bdmurray> seb128: Do you have any plans for bug 1781597 as it is assigned to you?
<ubottu> bug 1781597 in network-manager (Ubuntu Bionic) "[SRU] WoWLAN settings are not supported" [Wishlist,Triaged] https://launchpad.net/bugs/1781597
<leaves> Hello, version 2.11.0~beta2-2 of my package opendkim is only now on its way into Debian testing. I see that the import freeze was end of February, does that mean my package has definitely missed the window to be in the LTS 20.04?
<juliank> leaves: well it needs manual sync now, and possibly a feature freeze exception first
<leaves> juliank: oh well. It was a bit of a milestone this version, but not that important at the end of the day. But thanks for the info.
<xnox> sil2100:  do you know who can review template import https://translations.launchpad.net/ubuntu/focal/+source/subiquity/+imports ?
<xnox> sil2100:  it should be imported into Template "subiquity" in Ubuntu Focal package "subiquity"
<xnox> sil2100:  not sure why it's not done automatically
<xnox> also not sure who uploaded that at 10am today
<xnox> but also they are the same
<xnox> vorlon:  did you upload subiquity.pot at 10:05am today?
<xnox> oooooh
<xnox> i think the imported one is by the build in focal-proposed
<xnox> and the second one is from proposed-migration
 * xnox ponders if we have tonnes of Needs Review template imports from all the package copies
<rbasak> I've started tagging every bug that seems somehow entangled with the openssl 1.0/1.1/TLS 1.3 stuff in Bionci with bionic-openssl-1.1.
<rbasak> ahasenack: ^
<rbasak> Since there are so many of them now, I thought it better to draw a wider net so we can find them all again than worry about exactly what the tag means.
 * ahasenack fetches 6
<rbasak> I'm also including resolved bugs because they might still be helpful in analysis/retrospective.
<xnox> rbasak:  i don't understand the meaning of the tag. is it about 1.1.0 or 1.1.1 series? for example why https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1794589 was tagged with that bug?
<ubottu> Launchpad bug 1794589 in openssl1.0 (Ubuntu Bionic) "libssl1.0-dev conflicts libssl-dev" [Medium,Won't fix]
<xnox> rbasak:  note that libssl1.0-dev has always conflicted with libssl-dev 1.1.x series (an in both 1.1.0 series and 1.1.1 series) and nothing was changed with the 1.1.1 sru
<xnox> rbasak:  which series is the bug about? 1.0.2, 1.1.0, 1.1.1, or certain combinations?
<ogra> sil2100, https://github.com/snapcore/pi-gadget/pull/33 (sorry for the many commits and reverts, i worked with a custoer on this and had to clean up the customer specific hacks to make it upstreamable)
<rbasak> xnox: I'm using it to track every complication related to there being two OpenSSLs in Bionic.
<rbasak> xnox: whether valid or not
<xnox> rbasak:  makes sense! "whether valid or not" => chuckle
<xnox> rbasak:  and like "whether it is actionable or not" i agree it is a bit of a mess for certain stacks, but equally not sure we can do anything about it. Apart from like backporting new nodejs 12
<xnox> LTS
<rbasak> not sure we can do anything> agreed
<rbasak> My thought is that by having all possible relevant bugs tagged, if there is some pattern or action we decide later, we can check it for applicability. Or also avoid missing something when we're documenting or doing any kind of retrospective, etc.
<bdmurray> marcustomlinson: What are you doing to bugs?
<bdmurray> marcustomlinson: I'm not appreciating all the email / changes to apport bugs.
<marcustomlinson> bdmurray: when youâre sitting on 1000 open bugs, is human triaging honestly possible anymore
<marcustomlinson> I'm trying to do 2 things:
<marcustomlinson> 1. reduce the backlog to something remotely manageable by humans.
<marcustomlinson> 2. ping old bugs to allow those effected to respond and put their bug back on the radar.
<bdmurray> marcustomlinson: you are making an assumption that things are fixed and from some of the bugs I've seen I know that are still not fixed
<marcustomlinson> bdmurray: I'm not assuming anything, I'm asking
<bdmurray> marcustomlinson: what set of criteria are you using to find bugs to ping?
<marcustomlinson> before 16.04 existed
<bdmurray> marcustomlinson: Bugs with status New and reported before April 2016?
<marcustomlinson> before october 2015
<bdmurray> and are you doing this for the whole distro?
<marcustomlinson> no just the 4 worst here: https://docs.google.com/spreadsheets/d/e/2PACX-1vRDHPxGBHqM6XkT_S8ggtYfD0xchKSUD_z9PopNVE3G1rU05fVSnxDGcDsEstl7gu7N-tzCU6mLUp2V/pubchart?oid=254968654&format=interactive
<bdmurray> How did apport end up on a desktop bugs list?
<bdmurray> The desktop team isn't subscribed to that package.
<marcustomlinson> that is a good question, and if that's the case, I'm very sorry
<marcustomlinson> I didn't know I was overstepping my team's packages
<bdmurray> If you could stop for apport that would be great and I'd reconsider changing a bug from Triaged to Incomplete.
<marcustomlinson> bdmurray: yeah I've stopped
<bdmurray> I can understand doing New but I think for Triaged bugs the burdern should be on us as developers not the reporter.
<marcustomlinson> fair point
<vorlon> xnox: I did not upload anything subiquity today, no
#ubuntu-devel 2020-03-06
<xnox> kanashiro:  so are you actively fixing FTBFS and autopkgtest failures to get ruby2.7 transition to actually migrate?
<xnox> kanashiro:  do you have a fix for vim FTBFS on arm64?
<xnox> or rafaeldtinoco?
<bdmurray> marcustomlinson: I'm still seeing apport bugs being modified
<marcustomlinson> bdmurray: I'm just responding to people
<marcustomlinson> if you'd like to handle that
<bdmurray> bug 1491128 was recently set to Invalid
<ubottu> bug 1491128 in apport (Ubuntu) "Doesn't allow to file a bug for mtr" [Undecided,Invalid] https://launchpad.net/bugs/1491128
<marcustomlinson> yeah I thought the guy deserved a response
<bdmurray> and bug 772336?
<ubottu> bug 772336 in Apport "Add feature to take screenshots of the buggy window" [Wishlist,Triaged] https://launchpad.net/bugs/772336
<marcustomlinson> that was 19 hours ago
<marcustomlinson> before we spoke
<bdmurray> weird, I just got the mail
<bdmurray> well that'll be exciting I wonder how much more mail is coming
<rbalint> bryce, if you run login just to show motd in lxc you may find show-motd interesting: https://twitter.com/balintreczey/status/1209270160479133696
<rbalint> bryce, it is available from eoan and up
<kanashiro> xnox, re ruby2.7 transition: yes, I am actively working on the regressions to make it migrate. And no, I didn't investigate vim FTBFS on arm64 yet
<LocutusOfBorg> kanashiro, after the mass retries the situation looks better on update_excuses page
<kanashiro> LocutusOfBorg, yes, I just saw that (and thanks for that), I am already working on patches to fix the remaining regressions
<LocutusOfBorg> thanks!
<xnox> kanashiro:  with either swig3.0 or swig4.0 subversion surby bindings fail to build, it looks like something is using assert() yet subversion compiles with -DNDEBUG somehwere, meaning assert() is not linked in the relevant .so objects
<kanashiro> xnox, right, I saw this assert error while I was trying to investigate the FTBFS
<xnox> kanashiro:  which might be coming from python3.8!
<ahasenack> subtitle for focal fossa: the entangled release
<gsedej> hi! Where can one report bugs in 20.04 installer?
<rbasak> gsedej: thank you for testing! Which installer? Desktop? Server?
<gsedej> desktop. should i ask in #ubuntu+1 or #ubuntu-bugs?
<rbasak> gsedej: yes please, if you have further questions. I think the answer to your question though is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug
<gsedej> rbasak, thank you
<LocutusOfBorg> kanashiro, xnox I retried vim/arm64, lets see what happens, maybe it was an error due to some entangling?
<LocutusOfBorg> btw nice to see how new icu fails with #include<libxml> stuff if extern "C" is defined
<LocutusOfBorg> doko ^^, http://launchpadlibrarian.net/467947562/scilab_6.1.0+dfsg1-1ubuntu2_6.1.0+dfsg1-1ubuntu3.diff.gz
<LocutusOfBorg> not sure if this is intended
<LocutusOfBorg> lots of /usr/include/unicode/ucnv.h:585:1: error: conflicting declaration of C function âvoid icu_66::swap(icu_66::LocalUConverterPointer&, icu_66::LocalUConverterPointer&)â
<LocutusOfBorg> and similar
<LocutusOfBorg> (vim was good on the first retry)
<LocutusOfBorg> xnox, kanashiro ^^
<kanashiro> LocutusOfBorg, yay \o/
<ahasenack> infinity: around? It's about that glibc bug https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864
<ubottu> Launchpad bug 1864864 in glibc (Ubuntu) "[SRU] pthread_rwlock_trywrlock results in hang" [Undecided,New]
<blackboxsw> rbasak: or others with gitfu skillz:    I've landed a commit in tip of master of the cloud-init that got attributed to the wrong author (me). Is there a sane way to ammend that author and/or commit message that doesn't risk breaking consumers of tip or master?
<blackboxsw> I know that git ammend will generate a new commitish for that commit... and that could cause problems where consumers may have to rebase (since we know of at least 2 vendors that run CI on our master branch, I'd be a bit concerned that this could impact their automation)
<blackboxsw> smoser: it's worth highlighting you too on this ^. Maybe it's not worth the trouble to fix this case?
<smoser> i don't think you can. i'd not bother.  I think there is another commit in cloud-init that has my attribution. I just apologized.
<smoser> humans suck
<blackboxsw> yeah, stinks, strange as it came in via a squash merge button press in github UI. not really sure how that happened in this case.
<blackboxsw> ahh well, will be more careful in the future.
<doko> LocutusOfBorg: we fixed that for 65 as well, nothing new. there is a surplus extern "C" iirc
<mwhudson> blackboxsw: i think github turned that feature off again
<xnox> ahasenack:  thank you for doing this!
<xnox> ahasenack:  please upload into bionic unapproved queue.
<bryce> One of the last php packages I'm trying to troubleshoot is uwsgi-plugin-php
<bryce> https://launchpadlibrarian.net/467781450/buildlog_ubuntu-focal-s390x.uwsgi-plugin-php_0.0.4build1_BUILDING.txt.gz
<bryce> it's ftbfs running the command `uwsgi --build-plugin /usr/src/uwsgi/plugins/php` which exits 1
<bryce> running it with -v, the error it gives is:
<bryce>   unable to load configuration from /usr/src/uwsgi/plugins/php
<bryce> this appears to work fine in Debian, per kanashiro
<bryce> I'm not sure what to do to get this to build
<bryce> I'm able to reproduce the error locally (as is kanashiro).
<bryce> one of the things that's unusual for uwsgi-plugin-php is that its source code is in a different package, uwsgi-src.
<bryce> I plan to look at it more next week, but meanwhile any tips/advice/pointers would be appreciated.
<rbasak> blackboxsw: you can leave a note as a correction
<rbasak> See git-notes(1)
<rbasak> But if you don't want to change the commit hash (you're right in doing that; that's inappropriate in a public master branch) then that's the most you can do I think
<blackboxsw> thanks rbasak!
#ubuntu-devel 2020-03-07
<rbasak> I used to be able to run sbuild with -pnever, and afterwards run schroot -r -c <chroot> to enter the chroot and find the build tree in /var/lib/sbuild/build
<rbasak> Now /var/lib/sbuild/build doesn't seem to be available inside the schroot
<rbasak> What changed, and how can I get to the sbuild build environment?
<rbasak> Ah, I found /build inside the schroot
<rbasak> That seems odd though, as it mismatches the sbuild log's use of var/lib/sbuild/build/
<JackFrost> It's been noted that pyyaml should likely be merged from Debian since it fixes a few CVEs, fwiw.
#ubuntu-devel 2020-03-08
<Logan> JackFrost: by whom has it been noted?
<JackFrost> Logan: ScottK in Debianland.
<Logan> looks like it can just be synced
<JackFrost> Indeed, backlog shows that tumble looked into it, and then ScottK did sync it.
<JackFrost> Logan: Nice to see you around, still. :)
<Logan> good to see you too :) Life got in the way of my MOTU work, but it's good to be getting back into it again
<JackFrost> Logan: Hmm, do you maintain anything in Debian?
<Logan> not at the moment, but I've considered it. Why?
<JackFrost> Just curious, you do so much with Ubuntu, or did last I saw the graph.
<Logan> being a MOTU doesn't involve as much commitment :P Although I have seen my fair share of Debian packages where the maintainers went MIA...
<JackFrost> Yep, though if you find a team to take it...
